http://www.spinellis.gr/pubs/jrnl/2003-PUC-ifurnace/html/furnace.html
This is an HTML rendering of a working paper draft that led to a publication. The publication should always be cited in preference to this draft using the following reference:

Citation(s): 57 (Google Scholar), 30 (selected).

This document is also available in PDF format.

The final publication is available at Springer via doi:10.1007/s00779-002-0213-8.

The document's metadata is available in BibTeX format.

This material is presented to ensure timely dissemination of scholarly and technical work. Copyright and all rights therein are retained by authors or by other copyright holders. All persons copying this information are expected to adhere to the terms and constraints invoked by each author's copyright. In most cases, these works may not be reposted without the explicit permission of the copyright holder.

Diomidis Spinellis Publications

The Information Furnace: Consolidated Home Control

Diomidis D. Spinellis
Department Management Science and Technology
Athens University of Economics and Business
Patision 76, GR-104 34 Athens, Greece
email: dds@aueb.gr

Abstract

The Information Furnace is a basement-installed PC-type device that integrates existing consumer home-control, infotainment, security, and communication technologies to transparently provide accessible and value-added services. A modern home contains a large number of sophisticated devices and technologies. Access to these devices is currently provided through a wide variety of disparate interfaces. As a result, end-users face a bewildering array of confusing user-interfaces, access modes, and affordances. In addition, as most devices function in isolation, important opportunities to exploit synergies between their functionalities are lost. The information furnace distributes data, provides services, and controls an apartment's digital devices. Emphasis is placed on accessibility and on exploiting the synergies that inevitably come up when these technologies and services are housed under a single roof. The prototype implementation I outline integrates on a FreeBSD server the distribution of MP3-encoded music to DNARD/NetBSD thin clients, an answering machine, a burglar alarm, an Internet router, a fax server, a backup server, and intelligent control of a PBX.

Keywords: Home-control, automation, multi-modal interfaces

1  Introduction

Although our complex lives are not necessarily improved by each new technological widget we adopt, uncooperative devices and appliances with deficient user-interfaces can certainly conspire to frustrate us. Over the past three years I have experimented with a number of technologies that gave birth to the information furnace concept: a basement-installed PC-type device that integrates existing consumer home-control, infotainment, security, and communication technologies to transparently provide ubiquitous access and synergistic value-added services. In the following sections we will examine the devices and appliances lurking in the modern home, overview the problems associated with the current breed of devices, and go over the basic elements of the information furnace concept and its prototype implementation. Further implementation details on technologies behind the system we describe can be found in [1]; this paper focuses on the system's concept, architecture, and evaluation.

2  The Modern Home

A modern home contains a large number of sophisticated devices and technologies. Current and near future technologies and respective devices can be roughly categorised into the categories of home control, infotainment, security, communication, and special-purpose devices.

2.1  Home Control

Contemporary central heating systems are regulated by one external and a number of internal temperature sensors in conjunction with a control unit occupants use to set the desired room temperature. The system compares the internal room temperature to the setting of the control unit and, using the external temperature as a compensating factor, regulates the temperature of the water produced by the local heat-generating plant or the valve bringing remotely-heated water into the home. Burners often have their own control circuits based on target temperatures for the burner and the circulating pump, but we can regard them as a black box for the purposes of this article. Convenience elements associated with control units involve the ability to maintain different temperature settings for day and night, manually set the system to day, night, or absence mode, keep a weekly schedule of automatic switchovers between these modes, and switch-off for the prescribed duration of a trip.

Instead of a burner, some systems are based on a heat pump and air circulation. They are controlled by the same principles, but can also lower the building's temperature during hot days. Split-type wall-mounted room air conditioners feature an integrated opaque control circuit adjusted individually through a remote control.

The provision of hot running water to the bathrooms and kitchen is often controlled together with the central heating system. The added complications this brings into the picture involve the possibility of heating the water on sunny days through a solar panel, an electrical heater used as a backup measure, a circulating pump to pass water through the solar panel, and a second pump to bring hot water near the taps. The first pump operates through a thermostat comparing the temperature difference between the hot water storage tank and the solar panel; we can again regard the system as a black box that absorbs solar energy. The operation of the second pump is more tricky: its intention is to save water by bringing the hot water close to the taps. When the central heating system is operating, having a secondary warm water circulating circuit in the house does not hurt; the floors and walls where the running hot water pipes run act as secondary radiators. When however the central heating is switched off (on warm days or during an absence) the circulator actually cools the stored warm water by continuously running it through the house. In my experience modern heating controllers do not deal with this complication.

The natural light entering a building is often controlled through external blinds or stores. These also play an important role in regulating the heat flowing into or out of the building. In addition, a heliostat device can be used to track the sun movement and actively reflect sunlight into the building. Artificial lighting can be electronically controlled through a system such as X10 or LonWorks in the United States and the European Installation Bus (EIB) in Europe. Perversely, in the case of the EIB at least, it is currently cheaper to control lights using 230V switches and individual switch-to-appliance power-carrying cables than to use a signal and power bus, cheaper control switches, and the associated electronics. This is clearly a case where the silicon economy has not yet done its work. Other interesting elements of modern artificial lighting include light fixtures with integrated motion and light detectors that are increasingly used outside homes as burglar deterrents, time switches used for the same purpose inside the house, and ``economy''-type light bulbs that may take up to five minutes to reach their rated light output.

A case where the silicon economy has worked is exemplified by the availability of affordable devices to control plant and garden watering. These often sport a bewildering array of daily and weekly watering programs (apart from the one you really require, that is), can be directly fitted into a watering hose, or can control multiple valves, and can receive additional feedback from a soil humidity sensor.

2.2  Infotainment

The array of devices used for servicing our entertainment, and, supposedly, our information access needs (covering the so-called ``infotainment'' category) is bewildering. It involves CD, MP3, and DVD players, radios, the (increasingly digital and interactive [2]) television, tape or hard-disk based video recorders, digital photograph and video cameras, game consoles, and networked personal computers. Across those devices we typically witness a gratuitous duplication of functionality, and a lack of standardisation; both are exemplified by the growing array of remote controls adorning the typical lounge table. The last problem has spurned research [3] and development of universal, configurable remote controls.

2.3  Security

Home owners not wishing to trust their security of the prized possessions I outlined in the previous paragraph to the watchful eye of the local cop or a bona fide man-eating animal often end-up contributing to the bottom line of the burglar alarm and home monitoring industry. A modern burglar alarm consists of a control unit, an array of sensors, and facilities for alerting whomsoever the owner can afford. The sensors used include motion detectors based on passive infrared (PIR), microwave, or hybrid technologies, magnetic contacts that detect the opening of doors and windows, and glass vibration sensors. Sensors placed under mats and carpets, and light beam detectors are less often used. Contrary to the popular perception promoted by Hollywood films, visible red intersecting laser beams used to test a burglar's agility are not a popular sensor option.

The control unit is typically an overpriced, and underpowered microprocessor-controlled contraption. It monitors the sensors (due to a dearth of input ports these are often or-wired into ``zones''), allows the owners to activate and deactivate it using a PIN, distinguishes between a normal entry (e.g. through a door) that provides a delay for deactivating the system and an unexpected event (e.g. motion, entry through a window) that immediately triggers an alarm, offers a facility for operating with the occupants inside the house (``night mode''), and controls the alarm triggering and rearming process. Alarms in most cases sound an internal siren that is supposed to frighten the burglars (but will in most cases only frighten the poor owners when set-off in a ``night-mode'' operation), activate an external siren-often coupled with a strobe light-that passers-by typically try to ignore, and notify via a modem or a recorded message a control centre or a list of pre-assigned phone numbers.

