Ad hoc and Sensor Networks Chapter 2: Single node architecture - PowerPoint PPT Presentation

Loading...

PPT – Ad hoc and Sensor Networks Chapter 2: Single node architecture PowerPoint presentation | free to download - id: 210824-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Ad hoc and Sensor Networks Chapter 2: Single node architecture

Description:

Putting into perspective different operational modes and what different energy ... quite specific to WSN; energy consumption principles carry over to MANET as well ... – PowerPoint PPT presentation

Number of Views:701
Avg rating:3.0/5.0
Slides: 119
Provided by: Holg152
Learn more at: http://ube.ege.edu.tr
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Ad hoc and Sensor Networks Chapter 2: Single node architecture


1
Ad hoc and Sensor NetworksChapter 2 Single node
architecture
  • Holger Karl

2
Goals of this chapter
  • Survey the main components of the composition of
    a node for a wireless sensor network
  • Controller, radio modem, sensors, batteries
  • Understand energy consumption aspects for these
    components
  • Putting into perspective different operational
    modes and what different energy/power consumption
    means for protocol design
  • Operating system support for sensor nodes
  • Some example nodes
  • Note The details of this chapter are quite
    specific to WSN energy consumption principles
    carry over to MANET as well

3
Outline
  • Sensor node architecture
  • Energy supply and consumption
  • Runtime environments for sensor nodes
  • Case study TinyOS

4
Sensor node architecture
  • Main components of a WSN node
  • Controller
  • Communication device(s)
  • Sensors/actuators
  • Memory
  • Power supply

Memory
Sensor(s)/actuator(s)
Communicationdevice
Controller
Power supply
5
Ad hoc node architecture
  • Core essentially the same
  • But Much more additional equipment
  • Hard disk, display, keyboard, voice interface,
    camera,
  • Essentially a laptop-class device

6
Controller
  • Main options
  • Microcontroller general purpose processor,
    optimized for embedded applications, low power
    consumption
  • DSPs optimized for signal processing tasks, not
    suitable here
  • FPGAs may be good for testing
  • ASICs only when peak performance is needed, no
    flexibility
  • Example microcontrollers
  • Texas Instruments MSP430
  • 16-bit RISC core, up to 4 MHz, versions with 2-10
    kbytes RAM, several DACs, RT clock, prices start
    at 0.49 US
  • Atmel ATMega
  • 8-bit controller, larger memory than MSP430,
    slower

7
Custom single-purpose processor basic model
8
Example greatest common divisor
  • First create algorithm
  • Convert algorithm to complex state machine
  • Known as FSMD finite-state machine with datapath
  • Can use templates to perform such conversion

(c) state diagram
(b) desired functionality
0 int x, y 1 while (1) 2 while
(!go_i) 3 x x_i 4 y y_i 5 while
(x ! y) 6 if (x lt y) 7
y y - x else 8
x x - y 9 d_o x
9
State diagram templates
10
Creating the datapath
  • Create a register for any declared variable
  • Create a functional unit for each arithmetic
    operation
  • Connect the ports, registers and functional units
  • Based on reads and writes
  • Use multiplexors for multiple sources
  • Create unique identifier
  • for each datapath component control input and
    output

11
Creating the controllers FSM
  • Same structure as FSMD
  • Replace complex actions/conditions with datapath
    configurations

12
Splitting into a controller and datapath
go_i
Controller
!1
1
0000
1
!(!go_i)
2
0001
!go_i
2-J
0010
x_sel 0 x_ld 1
3
0011
y_sel 0 y_ld 1
4
0100
x_neq_y0
5
0101
x_neq_y1
6
0110
x_lt_y1
x_lt_y0
y_sel 1 y_ld 1
x_sel 1 x_ld 1
7
8
0111
1000
6-J
1001
5-J
1010
d_ld 1
9
1011
1-J
1100
13
Controller state table for the GCD example
14
Completing the GCD custom single-purpose
processor design
  • We finished the datapath
  • We have a state table for the next state and
    control logic
  • All thats left is combinational logic design
  • This is not an optimized design, but we see the
    basic steps

15
Communication device
  • Which transmission medium?
  • Electromagnetic at radio frequencies?
  • Electromagnetic, light?
  • Ultrasound?
  • Radio transceivers transmit a bit- or byte stream
    as radio wave
  • Receive it, convert it back into bit-/byte stream

ü
16
Transceiver characteristics
  • Capabilities
  • Interface bit, byte, packet level?
  • Supported frequency range?
  • Typically, somewhere in 433 MHz 2.4 GHz, ISM
    band
  • Multiple channels?
  • Data rates?
  • Range?
  • Energy characteristics
  • Power consumption to send/receive data?
  • Time and energy consumption to change between
    different states?
  • Transmission power control?
  • Power efficiency (which percentage of consumed
    power is radiated?)
  • Radio performance
  • Modulation? (ASK, FSK, ?)
  • Noise figure? NF SNRI/SNRO
  • Gain? (signal amplification)
  • Receiver sensitivity? (minimum S to achieve a
    given Eb/N0)
  • Blocking performance (achieved BER in presence of
    frequency-offset interferer)
  • Out of band emissions
  • Carrier sensing RSSI characteristics
  • Frequency stability (e.g., towards temperature
    changes)
  • Voltage range

