Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
“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