Certifying Auto-generated Flight Code

1. Certifying Auto-generated Flight Code Ewen Denney Robust Software Engineering NASA Ames Research Center California, USA

2. Auto-generated code at NASA • Most NASA missions and projects use modeling tools like Simulink and Matlab • Commercial code generators (e.g., Real-Time Workshop and MatrixX) are available and have been successfully used • X-43 Hyper-X: On-board flight-software generated from Simulink models • RASCAL: Helicopter control laws implemented using Real-Time Workshop "We never found any errors in the automatically generated code, so we were confident in creating a quick prototype for NASA.”

3. Orion Software process

4. Autocode issues Dear Ewen, If you are using R14SP3 Simulink code generation products, please review the following information. If you are not using R14SP3 versions of MathWorks products, please disregard this message. We have identified bugs in R14SP3 Simulink^® code generation products, which in rare instances generate incorrect code that is not easily detected. These bugs have been fixed in subsequent releases: R2006a, R2006b, or the upcoming R2007a release. To prevent impact from these bugs, R14SP3 code generation software users should take the following actions: *Review Related Bug Reports with Potential Workarounds* You can find the documented issues and potential workarounds through the following links (login required): Bug Report 275411 <http://www.mathworks.com/support/bugreports/details.html?rp=275411> Bug Report 283331 <http://www.mathworks.com/support/bugreports/details.html?rp=283331> Bug Report 284002 <http://www.mathworks.com/support/bugreports/details.html?rp=284002> Bug Report 291423 <http://www.mathworks.com/support/bugreports/details.html?rp=291423> Bug Report 291978 <http://www.mathworks.com/support/bugreports/details.html?rp=291978> Frequent updates - bug reports, work-arounds and fixes

5. Autocode issues • Commercial code generators are black boxes • Not qualified so need to analyze generated code • Historically buggy: despite extensive heritage, rare bugs still remain • Cannot detect many bugs at model level or via simulation • Code can be difficult to understand and review • Math intensive code requires powerful analysis techniques • Diverse source of knowledge • Models not good for expressing requirements

6. Assurance strategies for autocoders • Documentation • explain the code generation (and certification) process • increases transparency and trust in process • Traceability • link elements of generation process • mandated by NASA standards • Proof • for all possible inputs, • if the safety assumptions hold • then for all possible execution paths, • the safety requirements hold.

7. Product-oriented assurance • Augment code generator to generate certificates together with code (aka. the “verifying compiler” approach) • No need to qualify/re-qualify code generator • Code certificates: • evidence of compliance with specific requirement • can be independently verified • generate automatically • Support engineers doing software assurance • generate safety documentation for human analysts

8. AutoCert • A code generator plug-in for certifying mathematical properties of auto-generated code

9. AutoCert/RTW • A Real-Time Workshop plug-in for certifying mathematical properties of auto-generated code

10. Technical approach • Combine generator with certification plug-in: AutoCert • Generate certificates which can be verified independently(IV&V) • Based on formal logic • Range of safety properties • Inferred annotations drive source-code analysis • Fully automated • Analysis provides tracing and documentation

11. Example: Coordinate systems • Level 2 Coordinate Systems (CxP 70138): “All pertinent geometric technical data … shall be in the coordinate systems described in this document.” • Problem: • Not directly represented in model or code • Transformations involve matrix algebra, etc.

12. Example: Coordinate systems tmpRe = 0.0; for( row = 0; row < 3; row++) for( col = row + 1; col<3; col++) { tmpRe = mx[row * 3 + col]; mx[row * 3 + col] = mx[col * 3 + row]; mx[col * 3 + row] = tmpRe; }

13. Example: Coordinate systems tmpRe = 0.0; for( row = 0; row < 3; row++) for( col = row + 1; col<3; col++) { tmpRe = mx[row * 3 + col]; mx[row * 3 + col] = mx[col * 3 + row]; mx[col * 3 + row] = tmpRe; } post forall x : int, y : int & (0 <= x <= 2 & 0 <= y <=2) => mx_prime(x + 3 * y) == mx(y + 3 * x)

14. Example: Coordinate systems tmpRe = 0.0; for( row = 0; row < 3; row++) for( col = row + 1; col<3; col++) { tmpRe = mx[row * 3 + col]; mx[row * 3 + col] = mx[col * 3 + row]; mx[col * 3 + row] = tmpRe; } post mx == trans(prime(mx))

