1

Semantic-based Enhancement of ISO/IEC 14543-3EIB/KNX Standard for Building Automation

Michele Ruta, Floriano Scioscia, Eugenio Di Sciascio, and Giuseppe Loseto

Abstract—Current technologies for Home and Building Au-tomation (HBA) basically require an explicit interaction withthe user and allow a static set of operational scenarios definedduring system implementation. On the contrary, novel HBAsolutions should enable so-called ambient intelligence, derivingfrom a flexible and automatic control of appliances and sub-systems dipped into an environment. To this aim, this paperproposes backward-compatible enhancements to one of the mostwidespread domotic standards, i.e., EIB/KNX ISO/IEC 14543-3,able to support advanced, knowledge-based and context-awarefunctionalities, grounded on the semantic annotation of both userprofiles and device capabilities. Such an approach enables novelresource discovery, matchmaking and decision support featuresin HBA. Main benefits are in: (i) determining the most suitableservices/functionalities according to implicit and explicit userneeds, (ii) allowing device-driven interaction for autonomousadaptation of the environment to context modification. A casestudy is presented to better clarify the proposed framework alsohighlighting main characteristics, while performance evaluationis provided to assess its effectiveness.

Keywords-Ambient Intelligence; Building Automation;EIB/KNX; Semantic Web; Service/resource discovery

I. INTRODUCTION

In latest years, advances in information and communica-tion technology have opened the possibility to create smarthome/building environments, aimed at increasing comfort andsecurity, making management easier, reducing energy con-sumption and minimizing environmental impact [1]. The so-called Ambient Intelligence (AmI) [2] aims at a research visionwhere people are surrounded by intelligent and unobtrusivemicro-components dipped in the environment, capable of be-ing sensitive and responsive, recognizing user profiles and self-adapting behavior accordingly. Devices should communicateand interact autonomously, without the need for direct userintervention, also making decisions based on multiple factors,including user presence and preferences. They should be co-ordinated by intelligent systems acting as supervisors. Currentsystems and standard technologies developed for Home andBuilding Automation (HBA) are far from that vision, being un-suitable for granting such an autonomicity and flexibility. Theystill require explicit interaction with the user and are basicallytied to static operational scenarios set during implementation.

Manuscript received March 31, 2011; revised May 30, 2011; accepted forpublication July 31, 2011.

Copyright c⃝ 2011 IEEE. Personal use of this material is permitted.However, permission to use this material for any other purposes must beobtained from the IEEE by sending a request to pubs-permissions@ieee.org.

The authors are with SisInfLab (Information Systems Lab) at Dipartimentodi Elettrotecnica ed Elettronica, Politecnico di Bari, 70125, Bari, Italy (cor-responding author e-mail: m.ruta@poliba.it).

