1. A Network-Centric Approach to Embedded Software for Tiny Devices
David Culler
Computer Science Division
U.C. Berkeley
Intel Research
Berkeley

2. A new EMSOFT paradigm is emerging
Complete embedded systems going microscopic
Processing
Storage
Sensing
Actuation
Communication
LNA
mixer
PLL
baseband
filters
I SD
Q SD
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
Circulatory Net
Habitat Monitoring
condition-based maintenance
Disaster Management
10/10/2001
TinyOS EmSoft

4. 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

5. 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

6. Outline Emerging wireless embedded systems
Platform for exploring this space
TinyOS framework
Network-centric EmSoft experiences
10/10/2001
TinyOS EmSoft

7. Networked Sensor/Act Node
1” x 1.5” motherboard
ATMEL 4Mhz, 8bit MCU, 512 bytes RAM, 8KB pgm flash
900Mhz Radio (RF Monolithics) 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

8. Basic Power Breakdown…
Active
Idle
Sleep
CPU
5 mA
2 mA
5 μA
Radio
7 mA (TX)
4.5 mA (RX)
EE-Prom
3 mA
LED’s
4 mA
Photo Diode
200 μA
Temperature
Panasonic CR 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 cycles of computation.
Idleness is not enough, sleep!
The ratio between Active and Idle is interesting…. This has bearing on the decision to include multiple controllers in the I/O hierarchy. It is better to have a single CPU 80% active that two CPU’s
10/10/2001
TinyOS EmSoft

9. Experimenting at Scale
10/10/2001
TinyOS EmSoft

10. 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

11. 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

12. Tiny OS Concepts Scheduler + Graph of Components Component:
constrained two-level scheduling model: threads + events
Component:
Commands,
Event Handlers
Frame (storage)
Tasks (concurrency)
Constrained Storage Model
frame per component, shared stack, no heap
Very lean multithreading
Efficient Layering
msg_rec(type, data)
msg_send_done)
Commands
Events
send_msg(addr, type, data)
power(mode)
init
Messaging Component
internal thread
Internal
State
Power(mode)
TX_packet(buf)
init
TX_packet_done (success)
RX_packet_done (buffer)
10/10/2001
TinyOS EmSoft

13. Application = Graph of Components
Route map
router
sensor appln
application
Active Messages
packet
Radio Packet
Serial Packet
Temp
photo SW
Example: ad hoc, multi-hop routing of photo sensor readings
UART HW
Radio byte
byte
ADC
3450 B code
226 B data
RFM
clocks
bit
Graph of cooperating
state machines
on shared stack
10/10/2001
TinyOS EmSoft

14. TOS Execution Model commands request action events notify occurrence
ack/nack at every boundary
call cmd or post task
events notify occurrence
HW intrpt at lowest level
may signal events
call cmds
post tasks
Tasks provide logical concurrency
preempted by events
Migration of HW/SW boundary
application comp
data processing
message-event driven
active message
RFM
Radio byte
Radio Packet
bit
byte
packet
event-driven packet-pump
crc
event-driven byte-pump
encode/decode
event-driven bit-pump
10/10/2001
TinyOS EmSoft

15. TinyOS Execution Contexts
Tasks
events
commands
Interrupts
Hardware
10/10/2001
TinyOS EmSoft

16. Dynamics of Events and Threads
bit event => end of byte => end of packet => end of msg send
thread posted to start
send next message
bit event filtered at byte layer
radio takes clock events to detect recv
10/10/2001
TinyOS EmSoft

17. Quantitative Analysis...
Power down when task queue empty
Components
Packet reception work breakdown
Percent CPU Utilization
Energy (nj/Bit) AM
0.05%
0.20%
0.33
Packet
1.12%
0.51%
7.58
Radio handler
26.87%
12.16%
182.38
Radio decode thread
5.48%
2.48%
37.2
RFM
66.48%
30.08%
451.17
Radio Reception -
1350
Idle
54.75%
Total
100.00%
10/10/2001
TinyOS EmSoft

18. 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

19. 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

20. Tiny Event-Driven Active Messages
TOS_FRAME_BEGIN(INT_TO_RFM_frame) {
char pending;
TOS_Msg msg; }
TOS_FRAME_END(INT_TO_RFM_frame);
...
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;}
source buffer
handler
destinations
10/10/2001
TinyOS EmSoft

21. 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

22. 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

23. 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
appln comp
buffer handoff
active message
packet-pump
Radio Packet
byte-pump
upper fsm
Radio byte
lower fsm
bit-pump
RFM
10/10/2001
TinyOS EmSoft

24. 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
Byte 1
Byte 2
Byte 3
Byte 4
Bit transmission
start
Byte 1
Byte 2
Byte 3
RFM Bits
10/10/2001
TinyOS EmSoft

25. 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
Application-level synchronization rendezvous to determine when to sample
sleep
Xmit:
Recv:
preamble
message b
Optimal Preamble = (2/3 Sxb)1/2
10/10/2001
TinyOS EmSoft

26. 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

27. 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

28. Network Discovery: Radio Cells
10/10/2001
TinyOS EmSoft

29. Network Discovery
10/10/2001
TinyOS EmSoft

30. Self-organization has complex dynamics2b 2a 2d 1 2c
10/10/2001
TinyOS EmSoft

31. 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

32. Example: Multihop Adaptive Transmission ControlB 14 15 18 17 16
Max rate: 4 samples/sec
- rate = 4p
Channel BW ~20 p/s
- cannot expect more than 1/3 thru parent
Monitor number of children (n)
a(n) ~ 1/n b = ½
p’ = p + a(n) on success (echo)
p’ = p * b
without rate control, success drops ~½ per hop
10/10/2001
TinyOS EmSoft

33. 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

34. Summary Distribute the embedded system over many small devices
webs.cs.berkeley.edu or
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