WIND FORUM KOREA 2017 Multicore and the Challenges of Certification

WIND FORUM KOREA 2017

Multicore and the Challenges

of Certification

 윈드리버 코리아 장승한 차장

AGENDA

 The Certification Process

 COTS Multi-core hardware and software

– Integrating CAST-32A guidelines

 Common misconceptions and best practices

 Building a low-risk certification strategy

 Using affordable COTS software foundations

 Leveraging COTS RTCA DO-178C DAL A certification evidence with

Software Certification Process

Exciting, fast, easy, or simple?

 No!

– it is hard work, time-consuming, extremely detailed and expensive

 Result?

– For the most recent Wind River certification project:

Requirements > Implementation > Verification

Aircraft level Requirements Aircraft level verification System level Requirements Subsystem Requirements (High Level) SW and HW requirements (Low Level) Source Code Implementation SW and HW verification Subsystem verification System verification Verify Design

Production Testing/Result  Code  Code reviews  Test cases  Test case reviews  PSAC  SDP  SCMP  SQA  SVP  Standards  SRS (HLRs)  SDD  SRS (LLRs)  RTD  STP  Reviews  Test Harness  Test case results  Code coverage test and results  SAS  SVA*  Partitioning Analysis*  SCI  Traceability matrix

DO-178C Cert Evidence Deliverables

DO-178C Certification Evidence applies to:

Generic Operating System and Services and Standard C lib Applicable to a specific processor (e.g., ARM A9, QorIQ T2080)

* SVA and Partitioning Analysis are specific to an architecture

Implementation and Test Definition

 6

 Plan for Software Aspects of Certification (PSAC)

 Software Quality Assurance Plan

 Software Configuration Management Plan (SCMP)

 Software Development Plan (SDP)

– Software requirements standards

– Software design standards

– Software coding standards

 Software Verification Plan (SVP)

 Software Requirements Specification (SRS)

 Software Design Document (SDD)

 Version Description Document (VDD)

 Traceability Matrix

 Software Development Folder

– Design reviews

– Code reviews

– Test reviews (7,500 tests)

– Functional tests (270,000 LOC)

– Coverage results (object level)

 Tool Qualification Documentation

– Development and verification tools

 Software Accomplishment Summary (SAS)  Software Vulnerability Analysis

(will be required by DO-178C)

2.2GB sealed DVD with more than 65,000 hyperlinked

files.

Production Testing/Result Implementation and Test Definition Project Startup

Design and methodology

considerations

MULTI-CORE AND SYSTEM CERTIFICATION

TODAY’S CHALLENGES

 Reduce cost of development, deployment, and system maintenance

 Robust standardized platforms with common skills, tools, and certification

 System consolidation, A380-1000 – 10,000 sensors in each wing

Affordability

 Cycle time is total time from beginning to end of the project

 Projects start with a predicted technology readiness level

 Reuse of software, test assets, and system simulation

Cycle Time Reduction

 Conformance to safety, security, and industry standards across projects

 Reduce regulatory pressures as market and capabilities expand

Regulatory Compliance

FEDERATED VS. INTEGRATED MODULAR AVIONICS (IMA)

Federated Architecture

Advantages

 Independence of design and certification  Well-understood methodology

 Established supply chain

Challenges

 Greater size, weight, and power (SWaP) requirements

 Each function associates with a separate LRU

 Less software reuse

 Less portability, less modularity

IMA

Advantages

 Lower SWaP requirements

– Multiple functions on a single LRU

 Better software reuse  Better portability  Better modularity

Challenges

 Greater complexity of system integration  Greater complexity of design and certification  Inexperienced supply chain

Flight

Control Displays

ARINC 429, MIL-STD-1553B, ARINC 664

Mission Systems Flight Control Mission Systems Displays

DO-178C Failure Conditions

Failure Condition Level

(% of Avionics SW*)

Catastrophic (May be total loss of life) Level A

(35%)

Hazardous/Severe (May be some loss of life) Level B

(30%)

Major

(May be serious injuries) Level C

(20%)

Minor

(May be minor injuries) Level D

(10%)

No Effect

(No impact on passenger or aircraft safety) Level E (5%) Process Objectives 66 65 57 28 0 Code Coverage Required Level B + 100% of conditions (MCDC) Level C + 100% of decisions Level D + 100% of lines 100% of requirements None

TRADITIONAL INTEGRATED MODULAR AVIONICS SYSTEM

Safety Systems Are Mature

 Multiple levels of criticality

 Multiple cores for separation

 Time and space partitioning – ARINC 653 standard  Abstraction interface – ARINC 653 APIs – VxWorks APIs – POSIX APIs  DO-178C certification

MANAGING CONTENT

 Managing contention between

cores for shared resources

 Application isolation and determinism

– Core Deactivation

– Multi-core Interference

– Error Handling

Figure 2. Benchmarks results for dual core operation with single memory controller

