Kevin Hammond

1
TinyOS Good Things come in Tiny packages.

• Kevin Hammond
• ECGR 8185, Advanced Embedded Systems
• Dr. James Conrad, UNCC
• Spring 2005

2
What is TinyOS?

• 16 bit operating system
• Initially developed by the U.C. Berkeley EECS
  Department
• Specifically designed for Wireless Sensor
  Networks

3
A Little Background.

• TinyOS is
• an open-source operating system.
• designed for wireless embedded sensor networks.
• a component-based architecture.
• enables rapid innovation and implementation
• minimizes code size
• TinyOS includes
• a component library with network protocols,
  distributed services, sensor drivers, and data
  acquisition tools.
• an event-driven execution model.

4
A Little Background.

• TinyOS has been
• ported to over a dozen platforms and numerous
  sensor boards.
• Including the Renesas H8, Atmel Mica, Mica2
  Mica2Dot
• used in simulation to develop and test various
  algorithms and protocols.
• TinyOS is alive and well.
• New releases see over 10,000 downloads.
• Over 500 research groups and companies are using
  TinyOS.
• Numerous groups are actively contributing code in
  an open environment.
• Version 1.2 is the last stable version.
• Currently working on version 2.0.

5
Different Platforms Require Different Solutions
Highly constrained (memory, cpu, storage,
power) Solutions TinyOS,
PC-104
Capabilities
Renesas M16C
Abundant resources Solutions Linux, QNX, uCos
MICA Mote
Spec
Size, Power Consumption, Cost
6
Network Sensor Characteristics

• Small physical size and low power consumption
• Concurrent, intensive operations
• multiple flows, no wait-command-respond (never
  poll, never block)
• Limited Physical and Controller Hierarchy
• primitive direct-to-device interface
• Asynchronous and synchronous devices
• (interleaving flows, events, energy management)
• Diverse in Design and Usage
• application specific, not general purpose
• huge device variation
• need efficient modularity
• Robust Operation
• numerous, unattended, critical
• Hurry Up and Sleep!

7
Design Objectives

• Power efficiency
• Small memory footprint
• Application specific
• Modularity
• Concurrency-intensive operations
• Multiple, high-rate data flows (radio, sensor,
  actuator)
• Real-time
• Real-time query and feedback control of physical
  world
• Little memory for buffering data must be
  processed on the fly
• TinyOS No buffering in radio hw deadline miss ?
  data loss
• NOTE TinyOS provides NO real-time guarantees!

8
TinyOS Overview

• Application scheduler graph of components
• Compiled into one executable
• Event-driven architecture
• Single shared stack
• No kernel/user space differentiation

Main (includes Scheduler)
Application (User Components)
Actuating
Sensing
Communication
Hardware Abstractions
9
TinyOS Concepts
Events
Commands

• Scheduler Graph of Components
• constrained two-level scheduling model threads
  events
• Component
• Commands
• Event Handlers
• Frame (storage)
• Tasks (concurrency)
• Constrained Storage Model
• frame per component, shared stack, no heap
• Very lean multithreading
• Efficient Layering

send_msg(addr, type, data)
power(mode)
init
Messaging Component
Internal State
internal thread
TX_packet(buf)
Power(mode)
init
RX_packet_done (buffer)
TX_packet_done (success)
10
Scheduler

• Simple two level FIFO scheduling
• Events
• Handle multiple data flows.
• Interrupts trigger lowest level events
• Can preempt tasks, tasks do not
• Can signal events, call commands, or post tasks.
• Tasks
• Perform computationally intensive work
• Bounded number of pending tasks
• Non-preemptive from other tasks.
• Tightly coupled with the application
• When idle, shuts down except for clock.

11
Components

• Components have
• Frame (internal state)
• Tasks (computation)
• Interface (events, commands)
• Frame
• one per component
• statically allocated
• fixed size
• Commands and Events are function calls
• Application
• Links interfaces (events, commands)

12
Two Types of Components

• Modules
• Implement the application behavior.
• Configurations
• Wires components together.
• A component does not care if another component is
  a module or configuration
• A component may be composed of other components

13
Execution Model

• commands request action
• ack/nack at every boundary
• call cmd or post task
• events notify occurrence
• HW intrpt at lowest level
• may signal events
• call cmds
• post tasks
• Tasks provide logical concurrency
• preempted by events
• Migration of HW/SW boundary

14
Development Environment

• Develop under Windows/Linux
• Uses nesC programming language

15
nesC A programming language for sensor networks

• Supports concurrency model of TinyOS
• Non-blocking operations - split phase
• Very low overhead, no threads
• Dialect of C with support for components
• Components provide and require interfaces
• Create applications by wiring together components
  using configurations
• Whole program compilation and analysis
• Aggressive cross-component inlining
• Static data-race detection
• Optimization approaches include
• No function pointers
• No dynamic memory allocation
• No dynamic component instantiation/destruction

16
TinyOS Issues

• Programming perspective
• No memory protection
• Easy to corrupt/crash the system. system
• Heavy use of macros
• System perspective
• Simplistic FIFO scheduling
• no real-time guarantees
• Bounded number of pending tasks
• No process management
• resource allocation
• Software level bit manipulation

17
Active Messaging

• Simple, extensible paradigm
• Widely used in parallel and distributed systems
• Integrating communication and computation
• Distributed event model where networked nodes
  send events

18
Active Messages Basic structure

• Light weight architecture
• Each Active Message contains
• User-level handler to be invoked on arrival
• Data payload passed as argument
• Event-centric nature
• Enables network communication to overlap with
  sensor-interaction.
• Handler functions
• Extract message quickly from network
• Provide data for computation/forward data
• Prevent network congestion
• Minimal buffering
• Pipeline analogy
• Quick execution of handlers prevents use of
  send/receive buffers

19
Tiny Active Messages

• Three basic sufficient primitives
• Best effort message transmission
• Addressing Address checking
• Dispatch Handler invocation
• Components provide modularity
• Applications choose between types/levels of error
  correction/detection
• Consistent interface to communication primitives
• Portability across hardware platforms.

20
What is it good for?

• Zigbee!
• Goal is to define the network, security and
  application software layers for wireless
  networks.
• Lowest level of the Zigbee communications stack
  is the networking level.
• Not a replacement, but compatible with TinyOS.
• That is, a Zigbee protocol could be written in
  TinyOS/nesC.
• Not open source, but available to all Zigbee
  alliance members.
• 802.15.4
• IEEE standard that defines a MAC and PHY layer
  targeted to wireless sensor networks.
• Built in to the TinyOS stack.
• SmartDust
• Tiny, tiny sensing modules.

21
TOSSIM

• TinyOS mote simulator
• Scales to thousands of nodes
• Compiles directly from TinyOS source
• Simulates network at bit level

22
Conclusions

• Sensor networks are becoming more and more
  popular.
• A major bottleneck is power consumption.
• Another is an adequate driver library and modular
  framework.
• TinyOS attempts to facilitate development in
  these areas by addressing these issues.
• An unsolved problem is the disposal of sensor
  nodes.

23
Questions?