Date post: | 13-Jan-2016 |
Category: |
Documents |
Upload: | abner-warner |
View: | 225 times |
Download: | 0 times |
Vishal Jain , 2004110291.1TinyOS Design Viewpoint
“TinyOS” Design Viewpoint
Vishal Jain , 2004110291.2TinyOS 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
Vishal Jain , 2004110291.3TinyOS Design Viewpoint
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. …………………………
Vishal Jain , 2004110291.4TinyOS Design Viewpoint
Non Goals
To write program in nesC To upload it in Motes and run it. To really setup an sensor Network
Vishal Jain , 2004110291.5TinyOS Design Viewpoint
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.
Vishal Jain , 2004110291.6TinyOS Design Viewpoint
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.
Vishal Jain , 2004110291.7TinyOS Design Viewpoint
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).
Vishal Jain , 2004110291.8TinyOS Design Viewpoint
Abstract View of System Components
Vishal Jain , 2004110291.9TinyOS Design Viewpoint
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).
Vishal Jain , 2004110291.10TinyOS Design Viewpoint
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.
Vishal Jain , 2004110291.11TinyOS Design Viewpoint
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
Vishal Jain , 2004110291.12TinyOS Design Viewpoint
Why New Operating System?
Vishal Jain , 2004110291.13TinyOS Design Viewpoint
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.)
Vishal Jain , 2004110291.14TinyOS Design Viewpoint
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.
Vishal Jain , 2004110291.15TinyOS Design Viewpoint
Example Component
Fired event
Start command
Stop command
Init command
Fire eventSetrate() command
Vishal Jain , 2004110291.16TinyOS Design Viewpoint
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.
Vishal Jain , 2004110291.17TinyOS Design Viewpoint
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
Vishal Jain , 2004110291.18TinyOS Design Viewpoint
Concurrency : Terms and Def.
Vishal Jain , 2004110291.19TinyOS Design Viewpoint
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()
Vishal Jain , 2004110291.20TinyOS Design Viewpoint
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.
Vishal Jain , 2004110291.21TinyOS Design Viewpoint
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.
Vishal Jain , 2004110291.22TinyOS Design Viewpoint
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.
Vishal Jain , 2004110291.23TinyOS Design Viewpoint
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;
Vishal Jain , 2004110291.24TinyOS Design Viewpoint
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
Vishal Jain , 2004110291.25TinyOS Design Viewpoint
Frames
Internal storage Fixed Size
Memory requirement known at compile time Static Allocation Prevents Overheads
Example State of a component Packet to be sent
Vishal Jain , 2004110291.26TinyOS Design Viewpoint
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
Vishal Jain , 2004110291.27TinyOS Design Viewpoint
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
Vishal Jain , 2004110291.28TinyOS Design Viewpoint
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
Vishal Jain , 2004110291.29TinyOS Design Viewpoint
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.
Vishal Jain , 2004110291.30TinyOS Design Viewpoint
Surge Graph of Components
Vishal Jain , 2004110291.31TinyOS Design Viewpoint
Example Component
Fired event
Start command
Stop command
Init command
Fire eventSetrate() command
Vishal Jain , 2004110291.32TinyOS Design Viewpoint
Configuration
Vishal Jain , 2004110291.33TinyOS Design Viewpoint
Let Us Try One: Oil Exploration Our Role to Get TinyOS Application
Vishal Jain , 2004110291.34TinyOS Design Viewpoint
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.
Vishal Jain , 2004110291.35TinyOS Design Viewpoint
Seismic Profile
Vishal Jain , 2004110291.36TinyOS Design Viewpoint
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.
Vishal Jain , 2004110291.37TinyOS Design Viewpoint
Components
Acoustic Sesmic Multihop Timer Golden_Vector Relocation
Oil
Relocation Golden_VectorAcoustic MultihopTimer
clock
HWclock
TimerReceive
SendMsgADC2Reloc
Vishal Jain , 2004110291.38TinyOS Design Viewpoint
Let us Specify Golden Vector
Golden_Vector
ReceiveStdCtl
HWRec
Get_GV
Got_GV
New_GVGV_Chang
Vishal Jain , 2004110291.39TinyOS Design Viewpoint
Evaluation of TinyOS:Components
Component Model Code can be divided into two
Application Specific Core (172 components=108code+64 confg)
Vishal Jain , 2004110291.40TinyOS Design Viewpoint
Evaluation of TinyOS:Concurrency
Concurrency Simple tasks and events statements that implements
concurrency by calling interrupts.
Vishal Jain , 2004110291.41TinyOS Design Viewpoint
Evaluation of TinyOS: Optimization
Inlining
Vishal Jain , 2004110291.42TinyOS Design Viewpoint
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
Vishal Jain , 2004110291.43TinyOS Design Viewpoint
Thanks for Patience…..
Next Talk : “NesC : Programming”
Ask Questions*
*No Programming Questions Please
What? How?