The whole system has some redundancy and self-monitoring capabilities. Many sensors and sirens are equipped with a normally-closed ``tamper'' switch; opening the device's cover, or cutting its connecting wire will be immediately registered by the alarm unit. The control unit is equipped with a battery which supplies power during a power failure. In addition, many outdoor sirens come with their own battery and are wired for stand-alone operation: if the power supplied by the control unit is interrupted or the siren's tamper switch is activated the siren will begin to sound. Some systems are also installed with wall mounted panic buttons or similar signalling tokens that an individual can wear. These are also useful when elderly or disabled people wish to signal they need attention. Some owners also combine their unit with fire-detection sensors; however, fire-detection equipment installed to satisfy building regulations falls outside the scope of this article.

Related to security are also the door phone (and sometimes a TV camera), the associated door opener, and the remote-controlled garage door opener. Note that the typical door phone and opener combination is an system cunningly designed to minimise the number of individual cables required for its installation. Interfacing with such a system can be very difficult; however many small private branch exchanges (PBXs) offer a door phone / door opening option and can be easier to interface.

2.4  Communication

The modern home's communication needs are served by the phone and an Internet connection using the ``plain old telephone system'' (POTS) and a modem, the integrated services digital network (ISDN) and a terminal adaptor, or another digital network technology, e.g. a digital subscriber line (DSL) and the associated terminator box. Sharing of phone lines and internal communication can be facilitated via a PBX, while the corresponding sharing of data connections can be facilitated by a network and hub (or wireless network) and a router. PCs are also increasingly used to share network collections. Phone lines are often terminated on an answering machine and a fax; the more exotic ISDN offerings trumpeted by the incumbent telecom providers (videophones, digital faxes) have been persistently snubbed by consumers. Connected to the data lines are PCs, holding valuable personal data and in dire need of regularly scheduled backups, and connected to the PC are various personal digital assistants (PDAs) holding the owner's telephone number directory and other personal data. A baby monitor typically functions independently of the above setup. A variety of wired and wireless home networking technologies aim at interconnecting the systems I described [4].

2.5  Special-purpose Devices

Finally, inside a modern home there is a number of electronically controlled special-purpose devices. These include the humble vacuum cleaner, the microprocessor engineer show-off case microwave oven, and the increasingly clever refrigerator, oven, washing machine, drier, and coffee machine [5]. Unfortunately for this article's author and probably fortunately for their other users, none of these devices offers a viable interface for controlling their operation.

3  Modern Problems

The coexistence of the devices and systems I described in the previous section under the same roof is a sad story of unattained potential, lost opportunities, and waste.

3.1  User Interface

The most important problem inflicting the systems is their often dysfunctional (to put it politely) user interface. The reason behind this problem stems from the restricted human interaction devices the systems have at their disposal. In most cases interaction devices consist of small numerical liquid crystal displays (LCDs) (sometimes capable of displaying some additional hieroglyphic symbols), and a few domain-specific buttons.

The usability aspects of consumer electronic products [6] and even their design principles [7] differ from those of workstation-based software. However, given the increasing similarities and interactions between products in the two categories, it is instructive to examine the usability of home appliances through accepted user interface design principles. The appliances I described rarely follow the principles of a user-centred design [8]. It is thus difficult to determine what actions are possible at any moment, the system's conceptual model and current state are hidden from the user, and there are no natural mappings between a user's intentions, the required actions, and the resulting effect. Similarly, many of the user interface design Golden Rules [9] are never followed: interfaces are inconsistent, require tedious sequences of data entry, and often lack shortcuts, informative feedback, and the ability to reverse actions. Other important user-interface problems include non-intuitive interaction sequences, the operation in various different ``modes'' [10], the overloading of buttons for different purposes, cryptic display messages, lack of localisation and accessibility for disabled people, and a non-ergonomic design.

Appreciating that I might be accused of shooting a lame duck, I illustrate these points with three representative examples.

Programming a Heating Controller

Figure 1: A heating controller and its programming interface.

The room unit in question allows programming a weekly schedule for the controller's operation. Programming is performed by opening the room unit access panel to reveal a numerical menu and switching between its 17 different modes (see Figure 1). The following excerpt from the operation manual outlines the weekly programming procedure [11]:

``With the heating program, you can predetermine the temperature switchover times for one week. The weekly program consists of seven 24-hour programs. One 24-hour program may include up to three heating periods each of which is defined by a start and an end time. If you do not require a certain heating period, you need to enter the same time of day as start and end time.''

4
Select the required day for the heating period (1 = Monday / 7 = Sunday)
5
Start of heating period 1: nominal operation
6
End of heating period 1: reduced operation
7
Start of heating period 2: nominal operation
8
End of heating period 2: reduced operation
9
Start of heating period 3: nominal operation
10
End of heating period 3: reduced operation''

Operating a Digital Answerer

The state of this particular digital answerer [12] is indicated by a single ``messages indicator'' light. Its behaviour is to be interpreted as follows [12]:

On
Answerer is on and there are no messages.
Flashing
Number of flashes indicates number of messages.
Off
Answerer is off, but there might still be messages.
Flashing rapidly
Outgoing announcement is invalid or memory is full.

For remotely accessing the messages the device's owner is provided with a paper cut out ``remote access card' that lists the eleven different commands (five are to be used during message playback and six at all other times) the answering machine supports.

Programming a PBX

The low end PBX we examine [13] can be programmed from a dual tone multifrequency (DTMF) phone connected to the extension 21 (only). The PBX allows the specification of different extension ringing patterns for day and night use. To specify the day or night starting time the following procedure has to be followed [13]:

The examples we have seen, illustrate that in many cases the user interface of consumer-oriented home appliances and control devices is far from ideal. Clearly human interface studies and approaches towards better interaction paradigms [14,15] have not yet found their way into widespread practice.

3.2  Lacking Functionality

One other problem with the devices we examined is that for a number of reasons they may impose arbitrary limits on their functionality, or lack support for useful functions. For many devices the available CPU power, RAM, or ROM are just not sufficient for implementing a given function. For others, the already complicated user interface would crumble under the requirements of the added functionality.

As an example, there is no reason why the heating controller I described should support only three heating periods per day, or not allow one to provide a schedule for the temperature of the running hot water as well as the temperature of the room. Similarly, a CD player may offer a facility to skip a boring track, but will not remember to skip the same track in the future. On another front, a burglar alarm unit could provide a precise report of the alarm triggering circumstances, and allow its user to remotely probe and disable individual sensors. Finally, the PBX we examined could be more versatile if it supported different day and night mode start times for different days of the week.

A general lack of functionality witnessed in all the devices we examined is a facility to backup and restore the tediously entered program data. True, many devices have a power-backup system for their memory contents, but, in my experience, that inevitably one day will fail-typically long after the user has forgotten how to program the device and has lost the respective user manual.

3.3  Lost Synergies

I will fully expand the synergies made possible when all home systems communicate and cooperate with each other in Section 4.3; at this point I will illustrate my thesis with a simple example. The ``blinking clock syndrome'' refers to the myriads of device clocks flashing ``12:00'' all over our planet. Even in households where these are correctly set after a power failure, twice a year they need to be re-adjusted following the daylight savings time settings. However, a correct time signal enters a modern home from at least three different sources: teletext TV, the radio data system (RDS), and the Internet [16]. In addition, modern operating systems can correctly interpret and adjust the time following the local daylight savings rules. Our wonderful devices however, fail to cooperate to correctly set their time. Even modern sophisticated cooking ovens, whose marketing literature implies that they possesses artificial intelligence, are unable to set their clock to the correct time.

3.4  Provisioning

Related to the lost synergies is the duplication of hardware and functionality we witness in the modern home. Provisioning communication, user access, power, and space for all different devices is simply an unproductive use of resources.

