1

A Verifiable and Correct-by-Construction Controllerfor Robots in Human Environments∗

Saddek Bensalem† Lavindra de Silva‡ Matthieu Gallien† Felix Ingrand‡ Rongjie Yan†

Abstract—Autonomous robots are complex systems that re-quire the interaction and cooperation between numerous hetero-geneous software components. In recent times, robots are beingincreasingly used to assist and replace humans. Consequently,robots are becoming critical systems that must meet safety prop-erties, in particular, logical, temporal and real-time constraints.To this end, we present an evolution of the LAAS architecturefor autonomous systems, and its tool GenoM. This evolution relieson the BIP component-based design framework, which has beensuccessfully used in other domains such as embedded systems.We show how we integrate BIP into our existing methodology fordeveloping the lowest (functional) level of robots. Particularly, wediscuss the componentization of the functional level, the synthesisof an execution controller for it, and how we verify whetherthe resulting functional level conforms to properties such asdeadlock-freedom. Our approach has been fully implemented inthe LAAS architecture, and the implementation has been usedin several experiments on a real robot.

I. INTRODUCTION

As autonomous robots become more and more widespread,the need increases for robotic systems that are safe, depend-able, and correct. This is particularly true for robots that haveto interact regularly and in close contact with humans orother robots. Consequently, it will soon become commonplacefor the developer of robot software to provide guarantees tocertification bodies that, for instance, a hospital nursebot willnot start moving too fast when an elderly person is leaningon it, that the arm of a service robot will not open its gripperwhile holding a bottle, or that there will not be a deadlockwhile a service robot is navigating in an office.

A certain level of dependability and safety can be providedwith thorough software testing and extensive simulation. Thegoal of software testing is to “validate” and “verify” thatthe software meets a given set of requirements, and the goalof simulation is to detect errors as early as possible in thedesign phase. Unfortunately, both simulation and testing havethe disadvantage of being incomplete, in the sense that eachsimulation run and each test evaluates the system only againsta small subset of the foreseeable set of operating conditionsand inputs. Hence, with complex autonomous and embeddedsystems it is often impractical to use these techniques to covereven a small fraction of the total operating space, not tomention the high cost of building test harnesses.

In this paper, we make a significant step toward buildingsafe and dependable robotic architectures. Robotic architec-

∗Authors are in alphabetical order by last name. Part of this work is fundedby the ESA/ESTEC GOAC project and by the FNRAE MARAE project.†Verimag/CNRS, Grenoble I Uni., France. first.last@imag.fr‡LAAS/CNRS, Toulouse Uni., France. first.last@laas.fr

tures are typically organized into several levels, which usuallycorrespond to different temporal requirements (e.g. TREX [1])or different levels of abstraction of functionality (e.g. theLAAS architecture [2]). The lowest level of the latter typeof architecture is the functional level, which includes allthe basic, built-in action and perception capabilities such asimage processing, obstacle avoidance, and motion control.We propose an approach for developing safe and dependablefunctional levels of complex, real-world robotic architectures.With our approach one can provide guarantees that the robotwill not perform actions that may lead to states that are deemedunsafe, which may eventuate in undesired or catastrophicconsequences.

Our solution relies on the integration of two state-of-the-arttechnologies, namely:

• GenoM [2] – a tool (part of the LAAS architecturetoolbox) that is used for specifying and implementingthe functional level of robots; and

• BIP [3] – a software framework for formally modelingcomplex, real-time component-based systems, with sup-porting toolsets for, among other things, verifying suchsystems.

This integration allows us to synthesize for our Dala robota complete functional level that is correct by construction,which can be checked offline for properties such as deadlocksusing verification tools and suites. Moreover, our integrationallows safety constraints to be modeled and included, whichcan then be enforced online by the resulting controller. Withthe inclusion of such constraints, one can guarantee that thefunctional level will not reach unsafe states, even if bugs existin user-supplied programs at higher levels of abstraction (e.g.,the decisional level). Specifically, developing a functionallevel using our approach consists of the following steps: (i)developing the functional level using the GenoM tool of theLAAS architecture; (ii) translating the GenoM functional levelinto an equivalent BIP model; (iii) adding safety constraintsinto the generated BIP model; and (iv) verifying the modelwith the D-Finder [5] tool in our BIP tool-chain.

Then, we can summarize the contributions of this paper asfollows. First, we provide algorithms and data structures forgenerating from a given GenoM functional level specificationan equivalent BIP functional level. The BIP functional levelcan then be used in place of its GenoM counterpart. We providean implemented tool that can automate this translation process.Second, we show, using a construction site inspection scenariofor the decisional level, how the user can straightforwardly useBIP to specify and enforce different kinds of safety constraints

2

on a generated BIP functional level. Third, we present resultsfrom using D-Finder to incrementally verify the generated BIPfunctional level. In particular, we prove that a substantial partof the BIP functional level is deadlock-free, and we report, forthe first time, experiences in using D-Finder (e.g. solutions todeadlocks encountered) with a complex, real-world domain.

This paper is organized as follows. In Section II, we presentthe existing LAAS architecture and the BIP tool-chain; inSection III, we discuss in detail how to generate from a GenoMfunctional level an equivalent BIP functional level; in SectionIV, we show how BIP can be used as a controller of the BIPfunctional level, in order to prevent the system from reaching“dangerous” states; in Section V, we show how D-Finder wasused to analyze the BIP functional level for properties such asdeadlocks. Finally, in Section VI, we present our conclusionsand directions for future work.

II. BACKGROUND

A. GenoMThe lowest level of most complex systems and robotic

architectures is the functional level, which includes all thebasic, built-in action and perception capabilities. These pro-cessing functions and control loops (e.g. image processing,obstacle avoidance, and motion control) are encapsulatedinto controllable, communicating modules. At LAAS, we useGenoM1 [2] to develop these modules. Each module in thefunctional level of the LAAS architecture is responsible fora particular functionality of the robot. Complex modalities(such as navigation) are obtained by making modules “worktogether.”

