TinyOS Software Engineering Sensor Networks for the Masses

Outline Software engineering in sensor networks Characteristics of TinyOS 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 TinyOS Abstractions: frames, commands, events, tasks Event-based non-blocking design Intra-mote concurrency Single stack User code handles interrupts (e.g. ADC)

TOSSIM TinyOS mote execution simulator Scalable to one thousand motes Compiles directly from TinyOS 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 RADIO RADIO_STATE SEC_DEDMAC CRCPACKETOBJ AM Addressing Packet, CRC Data encoding/decoding FSM, event demux Radio bits, timing MAC, packet detection Experimental Radio Stack

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 TinyOS 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 $command $aevent $sevent $aevent < $command $sevent < $command 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; }

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 TinyOS domain is distinct from traditional software engineering For TinyOS 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 SEND_BYTE BYTE_DONE SEND_BYTE PACKET_DONE CRCPACKETOBJSEC_DEDAM SEND_PACKETSEND_BYTE