Communication

The systems I outlined in Section 2 are typically implemented using the following distinct communication networks:

  1. Voice
  2. Data
  3. Door interfacing
  4. Heating
  5. Security
  6. Light control

There are (expensive) systems that integrate some of the above functions, but the general case involves a waste of resources.

Usability Concerns

Each home system has its own user interface, with its ergonomically-challenged human interfacing devices. Humans have to learn different dysfunctional interfaces to perform a limited number of tasks.

Power

Each system needs line power, and, in the best case, also has a separate backup power system (typically a 9V battery). Apart from the nuisance of maintaining the tens of different backup power systems, the power requirements of all devices add-up to a sizable power drain which is both expensive, and environmentally unsound.

Space

Finally, many devices occupy space in living areas daily imposing their unsightly presence on us. The ubiquitous table with the telephone, answering machine, and fax is one example; the collection of the remote controls on the lounge table is another.

4  The Information Furnace

The Information Furnace, supporting the post-PC ubiquitous computing paradigm [17,18], is a basement-installed PC-type device that integrates existing consumer home-control, infotainment, security, and communication technologies to transparently provide ubiquitous access and synergistic value-added services. The use of integrated intelligent devices in the home automation area is not a new concept [19,20,21,22,23], the information furnace differs however from other approaches by prescribing concrete architectural guidelines, expressly adopting a maximalistic approach towards its functionality, and aggressively targeting and exploiting the resulting synergies.

4.1  Architecture

The architecture of the information furnace is based on three basic premises. The device:

  1. is located in the basement or in a cupboard,
  2. acts as a central hub for content, communications, and control, and
  3. offers multi-modal, ubiquitous and easy to use access to all its functions.

The location of the device in a secure, non-accessible place is central to our design having a number of important repercussions. Firstly, the same location will be used to terminate the various connections. These often include home networks, telephone lines, reception antennas, network lines, and cable TV connections. The unsightly presence of all these cables can only be accommodated in a specially provisioned place. In addition, the noise the system will generate can be effectively isolated. Rotating hardware (hard disks and fans) and other noise-generating components such as electromagnetic relays can be brought together into a single place keeping the rest of the house serene. Furthermore, the system can be physically secured deterring burglars, minors, or even pranksters (have you checked your answering machine message lately?) Finally, an appropriate uninterruptible power supply (UPS) can be provisioned to constantly maintain power without worrying about its size, noise, or appearance, or the distribution of power to multiple locations.

As the furnace acts as a central hub for content, communications, and control, we can eliminate wasteful duplication, provide universal access to all its functionality from any local or remote location, centralise our access and control policies, effectively backup all data, and, most importantly, exploit the synergies that the centralisation allows. A single modern CPU can easily handle all the functions I described in Section 2. Thus the numerous underpowered, specialised devices can be replaced with a single general-purpose one. When all functionality is housed in a centrally connected location, it can be accessed from all networked locations. Thus elements such as, the family's music and photograph collection, the answering machine messages, lighting controls, the burglar alarm log, and the heater programme are available from all rooms in the house, and also from remote locations. Naturally, the centralisation of these important functions entails considerable risks; these can however be effectively controlled if the associated policies are centralised, reviewable, and implemented under a reasonably secure operating system. In addition, all the programming and other information stored in the device can be centrally backed-up on a regular basis.

Surprisingly, the information furnace concept, when applied as a replacement for the stand-alone provision of the functions it supports, increases all aspects of the figure of merit M, originally proposed for nomadic computers [24]:

M = Intelligence
Size ×Cost ×Power
However, the most important benefit of the centralisation is the synergies that can be exploited; we will examine this aspect in Section 4.3

The final element of the information furnace architecture concerns its user interface. I do not believe that a single user-interface is appropriate for all occasions. For this reason, the information furnace offers a number of different access modes. These can include web forms and Java applets, telephone-based DTMF commands, infrared remote controls, access via Bluetooth devices, or even a command-line interface. Thus, for selecting a song to hear one will use an infrared remote control, to start the hot-water boiler when returning from a trip one will issue DTMF commands over the cellular phone, to open the garage door one could use a Bluetooth interface of a PDA, and to program or review the activity log of the PBX or the burglar alarm one would prefer to interact with a web form. Ideally, all functionality should be available from all devices; at night one might prefer to use the bedside phone to check the burglar alarm sensors; when working on a PC, a web interface might be used to review the answering machine messages. Some of the access modes can be more easy to use than others, however the processing and storage power of the information service means that there will be no artificial restrictions to the usability of a particular access mode. As an example, a complete answering machine help menu can be made available as a voice message over a phone connection without requiring the user to rely on cut-out cards or memorise the access commands.

4.2  Functionality

func.gif
Figure 2: Information furnace functionality.

The functionality the information furnace provides encompasses everything it can reliably and safely accommodate (Figure 2). The information furnace should also act as the centralised repository for the home occupants' data, in a manner analogous to the one suggested by the CyberAll project [25,26], and integrate the home's communication interfaces by performing the functions of a firewall, a router, an, intercom, and a PBX, acting as the hub of a Home Media Network [27]. I take this maximalistic view, because, by my experience, every system and function moving to the information furnace automatically benefits from universal multi-modal access, easy to use control, and data backup, while providing additional opportunities for synergies with other services.

When some type of functionality can not be directly implemented by the hardware at hand, the information furnace shall at least communicate with the respective dedicated device so that it can indirectly control it. As an example, by communicating with a PBX using a simple modem, one can provide a decent user-interface to the functionality I described in Section 3.1.

All integration shall of course be performed with an eye on safety and security. Where appropriate, the information furnace should work in parallel with dedicated hardware providing redundancy, or be isolated from it. Elevators, fire monitors, and emergency lighting should probably be left to work on their own; tapping an elevator's ``call'' button or a fire-alarm's output should be the limit to the type of coupling that should be considered safe. Similarly, control of mains voltages should be performed by dedicated hardware, leaving to the information furnace the task of issuing the respective commands [20].

4.3  Synergies

The most effective user interface is the one that does not exist [28,14,29]. Centralising all home control, content, and communications in a single place allows us to exploit synergies that make many control functions redundant, or provide new and more versatile features. In this sense the information furnace behaves as sentient computing system, one that reacts to changes in its environment according to the user's preferences [23].

The collocation of all services in a powerful processing and storage device makes it possible to provide centralised backup, universal and multi-modal access to all functions, and interfaces that are easy to use.

Consider the alarm-system motion detectors. These can detect activity in rooms and can therefore be used to:

When leaving the home and on return the activities we perform can be comparable to walking through a jet-pilot's checklist. The information furnace can collectively perform these standardised activities through a single command. Thus the ``leave-home'' command will turn-on the answering machine, switch-off the internal artificial lighting and entertainment systems, lower the central-heating temperature, light the entrance, activate the burglar alarm, and open the garage door. On return a single (password protected) command will deactivate the burglar alarm, turn-off the answering machine, play-back any incoming messages, provide caller-id information on unanswered phone calls, switch-on the internal artificial lighting and entertainment systems, raise the central-heating temperature, switch-off the entrance light, and close the garage door. Similar sequences can be used for putting the house to sleep and preparing it for its owners' wakeup.

Other activities can trigger synergistic events. As an example picking up the phone can cause the entertainment system to pause the music or video playback in the respective room; when the alarm system detects an unlawful entry it can begin flashing all the house's lights to frighten the burglar and attract neighbourhood attention; watering the garden should probably be avoided when the garden lighting indicates that a party is taking place; a visitor overstaying his welcome might cause a gradual lowering of the house's temperature and lighting.

5  Prototype Implementation

