Transcript A Network-Centric Approach to Embedded Software for Tiny Devices David Culler Computer Science Division U.C.

A Network-Centric Approach to
Embedded Software for Tiny Devices
David Culler
Computer Science Division
U.C. Berkeley
www.cs.berkeley.edu/~culler
Intel Research
Berkeley
A new EMSOFT paradigm is emerging
• Complete embedded systems going microscopic
Processing
Storage
Sensing
Actuation
Communication
I SDQ SD
PLL baseband
filters
mixer
LNA
10/10/2001
TinyOS EmSoft
2
A new EMSOFT paradigm is emerging
• Complete embedded systems going microscopic
• Embedded software is blown across the physical
space
Disaster
Management
Habitat Monitoring
Circulatory Net
condition-based
maintenance
10/10/2001
TinyOS EmSoft
3
A new EMSOFT paradigm is emerging
• Complete embedded systems going microscopic
• Embedded software is blown across the physical
space
• So we are looking at dense, distributed systems
of systems tightly coupled to the physical world
– control loops at many levels
– networking is central
– many new constraints
10/10/2001
TinyOS EmSoft
4
Critical issues
• Highly constrained devices
– power, storage, bandwidth, energy, visibility
– primitive I/O hierarchy
• Observation and action inherently distributed
– many small nodes coordinate and cooperate on overall task
• The structure of the SYSTEM changes
• Devices ARE the infrastructure
– ad hoc, self-organized network of sensors
• Highly dynamic
–
–
–
–
–
passive vigilance most of the time
concurrency-intensive bursts
highly correlated behavior
variation in connectivity over time
failure is common
10/10/2001
TinyOS EmSoft
5
Outline
•
•
•
•
Emerging wireless embedded systems
Platform for exploring this space
TinyOS framework
Network-centric EmSoft experiences
10/10/2001
TinyOS EmSoft
6
Networked Sensor/Act Node
• 1” x 1.5” motherboard
–
–
–
–
–
–
–
ATMEL 4Mhz, 8bit MCU, 512 bytes RAM, 8KB pgm flash
900Mhz Radio (RF Monolithics) 1-10+ m range
ATMEL network pgming assist
Radio Signal strength control and sensing
I2C EPROM (logging)
Base-station ready
stackable expansion connector
» all ports, i2c, pwr, clock…
• Several sensor boards
–
–
–
–
–
basic protoboard
tiny weather station (temp,light,hum,press)
vibrations (2d acc, temp, LIGHT)
accelerometers
magnetometers
• Integrated “quarter size” node
10/10/2001
TinyOS EmSoft
7
Basic Power Breakdown…
Active
Idle
Sleep
CPU
5 mA
2 mA
5 μA
Radio
7 mA (TX)
4.5 mA (RX)
5 μA
EE-Prom
3 mA
0
0
LED’s
4 mA
0
0
Photo Diode
200 μA
0
0
Temperature
200 μA
0
0
Panasonic
CR2354
560 mAh
• But what does this mean?
– Lithium Battery runs for 35 hours at peak load and years at
minimum load!
» three orders of magnitude difference!
– A one byte transmission uses the same energy as approx
11000 cycles of computation.
– Idleness is not enough, sleep!
10/10/2001
TinyOS EmSoft
8
Experimenting at Scale
10/10/2001
TinyOS EmSoft
9
Example TinyOS study
• UAV drops 10 nodes along road,
– hot-water pipe insulation for package
•
•
•
•
•
•
•
•
Nodes self-configure into linear network
Synchronize (to 1/32 s)
Calibrate magnetometers
Each detects passing vehicle
Share filtered sensor data with 5 neighbors
Each calculates estimated direction & velocity
Share results
As plane passes by,
– joins network
– upload as much of missing dataset as possible from each node when
in range
• 7.5 KB of code!
• While servicing the radio in SW every 50 us!
10/10/2001
TinyOS EmSoft
10
A Operating System for Tiny Devices?
• Would love to have theoretically-sound
tools to go from req. to implementation,
but...
• Traditional approaches
– command processing loop (wait request, act, respond)
– monolithic event processing
– bring full thread/socket posix regime to platform
• Alternative
– provide framework for concurrency and modularity
– never poll, never block
– interleaving flows, events, energy management
=> allow appropriate abstractions to emerge
10/10/2001
TinyOS EmSoft
11
Tiny OS Concepts
• Scheduler + Graph of Components
init
Commands,
Event Handlers
Frame (storage)
Tasks (concurrency)
Messaging Component
– frame per component, shared stack, no
heap
• Very lean multithreading
• Efficient Layering
10/10/2001
TinyOS EmSoft
internal thread
Internal
State
TX_pack
et_done
(success
RX_pack
)et_done
(buffer)
• Constrained Storage Model
init
Power(mode)
TX_packet(buf)
–
–
–
–
msg_rec(type, data)
msg_sen
d_done)
• Component:
Events
send_msg
(addr,
type, data)
Commands
power(mode)
– constrained two-level scheduling model:
threads + events
12
application
Application = Graph of Components
Route map
router
sensor appln
packet
Radio byte
bit
Radio Packet
byte
Active Messages
RFM
10/10/2001
Serial Packet
UART
Temp
photo
ADC
SW
HW
clocks
TinyOS EmSoft
Example: ad hoc, multi-hop
routing of photo sensor
readings
3450 B code
226 B data
Graph of cooperating
state machines
on shared stack
13
TOS Execution Model
• commands request action
– ack/nack at every boundary
– call cmd or post task
message-event driven
• events notify occurrence
active message
event-driven packet-pump
packet
HW intrpt at lowest level
may signal events
call cmds
post tasks
Radio byte
encode/decode
event-driven bit-pump
bit
– preempted by events
10/10/2001
crc
event-driven byte-pump
• Tasks provide logical
concurrency
• Migration of HW/SW
boundary
Radio Packet
byte
–
–
–
–
data processing
application comp
RFM
TinyOS EmSoft
14
TinyOS Execution Contexts
events
Tasks
commands
Interrupts
Hardware
10/10/2001
TinyOS EmSoft
15
Dynamics of Events and Threads
bit event filtered
at byte layer
bit event =>
end of byte =>
end of packet =>
end of msg send
thread posted to start
send next message
radio takes clock events to detect recv
10/10/2001
TinyOS EmSoft
16
Quantitative Analysis...
4000
Multihop Router
3500
AM light
AM Temp
3000
AM
Packet
2500
Radio Byte
RFM
2000
Photo
Power down when task queue empty
Temp
UART Packet
1500
UART
i2c
1000
Init
TinyOS Scheduler
500
C Runtime
Components
AM
0
Packet
Radio handler
Radio decode thread
RFM
Radio Reception
Idle
Total
10/10/2001
TinyOS EmSoft
Packet reception Percent CPU
work breakdown Utilization
0.05%
1.12%
26.87%
5.48%
66.48%
100.00%
0.20%
0.51%
12.16%
2.48%
30.08%
54.75%
100.00%
Energy (nj/Bit)
0.33
7.58
182.38
37.2
451.17
1350
2028.66
17
Maintaining Scheduling Agility
• Need logical concurrency at many levels of the
graph
• While meeting hard timing constraints
– sample the radio in every bit window
Retain event-driven structure throughout
application
Tasks extend processing outside event window
All operations are non-blocking
lock-free scheduling queue
10/10/2001
TinyOS EmSoft
18
Typical split-phase pattern
char TOS_EVENT(SENS_OUTPUT_CLOCK_EVENT)(){
return TOS_CALL_COMMAND(SENS_GET_DATA)();
}
char TOS_EVENT(SENS_DATA_READY)(int data){
VAR(buffer)[VAR(index)++] = data;
if (full()) TOS_POST_TASK(FILTER_DATA);
return 1;}
• clock event handler initiates data
collection
• sensor signals data ready event
• data event handler posts task to process
data
10/10/2001
TinyOS EmSoft
19
Tiny Event-Driven Active Messages
TOS_FRAME_BEGIN(INT_TO_RFM_frame) {
char pending;
TOS_Msg msg;
}
TOS_FRAME_END(INT_TO_RFM_frame);
destinations
source buffer
handler
...
s=TOS_COMMAND(SEND_MSG)(TOS_MSG_BCAST,AM_MSG(INT_READING),&VAR(msg)))
...
char TOS_EVENT(MSG_SEND_DONE)(TOS_MsgPtr sentBuffer){
...}
TOS_MsgPtr TOS_MSG_EVENT(INT_READING)(TOS_MsgPtr val){
...
return val;}
10/10/2001
TinyOS EmSoft
20
Conservative Component Coupling
• Each component has bounded state and
concurrency
• Each command interface has explicit
handshake
each component must deal with rejections
• Message layer may reject send request if
full or busy
• Requestor cannot busy wait
send_done event broadcast to all potential senders
send_buffer pointer used to disambiguate
can elect to retry or drop
10/10/2001
TinyOS EmSoft
21
Communication Storage Management
• Strict ownership protocol at appln components
• Each component ‘owns’ set of buffers
• send => comp. ‘gives’ out-buffer till send_done
– component tracks state
• receive => system ‘gives’ in-buffer to handler
– handler must return a free buffer to the system
– if completely consumed, returns same
– otherwise, returns another one it ‘owns’
» if none available, must give back incoming
10/10/2001
TinyOS EmSoft
22
Crossing Layers without buffering
• stack consists of series of
data pumps
• each peels off portion of
packet and feeds to lower
layer
• task starts event-driven data
pump
upper fsm
appln comp
buffer handoff
active message
packet-pump
Radio Packet
byte-pump
Radio byte
lower fsm
bit-pump
RFM
10/10/2001
TinyOS EmSoft
23
Deadline Avoidance
• Pipelines transmission – transmits single byte
while encoding next byte
• Trades 1 byte of buffering for easy deadline
• Separates high level latencies from low level
real-time requirements
• Encoding Task must complete before byte
transmission completes
• Decode must complete before next byte arrives
Encode Task
Bit transmission
Byte 1
start
Byte 2
Byte 3
Byte 1
Byte 2
RFM Bits
10/10/2001
TinyOS EmSoft
…
Byte 4
Byte 3
24
Low-Power Listening
• Costs about as much to listen as to xmit, even when
nothing is received
• Only way to save power is to turn radio off when there is
nothing to hear.
• Can turn radio on/of in <1 bit
– 30 ms on every 300 ms
– Can detect transmission at cost of ~2 bit times
 Small sub-msg recv sampling
