MODEL CHECKING OF ROBOTIC CONTROL SYSTEMS

S. Scherer(1), F. Lerda(2), and E. M. Clarke(2)

(1)The Robotics Institute, Carnegie Mellon University, 5000 Forbes Avenue, Pittsburgh, PA 15213, U.S.A.(2)Computer Science Department, Carnegie Mellon University,5000 Forbes Avenue, Pittsburgh, PA 15213, U.S.A.

{basti, lerda, emc}@cs.cmu.edu

ABSTRACT

Reliable software is important for robotic applications.We propose a new method for the verification of con-trol software based on Java PathFinder, a discrete modelchecker developed at NASA Ames Research Center. Ourextension of Java PathFinder supports modeling of a real-time scheduler and a physical system, defined in termsof differential equations. This approach not only is ableto detect programming errors, like null-pointer derefer-ences, but also enables the verification of control softwarewhose correctness depends on the physical, real-time en-vironment. We applied this method to the control soft-ware of a line-following robot. The verified source code,written in Java, can be executed without any modifica-tions on the microcontroller of the actual robot. Perfor-mance evaluation and bug finding are demonstrated onthis example.

Key words: Model Checking; Verification; Control Sys-tems; Software Testing; Java.

1. INTRODUCTION

Reliability of software is key to successful robot andspace missions [1]. Control software is at the foundationof complex robotic systems and higher level software re-lies on its correct implementation. Although logical er-rors in an abstract design may occur, programming bugsin the implementation of an abstract design are frequentlythe reason for software crashes [2].

Conceptually, there are two distinct types of methods tovalidate control systems:generative methodsanddirectmethods. Generative methods [3] take an abstract repre-sentation of the system, e.g. a block diagram, and gener-ate source code that implements the control strategy. Thesource code is then integrated with the control computersource code. Unless the generated code can be used un-modified and the generator of source code itself is provencorrect, this method is not able to guarantee a correct im-plementation. Direct methods, instead, prove the correct-ness of the control systems itself, regardless of how it hasbeen developed, and therefore they do not depend on thecorrectness of the development tools.

We chose a direct method based on software modelchecking [4], a verification technique that performs an

Proc. ‘ISAIRAS 2005 Conference’, Munich, Germany,5-8 September 2005 (ESA SP-603, September 2005)

Fig. 1. A line-following robot on a white line in the initialconfiguration.

exhaustive and systematic search of the reachable statesof a model. Model checking can uncover subtle bugs insoftware and provides a trace of the execution steps thatlead to a violation.

One of the biggest impediments in applying model check-ing to robotic systems is that most tools are not designedto handle the software’s interaction with the physical en-vironment. Specifically, our method explictly models theinteractions with the environment, allowing the verifica-tion of more complex properties about the robotic controlsystem. We have developed an extended version of themodel checker Java PathFinder [5] that verifies modelswith these additional constraints.

With our method control system designers can expressthe controller naturally: differential equations are usedtoexpress the physical system and source code is used todescribe the software. This more detailed model allowsour method to verify safeness and liveness properties thatrefer to the controlled system as well as implicit correct-ness properties of the software, e.g. null-pointer derefer-ences, assertion violations, and deadlocks. Exploiting theexhaustiveness of the model checker, it is also possibleto check the software under different scheduling choicesand introduce errors on the sensors and actuators. Theadditional capabilities come at the price of higher com-putational complexity, which is well justified for mission

critical components.

We have applied our method to the source code of a line-following robot (Fig. 1) that won the “Mobot” race, arobot design competition at Carnegie Mellon. The robothas to follow a white line along a course in the least timepossible. Two separate tasks control velocity and streer-ing. The microcontroller of the robot executes Java code,therefore we chose Java PathFinder for our implementa-tion. We use this robot as a case study to evaluate theeffectiveness of our verification method.

The paper is organized as follows: in Section 2 we dis-cuss some related work; Section 3 introduces our algo-rithm; Section 4 presents the case study in detail and theresults of the verification; lastly, Section 5 provides someconclusions and directions for future work.

2. RELATED WORK

The use of model checking in the context of robotic ap-plications is not new. For instance, model checking hasbeen applied to a robot arm in [6] and a servo loop con-troller in [7]. However, in these cases, the goal of veri-fication was to uncover violations of safety and livenessproperties in the design and the actual software imple-mentation had been abstracted. These approaches fail tocapture the software implementation in enough detail toguarantee the absence of errors and require considerablemanual effort in developing a suitable abstraction of thesoftware.

