Imagine the following scenario: An AI-based perception system passes all gate reviews with flying colors. Simulations run stably, track testing shows no anomalies. Then, after a few weeks in the field, three recurring incidents occur: low sun, wet road surface, a specific reflection pattern on the road surface. A scenario that was simply not anticipated in the validation suite.
This is not a bug in the traditional sense. The code is correct; the model behaves according to specifications. It is precisely the phenomenon for which ISO 21448, the standard for “Safety of the Intended Functionality (SOTIF),” was written: functional inadequacies without classic errors, triggered by operating conditions that no one explicitly ruled out.
AI-based vehicle functions are moving targets. Every new sensor generation, every new market, every new vehicle variant expands the Operational Design Domain (ODD): the totality of all operating conditions under which the system is supposed to function safely. This expansion is not a one-time project, but an ongoing process that runs on an 18- to 24-month cycle of new sensor generations.
The fundamental problem here is that classic code coverage metrics such as branch coverage, MC/DC, and statement coverage are designed for algorithmic code. A neural network has no branches in the conventional sense, but rather weights. Even complete coverage of the wrapper code does not verify the actual model behavior.
What actually needs to be tested are the so-called triggering conditions: those input classes that can trigger safety-critical malfunctions in the machine learning model. Triggering conditions combine in a combinatorial manner. Four weather conditions, five lighting situations, three reflection patterns: that already yields 60 basic variations, and that is a highly simplified model. Without a reusable suite of scenarios, every new validation round starts from scratch. Not because the team is doing a poor job, but because there is no structured tool available that translates ODD changes into evaluable scenarios.
The “Rule of Ten in Quality Assurance” is well-known in the embedded environment: A defect discovered only in the field costs many times more than one detected during the design phase. In projects with AI-based vehicle functions, this factor is particularly noticeable because scenario gaps are rarely isolated individual problems.
A late finding shortly before the gate review forces retests. If the scenario suite is not maintained in a modular fashion, these retests start from scratch, with the corresponding effort and time pressure. Delayed production start dates have a measurable impact on program profitability and OEM confidence.
Added to this is the pressure from type approval: the SOTIF justification must seamlessly support the safety case. If this link is missing, audit findings arise in the gaps between Safety-FMEA, TARA, and SOTIF analysis. And after series production begins, another risk looms: those who fail to establish drift monitoring are operating their safety case with an unspoken expiration date. UN R155 and UN R156 have been relevant for type approval since July 2024. Starting August 2, 2027, the high-risk requirements of the EU AI Act for AI as a safety component will take effect, with requirements for post-market monitoring and penalties of up to 35 million euros or 7 percent of global annual turnover.
The answer to a growing ODD is not complete coverage of all conceivable scenarios; that would be neither economically nor technically feasible. The answer is a structured validation pyramid in which each level addresses what the others cannot.
The ODD model itself should not be a static document, but a living engineering artifact that reflects sensor generation changes, market expansions, and release cycles. Reusable scenario suites based on standards such as ASAM OpenSCENARIO provide the foundation so that new variants do not have to start from scratch every time.
A perfect validation pyramid does not protect against every edge case. But it makes it assessable, and that is exactly what UN R155, UN R156, and the EU AI Act require.
Learn more about automotive software validation.
Not every level needs to be developed to the same extent. Simulation covers the combinatorial breadth, HIL tests system behavior under real-time conditions, and track testing provides ground truth for the most critical scenarios. Omitting one level entirely leaves a gap in provability that no other level can fully close.
An edge case is rare but known. A triggering condition is a specific input constellation that can trigger a safety-relevant malfunction, even if it is not rare. ISO 21448 (SOTIF) addresses precisely this class: risks arising from normal operation, not from hardware failures.
ISO 26262 addresses risks from random hardware failures and systematic software errors. ISO 21448 (SOTIF) supplements this by addressing risks arising from functional inadequacies without classic errors. For AI-based vehicle systems, both standards are relevant and must be considered together.
Yes. Anyone developing or planning AI-based vehicle functions today is laying the groundwork for a validation strategy and safety case. The decisions made today regarding scenario suites and ODD modeling will determine the audit effort in 12 to 18 months.
Firstname:
Lastname:
E-Mail Address:
Phone:
Subject:
Your message:
Yes, I consent to my personal data being collected and stored electronically. My data will only be used for the purpose of responding to my inquiry. I have taken note of the privacy policy.
You are currently viewing a placeholder content from OpenStreetMap. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
You need to load content from hCaptcha to submit the form. Please note that doing so will share data with third-party providers.
You are currently viewing a placeholder content from Hubspot Embedded Content. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
You are currently viewing a placeholder content from HubSpot. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
You are currently viewing a placeholder content from Hubspot Meetings. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
You are currently viewing a placeholder content from Google Maps. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.