Figure 1. Benchmark results for single core operation

Figure 3. Benchmarks results for dual core operation with dual memory controller

Multi-core System Issues

 Contention makes it difficult to prove that timing constraints are met

 Most SoCs uses hardware that is shared between cores

 Designs and effects of sharing are often unavailable

 Sharing effects may change as SoC microcode is updated

 Addressing these issues can involve additional cert effort

Performance and certification costs depend on matching the choice of strategies of the multicore hardware and the software application

Certification Authorities Software Team -- CAST-32A

(Multi-Core Processors)

 FAA-published guidance on usage of multi-core processors in aviation

 Available free on FAA website

 Topics Applicable to Multi-Core Processors (MCP) in Safety-Critical Applications

– Sixteen objectives on MCP Determinism

– Six objectives for MCP Software

– Two objectives for MCP Error Handling

– CAST paper addresses only 2 cores at this time, but is largely applicable to more than 2 cores

– Wind River Verification Activities will support many objectives, but

integrators will need to conduct additional activities to ensure compliance

Released November 2016

CAST-32A Appendix has mapping from CAST 32 to 32A

Common misconceptions

to avoid

The minimalist

“

Since this has been certified

before, why can’t we reuse

all the artifacts.

“

Any new code, has to go through the process

 All new features must adhere to the process

 Defects can be found in any stage of the process

 A code defect can end up modifying or adding requirements

 A test case may not capture the requirement

 Always keep an eye on safety in the process

 Every DER is different, and will see different things

The schedule hound

“

What can we cut to keep the

schedule? Lets minimize

the verification… We know it

works in other programs.

“

Saving testing till the end

 Continuous incremental testing is a key.

– Test for credit can be stored, but don’t wait to long.

 Discovery of a failure near the end of a program can cause churn and

possibly respin of a requirement.

Best Practices

Software Requirements

“

many of the problems

encountered in software

development come from

poorly defined system

requirements and architecture.

“

Leanna Rierson; Author of Developing Safety Critical Software

Spend time on requirements

 Requirements must be unambiguous

 Requirements should be short

 Requirements should not overlap

 Requirements should be testable

Train your people

 Establish a training curriculum

 Train on a regular basis for newcomers

 When a new DER is involved, they may find a common mistake, make

sure to update the curriculum.

Track your progress

 Estimate how many requirements are needed

– Add additional requirements as needed.

 Track them through the phases

– Draft

– In Review – Reviewed – Approved

Modularize to Reduce Recert Costs

 Decouple components  Isolate changes – Implementation of a module – Underlying physical transports  Promote reuse Operating System DDS Middleware UDP T CP Sh mem Qs/ po rts Modul e Modul e Modul e Operating System Transport & Proximity Assumption (e.g., queues, ports,

shmem or TCP)

Application Code

Custom Logic for IPC & Integration

Use certified COTS components

 Integrate certification evidence packages into your own project

 Reduce project risk

How Wind River fits

MARKET DRIVERS

Safety and Security

Risk Reduction

Regulatory

Affordability

WHY WIND RIVER?

Reputation

Balance of features

Safety and Security

Certification Evidence

VXWORKS 653 FOR IMA

 Complies with industry specification ARINC 653 for integrated modular avionics (IMA)

 ARINC 653 compliance with:

• ARINC 653 APEX APIs

• Time and space partitioning

• Inter- and intra-partition communications (IPC)

 VxWorks 653

• 3-level health management system (error detection and reporting)

• COTS RTCA DO-178C DAL A certification evidence

• FACE operating system segment (OSS) conformance

• Independent supplier build for DO-297 support

• XML complier qualified as a development tool for robust XML configuration

• Support for ARINC 653, VxWorks, POSIX, Ada, Java, third-party API partition environments

• More …

Flight

Control Radar Graphics Time and Space Partitioning

VXWORKS 653 FOCUS

Safety first: Partitioning with MMU and hardware virtualization assist, deterministic software, strict communications

PARTITIONING

PORTABILITY

CERTIFICATION

STANDARDS

Portable, reusable software: From “simple” systems to complex systems and next-generation virtualized multi-core platforms

Commercial off-the-shelf (COTS) certification evidence to support rapid customer certification, reliability, and quality

Conformance with global avionics, and business safety standards ARINC 653, POSIX, FACE, DO-178C, DO-297, more

VXWORKS 653

COTS DO-178C CERTIFICATION AND FACE CONFORMANCE

COTS RTCA DO-178C DAL A Certification Evidence Available

F ed er ated 2000 2017 VxWorks Cert DO-178 Level A IEC-61508 SIL 3 PowerPC 750 PowerPC 74xx PowerPC 8245 VxWorks Cert DO-178 Level B Intel Pentium III VxWorks Cert DO-178 Level A IEC-61508 SIL 3 PowerPC MPC8349E PowerPC MPC7447 Intel Core 2 Duo*

