Model Checking of Robotic Control Systems

transcript

Model Checking of Robotic Control Model Checking of Robotic Control SystemsSystems

Presenting:Sebastian Scherer

Authors:Sebastian Scherer, Flavio Lerda,

and Edmund M. Clarke

OutlineOutline

● Motivation

– Why verification

– Scope

– Control software● Method

● Case Study

● Conclusions

Why verify robot software?Why verify robot software?

● Failure is expensive:

– Interplanetary exploration

– Crash / Rollover

● Autonomy increases responsibility:

– Human interaction

– Large forces and momenta

The scope of our approachThe scope of our approach

Start by verifying this part.

Typical mobile robot architecture

Environment

ActuatorsSensors

Preprocessing Controller

Accumulation Planning

GoalSoftware

Hardware

Specified

Control systems are implemented in Control systems are implemented in softwaresoftware

● Main loop is only a small fraction of the control software:

– Initialization

– Exception handling

– Conversion● Fatal bugs can be in any line

of the code.

Typical mobile robot architecture

Environment

ActuatorsSensors

Preprocessing Controller

Accumulation Planning

Software

Hardware

Specified

OutlineOutline

● Motivation

● Method

– Capabilities & Limitations

– Method

– Model Checking

● Case Study

● Conclusions

import gov.nasa.jpf.jvm.Verify;import com.ajile.jem.PeriodicThread;import com.ajile.jem.PianoRoll;import com.ajile.drivers.gptc.*;import intermediate.*;import drivers.*;import controller.*;import model.*;

