Upload
isra
View
47
Download
0
Embed Size (px)
DESCRIPTION
Pattern-Oriented Composition and Synthesis of Middleware Services for NEST. PI: Akos Ledeczi – Miklos Maroti – Ken Frampton Affiliation: Vanderbilt University. Administrative. Project Title : Pattern-Oriented Composition and Synthesis of Middleware Services for NEST PM : Vijay Raghavan - PowerPoint PPT Presentation
Citation preview
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: [email protected]
• 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