Design Challenges in Instrumenting the Physical World with TinyOS PowerPoint PPT Presentation

presentation player overlay
About This Presentation
Transcript and Presenter's Notes

Title: Design Challenges in Instrumenting the Physical World with TinyOS


1
Design Challenges in Instrumenting the Physical
World with TinyOS
  • David Culler
  • University of California, Berkeley

August 04
http//webs.cs.berkeley.edu
2
Bells Law new computer class per 10 years
log (people per computer)
streaming information to/from physical world
  • Enabled by technological opportunities
  • Smaller, more numerous and more intimately
    connected
  • Ushers in a new kind of application
  • Ultimately used in many ways not previously
    imagined

year
3
Technology Push
nearly a thousand 8086s would fit in a modern
microprocessor
4
New Technology SweetSpot (uW mW)
  • CMOS miniaturization
  • 1 M trans/ gt tiny (mm2), inexpensive
    processing and storage
  • 1-10 mW active, 1 mW passive (at 1 use 100 mW
    ave)
  • Micro-sensors (MEMS, Materials, Circuits)
  • acceleration, vibration, gyroscope, tilt,
    magnetic, heat, motion, pressure, temp, light,
    moisture, humidity, barometric
  • chemical (CO, CO2, radon), biological,
    microradar, ...
  • actuators too (mirrors, motors, smart surfaces,
    micro-robots)
  • Communication
  • short range, low bit-rate, CMOS radios (1-10 mW)
  • Power
  • batteries remain primary storage (1,000
    mWs/mm3), fuel cells 10x
  • solar (10 mW/cm2, 0.1 mW indoors), vibration
    (uW/gm), flow
  • 1 cm3 battery gt 1 year at 1 msgs/sec

5
Application Pull
  • Env. Monitoring, Conservation biology, ...
  • Precision agriculture, land conservation, ...
  • built environment comfort efficiency ...
  • alarms, security, surveillance, treaty
    verification ...
  • Civil Engineering structures response
  • condition-based maintenance
  • disaster management
  • urban terrain mapping monitoring
  • Interactive Environments
  • context aware computing, non-verbal communication
  • handicap assistance
  • home/elder care
  • asset tracking
  • Integrated robotics

CENS.ucla.edu
6
Interactions of Space and Things
ElderCare
Sensor Augmented Fire Response
Shooter Localization - Vanderbilt, BBN
Smart Environments
Clinical Management
Asset Management
Manufacturing
7
Typical Characteristics
  • nodes gtgt people
  • sensor/actuator data stream
  • Unattended, inaccessible
  • prolonged deployment
  • energy constrained
  • operate in aggregate
  • in-network processing is necessary
  • what they do changes over time
  • gt must be self-organized, self-maintaining and
    programmed in situ to operate at very low duty
    cycle
  • gt Wide variation is application needs

8
The Systems Challenge
  • Monitoring Managing Spaces and Things

applications
Store
Comm.
uRobots actuate
MEMS sensing
Proc
Power
technology
Miniature, low-power connections to the physical
world
9
Open Experimental Platform to Catalyze a Community
WeC 99 Smart Rock
Small microcontroller - 8 kb code, - 512
B data Simple, low-power radio - 10
kb EEPROM (32 KB) Simple sensors
Crossbow
10
Technical Challenges
  • Architecture
  • Operating System
  • Networking
  • Network Services
  • Programming the Ensemble
  • Establishing Trust

