DO-178C OOT supplement: A user's perspective
0 likes626 views
The document discusses the application of DO-178C/ED-12C standards in software certification, particularly focusing on object-oriented programming (OOP) techniques and their implications for safety-critical systems. Key topics include inheritance issues, virtualization through Java Virtual Machine (JVM), and dynamic memory management via garbage collection strategies, emphasizing the importance of local type consistency and effective testing methods. The conclusion highlights that the DO-178C/OO supplement provides guidance for implementing OOP technologies safely in modern aircraft systems.
![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](https://image.slidesharecdn.com/6ctic10-oot-usersperspective-v0-8-101110030751-phpapp01/85/DO-178C-OOT-supplement-A-user-s-perspective-16-320.jpg)
![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.](https://image.slidesharecdn.com/6ctic10-oot-usersperspective-v0-8-101110030751-phpapp01/85/DO-178C-OOT-supplement-A-user-s-perspective-26-320.jpg)
DO-178C OOT supplement: A user's perspective
- 1. DO178C/ED12C OOT A User’s Perspective Cyrille Comar Hugues Bonnin Fred Rivard Certification Together International Conference, Toulouse, October 2010
- 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. Inheritance : Liskov Substitution Principle (LSP) with Ada
- 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. 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. 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. 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. 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. 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. 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. 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. 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. Virtualization : the Java Virtual Machine case
- 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. 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. 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. 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. 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. 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. 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. 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. Dynamic Memory Management : the Java Garbage Collector example
- 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. 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. 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. 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. 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. 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. Conclusion
- 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. CTIC 2010 31 Thank you.