Jason Hill, Robert Szewczyk, Alec Woo Spring 2000 TinyOS Operating System for Networked Sensors Networked SensorsSystem Structure Composing Components Implement and investigate an event-based Operating Environment for a wireless network of deeply embedded sensors. The Problem: –Limited computational ability & energy supply –High levels of concurrency required –Limited physical parallelism –Diversity in design and usage –Robust operation is required The Study Analysis Sample Application & Future Work We leverage aspects of an event based programming model and component based object model to: –Support composition of diverse applications –Provide a natural paradigm for supporting interaction with the physical world –Minimize dynamic memory resources required What is a Networked Sensor? –Small (I.e. 2”x2” and smaller) –Onboard processor and communication device (e.g IR, Radio) –Self-contained power source (e.g. Battery, Solar) Mote (‘mOt) noun : a small particle –A sub-device with attached sensor(s). Autonomous Sensor Node. Our Example Networked Sensor –ATMEL 8535 Microcontroller (4Mhz, 512B SRAM, 8KB Flash) –Communication: RF (916.5 MHz), 10Kbps raw –Sensors: Light, Temperature –Features: Wireless reprogramming, 3 LEDs –Has the ability to be re-programmed wirelessly Software Footprint –3.4KBytes for complete sensing & communication application Power consumption (sleep & idle states) –Transmission cost 1uj per bit –Inactive state ~ 5  A –Peak Load ~ 19.5mA Efficient Concurrency support –Even during periods of active communication with bit-level processing, CPU is sleeping 50+% of the time. Efficient Modularity –Event can propagate through our entire communication stack in under 40  s. Route discovery application: –Nearest neighbor with a single, static root (the base station mote) –Each mote broadcasts a beacon every 1 second –Neighbor mote responds if it knows how to get to base station –Beacons propagate to base-station/host Use CAD tools to compose –Each component is created with a CAD symbol specifying the names of commands and events used and handled by the component –Schematic drawings are used to “link together” components –Structural VHDL is exported and used at compile time –Internally, components only refer to the interfaces described in their declaration (IE: refer to their own pins) Example: –If the application depicted on the left wanted to use a different messaging component, the author would use the schematic editor to replace the messaging component with the desired one, export VHDL and recompile. This would automatically re-target events and command of neighboring components to the new component as well as target its commands and events. We demonstrate –A compact system with highly efficient resource utilization –An efficient mechanism for achieving modularity –The support of concurrency intensive operations –A rich set of applications enabled by our architecture Future Work –Provide additional communication interfaces (more complex MAC layers or messaging protocols) –Dynamic uploading of handler functions. –Comparison with other models –Extension to multiple hardware platforms Screen Shot of Routing Application Designed to be: –Embedded throughout the environment –Low Cost –Non-obtrusive –Un-attended or Un-managed –Dynamically reprogrammed System image consists of scheduler and a graph of components “Higher-level” components issue commands to and respond to events from “Lower-level” components Components contain: Set of command handlers, Set of event handlers, A fixed size storage frame, Collection of simple threads which can be scheduled Commands and Events are non-blocking requests or signals Threads perform primary work, run to completion, and are atomic with respect to each other Two level scheduling system allows events to preempt threads Messaging Component init Power(mode) TX_packet(buf) TX_packet_done (success) RX_packet_done (buffer) Internal State init power(mode) send_msg(addr, type, data) msg_rec(type, data) msg_send_done (success) send_msg_thread Example Component /* Messaging Component Declaration */ //ACCEPTS: char TOS_COMMAND(AM_SEND_MSG)(char addr,char type, char* data); void TOS_COMMAND(AM_POWER)(char mode); char TOS_COMMAND(AM_INIT)(); //SIGNALS: char AM_MSG_REC(char type, char* data); char AM_MSG_SEND_DONE(char success); //HANDLES: char AM_TX_PACKET_DONE(char success); char AM_RX_PACKET_DONE(char* packet); //USES: char TOS_COMMAND(AM_SUB_TX_PACKET)(char* data); void TOS_COMMAND(AM_SUB_POWER)(char mode); char TOS_COMMAND(AM_SUB_INIT)(); Timing diagram of event propagation Components Packet reception work breakdown Percent CPU UtilizationEnergy (nj/Bit) AM 0.05%0.20%0.33 Packet 1.12%0.51%7.58 Ratio handler 26.87%12.16% Radio decode thread 5.48%2.48%37.2 RFM 66.48%30.08% Radio Reception Idle-54.75%- Total %