Docstoc

TOS

Document Sample
TOS Powered By Docstoc
					 TinyOS
Operating System for Networked Sensors




         Real-time and Embedded System Laboratory
               Outline
Overview
Main Properties
Hardware Platforms
Design
Implementation
Wireless Network Communication: Active Messages
Important Subsystems & Tools
  TinyDB
  TASK
  TOSSIM
  Bombilla
  TinySec

Conclusions
                   Overview
 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 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”
                      Design
 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.
                     Design
 In TinyOS is talked then about bidirectional interface, referring
communication between components through events and commands.
                Design
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
                Design
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
  Return status to the caller
                 Design
EVENTS
  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
                   Design
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
                                                                                                       Design
                                                                                                                                     AM.comp




                                                                                                    AM_MSG_SEND_D
                                                                  AM_SEND_M
                                                     AM_POWER




                                                                                       AM_MSG_REC
               AM_INIT




                                                                                                                    TOS_MODULE AM;
                                                                                                                    ACCEPTS{
                                                                  SG



                                                                                                                     char AM_SEND_MSG(char addr, char type,


                                                                                                    ONE
                                                                                                                                 char* data);
Messaging Component
                                                                                                                     void AM_POWER(char mode);
                                                                                                                     char AM_INIT();
                                                                                                                    };
                                                                Internal Tasks   Internal State
                                                                                                                    SIGNALS{
                                  AM_SUB_TX_PACKET




                                                                                                                     char AM_MSG_REC(char type,
                   AM_SUB_POWER




                                                                                                                                 char* data);
                                                                                                    AM_RX_PACKET
                                                                                 AM_TX_PACKET




                                                                                                                     char AM_MSG_SEND_DONE(char success);
 AM_SUB_INIT




                                                                                                                    };
                                                                                                                    HANDLES{
                                                                                 _DONE


                                                                                                    _DONE




                                                                                                                     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();
                                                                                                                    };
       Implementation
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.
          Implementation
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 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
                 Implementation
EXAMPLE: Blink Application
Blink.nc                                           BlinkM.nc
  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()
StdControl.nc                                           { 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
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 Messages
INTERESTING USABILITY
    Routing:

       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)

    Broadcasting

       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
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 Messages
SOME FIGURES
                                                                        Time (msec)
             400
                                                   First bit of              0
             350                                   request on mote
             300                                   Last bit of             15.6
                                                   request on mote
RTT (msec)




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



• Throughput: ~800 bytes/sec (~6.5
  Kbps) with 4b6 encoding                               Power Consumption
                         TinyOS
                                                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
                                                Packet
                                                                                  356
                                                                                  334
                                                                                                       40
                                                                                                       40
                                                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 &
         Tools
TinyDB: The TinyDB "sensor network as database"
application
Bombilla (Maté): TinyOS virtual machine
MatchBox: Simple mote filing system
TASK: The TASK "Tiny Application Sensor Kit"
application
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
                   TinyDB
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
           Important Subsystems & Tools
                         TinyDB
Example:

     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
      EPOCH DURATION 5min
            Important Subsystems & Tools
                         TinyDB
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




                                                                           Query

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


   4   55   43       5   32    49
       Important Subsystems & Tools
                       TinyDB
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
         TinyDB




                           Status Window




   Query Window
                          Command Window
            Important Subsystems & Tools
                        TinyDB
Features:

    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
          Important Subsystems & Tools
                             TASK
TinyDB 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
                    TOSSIM
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
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
                   TOSSIM
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
                        TOSSIM
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
   applications.
   Radio model: Sets the bit error rate according to simulated location and two
   radio models (empirical and fixed radius)
         Important Subsystems & Tools
                BOMBILLA
Bombilla 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 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
                 BOMBILLA
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
Architecture
   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
               BOMBILLA
Architecture
         Important Subsystems & Tools
                      TinySec
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
             Conclusions
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.

				
DOCUMENT INFO