9/29/11

TinyOS TinyOS

● application = scheduler + graph of components

● event-driven architecture

● single shared stack

● NO kernel, process/,

UCLA – CS213 – Fall 2008

Components Commands/Events

● A component has: ● commands: – Frame (internal state) – deposit request parameters into the frame – Tasks (computation) Component – are non-blocking Fra – Interface (events, commands) Tasks me – need to return status => postpone time consuming work by posting a task

● Frame : – can call lower level commands

– one per component ● events: – statically allocated – can call commands, signal events, post tasks, can not be signaled by – fixed size Commands Events commands – preempt tasks, not vice-versa – interrupt trigger the lowest level events ● Commands and Events are function calls – deposit the information into the frame ● Application: linking/glueing interfaces (events, commands)

Scheduler Tasks

● two level scheduling: events and tasks ● FIFO scheduling

● scheduler is simple FIFO ● non-preemptable by other task, preemtable by events

● a task can not preempt another task ● perform computationally intensive work

● events preempt tasks (higher priority) ● handling of multiple data flows: – a sequence of non-blocking command/event through the component graph main { Preempt Tasks – … POST FIFO post task for computational intensive work while(1) { – preempt the running task, to handle new data

while(more_tasks) commands schedule_task; events commands sleep;

} Interrupts } Time Hardware

1 9/29/11

Application Programming Environment

● OS: cygwin/Win2000 or gcc/ application sensing application ● Software: atmel tools, java, perl mote-PC Routing Layer routing comms mote Code download messaging Messaging Layer programming board packet Radio Packet UART Packet

Radio byte UART byte Temp byte photo SW

HW bit RFM clocks ADC i2c

Programming Environment nesC

