University of Virginia 1

System Architecture Directions for Networked

Sensors

CS 851 - Radu Stoleru

J.Hill, R.Szewczyk, A.Woo, S.Hollar, D.Culler, K.Pister

University of Virginia 2

TinyOS application = scheduler + graph of components event-driven architecture single shared stack NO kernel, process/memory management, virtual memory

University of Virginia 3

Components A component has:

Frame (internal state) Tasks (computation) Interface (events, commands)

Frame : one per component statically allocated fixed size

Tasks

ComponentFrame

EventsCommands

Commands and Events are function calls Applicaton: linking/glueing interfaces (events,

commands)

University of Virginia 4

Commands/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

University of Virginia 5

Scheduler two level scheduling: events and tasks scheduler is simple FIFO a task can not preempt another task events preempt tasks (higher priority)

Hardware

Interrupts

eve

nts

commands

FIFOTasks

POSTPreempt

Time

commands

main { … while(1) {

while(more_tasks)

schedule_task;sleep;

}}

University of Virginia 6

Tasks FIFO scheduling non-preemptable by other task, preemtable by events perform computationally intensive work handling of multiple data flows:

a sequence of non-blocking command/event through the component graph

post task for computational intensive work preempt the running task, to handle new data

University of Virginia 7

Application

RFM

Radio byte

i2c

Tempphoto

Messaging Layer

clocksbit

byte

packet Radio Packet

Routing Layer

sensing applicationapplication

HW

SW

ADC

messaging

routing

UART Packet

UART byte

University of Virginia 8

Programming Environment download, install and build:

cygwin (http://www.cygwin.com) WinAVR (http://winavr.sourceforge.net) nesC (http://nesc.sourceforge.net) Java JDK (http://java.sun.com/j2se/1.4.1) tinyOS distribution (http://sourceforge.net/projects/tinyos)

build your application code your components $ make mica2 install.1

debug your application with TOSSIM simulator: $ make pc $ build/pc/main.exe 25

University of Virginia 9

nesC the nesC

model: interfaces:

uses provides

components: modules configuration

s

application:= graph of components

Component A

Component B

ComponentD

Component C

Application

configurationconfigurationComponent

E

ComponentF

University of Virginia 10

nesC naming conventions:

nesC files suffix: .nc C stands for Configuration (Clock, ClockC) M stands for Module (Timer, TimerC, TimerM)

?

Clock.nc

?

ClockC.nc

configuration ClockC { ...}

implementation {…}

ClockC.nc

interface Clock { ...}

Clock.nc

?

Timer.nc

interface Timer { ...}

Timer.nc

?

TimerC.nc

?

TimerM.nc

configuration TimerC { ...}

implementation {…}

TimerC.nc

module TimerM { ...}

implementation {…}

TimerM.nc

clarifications: “C” distinguishes between an

interface and the component that provides it

“M” when a single component has both: a configuration, a module

University of Virginia 11

Interfaces used for grouping functionality, like:

split-phase operation (send, sendDone) standard control interface (init, start, stop)

describe bidirectional interaction:

interface provider must implement commands interface user must implement events

interface Clock { command result_t setRate (char interval, char scale); event result_t fired ();} Clock.nc

TimerM

ClockC

University of Virginia 12

Interfaces examples of interfaces:

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

interface Timer { command result_t start (char type, uint32_t

interval); command result_t stop (); event result_t fired ();}

interface SendMsg { command result_t send (uint16_t

addr, uint8_t len, TOS_MsgPtr

p); event result_t sendDone ();}

interface ReceiveMsg { event TOS_MsgPtr receive (TOS_MsgPtr

m);}

StdControl.nc Timer.nc

ReceiveMsg.ncSendMsg.nc

University of Virginia 13

Modules implements a component’s specification with C

code:

a thread of control crosses components only through their specifications

module MyComp { provides interface X; provides interface Y; uses interface Z;}implementation {…// C code}

MyComp.nc

University of Virginia 15

Modules implementing the specification:

simple interfaces, (e.g. interface Std of type StdControl):module DoesNothing {

provides interface StdControl as Std;}implementation { command result_t Std.init() { return SUCCESS; } command result_t Std.start() { return SUCCESS; } command result_t Std.stop() { return SUCCESS;} DoesNothing.n

c

University of Virginia 16

Modules calling commands and signaling events

simple interface:

module TimerM { provides interface StdControl; provides interface Timer[uint8_t id]; uses interface Clock;…}

implementation { command result_t StdControl.stop() { call Clock.setRate(TOS_I1PS, TOS_S1PS); } …} TimerM.n

c

University of Virginia 17

Modules posting tasks:

module BlinkM {…}implementation {… task void processing () { if(state) call Leds.redOn(); else call Leds.redOff(); }

event result_t Timer.fired () { state = !state; post processing(); return SUCCESS; }…} BlinkM.nc

University of Virginia 18

Configurations implements a component by wiring together

multiple components:

wiring := connects interfaces, commands, events together

configuration MyComp { provides interface X; provides interface Y; uses interface Z;}implementation {…// wiring code}

MyComp.nc

University of Virginia 19

Configurations connected elements must be compatible

(interface-interface, command-command, event-event)

3 wiring statements in nesC: endpoint1 = endpoint2

endpoint1 -> endpoint2

endpoint1 <- endpoint2 (equivalent: endpoint2 -> endpoint1)

University of Virginia 20

Configurations wiring example:

configuration GenericComm { provides interface StdControl as

Control; command result_t activity();…}

implementation { components AMStandard, LedsC;

Control = AMStandard.Control; AMStandard.Leds -> LedsC.Leds; activity = AMStandard.activity;}

GenericComm.nc

AMStandard

LedsC

GenericComm

University of Virginia 22

Future abstract components: allow components to be

instantiated several times automatic wiring threadlets

University of Virginia 25

Summary/Discussion small memory footprint + concurrency intensive application, event-driven architecture

+ power conservation + modular, easy to extend + simplistic FIFO scheduling -> no real-time guarantees - bounded number of pending tasks - no process management -> resource allocation problems - software level bit manipulation. HW implementation can

provide speed up and power saving. - no hardware timer support. It is done in software, which is lost

during sleep. - better OS race conditions support. -

University of Virginia 26

References[1] E.Brewer et al. “nesC Overview (and Summary of

Changes), 06/2002[2] D.Gay, D.Culler, P.Levis “nesC Language Reference

Manual”, 9/2002[3] D.Gay “nesC: A Programming Language for Motes”,

06/2002[4] D.Culler “Welcome to the WeBS Retreat”, 06/2002[5] E.Brewer et al. “Macroprogramming”, 06/2002[6] http://webs.cs.berkeley.edu[7] http://www.cens.ucla.edu[8] http://www.rsc.rockwell.com[9]

http://www-mtl.mit.edu/research/icsystems/uamps/uAMPS-1