Vehicle Controller Switching Safety Testing using NVIDIA AI

• 

  System Architecture

1. Inspiration

Autonomous vehicle safety is not only about how accurately a vehicle follows a planned trajectory. It is also about what happens when a control system fails—and whether the vehicle can recover safely.

Our interest in vehicle control algorithms led us to investigate Model Predictive Control (MPC) and its interaction with backup control strategies. MPC can predict future system behavior and incorporate operating constraints, but its computational and execution requirements also introduce potential failure conditions.

Consider a vehicle entering a sharp curve when its primary MPC experiences an unexpected delay or abnormal steering output. A supervisor detects the failure and transfers control to a backup Linear Quadratic Regulator (LQR).

The controller switch may succeed technically, yet the vehicle may still fail to recover safely. The outcome depends on the vehicle's speed, road curvature, steering state, detection delay, and the exact timing of the fault.

This raised a central question:

Does successful controller switching actually mean successful vehicle recovery?

Investigating this question requires testing many combinations of driving conditions, fault types, and switching events. However, simulation resources are limited, and predefined or randomly generated tests may overlook important failure boundaries.

At the same time, we became interested in another challenge: Could a general-purpose reasoning model perform specialized engineering tasks without additional model training?

Instead of fine-tuning a large model specifically for autonomous vehicle safety testing, we wanted to investigate whether carefully designed context, structured reasoning roles, deterministic validation, and experimental feedback could make an existing model useful in a specialized engineering workflow.

These two interests led us to this project.

We set out to combine NVIDIA Nemotron with CARLA simulation and Gaussian Process active learning, creating a testing system in which AI proposes experiments, simulation produces physical evidence, and the results guide subsequent testing decisions.

Our objective is not simply to automate fault injection. It is to build an evidence-driven testing loop that helps engineers discover where controller recovery succeeds, where it fails, and which conditions separate the two.

2. What it does

Our project is an AI-assisted Software-in-the-Loop (SIL) framework for investigating the safety of MPC-to-LQR controller switching in autonomous vehicles.

It combines general-purpose reasoning models, physical simulation, probabilistic modeling, and deterministic safety evaluation in a closed-loop testing process.

1. Code-aware safety analysis

The framework organizes controller implementation information, operating constraints, and potential failure mechanisms into structured safety profiles.

Nemotron B performs code-related reasoning using source files with line-numbered evidence. It cites relevant code locations, and the framework validates the referenced line ranges. This model does not receive simulation outcomes, keeping code-based analysis separate from experimental results.

2. AI-guided fault scenario generation

Nemotron A generates structured candidate scenarios involving vehicle speed, road geometry, fault timing, and control failure parameters.

The system uses task-specific context and JSON schema constraints rather than task-specific model fine-tuning.

In the recorded experiments, Nemotron A was requested to generate 452 candidates and returned 373, representing approximately 82.5% of the requested candidates. All 373 returned candidates passed schema validation.

3. Scenario feasibility validation

Before execution, deterministic checks filter invalid scenario configurations and verify parameter constraints.

Candidate expansion and controlled perturbations allow the system to explore nearby conditions without relying exclusively on new LLM-generated scenarios.

4. CARLA-based fault injection

The system uses CARLA 0.9.15 to execute controller-switching experiments.

Faults are injected into the primary MPC, and a supervisor determines when control should transfer to the backup LQR.

The recorded evaluation includes 11 real CARLA campaigns totaling 218 simulation runs.

5. Deterministic safety monitoring

The framework evaluates measurable vehicle behavior, including lateral tracking error, lane-boundary violations, controller-switching events, and recovery conditions.

The recorded outcomes include 56 switched_safe, 66 switched_unsafe, 81 triggered_no_switch, and 5 simulation_invalid classifications.

The supplied categories account for 208 of the 218 runs; the status of the remaining 10 requires reconciliation with the full records.

Safety judgments are made exclusively by the deterministic monitor (engine/monitor.py), not by an LLM.

6. Gaussian Process active learning

A Gaussian Process surrogate implemented with scikit-learn and a Matérn ARD kernel models observed safety-related outcomes and uncertainty.