struc.gif
Figure 3: Information furnace connection diagram.

To experiment with the ideas I outlined in the previous sections I designed and implemented a prototype of the information furnace. (In all honesty this is not an entirely accurate description of the causal relationship between the two aspects of my work, but seems to be the generally-accepted politically-correct way of expressing it.) The implemented information furnace provides the functionalities of an alarm system, an answering machine, a fax server, a PBX interface, an internet firewall and router, a content management and distribution point, and a backup server.

5.1  System Structure

You can see a diagram of the information furnace connections in Figure 3. The information furnace consists of a low-end (100 MHz Pentium) PC equipped with a 80Gb hard disk, an additional serial port card, and an Advantech PCL-724 24-bit digital input / output card. For the PC I was fortunate to acquire a surplus IBM Personal Computer 340 unit; running FreeBSD 4.1, and later 4.6, it proved to be a very stable platform with uptimes in excess of 200 days. The national telecom operator provides with each ISDN connection a terminal adapter with two POTS (plain old telephone system-traditional analogue phone) interfaces and an RS-232 or USB data port. The data port is connected to the information furnace for providing internet access and firewall functionality. The two POTS interfaces are connected to an entry-level analogue PBX. I decided to use an analogue PBX instead of an ISDN model to minimise the system's cost and by reasoning that new upcoming telephony offerings, such as xDSL or fixed wireless lines, might not be compatible with an ISDN PBX. The PBX connects to a number of plain phones, a door-entry phone, a relay-actuator for opening the door, and a POTS modem used for programming the PBX and providing a voice/DTMF interface. The 80Gb hard disk is used to store music content in MP3 form to distribute throughout the house and as intermediate storage for backup purposes. PCs and MP3 players connect to the information furnace via an Ethernet local area network (LAN). The GSM phone and a UPS, both connected to the information furnace via serial links, provide communications and power backup.

Connecting the alarm system devices to the furnace was more challenging. Alarm sensors and actuators typically work with 12V voltage, while the digital I/O card I used provided an 8255-compatible TTL type interface on a 50-pin ribbon-cable connector. To match the physical form and electrical characteristics of the two systems I designed and implemented a simple printed circuit board (PCB) circuit that converts sensor signals into TTL-compatible inputs, uses relays to activate external loads, and provides screw-clamp terminal blocks for connecting the sensors and sirens (Figure 4, right).

Figure 4: The information furnace and the sensor connection PCB.

5.2  Home Security

The information furnace's alarm subsystem consists of a device driver that interfaces to the PCL-724 card and a daemon that monitors sensors and reacts to signals and commands.

The user-mode alarm daemon is structured around an event-driven driven loop. Three types of events are handled:

Different levels of logging are provided by calls to the Unix syslogd(8) daemon. Apart from triggering the various sirens, alarms cause the queuing of voice and data messages to kind (unlucky) individuals and the responsible authorities via the modem and the (backup) GSM phone.

The actual behaviour of the alarm is specified using a domain-specific language [30,31,32]. A domain-specific language (DSL) [33] is a programming language tailored specifically for an application domain: rather than being general purpose it captures precisely the domain's semantics. Examples of DSLs include lex and yacc [34] used for program lexical analysis and parsing, HTML [35] used for document mark-up, and VHDL used for electronic hardware descriptions. Domain-specific languages allow the concise description of an application's logic reducing the semantic distance between the problem and the program [36,30]. As a design choice for implementing safety-critical software systems DSLs present two distinct advantages over a ``hard-coded'' program logic:

Concrete Expression of Domain Knowledge
Domain-specific functionality is not coded into the system or stored in an arcane file format; it is captured in a concrete human-readable form. Programs expressed in the DSL can be scrutinised, split, combined, shared, published, put under release control, printed, commented, and even be automatically generated by other applications.

Direct Involvement of the Domain Expert
The DSL expression style can often be designed so as to match the format typically used by the domain expert. This results in keeping the experts in a very tight software lifecycle loop where they can directly specify, implement, verify, and validate, without the need of coding intermediaries. Even if the DSL is not high-level enough to be used as a specification language by the domain expert, it may still be possible to involve the expert in code walkthroughs far more productive than those over code expressed in a general purpose language.

