Overview

1
Overview

• A System Architecture for Tiny Networked Devices
• One of the original sensor device/OS group

2
New Design Themes (Mobicom02 tutorials)

• Long-lived systems that can be untethered and
  unattended
• Low-duty cycle operation with bounded latency
• Exploit redundancy and heterogeneous tiered
  systems
• Leverage data processing inside the network
• Thousands or millions of operations per second
  can be done using energy of sending a bit over 10
  or 100 meters (Pottie00)
• Exploit computation near data to reduce
  communication
• Self configuring systems that can be deployed ad
  hoc
• Un-modeled physical world dynamics makes systems
  appear ad hoc
• Measure and adapt to unpredictable environment
• Exploit spatial diversity and density of
  sensor/actuator nodes
• Achieve desired global behavior with adaptive
  localized algorithms
• Cant afford to extract dynamic state information
  needed for centralized control

3
High Level (Query Based) Interfaces are Good

• Programming Apps is Hard
• Limited power budget
• Lossy, low bandwidth communication
• Require long-lived, zero admin deployments
• Distributed Algorithms
• Limited tools, debugging interfaces
• Queries abstract away much of the complexity
• Burden on the database developers
• Users get
• Safe, optimizable programs
• Freedom to think about apps instead of details

Tutorial from Sam Madden at EWSN 06
4
TinyDB Revisited
SELECT MAX(mag) FROM sensors WHERE mag gt
thresh SAMPLE PERIOD 64ms
High level abstraction Data centric
programming Interact with sensor network as a
whole Extensible framework Under the
hood Intelligent query processing Fault
Mitigation
App
Query, Trigger
Data
TinyDB
Cougar is very similar
5
Feature Overview

• Declarative SQL-like query interface
• Metadata management
• Multiple concurrent queries
• In-network, distributed query processing
• Extensible w/ new attributes, commands,
  aggregates
• In-network, persistent storage

6
Architecture
TinyDB GUI
JDBC
TinyDB Client API
DBMS
PC side
0
Mote side
TinyDB query processor
2
1
8
4
5
6
Sensor network
7
7
A System Architecture for Tiny Networked Devices

• Jason Hill
• http//www.cs.berkeley.edu/jhill
• http//tinyos.millennium.berkeley.edu
• U.C. Berkeley
• 9/22/2000

8
Goals

• To develop an ultra low power networked sensor
  platform, including hardware and software, that
  enables low-cost deployment of sensor networks.
• To be a system level bridge that combines
  advances in low power RF technology with MEMS
  transducer technology.

9
Key Characteristics of TNDs

• Small physical size and low power consumption
• gt Limited Physical Parallelism and Controller
  Hierarchy
• gt primitive direct-to-device interface
• Concurrency-intensive operation
• flow-thru, not wait-command-respond
• gt must handle multiple inputs and outputs
  simultaneously
• Diverse in Design and Usage
• application specific, not general purpose
• huge device variation
• gt efficient modularity
• gt migration across HW/SW boundary
• Largely Unattended Numerous
• gt robust operation
• gt narrow interfaces

10
UC Berkeley Family of Motes
11
Mica2 and Mica2Dot

• ATmega128 CPU
• Self-programming
• Chipcon CC1000
• FSK
• Manchester encoding
• Tunable frequency
• Lower power consumption

1 inch
12
COTS-BOTS (UCB)Commercial Off-The-Shelf roBOTS

• 5 x 2.5 x 3 size
• lt250 total
• 2-axis accelerometer

13
Robomote (USC)

• Less than 0.000047m3
• 150 each
• Platform to test algorithms for adaptive wireless
  networks with autonomous robots

14
MICAbot (Notre Dame)

• Designed for large-scale research in distributed
  robotics and ad-hoc wireless networking.
• 300 each

15
Basic Sensor Board

• Light (Photo)
• Temperature
• Prototyping space for new hardware designs

16
Mica Interface Board

• 8 External Analog Inputs using Block Screw
  Terminals
• External Probes
• 8 channel digital I/O
• 1 relay driver
• On board 12-bit ADC
• 0-2.5V, 0-3V, 0-5V Ranges
• Stable 2.5V Reference
• 3V and 5V power
• Designed by UCLA CENS w/ Crossbow and UCB

17
Mica Sensor Board

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

18
PNI Magnetometer/Compass

• Resolution 400 mGauss
• Three axis, under 15 in large quantities

19
Ultrasonic Transceiver

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

20
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
21
Motor/Servo Board

• H Bridge
• Standard Motor Interface
• On-board microprocessor

22
Connexus Interface

• Interfaces a mote with
• Vibration Motors
• Super-bright LEDs
• Force Sensing
• Accelerometer
• Nitinol/Flexinol contractormuscle wire
• Peltier Junction
• Tool for HCI research using wireless devices

For More Information, SeeEric Paulos.
Connexus An Evocative Interface Workshop on
Ad hoc Communications and Collaboration in
Ubiquitous Computing Environments New Orleans,
LA. Nov 2002.
23
In Manufacturing

• Dot sensorboards (1 diameter)
• HoneyDot Magnetometer
• Resolution 134 mGauss
• Ultrasonic Transceiver
• Weather Station

24
Mica Environmental Enclosure
25
Tiny OS The Software

• Provides a component based model abstracting
  hardware specifics from application programmer.
• Capable of maintaining high levels of
  concurrency.
• Allows multiple applications to be running.
• Services Provided Include
• RF messaging protocols.
• Periodic Timer Events.
• Asynchronous access to UART data transfers.
• Mechanism for Static, Persistent Storage.
• Can Swap Out system components to get necessary
  functionality.
• Complete applications fit in 4KB of ROM and 256B
  RAM.

26
Tiny OS Internals

• Scheduler and Graph of Components
• constrained two-level scheduling model tasks
  events
• Component
• Frame (storage)
• Tasks (concurrency)
• Commands, and Handlers (events)
• Constrained Storage Model
• frame per component, shared stack, no heap
• Very lean multithreading
• Layering
• components issue commands to lower-level
  components
• event signal high-level events, or call
  lower-level commands
• Guarantees no cycles in call chain

27
Event Based Programming Model

• System composed of state machines
• Each State Machine is a TinyOS component
• Command and event handlers transition a component
  from one state to another
• Quick, low overhead, non-blocking state
  transmissions
• Allows many independent components to share a
  single execution context
• Emerging as design paradigm for large scale
  systems
• Tasks are used to perform computational work
• Run to completion, Atomic with respect to each
  other

28
Migration of the Hardware Software Boundary

• TinyOS component model propagates hardware
  abstractions into software.
• Allows for a migrations of software components
  into hardware
• Example
• Bit level radio procession component could be
  implemented as specialized FIFO with complex
  pattern matching.