1 Table of Contents • Introduction • Overview • Context • References • Conclusion     2 Introduction This article presents an automotive system built around a central computer that processes high volumes of data to manage interactions and decisions across the vehicle. Implemented on an NXP S32N55 board, a main node orchestrates peripheral nodes — Lighting, Motor Control, Steering, Radar, and Parking Sensors — over CAN, demonstrated through real-time interactions and Driver-in-the-Loop (DiL) simulations. The same architecture also enables stimuli and scenarios to be injected directly from Simulink/MATLAB via the Model-Based Design Toolbox (MBDT), turning the setup into both a functional prototype and a flexible test bench that shortens the loop between design, validation, and refinement.     3 Overview The communication hub acts as a comprehensive aggregator and decision-maker, serving as the central intelligence of the entire automotive control network. This architectural choice follows industry's best practices by consolidating critical decision-making processes into a single, robust processing unit capable of efficiently managing multiple concurrent data streams and executing time-sensitive commands. Centralizing this logic also simplifies maintenance and traceability, since the rules governing vehicle behavior live in one well-defined place rather than being scattered across multiple ECUs. For a project of this nature, the NXP Model-Based Design Toolbox (MBDT) offers a practical development path: control logic and application behavior can be designed in Simulink/MATLAB and deployed directly onto the S32N55, without a separate hand-coding step. The graphical, model-based workflow makes the system's structure easier to follow and adjust, while built-in support for CAN communication and integration with tools like FreeMASTER for live telemetry simplify both stimulus injection and runtime observation. The result is a smoother path from initial concept to a working prototype that can be iterated on and validated in a controlled, repeatable way. In this specific implementation, the main node hosts an application that fulfills two complementary roles: data aggregator and decision-maker. As an aggregator, it collects, synchronizes, and interprets incoming signals from the sensing nodes; as a decision-maker, it translates that fused view of the environment into concrete commands for the actuators. Practically, our system receives data over CAN from the peripheral sensing nodes (Radar, Parking Sensors) and dispatches commands to the actuator nodes (Motor Control, Lights, Steering). The main node is also designed to make safety-critical decisions based on the incoming inputs — for example, triggering Automated Emergency Braking (AEB) when the Parking Node or the Radar Node detects a hazardous situation. Because these decisions are made centrally, the response logic can take the full context into account (vehicle speed, proximity of obstacles, current steering input) rather than reacting to a single sensor in isolation.     4 Context At its core, the main node receives a continuous stream of data over the CAN bus from peripheral nodes distributed throughout the vehicle. These peripheral nodes include: Radar sensors — provide long-range object detection and relative velocity measurements, making them ideal for highway-speed scenarios and forward collision awareness. Parking sensors — monitor the immediate vicinity of the vehicle for obstacles and potential collision risks, typically at very short range and at low speeds. Fault sensors — for actuator nodes, like the motor control, steering and lighting systems. The CAN bus protocol guarantees the reliable, deterministic communication required to meet the stringent timing demands of automotive safety systems. Its built-in arbitration, error detection, and message prioritization make it a natural fit for a distributed architecture in which safety-relevant signals must always reach the main node within a bounded time window. To streamline communication across components, a CAN Database ( DBC ) file has been created that contains all the signals and messages used throughout the system. The DBC file acts as a single source of truth for the entire network: every node — whether sensing or actuating — references the same definitions for message IDs, signal layouts, scaling factors, and value ranges. This drastically reduces the risk of integration mismatches when multiple boards are developed in parallel. Beyond its data aggregation role, the main node also serves as the command center for the vehicle's actuator systems. After receiving data from the simulation, it is being processed and then it transmits precisely timed control signals to critical subsystems, including the motor control unit, lighting system, and steering mechanism. This bidirectional architecture enables closed-loop control strategies, in which sensor feedback continuously informs actuator commands to achieve the desired vehicle behavior. Each actuator node remains responsible for the low-level handling of its hardware, while the main node provides the high-level command to the actuators. Since the main node is responsible for receiving, analyzing, processing and sending data, it also becomes the one responsible for sharing the telemetry information upstream, either to the cloud, or to real time monitoring tools like FreeMASTER. A particularly valuable aspect of this system is its seamless integration with the Simulink/MATLAB environment, which unlocks extensive possibilities for system validation and scenario testing. Engineers can inject stimuli into the simulation and analyze a wide range of driving conditions and edge cases without requiring a full-scale prototype. This is especially useful for reproducing rare or dangerous situations — such as sudden obstacles or sensor faults — in a fully controlled and repeatable environment. To achieve two-way communication between the main node and the simulation, the CAN bus itself is used to communicate with the Simulink model. This way, the physical prototype can feed stimuli into the simulation — and vice versa — on the same CAN bus that devices are using to communicate, significantly expanding the boundaries of the testing environment. The same DBC file that defines the on-vehicle communication is reused on the simulation side, ensuring that the messages exchanged between the real and virtual worlds remain perfectly consistent.   Note: Perhaps one of the most noteworthy features of the main node's active functions is its ability to make safety-critical decisions in real time based on aggregated sensor inputs. The system continuously monitors data from both the parking sensors and the radar node, detecting potentially dangerous situations that require immediate intervention: At low speeds — hazard detection is typically driven by the parking sensors mounted on the front and/or rear of the vehicle, where short-range, high-resolution distance measurements are most relevant. At driving speeds — the radar module takes over, collecting and analyzing data that is then forwarded to the main node for higher-level interpretation. In both scenarios, the main node remains the ultimate decision-maker, fusing all available data to determine the appropriate response. This clear separation between sensing, decision-making, and actuation keeps each component focused on a single responsibility and makes the overall system easier to reason about, extend, and validate.     5 References NXP Model-Based Design Toolbox (MBDT) Community Interacting with Digital Inputs/Outputs on MR-CANHUBK344 Communicating over the CAN Bus S32N Vehicle Super-Integration Processors     6 Conclusion This article has provided an overview of the communication hub's core functionality, offering a high-level perspective on how key systems interact within the overall architecture. The main node was presented both as a data aggregator and as a decision-maker, with a particular emphasis on its role in safety-critical scenarios and its integration with the Simulink/MATLAB environment. Future installments in this series will take a deeper dive into the communication hub — covering the specific board in use, detailed hardware and software requirements, and other technical considerations and implementation nuances. Subsequent articles will also explore individual peripheral nodes in more detail, building up a complete picture of the system one subsystem at a time.

  1 Table of Contents • Introduction • Context • Component Overview • Design and Implementation • Results • Common Pitfalls & Troubleshooting • Summary & Next Steps • References 2 Introduction This article explains how virtual scenes and driving scenarios can be created and used within a Model-Based Design workflow using MathWorks tools. It focuses on how MATLAB® and Simulink® integrate with RoadRunner and Unreal Engine to enable realistic, repeatable, and scalable simulation environments for developing and validating advanced automotive systems. The article is aligned with the NXP Model-Based Design Toolbox (MBDT) workflow and targets users working on control, perception, and system-level validation. In our demo setup, the same workflow presented in this article was applied to build a Driver-in-the-Loop simulation scenario. By leveraging MATLAB®, Simulink®, RoadRunner, and Unreal Engine, we created a realistic virtual environment that allowed direct interaction with the system running on NXP hardware. This approach highlights the practical value of these simulations, not only for early validation and testing, but also for closing the loop between model-based design and real-time execution on target hardware, enabling faster iteration, safer validation, and improved system reliability. 3 Context As automotive systems become more complex, early validation is increasingly important. Engineers must assess advanced functionality under tight development timelines, often before hardware is available. Model-Based Design supports this need by enabling system logic and behavior to be verified early using executable models. Virtual scenes extend this approach by embedding those models in realistic, controlled environments that reflect real-world operating conditions. Within an NXP-based development workflow, virtual scenes enable teams to explore a wide range of driving situations quickly, safely, and repeatably. Complete applications can be evaluated at Model-in-the-Loop (MIL), Software-in-the-Loop (SIL), and Processor-in-the-Loop (PIL) stages, helping uncover issues early and reducing risk before hardware integration. This structured use of virtual validation supports smoother transitions from simulation to deployment on automotive microcontrollers. 4 Component Overview Creating and using virtual scenes with MathWorks relies on several tightly integrated components: MATLAB and Simulink – used for algorithm development, control logic, and system modeling. RoadRunner – a dedicated environment for building detailed road networks, traffic infrastructure, and driving scenarios. Unreal Engine – responsible for high-fidelity 3D visualization and sensor realism. Simulation interfaces – enabling data exchange between Simulink, RoadRunner, and Unreal Engine during runtime. 5 Design and Implementation This section describes the design principles and implementation flow used to create virtual scenes and scenarios. The process emphasizes modularity, repeatability, and tight integration with control and system models. 5.1 System Requirements The following prerequisites must be satisfied to build and execute virtual scenes with MATLAB and Simulink and follow our path: MATLAB and Simulink with Automated Driving Toolbox and Simulink 3D Animation Toolbox installed. RoadRunner. Adequate GPU resources for real-time rendering and sensor simulation. These requirements ensure smooth interaction between simulation models and the visualization environment. 5.2 Architecture & Model Description At a higher level, the architecture consists of a Simulink model acting as the system under test, connected to a virtual world generated by RoadRunner and Unreal Engine. The Simulink model publishes vehicle states and receives environmental feedback, such as lane boundaries, traffic participants, or sensor detections. Clear interface definition between the model and the virtual environment is essential. Signals representing vehicle position, velocity, and actuator commands are exchanged at each simulation step, enabling closed-loop execution.   5.3 MATLAB/Simulink Implementation Connecting to RoadRunner and Loading a Scenario MATLAB connects directly to RoadRunner to open projects and load driving scenarios: % Launch RoadRunner and open a project rrApp = roadrunner('C:\RoadRunnerProjects\VirtualScenes'); openProject(rrApp, 'HelloWorld_Project'); % Open a RoadRunner scenario and start simulation scenarioName = 'Intersection_CrossTraffic'; openScenario(rrApp, scenarioName); rrSim = createSimulation(rrApp); start(rrSim); Integrating RoadRunner with Simulink Once configured, Simulink and RoadRunner run synchronously. RoadRunner updates the virtual environment, while Simulink computes vehicle behavior and control actions. sim('ConfiguredVirtualVehicleModel'); close(rrApp); 5.4 Integration (RoadRunner ↔ Unreal Engine) RoadRunner is used to design road geometry, traffic signs, intersections, and actor paths. These assets are exported to Unreal Engine, which provides photorealistic rendering and sensor simulation. % Open the Simulink model open_system('ConfiguredVirtualVehicleModel'); % Path to the RoadRunner project containing the scene scenarioPathFull = 'C:\RoadRunnerProjects\VirtualScenes\HelloWorld_Project'; % Configure the Simulation 3D Scene Configuration block set_param('ConfiguredVirtualVehicleModel/Visualization/3D Engine/3D Engine/Simulation 3D Scene Configuration', ... 'RoadRunnerProjectPath', scenarioPathFull);   5.5 Creating a Custom Scene from Real Map Data Custom scenes can be created by importing real-world map data into RoadRunner. Geographic information such as road layouts and elevation profiles can be converted into editable road networks. This is an example of how to create a custom scene for recreating the Silverstone Racing Circuit in RoadRunner, using OpenStreetMap and Driving Scenario Designer. And the result using Simulink 3D with Unreal Engine.   5.6 Testing & Validation Once scenarios are defined, automated simulation runs can be executed to validate system behavior across multiple variants. Key metrics such as trajectory tracking, sensor coverage, and control stability can be evaluated offline. This systematic testing approach increases confidence before integrating software with NXP hardware targets. 6 Results Using virtual scenes significantly reduces development time. Engineers can identify functional issues early, explore edge cases, and refine algorithms without hardware constraints. In practice, this results in higher software quality at the time of hardware deployment and a smoother transition to real-world testing. 7 Common Pitfalls & Troubleshooting Simulation time overhead can become noticeable when RoadRunner scenes are used directly in the Simulation 3D Scene Configuration block, as Unreal Engine re-imports RoadRunner assets at the start of each simulation. While this is well suited for iterative development and scene refinement, it can slow down repeated runs. Note: For final validation or deployment-oriented testing, improved performance can be achieved by using a precompiled Unreal Engine project, which avoids repeated asset import and significantly reduces startup time. In addition, repeatedly launching RoadRunner for each simulation introduces unnecessary overhead. A recommended practice is to keep RoadRunner running across multiple simulations and reuse the existing connection. This can be achieved using the RoadRunner roadrunner.connect API, allowing MATLAB and Simulink to reconnect to an active RoadRunner instance instead of restarting it for every run, thereby improving iteration speed and overall workflow efficiency. 8 Summary & Next Steps Virtual scenes turn simulation into experience. Combined with an NXP Model-Based Design workflow, MathWorks tools enable engineers to innovate faster, validating complex behavior early while reducing risk, cost, and development effort. Next, these environments can be expanded with high-fidelity sensor models, automated regression testing, and hardware-in-the-loop execution, closing the gap between virtual validation and real-world deployment. 9 References Import OpenStreetMap Data into Driving Scenario — MathWorks Help Driving Scenario Designer App — MathWorks Help RoadRunner — MathWorks Product Page Simulink 3D Animation Toolbox — MathWorks Help OpenStreetMap Automated Driving Toolbox — MathWorks Product Page Visualize 3D Scenes with Unreal Engine — MathWorks Help roadrunner.connect API — MathWorks Help NXP Model-Based Design Toolbox — Community

  1 Table of Contents •Introduction •Overview •Context •References •Conclusion 2 Introduction This article walks through the complete process of setting up the NXP Model-Based Design Toolbox (MBDT) and running a first application on NXP hardware. Before starting the installation, make sure that the prerequisite toolboxes are available in MATLAB. By the end of this guide, the reader will have a fully functional MBDT environment and will have successfully generated, compiled, and deployed embedded C code from a Simulink model to NXP hardware. 3 Overview This guide begins with the installation prerequisites and required toolboxes, then continues with the MATLAB Add-On Explorer flow for installing NXP_Support_Package_S32K3 . After the support package is installed, the guide explains how to launch the multistep installer, verify the required toolboxes and installation path, download the toolbox package from NXP, and complete the toolbox installation before running the first application. Installation Scope and Workflow This article focuses on practical installation flow required to start working with the NXP Model-Based Design Toolbox and run a first example application. It covers the software prerequisites, the toolbox setup sequence, and the validation steps needed before opening and deploying a model on the target board. The installation content in this guide should use the current multistep installer flow. Target Audience This article is intended for engineers and technical professionals who want to begin developing embedded applications for NXP hardware using a Model-Based Design workflow. The main target audience includes: Embedded software engineers MATLAB / Simulink developers evaluating NXP hardware Control and algorithm engineers Students and academic researchers using NXP evaluation boards Model-Based Design engineers Hardware integration engineers 4 Context 3.1 Prerequisites Before starting the installation, verify that the following prerequisite toolboxes and setup conditions are met: MATLAB installed - Required by the support package and multistep installer flow. Simulink installed - Required for model-based development and Simulink example execution. Embedded Coder installed - Required for embedded C code generation from Simulink models. MATLAB Coder installed - Required by the current S32K3 support package prerequisites. Simulink Coder installed - Required by the current S32K3 support package prerequisites. Embedded Coder Support Package for ARM Cortex-M Processors installed - Required by the installer verification step and target support flow. NXP account - Required to access the NXP download page and retrieve the toolbox package. Short local installation path - The installation path should be local, short, and should not contain whitespace to avoid setup issues. Figure 1 - MATLAB Add-On Manager confirming requirement are installed 3.2 Toolbox Setup NXP's Model-Based Design Toolbox is delivered as a MATLAB Toolbox Package that can be installed offline or online from MathWorks Add-ons. The recommended installation path uses the NXP Support Package, a graphical wizard that guides through download, installation, and license activation in a single workflow. Note: Throughout this guide, the placeholder {platform} refers to the NXP MCU family targeted by the toolbox (for example S32K3 , S32K1 , S32M2 , MPC57XX , etc.). Each family has its own dedicated Support Package and Toolbox in the MATLAB Add-On Explorer. When following the steps below, replace {platform} with the identifier matching the hardware family in use, for instance, for the S32K3 evaluation boards, the script name becomes NXP_Support_Package_s32k3.m and the path command becomes mbd_s32k3_path . Step 1 - Install NXP Support Package from MATLAB Add-On Explorer Install the current NXP support package directly from the MATLAB Add-On Explorer. This package provides the multistep installer flow used to verify prerequisites, download the toolbox, and guide the installation for S32K3. In MATLAB, navigate to Home → Add-Ons → Get Add-Ons. Figure 2 - Open the Add-On Explorer from the MATLAB Home tab Search for NXP_Support_Package_S32K3 in the Add-On Explorer. Figure 3 - Search results for NXP_Support_Package_S32K3 in the Add-On Explorer Open the package page and click Add to start the installation. Figure 4 - Open the NXP_Support_Package_S32K3 page and click Add Review the license agreement for NXP_Support_Package_S32K3 and click I Accept. Figure 5 - License agreement shown during installation of NXP_Support_Package_S32K3 Wait for the installation to complete. When finished, the Getting Started Guide opens automatically. Figure 6 - Support package installation completed successfully In the MATLAB Command Window, run sp_s32k3.nxp.setup(); to launch the multistep installer. sp_s32k3.nxp.setup(); Figure 7 - Run sp_s32k3.nxp.setup(); from the MATLAB Command Window Step 2 - Use the multistep installer to download and install the toolbox The multistep installer guides you through prerequisite verification, toolbox download, installation, activation, and access to the documentation for S32K3. Figure 8 - Welcome page of the S32K3 multistep installer In the installer, continue to the download step. On the NXP website, review the software terms and conditions and click I Agree before downloading the toolbox package. If the product download page does not open automatically, sign in to your NXP account and open the Product Download page for the required S32K3 toolbox release or click the link from Download page of the S32K3 multistep installer. Figure 9 - Download page of the S32K3 multistep installer Figure 10 - Accept the NXP software terms and conditions before downloading Download the toolbox package from the Product Download page. The installer accepts both .zip and .mltbx files. Figure 11 - Product Download page for the S32K3 MBDT package The setup verification step checks whether all required toolboxes are installed in MATLAB and whether the installation path is valid for the S32K3 toolbox setup. If any dependency is missing or an unsupported version is detected, resolve the issue before continuing to the download and installation steps. Figure 12 - Setup verification page showing required toolboxes and installation path checks Important: It is recommended to install MATLAB and the NXP Toolbox into a location that does not contain special characters, empty spaces, or mapped drives. Use a short local path whenever possible. After downloading the package, return to the installer and continue with the local file selection step. Browse to the downloaded archive or toolbox package and click Install to continue. The installer accepts both .zip and .mltbx files. Figure 13 - Browse to and download the S32K3 MBDT package from the Product Download page Figure 14 - Accept the license agreement for NXP_MBDToolbox_S32K3 Accept the toolbox license agreement to allow MATLAB to complete the MBDT installation. Figure 15 - Toolbox installation in progress After the installation is complete, use the Add-On Manager context menu to open the installed toolbox folder if you need to inspect the package contents or access installed files directly. Wait until the installation finishes. The process may take several minutes depending on the system configuration and package size. Figure 16 - Open the installed toolbox location from MATLAB Add-On Manager Step 4 - Set the Path for Toolchain Generation The MBDT uses Simulink's toolchain mechanism to enable automatic code generation with Embedded Coder. When installed as a MATLAB add-on, the toolbox path is configured automatically. If manual configuration is still required in your environment, run the platform path script from the installation directory. If manual setup is required, in MATLAB change the Current Directory to the toolbox installation folder: ..\MATLAB\Add-Ons\Toolboxes\NXP_MBDToolbox_{platform}\ Then run the configuration script: mbd_{platform}_path Figure 17 - Output of the mbd_{platform}_path script in the MATLAB Command Window 3.3 How to Run an Application With the toolbox installed and the compiler configured, the following steps demonstrate how to open, build, and deploy the LED blinky example - the embedded equivalent of Hello World to an NXP evaluation board. Open an Example Model Open MATLAB and start Simulink by typing simulink in the Command Window (or by clicking the Simulink button on the Home tab). In the Simulink Start Page, open the Simulink Library Browser (View → Library Browser, or press Ctrl+Shift+L). In the Library Browser tree, expand NXP Model-Based Design Toolbox for {platform} to confirm that the NXP blocks are available. This validates that the toolbox is properly registered with Simulink. Open the Example Projects tab from the Simulink Start Page, it lists every example shipped with the MBDT, grouped by peripheral (ADC, CAN, DIO, PWM, UART, etc.). Browse the list, select the example matching your hardware (for instance s32k3xx_dio_s32ct for the LED blinky on FRDM-A-S32K312 / FRDM-A-S32K344 ), and click Open to load the model. Figure 18 - MBDT Examples Library available from the Simulink Library Browser Open the example model ( .slx / .mdl file). Configure the Target Hardware Figure 19 - Model Settings  Figure 20 - Code Generation Tip: Example models that ship with the MBDT are pre-configured for a specific evaluation board. Always verify the hardware target matches your physical board before building. Build and Deploy Connect the NXP evaluation board to the PC via USB. In Simulink, open the Hardware tab and click Build, Deploy & Start (or use Ctrl+B). Monitor the MATLAB Diagnostic Viewer for build status messages. Verify on Hardware Confirm that the application runs on the target hardware as expected - for example, observe the LED blinking at the rate defined in the model. If the application produces serial output, open a terminal and verify the expected data on the communication port. Use debugging or monitoring tools to inspect variable values and system signals from the running application in real time. 5 References NXP Model-Based Design Toolbox - Product Page Automotive SW - S32K3 - Model-Based Design Toolbox Model-Based Design Toolbox S32K3xx Quick Start Guide (PDF) MathWorks Embedded Coder     6 Conclusion This article described the complete setup of the NXP Model-Based Design Toolbox: from installation and compiler configuration to building and deploying a first application to NXP hardware. The next article in the series focuses on the Toolbox Workflow, presenting in detail the end-to-end development flow with the MBDT, from configuring a Simulink model with NXP blocks, through code generation with Embedded Coder, to building, deploying and validating the resulting application on NXP hardware.

    1 Table of Contents • Introduction • Overview • Target Audience • Context • References • Conclusion     2 Introduction A Battery Management System (BMS) is a system that monitors and manages a battery pack to ensure it operates safely, efficiently, and reliably, making it a critical component in electric vehicles. Its main functions include measuring voltages, currents, and temperatures and balancing the cells to maintain consistent performance. This overview introduces a series on the architecture, development and integration of a battery management system developed using NXP hardware and software. To accelerate this process, MathWorks ecosystem is used to streamline the development, maintain traceability from model to implementation and to validate complex embedded applications.     3 Overview Articles roadmap Developing a battery management system is a complex undertaking, and explaining it thoroughly requires a structured series of articles. Each article focuses on a key stage of the development process, offering detailed insight into how such a system is designed, implemented, tested, and validated from concept to deployment. The series includes the following articles: Software and Hardware Environment - An overview of the required software environment, including NXP software development kits (SDKs), real-time drivers (RTDs), and MathWorks toolboxes, together with the hardware platform used in the application. Architecture and Model Description - A detailed description of the system architecture, including the model structure, input and output signals, and the core algorithms used in the battery management system. Validate the BMS Algorithms (Model-in-the-Loop) - An explanation of how validated MathWorks battery management assets - such as state-of-charge (SoC) and state-of-health (SoH) estimation algorithms - can be adapted, integrated, and verified within the application model. Preparing BMS Algorithms for Code Generation (Software-in-the-Loop) - Guidance on generating production-oriented code from validated models and running software-in-the-loop (SiL) simulations to compare code behavior against the model-in-the-loop (MiL) baseline. Bringing the BMS Closer to Hardware (Processor-in-the-Loop) - Steps to prepare the model for execution on target hardware by deploying the generated software to an NXP evaluation board while emulating battery measurements on a host PC. Deployment and Validation on the High-Voltage BMS Reference Design Kit - Configuration of external devices to supply real data to the BMS algorithms, followed by system-level validation. Extending the Controller with CAN Communication - Integration of controller area network (CAN) communication by defining the CAN database, configuring the communication stack, and validating message exchange on the NXP hardware. Final Results - A summary and discussion of results, along with final validation of the complete battery management system. What is the Battery Management System? A Battery Management System (BMS) is a combined hardware and software system responsible for monitoring, controlling, and protecting an electric vehicle's battery pack. Technically, it acts as the central authority that has full visibility into the battery's operating conditions, such as cell voltages, pack current, and temperatures. Based on this information, the BMS makes real-time decisions to keep the battery within safe operating limits. It also enforces critical protections - such as preventing overcharge, over-discharge, over-temperature, or short-circuit conditions - which are essential for safety, reliability, and regulatory compliance. From a functional perspective, the BMS performs several key jobs that directly impact vehicle performance and longevity. These include estimating battery states such as State of Charge (SoC), State of Health (SoH), and available power, which higher-level vehicle systems rely on for range prediction and energy management. The BMS also manages cell balancing, ensuring that individual cells within the pack age uniformly and maintain similar voltage levels. This combination of accurate state estimation and active control helps maximize usable energy, protect the battery from accelerated degradation, and maintain consistent performance throughout the vehicle's life. On the hardware side, a BMS typically consists of sensing components (voltage, current, and temperature sensors), cell monitoring and balancing ICs, a microcontroller, isolation components, and communication interfaces. These elements work together to acquire high-precision measurement data from the battery pack and execute control actions such as enabling contactors or activating balancing circuits. In many architectures, the system is distributed, with multiple cell monitoring units communicating with a central BMS controller.   The software layer ties everything together and is often the most complex part of the system. BMS software includes low-level drivers for sensors and communication, real-time control logic, diagnostic and fault-handling mechanisms, and advanced algorithms for state of charge estimation. It must integrate seamlessly with the rest of the vehicle through networks such as CAN, allowing the BMS to exchange data with vehicle control units, chargers, thermal management systems, and the powertrain. Through this tight hardware-software integration, the BMS becomes a core enabler of safe operation, efficient energy use, and coordinated vehicle behavior.     4 Target Audience This article series is intended for engineers, technical specialists, and decision-makers involved in the development, integration, or evaluation of high-voltage battery management systems for electric vehicle applications. It is especially relevant for readers who want to understand how BMS algorithms, embedded software, hardware platforms, and validation workflows come together in a complete development process. The content is suitable for both engineers looking for practical implementation guidance and technical stakeholders interested in the benefits of using a Model-Based Design approach with MathWorks and NXP solutions. The main target audience includes: Embedded software engineers Control and algorithm engineers Battery system engineers Electric vehicle system architects Model-Based Design engineers Hardware and integration engineers Test and validation engineers Technical managers and project leads     5 Context In the electric vehicle architecture presented in this series, the Battery Management System is located in the rear zone of the vehicle. It is a safety-critical controller responsible for battery supervision, but it operates within a highly interconnected ecosystem. It bridges: Battery pack (physical layer) Vehicle Control Network (communication layer) Powertrain and Vehicle Behavior (functional layer) The HVBMS is implemented on the reference design bundle for 800 V high-voltage battery management systems. It provides a complete hardware solution including: RD-K358BMU - battery management Unit (BMU) RD33774CNT3EVB - cell monitoring unit (CMU) RD772BJBTPL8EV - battery junction box (BJB) 18 Cell Battery Pack Emulator       6 References Speed-Up BMS Application Development with NXP's HVBMS RD and Model-Based Design Toolbox (MBDT) Model-Based Design Toolbox NXP Community 800 V Battery Management System (BMS) Reference Designs Using ETPL Model-Based Design Toolbox (MBDT)     7 Conclusion This article introduced the Battery Management System within the context of an electric vehicle architecture and established the technical foundation for the rest of the series. It described the role of the Battery Management System and illustrated how a Model-Based Design workflow can be implemented by combining the MathWorks and NXP ecosystems. The next article will focus on the software and hardware environment needed to develop, simulate, and deploy a Battery Management System using MathWorks and NXP solutions.

