A component-based approach to the design of networked ... · PDF fileA component-based approach to the design of networked control systems ... reusable software objects that shield

A component-based approach to the design ofnetworked control systems

Karl-Erik Arzen, Antonio Bicchi, Gianluca Dini, Stephen Hailes,Karl H. Johansson, John Lygeros, and Anthony Tzes

Abstract— Component-based techniques revolve around com-posable, reusable software objects that shield the applicationlevel software from the details of the hardware and low-levelsoftware implementation and vice versa. Components providemany benefits that have led to their wide adoption in softwareand middleware developed for embedded systems: They arewell-defined entities that can be replaced without affecting therest of the systems, they can be developed and tested separatelyand integrated later, and they are reusable. Clearly suchfeatures are important for the design of large-scale complexsystems more generally, beyond software architectures. In thistutorial we propose the use of a component approach to addressembedded control problems. We outline a general component-based framework to embedded control and show how it canbe instantiated in specific problems that arise in the controlover/of sensor networks. Building on the middleware compo-nent framework developed under the European project RUNES,we develop a number of control-oriented components necessaryfor the implementation of control applications and design theirintegration. The present paper provides the overview of theapproach, discusses a real life application where the approachhas been tested and outlines a number of specific controlproblems that arise in this application. Companion papersprovide the details of the implementation of specific componentsto address these control problems, as well as experimentalvalidation results.

I. I NTRODUCTION

Networked embedded systems play an increasingly impor-tant role and affect many aspects of our lives. By enablingembedded systems to communicate, new applications arebeing developed in areas such as health-care, industrialautomation, power distribution, rescue operations and smartbuildings. Many of these applications will result in a moreefficient, accurate and cost effective solution than previousones. The European Integrated Project Reconfigurable Ubiq-uitous Networked Embedded Systems (RUNES) [8] brings

Research supported by the European Commission under the integratedproject RUNES, FP6-IST-004536.

K.-E. Arzen is with the Department of Automatic Control, Lund Univer-sity, Sweden.

A. Bicchi is with the Department of Electrical Systems and Automation,University of Pisa, Italy.

G. Dini is with the Department of Information Engineering, Universityof Pisa, Italy.

S. Hailes is with the Department of Computer Science, UniversityCollege, London, U.K.

K. H. Johansson is with the School of Electrical Engineering, Royal Insti-tute of Technology, SE-100 44 Stockholm, Sweden;[email protected] author.

J. Lygeros is with the Automatic Control Laboratory, ETH Zurich,Switzerland.

A. Tzes is with the Department of Electrical and Computer Engineering,University of Patras, Greece.

together 21 industrial and academic teams in an attempt toenable the creation of large scale, widely distributed, hetero-geneous networked embedded systems that inter-operate andadapt to their environments. The inherent complexity of suchsystems must be simplified if the full potential for networkedembedded systems is to be realized. The RUNES projectaims to develop technologies (system architecture, middle-ware, networking, control etc.) to assist in this direction,primarily from a software and communications standpoint.

Networked control systems impose additional require-ments on the RUNES platform that arise from the need tomanipulate the environment in which the networked systemsare embedded. Timing and predictability constraints inherentin control applications are difficult to meet in general,due to the variations and uncertainties introduced by thecommunication system: delays, jitter, data rate limitations,packet losses etc. For example, if a control loop is closed overa wireless link, it should tolerate lost packets and be able torun in open loop over periods of time. Resource limitationsof wireless networks also have important implications forthe control design process, since limitations such as energyconstraints for network nodes need to be integrated into thedesign specifications. The added complexity and need forre-usability in the design of control over wireless networkssuggests a modular design framework.

In this paper, we propose a component-based approachto handle the software complexity of networked controlsystems. A general framework is presented and it is shownhow it can be instantiated in specific problems that arise incontrol over wireless sensor networks as well as in controlof network and communication resources. The proposedcomponent framework hides network programming detailsfrom the control system designer. The components are well-defined entities that can be replaced without affecting therest of the systems. It is shown how they can be developedand tested separately and integrated later. Building on themiddleware component framework of RUNES, we developa number of control-oriented components necessary for theimplementation of control applications and design their in-tegration. The paper provides the overview of the approach,discusses a real life application where the approach can beused and outlines a number of specific control problems thatarise in this application. Companion papers [27], [12], [14],[15] provide the details of the implementation of specificcomponents to address these control problems, as well asexperimental validation results.

The paper starts by presenting a brief overview of mid-

dleware and component frameworks in general, and thosetargeted to networked embedded systems in particular (Sec-tion II). The RUNES tunnel disaster relief scenario thatserves to focus our work is then described in Section III. Anoverview of control problems that arise in the scenario is alsogiven in the same section: maintaining the connectivity of awireless sensor network in an adverse environment, utilizingthe resources of the network itself (e.g., wireless transmissionpower control) and those of mobile robots (e.g., to replacemissing nodes). In Section IV we discuss the componentsthat need to be implemented to address the specific controlproblems in the task on physical network reconfiguration; thedetails of the development of these components and their ex-perimental testing are given in the companion papers. Someexamples of general purpose, low-level control componentsare also presented in the section. Section V details a securitycomponent framework, which provides an interface to protectcommunications among nodes. The hardware and softwareintegration for the demonstration of the physical networkreconfiguration is given in Section VI. Its validation is shownin Section VII, which describes both a computer simulationof the scenario and some preliminary experimental results.Finally, Section VIII gives an overview of this tutorial sessionfollowed by some concluding remarks in Section IX.

II. M IDDLEWARE AND COMPONENTS

A. Middleware

In a component-based software system, a component isa system element offering a predefined service and able tocommunicate with other components. A component is a unitof independent deployment and versioning. It is encapsulatedand non-context specific. It follows that components caninteract with other components without knowing much oftheir internal structure or their execution environment (for ex-ample, their operating system or network protocols). Clearly,devising such an abstract level of interaction is a non-trivialeffort. In many cases, an effective solution can be foundby the judicious application of a software abstraction layer,known as middleware. Middleware mediates the interactionsof a component with its environment by providing a program-ming interface transparent to the operating systems and tothe network protocols underneath. A comprehensive surveyof middleware concepts (motivated primarily for networkedembedded systems) can be found in [9]. Important examplesof middleware currently in use are Java Remote MethodInvocation (Java RMI) [5], Microsoft Component ObjectModel (COM) [6], and Common Object Request BrokerArchitecture (CORBA) [2]. These frameworks, however, arenot specifically targeted to embedded systems or distributedcontrol systems. The resource constrained implementationplatforms common in embedded and distributed controlsystems imply additional, severe requirements on the middle-ware. To meet these requirements, extensions of general pur-pose middleware have been developed. One such example isreal-time CORBA [30], which features prioritized schedulingpolicies for threads and export some control parameters in thecommunication protocols. Even real-time CORBA, however,

has several shortcomings that make its use on demandingembedded system applications problematic [9].

Several application domains have emphasized the im-portance of developing software infrastructures specificallytailored to the needs of the domain. For example, theautomotive industry has formed the development partnershipAUTOSAR [1], to achieve modularity, scalability, transfer-ability and re-usability of software functions in vehicles.AUTOSAR strives to provide an open system architecturefor automotive systems based on standardized interfaces forthe different system layers. A precise component definitionand an appropriate composition framework are essential toanswer a variety of questions on system architectures, e.g.,on synchronization and network protocols [25].

Specific control and real-time requirements on the middle-ware have also been investigated in recent academic softwareprototypes. Etherware [16] is a middleware for networkedcontrol that was recently proposed. This middleware focuseson the ability to maintain communication channels duringcomponent restarts and upgrades and to recovery from failuresituations. ControlWare [31] is a middleware that utilizesfeedback control for guaranteeing performance in softwaresystems. Though not specifically targeted to embedded sys-tems, its usefulness has been demonstrated on web server andproxy quality of service management. A tutorial overviewof software technologies for reusable and distributed controlsystems is given in [23].