In order to enable novel and intelligent HBA infrastructures,able to adapt and autonomously control building appliances,smart environments have to be conceived according to re-sults coming from pervasive and mobile computing, artificialintelligence theory and agent-based software design [3]. Adynamic management of information about users, devices andservices in a given context is needed. Consequently, AmIresearch is closely related to studies for effective discovery andcoordination in volatile and resource-constrained scenarios.This paper proposes to overcome restrictions of commondomotic appliances through the exploitation of KnowledgeRepresentation (KR) technologies and automated reasoningtechniques, originally conceived for the Semantic Web. Anenhancement to ISO/IEC 14543-3 EIB/KNX standard [4]has been devised in a knowledge-based and context-awarecomputing framework for building automation, supportingsemantic annotation of both user profiles (i.e., needs, moods,features) and device capabilities (i.e., services/resources homeappliances offer). The integration of a semantic micro-layerwithin KNX protocol stack enables novel resource discoveryand decision support features in HBA making them au-tonomous and decentralized, while preserving full backwardcompatibility. Machine-understandable metadata characterizeboth home environment and user profiles and preferences.Thanks to the integration of semantics at the applicationlayer, each object/subject joining a KNX network can describeitself and advertise managed services/resources. By meansof a matchmaking process –based on inference proceduresin [5]– the most suitable available services/functionalitiesfor adapting the ambient to a given request or event canbe easily detected. Annotations are expressed in ontologicalformalisms derived from Description Logics (DLs) [6]: DIG[7], a more compact equivalent of OWL-DL (OWL WebOntology Language, W3C Recommendation, February 10th2004, http://www.w3.org/TR/owlfeatures/), has been adoptedin particular. Furthermore, user-transparent and device-driveninteraction is enabled as opposed to current static configu-ration approaches. At network layer, KNX support for IPcommunication through KNXnet/IP is leveraged to extendthe management of building control beyond the local bus,while IEEE 802.11 and Bluetooth are exploited for wirelesscommunication with the user.

The remaining of the paper is organized as follows. In Sec-tion II relevant related work is briefly surveyed, while SectionIII outlines the proposed enhancements to KNX. Section IVdescribes the system prototype w.r.t. framework architecture(in IV-A), implemented testbed (IV-B) and experiments carriedout (IV-C), also reporting on performance evaluation. Final

2

remarks and future work are in Section V.

II. RELATED WORK

Although several technological issues related to the im-plementation of ad-hoc networks with a large number ofsensors and actuators have been solved (many of them ex-ploiting IEEE 802.15.4/ZigBee standard protocol [8], [9]),open questions still remain about high-level discovery andcoordination as well as user interaction. Many proposalscan be found in literature for improving flexibility of HBAsystems. Some approaches (see for example [10], [9]) allowmore advanced and user-friendly device management w.r.t.current standard technologies. Nevertheless, they still rely onlyon direct command-based user interaction, through local ornetwork-based interfaces. Intelligent multi-agent paradigms[11], wherein each software agent is able to interact with peersto achieve its goals, have been exploited for designing andmodeling smarter environments. In fact, Multi-Agent Systems(MAS), are leveraged in AmI to represent meaningful entitiessuch as rooms, devices or people. In early approaches [12],machine learning techniques were exploited for smart buildingautomation in a simulated campus dorm environment. Agentswere located on small embedded computers and adoptedsimple fuzzy logic rules, learned through observation of in-habitants’ behavior. Improvements in agent learning capabilitywere achieved in industrial automation settings by supportingthe temporal evolution of critical model parameters [13].

In order to achieve greater interoperability, a major goalis to provide a unified view of the home environment anda flexible application model. Traditionally, limited integrationof domotic sub-networks based on different technologies wasachieved by means of custom gateways. Several proposals[14], [15], [16] adopt Web Service technologies as unifiedabstraction layer to integrate various communication protocolsand mobile service discovery in automation contexts. StandardWeb Service description and orchestration languages basedon XML are adopted, only allowing syntactic match betweenusers’ needs and service/resource attributes, lacking semanticcharacterization. As a consequence, the improvement in ser-vice discovery and composition capabilities w.r.t. basic HBAprotocols is not so relevant to justify the increased architec-tural complexity. Similarly, proposals for service compositiontargeted to distributed systems take into account real-timerequirements and fault tolerance [17], but they are based onmerit figures and utility functions, which must be modeledcase-by-case.

Knowledge representation technologies allow greater gen-erality and more flexible reuse of models, because ontologiesprovide a conceptual framework to express and share for-mal and structured descriptions of services and appliances,while general-purpose reasoning procedures can be used forsemantic-based service composition in different HBA scenar-ios. DomoML [18] was the first specific proposal of a buildingautomation ontology suite. Reinisch et al. [19] acknowledgedthe relevance of semantic-enhanced approaches upon currentHBA standards, for cost and efficiency motivations; theyintroduced a theoretical ontology-based framework for the

integration of different HBA protocols at application level. In[20], Bonino et al. presented the first self-contained prototypewhich includes a reasoning module able to manage and coordi-nate heterogeneous devices by means of logic rules processing.In [21] the use of intelligent agents, designed according tothe BDI (Belief-Desire-Intention) model, was proposed toautomate service composition tasks, so providing transparencyfrom the user’s standpoint. Nevertheless, a very basic ontologywas derived from attribute-based service descriptions in UPnPand Bluetooth service discovery protocols. As a consequence,the approach lacks adequate expressiveness of user, device andservice profiles; furthermore the proposed case study is quitesimplistic and experimental evidences are absent.

An open issue of the above approaches is that classicalrule-based inferences are not enough in heterogeneous anddynamic AmI contexts. In order to execute a rule, conditionsit imposes must be fully matched by the current system state.Unfortunately, experience shows that full matches are quiteunlikely –and different descriptions can even be partially inconflict– in real-life scenarios. Semantic-based matchmakingframeworks as the one in [22], which exploits standard andnon-standard inference services and allows to match requestsand resources based on the meaning of their descriptions (alsoproviding classification and logic-based ranking), are more ef-fective. Beyond obviously good matches, such as exact or fullones, they enable so-called potential or intersection matches(i.e., those matches where requests and supplied resourceshave something in common and no conflicting characteristics)and partial or disjoint matches (i.e., cases where requests andsupplies have some conflicting features) which can also beconsidered useful in scenarios when nothing better exists.

III. SEMANTIC ENHANCEMENTS TO EIB/KNX STANDARD

In order to grant feasibility and leverage industry support,the proposed approach is based on one of the most widespreadHBA standards, introducing a semantic enhancement foradvanced management of user profiles and device proper-ties/services. A self-adapting framework has been devisedexploiting KR techniques and reasoning. In particular, KNXwas chosen as reference protocol, but the application of theabove enhancements to other widespread domotic protocolsis also under investigation, for possible semantic-based cross-protocol interactions. KNX is an open international standardderiving from the convergence of existing EIB (EuropeanInstallation Bus), EHS (European Home Systems) and Bat-iBus protocols into the specification of KNX Association [4].Basically, KNX is a backward compatible evolution of EIB,hence the name EIB/KNX. Several physical communicationmedia are supported: from twisted pair (TP) wiring to powerline (PL), radio frequency (RF) and Ethernet, complyingwith KNXnet/IP protocol. KNX networks have a hierarchicaltopology and an addressing structure used to unambiguouslyidentify and access domains and devices. In the proposedapproach, all devices share the same domain address becausethey are supposed to belong to the same installation. KNXalso supports an additional multicast address space availablefor groups. Multiple devices, or multiple functionalities of

3

different devices, can be grouped and featured by a singlegroup address in the form main.middle.littleGroup.

KNX 2.0 specification evidenced several limits in managingmetadata referred to devices. Hence, a new semantic micro-layer has been introduced on the top of the protocol stack,while keeping a full legacy compatibility with current appli-cations. Two new Interface Objects have been defined to storestructured and semantically annotated descriptions of bothdevices and functionalities (i.e., machine understandable DIGfragments referred to a given ontology). In order to maintainthe conformity to the standard, such new objects have beendeveloped according to the structural specification in [4]. Re-call that Interface Objects are data structures exposing devicefeatures. They simply consist of Object Properties, each com-posed by a property description and a property value. Propertydescriptions include: (i) a Property IDentifier (PID) code, (ii)a Property Data Type (PDT) code, (iii) a (max no of elem)value indicating the maximum number of contained elementsand (iv) a field related to property access rights. The propertyvalue is an array containing max no of elem+1 elements: theelement at index 0 contains the current valid elements. At leastone Object Property is mandatory for all Interface Objects,the Object Type: it is a 16-bit unique identifier. KNX standarddefines different value ranges for this code according to objectpurposes.

In order to reduce the size of semantic annotations referredto both device features and user profiles, an encoding algo-rithm devised in earlier work [23] is exploited for efficientlycompacting XML-based ontological languages, generating aheader and a body for each encoded document. Furthermore,an Interface Object named Generic Profile of the Device(GPD) has been introduced to describe general device featurese.g., type, manufacturer or model. A single GPD is associatedto a given device. A Specific Profile of the Device (SPD) objecthas been also defined to describe individual functionalities andoperating modes of a device. Multiple SPDs can be associatedto the same device, one for each different service/function itexposes. Both new objects have similar structure, reported inwhat follows:

• PID OBJ TYPE: a 16-bit field indicating the object type.GPD and SPD are identified by 1200 and 1205 codes,respectively. They belong to standardized applicationinterface object types range;

• PID OUUID: 16-bit Ontology Universally Unique IDen-tifier (OUUID), marking the reference ontology the de-vice semantic annotation refers to [24]; it allows toperform a preliminary selection of the knowledge domainthe system is going to operate on, in each matchmakingsession. Before starting any discovery phase, user andhome agent have to agree about the reference ontology,which provides a common conceptualization of the par-ticular knowledge domain. Due to space constraints, theinterested reader is referred to [24] for further details;

• PID OUUIDs: OUUID group. This field only refers toGPD and contains the list of OUUIDs of SPDs associatedto the device;

• PID SEMANTIC HEADER: header of encoded deviceannotation. It is stored on the object as a variable-length

������� ������� ������� �������

�� �� � � �� � � � � �� � � � � �� � � � �� � � � � �� �

���� ���� ��������� �������������

����

�

Fig. 1. Semantic-enabled Application-layer Protocol Data Unit

string;• PID SEMANTIC BODY: body of encoded semantic de-

scription. Also this property is a string.Standard modification also include the definition of a new

Property Data Type (PDT) for OUUIDs, labeled with 7.1000code. Main number 7 indicates a 16-bit unsigned value while1000 is the first available value in the range reserved byKNX standard for future uses. The definition of two specificapplication-layer service primitives has been further requiredby the goal of supporting user-independent device interaction:

• A SEMANTIC SUBMISSION.req, used to send a seman-tic description generated by a device agent and based onevents detected in the environment;

• A SEMANTIC SUBMISSION.res, containing the reply tothe above semantic request.

Each primitive is identified by a code included into theApplication-layer Protocol Control Information (APCI) fieldand selected among unused APCIs reserved by KNX specifi-cation. Such services allow devices to autonomously exchangesemantic metadata via an Application-layer Protocol Data Unit(APDU) of a generic KNX frame, as shown in Figure 1.

Even though semantically annotated descriptions are com-pressed, they might often exceed the 14 bytes avail-able in the APDU data field. Consequently, the extendedKNX frame is exploited, as supported by the standard. Itslength is 255 bytes, 249 of which for data. A new PDT,named PDT GENERIC EXT, has been introduced to definea variable-length string with that maximum size. If the com-pressed semantic annotation is still longer than the extendedAPDU payload, it is split in more chunks inserted in differentframes. In that case, the total packets will be specified intothe “number of elements” field of the related interface object.Chunks will be retrieved by accessing sequentially the ele-ments of the property value array. Standard KNX transmissioncontrol techniques are exploited for error control.

IV. SYSTEM PROTOTYPE

A. Reference Architecture

The proposed architecture, shown in Figure 2, exploits anIP network as a fast backbone. In a common building config-uration, KNX devices are connected to one or more KNX/IProuters through the bus so forming several sub-networks; eachrouter on turn is connected to the backbone. Both standardand smart devices are included in the system. The former areconform to ISO/IEC 14543-3, the latter can be assimilatedto virtual KNX/EIB devices [25], endowed with additionalhardware interface and able to directly communicate on the IPlink. Such devices are compliant with semantic enhancementsto the protocol reported in Section III. To coordinate, manage

4

Fig. 2. Framework architecture

Fig. 3. Central Unit modules Fig. 4. Semantic enhanced commu-nication exploiting Device Agent

and control the building environment, the system also in-cludes a lightweight software component, namely Central Unit(CU), which performs network configuration and monitoring,service/resource discovery and device remote control. TheCU could be hosted by any home device able to provideminimum computational capabilities and memory availability.It is composed by 7 modules, organized in 3 architecturallayers, as depicted in Figure 3. Purpose and function of eachof them is analyzed hereafter.

Graphical User Interface (GUI). A simple touch-screeninterface (not shown here due to lack of space) is providedallowing users to interact with the system. A virtual buttonpanel enables basic building profiles described through seman-tic annotations, view devices status and show the content ofreceived requests along with corresponding replies.

Client Manager. This module interconnects users to the CUby means of a mobile client, e.g., a smartphone, for checkingthe status of the building environment and to submit profiles.Basically, a profile consists of a semantically annotated de-scription –w.r.t. a reference ontology– that may include userfeatures such as age, gender, physical status, mood as wellas requests for specific service categories or home resources.Communication between clients and the CU occurs via eitherIEEE 802.11 or Bluetooth wireless technologies. A basic clientwas developed for Android smartphones to test the module(not described here as outside the scope of the paper).

DB Manager. At CU startup, this module parses the XMLdocument generated by ETS3 (Engineering Tools Software,a manufacturer-independent software tool provided by KNXAssociation for designing and configuring installations) inorder to detect the home configuration as well as the im-plemented network topology. It should be noted that ETS3,

:DomoLogic :KNXManager:UserAgent :DeviceAgent

alt Receiving Semantic Request

[request coming from a mobile client]

[request coming from a device]

loop Device Scan

[for each connected device]

loop Activate / Deactivate Functionality

[for each selected functionality]

alt Sending Semantic Response

[request coming from a mobile client]

[request coming from a device]

sendRequest()

A_Semantic_Submission.req()

forwardSemanticRequest()

getFunctStatus (grpAdd)

getFunctStatus (grpAdd)

processRequest()

setFunctStatus (grpAdd)

setFunctStatus(grpAdd)

sendResponse()

forwardSemanticResponse()

A_Semantic_Submission.res()

Fig. 5. Agent interaction sequence

by itself, cannot manage the semantic enhancements to KNXstandard introduced here. Consequently, typical configurationfiles produced by ETS3 have to be enriched with the supportto semantic-based extensions, so that they can be imported bythe DB Manager. In particular, a new XML line is added foreach service provided by a device:<functionality type="A|S|I" value="VAL" description="NAME" />

The type attribute describes the device class: “A” for ac-tuators, “S” for sensors and “I” (as “intelligent”) for smartdevices. Description is a label which references the SPDinterface object containing the semantic annotation of theservice, so that it can be accessed from the device. Eachservice is associated to a standard KNX data point via thevalue field, which is sent to the device when the servicemust be enabled. The proposed structure permits the high-level user-oriented representation of each service/resource tobe anyway triggered by low-level device-oriented parametersfor service/resource execution. Parsed data referred to networktopology (including group address, data types and providedfunctionalities for each device) are then stored into a database,acting as simple device cache. SQLite (http://www.sqlite.org),a lightweight embedded SQL database engine, was adopted forthis purpose. During startup phase, the semantic descriptionof each available service/resource is also retrieved from itsprovider and cached into the DB, in order to reduce networkcongestions and response latency. Nevertheless, it is useful topoint out that the exploitation of both configuration file anddevice database is a mean to improve system performance: theaddition/removal of devices and services to/from the networkis performed through standard KNX protocol primitives, andcached information is updated accordingly.

DomoLogic. This module implements the automated rea-soning functions of the CU by means of an embedded semanticmatchmaker, leveraging algorithm and approach in [26]. Stan-dard and non-standard inference procedures in ALN Descrip-

5

tion Logics (Attributive Language with unqualified Numberrestrictions) are used to carry out a matchmaking processbetween a semantic request and a set of resource/serviceannotations. An algorithm based on the solution of ConceptCovering Problem (CCoP) [27] has been also implemented tocover (i.e., satisfy) features expressed in a request as much aspossible, through the conjunction of services available in theenvironment (seen as elementary building blocks). A requestfrom a user or device starts the interaction sequence shownin Figure 5. Performed steps are: 1) Query the DB, retrieveall services coming from available devices and associate tothem a device address (cache is populated at boot time andexploited to reduce latency). 2) Read the status of each service,through a specific function of KNX Manager module (de-scribed afterwards). Such status can be represented by a string,a numerical or a boolean value according to the associated datatype. 3) Extract semantic annotations from the DB, using the<address,status> pair as a key, and separate services into acti-vated and deactivated sets. 4) Check active services to discoverincompatibilities w.r.t. the request, by means of the ConceptContraction algorithm [22]. Mark incompatible services fordeactivation. 5) Exploiting the Concept Abduction algorithm[22], check whether the request is already completely coveredby active services or not. 6) In the latter case, solve the CCoPto select one or more services that should be activated, whosecombination covers the missing features (a preliminary checkis performed to skip out services in contrast with currentlyactive ones). The algorithm returns two groups of services,respectively marked for activation and deactivation, along withthe semantic expression of the request part that could not becovered (if present).

