1 Table of Contents •Introduction •Overview •Context •Component Overview •Design and Implementation •Results •Common Pitfalls & Troubleshooting •Summary & Next Steps •References 2 Introduction A virtual vehicle can reproduce vehicle dynamics, driver inputs, road scenarios, sensor stimuli, and network communication long before the complete physical vehicle is available. However, a successful desktop simulation answers only one part of the engineering question: does the algorithm behave correctly as a model? Processor-in-the-Loop (PIL) adds the target processor to the validation loop. The plant, scenario, and test harness remain in MATLAB ® and Simulink ® , while selected generated algorithm code is cross-compiled, downloaded, and executed on the NXP processor. Inputs are sent from the host to the target, and the computed outputs are returned to the simulation for comparison and analysis. This makes PIL the bridge between a virtual vehicle that behaves correctly on the development computer and embedded software that must produce equivalent results on its intended processor. It also provides target-based execution-time measurements, helping engineers assess whether an algorithm is not only functionally correct, but also suitable for its timing budget. 3 Overview This article presents how Processor-in-the-Loop fits into a Model-Based Design workflow for virtual vehicle development. The goal is to show where PIL adds value between desktop simulation and deeper hardware integration, and how the same virtual vehicle and scenario can be reused to validate generated code on the target processor. In this workflow, the model remains the starting point. The virtual vehicle provides the plant behavior, the simulated environment provides repeatable driving conditions, and the selected algorithm is generated and executed on target hardware. PIL therefore supports a controlled transition from model behavior to target implementation behavior.   Figure 1. PIL connects virtual vehicle simulation with generated algorithm execution on target hardware. 4 Context The practical context for this article is the Hello World with the Model-Based Design Toolbox — Model. Generate. Drive. project. In that setup, driver inputs come from a physical steering wheel and pedals, the vehicle is driven through a RoadRunner simulated environment, and an S32N processor communicates with the host simulation while making vehicle-level decisions. The virtual vehicle is created with MathWorks tools and reused as the common integration point for driver inputs, vehicle behavior, RoadRunner scene interaction, Unreal Engine visualization, CAN communication, and closed-loop feedback from the physical setup. From that perspective, PIL is not used to move the entire virtual world to the processor. Instead, the virtual vehicle and simulated scenario remain on the host while selected generated algorithms are executed on the target. This keeps the environment flexible and repeatable while bringing processor behavior into the validation loop. 5 Component Overview A PIL-enabled virtual vehicle workflow combines the following elements: Virtual vehicle - represents vehicle dynamics, driver interaction, powertrain, steering, braking, CAN communication, and feedback paths. Virtual scene and scenario - provides roads, lanes, signs, intersections, actors, traffic movement, and repeatable test conditions using RoadRunner and Unreal Engine. PIL component - contains the selected generated algorithm code that is cross-compiled and executed on the target processor. S32N main node - acts as an aggregator and decision-maker, receiving information from sensing nodes and sending high-level commands to actuator nodes. S32N positioning: S32N is a suitable solution for running complex central-compute algorithms in PIL because it is positioned at the point where vehicle-level decisions, aggregated data, CAN communication, and actuator commands come together. 6 Design and Implementation A practical PIL workflow starts by selecting a bounded algorithm and keeping the plant, scene, and test harness on the host. This makes the test setup easier to control and keeps the comparison focused on the generated target implementation. 6.1 Select the algorithm boundary Relevant candidates include data aggregation, vehicle-level decision logic, Automated Emergency Braking logic, actuator command generation, CAN signal processing, and telemetry preparation. 6.2 Create repeatable virtual tests Use the simulated environment to define controlled driving conditions such as road geometry, actors, traffic movement, obstacle placement, and driver commands. The same scenario can be replayed for model and PIL execution. 6.3 Establish the model baseline Run the selected scenario with the original Simulink implementation and log the component inputs, outputs, and vehicle-level signals required for comparison. 6.4 Run the generated implementation in PIL Generate and build the selected component for the supported S32N5 target configuration. During the PIL run, Simulink sends test vectors to the target and receives the target results while the rest of the virtual vehicle continues to execute on the host. 6.5 Compare and profile Compare model and PIL outputs using the acceptance criteria defined for the algorithm. Where supported, collect target-side execution-time data to evaluate whether the generated component fits its timing budget. PIL Setup on S32N5. 7 Results The result of this workflow is a direct comparison between model behavior and generated code running on the target. A useful result set shows whether target outputs remain equivalent to model outputs, whether decision thresholds and state transitions occur under the same scenario conditions, and whether the target-side execution time fits the assigned budget. Because the virtual scenes are controlled and repeatable, failing cases can be preserved as regression scenarios and rerun after model, configuration, or implementation changes. 8 Common Pitfalls & Troubleshooting The PIL boundary is too large - keep the virtual world, visualization, and detailed plant on the host. Simulation time is confused with target execution time - use target-side profiling for algorithm timing conclusions. Model and target interfaces differ - keep signal definitions, data types, scaling, units, and sample times consistent. CAN definitions are inconsistent - reuse the same DBC definitions across the simulation and physical network. PIL is treated as complete system validation - PIL validates selected generated code on the processor; full distributed-system behavior still requires later integration stages. 9 Summary & Next Steps PIL connects the virtual vehicle, simulated scenarios, and S32N5 target execution into one validation flow. The host continues to simulate the driver, vehicle, road, actors, and environment, while selected generated main-node algorithms execute on the S32N5. A practical next step is to select one bounded S32N5 function, define its acceptance criteria, and replay a representative RoadRunner scenario first with the model and then in PIL. Suitable starting points include data aggregation, AEB decision logic, high-level actuator command generation, or CAN signal processing. 10 References Hello World with the Model-Based Design Toolbox — Model. Generate. Drive. Creating virtual vehicle with MathWorks - Overview Creating Virtual Scenes & Scenarios with MathWorks (RoadRunner & Unreal Engine) MathWorks: Processor-in-the-Loop Simulation

      1 Table of Contents • Introduction • Required Software • Required Hardware • References • Conclusion     2 Introduction This article is part of the Zone Node series and describes the software and hardware environment used throughout the project. The purpose of this article is to describe the software and hardware setup required to follow the series and reproduce the results. Before examining communication routing, control logic, or integration challenges, it is important to understand the tools and platforms that support the development and execution of the zonal node application. This article introduces the software components used to develop, configure, and deploy the application, as well as the hardware platforms used to demonstrate the zonal controller functionality. This information provides the foundation required for the remaining articles in the series. Overview of the development flow The zonal node application presented in this series is developed using a combination of Model-Based Design tools, NXP software components, and automotive-grade hardware platforms. At a high level: Application modeling starts in MATLAB® and Simulink®, where communication routing and control logic are implemented graphically. Code generation converts the model into production-ready embedded software using the code-generation tools provided by MathWorks and NXP. Deployment compiles the generated software and loads it onto the target hardware, where it is used to demonstrate communication between multiple vehicle networks. This environment was selected to support rapid development, easier validation, and improved traceability between model design and generated software. By using a Model-Based Design approach, algorithm development, communication integration, and application verification can be performed within a common framework. The software and hardware presented here are used consistently throughout the series and will be referenced when discussing communication routing, system behavior, and integration scenarios. ㅤ Figure 1. Development flow diagram The workflow begins with application development in Simulink. Communication routing logic, control functions, and software configuration are implemented within the model. The NXP Model-Based Design Toolbox (MBDT) provides hardware-specific blocks that enable integration with S32K3 peripherals and communication interfaces. Following code generation, the application is compiled and deployed to the target hardware, where communication routing functionality can be validated. This article is intended for: Engineers interested in reproducing the zonal node demonstration Simulink users developing automotive communication applications Developers evaluating Model-Based Design workflows Engineers working with NXP automotive microcontrollers and evaluation boards By understanding the software and hardware environment early in the series, readers will be better prepared to follow the implementation details presented in subsequent articles.     3 Required Software The following software components are used throughout the project: MATLAB® and Simulink® – model development and simulation Embedded Coder® (required MATLAB toolbox) – automatic code generation from the model Simulink models – the zonal node routing application model referenced throughout the series NXP Model-Based Design Toolbox (MBDT) – S32K3 support and peripheral configuration NXP additional tools – FreeMASTER and S32 Design Studio for build, deployment, and debugging CAN analysis software – monitoring and validating CAN communication LIN analysis software – monitoring and validating LIN communication 3.1 MATLAB® and Simulink® MATLAB® and Simulink® form the foundation of the development environment. They are used to create the zonal node application, implement communication routing logic, configure software behavior, and perform model-based verification activities. The application described throughout this series is developed as a Simulink model and later translated into embedded software using automatic code-generation tools (Embedded Coder®). 3.2 NXP Model-Based Design Toolbox (MBDT) The NXP Model-Based Design Toolbox (MBDT) extends Simulink with hardware-specific support for NXP automotive microcontrollers. For this project, MBDT for S32K3 version 1.8.0 is used. The toolbox provides blocks and configuration interfaces for communication peripherals, timers, digital I/O resources, and other hardware modules available on the target device. It also integrates with the code-generation workflow, allowing Simulink models to be converted into software that can run directly on the S32K3 microcontroller. Note: Installation and configuration instructions are provided in the dedicated article series (How to install .MLTBX). Readers who have not yet installed the toolbox should complete that step before continuing with this series. 3.3 CAN Analysis Software CAN analysis tools are used during development and validation to observe CAN and CAN FD traffic exchanged between the zonal node and other network participants. Typical use cases include: Monitoring transmitted and received CAN frames Verifying CAN-to-CAN routing behavior Measuring message timing and bus utilization Troubleshooting communication issues Examples of commonly used software include PCAN-View, CANalyzer, and CANoe. 3.4 LIN Analysis Software LIN analysis tools are used to monitor communication between the zonal node and LIN-connected edge devices. Typical use cases include: Verifying LIN schedule execution Monitoring frame transmission and reception Validating signal timing and integrity Testing LIN-to-CAN routing scenarios Examples of commonly used software include PLIN-View and LINalyzer.     4 Required Hardware The following hardware components are used throughout the project: S32K344 automotive microcontroller – used to execute the zonal node application S32K344-WB Evaluation Board – used as the development and validation platform CAN analysis hardware – used to monitor and verify CAN/CAN FD communication LIN analysis hardware – used to monitor and verify LIN communication 4.1 S32K3 Microcontroller The S32K3 family provides: Arm® Cortex®-M7 processing cores CAN FD communication interfaces LIN communication support Safety-oriented automotive features Low-power operating modes Rich peripheral connectivity These capabilities make the device suitable for implementing communication aggregation and routing functions within the scope of this project. 4.2 Evaluation Hardware The zonal node application runs on the S32K344-WB Evaluation Board, a development platform based on the NXP S32K344 microcontroller. The board provides access to the communication interfaces and processing capabilities of the target device while offering an integrated platform for software development, debugging, and validation activities. Within the scope of this project, the board is used to execute the routing application and exchange messages with nodes connected through CAN and LIN networks. Its communication interfaces, debugging connectivity, and expansion capabilities make it suitable for evaluating zonal communication architectures and routing scenarios. ㅤ Figure 2. S32K344-WB evaluation board 4.3 Communication Networks The examples presented throughout this series use CAN and LIN networks to demonstrate message forwarding, routing, and protocol translation scenarios. These networks provide the communication backbone between the zonal node, central controller, and edge nodes, and are referenced throughout the upcoming routing and integration articles. 4.4 Network Analysis Hardware Additional hardware tools are used during development and validation to observe network traffic and verify communication behavior. CAN analysis interfaces can be connected to the network to monitor transmitted and received CAN/CAN FD frames, validate routing functionality, and troubleshoot communication issues. LIN analysis interfaces can be used to monitor LIN schedules, frame exchanges, and LIN-to-CAN routing scenarios. These tools provide visibility into network activity and support verification of the communication flows presented in later articles of this series.     5 References Model-Based Design Toolbox (MBDT) Embedded Coder® Documentation MATLAB® and Simulink® Documentation S32K3 Microcontrollers S32K344-WB Evaluation Board     6 Conclusion This article introduced the software and hardware environment used throughout the zonal node project. It presented the development tools, code-generation workflow, and target hardware that support the implementation of the communication routing application. The next article will build on this foundation by examining the internal logic control mechanisms used within the zonal node and how they contribute to communication handling across multiple networks.

      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 Radar (Radio Detection and Ranging) is a key sensing technology in modern vehicles, used to perceive the environment by transmitting radio waves and analyzing their reflections from surrounding objects. In automotive systems, radar enables reliable detection under a wide range of weather and lighting conditions. This article introduces the automotive radar node of our demo and explains how it can be integrated into a modern vehicle electronic architecture.   2 Table of Contents •Introduction •Overview •Context •References •Conclusion   3 Overview How radar supports automotive systems Within an automotive system, the radar node plays a central role in advanced driver assistance systems (ADAS) and automated driving functions, such as adaptive cruise control, collision avoidance, and blind-spot detection. It continuously measures object presence and motion in the vehicle’s surroundings, providing robust and real-time perception data. In this implementation, the radar application is developed using NXP’s Model-Based Design Toolbox for Radar, a MATLAB add-on developed by NXP. By using this toolbox, developers can design, simulate, and generate code while leveraging the hardware accelerators available on the target platform to achieve high performance and deterministic execution. The offloading of processing to the accelerators is achieved through the integration of the NXP Radar SDK within the MATLAB environment. Target Audience This series of articles serves a wide range of engineering and technical stakeholders involved in the design, development, and integration of radar systems. This chapter outlines the intended audience: Embedded Software Engineers Radar Engineers System Architects & Vehicle Architecture Engineers Hardware Engineers Model-Based Design and MATLAB Developers Academic and Research Communities   4 Context The radar application is targeted for the NXP S32R45 MCU, a high-performance processor designed specifically for automotive radar signal processing. In the vehicle electronic architecture, the radar node is connected directly to the Central Node, which is responsible for sensor fusion and higher-level decision-making. For each radar frame, the NXP S32R45 MCU detects and processes objects in the field of view and transmits, via CAN, the distance, speed, and direction of each detected object to the Central Node. This structured data exchange enables efficient integration of radar information into the overall vehicle perception and control system.   Figure 1. Example integration of the radar node into a vehicle electronic architecture.   5 References MathWorks Model-Based Design Toolbox for RADAR Community Accelerate the Discrete Fourier Transform with NXP SPT   6 Conclusion In conclusion, the radar node is a fundamental building block of the modern vehicle electronic architecture, providing accurate and reliable perception data that enables advanced safety and automation functions. This introductory chapter has outlined the role of the radar node within the vehicle system and its contribution to environment perception for advanced driving functions. The next chapters will build on this foundation by exploring the radar signal processing chain, the implementation approach, and the main software components that enable the application on the target platform.

    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 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 Software & Hardware Environment for Parking Sensor System 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.

