An Integral and Networked Home Automation Solution for...

66 PERVASIVEcomputing Published by the IEEE CS n1536-1268/10/$26.00©2010IEEE

H O M E A U T O M A T I O N T E C H N O L O G I E S

K nowledge is limited about what home automation (or domotics) really is. People usually under-stand this concept as “a set of expensive gadgets that makes

the house smart,” and many people think that domotics isn’t essential. They probably were right some years ago, but perhaps an updated, complete explanation of what new technolo-gies and home automation systems can offer might persuade them. Initial solutions that turned on lights when the inhabitants were

present have given way to automated systems that can control most appliances, win-dows, lighting, blinds, and locks—and, what’s ever more frequently demanded, can monitor the house state.

The primary fields in which home automation is applied are security, en-tertainment, energy-efficient appliances, heat-ing and air conditioning, e-health, and remote controls.1 Such systems’ potential customers are working adults who need to save time, an aging population that needs assistance, and users wanting remote control of the house. Thus, the number of services and variety of clients make adapting commercial solutions a challenge. Such adaptation must also account for the system’s usefulness in the target en-vironment. The boundary between a system

that helps users with daily tasks, and one that performs undesired automatic actions, can be narrow.2 And this is why it’s necessary to iden-tify user requirements for home automation solutions. User requirements generally fall into the following groups:

• Efficient automation of routine tasks.• Security of automation systems.• Ease of use.• Local and remote access.• Telemonitoring.• System cost and flexibility.

Perhaps obviating the previous require-ments, the domotics world has been immersed in a competition of communication standards and specifications since the early 1990s.3 Nowadays, in Europe at least, wired domotics protocols are more established, and EIB (Euro-pean Installation Bus) and its successor KNX (www.knx.org) appear to be the most-used specification; however, as with these compet-ing specifications, a similar problem has re-cently arisen in the wireless communication technologies field due to continual advances in in-home networking. Apart from initial radio-based solutions and the more recent Bluetooth, new wireless communication technologies are suitable for home automation.4 ZigBee (www.zigbee.org) and Z-Wave (www.z-wave.com) are competing to become the in-home net-

A new home automation system improves on existing technologies by considering user requirements and addressing integration and deployment issues.

Miguel A. Zamora-Izquierdo, José Santa, and Antonio F. Gómez-SkarmetaUniversity of Murcia

An Integral and Networked Home Automation Solution for Indoor Ambient Intelligence

OCTOBER–DECEMBER2010 PERVASIVEcomputing 67

working reference of future houses. The solution we present in this article uses EIB and ZigBee as main technol-ogies to communicate with in-home appliances, but proposes an IP-based communication protocol between the

house’s main controller (home auto-mation module) and the rest of the lo-cal embedded computers and remote equipment. (For information on other projects, see the “Related Work in Home Automation” sidebar.)

The DOMOSEC ArchitectureThe DOMOSEC (Domotics and Secu-rity) platform offers a home automa-tion solution that covers current and future necessities in indoor domot-ics. It avoids a tight dependence on

U ntilnow,themostcommondesignapproximationin

homeautomationhasbeenconsideringuserneedsand

currenttechnologiestodeployadhocsolutions.Thishasled

tosystems thataretootechnologydependent,eveninthe

researchworld.Abdul-RahmanAl-AliandMohammadAl-Rousan

describeahomeautomationsystembasedonanInternet-

accessibleserver.1ThishostsaJavaapplicationthatmanagesa

setofdigitalI/Olinesconnectedtosomeappliances.AliZiya

AlkarandUmitBuhurdescribeasimilarsolution.2However,their

system communicateswithappliancesusingaradiofrequency

linkandanonstandardmanagementprotocol.Thisrequires

slavenodes,whichsupporttheprotocolsovertheRFlink,tobe

deployedinthehouseandwiredtoappliances.Ourwork,apart

fromsupportingdigitalI/O(andotherinheritedcommunication

technologies),iscompliantwithstandardizeddomoticsproto-

cols.RenatoCaleira’sworkfocusesonspecificationofthelogical

modelofthehouseandappliancestoimplement“if/then”sen-

tencestomanagethedevices.3Althoughthegatewayhasbeen

developed,theworkdoesn’tintegrateitinacompleteautoma-

tionsolution.Furthermore,anotherissuethatclearlydifferenti-

atesourworkistheintegrationofcriticalautomationtasksina

PC-basedgateway.Webetonahigh-reliabilitysolutionbased

onanembeddedhomeautomationunitinstead.

Inpreviouswork,researcherstrytosolvescalabilityissuesand

alsoofferremotemanagementcapabilitiesthroughtheInternet.

Thepreviousworksfocusmainlyonthehomeautomationunit,

highlylinkedtoaWeb-basedgateway.However,therearemore

elementstoconsiderinanintegralhomeautomationsolution.

OursolutionalsohasasuitableHMI(human-machineinterface),

notonlybymeansofagatewaybutalsousinglocalcontrolpan-

els.Likewise,acompletesecuritysystemforthehouseinvolves

communicationwithmoreentities,suchasthelocalsecurity

staffandthesecuritycompany.Moreover,currentsolutionshave

