static analysis of software for autonomous spacecrafts

1

Research Heaven,West Virginia

Static Analysis of Software for Autonomous Spacecrafts

Supratik Mukhopadhyay

[email protected]


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…

• “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 …”

Bugs from the GNATS Database

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?

Model in JMPL

JMPL Compiler

Model in XMPL

Livingstone (L2)Source in C++

C++ Compiler

LivingstoneExecutable

SystemBehavior

• Is it the correct model?• Is the model built correctly?

Does the system crash?

11


Why is the autonomous landscape is so special?

•Procedural (Livingstone C++)•Object-oriented (source of L2)•.Declarative (JMPL)

•.Involves Concurrency and Components

• embedded and real-time aspects

• More high-level than traditional programs

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

…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}

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(12,X,Y,Z).

Property

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

r(p(10,X,Y,Z),p(11,X1,Y,Z),{X1=Y+10}).

Tool generated translation

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

p(x) p(x).p(x) {x=0}.p(x) {x=1}

p(x)

{x=0} {x=1} p(x)

p(x): x=0,x=1Table

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

Research Heaven,West VirginiaCurrent 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

Research Heaven,West VirginiaRelated 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

Research Heaven,West VirginiaLessons 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

static analysis of software for autonomous spacecrafts

Documents