1 / 23

Model Checker In-The-Loop

Model Checker In-The-Loop. Flavio Lerda, Edmund M. Clarke Computer Science Department Jim Kapinski, Bruce H. Krogh Electrical & Computer Engineering. MURI Review Meeting Frameworks and Tools for High-Confidence Design of Adaptive, Distributed Embedded Control Systems Berkeley, CA

melvin-schmidt
Download Presentation

Model Checker In-The-Loop

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Model Checker In-The-Loop Flavio Lerda, Edmund M. Clarke Computer Science Department Jim Kapinski, Bruce H. Krogh Electrical & Computer Engineering MURI Review Meeting Frameworks and Tools for High-Confidence Design of Adaptive, Distributed Embedded Control Systems Berkeley, CA September 6, 2007

  2. Motivation • Designing control software is difficult: • Designing software is difficult • Interaction between software and the plant • Simulation is not always sufficient: • Difficult to model software accurately: • Concurrent tasks • User inputs • Only some specific cases

  3. Accomplishments • A tool that combines a software model checker with continuous-time plant models: • Model checker uses simulation traces produced byMATLAB/Simulink • Control code reacts to plant at fixed sample times • Simulation is used to determine behaviors of plant between sampling instants

  4. Accomplishments • More than simple simulation: • Using a model checker to efficiently search for counterexamples • Non-deterministic model • Able to handle concurrency • Model the software in detail • Able to evaluate concurrency issues more efficiently than simulation

  5. Accomplishments • Analyzed the Simulink model of the STARMAC Quadrotor from the Stanford group: • Designed a concurrent supervisory controller • Detected a bug in our controller: • Due to the interleaving of concurrent tasks

  6. System Model • The controller: • Discrete time • Stateflow diagrams • Interleaving semantics • The plant: • Continuous time • Simulink model

  7. Systematic Simulation Standard Simulation • Simulations traces are not independent • Common prefixes • Explore a tree of simulations • The model checker generates the traces • Exploration can be done efficiently Systematic Simulation

  8. Trace Generation • Finite set of initial states • States are composed of both • Controller state • Plant state • Discrete transitions: • Corresponding to the controller • Continuous transitions: • Corresponding to the plant • Duration is determined by the period of the tasks • Generate traces by alternating transitions Initial State Discrete Transitions Continuous Transitions Discrete Transitions Continuous Transitions

  9. Approximate Equivalence • Some simulation traces are similar: • Reach a state near a previous simulation state • We expect the evolution to be similar to the previous trace The same controller state and proximity of the plant state

  10. Approximate Equivalence • Some simulation traces are similar: • Reach a state near a previous simulation state • We expect the evolution to be similar to the previous trace • Heuristic approach: • Ignore traces that lead close to a previously visited point

  11. Approximate Equivalence • Non-conservative: • The ignored trace may lead to new behavior • Useful heuristic for efficiently searching for counterexamples[1] • Dynamicallychoose a subset of simulations to perform, based on proximity [1] J. Kapinski, O. Maler, O. Stursberg, and B. H. Krogh. On Systematic Simulationof Open Continuous Systems.

  12. STARMAC Example • Supervisory controller constructed for the STARMAC • Flies the vehicle through a given sequence of waypoints • Safety property • The altitude is never lower than the minimum safe altitude (1 meter) unless the vehicle is taking off or landing • Modeled in Stateflow but we assume implementation uses interleaving semantics

  13. Controller Tasks • Waypoint Tracking task: • Checks the proximity to a waypoint • Picks next waypoint from a list • Generates the next command • Waypoint Monitoring task: • Checks if altitude value of the next waypoint is less than 1.1 meters • If so, it fixes the altitude command to be equal to 1.1 meters, unless it is the first of last waypoint • ADC task • Samples the state of the environment • Command Latch task: • Maintains the command until the next waypoint is issued

  14. STARMAC Example Waypoint Tracking Task ADC Task Waypoint Monitoring Task Command Latch Task

  15. Systematic Simulation Waypoints: WP1: z = 0 WP2:z = 1.2 WP3:z = 1.5 WP4:z = 0.5 WP5:z = 1.5 WP6:z = 0 • The controller is given a list of waypoints • Given by the table on the right • One waypoint is belong the minimum safe altitude • The model checker generates a large number of traces: • They represent different possible executions • They correspond to the different interleaving of tasks

  16. Systematic Simulation • I will show only two traces: • The first trace satisfies the property • The STARMAC takes off, goes through the waypoints, lands safely • In the second one, the vehicle goes below the minimum safe altitude • The error is due to the particular interleaving of tasks

  17. Successful trace The fourth waypoint is below 1.1 meters The Waypoint Tracking task generates the invalid command The Waypoint Monitor task corrects the value The UAV remains above the minimum altitude and lands safely Waypoints: WP1: z = 0 WP2:z = 1.2 WP3:z = 1.5 WP4:z = 0.5 WP5:z = 1.5 WP6:z = 0

  18. Counterexample A different interleaving is possible at time t = 7.5 The Waypoint Monitor task executes first and sees a valid waypoint The Waypoint Tracking task generates the invalid value The UAV received the lower waypoint and flies below the minimum altitude Waypoints: WP1: z = 0 WP2:z = 1.2 WP3:z = 1.5 WP4:z = 0.5 WP5:z = 1.5 WP6:z = 0

  19. Work In Progress Conservative Approach • Approximate equivalence is a heuristic: • Proximity of states at the current timenot of future evolutions originating from these states • Determine a set around each simulation state which is guaranteed to be safe • Special case: • Affine dynamics • Bounded time

  20. Safe Ellipsoidal Set x0 • For stable affine systems, we can determine a Lyapunov function and the level sets are ellipsoids • Given a trajectory from x0 to x1, consider a point y within a level set of the Lyapunov function centered around x0 • The trajectory starting at y0 ends within the corresponding level set centered around x1 • We can use the Lyapunov function to determine safe sets of states • Efficient operations on ellipsoids y0 x1 y1

  21. Conclusion • How to use a software model checker for systematic simulation • Using Matlab/Simulink for the plant • A model checker for the automatically generated code from Stateflow • Heuristic for ignoring traces that are similar • Currently working on a conservative approach for affine systems

  22. Future Work • Developthe conservative approach • Integrate with Vanderbilt’s code generator • Extend results to unbounded time • Use Lyapunov functions for non-linear systems

  23. Questions?

More Related