anoticeablyinsufficientsecuritytreatmentforIP-basedcommu-

nications.Ourplatformcoversthisbymeansofsecurecommuni-

cationchannels.

Aconceptthat’sgraduallygainingimportanceisambientin-

telligence.Thisidea’spenetrationinhomeautomationisever

moreevidentintheliterature,andproposalsthatoffercontext-

awarenessandubiquitycapabilitiesarebeingintroducedonthe

automationbasistoprovidehouseswithrealintelligence.4This

workadaptsambientintelligenceconceptstothespecialcase

ofassistedlivingsystems—afieldinwhichourplatformhasalso

beenappliedsuccessfully.5SumiHelalandhiscoauthorspres-

entaresearchprojectinwhichahousehasbeenautomatedto

offerpervasiveservicestoinhabitants.6Althoughtheypropose

interestingubiquitousservices,thewidedeploymentofsen-

sors,actuators,andapervasivemiddlewarepreventsthemfrom

properlyconsideringthesystem’sreliability.Thus,servicesare

offeredviaasoftwaregateway,whichcommunicateswithde-

ployeddevicesusingRF.Inaddition,theprojectdidn’tconsider

thehouse’ssecurityortheremotemanagementandmonitoring.

Instead, supportfortheseservicescomesfromthenetworked

homeplatformpresentedbyApostolosMelionesandhiscol-

leagues.7Althoughthisworkonlyincludesthearchitecture’s

logicalmodel,anditfocusesspecificallyonUPnP(UniversalPlug

andPlay),thesolution’sfunctionalitiesaresimilartooursolu-

tion’sfunctionalities.

REFERENCES

1. A.R.Al-AliandM.Al-Rousan,“Java-BasedHomeAutomationSys-tem,”IEEE Trans. Consumer Electronics,vol.50,no.2,2004,pp.498–504.

2. A.Z.AlkarandU.Buhur,“AnInternetBasedWirelessHomeAutoma-tionSystemforMultifunctionalDevices,”IEEE Trans. Consumer Elec-tronics,vol.51,no.4,2005,pp.1169–1174.

3. R.J.Caleira,“AWeb-BasedApproachtotheSpecificationandPro-grammingofHomeAutomationSystems,”Proc. 12th IEEE Mediterra-nean Electrotechnical Conf.,IEEEPress,2004,pp.693–696.

4. J.Nehmeretal.,“LivingAssistanceSystems:AnAmbientIntelligenceApproach,”Proc. ACM Int’l Conf. Software Eng.,ACMPress,2006,pp.43–50.

5. A.J.Jara,M.A.Zamora,andA.G.Skarmeta,“AWearableSystemforTelemonitoringandTeleassistanceofPatientswithIntegrationofSo-lutionsfromChronobiologyforPredictionofIllness,”Ambient Intel-ligence Perspectives,IOSPress,2008,p.221.

6. S.Helaletal.,“TheGatorTechSmartHouse:AProgrammablePerva-siveSpace,”Computer,vol.38,no.3,2005,pp.50–60.

7. D.Melionesetal.,“AContextAwareConnectedHomePlatformforPervasiveApplications,”Proc. 2nd IEEE Int’l Conf. Self-Adaptive and Self-Organizing Systems Workshops,IEEEPress,2008,pp.120–125.

Related Work in Home Automation

68 PERVASIVEcomputing www.computer.org/pervasive

HOME AUTOMATION TECHNOLOGIES

technologies, but considers successful experiences and proposes innovative subsystems thanks to an analysis, de-sign, implementation, and deployment of an entire home automation, man-agement, and monitoring architecture. The underlying architecture provides common domotic capabilities while still accounting for the design of an in-tegral platform to offer novel pervasive services.

Figure 1 shows DOMOSEC’s com-plete architecture, which includes the in-home system, supporting security in-frastructure, and homeowner remote-access subsystem. External entities communicate with in-home subsystems via the Internet. DOMOSEC provides two external connection methods. First, the local gateway lets homeown-ers monitor and manage their houses using an authenticated HTTP (Web-based) channel. Second, the home au-tomation module communicates with security modules and remote gateways using a secure User Datagram Protocol (UDP).

Although the diagram in Figure 1 considers all possible elements of a complete configuration for automat-ing a building, the system is completely modular, and only the home automa-

tion module is mandatory. Moreover, the system’s generic nature lets us apply the automation architecture not only in houses, but also in offices, schools, shopping centers, hospitals, resorts, and any other domain where domotics and indoor automation occur.

Home Monitoring and ControlThe architecture’s main element is the home automation module (HAM), which consists of an embedded com-puter that’s connected with all appli-ances, sensors, and actuators. In this way, the HAM centralizes the house’s “intelligence,” because it contains the configuration used to control all in-stalled devices.

The HAM includes an optional human-machine interface (HMI). In addition, several control panels can be spread throughout the house to control specific parts of the build-ing. These include an embedded so-lution with an HMI adapted to the controlled devices. For example, in a three-story office building, each floor could have a control panel set to au-tomatically open windows, turn the air conditioning to the desired tem-perature, or open and close the blinds according to the desired light inten-

