HIL simulation using a B-Board PRO

This technical note introduces the basic principles of HIL simulation and provides practical considerations for the implementation of a controller-HIL setup using the imperix B‑Board PRO. In the developed example, Plexim’s RT Box is used as the simulator executing the plant model in real time.

Introduction to HIL simulation

Hardware-in-the-loop (HIL) simulation is generally defined as a validation technique where a real physical controller interacts with a simulated plant instead of the actual physical plant. The controller is therefore the hardware inside the (control) loop involving an emulated system, the latter being often implemented using dedicated real-time simulation equipment. A HIL test bench typically consists of:

• Real-time simulator: executes the plant model, often with a fixed time step.
• Controller: runs the control algorithm on the real control hardware.
• I/O interface layer: connects the controller with the simulator.

This configuration is often referred to as controller-HIL (or C-HIL), because the controller is the device under test (DUT) inside the loop. Other configurations of “hardware inside the loop” are also possible, for instance involving an emulated controller connected to a real plant (opposite configuration), although this is usually not designated as a HIL setup. In the same line of ideas, the configurations that involve real power exchanges are rather designated as Power HIL (or PHIL) scenarios, so that they are clearly distinghuished from those that only exchange signals or information. In this case, a power amplifier (or equivalent) is required between the simulator and the DUT.

HIL and PHIL simulation are widely used in domains such as power electronics, automotive, aerospace, microgrids, and power systems. Their typical benefits are to help accelerate development and improve safety, notably by shifting risky or hard-to-reproduce scenarios into a secure, controlled environment.

In a typical C-HIL configuration, illustrated in Fig. 1, the simulator computes the plant response in real-time and emulates the corresponding physical sensor signals (such as voltages and currents) that the controller would otherwise receive in an actual deployment. These signals are exchanged through a physical I/O interface, creating a closed loop. On the other side of the interface, the controller sees the simulator through the same analog and digital interfaces, “believing” that it is connected to the real system.

Offline vs. real-time simulation

In order to compute the plant response in real time, the simulator must be able to solve the corresponding differential equations within a pre-determined latency. For this reason, the model must be compatible and optimized for fixed-step execution. Iterative solvers are typically avoided. Additionally, the model fidelity must be chosen as a trade-off, so that the simulator can reliably finish computation before the next time step. Over-runs are generally considered as a real-time violation.

Due to the above constraints, discrepancies between offline and real-time simulation can often happen. Some typical situations are mentioned below:

• Offline simulation might be using a solver type and configuration (i.e., variable-step or fixed-step) that resolves switching and fast dynamics differently than the real-time solver being used by the simulator.
• Real-time simulation forces a compromise between time step and model complexity, which can result in changes in high-frequency behavior and transient performance.
• The controller generates PWM edges almost continuously in time, but the real-time simulator sees them through a discrete-time capture interface. If edges don’t align exactly with the real-time step, edge timing quantization happens, which significantly distort the duty-cycle estimation, especially for high switching frequencies. All HIL vendors implement techniques to minimize this effect, with different pros and cons.

Imperix interfaces for HIL simulation hardware

Imperix offers different rapid control prototyping (RCP) controllers, power modules and sensors, enabling users to perform experimental validation. Additionally, imperix provides dedicated simulator interfaces that act as a physical bridge between its B-Box family of controllers and third-party real-time simulators (see Fig. 1). These interfaces ensure electrical and signal-level compatibility for both analog and digital interfaces:

• Analog outputs of the simulator are converted to RJ45 connectivity for the B-Box controllers.
• Optical PWM signals from B-Box controllers are converted to electrical signals for the simulator.

Imperix currently supports the following HIL simulation platforms:

• OPAL-RT Simulator Interface, refer to TN180 for further details on simulation with OPAL-RT simulators.
• Typhoon HIL Simulator Interface
• Plexim RT Box Simulator Interface
• Speedgoat Simulator Interface

Benefits and limitations of HIL simulation

In a typical development process, HIL simulation can serve as the bridge between simulation and hardware testing, as illustrated in Fig. 2. It is an optional step that can help validate controller algorithms early in the development process, typically when a hardware prototype is not yet available or when offline simulations are inconveniently long to execute.

HIL simulation is particularly useful when testing involves difficult or destructive scenarios that are unsafe, costly, or impractical to reproduce on physical prototypes (e.g., fault injection, AC grid disturbances, over-current events, etc). More generally, HIL simulation also brings increased realism compared to offline simulation by:

• Forcing the incorporation of real-world challenges such as measurement noise, quantization phenomena, discrete control execution, hardware-specific limitations (e.g. memory usage, stack overflows), etc. inside the simulation.
• Offering support for testing random interactions such as perturbations, communication exchanges, etc.

On the other hand, HIL simulation also possesses some inherent limitations, such as:

• Dynamics close to the discretization step size are difficult to model or cannot be modeled with sufficient accuracy. While this is obvious for very fast phenomena (e.g., semiconductor ringing), this often also applies to medium-frequency dynamics (e.g. DAB or LLC waveforms), at least without highly dedicated FPGA-based solvers (which generally offer only limited user flexibility or observability).
• The validation of efficiency-related concerns (thermal behavior, cooling, etc.) is generally not possible, or only incompletely.
• Phenomena related to the common-mode behavior of the system are generally ignored (due to the associated computational burden, incompatible with real-time execution), imposing limited visibility on the possible issues associated to filters, circulating and leakage currents, etc.
• More generally, any aspect that is not anticipated and, therefore, not included in the simulation model cannot be faced or tested. This prevents HIL simulation from being able to expose unforeseen challenges or problems.

In light of the above, the value of HIL simulation lies not so much in improving the plant model fidelity, but rather in offering what offline simulation lacks, i.e.:

• Testing opportunity for the real control hardware along with the embedded software or firmware.
• Offering support for faster simulations with faster iteration cycles, as they run in real-time.

In practice, HIL simulation is generally cost-effective when it prevents expensive prototype iterations by catching integration- and control-related issues early, while prototyping is attractive and necessary when the dominant risks are related to the power stage, or involve efficiency- and EMC-related concerns.

C-HIL simulation example

This example uses the imperix B-Board PRO and Plexim’s RT Box 2. The real-time simulation of a DC-DC buck converter is used to demonstrate the workflow using PLECS. TN100 outlines the implemented output voltage control and is used as a reference. The simulation model is built using the imperix Power library.

In this example, a single PLECS model is used to generate C++ code for both the control side and the plant side, which are subsequently deployed to the  B-Board PRO and Plexim RT Box, respectively. Specific settings may differ for other real-time simulators, but the underlying concepts remain the same. The following articles address the corresponding steps and are recommended for further reading:

• PN134 for getting started with imperix ACG SDK
• PN137 for understanding simulation essentials with PLECS
• PN151 for other PLECS examples with different plants available for download
• AN006 for a similar implementation of HIL simulation using the B-Box RCP 3.0 and Plexim’s RT Box 2

Downloads

A PLECS model containing the closed-loop output current control of the DC-DC buck converter is provided. The imperix power library requires ACG SDK 2024.2 or a later version.

Experimental setup

The experimental setup is shown in the Fig. 3. In this case, as the evaluation kit of the B-Board provides direct access to electrical signals, a special hardware is not required. Instead, an exploded DB-37 cable is used to directly connect the B-Board PRO development kit to the front side of the RT Box.

Hardware and software requirements

The following list includes imperix products, plus additional components required for this example:

• Imperix products
  • 1x B-Board PRO development kit
  • Imperix Control development tools for Simulink and PLECS (ACG SDK) that includes Cockpit
• Additional software
  • PLECS standalone with PLECS coder
• Additional hardware
  • Plexim RT Box (can be any variant)
  • 2x exploded DB-37 cable
  • 1x gender changer
  • 12V DC adapter for powering the B-Board PRO

Setting up HIL simulation

The setup of HIL simulation involves several steps. A similar procedure can be followed for setting up a HIL simulation with any other control implementation or plant model.

Model implementation

A buck converter example is built in PLECS using the default template file provided by imperix. The controller and the plant are modelled in seperate subsystem as shown in Fig. 4.

PLECS model preparation and settings

Effective data exchange between the RT Box and the B-Board PRO relies on several key blocks from the PLECS RT Box library (italicized below) and the imperix library (in bold red below). Below are the critical considerations for their implementation:

• PWM capture blocks must be used for receiving the PWM signals (as opposed to regular digital input blocks) so that sub-cycle averaging is possible. The offline behavior in the PWM capture block should be selected as sub-cycle average to properly mimic the real-time behavior (Fig. 5). Nanostep is in fact not usable in real-time unless an FPGA-based converter model is used.
• The subsystem containing the plant side must be enabled for code generation so that PWM capture blocks can be simulated offline. For that, right-click on the plant subsystem and selected subsystem–> execution. Then check “enable code generation”, as shown in Fig. 9.
• Analog out blocks should be used on the RT Box to provide the scaled analog signal to the imperix ADC blocks. Scaling and min/max output settings are shown in Fig. 6. The scaling for each Analog out and the corresponding ADC block (Fig. 7) on the imperix side must be identical. This can be validated during offline simulation. As the B-Board PRO operates within ±5V, using this range on the RT Box too is recommended.
• The recommended settings for CB-PWM block are shown in Fig. 8. As both PWM signals are generated and transmitted to the simulator, reverse conduction is implemented in the lower MOSFET.

The following are some optional interfaces included for the sake of completeness. They can be used, for example, when control logic or relaying is required:

• Digital In can be used for general-purpose output signals (GPO) coming from the B-Board PRO.
• General-purpose input signals (GPI) from the B-Board can be connected to the Digital Out of the RT Box.
• DAC channels can be used to output analog signals from the B-Board PRO. The imperix DAC block and the corresponding Analog In of the RT Box library can be used.

