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

Copyright © 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) PI Institution: Institute for Software Integrated Systems, Vanderbilt University Contract #: C-1903 AO number: L538 Award start date: 6/2001 Award end date: 5/2005 Agent name & organization: Al Scarpelli, AFRL/IFTA

Copyright © Vanderbilt University 3 Subcontractors and Collaborators Subcontractors –None Collaborators –Berkeley –MIT –Ohio State/Iowa –Virginia –UIUC –Rutgers

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 Q3 FY03):  PSL based on Asynchronous IO Automata theory provides a solid compositional foundation for NEST middleware representation  Formal representation of services enable the analysis, verification and automatic generation and system-level optimization of the middleware layer (CCSL)  Proof-of-concept demonstration of shooter localization showed the applicability of NEST technology to a challenging military application DISSECT 4QFY03 Shooter Localization System 1QFY04 Revised modeling language in DISSECT 2QFY04 Extended middleware service library in DISSECT Enhanced composition capability for DISSECT Synthesized middleware for the Shooter Localization System 3QFY04 Enhanced synthesis tool for UCB Mote/TinyOS platform Q4Q1Q2Q3

Copyright © Vanderbilt University 5 Component and composition verification Use I/O Automata –Existing tool chain developed at MIT (Nancy Lynch) IOA language: nondeterministic, declarative Safety and liveness properties Forwards and backwards simulations Invariants, and other assertions (first order language) Composer, theorem prover (Larch), and simulator Network size and topology is not limited –Exploit existing and verified distributed algorithms Model each interface using IOA –Two models: user and provider –Compose these two models –Specify and verify assertions

Copyright © Vanderbilt University 6 Module verification Model each module using IOA –Has used and provided interfaces –The interfaces have implemented and expected interface model –State properties that this implementation relies on Verify that the module implements its used and provided interface models using bi-simulation –For each implemented interface model (red dot), compose the module with all other expected interface models (blue dot). –Verify the bi-simulation from this composition to the implemented interface model module used interface provided interface implemented model expected model

Copyright © Vanderbilt University 7 Configuration verification No new IOA models, just composition State and verify new invariants and properties Verify interface implementation configuration component

Copyright © Vanderbilt University 8 Gratis II Graphical Development Environment for TinyOS New version supporting NesC and TinyOS v1.0 directly Automatic configuration generation Automatic TinyOS parsing Just released Plan to support TinyOS and nesC v1.1

Copyright © Vanderbilt University 9 Interface checking Graphical environment for TinyOS component interface checking Interface automaton model of a component Automatic wrapper generation: –nesC component –exercises component implementation –verifies its runtime behavior Undergraduate project Plans: –Merge with Gratis II –Verification that two connected components are compatible

Copyright © Vanderbilt University 10 Time Synchronization Algorithm: –Each mote maintains a separate local and global time –Simple integrated leader election –Leader broadcasts its time and a sequence number –Message is timestamped in the radio stack –Receivers update their global time and rebroadcast it –If message arrives with known sequence number, it is discarded –Motes keep last ten local and global time pairs and perform linear regression –If leader is lost, new leader is elected Performance: –+/- 2 jiffies (+/- 60 microseconds) error per hop –One timesynch round per minute (i.e. one msg per min per mote) Experiment: –50 motes –10 hop diameter –Worst error: jiffies Demonstrated on Monday by Berkeley

Copyright © Vanderbilt University 11 Acoustic Ranging Uses the standard sensor board (buzzer & microphone) One mote sends radio message and chirps repeatedly afterwards: –1 second –16 chirps –non-uniform delay between chirps (to lessen the effect of echoes) Receiver: –takes timestamp of radio message –samples acoustic channel at 18 KHz, stores data in buffer –adds signals together improving signal to noise ratio –applies KHz digital bandpass filter –obtains time of flight using peak detection and filtering –estimates distance using speed of sound Average error: 15 cm Range: 10 meters (limited by buffer size) Issues (we plan to address in the near future): –does not work inside (echoes) –does not work as well on grass

