Interoperability for Web Services based Smart Home Control Systems

Hannu J¨arvinen and Petri Vuorimaa

Department of Media Technology, Aalto University School of Science, Espoo, Finland

Keywords:

Ambient Intelligence, Building Automation, oBIX, REST, Rule Engine, Smart Home, Web Intelligence, Web

of Things, Web Services.

Abstract:

One of the problems in smart home systems today is the lack of interoperability on different levels. While

applying closed, non-standard, and complex protocols can cause the problem on a lower level, the architecture

and design of a common building control system can cause it on a higher level. We present a solution for

enabling the interoperability on the higher level in building automation systems with XML based rules and a

Web API. To ensure the interoperability, we deﬁne requirements for Web services based building automation

control systems. A standard building automation guideline, oBIX, is used to provide interoperability on the

low level, and adopted for the rule management and description on the high level. The resulting rule engine

architecture and implementation are evaluated against the requirements. The solution provides interoperability

using standard Web technologies and supports employing several control systems simultaneously.

1 INTRODUCTION

In the Ambient Intelligence (AmI) world, our living

environmentsconsist of distributed embedded devices

cooperating with one another while the intelligence of

the system resides hidden in the network. These envi-

ronments comprise of different kind of technology re-

quired to properly function together towards common

goals. To achieve true interoperability between these

technologies, four layers of interoperability need to

be addressed: protocol layer, logic layer, semantic

layer, and intelligence layer. In this paper, we present

a solution for enabling smart home interoperability on

the logic layer, and for supporting it on the semantic

layer.

Common approach in smart home research has

been to connect devices to a central control system

that functions as a home server. Such a system can

offer remote access interface for the users to manage

their devices. The system can also offer means for

a user to program certain logic by deﬁning rules be-

tween the device states. While these kind of systems

can help people to better manage their homes, they

share two common constraints. In many cases, they

are using closed and non-standard protocols for the

communication, which restricts interoperability with

generic devices. They also handle their logic inter-

nally in the control system blocking third party so-

lutions out and forcing users to only use what is in

hands. Hence, the system can function well with the

devices that are connected to it, but is unable to in-

teract with other systems or consider a new type of

logic when built in functionality is felt insufﬁcient.

These independent systems can easily manage their

internal behavior but the inter-system communication

and logic is still a challenge.

In this paper, we present a solution for enabling

higher level interoperability in smart homes. After a

short introduction to home automation, we ﬁrst dis-

cuss related recent research on smart homes and rule

based systems, and then, considering the domain spe-

ciﬁc needs, deﬁne the requirements for Web services

based building automation control system with basic

logic interoperability and support for semantic inter-

operability. Next, we describe our architecture, use

case and implementation, and ﬁnally evaluate the re-

sults against the requirements. The main contribu-

tions of our work are the requirements for the Web

services based building automation control systems,

and the rule engine implementation with high-level

oBIX XML abstraction for the rule deﬁnition and

management through a RESTful Web API.

2 BACKGROUND

Intelligent buildings have a long history and ﬁrst at-

tempts to make our homes smarter were planned al-

Järvinen H. and Vuorimaa P..

Interoperability for Web Services based Smart Home Control Systems.

DOI: 10.5220/0004948500930103

In Proceedings of the 10th International Conference on Web Information Systems and Technologies (WEBIST-2014), pages 93-103

ISBN: 978-989-758-023-9

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

ready in the 1940s (Mozer, 1998). After that, the in-

dustry and research have periodically become inter-

ested in the idea of smart homes, and more lately the

concepts of ubiquitous computing, pervasive comput-

ing and physical browsing have hyped the discussion

on ambient intelligence up again.

Recent advancements in communication technol-

ogy have brought us with possibility to network our

home and building automation systems. The Internet

is considered ubiquitous in modern buildings and pro-

vides a natural way to connect these systems together

and with the rest of the IT world, offering the basic

network infrastructureon both local and global scales.

While the technology has been ready for smart build-

ings for a long time, they have not yet become reality

for the people. Main reason for that has been the long

battle between the standards on both national and in-

ternational levels (Felser and Sauter, 2002). Agree-

ments are not done on neither level, and today we

have a huge set of competing device protocols.

The diversity of the device protocols forced to de-

velop alternative solutions for modern Building Au-

tomation Systems (BASs). To cope with numerous

non-interoperable standards, developers implemented

ﬁrst protocol converters between different devices,

and later integrationplatforms, which are able to com-

municate over a variety of different protocols, and

thus function as central servers for the device com-

munication. An integration platform is basically a

combination of hardware and software that is able

to convert messages from different formats to oth-

ers and communicate over different physical layers

using a number of protocols (J¨arvinen et al., 2011)

(Valtchev and Frankov, 2002). It can offer a high level

interface to support information exchange with enter-

prise applications. Usually this interface, and more

and more often the backbone network of the integra-

tion platform, is based on the Internet Protocol (IP)

(Maile et al., 2007). Indeed, IP based communica-

tion is already widely applied in home automation

