Lifecycle Verification of the NASA Ames K9 Rover Executive

1
Lifecycle Verification of the NASA Ames K9 Rover
Executive

• Dimitra Giannakopoulou
• Mike Lowry
• Corina Pasareanu (pcorina_at_email.arc.nasa.gov)
• Rich Washington
• Collaborators Howard Cannon, Ray Garcia ARA
  Group
• Summer Students Colin Blundell (University of
  Pennsylvania),
• Jamie Cobleigh
  (University of Massachusetts)

2
Objectives

• Motivation / NASA Relevance
• Verification is essential for autonomy insertion
  into missions
• Traditional testing of autonomy software is hard
  due to high complexity and unpredictable
  environments
• Integration problems are difficult to detect and
  expensive to fix verification should be
  addressed early in the software lifecycle
• Objectives
• Use a combination of formal analysis techniques
  (model checking) and testing to analyze
  autonomous systems throughout their lifecycle
• Provide support for compositional (divide and
  conquer) verification to address scalability
• Use design level artifacts to guide the
  implementation and to enable efficient source
  code verification

3
Accomplishments/Contributions

• Development of novel, fully automated
  compositional verification techniques
• Integrated lifecycle approach to verification of
  autonomy software
• Analysis of K9 Rover Executive (35KLOC of C)
• Design level modeling
• Design models describe concurrent architecture
  and autonomy features
• Requirements concurrency and plan execution
  properties
• Design level analysis
• Model checking used for exhaustive verification
  of design models
• 10x improvement over monolithic
  (non-compositional) verification
• Code level analysis
• Model checking 3x improvement over monolithic
  verification
• Advanced testing (automated plan input generation
  and run time verification)
• Several integration problems discovered
• Change in design as a result of our analysis
• Simplified architecture with increased modularity

4
Outline

• Introduction
• The K9 Rover Executive
• Compositional Techniques for Design- and Code-
  Level Verification
• Analysis of the Rover Executive
• Conclusions and Future Work

5
Ames K9 Rover Executive

• Executes flexible plans for autonomy
• branching on state / temporal conditions
• Multi-threaded system
• communication through shared variables
• synchronization through mutexes and condition
  variables
• Architecture changed as a result of our analysis
• Simplified inter-thread communication through
  event queue

Updated architecture
Original architecture
6
Outline

• Introduction
• The K9 Rover Executive
• Compositional Techniques for Design- and Code-
  Level Verification
• Analysis of the Rover Executive
• Conclusions and Future Work

7
Model Checking for Design Level Analysis
8
Compositional Verification for Increased
Scalability
Does system made up of M1 and M2 satisfy property
P?

• Check P on entire system too many states
• Check one component at a time need abstraction
  of other modules

M2
M1
finite state models safety properties
9
Learning Framework for Automated Compositional
Verification

• Process is iterative
• We use a learning algorithm to infer the
  smallest assumption at each stage
• Assumptions are generated by querying the
  system, and are gradually refined
• Queries are answered by model checking
• Refinement is based on counterexamples obtained
  by model checking
• Termination is guaranteed
• Algorithm is any-time

TECHNOLOGY
Extended LTSA verification tool to support
automated assume guarantee reasoning at design
level
P violated
10
Assume-guarantee Verification of Code with
Design-Level Assumptions
11
Testing Framework
Input plan property generation
Input plans
Behavioural properties
K9 executive
instrumentation
event stream
Observer (Eagle)
reports
instrumentation
12
Outline

• Introduction
• The K9 Rover Executive
• Compositional Techniques for Design- and Code-
  Level Verification
• Analysis of the Rover Executive
• Conclusions and Future Work

13
Analysis of the Executive

• Properties
• Concurrency deadlocks, correct lock usage / data
  races, sequence of interactions between modules
• Plan execution properties
• Analyzed several versions
• Original architecture components (threads),
  locks, condition variables
• New architecture queuing and event handling,
  floating branch execution (execution of
  synchronous and asynchronous alternate plans)
