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

BYTE_DONE

SEND_BYTE

PACKET_DONE

CRCPACKETOBJ SEC_DEDAM

SEND_PACKET SEND_BYTE