TinyOS Software Engineering Sensor Networks for the Masses.
-
date post
21-Dec-2015 -
Category
Documents
-
view
219 -
download
2
Transcript of 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
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
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