IEEE Transactions on Consumer Electronics, Vol. 54, No. 4, NOVEMBER 2008

Contributed Paper Manuscript received August 28, 2008 0098 3063/08/$20.00 © 2008 IEEE

1656

Dario Bonino, Emiliano Castellina, Fulvio Corno

Abstract — This paper moves a first step towards the crea-

tion of Intelligent Domotic Environments (IDE) in real-life home-living. A new Domotic OSGi Gateway (DOG) is pre-sented, able to manage different domotic networks as a single, technology neutral, home automation system. The adoption of a standard framework such as OSGi, and of sophisticated modeling techniques stemming from the Semantic Web re-search community, allows DOG to go beyond simple automa-tion and to support reasoning-based intelligence inside home environments. By exploiting automatic device generalization, syntactic and semantic command validation, and inter-network scenario definition, DOG provides the building blocks for supporting the evolution of current, isolated, home automation plants into IDEs, where heterogeneous devices and domotic systems are coordinated to behave as a single, intelligent, proactive system. The paper introduces the DOG architecture and the underlying ontology modeling. A case study is also illustrated, where DOG controls a laboratory reconstruction of a simple domotic environment1.

Index Terms — System architectures, integration and model-ing, Ubiquitous computing, Rule-based processing, Knowledge modeling.

I. INTRODUCTION Domotic systems, also known as home automation systems,

have been available on the market for several years, however only in the last few years they started to spread also over residen-tial buildings, thanks to the increasing availability of low cost devices and driven by new emerging needs on house comfort, energy saving, security, communication and multimedia services.

Current domotic solutions suffer from two main drawbacks: they are produced and distributed by various electric compo-nent manufacturers, each having different functional goals and marketing policies; and they are mainly designed as an evolu-tion of traditional electric components (such as switches and relays), thus being unable to natively provide intelligence be-yond simple automation scenarios. The first drawback causes interoperation problems that prevent different domotic plants or components to interact with each other, unless specific gateways or adapters are used. While this was acceptable in the first evolution phase, where installations were few and isolated, now it becomes a very strong issue as many large buildings are mixing different domotic components, often

1 The authors are with the Dipartimento di Automatica ed Informatica of Politecnico di Torino, Torino, Italy. E-mail: {dario.bonino, emiliano.castellina, fulvio.corno}@polito.it

realized with different technologies, and need to coordinate them as a single system. On the other hand, the roots of domo-tic systems in simple electric automation prevent satisfying the current requirements of home inhabitants, who are becoming more and more accustomed to technology and require more complex interactions.

In the literature, solutions to these issues usually propose smart homes [1], [2], [3], i.e., homes pervaded by sensors and actuators and equipped with dedicated hardware and software tools that implement intelligent behaviors. Smart homes have been actively researched since the late 90’s, pursuing a revolu-tionary approach to the home concept, from the design phase to the final deployment. Involved costs are very high and pre-vented, until now, a real diffusion of such systems, that still retain an experimental and futuristic connotation.

The approach proposed in this paper lies somewhat outside of the smart home concept, and is based on extending current domotic systems, by adding a hardware device and software agents for supporting interoperation and intelligence. Our solution takes an evolutionary approach, in which a low cost device (embedded PC) is added to new or existing commercial domotic systems allowing interoperation and supporting more sophisticated automation scenarios. In this case, the domotic system in the home evolves into a more powerful integrated system, that we call Intelligent Domotic Environment (IDE).

Most solutions for IDEs rely on a hardware component called residential [4] or home gateway [5], [6] originally con-ceived for providing Internet connectivity to smart appliances available in a given home. This component, in our approach, is evolved into an interoperation system, called DOG (Domo-tic OSGi Gateway), where connectivity and computational capabilities are exploited to bridge, integrate and coordinate different domotic networks.

DOG exploits OSGi (Open Source Gateway initiative) [11] as a coordination framework for supporting dynamic module activation, hot-plugging of new components and reaction to module failures. Such basic features are integrated with an ontology model of domotic systems and environments named DogOnt. The combination of DOG and DogOnt supports the evolution of domotic systems into IDEs by providing means to integrate different domotic systems, to implement inter-network automation scenarios, to support logic-based intelli-gence and to access domotic systems through a neutral inter-face. Cost and flexibility concerns take a significant part in the platform design and we propose an open-source solution ca-pable of running on low cost hardware systems such as an ASUS eeePC 701.

The DOG Gateway: Enabling Ontology-based Intelligent Domotic Environments

1657D. Bonino et al.: The DOG Gateway: Enabling Ontology-based Intelligent Domotic Environments

The paper is organized as follows: Section II introduces the logic architecture of an Intelligent Domotic Environment and the adopted ontology model. In Section III the DOG platform is described, starting from high-level design issues and includ-ing the description of platform components and their interac-tions, while in Section IV ontology-driven tasks in DOG are described. Section V provides implementation details, with respect to the currently available DOG release and Section VI discusses relevant related works. Eventually Section VII draws conclusions and proposes some future works.

