1

System Architecture Directions for Networked Sensors (TinyOS & Mica2)

Presented by Jang Young, Kim (Chris)

2

Outline Introduction & Motivation Networked Sensor Characteristics H/W & Power Tiny Operating System (TinyOS) TinyOS Design Components Evaluation Mica2 mote programming and TOSSIM Conclusion Discussion

3

Smart Dust

What is TinyOS ?

Operating system developed at UC Berkeley for use with sensor motes

Support sensor motes and ease development of sensor applications

Event-driven architecture Utilizes new programming language

called nesC Currently the standard in sensor OS

5

Networked Sensor

Smaller, cheaper, lower-power communication

Complete systems on a chip Integrated low-power communication Integrated low-power transducers

Networked sensor

6

Motivation General purpose operating systems are not

appropriate for sensor networks Sensor networks require a task specific OS Concurrency intensive Multiple flows move through sensor in parallel Modular design Components connect easily to facilitate

application specific additions/modifications

7

TinyOS

Missing technolygy : the system software support to manage and operate the device.

Address this problem TinyOS Concurrency intensive – several different

flows of data must be kept moving simultaneously

Efficient modularity – hardware specific and application specific components must snap together with little processing and storage overhead

8

TinyOS

178 bytes of memory Propagates events in the time it takes to

copy 1.25 bytes of memory Context switches in the time it takes to copy

6bytes of memory Supports two level scheduling

9

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

10

Small Physical size and low power consumption

Reducing the size and power required for a given capability are driving factors in the hardware design.

The software must make efficient use of processor and memory while enabling low power communication.

Concurrency-intensive Operation

Information may be simultaneously captured from sensors, manipulated, and streamed onto a network.

11

Limited Physical Parallelism and Controller Hierarchy

The number of independent controllers, the capabilities of the controllers, and the sophistication of the processor-memory-switch level interconnect are much lower than in conventional systems.

The sensor provides a primitive interface directly to a single-chip microcontroller.

In contrast, conventional systems distribute the concurrent processing over multiple levels of controllers.

12

Diversity in Desing and Usage

Sensor devices will tend to be application specific, rather than general purpose, and carry only the available hardware support actually needed for the application.

Robust Operation

This devices will be numerous, largely unattended, and expected to from an application which will be operational a large percentage of the time.

One of the ways of increasing reliability is to tolerate individual device failure.

13

Hardware Organization

Three sleep modes (idle, power down & power save)

Three LEDs to represent outputs Photo-sensor Radio Temperature Sensor Serial Port

14

Photograph and schematic for representative network sensor platform

It consists of a microcontroller with internal flash program memory, data SRAM and data EEPROM, connected to a set of actuator and sensor devices, including LEDs, a low-power radio transceiver, an analog photo-sensor, a digital temperature sensor, a serial port, and a small coprocessor unit.

15

Photograph and schematic for representative network sensor platform

CPU: 4MHz Memory: 8KB flash(data), 512 B SRAM

(program) Network: 19.2 Kbps

Input: temperature andlight sensors

Output: 3 LEDs Serial Interface

16

Three sleep modes (idle, power down & power save)

Idle, which just shuts off the processor.

Power down, which shuts off everything but the watchdog and asynchronous interrupt logic necessary to wake up.

Power save, which is similar to the one above, but leaves an asynchronous timer running.

17

Three LEDs represent outputs

Connected through general I/O ports.

Photo - Sensor

An analog input device which simple control lines.

18

Radio

The most important component. It represents an asynchronous input/output device with

hard real time constraints. Contains no buffering so each bit must be serviced by

the controller on time.

Serial Port

Represents an important asynchronous bit level device with byte-level controller support.

19

Power CharacteristicsBiggest energy drain is radio About 3 orders of magnitude between idle and inactive!

No transition costs documented

Active == Peak Load

20

TinyOS Overview Application = scheduler + graph of components

Compiled into one executable Event-driven architecture Single shared stack No kernel/user space differentiation

Communication

Application (User Components)

Main (includes Scheduler)

21

Tiny Microthreading OS (TinyOS)

Requirements (small physical size, modest active power load & tiny inactive load) An operating system framework is needed that will retain

these characteristics by managing the hardware capabilities effectively, while supporting concurrency-intensive operation in a manner that achieves efficient modularity and robustness.

Two-level scheduling structure

High levels of concurrency

22

Two-level scheduling structure

A small amount of processing associated with hardware events can be performed immediately while long running tasks are interrupted.

Hardware

Interrupts

eve

nts

commands

FIFO

TasksPOST

Preempt

Time

commands

23

Two-level scheduling structure

Tasks do computations Non-preemptive FIFO scheduling Bounded number of pending tasks

Events handle concurrent dataflows Interrupts trigger lowest level events Events preempt tasks, tasks do not Events can signal events, call commands, or post tasks

