1. 1 Pattern-Oriented Composition and Synthesis of Middleware Services for NEST PI: Akos Ledeczi – Miklos Maroti – Ken Frampton Affiliation: Vanderbilt University

2. 2 Administrative Project Title: Pattern-Oriented Composition and Synthesis of Middleware Services for NEST PM: Vijay Raghavan PI: Ákos Lédeczi PI phone # : (615) 343-8307 PI email: akos.ledeczi@vanderbilt.edu Institution: Institute for Software Integrated Systems, Vanderbilt University Contract #: 733615-01-C-1903 AO number: L538 Award start date: 6/2001 Award end date: 5/2005 Agent name & organization: Al Scarpelli, AFRL/IFTA

3. 3 Subcontractors and Collaborators Subcontractors –None Collaborators –Berkeley –MIT –Ohio State/Iowa –Notre Dame –UIUC –Rutgers –Parc

4. Impact New Ideas Schedule  Using the Pattern Specification Language (PSL), NEST middleware services are formally captured as design patterns.  Requirements, applicability and resource constraints are also formally captured.  Library of middleware services specified in PSL is defined.  Composable Coordination Service Layer (CCSL): desired design patterns are composed and the application-specific middleware satisfying all constraints is automatically synthesized.  Support for optimization and dynamic reconfiguration.  Employ technology to solve the challenging shooter localization problem using an ad hoc wireless sensor network. Pattern-Oriented Composition and Synthesis of Middleware Services for NEST Lédeczi, ISIS  A design pattern specification language allows capturing and documenting common and reusable middleware services for DoD systems.  Composable Coordination Service Layer (CCSL) ensures that only necessary services are included in the middleware providing a thin layer that can run efficiently on the resource limited nodes.  Rapid and cost-effective composition of application-specific middleware layer(s).  Approach supports upgrades and reconfiguration performed dynamically enabling uninterrupted operation of DoD systems.  An accurate shooter localization system would significantly increase war fighting capabilities and could lessen casualties. MW Service Lib a2a2 x4x4 b1b1 m2m2 Application I/O Automata Platform A Middleware Application I/O Automata Platform A Middleware Application I/O Automata Platform A CCSL Composition Analysis and Optimization Synthesis Summary of Results (as of Q1 FY04):  Formal representation of services enable the analysis, verification and automatic generation and system-level optimization of the middleware layer  Our precise time synchronization service and the directed flooding routing framework are applicable to a wide range of sensor network applications  Successful demonstration of shooter localization showed the applicability of NEST technology to a challenging military application DISSECT 2QFY04 Mobile Shooter Localization System Demonstration 3QFY04 Revised middleware modeling language New sensorboard, shot detection and sensor fusion 4QFY04 Extended middleware service library in DISSECT Enhanced composition and synthesis capability for DISSECT Enhanced Shooter Localization System Demonstration Q4Q3Q2

5. 5 Recent Contributions Composition: GRATIS II ported to TinyOS v1.1 Hierarchical interface automata based temporal models Automatic composition verification tool Middleware Services: Improved time synchronization Improved message routing framework Remote Control Utilities: StackMonitor 2.5D Visualizer JProwler Shooter localization (UW demonstration): System integration of the application Highly successful demonstration at Ft Benning Publications

6. 6 Composition and Synthesis Gratis II: Visual Composition and Synthesis Environment for TinyOS Ported to nesC 1.1 Built using the Generic Modeling Environment (GME) –Meta programmable toolkit using UML and OCL Hierarchical representation of TinyOS applications –Interfaces: set of events and commands –Modules: interface references and implementation code –Configurations: set of interface, module and configuration references Automatic generation of all interface, module and configuration source files from graphical models Can parse existing TinyOS applications and libraries and build equivalent graphical models –In TinyOS 1.1 over 10000 connections and objects are provided as a library to the user –Necessary to keep visual models and source base in sync Extensible through meta-model composition and add-ons

7. 7 Gratis II: Acoustic Ranging

8. 8 Automatic Verification and Testing TinyOS interfaces do not describe the temporal and behavioral aspects of components –Native TinyOS components are not verifiably composable Hierarchical Interface Automata (HIA) formalism –Hierarchical extension of the Interface Automata of de Alfaro and Henzinger TinyOS applications are inherently hierarchical –Adopted to the concurrency model of TinyOS Pessimistic component compatibility non-preemptable states are introduced –Two hierarchical interface automata is compatible if no illegal state can be reached from the initial states in the composed automaton HIA is the formal foundation of temporal models of TinyOS interfaces, modules and configurations

