Pc Ieee Trans Consumer Elect 1997 b

8/3/2019 Pc Ieee Trans Consumer Elect 1997 b

1/7

Corcoran and Desbonnet: Browser-Style Interface s to a Home Automation Network 1063

BROWSER-STYLE INTERFACESTO A HOME AUTOMATION NETWORKPeter M. Corcoran and Joe DesbonnetDept. of Electronic Engineering, University College, Galway, Ireland

Abstract - The design and implementation of a browser-style interface to a home autom ation network is described .The interface supports browsing and navigation ofnetwork devices and context structures and the user caninteract with individual devices on the network, and accessand control context and object structures within thesedevices.The interface can be used to access a local homeautomation network from a standard desktop PC, or froma TVlset-top box system with built-in interface hardware.Furthermore, as the interface is implemented usingconventional Internet and home network tech nology it canprovide access and control services to the home networkfrom any computer with an Internet connection.1. IntroductionThe Consumer Electronic Bus (CEBusB) is a multi-media LAN standard developed for home automationapplications [l]. In earlier work we discussed some ofthe issues involved in providing access to a CEBusnetwork via a conventional Web browser and Java@virtual machine JVM [2]. The aim was to demonstratethat wide-area-network (WAN) access to a local controlnetwork was practical and broadened the scope andrange of applications of home autom ation technology.However we note that the market penetration of suchtechnology has remained slow, apart from certain nicheapplications. The authors feel that this is largely due toa combination of (i) poor end-user perception of thebenefits of home netw orking and (ii) a relucta nce on thepart of consumer electronics manufacturers to take risksin applying new technology in unproven m arkets.Further. drawing on the recent example of the masspublic acceptance and, in some instances, obsessionwith the Internet, we argue that the lack of a practical,generic and readily available user-interface to homeautomation networks is a key reason for poor userperceptions and lack of market penetration. In thispaper we offer a preliminary approach to the issue ofproviding a generic user-interface suitable for the smarthome of the 2 1st century.2. Philosophy and Design IssuesIn this section we give an overview of the issuesinvolved in providing a useful, but non-trivial userinterface to a home automation network and theindividual devices which are members of the network.

2.1 End-User RequirementsIt is important that any such interface is both user-friendly and can provide generic access to the broadrange of consumer appliances found in a modernhome. This requires a degree of flexibility andinteroperability which is currently unavailable in anyof the interfaces used in, for example, the desktopcomputing market.In particular it should be noted that few home users ofsuch a system will be more than marginally computerliterate. Such users are unlikely to tolerate the situationwhich persists with computer peripherals, where everynew piece of hardware has a manufacturer-suppliedsoftware device driver which must be installed by theend-user. Thus the interface software for any newconsum er devices must not on ly be user-friendly, but itshould also be self-installing and largely self-configuring. The vast majority of home users willtolerate nothing less.2.2 The Requi rem ents ofManufacturersIn addition we note some of the needs andrequirements of the manufacturers of consumerelectronic products. Such com panies require a meansto (i) differentiate their products and to (ii) provideuser-friendly access to com plex features.It is also important that manufacturers have theflexibility to change and adapt the user interface,ideally without requiring that devices be manuallyupgraded or otherwise serviced. This is particularlyimportant where a single consumer appliance mayserve several different markets. If the usage andcomplexity of this app liance can be change d simply byloading a different user interface then the samephysical appliance may be able to serve multiplemarkets, reducing overall production costs for themanufacturer. Finally, manufacturers may be able toearn additional revenues by selling user-interface (UI)upgrades to add new operational features and enhancethe functiona lity of their applianc es.2.3 The Limitations of Consumer AppliancesIt is also noted that many consumer appliances are notyet sufficiently intelligent to support full Internetconnectivity or to present a high-end graphic userinterface (GUI) to the user. However most appliancescontain sufficient intelligence to support a product

i

Manuscript received June 18, 1997 0098 3063197 $10.00 1997 IEEE


2/7

1064 E E E Transactions on Consumer Electronics, Vol. 43, No. 4, NOVEMBER 1997

