Why a Sensor Node Needs an Operating System
Chapter Twenty-Four
Syllabus topic Module 1, "WSN Operating Systems and Ad-hoc Networks: Overview of wireless sensor network operating systems"
Pages 133 to 136 of 862
In one line
A sensor node needs an operating system to share one tiny processor among many things happening at once (sensing, receiving, forwarding, sending), to hide the hardware behind simple interfaces, and to put everything to sleep whenever possible, all within a few kilobytes of memory.
In the wording a student can write in an examination: an operating system for a WSN node manages concurrency (many flows of events on one microcontroller), provides hardware abstraction for sensors, radio and timers, handles scheduling, memory, communication, power management and reprogramming, and must do so with a tiny footprint. Its design issues are the execution model (event-driven or multithreaded), scheduling, memory management, protocol support, resource sharing, modularity, energy management, dynamic reprogramming, robustness and timing. A desktop operating system cannot be used, because a node has kilobytes of memory, no memory protection and a battery that must last months.
Why not simply program the hardware directly?
A small node could be programmed as one loop: read the sensor, send, sleep, repeat. That works for a node that does only one thing. A real node, even a simple one, does several things whose timing it does not control:
- a timer says it is time to sample;
- the ADC finishes a conversion some microseconds later;
- a packet arrives from a neighbour that must be forwarded;
- the radio reports that a send has finished, or failed;
- a new command arrives from the sink.
These are concurrent: they overlap, and any of them can happen while another is being handled. Managing them by hand in one loop quickly becomes unmanageable and wasteful. An operating system provides the structure: a way to respond to each event, to share the processor between them, to schedule deferred work, and to sleep when nothing is left to do.
What the TinyOS designers said a sensor OS must handle
The Berkeley paper that introduced TinyOS in 2000 began by setting out the "requirements that shape the design of network sensor systems". There are five, and they are still the best short answer to why is a sensor OS different?.
- Small physical size and low power consumption. Processing, storage and interconnect are "limited and scarce", so the rest of the solution "must be austere and efficient".
- Concurrency-intensive operation. The node's main job is "to flow information from place to place with a modest amount of processing on-the-fly, rather than to accept a command, stop, think, and respond". Data is captured, processed and streamed at once, or received and forwarded, with little memory to buffer between flows, and some of the events have real-time requirements.
- Limited physical parallelism and controller hierarchy. A desktop spreads work across many controllers and buses. A node has one microcontroller wired directly to its sensors and radio, so the concurrency must all be managed by that one processor.
- Diversity in design and usage. Nodes are application-specific and carry only the hardware their application needs, so the software must be modular: it must be easy to assemble "just the software components required", with very efficient interfaces between them.
- Robust operation. Nodes are numerous and unattended, and redundancy inside a device is too costly, so each device must be reliable: its components "should be as independent as possible and connected with narrow interfaces".
Why a Sensor Node Needs an Operating System
Their result was an operating system that, in the paper's words, "fits in 178 bytes of memory".
The design issues a sensor OS must settle
Each of these is a decision, and the systems of [TinyOS: Components, Tasks and the Scheduler] and [Contiki, RIOT and the Other Sensor Operating Systems] settle them differently.
| Design issue | The question | Why it is hard on a sensor node |
|---|---|---|
| Execution model | Events that run to completion, or threads that block? | Threads need a stack each; the next chapter weighs the two |
| Scheduling | Who runs next, and can a running job be interrupted? | Must be tiny and must let the node sleep as soon as work runs out |
| Memory management | Is memory allocated statically or at run time? | Kilobytes of RAM and no memory protection, so a runaway allocation corrupts everything |
| Protocol support | How are the radio, MAC and routing provided? | The protocols are part of the application's energy budget, not a fixed layer |
| Resource sharing | How do tasks share the radio, the ADC and the flash? | One of each, used by everything |
| Modularity | How is a system assembled for one application? | Only the components needed should be linked in |
| Energy management | How does the OS put the hardware to sleep? | The single most important job; idle time must become sleep time automatically |
| Reprogramming | How is new code installed in a deployed network? | Nodes cannot be collected; code must travel over the radio and should be small |
| Robustness | What happens when one component misbehaves? | No protection hardware to contain the damage |
| Timing | Can the OS meet real-time deadlines? | Some events (a radio byte, a sample) cannot wait |
Reprogramming deserves a word of its own
Contiki's authors put the case: networks of "hundreds or even thousands of nodes" must have code downloaded into them, and "bugs may have to be patched in an operational network", because "it is not feasible to physically collect and reprogram all sensor devices". Sending code costs energy, so the smaller the piece sent, the better. Most embedded systems must send a complete binary image of the whole system; Contiki's answer is to "load and unload individual applications or services at run-time", so only the changed program travels.
Why a Sensor Node Needs an Operating System
How small is small
The numbers in the two founding papers make the constraint concrete.
- Contiki's paper describes the typical device of 2004: "8-bit microcontrollers, code memory on the order of 100 kilobytes, and less than 20 kilobytes of RAM". Its own platform, the ESB, had an MSP430 with 2 kilobytes of RAM and 60 kilobytes of ROM, running at 1 MHz.
- On that platform a Contiki process's whole state was 23 bytes.
- The first TinyOS fitted in 178 bytes.
- The Telos mote of [Inside a Sensor Node: The Five Units] was generous by comparison: 10 kB of RAM.
A desktop operating system needs thousands of times more memory just to start.
Worked example: one wake-up of a relay node
A relay node in the vineyard wakes on a timer. In the next few milliseconds, all of this may happen, and the operating system is what keeps it in order.
| Time (ms) | Event | What the OS must do |
|---|---|---|
| 0 | Timer fires: time to sample | Run the timer's handler; schedule the sampling |
| 0.1 | Sampling started on the ADC | Let the processor do other work, or sleep, while the ADC converts |
| 0.4 | A neighbour's packet starts arriving | Handle the radio's interrupt at once: the bytes cannot wait |
| 0.6 | ADC conversion complete | Record the reading; schedule the packet to be built |
| 2.1 | Neighbour's packet complete | Schedule it to be forwarded |
| 2.2 | Own packet built | Hand it to the radio; queue the neighbour's packet behind it |
| 4.8 | Radio reports own packet sent | Send the neighbour's packet |
| 7.5 | Radio reports forwarded packet sent | Nothing left to do: power the radio down, put the processor to sleep |
Three things in the table are an operating system's whole job in miniature: the radio's interrupt at 0.4 ms could not wait for the sampling to finish, so the OS must let urgent events interrupt; the ADC and the radio worked while the processor did other things, so the OS must let operations start and finish later; and at 7.5 ms the node went back to sleep because the OS knew nothing else was pending.
Distinctions
| Desktop operating system | Sensor node operating system | |
|---|---|---|
| Memory | Gigabytes, protected, virtual | Kilobytes, unprotected, physical |
| Main concern | Throughput and responsiveness for users | Energy, concurrency and footprint |
| Processes | Many, isolated from each other | A few components or processes in one address space |
| Idle time | Wasted | Converted into sleep |
| Updating software | Install a package | Send code over the radio to thousands of nodes |
What it does not mean
A sensor OS is not a small Linux. It usually has no memory protection, no file system in the usual sense and no users, and it is organised around events and energy.
Why a Sensor Node Needs an Operating System
"178 bytes" is not the size of a whole application. It is the core of the 2000 TinyOS; applications and their components add to it.
An operating system does not make the node faster. It makes it organised and economical: it lets many slow things overlap and sleeps in the gaps.
Quick revision
- A sensor OS manages concurrency, hardware abstraction, scheduling, memory, communication, power and reprogramming, in a tiny footprint.
- TinyOS's five requirements (2000): small size and low power; concurrency-intensive operation; limited physical parallelism and controller hierarchy; diversity in design and usage (modularity); robust operation. First TinyOS: 178 bytes.
- Design issues: execution model, scheduling, memory management, protocol support, resource sharing, modularity, energy management, reprogramming, robustness, timing.
- Typical 2004 node (Contiki paper): 8-bit MCU, about 100 kB code, under 20 kB RAM; ESB: 2 kB RAM, 60 kB ROM, 1 MHz; a Contiki process state: 23 bytes.
- Reprogramming over the radio must send as little code as possible; Contiki loads individual programs at run time.
Test yourself
1. Why does a sensor node need an operating system? Because even a simple node handles several concurrent activities (timers, sensor conversions, arriving and departing packets, commands) on one small processor. The OS provides a structure to respond to events, share the processor, defer work, abstract the hardware, manage energy by sleeping whenever possible, and support reprogramming, within a few kilobytes.
2. State the five requirements the TinyOS designers identified for networked sensors. Small physical size and low power consumption; concurrency-intensive operation; limited physical parallelism and controller hierarchy; diversity in design and usage, requiring efficient modularity; robust operation of numerous unattended devices.
3. List the design issues of a WSN operating system. Execution model, scheduling, memory management, communication protocol support, resource sharing, modularity, energy management, dynamic reprogramming, robustness, and meeting timing requirements.
4. Why is dynamic reprogramming important, and how does Contiki make it cheaper? Deployed networks have hundreds or thousands of nodes that cannot be collected, and bugs must be fixed in the field, so code must be sent over the radio, which costs energy. Contiki loads and unloads individual programs at run time, so only the changed program is sent rather than a whole system image.
5. In the relay node's wake-up, what three things did the OS have to make possible? Letting an urgent event (the radio interrupt) interrupt other work; letting slow operations (the ADC conversion, the radio send) start and finish later while the processor did other things; and putting the node to sleep as soon as nothing was pending.
The rest of this subject
These notes are cut from the University's printed syllabus. Open the syllabus itself for the same subject.