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