This is an archive of the AutoHAN main index page from 2001.

Autohan is split into a core systems part, lead by David Greaves and a user interface part, lead by Alan Blackwell. We are just starting a new application scripting part to the Autohan project.

Further information about those working on the project and their current activities is here.

Core Systems Overview

In Autohan we are trying to solve the basic problems of home control, where a multitude of devices must interact with each other and the residents in a sensible manner. Our focus has been on designing an architecture, but now we are working on the application coding model and user interfaces.

The project is building on work done previously in the Computer Laboratory in the Events and Warren projects within the Opera and HAN subgroups of the SRG. The aim of Autohan is to develop an advanced and comprehensive methodology for control of home devices. The emphasis is on automatic configuration and automated enforcement of rules of home consistency. The project will use a type-safe language to manipulate XML expressions of the form used in UPnP and HomeAPI.

Autohan already has a set of devices, an XML repositorary and an event engine. We are working now on the semantics of the home control language.

Project Plan

The project is building a complete system that is a prototype of the home of the future. The system will assume that all devices implement the autohan protocols. The autohan protocols are extensions of the UPnP/HomeAPI protocols. An overview of the operation and architecture is given below. The protocols but not the implementation will be placed in the public domain. They would then neet to be promoted within an industry consortium such as HomeAPI or VESA or another relevant standards body.

Autohan operation and architecture

The system operates, in summary, as follows. Greater detail is in the Autohan Core Systems Draft (see link below). All devices are connected to a network of some sort and these networks are bridged within the home. The UPnP subsystem creates an IPV4 subnetwork that spans all devices. Devices register descriptions of themsevles using XML strings, as defined by UPnP and extended by ourselves, in an XML repositorary. The repositorary may be centralised, distributed or mirrored but we shall concentrate on the centralised implementation. The repositorary runs as a software agent on one of the more-able platforms in the home. The repositorary also contains information about the structure of the house and the people who live there. The way this information is placed there is covered in the user interface part of Autohan.

Devices export user interfaces to their components, as described in UPnP and the Autohan white paper. These interfaces are immediately available as web interfaces using the UPnP mechanisms. What is new in Autohan is that they export a semantic description of the application code that is built into them. The semantic description may be the code itself, provided it is written in our new Autohan Language (AL). They may also export the code to run on a server elsewhere in the system (perhaps the same platform that contains the registery). They may also contain or export other code that enables new applications to run given that network connectivity has been provided. Finally, they may request that code to support enhanced functionality is run on their behalf on the server.

Devices are designed so that the minimum functionality they need to have is a network interface, 1 Mbyte of ROM code, a less-than 2 MIPS CPU, 1 Kbyte of RAM and preferably a non-volatile or unique serial number.

Code running on the server is all implemented in our Autohan Language (AL). This is envisioned as a byte coded or interpreted language. Many applets written in AL are running concurrently on the server. This language contains type-safe mechanisms for dealing with XML expressions. The method by which strings in an Applet's body are bound to XML expressions in the respositorary is fundamental to the language. Example strings which need binding are `frontdoorbell', `kitchen', `media-server' and `default-ISP'. It also contains an advanced fork and kill statement which is highly integrated with a security, naming and proof architecture. Within the repositorary, a large set of operational rules and a heirarchy of rules for adding or deleting the rules exists. These rules govern what an applet may do and how an applet may fork and kill the execution of other applets.

Typical rules prevent the inadvertent muting of fire alarms, or people locking themselves outside the front door. The user interface part of the project will explore, for example, how a parent may write a rule to limit the amount of pay-per-view TV a child watches per day.

In summary, this is a project about implementation and semantics. The novel aspect of the implementation is that the semantics of the way devices operate is to some extent `understood' by the system and this helps us avoid programming errors. In the long term (e.g. 30 years), we could envisage that some of the consitency rules are enforced by national or state laws.

Further Information

Autohan is split into a core systems part, an application scripting part and a user interface part. There is a small amount of public information on the following two pages.

• Core Systems Draft.

• User Interface.

• Application Scripting (no additional info online today).