Introduction to TinyOS

Open Experimental Platform

Services Networking TinyOS
WeC 99 Smart Rock Rene 11/00 Dot 9/01 Mica 1/02 Telos 4/04 Robust Low Power 250kbps Easy to use

Small microcontroller 8 kB code 512 B data Simple, low-power radio 10 kbps ASK EEPROM (32 KB) Simple sensors Designed for experimentation -sensor boards -power boards

Demonstrate scale

Mica2 12/02 38.4kbps radio FSK NEST open exp. Platform 128 kB code, 4 kB data 40kbps OOK/ASK radio 512 kB Flash

Spec 6/03 Mote on a chip

Commercial Off The Shelf Components (COTS)

Reminder
watt = voltage * amphere
Unit of power

joule = watt * second

Unit of energy

Faster, Smaller, Numerous

Moores Law
Stuff (transistors, etc) doubling every 1-2 years

Bells Law
New computing class every 10 years
Streaming Data to/from the Physical World
log (people per computer)

year

Source: HotChips 2004

Mote Evolution

Source: HotChips 2004

Design Principles
Key to Low Duty Cycle Operation:
Sleep majority of the time Wakeup quickly start processing Active minimize work & return to sleep

Source: HotChips 2004

Sleep
Majority of time, node is asleep
>99%

Minimize sleep current through

Isolating and shutting down individual circuits Using low power hardware
Need RAM retention

Run auxiliary hardware components from low speed oscillators (typically 32kHz)
Perform ADC conversions, DMA transfers, and bus operations while microcontroller core is stopped

Source: HotChips 2004

Wakeup
Overhead of switching from Sleep to Active Mode Microcontroller Radio (FSK)

292 ns 10ns 4ms typical 2.5 ms 1 10 ms typical

Source: HotChips 2004

Active
Microcontroller
Fast processing, low active power Avoid external oscillators

External Flash (stable storage)

Data logging, network code reprogramming, aggregation High power consumption Long writes

Radio
High data rate, low power tradeoffs Narrowband radios
Low power, lower data rate, simple channel encoding, faster startup

Radio vs. Flash

250kbps radio sending 1 byte
Energy : 1.5QJ Duration : 32Qs

Atmel flash writing 1 byte

Energy : 3QJ Duration : 78Qs

Wideband radios
More robust to noise, higher power, high data rates

Source: HotChips 2004

Power Calculation Comparison

Design for low power

Mica2 (AVR)

MicaZ (AVR)

Telos (TI MSP)

0.006 ms wakeup 2 QW sleep 3 mW active 250 kbps 1.8V min 8/8 of AA capacity

0.2 ms wakeup 30 QW sleep 33 mW active 19 kbps 2/3 of AA capacity 2.5V min

0.2 ms wakeup 30 QW sleep 33 mW active 250 kbps 2.5V min 2/3 of AA capacity

Report data once every 3 minutes with two AA batteries (<1% duty cycle)

453 days

328 days

945 days

Software challenges
Power efficiency Small memory footprint Application specific Modularity Concurrency-intensive operations
Multiple, high-rate data flows (radio, sensor, actuator) 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 TinyOS provides NO real-time guarantees! EDF (Earliest Deadline First) scheduling supported in TinyOS 2.x
http://www.tinyos.net/tinyos-2.x/doc/html/tep106.html Perfect???

Real-time

General-Purpose OS?
MANY functionalities & programming APIs Protection between untrusted applications and kernel
Overhead for crossing kernel/user boundary & interrupt handling

Multi-threaded architecture
Large number of threads Context switch overhead large memory

I/O model
Blocking I/O: waste memory on blocked threads Polling: waste CPU cycles and power

Need a new OS architecture!

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

Communication Sensing Communication Hardware Abstractions

Traditional OS Architectures
Application 1 Application 2 Application 1 NFS Micro-kernel Scheduler IPC Scheduler HW VM I/O Monolithic kernel VM I/O HW