Level-set acquisition helps select subsequent experiments near uncertain controller-switching and recovery boundaries.

This allows the testing process to prioritize informative scenarios rather than relying only on random exploration.

7. Video reasoning and evidence validation

NVIDIA Cosmos3-Super-Reasoner analyzes simulation video through a Nebius Dedicated Endpoint, with Nemotron-3.5-Super-VL available as a fallback.

Of 83 recorded video explanations, 23 passed validation against simulation logs using event-timing tolerance of ±0.5 seconds and mechanism-tag checks.

Only validated explanations are eligible to contribute to subsequent analysis. Video reasoning cannot change the deterministic safety verdict.

The system therefore follows a continuous experimental workflow:

Analyze → Generate → Validate → Simulate → Evaluate → Learn → Generate Again

Rather than treating each simulation as an isolated test, our framework connects observations from previous runs to the selection of future experiments.

3. How we built it

We developed the system as a modular Python framework connecting NVIDIA AI inference, CARLA-based controller testing, Gaussian Process active learning, and deterministic safety monitoring.

1. CARLA simulation and controller switching

We used CARLA 0.9.15 with an MPC primary controller, LQR backup controller, and supervisory switching logic.

The testing framework supports fault injection and paired baseline-versus-fault evaluation, allowing vehicle behavior under injected faults to be compared with corresponding no-fault conditions.

Our real execution environment uses a local CARLA instance with sequential simulation execution.

Across 11 recorded campaigns, we executed 218 CARLA simulation runs.

2. NVIDIA Nemotron through Nebius Token Factory

We integrated NVIDIA models using the OpenAI-compatible Nebius Token Factory API.

Instead of fine-tuning the models, we designed specialized inference roles, structured context, constrained output formats, and post-generation validation.

• Nemotron A — NVIDIA Nemotron-3.5-Lightning: Structured fault scenario generation using thinking disabled and JSON schema output. The recorded workload includes 37 calls, zero reported API errors, and a median latency of 11.3 seconds.
• Nemotron A refinement: A reasoning-enabled refinement configuration with 25 recorded calls and a median latency of 78.5 seconds.
• Nemotron B — NVIDIA Nemotron-3-Ultra-550B-A55B: Code-aware reasoning with thinking enabled, line-numbered source evidence, and validated citations. The recorded workload includes 813 calls, zero reported errors, a median latency of 14.3 seconds, and a 90th-percentile latency of 34.1 seconds.

3. NVIDIA Cosmos video reasoning

We integrated Cosmos3-Super-Reasoner through a Nebius Dedicated Endpoint and made 105 actual inference requests.

We implemented automatic endpoint startup and shutdown using --cosmos-power auto, along with inference readiness checks and fallback handling.

Nemotron-3.5-Super-VL was invoked 13 times as a fallback.

4. Gaussian Process surrogate and experiment selection

We implemented Gaussian Process modeling with scikit-learn, using a Matérn kernel with automatic relevance determination.

A level-set acquisition strategy selects scenarios near uncertain safety boundaries. The orchestration pipeline combines AI-generated candidates with deterministic feasibility checks and probabilistic scenario selection.

5. Deterministic monitoring and evidence management

We implemented structured simulation evaluation and reporting components.

The deterministic monitor processes simulation results and assigns recovery classifications according to predefined criteria.

The system also maintains experiment records, inference usage information, video explanations, and campaign reports.

6. Testing and evaluation

We conducted 11 real CARLA campaigns comprising 218 runs.

We also implemented X-1 through X-6 ablation configurations and executed comparisons using a synthetic mock simulator.

The synthetic ablation results are treated separately from real CARLA evidence and are not presented as proof of real-world performance improvements.

7. Unified execution workflow

A Python orchestration layer connects AI inference, scenario generation, feasibility validation, simulation, safety monitoring, surrogate updates, and reporting.

Across the recorded workloads, the system made 993 LLM and multimodal model calls, processing approximately 16.69 million input tokens and 4.33 million output tokens.

The implementation uses Nebius Token Factory and Dedicated Endpoints for actual model inference. CARLA simulation runs locally; Nebius parallel simulation, Serverless Jobs, Tool Calling, and Isaac Sim were not used.