Real-Time debugging tool for embedded application running on NXP CPUs

      1 Table of Contents • Introduction • Overview • Context • References • Conclusion     2 Introduction Parking assistance systems are a familiar feature in modern vehicles, helping drivers detect nearby obstacles and maneuver the vehicle more safely. In our Hello World with MBDT project, the parking sensor subsystem provides this capability by measuring the distance to nearby objects and supplying that information to the rest of the system. Figure 1 - Physical concept This article introduces the parking sensor system and leads into the next articles in the series, where we will examine how this part of the project is developed. The Parking Sensors System (PSS) focus is set on how Model‑Based Design (MBD) enables the subsystem to be designed, simulated, tested, and deployed rapidly using MATLAB/Simulink and the NXP Model-Based Design Toolbox (MBDT).     3 Overview The role of this subsystem within the overall project describes the main elements that make up the parking sensor application and explains its purpose and behavior at a conceptual level. The article outlines how NXP's MBDT supports the development of this component and how a single model is reused for both front and rear parking modules. It also clarifies how this component fits into the larger project and how it connects to the rest of the components. The importance of this subsystem lies not only in its functional role of acquiring and processing distance information but also in how it demonstrates the efficiency of model‑based workflows. Rather than relying on traditional hand‑written embedded code, the entire application — logic, algorithms, peripheral drivers, timing behavior — can be designed graphically in Simulink. This accelerates development in several ways: Behavior can be simulated on the PC, without flashing hardware. The same model drives both simulation and embedded implementation. Peripheral interactions like Analog‑to‑Digital Converter (ADC) and Local Interconnect Network (LIN) are handled through dedicated blocks, not hand‑written code. Parameter tuning and validation are simplified through FreeMASTER, providing real-time visualization of the embedded system parameters. This accelerates development and ensures that the final embedded behavior matches the tested model. Developing an embedded sensor node application typically involves writing extensive low‑level code, configuring peripherals manually, and iterating slowly through hardware tests. This slows down development, limits experimentation, and creates fragmentation between design and implementation. The parking sensor subsystem demonstrates how Model-Based Design in Simulink solves this problem by enabling the entire feature to be built directly in Simulink. Engineers can model ADC acquisition, LIN communication, filtering logic, and threshold detection using graphical blocks rather than manual code. They can simulate the behavior instantly, refine algorithms quickly, and deploy the design to the microcontroller through automatic code generation. The MBD approach significantly improves the efficiency and reliability of developing, testing, and refining the complete parking sensor application. This series is intended for: Engineers learning Model‑Based Design with MATLAB/Simulink Developers working with NXP automotive microcontrollers Teams building rapid prototypes of embedded measurement and control features Students and researchers studying vehicle architectures Anyone interested in a full, reproducible example of embedded system development using MBDT Readers will gain a clear, step‑by‑step understanding of how a complete embedded feature is designed and implemented using a unified model‑based workflow.     4 Context A key aspect of the design is that the same PSS application developed in Simulink is used for both front and rear parking. Two separate S32K144 boards run the identical autogenerated code — one at the front of the vehicle and one at the rear. This showcases one of the major advantages of MBD: a single validated model can be scaled, cloned, and reused across multiple hardware nodes with minimal parametrization. Figure 2 - Parking System Architecture The purpose of the parking sensor subsystem is to provide a clean, consistent, and rapidly developed interface that delivers accurate distance information to the rest of the system. In the implemented setup, each ultrasonic sensor outputs an analog voltage proportional to distance. This signal is sampled by the ADC (Analog‑to‑Digital Converter) of the S32K144 microcontroller. The embedded application running on the S32K144 performs the acquisition sequence, processes the ADC values to compute distance measurements, and formats the results into a communication frame. The prepared data is then transmitted over the LIN bus to the zonal controller, where it can be further used by higher‑level vehicle functions. All functional aspects — ADC acquisition configuration, signal processing, communication formatting, and diagnostic handling — are defined directly in the Simulink model, enabling rapid refinement and immediate validation through simulation. During development, FreeMASTER is used to monitor live ADC samples from the ultrasonic sensors, observe processed distance values, and validate the behavior of the embedded application before integrating the component into the full system. The parking sensor component (front and rear) is highlighted to show its position in the project setup: Figure 3 - Parking System highlighted within the project Related articles in the series Note: Additional articles in the series, including topics such as Software & Hardware Environment, Architecture & Model Description, Deploy & Validate on Hardware, Final Results and Challenges, will be added here as they become available. Each will explore individual technical details such as ADC acquisition, model structure, filtering logic, and communication behavior introduced in this overview.     5 References MathWorks Model-Based Design Toolbox for S32K Community Model-Based Design Toolbox for S32K How To NXP Support Package for S32K1xx NXP Model-Based Design Toolbox for S32K1 Toolbox Download These resources provide deeper insight into the tools and methods used to build the subsystem.     6 Conclusion The parking sensor subsystem demonstrates how Model-Based Design accelerates the development of embedded automotive features. By modeling the sensing logic in Simulink, validating behavior through simulation, downloading it automatically using MBDT and monitoring it on hardware with FreeMASTER, the entire application can be developed and deployed from within a single environment. Rather than duplicating the parking sensors logic, the application is implemented as a parameterized Simulink model. Using MBDT, the same model instance can be configured for the front or rear module by adjusting parameters such as communication identifiers. This approach enables consistent behavior across parking modules while minimizing duplication and simplifying maintenance. This article introduced the component's behavior, purpose, and development workflow. The next articles in the series will expand on specific technical aspects, building a complete understanding of the subsystem from model to deployment.

  1 Introduction This article series presents the Motor Control System (MCS) within an electric vehicle (EV) architecture. It introduces the end-to-end development flow, from controller and plant modeling to simulation, code generation, hardware deployment, and integration with the rest of the vehicle network. This opening article establishes the technical foundation for a series focused on the architecture, implementation, and integration of a dual-motor control system for EV traction applications. The series also shows how MathWorks tools can be used together with NXP software and hardware to support a Model-Based Design workflow. This approach helps engineers develop, verify, and deploy motor control applications more efficiently while maintaining traceability across the development cycle. Figure 1-1. Role of the Motor Control System within the EV traction domain     2 Table of Contents • Introduction • Overview • Context • References • Conclusion     3 Overview 3.1. What will this series of articles cover? The articles in this series define the development roadmap for the Motor Control System within a broader EV architecture. The series covers the following topics: Software and Hardware Environment - Overview of the MathWorks and NXP tools used to develop, test, and validate a dual-motor control system. Architecture and Model Description - Description of the model architecture, signal interfaces, and core control algorithms implemented in the Motor Control System. Model-in-the-Loop Development - Simulation of the controller and plant in Simulink to validate algorithms before code generation. Software-in-the-Loop Validation - Code generation for the validated controller and comparison of the generated software against the Model-in-the-Loop baseline. Processor-in-the-Loop Validation - Execution of the controller on NXP hardware while the plant remains simulated on the host system. Deployment and Validation on Real Hardware - Integration with physical hardware, scaling from single-motor to dual-motor operation, and configuration of the NXP MCU peripherals required for motor control. CAN Integration - Definition of the CAN communication interface, including database design and integration on the target NXP platform. Results and System Validation - Presentation of the final implementation results and validation of the complete system behavior. 3.2. What is the Motor Control System? Electric vehicles depend on traction systems that deliver efficient propulsion, accurate torque control, and safe operation. At the center of this functionality is the Motor Control System (MCS), which combines real-time control software, power electronics, sensing, actuation, and communication interfaces into a tightly coordinated embedded system. Figure 3-1. PMSM motor and controller as core elements of the traction system In modern EVs, the traction system delivers the torque and power needed to propel the vehicle. It is typically composed of the following elements: Electric motor - converts electrical energy from the battery into mechanical power at the wheels. Inverter system - converts DC energy from the battery into the controlled AC waveforms required by the motor. Transmission system - transfers the generated torque from the motor to the wheels. At its core, the Motor Control System regulates motor torque, speed, and position by controlling the voltage and current applied to the motor phases. A typical MCS includes the following functional layers: Control Algorithm - implements torque and current control strategies such as Field-Oriented Control (FOC). Sensing and Feedback - measures motor currents, voltages, rotor position, and temperature. Power Electronics - inverter circuitry that switches DC power into AC waveforms for motor drive. Embedded Processor - microcontroller executing real-time control loops. Communication Interfaces - CAN, LIN, or Ethernet for integration with other system modules. Together, these layers form a closed-loop control system that operates at high switching frequencies and under strict real-time constraints. Figure 3-2. Field-Oriented Control (FOC) architecture EV traction systems can be implemented using different architectures depending on the required balance of efficiency, performance, cost, and system complexity. A single-motor architecture uses one traction motor to drive either the front or rear axle. This approach reduces hardware complexity and cost, and it often improves vehicle range because of lower mass and lower overall energy consumption. A dual-motor architecture uses two independent traction machines that can be arranged in several drivetrain topologies. This configuration enables higher total power, better traction, improved vehicle dynamics, and stronger acceleration. The tradeoff is increased electrical and mechanical complexity, together with higher system cost. Figure 3-3. Example dual-motor traction architecture Advantages & Disadvantages of Dual Motor: Acceleration faster due to torque from both motors Superior traction and handling, especially in snow, rain or off-road conditions Slightly lower range due to increased weight and power consumption More expensive but can include AWD and performance benefits Advantages & Disadvantages of Single Motor: Slightly better range due to less energy consumption More affordable Moderate traction, suitable for most road conditions Slower acceleration Note: The example used throughout this series is based on a dual-motor rear-axle architecture, where each rear wheel is driven by its own motor. 3.3. Target Audience This series is intended for engineers and technical stakeholders involved in the development, integration, and evaluation of electric drive systems, including the following audiences: Embedded Software Engineers Motor Control & Power Electronics Engineers System Architects & Vehicle Architecture Engineers Hardware Engineers Model-Based Design and Simulink Developers Academic and Research Communities     4 Context In the electric vehicle architecture presented in this series, the Motor Control System is located in the rear zone of the vehicle. Each rear wheel is driven by an independent Permanent Magnet Synchronous Motor (PMSM). The Motor Control System ECU coordinates both motors and exchanges real-time data with the rest of the vehicle over the CAN network. Figure 4-1. Motor Control System highlighted within the EV architecture The traction ECU is built around NXP's S32K396 microcontroller, which supports both single 6-phase motor control and dual 3-phase motor configurations. The inverter stage is driven by the MC33937 pre-driver, which provides three high-side and three low-side FET pre-drivers for automotive motor control applications. Note: The inverter receives DC power from the vehicle battery, while battery operation and safety are supervised by the Battery Management System. The Motor Control System communicates over CAN with the Zone Node controller, which in turn exchanges commands and status information with the main vehicle control node responsible for speed and torque requests.     5 References PMSM Control Workshop BLDC Control Workshop A Model-Based Design (MBDT) Environment for Motor Control Algorithm Development Deploy Motor Control Algorithms on NXP S32K3 from Simulink Motor Control Rapid Prototyping on NXP S32M2 with MathWorks and Model-Based Design Toolbox Next Generation of NXP EV Traction Inverter with S32K39 MCU and FS26 SBC AN14326: 3-phase Motor Control Kit with S32K396 Application Note AN13884: 3-phase Sensorless PMSM Motor Control Kit with S32K344 using RTD AUTOSAR API Application Note Advancing Motor Control Performance with Digital Twins Extended Range Dual-Motor Electric Vehicle Model     6 Conclusion This article introduced the Motor Control System within an EV architecture and established the technical context for the rest of the series. It explained the role of the Motor Control System, compared single-motor and dual-motor traction topologies, and outlined how a Model-Based Design workflow can be applied using MathWorks tools together with NXP software and hardware. The next article will focus on the software and hardware environment required to develop, simulate, and deploy the Motor Control System using MathWorks and NXP solutions.

    1 Table of Contents • Introduction • Open the generated project in S32 Design Studio • Debug the generated application in S32 Design Studio • Debug the code generated from the Simulink model • Conclusion 2 Introduction This article explains how to take a project generated with the Model-Based Design Toolbox (MBDT) in Simulink and open, build, and debug it in S32 Design Studio. It focuses on the transition from model execution in Simulink to target-level debugging and validation on S32 hardware.     3 Open the generated project in S32 Design Studio MBDT generates code from Simulink models and exports it as an S32 Design Studio-compatible project. After a successful model build, the generated <modelName>_Config folder contains the files required by the IDE. The project can then be opened directly from Simulink or imported into S32 Design Studio for further configuration, building, and debugging on S32 hardware. Before opening or debugging the project in S32 Design Studio, build the Simulink model. The build process generates the code and project structure required for IDE integration. You can open the generated project either directly from Simulink or manually from within S32 Design Studio. Use the Simulink option when you want to launch the generated project immediately after configuration. Use the IDE import option when you want to manage the project manually from an S32 Design Studio workspace. Open the project from Simulink To open the project from Simulink, open the model Hardware Settings from the Hardware tab or press Ctrl + E. Then go to Hardware Implementation → Hardware board settings → Target hardware resources → S32 Design Studio Project and select Open. Figure 1. S32 Design Studio project settings in Simulink A dialog appears and prompts you to select the S32 Design Studio installation path. Figure 2. S32 Design Studio installation path selection To select the S32 Design Studio installation path later, or to change it during toolbox usage, click Browse in the S32 Design Studio location field under the Tools Paths group. Figure 3. S32 Design Studio path changing The generated project opens in S32 Design Studio and is ready to build, configure, or debug. Figure 4. Generated project opened in S32 Design Studio Open the project inside the IDE To import the project manually into S32 Design Studio, follow these steps: Inside the IDE, select File → Import → Existing Projects into Workspace. Figure 5. Importing an existing project into the workspace Browse for the <modelName>_Config folder in Select root directory. Before clicking Finish, make sure that Copy projects into workspace is disabled. If the project is copied into the S32 Design Studio workspace, the build process will fail. Figure 6. Directory selection for the generated project     4 Debug the generated application in S32 Design Studio To build and debug the project in S32 Design Studio, select the project and click Debug. S32 Design Studio builds the project and automatically switches to the Debug perspective. Note: Ensure that the target hardware board is connected before starting the debug session. Figure 7. Starting the debug session Figure 8. Debug perspective in S32 Design Studio After the debugger launches and the application is loaded on the target, you can use the following actions to control program execution and inspect the generated code: The Breakpoint action sets a breakpoint when you double-click in the left margin of a .c file:   Figure 9. Breakpoint set in the generated source file The Step Over (F6) action executes the current line while remaining in the same function: Figure 10. Step Over action in the Debug toolbar The Step Into (F5) action enters a called function: Figure 11. Step Into action in the Debug toolbar The Step Return (F7) action runs to the end of the current function: Figure 12. Step Return action in the Debug toolbar The Resume (F8) action runs until the next breakpoint: Figure 13. Resume action in the Debug toolbar Figure 14. Breakpoint reached after pressing Resume action The Suspend (F9) action pauses execution at the current instruction: Figure 15. Suspend action in the Debug toolbar Figure 16. Function paused after pressing Suspend action The Terminate (Ctrl + F2) action stops the debug session and disconnects from the target: Figure 17. Terminate action in the Debug toolbar The Disconnect action leaves the target running while detaching the debugger: Figure 18. Disconnect action in the Debug toolbar     5 Debug the code generated from the Simulink model The code generated by the Simulink model can be found in the <modelName>_step() function. To enter this function, set a breakpoint before the function call, run the application until the breakpoint is reached, and then select Step Into. Alternatively, Ctrl + Click the function name to open the function and place a breakpoint inside it. Figure 19. modelName_step function In this function, you will also find the generated code for the blocks placed inside the Simulink model. Figure 20. Generated step function in the source code To monitor variable values, hover over a variable to see its current value: Figure 21. Variable value displayed on hover Alternatively, add the variable to the Expressions view by selecting Add new expression, entering the variable name, and pressing Enter. Figure 22. Add new expression in Expressions view Figure 23. Variable added to Expressions view Upon running the code, if the value changes, it will be highlighted. Figure 24. Variable value highlighted during debug The names of the variables in the generated code are the same as the names they have in the Simulink model, making it easier to debug the generated code. Figure 25. Variable name in Simulink model and generated code   6 Conclusion After identifying the generated function and monitoring key variables, you can validate how the Simulink model behavior maps to the generated application running on the target hardware. For more tutorials on installing, activating, and using S32 Design Studio, see the S32 Design Studio tutorials on the community page: S32 Design Studio Knowledge Base.