modeling scheme such as the Common ApplicationLanguage (CAI;) as defined in [ 3 ] . In fact CAL was specific U1 element for that device is loaded by thesystem.designed to meet the specific requirements of homeautomation networks. A description is also give of how several UIDevs maybe combined in a group and operate through a singleThus we do not feel that local home automationnetworks will, in the near future, be directly integratedwith broader W AN networks such as the Internet. In theopinion of the authors, a much more practical andsecure approach employs a local home gateway whichintelligently brokers network traffic and integrates thehome network with the outside world.Further, we feel that the real ben efit of such integrationwill not be an ability to remotely access the homenetwork, but rather the ability of the home network toaccess external services and resources to enhance itsow n functionality and that of the appliances connectedto it. In the context of this present work these externalresources could be complete GUI elements for eachconsumer appliance in the home.2.4 System RequirementsConsideration of the abov e issues led us to the considerin some detail the hardw are subsystems and the softwarearchitecture necessary to support the requirements ofboth end-users and appliance manufacturers. Details ofthe gateway system implementation are given in acompanion paper [4]. n this paper we focus on how th isgateway system described in 141 can provide a genericmechanism for downloading user interfaces to homeautomation devices over a WAN .In section 3 we describe how the gateway architecturesupports intelligent U1 elements which can interact withdaemon programs to send and receive CAL messages toreal network devices, & Rdevs. These U1 elements, orUIDevs, may contain their own independent CAI;generation and interpretation layers, or they may alsotake advantage of inbuilt primitives within theCALNetd daemon program. Furthermore thisarchitecture supports the creation of virtual homeautomation networks and virtual devices. It is thuspossible to create an d test, in software, complete devicestructures with related user interfaces.In section 4 we describe the practical provision of a GUIfor a simple home automation network. An overview isgiven of the actual hardware and software used in theimplementation. We also describe how the database ofdevice information contained in system memory is madeavailable to the user through a graphical browserinterface, similar in concept to a Web browser. Whendevices are accessed through this device browser a

network socket. Such group s of GUI elements providethe basis for building more complex interfacestructures and we have coined the term HiPlet, orhome-interactive programlet to describe theirfunctionality.Section 5 gives some sim ple, but practical examples ofHiPlets and their functionality is described. We thenoutline how they can interact with each other, or withreal network devices. A summary and someconclusions are then d rawn in section 6.I CEBus Network I

GU I on TVNJeb Browser

Fig: 1 Overview of System Architecture and UI3. System A rchitecture & ImplementationIn this section we briefly describe the gatewayarchitecture and how it supports intelligent UIDevswhich interact with the core system daemon, CALN etdand with external real-devices (Rdevs) and internalvirtual-devices (Vdevs).3.1 System HardwareIn its presen t implementation the system software runson a desktop PC platform, but as all of the key systemsoftware is coded in a platform independent languagethe core system elements are suitable for down-sizingand porting to the embedded hardware platforms usedfor Set-Top-Box or Web-TV appliances. The interfaceto the powerline CEBus network is through aproprietary module, but the hardware components areavailable as low-cost ICs for production purposes.


3/7

Corcoran and Desbonnet: Browser-Style Interfaces to a Home Automation Network 1065

GraphicUser Interface(o n TV or VG A screen)

Set-Top Boxor Web -TV

--------i=-lr--

I I