systems. This allows exploiting successful and well-

known Web technologies and tools in this domain.

Integration platforms partly solve the interoper-

ability problem bringing information and controls

from the devices available to the BASs. They unify

numerous different protocols and data representa-

tions under one format, hopefully an agreed standard.

However, after the interconnectivity, more is needed

to make the devices to actually interoperate with each

other. In practice, the interoperability on this level

is realized with some kind of logic that makes deci-

sions and strategies to execute commands based on

the available information. In this paper, we refer to

any system dedicated on handling this kind of logic

in a building as a control system. Such system per-

ceives the relevant environment states through, for

example, current device state values, device history

data, weather information and forecasts, or alterna-

tion of electricity price depending on the time of the

day. It can also use any other external data available

or a prediction made based on any of the mentioned

data. Internal logic of the control system then eval-

uates this information with some reasoning and can

decide to take actions based on the results.

In literature, various types of control systems have

been studied. In addition to simple rule deﬁnition,

other approaches such as fuzzy rules (Rutishauser

et al., 2005) and Artiﬁcial Intelligence (AI) (Mozer,

1998) based solutions are suggested. What is com-

mon in traditional approaches is that they concentrate

only on one type of control and handle it in a closed

module with a speciﬁc user interface to manage the

functioning.

The success of Web services as a solution for the

integration of distributed heterogeneous systems has

capitalized the research of service-oriented commu-

nications in the last decade. Web services are nowa-

days a de facto standard used to solve interoperabil-

ity problems in distributed computing, which has mo-

tivated us to support interoperability offering a Web

API for the rule management. Thus, in addition to de-

vices, also the logic is controllable through the Web

services interface.

In this paper, we concentrate on rule based control

systems. However, we suggest supporting a whole

horizontal layer of control systems simultaneously,

thus enabling the interoperability also between the

control systems. The focus of our research is on XML

based rules in a distributed environment. In the next

section, we describe earlier research on that area.

3 RELATED WORK

Rule based control systems generally describe rules

with events, conditions, and actions. Such systems

are able to automatically perform actions based on the

occurringeventsand evaluated conditions. The idea is

to have central management of the application logic,

instead of implementing the functioning in separate

programs, and to describe the rules with high-level,

declarative syntax (Papamarkos et al., 2003). The

composed Event-Condition-Action (ECA) rule struc-

ture has its roots in active databases. Originally, ECA

rules were developed in eighties as a solution for the

inability of the database management systems to trig-

ger actions based on the alarms. Later on, ECA rules

have been adopted by various other domains includ-

WEBIST2014-InternationalConferenceonWebInformationSystemsandTechnologies

ing XML, semantic web, and ubiquitous computing

(Chakravarthy and Adaikkalavan, 2007).

Considering the event part particularly in XML

documents, W3C has standardized Document Object

Model (DOM) Event Module (Schepers et al., 2011)

for that purpose. In addition to UI events, it deﬁnes

mutation events which are triggered on any change

to the structure of a document. Corresponding event

handlers can thus be created in a standard manner to

handle required actions when the DOM is altered.

Similarly for the condition and action part,

the Extensible Stylesheet Language Transformations

(XSLT) (Kay, 2007) provides a standard way for ap-

plying rules to XML documents. It can be used to

create an XML document based on two source docu-

ments. The source documents are an input XML data

ﬁle, and an XSLT rule ﬁle describing which elements

and attributes of the input XML are included and how

the output ﬁle is then constructed. The application

area of XSLT is well deﬁned and narrow, thus offering

a common tool for the application development. Ad-

ditionally, related to our solution, extensions such as

XSLT 2.0 Extensions for Saxon

and EXPath HTTP

Client

offer support for making HTTP requests from

the XSLT.

For the semantic layer, W3C has a recommenda-

tion for Rule Interchange Format (RIF). It has been

developed for the exchange of rules between the rule

languages, such as the oBIX based rule language we

propose in this article. RIF thus maps different rule

languages together using a common syntax and se-

mantics. Our approach for the interoperability here

however focuses on the logic layer providing an open

way for managing the rules through a Web API. To-

gether with addition of semantic layer, rule engine

would beneﬁt from RIF, as it would be interoperable

also with other RIF supported rule engines.

One common format for describing rules in XML

format is the Rule Markup Language (RuleML). (Bo-

ley et al., 2001) It deﬁnes a general and ﬂexible rule

language and is speciﬁed by a group of international

experts on the ﬁeld. However, in this paper we wanted

to concentrate on the smart home control systems, and

to unify the markup and the interface for both the de-

vices and rules.

A number of approaches for applying ECA rules

on XML has been proposed. Typically, they consider

XML as a data description format for the database,

otherwise keeping a close relation to the traditional

database systems. This means that the rules operate

on XML documents but are themselves described in

various non-XML formats (Bailey et al., 2002) (Pa-

http://www.fgeorges.org/xslt/saxon-ext/

http://www.expath.org/modules/http-client/

pamarkos et al., 2003) (Bonifati et al., 2002), and that