For example, the functional level of our Dala robot is shownin Figure 1. This functional level2 includes two navigationmodes. The first one, for mostly flat terrain, is laser based(LaserRF), and it builds a map (Aspect) and navigatesusing the near diagram (NDD) approach. In particular, (i)LaserRF acquires laser scans and stores them in the Scanposter, from which Aspect builds the obstacle map Obs; and(ii) NDD manages the navigation by avoiding these obstaclesand periodically produces a speed reference to reach a giventarget from the current position Pos produced by POM. Thespeed reference produced by NDD is, in turn, used by RFLEX,which manages the low level robot wheels controller in orderto control the speed of the robot. RFLEX also produces thecurrent position of the robot based on odometry; this positionis used by POM to generate the current position of the robot.The second navigation mode, for rough terrain, is vision based,and uses stereo images (VIAM and Stereo) to build a 3Dmap (DTM), which is used as input into an arc based trajectoryplanner (P3D). P3D also produces a speed reference whichcan be used by RFLEX. Hueblob, using panoramic imagestaken by VIAM, monitors potentially interesting features in theimages. Finally, Antenna emulates communication with aninspector/operator PDA, and Battery emulates the manage-ment of the power on the whole platform.

1GenoM and other tools from the LAAS architecture can be freely down-loaded from: http://softs.laas.fr/openrobots/wiki/genom

2Module names in Figure 1 are given in fixed font.

Functional level with integrated BIP controller

Battery

SpeedP3D

PosPOM

HueblobIm. St.Stereo

VIAM Im. Pos RFLEXPan-TiltUnit

DTM Env

Aspect Obs

Laser RF Scan

NDD Speed

Antenna

Decisional level

ProceduralExecutive(open-PRS)

Flat terrainnavigation

Rough terrainnavigation

Fig. 1. The complete architecture of Dala.

Control & Functional

IDS

Requests Reports

Control TaskTimer Message Box

Execution Task

PosterIDS Lock

Control Service

Execution ServiceService Controller

Activity

Task Controller

Scheduler

Timer

Permanent

Control ServiceControl Service

Control Service

Execution ServiceService Controller

Activity

Execution ServiceService Controller

Activity

PosterPoster

PosterPoster

Execution Task

Execution ServiceService Controller

Activity

Task Controller

Scheduler

Timer

Permanent

Execution ServiceService Controller

Activity

Execution ServiceService Controller

Activity

.....

.....

.....

..... .....

Timer

Fig. 2. A GenoM module functional organization and its componentization.

All these modules are built by instantiating a unique genericcanvas. This canvas is shown in Figure 2. Each module pro-vides services, which can be invoked by the higher (decisional)level according to tasks that need to be achieved. Services canbe execution services, which initiate activities that take time

3

to execute, or control services, which take negligible time toexecute and are responsible for setting and returning variablevalues.3 For example, the NDD module provides five servicescorresponding to initializations of the navigation algorithm(SetParams, SetDataSource, and SetSpeed), and launching andstopping the path computation toward a given goal (Stop andGoTo). Execution services are managed by execution tasks,responsible for launching and executing activities within theassociated running services. The remaining boxes in the figurecorrespond to BIP entities, which will be discussed in SectionIII.

Figure 3 presents the automaton of an activity. Transitionsin the automaton correspond to the execution of particularelementary (C/C++) code, called codels, available throughlibraries. Codels actualize activities, and they are responsiblefor things such as initializing parameters (transition from startlocation), executing the “body” of the activity or its main codel(transition from exec location), and safely ending the activity,which may amount to things such as resetting parameters andsending error signals.

start

failether

execinter

end

request(args)/--/started

-/interrupted

-/failed

abort/-

abort/-

-/OK(ret)abort/-

Fig. 3. The execution automaton of a GenoM activity. Transitions are of theform input/output.

Each module can return information to the caller – such asa final report – regarding the status of executed services, andexport posters for others (modules or the decisional level) toread; posters store data produced by the module.

B. BIPBIP [3] is a framework for modeling heterogeneous real-

time programs. The main characteristics of BIP are the fol-lowing:

• It supports a model-based design methodology whereparallel programs are obtained as the superposition ofthree layers. The lowest layer describes behavior, theintermediate layer includes a set of connectors describingthe interactions between transitions of the behavior, andthe upper layer is a set of priority rules describingscheduling policies for interactions of the layer under-neath. Such a layering offers a clear separation betweenbehavior and structure (connectors and priority rules).

• It uses a parametrized composition operator on programs.The product of two programs is the composition of

3These variables are stored in a data structure called Functional IDS, whichstores the data that is shared by all parts of a module.

their corresponding layers separately. Parameters are usedto define the interactions as well as new priority rulesbetween the parallel programs [4]. The use of such a com-position operator allows incremental construction, i.e.,obtaining a parallel program by successive compositionof other programs.

• It provides a powerful mechanism for structuring interac-tions involving strong synchronization (rendezvous) andweak synchronization (broadcast).

The BIP framework is implemented in the form a tool-chain. This is presented in Figure 4. The BIP tool-chainprovides a complete implementation, with a rich set of toolsfor modeling, execution, analysis (both static and on-the-fly)and static transformations.

BIPModel

compiler

D-Finderdeadlock analysis

BIP2BIPsource to source

architecture transformations

C/C++Code

Enginesequential,

distributed, …

C/C++Code

IFToolbox

BIPPrograms

Programming ModelsLustre, Matlab/Simulink, DOL,

AADL, GenoM, nesC, …

Execution ModelsMPI, Think, …

exporter

AnalysisTools

AnalysisTools

exporter

code generatorcode generator

Fig. 4. The BIP tool-chain.

C. BIP LanguageThe BIP language supports a methodology for building

components from: (i) atomic components, which are a classof components with behavior specified as a set of transitionsand having empty interaction and priority layers, and wheretriggers (labels) of transitions are ports (action names) usedfor synchronization; (ii) connectors, used to specify possibleinteraction patterns between ports of atomic components;and (iii) priority relations, used to select amongst possibleinteractions according to conditions, whose valuations dependon the state of the integrated atomic components.

An atomic component consists of: (i) a set of ports P ={p1 . . . pn}, where ports are used for synchronization withother components; (ii) a set of control states/locations S ={s1 . . . sk}, which denote locations at which the componentsawait synchronization; (iii) a set of variables V used to store(local) data; and (iv) a set of transitions modeling atomiccomputation steps.

