Toward a Practical Digital Twin Platform Tailored to the Requirements of Industrial Energy Systems

Abstract

Digitalization and concepts such as digital twins (DT) are expected to have huge potential to improve efficiency in industry, in particular, in the energy sector. Although the number and maturity of DT concepts is increasing, there is still no standardized framework available for the implementation of DTs for industrial energy systems (IES). On the one hand, most proposals focus on the conceptual side of components and leave most implementation details unaddressed. Specific implementations, on the other hand, rarely follow recognized reference architectures and standards. Furthermore, most related work on DTs is done in manufacturing, which differs from DTs in energy systems in various aspects, regarding, for example, multiple time-scales, strong nonlinearities and uncertainties. In the present work, we identify the most important requirements for DTs of IES. We propose a DT platform based on the five-dimensional DT modeling concept with a low level of abstraction that is tailored to the identified requirements. We address current technical implementation barriers and provide practical solutions for them. Our work should pave the way to standardized DT platforms and the efficient encapsulation of DT service engineering by domain experts. Thus, DTs could be easy to implement in various IES-related use cases, host any desired models and services, and help get the most out of the individual applications. This ultimately helps bridge the interdisciplinary gap between the latest research on DTs in the domain of computer science and industrial automation and the actual implementation and value creation in the traditional energy sector.

1. Introduction

The mitigation of climate change and environmental damage due to industrial activity are regarded as some of the most pressing issues that society faces today [1]. Consequently, decarbonization and sustainable production are high-priority goals that also have huge implications for the present and the future of energy systems. There are two concurrent transformations with the common goal to make energy systems more efficient: the shift toward integrated energy systems and digitalization. Both of these transitions can mutually benefit from each other [2] since they share essential characteristics, both being highly influenced by technological innovations [3].

The key characteristics of integrated energy systems are that they utilize a high share of energy produced by intermittent renewable sources, high energy-efficient systems, and strong integration of electricity, gas, heating/cooling, mobility systems, and markets to maximize the synergies among new technical solutions [4]. The transition toward integrated energy systems is also eminent within industrial energy systems (IES), where renewable energy sources are gradually replacing fossil sources in an attempt to reduce greenhouse gas emissions. Although this transition is supported by policies [5], implementation and even more so the operation of such systems confronts us with serious challenges. The interconnection between different sectors and stakeholders, diversity of demands and technology, numerous sources of uncertainty and large scales to consider require novel approaches from various disciplines.

The digitalization of IES is driven by the rapid development of information and communication technologies. This paradigm shift is often referred to as the fourth industrial revolution or Industry 4.0 [6]. While there is justified concern that digitalization could increase energy consumption due to subsequent rebound effects and economic growth [7], there is undoubtedly an immense potential for digitalization and Industry 4.0 to reduce energy consumption and increase economic sustainability [8]. To realize this potential, various applications based on novel digital technologies have been proposed such as forecasting, demand response, operational and design optimization, fault prediction and predictive maintenance, to name just a few. However, today, all these digital applications are usually considered individually. By integrating these solutions into a collaborative platform, their impact could be even more significant.

To realize the visions of Industry 4.0 and smart, sustainable integrated energy systems, the digital twin (DT) is considered one of the most promising concepts [9]. DTs are the key enabler for integrating the solutions mentioned in the previous paragraph [10]. DTs in the energy sector can thus fundamentally change the way IES operate, minimize energy consumption and increase the integration of renewable energy sources [11].

However, the concepts and capabilities of DTs are not yet clearly defined and still vigorously debated in contemporary scientific literature. So far, a unified DT platform has not been established but is considered to be direly needed [9]. Furthermore, most work on DTs has focused on the manufacturing domain [12,13], which differs from the domain of energy systems in various aspects.

Tao et al. [9] state that the history of DTs is rather brief and that the concept was first introduced as early as 2003 by Grieves in the context of product lifecycle management [14]. The first actual definition of a DT was given by NASA in 2012 [15]. To date, various definitions have arisen and are still the subject of discussion in the literature [16]. Negri et al. [17] and Liu et al. [18] even presented tables of 16 and 21 separate definitions of the DT, which they found in the literature. The basic characteristics given by NASA [15] are still aligned with the refined definition given by Negri et al. [17] and reported by Cimino et al. [16] and Kritzinger et al. [19]: “The DT consists of a virtual representation of a production system that is able to run on different simulation disciplines that is characterized by the synchronization between the virtual and real system, thanks to sensed data and connected smart devices, mathematical models and real time data elaboration”. Most definitions, such as this one, are tailored to production systems, which hints at the origin of DTs in the manufacturing domain. For a more general understanding, we can break down the definition to the term physical object [20] or physical entity [21]. Josifovska et al. [21] define a physical entity as an abstraction of a “thing” persisting in the real world which has to be mirrored or twinned in the virtual world. In this framing, the definition by Negri et al. [17] is suited for industrial energy systems, where the physical entity of a considered DT can be a single process unit or even part of that unit but also a whole energy system including boundary conditions (e.g., external energy supply systems/grids). Therefore, this is the definition that we adhere to. It is important to note the difference in the level of data integration between mere digital models of a physical entity and a full DT, which was most prominently discussed by Kritzinger et al. [19]. While DTs are using digital models to dynamically simulate the physical entity and thus can build on the same principles, their key feature is bidirectional automated data exchange, i.e., synchronization with the real world. This is where the technical complexity of DT modeling arises. Hence, DT frameworks and practical platforms are needed to allow for the strict synchronization of digital models with their physical entities and to enable additional functionalities compared to a mere model.

Although the number and maturity of DT concepts is increasing, there is still no uniform platform available for the practical implementation of a DT [18]. Most proposals focus on the conceptual side, maintaining a high level of abstraction and leaving important implementation details unaddressed [22]. Concrete DT implementations, on the other hand, are mostly realized with a specific application in mind without any architectural template [21] or only offer a limited set of services [16], hence not reaching the full potential. Thus, there is still a significant gap in DT research regarding how to offer a higher number of services in the same environment to support complex decision making [16]. Missing architectural guidelines result in application-specific solutions which are barely reusable, hence increasing development time and maintenance costs [22].

After its origin in the aerospace industry [15,23], the DT was widely announced following Grieves’ Whitepaper [14] in 2014 [24]. Only then did the DT topic find its way into other sectors, such as automotive, oil and gas [25], and healthcare and medicine [26] and was driven forward massively in (discrete) manufacturing, which is apparent by the distribution of DT applications analyzed in Jones et al. [12], Negri et al. [17], and also Melesse et al. [13]. In recent years, the DT was also explored in the context of chemical process engineering [27] and the food industry [28]. In the domain of energy systems, DTs are notably represented in the domain of electric power systems [29] and especially in the context of smart grids [30] and battery management [31]. Other examples include DTs for decision making in energy system design [32] and, during operation, the application of DTs for wind turbines [33] and for scheduling [34] and state estimation [35], to name just a few. Only recently, the transfer of the DT concept to thermal IES has begun [36,37]. For a complete overview of existing DT research and industrial application, we refer interested readers to the current literature review by Liu et al. [18].

1.1. Scope of This Paper

