|
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:
|
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
Keywords: Home-control, automation, multi-modal interfaces
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.
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.
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.
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''
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.
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.
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.
There are (expensive) systems that integrate some of the above functions, but the general case involves a waste of resources.
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]:
|
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.
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].
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.
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.
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).
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:
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
;
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.
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].
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
References