CC301 :: Towards virtual appliances in the future digital home

This is the 3rd year project report from my Computer Science degree at the University of Essex. The original report is available for download in PDF format. This online version has had some sections omitted for space considerations (these include UPnP interface descriptions, Java class descriptions and the appendecies).
virtual-appliances.pdf (1,404.69 Kb)

I. Abstract

Virtual Appliances is the de-composition and re-composition of modern-day appliances in exciting new user-lead ways. The goal is to extend the functionality of existing appliances and even build new ‘virtual’ appliances from a set of distributed services.

UPnP is at the core of this vision, providing automatic service discovery on ah-hoc networks. XML, XSL and Apache Cocoon are used together to provide a web-based user interface onto the Virtual Appliances. This interface is automatically tailored to the display capabilities of client.

This project aims to demonstrate the concept of Virtual Appliances and lay the technological groundwork. To do this a number of de-composed UPnP devices have been created along with an adaptive user interface.

II. Acknowledgements

I would like to thank the following people for their help with this project:

  • Dr. Vic Callaghan, project supervisor, University of Essex, for general guidance throughout the project.
  • Paul Benyon, BT Exact, for feedback on the system.
  • Rowan Limb, BT Exact, for feedback on the system.

1. Introduction

1.1. Overview

Pervasive computing is appearing all around us and in the homes of the future computers will be ubiquitous. Everything from the oven to the window blinds will be augmented with microprocessors, the sole purpose of which to improve our quality of life. There are a number of research projects currently being undertaken at various universities and companies both in the UK and abroad trying the solve the problem of how to make people’s lives easier through pervasive and distributed computing. This project aims to look at the creation of virtual appliances in the future digital home.

In today’s world you can go out and buy appliances for your home such as video recorders, hi-fi’s, dishwashers, washing machines, burglar alarms, etc. However these devices are standalone, they can only do the job they were designed to do and they cannot communicate with other devices. Now imagine if each of these appliances were decomposed into their separate core functions. If each of these core functions were then exposed and made available as network services, other devices would then be able to communicate with each other and work together.

This is a completely new and novel idea as there is nothing else like this. It has the potential to massively empower users by allowing them to completely re-configure appliances and build new ones from a wide selection of "building blocks". In essence it allows appliances to become more than the sum of their parts, and could even be considered to be a paradigm shift in terms of pervasive and distributed computing.

Knowledge of embedded systems and distributed and pervasive computing will be required to demonstrate this concept. Solutions to the problem should not constrain the user in anyway as the goal is to free them and empower them. This is a fairly demanding and challenging problem, and is one that cannot be solved overnight. As such this project should not be considered a complete solution to the problem, but rather a demonstration of the basic concept and the foundations of a solution.

1.2. Scenario

The example below shows the components of a VCR. These are typically a TV tuner, a recording function, a timer, a clock and a display. A burglar alarm system has various sensors, lights and sirens. A microwave has a clock, a timer, a display and the actual oven.

Figure 1 – Functions of a VCR

With these services available to other devices it is then possible to extend the functionality of existing devices and even build new devices. For example, you could configure the timer on your kitchen cooker to make a noise through the hi-fi in your bedroom or through the speakers on your computer instead of beeping away in the other end of the house where it can’t be heard, causing your tea to get burnt.

From a security point of view if a webcam, motion sensor, light and a video recording service were available then you could create a CCTV appliance. As soon as the motion sensor detects movement it activates the light and tells the video recording service to record the video stream from the webcam.

It would also be possible to create a “master switch” for your house so that when you go out it automatically turns all your lights off, except for maybe a couple for security, closes the windows, turns the TV off, diverts calls from the home phone to your mobile, etc.

These are just a few simple examples, and the user should be able to link devices in an infinite number of ways to create all kinds of virtual appliances that meet their needs.

1.3. Project Goals

Aim: To demonstrate the concept of creating, configuring and managing virtual appliances.


  1. Complete research into problem domain and suitable technologies.
  2. Create some sample, simulated devices.
  3. Create association mechanism to allow the creation of virtual appliances.
  4. Create client program to allow the user to manage the virtual appliances.
  5. Test and evaluate the project.
  6. Complete final report.

The objectives outlined above are the minimum objectives that must be completed to meet the aim of the project. However, if time permits then are a couple of further objectives that would better demonstrate the concept of virtual appliances.

Further Objectives:

  1. Create some more complex simulated devices.
  2. Create some real devices using embedded boards.

2. Background

This section gives a brief introduction to pervasive and distributed computing and covers some existing projects looking at intelligent home networks and decomposition of appliances.

2.1. Pervasive and Distributed Computing

To be pervasive is to be spread throughout and in the context of computing this means that computers are everywhere. The word computer does not just refer to the beige box on your desk but to anything that contains a microprocessor. Even today it is reckoned that there are between 100-200 microprocessors in the typical house [1]. Pervasive computing is not just about hundreds of individual microprocessors spread throughout a particular environment though. It is vision whereby all the devices in which a microprocessor is embedded are networked together in order to communicate with each other and work together. This network is human-centric in that it is there for the sole purpose of improving our quality of life.

Distributed computing is where computation takes place on a number of computers on a network. The task may be a highly computational one such as decryption or simulation where a large number of medium-spec computers can provide the computational power of a super computer. Or it may simply be a case where a lowspec device such as a PDA requires a computational task to be performed that would take too long if performed on the PDA itself. This model is in contrast to the popular client-server model currently in use in many applications. As well as sharing computational power, a number of devices in a distributed system can also provide services to each other.

It is easy to see how distributed computing is relevant to pervasive computing as it allows the dissemination of information, sharing of services and through duplication can provide self-healing. If a single piece of information is scattered across a network of devices, then even if several of the devices are unavailable the information is still accessible. This concept applies to self-healing where if a number of devices provide a particular service required by another device, then in the situation where one of those required services disappears the device can simply search for the same service provided by a different device. If the state of the service as it were in use were communicated to the other devices then even if the device fails partway through servicing a client then another device could automatically take-over the processing without any interruption. This leads to highly reliable networks and services through the use of distributed information and services.

2.2. Similar Projects

There are a large number of projects currently being undertaken by companies and universities both at home and abroad looking at the home of the future. These projects are examining the problem from different angles and looking at the various aspects involved. For example, some are more concerned with how people interact with smart environments, some are looking at how to get devices to interact with each other and the network infrastructure required, and some are looking at how to create intelligent buildings that help take care of the people inside them.

As well as the home network and intelligent building aspect, there are a few companies researching Modular Computing. In particular there is IBM’s Meta Pad, described later, which essentially decomposes computers into modules for re-composition into different formats such has handheld and desktop formats.

This project is completely unique because of the concept of creating virtual appliances and giving the user the power to link devices in ways manufacturers and designers would not even have thought of. Despite the uniqueness of this project it is still important to look at other projects in the area of intelligent home networks and modular computing as the technology and ideas used by those projects will be useful in building the basic infrastructure for this project.

The first two projects described in this section are the iDorm at the University of Essex and AutoHAN at the University of Cambridge. Both these projects are looking at different aspects of the problem domain and neither have the concept of virtual appliances. However they are interesting in terms of the technology they employ. Finally, the third project described is IBM’s Meta Pad.

2.2.1. iDorm (University of Essex)

The iDorm at the University of Essex is a "purpose built environmental testbed for Intelligent Interactive Environments research, based upon student accommodation." [24]. The iDorm is filled with sensors and effectors using a variety of networks including 1-Wire and LonWorks. Each of these networks is connected to a central server that then provides status information and control through a common protocol.

Figure 2 – The iDorm

Figure 3 – The networks used in the iDorm

None of the sensors are hard-wired to any of the effectors in the iDorm so, for example, when a switch is pressed a state-change message is sent and then an action associated with that event is performed such as turning the lights on or closing the blind. This allows the whole environment to be re-configured depending on user preferences.

Figure 4 – UPnP in the iDorm

Devices on multiple networks have been UPnP enabled. Figure 4 shows how UPnP has been added to these devices and networks. UPnP, described in more detail later, enables the automatic discovery and utilisation of other devices on the network.

The iDorm uses embedded agent technology in order to adapt the environment tothe occupant’s preferences. The system starts with a basic set of pre-defined rules to allow switches to control lights and blinds, etc. When the user performs actions in the environment, the agent takes a snapshot of the state of the environment when the event was performed. The agent then uses various AI techniques to try and work out why the user performed the actions they did. Over time the agent learns the user’s preferences and is eventually able to adapt the environment to the user’s preferences on behalf of the user. For example, the iDorm is capable of learning that when the occupant is at the desk they like the desk lamp on, but then they are sitting on the bed they prefer the bed light on instead. The agent learns these behaviours by monitoring the user, but once learnt it is able to perform the actions without user interaction, although the user is always able to override the agent.

As well as directly interacting with the environment, the iDorm provides a number of interfaces that allow the user to configure and monitor it including a web interface, a 3D VRML model, a mobile phone WAP interface, and a voice control interface.

2.2.2. AutoHAN (University of Cambridge)

The Home Area Networking (HAN) Group was set up in September 1995 at the University of Cambridge Computer Laboratory where research interests range from the network architecture to human-computer interaction for home applications. The AutoHAN project is a middleware platform for inter-device communication using HTTP, XML and GENA. In this respect it is similar to UPnP, discussed later, but AutoHAN implements a form of access control through the use of a registry service and is able to communicate over HomePNA and HomeRF which differentiates it from UPnP. [2].

An AutoHAN consists of AutoHAN compliant devices, including dumb devices served by proxies, AutoHAN servers which provide services such as registration, encryption, video storage and general purpose execution resources for mobile devices, and an AutoHAN active home server which is the master home server. Any AutoHAN server can act as master server provided it has that ability. The main feature of the master server is that it is aware of resource allocation in all parts of the network and can allocate new requests to available resources. [3].

When AutoHAN compliant devices are connected to an AutoHAN network they can detect other services available on the network and offer services based on it. For example, a pair of audio amplifiers may detect each other and allow audio to be routed from one to the other. [3].

2.2.3. IBM’s Meta Pad & Antelope Technologies’ Modular Computing Platform

