A look at the OOT supplement being introduced in the upcoming DO-178C avionics standard.

1. Cyrille Comar
comar@adacore.com

2. Content
Scope & History
Structure of the Document
The new objectives & activities
Conclusion

3. Software
Scope
Why a need for an OOT Supplement?
- Very little text about programming techniques in DO-178B
OO Certifiable
80s-90s

4. Software
Scope
Why a need for an OOT Supplement?
- Very little text about programming techniques in DO-178B
- -178B objectives & activities appropriate
when using OO techniques?
OO
Certifiable
2000-2010

5. History
OOTiA
- 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/)

6. 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

7. 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 ++)

8. Structure of the Document
OO.1.6
OO.2
OO.12
Annexes
Appendixes
OO.C.1-6
OO.C.7-8
DP#1
DP#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 lines
OO.5 < 20 lines
OO.6 < 3 pages
OO.11 < 1 page
Can be deduced from the rest (particularly OO.D)

9. 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

10. 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)

11. 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

12. OO.6.7: Local Type Consistency Verification (2)
Class C1
Method M
Class C3
overriding Method M
Class C2
inherited Method M
Class C4
overriding Method M
Do_Something (Object : C1)
-­‐-­‐ precondition: what does the context provide to M
Object.M ();
-­‐-­‐ postcondition: what is M contribution to the context
-
- it provides as much to the context (postcondition strengthening)

13. 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

14. 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)

15. Virtualization
What is Code & what is Data ?
OO4.2.a : Any time that data, when interpreted, provides
control flow for the executable program, virtualization is being
used
Layered Verification
Virtualization Software to be certified at appropriate level
Same for Virtualized Software
Interpreted Language Java Byte Code State Machine
Language Interpret JVM SM interpretLayer 1
Layer 2

16. 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

17. 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

18. 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