Advances and Prospects in Distributed Generation Sources Digital Twins Design

Abstract

Power electronics devices are highly dynamic and nonlinear systems governed by complex control algorithms. In addition, power electronics converters must demonstrate high reliability and must be safe to operate, although in some applications they condition dangerously high power levels. Therefore, the development, evaluation and deployment of these systems traditionally had to be meticulously conducted, using specialized tools and approaches. With the proliferation of power electronics devices into the domain of power systems, in form of distributed generation sources, the mentioned tools and approaches had to evolve further. Consequently, a wide range of representations of the addressed systems within various digital platforms is nowadays at disposal of researchers and engineers. These representations, designated as digital twins, facilitate, and sometimes simply make possible, expeditious development and comprehensive evaluation of increasingly complex power electronics-based systems. This chapter catalogues the most important digital twin types, explicates their advantages and disadvantages and addresses their applicability. Hence, it could be regarded as a set of guidelines on how to choose appropriate digital twin type and digital twinning platform for some particular research and engineering problem. Also, details on how digital twins of distributed generation sources will be created and utilized in near future are provided.

1. Introduction

The power electronics (PE) devices consist of semiconductor switches, some of which are controllable (transistors, thyristors, etc.), while some are uncontrollable (diodes). Since semiconductor switches themselves are nonlinear elements (voltage–current dependency of the switches is nonlinear), the resulting power converter is also a highly nonlinear device. Additionally, several important PE topologies consist of many semiconductor switches. Consequently, addressing the hardware of PE devices can be a difficult task.

On the other hand, since controllable semiconductor switches necessitate control algorithms to govern their operation, and with a goal to secure different types of efficient electric energy conditioning, i.e., conversion—from AC to DC, from DC to AC, etc., the PE converters require complex software structures to be implemented on dedicated microcontrollers. Moreover, as for other automated systems, here also all subsystems in a closed feedback loop must operate properly or device destruction can take place.

On system level, PE devices must demonstrate high levels of reliability since they are integral part in many critical systems (e.g. systems for electric energy production, electric vehicles) or because they are embedded in mass-produced devices (e.g. consumer electronics). They are also not easy to repair, and their failure leads to prolonged non-operation periods. Furthermore, strict safety standards must be satisfied before product commercialization, so that the safety of humans is not jeopardized even during catastrophic failures. Similarly, the operation of PE devices must not compromise the proper operation of other devices in their vicinity. This is especially difficult if a converter is used in high-power applications. Also, electromagnetic-interferences standards must be followed, which adds an additional layer of complexity to the PE design process.

Finally, the PE product development life cycle is affected by market dynamics and even PE devices must be designed and produced at an ever-increasing pace. In this context, seemingly the most meaningful trajectory from idea to an operational device is to synthesize a sketch of a device (hardware and software aspects) and immediately build a prototype. Every young engineer has tried this approach and has failed.

For these reasons, conceptualization, design, implementation, integration, and system verification of these multidomain devices must be conducted both systematically and rapidly [1]. While others depend mostly on the skill and experience of the developers and cannot be easily changed and improved, the system verification depends heavily on which tools are used and consequently can be done in a more or less optimized fashion.

The system verification should not be done on a prototype at the beginning of the product development process, as indicated previously, but rather at its end. Before that, verification of certain subsystems and features has to be conducted within safe and flexible environments. This is true for PE devices in general, but it is especially so for PE systems that are part of distributed generation sources (DGSs). In these systems, mistakes made during development processes are exceptionally expensive, time-consuming, and dangerous for equipment operators.

PE solutions’ verification tools are numerous, but most of them are used to build a digital representation of the addressed system within a certain type of digital computer. Such representations are called either digital twins or simulation models, since they are built with simulation software. This migration of PE devices into the digital domain and usage of digital twins, although being an additional step, actually accelerate the development process. That is because conducting tests within software environments is completely safe, enables test automation, accelerates design errors identification and correction, allows for certain parts of the design or the whole design to be shared more easily among the researchers and engineers (facilitates cooperation), gives freedom to developers to risk more and try novel solutions, not worrying about making mistakes, etc. Hence, digital twinning has been an integral part of the development process of practically all PE device types, excluding only the simplest ones. Moreover, digital twinning has been in use essentially ever since the rise of personal computers (PCs). Accordingly, there are many types of tools for digital twinning that have been developed over the years, each solving a specific set of design problems.