9. 9 HIA Models in Gratis II Integrated into Gratis II –HIA models are hierarchical state-transition diagrams –Natural extension of the TinyOS composition architecture –Interweaved with interface references –Interfaces define the actions of HIA models Used to automatically detect: –incorrect wiring of components –components not obeying the implicit contract of interfaces Configuration verification –Verifies that the composed modules and interfaces are compatible –Implemented in Prolog –The graphical HIA models are translated into logic programs Module verification –Model verification of nesC code is hard (especially if obfuscated) –We automatically generate a wrapper around modules to verify the consistency between the implementation and its temporal model at runtime

10. 10 HIA: Clock and Timer state transition input action (?) output action (!)

11. 11 Time Stamping Time synchronization primitive: establishing time reference points between a sender and receiver(s) using a single radio message –Sender obtains timestamp when the message was actually sent in its own local time –The message can contain the local time of the sender at the time of transmission (or the elapsed time since an event) –Receiver obtains timestamp when the message was received in its own local time On NEST systems time stamping should/can be integrated into the network layer Calibration is necessary because of receiver side bit-offset Selection of clock for local time –CPU clock: high resolution, not stable, no power management –External crystal clock: relatively stable, allows power management, hard to implement Uses –time sync protocols –time sync debugging –acoustic ranging –shooter localization (implicit time sync while routing)

12. 12 0132 Time Stamping on MICA2 01234 4 5 5 hw and sw delay (~1386 μs) bit-offset (~0-365 μs) time stamp sync … hw interrupt min average headerdata sender receiver byte (~417 μs) sw interrupt handling delay (95% 0-1 μs) (5% 1-20 μs) Mica2: 1.2 μs average error, 4.5 μs maximum error Mica2Dot: 4 μs average, 12 μs maximum error Limiting factor: the stability of the CPU clock

13. 13 Time Synchronization Time Synchronization metrics –It should NOT be only end-to-end accuracy –Network load (in msgs per second per mote) –Start-up time (as a function of the network diameter) –Fault tolerance nodes leaving and entering the network nodes with incorrect or unstable local times network topology changes Flooding Time Synchronization Protocol (FTSP) –Sender-receiver multi-hop time synchronization –Integrated leader election, global time is synchronized to the local time of the leader –End-to-end accuracy: average 1.2 μs per hop, maximum 6 μs per hop –Constant network load: 1 msg per 30 second per mote –Start up time: network diameter times 60 seconds –Uses the Time Stamping module –Topology change tolerant: motes can move with speed less than 1 hop per 30 seconds. –Available from the contrib/vu directory of the TinyOS CVS. Real challenges: scalability, rootless time sync (Ted Herman, Iowa)

14. 14 Time Sync Experimental Evaluation B.A.C.D. A. All motes are turned on B. The first leader is turned off C. Randomly selected motes were reset every 30 seconds D. Half of the motes were switched off E. All motes were switched back on E. first leader second leader layout and links: 1 message per 30 seconds per mote

15. 15 Temporal Model of Time Sync

16. 16 Ad-hoc Routing Network neighborhood (Alec Woo et al, UCB) –Effective region: higher than 95% message delivery –Transitional region: variable 5-95% message delivery –Clear region: less than 5% message delivery, almost no interference Mica2 under no load: single mote is transmitting –Effective region is 0-10 feet –Transitional region is 10-40 feet Mica2 under heavy load: most motes transmit –Effective region: 5 feet, transitional region: 5-30 feet –70% of the motes in the transitional region receive messages with less than 30% –There are polite (never transmits) and impolite (causes collision) motes Use probabilistic methods: rely on the unreliable –It is more probable that one of the motes with less that 30% delivery rate will receive a broadcasted message than one with a higher rate –Do not limit the next hop to a single node –Long unreliable links can route messages faster than short reliable ones Must be tailored to the application via pluggable routing policies (also observed by Markus Fromherz, PARC)

17. 17 Directed Flood-Routing Framework app id “rank” packet 1packet 2packet n msg format: 3 bytes Flood Routing Engine: –Ad-hoc routing –Automatic aggregation –Implicit acknowledgments –Table/cache management –Very low overhead Flooding Policy: –Defines the meaning of “rank” –Controls the flooding and retransmission Application: –Can change the packet on the way –Can drop the packet on the way Data packet: –Fixed size length –Must contain unique part

18. 18 Flooding Policies Broadcast –Rank is void Converge-cast based on hop-count gradient –Rank is hop count from root –Nodes retransmit messages if their rank is smaller Geographic routing –Rank is location –Target location is contained in message Fat spanning-tree converge-cast Each flooding policy defines a state machine –On each node each data packet is in one of the states –Actions: received, sent, aged –States are numbered from 0 (initial state) to 255 (final state) –Packets with low numbered states are more important –Packets with even numbered states are eligible for transmission