Java PathFinder itself, the model checker we extended,has been used to verify the software of a Mars rover [2].However, the focus of that study was to uncover commonfatal program errors like data races and deadlocks, whichdo not depend on the environment the software is exe-cuted in. Our method, an extension of Java PathFinder,is still able to find these errors, but it adds the capabil-ity of checking more complex properties that involve aninteraction with the environment.

Modeling techniques for systems that include both con-tinuous and discrete components exist. In particular, hy-brid automata [8] can represent the type of systems thatwe consider in this paper. Moreover, model checkingtechniques for hybrid automata have been proposed andmodel checking tools like HyTech [9] have been used toverify robotic systems, such as arm control systems [10],mobile robot systems [11], and highway traffic controlsystems [12]. These techniques focus, however, on thecontinuous components of the controlled system and acoarse abstraction of the software is usually considered.Our method, instead, focuses on the software and appliesdirectly to the source code of the controller.

3. METHOD

3.1. Modeling the System

We aim to verify control software. Typical examples arecontrollers for robotic systems, where a program is run-ning on an embedded microcontroller. However, in gen-eral, it is not possible to examine the software in isolation.The correctness of the control software often relies on

implicit assumptions about the system it controls. More-over, properties are expressed in terms of the behavior ofthe controlled systems, not in terms of the behavior of thesoftware itself.

In this section we present a model made of three compo-nents:(i) the controlled physical system;(ii) the controlsoftware; and(iii) the scheduler.

The Controlled Physical System.The physical systemis modeled as a continuous or discrete time dynamicalsystem. In the following, we assume that the system canbe modeled using linear time-invariant ordinary differ-ential equations. Specifically, we consider the dynam-ics of the physical system in state space form[13], i.e.x = Ax + Bu, wherex is a vector of state variablesandu is a vector of inputs. The inputsu are the quan-tities that the software controls via the actuators. Letyto be the vector of outputs, determined by the equationy = Cx + Du. The outputsy are the quantities that canbe observed by the software via the sensors. The valuesof A andB determine the dynamics of the system. Thevalues ofC andD determine which parts of the state areaccessible by the software.

The Control Software. The software consists of a setof tasks, implemented on top of a real-time schedulingcomponent. Each task is a concurrent thread of execu-tion. The body of a task is a fragment of code written ina programming language. The body is executed period-ically with a fixed period. The controller communicateswith the controlled physical system by means of sensorsand actuators. The sensors measure some physical quan-tity of the controlled system while the actuators changesome physical quantity. The sensors and the actuatorsdefine the interface between the controller and the con-trolled system.

The Scheduler.The execution of the code is constrainedby the scheduler which executes each task at the propertime. The main reason for including the scheduler in ourmodel is that the behavior of the controller usually de-pends on the timing of the different tasks. Therefore, wemaintain some of this information in order to verify thecorrectness of the software. Moreover, the introductionof a scheduler may even make the verification easier: byconstraining the execution of the different threads, a re-duced set of interleavings needs to be explored, whichyields a smaller number of reachable states.

3.2. Verification Algorithm

The algorithm we propose is based on the depth-firstsearch model checking algorithm implemented in JavaPathFinder. The depth-first search looks for a violation ofthe properties by visiting all reachable states of the sys-tem. At each step the next state is generated; if the statehas been visited before, the algorithm backtracks; oth-erwise, the search continues with the newly discoveredstate. The procedure continues until all reachable stateshave been visited.

Our algorithm (Fig 2) needs to keep track of the discretevariables present in the program as well as the continuousvariables which define the state of the physical environ-

ment. Moreover, a new state is generated either by a dis-crete transition (the execution of a program statement) orby a continuous transition (the evolution of the physicalsystem over a given amount of time).

var visited: set= {};procedureHybridMC(P, S, E, ds, cs);begin

visited= visited∪ {(ds, approx(cs))};foreach ds’ in DiscreteSuccs(P, S, ds, cs) dobegin

cs’ = ContinuousSucc(E, delta(S), ds’, cs);if (ds’, approx(cs’)) 6∈ visitedthen

HybridMC(P, next(S), E, ds’, cs’);end;

end;function DiscreteSuccs(P, S, ds, cs): set;var succs: set= ;

