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.

  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

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

    1 Table of Contents • Introduction • Required Software • Required Hardware • References • Conclusion     2 Introduction This article belongs to the Front and Rear Lights series and describes the software and hardware environment used throughout the project. Before looking into signal routing, control logic, or integration aspects, it is important to first understand the tools and platforms that support the development and execution of the front and rear lights application. This article introduces the software components used to develop, configure, and deploy the application, together with the hardware platforms used to demonstrate the lighting functionality. This information provides the foundation needed for the remaining articles in the series. Model-Based Design sits at the center of the workflow. MathWorks tools handle the modeling of the front and rear lighting control logic, the definition of the CAN communication interfaces, and validation across simulation stages. NXP tools then deploy those models to the S32K3 target platform, wiring the generated application to real-time peripherals, LED driver hardware, and lighting feedback signals.     3 Required Software 3.1. Vehicle Network Toolbox Within this workflow, Vehicle Network Toolbox plays a central role in defining, simulating, and validating the CAN interfaces of the front and rear lights module. It brings DBC-driven message definitions directly into Simulink, allowing communication behavior to be tested alongside the control logic long before integration. Every command received from the central controller and every status message sent back to the network is modeled using the exact structure defined in the DBC files, keeping the application perfectly aligned with the vehicle-level specification. Vehicle Network Toolbox is available as an add-on in MATLAB/Simulink, adding support for CAN communication and DBC-based message definitions.     Figure 1 - Vehicle Network Toolbox 3.2. Stateflow Stateflow is used to model the control logic of both lighting modules, translating the CAN commands received from the central controller into concrete lighting actions. Each function is represented as a state machine, where transitions are triggered by incoming signals and internal conditions. This approach keeps the logic structured and readable: activation, deactivation, mode switching, and fault handling are all captured in the same diagram. Stateflow is available as an add-on that can be installed directly from within MATLAB/Simulink, extending the environment with state machine modeling capabilities.   Figure 2 - Stateflow 3.3. NXP Model-Based Design Toolbox for S32K3 NXP Model-Based Design Toolbox for S32K3 is the link between the Simulink model and the S32K3 microcontroller. It takes care of generating the code, building it, and running it on the target, turning the lighting model into a real embedded application. Through its peripheral blocks, the model can directly use the resources needed by the front and rear lights modules, such as DIO, CAN, and UART without leaving the Simulink environment. It also connects to the NXP configuration tools and supports FreeMASTER for real-time monitoring, which makes it easy to check how the lighting logic actually behaves on the hardware.   Figure 3 - Development flow diagram     4 Required Hardware 4.1. FRDM Automotive S32K312 Development Board (FRDM-A-S32K312) The front and rear lights application runs on the FRDM Automotive S32K312 Development Board, a development platform based on the NXP S32K312 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 lighting application and exchange messages with the central controller through the CAN network. Its communication interfaces, debugging connectivity, and expansion capabilities make it suitable for evaluating body electronics use cases and lighting control scenarios.   Figure 4 - FRDM Automotive S32K312 Development Board 4.2. CAN analyzer Emulates the central controller when the node is not yet integrated with the full system. It injects the CAN commands defined in the DBC files (turn signals, headlight modes, hazard, brake indication, etc.) and captures the status messages sent back by the module, enabling the CAN interface and control logic to be validated in a controlled and repeatable way. 4.3. Addressable LED Strip The physical lighting output is represented by an addressable LED strip, in which each LED can be controlled individually. This makes it possible to reproduce all the relevant lighting functions on a single strip - turn signals, hazard lights, headlight modes, and brake indication - by assigning different LEDs or groups of LEDs to each function. The result is a clear visual representation of the module's behavior, making it easy to demonstrate how the control logic reacts to incoming CAN commands.     5 References Model-Based Design Toolbox (MBDT) MATLAB® and Simulink® Documentation S32K3 Microcontrollers FRDM Automotive S32K312 Development Board (FRDM-A-S32K312)     6 Conclusion This article described the software and hardware enablement required for the front and rear lights modules. The software environment combines MathWorks modeling and vehicle network capabilities with NXP target support, while the hardware environment brings together the FRDM Automotive S32K312 Development Board, a CAN analyzer, and an addressable LED strip. Together, these elements provide the foundation for modeling, simulation, communication, code generation, deployment, and validation of the lighting application. The next article will focus on the architecture and model description of the front and rear lights modules, including the control logic, CAN interfaces, and overall application structure.