# Toward a Practical Digital Twin Platform Tailored to the Requirements of Industrial Energy Systems
## 3 The Digital Twin Platform
### Connection Dimension  
The main task of the connection dimension is to enable the communication between all parts of the DT. The goal of our DT platform is to provide powerful yet versatile standards, which can be used easily, while allowing the implementation of more efficient alternatives for applications with special requirements. Implementing various communication channels between the parts of the DT would result in an unnecessarily complicated architecture. Instead, the main communication channel should be designed so that it is interoperable with all parts of the DT. Figure 2: Illustration of the DT platform for an IES inspired by the five-dimensional 5D-DT concept and the GOTA. There are numerous choices for appropriate communication technology, such as Message Queuing Telemetry Transport (MQTT), Advanced Message Queuing Protocol (AMQP), Constrained Application Protocol (CoAP), Hyper Text Transport Protocol (HTTP) or Open Platform Communications Unified Architecture (OPC UA) [94], to name just a few. The choice is often application-specific and depends on reliability, speed and resource constraints, amongst other things. For a review on messaging technologies for IoT systems, see, for example, the work of [PERSON] [95] and [PERSON] et al. [96]. To enable event-driven asynchronous communication between all dimensions, a publish-subscribe message queue in form of a message broker is the most viable solution [97]. We thus chose MQTT as the default communication protocol of our DT platform. [PERSON] et al. [94] demonstrated the effective use of MQTT for DTs of complex systems. It is appropriate because of its versatile topic-based publish/subscribe functionality, lightweight messages and low bandwidth requirements, which allows 1:n as well as n:1 communication [22]. It is well established in IoT [96] and can be utilized by clients based on the Internet Protocol Suite TCP/IP; hence, it is also compatible with heterogeneous hardware components of the physical entity. Furthermore, it features three levels of Quality of Service (QoS) for reliable message delivery and an adequacy for large networks [94]. Each of the other four dimensions of the DT is connected to the MQTT message broker in the connection dimension as a client and can publish and subscribe to different topics. These topics are defined and managed by the MQTT message broker. The broker is responsible for receiving all messages, filtering the messages, determining who subscribed to which topic, and sending the messages to those subscribed clients. On an even more abstract level, all parts of the DT can be considered some kind of service, and the whole DT can be modeled in analogy to a microservice framework (see, e.g., [22]). By applying a message broker in this way, the connection dimension turns into a central communication hub, as it is shown in Figure 2.  
With regard to the practical implementation of the DT platform, we propose Eclipse Mosquito ([[https://mosquito.org/](https://mosquito.org/)]([https://mosquito.org/](https://mosquito.org/)), accessed on 10 June 2022) as an MQTT message broker. The lightweight architecture allows for deploying on different devices and does support various authentication and encryption protocols, such as username/password authentication, and certificate-based encryption. Depending on the application which aims to connect to the broker, various MQTT client libraries are available that support the used MQTT version 3.1.1 (OASIS Standard. Available online: [[http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html](http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html)]([http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html](http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html)), accessed on 10 June 2022). Figure 3 illustrates an exemplary request-response message pattern in our DT platform and the message topics involved. The function of the service orchestrator is explained in detail in Section 3.5.