Even though both industry and academia ascribe huge potential to DTs in IES, their use in this domain is lagging behind other sectors, most notably the manufacturing sector [12], which differs from DT research in energy systems in various aspects. A relatively low number of papers can be found in the literature addressing DTs in the energy domain [38]. In a current literature review by Kaiblinger et al. [39], only 5% of evaluated DT case studies could be attributed to the energy domain, which is inline with the findings of Yu et al. [11] and Sleiti et al. [37]. Regarding application scenarios, DTs are mostly represented in the area of prognostics and health management, while Tao et al. [9] found that the areas of DTs in dispatching optimization and operational control are currently underexplored but very promising.

Based on the past evolution and current difficulties in DT development outlined above, we focused our research on a tangible implementation of a DT platform for IES. In this paper, we

• identify the most important requirements on DT of IES,
• propose a DT platform tailored to these requirements in line with current standardization developments,
• address essential architecture and implementation challenges,
• solve technical implementation barriers by providing practical solutions, and,
• highlight the advantages of service engineering on this DT platform.

Ultimately, our work aims to bridge the gap between the latest research on DTs in the domain of computer science and practical deployment in the energy sector. The proposed DT platform should pave the way to standardized DT implementations with service encapsulation and thus efficient DT service engineering. In this way, DTs will be easy to implement in various cases related to energy systems and be capable of hosting various complex models and services fulfilling different application purposes.

1.2. Paper Structure

After this introduction into the topic, we elaborate on specific features and requirements of energy systems and the need for an appropriate DT platform in Section 2. We also compare the most relevant DT concepts and architectures. We will show that none of the existing implementations is a good match for IES but that the five-dimensional (5D) DT concept is feasible despite its high level of abstraction. In Section 3, we propose concrete solutions to fill in the blanks in the 5D-DT concept and overcome implementation barriers, thus creating a practical DT platform. We highlight the capabilities and benefits and critically discuss the proposed DT platform with regard to the specific requirements of IES as well as emphasizing the potential of service engineering in Section 4.

2. State of the Art

Considering that the typical claim of DT platforms is that they are universal, i.e., that they are not just applicable for the specific system that they were developed for, but that they are transferable to any physical entity, the scarce use of DTs in the energy domain compared to the manufacturing domain appears unjustified. This disparity cannot be explained by the DT’s historical evolution alone. There must also be a number of distinct differences that distinguish manufacturing and energy systems. We thus argue that the unique requirements of energy systems have to be considered for the successful development of a DT platform.

2.1. Characteristics of Industrial Energy Systems

As a typical use case for a DT platform in this domain, we consider an exemplary industrial energy system, as illustrated in Figure 1. It is composed of a conventional combined heat and power unit, electrically powered heating units and internal renewables based on photovoltaics for electric and thermal energy supply. A number of production processes typically account for electric and thermal energy demand. Heat exchanger networks and heat pumps are used for waste heat recovery. Electrical and thermal energy storage components are employed to provide additional flexibility and improve the energy efficiency enhancement of the IES. Furthermore, the IES is not isolated but instead coupled with both the electricity grid and a district heating/cooling network.

Such an IES is a complex integrated energy system that has a number of characteristics that set it apart from typical manufacturing systems:

• Many sources of uncertainty such as weather influences, prices on the energy market and stochastic processes within the system itself make the optimal operation of an IES challenging.
• Energy system units feature complex thermophysical behaviors, hence leading to strong nonlinearities in mathematical model descriptions.
• Energy systems are often vast and distributed systems with specialized equipment.
• Power plants as well as industrial and urban energy systems have very long lifetimes or are even continuously refurbished instead of being rebuilt. Thus, “off the shelf” solutions have a limited field of applications.
• Energy systems are very dynamic systems with a broad range of operational time scales.
• Some process quantities cannot be measured directly, e.g., due to high temperatures or abrasive conditions.
• System properties change over time, e.g., the efficiency of a unit can change due to wear, while the mechanical resistance of a system can degrade due to fatigue.
• Energy systems consist of continuous processes as opposed to processes with discrete units in manufacturing; hence, scalar and vector fields instead of single values are used to describe the system.
• Given their critical nature within the power grid infrastructure, cyber attacks targeting IES have potential for disastrous consequences.

All of these aspects more or less differentiate from manufacturing systems and can be considered specific features of IES, thus contributing to the fact that DTs are underdeveloped in the energy sector. We deduce that these characteristics explain why DT frameworks that have been applied successfully in the manufacturing domain have not been extensively transferred to the energy domain yet. One way or another, if DTs are to be widely deployed in the energy sector, these specific properties must be properly considered.

2.2. Digitalization Developments and Opportunities in Industrial Energy Systems

Technical developments such as Internet of Things (IoT) technologies and the growing data acquisition in energy systems have resulted in new challenges and opportunities for energy systems [40]. Digital innovations have the potential to trigger significant changes in the energy sector in the near future [41]. For example, the increasing maturity of machine learning approaches enables applications to improve the accuracy of demand, generation, and price forecasting [40]. Various other solutions have been proposed, such as intelligent energy management [42], demand response [43], operational optimization [44] and design optimization [45], fault prediction [46] as well as preventive and predictive maintenance for energy efficiency [47] and to extend the lifespan of machinery [48]. In the area of battery management, IoT and data science technologies enable numerous solutions to optimize battery manufacturing, operation and re-utilization [49].

Existing DT concepts and implementations in the energy sector aim to provide at least one specific solution. In a recent study by Wang et al. [50], targeting energy neighborhood applications emphasized the use of DT in energy storage use cases, which are equally important in IES. The estimation of stage of charge and aging state of storage devices as well as the cloud-based interconnection of multiple units to enhance computational abilities and overall operation management were highlighted. A recent summary of the modest amount of DT development in the area of power generation was given by Sleiti et al. [37], including electricity generation, power distribution, the renewable and nuclear power industry, and the energy vehicle and storage sector. They concluded that while the energy industry is actively pursuing the tremendous opportunities of DT, most articles did not include details on the comprehensiveness of their DTs or details on the used models and enabling technologies. Furthermore, the scope of implementations is mostly very limited to specific applications scenarios.

Weigel et al. [41] provided a structured overview of digital applications in the German energy sector, and Ardebili et al. [51] listed the most frequent application scenarios for DTs in smart energy systems based on a systematic literature review. Furthermore, Yu et al. [11] recently derived a structured list of DT applications in the process and energy industry from the literature. Grouped into three lifecycle phases, these included [11]: virtual testing [52] and design optimization [53] in the Desing phase, process optimization [54], prediction [55], monitoring [56] and training [57] as well as production control [58] in the processing phase and fault detection and diagnosis [59] in the service phase. Based on these studies, we deduced a list of application categories which we consider most relevant for industrial energy systems from a technical perspective (see

Table 1. Most relevant technical categories of digital applications considered for value creation during operation of industrial energy systems. For an in-depth review, we refer to [11,41,51].

ID	Application
A1	Condition monitoring
A2	Anomaly/deviation detection
A3	Fault classification and analysis
A4	Predictive maintenance
A5	Forecasting
A6	Operational optimization

).

