Tiny Microthreading Operating System Tiny OS Networked Sensor

Tiny Microthreading Operating System: Tiny. OS

Networked Sensor Characteristics w Small physical size and low power consumption w Concurrency-intensive operation w Limited physical parallelism and controller hierarchy w Diversity in Design and Usage w Robust Operation

Photograph and schematic for the Network Sensor

The Solution: Tiny. OS w A microthreaded OS that draws on previous work done for lightweight thread support, and efficient network interfaces w Two level scheduling structure n Long running tasks that can be interrupted by hardware events w Small, tightly integrated design that allows crossover of software components into hardware

Tiny. OS - Design Components Commands Events Scheduler Events Hardware components

Structure of a Component Command Handlers Set of Tasks Event Handlers Frame (containing state information) Tiny. OS Component

Tiny. OS Component Model w Component has: Frame (storage) n Tasks (computation) n Command Event Interface n Messaging Component Internal Tasks Commands Internal State Events n To facilitate modularity, each component declares the commands it uses and the events it signals. n Statically allocated, fixed sized frames allow us to know the memory requirements of a component at compile time, and avoid the overhead associated with dynamic allocation.

Tasks w Perform the primary computation work w Atomic with respect to other tasks, and run to completion, but can be preempted by events w Allow the OS to allocate a single stack assigned to the currently executing task w Call lower level commands w Signal higher level events w Schedule other tasks within a component w Simulate concurrency using events

Commands w Non-blocking requests to lower level components w Deposit request parameters into a component’s frame, and post a task for later execution w Can also invoke lower level commands, but cannot block w To avoid cycles, commands cannot signal events w Return status to the caller

Events w Event handlers deal with hardware events (interrupts) directly or indirectly w Deposit information into a frame w Post tasks w Signal higher level events w Call lower level commands

AM_MSG_SEND_DONE AM_MSG_REC AM_SEND_MSG AM_POWER AM_INIT TOS Component Messaging Component Commands AM_RX_PACKET _DONE Internal State AM_TX_PACKET _DONE AM_SUB_INIT AM_SUB_POWER AM_SUB_TX_PACKET Internal Tasks Events //AM. comp// TOS_MODULE AM; ACCEPTS{ char AM_SEND_MSG(char addr, char type, char* data); void AM_POWER(char mode); char AM_INIT(); }; SIGNALS{ char AM_MSG_REC(char type, char* data); char AM_MSG_SEND_DONE(char success); }; HANDLES{ char AM_TX_PACKET_DONE(char success); char AM_RX_PACKET_DONE(char* packet); }; USES{ char AM_SUB_TX_PACKET(char* data); void AM_SUB_POWER(char mode); char AM_SUB_INIT(); };

Putting It All Together w The task scheduler is a simple FIFO scheduler. w The scheduler puts the processor to sleep when the task queue is empty. w Peripherals keep operating and can wake up the processor. w Communication across components takes the form of a function call. This results in low overhead, and allows compile time type checking.

Sample Application w The sample application is consisting of a number of sensors distributed within a localized area w Monitor temperature and light conditions w Periodically transmit measurements to a base station

Sample Application (cont) w Sensors can forward data for other sensors that are out of range of the base station w Dynamically determine the correct routing topology for the network Image courtesy Jason Hill et al

Internal Component Graph Ad hoc Routing Application application Active Messages packet Radio Packet Serial Packet Temp Radio byte UART I 2 C SW byte HW Photo bit Clocks RFM Slide courtesy Jason Hill et al

Ad hoc Routing w Base station periodically broadcasts route updates w Any sensors in range of this broadcast record the identity of the base station, and rebroadcast the update w Each sensor remembers the first update received in an era, and uses the source of the update as the destination for routing 2 data back to the base station 1 3 Base 0 2 1 Image courtesy Jason Hill et al

Resource requirements

Review w Component interface: n n commands accepts (implemented) commands uses events accepts (implemented) events uses Messaging Component Internal Tasks Internal State w Component implementation n functions that implement interface frame: internal state tasks: concurrency control Commands Events

Programming Model comp 3 comp 1: C code w Components n n n . comp: specification. C: behaviour. desc: select and wire w specification: n n n comp 2: . desc comp 4 n accepts commands uses commands signals events handles events application: . desc

Programming Model w 4 kinds of components: n n . desc only (ex: cnt_to_leds). C and. comp (ex: CLOCK). desc and. comp (ex: GENERIC_COMM). C, . comp and. desc (ex: INT_TO_RFM)