Finally, from a theoretical point of view, semantic frame-works that support composition and abstraction operationsare central to the formal modeling and analysis of suchdistributed systems. For embedded systems (where the logicfunctions encoded in the computational elements have tointeract with a primarily analog environment) the mostrelevant frameworks are those developed in the area of hybridsystems. Several such frameworks have been proposed inrecent years, to support the modeling, verification, systemdevelopment and simulation efforts; for an overview see [29].Some are general purpose, while others are targeted tospecific application areas [18]. Most are also supported bysimulation, verification or design computer tools. A linkbetween these theoretical developments and the middlewareframeworks discussed above is just emerging as an excitingand important research area.

B. Component frameworks for networked embedded systems

The main reason for using component-based approachesin software development is to enforce re-usability. A newsoftware application is built from existing well-tested com-ponents. The components are composed (or assembled) intoapplications. It is often possible to aggregate componentstogether, forming new components.

Component-based software engineering has been success-fully used in several software development projects, pri-marily for desktop and eBusiness applications. Within real-time embedded systems, the use of component techniquesis not well-developed. For desktop applications the COMtechnology is most widely used. COM components are often

relatively large in size, each component encompassing asubstantial amount of the application functionality. Anotherwidely used class of component models are the models thathave their basis in distributed object models. These includethe CORBA Component Model (CCM) [3], Enterprise JavaBeans (EJB) [4], and .NET [7]. The .NET model can beviewed as an distributed evolution from COM that is espe-cially interesting due to Common Language Runtime (CLR).CLR is a virtual machine technology that can be compared toJava’s Virtual Machine. It is Microsoft’s implementation ofthe Common Language Infrastructure (CLI) standard, whichdefines an execution environment for program code. TheCLR executes a bytecode format into which several lan-guages can be compiled, e.g., C# and Visual C++. Throughthis it is possible to integrate software components developedin different programming languages. The drawback with theapproach, compared to, e.g., Java-based approaches, is thatit is operating system dependent, i.e., it is only supportedfor Windows-based systems. Components are viewed asextended objects that can be distributed. However, each indi-vidual object still resides on a single node in the network. Inthese types of component models object-oriented concepts,such as classes and inheritance, are integral parts.

In component technologies for embedded systems, non-functional properties such as safety, timeliness, memoryfootprint, and dependability are of particular interest. Com-pared to the desktop component approaches described abovethe component models here are much more limited infunctionality. Often the component models are intended forapplications of an algorithmic nature. These applicationsarecommonly modeled as data- or signal-driven block diagrams.Another name for this is a pipe and filter architecture.The individual components are typically smaller than in theprevious component models, and the emphasis on componentaggregation is larger. These component technologies arefrequently inspired by the block diagram approach in Mat-lab/Simulink, the function block diagrams in the automationlanguage standard IEC 61131-3, and by ordinary discretelogic gates. There are still no good examples of commerciallysuccessful component technologies for embedded systems.However, it is an area where considerable research currentlyis being performed.

For sensor network and mobile ad-hoc network applica-tions, all the component technologies above are, in principle,applicable. Sensor networks are an example of a severelyresource-constrained distributed implementation platform. Ifthey are to host sensor fusion and control applications, it isquite clear that the component technologies developed forembedded systems are a natural option. Embedded controlsystems and sensor network applications, furthermore, havemany similarities. In both cases, a component model centeredaround data flows is more natural than the focus on com-ponent function calls found in desktop component models.Following this path a possibility would be to develop a set ofgeneric sensor, data fusion, control and actuator componentsor component types; examples along these lines are outlinedin Section IV. The limited battery resources make power-

Embedded Networked Component Technologies

RUBUS ComponentModel, Koala, SaveCCM,

PECOS, AUTOSAR Component Model

Etherware, Fractal for OSGi, Sensor Bean

COM, CORBA/CCM, EJB, .NETExamples

Thin component models. No support for massive

distribution and networking

Thin component models, limited functionality,

limited real-time supprt

Large computingoverhead, large memory

footprint, client-serveronly

Drawbacks

Temporal determinism, small memory footprint,

predictable system properties

Power-awareness,distributed execution

Rich component

Advantageous Features

Data/signal flowarchitectures, compute-

intensive and algorithmic

Messaging middleware, data-centric services,

event-based

Encapsulation, support for re-use, composability,

indivual deployment, client-server architectures

Main Characteristics

Components for feedback control loops comprising

sensors, controllers and actuators

Sensor network data management (gathering,

analysis, access, reaction)

General desktop applications, real-time

and non-real-timeScope

Resource-ContrainedEmbedded Control

Ad-hoc Sensor Networking

Desktop ComponentTechnologiesComparison Table

Fig. 1. Comparison of embedded networked component technologies.

awareness an important attribute of component models forsensor networks.

The different characteristics of desktop applications andsensor/actuator networks do, however, not necessarily implythat it is not possible to base a component model forsensor/actuator networks on more conventional componenttechnologies; the development effort only becomes consider-ably larger. Rather than having built in support for data flowsin the middleware, it has to be explicitly realized throughcomponent function calls. This is the approach that has beentaken in the RUNES project.

In mobile ad-hoc network applications the resource con-straints are normally less severe than in wireless sensor net-works. More powerful CPUs with more memory and batteryresources are often used. Hence, here the desktop-type ofcomponent technologies can be applied. The components ofthis type are often more application-oriented than the simplerand more generic sensor-controller-actuator components.Ina mobile robot setting we may decompose the applicationinto components for localization, path planning, collisionavoidance, etc. These are the types of components of maininterest in this tutorial.

The table in Figure 1 summarizes embedded networkedcomponent technologies by listing their characteristics to-gether with some advantages and disadvantages.

C. RUNES middleware components

Central to our efforts in developing a component-basedframework for networked control is the RUNES middlewarecomponent model [10]. Even though sensor networks (andother ad hoc networks) are of central interest to RUNES, theRUNES middleware component model is closer in spirit tothe desktop model discussed above, than to the embeddedmodel. One reason for this is that the RUNES componentsare not only intended for the sensor nodes, but should alsoreside on the gateways and on the back-end computers.Another reason is that the RUNES components are also

intended as a means for structuring parts of the RUNESmiddleware itself.

A component-based framework for networked controlshould enable quality of service definitions and negotiationbetween the designer of the control application and themiddleware. The solution should combine the appropriatelevel of abstraction needed by control applications with alightweight and scalable architecture. The middleware shouldprovide the appropriate support for a wide variety of controlapplications, ranging from sensor networks to distributedcontrol systems. To this end, it is of utmost importance tokeep track of the level of introduced complexity. Memoryconsumption and communication latency are examples offundamental parameters in the design. Our conclusion is that,even if some existing proposals attempt to cope with someof these issues, a middleware based on a comprehensiveevaluation of the multifaceted requirements of networkedcontrol applications is still to come.

The RUNES middleware [10] is illustrated in Figure 2.The middleware acts as a glue between the sensor, actuator,gateway and routing devices, operating systems, networkstacks, and applications. It defines standards for implement-ing software interfaces and functionalities that allow thedevelopment of well-defined and reusable software. Thebasic building block of the middleware developed in RUNESis a software component. From an abstract point of view, acomponent is an autonomous software module with well-defined functionalities that can interact with other compo-nents only through interfaces and receptacles. Interfacesaresets of functions, variables and associated data types thatareaccessible by other components. Receptacles are requiredinterfaces by a component and make explicit the inter-component dependencies. The connection of two componentsoccurs between a single interface and a single receptacle.Such association is called binding and is shown in moredetail in Figure 6. Part of the RUNES middleware hasbeen demonstrated to work well together with the oper-ating system Contiki [22], which was developed for low-memory low-computation devices. The implementation ofthe component model for Contiki is known as the componentruntime kernel (CRTK). This component framework providesfor instance dynamic run-time bindings of components, i.e.,during execution it allows components to be substituted withother components with the same interface.