24

Two-level scheduling structure

Event and Task Tasks cannot preempt other tasks Single shared stack

Used by both interrupts and function calls Simple FIFO scheduler Events can preempt a task Events can preempt each other When idle, scheduler shuts down the node except for

clock

25

Tiny OS Design

Tiny Scheduler Components

Frame Tasks Event Handlers Command Handlers

Messaging Component

Internal StateInternal Tasks

Commands Events

26

Tiny OS Design

Frame It has information related to the current state of the system. Commands, events and tasks execute in the context of the frame.

Tasks Perform the primary work. They are atomic with respect to other tasks and run to completion,

though they can be preempted by events.

Event Handlers Invoked to deal with hardware events, either directly or indirectly.

Command Handlers Non-blocking requests made to lower level components.

27

Components

Messagin

g Com

pon

ent

init

Power(mode)

TX_packet(buf)

TX_packet_done (success)

RX_packet_done (buffer)

Intern

al State

init

power(mode)

send_msg(addr, type, data)

msg_rec(type, data)

msg_send_done (success)

send

_msg_th

read

Block of state

Events signal

commands Set of commands

handlers

28

/* Messaging Component Declaration */

//ACCEPTS: char TOS_COMMAND(AM_send_msg)(int addr, int type, char* data); void TOS_COMMAND(AM_power)(char mode); char TOS_COMMAND(AM_init)();

//SIGNALS: char AM_msg_rec(int 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 TOS_COMMAND(AM_SUB_TX_packet)(char* data); void TOS_COMMAND(AM_SUB_power)(char mode); char TOS_COMMAND(AM_SUB_init)();

29

Component Types

Send_message

TX_Packet

TX_byte

TX_Bit_Event

Msg_Send_Done

TX_Packet_Done

TX_Byte_Done

TX_Bit_Done

30

Component Types

Hardware Abstractions

- RFM Synthetic Hardware

- Radio Byte High Level Software

Components - messaging module

31

Component Types

Hardware Abstractions This component exports commands to manipulate the individual I/O pins

connected to the RFM transceiver and posts events informing other components about the transmission and reception of bits.

Its frame contains information about the current state of the component.

Synthetic Hardware It shifts data into or out of the underlying RFM module and signals when an

entire byte has completed. The internal tasks perform simple encoding and decoding of the data. Conceptually, this component is an enhanced state machine that could be

directly cast into hardware.

High Level Software Components It performs the function of filling in a packet buffer prior to transmission and

dispatches received messages to their appropriate place. Additionally, components that perform calculations on data or data

aggregation fall into this category.

32

Component Types

Two-level scheduler and directed graph of components Component parts Command handlers Respond to higher components Event handlers Respond to lower components Fixed-size frame Size of component is known at compile time Set of tasks Functions to do arbitrary

computation

33

Putting it All Together

A sample configuration of a networked sensor, and the routing topology created by a collection of distributed sensors.

Network sensorLight sensor Temperature sensor

The internal componentgraph of a base station sensor is shown along with the routing topology created by a collection of sensors.

34

Evaluation(1)Code and Data size Breakdown

Small Physical Size

Scheduler: 178 Bytes codeTotals: 3450 Bytes code

226 Bytes data

35

Evaluation(2)Time Breakdown

Concurrency-Intensive Operations

50 cycle thread overhead (6 byte copies)10 cycle event overhead (1.25 byte copes)

36

Evaluation(3) Time Breakdown

Efficient Modularity Events and commands can propagate through

components quickly. Total propagation delay: 40 us

Timing diagram of event propagation

37

Evaluation(4)Power Breakdown

Limited Physical Parallelism and Controller Hierarchy

Diversity in Usage and Robust Operation

What does this mean?Lithium Battery runs for 28 hours at peak load and years at minimum load!All its energy can only support 144KB data

Mica2 mote

Mica2 mote

MICA2 MOTE

Download TinyOS http://www.tinyos.net/tinyos-1.x/doc/install.html

Windows: Uses Cygwin environment to simulate Linux environment More complex than Linux installation (this took some

time) WARNING: TinyOS has problems with newer versions of

Cygwin and prefers older versions for proper functioning Linux:

Preferred as it’s native and faster; Easier setup Simply involves installing several RPMs (for Red Hat) Note that nesc-1.1-1.i386.rpm should be used (the

recommended nesc-1.1.2b-1.i386.rpm gives many compiler errors)

TinyOS installation Installs

nesC compiler and AVR package (processor dependant) Java JDK and Communications package TinyOS software/modules

TinyOS installation (Red Hat) can be found in /opt/tinyos-1.x/ /opt/tinyos-1.x/apps contains example components (such as

Blink) /opt/tinyos-1.x/tools/java contains many java applications that will

