Efficient Model-Driven Prototyping for Edge Analytics

Abstract

Software development cycles in the context of Internet of Things (IoT) applications require the orchestration of different technological layers, and involve complex technical challenges. The engineering team needs to become experts in these technologies and time delays are inherent due to the cross-integration process because they face steep learning curves in several technologies, which leads to cost issues, and often to a resulting product that is prone to bugs. We propose a more straightforward approach to the construction of high-quality IoT applications by adopting model-driven technologies (DIME and Pyrus), that may be used jointly or in isolation. The presented use case connects various technologies: the application interacts through the EdgeX middleware platform with several sensors and data analytics pipelines. This web-based control application collects, processes and displays key information about the state of the edge data capture and computing that enables quick strategic decision-making. In the presented case study of a Stable Storage Facility (SSF), we use DIME to design the application for IoT connectivity and the edge aspects, MongoDB for storage and Pyrus to implement no-code data analytics in Python. We have integrated nine independent technologies in two distinct Low-code development environments with the production of seven processes and pipelines, and the definition of 25 SIBs in nine distinct DSLs. The presented case study is benchmarked with the platform to showcase the role of code generation and the reusability of components across applications. We demonstrate that the approach embraces a high level of reusability and facilitates domain engineers to create IoT applications in a low-code fashion.

1. Introduction

Modern IoT architectures enable efficient communication among interconnected infrastructures of sensors, devices, and systems, with the intention of offering innovative solutions for diverse applications [1]. In recent years, there has been a significant increase in the adoption of various IoT platforms and there is a growing demand for these platforms, devices and solutions from different vendors to seamlessly work together. This need not only leads to interoperability challenges in the ecosystem, but also makes the software development process more complex. The complexity across the different technological layers that compose a system requires deep and cross-functional technical expertise and integration knowledge for each of the involved heterogeneous system. In this context, IoT middleware platforms become an integral part of the IoT ecosystem that provides a common interface between the different sensors, computing devices, and actuators. These platforms address different kinds of requirements and often push project managers to perform an exhaustive analysis before choosing and implementing a specific type of architecture. From the point of view of application developers, the lack of compatibility between IoT platforms introduces an extra step towards tailoring their application to support platform-specific APIs. Considering the specifications of the application under development, the analysis may concentrate on various aspects such as interoperability, scalability, security and privacy, spontaneous interaction, or an unfixed structure.

In this context, we are developing a low-code Digital Thread Platform (DTP) [2] for Cyber-Physical Systems (CPS), which is based on the principles of Model Driven Development (MDD) and supports the capabilities of automatic code generation from the formal semantics underlying the models. It also supports one-click deployment of heterogeneous applications that require the interoperability across various systems, technologies and programming paradigms. The platform also enables the development of personalised solutions by seamlessly integrating applications and solutions into the wider landscape of enterprise applications, harnessing the potential of digital threads and digital twins [3,4]. We opted for model types that have well-defined semantics for formal analysis and verification. This decision is based on our belief in the advantages of early validation and verification at the model level, as well as its enabling the automated support for syntactic and semantic correctness.

We discuss as a case study the development of an IoT application including Edge Analytics by using two low-code platforms. We consider here the scenario of controlling and maintaining the environmental conditions of a storage facility as an example of a Stable Storage Facility (SSF), where the temperature, humidity and light intensity levels need to be maintained at the required levels in the facility. We leverage the usage of two low/no-code development environments, DIME [5] and Pyrus [6] to extend the horizon of services, platforms and the domain-specific functionalities that they support. Figure 1 shows the architecture of the Digital Thread platform, where the modeling Languages layer provides the essential modeling capabilities, e.g., for the GUI, data persistence, etc. The Process modeling layer models the business logic for the application in combination with already implemented Common and External Native Domain Specific Languages (DSLs). External Native DSLs are the set of services, technologies and platforms that reside on top of the standard DIME distribution. The different categories of functionalities that the platform supports are either already implemented/integrated (solid arrows among the External Service Providers) or in the testing phase/in progress (dotted arrows).

Figure 1. Architecture Overview of the Low-code Digital Thread Platform.

The rest of the paper is organised as follows: Section 2 summarises related work, Section 3 gives an overview of the software platforms adopted for the use case, Section 4 discusses the use case of a stable storage facility, Section 5 discusses the results, and Section 6 concludes and outlines future work.

2. Related Work

The widespread availability of technologies such as IoT, Cloud Computing, and communication protocols (e.g., Bluetooth, WiFi, LoRaWAN, etc.) has revolutionised the IT industry by enabling decentralisation of not only data locality but also computing resources. This allows improvement in large-scale data management in real-time and leads towards a high degree of innovation and simplicity in development workflows. Low-code development platforms are increasingly being adopted by the Information technology (IT) industry and enabling rapid development of complex workflows and software solutions by following a model-like paradigm, which focuses on composition behaviours rather than boilerplate code. In a worldwide survey, 96% of the IT professionals agreed that low-code development in comparison with traditional development is much faster [7] and expected to generate approximately 65 billion U.S. dollars revenue globally by 2027 within the low-code platforms market [8], which also demonstrates the potential and capabilities of this paradigm.

2.1. General Purpose Low-Code Platforms

Many industrial solutions support the visual composition of the orchestrations, which is more intuitive than manual coding. Several tools are available in the industry to work in a low-code fashion, e.g., Tines [9], an Irish-based company providing automatised solutions for security prevention; PTC ThingWorx [10], an all-in-one IIoT platform developed by PTC providing a pre-built solution for several requirements in the context of manufacturing; AWS IoT [11], a popular and scalable solution to handle up to billions of devices in the IoT context, allowing a cross-integration of capabilities with different services such as ML, analytics for Data-Driven decisions, etc; Microsoft Azure IoT Suite, another solution from Microsoft delivering integration with several services, not only with ML and analytics, but also adding security layers and connecting, monitoring and controlling in the cloud up to billions of devices as well [12] or H2o.ai [13], a complete no-code platform to deliver AI/ML solutions in the cloud targeting non-technical people to be able to complete working pipelines. Many of these tools either support control-flow or dataflow models, but not both, and do not have formal models incorporated.

Several use cases also have appeared in academia, to work in different domains to rapidly fulfil these requirements in a low-code way. For instance, [14] proposes an AI engineering platform for smart IoT services, enabling data analytics and ML parts to run partially or completely on the IoT edge devices. In [15], the authors establish an IoT-enabled application with early analysis of performance characteristics, such as timing and performance properties. This approach has a direct application in identifying issues with performance attributes, decreasing development time/effort, and delivering better quality without budget overshooting. The application itself is being developed using a lightweight interface tool framework, developed with the Eclipse Modeling Framework (EMF) [16].

2.2. Model-Driven Development

Model-driven development is a type of low-code development approach that focuses on the use of models to automate the software development process. In model-driven approaches, code generators are typically utilised to generate code automatically from higher-level specifications [17]. An interesting case for MDD IoT simulators can be found in [18], where new projects require a highly specialised setup (devices, fog/cloud/analytic nodes, hardware and software) and, together with the development cost, could be quite expensive. The AToMPM tool [19] is a web-based open-source framework to design DSL environments, perform model transformations and manipulate and manage models [20]. It also has an API for binding Python language. Component-based development [21,22] is another similar paradigm where independently deployable components are developed and then integrated into the bigger ecosystem. The modeling in component-based development, referred to as component modeling, defines the standards for the composition, modeling and deployment mechanism for the implementations of components. The authors of [23,24] used UML annotations for component models while [25] developed their own modeling languages. The PROGRESS project [25] defines the component models in the domain of embedded systems and consists of two modeling layers to handle different kinds of operation, i.e., ProSys models the systems and subsystems while ProSave captures the data transfer and control flow between the components. The functional behaviours of components are defined using REMES [26], a hierarchical modeling language.

Domain-Specific Languages in context of low-code platforms typically include pre-built components, templates, visual interfaces for designing and arranging application components and tools for integrating with external data sources and systems. Some prominent platforms that use DSLs are OutSystems [27] for enterprise applications, Mendix [28] for mobile applications, Appian [29] for business processes, Cinco [30] for metamodeling and [31] for big data workflows.

To make this more cost-efficient, simulation environments can help to model and obtain more useful insights about the architecture and focus on high-level concepts. Moreover, these types of architectures require programming skills to create the simulation environments. In order to make it accessible to everyone and enable the design of complex IoT simulation environments without writing code, a graphical and model-to-text approach was developed. Furthermore, these model-based languages often have a lower barrier to entry since they utilise graphical symbols and diagrams instead of code, which reduces the overall learning curve for domain experts. The study [32] compared various language workbenches with Cinco-family products and concluded that the LDE approach through DSLs overcomes the challenge of an extremely steep learning curve associated with development with traditional approaches.

2.3. DIME

DIME [5] is an Eclipse-based Integrated Modeling Environment that provides graphical DSLs for the development and deployment of prototype-driven web applications. DIME follows the One Thing Approach (OTA) [33] and the Model-Driven Design (XMDD) paradigm [34] for modeling and development. It provides a family of model types that are programming Language DSLs in order to tailor the environment to specific application domains. The different models are the following:

• Data Model: To describe the database layer.
• Process Model: This model type defines the business logic of the application. It uses control and data flow together to give a detailed view of the described logic.
• UI Model: A WYSIWYG editor for the web user interface.

The collections of components that can appear in the process models can be extended with Java code through a Native Service Independent Building Blocks (SIBs) mechanism, enabling the definition of new SIB palettes. SIB palettes are typically domain-specific and grow over time due to incremental extensions. These native DSLs are collections of ready-to-use functionalities, as described in Section 3.3 for our Stable Storage Facility (SSF) use case.

2.4. Pyrus

Pyrus [6] is a web-based graphical modeling platform specialised for Data Analytics that supports pipelines in a data-flow-driven fashion. The Python functions are implemented, stored and executed in Jupyter and displayed as a family of reusable DSLs in Pyrus. On execution, Pyrus performs automated model-to-code transformation on designed pipelines and executes them on Jupyter instance.

2.5. Node-RED

Node-RED [35] is a JavaScript-based, low-code platform, widely used for IoT projects. Originally developed by IBM, it is now also fully open source. The Node-RED modeling style is based on Flows, which are simple control workflows that can contain multiple operations (see Figure 2). Each operation is started by a trigger node, and successor nodes are linked via flow edges. If a node has multiple successors, they are executed in parallel. Node-RED flows are directly deployable from the flow editor in a single-click fashion. The dataflow is not visually presented and is implemented through Java Script Object Notation (JSON) messages passed along the control flow edges.

Figure 2. Example of a flow in Node Red.

Node-RED comes with a default set of available blocks and functions, but can easily be extended by adding modules to the Node-RED instances. As Node-RED has a very active community, there are many modules available, which can be installed directly through the UI interface. There is no notion of a data layer or database for the created flows, but there are modules to interact with files and databases.

There is no out-of-the-box UI element for the flows, but several UI modules are available. The Node-RED Dashboard is the de facto standard tool to create simple interactive UIs (see Figure 3). In the Node-RED Dashboard, the UI elements are introduced via node inflows and arranged via different node properties. There is no WYSIWYG editor for the UI, and the flow developer must specify the position of the element within a fixed page, tab, or row-like structure. This limits the available ways to position elements, but it creates very consistent UIs.

Figure 3. Example of a UI definition in Node-RED. (a) Simple UI Model in Node-RED. (b) The Node-RED Dashboard created by the UI Model (* indicates a required field).

2.6. Embedded Hardware Platforms

A plethora of low-power embedded computing and wireless sensor platforms have been developed over the past two decades by academic researchers, commercial enterprises and the Maker community. These platforms range from single board computers such as RaspberryPi, Beaglebone, and BananaPi to low-power, small-scale sensor nodes such as Rene, Mica, MicaZ, TelosB, IRIS, SunSPOT, the latter developed to study wireless sensor networks and their applications. The Maker community is served by several companies that develop and supply low-power embedded systems boards and platforms under labels such as Arduino, Adafruit, Sparkfun, and PyCom. The Pycom IoT device consists of a wireless module (Fipy) mounted on a Pysense expansion board equipped with several sensors: a temperature, humidity (SI7006A20) and light sensor (LTR329ALS01). The light sensor typically provides two channels labelled as ctrl_ch1 and ctrl_ch2, etc. to measure light intensity in different parts of the spectrum: one for visible light and one for infrared light. The outputs of these two channels are then combined to determine the overall light intensity in the environment. These computing platforms use microcontroller technologies from ARM, NXP, ST Microelectronics, Nordic, TI, or Espressif among others. They include wireless chipsets based on IEEE802.11 (Wi-Fi), Bluetooth (standard and BLE), IEEE802.15.4 and wide-area wireless technologies such as LoRa, Sigfox, NB-IoT and LTE-M. A wide range of commercial low-power embedded systems platforms are also available [36,37], but they tend to be designed for specific applications and use cases. A broad range of companies from system solutions providers to chip manufacturers also provide similar low-power embedded hardware and prototyping boards. The space is particularly vibrant with small companies and start-ups. A comprehensive survey of academic prototypes and commercially available wireless sensor platforms for Internet of Things applications can be found in [38].

3. The Software Platforms

In this section, we describe our technology stack for this case study and why we chose those technologies. Further, we show how the Native SIB concept leads to the production of reusable SIB palettes.

3.1. The Two LC/NC Integrated Modeling Environments

For this work, DIME and Pyrus are used as the modeling environments of choice. The combined view of control and data flow in DIME makes it easier to formulate complex workflows. Additionally, the interaction between DIME’s data and process layer allows checking the data types used by the individual SIBs, which helps to ensure the correctness of the operations. However, the complexity of DIME can also be too much when one just wants to analyse the collected data. So, Pyrus will be used for this step in the case study. The pure data flow approach of Pyrus makes it easy to clean, analyse and visualise the outcomes.

3.2. The External Software Platforms and Applications

EdgeX Foundry [39] is a leading open-source Industrial IoT middleware platform. It is widely used by industry and research teams for industrial automation. It helps exploit the benefits of the edge in terms of computing and intelligence. Its internal architecture has four service layers: (1) device services (2) core services, (3) supporting services, and (4) application services. A detailed description of all the layers and associated microservices can be found in [40,41]. The EdgeX services needed for our SSF use case are provided in DIME as an EdgeX-specific native DSL.

The Atlas NoSQL cloud database is a Database-as-a-Service product by MongoDB [42] that is optimised for complex data objects in real-time, which is one of the core needs of IoT applications. Hence, we use MongoDB to store/access the data collected from the Pycom FiPy sensors (light, temperature and humidity) via MongoDB-specific native DSL.

R [43] is an open-source programming language specifically for statistical computations and data visualisation. We use an R language native DSLs to analyse and visualise the datasets collected from different sensors.

Docker [44] is an open-source cutting-edge containerisation platform revolutionizing the way software applications are developed, deployed, and managed. With its lightweight, portable containers, Docker empowers developers to build, ship, and run applications seamlessly across diverse environments, ensuring consistency and scalability in the modern era of software development. We use Docker to securely deploy frameworks, services and platforms in separate containers.

3.3. The Native SIBs and SIBs Palettes

Figure 4a shows the visual representation of an SIB when used in a process model. The SIB requires two text inputs, a JSON string and a device_name, either from another SIB via data flow (dotted) edges or a static value.

Figure 4. Native EdgeX palette: the read_device_data SIB in DIME [45]. (a) The SIB in DIME. (b) The SIB body implementation in Java.

The backend implementation of this SIB in Java is shown in Figure 4b and is invoked at runtime, it reads all the values of the database from the different devices connected to the middleware. If the execution is successful, the corresponding data output is made available and the outgoing control branch labelled success leads to the next SIB in the workflow.

The low-code part of the development process consists of extending the capabilities of the DIME platform through this integration of further native SIBs when developing a new application. Every SIB is developed once and integrated into the platform for further reuse. This way the development of further applications that require similar functionalities in systems becomes increasingly a no-code task that also leads to much more efficient and waste-free production of software, based on large-scale reuse of quality-assessed components.

4. The Use Case: Stable Storage Facility

We illustrate the application of our low code development platforms through a specific IoT use case: controlling and maintaining the environmental conditions of a storage facility, where the temperature, humidity and light intensity need to be maintained at the required levels (SSF).

4.1. The SSF IoT Architecture

Figure 5 shows the run-time architecture of the SSF application. We use Pycom IoT devices to monitor the environment. In the experimental setting, Pycom FiPy devices are installed in the test environment (Lero building at the University of Limerick) to record the observations at fixed intervals. Each device periodically reports the data, i.e., light, humidity and temperature values, to an on-premise edge device. These devices send the data to the middleware platform (i.e., edge device with EdgeX Foundry listener) via the MQTT protocol that stores it in a no-SQL database in a MongoDB Atlas instance. Based on the received sensor data, the corresponding controlling actions can be enabled to manage the stability of conditions in the SSF. On the right side of Figure 5, we find the controller application. It is a web application developed in a low-code fashion using DIME and deployed into a dedicated Docker container. The web application manages all the devices and maintains stable environmental conditions. The web controller initiates the communication with the local MongoDB Atlas database and manages the data mobility with EdgeX Foundry over REST protocol and finally communicates internally with the R docker container for data-related computations and visualisations. We then implement the same data analytics pipelines in the Pyrus dataflow environment and then extend the analytics with more advanced features. This use case requires the integration and interoperation of a variety of systems, devices, software platforms, communication protocols and runtime environments. They are successfully orchestrated to produce a visualisation, an understanding and an interpretation of the data, in two different low-code platforms.

Figure 5. Stable Storage Facility (SSF): runtime architecture, infrastructure and communications.

4.2. Data Acquisition Process Model

Figure 6 shows the process model in DIME for the data acquisition from the IoT devices and its ingestion into MongoDB. In this model, the workflow starts with start SIB followed by a hierarchical GUI SIB for user interactions concerning device selection. The control flow then moves to the next SIB read_REST, reads the device data from the EdgeX Foundry instance and retrieves the corresponding raw data. For data collection, the SIB read_device_data, previously discussed in Section 3.3, parses the raw data, i.e., sensors data in JSON format from the middleware platform and returns the parsed data back to the GUI, which is then displayed on the web page. In the case of the storage requirements by the user, the control flow in Figure 6 proceeds to the right side of the workflow and performs the data ingestion into the MongoDB cloud database.

Figure 6. Data Acquisition from EdgeX Foundry and Data Ingestion into MongoDB-Process in DIME [45].

4.3. The SSF Control Application in DIME

Figure 7 shows the web page for the control application, where the header section displays the data collected from the different sensors: the temperature, humidity and light sensors. In the grid section, each "card" controls one of the actuators depending on the respective value/range that is selected using the range setter. Accordingly, all the sensors are continuously monitored. Whenever a sensor reaches one of its set threshold values, the controller will send the appropriate command to turn on/off the respective controlling unit: the cooling or heating unit in case of a temperature threshold, the humidifier in case of a humidity threshold and the lights based on the lux values. Additionally, the user also has the option to enable/disable selected devices using the toggle button visible at the top right of each card. For example, in this view, the Heating Unit is switched off while the other units are active. In this way, the application helps the users to optimise the environmental conditions of the Stable Storage Facility automatically with maximum efficiency.

Figure 7. The Control Application: the GUI.

4.4. The Reporting Dashboards in DIME and Pyrus

DIME: Figure 8 shows the process model for Analytics Dashboard in the DIME application, where connection_mongoDB SIB fetches the required data from storage and passes it to the split_data_frame SIB along with the column names that require splitting, e.g., in this case, a total of four channels from two devices, i.e., light_ch1, light_ch2, light_ch3 and light_ch4. The next SIBs plot the graphs against these data frames, as shown in Figure 9. The plots are then displayed on the web application using the GUI SIB analytics_dashboard.

Figure 8. Analytics Dashboard in R: the process in DIME [45].

Figure 9. Dual and quad summary line plots generated using R and the DIME DSLs and processes [45].

Pyrus: Now we discuss how we carry out essentially the same computations in Python using another low-code/no-code platform: Pyrus. Figure 10 shows an alternative data processing pipeline implemented in the Pyrus. The pipeline starts by establishing a connection to the MongoDB with the connection_to_mongoDB block with the required inputs. It again fetches the required data in JSON format and the data frame is passed to the next block, convert_to_datetime for preprocessing. The data frame and the names of the channels are then passed to the block dataframe_split to create a separate data frame for each light channel. Finally, the plot_all_data block plots the same graphs in Pyrus as shown in Figure 9.

Figure 10. Analytics Dashboard in Python: the Pyrus pipeline [45].

Further, we extended the analytics capabilities of the pipeline from Figure 10 with additional parameters, as shown in Figure 11. This new pipeline analyses the data collected from light, humidity and temperature sensors. The data are directly acquired from the MongoDB database using the connection_to_mongoDB block. The data are then pre-processed by dropping the irrelevant columns, renaming existing columns and converting the time column to Pandas datetime format using the clean_df block. Since the data are collected from the devices over the span of several days, a range of dates can be selected for analysis. This happens using the date_mask block, where the sample date of 18 November 2022 is input. The final plot_all_data block plots all the processed data frames in the Pyrus dashboard, as shown in Figure 12.

Figure 11. Extended Pyrus pipeline.

Figure 12. Advanced Analytics visualisations generated using Python and Pyrus.

5. Results and Discussion

The presented case study concretises a heterogeneous architecture for the development of low-code IoT applications, where sensor devices interact with an orchestrator and an analytics server to automatically control the environmental parameters via a web controller based on the sensors’ input, and eventually facilitate the decision-making process with the help of data analytics, which enables the storage facility supervisors to take future decisions. In the concrete experimental setting, we consider the scenario of controlling and maintaining the environmental conditions of a Stable Storage Facility (SSF) where the temperature, humidity and light intensity levels need to be maintained at the required levels.

5.1. Platform Extension through New DSLs

We have extended the Native DSLs for EdgeX Foundry, REST, R, and MongoDB, while also addressing MQTT and Raspberry Pi. From the DIME processes, we communicate with the EdgeX Foundry services via REST protocol without any manual integrations. For the sensor devices, we use standard APIs to capture and send data to the EdgeX Foundry server using the MQTT protocol over WiFi. Altogether, we have integrated nine independent technologies in two distinct Low-code development environments with the production of seven processes and pipelines, and the definition of 25 SIBs in 9 distinct DSLs. The significance of this approach lies in its contribution to the extent of the supported functionalities in the Digital Thread Platform of Figure 1.

5.2. Benchmarking Code Generation

Embracing a platform mindset results in a single implementation of functionality with high reusability across multiple domains by very different domain experts. Additionally, a large part of the code is automatically generated from the models. To showcase these effects, we benchmark two of the implemented case studies: the SSF presented in this work and the predictive maintenance case study presented in [46].

Figure 13 shows the count of total lines of code generated (blue bars) for the implemented pipelines vs. the lines of code manually implemented (orange bars) as new SIBs. In Table 1, we see that for all three languages (Dart for the frontend, Java for the business logic and HTML for the UI), the new code written manually is a fraction of the total code. For Java in our use case, we have 1326 new lines of code in comparison with 10,889 resulting from the generation, which links also preexisting SIBs. This means that we wrote only 12.18% of the new code needed for this application, and the data show that this proportion is similar across languages and case studies. This comparison demonstrates that the dependency on software developers for new code is greatly reduced because we leverage the generation from models and the availability of the platform and prior DSLs.

Figure 13. Total lines of code vs. newly added functionality code in both DTP applications.

Table 1. Code stats for DTP applications.

	Predictive Maintenance			Stable Storage Facility
	Dart	Java	HTML	Dart	Java	HTML
Total lines of code generated	11,250	11,096	943	12,037	10,889	1006
Total lines of code implemented	1517	1533	190	2304	1326	253
Percentage of code implemented manually	13.48%	13.82%	20.15%	19.14%	12.18%	25.15%

5.3. Effects on Reuse

The encapsulation of this heterogeneity within the DSLs via uniform graphical representation in DIME makes it possible for domain experts to correctly identify and reuse large portions of functionality across different applications. Identifying features in code with the goal of encapsulation and reuse is a well-known nightmare at the code level, as it requires reverse engineering of code and dependencies. This is a core reason why even very common functionality is re-implemented over and over again. With our low-code, graphical and generation-based approach, we avoid the problem by learning to work with only three DIME model types. In addition, domain experts can create high-quality applications spanning across various application domains and technologies without requiring the mastery of the underlying technologies, programming languages, or communication protocols.

In terms of relevance to the IoT user community, this is a transformative contribution where, rather than requiring expertise in a multitude of diverse technologies, users only need training on these low-code platforms with small learning curves because of the simpler abstractions compared to traditional programming languages. After initial training, IoT application developers can effortlessly design, deploy, maintain, and evolve their applications in a uniform environment through platforms like DIME and Pyrus. The proposed approach can effectively support the development and deployment of small to large-scale IoT applications using the multi-node Edge-X deployment.

In terms of the choice of models, we chose to combine simplicity [47] with formality [48,49], to enable ease of comprehension by a wide range of specialists and at the same time pave the way to automated verification and validation along the lines of [50] for model checking, [51] for automated synthesis, [49,52] for automated testing and validation, and [53] for the automated support of CI/CD. Altogether, the long-term goal is to support the full lifecycle of continuous model-driven engineering [54].

6. Conclusions and Future Work

Domain-specific languages in a low-code and underlying model-driven paradigm have become a popular approach to design, develop and quickly ship heterogeneous systems. In this use case, we developed a heterogeneous system that connects various technologies: the web application interacts through the EdgeX middleware platform with several sensors and data analytics pipelines. We presented a specific IoT use case: controlling and maintaining the environmental conditions of a storage facility, where the temperature, humidity and light intensity need to be maintained at the required levels (SSF). The edge computing and analytics-related SIBs are developed and added to the suite of External Native DSLs library of the Digital Thread Platform. The developed application collects, processes and displays key information about the state of the edge data capture and computing. We use DIME to design the complete application and to implement the IoT and edge aspects, and Pyrus to implement no-code data analytics in Python. The developed case study is benchmarked and compared with prior case studies to showcase the aspects of reusability. We demonstrate and conclude that both are straightforward approaches in which domain experts can create IoT applications in a low-code fashion. Our next steps include the extension of the supported devices, protocols and services within the capabilities of the DTP.