Fakultät Informatik – Institut für Systemarchitektur – Professur Rechnernetze

Runtime Environments in

Wireless Sensor Networks

Waltenegus Dargie

Technical University of Dresden, Germany

What is an Operating System (OS or O/S)?

• OS is a software component in computer systems

• OS controls resources of the computer system

– Allocation of memory for processes

– power management

• OS coordinates activities in the computer system

– which process uses the CPU

– when I/O takes place


What is an Operating System (OS or O/S)?

• Application programs run on top of OS Services

• Many criteria to classify OS

– Design goal: general purpose

vs OS for specific purposes

– Target platforms: imitation

of resources, reliability guarantees


General purpose OS

• Design principles and Concepts

• Execution model

• Memory management

• Multitasking and concurrency

• Support for File systems

• Safety and Security Features

• GUI, I/O System, Portability

• Device Drivers and OS Networking


OS for WSN. Why specific OS for WSN?

• Nodes are designed to operate with limited resources

– Power: WSN use batteries as a power supply

– Memory and operational capabilities: sensing is less

resource demanding than computation in conventional


• Sensor networks are often designed for reliable real-

time services

– Additional limitation towards some characteristics of

conventional OS



• Power management in WSN OS is very important

• Variety of solutions for WSN

– Several WSN OS: TinyOS, Contiki, SOS etc.

– Several Simulator tools: NS-2, TOSSIM etc.

– Several programming languages: C, nesC etc.

• TinyOS and Contiki: the most popular WSN OS


TinyOS (TOS) Design Principles

• TinyOS is designed to address four essential


– Limited resources

– Reactive concurrency

– Flexibility

– Low power


TinyOS Concepts

• TinyOS program is a graph of components

• Components are independent computational units

– Modules or configurations

– Set of services, specified by interfaces

– Three abstractions: commands, events, tasks

• Interfaces are used to wire components

– Contain commands and events


• Run-to-completion tasks

TinyOS Execution model

– Non-preemptive, p FIFO scheduling policy

– Tasks are atomic with respect to each other

• Interrupt handlers

– Tasks are not atomic with respect to interrupt handlers

or to commands and events, they invoke

– Race conditions are possible

• Split phase operation

– provides the non-blocking property


TinyOS Concurrency

• Event-driven concurrency model in TinyOS

– Concurrency: events and tasks (no races)

– Only events can trigger interrupts

– No multithreaded concurrency

• Synchronous (SC) and asynchronous code (AC)

– AC reachable from at least one interrupt handler

– SC only reachable from tasks

– Deal with possible race conditions

• Split-phase operation principle

– Allows high concurrency with low overhead


TinyOS Memory management

• Static memory allocation only

• No heap, no function pointers, no virtual memory

– global and local variables

• No memory protection

– No safe programming

• No memory management

– Program execution on a mote

• TinyOS: very small footprint

– Core OS requires only 400 bytes of code and data

memory, combined


• Communication

More aspects of TinyOS

– Based on active messages

– Higher-level protocols built on top of the AM interface

• Peripherals

– virtualized services in TinyOS (i.e. Timer)

• Portability

– AVR and MSP430 family of microcontrollers


• Limited memory safety

TinyOS Safety and Security Features

– No memory protection

– No isolation and safe termination

• Efforts to enhance safety in TinyOS

– Safe TinyOS: provides a minimal kernel for safely

executing trusted applications

– UTOS: implements a user kernel boundary that supports

isolation and self termination

• Efforts to enhance security in TinyOS

– TinySec


TinyOS Power management

• TinyOS scheduler responsible for power management

• Power management

– Radio power management

– Managing power of sensor nodes

• Power-save mode

– Low-power mode (e.g. TinyOS Timer)


TinyOS and nesC

• nesC Concepts

– Separation of construction and composition

– Interfaces specify components’ behaviour

– Interfaces are bidirectional

– Static linking of components via their interfaces

– Code to be generated by while-program compilers

– Suitable concurrency model


TinyOS sample application


Contiki (CTK) Design Principles

• Contiki is designed to address four essential demands

– Need for a lightweight OS

– Dynamic loading/ re-programming in a resource

constrained environment

– Event-driven kernel model desired

– Optional Protothread/ Preemptive multithreading


Contiki Concepts

• A Contiki system is partitioned into core and loaded


• Processes

– Application programs

– Services

• Core

– Kernel

– Program loader

– Libraries


Contiki Execution model

• Lightweight event scheduler

– Dispatches events to running processes

– Periodically call processes’ polling handlers

• Triggering of program execution

– Events dispatched by the kernel

– Through a polling mechanism

• Threads are driven by events

– Real threads can be used if needed

– There is a memory problem however


Contiki Concurrency

• Synchronous and asynchronous events

– Synchronous events: like function calls

– Asynchronous events: like posting new events

• Events can not pre-empt empt each other

– The kernel does not pre-empt an event handler

– They can only be pre-empted p by interrupts

• Complete multithreaded concurrency possible

– Implemented as an optional library


• Middle ground approach

Contiki Memory management

– Modules use static memory almost exclusively

– Modules allocate space dynamically for each of its

modules variables, when loading

• No virtual memory

• No support for protection mechanisms

– No memory protection ti between applications

– Single shared stack except for threads

– Each thread with a separate stack


• Communication

More aspects of Contiki