1 Table of Contents • Introduction • Overview • Context • References • Conclusion 2 Introduction The steering system is an essential and safety-critical component of any vehicle, responsible for controlling the direction of wheel movement and guiding the vehicle along the intended path. In our Hello World with MBDT project, the Steering subsystem delivers this capability by driving a steering motor to a desired angle and direction, transmitting the resulting torque to the road wheels through the steering column and rack-and-pinion assembly. Figure 1. Hello World with MBDT Demo – Steering system This article series presents the Electric Power Steering (EPS) system in Electric Vehicle (EV) architecture and covers the hardware, software, code generation, and vehicle network integration needed to implement the system using a Model-Based Design (MBD) workflow with MathWorks tools and NXP hardware. 3 Overview 2.1. What will this series of articles cover? The articles in this series will present the Steering System within an EV architecture and cover the following topics: Software and Hardware Environment Overview of the MathWorks and NXP tools used to develop, test, and validate the EPS control system. Logic Control Description of the model architecture, signal interfaces, and core control algorithms implemented in the Steering System. Deployment on Real Hardware Integration with physical hardware, the stepper motor, and configuration of the NXP MCU peripherals required for motor control. CAN Integration Definition of the CAN communication interface, including database design and integration on the target NXP platform. System Validation Presentation of the final implementation results and validation of the complete system behavior. 2.2. What is the Electric Power Steering System? Electric Power Steering (EPS) eliminates the hydraulic pump found in conventional steering systems, instead relying on an electric motor driven by an Electronic Control Unit (ECU). Torque and position sensors mounted on the steering column feed real-time measurements to the ECU, which computes the required assist level and commands the motor accordingly. This on-demand assist approach improves energy efficiency, enables precise tuning of steering feel, and provides a programmable interface for Advanced Driver Assistance Systems (ADAS). Figure 2. Electric Steering Rack and Pinion EPS systems are classified based on where the electric motor is mounted on the steering mechanism. Column Assist Type (C-EPS) - The electric motor and control unit are mounted directly on the steering column inside the cabin. Pinion Assist Type (P-EPS) - The electric motor is attached to the pinion shaft within the steering gear box. Dual-Pinion Assist Type (DP-EPS) - This system separates the assist function from the steering mechanism. One pinion gear connects the steering wheel, while the electric motor applies assistance to a second, separate pinion gear directly on the steering rack. Rack Assist Type (R-EPS) - The electric motor is mounted directly onto the main steering rack, either via a concentric motor around the rack or a belt drive. Steer-by-Wire (SbW) - The mechanical connection (steering column and intermediate shaft) between the steering wheel and the wheels is entirely removed. Key Characteristics of Steer-by-Wire EPS: The wheel's movement is handled completely by electronic sensors, algorithms, and actuators It allows for completely customizable steering ratios Frees up interior cabin space Relies heavily on redundant electronics and fail-safes 2.3. Target Audience This series is intended for engineers and technical stakeholders involved in the development, integration, and evaluation of electric power steering systems, including the following audiences: Mechanical and Embedded Software Engineers Motor Control & Power Electronics Engineers System Architects & Vehicle Architecture Engineers Model-Based Design and Simulink Developers Academic and Research Communities 4 Context In the example vehicle architecture used throughout this series, the Steering System is located in the front zone of the vehicle. The Steering ECU is built around the NXP S32K312 microcontroller, which provides both CAN and LIN connectivity. Note: The NXP S32K312 microcontroller provides the processing performance, peripheral set, and communication interfaces (CAN, LIN) required for automotive steering control applications. The ECU drives the stepper motor to the commanded position and communicates desired angle and direction requests over CAN to the Zonal Controller, which coordinates these signals with the central vehicle control node. 5 References Steering column - Wikipedia Power steering - Wikipedia Electric Power Steering (EPS) System Parts Solutions | NXP Semiconductors Electric power steering system (EPS) Clemson Vehicular Electronics Laboratory: Electric Power-Assisted Steering Electric Steering Rack and Pinion 6 Conclusion This article introduced the Electric Power Steering system architecture, its core components, and its position within a modern EV platform. It outlined the Model-Based Design approach using MATLAB/Simulink and NXP hardware as the development foundation, from algorithm modeling through automatic code generation and hardware deployment. The next article will focus on the software and hardware environment required to develop, simulate, and deploy the EPS control system using MathWorks and NXP solutions.