Programming Model w (4 th type) component : = interface (. comp) + implementation (. c) + wiring (. desc) <Comp. Name>. comp TOS_MODULE <Comp. Name>; ACCEPTS { // command_signatures }; HANDLES { // event_signatures }; USES { // command_signatures }; SIGNALS { // event_signatures };

Programming Model <Comp. Name>. c #include "tos. h" #include “<Comp. Name>. h" #define TOS_FRAME_TYPE TOS_FRAME_BEGIN(< Comp. Name >_frame) { // state declaration } TOS_FRAME_END(< Comp. Name >_frame); char TOS_COMMAND(<command_name)(){ // command implementation } char TOS_EVENT(<event_name>)(){ // event implementation }

Programming Model <Comp. Name>. desc // Component Selection INCLUDE { MAIN; <Comp. Name>; <Comp_I>; <Comp_J>; … }; // Wiring <Comp. Name>. <command> <Comp_I>. <command> … <Comp. Name>. <event> <Comp_J>. <event> …

TOS 101: the Blink example w example app that handles the clock events to update LEDs like a counter MAIN main_sub_init main_sub_start blink_init blink_start BLINK blink_sub_init clock_init CLOCK blink_clock_event blink_ledy_on blink_ledy_off clock_fire_event yellow_led_on yellow_led_off LED

TOS 101: the Blink example blink. desc include modules { MAIN; BLINK; CLOCK; LEDS; }; BLINK: BLINK_INIT BLINK: BLINK_START BLINK: BLINK_LEDy_on BLINK: BLINK_LEDy_off BLINK: BLINK_LEDr_on BLINK: BLINK_LEDr_off BLINK: BLINK_LEDg_on BLINK: BLINK_LEDg_off BLINK: BLINK_SUB_INIT BLINK: BLINK_CLOCK_EVENT MAIN: MAIN_SUB_INIT MAIN: MAIN_SUB_START LEDS: YELLOW_LED_ON LEDS: YELLOW_LED_OFF LEDS: RED_LED_ON LEDS: RED_LED_OFF LEDS: GREEN_LED_ON LEDS: GREEN_LED_OFF CLOCK: CLOCK_INIT CLOCK: CLOCK_FIRE_EVENT

TOS 101: the Blink example blink. comp TOS_MODULE BLINK; ACCEPTS{ //commands char BLINK_INIT(void); char BLINK_START(void); }; HANDLES{ // events void BLINK_CLOCK_EVENT(void); }; USES{ // commands char BLINK_SUB_INIT(char interval, char scale); char BLINK_LEDy_on(); char BLINK_LEDy_off(); char BLINK_LEDr_on(); char BLINK_LEDr_off(); char BLINK_LEDg_on(); char BLINK_LEDg_off(); }; SIGNALS{ //events };

TOS 101: the Blink example blink. c #include "tos. h" #include "BLINK. h" //Frame Declaration #define TOS_FRAME_TYPE BLINK_frame TOS_FRAME_BEGIN(BLINK_frame) { char state; } TOS_FRAME_END(BLINK_frame); /* BLINK_INIT: Clear all the LEDs and initialize state */ char TOS_COMMAND(BLINK_INIT)(){ TOS_CALL_COMMAND(BLINK_LEDr_off)(); TOS_CALL_COMMAND(BLINK_LEDy_off)(); TOS_CALL_COMMAND(BLINK_LEDg_off)(); VAR(state)=0; TOS_CALL_COMMAND(BLINK_SUB_INIT)(tick 1 ps); return 1; }

TOS 101: the Blink example blink. c (cont. ) /* BLINK_START: initialize clock component to generate periodic events. */ char TOS_COMMAND(BLINK_START)(){ return 1; } /* Clock Event Handler: Toggle the Red LED on each tick. */ void TOS_EVENT(BLINK_CLOCK_EVENT)(){ char state = VAR(state); if (state == 0) { VAR(state) = 1; TOS_CALL_COMMAND(BLINK_LEDr_on)(); } else { VAR(state) = 0; TOS_CALL_COMMAND(BLINK_LEDr_off)(); } }

nes. C Programming Language w Goals: n n pragmatic low-level language for programming motes intermediate language for future high-level languages

nes. C Programming Language comp 3 comp 1: module w Components: n n implementation - module: C behaviour - configuration: select and wire interfaces - comp 2: configuration provides interface requires interface comp 4 application: configuration

nes. C Programming Language w 2 kinds of components: n n configuration: was. desc and. comp module: was. C and. comp

nes. C Blink example blink. td (configuration) configuration Blink { } implementation { uses Main, Blink. M, Clock, Leds; Main. Simple. Init -> Blink. M. Simple. Init; Blink. M. Clock -> Clock; Blink. M. Leds -> Leds; }

nes. C Blink example blink. M. td (module) module Blink. M { provides { interface Simple. Init; } requires { interface Clock; interface Leds; } } implementation { bool state; command result_t Simple. Init. init() { state=FALSE; return SUCCESS; }. . .

nes. C Blink example blink. M. td (module). . . command result_t Simple. Init. start() { return call Clock. set. Rate(128, 6); } event result_t Clock. fire() { state = !state; if(state) call Leds. red. On(); else call Leds. red. Off(); } }

nes. C Programming Language w nesc 1 takes a component and: n n n checks nes. C errors checks (most) C errors generates one C-file for the application w avr-gcc compiles nesc 1 output n generated code has #line directives, so clean error messages

nes. C Programming Language Application C (Tiny. OS) nes. C Savings Blink 1092 796 27% Cnt. To. Leds 1170 972 17% Sense. To. Leds 1636 1086 34% Oscilloscope 2792 2230 20% Rfm. To. Leds 5226 4168 20% Generic. Base 4544 4632 -2% Cnt. To. Rfm 5220 4678 10% Cnt. To. Leds. And. Rfm 5544 4850 13% Chirp 5516 4948 10% EEPROMTest 7830 6220 21%

nes. C Programming Language w nes. C much nicer to use than Tiny. OS: n n n produces smaller code than Tiny. OS get rid of the macros for frames, commands, events eliminate wiring error through type checking simplify wiring by using interfaces increase modularity by separation of interfaces and modules

The Communication Subsystem Active Messages

Active Messages : Motivation w Legacy communication cannot be used : TCP/IP, sockets, routing protocols like OSPF n n Bandwidth intensive Centered on “stop and wait” semantics w Need real time constraints and low processing overhead

Active Messages w Integrating communication and computation w Matching communication primitives to hardware capabilities w Provides a distributed eventing model where networked nodes send events to each other w Closely fits the event-based model of Tiny. OS

Active Messages w Message contains : n n User-level handler to be invoked on arrival Data payload passed as argument w Message handlers executed quickly to prevent network congestion and provide adequate performance w Event-centric nature enables network communication to overlap with sensor-interaction

Active Message + Tiny. OS = Tiny Active Messages w Messaging is a component in Tiny. OS

Tiny Active Messages w Support for three basic primitives : n n n Best effort message transmission Addressing Dispatch w Three primitives necessary and sufficient w Applications build additional functionality on top

Tiny Active Messages - Details w Packet format

Tiny. DB-Design, Code and implementation

Tiny. DB-Overview w Tiny. DB is a query processing system for extracting information from a network of Tiny. OS sensors. w Tiny. DB provides a simple, SQL-like interface. w Tiny. DB provides a simple Java API for writing PC applications that query and extract data from the network

Tiny. DB-Overview Contd. . w Two Subsytems n Sensor Network Software l Sensor Catalog and Schema Manager l Query Processor l Memory Manager l Network Topology Manager n Java-based Client Interface

Architecture Tiny. DB GUI Tiny. DB Client API JDBC PC side Mote side 0 0 2 1 4 Sensor network Tiny. DB query processor 5 83 6 7 DBMS

Data Model w Entire sensor network as one single, infinitely-long logical table: sensors w Columns consist of all the attributes defined in the network w Typical attributes: n Sensor readings n Meta-data: node id, location, etc. n Internal states: routing tree parent, timestamp, queue length, etc. w Nodes return NULL for unknown attributes w On server, all attributes are defined in catalog. xml

Query Language (Tiny. SQL) SELECT <aggregates>, <attributes> [FROM {sensors | <buffer>}] [WHERE <predicates>] [GROUP BY <exprs> [HAVING having-list]] [EPOCH DURATION integer] [INTO <buffer>] [TRIGGER ACTION <command>]

Comparison with SQL w Single table in FROM clause w Only conjunctive arithmetic comparison predicates in WHERE and HAVING w No subqueries w No column alias in SELECT clause w Arithmetic expressions limited to column op constant w Only fundamental difference: EPOCH DURATION clause

Tiny. SQL Examples “Find the sensors in bright nests. ” Sensors 1 SELECT nodeid, nest. No, light FROM sensors WHERE light > 400 EPOCH DURATION 1 s Epoch Nodeid nest. No Light 0 1 17 455 0 2 25 389 1 1 17 422 1 2 25 405

Tiny. SQL Examples (cont. ) 2 SELECT AVG(sound) FROM sensors EPOCH DURATION 10 s “Count the number occupied nests in each loud region of the island. ” Epoch 3 SELECT region, CNT(occupied) region CNT(…) AVG(…) 0 North 3 360 0 South 3 520 GROUP BY region 1 North 3 370 HAVING AVG(sound) > 200 1 South 3 520 AVG(sound) FROM sensors EPOCH DURATION 10 s Regions w/ AVG(sound) > 200

Event-based Queries w ON event SELECT … w Run query only when interesting events happens w Event examples n n n Button pushed Message arrival Bird enters nest w Analogous to triggers but events are user-defined

Query over Stored Data w w w Named buffers in Flash memory Store query results in buffers Query over named buffers Analogous to materialized views Example: n n n CREATE BUFFER name SIZE x (field 1 type 1, field 2 type 2, …) SELECT a 1, a 2 FROM sensors EPOCH DURATION d INTO name SELECT field 1, field 2, … FROM name EPOCH DURATION d

Tree-based Routing w Tree-based routing n Used in: l l l n Query delivery Data collection In-network aggregation Relationship to indexing? Q: SELECT … A Q R: {…} B Q R: {…}Q Q D R: {…}Q E C Q Q R: {…} Q Q Q F Q

Power Management Approach Coarse-grained app-controlled communication scheduling Mote ID 1 … zzz … Epoch (10 s -100 s of seconds) … zzz … 2 3 4 5 time 2 -4 s Waking Period

Time Synchronization w All messages include a 5 byte time stamp indicating system time in ms n Synchronize (e. g. set system time to timestamp) with l l n Any message from parent Any new query message (even if not from parent) Punt on multiple queries w All nodes agree that the waking period begins when (system time % epoch dur = 0) n And lasts for WAKING_PERIOD ms w Adjustment of clock happens by changing duration of sleep cycle, not wake cycle.

Tiny. DB and the Java API w Tiny. DBNetwork n n send. Query() injects query into network abort. Query() stops a running query add. Result. Listener() adds a Result. Listener that is invoked for every Query. Result received remove. Result. Listener() w Sensor. Queryer n translate. Query() converts Tiny. SQL string into Tiny. DBQuery object w Key difference from JDBC: push vs. pull

Tiny. DB and Java API Contd. . w Tiny. DBQuery n n n a list of attributes to select a list of expressions over those attributes, where an expression is l a filter that discards values that do not match a boolean expression l an aggregate that combines local values with values from neighbors, and optionally includes a GROUP BY column. an SQL string that should correspond to the expressions listed above. w Query. Result n n A complete result tuple, or A partial aggregate result, call merge. Query. Result() to combine partial results

Tiny. DB and Java API Contd. . w Agg. Op w Sel. Op w Catalog w Command. Msgs

Tiny. DB Demo Application w Tiny. DBMain n n Opens AM (Active message) connection to serial port(“COM 1”) and uses it to initialize a TinyDBNetwork object. Allocates GUI objects Cmd. Frame and Query. Frame w Cmd. Frame - Sending Tiny. DB commands into the network w Main. Frame - Main GUI for building queries w Query. Field - Routines for handling attributes in the query builder w Result. Frame w Plot w Topology w Result Graph w Magnet Frame

Inside Tiny. DB Sensor Catalog and Schema Manager Query Processor Memory Manager Network Topology Manager

Component Diagram

Inside Tiny. DB w Schema-capabilities of motes in the system as a single virtual Database “table” w Tables-typed attributes , commands that can be run within query executor. w Query processing-sensor readings from each mote is placed in “tuples” (passed between motes for multihop routing and/or aggregation, or might be passed to the font end code) w Attr and command components

Inside Tiny. DB Contd. . Components: n n Tiny. DBAttr Tiny. DBCommand Tuple Query. Result

Tiny. DB Query Processing operators w Tuple. Router - Heart of Tiny. DB System The Tuple. Router component contains three main execution paths: n n n Handling of new query messages Result computation and propagation (each time a clock event goes off) Subtree result message handling

Tiny. DB Query Processing operators Contd. . w Network. query. Msg event- new queries w Query message-part of a query: either a single field (attribute) to retrieve, a single selection predicate to apply, or a single aggregation function. w parse. Query() – Compact representation of query. w Allocation of space given a parsed query w set. Sample. Rate() n n Deliver the tuples that were completed Decrement the counter for all queries Fetch data fields Route filled-in tuples to query operators. w Network. data. Msg event –Neighbour result arrival w Sel. Operator w Agg. Operator

Tiny. DB Multi. Hop Routing w Modular interface -Network. nc. The royting layers must provide the following methods. n n n n n command Query. Result. Ptr get. Data. Pay. Load(TOS Msg. Ptr msg) command Tiny. DBError send. Data. Message(TOS Msg. Ptr msg) command Query. Message. Ptr get. Query. Pay. Load(TOS Msg. Ptr msg) command Tiny. DBError send. Query. Message(TOS Msg. Ptr msg) event result t send. Query. Done(TOS Msg. Ptr msg, result t success): event result t send. Data. Done(TOS Msg. Ptr msg, result t success): event result t data. Sub(Query. Result. Ptr qres. Msg): event result t query. Sub(Query. Message. Ptr q. Msg): event result t snooped. Sub(Query. Result. Ptr qres. Msg, bool is. From. Parent, uint 16 t senderid)

Inside Tiny. DB SELECT T: 1, AVG: 225 AVG(temp) Queries Results T: 2, AVG: 250 WHERE light > 400 Multihop Network Query Processor Aggavg(temp) ~10, 000 Lines Embedded C Code Filter light > 400 got(‘temp’) ~5, 000 Lines. Samples (PC-Side) Java get (‘temp’) Tables Schema ~3200 Bytes RAM (w/ 768 byte heap) get. Temp. Func(…) ~58 k. B compiled Tiny. OS code (3 x larger than 2 nd largest Tiny. OS Program) Tiny. DB

Extending Tiny. DB w Why extending Tiny. DB? n n New sensors attributes New control/actuation commands New data processing logic aggregates New events w Analogous to concepts in object-relational databases

Tiny. Schema w Collection of Tiny. OS components that manages a small repository of named attributes, commands and events. w Attribute-similar to column in traditional database. w Command-stored procedure in a traditional database system. n n Actuation commands - physical actions on motes Tuning commands - adjust internal parameters w Event-capture asynchronous events in WSN, e. g, detection of a bird.

Tiny. Schema Contd. . w Attribute interfaces n n Stdcontrol (initialization) Attr. Register (create new non-constant attribute) Attr. Register. Const (create new constant attribute) Attr. Use (discover and use) w Command Interfaces n n n Stdcontrol (initialization) Command. Register (create new command) Command. Use (discover and use) w Event Interfaces n n n Std. Control (initialization) Event. Register (create new event) Event. Use (discover, signal)

Adding Attributes w Types of attributes n n n Sensor attributes: raw or processed sensor readings Introspective attributes: values from internal software or hardware states e. g parent node in routing tree, voltage, ram usage, etc. Constant attributes: constant values that can be statically or dynamically assigned to a mote, e. g. , nodeid, location, etc.

Adding Attributes (cont) w Interfaces provided by Attr component n n Std. Control: init, start, stop Attr. Register l l n command register. Attr(name, type, len) event get. Attr(name, result. Buf, error. Ptr) event set. Attr(name, val) command get. Attr. Done(name, result. Buf, error) Attr. Use l l l command start. Attr(attr) event start. Attr. Done(attr) command get. Attr. Value(name, result. Buf, error. Ptr) event get. Attr. Done(name, result. Buf, error) command set. Attr. Value(name, val)

Adding Attributes (cont) w Steps to adding attributes to Tiny. DB 1) 2) 3) 4) w Create attribute nes. C components Wire new attribute components to Tiny. DBAttr configuration Reprogram Tiny. DB motes Add new attribute entries to catalog. xml Constant attributes can be added on the fly through Tiny. DB GUI

