DO-178C: the OOT supplement
-
Upload
adacore -
Category
Technology
-
view
2.181 -
download
3
description
Transcript of DO-178C: the OOT supplement
Cyrille [email protected]
Content
Scope & History
Structure of the Document
The new objectives & activities
Conclusion
Software
ScopeWhy a need for an OOT Supplement?
- Very little text about programming techniques in DO-178B
OO Certifiable
80s-90s
Software
ScopeWhy a need for an OOT Supplement?
- Very little text about programming techniques in DO-178B
- -178B objectives & activities appropriate when using OO techniques?
OOCertifiable
2000-2010
HistoryOOTiA
- 2 workshops in 2002 & 2003 4 documents in 2004
-
- Many OO programming guidelines (wrong level for DO-178)
-
Other Input Documents
- CAST 4 (http://www.faa.gov/aircraft/air_cert/design_approvals/air_software/cast/cast_papers/)
- FAA OO Issue Papers
- EASA OO CRIs
- FAA sponsored Research study: DOT/FAA/AR-02/113 (http://www.faa.gov/aircraft/air_cert/design_approvals/air_software/research/)
Is this supplement only about OO?
Some programming features are not specific to OO but are
common in OO languages and not properly addressed in DO-178 :
- genericity
- overloading
- exception management
- memory management
Scope
Subgroup 5
- 15 persons in average (significant turnover)
-
- Little participation from major OOTiA actors
- Mix of
- Industrial Users ( OO ++, Certif --)
- Tool providers
- DERs (OO --, Certif ++)
Structure of the Document
OO.1.6
OO.2
OO.12
Annexes
AppendixesOO.C.1-6
OO.C.7-8DP#1DP#2
Characteristics of OO&RT
Overridings of DO-178C core
Overridings of DO-178C Tables
Glossary
Overridings of DO-178C Tables
FAQs
Vulnerability and Guidelines
Most of the new text is here
OO.4 < 20 linesOO.5 < 20 linesOO.6 < 3 pagesOO.11 < 1 page
Can be deduced from the rest (particularly OO.D)
Planning & Development Processes
Virtualization layers
Planning
Component reuse
Design- HLR Class Hierarchy- LLR + Class Hierarchy Type Consistency- Exception Management Strategy- Memory Management Strategy- Reuse & Deactivation
Appendix OO.C7 & OO.C8
1.Key Features-
-
-
-
-
-
-
2.General Issues-
-
-
-
Guidance Guidelines
New objective+activities(OO.4.2, OO.5.2.2, OO.6.6)
Design standard
none Separate instance verif
none Code Standard
One word(OO.6.3.4.f)
Code Standard & Review
Enhanced activities(OO.4.2.b, OO.5.2.2.d, OO.6.3.3.a)
Design Standard
New Objective+Activities(OO.4.2, OO.5.2.2, OO.6.7)
Design Standard
Clarification(OO.4.2.a)
Layered certif evidence
Clarification(OO.5.5)
none Data & Control coupling
Clarification(OO.4.2.b, OO.5.2.2.e)
Extensive (redundant)
None Extensive (redundant)
OO.6.7: Local Type Consistency Verification
How to Address verification of dynamic dispatch ?
Is Statement Coverage a good measure?
Do_Something (Object : C1)
Object.M ();
Do_Something_Else (Object : C2)
Object.M ();
Do_Something (Object : C1)
case is=> Object.C1::M ();=> Object.C2::M ();
end case;
Do_Something_Else (Object : C2)
case is=> Object.C1::M ();=> Object.C2::M ();
end case;
Do_Something (Object : C1)
Dispatch_M (C1);
Do_Something_Else (Object : C2)
Dispatch_M (C2);
Dispatch_M (Object : C1)case is
=> Object.C1::M ();=> Object.C2::M ();
end case;
pessimistic optimistic
OO.6.7: Local Type Consistency Verification (2)
Class C1Method M
Class C3overriding Method M
Class C2inherited Method M
Class C4overriding Method M
Do_Something (Object : C1)
-‐-‐ precondition: what does the context provide to MObject.M ();-‐-‐ postcondition: what is M contribution to the context
-
- it provides as much to the context (postcondition strengthening)
Local Type Consistency (3)3 possible activities:
-- Define explicit annotations (Pre/Postconditions, invariants)- Annotations must be complete & correct- Prove theorem on Pre & Post
- Verify substitutability by (unit) testing- LLRs are associated to Class methods- Run LLR tests associated with superclass on subclass
- Pessimistic Testing- New coverage criteria for dispatching call- any method invocation must be covered at each dispatch point
OO.6.8: Dynamic Memory Management
7 activities corresponding to usual vulnerabilities:- Reference Ambiguity- Fragmentation Starvation- Deallocation Starvation- Heap exhaustion- Premature Deallocation- Lost Update (Moving GCs)- Time bound on alloc/dealloc
4 Types of Dynamic Allocation Considered- Object Pooling- Stack/Scope Allocation- Manual Heap allocation- Automatic Heap Allocation (GC)
VirtualizationWhat is Code & what is Data ?
OO4.2.a : Any time that data, when interpreted, provides control flow for the executable program, virtualization is being usedLayered Verification
Virtualization Software to be certified at appropriate levelSame for Virtualized Software
Interpreted Language Java Byte Code State Machine
Language Interpret JVM SM interpretLayer 1
Layer 2
Design & Code Standards
Restrict Static Dispatch (vs Dynamic dispatch, see Faq #23)
Restrict parametric polymorphism
Restrict overloading & implicit type conversions
Restrict downcasting and narrowing conversions
Restrict Exception Handling
Restrict Dynamic Memory management
Restrict /= Forbid
Find the right bounded usage depending on the language and specific needs of the applications
Questions & Answers
36 Q/A
Most of them are text explanations from various angles
FAQ#20: same example of LSP violation in - Ada- C++ - Java
- FAQ#23 : example of static dispatch vs dynamic dispatch
Conclusion
Was an OOT supplement necessary?
NO: - most of the changes could go in the core document
YES: - difficult to get significant changes in the core document- groups all the related accompanying information