Autonomous Vehicle Testing Homologation Challenges Unveiled – What I Learned from Experts at Tech.AD 2026
The software for self-driving systems largely exists. The bottleneck is proving it’s safe enough to deploy. With regulators demanding coverage across millions of edge-case scenarios, AI systems producing probabilistic outputs that resist traditional certification, and liability questions nobody has answered yet, autonomous vehicle development has entered a validation crisis. Four companies at the front of this challenge — Synopsys (formerly ANSYS), Cadence/VTD, Critical Software, and MHP — sat down at Tech.AD Berlin 2025 to explain what’s actually going on.
- Brute-force testing of every possible scenario is not an engineering solution — it’s a delay mechanism.
- The four-step simulation journey (data → scenarios → simulation → analysis) is well understood but still painfully slow at each stage.
- Homologation is now the primary risk factor for missing start-of-production (SOP) dates, not software quality itself.
- OEMs are increasingly relying on specialist suppliers for simulation toolchains — because building in-house costs more time than it saves.
- AI is no longer the headline at industry events. It’s embedded in the tools. The open question is whether anyone has an end-to-end solution yet (they don’t).
What does “the problem is not the code” actually mean?
It means the industry has largely solved the engineering problem of writing autonomous driving software. The unsolved problem is validation: how do you prove, to a regulator’s satisfaction, that the software behaves correctly across every scenario it will encounter in the real world?
Pierre Vincent, Director of Application Engineering at Synopsys, frames the pressure clearly: engineers are dealing with systems that are more complex, developed under extreme time pressure, in highly competitive markets, and requiring multi-discipline collaboration within large organisations — simultaneously. Each of those variables compounds the others.
Emmanuel Follin, Senior Product Manager at Synopsys for AVxcelerate, points to physical AI as the specific technical challenge. Autonomous systems perceive and act on the physical world. To validate them, you need to simulate that world accurately — sensor by sensor, physics by physics. “You need to be capable of emulating the world around these AI systems,” Follin explains. “Giving the system accurate, trustable sensor simulations — that’s where the whole validation chain starts.”
Without accurate simulation inputs, every test result downstream is suspect. That’s the foundational problem.
How does scenario-based testing work at scale — and why is it still so slow?
Gordon Köfner, Product Manager for VTD and VTDx at Cadence, lays out the four-step process that every ADAS engineer navigates. Understanding where time is lost at each stage explains why teams routinely miss SOP targets.
Step 1: Simulation data
Before any testing happens, you need road networks — stretches of road, geo-referenced or synthetic, that match the scenarios you’re trying to cover. Building these manually takes weeks. Cadence’s VTD offers a tile library for synthetic road networks and geo-referenced generation with partners for measured data, but the choice of approach still requires engineering time upfront.
Step 2: Scenario variation
Once you have road networks, you build test scenarios. The scope of what needs to be covered has expanded significantly with regulations like UN ECE DCAS and Euro NCAP 2026. Köfner notes that newer regulatory language is deliberately open-ended — instead of specifying concrete scenarios, it describes categories that could generate thousands of parameter combinations. “Nobody’s going to start creating these by hand,” he says. Generative AI is being applied here, with the goal of reducing requirements engineering from three weeks to minutes. That goal is not yet achieved.
Step 3: Simulation
The actual simulation stage involves software-in-the-loop (SIL), hardware-in-the-loop (HIL), and driver-in-the-loop (DIL) testing. Each method has different speed, cost, and fidelity trade-offs. SIL enables massive-scale continuous testing. HIL catches integration issues. DIL is expensive and comes late. The sequence is well understood; the challenge is running it fast enough to keep pace with development commits.
Step 4: Data analysis and feedback
The most underrated step. Finding false positives, false negatives, and inconsistencies in results — then feeding those findings back into the development cycle — is what prevents regressions. The earlier you catch an issue in this loop, the cheaper the fix. As Köfner puts it: “The closer those tests are to what you would see in the real world, you can ideally shift left the entire homologation and validation process.”
Why is homologation the biggest risk factor for missing production timelines?
Homologation — the process by which regulators certify that a vehicle system is safe for public roads — has always been a hurdle. It’s now the primary one.
Khaled Alomari, Manager at MHP (a Porsche company), explains the structural shift: “It’s not anymore a question of what to develop. It’s a question of whether what we develop is going to be certified — is it safe enough to be used on public roads?” The engineering problem has migrated upstream into a regulatory problem.
The compounding factor, as José Rui Simões of Critical Software identifies, is AI. Traditional certification frameworks were built around predictable, deterministic systems. AI-based functions are probabilistic. For very similar inputs, you can get very different outputs. “That’s a problem the industry is still trying to solve,” Simões says. Regulators know it too, but the frameworks for certifying AI-based systems at scale don’t exist yet in final form.
Liability makes this more acute. If a fully autonomous vehicle has an accident, who is responsible — the OEM, the software provider, the sensor supplier? Alomari is direct about the current state: “There is no clear answer for that question.” MHP’s role is to advise OEMs on getting their systems as safe as possible given that open question — not to resolve it.
The accumulation of mandated safety features also contributes. As Simões catalogues: emergency braking, lane keeping, speed assistance, cabin monitoring — each layer added by regulators adds test coverage requirements, adds software complexity, and adds cost that eventually reaches the consumer. “We are on the ramping part,” he says. These features will become commodities eventually. Right now, they’re a bottleneck.
Should OEMs build their own simulation tools or rely on suppliers?
Most OEMs tried to build their own. Most have concluded that this was a mistake.
Köfner traces the history: VTD has existed for years, and in its early days, OEMs were largely building their own simulation tooling alongside it. Over time, a pattern emerged. Common requirements across OEMs create natural market conditions for shared tooling. Building a dependable simulation tool in-house is a significant engineering effort — and simulation software is not an OEM’s core competency. “They’re already struggling to deliver software on time,” Köfner notes. “Why would they do that?”
The business logic is straightforward. When requirements are shared across OEMs — passing UN ECE regulations, achieving Euro NCAP ratings, verifying DMS and AEB functions — a supplier that serves all of them can invest proportionally more in the toolchain than any single customer could justify building alone. The OEM gets a more capable tool faster and can apply its engineering capacity to differentiated vehicle software instead.
This doesn’t mean the toolchain relationship is passive. Cadence’s VTD is typically deployed at the customer’s site, integrated into an existing workflow alongside partners like TraceTronic ECU-Test or ADL Senius. Customisations happen — specific highway segments, custom sensor configurations, proprietary data pipelines. The relationship is part toolbox, part partnership.
Critical Software’s Simões makes a complementary point from the services side. His team brings in specialist expertise — unit testing, safety validation, systems integration — not to write the OEM’s software for them, but to handle the parts that require narrow technical depth that would be expensive to maintain in-house year-round.
Is AI actually changing automotive development, or is it just everywhere now?
Both, depending on which layer you’re looking at.
Alomari made an observation at Tech.AD that cuts through the noise: he was surprised by how few AI logos he saw on exhibitor booths, not how many. AI has stopped being the headline claim. It’s now embedded in the tools — requirements generation, scenario creation, data analysis, fault detection — as an expected capability rather than a differentiator.
“AI is now part of the tools used to develop the vehicle from setting the requirements to developing the function,” Alomari says. “It is now everywhere.” The open question is integration: “Who is willing to provide an end-to-end solution for the whole vehicle development lifecycle?” His answer: no one has that yet. Every tool supplier is using AI in some form, but the lifecycle remains fragmented.
Simões adds a cautionary note from the safety side. AI in production systems creates a certification problem: AI components in deterministic safety architectures can make those architectures non-deterministic. The industry is still figuring out how to bound that risk formally.
On the development side, the picture is more positive. Cadence’s Köfner points to generative AI-driven scenario creation as the most immediately useful application — taking requirements and generating test cases automatically, compressing weeks of work. The technology works in limited domains today. The goal is to generalise it.
How is the automotive supply chain changing as a result of all this?
The Tier 1-centric model — where a Tier 1 supplier delivered a complete subsystem and the OEM integrated it — is being replaced by something that looks more like the smartphone supply chain.
Simões describes the new structure: a small number of hardware providers (Qualcomm and NVIDIA dominate ADAS silicon), a software stack from multiple specialised vendors at the OS, middleware, and perception layers, and an integration layer where companies like Critical Software have historically lived. OEMs are becoming more directly involved at every layer, including hardware specification. Simões cites conversations he’s had with people from chip companies where OEMs are now actively influencing silicon design for their vehicles.
This is what Stéphane Lagresle calls the “sawdust concept” during the MHP conversation: companies investing heavily in building internal autonomous driving capabilities generate expertise that other OEMs will pay to access. The capability built for internal use becomes a commercial product. Several OEMs are now exploring selling their software stacks to competitors rather than treating them as proprietary.
Alomari confirms this at MHP: “OEMs are moving in the direction of building their own or selling their own solutions to other OEMs — not only using them for their own vehicles. That might generate more business for them than selling vehicles in the market.”
It’s a structural shift in how the automotive industry creates and captures value. The vehicle is increasingly a platform for software revenue, not just a product sold once.
Key quote from the episode
“It’s not anymore a question of what to develop. It’s a question of whether what we develop is going to be certified — is it safe enough to be used on public roads?”
— Khaled Alomari, Manager, MHP (A Porsche Company), at Tech.AD Berlin 2025
Frequently asked questions
What is physical AI in the context of autonomous vehicles?
Physical AI refers to AI systems that perceive and act on the physical, three-dimensional world — as opposed to AI that processes text or structured data. In autonomous driving, validating physical AI requires simulating real-world sensor inputs (radar, lidar, cameras) with sufficient physical accuracy that the AI behaves as it would in reality. Synopsys (formerly ANSYS) is one of the few companies with depth in both sensor simulation and physics simulation at this level.
What is “shift left” in autonomous vehicle testing?
Shift left means moving validation activities earlier in the development cycle — from the test track and physical prototype stage back to software-in-the-loop simulation running on development machines. The earlier you find a defect, the cheaper it is to fix. Simulation-based shift-left strategies aim to give engineers confidence in their code changes with every commit, not just at milestone reviews.
What is UN ECE DCAS and why does it matter for testing?
UN ECE DCAS (Driver Control Assistance Systems) is a regulatory framework from the United Nations Economic Commission for Europe that governs advanced driver assistance functions. Its newer provisions use more open-ended language about test coverage requirements, which means engineers need to derive and cover a much larger space of scenarios than previous concrete-specification regulations required. This directly expands the simulation burden for OEMs seeking certification in European markets.
Why can’t OEMs certify AI-based ADAS systems the same way they certify traditional software?
Traditional safety-critical certification (ISO 26262, MISRA C, formal verification) relies on systems producing deterministic outputs for given inputs. AI-based perception and decision-making functions are probabilistic — the same input can produce different outputs across runs. Current regulatory frameworks don’t have a settled approach for certifying systems with this characteristic. The industry is developing statistical and formal-methods approaches, but no standard has fully resolved this.
What is the “sawdust concept” as applied to automotive software?
The sawdust concept describes a situation where internal investment in building a capability generates more value than the original use case. In automotive, OEMs investing in proprietary simulation or software-defined vehicle platforms are discovering that the resulting software stack is something other OEMs will pay for — turning an internal engineering asset into a commercial product line.
How does Critical Software approach formal methods for test completeness?
Critical Software has been developing approaches to translate natural-language specifications — including regulatory requirements — into formal mathematical representations that can be proved complete using automated verification tools. The goal is not to reduce the number of test scenarios, but to identify which scenarios are genuinely necessary for regulatory compliance and remove work that doesn’t contribute to confidence or certification.
About the guests
Pierre Vincent is Director of Application Engineering at Synopsys, leading a global team of engineers supporting the adoption of autonomous system simulation solutions across automotive and aerospace and defence customers.
Emmanuel Follin is Senior Product Manager at Synopsys for AVxcelerate, a simulation platform for autonomous system development and validation, with over ten years of experience in automotive and aeronautic simulation.
Gordon Köfner is Product Manager for VTD and VTDx at Cadence, responsible for virtual test drive simulation software used in ADAS and autonomous driving validation. He joined Cadence following the acquisition of the VTD product line from Hexagon.
José Rui Simões is Principal Engineer at Critical Software, leading the Automotive vertical. He has twenty years of experience in safety-critical software across automotive, aviation, railway, defence, and space, and holds expertise in functional safety, AI integration, and systems architecture.
Khaled Alomari is Manager at MHP, a Porsche company, specialising in software-defined vehicles and autonomous driving. He has a research background in intelligent control methods and ADAS algorithm development from Freie Universität Berlin.
This article is based on interviews recorded at Tech.AD Europe Berlin 2025 for the Under the Hood: Automotive Storytelling podcast. Listen to the full episode wherever you get your podcasts.
Outbound citations
- UN ECE Regulation on DCAS — official regulatory text — referenced in context of expanding scenario coverage requirements.
- Euro NCAP 2026 Assessment Protocols — the basis for Gordon Köfner’s discussion of expanding test domains.
- ISO 26262 Road Vehicles — Functional Safety — the foundational safety standard underpinning homologation discussions throughout the episode.
- ASAM OpenSCENARIO Standard — the open standard for scenario-based testing referenced by Gordon Köfner as enabling cross-tool comparability.
- Synopsys AVxcelerate Autonomous Vehicle Simulation Platform — the product discussed by Pierre Vincent and Emmanuel Follin.
Linked articles: Charlotte Eisner from Bolt