procedureDFS(ds);begin

visited= visited∪ {(ds, approx(cs))};if no tasksare running(ds) then

succs:= succs∪ {ds};else

foreach ds’ in ProgramSuccs(P, S, ds, cs) dobegin

if (ds’, approx(cs)) 6∈ visitedthenDFS(ds’);

end;end;

beginDFS(ds);return succs;

end;

Fig. 2. Pseudo-code of the main algorithm.

The global variablevisited keeps track of the statesthat have already been explored.

The outer procedure,HybridMC, takes as arguments aprogramP, a schedulerS, an environmentE, a discretestateds, and a continuous statecs. HybridMC gener-ates all states reachable from the state〈ds, cs〉. It alter-nates discrete steps (DiscreteSuccs) and continuoussteps (ContinuousSucc). The value ofdelta(S)is the amount of time that needs to pass before anothertask is scheduled. If a state that is already in the visitedset is generated, the procedure backtracks. Otherwise,the search continues in a depth-first fashion from the newstate〈ds’, cs’〉 with an updated schedulernext(S).

The procedureDiscreteSuccs computes the set ofstates that satisfy the following three conditions:(i) thatare reachable from the given state〈ds, cs〉 by meansof discrete transitions;(ii) that do not have any outgoingdiscrete transition; and(iii) in which all the tasks are idle,waiting for the next period. The procedure uses depth-first search to enumerate the states. This is similar tothe way a model checker generates the reachable states.Properties are checked within this procedure as well, butthis has been left out of the pseudocode for readability.

The procedureProgramSuccs computes the succes-sors of a state that are obtained by executing a single

10ms

10ms

Task2

Task1Task1

Fig. 3. A scheduler for tasksTask1 and Task2 withperiods10ms and20ms.

discrete transition of the programP. The set of discretetransitions considered may be constrained by the sched-ulerS.

The procedureContinuousSucc updates the contin-uous state using the differential equations given by theenvironmentE and the time intervaldelta.

The schedulerS can be represented as a finite state ma-chine where each node is labeled by a set of tasks thatare allowed to execute and each edge is labeled by theamount of time that needs to pass before the next set oftasks can execute. For instance, a scheduler for tasksTask1 andTask2with periods10ms and20ms respec-tively is depicted in Fig. 3.

The algorithm makes the simplifying assumption that thetime to execute each task is zero, or very small comparedto the tasks’ periods. As a consequence, all inputs areread and all the controls are set at the beginning of a task’sexecution. This is an approximation of how the real sys-tem behaves, but it is an acceptable approximation as ourcase study demonstrates. In future work, we would liketo explore more sophisticated ways of approximating theexecution time of the code, such as use worst case execu-tion time analysis [14].

The continuous variables can assume an infinite numberof values. However, we desire a representation of thestate that is finite. Since continuous variables are part ofthe state, we need a finite representation of the continuousvariables. Such conversion is performed in the algorithmby the functionapprox. In the next section we give apossible implementation of theapprox function whichperforms an approximation on the values of the continu-ous variables in order to reduce the set of reachable states.

3.3. Implementation

Java PathFinder [5] is an explicit state model checker thattakes as input Java code. The model checker exhaus-tively explores all the reachable states of a given program.States are generated by a depth-first search. Computa-tion of the successors of a state is performed by a customJava Virtual Machine (the Java PathFinder Virtual Ma-chine). Java PathFinder itself is written in Java, therefore,its code is executed by a standard Java Virtual Machine(or Host Virtual Machine).

One of the features of Java PathFinder that we exploitedin our extension is the so-called Model Java Interface (orMJI). MJI allows the users to specify code to executewhen a particular method is called, instead of the codeassociated with the method itself. Among the reasonsfor this facility are the need to specify code for nativemethods (methods of a Java class provided as native bi-nary code by the runtime) as well as the need to define

B

R

x1

x2

A

Fig. 4. Two trajectories rooted at points A and B belong-ing to the same approximated state. The trajectory rootedat A reaches region R, while the one rooted at B does not.

a more efficient implementation for some critical meth-ods. Methods implemented using MJI are more efficientbecause their code is executed by the Host Virtual Ma-chine instead of the Java PathFinder Virtual Machine. Asa consequence, intermediate states within an MJI methodare not stored by the model checker and their instructionsare not interleaved with the instructions of other threads.

