Simulating an LLC resonant converter in real time

Key Takeaways

• Real-time simulation of an LLC resonant converter only holds up in HIL when the solver resolves switching-state changes instead of smoothing them into a fixed network.
• Multi-phase resonant operation is a coupled electrical problem, so cross-phase terms must be recomputed during each step if you want believable current balance, protection response, and timing margins.
• Latency budgets should set the first screening rule for solver choice, but timing closure only matters when the model still preserves resonant boundary waveforms and commutation order.

Accurate real-time simulation of an LLC resonant converter requires a solver that resolves every switching state and every phase interaction.

That requirement matters because high-frequency power stages now sit inside chargers, power supplies, and vehicle platforms that must be validated before hardware is tuned. Global electric car sales reached more than 17 million in 2024, which widened the need for dependable converter test workflows across transport and charging systems. Generic averaged models can support early sizing. Closed-loop HIL work will only hold up when the solver follows the resonant tank, commutation events, and cross-coupling as they happen.

Why LLC converters are hard to simulate in real time

LLC converters are hard to simulate in real time because their equations switch with every commutation event, their gain shifts with frequency, and soft switching depends on operating point. A coarse model will still execute quickly. It won’t preserve the behaviour that your controller actually sees. That gap is what makes resonant converter HIL testing difficult.

Consider a battery charger that sweeps switching frequency to hold output during a mains sag. The tank current, magnetizing current, and rectifier conduction pattern all shift within a few cycles. A model built from a single averaged transfer function will smooth over those shifts. Your controller looks stable in the simulator, then chatters when hardware reaches the same corner case.

Start-up shows the same problem. The converter can pass through hard-switching pockets before it settles into zero-voltage switching, and those pockets set stress on devices and sensing paths. If the solver ignores mode boundaries, gate timing tweaks will appear harmless. Bench work will prove otherwise.

Accurate models must resolve each switching configuration

Accurate LLC models must resolve each switching configuration because the circuit seen by the resonant tank changes when switches, diodes, and rectifiers commutate. Each state has its own differential equations. State sequencing also depends on load current. A solver that assumes one fixed network misses that causality.

Take a full-bridge LLC stage feeding a regulated bus through synchronous rectifiers. During one interval, the tank sees the input source and transfers energy to the load. A moment later, secondary current freewheels and the magnetizing branch carries the transition. Those are separate electrical problems, so they must be solved as separate states.

That state resolution matters most near resonance and near light load. Small changes in dead time or device capacitance can shift the order of events, which alters zero-voltage switching margins. Control loops that depend on current zero crossing will only tune well when those transitions appear at the right instant. You aren’t chasing detail for its own sake. You are protecting the test from false stability.

Resonant tank dynamics set the minimum useful timestep

The resonant tank sets the minimum useful timestep because its current and voltage can swing much faster than the outer control loop. A timestep that looks acceptable for output regulation will still blur the tank trajectory. Once that happens, phase error enters every commutation estimate. Timing fidelity drops before average voltage looks wrong.

Picture a server supply running above resonance during light load, then dropping toward resonance as load rises. Tank current peaks sharpen as the switching frequency moves, and the magnetizing branch injects its own slope. If the timestep skips over those peaks, the model will understate device stress and misplace zero crossings. That error feeds straight into your HIL controller response.

Useful timestep selection also depends on what you need to validate. Average output voltage can tolerate a rougher step than synchronous rectifier turn-off timing. Thermal studies, fault insertion, and protection checks each care about different waveform details. You should size the timestep from the fastest important event, then confirm that the execution budget still closes.

Multi-phase LLC stages create coupled resonant states

Multi-phase LLC operation creates coupled resonant states because each phase shares part of the electrical system even when each tank looks local on a schematic. Shared buses, magnetics, and load paths tie the phases together. One phase event will shift the initial conditions seen by the next phase. A separate per-phase model won’t represent that interaction.

