How to simulate modular multilevel converters in real time

Key Takeaways

• MMC control validation stops being credible once cell-level states are averaged away.
• Full-count real-time simulation depends more on partitioning and timing discipline than on a headline cell limit.
• Submodule-level execution matters most when you must verify balancing, protection response, and closed-loop hardware timing.

Accurate real-time MMC simulation depends on modelling enough submodules to expose the control and balancing behaviour you’ll see in hardware.

That requirement matters because MMCs sit inside grid applications where missed timing and hidden capacitor spread carry expensive test risk. Annual grid investment will need to rise from about USD 300 billion to more than USD 600 billion by 2030, which puts pressure on validation teams to move faster without giving up electrical detail. Early control work can start with reduced models. You can’t stop there if your goal is closed-loop proof that a controller will hold cell voltages, arm energy, and protection timing where they belong.

An MMC converter stacks submodules into each phase arm

An MMC converter builds each phase leg from two arms, and each arm contains many repeated submodules plus an arm reactor. Every submodule stores energy in its capacitor and switches between inserted and bypassed states. That structure is what gives the converter fine voltage steps. It is also what makes detailed simulation expensive.

Picture a three-phase converter with six arms and 250 half-bridge cells in each arm. Your controller does not command one large switch. It decides which cells must be inserted so arm voltage, circulating current, and capacitor distribution stay controlled. Each cell carries its own capacitor voltage state, and those states drift apart unless your balancing method keeps correcting them.

You’re not just simulating a power stage. You’re simulating many small energy stores linked through arm current. That is why an MMC converter behaves differently during start-up, power reversal, or blocked-gate events. A model that ignores the cells can show terminal power, yet it won’t show the cell-level behaviour your controller must manage.

Real-time limits come from the submodule count

Real-time limits show up when the solver must update hundreds or thousands of switching states before the next sample closes. Every added submodule brings another switching state, capacitor voltage, and gate command that the solver must resolve before the next time step closes. General-purpose CPU solvers run out of margin first. MMC scale is the reason.

Published MMC reviews describe HVDC designs with 200 to 400 submodules per arm, or 1,200 to 2,400 cells in a three-phase converter. A model at that size must update capacitor voltages, insertion states, arm currents, and control I/O under a hard deadline. Miss that deadline and the run is no longer real time, even if an offline replay still looks plausible.

A lab setup with a controller sampled at 50 microseconds shows the problem clearly. A reduced model might execute comfortably on a CPU. A full-count switching model with balancing and fault logic can’t fit the same budget without parallel hardware. The limit comes straight from how many electrical states you keep active.

“Every added submodule brings another switching state, capacitor voltage, and gate command that the solver must resolve before the next time step closes.”

Averaged models hide capacitor voltage ripple under control

Averaged models will show arm currents and terminal power, but they hide the cell-level ripple and sorting behaviour that balancing logic must handle. They smooth switching action into continuous variables. That makes them useful for early control design. It also removes the exact signals many MMC tests depend on.

You can tune an outer active and reactive power loop with an arm-averaged model and get stable results quickly. Trouble starts when you test capacitor balancing during a power step, a DC voltage disturbance, or a block and restart sequence. Those events redistribute energy from cell to cell. A smoothed model cannot show the voltage spread that forces your sorting logic to work harder on some cells than others.

This matters most when control acceptance depends on limits rather than averages. A mean arm voltage can look fine while a handful of cell capacitors drift beyond your allowable band. You’re then validating the wrong thing. Averaged models still have value, but mostly earlier in the flow, before you need proof that submodule states remain controlled.

Switching detail should follow the control question asked

The right model fidelity depends on what your controller must prove, not on a fixed rule about detail. Some tasks need only arm-level energy trends. Others need every inserted and bypassed state. You’ll waste time with too much detail early. You’ll miss failure modes with too little detail late.

A current regulator check can start with averaged arms because you’re looking for loop stability and gross power response. A capacitor balancing check needs full switching detail because the controller acts on cell order and voltage spread. Protection timing belongs there too, since blocked-gate behaviour depends on stored energy paths and individual cell states an averaged model will hide.

