TinyOS Overview

1
TinyOS Overview

• Source
• System Architecture Directions or Networked
  Sensors - Jason Hill, Robert Szewcyk, Alec Woo,
  Seth Hollar, David Culler, Kristofer Pister
• The Mica Sensing Platform Alec Woo, Jan. 14
  2002, NEST Retreat
• Mica Node Architecture Jason Hill, Jan. 14
  2002, WEBS Retreat
• All Sources could be located at
  http//webs.berkeley.edu/tos/media.html
• Presented by Mark Miyashita
• 06-18-2002

2
TinyOS Introduction

• Computing in a Cubic millimeter
• Advances in low power wireless communication
  technology and micro-electromechanical sensors
  (MEMS) transducers make this possible
• Continued progress in inexpensive MEMS based
  sensors and communication technology accelerate
  research in the embedded network sensor for
  information processing

3
TinyOS Introduction

• Computing in a Cubic millimeter
• Networked sensor is emerging area of interest as
  a result of advancement in RF communication
  technology and MEMS
• TinyOS (an event based operating environment)
  explores the software support for this emerging
  area of networked sensor
• It combines sensing, communication, and
  computation into single architecture Complete
  systems on a chip (micro controller memory
  sensors interfaces etc)

4
Network Sensor Characteristics

• Use commercial components to build sensors
• Small Physical size (as small as square inch)
• Low Power consumption.
• Concurrency intensive operation.
• Limited Physical Parallelism and Controller
  Hierarchy
• Diversity in design and Usage
• Robust operation

5
Ad hoc sensing

• Autonomous nodes self assembling into a network
  of sensors
• Sensor information propagated to central
  collection point
• Intermediate nodes assist distant nodes to reach
  the base station
• Connectivity and error rates used to infer
  distance

Base Station
6
Previous Hardware Design

• MICA is the 4th generation of the Berkeley Motes.
• COTS dust prototypes, by Seth Hollar
• weC Mote
• Rene Mote, manufactured by Crossbow
• 3.1 Dot mote, used for IDF

7
Hardware Organization (MICA)

• Atmel ATMEGA103
• 4 Mhz 8-bit CPU
• 128KB Instruction Memory
• 4KB RAM
• Modes idle, pwr down and pwr save
• 4 Mbit flash (AT45DB041B)
• SPI interface (Serial Peripheral Interface)
• 1-4 uj/bit r/w
• RFM TR1000 radio
• 50 kb/s ASK
• Internal antenna
• Focused hardware acceleration
• Network programming
• Serial port ---I/O pin connected to UART

8
Device Placement
Microphone
Sounder
Magnetometer
1.25 in
Temperature Sensor
Light Sensor
2.25 in
Accelerometer
9
More on Hardware

• Two Board Sandwich
• Main CPU board with Radio Communication
• Secondary Sensor Board
• Allows for expansion and customization
• Current MICA sensors can include Accelerometer,
  Magnetic Field,Temperature, Photo, Sounder,
  Microphone, Light, and RF Signal Strength
• Can control RF transmission strength Sense
  Reception Strength

10
MICA
11
What is TinyOS?

• TinyOS is an event based operating environment
  design to work with embedded network sensors
• Designed to support concurrency intensive
  operations required by network sensors with
  minimal hardware requirements
• TinyOS was initially developed by the U.S.
  Berkeley EECS department

12
Software Challenge

• Concurrency intensive operations
• Unsynchronized, Multiple , high data flow (sensor
  readings, forwarding data packets etc)
• Low memory ? data must be processed on the fly
• Low power consumption
• Bit by Bit interaction with radio ( no buffering
  missed deadline ? lost data)
• Small physical size ( no multiple controllers,
  direct interface with micro controller)
• Modular application specific

13
Tiny OS Overview

• Event driven model.--- uses CPU efficiently
• Two level scheduling ( Event and Tasks)
• System composed of state machines
• Each state machine is a TinyOS component
• Command and event handlers transition a module
  from one state to another
• Quick, low overhead, non-blocking state
  transitions
• Many independent modules allowed to efficiently
  share a single execution context
• No kernel/user space differentiation
• Tasks are used to perform computational work
• Run to completion, Atomic to respect to each
  other

14
Tiny OS Design

• Application scheduler graph of components
• Compiled into one executable

15
Composition
Route map
router
sensor appln
application
Active Messages
packet
Serial Packet
Temp
Radio Packet
SW
byte
HW
UART
Radio byte
i2c
photo
bit
clocks
RFM
16
Simple State Machine Logic
Bit_Arrival_Event_Handler
State bit_cnt
Start
Send Byte Eventbit_cnt 0
Yes
bit_cnt8
bit_cnt
Done
No

• Dont you have to do computational work
  eventually?
• Tasks used to perform computational work

17
Tiny OS The Software

• Scheduler and graph of components
• constrained two-level scheduling model tasks
  events
• Provides a component based model abstracting
  hardware specifics from application programmer
• Capable of maintaining fine grained concurrency
• Can interchange system components to get
  application specific functionality

18
Tiny OS Component Design

• Every component has
• Frame ( storage)
• Tasks ( computation)
• Command Handler Interface
• Event Handler Interface
• Frame static storage model - compile time memory
  allocation (efficiency)
• Command and events are function calls (efficiency)

19
Component Interface