Problems Large memory & storage requirement Unnecessary and overkill functionality Address space isolation, complex I/O subsystem, UI Relative high system overhead, e.g, context switch Require complex and power consuming hardware support

Desirable OS architecture
Extremely small footprint Extremely low system overhead Extremely low power consumption

TinyOS Architecture Overview

Scheduler Application Component I/O Application Component COMM . TinyOS Application Component .

NO Kernel Direct hardware manipulation NO Process management Only one process on the fly NO Virtual memory Single linear physical address space NO Dynamic memory allocation Assigned at compile time NO Software signal or exception Function call Goal: to strip down memory size and system overhead.

TinyOS Architecture Overview

Characteristics of TinyOS
No UI, power constrained Application specific HW and SW Multiple flows, concurrent bursts Extremely passive vigilance (power saving ) Tightly coupled with the application

Main (includes Scheduler) Application (User Components) Active Message Actuating Sensing Communication Mote Hardware

Simplified TinyOS Architecture

TinyOS component model

Component has:
Frame: storage Tasks: computation Interface
Command Event
Messaging Component
Internal Tasks Internal State

Commands

Events

Frame: static storage model - compile time memory allocation (efficiency) Command and events are function calls (efficiency)

An Example Application
application sensing application

routing

Routing Layer

messaging

Messaging Layer

packet

Radio Packet

byte

Radio byte (MAC)

photo

Temp

SW HW

bit

RFM

clocks

ADC

i2c

TinyOS Two-level Scheduling

Tasks do computations
Non-preemptive FIFO scheduling Bounded number of pending tasks

Events handle concurrent dataflows

Interrupts trigger lowest level events Events preempt tasks, tasks do not Events can signal events, call commands, or post tasks
Preempt POST events Tasks FIFO

commands commands Interrupts

Hardware

Time

Two-Level Scheduling
Event and Task
Tasks cannot preempt other tasks Single shared stack
Used by both interrupts and function calls

Simple FIFO scheduler Events can preempt a task Events can preempt each other When idle, scheduler shuts down the node except for clock

Event implementation
Event is independent of FIFO scheduler. Lowest level events are supported directly by Hardware interrupt Software events propagate from lower level to upper level through function call

How to handle multiple data flows?

Data are handled by
A sequence of non-blocking event/command (function calls) through the component graph Post tasks for computations that are not emergent

Preempting tasks to handle new data

How should network msg be handled?

Socket/TCP/IP?
Too much memory for buffering and threads Data are buffered until application threads read it Application threads blocked until data is available Transmit too many bits (sequence #, ack, retransmission) Tied with multi-threaded architecture

TinyOS solution: Active Messages

Active Message
Every message contains the name of an event handler Sender
Declare buffer storage in a frame Name a handler Request Transmission Done - completion signal

Receiver
The corresponding event handler invoked

 No blocked or waiting threads on the receiver  Behaves like any other events  Single buffering

Analysis and Evaluation

Space, Power and Time

Code and Data Size Breakdown

Scheduler: 178 Bytes code Totals: 3450 Bytes code 226 Bytes data

Time Breakdown

Time Breakdown

Total propagation delay: 40 us (80 instructions)

Power Breakdown

Evaluation of TinyOS
Small memory footprint Power efficient
Put microcontroller and radio to sleep

Non-preemptable FIFO task scheduling

Efficient modularity
Function call (event, command) interface between components

Concurrency-intensive operations
Event-driven architecture Efficient interrupts/events handling (function calls, no user/kernel boundary)

Real-time v
Non-preemptable FIFO task scheduling No real-time guarantees or overload protection

What should be added to TinyOS?

Priority- & deadline-driven scheduling?
RM? EDF? Appropriate for data-centric applications? How to deal with multiple resources, e.g., CPU & wireless bandwidth? Extend RM or EDF?

End-to-end timing guarantees? Reliable synchronization mechanism? Internet or large scale service infrastructure?
Interoperability? Protocols?
TCP/IP, UDP, RTP?