The potential of current technologies in smart automation has been largely unexploited. Pervasive computing7 vision is still far from being achieved, especially with regard to Domotics4 and home applications. In fact, even though many implementations have started to appear in several contexts, few applications have been made available for the home environment and the general public. This is mainly due to the segmentation of standards and proprietary solutions, which are currently confusing the market with a sparse offer of uninteroperable devices and systems.
Although modern houses are equipped with smart technological appliances, still very few of these appliances can be seamlessly connected to each other.
Moreover, inter-working capabilities are required beyond house boundaries, towards external services and towards other houses as nodes of a global network.
Therefore, the main goal of this research is to find solutions to the problem of interoperability that will be in line with open and widely recognized standards.
The result is a computing framework based on open communication standards, capable of abstracting the peculiarities of underlying heterogeneous technologies, and letting them co-exist and interwork, without eliminating their differences. Interoperability can thus be made potentially feasible between any domotic technology, both currently existing, and still to be defined.
Currently, domotic technology vendors concentrate on building closed relationships with their customers, and leveraging their economic investments by establishing barriers against new manufacturers entering the market.
Examples of current domotic protocols are X10, Konnex, LonWorks, UPnP, HAVi, and Jini supporting various communication standards (Ethernet, FireWire, Bluetooth, ZigBee, IrDA and proprietary buses). We believe that no domotic technology currently has the potential to actually play a leading role. Within this wide and heterogeneous framework, the market logic is to tie consumers to a particular domotic protocol, which then forces them to only purchase conforming devices in order to keep a consistent level of interoperability.
In recent years several interesting and innovative solutions have emerged, with a reasonable level of scalability and dependability, providing interoperability among heterogeneous home systems.
Twente University10 has proposed a solution that aims at supporting heterogeneous technologies (including legacy ones) with a “cluster cultures” approach. The architecture outlines a “touch and play” system which, at device registration time, enables a zero-configuration environment for the exchange of credentials among its gateways and to register device services in a hierarchical structure. The architecture provides a high level of security by using cryptographic algorithms.
Waseda University10 have proposed a framework designed to easily enable the integration of legacy middleware and legacy services and clients, with a predefined path for the inclusion of new, future, middleware. This is accomplished mainly through the use of a Virtual Service Gateway. This connects one piece of middleware to another by exploiting a Protocol Conversion Manager, whose task is to convert the different middleware protocols into the specific internal protocol used by the Virtual Service Gateway. Information about the location and functions of services is provided by a Virtual Service Repository.
Another interesting project is the “Domotic House Gateway.”9 It implements an event-based mechanism which is used to exchange messages between the single device and the system. These events are internally converted into logical events so as to clearly separate the actual physical issues from the semantics that goes beyond the devices and their role within the house. One level of the architecture implements a rule-based core that can be dynamically adapted either by the system itself or manually through external interfaces. Each device needs a device driver, which is responsible for translating its low level or hardware states and activities into events that can be managed by the system.
Another promising approach, in line with our research, is proposed by the Open Building Information Exchange groupa who are working to create standard XML and Web Services guidelines to facilitate information exchange among mechanical and electrical systems in building automation.
One such important European project in this context is Amigo.b This project was aimed at Ambient Intelligence features for the networked home environment and the usability of the system was among its main goals and included three major guidelines: user-friendly interfaces,6 interoperability, and automatic discovery of devices and services.
All these projects resolved the interoperability problem with several approaches, all of which are different from what we consider, in our vision, as the optimal solutions.
Lastly, we enlist a prototype5 previously created by our research laboratory. This solution had the limitation of abstracting each device typology with a Web service implementing their specific functionalities. The implementation of a new ad hoc Web service was needed whenever a new category of device needed to be included in the network. In addition, this prototype solved the problem of cooperation by virtualizing devices belonging to each domotic system onto the others. This solution, however, had a drawback: the same device appeared virtually replicated on every single domotic system, thus creating data replications and possible consistency problems.
domoNet Architecture and Interaction Model
In order to achieve significant results in the interoperability field, a comprehensive and abstract approach is required, rather than addressing the technology mismatch directly through the use of ad hoc mappings of different specific standards. By focusing on functionalities and semantics, we can first identify a suitable way to describe, and a coherent process to control the devices, using well-proven and standard technologies. The most suitable choice is XML for description, and Web Services for control. Both these technologies are emerging as Internet open standards for organizing and using distributed application capabilities, due to their inner cross-platform nature.
Identifying the functional elements of devices is the preliminary step towards formalizing a semantic structure, through a suitable XML language called domoML. A first abstraction level is thus reached, in which incompatible device capabilities are de-structured towards their most basic control semantics in the overall context of domotics.
Once we have gone through this process of defining and describing single functions (profile definition), the next step is to associate these control information units with corresponding active control elements, which we identify as services. Since these services all map against the same domoML language, they can be considered as being equivalent as far as interoperability is concerned. They define and constitute a new control layer, which can be seen as a meta-infrastructure of high-level services. In our vision, this is a Service Oriented Architecture (SOA)8 based on Web Services technology and is called domoNet.4 This logical infrastructure binds several single domotic systems, providing them with common information and control exchange mechanisms.
Since the intention is to provide a universal approach rather than an ad hoc interoperability tool, domoNet was created with a modular structure to map the abstraction layer against the actual protocols and peculiarities. Therefore, domoNet has been equipped with appropriate internal plug-in modules called techManagers. This modular structure is there to ensure more protocols can be included in the future, within the interoperability framework. Figure 1 shows that domoNet can be seen as a central network infrastructure and each domotic system represents a sub-network connected through a suitable techManager gateway.
It should be noted that these technology choices are enabling factors for remote control, along with interoperability. The Web service at the core of our infrastructure, called domoNetWS, is, in fact, a real Internet node designed to share environments and services in a distributed fashion with any other domoNetWS regardless of its location.
Our objectives were:
- to create a modular engine capable of managing entire domotic systems without introducing specific drivers for specific device typologies,
- to automate the configuration process by providing an environment to re-fine it and set the behaviours of devices in the home environment; and
- to make the system scalable both by introducing different techManagers for each technology, and by allowing the distribution to remote locations of several domoNetWSs on the Internet.
The Domotic XML Language
The domoML language is needed to provide a first semantic abstraction of heterogeneous systems. It has been structured as an XML dialect, through the use of XML schemas and plays the role of a common language for domotic interoperability. DomoML defines the specifications for future standardization processes regarding domotic devices, their communication models and their functionalities. Through domoML, data type models are also standardized, providing a suitable intermediate representation, from and to which to convert outbound and inbound values, in order to enable data marshalling among heterogeneous technologies. DomoML is also aimed at formalizing abstract communication messages expected within domoNet and between domoNet abstract devices.
As Figure 2 suggests, domoML is the top layer in the domoNet protocol stack and, as such, its role is to define standard communication procedures for high level applications.
In essence, domoML consists of two main elements:
1. domoDevice standardizes parameters in order to describe the characteristics of the devices, their position within the environment, available functions (services), the process through which interactions with other domoDevices must take place, and supported data types. Each domoDevice contains all the possible services and functionality that are available in all the domotic technologies that are currently supported.
Table 1 shows the domoDevice structure of a bathroom light. In this example, switching the light on is linked to an UPnP multimedia service that plays music.
At the moment the tags available are:
- device (specifies general characteristics of the abstracted device).
- service (describes all the features that can be used by the system).
- input (describes how to interact with a service and the value range allowed)
- linkedService (creates a link between two domoDevices). In order to reference a domoDevice, id and url attributes are used inside the domonet architeture.
- linkedInput (shares environments and values).
The main attributes of the device are:
- url and id needed to correctly route domoMessages to domoDevices and techManagers in a structured manner
- category and sub-category, the latter provides a more specific description of particular device services, still maintaining uniformity for base functionalities (belonging to category).
2. domoMessage describes an event, a command or a response. It standardizes the messages that will be exchanged among domoDevices and throughout the framework. A message can belong to different types: command when it requests execution of a service belonging to a domoDevice; success, when the service execution is successfully completed; failure, when the request for the service has not been correctly executed; event, when there is a domoDevice status change.
Table 2 shows an example of a domoMessage, where an event type domoMessage notifies a state change to ‘active’ with regard to the light service.
The Domotic System Gateways (the techManager)
The techManager implementation is structured in two parts. One acts directly towards domoNet, implementing the Web Service client that interacts with the system (common for all technologies and therefore not requiring future re-implementation or specialization). The second physically interfaces specified domotic protocol devices. It does this by providing the physical and logical access methods required for correct interaction with physical devices (direct translation occurs at this level). Generally techManager tasks include:
- creating a list of domoDevices related to its subnetwork, and submitting them to domoNetWS;
- ensuring correspondence between actual devices and domoDevices;
- translating domoMessages into actual domotic protocol messages (techMessage) expected in its managed subsystem; and
- notifying events that occur within its managed domotic subsystem by creating appropriate domoMessages.
During the framework start-up phase, each techManager connected to domoNet builds an abstraction for each domotic device belonging to its own subnetwork. Thus details are provided about the control of features and services, omitting accessory and descriptive information where not considered mandatory to reach the framework’s target interoperability level. Therefore, every single feature of each real device is made available and usable through the framework itself. The implementation of device and service discovery is different for each techManager since it is strictly dependant on the underlying technology. To each device detected by the techManagers, domoNet assigns a unique id and the pertaining Web service url, so that it can be addressed from inside and outside the framework. To keep coherence among distinct address spaces for distinct subnetworks, a global mapping table is maintained, which, for each unique domoNet identifier, associates the actual device address. This address is valid and unique within the specific subnetwork involved.
The domoNet Engine
At the core of the framework there is domoNetWS, a Web Services-based engine whose task is to create a real cooperation between nodes. It constructs a unique view of the system including all the devices belonging to all the different technologies available throughout the system.
Figure 3 shows a state modification for a generic device xDevice (where × represents a generic technology): an event is generated, and then subsequently captured, through a techMessage, by the xManager. The xManager translates the techMessage into a domoMessage, converting all possible data into the intermediate format supported by domoML. The xManager is now able to route all the information related to this event to the domoNetWS through the searchExecLinkedSer method.
By analyzing the xDevice description, domoNetWS can identify the service associated with the captured event, and all the information required in order to create the related domoMessage and route it to the right techManager. Its execution is then requested, and data is converted from the intermediate domoNet format into the target one, belonging to the underlying subnetwork. The yManager then interacts with yDevice with the final techMessage.
The Prototype
A prototype has been developed and tested at ISTI-CNR (Italian National Research Council) Domotic Laboratory in Pisa, which conforms completely to the architecture described above.
It is open source software released under GPL licence, and freely available.c It was developed using Java and only open source libraries and tools.
It was successfully deployed during an Ambient Assisted Living project, at a stable demo centre, mounted on mobile panels. It has also been shown at important technology exhibitions. Some very important features have been introduced, which are usually not feasible, by exploiting the integration of domotic technologies.
The implementation features five techManagers related to five home domotic systems (UPnP, Konnex, MyHome, X10 and BacNet). UPnP is used to control multimedia devices in order to manage audio and video content; Konnex, MyHome, X10 and BacNet are used to manage home appliances and plants.
The prototype implements also an experimental user friendly interface to configure the interoperability relations among devices and an auto-learning system that tries to predict user actions analyzing user habits and creating domotic command rules.
Conclusion
We believe this article proves that this system has the potential to be used in cooperation with all existing domotic systems, and manage them without the use of specialized software for each type of device.
The next important step is to enhance the system’s robustness, in fact the current system has not yet been tested with a large number of devices. A more solid approach regarding information storage (device descriptions, mapping tables, and so on), currently realized by means of simple file dumping, could make use of a relational db. After this crucial migration, it will be possible to focus on the security of the framework using two main techniques: classical authentication and access control to database records, and communication protection procedures such as message coding, especially between remote domoNet instances.
Another crucial enhancement will involve setting up a really user-friendly interface system, supporting dynamic interface adaptability and reconfiguration. This will be done through the development of a universal remote control, which can also be interacted with by elderly and disabled people. By interacting with domoNet, this remote control, will be able to operate all devices available in the home environment and belonging to any domotic protocol, and will be made so that it will automatically adapt to several different platforms.
Future framework versions will most likely move towards a more extensive semantic approach in the definition of devices and services, allowing for greater context awareness and user friendliness. These Ambient Intelligence features will be achieved by investigating the use of ontology, functional languages such as CAML, and Semantic Web. Research in this field is already being carried out within the NICHE project,1 which aims to define a Semantic Web model in order to increase the usability of the domoML abstraction layer.
Some improvements on the architecture will be performed in order to fully embrace the digital ecosystem philosophy11 that it’s now included only in techManager modules. Each techManager is independent from the rest of the middleware and it follows its “life-cycle” according to its own standard and characteristics, without be subordinate to any hierarchical order (P2P and horizontal architecture).
Finally, an important work in its starting phase is to port the software to an embedded platform in order to evaluate performance and power consumption on a large scale. This then eliminates the need to be tied to a dedicated personal computer in order to have an interoperable, domotic house.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment