Software-Bus-Toolchain (SBT): Introducing a Versatile Method for Quickly Implementing (I)IoT-Scenarios

Abstract

The Internet of Things (IoT) has become ubiquitous. IoT devices are applied in a multitude of applications, e.g., in smart home scenarios, building automation, smart energy and smart cities, healthcare, and industrial environments. Fast and efficient implementation and roll-out of IoT devices is a critical factor for successs and acceptance of IoT devices. At the same time, the variety of hardware platforms that can be used for IoT applications, as well as the number of IoT orchestration platforms is increasing. Finding the right combination of tooling and hardware is not trivial, but essential for building applications that provide value. In this work, a Software-Bus-Toolchain (SBT) is introduced that encapsulates firmware design, data point definition, and communication protocol usage. Furthermore, an IoT control platform is provided to control and evaluate the IoT modules. Thus, using the SBT, solely the business logic has to be designed, while the hardware-design is automated to a high degree. Usage of the Zephyr framework allows the interchange of hardware modules, while interfaces provide easy adaption of data points and communication capabilities. The implementation of interfaces to the IoT-platform as well as to the communication layer provides a universal usage of logic and data elements. The SBT is evaluated in two application scenarios, where its flexible nature is shown.

1. Introduction

The term Internet of Things (IoT) gained popularity after Kevin Ashton used it in 1999, in conjunction with the development of Radio Frequency IDentification (RFID) technology [1]. It is used for sensor and actuator networks, usually employed in a distributed manner with a high data volume, using Internet Protocol (IP)-based technologies, e.g., as defined by McKinsey [2]. These definitions imply that the value of IoT networks does not lie in their hardware-capabilities alone, but in the possible combinations of sensors and actuators to obtain multi-dimensional information in the application environment. Consequently, the market for IoT applications is consistently increasing, with a peak of a global market size of 384.70 billion USD in 2021 according to Fortune Business Insights^TM [3]. A large number of different application areas explain the constant increase in demand. End users employ IoT devices in smart home environments [4,5]. The principal of control, sensing and automation with distributed devices is employed in smart city [6,7], smart farming [8,9] and industrial [10] applications. Smart grids [11] assist in the smart and sustainable distribution of energy. Retail [12,13] scenarios with IoT assistance provide a more convenient shopping experience, while IoT in healthcare [14] increases efficiency in treating and curing people. In general, IoT applications provide the potential to lower cost and management effort by minimising the need for on-site operations while increasing efficiency by providing insights from measurements and data aggregation. This potential provided by IoT solutions has risks, however. Security is paramount, as vulnerabilities in systems interacting with the physical world provide threats to digital as well as physical assets [15,16]. Generally, IoT devices are expected to be cheap, with a short time to market [17]. This puts constraints on the development and integration of such devices, leading to code reuse and a consequent vulnerability of devices to the same threats [18]. A strong competition has emerged on the IoT market, highlighted by the growing number “publicly known IoT platforms”, as analysed by IoT Analctics [19]. As depicted in Figure 1, provided by aciot Analctics (https://iot-analytics.com/iot-platform-companies-landscape/, accessed on 23 June 2024) [19].

An increase in IoT platforms between 2015 and 2019 can be observed. However, starting 2019, the trend stops and the number of IoT platforms remains stagnant. This fact, combined with the ongoing growth of the IoT market size indicates that IoT is still a sound business model. According to their study, a number of 188 platform operators has ceased business over the years 2019 and 2020. Such platforms are commonly used to orchestrate and manage IoT devices. Apart from the platform, the devices are required. Low-cost embedded hardware platforms are commonly used, providing a number of development environments for easy implementation and set-up, such as Arduino [20], MIKROE [21] and Zephyr [22]. These tools still require a significant amount of coding, but mitigate the need to program hardware bare-metal. The large number of management platforms on the one hand and the still high implementation effort on the hardware-side motivate the need for an end-to-end IoT builder framework that allows an easy implementation as well as set-up and management of devices.

In addition to the IoT employed in home environments, the Industrial Internet of Things (IIoT) has been introduced to industrial applications as part of the concept of Industry 4.0. Despite the difference in application scenarios, the use cases are often similar and include distributed, heterogeneous systems that need to provide correct information in a timely matter. While Open Platform Communication Unified Architecture (OPC UA) has become the de facto standard for industrial communication in the context of Industry 4.0, an abundance of scenarios still employ legacy communication protocols.

In the course of research project InnoTop, a Software-Bus-Toolchain (SBT) was developed to meet this demand. InnoTop is a public funding programme provided by the Federal State Rhineland Palatinate and managed by the Investitions- und Strukturbank Rheinland-Pfalz (ISB). Its aim is to foster research and development in local SMEs. The contribution of this work consists of the development of an IoT builder framework that:

• Allows for a quick implementation of business logic. That means the actual functionality in should be easy to set up without implementation of low-level functions.
• Functionally separates data elements the IoT device interacts with, meaning the data can be defined and used independent from the low-level implementation.
• Functionally separates the communication protocol from the business logic implementation.

This framework allows for the quick creation of novel IoT devices and networks as well as integration of new IoT devices into existing environments, resulting in less time to release, less low-level implementation effort, higher flexibility in terms of decoupling hardware from function and unified date elements. In contrast to existing tools, the SBT considers programming environment for embedded devices and IoT platform alike, while reducing implementation effort for both. The implementation of abstraction layers allows for seamless transfer of application code between devices. Furthermore, these abstraction layers enable the integration into an IoT platform. Data is defined and standardised into data points that are described as Google Protocol Buffer elements. This standardisation provides fast creation and re-use of elements as well as a standardised interface to the communication layer. Additionally, any computation on the IoT platform, for which Node-RED is used, is performed based on these data points by functions specifically implemented in the course of the project. In the course of project SBT wrapper functions are implemented that provide standardised interfaces and enable exchange of data from physical sources, as well as hardware platform.

The remainder of this work is structured as follows. A background is provided in Section 2. Requirements for an IoT builder set up are discussed in Section 3. The components developed in the course of this work are presented in Section 4. Implementation details are introduced in Section 5. The IoT builder environment is evaluated in Section 6. A conclusion is drawn in Section 7.

2. Background

Two different aspects of frameworks for IoT environments are discussed in this section: Management and orchestration approaches discussed in the scientific community, and management and control platforms that are predominately available in commercial and open source software projects. Noura et al. evaluate taxonomies and present levels of interoperability that can be used to measure the usefulness of IoT systems [23]. They distinguish between the following six levels of interoperability:

• Device Level Interoperability
• Network Level Interoperability
• Syntactic Level Interoperability
• Semantic Level Interoperability
• Cross-platform Interoperability
• Cross-domain Interoperability

These levels of interoperability are used to evaluate the use cases that a certain IoT solution can satisfy the requirements for.

Braten et al. present a survey on autonomous IoT device management systems [24]. They distinguish along several dimensions and classify scientifically developed approaches to IoT device management according to several adaption mechanisms, where the functional aspects of the device management are considered. Cheruvu et al. present a survey of IoT frameworks with a focus on complexity in terms of functionality and resource cost [25]. Several authors address the demands posed by the heterogeneity of IoT networks as well as simplified representation of services and devices. Aïssaoui et al. introduce an ontology-based approach to handling heterogeneous IoT devices [26]. Privat disusses how IoT devices can be integrated into a broader network context and used for complex sensor and actuator networks [27]. Fortino et al. discuss the digital representation and integration of IoT objects into digital libraries for simple reuse and management [28]. Microservice-based architectures are discussed as well. Uviase and Kotonya survey existing integration frameworks for Service Oriented Architectures (SOAs) in IoT and conclude with a microservice-based architecture for enhanced interactionability [29]. Similarly, the interoperability of IoT devices in a Peer to Peer (P2P) fashion is discussed by Chen [30]. Sun et al. present a microservice-based architecture for IoT networks [31]. Furthermore, resource constraints and Wireless Sensor Networks (WSNs) are commonly discussed. Mavromatis et al. highlight the networking aspect of IoT device management [32]. They focus on edge and cloud approaches with Software-Defined Network (SDN)-based solutions in WSNs. In their Machine to Machine (M2M) scenario, this communication provides a significant decrease in traffic volume. Maloney et al. discuss an agent-based approach to address the resource constraints in IoT devices [33]. They aim at mitigating the overhead in commonly used management platforms with a lightweight mechanism. Großmann et al. discuss a sensor monitoring framework that provides a resource-efficient platform for collecting information from sensor devices [34]. IoT can be applied in several domains. Calderoni et al. introduce an IoT management platform focussing on smart cities [35]. Balachandar and Chinnaiyan address the security aspects of IoT networks with a rule-based approach that allows management of the security objectives [36]. An application for IoT in healthcare is discussed by Gelogo et al. [37]. Burger et al. present an approach for integrating Field-Programmable Gate Arrays (FPGAs) into IoT networks in an on-demand-basis to better distribute and manage resources [38]. Perumal et al. present a concept architecture for smart home IoT applications [39]. It basically consists of wrappers that identify devices in a network and map their functionality to actionable items in the presented framework. Implementation of IoT devices is not discussed in their paper.

Management and orchestration platforms are provided by major cloud providers, such as Microsoft [40], IBM [41], GE [42], and Amazon [43]. Bilgeri et al. present an IoT buisness model builder approach in a white paper [44]. They put a strong focus on the organisational aspects in creating business value from IoT systems. Apart from the large companies, there are several smaller companies, such as twilio [45], openremote [46], or MiMove [47]. The main concern of such platforms is the management of devices, i.e., the collection of data and provision of commands. They offer respective eco-systems that allow integration of novel, pre-conditioned devices into a system. However, the development and implementation of devices is mostly not considered. This is a drawback which is considered by the SBT framework. Platforms such as macchina [48], DeviceHive [49], DSA [50], Kaa [51], and openHAB [52] provide platforms for easy integration and control of devices. These devices need to be able to communicate with the platforms in order to function correctly. On the other hand, there are frameworks, such as Zephyr [22] and Arduino [20] that focus on simple implementation of IoT devices. In a similar fashion, Zetta provides interfaces for IoT components to enable easy integration of devices into IoT systems [53]. The SBT framework presented in this work employs Zephyr for creation of IoT devices.

3. IoT-Builder Requirements

There is a consistency in literature regarding IoT products about the obstacles to overcome in order to obtain sound and useful IoT products [54,55]. Commonly mentioned criteria that need to be addressed for successful implementation of products contain:

• Security,
• connectivity,
• heterogenity and cross-platform compatibility,
• data collection and processing, and
• the skill set of the people.

Additionally, Hackbarth mentions the three challenges of

• “Rapid application development for IoT”,
• “Managing heterogeneity and diversity”, and
• “Building customizable IoT solutions”

In a blog contribution for Bosch [56]. These assessments from different sources highlight that developing and rolling out IoT products requires diverse expertise and resources. The devices have to be implemented on a variety of hardware bases, be integrated into IoT platforms and exchange a well-defined set of data and controls. Thus, IoT implementation requires knowledge in hardware-constrained programming for embedded devices, data engineering and management as well as platform architectures. Due to the hardware used for IoT-scenarios, resource constraints are to be taken into account as well. In addition to these conditions, timing commonly is a factor. Embedded hardware boards that provide the basis for IoT devices have short update cycles. Communication protocols are regularly introduced and need to be integrated into new and existing platforms. Based on these restrictions, the comlet SBT toolchain adheres to certain requirements. The SBT toolchain needs to be extensible, i.e., if new hardware boards or communications protocols are introduced, they are easily integratable into the platform. Use cases need to be easiliy implemented with the SBT toolchain. That necessitates a high level of abstraction so that commonly used functionality is handled independant of the user. This additionally allows for a separation of business case and technical implementation which reduces time to market and implementation effort. Furthermore, as an enabling condition for this requirement, data and communication needs to be abstracted and provided via a defined interface for an abstracted and pre-defined control platform. How these requirements are met is discussed in the next section. After that, demonstrator implementations of IoT networks based on the SBT toolchain are presented.

4. Software-Bus Components

The SBT consists of several components that are combined to either individual devices or extensive networks. These components address every aspect in IoT architectures. They are discussed in the following subsections.

4.1. Architecture and Structure

Regarding the structure of the SBT, two aspects need to be considered: The implementation part as well as the operation part. During implementation, the SBT provides extensive aid in setting up parts of or complete IoT environments. During operation, the architecture can be employed both in green field and brown field scenarios, i.e., SBT devices can be integrated into existing networks or used to create networks from scratch. Regarding the implementation of IoT devices or environments, SBT offers a tool box that provides data point descriptions and communication stacks which can be used with a variety of different hardware devices. Setting up a device or network only requires implementation of business logic as functional aspects of data description and communication are addressed by SBT. This approach is depicted in Figure 2.

The implementation approach leads to one or several devices that can be integrated with an IoT platform. Figure 3 provides an overview of common IoT environments.

Furthermore, potential applications of SBT are highlighted in this figure. The SBT can either be used to create the highlighted parts and thus be used for retrofitting or extending existing networks. Alternatively, the SBT can be used to create novel IoT environments and is able to provide all of the features. Consequently, the device level, syntactic level, semantic level, cross-platform, and cross-domain interoperability according to Noura et al. [23] are satisfied, leaving only the network level interoperability which can be integrated into the SBT at a later point, but is currently not part of the framework. The remainder of this section describes individual aspects of the SBT components in further detail.

4.2. Data Points

Data is the crucial aspect of any IoT environment. Embedded devices are controlled to perform certain actions, depending on conditions, or sense their surroundings and provide this information. Collecting and transferring data is the basis for any activity. Examples are the turning off of a heater if a sensor discovers an open window or the collection of temperature and humidity. In the context of the SBT, data points contain a piece of data in connection with meta-information, such as unit, type and upper and lower bound. Data points are created by the SBT components and transmitted via communication protocols. This approach provides syntactic level interoperability, as any given data can be defined and integrated into devices.

4.3. Communication Protocols

In order to be universally applicable, the SBT supports a large number of communication protocols. This stack is an initial set-up that will be extended continuously. As a general concept, the communication protocol is abstracted in a way that interfaces take data points, wrap them in packets of the corresponding communication protocol and transmit them via a hardware connector. This approach ensures independence of data points from the communication aspect. The same data point can be created, sent or received on different devices via different protocols. This approach provides device level interoperability. As protocols are available as functional modules, the implementation time is reduced as well. Currently, the following protocols are implemented:

• WiFi
• TCP/IP
• Bluetooth
• I²C
• SPI
• UART

This collection shows a focus on microprocessor-boards and their communication. However, the implementation of protocols from IIoT scenarios, such as Modbus, CAN, and Profibus are currently pending.

4.4. IoT Platform

In IoT scenarios, the dashboard plays a crucial role in data collection, preparation, storage, analysis and visualisation on one hand. On the other hand, devices are commonly controlled via a dashboard platform. This dashboard connects the individual devices, stores and aggregates the information they provide and forms decisions based on the data that is translated to actionable commands. As discussed in Section 2, a multitude of publicly and commercially available solutions focuses on the central platform for control and collection. In the SBT, a central platform is tightly integrated with the devices. The data points are exchanged and integrated into the control logic in the platform. Interfaces for visualisation, data storage, and analysis are provided. In general, this versatile platform allows for semantic level, cross-platform, and cross-domain interoperability, as domains and platforms can be integrated and data can be processed with a semantic understanding.

The implementation solutions for these components are discussed in the next section.

5. Implementation

This section discusses how the components of the SBT architecture, as presented in the previous section, are implemented. The basis of any IoT framework is data, while the backbone is a platform interconnecting devices and making sense of the data. Consequently, communication is the third vital aspect, as devices need to communicate and data needs to be transmitted.

5.1. Data

Data is stored using Google Protocol Buffers [57]. On their website, they are labelled a “language-neutral, platform-neutral extensible mechanism for serializing structured data”. As IoT devices most commonly provide structured data, i.e., a value, a unit, and additional information, such as boundaries, they are easily encoded as Protocol Buffer elements. An advantage of Protocol Buffers is their platform- and software-independence. Currently, the SBT framework is used for embedded devices that are implemented using C and C++. However, the same data can be used in apps on mobile applications or in desktop tools. Furthermore, Protocol Buffer provide a small fingerprint regarding data size which is especially useful in low-latency communications. An exemplary description of a data point can be found in Listing 1.

Listing 1. Exemplary Protocol Buffer definition.

message Data {       required name = 1;       optional unit = 2;       required value = 3; }

These definitions are created once for every data point of interest that is to be integrated into and used inside the IoT environment. In the context of the SBT project, data point definitions were created to generalise the data embedded devices are working on. These data points are consequently used and stored in the IoT platform. In the course of the project, relevant data points were defined to describe common sensor and actuator values, such as temperature, brightness, or current. These data points were shared between all participating devices as well as the IoT platform.

5.2. Platform

A crucial part of IoT environments is a platform that collects, analyses and orchestrates data. Data in this context describes physical environmental conditions, such as temperatures or actuators, such as light switches. This data from distributed entities is gathered and combined to create a meaningful result. For the SBT framework, Node-RED [58] was chosen. It acts as a middleware to connect entities and perform computations. Its application to industrial systems has been, for example, discussed by Nitulescu and Korodi [59] as well as Folgado et al. [60]. The benefits of Node-RED are its easy to use interface, its flexibility, and its potential to be extended with custom functionality. It is lightweight and supports several hardware platforms. It provides a large set of supported functions and communication protocols. Additionally, implementing a semantic representation of the data points by integrating the Protocol Buffer descriptions was a simple task. Node-RED allows the creation of flows that connect inputs from distributed devices to outputs. An exemplary flow is shown in Figure 4.

Node-RED furthermore provides means to extract data and store it persistently, for later analysis and visualisation. For the SBT, InfluxDB in combination with Grafana were used, as they both are tailored for time series and the serial values in IoT environment can easily be represented as a time series. Due to the versatile nature of Node-RED, sending time series data into InfluxDB is possible independent of the manner of hosting the database. In our case, the InfluxDB database was located on the same system as Node-RED. However, as a web service, it can be hosted on premise as well as the cloud. Since Node-RED provides connectors for commonly used protocols, it was easy to connect SBT devices to the Node-RED platform. Communication of the SBT framework is discussed in the next subsection. This platform is currently hosted on a Raspberry Pi 3. In the context of the SBT-project, Node-RED modules for collecting and working on the data generated by the embedded devices were implemented. Furthermore, logic to compute output signals that could be translated to actions by the IoT devices was developed. The concept of a Node-RED platform was taken and extended with custom functionality, namely additional function blocks for reading, decoding, encoding, and writing data points to and from the embedded devices. This feature enabled the IoT platform to orchestrate the embedded devices.

5.3. Communication

Communication between machines and devices occurs following specific protocols. These protocols differ depending on the application area. Industrial applications employ certain established protocols, such as Modbus TCP/IP, Profinet, and OPC UA. In the automotive area, CAN is widely used. For home automation and IoT, MQTT, M-Bus, KNX, and Ethernet-based protocols are used for wired communication. In wireless use cases, ZigBee, LoRaWAN, and, more recently Thread as the protocol of Matter, are well-established. MQTT can be considered as the de facto standard for IoT applications. These protocols are provided by hardware drivers that correctly employ the hardware interfaces of a device, as well as by software stacks that implement the protocol to ease the integration. For the SBT framework, an interface between data and communication protocol was designed. Thus, the application specific code can hand over data to an abstracted communication interface, while the concrete implementation is device-specific. As a consequence, application-specific code can be re-used by changing the device and corresponding software stack. This layer of abstraction increases the usability and ease of use, while also providing benefits regarding the time to market. Most embedded hardware boards provide libraries with drivers for a given communication stack. The advantage of SBT was to implement and provide a layer of abstraction by creating a wrapper with interfaces that translates between the communication drivers and the data points. This allows for a seamless change of hardware platform, as the implemented wrappers provide the same interface for the application, i.e., the data points, while translating to all common hardware drivers.

5.4. Putting It All Together

Finally, the previosly discussed parts of the SBT framework are integrated. Zephyr [22] is used for this integration. Because of its support for a wide variety of embedded devices from different vendors, Zephyr provides support for many different hardware layouts. The interface used to communicate data points to the protocol layer allows for easy integration of the SBT framework into Zephyr. This interfacing, allowing the use of Zephyr as well as use of other embedded programming languages, is a benefit of the SBT project. Every interaction with a hardware driver is abstracted so that a programmer does not have to implement it anew for novel hardware. Furthermore, the abstracted data points can be used in an architecture- and programming language-independent way. In general, the data points are defined for the application using the Google Protocol Buffer, since they are architecture and code agnostic. The communication protocols are implemented from scratch, using common drivers. Furthermore, they are set up with an abstraction layer so that the communication protocols can be set up to work with any given data point on any supported hardware. This is a contribution of SBT. Node-RED is used as an orchestration platform, with custom-made modules for data handling and storage. All components are sufficiently lightweight in terms of resource usage that they are feasible for IoT-environments.

6. Evaluation and Demonstrator Use Cases

In order to evaluate the usefulness and applicability of the SBT framework, two demonstrator scenarios were implemented. A smart home demonstrator was set up using only SBT components. Furthermore, an industrial use case was considered. Here, an existing model factory was extended with additional sensors for Condition Monitoring (CM) and obtaining process information.

6.1. Smart Home Demonstrator

The smart home demonstration environment implements commonly used smart home functionality in a doll house. Smart home functionality as such is not a novel feat. However, the approach in setting up and implementing the features is of interest. The following criteria were evaluated:

• Transferability of functionality
• Time
• Reusability

A comparison with traditional implementation of embedded devices is intended. In this doll house, as shown in Figure 5 the following sensors are physically implemented:

• two Photovoltaic (PV) modules,
• five temperature sensors, and
• one motion detector.

The following actuators are integrated to control the smart home environment:

• five heating elements, simulating heaters,
• two sets of WS2812 NeoPixel LEDs, simulating television and bathtub,
• five LEDs, simulating lightbulbs, and
• one set of LEDs, simulating an oven

Each of those sensors and actuators was described by a data point containing information such as value and unit. This definition was reusable between devices and IoT platform.

These elements were controlled by four embedded devices, two ESP32 micro-controllers that were connected to the IoT platform via Ethernet, one nrf9160 micro-controller, that was connected to an ESP32 via Bluetooth that, in turn, routed communication to and from the platform. Finally, an STM micro-controller Nucleo-L073RZ, that was connected to the other ESP32 via UART, was used. The sensors and actuators were distributed among these four micro-controllers. An overview of this architecture is shown in Figure 6.

From a technical perspective, this architecture is more complex than necessary. However, the aim of this demonstrator scenario was to create complexity. A central IoT platform based on Node-RED was successfully used to control four distributed devices, of which only two had direct access to the platform. A PID controller was implemented for the heating elements, combining temperature values from one physical device with output values from another. Conditions and connections of sensor values and actuator were created in a simple fashion, due to the unified data point-structure. In the course of the demonstrator scenario, several micro-controllers were used. Exchange of devices was simple and quick due to the abstraction layer, provided by the SBT framework, as well as the underlying Zephyr toolchain. The following findings were derived. he base code remained the same. Also the data point definitions were used on every device. The implementation had to be done only once. That means Zephyr provided a base for any feature implementation. These features were dependent on data points providing information about sensor values and setting actuator targets. The logic was created on the Node-RED platform. Generally, the same code could run on boards of different vendors, with only the pin-layout needing to be adapted. In Zephyr, this can be done with an overlay file that maps logic pin descriptions to the physical pins. Additionally, communication stacks could be integrated into the solutions and were wrapped with standardised interfaces. That allowed transfer of functionality between communication channels. Generally, the SBT functions as a building toolbox that connects hardware drivers, an IoT platform and expressive data point definitions to functionality with few manual labour. The time to change a micro-controller board while maintaining the same functionality was considerably less than a reimplementation would have required.

6.2. Smart Factory Demonstrator

In contrast to the smart home demonstrator, the smart factory demonstrator is a so-called brown-field scenario. Such scenarios are often found in practice, as industrial environments commonly contain legacy devices [61,62]. These devices are used for specific steps in processing. They are spatially distributed and difficult to upgrade as upgrades are mostly rolled out via physical medium [61,62]. Legacy and proprietary protocols are used that need to be integrated into the environmental context [61,62]. Due to the cost of downtimes, these machines often run around the clock and are seldomly maintained or updated from a software-perspective. This fact in conjunction with the increase in interconnectivity in industrial areas, creating the IIoT, creates an abundance of vulnerabilites [16,61].

For this demonstrator, a fischertechnik smart factory was employed with the pre-implemented process scenario [63]. It consists of a high-bay warehouse, a crane with vacuum grabber for moving the materials around, a processing as well as a sorting station. Material can be delivered to and from the factory. A picture of this smart factory is shown in Figure 7.

For the smart factory demonstrator, the available system model from fischertechnik was employed to emulate a brown-field scenario. This system uses a Siemens S7-1500 to take in, store, process, and deliver materials. This Programmable Logic Controller (PLC) provides OPC UA-support. OPC UA is an industrial data model that provides connectivity and descriptions of devices and allows, among other features, for M2M communication. An Asset Administration Shell (AAS) can be integrated. This OPC UA functionality was used to notify the SBT dashboard of changes in the output connectors of the PLC. Additionally, an SBT component was set up that measured the electrical current consumed by different parts of the factory. With this sensor-fusion approach, deviations of expected behaviour can be discovered. The electrical current sensors were controlled by an ESP32 micro-controller, which was integrated into the system. Data points describing the current in terms of value and unit were used to generalise monitoring. The features of the SBT allow for the integration of OPC-UA values and the retrofit of external sensors, such as the ESP32 used in this scenario. This is especially interesting as the base functionality of the smart factory was already implemented on the PLC. The possibility to integrate that into an IIoT with standardised interfaces enables flexibility. To simulate wear of devices, rubber bands were employed to mimic increasing mechanical load as it occurs in practice when lubrication of housing of rotating parts degrades, or when the tools grow dull due to wear and require more force. While the OPC UA state clearly shows that the correct outputs for the processing steps were set, the electrical current sensor is capable of differentiating between zero, one, and two rubber bands. A comparison is shown in Figure 8. It shows that the current required to move a motor is nearly linearly dependant on the number of rubber bands added to the motor. The addition of rubber bands in this case simulates wear of a motor due to degradation of an attached tool or the lubricant used.

That indicates the value of retrofit sensors and shows their usability. A framework to quickly and easily set up IIoT sensor networks can prove significantly useful in detecting and predicting faults and, consequently, leading to stable operation.

7. Conclusions

In this work, an SBT was introduced. Its contribution is twofold: On the one hand, a framework for quick, easy and versatile setup of partial or complete IoT networks is provided for programmers. On the other hand, a flexible environment is created that can serve as a stand-alone IoT network as well as an extension to existing ones is provided to users. It allows an easy set-up of IoT and IIoT devices as well as platforms to control these devices. The integrated support of commonly used communication protocols with the capabilities for easy extension enable flexible creation and extension of IoT and IIoT environments. As data, its creation, transport, and usage is a core concept of IoT environments, the SBT provides a unified data model based on Google Protocol Buffers. An integration of the data and communication model into the Zephyr-environment creates an easy-to-use framework for quickly and efficiently setting up IoT environments. Standardised interfaces allow seamless integration and extension. Every level of interoperability according to Noura et al. [23], except for network level interoperability, which can easily be integrated as well, is provided. In contrast to other existing solutions, this framework provides value to programmers and users alike.

This concept was evaluated in two application scenarios, a smart home environment as well as an emulated smart factory. According to a non-representative survey of developers participating in this project, the solution was able to reduce the time for set-up and implementation of functionality by factor four on the hardware-side. The intended functionality could be easily set-up and ported between different devices with the presented framework. Implementation of business logic is easily separable from the device control. Control and data storage are integrated into the framework and provide means for visualisation and analysis of data. The implementation of abstraction layers was successfully addressed and enabled seamless transfer of application code between devices. The integration into an IoT platform was achieved by defining and standardising data points as Google Protocol Buffer elements, allowing fast creation and re-use of elements. Computations on the IoT platform were performed using these data points by functions specifically implemented during the project. Wrapper functions were developed to provide standardised interfaces and enable data exchange from physical sources as well as hardware platforms.

Next steps in the development of the SBT include the integration of additional communication protocols, an increase in capabilities for data analysis and an extension of the framework to industrial devices, such as PLCs and others. Due to the different setup approach of PLCs, the adaption will have to take novel features into account, as setting up PLCs for industrial applications is not a trivial task.