ABSTRACT

This paper was presented at the First IRC Workshop 'Dependability in Healthcare Informatics' March 23rd 2001.

Designing assistive technological solutions for disabled people and older people is fraught with problems due to the number of agencies involved.  These problems are compounded by the lack of understanding that can exist between the engineers and the health staff.  This lack of understanding can develop into extreme delays in installing the technology and the needs of the person with disabilities being subsumed in preference to ease of design and installation.  Clearly, these potential misunderstandings could be ameliorated by improved communication between the widely different disciplines each with their own culture, ethos, knowledge and jargon.  The CUSTODIAN[2] smart house simulation software provides a focus for discussion on CUSTODIAN's development in relation to reliability and safety of systems design. 

KEYWORDS

Software development, smart homes, assistive technology, automated homes, disability,

INTRODUCTION

The design of smart home systems is littered with pitfalls for the unwary.  Distinct problems arise from lack of knowledge of how to transfer needs of an individual to specified 'smart' devices in a reliable and valid manner and install them in a way that will achieve their intended purpose.  The current situation within the community care framework means that resources are shared between different agencies such as social work, housing associations and health professionals.  A major impediment to obtaining optimum technological solutions is derived from the resource constraints placed upon each of these areas and the problems associated with interagency communications.  In attempting to facilitate the process of communication between agencies the CUSTODIAN, software was developed.

The CUSTODIAN software suite is a set of tools that enables untrained people fully to design and test smart homes for disabled people and older people.  The software is a visualisation tool that enables the user to test scenarios and set-up configurations as well as demonstrate the functional working design to client groups and other stakeholders.  The tool has been used effectively within the test sites and has proved to be effective as a means of communication between different parties with differing perspectives on design.  The reliability and robustness of the user needs component of the software are discussed.  The use of a metaphor (of purchasing a new car) provides a means of encapsulating knowledge bases such as client needs assessment, product information, building issues and installation techniques.  The paper describes the rationale behind the metaphor and the shows how the metaphor is implemented as a series of specifications for smart house systems.  Although the tool was originally designed to produce whole house installations, this need not be the case and the software can be used for demonstrating how one part of a system works, such as how a remotely operated door opener functions.

Safety is essential for any engineered system, especially for systems for use by vulnerable people [8].  Systems are required to be robust and reliable as the person with disabilities will rely on the installed devices and they will become internalised within their self-concept [3] [5] [7].  To this end, the paper explores the potential pitfalls and actual problems with the use of smart home technology for vulnerable people.  Central questions such as how can technology be made safer and more reliable are posed and discussed within the framework of the CUSTODIAN[3] software development.

SMART HOME SYSTEMS

The authors’ experience of developing generic products lists for Smart Home Systems for a number of people who had widely varying disabilities arising from traumatic brain injury showed that the resulting lists were broadly similar and largely independent of the nature of the disability.  This paper explores the explanations for this result and the implications for the design of Smart Home Networks for older and disabled people and the consequent functional requirements for the CUSTODIAN tool.  The result of this is presented in this paper as a new metaphor for the specification and design of Smart Home Systems for disabled people (including age related disabilities) based on the purchase of a new car.  This involved the development of a range of standard ‘models’ to which a limited range of devices may be added or removed. 

The metaphor also provided a way of encapsulating knowledge bases such as client needs assessment, product information, building issues and installation techniques, wiring regulations and standards.  The output from the CUSTODIAN tool is a list of specified or generic devices that will be networked in a Smart Home System and a specification describing the functionality of these networked devices required to meet the specific needs of a client [9].  Whilst in this paper Networked Home Systems are described in the context of the European Installation Bus (EIB) system, the specifications that are produced by CUSTODIAN are sufficiently generic that they could be implemented by other Smart Building systems such as LonWorks, CeBus, and BatiBus etc.  In addition, the paper refers to domestic electrical systems in the UK.

EIB SMART HOME SYSTEMS

