AI Test Generation for Safety-Critical Vehicle Software

The Challenge

The client is a Tier-1 supplier building control software for commercial vehicles. Its team works to an Automotive SPICE process, operates under ISO 26262 functional safety constraints and must hand over evidence files at assessment. Writing tests for embedded software costs effort that grows with the codebase. For each function an engineer works out the logic branches, picks data that exercises each one, simulates hardware dependencies and wires everything into a test harness. When a schedule slips, that effort is the first thing cut, and defects that survive into hardware integration cost several times more to fix.

What We Built

Nexora engineers built a tool that reads the client’s control software, finds every logic branch in every function and generates a ready test scaffold for each one. The scaffolds follow the exact format of the harness the team already uses. The tool runs on internal machines and sends nothing out, which matters because cloud AI services would require shipping control software source outside the company. It has run against the client’s real source.

• A complete tool delivered with an automated suite of 34 checks, green on a clean install
• Scaffolds in the client’s own harness format
• Deployable with no internet access
• A report listing every function it cannot handle, with the reason

The Audit That Found Five Defects

Everything the tool is worth rests on finding logic branches correctly and completely. Miss one and the coverage number is quietly corrupted. The first agent finished the job and the automated suite came back green. Nexora then gave a second agent a single task: audit the branch-finding logic, with no involvement from the agent that wrote it. It found 5 real defects, all of the kind that makes the tool undercount branches. Fewer branches on the list shrinks the denominator, so reported coverage climbs while the untested code stays where it was. All five were reproduced, fixed and pinned down with regression checks.

Built to Absorb Change

Once the client saw the first output on its own code, it asked for a different output format, a change that reached the root of the generator. The project structure took the change without a rewrite, and the test suite stayed green afterwards. The episode also showed where people stay in the loop. Whether the output fits the team’s workflow is a judgment no agent can make from source code alone, so on several points the agent raised a question and stopped for a decision instead of guessing.

Where the Tool Stops

The tool answers two questions: in how many ways can this function run, and how do you force each one. Both are structural facts read straight from the source, so the answers are certain and repeatable. Where it cannot derive a valid input value, it leaves a marked gap instead of a guess. It builds enough scaffolding to run exactly one branch and then stops, because the correct result lives in the requirements and the physical meaning of the signals, not in the code.

• Certain: which ways a function can run, and how to force exactly one of them
• Simple cases only: physically meaningful input data
• Left to engineers: the expected result, required side effects and requirement traceability

Results

The client has a working, offline test-generation tool with measured verification behind it: 34 passing checks and 5 audit-found defects fixed before the tool shipped. The structural half of test writing no longer costs engineer time. The remaining work is the part that needs reading requirements and context, and the tool is explicit about where that begins.

Why It Matters

AI-written code that goes unchecked is the wrong fit for safety-related software. The useful pattern here is separation of roles: one agent produces, another audits, and a person judges what the tool cannot know. Teams that want AI in an automotive test chain can start from the same split.