The following three sections give details on the three most important approaches for digital twin’s generation and usage. The advantages and disadvantages of these approaches are given and when it is meaningful to use certain digital twinning tool is described. The digital twinning tools based on personal computers (offline simulation tools) are addressed in the second section. Those based on dedicated digital platforms (real-time simulation tools) are analyzed in the third section, while those considered emerging approaches are considered in the fourth section. The last section brings concluding remarks.

The following two statements should be noted. DGSs will be of particular interest in the remainder of the text because of their complexity and wide social, economic, and ecological importance. Still, most of the concepts and approaches provided in the text can be applied during the digital twinning processes of other power electronics devices. Also, models are never verbatim digital representations of physical systems, and some phenomena are always neglected or abstracted, but it is up to a developer to define how detailed the models will be.

2. Offline simulation platforms for DGSs digital twinning

Ever since the inception of PE as a major electrical engineering field, it became obvious that it would be rather arduous to develop PE devices and examine their behavior analytically, particularly their transient behavior. The first platform that enabled accelerated development, especially the validation stage, was personal computers (PCs). Many simulation tools that could be used to build digital representations of DGSs and PE devices, in general, were developed during the eighties, quickly after personal computers became widely available. The fact that many of these tools are still in use today is a testimonial of their usefulness and efficacy.

Initially, to build a digital twin and use it as an investigative tool using the offline simulations approach, the researchers and engineers needed only a PC and a single software tool (simulation tool or engine). Nowadays, offline simulations can be conducted in a slightly more complicated way, but the PC, i.e., general-purpose device, is still the main platform.

Depending on what part of DGS is of particular interest and which operational domain of the device should be put under scrutiny, four main types of offline simulations can be used today:

• Model in the loop (MIL);

• Software in the loop (SIL);

• Processor in the loop (PIL);

• Controller model in the loop (CMIL).

Several simulation software can be used in either of these approaches, but the tool itself must be optimized and additionally set up, i.e., cannot be used interchangeably out of the box.

The noun before “in the loop” in the approaches’ names generally (excluding MIL) designates which part of the system is modeled in more detail or which part of the system is a real device, i.e., device under test (DUT).

2.1 Model in the loop

A digital twin of the addressed system always consists of digital representations of hardware (power stage) and software (control scheme) subsystems, correspondingly with real PE device. The power stage, or more precisely sensors’ representations, provides the control scheme with the information about controlled variables, and the control scheme generates control signals for semiconductor and other active devices in the power stage. In the case of MIL, both power stage and control structures, governing the power stage, are implemented within the simulation tool using the blocks and elements that are native to the simulation tool. Hence, the digital twin consists only of the simulation model and the model is in the loop (is analyzed). The MIL approach corresponds to a traditional offline simulation. This environment consists of a PC with the installed simulation software, as indicated in Figure 1.

Figure 1.

Offline simulation approach—Model in the loop.

Since the power stage can be comprised of different PE devices, machines, power systems’ parts, and electrochemical elements, the simulation tool must either have rich library elements or enable the user to develop his own parts using available blocks. Either way, a graphical user interface is used in modern simulation tools. This graphical representation is then compiled and run within the same software environment. The difference between the execution time, i.e., how much time is necessary for compilation and running of the model, and simulation time depends on model complexity and the PC performances. Since DGSs are complex, the execution time is significantly longer than simulation time (at least one order of magnitude). Once the execution is done, the developer can inspect the model’s behavior and introduce changes if necessary.

Different simulation tools that enable the MIL approach focus on different aspects of DGSs. It is true that different software packages can be used to focus on more than one aspect of the DGSs, but they are usually optimized for one or maybe two layers of abstractions pertinent to DGSs. If semiconductor driver circuits, parasitic phenomena, and generally detailed simulation of solely PE devices (not the whole DGS) are necessary, the user can use several free (LTspice [2], Xyce [3]), and licensed (PSIM [4], PSpice [5], etc.) software tools. Alternatively, if the behavior of the complete DGS should be analyzed, the user again can choose between free (Typhoon HIL’s VHIL [6]) and licensed (MATLAB/Simulink [7], PSIM, PLECS [8]) packages. Lastly, if the DGSs are to be integrated with the large power systems and jointly analyzed, users can employ several mature tools (PowerFactory [9], PSCAD [10], EMTP [11], etc.).