the operations are done with a local database.

An approach from (Bonifati et al., 2001) deﬁnes

the rules in XML, but also operates on XML doc-

uments locally. As the target documents are local,

the system does not offer interoperability for dis-

tributed systems as we propose. Another approach

from (Bernauer et al., 2004) tackled the problem of

deciding on which events to react. As every mod-

iﬁcation of the document triggers Document Object

Model (DOM) event, it is difﬁcult to decide when

conditions needs to be evaluated. Thus, they pro-

posed a solution for detecting composite events for

XML. However, they concentrate on the object node

relations inside an XML document, and on the DOM

events. This binds the solution to the local and com-

plete XML documents. An article from (Papamarkos

et al., 2004) presents an ECA language for Resource

Description Framework (RDF). The language is able

to function in distributed environments, as it supports

path expressions with requests to resource URIs. The

language itself is described in non-XML format, and

the rule management is not discussed.

A recent research from (Leong et al., 2009) con-

centrated on rule based interaction. They employed

ECA rules to enable interoperation between different

heterogeneous subsystems in a smart home environ-

ment. They used SOAP as a backbone network proto-

col and stored rules in table form on a home applica-

tion server. Subsystems reported their state changes

to the home application server, which then fetched

the related rules from the database, evaluated them

and informed the subsystems if necessary. They de-

ﬁned an SQL based Application Programming Inter-

face (API) for the management of the rules. The sys-

tem could handle interoperation between the subsys-

tems, but due to an additional API for the rule base,

management of the rules could only be done using a

speciﬁc user agent, not by other system modules.

4 REQUIREMENTS

Our approach is to gain the requirements for the Web

services based building automation control systems

from the properties of an Intelligent Agent (IA) de-

ﬁned in the Multi-Agent System (MAS) domain. An

intelligent agent is a piece of software that is situ-

ated, autonomous,reactive,proactive, ﬂexible, robust,

and social (Padgham and Winikoff, 2004). We recog-

nize four main properties of an IA that match with

the properties needed for the control logic of a build-

ing automation system. These properties are: au-

tonomous control, reactive responding to the changes

InteroperabilityforWebServicesbasedSmartHomeControlSystems

in the environment, proactive observation of the envi-

ronment, and social interaction with other agents.

We have derived the requirements from these

properties and divided them into four categories. We

suggest that the control descriptions should be based

on standard XML description format, system be able

to operate in distributed environments, support active

knowledge base updates, and offer a standard inter-

face for the management.

4.1 Description Format

To support social interaction, and for the simplicity

of the control description, there are two requirements.

The logic provided by the system should be described

based on a common language utilized on the Web

based building systems, similarly as all the data in the

system should be presented using one standard XML

based format. An XML based format is preferred due

to its popularity in the Web, ﬂexibility, both human

and machine-readable nature, and direct support with

Semantic Web techniques.

The description of the control logic in XML of-

fers a way to hide the complexity behind a high-level

abstraction layer. If a standard XML based building

system language is utilized, there is no need to learn

and implement new language syntax and semantics.

Using a standard language also facilitates social inter-

action within different system modules and with the

third party solutions. In addition to the XML encod-

ing, the control logic should be described in a simple

fashion. Declarative deﬁnition style deﬁnes the logic

without describing the control ﬂow. It contributes to

the simplicity by offering a natural and intuitive way

for presenting the logic. (Lloyd, 1994)

• R1: high-level standard XML abstraction for the

control logic description

• R2: declarative control logic deﬁnition

4.2 Interaction in Distributed

Environments

By their very nature, Web services based BASs are

distributed device environments. In such environ-

ment, control systems should offer functionality for

creating interoperability between various devices that

provide their data and controls on the Web. Social

interaction of the control logic and the devices can

realize this behavior. Thus, control systems need to

be able to both access web resources that are referred

in their logic with URIs, and similarly to send re-

quests to URIs for controlling web resources based

on the following actions. A control system thus

keeps up its knowledge base by perceiving the en-

vironment through references to multiple distributed

web resources, instead of referring to path expres-

sions within one XML document. This active inter-

device communication also enables the interoperabil-

ity in the action part of the logic. If the environment

meets a certain state that changes the output of the

logic, ﬁring actions can reactively make requests to

web based device resources, or similarly command

other web resources, such as control systems.

• R3: ability to perceive the environment with web

resource requests

• R4: ability to command actions with web resource

requests

4.3 Knowledge Base Updates

Distributed nature and real-time requirements of

building control systems require some considerations

to be made for the knowledge base of the control sys-

tem. One such requirement is the support for getting

informed, or proactive/automatic updates of the web

resource states that the system is aware of. A control

system thus needs to be able to periodically request

web resources for updating the knowledge base con-

taining the relevant current perception of the environ-

ment.

• R5: active knowledge base updates

4.4 System Management

For the general interoperability, the control system

management should be supported through a standard

Web services interface. In addition, direct support for

URIs as an addressing method simpliﬁes the integra-

tion with the Web, and partly enables the social in-