KNX Manager. This module acts as interface toward thephysical network. It exploits the Calimero NG Java library[28] to control KNX devices, e.g., activate/deactivate servicesaccording to outcomes of DomoLogic module. Calimero NGalso includes several tools and features that simplify networkmanagement. It was extended to access standard and semanticproperties on devices. KNX Manager includes the MessageManager (MM), which performs the following basic tasks:(i) to analyze and extract fields of a KNXnet/IP frame forcontrolling the communication between CU and devices; (ii)to identify semantic frames and manage their content. Noticethat the CU manages plain KNX data and semantic annotationsin a uniform way, so maintaining the compliance with protocolspecification.

Device Agent. As said above, semantic annotations are notcurrently stored into the embedded memory of devices. More-over, legacy or very elementary devices –also widespread inexisting households– have no storage/processing capabilities.It is needed, therefore, to integrate semantic-based capabilitiesinto a software agent associated to each device or set of devicesand equivalent for each user. A Device Agent will be so able toprovide support for semantic enhancements also for simplisticcomponents according to the proposed protocol variant. Insuch cases, if the CU requires standard device properties, therequest will be commonly forwarded on the network, throughthe KNX router, to the given device. Conversely, in casesemantic annotations are needed, the request will be replied

by the agent, as shown in Figure 4.Smart Agent. The semantic extension of KNX standard