4. Challenges we ran into

1. Adapting general-purpose models without fine-tuning

One of our most important challenges was making general-purpose reasoning models useful for highly specialized autonomous vehicle safety testing without training new model weights.

We had to determine which controller details, physical constraints, code evidence, and previous observations should be provided to each model.

This led us to develop role-specific prompts, structured contexts, schema-constrained outputs, and deterministic validation mechanisms.

2. Maintaining reliable structured generation

Nemotron A returned 373 of 452 requested candidate scenarios, an approximately 82.5% return rate.

All returned candidates passed schema validation, but the recorded workload also included 7 parsing failures and 6 output truncations.

This highlighted the importance of distinguishing valid returned outputs from failures in the overall generation process.

We addressed these limitations through structured-output constraints, error handling, and separate refinement strategies.

3. Defining meaningful safety criteria

A controller switch does not automatically mean that the vehicle recovered safely.

We needed to distinguish successful switching from safe post-switch vehicle behavior and evaluate recovery using measurable simulation evidence.

We therefore separated AI-generated hypotheses from deterministic safety judgments.

4. Managing simulation constraints

Not every proposed scenario is suitable for a valid CARLA test.

Route feasibility, fault timing, baseline behavior, controller conditions, and simulation execution constraints can affect whether a result is meaningful.

We introduced feasibility checking, matched baseline comparisons, and explicit invalid-run classification to improve the reliability of the testing process.

5. Operating multimodal inference through dedicated endpoints

The Cosmos3-Super-Reasoner integration introduced practical inference availability challenges.

Among 105 recorded Cosmos requests, 26 returned HTTP 404 while the dedicated endpoint was not yet ready to serve inference.

We implemented automatic endpoint power management, readiness checking, and a Nemotron-3.5-Super-VL fallback to handle these conditions.

6. Validating AI-generated visual explanations

A plausible video explanation is not necessarily supported by simulation evidence.

Among 83 recorded explanations, only 23 passed our log-based timing and tag validation.

This reinforced the need to validate multimodal reasoning against independent measurements before reusing it in an engineering feedback loop.

5. Accomplishments that we're proud of

Our proudest accomplishment is building and executing an AI-assisted controller safety testing system that connects general-purpose reasoning models with real CARLA simulation, without task-specific fine-tuning.

1. Real simulation execution

We completed 11 recorded CARLA campaigns comprising 218 simulation runs.

The provided result summary includes:

• 56 switched_safe outcomes.
• 66 switched_unsafe outcomes.
• 81 triggered_no_switch outcomes.
• 5 simulation_invalid outcomes.

These observations show that our testing framework can record and distinguish different controller-switching and recovery outcomes.

2. Extensive NVIDIA model integration

We recorded 993 LLM and multimodal inference calls across the project.

The workload included Nemotron scenario generation, reasoning-enabled refinement, code analysis, Cosmos video reasoning, and vision-language fallback.

3. Structured fault scenario generation

Nemotron A returned 373 candidate scenarios from 452 requested candidates. All returned candidates passed schema validation.

4. Evidence-grounded technical reasoning

Nemotron B completed 813 recorded calls with zero reported errors, using source-code evidence and validated line references without access to simulation outcomes.

5. Actual Nebius Dedicated Endpoint integration

We made 105 Cosmos requests through a Nebius Dedicated Endpoint and implemented automatic startup, shutdown, readiness handling, and fallback functionality.

6. Deterministic safety evaluation

We established a clear boundary between AI-generated hypotheses and safety verdicts.

Only the deterministic monitoring system assigns safety classifications.

7. An adaptive experiment selection architecture

We integrated Gaussian Process modeling and level-set acquisition into the scenario selection workflow, allowing subsequent tests to be selected using observed outcomes and predictive uncertainty.

We are particularly proud that the project goes beyond a conceptual architecture: it includes actual CARLA runs, extensive NVIDIA inference usage, and recorded evidence from the testing process.

At the same time, our real experiments do not yet establish that this approach outperforms conventional testing baselines.