• Design level analysis
• Several synchronization issues discovered (also
  present in actual implementation)
• 10x improvement over monolithic
  (non-compositional) verification
• Code level analysis
• Model checking 3x improvement over monolithic
  verification
• Testing
• Automatic generation of hundreds of plans in a
  few seconds
• Detection of integration problems early (during
  unit testing)
• Better coverage (predict, by mathematical
  inference, properties about all possible
  inter-leavings)

14
Analyzed Properties

• P1 If the last task in the plan terminates
  successfully, then the only possible outcome for
  the plan is successful termination.
• P2 When a task fails, the continue-on-failure
  flag on the block will always be checked before
  any outcome is produced moreover, if
  continue-on-failure is true, the outcome is
  success, otherwise it is failed.
• P3 The Executive only receives ExecCondChecker
  events if it has registered for them.
• P4 The ExecCondChecker only puts events in the
  queue if the Executive registered for them.
• P5 When a task fails, it will always check its
  continue-on-failure flag moreover, if the
  continue-on-failure flag is false, no subsequent
  task in the block will be started new tasks can
  be started after the parent block reports the
  results (i.e. other block is expanded).
• P6 If a task fails, then the parent blocks
  continue-on-failure flag will be checked if it
  is true, then the block succeeds, otherwise it
  fails.
• P7 If the Executive thread reads the value of
  the shared variable savedWakeupStruct, then the
  ExexcCondChecker thread should not read it until
  the Executive clears it first.
• P8 (Race condition) All accesses to shared
  structure conditionSetChanged by the Executive
  and the ExecCondChecker threads will be protected
  by locks.
• P9 (Race condition) All accesses to shared
  structure existConditions by the Executive and
  the ExecCondChecker threads will be protected by
  locks.
• P10 Absence of local and global deadlocks.

15
Example property (P7)
plan
ExecTimerChecker
Executive
Internal
savedWakeupStruct
ActionExecution
Database (state of system)
DBMonitor
ExecCondChecker
If the Executive thread reads the value of
variable savedWakeupStruct, the ExecCondChecker
thread should not read this value unless the
Executive clears it first.
16
Example Property (P7)
executive.savedWakeupStruct.read0..1
0
1
execCondCh.savedWakeupStruct.read0..1
executive.savedWakeupStruct.assign0 execCondCh.s
avedWakeupStruct.assign0..1
error
17
Generated Assumption

• Assumption Q0,
• Q0 ( executive.exec.lock -gt Q2),
• Q2 (executive.exec.unlock -gt Q0
• executive.savedWakeupStruct.read1 -gt
  Q3
• executive.savedWakeupStruct.assign0
  -gt Q4
• executive.savedWakeupStruct.read0 -gt
  Q5),
• Q3 ( executive.savedWakeupStruct.read1 -gt Q3
• executive.savedWakeupStruct.assign0
  -gt Q4),
• Q4 ( executive.exec.unlock -gt Q0
• executive.savedWakeupStruct.assign0
  -gt Q4
• executive.savedWakeupStruct.read0 -gt
  Q5),
• Q5 ( executive.savedWakeupStruct.assign0 -gt
  Q4
• executive.savedWakeupStruct.read0 -gt
  Q5).

not displaying sink state Q1
18
Analysis Results for P7
Analysis Tool LOC Monolithic model checking Modular verification
Design level LTSA 700 FSP 4,672 states 541 states
Code level JPF 7.2K Java 183K states 53K states
19
Conclusions and Future Work

• Lifecycle verification and validation of K9
  executive
• Modeled and checked key autonomy features at
  design level
• Found error in design (before coding) error
  fixed by developer
• Influenced developer to improve/simplify design
• Developed testing framework for code verification
• Tool for automated input plan generation,
  property monitoring
• Developed novel compositional verification
  techniques for increased scalability
• Future plans
• Verification and validation for future universal
  executive (PLEXIL)
• Automated verification of plans generated by Ames
  planner