Overview of: System Architecture Directions for Networked Sensors John Kerwin CSE 291 Sensor...
-
Upload
collin-grant -
Category
Documents
-
view
217 -
download
0
Transcript of Overview of: System Architecture Directions for Networked Sensors John Kerwin CSE 291 Sensor...
Overview of: System Architecture Directions for
Networked Sensors
John Kerwin
CSE 291 Sensor Networks
Paper by:
Jason Hill, Robert Szewczyk, Alec Woo, Seth Hollar, David Culler, Kris Pister
http://webs.cs.berkeley.edu/tos/
Motivation
Sensor networks are new computing environments in the post-PC era that are different from traditional desktop and server environments.
There are several trends working together to enable the networked sensor: Moore’s Law System on a chip Micro-electromechanical sensors (MEMS) Integrated low power communication
Motivation (cont)
Today, sensors exist on the scale of a square inch in size, and a fraction of a watt in power.
In the future, it may be possible to reduce sensors to the size of a cubic millimeter, or smaller.
The key missing technology for these devices is system software to manage and operate them efficiently.
Project Objectives
Create a prototype of a current generation sensor constructed from off the shelf components.
Identify key requirements that an operating system for such a sensor must satisfy.
Build an operating system that meets these requirements.
Evaluate the operating system’s performance while running a real application.
Today’s Hardware
Assembled from off-the-shelf components
4Mhz, 8bit MCU (ATMEL) 512 bytes RAM, 8KB ROM
900Mhz Radio (RF Monolithics) 10-100 ft. range
Temperature Sensor & Light Sensor
LED outputs Serial Port
1.5” x 1.5”
Slide courtesy Jason Hill et al
Hardware Features
3 Sleep Modes that can shut off the processor and other components not required for wake up.
Radio can transfer data at up to 19 Kbps, with no data buffering.
Sensor consumes about 19.5 mA at peak load, and 10 μA when inactive.
A 575 mAh battery can power a sensor for 30 hours at peak load, or for over a year when inactive.
Image courtesy Jason Hill et al
Operating System Requirements
Small physical size and low power consumption Devices have limited memory and power resources
Concurrency intensive operation Need to be able to service packets on-the-fly in real-time
Limited hardware parallelism and controller hierarchy Limited number, and capability of controllers Unsophisticated processor-memory-switch level
interconnect Diversity in design and usage
Provide a high degree of software modularity for application specific sensors
Robust Operation OS should be reliable, and assist applications in surviving
individual device failures
The Solution: TinyOS
A microthreaded OS that draws on previous work done for lightweight thread support, and efficient network interfaces
Two level scheduling structure Long running tasks that can be interrupted by
hardware events Small, tightly integrated design that allows
crossover of software components into hardware
TinyOS Component Model
Component has:Frame (storage)Tasks (computation)Command and Event
Interface
Messaging Component
Internal StateInternal Tasks
Commands Events
Image courtesy Jason Hill et al
To facilitate modularity, each component declares the commands it uses and the events it signals.
Statically allocated, fixed sized frames allow us to know the memory requirements of a component at compile time, and avoid the overhead associated with dynamic allocation.
Tasks
Perform the primary computation work Atomic with respect to other tasks, and run to
completion, but can be preempted by events Allow the OS to allocate a single stack
assigned to the currently executing task Call lower level commands Signal higher level events Schedule other tasks within a component Simulate concurrency using events
Commands
Non-blocking requests to lower level components
Deposit request parameters into a component’s frame, and post a task for later execution
Can also invoke lower level commands, but cannot block
To avoid cycles, commands cannot signal events
Return status to the caller
Events
Event handlers deal with hardware events (interrupts) directly or indirectly
Deposit information into a frame Post tasks Signal higher level events Call lower level commands
TOS Component
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_SEND_MSG
AM_MSG_REC
AM_MSG_SEND_DONE
Internal Tasks
Commands Events
//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();};
Slide courtesy Jason Hill et al
Putting It All Together
The task scheduler is a simple FIFO scheduler.
The scheduler puts the processor to sleep when the task queue is empty.
Peripherals keep operating and can wake up the processor.
Communication across components takes the form of a function call. This results in low overhead, and allows compile time type checking.
Sample Application
The authors built an application consisting of a number of sensors distributed within a localized area
Monitor temperature and light conditions Periodically transmit measurements to a base
station
Sample Application (cont)
Sensors can forward data for other sensors that are out of range of the base station
Dynamically determine the correct routing topology for the network
Image courtesy Jason Hill et al
Internal Component Graph
Slide courtesy Jason Hill et al
RFM
Radio byte
Radio Packet
UART
Serial Packet
I2C
Temp
Photo
Active Messages
Clocksbit
byte
packet
Ad hoc Routing Applicationapplication
HW
SW
Ad hoc Routing
0Base
1
1
2
2
3
Base station periodically broadcasts route updates Any sensors in range of this broadcast record the
identity of the base station, and rebroadcast the update
Each sensor remembers the first update received in an era, and uses the source of the update as the destination for routing data back to the base station
Image courtesy Jason Hill et al
Evaluation: Small Physical Size
Component Name Code Size (bytes)
Data Size (bytes)
Multihop router
AM_dispatch
AM_temperature
AM_light
AM
Packet
RADIO_byte
RFM
Photo
Temperature
UART
UART_packet
I2C_bus
88
40
78
146
356
334
810
310
84
64
196
314
198
0
0
32
8
40
40
8
1
1
1
1
40
8
Processor_init
TinyOS scheduler
C runtime
172
178
82
30
16
0
Total 3450 226
Scheduler only occupies 178 bytes
Complete application only requires 3 KB of instruction memory and 226 bytes of data (less than 50% of the 512 bytes available)
Only processor_init, TinyOS scheduler, and C runtime are required
Evaluation: Concurrency Intensive Operations
Operations Cost (cycles)
Time (µs)
Normalized to byte copy
Byte copy 8 2 1
Post an Event
Call a Command
Post a task to scheduler
Context switch overhead
10
10
46
51
2.5
2.5
11.5
12.75
1.25
1.25
6
6
Interrupt (hardware cost) 9 2.25 1
Interrupt (software cost) 71 17.75 9
Low overhead is essential for achieving modular efficiency
Cost of posting an event = cost of copying 1 byte of data
Cost of posting a task or context switching is the same as copying 6 bytes of data
Interrupt handling requires saving and storing registers
Efficient Modularity
Message Send Transition Total propagation delay up the 5 layer radio
communication stack is about 80 instructions
Timing diagram of event propagationSlide courtesy Jason Hill et al
Evaluation: Limited Hardware Parallelism and Controller Hierarchy
Successfully demonstrated a system with multiple flows of data running through a single microcontroller
ComponentsPacket reception work breakdown CPU Utilization Energy (nj/Bit)
AM 0.05% 0.20% 0.33
Packet 1.12% 0.51% 7.58
Radio handler 26.87% 12.16% 182.38
Radio decode thread 5.48% 2.48% 37.2
RFM 66.48% 30.08% 451.17
Radio Reception - - 1350
Idle - 54.75% -
Total 100.00% 100.00% 2028.66
Slide courtesy Jason Hill et al
Evaluation: Diversity in Usage and Robust Operation
Created several sample applications that exploit the modular structure of the systemSource based multi-hop routing applicationsActive-badge-like location detection applicationsSensor network monitoring applications
C programming language allows the ability to target multiple CPU architectures in future systems
Robustness: Multihop routing application automatically reconfigures itself to withstand individual node failures
Slide courtesy Jason Hill et al
Conclusions
TinyOS is a highly modular software environment tailored to the requirements of Network Sensors, stressing efficiency, modularity, and concurrency.
TinyOS should be able to support new sensor devices as they evolve.
Running an application on TinyOS can help reveal the impact of architectural changes in the underlying hardware, making it easier to design hardware that is optimized for a particular application.