Tiny OS Software Engineering Sensor Networks for the

Tiny. OS Software Engineering Sensor Networks for the Masses

Outline • • • Software engineering in sensor networks Characteristics of Tiny. OS TOSSIM and TOSSER Systems in development Future Ideas Conclusion

Sensor Network Domain • • • Wide range of users Highly distributed algorithms Limited resources Individual motes have minimal I/O Combination of usually separate difficulties

Sensor Network Domain • • • Wide range of users Highly distributed algorithms Limited resources Individual motes have minimal I/O Combination of usually separate difficulties

Highly Distributed Algorithms • Individual motes have limited computational capability – Efficient algorithms require distributed processing over a network of motes • Inter-mote concurrency • Hard to write and debug • Unable to inspect mote state

Characteristics of Tiny. OS • Abstractions: frames, commands, events, tasks • Event-based non-blocking design • Intra-mote concurrency • Single stack • User code handles interrupts (e. g. ADC)

TOSSIM • • Tiny. OS mote execution simulator Scalable to one thousand motes Compiles directly from Tiny. OS source Allows use of traditional tools (e. g. gdb) • Extensible radio, ADC and spatial models • External interface to network (monitor traffic, inject packets)

TOSSIM Benefits • One can debug implementations, not just algorithms • Bit-level radio simulation requires modifications to only one component • Complexity of real-world simulation (e. g. radio) configurable by user • Debug inter-mote and intra-mote concurrency

TOSSIM: Inter-mote Concurrency • Implement distributed algorithm • Run in TOSSIM, examine algorithm component state as messages propagate • Discover and fix bugs • Implement noisy radio model, see how algorithm holds up

Bug Example: Intra-mote concurrency Experimental Radio Stack AM MAC, packet detection CRCPACKETOBJ MAC SEC_DED RADIO_STATE RADIO Addressing Packet, CRC Data encoding/decoding FSM, event demux Radio bits, timing

New Radio Stack Bug • Packets sent in PACKET_DONE event handler would usually (95% of the time) not be heard by other motes • These packets heard with old radio stack • Quick simulator output result: packets sent in handler don’t go through MAC component (no backoff, start symbol, etc. )

Bug: Implicit State Transition • CRCPACKETOBJ signaled PACKET_DONE when it received BYTE_DONE event after last byte has been sent to SEC_DED • Problem: SEC_DED has a two byte pipeline • Sending a new packet before SEC_DED thinks it’s done appends the new data (not sent in a new packet) • Fix: Signal packet done when SEC_DED signals its byte queue is empty

TOSSER • Developed with Emil Ong (not here) • Visual programming environment • Displays component graph as a circuit – Components are chips – Links are wires • Hooks up to TOSSIM for visual simulation • Different view of program source – Finding some bugs becomes trivial

TOSSER Screenshot

Systems in Development • Tiny. OS component graph validation – Commands cannot signal events • Asynchronous vs. synchronous events – Defining the task boundary

Adding Qualifiers to Functions (cqual from Berkeley) • Specify a qualifier lattice • Annotate functions • Check qualifier propagation char sync_event() $sevent { return async_event(); } char async_event() $aevent { return $command_two(); } char command_one() $command { return sync_event(); } char command_two() $command { return 0; } $command $aevent $sevent $aevent < $command $sevent < $command

Future Work • Real-time requirement warnings – Interfacing with AVR studio – Instruction counts • Debugging motes as threads – Is this a good idea? • Building efficient abstractions – Traditional design patterns too heavyweight – Timers vs. clocks – ILP in radio stack for power conservation

Conclusions • Tiny. OS domain is distinct from traditional software engineering • For Tiny. OS to be widely used, it must be easy to use • Reducing programming complexity and providing tools is necessary

Questions

Extra Slides

Sensor Network Users • Small number of knowledgeable hackers – Systems work: protocols, services, power • Large number of novice users – Developing applications: animal behavior logging, agricultural information collection, workspace monitoring – Weak programming and debugging skills

Mote I/O • Network and physical indicators (e. g. LEDs) • Difficult to inspect mote state – Can’t hook every mote up to a PC • What if the bug is in the radio stack?

Limited Resources • • Weak processors (4 MHz) Small amounts of RAM (4 KB) Low network bandwidth (10 -50 Kb) Radio start symbol detection: 80% CPU utilization • Traditional layer of abstraction approach currently unfeasible

Radio Bug Visualized AM CRCPACKETOBJ SEND_BYTE_DONE PACKET_DONE SEND_PACKET SEND_BYTE SEC_DED