II. INTELLIGENT DOMOTIC ENVIRONMENTS An Intelligent Domotic Environment (IDE, Figure 1) is

usually composed by one2, or more, domotic systems, by a variable set of (smart) home appliances, and by a Home Gateway that allows to implement interoperation policies and to provide intelligent behaviors.

Fig. 1 Intelligent Domotic Environment.

Domotic systems usually include domotic devices such as plugs, lights, doors and shutter actuators, etc., and a so-called network-level gateway that allows to tunnel low-level protocol messages over more versatile, application independent, inter-connection technologies, e.g., Ethernet. Network-level gateways are not suitable for implementing features needed by IDEs as they have reduced computational power and they are usually closed, i.e., they cannot be programmed to provide more than factory default functionalities. However, they play a significant role in an IDE architecture as they offer an easy to exploit ac-cess point to domotic systems.

Appliances can be either “dumb” devices that can only be controlled by switching on and off the plugs to which they are

2 in this case interoperation may not be needed but intelligence still needs to be supported

connected or “smart” devices able to provide complex function-alities and to control (or be controlled by) other devices, through a specific, often IP-based, communication protocol.

The Home Gateway is the key component for achieving in-teroperation and intelligence in IDEs; it is designed to respond to different requirements, ranging from simple bridging of net-work-specific protocols to complex interaction support. These requirements are grouped in 3 priority levels (Table I): priority 1 requirements include all the features needed to control different domotic systems using a single, high-level, communication pro-tocol and a single access point, priority 2 requirements define all the functionalities needed for defining inter-network automation scenarios and to allow inter-network control, e.g., to enable a Konnex switch to control an OpenWebNet light, and priority 3 requirements are related to intelligent behaviors, to user model-ing and to adaptation.

A domotic home equipped with a Home Gateway is defined an Intelligent Domotic Environment if the gateway satisfies at least priority 1 and priority 2 requirements. Priority 3 requirements can be considered advanced functionalities and may impose tighter constraints on the gateway, both from the software architecture and from the computational power points of view.

While priority 1 requirements basically deal with architec-tural and protocol issues, requirements listed in priorities 2 and 3 imply the adoption of sophisticated modeling tech-niques. In fact, the cornerstone of intelligent behaviors and applications is a suitable House Modeling methodology and language (R2.1). In DOG, we chose to adopt a semantic ap-proach and to adopt technologies developed in the Semantic Web community, to solve this knowledge representation prob-lem and enable DOG to host or support intelligent applica-tions.

Modeling the house structure, its domotic components, their states and functionalities is achieved by defining a custom ontology, called DogOnt [7]. According to the classical Gru-ber’s definition [8] an ontology is an “explicit specification of a conceptualization,” which is, in turn, “the objects, concepts, and other entities that are presumed to exist in some area of interest and the relationships that hold among them”. Today’s W3C Semantic Web standard suggests a specific formalism for encoding ontologies (OWL), in several variants that vary in expressive power [9].

Fig. 2 An overview of the DogOnt ontology.

IEEE Transactions on Consumer Electronics, Vol. 54, No. 4, NOVEMBER 2008 1658

TABLE I REQUIREMENTS FOR HOME GATEWAYS IN IDES.

Priority Requirement Description R1 Interoperability R1.1 Domotic network connection Interconnection of several domotic networks. R1.2 Basic Interoperability Translation / forwarding of messages across different networks. R1.3 High level network protocol Technology independent, high-level network protocol for allowing neutral access to

domotic networks. R1.4 API Public API to allow external services to easily interact with home devices. R2 Automation R2.1 Modeling Abstract models to describe the house devices, their states and functionalities, to support

effective user interaction and to provide the basis for home intelligence. R2.2 Complex scenarios Ability to define and operate scenarios involving different networks / components. R3 Intelligence

R3.1 Offline Intelligence Ability to detect misconfigurations, structural problems, security issues, etc.

R3.2 Online Intelligence Ability to implement runtime policies such as energy saving or fire prevention. R3.3 Adaptation Learning of frequent interaction patterns to ease users’ everyday activities. R3.4 Context based Intelligence Proactive behavior driven by the current house state and context aimed at reaching spe-

cific goals such as safety, energy saving, robustness to failures.

DogOnt is an OWL meta-model for the domotics domain describing where a domotic device is located, the set of its capabilities, the technology-specific features needed to inter-face it, and the possible configurations it can assume. Addi-tionally, it models how the home environment is composed and what kind of architectural elements and furniture are placed inside the home. It is organized along 5 main hierarchy trees (Figure 2), including: Building Thing, modeling avail-able things (either controllable or not); Building Environment, modeling where things are located; State, modeling the stable configurations that controllable things can assume; Function-ality, modeling what controllable things can do; and Domotic Network Component, modeling peculiar features of each do-motic plant (or network). The BuildingThing tree subsumes the Controllable concept and its descendants, which are used to model devices belonging to domotic systems or that can be controlled by them.