17
Transceiver states
  • Transceivers can be put into different
    operational states, typically
  • Transmit
  • Receive
  • Idle ready to receive, but not doing so
  • Some functions in hardware can be switched off,
    reducing energy consumption a little
  • Sleep significant parts of the transceiver are
    switched off
  • Not able to immediately receive something
  • Recovery time and startup energy to leave sleep
    state can be significant
  • Research issue Wakeup receivers can be woken
    via radio when in sleep state (seeming
    contradiction!)

18
Example radio transceivers
  • Almost boundless variety available
  • Some examples
  • RFM TR1000 family
  • 916 or 868 MHz
  • 400 kHz bandwidth
  • Up to 115,2 kbps
  • On/off keying or ASK
  • Dynamically tuneable output power
  • Maximum power about 1.4 mW
  • Low power consumption
  • Chipcon CC1000
  • Range 300 to 1000 MHz, programmable in 250 Hz
    steps
  • FSK modulation
  • Provides RSSI
  • Chipcon CC 2400
  • Implements 802.15.4
  • 2.4 GHz, DSSS modem
  • 250 kbps
  • Higher power consumption than above transceivers
  • Infineon TDA 525x family
  • E.g., 5250 868 MHz
  • ASK or FSK modulation
  • RSSI, highly efficient power amplifier
  • Intelligent power down, self-polling mechanism
  • Excellent blocking performance

19
Example radio transceivers for ad hoc networks
  • Ad hoc networks Usually, higher data rates are
    required
  • Typical IEEE 802.11 b/g/a is considered
  • Up to 54 MBit/s
  • Relatively long distance (100s of meters
    possible, typical 10s of meters at higher data
    rates)
  • Works reasonably well (but certainly not perfect)
    in mobile environments
  • Problem expensive equipment, quite power hungry

20
Wakeup receivers
  • Major energy problem RECEIVING
  • Idling and being ready to receive consumes
    considerable amounts of power
  • When to switch on a receiver is not clear
  • Contention-based MAC protocols Receiver is
    always on
  • TDMA-based MAC protocols Synchronization
    overhead, inflexible
  • Desirable Receiver that can (only) check for
    incoming messages
  • When signal detected, wake up main receiver for
    actual reception
  • Ideally Wakeup receiver can already process
    simple addresses
  • Not clear whether they can be actually built,
    however

21
Optical communication
  • Optical communication can consume less energy
  • Example passive readout via corner cube
    reflector
  • Laser is reflected back directly to source if
    mirrors are at right angles
  • Mirrors can be titled to stop reflecting
  • ! Allows data to be sent back to laser source

22
Ultra-wideband communication
  • Standard radio transceivers Modulate a signal
    onto a carrier wave
  • Requires relatively small amount of bandwidth
  • Alternative approach Use a large bandwidth, do
    not modulate, simply emit a burst of power
  • Forms almost rectangular pulses
  • Pulses are very short
  • Information is encoded in the presence/absence of
    pulses
  • Requires tight time synchronization of receiver
  • Relatively short range (typically)
  • Advantages
  • Pretty resilient to multi-path propagation
  • Very good ranging capabilities
  • Good wall penetration

23
Sensors as such
  • Main categories
  • Any energy radiated? Passive vs. active sensors
  • Sense of direction? Omidirectional?
  • Passive, omnidirectional
  • Examples light, thermometer, microphones,
    hygrometer,
  • Passive, narrow-beam
  • Example Camera
  • Active sensors
  • Example Radar
  • Important parameter Area of coverage
  • Which region is adequately covered by a given
    sensor?

24
Outline
  • Sensor node architecture
  • Energy supply and consumption
  • Runtime environments for sensor nodes
  • Case study TinyOS

25
Energy supply of mobile/sensor nodes
  • Goal provide as much energy as possible at
    smallest cost/volume/weight/recharge
    time/longevity
  • In WSN, recharging may or may not be an option
  • Options
  • Primary batteries not rechargeable
  • Secondary batteries rechargeable, only makes
    sense in combination with some form of energy
    harvesting
  • Requirements include
  • Low self-discharge
  • Long shelf live
  • Capacity under load
  • Efficient recharging at low current
  • Good relaxation properties (seeming
    self-recharging)
  • Voltage stability (to avoid DC-DC conversion)

26
Battery examples
  • Energy per volume (Joule per cubic centimeter)

Primary batteries Primary batteries Primary batteries Primary batteries
Chemistry Zinc-air Lithium Alkaline
Energy (J/cm3) 3780 2880 1200
Secondary batteries Secondary batteries Secondary batteries Secondary batteries
Chemistry Lithium NiMHd NiCd
Energy (J/cm3) 1080 860 650
27
Energy scavenging
  • How to recharge a battery?
  • A laptop easy, plug into wall socket in the
    evening
  • A sensor node? Try to scavenge energy from
    environment
  • Ambient energy sources
  • Light ! solar cells between 10 ?W/cm2 and 15
    mW/cm2
  • Temperature gradients 80 ? W/cm2 _at_ 1 V from 5K
    difference
  • Vibrations between 0.1 and 10000 ? W/cm3
  • Pressure variation (piezo-electric) 330 ? W/cm2
    from the heel of a shoe
  • Air/liquid flow (MEMS gas turbines)

