1. Introduction
The power electronic devices R&D process has changed significantly since the inception of power electronics (PE) as a significant electrical engineering field. Initially, new topologies, or known topologies with new switching devices, were developed using analytical tools and tested using real, although sometimes power-scaled-down, setups.
Similarly, power systems (PS) development relied on expert knowledge, analytical analysis and field data coming from the already operational systems. The test on the real hardware was performed only in the context of singular/particular pieces of hardware and certainly not in the context of whole areas, or even small parts, of power systems.
Only with the proliferation of personal computers did a new tool appear—simulation software. Numerical analysis, using different simulation software, was inserted between the PE or PS device conceptualization and analytical analysis and real hardware tests or field deployment. Although it was an additional step in the R&D process, it had accelerated the process simply because conceptual mistakes and “unknown-unknowns” of the system were identified before the real hardware was made and tested.
This was how development was conducted until the beginning of the twentieth century. It should be noted that the development of the PE and PS fields went on independently to a large extent during this period.
During the first decade of the twentieth century and with the expansion of distributed generation sources (DGS), based on PE devices, into the PS, the two research domains started to overlap. This amalgamation rendered the usage of simulation tools unacceptable—the small simulation steps, imposed by PE devices, and the size of the addressed systems, dictated by the size of PS, resulted in impractical simulation execution times. This problem was exacerbated by the fact that tests had to be performed repeatedly (for different operating points, considering different standardization requirements, etc.). Consequently, new tools were necessary and indeed were developed. This paper offers an overview of tools and environments used to develop and test distributed generation source-related technologies. Additionally, the recent advances and prospects in the field are described.
The following sections are dedicated to the specific environment for DGS examination and are arranged following their novelty.
2. Offline Simulation
Offline simulation, i.e., PC-based simulations executed on “general purpose” simulation tools, have been in use for decades now. They are proven tools, with well-known advantages and disadvantages. Numerous simulation software tools are used by engineers and researchers on a daily basis.
Among other things, the advantages of simulation tools in the development and testing of PE converters and PS are the availability of the software, developed users’ community and support, the possibility of precise and detailed analysis, multidomain examinations, etc.
The most important drawback is that the simulations are almost always executed significantly slower than in real time. This is a consequence of these simulation tools being tailored to suit the needs of engineers from different engineering trades (i.e., solvers are not custom-made). Additionally, since some phenomena are hard to model (latencies and parasitic effects), the simulation results will necessarily differ from responses obtained from the real hardware.
There are four basic types of offline simulations (diagrams (
a) through (
d) in
Figure 1):
Model in the loop (MIL);
Software in the loop (SIL);
Processor in the loop (PIL);
Controller model in the loop (CMIL).
MIL corresponds to a traditional offline simulation. Both the power stage of the addressed system and the appropriate control schemes are implemented using the elements from the same toolbox. Of all the modeling approaches, MIL gives the crudest information on how the real system is going to behave.
SIL assumes the usage of a certain embedded code (e.g., C code) together with the power stage modeled the same way as in MIL (using the elements from the software’s inbuilt library). By executing SIL models, the designer can see whether the code is properly organized and structured (semantic and syntactic checkup), in addition to functional tests of the control scheme. SIL models’ execution necessitates the usage of specific embedded code compilers that are not necessarily readily available within the simulation software.
PIL software utilizes a specific connection between the simulation tool and the processor of the controller board (to be used in real devices). This approach gives insight into the control card memory and processor-time utilization (ADC and PWM peripherals are usually not considered). Still, specific toolboxes must be installed that support communication between the simulation model and the processor and their operation synchronization. These are also not available for a majority of controllers, but only for flagship controllers. Recently, certain vendors started to provide users with a detailed behavioral model of their controller cards that can be included within several popular PC simulation tools. Hence, a new way of performing digital twinning is emerging—controller model in the loop (
CMIL). The users implement the embedded code in the modeled controller, connect the controller to the specific power stage and conduct the desired test. This approach is a great way to test how the complete controller is going to behave once the developed code is deployed on the real controller. In that sense, CMIL is becoming a popular way of digital twinning with a focus on the controller. Unfortunately, only a few vendors (although the most popular are among them) have developed such behavioral models and only for their flagship controllers [
1].
3. Real-Time Simulation (Emulation)
The biggest disadvantage of offline simulations is the time necessary for the simulation to execute. The source of the problem is that the simulating software is executed on a general-purpose platform (PC), usually using simulation tools that are not optimized for digital twinning in the domain of DGS. To overcome this problem, several hardware platforms dedicated to the simulation of PE devices and PS have been developed recently. They enable real-time execution of addressed systems (with similar precision), consequently shortening the development and testing time significantly.
There are two basic types of real-time simulations (diagrams (
e) and (
f) in
Figure 1):
The C-HIL environment consists of a controller (which is a device under test—DUT, i.e., a real piece of hardware), the emulator that mimics the behavior of certain electrical systems and the interface board. To expose the controller to operating conditions similar to those in the real system, the real-time execution of the remaining part of the setup is necessary. To be more precise, in the C-HIL approach, the power stage executed in real time on the emulators must be executed neither slower nor faster than in real time. To secure this, emulators have been developed using dedicated hardware and software tools—most notably, those related to the field-programmable gate array (FPGA) platforms. The interface board in the C-HIL system is usually the simplest part—essentially, it consists of analogue amplifier circuits and voltage level shifters. Analog amplifier-based circuits adjust the analogue signals coming from the emulators (carrying the information about the relevant, most often controlled, variables) to voltage levels of ADC channels of the controller. Similarly, the voltage level shifters adjust the digital signals coming from the controller (most notably, gating signals) to the digital inputs of the emulator. The reverse analogue and digital data transfer are also possible, albeit less relevant.
The primary goal of the C-HIL approach is to test the controller and the control schemes embedded within the controller. This is particularly true when code for machine drives is examined. On the other hand, C-HIL setups can be used to examine the interaction of certain converters with their surrounding electrical or mechanical systems (e.g., inverter connected to a distribution network or electric vehicle). Finally, the modern C-HIL environments can be used to develop control schemes for large systems with several, if not many, converters, as in emerging power grids and microgrids. Considering the complexity and size of the emerging power grids and the impossibility of conducting the tests with such grids and real devices, the C-HIL approach has emerged as the only possible environment to develop pertinent control and coordination algorithms.
It should be emphasized that there are commercially available emulators that have a sufficient amount of computational resources to execute both power stages and the code that would have been implemented on some microcontrollers in a traditional C-HIL system. In other words, only emulators could be used without any “external” microcontrollers. This is particularly important for grid-related applications, where it is not important which specific controller is used for code implementation, but rather the effectiveness of the control code itself. Since there are no microcontrollers that run the code strictly in real time, not only does this approach simplify the environment (everything is executed on the same devices using the same toolchains), but also the execution speed now can be even faster than real time, depending on the model complexity and level of details considered.
The emulators can be also used in conjunction with high-power devices (high-power devices are DUT, in this case). These setups are denoted as
P-HIL setups. Emulators are essentially similar, if not the same, as those used in the C-HIL environment. The DUT can be anything from simple protection devices to multilevel converters. However, DUT (high-power devices) and emulators here are interfaced by significantly more complex interface systems in comparison to the C-HIL approach. These interface systems must amplify electric variables coming from the emulators to adjust them to variables to which DUT should be exposed. In other words, digital-to-analogue conversion (which is not always necessary) must be followed by the rather complex amplification circuitry. This circuitry can be based on switching amplifiers, linear amplifiers, synchronous machines, multilevel converters, etc. [
2]. This amplification stage might be as complex as the DUT! Inherently, P-HIL systems have problems with signal propagation bandwidth and latency, which can compromise testing accuracy and reliability and can even cause stability issues. A general solution for these problems is not found and is a topic of ongoing research [
3]. In addition to complexity and latency issues, the interface systems are expensive and can render the whole environment difficult to manage.
Nevertheless, P-HIL can be meaningfully used in several development processes and testing procedures. For complex systems, whose parts are developed and/or deployed at different paces, it is beneficial to test the certain part as soon as possible and not wait for the whole system to be available. Additionally, generally, oftentimes it is advisable to test parts of a complex system before conducting the test on the complete system. Furthermore, since it is based on the emulators, it is a versatile environment, and consequently reconfigurable and convenient for conducting different tests. Additionally, in comparison to tests conducted on the complete full-power prototypes, the P-HIL environment is inherently safer and able to terminate dangerous tests promptly.
4. Emerging Digital Twinning Tools
There are two novel approaches used to build digital twins:
Co-simulation (diagram (
a) in
Figure 2);
Cloud emulation and simulation (diagrams (
b) and (
c) in
Figure 2).
There are several
co-simulation system versions that can be established. The first version consists of several C-HIL systems, i.e., several real-time simulators and several interface and controller boards (shaded with red in
Figure 2a). Additionally, the co-simulation system can consist of several P-HIL systems (shaded with blue in
Figure 2a). Moreover, the co-simulation system can be established by several C-HIL and P-HIL systems. Generally, these systems are used to emulate large electrical systems. The rationale for using such setups comes from the fact that all of the advantages of C-HIL and P-HIL setups are essentially amplified. Unfortunately, co-simulation systems are often expensive and, if C-HIL–P-HIL combination is in question, quite difficult to manage. Finally, the different co-simulation setups can be integrated into even more complex, geographically dispersed, systems [
4,
5]. Here, the setups exchange the emulation-relevant data over a dedicated internet connection in real time, but with significant latency. These systems are used when privacy and data security should be provided, to evade the model implementation (or porting) on different platforms, to execute the most complex models (at the level of electrical systems of whole countries) and to sell the HIL setup usage time to third parties. Still, since managing these systems is difficult, especially in the context of latency, and since they are expensive to establish, only a few such systems are available.
Currently, services for
cloud emulation and simulation are being deployed [
6]. The main goal of these systems is to “hide” the emulation and simulation tools behind the cloud and provide electrical and interested parties from other engineering and non-engineering trades with a platform that is the next best thing to a real operating system. These services will enable automatic model development, compilation and execution, in accordance with the data provided by the users. After the execution is finished, the services will simply provide the users with generated simulation/emulation results. In other words, the simulation and emulation platforms will behave as black boxes for the end-user or third-party service. Consequently, these systems shall seamlessly be used to completely derisk further proliferation of DGS into the emerging power systems and represent the ideal platform for third-party services to test their features. For example, the economic and feasibility analysis of different DGS deployments within a certain network, using historical and prognosis data, will be performed to the highest possible detail. The investors, who do not possess the expertise to build and execute pertinent models, will have conclusive insight into how their investments will generate profits, as if they had the real system deployed and at their disposal to analyze. Additionally, real-time or even significantly faster than real-time execution is possible, depending on the phenomena that are observed and how detailed the models are.
5. Conclusions
There are several ways how the digital twinning of distributed generation sources can be performed nowadays—from traditional offline (PC) simulations, real-time modeling using C-HIL, P-HIL or co-simulation setups to the abstraction of these approaches in the form of cloud services. Each approach has its advantages and disadvantages. This paper hopefully will help readers understand how these systems function and will help them find a suitable platform for their needs.