I[qI III /I

-eII

PI

CEB usNetwork

Fig: 2 Deta i l s of Internal Sys tem Architecture and UI Elements .

3.2 The Gateway Software DaemonsThe software architectutre of the Internet/CEBusgateway is described in detail in a companion paperBriefly a lightweight IOd daemon - represented as ahardware abstraction layer (HAL) in Fig 2 -continually monitors the traffic on a local powerlinenetwork. As devices initiate or receive messages,coded in Comm on Application Langua ge (CAL) thissystem daemon provides low-level hardwareacknowledgements and responses as required, thenpasses on the CAL messages to a big-sister daemon,CALNetd.The CALNetd daemon records the state of networkdevices in a local registry of devices. Thus stateinformation for the local CEBus network is availablewithout the need to query individual devices. It alsobrokers and routes CAL messages between the variousflavours of system devices: UIDevs, RDevs andVDevs.3.3 The Device Browser InterfaceThe user interfac e has two distinct components. Firstlythere is a graphical device browser for the local homenetwork. This browser simply shows the list ofnetwork devices registered in the local d atabase, in thesame way that file managem ent utilities show a list offiles in a local filesystem. However when a device is

~ 4 1 .

accessed in the browser the user-interface for thatdevices does not originate fro m the local system software- instead it is loaded, as a HiPlet, from an HTTP-styleuniversal resource locator (URL).

Fig: 3 The Device Brow ser showing a simple network with us t4 devices: a light-switch,a light, a keypad and a display ('listmemoy) .

3.4 Software Interfaces to Individual DevicesThis scheme allows the local InternetKEBus gateway toload user interfaces for any consumer appliances with aCEBus powerline interface and an embedded UR L


4/7

1066 IEEE Transactio ns on Consu mer Electronics, Vol. 43, No . 4, OVEMBER 1997

Furthermore it satisfies the requirements ofmanu facturers to be able to custom ize and differentiatetheir products by creating unique user interfaces andproduct features.4. Implementation of the User InterfacePrototype implementations of the user-interfaceelements describe above have been developed on alocal TCP/IP network and interfaced with a localpowerline CEBus network. The gateway isimplemented on a standard desktop PC and theinterface to the powerline network is via the RS-232port and a proprietary interface module. The PC isconnected to the TCP/IP network using standard thin-wire ethernet.In its normal mode of operation the IOd daemonprogram (HAL) monitors the local home networktraffic and provides hardware-level responses. Theactual CAL. packets are passed onto C ALN etd which,if appropriate, routes the packets to UIDevs or VDevsand records and registers new devices. It can alsoregister and interact with active virtual devices(VDevs) or user-interface devices (UIDevs). Useraccess to the registered devices is via the browserinterface shown in Fig 3 .4.1 The Network Brow serThe browser described in section 3.3 above is quite asimple implemen tation of a dev ice browser. It providesa very useful level of interface for most end-users whoonly need partial access to the complete functionalityof most network devices. However, for the purpose ofdeveloping new UIDevs, HiPlets and VDevs it wouldbe very useful to have a more flexible browser whichprovides detailed access to the comp lete CAL struc tureof network devices.

In the interests of completeness we show in Fig 4 suchan alternative browser implementation which canprovide very detailed access 10 the CAL structure of anetwork device. In addition this alternative browserimplementation is also aware of many of the standardDevice and Context structures defined in [ 3 ] . It issomewh at more so phisticated than we would ex pect tosee in a home user's system, providing access to theentire contextiobjecthstance-variable structure of aCAL, device. The fun ction of such a browser is to providean engineering tool to assist in the development anddebugging of new UIDevs and HiPlet interfaces to thehome network.4.2 User Interface Devices (UIDevs)In our implementation these user-interface elements arespecialised Java applets which are uploaded from a UR Lon a TCP/IP network and attach through a containerobject, to a network socket provided by the localCALNetd. They may also attach through a direct-interface-layer or DIL. The socket-based connectionallows the UIDev to exist at a remote IP address or in aseparate JVM, whereas the DIL req uires that it reside inthe JVM of the local gateway.Note that a UIDev can access additional systemfunctionality over that normally available through astandard TCP/IP network socket. Much of thisfunctionality is designed to support the low-levelrequirements of the local home automation network andalso to provide som e CAL related services to sim plify thedesign and testing of UIDevs. In the current systemimplementation many of these system functions are stillunder development. Some brief details of the basicCALNetd services which are currently available aregiven in section 4.4.

Fig: 4 n Enhanced D evice Browser can provide v ery detailed access to the CAL O bject Structure ofApp1ianct.sconnected to a Home Automation Network.


5/7


4.3 Home-Interactive Program lets (HiPlets)To support the development of more sophisticated U1elements we have introduced the concept of groupingUIDevs into interactive container objects known ashom e-interactive program lets, or HiPlets. This allowsseveral different network devices, or app liances to havetheir functionality combined and accessed through a

The sensor interface could equally well be a real sensordevice, such as a PIR sensor in a security system. Inou r virtual example activating the check box has thesame effect as activating the PIR sensor. This generatesa CA L report to the binary sw itch U1 which turn s on avirtual LED to indicate that the switch, which cou ld bean alarm relay, is active.single user-interface. At the same time, each device may

have its own independen t interface.Each such HiPlet attaches to a specific CALN etd socketwhich is mapped onto a local CEBus MAC address.Thus a one-to-many mapping between a single userinterface and several local network devices can beachieved.4.4 CALNetd Interface ServicesAs was mentioned above, we are still developing andexperimenting with the internal services and structuresof CALNetd. The basic services which are currentlyavailable include:

fullhiltered packet dumptx packet/tk-ack packet

0 list network devices0 list/seek de vice state info0 list/seek house state info0 lid see k context state info0 select TCPAJDP broadcast0 network statistics0 MA C binding services

5. Practical Device InterfacesIn this section the intention is to introduce some simpleHiPlet implementations which are available live on ourWebsite [ 5 ] . These are quite basic interfaces, but theydemonstrate how m ore com plex interfaces can be builtby com bining interface elements.They first example we give is the standard C EBus light-switch. In this case it is a bit different as it is a light-switch with a GUI. A more complex example is thengiven which combines a keypad HiPlet with a displaydevice HiPlet. For convenience we will show thesoftware implementation of each device, but we notethat each device can have a real-w orld equivalent whichcould just as easily substitute for the software objectmodel representing it. Thus a real CEBus keypad couldsend data to the software display HiPlet in exactly thesame way as the virtual keypad does.5.1 The Light-Switch with a GUIThis is the classic CEBus examde. In our simde

Fig S(a) The U I element fo r a basic b inaly switch.

Desc tighuwitch C

5(b) The UI elementfor a basic binay sensor.5.2 A Sample Keypad DeviceA very common U1 device is the simple numeric.keypad. These devices are found in many applications,from touch-tone phones to point-of-sale terminals. InFig 6 we show the equivalent HiPlet with a single U1context. When a key is activated this generates a CALmessage containing the value of the key depressed. Themessage will be passed on to any devices which arebound to the keypad HiPlet.

example a binary sensor is bound directly to a binaryswitch.Fig 6 The Keypa d - a single UI-context HiPlet; morecomplex HiPlet inte$aces may have multiple UI-contexts.


6/7

1068 IEEE Transactio ns on Consu mer Electronics, Vol. 43, No . 4, NOVEMBER 1997

5.3 A Display WiPlet using ListThis simulates one of the most common display devices- a simple ASCII character display. The HiPlet may bebound to any CAL source of character data.keypad is directed to the display HiPlet. A live,Internet-based, demon stration is available from [5].6. Summary and ConclusionsPrototype implementations of the user-interfaceelements described above have been developed on alocal TCPIIP network and interfaced with a localpowerline CEBus network. The gateway isimplemented on a standard desktop PC and theinterface to the powerline network is via the RS-232port and a proprietary interface module. The PC isconnected to the TCP/IP network using standard thin-wire ethernet.The most important lessons to be learned are withregard to the auto-conIiguration of U1 elements asdescribed in this paper. Briefly this is a non-trivialexercise, and it is clear that the gateway between WANFig 7A simple Display HiPlet - this is based on the ListMemovy CA L object.

5.4 Interaction Between D evices using CALIn Fig 8 below we show the basic browser described insection 3.3. This has b een used to load HiPlet interfacesto a keypad and a display device, as described insections 5.2 an d 5.3 respectively. These devices arebound to each other, so that the CAL output from the

and local control network must be quite an intelligentone, if au to-configuration is to be achieved in practice.Finally, in order to achieve a truly generic mechanismfor loading U1 elements for ho me au tomation networksit is essential that open standards be developed andpromoted in this field. As our work in this areaproceeds it is hoped to make more detailed resultsavailable through the W eb-site at [ 5 ] .

Fig: 8 The Device Browser described in 3.3 is shown with two single-context HiPlets, A Keypad and a Display.


7/7


REFERENCES[l]Hofmann, J., "The Co nsumer Electronic Bus: AnIntegrated Multi-Media LAN for the Home",

International Journal of Digital and AnalogCommunication Systems, Vol. 4, No . 2, Apr.

[2] Desbonnet, J., Corcoran P.M., and Lusted, K.,"CEBus Network Access via the World-Wide-Web", IEEE Trans. Consumer Electronics, Aug.1996.

[3 ] EIA Home Automation System (CEBus) StandardIS-60, "Common Application LanguageSpecifications", EIA , Part 8 , June 29* 1992.[4 ] Corcoran P. M. and Desbonnet, J., "SystemArchitecture and Implementation of anInternet/CEBus Gateway", ICCE '97 - IEEEConference on Consumer Electronics, Chicago I l ,Jun. 1997.

1991, pp. 77-86, 1991.

[ 5 ] "http://w"u.ucg.ie/cebus"

BiographiesPeter Corcorun received the BAI (Electronic Engineering)and BA (Maths) degrees from Trinity College Dublin in1984. He continued his studies at TCD and was aw arded aPh.D. in Electronic Engineering in 1987 for research workin the field of Dielectric Liquids. In 1986 he was appointedto a lecturship in University College Galway. He isinvolved in intemational Joint-Venture projects in bothChina and Eastern Europe. He is currently teaching on afull-time basis at University College Galway. His currentresearch interests include home automation networks,Internet technologies, embedded computing applications,and telecomm unications technologies. He is a member ofthe IEEE and a technical committee member of the IEEEConsumer E lectronics Society.Joe Desbonnet received his BSc. degree in Physics andElectronics from University College Galway in 1993. Heha s run a professional WWW site at http://www.wombat.iesince 1992. He is presently working as a ResearchAssociate at University College Galway and is a director ofWorld-Wide-Web Marketing, a Galway based Internetservices company.
http://w%22u.ucg.ie/cebushttp://w%22u.ucg.ie/cebushttp://www.wombat.ie/http://www.wombat.ie/http://w%22u.ucg.ie/cebus

Documents

Pc Ieee Trans Consumer Elect 1997 b