Tiny OS

1
Tiny OS

• Thomas Hutschenreuther
• Frank Beyer
• Jens Heymann
• Supervisor Dr. Waltenegus Dargie

2
Table of contents

• Introduction and Motivation
• Concept
• Architecture
• Hardware Abstraction Architecture
• Components
• Networking
• Implementation
• nesC
• Scheduling
• Shared resources
• Power Management
• Data Storage
• Active Messages
• Evaluation
• Examples of TinyOS applications
• References

3

• Introduction and Motivation

4
Introduction and Motivation

• 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
History

• 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

rene2
6

• Concept

7
Concept

• 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

• TinyOSs 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
Architecture

• 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
Architecture

• 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)

internal communication between components using
bidirectional interfaces
15
Architecture

• 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

• 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)
• 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
• Active Messages
• node to node communication
• Dissimination
• reliably spreading pieces of data from root to
  every node in network
• primarily used for reconfiguration and
  maintainance of network
• Collection
• collecting data from all nodes to the root
• tree-based routing

20

• Implementation

21
Implementation

• 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
• modules
• configurations
• components use and provide interfaces
• interfaces are bidirectional
• events
• commands
• application built by wiring components together

23
Implementation

• example for an interface
• the interface specifies Timer must implement
  start and stop, Application must implement fired

interface Timerltprecision_taggt 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
Implementation

• Power Management
• microcontroller powermanagement
• three mechanisms
• dirty bit
• chip specific low power calculation function
• power state override function

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()
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 headersizeof(message_header_t)
• nx_uint8_t dataTOSH_DATA_LENGTH
• nx_uint8_t footersizeof(message_footer_t)
• nx_uint8_t metadatasizeof(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
Evaluation

• 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 (gt 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
  256266,
• Gold Coast, Qld., Australia, May 1992
• 6 CotsBots Homepage
• http//www-bsac.eecs.berkeley.edu/projects/cotsb
  ots/index.html

43

• Thank you for your attention!