You are on page 1of 78

TinyOS

Learning Objectives
Understand TinyOS the dominant open source operating systems for WSN
Hardware abstraction architecture (HAA) TinyOS architecture and component model Main characteristics of TinyOS 2

Understand NesC programmng Learn representative WSN applications

Prerequisites
Module 1 Basic concepts of Operating Systems Basic concepts of Object-oriented Design and Analysis Basic concepts of Computer Networks

Software Challenges - TinyOS


Power efficient
Put microcontroller and radio to sleep

Small memory footprint


Non-preemptable FIFO task scheduling

Efficient modularity
Function call (event and command) interface between commands

Application specific Concurrency-intensive operation


Event-driven architecture No user/kernel boundary
http://www.tinyos.net 4

TinyOS Hardware Abstraction Architecture (HAA)

Section 2.3 and Figure 2.5 of J. Polastre Dissertation: http://www.polastre.com/papers/polastre-thesis-final.pdf


[TinyOS_1]: Table 2 5

TinyOS Hardware Abstraction Architecture (HAA)

Ref: Figure 2.4 of J. Polastre Dissertation


http://www.polastre.com/papers/polastre-thesis-final.pdf

Traditional OS Architectures
Application 1 Application 2 Application 1 NFS Micro-kernel Scheduler IPC Scheduler HW VM I/O Monolith-kernel VM I/O HW

Problem with Large Scale Deeply embedded system.. Large memory & storage requirement Unnecessary and overkill functionality ( address space isolation, complex I/O subsystem , UI ) for our scenario. Relative high system overhead ( e.g, context switch ) Require complex and power consuming hardware support.

TinyOS Architecture Overview (1)


Scheduler Application Component I/O Application Component COMM . TinyOS Application Component .

NO Kernel Direct hardware manipulation NO Process management Only one process on the fly. NO Virtual memory Single linear physical address space NO Dynamic memory allocation Assigned at compile time NO Software signal or exception Function Call instead Goal: to strip down memory size and system overhead.

TinyOS Overview
Application = scheduler + graph of components
Compiled into one executable

Event-driven architecture Single shared stack No kernel/user space differentiation


Main (includes Scheduler) Application (User Components)

Actuating

Communication Sensing Communication Hardware Abstractions

TinyOS Component Model


Component has:
Frame (storage) Tasks: computation Interface:
Command Event
Messaging Component
Internal Tasks Internal State

Commands

Events

Frame: static storage model - compile time memory allocation (efficiency) Command and events are function calls (efficiency) [TinyOS_4]

10

Power Optimization
Energy is the most valuable resource All components must support low power modes (sleep) Low Duty cycle operation
Duty cycle - The proportion of time during which a device is operated

Get job done quickly and go to sleep!

Typical WSN Application


Periodic
Data Collection Network Maintenance Majority of operation
processing data acquisition communication

Triggered Events
Detection/Notification Infrequently occurs
Power

Long Lifetime
Months to Years without changing batteries Power management is the key to WSN success

sleep
Time 12

The mote revolution: Low Powr Wireless Sensor Network

wakeup

But must be reported quickly and reliably

Design Principles
Key to Low Duty Cycle Operation:
Sleep majority of the time Wakeup quickly start processing Active minimize work & return to sleep

The mote revolution: Low Powr Wireless Sensor Network

13

Minimize Power Consumption


Compare to Mica2: a MicaZ mote with AVR mcu and 802.15.4 radio Sleep Majority of the time Telos: 2.4mA MicaZ: 30mA Wakeup As quickly as possible to process and return to sleep Telos: 290ns typical, 6ms max MicaZ: 60ms max internal oscillator, 4ms external Active Get your work done and get back to sleep Telos: 4-8MHz 16-bit MicaZ: 8MHz 8-bit
The mote revolution: Low Powr Wireless Sensor Network 14

Power Consumption

