cyber physical nsf
Post on 07-Apr-2018
223 Views
Preview:
TRANSCRIPT
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 1/59
Low-Power Sensor Networks
Philip Levis (and John Regehr in abesntia)
Stanford University and the University of UtahNSF HCSP-CPS Workshop
November 30, 2006
Alexandria, VA
A Case Study in Seeking Distributed Predictability
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 2/59
Predictable
TinyOS and the specter of low-power
Limited resources and communication
Black box operation
Systems are easy; predictable/dependable systems arehard
Large numbers, distributed through space
Failures are inevitable: isolating them is paramount
Systems approach: TinyOS, TinyOS 2.0/T2Networking approach: MNet
This talk has nothing to say about real-timeMore on why later
2
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 3/59
Outline
A brief history of: 1.0, 1.1 and 2.0 (T2)
T2 core structure, language/OS co-design
MNet architecture
Real Time?
3
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 4/59
In the Beginning(1999)
Sensor networks are on the horizon...
... but what are they going to do?
What problems will be important?
What will communication look like?
What will hardware platforms look like?
Having an operating system is nice...... but how do you design one with these uncertainties?
4
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 5/59
The TinyOS Goals(ASPLOS 2000)
Allow high concurrencyOperate with limited resources
Adapt to hardware evolution
Support a wide range of applications
Be robust
Support a diverse set of platforms
5
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 6/59
History
6
1999 2006
2000TinyOS 0.4perl scripts + CWeC platform (30)
2001TinyOS 0.63perl scripts + CWeC + rene (1000)
2002TinyOS 1.0nesC 1.0rene + mica
2003TinyOS 1.1nesC 1.1>20 platforms
2006TinyOS 2.0nesc 1.29 platforms
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 7/59
TinyOS Basics
A program is a set of components
Components can be easily developed and reused
Adaptable to many application domains
Components can be easily replaced
Components can be hardware or software
Allows boundaries to change unknown to programmer
Hardware has internal concurrency
Software needs to be able to have it as well
Hardware is non-blockingSoftware needs to be so as well
7
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 8/59
Software
Crypto
EncryptThis
EncryptFinished
Component
TinyOS Basics(2000)
Hardware
CryptoTasks
EncryptThis
EncryptFinished
Non-volatile
Storage
Non-volatile
Storage
Component 8
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 9/59
Software
Crypto
EncryptThis
EncryptFinished
Component
TinyOS Basics, Continued(2002, nesC)
Hardware
CryptoTasks
EncryptThis
EncryptFinished
Non-volatile
Storage
Non-volatile
Storage
Interface
Component 9
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 10/59
The TinyOS Goals(A Scorecard, 2005)
Allow high concurrency (A)Operate with limited resources (A-)
Adapt to hardware evolution (B)
Support a wide range of applications (B)
Be robust (D)
Support a diverse set of platforms (B-)
10
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 11/59
Robustness Drives Design
Allow high concurrency (A)Operate with limited resources (A-)
Adapt to hardware evolution (B)
Support a wide range of applications (B)
Be robust (D)
Support a diverse set of platforms (B-)
11
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 12/59
TinyOS 0.6 -> TinyOS 1.0
Introduce nesC language instead of perl + C
Compilation benefits
Pre-nesC linked compiled components into an executable
The nesC compiler generates a single C file
Whole program analysis
Whole program optimization (code the native compiler likes)
Dead code elimination
InterfacesEstablish programming abstraction as a language abstraction
Prevent bugs
12
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 13/59
TinyOS 1.0 -> TinyOS 1.1
Major addition: async keyword
Synchronous code: tasks (non-
preemptive)async code is safe to calloutside a task
Interrupt handlers are all async(preemptive code)
To call sync code, async codemust post a tasksync examples: start a ms timer,send a packet
async examples: start a 32kHzalarm, send a byte over a bus
13
Async
Sync
TaskScheduler
Hardware
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 14/59
Async vs. Sync
Async code can preempt sync code
Might cause data races, atomic statements
Sync code is written assuming no preemption
Sync code executes atomically with respect to other sync code
Simple, easy to write, no data races
Tasks are the interface which transforms async to sync
The explicit sync/async distinction allows nesC todetect all data races at compile time
Fixed >100 data races in TinyOS (6 races/1000 lines)
14
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 15/59
Outline
A brief history of: 1.0, 1.1 and 2.0 (T2)
T2 core structure, language/OS co-design
MNet architecture
Real Time?
15
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 16/59
TinyOS Evolution
TinyOS 1.x improved component dependabilityAdding language mechanisms for better checking
Low-level system code (few writers, many users)
OK to trade verbosity for dependability
Push checks to compile-time when possible
TinyOS 2.0 takes the next step: system predictability
16
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 17/59
Failures of Implementation
Components intended to be independentUnforeseen interactions
“The ADC hangs when I send packets!”
“Time synchronization gives crazy readings!”
“When I turn of the radio my application hangs!”
“When I boot with flash support the radio stops working!”
17
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 18/59
Failures of Structure
TinyOS 1.x has no resource management
Most operations can fail at any time (busy)Packet transmission
Bus access
ADC sampling
Depends on higher-level retries
Global “done” events (e.g., GenericComm.sendDone)Fan-out has deterministic scheduling
No component isolation
18
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 19/59
Allocation
TinyOS has always followed a static allocation policy
Argument: dynamic allocation leads to dynamic failures
One major 1.x exception: the task schedulerMajor source of failures
Inherent inter-component dependency
19
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 20/59
Concurrency Model
T2 has the same basic concurrency model
Tasks, sync vs. async
T2 changes the task semanticsTinyOS 1.x: post() can return FAIL, can post() multipletimes (shared slots)
T2: post returns FAIL if the task is already in the queue(single reserved slot per task)
TinyOS 1.x T220
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 21/59
Static Binding
Run-time vs. compile time parameters
interface CC2420Register {
command uint16_t read(uint8_t reg);
command uint8_t write(uint8_t reg, uint16_t val);command uint8_t strobe();
}
component CC2420C {
provides interface CC2420Register;
}
interface CC2420StrobeReg {
command uint8_t strobe();}
component CC2420C {
provides interface CC2420StrobeReg as SNOP;
provides interface CC2420StrobeReg as STXONCCA;
....
}
21
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 22/59
Static Allocation
You know what you’ll need: allocate it at compile-time
(statically)Depending on probabilities is a betI.e., “it’s very unlikely they’ll all need to post tasks at once” =“they will”
You know what components will use a resource, canallocate accordingly
In some cases, static allocation can save memory
Less defensive programming/error handling
22
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 23/59
Predictability Saves Memory
module Foo {
bool busy;
command result_t request() {if (!busy() &&
post fooTask() == SUCCESS) {
busy = TRUE;
return SUCCESS;
}
else {
return FAIL;}
}
module Foo {
bool busy;
command result_t request() {return post fooTask();
}
TinyOS 1.x T2
23
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 24/59
The Power of Counting
Basic language mechanism that TinyOS provides
Ability to count elements in an application at compiletime
unique(key): for each key, returns a unique number starting at 0
uniqueCount(key): returns number of calls to unique(key)
Each needed service or abstraction can use its own key
Tasks: uni ue(“Tin SchedulerC.BasicTask”), etc.
24
unique(...) = 1
unique(...) = 2
uniqueCount(...) = 8
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 25/59
Basic OS Requirement: QoS
Flaw in many protocols: under load, routing failsData packets overflow queues
Control packets are lost, routes disintegrate
Priorities are dicult: they can break promises
I’ve agreed to forward this data packet, but have to drop it now...
Defining priorities across many protocols can be dicult
Want to promise a minimum quality of serviceControl trac receives at least k/n of the available bandwidth
A control packet has to wait for at most x packets
25
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 26/59
QoS Through an OS Interface
Every component that needs to send a packetinstantiates an instance of a packet sending service
Broadcast, collection, unicast, etc.
Each instance of the service can have at most oneoutstanding packet at any time
Like tasks, send fails if and only if a packet is alreadypending
26
Sender
Application
Sender
Application
Time Time
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 27/59
QoS Through Counting
Each instance allocates a queue entry with unique(...)
The service has a queue of length uniqueCount(...)
Implementation scans through the queue for pendingpackets
27
Sender Sender Sender Sender
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 28/59
Extending the Model
A protocol can allocate more than one sender for agreater share
28
Sender Sender Sender Sender Sender
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 29/59
Extending the Model
A protocol can allocate more than one sender for agreater share
A protocol can introduce its own queue
Still uses k n bandwidth
29
Sender Sender Sender Sender Sender
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 30/59
More Defensive Programming
Interfaces allow programs to easilyswap component implementations
Exchange SerialAMSenderC forAMSenderC
Interfaces are weakly specifiedAllow implementation dif erences
E.g., 1.x SendMsg vs 2.0 Send
Weak specifications lead todefensive programming
More code -> more errors
Wastles resources
30
Packets
EncryptThis EncryptFinished
Router
?
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 31/59
Interface Contracts
Specify valid call patternswith annotations
Per-interface basis (heavy reuse)
Both sides of the interface
Base case: hardwareabstractions follow contracts
Inductive static, dynamic,run-time checking
Run-time approach has detectedseveral serious bugs in 1.x(which turn out to be impossibleby design in 2.0)
31
HPL
HAL
HIL
Service
Application
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 32/59
Outline
A brief history of: 1.0, 1.1 and 2.0 (T2)
T2 core structure, language/OS co-design
MNet architecture
Real Time?
32
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 33/59
Sensornets Are Hard
Sensor networks often fail/operate poorly
Great Duck Island network: median yield 58% [SenSys 2004]
Redwood network: median yield 40% [SenSys 2005]
Volcano network: median yield:68% [OSDI 2006]
Survey of causes
Protocol conflicts/interference
Collisions and congestion induced loss
Neighbor management (with layer 2 scheduling, e.g. TMAC)
Don’t know!
Low-power, limited resources make complete loggingprohibitively expensive...
33
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 34/59
Management
Give operators a peek into the sensornet black box
SNMS [EWSN 2005]: lightweight get/set
Sympathy [SenSys 2005]: expert system
34
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 35/59
MNet Principle
The diculty in deploying and developing sensornets ispart of the essence of this class of systems.
Large numbers, limited energy, distributed over space, dif erent
views of the environment, noise, local optimizations, etc.
This is more than an artifact.
MNet principle: Improve visibility into the internaloperation of the network.
Quantify: Minimize the energy required to identify the cause of
network behavior.Case study: network protocols.
35
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 36/59
Goal
36
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 37/59
37
Inter-Protocol Interference
Snooping is a common routing approachImplicit acks, rate control, backpressure, etc.
Vulnerable to inter-protocol interference
Reduces energy eciency, can even cause failures
One misbehaving protocol can prevent anyone elsefrom performing well
SINKA B C
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 38/59
Isolation
Isolating behaviors simplifies reasoning.
Basic technique in systems: apply to networks
If any protocol X, Y, Z can a protocol to fail, then wehave a larger (more expensive) state space to explore
We need a way to isolate protocols from one another, sothey can operate concurrently but not interfere.
Mechanism: grant-to-send (GTS)
38
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 39/59
Grant-To-Send
A transmitter may embed a quiet time in a packet.
No-one except the destination may transmit for theduration of the quiet time (including transmitter).
Sending a packet grants the channel to the receiver.
39
0 0 0 0
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 40/59
Grant-To-Send
A transmitter may embed a quiet time in a packet.
No-one except the destination may transmit for theduration of the quiet time (including transmitter).
Sending a packet grants the channel to the receiver.
40
0 0 0 02
2
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 41/59
Grant-To-Send
A transmitter may embed a quiet time in a packet.
No-one except the destination may transmit for theduration of the quiet time (including transmitter).
Sending a packet grants the channel to the receiver.
41
2 0 0 02
2
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 42/59
Grant-To-Send
A transmitter may embed a quiet time in a packet.
No-one except the destination may transmit for theduration of the quiet time (including transmitter).
Sending a packet grants the channel to the receiver.
42
1 0 2 02
2
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 43/59
Grant-To-Send
A transmitter may embed a quiet time in a packet.
No-one except the destination may transmit for theduration of the quiet time (including transmitter).
Sending a packet grants the channel to the receiver.
43
0 0 2 21
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 44/59
Grant-To-Send
A transmitter may embed a quiet time in a packet.
No-one except the destination may transmit for theduration of the quiet time (including transmitter).
Sending a packet grants the channel to the receiver.
44
0 0 1 202
2
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 45/59
Fairness
Isolation is insucient.The simplest approach is to not let anyone do anything.
Every protocol should receive its fair share of thenetwork bandwidth.
Wireless is inherently distributed
Dif erent views of the channel
Perfect fairness is not always possible (but we can be close)
Mechanism: fair queueingGTS times represent channel utilization
Naturally fit into fair queueing
45
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 46/59
Fair Queueing(Demers, Shenker, and Keshav)
46
Send protocol which has lowest channel utilization.
P1
P2
P3
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 47/59
47
Fair Waiting Protocol
Uses Grant-To-Send
mechanism
Sits between CSMA layer
and network layer
Fair queueing according
to the channel occupationConsiders the grant duration
as a channel occupation
FWP
CSMA
Network Protocols
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 48/59
48
Single-Hop Uniform Lossless Load
Ideal case without collisions and packet losses
Perfect fairness among nodes and protocolsCSMA allows all nodes to have equal chance of transmission
All nodes agree on channel usages of protocols, thus perfectfairness among protocols
Perfect Isolation
Every node waits until the current quiet time expires
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 49/59
49
Loss
Lost packets can cause inconsistentview of the channel occupationtimes of protocols
Experimental Setting:
Five nodes in single-hop range
Three protocols with dif erent quiet times(20ms / 40ms / 80ms)
Normalized share of one node
High channel fairness: 0.99 (Jain’sFairness Index)
However, individual nodes areservicing protocols unevenly
“Ping-pong Ef ect”
0
0.2
0.4
0.6
0.8
1
0 100 200 300
Time (s)
C h a
n n e l S h a r e P1
P2
P3
TT+1
T-1T+1
T-1T
T-2T
P2P1
T+2T+1
T+1T+1
T+1T
TT
P2P1
P2
P2
P1
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 50/59
50
Multihop Uniform Load
Uniform loads on 40
nodes on motelab
20 / 40 / 80 ms (Fig. 1)
20 / 60 / 140 ms (Fig. 2)Plain (no decay)
Global fairness : 0.997
Poor transmit fairness
Decaying every 500 ms
Global Fairness : 0.995
Best transmit fairness
Understanding the
decaying period better is a
future work
C D F
C D F
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 51/59
51
Real Loads - ARC
ARC: rate-limiting collection protocol [Mobicom 2001]
Goodput and cost for two separate ARC instances running in the
presence of two other protocols (PSFQ and Trickle)
FWP increases ARC goodput by 23-30% and decreases cost by 5-10%
0
2
4
6
8
10
ARC1 ARC2
G o o d p u t ( p a c k e t s / s )
CSMA
FWP
0
2
4
6
8
ARC1 ARC2
C o s t ( t x / g o
o d p u t )
CSMA
FWP
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 52/59
Network Protocols
FWP isolates networkprotocols from each other
How do we isolate causeswithin a protocol?
Apply minimization
principle to higher layers
52
FWP
CSMA
Network Protocols
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 53/59
Case Study: Collection
53
5 principal causes of packet loss
1. Retransmit timeout2. Queue drop
3. False positive duplicate suppression
4. Reboot
5. Kaboom!
Origin sequence numbers, THL field
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 54/59
High THL?
Suppression Queue Drop
Decision Tree
54
No more packets?
Seq No. Break?
Reboot
Death/Disconnect
Requires no querying of network state!
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 55/59
MNet Architecture
Elevate management and visibility to an architecturalprinciple and design goal
Isolation of causes
Fairness (protocol, node, application...)
FWP as the narrow waist
55
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 56/59
Outline
A brief history of: 1.0, 1.1 and 2.0 (T2)
T2 core structure, language/OS co-design
MNet architecture
Real Time?
56
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 57/59
The Real-Time Tension
Real-time is inherently unfairSome people get to go first!
Understanding *why* something failed is hard (Mars Rover)
Necessitates local operations and internal decisions
Makes it more dicult to understand the internal operation of thesystem
Optimal scheduling of a scarce resource
Uncommon in sensornets because utilization is so low...
Event-driven, not periodic workloads
Wireless is an inherent challenge
Outside of your control
57
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 58/59
Predictability
Being able to assume things will behave in a certain way
Breaking outside current approachesLanguage-OS co-design
Static, dynamic, run-time approaches
Predictable networks, not just systemsNetwork is increasingly cause of failure
Wireless more so...
58
8/3/2019 Cyber Physical Nsf
http://slidepdf.com/reader/full/cyber-physical-nsf 59/59
Questions
top related