System Architecture Directions for Networked Sensors

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

CS 851 - Radu Stoleru

University of Virginia

TinyOS

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

University of Virginia

Components

A component has:

Frame (internal state) Tasks (computation) Interface (events, commands) one per component statically allocated fixed size

Component
Tasks Frame

Frame :

Commands

Events

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

University of Virginia

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 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 4

events:

Scheduler

two level scheduling: events and tasks scheduler is simple FIFO a task can not preempt another task events preempt tasks (higher priority)
Preempt events POST Tasks FIFO commands commands Interrupts Hardware Time

main { while(1) { while(more_tasks) schedule_task; sleep; } }

University of Virginia

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

Application
application Routing Layer sensing application routing

messaging

Messaging Layer

packet

Radio Packet

UART Packet

byte

Radio byte

UART byte

photo

Temp

SW HW
7

bit

RFM

clocks University of Virginia

ADC

i2c

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) code your components $ make mica2 install.1 $ make pc $ build/pc/main.exe 25
University of Virginia 8

build your application

debug your application with TOSSIM simulator:

nesC

the nesC model:

Application

interfaces:

Component D Component A

uses provides
Component C

components:

modules configurations
Component F configuration Component E

application:= graph of components

Component B

configuration

University of Virginia

nesC

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

clarifications:

Clock.nc interface Clock { ... }

ClockC.nc configuration ClockC { ... } implementation { } TimerC.nc configuration TimerC { ... } implementation { } TimerM.nc module TimerM { ... } implementation { }

C distinguishes between an interface and the component that provides it M when a single component has both: a configuration, a module

Timer.nc interface Timer { ... }

University of Virginia

10

Interfaces

used for grouping functionality, like:

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

describe bidirectional interaction:

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

Clock.nc
ClockC

interface provider must implement commands interface user must implement events
University of Virginia 11

Interfaces

examples of interfaces:
interface Timer { command result_t start (char type, uint32_t interval); command result_t stop (); event result_t fired (); } Timer.nc interface ReceiveMsg { event TOS_MsgPtr receive (TOS_MsgPtr m); }

interface StdControl { command result_t init (); command result_t start (); command result_t stop (); } StdControl.nc interface SendMsg { command result_t send (uint16_t addr, uint8_t len, TOS_MsgPtr p); event result_t sendDone (); } SendMsg.nc

ReceiveMsg.nc
12

University of Virginia

Modules

implements a components specification with C code:

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

a thread of control crosses components only through their specifications

University of Virginia 13

Modules

parameterised interfaces:
module GenericComm { provides interface SendMsg [uint8_t id]; provides interface ReceiveMsg [uint8_t id]; } implementation { }

GenericComm.nc

i.e., it provides 256 instances of SendMsg and RecvMsg interfaces they are not strictly necessary the handler ID can be passed as an argument to the send method
University of Virginia 14

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; }
University of Virginia

DoesNothing.nc
15

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.nc

University of Virginia

16

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 17

Configurations

implements a component by wiring together multiple components:

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

wiring := connects interfaces, commands, events together

University of Virginia 18

Configurations

connected elements must be compatible (interfaceinterface, command-command, event-event) 3 wiring statements in nesC:

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

University of Virginia

19

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

20

Configurations

other examples:

configuration C { provides interface X as Xprovider; uses interface X as Xuser; } implementation { Xuser = Xprovider; C.nc } configuration D { provides interface X; } implementation { components C1, C2; X = C1.X; X = C2.X; }

C1

C2 D

D.nc
University of Virginia 21

Future

abstract components: allow components to be instantiated several times automatic wiring threadlets

University of Virginia

22

Example

Blink application

Blink Main

configuration Blink { } implementation { components Main, BlinkM, ClockC, LedsC; Main.StdControl->BlinkM.StdControl; BlinkM.Clock->ClockC; BlinkM.Leds->LedsC; Blink.nc
ClockC

BlinkM

LedsC

University of Virginia

23

Example

BlinkM module:
command result_t StdControl.start() { return call Clock.setRate(128, 6); } command result_t StdControl.stop() { return call Clock.setRate(0, 0); event result_t Clock.fire() { state = !state; if (state) call Leds.redOn(); else call Leds.redOff(); } Blink.nc
24

module BlinkM { provides interface StdControl; uses interface Clock; uses interface Leds; } implementation { bool state; command result_t StdControl.init() { state = FALSE; call Leds.init(); return SUCCESS; } Blink.nc

University of Virginia

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 25

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

University of Virginia

26