A configuration tool for HomeNet

Leeb, et al.: A Configuration Tool for Homenet 387

A CONFIGURATION TOOL FOR HOMENET Gunter Leeb, Ratko Posta, Gerhard H. Schildt, Maximilian Ochensthaler, and Dietmar Dietrich

Department for Automation and Institute for Computer Technology, Vienna University of Technology

{leeb, posta, schi, max}@auto.tuwien.ac.atdietrich @ict.tuwien.ac.at

The central goal of Home Information Systems, and Home Automation in general, is to provide convenient and efficient integration and interoperation among appliances in a household. The necessary software tools need to present a comfortable user interface for end-users that allows to control and maintain the system on several levels of expertise. One major aspect is the configuration of the Home System according to the user’s needs and preferences. In this paper, we present the architecture of an adaptable, expandable, network technology independent configuration tool for a Home System called HomeNet Configuration Tool (HCT) 1.

Introduction A Home System has to transport various

kinds of data and provide intercommunication among manifold devices of the household. The more flexible the Home System is, the better the services in the household can be adjusted to the individual desires of the user, and the more functionality can be automated. For coordinating and integrating services, the Home System has to provide management tools.

The research for this paper was supported by the Austrian Science Foundation (FWF) under grant P10699-OMA.

First of all, the user needs tools for monitoring, controlling, and coordinating a diversity of independent appliances connected to the Home System. This requires a new concept for consumer electronics products: The user interface should be physically independent and logically only loosely coupled to the appliance that is controlled by it.

Second, the Home System has to provide tools which allow the user to express policies and develop and test applications, often called scenarios, based on the functionality of the appliances. Appliances can be used in multiple concurrent applications. For example, a motion detector can belong to a security application as well as to a lighting application.