15. Example: Coordinate systems tmpRe = 0.0; for( row = 0; row < 3; row++) for( col = row + 1; col<3; col++) { tmpRe = mx[row * 3 + col]; mx[row * 3 + col] = mx[col * 3 + row]; mx[col * 3 + row] = tmpRe; } post has_frame(prime(mx), dcm(ned, ecef)) & mx == trans(prime(mx)) has_frame(mx, dcm(ecef, ned))

16. Example: Matrix symmetry Embedded Matlab /* post forall eml_i0: int, eml_i1: int 0 <= eml_i0 < 2 & 0 <= eml_i1 < 2 => eml_x[eml_i0 + (eml_i1 << 1)] = eml_x[eml_i1 + (eml_i0 << 1)] */ • Covariance matrices (PM, PP) in a Kalman filter must remain symmetric during update • Individual matrix operations in the generated code must be checked: • R+H*PM*H’ is symmetric • Annotations are required • Analysis tool generates annotations based upon idiomatic code patterns K=PM*H'*inv(R+H*PM*H'); PP = (I-K*H)*PM*(I-K*H)' + K*R*K'; RTW … for (eml_i0 = 0; eml_i0 < 2; eml_i0++) { for (eml_i1 = 0; eml_i1 < 2; eml_i1++) { eml_x11 = 0.0; for (eml_i2 = 0; eml_i2 < 2; eml_i2++) { eml_x11 += eml_dv0[eml_i0 + (eml_i2 << 1)] * eml_dv1[eml_i2 + (eml_i1 << 1)]; } eml_x[eml_i0 + (eml_i1 << 1)] = eml_R[eml_i0 + (eml_i1 << 1)] + eml_x11; }}

17. Execution safety Execution safety requires that the constraints of the target language are not violated. • memory safety (array bounds) • Buffer overflows often lead to unsafe programs • variable initialization before use • Uninitialized variables can cause unpredictable/unrepeatable behavior • Compilers only check for initialization of scalars • e.g.: RTW bug: uninitialized variables in demux blocks

18. Other safety properties • Vector/matrix properties • symmetry, triangularity, positive definiteness • quaternion, probability vector normalization • Representation conventions • consistent use of physical units, coordinate systems • Euler angles: YPR vs RPY • quaternion handedness • Signal properties • all bus data used, updated

19. Traceability • Traceability: “the ability to link requirements back to rationales and forward to corresponding design artifacts, code, and test cases”

20. Traceability • Traceability: “the ability to link requirements back to rationales and forward to corresponding design artifacts, code, and proofs” • “why is this line of code safe?” code → verification conditions → assumptions • “how is this requirement satisfied?” property → verification conditions → code

21. Autocode safety reports • Verification says that the code is safe • Certification says why the code is safe • Code analysis generates safety report: explain how code complies with safety properties • Make assumptions and requirements explicit • Algorithms, formulas, equations used to implement blocks • Chain of reasoning from assumptions to requirements “the variable rtb_GetVeci is in the coordinate frame Earth-Centric Inertial because it is defined by applying the ECEF to ECI transformation to the variable … which is in turn…” support code reviews • Traces between code, documentation and V&V artifacts

22. Certification browser Proof Status Show obligations Highlight code Formula or explanation Auto-generated code Safety Obligations

23. Advantages of approach • Low to no false positives/negatives • Accurate analysis of loops, EML, buses • Tight integration with Matlab tool suite • Minimal impact to existing process • Can encode mathematical properties • Use automated theorem proving to check math • Generates safety documentation • Multiple forms of evidence • Traces code and model to verification artifacts • Supports independent V&V • Qualifiable: small kernel of trusted components

24. Future work • Greater domain coverage • More Simulink blocks/EML functions • More properties (e.g., checking control laws) • More extensive documentation • Integrated report for multiple properties, subsystems • Safety cases • Tighter Matlab integration

25. Extra Slides

26. Example: Vector norms • Intuitively: Probability vectors must be normalized • Show preservation of norm by update operations • Domain-specific requirement • Requires code annotations

27. Tool architecture • Small kernel of untrusted components • - patterns and annotations untrusted

28. Qualification • A code generator is qualified • with respect to a given standard • for a given project if there is sufficient evidence about the generator itself so that V&V need not be carried out on the generated code to certify it • Must be done for every project, version • can obtain verification credit • Generators are rarely qualified • ASCET-SE (IEC 61508), SCADE, VAPS (DO-178B) • Qualifying code generators is (almost) infeasible!