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