sity before using artificial lighting. These examples are developed case studies that diminish the power con-sumption and contribute to environ-mental preservation.

The local gateway offers value-added services for managing and monitoring tasks, but it doesn’t directly control ap-pliances or actuators. Instead, this gate-way communicates with the HAM us-ing a UDP-based protocol. Some other solutions leave these tasks to a PC-based gateway, which we consider inap-propriate. A research project by Paolo Pellegrino, Dario Bonino, and Fulvio Corno uses a software implementation of a gateway as an automation station, which is executed over a common PC/Java platform.5 The embedded solution we use in HAM offers a fault-tolerant architecture and ensures that devices are operating correctly. Our architec-ture uses a PC-based gateway to give users extra services and perform net-working tasks from the transport to the application layer in the OSI (open systems interconnection) stack, as de-scribed by Frank den Hartog and his colleagues.6 We use the OSGi (Open Services Gateway initiative) framework in the gateway to manage the life cycle of services that cover these features. Thus, a service that implements the underlying UDP protocol to connect with the HAM enables the implemen-tation of more complex applications; and the HTTP service that the OSGi framework offers is used by a Web

Internet

Security company

Alarm control center

Public switched telephone network alarm proxy

Cellular network alarm proxy

Wired alarm proxy

Homeautomation

module

Controlpanel 1

LAN Control

panel NLocal

gateway

IP cameras

ZigBeeEIB

X10Controllerarea network(CAN)

CAN nodes

Devices andappliances



Homeowner remote access Local security center

Remote gateway

Figure 1. DOMOSEC’s overall home automation system. The in-home platform, which integrates several domotics technologies, connects with remote security providers and homeowners through the Internet, via secure and efficient communication protocols. Inherited home automation technologies, such as a telephone-based connection with a security company, combine with new remote and local capabilities toward indoor ambient intelligence.


application to provide local and remote management capabilities through a 3D interface. In addition, the homeowner can also use an SMS-based remote con-trol strategy if the wired Internet access is out of service.

In-Home NetworkingTo date, most efforts in designing novel communication protocols in home au-tomation have focused on communica-tion between a home automation con-troller and appliances. In one project, for instance, a bus-based protocol is defined over the power line.7 DOMO-SEC, on the contrary, bets on current specifications to connect the HAM with appliances and the remaining de-vices, and it proposes a novel commu-nication protocol that connects the ar-chitecture’s IP-based elements through UDP. IP-based elements are consid-ered the local gateway; control panels and architectural elements outside the house are the remote gateway.

The HAM supports several commu-nication controllers to connect with many devices. By complementing the direct digital and analog I/O with com-mon wiring, we can use a CAN (con-troller area network) bus to extend the operation range or provide a more dis-tributed wiring solution. X10 connec-tions over the power line are also avail-able for low-cost domotics installations, whereas the EIB controller offers a pow-erful solution for connecting with more complex appliances. ZigBee and Blue-tooth can help avoid wiring in already built houses, for instance.

We use a LAN installation in the house to connect all IP-based ele-ments with the HAM. We’ve been us-ing Ethernet, but we’re also consider-ing 802.11i for future installations where wireless LAN communications are preferable. The in-home network connects to the Internet via a nonfixed communication technology. Common ADSL (Asymmetric Digital Subscriber Line), ISDN (Integrated Services Digi-tal Network), or cable-modem connec-tions could be enough to offer remote

monitoring and management and a ba-sic security system.

The Superior Home Automation ProtocolWe propose the Superior Home Au-tomation Protocol (SHAP) to connect a home automation system’s IP-based components over an IP network. In our architecture, it connects the HAM with the in-home and remote IP-based enti-ties, following a sliding window strat-egy with UDP packets to ensure the data flow control.

Management messages are sent from control panels or gateways to the HAM using SHAP. Moreover, SHAP includes a set of messages that flash the microcontroller code memory remotely. We’ve developed an application that performs this task, which also lets spe-cialists update the HAM firmware us-ing a local Ethernet connection or the Internet. This makes it possible to re-duce maintenance costs.

Because home networks accessed from the outside imply several secu-

rity issues,8 SHAP implements an ap-proach based on symmetric cryptogra-phy and hash algorithms to ensure the authenticity and integrity of messages transmitted. Confidentiality isn’t di-rectly provided for the packet payload because encryption is supposed to be included only in desired messages. For example, applying encryption to the payload is unnecessary for memory map messages when the HAM memory is flashed; decoding all packets would delay the process. Alarm messages, on the other hand, can offer encryption by themselves. At the service level, a secure HTTP access offers confidentiality. In the same way, an authentication stage executed at the beginning of the session

authorizes remote clients to access the 3D monitoring application.

Configuration Data DistributionThe HAM is in charge of maintaining the house configuration’s main data-base, and it uses a local nonvolatile memory for this purpose. This data-base also saves the actions to be ex-ecuted according to periodic or pro-grammed tasks or sensor-dependent conditions. In addition, each control panel and the local gateway include a local database synchronized with the main one to avoid overloading the net-work. In this way, users can perform changes in the operation of automated devices using control panels, but these modifications are reflected in the inter-face only when they receive the confir-mation of the action from the HAM. This communication occurs by using SHAP messages and ensures consis-tency of local databases. Communi-cation between local and remote gate-ways with the HAM follows the same strategy. The database stored in the