19. 19 Fat Spanning-Tree Convergecast A spanning tree is formed Each node needs to know the node ID of its –parent –grandparent –great-grandparent –great-great-grandparent The “rank” of the node is the node ID of its grandparent If the rank of the sender is –the node ID of the grandparent of the receiver, then the sender is at the same distance –the node ID of the receiver or its parent, then the sender is further from the root than the receiver –the node ID of the great- or great-great-grand parent of the receiver, then the sender is closer to the root –non of the above: not in the same channel or further away. Increases the reliability and robustness of tree routing protocols Scales linearly with distance gradient flooding fat spanning-tree flooding

20. 20 Other Components StackMonitor: on-line stack overflow monitoring RemoteControl: –Sends commands and configuration information to all or a selected set of motes –Motes send back acknowledgments and error codes –Uses the Directed Flood-Routing Framework (multi-hop) –Simple pluggable command modules LedCommands : set / query LED status VoltageCommands: query current voltage StackCommands: query current / minimum free stack space RadioCommands: set the current transmit power / radio frequency TimeSyncCommands: query time sync precision FlashCommands: clear measurement flash buffer, download through radio or UART Sensorboard configuration and monitoring –Java application configurable to send various commands displays the replying node IDs and their error codes

21. 21 Message Center

22. 22 2.5D Visualizer

23. 23 Shooter Locator Summary Ad-hoc wireless network of cheap acoustic sensors is used to accurately locate enemy shooters in urban environment Demo Deployment at Ft. Benning –60 motes –100x40 meter area –8-hop network Performance of shooter localization –Average accuracy: 1 meter in 3D –Latency: 2 seconds Performance of software components –Sensorboard detection latency: 0.1 second –Routing: 20-40 acoustic events detected (muzzle blast + shock wave) Up to 4 sensor readings are aggregated into a single radio message 50% of the acoustic events arrive in the first 0.5 second 100% of the acoustic events arrive in the first 1.5 seconds –Sensor fusion: Incremental processing Latency: 0.4-0.8 second –Remote control performance: Round time: 1-2 seconds Reply rate: 95%

24. 24 Shooter Locator Software Architecture Sensorboard Time Sync Muzzle Blast & Shockwave Detector Remote Control Sensorboard Interface Sensorboard Config/ Monitor Stack Monitor Data Recorder Download Manager Acoustic Event Encoder Time Sync Message Routing User Interface Message Center Sensor Fusion Plotter Logger Sensor Location Remote Controller I2CI2CUART SENSORBOARD MICA2 MOTE BASE STATION

25. 25 Publications  Simon, Maróti, Lédeczi, Balogh, Kusy, Nádas, Pap, Sallai, Frampton: Shooter Localization in Urban Environments, submitted to IPSN 2004  Ledeczi, Maróti, Simon, Balogh, Kusy, Nadas, Pap, Sallai, Frampton: Sensor Network-Based Countersniper System, submitted to MobiSys 2004  Volgyesi, Maróti, Dora, Osses, Ledeczi, Paka: Embedded Software Composition and Verification, submitted to Pervasive 2004  Volgyesi, Maróti, Dora, Osses, Ledeczi: Software Composition and Verification for Sensor Networks, submitted to the Journal of Science of Computer Programming Special Issue on New Software Composition Concepts  Kusy, Maróti: Flooding Time Synchronization in Wireless Sensor Networks, submitted to WCNC 2004  Sallai, Balogh, Maróti, Lédeczi: Robust Self-Localization with Low-Cost Hardware in Sensor Networks, submitted to WMAN 2004  Maróti: Directed Flood-Routing Framework for Wireless Sensor Networks, submitted to WMAN 2004  Kusy, Maróti: Robust Time Synchronization Protocol for Sensor Networks, submitted to WMAN 2004

26. 26 Project Plans Q2 FY04:  Enhance shooter localization for multiple shots, different weapons type, large scale (hierarchical sensor net architecture), power management etc.  Revise DISSECT modeling language*  Gather middleware services for the UCB mote platform from other NEST researchers* Q3-4 FY04:  Continue the development of enhanced shooter localization system  Model all available services in DISSECT*  Revise and enhance the composition capabilities of DISSECT*  Revise and enhance the code synthesis tool for UCB mote platform/TinyOS* Goals:  Successful demonstration of the shooter localization system  Have at least 8 different services captured in DISSECT  Full support for composing these services and synthesizing TinyOS code  Capability to model, compose and generate middleware layer of shooter localization system * Rescheduled milestone