1 / 24

TinyOS Software Engineering

Explore the characteristics of TinyOS, TOSSIM, and TOSSER in the context of software engineering in sensor networks. Learn about the challenges and future ideas for sensor network development.

judev
Download Presentation

TinyOS Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TinyOS Software Engineering Sensor Networks for the Masses

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

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

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

  5. 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

  6. 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)

  7. 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)

  8. 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

  9. 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

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

  11. 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.)

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

  13. 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

  14. TOSSER Screenshot

  15. Systems in Development • TinyOS component graph validation • Commands cannot signal events • Asynchronous vs. synchronous events • Defining the task boundary

  16. 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

  17. 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

  18. 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

  19. Questions

  20. Extra Slides

  21. 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

  22. 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?

  23. 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

  24. Radio Bug Visualized AM CRCPACKETOBJ SEC_DED SEND_BYTE BYTE_DONE SEND_BYTE BYTE_DONE PACKET_DONE SEND_PACKET SEND_BYTE

More Related