Customer Insights
Authors:
16-minute read
Our motor control group at Eaton is responsible for designing, developing, and testing high-quality control software for variable frequency drives and other motors (Figure 1). For decades, much of this software was coded by hand. Although our legacy codebase has proven its reliability across multiple applications in our electrical, aerospace, and mobility sectors, we faced significant challenges as we looked to deploy it on new hardware platforms and extend its use across different operating environments, including AUTOSAR®, bare-metal, and real-time operating system (RTOS) implementations. The original developers were no longer with the company, and design documentation was sparse. Further, the code’s complex architecture made substantive modifications both time-consuming and risky.
Figure 1. Control diagrams for a permanent magnet synchronous motor (PMSM) and a brushless DC (BLDC) motor.
These challenges coincided with a broader organizational initiative to adopt Model-Based Design across our engineering teams. Our team viewed this transition as an opportunity to address our immediate technical hurdles and fundamentally improve our development process for motor control software. The prospect of faster feature development, along with automation, software portability, robust processes, and the creation of reusable software components, addressed our key requirements for modernizing our motor control software.
Working with MathWorks consulting engineers, we began a systematic conversion of our legacy motor controller software to Model-Based Design by using MATLAB® and Simulink®. Early in the process, it became clear that a brute-force, one-to-one translation of the existing codebase would not only fail to capture the architectural intent of the system but could also introduce long-term maintainability and scalability problems. Using an iterative approach instead, we explored different conversion strategies—including bottom-up, top-down, and center-out approaches—to find the best path forward given our specific code architecture challenges. The transition has yielded significant benefits: improved development efficiency, better visualization and communication across teams, and a foundation for creating a clean software architecture and a Software Platform Library that enables reuse of validated algorithms across multiple projects and sectors within Eaton.
In deciding to transition to Model-Based Design, we needed to consider several critical factors carefully. First, we had to determine whether it would be better to start from nothing or gradually convert the existing code to models. Second, we needed a development team that had experience with both Model-Based Design and manually coded software. Engineers with this combination of skills can understand how an algorithm has been implemented in legacy code and then reimplement it efficiently in Simulink. Third, we recognized that due to the inherent differences between manually coded software and software developed using Model-Based Design, algorithm implementation would vary at both architectural and component levels, presenting challenges in integration and model-in-the-loop (MIL) testing.
Given the size of our legacy codebase (114 C files and 183 header files), the proven reliability of this code, and the need to maintain continuity in our development process, we opted for a gradual conversion approach. We assembled a team of engineers experienced in both manual coding and Model-Based Design and engaged MathWorks Consulting Services for support.
To minimize potential pitfalls—including the challenges related to differences between handwritten and generated code—our goal was to produce a converted Model-Based Design implementation that featured a clear signal flow from left to right, with naturally connected functions working together as an integrated system. Each smaller block would represent a distinct function, and the interfaces between components would be well-defined and traceable (Figure 2). However, achieving this clean architecture from our legacy implementation would prove more challenging than we initially anticipated.
Figure 2. An efficient conversion process in which code functions are converted to modular Simulink blocks, and those blocks are linked together with a clear signal flow.
Our initial conversion strategy followed a bottom-up approach. The idea was to sort the existing code into application functions—those directly implementing the motor controller’s algorithms or supporting its input/output processing—and non-application functions, such as error logging, diagnostics, task scheduling, and other utilities that do not influence the controller’s logical behavior. With this separation in place, we began systematically converting individual functions into Simulink models. We would implement data types in Simulink data dictionaries, develop template and skeleton models, and build a Simulink library of converted components. Once we had converted the individual functions, we would connect them to create the complete system-level model.
As we worked through the code, this approach exposed a fundamental structural limitation. Relatively few of the functions in the code were implemented as tightly encapsulated units that accepted arguments and returned a result to the calling function. Rather, many functions directly accessed global data structures, including structures for configuration and status results, and simply returned void. In the system-level model, these widely used global structures were represented as buses. With this model architecture, tracing data flow between components and determining the effective sequence of function execution was impractical (Figure 3). Further, even after converting functions to models, the total number of required buses could not be determined without analyzing the entire codebase.
Figure 3. Widely used global buses throughout the code made it difficult to trace data flow.
Given these challenges, we next pursued a top-down strategy using System Composer™ (Figure 4). Our goal was to assess whether a system-level architecture model could meaningfully clarify signal flow between components while incorporating the individual function models we had already converted. However, the same global structural issues with the code made it difficult for us to confidently validate that the system-level model accurately represented the actual behavior of the original controller.
Figure 4. A top-down approach using System Composer to define system architecture and component interfaces.
It is important to note that the bottom-up approach can be highly effective for some legacy code conversions, particularly those with well-encapsulated functions and limited use of global data structures. Likewise, a top-down approach may be a better fit for new projects or those based on clearly defined architectures with, again, less reliance on global data. For this particular project, neither a purely bottom-up nor a purely top-down approach was viable; we needed a different strategy.
Ultimately, we adopted a hybrid approach in which we started the conversion with a core component and gradually expanded outward. We began by identifying the core voltage-frequency (VF) control algorithm—the heart of our motor controller—as the starting point. We then identified all the functions that directly fed inputs to this core controller or received outputs from it, converted these functions to models, and wrapped this initial group into what we called the “core system.” This core system interfaced with the rest of the legacy codebase through the existing global structure buses by using a wrapper model (Figure 5). Critically, this approach allowed us to test and validate the converted core while maintaining compatibility with the unconverted portions of the code.
Figure 5. A core system of Simulink models with clear, well-defined connections, interfacing with still-to-be-converted C code functions.
From there, we followed an iterative process. We identified the next layer of functions in the direct hierarchy of the core system, converted them into models, and incorporated them into the expanding core system. With each iteration, more functionality moved inside the converted core. This approach established a clear direction for continuing the conversion work, with the eventual goal of incorporating all application-layer components and eliminating the global structure buses.
This incremental center-out strategy proved to be well-suited for this project and its codebase. It enabled us to expand the scope gradually without disrupting production. Further, we could test at each step of the process, ensuring that the growing Model-Based Design implementation maintained the same behavior as the original manually coded system.
Throughout this conversion process, we gained valuable insights that extended beyond the immediate project. Each approach we explored—bottom-up, top-down, and center-out—played an important role. The bottom-up work helped us identify Simulink interfaces and establish our initial workflow. The System Composer exploration gave us tools to define system and software architecture. And the center-out approach provided a robust methodology for incremental conversion.
This effort positioned us well to pursue a broader initiative: creating a Software Platform Library (SPL) for Eaton. The SPL concept centers on developing a repository of reusable Simulink blocks with complete V-model artifacts, including requirements, unit test coverage, and integration tests. The library focuses on common algorithms and application functions that are heavily used within and across sectors, with components designed to be agnostic to hardware and base software layers (Figure 6). As we began work on the SPL, two parallel motor control projects were underway that used many of the same algorithms, which helped us identify exactly which components qualified for the SPL. Using System Composer, we could define which components should be standardized in the SPL and which could remain specific to the project. This collaborative approach, enabled by the visual nature of Model-Based Design, would have been far more difficult with handwritten code. Understanding others’ implementations would have required significantly more time and effort.
Figure 6. The Software Platform Library provides a repository for common algorithms and application functions modeled in Simulink.
The transition to Model-Based Design also significantly enhanced our testing capabilities. Previously, we had very little unit and system testing in simulation and relied primarily on hardware-in-the-loop and system-level simulation, which meant extensive debugging when issues arose. Now, we can perform MIL testing using plant models derived from the existing handwritten code projects, validating algorithm behavior before deployment to hardware (Figure 7).
Figure 7. MIL test results plotted in MATLAB.
Beyond testing improvements, the visualization capabilities of Model-Based Design have transformed how engineers interact with the motor control system. Previously, understanding the system required navigating numerous code files with sparse documentation. Now, models can be directly shown to any engineer to explain system behavior and interactions. Combined with our iterative approach, this foundation supports continued expansion to protection layers, supervisory layers, and additional components. The result is improved development efficiency, better communication across teams, and a maintainable platform for accelerated motor controller development across Eaton’s diverse product lines.
The authors would like to acknowledge the contributions of Li Dang of MathWorks to this project.
Published 2026
