System Design for Vastly Diverse Devices

1
System Design for Vastly Diverse Devices

• David Culler
• U.C. Berkeley
• HP Visit
• 3/9/2000

2
Q1 How do we get arbitrarily powerful,
personalized services on arbitrarily small
devices anywhere?

• Harness the intelligence in the infrastructure
• adapt (distill) content to specific device and
  context
• increasingly diverse population
• Connectivity!

3
Q2 How do we enabled distributed innovation on
Scalable, Available Services?
Infrastructure Services
gt Push services into an Active infrastructure
4
Q3 how do we integrate zillions of tiny,
semi-autonomous devices into the computational
world?

• Find them
• Organize them
• Orchestrate them
• Build services upon them
• using information/data they provide
• influencing the world through them
• Make them reliable, easy to use (program)
• Cope with tremendous heterogeneity

5
Structured Approach

• Active Proxies
• connected to the infrastructure
• soft-state
• receptive exec. env.

6
Project Components

• Platform for Open, Scalable, Available
  Infrastructure Services - ninja.cs
• service composition (lookup, msg, negotiation)
• scalability, availability built into the platform
• High-level Communications / Services Architecture
• Simple / robust Tiny OS
• microthreading for concurrency intensive
  environment
• Tiny MAC (that isnt braindead)
• Sample devices
• embedded servers
• sensors, actuators, personal devices

7
Zillions of Little Devices

• Connected device as client is well-established
• distiller in the infrastructure spoonfeeds client
• powerful services in power-limited devices!
• How to get the illusion of continuous
  connectivity?
• What about sensors-based devices?
• they should behave as servers
• eg camera server
• How to scale tiny server to need?
• How to get illusion of continuous connectivity?
• use the infrastructure

8
Architecture Assumptions

• Computation and storage in the infrastructure is
  plentiful
• Wired bandwidth is pervasive and essentially free
• gt every device has a representative proxy in the
  infrastructure

9
Device Access Architecture
low power local device link
Clients
Physical Device
Services

• infra proxy provides name, state, queuing, etc.
• extend toward AP as optimization

10
Towards Principles for Simple OS

• Communication is fundamental
• treated as part of the hardware. No comm is like
  no power
• you dont bring up the device then configure
  comm.
• Concurrency intensive
• schedule data movement and events, not arbitrary
  threads of computation
• hands off a direct user interface is the
  exception not the norm
• need extreme reliability and ease of development
  for distinct, specialized devices
• gt Micro threads operating against storage
  chunks
• gt constant self-checking and telemetry
• rely on the infrastructure for hard stuff

11
Escape the 486 OS trap

• Operating systems that are not called operating
  systems
• eg modern disk controller
• event scheduler handling stream of commands from
  network link, controlling complex array of
  sensors and actuators, performing sophisticated
  calculations to determine what and when
  (scheduling and caching) as well as transforming
  data on the fly
• automatic connection, enumeration, configuration
• but several simplifying assumptions must be
  removed

Complex array of Sensors and actuators
Network link - EIDE, SCSI - FCAL, SSA - USB,
1394 - ???
12
OS as little more than FSM

• Primary focus is scheduling discrete chunks of
  data movement
• not general thread scheduling and unlimited
  memory management
• there may be a bounded amount of work to xform or
  check data
• Commands are an event stream merged with
  sensor/actuator events
• General thread must be compiled to sequence of
  bounded atomic transactions
• spagetti part of an application is configuring
  the flows
• steady-state is straight-forward event processing
  signaling unusual events
• Simplify network-based debug and mgmt

13
Tiny OS microthreading

• Focus on concurrency and modularity
• TOS Component
• command handlers API
• event handlers ADI
• bounded state
• state-transitions threads
• Base Component per device
• Integration components compose flows into
  application
• ex atmel/RFM mote
• 8 kB inst, 512 B data

14
Key building blocks

• Low power controller with stream devices
• X sensor actuator for devices
• X host interface for AP and Embedded server

Application
Tiny Kernel
Tiny flow drivers
RF tcvr
X
host
a
s
s a
svr
s a
15
Convergence at the Extremes

• Powerful Services on Small Devices
• massive computing and storage in the
  infrastructure
• active adaptation of form and content along the
  way
• Illusion of Tiny Servers via infra. proxies
• Extremes more alike that either is to the middle
• More specialized in function
• Communication centric design
• wide range of networking options
• Federated System of Many Many Systems
• Hands-off operation, mgmt, development
• High Reliability, Availability
• Scalability
• Power and space limited
• simplicity
• They have to work or die!