III. M OTIVATING SCENARIO

This section describes the RUNES tunnel disaster reliefscenario and gives an overview of some of the controlproblems that arise within the scenario.

A. Disaster relief scenario

One of the major aims of the RUNES project is to createa component-based middleware that is capable of reducingthe complexity of application construction for networkedembedded systems of all types. Versions of the componentruntime kernel, which forms the basis of the middleware,are available for a range of different hardware platforms.

Fig. 2. Overview of the RUNES middleware platform. The component-based middleware resides between the application and the operating systemsof the individual network nodes.

However, the task is a complex one, since the plausibleset of sensing modalities, environmental conditions, andinteraction patterns is very rich. To illustrate one potentialapplication in greater detail, the project selected a disasterrelief scenario, in which a fire occurs within a tunnel, muchas happened in the Mont Blanc tunnel in 1999. In this,the rescue services require information about the developingscenario both before arrival and during rescue operations,and such information is provided by a network of sensors,placed within the tunnel, on robots, and on rescue personnelthemselves. We explore the scenario in more detail below,but it should be noted this is intended to be representativeof a class of applications in which system robustness isimportant and the provision of timely information is crucial.So, for example, much the same considerations apply in theprevention of, or response to, Chemical, Biological, Radi-ological, Nuclear or Explosive (CBRNE) attacks; likewise,search and rescue operations, and even industrial automationsystems form application domains with similar requirementsfor predictability of response given challenging externalconditions.

The fire-in-a-tunnel scenario deals with disaster reliefactivities in response to a fire in a road tunnel causedby an accident, as illustrated in Figure 3. For example,in the case of Mont Blanc, a very severe fire was causedas the result of the ignition of a lorry carrying margarineand flour. The resulting fire burned for two days, trappingaround 40 vehicles in dense, poisonous, smoke, with a deathtoll of 37 people. Communications, lighting, and sprinklersystems failed within minutes of the fire starting with theresult that Christian Comte, fire brigade chief at Chamonix,is reported to have said:Sur le moment, on n’avait pasd’informations precises—on ne savait pas ce qui brulait, nia quel endroit, s’il y avait du mondea l’int erieur ou pas.In other words, there was no precise information about whatwas happening: it was not clear what was burning, nor whereit was, nor whether there were people inside the tunnel ornot. As a consequence, firefighters entered the tunnel long

Fig. 3. Illustration of the RUNES tunnel disaster relief scenario.

past the time at which they could have made a difference,and themselves became trapped.

In the RUNES scenario, we project what might happenin a similar situation if the vision of the US Departmentof Homeland Security’s SAFECOM programme becomesa reality. The scenario is based around a storyline thatsets out a sequence of events and the desired response ofthe system, part of which is as follows. Initially, trafficflows normally through the road tunnel; then an accidentresults in a fire. This is detected by a wired system, whichis part of the tunnel infrastructure, and is reported backto the Tunnel Control Room. The emergency services aresummoned by Tunnel Control Room personnel. As a resultof the fire, the wired infrastructure is damaged and the linkis lost between fire detection nodes (much as happened inMont Blanc). However, using wireless communication asa backup, information from (for example) fire and smokesensors continues to be delivered to the Tunnel ControlRoom seamlessly. The first response team arrives from thefire brigade and rapidly deploys search and rescue robots,following on foot behind. Each robot and firefighter carriesa wireless communication gateway node, sensors for environ-mental temperature, chemical and smoke monitoring, and therobots carry light detectors that help them identify the seatof the blaze.

The role of the robots in this scenario is twofold: tohelp identify hazards and people that need attention, withoutexposing the firefighters to danger; and to augment thecommunications infrastructure to ensure that both tunnelsensor nodes and those on firefighters remain in contactwith the command and control systems that the situationcommander uses to make informed decisions about howbest to respond. To accomplish this, the robots are movingautonomously in the tunnel taking into account informationfrom tunnel sensors about the state of the environment,

from a human controller about overall mission objectives,and from received signal strength measurements from thewireless systems of various nodes about the communicationquality. The robots coordinate their activity with each otherthrough communication over wireless links. Local backupcontrollers allow the robots to behave reasonably in the eventthat communication is lost.

B. Overview of control problems

The RUNES work in general and the disaster reliefscenario in particular offer a number of interesting andchallenging problems where control methods can make akey contribution. One can envision control algorithms beingdeveloped to control infrastructure resources; such as fansor fire extinguishing devices, control robot motion in orderto localize hazards or localize injured humans and assistin removing them from the disaster area, and, last but notleast, control network resources to ensure connectivity andtimely delivery of crucial information. Here we will focusour attention to this last type of control problem, namelycontrolling network resources.

The control problem of interest is sketched in Figure 4.A set of nodes with wireless communication capabilitiesare deployed inside the tunnel for monitoring purposes.As soon as an emergency situation occurs, for example anaccident involving many cars, the nodes need to transmitdata regarding the tunnel conditions to a base station. Insuch a scenario, accurate and comprehensive informationmust be provided to the base station so that correct countermeasures can be taken. It is of fundamental importance thatthe network would maintain connectivity, so that the flow ofcritical data to the base station is guaranteed. However, thenetwork could be partitioned because of a malfunction of thenodes, caused by a fire, or because the presence of obstaclesthat deteriorate or even nullifies metrics of the Quality ofService.

����������������������������������������������������������������������������������

����������������������������������������������������������������������������������

Reachable Node

Unreachable Node

Damaged Node

Tunnel Wall

Network break area

Base Station

Mobile Robot

Fig. 4. Road tunnel scenario in which part of the deployed wirelessnetwork is disconnected due to two damaged network nodes. A mobilerobot moves into the region of the damaged nodes to relay informationfrom the unreachable nodes towards the base station.

In such a critical situation, the control application isresponsible for restoring the network connectivity. This isdone by sending a mobile autonomous robot inside thetunnel, see Figure 4. The robot is equipped with a radiotransmitter–receiver so that it can maintain connectivitywiththe base station directly or through the deployed network.Once the base station determines the network break area, atarget position for the mobile robot is computed. This is doneby the network reconfiguration component. The robot thenneeds to navigate inside the tunnel until either it reaches thetarget position or it determines that the target position isoutof reach because of obstacles.

Control applications impose additional requirements onthe RUNES platform that arise from the need to manipulatethe networked systems and/or the environment in which theyare embedded. In the rest of the paper we present the orga-nization of the control system components that need to beimplemented in order to guarantee that network connectivityis reestablished. The core are the four components: networkreconfiguration, localization, collision avoidance and powercontrol. Details of the development of these components aregiven in the companion papers.

IV. CONTROL COMPONENTS FOR MAINTAINING

NETWORK CONNECTIVITY IN ADVERSE ENVIRONMENTS

This section describes the software architecture for thecontrol components used for maintaining network connectiv-ity, together with the functionality of each component. Thecontrol components outlined below follow the RUNES com-ponent model [10]. The four main control components dealwith network reconfiguration, localization, collision avoid-ance and power control. Their integration is demonstratedthrough the network reconfiguration scenario described next.The section concludes with a discussion of the low-levelcomponent library containing sensor, data fusion, controllerand actuator components; the higher level components of net-work reconfiguration, localization, collision avoidance andpower control invoke the low level components in this libraryto accomplice their goals. Communication security issues areaddressed by a specialized security component (which in turncomprises a number of subcomponents); this component isdealt with separately in Section V.

A. Physical network reconfiguration scenario