MIL approach was the first to be utilized to create DGSs digital twins and that pertinent simulation tools and have been in use for decades. From this stems the main advantage of MIL. MIL simulators have rich libraries, many readily available examples and developed user’s communities. Consequently, it is both easy to start using these tools and to start new projects. Also, there are many plugins and add-ons that expand the software functionalities, albeit these additional features are not always free. Furthermore, MIL software is reliable. In addition, MIL in principle allows arbitrarily complex and detailed models to be implemented, at the price of slow model execution.

On the other hand, the MIL assumes utilization of PC—a general-purpose device that certainly is not optimized for running simulations software. In case when DGSs are analyzed, this results in long, sometimes impractical, execution times, especially if DGSs are integrated with a certain power system. Moreover, the MIL approach in many aspects gives crude information on how the real system is going to behave. If semiconductor phenomena are included in the model, for example, it becomes impractical to analyze wide power system dynamics. Alternatively, if large systems are analyzed, transient phenomena in PE devices are not captured properly. The most problematic aspect of MIL usage in this context is the estimation of how DGS control software will behave once deployed on the real device, i.e., microcontroller.

Consequently, the MIL approach is usually employed as the first stage in the DGS design verification process or when a singular feature is to be tested.

2.2 Software in the loop

SIL approach is quite similar to the MIL approach. It is also based on a PC, and it consists of one software package, usually the same as in the case of MIL. The power stage can be the same in both cases. The same information is exchanged between the power stage and control scheme. Hence, it brings similar features, advantages, and disadvantages. Still, it has one crucial difference. As Figure 2 suggests, the software is not implemented using the same elements that are used for building the hardware part of the digital twin.

Figure 2.

Offline simulation approach—Software in the loop.

The software is realized utilizing certain embedded language (usually C or C++)—the same language that will be used to program the real microcontroller. Hence, SIL, besides providing a functional test of the control algorithm, enables the developer to gain insight into how the code is structured and organized, that is, it includes semantic and syntactic checkups. Nowadays, embedded code compilers that must be invoked implicitly during model execution are available for most popular simulation packages [12].

2.3 Processor in the loop

To investigate further control code features and behavior, the code developed in the simulation tool is not placed in the PC’s memory, but it is downloaded to a real controller that shall be used in the final design. This approach is called “processor in the loop” (PIL) since the processor of the real controller is used. The embedded code compilers are again called during model execution. There has to be a communication line established between the controller and offline simulator (PC), so that relevant information between the power stage and control structures is exchanged, as in the previous two cases. The power stage developed in the simulator is again the same, and the model is executed usually significantly slower than in real time, because of the simulated power stage complexity. This implies that the control code execution on the microcontroller has to be slowed down (otherwise it could be run in real time) so that it is synchronized with the model execution.

In addition to advantages and disadvantages inherited from the SIL approach, the PIL approach allows control card memory and processor-time utilization to be examined. It should be noted that not all control card hardware peripherals are utilized and tested—most notably, pulse width modulation peripheral and analog-to-digital conversion unit are not put under test. Additionally, PIL has a bottleneck in the number of DGSs that can be modeled simultaneously. Since one communication channel can be formed between the offline simulator and the controller board, the real controller can drive only one DGS. Also, the toolboxes necessary to utilize PIL are not available for many controllers, but only for flagship models (Figure 3) [13].

Figure 3.

Offline simulation approach—Processor in the loop.

2.4 Controller model in the loop

Controlled code execution and controller board’s resources utilization can be studied in even more detail. For that, comprehensive behavioral models of microcontrollers can be developed. Although the idea is not new, only recently several microcontrollers’ vendors have developed these models and made them available for usage on PC [14]. It should be emphasized that the controller model is usually executed on software different from simulation software, and these two software packages must communicate and exchange relevant information between the power stage (simulation tool) and control scheme (software dedicated to the simulation of the controller behavioral model). Hence, the controller model in the loop approach assumes usage of only PC (without any external hardware), as MIL and SIL (Figure 4).

