Application development in the Internet of Things is becoming an ever greater challenge. An almost unmanageable range of different technology modules plus a global competitive environment that has never existed before in information technology at this level of intensity, as well as emerging legislative initiatives on cyber security such as the EU Cyber Resilience Act, are one thing. Multidimensional cost aspects, the need to bring new products and solutions to market as quickly as possible, uncertain global hardware component supply chains and the shortage of skilled workers for development, installation and service are other influencing factors. All in all, IoT solution developers are well advised to create something like a blueprint with reusable functional components. However, there are no generally applicable standards for all IoT application categories. In this respect, individual initiative is required.

Focus on the data flow

Many IoT applications were originally developed from a proof of concept (PoC) and were modified until a certain degree of practicality and user benefit was achieved. They are now used in this state and are constantly being developed further due to changing customer requirements. The result of this approach is often relatively poor documentation of the overall context. This not only has a negative impact on the reliability and maintenance of an application, but also on the operational security and competitiveness of the application provider. In this respect, professional IoT developers should create a standard blueprint for their own applications. This allows a learning curve with empirical values and security concepts based on these to be implemented for the individual components and further developed over the entire application life cycle.

Figure 1 on the left shows an example based on the flow of data and information. The entire IoT application is shown as a modular end-to-end solution. At the bottom left is a device endpoint (IoT device), and on the right is the web client of a human user or an IT application. Between these two security-critical points, authenticity, data integrity and contextual confidentiality are required. Here is a brief overview of the reusable individual components:

• IoT Device: Sensors that collect data and actuators that perform actions (close or open valve).
• Device hub: The communication and data node for the connections to the individual sensors and actuators.
• Device logic: Runtime environment with software functions to enable the flow of data between the sensors and actuators as well as higher-level database functions.
• Database: Collective term for the storage functions of an IoT application. Implementation details of the database functions are determined individually.
• Business logic: Runtime environment with software functions to enable the flow of data between external users and applications as well as the database functions of an IoT application.
• Web server: Communication and data technology hub for the connections to external users and other applications.
• Web client: Users and applications that can be assigned to a specific IoT application. They are usually the data consumers, and in many cases also data sources.

A simple practical example

In the right-hand section of Fig. 1, the IoT application modules described above are transferred to an industrial IoT condition monitoring application. A controller (PLC) plus gateway is used as an IoT device to transfer changed PLC status data to an MQTT broker (device hub). When new status data arrives, the broker generates an event. This starts a device logic process. This takes the MQTT data from the broker, converts it into the format required by the application and saves a new data object in the application database (ADB, the database for this example).

The right-side database interface enables external users and IT applications to access the condition monitoring data. Human users can access the respective data via a web browser, while applications can access it via a REST API, for example. In addition to these typical web clients, OPC UA-based data access could also be implemented. Each external web server access generates an event trigger for the business logic of the IoT application to execute certain actions. In practice, this part of the application can be implemented using WSGI (Web Server Gateway Interface), for example. It ensures that a web client request is supplied with appropriately prepared data via ADB access. This data is dynamically integrated into a website for user access. The REST-based request from another application is answered by the WSGI process with a JSON object, for example, which then contains the required data.

Documenting the data flow

Every professional IoT application also includes a data flow diagram (DFD), which shows the external entities, processes, data storage functions, data and information flows and trust boundaries. There are various symbols and notations for creating DFDs. Entities are represented by rectangles, processes by circles and storage functions by two parallel horizontal lines. A label can be found inside each of these symbols. The data flow is indicated by arrows. Dotted lines are used to represent the confidence limits. Figure 2 shows the DFD for the condition monitoring example application described above. It was created according to generally valid DFD rules:

• Each individual process should have at least one input and one output.
• A data storage system must have an incoming and an outgoing data flow. In some use cases, the incoming data path is omitted for reasons of simplification (e.g. a storage system for static web pages; storing the web pages in a database would be a sub-application with its own DFD).
• Data that is stored in a database must pass through at least one process.
• All processes of a DFD have a data flow to another process, data store or entity.
• Data that is stored in a system must always run through a process.
• Only processes change data, whereas a data storage system does not.

The respective communication protocols used for data transfer between entities and processes can also be entered in a DFD. Furthermore, the trust limits should be marked in the DFD in order to ensure the necessary cybersecurity as part of a threat analysis. If the DFD is created at the beginning of an IoT solution development, security by design is possible.

Digital twin as an extension

The author: Klaus-Dieter Walter is a member of the management board at SSV Software.

© SSV Software Systems

A central database with an IoT interface on one side and a web client interface on the other also offers an ideal environment for implementing digital twins. This requires additional data storage options, for example for the design and configuration data of a machine or system. In the next article in the 'Digital Twin' series, the author will look at these aspects.