A transition is a tuple of the form (s1, p, gp, fp, s2), rep-resenting a step from control state s1 to s2. A transitioncan be executed if the guard (boolean condition on V) gp

4

is true and some interaction including port p is offered.Its execution is an atomic sequence of two microsteps: (1)an interaction including p, which involves synchronizationbetween components with possible exchange of data, followedby (2) an internal computation specified by the function fp onV .

emptystart full

in out

in 0 < x y ← f(x)

out

Fig. 5. A simple BIP atomic component.

Figure 5 shows a simple atomic component. This componenthas: two ports in, out; two variables x, y; and control locationsempty, full. At control location empty, the transition labeledin is possible if 0 < x. When an interaction through in takesplace, the variable y is eventually modified when a new valuefor y is computed. From control location full, the transitionlabeled out can occur. The omission of the guard and functionfor this transition means that the associated guard is true andthe internal computation microstep is empty. Note that in therest of the paper, we do not show, for legibility, guards andfunctions in figures of BIP components. The BIP descriptionof the reactive component of Figure 5 is the following:

component Reactiveport in,outdata int x,ybehaviour

state emptyon in provided 0 < x do y ← f(x) to full

state fullon out to empty

endend

Components are built from a set of atomic componentswith disjoint sets of names for ports, control locations, vari-ables and transitions. We simplify the notation for sets ofports by writing p1‖p2‖p3‖p4 for the set {p1, p2, p3, p4} . Aconnector γ is a set of ports of atomic components whichcan be involved in an interaction. We assume that connectorscontain at most one port from each atomic component. Aninteraction of γ is any non empty subset of this set. Forexample, if p1, p2, p3 are ports of distinct atomic components,then the connector γ = p1‖p2‖p3 has seven interactions:p1, p2, p3, p1‖p2, p1‖p3, p2‖p3, p1‖p2‖p3. Each non trivial in-teraction, i.e., interaction with more than one port, representsa synchronization between transitions labeled with its ports.Given a connector γ, there are two basic modes of synchro-nization: (i) strong synchronization or rendezvous, when theonly feasible interaction of γ is the maximal one, i.e., itcontains all the ports of γ; and (ii) weak synchronization or

broadcast, when feasible interactions are all those containinga particular port which initiates the broadcast.

A connector description includes its set of ports followedby the optional list of its minimal complete interactions andits behavior. If the list of the minimal complete interactionsis omitted, then this is considered to be empty. Connectorsmay have behavior specified as for transitions, by a set ofguarded commands associated with feasible interactions. Ifα = p1‖p2‖ . . . ‖pn is a feasible interaction, then its behavioris described by a statement of the form: on α provided Gαdo Fα, where Gα and Fα are respectively a guard and astatement representing a function on the variables of thecomponents involved in the interaction. An example of thesyntax of a connector is given below. Note that this syntax isa simplified version to that given in the BIP literature.

connector conn(c1.p1, c2.p2)define [c1.p1′, c2.p2]on c1.p1,c2.p2provided g

do {c2.p2.v ← C}on c1.p1provided g

do {}

This connector, called conn, is a broadcast connector dueto the inverted comma next to one of the ports. Port p1 ofcomponent c1 is the initiator of the broadcast synchronizationbetween ports c1.p1 and c2.p2, where c2 is a component andp2 is one of its ports. If a strong synchronization involvingboth ports can occur, then a data transfer takes place, i.e.,the variable v of port p2 is assigned the constant C. Nosynchronization can take place unless guard g is met.

Finally, a compound component allows defining new com-ponents from existing sub-components (atoms or compounds)by creating their instances, specifying the connectors betweenthem and the priorities. The instances can have parametersproviding initial values to their variables through a namedassociation.

D. D-FinderThe D-Finder tool implements a compositional [5] and in-

cremental methodology [6] for the verification of component-based systems described in the BIP language [3]. D-Finderis mainly used to check safety properties of composite com-ponents. To check safety properties, D-Finder applies thecompositional verification method proposed in [5], [6]. Inthis method, the set of reachable states is approximated bycomponent invariants and interaction invariants. Componentinvariants are over-approximations of the set of the reachablestates of atomic components and are generated by simpleforward propagation techniques. Interaction invariants expressglobal synchronization constraints between atomic compo-nents.

When we are concerned with the verification of deadlockproperties, we let DIS be the set of global states in wherea deadlock can occur. The tool will progressively find and

5

eliminate potential deadlocks as follows. D-Finder starts witha BIP model as input and computes component invariants CIby using the technique outlined in [5]. From the generatedcomponent invariants, it computes an abstraction of the BIPmodel and the corresponding interaction invariants II . Then,it checks satisfiability of the conjunction II ∧ CI ∧DIS. Ifthe conjunction is unsatisfiable, then there is no deadlock. Oth-erwise, either it generates stronger component and interactioninvariants or it tries to confirm the detected deadlocks by usingreachability analysis techniques. When verifying other safetyproperties with D-Finder, one of the steps is to replace DISby the set of global states in which property violations occur.The other steps are identical to those of deadlock-freedomchecking.

E. BIP EngineThe BIP tool-chain provides a platform for executing and

analyzing the C++ application code generated by the front-end.The tool-chain includes an engine and the associated softwareinfrastructure. The engine, entirely implemented in C++ onLinux, directly implements the operational semantics of BIP.

EngineInteractions

filter()

Prioritiesevaluate()

execute()

B1 B2 ··· Bn

init()/notify()

sync()

Fig. 6. The centralized engine architecture.

The engine works based upon the complete state informa-tion of the components. The execution follows a two-phaseprotocol, marked by the execution of the engine, and theexecution of the atomic components. In the execution phaseof the engine, it computes the interactions possible from thecurrent state of the atomic components, and guards of theconnectors. Then, between the enabled interactions, priorityrules are applied to eliminate the ones with low priority.During this phase, the components are blocked, and awaitto be triggered by the engine. The engine selects a maximalenabled interaction, executes its data transfer, and triggersthe execution of the atomic components associated with thisinteraction. The second phase is the execution of the localtransitions of the notified atomic components. They continuetheir local computation independently and eventually reachnew control states. Here, the atomic components notify of theirenabled transitions to the engine and get blocked once more.The two phases are repeated, unless a deadlock is reached orthe user wants to terminate the simulation. The scheme of theprotocol is shown in Figure 6.

