The Tower of Babel in Electric Motor Design — And How to Tear It Down

The Invisible Wall Between Electric Machines and the Software That Controls Them

Every electric motor in a modern electric vehicle, a wind turbine, or an industrial robot is governed by two separate worlds that rarely speak the same language. There's the physics world — the spinning rotor, the magnetic fields, the voltage pulses — and there's the control world, the software that tells the motor how fast to spin, when to accelerate, and how to manage its temperature. Designing these systems should be straightforward: build each piece, connect them, test. In practice, it resembles trying to assemble furniture from five different manufacturers using tools that don't quite fit.

The problem is interoperability — the ability of different software systems to work together. In electric drive development, this manifests in a particular frustrating way. An engineer might write a machine model in Python for quick prototyping, while a colleague builds the controller in C for real-time performance, and another team prepares Hardware-in-the-Loop testing in a specialized HIL simulator. Each piece works beautifully on its own. Put them together, and suddenly you're spending weeks translating between them, rewriting code, and losing confidence that your simulation actually reflects reality.

This is the problem Ajay Pratap Yadav addresses in a new paper published on arXiv. His solution isn't a new simulation tool or a better programming language. Instead, he demonstrates how an existing framework designed for massive infrastructure simulations — originally built for power grids and smart cities — can serve as a universal translator for electric drive development. The results suggest a future where swapping a Python prototype for a C implementation requires changing two lines of code rather than rebuilding an entire integration layer.

The core insight is deceptively simple: instead of forcing all components into one simulation environment, let each component run in its native environment and use a coordinator to pass messages between them. The coordinator, built on a framework called HELICS, handles the delicate work of synchronizing time across different simulators and ensuring that data arrives in the right order. This is not a new idea in principle, but Yadav's application to electric drives demonstrates its practical utility for a domain that desperately needs it.

The Science

The work centers on co-simulation — a approach where multiple simulation programs run simultaneously, exchanging data at defined intervals to create a unified representation of a complex system. Co-simulation contrasts with traditional monolithic simulation, where everything must be expressed in a single modeling framework. For electric drives, this distinction matters enormously because the field spans multiple physical domains (electrical, mechanical, magnetic) and requires different levels of fidelity for different components.

Yadav builds his framework on HELICS — the Hierarchical Engine for Large-scale Infrastructure Co-Simulation. HELICS was originally developed at Pacific Northwest National Laboratory for large-scale power system analysis, particularly for studying how distributed energy resources like solar panels and battery storage interact with the electrical grid. Its design philosophy centers on treating each simulation component as an independent "federate" that publishes and subscribes to data values, with a central broker managing the timing and routing of information between federates.

The electric drive Yadav uses as his demonstration case is a permanent magnet synchronous motor — a type of motor that uses permanent magnets rather than electromagnets to generate the magnetic field in the rotor. PMSMs are ubiquitous in electric vehicles and industrial applications because they offer high efficiency, compact size, and precise speed control. The motor is powered through an inverter — a device that converts direct current from a battery into the alternating currents that drive the motor windings.

Control of the motor uses a strategy called field-oriented control, which transforms the three-phase AC currents in the motor windings into a rotating reference frame that simplifies the mathematics of motor control. In this frame, the current can be decomposed into a component that produces torque and a component that produces magnetic flux. By independently controlling these components, FOC enables precise, responsive motor operation.

The system dynamics follow standard PMSM equations that relate the motor's electrical behavior to its mechanical behavior. The stator currents in the direct and quadrature axes evolve according to differential equations involving the applied voltages, winding resistances, and inductances, as well as the rotor speed through coupling terms. The rotor mechanical speed depends on the electromagnetic torque produced by the motor, the load torque applied externally, and frictional losses. These equations are well-established in the literature, dating to foundational texts on power electronics.

The inverter model Yadav uses for most of his analysis is a two-level PWM inverter — a device that rapidly switches the DC input voltage on and off to create a pulse-width modulated output that approximates a sine wave when filtered by the motor's inductance. This is the workhorse inverter topology for motor drives. He also includes an "averaged" inverter model that applies the voltage commands directly, without the switching dynamics, which is useful for faster simulation when the high-frequency switching details aren't important.

The FOC controllers use proportional-integral regulators — standard industrial control elements that adjust their output based on both the current error and the accumulated past error. The speed controller generates a torque-producing current reference, while the current controllers generate voltage commands that the PWM modulator converts to inverter switching signals.