In order to implement our algorithm in Java PathFinder,we first extended the representation of the state to includethe continuous variables. Since the domain of the con-tinuous variables is infinite, we need to provide a finiterepresentation for each continuous variable. Possible rep-resentations include infinite precision rational and float-point representations, but we choose a fixed-point repre-sentation whose parameters, e.g. the precision, can be setdepending on the application. This choice was made be-cause we wanted a represention as compact as possible(to reduce the space required to store the states). A preci-sion higher than the computational error can lead to twoequivalent states having different representations.

The functionapprox introduced above converts the val-ues of the continuous variables into the appropriate fixed-point representations. The result of this approximationcan be interpreted as performing an abstraction of thecontinuous space which associates each approximatedvalue with an hyper-rectangle whose size depends on theprecision (Fig. 4). If two states differ only for the val-ues of the continuous variables and these values fall inthe same hyper-rectangle, then the two states have thesame representation. For instance, points A and B inFig 4 have the same representation. Note that this ap-proximation may lead to unsoundness if an error-state(i.e. hyper-rectangle R in the figure) can be reached fromsome points within an hyper-rectangle (point A) but notfrom all (point B).

Another necessary modification to the core of JavaPathFinder was to extend the scheduler to take into ac-count discrete and continuous transitions. In our proto-type implementation, we only considered periodic taskswith the same period. The scheduler will then execute thebody of each task until all tasks complete. At this point,ContinuousSucc is executed, which updates the con-tinuous state.

The Java PathFinder Virtual Machine is used to imple-ment the procedureProgramSuccs: given the currentdiscrete state, it generates the next discrete state.

Motor

Motor

Encoder

Encoder

Ligh

t Sen

sors

Ste

erin

g

Wheel

Wheel

Wheel

Wheel

Fig. 5. Diagram of the robot showing the location of sen-sors and actuators.

ContinuousSucc is implemented as an MJI proce-dure. The body of this procedure is currently writtenmanually and corresponds to a numerical algorithm forthe set of differential equations that describe the physicalenvironment. Implementing the numerical integration asa MJI procedure has the advantage of reducing the com-putation time as well as the state space (cf. above).

4. CASE STUDY

Below we demonstrate the feasibility of our method byapplying it to the line-following robot shown in Fig. 1.We first present the problem and then explain how ourrobot is designed to traverse the course. After that, weoutline the steps involved in model checking the softwareof the robot and the results we obtained. There are bothgeneral and more specific techniques, such as abstractionand system identification respectively, that enable us toverify the software using the extended Java PathFinder.

4.1. Problem Statement

The goal of this case study is to verify the correctness ofthe two control algorithms of the robot. These algorithmsare implemented in software, running and interacting onthe same microcontroller. This raises a number of issuestraditionally not considered in either the model check-ing or control community. In the model checking con-text correctness is defined by invariants, many of whichare implicitly defined by the environment. Moreover, thequantization steps in sensors and actuators as well as de-pendencies between the two control algorithms increasecomplexity.

A slalom course laid out on the pavement in front of theComputer Science Department at Carnegie Mellon de-fines the challenge for the robot. A white line connects aseries of gates which the robot follows while controllingthe speed. Various weather and lighting conditions chal-lenge sensing, computing, and locomotion. The robottries to complete the course as quickly as possible whiletracking the line.

4.2. Robot

A robot designed to meet the specification requires an ad-equate physical platform with correct software. There-fore, we first examine the hardware underlying the soft-ware and then describe the tasks processing the sensordata and executing the control algorithms.

Hardware. The robot is 41x27x12cm in size and utilizestwo battery packs with 7.2V and 12V to provide powerfor processing and actuators independently.

Two geared 12V motors drive the back wheels as depictedin Fig. 5. The microcontroller adjusts the pulsewidth ofthe signal and effectively regulates the power supplied tothe motors. To actuate the rack-and-pinion steering, themicrocontroller sends pulsewidth commands to a servo.

Steering and velocity commands are determined using thedata read from the sensors. The robot has 12 sensors(Fig. 5): ten brightness sensors measure the reflectivityof the ground and two encoders measure the velocity anddistance travelled. The brightness sensors are mountedon a line perpendicular to the direction of travel. The ap-proximate offset from the center of the line is measuredusing this sensor arrangement.