28
Energy scavenging overview
29
Energy consumption
  • A back of the envelope estimation
  • Number of instructions
  • Energy per instruction 1 nJ
  • Small battery (smart dust) 1 J 1 Ws
  • Corresponds 109 instructions!
  • Lifetime
  • Or Require a single day operational lifetime
    246060 86400 s
  • 1 Ws / 86400s ¼ 11.5 ?W as max. sustained power
    consumption!
  • Not feasible!

30
Multiple power consumption modes
  • Way out Do not run sensor node at full operation
    all the time
  • If nothing to do, switch to power safe mode
  • Question When to throttle down? How to wake up
    again?
  • Typical modes
  • Controller Active, idle, sleep
  • Radio mode Turn on/off transmitter/receiver,
    both
  • Multiple modes possible, deeper sleep modes
  • Strongly depends on hardware
  • TI MSP 430, e.g. four different sleep modes
  • Atmel ATMega six different modes

31
Some energy consumption figures
  • Microcontroller
  • TI MSP 430 (_at_ 1 MHz, 3V)
  • Fully operation 1.2 mW
  • Deepest sleep mode 0.3 ?W only woken up by
    external interrupts (not even timer is running
    any more)
  • Atmel ATMega
  • Operational mode 15 mW active, 6 mW idle
  • Sleep mode 75 ?W

32
Switching between modes
  • Simplest idea Greedily switch to lower mode
    whenever possible
  • Problem Time and power consumption required to
    reach higher modes not negligible
  • Introduces overhead
  • Switching only pays off if Esaved gt Eoverhead
  • Example Event-triggered wake up from sleep
    mode
  • Scheduling problem with uncertainty (exercise)

33
Alternative Dynamic voltage scaling
  • Switching modes complicated by uncertainty how
    long a sleep time is available
  • Alternative Low supply voltage clock
  • Dynamic voltage scaling (DVS)
  • Rationale
  • Power consumption P depends on
  • Clock frequency
  • Square of supply voltage
  • P / f V2
  • Lower clock allows lower supply voltage
  • Easy to switch to higher clock
  • But execution takes longer

34
Memory power consumption
  • Crucial part FLASH memory
  • Power for RAM almost negligible
  • FLASH writing/erasing is expensive
  • Example FLASH on Mica motes
  • Reading ¼ 1.1 nAh per byte
  • Writing ¼ 83.3 nAh per byte

35
Transmitter power/energy consumption for n bits
  • Amplifier power Pamp ?amp ?amp Ptx
  • Ptx radiated power
  • ?amp, ?amp constants depending on model
  • Highest efficiency (? Ptx / Pamp ) at maximum
    output power
  • In addition transmitter electronics needs power
    PtxElec
  • Time to transmit n bits n / (R Rcode)
  • R nomial data rate, Rcode coding rate
  • To leave sleep mode
  • Time Tstart, average power Pstart
  • ! Etx Tstart Pstart n / (R Rcode) (PtxElec
    ?amp ?amp Ptx)
  • Simplification Modulation not considered

36
Receiver power/energy consumption for n bits
  • Receiver also has startup costs
  • Time Tstart, average power Pstart
  • Time for n bits is the same n / (R Rcode)
  • Receiver electronics needs PrxElec
  • Plus energy to decode n bits EdecBits
  • ! Erx Tstart Pstart n / (R Rcode) PrxElec
    EdecBits ( R )

37
Some transceiver numbers
38
Comparison GSM base station power consumption
  • Overview
  • Details
  • (just to put things into perspective)

39
Controlling transceivers
  • Similar to controller, low duty cycle is
    necessary
  • Easy to do for transmitter similar problem to
    controller when is it worthwhile to switch off
  • Difficult for receiver Not only time when to
    wake up not known, it also depends on remote
    partners
  • ! Dependence between MAC protocols and power
    consumption is strong!
  • Only limited applicability of techniques analogue
    to DVS
  • Dynamic Modulation Scaling (DSM) Switch to
    modulation best suited to communication depends
    on channel gain
  • Dynamic Coding Scaling vary coding rate
    according to channel gain
  • Combinations

40
Computation vs. communication energy cost
  • Tradeoff?
  • Directly comparing computation/communication
    energy cost not possible
  • But put them into perspective!
  • Energy ratio of sending one bit vs. computing
    one instruction Anything between 220 and 2900
    in the literature
  • To communicate (send receive) one kilobyte
    computing three million instructions!
  • Hence try to compute instead of communicate
    whenever possible
  • Key technique in WSN in-network processing!
  • Exploit compression schemes, intelligent coding
    schemes,

41
WSN Platforms Hardware Software
  • Murat Demirbas
  • Lecture uses some slides from tutorials prepared
    by authors of these platforms

42
Why use a WSN?
  • Ease of deployment
  • Wireless communication means no need for a
    communication infrastructure setup
  • Drop and play
  • Low-cost of deployment
  • Nodes are built using off-the-shelf cheap
    components
  • Fine grain monitoring
  • Feasible to deploy nodes densely for fine grain
    monitoring