III. COMPONENTIZATION OF THE GenoM FUNCTIONALLEVEL

In this section, we discuss our algorithms for mapping agiven GenoM functional level into an equivalent BIP functionallevel. We start with the mapping from individual GenoMmodules to their BIP counterparts. Each GenoM module ismapped to a hierarchy of BIP components, as shown inFigure 2. In addition to representing some GenoM entity, eachbox in this figure also represents an atomic or compound BIPcomponent.

In the componentization, an Execution Task is a compoundcomponent consisting of: a Scheduler (atomic) component, tocontrol the execution of the associated Activity componentof some Execution Service component; a Task Controller(atomic) component to stop the Scheduler if none of theassociated Execution Service components are running; a Timercomponent to control the execution period of the ExecutionTask, provided it has a temporal period specified for it; anda Permanent component, provided the Execution Task has apermanent codel.

The Poster components store data associated with the mod-ule and provide operations for reading from and writing tothis data. The IDS Lock component represents a semaphore forensuring mutual exclusion between different Execution Taskcomponents and Execution Service components when manip-ulating Poster components. The Timer component (directly)in the Module component is used by Poster components todetermine how much time has elapsed, in terms of “ticks,”since the last modification to their data. Specifically, Postercomponents contain a variable called PosterAge (initially 0)that is incremented for each “tick” in the associated Timercomponent, and reset whenever the poster is written to. TheService Controller, Activity, and Control Task components arediscussed later.

As shown in Figure 2, some of the atomic components arecombined to form compound components such as ExecutionService. This is done by adding the necessary connectorsbetween the atomic components. In turn, these compoundcomponents are combined using connectors to form theeven more compound component Module, corresponding to aGenoM module. By combining components incrementally (or“bottom-up”) in this way, we have the guarantee that if itsconstituent components are proven to be correct with respect tosome properties, then the resulting compound component willalso be correct, provided it is free of deadlocks. Checking fordeadlock-freedom using D-Finder will be discussed in SectionV.

The most important components from those mentioned areMessage Box (Figure 7), Activity, and Service Controller(Figure 8). Each Module component has, within its ControlTask component, a Message Box component, which representsthe interface for receiving requests for services and sendingback replies. The period with which requests are read iscontrolled by the Timer component of the Control Task. Thereare two approaches for handling a newly received request inthe Message Box: either (i) reject the request along with aspecific report explaining the reason; or (ii) unconditionally

6

accept the request. The latter is done via two transitions. Thefirst transition (abtIncbi ) is for implementing a GenoM featureof interrupting certain execution services (Execution Servicecomponents) that are incompatible with the new request, andthe second transition (trigbi ) actually executes the requestby interacting with either a Control Service or an ExecutionService component.

readchck

giveidleinitstart

stop stpd fini

abtI

chck stop read give trigb1. . . trigbn

abtIncb1 . . . abtIncbn rejb1 . . . rejbn exit stopped

read

rejb1 , . . . , rejbn , rejStp

give

noMsg chck

abtIncb1 , . . . , abtIncbn

trigb1, . . . , trigbn

init

stop

err, term

kill

kill

stoppedchck chck chck

exit

Fig. 7. An (atomic) BIP Message Box component. Transitions with multipleports (separated by commas) represent multiple such transitions, each with oneof the ports.

Each GenoM execution service has one corresponding Ser-vice Controller component, which controls its execution by,for example, checking the validity of the parameters (if any)of the request associated with the service, and handling theaborting of the service’s execution. This component has twovariables active and done, which are both initially false. Theexecution of the Service Controller starts via a synchronizationwith port trig, which sets active to true, after which the servicecan be aborted from any location via synchronization with theabt port. On the two transitions to location ethr, variable activeis set to false, and variable done is set to true provided thetransition labeled fin (denoting successful completion of theactivity) was taken. Like a GenoM activity, the execution ofthe main codel of the Service Controller is initiated by theexec transition from the exec location. In each location of theService Controller the status of the service can be obtained bysynchronizing with the stat port of the component. Note thatService Controller components belonging to different Modulecomponents are equivalent except for the code executed duringcertain transitions (e.g., the ones labeled ctrl and abt), andthat transitions labeled abt have higher priority than all othertransitions, i.e., whenever a transition labeled abt and someother transition are both possible, the former will be takeninstead of the latter.4

The Activity component corresponds to the GenoM activityautomaton shown in Figure 3. This component will wait to be

4This is necessary to ensure, for instance, that a request to abort a serviceis given priority over starting another step in its execution.

initiated, i.e., for a synchronization between its start port andthe start port of Service Controller, and then wait for its mainexecution to begin, i.e., for a synchronization between its execport and the exec port of Service Controller. In particular, thislatter synchronization will, in the Activity component, lead to atransition that executes the main codel of the associated GenoMmodule. The Activity component is aborted by synchronizingwith the abt port of the corresponding Service Controller;this synchronization will set a flag that prevents the Activitycomponent from executing its main codel again.

ethrstart

start

ctrl rprt

exec abrt

start stat exec abt trig fail fin

ctrl inter reprt err

trig

ctrlabt

abt, err

start

reprt

fail, fin

abt

inter

stat

stat

stat

stat

reprt

stat, exec stat

Fig. 8. An (atomic) BIP Service Controller component.

It is worth noting that, unlike its GenoM counterpart, eachBIP Execution Service component has exactly one ServiceController component, and consequently, a given ExecutionService component cannot have more than one Activity com-ponent associated with it (and executing concurrently). Whilethis is indeed limiting, it can be overcome to a certain extent bydefining multiple execution service types in the GenoM module,to represent the different activity instances that may be neededat runtime. In our experience, this solution was found to bea reasonable one for the modules that we have developed sofar.

Observe from Figure 7 that, due to the semantics of BIPcomponents, an interaction involving a trigbi port of a MessageBox component cannot happen concurrently with an inter-action involving some other trigbj port of the component.Similarly, we add the restriction that no interaction involv-ing a trigbi port of a Message Box component can happenconcurrently with an interaction involving a trigbj port ofsome other Message Box component (belonging to some otherModule component). Without this restriction it would not bepossible to add connectors (as we do later in Section IV) toguarantee that two services are not executed concurrently.5

