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

4. 4 CMI O2S/AUTOHAN OCT 04 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. 5 CMI O2S/AUTOHAN OCT 04 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 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. II. Techniques Existing solutions to planning problems

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

7. 7 CMI O2S/AUTOHAN OCT 04 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. 8 CMI O2S/AUTOHAN OCT 04 Prototype IR Cubes

9. 9 CMI O2S/AUTOHAN OCT 04 A cube “modifies” the IR beam VCR Universal Remote Controller Tomorrow cube

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

11. 11 CMI O2S/AUTOHAN OCT 04 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. 12 CMI O2S/AUTOHAN OCT 04 Goal/Technique wide-area applications “Connect me To Steve” Goal-oriented Software Architecture: Achieving goals by pursuit of sub-goals Standardized GOALS as commodities TeleConference(Victor, Steve) Victor Distributed database of TECHNIQUES Steve Audio Video Room? H21? Phone?

13. 13 CMI O2S/AUTOHAN OCT 04 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. 14 CMI O2S/AUTOHAN OCT 04 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 T his 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. 15 CMI O2S/AUTOHAN OCT 04 RBC Controller On A Stick 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 Registry Application Scripts in a “rulebase” Execution Platform Platform OS and Network I/O Ethernet etc API Applications

16. 16 CMI O2S/AUTOHAN OCT 04 AutoHAN AppScript Rehydration Running Application Scripts RBS Engine Core Imperative command VM GENA Subscription Arbiter DHAN registery lookup Application Loader Automatic Checker GENA network events HTTP Binder or Re-hydrator

17. 17 CMI O2S/AUTOHAN OCT 04 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@cl.cam.ac.uk