Transcript Slide 1

Pervasive Computing Applications
and Wireless Sensor Networks
Embedded Systems Conference
Boston 2005
ESC-413
Dave Stewart
Chief Technology Officer, ERS, Inc.
http://www.embedded-zone.com
[email protected]
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Outline
 Pervasive Computing Applications
• Definition and Examples
• Multi-Dimensional Optimization
 Key Technical Challenges
•
•
•
•
© 2005 ERS, Inc.
Wireless networking is just one component
Resource constraints dominate design decisions
A real-time run-time environment is critical
Current WSN development tools are inadequate
Embedded Systems Conference – Boston 2005
“Pervasive Computing”
 NIST Definition:
• Pervasive computing is the strongly emerging trend toward
numerous, casually accessible, often invisible computing
devices, frequently mobile or embedded in the environment, and
connected to an increasingly ubiquitous network structure
 Alternate (My) Definition:
• Processors Everywhere and Anywhere
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Applications
Building
Automation
Military Logistics
Physiological
Monitoring
Transportation
Location Tracking and
Asset Management
Security,
Surveillance, and
Access Control
Industrial Control
and Machine Health
Environmental Monitoring
Precision Agriculture
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Multi-Dimensional Optimization
Everything is a Trade-Off
•
•
•
•
•
•
•
•
•
•
•
•
Unit Size
Cost
Power
Battery Type
Processor Speed
Distance
Hardware Architecture
Encoding Schemes
Dynamic Loading over RF
Antenna Size
RF Frequency
Development Tools
© 2005 ERS, Inc.
•
•
•
•
•
•
•
•
•
•
•
•
Functionality
Algorithm complexity
Sampling Rate
Routing Algorithms
Redundancy
Reliability
Security
Encryption
Mobility
Real-Time Guarantees
Number of Nodes
Etc.
Embedded Systems Conference – Boston 2005
Sensor Nodes vs. RFID Tags
 Sensor Nodes are “Smart”
•
•
•
•
•
•
•
•
•
Small CPU
Self-Powered
Sensors
Range 10 to 1000m
Transmit variable data
Can receive data
Can route messages
Today’s Size: 4 sq in
Today’s Cost: $50 to $500
 RFID Tags are “Dumb”
•
•
•
•
•
•
•
•
•
No internal CPU
Powered by “Readers”
No sensors
Range 0 to 3m
Always transmits same data
No receive
No routing
Today’s Size ¼ sq inch
Today’s Cost: $0.25 to $5
As hardware and battery technology improves and shrinks, expect these to merge.
The merging of these technologies will enable the Smart Refridgerator application.
RFID: Radio-Frequency Identification
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Wireless Networking
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Network Topology
• Star network with central base station is simplest
• Base node becomes bottleneck
• More sophisticated networks require careful planning
• Knowing where each node is physically located is
challenging
• Range of transmission is extended through “hops”
• Multi-hop solutions enable nodes to serve as routers
• Tree: centralized architecture
• Mesh: de-centralized architecture
• Solutions to mobile ad-hoc networks are attractive
• But today’s solutions are costly to implement, requiring
either too much memory, CPU time, or power
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Networking Strategies
 CSMA / CA
• Carrier Sense Multiple Access / Collision Avoidance
 TDMA
• Time Division Multiple Access
 Hybrid
• Some TDMA Slots, some CSMA Slot
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Networking Strategies: CSMA/CA
 Check if anyone transmitting; if not, send
• Race condition if two nodes check at about the same time
• Results in collisions and loss of messages
• Cannot guarantee timing
• Uses more power
• Receive for carrier sense before sending consumes power
• Collisions can occur frequently with heavy traffic
• Retries due to collision increase traffic even further
• Receiver is on more than necessary, since arrival time of
incoming message is not known
• Becomes unstable with high traffic
• Thrashing occurs when bandwidth becomes dominated by retries
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Networking Strategies: TDMA
 Global schedule to decide who sends when
• No conflicts or collisions
• Bandwidth is reserved for each transmission
• Enables real-time guarantees if channels are “clean”
• No arbitrary retries to gain access to network
• Requires global clock synchronization
• Clock skew among nodes is non-negligible
• Stable as traffic in network increases.
• As long as a node has a slot to send, the data can be sent.
• Analytically determine when the network will be “full”
• Poses a major challenge to ad-hoc multi-hop networks
• Requires more constraints on routing
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
TDMA Needs Global Clock Synchronization
 Clock skew between nodes is non-negligible