11
Mote Platform Evolution
12
Recent 802.15.4 Platforms
  • Focused on low power
  • Sleep - Majority of the time
  • Telos 2.4mA
  • MicaZ 30mA
  • Wakeup
  • As quickly as possible to process and return to
    sleep
  • Telos 290ns typical, 6ms max
  • MicaZ 60ms max internal oscillator, 4ms external
  • Process
  • Get your work done and get back to sleep
  • Telos 4MHz 16-bit
  • MicaZ 8MHz 8-bit
  • TI MSP430
  • Ultra low power
  • 1.6mA sleep
  • 460mA active
  • 1.8V operation
  • Standards Based
  • IEEE 802.15.4, USB
  • IEEE 802.15.4
  • CC2420 radio
  • 250kbps
  • 2.4GHz ISM band
  • TinyOS support
  • New suite of radio stacks
  • Pushing hardware abstraction
  • Must conform to std link
  • Ease of development and Test
  • Program over USB
  • Std connector header
  • Interoperability
  • Telos / MicaZ / ChipCon dev
  • 97 Yield on first 200
  • Remaining reparable

UCB Telos
Xbow MicaZ
13
An Operating System for Tiny Devices embedded in
the Physical World
14
Traditional Systems
  • Well established layers of abstractions
  • Strict boundaries
  • Ample resources
  • Independent Applications at endpoints communicate
    pt-pt through routers
  • Well attended

Application
Application
User
System
Network Stack
Transport
Threads
Network
Address Space
Data Link
Files
Physical Layer
Drivers
Routers
15
by comparison ...
  • Highly Constrained resources
  • processing, storage, bandwidth, power
  • Applications spread over many small nodes
  • self-organizing Collectives
  • highly integrated with changing environment and
    network
  • communication is fundamental
  • Concurrency intensive in bursts
  • streams of sensor data and network traffic
  • Robust
  • inaccessible, critical operation
  • Unclear where the boundaries belong
  • even HW/SW will move
  • gt Provide a framework for
  • Resource-constrained concurrency
  • Defining boundaries
  • Appln-specific processing and power management
  • allow abstractions to emerge

16
Tiny OS 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
  • structured event-driven execution

Events
Commands
send_msg(addr, type, data)
power(mode)
init
Messaging Component
Internal State
internal thread
TX_packet(buf)
Power(mode)
TX_packet_done (success)
init
RX_packet_done (buffer)
17
Application Graph of Components
Route map
router
sensor appln
application
Active Messages
Radio Packet
Serial Packet
packet
Temp
photo
SW
Example ad hoc, multi-hop routing of photo
sensor readings
HW
UART
Radio byte
ADC
byte
3450 B code 226 B data
clocks
RFM
bit
Graph of cooperating state machines on shared
stack
18
TinyOS Execution Contexts
  • Events generated by interrupts preempt tasks
  • Tasks do not preempt tasks
  • Both essentially process state transitions

19
Programming TinyOS
  • TinyOS 1.x is written in an extension of C,
    called nesC
  • Applications are too!
  • just additional components composed with the OS
    components
  • Provides syntax for TinyOS concurrency and
    storage model
  • commands, events, tasks
  • local frame variable
  • Rich Compositional Support
  • separation of definition and linkage
  • robustness through narrow interfaces and reuse
  • interpositioning
  • Whole system analysis and optimization

20
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

21
Composition
  • 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 bi-directional
  • logically related set of commands and events
  • Interface methods are the external namespace of
    the component
  • Modules
  • provide code that implements one or more
    interfaces and internal behavior
  • Configurations
  • link together components to yield new component

provides
StdControl
Timer
provides interface StdControl interface
Timer uses interface Clock
Timer Component
Clock
uses
22
A Multihop Routing Example
23
Resource-Constrained Concurrency
  • Application lines bytes data tasks events
  • Surge 2,860 14,794 1,188 7 221
  • Mate 4,736 25,040 1,710 13 317
  • TinyDB 11,681 64,910 11,681 18 722

The nesC Language A Holistic Approach to
Networked Embedded Systems, PLDI03
24
Communication Centric Design
  • Tiny Active Messages
  • Communication fits into event driven model
  • Sending
  • Declare buffer storage in a frame
  • Request Transmission
  • Name a handler
  • Handle Completion signal
  • Receiving
  • Declare a handler
  • Firing a handler
  • automatic
  • behaves like any other event
  • Buffer management
  • strict ownership exchange
  • tx done event gt reuse
  • rx must rtn a buffer

