1. Fakultät Informatik – Institut für Systemarchitektur – Professur Rechnernetze Tiny OS Thomas Hutschenreuther Frank Beyer Jens Heymann Supervisor: Dr. Waltenegus Dargie

2. Table of contents 1.Introduction and Motivation 2.Concept 3.Architecture 1.Hardware Abstraction Architecture 2.Components 3.Networking 4.Implementation 1.nesC 2.Scheduling 3.Shared resources 4.Power Management 5.Data Storage 6.Active Messages 5.Evaluation 6.Examples of TinyOS applications 7.References

3. Introduction and Motivation

4. open source OS designed for wireless embedded sensor networks ported to over a dozen platforms and numerous sensor boards in use by wide community to develop and test various algorithms and protocols

5. Introduction and Motivation developed since 2000 by a consortium led by the University of California, Berkeley in co-operation with Intel Research several versions: –May 2002: version 0.6.1 for mica, rene, rene2 hardware platforms –October 2002: version 1.0 for mica and mica2 –since February 2006: version 2.0 beta for eyesIFXv2, intelmote2, mica2, mica2dot, micaZ, telosb, tinynode, btnode3 TinyOS Alliance founded - organizational structure to support the worldwide academic and industrial TinyOS community History: rene2

6. Concept

7. features component-based architecture  rapid innovation and implementation minimal code size event-driven execution model – fine-grained power management – scheduling flexibility supports Active Messaging for communication between sensor nodes

8. Concept TinyOS’s component library –network protocols –distributed services –sensor drivers –data acquisition tools examples: –AD conversion− timers –cryptography− memory allocation –random numbers− routing –LED control− file system

9. Concept TinyOS provides runtime environment for nesC applications running on mote hardware –performs some resource management –selected components are linked into the program at compile time (static linking) aims: –minimized hardware requirements –efficient parallel processing of multiple data streams –modularity of software

10. Architecture

11. Hardware Abstraction Architecture (HAA) –increasing portability –simplifying application development by hiding hardware intricacies from rest of system  flexible, 3-layer abstraction hierarchy

12. Architecture layer 1: Hardware Presentation Layer (HPL) –thin software layer on top of raw hardware –presents hardware (such as IO pins or registers) as nesC interfaces layer 2: Hardware Adaptation Layer (HAL) –offers higher level abstractions (easier to use than HPL) –still provides full functionality of underlying hardware layer 3: Hardware Independent Layer (HIL) –provides hardware independent abstractions  generalization limits functionality compared to HAL –HIL components represent abstractions that applications can use and safely compile on multiple platforms

13. Architecture Hardware Abstraction Architecture principle structure taken from [1]

14. each layer represents components component: –consists of 4 parts 1. command handler 2. event handler 3. frame 4. task(s) scheduler handles processing of tasks (FIFO) Architecture internal communication between components using bidirectional interfaces

15. Architecture 1.command: –request sent from components of higher layer to components of lower layer –deposits parameters to components frame and conditionally schedules a task for execution –may return value if successful

16. Architecture 2.event: –signalled by components of lower layer to components of higher layer –can be initiated by hardware interrupts on lowest layer –every component can signal events, post tasks or call commands (e.g. timer) 3.frame: –data storage of a component –static size

17. Architecture 4.task: –do the underlying work –activated by events, commands or other tasks out of the same component –there can only be one task at the same time, can only be interrupted by events –runs as long until it terminates itself

18. Architecture example for a component: picture taken from [2]

19. Architecture Networking: 3 mechanisms: 1) Active Messages: ● node to node communication 2) Dissimination ● reliably spreading pieces of data from root to every node in network ● primarily used for reconfiguration and maintainance of network 3) Collection ● collecting data from all nodes to the root ● tree-based routing

20. Implementation

21. nesC ● extension of C ● developed for the implementation of TinyOS ● concurrency model based on tasks and events ➔ direct support of TinyOS' component based concurrency model ● static language ➔ no dynamic memory allocation ➔ call graph known at compile time ● compile time race detection

22. Implementation nesC - components ● two types of components 1) modules 2) configurations ● components use and provide interfaces ● interfaces are bidirectional ● events ● commands ● application built by wiring components together

23. example for an interface: the interface specifies: Timer must implement start and stop, Application must implement fired picture taken from [4] Implementation interface Timer { command void start(uint32_t dt); command void stop(); event void fired(); }

24. Implementation configuration example:

25. Implementation Scheduling 3 types of workload: –direct function calls (synchronous/asynchronous) –event handlers (synchronous/asynchronous) –tasks(synchronous) event handlers can be executed immediately when event signalled (can preempt anything else) –consistency assured by atomic sections tasks for background processing for expensive instructions - SplitPhase commands –function call returns immediately –completion signalled by callback

