DO178C/ED12C OOT
A User’s Perspective
Cyrille Comar Hugues Bonnin Fred Rivard
Certification Together International Confere...
CTIC 2010 2
Agenda
3 examples of DO178C/OOT usage
1. Inheritance : Liskov Substitution
Principle (LSP) with Ada
2. Virtual...
Inheritance : Liskov
Substitution Principle (LSP)
with Ada
CTIC 2010 4
Local Type Consistency (TC)
 In order to mitigate inheritance vulnerabilities, local type
consistency has to ...
CTIC 2010 5
Local Type Consistency (TC)
1. Formal Methods:
◦ Precondition weakening
◦ Postcondition Strengthening
2. Unit ...
CTIC 2010 6
TC by Formal Analysis
type Class1 is tagged private;
procedure Method (C : in out Class1; I : Integer) with
pr...
CTIC 2010 7
TC by Formal Analysis (2)
 Spark = Small Ada +
logical annotations
 Spark supports limited
OO features
 Spa...
CTIC 2010 8
TC by Unit Testing
 With proper organization of unit testing, verification is relatively
easy to put in place...
CTIC 2010 9
TC by Unit Testing
package Example is
type T1 is tagged private;
procedure M1 (X : T1);
function F1 (X : T1) r...
CTIC 2010 10
TC by Unit Testing
package body Example.Test_Suites is
procedure T1_Test_Suite (T : Test_T1) is …
procedure T...
CTIC 2010 11
TC by Pessimistic Testing
 Locate all dispatching calls in the application
 For each, infer every method th...
CTIC 2010 12
TC by Pessimistic Testing
procedure Do_Something (Obj1 : T1’Class; Obj2 : T2’Class) is
begin
…
Obj1.M1;
…
Val...
Virtualization :
the Java Virtual Machine case
CTIC 2010 14
Multilayering needs
 virtualization has multiple known interests for
productivity and industrialisation
◦ SW...
CTIC 2010 15
Executable (on
target)
Code
Design
Specification
Introduction
of
Virtualizatio
n
No
room
for
Java
Byte
Code
D...
CTIC 2010 16
DO178C ref. on virtualization
 OO.4.2 m.
