Vishal Jain, 200411029 1.1 TinyOS Design Viewpoint “TinyOS” Design Viewpoint.

Vishal Jain , 2004110291.1TinyOS Design Viewpoint

“TinyOS” Design Viewpoint


Index What is Sensor Network? Traditional Stuff

What is an Operating System? System Component OS definitions

Motes : Take a deep Look Sensor Network Design Factors Why new OS? TinyOS Features

Component-based architecture Tasks and event-based concurrency Split-phase operations Scheduler Frames

Composition Model Examples

Surge : Given in Paper Oil Exploration : Let us try

Review

Technical Details

Exercises


Goals of Presentation

To give knowledge about Sensor Network To view application from component viewpoint To implement system by designing components and

wiring them together to have an application To know about concurrency: Tasks and events To know data races and program inlining concepts To learn about active messages To tryout design of Application. …………………………


Non Goals

To write program in nesC To upload it in Motes and run it. To really setup an sensor Network


What is Sensor Network?

A sensor network consist of many spatially synchronized distributed sensors, which are used to monitor or detect changes of a phenomena at different locations(say temperature change, pollutant level etc). Sensor nodes(motes) may have onboard processor to process the raw data.


What is an Operating System?

A program that acts as an intermediary between a user of a computer and the computer hardware.

Operating system goals: Execute user programs and make solving user problems

easier. Make the computer system convenient to use.

Use the computer hardware in an efficient manner.


System Components

1. Hardware – provides basic computing resources (CPU, memory, I/O devices).

2. Operating system – controls and coordinates the use of the hardware among the various application programs for the various users.

3. Applications programs – define the ways in which the system resources are used to solve the computing problems of the users (compilers, database systems, video games, business programs).

4. Users (people, machines, other computers).


Abstract View of System Components


Operating System Definitions

Resource allocator – manages and allocates resources. Control program – controls the execution of user

programs and operations of I/O devices . Kernel – the one program running at all times (all else

being application programs).


Take a Deep Look Into Motes

Motes are very small and interact with environment Run specific application Limited resources and all resources known in advance Hardware software boundaries are system and

application dependent. Motes are Event Driven Reliability of motes is important because they are

unattended. Soft real time requirement.


Sensor Network Design Factors

Design Factors Fault ToleranceFault Tolerance ScalabilityScalability Production CostsProduction Costs Resource Constraints Sensor Network TopologySensor Network Topology EnvironmentEnvironment Transmission MediaTransmission Media Power ConsumptionPower Consumption


Why New Operating System?


TinyOS: Features

Simple component based OS Subset of Components used for application specific

functionality Maintains high level of concurrency in a limited space Uses power efficiently

Spending unused CPU cycles in sleep Turning radio off when not in use

Programming Model Reactive to environment Concurrency CommunicationnesC is suitably design to support all above. ( sorry wait for next talk on detailed nesC programming.)


TinyOS: Components

Components: Reusable piece of code. Provides and uses interfaces.

Interface :interfaces are the only point of access to the component.

Interfaces in TinyOS are bi-directional: they contain commands and events

The providers of an interface implement the commands, while the users implements the events.

downward-pointing arrows depict commands and upward-pointing arrows depict events.


Example Component

Fired event

Start command

Stop command

Init command

Fire eventSetrate() command


TinyOS: Wiring the Components

An application connects components using a wiring specification that is independent of component implementations.

Fan-out : a single command call expression may be connected to an arbitrary number of command implementations.

Fan in : an arbitrary number of command call expressions may be wired to a single command implementation.


What is Concurrency?

On a single-processor machine, the operating system’s support for concurrency allows multiple tasks to share resources in such a way that tasks appear to run at the same time.

Advantages be able to run multiple applications at the same time. better resource utilization better average response time of individual applications

Disadvantages Multiple applications need to be protected from one another. Multiple applications may need to coordinate through

additional mechanisms Switching among applications requires additional

performance overheads


Concurrency : Terms and Def.


TinyOS: ConcurrencyTasks and Event

There are two sources of concurrency in TinyOS: Tasks Events

