Document Sample
TOS Powered By Docstoc
Operating System for Networked Sensors

         Real-time and Embedded System Laboratory
Main Properties
Hardware Platforms
Wireless Network Communication: Active Messages
Important Subsystems & Tools

 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

 Developed in their own language NesC

 Optimised in terms of memory usage and energy efficiency, while
supporting concurrency-intensive operations
          Main 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 Platforms

 Hardware differences between mote platforms affect software
structure, networking capabilities and performance
Hardware Platforms

       Next Generation Sensor Networks?
              - All in one chip
              - “Smart Dust”
 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
 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.
 In TinyOS is talked then about bidirectional interface, referring
communication between components through events and commands.
   Perform the primary computation work
   Atomic with respect to other tasks, and run
   to completion, but can be preempted by
   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
  Non-blocking requests to lower level
  Deposit request parameters into a
  component’s frame, and post a task for later
  Can also invoke lower level commands, but
  cannot block
  Return status to the caller
  Event handlers deal with hardware events
  (interrupts) directly or by lower layer components
  Deposit information into a frame and post tasks to
  the scheduler (similar to commands)
  Signal higher level events
  Call lower level commands
Three 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



                                                                                                                    TOS_MODULE AM;

                                                                                                                     char AM_SEND_MSG(char addr, char type,

                                                                                                                                 char* data);
Messaging Component
                                                                                                                     void AM_POWER(char mode);
                                                                                                                     char AM_INIT();
                                                                Internal Tasks   Internal State

                                                                                                                     char AM_MSG_REC(char type,

                                                                                                                                 char* data);

                                                                                                                     char AM_MSG_SEND_DONE(char success);



                                                                                                                     char AM_TX_PACKET_DONE(char success);
                                                                                                                     char AM_RX_PACKET_DONE(char* packet);