Energy Consumption
Idle listen:receive:send = 1:1.05:1.4

TinyOS Radio Stack

[Introduction_2]: Figure 3

17

Code and Data Size Breakdown

[Introduction_2]: Table 2

18

WSN Protocol Stack

Ref: [Introduction_1] A Survey on Sensor Networks, IEEE Communications Magazine, Aug. 2002, pp. 102-114.

TinyOS 2
An operating system for tiny, embedded, and networked sensors NesC language
A dialect of C Language with extensions for components

Three Limitations
Application complexity High cost of porting to a new platform reliability

Little more that a non-preemptive scheduler Component-based architecture Event-driven


Ref: P. Levis, et al. T2: A Second Generation OS For Embedded Sensor Networks

TinyOS 2
Static binding and allocation
Every resource and service is bound at compile time and all allocation is static

Single thread of control Non-blocking calls

A call to start lengthy operation returns immediately the called component signals when the operation is complete Split phase See this link for one example http://docs.tinyos.net/index.php/Modules_and_the_TinyOS_Exe
Ref: P. Levis, et al. T2: A Second Generation OS For Embedded Sensor Networks Ref: [TinyOS_3] Section 2.1

TinyOS 2
The scheduler has a fixed-length queue, FIFO Task run atomically Interrupt handlers can only call code that has the async keyword Complex interactions among components Event In most mote applications, execution is driven solely by timer events and the arrival of radio messages ATmega128 has two 8-bit timers and two 16-bit timers
Ref: P. Levis, et al. T2: A Second Generation OS For Embedded Sensor Networks

TinyOS 2
sync code is non-preemptive,
when synchronous (sync) code starts running, it does not relinquish the CPU to other sync code until it completes

Tasks
enable components to perform general-purpose "background" processing in an application A function which a component tells TinyOS to run later, rather than now

The post operation places the task on an internal task queue which is processed in FIFO order Tasks do not preempt each other A Task can be preempted by a hardware interrupt See TinyOS lesson:
Modules and the TinyOS Execution Model

802.15.4 and CC2420


CC2420 hardware signals packet reception by triggering an interrupt The software stack is responsible for reading the received bytes out of CC2420s memory; The software stack sends a packet by writing it to CC2420s memory then sending a transmit command
Ref: P. Levis, et al. T2: A Second Generation OS For Embedded Sensor Networks

TinyOS 2
Platforms
MicaZ, Mica2, etc; Compositions of chips

Chips
MCU, radio, etc Each chip follows the HAA model, with a HIL implementation at the top

Ref: P. Levis, et al. T2: A Second Generation OS For Embedded Sensor Networks

TinyOS 2
A T2 packet has a fixed size data payload which exists at a fixed offset The HIL of a data link stack is an active message interface Zero-copy

Ref: P. Levis, et al. T2: A Second Generation OS For Embedded Sensor Networks

Scheduler in TinyOS 2.x

SchedulerBasicP.nc of TinyOS 2.x

TinyOS Serial Stack

Ref: P. Levis, et al. T2: A Second Generation OS For Embedded Sensor Networks

Device Drivers in T2

Virtualized Dedicated Shared


Ref: Section 3 of [Energy_1]

T2 Timer Subsystem
MCU comes with a wide variation of hardware timers
ATmega128: two 8-bit timers and two 16-bit times MSP430: two 16-bit timers

Requirement of Timer subsystem


Different sampling rates: one per day to 10kHz

[TinyOS_1]: Section 5

30

T2 Timer Subsystem
See interface at:
tos/lib/timer/Timer.nc

One Example TinyOS Application BlinkC


http://docs.tinyos.net/index.php/TinyOS_Tutor ials

One Example of Wiring

Ref: D. Gay, et al. Software Design Patterns for TinyOS

AppM

Ref: D. Gay, et al. Software Design Patterns for TinyOS

AppM

Ref: D. Gay, et al. Software Design Patterns for TinyOS