25
Cooperative Interfaces
  • Power management extends std control
  • 1000-fold range of power draw
  • Components informed of intention to go to sleep
  • Take internal actions
  • Propagate control
  • Scoreboard determined permissible depth of sleep
    state
  • Scheduler drops to sleep on idle
  • Key interrupts drive wake-up
  • Rich communication interfaces
  • Signal strength
  • Post-MAC time-stamping
  • Sub-carrier signaling

26
TinyOS evolution
  • de facto std in sensor nets
  • active open source community
  • www.tinyos.net tinyos.sourceforge.net
  • 25,000 downloads, 500 research groups
  • Many differing platforms rene, mica, dot, mica2,
    bosch, iMOTE, dust, micaZ, Telos, TinyBT, Eyes,
  • OEP for DARPA Network Embedded Systems Technology
  • framework for appln. specific OS
  • communication centric, event driven, modular
  • Expressed in nesC
  • Permits whole-system optimization
  • Race detection
  • Rich set of components, services tools
  • Time, drivers, networks, power, sensors, flash
    storage, net prog, nVMs
  • Management, security
  • setting for CS explorations across the stack

27
Example Chipcon CC2420 InteroperabilityTinyOS
Platform Independent Radio Stack
  • One implementation, many platforms
  • Lower layers for communicating with the CC2420
    part of each platform
  • UCB wrote Telos drivers
  • Xbow wrote MicaZ drivers
  • Link layer adjusts for
  • Byte ordering
  • Alignment
  • Proven MicaZ/Telos interoperability
  • ChipCon dev board too

Telos (TI MSP430)
MicaZ (AVR)
28
NEST Pursuer/Evader Mid Term Demo
  • Problem detect vehicle entering sensitive area,
    track using magnetics, pursue and capture by UGV.
  • Components
  • 10x10 array of robust wireless, self-localizing
    sensors over 400 m2 area
  • Low cost, robust mote device magnetometer,
    microcontroller, radio network, ultrasonic
    transceiver
  • Evader human controlled Rover
  • Pursuer autonomous rover with mote, embedded PC,
    GPS
  • Operation
  • Nodes inter-range (Ultrasonic) and self localize
    from few anchors, correct for earth mag, go into
    low-power sentry state
  • Detect entry and track evader
  • Local mag signal processing determines event and
    announces to neighbors
  • Neighborhood aggregates and estimates position
  • Network routes estimate from leader to tracker
    (multihop)
  • Pursuer enters and navigates to intercede
  • Motes detect and estimate multiple events
  • Route to mobile Pursuer node
  • Disambiguates events to form map
  • Closed inner-loop navigation control
  • Closed information-driven pursuit control
  • Capture when within one meter

evader
pursuer
29
NEST PEG Architecture
  • Node Services
  • Event-driven, power-aware operating system
    (TinyOS)
  • Sensing, data processing (EWMA threshold
    detector), RF packet comm
  • Ultrasonic ranging
  • Power control
  • Interactive configuration
  • Neighborhood Services
  • Local Connectivity
  • Tuple-based information sharing
  • Distributed center-of-mass estimation (mag
    events)
  • Distributed shortest sum of distance to anchors
    localization
  • Network Services
  • Distributed robust tree-build and broadcast
  • RSSI-based, density aware, low-collision
  • Multihop routing
  • Mobile-to-mobile landmark-based routing
  • In situ network programming

30
TinyOS Org Release Model Working
  • Monthly minor release
  • 1.1.1 nov, 1.1.3 jan, 1.1.4 feb, 1.1.5 mar, 1.1.6
    may
  • Components must become default in sourceforge one
    month prior to release
  • 2-mote Regression testing (tinyos-1.x/regression)
  • Less frequent major releases (1.2, 1.3)
  • Core (tinyos-1.x/tos)
  • system services, supported on all standard
    platforms
  • supported by core TinyOS developers
  • new developments in tinyos-1.x/beta
  • changes tracked in bug tracker
  • Extensions
  • modules (under tinyos-1.x/tos/lib), ex TinyDB
  • compatible with the core, distributed in separate
    package
  • supported by external developers
  • contributions (under tinyos-1.x/contrib)
  • may be incompatible with core
  • supported by external developers
  • OPTIONAL distribution along with TinyOS releases
  • Forming Open Alliance for TinyOS (OATS)

