Dynamic Software Reconfiguration in Sensor

Network

Sachin Kogekar, Sandeep Neema, Xenofon Koutsoukos

Published by ICW 2005

Presented by Taewan You

2008. 11. 25

Contents

• Introduction• An Tracking Application for sensor

network• Reconfiguration architecture• Modeling reconfigurable applications• Implementation and Results• Conclusion

2

Introduction

• Wireless sensor network– Number of nodes spread across a geographical

area, deployed in an ad hoc manner– Wireless communication, occasionally actuators,

and computation capabilities

• Reconfiguration and self-adaption– Virtual capabilities of sensor network that are

required to operate in dynamic environments

• Dynamically adaptive software– Detect system changes, reflect on the event

occurrences, and adapt to the new operating conditions

3

Sensor Node Technology• Widely used Platforms

– Berkeley MICA mote• Very small factor: 58mm * 32mm * 7mm• Constraint resources: 4MHz microcontroller, 4KB of RAM, 128KB of flash memory• Runs TinyOS operating system

– Event driven and modular OS desinged

• TinyOS application– Compiled graph of components– Components have memory frames to store their

state, and communicate with other• A typical MICA system

– Consist of tens to hundreds of motes forming and adhoc multi-hop network and a base station that is typically a PC class computer

4

Modeling sensor network• Composition and Synthesis

– Gratis: Visual Composition and Synthesis Environment for TinyOS

– Built using the Generic Modeling Environment (GME)• Meta programmable toolkit using UML

and OCL– Automatic generation of all

configuration files from graphical models

• Model Integrated Computing (MIC)– Domain-specific models to represent

S/W– Model-Integrated Program Synthesis

(MIPS) used for the modeling– UML, Object Constraint Language (OCL)

are used in the Multigraph Architecture (MGA)

5

Dynamic Reconfiguration• Software domain

– Commonly used to refer to software mechanisms that logically attach and detach system resources from an operating environment without incurring downtime

• Wireless Sensor Network– Ability of deployed nodes to organize and

reorganize themselves when some nodes are lost• Retrieve information from the environment• Transmit this information to a base station

• Embedded world– Ability of a programmable System-On-Chip (SOC) to

change its functionalities at run-time, performing seemingly different functions at different instances in time

6

Contributions

• Dynamic software reconfiguration– Constraint based approach for determining

network configuration during runtime– Prototyped a software architecture– Key components

• A domain-specific modeling environment– Sensor Network Reconfiguration Architecture

Modeling Language (SNRAMoLa)• A constraint-based design-space exploration tool

– DESERT• A suite of runtime components and services

– Allow monitoring the operating conditions and enacting the reconfiguration instructions

7

Case Study

• Sensor network Testbed– Eight Red Hat Linux OpenBrick-E wireless devices

• Each node is equipped with a Logitech QuickCam Pro 4000 webcam.

– Windows XP base station• The base-station is connected to one sensor node through a

wired 802.3 LAN

– The distributed aislemonitor application• Designed to perform one-dimensional tracking of people walking in an

aisle

8

Reconfiguration Architecture (1/2)

• Building Self-adaptive sensor networks– Utilizes explicit models of the design space

of the embedded application • Captured by formally modeling all the software

components and their interactions based on the Asynchronous Data Flow model of computation

– System requirements are expressed as formal constraints• Operational parameters such as power

consumption, latency, accuracy, and other QoS properties etcs.

• These constraints are expressed in the Object Constraint Language (OCL)

9

Reconfiguration Architecture (2/2)

• The exploration of the operation– Parameterized constraints captured in the

embedded models– Online constraint solving using a

combination of symbolic constraint satisfaction and linear programming

• Two major tasks for Reconfiguration– Finding the new configuration– Switching or reconfiguring the components

that are actually executing on the individual sensors

10

Reconfiguration Process (1/2)

• During design time– The entire application is modeled in the Generic Modeling

Environment (GME) – The Sensor Network Reconfigurable Applications

Modeling Language (SNRAMoLa) for component based sensor network applications supports the modeling of alternate implementations of the same components and explicit representation of constraints in OCL

– The constraints are resolved over these attributes by the DEsign Space ExploRation Tool (DESERT) and valid configurations of the application are generated

• During run-time – Detecting failure, the Global Constraint Monitor (GCM)

(located on the base station) updates the values of the critical QoS attributes in the application models.

– A change in the values of the attributes invokes the reconfiguration process.

11

Reconfiguration Process (2/2)

• During reconfiguration – Finding a new configuration is performed by a controller

program executing on the base station – The SNRAMoLa models of the application form the design

space for selecting the valid configurations of the application