public class Mobot{

static final int PR_DURATION_MSEC = 80; static final int PR_BEAT_MSEC = 1; static PianoRoll Piano_Roll = new PianoRoll (PR_DURATION_MSEC, PR_BEAT_MSEC); public static void main(String[] args) { DecsionPoints.runSys=true; //Initialize threads PWM2 pwm = PWM2.getInstance(); Gate gate = Gate.getInstance(); SpeedOMeter encoder = SpeedOMeter.getInstance(); LightArray lightsensor = LightArray.getInstance(); TLC2543 tlc = TLC2543.getInstance();* if(Environment.isMC) { lightsensor.initDefault();

SpeedControl speedcontrol = SpeedControl.getInstance(); SteeringControl steeringcontrol = SteeringControl.getInstance(); Environment env = Environment.getInstance();

Code of controller +environment(plant)

kukD+kxkC=ky

kukB+kxkA=+kx

CapabilitiesCapabilities of our method of our method● Utilizes environment (plant) of the control system.

● Simulates behaviour:

– Determines stability.

– Models influence of noise.

– Checks performance specifications.

– Computes ranges of trajectories.

● Checks programming errors:

– Null pointer exceptions.

– Dead lock, concurrency bugs.

– Errors affecting the behavior.

● Code checked is identical to executed code.

LimitationsLimitations of our method of our method● Discrete method:

– Makes assertions only about a particular initial condition.– Continuous states are approximated up to a fixed point

precision.– Precision often determines the length of a simulation trace

and the size of the state space to explore.– Noise is approximated by a discrete set of values.

● Detailed model:– Requires model relating inputs and outputs.– Additional memory and computation time.

● Assumptions:– Time elapses only while tasks sleep.– Unbounded variables like time and distance must be

abstracted manually.

Model check software with a Model check software with a physical environmentphysical environment

public class Mobot{

Code of controller +environment(plant)

kukD+kxkC=ky

kukB+kxkA=+kx

public class Mobot{

Source codeof controller

Abstract controller

Source code including the environment

Verify actual source code

MethodMethod

public class Mobot{

Actual Robot

Sensors

Actuators

Software executedon robot Environment model

● Execute the source code.

● After all tasks sleep execute the environment.

● Equivalent states are not revisited.

kukD+kxkC=ky

kukB+kxkA=+kx

MethodMethod

public class Mobot{

Actual RobotSoftware executedon robot Environment model

● Software executes until all tasks yield.

kukD+kxkC=ky

kukB+kxkA=+kx

MethodMethod

public class Mobot{

● Commands are set. Sensors are read. Time elapses

kukD+kxkC=ky

kukB+kxkA=+kx

MethodMethod

public class Mobot{

● Commands are set. Sensors are read. Time elapses

● Software executes with new sensor values.

kukD+kxkC=ky

kukB+kxkA=+kx

MethodMethod

public class Mobot{

● Commands are set. Sensors are read. Time elapses.

● Software executes with new sensor values.

● Commands are set. Sensors are read. Time elapses with new commands.

kukD+kxkC=ky

kukB+kxkA=+kx

Model checkingModel checking

● Model consists of states and transitions.

● Java byte code specifies a model.

● Verify a model against a specification given as logic properties.

● The algorithm visits all states of the model to verify that none of the specified properties are violated.

● If the same state is reached twice backtrack.

public class Mobot{

States

Transitions

Java PathFinderJava PathFinder

● All states are explored to find a violation of the properties.

● Executing the byte code generates successors.

● If no new successors are generated the search backtracks.

● Environment byte code is executed on host JVM. No intermediate states are generated from it.

● Environment stores only necessary state variables.

Robot source code

Host JVM running Java PathFinder

Java Virtual Machine of Model Checker

Environment

OutlineOutline

● Motivation

● Method

● Case Study

– Architecture

– Verification

– Model

– Results

● Conclusions

OverviewOverview

• Robot has to follow a line and maintain a constant speed.

• Native Java microcontroller executes the code.

• Check source code without change.

ArchitectureArchitecture

● Actuators

– Steering

– Motors

● Sensors

– Light sensors

– Encoder

SoftwareSoftware● 3 tasks running with a

fixed frequency of 33Hz.

● Task 1: Reads sensor values.

● Task 2: Controls the steering.

● Task 3: Controls the velocity.

● A fixed rate scheduler determines the execution order and duration.

Task 1 Task 2

Task 3

VerificationVerification

● Need model of the environment.

● Need definition of states.

● Verify robot starting from initial condition offset from center of line and on a straight line.

Environment modelEnvironment model● Two models necessary

● Model relate commands to sensor information

● Sensed position over line depends on

– Steering command

– Velocity command

● Sensed encoder velocity depends on the velocity command.

Sensed positionmodel

Sensed velocitymodel

Input:Velocity command

Output:Encoder velocity

Inputs:Velocity commandSteering command

Output:Encoder velocity

Determining the modelDetermining the model

• One way to obtain a model of the environment is system identification.

• Performed experiments and obtained a second-order model for velocity and a fourth-order model for steering

• Quality of sensor gave a better fit for the velocity

0027.0)(

87.004.002.003.0

13.098.010.0096.0

07.011.098.011.0

22.011.014.096.0

tutxtx

StatesStates● Continuous state:

– 6 state variables– 2 inputs

● States are discretized up to a fixed precision to terminate on stability and disambiguate quasi-equal states.

● Monotonic variables such as time or distance are (manually) abstracted.

● DESCRIBE PICTURE

public class Mobot{

static final int PR_DURATION_MSEC = 80; static final int PR_BEAT_MSEC = 1; static PianoRoll Piano_Roll = new PianoRoll (PR_DURATION_MSEC, PR_BEAT_MSEC); public static void main(String[] args) { DecsionPoints.runSys=true; //Initialize threads PWM2 pwm = PWM2.getInstance(); Gate gate =

+State space model

Discrete State Continuous State

kukD+kxkC=ky

kukB+kxkA=+kx

Non-DeterminismNon-Determinism

● Possible to explore non-determinism in the software and environment.

● Model checking explores a wider spread of trajectories.

● Non-determinism is discrete. Differential equations are deterministic.

Blue region is the spread of trajectories covered by the model checker.

Red trajectory showsan actual trace of therobot.

ResultsResults● Added different kinds

of non-determinism to model.

– Encoder reading off by -10, 0, +10 ticks

– Failure of one sensor in the array of light sensors

– Commanded steering and velocity pulsewidth is not accurate.

Ground

Wheel Slip

ResultsResults

● We verified a set of properties of the control software.

● No programming errors (e.g. Null pointer exceptions) were found.

ConclusionConclusion

● Model checker covers a sufficient range of trajectories to simulate all inputs to program.

● Seeded type conversion bug was found.

● Verifies software for robot controllers directly.

● Discretization, abstraction and extraction of continuous states enable efficient verification.

● Exhaustive exploration of non-determinism such as random sensor failure.

● Aids the control system designer by direct verification of all reachable states of the model.

Future workFuture work

● Prove correctness of model checking algorithm

● Extend notion of discretization of state space to be an over-approximation.

● Provide integrated support for modeling the environment

● Integrate with higher level software interfaces

● Check complex systems

● Extend to languages other than Java

Questions? Comments?Questions? Comments?

Contact Information:Sebastian Scherer

basti@andrew.cmu.eduhttp://www.cs.cmu.edu/~basti/

Model Checking of Robotic Control Systems

Documents