31
Scalable Simulation
  • TOSSim just another target
  • Maps events to event-driven simulation
  • Up to thousands of nodes
  • Complete PEG midterm demo running under TOSSIM
  • Simulated vehicle
  • Simple magnetometer model
  • TinyViz plugins and Tython scripts
  • Sensor models
  • Positioning, motion
  • Repeatable experiments
  • Tython scripts for automation
  • Rapid algorithm evaluation debugging

32
Application Specific Virtual Machines
  • Extensible Tiny VM framework
  • Simple threads and triggers over TinyOS
  • Run-time safety
  • Add operators for application class
  • Operator TOS component
  • Specify language runtime
  • Automated VM build
  • Low runtime ovhd
  • Very small application capsule
  • Trickle-based propagation
  • Two Current Source Languages
  • TinyScript Mottle

33
TinyOS Appln Sensor Kit - TASK
TASK Client Tools
External Tools
JDBC/ODBC
Internet
JDBC
Basestation
TASK Server
TASK Field Tools
Sensor Network
34
Vast Networks of Tiny Devices
  • Past 25 years of internet technology built up
    around powerful dedicated devices that are
    carefully configured and very stable
  • local high-power wireless subnets at the edges
  • 1-1 communication between named computers
  • Here, ...
  • every little node is potentially a router
  • work together in application specific ways
  • collections of data defined by attributes
  • connectivity is highly variable
  • must self-organize to manage topology, routing,
    etc
  • and for power savings, radios may be off 99 of
    the time

35
The Most Basic Neighborhood
  • Direct Reception
  • Non-isotropic
  • Large variation in affinity
  • Asymmetric links
  • Long, stable high quality links
  • Short bad ones
  • Varies with traffic load
  • Collisions
  • Distant nodes raise noise floor
  • Reduce SNR for nearer ones
  • Many poor neighbors
  • Good ones mostly near, some far

36
The Basic Primitive
  • Transmit a packet
  • Received by a set of nodes
  • Dynamically determined
  • Depends on physical environment at the time
  • What other communication is on-going
  • Each selects whether to retransmit
  • Potentially after modification
  • And if so, when

37
Routing Mechanism
  • Upon each transmission, one of the recipients
    retransmit
  • determined by source, by receiver, by
  • on the edge of the cell

38
The Common Case Data Gathering
  • Collection of nodes take periodic samples
  • Stream data towards a root node
  • Root announces interest
  • depth 0
  • Nodes listen
  • When hear neighbor with smaller depth
  • start transmitting data to best lower neighbor
  • set own depth to one greater (and include with
    data)
  • Data transmission continuously reinforces
    adjusts routes
  • Aggregation within nodes or within the tree

39
Continuous Network Discovery
0
40
Building Neighborhoods Routes
  • Node transmits to some unknown set
  • Candidate nbrs are sources of incoming packets
  • Estimate of inbound link reliability
  • Occasionally announce inbound link states
  • Provides reverse link estimate to outbound
    neighbors
  • Basis for cost-based routing
  • Cost-based Parent Selection
  • depth(me) MIN nbr(me) depth(i)
  • loss(me) MIN nbr(me) loss(i)est(me,i)
  • trans(me) MIN nbr(me) trans(i)etrans(me,i)
  • What about the nbrs that dont fit in the table?
  • FIFO, LRU, Frequency

41
Example Study
  • 50 nodes
  • 3 off ground
  • 8 spacing
  • Low xmit power
  • 4,500 ft2