• Two nodes with 2MHz CPU, 20 PPM accuracy, will skew by about
1 msec for every minute of operation
• Slow sampling rates (seconds to minutes) increase the problem
 Accuracy significantly affects power consumption
• 20x power savings are possible using TDMA compared to CSMA/CA
• Accurate synchronization allows nodes to be in sleep mode longer
 Accurate synchronization is difficult
• Algorithms are especially challenging in multi-hop environments
• Dissemination of global schedule
• Additional communication overhead
 Clock synchronization also needed for synchronized sensor
gathering
• Sensor data on different nodes might be meaningless if not collected at
the “same time”
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Example of Power Optimization using TDMA
TX
RX
Base
3 Full hyperperiods, showing
1% duty cycle of TX/RX On vs Off
Clock
Clock
TX
Node
RX
1 sec
TX
RX
Base
1 Full hyperperiod, (zoom of
above diagram). TX/RX of node
on for 8 msec every 850 msec
Clock
Clock
TX
Node
RX
500 msec
TX
RX
Base
Clock
Clock
Node
TX
RX
200 usec
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Receiver turns on just
microseconds before message
arrives, thus minimizing wasted
power
Example of Global Clock Synchronization
ACK/RESYNC sent
Beacon listen
Beacon received
Unsynchronized
heartbeats
first report received
synchronized
heartbeats
TX
Base
RX
Clock
Clock
Node
TX
RX
50 msec
Beacon sent
Node’s Clock
Resynchronizing
ACK/SYNC received
report sent
ACK received
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Network Bandwidth
 Lowest power transceivers have limited bit rates
• Bit rates of 20 to 200 Kbps are typical
• Protocol overhead and training sequences are significant
• Could account for 90% of used bandwith
 Consider a 100-Node network at 56 Kbps
• Average 6 data bytes per node per second
• Protocols must be simple and compact, yet powerful enough to
handle diverse needs within a single network
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Network Limitations
 RF communication known to be unreliable
• Error correction is costly
• Inadequate for garbled or missed messages
• Re-transmission of data adds complexity to schedule
• Reserving bandwidth just in case of error is costly
• Acknowledgements are useful, but …
• Reduces bandwidth in half and doubles power usage
 Just because you can hear another node does not mean it can hear you
• There is no guarantee that transmitters on different nodes will have the
same range.
 FCC Limitations
• ISM bands have many restrictions; licensed bands are expensive
• For example, a 900MHz system cannot transmit continuously on the
same channel for more than 0.4 sec every 20 sec
• To use full bandwidth, more complex frequency hopping or spread
spectrum techniques needed. But nodes have few resources available
to implement this.
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Network Reliability
 Redundant Networks
• Nodes provide redundancy
• DoD’s main objective
• Focus on routing and networking
 Functional Networks
• Every node produces unique data
• Commercial/industrial objective
• Focus on configuration, diagnostics, and availability
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Sensor-Network Research Areas
• Routing
• Determine most efficient path from Point A to Point B
• Self-Healing
• If nodes go down, reconfigure network so that remaining nodes still
reach ultimate destination
• Data Aggregation
• Merge data from locally adjacent nodes to minimize communication
bandwidth
• Sentry
• Monitor and control power consumption throughout the network
• Local Positioning
• Detect where is a node, in areas where GPS is not available
• Swarm
• Multiple nodes work together to produce a single sensory value
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
WSN Standards

IEEE 802.15.4
•
•
•
•

ZigBee
•
•
•

PHY and MAC Layers
Option 1: Slotted CSMA with guaranteed time slots (GTS) for TDMA-like Transfers
Option 2: CSMA/CA
PHY layer built-in to transceivers; MAC layer in software.
NWK and APL Layers
Relies upon 802.15.4 CSMA/CA
Current ZigBee stack implementations are about 60 KBytes
Is it Ready?
•
•
•
•
Still lots of confusion about what ZigBee is and isn’t
Increasingly growing newsgroup chatter about major deficiencies and unnecessary
complexity in these standards
Low power and scalability promises are being questioned and remain unproven
Real-time features are lacking
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Recommended Approach to Building
Embedded Software for WSN

Know and use standards when appropriate
•

Component-based real-time protocols
•
•

