# Toward a Practical Digital Twin Platform Tailored to the Requirements of Industrial Energy Systems
## 3 The Digital Twin Platform
### Service Dimension  
The service dimension in our DT platform is realized according to the microservice framework by [PERSON] et al. [22], which is aligned with the GDTA and the RAMI4.0 IT layers. A key advantage of this framework is that small services can be realized and developed independently. To compose and deploy services, choreography or orchestration can be used [22]. Compared to the sometimes advantageous decentralized choreography approach, our platform builds on service orchestration, leading to an integrated service logic and a potentially less laborious development [115]. To realize and manage complex processes and computations, multiple services can be linked in workflows. Workflows can be defined in a graphical language, such as BPMN (Business Process Model and Notation) and executed via a workflow engine, which is located in the Service Orchestration (see Figure 2). For the inter-service communication, again, the central MQTT message broker is used. Once deployed, the services can be containerized for the sake of reliability. Each service holds its relevant data in its own local database or triplestore and can add relevant information to the shared knowledge graph in the data dimension via a federated SPARQL query engine. For details, we refer to the work of [PERSON] et al. [22] and the corresponding source code [116]. The services within our service dimension are grouped in accordance with the GDTA [63]. We consider different forms of control, prediction, diagnostic, monitoring and simulation services to be implemented in our platform as well as potential non-categorized services relevant for DTs of IES. Services that require models can fetch the up-to-date model instances from the virtual entity via the MQTT message broker. Additionally, we consider the human-machine interface (HMI) as an important service in this dimension, since humans have to be informed about the current state of the physical entity as well as the DT itself to interact with it. This is possible via the platform's workflow engine. Different HMIs for the sole purpose of physical entity monitoring located in the SCADA system are also viable. As indicated by Figure 3, the DT platform uses a BPMN workflow engine as a service orchestrator, namely Zeebe ([[https://github.com/camunda-cloud/zeebe](https://github.com/camunda-cloud/zeebe)]([https://github.com/camunda-cloud/zeebe](https://github.com/camunda-cloud/zeebe)), accessed on 10 June 2022). It allows loading BPMN files and enriching them with metadata necessary for the connection to MQTT. In particular, these enriched BPMN files cover MQTT request and response topics. Figure 5 illustrates a simple exemplary workflow, which incorporates application category A2, respectively, deviation detection, of Section 2.2. This workflow is either triggered by a timer, i.e., in a predefined interval, or manually by the request of a user or another service. The activities in this workflow (\"Simulation (virtual entity)\" and \"Deviation detection\") describe the services which the workflow engine will call on their corresponding MQTT request topic, as seen in Figure 3. In case of the \"Deviation detected\" activity, this send activity will trigger another workflow, which handles the classification of the deviation for further processing, e.g., to detect possible faults. The intermediate message events (\"Simulation results received\" and \"Deviation detection results\") indicate that the workflow has to wait at these events until the services successfully complete their processing and return a result on the respective MQTT response topic. Other application categories can be modeled and integrated in a similar way. The proposed architecture of the service dimension aims to be very flexible, which includes allowing the deployment on various machines.