UniDA Framework Overview

The UniDA framework is a solution for the integration and interoperation of devices in Human Interaction Environments. It is possible to use UniDA for two different, but interrelated, purposes. As an abstraction layer it allows the development of applications that handle hardware devices with independence of the technologies used in each device and their particular characteristics. As a complete HIE instrumentation solution it permits building distributed device networks with support for the transparent integration of existing installations and technologies.

Figure 1 compares the vision of the hardware available in a HIE from applications that interact directly with the devices, to the vision of applications that use the UniDA framework to interact with the same devices.

In the first case, the applications have a heterogeneous vision of the network of devices; they must include particular logic to interact with each specific technology and device available in the network, thus complicating the development process and making the addition of new devices more difficult, as they need to take care of all the complexities and particularities of each hardware technology deployed in the installation. In the second case, the applications have a homogeneous vision of the network, they are able to use the same concepts and operations to interact with every device, independently of their underlying technologies. This way they do not require knowledge of specific technologies, they can use devices from different technologies homogeneously, and new devices can be easily added to the network without requiring any modification of the application logic.

Figure 1. High-level architecture of the UniDA framework.

There are two points of view to describe the UniDA framework. On one hand there is a set of abstract conceptual components that made up a conceptual framework for the development of solutions in the HIE instrumentation field. On the other there are a set of elements that implement this conceptual framework, providing usable solutions for the design, implementation and deployment of HIE instrumentation systems.

The conceptual framework is made up of three components. A common conceptual model for the description of an instrumentation network and its devices, a uniform paradigm to model the interaction with devices, and a distributed operation protocol for the interaction between the different distributed elements of the system. The conceptual framework will be described in detail in section 4 of this paper.

These components are realized by two main elements, complemented with some configuration tools, which allow developers to use the model to interact with the available hardware devices within their software:

• A software library (developed in JAVA) implements the common conceptual model and provides a simplified façade with the operations supported by the uniform devices access paradigm. An ontology [15] is used to support the model and enrich its semantics, allowing some useful inference capabilities, like device class inheritance.

• Proxy-like components, called device gateways, one for each supported instrumentation technology, are in charge of translating the abstract concepts managed by UniDA to specific concepts of a particular technology. These gateways are usually deployed on remotely accessible embedded hardware devices that are physically connected to the end devices or to other instrumentation network technologies. The library and the device gateways will be further discussed in the section 5 of this paper. The UniDA conceptual framework, together with its implementation components builds a complete framework for interoperability of instrumentation hardware, alleviating the development costs of applications and installations for such heterogeneous environments as HIEs are.

###UniDA Conceptual Framework As presented in the overview of section 0, the UniDA framework is constructed around three conceptual components. These components make up a complete conceptual framework for the development of instrumentation systems for HIEs. Therefore, when using UniDA, these components represent the shared knowledge that developers, installers, and even manufactures, need in order to design and implement applications, systems and devices for HIEs. The next section is devoted to the description of these three conceptual components.

####Common Conceptual Model In UniDA, the homogeneous vision of a heterogeneous network of technologies is provided by a common conceptual model with a uniform device access paradigm.

This common conceptual model takes the similarities between the different existing technologies, and builds a new set of concepts that represent the essential characteristics of every instrumentation technology. This set of concepts abstract the peculiarities of a heterogeneous instrumentation network, providing developers with a homogeneous language to interact with devices, backed up by a set of software and hardware components that translate it into the particular concepts and technologies required to interact with specific devices. When using UniDA, developers, and more specifically, the applications that must make use of the instrumentation network, only need to talk in the common language provided by the common conceptual model. Therefore, this conceptual model must be, on one hand, powerful enough to support all the characteristics and functionalities required by the applications, and on the other, simple enough to be easy to use and not transfer the hardware complexities to the applications.

