PPT

TinyOSTinyOS

Real-time and Embedded System Laboratory

Operating System for Networked Sensors

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


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


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


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


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


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


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


TinyDBTinyDB

Classroom 1

B.S. RoomClassroom 5Classroom 4

Classroom 3Classroom 2

22121

49325

43554

5648215103

22121

49325

43554

5648222121

4932543554

Query

NodeID Light Volume


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…


TinyDBTinyDB

Query WindowCommand Window

Status Window


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)


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.


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


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


TOSSIMTOSSIM

TinyViz is a Java based GUI for graphical simulations of nodes running TinyOS applications, behaving as a front-end for the TOSSIM simulator


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)


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


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


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


BOMBILLABOMBILLAArchitecture


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.

PPT

Documents

hardware events

lower level commands

layers of components

components frame

hardware modules

events short

handle events

higher level events