# Toward a Practical Digital Twin Platform Tailored to the Requirements of Industrial Energy Systems
## 4 Discussion
### Alignment with the Requirements on Industrial Energy Systems  
We developed the DT platform with a special focus on IES that has some unique features, resulting in specialized requirements, as emphasized in Section 2. In Table 5, we summarize how these requirements are met by our DT platform. Some important requirements for DTs of IES are fulfilled via adequate use of the physical entity in our platform, such as R1 and R3, which are achieved by the efficient use of typical infrastructure such as SCADA/PLC systems and interconnection with the DT via a reliable message broker. Real-time observation (R1) is realized via PLCs connected to the SCADA system, which itself can publish values via the message broker. Actuation of the physical components (R3) can also be triggered by services within the DT via the message broker. Figure 5: BPMN representation of an exemplary workflow for the application deviation detection. Services communicate via their corresponding MQTT request and response topics, as illustrated in Figure 3. The simulation service can query and fetch virtual entity models via information from the data dimension (see Figure 4). The connection within the DT is a crucial part of the whole platform. Using a message broker with event-based messaging supports the fulfillment of several requirements (R4, R5, R6, R7, R8, and R14). The microservice architectural style of the platform supports the modularity (R4), scalability and maintainability (R6). Models can be defined via FMI and all services are containerized, facilitating maintainability and transferability. Complex processes can be realized via multiple interlinked DT services assembled to workflows. Defining, maintaining and adapting workflows within the DT is conveniently achieved via BPMN. This was highlighted in Section 3.5 via an exemplary workflow within the DT platform. The DT is able to optimize operation of the physical entity (R7) via specific target applications (see also Table 1) that can be conveniently incorporated in the DT platform via workflows and by the use of specialized (micro)services. Optimized operation schedules are executed on the physical entity via control services. User interaction (R8) is primarily localized within the service dimension, but different interfacing possibilities are feasible. For the sole observation of physical entity state variables, existing interfaces within legacy SCADA systems and also the use of such systems in a greenfield approach are encouraged. Observation of the DT and access to it is conveniently realized via the BPMN workflow engine as a service orchestrator. An HMI is already covered in typical software packages, such as for example Zeebe, in our implementation. Additional specific HMIs, e.g., for virtual entity services, could be realized accordingly. The DT is thus able to monitor, inform and issue warnings on relevant physical alterations (R2). Decision frameworks can be integrated via workflows and trigger corresponding actions on the virtual entity (R5) via the message broker. Our virtual entity implementation accounts for robust and adaptive modeling (R9), extensive simulation and prediction capabilities (R10) and model versatility (R11). These properties are enabled by providing standardized interfaces and model management as presented in Section 3.3 and Figure 4 as well as the possibility to host models developed in different environments and varying fidelity.