Mobile autonomous robots are sent inside the tunnel torestore connectivity, see Figure 4. The navigation of a robotinside the tunnel is made possible by two components. Thefirst is the localization component, that provides the positionand orientation of the robot inside the tunnel and informationabout the presence of obstacles. The second is the collisionavoidance component that ensures that the robot does notcollide with obstacles or other robots. Once the mobilerobot is in a suitable position it attempts to reconnect thenetwork, by acting as a relaying node between the nodesin the disconnected parts of the network. At this stage, athird component, the power control component, is invoked, toreduce the energy consumption and lower the packet collisionprobability of the nodes at the boundary of the network.In case the network is not reconnected with the first robot,additional robots could be deployed in a similar fashion.

The flowchart in Figure 5 details the sequence of tasks inthe reconfiguration scenario. The acronyms in the column tothe left indicate the control component primarily responsiblefor the action. The scenario starts by the detection of that thenetwork is disconnected. The network reconfiguration com-ponent (NetReC) then makes the decision that the first robotshould be deployed. The robot moves autonomously to thedestination using localization information about its positionprovided by the localization component (LoC). In parallel,italso uses the collision avoidance component (CAC) to avoidcolliding with stationary objects or other moving agents.When the network reconfiguration component detects thatthe robot has reached a suitable goal position (possiblyby adjusting the original destination point based on localinformation at the scene), it initializes the power controlcomponent (PCC). The radio transmission power is adjustedin the robot node and in its neighboring network nodes, inorder to not only preserve battery power but also minimizeinterference among nodes. If the network is still disconnectedafter the power has been adjusted, the algorithm starts overand a new robot is deployed.

The interrelations between the control components and theoverall application, robot actuation platform, and communi-cation network are indicated in the component frameworklayout shown in Figure 6. The components are encapsulatedsoftware units of functionality and deployment that interactwith other components exclusively through interfaces andreceptacles [10]. The figure shows that the main application,which initializes the restoration of the network connectivity,interacts with the network reconfiguration component. Thiscomponent supervises activity through its coupling to thecollision avoidance and the power control components. Thecollision avoidance component is responsible for the physicalactuation of the commands, i.e., for moving the robot. Itbases its decisions on information from the localizationcomponent, which is divided into one part handling thelocalization of neighboring robots and other potential ob-stacles, and another part providing localization informationabout the robot itself. As indicated in the figure, the control

Yes

Optimize transmission power

Robot moves to destination

Deploy robot

Network disconnected?

Start

PCC

LoC & CAC

NetReC

NetReC

NetReC

Yes

No

No

Robot at destination?

Fig. 5. Flow chart showing the actions taken in order to reestablishnetwork connectivity. The acronyms to the left indicate the active controlcomponents.

Fig. 6. Component framework layout for the control components used formaintaining network connectivity.

components rely heavily on the network communication.

B. Network reconfiguration component

The network reconfiguration component is responsibleto position the mobile robot at a point that ensures therestoration of the communication along the network. Thenetwork reconfiguration component is activated as soon asinformation about that the network is disconnected and thelocalization of the malfunctioning network nodes has beenobtained. The functionality of the component is based ona beacon, which tests the operational capabilities of eachnode near the network break area through handshaking. Theconnectivity of the mobile robot with the operational part of

the network is rather critical, because commands may be sentfrom the base station to the robot and information from therobot can be requested. The locations of the (static) networknodes are assumed to be known a priori.

The network reconfiguration component provides the goalcoordinates to the collision avoidance component, whichensures that the robot safely moves to the vicinity of thefurthest known operational node of the network. The com-ponent computes the area, within which the final positioningof the robot is possible. This area is important in the caseobstacles have occupied the damaged node’s position or donot allow for a closer visit. From the obtained position,the robot tries to establish communication with both thenetwork connected to the base station and the network thathas been disconnected. The former action is performed inorder to check the functionality of the specific node, butalso to ensure that the communication failure has not beendue to debris or other kinds of communication blocks. Ifthe functionality of the node is verified, the robot moveson to the next node, etc., until the non-operational nodeis accurately located. As soon as this node is located, thenetwork reconfiguration component provides the necessaryinputs for the initialization of the power control component.If the non-operational node cannot be located through anexhaustive search, there is a change in mode of operationinto finding a sub-optimal position within the lattice of thesensor nodes. If even this approach fails, the mobile robot ispositioned near the edge of the previously described regionand sends a message to the base station for the deploymentof a second mobile robot. The algorithm terminates as soonas the communication coverage of the region of interest iscompleted. The network reconfiguration component is furtherdescribed in [27].

C. Localization component

The localization component provides interfaces to localizemobile agents or robots. It also provides interfaces to detectobstacles in front of the mobile robot. Each mobile robotis required to contain one instance of this component. Addi-tionally, each of the stationary sensor motes within the tunnelare required to contain one instance of the complementarydistance sensor component.

The localization method is based on ultrasound. Eachmobile robot is equipped with an ultrasound sender unit andeach stationary sensor mote is equipped with an ultrasoundreceiver unit. The mobile robot periodically broadcasts aradio message shortly followed by an ultrasound pulse. Eachstationary node measures the difference in time of arrivalbetween the radio message and the ultrasound pulse, anduses this to calculate its distance to the mobile robot. Aftera predetermined time to avoid contention, a radio packetcontaining the distance is sent to the mobile robot. Afteremitting the ultrasound pulse, the mobile robot spends apredetermined time collecting distance measurements fromthe sensor nodes. After that, data fusion is applied to thecollected distance measurements. Different alternativeshavebeen evaluated. One possibility is to use triangulation. In

this approach as many triangular sensor cells as possible areformed, and a position estimate is calculated for each cell.Finally, the individual position estimates are combined intoa single estimate using outliers removal and averaging. Oncea position estimate is available this is used as an input to thecorrector part of an extended Kalman filter. The predictorpart of the filter uses the encoder information from the robotwheels to predict its current position. Alternatively, it ispossible to directly use the estimated distances as inputs tothe extended Kalman filter. Both approaches require that eachmobile robot knows the position of every stationary sensornode.

The above approach runs the risk of not working whenmultiple robots simultaneously try to determine their lo-cations. In order to avoid this problem the mobile robotsalso listen to the radio messages associated with ultrasoundmessages. If a mobile robot hears this type of message it willwait, or back off, a certain time, before attempting again toemit its combined radio and ultrasound pulse.

Once the self-localization is performed, i.e., the filteredposition and orientation estimates are available, a radiopacket containing this information together with a time-stamp is multi-casted to the other mobile robots. Thus eachmobile robot obtains information about the current locationof its neighboring mobile robots.

The ultrasound localization can only be used to detect theposition of known mobile robots. In order to detect unknownobstacles, the mobile robots need to be equipped with one orseveral forward pointing proximity or distance sensors. Onepossibility is to use an IR sensor, e.g., a SHARP GP2D12sensor. Either one or two fixed sensors are used, or a sensor ismounted on a simple RC servo, which then sweeps a certainangular region in front of the mobile robot. The localizationcomponent is further described in [12].

D. Collision avoidance component

The collision avoidance component provides an interfaceto steer, in a safe way, a mobile robot to a desired finalposition with an assigned heading. The collision avoidancestrategy is based on areserved diskassociated to each robot.The disk contains all the positions that can be reached if thevehicle performs a maximum curvature turn in clockwisedirection.

The motion strategy of the robot is based on four distinctmodes of operation, each assigning a suitable value to thecurvature rate of the robot. Figure 7 shows these modesalong with the corresponding switching conditions. The robotenters thestraight mode if is possible to move in the samedirection as the robot is heading, i.e., if its reserved diskdoes not overlap with other reserved disks. When the robotis in this mode, its curvature rate is set to zero. Whenever itsreserved disk becomes tangent to the one of another robot,a test is made based on the current motion headingθ . Ifa further movement in the direction specified byθ causesan overlap, then the robot enters thehold mode. Otherwise,the robot is able to proceed, and remains in thestraightmode. When thehold mode is entered, the robot’s curvature

Fig. 7. Finite state automaton that summarizes the collision avoidanceprotocol implemented by the collision avoidance component.

