Service interoperability for embedded devices is a mandatory feature for dynamically changing Internetof-Things and Industry 4.0 software platforms. Service interoperability is achieved on a technical, syntactic, and semantic level. If service interoperability is achieved on all levels, plug-and-play functionality known from USB storage sticks or printer drivers becomes feasible. This reduces the manual efort for system integration for home automation systems and, in the case of the producing industry, allows for micro-batch size production, individualized automation solution, or job order production. However, interoperability at the semantic level is still a problem for the maturing class of IoT systems. In this work, we present a software engineering tool that allows storing, sharing, and reusing integration knowledge between software interfaces incrementally by looking at integration cases instead of domain models.
Architectural mismatch due to semantic diferences in software interfaces is a well-known
problem [
This work introduces a novel tool called Gabble that explicitly allows for an incomplete semantic domain model by looking at integration cases instead of domain models. "Gabble" is inspired by the fast-growing number of connected devices which talk so quickly that devices cannot understand each other. Therefore, it assists the system integrator at design time with logical reasoning capabilities by 1) proposing interface mappings based on previous integration cases and by 2) generating a software adapter in an automated way. We assume, that valid interface descriptions are present but the adapter design can be incomplete (i.e., missing functionalities).
To illustrate the tool functionality, we will take a look at an exemplary use case. In our setting, Alice and Bob work on an app that controls a Philips smart light. This device has a public API which is described in a syntactic specification standard (e.g., OpenAPI). Based on this specification, the client code to interface with the device was created using existing code generators. Subsequently, the necessary client logic to work with the generated library was developed.
The development team is now tasked to make the app work with a diferent device (i.e. by Yeelight). This light has a diferent, yet semantically identical API with a corresponding API specification. The interfaces of both devices are depicted in Fig. 1. This figure also shows how a diferent person integrated the Philips API with the LIFX (smart light brand) API (at time t=1), and yet another system integrator mapped the LIFX to the Yeelight API (at t=2). t=1 <<Interface>>
Philips + deviceId: Integer + power: String + color: String + brightness: Integer + controlLight (deviceId, power, brightness, color) : success, time, ...
set true if 'on' t=2 <<Interface>>
LIFX + id: Integer + active: Boolean + color: String + brightness: Integer + setSate (id, power, brightness, color) : status, time, ...
set 'on' if true, else 'off' divide by 100 multiply with 100
To make the Yeelight device work with the existing app in a practical way, Bob would have to generate new client code and adjust the application logic so that it can handle the new data model. This process has to be done manually every time such a change needs to be performed and does not allow the reuse of existing integration knowledge (see arrows that illustrate mappings in Fig. 1). The Gabble tool allows for such easy reuse of integration knowledge which is defined in a case-based manner. The main benefit of the tool support is the ability to handle simple scenarios as displayed and more complex ones with thousands of integration cases where manual knowledge extraction would get infeasible.
The underlying theoretical approach of Gabble is Knowledge-Driven Architecture Composition
(KDAC) – a novel paradigm of system integration that allows reusing atomic integration
knowledge preserved from previous integration cases [
Interface Database
retrieve source & target interface KDAC Framework
Mapping Knowledgebase use chain save mapping retrieve source & target
interface Transformation Preprocessor
compute mapping suggestions
Mapping View
invokes creates mappings retrieve mapping executes & oversees
Key
Gabble Component
External Component Adapter Generator builds (partial) adapter
IDE deploys
Application Test Component
invoke System Integrator
Target... API 1 Target API n updates adapter (if necessary)
The tool consists of several logical components (see Fig. 2). To start with, it allows users to add interfaces to the Interface Database which are then available later in the process. When adding an interface, the user has to provide either an AsyncAPI or OpenAPI specification and the interface name. Those interfaces are then available in the Mapping View where the user can create mappings between them. To do this, they select a source interface and one or many target interfaces. As soon as a selection is made, the Transformation Preprocessor is invoked. It uses the integration knowledge stored in the Mapping Knowledgebase to compute mapping suggestions. Those are directly added to the mapping view and color coded, cased on the their generation type.
The generation of suggestions is done in two ways. For transitive mapping suggestions, the preprocessor searches for paths from the source to the target interface(s). The resulting mapping chain is combined into a single mapping operation from source to target if a path is found. In our example, a mapping chain would be Philip→s− LIFX→− Yeelight. The other type of suggestion is based on knowledge graphs on single attributes instead of whole mappings. Those knowledge graphs capture the equality relationships (e.g., arrows in Fig. 1) between single interface attributes. Invoking the Transformation Preprocessor on every update allows generating new mapping suggestions whenever the user adds new integration knowledge in the integration case at hand.
It is important to note that the generated mapping suggestions might not be able to cover all the required attributes of the target interface(s), in which case the user can also add manual mappings. Those mappings can either be one-to-one (i.e., one provided attribute to one required attribute) or many-to-one (i.e., several provided attributes to one required attribute). Mappings are created by selecting the involved attributes in the Mapping View and can either be simple (i.e., only value replacement, no computations) or complex (i.e., mathematical functions to convert or combine attribute values). In our example, this is displayed by arrows without a label or with a label.
Once all required attributes are assigned, the user can test the mapping using the Test Component. To do this, the user provides the input data in the source interface’s data model and executing the mapping. This will transform the source to the target data model and perform the requests against the target API(s). The final result and all intermediate transformations are then shown to the user to ensure the correct functionality.
Finally, the user saves the complete mapping in the Mapping Knowledgebase, making it available for other users. In this way, case-based integration knowledge is preserved and made available for reuse. Once a mapping is completed, a software adapter can be automatically generated. This adapter encapsulates the mapping of the data models defined by the user. The result is a code library that has the same API as the client library for the source interface if it had been directly generated by an OpenAPI code generator. In our case, we added support for JavaScript adapters, but the Adapter Generator can also be extended to support other programming languages.
The Gabble tool’s underlying services are containerized using Docker and can be deployed
using one single command on any cloud infrastructure. Extensions are feasible as we rely on
current software frameworks such as React, TypeScript, OpenAPI, JSONata, and Mustache
templates. The benefits of the tool and the underlying method have already been demonstrated
in a home automation scenario by decreasing the engineering time of software adapters and
increasing the reliability of interface mappings [
Approaches from the industry include top-down designed standards such as OPC UA in
combination with ecl@ss. For instance, BaSys 4.0 [
The Gabble tool and the underlying approach do not try to (partially) formalize a domain and link interface elements to it, but look at integration knowledge based on concrete integration cases that can evolve over time.
In this work, we presented Gabble. Gabble is a tool accompanying the knowledge-driven architecture composition approach, which resolves architectural mismatch at the semantic level for highly interconnected and dynamic IoT software platforms. We believe that Gabble can lower the amount of manually written adapter code until one domain-specific standard emerges. In the future, we plan to apply Gabble to other integration scenarios demanding a higher degree of dependability, such as automated production lines.
This work has been developed in the project BIoTope (Research Grant Number 01lS18079C) and is funded by the German Ministry of Education and Research (BMBF).
Online Resources • Tool Demonstration Video: https://www.youtube.com/watch?v=6IuChI6Q4E4 • Source Code: https://github.com/mauriceackel/Gabble/tree/demo • Web Page: https://iot.informatik.uni-mannheim.de/