Sensor Interface

Ref: D. Gay, et al. Software Design Patterns for TinyOS

Initialize Interface

Ref: D. Gay, et al. Software Design Patterns for TinyOS

SensorC

Ref: D. Gay, et al. Software Design Patterns for TinyOS

AppC

Ref: D. Gay, et al. Software Design Patterns for TinyOS

Notation

CTP Routing Stack

Parameterized Interfaces
An interface array

Ref: D. Gay, et al. Software Design Patterns for TinyOS, Section 2.3

unique and uniqueCount


Want to use a single element of a parameterized interface and does not care which one, as long as no one else use it

Want to know the number of different values returned by unique

Ref: D. Gay, et al. Software Design Patterns for TinyOS, Section 2.4

async
Functions that can run preemptively are labeled with async keyword Command an async function calls and events an async function signals must be async All interrupt handlers are async atomic keyword
Race conditions, data races

section 4.5 "TinyOS Programming manual"

44

Generic Components and Typed Interface


Have at least one type parameter Generic Components are NOT singletons
Can be instantiated within an configuration Instantiated with the keyword new (Singleton components are just named)

Use a single timer to create up to 255 virtual timers generic module VirtualizeTimerC(typedef precision_tag, int max_timers)
Precision_tag: A type indicating the precision of the Timer being virtualized max_timers: Number of virtual timers to create.

Example - VirtualizeTimerC

How to use it?


Components new VirtualizeTimerC(TMilli, 3) as TimerA
This will allocate three timers

Components new VirtualizeTimerC(TMilli, 4) as TimerB


This will allocate three timers

Ref:
/tos/lib/timer/VirtualizeTimerC.nc Section 7.1 of TinyOS Programming Manual
/tos/lib/timer/VirtualizeTimerC.n 46

Virtualized Timer

Timer Stack on MicaZ/Mica2

Figure 4 of [TinyOS_1]

48

Timer Subsystem
HplTimer[0-3]C provide dedicated access to the two 8-bit and two 16-bit timers of ATmega128 MCU T2 subsystem is built over the 8-bit timer 0 Timer 1 is used for CC2420 radio

message_t
tos/types/message.h Ref. TEP 111 Every link layer defines its header, footer, and metadata structures

Relationship between CC1000 Radio Implementation and message_t


tos/chips/cc1000/CC1000Msg.h

Relationship between CC2420 Radio Implementation and message_t


tos/chips/cc2420/CC2420.h

Relationship between Serial Stack Packet Implementation and message_t


tinyos-2.x/tos/lib/serial/Serial.h

Active Message (AM)


Why do we need AM?
Because it is very common to have multiple services using the same radio to communicate AM layer to multiplex access to the radio

make micaz install,n


n: unique identifier for a node

Active Message
Every message contains the name of an event handler Sender Declaring buffer storage in a frame Naming a handler Requesting Transmission Done completion signal Receiver The event handler is fired automatically in a target node

No blocked or waiting threads on the receiver Behaves like any other events Single buffering Double Check!!!!!!!

TinyOS Component
Two types of components
Module: provide implementations of one or more interfaces Configuration: assemble other components together

TinyOS Component Model


Component has:
Frame (storage) Tasks: computation Interface:
Command Event
Messaging Component
Internal Tasks Internal State

Commands

Events

Frame: static storage model - compile time memory allocation (efficiency) Command and events are function calls (efficiency)

Structure of a Component

Command Handlers

Set of Tasks

Event Handlers

Frame
(containing state information)

TinyOS Component

TinyOS Two-level Scheduling


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

Events handle concurrent dataflows


Interrupts trigger lowest level events Events prempt tasks, tasks do not Events can signal events, call commands, or post tasks
Preempt POST Tasks FIFO commands commands Interrupts Hardware Time

events

TinyOS Applications
In most mote applications, execution is driven solely by timer events and the arrival of radio messages

