HIL Testing for Electric Motor Control

The Complete Workflow: From Desktop Simulation to Full Power

Impedyme structures motor control validation as a continuous workflow with three stages. The power of the approach is that the same models and test assets carry forward at every stage, so engineers never have to rewrite their work when they move from simulation to hardware.

Stage 1: Desktop Simulation

Engineers first build high-fidelity models of the controller and the plant — the PMSM and inverter — in a desktop simulation environment. Here the control algorithm is developed and refined virtually, before any hardware is involved. This is where a reference behavior is established that later HIL tests will be compared against.

Stage 2: Controller HIL Against a Virtual PMSM

Next, the embedded controller becomes the device under test. The motor and inverter models are deployed to an FPGA-based real-time target — an Impedyme CHP Series system or HIL/RCP-Box — running MotorSim Studio. The controller runs its real firmware and interacts with the virtual motor in a closed loop at microsecond time steps.

Stage 3: Power HIL With Motor Emulation

Finally, testing moves into the power domain. Impedyme’s PHIL capability adds a regenerative power interface — a high-bandwidth power amplifier co-designed with the FPGA real-time core — that turns the simulated motor into real current and voltage. A physical inverter is now driven by an emulated motor that sources and sinks genuine power, with no physical machine or dynamometer required. This is where component stress, thermal behavior, and full-power protection are validated.

Inside a PMSM Controller HIL Test: A Walkthrough

To make the concept concrete, consider a representative controller HIL test of a PMSM drive, genericized to the Impedyme ecosystem.

The device under test is an embedded motor controller running a field-oriented control algorithm. It is wired to an Impedyme CHP Series real-time target instead of a real motor and inverter. The closed loop works like this:

• Speed command in: A speed reference is sent to the controller over the CAN bus — the same interface it would use in a vehicle.
• PWM capture: The controller’s PWM outputs are captured by the high-speed digital inputs of the real-time target at nanosecond resolution.
• Motor emulation: The FPGA runs the inverter and PMSM models, computing the resulting phase currents in real time.
• Current feedback: The simulated motor currents are fed back to the controller through the target’s analog outputs, exactly as current sensors would provide.
• Position feedback: Rotor position is returned via quadrature encoder emulation, so the FOC algorithm receives the angle it needs to run correctly in the rotating reference frame. 

From the controller’s perspective, a real motor is spinning. Engineers watch it command a speed, see the virtual motor accelerate, and observe balanced three-phase currents develop — all on screen, with no rotating mass anywhere in the lab.

Requirements Traceability

A disciplined HIL test starts from named requirements and ends with numeric checks. In this walkthrough, two example requirements illustrate the idea: 

• A speed limit requirement — for instance, the drive must not exceed 5,000 RPM.
• A balanced-operation requirement — the three phase currents must remain balanced during normal operation.

Each requirement maps to a test case with defined initial conditions, stimulus, and pass criteria. When the automated test runs, it verifies the requirement and records the result, creating the traceable evidence chain that validation and certification teams need.

Ideal (Averaged) Inverter Model vs. FPGA Switching-Level Model

One of the most important decisions in motor control HIL is how to model the inverter. There are two fundamentally different approaches, and choosing correctly determines whether your test reveals real behavior or hides it.

An averaged (ideal) inverter model represents the inverter using controlled voltage sources that reproduce the average behavior over a PWM period. It is computationally cheap and runs comfortably on a CPU at relatively coarse time steps. It is excellent for validating slow dynamics — speed loops, DC-bus energy balance, system-level coordination — where the fine detail of switching is irrelevant.

A switching-level inverter model represents each semiconductor switch explicitly. It reproduces the actual on/off transitions, and therefore the current ripple, torque ripple, dead-time distortion, and switching harmonics that a real inverter produces. This detail is essential when you are developing the control for the inverter itself, or when protection logic trips on instantaneous peak currents rather than filtered averages. The catch is that it demands a very small time step — which is exactly why an FPGA is required. 

Why the FPGA Matters

An averaged model on a CPU will slow down until ripple and peak currents are muted, and hardware protection that would trip on a real bench misses the same trigger in simulation — leaving teams tuning around a simulator artifact instead of a real control issue. The FPGA solves this because it co-locates computation and I/O on the same chip, eliminating bus-transfer latency. 

In an Impedyme FPGA-based real-time target, PWM gate edges are captured at nanosecond-scale resolution — on the order of a few nanoseconds — while the motor and inverter model updates at approximately one microsecond, driven by an FPGA clock running at roughly 200 MHz. Impedyme’s CHP platform pushes model updates as fast as 90 nanoseconds, performing hundreds to over a thousand updates per electrical period. That temporal resolution is what allows the emulated motor to reproduce saturation, cross-coupling, torque ripple, and back-EMF harmonics faithfully. 

The stakes are quantitative. Impedyme notes that a 25-microsecond simulation loop reproducing an 8 kHz PWM can introduce up to 20% error, while sub-microsecond time steps cut that error to under 1%. In motor control, that difference is the line between a test you can trust and one you cannot.

Observing Ripple, Harmonics, and EMC Behavior

Once the switching-level model is running, engineers can use Impedyme FPGA Scope to observe the signals that matter. FPGA Scope is a built-in, high-speed visualization tool embedded directly in the real-time signal path, capable of monitoring up to 16 simultaneous channels — phase currents, dq-axis currents, phase voltages, PWM edges, and internal controller states — at sub-microsecond resolution, without any external oscilloscope or DAQ hardware. 

With the switching model, current ripple appears as the small high-frequency oscillation superimposed on the fundamental current waveform. This ripple is a direct consequence of the PWM switching acting on the motor’s winding inductance. It drives torque ripple, which in turn causes noise, vibration, and additional losses.