The condition monitoring (A1) of physical components by analyzing measurement data is crucial to guarantee the optimal and safe operation of energy systems [33]. Furthermore, condition monitoring via models and “soft sensors” can facilitate this process, especially in harsh environments and for quantities that cannot be directly measured. On top of monitoring, anomaly or deviation detection (A2) aims to detect deviations between the expected and observed behavior of physical components, which is often via the use of simulation models. The application of fault classification (A3) is typically designated to identify the type and cause of detected anomalies or errors and sometimes also to predict future fault scenarios. Predictive maintenance (A4) aims to predict and extend the remaining useful lifetime of machinery to determine an optimal maintenance schedule. Forecasting (A5) of energy demand, prices and environmental conditions becomes increasingly relevant and also more feasible by using historical and external data and advanced analytic methods. The operational optimization (A6) and control of IES generally aims to decide on optimal operating points and scheduling in order to minimize energy consumption or overall costs. We consider the leveraging and marketing of demand flexibility also within this category, although it is sometimes known as demand-side management, since it is generally based on very similar methods and merely considers different operational variables, constraints and external information sources.

Weigel et al. [41] derived the benefits of such digital applications from the literature, which were allocated into six clusters: (1) system stability, (2) environmental protection, (3) energy demand reduction, (4) revenue increase, (5) cost reduction and (6) customer expectations. These benefits are based on the potential of individual applications, i.e., to automate and improve efficiency in processes and optimize the operation and maintenance of systems but also on digitalization’s potential to create interacting networks, increase transparency and improve convenience [41]. While some of these categories clearly show some correlation with each other, cost reduction is inherently covered in all of them. Yu et al. [11] evaluated the main driving benefits for DT adoption in the energy sector from the literature as energy efficiency, profit, decarbonization, throughput, quality and safety.

To enable individual digital applications and thus leverage the benefits ascribed to them, various methodical approaches were already successfully developed. However, although many of these solutions have been deployed in all energy value stream steps, the value stream itself has remained mostly unchanged [60]. A major problem today is that all these solutions are usually considered individually. By integrating them into a collaborative platform, their impact could be much more significant, and future development and software maintenance effort could be reduced. The DT is considered as such a platform that can host a large number of services in a single environment [16]. These services can either provide specific application purposes on their own [61] or can be loosely coupled with other small software services to build service-oriented applications [22]. This microservice architectural style gains increasing popularity in software development due to its improved scalability and maintainability [62].

The most common services and features of DTs in general have been reviewed by a number of researchers. Tao et al. [61] listed nine main services of DTs in the production sector, while Cimino et al. [16] grouped these in six categories; however, these are specifically tailored to manufacturing systems. Ardebili et al. [51] list the most frequent goals and applications for DTs in the energy sector, and Steindl et al. [63] identified six groups of functional services: simulation services, monitoring services, diagnosis services, prediction services, control services, and reconfiguration services.

2.3. Barriers Impeding Digital Twin Implementation

The distinct features of IES, which we outlined in Section 2.1, present challenges for the implementation of DTs in these systems in addition to general technical barriers. The fact that DTs are relatively scarcely addressed in the literature relating to the energy domain both gives evidence to such challenges and reinforces the underdevelopment of DTs for IES. In that regard, we see the energy domain at a similar stage as the process industry, where similar difficulties led to the fact that little research on DTs has been conducted [64]. This fact is supported by the review from Yu et al. [11], where only 50 papers were retrieved for process or energy DT within a thousand research papers on DTs in general since 2010. Perno et al. [65] recently presented a systematic review of barriers for DT implementation in the process industry. Such barriers are equally present in the energy domain. A summary of the most crucial barriers impeding DT development from a technical perspective is given in

Table 2. Most crucial technical barriers impeding DT implementation. We endorse and apply the categories established by Perno et al. [65] for the process industry and provide a summary of topics causing difficulty in the energy domain.

ID	Barrier Category	Challenges
B1	System integration issues	Lack of system integration; Interoperability issues; Legacy systems
B2	Security issues	Data protection; Real-time communication; Robustness
B3	Performance issues	Prediction accuracy; Data volume; Scalability; Flexibility; Standardization
B4	Organizational issues	Fragmented data management; Data availability; Technology investment decisions
B5	Data quality issues	Data validity; Lack of methodologies and tools; Low DT maturity
B6	Environmental issues	Software decisions; High-fidelity modelling; Multi-disciplinarity; Heterogeneity

.

System integration issues (B1) include interoperability issues and often problems with legacy systems. Fuller et al. [66] stated that such DT challenges fall into the area of IoT and IIoT. DT implementations should thus not only feature a standardized architecture but also a certain flexibility to retrofit existing infrastructure. This is especially critical for IES that feature very long lifetimes.

Security issues (B2) are a barrier that is not necessarily crucial during DT development but during DT deployment. The key enabling technologies for DT must follow the current practices and updates in security and privacy regulations to resolve this barrier [66].

Performance issues (B3) cannot be solved alone by large computational capacities but include aspects of standardization and scalability. Standardization will facilitate the interoperability of new and existing supporting software [37]. Only when standardization is achieved can DT really thrive in the energy sector due to the easy exchange of information and models.

Data quality issues (B5) include the lack of methodologies, low data validity or low DT maturity that results, e.g., in information resulting from DT models that are untrustworthy or incomprehensible. This is crucial in IES, where many sources of uncertainty complicate operation.

Organizational issues (B4) and environmental issues (B6) feature multidisciplinary problems that also needs to be tackled from the area of business management, impeding the fast development of DTs.

Yu et al. [11] stated that DT development in the energy sector is inherently multidisciplinary, including fields such as chemical, mechanical, electrical, civil, software engineering and data science. Additionally, DT operation should ideally be unclosed to non-technical staff and business managers. Thus, further non-technical challenges arise that have to be countervailed by a convenient DT architecture.

For more details on barriers and possible enablers in current DT research, we refer to the reviews of Perno et al. [64,65], Yu et al. [11] and Fuller et al. [66].

2.4. Requirements on Digital Twins in the Energy Sector

Since most DT implementations are realized following a specific goal without any architectural template [21], it is impossible to overcome the implementation barriers given in Section 2.3 in a standardized manner. However, a DT that is tailored to the specific characteristics of IES (i.e., one that meets their requirements) could be an enabler to integrate digital applications on a single platform and thus make IES significantly more efficient. While having mainly different scopes of applications in mind than the energy sector, some researchers directed their research on establishing common focus points in DT development and servization. Furthermore, they listed requirements they deemed as necessary DT capabilities. These requirements are summarized in the following paragraph and critically reviewed to provide a foundation for our assessment in regard to IES.

Boje et al. [67] highlighted requirements on DTs in the construction sector. Demands for smart factory systems were established in Ref. [68]. Moyne et al. [69] studied DT definitions in manufacturing and clustered them into requirements (1) derived from the literature, (2) derived from DTs in use today, and (3) applications in the near future. Weskamp et al. [70] formulated requirements for the architecture of a knowledge exploration platform of industrial data for integration into digital services. Steindl et al. specified functional and non-functional requirements for a DT service framework derived in a literature review [22] and clustered these requirements based on three RAMI 4.0 layers (information, functional and business). Negri et al. [71] collected requirements for ontological modeling in industrial applications. Tao et al. [72] proposed eight rules for DT modeling, which are, in their original short denomination, (1) data and knowledge based, (2) modularization, (3) light weight, (4) hierarchy, (5) standardization, (6) servitization, (7) openness and scalability, and (8) robustness. Neto et al. [73] summarized and identified four features of digital twins based on the literature, including digital modeling, analytical support, timeliness update and control. Sleiti et al. [37] stated seven requirements for their DT architecture for power plants.