Figure 4.

Offline simulation approach—Controller model in the loop.

The feature of the controller model in the loop approach is that developers can see exactly how the controller and implemented control code are going to behave once deployed on the real controller—how the memory is going to be utilized, will there be computational overload, how the latency will affect the system operation, etc. Also, the code embedded in the simulated controller model can be immediately deployed on the real controller, without any changes.

This main novelty of this approach, in the context of DGSs, is its main drawback. CMIL puts focus on the controller and control code implementation. Moreover, as for PIL, the setup is essentially limited to one controller and one DGS.

3. Real-time simulation platforms for DGSs digital twinning

The proliferation of renewable energy sources and DGSs into the traditional power systems during the beginning of the twentieth century brought new development challenges. This amalgamation of the two fairly different domains of electrical engineering challenged the existing development and validation tools. PE devices and DGSs necessitate small simulation time steps (high simulation resolution) to capture properly dynamic phenomena associated with these systems. The power systems are by themselves large and complex and developers used offline simulation tools that tackled this problem by increasing simulation time steps—which was acceptable since all relevant phenomena in traditional power systems were characterized by long time constants. This translated to the possibility of setting essentially arbitrarily long simulation time when simulating power systems. Hence, to address properly these emerging systems, both small simulation time steps and long simulation times were necessary. This predicament was exacerbated further by the fact that tests had to be repeatedly conducted (considering different operating points, networks configurations, control functions, etc.). Consequently, the usage of traditional offline simulation tools for modeling power systems integrated with DGSs became impractical.

The main impediment was the platforms used to conduct traditional offline simulations—PCs. To enable more efficient and practical validation of DGSs integrated with power systems, new, dedicated, digital platforms had to be developed.

The first efforts went in the direction of paralleling many conventional processors [15]. Although this gave certain improvements (systems that are more complex indeed could have been addressed), the scalability, firmware complexity, and maintenance of such systems were impractical for commercial products.

The paradigmatic change happened with the introduction of field-programmable gate arrays (FPGA) platforms in the domain of DGSs simulations. They provide parallel computations and consequently enable a significant decrease in models’ time execution.

Actually, not only that complex models’ execution was accelerated, it became possible to run models in real time. Besides accelerating validation procedure, the usage of FPGA-based platforms enabled interaction of real-time executed models and real devices, in which cases the real device was a device under test (DUT), and the model was used to mimic sophisticated operating conditions, often found in power systems rich with DGSs.

Consequently, two real-time simulation approaches emerged:

• Controller hardware in the loop (C-HIL);

• Power hardware in the loop (P-HIL).

Both approaches are based on real-time simulators (RTSs). RTSs are interfaced with either microcontroller running designed control schemes or with certain high power devices (e.g., inverter).

3.1 Controller hardware in the loop

The most comprehensive microcontroller and control schemes operation analysis can be conducted using the C-HIL approach, especially if distribution networks or microgrids with many DGSs are considered. The real controllers, with control code that will be deployed in the field to drive DGSs, are used, and their interaction with the rest of the system can be examined considering phenomena pertinent to networks proliferated with DGSs. How precise are the test results depends only on how precise are the power stage models. It should be emphasized that the models’ complexity, precision, and level of details are as good as in the case of offline simulator approaches, if not better. The power stage complexity does influence the simulation time steps, but modern RTS enables sub-1 μs time steps, even for complex power stages, which is sufficiently small for DGSs applications. Alternatively, C-HIL can be used to test the interaction of one converter and its surrounding subsystems (e.g., grid-connected converter with stiff grid, electric vehicle, etc.). Finally, this environment can be used to test the operation of the singular converter, such as an inverter in machine-driven applications. In other words, the same C-HIL platform can be used to analyze PE systems of almost arbitrary complexity.

Still, it should be said that the C-HIL is usually not intended to be used for testing semiconductor-devices-related phenomena, although there are no technical obstacles [16]. Actually, semiconductor devices are oftentimes modeled as ideal switches. The semiconductor-devices-related phenomena can be more meaningfully addressed using the MIL approach, utilizing free MIL software.