How to Program motes Under TinyOS


make telosb install,n mib510,/dev/ttyUSB0 make telosb install,1 mib510,/dev/ttyUSB0

Representative WSN Applications


BaseStation Listen BlinkToRadio
One-hop WSN application to collect sensed values

OscilloScope
one-hop WSN application with GUI interface

MultiOscilloScopre
multihop WSN application

Octopus
multi-hop WSN application with a more dynamic display of network topology and data dissemination functions

Application Example - BaseStation, Listen and BlinkToRadio


UHCL Terminal 1 of PC B# java net.tinyos.tools.Listen -comm sf@140.158.130.239:9002 Option 3: Listen connects to remote SerialForwarder Lamar Terminal 1 of PC A# java net.tinyos.tools.Listen -comm serial@/dev/ttyUSB1:micaz Run BlinkToRadio MTS300 Option 1: Listen connects to local + MicaZ serial ports Internet MIB520 + MicaZ Run BaseStation PC A at Lamar Univ. with IP 140.158.130.239 Terminal 2 of PC A# java net.tinyos.sf.SerialForwarder -comm serial@/ dev/ttyUSB1:micaz Terminal 3 of PC A# java net.tinyos.tools.Listen -comm sf@localhost:9002 Option 2: Listen connects to SerialForwarder running on a local machine

PC B at UHCL Terminal 2 of PC B# java net.tinyos.sf.SerialForwarder -comm sf@140.158.130.239:9002 Terminal 3 of PC B# java net.tinyos.tools.Listen -comm sf@localhost:9002 Option 4: One local SerialForwarder connects to a remote SerialForwarder. Listen connects to local SerialForwarder

Application Example - Oscilloscope


UHCL Lamar Terminal 1 of PC A# export MOTECOM=serial@/dev/ ttyUSB1:micaz Terminal 1 of PC A# oscillloscope/ java/run Terminal 1 of PC B# java net.tinyos.tools.Listen -comm sf@140.158.130.239:9002 Option 3: Listen connects to remote SerialForwarder Run OscilloscopeC.nc

PC B at UHCL

MTS300 Option 1: Oscilloscope connects to + MicaZ local serial ports Internet MIB520 + MicaZ Run BaseStation PC A at Lamar Univ . with IP 140.158.130.239 Terminal 2 of PC A# java net.tinyos.sf.SerialForwarder -comm serial @/ dev/ttyUSB1:micaz Terminal 3 of PC A# export MOTECOM=sf@localhost:9002 Terminal 3 of PC A# oscilloscope/java/run Option 2: Oscilloscope connects to SerialForwarder running on a local machine

Terminal 3 of PC B# export MOTECOM=sf@140.158.130.239:9002 Terminal 3 of PC B# oscilloscope/java/run Option 4: oscilloscope connects to remote SerialForwarder

Add SENSORBOARD=mts300 in Makefile

Application Example MultihopOscilloscope


GUI Interface
Terminal 1 of PC# java
Run net.tinyos.sf.SerialForwarder MultihopOscilloscopeC .nc comm serial@/dev/ttyUSB 1:micaz

MTS300 + MicaZ
Run MultihopOscilloscopeC .nc

Terminal 2 of PC#
MultihopOscilloscope /java/run

MTS300 + MicaZ MIB520 + MicaZ

Run MultihopOscilloscopeC .nc

Text Interface
Terminal 3 of PC# java
net.tinyos.tools.Listen -comm serial @/dev/ttyUSB 1:micaz

MTS300 + MicaZ
Run MultihopOscilloscopeC .nc

Run MultihopOscilloscopeC .nc

MTS300 + MicaZ