To add this restriction, we use a simple atomic componentwhich represents a semaphore; its token is obtained by the

5Note that this restriction does not imply that two Service Controllercomponents cannot be executed concurrently.

7

···

····

···

···

. . .mod2 mod3 modm

. . .

abtIncb2abtIncb1

rejb1rejb2

abtIncbn

rejbn

msgbx trig

abtstat

b1

b2

bnabtstat

trig

trigb1trigb2

trigbn

abtstat

trig

mod1

root

Fig. 9. A high-level illustration of exported ports (in grey), and importantconnectors within Module components (mod1, . . . ,modm). Connectorsare between a Message Box (msgbx) and the associated Service Controllercomponents (b1, . . . , bn).

read transition of Message Box components, and released bythe give transition of Message Box components.

As shown in Figure 9, each port trigbi of a Message Boxcomponent is synchronized via rendezvous with port bi.trigof Service Controller component bi. All such connectors areexported so that they are “visible” from the root component,i.e., it is possible to interact with them from the root compo-nent. The root component in BIP is the top-level (compound)component that includes all the other components. In our case,the root component includes all components of the functionallevel.

From now on, for convenience, we simply use trigbi to referto such an exported connector involving a port trigbi . Forexample, the exported port (grey circle) in Figure 9 that isassociated with the connector involving trigb1 is also referredto as trigb1 . Similarly, for each Service Controller componentbi, the rejbi and abtIncbi ports of the associated Message Boxcomponent, as well as the bi.abt and bi.stat ports of bi areexported so that it is possible to interact with them fromthe root component. As before, from now on we simply userejbi , abtIncbi , bi.abt and bi.stat to refer to these exportedports. Unlike the other ports shown in Figure 9 (e.g., abt),by default, all trigbi ports are possible due to a singletonconnector with no guard (i.e., a “no-op” connector) at theroot-component level for each trigbi port. On the other hand,by default, all rejbi , abtIncbi , bi.abt and bi.stat ports are notavailable (i.e., synchronizations involving any of these portsare not possible) due to all such ports being left unconnectedat the root-component level.

To ease the integration of BIP in the new framework, wehave developed a tool that automatically produces a BIP modelfrom a GenoM module description file. Still, if one wants toenforce some safety properties inside a module (intra-module)or between modules (inter-module), these constraints have tobe explicitly added to the resulting BIP model. Adding such

constraints will be discussed in the next section.

IV. FUNCTIONAL LEVEL CONTROLLER SYNTHESIS

Since commands to the functional level are sent fromthe decisional level, i.e., the Procedural Reasoning System(PRS) [7] executive in our case, and since programs writtenfor the decisional level may contain erroneous handcodedprocedures, it is important to be able to constrain the decisionallevel so as to ensure the appropriate/safe execution of GenoMservices in the functional level. For example, one may want toensure that there is never a situation in which too much poweris drawn from the battery, that the speed reference producedby a navigation mode is “fresh” enough with respect to thesensing data that it uses, or that the robot will not move whenit is taking high resolution pictures or communicating.

In the previous LAAS architecture, the proper executionof GenoM services was managed by a centralized controllercalled R2C [8]. The purpose of such a controller is to preventthe system from reaching dangerous states, such as thosementioned, which could lead to undesirable or catastrophicconsequences. The R2C controller maintains its own modeland global state of the system. For the latter, R2C monitorsall requests sent from the decisional level to the functionallevel and all reports sent back from the functional level. Ifa request sent to the functional level may move the systeminto an undesirable (or unsafe) state, R2C takes actions toprevent the state from being reached, such as killing a serviceor rejecting the request. Otherwise, R2C allows the request togo through and the result to be returned.

One of the main differences between the R2C approachand the BIP approach is that the former merely acts asa “filter” below the decisional level to enforce constraintsbetween requests, while relying mostly on the control providedby GenoM. The BIP model and engine, on the other hand, gofar beyond this by providing a formal and much finer grainedmodel of the control taking place inside a functional module,which allows the user to specify finer grained constraints onthe behaviour of functional modules. Moreover, in our newframework, we have one integrated system with a single modeland single global state, rather than two systems (GenoM andR2C) with two different models and two (possibly incon-sistent) representations of the global state. Finally, by usingBIP we now have a clearer semantics for constraints specifiedas BIP connectors, compared to the semantics of constraintsspecified in R2C.

Before discussing how safety constraints can be encodedas BIP connectors in the functional level, we first discuss theconstruction site inspection scenario we have implemented forthe PRS [7] based executive at the decisional level. We usethis scenario to motivate and illustrate our constraints. Therobot’s duty is to work collaboratively with human inspectorsand to assist them with the inspections. Our scenario consistsof the robot exploring a set of waypoints initially suppliedby the human inspector(s), which involves navigating to themand then taking images. Taking an image at a location involvesaligning the high resolution cameras – mounted on the pan-and-tilt unit – to face the surfaces on the left and right sides of

8

the robot. During navigation, the robot continuously monitorsits surroundings for potentially unsafe piles of (red) bricks,using the low resolution panoramic camera mounted on themast. If such a pile is found, the robot stops navigating,determines if the pile is still within its front cameras’ visibilityarea, and then takes a picture of the pile by aligning the frontcameras toward it. The robot transmits all new images andassociated waypoints to the PDAs of the human inspectors.Once all locations have been explored, the robot navigatesback to its original location. Throughout the inspections therobot needs to stay clear of humans at work. Although notimplemented in our scenario, one could extend it to make therobot opportunistically detect other potential hazards such asobstructions and cables strewn across walkways.

Now we can discuss in detail some of the constraintswe have added into the BIP functional level (i.e., rootcomponent). We split the constraints into intra-module con-straints, i.e., those between services belonging to a singlemodule, and inter-module constraints, i.e., those betweenservices belonging to two or more modules. In what fol-lows, ports with suffixes Trigger, Reject, Abort, Status, andAbortIncompatibleServices are used to represent (respectively)particular trigb, rejb, abtIncb, b.abt, and b.stat ports. Recallfrom Section III that all of these are exported ports.

A. Intra-module constraints