Tiny. DB Aggregation Framework

Adding Aggregates (cont) w Step 2: add entry to catalog. xml <aggregate> <name>AVG</name> <id>5</id> <temporal>false</temporal> <reader. Class>net. tinyos. tinydb. Average. Class</reader. Class> </aggregate> w Step 3 (optional): implement reader class in Java n a reader class interprets and finalizes aggregate state received from the mote network, returns final result as a string for display.

Tiny. Sec

Tiny. Sec Architectural Features w Single shared global cryptographic key w Link layer encryption and integrity protection transparent to applications w Cryptography based on a block cipher K K K

Tiny. Sec Summary w Security properties n n n Access control (Only nodes that posses the shared key can participate in the network) Integrity (a message should only be accepted if it was not altered in transit) Confidentiality (the content of a message shoulb not be infered by unauthorized parties)

Tiny. Sec (The fact) Ø Integration Ø OS: Tiny. OS 1. 1. 0 Ø Processors: Mica, Mica 2 Dot using Atmel Processors Ø Radio: RFM TR 1000 and Chipcon CC 1000 Ø SIM: TOSSIM simulator Ø Implementation Ø 3000 lines of Nes. C code Ø RAM: 455 bytes (not an issue for applications, can be reduced to 256 bytes) Ø MEM: 7000 bytes of program space Ø Real time: Two priority Tiny. OS scheduling process (cryptographic computations must be completed by the time the radio finishes sending the start symbol) Ø Usage Ø Build: maintains a key file and uses a key from the file, includes the key at compile time. Ø Application: “make TINYSEC=true …” to enable Tiny. Sec-Auth.