aims to develop smart devices able to either declare theirsemantically annotated status and function or send semantic-based requests to the central unit for requiring home services(generated after a sensor data gathering phase or when their in-ternal status changes). To this purpose devices embed a SmartAgent that will take care to communicate and negotiate anenvironmental profile with the CU. Particularly, modificationin the user profile are managed by the agent triggering homestatus modifications through new matchmaking processes. Asshown in Figure 2, smart devices are able to directly send KNXframes over the LAN. In the current system prototype, smartagents are not implemented in physical devices, but simulatedas separate processes running in the computer hosting theCU. However, this constraint does not change the operatinglogic, because in any case the CU sees agent messagesas frames stream coming from network interface. Anywaya smart media center with embedded semantic processingand communication capabilities is under development at themoment, and several commercial home equipments could beable to host smart agents.

B. TestbedBased on the above theoretical framework, the prototypical

testbed depicted in Figure 6(a) was developed to prove itsfeasibility also evaluating provided capabilities. A subset ofhome areas, i.e., a hall door, a living room, a kitchen anda small outdoor space were simulated. Currently, it integrates13 devices/appliances, including both traditional (legacy) elec-trical equipments and KNX-compliant ones, as summarizedin Table I. Devices are connected through a twisted pair busin a hierarchical network structure. They expose 42 differentservices/functionalities as a whole, each one associated toa KNX group address. Since KNX specification does notmandate fixed schemes for address assignment, the followingcriteria have been adopted: Main Group specifies the area;Middle Group denotes the service type, with “0” used forinput-only, “1” for output-only and “2” for I/O services; LittleGroup identifies the service/resource within a given area. Mainpanel, shown in Figure 6(b), stores the electrical components,including a KNX Router. It converts the KNX/EIB telegramsinto IP frames and vice-versa, according to KNXnet/IP stan-dard. Besides, it can buffer telegrams to keep the bus loadlow. The panel also includes four circuit breakers for overloadprotection. Common types of digital (on/off) and analogswitches have been integrated. In particular, panels simulatingliving room and kitchen contain both traditional and dimmerlights. Moreover a testbed face is equipped with an analogactuator to simulate window electric blinds. The prototypicalhouse finally includes an alarm system, composed by an outeralarm, with sensors positioned around the building perimeter,and an internal alarm. It is managed by the control unit inFigure 6(c). Internal alarm comprises a camera (Figure 6(d))and infrared sensors properly placed within the environment.In order to assume the presence of an outdoor area, a weatherstation, shown in Figure 6(e), has been also added to measurewind speed, environmental brightness, rain and temperature.