A sub-net might use an optimized TDMA algorithm
One node on the sub-net is on a larger net that communicates using a standard
such as ZigBee
Wireless network component library with optimized algorithms
•
•

Plug-and-play protocols allow optimizing different parameters
Select the right one for each mode or application
Establish harmony between multiple protocols
•
•

Includes 802.15.4 and ZigBee
Protocols implemented as plug-in components
Data Aggregation, localization, strategic routing, etc.
Accurate global clock synchronization
•
•
Accomplished by using an underlying real-time framework
Microsecond accuracy is possible
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Resource Constraints
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Sensor Nodes are Resource Constrained
 Typical characteristics of sensor nodes
•
•
•
•
•
•
•
•
•
© 2005 ERS, Inc.
Small CPU
Self-powered
Sensors and/or actuators
Range 10 to 1000m
Transmit variable data
Can receive data
Can route messages
Today’s size: 4 sq in
Today’s cost: $50 to $500
Embedded Systems Conference – Boston 2005
CPU Comparison
Package
Power
Processor
PIC12C509
MSP430F1132
MC68HC08G60
MSP430F1612
MC68HC912B32
ATMEGA 128L
LPC2106 (ARM)
ColdFire MCF5206
Intel Xscale PXA255
© 2005 ERS, Inc.
mA
@
Volts
@
Mhz
cost
0.8
0.2
1.1
0.3
15.0
5.5
30.0
21.0
240
5.5
2.0
3.0
2.0
5.0
3.0
1.8
5.0
1.3
4
1
2
1
2
4
60
33
400
$1.15
$1.75
$3.95
$8.95
$12.20
$12.90
$11.00
$15.27
$40.00
Processor
size
size
(cm²) (bits)
0.7
1.0
2.4
1.0
2.0
2.6
0.5
9.0
2.9
8
16
8
16
16
8
32
32
32
max
MHz
4
10
20
8
8
16
60
33
400
Memory (bytes)
Usage
Internal Internal External
Sample Application
RAM
Flash
Max
41
256
4K
5K
2K
4K
64K
1K
256K
Embedded Systems Conference – Boston 2005
1.5K
8K
60K
55K
32K
128K
128K
0
32MB
0
0
0
0
32K
64K
0
512M
128MB
Elec. infant toy
Calculator
Motor control
Industrial control
Automotive
Thermostats
Access control
Internet appliance
PDA, smart phone
CPU Constraints
 Sensor algorithms drive choice of CPU
 Simple: can use lowest-end microcontrollers
• Suitable for monitoring of simple sensors
• Averaging
• Threshold
 Complex: requires more powerful CPUs or DSPs
•
•
•
•
Needed for signal processing and diagnostics
FFT
Encryption
Compression
 Complexity of networking protocols may require more powerful CPUs
• Low-end devices implement only a subset of the protocol
• High-end devices are not power-constrained, and implement the full
protocol
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
CPU Constraints
 How do we get small, cheap, and low power?
 Use lowest-end microcontrollers
• 1 square cm
• $1 to $10 each
• Micro-amp current draw for longer battery life
 But … these same CPUs have
• The least memory (kilobytes)
• The slowest processor speed (one’s to tens of MHz)
• The least built-in support for debugging (few I/O pins)
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Memory Constraints
 Consider lowest-end CPUs
• 256 Bytes of RAM, 8 KBytes of Flash
 Problem: with so little memory, no RTOS
• The dynamic needs of a sensor network require run-time support
 Need for configurable environment
• Ad-hoc programming is not acceptable
• Component framework is needed
 Problem: Component frameworks traditionally require lots of
memory
• Usually implemented as middleware above an RTOS
• Not even enough memory for an RTOS, let alone middleware
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Flash (ROM) Constraints
 Larger flash is available, but …
• Need larger processor, which increases cost and power and size
• Will be a problem for mass-produced applications
 On-the-fly reprogramming of flash improves flexibility
• Receive new code or schedules, and load them into flash.
• Constraint is that flash is only erasable by block, not by byte.
• Dynamic linking and loading with very little memory is hard if there is no
room for symbol tables on the node.
 Using flash as ram
• Slow writing speed consumes power and increases complexity
• Write-cycle lifetime
• 100,000 cycles at once per second = 1.2 days!
• Wear-leveling algorithms needed
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Power Constraints
 Main contributors to power consumption:
• Voltage regulator quiescent
• Dominates “sleep mode” power consumption
• Processor
• Proportional to processor speed
• Transceiver
• Using most frequency modulation techniques, TX and RX
use about same amount of power
• Sensors
• Range from very little (e.g. thermister) to a lot (e.g.
magnetometer)
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Power Constraints
 Wireless is power-hungry
• Wireless transceivers are usually highest-power components on a node
• 1 hour of wireless communication uses same power as
10 days of CPU operation
• Significant overhead
• Training sequences
• Sleep and mode changes
• Need to synchronize receiver with transmitter
• More power needed for longer range
• Two short hops often use less total power than one long hop
 Reduce power by maximizing time in sleep mode
• Knowing “when” to wakeup is biggest challenge
• Even if not in sleep mode, turning off receiver provides huge savings,
but then need to know when to listen.
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Power Constraints
 Saving power is often counter-intuitive
• Software has more impact on power than hardware
• Duty cycle of CPU in sleep mode is software dependent
• Increase speed of the CPU
• Finish a task faster, to get back to low-power mode quickly
• Transmit RF data faster
• Although transmitter may use more power when on, it is on
for less time.
• Focus on reducing receive time, not transmit time
• Receiving uses more power than transmit, because
Time(Receive) ≥ Time(Transmit), yet
Power(Receive) = Power(Transmit)
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Batteries
 Issues:
• Size: the most powerful batteries are very big
• Lifetime: mAh is deceiving.
• Two 1.5AA at 2500 mAh will last less than 800 mAh, if 2.7V
regulator is used, since 2500 hours is time for each battery to
go down to 0.8 volts.
• Maximum instantaneous current
• Button cells are the smallest, but they don’t have enough
current nor lifetime for most node applications
• Rechargeable batteries require a source for recharging
• Might not be an option for fielded sensors
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Battery Life


Typically 1 hour to 10 years 
Depends on many parameters:
•
•
•
•
•
•
•
•
•
•
•
•
•
© 2005 ERS, Inc.
Choice of battery
Sensor sampling rates
Node reporting rates
Duty cycle (sleep time vs. on time)
CPU and Transceiver hardware
Transmit Power Level
Processor Speed
RF Data Rate
Real-time precision
Power needed by sensors
Routing algorithms
Amount of data collected and transmitted
Many more parameters
Embedded Systems Conference – Boston 2005
Strategy to Managing Resources
 Use commercial off-the-shelf (COTS) hardware
• Leverage the growing number of products being developed by others
 Abstract hardware with a scalable, configurable framework
• Features and functionality grow as resources grow
 Support lowest-end devices first
• It is easier to add resources than to remove them
 Focus on SOFTWARE to reduce power consumption
• Reducing CPU “on” duty cycle from 5% to 1% saves much more power
than cutting power consumption of a processor in half.
• Use a real-time foundation to achieve savings
 Portable software that can grow with resources
• Enables heterogeneous networks
• Quickly implement trade-offs between power and functionality
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Run-Time Environment
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Problems with
Traditional Environments
100000 Times
Too Big
(OK for Desktops & Laptops)
None of these software
technologies can solve all the
technical challenges encountered in
wireless sensor networks
100 Times
Too Big
(OK for PDAs and Cell Phones and
Larger Embdded and Real-Time Systems)
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Traditional Operating System
 Virtual Machine:
• Abstract the hardware to simplify programming by assuming the
application programmer has full use of the CPU, even if it
doesn’t
 Resource Management:
• Manage shared resources, such as disk drives and printers
 Middleware:
• A layer that extends operating systems to use configurable
components in a distributed environment
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
WSN Run-Time Needs
 WSN needs a run-time environment like an operating
system
• Heterogeneous architectures used within a single WSN require the
hardware abstractions of a virtual machine
• WSN applications have the most severe resource constraints, and
have the greatest need for resource management
• Distributed applications require the component-based approach of
middleware
 But most operating systems are too big for WSN nodes
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
WSN Framework
 Virtual Machine:
• Abstract the distributed hardware so that a collection of dozens to
thousands of nodes appear as a single CPU to the application
programmer
 Resource Manager:
• Use configurable real-time methods to manage constrained resources,
such as memory, power consumption, and communication bandwidth
 Framework:
• Manages software components across a distributed platform.
• Includes task management and other necessary OS functions to
eliminate need for full OSs
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Is a Real-Time Approach Needed?
 Yes! If you want any of the following (even if application is not realtime):
•
•
•
•
•
•
•
•
Optimized resource usage
Predictable reliable software
Execution of software on smallest (not just ‘small’) embedded hardware
Guaranteed response times
Prove deadlock-free operation
Accurate time synchronization across the network
Stability of operation as network scale increases
Configurable time parameters such as sampling rates
 Most WSN software designs do NOT use a real-time approach
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Local Real-Time Scheduling
 Traditional embedded real-time systems:
• Maximize CPU utilization
while guaranteeing real-time constraints are met
 Wireless Sensor Networks:
• Minimize power consumption
while guaranteeing real-time constraints are met. e.g.:
• Maximize use of low-power modes
• Minimize sampling rates
• Minimize amount and size of data transmitted over RF
• Maximize data aggregation
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Development Tools
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Design for Trade-Offs
 There is no right answer; everything is a trade-off
• Perhaps the most important design criteria
 Can’t generalize and support every function on a node
• If you do, nodes are too big, too power hungry, and too expensive
 Need a WYNIWYG approach
• What You Need is What You Get
• No more, no less!
 Configurable and reusable software is essential
• Each instance of an application may need unique customization
• Code or data must be loaded over RF link
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Design Trade-Off Considerations
•
•
•
•
•
•
•
•
•
•
•
•
Unit Size
Cost
Power
Battery Type
Processor Speed
Distance
Hardware Architecture
Encoding Schemes
Dynamic Loading over RF
Antenna Size
RF Frequency
Development Tools
© 2005 ERS, Inc.
•
•
•
•
•
•
•
•
•
•
•
•
Functionality
Algorithm complexity
Sampling Rate
Routing Algorithms
Redundancy
Reliability
Security
Encryption
Mobility
Real-Time Guarantees
Number of Nodes
Etc.
Embedded Systems Conference – Boston 2005
Programming an Application
 Use of model-based design tools a necessity
• Today’s methods of compiling and loading embedded code
result in a component management nightmare
• Existing model-based design tools (e.g. Simulink, LabVIEW
etc.), compile to a single executable, not a distributed network of
very small nodes
• New tools that perform distributed model-based design and
synthesis are needed
• So far, this is being done manually
 How do you program 1000 nodes at once?
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Debugging Tools
 How do we test and debug a 1000 node network?
 Traditional embedded debugging methods are impractival beyond a
network of 4 or 5 nodes
•
•
•
•
•
•
•
Small devices have very few I/O pins and no display
At most one or two I/O bits available for debugging
JTAG not feasible beyond 2 or 3 nodes during debugging
Instrumentation practical only up to 3 or 4 nodes
Cannot put a logic analyzer on every node
Can’t log more than a few bytes of data per node
The data needed for debugging might need to be transmitted over the
medium being debugged
• “Watching LEDs” is impractical; can’t simultaneously see or decipher
LEDs from hundreds of nodes
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Strategy to Build Reliable Systems
 Step 1: Avoid bugs in the first place
• Use solid software engineering methods to develop the highest quality
embedded software
• Use real-time methods to maximize predictability; reducing system
randomness makes it easier to monitor and debug an application
• Regular formal design and code reviews
• Establish formalized test procedures for module acceptance, so that if
module works on one node, it works on all nodes.
 Step 2: Integrated debugging support
• Diagnostic data collected on nodes and transmitted at opportune times
over the RF link when needed
• Integrate diagnostic data with model-based tools to diagnose problems,
and if possible correct through dynamic upload or reconfiguration
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005
Other Development Issues








© 2005 ERS, Inc.
Configuration Management
Version Control
Data Visualization
Modeling Fault Diagnosis and Recovery
Dynamic Software Loading over Multi-Hop
Shrinking Heavyweight Algorithms into Nodes
Security and Authentication
… Many more
Embedded Systems Conference – Boston 2005
Summary of WSN Technical Challenges
• Wireless networking is a tool to communicate
• Wireless should be transparent
• Resource constraints dominate design decisions
• Power, size, and cost per node will dominate
• A real-time run-time environment is needed
• Even if application is not real-time, the underlying services should be
• Current WSN development tools are inadequate
• Need tools ranging from development to debugging to monitoring
© 2005 ERS, Inc.
Embedded Systems Conference – Boston 2005