tinyos. learning objectives understand tinyos – the dominant open source operating systems for wsn...

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

http://www.tinyos.net 4

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

[TinyOS_1]: Table 2 5

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 Hardware Abstraction Architecture (HAA)

Ref: Figure 2.4 of J. Polastre Dissertation http://www.polastre.com/papers/polastre-thesis-final.pdf

Traditional OS Architectures

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.

VM I/O Scheduler

Application 1 Application 2

Monolith-kernel

HW

NFS I/O

Scheduler

Application 1

Micro-kernel

HW

IPC VM

NO Kernel Direct hardware manipulationNO Process management Only one process on the fly.NO Virtual memory Single linear physical address space NO Dynamic memory allocation Assigned at compile timeNO Software signal or exception Function Call instead

Goal: to strip down memory size and system overhead.

TinyOS Architecture Overview (1)

I/O COMM . …….

Scheduler TinyOS

Application Component



TinyOS Overview• Application = scheduler + graph of components

– Compiled into one executable

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

CommunicationActuating Sensing Communication

Application (User Components)

Main (includes Scheduler)

Hardware Abstractions

[TinyOS_4] 10

TinyOS Component Model

• Component has:– Frame (storage)

– Tasks: computation

– Interface: • Command

• Event

• Frame: static storage model - compile time memory allocation (efficiency)

• Command and events are function calls (efficiency)

Messaging Component

Internal StateInternal Tasks

Commands Events

The mote revolution: Low Powr Wireless Sensor Network Devices, Hot Chips 2004

12

Typical WSN Application

• Periodic– Data Collection– Network Maintenance– Majority of operation

• Triggered Events– Detection/Notification– Infrequently occurs

• But… must be reported quickly and reliably

• Long Lifetime– Months to Years without

changing batteries– Power management is the key

to WSN success

sleep

wak

eup

processingdata acquisitioncommunication

Po

wer

Time


13

Design Principles

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


14

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

Power Consumption

Energy Consumption

• Idle listen:receive:send = 1:1.05:1.4

[Introduction_2]: Figure 3 17

TinyOS Radio Stack

[Introduction_2]: Table 2 18

Code and Data Size Breakdown

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_Execution_Model • Ref: P. Levis, et al. “T2: A Second Generation OS For Embedded Sensor Networks”

• Ref: [TinyOS_3] Section 2.1

http://docs.tinyos.net/index.php/Modules_and_the_TinyOS_Execution_Model

http://docs.tinyos.net/index.php/Modules_and_the_TinyOS_Execution_Model

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


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 CC2420’s memory;

• The software stack sends a packet by writing it to CC2420’s memory then sending a transmit command


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


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


Scheduler in TinyOS 2.x

SchedulerBasicP.nc of TinyOS 2.x

TinyOS Serial Stack


Device Drivers in T2

• Virtualized• Dedicated• Shared

• Ref: Section 3 of [Energy_1]

[TinyOS_1]: Section 5 30

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

T2 Timer Subsystem

• See interface at:– tos/lib/timer/Timer.nc

One Example TinyOS Application - BlinkC

• http://docs.tinyos.net/index.php/TinyOS_Tutorials

One Example of Wiring

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

AppM


Sensor Interface


Initialize Interface


SensorC


AppC


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

section 4.5 "TinyOS Programming manual"

44

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

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)

/tos/lib/timer/VirtualizeTimerC.n 46

Example - VirtualizeTimerC• 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.

• 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”

Virtualized Timer

Figure 4 of [TinyOS_1] 48

Timer Stack on MicaZ/Mica2

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

• Frame: static storage model - compile time memory allocation (efficiency)

• Command and events are function calls (efficiency)

Messaging Component

Internal StateInternal Tasks

Commands Events

Structure of a Component

TinyOS Component

Command Handlers

Event Handlers

Set of Tasks

Frame (containing state information)

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

Hardware

Interrupts

eve

nts

commands

FIFO

TasksPOST

Preempt

Time

commands

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

MIB520 + MicaZ Run

BaseStation

MTS300 + MicaZ

Run BlinkToRadio

PC A at Lamar Univ. with IP 140.158.130.239

Lamar

PC B at UHCL

UHCL

Terminal 1 of PC A# java net.tinyos.tools.Listen -comm serial@/dev/ttyUSB1:micaz

Option 1: Listen connects to local serial ports

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

Terminal 1 of PC B# java net.tinyos.tools.Listen -comm [email protected]:9002

Option 3: Listen connects to remote SerialForwarder

Terminal 2 of PC B# java net.tinyos.sf.SerialForwarder -comm [email protected]: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

Internet

Application Example - Oscilloscope

MIB520 + MicaZ Run

BaseStation

MTS300 + MicaZ

PC A at Lamar Univ. with IP 140.158.130.239

Lamar

PC B at UHCL

UHCL

Terminal 1 of PC A# export MOTECOM=serial@/dev/ttyUSB1:micazTerminal 1 of PC A# oscillloscope/java/run

Option 1: Oscilloscope connects to local serial ports

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