Copyright © Vanderbilt University 12 Acoustic Self-Localization Two-phase algorithm: –Timeslot negotiation: Each mote needs unique time slot within a neighborhood of 2 radio hops Each mote picks a number, broadcasts it, conflict resolution on mote ids 30 seconds (regardless of network size) –Repeated acoustic ranging: When one mote chirps, all neighbors listen One round takes 2 minutes (depends on deployment density) Data is routed back to the base station Base station carries out localization –Based on spring model –Needs at least 3 anchors Localization using 10 ranging rounds takes 20 minutes

Copyright © Vanderbilt University 13 Experimental Results 50 motes, 30 x 15 meter area, random distribution, asphalt, moderate noise (AC units, street traffic)

Copyright © Vanderbilt University 14 Raw Ranging Data 10 rounds 3000 individual measurements Average distance error: 27 cm Most outliers due to a single mote (hardware failure?)

Copyright © Vanderbilt University 15 Filtered Ranging Data Filtering out outliers: –Calculate standard deviation for each pair of motes –Discard ranging data outside the deviation –Take average of remaining data Linear data correction: –27 cm offset –Will be incorporated into acoustic ranging –Depends on temperature (!) Average ranging error: 13 cm

Copyright © Vanderbilt University 16 Localization Data Average localization error: 9 cm Worst error: 25 cm (Internal error in reference locations: 4 cm)

Copyright © Vanderbilt University 17 Localization Summary Centralized algorithm Works in 3D Effects of temperature/humidity on speed of sound Experimental results: –50 motes, 400 square meters –5 anchor points –One faulty mote/sensor board: its measured data were discarded –13 cm average ranging error –9 cm average localization error –25 cm worst localization error –Microphone and buzzer are not colocated: can add max 5 cm error

Copyright © Vanderbilt University 18 Directed Flood Routing Framework Flood Routing: –Ad-hoc routing –Automatic aggregation –Implicit acknowledgments –Very low overhead –Table management –Configurable Data packet: –Fixed size length –Must contain unique part Flooding Policy: –Defines the meaning of “location” and gradient –Controls the flooding, and retransmission –Retransmit only if packet is not heard from “closer” to the intended target. Application: –Can change the packet on the way –Can drop the packet on the way flooding policy application flood routing flooding policy application app id “location” packet 1packet 2packet n msg format: 3 bytes

Copyright © Vanderbilt University 19 Flooding Policies Broadcast, or N-hop broadcast. Converge cast: route to root –“location” is the hop count distance from the root. –Root performs 16 broadcasts, this saturates the network. Nodes calculate the average hop count from root. –Experimental result: 50 motes, 20 x 40 m area, 5 hops average distance, to send query and get all responses (6 bytes): 3 seconds Converge cast to closest sink –“location” is the hop count distance from the closest sink. Geographic routing: –“location” is (x,y) coordinates –Message contains source and target coordinates. Application can: –Record the node ids of the intermediate nodes. –Drop the packet if too old based on a timestamp. source target root source

Copyright © Vanderbilt University 20 Utilities Message Center: Java framework to monitor and display messages in the network –Connected to one or more GenericBase applications –Can monitor all messages –Extensible/configurable: pluggable GUIs –Table display with multiple configurable message formats –Filtering, time stamping, sorting Stack watchdog: monitors available space between stack and application memory DiagMsg: –“printf(…)” for the motes –Integrated w/ Message Center –Integrated w/ Matlab by Berkeley Improved GenericBase: –Message buffering –Synchronized serial communication w/ CRC –Extended Xbow’s code Sound recorder: –Programmable sampling rate up to 18KHz –Turns radio off –Downloadable to base station –Creates.WAV file Clap detectol: –acoustic triggering –300 Hz sampling –Leaves radio on