remote gateway is a part of the whole house state as well, because it’s only related to security sensors. However, the database maintained in the local gateway is a complete copy of the one stored in the HAM’s nonvolatile mem-ory, because it includes management capabilities that comprise complete control over the house.

Securing the HouseOwing to the relevance of safety ser-vices in home automation systems, DOMOSEC includes an integrated se-curity system. It uses local sensors con-nected to the HAM (such as presence, noise, and door opening detectors) as inputs for the security system. As

DOMOSECproposesanovelcommunication

protocolthatconnectsthearchitecture’s

IP-basedelementsthroughUDP.



Figure 1 shows, several entities, called alarm proxies, receive security events from houses. These proxies are logical entities (that is, software) that run on servers located at the security supplier. Although this security model isn’t part of any standard or specification, it’s common in the systems that security companies use. DOMOSEC interfaces with the software installed at the secu-rity company, called the alarm control center in Figure 1. The alarm proxies forward all security events they receive to the alarm control center using stan-

dardized alarm messages.Several types of alarm proxies ex-

ist. Recently, security suppliers have introduced wired alarm proxies using a common Internet access as a substi-tute for the common public switched telephone network (PSTN) connec-tion. Our platform supports these two communication links and also cellular networks (CNs). The CN-based solu-tion requires a modem in the HAM; the CN operator offers direct Internet access. Internet-based alarm prox-ies receive security notifications via alarm messages defined in SHAP. The PSTN connection—the most com-mon among security companies—uses a tone-based codification to send security events. Our architecture can combine these three types of alarm proxies, and in fact, we can include more than one of the same type to of-fer extended reliability. Alarm events are simultaneously notified through all available alarm proxies, and a “keep alive” strategy is employed to receive periodic messages from the HAM. This mechanism prevents an attacker from blocking the security channel without being detected.

Security companies usually process

the payload of alarm messages by fol-lowing a standardized format. Our system supports Ademco Contact ID, but we’re extending it to support other message formats, such as 4+2. At the connection stage, the HAM negoti-ates the message format to be used in further security notifications with alarm proxies. This handshake is part of SHAP. The alarm proxy initiates the process and, after receiving a set of message formats supported by the HAM, replies with the selected one.

In cases of administrative domains

(such as housing developments) that include automated houses, a local staff could perform monitoring and security tasks in a centralized man-ner. For this purpose, the architecture includes a remote gateway, which re-ceives security events from houses. This could be a cost-efficient and pref-erable option for small- or medium-sized administrative domains, instead of using local gateways. The remote gateway contains a modified version of the software installed on local gateways, so it can connect with indi-vidual HAMs and attend to security events from all controlled houses. In some configurations, the remote gate-way could reside in the same IP net-work as controlled houses, but Figure 1 shows the general case.

System DevelopmentWe’ve developed the DOMOSEC com-ponents described in the previous sec-tion. All prototypes we present here are part of a real system deployment in a test bed house, although we show some hardware components out of their installation point to simplify the explanation. Application screenshots comprise real usage scenarios.

Home Automation ModuleWe based the HAM on the SIROCO (System for Integral Control and Com-munications) hardware architecture, designed at the University of Murcia for remote automation. Figure 2 shows the modules that comprise the unit. SIROCO is a modular system that’s highly adaptable and compliant with current regulations (EN-50131 and EN-50136). Related works in the lit-erature often plump for too simple and nonflexible architectures. For exam-ple, an automation module designed by Juing-Huei Su, Chyi-Shyong Lee, and Wei-Chen Wu offers an embedded solu-tion with basic I/O capabilities, which needs the support of external PC soft-ware.9 On the contrary, SIROCO has a self-sufficient platform to perform management and monitoring tasks. It offers the option of installing a low-cost solution or a complex one, extend-ing the base system with the required modules.

The heart of the HAM system is a 32-bit ARM microcontroller. The MPU (main processor unit) board has basic I/O capabilities through common serial and parallel interfaces, and an Ethernet connection to the IP network. The MPU board is the basis of both the HAM and control panels, and the dis-play is connected by a serial interface. The HAM, however, has more commu-nication capabilities. The X10 module, connected through a serial interface, and an EIB controller, integrated in the MPU board, provide specific domot-ics communications. The user inter-face (if needed) is a 5.6" color touch screen. Alternatively, we can integrate a low-cost user interface by using a 16- button touch pad plus a character LCD. The MPU board is extended with two additional boards: the communication and the I/O boards.

The main I/O board provides ex-tra wired interfaces with appliances, sensors, and actuators and supports up to 16 lateral I /O boards. With this configuration, users can tackle complex control schemes. The com-

Thealarmproxiesforwardallsecurityevents

theyreceivetothealarmcontrolcenterusing

standardizedalarmmessages.


munication board is equipped with ZigBee and Bluetooth interfaces and an extra wired connection through the CAN bus. Moreover, small CAN node boards with dimmers and addi-