Terminal 3 of PC A# export MOTECOM=sf@localhost:9002Terminal 3 of PC A# oscilloscope/java/run

Option 2: Oscilloscope connects to SerialForwarder running on a local machine

Terminal 1 of PC B# java net.tinyos.tools.Listen -comm [email protected]:9002

Option 3: Listen connects to remote SerialForwarder

Terminal 3 of PC B# export [email protected]:9002Terminal 3 of PC B# oscilloscope/java/run

Option 4: oscilloscope connects to remote SerialForwarder

Internet

Run OscilloscopeC.nc

Add SENSORBOARD=mts300 in Makefile

Application Example - MultihopOscilloscope

Run MultihopOscilloscopeC.nc



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

Terminal 2 of PC# MultihopOscilloscope/java/run

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



Terminal 3 of PC# java net.tinyos.tools.Listen -comm serial@/dev/ttyUSB1:micaz

GUI Interface

Text Interface

MTS300 + MicaZ

MTS300 + MicaZ

MTS300 + MicaZ

MTS300 + MicaZ

MIB520 + MicaZ

Application Example - MViz

Internet

Run MViz

Run MViz

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

Run MViz

Run MViz

PC A with IP: 140.158.130.239

PC B at UHCL

LamarUHCL

MIB520 + MicaZ

MTS300 + MicaZ

MTS300 + MicaZ

MTS300 + MicaZ

MTS300 + MicaZ

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

Terminal 2 of PC A#tos-mviz -comm sf@localhost:9002 -dir /opt/tinyos-2.x/apps/MViz MVizMsg

Run MViz

Terminal 1 of PC B#tos-mviz -comm [email protected]:9002 -dir /opt/tinyos-2.x/apps/Mviz MVizMsg

Terminal 2 of PC B#java net.tinyos.tools.Listen -comm [email protected]:9002

MViz

Internet

Run MViz

Run MViz

Run MViz

Run MViz

PC A with IP: 140.158.130.239

Lamar UniversityUniversity of Houston, Clear Lake

TelosB

TelosB

TelosB

TelosBTelosB

Run MViz

Application Example - Octopus

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

Run Octopus

Run Octopus

Run Octopus

Run Octopus

Run Octopus

MTS300 + MicaZ

MTS300 + MicaZ

MTS300 + MicaZ

MTS300 + MicaZ

MIB520 + MicaZ

Data Collection

Data Collection

Data Collection

Data CollectionData

Collection

Data Dissemination

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

Data Dissemination

Data Dissemination

Data Dissemination

Data Dissemination

Octopus

Run Octopus

Run Octopus

Run Octopus

Run Octopus

Run Octopus

TelosB

TelosB

TelosB

TelosB

TelosB

Data Collection

Data Collection

Data Collection

Data CollectionData

Collection

Data Dissemination

Data Dissemination

Data Dissemination

Data Dissemination

Data Dissemination

BaseStation – Listen - BlinkToRadio

TelosB Mote

Run BaseStation

run java net.tinyos.tools.Listen -comm serial@/dev/ttyUSB0:telosb

TelosB Mote

Run BlinkToRadio

OscilloScope

TelosB Mote

Run BaseStation

TelosB Mote


TelosB Mote


1. run java net.tinyos.sf.SerialForwarder -comm serial@/dev/ttyUSB0:telosb2. Under Oscilloscope/java, run ./run

1. run java net.tinyos.tools.Listen -comm serial@/dev/ttyUSB0:telosb

Text Interface

GUI Interface

MultihopOscilloscope

TelosB


TelosB


TelosB


1. run java net.tinyos.sf.SerialForwarder -comm serial@/dev/ttyUSB0:telosb

2. Under MultihopOscilloscope/java, run ./run

TelosB



TelosB

1. run java net.tinyos.tools.Listen -comm serial@/dev/ttyUSB0:telosb

GUI Interface

Text Interface

MViz

InternetTelosB

Run MViz

TelosB

Run MViz

TelosB

Run MViz

TelosB

Run MViz

Run MViz

TelosB

run tos-mviz -comm [email protected]:9002 -dir /opt/tinyos-2.x/apps/Mviz MVizMsg

IP: 140.158.130.239

Machine in UHCL

Lamar Univ.UHCL


2. run tos-mviz -comm sf@localhost:9002 -dir /opt/tinyos-2.x/apps/MViz MVizMsg TelosB

Octopus

TelosB

Run Octopus

TelosB

Run Octopus

TelosB

Run Octopus


2. run

2.a export MOTECOM=serial@/dev/ttyUSB0:telosb

2.b java OctopusGui

TelosB

Run Octopus

Run Octopus

TelosB

IP: 140.158.130.239

Lamar Univ.

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/tinyos-2.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 doesn’t TinyOS 2 make every statement async?

tinyos. learning objectives understand tinyos – the dominant open source operating systems for wsn...

Documents

memory size

tinyos architecture

dynamic memory allocation

power optimizationenergy

power consumptioncompare

sleepthe mote revolution

hot chips

micaz mote