Based on this literature about DT requirements and considering the specific characteristics of IES and technical barriers impeding the DT development outlined in this subsection, we established a set of key requirements for DTs in the energy domain. These requirements are listed in

Table 3. Requirements of DT platfoms for application in IES. The requirements are specified together with an identifier for later reference and with literature sources that provided motivation for them.

ID	Requirement	Source
R1	The DT must be able to observe the physical world in real time via the use of sensors.	[61,67]
R2	The DT must be able to monitor, inform and issue warnings on relevant physical alterations.	[37,67]
R3	The DT must be able to actuate physical components.	[67]
R4	The DT should be designed in a modular fashion.	[61,69,72]
R5	The DT must be able to make decisions and trigger actions on the virtual entity.	[67]
R6	The DT should be open, re-usable, and scalable.	[61,69]
R7	The DT must be able to optimize operation of the physical entity.	[61,67]
R8	The DT must provide interfaces for seamless user interaction.	[70,74]
R9	The DT must be robust and able to provide automatic model adaptation, i.e., for simulating the physical entity.	[69,72]
R10	The DT must be able to predict the behavior of the physical entity based on simulations and sensing.	[61,67,69]
R11	The DT should be able to accommodate simulation models for various applications and in arbitrary fidelity.	[61,67]
R12	The DT should build on standardized technologies and use available metadata, hence facilitating model integration, information exchange and maintenance.	[70,72]
R13	The DT must be able to process heterogeneous data from different sources.	[37,61]
R14	The DT should be able to store data with context information and exchange information in a semantically meaningful way.	[61,69,70]
R15	The DT must allow for safe and secure operation of the physical entity.	[75]

together with references that provided motivation for them.

Requirements R1 and R3 express the need for bidirectional automated information exchange between physical and virtual entities, which is considered the most distinctive feature of a DT [19]. Especially for highly dynamic systems, the DT must be capable of informing and warning human operators (R2).

Both requirements R5 and R7 address the issue that the DT must not only provide recommendations for action but to trigger these actions, hence optimizing the operation of IES.

Since IES and their corresponding DTs should be in operation for very long time-spans, IES are continuously evolving; i.e., components are added and environment variables change. Therefore, DTs should be modular (R4), scalable (R6) and build on standardized technologies (R12), thus facilitating the maintenance and continuous development of the DT platform.

Especially in IES, parameters of physical units can change significantly, e.g., due to degradation in harsh conditions. Hence, the DT must be robust in that it can automatically adapt to behavioral changes (R9). This reinforces also requirement R10, which is a typical DT requirement also in other domains.

The need for the accommodation of various types of simulation models (R11) is particularly important in IES, where models of both varying fidelity and different physical considerations are applied, e.g., heat transfer, fluid dynamics, mechanical stress and chemical kinetics.

The need for heterogeneous data processing (R13) is crucial in IES, since specific tasks may require data from multiple simulation models, different legacy measurement devices and also input data streams with respect to the surrounding integrated energy system.

Dynamic processes in IES can be very complex, and operation experience is still indispensable. Hence, storing data with context information and exchanging information in a semantically meaningful way (R14) makes a DT a much more powerful tool.

Last but not least, both plant safety procedures and cyber-security concerns should be addressed (R15) in a way that the DT must not impede the safe operation of the physical entity and, ideally, increase the overall security of the energy system.

Even though this list could be extended even further, it should cover the most relevant requirements and provide a solid foundation for evaluating a proper DT platform in the energy domain. Other researchers argued that a DT must deliver quantifiable metrics and ultimately add value in its application area [69]. However, while we share this opinion for DTs in general, we see this not as a necessary consideration for the technical implementation of a DT platform. In addition, lifecycle aspects are often raised. While we do not assign a high value to this topic with regard to IES, we argue that basic requirements for the lifecycle aspect in DTs are already covered by various functional requirements in our list (e.g., R6). For more detailed necessities, e.g., on information technology (IT) infrastructure, service- and model management, we refer to the particular literature presented above, i.e., the work of Weskamp et al. [70], Steindl et al. [22] and Negri et al. [71].

2.5. Digital Twin Architectures

A number of research articles have addressed DT concepts, architectures and platforms in varying levels of abstraction in recent years. Cimino et al. [16] and Semerano et al. [76] broach the issue of DT architectures as part of their respective review papers. However, we could only ascribe four references [51,63,77,78] to the energy domain. While it is considered an urgent necessity to define standardized DT frameworks, no consensus has been reached [9] yet. This is even more critical for DTs in the energy domain.

In this subsection, concepts and architectures for DTs and related work for cyber-physical systems (CPS) are reviewed and then discussed with regard to their viability for DTs of IES.

2.5.1. Existing Digital Twin Concepts, Architectures and Platforms

The first DT concept was published by Grieves [14] in 2014, defining the three basic aspects of (i) the physical space, (ii) the virtual space and (iii) the connection between them to exchange data and information. These three main dimensions are found in most other concepts and architectures. Concurrently, they are often organized into physical (i), computing (ii) and network layers (iii) [67,76]. Grieves’ three-dimensional approach is very minimalistic, and consequently, many extensions have been proposed in recent years to reflect the growing complexity of DT concepts.

Tao et al. [79] argued that Grieves’ three dimensions do not indicate the extent to which services and features can be provided, and also, the extent to which information can be retrieved and data can be processed is not explicitly presented. These shortcomings in combination with the rapid development of enabling technologies, omnipresent availability of data, and the need for services led Tao et al. [24,80] to propose a 5D-DT concept, adding (iv) DT data and (v) DT services to the three dimensions proposed by Grieves [14]. In the 5D-DT concept, especially the service dimension is emphasized as an important part. The functionality of the DT is encapsulated into standardized services with user-friendly interfaces for easy and on-demand usage.

Stark et al. [81] propose a “DT 8-dimension model” to provide a template for planning DTs; however, they admit that further research is needed toward a reference model for the implementation of a DT.

Wang et al. [31] presented DT models and a four-layer networked architecture of cloud-side-end collaboration for battery management systems. This architecture contains four layers from the perspective of hardware functionality, namely “edge computing layer”, “data access layer”, “data storage and analysis layer” and “data-based application layer”.

Sleiti et al. [37] proposed a five-component DT architecture for robust power plant operation, consisting of (1) a physics-based dynamic system model, (2) an anomaly detection model, (3) a sensor database, (4) a digital thread model and (5) localized in-depth simulations. While this architecture is specific regarding purpose and possible modeling techniques for physical components, the authors circumvent the important topics of data storage and processing and connections within the DT. Furthermore, no standardization aspects are considered to ensure the scalability and openness of the architecture.

In [21], a “Reference Framework for Digital Twins” is presented that specifies the structure and interrelations of the main DT building blocks, which were identified based on a literature review. Interestingly, the blocks are almost identical to the dimension in the 5D-DT concept by Tao et al. [72,80] except for the notable absence of an equivalent to the connection dimension.