Trying to hide all the particularities and complexities of every instrumentation technology is not an easy goal. Even if a set of common concepts can be easily identified, the wide variety of devices and characteristics available can pollute the model with an increasing number of low-level concepts such as the types of devices that could exist, the different states a device can have, the different operations supported, etc., complicating the usage of the model with a lot of unneeded details and information. It would be really difficult and costly to try to identify in advance every type of state or functionality that can be available, and in fact, it must be taken into account that new types of devices may appear in the future. Consequently, it was decided to decouple the model into two models, a simple abstract model to represent the high-level concepts and relationships that support the operation and management of an instrumentation network, and another model to act as a taxonomy of the specific instances of those concepts and the relationships that could exist. This way, the framework can easily accommodate new types of devices, by only defining them in the taxonomy using the simple abstract model, and every operation supported by the framework can be performed on top those abstract concepts, isolated from the particularities of each device. One of the best ways to describe such a taxonomy is to use ontology description languages [25, 26], like RDF [22] or OWL [21]. These technologies have been widely used in recent years due to their adoption as key technologies for the semantic web. They provide powerful mechanisms to describe comprehensive semantics about concepts, content and relationships between them. This, along with ways to exploit those relationships by inference engines, provides powerful tools to reason with the concepts supported by the ontology. Another interesting point about ontologies is that they can be a highly isolated piece of software, so they can be easily shared between different software projects, with the added benefit that if two software projects use the same ontology to model some environment, they can interoperate very easily, and improvements to the ontology are reflected as direct improvements in every software component using it.

There are some device description ontologies available, unfortunately many of them are too related to computer devices [23, 27] and, in general, they are only conceptual ontologies, being difficult to find public accessible and usable implementations of them [24, 25]. Nevertheless, one prominent example of a device ontology is the DogOnt ontology [16], a device reasoning ontology developed by the e-Lite research group of the Politecnico di Torino, in Italy.

The DogOnt ontology is a very comprehensive taxonomy of devices typically used in home environments. It was developed as a part of the Domotic OSGi Gateway (DOG) project. DOG is a software home gateway that can be installed on an embedded PC and contains plugins to support current existing domotic technologies, providing a homogeneous API to access the available domotic devices. The DogOnt ontology serves as the model of a home automation environment for the DOG gateway and its client applications.

We decided to use the DogOnt ontology as our taxonomy of devices, not only because it is very complete, well supported and updated, but also because it matched very well the requirements of the conceptual model that we were designing. Our model is based in three main concepts, the devices, the functionality that those devices provide and some kind of proxies or gateways that connect the devices to the instrumentation network. The DogOnt ontology has very good support for these concepts, the device concept is directly supported and its functionalities are represented by two elements, control functionalities and notification functionalities. Furthermore, even the devices proxy concept is directly supported by a gateway concept represented in the taxonomy as 'DomoticNetworkComponent'.

Figure 2. Simplified vision of the proposed conceptual model for instrumentation networks.

Therefore, many of the concepts found in the model presented here are adapted, and even some of them directly extracted, from the DogOnt ontology. Thus, the conceptual model, as shown in Figure 2, is made up of eight main concepts:

• Devices. They are the devices that a user expects in his instrumentation network. They provide end users with services and functionalities. There exist two different kinds of devices; physical devices and groups of devices.
• Physical devices. They are a conceptual representation of the real hardware devices.
• Groups of devices. Multiple devices can be grouped together, and a group has the same entity as one device. Thus, a user or an application can send commands, queries, etc. to a group of devices in the same way (transparently) as to a single device.
• Device gateways. They are the connection point between the devices and the instrumentation network. They act as a control point for the devices, controlling them and transferring to them the commands that came from the instrumentation network, and vice versa.
• Device I/O. Physical devices are not directly connected to the gateways, they are connected through what we call a device I/O. A gateway has a set of device I/Os to which devices can be connected (this set can be static, or dynamic) and each device I/O has a list of states that restrict the type of devices that it can hold, so the I/Os of a gateway specify the number and type of devices it supports.
• Classes of devices. The class of a device represents its type. It supports inheritance thanks to the use of ontologies.
• Device states. They represent the type of states that a device has. A device can have multiple different states and they are specified by its device class.
• Device commands and device notifications. Together they represent the functionality of a device. Commands can be received by a device and it usually reacts by changing its state and acting over the environment changing it. Notifications represent changes in the state of a device. Devices send notifications to notify the clients of the instrumentation network about a change in its state.