teraction. It also ensures that the logic is manageable

the same way than other objects in the Web of Things

(WoT) (Guinard and Trifa, 2009). While the control

system expects devices to expose their functionality

for the interaction, it should apply the same guideline

to itself and provide its services through a Web API.

These requirements ensure that the application

logic implementing the interoperation between the

devices and subsystems is accessible for all system

modules. Hence, the control modules of the sys-

tem are manageable using the same standard interface

than all the other modules of the system. This also al-

lows logic to access other logic in the same control

system, or in another type of control system.

Following these requirements in various control

systems allows different modules to build a uniform

WEBIST2014-InternationalConferenceonWebInformationSystemsandTechnologies

system, where management of any module is accom-

plished following the same consistent principles. In

practice, modules can exploit the functionalities of-

fered by other modules, thus supporting interoperabil-

ity on a higher level.

• R6: control system management through standard

web interface

• R7: logic identiﬁable with URIs.

5 ARCHITECTURE

We have deﬁned an architecture for smart home sys-

tems following the requirements from the previous

section, and apply those across all the system mod-

ules. As depicted in the Figure 1, on the high level all

modules of the system are using the same Web ser-

vices interface for the communication between them.

This allows ﬂexible management of the modules to

achieve a conﬁguration of the system that the user de-

sires. Opposed to more complex SOAP approach, we

promote use of RESTful Web services to simplify the

communication and the design, and to facilitate the

development of the following implementations. It is

notable, that the applied Web service technique has to

be open and standard to achieve interoperability with

third party solutions.

As the communication interfaces are uniﬁed into

one standard RESTful Web API, it is easy for modules

to communicate with each other. In our model, this

is the only interface for the management of a certain

module. This important design principle assures, that

the management of the modules is open for the whole

system. As seen in the Figure 2, this is a conceptually

different approach than having, for example, the ap-

plication logic managed inside a closed module that is

conﬁgurable only by a speciﬁc user interface or appli-

cation. Now, control logic can be easily created and

modiﬁed using the Web API that the modules provide.

While usage of only one interface makes the sys-

tem simple, it also sets speciﬁc requirements for it.

The interface standard has to allow a ﬂexible way for

developers to deﬁne their own diverse data models for

describing their data. It has to be ﬂexible enough to

also allow the management of the control systems and

be able to describe their functionality sufﬁciently. The

network includes various different types of modules,

and there can be multiple instances of any module

type functioning at the system simultaneously.

An integration platform brings the information

from the home devices available to the system. It

communicates using various underlying low-level de-

vice speciﬁc protocols and uniﬁes their representa-

tions to a standard data format offering an interface

!"#$%&$'(")*

+#,)'

-$./0$

12'$3),'/"2

45,'6")#

785$

923/2$

:;,<'/.$

="2')"5

+>?'$#

@?$)

:3$2'

92'$)<)/?$

:<<5/0,'/"2?

7$?/;$2'/,5

A,'$(,>

7$#"'$

@?$)%:3$2'

!BB4

Figure 1: A smart home system model with distributed in-

telligence. A standard Web services based building automa-

tion guideline is applied for the communication.

for managing the devices that are connected to it.

Smart devices instead are able to directly communi-

cate using the standard backbone network protocol

applied in the system. They do not need to be con-

nected to any integration platform but if desired, they

can do that as well. A smart device can also in-

clude application logic and it can, for example, di-

rectly communicate with other modules.

A rule engine is one type of control system. Using

the standard RESTful Web API, other modules can

create, modify and delete rules that run on the rule

engine. Rules are a way to deﬁne interoperating logic

to the system. Actions deﬁned in an individual rule

are executed if a certain logical condition is fulﬁlled.

The rule engine then commands the related devices to

take the appropriate actions. Rules are the most ba-

sic form of device independent interoperation in the

smart home system. Similarly to a rule engine, adap-

tive control system is responsible for implementing

interoperability to the system. The type of the logic,

however, differs from the one in rule engines. The

goal of the module is to learn from the behavior of

the system and adapt the functioning to it. It can, for

example, analyze the device history data and try to

improve the efﬁciency and the user comfort. Because

of this, the actual resulting behavior is not directly

manageable but the related parameters are.

6 IMPLEMENTATION

The implementation focused mainly on the rule en-

gine and the smart device but also included an inte-

gration platform and a couple of devices. As depicted

in the Figure 3, the rule engine played a central part

in the system. The following scenario was applied to

test the implementation:

InteroperabilityforWebServicesbasedSmartHomeControlSystems

!"#$%"&'()"*+,%"-

.*,/0$%,1&2-"*&'()"*+,%"

!"#$%"

!,),

34()*41&546$%

&&&&74891"-

:;-)"<&34*"

'()"*(,1&54=&5"#"1&'()"*+,%"

>4)$+;

34()*41

7,(,6"&!"#$%"-

&&&&,(8&546$%

!"#$%"&'()"*+,%"-

.*,/0$%,1&2-"*&'()"*+,%"

!"#$%"

!,),

34()*41&546$%

&&&&74891"-

'()"6*,)$4(

&&?1,)+4*<

