Transcript Document

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
TinyOS Introduction
Computing in a Cubic millimeter
• Advances in low power wireless
communication technology and microelectromechanical 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
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)
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
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
Routing Tree Link
Connectivity
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
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
Device Placement
Microphone
Sounder
Magnetometer
1.25 in
Temperature
Sensor
Light
Sensor
2.25 in
Accelerometer
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
MICA
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
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
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
Tiny OS Design
Main (includes Scheduler)
Application (User Components)
Actuating
Sensing
Communication
Communication
Hardware Abstractions
Application = scheduler + graph of components
•Compiled into one executable
Composition
application
Route map
router
sensor appln
Active Messages
packet
Radio Packet
Serial Packet
Temp
Radio byte
UART
i2c
SW
byte
HW
photo
bit
RFM
clocks
Simple State Machine Logic
Bit_Arrival_Event_Handler
State: {bit_cnt}
Start
Yes
bit_cnt++
bit_cnt==8
Send Byte Event
bit_cnt = 0
No
• Don’t you have to do computational work
eventually?
• “Tasks” used to perform computational work
Done
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
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)
Messaging Component
Internal Tasks
Commands
Internal State
Events
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
AM_MSG_SEND_DONE
AM_MSG_REC
AM_POWER
AM_INIT
TOS Component
Messaging Component
AM_RX_PACKET
_DONE
AM_TX_PACKET
_DONE
AM_SUB_INIT
AM_SUB_POWER
AM_SUB_TX_PACKET
Internal Tasks Internal State
//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();
};
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.
TOS Component
• Commands & Events(Function calls) do a small, fixed
amt of work in the component’s 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
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
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.
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
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.
Example - Generic Comm
CONNECT
Application
AM
Interprets packets as
messages
Messaging
PACKETOBJ
Constructs packets from
bytes
Packet Level
SEC_DED_RADIO_BYTE
RFM
Hardware.h
Encoding
Bit level control
Byte Level
RFM Bit Level
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
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
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.
Space Breakdown
Code size for ad hoc networking
application
3500
3000
Bytes
2500
2000
1500
1000
500
Interrupts
Message Dispatch
Initilization
C-Runtime
Light Sensor
Clock
Scheduler
Led Control
Messaging Layer
Packet Layer
Radio Interface
Routing Application
Radio Byte Encoder
0
http://tinyos.millennium.berkeley.edu
Scheduler: 144 Bytes code
Totals: 3430 Bytes code
226 Bytes data
Power Breakdown
Active
Idle
Sleep
CPU
5 mA
2 mA
5 μA
Radio
7 mA (TX)
4.5 mA (RX)
5 μA
EE-Prom
3 mA
0
0
LED’s
4 mA
0
0
Photo Diode
200 μA
0
0
Temperature
200 μA
0
0
•
•
Panasonic
CR2354
560 mAh
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
Work & Time breakdown
Components
AM
Packet
Ratio handler
Radio decode thread
RFM
Radio Reception
Idle
Packet reception work
breakdown
CPU Utilization
0.05%
1.12%
26.87%
5.48%
66.48%
100.00%
Total
•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
0.20%
0.51%
12.16%
2.48%
30.08%
54.75%
100.00%
Energy (nj/Bit)
0.33
7.58
182.38
37.2
451.17
1350
2028.66
Sample tradeoffs
Average Power
Consumption (mA)
Radio Receive Power Optimizations
8
Sender Overhead
Receiver Radio
Receiver CPU
7
6
5
4
Panasonic
CR2354
560 mAh
3
2
1
0
None
Micro
Macro
Both
Optimization Type
Battery Lifetime for sensor reporting every minute
Duty Cycle Estimated Battery Life
Full Time Listen
100%
3 Days
Full Time Low_Power Listen
100%
6.54 Days
Periodic Multi-Hop Listening
10%
65 Days
No Listen (no Multi-hop)
0.01%
Years
Ad hoc networking
• Each node needs to determine it’s parent and its depth in the
tree
• Each node broadcasts out <identity, depth, data> when
parent is known
• At start, Base Station knows it is at depth 0
• It send out <Base ID, 0, **>
• Individuals listen for minimum depth parent
2
1
3
0
2
1
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
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