Consider how an electrical engineer designs an EIB system for a new building such as a house.  All houses have similar common features (bathroom, toilet, food preparation and cooking, sleeping area, entrance etc. 

When an EIB system is proposed it will almost certainly include the lighting circuits, which is the simplest and most basic EIB application.  Heating (both space and water) is an essential requirement in the UK so it makes sense to connect the heating systems into the EIB network.  These systems together form the EIB, or any other proprietary, Home Network Solution.  There may be cases where the space and water heating is provided by a solid fuel fire, in which case, interfacing the heating system with the EIB is not such a realistic option.

Other systems that a client might want to add to a basic EIB system are security and, for clients with disabilities including age related disabilities, safety systems.  These “optional” EIB safety and security systems would not be put in place without the core EIB systems (lighting, space and water heating).  It would be neither practical nor economic in the majority of cases.  However, these optional safety and security systems are often the main motivators for installing an EIB system for clients with disabilities.  It is incidental that they also get the benefits of having the core EIB system. No purchasing authority would go to the expense of providing only a core EIB system for older or disabled people.  However, it is by including these safety and security systems and linking them into the core EIB system that the full benefits of an EIB system for elderly and disabled people can be exploited.

Furthermore, for the safe operation of any electrical system under normal and fault conditions there are a number of major devices that are required to be installed.  These are often hidden in a cupboard or roof space and are not obvious to anyone except to an electrician who would automatically include them in the engineering design of the system.  These are not insignificant cost items and could easily be included in the generic products list for a standard baseline system.

In conclusion, the majority of the components of an EIB system for a person with disabilities will be the same irrespective of their degree or character of disability. Only a minority of the hardware components (some of them are major cost items) will differ for individual cases and these will be in the following areas:

• User interface with system

• Door entry system

• Motorised control systems such as Window and Curtain controls

• Toileting and bathing requirements

• Lifts & hoists

• Safety shut down of appliances

Many of the above such as door entry system, lifts and hoists may not yet be available off the shelf in EIB compatible form but interfaces to the EIB system can be created if these are required.

The major difference between systems designed for individuals will be in the software programming of the devices i.e. the functionality of the installed system.  Two home network systems could be physically identical but function very differently.  There will be a fixed cost for programming the system no matter how small it is and the marginal cost of creating rich functionality will be a relatively small proportion of this. 

These considerations lend weight to the view that, since the physical EIB systems installed for disabled people, will be very similar to each other, with only minor differences, there is little point in going to the trouble of specifying and designing an EIB system from scratch every time.  The user of the software can start either with a basic model and add devices to it or start with a comprehensive model and remove devices.

METAPHOR FOR THE CUSTODIAN SUITE OF TOOLS

When developing a new software application for which there is not a real world equivalent the designers need some sort of model or metaphor to guide their thinking and to help explain their ideas to others.  When the Apple graphical interface was developed and later copied by Microsoft in Windows the analogy or metaphor used by the software developers was that of a desk, at which someone is writing a document and has to refer to other documents open on the desk.  At the end of each day or when the work is completed the various documents used and created are filed away in folders.  This is the familiar desktop metaphor.

The metaphor the authors conceived for the design of Smart Home Systems was the process of buying a new car from a showroom.  The customer first begins by looking in magazines or brochures or visits the showroom to compare the specifications of the type of car s/he would like.  To develop the actual specification for the particular model that is to be bought (one the customer likes and can afford) the customer starts with a basic model and adds in extras like sun-roof, power steering etc.  The customer does not go along to the show room and specify the car by selecting, engine, transmission, brakes, lights, etc from a database of components from different original equipment manufacturers.  There is no need.  The car designer and manufacturer has already done this and produced a range of fully integrated, and tested systems (models of cars) to which the customer can add optional extras.

If one were to buy cars by selecting components from a database from different original equipment manufacturers, three things are likely to happen:

1.       An important component or sub-system might be accidentally omitted from the specification (e.g. seats)

2.       The resulting specification might not be fully integrated for example a Lamborghini engine with a Morris Minor brake system. 

3.       The resulting specification might not meet standard safety or reliability specifications (the seat belt from an standard car would not meet current safety standards for a racing car).

4.       The reliability of the specification might be in doubt.

When the customer is looking at the basic model of car the customer can be confident that s/he is looking at a fully integrated and working system to which can be added a few extras without upsetting the integrity of the basic system (car).  The automated windows or sunroof of a car are unlikely to effect the performance.  When a person with disabilities or older person buys a new car, the process is exactly the same, except that the range of optional extras offered is greater: longer seat runners to make it easier to get in and out of car, hand controls instead of pedals, adapted steering wheel etc.

Using this analogy it can be seen that specifying Smart Home systems from scratch every time, as well as replicating 90% to 95% of the design every time, also runs the risk of omitting vital components and generating a specification that requires a great deal of work to integrate and might not turn out to be safe for the user.  Should this form of design be developed and installed the needs of the user might appear to have been met, but in reality the system's deficiencies will soon become clear (the Sinclair C5 is an excellent example of this principle)

DESIGN OF SMART HOME SYSTEMS

Translating the motor car metaphor to the design of Smart Home systems the authors arrived at the following proposal: the CUSTODIAN software tool presents to the elderly and/or disabled client an example of a Smart Home System. This would be a standard Smart home System.  The client will see devices allocated to rooms on a floor plan.  The software user mediates with the client, with the help of a laptop computer.  He or she is able to demonstrate the functionality of the system, remove or add devices, alter the functionality of the devices in accord with the views and wishes of the client and/ or other stakeholders.  In this way, the client and the software user mediates together produce the required list of generic products and the required functionality.

The experience of carrying out the exercise, by hand, of producing a generic products list from scratch using the ASHoRED report [2] indicates that it is possible to produce a generic products list, but this is time intensive and ultimately requires a considerable specific knowledge to ensure the list is accurate.  Conversely, starting with a fairly comprehensive baseline system (that might cover say 95% of cases) adding and subtracting any devices to meet specific requirements proved to be quicker; produced with greater confidence (since one knows that the system is fully designed and that there are no important components missing); and with greater safety and certainty.  Therefore, it was proposed that the standard Smart Home System be a comprehensive by which it is meant that it contains all the devices required but not all inclusive, by which it is meant that the functionality can still be modified and devices changed rather than a basic system.

This comprehensive specification is used in front of clients.  The software user needs to avoid building up client expectations that cannot be met due to say lack of funds.  Removing devices and functionality before the client’s eyes may lead to disillusion, demoralisation and finally disengagement from the consultation.

The use of a Standard Smart Home System with a comprehensive list of generic devices installed is an inherently fast way to generate the list of generic devices and functionality to meet a client’s specific need.  Further benefit of starting with a complete home-networked system are firstly that it will be an effective way of marketing and explaining what Home Networks can do.  Secondly, the costing of proposed systems would be much easier to calculate since one is required to only add in or take off the cost of few items.  The cost of the baseline system could also updated each year merely by applying one price inflation index factor or importing updated manufacturer databases.

The conclusion is that the use of a computer representation of a standard Smart Home System is the most realistic and efficient way of specifying an EIB system for an older person or person with disabilities.

STANDARD SMART HOME

To develop the specification for the Standard Smart Home one need look no further than the Edinvar Demonstration Flat[4].  This has a very comprehensive range of devices installed.  The Edinvar generic list contains most of the devices likely to be installed in each room covering the functional areas of safety, security, lighting (including day light control by blinds and curtains), temperature and ventilation control, operation of appliances (e.g. TV, etc).  Detailed specifications and results of user evaluations of the Edinvar Demonstration Flat have been published [4]. 

For the purposes of generating a generic list of products and a detailed functional specification the authors believe that it will not matter materially that the standard Smart Home may not have the same number, size and physical arrangement of rooms is the client’s actual or intended home.  If the client’s home is a bed-sit the sleeping, cooking and living areas will all be in one room with no physical barriers between.  Nevertheless, the safety and security requirements whilst sleeping and cooking will be very similar, if not exactly the same, to those in a flat where these areas were separated off by walls.  Where it will make a difference is in the number of devices required.  If the standard house based on the Edinvar flat proved to be inadequate for a bed-sit then a bed-sit standard home would be required to be developed.  The fact that one may need a range of standard home network systems to cover all cases does not invalidate the metaphor of new car purchase as manufacturers tend to produce a number of different models of one type of car in order to satisfy customer demand.

WAYS OF ORGANISING A STANDARD SMART HOUSE SYSTEM

In order to develop standard Smart House systems a conceptual framework was required.  The ASHoRED documentation [1] provided a useful starting point.  ASHoRED identifies the following six functional areas:

·         Entrance, hallway, elevator, stairs, garden, drive

The internal areas can be termed circulation and external for the others