What makes this setup interesting is not the individual components, which are well-understood, but how Yadav connects them. Each component runs as a separate HELICS federate. The plant federate — containing the machine model and inverter — publishes the motor currents and speed while subscribing to voltage commands. The controller federate does the inverse, subscribing to motor states and publishing voltage references. HELICS coordinates their execution, advancing time in 100-microsecond increments while the plant internally uses a finer 10-microsecond step for accurate PWM modeling.

Yadav demonstrates the framework with two studies. The first varies the controller while keeping the plant fixed: he compares a Python FOC controller, a C FOC controller, and a one-step model predictive controller (MPC) — all driving the same Python PMSM/inverter model. The second study varies the plant while keeping the controller fixed: three different machine models (nominal PWM PMSM, parameter-varied PWM PMSM, and averaged PMSM) each connect to the same C FOC controller.

What They Found

The headline result is straightforward: different implementations of the same algorithm, written in different programming languages, produce essentially identical results when connected through HELICS. The Python FOC controller and the C FOC controller driving the same PMSM model yield speed tracking performance that is indistinguishable within plotting resolution. Both achieve a root mean square error of 6.42 rad/s relative to the commanded speed profile, a final steady-state error of 0.62 rad/s, and peak quadrature current of 9.70 A.

This is significant because it validates that HELICS introduces no meaningful distortions to the control signals — the abstraction layer between federates is mathematically transparent. An engineer can prototype a controller in Python for rapid development and testing, then deploy the equivalent algorithm in C for real-time performance, with confidence that the behavior will carry over.

The model predictive controller, implemented in Python with a 600-microsecond prediction horizon and a 17-by-17 voltage command grid, produces slightly different results. Its RMSE increases to 7.32 rad/s, though its final steady-state error actually improves to 0.45 rad/s and its peak current rises to 10.52 A. This reflects the different control logic of MPC — it optimizes over a finite horizon rather than using simple PI feedback — and the results demonstrate that novel controllers can be introduced into the framework without modifying the plant model or the interface structure.

Controller Comparison: Same Plant, Different Algorithms

Label	Value
Python FOC	6.42
C FOC	6.42
Python MPC	7.32

RMSE measures speed tracking accuracy; final error is steady-state deviation from commanded speed

The second study demonstrates plant interchangeability. Three machine models with different parameterizations and fidelity levels all connect successfully to the same C FOC controller. The nominal PWM model achieves RMSE of 6.42 rad/s and final error of 0.62 rad/s. The parameter-varied model — using different stator resistance, inductances, magnet flux linkage, and inertia — yields RMSE of 6.56 rad/s and final error of 0.56 rad/s. The averaged model — which skips the PWM switching detail — produces RMSE of 6.94 rad/s and reaches the commanded speed exactly in steady state.

Plant Exchangeability: Same Controller, Different Models

Label	Value
Nominal PWM PMSM	6.42
Parameter-Varied PWM	6.56
Averaged PMSM	6.94

All models achieve comparable speed tracking despite different internal implementations

The current traces differ across models because each model uses different motor parameters, so direct comparison of current magnitudes isn't meaningful. What matters is that all three models respond appropriately to the same controller, track the commanded speed profile, and handle the load torque disturbance in similar fashion.

Peak Current Comparison Across Controllers

Label	Value
Python FOC	9.7
C FOC	9.7
Python MPC	10.52

C FOC and Python FOC produce identical current peaks; MPC shows higher peak current

Taken together, these results establish that the HELICS interface acts as a stable contract between controllers and plants. As long as federates publish the expected signals (current, speed, position on one side; voltage commands on the other), their internal implementation is irrelevant to the partner federate. This is the fundamental enabler for modular, collaborative development.

Why This Changes Things

Electric drive development currently suffers from a Tower of Babel problem. Large organizations building motor drives for electric vehicles or industrial automation typically involve multiple teams working in parallel. Controls engineers might prototype in MATLAB/Simulink for its symbolic math capabilities. Embedded software engineers implement the production controller in C for real-time constraints. Machine designers run finite element analysis in specialized tools. HIL testing happens in real-time simulators from companies like OpalRT or Speedgoat. Each transition between environments requires manual translation.

The cost of this fragmentation is substantial. Engineering time gets consumed by integration work rather than innovation. Errors creep in during translation between representations. The confidence that comes from testing the actual production code against the actual machine model is delayed until hardware is available, which is the worst possible time to discover integration issues. And the ability to rapidly explore alternative architectures — what if we tried a different control algorithm? a different machine design? — is hampered by the friction of re-integration.