The DSL used for specifying the alarm daemon behaviour describes a state machine. Each state description consists of its name, actions to perform when it is entered (written on lines starting with a | symbol, and events that lead to other states (denoted using a > symbol). Actions are simply C function calls. To enhance the DSL's expressiveness a state can also transfer immediately to another state without waiting for an event; I use this feature to modularise the specification by defining ``subroutine'' states. As an example, the sequence in Figure 5 is used to specify that a ``leave'' command will arm the system 10s after opening the door: A small Perl [37] script transforms the alarm specification into an efficient C loop structure.

leave:
    | set_sensor_active(ALL, OFF)
    | set_sensor_active("Door", ACTIVE)
    > wait_for_door_open
    ;
wait_for_door_open:
    | syslog(LOG_INFO, "Waiting for door open")
    ActiveSensor > door_open
    ;
door_open:
    | syslog(LOG_INFO, "Door opened")
    10s > day_arm
    ;

Figure 5: DSL specification of the ``leave'' command.

5.3  Telephone Integration

The answering machine, fax server, PBX programming, and alarm-notification functions of the information furnace are handled by software written on top of the vgetty [38] extension: a voice-handling add-on to the mgetty [39] package, which in turn replaces the Unix getty(8) terminal handler to handle data and fax calls. I wrote the incoming and outgoing modem interaction scripts in Perl using the Modem::Vgetty(3) [40] Perl package.

The PBX provides a global 100 phone quick access memory feature. By using these memories one can access the same number from all extensions, without having to individually program and maintain the memories of each different telephone. Apart from offering a centralised point for storing the quick-dial numbers, this approach obviates the need to handle the disparate user-interface each device has for storing phone numbers (is the programming sequence ``code AUTO number store'' or ``MEM code number hangup''?) Of course, this approach solves one user-interface problem by replacing it with another, since the quick-access programming sequence for the PBX is (hold your breath) ``6206206# #00code0number# 6206#''. Thankfully, having the PBX connected to the information furnace, one can easily package this functionality as a shell script and have another script program the PBX quick-access memories to a known state:

# John Doe Home
setmem 10 0105554321
# John Doe mobile number
setmem 11 0935551234
# John Doe Office
setmem 12 0105556789

Since this script is rarely used, I did not provide a more elaborate interface to it, although the script could easily be generated by mining the PDA phone database backups, or through web forms. However, even in the format it currently is, it proved a time-saver when the country's numbering plan changed: a simple global replace operation in the editor resulted in a new script that when run correctly programmed the PBX memories for the new plan.

5.4  Content Distribution

A motivating requirement that led to the information furnace's conception was the ability to access our music collection from any networked place in the house. Converting CDs into a collection of MP3-compressed files is a relatively easy task these days. I used dagrab [41] and cdparanoia [42] to extract raw content from audio CDs, and the encoders bladeenc [43] and notlame [44] to convert that content into MP3 form. More difficult were the tasks of organising the transfer of a set of CDs into MP3 format (the so-called ``ripping'' operation), systematising the material's storage and access, providing useful metadata, and setting up an appropriate content directory.

Figure 6: CD and track-level HTML playlists.

The ripped CD directories form a hierarchical structure made up out of the music type, the composer, performer, or band name, the album name, and the CD number. A script crawls the directory structure and creates a metadata file for each CD (info.txt by pulling information out of the cddb.com (and later the freedb.org) server. I decided to store the metadata into a separate file and not use the ID3 standard, because the type of data available from the public CD directories does not exactly match that maintained in the MP3 ID3 structures. A separate Perl script crawls the content directories gathering metadata and creating the content directory in plain text, HTML, and LaTeX file formats. Each CD is identified by a three digit number and each individual track is identified by a five digit number (Figure 6). These numbers are again stored in one plain-text file (index.txt) for each CD. The numbers increase monotonically as new CDs are added and are never reused thus providing numbering persistency, so that bookmarks and music collections are not rendered invalid when CDs are added or deleted. The CD and track identification numbers are also needed for selecting a particular CD or track using a simple remote control. I reserved two-digit numbers for creating bookmarks to particular songs, and single-digit numbers for identifying a music type (e.g. Rock, Jazz, or Classical) from which an MP3 player would randomly shuffle tracks. The last option proved to be the most popular. The plain-text file forms the track database. It simply contains track and CD identification numbers as comments, followed by the respective file name:

# 521
# 10297
/vol/music/Classical/Bach/FrenchSuites/cd1/track01.mp3
# 10298
/vol/music/Classical/Bach/FrenchSuites/cd1/track02.mp3
# 10299
/vol/music/Classical/Bach/FrenchSuites/cd1/track03.mp3

This format allows simple sed(1) scripts to select data based on a CD or track identification number and feed the results directly as a playlist to MP3 players such as mpg123 [45] and mad [46].

Figure 7: The Digital Network Appliance Reference Design-DNARD and the Shark as an MP3 player .

The first MP3 player connected to the information furnace was a network computer. In 1997, Digital Equipment Corp. (which became part of Compaq Computer Corp. which became part of HP) produced the DIGITAL Network Appliance Reference Design (DNARD), and published the hardware specifications for free use. DEC used the code-name ``Shark'' to refer to these NCs-probably due to the plastic fins used to make them stand in an upright position (Figure 7). The DNARD exploits the power of the StrongARM microprocessor combined with the flexibility and economy of industry standard busses and chips. With the sale of Digital Semiconductor to Intel in early 1998, ownership of the StrongARM passed to Intel. Since that time, the DNARD design has no longer been supported by Digital or Compaq. Using however, a DNARD as an MP3 player connected to the information furnace was an attractive proposition, because of the DNARD's attractive slim design, silent operation (it does not contain a disk or a fan), infrared port, and audio hardware. The Shark runs NetBSD 1.5 patched with Mark Foster's AV package to support the audio hardware and the infrared port [47]. The Shark gets its initial configuration from the information furnace dhcpd(8) server and boots using the trivial file-transfer protocol (TFTP) [48]; it subsequently mounts its file systems and the MP3 disk volume over the network file system (NFS) [49]. A small shell script, run at startup time, allows us to use a remote control to select music. The irw command from the LIRC distribution [50] reads remote control messages. These can be a number forming a CD, track, or music-type code, play, stop, previous, next, or pause. The play command starts an MP3 player process. All other commands are handled by sending signals to the MP3-player process: stop kills the player process; pause pauses it; previous and next send it the USR1 and USR2 signals respectively. Playlists are generated by a sed(1) command that prints the master playlist from the music part selected until its end. As music is sorted and traversed according to its content, when the player finishes the selected track or CD, it will continue playing roughly similar content. Shuffling of music tracks is simply accomplished using the NetBSD shuffle(1) command.

The two other MP3 players we deployed use similar concepts, but run on less polished hardware and software configurations. One consists of an Intel 100MHz Pentium PC that boots a copy of FreeBSD diskless from the information furnace using etherboot [51]; the other is an old laptop running SuSE Linux 7.0. Having the information furnace utilise simple standards for organising and disseminating the content (a text index and MP3 files exported via NFS as a directory tree) allowed me to choose the operating systems opportunistically: I selected FreeBSD to avoid the burden of configuring, maintaining, and provisioning disk space for another operating system (the player shares the read-only partitions of the information furnace), and SuSE Linux because it was the first OS installation to run correctly on the laptop's idiosyncratic hardware.

5.5  Security and Availability

The information furnace is secured in a place that is not easily accessible, continuously performing a number of critical functions. For these reasons it is imperative that it runs unattended and recovers gracefully after any problem. An appropriately provisioned and correctly configured UPS proved to be essential for its reliable operation.

The information furnace also acts as an internet router and as a firewall by means of the native FreeBSD user-mode ppp(8) package running with network address translation (NAT) enabled. This approach while not perfect is adequate for the profile of the users living inside the firewall. Configuring the filters was relatively easy, once I had reference [52] at hand. Despite my earlier thoughts to the contrary, I found that protecting a dial-up connection can be worthwhile. I do not have time to maintain the various MP3 players with the latest security patches and, as the following excerpt from the information furnace's apache log shows, dial-up connections are actively scanned for security holes:

[Tue Sep 18 20:35:49 2001] [error] [client 195.158.192.25]
File does not exist: /usr/local/www/data/scripts/..\xc1\x9c
../winnt/system32/cmd.exe

6  Discussion

In the previous section we saw that the concept of the information furnace is indeed realisable, if only as a prototype with a subset of the functionality we prescribed in Section 4. The move from distributed specialised appliances into a centralised information furnace is not without risks and potential problems. Here I will describe the most important factors that facilitated and hampered the development as well as issues that are likely to affect the adoption and evolution of information furnace systems in the future. A wider view of the challenges in deploying ubiquitous systems, such as the one we describe, can be found in [53].

6.1  Open Source Software

Clearly, the most important aspect that affected the development was the availability of open-source software. The information furnace and its appendages were based on three different open-source operating systems. The stability and clear structure of FreeBSD provided the platform for the main unit, NetBSD with its multiple architecture support was at the time the only OS that supported the Shark's StrongARM architecture, while the aggressive development model of Linux resulted in an installation procedure and the existence of device drivers that could revive an old laptop as an MP player. The distribution of the operating systems in source form allowed me to easily write and add a device driver to support the PCL-724 I/O card under FreeBSD, and Mark Foster to patch NetBSD to provide audio and infrared support for the Shark. A number of times I found myself going over the source code to verify elements that were not clearly documented-documentation can not possibly cover everything. Some early failed experiments for diskless-booting the Shark were based on an old Linux platform; by comparing the NFS implementation of the Linux version I was using with that of the Shark's NetBSD I quickly found out that the configuration would never work since the two were supporting different versions of the NFS protocol.

No less important were the various add-on packages I used. In some cases I experimented with more than one package for a given task. It was clear that the co-existence and evolution of competing packages created evolutionary pressure that resulted in better overall offerings. A clear example of this case was the area of MP3 encoders and decoders. The Shark, with its StrongARM processor lacking floating-point support, is a tough platform for MP3 decoders. I fortunately was able to choose and test several different packages until I settled for the MAD MP3 decoder; the only one that run successfully on the Shark. A counterexample was the vgetty package: as far as I could determine it is the only viable offering for handling voice modems, and it has a lot of room for improvement. At the start of the project I was somewhat ambivalent on binary and package distributions. However, I found that being able to quickly try packages without having to go through the configuration and manual compilation process outweighed the opacity problems of this distribution process.

6.2  Standards and Costs

The existence of open standards proved to be a blessing for the project's success; the lack of standardisation a curse. Specifically, the lack of open standards ruled out having the information furnace controlling the home's heating in the form I described: the heating controller was clearly attached to a form of a network bus, but its operation at all the network stack levels was apparently a secret closely guarded by its manufacturer (i.e. the standard was not available on the web). Similarly, in the domain of artificial lighting controls, it being an area where a number of incompatible proprietary standards compete, there are expensive solutions that do not deliver the economies they could. Efforts for integrating arbitrary communication protocols such as [54] could help, so would adopting TCP/IP for communicating with all devices [55].

On the other hand, the standards and the resulting economies of PC manufacturing coupled with the rapid obsolescence of PCs provided me with a number of cheap and viable platforms for deploying the information furnace's infrastructure. While scavenging obsolete hardware can be a viable strategy for a researcher or a hobbyist, it can not form a long-term technology adoption plan. However, the above forces can also result in the development of affordable hardware platforms based on established components and processors like the DNARD Shark. These platforms, based on cheap industry-standard busses and chips can form the base of the future's mass-produced information furnaces.

6.3  Emerging Technologies

Several new technologies are likely to influence the way the information furnace concept is realised in practice. Closer networking of appliances is likely to influence the way information furnace architectures are deployed and interfaced. Third generation mobile phones [56] and personal area networks using Bluetooth [57] may provide the infrastructure for users to communicate with the furnace on the road and at home, while wireless LAN technologies such as IEEE 802.11b, HiperLAN, and HomeRF [58] may be used for interfacing the information furnace with the devices it controls. On the software side, components [59], architectures based on web services [60], or adaptive network-centric technologies such as Jini [61] can in the future be used to build the functionality of the information furnace out of preconfigured subsystems. Other technologies that could influence the evolution of the information furnace concept include the use of indoor positioning technologies [62] to enhance the capabilities of the passive sensors we used, and the adoption of the interactive digital TV as the front-end for most leisure related interactions [63].

6.4  User Interface

Figure 8: Web-based interface to communications and security functions.

A constant theme that came up during the development, deployment, and evaluation of the information furnace was its user interface. The main objectives of the prototype development described in this paper were to demonstrate the technical viability of the proposed setup and provide an experimental test-bed to investigate the synergies emerging from the service co-location. User-interface improvements should naturally surface once devices were freed from the artificial constraints imposed by their hardware: tiny displays, primitive input devices, and limited communication capabilities. In Figure 8 you can see a simple prototype demonstrating how an interface to the information furnace's communications and security functions can be provided through simple web forms. Similar forms could be offered in the future through a mobile phone's or PDA's web browser, providing a consistent interface to the residents at home and on the road. In addition, research in the area of multi-platform service delivery [64] and ``create once publish everywhere'' (COPE) strategies could in the future provide the infrastructure for offering a consistent, personalised interface across multiple devices with different affordances. Future research could be directed towards examining the use of the proposed prototype in its context of application. Scholars could then consider issues arising from the application of human computer interaction theories into its different application domains.

However, the most important qualitative change the information furnace brought to the user interface was a move from the typical imperative commands humans issue to their appliances (``turn answering machine on'', ``deactivate alarm'', ``mute the volume'') into more a sophisticated declarative dialogue. Thus, typical commands that we issue are ``we are leaving home'' (which activates both the alarm and the answering machine once the building's door is opened, and also unlocks the street door), and a complementary ``we are back now'' (which reverses the above actions and also informs us on any pending voice and fax messages or missed calls). Although this interface, operating on voice prompts and DTMF commands, does not utilise a fancy graphical user interface (GUI), it has literally halved the twice-a-day appliance interactions we would have to engage-in.

6.5  Human Diversity

Coupled with the information furnace's new capabilities comes a vast array of tuning and parameterisation possibilities. The appropriate methods and, possibly, interfaces for configuring these are an open question. Environments that automatically adapt to their users' preferences and agent-based architectures that handle tasks on behalf of users have been touted as a possible answer [65,66]. In practice however users have often found such environments complex, intrusive, and unpredictable; some researchers believe that being in control, gaining mastery of a system, and accepting responsibility for its actions will lead to feelings of accomplishment that should not be overlooked [67]. In addition, population variation in technical sophistication, cognitive and perceptual abilities, and cultural background will result in users with radically different expectations from their interactions with the information furnace.

Orthogonal to the above variations in interaction style are the needs of users with disabilities, children, and the elderly. To those the information furnace can provide universal access to all home's appliances using communication channels tailored to their preferred interaction methods [68]. The information furnace's computational power and flexibility in configuring input and output peripherals make it an ideal platform for deploying the appropriate interfaces. Large fonts, voice and haptic interfaces, eye-gaze control, and speech recognition are some of the technologies that could allow users with disabilities participate in a richer interaction with their home environment.

6.6  Security and Dependability

Before information furnaces are widely deployed, an important new risk that will have to be addressed is the pervasive impact of security breaches and software or hardware failures. Currently, a guessed answering machine PIN will only provide access to the owner's voice mail messages; in contrast, a compromised information furnace will allow the intruder to control many of the home's appliances. On the other hand the increased computational power of the information furnace enables the deployment of more sophisticated authentication mechanisms, based e.g. on one time passwords or on private keys stored on a mobile phone's subscriber identity module (SIM) card.

Dependability issues are equally important. The integration of existing consumer home-control, infotainment, security, and communication technologies on the information furnace platform creates a single point of failure; a non-functioning information furnace will result in considerable inconvenience to the home's residents. A three pronged approach will be needed to provide a dependable platform. First of all, the information furnace shall be based on reliable hardware and software configurations. Our prototype system based on vintage IBM hardware and the ``stable'' version of the FreeBSD operating system achieved continuous operation exceeding 200 days. In addition, the information furnace and the devices it controls must be designed so that hardware and software problems result in a fail-safe, graceful degradation of the provided services. As an example, a catastrophic motherboard failure could result in doors reverting into manual control, and phone service provided only on a single handset. In the longer term, approaches such as autonomic computing [69] may result in systems with substantially improved dependability and serviceability characteristics.

6.7  Deployment and Maintenance

Related to the issue of dependability, and perhaps the biggest roadblock to the universal deployment of information furnaces, is their installation, testing, and maintenance. The broadband deployment business plans of a number of telecommunications companies were foiled by the cost incurred for having expensively trained technicians install the network adapters at the each customer's premises [70]. The installation of an information furnace using today's interfacing technologies, will probably be an order of magnitude more challenging. The interactions of multiple systems can result in many subtle and difficult to find bugs. Some of them can be amusing: the first visitors to ring the doorbell after the information furnace was deployed were greeted with a telephone answering machine message! More than a year after the furnace's deployment we are still tuning its operation and correcting (minor by now) inconveniences.

Most people would not regard the existence of a resident system administrator an acceptable solution to this problem. The availability of stable software (rather than its organic home-growth), the adoption of the domain-specific languages we saw in Section 5.2, and the initial configuration of the furnace by a qualified professional can help in this direction. However, the above process, although similar to other processes followed for building homes, is completely different from the ad hoc procedure typically employed when purchasing and deploying consumer-oriented hardware (plug it in, play with the buttons, avoid reading the manual). Although standard interfaces, similar to those that currently allow the seamless installation of USB-style peripherals on PCs, may somehow ease the configuration burden, the current state of the art makes even the installation of home theatre equipment a formidable task [71]. Unless the widespread deployment of information furnaces is coupled with an appropriate installation and maintenance process, significant problems will ensue.

6.8  Lifespan Mismatch

The mismatch between the lifespan of residential housing and that of typical IT consumer appliances is one other source of concern. Most dwellings are designed to last for fifty or more years. In contrast historical experience suggests that typical IT appliances are outdated in less than two years, are impossible to service using spare parts after ten years, and in thirty years even the skill set required for their maintenance disappears from the job market. Performing a hardware and software upgrade every five years (current practice for workstation maintenance in many IT departments) will most probably not be a proposition home owners are likely to accept. Standardising hardware interfaces and home configuration files may initially appear to be a solution, until one considers the difficulty one would face today in reading data from a standardised and once ubiquitous 9-track, half-inch tape. Solutions for matching the life of the information furnace to that of the home it supports are likely to be provided either through the application of research results from the area of digital preservation [72] or from a specialised industry segment supplying IT appliances with guaranteed support through a of a very long lifespan.

7  Concluding Remarks

There is tremendous scope for making the devices found in a modern home more easy to use and synergistic. The isolated location, all-inclusive scope, and multi-modal interface attributes of the information furnace offer a potential roadmap for achieving these goals. By implementing a prototype I discovered the pivotal role that open-source software, standards, and the deployment process will play in such an endeavour.

Some may counter that my thesis for a centralised information furnace contradicts the proposed move from a complex general purpose personal computer towards user-friendly simple, and versatile ``information appliances'' [14,73]. I can defend my position on two grounds. Firstly, the systems my proposed information furnace is set to replace do not exhibit any of the information appliance design axioms: simplicity, versatility, pleasurability [14]. Secondly, my solution, although based on personal computer technology, does not entail (at least in the form I designed it) the two damning characteristics of PCs: creeping featurism and an application-oriented mindset [14]. I propose that application furnaces be individually configured by experts to match the needs to a home's occupants in the same sense as the house itself is architected. In addition, the information furnace I propose is in fact an information appliance, albeit one with a rather large scope: to integrate the home's control, information, and communication systems. This integration aspect-necessary to exploit the synergies I discussed-is the diametrical opposite to the PC's ``one application for each task'' design philosophy.

While my prototype implementation proves the concept, its piecemeal implementation by a single developer has resulted in a wanting (to put it politely) software architecture. If the information furnace concept is to be widely adopted major architectural challenges have to be overcome. Already, research approaches such as iRoom [22], demonstrate how the task of developing such an architecture could be approached. Mass-produced hardware for information furnace applications should be uniquely tailored to the special needs of its domain; in our implementation we found that a large number of digital and analog I/O ports and appropriate network interfaces were more useful than raw processing power. Similarly, the software architecture of a consumer-oriented information furnace should: be extremely reliable, allow installator and end-user customisation, provide means for interfacing to many different proprietary devices, and integrate the above with a modular, multi-modal, and easy to use interface. Context-awareness issues need to be carefully examined and resolved [74]. What is not needed is a repeat of the PC usability and reliability debacle in a scale that will affect our entire family, lives, and home.

Acknowledgements

Compaq Research contributed (as a prize of the 2000 Usenix technical conference ``win a pet Shark contest'') the Digital Network Appliance Reference Design-DNARD that I used as the system's first MP3 player. Jeffrey Mogul kindly handled the tricky logistics for distributing the contest's Sharks and saved the day by explaining to me how a keyboard could be essential for its operation. Eliza Fragkaki contributed the server's processing unit, literally provided a helping hand during the CD ripping operation, and patiently endured the prototype system's alpha and beta testing period. Lorenzo Vicisano came up with the idea of using the Shark as an MP3 player, while Isidoros Kouvelas and Vasilis Prevelakis offered encouragement, help, and interesting ideas during the prototype's implementation. Finally, Giorgos Gousios, Konstantina Vassilopoulou, and the anonymous referees provided valuable constructive comments and pertinent remarks on earlier drafts of this paper.

Software Availability

The source code for the PCL-724 device driver and the Shark MP3 player script is available at < http://www.spinellis.gr/sw/ifurnace>.

References

[1]
Diomidis Spinellis. The information furnace: User-friendly home control. In Proceedings of the 3rd International System Administration and Networking Conference SANE 2002, pages 145-174, Maastricht, The Netherlands, May 2002.

[2]
Giorgos Lekakos, Kostas Chorianopoulos, and Diomidis Spinellis. Information systems in the living room: A case study of personalized interactive TV design. In Proceedings of the 9th European Conference on Information Systems, Bled, Slovenia, June 2001.

[3]
Diomidis Spinellis. Palmtop programmable appliance controls. Personal Technologies (Personal and Ubiquitous Computing), 2(1):11-17, March 1998.

[4]
Amitava Dutta-Roy. Networks for homes. IEEE Spectrum, 36(12):26-33, December 1999.

[5]
Fotis Georgatos and Annie Pinder. Coffee-HOWTO. Online. http://www.linuxdoc.org/HOWTO/mini/Coffee.html, 2000. Current March 2002.

[6]
Sung H. Han, Myung Hwan Yun, Jiyoung Kwahk, and Sang W. Hong. Usability of consumer electronic products. Industrial Ergonomics, 28:143-151, 2001.

[7]
B. A. T. Brown and M. Perry. Why don't telephones have off switches? Understanding the use of everyday technologies. Interacting with Computers, 12:623-634, 2000.

[8]
Donald A. Norman. The Psychology of Everyday Things. BasicBooks, New York, NY, USA, 1988.

[9]
Ben Shneiderman. Designing the User Interface: Strategies for Effective Human-Computer-Interaction. Addison-Wesley, third edition, 1998.

[10]
Jef Raskin. The Humane Interface: New Directions for Designing Interactive Systems. Addison-Wesley, 2000.

[11]
Siemens Building Technologies. Room Units for Use with Heating Controllers: QAW70, June 1999. Document code CE2N1637E.

[12]
Thomson Consumer Electronics, Indanapolis, USA. GE Digital Answerer, 1996. Document code 2-9865.

[13]
Matsushita Electric Industrial Co., Osaka, Japan. Panasonic Electronic Modula Switch System Modem KX-T206: Installation Manual, 1993. Document code PSQX1158YA KW0796KM1027.

[14]
Donald A. Norman. The Invisible Computer. MIT Press, Cambridge, MA, USA, 1998.

[15]
Catherine Plaisant and Ben Shneiderman. ON-OFF home-control devices: Design issues and usability evaluation of four touchscreen interfaces. Interacting with Computers, 3(1):9-26, 1992.

[16]
David L. Mills. RFC 1305: Network time protocol (version 3) specification, implementation, March 1992.

[17]
M. Weiser. Some computer science issues in ubiquitous computing. Communications of the ACM, 36(7):74-84, October 1993.

[18]
Larry Press. Personal computing: the post-PC era. Communications of the ACM, 42(10):21-24, October 1999.

[19]
Elizabeth Mynatt, Douglas Blattner, Meera M. Blattner, Blair MacIntyre, and Jennifer Mankoff. Augmenting home and office environments. In Proceedings of the third international ACM conference on Assistive technologies, pages 169-172. ACM Press, 1998.

[20]
Stewart Benedict. X-automate. Linux Journal, 1999(57es):7, 1999.

[21]
Goran Devic. Home entertainment linux MP3 player. Linux Journal, 2000(71es):8, 2000.

[22]
Armando Fox, Brad Johanson, Pat Nanrahan, and Terry Winograd. Integrating information appliances in an interactive workspace. Computers Graphics and Applications, 20(3):54-65, May/June 2000.

[23]
Mike Addlesee, Rupert Curwen, Steve Hodges, Joe Newman, Pete Steggles, Andy Ward, and Andy Hopper. Implementing a sentient computing system. Computer, 34(8):50-56, August 2001.

[24]
Tsugio Makimoto, Kazuhiko Eguchi, and Mitsugu Yoneyama. The cooler the beter: New directions in the nomadic age. Computer, 34(4):38-42, April 2001.

[25]
Gordon Bell. A personal digital store. Communications of the ACM, 44(1):86-91, December 2001.

[26]
Gordon Bell and Jim Gray. Digital immortality. Communications of the ACM, 44(3):28-30, March 2001.

[27]
Gordon Bell and Jim Gemmell. A call for the home media network. Communications of the ACM, 45(7):71-75, July 2002.

[28]
Mark Weiser. The computer of the 21st century. Scientific American, 265(3):66-75, September 1991.

[29]
Roy Want, Trevor Pering, Gaetano Borriello, and Keith I. Farkas. Disappearing hardware. IEEE Pervasive Computing, 1(1):36-47, January-March 2002.

[30]
Diomidis Spinellis and V. Guruprasad. Lightweight languages as software engineering tools. In Ramming [33], pages 67-76.

[31]
Diomidis Spinellis. Reliable software implementation using domain specific languages. In G. I. Schuëller and P. Kafka, editors, Proceedings ESREL '99 - The Tenth European Conference on Safety and Reliability, pages 627-631, Munich-Garching, Germany, September 1999. ESRA, VDI, TUM, A. A. Balkema.

[32]
Diomidis Spinellis. Notable design patterns for domain specific languages. Journal of Systems and Software, 56(1):91-99, February 2001.

[33]
J. Christopher Ramming, editor. USENIX Conference on Domain-Specific Languages, Santa Monica, CA, USA, October 1997. Usenix Association.

[34]
Stephen C. Johnson and Michael E. Lesk. Language development tools. Bell System Technical Journal, 56(6):2155-2176, July-August 1987.

[35]
T. Berners-Lee and D. Connolly. RFC 1866: Hypertext Markup Language - 2.0, November 1995.

[36]
J. Bell, F. Bellegarde, J. Hook, R. B. Kieburtz, A. Kotov, J. Lewis, L. McKinney, D. P. Oliva, T. Sheard, L. Tong, L. Walton, and T. Zhou. Software design for reliability and reuse: a proof-of-concept demonstration. In Conference on TRI-Ada '94, pages 396-404. ACM, ACM Press, 1994.

[37]
Larry Wall, Tom Christiansen, Randal L. Schwartz, and Stephen Potter. Programming Perl. O'Reilly and Associates, Sebastopol, CA, USA, second edition, 1996.

[38]
Marc Eberhard. Vgetty documentation center. Online. http://alpha.greenie.net/vgetty/, 1998. Current March 2002.

[39]
Gert Doering. Mgetty+sendfax archive/documentation centre. Online. http://alpha.greenie.net/mgetty/, 2002. Current March 2002.

[40]
Jan Kasprzak. Modem::vgetty perl module. Online. http://www.cpan.org/authors/id/Y/YE/YENYA/, 1998. Current March 2002.

[41]
Marcello Urbani. dagrab: Read audio tracks from a CD into wav sound files. Online. http://web.tiscalinet.it/marcellou/dagrab.html, 2000. Current March 2002.

[42]
Monty. Cdparanoia-an audio CD reading utility. Online. http://www.xiph.org/paranoia/manual.html, 2002. Current March 2002.

[43]
Tord Jansson. bladeenc MP3 encoder. Online. http://bladeenc.mp3.no, 2002. Current March 2002.

[44]
Conrad Sanderson. Notlame: LAME command-line front end. Online. http://hive.me.gu.edu.au/not_lame, 2002. Current March 2002.

[45]
Michael Hipp. mpg123: A fast MP3 player of Linux and Unix systems. Online. http://www.mpg123.de/, 2001. Current March 2002.

[46]
Robert Leslie. MAD: MPEG audio decoder. Online. http://www.mars.org/home/rob/proj/mpeg/, 2002. Current March 2002.

[47]
Mark J. Foster. AV: An audio/visual equipment device driver for NetBSD. Online. ftp://ftp.talix.com/pub/av/, 1999. Current March 2002.

[48]
K. Sollins. RFC 1350: The TFTP protocol (revision 2), July 1992.

[49]
Sun Microsystems, Inc. RFC 1094: NFS: Network File System Protocol specification, March 1989.

[50]
Christoph Bartelmus, Pablo d'Angelo, Heinrich Langos, Tom Wheely, Karsten Scheibler, Jim Paris, Pawel T. Jochym, and Milan Pikula. LIRC: Linux infrared remote control. Online. http://www.lirc.org/, 2002. Current March 2002.

[51]
Markus Gutschke, Gero Kuhlmann, Jamie Honan, Martin Renters, Bruce Evans, Rob de Bath, and et al. Etherboot open source code for creating boot ROMs. Online. http://etherboot.sourceforge.net/, 2002. Current March 2002.

[52]
Elizabeth Zwicky, Simon Cooper, and D. Brent Chapman. Building Internet Firewalls. O'Reilly and Associates, Sebastopol, CA, USA, second edition, 2000.

[53]
Nigel Davies and Hans-Werner Gellersen. Beyond prototypes: Challenges in deploying ubiquitous systems. IEEE Pervasive Computing, 1(1):26-35, January-March 2002.

[54]
Markus Lauff and Hans-Werner Gellersen. Adapation in a ubiquitous computing management architecture. In Proceedings of the 2000 ACM symposium on Applied computing 2000, pages 566-567. ACM Press, 2000.

[55]
Robert E. Filman. Editor's introduction: Embedded internet systems come home. IEEE Internet Computing, 5(1):52-53, January / February 2001.

[56]
Lee Garber. Will 3G really be the next big wireless technology. Computer, 35(1):26-32, January 2002.

[57]
Pravin Bhagwat. Bluetooth: Technology for short-range wireless apps. Internet Computing, 5(3):96-103, 2001.

[58]
Linda Dailey Paulson. Exploring the wireless LANscape. Computer, 33(10):12-16, October 2000.

[59]
Clemens Szyperski. Component Software: Behind Object-Oriented Programming. Addison-Wesley, 1998.

[60]
Michael Stal. Web services: Beyoond component-based computing. Communications of the ACM, 45(10):71-76, October 2002.

[61]
Ken Arnold (editor), Jim Waldo, and the Jini Technology Team. The Jini Specifications. Addison-Wesley, second edition, 2000.

[62]
Ioannis Mathes, Adamantia Pateli, Argiris Tsamakos, and Diomidis Spinellis. Context aware services in an exhibition environment- the mEXPRESS approach. In Proceedings of the eBusiness and eWork Conference, Prague, The Czech Republic, October 2002.

[63]
Konstantinos Chorianopoulos and Diomidis Spinellis. A metaphor for personalized television programming. In Proceedings of the 7th ERCIM Workshop on User Interfaces for All, Paris (Chantilly), France, October 2002. Springer-Verlag.

[64]
Maria Tsakali and Ioannis Kaptsis. Cross-media content production and delivery: trends and challenges. In Proceedings of the 2002 Euro-China Co-operation Forum on the Information Society, 2002.

[65]
Pattie Maes. Artificial life meets entertainment: Lifelike autonomous agents. Communications of the ACM, 38(11):108-114, November 1995.

[66]
Barbara Hayes-Roth. An architecture for adaptive intelligent systems. Artificial Intelligence, 72:329-365, 1995. Special Issue on Agents and Interactivity.

[67]
Jaron Lanier. Agents of alienation. ACM Interactions, 2(3):66-72, 1995.

[68]
Alistair D. W. Edwards. Extra-Ordinary Human-Computer Interactions: Intefaces for Users with Disabilities. Cambridge University Press, 1995.

[69]
Alfred Z. Spector. Challenges and opportunities in autonomic computing. In Proceedings of the 16th international conference on Supercomputing, pages 96-96. ACM Press, 2002.

[70]
Emma Duncan. There's nothing on. The Economist, October 5th 2000. Survey on e-Entertainment.

[71]
Donald A. Norman. Home theater: Not ready for prime time. Computer, 35(6):100-102, June 2002.

[72]
Su-Shing Chen. The paradox of digital preservation. Computer, 34(3):24-28, March 2001.

[73]
Roy Want and Gaetano Borriello. Survey on information appliances. Computers Graphics and Applications, 20(3):24-31, May/June 2000.

[74]
Thomas Erickson. Some prolems with the notion of context-aware computing. Communications of the ACM, 45(2):102-104, February 2002.