Ubiquitous Computing in the AutoHAN/Oxygen Project

1
Ubiquitous Computingin theAutoHAN/Oxygen Project

• The evolution of application software
• in the age of pervasive computing

Dr David Greaves, University of
Cambridge Computer Laboratory Steve Ward, Umar
Saif MIT CSAIL
2
Ubiquitous Computing
Raises new challenges for 1. Operating
Systems - Power control and security - Secure
code loading and life-cycle management 2.
Middleware - Interoperability over multiple
generations - Asynchronous eventing replacing
RPC 3. High-level languages - More flexible
type systems - Dynamic module loading and
reflective binding 4. Application development
environments...
3
Pervasive Computing EnvironmentsA world of new
applications...
4
The AutoHAN Approach.

• Automatic configuration of the Home Area Network
• Control of the home or other closed
  domain/environment (e.g. spacecraft)
• An XML ontology for the home rooms, people and
  devices
• Logic programming for real-time control
• Automatic detection of feature interaction
• Federation of domains now being investigated
• Five or six people at each site.

O2S (Oxygen) Approach is complementary, currently
some differences, but using shared set of
pebbles.
5
The AutoHAN Approach, continued.

• I. Applications split apart from the components
  (Pebbles) they use
• An app may be as simple as a list of times to
  control a light
• or as complex as a TiVo
• Applications perform real-time and programmed
  control, but do not deal directly with streaming
  media
• Apps operate via a planner and are directly coded
  in logic programming or else describe their
  behaviour with logical predicates

• II. Techniques
• Existing solutions to planning problems

• III. Components (Pebbles)
• Devices with no autonomous behaviour
• Use UPnP or similar Reflexive technology
• Circuit view of component assembly
• A pebble may be a pushbutton or a speech
  recogniser.

6
Demo Environment The Active Home
Tuner
Display Device
Sounder Device
Home Network
Application Execution Platform
Media Store
7
Application Scripting and Execution

• We envisage four sources of applications
• 1. Base function of device.
• 2. Built-in ROM code works when neighbours find
  themselves on the same network.
• 3. Programs loaded from elsewhere but written by
  experts.
• 4. Rule programs that are written by users.
• Application scripting projects so far include
• 1 Media cubes tangible programming interface
• 2 IOTA ML-like XML manipulation language
• 3 CEL event language rule based controller
• 4 Python goals/techniques class library (MIT)
• 5 Real-Time Predicate Calculus (or Sequent/Horn
  style).

8
Prototype IR Cubes
9
A cube modifies the IR beam
Tomorrow cube
VCR
10
IR controller with Voice Input
When I press THIS BUTTON I want THIS CD
PLAYER to play THE CD IN IT NOW.
Remote Controller with microphone
CD Player
Voice Recogniser soft device
DECT basestation
Events to RBS
11
Goals and Rules Examples

• Create a video call to Peter.
• When Lulu comes home, play Thriller on all
  loudspeakers downstairs.
• Jonny is not allowed to spend more than 2 pounds
  per day on pay-per-listen.
• Fire Alarm must mute all music sources.
• The front gates must always be remotely openable
  by some method or other.

12
Goal/Technique wide-area applications
Goal-oriented Software Architecture
Standardized GOALS as commodities
Distributed database of TECHNIQUES
Victor
TeleConference(Victor, Steve)
Achieving goals by pursuit of sub-goals
Room?
Video
Audio
H21?
Phone?
Steve
13
Real-time logic programming

• We store all running apps (or info about them) as
  pure logic rules in our Rule-Based Controller.
  This
• 1. Understands detailed behaviour of local code
  in current domain
• 2. Understands constraints and obligations of
  applications running in neighbouring domains.
• 3. Prevents loading of inconsistent applications
  and implements priority and policies in the form
  of further rules.
• 4. Accepts non-rule code converted to rule form
  for import.
• Real-time logic programming allows seamless
  integration or real-time control, programming and
  consistency checking.

14
Rule-Based Controller Development

• Rules can be checked, composed and executed.
• Checking in advance spots potential conflicts,
• Composing from separate sources is just logical
  AND
• Rule execution in the style of Prolog makes
  things happen.
• Develop methodologies for
• rule representation, rule insertion, action
  explanation,
• feature interaction detection, prior solution
  reuse,
• rule priorities.
• Develop compiler for imperative code to extract
  rule behaviour
• This allows existing apps to be inserted into
  the rulebase and executed on the RBC engine
• Or it allows meta information about existing
  apps to be created

15
RBC Controller On A Stick
Application Scripts in a rulebase
Applications
Registry
Execution Platform
Platform OS and Network I/O
Ethernet etc
API

• Baseline
• A single controller for each home
• All apps are stored in rule script form on the
  controller
• All apps are executed by one engine (RBS)
• All I/O is via XML RPC or UPnP over the network

16
AutoHAN AppScript Rehydration
Running Application Scripts
Automatic Checker
Imperative command VM
RBS Engine Core
Binder or Re-hydrator
Application Loader
GENA Subscription Arbiter
DHAN registery lookup
GENA network events
HTTP
17
Current Status

• A wide variety of hardware and software Pebbles
  have been constructed
• A number of experimental execution engines have
  been tested
• Architecture details are currently being
  redesigned again with a closer integration of MIT
  techniques and Cambridge formal logic and to
  better support federation of RBCs.
• We hope to build a high performance Rule-Based
  Controller to the new architecture within six
  months and test under artificial load.

18
The End

• David.Greaves_at_cl.cam.ac.uk