runtime

ptroeger

runtime

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

2/40


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

3/40


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

4/40


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

OS

• Sensor networks are often designed for reliable real-

time services

– Additional limitation towards some characteristics of

conventional OS

5/40


OS for WSN (WSN 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

6/40


TinyOS (TOS) Design Principles

• TinyOS is designed to address four essential

demands

– Limited resources

– Reactive concurrency

– Flexibility

– Low power

7/40


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

8/40


• 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

9/40


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

10/40


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

11/40


• 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

12/40


• 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

13/40


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)

14/40


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

15/40


TinyOS sample application

16/40


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

17/40


Contiki Concepts

• A Contiki system is partitioned into core and loaded

programs

• Processes

– Application programs

– Services

• Core

– Kernel

– Program loader

– Libraries

18/40


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

19/40


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

20/40


• 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

21/40


• 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

22/40


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

23/40


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

24/40


Contiki Sample application

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

service processes

25/40


• 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

26/40


TOS vs Contiki Execution Model and

Concurrency

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

concurrency models

27/40


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

28/40


Events vs Threads

Event-driven concurrency models

Multi-threaded concurrency models

Advantages Disadvantages Advantages Disadvantages

Compact

code

Locking less

problematic

No wait()

statements

No pre-emption

wait()

statements

Pre-emption

possible

Larger code

overhead

Locking

problematic

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

29/40


TOS vs Contiki Memory Management

• No memory protection in either system

• Static (TinyOS) vs mixed memory allocation approach

(Contiki)

• 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

30/40


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

31/40


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

p

– 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

32/40


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

33/40


Programming model in TinyOS

TOS vs Contiki Programming

Model

Programming model in Contiki

Advantages Disadvantages Advantages Disadvantages

Smaller code

size

More difficult

programming structure

Nicer programming

structure

Bigger code size

Smaller code

Code update &

Loadable

Bigger code size

size

reprogramming not applications, easy

supported in TinyOS reprogramming

Smaller code

High energy costs for

Smaller upload

Bigger code size

size

reprogramming, less

portable, more

protocols

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

model

TU Dresden, 23.10.08

34/40


Programming Example TinyOS

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

35/40


Programming Example Contiki

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

36/40


Conclusions

• 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

37/40

Similar magazines