IEEE Transactions on Consumer Electronics, Vol. 54, No.

4, NOVEMBER 2008

1656

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
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
Contributed Paper
Manuscript received August 28, 2008

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

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

1657

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.

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

1658

Priority
R1 Interoperability

R2 Automation

R3 Intelligence

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.

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

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)

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.

D. 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 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.

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.

1659

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).

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

1660

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.

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.

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.

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

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.

1661

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

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.

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.

?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-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.

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

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 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

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

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

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 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]

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

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.

[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]

[20]

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

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.