Fig. 3 A dimmer lamp as modeled in DogOnt.

Devices are described in terms of capabilities (Functionality concept) and possible configurations (State concept). Func-tionalities are mainly divided in Continuous and Discrete, the former describing capabilities that can be variated continu-ously and the latter referring to the ability to change device configurations in a discontinuous manner, e.g., to switch on a light. In addition they are also categorized depending on their goal, i.e., if they allow controlling a device (Control Func-tionality), querying a device condition (Query Functionality)

or notifying a condition change (Notification Functionality). Each functionality instance defines the set of associated com-mands and, for continuous functionalities, the range of al-lowed values, thus enabling runtime validation of commands issued to devices. Devices also possess a state instance deriv-ing from a State subclass, which describes the stable configu-rations that a device can assume. Each State class defines the set of allowed state values; states, like functionalities, are di-vided in Continuous and Discrete. Figure 3 shows the DogOnt representation of a dimmer lamp.

DOG uses the DogOnt ontology for implementing several functionalities (Section IV) encompassing command valida-tion at run-time, using information encoded in functionalities, stateful operation, using the state instances associated to each device, device abstraction leveraging the hierarchy of classes in the controllable sub-tree. The last operation, in par-ticular, allows dealing with unknown devices treating them as a more generic type, e.g., a dimmer lamp can be controlled as a simple on/off lamp. Ontology instances modeling controlled environments are created off-line by means of proper editing tools, some of which are currently being designed by the au-thors, and may leverage auto-discovery facilities provided by the domotic systems interfaced by DOG.

III. DOG ARCHITECTURE DOG is a home gateway designed to transform new or ex-

isting domotic installations into IDEs by fulfilling the re-quirements defined in Section II. Design principles include versatility, addressed through the adoption of an OSGi based architecture, advanced intelligence support, tackled by for-mally modeling the home environment and by defining suit-able reasoning mechanisms, and accessibility to external ap-plications, through a well defined, standard API also available through an XML-RPC [10] interface. OSGi [11] is an Univer-sal Middleware that provides a service-oriented, component-based environment for developers and offers standardized ways to manage the software life cycle. It provides a general-purpose, secure, and managed framework that supports the deployment of extensible service applications known as bun-dles.

1659D. Bonino et al.: The DOG Gateway: Enabling Ontology-based Intelligent Domotic Environments

DOG is organized in a layered architecture with 4 rings, each dealing with different tasks and goals, ranging from low-level interconnection issues to high-level modeling and inter-facing (Figure 4). Each ring includes several OSGi bundles, corresponding to the functional modules of the platform. Ring 0 includes the DOG common library and the bundles necessary to control and manage interactions between the OSGi platform and the other DOG bundles. At this level, sys-tem events related to runtime configurations, errors or failures, are generated and forwarded to the entire DOG platform.

Fig. 4 DOG architecture.

Ring 1 encompasses the DOG bundles that provide an inter-face to the various domotic networks to which DOG can be connected. Each network technology is managed by a dedi-cated driver, which abstracts network-specific protocols into a common, high-level representation that allows to uniformly drive different devices (thus satisfying requirement R1.1). Ring 2 provides the routing infrastructure for messages travel-ing across network drivers and directed to DOG bundles. Ring 2 also hosts the core intelligence of DOG, based on the DogOnt ontology, that is implemented in the House Model bundle (R1.2, R1.3, R2.1 and, partially, R2.23). Ring 3 hosts the DOG bundles offering access to external applications, either by means of an API bundle, for OSGi ap-plications, or by an XML-RPC endpoint for applications based on other technologies (R1.4).

In the following, services and functionalities of each bundle are described in more detail.

A. Ring 0 DOG library This bundle acts as a library repository for all other DOG bundles. In particular, it defines the interfaces (listed in Table II) through which bundles can interact. Inter-action of different bundles is based on exchanging DogMes-sage objects, also defined here. DogMessages are composed by a type declaration, that identifies the type of content, and a

3 In the currently implemented version, external applications can control

many domotic networks as a single home automation system, while network-to-network integration is still being implemented.

payload that stores the content. A subset of DogMessages is also available to external applications, either through OSGi integration or XML-RPC calls: such exposed messages are called DogML messages, and are encoded in XML according to the DogMLSchema (XSD) provided by the DOG Library bundle. Platform manager This bundle handles the correct startup of the whole system and manages the life cycle of DOG bundles. The platform manager coordinates bundle activations, enforc-ing the correct start-up order, and manages bundle errors with a two-stage strategy. First, it attempts to restart modules brought down by uncaught exceptions, then, if after re-bootstrapping bundles are still in error, it notifies the unavail-ability of the interrupted services to all other DOG bundles. The platform manager can be extended to integrate principles from autonomic computing, exploiting more advanced tech-niques to react to failures and keeping DOG operational, as long as possible. Configuration Registry The Configuration Registry imple-ments the Configurator interface by maintaining and export-ing bundle configuration parameters. Typical examples of these parameters are the ontology repository location for the House Model bundle, the bundle versions needed to manage compatibility issues, and so on.

