Slide: 1

DO-178C : upcoming guidance for OOS

Cyrille Comar

SafeComp2009, Humburg, Sept 15, 2009

Slide: 2

Summary

• A few words on DO-178B

• Toward DO-178C

• Glimpse at the Tools Qualification Supplement

• Glimpse at the OOT Supplement

• Glimpse at the Formal Methods Supplement

Slide: 3

DO-178B

• Software Aspects of commercial aircraft certification(Aeronautic Industry vs FAA & EASA)

• Evidence must be shown for 80+ objectives encompassing:

– Planning & liaison with authorities

– Software Development

– Software Verification

– Configuration Management

– Quality Assurance

• Strong emphasis on– Requirement-based Testing

– Traceability of life cycle data

Slide: 4

DO-178B

• 5 levels (A to E) depending on the criticality of the software

• Higher levels means more– Detailed evidence

– Independence in verification

– Testing (Statement Coverage, Decision Coverage, MCDC)

ad hoc Standard verifying good Software Engineering Practices (of the 90s…)

Well adapted to traditional development in Ada83 or C

Slide: 5

DO-178C / ED-12C

• Working group: SC-205 (RTCA) WG-71 (EUROCAE)

• Final documents are owned jointly by RTCA & EUROCAE

• Goals:– Fix known issues in the official documents

– Take into account new trends in Software Engineering

• Past revisions:– 1982: DO-178 / ED-12

– 1985: DO-178A / ED-12A

– 1992: DO-178B / ED-12B

Slide: 6

TimeLine

• First plenary meeting early 2005 (in London)

• 14 plenary meetings between 2005 & 2010

• Meetings alternate between US & Europe

• Last Meeting in 06-2009 in Hartford CT

• Next Meeting in 10-2009 in Paris

2 0 1 0

Sarasota, Florida, Feb 8 Integration committee Final Plenary

Slide: 7

Participants

• The group is completely open, based on volunteer’s participation

• About 110 regular participants in 2009– Many one-time visitors

– Some plenary had more than 200 participants

• About ½ from the US and ½ from Europe– Europe: mostly GB, France, Germany, Sweeden

– Some participation from Brazil and recently China

• 3 main types of Participants– Industry (Boeing, Airbus, Lockeed, RC, Honeywell, Thales, Eurocopter, …)

– Authorities & DERs (FAA, EASA, Transport Canada, DGAC…)

– Tool vendors (LDRA, Esterel, Mathworks, AdaCore, Verocel, …)

Slide: 8

Organization

• 2 chairs (Jim Krodel & Gérard Ladier)

• 7 Subgroups:– SG1: SCWG Document Integration

– SG2: Issues & Rationale

– SG3: Tool Qualification

– SG4: Model Based Design & Verification

– SG5: Object Oriented Technology

– SG6: Formal Methods

– SG7: Safety Related Considerations (ground based systems)

• Subgroups work specific items– Based on original TOR & Issue list

– New supplements or changes to the core document

• Plenary vote for acceptance– “almost-unanimity” is the rule

Slide: 9

Expected Result(s)

DO-178B

DO-278

DO-248B DO-248C

DO-178Ccore

12.3

guidance

guidelines

Clarificationfixes

Clarificationfixes

MBDSuppl.

OOTSuppl.

FormalmethodsSuppl.

Tools Qual

Suppl

Overriding supplements

DO-278Acore

changesEquivalent to DO-178c

Slide: 10

Status as of Hartford Meeting

• Core DO-178c: some moderate changes to come

• Tools supplement : almost complete

• MBD supplement: ½ of the text approved

• OO supplement : ¾ of the text approved

• FM supplement : ¾ of the text approved

Most of the guidanceapproved

Slide: 11

Example of change in the Main Document : fig 2-1

DO-178B

SoftwarePlanning Process

System User / Functional Requirements

Functional Hazard AnalysisPrel. System Safety Assessment

Functional/Req. Allocations

Software Requirements Process

Software Coding and Integration Processes

Software DesignProcess

Sys

tem

Des

ign

and

V&

V p

roce

ss /

Saf

ety

Ass

essm

ent P

roce

ss

Sof

twar

e L

ife

Cyc

le P

roce

sses

Other processes

SoftwareVerification Process

System V&V Activities

System Safety

Assessment

System requirements allocated to S/WS/W Development Assurance LevelHardware Definition

Other Requirements

System ApprovalActivities

Compliance Data

DerivedHigh LevelRequirements

Derived Low Level Requirementsand Software Architecture

DO-178C

Slide: 12

Tool Qualification Supplement

DO-178B

2 cases

Development Tool

Verification Tool

DO-178C

3 criteria & 5 levels (TQL)

Criteria 1

Criteria 2

Criteria 3

Could insert an error

Could fail to detect an error and is used to reduce other development or verification activities

Could fail to detect an error

Qualification needed when processes are eliminated, reduced or automated without manual verification

Slide: 13

Tool Qualification Supplement (2)

Examples of “Criteria 2 vs Criteria 3”

Proof Tool

Static Analysis Tool

Source code verification+

reduce robustness testing

Level 3

Level 2

Source code review+

Remove defensive code

Level 3

Level 2

Slide: 14

Tool Qualification Supplement (3)

Software Level

Criteria

1 2 3

A TQL-1 TQL-4 TQL-5

B TQL-2 TQL-4 TQL-5

C TQL-3 TQL-5 TQL-5

D TQL-4 TQL-5 TQL-5

Mostly for formal methods & MBD

TQL 1: do-178 level A

TQL 2: do-178 level B

TQL3: do-178 level C

TQL4 : complete requirementsdescribe architecturemore verifications

TQL5 : TOR verification

Slide: 15

OOT Supplement

• Very few changes related to DO-178B

• Addresses more than pure OOT stuff– Memory management (e.g. garbage collection)

– Exception management

– Generics (parametric polymorphism)

– Virtualization techniques

• One significant additional objective: “Local Type Consistency Verification”

• Many guidelines– Can be addressed by proper Design/Coding standards

Slide: 16

Local Type Consistency Verification

• 3 choices are given:

– Formally verify substitutability

– Ensure that each class pass all the tests of its parent types that the class can replace

– For each call point, test every method that can be invoked (pessimistic testing approach)

• Rationale:– Usual Structural Coverage Analysis not sufficient in presence of dynamic

dispatch

Liskov Substitution Principle

Slide: 17

Memory Management

• The bar is pretty high but it makes it possible to use sound real-time garbage collectors

• All typical vulnerabilities of memory managers are to be verified:

– Ambiguous references

– Fragmentation

– Deallocation starvation

– Heap memory exhanstion

– Premature deallocation

– Time bound allocation & deallocation

– …

Slide: 18

Virtualization

• What is code and what is data ?– Many objectives apply to code (… and not to data…)

“Any time that data, when interpreted, provides control flow for the executable program, virtualization is being used”

• Each virtualization layer must be verified on its own

Slide: 19

Formal Methods Supplement

• Many activities can be achieved by formal methods– Requirements consistency, correctness & review

– Source code review and compliance with LLR

– Test cases covering the LLR

– …

• Some (but not all) testing can be replaced by formal verification

Slide: 20

What about formal verification of the source code?

• Can it be used to alleviate testing?– No. What runs of the target hardware is the object code not the source

code!

… but … there is an escape clause:

<< Formal analysis of source code can be used to reach [compliance with LLR] provided that complementary analyses show the property preservation between source code and object code>>