The C-HIL environment consists of real-time simulators, interface boards, and controllers. The outline of the C-HIL platform is given in Figure 5a. The RTSs are often denoted as emulators, as they emulate the behavior of certain power stages. The complexity of the power stage can range between singular and simple DC-DC converter (e.g., buck converter) to a distribution network of a small town with many DGSs included.

Figure 5.

Real-time simulation approaches—Controller model in the loop (a) and power hardware in the loop (b).

The power stages are defined on PC, using dedicated software, compiled and downloaded on emulators. Although emulators themselves are rather complex digital systems, their complexity and complexity of power stages are usually hidden from the user behind IO boards.

The interface board (IB in Figure 5) is used to adjust analog and digital signals exchanged between the emulator and the controller. The emulator sends analog signals that should be analogous to the signals that would be generated by the real sensors in the real power stage (currents, voltages, machine speed, etc.). These signals are adjusted using ordinary operational amplifiers circuits (AMP in Figure 5a). Then they are forwarded to the controller’s analog inputs and analog-to-digital conversion units. This information about relevant power stage variables is used in the controller to synthesize new control and gating signals. Accordingly, the controller generates digital, gating, signals for the converters’ switches, found in the power stage. These signals are also adjusted using level shifters (LSH in Figure 5a). Then these signals are sent to the RTS’s digital inputs. There, they result in turning on and off certain switches, resulting in circuit reconfiguration and adequate change in controlled variables. Hence, the feedback loop is closed. Analog and digital signals can be exchanged in the reversed fashion also, but those signal pathways are of secondary importance in most of the DGSs-related applications. Since operational amplifiers and level shifter circuits are simple, the whole interface boards are simple electronics circuits and can be quickly developed for any controller board.

Controller boards used in C-HIL, which is a DUT in this setup, can be arbitrarily chosen with the only limitation that they must have sufficient resources to run the control code that should secure necessary DGS’s features.

The C-HIL setups enable the creation of comprehensive DGS’ digital twins and high-fidelity testing procedures. The users are provided with reliable control code behavior testing results, without compromising either the equipment nor personnel. The fact that no high power devices are used makes this environment perfectly safe and equipment management is done without procedural hurdles. Since real-time tests execution is secured, the tests execution is significantly accelerated, in comparison to offline simulation approaches. Actually, if it was not for controller boards, the test could be done even faster than in real-time—the RTSs are sufficiently quick, but are “slowed down” so that they can be meaningfully interfaced with controller boards. Moreover, considering that both power stage and control code are run in a form of code on a specific platform (RTS for power stage and controller boards for control code), test automation is possible [17]. Complete testing procedures (with different operating points, control codes, network parameters, etc.) can be executed consecutively and with minimal personnel effort by running simple scripts, usually written using python. Finally, nowadays, the RTSs are affordable, and their price is comparable with MIL or SIL software licenses.

The only disadvantage of C-HIL usage to build DGSs digital twins and run tests on them is that it is not possible to examine the operation of high-power hardware components.

3.2 Power hardware in the loop

P-HIL setup was proposed to address the shortcoming of the C-HIL approach—as an environment in which certain high-power devices can be tested in conjunction with an adequate digital twin. DUT can be anything from a simple protection device to a multilevel converter.

These setups could be meaningfully deployed in several situations. Firstly, in complex PE and DGSs systems, the system’s parts are developed at different instances. Hence, to manage efficiently development and verification time, the functional subsystems can be tested before the whole setup is ready for integration and verification. Similarly, it is generally advisable to test parts of a complex system before operating on the complete system, since this facilitates design mistakes identification and decreases the possibility of catastrophic failures occurring during final tests. In these cases, the P-HIL can mimic the behavior of the still-to-be-implemented part of the addressed system. Secondly, when addressing high-power devices, the P-HIL environment is advantageous since it can be safer for verification than standard full-power prototypes—prompt termination of dangerous and faulty tests is inherently easier in a P-HIL setup. Thirdly, if the behavior of DGS’s hardware should be investigated against complex network conditions (e.g. protection device of a grid-connected converter in microgrids), the P-HIL is irreplaceable since tests on real networks would be either impossible or expensive and dangerous for both equipment and personnel.