The input/output (I/O) ports of the microcontroller areconnected to an analog-to-digital (A/D) converter, 25-tick encoders, a servo, and an amplifier. Three tasks readand write values via I/O ports and memory. The micro-controller directly executes Java, which significantly sim-plifies the verification using Java PathFinder. It imple-ments Java 2 Micro Edition with the connected limiteddevice configuration, and it has multithreading and a pre-emptible garbage collector. The software is written andcompiled on a host computer and then downloaded to theflash memory of the microcontroller.

Software. The software implements two controllers,which regulate the steering and the speed, as two sepa-rate tasks. An additional task reads the reflectance valuesfrom the brightness sensors. All computations do not in-volve dynamic object creation or destruction and use onlyinteger arithmetic to improve performance. Dependingon the setup, different interleavings of tasks are possi-ble but all tasks execute periodically with a frequency of33Hz.

In particular, a periodic scheduler is implemented usinga piano roll timer [15]. In this configuration, the tasksare executed in a round-robin fashion and execution of atask starts exactly when a beat occurs, allowing accuratetiming of processes which need to satisfy hard real-timeconstraints. Priorities determine the order in which tasksare executed. The piano roll timer is configured with abeat of 1ms and a duration of 80ms. Each task has zeroinitial delay and a period of 10ms. The calculations of ini-tial delays, periods, duration, beat, and priorities are notdifficult but errorprone, as we will demonstrate in Sec-tion 4.3.

The A/D converter measures the voltage generated byeach light sensor. The microcontroller communicates viaa serial bus to read the values. Since commands are sentat the fixed frequency of 33Hz, sensor values are readat the same frequency. The two encoders are connecteddirectly to the microcontroller and provide speed and dis-tance travelled using interrupts.

The cached brightness values are used by the controllerto calculate a steering command. After normalizing thevalues, the algorithm finds the left and right edge of theline. Proportional control is performed to try to keep the

Velocity response

f(u)

Steering Controller(Task 2)

Steeringresponse

f(u)

Speed Controller(Task 3)

RobotController Software

0steeringmodel

speedmodel

Fig. 6. A block diagram representing the control soft-ware and discrete time plant model of the robot. Inputsand outputs are quantized since fixed-point arithmetic isused. A dependency between the steering and speed con-trol task is shown.

25 30 350

75

150

Time

Vel

ocity

in e

ncod

er ti

cks

Measured and simulated model output

28 30 32 34−5

0

5

Time

Ste

erin

g po

sitio

n

Measured and simulated model output

Fig. 7. The identified system response for steering andvelocity data as a solid line on top of a validation dataset.

middle of the line centered underneath the sensors. If it isever detected that the line is out of bounds, the last knowngood direction is used as the steering direction.

The speed of the robot is calculated from elapsed timeand registered encoder ticks. The desired goal speed isdetermined from the the last steering command in order toadapt to curvature. The difference between the two deter-mines the pulsewidth command sent to the motor driver.

4.3. Verification

The hardware and software are used to define assertionsabout the correctness. Similar to a control theoretic ap-proach, we need an environment (”plant”) to control. Thesystem is depicted in a block diagram representation inFig. 6. The control software is on the left and the environ-ment is on the right. The inputs and outputs of the con-troller software are quantized since the implementationof the software relies on fixed point integer arithmetic.

The dependency between the steering and speed controltasks is indicated by a connection from the output of thesteering controller to the input of the speed controller.

Identify the Physical System.The environment can bederived from first principles or automatically identifiedusing a technique known assystem identification[16].Although the robot is simple, it is not trivial to derivethe physical model from first principles because many pa-rameters are unknown and hard to measure. Therefore,we derived the environment using system identification.We recorded seven traces of the inputs and outputs of therobot and searched for the best model fitting the relation-ship between the inputs and outputs.

The encoder response to a pulsewidth command appliedto the motors is direct and therefore a first-order systemmatches well. The position relative to the line depends onthe velocity of the robot and the steering angle. A fourth-order system gives a good relationship between velocity,steering pulsewidth, and position relative to the line.

We tested the response on a validation dataset to confirmthe validity of our models with the identified systems. InFig. 7 the prediction of the sensor output is plot on top ofa validation dataset.

The identified system model constrains the input into thesoftware. Since the interactions with the environment areexecuted at a fixed frequency of 33Hz, we express thesystem as a discrete state space systems with a sampletime of 0.03s. This eliminates the problem of potentialnumerical integration errors.

