UniDA Framework Implementation

In the previous sections we have presented UniDA as three conceptual components, a common conceptual model of an instrumentation network, a uniform device access paradigm that models the interactions between the members of the instrumentation network and a distributed operation protocol for the remote interaction between some of the members of the network. In the present section we are going to show an actual implementation of those components.

Figure 3 shows an architecture diagram of the UniDA framework implementation. As can be seen it is decomposed into two main components, the UniDA Library and the UniDA gateway. The UniDA Library is an implementation of the common conceptual model, the uniform device access paradigm and the distributed operation protocol as a J2SE library. The library (and its dependencies) is the only software component that a client application needs in order to command and control an instrumentation network.

The UniDA Gateway is the realization of the Device Gateway concept defined in the common conceptual model. There can be multiple implementations of the UniDA Gateway, from generic implementations that will be run in common hardware, such as computers or smartphones, to embedded implementations for specifically designed gateways. It is in the gateways where the particular control logic of each device resides, and by using some components of the UniDA library (or implementing them for embedded gateways), like the distributed operation protocol, they provide access to devices to clients of the UniDA Library. That is, UniDA Gateways translate the common concepts managed by UniDA to the particular ones used by each device technology.

###UniDA Library The functionality of the library is presented to external clients through a reduced set of concepts (classes of objects, as it is implemented using JAVA, an object-oriented language) directly implemented from the proposed conceptual model shown in section 4, and three façades that export the operations to manipulate those concepts in a uniform way. There exists one façade for the operational functionality of the instrumentation network, like query the state of a device or issue a command to a device, and two façades for management operations, one for device management operations and another for device gateway management operations.

Figure 3. Architecture diagram of an UniDA system.

As can be seen in Figure 3, the library is implemented as five modules that are encapsulated behind the three façades: an implementation of the common conceptual model; a management subsystem, in charge of providing access to information about the devices available in an instrumentation network; an operational subsystem, in charge of providing control capabilities over those devices, a communications subsystem, that implements the distributed operation protocol; and a device ontology module that manages the access to the DogOnt ontology. These modules will be described next, except for the common conceptual model implementation, which is only an object-oriented implementation of the model proposed in section 4.1.

####Management Subsystem The management subsystem, implements two different sets of operations related to two different concepts. On one hand, it provides operations to create new devices or gateways, remove existing ones, edit their information and relationships, etc. On the other, it provides query functionalities to allow applications to access the information about the devices and device gateways available in an instrumentation network. The management subsystem is designed to require minimal, or even no interaction with the devices. This is an important characteristic because one of our goals was to support the off-line management of the instrumentation network, so that, an installer could set up a network at his office and then deploy it in the physical installation with minimal intervention.

Therefore, the management subsystem does not require communications with the devices, any change in the installation is stored in a database. Once the installation is deployed and on-line, the operational subsystem interacts with the network, and uses the management subsystem to update the state of the devices and gateways to reflect the current state of the network.

The installation database contains the complete definition of a particular installation. This definition is a series of instances of the concepts defined in the common conceptual model, more specifically devices, device gateways and the relationships between them, the ontology and the physical environment. As we wanted to make the device access library small and easy to use and deploy, so that even small standalone control applications could use it. We decided to reduce the deployment requirements by not using a classical database management system (RDMS) with a separate server; instead, we used an embedded RDMS, HSQLDB [30].

As shown in Figure 3, the management subsystem also makes use of the DOG ontology. As mentioned before in section 4, the ontology is used as a taxonomy of the different types of devices and device gateways that can exist, as well as a source of semantic metadata about those concepts, like their relationships, their properties, etc. A complete description of how the ontology is used will be provided later in this paper.

####Operational Subsystem In a similar way to the management subsystem, the operational subsystem implements two different sets of functionalities. On one hand, it implements the operations required to control the devices and the instrumentation network. On the other, it supports the maintenance operations by implementing the functionality required to continuously monitor, in real time, the operational state of the network and update the management database through the management subsystem in order to reflect the current state of the network.

The command functionalities are all implemented as asynchronous operations. We decided to take advantage of the fact that the protocol of the instrumentation network (section 5.1.3) is designed as a connectionless protocol, and the control and command capabilities of the library were implemented in an asynchronous way, so that the client applications can operate the network without actively waiting for responses. This allows for an easier development of more responsive and efficient applications.

The command functionalities also contain the logic required to control groups of devices, so it is able to execute the same operations over multiple devices. Even if a device of the group is not available, it stores the operation in a queue and sends it to the devices as soon as is available.

The monitoring of the device network is achieved by continuously receiving and processing gateway announce messages. They must be sent periodically by the gateways to maintain the management subsystem updated with the last known information about the network, like new devices that were connected to the network, devices or gateways that were disconnected, or failures detected.

####Communications Subsystem The communications subsystem implements the distributed operation protocol independently from the other subsystems, and it is divided into two components. On one hand, a message handling system, made up of a set of messages, logic to code and decode them in a binary format, and logic to manage their processing. And on the other, a communications channel implementing the particular logic to send and receive messages from a specific network technology. The internal division of the communications subsystem into two components allows reusing the message system with different network technologies.