The concept for a “Cognitive Twin Toolbox” was presented in [82] with a special focus on the process industry. The toolbox is organized into the five layers, which again have some similarity to the 5D-DT [72]. The “Data Ingestion and Preparation Layer” and the “Service Management Layer” are of a similar design as the data and service dimension in the 5D-DT. The “Model Management Layer” serves a similar function as the virtual entity. Additionally, the toolbox also has a “Twin Management Layer”, to handle synchronization of the DT structure, and a “User Interaction Layer”. Just like the “Reference Framework for Digital Twins”, the “Cognitive Twin Toolbox” has no explicit connection layer.

The three main building parts of a DT presented by Grieves [14] align with the definition of CPS, which is a concept that is very prominent in the industrial production domain. Various papers in the manufacturing field mention the use of the DT to simulate a CPS [17]. Therefore, some researchers see a DT as merely the digital model inside a CPS [10], and this conversely implies that a DT is the prerequisite for a CPS [12]. Zheng et al. [83] state that the DT in the broad sense belongs to the CPS but has a higher fidelity and focuses more on data and models with ultra-high-fidelity simulations. Either way, DTs and CPSs are undoubtedly very similar, and thus, CPS architectures are also highly relevant for DT implementations.

The prominent five-layer architecture (5C architecture) for CPSs proposed by Lee et al. [84] consists of the five pyramid-like layers “Smart Connection Level”, “Data-to-Information Conversion Level”, “Cyber Level”, “Cognition Level”, and “Configuration Level”, in order from bottom to top, bearing similarity with the 5D-DT architecture by Tao et al. [72,80]. The 5C architecture aims to guide the development and deployment of CPSs in manufacturing even though it cannot be considered to be a mature DT platform.

In Ref. [85], an “Intelligent Digital Twin” architecture for implementation in CPSs was proposed. In the “Cyber Layer”, a synchronization interface is introduced besides a data acquisition interface to keep simulation models of the DT consistent with the physical entity. Furthermore, a co-simulation interface is described as a component of the architecture to facilitate interaction between simulation models and to enable communication with other DTs. While focus of this architecture lies on automated synchronization and inseparability, the dimension of services seems underdeveloped, since the “DT” is only regarded as a virtual replication of physical functionalities in that article.

2.5.2. Standardization Aspects

We see that the available reference architectures for DTs and related concepts such as CPSs use either structured elements (e.g., building blocks, components, dimensions) or some kind of layers (also interfaces) to structure functionality and reduce complexity for DT implementation. These basic DT parts often have the same function even though they have different names, which impedes direct comparison. In an attempt to bring order to this topic, several standardization efforts have been made.

The Asset Administration Shell (AAS) was introduced in the context of the Industry 4.0 initiative as a standardized digital representation of an asset [86,87]. The AAS is used to uniquely identify assets, describe their functionality over the whole lifecycle and enable the communication among assets within a single factory and between companies. The AAS is still being developed, and the integration of models into the AAS is due to be added soon [88]. However, it is not in the scope of the AAS to provide simulations [20], hence missing basic requirements for a DT. For this reason, the AAS can rather be seen as the first step to a standardized DT solution providing the basic DT functionalities of resource description, discovery and access.

The ongoing standardization initiatives by the International Organization for Standardization (ISO) under the code ISO 23247 and title “Automation systems and integration—Digital twin framework for manufacturing” are also noteworthy as are the DT implementations that are built on these [89] as well as other standards relating to the scope of DTs, such as ISO 22989 and ISO 10303. However, both the transferability of such standards to the energy sector and ultimately the acceptance of the norms are not foreseeable yet.

In an attempt to establish a common view and terminology, the Reference Architecture Model Industry 4.0 (RAMI 4.0) was introduced in the context of Industry 4.0 [90]. RAMI 4.0 is a guidance framework for implementing Industry 4.0 aspects and developing a common understanding of standards, tasks and use cases. Thus, RAMI 4.0 provides a very useful system for localizing the parts of a DT.

To connect RAMI 4.0 with DT concepts, the Generic Digital Twin Architecture (GDTA) was proposed by Steindl et al. [63]. In it, the 5D-DT concept [72] was used as a basic conceptual model and aligned with the six interoperability layers of RAMI 4.0 (Business, Functional, Information, Communication, Integration and Asset Level [63]) in an attempt to achieve a consistent naming and understanding of the layers. The GDTA targets the “instance-phase” of the RAMI 4.0 lifecycle, i.e., the operational phase as opposed to the “type” or engineering phase. A DT can be located at various hierarchy levels within RAMI 4.0, depending on the physical entity for which it is designed for, potentially covering all levels [63]. Defined data models within the AAS can be semantically lifted to a knowledge representation based on Resource Description Framework (RDF) [91], enabling the representation of the AAS inside the shared knowledge base of a GDTA-based DT.

2.5.3. Summary and Discussion

In

Table 4. Overview of concepts, architectures and frameworks for DTs. Adapted and extended from Steindl et al. [63].

Name	Target Domain	Structure	Main Parts	Level of Abstraction
3D-DT [14]	Lifecycle management	component-based	3 components	high
5D-DT [72]	Manufacturing	component-based	5 components	high
5C Architecture [84]	CPSs in manufacturing	layer-based	5 layers	high
Intelligent DT [85]	Production systems	component-based	4 interfaces and 9 components	low
Ref. Framework for DT [21]	CPSs in general	component-based	4 main components	low
“4S” architecture [31]	Battery management	layer-based	4 layers	low
COGNITWIN [82]	Process industry	components and layers	5 layers and 19 components	low
Conceptual DT model [92]	CPS in general	layer-based	6 layers	medium
ASS [86,87]	Manufacturing	only meta-model	ongoing work	-
The Twinning process [12]	DT characterization	only synchronization model	sequential processes	high
Data-driven reference architecture for DT [93]	Various industries	layer-based	6 layers and several components	high
Digital Twin 8-dimension model [81]	Smart manufacturing	component based	8 components	high
Application framework of DT [83]	Lifecycle management	modules and layers	3 components and 1 layer	high
The Interactive Digital Twin [32]	Decision making in energy system design	only design model	sequential processes	low
GDTA [63]	Industrial Energy Systems	components, layers and services	6 layers	medium
Robust DT for power plants [37]	Power plants	component-based	5 components	medium

, a summary of the concepts, architectures and frameworks presented in the preceding paragraphs is given. The table was adapted and extended from our previous work [63]. It also gives a classification of the architectures based on their level of abstraction ranging from “high” (more general concept) to “low” (concrete framework, targeting implementation details).

While abstract DT concepts are very useful for the initial development of the DT platform for a particular use case, they mostly do not indicate how to implement a DT. The propositions at a low level of abstraction that we found in our literature search either do not meet energy system specific requirements or lack the perspective of standardization.

Aligning solutions with the architectural guidelines of the GDTA outlined above facilitates technology-independent implementations of DTs, thus ensuring reusability ultimately reducing development expenses. However, services are still considered in an abstract way in the GDTA, and appropriate implementation technologies have to be chosen. The prominent 5D-DT concept is being simple to understand in theory while keeping implementation details vague.

We conclude that a more tangible DT platform, addressing the requirements for the domain of IES, can significantly facilitate DT implementation. Therefore, we propose a DT platform in Section 3 based on the previous work on the 5D-DT concept [80] and the GDTA [63]. The 5D-DT concept allows to conceptualize a specific DT based on five main dimensions, which are found in the majority of existing literature concepts. The GDTA, being also based on the 5D-DT concept, aims structuring its essential components and functionality and helps to classify, combine, and re-use already existing frameworks and technologies based on its alignment with RAMI 4.0.

