Language Challenges inspired by Networks of Tiny Devices

1
Language Challenges inspired by Networks of Tiny
Devices

• David Culler
• Computer Science Division
• U.C. Berkeley
• Intel Research _at_ Berkeley
• www.cs.berkeley.edu/culler

2
Challenges 6-pack

• Optimizing for efficient modularity
• Analysis for jitter bounds and other system
  properties
• Whole Program code generations for network
  capsules
• Analysis for verification of system invariants
• Programming environments for event-driven
  execution
• Programming language for unstructured aggregates

3
Outline

• Motivating networked sensor regime
• TinyOS structure
• Discussion of 5 challenges

4
Emerging Microscopic Devices

• CMOS trend is not just Moores law
• Micro Electical Mechanical Systems (MEMS)
• rich array of sensors are becoming cheap and tiny

• Imagine, all sorts of chips that are connected
  to the physical world and to cyberspace!

5
What can you do with them?
Disaster Management

• Embed many distributed devices to monitor and
  interact with physical world
• Network these devices so that they can coordinate
  to perform higher-level tasks.
• gt Requires robust distributed systems of
  hundreds or thousands of devices.

Habitat Monitoring
Condition-based maintenance
6
Getting started in the small

• 1 x 1.5 motherboard
• ATMEL 4Mhz, 8bit MCU, 512 bytes RAM, 8K pgm flash
• 900Mhz Radio (RF Monolithics) 10-100 ft. range
• ATMEL network pgming assist
• Radio Signal strength control and sensing
• I2C EPROM (logging)
• Base-station ready (UART)
• stackable expansion connector
• all ports, i2c, pwr, clock
• Several sensor boards
• basic protoboard
• tiny weather station (temp,light,hum,prs)
• vibrations (2d acc, temp, light)
• accelerometers, magnetometers,
• current, acoustics

7
A Operating System for Tiny Devices?

• Traditional approaches
• command processing loop (wait request, act,
  respond)
• monolithic event processing
• bring full thread/socket posix regime to platform
• Alternative
• provide framework for concurrency and modularity
• never poll, never block
• interleaving flows, events, energy management
• allow appropriate abstractions to emerge

8
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

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)
9
Appln graph of event-driven components
Route map
router
sensor appln
application
Active Messages
Radio Packet
Serial Packet
packet
Temp
photo
SW
HW
UART
Radio byte
ADC
byte
Example ad hoc, multi-hop routing of photo
sensor readings
clocks
RFM
bit
10
Quantitative Analysis...
3450 B code 226 B data
11
TOS Execution Model

• commands request action
• ack/nack at every boundary
• call cmd or post task
• events notify occurrence
• HW intrpt at lowest level
• may signal events
• call cmds
• post tasks
• Tasks provide logical concurrency
• preempted by events
• Migration of HW/SW boundary

data processing
application comp
message-event driven
active message
event-driven packet-pump
crc
event-driven byte-pump
encode/decode
event-driven bit-pump
12
Dynamics of Events and Threads
bit event gt end of byte gt end of packet gt
end of msg send
thread posted to start send next message
bit event filtered at byte layer
radio takes clock events to detect recv
13
Event-Driven Sensor Access Pattern
char TOS_EVENT(SENS_OUTPUT_CLOCK_EVENT)() return
TOS_CALL_COMMAND(SENS_GET_DATA)() char
TOS_EVENT(SENS_DATA_READY)(int data) return
TOS_CALL_COMMAND(SENS_OUTPUT_OUTPUT)((data gtgt 2)
0x7)

• clock event handler initiates data collection
• sensor signals data ready event
• data event handler calls output command
• common pattern

14
Tiny Active Messages
TOS_FRAME_BEGIN(INT_TO_RFM_frame) char
pending TOS_Msg msg TOS_FRAME_END(INT_TO_RF
M_frame) ...TOS_COMMAND(SUB_SEND_MSG)(TOS_MSG_B
CAST, AM_MSG(INT_READING),
VAR(msg))) ... char TOS_EVENT(SUB_MSG_SEND_DON
E)( TOS_MsgPtr sentBuffer) ... TOS_MsgPtr
TOS_MSG_EVENT(INT_READING)(TOS_MsgPtr
val) ... return val

• Sending
• Declare buffer storage in a frame
• Request Transmission
• Naming 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

15
TinyOS Execution Contexts
Tasks
events
commands
Interrupts
Hardware
16
Typical application use of tasks

• event driven data acquisition
• schedule task to do computational portion

char TOS_EVENT(MAGS_DATA_EVENT)(int data)
struct adc_packet pack (struct
adc_packet)(VAR(msg).data) printf("data_event\
n") VAR(reading) data TOS_POST_TASK(FILTER
_DATA) ...

• 128 Hz sampling rate
• simple FIR filter
• dynamic software tuning for centering the
  magnetometer signal (1208 bytes)
• digital control of analog, not DSP
• ADC (196 bytes)

17
Tasks in low-level operation

• transmit packet
• send command schedules task to calculate CRC
• task initiated byte-level datapump
• 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
• i2c component
• i2c bus has long suspensive operations
• tasks used to create split-phase interface
• events can procede during bus transactions

18
Example Radio Byte Operation

• Pipelines transmission transmits single byte
  while encoding next byte
• Trades 1 byte of buffering for easy deadline
• Separates high level latencies from low level
  real-time requirements
• Encoding Task must complete before byte
  transmission completes
• Decode must complete before next byte arrives

Encode Task
Byte 2
Byte 1
Byte 3
Byte 4
Bit transmission
Byte 1
Byte 2
Byte 3
start
RFM Bits
19
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

20
DARPA-esq demo

• UAV drops nodes along road,
• hot-water pipe insulation for package
• Nodes self configure into linear network
• Calibrate magnetometers
• Each detects passing vehicle
• Share filtered sensor data with 5 neighbors
• Each calculates estimated direction velocity
• Share results
• As plane passes by,
• joins network
• upload as much of missing dataset as possible
  from each node when in range
• 7.5 KB of code!

21
Re-exploring networking

• Fundamentally new aspects in each level
• encoding, framing, error handling
• media access control
• transmission rate control
• discovery, multihop routing
• broadcast, multicast, aggregation
• active network capsules (reprogramming)
• security, network-wide protection
• New trade-offs across traditional abstractions
• density independent wake-up
• proximity estimation
• localization, time synchronization
• New kind of distributed/parallel processing

22
6 Challenges

• Optimizing for efficient modularity
• narrow interfaces for robustness
• components for application specific composition
• encapsulated state and concurrency
• creation distinct from composition
• without sacrificing code generation
• optimize for energy
• Analysis for jitter bounds and other system
  properties
• need to get back to the radio bit layer every 50
  us - 10
• many paths through potential higher level
  activities
• tasks preemptible by events
• can you make guarantees about all paths

23
Challenge 6-pack

• Whole Program code generation for network
  capsules
• compile away module boundaries and indirection
  for efficiency
• incremental update of a few components is common
• compute the change in the infrastructure and
  update capsules
• append-only flash adds to challenge
• Analysis for verification of system invariants
• Dawson Engler has shown big wins for Flash magic,
  linux, ...
• system designers formulate invariants,
  specialized analysis routines check

24
6-pack continued

• Programming environments for event-driven
  execution
• high concurrency, in lots of places at once
• relationship between FSMs important
• visualization is key
• Programming language for unstructured aggregates
• currently program message protocol for each node
• infer global behavior from local function
• design to specify the global behavior
• build on data parallel, SPMD, scan operations,
  set languages

25
To learn more

• http//www.cs.berkeley.edu/culler
• http//tinyos.millennium.berkeley.edu/
• http//webs.cs.berkeley.edu/

26
Characteristics of the Large

• Concurrency intensive
• data streams and real-time events, not
  command-response
• Communications-centric
• Limited resources (relative to load)
• Huge variation in load
• Robustness (despite unpredictable change)
• Hands-off (no UI)
• Dynamic configuration, discovery
• Self-organized and reactive control

• Similar execution model (component-based events)
• Complimentary roles (eyes/ears of the grid)
• Huge space of open problems