1 Table of Contents • Introduction • Overview • Context • References • Conclusion 2 Introduction This article provides a high-level overview of the typical workflow for developing an application using the toolbox. It explains how the main development stages fit together, from preparing the environment and selecting the target hardware to configuring the project, generating code, building the application, programming the target, and validating the results. The purpose of this topic is to help users understand the overall process and to guide them toward the related articles that describe each stage in more detail. 3 Overview Workflow Scope The workflow described in this article covers the main steps typically followed when developing an application with the toolbox. After the toolbox and supporting environment are prepared, the user can create a new model or open an existing example, select the target hardware, configure the required software components, prepare the Simulink model, generate code, build the application, program the target device, and debug and validate the behavior on hardware. This article is intended as an overview topic and does not replace the more detailed setup, modeling, and debugging documentation. Target Audience This article is intended for users who want to understand the overall development flow supported by the toolbox. It is useful both for new users who start from supported examples and evaluation boards and for advanced users who need to adapt the workflow to a custom target or project configuration. 4 Context Prerequisites Before following the workflow described in this article, the development environment should already be prepared. The setup process, including toolbox installation and the basic steps required to run an application, is described in the previous article. Depending on the selected project and application requirements, additional tools such as S32 Configuration Tools or EB tresos may be needed, especially when the default project configuration must be modified or when a custom project is created. Toolbox Workflow The development flow typically starts with creating a new project or opening an existing example and then selecting the target hardware. Figure 1. Opening a Simulink project or toolbox example. The selected target determines the available peripherals, supported examples, software configuration options, and build settings. As part of this step, the user can start from the default project associated with the selected target. This default project provides a ready-to-use baseline configuration and is typically the recommended option for evaluation boards and quick start development. For more advanced use cases, the workflow can also use a custom project configuration adapted to the application requirements. Figure 2. Selecting a custom project configuration. If the user continues with the default project configuration, additional low-level software changes may be limited. However, when the default project needs to be modified or when a custom project is used, tools such as S32 Configuration Tools or EB tresos may be required. Figure 3. Low-level software configuration using EB tresos or S32 Configuration Tool.  Figure 4. S32 Configuration Tool Configuration Template. Once the software stack is prepared, the Simulink model must be configured. This includes adding and parameterizing the relevant toolbox blocks, defining the application behavior, setting the model parameters, and aligning the model with the selected target and software configuration. Figure 5. Embedded Coder. Figure 6. Build or Generate Code step. After the model configuration is complete, code can be generated from the Simulink model. This step transforms the model into source code suitable for the selected target platform. The generated output reflects both the model behavior and the configuration settings applied in the previous stages. The generated code is then built using a supported compiler toolchain. The build process compiles and links the generated code together with the required software components and libraries. Build settings may vary depending on the target, compiler version, and selected optimization or debug options. Figure 7. Generated code. After a successful build, the application can be programmed onto the target hardware and executed. At this stage, the user can debug the application using the supported debug tools, inspect signals and variables, and verify that the application behaves as expected on the real hardware platform. Figure 8. Programming and debugging the application on target hardware. The final step of the workflow is validation and iteration. If issues are found during testing or debugging, the user may need to update the model, adjust the low-level software configuration, or modify build settings. The workflow is therefore iterative, allowing repeated cycles of configuration, code generation, build, programming, and validation until the desired result is achieved. Related Topics Additional details for each workflow stage are available in related documentation topics. For environment preparation, toolbox setup, and the basic steps required to run an application, refer to the previous article. More detailed information about model creation and configuration is provided in the next article. Other related topics may include examples library, supported boards and derivatives, low-level software configuration, compiler versions and options, and debugger usage. 5 References For more detailed information, refer to the related toolbox documentation and associated setup, modeling, software configuration, compiler, and debugging articles. MathWorks Simulink MathWorks Embedded Coder Generate Code from Simulink Models 6 Conclusion The toolbox workflow provides a structured path from model-based development to execution on the target hardware. Users can start quickly from the default project associated with the selected target, while still having the flexibility to create and use a custom project configuration when required. By following this workflow and using the related detailed documentation, users can iteratively configure, build, program, debug, and validate their applications more efficiently.

    1 Table of Contents • Introduction • Overview • Context • References • Conclusion     2 Introduction Automotive lighting systems play an essential role in vehicle safety, visibility, and communication with other road users. In general, these systems can be grouped into two main categories: Front Lighting and Rear Lighting. Both help provide road illumination for the driver and signal the vehicle's actions and presence to surrounding traffic. Front Lights - General Role and Functions Front lighting improves the driver's visibility in different driving conditions, including low light, nighttime driving, and adverse weather. It includes several key functions commonly found in modern vehicles, such as: Daytime Running Lights (DRL) - increase vehicle visibility during daytime driving Turn Lights - indicate the driver's intention to change direction Head Lights - provide road illumination during nighttime or low-light conditions Fog Lights - improve visibility in fog, rain, snow, or other low-visibility situations Rear Lights - General Role and Functions Rear lighting is primarily used to communicate the vehicle's status and intentions to other road users. It includes important functions such as: Stop Lights - signal braking actions Head Lights - make the vehicle visible from behind Turn Lights - indicate the intended direction of travel Fog Lights - improve vehicle visibility in low-visibility conditions     3 Overview The lighting system presented in this article is developed using a Model-Based Design (MBD) approach. This methodology enables early validation of system behavior, systematic refinement of the control logic, and a direct path from simulation to embedded implementation. The control behavior is modeled in MATLAB/Simulink, where the functionality is structured into modular and reusable components. Stateflow is used to describe the control logic, providing a clear and formal representation of operating modes, state transitions, and event-driven behavior. The Simulink model runs on the NXP S32K3 platform and communicates with other vehicle nodes via CAN Bus. Message reception and signal handling are managed using the Vehicle Network Toolbox, which simplifies CAN communication by utilizing DBC files without introducing additional hand-written interface code. This integration supports a smooth transition from simulation to embedded deployment through automatic code generation, minimizing the risk of discrepancies between modeled behavior and deployed software. Target audience: Engineers interested in Model-Based Design for automotive applications Those learning or experimenting with simulation-based development and control logic Anyone using NXP automotive hardware platforms who wants to faster develop complex applications on real embedded systems Figure 2 - Front Hazard Lights Activated     4 Context In this project, separate models are implemented for front and rear lighting to showcase the physical layout of the car and keep the logic simple and easier to test. Each lighting area handles its own functions, while staying synchronized with overall vehicle behavior through standard vehicle communication.   Figure 1 - Front and Rear Lights System highlighted within the EV architecture All lighting commands are received via the CAN bus, ensuring consistent and predictable behavior for functions such as Daytime Running Lights (DRL), Head Lights, Fog Lights, Turn Indicators, and Stop Lights. Using CAN-based commands reflects standard vehicle communication practices and allows the lighting logic to be evaluated under conditions close to those in a production system. Incoming CAN messages are processed by the lighting module. Based on vehicle states and received commands, the module: interprets CAN signals and system status, prioritizes lighting functions and handles fault-related conditions, turns on the lights. This structure keeps responsibilities clear: the CAN layer provides high-level commands, while the lighting control logic handles decision-making and execution. The result is a deterministic and easy-to-follow path from vehicle-level inputs to visible lighting behavior. In our project, the system uses addressable LEDs, allowing individual control of multiple light segments within each lamp. This enables a realistic representation of modern automotive lighting systems, where lighting units are no longer simple on/off devices but consist of multiple independently controlled segments. Addressable LEDs rely on a dedicated communication protocol to transfer control data such as color, brightness, and activation timing to each individual LED element. To simplify the integration of this protocol and ensure deterministic behavior, the LED communication was configured and integrated using NXP's Model-Based Design workflow. This approach allows the LED control logic and communication timing to be defined, simulated, and validated directly at model level. The system behavior can be easily followed from input to output, since each step is clearly defined. CAN messages trigger specific actions, and the result is directly visible in the LEDs. This makes the logic straightforward to understand and verify.     5 References Model-Based Design Toolbox (MBDT) Community Model-Based Design Toolbox (MBDT) - S32K3 - How To     6 Conclusion This article provides a simple overview of how Model-Based Design can be applied to develop an automotive lighting system using NXP hardware, focusing on the general architecture and design approach. In the following articles, we will explain the configuration, implementation, and deployment of the lighting system on the NXP hardware.

      1 Table of Contents • Introduction • Overview • Context • References • Conclusion     2 Introduction Virtual vehicles are becoming a common part of modern automotive development, helping teams validate vehicle behavior, driver interaction, and system integration in realistic digital environments before moving to broader physical testing. Figure 1. Virtual vehicle plant model The goal of this first article is to present the virtual vehicle system used in the Hello World demo at a high level and establish the context for the articles that follow. The focus here is on what the subsystem is, why it is relevant in the demo, and how Model-Based Design supports its development within the MathWorks and NXP ecosystem.     3 Overview The importance of this subsystem lies not only in its functional role of simulating the vehicle and linking it to a physical zonal architecture, but also in how it demonstrates an efficient model-based workflow. Rather than building separate assets for vehicle behavior, driver interaction, visualization, and hardware communication, the workflow starts from a configurable virtual vehicle model that can be tested, extended, and connected to other parts of the system. The Virtual Vehicle Composer is a MathWorks tool that enables you to create a Simulink vehicle model for system-level testing, software integration testing, and driver-in-the-loop workflows. The generated model can simulate key vehicle functions such as powertrain, steering, braking, and overall vehicle dynamics. Powertrain Blockset and Vehicle Dynamics Blockset provide reference applications and component models that help define and simulate vehicle behavior in more detail. Simulink 3D Animation supports visualization and interaction with 3D environments, helping connect the vehicle model to a more realistic driving experience. This accelerates development in several ways: The vehicle can be configured and built from a structured workflow rather than assembled manually from scratch. The same model can support simulation, software integration, and connection to external hardware. The built-in 3D interface with Unreal Engine helps connect the vehicle behavior to a realistic visual environment. RoadRunner scenes and scenarios can be incorporated into the simulation workflow to create interactive driving scenarios. CAN communication and feedback from the physical setup can be integrated into the Simulink-based system model. The same workflow can be extended to support additional sensing paths, such as radar data generation and off-board processing on NXP radar hardware. This series is intended for: Engineers learning Model-Based Design with MATLAB and Simulink Developers working with NXP automotive processors and microcontrollers Teams building virtual validation and hardware-connected automotive demonstrations Engineers interested in Driver-in-the-Loop workflows Students and researchers studying vehicle architectures, simulation, and embedded integration Anyone interested in a reproducible example of simulation-to-hardware integration using MathWorks tools and NXP platforms Readers will gain a clearer, step-by-step understanding of how a virtual vehicle can be created, integrated into a 3D driving scene, connected to a physical zonal platform, and used as part of a broader model-based development workflow.     4 Context Created with the Virtual Vehicle Composer, the Simulink hybrid electric vehicle (HEV) model is used not only for standalone simulation, but is reused as the common integration point for driver inputs, RoadRunner-based scene interaction, including actor scenarios implemented in RoadRunner, Unreal Engine visualization, CAN communication, and closed-loop feedback from the physical setup. Figure 2. Virtual vehicle system model In the implemented setup, a driver controls the virtual vehicle through an Xbox-compatible steering wheel and pedals. These inputs are processed by the Simulink model, which updates the vehicle behavior inside a RoadRunner scene rendered through Unreal Engine. At the same time, the virtual vehicle sends key signals such as speed, steering, braking, turn indicators, hazard lights, and beam light commands over CAN to a physical setup that represents an electric vehicle built from multiple NXP reference boards organized in a zonal architecture. The physical platform includes a main node, zonal nodes, and multiple end nodes. These elements receive the simulation-driven commands and reproduce the state of the virtual vehicle in hardware. Communication is bidirectional, so feedback generated by the physical setup can also influence the simulated vehicle. For example, if front or rear parking sensors detect an obstacle, that information can be returned to the virtual vehicle model and used to trigger braking behavior. All major functional aspects of this interaction, including driver input handling, vehicle behavior, signal exchange, and feedback response, are defined in the Simulink model. This supports rapid refinement and validation before deeper integration into the full system. An additional part of the setup extends the virtual vehicle interaction toward sensing and perception workflows. Actor poses from the virtual scene are used to generate a radar cube, which is sent to an NXP S32R45 board that runs a radar processing chain. This expands the role of the virtual vehicle beyond motion and body-domain interaction. It shows how the simulated environment can also stimulate external sensing functions and hardware processing paths as part of the same demo workflow. Figure 3. Virtual Vehicle highlighted within the demo The virtual vehicle component is highlighted in the architecture diagram from Figure 3 to show its position in the overall project setup and its connection to the driver interface, the 3D environment, the physical zonal platform, and the radar processing path. The next articles in the series will build on this system overview and examine the virtual vehicle in more detail, including the software and hardware environment, the model architecture, the vehicle creation workflow, the driver input options, RoadRunner and Unreal integration, CAN communication, and the final results and challenges observed during development.     5 References The following resources provide useful background for the technologies referenced in this article: MathWorks documentation for Virtual Vehicle Composer MathWorks virtual vehicle documentation and examples MathWorks RoadRunner documentation MathWorks documentation for Unreal Engine simulation with Simulink NXP Model-Based Design Toolbox overview     6 Conclusion The virtual vehicle subsystem provides the foundation for the Hello World demo by supplying a reusable vehicle model that supports simulation, validation, and integration within a model-based workflow. This article established its purpose and position in the overall architecture. In the next articles, we will move from this high-level overview to the practical details of how the subsystem is created, connected, and exercised in the complete demo.

  1 Introduction Turning a motor control concept into a running dual-motor traction real system requires more than a control algorithm. It requires a connected software and hardware environment that can take the design from simulation to generated code, from target deployment to real-time calibration, and finally to validation on physical motors. This article continues the Motor Control System series by moving from the system-level overview to the enablement layer behind the application. It highlights the MathWorks and NXP tools, software components, MCU resources, and power-stage building blocks that make the Dual-Motor EV traction system possible. At the core of the workflow is Model-Based Design. MathWorks tools are used to model the field-oriented control algorithms, define the CAN communication interfaces, and support validation across simulation stages. NXP tools then bring those models onto the S32K396 target platform, connecting the generated application to real-time peripherals, gate-driver hardware, and motor feedback signals. Together, these elements form the development backbone of the dual-motor application: a path that starts with definition of the control strategy and ends with validation on real hardware. 2 Table of Contents • Software • Hardware • References • Conclusion 3 Software The software environment provides the modeling, simulation, communication, code generation, and deployment capabilities required by the Motor Control System. Each tool contributes a specific part of the development flow. 3.1. Motor Control Blockset Motor Control Blockset is the control-algorithm engine behind the traction application. It provides a ready-to-use environment for designing, simulating, and deploying motor control algorithms, while also supporting optimized C code generation from Simulink. In this Motor Control System, the MCB models the Field-Oriented Control strategy for Permanent Magnet Synchronous Motors. It supports the main control-loop blocks. These include Clarke and Park transforms, current and speed regulation, Space Vector Modulation, and position or speed feedback processing. The same model can run across desktop simulation and real-time validation. This keeps the controller consistent from early algorithm work to target execution. It also aligns the design across Model-in-the-Loop, Software-in-the-Loop, Processor-in-the-Loop, and hardware deployment stages. For more information, see the Motor Control Blockset documentation in the References chapter. 3.2. Vehicle Network Toolbox Vehicle Network Toolbox brings CAN communication into the model-based workflow. It provides MATLAB functions and Simulink blocks for sending, receiving, encoding, and decoding CAN messages. This makes network behavior visible and testable before deployment. In the Motor Control System, CAN exchanges commands, feedback, and status information. It links the ECU with the surrounding vehicle architecture. The toolbox helps define the signal interface, pack and unpack CAN frames, simulate bus traffic, and validate communication behavior before target execution. Communication is not treated as a late integration step. CAN interaction can be simulated and verified together with the control model. This reduces integration risk and makes ECU behavior easier to validate end to end. For more information, see the Vehicle Network Toolbox documentation in the References chapter. 3.3. NXP Model-Based Design Toolbox for S32K3 NXP Model-Based Design Toolbox for S32K3 connects the Simulink model to the NXP S32K3 target environment. It provides the embedded target support required to generate, build, download, and run applications on NXP microcontrollers. The toolbox provides peripheral blocks for hardware access. These include interfaces for ADC, PWM, CAN, SPI, UART, timers, interrupts, and other target resources used by motor control applications. For the Motor Control System, the toolbox enables the generated application to run on top of the S32K3 software stack. It also supports configuration flows based on NXP tools, real-time data visualization with FreeMASTER, and integration with optimized libraries such as AMMCLib. NXP Model-Based Design Toolbox for S32K3 is used as part of the enablement environment for the S32K3 complex applications. It provides the bridge between the model and the production-oriented embedded implementation. 4 Hardware The hardware environment provides the real-time execution platform and the power stage interface required to control the motors. The key hardware components are the NXP S32K396 microcontroller and the NXP MC33937 three-phase FET pre-driver. 4.1. The NXP S32K396 Microcontroller The NXP S32K396 is the main processing device used by the Motor Control System. It belongs to the S32K39 family of electrification microcontrollers and is optimized for traction inverter, torque vectoring, and smart actuation applications. The device combines real-time compute, motor control acceleration, advanced analog acquisition, high-resolution actuation, safety mechanisms, security services, and automotive networking in a single MCU platform. At the compute level, the S32K396 provides Arm Cortex-M7 processing resources running up to 320 MHz. The architecture supports safety-oriented execution through lockstep and split-lock configurations. This enables separation between safety-critical motor control tasks and additional monitoring or communication functions. For motor control, the device includes a dedicated motor control coprocessor called eTPU (Enhanced Time Processing Unit) and a programmable CoolFlux DSP. These resources can offload timing-critical functions from the main CPU. They support fast current-loop execution, resolver processing, PWM generation, analog sensing, and other functions required by high-performance FOC applications. The smart timer and I/O subsystem is also important for traction control. The S32K396 includes eFlexPWM modules with NanoEdge capability, eMIOS channels, Logic Control Units, and Body Cross-Triggering Units. These blocks help synchronize PWM generation, ADC triggering, fault handling, and real-time control events. The analog subsystem supports the feedback path of the inverter. It includes multiple SAR ADCs, Sigma-Delta ADCs, analog comparators, and sine wave generators. These resources are used to acquire phase currents, DC bus voltage, phase voltages, temperature signals, and position-related feedback. The communication subsystem enables integration with the vehicle network and external devices. The S32K396 provides CAN FD, Ethernet with TSN support, LIN/UART, SPI, I2C, QSPI, FlexIO, and Zipwire interfaces. In this Motor Control System, CAN is used for vehicle-level command and status exchange. Figure 4-1. S32K396 Block Diagram In the Motor Control System, the S32K396 executes the real-time control loops, reads current and voltage feedback, processes rotor position or speed information, generates PWM signals, and exchanges data with the vehicle network over CAN. The same platform can support one six-phase motor or two three-phase motors. This makes it suitable for the dual rear-motor architecture used throughout this article series. 4.2. The NXP MC33937 Three-Phase FET Pre-Driver The NXP MC33937 is the three-phase Field Effect Transistor pre-driver used between the microcontroller and the inverter power switches. It is designed for three-phase motor control and similar automotive actuation applications. The device contains three high-side FET pre-drivers and three low-side FET pre-drivers. Together, these six gate-drive channels control the external MOSFET bridge used by the three-phase inverter. The MC33937 interfaces with the S32K396 through six direct input control signals. These signals provide the fast phase control path from the PWM outputs of the microcontroller to the gate-driver stage. The device also includes an SPI interface. SPI is used for device setup, configuration, diagnostics, and safe control features. Reset, enable, and interrupt pins provide additional control and fault signaling between the pre-driver and the MCU. The MC33937 supports an extended operating range from 6 V to 58 V and is fully specified from 8 V to 40 V. This makes it suitable for 12 V and 24 V automotive systems, as well as higher-voltage transient operating conditions. The MC33937 also provides protection and monitoring features needed in motor control applications. These include undervoltage detection, overcurrent comparison, desaturation comparison, temperature limitation, phase voltage comparison, and protection against reverse charge injection from the external FETs. The device accepts both 3.3 V and 5 V logic-level inputs and provides 5 V logic-level outputs. This simplifies the connection with automotive microcontrollers and allows the pre-driver to fit into different control board designs. Figure 4-2. MC33937 Block Diagram In the Motor Control System, the MC33937 forms the actuation bridge between the PWM signals generated by the S32K396 and the three-phase inverter that drives each PMSM. It converts logic-level control commands into the gate-drive signals required by the external power stage. 4.3. NXP Evaluation Boards The Motor Control System hardware is built from modular NXP evaluation boards. This allows the same S32K396 control platform to be connected to one or two low-voltage three-phase inverter stages. Figure 4-3. NXP S32K396-BGA-DC1 The S32K396-BGA-DC1 evaluation board is the main controller board. It contains the S32K396 microcontroller in MAPBGA 289 package, an onboard debugger, communication interfaces, and the connectors required to access the real-time control signals. It is optimized for electrification applications such as traction drive and torque vectoring. The S32X-MB board is used as an I/O extension board. It is not a standalone development board. It must be used together with a compatible S32K39/37 evaluation board. In this setup, it expands the number of accessible peripherals and provides an additional motor control connector. Figure 4-4. S32X-MB Board The MCSPTR2AK396 kit provides the low-voltage motor control power stage used in the demo. From this kit, the demo uses the three-phase low-voltage pre-driver board and the PMSM motor. The power stage is based on the MC33937A pre-driver and is designed for BLDC or PMSM control. Figure 4-5. 3-Phase Low Voltage Motor Control Kit The kit also provides useful motor control interfaces. These include the three-phase motor output, Hall or encoder interface, resolver interface, DC bus sensing, phase voltage sensing, and protection feedback. These signals are required to close the control loop on the target hardware. 4.4. Dual-Motor Hardware Connections For the dual-motor hardware set-up, the S32K396-BGA-DC1 board provides the main MCU resources. The first three-phase motor control channel is connected through the primary motor control connector. The second channel is routed through the S32X-MB extension board. Each motor channel uses one low-voltage three-phase pre-driver and one PMSM motor. The PWM signals generated by the S32K396 are routed to the MC33937A gate-driver stage. The pre-driver then controls the external MOSFET bridge of the inverter. The feedback path is routed back from each power stage to the MCU. This includes phase current feedback, DC bus voltage, phase voltage, and position or speed feedback from the selected sensor interface. These signals are sampled and synchronized with the PWM events. The S32K396 therefore controls two independent three-phase inverter stages. Each motor has its own PWM outputs, sensing path, position feedback, and protection signals. The control software coordinates both channels and exchanges the resulting status information over CAN. This hardware arrangement can also be viewed as a scalable topology. The same MCU platform can be used for two independent three-phase motors or for one six-phase motor, depending on how the PWM outputs, sensing resources, and power stages are mapped. By connecting the software workflow with the hardware execution path, this enablement layer shows how a model-based motor control concept can be taken from algorithm design to a running dual-motor traction demonstrator on NXP silicon.   5 References Motor Control Blockset Documentation Vehicle Network Toolbox Documentation NXP Model-Based Design Toolbox for S32K3 S32K39-37-36 Microcontrollers for Electrification Applications MC33937: 3-Phase Field Effect Transistor Pre-Driver S32K396-BGA-DC1 Evaluation Board MCSPTR2AK396 BLDC/PMSM Motor Control Development Kit S32X-MB I/O Extension Evaluation Board 6 Conclusion This article described the software and hardware enablement required for the Motor Control System. The software environment combines MathWorks motor control and vehicle network capabilities with NXP target support. The hardware environment combines the S32K396 microcontroller with the MC33937 pre-driver and the inverter stage. Together, these elements provide the foundation for modeling, simulation, communication, code generation, deployment, and validation of the dual-motor control application. The next article will focus on the architecture and model description of the Motor Control System, including the main control layers, signal interfaces, and application structure.