Tiny Microthreading Operating
System: TinyOS
Networked Sensor
Characteristics
 Small physical size and low power
consumption
 Concurrency-intensive operation
 Limited physical parallelism and controller
hierarchy
 Diversity in Design and Usage
 Robust Operation
Photograph and
schematic for the
Network
Sensor
The Solution: TinyOS
 A microthreaded OS that draws on previous work
done for lightweight thread support, and efficient
network interfaces
 Two level scheduling structure

Long running tasks that can be interrupted by hardware
events
 Small, tightly integrated design that allows
crossover of software components into hardware
TinyOS - Design
Components
Commands
Events
Scheduler
Events
Hardware components
Structure of a Component
Command Handlers
Set of Tasks
Event Handlers
Frame
(containing state information)
TinyOS Component
TinyOS Component Model
 Component has:
Frame (storage)
 Tasks (computation)
 Command and Event
Interface

Messaging Component
Internal Tasks
Commands
Internal State
Events
 To facilitate modularity, each component declares
the commands it uses and the events it signals.
 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
 Perform the primary computation work
 Atomic with respect to other tasks, and run to
completion, but can be preempted by events
 Allow the OS to allocate a single stack assigned to
the currently executing task
 Call lower level commands
 Signal higher level events
 Schedule other tasks within a component
 Simulate concurrency using events
Commands
 Non-blocking requests to lower level components
 Deposit request parameters into a component’s
frame, and post a task for later execution
 Can also invoke lower level commands, but cannot
block
 To avoid cycles, commands cannot signal events
 Return status to the caller
Events
 Event handlers deal with hardware events
(interrupts) directly or indirectly
 Deposit information into a frame
 Post tasks
 Signal higher level events
 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_POWER
AM_SUB_TX_PACKET
AM_SUB_INIT
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
 The task scheduler is a simple FIFO scheduler.
 The scheduler puts the processor to sleep when the
task queue is empty.
 Peripherals keep operating and can wake up the
processor.
 Communication across components takes the form
of a function call. This results in low overhead, and
allows compile time type checking.
Sample Application
 The sample application is consisting of a
number of sensors distributed within a
localized area
 Monitor temperature and light conditions
 Periodically transmit measurements to a base
station
Sample Application (cont)
 Sensors can forward
data for other sensors
that are out of range of
the base station
 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
I2C
SW
byte
HW
Photo
bit
Clocks
RFM
Slide courtesy Jason Hill et al
Ad hoc Routing
 Base station periodically broadcasts route updates
 Any sensors in range of this broadcast record the
identity of the base station, and rebroadcast the
update
 Each sensor remembers the first update received
in an era, and uses the source of the update as the
destination for routing data back to the base
2
station
1
3
Base
0
2
1
Image courtesy Jason Hill et al
Resource requirements
Review
 Component interface:




commands accepts (implemented)
commands uses
events accepts (implemented)
events uses
Messaging Component
Internal Tasks
Internal State
 Component implementation



functions that implement interface
frame: internal state
tasks: concurrency control
Commands
Events
Programming Model
comp3
comp1:
C code
 Components



.comp: specification
.C: behaviour
.desc: select and wire
 specification:



comp2:
.desc
comp4

accepts commands
uses commands
signals events
handles events
application:
.desc
Programming Model
 4 kinds of components:




.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
 (4th type) component := interface (.comp) +
implementation (.c) + wiring (.desc)
<CompName>.comp
TOS_MODULE <CompName>;
ACCEPTS {
// command_signatures
};
HANDLES {
// event_signatures
};
USES {
// command_signatures
};
SIGNALS {
// event_signatures
};
Programming Model
<CompName>.c
#include "tos.h"
#include “<CompName>.h"
#define TOS_FRAME_TYPE
TOS_FRAME_BEGIN(< CompName >_frame) {
// state declaration
}
TOS_FRAME_END(< CompName >_frame);
char TOS_COMMAND(<command_name)(){
// command implementation
}
char TOS_EVENT(<event_name>)(){
// event implementation
}
Programming Model
<CompName>.desc
// Component Selection
INCLUDE {
MAIN;
<CompName>;
<Comp_I>;
<Comp_J>;
…
};
// Wiring
<CompName>.<command> <Comp_I>.<command>
…
<CompName>.<event>
<Comp_J>.<event>
…
TOS 101: the Blink example
 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)(tick1ps);
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)();
}
}
nesC Programming Language
 Goals:


pragmatic low-level language for programming motes
intermediate language for future high-level languages
nesC Programming Language
comp3
comp1:
module
 Components:


implementation
- module: C behaviour
- configuration:
select and wire
interfaces
-
comp2:
configuration
provides interface
requires interface
comp4
application:
configuration
nesC Programming Language
 2 kinds of components:


configuration: was .desc and .comp
module: was .C and .comp
nesC Blink example
blink.td (configuration)
configuration Blink {
}
implementation {
uses Main, BlinkM, Clock, Leds;
Main.SimpleInit -> BlinkM.SimpleInit;
BlinkM.Clock -> Clock;
BlinkM.Leds -> Leds;
}
nesC Blink example
blinkM.td (module)
module BlinkM {
provides {
interface SimpleInit;
}
requires {
interface Clock;
interface Leds;
}
}
implementation {
bool state;
command result_t SimpleInit.init() {
state=FALSE; return SUCCESS;
}
...
nesC Blink example
blinkM.td (module)
...
command result_t SimpleInit.start() {
return call Clock.setRate(128, 6);
}
event result_t Clock.fire() {
state = !state;
if(state) call Leds.redOn();
else call Leds.redOff();
}
}
nesC Programming Language
 nesc1 takes a component and:



checks nesC errors
checks (most) C errors
generates one C-file for the application
 avr-gcc compiles nesc1 output

generated code has #line directives, so clean error
messages
nesC Programming Language
Application
C (TinyOS)
nesC
Savings
Blink
1092
796
27%
CntToLeds
1170
972
17%
SenseToLeds
1636
1086
34%
Oscilloscope
2792
2230
20%
RfmToLeds
5226
4168
20%
GenericBase
4544
4632
-2%
CntToRfm
5220
4678
10%
CntToLedsAndRfm
5544
4850
13%
Chirp
5516
4948
10%
EEPROMTest
7830
6220
21%
nesC Programming Language
 nesC much nicer to use than TinyOS:





produces smaller code than TinyOS
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
 Legacy communication cannot be used :
TCP/IP, sockets, routing protocols like OSPF


Bandwidth intensive
Centered on “stop and wait” semantics
 Need real time constraints and low
processing overhead
Active Messages
 Integrating communication and computation
 Matching communication primitives to
hardware capabilities
 Provides a distributed eventing model where
networked nodes send events to each other
 Closely fits the event-based model of
TinyOS
Active Messages
 Message contains :


User-level handler to be invoked on arrival
Data payload passed as argument
 Message handlers executed quickly to prevent
network congestion and provide adequate
performance
 Event-centric nature enables network
communication to overlap with sensor-interaction
Active Message + TinyOS =
Tiny Active Messages
 Messaging is a component in TinyOS
Tiny Active Messages
 Support for three basic primitives :



Best effort message transmission
Addressing
Dispatch
 Three primitives necessary and sufficient
 Applications build additional functionality on
top
Tiny Active Messages - Details
 Packet format
TinyDB-Design, Code and
implementation
TinyDB-Overview
 TinyDB is a query processing system for
extracting information from a network
of TinyOS sensors.
 TinyDB provides a simple, SQL-like
interface.
 TinyDB provides a simple Java API for
writing PC applications that query and
extract data from the network
TinyDB-Overview Contd..
 Two Subsytems
 Sensor Network Software
 Sensor Catalog and Schema Manager
 Query Processor
 Memory Manager
 Network Topology Manager
 Java-based Client Interface
Architecture
TinyDB GUI
TinyDB Client API
JDBC
PC side
Mote side
0
0
2
1
4
TinyDB query
processor
5
Sensor network
83
6
7
DBMS
Data Model
 Entire sensor network as one single, infinitely-long
