1656

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

The DOG Gateway: Enabling Ontology-based Intelligent Domotic Environments

Dario Bonino, Emiliano Castellina, Fulvio Corno
Abstract This paper moves a first step towards the creation of Intelligent Domotic Environments (IDE) in real-life home-living. A new Domotic OSGi Gateway (DOG) is presented, 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 research community, allows DOG to go beyond simple automation and to support reasoning-based intelligence inside home environments. By exploiting automatic device generalization, syntactic and semantic command validation, and internetwork 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 modeling, 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 residential 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 component manufacturers, each having different functional goals and marketing policies; and they are mainly designed as an evolution of traditional electric components (such as switches and relays), thus being unable to natively provide intelligence beyond 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
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 Contributed Paper Manuscript received August 28, 2008
1

realized with different technologies, and need to coordinate them as a single system. On the other hand, the roots of domotic 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 90s, pursuing a revolutionary approach to the home concept, from the design phase to the final deployment. Involved costs are very high and prevented, 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 conceived 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 (Domotic 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 internetwork automation scenarios, to support logic-based intelligence and to access domotic systems through a neutral interface. Cost and flexibility concerns take a significant part in the platform design and we propose an open-source solution capable of running on low cost hardware systems such as an ASUS eeePC 701.

0098 3063/08/$20.00 2008 IEEE

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

1657

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 including the description of platform components and their interactions, 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, interconnection 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 access 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 functionalities 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 interoperation and intelligence in IDEs; it is designed to respond to different requirements, ranging from simple bridging of network-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 protocol 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 modeling 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 architectural and protocol issues, requirements listed in priorities 2 and 3 imply the adoption of sophisticated modeling techniques. 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 approach and to adopt technologies developed in the Semantic Web community, to solve this knowledge representation problem and enable DOG to host or support intelligent applications. 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 Grubers 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. Todays 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.

1658

IEEE Transactions on Consumer Electronics, Vol. 54, No. 4, NOVEMBER 2008 TABLE I REQUIREMENTS FOR HOME GATEWAYS IN IDES. Requirement Description 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.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.1 Offline Intelligence Ability to detect misconfigurations, structural problems, security issues, etc. R3.2 Online Intelligence R3.3 Adaptation R3.4 Context based Intelligence Ability to implement runtime policies such as energy saving or fire prevention. Learning of frequent interaction patterns to ease users everyday activities. Proactive behavior driven by the current house state and context aimed at reaching specific goals such as safety, energy saving, robustness to failures.

Priority R1 Interoperability

R2 Automation

R3 Intelligence

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 interface it, and the possible configurations it can assume. Additionally, 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 available things (either controllable or not); Building Environment, modeling where things are located; State, modeling the stable configurations that controllable things can assume; Functionality, modeling what controllable things can do; and Domotic Network Component, modeling peculiar features of each domotic 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.

or notifying a condition change (Notification Functionality). Each functionality instance defines the set of associated commands and, for continuous functionalities, the range of allowed values, thus enabling runtime validation of commands issued to devices. Devices also possess a state instance deriving from a State subclass, which describes the stable configurations that a device can assume. Each State class defines the set of allowed state values; states, like functionalities, are divided 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 validation 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 particular, 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 authors, 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 existing domotic installations into IDEs by fulfilling the requirements defined in Section II. Design principles include versatility, addressed through the adoption of an OSGi based architecture, advanced intelligence support, tackled by formally modeling the home environment and by defining suitable reasoning mechanisms, and accessibility to external applications, through a well defined, standard API also available through an XML-RPC [10] interface. OSGi [11] is an Universal Middleware that provides a service-oriented, componentbased environment for developers and offers standardized ways to manage the software life cycle. It provides a generalpurpose, secure, and managed framework that supports the deployment of extensible service applications known as bundles.

Fig. 3 A dimmer lamp as modeled in DogOnt.

Devices are described in terms of capabilities (Functionality concept) and possible configurations (State concept). Functionalities are mainly divided in Continuous and Discrete, the former describing capabilities that can be variated continuously 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 Functionality), querying a device condition (Query Functionality)

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

1659