The P-HIL platforms, depicted in Figure 5b, are conceptually similar to C-HIL counterparts, but have some specificities also. The RTS part of the setup can be the same emulator unit as in the C-HIL setup, but the model realized in the RTS is generally either passive network or active network with simplified (averaged) models of DGSs, since there are no controller boards controlling the DGSs’ operation.

The interface cards are in this case significantly different. This is a consequence of the fact that DUT is a high-power device. Hence, to connect and exchange relevant data between the RTS and DUT, the interface board must contain, besides ordinary operational amplifiers circuits and digital-to-analog conversion units (DAC in Figure 5b), high-power amplification circuits (AMP in Figure 5b). AMP in Figure 5a and AMP in Figure 5b are not the same circuits. High-power amplification circuits are rather complex devices and can be based on switching amplifiers, linear amplifiers, synchronous machines, or multilevel converters [18]. It is evident that the amplification circuits can be as complex as DUT itself, and they are only a part of the interface board. Moreover, high-power amplification units inherently introduce signal propagation bandwidth limitation and latency. This can compromise experiments’ precision and reliability and can cause stability issues. Mitigation of these issues is a topic of ongoing investigations [19]. The interface board, besides generating high power variables (currents, voltages, and mechanical variables), must adjust analog variables coming from DUT toward the RTS. For this, sensors and analog-to-digital conversion circuits must be implemented. This complicates the interface board further.

The power hardware, i.e., DUT, can be any piece of hardware pertaining to PE or DGS device whose operational characteristic shall be examined.

Consequently, the P-HIL offers a comprehensive analysis of how certain real pieces of hardware will behave once deployed in the field. It is a relatively safe environment, but since it does consist of high-power devices, the flexibility and ease of use of P-HIL are decreased in comparison to C-HIL setups. Moreover, interface boards’ complexity limits to some extent the commercial attractiveness of P-HIL setups. Finally, although P-HIL setups are based on emulators and are easily reconfigurable, testing automation cannot be fully realized, and some manual interventions must be made during different experiments being executed consecutively.

4. Emerging platforms for DGSs digital twinning

The C-HIL and P-HIL environments were until recently sufficient to meet all the digital twinning needs of engineers and researchers in the domain of DGSs. Several niches, but important, research and public sphere incentives have resulted in the development of advanced platforms for digital twinning. They are all based on C-HIL and P-HIL devices, but are conceptually somewhat different and bring several new features.

Currently, the following types of advanced digital twinning platforms are developed:

• Cosimulation platforms;

• Cloud emulation and simulation platforms.

4.1 Cosimulation platforms

The first cosimulation platform version is intended for the emulation of large power systems. MC-HILs consists of multiple interconnected hardware in the loop, i.e., RTS units. The RTS units usually are from the same vendor, but they can be from different suppliers, so that the advantages of different units can be put into practice. Moreover, the microcontroller units can be different if serving different purposes. For example, if microgrids with many DGSs are addressed and if both low-level and high-level control structures are implemented, such setup would be rather convenient. This cosimulation type is depicted in Figure 6a. It essentially brings the same advantages and disadvantages that the C-HIL approach brings. The only differences stem from the fact that large systems can be addressed and that the setup itself is more complex and consequently somewhat harder to manage. Still, since there are no high-power devices, MC-HILs setups are versatile and easily reconfigurable.

Figure 6.

Cosimulation platforms—MC-HILs (a), HILs (b).

Modern RTSs consist of both the FPGA platform (used for power stage emulation) and digital signal processing, i.e., microcontroller-like, part. The latter can be used to implement different control functions, ranging from simple network reconfiguration functions to low-level, time-critical, PE-related control structures. Hence, the control algorithms that were.

previously implemented on the dedicated controller cards are now implemented on the same unit as emulated power stage—no external controller cards are necessary. The HILs setup is shown in Figure 6b. A mixture of MC-HILs and HILs setups can be used, also (control structures can be implemented both on dedicated controllers and the emulators).

The HILs configuration has a disadvantage in that the control code is not run on the separated controllers, and consequently the control code execution and the controller cannot be directly validated. Still, if this is not of primary interest, but rather an acceleration of control structures development and validation, particularly in the context of large power systems, ease of use and environment’s management simplicity render HILs a most meaningful platform in this regard.

