Blog Highlights:
- What is a digital twin and how does it work in HIL?
- What are the types of digital twins?
- What do you need to make a HIL digital twin?
Introduction | What is a digital twin? How does it work in HIL?
The renewable energy transition is well underway, with current events driving an urgent push away from a heavy reliance on foreign sources of natural gas and oil. Advances in sustainable energy technologies and grid control methods are making this possible; generating and sharing power locally is now more accessible than ever before. However, actually implementing these changes is a major challenge on its own. Existing grid infrastructure features a complex mix of new and old equipment, most of which is not designed for the unique grid balancing and stability challenges posed by distributed renewable energy sources and energy storage. For this reason, any new grid equipment or control mechanism must be carefully tested in order to avoid any unexpected or disastrous consequences. If only there was a safe environment where these complex interactions could be tested, considering the unique local conditions of each site!
Enter the digital twin. Digital twins are high-fidelity mathematical models of a physical device or a system. The key word in this definition is “high-fidelity”. This means that, for the same conditions or stimuli, a digital twin will behave in precisely the same way as the physical device or a system. For example, a digital twin of a solar power plant will produce the same amount of power and provide the same power quality (voltage, frequency, harmonics, etc.) as the physical power plant for identical conditions: solar irradiation, outside temperature, type of the PV panels, condition of PV panels (e.g. recently cleaned or atmospherically contaminated), type of the inverter(s) used in the solar power plant, etc.
Figure 1. Example of the C-HIL digital twin concept. With HIL, the real controller (bottom) is the device under test, and it receives and sends the same signals to either the real system (left) or the digital twin emulation (right).
Hardware-in-the-Loop (HIL) methodology is the most powerful way to utilize the digital twin, acting as an interface between the digital twin and a physical device or a system. More specifically, HIL testing allows a device under test (DUT) to “believe” it is operating on the real system while it is actually operating on a digital twin. This is possible thanks to the high fidelity of the digital twin, which provides the DUT the same types of signals at the same speed and the same power levels as it would in a real installation. In the context of digital twins of microgrids or community energy systems (CES), the DUT is typically a SCADA system, a building management system (BES), or a cloud aggregator, controlling and operating the digital grid just as if it were the real grid. This can be useful in a wide range of cases, such as when testing new operational strategies, training new grid operators, troubleshooting equipment errors, and assessing new functionalities or technical implications of introducing new business models and new devices.
Types of Digital Twins | Why would I need a digital twin?
Digital twins are categorized in several different ways, but one of the simplest is by focusing on the phases in the product lifecycle that they support. In this context, digital twins usually are built for one of two phases: developmental phase digital twins and operational phase digital twins.
Development phase digital twins (a.k.a product or production digital twins) are designed to support the development, renovation, and implementation processes of new products and services. These involve making a digital twin prototype of the planned component or system prior to construction. For example, if you wanted to install a new grid-storage battery system on an existing site, a development phase digital twin of the battery and the inverter can let you validate how the proposed components would behave under the real conditions present at the target site. Then, creating a digital twin of the grid with its components allows you to see where and how any needed changes to the electrical network could be implemented. With HIL, you could bring these digital twins to life and explore how the planned system would perform in real-time, helping you better identify potential control and communication issues, all before you start building a real prototype.
Figure 2. Example of SCADA system control testing using a digital twin of a microgrid.
Operational phase, or performance, digital twins, on the other hand, are designed to support the operational and maintenance (O&M) phases of an installation. These work by gathering live and historical data in a central database in order to tune existing component and system models to more accurately represent real assets and present them in a way that is easy to interpret by site managers, such as with a SCADA panel or Building Information Management (BIM) system. With HIL, you can perform scenario tests to see how the real system in its current state would respond to a wide range of unexpected events. This is particularly useful for identifying and avoiding grid failures before they occur via performance, unintentional islanding, or cybersecurity robustness tests, as well as for troubleshooting and analyzing grid failures after they occur to quickly find potential solutions that can bring the grid system back online faster. Additionally, the same digital twin can be used for analyzing and characterizing new control strategies using real data, helping improve system response and even support training for new microgrid operators, all without putting the real system at risk.
A modular and vertically-integrated HIL solution makes this process even easier. Since HIL models are built to run in real-time from the beginning, you can use the same digital twin model for both the development and operational stages by simply tuning and feeding your development phase model as you gather more real or live site data. This further improves model fidelity, while also providing all the scenario testing advantages that are invaluable for mitigating risk in modern grid applications, where existing assets often must be safely controlled in new and unexpected conditions.
HIL-based Digital Twins | What do you need to make a digital twin?
Every digital twin is a model, but not all models are digital twins. The difference between a model and a digital twin is in the fidelity and accuracy of emulation of the physical device or a system, which, in the case of digital twins, are indistinguishable from the physical one. To make this possible and create a model that can be rightfully called a “digital twin” it is necessary to, firstly, get the relevant inputs for modeling and, secondly, to have relevant data for its validation.
The first requirement for creating a digital twin is the proper modeling inputs. In other words, the modeling engineer creating a digital twin needs to know exactly what devices should be included in the twin, as well as their specifications and operational characteristics. The level of details and data inputs required depend on the purpose that the digital twin will serve. For example, when performing sizing studies for new assets in microgrids, such as choosing the optimal size of a battery storage system, the relevant modeling inputs include the nameplate data of existing assets, such as the types of solar panels, the power rating and efficiency of the solar inverters, and other relevant data that is typically available in the specification table at the end of the modeled asset’s user manual. However, for integration and pre-commissioning use cases, it is necessary to also have information on the communication layer, such as the MODBUS register maps of the inverter, custom SunSpec registers and functionalities of a battery storage system, or, say, the OCPP version of the EV charger. By creating a model with the same communication capabilities as the physical system, the modeling engineer can create a true digital twin that, from the point of view of a device under test, e.g. SCADA or a building management system, behaves precisely like the real system, including the capability to read and write the same data using the same communication setup. To make this model, the modeling engineer creates a data specification document based on the agreed-on purpose of the digital twin which the relevant stakeholders then need to fill in with nameplate data, technical specification and, possibly, communication registers for the modeled assets. With the proper input data, the model is guaranteed to accurately replicate the physical device or system.
Figure 3. Visualization of a digital twin of a microgrid. Real power (solid lines) and data flows (dashed lines) can both be tested in such with the proper input data and model parameterization.
Of course, any modeling engineer knows the significance of the phrase “garbage in; garbage out”. What transforms this accurate model into a digital twin is model validation, which ensures that relevant modeling inputs also produce relevant and accurate model outputs. In the context of digital twinning, validation is the process of fine-tuning the model so that its behavior fully matches the behavior of the physical device or system it is intended to represent – in short, ensuring the model is actually useful for the conditions and inputs in question. The main requirement for validation is a data set of relevant measurements: historical, or, preferably, both historical and real-time. By having relevant historical measurements, the modeling engineers can carefully modify and parametrize the model until its behavior is identical to the physical device (or a system) for the same inputs and in the same conditions. The type of data required for validation and its granularity depends on the purpose of the digital twin. For power flow analyses and asset sizing studies, 15-minute interval data is usually sufficient (e.g. for PV plants: solar irradiation, power output, etc.). On the other hand, for emulation of time-critical scenarios, e.g. provision of ancillary services (such as frequency restoration, power quality support, etc.), it is necessary to have second- or even sub-second measurements, as well as additional data from the asset(s) in question (e.g. state of charge, current operational mode of the battery, etc.). If the purpose of the digital twin is to accelerate integration, the communication layer of the digital twin also needs to be validated, whereby the modeling engineers ensure the correct scaling and type of measurements made via MODBUS, CAN, IEC61850, or other communication protocols. Finally, if the digital twin is a multi-physics twin, additional second-degree validation is needed to ensure that each of the individually validated models work together as expected. For instance, if a microgrid includes a CHP whose thermal output needs to be emulated together with its electrical power output, the power and thermal models will need to be validated together to ensure that the measurements of the complete emulated system do not statistically differ from a physical site or system with the same inputs and conditions.
In short, once you create a model based on relevant inputs and validate it on the basis of relevant historical or real-time measurements, you have created a digital twin for that purpose: a model whose behavior matches the behavior of your physical device or a system. In the next part, we will look in detail at two European projects where these kinds of digital twins play a critical role in the validation and adoption of novel technologies and services.
Are you exploring adopting HIL testing in your work?
Contact us to schedule a free demo.
Did you enjoy this article?
Check out our other Digital Twin blog.
Interested in HIL for microgrid applications?
Read more Grid Modernization blog stories.
Text | Sergio Costa, Aleksandar Kavgic
Visuals | Karl Mickei, Milica Obradovic
Editor | Debora Santo