logical table: sensors
 Columns consist of all the attributes defined in the
network
 Typical attributes:
 Sensor readings
 Meta-data: node id, location, etc.
 Internal states: routing tree parent, timestamp,
queue length, etc.
 Nodes return NULL for unknown attributes
 On server, all attributes are defined in catalog.xml
Query Language (TinySQL)
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
 Single table in FROM clause
 Only conjunctive arithmetic comparison predicates in
WHERE and HAVING
 No subqueries
 No column alias in SELECT clause
 Arithmetic expressions limited to column op constant
 Only fundamental difference: EPOCH DURATION clause
TinySQL Examples
“Find the sensors in bright
nests.”
Sensors
1
SELECT nodeid, nestNo, light
FROM sensors
WHERE light > 400
EPOCH DURATION 1s
Epoch
Nodeid
nestNo
Light
0
1
17
455
0
2
25
389
1
1
17
422
1
2
25
405
TinySQL Examples (cont.)
2 SELECT AVG(sound)
FROM sensors
EPOCH DURATION 10s
“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
FROM sensors
0
South
3
520
GROUP BY region
1
North
3
370
HAVING AVG(sound) > 200
1
South
3
520
AVG(sound)
EPOCH DURATION 10s
Regions w/ AVG(sound) > 200
Event-based Queries
 ON event SELECT …
 Run query only when interesting events happens
 Event examples



Button pushed
Message arrival
Bird enters nest
 Analogous to triggers but events are user-defined
Query over Stored Data





Named buffers in Flash memory
Store query results in buffers
Query over named buffers
Analogous to materialized views
Example:



CREATE BUFFER name SIZE x (field1 type1, field2 type2, …)
SELECT a1, a2 FROM sensors EPOCH DURATION d INTO name
SELECT field1, field2, … FROM name EPOCH DURATION d
Tree-based Routing
 Tree-based routing

Used in:




Query delivery
Data collection
In-network aggregation
Relationship to indexing?
Q:SELECT …
A
Q
R:{…}
Q
R:{…}
B
Q
R:{…}Q
Q
D
R:{…}Q
C
Q
Q
R:{…}
Q
Q
Q
F
E
Q
Power Management Approach
Coarse-grained app-controlled communication scheduling
Mote ID
1
… zzz …
Epoch (10s -100s of seconds)
… zzz …
2
3
4
5
time
2-4s Waking Period
Time Synchronization
 All messages include a 5 byte time stamp indicating system time in ms

Synchronize (e.g. set system time to timestamp) with



Any message from parent
Any new query message (even if not from parent)
Punt on multiple queries
 All nodes agree that the waking period begins when (system time %
epoch dur = 0)

And lasts for WAKING_PERIOD ms
 Adjustment of clock happens by changing duration of sleep cycle, not
wake cycle.
TinyDB and the Java API
 TinyDBNetwork




sendQuery() injects query into network
abortQuery() stops a running query
addResultListener() adds a ResultListener that is invoked for every
QueryResult received
removeResultListener()
 SensorQueryer

translateQuery() converts TinySQL string into TinyDBQuery
object
 Key difference from JDBC: push vs. pull
TinyDB and Java API Contd..
 TinyDBQuery



a list of attributes to select
a list of expressions over those attributes, where an expression is
 a filter that discards values that do not match a boolean
expression
 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.
 QueryResult


A complete result tuple, or
A partial aggregate result, call mergeQueryResult() to combine
partial results
TinyDB and Java API Contd..
 AggOp
 SelOp
 Catalog
 CommandMsgs
TinyDB Demo Application
 TinyDBMain


Opens AM (Active message) connection to serial port(“COM1”) and
uses it to initialize a Tiny\DBNetwork object.
Allocates GUI objects CmdFrame and QueryFrame
 CmdFrame - Sending TinyDB commands into the network
 MainFrame - Main GUI for building queries
 QueryField - Routines for handling attributes in the query
builder
 ResultFrame
 Plot
 Topology
 Result Graph
 Magnet Frame
