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
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Source :
System Architecture Directions or Networked Sensors - Jason Hill, Robert Szewcyk, Alec Woo, Seth Hollar, David Culler, Kristofer Pister
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
• 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
• 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