43
Outline
  • Hardware
  • RFID, Spec
  • Mica2, XSM, Telos
  • Stargate
  • Software
  • TinyOS
  • Simulation
  • TOSSIM
  • Prowler

44
Types of sensor platforms
  • RFID equipped sensors
  • Smart-dust tags
  • typically act as data-collectors or trip-wires
  • limited processing and communications
  • Mote/Stargate-scale nodes
  • more flexible processing and communications
  • More powerful gateway nodes, potentially using
    wall power

45
Popular Nodes Overview
46
Grain-sized nodes
  • Powered by inductive coupling to a transmission
    from a reader device to transmit a message back
  • Available commercially at very low prices
  • Computation power is severely limited
  • Can only trasmit stored unique id and variable
  • Hard to add any interesting sensing capability

47
Spec Mote (3/6/2003)
  • size 2x2.5mm, AVR RISC core, 3KB memory, FSK
    radio (CC1000), encrypted communication hardware
    support, memory-mapped active messages

48
Matchbox-sized nodes
  • Mica series, XSM node, Telos
  • 8-bit microprocessor, 4MHz CPU
  • ATMEGA 128, ATMEL 8535, or Motorola HCS08
  • 4Kb RAM
  • holds run-time state (values of the variables) of
    the program
  • 128Kb programmable Flash memory
  • holds the application program
  • Downloaded via a programmer-board or wirelessly
  • Additional Flash memory storage space up to
    512Kb.

49
Mica2 and Mica2Dot
  • ATmega128 CPU
  • Self-programming
  • Chipcon CC1000
  • FSK
  • Manchester encoding
  • Tunable frequency
  • Low power consumption
  • 2 AA battery 3V

1 inch
50
Basic Sensor Board
  • Light (Photo)
  • Temperature
  • Prototyping space for new hardware designs

51
Mica Sensor Board
  • Light (Photo)
  • Temperature
  • Acceleration
  • 2 axis
  • Resolution 2mg
  • Magnetometer
  • Resolution 134mG
  • Microphone
  • Tone Detector
  • Sounder
  • 4.5kHz

52
PNI Magnetometer/Compass
  • Resolution 400 mGauss
  • Three axis, under 15 in large quantities

53
Ultrasonic Transceiver
  • Used for ranging
  • Up to 2.5m range
  • 6cm accuracy
  • Dedicated microprocessor
  • 25kHz element

54
Mica Weather Board
  • Total Solar Radiation
  • Photosynthetically Active Radiation
  • Resolution 0.3A/W
  • Relative Humidity
  • Accuracy 2
  • Barometric Pressure
  • Accuracy 1.5mbar
  • Temperature
  • Accuracy 0.01oC
  • Acceleration
  • 2 axis
  • Resolution 2mg
  • Designed by UCB w/ Crossbow and UCLA

Revision 1.5
Revision 1.0
55
MicaDot Sensor Boards
Dot sensorboards (1diameter) HoneyDot
Magnetometer Resolution 134 mGauss Ultrasonic
Transceiver Weather Station
56
XSM node platform
  • Derived from Mica2 mote
  • Better sensor actuator range
  • 4 Passive Infrared 25m for SUV
  • Sounder 10m
  • Microphone 50m for ATV
  • Magnetometer 7m for SUV
  • Better radio range 30m
  • Other features
  • Grenade timer
  • Wakeup circuits (Mic, PIR)
  • Adjustable frequency sounder
  • Integrated Mag Set/Reset

57
Telos Platform
  • Low Power
  • Minimal port leakage
  • Hardware isolation and buffering
  • Robust
  • Hardware flash write protection
  • Integrated antenna (50m-125m)
  • Standard IDC connectors
  • Standards Based
  • USB
  • IEEE 802.15.4 (CC2420 radio)
  • High Performance
  • 10kB RAM, 16-bit core, extensive double buffering
  • 12-bit ADC and DAC (200ksamples/sec)
  • DMA transfers while CPU off

58
TelosMeeting the Low Power Goal
All values measured at room temperature
(approximately 25oC) at 3V supply voltage Source
Telos Enabling Low Power Wireless Sensor
Network ResearchTo appear, IPSN/SPOTS, April
2005
59
Telos Performance
  • 200ksamples/sec sampling rate, DMA transfers, DAC
  • Increased performance functionality over
    existing designs
  • New link quality indicator predicts average
    packet loss

Flat field range test _at_ 4 off ground (125m _at_ 1m
elevation)
60
Brick-sized node Stargate
  • Mini Linux computers communicating via 802.11
    radios
  • Computationally powerful
  • High bandwidth
  • Requires more energy (AA infeasible)
  • Used as a gateway between the Internet and WSN

