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

2. Vishal Jain, 200411029 1.2 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

3. Vishal Jain, 200411029 1.3 TinyOS 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. …………………………

4. Vishal Jain, 200411029 1.4 TinyOS Design Viewpoint Non Goals To write program in nesC To upload it in Motes and run it. To really setup an sensor Network

5. Vishal Jain, 200411029 1.5 TinyOS 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.

6. Vishal Jain, 200411029 1.6 TinyOS 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.

7. Vishal Jain, 200411029 1.7 TinyOS 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).

8. Vishal Jain, 200411029 1.8 TinyOS Design Viewpoint Abstract View of System Components

9. Vishal Jain, 200411029 1.9 TinyOS 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).

10. Vishal Jain, 200411029 1.10 TinyOS 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.

11. Vishal Jain, 200411029 1.11 TinyOS Design Viewpoint Sensor Network Design Factors Design Factors F Fault Tolerance F Scalability F Production Costs F Resource Constraints F Sensor Network Topology F Environment F Transmission Media F Power Consumption

12. Vishal Jain, 200411029 1.12 TinyOS Design Viewpoint Why New Operating System?

13. Vishal Jain, 200411029 1.13 TinyOS 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  Communication nesC is suitably design to support all above. (    sorry wait for next talk on detailed nesC programming.)

14. Vishal Jain, 200411029 1.14 TinyOS 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.

15. Vishal Jain, 200411029 1.15 TinyOS Design Viewpoint Example Component Fired event Start command Stop command Init command Fire event Setrate() command

16. Vishal Jain, 200411029 1.16 TinyOS 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.

17. Vishal Jain, 200411029 1.17 TinyOS Design Viewpoint What is Concurrency? n 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. n Advantages F be able to run multiple applications at the same time. F better resource utilization F better average response time of individual applications n Disadvantages F Multiple applications need to be protected from one another. F Multiple applications may need to coordinate through additional mechanisms F Switching among applications requires additional performance overheads

18. Vishal Jain, 200411029 1.18 TinyOS Design Viewpoint Concurrency : Terms and Def.

19. Vishal Jain, 200411029 1.19 TinyOS Design Viewpoint 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()

20. Vishal Jain, 200411029 1.20 TinyOS 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.

21. Vishal Jain, 200411029 1.21 TinyOS 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.

22. Vishal Jain, 200411029 1.22 TinyOS 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.

23. Vishal Jain, 200411029 1.23 TinyOS 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;

24. Vishal Jain, 200411029 1.24 TinyOS 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

25. Vishal Jain, 200411029 1.25 TinyOS 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

26. Vishal Jain, 200411029 1.26 TinyOS 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

27. Vishal Jain, 200411029 1.27 TinyOS 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

28. Vishal Jain, 200411029 1.28 TinyOS 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 comp4 comp2:.desc application:.desc

29. Vishal Jain, 200411029 1.29 TinyOS Design Viewpoint Solved Example: Surge Problem Statement: n 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. n Each mote maintains the address of its parent and its depth in the tree, advertising its depth in each radio message n Once a second, each mote samples its light sensor and sends the sample to its parent. n Parents acknowledge received packets. Surge uses the acknowledgments to provide a reliable transport layer.

30. Vishal Jain, 200411029 1.30 TinyOS Design Viewpoint Surge Graph of Components

31. Vishal Jain, 200411029 1.31 TinyOS Design Viewpoint Example Component Fired event Start command Stop command Init command Fire event Setrate() command

32. Vishal Jain, 200411029 1.32 TinyOS Design Viewpoint Configuration

33. Vishal Jain, 200411029 1.33 TinyOS Design Viewpoint Let Us Try One: Oil Exploration Our Role to Get TinyOS Application

34. Vishal Jain, 200411029 1.34 TinyOS Design Viewpoint How People are Locating? n The steps in finding oil are similar throughout the world. n 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.

35. Vishal Jain, 200411029 1.35 TinyOS Design Viewpoint Seismic Profile

36. Vishal Jain, 200411029 1.36 TinyOS 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.

37. Vishal Jain, 200411029 1.37 TinyOS Design Viewpoint Components Acoustic Sesmic Multihop Timer Golden_Vector Relocation Oil Relocation Golden_Vector Acoustic Multihop Timer clock HWclock Timer Receive SendMsg ADC2 Reloc

38. Vishal Jain, 200411029 1.38 TinyOS Design Viewpoint Let us Specify Golden Vector Golden_Vector Receive StdCtl HWRec Get_GV Got_GV New_GV GV_Chang

39. Vishal Jain, 200411029 1.39 TinyOS Design Viewpoint Evaluation of TinyOS:Components Component Model  Code can be divided into two  Application Specific  Core (172 components=108code+64 confg)

40. Vishal Jain, 200411029 1.40 TinyOS Design Viewpoint Evaluation of TinyOS:Concurrency Concurrency  Simple tasks and events statements that implements concurrency by calling interrupts.

41. Vishal Jain, 200411029 1.41 TinyOS Design Viewpoint Evaluation of TinyOS: Optimization Inlining

42. Vishal Jain, 200411029 1.42 TinyOS 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/jhpe troleum.pdf

43. Vishal Jain, 200411029 1.43 TinyOS Design Viewpoint Thanks for Patience….. Next Talk : “NesC : Programming” Ask Questions* *No Programming Questions Please What? How?