Wiring of the B-Board and RT Box

The PWM outputs of the B-Board PRO are wired to the RT Box digital inputs as shown in Fig. 10. An exploded DB-37 cable can be used to wire them together as shown in Fig. 3.

Deployement of the plant model

The step-by-step procedure to compile and load the plant model on the RT Box is as follows:

• If not already, code generation must be enabled for subsystem containing the plant side. Right-click on the plant subsystem and selected subsystem–> execution. Then check “enable code generation”, as shown in Fig. 9.
• In the PLECS environment, go to Coder→ Coder options. Select “plant” in the left area (under the model file name).
• The “General” tab can keep the default settings.
• In the “Target” tab:
  • Select the RT Box variant being used. In this example, PLECS RT Box 2 is selected.
  • Select the analog input voltage range to “-5V … 5V” as B-Board PRO’s input voltage range is ±5V.
  • Select the analog output voltage range to “-5V … 5V” in case DAC blocks are used as well.
  • Select HIL for the simulation mode. All the settings for the “Target” tab are shown in Fig. 11.
• In the “External mode” tab of the coder options menu:
  • Select the target device by entering the hostname or IP address. Other settings are shown in Fig. 12.
  • Click “Build” to generate and upload the code directly to the RT Box.
  • When everything is rightly done, a blue LED next to “Running” on the front interface of RT Box 1 will light up. For other RT Box variants (e.g., RT Box 2 used here), the LCD will display the name of the subsystem being simulated in addition to the current CPU cores’ processing time.

Deployement of the control implementation

The following are the steps to compile and load the control algorithms to the B-Board PRO:

• The subsystem containing the control side must also be enabled for code generation. Right-click on the controller subsystem and selected subsystem–> execution. Then check “enable code generation”, as shown in Fig. 9.
• Open Coder → Coder Options, then choose “imperix controller” from the panel on the left (under the model name).
• The “General” tab can keep the default settings.
• Go to the “Target” tab and select “imperix controllers”.
• Go to the ” Scheduling” tab:
  • Select “single-tasking” under Tasking mode
  • The discretization step size must be set equal to the control time period as shown in Fig. 13.
• Click “Build”. Imperix Cockpit should open up automatically.

Testing and validation

The results of offline simulation in PLECS as well as HIL simulation are captured and presented in Fig. 14. In this example, the switching frequency of the buck converter is set to 10kHz. With a fixed discrete time step of 2µs, the RT Box updates the model at 500 kHz (f_s), which means it cannot represent any dynamics above the Nyquist limit of 250 kHz. In practice, the usable frequency range is typically much lower, in the order of 50 kHz (≈ f_s/10). As a result, phenomenas faster than this are not captured realistically.

The following can be observed:

• By keeping the electrical and control parameters identical in both offline and HIL simulations, and by accurately modeling delays in the offline model, both results show an essentially identical response to a step change in the output current reference. The offline and real-time HIL waveforms align closely, as also seen in the zoomed settling-time view.
• The reference step is applied at 0.01s and the controller reacts after the expected delay of 200µs in both offline and HIL simulations, as shown in Fig. 15. Sampling, actuation, and response timing are all observed to be coherent.

If the model is complex and overruns occur during real-time deployment, iterative adjustments to plant fidelity and time steps may be necessary to balance real-time constraints with test objectives.

Getting-started recommendations

Conclusion

The workflow utilizing the imperix B-Board PRO and Plexim’s RT Box demonstrates seamless compatibility between the controller and the real-time simulator. Comparative results reveal identical delays and dynamic responses across both offline and HIL simulation environments, confirming the correct interaction between the devices.

These findings suggest that HIL simulation can be an attractive alternative to offline simulation, offering increased realism, when the perspective is set on the control hardware testing. In such as case, the ability to conduct testing early along the development cycle provides benefits that outweigh the limited accuracy of the model (such as a restricted frequency range or disregarded common-mode behavior). That said, more generally, HIL shall rather be seen as a complement than a replacement to offline simulation. Notably, HIL should not be considered blindly as a method for achieving higher modelling accuracy, which it isn’t.

When opposed to experimental prototyping, HIL simulation is an excellent framework for executing tests that are either hazardous or difficult to replicate in a laboratory setting. It is also often faster and less cumbersome than physical testing. However, thermal and EMI-related phenomena typically remain outside the scope of current HIL capabilities. Additionally, the cost-effectiveness of HIL versus full-scale prototyping remains a subject for further debate.

To go further from here…

The next step could be to implement the buck converter physically and test the controller’s performance. Refer to PN119 to understand how to build a buck converter from scratch using imperix half-bridge modules and sensors. The following resources can also be helpful:

• TN100: Step-down buck converter
• TN180: C-HIL simulation scenario with OPAL-RT simulators
• TN122: Interleaved buck converter current control
• TN102: Buck-boost converter
• PN151: Basic examples for ACG SDK on PLECS