tional remote I/O have been developed to provide connectivity with a range of home automation devices (such as lights and shutters). The CAN bus of-fers an alternative to EIB for when us-

ers need a more flexible communica-tion channel with wired sensors (not necessarily EIB compliant). Finally, a cellular modem (GSM/GPRS/UMTS) and a phone interface (DTMF) send

Home automation module

MPU board

CPU X10

CAN I/O nodes

CAN node1

Additional I/O

Ethernet

Main I/O board

Digital inputs Analog inputs Relay outputs

Display EIB Serial

Communication board

Cellular Phone

ZigBee/Bluetooth

CAN

Complementary I/O module

Lateral I/O board16


Lateral I/O board1


CAN nodenAdditional I/O

External control panel

User interface

Touch LCDn

User interface

Touch LCD1

Figure 2. Logical diagram of the home automation module (HAM) and its communication capabilities. The base HAM architecture supports several domotics standards and communication technologies, but it can be easily extended by additional I/O modules and distributed CAN (controller area network) modules. A graphical user interface can be provided in the HAM, by control panels distributed in the house, or both.

(b)(a)

Figure 3. Prototype of the home automation module: (a) the HAM installed in the test bed house, with the graphical interface powered by a touch screen and (b) boards and electronics of the prototype, showing the different digital and analog I/O lines and a battery to support power cuts.



security events to alarm proxies.Figure 3 shows a HAM with HMI

capabilities, using the touch screen. This HAM has been installed on the back of the main entrance of the proto-type house, near the electric panel, as shown in Figure 3a. Figure 3b shows in detail the HAM prototype’s elec-tronic components. On the left part, the main I/O board is fixed on the base of the plastic casing, connected to the MPU board located above it. The communication board would be connected above the latter, but it has been removed for clarity. The rest of the hardware consists of the battery, provided to prevent system failures in

power cuts; the power supply, near the top part of the battery; and, finally, an X10 module on the right.

Control PanelsControl panels are based on the SIROCO architecture’s MPU board. They guarantee a familiar HMI, equiv-alent to that offered by the LCD-based HAM but limited to automated devices in the surroundings. Users can define configuration profiles, which contain a set of device states and actions to be performed under certain conditions. Users can save these using illustrative names, such as “At work” or “Sleep-ing.” Moreover, the house alarm can be

armed and disarmed by a defined con-trol panel. Any panel, however, can be used to activate panic, security, or fire alarms at any time. When an alarm is activated by the HAM (due to sensor measurements) or manually, control panels warn users via acoustic and vi-sual messages.

Figure 4 shows the prototypes of de-veloped control panels. Figure 4a shows two versions, one based on a touch pad screen and the other mounted with a button pad and a character LCD. We’ve recently replaced the latter with the touch pad version in the prototype house (see Figure 4b). In this case, the user is modifying the lighting intensity

(b)(a)

(d)(c)

Figure 4. Control panel prototypes: (a) control panels with touch screen and button pad interfaces, (b) control panel installed in the test bed house, (c) touch pad version of the control panel software, and (d) control panel for an energy-efficient building.


in the living room, where the control panel is installed. Figure 4c shows a screenshot of the graphical applica-tion included in the touch pad-based control panel. The user is reviewing the configuration of the house’s blinds and awnings. Two blinds are used; the first has been set to close and open automatically, depending on lighting conditions, whereas the second has been programmed to close and open at different times of the day. Currently, they are opened at 50 percent and 60 percent, respectively. Another version of this application is available for PDA platforms, to allow in-home control over a wireless network. Finally, Figure 4d illustrates another control panel de-signed for an energy-efficient building.

House Setup SoftwareThe setup application lets specialists access the house configuration locally or remotely by connecting with the HAM. The application can use a UDP/IP access, via SHAP, or a direct serial connection with the HAM. Figure 5 shows a screenshot of the application while we were establishing the keys to be used in the communication with the HAM. The software also monitors X10, EIB, and UDP communications with the HAM.

The software enables the installer to configure the different partitions and zones of the security system, set the de-vices connected to the system, and de-fine the remote accesses allowed from outside. The HAM database stores all this information. The HMI allows the installation of initial profiles and ac-tions to be performed under certain events detected by sensors. Specialists can save all settings for application to other houses.

Home Management Application for Local and Remote AccessIn addition to control panels and the optional HMI of the HAM, a local and remote management application offers users monitoring and control capabili-ties over the house. This application is

hosted in an HTTP server at the local gateway. It includes a Flash program that’s downloaded from the server to the client machine and gives an ex-tended view of the whole house.

By using this application, the home-owner has a 3D view of the house and can manage the automation system as if he or she were at home. We used an IP camera in the prototype house to of-fer real-time video monitoring of the house. Figure 6a shows a screenshot of the application, where we’re check-ing the state of the living room. This screenshot also shows the 3D map of the house. In Figure 6b, the user has rotated the view and is modifying the lighting configuration to automatically activate when the sunlight is poor.

The application has been designed as module-based software, using graphi-cal plug-ins for the desired parts of the house. Technical staff will be in charge of creating such modules according to house specifications. This task would