@A)"*(,1&B$60&5"#"1&'()"*+,%"

@A)"*(,1&

&&B$60&

&&5"#"1&

'()"*+,%"

>4)$+;C

34()*41

@A)"*(,1&

&&B$60&

&&5"#"1&

'()"*+,%"

@A)"*(,1&B$60

5"#"1&'()"*+,%"

7,(,6"

!"#$%"-

7,(,6"

&&546$%

&&&&&&@A)"*(,1&B$60&

5"#"1&'()"*+,%"

Figure 2: Communication between system modules in a

system using a) Closed Control Logic; b) Open Control

Logic.

Michael is watching television at the living room

but wants to arrange some things at home at the same

time. When he enters a room to pick up something, the

light goes on in the room. When he leaves the room to

put the thing in its correct place, the light switches off.

However, when wandering around the ﬂat he does not

miss anything on the television, as always when he

leaves the sofa, the program pauses. Similarly, when

he sits down to the sofa again, the program continues.

For our implementation, we decided to use the

open Building Information eXchange (oBIX) (Con-

sidine and Ehrlich, 2006) from the Organization for

the Advancement of Structured Information Stan-

dards (OASIS). The data format is based on XML

and deﬁnes, similarly to any common programming

language, a small set of primitive data types for de-

scribing the data. It supports deﬁnition of contracts

based on the primitives to allow developers to deﬁne

data structures for their own devicesand systems. The

Figure 3: Communication ﬂow of the implemented system.

extendibility suits well to our needs, as we want to

describe multiple types of devices and control sys-

tems. The speciﬁcation deﬁnes both SOAP and HTTP

REST bindings. To simplify the development of the

applications, we have selected to use the latter. An ad-

ditional protocol layer is left out and the information

can be directly read using an HTTP browser.

The environment had two rooms, both having

three lights. For connecting devices to the integration

platform, we decided to follow the same communi-

cation method than the rest of the system. Thus, the

integration platform works as a standalone server and

devices can connect to it through the Local Area Net-

work (LAN). A camera based tracking system was

used to get the location of the user. The tracking

was implemented as a smart device and included ad-

ditional logic. It used Linear Discriminant Analysis

(LDA)

to predict if the user was about to enter the

room or not. It was able to anticipate this behavior of

the user and directly communicate with other system

modules. The purpose of the rule engine was to al-

low interoperation in the system using simple logical

rules, referred here as smart applications.

The idea of the prediction in the tracking system

was to remove the general system delay so that the

interaction with the environment would be pleasant.

Rule agents provided backup functions for the light

control, in case that the prediction would fail to rec-

ognize the behavior. In short, the overall system logic

switched the lights on in the room which was entered

and off in the room that was left. This happened ex-

actly when the user entered the room without a de-

lay. Additionally, the logic played and paused a TV

program based on the user’s presence on the sofa.

The implemented system modules and especially the

http://www.psychometrica.de/lda.html - Java imple-

mentation of the LDA.

WEBIST2014-InternationalConferenceonWebInformationSystemsandTechnologies

different parts of the rule engine are described in

more detail in the following subsections. Communi-

cation between these different system parts is empha-

sized. Detailed description of the user tests and mea-

surements are presented in (J¨arvinen and Vuorimaa,

2012).

6.1 Rule Engine

An oBIX standard based rule engine was developed

for the implementation. It is a further development

result of our Java based open Facility Management

Server (oFMS) (J¨arvinen et al., 2011). Thus, in ad-

dition to the rule management, the rule engine can

simultaneously function as an integration platform.

However, in this experiment we wanted to use a sep-

arate integration platform to follow the proposed ar-

chitectural design.

The rule engine is not following the ECA structure

as there is no separate event part in the rules. Its active

component, the smart application executor takes care

of regularly updating all the individual device states

that are referred in any of the rule conditions. Thus,

the conditions are evaluated only when needed. The

actual triggering event is a change in any of the de-

vice states referred in the condition. The Algorithm 1

illustrates the behavior of the six rules that were used

in the experimentation.

6.2 Smart Application Service

Smart application service offers an access point for

external modules to create rules. Following the oBIX

principles, it publishes information in the oBIX lobby

object, access point to any oBIX based system (Figure

4). After the creation of a new smart application, all

the needed references to it are found in the returned

smart application oBIX object. This object provides

functionality for management of the rule conditions

and actions and the logical parameters affecting the

<ref name="about" href="about/"

is="obix:About"/>

<ref name="smartApplicationService"

href="smartApplicationService/"

is="smartApplicationService"/>

</obj>

<op name="make" href="make" in="obix:Nil"

out="smartApplication"/>

</obj>

Figure 4: The smart application service is found in oBIX

lobby. The service provides a way to create smart applica-

tions.

Algorithm 1: Rules used in the experimentation.

Rule 1: When someone enters or leaves this room, switch

on and off the lights accordingly

if rulestate.has.changed then

if rulestate = true then

