OutlineOutline Overview Main Properties Hardware Platforms Design Implementation Wireless Network Communication: Active Messages Important Subsystems & Tools
TinyDBTASKTOSSIMBombillaTinySec
Conclusions
OverviewOverview Component-based OS for sensor Networks modularity
Developed at UC Berkeley for their original sensors called Motes
Its open-source approach and has achieved a big community and tenths of side projects. Also its open and promising design have helped
Developed in their own language NesC
Optimised in terms of memory usage and energy efficiency, while supporting concurrency-intensive operations
Main PropertiesMain Properties Event Model
Perfect solution for high concurrency and small amount of memory space
Use CPU resources more efficiently
Division among events (short and with preemption capabilities) and tasks (longer and deferred, but can't preempt)
Two level scheduling
Designed to scale with technology trends due to its support for crossover of software components into hardware.
Hardware Hardware PlatformsPlatforms
Hardware differences between mote platforms affect software structure, networking capabilities and performance
Hardware Hardware PlatformsPlatforms
Next Generation Sensor Networks? - All in one chip - “Smart Dust”
DesignDesign Architecture of TinyOS consist of interacting components
and a task scheduler
3 entities exist that allow components to execute code and communicate among them:
Commands and Command Handlers Events and Event Handlers Tasks
Also a fixed-size and statically allocated frame exist per each component, representing its internal state and being operated by the 3 previous entities.
Components declare commands used and events signalled, creating a layers of components, where upper layers issue commands to lower layers and handle events coming from them.
DesignDesign In TinyOS is talked then about bidirectional interface,
referring communication between components through events and commands.
DesignDesign
Perform the primary computation workAtomic with respect to other tasks, and run to completion, but can be preempted by eventsAllow the OS to allocate a single stack assigned to the currently executing taskCall lower level commandsSignal higher level eventsSchedule other tasks within a componentSimulate concurrency using eventsAre queued in FIFO task scheduler
TASKS
DesignDesignCOMMANDS
Non-blocking requests to lower level componentsDeposit request parameters into a component’s frame, and post a task for later executionCan also invoke lower level commands, but cannot block Return status to the caller
DesignDesignEVENTS
Event handlers deal with hardware events (interrupts) directly or by lower layer componentsDeposit information into a frame and post tasks to the scheduler (similar to commands)Signal higher level eventsCall lower level commands
DesignDesignThree type of components
Hardware abstraction components Synthetic hardware components High-level software components
Interesting similarities of components with hardware modules in hardware description languages (i.e. VHDL) benefits for future hardware designs
DesignDesign
Messaging Component
AM_SUB_INIT
AM_SUB_POWER
AM_SUB_TX_PACKET
AM_TX_PACKET
_DONE
AM_RX_PACKET
_DONE
Internal State
AM_INIT
AM_POWER
AM_SEND_MSG
AM_MSG_REC
AM_MSG_SEND_DONE
Internal Tasks
Commands 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();};
ImplementationImplementationProprietary language based on CC language called NesCNesC
“A language for programming structured component-based applications, primarily intended for embedded systems such as sensor networks”
Two types of components in NesC:
Modules: Application code, implementing one or more interfaces Configurations: Wires components and, on a top level, assembles applications to produce and executable
TinyOS provide a wide variety of system components and some pre-built applications. Application development can start immediately.
ImplementationImplementationEXAMPLE: Blink ApplicationSimple application that causes the
red LED on the mote to turn on and off at 1Hz
Two components. A module called BlinkM.nc and a configuration called Blink.nc
Access to system components (ClockC and LedsC) which access the hardware
Main is the first component executed in any TinyOS application and must be indicated in its configuration file
ImplementationImplementationEXAMPLE: Blink Application
module BlinkM { provides { interface StdControl; } uses { interface Timer; interface Leds; }}
implementation { command result_t StdControl.init() { call Leds.init(); return SUCCESS; }
command result_t StdControl.start() { return call Timer.start(TIMER_REPEAT, 1000); }
command result_t StdControl.stop() { return call Timer.stop(); }
event result_t Timer.fired() { call Leds.redToggle(); return SUCCESS; } }
BlinkM.ncconfiguration Blink {}implementation { components Main, BlinkM, SingleTimer, LedsC;
Main.StdControl -> BlinkM.StdControl; Main.StdControl -> SingleTimer.StdControl; BlinkM.Timer -> SingleTimer.Timer; BlinkM.Leds -> LedsC;}
Blink.nc
interface StdControl { command result_t init(); command result_t start(); command result_t stop(); }}
StdControl.nc
Wireless Network
Communication Active Active MessagesMessages
Motivation: Existing solutions not applicable (bandwidth intensive, too complex packets, computational and energy demanding, stop & wait…)
Active Messages:
Simple, extensible paradigmWidely used in parallel and distributed systemsDistributed event model matching TinyOS design
Tiny Active Messages:
Wireless Network
Communication Active Active MessagesMessages
Messages contain the handler ID (globally unique byte) to be executed at destination. Special handlers:
Handler 0: Routing handler.Handler 255: List installed handlers
Mote handlers are invoked through events
Base Station mote (node connected to PC host) has the special destination address 0x7e (126)
Wireless Network
Communication Active Active MessagesMessages
Data payload (up to 28 bytes) is passed to the handler as an argument
Event-based architecture enables network communication to overlap with sensor interaction
Three basic primitives are supported:
Best effort message transmission Addressing (address checking) Dispatch (Handler invocation)
Sufficient for operation. Applications can build other functionality on top (encryption, flow control, fragmentation, error correction/detection… )
Wireless Network
Communication Active Active MessagesMessages
INTERESTING USABILITY
Routing:
Handler 0 forwards to next hopEach hop decreases N and forwards the packetLast hop (N=1) inserts destination handler (HF) into H0Hop’s addresses are stored (up to 4)
Broadcasting
Address 255 allows message broadcasting2-hope messages will discover all closest neighbors Returned packets hold those neighbors addressesPermits a method of route discovery
Wireless Network
Communication Active Active MessagesMessages
INTERESTING USABILITY Radio Reprogramming:
Mica2 and Mica2dot platforms can be reprogrammed (change the running application) by radio connection using AM
A Java application on the base station is used to send the program to one or several motes
A special & reserved handler is used in the motes to receive AMs for reprogramming
A special module has to be wired with applications.
Program is stored in external flash and motes’s IDs are in eeprom. An special boot loader, stored previously in processor’s program memory, executes to load and reboot the mote so new application will be run.
Wireless Network
Communication Active Active MessagesMessages
SOME FIGURES
0
50
100
150
200
250
300
350
400
0 1 2 3 4 5 6Hops
RT
T (
ms
ec
)
Power Consumption
• Throughput: ~800 bytes/sec (~6.5 Kbps) with 4b6 encoding
Time (msec) First bit of request on mote
0
Last bit of request on mote
15.6
First bit of reply sent from mote
16.4
Last bit of reply sent from mote
31.8
First bit of next request on mote
54.5
TinyOSTinyOSSOME OTHER FIGURES
Small Size:
Scheduler just 178 bytes
Complete applications need only around 4 Kb + application code
Concurrency: Low Overhead :Cost of posting
and event = cost of copying 1 byte of data
Even during periods of active communication with bite level processing, CPU is sleeping 50+% of the time
Component Name Code Size (bytes) Data Size (bytes)
Multihop router
AM_dispatch
AM_temperature
AM_light
AM
Packet
RADIO_byte
RFM
Photo
Temperature
UART
UART_packet
I2C_bus
88
40
78
146
356
334
810
310
84
64
196
314
198
0
0
32
8
40
40
8
1
1
1
1
40
8
Processor_init
TinyOS scheduler
C runtime
172
178
82
30
16
0
Total 3450 226Components CPU Utilization Energy (nj/Bit)
AM 0.20% 0.33Packet 0.51% 7.58Radio handler 12.16% 182.38Radio decode thread 2.48% 37.2RFM 30.08% 451.17Radio Reception - 1350Idle 54.75% -Total 100.00% 2028.66
Important Subsystems Important Subsystems & Tools& Tools
TinyDB: The TinyDB "sensor network as database" applicationBombilla (Maté): TinyOS virtual machineMatchBox: Simple mote filing systemTASK: The TASK "Tiny Application Sensor Kit" applicationTOSSIM: The TinyOS (PC) Simulation Environment MIG: Message Interface GeneratorMessage Center: Easy injection of arbitrary messages into a mote network TinySec: Secure communication on motes.
Important Subsystems & Tools
TinyDBTinyDB
Query process system SQL-like for extracting information from a network of TinyOS sensors
TinyDB provides an interface in the base station for query input
The query is spread and collected back to the base station
A set of attributes can be selected for the query
TinyDB component must be installed in each node to collect those attributes
An API is provided to embed TinyDB on user’s own applications
Important Subsystems & Tools
TinyDBTinyDB
Example:
Sensor equipped university buildingWhich classes are in use? light sensor reading from sensor’s room is above threshold l and volume sensor above vWriting an application in nesC to read network light sensors and route results to base station would be difficultWith TinyDB, we run its component on each sensor and equip them with a room number (i.e. node ID):
SELECT nodeID, AVERAGE(light), AVERAGE(volume)FROM sensorsGROUP BY nodeIDHAVING AVERAGE(light) > l AND AVERAGE(volume) > vEPOCH DURATION 5min
Important Subsystems & Tools
TinyDBTinyDB
Classroom 1
B.S. RoomClassroom 5Classroom 4
Classroom 3Classroom 2
22121
49325
43554
5648215103
22121
49325
43554
5648222121
4932543554
Query
NodeID Light Volume
Important Subsystems & Tools
TinyDBTinyDBComponents Overview
Sensor Network Software
Sensor Catalog and Schema ManagerQuery ProcessorMemory ManagerNetwork Topology
Java-based Client Interface
Network InterfaceClasses to build and transmit queriesA class to receive and parse query resultsA GUI for result display, query construct and visualize dynamic network topologies…
Important Subsystems & Tools
TinyDBTinyDBFeatures:
Multiple Queries: Allowance of multiple queries over the same motes at the same time
Triggers: Local command execution on some result (i.e. alarm sound on temperature over t)
Even-Based Queries: Queries starting on when a low-level event occurs.
Queries over Flash: Creating, inserting, retrieving and deleting tables in Flash memory
Power Management and Synchronization: Each sensor is on for the same period of time of every sample period. Allow power saving and long time battery life of sensors (i.e. 60 days for sampling periods of 30 seconds)
Important Subsystems & Tools
TASKTASKTinyDB is included into a toolkit called “Tiny Application Sensor Kit” (TASK)
Apart from TinyDB, TASK offers:
TASK Server: server process running on a sensor network gateway that acts as a proxy for the sensor network on the internet.TASK DBMS: A relational database that stores sensor readings, statistics… (currently only accepting PostgresSQL)Task Client Tools: including TASK Deployment Tool that helps users record sensor node metadata, TASK Configuration Tool that helps users choose data collection intervals and data filtering and aggregation criteria, and TASK Visualization Tool that helps users monitor the network health and sensor readings.TASK Field Tool: running on a PDA that help users diagnose and resolve problems in certain areas of the network in the field.
Important Subsystems & Tools
TOSSIMTOSSIM
TinyOS simulator able to simulate thousands of nodes simultaneously, while displaying its interaction and providing run-time configurable debugging output, allowing a user to examine the execution of an application from different perspectives without needing to recompile
PC application (executable) compiled directly from TinyOS with the option pc
TinyViz is a Java-based GUI that allows visualization and controlling the simulation as it runs, inspecting debug messages, radio and UART packets, etc
Important Subsystems & Tools
TOSSIMTOSSIM
TOSSIM runs originally in text mode, showing events output and debugging information that can be configured.
Accepts one single parameter: number of nodes to simulate, which will run the same application
Apart from the possibility to shift debugging modes, 4 debugging modes are reserved for user-specific messages:
dbg(<mode>, const char* format, ...);
As TOSSIM runs natively in the PC, traditional debugging tools, such as gdb (GNU debugger), can be used. However, event based nature of TinyOS (programmed with NesC and not C) makes debugging process not standard
Important Subsystems & Tools
TOSSIMTOSSIM
TinyViz is a Java based GUI for graphical simulations of nodes running TinyOS applications, behaving as a front-end for the TOSSIM simulator
Important Subsystems & Tools
TOSSIMTOSSIM
TinyViz builds its functionality with a set of plug-ins, software modules that watch for events coming from the simulation and react by drawing information on the display
Main plug-ins are provided with TinyOS installation, and the implementation is opened to user-made plug-ins that can be included later in the GUI. Implemented
Debug Messages: Generated by simulation and can be filteredSet Breakpoints: On a pattern matching bases on debug or radio messagesSent radio packets: Display only radio packets (also in debug messages)Radio links: Highlight active radio motes and sets arrows between communicating nodesSet location: Simulates node location for possible location services applications. Radio model: Sets the bit error rate according to simulated location and two radio models (empirical and fixed radius)
Important Subsystems & Tools
BOMBILLABOMBILLABombilla is a bytecode interpreter running on TinyOS, composed of several components that sit on top of several system components.
Bombilla is an stack-based architecture: no embedded addresses are required
Condensed high-level assembler instructions makes programs very short:
getvar 0 # Get heap variable 0pushc 1 # Push one onto operand stackadd # Add the one to the stored countercopy # Copy the new counter valuesetvar 0 # Set heap variable 0pushc 7and # Take bottom three bits of counterputled # Set the LEDs to these three bitshalt
Important Subsystems & Tools
BOMBILLABOMBILLAAdditionally, Bombilla has an automatic network forwarding mechanism that allow programs installed in one mote spread eventually to every node of the network security problem
Errors are caught at run time. When an error is triggered, system is stopped and debugging information sent through the UART
Bombilla also has a 16 variable heap to provide a shared variable workspace (to be accessed only by special instructions): Event handlers implicitly lock all shared resources they use, so no “race conditions” are possible
Important Subsystems & Tools
BOMBILLABOMBILLA
Bombilla programs are broken into capsules of 24 instructions, small enough to be retransmitted in a single radio message (AM) and eliminating the need of partial capsule buffering, saving RAM
Two kinds of capsules: event handlers (in response to an event) and subrutines (called from another capsules).
Each instruction is executed as a TinyOS task, allowing execution interleaving at instruction granularity.
Three execution context: clock, send and receive. Each context is associated with different events
Each context has two stacks: operand stack (instructions handling data) and return address stack (for subrutines).
Architecture
Important Subsystems & Tools
TinySecTinySecLink layer encryption mechanism for motes running TinyOS:
Access control and confidentiality: Only authorized nodes can participate in the networkIntegrity: Against man-in-the-middle attacksEase of use: Just an interface change
Each node participating in the communication has the same key specified at compile time. That key is used for data encryption and verification, applied to every AM leaving the node
An script is used to able TinySec on motes
GenericComm (TinyOS radio stack) is replaced with SecureGenericComm, which enables authenticity. To use encryption, application must use specific sendMsg commands, exported also by SecureGenericComm
ConclusionsConclusions
AND FINALLY…
TinyOS is a highly modular software environment tailored to the requirements of sensor networks needed of an efficient concurrency management
Its design makes possible an easy evolution to support new hardware features and architectures coming with new times
Its flexibility and popularity makes from TinyOS a safe solution to invest in. New features are constantly developed and new versions of the OS are being released every month.
Only certain limitations, such a simplistic Scheduling or lack of memory protection, exist. However, TinyOS, as the most popular (and open source) OS for sensor networks, assures a future fix of virtually any issue due to its extensive communicity.