◦ « Describe any planned use of virtualization » and « This
data [b...
CTIC 2010 17
Development principle
for a Java Software (1/2)
Java
Application
JVM Platform
HW targetExecutable
Code
Design...
CTIC 2010 18
Development principle
for a Java Software (2/2)
 Tests principles : « IMA-like » process
Application on JVM
...
CTIC 2010 19
Constraints on Application devt.
 development of application is not changed
 but « executable object code »...
CTIC 2010 20
Constraints on JVM devt. (1)
 Devt. of the JVM must be done at least at the
same SW level as the application...
CTIC 2010 21
Constraints on JVM devt. (2) :
JVM Tests strategy
HW target
JVM Java tests
JVM
tests execution on JVM
JVM Jav...
Dynamic Memory
Management : the Java
Garbage Collector example
CTIC 2010 23
DO178C ref. on Dynamic Memory
Management
 OO.C.7.6
◦ vulnerabilities are listed and explained, with guidelin...
CTIC 2010 24
Memory ManagementTable OO.C.7.6.3 : where sub-objectives are addressed
MMI : Memory Management Infrastructure...
CTIC 2010 25
7 vulnerabilities in DMM
a. Ambiguous References
b. Fragmentation Starvation
c. Deallocation Starvation
d. He...
CTIC 2010 26
Verify GC by tests against
vulnerabilities
 these verification points are a sort of minimal
requirements for...
CTIC 2010 27
Verify GC by analysis against
vulnerabilities (1/2)
 The fine characteristics of the GC give
supplementary L...
CTIC 2010 28
Verify GC by analysis against
vulnerabilities (2/2)
 For example,
b. Fragmentation Starvation
c. Deallocatio...
Conclusion
CTIC 2010 30
Conclusion
 DO178C/OOT supplement is a real guide to go to
certification with OO features
◦ it gives the nec...
CTIC 2010 31
Thank you.
Upcoming SlideShare
Loading in …5
×

DO-178C OOT supplement: A user's perspective

1,549 views
1,443 views

Published on

A perspective user's view of the OOT supplement being introduced in the upcoming DO-178C avionics standard.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,549
On SlideShare
0
From Embeds
0
Number of Embeds
160
Actions
Shares
0
Downloads
24
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

DO-178C OOT supplement: A user's perspective

  1. 1. DO178C/ED12C OOT A User’s Perspective Cyrille Comar Hugues Bonnin Fred Rivard Certification Together International Conference, Toulouse, October 2010
  2. 2. CTIC 2010 2 Agenda 3 examples of DO178C/OOT usage 1. Inheritance : Liskov Substitution Principle (LSP) with Ada 2. Virtualization : the Java Virtual Machine case 3. Dynamic Memory Management : a Java Garbage Collector example
  3. 3. Inheritance : Liskov Substitution Principle (LSP) with Ada
  4. 4. CTIC 2010 4 Local Type Consistency (TC)  In order to mitigate inheritance vulnerabilities, local type consistency has to be demonstrated. Indeed, this property limits reliably inheritance mechanism.  TC is referred in : ◦ OO.4.4 n. : if reuse is planned, maintenance of TC shall be described. ◦ OO.5.2.2 j. : in design activities, class hiearachy with TC must be developped with associated LLR. ◦ OO.6.7 : specific verification for Local Type Consistency has to be done, with added objective in table A-7 (OO-10).
  5. 5. CTIC 2010 5 Local Type Consistency (TC) 1. Formal Methods: ◦ Precondition weakening ◦ Postcondition Strengthening 2. Unit Testing (on LLRs associated with Class methods) ◦ Run all tests associated with a class using objects of child classes 3. Pessimistic Testing ◦ Verify that all dispatching calls are covered by tests exercising all methods potentially reachable from a dispatch point
  6. 6. CTIC 2010 6 TC by Formal Analysis type Class1 is tagged private; procedure Method (C : in out Class1; I : Integer) with pre => I > 0; post => C.Updated; type Class2 is new Class1 with private; procedure Method (C : in out Class2; I : Integer) with pre => I >= 0; post => C.Updated and C.Sorted; Ada2012 syntax must demonstrate that • I > 0  I >= 0 • C.Updated and C.Sorted  C.Updated Liskov Substitution Principle: • Precondition is weakened • Postcondition is strengthened
  7. 7. CTIC 2010 7 TC by Formal Analysis (2)  Spark = Small Ada + logical annotations  Spark supports limited OO features  Spark already performs this verification type Class1 is tagged private; function Updated (C : Class1) return Boolean; function Sorted (C : Class1) return Boolean; procedure Method (C : in out Class1; I : Integer); --# pre I > 0; --# post Updated(C); type Class2 is new Class1 with private; procedure Method (C : in out Class2; I : Integer); --# pre I >= 0; --# post Updated(C) and Sorted (C); H1: updated(fld_inherit(c)) . H2: sorted(fld_inherit(c)) . -> C1: updated(fld_inherit(c)) . H1: i > 0 . -> C1: i >= 0 . Spark produces 2 VCs (Verification Conditions)
  8. 8. CTIC 2010 8 TC by Unit Testing  With proper organization of unit testing, verification is relatively easy to put in place: ◦ Each class has a mirror “test” class ◦ Each method has a mirror “test” method  Low-Level Requirements are associated with methods  Corresponding testcases are associated to the “mirror” test method ◦ Group all the tests related to a class in a testsuite ◦ Apply this testsuite to objects of the class ◦ Apply this testsuite to objects of subclasses Verify the LLRs associated with the class Verify type consistency
  9. 9. CTIC 2010 9 TC by Unit Testing package Example is type T1 is tagged private; procedure M1 (X : T1); function F1 (X : T1) return Integer; type T2 is new T1 with private; overriding procedure M1 (X : T2); -- inherit F1 (X : T2) end Example; package Example.Unit_Tests is type Test_T1 is new Root_Class_Test with record Ptr : access_T1_Class; end record; procedure Test_M1 (X : Test_T1); procedure Test_F1 (X : Test_T1); type Test_T2 is new Test_T1 with private; overriding procedure Test_M1 (X : Test_T2); -- inherit Test_F1 (X : Test_T2) end Example.Unit_Tests; LLR1_M1 LLR2_M1 LLR1_M1_TestCase1 LLR1_M1_TestCase2 … +M1() +F1() T1 +M1() T2 +Test_M1() +Test_F1() -Ptr T1_Test +Test_M1() T2_Test 1 1
  10. 10. CTIC 2010 10 TC by Unit Testing package body Example.Test_Suites is procedure T1_Test_Suite (T : Test_T1) is … procedure T2_Test_Suite (T : Test_T2) is begin Test_M1 (T); Test_F1 (T); -- call inherited test end T2_Test_Suite; end Example.Test_Suites; Procedure My_Test is T2_Obj : Test_T2 := (Root_Class_Test with new T2); begin -- regular testing on T2 Example.Test_Suites.T2_Test_Suite (T2_Obj); -- verify that T2 can substitute T1 safely Example.Test_Suites.T1_Test_Suite (Test_T1(T2_Obj)); end My_Test;
  11. 11. CTIC 2010 11 TC by Pessimistic Testing  Locate all dispatching calls in the application  For each, infer every method that can be called  Verify that Req based testing cover all such cases
  12. 12. CTIC 2010 12 TC by Pessimistic Testing procedure Do_Something (Obj1 : T1’Class; Obj2 : T2’Class) is begin … Obj1.M1; … Val := Obj2.F1; … end Do_Something; T2’s F1 T2’s M1 T1’s M1 … Do_Something (My_Obj1, My_Obj2); … Do_Something (My_Obj2, My_Obj2); … Enough to achieve stmt coverage but Not enough for Type Consistency verif Necessary to complete “pessimistic testing”
  13. 13. Virtualization : the Java Virtual Machine case
  14. 14. CTIC 2010 14 Multilayering needs  virtualization has multiple known interests for productivity and industrialisation ◦ SW/HW independance ◦ simulation easier ◦ portability improved  but for safety too : ◦ breakdown of complexity (« divide and conquer ») ◦ in case of Java :  stability of Java Bytecode (10+ years)  formal properties of bytecode but with DO178-B...
  15. 15. CTIC 2010 15 Executable (on target) Code Design Specification Introduction of Virtualizatio n No room for Java Byte Code DO178-B approach Executable (on target) Code Design Specification Byte-Code (on VM) DO178C/OOT approach OO.4 “The target environment is either a target computer or a combination of virtualization software and a target computer. Virtualization software also needs to comply with DO-178C/ED-12C and applicable supplements”
  16. 16. CTIC 2010 16 DO178C ref. on virtualization  OO.4.2 m. ◦ « Describe any planned use of virtualization » and « This data [byte code] should be treated as executable code »  OO.C.7.7 ◦ main vulnerability is « the code of a given virtualization layer may be considered to be data, consequently, tracing may be neglected, and verification may be insufficient »  OO11.7 g., OO11.8 f. ◦ standards (design and code) must include contraints on usage of virtualization
  17. 17. CTIC 2010 17 Development principle for a Java Software (1/2) Java Application JVM Platform HW targetExecutable Code Design Specification Executable Code Design Specification
  18. 18. CTIC 2010 18 Development principle for a Java Software (2/2)  Tests principles : « IMA-like » process Application on JVM  main part of appl. HLR, LLR tests JVM on target  main part of JVM HLR, LLR tests ApplicationonJVM ontarget smallpartof integrationtests Application exec. on JVM JVM exec. on HW
  19. 19. CTIC 2010 19 Constraints on Application devt.  development of application is not changed  but « executable object code » is Java bytecode, and the target is a JVM.  it allows to executes tests on any JVM, considering that target environment is representative of final HW target. ◦ standardisation of the JVM greatly helps for this demonstration
  20. 20. CTIC 2010 20 Constraints on JVM devt. (1)  Devt. of the JVM must be done at least at the same SW level as the application.  JVM HLR and LLR are principally described in Java Virtual Machine specification (the « blue book »).  Robust and deterministic algorithms must be chosen, and described in LLRs, to implement the JVM (see for example Garbage Collector in next part) ◦ The simplest are the choices, the easiest is the demonstration.
  21. 21. CTIC 2010 21 Constraints on JVM devt. (2) : JVM Tests strategy HW target JVM Java tests JVM tests execution on JVM JVM Java Bytecode JVM target bytecode JVM execution on a Test JVM JVM execution on the target Test JVM Single test battery Stage 1 Stage 2
  22. 22. Dynamic Memory Management : the Java Garbage Collector example
  23. 23. CTIC 2010 23 DO178C ref. on Dynamic Memory Management  OO.C.7.6 ◦ vulnerabilities are listed and explained, with guidelines  OO.5.2.2 (design activities) : ◦ k. « As part of the software architecture, develop a strategy for memory management »  OO.11.7 g. et OO.11.8 f. ◦ standards (design and code) must include contraints on usage of memory management  OO.6.8 ◦ specific verification for Dynamic Memory Management has to be done, with added objective in table A-7 (OO- 11), covering all the vulnerabilities explained in OO.C
  24. 24. CTIC 2010 24 Memory ManagementTable OO.C.7.6.3 : where sub-objectives are addressed MMI : Memory Management Infrastructure AC : Application  With automatic heap managament allocation, application transfers dynamic memory management problems to the infrastructure  this is a main advantage of using a Garbage Collector (GC) a b c d e f g Object pooling AC AC AC AC AC N/A MMI Stack allocation AC MMI MMI AC AC N/A MMI Scope allocation MMI MMI MMI AC AC MMI MMI Manual heap allocation AC AC* AC AC AC N/A MMI Automatic heap allocation MMI MMI MMI AC MMI MMI MMI Sub-objectives (OO.6.8.2) Technique
  25. 25. CTIC 2010 25 7 vulnerabilities in DMM a. Ambiguous References b. Fragmentation Starvation c. Deallocation Starvation d. Heap Memory Exhaustion e. Premature Deallocation f. Lost Update and Stale Reference g. Time bound Allocation or Deallocation MMI MMI MMI MMI MMI MMI AC
  26. 26. CTIC 2010 26 Verify GC by tests against vulnerabilities  these verification points are a sort of minimal requirements for a DMM infrastructure.  They all can be tested by adequate stress tests  For example, property e. « Premature Deallocation » ◦ 6.8.2.e states « Verify that reference consistency is maintained, that is, each object is unique, and is only viewed as that object. » ◦ One test could be :  one thread fill an array with objects ;  another one compare randomly cells of the array (a[x]==a[y]) ;  one third thread destroys the objects.  This process is repeated at a high rate and during a long period.  The comparison must never be true.
  27. 27. CTIC 2010 27 Verify GC by analysis against vulnerabilities (1/2)  The fine characteristics of the GC give supplementary LLRs ◦ Stop-the the-world / concurrent ◦ Mark-sweep / copy ◦ Compact / not compact ◦ Exact / conservative pointers ◦ Work / time based ...
  28. 28. CTIC 2010 28 Verify GC by analysis against vulnerabilities (2/2)  For example, b. Fragmentation Starvation c. Deallocation Starvation g. Time bound Allocation or Deallocation are well demonstrated by Shoeberl works, for concurrent-copy GC,  these charactristics can be used to give some sound verification of vulnerabities with periodic GC.
  29. 29. Conclusion
  30. 30. CTIC 2010 30 Conclusion  DO178C/OOT supplement is a real guide to go to certification with OO features ◦ it gives the necessary constraints to make OO programs safe ◦ it gives the sufficient genercity to accept any known OO technology ◦ it gives didactical material (APP.C)  Thanks to this new DO178 version, modern OO technology will finally be embedded in our modern aircrafts.
  31. 31. CTIC 2010 31 Thank you.

×