A three-phase charger module makes this easy to see. Phase A can refill a shared output node while Phase B enters a freewheel interval and Phase C commutates into conduction. The shared node voltage moves during those transitions, so none of the three tanks is solving against a fixed boundary. That coupling alters current balance and device stress.

Interleaving helps ripple and filter size, yet it also creates more paths for error when the model is simplified. A phase that appears balanced in a decoupled simulation can drift once shared parasitics and timing offsets are present. Lab teams often see one phase heat more after a firmware change. Sometimes the model removed the interaction that caused the imbalance.

Cross-phase coupling must be recomputed at each step

Cross-phase coupling must be recomputed at each step because the coupling terms depend on the exact conduction state of every phase. Fixed coupling matrices only work when the network topology stays unchanged. Resonant converters do not behave that way. Their shared paths open and close every switching cycle.

Consider a three-phase LLC stage with a common secondary bus and phase shedding under light load. When one phase drops out, the remaining phases inherit new boundary conditions and circulating current paths. A high-speed converter solver inside OPAL-RT handles that case by re-solving the active network at each step instead of freezing the coupling structure.

You can see the payoff during HIL fault tests. A short dip on one phase gate signal will disturb the other phases through the shared bus, and the disturbance can last longer than the original fault. Protection code that looks clean in a decoupled model can overreact once that cross-coupling is present. Recomputing the coupling terms turns that hidden path into a measurable signal.

“Recomputing the coupling terms turns that hidden path into a measurable signal.”

Fixed topology solvers miss key HIL test behaviour

Fixed topology solvers miss key HIL test behaviour because they preserve a circuit structure that the converter does not keep. That simplification hides commutation order, freewheel intervals, and boundary shifts under load. HIL then validates the controller against a gentler plant than the one on the bench. The mismatch shows up late, when debug costs more.

Published LLC converter reviews report peak efficiencies up to 98%. That narrow loss budget means timing errors matter. A solver that smears a short hard-switching interval can understate heating, overstate zero-voltage switching margin, and hide why a device pair fails qualification.

Bench symptoms usually appear during mode boundaries. A converter that passes a steady load test can stumble during burst entry, synchronous rectifier turn-off, or a rapid load release. The issue isn’t simulator speed alone. The issue is speed spent on the wrong mathematical problem.

Control validation needs waveforms near resonant boundaries

Control validation needs waveforms near resonant boundaries because that is where frequency control, dead time, and rectifier timing interact most strongly. Steady nominal points rarely expose the weak spots. Boundary waveforms do. They show the moments when stable code starts acting on misleading feedback.

A common case appears during a sharp load release. The controller pushes frequency upward, magnetizing current persists, and the secondary devices can see an awkward handoff between conduction paths. If your model smooths that handoff, current limiting, burst logic, and synchronous rectifier timing can all look cleaner than they are. Hardware will answer with extra ringing, false trips, or missed soft switching.

Boundary testing also gives you better evidence for calibration. Current probes, timing captures, and firmware logs line up more clearly when the simulation reproduces the same event order. That makes disagreement useful instead of confusing. You can trace a bad threshold or dead time setting to a visible waveform cause instead of guessing at loop tuning.

Solver selection should start from latency budgets

Solver selection should start from latency budgets because a faithful model that misses the execution deadline is useless, and a fast model that skips resonant state changes is misleading. You need both timing closure and circuit fidelity. That balance sets the value of every HIL test. It should be your first filter.

A practical screen is short and concrete.

• Match the timestep to the fastest switching event you need to validate.
• Confirm the solver reconfigures equations when conduction paths change.
• Check that shared nodes and magnetics are solved across all active phases.
• Measure total I/O and controller latency against the simulation step.
• Test one boundary case before scaling the model across the full bench.

Teams usually regret the model that looked convenient during setup and vague during debug. 

“The better choice preserves the event sequence you’ll later compare against scope traces and firmware logs.”

That is why OPAL-RT focuses on solving three-phase LLC coupling directly when the converter itself is the hard part of the test. Careful solver selection saves lab time.