Tasks are a deferred computation mechanism. They run to completion and do not preempt each other. Components can post tasks; the post operation immediately returns, deferring the computation until the scheduler executes the task later. Components can use tasks when timing requirements are not strict. Example: Packet Transmission Example: task send_data(){//code of send data}

…………….

post send_data()


TinyOS: Tasks and event-based concurrency…….

Events also run to completion, but may preempt the execution of a task or another event. Events signify either completion of a split-phase operation (discussed below) or an event from the environment (e.g. message reception or time passing). TinyOS execution is ultimately driven by events representing hardware interrupts.


Concurrency and Atomicity

Asynchronous Code (AC): code that is reachable from

at least one interrupt handler.

Synchronous Code (SC): code that is only reachable

from tasks.

Invariant: Synchronous Code is atomic with respect to

other Synchronous Code.


Concurrency and Atomicity

Claim 1: Any update to shared state from AC is a potential. race condition.

Claim 2: Any update to shared state from SC that is also updated from AC is a potential race condition.

Race-Free Invariant: Any update to shared state is either

not a potential race condition (SC only), or occurs

within an atomic section.

Tools : atomic sections and tasks.


Split Phase

All long-latency operations are split-phase: operation request and completion are separate functions . Commands are typically requests to execute an operation.If the operation is split-phase, the command returns immediately and completion will be signaled with an event;


Scheduler

Constrained two-level scheduling model: tasks + events Tasks have lower priority

Tasks cannot preempt other tasks or events FIFO scheduler Priority/ deadline based?

May be added, depends on your application Power aware

Processor sleeps when task queue empty


Frames

Internal storage Fixed Size

Memory requirement known at compile time Static Allocation Prevents Overheads

Example State of a component Packet to be sent


How should network msg be handled?

Socket/TCP/IP? Too much memory for buffering and threads Data buffered in network stack until application threads read

it. Application threads blocked until data is available Transmit too many bits (sequence #, ack, re-transmission) Tied with multi-threaded architecture

TinyOS solution: active messages


Active Message

Every message contains the name of an event handler Sender: split-phase operation

Phase I

– Declaring buffer storage in a frame

– Naming a handler

– Requesting Transmission; exit Phase II

– Done completion signal Receiver

Event handler is called when message is received

No blocked or waiting threads on sender or receiver Behaves like any other events Reduce buffering


The Composition Model

Components .comp: specification .C: behaviour .desc: select and wire

specification: accepts commands uses commands signals events handles events

comp1:C code

comp3

comp4comp2:.desc

application:.desc


Solved Example: Surge

Problem Statement: Surge, a simple application that performs periodic sensor

sampling and uses ad-hoc multi-hop routing over the wireless network to deliver samples to the base station.Surge motes organize themselves into a spanning tree rooted at the base station.

Each mote maintains the address of its parent and its depth in the tree, advertising its depth in each radio message

Once a second, each mote samples its light sensor and sends the sample to its parent.

Parents acknowledge received packets. Surge uses the acknowledgments to provide a reliable transport layer.


Surge Graph of Components


Example Component

Fired event

Start command

Stop command

Init command

Fire eventSetrate() command


Configuration


Let Us Try One: Oil Exploration Our Role to Get TinyOS Application


How People are Locating?

The steps in finding oil are similar throughout the world. Creating seismic profiles in a suspected oil field, a

charge or “shot” is set off that produces waves. The waves will then reflect differently on diverse rock strata. The waves are reflected back to the surface and recorded using geophones, which then translates the information into seismograms.


Seismic Profile


Let Us Design Application

Let us take very simple Model:Problem Statement•Sending of acoustic signal by Base Station about the Blasting.•Collection of data when Blasting is done.•Transmission of data using wireless multihop routing.•Calculation of “Golden Vectors” by base station for each node.•Sending “Golden Vector” information to all nodes.•Relocation of motes in the direction of “Golden Vector”•Inform about positions after relocation.


Components

Acoustic Sesmic Multihop Timer Golden_Vector Relocation

Oil

Relocation Golden_VectorAcoustic MultihopTimer

clock

HWclock

TimerReceive

SendMsgADC2Reloc


Let us Specify Golden Vector

Golden_Vector

ReceiveStdCtl

HWRec

Get_GV

Got_GV

New_GVGV_Chang


Evaluation of TinyOS:Components

Component Model Code can be divided into two

Application Specific Core (172 components=108code+64 confg)


Evaluation of TinyOS:Concurrency

Concurrency Simple tasks and events statements that implements

concurrency by calling interrupts.


Evaluation of TinyOS: Optimization

Inlining


References

Main Paper The nesC Language:A holistic approach to NES

Core References: Sensor Network

http://intranet.da-iict.org/~ranjan/sn/papers/akyildiz2.pdf TinyOS

http://rts-lab.eas.asu.edu/document/TinyOS-seminar.ppt OS

Galvin : OS concepts nesC

http://intranet.da-iict.org/~ranjan/sn/papers/nesc-ref.pdf Oil Exploration

http://www.msnucleus.org/membership/html/jh/earth/petroleum/jhpetroleum.pdf


Thanks for Patience…..

Next Talk : “NesC : Programming”

Ask Questions*

*No Programming Questions Please

What? How?

Date post:	13-Jan-2016
Category:	Documents
Upload:	abner-warner
View:	225 times
Download:	0 times

Vishal Jain, 200411029 1.1 TinyOS Design Viewpoint “TinyOS” Design Viewpoint.

Documents