Xmit:
sleep
preamble
message
b
Recv:
Optimal Preamble = (2/3 Sxb)1/2
 Application-level synchronization rendezvous to
determine when to sample
10/10/2001
TinyOS EmSoft
25
Feedback within comm. stack
• Media access control
– radio is single shared channel (spatial multiplexing)
» want to avoid protocol msgs (RTS, CTS)
– CSMA implemented in software
– traffic is highly correlated
» must randomize initial delay, as well as backoff
– able to deliver 70% of channel bandwidth fairly
• Byte layer implements listening and backoff
• If fails to acquire channel
–
–
–
–
signals failure event
propagates up the stack
application gets send_done failure
able to adapt sampling rate, transmission rate, etc.
10/10/2001
TinyOS EmSoft
26
The nodes are the infrastructure
• Network discovery and multihop routing are just
additional active message handlers
– every node is also a router
• Example: Beacon-based Network discovery
if (new mcast) then
record ‘parent’
retransmit from self
else
record neighborhood info
10/10/2001
TinyOS EmSoft
27
Network Discovery: Radio Cells
10/10/2001
TinyOS EmSoft
28
Network Discovery
10/10/2001
TinyOS EmSoft
29
Self-organization has complex dynamics
2e
2b
2a
2d
1
0
2c
10/10/2001
TinyOS EmSoft
30
Multihop Bandwidth Management
• Should self-organize into fair, dynamic multihop net
• Hidden nodes between each pair of “levels”
– CSMA is not enough
• P[msg-to-base] drops with each hop
– Investment in packet increases with distance
– need to optimize for low-power fairness!
• RTS/CTS costly (power & BW)
 Local rate control to approx. fairness
 Priority to forwarding, adjust own data rate
 Additive increase, multiplicative decrease
 Listen for retransmission as ack