Finally, the user needs tools for managing the underlying network technologies. This topic is well addressed in the literature, e.g., [TAN89, HAE931. However, most existing solutions are targeted to the professional network administrator and therefore too complex for the average end-user of a Home System.

This paper presents a taxonomy of tools that support end-user interaction with Home Systems, and describes a configuration tool that allows users to specify applications using the combined functionality of appliances connected to the Home System. Our solution meets the requirements for a configuration tool as defined by [MUS92]. [KMS89] describes a similar system which is targeted to programmers and

Manuscript received June 10, 1996 0098 3063/96 $04.00 @ 1996 IEEE

388 EEE Transactions on Consumer Electronics, Vol. 42, No. 3, AUGUST 1996

which is based on a different system structure and does not consider multimedia data routing.

Problems with Existing Tools Most existing tools for Home Systems

follow guidelines and techniques traditionally used in related fields, such as process automation, building control or security

. systems, and, therefore, they do not fit the specific set of requirements of a Home System. In particular, most solutions do not support the heterogeneity and extensibility of services characteristic for a Home System. Furthermore, they usually present user interfaces that are far too complex for the end-user and require detailed knowledge about the underlying network technology.

Even the most general tools support only a particular network technology. This is a problem since network technologies are currently evolving very fast. Moreover, it is likely that future Home Systems will combine several network and communication technologies, due to the variety of services and data in a household.

Today, even the choice of the technology to control the appliances in the Home System is undecided. The highly integrated design of existing systems and the closed, proprietary network technologies (e.g., LON (Local Operating Network) [ECH92, MOT951, EIB (European Installation Bus) [ZVI92]) hinder the development towards a broad engagement in Home Systems by the industry. On the other hand, more general and open approaches, such as the EHS (European Home System) [EHS92] and the American CEBus (Consumer Electronics Bus) [EA1921 standard, have had

hardly any support and no effect in the market2 until now.

For configuration tools, we identify additional problems. Most configuration tools are dedicated to only a particular application. Usually, a system is configured once and forever by trained professionals that install the Home System. The user receives tools to control and manage a particular application but rarely tools to integrate new services later on. Moreover, in the few cases in which configuration tools are available, end-users are usually not capable of using them, since the tools require technical knowledge about the underlying network technology that most users do not possess.

Compared to computer network configuration, Home System configuration is further complicated by the heterogeneity of the appliances. In particular, it involves the coordination of appliances from different manufacturers, with different interfaces, different features and functionality, and different resources and capabilities. No standardization could eliminate this variety.

Moreover, despite many efforts, we cannot expect plug-and-play application configuration. Conventional appliances are self- contained, independent units which do not interact with other appliances. Each appliance has a clear behavior, determined by its manufacturer and, usually, well-understood by the user. In the dynamic and multifunctional context of a Home System, however, determining the default behavior of an individual appliance with respect to its interaction with a variable number of further

A consequence of this situation is a number of new standardization approaches e.g. from the VESA Home Network Committee in the USA and CEN TC 247 and CENELEC TC 105 in Europe.

Leeb, et al.: A Configuration Tool for Homenet 389

Control Mode

appliances becomes impossible. Each appliance can be used for a variety of purposes as a part of different applications. No manufacturer can anticipate how an appliance will be applied within the Home System. Therefore, in most cases, plug-and-play techniques will be too restrictive and do not provide a satisfactory solution. Instead, manual configuration, as described in [MUS92], and integration of each appliance by the user will be the rule.

For the architecture described here, we assume that the appliances are usually bought one by one and that the end-user is the installer. As a consequence, appliances are independent and the manufacturer cannot anticipate any other appliance or particular appliance functionality in the network. The configuration tool establishes information about the environment and the communication partners and defines their aggregate functionality.

In summary, heterogeneity and dynamic evolution over time clearly distinguish Home Systems from other applications of field bus and network technology in industry and commerce. Next to user-friendliness [BUT9 13, flexibility and extensibility are key requirements for a Home System tool in order to be able to exploit the potential of a Home System. Together with the Home System, the tool has to adapt and scale. In general, existing approaches lack flexibility and, therefore, they do not allow-users to take full advantage of the capabilities of a Home System.

Configuration Network Programming Mode Management Mode

Classification Tools

We identify

of Home System

four closely cooperating categories of tools that correspond to four modes of interaction with a Home System. The distinction is based on the degree of required expertise and the anticipated frequency the user needs to interact with each tool.

Mapping onto a particular Network Technology I :

Figure 1: Different kinds of tools allow the user to interact with the Home System in various modes suited to different levels of expertise and increasingly complex functionality.

The first category, called the control mode, consists of tools that allow to control individual appliances or applications remotely. In the control mode, users can observe the behavior and status of the Home System and gain an overview from a graphical representation. These tools may provide virtual appliances, e.g., functional units that do not correspond to a physical device, or they may allow users to run off-line simulations to test the system configuration.

Second, the configuration mode allows users to modify the system configuration. It supports visual articulation of the user's wishes concerning the behavior, integration and coordination of appliances, applications and the overall system. In addition, depending on available functionality, the user can specify application-specific strategies for automatic monitoring and error handling. Moreover, the tools have to detect and advertise inconsistencies, e.g., conflicting policies.

The third category, the network management mode, allows advanced users to fine-tune the peculiarities of the network technology and helps users in analyzing, manipulating or expanding the network. It allows detailed failure diagnosis, supports monitoring, error recovery and redundancy control, and controls bridges and routers. User-

3 90 IEEE Transactions on Consumer Electronics, Vol. 42, No. 3, AUGUST 1996

friendliness is essential to make such tools accepted in the home. This category includes all network technology dependent tools while the first two categories operate entirely on a transparent network.

Finally, the programming mode provides tools for writing, importing and testing program code written by the user as well as professionals. While the tools for the configuration allow the user only to combine existing functionality, this category contains a full programming environment to develop new functionality. Obviously, tools from this category require the most knowledge of the system and are least likely to be used by an average user. Nevertheless, we believe such tools need to be offered for any Home System in order to keep up with the dynamic development of such a system over time.

The presented structure is intended to make the user’s interactions with the system as efficient as possible and to minimize the required know-how for each particular task. While most users will use the control mode to control the Home System, fewer will want to adjust and modify the system, and still less people will want to deal with hardware problems or even develop programs for the system.

In the following, we concentrate on the second mode and present a configuration tool which demonstrates a possible solution to the broad requirements of a Home Systems in terms of flexibility and ergonomy.

The HomeNet Configuration Tool The HomeNet Configuration Tool (HCT)

is a manufacturer and network technology independent software package that allows end- users to specify the behavior of the system and the cooperation of appliances. Such operations are often called binding.

We define the HomeNet3 as an abstraction of a network capable of transporting any services for appliances in the household. These services operate on video, audio, computer and control data. Since the Home System has to provide control, each appliance that can receive and interpret the control datu belongs to the HomeNet. Appliance data is data which can be processed only by specific appliances (e.g., a video stream).

The HomeNet is controlled by a set of common management operations and additional special management operations for each network technology involved. This interface provides a platform for great variety applications and tools. In order to achieve network technology independence, the configuration tool operates on a higher abstraction level using common management operations which are mapping to each network technology used in the HomeNet.

Generally speaking, such a HomeNet consists of a number of independent appliances which can be controlled electronically from anywhere in the HomeNet and can exchange any kind of application data through the HomeNet.

In our model, we assume that manufacturers provide their appliances with a standardized software interface to the HomeNet. In addition, the manufacturer needs to supply information about that interface and a software module that represents the corresponding physical device. While the information, loaded into the HCT, allows the tool to represent the functionality of the appliance, the software module that belongs to the control mode, will be used as a basic remote

It is a goal of our project HomeNet Configuration Tool to present an implementation of such a HomeNet .

Leeb, et al.: A Configuration Tool for Homenet 391

user interface to the particular appliance. With this software module the user can monitor and control the appliance.

Appliances are represented graphically, and users can combine their functionality to build applications using simple visual programming techniques. The functions of each appliance are grouped together into objects. An object is the basic unit on which the configuration tool operates. Each object contains functions that belong together because of related purpose, e.g., all functions that control the tape unit of a VCR (Video Cassette Recorder); the functions that control the timer form another object. The semantics of the individual functions and the number of functions in an object are defined by the manufacturer either arbitrarily or following an agreed upon standard. In this way, our model allows for any functionality or any representation of the functionality and the strict software interfaces allow to hide technical details of the appliance from the user.

Figure 2: The user specifies the behavior of the Home System by connecting services. In this example, the user specifies that whenever she turns on the desk light, the main light will be turned off, besides the expected behavior between lights and light switches.

The big advantage of the presented model is that there is no programming (in the traditional sense) or learning of a programming language involved. The user simply chooses functionality provided by the displayed objects and connects it to other objects (see figure 2). Either the configuration tool is based on a standard or the user has to interpret the function semantics and describe her intentions with it.

For our approach, we chose a command- based configuration style in contrast to a state- based style. A state-based configuration is proposed for programming and described in more detail for the LON technology [ECH92], in the EHS standard [EHS92] and many software engineering and visual programming approaches, such as the programmer’s playground [GSM95]. In our command-based approach, each object offers a set of functions that can be called from other objects and another set of function calls that the object can generate.

While state-based configuration seems to be simpler to work with for a trained programmer, we believe that a command-based configuration is easier to understand for an average user. In general, we anticipate a simple implementation of the command-based style using a rpc-like (remote procedure call [BL092]) structure. An efficient mapping of this description onto any particular network and appliance hardware seems feasible.

The functionality of objects may be bound to particular appliance hardware (e.g. a function that reads a sensor value) or it can also be entirely software (e.g. a function that converts a value between two formats). Our model supports the integration of software objects which are location independent. Such a software object may test a condition, for example a parameter value, and based on the outcome generate one function call or another. This represents a usual ifstatement and similarly the user could get other constructs of a

392 IEEE Transactions on Consumer Electronics, Vol. 42, No. 3, AUGUST 1996

universal programming language. In our view, such objects are not intended for extensive programming but for simple adjustments. Other software objects may provide time or delay operations or state consistency checks which may activate an appropriate error handling.

Similar to software development, the configuration tool provides techniques for combining several objects into a compound object. The possibilities for an abstraction of system functionality or applications will help the user enormously in defining and understanding applications.

As an important characteristic, this tool allows to configure and route appliance information, e.g., a video stream, on virtual channels through the HomeNet. For example, a television in the HomeNet may be capable of receiving a video stream in a particular format but may not be capable of processing audio data which need to be routed to another appliance, e.g. an HiFi amplifier.

The configuration process describes the routing of information services transporting multimedia data as well as the coordination and flow of control data between appliances and, in more detail, between objects. Similar to describing the control flow and relation between objects, the user can express the flow of appliance information by point-and-click.

At a further stage, the user can describe the importance of an operation through prioritizing the services, parameterizing security features and activating additional safety features. For control communication between HomeNet nodes, it suggests means to improve communication reliability and security based on priorities and attributes. For appliance information, the configuration tool may suggest the use of data converters, if necessary.

Figure 3a: A more complicated configuration including a TV and a VCR and appliance data routing. The user describes that events generated by the switch will activate functionality in the four other objects.

Figure 3b: The figure shows the generated signal from both the switch and the VCR. The VCR sends its video and audio output to channel 1 of the home theater TV.

The configuration example in figure 3 describes an application for a small home theater. By using a switch the lights are turned off but one safety light and the VCR, which

Leeb, et al.: A Configuration Tool for Homenet 393

may be in another room, started. The video and audio is routed to the TV and the TV is automatically turned on, too. Whenever either the TV or VCR is stopped the light are turned on. Wiring such an application with traditional techniques would be very costly or even physically impossible. In a Home System with the help of the configuration tool the user can even change this application whenever she wants and simply integrate new appliances. Moreover, such an application may contain a software module (possibly a third-party product) which integrates all the functionality of this application in a particular user interface.

Besides a prototype of the presented configuration tool, we have implemented tools for the control mode as part of our project. Besides the mentioned module to control the appliance remote, our implementation assumes that the manufacturer provides an additional software module for the simulation of each appliance. This allows the user to simulate the behavior of the application off-line and to check its correctness. Other information supplied by the manufacturer will be used to convert a particular configurations into code which can be distributed into the HomeNet system and onto the appliances.

Conclusion In this paper we have identified special

requirements for Home Systems and a configuration tool, and we have presented an implementation of a flexible and network technology independent configuration tool.

HomeNet configuration inherits many techniques from other fields. The field of computer network research provides examples for off-line simulation, techniques for fault tolerance and strategies for error recovery. Furthermore, visual programming techniques (e.g., [NKM95]) have demonstrated as very useful for the comparably small-scale problems

involved in configuring a Home System. Although experiments with the presented tools look promising in terms of fast acceptance and understanding by average users a more detailed investigation of its use in practice has yet to be done.

Further research includes techniques to identify inconsistencies and errors in the particular Home System configurations prepared by the user and strategies for automatic configuration and safety checks based on service naming, type information and priorities. Furthermore, we will analyze the acceptance of command-driven configuration against state-based configuration for Home Systems.

Literature [BL092]

[BUT911

[ECH92]

[EHS92]

[EIA92]

[GSM95]

Bloomer, J.: Power Programming with RPC, O’Reilly & Assoc., 1992

Butler, D.: “The Impact of Home Bus Standards on Consumer Product Design: Addressing the Challenge for a Better User Interface”, IEEE Trans. on Consumer Electronics, Vol. 37, No.2, May 1991

ECHELON Corp.: “NEURON C Programmer’s Guide”, Palo Alto 1992

European Home System Association: “Home System Specification Release 1. 1”, ESPRIT Project 5448, March 1992

Electronic Industries Association of the U.S.: “Interim Standard Home Automation System (CEBus - Consumer Electronics Bus)”, October 1992

Goldman, K. J. ;Swaminathan, B.;McCartney, T. P.;Anderson, M. D.;Sethuraman, R.: The Programmers‘ Playground: U 0 Abstraction for User- Configurable Distributed Applications. IEEE Transactions on Software Engineering, 21 (9): 735-746, September 1995.

3 94

[HEA93]

[KMS89]

[MOT951

[MUS921

[NKM95]

[TAN891

[ZVI92]

Hegering, H.; Abeck, S.: “Integriertes Netz- und Systemmanagement” - Integrated Network and System management, Addison-Wesley Verlag, ISBN 3-89319- 508-4, 1993

Kramer, J.; Magee, J.; Sloman, M.: Constructing Distributed Systems in CONIC; IEEE Trans. On Software Engineering, Vo1.15, No. 6, pp. 663-675, 1989

Motorola: LONWORKS Technology Device Data, Motorola Literature Distribution, 1995

Muhlhauser, M.; Schill, A.: “Software Engineering fur verteilte Anwendungen” - oftware Engineering for distributed applications, Springer-Verlag, ISBN 3- 540-55412-2, 1992

Ng, K.; Kramer, J.; Magee, J. Dulay, N.; “The Software Architect’s Assistant - A Visual Environment for Distributed Programming” Proceedings of Hawaii International Conference on System Science (HICSS-28)(Software Technology Track) pp254-263, January 1995,

Tannenbaum, A.S.: Computer Networks, Prentice Hall, 2nd ed., 1989

Gebaudesystemtechnik: “Information zum Europaischen Installation-Bus (EIB)” - Building Automation: Information to the European Installation Bus, ZVEI, ZVEH Frankfurt, 2nd ed., 1992

Bibliographies Gunter Leeb was born in Vienna, Austria, in 1969. He received a Masters degree in Computer Science from the Technical University of Vienna in 1992. He is Ph.D. candidate at the Vienna University of Technology, Institute for Automation. He conducted research at the University of Illinois at Urbana-

Champaign and at the Massachusetts Institute of Technology in the USA. He is interested in Home

IEEE Transactions on Consumer Electronics, Vol. 42, No. 3, AUGUST 1996

Automation Systems design, user interface design, networks and real-time systems. He is member of the IEEE.

Ratko Posta was born in Zagreb, Croatia, in 1969. He received the Dip1.- Ing. degree from the University of Technology Vienna and. In 1994 he joined the research group at the Center of Excellence for Field Bus Systems. He is Ph.D. candidate at the Vienna University of Technology, Institute for

hnic. His research includes Intelligent

Gerhard €3. Schildt was born in Berlin, Germany, in 1942. He received his Ph.D. from Technical University of Braunschweig, Germany, in 1976 after studying Computer Science and Control Engineering. In 1988 he was appointment professor at Technical University of VienndAustria, Institute

for Automation, Department of Computer Science. His work is focused on process control, distributed systems, computer integrated manufacturing and safety techniques. He is Senior Member of IEEE since 1982.

Networks, fault tolerant methods and fieldbuses.

Maximilian Ochensthaler was born in Vienna, Austria, in 1968. He received his Master’s in Computer Science from the Vienna University of Technology in 1995. Since 1987 he works for SIEMENS AG, Austria, in the area call processing for private automated branch exchange. His research interests include

real-time programming, distributed systems, system management, networks and software engineering.

Dietmar Dietrich was born in Karlsruhe, Germany, in 1945. He received his Ph.D. from University of Berlin in 1981. He became professor of computer technology at the ICT (Institute for Computer Technology) at the Vienna Technical University in 1992. He focused his research on

bussystems (especially, on fieldbussystems) and on ASIC design. He is engaged in different user groups for PROFIBUS and LON and their working groups, also in the OVE and delegate in CEN and CENELEC.