Keywords

1 Introduction

The key challenges in the adoption of advanced knowledge, information management and AI systems in smart manufacturing ecosystems [7, 9, 28] center on close collaboration between industries and research centres and sustainable manufacturing and products. These problems require the orchestration of the different actuators involved, dealing with heterogeneous protocols, different types of architectures and latency in edge devices. Such requirements pose great challenges to the stakeholders, due to the inherent complexity of the systems themselves, the possibility of boilerplate or legacy code needing to be understood and amended, and people lacking necessary skills that are nevertheless required to fully build a system with the desired characteristics. Therefore, solving the underlying data integration problem needs to be simplified. We adopt two open-source frameworks to address this heterogeneity and the corresponding integration problem. FiWARE [27] is an open-source platform supported by the European Union to develop and deploy IoT applications. The main idea behind FiWARE is to support collaboration and establish an open, free architecture that allow companies to develop their products in this context. On the other hand, EdgeX Foundry is a scalable and flexible software framework that facilitates the interoperability between devices and applications at the IoT Edge level. It acts as a middleware between the cloud and enterprise applications on one side, and the devices and “things” on the other side, providing a uniform way to define communication pipelines [8].

Fig. 1.
figure 1

Conventional approach for developing an edge analytics pipeline

Full size image
Fig. 2.
figure 2

MDD approach for developing the edge analytics pipeline using EdgeX/eKuiper in DIME

Full size image
Fig. 3.
figure 3

FiWARE Architecture using the Context Broker and the IoT Agent in DIME

Full size image

The traditional approach shown in Fig. 1 presents a significant complexity during the development cycle: to complete an entire application, one has to define and manage at the code level a frontend, backend, databases, setting up IoT frameworks and the IoT devices, and finally creating the workflows to interact with the Edge. In this approach, users deal with:

  1. 1.

    having to produce code by hand, that could be possibly be prone to errors,

  2. 2.

    a steep learning curve to fully understand the procedures involved, and

  3. 3.

    a large number of state-of-the-art technology skills, where is difficult to find specially trained people.

In contrast, building the same system application using models brings advantages over the conventional direct code approach. As shown in Fig. 2 and Fig. 3 this model-centred approach provides a more straightforward way to build the system: adequate models provide the low-code solutions. They enable a rapid and efficient development of applications involving IoT, EdgeX/FiWARE and eKuiper/IoT Agents using the DIME Domain-oriented Integrated Modelling Environment [1]. DIME empowers prototype-driven application development following the One Thing Approach [18] and enables an Extreme Model-Driven Design collaboration between domain experts and programmers [19]. Our low-code solution integrates both platforms by means of the DIME extension through an External Native DSL for eKuiper (see Fig. 2) and the FiWARE IoT Agent (see Fig. 3). This way, the rich facilities provided by the EdgeX/FiWARE framework become part of the DIME ecosystem, recreating in the context of the Digital Platform, a m2m communication in a low-code fashion way. Either way, users can build and deploy a cohesive platform without having to deal with complex cross-platform integrations. We take advantage of DIME’s flexible capability to extend its behaviour by adding a new palette of external native SIBs, implemented using Java code. Once the code is available, we define our convenient SIB-level API to interact with the Edge.

Considering the three challenges posed by a traditional code-based adoption, there is no need to deal with complex logic functionality or to understand boilerplate code (1), as in our architecture we rely on reusable Service Independent Building blocks (SIBs), executable and reusable modelling components previously defined and implemented by experts, and the application development amounts to composing the entire workflow process using such provided SIBs, and then generating the code automatically from that workflow and the SIBs that occur in it. This also lowers the learning curve (2), as the user of our system does not need to master the technical details nor implementation of the platform, and thus we also avoid the shortage of trained experts (3).

The rest of the paper is organized as follows: Sect. 2 covers related work in the application domain as well as some examples of our technology of choice. Section 3 explains in detail our API and DSL setup, the architecture developed to support the functionalities enabled and the corresponding integration work. Section 4 describes a use case that uses the developed DSL, and Sect. 5 reports our conclusions.

2 Related Work

2.1 Literature Review

Related work in the context of Model-Driven design with a focus in Smart Manufacturing evidences the importance of low-code approaches. Cadavid et al. [3] state the goal is “to be able to reuse processes definitions, by having readily available manufacturing actions that can be chained together to form compound processes”. The authors utilise Eclipse Papyrus [14], an open-source Model-Based Engineering tool that uses different representation schemas (such as UML 2.5.0, SysML 1.1 and 1.4, etc.) to create a high-level representation of the system. It also contains a framework called Moka [10], that enables executing models using an animation and simulation framework. It leverages the usage of models to fully setup a working workflow “representing a gain of time and effort as it provides a starting point of existing processes”. Trenzer et al. [30] provide a model-driven approach for developing data collection architectures. The authors consider these model-driven solutions as “capable of significantly lower manual implementation efforts” and leverage the usage of Eclipse Modeling Framework (EMF) [26]. EMF is a framework and code generation facility for building tools based on a structured data model. It provides support to produce a set of Java classes for the model, along with a set of adapter classes that enable viewing and command-based editing of the model, and a basic editorFootnote 1 to build the architecture itself, making the development more straightforward. The framework developed by the authors still is not being considered for productive environments, as there is no automatic link and synchronization between the graphical representation and the model instances, which represents a clear impediment when deploying an application. Vogel-Heuser et al. [31] propose a Model-Based System Engineering (MBSE) approach based on the systems modeling language SysML [12] that “enables an optimized deployment of a production system’s automation software to automation hardware resources”. The system might leverage itself from implementations such as SystemC [20] used for functional and timing verification and code synthesis (hardware and software). SystemC allows design and verification at the system level, allowing to test and verify any kind of architectural decision at a high level. Thramboulidis et al. [29] utilizes a Model Integrated Mechatronics (MIM) in the context of a cyber-physical system, where MIM belongs to the MDE paradigm for the development of Manufacturing Ecosystems. These ecosystems are defined as a composition of other mechatronics components, such as mechanics, electronics and software with the objective to do specific tasks. The authors define a meta-model with UML [13] notation and leverage from tools such as SysML and RDF [2]. The process goes through a “translation process” in order to get the specification of then tasks and act in consequence.

2.2 Own Previous Work

Previous state-of-the-art solutions developed with DIME, show the potential of this approach in simplifying the integration of heterogeneous components and application development. In the smart manufacturing context, in terms of integration of heterogeneous domains and technologies. Margaria et al. [16] show a remote control of a UR3 robot through a web-based application connecting to an IP address. Operations through domain-specific languages (DSLs) are added to DIME for the UR3, then used in the workflow of the Web application to control the robotic arm. Margaria et al. [17] show how to extract the digital twin of this composite system (robot and controller). Chaudhary et al. [6] show use cases for integration of the platform to support R and REST services. R is a programming language for statistical computing and graphical visualization of the outcomes. It provides statistical capabilities (linear, nonlinear, statistical tests, time series analysis, classification etc.), one of its strengths is the ease to produce well-designed publication-quality plots with mathematical symbols and formulas [22]. Representational State Transfer (REST), in the other hand, is an architectural style for service-oriented computing, very popular as a simple way of exposing service interfaces, especially in comparison with earlier protocols such as the complex and heavyweight SOAP/WS-* and similar RPC-inspired protocols [21]. Guevara et al. [11] includes a preliminar work in eKuiper as well, where sets the foundations of SIBs to leverage the MDD approach for Edge Analytics in the context of a Smart Manufacturing case.

The integration of FiWARE and eKuiper in DIME presented in this paper is a contribution to the construction of the Digital Thread Platform described in Margaria et al. [15], that aims to include heterogeneous technologies within a DIME-based low-code platform for application development in order to facilitate a seamless and rapid development of end-to-end applications that include functionalities stemming from different domains. Currently, the platform also includes a persistence layer with MongoDB and ElephantSQL, analytics in R and using cloud-based services (AWS), IoT capabilities using MQTT directly and through EdgeX, and the already mentioned robotics and REST capabilities.

3 Methodology

For both integrations, we introduce virtualization through the Service-Independent Building blocks (SIBs) mechanism of DIME. SIBs are high-level abstractions that hide their implementation details, and lift the technical vocabulary used in the system design and implementation to the domain specific language of the domain experts. This reduces the technical complexity of definition, design, and implementation of use cases, focussing the design on the specific step of the problem. Domain-specific collections of SIBs that integrate external tools or platforms are called here External Native DSLs (domain specific languages). This significantly speeds up the development of larger components and applications.

We sketch next the integration process (Sect. 3.1), then delve into EdgeX (Sect. 3.2) and FiWARE (Sect. 3.3) the analytics on the Edge (Sect. 3.4), and through eKuiper (Sect. 3.5).

3.1 The Integration Process

To achieve a proper integration of external resources and capabilities, application and DSL designers need to tackle together the following steps:

  1. 1.

    definition of the use case,

  2. 2.

    define the SIBs palette,

  3. 3.

    if the SIBs are missing, define functions and methods

  4. 4.

    define the application logic inside the SIB

  5. 5.

    test functionality,

  6. 6.

    use the SIB in the application domain

As in the traditional software development lifecycle, once the use case is defined (Step 1), we define in general terms the SIBs needed in our system (Step 2). A SIB declaration (Step 3) has a very user-friendly syntax, as shown in Fig. 4 (left) to upload device profile into system. A SIB declaration consists essentially of its signature, which is easy to read and produce: it has the same structure and elements as a function/method declaration. It starts with the SIB name, then it specifies the full path to the Java package where the class is located (the functionality itself) and the name of the method to call it. Then it lists the input parameters and the outgoing branches, i.e., the different continuation paths the function can take, they are mostly failure/success, but in general there can be many outgoing branches) and the (optional) outputs associated with each branch.

Fig. 4.
figure 4

Syntax and representation of a SIB within DIME

Full size image

Once the SIB is properly declared, in Step 4 we define the functions and methods that implement it in Java code. A Java SIB body takes advantages of all the services and functionality provided by the Eclipse IDE and the OpenJDK 11, which include performance improvements and functional programming approaches that are useful for improving syntactic sugar. Alternatively, a complex SIB can itself be implemented by a process (Step 4 too) and contain business logic and other SIBs.

In Step 5, once a SIB has both a declaration and an implementation, it is thoroughly tested in order to make sure it fulfils the expected behaviour. We recommend using unit testing and integration tests for the expected use and the most common kinds of incorrect use: trying to emulate a typical use case it will be expected to work with is effective to find potential issues and resolve them.

Finally, in Step 6 the functionality is ready to be used into the DIME development environment (loading the SIB, or the palette to which it belongs), and then used in applications by dragging and dropping its symbol from the list of SIBs available in our platform.

3.2 Architectural Components in EdgeX

The EdgeX Foundry framework facilitates this interaction with simpler data structures to get the information from the IoT devices. The architecture is basically composed by four main services: 1) Device Services 2) Core Services 3) Supporting Services. 4) Application Services. The first layer are the connectors which interacts with the IoT devices (sensors, actuators, sensors + actuators) to get data from/to them. The second layer, Core Services, contains the information about what devices are connected, the type of data going through and how to connect with them. The third layer, Supporting Services, contains eKuiper (the rule engine framework), and other frameworks for logging, scheduling and data cleaning. Finally, the fourth layer, the Application Services which extracts, process and send data from EdgeX to any endpoint of choiceFootnote 2

3.3 Architectural Components in FiWARE

FiWARE as previously mentioned, is another open source platform to deploy Internet of Things applications. FiWARE uses Docker containers and the architecture consists of two main components: 1) the Orion Context Broker and 2) the IoT Agent. The Contex Broker allows us to manage the entire lifecycle of context information, including updates, queries, registrations and subscriptions. The information consists of entities (i.e., objects we want to track) and their attributes (i.e., the properties of the objects). Orion implements an NGSIv2 server to manage information and availability, and it also provides creational capabilities to include elements and manage them through updates and queries. NGSI is a standard by the ETSI (European Telecommunications Standards Institute) to improve the communication framework with these types of devices. The IoT Agent acts as a bridge between the IoT devices and the Context Broker which maintains the state for each of them. The IoT Agent takes care of the requests from IoT devices and the petitions created from the user in an uniform way, also taking into consideration the security for each actuator/sensorFootnote 3.

3.4 Computing on the Edge and Data Analytics

Edge Analytics could be defined as “receive and interpret data from Edge computing”. Specifically, based on the information collected from the sensors, we establish a decision-making process and take actions based on those decisions. Edge Analytics can span several levels of complexity, from a simple SQL query to retrieve a few rows of data to complex heterogeneous machine learning systems to leverage a PdM system (predictive maintenance). There are currently two main approaches to accomplish Edge analytics:

  1. 1.

    run the analytics service in each device/sensor, or

  2. 2.

    deliver data from sensors to an analytics service in the cloud.

According to Shi et al.  [23], the first option has an advantage over the second one for three main reasons:

  1. 1.

    Computing tasks in the cloud are efficient, but it faces a bottleneck in the speed of data, i.e., the bandwidth to transport the data towards the network.

  2. 2.

    Everything is becoming part of the Edge IoT environment, leading to a massive production of data for which the conventional cloud computing approach is not efficient enough.

  3. 3.

    Security: as the edge devices are becoming data consumers, it makes sense to process data in edge devices (e.g., mobile phones) instead of uploading raw data to cloud services for subsequent processing.

3.5 Towards Model-Driven Edge Analytics with IoT Agents and eKuiper

Our providing a model-driven approach for edge analytics using two main tools, 1) EdgeX and 2) FiWARE, builds upon previous work already done with DIME and EdgeX [4, 5], where we retrieved data from IoT devices using REST API. Both EdgeX and FiWARE technologies provide many functionalities to handle data from the Edge. However, they still rely on complex code that an adopter needs to understand. Due to the complexity of the system itself, it also lacks the simplicity of an easy setup of the environment. In the specific context of the Digital Thread Platform realised with DIME, its XMDD paradigm gives us several benefits. The integration via SIBs, as per steps 2 to 6 described in Sect. 3.1, leads to the DSLs of Figs. 5 and 11, which show the SIBs created to automate the set-up and use workflow.

Fig. 5.
figure 5

SIB Library created to abstract and virtualize the logic building blocks from the EdgeX eKuiper Rule Engine

Full size image
Fig. 6.
figure 6

Code using the traditional approach (part 1)

Full size image
Fig. 7.
figure 7

Code using the traditional approach (part 2)

Full size image
Fig. 8.
figure 8

Code using the traditional approach (part 3)

Full size image

As we can see in Fig. 6, Fig. 7 and Fig. 8, the traditional code-level approach requires an average of 15 LOC per functionality. The code concerns the management of: 1) REST API requests and 2) Stream Java API, therefore requiring to be versed also in 3) functional programming, 4) exceptions, and 5) Java HttpRequest API. In a quick comparison with the DIME solution shown in Fig. 9, the workflow solution is more straightforward to setup and execute over the system. Despite the fact we still need to define the technical properties, this model level is more manageable and easier to understand than the traditional code-based approach.

Fig. 9.
figure 9

DIME workflow to support interaction with FiWARE

Full size image

4 Results and Discussion

4.1 EdgeX and eKuiper Integrations

The DIME version of the Edge Analytics application system, using EdgeX and eKuiper, has the simple setup workflow shown in Fig. 10 and a simpler way to connect the different functionalities and tasks, such as create a device or start a rule to perform analytics on the edge. Also, here we rely on the model-driven approach: defining the different properties of each SIB and connecting them along the control flow and data flow puts the focus on the problem instead of in the implementation details:

  1. 1.

    we create a given Device (with an internal reference to it),

  2. 2.

    start it,

  3. 3.

    create a stream to communicate,

  4. 4.

    create a rule,

  5. 5.

    show the available rules,

  6. 6.

    and finally the available streams.

In spite of its simplicity, this application is complete and serves as template for adoption and blueprint for further evolution. The definitions of the SIBs happen through their declaration: it is easy to understand and change by any person with no technical knowledge of software development, as the SIBs declarations and use are very intuitive to follow. Due to the formal nature of these models, they are also a vehicle to formal verification and in perspective automated synthesis techniques, e.g., along the lines of Steffen et al. [24].

There is still much more functionality to be addressed in both platforms. The DSLs integrations will happen organically over time, following the requirements of the additional use cases. We expect the additions to be carried out mostly by adopters of the Digital Thread platform, and not by ourselves. Our concern here is to show the simplicity and elegance of this set up in DIME, as a combination of SIB DSL and workflows. In parallel we are working on refining and testing this approach on productive environments.

Fig. 10.
figure 10

DIME workflow for the set-up and use of eKuiper rule-based analytics

Full size image

We rely for the rule definition language on SQL queries (this is the original eKuiper language of choice) and on the expertise of those who define them, as well as their understanding for structuring a JSON object. With the DIME approach one could consider a further abstraction layer that frees the user form the need to know SQL and JSON, through another DSL that lifts those functionalities to a more intuitive language/schema followed by transformation to SQL/JSON. This is similar to the approach taken in [25] for the DSL-driven integration of highly parameterized HTTP services and REST services as a hierarchy of DSLs at different levels of abstraction and virtualization.

We intend to tackle these still pending issues in the future, in order to make the model-driven programming environment more appealing to expert users who are not programmers. So far, we consider our contribution to constitute a considerable progress in delivering a more user-friendly solution to the academic community and to our industry partners.

4.2 FiWARE and IoT Agent Integrations

Another DIME solution for Edge Analytics was developed using FiWARE and IoT Agents, as shown in Fig. 11. The solution provides a different perspective, as we need to deal with two main components, the Context Broker and the IoT Agent which will act as middleware between the Edge and the requests from the user. The solution in terms of complexity ends up being more simple, as we don’t need to rely on another technology such as SQL. Instead of creating a stream and rules with SQL statements to retrieve data from the “things”, we simply use a query describing the values and conditions we want to filter and the IoT Agent will take care of the interpretation and gathering of the data.

Fig. 11.
figure 11

SIB Library created for interaction with FiWARE

Full size image

5 Conclusion

This paper establishes a major step towards an edge analytics low-code solution for Smart Manufacturing environments. This happens in the context of the Digital Thread Platform for smart advanced manufacturing currently under development, and through the adoption and extension of the DIME no-code/low-code platform. This technology choice privileges domain-specific abstractions that empower people with non-technical or non-programming expertise to create, deploy and run fully functional analytics solutions, virtualizing the underlying technologies, and thus making them opaque to the application designers that reuse the SIBs as pre-defined, pre-tested building blocks. We showed this on the basis of the eKuiper Rule Engine, that is part of the EdgeX ecosystem and IoT Agents as part of the FiWARE ecosystem, The effect is to democratise the development cycle and tackle down the high learning curve that is otherwise required in order to manage all these layers of knowledge. We believe this move can have a significant impact on the ability of manufacturing experts to use advanced analytics and, more in general, integration and interoperability platforms that they would not be able to program, manage and evolve with the current need of heterogeneous coding and architectural expertise.

The platform still needs some refinement (testing in productive environments and improvement of user experience), but we have a fairly complete palette of Service-Independent Building blocks (SIBs) to encapsulate the behaviour of each step and provide a high-level abstraction to the users. All they need to do is understand the SIBs and their parameters, and then orchestrate them in an appropriate way using our Digital Thread platform. Our case study targets the usage of the EdgeX Foundry framework and its advanced services like the eKuiper Rule Based engine for analytics, and FiWARE with the Context Broker and the IoT Agents, leverages a more straightforward way to use it, having to deal much less with configuration files and boiler-plate code.