1

Pattern-Oriented Composition and Synthesis of Middleware

Services for NEST

PI: Akos Ledeczi – Miklos Maroti – Ken FramptonAffiliation: 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

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

a2

x4 b1

m2

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

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

HIA: Clock and Timer

statetransitioninput action (?)output action (!)

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

0 1 32

Time Stamping on MICA2

0 1 2 3 4

4

5

5

hw and sw delay (~1386 μs)bit-offset (~0-365 μs)

time stampsync …

hw interrupt

min min

average

header data

sen

der

rece

ive

r 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

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

0

5

10

15

20

25

30

35

40

45

50

0:00 0:10 0:20 0:30 0:40 0:50 1:00 1:10 1:20 1:30 1:40 1:50 2:00 2:10

Time (hh:mm)

mic

rose

cond

s

0.00%

10.00%

20.00%

30.00%

40.00%

50.00%

60.00%

70.00%

80.00%

90.00%

100.00%

perc

enta

ge

average error (μs)

maximum error (μs)

syncronized motes (%)

B.A. C. D.

A. All motes are turned onB. The first leader is turned offC. Randomly selected motes

were reset every 30 seconds

D. Half of the motes were switched off

E. All motes were switched back onE.

first leadersecond leader

layout and links:1 message per 30 seconds per mote

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

Directed Flood-Routing Framework

app id “rank” packet 1 packet 2 packet nmsg format:

3 bytes

Engine

sent

rece

ived

aged

getR

ank

acce

pt

rece

ive

send

OS / Radio stack

unre

gist

er

regi

ster

PolicyPolicyUserUserApplication(s)

• 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

s255

11 …a

a

253

r−

7 9a

0 1 3

4

s

5

a

a

6 sa

r+

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

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

gra

die

nt

flo

od

ing

fat

span

nin

g-t

ree

flo

od

ing

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

SensorboardTime Sync

Muzzle Blast&

ShockwaveDetector

RemoteControl

SensorboardInterface

SensorboardConfig/Monitor

StackMonitor

DataRecorder

DownloadManager

Acoustic EventEncoder

TimeSync

MessageRouting

UserInterface

MessageCenter

SensorFusion

PlotterLogger

SensorLocation

RemoteController

I2C UART

SENSORBOARD MICA2 MOTE BASE STATION

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