The useful question is simple: what hidden state could invalidate your controller result? Once you answer that, model choice gets narrower. You don’t need every cell for every test. You do need every cell when the control law or protection logic depends on cell-level truth.

How do you simulate an MMC at full count

You simulate an MMC at full count by separating the fast electrical work from slower supervisory tasks and keeping every submodule state active in the loop. The model must preserve switching events, capacitor updates, and controller I/O at deterministic sample times. Full-count execution is a partitioning problem first. It is a solver problem second.

A practical setup starts with the exact arm topology, cell count, and submodule type. OPAL-RT is used for this kind of execution because the fast switching network can be resolved in parallel while the controller interface stays synchronized. That matters when you’re feeding a physical controller with gate commands, measurements, and fault signals that must land on time. If one side runs late, the test loses value even if the waveforms still look smooth on screen.

• Fix the arm topology and full submodule count before any tuning starts.
• Assign hard sample times for power stage updates and controller exchange.
• Keep each capacitor voltage as an active state in the execution flow.
• Inject disturbances that force balancing logic to reorder inserted cells.
• Check timing margins before trusting any closed-loop result.

That sequence keeps the model honest. It also stops a common mistake where engineers tune control on a reduced plant and only later find that the detailed plant needs different timing, gain limits, or balancing thresholds. Full-count simulation works best when it is treated as the target test platform from the start.

CPU to FPGA partitioning sets submodule simulation speed

CPU and FPGA partitioning decides whether a full-count MMC model will meet its time step or miss it. CPUs handle supervisory control, communication, and slower network tasks well. FPGAs handle repeated switching operations in parallel. MMC submodules fit that parallel pattern almost perfectly. That is why partitioning matters more than raw processor clock speed.

Consider a setup where your outer controller runs every 50 microseconds but your submodule network needs updates near the microsecond range. A CPU can manage the slower control layer and system coordination. The FPGA side can update inserted states, arm sums, and capacitor voltages for many cells at once. That split keeps switching detail without forcing a single serial path.

You should treat the partition boundary as an engineering choice, not a software convenience. Put too much on the CPU and execution slips. Put too much on the FPGA and model maintenance gets harder. Good partitioning keeps the fast repetitive physics close to parallel hardware and the configurable control logic where you can still iterate quickly.

How many submodules can a real-time model include

The number of submodules you can include in real time depends on fidelity, sample time, fault logic, and I/O, not on a single published limit. A stripped model can support many more cells than a protection-heavy HIL setup. The honest answer starts with the test objective. It ends with measured timing margin on the target platform.

A small research setup might carry 50 cells per arm with detailed switching and good timing margin on modest hardware. A utility-scale study might need 300 or 400 cells per arm, blocked-state logic, balancing, arm reactors, and a physical controller connected through analogue and digital I/O. Those are different problems, even though both are called MMC simulation. Cell count alone tells you very little.

You’ll get a useful answer only after defining four items clearly: submodule type, fixed step size, control coupling, and test disturbances. Once those are fixed, timing tests will show if the model fits. Engineers who ask only for a maximum cell count often miss the harder question, which is how much electrical truth must stay present while every step still closes on time.

Full cell count exposes balancing behaviour before hardware tests

Full cell count matters when controller quality depends on cell-to-cell states. You can tune average current loops on reduced models, yet you can’t sign off balancing, blocked-gate response, or energy spread until every submodule is present. Hardware issues usually start in those hidden details. That is why detailed real-time execution earns its cost.

A balancing algorithm can look clean in an averaged plant and still fail once a few capacitors drift, insertion order changes, and circulating current rises during a disturbance. The same applies to restart tests after a block command. If the model does not carry each cell, you’re accepting blind spots where MMC control becomes difficult. Full cell count matters when you need to trust balancing logic before first hardware energization.

This is the practical standard many labs are moving toward, and OPAL-RT fits it because the converter is resolved at the submodule level in real time instead of being masked behind arm averages. You end up with a stricter validation flow and a more useful one. The result is a controller that has already faced the electrical details it will meet on the bench.

“Full cell count matters when you need to trust balancing logic before first hardware energization.”