10/10/2001
TinyOS EmSoft
31
Example: Multihop Adaptive Transmission
Control
Max rate: 4 samples/sec
- rate = 4p
Channel BW ~20 p/s
1
8
- cannot expect more than 1/3
thru parent
Monitor number of children (n)
1
5
1
4
1
6
B
1
7
a(n) ~ 1/n
b=½
p’ = p + a(n) on success (echo)
p’ = p * b
node
14
15
16
17
18
10/10/2001
mean
0.36
0.56
0.55
0.55
0.39
p/s (COV)
(64%)
(14%)
(11%)
(12%)
(11%)
without rate control,
success drops ~½ per hop
TinyOS EmSoft
32
Rich set of additional challenges
•
•
•
•
Efficient and robust security primitives
Application specific virtual machines
Time & space information in every packet
Density independent wake-up, aggregation
– sensor => can use radio in ‘analog’ mode
• Resilient aggregators
• Programming support for systems of generalized state
machines
• Programming the unstructured aggregate
– SPMD, Data Parallel, Query Processing, Tuples
• Understanding how an extreme system is behaving and
what is its envelope
– adversarial simulation
• Self-configuring, self-correcting systems
10/10/2001
TinyOS EmSoft
33
Summary
webs.cs.berkeley.edu or www.tinyos.org
• Distribute the embedded system over many
small devices
• Integrated them with communication
• New set of embedded software challenges
– local scheduling, synthesis, etc. must address resource
constraints
– plus the distributed aspects
• Operating against energy constraints
– rather than overload
• Inherent asynchrony
• NEST platform due in Jan
– working 10/5
10/10/2001
TinyOS EmSoft
34