Commands                                                                         Events                             USES{
                                                                                                                     char AM_SUB_TX_PACKET(char* data);
                                                                                                                     void AM_SUB_POWER(char mode);
                                                                                                                     char AM_SUB_INIT();
Proprietary language based on C language called NesC

 “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.
EXAMPLE: Blink Application
  Simple application that causes
  the red LED on the mote to turn
  on and off at 1Hz

  Two components. A module
  called and a
  configuration called

  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
EXAMPLE: Blink Application                                 
  configuration Blink {                             module BlinkM {
  }                                                   provides { interface StdControl; }
  implementation {                                    uses { interface Timer; interface Leds; }}
    components Main, BlinkM, SingleTimer, LedsC;
                                                    implementation {
      Main.StdControl -> BlinkM.StdControl;
                                                        command result_t StdControl.init()
      Main.StdControl -> SingleTimer.StdControl;
                                                        { call Leds.init(); return SUCCESS; }
      BlinkM.Timer -> SingleTimer.Timer;
      BlinkM.Leds -> LedsC;
                                                        command result_t StdControl.start()
                                                         { return call Timer.start(TIMER_REPEAT, 1000); }

                                                        command result_t StdControl.stop()                                           { return call Timer.stop(); }
  interface StdControl {
    command result_t init();                             event result_t Timer.fired()
    command result_t start();                           { call Leds.redToggle(); return SUCCESS; }
    command result_t stop(); }}                     }
Wireless Network Communication
         Active Messages
Motivation: Existing solutions not applicable (bandwidth
intensive, too complex packets, computational and energy
demanding, stop & wait…)

Active Messages:

  Simple, extensible paradigm
  Widely used in parallel and distributed systems
  Distributed event model matching TinyOS design

Tiny Active Messages:
Wireless Network Communication
        Active Messages

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 Messages
Data payload (up to 28 bytes) is passed to the handler as an

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 Messages

       Handler 0 forwards to next hop
       Each hop decreases N and forwards the packet
       Last hop (N=1) inserts destination handler (HF) into H0
       Hop’s addresses are stored (up to 4)


       Address 255 allows message broadcasting
       2-hope messages will discover all closest neighbors
       Returned packets hold those neighbors addresses
       Permits a method of route discovery
  Wireless Network Communication
           Active Messages
   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 Messages
                                                                        Time (msec)
                                                   First bit of              0
             350                                   request on mote
             300                                   Last bit of             15.6
                                                   request on mote
RTT (msec)

                                                   First bit of reply      16.4
             200                                   sent from mote
             150                                   Last bit of reply       31.8
                                                   sent from mote
                                                   First bit of next       54.5
              50                                   request on mote
                   0   1    2     3    4   5   6

• Throughput: ~800 bytes/sec (~6.5
  Kbps) with 4b6 encoding                               Power Consumption
                                                Component Name     Code Size (bytes)    Data Size (bytes)
SOME OTHER FIGURES                              Multihop router                    88                   0
                                                AM_dispatch                        40                   0
                                                AM_temperature                     78                  32
                                                AM_light                          146                   8
Small Size:                                     AM
                                                RADIO_byte                        810                   8
                                                RFM                               310                   1
  Scheduler just 178 bytes                      Photo                              84                   1
                                                Temperature                        64                   1
                                                UART                              196                   1
  Complete applications need only               UART_packet                       314                  40
 around 4 Kb + application code                 I2C_bus                           198                   8
                                                Processor_init                    172                  30
                                                TinyOS scheduler                  178                  16
                                                C runtime                          82                   0
Concurrency:                                    Total                           3450                  226

                                               Components           CPU Utilization      Energy (nj/Bit)
  Low Overhead :Cost of posting and       AM                                  0.20%                  0.33
 event = cost of copying 1 byte of data   Packet                              0.51%                  7.58
                                          Radio handler                      12.16%               182.38
   Even during periods of active          Radio decode thread                 2.48%                  37.2
                                          RFM                                30.08%               451.17
 communication with bite level
                                          Radio Reception                           -               1350
 processing, CPU is sleeping 50+% of      Idle                               54.75%                      -
 the time                                 Total                             100.00%              2028.66
Important Subsystems &
TinyDB: The TinyDB "sensor network as database"
Bombilla (Maté): TinyOS virtual machine
MatchBox: Simple mote filing system
TASK: The TASK "Tiny Application Sensor Kit"
TOSSIM: The TinyOS (PC) Simulation Environment
MIG: Message Interface Generator
Message Center: Easy injection of arbitrary
messages into a mote network
TinySec: Secure communication on motes.
       Important Subsystems & Tools
Query process system SQL-like for extracting information
from a network of TinyOS sensors

TinyDB provides an interface in the base station for query

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
           Important Subsystems & Tools

     Sensor equipped university building
     Which classes are in use?  light sensor reading from sensor’s
     room is above threshold l and volume sensor above v
     Writing an application in nesC to read network light sensors and
     route results to base station would be difficult
     With 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 sensors
      GROUP BY nodeID
      HAVING AVERAGE(light) > l AND AVERAGE(volume) > v
            Important Subsystems & Tools
Classroom 1      Classroom 2                 Classroom 3

                                    2   48     56
                                                                3   10    15
   1   12   22                      4   55     43
                                                                2   48    56
                                    5   32     49
                                                                4   55    43
                                    1   12     22
                                                                5   32    49
                                                                1   12    22


Classroom 4      Classroom 5                        B.S. Room       NodeID Light Volume

   4   55   43       5   32    49
       Important Subsystems & Tools
Components Overview
    Sensor Network Software
      Sensor Catalog and Schema Manager
      Query Processor
      Memory Manager
      Network Topology

    Java-based Client Interface
      Network Interface
      Classes to build and transmit queries
      A class to receive and parse query results
      A GUI for result display, query construct and visualize dynamic
      network topologies
Important Subsystems & Tools

                           Status Window

   Query Window
                          Command Window
            Important Subsystems & Tools

    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

    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
          Important Subsystems & Tools
TinyDB is included into a toolkit called “Tiny Application Sensor Kit”

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
   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
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
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
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
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 filtered
   Set Breakpoints: On a pattern matching bases on debug or radio messages
   Sent radio packets: Display only radio packets (also in debug messages)
   Radio links: Highlight active radio motes and sets arrows between
   communicating nodes
   Set location: Simulates node location for possible location services
   Radio model: Sets the bit error rate according to simulated location and two
   radio models (empirical and fixed radius)
         Important Subsystems & Tools
Bombilla is a bytecode interpreter running on TinyOS, composed
of several components that sit on top of several system

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 0
   pushc 1      # Push one onto operand stack
   add          # Add the one to the stored counter
   copy         # Copy the new counter value
   setvar 0     # Set heap variable 0
   pushc 7
   and          # Take bottom three bits of counter
   putled       # Set the LEDs to these three bits
        Important Subsystems & Tools
Additionally, 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
   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).
       Important Subsystems & Tools
         Important Subsystems & Tools
Link layer encryption mechanism for motes running TinyOS:

      Access control and confidentiality: Only authorized nodes can
      participate in the network
      Integrity: Against man-in-the-middle attacks
      Ease 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
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
                  AND FINALLY…
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.