rate is set to the minimum allowable, and the motion of itsreserved disk is stopped. As soon as the robot motion in theheading direction is permitted but not directed towards thetarget destination, the robot enters theroll mode, and triesto go around the reserved disk of the other robot. This isachieved by selecting a suitable value for the curvature rateof the robot such that the two disks never overlap. Duringroll, the tangency of the two disks can unexpectedly be lost.In such circumstances, the robot enters theroll2 mode, andthe curvature rate is set to the maximum allowable in orderto restore the contact. Theroll2 mode can only be entered ifthe previous mode wasroll. When the tangency is restored,the robot switches back to thehold mode and possibly fromthere to theroll mode again.

The decentralized characteristic of the collision avoidanceprotocol allows the collision avoidance component to beimplemented on-board the robots. Each robot is able tomake a safe decision about its motion, based only onlocally available information. This information consistsofthe position and orientation of robots that are within a certainsensing or communication radius. For this reason, each robotis not required to explicitly declare its positioning goal.Thecollision avoidance component is further described in [12].

E. Power control component

The power control component provides an interface forregulating the transmission power of nodes at the boundaryof a disconnected area of the wireless network of the tunnel.The main functionality of this component is to provide apower control algorithm that adjust the power such that the

Power

updating

SINR Estimation

+

Delay

x

+

Node i

Controlling

node

- +

Quantization

Fig. 8. The transmission powers of the network nodes are controlled by thepower control component residing in the mobile robot. Each power controlloop consists of a transmitter node (on the left) and a receiver node (onthe right). The receiver node executes the control algorithm and sends thecommand to the transmitter.

network is reconnected. A fine tuning of the output power isessential to preserve the battery of the nodes and to minimizeinterference among network nodes.

The power control algorithms are based on radio modelsfor the network nodes, i.e., the Telos motes. Communicationquality is characterized through the received signal strengthindicator (RSSI), which is related to the signal to noiseplus interference ratio (SINR) for the radio devices mountedon the nodes. The power control mechanism reacts to thefluctuations of the SINR by controlling the level of powerthat the transmitter uses in order to ensure a desired packeterror probability. The power control command is computedin the receiver and then communicated to the transmitter,which transmits packets using the updated power level. Thefeedback control loop for a single transmitter–receiver pairis shown in Figure 8.

Two power control mechanisms have been developedand tested: one scheme based on a multiplicative-increaseadditive-decrease (MIAD) updated of the power, and onescheme that is based on a model of the average packet errorrate (PER). The MIAD power control, which is inspiredby [11], implements the following simple algorithm: eachcorrectly received packet imposes a decrease of the transmitpower by ∆, where ∆ is the step size; whereas when anerroneous packet is detected, the transmission power is in-creased byd∆, whered is a positive integer. The parametersd and∆ influence performance (packet error rate and powerconsumption), and thus need to be tuned. The PER powercontrol adjust the transmission power according to a modelof what power is needed for a desired SINR given the currentSINR and power. Accurate estimates of SINR and RSSI areobtained through online filters. The power control componentis further described in [14].

F. Low-level control component library

The components defined above build on and make useof lower-level components developed to perform tasks such

as polling sensors, sending commands to actuators, etc. Weconclude this section by providing a brief overview of someexamples of this type of components.

Sensor components:Two types of sensor componentscan be distinguished. A passive sensor component returns aphysical measurement, e.g., temperature, light intensity, etc,through the use of some hardware device, as the response to acall to an interface function, e.g.,getValue() from eitheranother component on the same node, from the applicationcode in the node, or from a component or applicationon some other node via the radio interface. Hence, froma passive sensor component, measurement values must bepulled by the users of the component

An active sensor, on the contrary, is realized by a separateexecution thread that provides a new measurement valueon its own initiative. This value is then forwarded to, e.g.,another component by a call to the corresponding interfacefunction of that component. Hence, the active sensor pushesnew values to the users of the component.

Another distinguishing characteristic of sensor compo-nents is whether they are time-driven or event-driven. Ina time-driven sensor the measurement is performed pe-riodically. In an event-driven sensor the measurement isperformed when an event occurs. This event could be thecall to somegetValue interface function. However, wecould also think of an event-driven active sensor that, e.g.,only generates a new output if its current value has changedsufficiently much from the old value. Also, it is not necessaryfor a passive sensor to be event-driven. A passive sensorcould be realized as an execution thread that performs thesampling periodically, but where the users of the componentstill must pull out a value, in this case typically the latestvalue, by calling an interface function.

A sensor component could also contain other functionality.Instead of generating only a value it could associate the valuewith a time stamp indicating when the value was generated.The sensor may perform filtering, e.g., low-pass filtering.For an event-based sensor several different event types areplausible, together with the associated threshold values.

Data fusion components:In sensor network applicationdata fusion or aggregation is important. A major reason forthis is a desire to reduce the communication traffic in thenetwork.

Because of the spatial distribution of the sensors, datafusion can be performed both in the time and space domain.An example of data fusion in the time-domain is down-sampling; for example, an active sensor may elect to onlyforward a reduced number of data values. This can bedone periodically, e.g., removing every second data value,or be event-driven. In the latter case one could think of adata fusion component that only forwards data values thatcorrespond to significant changes in the value. Other typesof time-domain data fusion are various sorts of averaging andwindowing. Data fusion in the space-domain shares severalsimilarities with the time-domain. Spatial averaging is oneexample.

Another distinguishing characteristic of data fusion com-

ponents is whether they are signal-based or model-based.A signal-based data-fusion component performs the ag-gregation using the signal values as the only informationsource. In model-based data fusion there is a model, e.g.,a differential equation, that describes the spatial or temporalrelationship between one or several measurements. Using thisit is possible to refine the data aggregation. Techniques basedon, e.g., Kalman filtering, can be used to estimate signals thatare not measured.

A relevant technique for redundancy reduction in theinformation flow generated by the nodes of wireless sensornetworks is distributed source data compression, e.g., [24],[19]. This technique compresses data based on the (usuallysignificant) spatial and temporal correlation of the sensormeasurements.

Controller components:A controller component realizes adynamical system and comprises the actual control algorithmof the component. A distinguishing characteristic is whetherthe component operates on a single measured signal andgenerates a single controller output (SISO controller), orwhether either or both the input and output consist ofmultiple signals (MIMO controller).

Another distinguishing feature is whether the controller islinear or non-linear. A general non-linear controller can berepresented as

xk+1 = f (xk,yk, rk)

uk = g(xk,yk, rk),

where x is a vector representing the internal state of thecontroller,y is the measurement,r is the reference or setpointfor y, andu is the output of the controller. The subscriptkindicates time step. If the functionsf andg are linear, thenthe controller is linear and can be represented as

xk+1 = Axk +Byk +Grk

uk = Cxk +Dyk +Erk

where A,B,C,D,E, and G are matrices of suitable sizes.These general forms can be one possible starting point fora controller component library. Another possibility is tofocus on commonly used special forms of the above. Someexamples are PID controllers, state feedback controllers,observer-based controllers, and lead-lag controllers.

Actuator components:An actuator component determinesthe action the system takes on the physical environment. Itshares some of the characteristics of the sensor component:it can be based on push, namely, the component provides atthe interface a function, e.g.,setValue(val), which setsthe valueval to the actuator; or it can be based on pull,namely, the actuator itself requests the value. Furthermore,the actuation can be time-driven or event-driven. In the firstcase, the actuator component is accessed at precise timeinstances, whereas in the second case it is accessed whena predefined event is detected. The actuator component mayinclude some filtering, such as a zero-order hold, or nonlinearfilters, e.g., saturation.

Fig. 9. The Security Component Framework.

V. SECURITY