1. Add SENSORBOARD=mts300 when compile 2. Based on MultihopOscilloscopeC .nc, the root id should be 0 2.a For root node: make micaz install,0 mib510 ,/dev/ttyUSB0 2.b For non-root node (e.g. node 1): make micaz install,1 mib510 ,/dev/ttyUSB0 3. chmod 666 /dev/USB* 4. Make sure the root node and non -root nodes are all running 5. How to configurate light, temperature sensors ? Modify: 5.a $TOSROOT/tos/platforms /micaz/DemoSensorC .nc 5.b $TOSROOT/tos/sensorboards /mts300/DemoSensorC .nc 5.c $TOSROOT/apps/MultihopOscilloscope /MultihopOscilloscopeAppC .nc

Application Example - MViz


UHCL
Terminal 1 of PC A#java net.tinyos.sf.SerialForwarder -comm serial @/dev/ttyUSB 1:micaz Terminal 2 of PC A#tos-mviz -comm sf@localhost:9002 -dir /opt/tinyos-2.x/ apps/MViz MVizMsg Run MViz

Lamar MTS300 + MicaZ MTS300 + MicaZ


Run MViz Run MViz

PC B at UHCL

Internet
Terminal 1 of PC B#tos-mviz -comm sf@140.158.130.239:9002 -dir /opt/ tinyos-2.x/apps/Mviz MVizMsg Terminal 2 of PC B#java net.tinyos.tools.Listen -comm sf@140.158.130.239:9002

MIB520 + MicaZ
PC A with IP: 140.158.130.239

MTS300 + MicaZ

MTS300 + MicaZ

Run MViz Run MViz 1. Add SENSORBOARD=mts300 when compile 2. Modify MVizSensorC.nc to add related sensors 3. Based on MultihopOscilloscopeC .nc, the root id should be 0 3.a For root node: make micaz install ,0 mib510 ,/dev/ttyUSB0 3.b For non-root node (e.g. node 1): make micaz install ,1 mib510,/dev/ttyUSB0 4. chmod 666 /dev/ttyUSB* 5. add CFLAGS += -DCC2420 _DEF_RFPOWER=3 in Makefile to change transmission power 6. How to configurate light , temperature sensors ? Modify: 6.a $TOSROOT/tos/platforms /micaz/DemoSensorC .nc 6.b $TOSROOT/tos/sensorboards /mts300/DemoSensorC .nc 6.c $TOSROOT /apps/Mviz/MVizSensorC .nc

MViz
University of Houston, Clear Lake Lamar University TelosB
Run MViz Run MViz

TelosB
Run MViz

Internet

TelosB

PC A with IP: 140 .158 .130 .239

TelosB
Run MViz

TelosB
Run MViz

Application Example - Octopus


Terminal 1 of PC# java net .tinyos.sf.SerialForwarder
-comm serial@/dev/ttyUSB1:micaz

Terminal 2 of PC# export MOTECOM =serial @/dev/


ttyUSB1:micaz

Terminal 2 of PC# java OctopusGui


Run Octopus Data Collection

Data Collection

MTS300 + MicaZ

MTS300 + MicaZ

Run Octopus Data Dissemination

MIB520 + MicaZ
Data Collection Data Dissemination Data Dissemination

Data Run Octopus Dissemination Data Collection Data Collection

Run Octopus

MTS300 + MicaZ

Data Dissemination

MTS300 + MicaZ
Run Octopus

http://csserver.ucd.ie/~rjurdak/Octopus.htm

Octopus
Data Collection Data Collection

TelosB

Run Octopus

TelosB

Run Octopus Data Dissemination

TelosB
Data Collection Data Dissemination Data Dissemination

Data Run Octopus Dissemination Data Collection Data Collection

TelosB

Run Octopus

Data Dissemination

TelosB
Run Octopus

BaseStation Listen - BlinkToRadio


Run BaseStation run java net .tinyos.tools.Listen comm serial@/dev/ttyUSB 0:telosb
TelosB Mote TelosB Mote

Run BlinkToRadio