• Upper Interface (from upper comp)
• List of commands it ACCEPTS
• List of events it SIGNALS
• Lower Interface (from lower comp)
• List of commands it USES
• List of events it HANDLES

20
TOS Component
//AM.comp// TOS_MODULE AM ACCEPTS char
AM_SEND_MSG(char addr, char type, char data)
void AM_POWER(char mode) char
AM_INIT() SIGNALS char AM_MSG_REC(char
type, char data) char
AM_MSG_SEND_DONE(char success) HANDLES
char AM_TX_PACKET_DONE(char success) char
AM_RX_PACKET_DONE(char packet) USES char
AM_SUB_TX_PACKET(char data) void
AM_SUB_POWER(char mode) char AM_SUB_INIT()
AM_INIT
AM_POWER
AM_SEND_MSG
AM_MSG_SEND_DONE
AM_MSG_REC
Messaging Component
Internal State
Internal Tasks
AM_SUB_POWER
AM_TX_PACKET_DONE
AM_SUB_TX_PACKET
AM_RX_PACKET_DONE
AM_SUB_INIT
21
TOS Component

• FRAMES / MEMORY ALLOCATION
• Keeps the state of the component between
  invocation of its functions.
• Statically allocated. ( mem req. is known at
  compile time)
• Defined as a global structure.

22
TOS Component

• Commands Events(Function calls) do a small,
  fixed amt of work in the components state
• COMMANDS
• Non blocking requests to lower components
• Post unconditional tasks for later execution.
• Can call lower level commands
• Travel downward through the graph
• Events
• Handles Hardware events directly or indirectly
• Can post tasks, signal higher level events or
  call lower level commands.
• Can preempt tasks
• Travel upwards through the graph.
• COMMANDS CANNOT SIGNAL EVENTS

23
TOS Component

• TASKS
• Perform all the major work (computation)
• Atomic w.r.t other tasks and run to completion.
• Can be preempted by events.( not vice-versa)
• Can call lower level commands, signal higher
  level events and schedule other tasks.
• Simulate concurrency within components.
• Provide means to incorporate arbitrary
  computation into the event driven model

24
TOS Component

• Two level scheduling structure (events and tasks)
• Scheduler is simple FIFO
• Bound on the number of pending tasks.
• Tasks cannot preempt other tasks.
• Scheduler is power aware
• Puts processor into Sleep mode when queue is
  empty.

25
TOS Component

• MAIN top component, interface to lower
  components only
• APPLICATION Define main purpose of OS and
  reside below MAIN.
• Documentation
• Apps/FOO.desc describes the component graph of
  an app
• FOO.comp describes the interface specification
• FOO.c describes the implementation of the
  component

26
TOS Component

• Group certain components together to perform a
  certain function.
• These can be treated as a single entity.
• Example - GENERIC_COMM used to handle radio
  communication
• There is no separate FOO.c for component groups.

27
Example - Generic Comm
Application
Messaging
Interprets packets as messages
Packet Level
Constructs packets from bytes
Byte Level
Encoding
RFM Bit Level
Bit level control
28
Handling Network Message

• ACTIVE MESSAGES PARADIGM
• Integrate communication with computation
• Sender
• Includes event handler identifiers with each
  message
• Receiver
• The event handler is automatically invoked on the
  target node.
• Fits in well into the event based execution model

29
Message format

• Destination address (0xff for broadcast)
• Message type (event handler to invoke -- 255)
• Communication group (to enable smaller group
  comm. 0x13)
• Payload (30 char)
• PC Simulation will add additional fields to the
  header and wrap around fields mentioned above

30
Compilation

• Matching of names/arguments of caller and calling
  function done through preprocessor directives.
• File tos.h -- mapping of initial names to
  intermediate names.
• File foo.desc specific component interface
• Before compilation a Perl script ?.desc file
  ?super.h
• Super.h mapping of preprocessor directives and
  function names of all related components.

31
Space Breakdown
Code size for ad hoc networking application
Scheduler 144 Bytes code Totals 3430 Bytes
code 226 Bytes data
http//tinyos.millennium.berkeley.edu
32
Power Breakdown

• A one byte transmission uses the same energy as
  approx 11000 cycles of computation.
• Lithium Battery runs for 35 hours at peak load
  and years at minimum load!

http//tinyos.millennium.berkeley.edu
33
Work Time breakdown

• 666.4 of work is done in RFM component
• IIt utilizes 30.48 of CPU time for receiving
• IIt consumes 451.17nJ per bit of energy

34
Sample tradeoffs
http//tinyos.millennium.berkeley.edu
35
Ad hoc networking
 

• Each node needs to determine its parent and its
  depth in the tree
• Each node broadcasts out ltidentity, depth, datagt
  when parent is known
• At start, Base Station knows it is at depth 0
• It send out ltBase ID, 0, gt
• Individuals listen for minimum depth parent

 
 
 
 
0
 
 
36
Conclusions

• Small memory footprint ?
• Non-preemptable FIFO task scheduling
• Power efficient ?
• Put micro controller and radio to sleep
• 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 ?
• Non-preemptable FIFO task scheduling
• NO real-time guarantees or overload protection

37
Conclusion

• Driving force
• Smaller, low power and cheaper
• TinyOS is
• Highly modular software environment
• stressing efficiency
• Concurrency
• More Info
• http//webs.berkeley.edu/tos/index.html