Following the guidelines for the implementation of the protocol described in section 4.3, the messages are encoded as byte data in little-endian format. The selection of little-endian was made because many of the most commonly used low power microcontrollers available in the market, such as the Microchip PIC or the Atmel Atmega, internally represent data in little-endian, thus, the use of big-endian format, more of a network standard, would require a translation phase for every message. Bearing in mind the simplicity of the typical interactions in an instrumentation network, in gateways that use embedded hardware the translation process would be even more costly than the interaction itself.

In the current implementation of the UniDA Library, the message handling system uses one thread to continuously receive messages through the communications channel, these messages are decoded and stored in a message processing queue. This queue is processed by message handler objects containing the logic to process a message of a given type. They are the connection between the communications module and their external clients, the operational subsystem and the gateway controller, see Figure 3.

Bearing in mind the capabilities of low power microcontrollers and the sessionless requirement of the protocol, the default implementation of the communications channel uses the UDP transport protocol, and broadcast messages for discovery and notification messages.

As mentioned in section 4.3, every message, except those used for gateway announce and notifications, has an associated response. This response is used by the protocol implementation to guarantee the reception of the message by its receiver, or at least, in the worst case, detect a communications error. A simple exponential backoff algorithm is used to resend the message N times if its response is not received during a certain period. If the maximum number of repetitions is exceeded, the message is cancelled and the component that requested the operation to the communications subsystem is notified of the error, so that it can take the appropriate actions. The number of resends and the expiration time of the first response can be specified independently for every operation requested to the communications subsystem.

The current UDP implementation sends messages as a single UDP datagram. It is part of the future work to modify the protocol to support multiple datagram messages, so that large messages can be used if required.

####Device Ontology One usual problem of ontologies is that ontology management requires lots of memory and processing power to achieve low response times. As it was of paramount importance to keep the device access library light and responsive, it was decided to use ontologies in a limited way, that is, only as a repository of metadata, instead of using them directly for storing instances of the concepts and reasoning with them. Therefore, we use ontologies as a taxonomy of the different types of devices and gateways that could exist in an installation, and as a repository of semantic metadata about those devices, their properties and their relationships.

A little module was designed and developed to manage the access to the ontology. This subsystem exports the ontology through a series of query methods that return metadata about the different concepts managed by the system. The biggest benefit of totally encapsulating the ontology behind this module is that the ontology can be updated or changed without affecting the other components of the system.

The ontology subsystem is implemented using the OWL-API [31] JAVA library for reading the DogOnt ontology, which is described in the OWL language, and the Pellet [32] library as the inference engine for the management of complex relationships between concepts. To reduce the hardware requirements and response times, we are using the basic query capabilities of the OWL-API whenever possible, and only relying on the inference capabilities of Pellet for traversing complex inheritance hierarchies.

###UniDA Gateways In a UniDA based system the gateways are the elements in charge of translating the concepts from the common conceptual model and the uniform device access parading to the particular concepts and interfaces required by each specific device. Their job is to control hardware devices and to interconnect them building an instrumentation network that can be accessed and managed by the clients of the UniDA Library. Therefore, gateways are highly coupled to particular devices or technologies, and usually include specific software and hardware.

To this end, a UniDA gateway should include: The particular control logic for each device connected to it, that is, the device drivers. An implementation of the distributed operation protocol so that it can interact with other elements of the network.

Depending on the requirements of the hardware devices, there can be many UniDA gateways deployed on very different hardware. For example, there can be gateways deployed on generic platforms, such as PCs, for devices that require complex control software, like domotic technologies; gateways deployed on smartphones to provide access to their sensing devices; or gateways deployed on custom embedded hardware to control simple devices or build new hardware devices directly compatible with UniDA.

We have created a generic UniDA gateway software component, shown in Figure 4, which can be used to build new gateways. It is implemented in Java using the J2SE API so that it can run in any device with a J2SE virtual machine. It is a reference implementation of a UniDA gateway, with all the logic required to interact with the UniDA network and manage the processing of requests and notifications.

The generic UniDA gateway component is designed to simplify building new gateways. For this, developers need to provide the particular logic to control a device, that is, the device drivers. This is achieved by implementing two interfaces, the UniDA Device and the UniDA Device Operations Façade for each type of device. Finally it is also necessary to implement a main class to add the devices to the UniDA Gateway and start its execution.

Figure 4 shows a simplified class diagram of the generic UniDA gateway. The interfaces of the UniDA device driver API are those that developers must implement to develop new device drivers. The generic gateway groups devices into hubs, the Proxy Device Hub. this way, Each hub is announced to the instrumentation network as a UniDA gateway, so one generic gateway can represent multiple UniDA gateways. This way, multiple UniDA gateways can be run in the same computer using fewer resources and sharing the same communications subsystem

Figure 4. Simplified class diagram of the generic gateway software.

Using the generic UniDA gateway component we have built gateways that allow the integration of some existing technologies into a UniDA instrumentation network. These gateways are an integral part of the UniDA framework, so they can be used by developers and installers to build their systems. By using these gateways, any application that uses the proposed framework will be directly compatible with the devices and technologies supported by these gateways, such as EIB/KNX domotic networks, uPnP media renderer devices, PJLink compatible projectors or Android smartphones.