42
Behavior over Time
Est. Link Quality
Tree Depth
1
2
3
43
Quality MultiHop Communication
  • Several iterations of improvement
  • Based on mintroute cost-based tree routing
  • Uses BMAC with retrans and LPL
  • Collaborations with xbow and JHL labs
  • Surge application (mhop sensesend GUI) has
    become network performance analyzer

n.b. scale
See Surge Report
44
Reliable Epidemic Dissemination
Simulation (16x16)
45
Emerging Sensor Network Architecture
  • Narrow waist roughly drops to layer 2
  • Diversity of network (routing) protocols

46
Rough Consensus / Running Code
  • Open flexible framework has allowed wide
    exploration (internationally)
  • Classes of communication, key protocols,
    relationships solidifying
  • Novel in many respects
  • Cross-layer control
  • holistic power management
  • Time synchronization
  • Density aware epidemic dissemination
  • Continuously adapting topology
  • Mobility fits in naturally
  • Continuous reconnection
  • Custody Trasfer

47
Real Sensor Nets have Multiple Layers
Patch Networks
Verification Network
  • New challenges at lowest tier
  • Higher layers will be primarily IP
  • Intermittent connectivity
  • Power-aware
  • Reframe the lowest layer
  • Integrate at many points
  • Deep info-mgmt around the sensor net

GW
Transit Network
Client Data Browsing and Processing
Site Link
data storage processing
48
A New Kind of Scope
gt 1000 ft
49
Occupancy VerificationValidating Burrows
Readings with Infrared Web Cameras
Parent and chick
CLICK IMAGE
IR web camera kits
Chick with parent
CLICK IMAGE
CLICK IMAGE
50
Programming Challenges
  • thousands of constrained nodes,
  • interacting in real-time with physical world,
  • where you cannot touch them,
  • and what you want them to do changes with time...
  • How do you program the network?
  • How do you specify what you want it to do?

51
Programmable network fabric
  • Architectural approach
  • new code image pushed through the network as
    packets
  • assembled and verified in local flash
  • second watch-dog processor reprograms main
    controller
  • Viral code approach
  • each node runs a tiny virtual machine interpreter
  • captures the high-level behavior of application
    domain as individual instructions
  • packets are capsule sequence of high-level
    instructions
  • capsules can forward capsules
  • Rich challenges
  • security
  • energy trade-offs
  • DOS

pushc 1 Light is sensor 1 sense Push
light reading pushm Push message
buffer clear Clear message buffer add
Append val to buffer send Send message
using AHR forw Forward capsule halt
52
Higher-level Programming?
  • Ideally, would specify the desired global
    behavior
  • Compilers would translate this into local
    operations
  • High-Performance Fortran (HPF) analog
  • program is sequence of parallel operations on
    large matrices
  • each of the matrices are spread over many
    processors on a parallel machine
  • compiler translates from global view to local
    view
  • local operations message passing
  • highly structured and regular
  • We need a much richer suite of operations on
    unstructured aggregates on irregular, changing
    networks

53
Sensor Databases a start
  • Relational databases rich queries described by
    declarative queries over tables of data
  • select, join, count, sum, ...
  • user dictates what should be computed
  • query optimizer determines how
  • assumes data presented in complete, tabular form
  • First step database operations over streams of
    data
  • incremental query processing
  • Big step process the query in the sensor net
  • query processing content-based routing?
  • energy savings, bandwidth, reliability

SELECT AVG(light) GROUP BY roomNo
54
TinyOS-driven architecture
  • 3K RAM 1.5 mm2
  • CPU Core 1mm2
  • multithreaded
  • RF COMM stack .5mm2
  • HW assists for SW stack
  • Page mapping
  • SmartDust RADIO .25 mm2
  • SmartDust ADC 1/64 mm2
  • I/O PADS
  • Expected sleep 1 uW
  • 400 years on AA
  • 150 uW per MHz
  • Radio
  • .5mm2, -90dBm receive sensitivity
  • 1 mW power at 100Kbps
  • ADC
  • 20 pJ/sample
  • 10 Ksamps/second .2 uW.