In a system like the one under consideration, protectingcommunication among mobile robots and sensor nodes posesunique challenges. First of all, unlike traditional wired net-works, in a wireless network, an adversary with a simpleradio receiver/transmitter can easily eavesdrop as well asinject or modify packets. Second, in order to make thesystem economically viable, nodes are limited in their en-ergy, computation, storage, and communication capabilities.Furthermore, they typically lack adequate support for makingthem tamper-resistant. Therefore, the fact that nodes can bedeployed over a large, unattended, possibly hostile area ex-poses each individual node to the risk of being compromised.

In this wireless network, security hinges on a groupcommunication model. This means that authorized nodes inthe network share a symmetric group key that is used toencrypt communication messages. Anyone that is not part ofthe group can neither access nor inject or modify messages.This implies that when a node leaves the group, the currentgroup key must be revoked and a new one distributed toall nodes except the one that is leaving (forward security).A node may leave the group either because it has finishedits task or because it is considered malicious and thus itmust be evicted. Failure to provide the correct group keycan be interpreted as an alarm by the system, which triggerscountermeasures. It follows that the ability to revoke keystranslates into the ability to logically remove compromisednodes from the network.

The Security Component Framework provides an inter-face to protect communications among nodes and guaranteeforward security. Figure 9 shows the architecture of theSecurity Component Framework in terms of components andtheir interrelations. TheCryptographic componentprovidesan interface for the basic cryptographic primitives such assymmetric ciphers (e.g., Skipjack and RC5) and hash func-tions (e.g., SHA-1). TheRekeying componentprovides andinterface for key distribution and revocation. This componentimplements cryptographic network protocols and, therefore,uses the services offered by the Network Communicationcomponent and the Cryptographic component. Finally, theAdaptor componentimplements the communication security

Fig. 10. The rekeying tree.

policy by properly encrypting/decrypting messages. For thatpurpose, it uses the services offered by the Cryptographiccomponent and the Rekeying component. The Adaptor com-ponent provides application components with the same inter-face as the Network Communication components. It is pos-sible to transparently insert and remove the whole SecurityComponent Framework without affecting the functionality ofthe other components.

The Rekeying component guarantees forward security byimplementing a scalable rekeying protocol, which refreshesthe group key whenever a node leaves the group. The rekey-ing protocol scales to a large number of nodes because itscommunication overhead is logarithmic, and the computingoverhead is kept low by using only hash functions to verifythe authenticity of newly deployed keys.

When a node leaves, a centralized Key Distribution Serveris responsible for distributing the new group key to all nodesexcept the leaving one. These nodes have only to verify thefreshness and the authenticity of the keys coming from theserver. The key authentication mechanism levers on key-chains, a technique based on one-time passwords. A key-chain is a set of symmetric keys, such that each key is thehash pre-image of the previous one under a one-way hashfunction. Hence, given a key in the key-chain, anybody cancompute all the previous keys, but nobody can compute anyof the next keys. Keys are revealed in the reversed order withrespect to creation. Given an authenticated key in the key-chain, the nodes can authenticate the next keys by simplyapplying a hash function.

In order to reduce the communication overhead, the servermaintains a tree structure of keys, see Figure 10. The internaltree nodes are associated with key-chains, while each leaf isassociated with a symmetric private key, which each groupmember secretly shares with the server. A group memberstores the last-revealed key for every internal tree nodebelonging to the path from its leaf to the root. Hence, the keyassociated to the tree root is shared by all group membersand it acts as the group-key. When a group member leavesthe group, all its keys become compromised and have tobe redistributed. For example, let us suppose that groupmember D in Figure 10 leaves. The server then has tosecurely broadcast a new key for each internal tree node

Fig. 11. Khepera robot with a Telos mote mounted on top.

whose subtree contains theD leaf (e.g., nodes numberedwith 1, 2, and 5 in the figure). In case of a binary tree, theserver has to broadcast 2 log(n)−1 messages wheren is thenetwork size. A more detailed description of the rekeyingprotocol can be found in [20].

VI. H ARDWARE AND SOFTWARE INTEGRATION

Demonstration of the component-based design approachthrough the network reconfiguration scenario requires inte-gration of both hardware and software. In this section, theseefforts are described.

A. Hardware integration

The main hardware components for demonstrating thephysical network reconfiguration are mobile robots and awireless sensor network. A heterogeneous set of mobilerobots are used. The wireless sensor nodes are the Telosand Tmote Sky motes, which are low power IEEE 802.15.4compliant wireless sensor modules [26]. The Telos motes areequipped with humidity, light and temperature sensors. Aspart of the experimental validation this sensor network wasmade to interact with numerous mobile robotic platforms.

Figure 11 shows the simplest configuration used in ourexperiments, a Telos mote mounted on top of a Kheperarobot. In this instance, the robot and mote communicatethrough their serial ports. The Telos acts both as a sensor anda radio interface for the mobile robot. The platform shown inFigure 11 was used for the early development of the networkreconfiguration component. Subsequent development wasbased on the more powerful rover robotic platform shownin Figure 12. Again, communication between the mote andthe robot was accomplished through the serial link.

The localization component was developed and tested onan RBbot mobile robot, shown in Figure 13. The controlcomputations are done both in an integrated Tmote Sky moteand in an AVR processor. An I2C bus is used to expandcomputational capabilities and to allow data exchange be-tween components and external hardware. Localization isdone using a Tmote Sky motes with an ultrasound sender

Fig. 12. Rover–Telos mote pair.

Fig. 13. RBbot robot and ultrasound equipped Tmote Sky.

unit, as shown to the upper right in the figure. This mote ismounted at the top of the robot. A Tmote Sky mote withultrasound receiver is shown to the lower right. Such motesare placed along the walls of the tunnel and communicatewith the robots to provide position information.

The collision avoidance component was developed on afleet of mobile robots like the ones shown in Figure 14. Eachrobot comprises one Tmote Sky that implements the wirelesscommunication via 811.15.4 protocol, and part of the controlalgorithm. It also comprises three PSoC micro-controllers,connected via I2C with one another. These micro-controllersperform the computations necessary to drive the robot.The mote and the micro-controllers exchange information(encoder readings, motors actuation, execution of rest of thecontrol algorithm) via the RS232 serial interface.

Fig. 14. Robots used for the development of the collision avoidancecomponent.

The power control component was developed and testedfor a wireless sensor network that consists of Telos motes.The transceiver of these nodes uses a Direct Sequence SpreadSpectrum (DSSS) technique. Data are coded according to aDSSS operation, and then transmitted through a CSMA/CAtechnique. The Telos motes provide RSSI measurementsdefined as an average of the received signal power calculatedover eight symbol periods. The implemented power controlalgorithms are based on these measurements and a new radiomodel that was developed for the Telos motes.

B. Software integration

The connecting theme underlying the different roboticplatforms and the wireless sensor network is the componentsoftware. This is based on the Contiki operating system,which runs on all the mote platforms used in the experiments.The use of a common software substrate means that compo-nents developed by one team on one robotic platform can beported to other platforms. The hardware resources availableon the robot are exploited by the different components viathe use of the same interface protocol.

Contiki is a lightweight and flexible operating system fortiny networked sensors [22]. It is built around a simple event-driven kernel on top of which application programs are writ-ten with stack-less threads. Thus, programs can be writtenin a threaded fashion, while interprocess communication isenabled using message passing through events. Contiki has adynamic structure that allows to replace programs and driversduring runtime. Contiki provides also an implementation ofa so calledµ IP stack for TCP and UDP communication [21].Contiki implementsµAODV, a light-weight implementationof the AODV ad-hoc routing protocol. AODV [28] standsfor Ad-hoc On-Demand Distance Sensor Vector routing,which, contrary to most routing mechanisms, does not relyon periodic transmission of routing messages between thenodes. Instead, routes are created on-demand, i.e., only whenactually needed to send traffic between a source and a

destination node. This leads to a substantial decrease in theamount of network bandwidth consumed to establish routes.