3. The Digital Twin Platform

Taking the 5D-DT concept as a fundamental pattern, we developed a DT platform that is tailored to the specific requirements of IES (see Section 2).

The architecture of the developed DT platform is presented in Figure 2. The connection dimension is at the center of our platform, which highlights its function as the central communication hub. All parts of the DT can communicate via a message broker. The physical entity (left-most box in Figure 2) is connected to the virtual space via the supervisory control and data acquisition (SCADA) system. New data points are sent to the message broker, and control signals are received. The virtual entity (right-most box in Figure 2) is connected via the model management layer. Via this model management layer, models are made available to the other parts of the DT. Each model is associated with an identifier and models can be added, updated and fetched. The data dimension (box at the bottom center of Figure 2) provides a uniform interface and semantic structuring to the various data sources in the DT. Queries are received from the message broker, processed, and the result is returned via the broker to the requesting client. In the service dimension (top center in Figure 2), each service can connect directly to the message broker. Services can send requests for models to the virtual entity and send data queries to the data dimension. The coordination of the various services and the realization of complex sequences is realized by the service orchestrator.

In the following subsections, we address the particular implementation issues of each dimension of the DT and propose universal, yet concrete, approaches for resolving these issues. As a use case, we consider a generic IES comprised of typical components, as illustrated in Figure 1.