– Inter-process communication via event posting

– Communication implemented as a service

• Peripherals

– C functions used for communication with hardware

– No general-purpose support for implementing either

shared or virtualized services

• Portability

– Highly portable: including Texas Instruments MSP430

and the Atmel AVR


Contiki Safety and Security Features

• C programming without safety guarantees

– Programming requires proficiency with C pointers

• No sufficiently safe mechanism for abnormal

behaviour of the kernel or application

– Proto-threads are proposed

• Limited security services in current Contiki

– Radio chip, secure real-time services

• No OS protection guarantees


Contiki Power management

• No standard mechanisms for managing the power

state of peripheral devices

• Power optimizations

– Microcontroller

• in a sleep mode

– Power estimation

as additional feature


Contiki Sample application

• Application in the Contiki OS: a set of application and

service processes


• TinyOS

– Event-driven model

– Programs written as

explicit state machines

– Statically linked applications

• Contiki

– Proto-threads threads

– Programs written

in a sequential fashion

– dynamic linking of binaries

TOS vs Contiki Concepts


TOS vs Contiki Execution Model and


• Events-driven (TinyOS) vs multi-threaded (Contiki)

concurrency models


Events vs Threads vs Proto-threads

• Events-driven concurrency models (EDCM) vs multi-

threaded concurrency models (MTCM)

– EDCM: suitable for reactive systems

– MTCM: suitable for long running computations

Source: 1. A. Dunkels, B.Grönvall, T. Voigt, Contiki – a Lightweight and Flexible Operating System for Tiny Networked Sensors; 2. A. Dunkels, O. Schmidt, T. Voigt,

Using Protothreads for Sensor Node Programming


Events vs Threads

Event-driven concurrency models

Multi-threaded concurrency models

Advantages Disadvantages Advantages Disadvantages



Locking less


No wait()


No pre-emption





Larger code




Memory efficient State machines Sequential

Larger memory

code flow requirements

Source: A. Dunkels, B.Grönvall, T. Voigt, Contiki – a Lightweight and Flexible Operating System for Tiny Networked Sensors, Presentation

TU Dresden, 23.10.08


TOS vs Contiki Memory Management

• No memory protection in either system

• Static (TinyOS) vs mixed memory allocation approach


• Similar memory footprint of the communication stacks

(uIP and uIPv6) for both systems

Source: 1. D. Manjunath, Wireless Sensor Networks (WSN): Open Source Tools; 2. A. Dunkels, B.Grönvall, T. Voigt, Contiki – a Lightweight and Flexible Operating System

for Tiny Networked Sensors; 3. J. Schiff, Contiki - A Lightweight and Flexible Operating System for Tiny Networked Sensors; 4. A. Dunkels, IP for Smart Objects


TOS vs Contiki Safety and Security Features

• Neither system guarantees safe execution

– OS safety is not guaranteed

– Badly written code might have unexpected effects

• Optimizations in both systems are feasible

• Optimizations for TinyOS

– Safe TinyOS and UTOS

– Safe, optimized TinyOS program can be faster than the

original unsafe unoptimized application


TOS vs Contiki Power Management

• Both systems use sleep mode techniques to save

power in nodes and components

– Nodes and components forced to go into a low-power

power-save mode

• Sleep mode for peripherals


– TinyOS: chip specific function to select the appropriate

sleep mode for peripherals

– Contiki: no standard mechanisms for managing g the

power state of peripheral devices

• Many techniques offered to estimate energy

consumption of sensor nodes


TOS vs Contiki More Aspects

• Communication

– Active messages (TinyOS) vs event-posting (CTK)

– Communication in Contiki implemented as a service

• Peripherals

– Virtualized services in TinyOS

– No shared or virtualized services in Contiki

• Portability

– Both OS designed to be highly portable


Programming model in TinyOS

TOS vs Contiki Programming


Programming model in Contiki

Advantages Disadvantages Advantages Disadvantages

Smaller code


More difficult

programming structure

Nicer programming


Bigger code size

Smaller code

Code update &


Bigger code size


reprogramming not applications, easy

supported in TinyOS reprogramming

Smaller code

High energy costs for

Smaller upload

Bigger code size


reprogramming, less

portable, more


files, less energy,

less protocols,

more portable

Source: 1. J. P. Cotarelo, Comparison of different Operating Systems for Wireless Sensor Networks; 2. T. Voigt, Contiki – a Dynamic Operating System for Networked

Embedded Systems; 3. J. Schiff, Contiki - A Lightweight and Flexible Operating System for Tiny Networked Sensors; 4. P. Stok, J. Catalano, A. Schoofs, L. Vanzago, L.

Allmen, M. Andree, H. Karl, A. Fraboulet, E. Fleury, M. Hauspie, C. Brandolese, M. Berekovic, WASP, Preliminary description of hardware abstractions and programming


TU Dresden, 23.10.08


Programming Example TinyOS

Source: T. Voigt, Contiki – a Dynamic Operating System for Networked Embedded Systems


Programming Example Contiki

Source: T. Voigt, Contiki – a Dynamic Operating System for Networked Embedded Systems



• TinyOS and Contiki

– The most popular OS for WSN applications nowadays

– Almost equally used around the world

– Adequately answer the demand for operating in

environments with limited energy supply and

computational resources

– Similar but different


Similar magazines