In the NDD module, there must be at least one successfullycompleted SetParams service,6 and at least one successfullycompleted SetSpeed service before a GoTo service can betriggered. Note that SPS = SetParamsStatus, SSS = SetSpeedStatus,GT = GotoTrigger, and GR = GotoReject.

connector AllowGotoIfArgsSet(ndd.GT , ndd.SPS, ndd.SSS)define [ndd.GT , ndd.SPS, ndd.SSS]on ndd.GT , ndd.SPS, ndd.SSSprovided ndd.SPS.done ∧ ndd.SSS.donedo {}

connector RejectGotoIfArgsNotSet(ndd.GR, ndd.SPS, ndd.SSS)define [ndd.GR, ndd.SPS, ndd.SSS]on ndd.GR, ndd.SPS, ndd.SSSprovided ¬ndd.SPS.done ∨ ¬ndd.SSS.donedo {ndd.GR.rep ← PARAMS-OR-SPEED-NOT-SET}

For any module with an Init service, no other executionservice of the module should be allowed unless the lastinstance of an executed service, if one exists, is a successfullycompleted Init service. The BIP connectors for this constraintare similar to the ones shown above.

B. Inter-module constraints

Next, we discuss constraints involving multiple modules.First, pictures should not be taken with any high resolutioncamera while the robot is moving, and vice versa, in orderto prevent high resolution pictures from being blurred (this

6i.e., where the execution of the service returned a nominal report

constraint does not apply to low resolution panoramicpictures). Hence, we say that moving is “incompatible” withtaking a picture with a high resolution camera. To enforcethis constraint, whenever a new request is received that isincompatible with a currently executing service, the latter isaborted with a specific error message and the new request isexecuted. In what follows, note that AcS = AcquireStatus, TSST= TrackSpeedStartTrigger, and TSSR = TrackSpeedStart Reject.7

We only show the first two connectors; the other two (i.e.,AllowAcquireIfNotMoving and RejectAcquireIfMoving) areanalogous.

connector AllowMoveIfNotAcquiring(rflex.TSST , viam.AcS)define [rflex.TSST , viam.AcS]on rflex.TSST , viam.AcSprovided ¬(viam.AcS.active ∧

viamAcParams.bank.id = “Marlin”)do {}

connector RejectMoveIfAcquring(rflex.TSSR, viam.AcS)define [rflex.TSSR, viam.AcS]on rflex.TSSR, viam.AcSprovided viam.AcS.active ∧

viamAcParams.bank.id = “Marlin”do {rflex.TSSR.rep ← CANNOT-ACQ-AND-MOVE}

Likewise, we have connectors to disallow taking pictureswith the high resolution camera while the pan-and-tilt unitis moving, and vice versa, and connectors also to disallowcommunication with a PDA while moving, and vice versa,in order to ensure that communication is not disrupted. Theconnectors for the first constraint is similar to those shownabove. The connectors for the second constraint are shownbelow. In what follows, TSSA = TrackSpeedStartAbort, CAIS= CommunicateAbortIncompatibleServices, CT = CommunicateTrigger, and TSSS = TrackSpeedStartStatus. As before, we onlyshow the first two connectors; the other two are analogous.

connector AllowCommIfNotMoving(antenna.CT , rflex.TSSS)define [antenna.CT , rflex.TSSS]on antenna.CT , rflex.TSSSprovided ¬rflex.TSSS.activedo {}

connector AbortMovingToComm(antenna.CAIS, rflex.TSSA)define [antenna.CAIS′, rflex.TSSA]on antenna.CAIS,rflex.TSSAprovided truedo {rflex.TSSA.rep ← CANNOT-COMM-AND-MOVE}on antenna.CAISprovided truedo {}

Finally, the following connector prevents poster dataproduced by certain modules from being used if the data is

7Marlin is the camera model, and viamAcParams is a variable that storesthe camera model passed (as a parameter) with the most recent request toacquire an image.

9

not “fresh”; e.g., a speed reference produced by the NDDmodule is not “fresh” if it has not been updated for morethan ten ticks. Recall that the PosterAge variable keeps trackof the amount of time that has elapsed since the last time theassociated Poster component was written to.

connector AbtMoveIfPstrNotFresh(rflex.TSSA, ndd.PosterAge)define [rflex.TSSA, ndd.PosterAge]on rflex.TSSA, ndd.PosterAgeprovided ndd.PosterAge > 10

do {rflex.TSSA.rep ← NDD-POSTER-NOT-FRESH}

From the constraints presented in this section, it is clear thatthe BIP language provides a natural syntax for encoding non-trivial constraints on certain aspects of BIP components. Suchconstraints are fundamental for synthesizing a controller forthe functional level. To make it even more convenient for theuser, we are currently in the process of developing a higher-level language for specifying constraints; these will then beautomatically translated into BIP connectors, such as thoseshown in this section.8

V. VERIFICATION WITH D-FINDER

The connectors added in the previous section could causedeadlocks in the functional level, since they amount to addingtighter constraints to certain subsets of components. To checkwhether the additional connectors may cause deadlocks, andto determine whether (atomic and compound) components bythemselves are free of deadlocks, we use D-Finder to firstverify atomic components and to then incrementally verify thecompound components resulting from their composition. Dueto space constraints, we do not discuss our experiences withusing D-Finder for verifying properties other than deadlocks,such as “data freshness.” We first discuss our results fromthe verification we carried out for compound componentscorresponding to individual GenoM modules. We start with adeadlock found while verifying the NDD (Module) componentwith D-Finder.

Figure 10 shows some of the components and associatedconnectors of the NDD component. Observe that there arethree Timer components, one for the Control Task component,one for the Execution Task component, and one for the Postercomponent. The purpose of a Timer component is to makea trigger port available when the elapsed time in terms of“ticks” reaches a predefined value or period. To ensure thatthe duration between two contiguous tick synchronizations ina Timer component is equivalent to such a duration in anyother Timer component, we strongly synchronize all tick portsof the mentioned Timer components with the tick port ofthe MasterTimer component. This component will effectivelyensure that there are at least 10 milliseconds (ms) between two

8Examples of constraints in this new language are (r1 ≺ r2) and (r1 ∦r2), where the former means that request r2 can only start after request r1has completed, and the latter means that the execution of r1 should not beoverlapped with the execution of r2.

