1 Table of Contents • Introduction • Required Software • Required Hardware • References • Conclusion   2 Introduction This article focuses on the software and hardware environment required to build, deploy, and monitor the parking sensor node. On the software side, it presents the MATLAB/Simulink workflow, NXP's Model-Based Design Toolbox (MBDT) for S32K1xx devices, FreeMASTER, and the supporting build environment. On the hardware side, it describes the S32K144-Q100 evaluation board, the MaxBotix MB1020 ultrasonic sensors, the wiring approach, and the communication/debug interfaces used in the setup. The goal is to provide a clear setup foundation before moving into the next article, where the internal model architecture, control flow, and application behavior will be described in more detail.   3 Required Software The parking sensor application is developed using a model-based workflow built around MATLAB, Simulink, Stateflow, and NXP's MBDT for S32K1xx devices. The Simulink model remains the main development artifact, while the supporting toolchain is used to generate code, build the application, download it to the target board, and monitor the running system. 3.1 MATLAB, Simulink and Stateflow MATLAB and Simulink provide the main environment for developing the parking sensor application model. Simulink and Stateflow are used to organize the application structure, configure the processing blocks, and prepare the model for deployment on the S32K144 target.   Figure 1. PSS top-level model in Simulink 3.2 NXP Model-Based Design Toolbox for S32K1xx NXP's Model-Based Design Toolbox (MBDT) for S32K1xx acts as the bridge between the Simulink model and the S32K144 hardware. It provides dedicated blocks for configuring and using the microcontroller peripherals required by the parking sensor node. In this project, MBDT is used for Analog-to-Digital Converter (ADC) acquisition, General-Purpose Input/Output (GPIO) control, Local Interconnect Network (LIN) communication, and FreeMASTER for real-time data visualisation. This allows the model to interact directly with the target hardware without requiring the developer to manually implement low-level peripheral code. The key point for this article is that MBDT keeps the hardware configuration close to the model. The detailed usage of each block and how the blocks are arranged inside the application will be explained in the model architecture article. 3.3 Code Generation and Deployment Flow The application is prepared for embedded deployment through the code generation flow supported by Simulink, Embedded Coder, ARM Cortex-M support, and NXP MBDT. From the developer's perspective, the main workflow remains inside Simulink: the model is configured, generated, built, and deployed to the S32K144 board. NXP's toolchain environment integrated in MBDT provides the compiler and target support used by the build process. In this setup, it does not need to be treated as a separate development step. The generated application can be downloaded to the S32K144-Q100 evaluation board through the MBDT build/deploy workflow using the on-board JTAG debug interface. This keeps the setup straightforward: once MBDT is installed, the application can be built and programmed from the Simulink workflow. 3.4 FreeMASTER FreeMASTER is used as the runtime monitoring tool during development. It provides visibility into the embedded application while it is running on the S32K144 board. In the Parking Sensors System (PSS) setup, FreeMASTER is used to monitor live ADC samples from the ultrasonic sensors, processed distance values, and selected application variables. This helps during bring-up and validation because the developer can check the behavior of the generated application without adding custom debug code. Note: The FreeMASTER channel is separate from the LIN communication used by the parking node to exchange data with the zonal controller. 3.5 Toolchain Versions The following software components are used for this demo setup: Component Version / Variant MATLAB / Simulink / Stateflow R2024a or newer Embedded Coder Matching MATLAB release ARM Cortex-M support Matching MATLAB release NXP MBDT for S32K1xx 4.3.0 FreeMASTER 3.2 or newer These versions define the reference environment used to build and deploy the parking sensor application.   4 Required Hardware The hardware setup is centered on the S32K144-Q100 evaluation board, which acts as the local parking sensor node. Four MaxBotix MB1020 ultrasonic sensors are connected to the board through analog inputs and control lines. The board also connects to the zonal controller over LIN and to the development PC through the FreeMASTER interface.   Figure 2. Parking Sensor Node Hardware Setup 4.1 NXP S32K144-Q100 Evaluation Board The S32K144-Q100 evaluation board is the target hardware used for the parking sensor node. It provides the microcontroller platform required to run the generated application and includes the peripherals needed by the demo: ADC channels for the ultrasonic sensor outputs, GPIO pins for sensor control, LIN support for communication with the zonal controller, and a debug interface for programming and monitoring. In this setup, the board performs the hardware-side interaction with the sensors and communication interfaces.   Figure 3. S32K144-Q100 Evaluation Board Used for the Parking Sensor Node The board configuration used by the project is summarized below. Setting Value Device S32K144 Package 100-LQFP SRAM size 64 KB External crystal 8 MHz System clock 80 MHz Memory model FLASH Debug interface JTAG The exact configuration is provided by the MBDT configuration block in the Simulink model. 4.2 MaxBotix MB1020 Ultrasonic Sensors The demo uses four MaxBotix MB1020 sensors, also known as LV-MaxSonar-EZ ultrasonic sensors. Each sensor provides an analog voltage output that varies with the measured distance, which makes the device easy to connect to the S32K144 ADC inputs. The sensor also includes an RX pin that can be used as an enable or control input. 4.3 Sensor Wiring and Pin Mapping Each MB1020 sensor is connected to the S32K144-Q100 board using two main signal types. The analog output pin is connected to one ADC input channel, while the RX pin is connected to a GPIO output and can be used by the application to control the sensor. Power and ground are distributed from the evaluation board through the breadboard. The following pin mapping comes from the PSS model connection annotation. Sensor Analog pin to S32K144 RX enable pin to S32K144 SONAR1 — Left AN → PTB2, ADC0_SE6, J2.11 RX → PTA11, J1.2 SONAR2 — Center Left AN → PTB3, ADC0_SE7, J2.9 RX → PTA17, J1.4 SONAR3 — Right AN → PTA0, ADC0_SE9, J5.7 RX → PTD10, J1.6 SONAR4 — Center Right AN → PTA1, ADC0_SE15, J5.5 RX → PTD11, J1.8 Power and ground connections are defined as follows. Signal Connection GND Breadboard black rail → J13.4 on S32K144-Q100 VCC 5 V Breadboard red rail → J3.9 on S32K144-Q100   Figure 4. Sensor Wiring Between the S32K144-Q100 Board and MB1020 Sensors 4.4 ADC Configuration The MB1020 sensors provide analog voltage outputs, so the S32K144 ADC is used to convert these signals into digital values. In the project setup, ADC0 is configured for software-triggered acquisition and uses the channels assigned to the four ultrasonic sensors. Setting Value ADC instance ADC0 Resolution 12-bit Trigger source Software trigger Voltage reference 5 V / 0 V Used channels ADC0_SE6, ADC0_SE7, ADC0_SE9, ADC0_SE15 Averaging Enabled, 4 samples This section describes only the peripheral setup. The timing of the acquisitions and the conversion from ADC values to distance measurements will be covered in the next article. 4.5 LIN Interface to the Zonal Controller The parking node communicates with the zonal controller using LIN. In this setup, the parking node is configured as a LIN slave, while the zonal controller acts as the LIN master. Setting Value Peripheral LPUART2 in LIN mode Node function Slave Baud rate 19200 bit/s Checksum Enhanced LIN 2.x LIN TX pin PTD7 LIN RX pin PTD6 The physical connection between the parking node and the zonal controller uses LIN and ground lines. Signal Zonal board pin Parking S32K144-Q100 pin LIN J31.8 J11.1 GND J31.2 J11.4 4.6 FreeMASTER Debug Channel FreeMASTER uses a dedicated serial channel that allows the developer to monitor the application on the PC while the parking node continues to communicate with the zonal controller. Setting Value Interface LPUART1 Baud rate 115200 bit/s RX pin PTC6 TX pin PTC7 Usage Runtime monitoring and variable visualization   5 References Developing a Parking Sensor System with Model-Based Design Toolbox 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 NXP S32K144 Reference Manual and S32K144-Q100 evaluation board user guide MaxBotix MB1020 / LV-MaxSonar-EZ1 datasheet MathWorks documentation: MATLAB, Simulink, Stateflow, Embedded Coder, ARM Cortex-M support FreeMASTER Run-Time Debugging Tool   6 Conclusion This article described the software and hardware environment required to build and run the Parking Sensor System. The software side is based on MATLAB, Simulink, Stateflow, NXP MBDT, code generation support, and FreeMASTER. The hardware side uses the S32K144-Q100 evaluation board, four MaxBotix MB1020 ultrasonic sensors, ADC input channels, GPIO control lines, LIN communication, and a dedicated FreeMASTER serial channel. With this environment in place, the PSS model can be built, downloaded to the S32K144 board, monitored in real time, and connected to the zonal demo setup. The next article will move inside the model and explain the application architecture, including the sensor acquisition flow, model structure, distance conversion, and LIN communication behavior.

  1 Table of Contents • Introduction • Overview • Context • References • Conclusion     2 Introduction Modern vehicle development increasingly relies on digital validation before physical prototypes are available. Simulation enables rapid testing and iteration, but engineering teams also need to demonstrate how virtual behavior maps to real hardware. In the Hello World demonstrator, this connection is handled by the Main Node application running on the NXP S32N55. The Main Node acts as the central execution point of the demonstrator, transforming vehicle information generated inside MATLAB ® and Simulink ® into decisions and actions that can be observed on physical hardware. By combining Model-Based Design, CAN communication, and centralized decision making, the system creates a bidirectional link between the virtual vehicle and the physical demonstrator. This article explains how the Main Node converts simulation inputs into coordinated vehicle behavior while maintaining synchronization between the digital and physical domains.     3 Overview As introduced in the previous article, the S32N55 functions as the communication hub of the demonstrator, aggregating information from distributed modules and distributing commands throughout the system. Beyond communication, however, the Main Node also serves as the decision-making layer responsible for interpreting vehicle state and translating it into actionable control signals. Developed using the NXP Model-Based Design Toolbox (MBDT), the application is entirely modeled in Simulink and deployed directly onto the target hardware. This workflow enables engineers to focus on vehicle functionality and system behavior while leveraging automated code generation and integrated CAN communication support. The Main Node receives data from simulated and physical sources, maintains a coherent vehicle-state view, runs vehicle-level control logic, and sends commands to the actuator nodes that make up the demonstrator. This centralized architecture reflects the direction of modern software-defined vehicle platforms, where coordination moves from isolated ECUs toward higher-level compute nodes. Figure 1. Main Node overview showing how the S32N55 coordinates simulation inputs, vehicle-state processing, and commands to distributed hardware modules.     4 Context The Main Node is positioned between the virtual vehicle environment and the physical hardware modules that form the demonstrator. Driver inputs generated through the Driver-in-the-Loop simulation environment are transmitted over CAN and received by the S32N55, where they are processed alongside feedback arriving from multiple distributed nodes. Commands such as vehicle speed, steering angle, gear selection, braking requests, and lighting controls enter the Main Node from the simulation environment. These inputs are then evaluated by the application and translated into CAN messages that drive the corresponding hardware modules. This architecture enables the physical demonstrator to mirror the behavior of the virtual vehicle. When the simulated vehicle accelerates, the speed command is interpreted by the Main Node and forwarded to the motor control subsystem. Steering-wheel movements are translated into steering-angle commands for the steering module, while lighting commands activate headlights, fog lights, hazard lights, and turn indicators on the physical hardware. Figure 2. System context illustrating the Main Node as the bridge between the virtual vehicle environment and the physical demonstrator hardware. The Main Node can be driven either by the Driver-in-the-Loop simulation or by the External Control model. In both cases, the command source publishes the same DBC-defined CAN frames, so the S32N55 receives speed, steering, brake, gear, and lighting commands through the same interface. This allows the same deployed application to be exercised from two sources without changing the Main Node software. This approach is especially useful during integration, demonstrations, and incremental validation. Engineers can exercise the Main Node and the downstream actuator modules even when the complete virtual environment is not active, while still preserving the exact communication contract used by the full system. As a result, the application can be validated against two different input sources without changing the deployed software on the board. Rather than acting as a simple gateway, the Main Node continuously evaluates received information and executes vehicle-level decisions. One example is the processing of motor feedback data, where information from multiple motors is combined to derive a representative vehicle speed used throughout the system. Centralizing this functionality simplifies system coordination while ensuring consistency across all connected modules. Gear selection is handled as part of this centralized decision layer. The incoming gear command is interpreted as a driving mode that affects how the requested speed is applied: Park and Neutral block motion commands, Reverse changes the sign of the velocity reference, and Drive or Sport propagate the requested speed as a forward-driving command. This keeps speed-control behavior aligned with the selected driving mode while preserving the same driver-input signal set. The target-speed command is computed from the requested speed reference, the selected gear mode, the reported vehicle speed, and the effective brake command. Motor feedback is fused into a representative reported speed, which provides the actual-speed reference used during braking decisions. Under normal driving conditions, the requested target speed passes through the gearbox-aware logic and is converted into the motor-speed command sent over CAN. When braking is active, the Main Node bases the outgoing command on the detected speed and brake value, reducing the command until the vehicle is considered stopped. The Main Node also hosts the demonstrator's automated emergency braking functionality. Parking sensor nodes continuously report obstacle distances over CAN. The application evaluates these measurements and determines whether an object has entered a predefined safety zone. When this condition is met, the braking command issued by the driver can be overridden and replaced with an emergency braking request generated by the system. Figure 3. Parking sensors in action detecting nearby obstacles and providing distance feedback used by the Main Node to support emergency braking decisions. An important aspect of this implementation is that the braking behavior is reflected across both domains. The physical hardware responds to the braking request, while the simulation environment can receive corresponding vehicle-state updates through the same CAN-based loop. This closed-loop behavior demonstrates bidirectional interaction between simulation and embedded execution, allowing safety-related functionality to be validated in a realistic environment before a full vehicle prototype is available. Figure 4. Closed-loop emergency braking flow showing how parking sensor feedback can trigger an automated braking request across both the physical and simulated domains. CAN communication is the key enabler of this architecture. Every subsystem communicates through DBC-defined interfaces, allowing functionality to be distributed across multiple independent nodes while preserving a consistent and scalable communication framework. The shared DBC approach ensures that signal definitions remain synchronized across all parts of the demonstrator. To support this workflow, MathWorks Vehicle Network Toolbox ™ provides direct integration between MATLAB ® , Simulink ® , and CAN communication interfaces. DBC files can be used directly throughout the development process, simplifying signal management and ensuring consistency across the virtual vehicle, the Main Node, and all peripheral modules. As the demonstrator grows to include additional functionality, the same network definition can be reused across all participating systems, reducing integration effort and helping accelerate development. Note: The combination of NXP Model-Based Design Toolbox and MathWorks Vehicle Network Toolbox creates a workflow in which vehicle behavior, communication interfaces, and deployed software remain aligned from modeling through system integration. Figure 5. CAN and DBC workflow showing how shared signal definitions keep the virtual vehicle, Main Node, and distributed hardware modules synchronized.     5 References NXP Model-Based Design Toolbox (MBDT) NXP S32N Vehicle Super-Integration Processors Vehicle Network Toolbox ™ NXP Model-Based Design Toolbox Community     6 Conclusion The Main Node demonstrates how a centralized compute platform can act as more than a communication gateway. Running on the NXP S32N55, it combines signal aggregation, decision making, and command distribution into a single application that coordinates the entire demonstrator. By transforming simulation-generated inputs into physical vehicle behavior and feeding real-world information back into the virtual environment, the Main Node creates a practical closed-loop development platform. Together, NXP Model-Based Design Toolbox, MathWorks Vehicle Network Toolbox, and CAN-based communication enable rapid iteration, simplified integration, and efficient validation of vehicle functionality across simulated and physical domains.

  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 • Component Configuration  • Conclusion • References 2 Introduction Before configuring the DIO component, make sure that the pins you intend to use have already been configured in both the Pins Tool and the Port component. If not, refer to the previous articles on pins and port configuration. 3 Component Configuration In order to configure the Dio peripheral, press on the Dio component on the left side of the screen for the Dio Configuration tab to be opened. There, press on the Dio Config tab. Understanding how the DioPort and DioChannel are organized might prove useful later. The number present under the DioPort label represents the corresponding value of the Dio port that you want to access. Below you can find a table with the correspondence between the values and the registers. Register half DioPort value AL 0 AH 1 BL 2 BH 3 CL 4 CH 5 DL 6 DH 7 EL 8 EH 9 Each of those is half of a register and together every line forms a 32-bit register. For example, AL and AH contain all the pin values that are assigned to PTA. AL contains the first 16 pins and AH contains the next 16 pins. For example, the RGBLED0_RED pin is assigned to PTA29. From that we can conclude that, since 29 is higher than 15 (the 16th value of AL, since the first value is 0), the PTA29 pin must be assigned to the AH register. To reiterate, the PTA0–PTA15 pins belong to the AL register while the PTA16–PTA31 (the value must be offset by -16 when computing the Id) pins belong to the AH register, and this is true for the rest of the registers too: PTB, PTC, PTD, PTE. Note: When computing the channel Id for pins in the upper half of a port (e.g. PTA16–PTA31), subtract 16 from the pin number. To create a new channel, select the appropriate DioPort and click the + button next to DioChannel. A new channel entry will be created. Fill in the required channel information according to the pin that was previously configured in the Pins Tool and Port component.   Repeat this process for each newly configured pin, ensuring that the channel is added under the correct DioPort. 4 Conclusion After configuring the required DioChannels, save the configuration and regenerate the code. The configured DIO channels can then be used by the application to access the corresponding digital inputs and outputs. 5 References NXP Model-Based Design Toolbox – Community Interacting with Digital Inputs/Outputs on MR-CANHUBK344

  1 Table of Contents • Introduction • Required Software • Required Hardware • Communication and Board-Specific Setup • References • Conclusion   2 Introduction The Main Node is the central application target used throughout this project. It sits between the simulation environment running on the host PC and the physical hardware that represents the various vehicle domains. While the previous article introduced the purpose of the Main Node and its role within the overall system, this article focuses on the environment that makes that functionality possible. Developing and validating the Main Node requires more than a target board. The application is modeled, tested, configured, deployed, and monitored using a collection of software tools that work together with the hardware platform. Understanding this environment is important for anyone interested in reproducing the setup or following the remaining articles in the series. This article describes the software components used during development, the hardware platform used to run the application, and the communication infrastructure that connects the Main Node to the rest of the system.   Figure 1. Position of the Main Node within the system architecture.   3 Required Software The Main Node software environment combines MathWorks modeling tools with NXP target support and development utilities. Together, these tools provide the workflow used to model the application, generate code, configure the hardware platform, deploy the software, and observe its behavior during validation and runtime analysis. 3.1 Modeling and Application Development The Main Node application is developed as a Simulink model. MATLAB and Simulink are used to describe the behavior of the application before any software is deployed to hardware. Communication interfaces, application states, signal handling, and system-level functionality are assembled and validated within the modeling environment, allowing development to begin long before the target board is involved. The software environment used for this project includes: MATLAB R2024a or newer Simulink Simulink Coder Embedded Coder MATLAB Coder Stateflow These tools provide the code-generation workflow that transforms the model into embedded software capable of running on the target hardware. 3.2 Network Definition and Validation Communication is one of the primary responsibilities of the Main Node. It exchanges information with the simulation environment, the zonal gateways, and the remaining vehicle-domain nodes through a shared CAN network. Vehicle Network Toolbox is used to bring those communication interfaces directly into MATLAB and Simulink. By using the same DBC definitions during development and validation, communication behavior can be verified before deployment and remain consistent across the complete system. The shared DBC maintained with CANdb++ acts as a common communication contract between all participating nodes. Required tools: Vehicle Network Toolbox CANdb++ 3.1 or newer 3.3 Target Support and Code Generation The bridge between the Simulink model and the target hardware platform is provided by the required NXP Model-Based Design Toolbox package. The toolbox provides: Main target platform support Peripheral integration blocks Build integration Deployment support FreeMASTER integration Using these components, the generated software can be executed directly on the target hardware without requiring manual integration of low-level peripheral code. 3.4 Build and Configuration Environment After code generation, the application is built and deployed using the NXP software toolchain integrated inside Model-Based Design Toolbox package. These tools are used to compile, link, and deploy the generated software to the target board. In parallel, EB tresos is used to maintain the low-level configuration required by the Main Node environment. CAN communication, UART telemetry, I2C initialization, interrupt configuration, and board-level peripheral settings are all managed through this configuration flow. Together, these tools ensure that the generated software and the target configuration remain aligned throughout development. 3.5 Runtime Monitoring and Validation Once deployed, the Main Node can be observed through two complementary mechanisms. FreeMASTER Lite provides runtime visibility into application variables and internal states, while CAN analysis tools are used to inspect the communication exchanged across the network. These tools are used throughout development and validation activities to verify both application behavior and network communication.   Figure 2. Development workflow used by the Main Node application.   4 Required Hardware Unlike the peripheral nodes, the Main Node is responsible for connecting the simulation environment with the physical hardware network. As a result, the hardware environment includes both the target board and the supporting infrastructure used during development, validation, and system-level execution. 4.1 S32N55 Board The Main Node application executes on an S32N55 board selected for the central application role. Within this setup, the board serves as the central application platform and hosts the software responsible for coordinating communication between the simulation environment and the zonal gateways. The board provides: CAN FD communication interfaces UART communication interfaces Debug and deployment connectivity I2C peripherals Processing resources required by the Main Node application The Main Node target board is the primary hardware platform referenced throughout this article series. 4.2 Host PC The host PC provides the environment used to interact with the full setup. Depending on the activity being performed, it may host: MATLAB and Simulink RoadRunner simulation environments FreeMASTER Lite CAN analysis software The host PC communicates with the Main Node both through the CAN network and through the dedicated telemetry interface used by FreeMASTER. 4.3 CAN Analyzer A CAN analyzer is used during development and validation to monitor network traffic exchanged between the Main Node and the zonal gateways. Beyond debugging, the analyzer also provides a convenient method of validating DBC definitions, message timing, and network integration behavior before the full setup is assembled.   5 Communication and Board-Specific Setup Several aspects of the Main Node environment are specific to the selected target board and are worth understanding before reproducing the setup. 5.1 Communication Topology The Main Node does not communicate directly with every vehicle-domain node. Instead, it exchanges information with the two zonal gateways, which distribute the relevant signals toward the corresponding vehicle-domain nodes. This arrangement keeps the system organized around a zonal architecture while allowing each subsystem to be developed and validated independently. 5.2 CAN Transceiver Initialization One hardware-specific detail of the target board concerns the external CAN transceiver. Note: Before CAN communication becomes available, the transceiver must first be switched from standby mode into normal operation. This transition is not controlled directly through a dedicated GPIO. Instead, it is performed through an I2C-connected port expander located on the board. As a result, the startup sequence requires an I2C initialization step before the FlexCAN controller can begin communication.   Figure 3. CAN transceiver enable sequence on the target board. 5.3 FreeMASTER Telemetry Interface In addition to the CAN network, the Main Node exposes runtime telemetry through a dedicated UART connection used by FreeMASTER Lite. This interface is used throughout validation and runtime analysis to visualize application variables and monitor system behavior in real time.   6 References Model-Based Design Toolbox (MBDT) Community NXP S32N Vehicle Super-Integration Processors MathWorks Vehicle Network Toolbox NXP FreeMASTER Run-Time Debugging Tool   7 Conclusion This article introduced the environment used to develop, deploy, and validate the Main Node application. It described the software workflow, the hardware platform, and the communication infrastructure that connect the Main Node to both the simulation environment and the physical hardware network. Particular attention was given to the Main Node's position within the system topology, the UART-based telemetry interface used by FreeMASTER, and the I2C-controlled CAN transceiver initialization required by the target board. The next article moves beyond the enablement layer and focuses on the Main Node application itself, describing the information it receives, the processing it performs, and the outputs it publishes back into the system network.

      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 Figure 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 • Black-Box Overview • Simulink Model Overview • Inputs • Algorithm • Outputs • References • Conclusion     2 Introduction This article explains the internal behavior of the Zone Node by opening the component "black box" and describing how information flows through the application. The objective is to provide a functional understanding of the model, starting from the incoming inputs, continuing through the internal processing logic, and concluding with the generated outputs. The Zone Node acts as an intermediary between the Central Controller and the Edge Nodes located within a vehicle zone. While previous articles introduced the component and the development environment, this article focuses on the application's behavior and the responsibilities performed by the embedded software. This article focuses on the functional behavior of the Zone Node and explains how information flows through the component. Detailed aspects such as CAN routing implementation, LIN scheduling mechanisms, peripheral configuration, and communication stack integration will be covered in dedicated articles later in the series.     3 Black-Box Overview From a system perspective, the Zone Node behaves as a communication gateway and data aggregation component. It receives information from different communication networks, processes that information according to predefined routing rules, and forwards the resulting data to other parts of the system. At a high level, the component can be represented as: Figure 1. Black-Box Overview The Zone Node does not implement vehicle-level control strategies. Functions such as braking decisions, steering calculations, or vehicle state management remain the responsibility of higher-level controllers. Instead, the Zone Node focuses on: Receiving messages from the Central Controller Receiving messages from Edge Nodes Acquiring data from local LIN-connected devices Routing information between networks Aggregating and forwarding data Providing monitoring and diagnostic information The result is a reusable communication component that can be deployed in different vehicle zones while maintaining the same overall behavior.     4 Simulink Model Overview The Zone Node functionality is implemented as a Simulink model organized around communication, routing, scheduling, and diagnostic subsystems. From a model perspective, the application can be divided into four logical areas: Input handling Routing and processing Communication scheduling Outputs and diagnostics Figure 2. Main Simulink Application The input layer receives information from CAN and LIN communication interfaces and makes it available to the application logic. The processing layer evaluates incoming messages and determines how they should be handled. The scheduling layer manages periodic communication activities, while the output layer is responsible for forwarding messages and generating diagnostic information. This separation helps keep the model modular and makes it easier to extend the application with additional communication paths or Edge nodes without changing the core routing behavior.     5 Inputs The Zone Node receives information from three main categories of inputs. 5.1 CAN Network Inputs CAN communication represents the primary source of information processed by the Zone Node. Messages can originate from: Central Controller Lighting modules Steering modules Motor control modules Other Edge Nodes within the zone Typical examples include: Vehicle commands Status reports Diagnostic information Fault indications Actuation requests The exact set of messages depends on the specific Edge Nodes connected to the zone. 5.2 LIN Device Inputs The Zone Node also acquires information from LIN-connected devices. In the reference implementation, LIN communication is used to retrieve parking sensor information. The Zone Node periodically requests data from the LIN device and receives measurement values in response. Examples include: Front parking distances Rear parking distances Other LIN-based sensor information From the perspective of the Zone Node, LIN data behaves similarly to any other external input source. 5.3 Configuration Inputs Before normal operation begins, the Zone Node initializes its communication interfaces and loads the required configuration information. Examples include: CAN interface configuration LIN interface configuration Communication schedules Routing rules These parameters define how the application interacts with the surrounding networks.     6 Algorithm Internally, the Zone Node performs three main processing activities. 6.1 Message Reception The first step consists of collecting incoming communication data. Whenever a message arrives, the application captures: Communication source Message identifier Data payload Message length This information becomes available to the routing and aggregation logic. Figure 3. CAN Reception Pipeline 6.1.1 Model Representation of Message Reception Within the Simulink model, message reception is implemented using communication interface blocks and dedicated processing subsystems that capture incoming network events and make the received information available to the rest of the application. Figure 4. CAN Reception Main Flow Figure 5. CAN Reception Subsystem At a high level, the reception subsystem performs three actions: Detects incoming communication events Stores the received information Makes the information available to the routing logic This allows the routing algorithm to operate independently from the physical communication interface. 6.2 Message Routing Message routing represents the primary responsibility of the Zone Node. The routing logic determines the origin of each incoming message and forwards it to the appropriate communication interface. The behavior can be simplified as: Figure 6. Bidirectional CAN Routing Messages received from the Central Controller are forwarded toward the Edge Nodes, while messages originating from Edge Nodes are routed back toward the Central Controller. The routing mechanism remains independent of the actual application payload, allowing the same software architecture to support different message sets and vehicle functions. 6.2.1 Model Representation of Routing Logic The routing functionality is implemented as a dedicated subsystem responsible for deciding where each received message should be forwarded. Figure 7. Message Routing Main Flow Figure 8. Message Routing Subsystem The routing subsystem evaluates the origin of the received message and selects the appropriate destination interface. At this level, the application does not interpret individual signal meanings; it simply ensures that information reaches the correct communication network. This approach keeps the routing layer independent from application-specific functionality and allows the same architecture to be reused across different deployments. 6.3 LIN Scheduling and Data Acquisition In parallel with CAN routing, the Zone Node periodically acquires data from LIN-connected devices. The sequence follows a simple request-response model: Figure 9. LIN Parking Acquisition Cycle This mechanism allows information originating on a LIN network to become available to the rest of the vehicle through CAN communication. 6.3.1 Model Representation of LIN Scheduling Periodic LIN communication is implemented using a dedicated scheduling subsystem. Figure 10. LIN Scheduling Main Flow The scheduler periodically requests data from LIN-connected devices, waits for a response, and updates the application data used by the rest of the system. Depending on the communication requirements, the scheduler may manage one or more request-response sequences while maintaining a deterministic execution pattern. 6.4 High-Level Data Flow The internal data flow implemented by the Zone Node can be summarized as follows: Figure 11. Zone Node Data Flow     7 Outputs The Zone Node produces several categories of outputs that are consumed by different parts of the vehicle architecture and by development tools used during validation and debugging. 7.1 Routed CAN Messages The primary outputs of the Zone Node are CAN messages forwarded between communication networks. Examples include: Commands sent from the Central Controller to Edge Nodes Status information returned from Edge Nodes Diagnostic messages Fault reports Configuration updates By routing these messages between communication domains, the Zone Node maintains communication between the central controller and the devices located within its assigned vehicle zone. 7.2 Aggregated Device Data In addition to forwarding CAN traffic, the Zone Node generates CAN messages containing information acquired from locally connected devices. One example is parking sensor data collected through a LIN interface and republished on CAN. This allows the Central Controller to access the information without requiring direct interaction with the LIN-connected device. The process can be summarized as: Figure 12. LIN-to-CAN Data Path This approach creates a unified communication interface while hiding the complexity of the underlying network topology. 7.3 Diagnostic Outputs The Zone Node generates diagnostic information that is useful during development, system integration, and troubleshooting activities. Examples include: Communication counters Status variables Network activity indicators Communication statistics Device data used for monitoring purposes These outputs provide insight into the current behavior of the application and can be accessed through development tools such as FreeMASTER. 7.4 Visual Indicators In addition to communication outputs, the Zone Node drives visual indicators available on the evaluation hardware. The on-board LEDs provide immediate feedback regarding: Message reception activity Message transmission activity LIN communication activity Application execution status Although these indicators are not used by the vehicle itself, they simplify application bring-up and validation by providing a quick visual confirmation that the software is operating correctly. 7.5 Output Destinations The outputs generated by the Zone Node are consumed by several different system components. Central Controller Receives: Status information from Edge Nodes Aggregated sensor data Diagnostic information generated within the zone Edge Nodes Receive: Commands originating from the Central Controller Configuration and control messages forwarded through the Zone Node Local Devices Receive: Periodic requests issued by the Zone Node Communication messages required to acquire local measurements Development Tools Receive: Monitoring variables Communication statistics Diagnostic information used for debugging and validation 7.6 High-Level Output Flow Figure 13. System Topology This output structure allows the Zone Node to act as a communication intermediary while simultaneously providing visibility into the behavior of the system during development and validation.     8 References NXP Model-Based Design Toolbox (MBDT) S32K3 Microcontroller Documentation S32K344-WB Evaluation Board Documentation     9 Conclusion This article described the internal behavior of the Zone Node by examining its inputs, processing logic, and outputs. By presenting the component as a functional black box, it explained how information is received, routed, aggregated, and distributed throughout the system without focusing on implementation-specific details. The next articles in the series will build upon this foundation by examining individual communication paths in more detail, including CAN-to-CAN routing, LIN-to-CAN routing, and the techniques used to validate and troubleshoot communication behavior.