Design for Verification. While Java PathFinder can beapplied to any kind of software, designing the softwarewith verification in mind is very useful in making ver-ification tractable. The source code of the robot, how-ever, was not developed following this principle and somemodifications to the original source code had to be madeto be able to verify the software using our extended JavaPathFinder. In particular, there are two unbounded vari-ables, time and distance, that increase monotonically.This increase leads to an infinite state space: the modelchecker will eventually run out of memory without com-pleting the verification. In order to make the state spacefinite, we abstracted the unbounded variables. If this isnot possible, one can provide bounds for the variablesand consider states outside the bounds to be equivalent.Moreover, the source code may contain fragments thatare irrelevant for verification but increase the size of thestate space. In our case study, we removed parts of theinitialization code that calibrate the sensors and test theactuators.

The initial configuration of the robot defines the initialvalues of the state vector. Although it is possible to testranges of initial configurations, we focused on the initialconfiguration depicted in Fig. 1. In this configuration therobot steers to the right since it wants to reach back tothe center of the line. The robot is offset from the middleof the line by 36mm, i.e. the middle of the line is underthe rightmost sensor. The robot starts with zero initialvelocity.

Identify Properties. The closed system with initial con-

ditions is fully specified and permits reasoning about theproperties that are necessary to ensure the correct oper-ation of the robot. In this context properties of safety,liveness, and correct implementation are important.

Safety properties state conditions that must hold for therobot to be able to advance and not damage the hardware.In particular, the line has to be visible by at least one lightsensor to ensure that a correct command is sent. Thisis specified as a property which checks that the positionwith respect to the line is within range. The speed alsohas to be within a range to give the robot enough time toprocess and react to the available data.

• 50 < speed < 150 (S1)

• 0 ≤ sensor position ≤ 9 (S2)

Liveness, in our context, states that the robot is alwaysable to make progress along the line and come closer tothe middle of the line as time progresses. In the case ofa straight line, we assert that the speed should be greaterthan zero and the robot has to attain the middle of the lineafter at most 3s.

• speed > 0 aftert > 3 (L1)

• 4 ≤ sensor position ≤ 6 aftert > 3 (L2)

• ∆t > 0 (L3)

It is not sufficient to define the correctness of the robotsoftware only in terms of safety and liveness because theinvariants assume a correct usage of the underlying sys-tem. For this Java microcontroller in particular, it is dif-ficult to use the periodic scheduler and the pulsewidthmodule correctly because some sets of parameters are in-valid andJava Exceptionsare not thrown in all cases.

The piano roll periodic scheduler executes tasks with dif-ferent periods, initial delays, and priorities by arrangingthem in a table with a priority mask defining which taskpriority is runnable. We assume that the runtime of oneiteration in all tasks is always less than the period. For acomplete verification one can use an analysis as in [17]and the longest time execution path to assert that the exe-cution time is less than the period.

The piano roll timer has adurationand abeat. The im-plementation of the piano roll scheduler generates an ar-ray of sizes = duration

beat. The array contains an entry

corresponding to each of the beats that occur in a sin-gle duration. Each entry contains a set of bits corre-sponding to the task priorities. Tasks in one priority arescheduled in a round-robin fashion. A task with periodp and initial delayid starts at beats multiple ofp offsetby id. If a task with periodp, initial delay id, and pri-ority x is added, bitx is enabled for the correspondingentries in the array. This implementation does not corre-spond to the intuition that one adds a task with a certainperiod and it is executed periodically because tasks withthe same priority, initial delay, and period are executed ina round-robin fashion. Consequently, instead of execut-ing with a period ofp they execute with a period ofn · pwheren is the number of tasks. We enforce the intuitionusing properties derived and partly taken from [15]:

• 1 ≤ beat ≤ 65 hardware limitation (PR1)

Experiment Time MemoryModel without Noise 0:00:07 5 MbNoisy Encoder Values 0:45:41 106 MbLight Sensor Failure 1:12:55 159 MbNoisy Pulsewidth Commands 0:18:18 41 Mb

Fig. 8. Computation time and memory necessary for theverification with and without different kinds of errors.

• duration ≥ beat (PR2)

• beat ≤ p ≤ duration (PR3)

• (p = 0) mod beat (PR4)

• (duration = 0) mod p (PR4)

• 0 ≤ id (PR5)

• id < p (PR6)

• id + p ≤ duration (PR7)