lamp1 ← on and lamp2 ← on and lamp3 ← on

else

lamp1 ← o f f and lamp2 ← o f f and lamp3 ← o f f

end if

Rule 2: When someone enters or leaves this room, switch

on and off the lights accordingly

if rulestate.has.changed then

if rulestate = true then

lamp4 ← on and lamp5 ← on and lamp6 ← on

else

lamp4 ← o f f and lamp5 ← o f f and lamp6 ← o f f

end if

Rule 3: When the user moves to this room, notify the light

batch rules and start observing when the user goes back

to the other room

if user.at.room.1 then

rule1.rulestate ← on and rule2.rulestate ← o f f and

rule4.active ← on and rule4.statechangestolive ← 1

end if

Rule 4: When the user moves to this room, notify the light

batch rules and start observing when the user goes back

to the other room

if user.at.room.2 then

rule1.rulestate ← o f f and rule2.rulestate ← on and

rule3.active ← on and rule3.statechangestolive ← 1

end if

Rule 5: When the user sits on the sofa, turn on

the TV and start observing when the user leaves the

sofa

if user.sitting.on.the.sofa then

tv ← on and rule6.active ← on and

rule6.statechangestolive ← 1

end if

Rule 6: When the user leaves the sofa, pause the pro-

gram and start observing when the user returns to the

sofa

if user.not.sitting.on.the.sofa then

tv ← o f f and rule5.active ← on and

rule5.statechangestolive ← 1

end if

rule behavior. Smart application service is able to re-

store smart applications from the XML presentations

stored in the database.

6.3 Smart Application Executor

Rule conditions can include references to a number of

device and object states. The main task of the smart

InteroperabilityforWebServicesbasedSmartHomeControlSystems

Figure 5: Smart application executor periodically updates

the watchstate objects. If an object state has been changed,

it creates a smart application evaluator to evaluate the con-

ditions that refer to this watchstate.

application executoris to take care that these states are

kept up to date. Based on the polling intervals deﬁned

in the rules, it periodically requests updates for the

state values. When any of the states change, it creates

a new smart application evaluator to evaluate the rules

that include conditions that were affected (Figure 5).

6.4 Smart Application Evaluator

Smart application evaluator is spawned for every

change in any of the device states that the smart appli-

cation executor is updating. Executor passes a list of

affected smart applications to the evaluator. Affected

smart applications are all the rules that refer to the

changed state in their conditions. Evaluator then goes

through all the smart applications in this list evaluat-

ing their conditions. For the evaluation, it requests

state values of the devices. If the return value of the

evaluation differs from the current smart application

state stored in its XML representation, corresponding

rule actions are executed.

6.5 Rule Agent

In practice, rule agent describes a rule as a smart ap-

plication (Figure 6). An individual rule includes rule

properties deﬁning its behavior, a conditions clause,

and a list of actions. A conditions clause can in-

clude many condition clauses. All watch state rules

in an individual condition clause have to be true for

the rule condition to be fulﬁlled. Instead, for a con-

ditions clause to be fulﬁlled, even one fulﬁlled con-

dition clause is sufﬁcient. An individual watch state

object inside a condition deﬁnes a primitive condition

for one device state (Figure 7). The resulting sim-

<op name="makeCondition" in="obix:Nil"

out="condition"/>

<op name="deleteCondition" in="obix:ref"

out="obix:Nil"/>

<op name="makeWatchState" in="obix:ref"

out="watchState"/>

<op name="deleteWatchState" in="obix:ref"

out="obix:Nil"/>

<op name="makeAction" in="obix:Nil"

out="action"/>

<op name="deleteAction" in="obix:ref"

out="obix:Nil"/>

<op name="delete" in="obix:Nil"

out="obix:Nil"/>

</obj>

Figure 6: The smart application contract in oBIX. In prac-

tice, smart application instances also include href attributes,

so that the individual elements can be referred. Thus, each

rule and its sub elements have unique URIs.

<enum name="relation"

range="relationshipRange"/>

</obj>

Figure 7: An oBIX contract for a watch state object deﬁning

a simple condition which refers to only one device state.

Instances of the contract also include href attributes for each

of the elements.

ple or-and mechanism can handle basic logic needed

for common purposes. For more complex logic, rules

can be chained together. This type of chaining is pos-

sible because rules are able to refer to the states of

each other. Actions list deﬁnes the resulting actions

that are executed if the state of the smart application

is changed.

6.6 Integration Platform

We used an integration platform provided by C oBIX

Tools (CoT)

from Andrey Litvinov. It handles all the

C oBIX Tools is published as an open source project at

http://code.google.com/p/c-obix-tools/

WEBIST2014-InternationalConferenceonWebInformationSystemsandTechnologies

100

basic oBIX features and additionally offers a more ef-

ﬁcient technique for polling than the original oBIX

speciﬁcation. The integration platform was used by

the lighting system oBIX client, virtual television

oBIX client, and, of course, the rule engine and the

smart device for the interoperation.

6.7 Smart Device

