Pebbles: Background and Overview

In recent years, Computing Science has made significant progress using strongly-typed HLL's, although certain vital concepts, such as those needed for code generation and RPC marshalling have been missing until recently. Now solutions to these problems can be found in, for example FreshML and MetaML, and are being taken up by the wider community as extensions to Java and C++ (e.g. generic parametric types, strongly-typed reflection and meta-programming). However, there are fundamental design decisions for the future of truely Ubiquitous Computing that are best explored using practical deployment:

• There remains a fundamental dichotomy between robust coding with compile-time warnings and errors (as supported by strongly-typed HLL's for hardware and software) and generating flexible, robust, eternal systems that can tolerate and adapt to huge changes in their execution environment and in their peers.
• A second tension arises between languages amenable to automated proof and fully-expressive programming languages. Do we need full power for scripting programs in the ubicomp scenario ? Or is it better to stick to limited or declarative forms and get more mileage from static analysis before nasty feature interactions occur ?
• A third tension arises at the application scripting stage. What is the fundamental difference between a write-once, execute-once command and a a more complex set of commands that continue to fire into the foreseeable future? How can UML be extended to support multi-view programming and reflexive interfaces to devices not thought of when a program/script was written?

One of the main aims of the Pebbles programme is to explore these problems by building a prototype system. In the system as a whole, Pebbles are small computing objects that fulfill a well-described function. Appropriate methods for describing Pebbles are being explored: WSDL, XML, UML, predicate logic or free text? Pebbles are used by applications that are synthesised directly from Goals. Goals are created by human beings, either for immediate satisfaction (e.g. "Turn the lights on") or as programs for future execution (e.g. "Record the Simpsons this evening and charge it to Mary").

The work here is undertaken as part of the AutoHAN project, whereas at MIT it is part of Project Oxygen.

The emphasis here in Cambridge UK is currently placed on control of delimited systems, such as a home or spacecraft. We started with a single, all-knowing controller, the Rule-Based Controller. Then we considered distributed execution of rules within a domain of interaction that is restricted by formal logical constraints. Next we shall allow rules/scripts to start operation in their own locally constrained domains and investigate the dynamic merging and division of the domains and how rules/scripts must be suspended or otherwise.

Broad-brush Summary of Work Tasks

Envisaged primary work tasks:

• Increasingly, everyday devices are able to describe themselves and be programmed over the network. These devices are also starting to be pro-active: they desire to interact with each other and control each other. Together with the Oxygen project at MIT, we are putting together demonstrator systems of this nature, with emphasis on controlling unforeseen interactions in the programmable home.

• We are developing tool chains for application scripting in the networked environment where feature interactions can be detected in advance.

• We are exploring techniques for exporting a device's or application's proactive behaviour in detailed and summary forms. Also perhaps its obligations within the environment.

• We are examining the limitations for declarative programming in an imperative environment. Can device APIs be changed to make them more amenable to declarative programming - we could perhaps increase their `idempotency'.

Envisaged secondary work tasks:

• We are exploring how semantic-web approaches, such as ontlology mapping, can be applied to low-level device control.

• We are exploring UML can break away from a traditional spec/compile/execute design flow and instead encompass dynamic device populations.

• We could enhance our scripting/debugging/visualization toolchains for multiview (speech/gesture/phone/keyboard etc.) for application scripting in the networked environment where feature interactions can be detected in advance.

Beneficiaries

One of our aims is to influence the manufacturers of embedded devices that participate in a ubicomp networking and the providers of their embedded operating systems, middleware and tool chains. We wish them to use new software architectures, based on our ideas, that clearly separate detailed mechanism from application scripting, with a view to applying automated formal safety checks to detect potential conflicts or undesirable situations. We wish to facilitate lightweight scripting or 'programming' using a variety of input interfaces, yet have a common infrastructure for checking, interrogation and execution.

Our technology looks as though it will be useful for those who implement industrial controllers and safety-critical systems. Although these systems are less dynamic, in terms of device population, than envisaged for ubicomp, the requirement for static analysis to predict future interaction is essentially the same.

Equally, we wish to promote new methods for lightweight application scripting. These methods should be easy to use through relieving the author/user of many implementation decisions, but also amenable to automatic checking and validation. Multi-view programming has been explored in this context by Hague. Currently, declarative forms are being investigated in this project, either as Goals or as directly executable specifications using Push Logic. Bastani is extending UML to support reflexive APIs and dynamic scripting.