B. Ring 1 Network Drivers In order to interface domotic networks, DOG provides a set of Network Drivers, one per each different technol-ogy (e.g., KNX, OpenWebNet, X10 [12], etc.). Every network driver implements a “self-configuration” phase, in which it inter-acts with the House Model (through the HouseModeling interface) to retrieve the list of devices to be managed, together with a de-scription of their functionalities, in the DogOnt format. Every de-vice description carries all the needed low-level information like the device address, according to the network dependent addressing format (simple in OpenWebNet, subdivided in group and individ-ual addresses in KNX, etc.). Network Drivers translate messages back and forth between Dog bundles and network-level gateways; they implement the CommandExecutor interface that supports que-ries and commands issued by other DOG bundles. In addition, they use the services defined by the StatusListener interface to propa-gate state changes to registered listeners (the DOG Status bundle, for example). Monitoring, at the Network Driver level, can either be done by listening to network events or by performing polling cycles when domotic networks do not propagate state-change mes-sages. In both cases, the driver bundles provide state updates to the other DOG bundles by using the typical event-based interaction paradigm supported by OSGi. Currently three Network Drivers have already been developed: Konnex, OpenWebNet and Simulator. Konnex and OpenWeb-Net drivers translate DogMessages into protocol messages of the corresponding networks. The Simulator driver, instead, emulates a synthetic environment by either generating random events or by re-playing recorded event traces (this allows to simulate critical situations in a safe environment).

IEEE Transactions on Consumer Electronics, Vol. 54, No. 4, NOVEMBER 2008 1660

TABLE II INTERFACES DEFINED BY THE DOG LIBRARY BUNDLE

Interface Description ApiConnector Allows OSGi bundles to control the domotic environment through a technology independent set of functionalities. More pre-

cisely, it allows to get the IDE configuration, to send commands to connected devices, to query the device states and to receive state-change notifications.

Configurable Supports runtime configuration of bundles. Every Configurable bundle can be tuned by external applications, that can adjust the parameters exposed through this interface.

CommandExecutor Provides means to propagate commands to the proper bundles. HouseModeling Provides access to the house formal model (DogOnt). It is used to retrieve the house configuration, which is propagated to

network drivers, to get device re-mapping, allowing to automatically recognize new devices, to semantically check commands and notifications, and to resolve group commands (scenarios).

StateAndCommandChecker Defines methods for validating commands and states in DOG. Validation is both syntactic, ensuring that received messages (in XML) are well formed and valid, and semantic, thus guaranteeing that every device is driven by using the appropriate com-mands according to the HouseModeling interface.

StateListener Allows bundles to be notified when managed devices change their states. StateProvider Provides information about the current state of devices. Configurator Defines a repository of start-up bundle configurations. Each bundle accesses the services exposed through this interface in the

start-up phase, to retrieve the needed configuration parameters. DevicesListUpgrade Permits to update the routing tables and the list of devices currently managed by DOG. In conjunction with the Configurable

interface, it allows runtime changes of the DOG configuration, supporting dynamic scenarios where new devices / networks can be hot-plugged into the system.

C. Ring 2 Message Dispatcher This bundle acts as an internal router, delivering messages to the correct destinations, be they the network drivers (commands and state polls) or other DOG bundles (notifications). Routing is driven by a routing table where network drivers are associated to high-level device identifiers, enabling DOG to deliver commands to the right domotic network. For example, if a high-level DogMessage specifies that the kitchen light must be lit, and if the House Model reports that the light belongs to Konnex plant, then the message dispatcher routes the message to the Konnex network driver. The routing table, dynamically built through the De-vicesListUpgrade service, is initially provided by the Configu-rator bundle during the start up phase and constantly updated by Network Drivers.

Executor The Executor validates commands received from the API bundle, either directly or through the XML-RPC pro-tocol. Commands are syntactically validated, by checking the relation between DogMessage type declaration and DogMes-sage content, and semantically validated, by checking them against the set of commands modeled by the HouseModel ontology. If all checks are passed, the Executor forwards mes-sages to the Message Dispatcher for the final delivery. Other-wise messages are dropped, avoiding to generate a platform inconsistent state. Thanks to its role in filtering and checking high-level messages in DOG, the Executor is a suitable candi-date for future implementations of rule-based, runtime auto-mation scenarios or safety policies, including command priori-tization, required for implementing security and manual over-ride mechanisms. Status The Status bundle caches the states of all devices con-trolled by DOG by listening for notifications coming from network drivers. This state cache is extensively used in DOG to reduce network traffic on domotic busses, and to filter out un-necessary commands, e.g., commands whose effects leave the state of the destination devices unchanged.