• p = t.p ∀ t ∈ Tasks (PR8)

• 0 ≤ x ≤ 14 hardware limitation (PR9)

• if two tasks have the same period and same initialdelay thent1.x 6= t2.x (PR10)

• if two tasks are enabled in the same array entryt1.x 6= t2.x (PR11)

Additionally, it is important to verify that the commandsfor the pulsewidth module are valid in order to avoid anerror condition in the system.

• The Servo has lower and upper pulsewidth-bounds:800µs < ts < 2200µs (PW1)

• 0 is not a valid command for the pulsewidth modulebecause the output is activated constantly. The com-mand also has to be less than the duration of 10ms:0µs < tm < 10000µs (PW2)

Implementation. The microcontroller has its own ap-plication programming interface (API) to connect to theinput and output ports. Using MJI procedures (see Sec-tion 3.3), the API is emulated by the model checker,which simulates the behavior of the environment. Forexample, a call tosetPulseWidthupdates the continuousvariables stored inside the model checker instead of send-ing a value to the actuator. This separates the code imple-menting the controller from the code handling I/O.

Once the commands have been received, the state is up-dated in the environment and the model checker saves thisupdated state. The state of the environment consists oftime, the state vectors, and last inputs. Two states are con-sidered equal if, in addition to the discrete equivalence,the countinuous state variables are approximately equalup to a given fixed-point precision. We introduce nonde-terminism in various parts of the system to model errorsin the commands, encoder readings, and light sensor val-ues, in order to examine their impact on the behavior ofthe robot.

4.4. Results

The goal of the case study was to demonstrate our ap-proach to verifying robot control system software. The

0 1 2 3 4 50

5

10

Offs

et fr

om li

ne

0 1 2 3 4 50

50

100

150

Time in s

Spe

ed in

enc

. tic

ks

Fig. 9. Scatter plots demonstrate the range of possibleoutcomes for added encoder inaccuracy. The plotted lineshows the result of an actual experiment.

problem was initially ill defined, because no model of theenvironment or formal specification was available. Con-siderable effort has been spent on bridging this gap.

All safety (S1, S2) and liveness properties (L1, L2, L3)were verified in a short amount of time (Fig. 8). How-ever, model checking robot control software, like soft-ware development, is an iterative process. The environ-ment model influences the safety and liveness propertiesthat can be checked. For this case study, we had to refinethe model of the environment multiple times.

The piano roll periodic scheduler, on the other hand, isa typical model checking problem and the existing bugscould be found within seconds. The most significant bugwas that all tasks used the same period, initial delay, andpriority (PR10, PR11). This configuration, as explainedin Section 4.3, causes a reduced frequency of task exe-cution. During testing of the robot this bug was neverdiscovered because the system still behaved correctly.

In [1], a fatal type-conversion bug for the Ariane 5 rocketis analyzed. In this incident, the conversion of a 64-bitfloating point value to a 16-bit signed integer caused anoverflow. This occurs only for specific trajectories, mak-ing it a perfect candidate for model checking. We inves-tigated if this type of bug could be discovered using ourtechnique. The source code of the robot was seeded withan intermittent type-conversion bug on the number of en-coder ticks per period. A signed byte, which ranges from-127 to 128, records that value. Usually, less than 128ticks occur within one period, but occasionally this valueis exceeded, e.g. when going down a hill. This bug ishard to find if the inputs and outputs are not determinedusing a model of the environment, but was detected usingour model checker as a violation of property (L1), whichasserts that the speed is always greater than zero.

In order to examine the effects of different kinds of sen-sor and actuator inaccuracy, we added nondeterministicbehavior to parts of the model. Specifically, we exploredthe influence of a±5 slip in encoder ticks, a random fail-ure of two light sensors, and a±50µs error in the outputpulsewidth times. The runtime and memory usage for thedifferent runs are shown in Fig. 8. While modeling errors

requires additional resources, it provides a better cover-age of the behavior of the system.

A typical run is shown in Fig. 9 which compares the cov-erage of model checking to one actual trajectory. Encoderinaccuracy causes a range of trajectories to be possible.The match of the line position in the actual trajectoryis not perfect because the position is inferred indirectlyfrom the brightness sensors. In future work we want toexternally track the robot to improve the identified phys-ical model and the line tracking accuracy. Speed, on theother hand, is within the bounds of the explored statespace which corresponds to a good match.

