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 Overview
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
TinyOS IntroductionComputing 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
Routing Tree Link
Connectivity
Base Station
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 Atmel ATMEGA103
• 4 Mhz 8-bit CPU4 Mhz 8-bit CPU• 128KB Instruction Memory128KB Instruction Memory• 4KB RAM4KB RAM• Modes – idle, pwr down and pwr
save• 4 Mbit flash (AT45DB041B)4 Mbit flash (AT45DB041B)
• SPI interface (SPI interface (Serial Peripheral Serial Peripheral InterfaceInterface))
• 1-4 uj/bit r/w1-4 uj/bit r/w• RFM TR1000 radioRFM TR1000 radio
• 50 kb/s – ASK50 kb/s – ASK• Internal antennaInternal antenna• Focused hardware accelerationFocused hardware acceleration
• Network programmingNetwork programming• Serial port ---I/O pin connected to UART
Device Placement
2.25 in
1.25 in
Microphone
AccelerometerLightSensor
TemperatureSensor
Sounder Magnetometer
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
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
Communication
Actuating Sensing Communication
Application (User Components)
Main (includes Scheduler)
Hardware Abstractions
Application = scheduler + graph of components
•Compiled into one executable
Composition
RFM
Radio byte
Radio Packet
UART
Serial Packet
i2c
Temp
photo
Active Messages
clocksbit
byte
packet
Route map router sensor applnapplication
HW
SW
Simple State Machine Logic
bit_cnt++ bit_cnt==8
Send Byte Eventbit_cnt = 0
DoneNo
Yes
Bit_Arrival_Event_HandlerState: {bit_cnt}
Start
• Don’t you have to do computational work eventually?
• “Tasks” used to perform computational work
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 StateInternal Tasks
Commands 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
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();};
Messaging Component
AM_SUB_INIT
AM_SUB_POWER
AM_SUB_TX_PACKET
AM_TX_PACKET
_DONE
AM_RX_PACKET
_DONE
Internal State
AM_INIT
AM_POWER
AM_MSG_REC
Internal Tasks
AM_SEND_MSG
AM_MSG_SEND_DONE
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.
• 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.
TOS Component
AM
PACKETOBJ
SEC_DED_RADIO_BYTE
RFMHardware.h
CONNECT
RFM Bit Level
Byte Level
Packet Level
Messaging
Application
Bit level control
Encoding
Constructs packets from bytes
Interprets packets as messages
Example - Generic Comm
• 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
Handling Network Message
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
• 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.
Compilation
Code size for ad hoc networkingapplication
Scheduler: 144 Bytes codeTotals: 3430 Bytes code 226 Bytes data
http://tinyos.millennium.berkeley.edu
0
500
1000
1500
2000
2500
3000
3500
Byt
es
InterruptsMessage DispatchInitilizationC-RuntimeLight SensorClockSchedulerLed ControlMessaging LayerPacket LayerRadio InterfaceRouting ApplicationRadio Byte Encoder
Space 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!
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
http://tinyos.millennium.berkeley.edu
Power 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
ComponentsPacket reception work breakdown CPU Utilization Energy (nj/Bit)
AM 0.05% 0.20% 0.33Packet 1.12% 0.51% 7.58Ratio handler 26.87% 12.16% 182.38Radio decode thread 5.48% 2.48% 37.2RFM 66.48% 30.08% 451.17Radio Reception - - 1350Idle - 54.75% -Total 100.00% 100.00% 2028.66
Work & Time breakdown
Panasonic CR2354
560 mAh
Duty Cycle Estimated Battery LifeFull Time Listen 100% 3 DaysFull Time Low_Power Listen 100% 6.54 DaysPeriodic Multi-Hop Listening 10% 65 DaysNo Listen (no Multi-hop) 0.01% Years
Battery Lifetime for sensor reporting every minute
http://tinyos.millennium.berkeley.edu
Sample tradeoffs
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
0
1
1
2
2
3
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