Inside TinyDB
Sensor Catalog and Schema Manager
Query Processor
Memory Manager
Network Topology Manager
Component Diagram
Inside TinyDB
 Schema-capabilities of motes in the system as a
single virtual Database “table”
 Tables-typed attributes , commands that can be run
within query executor.
 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)
 Attr and command components
Inside TinyDB Contd..
Components:




TinyDBAttr
TinyDBCommand
Tuple
QueryResult
TinyDB Query Processing
operators
 TupleRouter - Heart of TinyDB System
The TupleRouter component contains three
main execution paths:



Handling of new query messages
Result computation and propagation (each time a
clock event goes off)
Subtree result message handling
TinyDB Query Processing
operators Contd..
 Network.queryMsg event- new queries
 Query message-part of a query: either a single field (attribute) to
retrieve, a single selection predicate to apply, or a single
aggregation function.
 parseQuery() – Compact representation of query.
 Allocation of space given a parsed query
 setSampleRate()




Deliver the tuples that were completed
Decrement the counter for all queries
Fetch data fields
Route filled-in tuples to query operators.
 Network.dataMsg event –Neighbour result arrival
 SelOperator
 AggOperator
TinyDB MultiHop Routing
 Modular interface -Network.nc. The royting layers must
provide the following methods.









command QueryResultPtr getDataPayLoad(TOS MsgPtr msg)
command TinyDBError sendDataMessage(TOS MsgPtr msg)
command QueryMessagePtr getQueryPayLoad(TOS MsgPtr msg)
command TinyDBError sendQueryMessage(TOS MsgPtr msg)
event result t sendQueryDone(TOS MsgPtr msg, result t success):
event result t sendDataDone(TOS MsgPtr msg, result t success):
event result t dataSub(QueryResultPtr qresMsg):
event result t querySub(QueryMessagePtr qMsg):
event result t snoopedSub(QueryResultPtr qresMsg, bool
isFromParent, uint16 t senderid)
Inside TinyDB
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
LinesSamples
(PC-Side)
Java
get (‘temp’) Tables
Schema
~3200 Bytes
RAM (w/ 768 byte heap)
getTempFunc(…)
TinyOS code
~58 kB compiled
(3x larger than 2nd largest TinyOS Program)
TinyDB
Extending TinyDB
 Why extending TinyDB?




New sensors  attributes
New control/actuation  commands
New data processing logic  aggregates
New events
 Analogous to concepts in object-relational
databases
TinySchema
 Collection of TinyOS components that manages a
small repository of named attributes, commands
and events.
 Attribute-similar to column in traditional database.
 Command-stored procedure in a traditional
database system.


Actuation commands - physical actions on motes
Tuning commands - adjust internal parameters
 Event-capture asynchronous events in WSN, e.g,
detection of a bird.
TinySchema Contd..
 Attribute interfaces




Stdcontrol (initialization)
AttrRegister (create new non-constant attribute)
AttrRegisterConst (create new constant attribute)
AttrUse (discover and use)
 Command Interfaces



Stdcontrol (initialization)
CommandRegister (create new command)
CommandUse (discover and use)
 Event Interfaces



StdControl (initialization)
EventRegister (create new event)
EventUse (discover, signal)
Adding Attributes
 Types of attributes



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)
 Interfaces provided by Attr component


StdControl: init, start, stop
AttrRegister





command registerAttr(name, type, len)
event getAttr(name, resultBuf, errorPtr)
event setAttr(name, val)
command getAttrDone(name, resultBuf, error)
AttrUse





command startAttr(attr)
event startAttrDone(attr)
command getAttrValue(name, resultBuf, errorPtr)
event getAttrDone(name, resultBuf, error)
command setAttrValue(name, val)
Adding Attributes (cont)

Steps to adding attributes to TinyDB
1)
2)
3)
4)

Create attribute nesC components
Wire new attribute components to TinyDBAttr
configuration
Reprogram TinyDB motes
Add new attribute entries to catalog.xml
Constant attributes can be added on the fly
through TinyDB GUI
TinyDB Aggregation
Framework
Adding Aggregates (cont)
 Step 2: add entry to catalog.xml