DOG is organized in a layered architecture with 4 rings, each dealing with different tasks and goals, ranging from lowlevel interconnection issues to high-level modeling and interfacing (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, system events related to runtime configurations, errors or failures, are generated and forwarded to the entire DOG platform.

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, enforcing 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 rebootstrapping bundles are still in error, it notifies the unavailability of the interrupted services to all other DOG bundles. The platform manager can be extended to integrate principles from autonomic computing, exploiting more advanced techniques to react to failures and keeping DOG operational, as long as possible. Configuration Registry The Configuration Registry implements the Configurator interface by maintaining and exporting 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 technology (e.g., KNX, OpenWebNet, X10 [12], etc.). Every network driver implements a self-configuration phase, in which it interacts with the House Model (through the HouseModeling interface) to retrieve the list of devices to be managed, together with a description of their functionalities, in the DogOnt format. Every device 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 individual 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 queries and commands issued by other DOG bundles. In addition, they use the services defined by the StatusListener interface to propagate 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 messages. 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 OpenWebNet 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).

Fig. 4 DOG architecture.

Ring 1 encompasses the DOG bundles that provide an interface to the various domotic networks to which DOG can be connected. Each network technology is managed by a dedicated 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 traveling 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 applications, 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. Interaction of different bundles is based on exchanging DogMessage 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 networkto-network integration is still being implemented.

1660

IEEE Transactions on Consumer Electronics, Vol. 54, No. 4, NOVEMBER 2008 TABLE II INTERFACES DEFINED BY THE DOG LIBRARY BUNDLE

Interface ApiConnector Configurable CommandExecutor HouseModeling StateAndCommandChecker StateListener StateProvider Configurator DevicesListUpgrade

Description Allows OSGi bundles to control the domotic environment through a technology independent set of functionalities. More precisely, it allows to get the IDE configuration, to send commands to connected devices, to query the device states and to receive state-change notifications. Supports runtime configuration of bundles. Every Configurable bundle can be tuned by external applications, that can adjust the parameters exposed through this interface. Provides means to propagate commands to the proper bundles. 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). 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 commands according to the HouseModeling interface. Allows bundles to be notified when managed devices change their states. Provides information about the current state of devices. 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. 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 DevicesListUpgrade service, is initially provided by the Configurator 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 protocol. Commands are syntactically validated, by checking the relation between DogMessage type declaration and DogMessage 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 messages to the Message Dispatcher for the final delivery. Otherwise 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 candidate for future implementations of rule-based, runtime automation scenarios or safety policies, including command prioritization, required for implementing security and manual override mechanisms. Status The Status bundle caches the states of all devices controlled 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 Network 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, bypassing 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 interfaces 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 ApiConnector 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, independently 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 interaction 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.

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

