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

Tiny OS

Thomas HutschenreutherFrank BeyerJens HeymannSupervisor: Dr. Waltenegus Dargie

Table of contents

1. Introduction and Motivation

2. Concept

3. Architecture1. Hardware Abstraction Architecture

2. Components

3. Networking

4. Implementation1. nesC

2. Scheduling

3. Shared resources

4. Power Management

5. Data Storage

6. Active Messages

5. Evaluation

6. Examples of TinyOS applications

7. References

Introduction and Motivation

Introduction and Motivation

• open source OS designed for wireless embedded sensor networks

• ported to over a dozen platforms and numerous sensor boards

• in use by wide community to develop and test various algorithms and protocols

Introduction and Motivation

• developed since 2000 by a consortium led by the University of California, Berkeley in co-operation with Intel Research

• several versions: – May 2002: version 0.6.1 for mica, rene, rene2

hardware platforms – October 2002: version 1.0 for mica and mica2– since February 2006: version 2.0 beta for eyesIFXv2,

intelmote2, mica2, mica2dot, micaZ, telosb, tinynode, btnode3

• TinyOS Alliance founded - organizational structure to support the worldwide academic and industrial TinyOS community

History:

rene2

Concept

Concept

• features component-based architecture rapid innovation and implementation

• minimal code size

• event-driven execution model– fine-grained power management– scheduling flexibility

• supports Active Messaging for communication between sensor nodes

Concept

• TinyOS’s component library– network protocols– distributed services– sensor drivers– data acquisition tools

• examples:– AD conversion − timers– cryptography − memory allocation– random numbers − routing– LED control − file system

Concept

• TinyOS provides runtime environment for nesC applications running on mote hardware– performs some resource management

– selected components are linked into the program at compile time (static linking)

• aims:– minimized hardware requirements

– efficient parallel processing of multiple data streams

– modularity of software

Architecture

Architecture

• Hardware Abstraction Architecture (HAA)– increasing portability

– simplifying application development by hiding hardware intricacies from rest of system

flexible, 3-layer abstraction hierarchy

Architecture

• layer 1: Hardware Presentation Layer (HPL)– thin software layer on top of raw hardware

– presents hardware (such as IO pins or registers) as nesC interfaces

• layer 2: Hardware Adaptation Layer (HAL)– offers higher level abstractions (easier to use than HPL)

– still provides full functionality of underlying hardware

• layer 3: Hardware Independent Layer (HIL)– provides hardware independent abstractionsgeneralization limits functionality compared to HAL

– HIL components represent abstractions that applications can use and safely compile on multiple platforms

ArchitectureHardware Abstraction Architecture

principle structure taken from [1]

• each layer represents components

• component: – consists of 4 parts

1. command handler

2. event handler

3. frame

4. task(s)

• scheduler handles processing of tasks (FIFO)

Architecture

internal communication between componentsusing bidirectional interfaces

Architecture

1. command:

– request sent from components of higher layer to components of lower layer

– deposits parameters to components frame and conditionally schedules a task for execution

– may return value if successful

Architecture

2. event:

– signalled by components of lower layer to components of higher layer

– can be initiated by hardware interrupts on lowest layer

– every component can signal events, post tasks or call commands (e.g. timer)

3. frame:

– data storage of a component

– static size

Architecture

4. task:

– do the underlying work

– activated by events, commands or other tasks out of the same component

– there can only be one task at the same time, can only be interrupted by events

– runs as long until it terminates itself

Architecture

example for a component:

picture taken from [2]

Architecture

Networking:• 3 mechanisms:

1) Active Messages:● node to node communication

2) Dissimination● reliably spreading pieces of data from root to every node in

network● primarily used for reconfiguration and maintainance of

network

3) Collection● collecting data from all nodes to the root● tree-based routing

Implementation

Implementation

nesC● extension of C● developed for the implementation of TinyOS● concurrency model based on tasks and events

➔ direct support of TinyOS' component based concurrency model

● static language➔ no dynamic memory allocation➔ call graph known at compile time

● compile time race detection

Implementation

nesC - components● two types of components

1) modules

2) configurations● components use and provide interfaces● interfaces are bidirectional

● events● commands

● application built by wiring components together

example for an interface:

• the interface specifies: Timer must implement start and stop, Application must implement fired

picture taken from [4]

Implementation

interface Timer<precision_tag>{ command void start(uint32_t dt); command void stop(); event void fired();}

Implementation

configuration example:

Implementation

Scheduling• 3 types of workload:

– direct function calls (synchronous/asynchronous)

– event handlers (synchronous/asynchronous)

– tasks (synchronous)

• event handlers can be executed immediately when event signalled (can preempt anything else)– consistency assured by atomic sections

• tasks for background processing

• for expensive instructions - SplitPhase commands– function call returns immediately

– completion signalled by callback

