Ubiquitous Computing in the Auto HANOxygen Project The

Ubiquitous Computing in the Auto. HAN/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 CMI O 2 S/AUTOHAN OCT 04 1

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. . . CMI O 2 S/AUTOHAN OCT 04 2

Pervasive Computing Environments: A world of new applications. . . PC models: • Shrink-wrapped applications – static resource requirements • Installation headaches • Openness barriers Distributed models: Web-based models: application • Developer hell! • State inconsistencies, remote failures, reliability nightmares • Least common denominator web UI • Platform/language dependencies Holy Grail: • • • Modularity, extensibility, evolvability Simple application logic Automatic adaptation to resources Platform, language independent UI-independent application logic CMI O 2 S/AUTOHAN OCT 04 3

The Auto. HAN 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. O 2 S (Oxygen) Approach is complementary, currently some differences, but using shared set of pebbles. CMI O 2 S/AUTOHAN OCT 04 4

The Auto. HAN 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 Ti. Vo • 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 UPn. P or similar “Reflexive” technology “Circuit” view of component assembly A pebble may be a pushbutton or a speech recogniser. CMI O 2 S/AUTOHAN OCT 04 5

Demo Environment: The Active Home Display Device Tuner Sounder Device Home Network Media Store Application Execution Platform CMI O 2 S/AUTOHAN OCT 04 6

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). CMI O 2 S/AUTOHAN OCT 04 7

Prototype IR Cubes CMI O 2 S/AUTOHAN OCT 04 8

A cube “modifies” the IR beam Universal Remote Controller Tomorrow cube VCR CMI O 2 S/AUTOHAN OCT 04 9

IR controller with Voice Input When I press THIS BUTTON I want THIS CD PLAYER Remote Controller with microphone DECT basestation CD Player to play THE CD IN IT NOW. Voice Recogniser soft device Events to RBS CMI O 2 S/AUTOHAN OCT 04 10

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 payper-listen. Fire Alarm must mute all music sources. The front gates must always be remotely openable by some method or other. CMI O 2 S/AUTOHAN OCT 04 11

Goal/Technique wide-area applications “Connect me To Steve” Goal-oriented Software Architecture: Standardized GOALS as commodities Distributed database of TECHNIQUES Victor Tele. Conference(Victor, Steve) Video Audio Achieving goals by pursuit of sub -goals Room? H 21? Phone? Steve CMI O 2 S/AUTOHAN OCT 04 12

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. CMI O 2 S/AUTOHAN OCT 04 13

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 CMI O 2 S/AUTOHAN OCT 04 14

RBC Controller On A Stick Applications Registry Application Scripts in a “rulebase” Execution Platform OS and Network I/O Baseline: Ethernet 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 UPn. P over the network etc API CMI O 2 S/AUTOHAN OCT 04 15

Auto. HAN App. Script Rehydration Automatic Checker Binder or Re-hydrator Application Loader Running Application Scripts Imperative RBS command Engine VM Core DHAN registery lookup HTTP GENA Subscription Arbiter GENA network events CMI O 2 S/AUTOHAN OCT 04 16

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. CMI O 2 S/AUTOHAN OCT 04 17

The End David. Greaves@cl. cam. ac. uk