Pebbles: Original Work Plan

Technical Background

Today's drive toward full-time immersive computation and communication environments raises a host of new technical challenges in the software engineering arena. Systems supporting this model must continuously adapt to changes in user locations and needs, respond both to component failures and newly available resources, and maintain continuity of service as the set of available resources evolve. Equally, users wish to control, customise and program these environments using a wide variety of interfaces and paradigms. From the user's point of view, these distinct operations should blend seamlessly into each other, all being thought of as expressing some sort of intent.

In a simple but representative example, a video-conference link might be established between a user at a desktop workstation and an ambulatory colleague carrying a well-equipped handheld device. As the mobile user moves from one part of his campus to another, the system might adapt to changes in resource availability: varied wireless network technologies, high-quality plasma displays which come in and out of view, and the like. A goal of the immersive environment is to provide continuous service of the user-level goal -- connectivity with a colleague -- while allowing for opportunistic adaptation of the specific mechanism chosen to achieve that goal.

We propose to address these issues by a developing and prototyping a new dynamic component architecture capable of automatically assembling applications to address underspecified goals, each of which describes some desired service. Implementation choices are heuristically selected by an ongoing planning process which continues so long as the goal stimulating it remains pertinent; thus changes in the environment (e.g. location of user, available resources, etc.) stimulate reconsideration of previous choices and possible consequent re-implementation. In a three-year program, we will develop the theory and implement sufficient infrastructure to host a significant demo.

The system architecture we propose features planning and component layers, separated by a strong abstraction. We hope to largely automate the planning process using goal-directed assembly, and to provide in the component layer a repertoire of policy-neutral reusable building blocks. Our goal is a proposed API standard which simplifies and streamlines the implementation of applications in multi-vendor immersive environments, as well as lowering the entry barrier for companies building components for such applications. Such standards will clearly benefit UK companies in areas such as virtual reality, gaming and perpetual systems, as well as facilitating the evolution of the next-generation immersive computing environment that will eventually benefit nearly every business in the UK.

Starting Model

We are developing a model. Our current model involves two separable software layers:

  • 1. The planning/management layer, in which service requests from a variety of user interfaces are considered and resolved into an interconnected network of software components; and

  • 2. The component layer, which provides a systematic, platform-independent interface to an expandable repertoire of generic software modules together with mechanism for their instantiation on actual hosts.

    An important feature of our proposed architecture is its focus on the architectural separation of these layers, and the development of a coherent, future-proof interface API between them. Our goal is that the computationally intensive aspects of an application will be confined to the component layer, whose interconnected modules reflect individually specified and testable functions - and explicit parallelism - but not application-specific policy. The interface to the planning layer provides a simple, coherent, sequential model on which application-specific behavior can be built.

    In terms of an implementation architecture, we aim to build a fully symmetric, peer-to-peer system, whereby all hardware entities in the system can host any part of the system, according to what they chose to offer. Therefore, nodes running autonomous software components will each have a computational core, and various I/O devices, sensors, a finite store of energy, a control system allowing for stand-alone operation, and a communication link to the rest of the world. Some nodes may be PCs, but in general they can be anything, such as a PVR (personal video recorder).

    Postscript

    This was the original plan. We have gone a long way further!

    • Pebbles offer an API and describe themselves to their environment, but do not perform proactive operations on their peers. They are pretty passive really.

    END.       Pebbles Main Page..