Implementation

Scheduling - Tasks• default: nonpreemptive FIFO• one slot per task in queue• tasks can only be posted once• if need for multiple postings:

– state variable– task reposts itself when ready

• task queue empty → processor sleep mode

Implementation

Shared resources

• 3 kinds of abstraction:– dedicated

• resource belongs to a single component

– virtualized• clients act, as if resource dedicated

• clients hidden from each other by software virtualization

• usefull if clients don't need full control over resource

– shared• several components need direct access to resource➔ resource arbiter

Implementation

Resource Arbiters• central place managing use of shared resources

– can also be used for power management

• each arbiter must implement :– Resource interface

interface Resource {

async command error_t request();

async command error_t immediateRequest();

event void granted();

async command error_t release();

async command bool isOwner();}

– ArbiterInfo interface• tells clients status of arbiter

• an arbiter should implement:– ResourceRequested interface– ResourceConfigure interface

Implementation

Implementation

Power Management● microcontroller powermanagement

● three mechanisms:1) dirty bit

2) chip specific low power calculation function

3) power state override function

component McuSleepC {

provides interface McuSleep;

provides interface PowerState;

uses interface PowerOverride;

}

component McuSleepC {

provides interface McuSleep;

provides interface PowerState;

uses interface PowerOverride;

}

interface McuPowerState {async command void update();}

interface McuPowerOverride {async command mcu_power_t

lowestState();}

interface McuPowerState {async command void update();}

interface McuPowerOverride {async command mcu_power_t

lowestState();}

Implementation

Power Management of Non-Virtualised Devices

• explicit power management– StdControl

– SplitControl

– AsyncStdControl

• implicit power management– ResourceController

Implementation

Data Storage• flash chips• divided into volumes via XML specification• storage abstraction instances:

– BlockStorageC• intended for large objects

• only entire objects can be written

• erase before every write

– LogStorageC• intended for data gathering

• circular or linear logs

– ConfigStorageC• transactional behavior

• random reads and writes

Implementation

• Active Messaging

– concept for communication between nodes in the network

– design challenge:• minimize communication overhead• allow communication to overlap computation • coordinate the two without sacrificing processor

performance

– Active Messages (AM) allow cost effective use of hardware

– latency tolerance becomes a programming/compiling concern

Implementation

• structure of an Active Message:– header: adress, function pointer, metadata

– payload (maximum default length = 29 bytes)

• general implementation:typedef nx_struct message_t {

nx_uint8_t header[sizeof(message_header_t)];

nx_uint8_t data[TOSH_DATA_LENGTH];

nx_uint8_t footer[sizeof(message_footer_t)];

nx_uint8_t metadata[sizeof(message_metadata_t)];

} message_t;

Implementation

• how it works:– each node has its own AM handler

• consists of: sender, receiver and snooper

– node (source) sends its AM

– header is pointer on AM handler of receiver node (sink)

– AM handler executes immediately on message arrival with payload as argument

Evaluation

Evaluation

• advantages:

– open source

– modularity (component model)

– event based

providing fast transmission of sensor data (collect data local computation transmit)

– low memory usage (~200 bytes)

Evaluation

• disadvantages:

– static linking (selected components linked into program at compile time)

– Interoperability with other software frameworks and languages

Examples of TinyOS

applications

Examples

• there over hundreds of projects based on TinyOS:

– TinyDB:

• query processing system for extracting information from a network of TinyOS sensors

• provides a simple, SQL-like interface instead of embedded C code

Examples

– CotsBots:• use commercial off-the-shelf (COTS) components to build

and deploy inexpensive and modular robots

• provide a convenient platform to investigate algorithms, cooperation and distributed sensing in large (> 50) robot networks

• based on Mica Motes

• including a board equipped

with light, temperature,

buzzer/microphone,

2-axis magnetometer

and accelerometer

picture taken from [6]

References• [1] www.tinyos.net, TinyOS tutorial, FAQ• [2] Christian Renner: Seminar Betriebssysteme für Rechnernetze,

Universität Tübingen• [3] Fei Xie, University of Texas at Austin

CS372 Programming Project www.cs.utexas.edu/users/feixie/cs372/

• [4] Jan S. Rellermeyer, 2005: Talk at Distributed Systems Prof. R. Wattenhofer and P. von Rickenbach: TinyOS http://people.inf.ethz.ch/rjan/publications/

• [5] T. von Eicken, D. E. Culler, S. C. Goldstein, and K.E. Schauser.Active messages: a mechanism for integrated communicationand computation. In Proceedings of the 19th Annual InternationalSymposium on Computer Architecture, pages 256–266,Gold Coast, Qld., Australia, May 1992

• [6] CotsBots Homepage

http://www-bsac.eecs.berkeley.edu/projects/cotsbots/index.html

Thank you for your attention!