Tiny. Sec (Interfaces) App Generic. Comm Secure. Generic. Comm Radio Making deployment easy: plug-n-play crypto + link-layer security

Tiny. Sec Interfaces w Tiny. Sec n Tiny. Sec. M: bridges radio stack and crypto libraries w Block. Cipher n 3 Implementations: RC 5 M, Skip. Jack. M, Identity. Cipher w Block. Cipher. Mode n CBCMode. M: handles cipher text stealing l No length expansion when encrypting data w MAC n CBCMACM: computes message authentication code using CBC

Tiny. Sec (Components) Interface: Tiny. Sec. M Radio Stack [Mica. High. Speed. Radio. M/ CC 1000 Radio. Int. M] CBC-MACM CBC-Mode. M Interface: Skip. Jack. M Block. Cipher. Info Ø Use a block cipher for both encryption & authentication Ø Skipjack is good for 8 -bit devices; low RAM overhead

TOSSIM

MOTIVATION w Embedded nature of sensor networks makes controlled experiments difficult w Development is complicated by motes' small form factor and limited accessibility in the field w Inspecting the internal state of programs on many remote nodes is laborious w Inspection that disturbs the reactive nature of a mote (ie. Breakpoint) can invalidate the observed behaviour

TOSSIM w TOSSIM: A discrete event simulator for Tiny. OS sensor networks w Provide high fidelity (reliability/accuracy) simulation of Tiny. OS applications w Debug, test and analyze algorithms in a controlled and repeatable manner w Key Requirements: Scalability, Completeness, Fidelity, Bridging