– The design space exploration tool, DESERT evaluates the constraints and selects an appropriate configuration by pruning the design space

– The output of DESERT is used in the generation of a set of configuration files, one for sensor

– Sending the new configuration files to the individual– It reads from the new configuration file and, stops, rewires

or starts active or dormant application components already present on the sensor nodes by Configurator components

– The Monitor components monitor the health of the network – These communicate with the GCM component executing on

the base station in case of failure in the network

12

Software infrastructure for Reconfiguration

• SNRAMoLa to DESERT Interpreter– Converts the SNRAMoLa application model to a format compatible with

DESERT– The converted data is fed to DESERT as an XML file

• DESERT to Configurator Interpreter– DESERT applies the constraints and generates another XML file, which

enumerates the design configuration in the pruned space– Generates a configuration file, which is then physically transported to the

nodes over the wireless network• Configurator

– Maintaining two link-list data structure and a memory ID counter to implement the reconfigurable infrastructure

– During initialization, Configurator opens a socket to listen for incoming signals from the base station.

– After initialization, Configurator goes in an infinite loop where it continues to listen for new messages on the open port coming from the base station.

• Monitor– Execute on each node and monitor QoS parameters of itself and its

immediate neighbors.

13

Reconfiguration Architecture Design

14

Modeling reconfigurable application

• SNRAMoLa (Sensor Network Reconfigurable Application Modeling Language)– A graphical Modeling language – To model the design space of the sensor network application in

Generic Modeling Environment (GME)– Defined with UML class diagrams– This modeling paradigm is based on the Asynchronous Data

Flow (ASDF) model of computation– Components based software systems

• SNRAMoLa paradigm – Enables the user to model complex component based sensor

network applications in a more intuitive manner. – Enables the user to model components that can be replaced by

others during runtime– The user can visualize the applications executing on individual

sensor nodes

15

Core concepts for Modeling (1/2)

• Component object– Separate process in the application– Contain InPort(s) and OutPort(s)– Either Reconfigurable or Non-reconfigurable

• Can be replaced or be irreplaceable in the application graph• ComponentsFolder declares non-reconfigurable components• Choice declares reconfigurable components

– ‘Path’ attribute• Identifies the physical path of the executable

• InPort object– Declared in Component or Choice object– Accept data from another Component object

• OutPort object– Declared in Component or Choice object– Send data to another Component object

16

Core concepts for Modeling (2/2)

• DataFlow object– A connection object that links an output port of a Component object

with an input port of another Component object– The Asynchronous flow of data from one application component to

another.

• Choice object– To model reconfigurable or mutually replaceable Component objects

in the application graph

• Condition object– Each Choice object contains at least one Condition object that

specifies a constraint expressed in OCL – During the reconfiguration process, this constraint is evaluated by

DESERT over the collection of reconfigurable Component objects also contained in the same Choice object

– Only those Component objects that satisfy the constraints are selected for inclusion in the final application graph.

17

SNRAMoLa meta-model

18

Design space exploration• DESERT

– Design space exploration tool developed by using MIC

– An intuitive user interface lets the user perform the exploration interactively

– The end result of the exploration is a pruned design space

• Evaluation design space– Design space can be summarized as

hierarchically layered parameterized – Design configuration

• Km = (Km-1 + 1) * n, K1 = n, (a*n)m leaf element

– Example• n = 4, a = 3, m = 3• Total of 1728 leaf elements can represent 384

design configuration in the space

19

DESERT Meta-Model

Testbed - Monitoring system design

• SNRAMoLa modeling– The Receiver and the

ImageSensor components continue to execute

– Only the Estimator1 and DataCollector1 components are stopped and their alternatives are started

• Explorating Constraints runtime– Pavailable – cuurently available

total power of the nodes– Adesired – current accuracy

requirements

20

Scenario• Test Case Design

– The tests that involved more than one person walking in the aisle were designed such that at any given time

– Disable OpenBrick device, sensing Gap occurs• Reconfiguration invoked

• Reconfiguration– Configuration 1

• One person was in the range of the sensor network for some interval of time but never in the range of the same OpenBrick device.

– Configuration 2• The components of the neighboring OpenBrick devices

then take over the prediction of the people in this range by predicting their position.

21

Results• Reconfiguration process overhead

– Total reconfiguration process took in 18 sec– Reconfiguration was achieved without affecting the entire

application

• Tracking results– The third OpenBrick device is executing the second configuration

22

Conclusion

• Develop and demonstrate– Dynamic software reconfiguration in

sensor network• Application Modeling using by SNRAMoLa• Exploration of design space using by

DESERT runtime• Real sensor network application

– Aislemonitor application to tracking of people working

– Linux-based sensor nodes

23