Static Analysis of Software for Autonomous Spacecrafts

1. Static Analysis of Software for Autonomous Spacecrafts Supratik Mukhopadhyay supratik@csee.wvu.edu Research Heaven,West Virginia

2. Why Autonomous Software? • Great distances from earth of the next generation missions (e.g., Mars) make autonomous software the only option • Systems must operate severely limited human intervention to control complex, real time, and mission-critical processes over many months in poorly understood environments • Any control from earth takes at least 8 minutes to get actuated on Mars • Promises improved capabilities at a reduced operational cost

3. The Challenges… • Complexity of software for autonomous systems tremendous • Validation poses a formidable challenge • Traditional testing fails due to the explosion in the number of possible situations.

4. Current Solutions… • Model-based programming for robust development and early validation • Introduce and enforce disciplined coding conventions to make debugging and testing easier (e.g., in flight code no dynamic allocation, always check for array bounds, use standard programming language exception handling mechanism and apply Purify ) • Formal Methods: Model Checking (e.g., translate models to SMV, Java Pathfinder) or Theorem Proving (PVS); able to uncover many concurrency bugs

5. Still… Current Status… Bugs from the GNATS Database • “I don’t know if it’s the candidate manager, Stanley or the engine, but it really seems to hog my machine. I have to shut it down to use other applications” • “the first release was announced but failed with some environment variable not being set properly …”

6. Current Status needs to improve. But… • Formal verification suffers from state explosion • Need to extract models from code; in many cases such extraction is manually aided • Formal verification acts on models, not on actual code • Simple coding errors are the cause of many crashes (remember Ariane); Formal verification bypasses them

7. Need of the hour… • New techniques that can work not only on the models but also on actual code • Techniques should require minimum amount of human support • Should be able to detect not only logical design errors but also programming errors • Should be able to integrate itself with the model-based development paradigm followed at NASA

8. New Technique: Static Analysis • a set of techniques used to infer program properties at compile-time • immensely successful for general purpose programming languages • autonomous systems developed using special-purpose languages; such languages typically at a higher level of abstraction and typically more constrained than general purpose programming languages. • features of the language to be included in a compiled instance specified by the user; typically only a few features are included. • such criteria make static analysis easier to apply to such software

9. Autonomous Software in NASA • Much publicized use of Remote Agent autonomy architecture used in Deep Space • Mode Identification and Recovery (MIR) component uses Lisp-based Livingstone (L1) Integrated Vehicle Health Management (IVHM) system • Accepts models of components of system; infers overall behavior of system • Being used in the next generation shuttles

10. Where does Static Analysis fit in? Livingstone (L2) Source in C++ Does the system crash? • Is it the correct model? • Is the model built correctly? C++ Compiler Model in JMPL Model in XMPL System Behavior Livingstone Executable JMPL Compiler

11. Why is the autonomous landscape is so special? • .Involves Concurrency and Components • embedded and real-time aspects • More high-level than traditional programs • Procedural (Livingstone C++) • Object-oriented (source of L2) • .Declarative (JMPL)

12. Static Analysis Technology • Slice the code automatically to prune portions irrelevant to the property (use Codesurfer from grammatech) • Automatic translation of source code (C++, JMPL) to Constraint Query Language (CQL) Programs • Properties to be inferred or validated to be incorporated as program transformations on constraint query language programs • Computing models of CQL programs provides the analysis • Widenings used to accelerate or terminate the computation; comes up with a ‘yes’ or ‘don’t know’ answer

13. Properties to check • Array bound violation • Code reachability • Constraints on variable values at program locations (memory content) • Deadlocks and concurrency errors

14. Translation of Source Code to CQL programs … 10:x=y+10; 11:while(x<=z){ … } p(10,X,Y,Z) p(11,X1,Y,Z),{X=Y+10} p(11,X,Y,Z) p(12,X,Y,Z),{X=<Z}

15. Incorporating properties Property … 10:x=y+10; 11:while(x<=z){ … } Line 12 is reachable p(10,X,Y,Z) p(11,X1,Y,Z),{X=Y+10} p(11,X,Y,Z) p(12,X,Y,Z),{X=<Z} p(10,X,Y,Z) p(11,X1,Y,Z),{X=Y+10} p(11,X,Y,Z) p(12,X,Y,Z),{X=<Z} p(12,X,Y,Z).

16. Tool for Automatic Translation • Built with Lex, Yacc and 400 lines of awk code • Translates C++ source code to CQL clauses • Able to handle 10000 lines of code in a matter of seconds • Used the tool to translate some Livingstone methods to CQL programs • Tool for translating JMPL source code currently underway Tool generated translation r(p(10,X,Y,Z),p(11,X1,Y,Z),{X1=Y+10}).

17. Computing Models of CQLs • Both forward and backward chaining methods • Forward chaining method wasteful • Backward chaining: Tabled Resolution; table each constrained atom as it is called; on subsequent calls use the information on the table • Tabled resolution: goal-directed Table p(x): x=0,x=1 p(x) p(x) p(x). p(x) {x=0}. p(x) {x=1} p(x) {x=1} {x=0}

18. Tool for Computing Models • Written in Sicstus Prolog with 3000 lines of code • Has a GUI written in Tcl/Tk • Uses CLP(R) library of Sicstus Prolog for constraint solving • Have checked array bounds automatically for several Livingstone methods; generated interface conditions for array bound violation • Handles 1000 lines of source code in < 30 seconds

19. Widenings • A series of widenings being developed for both accelerating • and enforcing termination • Most of them are based on syntax for efficient implementation M M

20. Implementing Widenings • Have implemented many of the widenings already in Sicstus Prolog • Implementation of more widenings underway • Some of the widenings lose information resulting in ‘don’t know’ answers • Accuracy of widenings to be studied

21. Current Status • Implemented tool for translating C++ source code to CQL clauses • Developed tool for computing models of CQL programs • Implemented many of the widenings • Conducted preliminary case studies To do in the next quarter • Implement translator from JMPL to CQL • Implement more widenings • Study new techniques to make the analysis faster • e.g., randomized techniques • Conduct more rigorous case studies

22. Related Work • Bandera: Conduct finite models from Java source code • SLAM: Constructs finite models from C source code • JavaPathfinder: Model Checks Java programs • BANE: Infers constraints from C programs and solves them

23. Lessons learnt • Adherence to disciplined coding practices like no dynamic allocation • in flight code makes static analysis easier • Techniques needed to make static analysis faster • Can be used to generate interface specification for modules • Preliminary experiments providing encouraging results