jhill mar 6, 2003
55
Small Technology, Broad Agenda
  • Social factors
  • security, privacy, information sharing
  • Applications
  • long lived, self-maintaining, dense
    instrumentation of previously unobservable
    phenomena
  • interacting with a computational environment
  • Programming the Ensemble
  • describe global behavior, synthesis local rules
    that have correct, predictable global behavior
  • Distributed services
  • localization, time synchronization, resilient
    aggregation
  • Networking
  • self-organizing multihop, resilient, energy
    efficient routing
  • despite limited storage and tremendous noise
  • Operating system
  • extensive resource-constrained concurrency,
    modularity
  • framework for defining boundaries
  • Architecture
  • rich interfaces and simple primitives allowing
    cross-layer optimization
  • Components
  • low-power processor, ADC, radio, communication,
    encryption, sensors, batteries

56
Turning the Physical World into Information
  • The Sensors are out there
  • The network is the breakthrough
  • About Fundamental Productivity
  • A new kind of scope
  • Unprecedented spatial temporal fidelity
  • Cell-phone could be THE core mobile device in
    this world
  • Connects locally to its environment
  • Machines, tags, AND the physical world
  • And offers global connectivity
  • Not just a glorified PDA

57
Acknowledgments
  • Supported by
  • DARPA Network Embedded Systems Technology (NEST)
    program,
  • National Science Foundation,
  • Intel, Sun, CrossBow, Microsoft, HP, NTT DoCoMo
  • CITRIS and California MICRO.
  • Where to go for more
  • www.tinyos.net
  • webs.cs.berkeley.edu

Thanks
58
backup
59
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

60
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 the format, no run-time parsing
  • performs action on message event
  • Must return free buffer to the system
  • typically the incoming buffer if processing
    complete

61
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

62
BMAC Reconfigurable MAC protocol (tinyOS 1.1.3)
10 pps per node
  • Higher bandwidth and Adaptive noise-floor based
    channel detection
  • Reported in Dec PI
  • Exposes control of sub-primitives
  • Inter-packet gap
  • Contention backoff
  • Preamble length
  • listen sample for low-power listen
  • Duty Cycle
  • Acknowledgements
  • Richer protocols built on top
  • Hidden terminal detection (RTS/CTS)
  • Fragmentation
  • Energy model
  • Feedback to higher protocols

Sensys 04 submission
63
Low Power Listening
  • Reduce cost of idle listening through preamble
    sampling
  • Energy Cost RX TX Listen
  • Start by minimizing the listen cost
  • Approach
  • wake up, sample channel, sleep
  • Wakeup time fixed
  • Check Time between wakeups variable
  • Preamble length matches wakeup interval
  • Overhear all data packets in cell
  • Duty cycle depends on number of neighbors and
    cell traffic
  • Higher level protocols can decide when to use
    low-power listen, full listen, full sleep.
  • Each OEP has required a different variant of LPL

TX
sleep
sleep
sleep
Node 1
time
RX
sleep
sleep
sleep
Node 2
time
64
Dissemination
  • Configuration, commands, queries, scripts, data
  • Mechanism?
  • Flood
  • For each new dissemination, all receivers
    retransmit once
  • Epidemic
  • Occasionally, each node announces what it has
  • When a node hears a new one, take it
  • may adjust announcement rate
  • Goal density independent rate of transmission
  • the more often you hear, the less often you
    should speak

65
Dissemination Dynamics
Simulation (10x10)
66
How does a bunch of wireless devices become a
(programmable) network?
  • Localized algorithms Distributed computation
    where each node performs local operations and
    communicates within some neighborhood to
    accomplish a desired global behavior
  • D. Estrin, 21st Century Challenges

67
Radio Cells
Write a Comment
User Comments (0)
About PowerShow.com