* Denotes single core operation

VxWorks Cert DO-178 Level A IEC-61508 SIL 3 PowerPC MPC8349E PowerPC MPC7447 Intel Core 2 Duo* Intel Atom* VxWorks 653 DO-178 Level A PowerPC 750 PowerPC 74xx VxWorks 653 DO-178 Level A PowerPC 750GX VxWorks 653 DO-178 Level A PowerPC MPC8349E PowerPC MPC8560 VxWorks 653 DO-178 Level A PowerPC MPC8641D* PowerPC MPC8270 VxWorks 653 DO-178 Level A PowerPC MPC8349E PowerPC 750GX VxWorks Cert DO-178 Level A IEC-61508 SIL 3 PowerPC 750GX PowerPC MPC8548 (e500v2) PowerPC 8280 VxWorks 653 DO-178 Level A PowerPC P4080* (e500mc) PowerPC MPC8548 (e500v2) VxWorks 653 DO-178 Level A + FACE PowerPC P4080* (e500mc)

VXWORKS RTOS CERTIFICATION HISTORY

VxWorks 653 Multi-core Edition

DO-178 Level A

PowerPC T2080 (e6500)

INTEGRATED MODULAR AVIONICS (IMA) WITH

VXWORKS 653 MULTI-CORE EDITION

ARINC Ports

Our heritage: More than 17 years of success in avionics

VxWorks Cert 5.4 released - Platform for Safety Critical DO-178B 1.x, VxWorks 61508 Platform 2.x

2000

VxWorks 653 1.x release – including DO-178B Certification Evidence Packages

2004

2005 VxWorks 653 2.x Evidence release for DO-178B Certification

2007 VxWorks Cert 6.x release with DO-178B/C Certification Evidence Packages

IEC61508 Certification Evidence Packages

2009 VxWorks 653 2.3VxWorks 653 3.0 Wind River DO-178B Network Stack

2014 VxWorks 653 3.0 Wind River DO-178B Network Stack

Today Works 653 3.0 DO-178C DAL A Certification Evidence Package

WIND RIVER A&D LEADERSHIP



More than 600 global Aerospace & Defense customers



More than 500 certification projects served



Over 2 billion devices deployed

SUMMARY

 The Certification Process

 Multi-core and system certification

 Common misconceptions and best practices

Multi-Core Certification: A systems approach

 We cannot possibly fully verify the behavior of a complex SoC using only

the low-level techniques of DO-178 or DO-254

– Economically and technically not viable

 As the silicon designs shrink, exposure to SEU or transient errors

increase

– More time and effort will need to be devoted to understanding the impact of soft errors

 A systems-level approach would augment/replace some DO-xxx activities

– Relies more heavily on systems analysis and design techniques similar to that for aircraft and avionics-level certification

Partitioning Requires Role-Based

Development and Delivery

Engineering teams and processes are organized around three roles per DO-297 1. Platform Supplier 2. Application Supplier 3. System Integrator Enabling: • Independent configuration,

build, link, and load processes for each role

• Engineering teams work independently, in parallel, asynchronously

• Components can be evaluated and re-evaluated independently Brakes Partitioning Kernel Configuration Vectors

Certification Hardware Platform

NS XML Middle-ware (MW) Network Stack (NS) MW XML MM XML Mission Mgmt. (MM) Graphics Display Systems (GD) GD XML Flight Control (FC) FC XML

Integrated Modular Avionics (IMA) with VxWorks 653

User Mode Kernel Mode ARINC 653 Partition OS Flight Control (FC) Application Level A POSIX Partition OS VxWorks Partition OS Ada/Java Partition OS Radar Application Level B Graphics Generator Application Level C Display Application Level D

Supplier 1 Supplier 2 Supplier 3 Supplier 4

Hardware VxWorks 653

Application Executive XML Configuration Data

Board Support Package (BSP) Architecture Support

Independent software delivery / DO-297

User Mode Kernel Mode ARINC 653 Partition OS Flight Control (FC) Application Level A POSIX Partition OS VxWorks Partition OS Ada/Java Partition OS Radar Application Level B Graphics Generator Application Level C Display Application Level D Application Suppliers Platform Supplier

Supplier 1 Supplier 2 Supplier 3 Supplier 4

Hardware VxWorks 653

Application Executive XML Configuration Data

Board Support Package (BSP) Architecture Support Package (ASP) IMA System Integrator

VxWorks 653 3.x Multi-core Edition (MCE)

Hypervisor

User Mode Kernel Mode ARINC 653 Guest OS Flight Control (FC) Application Level A VxWorks Guest OS Linux Guest OS Third Party Guest OS Radar Application Level B Graphics Generator Application Level C Display Application Level D

Supplier 1 Supplier 2 Supplier 3 Supplier 4

Hardware VxWorks 653

Multi-core Hypervisor XML Configuration Data

Board Support Package (BSP) Architecture Support