Dynamic Software Reconfiguration in Sensor Network

1. Dynamic Software Reconfiguration in Sensor Network 2008. 11. 25 Sachin Kogekar, Sandeep Neema, Xenofon Koutsoukos Published by ICW 2005 Presented by Taewan You

2. Contents • Introduction • An Tracking Application for sensor network • Reconfiguration architecture • Modeling reconfigurable applications • Implementation and Results • Conclusion

3. 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

4. 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

5. 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)

6. 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

7. 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

8. 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

9. 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)

10. 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

11. 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.

12. 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

13. 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.

14. Reconfiguration Architecture Design

15. 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

16. 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

17. 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.

18. SNRAMoLa meta-model

19. 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 DESERT Meta-Model

20. 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

21. 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.

22. 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

23. 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