61
Stargate
62
Manufacturers of Sensor Nodes
  • Crossbow (www.xbow.com)
  • Mica2 mote, Micaz, Dot mote and Stargate Platform
  • Intel Research
  • Stargate, iMote
  • Moteiv Telos Mote
  • Dust Inc
  • Smart Dust
  • Cogent Computer (www.cogcomp.com)
  • XYZ Node (CSB502) in collaboration with
    ENALAB_at_Yale
  • Sensoria Corporation (www.sensoria.com)
  • WINS NG Nodes
  • Millenial Net (www.millenial.com)
  • iBean sensor nodes
  • Ember (www.ember.com)
  • Integrated IEEE 802.15.4 stack and radio on a
    single chip

63
Challenges in sensor networks
  • Energy constraint
  • Unreliable communication
  • Unreliable sensors
  • Ad hoc deployment
  • Large scale networks
  • Limited computation power
  • Distributed execution
  • Nodes are battery powered
  • Radio broadcast, limited bandwidth, bursty
    traffic
  • False positives
  • Pre-configuration inapplicable
  • Algorithms should scale well
  • Centralized algorithms inapplicable
  • Difficult to debug get it right

64
Opportunities in sensor networks
  • Precise clock at each node
  • Atomic broadcast primitive
  • Geometry
  • New applications
  • Timers, synchronized clocks
  • All recipients hear the same message at the same
    time
  • Dense nodes over 2D plane
  • Tracking, spatial querying, geographic routing,
    localization, network reprogramming, etc.

65
Outline
  • Sensor node architecture
  • Energy supply and consumption
  • Runtime environments for sensor nodes
  • Case study TinyOS

66
Operating system challenges in WSN
  • Usual operating system goals
  • Make access to device resources abstract
    (virtualization)
  • Protect resources from concurrent access
  • Usual means
  • Protected operation modes of the CPU hardware
    access only in these modes
  • Process with separate address spaces
  • Support by a memory management unit
  • Problem These are not available in
    microcontrollers
  • No separate protection modes, no memory
    management unit
  • Would make devices more expensive, more
    power-hungry
  • ! ???

67
Operating system challenges in WSN
  • Possible options
  • Try to implement as close to an operating
    system on WSN nodes
  • In particular, try to provide a known programming
    interface
  • Namely support for processes!
  • Sacrifice protection of different processes from
    each other
  • ! Possible, but relatively high overhead
  • Do (more or less) away with operating system
  • After all, there is only a single application
    running on a WSN node
  • No need to protect malicious software parts from
    each other
  • Direct hardware control by application might
    improve efficiency
  • Currently popular verdict no OS, just a simple
    run-time environment
  • Enough to abstract away hardware access details
  • Biggest impact Unusual programming model

68
Main issue How to support concurrency
  • Simplest option No concurrency, sequential
    processing of tasks
  • Not satisfactory Risk of missing data (e.g.,
    from transceiver) when processing data, etc.
  • ! Interrupts/asynchronous operation has to be
    supported
  • Why concurrency is needed
  • Sensor nodes CPU has to service the radio modem,
    the actual sensors, perform computation for
    application, execute communication protocol
    software, etc.

69
Traditional concurrency Processes
  • Traditional OS processes/threads
  • Based on interrupts, context switching
  • But not available memory overhead, execution
    overhead
  • But concurrency mismatch
  • One process per protocol entails too many context
    switches
  • Many tasks in WSN small with respect to context
    switching overhead
  • And protection between processes not needed in
    WSN
  • Only one application anyway

70
Event-based concurrency
  • Alternative Switch to event-based programming
    model
  • Perform regular processing or be idle
  • React to events when they happen immediately
  • Basically interrupt handler
  • Problem must not remain in interrupt handler too
    long
  • Danger of loosing events
  • Only save data, post information that event has
    happened, then return
  • ! Run-to-completion principle
  • Two contexts one for handlers, one for regular
    execution

71
Components instead of processes
  • Need an abstraction to group functionality
  • Replacing processes for this purpose
  • E.g. individual functions of a networking
    protocol
  • One option Components
  • Here In the sense of TinyOS
  • Typically fulfill only a single, well-defined
    function
  • Main difference to processes
  • Component does not have an execution
  • Components access same address space, no
    protection against each other
  • NOT to be confused with component-based
    programming!

72
API to an event-based protocol stack
  • Usual networking API sockets
  • Issue blocking calls to receive data
  • Ill-matched to event-based OS
  • Also networking semantics in WSNs not
    necessarily well matched to/by socket semantics
  • API is therefore also event-based
  • E.g. Tell some component that some other
    component wants to be informed if and when data
    has arrived
  • Component will be posted an event once this
    condition is met
  • Details see TinyOS example discussion below

73
Dynamic power management
  • Exploiting multiple operation modes is promising
  • Question When to switch in power-safe mode?
  • Problem Time energy overhead associated with
    wakeup greedy sleeping is not beneficial (see
    exercise)
  • Scheduling approach
  • Question How to control dynamic voltage scaling?
  • More aggressive stepping up voltage/frequency is
    easier
  • Deadlines usually bound the required speed form
    below
  • Or Trading off fidelity vs. energy consumption!
  • If more energy is available, compute more
    accurate results
  • Example Polynomial approximation
  • Start from high or low exponents depending where
    the polynomial is to be evaluated

74
Outline
  • Sensor node architecture
  • Energy supply and consumption
  • Runtime environments for sensor nodes
  • Case study TinyOS