be performed only once in the case of blocks of houses. Configuration of de-vices installed in the house is dynami-cally requested from the same local gateway, which maintains a local copy of the house settings. Thus, for exam-ple, the software can access the IP cam-eras using the URL provided by the lo-cal gateway.

We’ve designed a variant of this ap-plication, with security capabilities, for installation on remote gateways. Using this software, security staff in resorts or housing developments can monitor all automated houses. This version of the Flash application centralizes the re-ception of alarms from houses and in-cludes basic features to control certain devices, such as the hall lighting, secu-rity sensors, and audible alarms. This scheme reduces the price of system de-ployment for low-cost installations be-cause users can leave monitoring tasks to security staff, rendering local gate-ways unnecessary, for example.

Figure 5. Screenshot of the house local/remote setup software. Specialists can use this application to program the HAM and replicate the configuration on other HAMs. Moreover, it allows monitoring of in-home communications, with control panels and connections from outside, such as remote gateways or security centers.



ExperienceWe deployed DOMOSEC exten-sively in varied settings. Here, we present our main case study of a prototype house and lessons learned from our development and deployment work.

Prototype HouseFigure 7 shows a diagram of the test bed house, including the deployment of DOMOSEC’s most relevant sensors, actuators, automated appliances, and management devices. Using a set of au-tomated switches, the HAM can con-trol appliances located in the kitchen. It can also control the intensity of the lighting independently for each room. The security system uses presence sen-sors and a robotic camera to receive information about the house’s status. As the figure shows, we’ve installed the HAM at the entrance and a con-trol panel in the living room. Whereas the HAM’s HMI offers management capabilities over the whole house, the control panel focuses specifically on the living room’s automation capabili-ties. Among these features, the HMI performs smart management of the lighting to automatically adjust its in-

tensity, and of the position of blinds and awnings, according to natural light. We’ve included a PC-based local gateway in the test bed, connected to an LCD television. This gateway also hosts the 3D management software, which lets the homeowner access the house remotely. The user can adapt the house’s temperature to his or her pref-erences, automatically switching on and off the centralized air condition-ing and the heating. The HAM moni-tors power consumption, thanks to the adaptation of the electric panel.

Regarding the communication pro-tocols that connect the various devices with the HAM, we’ve covered a wide spectrum of the supported standards. We installed three inherited X10 switches, connected to the power line, in the kitchen. We used EIB for com-municating with the presence sensors installed in all rooms. Nevertheless, the communication technology we used most is CAN. The lighting, heat-ing, automated blinds and awnings, and light sensors are connected in this way, deploying CAN nodes in the house. Finally, we used a serial com-munication to connect the electric panel and the air conditioning with the

HAM, using RS-485. IP-based devices connect to the in-home network using Ethernet. These devices comprise the local gateway, the control panel, and the IP camera.

Because most of the sensors are wired with the HAM, we’ve found it useful to consider DOMOSEC when building the house. Devices installed during the system exploitation—which can’t easily connect to the de-ployed communication infrastructure (CAN, EIB, or common I/O lines) or the Ethernet network—can use a Zig-Bee or Bluetooth link. We’ve installed some temperature sensors in this way, for example, using ZigBee’s home au-tomation profile.

We’ve also deployed the security sys-tem, supporting PSTN, cellular net-work, and wired alarm proxies. So, a security company needs only to include this software middleware in its system. For the wired connectivity, which is also used in the remote access, we’ve used a common ISDN link. The secu-rity middleware has been integrated in a security company’s information system. All the proxies have been in-stalled at the company offices, and we’ve successfully tested a wide set of

(b)(a)

Figure 6. Flash application with 3D HMI for local and remote management. (a) Overall house view and (b) setting up the lighting of the living room.


scenarios. Thus, we have intentionally blocked one or two communication channels to check the system opera-tion. Alarm messages, formatted using Ademco Contact ID, were correctly decoded by the private security soft-ware in all scenarios when at least one of the three security channels (PSTN, cellular, or wire) was available.

Lessons LearnedDuring the recent years of improving DOMOSEC from a simple automation node to the current platform, we’ve identified the necessity of migrating from proprietary designs to open plat-forms. In this sense, common digital I/O wires have given way to EIB and CAN, for instance. A problem we’re facing is the transition from stand-alone displays to panel PCs. These de-vices are decreasing in price in contrast to the high cost of independent touch screens, and they offer a more power-ful platform to develop friendly inter-faces. In the same way, the HAM’s core processor has evolved from a low-end PIC to a 32-bit ARM. At the moment, we’re evaluating several x86 and new ARM processors to migrate to a HAM that’s based on an embedded operating system, such as Familiar Linux. In our experience, it’s important to choose a robust processor with a secure manu-facturer support, because ours will be discontinued soon, and this implies several maintenance problems.

Our work has aimed to find a use-ful and efficient solution for the archi-tecture’s remote components. In that sense, we identified the alarm control