The tracking system oBIX client was implemented as

a smart device. It was able to predict the user entering

into a room and managed to compensate the common

system delay of approximately one second in that be-

havior. It used LDA for the prediction when the user

was close to the door. LDA considered walking di-

rection and the turning angle as factors to deﬁne the

behavior. Smart device did not command the lights

directly but used the batch rules (Rules 1 and 2) on

the rule engine to easily command multiple lights in

one room with one request.

7 EVALUATION

The results are evaluated against the requirements for

Web services based BA control systems deﬁned in

Section 4.

7.1 Description Format

The control system logic is implemented as rules. The

system is based on the oBIX standard, which deﬁnes

an XML-based data description format. The use of

oBIX XML data model for the rule description ful-

ﬁlls the requirement R1 per se. This language is used

to deﬁne rules in a declarative manner by describ-

ing them with condition clauses, watch states, actions,

and general rule parameters, fulﬁlling the requirement

R2. For further interoperability to exchange rules

with other systems, RuleML could be used as a rule

description format, and the rule managementinterface

could handle the translation into oBIX for the Web

API.

7.2 System Management

In the XML description, a rule element and its sub el-

ements all have unique URIs. Thus, they are manage-

able through the HTTP oBIX interface. This direct

support for URIs as an addressing method simpliﬁes

the rule management, provides an access method for

the control systems to perceive and control the envi-

ronment, and facilitates the integration with the rest

of the Web. These fulﬁll the requirements R6 and R7.

7.3 Active Interaction in Distributed

Environments

The implemented smart application executor regu-

larly requests updates for the device states that the

rules depend on, fulﬁlling the requirement R5. Ad-

ditionally, the rule engine contains a smart applica-

tion evaluator, which evaluates the rule conditions and

commands the actions if the conditions are fulﬁlled.

Both the executor during the regular update cycle and

the evaluator during the rule evaluation and action

commanding, are able to make HTTP requests to Web

resources. These fulﬁll the requirements R3 and R4.

8 DISCUSSION

According to Zelkha, et al. (Zelkha et al., 1998), the

ambient intelligence paradigm is characterized by the

systems that are:

• Embedded;

• Personalized;

• Adaptive;

• Anticipatory.

The system presented in this paper can be char-

acterized with these features. The integration plat-

form provides a solution for interconnecting the de-

vices embedded in the environment. Functioning of

the devices can then be managed and the system per-

sonalized through standard BA interface, and auto-

matic behavior be programmed with the rule engine.

Utilizing a standard interface enables usage of mul-

tiple control systems at the same time, thus allowing

modules for adaptive and context aware control to be

added to the system. Similarly, the system demon-

strates the possibilities for anticipatory behavior with

a simple prediction module for lighting control.

We believe that the deﬁned system requirements

offer a basis for developing interoperable smart home

systems. From the architectural point of view, the

main advangement is the support for multiple control

systems at the same time. While it offers a possi-

bility for modular system design, it also introduces

new challenges for the management of the system

functioning as a whole. Cooperative functioning of

this kind of distributed applications have been stud-

ied in the MAS domain (Weiss, 1999) (Wilmott et al.,

2001). Thus, applying advanced MAS techniques and

principles for the ﬂexibility, robustness, and concep-

tual reasoning of the control system agents is one of

our future research lines. In contrast to similar exist-

ing systems, our solution is based on Web technolo-

InteroperabilityforWebServicesbasedSmartHomeControlSystems

101

gies and provides a Web API for the rule manage-

ment, which allows user agents to create and remove

rules, but also to modify the content of existing rules

in the rule engine. These with an XML based descrip-

tion format are compatible with Semantic Web tech-

niques and allow us to add a new semantic layer on

top of the system in the future, and integrate MASs

with the smart home systems to further build intelli-

gence with semantic reasoning.

9 CONCLUSION

We presented a logic layer interoperability solution

for distributed smart home systems. The system was

based on requirements that ensure the support for

features that contribute to the interoperability on the

logic layer and enable it on the semantic layer. The

implementation considered a rule engine able to ob-

serve and control devices through standard Web ser-

vices interface. Similarly, the rule engine offered a

Web services interface for the rule management fol-

lowing the same building automation guideline. The

implemented system was functional, fulﬁlled the re-

quirements, and proved the applicability of the ap-

proach. However, the system does not offer all the

needed functionalities at the moment. Proper meth-

ods are needed for security, authentication, authoriza-

tion as well as managing conﬂicts in the logic. As the

system is using RESTful Web services, it can partly

exploit same well-known techniques that are used in

the traditional Web applications to overcome some of

the challenges.

We believe that Web services based control sys-

tems can offer solutions to gain better interoperability

in smart home environments. The interoperability in

the system is not achieved by offering a single man-

ner to control the system. It is a joint effort of multi-

ple control systems offering their services openly for

managing the logic. Individual control systems can

concentrate on their main functions and exploit ser-

vices from each other, shaping the smart home to a

fully functional ecosystem where every service does

its own part and interacts with the others.

