A summary of: System Architecture Directions for Networked Sensors

 

A summary of:

System Architecture Directions for Networked Sensors

Jason Hill, Robert Szewczyk, Alec Woo, Seth Hollar, David Culler, Kristofer Pister

April 27, 2000

This paper represents a design of a tiny event-driven operating system , which is called TinyOS to address the problem of manage and operate small devices and sensors. The motivation of this idea is that because of the sensor networks are new kind of computing environments in the post-PC era which are different from traditional desktop and server environments. There are several trends working together to enable the network sensors, system on a chip, micro-electrom echanical sensors(MEMS) and integrated low power communication. Today , sensors exist on the scale of a square inch in size, and a fraction of a watt in power. Furthermore, in the future, it may be possible to reduce sensors to the size of a cubic millimeter, or smaller. So the key missing technology for these devices is a kind of system software to manage and operate them efficiently.

   The objectives of this project is to create a prototype of a current generation sensor constructed from off the shelf components. And identify key requirements that an operating system for such a sensor must satisfy. Building an operating system that meets these requirements. Last, evaluate the operating system's performance while running a real application. First , it is about the hardware features of the device. It has 3 kind of sleep modes which can shut off the processor and other components which are not required for wake up. The radio of the device can transfer data at up to 19Kbps, with no data buffering. The sensor consumes about 19.5 mA at peak load, and 10 uA when inactive. A 575 mAh battery can power a sensor for 30 hours at peak load, or for over a year when inactive. They mentioned some requirements for the operating system. Because of the small physical size and low power consumption, the devices have limited memory and power resources. It should concurrency intensive operation , that means it needs to be able to service packets on-the-fly in real-time. In terms of the limited hardware parallelism and controller hierarchy , it has limited number and capability of controllers , and unsophisticated processor-memory-switch level interconnect. In order to satisfy the diversity in design and usage, it should provide a high degree of software modularity for application specific sensors. And of course , it needs a robust operation , the OS should be reliable, and assist applications in surviving individual device failures.

In order to satisfy the hardware requirements , they address the problem by design an OS called TinyOS. It is a microthreaded OS that draws on previous work done for lightweight tread support, and efficient network interfaces. It has two level scheduling structure. So that long running tasks can be interrupted by hardware events. Small , tightly integrated design that allows crossover of software components into hardware. The component of TinyOS has three basic things , frame to serve as storage, tasks for the computation and command & event interface. 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. The tasks of the TinyOS is performed as the primary computation work, atomic with respect to other tasks, and run to completion, but can be preempted by events. It allows the OS to allocate a single stack assigned to the currently executing task. It has lower level commands , signal higher level events, can schedule other tasks within a component and simulate concurrency using events. The commands of the operation system is non-blocking requests to lower level components. The commands deposit request parameters into a component's frame and post a task for later execution. It can also invoke lower level commands, but cannot block it. In order to avoid cycles, commands cannot signal events. It also returns status to the caller. About the events, the event handlers deal with hardware events (interrupts) directly or indirectly. They deposit information into a frame as well. Post tasks, signal higher level events and call lower level commands. In order to examine the composition and interaction within a complete configuration , they develop a network sensor application consist of a number of sensors distributed within a localized area, monitor temperature and light conditions and periodically transmit measurements to a base station. The task scheduler of it is a simple FIFO scheduler. The scheduler puts the processor to sleep when the task queue is empty. The 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. The sensors can forward data for other sensors that are out of range of the base station, it can dynamically determine the correct routing topology for the network. The 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. Finally , they give an evaluation by the given data to evaluate the system concurrency intensive operations , modularity and robust ,etc.

In conclude, 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.