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.
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, assessing new functionalities or technical implications of introducing new business models and new devices.
Types of Digital Twins | What does a digital twin for battery applications enable?
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 construction, renovation, and implementation processes of new products and services. These involve making a digital twin prototype of the planned 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 would allow you to centralize data on the site, see where and how the needed changes to the electrical network could be implemented, and see where. Then, with HIL, you could explore how the planned system would perform in the target site, helping you better size the final system, identify potential control issues and test the communication with the system works, all before you start building a real prototype.
Operational phase, or performance, digital twins are designed to support the operational and maintenance phases of an installation. These often work by gathering live and historical data from a real site, feeding it into a database, displaying the data of individual devices (digital twin instances) or the performance of all devices together (digital twin aggregates) so it can be interpreted easily by site managers, such as through a Building Information Management (BIM) system. An operational phase digital twin that works with HIL testing allows for a high-fidelity sandbox environment for testing new control strategies or for training new microgrid operators, without putting the real system at risk. Additionally, operational digital twins allow for scenario testing, enabling data-driven predictive maintenance and/or cybersecurity robustness tests to avoid system failures before they occur, as well as making post-mortem analysis of system failures and their potential solutions easier and bringing the grid system back online faster.
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 modelling and, secondly, to have relevant data for its validation.
The first requirement for creating a digital twin is the proper modelling inputs. In other words, the modelling 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 modelling 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 modelled 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 modelling 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 modelling engineer creates a data specification document based on the agreed-on purpose of the digital twin which the relevant stakeholders then need fill in with nameplate data, technical specification and, possibly, communication registers for the modelled assets. With the proper input data, the model is guaranteed to accurately replicate the physical device or system.
Of course, any modelling 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 modelling 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 modelling engineers can carefully modify and parametrize the model until its behaviour 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 modelling engineers ensure the correct scaling and type of measurements made via MODBUS, CAN, IEC61850 or other communication protocols.
In short, once you create a model based on relevant inputs and validate on the basis of relevant historical or real-time measurements, you have created a digital twin for that purpose: a model whose behaviour matches the behaviour of your physical device or a system.
H2020 HYBRIS | How can digital twins demonstrate the value of novel battery systems?
If digital twins are to be widely used, it is important that the modeling framework can be demonstrated in a repeatable and scalable way. In the HYBRIS project, a Toshiba Lithium-Ion battery optimized for power services and a Kemiwatt redox-flow battery optimized for energy services are integrated into a novel hybrid battery system designed to work in a single shipping container, which is moved from partner to partner during the project. To support this, a HIL-based digital twin of the hybrid battery system is developed and validated against real tests to support commissioning and control testing of the real battery prototype. The model is designed with flexible parameters, so that different sizings of the battery systems can be considered over the course of the project.
Once validated, this digital twin of the battery system will be integrated into a digital twin of an Italian grid system managed by Solidarity and Energy. This essentially creates a “virtual demonstration site”, where either the SCADA system on the site or a cloud-based controller can act as the control device under test. Of course, this requires that the site model is properly validated, which will be done in two stages: first, by using the historical and real site data to ensure the control inputs on the site match the simulated behavior in the twin, and second, by replicating the tests performed on the real site with the real battery prototype against those in the fully virtual digital twin environment. Once both validation tests are confirmed, tests on the “virtual demonstration site” can then be performed in advance of real tests, allowing it to act as an operational digital twin of the site.
Lastly, this approach is extended for a residential demonstration site in the Netherlands managed by i.LECO. Here, no real battery system or local controls will be implemented; instead, a “virtual demonstration site” will be created and validated without the battery asset just as for the Italian site. With the grid digital twin validated, the HYBRIS battery model can also be added virtually, allowing potential users to compare the benefits of the HESS system, and even the performance of different sized battery systems, using the real conditions of the site itself. This framework has the potential to be a powerful sales tool, making adoption of novel and custom battery systems much more feasible and giving confidence to those that seek to integrate these new technologies that they will work as intended.
Written by Sergio Costa and Aleksandar Kavgic from Typhoon HIL.
