From Simulation to Vehicle Control: Real-Time Decision Making on the S32N55
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_vehicle_brain_no_header.pngFigure 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_virtual_physical_synchronization_no_header.pngFigure 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.
Picture1.pngFigure 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_aeb_closed_loop_no_header.pngFigure 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_shared_dbc_workflow_no_header.pngFigure 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.
View full article