The third cosimulation platform is a composite of C-HIL and P-HIL approaches. The representation of CP-HILs setups can be found in Figure 7. Such a framework could find application in cases when grid-connected inverter’s hardware and software should be tested against realistic active grid operating conditions, for example. To test inverters’ parallel operation, several inverters can be emulated on the RTS and driven by the dedicated controllers, while DUT would be connected to the same virtual point of common coupling. Such tests are as close as possible to tests executed on real, complete setup, whereas a test in real operating conditions would be unacceptably expensive, dangerous, and impractical, especially during the validation phase and particularly at high-power levels.

Figure 7.

Cosimulation platforms—CP-HILs.

Since CP-HILs’ environment consists of all parts and devices found both in C-HIL and P-HIL paradigms, CP-HILs inherit all advantages and disadvantages of those two approaches, but are also much more complicated to manage, especially if several different RTSs and controllers are used. Furthermore, CP-HILs setups tend to be expensive.

The fourth cosimulation concept represents an aggregation of geographically dispersed C-HIL, P-HIL, and CP-HILs systems. The setups are connected over a dedicated Internet connection, and the emulation data are exchanged over this connection so that the cumulative platforms’ emulation data can be synthesized. Expectedly, the necessity of transferring data over large distances results in significant data latency. Hence, if the whole model is to be executed at the same time step, the step time must be significantly larger in comparison to one in the C-HIL approach. This problem can be somewhat mitigated if the model is partitioned in accordance with the geographical arrangement and different parts are executed at different time steps (or generally in a nonsynchronized manner). Then the latency would affect, i.e., artificially increase “data sampling” period of only those variables that are exchanged between the setups—the rest of the model’s parts could be executed at a much faster pace, in compliance with local setups capabilities. If slowly changing variables are chosen, the data latency does not affect significantly model execution and the reliability and validity of the results.

The first meaningful situation for Geo-CP-HILs setup usage is when the most complicated models should be emulated and one C-HIL, P-HIL or CP-HILs setup would not suffice. Next, Geo-CP-HILs platforms are used when interested parties want to conduct joint tests, but the data privacy must be secured. In these setups, the parts of the model are not necessarily known and available to all parties conducting the tests. Only the exchanged data, found at the model’s parts intersections, are available to more than one test participant (this can also be limited to two test participants). This is the case when power grids to be emulated cover multiple countries, or otherwise administratively, politically, or socially separated territories and entities that want to preserve the security of sensitive power system data. Moreover, Geo-CP-HILs are used when complex models should be merged and multiple model implementations are to be evaded. Only one test’s participant implements a model only once and afterward shares it with other participants. This is particularly important if the participants are using different platforms—the porting of the model then would be particularly difficult. Establishing Geo-CP-HILs setups can be financially meaningful when the setup usage time can be sold to other parties, as in time-sharing financial constructs.

There evidently are applications in which these frameworks would be applicable. Actually, Geo-CP-HILs indeed are the universal digital twinning platform, but considering Figure 8, it becomes obvious that Geo-CP-HILs systems are extremely complex, hard to manage, and difficult to constitute. Consequently, only a handful of such setups can be found worldwide [20, 21].

Figure 8.

Cosimulation platforms—Geo-CP-HILs.

4.2 Cloud emulation and simulation platforms

At the beginning of the third decade of the twenty-first century, the technical and technological problems are not the biggest obstacles for wide DGSs’ adoption in residential and industrial areas, but also generally in distribution and transmission networks. Software and hardware technologies pertinent to DGSs, excluding those applied to islanded microgrids, are mature and only incremental advancements are necessary. One of the biggest hurdles impeding further proliferation and “crossing the chasm” of the DGSs is related to how the general public perceives traditional grids and DGSs. The networks as they are operate reliably and efficiently and average resident and industrial entities are accustomed to how networks function. Moreover, DGSs are not technologies about which the average citizen is particularly knowledgeable. Hence, it may seem questionable why changing something that works well from the user standpoint. Especially since it should be replaced with a complex paradigm under which expensive renewable resources are used, energy storage systems are desirable, where third parties manage new assets so that they are (more) economically feasible and so that the system operates reliably.

The users must be provided with the best possible and palpable proof that the investment will be profitable and that the system will be reliable and safe. In order words, the investment in DGSs must be derisked.