Copyright © Vanderbilt University 21 Shooter Localization: a UW demonstration Detect TOA of acoustic shockwave and muzzle blast MICA2 motes New sensorboard: –3 acoustic channels –High-speed AD converters –FPGA for signal processing: shockwave and muzzle blast detection on board –I2C interface to mote –2 AA batteries Timestamp of shockwave and/or muzzle blast sent to mote Motes send data to base station Base station fuses data, estimates shooter position and displays result Middleware services: –Time synchronization –Message routing

Copyright © Vanderbilt University 22 t 1 -vd 1 t 2 -vd 2 t 3 -vd 3 t 4 -vd 4 time f(x,y) = variance t2t2 t1t1 t4t4 t3t3 ? d1d1 d2d2 d3d3 d4d4 f(x,y) TDOA Localization: Error Surface

Copyright © Vanderbilt University 23 Sensor Fusion Muzzle blast: three dimensional error function (x,y,z) Shockwave adds three more (azimuth, elevation, bullet speed) Multigranular search Utilizes all data, does it incrementally as data becomes available Provides estimate, overall error and individual measurement error Discards outliers Multipath effect: –Direct line-of-sight motes get real data first –Attenuated signals not recognized as shockwave and/or muzzle blast –Sensor fusion discards outliers

Copyright © Vanderbilt University 24 The experiment at McKenna MOUT site at Ft. Benning NORTH B1 Church B1 Church  June 4-6, 2003 (at 4 months into the effort)  Used different setups w/ 20 motes  Standard sensorboard:  18 KHz sampling rate  Periodically turned radio off  No routing, 1-hop network  No self-localization  No shockwave detection  ~200 shots fired from ~40 different locations  Used blanks and Short Range Training Ammunition (SRTA)  Used M-16 and M-4, no sniper riffle  Single shooter, operating in semiautomatic and burst mode  Variety of shooter locations (bell tower, inside buildings/windows, behind mailbox, behind car, …) chosen to absorb acoustic energy, have limited line of sight on sensor networks

Copyright © Vanderbilt University 25 Example shooter localization

Copyright © Vanderbilt University 26 Performance of the shooter localization experiment SRTA only Blank + SRTA  Results for one particular setup: 56 shots (25 SRTAs and 32 blanks)  More accurate w/ live fire (much louder):  80% shots have <2m error  Some of the blank shots were chose to test the limits of the system:  Outside network, shooting away from network  Outside sensor network accuracy gets worse  Accuracy is expected to get better w/ shockwave data

Copyright © Vanderbilt University 27 Shooter Localization Issues New hardware just arrived: Troubleshooting Algorithm development, and implementation in VHDL Tuning and testing Heat? Shockwave detection untested yet: Silencer? Long range Integration of acoustic self-localization: Memory constraints New sensor board vs old sensor board? Effect of echoes? Routing: Delay of current version: 50% - 1 sec, 75% - 2 secs, 100 % - 3 secs Multiple base stations? Integration into McKenna wireless infrastructure Integration w/ MIT GUI on PDA

Copyright © Vanderbilt University 28 Recent Contributions Composition: IOA-based techniques GRATIS II for graphical TinyOS development Automatic interface checker tool Middleware Services: Time synchronization Localization Message routing Utilities: Message center Several others Shooter localization (UW demonstration): New sensor board Shockwave and muzzle blast recognition algorithms Sensor fusion algorithm 2D / 3D user interface

Copyright © Vanderbilt University 29 Project Plans Q4 FY03:  Continue developing middleware services for UCB mote platform especially focusing on the shooter localization problem  Continue the implementation of a shooter localization system using the UCB motes  Revise DISSECT modeling language*  Gather middleware services for the UCB mote platform from other NEST researchers* Q1-Q3 FY04:  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*  Utilize the shooter localization system middleware to demonstrate the enhanced capabilities of DISSECT. Evaluate results.* Goals:  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