5. CONCLUSIONS AND FUTURE WORK

We presented a method, based on model checking, forthe verification of robotic control systems implemented insoftware. This technique leverages the recent advances insoftware model checking but extends its applicability tosystems that include a non-trivial physical component de-scribed by differential equations. The approach is basedon the construction of a simulation model for the dynam-ical system that is used in conjuction with the actual soft-ware to perform an exhaustive state exploration.

We have studied the effectiveness of this approach by ap-plying it to a line-following robot controller. The modelof the physical system has been derived by identificationand the actual code running of the robot has been checkedfor both safety and liveness properties.

The presented approach proved sufficient to identify bugsthat depend on the interaction with the physical environ-ment and the scheduler. It is, however, critical to havea model of the environment in order to perform formalverification. We believe that such model should be con-structed together with the control software. When design-ing a control system control engineers already use mod-els based on differential equations: such models shouldbe integrated in a way that they can later be used for ver-ification.

As for future work, we would like to extend our method tobe able to model more complex systems as well as checkmore complex properties. Moreover, we intend to formal-ize our approach in terms of hybrid automata. Our finalgoal is to provide an integrated verification framework forcontrol software developers.

AcknowledgmentsWe would like to thank the Java PathFinder teamat NASA Ames Research Center for making JavaPathFinder available as open source software.

Sebastian Scherer would like to thank Sanjiv Singh forhis continuing support.

REFERENCES

1. Lions, J. ARIANE 5 flight 501 failure. WorldWide Web, July 1996. http://ravel.esrin.esa.it/docs/esa-x-1819eng.pdf.

2. Brat, G., Drusinsky, D., Giannakopoulou, D., Goldberg,A., Havelund, K., Lowry, M., Pasareanu, C., Venet, A.,Washington, R., and Visser, W. Experimental evalua-tion of verification and validation tools on martian roversoftware. Formal Methods in Systems Design Journal,25(2-3), September 2004.

3. Sharygina, N., Browne, J., Xie, F., Kurshan, R., andLevin, V. Lessons learned from model checking a NASArobot controller. Formal Methods in Systems DesignJournal, 25(2-3):241–270, 2004.

4. Clarke, E., Grumberg, O., and Peled, D.Model checking.MIT Press, Cambridge, MA, USA, 1999.

5. Visser, W., Havelund, K., Brat, G., Park, S., and Lerda,F. Model checking programs.Automated Software En-gineering Journal, 10(2), April 2003.

6. Sharygina, N.Model checking of software control sys-tems.PhD thesis, University of Texas at Austin, 2002.

7. Johnson, M. E. Model checking safety properties ofservo-loop control systems. InInternational Conferenceon Dependable Systems and Networks, 2002.

8. Henzinger, T. The theory of hybrid automata. InPro-ceedings of the 11th Annual Sysmposium on Locgic inComputer Science, 1996.

9. Henzinger, T., Ho, P., and Wong-Toi, H. HyTech: amodel checker for hybrid systems.Software Tools forTechnology Transfer, 1:110–122, 1997.

10. Diethers, K., Fireley, T., Kroger, T., and Thomas, U. Anew framework for task oriented sensor based robot pro-gramming and verification. InIEEE International Con-ference on Advanced Robotics, pages 1208–1214, June2003.

11. Ivancic, F. Report on verification of the MoBIESvehicle-vehicle automotive OEP problem. Technical Re-port MS-CIS-02-02, University of Pennsylvania, March2002.

12. Lygeros, J., Godbole, D., and Sastry, S. A verified hy-brid controller for automated vehicles.Special Issue onHybrid Systems of the IEEE Transactions on AutomaticControl, March 1996.

13. Bay, J. S.Fundamentals of linear state space systems.WCB/McGraw-Hill, 1999.

14. Puschner, P. and Koza, C. Calculating the maximum ex-ecution time of real-time programs.The Journal of Real-Time Systems, 1(2):159–176, September 1989.

15. Søndergaard, H. Periodic threads on aJ-100].World Wide Web, December 2004. http://it-ingenior.vitusbering.dk/sw12801.asp.

16. Ljung, L. System identification: theory for the user.Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1986.

17. Bernat, G., Burns, A., and Wellings, A. Portable worstcase execution time analysis using Java byte code. InProceedings of the 12th EUROMICRO Conference onReal-time Systems, June 2000.