As the objectives of this proposal are a bit different and broader than the DOG objectives, even if some concepts of the model presented here directly matches concepts from the DogOnt ontology, there exist important conceptual differences. One of the more prominent differences is the inclusion of the device I/O concept. Even though it is a concept that developers do not need to know, it is very important for the internal workings of UniDA and for the configuration of the system.There are gateways that are able to automatically detect when a device is connected to them and identify it. These gateways support a variable number of devices and make use of dynamic device I/Os. Thus, when a device is connected to them, they automatically create a new device I/O for the device and configure it. Furthermore, there are gateways, known as static gateways, that have a fixed number of physical interfaces to connect passive devices and, in order to be compatible with very simple or legacy devices, they are usually unable to detect the presence of the device, requiring manual configuration.

This last case is one of the main reasons for the introduction of the device I/O concept. It provides the system and installers a way to know what kind of devices can be connected to a particular gateway. Therefore, when a static gateway is incorporated to the system, the installer needs to manually configure the device I/Os the gateway is reporting. To do that, he specifies the class of devices that are connected to each device I/O. It must be stressed that not every device can be specified as connected to a particular device I/O, due to the fact that each one of them has an associated list of states that it supports. For example, a digital I/O will only have associated an on/off state to it, so that, only device classes that support that state may be associated to that device I/O. This configuration can be carried out with a web based configuration tool available for system installers.

Another important key aspect of the proposed model is that it was decided to make use of the DogOnt ontology only as a taxonomy of metadata for the concepts considered here. That is, an implementation of the proposed conceptual model doesn't have to populate an ontology with instances in order to represent the proposed concepts. It can represent the concepts with any technology, like object-oriented programing, and only use the ontology as a repository of metadata about the different concepts managed by the system.

####Uniform Device Access Paradigm The common conceptual model will not be complete without a description of how these concepts can be operated to interact with the instrumentation network, this description is the uniform device access paradigm. It provides a set of generic operations that can be used to manage and command the different elements that populate the system, allowing client applications and other elements to access the functionality supplied by the available devices.

The uniform device access paradigm is made up of a very small set of operations that, by relying on the common conceptual model, are sufficient to access any device functionality defined in the ontology. It has three main device access operations complemented by set of management ones:

• Query a state of a device. Every state that a device supports can be queried at any moment.
• Send a command for execution. It is possible to send commands to the devices. The commands supported by a device are defined in its metadata, that is, specified in the DogOnt ontology for every device class. Once a device receives a supported command, it must act in accordance to the semantics of the command.
• Subscribe to a device state. Devices must send notifications when one of their states changes. Therefore, clients can subscribe to those notifications in order to receive them.

These three operations are complemented with a set of management operations that will allow clients of the model (developers and applications) to find the devices and gateways available or defined in an particular instrumentation network, as well as access their descriptive information and metadata.

Therefore, the concepts provided by the common conceptual model and how to operate them (the uniform device access paradigm) is the only knowledge of the instrumentation network that application developers need to have, as any implementation of UniDA will provide them with an API to manage those concepts and issue operations, completely decoupling the application logic from the particular hardware technologies used to build the instrumentation network.

Finally, in the next section we describe the third component of the UniDA framework: the distributed operation protocol that enables the interaction between the different distributed physical elements of the system.

