In contrast to the demanding processes in production technology with a large number of participants and long supply chains, end-to-end digitalization began decades ago in the somewhat more simply structured field of communication technology. Driven by the continuous progress in semiconductor technology and embedded software development as well as the proximity to the IT world, there is a very high degree of digitalization overall. The idea of the digital twin can also be found in countless communication applications via the software functions for application proxy servers, data agents and middleware solutions. As a result, there are a number of generally recognized standards for protocols and data interfaces in the Internet of Things, for example, which production technology will probably have to wait a little longer for. Two simple IoT practical examples of the use of digital twins:

Example 1: The data proxy

Figure 1: There are now numerous alternatives for IoT wireless connections that enable almost worldwide wireless coverage as a network. However, there are considerable differences in terms of data throughput per time unit. In order to implement uniform user and data interfaces in a larger application, digital twins can be used as "data substitutes". With such a function module, Low Earth Orbit (LEO) satellites can also be used for extraterrestrial IoT data connections for machine maintenance.

© SSV

IoT applications generally consist of four superimposed layers:

• 1. IoT device,
• 2. connectivity,
• 3. middleware and
• 4. the actual application software.

A fifth functional layer, IoT security, is added as a cross-sectional technology for the four layers. Middleware plays a special role in this layer model: it connects different, often complex and already existing software modules that were not originally designed to be used together.

In the last part of this IoT Hotspot article series, entitled "The digital twin in practical use", an industrial IoT application example was presented in which various wireless wide area network (WWAN) connections with completely different wireless interfaces and data throughputs are used. Regardless of the WWAN bandwidth and the associated latency times and data volumes per time unit, users should be able to access current machine data images at any time via standardized interfaces - web browser, VNC client, remote desktop. Possible alternative wireless connections between an IoT machine modem and a cloud service include LTE, NB-IoT or IoT LEO satellites (LEO = Low Earth Orbit) to enable a machine manufacturer to use an IoT retrofit solution worldwide. Radio connections to mobile base stations are technically relatively simple and therefore widespread. The situation is somewhat different with IoT satellite communication. Here, application developers still need to do some pioneering work to solve some particular challenges.

LEO satellites orbit the earth at an altitude of a few 100 km. This results in orbital periods of between 90 and 100 minutes. With such a satellite orbit, a permanent radio link between the IoT communication module in a machine on site and a specific satellite is not possible. LEO satellite operators therefore use larger satellite swarms to cover as much of the earth's surface as possible and reduce the interval times of the radio link per location. A communication module (IoT device) in the machine must therefore constantly try to establish an (IoT) satellite (data) connection in order to find a communication time window. Alternatively, the daily time periods for possible (IoT) satellite (radio) connections per location can of course also be calculated and stored in the IoT device firmware. Some LEO satellite providers provide special tools for this (see Swarm Pass Checker in Figure 1).

With an LTE connection between the machine and the cloud service, there is usually enough bandwidth available to allow a service employee to access a website or the VNC remote desktop of a machine controller directly. However, if the connection between the IoT machine modem and a cloud service is based on a LEO satellite link, this is not possible. In this case, a corresponding proxy website or a proxy remote desktop is implemented in the digital twin and equipped with the latest data received from the machine. A human data user therefore sees the familiar website or VNC remote desktop display. However, the associated server process runs in the digital twin, i.e. within the cloud service platform and not in the machine control system on site. The user should be informed via a data quality indicator about the type and method of remote access in individual cases, i.e. either directly to the servers in the machine control system or alternatively to deputy instances in the cloud.

In order to ensure sufficient data quality despite the sporadic LEO satellite data transfer, the digital twin can be equipped with a time series database and a machine learning-based algorithm for time series data analysis and trend prediction. With this extension, the different interval times of a measurement data transmission via LTE or LEO satellite connection can be largely compensated for.

Example 2: The security deputy

A problem similar to the data twin arises when an end-to-end security solution based on X.509 certificates is required for the previously mentioned WWAN alternatives (LTE, NB-IoT, LEO satellite). Although the TLS /DTLS protocol used here can be used with an IP-based LTE connection without any problems, the first hurdles usually arise with NB-IoT use due to the additional data volume and the monthly costs of the data plan. Since LEO satellite communication predominantly does not even use IP as a network protocol, but instead uses special protocols adapted to the technical limitations, the use of TLS/DTLS is not possible here. A uniformly high X.509 certificate-based cyber security level can therefore not be realized within an application with such different WWAN technologies. In order to provide the data users mentioned in the first example with uniform TLS-based end-to-end security for remote web browser and VNC remote desktop access to machine data, the digital twin and not the machine serves as the endpoint for mutual authentication with X.509 certificates in the case of an LEO satellite connection. Figure 2 illustrates the relationships.

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

© SSV Software

With mutual authentication, both communication partners each have their own X.509 certificate with the corresponding private key (server key and client key). In addition, at least one CA certificate (X.509 CA) exists on both sides in order to be able to check other certificates. The entire two-way authentication process takes place in five steps. It begins with a "Client Hello", which is answered by a "Server Hello". At the same time, the server sends its X.509 certificate and requests the client certificate. The client checks the digital signature of the server certificate using the X.509 CA. If this check is positive, the client responds with its certificate. If the check is negative, the client terminates the connection. Finally, the client certificate is checked on the server side. The user data transfer phase only takes place if the check result is also positive, otherwise the connection is terminated. In the case of an LTE connection, mutual authentication can be carried out directly between the data user's computer system and the IoT machine modem as a server on site - the optimum security solution. When using an LEO satellite link, however, the digital twin forms the server endpoint. Data authenticity and integrity are therefore relatively insecure. This situation can be improved by using a message authentication code (e.g. an HMAC procedure) for the satellite link to the digital twin.