Engineers can run harmonic analysis on the captured waveforms to quantify the distortion and understand its spectral content — critical for anticipating electromagnetic compatibility (EMC) problems before they show up in an EMC lab. The high-frequency content that a switching-level model reveals is precisely the content that averaged models delete by construction, and precisely the content that determines EMI behavior.

Mitigation: Increasing the PWM Switching Frequency

A classic mitigation is to raise the PWM switching frequency. Current ripple is inversely proportional to switching frequency: increasing the frequency shortens the interval over which current can drift between switching events, so the ripple shrinks. This inverse relationship is well established — as an illustrative example, a CERN technical report on high-precision power converters notes that raising switching frequency “from 5kHz that is currently used, up to 60kHz and beyond … gives an increase in accuracy by an order of magnitude or more.” Raising a drive’s PWM frequency to 20 kHz — above the audible range — reduces current ripple, smooths torque, lowers audible whine, and cuts harmonic content, at the cost of higher switching losses. 

Because HIL makes this a software change rather than a hardware rebuild, engineers can sweep the PWM frequency, observe the improvement in ripple and harmonics in real time on FPGA Scope, and find the optimal trade-off between ripple, losses, and thermal stress — all in a single afternoon.

Electrical Fault Injection Testing

Some of the most valuable HIL tests are the ones you could never safely run on real hardware. Fault-injection HIL is built to answer one question: what does the controller do when conditions break normal limits?

For a PMSM drive, the critical fault scenarios include short circuits in the inverter legs, phase loss, DC-link collapse, overcurrent events, over-speed, and sensor failures. On a physical bench, forcing a short circuit through an inverter leg stresses devices, varies run to run, and risks catastrophic damage. In HIL, the same fault is a scripted, perfectly repeatable event.

A typical scripted scenario shows the power of the approach: the test runs normally, then at exactly 5 seconds a short-circuit fault is injected. The controller’s protection logic should detect the overcurrent and shut off the PWM within its specified response time. Because the fault triggers on a timestamp and the plant is deterministic, the test verifies not only that protection fires, but that it fires fast enough and recovers cleanly — every single run.

This is impossible or prohibitively dangerous with real hardware, but straightforward and safe with HIL. It is one of the strongest arguments for adopting HIL testing for electric motor control.

Test Automation and Continuous Integration

The final piece of the workflow is automation. Once a HIL bench is safe and deterministic, motor control testing can join the same continuous-integration (CI) practices that software teams have used for decades — something that was traditionally impossible for power electronics because lab testing was too slow and expensive to run on every code commit.

With Impedyme PowerHIL Studio orchestrating the bench, engineers can build automated test campaigns using a scenario and sequence editor: drive cycles, ramps, step changes, and fault scenarios, with automated pass/fail criteria and reporting of key metrics such as current ripple, torque ripple, efficiency, and protection response. PowerHIL Studio also enforces built-in safety and limit management with configurable current, voltage, and power limits and controlled shutdown.

A mature motor control CI workflow looks like this:

• Baseline comparison: Each HIL run is compared against the desktop simulation reference, with a defined tolerance — for example, results must match the reference within 10%.
• Requirements verification: Every named requirement is checked automatically and linked back to its test case.
• Commit-triggered testing: When a developer commits new control firmware, the CI system automatically builds it, deploys it to the controller, and runs the HIL test suite — providing feedback in minutes instead of weeks. 
• Regression testing: The full suite runs on every change, catching unintended side effects and ensuring that a fix in one area does not break behavior elsewhere across the product lifecycle. 

Because the tests are scripted and the bench is safe, the whole suite runs unsupervised. Test execution that once took weeks in a power lab can complete in under an hour, and the same test assets remain valid from the earliest signal-level testing through full-power PHIL validation. 

The Impedyme Ecosystem for Motor Control HIL

What makes this workflow seamless is that Impedyme delivers every piece as an integrated ecosystem, so models and test assets flow from desktop simulation to full power without being rewritten.

• CHP Series real-time targets: FPGA-based HIL/PHIL platforms — the CHP 150 half-cabinet and CHP 300 full-cabinet — combining signal-level HIL and full-power, regenerative PHIL in one architecture, with simulation time steps as low as 90 nanoseconds and multi-channel analog, digital, and fiber I/O.
• MotorSim Studio: The high-fidelity motor and drive emulation environment, with model libraries for PMSM, induction, BLDC, and IPM machines, supporting nonlinear effects like magnetic saturation, hysteresis, and torque ripple, plus angle-dependent flux and torque maps.
• PowerHIL Studio: The orchestration and automation layer that configures hardware, scripts test campaigns, coordinates multi-emulator setups, and generates reports — all from a single MATLAB-integrated environment.
• FPGA Scope: Built-in, sub-microsecond signal visualization with up to 16 channels and trigger-based capture, embedded directly in the FPGA signal path — no external instruments required.
• HIL/RCP-Box: A compact rapid control prototyping platform with a user-programmable Ultrascale+ FPGA and dual-core ARM processor, closed-loop control up to 250 kHz, resolver/encoder interfaces, and CAN/CAN-FD — ideal for early-stage controller development and signal-level motor emulation. 
• Impedyme-RT: The real-time engine that connects model-based design tools directly to the hardware, with automatic code generation and one-click deployment to CPU, FPGA, or hybrid execution. 

Together these components enable Combined Hardware-in-the-Loop and Power (CHP) testing, letting engineers validate control logic and power electronics simultaneously.

This same platform extends naturally to adjacent validation challenges. Teams working on motor control HIL often also need BMS HIL testing for battery management systems, full EV powertrain HIL for system-level validation, and inverter testing at full traction power — all of which run on the same CHP Series hardware and software ecosystem.