1661

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 nonOSGi applications to exploit DOG services. It implements a lightweight 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 environment, and exposed through the House Model bundle, is queried to configure network drivers and to deal with unknown device types.

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 provides 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 network 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. 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 devices. The first interaction step involves querying a DogOnt instantiation, using constructs defined in the W3C standard query language for RDF (SPARQL [13]), for extracting device descriptions, filtered by technology (e.g., searching specific 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 translating 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-

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 proceeds as in Figure 6: when a DogMessage containing a command 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

1662

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

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.

bundle that routes them towards the correct NetworkDrivers. Each NetworkDriver translates the received commands into network-specific protocol messages, resulting in a simultaneous, deactivation of lamps managed by domotic plants connected 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.

Interoperation can be of two main kinds: network-tonetwork 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 whenever 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 application-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 (allOFF). 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 ontology for all devices of class Lamp. The transitive closure of DogOnt, performed by the HouseModel during start-up, ensures 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.

Fig. 9 Application-to-network interoperation.

After retrieving all involved devices (in a networkindependent 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

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 bundles, 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 corresponds 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.

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

1663

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 vocabulary for high-level XML messages. DOG, instead, models the home environment and the domotic devices with a proper ontology (DogOnt) and leverages information encoded in such model to support device generalization (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 interact 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.
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 Furniture Architectural Count 28 30

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 architecture 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 interoperability. 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 automatically perform generalization of device, functionality abstraction/matching and reasoning. UMB does not define a standard access point for the network it manages, and requires applications to implement a proper connection logic (UMB Adaptor) to interact with home devices and networks. The home server, in UMB, is seen more as a router, which correctly delivers messages between different Adaptors (i.e., networks or devices), 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 devices allowing to coordinate several appliances without a specific notion of used networks or protocols. Conversion of protocols 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 interoperability. This work is pretty similar to DomoNet as each appliance or network requires a dedicated Protocol Conversion Manager and a dedicated Virtual Service Gateway interface 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

VI. RELATED WORKS Many research works are evolving towards the concept of Intelligent 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 connection capabilities is a major driving force, towards systems based on simple, embedded PCs. In this context, Miori et al. [18] defined a framework called DomoNet for domotic interoperability based on Web Services, XML and Internet protocols. DomoNet defines so-called TechManagers, one per each integrated network, that expose the domotic network capabilities as Web Services 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 functionalities in virtual devices (proxies) available on each TechManager, requiring a considerable synchronization work, while DOG only allocates the necessary resources implementing a

1664

IEEE Transactions on Consumer Electronics, Vol. 54, No. 4, NOVEMBER 2008 [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] D. Bonino and F. Corno, DogOnt - Ontology Modeling for Intelligent Domotic Environments, in Proceedings of the 7th International Semantic Web Conference. Springer, 2008. T. Gruber, Toward principles for the design of ontologies used for knowledge sharing, International Journal Human-Computer Studies, vol. 43(5-6), pp. 907928, 1995. D. L. McGuinness and F. van Harmelen, Owl web ontology language, W3C Recommendation, http://www.w3.org/TR/owl-features/, February 2004. D. Winer, XML-RPC specification, UserLand Software, Tech. Rep., 2003. Osgi service platform release 4, http://www.osgi.org/, The OSGi alliance, Tech. Rep., 2007. D. Rye, The X10 PowerHouse powerline interface, http://www.x10.com, X10 PowerHouse, Tech. Rep., 2001. E. Prudhommeaux and A. Seaborne, SPARQL Query Language for RDF (W3C recommendation), http://www.w3.org/TR/rdf-sparqlquery/, January 2008. The Eclipse Equinox project, http://www.eclipse.org/equinox/. The HP Jena API, http://jena.sourceforge.net/. The Apache XML-RPC API, http://ws.apache.org/xmlrpc/. D. Bonino, E. Castellina, and F. Corno, The DOG Domotic OSGi Gateway, http://domoticdog.sourceforge.net, June 2008. V. Miori, L. Tarrini, M. Manca, and G. Tolomei, An Open Standard Solution for Domotic Interoperability, IEEE Transactions on Consumer Electronics, vol. 52, pp. 97103, 2006. K.-D. Moon, Y.-H. Lee, C.-E. Lee, and Y.-S. Son, Design of a Universal Middleware Bridge for Device Interoperability in Heterogeneous Home Network Middleware, IEEE Transactions on Consumer Electronics, vol. 51, pp. 314318, 2005. E. Tokunaga, H. Ishikawa, M. Kurahashi, Y. Morimoto, and T. Nakajima, A Framework for Connecting Home Computing Middleware, in International Conference on Distributed Computing Systems Workshops (ICDCSW02), 2002

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 supporting 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 related 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 comprehensive, home-wide Intelligent Domotic Environments. Several issues have been addressed related to network interoperation, 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 interoperation, 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. 521524. S. Davidoff, M. K. Lee, J. Zimmerman, and A. Dey, Principle of Smart Home Control, in Proceedings of the Conference on Ubiquitous Computing. Springer, 2006, pp. 1934. S. S. Intille, Designing a Home of the Future, IEEE Pervasive Computing, vol. 1, no. 2, pp. 7682, 2002. S.-L. Chung and W.-Y. Chen, MyHome: A Residential Server for Smart Homes, Knowledge-Based Intelligent Information and Engineering Systems, vol. 4693/2007, pp. 664670, 2007. 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. 11611166, Nov 2000. Home gateway technical requirements: Residential profile, Home Gateway Initiative, Tech. Rep., 2008.

[20]

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 semantic annotation, indexing and retrieval of web resources, 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 international 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 tracking (analysis and studies on gaze tracking algorithms), Computer Assistive Technologies (development of special software applications for disabled people) and Domotic 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 involved in several research projects. His current research interests include the application of semantic technologies to web systems, the design of Intelligent Domotic Environments, and interfaces for alternative access to computer systems. He published more than 150 papers at international conferences and 15 on international journals.

[2] [3] [4] [5] [6]