Plot embedded data in a Chart or Gauge in a Web Browser

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

      1 Table of Contents • Introduction • Software Environment • Hardware Environment • References • Conclusion     2 Introduction Turning a vehicle concept into an interactive Virtual Vehicle requires more than a standalone simulation model. It requires a connected software and hardware environment that can define the vehicle architecture, simulate the powertrain and vehicle dynamics, place the vehicle in realistic driving scenarios, visualize the behavior in 3D, and allow user interaction through driver-in-the-loop inputs. This article continues the Virtual Vehicle system series by moving from the system-level overview to the enablement layer behind the application. It highlights the MathWorks tools and host-side hardware resources that make the virtual vehicle demonstrator possible. At the core of the workflow is Model-Based Design. MathWorks tools are used to configure the vehicle architecture with Virtual Vehicle Composer, model the powertrain and vehicle dynamics, define and execute driving scenarios, create 3D road environments, exchange CAN-based signals, and analyze simulation results. The same environment also supports interactive execution, where driver inputs from a steering wheel and pedals can influence the virtual vehicle behavior during scenario playback.     3 Software Environment The software environment provides the modeling, simulation, scenario definition, visualization, communication, and analysis capabilities required by the Virtual Vehicle system. Each MathWorks tool contributes a specific part of the workflow, from vehicle architecture definition and plant modeling to 3D scenario execution and CAN-based interaction with external systems. 3.1 MATLAB and Simulink R2025b MATLAB and Simulink form the central engineering environment for the Virtual Vehicle. Figure 1. MATLAB MATLAB provides the scripting, data management, parameterization, and analysis capabilities required to configure simulations, process logged signals, and evaluate test results. Figure 2. Simulink Simulink provides the model-based design environment in which the virtual vehicle, control logic, communication interfaces, and test harnesses are assembled. The system-level model can connect plant models, vehicle dynamics, driver inputs, scenario interfaces, and network communication blocks into a single executable simulation. 3.2 Virtual Vehicle Composer Figure 3. Virtual Vehicle Composer Virtual Vehicle Composer is the configuration and assembly environment used to create the Virtual Vehicle model. It allows the user to define the vehicle class, select the powertrain architecture, choose the vehicle dynamics fidelity, configure components, specify test scenarios, select logged signals, build the vehicle model, run the configured tests, and analyze the results. In this Virtual Vehicle system, Virtual Vehicle Composer acts as the entry point for building a consistent vehicle model. It assembles the selected architecture from predefined and customizable components and prepares the model for closed-loop simulation in Simulink. The app also supports repeatable test execution. The same virtual vehicle can be operated across selected scenarios, while relevant signals are logged for review. This makes it suitable for early design studies, component comparison, control validation, and system-level behavior analysis before moving to hardware integration. 3.3 Powertrain Blockset Figure 4. Powertrain Blockset Powertrain Blockset provides the vehicle powertrain modeling foundation for the Virtual Vehicle model. It includes reference applications and component libraries for conventional, hybrid, and battery-electric propulsion systems. In this system, Powertrain Blockset supports the definition of the propulsion architecture, energy storage, electric motors, drivetrain elements, tires, driver models, and supervisory control behavior. It also provides workflows that help configure, resize, calibrate, and analyze the selected powertrain components. The generated vehicle model can be used for performance analysis, energy management studies, range evaluation, component sizing, control parameter optimization, and hardware-in-the-loop preparation. Because the models are open, project-specific subsystems can be integrated into the generated architecture when needed. 3.4 Vehicle Dynamics Blockset Figure 5. Vehicle Dynamics Blockset Vehicle Dynamics Blockset provides the vehicle motion and handling foundation for the Virtual Vehicle. It includes reference applications and component libraries for propulsion, steering, suspension, vehicle body, brakes, tires, driver models, and supervisory controllers. For the Virtual Vehicle system, the blockset enables different levels of vehicle dynamics fidelity depending on the simulation objective. Longitudinal dynamics can be used for drive-cycle and energy studies, while combined longitudinal, lateral, and vertical dynamics can be used for handling, chassis behavior, and more complex driving scenarios. The blockset also supports 3D visualization workflows, allowing the virtual vehicle behavior to be observed in a realistic environment. This helps connect numerical simulation results with intuitive visual feedback during ride, handling, ADAS, and driver-in-the-loop demonstrations. 3.5 Automated Driving Toolbox Figure 6. Automated Driving Toolbox Automated Driving Toolbox supports the definition, simulation, and analysis of driving scenarios used to exercise the Virtual Vehicle. It provides capabilities for creating road layouts, actors, trajectories, sensor-related contexts, and repeatable test cases. In this setup, the toolbox is used to create controlled and repeatable traffic situations around the ego vehicle. These scenarios can be used to evaluate how the virtual vehicle behaves in predefined maneuvers, traffic interactions, lane-following conditions, or other driving situations relevant to the demonstration. By combining scenario definition with the vehicle model, the Virtual Vehicle can be validated in a structured way. Instead of testing only isolated model behavior, the complete system can be exercised against realistic road and traffic conditions. 3.6 Vehicle Network Toolbox Vehicle Network Toolbox.pngFigure 7. Vehicle Network Toolbox Library Vehicle Network Toolbox brings vehicle network communication into the model-based workflow. It provides MATLAB functions and Simulink blocks for sending, receiving, encoding, and decoding messages over in-vehicle network protocols such as CAN, CAN FD, J1939, and XCP. In the Virtual Vehicle, the toolbox is used to exchange selected vehicle signals with external systems or hardware components. CAN messages can be packed and unpacked using database-driven definitions, allowing the model to follow the same signal structure expected by the vehicle-level architecture. This makes communication behavior visible and testable during simulation. Commands, feedback, status information, and selected virtual vehicle signals can be validated before deployment or integration with physical controllers, reducing late-stage integration risk. 3.7 RoadRunner Figure 8. RoadRunner RoadRunner provides the 3D scene creation environment used by the Virtual Vehicle system. It enables the design of detailed road networks, intersections, lane markings, traffic signs, buildings, terrain, and other environmental assets required for realistic driving simulation. In this workflow, RoadRunner supplies the visual and spatial context in which the virtual vehicle operates. The generated scenes can represent controlled proving-ground layouts, urban intersections, highway segments, or demonstration environments used for scenario execution. When combined with Simulink and the vehicle model, RoadRunner helps transform the simulation from a signal-level model into an interactive visual experience. This is especially useful for driver-in-the-loop demonstrations, ADAS workflows, and stakeholder-facing presentations. 3.8 Simulink 3D Animation Figure 9. Simulink 3D Animation Library Simulink 3D Animation connects Simulink models and MATLAB algorithms to a 3D simulation environment, enabling dynamic systems to be visualized in photorealistic scenes. In the Virtual Vehicle system, it provides the visualization and interaction layer used to observe vehicle behavior in a 3D environment during simulation. The toolbox can use prebuilt scenes or imported scenes created in RoadRunner, and it allows vehicles, objects, lighting, weather effects, and sensor-related elements to be controlled during simulation. This makes it suitable for connecting the Virtual Vehicle model to visually rich driving environments. For driver-in-the-loop operation, Simulink 3D Animation also supports interactive navigation and manual control through hardware devices. This allows steering wheel and pedal inputs to influence the simulated vehicle while the resulting motion is visualized in the 3D scene. 3.9 Stateflow Figure 10. Stateflow Library Stateflow provides the graphical environment for modeling state machines, decision logic, and event-driven behavior inside the Virtual Vehicle system. It is used when vehicle behavior must depend on operating modes, transitions, conditions, timers, or fault states. Within the Virtual Vehicle model, Stateflow can support supervisory control, mode management, scenario state handling, driver input interpretation, startup and shutdown sequencing, or fallback behavior. This helps separate discrete decision logic from continuous plant and controller behavior. Using Stateflow keeps the system behavior easier to understand, review, and validate. Complex conditions can be represented explicitly as states and transitions, which improves traceability during simulation and debugging.     4 Hardware Environment The hardware environment provides the execution platform, user input interface, and visualization resources required to operate the Virtual Vehicle system interactively. The main components are the GPU-accelerated PC and the Xbox-compatible steering wheel and pedal controller. 4.1 PC with GPU Acceleration The PC is the main host platform for the Virtual Vehicle system. It runs MATLAB, Simulink, Virtual Vehicle Composer, RoadRunner-related workflows, and the supporting toolboxes used to model, simulate, visualize, and analyze the vehicle behavior. GPU acceleration is important because the system includes visually rich 3D scenes and interactive simulation workflows. The graphics hardware helps render the driving environment smoothly, maintain responsive visualization, and support a more realistic driver-in-the-loop experience. In this setup, the PC also acts as the integration point between the simulation model, the 3D environment, the input devices, and any external communication interfaces. This makes it the central execution and orchestration node of the Virtual Vehicle demonstration. 4.2 Xbox-Compatible Wheel Controller Xbox-Compatible Wheel Controller The Xbox-compatible wheel controller provides the physical driver input interface for the Virtual Vehicle system. It allows the user to control steering, acceleration, and braking through a steering wheel and pedal set instead of using keyboard-based commands. This input device makes the simulation suitable for driver-in-the-loop demonstrations. User actions can be mapped into the Simulink model and used to influence the virtual vehicle response during scenario execution. The wheel controller improves the realism and accessibility of the demonstration. It allows engineers and stakeholders to experience the virtual vehicle behavior interactively, making it easier to evaluate the relationship between driver input, vehicle response, and 3D scene feedback.     5 References The following resources provide useful background for the technologies referenced in this article: MathWorks MATLAB and Simulink documentation MathWorks Virtual Vehicle Composer documentation MathWorks Powertrain Blockset documentation MathWorks Vehicle Dynamics Blockset documentation MathWorks Automated Driving Toolbox documentation MathWorks Vehicle Network Toolbox documentation MathWorks RoadRunner documentation MathWorks Simulink 3D Animation documentation MathWorks Stateflow documentation     6 Conclusion This section described the software and hardware enablement required for the Virtual Vehicle system. The software environment combines MATLAB and Simulink with Virtual Vehicle Composer, Powertrain Blockset, Vehicle Dynamics Blockset, Automated Driving Toolbox, Vehicle Network Toolbox, RoadRunner, Simulink 3D Animation, and Stateflow to support vehicle configuration, system-level modeling, scenario execution, 3D visualization, communication, and analysis. The hardware environment combines a GPU-accelerated PC with a steering wheel and pedal controller to support interactive driver-in-the-loop execution. Together, these elements provide the foundation for building, operating, visualizing, and validating the virtual vehicle before integration with physical controllers or target hardware.

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 • Pins Configuration • Configure Port Component • Conclusion • References 2 Introduction Before a microcontroller can interact with external hardware, its pins must be configured correctly. Whether you want to read a button state, drive an LED, communicate with a sensor, or use a peripheral, the first step is to configure the corresponding pins. 3 Pins Configuration First, identify the pin you want to use. In this example, we will use the following pin: RGBLED0_RED PTA29 GPIO29 Note: When working in S32 Configuration Tools, the pin MSCR value (third line) is not required. However, it will be needed later if you also configure the same pins in EB tresos. Configure the pins according to their intended use: input, output, or input/output. To begin, open the Pins Tool by clicking the Pins button in the upper-right corner. In the Pins Tool, the pins are organized into Functional Groups. In the default projects provided with the Model-Based Design Toolbox, these groups are arranged based on the peripheral to which the pins are routed. For this step, focus on the Pins tab in the upper-left area of the window. Search for the pin you want to configure; in this example, PTA29. If the desired functionality is already routed to a different pin, first disable that routing by clearing the corresponding selection before assigning it to PTA29. Next, update the identifier and label as needed, then enable the routing by selecting the checkbox on the left. This opens the routing selection dialog. Select SIUL2:gpio,29 , as it matches the intended functionality. A second dialog then prompts you to select the pin direction.   In this example, the LED is configured as Input/Output, matching the configuration used by the example project. Depending on the intended use of the pin, a different direction may be required — for example, a push button is typically configured as an input. Additional examples can be found in the default projects provided with the Model-Based Design Toolbox. 4 Configure Port Component The Port component must reflect the same pin configuration defined in the Pins Tool. After returning to the Peripherals Tool, the Port component may be highlighted in red because the pin configuration was modified in the Pins Tool and has not yet been updated in the Port component.   In the default Model-Based Design Toolbox projects, PortPins are grouped into PortContainers according to their associated peripheral, such as Dio_Pins or Can_Pins . Locate the Dio_Pins PortContainer and update the PortPin entries so that they match the values configured in the Pins Tool. The pin will already contain the MSCR value inherited from the Pins configuration. Update the pin name as desired so it can be easily identified in the model, then repeat the process for each additional pin. The PortPin Id uniquely identifies each PortPin entry. The identifier must remain unique across all PortContainers. Note: If a duplicate PortPin Id value is used, the configuration will report an error. Assign a unique PortPin Id value to each configured pin. For example, a configuration containing 40 pins can use identifiers within the range described by the tool configuration. 5 Conclusion Once the pin configuration is complete and the Port component has been updated accordingly, you can continue with the configuration of the software components that will use those pins. 6 References NXP Model-Based Design Toolbox – Community Interacting with Digital Inputs/Outputs on MR-CANHUBK344