Based on slides from Andreas Larsson

2013

Table from CY Chong, SP Kumar, BA Hamilton - Proceedings of the IEEE, 2003

CPU 7MHz

Program Memory

128 kB

RAM 4 kB

Storage Memory

512 kB

Bandwidth 250 kBps

Indoor Range

20-30 m

Outdoor Range

75-100 m

Battery LifeFull operation at all times

50 h

SleepingThe Main TaskData gatheringData aggregationData communication

Auxiliary TasksSynchronizationSecurity

UtilityStructural health monitoringAgricultureParking space guidance/monitoring

ResearchVolcanosPermafrostAnimal behavior

COMMONSense

Permasense

Part 2TinyOS and nesC

Programming

Selected slides from:

Wireless Sensor NetworksHardware/Software

Tiny OS & NesC Programming

borrowed fromTurgay Korkmaz

What is TinyOS?

• Operating system developed by UC Berkeley

• Open Source development environment

–System, library and applications written in nesC• nesC (network embedded system C) a component-based C

–Event-driven architecture

–Single shared stack

–NO kernel, process/memory management

Programming Model• Basic concept behind nesC:

• Separation of construction and composition

• Programs are built out of components

Components

• A component is a black box specified by interface(s)

• Interfaces define a set of logically related I/O functions called commands and events

• Components use and provide interfaces

• Components are statically wired together based on their interfaces

Timer Component

StdControl Timer

Clock

provides

uses

StdControl.nc

interface StdControl {

command result_t init();

command result_t start();

command result_t stop();

}

Clock.nc

interface Clock {

command result_t setRate( char interval, char

scale);

event result_t fire();

}

Components (cont’d)• A component–Processes Commands–Throws Events–Has a Frame for local state–Uses Tasks for concurrency

• Components must implement – the events they use and – the commands they provide

Can signalMust implementProvide

Must implementCan callUse

EventsCommandsComponent

Timer Component

StdControl Timer

Clock

provides

uses

Commands and Events• Commands

–deposit request parameters into the frame

–are non-blocking

–need to return status

–postpone time consuming work by posting a task

–can call lower level commands

• Events

–can call commands, signal events, post tasks

–can Not be signaled by commands

–preempt tasks, not vice-versa

–interrupt trigger the lowest level events

–deposit the information into the frame

{... status = call CmdName(args)...}

command CmdName(args) {...return status;}

{... status = signal EvtName(args)...}

event EvtName(args) {...return status;}

Component Hierarchy• Components are wired

together by connecting users with providers

•Commands:

–Flow downwards

–Control returns to caller

•Events:

–Flow upwards

–Control returns to signaler

Types of Components• There are two types of components:

•Modules: provide code that implements one or more interfaces and internal behavior

•Configurations: Wires/links components together to yield a new component

• A component does not care if another component is a module or configuration

• A component may be composed of other components

Component Syntax - Module

module ForwarderM { provides { interface StdControl; } uses { interface StdControl as CommControl; interface ReceiveMsg; interface SendMsg; interface Leds; }}implementation {code implementing all

provided commands used events, andtasks

}

ForwarderM

StdControl ReceiveMsg

provides uses

CommControl

SendMsg

Leds

interface StdControl {command result_t init(); command result_t start(); command result_t stop();

}

interface SendMsg{ command result_t send(uint16_t address, uint8_t

length, TOS_MsgPtr msg); event result_t sendDone(TOS_MsgPtr msg,

result_t success);}

module ForwarderM { //interface declaration}implementation { command result_t StdControl.init() { call CommControl.init(); call Leds.init(); return SUCCESS; } command result_t StdControl.start() {…} command result_t StdControl.stop() {…} event TOS_MsgPtr ReceiveMsg.receive(TOS_MsgPtr m) { call Leds.yellowToggle(); call SendMsg.send(TOS_BCAST_ADDR, sizeof(IntMsg), m); return m; } event result_t SendMsg.sendDone(TOS_MsgPtr msg, bool success) { call Leds.greenToggle(); return success; }}

module ForwarderM { //interface declaration}implementation { command result_t StdControl.init() { call CommControl.init(); call Leds.init(); return SUCCESS; } command result_t StdControl.start() {…} command result_t StdControl.stop() {…} event TOS_MsgPtr ReceiveMsg.receive(TOS_MsgPtr m) { call Leds.yellowToggle(); call SendMsg.send(TOS_BCAST_ADDR, sizeof(IntMsg), m); return m; } event result_t SendMsg.sendDone(TOS_MsgPtr msg, bool success) { call Leds.greenToggle(); return success; }}

Command imp.

(interface provided)

Event imp.

(interface used)

ForwarderM

StdControl ReceiveMsg

provides uses

CommControl

SendMsg

Leds

Component Implementation

Component Syntax - Configurationconfiguration Forwarder { }implementation{ components Main, LedsC; components GenericComm as Comm; components ForwarderM;

Main.StdControl -> ForwarderM.StdControl; ForwarderM.CommControl -> Comm; ForwarderM.SendMsg -> Comm.SendMsg[AM_INTMSG]; ForwarderM.ReceiveMsg -> Comm.ReceiveMsg[AM_INTMSG]; ForwarderM.Leds -> LedsC;}

ComponentSelection

Wiring the Components

together

ForwarderM

StdControl ReceiveMsg

provides uses

CommControl

SendMsg

Leds

Main StdControl

LedsCLeds

GenericCommSendMsg

ReceiveMsg

StdControlForwarder

21DSII: Group Comm.

• The lab is done on the computer:• dark.cs.chalmers.se

• You will receive a username and password in pingpong.• TinyOS with all sources for libraries and everything is

installed at /opt/tinyos-2.1.0• Unpack Rout.tar.gz into your home directory (at the server) and

do the assignment from there.• Compile the program by executing: make micaz sim• Run the simulation by executing: ./simulation.py <topology file>• Build topologies using buildtopo.py to get a grid and then

remove some nodes to get some interesting formation

Implement something better than the basic routing algorithm.

The battery level is something that is known to a node, so feel free to use that in your algorithm.

Sink

Messages:•Announcement•Content

Aggregate information and send it to the sink.Many nodes in an area send their information to a cluster headThe cluster head sends the aggregate message to the sink. A simple algorithm to choose cluster head:

for every node with a certain probability announces itself to be a cluster head.

Choose the parameters you like: battery level of the node, battery level of neighbors, etc.

A cluster head should not store content for more than 1 round.

Report: Part 1: Discuss the idea behind your algorithm. Present results from comparing your algorithm to the original

algorithm. Discuss failed improvements.

Part 2: Discuss the idea behind your algorithm. Present results from comparing your algorithm to your algorithm in

part one. Discuss failed improvements.

Presentation: Each group gives a 10 min presentation of their algorithm. March 6, 13:15-17:00, Room: EL42.

25