Both of these two projects are applying the concept of Modular Computing to PCs. A typical desktop PC system is modular; consisting of a monitor, mouse, keyboard, and the computer. The computer is also modular allowing graphics cards, hard disks and memory to be upgraded and this is without having to change or upgrade any of the peripherals. [22].

IBM originally developed the Meta Pad; a 3 by 5 inch portable computer core that is able to run Microsoft Windows XP and associated applications that can quickly transform into handheld, desktop, laptop, tablet, and wearable formats [23]. IBM developed the Meta Pad as a vehicle for studying technologies for pervasive computing, not as a product. Since then Antelope Technologies has signed a licence agreement with IBM to manufacture and market its own version of the Meta Pad, the Modular Computing Core.

Figure 5 – The IBM Meta Pad handheld with touch-screen next to a Meta Pad core

By building a complete computer core that can fit into the palm of a hand IBM and Antelope Technologies have removed the limitations of mobile computing by removing the need for a separate PDA and synchronisation with a desktop PC. The Meta Pad / MMC can be both a PDA and a desktop PC depending on whether it is connected a handheld shell or a desktop docking station.

2.3. Conclusion

All three projects discussed here are very different from each other and from this project. The main focus of the iDorm is the use of agent technology to develop intelligent environments that adapt to user preferences. This differs from the concept of Virtual Appliances because in this concept it is solely up to the user to create associations between devices in order to build Virtual Appliances. However the choice of hardware, network topology and network protocols are of interest.

The iDorm utilises the UPnP service discovery protocol to make devices and services available on the network. Different networks then have a UPnP wrapper to make the connected devices visible to the whole network though a common interface. AutoHAN also uses a service discovery protocol that is very similar to UPnP; the main difference being that it has been designed to operate over non-Ethernet networks. Again the use of network protocols and transports is of interest.

The IBM Meta Pad has nothing to do with home networks or intelligent buildings, but is an example of decomposing an appliance which can then be recomposed with different peripherals to construct a number of different configurations. This is similar to the vision provided by Virtual Appliances, except that the vision of Virtual Appliances encompasses all appliances, not just computers. The Virtual Appliances paradigm is far more wide ranging and flexible than the Modular Computing concept as it allows the user to be creative as they like and construct virtual appliances the manufacturer and designers may well have never envisaged.

3. Requirements

This section lists the functional and non-functional requirements for the system.

3.1. Functional Requirements

Outlined below are the list of services that the system should provide. It is important to note that as this is primarily a research project, the design and usability of the user interface is not a high priority.

  1. The user should be able to see a list of the devices currently available on the network.
  2. The user should be able to view information about the device and its status.
  3. The user should be able to view a list of the virtual appliances, the devices the appliance is made up of and the associations between the devices.
  4. The user should be able to create new virtual appliances and edit existing ones.

3.2. Non-Functional Requirements

The constraints on the design of the system are outlined below.

  1. The program code should be platform independent.
  2. The device code should be able to run on low-spec hardware.
  3. The system should be designed so that it does not require any network infrastructure to be in place (e.g. DNS, DHCP, routers, gateways, etc.).
  4. The system should be resilient to temporary failure of devices.
  5. The system should be as decentralised as possible.
  6. The user should be able to administer the virtual appliances from a variety of devices (PC, PDA, mobile phone, etc.).

4. Technical Discussion

Two steps are required if everyday appliances are to be decomposed and present their core functions as services on the network. Firstly the appliances will require a microprocessor that can control the hardware of the appliance and can communicate over the network. Secondly, a service discovery protocol is required to aid devices in discovering and utilising services that they require.

In the first half of this section a range of hardware platforms suitable for embedding in a variety of appliances are described. Each of these platforms have different architectures, form-factors and computational power. The platforms that are described are TINI boards, SNAP boards, PC/104 and MiniITX.

The second half of this section examines a number of currently popular service discovery protocols including Rendezvous, UPnP, Salutation and Jini.

4.1. Hardware Platform

4.1.1. TINI Board

TINI stands for Tiny InterNet Interface and is a platform developed by Dallas Semiconductor. TINI is "designed to provide system designers and software developers with simple, flexible and cost effective means to design a wide variety of hardware devices able to connect directly to corporate and home networks." [5]. The platform uses a Java programmable runtime environment and the chipset provides networking capabilities and device level communications. The TINI board comprises of a DS80C390 microcontroller clocked at 40MHz, 512kB of flash memory for critical system code and is available with either 512kB or 1MB of NV SRAM [6].

Figure 6 – A TINI board connected to a development board for access to Serial, CAN, Ethernet and 1-Wire busses

The TINI has Serial, CAN, 1-Wire, Ethernet and Parallel I/O allowing it to communicate with a wide range of devices from small sensors and actuators to factory automation equipment. Through the use of the TINI board these devices can then be monitored and controlled remotely or managed directly by a control program running on the TINI.

Figure 7 – An iButton

A large number of 1-Wire devices, known as iButton’s, are available from Dallas Semiconductor. An iButton is a small 16mm stainless steel can with a computer chip inside. Many varieties of iButton are available such as identification, memory, real-time clock and temperature loggers. 1-Wire ADC and relay boards are also available permitting use of other types of sensors and the ability to control large devices.

Example applications of the TINI technology include the deployment of simple sensor networks, the creation of a basic weather station with the use of the 1-Wire Weather Station Experimenter’s Kit [7], and control of simple devices through ADCs and DACs over the 1-Wire bus.

4.1.2. SNAP Board

SNAP stands for Simple Network Application Platform and is developed by a company called Imsys. SNAP is a "network-ready, Java-powered plug & play reference platform and is ideal for remote control, data processing and managing of everything from small sensors to advanced surveillance factory equipment." [8].

Figure 8 – SNAP Board

Figure 9 – The Cjip microprocessor

The SNAP board is very similar to the TINI board from Dallas Semiconductor described in the previous section. In fact, the SNAP is pin-for-pin compatible with the TINI and therefore plugs into the same development board allowing it the same access to Serial, CAN, 1-Wire, Ethernet and Parallel busses. The advantages of the SNAP over the TINI are that it is J2ME-CLDC compliant and has been certified by Sun Microsystems. The SNAP board is approximately 12x faster than the TINI in benchmarks performed by Imsys. The SNAP comes with 2Mb flash memory compared with 512Kb, and has 8Mb DRAM compared with 512Kb/1Mb NV SRAM.

As well as the increased memory capacity the SNAP board also uses Imsys’ own Cjip microprocessor clocked at 66MHz. The Cjip "microprocessor minimises the need for external controller hardware, i.e. the B.O.M., by doing parts of peripheral controller work (e.g. Ethernet MAC layer), internally in low-level microcode. Similarly, it executes Java bytecode without needing any accelerator hardware or software interpreter or JIT compiler." [9].

4.1.3. PC/104

PC/104 is a standard for PC-compatible modules that can be stacked together to create an embedded computer system [10]. The PC/104 system was developed in the late 1980s by a Californian based company called Ampro Computers. A specification was then published in 1992, and now over 150 vendors manufacture PC/104 products [11]. PC/104 gets its name from the fact that the systems are very similar to standard desktop PCs, except that they use a different form factor, and that the systems can be stacked together using a 104 pin connector.

Figure 10 – A typical PC/104 stack

PC/104 system typically consists of a CPU board and then a number of modules that provides additional features such as serial communications, network interfaces, video cards, digital and analogue I/O, sound, DSP, etc. Various CPU boards are available that use CPUs ranging from 8088s through to Pentiums. Because PC/104 systems are essentially standard PCs most PC programs and development tools can be used.

Power consumption for PC/104 modules is typically between 1-2 watts making them ideal for embedded systems. Additionally the modules measure only 3.6 by 3.8 by 0.6 inches and are designed to be much more rugged then their standard PC counterparts [10].

4.1.4. Mini-ITX

Mini-ITX is a motherboard form factor created by VIA, rather than a complete computer or embedded board. Mini-ITX differs from other motherboard form factors, such as ATX, because it is by far the smallest measuring just 6 inches square. Virtually everything from sound to video, serial, networking and USB is included on the motherboard meaning that PCI expansion cards are not required. Unlike normal PC motherboards the CPU is soldered to the board. This is because the CPU has been specially designed by VIA to run cooler and consume less power than standard Intel or AMD CPUs. A Mini-ITX PSU is rated at less than 100 watts compared to 350 watts for a typical desktop PC. Also most Mini-ITX based PCs are fan-less resulting in very small and very quiet computers.

Figure 11 – VIA EPIA M10000 Mini-ITX Motherboard

The CPUs available for Mini-ITX are currently based on either the C3 or Eden architecture. Neither architecture provides the raw performance of Intel or AMD architectures, although the more recent C3 processors have a performance similar to Intel Celeron processors of the same clock speed. Mini-ITX PCs are more suited to Audio/Video playback and network routing and firewalling [12].

4.1.5. Conclusion

In the first half of this section a range of hardware platforms suitable for embedding in appliances have been examined.

The SNAP and TINI boards are both low-power, small form-factor devices aimed at controlling a variety of hardware and at the deployment of sensor networks. As both these boards plug into the same development board they both have access to the same IO busses. Both boards use the Java programming language, which allows for rapid development of fairly large and complex programs. Where these two boards differ though is in the amount of memory and processing power available. As stated in section 4.1.2, the SNAP boards out performs the TINI board in a range of tests by a factor of 12 in benchmarks performed by Imsys. However the TINI board is available for ?36 compared with ?69 for the SNAP. As mentioned in section 2.2.1 the University of Essex use SNAP boards in their iDorm as well as in their pDorms/mDorms (plant dormitories). If cost is not a major constraint then the SNAP board is defiantly worth the extra money for the increased memory capacity and processing power.

For slightly more demanding appliances, a PC/104 stack may be more suitable. As described in section 4.1.3, PC/104 is based around the standard IBM PC architecture and uses processors ranging from 8088s through to Pentiums. PC/104 kits are available for specific applications such basic as IO, through to high performance multimedia, however depending on the required configuration of the system they can cost more than a typical desktop PC.

MiniITX differs from the other hardware platforms discussed, as it is basically a standard PC motherboard albeit in a much smaller form-factor. Therefore memory, a storage device and a suitable enclosure will also need to be purchased to build a complete system, although it is possible to buy pre-built systems. Because a MiniITX system is a PC it is much more suited to computer based appliances such as home entertainment systems or network appliances such as firewalls, routers and servers. A typical MiniITX system based around a 600MHz CPU and complete with a 40Gb hard disk, DVD/CDRW drive, 256Mb DDR RAM and Red Hat Linux preinstalled costs around £375.