● the nesC model: Application ● download, install and build: – interfaces: Component – cygwin (http://www.cygwin.com) D ● uses – WinAVR (http://winavr.sourceforge.net) ● provides LED – nesC (http://nesc.sourceforge.net) – components: – Java JDK (http://java.sun.com/j2se/1.4.1) ● modules – tinyOS distribution (http://sourceforge.net/projects/tinyos) Application ● configurations ● build your application ● application:= graph – code your components Counter – $ make mica2 install.1 of components

● ● debug your application with TOSSIM simulator: Why is this a good Component F – $ make pc choice for a sensor – $ build/pc/main.exe 25 net language? configuration Radio configuration

nesC Interfaces

● naming conventions: ● used for grouping functionality, like: – nesC files suffix: .nc – split-phase operation (send, sendDone)

– C stands for Configuration (Clock, ClockC) ● Non blocking operation – M stands for Module (Timer, TimerC, TimerM) – standard control interface (init, start, stop) TimerM ● describe bidirectional interaction: ● clarifications: Clock.nc ClockC.nc interface Clock { command result_t setRate (char interval, char scale); – “ ” interface Clock { configuration ClockC { C distinguishes between an ...... event result_t fired (); } } interface and the component ? ? } Clock.nc implementation { that provides it … } ClockC – “M” when a single ● interface provider must implement commands component has both: a Timer.nc TimerC.nc TimerM.nc interface Timer { configuration TimerC { module TimerM { ● interface user must implement events configuration, a module ...... } } } ? ? ? implementation { implementation { … … } }

2 9/29/11

Interfaces Modules

● examples of interfaces: ● implements a component’s specification with C code: interface StdControl { interface Timer { module MyComp { command result_t init (); command result_t start (char type, provides interface X; command result_t start (); uint32_t interval); provides interface Y; command result_t stop (); command result_t stop (); uses interface Z; } event result_t fired (); } } implementation { StdControl.nc Timer.nc …// C code } interface SendMsg { interface ReceiveMsg { command result_t send (uint16_t addr, event TOS_MsgPtr receive (TOS_MsgPtr m); uint8_t len, } MyComp.nc ● a thread of control crosses components only through their TOS_MsgPtr p); event result_t sendDone (); specifications }

SendMsg.nc ReceiveMsg.nc

Modules Modules

● parameterised interfaces: ● implementing the specification: – simple interfaces, (e.g. interface Std of type StdControl): module GenericComm { provides interface SendMsg [uint8_t id]; module DoesNothing { provides interface ReceiveMsg [uint8_t id]; provides interface StdControl as Std; … } } implementation { implementation {… command result_t Std.init() { } GenericComm.nc return SUCCESS; } – i.e., it provides 256 instances of SendMsg and RecvMsg interfaces command result_t Std.start() { – they are not strictly necessary – the handler ID can be passed as return SUCCESS; an argument to the send method } command result_t Std.stop() { return SUCCESS; } DoesNothing.nc

Modules Modules

● calling commands and signaling events ● posting tasks: – simple interface: module BlinkM {… – In addition to stop, put the start. } module TimerM { implementation {… provides interface StdControl; task void processing () { provides interface Timer[uint8_t id]; if(state) call Leds.redOn(); uses interface Clock;… else call Leds.redOff(); } }

implementation { event result_t Timer.fired () { command result_t StdControl.stop() { state = !state; call Clock.setRate(TOS_I1PS, TOS_S1PS); post processing(); } return SUCCESS; … }… } TimerM.nc } BlinkM.nc

3 9/29/11

Configurations Example

● connected elements must be compatible (interface- ● BlinkM module: interface, command-command, event-event) module BlinkM { command result_t StdControl.start() { ● 3 wiring statements in nesC: provides interface StdControl; return call Clock.setRate(128, 6); – endpoint1 = endpoint2 uses interface Clock; } uses interface Leds; – endpoint1 -> endpoint2 } command result_t StdControl.stop() { – endpoint1 <- endpoint2 (equivalent: endpoint2 -> endpoint1) return call Clock.setRate(0, 0); implementation { bool state; event result_t Clock.fire() { state = !state; command result_t StdControl.init() { if (state) call Leds.redOn(); state = FALSE; else call Leds.redOff(); call Leds.init(); } return SUCCESS; } } Blink.nc Blink.nc

Tools Summary/Discussion

● small memory footprint +

● concurrency intensive application, event-driven architecture + ● TinyDB

● power conservation +

● modular, easy to extend + ● Tossim Demo

● simplistic FIFO scheduling -> no real-time guarantees - – Lossy builder ● bounded number of pending tasks -

● no process management -> resource allocation problems - – Topology creation

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

TinyDB Architecture Declarative Queries

● Users specify the data they want SELECT T:1, AVG: 225 – Simple, SQL-like queries AVG(temp) Queries T:2, AVG: 250 WHERE light Results – Using predicates, not specific addresses > 400 Multihop Network Schema: ● Challenge is to provide: • “Catalog” of commands & attributes Query Processor – Expressive & easy-to-use interface – High-level operators Aggavg(temp)

● “Transparent Optimizations” that many programmers would miss – Sensor-net specific techniques Filterlight > 400 Name: temp Time to sample: 50 uS – Power efficient execution framework got(‘temp’) get (‘temp’) Tables Samples Cost to sample: 90 uJ Schema Calibration Table: 3 getTempFunc(…) Units: Deg. F TinyOS Error: ± 5 Deg F Get f : getTempFunc()… TinyDB

4 9/29/11

Declarative Queries for Sensor Benefits of Declarative Queries Networks ● Specification of “whole-network” behavior

● Simple, safe

● Complex behavior via multiple queries, app logic “Find the sensors in bright nests.” ● Optimizable ● Examples: – Exploit (non-obvious) interactions SELECT nodeid, nestNo, light – E.g.: 1 FROM sensors Sensors ● ACQP operator ordering, Adaptive join operator placement, Lifetime Epoch Nodeid nestNo Light WHERE light > 400 selection, Topology selection EPOCH DURATION 1s 0 1 17 455

0 2 25 389

1 1 17 422

1 2 25 405

Tiny Aggregation (TAG) Query Propagation Via Tree- Based Routing

● Not in today’s reading ● Tree-based routing Q:SELECT … ● In-network processing of aggregates – Used in: A

● Query delivery – Common data analysis operation Q Q ● Data collection R:{…} ● Aka gather operation or reduction in || programming R:{…} – Topology selection is important; – Communication reducing e.g. Q ● Operator dependent benefit B C ● Krishnamachari, DEBS 2002, Q Intanagonwiwat, ICDCS 2002, Heidemann, SOSP 2001 Q Q Q • LEACH/SPIN, Heinzelman et al. R:{…} MOBICOM 99 ● Exploit query semantics to improve efficiency! D • SIGMOD 2003 Q R:{…} – Continuous process R:{…}Q Q Q ● Mitigates failures F E Q Madden, Franklin, Hellerstein, Hong. Tiny AGgregation (TAG), OSDI 2002.

Types of Aggregates References ● SQL supports MIN, MAX, SUM, COUNT, AVERAGE

[1] E.Brewer et al. “nesC Overview (and Summary of Changes), 06/2002 ● Any function over a set can be computed via TAG [2] D.Gay, D.Culler, P.Levis “nesC Language Reference Manual”, 9/2002 [3] D.Gay “nesC: A for Motes”, 06/2002 [4] D.Culler “Welcome to the WeBS Retreat”, 06/2002 ● In network benefit for many operations [5] E.Brewer et al. “Macroprogramming”, 06/2002 – E.g. Standard deviation, top/bottom N, spatial union/intersection, [6] http://webs.cs.berkeley.edu histograms, etc. [7] http://www.cens.ucla.edu – Compactness of PSR [8] http://www.rsc.rockwell.com [9] http://www-mtl.mit.edu/research/icsystems/uamps/uAMPS-1

5