center as a key element to ensure the correct reception of security events. Al-though we installed the early versions of this software in high- performance servers, we experienced some nonre-coverable message losses when testing the system in highly stressful condi-tions (in the order of 1,000 houses be-ing controlled and notifying security events). For this reason, we created two new software entities: the reception and attendance units. The reception unit only quickly preprocesses security notifications, then passes the event to the attendance unit, which processes the entire event, and finally passes it to the alarm control center. Although only a back-end system exists—in this case, the alarm control center—both the reception and attendance units can be replicated, if needed, among dif-ferent servers. This idea is being ap-plied to remote gateways as well, be-cause they could be in charge of many houses or houses with many (security) sensors. Moreover, to improve moni-toring and management tasks in such schemes, our next step is to develop complementary SCADA (Supervisory Control and Data Acquisition) soft-ware—which is not as pretty as the 3D application, but is more practical for security staff. Whereas Flash is a pro-prietary platform, our SCADA soft-ware will be based on Java and Web functionalities.

When we started deploying

DOMOSEC in the prototype house, we faced several problems that we didn’t identify at previous stages. One of the most important complications was in-tegrating DOMOSEC with the electri-cal system. Apart from the extra con-nections needed for the HAM and the control panel, sensors and actuators also need a power supply. Moreover, because we manage the light intensity independently for each room of the house, we must adapt lighting circuits and wiring. To install components, we had to redesign the cases to hold all necessary digital I/O wires, serial inter-faces, Ethernet, and so on. In any case, the system’s modular nature has been one of our major successes. Distribut-ing capabilities among the different platform elements hasn’t diminished the system’s robustness, and from the early stages, the communication among components has worked properly.

Because the installation phase im-plies several tricky tasks, we’ve iden-tified a testing protocol to ensure the system is operating properly. For au-tomation platforms as distributed and integrated as DOMOSEC, it’s difficult to ensure that everything is set up cor-rectly. The subsystems that we must check, in order of preference, are

• power supply for all devices,• local digital I/O lines with HAM(s),• communications via CAN bus and

X10,

Automatic switches

Smart lighting

Presencesensors

HAM

Powermonitoring

Controlledair conditioning

Temperaturesensors

Local gateway

Control panel

Robotic camera

Lighting sensors

Automated blindsAutomated awnings

Figure 7. The prototype house used as a test bed of DOMOSEC, along with the system’s various sensors, actuators, and architecture elements. The home automation module is installed near the entrance, but a control panel provides management capabilities for the living room and a local gateway connected to the LCD television gives further graphical capabilities.



• serial communications,• EIB communications,• ZigBee and Bluetooth communi-

cations,• IP in-home communications via

Ethernet,• IP remote communications via

Internet,• PSTN communications,• software configuration of HAM(s),• hierarchical communication of

HAMs (when more than one is considered),

• software configuration of control panels,

• communications between gateways

and HAM(s), and• testing scenarios.

Most critical devices are checked first; so, we attend to the set of sen-sors, appliances, and actuators and their connection with the HAM in first stages. Apart from this manual check, we’ve envisaged the implemen-tation of self-checking software at the HAM and gateways, with the aim of making the installation phase easier. This middleware would also be useful to improve maintenance tasks and en-sure the platform’s robustness after the installation.

Other Study CasesDOMOSEC has been applied in more environments, exploiting its potential in other ambient intelligence scenarios. Here, we briefly introduce the most sig-nificant ones.

GreenhousesA parallel research project at the Uni-versity of Murcia applied DOMO-SEC to automating greenhouses. The system’s main objective lies in saving

ventilating and lighting resources. By processing information received from temperature, humidity, and light sensors, we can control several auto-mated parts of the greenhouse, such as windows, lighting, and cooling/heating systems. In this way, we can save power consumption and exploit natural resources.

Elderly AdaptationElderly people are potential system users, so several of our research lines aim to facilitate the control and man-agement of the house. We’re develop-ing an intelligent remote control, for

example, to learn current configura-tions of nearby devices and save reus-able profiles. These remote controls can manage the closest device fol-lowing a friendly design that includes only the most necessary buttons. In this manner, the user can open and close the blinds, adjust the air condi-tioning, or open or close a window, just by walking toward the automated device.

E-HealthWe’ve worked on an architecture based on DOMOSEC to offer e-health capa-bilities.10 We designed a novel system using chronobiological algorithms to telemonitor several illness factors that imply teleassistance. Complementing the base DOMOSEC system, we’ve designed a belt and bracelet with a set of monitoring sensors, including elec-trodes to capture the heartbeat, strain gauges to estimate the corporal posi-tion, a temperature sensor, and an ac-celerometer to detect inactivity or falls. The whole platform can also apply to different care environments—including public service providers (such as hospi-

tals, nursing homes, or assisted living facilities), private entities (such as insur-ance companies or care institutions), and the patient’s house itself—exploit-ing the platform flexibility.

Energy EfficiencyDOMOSEC has also been applied at the University of Murcia in a smart building project whose main purpose is energy efficiency. The building’s roof is a big solar panel, and the interior has been automated to make the most of the power used. Each floor has a HAM to control all common areas, whereas each working zone has another HAM to monitor the water and power con-sumption, adapt the lighting accord-ing to natural light, detect fires and floods, or automatically switch several devices on or off. Each working zone has a control panel installed to offer the HMI for these capabilities. Figure 4d shows this control panel, which is connected with the HAM included in the working zone, along with the adapted electric panel and the optional manual control of the air conditioning. All HAMs in the building have con-trol access capabilities by using smart cards, and a gateway has been set up at the reception position to enable remote management of all of them.

