Transcript TinyOS - GEOCITIES.ws

“TinyOS”
Design Viewpoint
TinyOS Design Viewpoint
1.1
Vishal Jain , 200411029
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
TinyOS Design Viewpoint
1.2
Review
Technical Details
Exercises
Vishal Jain , 200411029
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.
…………………………
TinyOS Design Viewpoint
1.3
Vishal Jain , 200411029
Non Goals
 To write program in nesC
 To upload it in Motes and run it.
 To really setup an sensor Network
TinyOS Design Viewpoint
1.4
Vishal Jain , 200411029
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.
TinyOS Design Viewpoint
1.5
Vishal Jain , 200411029
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.
TinyOS Design Viewpoint
1.6
Vishal Jain , 200411029
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).
TinyOS Design Viewpoint
1.7
Vishal Jain , 200411029
Abstract View of System Components
TinyOS Design Viewpoint
1.8
Vishal Jain , 200411029
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).
TinyOS Design Viewpoint
1.9
Vishal Jain , 200411029
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.
TinyOS Design Viewpoint
1.10
Vishal Jain , 200411029
Sensor Network Design Factors
 Design Factors
 Fault Tolerance
 Scalability
 Production Costs
 Resource Constraints
 Sensor Network Topology
 Environment
 Transmission Media
 Power Consumption
TinyOS Design Viewpoint
1.11
Vishal Jain , 200411029
Why New Operating System?
TinyOS Design Viewpoint
1.12
Vishal Jain , 200411029
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
 Communication
nesC is suitably design to support all above.
(   sorry wait for next talk on detailed nesC
programming.)
TinyOS Design Viewpoint
1.13
Vishal Jain , 200411029
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.
TinyOS Design Viewpoint
1.14
Vishal Jain , 200411029
Example Component
Fired event
Init command
Start command
Stop command
Setrate() command
TinyOS Design Viewpoint
Fire event
1.15
Vishal Jain , 200411029
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.
TinyOS Design Viewpoint
1.16
Vishal Jain , 200411029
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
TinyOS Design Viewpoint
1.17
Vishal Jain , 200411029
Concurrency : Terms and Def.
TinyOS Design Viewpoint
1.18
Vishal Jain , 200411029
TinyOS: Concurrency
Tasks 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 Design Viewpoint
1.19
Vishal Jain , 200411029
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.
TinyOS Design Viewpoint
1.20
Vishal Jain , 200411029
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.
TinyOS Design Viewpoint
1.21
Vishal Jain , 200411029
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.
TinyOS Design Viewpoint
1.22
Vishal Jain , 200411029
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;
TinyOS Design Viewpoint
1.23
Vishal Jain , 200411029
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
TinyOS Design Viewpoint
1.24
Vishal Jain , 200411029
Frames
 Internal storage
 Fixed Size
 Memory requirement known at compile time
 Static Allocation
 Prevents Overheads
 Example
 State of a component
 Packet to be sent
TinyOS Design Viewpoint
1.25
Vishal Jain , 200411029
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
TinyOS Design Viewpoint
1.26
Vishal Jain , 200411029
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
TinyOS Design Viewpoint
1.27
Vishal Jain , 200411029
The Composition Model
comp3
comp1:
C code
 Components
 .comp: specification
 .C: behaviour
 .desc: select and wire
 specification:
 accepts commands
 uses commands
 signals events
 handles events
comp2:
.desc
comp4
application:
.desc
TinyOS Design Viewpoint
1.28
Vishal Jain , 200411029
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.
TinyOS Design Viewpoint
1.29
Vishal Jain , 200411029
Surge Graph of Components
TinyOS Design Viewpoint
1.30
Vishal Jain , 200411029
Example Component
Fired event
Init command
Start command
Stop command
Setrate() command
TinyOS Design Viewpoint
Fire event
1.31
Vishal Jain , 200411029
Configuration
TinyOS Design Viewpoint
1.32
Vishal Jain , 200411029
Let Us Try One: Oil Exploration
Our Role to Get TinyOS Application
TinyOS Design Viewpoint
1.33
Vishal Jain , 200411029
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.
TinyOS Design Viewpoint
1.34
Vishal Jain , 200411029
Seismic Profile
TinyOS Design Viewpoint
1.35
Vishal Jain , 200411029
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.
TinyOS Design Viewpoint
1.36
Vishal Jain , 200411029
Components
 Acoustic
 Sesmic
 Multihop
 Timer
 Golden_Vector
Oil
 Relocation
Reloc
Relocation
ADC2
Timer
Acoustic
Timer
SendMsg
Receive
Multihop
Golden_Vector
clock
HWclock
TinyOS Design Viewpoint
1.37
Vishal Jain , 200411029
Let us Specify Golden Vector
Get_GV
Got_GV
StdCtl Receive
Golden_Vector
HWRec
GV_Chang
TinyOS Design Viewpoint
New_GV
1.38
Vishal Jain , 200411029
Evaluation of TinyOS:Components
 Component Model
 Code can be divided into two
 Application Specific
 Core (172 components=108code+64 confg)
TinyOS Design Viewpoint
1.39
Vishal Jain , 200411029
Evaluation of TinyOS:Concurrency
 Concurrency
 Simple tasks and events statements that implements
concurrency by calling interrupts.
TinyOS Design Viewpoint
1.40
Vishal Jain , 200411029
Evaluation of TinyOS: Optimization
 Inlining
TinyOS Design Viewpoint
1.41
Vishal Jain , 200411029
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/jhpe
troleum.pdf
TinyOS Design Viewpoint
1.42
Vishal Jain , 200411029
Thanks for Patience…..
Next Talk : “NesC : Programming”
What?
How?
Ask Questions*
*No Programming Questions Please
TinyOS Design Viewpoint
1.43
Vishal Jain , 200411029