26. Implementation Scheduling - Tasks default: nonpreemptive FIFO one slot per task in queue tasks can only be posted once if need for multiple postings: –state variable –task reposts itself when ready task queue empty → processor sleep mode

27. Implementation Shared resources 3 kinds of abstraction: –dedicated resource belongs to a single component –virtualized clients act, as if resource dedicated clients hidden from each other by software virtualization usefull if clients don't need full control over resource –shared several components need direct access to resource ➔ resource arbiter

28. Implementation Resource Arbiters central place managing use of shared resources –can also be used for power management each arbiter must implement : – Resource interface interface Resource { async command error_t request(); async command error_t immediateRequest(); event void granted(); async command error_t release(); async command bool isOwner(); } – ArbiterInfo interface tells clients status of arbiter an arbiter should implement: – ResourceRequested interface – ResourceConfigure interface

29. Implementation

30. Power Management ● microcontroller powermanagement ● three mechanisms: 1) dirty bit 2) chip specific low power calculation function 3) power state override function component McuSleepC { provides interface McuSleep; provides interface PowerState; uses interface PowerOverride; } component McuSleepC { provides interface McuSleep; provides interface PowerState; uses interface PowerOverride; } interface McuPowerState { async command void update(); } interface McuPowerOverride { async command mcu_power_t lowestState(); } interface McuPowerState { async command void update(); } interface McuPowerOverride { async command mcu_power_t lowestState(); }

31. Implementation Power Management of Non-Virtualised Devices explicit power management –StdControl –SplitControl –AsyncStdControl implicit power management –ResourceController

32. Implementation Data Storage flash chips divided into volumes via XML specification storage abstraction instances: –BlockStorageC intended for large objects only entire objects can be written erase before every write –LogStorageC intended for data gathering circular or linear logs –ConfigStorageC transactional behavior random reads and writes

33. Implementation Active Messaging –concept for communication between nodes in the network –design challenge: minimize communication overhead allow communication to overlap computation coordinate the two without sacrificing processor performance –Active Messages (AM) allow cost effective use of hardware –latency tolerance becomes a programming/compiling concern

34. Implementation structure of an Active Message: –header: adress, function pointer, metadata –payload (maximum default length = 29 bytes) general implementation: typedef nx_struct message_t { nx_uint8_t header[sizeof(message_header_t)]; nx_uint8_t data[TOSH_DATA_LENGTH]; nx_uint8_t footer[sizeof(message_footer_t)]; nx_uint8_t metadata[sizeof(message_metadata_t)]; } message_t;

35. Implementation how it works: –each node has its own AM handler consists of: sender, receiver and snooper –node (source) sends its AM –header is pointer on AM handler of receiver node (sink) –AM handler executes immediately on message arrival with payload as argument

36. Evaluation

37. advantages: –open source –modularity (component model) –event based  providing fast transmission of sensor data (collect data  local computation  transmit) –low memory usage (~200 bytes)

38. Evaluation disadvantages: –static linking (selected components linked into program at compile time) –Interoperability with other software frameworks and languages

39. Examples of TinyOS applications

40. Examples there over hundreds of projects based on TinyOS: –TinyDB: query processing system for extracting information from a network of TinyOS sensors provides a simple, SQL-like interface instead of embedded C code

41. Examples –CotsBots: use commercial off-the-shelf (COTS) components to build and deploy inexpensive and modular robots provide a convenient platform to investigate algorithms, cooperation and distributed sensing in large (> 50) robot networks based on Mica Motes including a board equipped with light, temperature, buzzer/microphone, 2-axis magnetometer and accelerometer picture taken from [6]

42. References [1] www.tinyos.net, TinyOS tutorial, FAQ [2] Christian Renner: Seminar Betriebssysteme für Rechnernetze, Universität Tübingen [3] Fei Xie, University of Texas at Austin CS372 Programming Project www.cs.utexas.edu/users/feixie/cs372/ [4] Jan S. Rellermeyer, 2005: Talk at Distributed Systems Prof. R. Wattenhofer and P. von Rickenbach: TinyOS http://people.inf.ethz.ch/rjan/publications/ [5] T. von Eicken, D. E. Culler, S. C. Goldstein, and K.E. Schauser. Active messages: a mechanism for integrated communication and computation. In Proceedings of the 19th Annual International Symposium on Computer Architecture, pages 256–266, Gold Coast, Qld., Australia, May 1992 [6] CotsBots Homepage http://www-bsac.eecs.berkeley.edu/projects/cotsbots/index.html

43. Thank you for your attention!