####Distributed Operation Protocol Due to the characteristics of HIEs and their intrinsic ubiquitous nature, devices need to be physically distributed throughout the environment in order to monitor and act over it. UniDA framework is designed to support the distributed operation of some of its elements, in particular, the elements that implement the device gateway concept can be installed distributed to build a network of devices. The objective of the distributed operation protocol is to allow the interaction between the clients of the framework (applications) and the devices deployed throughout the environment. The protocol must support all the operational, maintenance and management tasks required for the correct operation of the instrumentation network. These include support for:

• Control operations: query states, send commands, subscribe to state change notifications.
• Management operations: access to descriptive information about devices and gateways, discovery of devices/gateways available in the network, announcements of new devices/gateways available.
• Maintenance operations: Detection/notification of failures, announcements of device disconnections.

This kind of protocol can be modelled and implemented in multiple ways, being a very good option to use standard protocols. For example, the operational functions could be easily modelled by means of a RPC (Remote Procedure Call) protocol, like CORBA, XML-RPC or SOAP [28, 29, 12]. For the discovery of devices there are also good examples of standard protocols that could be applied, like SLP, SSDP or UPnP.

Unfortunately, these protocols are large and complex [12, 28], they use text based communications through the HTTP protocol, and they use the XML language to format the content of the messages [5, 12, 29]. As the logic required to control and command many of the devices available in a HIE will be fairly simple, using this type of protocols could cause that, in many cases, the power and processing time required for the communications logic be even larger than that required for the functionality logic. These protocols would hinder the construction of low cost, low power and small size hardware gateways for simple devices, like the one we are developing as part of the UniDA framework, (see section 5.3 for more details).

There are two ways of coping with this. On one hand, one could use two different communications protocols. Standard protocols to interact with high end device gateways and an ad-hoc protocol to interact with low end/low cost device gateways that command simple devices. On the other, one could use a single ad-hoc protocol for all the device gateways.

The first approach has the problem that the instrumentation network would be made up of two different types of device gateways that cannot interact directly between them. Thus it would be more difficult and inefficient to implement autonomous distributed behaviour capabilities directly in the gateways, which is one of our future goals.

As a consequence a new protocol has been designed for the interaction between the components of the instrumentation network. It is a simplified stateless message interchange protocol, based on the interchange of a series of predefined messages without requiring establishing sessions or connections. The reason to avoid a session based protocol is that a high percentage of the interactions present in an instrumentation network must be quick (kind of real time) and involve a very small amount of data transfer. Think for example of a request to power up a lamp or a notification of a state change in a door. A session based protocol would introduce a lot of overhead, and, in many cases, the overhead could even be larger than the communications act itself.

The communications protocol is defined as a set of messages that can be exchanged between the components of an instrumentation network. These messages are composed of three parts, a header, that contains metadata about the message, the content of the message and a checksum. Therefore, the protocol is defined in an abstract way and it can be implemented by using any connectionless transport protocol. In in order to keep the hardware requirements for the communication logic as low as possible, it is mandatory to implement it by using a binary encoding for the messages instead of using text-based ones like XML. The proposed protocol contains thirteen different types of messages to support all the functionality required by the instrumentation network, like gateway discovery and announce, command execution or notification messages. The interchange of messages is modelled as a request/response, except for the gateway announce message and the notification messages. The announce message must be broadcast to all the members of the instrumentation network, so everyone can know which gateways and devices are connected to the network. The notification messages must be multicast to all the members of the network subscribed to them.

The announce messages do not have to be answered or acknowledged, but they must be sent periodically by every gateway, in order to alleviate possible reception problems and because it is also used by other elements of the network to monitor the state of remote gateways and devices. Notification messages can be acknowledged, but it is not mandatory depending on the implementation.

Every other message has an associated response (or acknowledge) message, thus, it is mandatory for the implementation of the protocol to establish some kind of reception control mechanism in order to guarantee the reception of the messages, or at least, to be able to detect communications errors and act accordingly.