6

(a) Testbed (b) Main panel

(c) Alarm

(d) Camera

(e) Weatherstation

Fig. 6. Prototypical testbed

Area Device ♯ of ServicesKitchen Electric Oven 1

Kitchen Light 1Living Room Air Conditioner 2

Blind Controller 2Dimmer Light 4DVD Player 8Heating Controller 1Living Room Light 1Music Player 4Massage Chair 1

Hall Door Alarm 4Camera 1

Outdoor Space Weather Station 12

TABLE IDEVICES LIST

The CU is devoted to testbed management and control.It was implemented using Java language and a modifiedversion of Calimero NG library and runs on a laptop PCinterconnected via the IP backbone. In the next section, carriedout experiments on the above testbed are reported.

C. Experiments

The presented case study comprises several scenarios, al-lowing to highlight benefits induced by the proposed archi-tecture w.r.t. standard HBA solutions. Let us suppose a smartweather station interacts with several domotic devices, giventhe presence of two different users at home. The prototypicaltestbed was built as a full-functioning KNX installation. Smartdevices store their semantically annotated service descriptionsin programmable stable memory (e.g., EEPROM or solid statedisks). In the perspective of productization of the proposedtechnology, service profiles should be set at the factory andwill be easily updated by smart devices themselves if endowedwith Internet connection, while semantic requests are producedthrough data gathering, analysis and annotation algorithmsembedded in the devices. On the other hand, for “legacy”devices default profile annotations should be extracted fromthe ETS database and customized by KNX installer; then,during normal system operation, they will be managed by theassociated Device Agent (profiles update from the Internet isnot implemented now, but it can be done trivially). A softwareagent was developed to let the weather station act as smartdevice. Based on data coming from weather sensors, a changein context is detected and a request to adapt the environment is

Device ⊒

Appliance ⊒

