Sensor OS

Required reading: TinyOS


The paper's argument is that because sensor devices are resource constrained, and always will be, particular attention should be paid to the design of the operating system. The resource constraints for a single sensor are:

There are other constraints such bandwidth consumption etc., but the design of new network protocols falls outside of the scope of this paper.

How real are these constraints? In ten years does a sensor contain an ARM processor with 128 Kbytes of RAM running with low power consumption? Such a hardware environment would be good enough to boot v6. But, perhaps a sensor that cannot boot v6 might be smaller and less expensive.

A second argument in the paper is that conventional operating systems (e.g., v6) are not suitable for sensors, because sensors are devices that are data-oriented instead of computation-oriented (as desktops are). Sensors collect data from their enviroment (or other sensors), do some processing, and forward it. Data comes in from multiple sources with limited amount of buffering, resulting potentionally in rapid context switching.

A third argument in the paper is that conventional operating systems are too complex, and a simple, highly-modular operating system is needed for sensors. Simple so that the system is robust. Highly-modular so that the operating system can be configured easily for different sensors.

Case study: Sensor and TinyOS


It is important to switch components off to save energy (see Table 1).

Tiny OS. Consist of a collection of components. Each component has:

An example: the messaging component:

  • An example application: it collects sensor data (temparature) and sends it (see figure 3). Here is the calling graph in terms of tasks and functions. The scheduler calls the tasks. The scheduler runs after an interrupt or task completes:

    It is unclear radio generates interrupt when transmission completes or if clock interrupt checks for transmission completion. It appears to be the clock because in figure 1 there is no wire for transmission-completion interrupts.

    How is coordination enforced? To first order, the application programmer is responsible that coordination is correct (in terms of handlers and tasks not interfering). It appears that the only device that generates interrupts is the clock, which polls devices. (The RX wire is there only to put the processor into active mode when it sleeps and a bit arrives.) The components presumably also perform coordination: for example, the message component probably doesn't send another message until the first one has been sent. all works out.

    Paper discussion