ACKNOWLEDGEMENTS

Part of the work was done as part of TIVIT De-

vices and Interoperability Ecosystem (DIEM) project

Building Automation work package and supported by

The Doctoral Programme in the Built Environment

(RYM-TO) funded through the Academy of Finland

and the Ministry of Education and Culture.

REFERENCES

Bailey, J., Poulovassilis, A., and Wood, P. (2002). An event-

condition-action language for xml. In Proceedings of

the 11th international conference on World Wide Web,

pages 486–495. ACM.

Bernauer, M., Kappel, G., and Kramler, G. (2004). Com-

posite events for xml. In Proceedings of the 13th inter-

national conference on World Wide Web, pages 175–

183. ACM.

Boley, H., Tabet, S., and Wagner, G. (2001). Design ratio-

nale for ruleml: A markup language for semantic web

rules. In SWWS, volume 1, pages 381–401.

Bonifati, A., Braga, D., Campi, A., and Ceri, S. (2002).

Active xquery. In Data Engineering, 2002. Proceed-

ings. 18th International Conference on, pages 403–

412. IEEE.

Bonifati, A., Ceri, S., and Paraboschi, S. (2001). Active

rules for xml: A new paradigm for e-services. The

VLDB Journal, 10(1):39–47.

Chakravarthy, S. and Adaikkalavan, R. (2007). Ubiqui-

tous nature of event-driven approaches: A retrospec-

tive view.

Considine, T. and Ehrlich, P. (2006). Open building infor-

mation exchange (oBIX).

Felser, M. and Sauter, T. (2002). The ﬁeldbus war: History

or short break between battles? In IEEE WFCS, pages

73–80.

Guinard, D. and Trifa, V. (2009). Towards the web of things:

Web mashups for embedded devices. In Workshop on

Mashups, Enterprise Mashups and Lightweight Com-

position on the Web (MEM 2009), in proceedings of

WWW (International World Wide Web Conferences),

Madrid, Spain.

J¨arvinen, H., Litvinov, A., and Vuorimaa, P. (2011). In-

tegration platform for home and building automation

systems. In Consumer Communications and Network-

ing Conference (CCNC), 2011 IEEE, pages 292–296.

IEEE.

J¨arvinen, H. and Vuorimaa, P. (2012). Anticipatory lighting

in smart building. In Consumer Communications and

Networking Conference (CCNC), 2012 IEEE, pages

390–394. IEEE.

Kay, M. (2007). Xsl transformations (xslt) version 2.0.

W3C Recommendation, 23.

Leong, C., Ramli, A., and Perumal, T. (2009). A rule-

based framework for heterogeneous subsystems man-

agement in smart home environment. Consumer Elec-

tronics, IEEE Transactions on, 55(3):1208–1213.

Lloyd, J. (1994). Practical advantages of declarative pro-

gramming. In Joint Conference on Declarative Pro-

gramming, GULP-PRODE, volume 94, page 94.

Maile, T., Fischer, M., and Huijbregts, R. (2007). The vision

of integrated IP-based building systems. Journal of

Corporate Real Estate, 9(2):125–137.

Mozer, M. (1998). The neural network house: An envi-

ronment hat adapts to its inhabitants. In Proc. AAAI

Spring Symp. Intelligent Environments.

Padgham, L. and Winikoff, M. (2004). Developing intelli-

gent agent systems: a practical guide, volume 1. Wi-

ley.

WEBIST2014-InternationalConferenceonWebInformationSystemsandTechnologies

102

Papamarkos, G., Poulovassilis, A., and Wood, P. (2003).

Event-condition-action rule languages for the se-

mantic web. In Workshop on Semantic Web and

Databases, page 2003. Citeseer.

Papamarkos, G., Poulovassilis, A., and Wood, P. (2004).

Rdftl: An event-condition-action language for rdf. In

Proc. of the 3rd International Workshop on Web Dy-

namics.

Rutishauser, U., Joller, J., and Douglas, R. (2005). Control

and learning of ambience by an intelligent building.

Systems, Man and Cybernetics, Part A: Systems and

Humans, IEEE Transactions on, 35(1):121–132.

Schepers, D., Rossi, J., H¨ohrmann, B., Le H´egaret, P., and

Pixley, T. (2011). Document object model (dom) level

3 events speciﬁcation. W3C Working Draft.

Valtchev, D. and Frankov, I. (2002). Service gateway archi-

tecture for a smart home. Communications Magazine,

IEEE, 40(4):126–132.

Weiss, G. (1999). Multiagent systems: a modern approach

to distributed artiﬁcial intelligence. The MIT press.

Wilmott, S., Dale, J., Burg, B., Charlton, P., and O’Brien, P.

(2001). Agentcities: A Worldwide Open Agent Net-

work. AgentLink News, Issue 8.

Zelkha, E., Epstein, B., Birrell, S., and Dodsworth, C.

(1998). From devices to ambient intelligence. In Dig-

ital living room conference.

InteroperabilityforWebServicesbasedSmartHomeControlSystems

103