Since missed network-level messages or other network-related errors may result in an occasional state cache inconsistency, the Status bundle performs a low priority polling cycle, in which suitable DogMessages are generated for querying Net-work Drivers and consequently updating the state cache. The same query messages can also be generated by the API bundle for directly taking a real-time snapshot of the house state, by-passing the Status module. House Model The House Model is the core of intelligence of the DOG platform. It is based on a formal model of the house defined by instantiating the DogOnt ontology (Section II). The House Model loads the ontology and provides external inter-faces to query ontology contents. In this way, most complex semantic elaborations (described in Section IV) are confined within the House Model bundle, and the rest of DOG may operate with simpler message exchanges.

D. Ring 3 API Services provided by DOG are exposed to external OSGi-based applications by means of the API bundle. Four main functionalities are provided according to the ApiConnec-tor interface:

• getConfiguration. The ability to request the house configuration, including the possible states and the allowed commands of each device managed by DOG.

• setCommand. The ability to send single and multiple commands to devices managed by DOG, independ-ently from the domotic network to which they are connected (thus supporting inter-network scenarios).

• setListener. The possibility to register an application as event listener, thus enabling event-based interac-tion with IDEs, even if managed networks natively require a polling-based interaction.

• getDeviceStatus. The ability to directly check the state of house devices, bypassing the internal cache hosted by the Status bundle.

1661D. Bonino et al.: The DOG Gateway: Enabling Ontology-based Intelligent Domotic Environments

The API bundle is able to directly interact with the House-Model every time a complex, multiple command must be resolved into a set of single commands to be issued to the proper network drivers. For example, the command for switching all lights off is converted by the API module in a set of “Switch OFF” commands issued to all devices modeled as Lamp in the House Model ontology.

Messages exchanged between the API bundle and external OSGi applications must conform to the DogML schema defined by the DOG Library bundle.

XmlRPC The XmlRPC bundle simply provides an XMLRPC endpoint for services offered by the API bundle, thus enabling non-OSGi applications to exploit DOG services. It implements a light-weight web server able to listen for remote procedure calls and to map such calls to API calls.

IV. ONTOLOGY-BASED INTEROPERATION IN DOG

A. Start-up In the start-up phase (Figure 5), information contained in the

DogOnt ontology instantiation that models the controlled environ-ment, and exposed through the House Model bundle, is queried to configure network drivers and to deal with unknown device types.

Fig. 5 The DOG start-up sequence diagram.

When a DOG instance is run, DOG bundles are started, with a bootstrap order defined by the Platform Manager bundle.

The House Model is one of the first available services and is used by network drivers to get the list of their managed de-vices. The first interaction step involves querying a DogOnt instantiation, using constructs defined in the W3C standard query language for RDF (SPARQL [13]), for extracting de-vice descriptions, filtered by technology (e.g., searching spe-cific DomoticNetworkComponent instances).

Each device description contains the device name as well as all the low level details needed by drivers to communicate with the corresponding real device. Once the complete device list is received, each driver builds a mapping table for translat-ing high-level commands and states defined in DogOnt into suitable sequences of protocol-specific messages. In this phase, drivers can possibly find unsupported devices, i.e., de-

vices that they cannot control as no mapping between high and low level messages is defined, yet. In this case, a further interaction with the House Model requests a generalization step for instances of unknown devices. For each unknown device, the House Model retrieves the super-classes and pro-vides their descriptions back to the network drivers. In this way specific devices (e.g., a dimmer lamp) can be treated as more generic and simpler ones (e.g., a lamp), for which net-work drivers have the proper mapping information. This automatic reconfiguration capability to deal with unsupported devices sustains DOG scalability: even if devices (and their formalization) evolve more rapidly than drivers, they can still be (partially) controlled by DOG.

B. Runtime command validation At runtime, the DogOnt instantiation exposed by the House

Model is exploited to semantically validate received requests and internally generated commands.

Fig. 6 The DogMessage validation process.

For each DogMessage requiring the execution of a command, i.e., requiring an action on a given domotic component, the command value is validated against the set of possible values defined in DogOnt for that component type. Validation pro-ceeds as in Figure 6: when a DogMessage containing a com-mand needs validation, the House Model queries DogOnt for allowed commands (Figure 7) and, if necessary, retrieves the allowed range associated to each of its parameters. If the DogMessage command complies with constraints extracted from the ontology model, the command is considered valid and propagation to the DOG Message Dispatcher is allowed, otherwise the command is rejected, the message is dropped and the anomaly is logged.

C. Interoperation Besides validation and automatic generalization of devices,

the DOG House Model supports definition of inter-network scenarios and permits to issue commands involving devices

IEEE Transactions on Consumer Electronics, Vol. 54, No. 4, NOVEMBER 2008 1662

located in different domotic networks. Every DogMessage is based on the DogOnt representation of devices (either real or virtual), which is independent from underlying technologies. This allows to perform neutral API calls that are then routed by the Message Dispatcher bundle to the correct Network Driver.

SELECT ?h WHERE