3.1. 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.

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 Naik [95] and Profanter 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. Human 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, light-weight 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 Mosquitto (https://mosquitto.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, 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.

Each client publishing to the broker has to follow an MQTT topic naming convention depending on the type of message. This ensures that published messages have a defined payload allowing subscribed clients to process received messages accordingly. However, the DT platform does require a request/response message pattern, which is not supported by MQTT out of the box, as it follows the publish/subscribe pattern. Therefore, considerations on how to implement such a request/response message mechanism had to be made, which include two implementation possibilities: (1) one MQTT topic for request and response messages or (2) one MQTT topic for a request message and one MQTT topic for the correlated response message. The first approach requires to define the type of message within the payload alongside a unique identifier to correlate messages. Alternatively, the unique identifier could be appended to the MQTT topic for reducing the payload, but this would require parsing the MQTT topic for retrieving the identifier. Thus, we opted for the second approach, which defines the type of the message by the MQTT topic; hence, only the unique identifier has to be appended to the payload. An application would then need to parse the topic for getting the type of message and the identifier for message correlation. This approach allows exchanging messages while still enabling the use of arbitrary payloads.

3.2. Physical Entity

The key for realizing a DT is to enable a tight integration of physical and virtual space. To that end, a lot of information has to be exchanged with the physical entity. Data have to be recorded by sensors, and control signals have to be fed back to the actuators in the energy system. However, most DT applications do not mention the connection of the DT environment to the control system [16]. Hence, this critical implementation barrier needs to be dissolved.

In a typical DT deployment scenario for IES, it can be assumed that there is already a pre-existing system for at least basic interfacing of the physical entity in place. Various measurement values are typically connected via a programmable logic controller (PLC) to a state-of-the-art SCADA system. Our DT platform builds upon on such SCADA systems; hence, we locate them inside the physical entity dimension (see Figure 2). Such SCADA systems (or merely PLCs) can then be interfaced to the DT via standard industrial IoT protocols. In case of our DT platform, this is MQTT.

This tight integration would also allow realizing certain control tasks in the DT. The advantage is obvious: on the DT, the controller has access to more detailed models and more computation power. However, other factors that need to be taken into account are hard real-time and dependability requirements, which cannot be guaranteed for communication via the used network transmission protocols. For this reason, high-speed control tasks and plant safety measures should not be executed within the DT, but they always run on the PLC directly.

For our DT implementation, XAMControl (https://en.evon-automation.com/, accessed on 10 June 2022 ) was used as the SCADA platform, which allows to define, visualize, program and configure PLCs. In order to integrate this system into the proposed architecture, a prototype version of the server software enables publishing and receiving messages to and from the MQTT broker. These messages can then be processed by any interested application by subscribing to the relevant MQTT topic.

3.3. Virtual Entity

One of the key features of a DT is that its virtual entity represents the state of the physical entity at all times. This requires that models or the model parameters are adapted to changes in the physical entity. An adaption of the models in the virtual entity will, for example, be required when degradation changes the process performance, when parts have been replaced or refurbished in a maintenance intervention, or when new components were installed for modernization of the IES. The job of the DT is to keep track of these changes and manage the different versions of each model/parameter set.

In our platform, this requirement is fulfilled by the model management in the virtual entity. It essentially runs a database of all available model instances and stores information on each model in a local knowledge graph. Information includes (amongst other factors) the URI (Uniform Resource Identifier), scope, inputs, outputs, validity ranges, accuracy and time of validity. The model management runs an MQTT endpoint over which models can be queried and afterwards processed. The models can thus be provided for specific services.

Our DT platform allows for model integration developed in different environments. Thus, also different types of models, for example, physical, data-driven or hybrid models, with varying fidelity, can be applied for designated tasks within the DT. For details on modeling enabling technologies for DTs, see, for example [98].

Accessing the metadata of model instances and storing them within an ontology requires standardized interfaces. Functional Mock-up Interfaces (FMIs) (https://fmi-standard.org/, accessed on 10 June 2022) are an established standard to create relevant model instances and their input and output parameters (connections). This allows storing a model instance as a single file via corresponding Functional Mock-up Units (FMUs). By including a metadata file, which contains descriptions of the connection types, these two files provides all necessary information to describe the virtual entity.

Figure 4 illustrates how services can access virtual entity models within the DT platform. The platform contains a model management service written in Python (https://www.python.org/, accessed on 10 June 2022), which processes these files and provides access to the FMU model via the File Transfer Protocol (FTP). In order to select a specific model, any service connected to the MQTT broker is able to query all provided models of the model management service via an MQTT request and subsequently can access them via FTP. The reason for using FTP in contrast to provide the FMU file via MQTT lies within the nature of MQTT, which is not designed for exchanging binary files, hence the choice of using the much more suitable File Transfer Protocol.

3.4. Data Dimension

Generally, the data dimension holds information about five data categories according to Tao et al. [72,80] and as illustrated in Figure 2. In addition to sensor data from the physical entity (${\mathrm{D}}_{\mathrm{p}}$), model and simulation data from the virtual entity (${\mathrm{D}}_{\mathrm{v}}$), and data from the Service dimension (${\mathrm{D}}_{\mathrm{s}}$), it contains semantic data about the system and all the relationships within the DT, i.e., domain knowledge (${\mathrm{D}}_{\mathrm{k}}$), and fused data (${\mathrm{D}}_{\mathrm{f}}$) of ${\mathrm{D}}_{\mathrm{p}}$, ${\mathrm{D}}_{\mathrm{v}}$, ${\mathrm{D}}_{\mathrm{s}}$ and ${\mathrm{D}}_{\mathrm{k}}$.

However, the data dimension must not only store these data but also provide semantics to it. Therefore, in our DT platform, we use a so-called knowledge graph, which is a knowledge-based system, consisting of an ontology and a built-in reasoner that is capable of acquiring and integrating external information sources [99]. This knowledge graph consists of several ontologies that hold information about plant equipment, topology, instrumentation, etc. The runtime data from the IES, which is usually stored in relational databases, is integrated into the knowledge graph via ontology-based data access (OBDA). By defining mappings between the relational database structure and the ontologies, the implicit knowledge about the data models is made explicit. Thus, the knowledge graph acts as a semantic abstraction layer [100] where data can stay in the original local database, e.g., within an SQL database of the SCADA system. Data are only loaded when accessed, which also enhances performance [101]. For more detailed information about the data access, we refer to our previous work in references [22,63].

As a crucial methodical foundation, domain-specific ontologies have to be applied for IES. However, knowledge engineers do not need to build ontologies from scratch, but they can use and integrate existing standards that were developed in collaborative efforts among industry and academia and be conveniently created via open source tools (e.g., [102]). For our DT platform for IES, relevant ontologies include PETIont (Plant, Equipment, Topology and Instrumentation Ontology) [103], Sensor, Observation, Sample, and Actuator (SOSA) ontology [104], PQOnt (Electrical Power Quality Ontology) [105], OntoPowSys (Power System Ontology) [106], OpenEnergy [107], OntoCAPE (Ontology for Computer-aided Process Engineering) [108], and OntoEIP (Ontology for Eco-Industrial Park) [109]. Furthermore, for including information on services and virtual entity models in the knowledge graph, existing semantic web ontologies such as OWL-S (Web Ontology Language for Service) [110] and OWL-Time (Web Ontology Language of Temporal Concepts) [111], extended with Quality of Service (QoS), are considered as foundation. Domain ontologies, e.g., FMUont (Functional Mock-up Ontology) [112] and ML-Schema [113] for simulation services, are built on top, inheriting all classes and properties of the base service ontology [63]. The creation of a single generic ontology for IES is beyond the scope of this contribution. However, it has already been successfully demonstrated, e.g., by Ocker et al. [114], that the highly reusable terminological components of such ontologies can be (semi-)automatically merged to fit the requirements of specific applications.

For the practical use of the ontology, hence instancing the concepts of it and creating the relations between them, a triplestore provides the means to store the ontology similar to a database. A semantic triple consists of three entities, namely subject, predicate and object, and represents a relation between them. This way, knowledge can be structured in a machine-readable and standardized way. For the implementation, the RDF framework RDF4J (https://rdf4j.org/, accessed on 10 June 2022) is used, which supports a variety of established ontology file formats and provides a SPARQL endpoint to access data. For ontology-based data access, Ontop (https://github.com/ontop/ontop, accessed on 10 June 2022) enables connecting a SQL database into the knowledge graph, which means that data remain in the data source without being moved. A wrapper service, which translates MQTT requests to SPARQL queries (database connector in Figure 2), enables the integration into the DT platform. Listing 1 shows how to formulate a SPARQL query to receive the values from a sensor (FBR-TE-1A1) between two timestamps. Such a query can be automatically submitted, e.g., from the deviation detection service mentioned in Figure 3.

For connecting other databases to the DT platform, one requirement is that it supports MQTT, which is, for instance, fulfilled by InfluxDB (https://www.influxdata.com/, accessed on 10 June 2022).

Listing 1. Exemplary SPARQL query, requesting measurement values from a sensor (FBR-TE-1A1) between two timestamps from the DT’s knowledge graph.

3.5. Service Dimension

The service dimension in our DT platform is realized according to the microservice framework by Steindl et al. [22], which is aligned with the GDTA and the RAMI 4.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 Steindl 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, 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. For this, the containerization framework Docker (https://www.docker.com/, accessed on 10 June 2022) allows running services in so-called containers, which include all necessary libraries the services require. Therefore, no additional software besides Docker has to be installed on the host machine. However, as the DT platform already covers multiple services, it would be cumbersome to start every single container with the correct parameterization manually. In order to automate this process, Docker Compose (https://docs.docker.com/compose/, accessed on 10 June 2022) enables defining a single file in which multiple containers and their configuration are specified. This allows starting the DT platform based on a single file.

4. Discussion

In the following, we discuss and evaluate our proposed DT platform by aligning it with the requirements identified in Section 2, addressing the benefits of the platform and discussing the potential of service engineering.

4.1. 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. Alignment of the identified requirements (see Table 3) supported by implementation aspects of the proposed DT platform. The requirements are listed along with their given IDs, an abbreviation of their description in Table 3, and structured via localization within the five dimensions (5D-DT) of the DT platform for IES.

ID	Requirement Abbreviation)	5D-DT	DT Platform for IES
R1	Real-time observation	Physical entity	SCADA/PLC system
R2	Reaction on physical alterations	Service dimension	Various orchestrated services + HMI
R3	Physical entity actuation	Physical entity	SCADA/PLC system
R4	Modularity	Connection dimension	Microservice architecture + message broker integration
R5	Decision capability	Service dimension	Service orchestration
R6	Scalability	Service dimension	Microservice architecture + containerization
R7	Optimization capability	Service dimension	Optimization services
R8	User interaction	Service dimension	HMI + workflow engine
R9	Robust modelling	Virtual entity	Model management
R10	Prediction capability	Virtual entity	Simulation and Prediction services
R11	Model versatility	Virtual entity	Model management + Service encapsulation
R12	Standardized foundation	Data dimension	Alignment with RAMI 4.0 based on existing ontologies
R13	Heterogeneous data processing	Data dimension	Federated knowledge graph
R14	Semantic interoperability	Data dimension	Federated knowledge graph + message broker
R15	Secure operation	Physical entity	SCADA/PLC system

, 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.

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.

Our implementation of the data dimension (see Section 3.4) with a federated knowledge graph facilitates heterogeneous data processing (R13) and provides semantic interoperability (R14). It holds information about plant equipment, topology, instrumentation, etc. in a machine-readable and standardized format and integrates runtime data via OBDA. The implementation with the RDF framework provides means to semantically access data via SPARQL endpoints. A wrapper service, which translates MQTT requests to SPARQL queries, enables information exchange within the DT. Standardization technologies and metadata (R12) are applied throughout our DT platform, e.g., by the use of established protocols such as MQTT and standards such as FMI for virtual model description. However, these requirements are especially crucial in the data dimension. Therein, domain-specific standardized ontologies are a crucial methodical foundation, fulfilling this requirement. Existing IES ontologies, as introduced in Section 3.4, can be (semi-)automatically merged to fit the demands of specific DT services, exploiting their highly reusable terminological components. AAS or ISO frameworks, as introduced in Section 2.5.2, can be conveniently incorporated in the data dimension of the platform to ensure conformance in case these are established as recognized standards. The knowledge graph in the data dimension of the DT platform provides a single access point to acquire and integrate external information sources, e.g., metadata, further aiding the scalability of the DT (R6). Furthermore, the whole DT platform builds on the GDTA [63] and RAMI 4.0, hence aiding the re-use of existing frameworks and technologies.

Security requirements (R15) are only inherently covered in our DT platform. We argue that cyber-security mechanisms should be contained in the applied fundamental technologies and further investigated in the pertinent literature. As outlined in Section 3.2, plant safety measures and critical high-performance control loops should be implemented on the PLC/SCADA system. However, specialized services could be integrated to automatically reconfigure and compile these control mechanisms on the PLC if, for example, the plant topology changes.

Even if the message broker is designed to be the only means of communication between the parts of the DT, there might be situations where direct communication is a more suitable option. For example, if a specific service within the DT needs to access a large data set in one of the relational databases, MQTT’s maximum message size might be a limiting factor. In such a case, the service could request information about the location of the data set from the knowledge graph and then send a query directly to the database endpoint. The access to FMU files within the virtual entity via FTP or SFTP, as presented in Section 3.3, is another example.

Furthermore, service management is currently completed by hand and still has to be established if a DT should feature automated service deployment. Therefore, several (micro)services, e.g., for service discovery and access, still have to be implemented.

4.2. Digital Twin Platform Benefits

Our contribution aims to overcome the technical implementation barriers relevant for energy systems summarized in Table 2 and to enable different value-creating applications (see Table 1) in the same platform. Via the simple exemplary workflow for a deviation detection application, given in Figure 5, and considering typical use cases, it is possible to assess the attributes of our platform that aim to maximize the benefits of individual applications.

We have to stress here that the final benefits such as energy demand reduction, revenue increase and cost reduction that are expected from DT (see Section 2.2) are only provided via the respective applications integrated as services. However, we consider the detailed discussion of individual services to be out of scope of this contribution and refer to specialized literature instead. Nonetheless, via this evaluation, the platform’s qualitative benefits are clearly evident.

Instead of having one monolithic application that takes care of all aspects of fault detection starting from the data cleansing, deviation detection, and fault classification to decision making and also scheduling maintenance actions, the process can be split into microservices that are coordinated by the service orchestrator in the DT platform. For the deviation detection workflow itself, nothing changes, but it enables it to integrate it more tightly with other DT services. For example, if a deviation is detected by the deviation detection service (see Figure 5), a message can trigger a workflow for fault classification in order to check if the deviation is caused by a fault or due to a normal drift in the system’s behavior. In case of the latter, this information can then be used to trigger a model adaption workflow. For a more in-depth discussion of a semantic microservice framework, we refer to Steindl et al. [22], where automatic sensor data evaluation serves as a proof of concept.

To react to new data points within the IES, a dedicated topic for each sensor value is set up on the message broker. Any service that needs to react to new data points subscribes to the respective topics. Whenever a new data point is available, the SCADA system publishes a message on the corresponding topic, and the message broker will deliver the new data points to all services that require this data point. Through the publish/subscribe function of the message broker, neither the SCADA system nor the services need to have any information about each other aside from the name of the topic where data points are transferred.

The ability of the DT to adapt to changes of the plant is enabled by the separation of models and the services that use these models. If a continuous drift in the system’s behavior was detected via fault classification, models within the virtual entity can be automatically replaced or updated, e.g., via data-driven modeling and validation services, to fit the altered behavior. When a simulation service starts, it fetches the newest validated model instance from the virtual entity.

Figure 6 illustrates how the presented DT platform leverages the integration of digital applications to offer associated benefits. In addition to the easy integration, operation and maintainability of applications, another important aspect is that synergies between these individual solutions can be conveniently exploited. Naturally, applications such as condition monitoring and deviation detection can provide basic unidirectional information for subsequent fault classification and analysis. However, also, back-feeding information between applications can provide additional benefits. For example, a schedule derived from operational optimization can be used for estimations within predictive maintenance applications. Conversely, the latter can determine operational constraints for operational optimization services. This is not possible without sufficient information management. The architectural design of our platform, i.e., the division into the five DT dimensions with the message broker as the central communication hub and a microservice framework for managing inter-service workflows, facilitates interconnection between different applications and the access of distributed data sources. As presented in Section 2.2, these digital applications integrated in a DT platform provide benefits such as system stability, environmental protection, energy demand reduction, revenue increase or cost reduction.

4.3. The Potential of Service Engineering

While the energy industry strives to implement DTs as soon as possible to leverage its potential benefits, one of the biggest current obstacles remains to be that in-depth knowledge from various domains is required. Within the energy sector, most technical contributors have a background in electrical, chemical, mechanical, thermal or operations engineering, due to the fact that IES to date have been very complex systems requiring profound expertise in these fields to manage and develop. Industry 4.0, and with it concepts such as the DT, set a paradigm shift in motion, introducing more and more novel technology from information and communications technology to this sector. While energy domain experts struggle to understand modern IoT methods and what the implications for their work are, computer scientists typically do not fully comprehend the intricacies of IES and the challenges of operating them. The DT platform provides a common understanding of operational DTs, and it also defines clear interfaces to separate the work of the engineers and the computer scientists. In this way, everyone can focus on their strengths while still working efficiently on the big picture: the DT.

The engineering of complex IES-related models and services will still rely on expertise and profound experience with the respective assets in the years to come. However, these services can be encapsulated in standardized form in the DT platform. Deployment is facilitated by providing an appropriate IT infrastructure, making information from both physical and virtual entities easily accessible. Thus, on one hand, IES experts who develop new services and models have clear interfaces within the DT platform. Therefore, they can concentrate on application-related domain problems instead of deployment and connection within the DT.

On the other hand, computer scientists can focus on the infrastructure to provide an open, scalable, reliable, and secure DT platform solution by converging the operation technology and IT world. In this context, interoperability is key for integrating third-party systems and providing openness to enable new business opportunities. Therefore, interoperability must be established on a technical, syntactical, semantical, and operational level.

We presume that on the technical side, interdisciplinary work in DT development between computer scientists and energy system experts will have some distinct focus points. We see such a major overlap in the area of knowledge representation, i.e., the development of ontologies or knowledge graphs for IES. Methodologies such as METHONTOLOGY [117] structure and guide the work to build ontologies, but they also rely on the knowledge of domain experts.

5. Conclusions

In this paper, we identified special requirements on digital twins (DT) in industrial energy systems (IES) that set IES apart from other domains, where DTs are already established. On this foundation, we developed a DT platform that is tailored to the requirements of IES. Our DT platform is based on the five-dimensional DT (5D-DT) concept and provides solutions to various implementation issues that are not addressed in the 5D-DT concept. It also complies with the Generic Digital Twin Architecture (GDTA), hence facilitating alignment with existing technology and standardization.

The DT platform should prove a practical tool for interdisciplinary teams that aim to implement a DT for IES. The platform is designed to provide clear interfaces that allow domain experts to develop their services without in-depth knowledge about IT implementation aspects. Through the efficient service encapsulation of the proposed DT platform, energy domain experts can focus their work on engineering services, virtual entity models and ultimately the optimal operation of IES. At the same time, computer scientists can leverage their expertise on the scalability, reliability and security of the DT platform and on establishing interoperability on a technical, syntactical, semantical, and operational level.

The main benefit of the DT platform for the operation of IES will be that individual digitalization solutions such as predictive maintenance, deviation detection, fault classification, and operational optimization, which are typically developed and deployed as standalone solutions today, can be more tightly integrated, and synergies can be exploited. The DT platform provides the basis for the standardized implementation of complex digital applications that make the operation of IES more efficient and thus get us one step closer to the paradigm of integrated, decarbonized energy systems with sustainable production.