ECT overview

Created by Stefan Rennick Egglestone 2005-12-05
Last update by Stefan Rennick Egglestone 2006-06-29

What is ubiquitous computing?
Graphical user interfaces


ECT is an piece of software which aims to support the rapid deployment of ubiquitous computing experiences. This document explains our motiviation for developing ECT, introduces some of the concepts that you will need to understand in order to use it, and describes some of the useful features that ECT provides.

What is ubiquitous computing?

Ubiquitous computing (ubicomp) is a broad field of research, which involves investigations into the integration of computational devices into the environment. A short introduction to ubicomp can be found here, and a longer introduction can be found here. Ubicomp is also sometimes called pervasive computing. Installations of ubicomp devices in non-research settings (eg in museums, people's homes etc) are sometimes called ubiquitous computing experiences.


The development of ECT has been motivated by previous work involving the construction of ubiquitous computing experiences undertaken as part of the ACCORD project and the EQUATOR Interdisplinary Research Collaboration (IRC). Work in ACCORD focussed on the construction of domestic ubicomp experience, and ongoing work in EQUATOR has focussed on themes such as Playing and Learning, Citywide Performance and Digital Care.

Although the ubicomp experiences constructed as part of these activities have been very different, a common theme that has emerged from all of them is that the construction of experiences is difficult and time-consuming to get right. Some common problems that have been encountered include:

ECT has been developed as a result of the experiences that have been gained in solving these particular problems in the activities listed above. ECT allows:

As such, the ECT package is a combination of

ECT is currently provided with over 80 components, which allow it to communicate with a wide range of physical devices.


This section introduces some of the concepts necessary to understand and use ECT.


ECT uses the term component to refer to an item of software running on a particular computer which can be used to control a particular device. For a piece of software to be usable as a component in ECT, it must conform to certain requirements (although there will be many existing items of software that already conform to these requirements and that will therefore be directly usable in ECT without modification). ECT is supplied with a large number of components to allow interactions with popular ubicomp devices, and many of these components are listed in component documentation provided on this web-site (for example, see the Categorised components list).

It should be noted that, in addition to the components supplied with ECT that can be used to control hardware devices, ECT is also supplied with a number of software-only components that can be used to perform processing operations. For example, Dynamic BeanShell is a component that allows scripts written in the BeanShell language to be used in the ECT environment.

Component properties

All components define named properties, which can be used to control their operation, and as a result the operation of any hardware device with which they may commmunicate. For example, the Camera component, which can be used to take a picture using a webcam, defines the following properties:

Users control components by providing values to properties. In this case, a user who wishes to use this component with a webcam must first locate the ID of the camera they wish to use (see the Camera component online docs for information about how this ID can be determined). This ID must then be provided to the component through its configCaptureDevice property. On receipt of this ID, the component will attempt to connect to the camera that this specifies. After the component has connected, a user must trigger the camera to take a picture by providing a value to the triggerImageCapture property. This will cause the software component to communicate with the camera and request it to record an image. When this has occured, the component will then place the URL of this image onto the imageLocation property. This URL might then be used by other components (for example, the Simple Media Viewer component can be used to view the image that can be found at this URL).

Note that the names of some of the properties on the Camera component are examples of property names that follow certain conventions (you will also find these conventions regularly used in other ECT components):


In general a component which communicates with a particular device will run on the computer to which the device is attached, and may require the installation of various items of driver software on that machine for its operation (requirements for driver installation are documented by each component - for an example, see the PhidgetInterfaceKit component).

However, in general, properties defined by a ECT component running on one computer are controllable using ECT from another computer, as long as this computer is connected over a network and is also running ECT. To allow components to be controlled in this way, ECT has the concept of a container, which is an item of software which runs on a computer, and which manages the components running on that machine.

A container must be installed onto every machine on which components should run. When a container is started up, it will

Once other machines on the network have seen a component advert (known in ECT as a capability) they can The container is then responsible for manipulating components to fulfill these requests.

Note for developers - ECT is currently supplied with a container written in Java, which is capable of hosting components which are defined as JavaBeans. Properties of a supplied bean are then interpretted by ECT as being properties of the component. See ECT Developer documentation for more information.

Specifying complex behaviour

Although components provided with ECT can simplify the process of setting up software that can control ubicomp devices, setting up a ubicomp experience is likely to involve much more work than just installing ECT on a cluster of machines, attaching devices to machines, installing drivers for devices, and configuring components that can communicate with these devices. Designers are likely to wish to specify much more complex behaviours in theirs systems than can be provided using this process alone.

The primary mechanism in ECT for the specification of behaviour involves the creation of connections between properties on different components. Connections can be established between components, even when they are hosted in containers running on different machines. If a connection exists between two properties, and if one of these properties is set to a new value, then ECT will propogate this new value to any other connected properties. Note that new values might be supplied by either users or by the component to which the property belongs.

A simple example of this connection mechanism might involve two components - a Camera component and a Simple Media Viewer component. If a connection is created between the imageLocation property of the Camera components, and between the browserURL property of a Simple Media Viewer component, then every time the Camera component triggers its attached device to take a picture, the URL where this picture can be found will be placed on the imageLocation property, and will get propogated along the connection to the Simple Media Viewer browserURL property. This will cause the picture at that URL to appear in a browser window maintained by the Simple Media Viewer component. This browser window can easily be on a different machine to the one to which the camera device is attached.

Of course, there are limitations to the complexity of behaviour that can be specified by this property connection mechanism. Adding connections between components representing hardware devices is useful in the creation of reactive systems (eg ones in which the principal behaviour of the system involves a number of events causing a number of actions). However, it is not sufficient to create systems which exhibit data processing functionality. In ECT at present, data processing functionality can be added through the addition of software-only components. These are components which are still controlled through the modification of property values, and which can therefore be connected to components representing hardware devices, but which themselves do not connect to any hardware device. Instead, they may provide useful data storage or processing functionality.

ECT is currently provided with a wide range of software-only components, which have been developed to add behavioural features to existing installations. Examples of software-only components include


The combination of

is referred to within ECT as an installation. An installation is just another term for a ubicomp experience that has been created using ECT.

ECT provides functionality to manage multiple installations. Computers running ECT can be involved in multiple installations at once, and users can switch between different installations that have been created at different times. This process works as follows:

Note that it is of course possible to run ECT on just one computer (rather than on all computers in a cluster) and if an installation is created on this computer, then this computer will automatically be the master computer for the installation.

Graphical user interfaces

The first part of this document has described core concepts and entities in ECT, including components, component properties, containers, connections and installations. The rest of this documentent briefly introduces the different types of graphical user interface (GUI) functionality which are provided with ECT to manipulate these entities.

Different types of GUI functionality have been provided with ECT which are targetted at the needs of different categories of users. Types of functionality currently include:

The graph editor and capability browser

The combination of the graph editor and capability browser is currently the most commonly used interface to ECT, and as such is also the most well-developed and bug-free. This section gives a brief overview of the functionality of this interface - for much more detail, including a number of screenshots of these interfaces - follow the Learning to use ECT tutorial.

The capability browser is a window that displays views of all components that are available in any container which has been attached to a particular ECT installation. It allows users to view any documentation defined by a particular component, request that an instance of a component be created, and to request that existing instances of components be deleted.

Once a component instance has been created through the capability browser, it will appear in the graph editor. This allows users to view the properties defined by a component, modify any values they may have, and to establish connections between properties. As properties on components change (for example, when caused by someone providing an input using a hardware device) then these property changes appear on the graph editor, and if a user uses the capability browser to delete a component instance, it will disappear from the graph editor.

Display editor (experimental)

The display editor is currently an experimental piece of software, which is intended for use by users that are less computer-literate than those that may wish to use the graph editor. It has been optimised for use through a touch-screen interface. For a tutorial about using the display editor in combination with the graph editor, read Using the display editor.

Physical configuration editor (experimental)

The physical configuration editor is another experimental piece of software. It allows logical statements and inferences to be made about a ubicomp system. More information about the display editor will appear on this web-site soon.

Scripter application (experimental)

This is an application that allows scripts to be developed that can control complex components. As such, scripting is an alternative mechanism for the specification of complex behaviour in a ubicomp system than the construction of graphs. For an introduction to using the scripter, please read Using the scripter