A Network-Centric Approach to Embedded Software for Tiny Devices

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

2. Processing Storage Sensing Actuation Communication I SD Q SD baseband PLL filters mixer LNA A new EMSOFT paradigm is emerging • Complete embedded systems going microscopic TinyOS EmSoft

3. Disaster Management Circulatory Net Habitat Monitoring condition-based maintenance A new EMSOFT paradigm is emerging • Complete embedded systems going microscopic • Embedded software is blown across the physical space 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 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 TinyOS EmSoft

6. Outline • Emerging wireless embedded systems • Platform for exploring this space • TinyOS framework • Network-centric EmSoft experiences 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) 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 TinyOS EmSoft

8. Panasonic CR2354 560 mAh Basic Power Breakdown… • 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! TinyOS EmSoft

9. Experimenting at Scale 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! 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 TinyOS EmSoft

12. msg_rec(type, data) msg_send_done) Tiny OS Concepts • Scheduler + Graph of Components • 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 Events Commands send_msg(addr, type, data) power(mode) init Messaging Component internal thread Internal State TX_packet(buf) Power(mode) TX_packet_done (success) init RX_packet_done (buffer) TinyOS EmSoft

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

14. Radio Packet packet Radio byte byte RFM bit TOS Execution Model • commands request action • 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 data processing application comp message-event driven active message event-driven packet-pump crc event-driven byte-pump encode/decode event-driven bit-pump TinyOS EmSoft

15. TinyOS Execution Contexts Tasks events commands Interrupts Hardware 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 TinyOS EmSoft

17. 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% 100.00% 2028.66 Quantitative Analysis... Power down when task queue empty 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 TinyOS EmSoft

19. Typical split-phase pattern • clock event handler initiates data collection • sensor signals data ready event • data event handler posts task to process data 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;} TinyOS EmSoft

20. source buffer destinations handler 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;} 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 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 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 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 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 preamble message Xmit: Recv: b Optimal Preamble = (2/3 Sxb)1/2 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. 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 TinyOS EmSoft

28. Network Discovery: Radio Cells TinyOS EmSoft

29. Network Discovery TinyOS EmSoft

30. Self-organization has complex dynamics 2e 2b 2a 2d 1 0 2c 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 TinyOS EmSoft

32. 18 15 17 16 14 B Example: Multihop Adaptive Transmission Control 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 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 TinyOS EmSoft

34. 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 TinyOS EmSoft