Language Challenges inspired by Networks of Tiny Devices

1. Language Challenges inspired by Networks of Tiny Devices David Culler Computer Science Division U.C. Berkeley Intel Research @ Berkeley www.cs.berkeley.edu/~culler

2. Challenges 6-pack • Optimizing for efficient modularity • Analysis for jitter bounds and other system properties • Whole Program code generations for network capsules • Analysis for verification of system invariants • Programming environments for event-driven execution • Programming language for unstructured aggregates MRL Systems

3. Outline • Motivating networked sensor regime • TinyOS structure • Discussion of 5 challenges MRL Systems

4. Low-power Wireless Communication I SD Q SD baseband PLL filters mixer LNA Emerging Microscopic Devices • CMOS trend is not just Moore’s law • Micro Electical Mechanical Systems (MEMS) • rich array of sensors are becoming cheap and tiny • Imagine, all sorts of chips that are connected to the physical world and to cyberspace! MRL Systems

5. Circulatory Net What can you do with them? Disaster Management • Embed many distributed devices to monitor and interact with physical world • Network these devices so that they can coordinate to perform higher-level tasks. => Requires robust distributed systems of hundreds or thousands of devices. Habitat Monitoring Condition-based maintenance MRL Systems

6. Getting started in the small • 1” x 1.5” motherboard • ATMEL 4Mhz, 8bit MCU, 512 bytes RAM, 8K pgm flash • 900Mhz Radio (RF Monolithics) 10-100 ft. range • ATMEL network pgming assist • Radio Signal strength control and sensing • I2C EPROM (logging) • Base-station ready (UART) • stackable expansion connector • all ports, i2c, pwr, clock… • Several sensor boards • basic protoboard • tiny weather station (temp,light,hum,prs) • vibrations (2d acc, temp, light) • accelerometers, magnetometers, • current, acoustics MRL Systems

7. A Operating System for Tiny Devices? • 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 MRL Systems

8. 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) MRL Systems

9. Appln = graph of event-driven components Route map router sensor appln application Active Messages Serial Packet Radio Packet packet Temp photo SW HW UART Radio byte ADC byte Example: ad hoc, multi-hop routing of photo sensor readings clocks RFM bit MRL Systems

10. 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... 3450 B code 226 B data MRL Systems

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

12. 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 MRL Systems

13. Event-Driven Sensor Access Pattern char TOS_EVENT(SENS_OUTPUT_CLOCK_EVENT)(){ return TOS_CALL_COMMAND(SENS_GET_DATA)(); } char TOS_EVENT(SENS_DATA_READY)(int data){ return TOS_CALL_COMMAND(SENS_OUTPUT_OUTPUT)((data >> 2) &0x7); } • clock event handler initiates data collection • sensor signals data ready event • data event handler calls output command • common pattern MRL Systems

14. Tiny Active Messages TOS_FRAME_BEGIN(INT_TO_RFM_frame) { char pending; TOS_Msg msg; } TOS_FRAME_END(INT_TO_RFM_frame); ...TOS_COMMAND(SUB_SEND_MSG)(TOS_MSG_BCAST, AM_MSG(INT_READING), &VAR(msg))) ... char TOS_EVENT(SUB_MSG_SEND_DONE)( TOS_MsgPtr sentBuffer){ ...} TOS_MsgPtr TOS_MSG_EVENT(INT_READING)(TOS_MsgPtr val){ ... return val; } • Sending • Declare buffer storage in a frame • Request Transmission • Naming a handler • Handle Completion signal • Receiving • Declare a handler • Firing a handler • automatic • behaves like any other event • Buffer management • strict ownership exchange • tx: done event => reuse • rx: must rtn a buffer MRL Systems

15. TinyOS Execution Contexts Tasks events commands Interrupts Hardware MRL Systems

16. Typical application use of tasks • event driven data acquisition • schedule task to do computational portion char TOS_EVENT(MAGS_DATA_EVENT)(int data){ struct adc_packet* pack = (struct adc_packet*)(VAR(msg).data); printf("data_event\n"); VAR(reading) = data; TOS_POST_TASK(FILTER_DATA); ... • 128 Hz sampling rate • simple FIR filter • dynamic software tuning for centering the magnetometer signal (1208 bytes) • digital control of analog, not DSP • ADC (196 bytes) MRL Systems

17. Tasks in low-level operation • transmit packet • send command schedules task to calculate CRC • task initiated byte-level datapump • events keep the pump flowing • receive packet • receive event schedules task to check CRC • task signals packet ready if OK • byte-level tx/rx • task scheduled to encode/decode each complete byte • must take less time that byte data transfer • i2c component • i2c bus has long suspensive operations • tasks used to create split-phase interface • events can procede during bus transactions MRL Systems

18. Example: Radio Byte Operation • 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 MRL Systems

19. Task Scheduling • Currently simple fifo scheduler • Bounded number of pending tasks • When idle, shuts down node except clock • Uses non-blocking task queue data structure MRL Systems

20. DARPA-esq demo • UAV drops nodes along road, • hot-water pipe insulation for package • Nodes self configure into linear network • 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! MRL Systems

21. Re-exploring networking • Fundamentally new aspects in each level • encoding, framing, error handling • media access control • transmission rate control • discovery, multihop routing • broadcast, multicast, aggregation • active network capsules (reprogramming) • security, network-wide protection • New trade-offs across traditional abstractions • density independent wake-up • proximity estimation • localization, time synchronization • New kind of distributed/parallel processing MRL Systems

22. 6 Challenges • Optimizing for efficient modularity • narrow interfaces for robustness • components for application specific composition • encapsulated state and concurrency • creation distinct from composition • without sacrificing code generation • optimize for energy • Analysis for jitter bounds and other system properties • need to get back to the radio bit layer every 50 us +- 10 • many paths through potential higher level activities • tasks preemptible by events • can you make guarantees about all paths MRL Systems

23. Challenge 6-pack • Whole Program code generation for network capsules • compile away module boundaries and indirection for efficiency • incremental update of a few components is common • compute the change in the infrastructure and update capsules • append-only flash adds to challenge • Analysis for verification of system invariants • Dawson Engler has shown big wins for Flash magic, linux, ... • system designers formulate invariants, specialized analysis routines check MRL Systems

24. 6-pack continued • Programming environments for event-driven execution • high concurrency, in lots of places at once • relationship between FSMs important • visualization is key • Programming language for unstructured aggregates • currently program message protocol for each node • infer global behavior from local function • design to specify the global behavior • build on data parallel, SPMD, scan operations, set languages MRL Systems

25. To learn more • http://www.cs.berkeley.edu/~culler • http://tinyos.millennium.berkeley.edu/ • http://webs.cs.berkeley.edu/ MRL Systems

26. ...and Small Characteristics of the Large • Concurrency intensive • data streams and real-time events, not command-response • Communications-centric • Limited resources (relative to load) • Huge variation in load • Robustness (despite unpredictable change) • Hands-off (no UI) • Dynamic configuration, discovery • Self-organized and reactive control • Similar execution model (component-based events) • Complimentary roles (eyes/ears of the grid) • Huge space of open problems MRL Systems