Introduction
After introducing the Dual-Motor EV Traction platform and the Software & Hardware environment behind it, this article moves one step closer to the running application. It looks inside the Motor Control System and explains how the Simulink model is structured to control two PMSM motors using the NXP S32K396 MCU as the target hardware.
The goal is to provide a clear architectural view of the application before diving into simulation, validation, or deployment details. We will follow the main signal paths, from vehicle-level CAN commands and inverter feedback to FOC execution, PWM generation, ADC measurement, and communication back to the vehicle network.
The focus remains intentionally architectural. Instead of covering controller tuning, peripheral configuration, or low-level implementation, this article highlights the building blocks that make the dual-motor application understandable as a complete embedded control system.
This article is organized around five architectural views: the application overview, the system interfaces, the CAN communication path, the Simulink model structure, and the peripheral-to-data-flow mapping. Together, these views explain how the dual-motor application receives commands, measures feedback, executes control, drives the inverters, and reports diagnostic information back to the vehicle network.
Table of Contents
Application Overview
The Motor Control System is implemented on the NXP S32K396 microcontroller and runs as a single-core embedded application. The ECU controls two PMSMs, each connected to its own three-phase inverter stage.
From a control perspective, the application contains two Field-Oriented Control implementations. Each FOC instance is responsible for one motor and executes independently, based on its own sensing path, control states, and output generation.
Both control loops are scheduled from independent interrupt sources and are triggered every 100 microseconds. This execution period supports the fast current-control layer required by traction inverter applications, while the single-core implementation requires both motor-control paths to complete within the available timing budget.
Figure 3-1. Overall Simulink Application
At vehicle level, the Motor Control System behaves as a actuating end node. It receives enable and speed commands from the Central Node over CAN and sends back monitoring and diagnostic information at a slower periodic rate. The Motor Control System exchanges CAN data with the vehicle network through the South Zone Controller.
3.1. Control Strategy
At the heart of the application is the Field-Oriented Control algorithm, which provides the control structure required to drive each PMSM efficiently and independently. In this architecture, FOC transforms the three-phase motor behavior into a control problem handled in a rotating reference frame, where torque-producing and flux-producing current components are regulated separately.
The control strategy is built around speed control. The requested speed comes from the vehicle-level command interface, while the estimated rotor speed is provided by the sensorless observer. The speed controller compares these values and generates the current reference needed to reach the commanded operating point.
For each motor, the FOC structure combines an outer speed loop with inner current-control loops. The current PI controllers regulate the direct-axis and quadrature-axis currents in the rotating reference frame, allowing the application to control the electrical behavior of the motor in a deterministic and decoupled way.
Sensorless operation is achieved using an Extended EMF Observer. This observer estimates the rotor position and speed from the measured electrical quantities, removing the need for a physical position sensor in the control loop. The estimated position is then used by the Park and inverse Park transformations that connect the stationary and rotating reference frames.
The feedback path is based on phase-current reconstruction using the dual-shunt measurement method. The reconstructed phase currents are processed through the Clarke and Park transformations, while the DC bus voltage feedback is used to keep the control and modulation stages aware of the available inverter supply.
The two FOC implementations follow the same control structure, but each one operates on its own motor-specific inputs, states, and outputs. This separation allows Motor 1 and Motor 2 to be controlled independently, even though both algorithms execute on the same S32K396 device.
Because the control loops are executed every 100 microseconds, the FOC layer must remain compact and deterministic. The model architecture therefore separates the fast control path from slower communication and monitoring tasks, ensuring that current regulation and PWM update remain the highest-priority activities in the application.
Figure 3-2. Sensorless Field-Oriented Control diagram
System Inputs and Outputs
The application interface can be viewed through two categories of signals. The first category contains vehicle-level commands exchanged over CAN. These signals define how the traction application is started, stopped, and commanded from the rest of the vehicle. The second category contains real-time electrical feedback and actuation signals exchanged with the inverter hardware.
Figure 4-1. Split the Simulink model to Inputs, Outputs and Application layers
4.1. Inputs
The main vehicle-level inputs are received from the Central Node over CAN through the South Zone Controller. The command message contains the CCS_EnableMotors signal, used to engage or disengage the motors, and the CCS_SetSpeed signal, used to provide the desired speed reference for the control application.
Figure 4-2. CAN Message Unpack block for receiving the command signals
These CAN inputs are not part of the fast current-control loop, but they directly influence its behavior. Once decoded, the enable command defines whether the control logic is allowed to drive the inverters, while the speed reference becomes the target followed by the outer speed controller.
The hardware feedback inputs are acquired from the inverter stages through ADC measurements. For each motor, two phase currents are measured using the dual-shunt method, while the third phase current is reconstructed in software using Kirchhoff’s Current Law. The DC bus voltage is measured for each inverter so the control, modulation, and monitoring logic remain aware of the available supply voltage.
Figure 4-3. Gathering analog quantities via ADC Block
4.2. Outputs
The primary real-time outputs are the PWM commands used to actuate the inverter phases for both motors. The FOC algorithm computes the voltage commands required by each PMSM, and these commands are translated into duty cycles for the three-phase inverter.
Because each inverter leg requires a high-side and a low-side control signal, the application ultimately drives six PWM signals per motor. These signals are generated from the MCU timing path and routed to the gate-driver stage that controls the external power switches.
Figure 4-4. PWM Actuation Subsystem
In addition to the PWM outputs, the application sends CAN data to the South Zone Controller every 0.1 seconds. These messages are intended for diagnostics, monitoring, and vehicle-level observability.
The transmitted CAN data includes the estimated speed of each motor, the fault status reported by each control channel, the measured DC bus voltage for each inverter, the current operating state of each motor-control instance and many more. The following table highlights the output data sent over CAN bus:
| Name | Description | Unit |
|---|---|---|
| MC_BusVoltageM1 | DC Bus Voltage measured by inverter for Motor 1 | V |
| MC_BusVoltageM2 | DC Bus Voltage measured by inverter for Motor 2 | V |
| MC_FaultStatusM1 | Fault status reported by Motor 1 | true/false |
| MC_FaultStatusM2 | Fault status reported by Motor 2 | true/false |
| MC_PhACurrentM1 | Phase A current – Motor 1 | A |
| MC_PhACurrentM2 | Phase A current – Motor 2 | A |
| MC_PhBCurrentM1 | Phase B current – Motor 1 | A |
| MC_PhBCurrentM2 | Phase B current – Motor 2 | A |
| MC_PhCCurrentM1 | Phase C current – Motor 1 | A |
| MC_PhCCurrentM2 | Phase C current – Motor 2 | A |
| MC_SpeedEstM1 | Motor 1 estimated speed | rpm |
| MC_SpeedEstM2 | Motor 2 estimated speed | rpm |
| MC_SpeedRefM1 | Motor 1 desired speed | rpm |
| MC_SpeedRefM2 | Motor 2 desired speed | rpm |
| MCS_StateM1 | Motor 1 state. It can be Stand By, Running, Fault | - |
| MCS_StateM2 | Motor 2 state. It can be Stand By, Running, Fault | - |
| MCS_PhAVoltageM1 | Phase A Voltage – Motor 1 | V |
| MCS_PhAVoltageM2 | Phase A Voltage – Motor 2 | V |
| MCS_PhBVoltageM1 | Phase B Voltage – Motor 1 | V |
| MCS_PhBVoltageM2 | Phase B Voltage – Motor 2 | V |
| MCS_PhCVoltageM1 | Phase C Voltage – Motor 1 | V |
| MCS_PhCVoltageM2 | Phase C Voltage – Motor 2 | V |
Figure 3-5. Example for CAN Pack Message
Vehicle-Level Communication
The Motor Control System is part of a distributed EV control architecture. It does not operate as an isolated controller. Instead, it receives high-level commands from the vehicle network and reports measured and estimated values back to the rest of the system.
The communication path is organized around the CAN interface between the Central Node, the South Zone Controller, and the Motor Control System Node. Commands such as motor enable and desired speed are received through this path, while feedback messages such as estimated speed, DC bus voltage, phase-current information, and fault status are sent back through the same zonal communication route.
CAN receive handling is interrupt-driven. When a command frame is received, the application decodes the enable and speed request signals and updates the internal command variables used by the Simulink control model. This keeps the command interface responsive without placing CAN processing inside the 100 microsecond FOC interrupt.
Figure 4-1. CAN Receive Interrupt block
CAN transmit handling is periodic. A PIT interrupt schedules outgoing monitoring messages every 0.1 seconds. This separates network reporting from the real-time control path and ensures that diagnostics transmission does not disturb the deterministic execution of the motor-control interrupts.
Figure 4-2. Periodic Interrupt for transmitting CAN messages
The CAN database defines the mapping between application variables and network messages. For example, the enable and speed command are grouped in dedicated message, while fault information, estimated speed, DC bus voltage, and phase-current feedback are exposed through dedicated monitoring messages. More information about the CAN database created for organizing the CAN messages and signals will be presented in a dedicated article.
Simulink Application Architecture
The Simulink model is organized around a dual-control structure. Each motor channel contains the algorithmic blocks required to transform measured currents, estimate rotor position and speed, regulate the control loops, and generate voltage commands for PWM modulation.
Although both channels implement the same FOC strategy, they are treated as separate execution paths. This separation makes it easier to scale from a single-motor setup to a dual-motor configuration and to validate each channel independently before running both motors together.
6.1. Real-Time Control Layer
The real-time control layer is executed inside the BCTU-triggered interrupt flow. The BCTU is synchronized with the PWM timing generated by eMIOS, so the ADC conversions are requested at the correct moment within the switching period. Once the required current measurements are available, the interrupt allows the control algorithm to run using a coherent feedback set.
Figure 5-1. FOC Implementation
Inside this layer, the application reconstructs the three-phase current set, executes the Clarke and Park transformations, estimates rotor position and speed through the Extended EMF Observer, runs the speed and current PI controllers, and generates the voltage commands required by the modulation stage.
The voltage commands are then translated into PWM duty cycles. eMIOS provides the base PWM generation, while the LCU forms the complementary high-side and low-side signals needed by the inverter legs. LCU also adds the necessary dead-time in complementary PWM signals to avoid the DC source damage. TRGMUX routes the required trigger signals between these peripherals, maintaining alignment between actuation and measurement.
Figure 5-2. Fast Loop Subsystem
The same execution concept is applied to the second motor channel. The two FOC instances run on the same S32K396 core, so the application depends on the MCU processing capability and on a carefully scheduled interrupt structure to complete both control paths within the available timing budget.
6.2. Communication and Monitoring Layer
The communication and monitoring layer connects the fast control application with the vehicle network. It receives the enable and speed commands from CAN, prepares diagnostic information, and schedules outgoing status messages.
This layer runs at a lower rate than the FOC loops. It is intended for command exchange, observability, and integration with the Central Node through the South Zone Controller.
6.3. Hardware Abstraction and Peripheral Layer
The hardware abstraction and peripheral layer connects the generated Simulink application to the physical resources of the S32K396 MCU. Its purpose is to keep the control algorithm separated from the low-level hardware access, while still allowing the model to read measurements, update PWM outputs, handle interrupts, and exchange data over communication interfaces.
In practice, this layer contains the target-specific blocks used for ADC acquisition, PWM generation, and CAN communication. These blocks provide the interface between the algorithmic part of the model and the peripherals configured on the MCU.
This layer also makes the model easier to understand and maintain. The FOC subsystems can remain focused on control behavior, while the peripheral layer handles how signals enter and leave the MCU. As a result, the same architectural structure can be reused when moving between simulation, generated code, and target execution.
The NXP Model-Based Design Toolbox provides the Simulink blocks that expose these S32K396 peripherals at model level. This allows engineers to configure and connect hardware-facing functions directly in Simulink, while the generated embedded code uses the corresponding target drivers and configuration.
Peripheral Mapping
The peripheral mapping is centered on the synchronization between measurement, control execution, actuation, gate-driver communication, and vehicle-level CAN communication. Each peripheral has a specific role in this chain, and together they allow the generated Simulink application to interact deterministically with the inverter hardware.
SAR-ADC is used to measure the analog quantities required by the control algorithm. These measurements include the phase-current feedback acquired from the inverter stages and the DC bus voltage used by the modulation and monitoring logic.
BCTU (Body Cross Triggering Unit) performs the triggering of the ADC conversions. Instead of sampling the analog signals at an arbitrary moment, BCTU waits for the synchronization event coming from the PWM timing path and then starts the SARADC conversions at the correct point in the switching period.
eMIOS (Enhanced Multiple Input Output System) generates the three phase PWM signals for each motor channel. These PWM signals represent the base timing generated from the duty cycles computed by the FOC algorithm.
LCU (Logic Control Unit) takes the three PWM signals generated by eMIOS and creates the six PWM outputs required by the inverter. For each motor phase, it generates the complementary high-side and low-side control signals with dead-time insertion used to drive the corresponding inverter leg.
TRGMUX provides the internal routing between peripherals. It connects the three PWM outputs from eMIOS to the LCU inputs and also routes the synchronization signal between eMIOS and BCTU. This routing keeps the actuation path and the measurement path aligned.
LPSPI is used as the communication layer between the S32K396 controller and the MC33937 gate driver. Through this interface, the application can configure and exchange diagnostic information with the gate-driver device, complementing the direct PWM actuation path.
FlexCAN provides the CAN communication controller used by the Motor Control System. It enables reception of command messages from the South Zone Controller and transmission of monitoring and diagnostic data back to the vehicle network.
In this mapping, the fast motor-control path is formed by eMIOS, TRGMUX, BCTU, SARADC, and LCU, while LPSPI supports gate-driver interaction and FlexCAN supports vehicle-level communication. This separation helps keep the time-critical control loop independent from slower configuration, diagnostics, and network tasks.
Figure 6-1. Peripherals Mapping Overview
PIT (Periodic Interrupt Timer) peripheral is used for slower periodic activity, such as CAN diagnostics transmission every 0.1 seconds. CAN receive interrupts are used for incoming command messages from the South Zone Controller.
Data Flow
The data flow starts at the vehicle network and at the analog feedback interface. CAN provides the high-level operating commands, while the inverter sensing path provides the real-time electrical feedback required by the FOC loops.
When a CAN command is received, the enable and speed references are decoded and stored as application-level command variables. These signals are then consumed by the motor-control logic during the next control execution.
In parallel, synchronized ADC conversions provide the latest phase-current and DC bus voltage values. The control algorithm reconstructs the motor currents, estimates rotor position and speed, transforms the feedback into the rotating reference frame, and computes the required voltage commands.
The voltage commands are converted into PWM duty cycles and applied to the inverter actuation path. The resulting gate-drive signals control the external power stage, which drives the PMSM phases.
At a slower rate, selected internal variables are packed into CAN monitoring frames. These values allow the South Zone Controller and Central Node to observe the Motor Control System state without interfering with the fast control-loop execution.
Conclusion
This article described the architectural overview of the Dual-Motor EV Control System application. It presented the main Simulink model structure, the system inputs and outputs, the vehicle-level CAN communication path, the peripheral mapping, and the data flow between command reception, sensing, control, actuation, and monitoring.
The architecture is built around two independent FOC control paths running on the S32K396 in a single-core configuration. Each motor channel receives synchronized analog feedback, executes its control algorithm every 100 microseconds, and generates the PWM outputs required by its inverter stage.
By combining Model-Based design with target-specific peripheral integration, the application provides a scalable foundation for validating dual-motor traction behavior in simulation and on real hardware. The next article can build on this architecture by focusing on Model-in-the-Loop development and controller validation before deployment.
References
- Developing a Dual-Motor EV Control System with Model-Based Design Toolbox
- Software & Hardware Enablement for the Dual-Motor EV Control System
- Sensorless FOC with Motor Control Blockset
- Extended EMF Observer – Motor Control Blockset
- NXP Model-Based Design Toolbox for S32K3
- NXP S32K396 microcontroller documentation
- AN14481: MCSPTR2AK396 3-phase PMSM Motor Control Kit with S32K396 Application Note