be useful later /opt/tinyos-1.x/tools/scripts contains toscheck which can be used

to check installation for correctness Also ensure that you change your PATH variable to include

Blink.ncBlink.nc consists of:

configuration Blink {}implementation {  components Main, BlinkM, SingleTimer, LedsC;

  Main.StdControl -> BlinkM.StdControl;  Main.StdControl -> SingleTimer.StdControl;  BlinkM.Timer -> SingleTimer.Timer;  BlinkM.Leds -> LedsC;}

Code(1)

  configuration Blink {  } Specifies this is a configuration file whose name is

Blink implementation {

Indicates that this is where we specify the actual configuration of the component

components Main, BlinkM, SingleTimer, LedsC; A listing of the set of components that this

configuration file references (makes use of)

Code(2) Main.StdControl -> SingleTimer.StdControl;

  Main.StdControl -> BlinkM.StdControl; Main is a component and StdControl is an interface it

uses -> symbol indicates that the component on the left “is

wired to” (OR the component on the left “uses”) the component on the right and carries with it two conditions: The component on the right must implement all the

functions provided by the component’s interface on the left The component on the left must implement event handlers

for all the events that the component on the right exports Hence, Main’s StdControl interface uses (is wired to) the

StdControl interfaces provided by (implemented by) both BlinkM and SingleTimer

StdControl Interface Anyone who provides the StdControl

Interface must implement the following 3 functions: StdControl.init(), StdControl.start() and 

StdControl.stop() When a mote is started, the first two

functions called are Main.StdControl.init() and Main.StdControl.start() Any modules who implement this interface and are

wired to Main in such a way also have their init and start functions called

The last function called is Main.StdControl.stop() and it will call all the stop functions it is wired to

Code   BlinkM.Timer ->

SingleTimer.Timer; Indicates the BlinkM module is wired to

the SingleTimer.Timer interface and hence can utilize all the commands it provides and now as the obligation to respond to any events it exports

  BlinkM.Leds -> LedsC;– Similar to the Timer interface, through this line, BlinkM is

now able to utilize the Leds interface (commands that can control the LED lights on the mote)

BlinkM.nc module BlinkM {

  provides {    interface StdControl;  }  uses {    interface Timer;    interface Leds;  }}// Code continued on next slide...

Indicates this is a module file (an implementation) that: Provides the StdControl interface (the init(), start() and

stop() functions) Uses the interfaces Timer and Leds (allows it to utilize

the commands and respond to the events generated by those interfaces)

BlinkM.nc 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();  } //Code continued on next slide…

This is the implementation of the module Init() is called when the module is first initialized. It initializes the Led

lights Start() is called when the module is first started. It starts a timer function

that will fire every 1000 milliseconds and repeats doing this till the stop command is called.

Stop() is called when the module is shut off and this stops the timer function

BlinkM.nc event result_t Timer.fired()

  {    call Leds.redToggle();    return SUCCESS;  }

}//end implementation Since BlinkM uses the timer interface, it must also

provide event handlers for the events that Timer exports Every time the timer fires, we call a command provided

by the Leds interface (a command which toggles the red LED)

Hence, we have created a module that blinks the red LED light on the mote once every second!

TOSSIM cd /opt/tinyos-1.x/apps/Blink - where the

Blink application example is stored make pc – compile the module for use in

TOSSIM simulation on the host pc ./build/pc/main.exe N -run simulation where

N is the number of nodes in the simulation OR ./build/pc/main.exe –rf=lossy.txt N –

where lossy.txt specifies the topology of the nodes By default, in TOSSIM, the nodes are all placed in

virtual reach of each other

Debugging

Debugging Place debug lines in code such as:

dbg(DBG_USR1, "processingRecieve from %d”, source)

export DBG=usr1 This will enable all dbg lines with

DBG_USR1 to be outputted to the screen during simulation runs

51

Conclusion

TinyOS is a highly modular software environment tailored to the requirements of Network Sensors, increasing efficiency, modularity and concurrency.

52

TinyOS Pros & Cons

Small memory footprint Non-preemptable FIFO task scheduling

Power efficient Put microcontroller and radio to sleep

Efficient modularity Function call (event, command) interface between components

Concurrency-intensive operations Event-driven architecture Efficient interrupts/events handling (function calls, no user/kernel

boundary) Real-time

Non-preemptable FIFO task scheduling No real-time guarantees or overload protection

53

TinyOS Pros & Cons

Lack real-time scheduling Urgent task may wait for non-urgent ones

Lack kernel protection Rely on compile-time analysis Programmer deals with H/W directly Dynamic memory allocation

Lack flexibility Static linking only Cannot change code online Cannot change part of the code

Lack virtual memory Physical memory used

......

54

Any Questions ?