{BrownGood ⊒ {. . .WhiteGood ⊒ {. . .

HVACLightingSecurityControllerSafetyController

Service ⊒

EnvironmentTemperatureRegulationLightLevelRegulation ⊒ {. . .SafetyLevelRegulation ⊒ {. . .SecurityLevelRegulation ⊒ {. . .. . .

UserStatus ⊒

PhysicalStatus ⊒

Disease ⊒

FeverHeadache. . .

TemperaturePerception ⊒

HotNormalFreshCold

PsychologicalStatus ⊒

Stamina ⊒{

TiredRested

. . .

GeneralStatus ⊒

Gender ⊒ {. . .AgeRange ⊒ {. . .VideoPreference ⊒ {. . .MusicPreference ⊒ {. . .Handicap ⊒ {. . .

WeatherParameter ⊒

OutdoorBrightness ⊒

LowBrightnessMediumBrightnessHighBrightness

WindSpeed ⊒

LightWindModerateWindStrongWind

WeatherCondition ⊒

SunnyPartlyCloudyCloudyRainy

Fig. 7. Relevant axioms in the case study ontology

issued to the decision-making facilitator, which adjusts homesubsystem/appliance configuration, taking user profiles intoaccount.

It is a sunny morning with mild weather. The home envi-ronment is set to a typical profile with air conditioning turnedon and all blinds open. During the day, it clouds over andlooks like it is about to rain. The smart weather station sensesboth temperature and brightness decrease, as well as windspeed growing and humidity. After a data gathering phase,weather station processes information, so detecting the badturn in the weather, and generates a semantically annotatedevent description.

Figure 7 reports on an excerpt of the main class taxonomyof the domotics ontology O developed for the case study.It contains further class axioms and property definitions, notreported here for the sake of brevity. First-level classes broadlydivide the ontology in sub-domains: devices, services, userstatus, and weather conditions. Second-level classes representmain concepts HBA applications need to model and reasonupon; they are further specialized to provide a more fine-grained characterization. Properties are mostly used to relateuser profiles and device requests to such concepts. For in-stance, the above description from the weather station can beexpressed as follows (classical logic notation is adopted herefor the sake of readability).Weather Station req ≡ ∀ forOutdoorBrightness.LowBrightness ⊓

∀ forWindSpeed.StrongWind ⊓ ∀ forWeatherCondition.Rainy ⊓

∀ forTemperaturePerception.Fresh

It can be pointed out that, according to AmI paradigm,user intervention is not needed to request a specific servicein this case; instead, the updated weather conditions –detected by the station– trigger the agents which adapt theenvironment consequently, with the CU acting as a mediatorand semantic-based facilitator.

7

Case 1 Case 2Active Services Air Conditioner, Music PlayerDevice Request Fresh Perception, Low Brightness, Rain, Strong WindUser Profile Adult Man

HeadacheTired

Old ManCold PerceptionFever

Response Air Conditioner OFFSoft Light Level ONClose Blind ONPlay Music OFF

Air Conditioner OFFHeating Controller ONBright Light Level ONClose Blind ONOuter Alarm ON

TABLE IICASE STUDY CHARACTERIZATION

The annotation, expressed in DIG language w.r.t. ontol-ogy O and compressed, is stored by the agent into one ormore KNX frames and sent, along with OUIIDO, in aA SEMANTIC SUBMISSION.req as explained in Section III.The CU reassembles the message and retrieves environmentalinformation (particularly, currently enabled services) and pro-files of users in the house (cached from recent user requests)referred to the same ontology. Finally, semantic matchmakingis executed by DomoLogic module. In what follows, thesystem behavior is reported for two different home occupants(whose profiles were previously sent by their mobile clientsto the Client Manager), summarized in Table II: (a) an adultman with an intense headache producing a tiredness status;(b) an old man having a fever with strong cold feeling. Theirprofiles are expressed as:U1 ≡ ∀ forGender.Male ⊓ ∀ forAgeRange.Adult ⊓

⊓ ∀ forDisease.Headache ⊓ ∀ forStamina.T ired

U2 ≡ ∀ forGender.Male ⊓ ∀ forAgeRange.Old ⊓

∀ forTemperaturePerception.Cold ⊓ ∀ forDisease.Fever

Let us consider the following available services:Air Conditioning ≡ Service ⊓ ∃forTemperaturePerception ⊓

∀forTemperaturePerception.Hot

Heating Controller ≡ Service ⊓ ∃forTemperaturePerception ⊓

∀forTemperaturePerception.Cold

Soft Light Level ≡ LightLevelRegulation ⊓ ∃forDisease ⊓

∀forDisease.Headache ⊓ ∃forStamina ⊓ ∀forStamina.T ired

Bright Light Level ≡ LightLevelRegulation ⊓

∃forOutdoorBrightness ⊓ ∀forOutdoorBrightness.LowBrightness

Close Blind ≡ Service ⊓ ∃forWeatherCondition ⊓

∀forWeatherCondition.Rainy ⊓ ∃forOutdoorBrightness ⊓

∀forOutdoorBrightness.LowBrightness

Play Music ≡ Service ⊓ ∃forStamina ⊓ ∀forStamina.Rested

Outer Alarm On ≡ SecurityLevelRegulation ⊓ ∃forDisease ⊓

∀ forDisease.(Fever ⊓ Injury)

In the first case, the air conditioner is deactivated and theblinds are closed, due to weather condition. Moreover, thebrightness decrease causes the activation of room lights. Nev-ertheless, as user profile indicates headache, the CU turns offthe music player and selects a soft lighting level to satisfyboth environmental and user constraints. Blinds are closedalso in the second scenario. In that case, however, temperaturereduction causes a stronger cold feeling to the user, inducingthe system to activate heating instead of simply switching offcooling. Furthermore, a bright light level is selected due to lowexternal brightness, considering that no user characteristic is

Fig. 8. Processing Time

in contrast with this functionality. Finally, the outer alarm isactivated for users who cannot move due to fever or injury,while the music player is not disabled because the user doesnot specify anything in contrast with it.Performance analysis was carried out using a laptop PC ascentral unit and a smartphone as mobile client, respectivelyequipped with: Intel Core 2 Duo T7700 CPU (2.4 GHz clockfrequency), 4 GB DDR2 RAM and Ubuntu 10.04 operatingsystem with Java Virtual Machine 1.6.0 17; S5PC111 CPU(1 GHz clock frequency), 512MB RAM and Android 2.1operating system supporting IEEE 802.11 b/g/n and Bluetooth3.0 standard. In order to assess the performance impact of thecommunication medium, a TP1 cable –a worst-case scenario,though common in real KNX installations– was simulated,only for semantic-based annotations retrieved from devicesconnected through twisted pair bus. Each frame was delayedon the LAN to force a maximum transmission rate of 9600bps. It was not needed for virtual KNX devices connecteddirectly to the LAN. Tests were performed to evaluate CUstart-up time and request servicing turnaround time.Results are reported in Figure 8. Start-up is by far the longestphase with over 130 seconds, mainly due to constraints oflow-throughput field bus. Start-up includes several sub-steps:(i) import the XML settings file; (ii) retrieve all serviceannotations, which is the longest step; (iii) parse and pre-process the annotations (executing concept unfolding andnormalization, as explained in [26], in order to apply theproposed inference services), which takes about 300 ms perservice on average; (iv) store the annotations into the CUdatabase; (v) perform an early device scan to find alreadyactive services. It is useful to point out that CU start-up isperformed only once per working cycle, which may last severalhours or days in normal conditions. The subsequent five tasksin the chart are executed only when the CU receives a request.As described in Section IV-A and Figure 5, in the first stepa new device scan is performed to get an updated view ofactive services. Duration depends on the number of devices.In the above case study, this step spends about 1250 ms for13 devices, with an average time of 100 ms per unit. Thefirst reasoning task is compatibility check, then the CCoPis solved. Compatibility check is longer because all servicedescriptions must be evaluated, while only compatible servicesare processed in the CCoP. Finally, the response task includestime needed to send the reply to the requester agent, and toapply changes to the environment by enabling or disabling

8

services. The overall average turnaround time for servicingthe weather station request in the above case study is 2.68 s,which can be deemed as acceptable for an HBA system.

V. CONCLUSION AND FUTURE WORK

The paper presented a semantic enhancement to EIB/KNXHBA standard allowing the integration of knowledge repre-sentation and reasoning technologies with current protocol. Adistributed knowledge-based agent framework has been im-plemented to support advanced, fine-grained resource/servicediscovery grounded on the formal annotation of user char-acteristics and device capabilities. The devised framework hasbeen implemented in a prototypical testbed in order to test bothfeasibility and effectiveness. An early performance evaluationhas been also carried out. Future extensions will includeprotocol optimization to reduce average response times, whilethe design of a structured agent framework running on the usermobile client is now under investigation, able to automaticallybuild user profiles crawling phone PIM (Personal InformationManager), SMS and call lists. Finally, an explicit exploitationof the framework for optimizing household energy consump-tion and load scheduling is a further future direction.

VI. ACKNOWLEDGMENTS

The authors acknowledge partial support of Strategic RegionalProjects PS 025 and PS 121.

REFERENCES

[1] D. Dietrich, D. Bruckner, G. Zucker, and P. Palensky, “Communicationand Computation in Buildings: A Short Introduction and Overview,”Industrial Electronics, IEEE Transactions on, vol. 57, no. 11, pp. 3577–3584, 2010.

[2] N. Shadbolt, “Ambient intelligence,” Intelligent Systems, IEEE, vol. 18,pp. 2–3, July 2003.

[3] H. Nakashima, H. Aghajan, and J. C. Augusto, Eds., Handbook ofAmbient Intelligence and Smart Environments. New York: Springer,2010.

[4] Konnex Association, KNX Handbook for Home and Building Control,5th ed., 2006.

[5] S. Colucci, T. Di Noia, A. Pinto, A. Ragone, M. Ruta, and E. Tinelli, “Anon-monotonic approach to semantic matchmaking and request refine-ment in e-marketplaces,” International Journal of Electronic Commerce,vol. 12, no. 2, pp. 127–154, 2007.

[6] F. Baader, D. Calvanese, D. Mc Guinness, D. Nardi, and P. Patel-Schneider, The Description Logic Handbook. Cambridge UniversityPress, 2002.

[7] S. Bechhofer, R. Moller, and P. Crowther, “The DIG DescriptionLogic Interface,” in Proceedings of the 16th International Workshop onDescription Logics (DL’03), ser. CEUR Workshop Proceedings, vol. 81,Rome, Italy, September 2003.

[8] L. Lo Bello and E. Toscano, “Coexistence Issues of Multiple Co-LocatedIEEE 802.15.4/ZigBee Networks Running on Adjacent Radio Channelsin Industrial Environments,” Industrial Informatics, IEEE Transactionson, vol. 5, no. 2, pp. 157–167, 2009.

[9] K. Gill, S. Yang, F. Yao, and X. Lu, “A ZigBee-based home automationsystem,” Consumer Electronics, IEEE Transactions on, vol. 55, no. 2,pp. 422–430, 2009.

[10] M. E. Pardo, G. E. Strack, and D. C. Martinez, “A Domotic System withRemote Access based on Web Services,” Journal of Computer Science& Technology, July 2008.

[11] S. Theiss, V. Vasyutynskyy, and K. Kabitzsch, “Software agents inindustry: A customized framework in theory and praxis,” IndustrialInformatics, IEEE Transactions on, vol. 5, no. 2, pp. 147–156, 2009.

[12] H. Hagras, V. Callaghan, M. Colley, G. Clarke, A. Pounds-Cornish,and H. Duman, “Creating an ambient-intelligence environment usingembedded agents,” Intelligent Systems, IEEE, vol. 19, no. 6, pp. 12 –20, 2004.

[13] D. Filev, R. Chinnam, F. Tseng, and P. Baruah, “An Industrial StrengthNovelty Detection Framework for Autonomous Equipment Monitoringand Diagnostics,” Industrial Informatics, IEEE Transactions on, vol. 6,no. 4, pp. 767–779, 2010.

[14] V. Miori, L. Tarrini, M. Manca, and G. Tolomei, “An open standardsolution for domotic interoperability,” Consumer Electronics, IEEETransactions on, vol. 52, no. 1, pp. 97–103, 2006.

[15] T. Catarci, F. Cincotti, M. Leoni, M. Mecella, and G. Santucci,“Smart homes for all: Collaborating services in a for-all architecturefor domotics,” Collaborative Computing: Networking, Applications andWorksharing, pp. 56–69, 2009.

[16] T. Cucinotta, A. Mancina, G. Anastasi, G. Lipari, L. Mangeruca,R. Checcozzo, and F. Rusina, “A real-time service-oriented architecturefor industrial automation,” Industrial Informatics, IEEE Transactions on,vol. 5, no. 3, pp. 267–277, 2009.

[17] I. Estevez-Ayres, P. Basanta-Val, M. Garcıa-Valls, J. Fisteus, andL. Almeida, “QoS-aware real-time composition algorithms for service-based applications,” Industrial Informatics, IEEE Transactions on, vol. 5,no. 3, pp. 278–288, 2009.

[18] L. Sommaruga, A. Perri, and F. Furfari, “DomoML-env: an ontologyfor Human Home Interaction,” in Proceedings of SWAP 2005, the 2ndItalian Semantic Web Workshop, Trento, Italy, December 14-16, 2005,CEUR Workshop Proceedings, 2005.

[19] C. Reinisch, W. Granzer, F. Praus, and W. Kastner, “Integration of het-erogeneous building automation systems using ontologies,” in IndustrialElectronics, 2008. IECON 2008. 34th Annual Conference of IEEE, 2008,pp. 2736 –2741.

[20] D. Bonino, E. Castellina, and F. Corno, “The DOG gateway: enablingontology-based intelligent domotic environments,” IEEE Transactionson Consumer Electronics, vol. 54, no. 4, pp. 1656 –1664, november2008.

[21] M. Santofimia, F. Moya, F. Villanueva, D. Villa, and J. Lopez, “In-telligent Agents for Automatic Service Composition in Ambient Intel-ligence,” in Web Intelligence and Intelligent Agents, Z. Usmani, Ed.InTech, 2010, pp. 411–428.

[22] T. Di Noia, E. Di Sciascio, and F. Donini, “Semantic matchmakingas non-monotonic reasoning: A description logic approach,” Journal ofArtificial Intelligence Research, vol. 29, pp. 269–307, 2007.

[23] R. De Virgilio, E. Di Sciascio, M. Ruta, F. Scioscia, and R. Torlone,“Semantic-based RFID Data Management,” in Unique Radio Innovationfor the 21st Century: Building Scalable and Global RFID Networks,D. Ranasinghe, Q. Sheng, and S. Zeadally, Eds. Springer, 2010, pp.111–142.

[24] T. Di Noia, E. Di Sciascio, F. M. Donini, M. Ruta, F. Scioscia,and E. Tinelli, “Semantic-based bluetooth-rfid interaction for advancedresource discovery in pervasive contexts,” International Journal onSemantic Web and Information Systems, vol. 4, no. 1, pp. 50–74, 2008.

[25] F. Heiny, Y. Kyselytsya, and T. Weinzierl, “Virtual KNX/EIB devicesin IP networks,” in KNX Scientific Conference 2004, Deggendorf, FH,2004.

[26] M. Ruta, F. Scioscia, T. Di Noia, and E. Di Sciascio, “Reasoning inPervasive Environments: an Implementation of Concept Abduction withMobile OODBMS,” in 2009 IEEE/WIC/ACM International Conferenceon Web Intelligence. IEEE, 2009, pp. 145–148.

[27] A. Ragone, T. Di Noia, E. Di Sciascio, F. M. Donini, S. Colucci, andF. Colasuonno, “Fully automated web services discovery and compo-sition through concept covering and concept abduction,” InternationalJournal of Web Services Research, vol. 4, no. 3, pp. 85–112, 2007.

[28] B. Malinowsky, G. Neugschwandtner, and W. Kastner, “Calimero: Nextgeneration,” in Proc. KNX Scientific Conference 2007, 2007.

9

Michele Ruta received the laurea degree in Elec-tronics Engineering from the Technical Universityof Bari in 2002 and the Ph.D. in Computer Sciencefrom Technical University of Bari in 2007. He iscurrently assistant professor at Technical Universityof Bari. His research interests include pervasivecomputing and ubiquitous web, mobile e-commerceapplications, knowledge representation systems andapplications for wireless ad hoc contexts. On thesetopics, he has co-authored papers in internationaljournals and conferences. He is involved in various

research projects related to his research interests. He co-authored papers thatreceived the best paper award at the conferences ICEC-2007 and SEMAPRO-2010 and has been Program Committee member of several internationalconferences and workshops in areas related to his research interests.

Floriano Scioscia received the master’s degree inInformation Technology Engineering from Politec-nico di Bari (Technical University of Bari) in 2006,and the Ph.D. in Information Engineering in 2010from the same institution. His thesis received theannual Marco Cadoli award for the best Ph.D. thesisin artificial intelligence from the Italian Associationfor Artificial Intelligence (AI*IA) in 2011. He iscurrently a post-doc research fellow at the Infor-mation Systems Laboratory (SisInfLab) in the sameUniversity. His research interests include pervasive

computing and the Internet of Things, knowledge representation systemsand applications for wireless ad-hoc networks and ubiquitous contexts. Heco-authored about 30 papers in international edited books, journals andconferences and received the best paper award at the conferences ICEC-2007and SEMAPRO-2010.

Eugenio Di Sciascio received the master’s degreewith honours from University of Bari, and the Ph.D.from Politecnico di Bari (Technical University ofBari). He is currently full professor of InformationTechnology Engineering at Technical University ofBari, and leads the research group of SisInfLab, theInformation Systems Laboratory of Technical Uni-versity of Bari. Formerly, he has been an assistantprofessor at University of Lecce and associate pro-fessor at Technical University of Bari. His researchinterests include multimedia information retrieval,

knowledge representation and e-commerce technologies. He is involved inseveral national and European research projects related to his researchinterests. He co-authored papers that received awards at conferences ICEC-2004, IEEE CEC-EEE-2006, ICEC-2007, ESTC 2008, SEMAPRO-2010 andICWE 2010.

Giuseppe Loseto received the master’s degree inInformation Technology Engineering from Politec-nico di Bari (Technical University of Bari) in 2009.He is currently pursuing his Ph.D. in InformationEngineering at the same University. His researchinterests include pervasive computing and the Inter-net of Things, knowledge representation systems andapplications for home and building automation andubiquitous smart environments.