contiguous synchronizations involving all these tick ports.9

Although this design seemed correct, we found a non-trivial deadlock while verifying the NDD component with D-Finder. Intuitively, the reason for this deadlock is the strongsynchronization between the Timer in Control Task and theTimer in Execution Task. Specifically, the deadlock scenarioidentified was the following: the Message Box is in locationabtI ; the Scheduler is in location idle; Execution ServicesSetParams and GoTo have started executing and they arerespectively in locations exec and abrt ; variable t in theTimer of the Execution Task (ExecTaskTimer) has been resetto zero; and variable t in the Timer of the Control Task(InterfaceTimer) has reached the maximal value.

In this scenario, Scheduler is waiting to synchronize withthe trigger port of ExecTaskTimer in order to start the nextround of execution; ExecTaskTimer is waiting for variable t inInterfaceTimer to be reset (via the synchronization involvingits trigger port) in order to continue with the synchroniza-tion between the four connected tick ports; InterfaceTimeris waiting for Message Box to return to location idle vialocation give , so that the InterfaceTimer can reset its variablet and perform the synchronization with the four connectedtick ports; and Message Box, after having aborted the GoToservice, is waiting to trigger the Stop service, in order to returnto location idle via location give (see Figure 7). However,according to our mapping from GenoM to BIP, no conditionon the transition corresponding to any trigbi port in theMessage Box component will be met because the SetParamsand GoTo services have already started executing, and all otherservices in the NDD module have been declared by the user asincompatible with at least one of these services. Consequently,a deadlock state has been reached.

Our solution to this deadlock was to modify the connectorsynchronizing the tick ports to allow InterfaceTimer to notparticipate in the synchronization via the connector if it cannotparticipate. In precise terms, we have replaced the strongsynchronization between the Timer components in Figure10 with two new connectors, of which the first is shown below.

connector ModuleSync(execTaskTimer.Tick, posterTimer.Tick,interfaceTimer.Tick)define [execTaskTimer.Tick, posterTimer.Tick]′,

interfaceTimer.Tickexport port Port moduleTick

This connector, exported as moduleTick, executes a strongsynchronization between the three tick ports if the tick port ofthe InterfaceTimer component is available, and otherwise, theconnector executes a strong synchronization only between thetick ports of the ExecTaskTimer component and PosterTimercomponent. This solves the deadlock because it allows theTimer components inside the Module component to continueexecuting even if the Message Box component is waiting for

9More than 10 ms may be taken if at least one of the Timer componentstakes time to complete their trigger synchronizations. Waiting for 10 ms isimplemented using the usleep system call. There is ongoing work [9] to extendBIP with the ability to model time, which will remove the need for the systemcall and improve the accuracy of measuring time.

10

idle

Task Controller

trigger

ExecTaskTimer

Scheduler

t=0

runExecutionTaskstopService triggerService

blockExecutionTask

InterfaceTimert=10 tick

t++t==5t=0

trigger

tickPosterTimer

t<5

abrt

ethr

Goto

execSetParams

ethr

trigger

tickt<10

t++t==10t=0

trigger

tick

check

Message Box

idle

abtIinit

tickt<10

t++t==10t=0

trigger

tick

MasterTimer

tick

tick

Poster startread

endread

startwrite

endwrite

tickt++

startwrite

endwriteendread startread

blockExecutionTask

check

trigger

tick

trigger trigger

inter

fail

fin

runExecutionTask

goto_exec

setparams_exec

Fig. 10. A deadlock scenario caused by synchronization between Timer components. Dotted lines stand for ignored locations and transitions.

TABLE IRESULTS FOR DEADLOCK-FREEDOM CHECKING.

Module Components Locations Interactions States LOC MinutesLaserRF 43 213 202 220 × 329 × 34 4353 1:22Aspect 29 160 117 217 × 323 3029 0:39NDD 27 152 117 222 × 314 × 5 4013 8:16

RFLEX 56 308 227 234 × 335 × 1045 8244 9:39Antenna 20 97 73 212 × 39 × 13 1645 0:14Battery 30 176 138 222 × 317 × 5 3898 0:26Platine 37 174 151 219 × 322 × 35 8669 0:59

a service to be aborted. The second connector is shown below.

connector InterModuleSync (masterT imer.T ick,moduleT ick1,

. . . ,moduleT ickn)define masterTimer.Tick, moduleT ick1, . . . ,moduleT icknon masterTimer.Tick, moduleT ick1, . . . ,moduleT icknprovided truedo {}

This connector is for global synchronization betweenall Module components contained in the functional level,where {moduleT icki}1≤i≤n is a set of connectors of typeModuleSync, one for each Module component in the functionallevel composed of n Module components.

Table I shows the time taken for computing invariants forthe deadlock-freedom checking of eight modules by D-Finder.Module is the name of the module; Locations is the totalnumber of control locations in the module; Interactions isthe total number of interactions in the module; States is thetotal number of states in the module – including those in itsconstituent components; LOC is the number of lines of (BIP)code in the module; and Minutes is the time taken for D-Finder to return a result. Observe from the table that we wereable to check for the deadlock-freedom of all our modulesin reasonable amounts of time, even for those consisting ofthousands of lines of BIP code. This shows that D-Finder can

be used to verify complex, real-world domains, and not justtoy examples as shown in previous work [10]. It was alreadyshown in [10], [6] that the component sizes handled by D-Finder are far beyond those that can be handled by other stateof the art academic verification tools such as NuSMV [11] andSPIN [12].

Even after correcting individual modules with respect todeadlocks, it is still possible for collections of modules tocontain deadlocks or to exhibit unsafe behaviour. Consideronce again the two connectors described above, which syn-chronized all the Module components in the functional levelby synchronizing a single MasterTimer component with theassociated Timer components of all Control Task, ExecutionTask, and Poster components. As one might expect, withsuch a complex synchronization there may be the risk of adeadlock if one of the Timer components cannot perform atick transition due to its trigger port never becoming avail-able after the Timer’s period is reached. Interestingly, wesuccessfully verified using D-Finder that the synchronizationbetween the Timer components belonging to NDD, Aspectand LaserRF modules are deadlock-free, and moreover, thatthe synchronization between the Timer components of NDDand RFLEX are also deadlock-free.10 Unfortunately, becauseof the large state space, we were unable to check whether thesynchronization between all related Module components aredeadlock-free.11 Improving D-Finder to make such an analysispossible is an avenue we intend to explore in the future.