O ur architecture offers an integral indoor automa-tion solution suitable for deploying common

domotic or novel pervasive services, as evidenced by the various projects that have applied DOMOSEC. Moreover, we’re now defining a new research line to apply the HAM architecture in se-cure and mobile 6LoWPAN (IPv6 over Low-power Wireless Personal Area Networks) communications. This will involve using sensor networks to col-lect environmental information, but because these devices’ computational capabilities are restricted owing to consumption and size constraints, we propose to integrate SIROCO as a

We’redevelopinganintelligentremotecontrol

tolearncurrentconfigurationsofnearby

devicesandsavereusableprofiles.


security and mobility proxy. In this way, deploying these proxies as sup-porting infrastructure would signifi-cantly reduce the extra overload nec-essary for secure communications, ad hoc mobile routing protocols, and even data collection.

ACKNOWLEDGMENTSThisworkwassupportedbytheSpanishMinistryofIndustry,Tourism,andCommerce,undertheprojectIntelligentBedsTSI-020100-2008-536;theSpanishProgramtoAidGroupsofExcellenceoftheSénecaFoundation,undergrant04552/GERM/06;andpartiallybytheSpanishMinistryofEducation,undertheprojectSEISCIENTOSTIN2008-06441-C02.

REFERENCES 1. K. Sangani, “Home Automation: It’s No

Place Like Home,” IET Eng. & Technol-ogy, vol. 1, no. 9, 2006, pp. 46–48.

2. S.S. Intille, “Designing a Home of the Future,” IEEE Pervasive Computing, vol. 1, no. 2, 2002, pp. 76–82.

3. K. Wacks, “Home Systems Standards: Achievements and Challenges,’’ IEEE Communications, vol. 40, no. 4, 2002, pp. 152–159.

4. J. Walko, “Home Control,” IET Com-puting & Control Eng. J., vol. 17, no. 5, 2006, pp. 16–19.

5. P. Pellegrino, D. Bonino, and F. Corno, “Domotic House Gateway,” Proc. 2006 ACM Symp. Applied Computing, ACM Press, 2006, pp. 1915–1920.

6. F.T.H. den Hartog et al., “Convergence of Residential Gateway Technology,” IEEE Communications, vol. 42, no. 5, 2004, pp. 138–143.

7. K. Myoung et al., “Design and Imple-mentation of Home Network Control

Protocol on OSGi for Home Automation System,” Proc. 7th Int’l Conf. Advanced Comm. Technology, IEEE Press, 2005, pp. 1163–1168.

8. P. Bergstrom, K. Driscoll, and J. Kimball, “Making Home Automation Communi-cations Secure,” Computer, vol. 34, no. 10, 2001, pp. 50–56.

9. J. Su, C. Lee, and W. Wu, “The Design and Implementation of a Low-Cost and Programmable Home Automation Mod-ule,” IEEE Trans. Consumer Electronics, vol. 52, no. 4, 2006, pp. 1239–1244.

10. A.J. Jara, M.A. Zamora, and A.G. Skarmeta, “A Wearable System for Tele-monitoring and Teleassistance of Patients with Integration of Solutions from Chro-nobiology for Prediction of Illness,” Ambient Intelligence Perspectives, IOS Press, 2008, p. 221.

theAUTHORSMiguel A. Zamora-IzquierdoisanassociateprofessorintheDepartmentofInformationandCommunicationEngineeringattheUniversityofMurcia.Hisresearchinterestsincludeubiquitoussystems,sensortechnologies,automa-tion,andcontrol.Zamora-IzquierdoreceivedhisPhDincomputersciencefromtheUniversityofMurcia.Contacthimatmzamora@um.es.

José Santa isapostdocresearcherintheDepartmentofInformationandCommunicationEngineeringattheUniversityofMurcia.Hisresearchinterestsincludecontextawareness,location-basedservices,intelligenttransportationsystems,andhomeautomationanddomotics.SantareceivedhisPhDincom-putersciencefromtheUniversityofMurcia.Contacthimatjosesanta@um.es.

Antonio F. Gómez-SkarmetaisaprofessorintheDepartmentofInformationandCommunicationsEngineeringattheUniversityofMurcia.Hisresearchin-cludesmobilecommunications,pervasivesystems,networksecurity,andam-bientintelligence.Gómez-SkarmetareceivedhisPhDincomputersciencefromtheUniversityofMurcia.Contacthimatskarmeta@um.es.

SelectedCSarticlesandcolumnsarealsoavailableforfreeathttp://ComputingNow.computer.org.

IEEE Internet Computing reports emerging tools, technologies, and applications implemented through the Internet to support a worldwide computing environment.

For submission information and author guidelines, please visit www.computer.org/internet/author.htm

Engineering and Applying the Internet

An Integral and Networked Home Automation Solution for...

Documents

Transcript of An Integral and Networked Home Automation Solution for...