{ dog:DimmerLamp rdfs:subClassOf ?q.

?q rdfs:subClassOf ?y.

?y rdf:type owl:Restriction.

?y owl:onProperty dog:hasFunctionality.

?y owl:hasValue ?z.

?z a ?p.

?p rdfs:subClassOf ?l.

?l rdf:type owl:Restriction.

?l owl:onProperty dog:commands.

?l owl:hasValue ?h}

Fig. 7 The SPARQL query needed to retrieve the commands that can be issued to a DimmerLamp.

Interoperation can be of two main kinds: network-to-network and application-to-network. In the former, devices belonging to a given domotic system, e.g., a Konnex button, communicate with devices connected to another network, e.g. a OpenWebNet Lamp. The latter, instead, is required when-ever an application (either OSGi-based or XML-RPC enabled) needs to interact with devices belonging to different domotic systems, at the same time. DOG currently supports applica-tion-to-network interoperation by exploiting SPARQL queries on the ontology and automatic DogMessage generation. Example Consider a sample interoperation scenario where all the lights of a given domotic home must be switched off (al-lOFF). Some rooms of the sample home have lights controlled by a Konnex plant while the remaining are managed through a BTicino MyHome plant (OpenWebNet).

To activate the allOFF scenario, external applications send to DOG a message stating that all Lamps must be turned off. The DOG API bundle reacts by querying the DogOnt ontol-ogy for all devices of class Lamp. The transitive closure of DogOnt, performed by the HouseModel during start-up, en-sures that all sub-types of Lamp (e.g., dimmer lamps, flashing lamps, etc.) are retrieved by the query process (Figure 8), too.

SELECT ?lamp WHERE

{?lamp rdf:type dog:Lamp}

Fig. 8 The SPARQL query that retrieves all Lamps, independently from the domotic system they are connected to.

After retrieving all involved devices (in a network-independent manner), the API bundle automatically generates a set of DogMessages, one per each discovered lamp, and forwards them to the CommandExecutor bundle. Messages are then validated and propagated to the MessageDispatcher

bundle that routes them towards the correct NetworkDrivers. Each NetworkDriver translates the received commands into network-specific protocol messages, resulting in a simultane-ous, deactivation of lamps managed by domotic plants con-nected to DOG. Figure 9 shows a sequence diagram of the entire process.

V. IMPLEMENTATION AND CASE STUDY DOG has been implemented in Java, as a set of 12 OSGi

bundles running on the Equinox open source framework [14]. The DogOnt ontology is managed by the HouseModel using the HP Jena API [15] while the XML-RPC module exploits the Apache XML-RPC API [16]. DOG is currently released on SourceForge [17] under the Apache license. It runs on very cheap devices such as an ASUS eeePC 701: a sub-laptop equipped with a Intel Celeron processor, 512 Mbytes of RAM and a 4 Gb Solid-State Disk.

Fig. 9 Application-to-network interoperation.

Currently available DOG releases include 3 packages: a core DOG distribution, the OpenWebNet network driver and the Konnex network driver. Core DOG includes all the DOG bun-dles, a Simulator network driver, which allows to experiment with DOG in isolation, without requiring any domotic plant to be connected to the platform, and a sample instantiation of DogOnt describing a reference home environment. By adding the provided network drivers to the DOG plugins directory, the core DOG distribution becomes able to control OpenWebNet and Konnex domotic systems. The two drivers are currently in different maturity stages: the first completely support the OpenWebNet set of functionalities as the protocol is open and well documented, while the second only provides simple on-off capabilities and is still under development. The reference environment currently shipped with DOG cor-responds to a 6-rooms flat (Figure 10) equipped with several devices (lamps, shutter actuators, alarms, smoke sensors, etc., listed in Table III). This configuration partially corresponds to devices available on a BTicino MyHome demo-box kindly donated by the manufacturer, and a Konnex demo-box crafted by using off-the-shelf components from Merten and Siemens.

1663D. Bonino et al.: The DOG Gateway: Enabling Ontology-based Intelligent Domotic Environments

Fig. 10 The reference environment distributed with DOG releases.

These boxes are currently used to perform functional tests as well as interoperation tests.

TABLE III COMPONENTS IN THE REFERENCE ENVIRONMENT

Domotic Device Count Push Button 27 Lamp 7 Plug 23 Door Actuator 7 Window Actuator 6 Shutter Actuator 6 Door Sensor 7 Window Sensor 6 Infrared Sensor 5 Smoke Sensor 6 Appliances 8 Structural Element Count Furniture 28 Architectural 30

VI. RELATED WORKS Many research works are evolving towards the concept of In-