The implementation of the component model for Contikiis called a component runtime kernel (CRTK). It allows theinstantiation of a variety of components and the dynamic run-time binding of them. A component can be substituted withanother component that has the same interface. Due to thememory limitations of the Telos motes, the dynamic run-timebinding of the control components has not been exploredin the demonstrations. The hardware limitations moreoverforced the use of more powerful processors, such as AVRprocessors, to be connected with the Telos motes throughI2C buses, since the computational power of the motes wasnot sufficient to execute all the control components.

VII. VALIDATION

This section describes a computer simulation of the sce-nario and some preliminary experimental results.

A. TrueTime simulation

In order to validate the network reconfiguration scenario, asimulation model has been developed. A holistic simulationapproach is crucial for this, because it should be possibleto simultaneously simulate the computations that take placewithin the nodes, the wireless communication between thenodes, the power devices (batteries) in the nodes, the sensorand actuator dynamics, the dynamics of the mobile robots,and the dynamics of the environment. In order to evaluatethe limited resources correctly, the simulation model mustbequite realistic. For example, it should be possible to simulatethe computational delays associated with the execution of thesoftware components. It should also be possible to simulatethe effects of collisions and contention in the wirelessmedium access control (MAC) layer, the propagation ofthe ultrasound pulses, as well as the effects of the limitedbandwidth of the communication bus used within the mobilerobots.

There are a number of simulation environments availablefor networked control and sensor networks. However, themajority of these only simulate the wireless communicationand the node computations. TrueTime [17], [13] is a co-simulation tool that has been developed at Lund Universitysince 1999. By using TrueTime it is possible to simulate thetemporal behavior of computer nodes and communicationnetworks that interact with the physical environment. Thismakes it possible to concurrently simulate all the aspectsdescribed above.

TrueTime is a Matlab/Simulink-based tool that facilitatessimulation of the temporal behavior of multi-tasking andevent-based real-time kernels that execute controller tasks.The tasks are controlling physical systems, which are mod-eled as ordinary continuous-time Simulink blocks. TrueTimealso makes it possible to simulate simple models of wiredand wireless communication networks and their influence onnetworked control loops. The kernel block of TrueTime isevent-driven and executes code that models, e.g., I/O tasks,control algorithms, and network interfaces. The scheduling

Fig. 16. Animation workspace for the TrueTime simulation.

policy of the individual kernel blocks is arbitrary and can bedecided by the user. Likewise, in the network, messages aresent and received according to a chosen network model.

The TrueTime simulation of the tunnel scenario consists oftwo parts: a Simulink diagram containing the nodes, robots,and networks, and an 2D dynamic animation. The Simulinkdiagram is shown in Figure 15.

The stationary sensor nodes are implemented as Simulinksubsystems that internally contain a TrueTime kernel mod-eling the Tmote Sky mote and connections to the radionetwork and the ultrasound communication blocks. In orderto reduce the wiring,From and To blocks are used for theconnections. The blocks handling the dynamic animation arenot shown in the figure. The mobile robots, two RBbots asdescribed in Section VI, are modeled as Simulink subsys-tems. Internally, these subsystems contain a TrueTime kernelmodeling a Tmote Sky mote; a TrueTime kernel modeling anATMEL AVR Mega16 processor, which acts as an interfaceto the ultrasound receiver and the proximity sensor used forobstacle detection; a TrueTime kernel modeling an ATMELAVR Mega128 processor, which is used as a compute engine;two TrueTime kernels modeling two ATMEL AVR Mega16processors, which are used as interfaces to the wheel motors;a model of the robot dynamics; and a subsystem representingthe internal I2C bus of the robot.

The ultrasound propagation is modeled by a separate net-work block, which is implemented in a similar fashion as thewireless network block. The components are implementedas TrueTime tasks and interrupt handlers. The wireless radiocommunication is modeled as the IEEE 802.15.4 protocol(the radio MAC protocol used in the Tmote Sky motes).The routing is implemented using a simulation model of theAODV protocol. The AODV protocol is in TrueTime imple-mented in such a way that it stores messages to destinationsfor which no valid route exists at the source node. Thismeans that when, eventually, the network connectivity hasbeen restored through the use of the mobile radio gateways,the communication traffic will be automatically restored.

The position of the robots and status of the stationarysensor nodes, i.e., whether they are operational or not, areshown in a separate animation workspace, see Figure 16.

The TrueTime simulation environment is further describedin [15].

Fig. 15. The Simulink model diagram. In order to reduce the use ofwires From and To blocks are used to connect the stationary sensor nodes to theradio and ultrasound networks.

B. Experimental validation

The components outlined above were all implemented onthe various robotic and sensor platforms and their perfor-mance was experimentally validated.

Figure 17 shows an example run of the collision avoidancecomponent using three robots (see also Figure 14). The topsub-figure shows the origins and destinations of the threerobots while the bottom two show the collision avoidanceprocedure with the reserved disks highlighted.

Figure 18 shows experiments for the development ofthe network reconfiguration component. Four robots and abase station (not pictured) are involved. All robots carryTelos motes. The two Kheperas (standing on boxes, see alsoFigure 11) are stationary in this experiment. The spider robot(in the background) is trying to maintain connectivity withthe base station, multi-hopping its signals over any otheravailable nodes if necessary. The transmission power of allmotes is artificially reduced so that as the spider moves awayfrom the base station it loses its connection with the rest ofthe network. The rover robot (in the middle of the picture)then moves into the gap between the spider and the network,to act as a relay node.

Figure 19 shows experiments for the development of thelocalization component. The robot shown in the forefront(see also Figure 13) is trying to navigate down the corridorbased on localization information collected from ultrasoundequipped Tmote Sky motes situated on either side nearthe walls. The two graphs show the improvement in thenavigation if this localization information is used (right) vs.open loop navigation (left).

Figure 20 shows experimental results with the powercontrol component. The temporal evolution of the averagedRSSI is presented for a situation when three transmittingnetwork nodes are connected to the receiver node mounted

on the robot. The power is adjusted according to the MIADpower control algorithm discussed in Section IV. Node 1is not within line-of-sight, whereas nodes 2 and 3 are.Therefore, the signal strength of links 2 and 3 settle quicklyto their appropriate fixed values, while link 1 oscillates inaccordance with the MIAD control strategy.

Finally, Figure 21 shows a model of a road tunnel de-veloped for the demonstration of the disaster relief scenario.Trucks, cars and firefighters are indicated by lights in the tun-nel. The position of the Telos mote shows where the wirelessnodes are positioned in this particular demonstration.

VIII. O VERVIEW OF THE TUTORIAL

A tutorial session at the European Control Conference2007 is devoted to describe in some detail the component-based framework for networked control introduced in thispaper. The session consists of the current paper and fourmore [27], [12], [14], [15]. These other papers revolve aroundthe development, implementation and demonstration of aspecific set of components. Network reconfiguration, local-ization, collision avoidance and power control componentsare described in detail together with their integration on adistributed hardware and software platform that consists ofa set of mobile robots and a wireless sensor network.

The second paper in the session is on the networkreconfiguration component. It is discussed how partiallyconnected wireless sensor networks can be reconfigured viamobile robots that aim in reconnecting the disconnectedclusters of nodes. Mobile robots are repositioned in orderto reconnect the disjoint clusters. The positions of robotsdepend on the cardinality of each cluster of nodes and theminimum distance between the clusters. The reconfigurationscheme minimizes a cost function that penalizes the numberof disjoint clusters, and the area that is not covered by

Fig. 17. Example of collision avoidance component experimental results.

the overall set of nodes. Simulation results are offered toinvestigate the efficiency of the suggested scheme.

The third paper is on the localization and collision avoid-ance components. An ultrasound-based active localizationscheme is used. Motivations for this approach are given,as well as details of how it has been implemented. Specialattention is given to the extended Kalman filter that is usedfor data fusion. The collision avoidance component is alsodescribed, including its overall policy, implementation detailsand experimental results.