TOSSIM w Bridging n Implementations, not just algorithms w Completeness n Cover as many system interactions as possible w Fidelity n Capture these interactions at a very fine grain w Scalability n Examine behavior in dense or large networks (Largest sensor network ever deployed: 850 nodes)

TOSSIM w Scales to thousands of nodes w Simulates the Tiny. OS network at the bit level w Compiles directly from Tiny. OS code ('make pc') w Flexibility to replace parts of application component graph (ie. Packet level radio component) w Useful for prototyping and development (debugging, breakpoints etc. )

IMPLEMENTATION NOTES w Compiler support – nes. C (ncc) w Execution model – interrupts and events w Hardware - abstracts each resource as a component (ie. ADC, Clock, EEPROM, boot seq, radio stack) w Radio Models – can choose accuracy & complexity of model (allows for error-free transmission) w Communication services – mechanisms to allow PC apps to drive, monitor etc.

TOSSIM w What TOSSIM Doesn't do: n n Times interrupts, not execution time Does not model radio propogation Does not model power draw or energy consumption (but you can extend to track consumption (power/time stats) Interrupts are nonpreemptive

Tiny. Viz COMPONENTS w Communication subsystem w Event bus n Synchronization, information passing w Plug-ins n n Drawing, mote options Subscribe to events Send commands Maintain state w GUI n Drawing, user interaction

Tiny. Viz ARCHITECTURE

Visualizing Simulation

Actuating Simulation

This is the last slide ! w Time to wake up

http: //www. i 2 r. astar. edu. sg/icsd/Secure. Sensor/Document. html