telligent Domotic Environment, by adopting either centralized or distributed approaches that extend current domotic systems with suitable devices or agents. The decreasing cost of hardware and the constant increase in computational power and connec-tion capabilities is a major driving force, towards systems based on simple, embedded PCs. In this context, Miori et al. [18] de-fined a framework called DomoNet for domotic interoperability based on Web Services, XML and Internet protocols. DomoNet defines so-called TechManagers, one per each integrated net-work, that expose the domotic network capabilities as Web Ser-vices and act as proxies for the capabilities of other networks (exposed by corresponding TechManagers). TechManagers dynamically discover, register and de-register services through standard Web Service facilities such as UDDI. DomoNet differs from DOG in several aspects: first it replicates many functional-ities in virtual devices (proxies) available on each TechMan-ager, requiring a considerable synchronization work, while DOG only allocates the necessary resources implementing a

centralized approach. Second, DomoNet, although based on an ontology model (DomoML), does not exploit facilities such as device abstraction/categorization, functionality description and matching, and simply uses the ontology as a common vocabu-lary for high-level XML messages.

DOG, instead, models the home environment and the domo-tic devices with a proper ontology (DogOnt) and leverages in-formation encoded in such model to support device generaliza-tion (e.g., treating a dimmer lamp as a simple lamp), device functionality and device state description. Eventually, DomoNet does not define a clear interface for external applications to in-teract with the domotic system, directly exposing devices as separate Web Services while DOG provides a single access point with a well defined interaction API that hides unnecessary details.

Moon et al. [19] worked on a so-called Universal Middleware Bridge for allowing interoperability of heterogeneous house networks. Similarly to DOG, UMB adopts a centralized archi-tecture where each device/network is integrated by means of a proper UMB Adaptor. The Adaptor converts device-specific communication protocols and data (status, functions, etc.) in to a global, shared representation which is then used to support in-teroperability. Differently from DOG, devices are described and abstracted by means of a Universal Device Template, without an attached formal semantics. This prevents the system to auto-matically perform generalization of device, functionality ab-straction/matching and reasoning. UMB does not define a stan-dard access point for the network it manages, and requires ap-plications to implement a proper connection logic (UMB Adap-tor) to interact with home devices and networks. The home server, in UMB, is seen more as a router, which correctly deliv-ers messages between different Adaptors (i.e., networks or de-vices), than as an intelligent component able to coordinate the connected devices/networks to reach some goal.

Tokunaga et al. [20] defined a framework for connecting home computing middleware, which tackles the problem of switching from one-to-one protocol bridges to one-to-many conversions. In their work, Tokunaga et al. defined home computing middlewares able to abstract/control physical de-vices allowing to coordinate several appliances without a spe-cific notion of used networks or protocols. Conversion of pro-tocols is done by the so-called Protocol Conversion Manager, that translates local information into a newly defined Virtual Service Gateway protocol. Different protocol conversions can be combined to achieve multi-network or multi-device inter-operability. This work is pretty similar to DomoNet as each appliance or network requires a dedicated Protocol Conver-sion Manager and a dedicated Virtual Service Gateway inter-face that provides access to the other appliances available in the system. Discovery of available services and functionalities is done through an XML-based Virtual Service Repository. The main shortcomings of this approach, with respect to DOG are: replication, as any appliance needs a service proxy for interacting with all other appliances; lack of a common access

IEEE Transactions on Consumer Electronics, Vol. 54, No. 4, NOVEMBER 2008 1664

API, as applications shall implement a client proxy to interact with appliances and shall autonomously discover available devices and functionalities; absence of a formal model sup-porting device and functionality generalization, automatic functionality matching, and reasoning.

TABLE IV REQUIREMENTS SATISFIED BY RELATED WORKS, IN COMPARISON WITH

DOG. Req. DomoNet UMB [20] DOG R1.1 ++ ++ ++ ++ R1.2 ++ ++ ++ ++ R1.3 ++ ++ ++ ++ R1.4 + - + ++ R2.1 + - -- ++ R2.2 + + + + R3.1 -- -- -- - R3.2 -- -- -- - R3.3 -- -- -- - R3.4 -- -- -- --

Legend: ++completely satisfied, +partially satisfied, -easily satisfiable in the current architecture, --requires significant platform reengineering.

Table IV shows the degree with which DOG, and the re-

lated works described in this section, satisfy requirements for IDE domotic gateways (listed in Table I).

VII. CONCLUSIONS This paper proposed the DOG platform as a means to

smoothly evolve simple, isolated domotic networks into com-prehensive, home-wide Intelligent Domotic Environments. Several issues have been addressed related to network inter-operation, to flexible integration and to cost affordability. Based on a sound, dynamic framework such as OSGi, DOG allows to manage different networks in a light-weigth manner, exploiting the DogOnt ontology to support complex interop-eration, generalization and validation tasks. Many interesting research streams stem from this first work on semantics-based domotic interoperation; the authors are currently using the DogOnt model to perform structural and functional reasoning on the environment controlled by DOG and, at the same time, they are developing semantic-based autonomic policies for DOG to intelligently handle device failures.

REFERENCES [1] D. J. Cook, G. M. Youngblood, E. O. H. III, K. Gopalratnam, S. Rao, A.

