<ul><li>DO-178C :  upcoming guidance for OOS </li></ul><ul><li>Cyrille Comar </li></ul><ul><li>SafeComp2009, Humburg, Sept...
Summary <ul><li>A few words on DO-178B </li></ul><ul><li>Toward DO-178C </li></ul><ul><li>Glimpse at the Tools Qualificati...
DO-178B  <ul><li>Software Aspects of commercial aircraft certification (Aeronautic Industry vs FAA & EASA) </li></ul><ul><...
DO-178B <ul><li>5 levels (A to E) depending on the criticality of the software </li></ul><ul><li>Higher levels means more ...
DO-178C / ED-12C <ul><li>Working group: SC-205 (RTCA)  WG-71 (EUROCAE) </li></ul><ul><li>Final documents are owned jointly...
TimeLine <ul><li>First plenary meeting early 2005 (in London) </li></ul><ul><li>14 plenary meetings between 2005 & 2010 </...
Participants <ul><li>The group is completely open, based on volunteer’s participation </li></ul><ul><li>About 110 regular ...
Organization <ul><li>2 chairs (Jim Krodel & Gérard Ladier) </li></ul><ul><li>7 Subgroups: </li></ul><ul><ul><li>SG1: SCWG ...
Expected Result(s) <ul><li>DO-178B </li></ul>DO-278 DO-248B DO-248C DO-178C core 12.3 guidance guidelines Clarification fi...
Status as of Hartford Meeting <ul><li>Core DO-178c: some moderate changes to come </li></ul><ul><li>Tools supplement : alm...
Example of change in the Main Document : fig 2-1  DO-178B DO-178C
Tool Qualification Supplement <ul><li>DO-178B </li></ul><ul><li>2 cases </li></ul><ul><li>Development Tool </li></ul><ul><...
Tool Qualification Supplement (2) <ul><li>Examples of “Criteria 2 vs Criteria 3” </li></ul><ul><li>Proof Tool </li></ul><u...
Tool Qualification Supplement (3) <ul><li>Mostly for formal methods & MBD </li></ul>TQL 1: do-178 level A  TQL 2: do-178 l...
OOT Supplement <ul><li>Very few changes related to DO-178B </li></ul><ul><li>Addresses more than pure OOT stuff </li></ul>...
Local Type Consistency Verification <ul><li>3 choices are given: </li></ul><ul><ul><li>Formally verify substitutability </...
Memory Management <ul><li>The  bar is pretty high but it makes it possible to use sound real-time garbage collectors </li>...
Virtualization <ul><li>What is code and what is data ? </li></ul><ul><ul><li>Many objectives apply to code (… and not to d...
Formal Methods Supplement <ul><li>Many activities can be achieved by formal methods </li></ul><ul><ul><li>Requirements con...
What about formal verification of the source code? <ul><li>Can it be used to alleviate testing? </li></ul><ul><ul><li>No. ...
Upcoming SlideShare
Loading in …5
×

DO 178C Upcoming Guidance for OOS

4,174 views

Published on

Cyrille Comar looks at how the upcoming DO-178C standard will effect tool-qualification, OTT and formal methods.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

DO 178C Upcoming Guidance for OOS

  1. 1. <ul><li>DO-178C : upcoming guidance for OOS </li></ul><ul><li>Cyrille Comar </li></ul><ul><li>SafeComp2009, Humburg, Sept 15, 2009 </li></ul>
  2. 2. Summary <ul><li>A few words on DO-178B </li></ul><ul><li>Toward DO-178C </li></ul><ul><li>Glimpse at the Tools Qualification Supplement </li></ul><ul><li>Glimpse at the OOT Supplement </li></ul><ul><li>Glimpse at the Formal Methods Supplement </li></ul>
  3. 3. DO-178B <ul><li>Software Aspects of commercial aircraft certification (Aeronautic Industry vs FAA & EASA) </li></ul><ul><li>Evidence must be shown for 80+ objectives encompassing: </li></ul><ul><ul><li>Planning & liaison with authorities </li></ul></ul><ul><ul><li>Software Development </li></ul></ul><ul><ul><li>Software Verification </li></ul></ul><ul><ul><li>Configuration Management </li></ul></ul><ul><ul><li>Quality Assurance </li></ul></ul><ul><li>Strong emphasis on </li></ul><ul><ul><li>Requirement-based Testing </li></ul></ul><ul><ul><li>Traceability of life cycle data </li></ul></ul>
  4. 4. DO-178B <ul><li>5 levels (A to E) depending on the criticality of the software </li></ul><ul><li>Higher levels means more </li></ul><ul><ul><li>Detailed evidence </li></ul></ul><ul><ul><li>Independence in verification </li></ul></ul><ul><ul><li>Testing (Statement Coverage, Decision Coverage, MCDC) </li></ul></ul><ul><li>ad hoc Standard verifying good Software Engineering Practices (of the 90s…) </li></ul><ul><li>Well adapted to traditional development in Ada83 or C </li></ul>
  5. 5. DO-178C / ED-12C <ul><li>Working group: SC-205 (RTCA) WG-71 (EUROCAE) </li></ul><ul><li>Final documents are owned jointly by RTCA & EUROCAE </li></ul><ul><li>Goals: </li></ul><ul><ul><li>Fix known issues in the official documents </li></ul></ul><ul><ul><li>Take into account new trends in Software Engineering </li></ul></ul><ul><li>Past revisions: </li></ul><ul><ul><li>1982: DO-178 / ED-12 </li></ul></ul><ul><ul><li>1985: DO-178A / ED-12A </li></ul></ul><ul><ul><li>1992: DO-178B / ED-12B </li></ul></ul>
  6. 6. TimeLine <ul><li>First plenary meeting early 2005 (in London) </li></ul><ul><li>14 plenary meetings between 2005 & 2010 </li></ul><ul><li>Meetings alternate between US & Europe </li></ul><ul><li>Last Meeting in 06-2009 in Hartford CT </li></ul><ul><li>Next Meeting in 10-2009 in Paris </li></ul>2 0 1 0 Sarasota, Florida, Feb 8 Integration committee Final Plenary
  7. 7. Participants <ul><li>The group is completely open, based on volunteer’s participation </li></ul><ul><li>About 110 regular participants in 2009 </li></ul><ul><ul><li>Many one-time visitors </li></ul></ul><ul><ul><li>Some plenary had more than 200 participants </li></ul></ul><ul><li>About ½ from the US and ½ from Europe </li></ul><ul><ul><li>Europe: mostly GB, France, Germany, Sweeden </li></ul></ul><ul><ul><li>Some participation from Brazil and recently China </li></ul></ul><ul><li>3 main types of Participants </li></ul><ul><ul><li>Industry (Boeing, Airbus, Lockeed, RC, Honeywell, Thales, Eurocopter, …) </li></ul></ul><ul><ul><li>Authorities & DERs (FAA, EASA, Transport Canada, DGAC…) </li></ul></ul><ul><ul><li>Tool vendors (LDRA, Esterel, Mathworks, AdaCore, Verocel, …) </li></ul></ul>
  8. 8. Organization <ul><li>2 chairs (Jim Krodel & Gérard Ladier) </li></ul><ul><li>7 Subgroups: </li></ul><ul><ul><li>SG1: SCWG Document Integration </li></ul></ul><ul><ul><li>SG2: Issues & Rationale </li></ul></ul><ul><ul><li>SG3: Tool Qualification </li></ul></ul><ul><ul><li>SG4: Model Based Design & Verification </li></ul></ul><ul><ul><li>SG5: Object Oriented Technology </li></ul></ul><ul><ul><li>SG6: Formal Methods </li></ul></ul><ul><ul><li>SG7: Safety Related Considerations (ground based systems) </li></ul></ul><ul><li>Subgroups work specific items </li></ul><ul><ul><li>Based on original TOR & Issue list </li></ul></ul><ul><ul><li>New supplements or changes to the core document </li></ul></ul><ul><li>Plenary vote for acceptance </li></ul><ul><ul><li>“ almost-unanimity” is the rule </li></ul></ul>
  9. 9. Expected Result(s) <ul><li>DO-178B </li></ul>DO-278 DO-248B DO-248C DO-178C core 12.3 guidance guidelines Clarification fixes Clarification fixes MBD Suppl. OOT Suppl. Formal methods Suppl. Tools Qual Suppl Overriding supplements DO-278A core changes Equivalent to DO-178c
  10. 10. Status as of Hartford Meeting <ul><li>Core DO-178c: some moderate changes to come </li></ul><ul><li>Tools supplement : almost complete </li></ul><ul><li>MBD supplement: ½ of the text approved </li></ul><ul><li>OO supplement : ¾ of the text approved </li></ul><ul><li>FM supplement : ¾ of the text approved </li></ul>Most of the guidance approved
  11. 11. Example of change in the Main Document : fig 2-1 DO-178B DO-178C
  12. 12. Tool Qualification Supplement <ul><li>DO-178B </li></ul><ul><li>2 cases </li></ul><ul><li>Development Tool </li></ul><ul><li>Verification Tool </li></ul>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
  13. 13. Tool Qualification Supplement (2) <ul><li>Examples of “Criteria 2 vs Criteria 3” </li></ul><ul><li>Proof Tool </li></ul><ul><li>Static Analysis Tool </li></ul>Source code verification + reduce robustness testing Level 3 Level 2 Source code review + Remove defensive code Level 3 Level 2
  14. 14. Tool Qualification Supplement (3) <ul><li>Mostly for formal methods & MBD </li></ul>TQL 1: do-178 level A TQL 2: do-178 level B TQL3: do-178 level C TQL4 : complete requirements describe architecture more verifications TQL5 : TOR verification 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
  15. 15. OOT Supplement <ul><li>Very few changes related to DO-178B </li></ul><ul><li>Addresses more than pure OOT stuff </li></ul><ul><ul><li>Memory management (e.g. garbage collection) </li></ul></ul><ul><ul><li>Exception management </li></ul></ul><ul><ul><li>Generics (parametric polymorphism) </li></ul></ul><ul><ul><li>Virtualization techniques </li></ul></ul><ul><li>One significant additional objective: </li></ul><ul><ul><li>“ Local Type Consistency Verification” </li></ul></ul><ul><li>Many guidelines </li></ul><ul><ul><li>Can be addressed by proper Design/Coding standards </li></ul></ul>
  16. 16. Local Type Consistency Verification <ul><li>3 choices are given: </li></ul><ul><ul><li>Formally verify substitutability </li></ul></ul><ul><ul><li>Ensure that each class pass all the tests of its parent types that the class can replace </li></ul></ul><ul><ul><li>For each call point, test every method that can be invoked (pessimistic testing approach) </li></ul></ul><ul><li>Rationale: </li></ul><ul><ul><li>Usual Structural Coverage Analysis not sufficient in presence of dynamic dispatch </li></ul></ul>Liskov Substitution Principle
  17. 17. Memory Management <ul><li>The bar is pretty high but it makes it possible to use sound real-time garbage collectors </li></ul><ul><li>All typical vulnerabilities of memory managers are to be verified: </li></ul><ul><ul><li>Ambiguous references </li></ul></ul><ul><ul><li>Fragmentation </li></ul></ul><ul><ul><li>Deallocation starvation </li></ul></ul><ul><ul><li>Heap memory exhanstion </li></ul></ul><ul><ul><li>Premature deallocation </li></ul></ul><ul><ul><li>Time bound allocation & deallocation </li></ul></ul><ul><ul><li>… </li></ul></ul>
  18. 18. Virtualization <ul><li>What is code and what is data ? </li></ul><ul><ul><li>Many objectives apply to code (… and not to data…) </li></ul></ul><ul><ul><li>“ Any time that data, when interpreted, provides control flow for the executable program, virtualization is being used” </li></ul></ul><ul><li>Each virtualization layer must be verified on its own </li></ul>
  19. 19. Formal Methods Supplement <ul><li>Many activities can be achieved by formal methods </li></ul><ul><ul><li>Requirements consistency, correctness & review </li></ul></ul><ul><ul><li>Source code review and compliance with LLR </li></ul></ul><ul><ul><li>Test cases covering the LLR </li></ul></ul><ul><ul><li>… </li></ul></ul><ul><li>Some (but not all) testing can be replaced by formal verification </li></ul>
  20. 20. What about formal verification of the source code? <ul><li>Can it be used to alleviate testing? </li></ul><ul><ul><li>No. What runs of the target hardware is the object code not the source code! </li></ul></ul><ul><ul><li>… but … there is an escape clause: </li></ul></ul><ul><ul><li><< 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>> </li></ul></ul>

×