1 system architecture directions for networked sensors (tinyos & mica2) presented by jang young,...
TRANSCRIPT
1
System Architecture Directions for Networked Sensors (TinyOS & Mica2)
Presented by Jang Young, Kim (Chris)
2
Outline Introduction & Motivation Networked Sensor Characteristics H/W & Power Tiny Operating System (TinyOS) TinyOS Design Components Evaluation Mica2 mote programming and TOSSIM Conclusion Discussion
3
Smart Dust
What is TinyOS ?
Operating system developed at UC Berkeley for use with sensor motes
Support sensor motes and ease development of sensor applications
Event-driven architecture Utilizes new programming language
called nesC Currently the standard in sensor OS
5
Networked Sensor
Smaller, cheaper, lower-power communication
Complete systems on a chip Integrated low-power communication Integrated low-power transducers
Networked sensor
6
Motivation General purpose operating systems are not
appropriate for sensor networks Sensor networks require a task specific OS Concurrency intensive Multiple flows move through sensor in parallel Modular design Components connect easily to facilitate
application specific additions/modifications
7
TinyOS
Missing technolygy : the system software support to manage and operate the device.
Address this problem TinyOS Concurrency intensive – several different
flows of data must be kept moving simultaneously
Efficient modularity – hardware specific and application specific components must snap together with little processing and storage overhead
8
TinyOS
178 bytes of memory Propagates events in the time it takes to
copy 1.25 bytes of memory Context switches in the time it takes to copy
6bytes of memory Supports two level scheduling
9
Networked Sensor Characteristics
Small Physical size and low power consumption
Concurrency-intensive Operation Limited Physical Parallelism and Controller
Hierarchy Diversity in Design and Usage Robust Operation
10
Small Physical size and low power consumption
Reducing the size and power required for a given capability are driving factors in the hardware design.
The software must make efficient use of processor and memory while enabling low power communication.
Concurrency-intensive Operation
Information may be simultaneously captured from sensors, manipulated, and streamed onto a network.
11
Limited Physical Parallelism and Controller Hierarchy
The number of independent controllers, the capabilities of the controllers, and the sophistication of the processor-memory-switch level interconnect are much lower than in conventional systems.
The sensor provides a primitive interface directly to a single-chip microcontroller.
In contrast, conventional systems distribute the concurrent processing over multiple levels of controllers.
12
Diversity in Desing and Usage
Sensor devices will tend to be application specific, rather than general purpose, and carry only the available hardware support actually needed for the application.
Robust Operation
This devices will be numerous, largely unattended, and expected to from an application which will be operational a large percentage of the time.
One of the ways of increasing reliability is to tolerate individual device failure.
13
Hardware Organization
Three sleep modes (idle, power down & power save)
Three LEDs to represent outputs Photo-sensor Radio Temperature Sensor Serial Port
14
Photograph and schematic for representative network sensor platform
It consists of a microcontroller with internal flash program memory, data SRAM and data EEPROM, connected to a set of actuator and sensor devices, including LEDs, a low-power radio transceiver, an analog photo-sensor, a digital temperature sensor, a serial port, and a small coprocessor unit.
15
Photograph and schematic for representative network sensor platform
CPU: 4MHz Memory: 8KB flash(data), 512 B SRAM
(program) Network: 19.2 Kbps
Input: temperature andlight sensors
Output: 3 LEDs Serial Interface
16
Three sleep modes (idle, power down & power save)
Idle, which just shuts off the processor.
Power down, which shuts off everything but the watchdog and asynchronous interrupt logic necessary to wake up.
Power save, which is similar to the one above, but leaves an asynchronous timer running.
17
Three LEDs represent outputs
Connected through general I/O ports.
Photo - Sensor
An analog input device which simple control lines.
18
Radio
The most important component. It represents an asynchronous input/output device with
hard real time constraints. Contains no buffering so each bit must be serviced by
the controller on time.
Serial Port
Represents an important asynchronous bit level device with byte-level controller support.
19
Power CharacteristicsBiggest energy drain is radio About 3 orders of magnitude between idle and inactive!
No transition costs documented
Active == Peak Load
20
TinyOS Overview Application = scheduler + graph of components
Compiled into one executable Event-driven architecture Single shared stack No kernel/user space differentiation
Communication
Application (User Components)
Main (includes Scheduler)
21
Tiny Microthreading OS (TinyOS)
Requirements (small physical size, modest active power load & tiny inactive load) An operating system framework is needed that will retain
these characteristics by managing the hardware capabilities effectively, while supporting concurrency-intensive operation in a manner that achieves efficient modularity and robustness.
Two-level scheduling structure
High levels of concurrency
22
Two-level scheduling structure
A small amount of processing associated with hardware events can be performed immediately while long running tasks are interrupted.
Hardware
Interrupts
eve
nts
commands
FIFO
TasksPOST
Preempt
Time
commands
23
Two-level scheduling structure
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
24
Two-level scheduling structure
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
25
Tiny OS Design
Tiny Scheduler Components
Frame Tasks Event Handlers Command Handlers
Messaging Component
Internal StateInternal Tasks
Commands Events
26
Tiny OS Design
Frame It has information related to the current state of the system. Commands, events and tasks execute in the context of the frame.
Tasks Perform the primary work. They are atomic with respect to other tasks and run to completion,
though they can be preempted by events.
Event Handlers Invoked to deal with hardware events, either directly or indirectly.
Command Handlers Non-blocking requests made to lower level components.
27
Components
Messagin
g Com
pon
ent
init
Power(mode)
TX_packet(buf)
TX_packet_done (success)
RX_packet_done (buffer)
Intern
al State
init
power(mode)
send_msg(addr, type, data)
msg_rec(type, data)
msg_send_done (success)
send
_msg_th
read
Block of state
Events signal
commands Set of commands
handlers
28
/* Messaging Component Declaration */
//ACCEPTS: char TOS_COMMAND(AM_send_msg)(int addr, int type, char* data); void TOS_COMMAND(AM_power)(char mode); char TOS_COMMAND(AM_init)();
//SIGNALS: char AM_msg_rec(int 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 TOS_COMMAND(AM_SUB_TX_packet)(char* data); void TOS_COMMAND(AM_SUB_power)(char mode); char TOS_COMMAND(AM_SUB_init)();
29
Component Types
Send_message
TX_Packet
TX_byte
TX_Bit_Event
Msg_Send_Done
TX_Packet_Done
TX_Byte_Done
TX_Bit_Done
30
Component Types
Hardware Abstractions
- RFM Synthetic Hardware
- Radio Byte High Level Software
Components - messaging module
31
Component Types
Hardware Abstractions This component exports commands to manipulate the individual I/O pins
connected to the RFM transceiver and posts events informing other components about the transmission and reception of bits.
Its frame contains information about the current state of the component.
Synthetic Hardware It shifts data into or out of the underlying RFM module and signals when an
entire byte has completed. The internal tasks perform simple encoding and decoding of the data. Conceptually, this component is an enhanced state machine that could be
directly cast into hardware.
High Level Software Components It performs the function of filling in a packet buffer prior to transmission and
dispatches received messages to their appropriate place. Additionally, components that perform calculations on data or data
aggregation fall into this category.
32
Component Types
Two-level scheduler and directed graph of components Component parts Command handlers Respond to higher components Event handlers Respond to lower components Fixed-size frame Size of component is known at compile time Set of tasks Functions to do arbitrary
computation
33
Putting it All Together
A sample configuration of a networked sensor, and the routing topology created by a collection of distributed sensors.
Network sensorLight sensor Temperature sensor
The internal componentgraph of a base station sensor is shown along with the routing topology created by a collection of sensors.
34
Evaluation(1)Code and Data size Breakdown
Small Physical Size
Scheduler: 178 Bytes codeTotals: 3450 Bytes code
226 Bytes data
35
Evaluation(2)Time Breakdown
Concurrency-Intensive Operations
50 cycle thread overhead (6 byte copies)10 cycle event overhead (1.25 byte copes)
36
Evaluation(3) Time Breakdown
Efficient Modularity Events and commands can propagate through
components quickly. Total propagation delay: 40 us
Timing diagram of event propagation
37
Evaluation(4)Power Breakdown
Limited Physical Parallelism and Controller Hierarchy
Diversity in Usage and Robust Operation
What does this mean?Lithium Battery runs for 28 hours at peak load and years at minimum load!All its energy can only support 144KB data
Mica2 mote
Mica2 mote
MICA2 MOTE
Download TinyOS http://www.tinyos.net/tinyos-1.x/doc/install.html
Windows: Uses Cygwin environment to simulate Linux environment More complex than Linux installation (this took some
time) WARNING: TinyOS has problems with newer versions of
Cygwin and prefers older versions for proper functioning Linux:
Preferred as it’s native and faster; Easier setup Simply involves installing several RPMs (for Red Hat) Note that nesc-1.1-1.i386.rpm should be used (the
recommended nesc-1.1.2b-1.i386.rpm gives many compiler errors)
TinyOS installation Installs
nesC compiler and AVR package (processor dependant) Java JDK and Communications package TinyOS software/modules
TinyOS installation (Red Hat) can be found in /opt/tinyos-1.x/ /opt/tinyos-1.x/apps contains example components (such as
Blink) /opt/tinyos-1.x/tools/java contains many java applications that will
be useful later /opt/tinyos-1.x/tools/scripts contains toscheck which can be used
to check installation for correctness Also ensure that you change your PATH variable to include
Blink.ncBlink.nc consists of:
configuration Blink {}implementation { components Main, BlinkM, SingleTimer, LedsC;
Main.StdControl -> BlinkM.StdControl; Main.StdControl -> SingleTimer.StdControl; BlinkM.Timer -> SingleTimer.Timer; BlinkM.Leds -> LedsC;}
Code(1)
configuration Blink { } Specifies this is a configuration file whose name is
Blink implementation {
Indicates that this is where we specify the actual configuration of the component
components Main, BlinkM, SingleTimer, LedsC; A listing of the set of components that this
configuration file references (makes use of)
Code(2) Main.StdControl -> SingleTimer.StdControl;
Main.StdControl -> BlinkM.StdControl; Main is a component and StdControl is an interface it
uses -> symbol indicates that the component on the left “is
wired to” (OR the component on the left “uses”) the component on the right and carries with it two conditions: The component on the right must implement all the
functions provided by the component’s interface on the left The component on the left must implement event handlers
for all the events that the component on the right exports Hence, Main’s StdControl interface uses (is wired to) the
StdControl interfaces provided by (implemented by) both BlinkM and SingleTimer
StdControl Interface Anyone who provides the StdControl
Interface must implement the following 3 functions: StdControl.init(), StdControl.start() and
StdControl.stop() When a mote is started, the first two
functions called are Main.StdControl.init() and Main.StdControl.start() Any modules who implement this interface and are
wired to Main in such a way also have their init and start functions called
The last function called is Main.StdControl.stop() and it will call all the stop functions it is wired to
Code BlinkM.Timer ->
SingleTimer.Timer; Indicates the BlinkM module is wired to
the SingleTimer.Timer interface and hence can utilize all the commands it provides and now as the obligation to respond to any events it exports
BlinkM.Leds -> LedsC;– Similar to the Timer interface, through this line, BlinkM is
now able to utilize the Leds interface (commands that can control the LED lights on the mote)
BlinkM.nc module BlinkM {
provides { interface StdControl; } uses { interface Timer; interface Leds; }}// Code continued on next slide...
Indicates this is a module file (an implementation) that: Provides the StdControl interface (the init(), start() and
stop() functions) Uses the interfaces Timer and Leds (allows it to utilize
the commands and respond to the events generated by those interfaces)
BlinkM.nc implementation {
command result_t StdControl.init() { call Leds.init(); return SUCCESS; }
command result_t StdControl.start() { return call Timer.start(TIMER_REPEAT, 1000) ; }
command result_t StdControl.stop() { return call Timer.stop(); } //Code continued on next slide…
This is the implementation of the module Init() is called when the module is first initialized. It initializes the Led
lights Start() is called when the module is first started. It starts a timer function
that will fire every 1000 milliseconds and repeats doing this till the stop command is called.
Stop() is called when the module is shut off and this stops the timer function
BlinkM.nc event result_t Timer.fired()
{ call Leds.redToggle(); return SUCCESS; }
}//end implementation Since BlinkM uses the timer interface, it must also
provide event handlers for the events that Timer exports Every time the timer fires, we call a command provided
by the Leds interface (a command which toggles the red LED)
Hence, we have created a module that blinks the red LED light on the mote once every second!
TOSSIM cd /opt/tinyos-1.x/apps/Blink - where the
Blink application example is stored make pc – compile the module for use in
TOSSIM simulation on the host pc ./build/pc/main.exe N -run simulation where
N is the number of nodes in the simulation OR ./build/pc/main.exe –rf=lossy.txt N –
where lossy.txt specifies the topology of the nodes By default, in TOSSIM, the nodes are all placed in
virtual reach of each other
Debugging
Debugging Place debug lines in code such as:
dbg(DBG_USR1, "processingRecieve from %d”, source)
export DBG=usr1 This will enable all dbg lines with
DBG_USR1 to be outputted to the screen during simulation runs
51
Conclusion
TinyOS is a highly modular software environment tailored to the requirements of Network Sensors, increasing efficiency, modularity and concurrency.
52
TinyOS Pros & Cons
Small memory footprint Non-preemptable FIFO task scheduling
Power efficient Put microcontroller 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
53
TinyOS Pros & Cons
Lack real-time scheduling Urgent task may wait for non-urgent ones
Lack kernel protection Rely on compile-time analysis Programmer deals with H/W directly Dynamic memory allocation
Lack flexibility Static linking only Cannot change code online Cannot change part of the code
Lack virtual memory Physical memory used
......
54
Any Questions ?