Pattern-Oriented Composition and Synthesis of Middleware Services for NEST

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

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. Subcontractors and Collaborators • Subcontractors • None • Collaborators • Berkeley • MIT • Ohio State/Iowa • Notre Dame • UIUC • Rutgers • Parc

4. Lédeczi, ISIS MW Service Lib New Ideas a2 Application Application Application m2 x4 b1 CCSL Middleware Middleware I/O Automata I/O Automata I/O Automata Platform A Platform A Platform A Impact Schedule Pattern-Oriented Composition and Synthesis of Middleware Servicesfor NEST Composition DISSECT • 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. Analysis and Optimization 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 Synthesis  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 Q2 Q3 Q4 • 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. • 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

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. 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. Gratis II: Acoustic Ranging

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. 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. state transition input action (?) output action (!) HIA: Clock and Timer

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. Time Stamping on MICA2 header data sender … sync time stamp 0 1 2 3 4 5 hw and sw delay (~1386 μs) bit-offset (~0-365 μs) 0 1 2 3 4 5 byte (~417 μs) hw interrupt sw interrupt receiver handling delay (95% 0-1 μs) (5% 1-20 μs) min min average 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. 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. Time Sync Experimental Evaluation layout and links: 1 message per 30 seconds per mote first leader second leader • All motes are turned on • The first leader is turned off • Randomly selected motes were reset every 30 seconds • Half of the motes were switched off • All motes were switched back on A. B. C. D. E.

15. Temporal Model of Time Sync

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. 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 Directed Flood-Routing Framework app id “rank” packet 1 packet 2 packet n msg format: 3 bytes

18. 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 Flooding Policies

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

22. 2.5D Visualizer

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. Shooter Locator Software Architecture I2C UART User Interface Sensorboard Time Sync Muzzle Blast & Shockwave Detector Time Sync Sensor Fusion Sensor Location Sensorboard Interface Acoustic Event Encoder Message Routing Message Center Remote Controller Sensorboard Config/ Monitor Data Recorder Remote Control Plotter Logger Download Manager Stack Monitor SENSORBOARD BASE STATION MICA2 MOTE

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