Combining Model-Based Systems Engineering and Model-Based Design to Accelerate Electric Drivetrain Development

Across the electric vehicle (EV) and eMobility industry, the engineering teams responsible for electric drivetrain development face a number of common challenges. These not only include increased product complexity, but also the need to deliver high-quality products faster while containing costs and ensuring process compliance with ASPICE, ISO^® 26262, and other standards.

To address these challenges, we had a once-in-a-career opportunity at eMoveUs to combine our employees’ extensive experience in eMobility with the greenfield start of a new company. We established a lean development process with a consistent toolchain that addresses the drawbacks we had seen within previous approaches.

After a thorough assessment of the options available, we adopted a workflow that combines model-based systems engineering (MBSE) and Model-Based Design using MATLAB^® and Simulink^® products together with Polarion™ application lifecycle management (ALM) software. The system engineering process according to ASPICE can be seen in Figure 1. This workflow already has proven advantages in several areas. It enables us to work from a single source of truth and achieve substantial reuse of work products across disciplines and projects. Furthermore, it enables our engineers to focus on feature development rather than process satisfaction while establishing traceability from requirements to architectures, models, code, and tests. Importantly, it also enables us to apply the “shift-left” paradigm to systems engineering, making it possible to analyze dynamic system behavior at the system level and, in particular, identify specification errors early in the overall process.

System Architecture Modeling with System Composer

In classic product development processes, system specification errors are often first identified when prototypes are available and when they are tested against the system specification. This usually causes high error correction costs and partially leads to critical delays in the project. In order to avoid these additional and unpredictable costs due to specification errors at the system level, we aim to verify the correctness of the specification as early as possible in the process. In our workflow, we use System Composer™ to define simulatable system architectures, which enable us to “shift left” test and validation activities and automate them with CI pipelines, which is also outlined in Figure 1.

Furthermore, we maintain a one-to-one mapping between system components and their corresponding software architecture components in System Composer and Simulink, making it possible to analyze dynamic behavior at the system level. Thus, system-level behavioral models can be used as a draft by software engineers, who not only reuse the interfaces but also the behavioral models defined in the system architecture as a starting point when developing detailed designs for software production in Simulink. In addition, there exists a high reuse of simulation models and environments that are used across departments. For example, the same plant model for closed-loop simulations and tests is used in the system, hardware, and software department and is also capable of running directly on our Speedgoat^® HIL system in real time. A schematic describing the dependencies is outlined in Figure 2.

Additionally, we use Requirements Toolbox™ and the Polarion Connector for Simulink to link the requirements managed in Polarion with architectural elements defined in the System Composer models. We also link the detailed design elements within Simulink models of the software implementations using this connector. This setup enables bidirectional traceability between specification and implementation with no manual synchronization, facilitating collaboration between multidisciplinary teams and helping to ensure consistency across the development cycle.

Physical Modeling with Simscape

Closed-loop simulations at the system, software, or hardware level require a physical model of the electric vehicle powertrain. We created this model within Simscape™ and Simscape Electrical™. A high-level view can be seen in Figure 3. This multidomain model includes modular components for the drivetrain’s battery, DC cable, electromagnetic interference (EMI) filter, inverter, AC busbar, electric drives, load models, and cooling. Within this model, we can also incorporate reduced-order models for thermal and electromagnetic effects coming from CAE tools like Ansys Maxwell to preserve the intended simulation times.

To enable our engineers to select the fidelity level for any component of the current simulation use case, we implemented a variant management system using model variants. For example, using Variant Manager for Simulink, a team might choose to run basic simulations with a variant block that models the battery as a simple constant voltage source. Later, they might switch to the battery’s RC or RL circuit variants to examine low-frequency capacitive behaviors or high-frequency inductive behaviors, respectively. Similarly, our engineers might use a simple controlled voltage source variant for the inverter to speed up simulation or select a higher fidelity variant with a realistic switching behavior to assess PWM effects. An example of handling these variants in the Variant Manager is outlined in Figure 4.

Closed-Loop Simulation, Code Generation, and Real-Time HIL Testing

With the system architecture outlined in System Composer and the detailed plant model in place, it is possible for us to run closed-loop simulations at multiple levels using system behavior models, software architecture models, or detailed design models in Simulink, as shown in Figure 5.

It enables us to “shift left” our validation activities that are already at the system level, thus minimizing specification errors of complex drive system functions.

Within this environment we are able to analyze the behavior of the product at the system level by using MATLAB, as well as the Data Inspector, to visualize signals, performance metrics, and timing relationships. An example of the closed-loop simulation results of our system architecture for analyzing the current control behavior of a field-oriented controller can be seen in Figure 6. Automated tests can be executed in this closed-loop setup at the system level or for dedicated architectural components using Simulink Test™. Furthermore, these test results are automatically synchronized back to Polarion to enable up-to-date project tracking and reporting against the test case specification.

This consistent development approach does not stop at the domain boundaries but continues further. As we move to the domains in the V-cycle, progressing from system specification to software specification, architecture, Model-Based Design, and implementation, the next phase of our workflow includes code generation as well as MIL, PIL, and HIL testing. Here, we use Embedded Coder^® to generate code from our software architecture or detailed design models in Simulink, integrate it into an AUTOSAR^® stack, and deploy it to an Infineon^® AURIX™ TC3xx microcontroller. The already presented plant model is then deployed to an FPGA on a Speedgoat real-time target machine using HDL Coder™ and Simulink Real-Time™. This setup is able to verify the correct software behavior of the final product on a HIL. Furthermore, in order to utilize synergies and reduce equipment and development costs, the same HIL platform is used to perform system integration and verification tests before the final tests on a test rig are done.

Realized Benefits and Ongoing Integration Improvements

The workflow and toolchain approach were validated during our development of an 800 V silicon carbide–based inverter, capable of delivering up to 600 kilowatts of peak power for automotive traction drive applications. Participation in the MathWorks Startup Program helped us shorten the time to market for this product while keeping costs down, which is imperative for virtually all startups.

We are continuing to extend and improve our workflow. For example, we are already using CI with Jenkins^® and Bitbucket^® to continuously perform software unit, integration, and verification tests. We are also working on extending this CI-based automation workflow further up the V-cycle to enable automated CI-based verification of our system architectures.