Yadav's framework, by establishing a standard interface through HELICS, allows each team to work in their preferred environment while maintaining continuous integration with the broader system. The interface is not a new standard requiring industry adoption; it uses HELICS's existing publication-subscription mechanism, which supports typed, unit-aware data streams. A federate publishing "rotor speed in rad/s" is automatically understood by subscribing federates, with HELICS handling the routing.

The implications for development velocity are significant. Consider a controls engineer wanting to test a new algorithm against an existing machine model. In a traditional workflow, this might require obtaining the machine model in the engineer's preferred environment, potentially translating it, configuring a co-simulation, and validating the result. In Yadav's framework, the machine model could be a C++ federate maintained by a different team, running on a remote server, while the controls engineer works entirely in Python. The only requirement is that both federates agree on the signal contract — what variables are published, what variables are subscribed, and what units are used.

The Hardware-in-the-Loop angle deserves particular attention. HIL testing involves connecting real controller hardware to a simulated plant, allowing testing of the actual production controller software against a virtual machine. This is essential for validating embedded control code before building physical prototypes. The challenge has been that HIL simulators typically require specific interfaces and can't easily connect to the diverse models used in a development organization.

HELICS bridges this gap. The framework has already been used to interface with real-time simulation platforms like OpalRT, and Yadav's work extends this to electric drive applications. This means a controller developed and tested in software co-simulation can be moved to HIL testing with minimal changes — the interface remains constant. Controllers and plants can be independently swapped between software simulation, HIL, and eventually controller-HIL (where the machine is real but the controller is simulated), enabling a continuous validation pipeline.

The framework also enables something valuable for research: comparing algorithms on equal footing. When Yadav shows that Python FOC and C FOC produce identical results, he's not just demonstrating interoperability — he's establishing a methodology for fair comparison. A researcher proposing a new MPC algorithm can connect it to the same plant model used by colleagues working on traditional PI control, with confidence that any performance differences reflect the algorithms and not artifacts of different implementations.

What's Next

The current work is intentionally limited to software co-simulation — all federates run on conventional computers rather than real-time hardware. Yadav explicitly identifies extending to HIL targets as the next step, which is where the practical impact would be most pronounced. Demonstrating that the same interface works seamlessly between software-only simulation, HIL testing, and production deployment would validate the framework for industrial use.

There are also questions about scalability. The current demonstration involves one plant and one controller. Larger systems — such as multi-motor drivetrains, motor-drive-train-grid interactions, or comprehensive vehicle simulations with multiple subsystems — would require more complex broker hierarchies and careful management of timing. HELICS was designed for large infrastructure simulations, so this should be tractable, but specific application to multi-machine electric drive systems remains to be demonstrated.

The parameter variations in the paper are relatively modest — different stator resistances, inductances, and inertia values. A more severe test would involve fundamentally different modeling approaches. Could a finite-element machine model, which captures spatial variations in magnetic fields, co-simulate with a lumped-parameter controller through the same interface? Could electromagnetic transient models coexist with fundamental-frequency phasor models for hybrid simulation fidelity? These questions push toward the frontiers of what's possible with the approach.

Security and robustness of the communication between federates also warrant attention in production contexts. The current work assumes reliable local communication, but industrial deployment might require operation over lossy networks or with federates running on unreliable hardware. These concerns are not unique to this application, but they're essential for real-world adoption.

The bigger picture is that Yadav's work demonstrates a pattern that could propagate through electric drive development. By establishing a stable interface between components, he makes it possible to mix and match implementations, adopt new tools without abandoning existing investments, and maintain continuous integration throughout the development lifecycle. This is how software engineering evolved — from monolithic programs to modular architectures with well-defined interfaces — and it's how electric drive development could evolve too.

The electric motor is no longer the simple device it once was. It sits at the intersection of power electronics, advanced control theory, embedded computing, and increasingly, machine learning. Managing this complexity requires abstraction layers that let engineers focus on their specific domain while remaining connected to the larger system. Yadav's HELICS-based framework offers exactly this: a way to keep the pieces separate while ensuring they work together. Whether it becomes a standard practice depends on adoption by tool vendors, integration with HIL platforms, and demonstration on production-scale systems. But the foundation is solid, and the need is clear. The wall between electric machines and the software that controls them might finally be coming down.

For a field wrestling with the tension between increasing complexity and shrinking development cycles, this is genuinely good news. The future of electric drives — whether in vehicles, renewable energy, or industrial automation — depends on our ability to simulate, test, and refine them faster and more reliably. Yadav's framework doesn't solve that problem by itself, but it points toward an architectural approach that could. And in a world racing to electrify everything, that's the kind of infrastructure work that makes other progress possible.