6. What we learned

One of the most valuable lessons from this project was understanding how to apply a general-purpose reasoning model to a highly specialized engineering problem without task-specific fine-tuning.

We initially approached NVIDIA Nemotron as a general reasoning model, but integrating it into an autonomous vehicle safety testing framework required much more than writing prompts.

We had to carefully consider what knowledge the model needed, how to structure that knowledge, which tasks were appropriate for AI reasoning, and which decisions had to remain deterministic.

This led us to explore prompt engineering, context engineering, structured outputs, role separation, and evidence validation.

We learned that the same general-purpose model cannot simply be given every available piece of information and expected to produce reliable engineering results. The information provided to each model must match its role.

For example, our scenario-generation model can use previous failure observations to inform new proposals, while our code-analysis model works with source-code evidence without accessing simulation outcomes.

This separation helps keep the reasoning process more interpretable and prevents inappropriate information sharing between different stages.

We also learned that structured output correctness is not equivalent to overall task success.

Although all 373 returned scenario candidates passed schema validation, the generation workload also encountered parsing failures, truncated outputs, and requests that did not produce all requested candidates.

Similarly, only 23 of 83 video explanations passed our evidence-validation checks.

These observations taught us that reliable domain-specific AI systems need external constraints, verification, failure handling, and feedback—not just powerful models.

Another important lesson was how AI reasoning can complement probabilistic modeling and physical simulation.

Rather than expecting Nemotron to predict every physical consequence independently, we designed a closed-loop system in which CARLA generates observations, a deterministic monitor evaluates safety conditions, and Gaussian Process active learning informs subsequent experiment selection.

Ultimately, we learned that making general-purpose AI useful in a specialized domain is a system-design challenge as much as a model-selection challenge.

The key is designing the right context, responsibilities, constraints, validation mechanisms, and feedback pathways around the model.

This experience gave us a deeper understanding of how general-purpose AI can support specialized engineering workflows without additional model training, while preserving the distinction between generated reasoning and verified evidence.

3-7. What's next for Vehicle Controller Switching Safety Testing using NVIDIA AI

Our next objective is to expand the framework from demonstrated controller-switching experiments into a more thoroughly evaluated and scalable safety testing system.

1. Quantitative comparison with conventional testing

We plan to compare Nemotron-guided active learning with random sampling, structured exploration, and non-feedback generation under matched real CARLA simulation budgets.

Although we implemented X-1 through X-6 ablation comparisons, these have so far been executed only in the synthetic mock environment.

2. Improved scenario generation reliability

We aim to improve candidate return rates, reduce parsing failures and output truncation, and evaluate prompt and context strategies systematically.

3. More reliable video reasoning

We plan to improve the evidence-validation pass rate of multimodal explanations and investigate methods for more accurate event identification.

4. Scalable simulation execution

Our current CARLA environment uses one local simulation instance. We plan to investigate distributed simulation execution using Nebius infrastructure.

5. Expanded controller and fault coverage

We aim to investigate additional controller implementations, operating conditions, failure mechanisms, and recovery strategies.

6. Continuous software regression testing

We plan to extend the framework to compare controller software versions and identify safety-related regressions following software updates.

7. Generalizable AI-driven engineering workflows

Beyond MPC-to-LQR testing, we want to investigate whether the same architecture—general-purpose reasoning models, structured context, deterministic evaluation, and simulation feedback—can support other specialized engineering validation tasks without fine-tuning.

Our long-term goal is to develop a reusable framework in which general-purpose AI can intelligently organize testing, select informative experiments, and learn from measured outcomes while keeping engineering judgments grounded in verifiable evidence.

Built With

• active-learning
• autonomous-driving
• carla
• computer-vision
• fault-injection
• ffmpeg
• gaussian-process
• gaussian-process-regression
• json
• linear-quadratic-regulator
• model-predictive-control
• nebius-dedicated-endpoints
• nebius-token-factory
• numpy
• nvidia-cosmos
• nvidia-nemotron
• pdm-lite
• pytest
• python
• pyyaml
• requests
• safety
• scikit-learn
• software-in-the-loop
• yaml