Overview of: System Architecture Directions for Networked Sensors John Kerwin CSE 291 Sensor Networks Paper by: Jason Hill, Robert Szewczyk, Alec Woo, Seth Hollar, David Culler, Kris Pister

Motivation Sensor networks are new computing environments in the post-PC era that are different from traditional desktop and server environments. There are several trends working together to enable the networked sensor: Moore’s Law System on a chip Micro-electromechanical sensors (MEMS) Integrated low power communication

Motivation (cont) Today, sensors exist on the scale of a square inch in size, and a fraction of a watt in power. In the future, it may be possible to reduce sensors to the size of a cubic millimeter, or smaller. The key missing technology for these devices is system software to manage and operate them efficiently.

Project Objectives Create a prototype of a current generation sensor constructed from off the shelf components. Identify key requirements that an operating system for such a sensor must satisfy. Build an operating system that meets these requirements. Evaluate the operating system’s performance while running a real application.

Today’s Hardware Assembled from off-the-shelf components 4Mhz, 8bit MCU (ATMEL) 512 bytes RAM, 8KB ROM 900Mhz Radio (RF Monolithics) ft. range Temperature Sensor & Light Sensor LED outputs Serial Port 1.5” x 1.5” Slide courtesy Jason Hill et al

Hardware Features 3 Sleep Modes that can shut off the processor and other components not required for wake up. Radio can transfer data at up to 19 Kbps, with no data buffering. Sensor consumes about 19.5 mA at peak load, and 10 μA when inactive. A 575 mAh battery can power a sensor for 30 hours at peak load, or for over a year when inactive. Image courtesy Jason Hill et al

Operating System Requirements Small physical size and low power consumption Devices have limited memory and power resources Concurrency intensive operation Need to be able to service packets on-the-fly in real-time Limited hardware parallelism and controller hierarchy Limited number, and capability of controllers Unsophisticated processor-memory-switch level interconnect Diversity in design and usage Provide a high degree of software modularity for application specific sensors Robust Operation OS should be reliable, and assist applications in surviving individual device failures

The Solution: TinyOS A microthreaded OS that draws on previous work done for lightweight thread support, and efficient network interfaces Two level scheduling structure Long running tasks that can be interrupted by hardware events Small, tightly integrated design that allows crossover of software components into hardware

TinyOS Component Model Component has: Frame (storage) Tasks (computation) Command and Event Interface Messaging Component Internal State Internal Tasks CommandsEvents Image courtesy Jason Hill et al To facilitate modularity, each component declares the commands it uses and the events it signals. Statically allocated, fixed sized frames allow us to know the memory requirements of a component at compile time, and avoid the overhead associated with dynamic allocation.

Tasks Perform the primary computation work Atomic with respect to other tasks, and run to completion, but can be preempted by events Allow the OS to allocate a single stack assigned to the currently executing task Call lower level commands Signal higher level events Schedule other tasks within a component Simulate concurrency using events

Commands Non-blocking requests to lower level components Deposit request parameters into a component’s frame, and post a task for later execution Can also invoke lower level commands, but cannot block To avoid cycles, commands cannot signal events Return status to the caller

Events Event handlers deal with hardware events (interrupts) directly or indirectly Deposit information into a frame Post tasks Signal higher level events Call lower level commands

TOS Component Messaging Component AM_SUB_INIT AM_SUB_POWER AM_SUB_TX_PACKET AM_TX_PACKET _DONE AM_RX_PACKET _DONE Internal State AM_INIT AM_POWER AM_SEND_MSG AM_MSG_REC AM_MSG_SEND_DONE Internal Tasks CommandsEvents //AM.comp// TOS_MODULE AM; ACCEPTS{ char AM_SEND_MSG(char addr, char type, char* data); void AM_POWER(char mode); char 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 AM_SUB_TX_PACKET(char* data); void AM_SUB_POWER(char mode); char AM_SUB_INIT(); }; Slide courtesy Jason Hill et al

Putting It All Together The task scheduler is a simple FIFO scheduler. The scheduler puts the processor to sleep when the task queue is empty. Peripherals keep operating and can wake up the processor. Communication across components takes the form of a function call. This results in low overhead, and allows compile time type checking.

Sample Application The authors built an application consisting of a number of sensors distributed within a localized area Monitor temperature and light conditions Periodically transmit measurements to a base station

Sample Application (cont) Sensors can forward data for other sensors that are out of range of the base station Dynamically determine the correct routing topology for the network Image courtesy Jason Hill et al

Internal Component Graph Slide courtesy Jason Hill et al RFM Radio byte Radio Packet UART Serial Packet I2C Temp Photo Active Messages Clocks bit byte packet Ad hoc Routing Application application HW SW

Ad hoc Routing 0 Base Base station periodically broadcasts route updates Any sensors in range of this broadcast record the identity of the base station, and rebroadcast the update Each sensor remembers the first update received in an era, and uses the source of the update as the destination for routing data back to the base station Image courtesy Jason Hill et al

Evaluation: Small Physical Size Component NameCode Size (bytes) Data Size (bytes) Multihop router AM_dispatch AM_temperature AM_light AM Packet RADIO_byte RFM Photo Temperature UART UART_packet I2C_bus Processor_init TinyOS scheduler C runtime Total Scheduler only occupies 178 bytes Complete application only requires 3 KB of instruction memory and 226 bytes of data (less than 50% of the 512 bytes available) Only processor_init, TinyOS scheduler, and C runtime are required

Evaluation: Concurrency Intensive Operations OperationsCost (cycles) Time (µs) Normalized to byte copy Byte copy821 Post an Event Call a Command Post a task to scheduler Context switch overhead Interrupt (hardware cost) Interrupt (software cost) Low overhead is essential for achieving modular efficiency Cost of posting an event = cost of copying 1 byte of data Cost of posting a task or context switching is the same as copying 6 bytes of data Interrupt handling requires saving and storing registers

Efficient Modularity Message Send Transition Total propagation delay up the 5 layer radio communication stack is about 80 instructions Timing diagram of event propagation Slide courtesy Jason Hill et al

Evaluation: Limited Hardware Parallelism and Controller Hierarchy Successfully demonstrated a system with multiple flows of data running through a single microcontroller Components Packet reception work breakdownCPU UtilizationEnergy (nj/Bit) AM 0.05%0.20%0.33 Packet 1.12%0.51%7.58 Radio 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 % Slide courtesy Jason Hill et al

Evaluation: Diversity in Usage and Robust Operation Created several sample applications that exploit the modular structure of the system Source based multi-hop routing applications Active-badge-like location detection applications Sensor network monitoring applications C programming language allows the ability to target multiple CPU architectures in future systems Robustness: Multihop routing application automatically reconfigures itself to withstand individual node failures Slide courtesy Jason Hill et al

Conclusions TinyOS is a highly modular software environment tailored to the requirements of Network Sensors, stressing efficiency, modularity, and concurrency. TinyOS should be able to support new sensor devices as they evolve. Running an application on TinyOS can help reveal the impact of architectural changes in the underlying hardware, making it easier to design hardware that is optimized for a particular application.