75
Case study embedded OS TinyOS nesC
  • TinyOS developed by UC Berkely as runtime
    environment for their motes
  • nesC as adjunct programming language
  • Goal Small memory footprint
  • Sacrifices made e.g. in ease of use, portability
  • Portability somewhat improved in newer version
  • Most important design aspects
  • Component-based system
  • Components interact by exchanging asynchronous
    events
  • Components form a program by wiring them together
    (akin to VHDL hardware description language)

76
TinyOS components
  • Components
  • Frame state information
  • Tasks normal execution program
  • Command handlers
  • Event handlers
  • Handlers
  • Must run to completion
  • Form a components interface
  • Understand and emits commands events
  • Hierarchically arranged
  • Events pass upward from hardware to higher-level
    components
  • Commands are passed downward

77
Handlers versus tasks
  • Command handlers and events must run to
    completion
  • Must not wait an indeterminate amount of time
  • Only a request to perform some action
  • Tasks, on the other hand, can perform arbitrary,
    long computation
  • Also have to be run to completion since no
    non-cooperative multi-tasking is implemented
  • But can be interrupted by handlers
  • ! No need for stack management, tasks are atomic
    with respect to each other

78
Split-phase programming
  • Handler/task characteristics and separation has
    consequences on programming model
  • How to implement a blocking call to another
    component?
  • Example Order another component to send a packet
  • Blocking function calls are not an option
  • ! Split-phase programming
  • First phase Issue the command to another
    component
  • Receiving command handler will only receive the
    command, post it to a task for actual execution
    and returns immediately
  • Returning from a command invocation does not mean
    that the command has been executed!
  • Second phase Invoked component notifies invoker
    by event that command has been executed
  • Consequences e.g. for buffer handling
  • Buffers can only be freed when completion event
    is received

79
Structuring commands/events into interfaces
  • Many commands/events can add up
  • nesC solution Structure corresponding
    commands/events into interface types
  • Example Structure timer into three interfaces
  • StdCtrl
  • Timer
  • Clock
  • Build configurations by wiring together
    corresponding interfaces

80
Building components out of simpler ones
  • Wire together components to form more complex
    components out of simpler ones
  • New interfaces for the complex component

81
Defining modules and components in nesC
82
Wiring components to form a configuration
83
TinyOS
  • most popular operating system for WSN
  • developed by UC Berkeley
  • features a component-based architecture
  • software is written in modular pieces called
    components
  • Each component denotes the interfaces that it
    provides
  • An interface declares a set of functions called
    commands that the interface provider implements
    and another set of functions called events that
    the interface user should be ready to handle
  • Easy to link components together by wiring
    their interfaces to form larger components
  • similar to using Lego blocks

84
TinyOS
  • provides a component library that includes
    network protocols, services, and sensor drivers
  • An application consists of
  • a component written by the application developer
    and
  • the library components that are used by the
    components in (1)
  • An application developer writes only the
    application component that describes the sensors
    used in the application, the middleware services
    configured with the appropriate parameters based
    on the needs of the application

85
Benefits of using TinyOS
  • Separation of concerns
  • TinyOS provides a proper networking stack for
    wireless communication that abstracts away the
    underlying problems and complexity of message
    transfer from the application developer
  • E.g., MAC layer
  • Concurrency control
  • TinyOS provides a scheduler that achieves
    efficient concurrency control
  • An interrupt-driven execution model is needed to
    achieve a quick response time for the events and
    capture the data
  • For example, a message transmission may take up
    to 100msec, and without an interrupt-driven
    approach the node would miss sensing and
    processing of interesting data in this period
  • Scheduler takes care of the intricacies of
    interrupt-driven execution and provides
    concurrency in a safe manner by scheduling the
    execution in small threads.

86
Benefits of TinyOS
  • Modularity
  • TinyOSs component model facilitates reuse and
    reconfigurability since software is written in
    small functional modules. Several middleware
    services are available as well-documented
    components
  • Over 500 research groups and companies are using
    TinyOS and numerous groups are actively
    contributing code to the public domain