Litvin, and F. Khawaja, “MavHome: An Agent-Based Smart Home.” in International Conference on Pervasive Computing and Communications. IEEE Computer Society, 2003, pp. 521–524.

[2] S. Davidoff, M. K. Lee, J. Zimmerman, and A. Dey, “Principle of Smart Home Control,” in Proceedings of the Conference on Ubiquitous Com-puting. Springer, 2006, pp. 19–34.

[3] S. S. Intille, “Designing a Home of the Future,” IEEE Pervasive Com-puting, vol. 1, no. 2, pp. 76–82, 2002.

[4] S.-L. Chung and W.-Y. Chen, “MyHome: A Residential Server for Smart Homes,” Knowledge-Based Intelligent Information and Engineer-ing Systems, vol. 4693/2007, pp. 664–670, 2007.

[5] T. Saito, I. Tomoda, Y. Takabatake, J. Arni, and K. Teramoto, “Home gateway architecture and its implementation,” IEEE Transactions on Consumer Electronics, vol. 46, no. 4, pp. 1161–1166, Nov 2000.

[6] “Home gateway technical requirements: Residential profile,” Home Gateway Initiative, Tech. Rep., 2008.

[7] D. Bonino and F. Corno, “DogOnt - Ontology Modeling for Intelligent Domotic Environments,” in Proceedings of the 7th International Seman-tic Web Conference. Springer, 2008.

[8] T. Gruber, “Toward principles for the design of ontologies used for knowledge sharing,” International Journal Human-Computer Studies, vol. 43(5-6), pp. 907–928, 1995.

[9] D. L. McGuinness and F. van Harmelen, “Owl web ontology language,” W3C Recommendation, http://www.w3.org/TR/owl-features/, February 2004.

[10] D. Winer, “XML-RPC specification,” UserLand Software, Tech. Rep., 2003.

[11] “Osgi service platform release 4,” http://www.osgi.org/, The OSGi alli-ance, Tech. Rep., 2007.

[12] D. Rye, “The X10 PowerHouse powerline interface,” http://www.x10.com, X10 PowerHouse, Tech. Rep., 2001.

[13] E. Prud’hommeaux and A. Seaborne, “SPARQL Query Language for RDF (W3C recommendation),” http://www.w3.org/TR/rdf-sparql-query/, January 2008.

[14] “The Eclipse Equinox project,” http://www.eclipse.org/equinox/. [15] “The HP Jena API,” http://jena.sourceforge.net/. [16] “The Apache XML-RPC API,” http://ws.apache.org/xmlrpc/. [17] D. Bonino, E. Castellina, and F. Corno, “The DOG Domotic OSGi Gate-

way,” http://domoticdog.sourceforge.net, June 2008. [18] V. Miori, L. Tarrini, M. Manca, and G. Tolomei, “An Open Standard

Solution for Domotic Interoperability,” IEEE Transactions on Consumer Electronics, vol. 52, pp. 97–103, 2006.

[19] K.-D. Moon, Y.-H. Lee, C.-E. Lee, and Y.-S. Son, “Design of a Univer-sal Middleware Bridge for Device Interoperability in Heterogeneous Home Network Middleware,” IEEE Transactions on Consumer Electron-ics, vol. 51, pp. 314–318, 2005.

[20] E. Tokunaga, H. Ishikawa, M. Kurahashi, Y. Morimoto, and T. Naka-jima, “A Framework for Connecting Home Computing Middleware,” in International Conference on Distributed Computing Systems Workshops (ICDCSW’02), 2002

Dario Bonino (Ph.D) is a research assistant in the e-Lite research group at the Department of Computer Science and Automation of Politecnico di Torino. He received his M.S. and Ph.D. degrees in Electronics and Computer Science Engineering, respectively, from Politecnico di Torino in 2002 and 2006. His interests include Semantic Web technologies, with a focus on architectures for se-mantic annotation, indexing and retrieval of web re-

sources, domotics and semantic-aware, home-related technologies. He is the manager of the H-DOSE semantic platform and collaborates to other open source projects including Ontosphere3D. He published 24 papers at interna-tional conferences.

Emiliano Castellina (M.S.) is a Ph.D. candidate at the Department of Computer Science and Automation of Politecnico di Torino. He received his M.S. degree in Computer Science Engineering from the same institution in 2005. His current research interests include eye track-ing (analysis and studies on gaze tracking algorithms), Computer Assistive Technologies (development of spe-cial software applications for disabled people) and Domo-

tic Systems. He published 4 papers at international conferences.

Fulvio Corno (Ph.D) is an Associate Professor at the Department of Computer Science and Automation of Politecnico di Torino. He received his M.S. and Ph.D. degrees in Electronics and Computer Science Engineering from Politecnico di Torino in 1991 and 1995. He is in-volved in several research projects. His current research interests include the application of semantic technologies to web systems, the design of Intelligent Domotic Envi-

ronments, and interfaces for alternative access to computer systems. He pub-lished more than 150 papers at international conferences and 15 on interna-tional journals.