4.2. Service Discovery Protocols

4.2.1. Rendezvous

RendezvousRendezvous is a networking technology developed by Apple. Rendezvous, also known as Zero Configuration networking, enabling automatic discovery of computers, devices, and services on IP networks. Rendezvous enabled devices can allocate IP addresses without a DHCP server, translate between names and IP addresses without a DNS server and locate and advertise services without using a directory server. Although developed by Apple, Rendezvous is an open standard and works with standard nonproprietary IP networks and equipment. Source code is freely for Rendezvous as well as software for Windows, Linux, UNIX, VxWorks and Pocket PC 2003 systems. [13].

Rendezvous makes uses of multicast traffic and as such only works on a network subnet making it ideal for ad-hoc local networking. When a Rendezvous enabled device is added to a network it must configure its IP address so that it can communicate with other devices. To do this it first tries sending a DHCP request and will use the IP address returned by a DHCP server if one is present. If a response is not received the device will then use link-local addressing. Here the device randomly selects an address from the predefined range of addresses set aside for link-local addressing ( The devices then uses ARP to check whether the chosen address is already in use. If it is already in use the device then randomly selects another address and then checks again.

Once the device has configured itself with an IP address is must then give itself and its services unique names on the network. Theses are usually based on the name of the device (e.g. HP DeskJet 930C). In the event of a name clash the last two bytes of the devices MAC address are appended to the name. Now the device has an IP address and a name it needs advertise its services to the network. To do this Rendezvous uses a variant of the DNS system known as mDNS-SD (multicast DNSService Discovery). The device sends a multicast message with its IP address, port number, name, services and other any other optional information. Every device on the network receives this network and stores the information.

At some point devices may need to know about the services offered by other devices. In order to do this the device must query the network for services of the type it requires, for example, a PC may need to know what printers are available. All devices on the network receive this query, but only the ones implementing the requested service respond. To reduce network traffic and increase efficiency the responses are also sent multicast so that every device receives them. Every device then saves the response to the query so that at a later stage if they need the same information they do not have to send a duplicate query as they already have the information.

Security was a top priority when Apple where designing Rendezvous. As Rendezvous makes use of standard protocols Rendezvous relies on the security built into those protocols. Also, as Rendezvous is open source it benefits from the fact that hundreds of programmers can examine the source code and identify bugs and vulnerabilities and then put updates back into the community. It is important to note however that Rendezvous only provides a mechanism for devices to discover each other. Once a device has discovered a service that it requires communication takes place using standard protocols.

4.2.2. UPnP

UPnPUPnP stands for Universal Plug and Play and is an open standard being pushed mainly by Microsoft and Intel although the UPnP forum created in June 1999 currently consists of more than 656 consumer electronics, computing and security companies [14].

Universal Plug and Play may sound very similar to the Plug and Play technology that Microsoft built into Windows, but the similarities end there. UPnP is a distributed, open networking architecture that employs existing Internet protocols, such as TCP/IP, HTTP and XML, to enable discovery and control between devices regardless of their operating systems and programming languages [15]. A number of UPnP stacks are currently available for C and Java from Intel, Siemens and currently one open source project.

Figure 12 – UPnP devices in the digital home

UPnP devices are logical containers with specified device types. Each UPnP device contains a number of related services each with its own unique service type. Each service contains a number of actions, similar to remote procedure calls, each of which reference service-defined state variables [16]. To aid interoperability between devices from different vendors the UPnP Forum has drawn up a number of device and service definitions giving specific types of device a standard interface.

Figure 13 – UPnP Control Points, Devices and Services

UPnP devices are passive entities that can be discovered and controlled by UPnP control points. Devices periodically advertise their presence on the network and can respond to searches issued by control points. Control points may also invoke actions on the device and retrieve the status of the device through its service’s state variables. A service’s state variables can also be evented so that any subscribed control point receives event messages whenever the value of the state variable is updated. Control points typically provide the user with access to the device’s capabilities and status [16].

Figure 14 – Steps to UPnP networking

The five steps to UPnP networking are shown in Figure 14. The first step for any UPnP enabled device to configure its IP address and this process identical to that of Rendezvous devices.

The second stage is discovery and is where devices advertise their services to the network. This is carried out by SSDP (Simple Service Discovery Protocol) which itself makes use HTTPMU and HTTPU which are variants of the HTTP protocol using multicast and unicast over UDP. When a device wishes to leave the network it must cancel its advertisement so that all control points are aware that the device is leaving. To guard against devices leaving the network without warning the device advertisements expire and devices should renew their advertisement in order to maintain a presence on the network.

The discovery stage also deals with control points wishing to find specific devices or particular types of devices or services. When a UPnP control point starts it uses SSDP to send a multicast query to discover all the devices currently present. Each device will then send unicast responses using SSDP to the control point. Once the control point has sent its query it should not normally need to send further queries as it will receive advertisements from new devices automatically as they join the network.

Once a control point has discovered a device that it is interested in it then needs to get a description of the device and the services that it provides. This is the third stage in UPnP networking. The device’s advertisement and query response messages contain a URL which points to an XML description document on the device. The description document is retrieved using standard HTTP over TCP/IP. The device description document includes vendor-specific information, manufacturer information, model name, serial number and URLs to the vendor and product web pages. The description document also contains a list of any embedded devices and services along with URLs for control, eventing and presentation.

Now that the control point has knowledge of the device and its services it can invoke actions provided by those services and poll the status of the services state variables. Invoking an action is similar to a remote procedure call where the action may take and return number of arguments. The control point uses SOAP (Simple Object Access Protocol) which is an XML based protocol normally used by web servers in a decentralised, distributed environment to call remote procedures on one another.

Some of a service’s state variables may be evented. This means that the service publishes updates whenever the variables change. Once a control point has discovered and learned about a device and its services it may subscribe to the service and receive event notifications whenever a state variable is updated. The event notification uses an extension to HTTP known as GENA (General Event Notification Architecture) which was defined to provide the ability to send and receive notifications using HTTP over TCP/IP and multicast UDP. When a control point initially subscribes to a service it receives it receives an initial update notification which contains all the state variables that are evented along with their values allowing the control point to initialise a model of the state of the service. To prevent services from continually sending event notifications control points must send a message to cancel the subscription. If however the control point disappears and fails to cancel its subscription, the subscription will eventually expire and so as long as the control point wishes to receive events it must renew its subscriptions.

The final stage in UPnP networking is the presentation stage. As long as the device has been discovered and its description document contains a valid presentation URL then the presentation page can be viewed in a standard web browser. The presentation page typically represents the state of the device and may allow the user to control the device, however the UPnP forum places no requirements on the presentation page other than that it is written in HTML and delivered using HTTP over TCP/IP.

The current version of UPnP has left security to one side for the time being, but as with Rendezvous, because UPnP makes use of standard Internet protocols it relies on the security built into those protocols. The second version of UPnP, currently being drafted by the UPnP forum, is said to include encryption and access control.

4.2.3. Salutation

SalutationSalutation is another service discovery protocol and is an open architecture being developed by the Salutation Consortium. However, where as both Rendezvous and UPnP make use of existing Internet protocols and an IP network, Salutation is truly independent of the operating system, programming language, communications protocol and hardware platform. It does not require a specific programming language, as does Jini, nor does it make use of protocols such as UDP or HTTP. Salutation is able to operate over any communication system including IP, IrDA and Bluetooth [17].

Figure 15 – The Salutation architecture

The Salutation architecture is shown in Figure 15. The Salutation Manager acts as a service broker for applications and services called Network Entities. A Network Entity may be a client, a service provider or both. When a service provider joins the network it registers its capabilities with its local Salutation Manager. The Salutation Manager allows Network Entities to discover and use services provided by other Network Entities. The Salutation Manager also provides a transport independent interface to the Network Entities through the SLM-API (Salutation Manager Application Program Interface). The Salutation Managers communicate with each other using SMP (Salutation Manager Protocol) which makes use of Sun Microsystems’ Open Networking Computing Remote Procedure Call version 2 protocol in order to perform their role as service brokers [18].

The Salutation Manager provides a transport independent interface known as the Salutation Transport Interface (SLM-TI) to transport dependent entities called Transport Managers (TM). The Transport Manger allows the Salutation Managers to be transport independent and a Salutation Manager may utilise one or more Transport Managers. The Transport Managers discover other Salutation Managers connected to the same transport. For each remote Salutation Manager that the Transport Manger discovers, it registers the with the local Salutation Manager.

Clients discover services that they are interested in by querying their local Salutation Manager. The Salutation Managers then co-ordinate and return results. Once the client has identified the service that it is interested in it can then retrieve the service description.

Figure 16 – The use of Service and Description Records

Services can be subdivided into functional units. For example a print service will probably contains just one functional unit called ‘Print’, but a fax service may contains several functional units such as ‘Print’, ‘Scan’ and ‘Send’. Attribute records are used to describe these functional units.

Once the client has the description of the service it may then use the functions provided by that service. To do this the Salutation Manager establishes a Service Session (a virtual data pipe) between the client and the service. Commands, responses and data are exchanged between clients and services on these data pipes in blocks called Messages. The format of these messages and protocol is known as Personality Protocols.

Unlike both Rendezvous and UPnP, Salutation does not address the issue of network configuration because of its transport independent design. Also, it would not be easy to design a generic solution to this problem that worked on all transports. Salutation addresses the issue of security by providing user authentication through the use of a user-id and password scheme.

4.2.4. Jini

Jini is Sun Microsystems’ Java based connection technology that makes it possible for various devices to form dynamic local area networks and offer services to each other. Jini uses the term federation to refer to groups of devices. The notion of services is a key concept in Jini, and is an entity that can be used by a person, a program or another service. A Jini system consists of services that can be collected together for the performance of a particular task. Services may be added or removed from a federation at any time.

Services communicate with each other using a service protocol which is defined by a set of Java interfaces. The service protocols are completely open and Jini only defines a number of service protocols for critical service interaction. These service protocols run on top of Java Remote Method Invocation (RMI).

A lookup service is used by clients to find services that they require. The lookup service is the major point of contact between the system and its users. The role of the lookup service is to map interfaces indicating the functionality provided by a service to sets of objects that implement the service. Additionally, descriptive entries may be associated with services to provide easier identification and selection of services by people. As well as storing lookup information for services a lookup service may include references to other lookup services to provide a hierarchical lookup system.

When a service starts up or is newly added to a Jini system it must locate and register itself with a lookup service. This discovery and registration takes place using two protocols known as ‘Discovery’ and ‘Join’. To locate a lookup service the service sends a multicast request to the local network asking for any lookup services to identify themselves. Once a lookup service has responded the service may then register itself by creating an object of the same type as itself and an array of lookup entry instances that specify attributes to describe the capabilities of the service and passing these as parameters to the lookup services register method. As with UPnP registrations expire after a set period and the service will need to renew its registration to maintain a presence on the network. Once a registration expires the lookup service removes the entry for that service.

A client wishing to use a service must, in the same was as a service, first discover the lookup services on the local network. Once the client has discovered a lookup service it must then pass a template to the lookup service which is used to filter the set of known services. This template specifies the type of service required as well as a list of attributes specifying the required capabilities of the service. The lookup service then returns an array of matching services in the form of service objects. It is then up to the client to choose a service or further filter the results. Once a service has been selected the client communicates directly with the service by invoking the available methods. As with UPnP, the client may also register with the service to receive notifications when the state of the service changes. All of this communication and event notification takes place using Java RMI.

Although a lookup service would normally be available, Jini is capable of operating with no lookup service available. In this situation clients use a technique called peer lookup. This technique involves the client sending out the same identification message used by a lookup service to request services to register with the client as though it were a lookup service. The client can then select the service required from the registration requests and drop or refuse the rest [19].

As Java is a platform independent programming language it is unable to perform system calls required to configure a device’s network configuration. As such Jini does not address the issue of network configuration and assumes that the device is either already configured or is capable of configuring itself.

For security Jini makes use of access control lists to determine which clients may use which other services. Also, as Jini uses RMI for communication it also relies on the security policies built into RMI.

4.2.5. Conclusion

The second half of this section has looked at four popular service discovery protocols, namely Rendezvous, UPnP, Salutation and Jini. Rendezvous appears to have been designed for computers to discover devices such as network printers and other computers. Rendezvous enables networks to be created without any perquisites for existing infrastructure, however once devices have discovered services they require they communicate out-of-band using their own protocols.

UPnP is very similar to Rendezvous in terms of its zero configuration of the network and service discovery routines. However UPnP provides a form of RPC where devices can invoke actions and subscribe to events offered by remote services. This does not appear to be possible with Rendezvous. Another advantage of UPnP is the number of UPnP enabled devices that already exist. At the moment though these are mainly ADSL routers and modems, however with Microsoft and Intel along with at least another 150 manufacturers backing UPnP it is almost certain that were will be plenty more UPnP enabled devices in the near future. Even the University of Essex’s iDorm and the University of Cambridge’s AutoHAN project use UPnP, and as mentioned in section 4.2.2 a number of UPnP stacks are freely available.

Where as Rendezvous, UPnP and Jini all require a TCP/IP network, Salutation is truly transport independent enabling it to work over IrDA and Bluetooth as well. Salutation is also platform and programming language independent making it the ideal choice for heterogeneous networks, however no source code or stacks seem to be available at the time of writing.

Jini is Sun Microsystems’s offering and as such is entirely Java based. While this allows it to be platform independent it places the constraint that all devices must be written in Java, especially as Jini makes heavy use of RMI. Another drawback is that Jini appears to be far too heavyweight for small embedded devices such as TINI and SNAP boards. Also, although Jini can operate in peer-to-peer mode, a typical Jini system relies on lookup services and as such is not as decentralised as Rendezvous and UPnP.

5. Design

5.1. Devices

In order to demonstrate the concept of creating virtual appliances a number of different devices will need to be designed. A few of these will be stand-alone devices such as lights and switches. Some more complex devices containing sub-components will also be designed to show the concept of decomposing appliances into their core functions.

These devices will be designed using UPnP for the reason described in section 4.2.5; including availability of stacks and source code, and because of the number of UPnP enabled devices already available. UPnP also meets the non-functional requirements listed in section 3.2 because of its platform independence, its non-requirement for preexisting network infrastructure, and its ability to run on reasonably low-spec hardware such as SNAP boards. The program code will be written using Java to allow platform independence.

Most of the devices will be simulated and run on a PC, however depending on time constraints a few simple devices may be built using SNAP boards with external sensors and actuators to better convey the concept of virtual appliances.

5.2. User Interface

As a wide range of devices should be able to manage the virtual appliances, such as PCs, PDAs and mobile phones, it is inconceivable to design and create numerous applications to run on each of the client devices. However, almost all of these devices have a web browser and are therefore capable of displaying web pages. The advantage of this approach is that not even a single line of code has to be written for these client devices, although it does require a server to be available. The use of a server in an otherwise decentralised environment is not ideal although the devices themselves will still function without the server, as it is only required by the user to manage them.

Using a web server to handle client requests for managing the devices has simplified the design of the interface application, however the issue of displaying information on such a variety of screen sizes is now present. One solution exists in the form of The Apache Cocoon project which was designed to solve exactly this kind of problem.

Cocoon is an XML publishing framework written in Java on top of SAX (Simple API for XML) and XSL (Extensible Stylesheet Language). Unlike HTML, which defines how text should be laid out, XML can be used to represent the actual content of a document allowing applications to very quickly scan through a document and extract the required sections. Unfortunately XML does not deal with how the content of the document of should be displayed and this is where XSL comes in. XSL, like CSS, is a stylesheet language, however XSL is much more than CSS because it gives the ability to completely transform XML documents. Generally XSL transforms XML documents from one XML-based language to another, such as XHTML, however through the use of XSL Formatting Objects, XML documents can be transformed into a variety of different formats such as Word documents or PDF documents for example.

Figure 17 – How Apache Cocoon transforms an XML document

This is ideal for tailoring information to the display capabilities of client devices without having to have multiple versions of a document. Also, as new devices appear with different display capabilities a new XSL document can be created and instantly the information can be tailored for that display without having to re-produce all the information in yet another format and without any re-coding. Another advantage of Cocoon is that it is written in Java and runs as a servlet meaning that it is platform independent.

5.3. Device Management Application

As Apache Cocoon runs as a servlet it would be sensible to use the Apache Tomcat server to run Cocoon on and also to design the UPnP device management application as a servlet to run on Tomcat. Because of the use of Cocoon, the role of the device management application is greatly reduced, it’s job now being simply to communicate with the UPnP devices on the network and return XML documents to Cocoon for styling for the particular client devices.

To comply with the functional requirements listed in section 3.1 the devicemanagement application must be able to provide a list of the UPnP devices currently on the network along with detailed information about the individual devices. It must also provide the ability to manage the associations between devices used in creating virtual appliances.

5.4. Rules

Rules will need to be used to create associations between individual devices. It is these associations that form the virtual appliance. The simplest example would be a switch and a light where a rule tells the light to change state as the switch does. These rules could be stored on a central server which then subscribes to devices in order to receive state change events and fires rules associated with those events, however this requires the server to be reliable.

An alternative solution is to store the rules on the individual devices. The rules could be stored on the output devices as these would usually have more computational power than simple sensor devices. This means that the rules are distributed amongst the devices so there is no single point of failure. This approach requires devices to implement a special service to handle the rules. Obviously existing UPnP devices will not have this service and so to remain compatible with these devices a service that can handle rules on behalf of other devices is required. This service could be provided by a dedicated server or provided by other devices in a similar way to how the lookup service is provided by devices in Cambridge’s AutoHAN system.

The user creates rules through the web-based interface when configuring virtual appliances. Therefore rules should be kept relatively simple so that the user interface is not overly complicated. This is especially important on hand-held devices that have a limited display area.

Ideally the rules could be defined using an XML based language, however this requires a lot of processing for low-power embedded boards such as SNAP and TINI boards. Lightweight XML parsers do exist for these boards, but as the boards will already be running the UPnP stack and the device code there would not be much memory or processing time spare for XML parsing.

Another solution is to define a syntax for rules that is not based on XML. An example of a rule used in an AutoHAN system is show below.

Rule tv-mute => TVOn(TVID) ->
                   (telephone-rings(PHONEID) | door-bell(DOORID))
                   - TVOff(TVID);

This rule states that the television volume is should be muted if the telephone or the door bell rings. The problem with rules such as this is that the application must understand semantics such as "telephone-rings" and "door-bell" [4]. The meaning of these semantics could be hard coded but then new types of devices could not be added without modifying the code of the other devices.

What is needed is a simple IF-THEN type rule that will work with any type of device. With UPnP the state of a particular service is available through the service’s state variables. Invoking actions on the service can also change the state of the service. UPnP devices and services are identified on the network through unique IDs, but can also be grouped by type. Therefore rules can be built around the ID of a device, the ID of one of its services and then either one of the services state variables or actions. The rules can then be constructed by the user through the web interface by way of selection boxes for the device, service, state variable, action and associated values.

Rules could then be sent to devices through UPnP actions where each part of the rule is a separate argument. For example, the following rule states that when the switch with ID 123 is in position 1, the light with ID 456 will turn on:

    Device ID     123
    Service ID     Switch.1
    State Variable     Position
    Value     1
    Device ID     456
    Service ID     Light.1
    Action     Power
    Value     1

5.5. System Architecture

An overview of the system architecture is shown in Figure 18. The Virtual Appliance Management application communicates with the UPnP devices and exports information in XML. When a client wishes to view the state of or manage the virtual appliances Cocoon applies a particular XSL stylesheet to the XML data from the management application depending on the display capabilities of the client.

Figure 18 – System Architecture Diagram

6. Implementation

6.1. Introduction

This section covers the implementation of the Virtual Appliance system including numerous devices and the management servlet. As stated in the design section UPnP will be used for the service discovery protocol to allow devices to discover each other and for the management application to control the devices. The management application will be written as a Java Servlet running on top of the Apache Tomcat server. Tomcat will also run Apache Cocoon which will be used to tailor the XML documents from the management applications for the specific client devices.

All the program code is written using Java for platform independence. The specific UPnP stack used is the Siemens UPnP Java Stack v1.0.1. All coding is carried out using the freely available and open source Eclipse project and all code is self-authored (i.e. no auto-generated or wizard-generated code has been used).

6.2. Devices

Details of the UPnP interfaces and and descriptions of Java classes have been omitted from this version because of space considerations, however it is available in the original PDF version of this report.

6.2.1. Light Bulb

The UPnP Light Bulb device is a simple representation of a light bulb that can be turned on or off. As this device is an output device it implements the device association service, described later, allowing it to associated with other devices and store rules.
UPnP Light Bulb

6.2.2. Switch

The UPnP Switch device is a simple representation of a toggle switch having just two states. When the switch is clicked, either through the on screen GUI, or through the presentation page, the state of the switch toggles.
UPnP Switch

6.2.3. Timer

The UPnP Timer device is a simple timing device. The duration can be set and the timer started and stopped. Event notifications are sent when the timer has started counting and when it has finished. As this device is an output device it implements the device association service, described later, allowing it to associated with other devices and store rules.
UPnP Timer

6.2.4. Motion Sensor

The UPnP Motion Sensor device is a representation of a real life motion sensor. The sensor reacts to mouse movement over the window.
UPnP Motion Sensor

6.2.5. Camera

This is the first non-simulated UPnP device so far. Using the Java Media Framework this device grabs images from any WebCam or video capture device supported by the operating system. Originally it was intended that this device would be able to stream video, but this turned out to be too time consuming, so the device simply captures images when asked and then makes them available through the built in web server provided by the UPnP stack.
WebcamUPnP Camera

6.2.6. mDorm – Temperature and Light Sensor

mDormThe mDorm (also known as the pDorm) could be considered as a miniature version of Essex’s iDorm. It is a cabinet containing a SNAP board with two sets of lights, a fan, a heater, a temperature sensor and light sensor. The mDorm is designed as a purpose built, fully controllable environment for the remote care of plants, although it is being used in this project purely for its sensors and actuators.

A number of UPnP devices were written for the mDorm in order to assess the capabilities of the SNAP board. Some of these test devices simply accessed a single sensor or actuator, and others accessed multiple sensors and actuators.

Development of the UPnP devices on the SNAP board made use of the SNAP firmware revision 0.15.1 and an older version of the Siemens Java UPnP Stack. Version 1.0.0 of the Siemens Java UPnP Stack had to be used as the latest version would not work on the SNAP because it is not J2ME-CLDC compliant and therefore uses classes not available on the SNAP. Also, Java code to access the mDorm’s sensors and effectors was provided on the Essex University CC464 module page [20]. This code was later modified by myself to improve speed and memory utilisation. This modified version of this code is given in Appendix D. During testing the modified version was 2.64 times more memory efficient and 1.72 times faster than the original code when controlling lights and accessing light and temperature sensors. The code used to perform these benchmarks is included in the modified Java class in Appendix D.

During the assessment of the SNAP’s capabilities it became apparent that running more than two UPnP devices caused memory usage to reach critical levels often causing the SNAP board to crash requiring a power-cycle to reset it. Based on these findings it was decided to just UPnP enable the light and temperature sensors in the mDorm.

During development of the UPnP devices for the mDorm a bug was found in the class in the SNAP firmware (revision 0.15.1). The problem was with the toString() method not including a forward-slash (/) between the port number and the file name in the URL. This caused a NumberFormatException when trying to determine the port number from the URL because it had merged with the filename. Imsys (the makers of the SNAP) were informed and within 24 hours a response was received confirming the bug and stating it would be fixed in the next release.

This bug did not prove to be a problem in the development of the mDorm UPnP devices as it only affected UPnP Control Points. The bug was found whilst testing a UPnP Control Point on the mDorm which is required by the Association service. As such, the devices on the mDorm are currently incapable on storing and handling rules.

6.2.7. Internet Radio

The UPnP Internet Radio is the first complex simulated device to be written. The appliance contains a total of four embedded devices and five services:

  • LCD Display
  • Clock
  • Tuner
  • Audio Playback

The application uses JavaLayer (the MP3 decoder, player and converter library for the Java platform) [21] for streaming audio from a number of Shoutcast servers on the Internet. To keep things simple, and as this device is only a simulation, the Tuner device merely maintains a list of radio stations (URLs to Shoutcast servers). One of these URLs is then passed to the Audio Playback service which actually performs the streaming. The Internet Radio also provides a clock service which can provide time to other devices on the network, and a display service allowing other devices to display a message on the radio’s LCD screen.
UPnP Inet Radio

6.2.8. Audio/Video Playback Device

The second complex UPnP device is an Audio/Video playback device. The device is designed to play back video files and streams, display still images and stream audio from Shoutcast servers. It consists of the same Audio Playback device as the UPnP Internet Radio as well as a Video Playback device which utilises the Java Media Framework for the playback of MPEG videos.
UPnP AV Device

6.3. Device IDs

Every UPnP device, both root devices and embedded devices, must have a Universally Unique Identifier (UUID). This ID is used to identify a specific instance of a device and as such should never change.

UUIDs are 128-bit numbers that are guaranteed to be universally unique. Though, unlike MAC addresses for network cards these IDs do not need to be obtained from a registration authority. A typical UUID is based on the time of generation, the last few bytes of the device’s MAC address and some random numbers, although UUIDs can be generated based solely on time or random numbers. The string representation of a UUID look like: af688879-b94f-4d96-9da0-f11e99f167d8

For all the devices in this project the UUIDGen class generates the device’s UUID. Upon initial start-up the device will generate itself a UUID and store it, along with a couple of other configuration options, in the file. This file is then read at subsequent start-ups allowing the device to continue using the same UUID, although if this file is deleted or corrupted the UUID will be automatically generated again. Because Java cannot perform low-level system calls it is unable to determine the MAC address of the Ethernet adapter on the device, as such all UUIDs generated are random number based. To ensure uniqueness all devices except for the mDorm device use for the generation of random numbers as it provides cryptographically strong pseudo-random number generation.

Please note that the code used to generate the UUIDs for this project has been based on code from the freely available and open-source Java UUID Generator project.

6.4. Device Identification and Association

6.4.1. Identification Service

In order to distinguish between different devices of the same type when managing virtual appliances, some kind of personal identification is required. It has been previously stated that this project should be as distributed as possible. As such mapping device IDs to a user defined name and location directly on the management application servlet is not the best solution. A better solution is to store this information on the devices themselves. Names and locations for devices can then be manipulated through a UPnP Identification service. The user is still able to update the name and location of a device through the user interface, but the management application then forwards these updates to the specific devices.

The Identification service contains the following state variables:

Table 25 – Identification Service State Variable table
Variable Name Data Type Default Value Evented?
FriendlyName String 0 Yes
LocationName String 0 Yes
A_ARG_TYPE_String String 0 No

The State Variables FriendlyName and LocationName store the user defined friendlyname and location name. Both these state variables are evented so that control points receive the identification information when it is updated. A_ARG_TYPE_String is a Related State Variables for the SetFriendlyName() and SetLocationName() actions.

The Identification service also defines the following actions:

Table 26 – Identification Service Action table
Name Direction Related State Variable
GetFriendlyName FriendlyName Out FriendlyName
GetLocationName LocationName Out LocationName
SetFriendlyName FriendlyName In A_ARG_TYPE_String
SetLocationName LocationName In A_ARG_TYPE_String

GetFriendlyName and GetLocationName simply return the value stored in their Related State Variables. SetFriendlyName and SetLocationName can be used to update the friendly name and location name.

6.4.2. Association Service

A Virtual Appliance is made up of associated devices. In turn, these associations are made up of rules between devices, and as previously described, these rules are to be stored in the devices themselves rather than on a centralised server. The rules are of an IF-THEN style where the condition specifies a state of a State Variable on a given remote device, and the action specifies a UPnP action to invoke on the local device (rules are typically stored on actuator devices). For reasons given previously the various parts of the rule will be broken down into arguments which can be passed to devices through a UPnP action.

The Association service (urn:www-uk-dave-com:service:Association:1) contains the following state variables:

Table 27 – Association Service State Variable table
Variable Name Data Type Default Value Evented?
UpdateNotification String   Yes
A_ARG_TYPE_Virtual_App_Name String   No
A_ARG_TYPE_Remote_UDN String   No
A_ARG_TYPE_Remote_DescriptionURL String   No
A_ARG_TYPE_Remote_ServiceID String   No
A_ARG_TYPE_Remote_ServiceType String   No
A_ARG_TYPE_Remote_VariableName String   No
A_ARG_TYPE_ComparisonType Integer   No
A_ARG_TYPE_Remote_VariableValue String   No
A_ARG_TYPE_Local_ServiceID String   No
A_ARG_TYPE_Local_ServiceType String   No
A_ARG_TYPE_Local_ActionName String   No
A_ARG_TYPE_Local_ArgumentName String   No
A_ARG_TYPE_Local_ArgumentValue String   No
A_ARG_TYPE_RuleID Integer   No
RuleCount Integer   No
A_ARG_TYPE_Boolean Boolean   No

UpdateNotification and RuleCount are the two main State Variables with the rest being Related State Variables for the AddRule() and GetRule() actions. RuleCount contains the number of rules in the devices rule base. UpdateNotification reflects the previous invoked action so that the Management Application can update its cache. Fore example, if a new rule is successfully added the value of UpdateNotification will be set to "Rule x Added.". The Management Application can then parse this message and download a copy of the new rule. More on the Management Application will be discussed in the next section.

The Association service also defines the following actions:

Table 28 – Association Service Action table
Name Direction Related State Variable
AddRule VirtualAppName In A_ARG_TYPE_Virtual_App_Name
RemoteUDN In A_ARG_TYPE_Remote_UDN
RemoteDescriptionURL In A_ARG_TYPE_Remote_DescriptionURL
RemoteServiceID In A_ARG_TYPE_Remote_ServiceID
RemoteServiceType In A_ARG_TYPE_Remote_ServiceType
RemoteVariableName In A_ARG_TYPE_Remote_VariableName
ComparisonType In A_ARG_TYPE_ComparisonType
RemoteVariableValue In A_ARG_TYPE_Remote_VariableValue
LocalServiceID In A_ARG_TYPE_Local_ServiceID
LocalServiceType In A_ARG_TYPE_Local_ServiceType
LocalActionName In A_ARG_TYPE_Local_ActionName
LocalArgumentName In A_ARG_TYPE_Local_ArgumentName
LocalArgumentValue In A_ARG_TYPE_Local_ArgumentValue
GetRule RuleID In A_ARG_TYPE_RuleID
VirtualAppName Out A_ARG_TYPE_Virtual_App_Name
RemoteUDN Out A_ARG_TYPE_Remote_UDN
RemoteDescriptionURL Out A_ARG_TYPE_Remote_DescriptionURL
RemoteServiceID Out A_ARG_TYPE_Remote_ServiceID
RemoteServiceType Out A_ARG_TYPE_Remote_ServiceType
RemoteVariableName Out A_ARG_TYPE_Remote_VariableName
ComparisonType Out A_ARG_TYPE_ComparisonType
RemoteVariableValue Out A_ARG_TYPE_Remote_VariableValue
LocalServiceID Out A_ARG_TYPE_Local_ServiceID
LocalServiceType Out A_ARG_TYPE_Local_ServiceType
LocalActionName Out A_ARG_TYPE_Local_ActionName
LocalArgumentName Out A_ARG_TYPE_Local_ArgumentName
LocalArgumentValue Out A_ARG_TYPE_Local_ArgumentValue
GetRuleCount RuleCount Out RuleCount
DeleteRule RuleID In A_ARG_TYPE_RuleID
Status Out A_ARG_TYPE_Boolean

AddRule allows rules to be added to the device’s rule base. The action takes 13 arguments which make up the rule. These arguments include information such as the ID of the input/remote device, the URL to its XML description document, the ID and type of the service as well as the name and value of the State Variable. The value of the comparison type argument should be one of 1, 2 or 3 corresponding to equals, less than or greater than, the service ID and type on the output/local device, the action name and the name and value of one of the action’s arguments. AddRule returns the ID of the new rule in the rule base, or a value of -1 if the rule could not be added because it was invalid.

Passing a number to GetRule returns the corresponding rule from the rule base. If the given rule ID does not exist in the device’s rule base then null is returned for all output arguments.

DeleteRule is used to delete a rule from the device’s rule base and ClearRules removes all rules from the device’s rule base.

When the UPnP AddRule method is invoked the rule is passed to the addRule() method of the AssociationManager class in the form an instance of the Rule class. This method checks the rule’s validity including checking both device’s services, state variables and actions exist, and checks if an identical rule already exists. If the rule is valid and unique then the AssociationManager, which comprises a UPnP Control Point, subscribes to the input device’s service assuming there is not already a subscription. The rule is also saved to disc and information about the input device added to a UPnPDeviceStore (a class to simply store information about devices, services and subscriptions).

Once the AssociationManager has subscribed to a device it will begin receiving event notification from devices whenever one of their state variables changes. An instance of the UPnPSubscriptionEventHandler is created for every subscription. When an event notification is received the event is passed to the eventReceived() method of the AssociationManager class. The eventReceived() method then checks the ID of the device the rule came from, the service, the name of the state variable and the value of the variable against all the condition halves of the rules in the rule base. Any rule that matches is then placed in a queue. This queue is then passed to a RuleMatchThread class which invokes each of the matching rules actions in a separate thread allowing the AssociationManager to respond to the remote device confirming receipt of the event notification before a timeout occurs.

If one of the remote devices goes offline then obviously part of the virtual appliance will not function. When the device comes online again it announces itself to the network. As the AssociationManager receives announcement messages from all devices on the network it checks the device from which the announcement was received against all devices listed in the condition half of all the rules in the rule base. If there is a match the AssociationManager re-subscribes to the device’s service(s).

Because the rule base is saved to disc then when the local device restarts the rule base is loaded back into memory. The AssociationManager sends a search query for all devices. All currently online devices will respond to this query and the AssociationManager will re-subscribe to required devices in the manner described above.

When rules are removed or the rule base is cleared the AssociationManager unsubscribes from the services provided that there are no other rules requiring them. This then prevents devices needlessly sending event notification over the network.

6.4.3. Rule Proxy Device

As stated previously, other UPnP devices will obviously not implement the device Association service so to remain compatible with those devices a service needs to be created than can store and handle rules on behalf of other devices. This service could be implemented in by another device as part of its regular services, or it could be implemented in a device specifically designed for this task. The UPnP Rule Proxy device takes the latter approach.

The UPnP Rule Proxy device implements only one service and does not provide any sort of user interface other than that provided by the UPnP presentation page. The Rule Proxy service (urn:www-uk-dave-com:service:RuleProxy:1) is very similar to the regular Association service providing the same AddRule, GetRule, DeleteRule, ClearRules and GetRuleCount actions.

The Rule Proxy service contains the following state variables:

Table 29 – Rule Proxy Service State Variable table
Variable Name Data Type Default Value Evented?
UpdateNotification String   Yes
A_ARG_TYPE_Virtual_App_Name String   No
A_ARG_TYPE_Input_UDN String   No
A_ARG_TYPE_Input_DescriptionURL String   No
A_ARG_TYPE_Input_ServiceID String   No
A_ARG_TYPE_Input_ServiceType String   No
A_ARG_TYPE_Input_VariableName String   No
A_ARG_TYPE_ComparisonType Integer   No
A_ARG_TYPE_Input_VariableValue String   No
A_ARG_TYPE_Output_UDN String   No
A_ARG_TYPE_Output_DescriptionURL String   No
A_ARG_TYPE_Output_ServiceID String   No
A_ARG_TYPE_Output_ServiceType String   No
A_ARG_TYPE_Output_ActionName String   No
A_ARG_TYPE_Output_ArgumentName String   No
A_ARG_TYPE_Output_ArgumentValue String   No
A_ARG_TYPE_RuleID Integer   No
RuleCount Integer   No
A_ARG_TYPE_Boolean Boolean   No

The State Variables here are the same as the Association service except remote has been changed to input and local has been changed to output. Two new State Variables have also been added; A_ARG_TYPE_OutputUDN and A_ARG_TYPE_Output_DescriptionURL. These are specific to the Rule Proxy as it needs to know the ID of the output device along with the URL to its XML description document.

The Rule Proxy service also defines the following actions:

Table 30 – Rule Proxy Service Action table
Name Direction Related State Variable
AddRule VirtualAppName In A_ARG_TYPE_Virtual_App_Name
InputDescriptionURL In A_ARG_TYPE_Input_DescriptionURL
InputServiceID In A_ARG_TYPE_Input_ServiceID
InputServiceType In A_ARG_TYPE_Input_ServiceType
InputVariableName In A_ARG_TYPE_Input_VariableName
ComparisonType In A_ARG_TYPE_ComparisonType
InputVariableValue In A_ARG_TYPE_Input_VariableValue
OutputUDN Out A_ARG_TYPE_Output_UDN
OutputDescriptionURL Out A_ARG_TYPE_Output_DescriptionURL
OutputServiceID In A_ARG_TYPE_Output_ServiceID
OutputServiceType In A_ARG_TYPE_Output_ServiceType
OutputActionName In A_ARG_TYPE_Output_ActionName
OutputArgumentName In A_ARG_TYPE_Output_ArgumentName
OutputArgumentValue In A_ARG_TYPE_Output_ArgumentValue
GetRule RuleID In A_ARG_TYPE_RuleID
VirtualAppName Out A_ARG_TYPE_Virtual_App_Name
InputDescriptionURL Out A_ARG_TYPE_Input_DescriptionURL
InputServiceID Out A_ARG_TYPE_Input_ServiceID
InputServiceType Out A_ARG_TYPE_Input_ServiceType
InputVariableName Out A_ARG_TYPE_Input_VariableName
ComparisonType Out A_ARG_TYPE_ComparisonType
InputVariableValue Out A_ARG_TYPE_Input_VariableValue
OutputUDN Out A_ARG_TYPE_Output_UDN
OutputDescriptionURL Out A_ARG_TYPE_Output_DescriptionURL
OutputServiceID Out A_ARG_TYPE_Output_ServiceID
OutputServiceType Out A_ARG_TYPE_Output_ServiceType
OutputActionName Out A_ARG_TYPE_Output_ActionName
OutputArgumentName Out A_ARG_TYPE_Output_ArgumentName
OutputArgumentValue Out A_ARG_TYPE_Output_ArgumentValue
GetRuleCount RuleCount Out RuleCount
DeleteRule RuleID In A_ARG_TYPE_RuleID
Status Out A_ARG_TYPE_Boolean

Again, these are virtually identical to the actions provided by the Association service with the exception that the AddRule and GetRule actions have two extra arguments for the ID and description URL of the output device.

The Rule Proxy functions in very similar way to the Association service. It uses a slightly modified version of the AssociationManager class called a RuleManager, but the basic functionality is the same. Rules are stored in a ProxyRule class that extends the regular Rule class to take into account the ID and description URL of the output device.

6.5. Management Servlet

The Management Servlet is essentially a UPnP Control Point. The Control Point code is contained in the UPnPControlPoint class while the Servlet code is contained in the VirtualAppliancesServlet class.

When the Servlet is initialised it begins searching the network for any UPnP devices. As devices are discovered and announced information about them and their services is cached in an instance of the UPnPDeviceStore class (this is the same class used by the Association service). If the device implements the Identification service then a subscription is made and the name and location information cached. Likewise, if the device implements the Association or RuleProxy services a subscription is added and the rules downloaded and cached. These rules are stored in instances of the Rule and ProxyRule classes and managed by an instance of the RuleManager class. As rules are added and deleted from devices the UPnPControlPoint will receive notifications and update the RuleManager accordingly.

Figure 22 – Class hierarchy for the Management Servlet

The VirtualAppliancesServlet class is responsible for handling requests from clients and returning the required XML documents. Documents and actions are specified by passing parameters in the URL. For example, the URL will result in the list of currently online devices being returned while will return a list of Virtual Appliances and their rules. Users will not have to worry about these URLs or the XML documents as Cocoon will request these documents and generate the HTML page.

The XML documents returned by the servlet are constructed based on the contents of the cache of devices and rules. Examples of some of the XML documents can be found in Appendix A.

The contents of the caches is only updated by event notifications from devices, so when a rule is added to a device through the user interface the rule is not actually added to the cache until an event notification is received from the device. This means that the servlet does not have to perform any validity checking on arguments other than to ensure the correct types and amounts are present.

6.6. User Interface

As mentioned previously Apache Cocoon is used to generate the user interface. It does this by taking the XML output from the Management Servlet and applying particular XSL stylesheets to generate an XHTML document (XHTML is a version of HTML which conforms to XML rules and is compatible with all browsers). The stylesheets used depend on the page being requested and the device the request came from. The rules used to determine the transformations are contained in a Cocoon Sitemap file.

To determine whether a request has come from a PC or a PDA the Cocoon sitemap has been configured to check the client’s user-agent string. This is a string sent by the web browser to the server as part of the HTTP request and serves the purpose of identifying the browser. Cocoon can detect the type of client by matching sub-strings of the user-agent string. Below is an extract from the sitemap file showing the substrings used to identify PCs, PDAs and mobile phones.

<map:selectors default="browser">   
   <map:selector logger="sitemap.selector.browser" name="browser" src="org.apache.cocoon.selection.BrowserSelector">   
      <browser name="pc" useragent="MSIE 5"/>   
      <browser name="pc" useragent="MSIE 6"/>   
      <browser name="pc" useragent="Opera"/>   
      <browser name="pc" useragent="Netscape"/>   
      <browser name="pc" useragent="Firebird"/>   
      <browser name="pc" useragent="Gecko"/>   
      <browser name="pda" useragent="MSPIE"/>   
      <browser name="pda" useragent="Microsoft Pocket Internet Explorer"/>   
      <browser name="pda" useragent="WinCE"/>   
      <browser name="pda" useragent="Windows CE"/>   
      <browser name="pda" useragent="PPC"/>   
      <browser name="wap" useragent="Nokia"/>   
      <browser name="wap" useragent="UP"/>   
      <browser name="wap" useragent="Wapalizer"/>   

Although it was originally suggested that mobile phones might also be used to manage the Virtual Appliances, it has become apparent after creating the PDA stylesheets that displaying the required information on a mobile phone screen would be very difficult. Also, although creating rules for Virtual Appliances is reasonably simple from a PC and PDA, it would be extremely complicated from a mobile phone. For these reasons no mobile phone stylesheets have been developed.

Sample XSL documents are included in Appendix B, and screenshots of the resulting web pages are included in Appendix C.

6.7. UPnP & SNAP Issues

6.7.1. UPnP Reliability

During development of the UPnP devices a number of sporadic anomalies kept recurring. Occasionally control points would seemingly miss announcements from devices causing the device to either not appear online or be removed because its lease expired. Similar problems seemingly randomly occurred with subscription renewals being missed causing subscriptions to be removed and breaking the virtual appliance. Another problem encountered affected the more complex UPnP appliances which consisted of embedded devices. Sometimes the root device would announce its presence but the embedded devices would not be announced.

A fair amount of time was spent examining these problems, but as no error messages were ever produced and as the problems occurred randomly they could not be re-produced. Also, I am aware of other people developing UPnP devices with the Siemens stack who have reported similar experiences. Therefore it is believed that the problem lies in the Siemens UPnP stack itself.

At the very beginning of this project the initial devices were created using the older version of the UPnP stack, as used on the mDorm. During the course of development a newer version of the stack was released and this seems to be much more reliable, although problems do still occur from time to time.

6.7.2. SNAP Reliability

Although the SNAP has more processing power and much memory than the TINI, it is only just able to run two embedded UPnP devices. Any more than this and the SNAP crashes due to lack of memory. In fact memory issues are still a problem with just two devices. During development it was found that the SNAP would crash if it was heavily accessed by UPnP control points. The problem appears to be that the SNAP doesn’t invoke the Java Garbage Collector regularly enough to free up memory to process all the requests. As such the memory runs out and the SNAP crashes. A temporary solution has been to include a thread that regularly checks the amount of free memory and if it falls below about 100k then it manually invokes the garbage collector.

Earlier versions of the SNAP firmware were found to be very unreliable, with UPnP devices lasting no more than 10-20 minutes before the board crashed. Newer versions are much more stable but still exhibit problems.

7. Project Management

7.1. Work Plan

Appendix F contains the initial Gantt chart drawn up at the start of the project as well as the actual Gantt chart. It is clear from these two charts that certain tasks differed in the amount of time expected for completion. Also some tasks were delayed and some started earlier. The idea for the project had come during the summer, before the start of term. This and some similar work carried out as part of a student placement with BT Exact allowed for work to commence immediately at the start of term.

The simple UPnP devices were created within three weeks, however these devices did not contain any identification service or rule association service. Work on the Virtual Appliance Management Application commenced earlier than planned because of the lack of familiarity with XML, XSL and Apache Cocoon. The initial version of the management application focused on creating the UPnP control point and getting it to discover and maintain a record of devices on the network and then outputting this as an XML document. XSL style sheets were then created for different client devices.

Work on the association service used to handle rules on the individual UPnP devices started later than planned because of the research required to identify the best solution, however the implementation still took the estimated time of six weeks. During this time work on the management application continued.

Work on the XML and XSL documents for the management application took longer than expected as each set of documents were created when required by the management application. Initial versions of the management application simply returned a list of devices, and so XML documents for listing virtual appliances were not designed until later on. Most of the documents contain the same information about devices and so the actual design of the individual documents did not take that long. The XSL style sheets took longer than expected because of the complexity of some of the HTML and JavaScript code required to create parts of the user interface.

As work on the simple UPnP devices has been finished relatively quickly, more complex devices as well as devices based around a SNAP board were then created. As this was a further objective it was not put on the initial project plan as they were only to be created if everything else had been completed or was on target.

7.2. Methodology

Incremental prototyping was chosen as the software process for this project because, unlike the Waterfall model, does not demand that the customer commit to set of requirements before design begins, and it also allows functionality to be added in stages. This process is also well suited to this project because of the nature of the project being a concept demonstrator rather than a complete deliverable system.

As can be seen from the work plans and project diary (in the next section) the basic UPnP devices were written first. At a latter stage the Identification service was implemented and then finally the device association service. The management application was also designed in a similar manner with extra functionality being added once the previous build was proven to be correct. The XSL style sheets were also designed and written in stages with the basic ones for the device list being created first and the more complex one for rule creation being created later.

7.3. Project Diary

Omitted from this version because of space considerations, however it is available in the original PDF version of this report.

7.4. Evaluation of Project Management

The work flow chart drawn up the beginning of the project proved to be very useful in keeping the project on track as it would have been very easy to get carried away with particular parts of the system and run out of time whilst working on others. Despite the rather large difference between the initial and actual Gantt charts the main objectives of the project were completed well within time which allowed the further objectives to also be completed.

The use of the incremental prototyping process was also useful as it allowed the basic devices to be written first with more functionality being added latter. The same applies to the management application and the XSL stylesheets.

8. Testing and Evaluation

8.1. Testing

8.1.1. Introduction

The system consists of a large number of components; individual UPnP devices as well as the management servlet and the XSL stylesheets for Cocoon. A number of the UPnP devices also share common services such as the Identification and Association services. Each of these components must be tested in isolation against pre-defined test cases. Once each component has been tested and any bugs fixed the system should be tested again to ensure the bug fixes didn’t themselves introduce any new defects. Once all the components have been successfully tested the system can be tested as a whole using integration testing. During all testing procedures the components as well as the overall system will be treated as a blackbox (functional testing).

Also, as this project is demonstrating a new concept user feedback is very important. This feedback can be used to gauge the usefulness of the concept and what changes would need to be made if this concept were to be developed further.

8.1.2. Component Testing

As described above each UPnP device will be individually tested using component testing and treated as a black-box. The results of the component test are shown in Appendix E. Some devices share common services and in these instances the service will only been tested once.

8.1.3. Integration Testing & User Feedback

Once the individual UPnP devices have been tested the overall system can then be tested. This involves running numerous UPnP devices and then creating and managing Virtual Appliances through the user interface using a PC and PDA. As well as testing the system for defects a number of people will be asked to perform various tasks and asked to give their feedback on the system.

8.2. Evaluation

For this project a number of UPnP devices, both simulated and real, have been developed. Some of these devices are relatively simple, such as the switch and light bulb, and some are simulations of more complex appliances such as the Internet Radio and Audio/Video appliance. All the program code has been written using Java which allows the devices to run on both Windows and Linux. Even the UPnP mDorm device that runs on the SNAP board is written in Java and if it were not for access to specific hardware sensors, the same code could run on a PC without modification.

The use of the Siemens Java UPnP Stack provided a platform independent mechanism for automatic service discovery and utilisation. As with Jini, because the Java version of the UPnP stack was used no provision is made for automatic network configuration. Instead it is assumed that the device itself will be able to configure its network interface. In terms of PCs, the operating system can be configured to use a DHCP server, or to use statically assigned IP addresses. If Windows is configured to use a DHCP server and one is not present then it will automatically use link-local addressing, the same is probably true of Linux as well. However the SNAP board must either be assigned a static IP address manually, or use a DHCP server. It is important to note though that the UPnP specification places no requirements on their being any kind of network infrastructure already in place.

The system was designed to be resilient against temporary failure of devices. For example, if a UPnP switch and light bulb are associated, then if, say, the switch is removed from the network and then started with a different IP address the light bulb will detect this and re-subscribe to the switch. This will work provided the switch announces to the network that it is going offline. If it doesn’t then when it comes back online the light bulb will have no idea the switch disappeared and will still believe it is subscribed. To resolve this the device would have to send a "bye-bye" message when it starts up and before it announces its presence.

Another requirement of the system was it be as decentralised as possible. This has been achieved by storing the rules used to build Virtual Appliances on the actual devices rather than on a central server. Devices then subscribe to the services required by the rules and receive event notifications when evented state variables are updated. The state change is then checked against all the rules in the devices rule base and the associated action of matching rules is fired.

A user interface provides a way for users to create and manage the virtual appliances. The user interface meets the requirements listed in Section 3.1 by providing a list of devices currently on the network, technical details for each device, a list of the virtual appliances created and the rule they are made up of, and a mechanism for the user to create and edit virtual appliances. The interface has also been designed in such a way that it is automatically tailored to the display capabilities of the client. Currently PCs and PDAs are supported. Support for mobile phones was not implemented because the size of the display would make it extremely difficult to show the required information for the user to manage the virtual appliances in a user-friendly manner.

8.2.1. User Feedback

Although the system has been proven to work and met the requirements listed in Section 3, the usefulness of the Virtual Appliances still needs to be determined. In order to determine this usefulness and receive general feedback on what users thought of the system a number of people were asked to play with the system and give their comments.

Whilst in a commercial environment the capturing of user feedback would involve the use of formal methods and a large number of subjects, the resource limitations and time constraints imposed on this project have lead to a more limited evaluation. However, from the user feedback given below it is clear that even a small-scale evaluation can be helpful.

The user feedback obtained is shown below.

The pages where you select the input and output devices for constructing rules may get confusing if lots of devices are present. Would it be possible to show a list of devices that are better suited for linking with the previous device?

With the device identification it would be good to have a list of previously used locations and possibly a pre-defined list otherwise one person may say a device is located in a lounge, and another may say it is located in the living room. This would then enable the user to sort devices by their location in the situation where lots of devices are present.

The rules used are simple but do work well. Maybe the next version will use Boolean logic (although it gets difficult to design). You might even end up writing your own language to define rules!

Getting normal people to create the rules will always be problem.

Virtual appliance "templates" could be used to allow a number of basic appliances, such an alarm clock, to be constructed. An alarm clock typically consists of a clock service and a device that can make a noise. So a user could choose to create an alarm clock and all they have to do is select the time and where the noise should be made. The interface then automatically generates the rules and locates an available clock service.

Love the idea of distributing the rules, how about caching the rules elsewhere for backup and protection against failure? You could have a number of Rule Proxies that keep copies of all the rules on the network for backup so they not actually fired, but if a device forgets its rules they can be automatically re-sent back to the device from the cache.

You could do with more "real" UPnP devices. How about wrapping some X10 devices in UPnP?

9. Conclusion

9.1. Summary of Main Achievements

This project has succeeded in demonstrating the concept of creating and managing Virtual Appliances. It has shown the concept of de-composing modern-day appliances, the concept of service discovery, and the concept of re-composition to create new virtual appliances.

One of the main achievements of the system is the distribution of rules. The distributed nature of the system appears to be fairly unique as most other systems take a more centralised approach, such as the iDorm.

The user interface is also another main achievement in terms of how the interface is adapted to the display capabilities of the client. The use of XSL to transform the XML allows new stylesheets to be created for new devices without any modification to the management servlet. XSL also allows XML documents to be transformed into other types of files and documents, such as SpeechML which would be suitable for blind users. Special versions of the interface could be made for partially sighted users where large fonts and highly contrasting colours are used.

Another feature of the user interface is the context-sensitivity of the options used in creating rules. When creating rules the user has to pick the devices, services, state variables and actions. Once the input and output devices are selected the services, state variables and actions are selected through drop down menus. As different services are selected the drop down menus containing state variables and actions are updated. Inappropriate state variables and actions are not shown in an effort to aid the user in designing the rule.

9.2. Extensions and Further Work

Because of time limitations difficult decisions had to be made about which ideas to implement and how much time should be spent on them. However, the priorities and choices made in this project have allowed a basic demonstration of the concept to be created. Whilst this project has successfully demonstrated the concept of de-composing and re-composing appliances to build virtual appliances there are a number of extensions and further work that could be carried out.

One important extension would be to re-design the rules used to associate devices. The current rules were kept fairly basic to ease parsing on low-spec hardware and to keep the user interface as simple as possible for creating these rules. However these rules, while allowing a large number of virtual appliances to be constructed, were also quite limiting. For example, there is currently no ELSE clause, and Boolean operators such as AND and OR are not implemented. Adding these features would then allow rules such as IF light_level < 30 AND motion = 1 THEN light.power = on ELSE light.power = off to be created, which are currently impossible.

With these improved and more complex rules the design of the user interface, through which the user actually creates the rules, would have to be carefully designed in order to be as user-friendly as possible and display properly on a range of devices. The idea of providing templates for virtual appliances was mentioned in user feedback and could prove an effective way of aiding users in creating basic virtual appliances without being exposing them to the underlying rules. An important consideration when re-designing the user interface would be to not constrain the user in any way in terms of the virtual appliances they can build, but whilst ensuring that they can only create valid configurations. The whole concept of virtual appliances is about empowering the user to associate devices in ways the designers themselves may not even have thought of.

The system implemented here does not currently have a notion of self-healing, although it is resilient to temporary device failure. Further extensions should allow a virtual appliance to automatically adapt to use the same service provided by a different device when one it is currently using disappears. This implies some form of heart-beat to determine when a device has gone offline. Currently the only way to detect whether a device goes offline is if it announces to the network that it is leaving, or when its advertisement expires. These leases are typically 30 minutes long. Also, as mentioned previously, if a device goes offline without announcing the fact, and then comes back online before its lease would expire, subscribed devices will be unaware of the outage and still believe they are subscribed. In some situations though, self-healing may be difficult such as when a required light disappears. However, with something like a timer service the location of that service is unimportant.

Another aspect to this self-healing and resilience to failure is that of backing up rules, as mentioned in the user feedback. A scenario where this would be required is where a device fails and has to be replaced. This new device would not only have a different network ID, but also have no knowledge of the rules used by its predecessor. In this situation the system should detect the new device and send a copy if the rules to the device so that it can immediately take over the role of the previous device without any user interaction.

Also, the issues of security, access control and resource allocation have not been addressed in this project. The next version of UPnP, currently being drafted, is expected to address security and access control issues. In the current system it is quite possible to accidentally (or deliberately) create two or more virtual appliances to try and access a single device at the same time, for example a timer or light. This also leads on to detection of rule conflicts, which is made all the more difficult by the use of a distributed rule set rather than having all the rules stored in one place. Also, different classes of rules and appliances could be defined, such as safety, efficiency and comfort. Each of these classes then has a priority and, for example, a rule or virtual appliance could then not be added to the system if it compromises safety.

One important finding during the development of the UPnP mDorm device was that although the SNAP is designed for constructing sensor networks, it is sadly not quite powerful enough to run UPnP. Use of a MiniITX, or the even newer NanoITX, system may be a better option for constructing UPnP enabled sensor networks. Another observations is that although Cocoon provided a very good mechanism for automatically generating a user interface based upon client’s display capabilities, it is probably a bit to heavy-weight for the requirements of this project, although its use here meant that an alternative solution did not have to be developed.

9.3. The Future…

The long-term goal of this vision is that of ambient intelligence in environments so that they can respond to the needs and desires of occupants. However to achieve this computing and networking technology must first disappear into everyday artefacts around the home. This project has attempted to lay the technological groundwork for such an environment.

10. References and Bibliography

10.1. References

Figure 1: Image of VCR
Accessed: 2nd November 2003

Figure 2: The iDorm
Accessed: 2nd March 2004

Figure 3: The networks used in the iDorm
Accessed: 2nd March 2004 CCGrid 2002.pdf

Figure 4: UPnP in the iDorm
Accessed: 6th March 2004 UPnP.wmv

Figure 5: The IBM Meta Pad handheld with touch-screen next to a Meta Pad core.
Accessed: 13th March 2004

Figure 6: Image of TINI board
Accessed: 24th February 2004

Figure 7: iButton
Accessed: 24th February 2004

Figure 8: Image of SNAP board
Accessed: 5th November 2003

Figure 9: The Cjip microprocessor
Accessed: 24th February 2004

Figure 10: A PC/104 stack
Accessed: 24th February 2004

Figure 11: VIA EPIA M10000 Mini-ITX Motherboard
Accessed: 24th February 2004

Figure 12: UPnP devices in the digital home
Accessed: 25th February 2004

Figure 15: The Salutation architecture
Accessed: 26th February 2004

Figure 16: The use of Service and Description Records
Accessed: 26th February 2004

[1]  EEE111A/B Microprocessors
       Accessed: 23rd February 2004

[2]  Smart Environments booklet
       Accessed: 2nd March 2004

[3]  AutoHAN Core Services White Paper One
       Accessed: 2nd March 2004

[4]  AutoHAN Project Proposal
       Accessed: 2nd March 2004

[5]  TINI: Introducing TINI
       Accessed: 24th February 2004

[6]  Application Note 195 DSTINI1 (TINIm390) Verification Module Chipset Reference Design
       Accessed: 24th February 2004

[7]  iButton: 1-Wire Weather Station
       Accessed: 24th February 2004

[8]  SNAP: Simple Network Application Platform
       Accessed: 24th February 2004

[9]  Imsys: The Cjip Processor
       Accessed: 24th February 2004

[10] PC/104 Embedded Systems FAQ
         Accessed: 24th February 2004

[11] PC104.COM – What is PC104?
         Accessed: 24th February 2004

[12] – faq
         Accessed: 24th February 2004

[13] Technology Brief – Mac OS X: Rendezvous
         Accessed: 25th February 2004

[14] UPnP Forum
         Accessed: 25th February 2004

[15] Intel Corporation – UPnP Technology Overview
         Accessed: 25th February 2004

[16] UPnP – The Foundation of the Digital Home
         Accessed: 25th February 2004

[17] Salutation – Frequently Asked Questions
         Accessed: 26th February 2004

[18] Salutation Specification V2.0c Part 1
         Accessed: 26th February 2004

[19] Jini Technology Architectural Overview
         Accessed: 26th February 2004

[20] CC464 – Pervasive Computing and Ambient Intelligence
         Accessed: 6th March 2004

[21] Java MP3 Player
         Accessed: 7th March 2004

[22] Antelope Technologies – Vision for Modular Computing
         Accessed: 13th March 2004

[23] IBM Think Research – The Amazing Shrinking Computer
         Accessed: 13th March 2004

[24] A. Pounds-Cornish, A. Holmes (2002), The iDorm – a Practical Deployment of Grid Technology,
         In 2nd IEEE International Symposium on Cluster Computing and the Grid (CCGrid2002)

10.2. Bibliography


Omitted from this version because of space considerations, however it is available in the original PDF version of this report.