<aggregate>
<name>AVG</name>
<id>5</id>
<temporal>false</temporal>
<readerClass>net.tinyos.tinydb.AverageClass</readerClass>
</aggregate>
 Step 3 (optional): implement reader class in Java

a reader class interprets and finalizes aggregate state received from
the mote network, returns final result as a string for display.
TinySec
TinySec Architectural Features
 Single shared global cryptographic key
 Link layer encryption and integrity
protection  transparent to applications
 Cryptography based on a block cipher
K
K
K
TinySec Summary
 Security properties



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)
TinySec (The fact)
 Integration
 OS: TinyOS 1.1.0
 Processors: Mica, Mica2, Mica2Dot using Atmel Processors
 Radio: RFM TR1000 and Chipcon CC1000
 SIM: TOSSIM simulator
 Implementation
 3000 lines of NesC 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 TinyOS 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 TinySec-Auth.
TinySec (Interfaces)
App
App
GenericComm
SecureGenericComm
Radio
Radio
Making deployment easy:
plug-n-play crypto + link-layer security
TinySec Interfaces
 TinySec

TinySecM: bridges radio stack and crypto libraries
 BlockCipher

3 Implementations: RC5M, SkipJackM, IdentityCipher
 BlockCipherMode

CBCModeM: handles cipher text stealing

No length expansion when encrypting data
 MAC

CBCMACM: computes message authentication code using
CBC
TinySec (Components)
Interface:
TinySec
TinySecM
Radio Stack
[MicaHighSpeedRadioM/
CC1000RadioIntM]
CBC-MACM CBC-ModeM
Interface:
SkipJackM
BlockCipher
BlockCipherInfo
 Use a block cipher for both encryption & authentication
 Skipjack is good for 8-bit devices; low RAM overhead
TOSSIM
MOTIVATION
 Embedded nature of sensor networks makes controlled
experiments difficult
 Development is complicated by motes' small form
factor and limited accessibility in the field
 Inspecting the internal state of programs on many
remote nodes is laborious
 Inspection that disturbs the reactive nature of a
mote (ie. Breakpoint) can invalidate the observed
behaviour
TOSSIM
 TOSSIM: A discrete event simulator for
TinyOS sensor networks sensor networks
 Provide high fidelity (reliability/accuracy)
simulation of TinyOS applications
 Debug, test and analyze algorithms in a
controlled and repeatable manner
 Key Requirements: Scalability, Completeness,
Fidelity, Bridging
TOSSIM
 Bridging

Implementations, not just algorithms
 Completeness

Cover as many system interactions as possible
 Fidelity

Capture these interactions at a very fine grain
 Scalability

Examine behavior in dense or large networks
(Largest sensor network ever deployed: 850 nodes)
TOSSIM
 Scales to thousands of nodes
 Simulates the TinyOS network at the bit level
 Compiles directly from TinyOS code ('make
pc')
 Flexibility to replace parts of application
component graph (ie. Packet level radio
component)
 Useful for prototyping and development
(debugging, breakpoints etc.)
IMPLEMENTATION NOTES
 Compiler support – nesC (ncc)
 Execution model – interrupts and events
 Hardware - abstracts each resource as a
component (ie. ADC, Clock, EEPROM, boot
seq, radio stack)
 Radio Models – can choose accuracy &
complexity of model (allows for error-free
transmission)
 Communication services – mechanisms to
allow PC apps to drive, monitor etc.
TOSSIM
 What TOSSIM Doesn't do:




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
TinyViz COMPONENTS
 Communication subsystem
 Event bus

Synchronization, information passing
 Plug-ins




Drawing, mote options
Subscribe to events
Send commands
Maintain state
 GUI

Drawing, user interaction
TinyViz ARCHITECTURE
Visualizing Simulation
Actuating Simulation
This is the last slide !
 Time to wake up
http://www.i2r.astar.edu.sg/icsd/SecureSensor/Document.html