For such tasks, the C-HIL platforms seem reasonable and promising. Using the C-HIL paradigm, comprehensive digital twins of the networks that should be upgraded with the DGSs can be made. Moreover, all control layers that will be deployed in a real network can be executed on a C-HIL setup. Consequently, using historical data (for solar irradiation, wind speed, load profiles, etc.) and other pertinent data within C-HIL digital twins, it becomes possible to quickly execute all kinds of technoeconomic studies. Such studies are the next best thing to data obtained from the real operating power system.

Still, the C-HIL setups are not as affordable so that they can be bought anytime certain party necessitates a power system case study. Moreover, they are intended to be operated by professionals.

Therefore, cloud emulation and cloud simulation platforms are being developed [22]. The primary objective is to “hide” the emulation and simulation tools behind the cloud services and enable electrical engineers, engineers from other engineering trades and non-engineering personnel to conduct tests. These platforms will provide automatic model generation (in accordance with data provided by users), compilation and execution of the models. Hence, the user will just have to provide the data defining the model, network topology, DGS installed power, historical data, etc., and will get the testing reports automatically. Consequently, cloud emulation and simulation platforms will act as black boxes for C-HIL or HILs setups from the user standpoint. It is important to note that third-party services, such as financial and energy-trading platforms, will be able to access the emulation and simulation tools.

There are two types of cloud services developed—cloud emulation and cloud simulation services.

The cloud emulation platforms are based on RTSs, i.e., C-HIL or HILs setups, and inherit their performance characteristics. The outline of this paradigm is shown in Figure 9a. Once again, an external controller can be used, as in C-HIL, but certain RTSs have sufficiently large resources to run in real-time control code also and thus eliminate the need for dedicated controllers. In the domain of cloud services, it is irrelevant what will be the control code implementation platform. This enables further improvement. Namely, since both power stage and control code are run (more precisely designed, compiled, and run) on the same platform, there are no technical obstacles why both parts of the digital twin would not be run even faster than real time. The state-of-the-art RTSs enable up to two times faster than real-time models execution for medium complexity models, such as a network with 10 nodes and an equal number of DGSs. For more complex and larger models, the acceleration is naturally smaller, and vice versa. It should be emphasized that the RTSs, and hence cloud emulation services, can be used to examine even transient phenomena (phenomena with time constants smaller than 1 ms).

Figure 9.

Cloud emulation (a) and cloud simulation (b) platforms.

Alternatively, if transient phenomena are not of importance, but steady-state and averaged network behavior, the digital twin can be created using simplified network and DGSs elements. This is suitable for implementation using simulation tools on PC or server devices. This organization is designated as cloud simulation platform. It is conceptually depicted in Figure 9b. Since the digital twin is simpler than the digital twin implemented on emulation platforms, the execution time is significantly shorter. Depending on the network size, the execution time can be more than a thousand times shorter than the real time. This enables simulation of one year of network’s operation within one day or less.

Once completely functional, cloud emulation and simulation platforms will become an irreplaceable tool for emerging power systems operation examination and derisking.

5. Conclusion

The power electronics, distributed generation sources, and power systems research and development processes are layered and complex, and there are a plethora of different tools that can be used to help engineers and researchers carry out their activities. Consequently, even the terminology can be confusing at times, and it is not always transparent which tools should be used during different development and validation phases for different applications.

This chapter gives an overview of platforms and paradigms that can be employed to create and utilize digital twins pertaining to mentioned systems. How digital twinning platforms are constituted and what are their main advantages and disadvantages is explicated. Also, details regarding the area of applicability are provided.

The chapter addresses traditional digital twinning platforms (model in the loop, software in the loop, etc.), real-time platforms (controller hardware in the loop and power hardware in the loop), and emerging platforms for simulation and emulation of advanced power systems proliferated with distributed generation sources.

Conflict of interest

The authors declare no conflict of interest.

Funding

The research was funded by “Innovative scientific and artistic research from the FTS activity domain 451-03-9/2021-14/200156” project, financed by Serbian Ministry of Education, Science and Technological Development.

The authors would like to thank the European Commission and the partners of the European Horizon 2020 “CREATORS—CREATing cOmmunity eneRgy Systems” (https://www.creators4you.energy/) for their help and support. The CREATORS project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 957815.