87
TinyOS
  • Microthreaded OS (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

88
TinyOS Concepts
  • Scheduler Graph of Components
  • constrained two-level scheduling model threads
    events
  • Component
  • Commands
  • Event Handlers
  • Frame (storage)
  • Tasks (concurrency)
  • Constrained Storage Model
  • frame per component, shared stack, no heap
  • Very lean multithreading
  • Efficient Layering

Events
Commands
send_msg(addr, type, data)
power(mode)
init
Messaging Component
Internal State
internal thread
TX_packet(buf)
Power(mode)
init
RX_packet_done (buffer)
TX_packet_done (success)
89
Application Graph of Components
Route map
Router
Sensor Appln
application
Active Messages
Example ad hoc, multi-hop routing of photo
sensor readings
Serial Packet
Radio Packet
packet
Temp
Photo
SW
3450 B code 226 B data
HW
UART
Radio byte
ADC
byte
clock
RFM
bit
Graph of cooperating state machines on shared
stack
90
TOS Execution Model
  • commands request action
  • ack/nack at every boundary
  • call command or post task
  • events notify occurrence
  • HW interrupt at lowest level
  • may signal events
  • call commands
  • post tasks
  • tasks provide logical concurrency
  • preempted by events

data processing
application comp
message-event driven
active message
event-driven packet-pump
crc
event-driven byte-pump
encode/decode
event-driven bit-pump
91
Event-Driven Sensor Access Pattern
command result_t StdControl.start() return
call Timer.start(TIMER_REPEAT, 200) event
result_t Timer.fired() return call
sensor.getData() event result_t
sensor.dataReady(uint16_t data)
display(data) return SUCCESS
SENSE
LED
Photo
Timer
  • clock event handler initiates data collection
  • sensor signals data ready event
  • data event handler calls output command
  • device sleeps or handles other activity while
    waiting
  • conservative send/ack at component boundary

92
TinyOS Commands and Events
... status call CmdName(args) ...
command CmdName(args) ... return status
event EvtName(args) ... return status
... status signal EvtName(args) ...
93
TinyOS Execution Contexts
  • Events generated by interrupts preempt tasks
  • Tasks do not preempt tasks
  • Both essential process state transitions

94
Tasks
  • provide concurrency internal to a component
  • longer running operations
  • are preempted by events
  • able to perform operations beyond event context
  • may call commands
  • may signal events
  • not preempted by tasks

... post TskName() ...
task void TskName ...
95
Typical Application Use of Tasks
  • event driven data acquisition
  • schedule task to do computational portion

event result_t sensor.dataReady(uint16_t data)
putdata(data) post processData()
return SUCCESS task void processData()
int16_t i, sum0 for (i0 i maxdata
i) sum (rdatai 7)
display(sum shiftdata)
96
Task Scheduling
  • Currently simple fifo scheduler
  • Bounded number of pending tasks
  • When idle, shuts down node except clock
  • Uses non-blocking task queue data structure
  • Simple event-driven structure control over
    complete application/system graph
  • instead of complex task priorities

97
Maintaining Scheduling Agility
  • Need logical concurrency at many levels of the
    graph
  • While meeting hard timing constraints
  • sample the radio in every bit window
  • Retain event-driven structure throughout
    application
  • Tasks extend processing outside event window
  • All operations are non-blocking

98
The Complete Application
SenseToRfm
generic comm
IntToRfm
AMStandard
RadioCRCPacket
UARTnoCRCPacket
packet
noCRCPacket
photo
Timer
MicaHighSpeedRadioM
phototemp
SecDedEncode
SW
byte
RandomLFSR
SPIByteFIFO
HW
ADC
UART
ClockC
bit
SlavePin
99
Programming Syntax
  • TinyOS 2.0 is written in an extension of C,
    called nesC
  • Applications are too
  • just additional components composed with OS
    components
  • Provides syntax for TinyOS concurrency and
    storage model
  • commands, events, tasks
  • local frame variable
  • Compositional support
  • separation of definition and linkage
  • robustness through narrow interfaces and reuse
  • Interpositioning
  • Whole system analysis and optimization

100
Components
  • A component specifies a set of interfaces by
    which it is connected to other components
  • provides a set of interfaces to others
  • uses a set of interfaces provided by others
  • Interfaces are bidirectional
  • include commands and events
  • Interface methods are the external namespace of
    the component

provides
StdControl
Timer
provides interface StdControl interface
Timer uses interface Clock
Timer Component
Clock
uses
101
Component Interface
  • logically related set of commands and events

StdControl.nc interface StdControl
command result_t init() command result_t
start() command result_t stop()
Clock.nc interface Clock command result_t
setRate(char interval, char scale) event
result_t fire()
102
Component Types
  • Configurations
  • link together components to compose new component
  • configurations can be nested
  • complete main application is always a
    configuration
  • Modules
  • provides code that implements one or more
    interfaces and internal behavior

103
Example1
  • Blink application

Blink
Main
configuration Blink implementation
components Main, BlinkM, TimerC, LedsC
Main.StdControl -gt TimerC.StdControl
Main.StdControl -gt BlinkM.StdControl
BlinkM.Timer -gt TimerC.Timerunique("Timer")
BlinkM.Leds -gt LedsC
BlinkM
Blink.nc
TimerC
LedsC
104
Example1
  • BlinkM module

module BlinkM provides interface
StdControl uses interface Timer uses
interface Leds 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()
  • event result_t Clock.fire()
  • call Leds.redToggle()
  • return SUCCESS

Blink.nc
Blink.nc
105
Example2
configuration SenseToRfm implementation
components Main, SenseToInt, IntToRfm, TimerC,
Photo as Sensor Main.StdControl -gt
SenseToInt Main.StdControl -gt IntToRfm
SenseToInt.Timer -gt TimerC.TimeruniqueTimer
SenseToInt.ADC -gt Sensor SenseToInt.ADCControl
-gt Sensor SenseToInt.IntOutput -gt IntToRfm
Main
StdControl
SenseToInt
ADCControl
IntOutput
ADC
Timer
106
Nested Configuration
includes IntMsg configuration IntToRfm
provides interface IntOutput interface
StdControl implementation components
IntToRfmM, GenericComm as Comm IntOutput
IntToRfmM StdControl IntToRfmM
IntToRfmM.Send -gt Comm.SendMsgAM_INTMSG
IntToRfmM.SubControl -gt Comm
StdControl
IntOutput
IntToRfmM
SendMsgAM_INTMSG
SubControl
GenericComm
107
IntToRfm Module
command result_t StdControl.start() return
call SubControl.start() command result_t
StdControl.stop() return call
SubControl.stop() command result_t
IntOutput.output(uint16_t value) ...
if (call Send.send(TOS_BCAST_ADDR, sizeof(IntMsg),
data) return SUCCESS ... event
result_t Send.sendDone(TOS_MsgPtr msg, result_t
success) ...
includes IntMsg module IntToRfmM uses
interface StdControl as SubControl
interface SendMsg as Send provides
interface IntOutput interface StdControl
implementation bool pending struct
TOS_Msg data command result_t
StdControl.init() pending FALSE
return call SubControl.init()
108
Atomicity Support in nesC
  • Split phase operations require care to deal with
    pending operations
  • Race conditions may occur when shared state is
    accessed by premptible executions, e.g. when an
    event accesses a shared state, or when a task
    updates state (premptible by an event which then
    uses that state)
  • nesC supports atomic block
  • implemented by turning of interrupts
  • for efficiency, no calls are allowed in block
  • access to shared variable outside atomic block is
    not allowed

109
Supporting HW Evolution
  • Distribution broken into
  • apps top-level applications
  • tos
  • lib shared application components
  • system hardware independent system components
  • platform hardware dependent system components
  • includes HPLs and hardware.h
  • interfaces
  • tools development support tools
  • contrib
  • beta
  • Component design so HW and SW look the same
  • example temp component
  • may abstract particular channel of ADC on the
    microcontroller
  • may be a SW I2C protocol to a sensor board with
    digital sensor or ADC
  • HW/SW boundary can move up and down with minimal
    changes

110
Sending a Message
  • Refuses to accept command if buffer is still
    full or network refuses to accept send command
  • User component provide structured msg storage

111
Send done Event
event result_t IntOutput.sendDone(TOS_MsgPtr
msg, result_t success) if (pending msg
data) pending FALSE signal
IntOutput.outputComplete(success)
return SUCCESS
  • Send done event fans out to all potential senders
  • Originator determined by match
  • free buffer on success, retry or fail on failure
  • Others use the event to schedule pending
    communication

112
Receive Event
event TOS_MsgPtr ReceiveIntMsg.receive(TOS_MsgPtr
m) IntMsg message (IntMsg )m-gtdata
call IntOutput.output(message-gtval)
return m
  • Active message automatically dispatched to
    associated handler
  • knows format, no run-time parsing
  • performs action on message event
  • Must return free buffer to the system
  • typically the incoming buffer if processing
    complete

113
Tiny Active Messages
  • Sending
  • declare buffer storage in a frame
  • request transmission
  • name a handler
  • handle completion signal
  • Receiving
  • declare a handler
  • firing a handler automatic
  • Buffer management
  • strict ownership exchange
  • tx send done event ? reuse
  • rx must return a buffer

114
Tasks in Low-level Operation
  • transmit packet
  • send command schedules task to calculate CRC
  • task initiates byte-level data pump
  • events keep the pump flowing
  • receive packet
  • receive event schedules task to check CRC
  • task signals packet ready if OK
  • byte-level tx/rx
  • task scheduled to encode/decode each complete
    byte
  • must take less time that byte data transfer

115
TinyOS tools
  • TOSSIM a simulator for tinyos programs
  • ListenRaw, SerialForwarder java tools to receive
    raw packets on PC from base node
  • Oscilloscope java tool to visualize (sensor)
    data in real time
  • Memory usage breaks down memory usage per
    component (in contrib)
  • Peacekeeper detect RAM corruption due to stack
    overflows (in lib)
  • Stopwatch tool to measure execution time of code
    block by timestamping at entry and exit (in osu
    CVS server)
  • Makedoc and graphviz generate and visualize
    component hierarchy
  • Surge, Deluge, SNMS, TinyDB

116
TinyOS Limitations
  • Static allocation allows for compile-time
    analysis, but can make programming harder
  • No support for heterogeneity
  • Support for other platforms (e.g. stargate)
  • Support for high data rate apps (e.g. acoustic
    beamforming)
  • Interoperability with other software frameworks
    and languages
  • Limited visibility
  • Debugging
  • Intra-node fault tolerance
  • Robustness solved in the details of
    implementation
  • nesC offers only some types of checking

117
Summary
  • For WSN, the need to build cheap, low-energy,
    (small) devices has various consequences for
    system design
  • Radio frontends and controllers are much simpler
    than in conventional mobile networks
  • Energy supply and scavenging are still (and for
    the foreseeable future) a premium resource
  • Power management (switching off or throttling
    down devices) crucial
  • Unique programming challenges of embedded systems
  • Concurrency without support, protection
  • De facto standard TinyOS

118
Acknowledgements
  • Notes on TinyOS rely heavily on Murat Demirbas
    course CSE 646 Wireless Sensor Networks Suny
    Buffalo
About PowerShow.com