The fourth paper is on the power control component forthe stationary and mobile network nodes. This component

Fig. 18. Example of network reconfiguration component experimentalresults.

Fig. 19. Example of localization component experimental results.

40 80 120 160 200 24050

40

30

20

10

0

time (s)

Me

an

RS

SI

(dB

m)

P E R = 2 ,

=

6

Link 1

Link 2

Link 3

Fig. 20. Example of power control component experimental results.Temporal evolution of the RSSI for an implementation of the MIADpowercontrol algorithm.

Fig. 21. Road tunnel model demonstrator.

is important to enlarge the network lifetime, but also toreduce the packet collision probability. Two power controlmechanisms are studied, and a component-based descriptionis provided. The power control utilizes a new radio modeldeveloped for the Telos motes. Experimental results are alsoreported.

The fifth paper is on the development of a computersimulation tool denoted TrueTime. TrueTime allows Mat-lab/Simulink simulation of the temporal behavior of com-munication networks and computer nodes that interact withthe physical environment. The recent extension of TrueTimeto wireless networks is presented in this paper. Simulationstudies of the physical network reconfiguration scenario withinteracting mobile robots and wireless sensor nodes aredescribed.

IX. CONCLUDING REMARKS

The proposed tutorial will demonstrate techniques at theheart of the design and control of complex networked embed-ded systems. Even though the work presented was motivatedby a specific tunnel disaster relief scenario, we believethat the control components developed provide a suitableframework for addressing control problems in a wide rangeof applications; possible target applications include surveil-lance and environmental monitoring, critical infrastructureprotection, transportation, agriculture, industrial automationetc. The research presented here bridges the gap betweencontrol, communication and computation technologies andsuggests a number of productive and interesting researchdirections.

Acknowledgments

The work described in this paper has been done withinthe European project RUNES. It has been a major effortof Workpackage 6 and several people of the workpackagehas contributed. Among them P. Alriksson, D. Asztalos,R. Braun, A. Cervin, A. Danesi, A. Fagiolini, C. Fis-chione, D. Henriksson, M. Johansson, E. Kolybas, I. Koveos,G. Nikolakopoulos, J. Nordh, M. Ohlin, L. Pallottino,A. Panousopoulou, P. G. Park, I. M. Savino, R. Schiavi,A. Speranzon, G. Terzakis, B. Zurita Ares. Their work isgratefully acknowledged.

REFERENCES

[1] Automotive Open System Architecture (AUTOSAR).http://www.autosar.org.

[2] Common Object Request Broker Architecture (CORBA).http://www.omg.org/gettingstarted/corbafaq.htm.

[3] CORBA Component Model Specification.http://www.omg.org/technology/documents/formal/components.htm.

[4] Enterprise JavaBeans Technology. http://java.sun.com/products/ejb.[5] Java Remote Method Invocation (RMI).

http://java.sun.com/javase/technologies/core/basic/rmi.[6] Microsoft Component Object Model (COM).

http://www.microsoft.com/com.[7] Microsoft .NET. http://www.microsoft.com/net.[8] Reconfigurable Ubiquitous Networked Embedded Systems.

http://www.ist-runes.org.[9] D5.1—Survey of middleware for networked embedded systems.

RUNES deliverable, http://www.ist-runes.org/publicdeliverables.html,2005.

[10] D5.2—RUNES middleware architecture. RUNES deliverable,http://www.ist-runes.org/publicdeliverables.html, 2005.

[11] A. Sampath and P.S. Kumar and J.M. Holtzman. On setting reverselink target sir in a cdma systems. InProc. of IEEE VTC, 1997.

[12] P. Alriksson, J. Nordh, K.-E.Arzen, A. Bicchi, A. Danesi, R. Schiavi,and L. Pallottino. A component-based approach to localization andcollision avoidance for mobile multi-agent systems. InEuropeanControl Conference, Kos, Greece, 2007. Submitted.

[13] M. Andersson, D. Henriksson, A. Cervin, and K.-E.Arzen. Simulationof wireless networked control systems. InProceedings of the 44thIEEE Conference on Decision and Control and European ControlConference ECC 2005, Seville, Spain, December 2005.

[14] B. Zurita Ares, C. Fischione, A. Speranzon, and K. H. Johansson. Onpower control for wireless sensor networks: System model, middle-ware component and experimental evaluation. InEuropean ControlConference, Kos, Greece, 2007. Submitted.

[15] K.-E. Arzen, M. Ohlin, A. Cervin, P. Alriksson, and D. Henriksson.Holistic simulation of mobile robot and sensor network applicationsusing TrueTime. InEuropean Control Conference, Kos, Greece, 2007.Submitted.

[16] G. Baliga, S. Graham, L. Sha, and P. R. Kumar. Service continuity innetworked control using Etherware.IEEE Distributed Systems Online,5(8), 2004.

[17] A. Cervin, D. Henriksson, B. Lincoln, J. Eker, and K.-E.Arzen.How does control timing affect performance?IEEE Control SystemsMagazine, 23(3):16–30, June 2003.

[18] A. Deshpande, A. Gollu, and L. Semenzato. The SHIFT programminglanguage for dynamic networks of hybrid automata.IEEE Transac-tions on Automatic Control, 43(4):584–587, April 1998.

[19] L. Di Paolo, C. Fischione, F. Graziosi, F. Santucci, andS. Tennina.Performance analysis of distributed source coding and packet aggre-gation in wireless sensor networks. InIEEE Globecom, 2006.

[20] G. Dini and I. M. Savino. S2rp: a secure and scalable rekeying protocolfor wireless sensor networks. InThe Third IEEE International Con-ference on Mobile Ad-hoc and Sensor Systems (MASS’06), Vancouver,Canada, October 9–12 2006.

[21] A. Dunkels, J. Alonso, and T. Voigt. Making TCP/IP viable forwireless sensor networks. InProceedings of the First EuropeanWorkshop on Wireless Sensor Networks, 2004.

[22] A. Dunkels, B. Groonvall, and T. Voigt. Contiki—a lightweight andflexible operating system for tiny networked sensors. InProceedingsof IEEE Workshop on Embedded Networked Sensors, 2004.

[23] B. S. Heck, L. M. Wills, and G. J. Vachtsevanos. Softwaretechnologyfor implementing reusable, distributed control systems.IEEE ControlSystems Magazine, 23(1):21–35, 2003.

[24] J. Chou, D. Petrovic, K. Ramchandran. A distributed and adaptivesignal processing approach to reducing energy consumption in sensornetworks. InIEEE INFOCOM, 2003.

[25] H. Kopetz and G. Bauer. The time-triggered architecture. Proc. of theIEEE, 91:112–126, 2003.

[26] Moteiv Corporation, http://www.moteiv.com.Telos: Ultra low powerIEEE 802.15.4 compliant wireless sensor module, 2006.

[27] A. Panousopoulou and A. Tzes. Utilization of mobile agents forvoronoi-based heterogeneous wireless sensor network reconfiguration.In European Control Conference, Kos, Greece, 2007. Submitted.

[28] C.E. Perkins and E.M. Royer. Ad-hoc on-demand distance vector(AODV) routing. InProceedings of the 2nd IEEE Workshop on MobileComputing Systems and Applications, New Orleans, LA, 1999.

[29] S. Sastry, J. Sztipanovits, R. Bajcsy, and H. Gill (Editors). Specialissue on modeling and design of embedded software.Proceedings ofthe IEEE, 91(1), 2003.

[30] D. Schmidt and F. Kuhns. An overview of the real-time CORBAspecification.IEEE Computer, 2000.

[31] R. Zhang, C. Lu, T. F. Abdelzaher, and J. A. Stankovic. Control-Ware: A middleware architecture for feedback control of softwareperformance. InInternational Conference on Distributed ComputingSystems, Vienna, Austria, 2002.