System Architecture Directions for Networked Sensors

1
System Architecture Directions for Networked
Sensors

• By
• Jason Hill et al.

Presented by Ramakrishna Gummadi
2
Problem Description

• Designing and quantifying a tiny operating
  platform for sensor networks
• Providing base for designing future networked s/w
  for sensor networks

3
High Level Accomplishments

• Better balanced computation communication
• Proc. consumes 0.8microJ, does 100 instructions
  while xmitting 1bit_at_1.9microJ
• Low latency!
• Extremely efficient and specialized execution
  model
• Nice s/w architecture
• Builds upon past lessons from distributed
  systems, hpc, s/w PL design, etc.

4
Requirements for n/w sensors

• Small physical size, low power consumption, low
  costgtno h/w abstraction
• High task concurrency
• Managing information flow
• Interleaved computation communication
• Modest but essential data processing at every
  step, involving software several layers
• Streaming architecture
• Little/no buffering
• Multihop data routing
• Real-time requirements (bounded jitter, etc.),
  extended event processing (aggregated events)
• Limited scope for physical //ism, hierarchical
  h/w design
• System-level p2p vs. mu-c centric p-p star design
• App specific, non-federated, but
• Reusable, easily synthesizable s/w platform
• Generic dev. environment, h/w customization
• Robustness
• numerous, autonomous, long-lived units
• prohibitive communication overhead for
  multi-layer redundancy (but app-level ok)
• modularity helps

5
H/W description

• Atmel MCU
• 8-bit data, 16-bit address, Harvard architecture
• 32 8-bit general registers, 4Mhz, 3.0V
• 8KB flash pgm., 512B SRAM data
• Timers, counters, interrupts, ADC/DAC, UART, etc.
• 3 sleep modes idle, power down, power save
• RF
• 19.2Kbps on-off keyed RF monolithics 916.50Mhz
  tranceiver
• Support for signal strength and sensitivity
  measurement, power mgmt.
• Zero buffer, bit-serving, unlatched transmitted
  value, jitter propagation (IOW, NO abstractions)
• Temp. sensor
• digital, internal A/D, standard chip-chip I2C
  protocol (generic serial synchronous)
• micro-C s/w synthesizes I2C master on general
  I/O pins, no h/w arbiter (s/w supervised bus
  negotiationsgtNO abstractions)
• Coprocessor for IPLing MCU over SPI (gernic
  1Mbit sync. serial)
• 256KB EEPROM, 2KB Flash pgm., 128B SRAM
• Possibility for battery strength/health
  monitoring, radio xmission. strength actuator,
  etc.

6
(No Transcript)
7
Power Characteristics

• Active
• LED, RF MCU 60mW (19.5mA_at_3V)
• Inactivegt10microA
• Orders of magnitude savings possible
• Lesson Work rapidly, sleep mostly
• Lower the duty cycle

8
Power data (from paper)
9
TinyOS

• Goals similar to highly concurrent scalable
  Internet systems design
• Two prev. approaches
• physical //isms, VMs
• Alt extremely efficient multithreading engine
• Two-level scheduling structure
• avoids live-locks, minimal protection for DOS,
  etc.
• Programmable FSM design principles (involves PL,
  s/w checker models, etc.)
• Inter-changeable s/w h/w modules
• Traditional stack-based architecture inefficient
  because
• individual stack frame memory
• high context-switch overhead (40,000 ctxs/s!)
• No blocking/polling
• Minimize activity, no unbounded buffers, expose
  more choices to s/w (flexibility trading off
  power for CPU speed, etc.), realtime possibility
• use c/b, events instead

10
TinyOS Design

• Small scheduler, components arranged as a
  data-flow graph
• Component
• command handlers (downcalls), event handlers
  (upcalls), fixed-size frame, simple threads
• Strongly typed, signatures used to compose
  applications
• Modular/reusable
• Compile-time checking insures safety
• Commands specify what components they expose
  (consume), events specify what they return
  (produce) pumps and drains model---flexible
  natural
• H/W abstracted as components Typed objects move
  between nodes (components) in graph
• Structured subset of C

11
Design (contd.)

• Static memory allocationgtmemory requirements
  frozen at compile time, no dynamic mgmt.
  overhead, no runtime pointer chasing
• Asynchronous execution model
• Commands (non-blocking requests) call into
  lower-level components
• Single function call cost
• Specify where to find actual parameters in its
  stack frame, return immediately along with status
• Optionally schedule a thread for execution
• Fixed (even 1!) number of threads in a component
• Event handlers complete work, report work status

12
Event Handlers

• Triggered by h/w events (interrupts, watchdogs,
  timers, etc.) at lowest level
• Can deposit info into frame, schedule threads,
  signal higher level events, call lower-level
  commands
• Upcalls trigger fountain of processing that
  wind upward through events, and downward through
  commands
• Loop prevention commands cannot signal events
• Command/events execute as atomic units within a
  thread (run to completion)

13
Example component (from paper)
14
Threads

• Threads/events execute asynchronously, dont spin
  or wait
• Can call lower level commands, signal higher
  level events, schedule more threads
• Single stack assigned to current thread
• Never block or spin wait
• Thread bundles for richer computation models

15
Scheduler

• Currently simple FIFO w/bb
• Power aware
• Hardware triggered

16
(No Transcript)
17
Example Application Notes

• H/W exposed as components
• Unlike traditional device drivers
• Multiple stacked components increase abstraction
  (analogous to fs over generic SCSI disk driver
  over specific SCSI h/w controller)
• Permits easy migration of s/w h/w boundary
• General principle for constructing components
• when possibility of blocking, make new component
• For modularity (sufficient work accumulatedgtnew
  component)
• App with 3KB pgm. memory, 226B data memory
  (including scheduler)
• AM model
• registered handlers, typed data
• Fixed message size
• Safe and efficient multiplexing