OscilloScope
GUI Interface
1. run java net.tinyos.sf.SerialForwarder comm serial @/dev/ttyUSB0:telosb 2. Under Oscilloscope /java, run ./run Run BaseStation
TelosB Mote

Text Interface
1. run java net.tinyos.tools.Listen comm serial @/dev/ttyUSB 0:telosb

TelosB Mote

Run OscilloscopeC .nc

TelosB Mote

Run OscilloscopeC .nc

MultihopOscilloscope
GUI Interface
1. run java net .tinyos .sf.SerialForwarder -comm serial @/dev/ttyUSB0:telosb 2. Under MultihopOscilloscope /java, run ./run Run MultihopOscilloscopeC .nc
TelosB TelosB

Run MultihopOscilloscopeC .nc

Run MultihopOscilloscopeC .nc

Text Interface
1. run java net.tinyos.tools.Listen comm serial @/dev/ttyUSB 0:telosb

TelosB

TelosB

TelosB

Run MultihopOscilloscopeC .nc

Run MultihopOscilloscopeC .nc

MViz
UHCL
1. run java net.tinyos.sf.SerialForwarder -comm serial@/dev/ ttyUSB 0:telosb 2. run tos-mviz -comm sf@localhost:9002 -dir /opt/ tinyos-2.x/apps/MViz TelosB MVizMsg
Machine in UHCL

Lamar Univ.
Run MViz
TelosB TelosB

Run MViz

Run MViz

Internet
run tos-mviz -comm sf@140 .158 .130 .239 :9002 -dir /opt/ tinyos-2.x/apps/Mviz MVizMsg

TelosB

IP: 140.158.130.239

TelosB

TelosB

Run MViz

Run MViz

Octopus
1. run java net.tinyos .sf.SerialForwarder -comm serial@/dev/ ttyUSB0:telosb 2. run 2.a export MOTECOM=serial@/dev/ ttyUSB0:telosb 2.b java OctopusGui

Lamar Univ.
Run Octopus
TelosB TelosB

Run Octopus

Run Octopus
TelosB

IP: 140.158.130.239

TelosB

TelosB

Run Octopus

Run Octopus

Lab 1
a) Write a PingPong application that runs on two nodes. When a node boots, it sends a broadcast packet using the AMSend interface. When it receives a packet, it a) wait one second; b) sends a packet; c) toggle an LED whenever a node sends a packet.

Lab 2
b) Please add the reliable data transmission feature to the PingPong application from the Application and Link layer, respectively. Suppose that two motes A and B are talking to each other. I. Application Layer: When mote A sends a broadcast pack P to node B, mote A will start a timer T. When mote B receives the packet P, mote B will send an ACK to node A. b.1 If the timer T expires before mote A receives the ACK from mote B (either the packet P or the ACK is lost), mote A will retransmit the packet; b.2 If mote A receives the ACK from mote B before the timer T expires, mote A will do nothing when the timer T expires. b.3 If mote B receive a packet which has already been received (based on sequence number), node B just drop this packet. There is a sequence number included in the payload of the packet P. The sequence number starts from 0. When a packet P is received, the receiver will display the bottom three bits (through LEDs) of the sequence number in the packet P.

Lab 2 - continue
II. Link Layer: In TEP 126 (http://www.tinyos.net/tinyos2.x/doc/html/tep126.html), it says: PacketLink: This layer provides automatic retransmission functionality and is responsible for retrying a packet transmission if no acknowledgement was heard from the receiver. PacketLink is activated on a per-message basis, meaning the outgoing packet will not use PacketLink unless it is configured ahead of time to do so Therefore, as an alternative, you may also configure PacketLink to provide automatic retransmission functionality.

Assignment
1. What is the relationship among all the application components in the Oscilloscope application? 2. please give two examples of split-phase operations in TinyOS 2. 3. What is the usage of Active Message in TinyOS 2? 4. Why doesnt TinyOS 2 make every statement async?

You might also like