10For NDD, Aspect and LaserRF, deadlock-freedom checking took 25seconds, and for NDD and RFLEX deadlock-freedom checking took 66minutes and 43 seconds.

11When we used D-Finder with four modules, it was unable to find asolution within two days.

11

VI. CONCLUSION

There are numerous works that address similar issues towhat we address in this paper (e.g. [13], [14], [1], [15], [16],[17]). However, many of these frameworks do not present aformal model that allows to synthesize a controller that iscorrect by construction, and to verify safety properties onthe resulting system. The remaining frameworks from thosementioned either do not address the componentization ofthe functional level, or they focus on the decisional levelof the overall architecture whereas our work focuses on thefunctional level.

Despite the fact that software has become a large part ofrobot development, one must admit that the software modelsused up to now are either too coarse, too high level, or toolarge and thus very difficult to analyze. We propose a novelapproach to developing functional levels of robotic systems,which incorporates a component-based design approach (BIP)in an existing architectural tool for developing functionalmodules (GenoM). Our approach allows the synthesis of afunctional level that is correct by construction. To this end, weuse our D-Finder tool to formally verify that a significant partof our functional level is deadlock-free, and that it conformsto other safety properties such as data freshness. Our approachalso allows the synthesis of a controller that encodes andenforces user-supplied safety properties, thereby facilitatingthe development of safe and dependable robotic architectures.

We were able to run experiments with a complete functionaland decisional level on the Dala robot, and to demonstrate viafault injections that the BIP engine successfully stops the robotfrom reaching undesired/unsafe situations like those discussedpreviously, and that it reports appropriately to the decisionallevel. In terms of runtime performance, experiments showedthat by using the BIP engine, instead of using GenoM, as acontroller of the functional level, the CPU load of the PentiumIII machine on Dala is doubled. This is not surprising sincethe BIP engine must compute all the feasible interactionsat each step in its execution. Nonetheless, since most real-world actions take time to execute (e.g., in our experiments,moving Dala from (x, y) coordinates (0, 0) to (4, 0) takesapproximately 30 seconds), this overhead goes unnoticed inmost cases.

We plan to extend our work in various directions: e.g., areal-time BIP engine to take into account wall clock proper-ties, and a distributed engine to distribute it over more than oneCPU. Another more ambitious research direction is to studythe use of the BIP approach at the decisional level of ourautonomous robot.

REFERENCES

[1] C. McGann, F. Py, K. Rajan, H. Thomas, R. Henthorn, and R. McEwen,“A deliberative architecture for AUV control,” in Proc. of ICRA-08,2008, pp. 1049–1054.

[2] S. Fleury, M. Herrb, and R. Chatila, “GenoM: A tool for the specificationand the implementation of operating modules in a distributed robotarchitecture,” in Proc. of IROS-97, pp. 842–848.

[3] A. Basu, M. Bozga, and J. Sifakis, “Modeling heterogeneous real-timecomponents in BIP,” in Proc. of Int. Conf. on Software Engineering andFormal Methods (SEFM-06), 2006, pp. 3–12.

[4] S. Bensalem, M. Bozga, T.-H. Nguyen, and J. Sifakis, “Compositionalverification for component-based systems and application,” in Proc. ofInt. Symposium on Automated Technology for Verification and Analysis(ATVA-08), 2008, pp. 64–79.

[5] J. Sifakis, “A framework for component-based construction extendedabstract,” in Proc. of SEFM-05, 2005, pp. 293–300.

[6] S. Bensalem, A. Legay, T.-H. Nguyen, J. Sifakis, and R. Yan,“Incremental invariant generation for compositional design,” VerimagResearch Report, Tech. Rep. TR-2010-6, 2010. [Online]. Available:http://www-verimag.imag.fr/TR/TR-2010-6.pdf

[7] M. Georgeff and F. Ingrand, “Decision making in an embedded reason-ing system,” in Proc. of IJCAI-89, 1989, pp. 972–978.

[8] F. Ingrand, S. Lacroix, S. Lemai, and F. Py, “Decisional autonomy ofplanetary rovers,” Journal of Field Robotics, vol. 24, no. 7, pp. 559–580,2007.

[9] T. Abdellatif, J. Combaz, and J. Sifakis, “Model-basedimplementation of real-time applications,” Verimag Research Report,Tech. Rep. TR-2010-14, 2010. [Online]. Available: http://www-verimag.imag.fr/TR/TR-2010-14.pdf

[10] S. Bensalem, M. Bozga, T.-H. Nguyen, and J. Sifakis, “D-Finder: A toolfor compositional deadlock detection and verification,” in Proc. of CAV,2009, pp. 614–619.

[11] A. Cimatti, E. Clarke, F. Giunchiglia, and M. Roveri, “NuSMV: a newsymbolic model checker,” Int. Journal on Software Tools for TechnologyTransfer, vol. 2, pp. 410–425, 2000.

[12] G. J. Holzmann, SPIN Model Checker, The: Primer and ReferenceManual. Addison-Wesley, 2003.

[13] I. A. Nesnas, A. Wright, M. Bajracharya, R. Simmons, and T. Estlin,“CLARAty and challenges of developing interoperable robotic soft-ware,” in Proc. of IROS-03, 2003, pp. 2428–2435.

[14] A. Finzi and F. I. N. Muscettola, “Robot action planning and executioncontrol,” in Proc. of Int. Workshop on Planning and Scheduling forSpace, 2004.

[15] P. Kim, B. C. Williams, and M. Abramson, “Executing reactive, model-based programs through graph-based temporal planning,” in Proc. ofIJCAI-01, 2001, pp. 487–493.

[16] R. P. Goldman, D. J. Musliner, and M. J. Pelican, “Using model checkingto plan hard real-time controllers,” in Proc. of AIPS Workshop on Model-Theoretic Approaches to Planning, 2000.

[17] R. Simmons, C. Pecheur, and G. Srinivasan, “Towards automatic veri-fication of autonomous systems,” in Proc. of IROS-00, 2000.