Cyrille Comarcomar@adacore.com

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