ISO 26262 and ISO 21448 divide automotive safety risk by where the hazard comes from. ISO 26262 functional safety covers malfunctions such as hardware failures, software faults and systematic errors. ISO 21448 (safety of the intended functionality, SOTIF) covers hazards that arise when every component works as designed but the intended function cannot cope with the scene in front of it. A sign-off package therefore carries two kinds of evidence. The first is an ISO 26262 safety case showing that the ASIL-derived safety requirements are met. The second is a SOTIF safety argument showing that the residual risk from functional insufficiencies is acceptable across the operational design domain (ODD). TechnoLynx builds the SOTIF side for a perception stack from three engineering artefacts: a scenario campaign framed against the applicable SOTIF and ODD framework, quantitative pass/fail metrics for each scenario category, and a traceability package for sign-off. Approval-grade evidence is an engineering output, not a policy or marketing write-up.

ISO 26262 functional safety and SOTIF: who owns which perception evidence

ISO 26262 implicitly assumes that all functionality can be specified, but a learned perception subsystem cannot be fully specified beyond its training set, so testing it is always incomplete. ISO 21448:2022 explicitly excludes faults covered by the ISO 26262 series, as well as cybersecurity threats. It applies to functions whose situational awareness comes from complex sensors and processing algorithms, across driving automation levels 1 to 5.

The two standards also classify hazards differently. ISO 26262 assigns an Automotive Safety Integrity Level (ASIL) from exposure, severity and controllability during the hazard analysis and risk assessment (HARA). The SOTIF analysis identifies hazards without assigning ASIL levels. According to a 2023 arXiv analysis of ISO 21448’s quantification guidance, the standard treats severity and controllability as yes-or-no questions when selecting SOTIF-relevant hazardous events, and it leaves exposure out of that first evaluation.

A camera-based object detector has to satisfy both standards at once. Under ISO 26262 it needs hardware reliability (diagnostic coverage, safe failure fraction) and a software process suited to its ASIL. Under ISO 21448 it needs adequate detection performance across the ODD, including edge cases, adverse weather and difficult lighting. ISO/PAS 8800, released in December 2024, extends both standards for AI. Malfunctions in AI systems are handled by tailoring clauses of ISO 26262-4, -6 and -8, and functional insufficiencies by extending ISO 21448 concepts.

Side by side: what each standard expects of a perception function

Hazard source	Malfunctions: hardware failures, software faults, systematic errors	Gaps in specification or performance while every element works as intended
Classification	ASIL from exposure, severity and controllability in the HARA	Hazards identified, no ASIL assigned
Core analysis	HARA, safety concept, confirmation measures	ODD, triggering conditions, known and unknown hazardous scenarios
Sign-off artefact	Safety case against ASIL-derived requirements	SOTIF safety argument that residual risk is acceptable across the ODD
Typical perception evidence	Diagnostic coverage, safe failure fraction, coding guidelines, unit test coverage	Detection performance across the ODD, including adverse weather and lighting
AI extension	ISO/PAS 8800 tailoring of ISO 26262-4, -6 and -8	ISO/PAS 8800 extensions of ISO 21448 concepts

What corner-case coverage does SOTIF need before a perception function can be signed off?

SOTIF provides only a non-exhaustive list of scenario factors, not a fixed set of corner cases. Scenarios for an ADAS perception function can be built from its ODD combined with the triggering conditions that could provoke hazardous behaviour, and their coverage argued against a recognised scenario framework such as ISO 34502.

LynxBenchAI benchmarks the throughput, latency and memory of candidate target hardware, so the first step is to run it on that hardware to check whether it handles the replay volume; it measures the hardware, not your perception workload.

TechnoLynx builds this coverage as an engineering campaign. It starts by framing the specific robustness question (lane detection under rain, or blind-spot detection with a trailer attached) against the applicable SOTIF and ODD framework. It then implements the lighting- and sensor-variation test suite, runs replay and stress campaigns at scale on the target compute, and turns the results into pass/fail metrics for each category, ready for the traceability package.

Building the scenario space from the ODD and triggering conditions

The ODD is the set of environmental conditions the function is designed to work in, and it must include every parameter needed to make that definition meaningful, such as limits on road conditions. Weather (rain, fog, snow), lighting (day, night, glare), road type and geography all belong in it. SOTIF validation has to show safe behaviour inside the ODD and safe handling at its boundary, typically by handing control back to the driver or bringing the vehicle to a safe stop. ISO 21448 defines a triggering condition as the specific condition of a scenario that sets off a system reaction leading to hazardous behaviour.

For perception, triggering conditions act on specific sensor properties. For cameras these are brightness and contrast. For lidar they are point count, signal intensity, noise points, SNR and measurement range. Target distance matters too: most triggering conditions reduce the sensor’s effective detection distance, so a distant target combined with another triggering condition is harder to detect.

ISO 34502 adds detail to ISO 21448 Clause 7 by identifying reasonably foreseeable risk factors, structuring them into critical scenarios and compiling those into a scenario catalogue for testing. It also calls for a representative set of test scenarios that can show the relevant scenario space has been covered well enough in the search for unknown hazardous scenarios. ISO 21448 sorts scenarios into four areas: known and not hazardous, known and hazardous, unknown and hazardous, and unknown and not hazardous. The campaign has to show that the residual risk in the two hazardous areas is at or below the acceptance criteria. Structuring that taxonomy so it survives ODD expansion deserves its own treatment, which we give in building a defensible scenario taxonomy and safety case for SOTIF.

A structured method identifies triggering conditions more completely than relying on expertise alone. In one ontology-based study, seven triggering sources (including pedestrians, illumination and rain) produced 87 candidate triggering conditions. Of those, 20 were field-tested and 15 caused unexpected vehicle behaviour. One lidar perception study found that traffic density affects both the false-negative rate and occlusion, and modelled it as a new triggering condition.

Mapping an existing log library and filling the gaps

ISO/PAS 21448 describes two complementary routes for perception verification: dedicated expert scenario generation (knowledge-driven) and large-scale random data recording (data-driven). Mapping your existing logs against the catalogue first shows which triggering-condition categories are already represented and which are empty. Data gathered for development is usually a poor approximation of the system’s ODD in the open world. Treat it as a starting inventory, not as evidence. Two of the constraints the perception-testing literature sets out apply here. The test scenario catalogue must be statistically significant and cover the ODD well enough, and test data must be kept separate from development data.

Simulated scenarios complement field testing, which is costly and sometimes dangerous. In ASAM OpenSCENARIO 2.0, one abstract scenario with parameter ranges can expand into hundreds or thousands of concrete scenarios, and coverage statements set which parameter ranges must be reported. Cross-coverage, a multi-dimensional map of related coverage items, is a stricter measure than any single item on its own.

Simulation leaves gaps that higher-fidelity tests are used to close. In the layered residual-risk view, higher-fidelity tests reduce the risk left by assumptions in lower-fidelity ones, closed-course tests reduce gaps left by simulation, and field testing discovers new scenarios and gaps in the catalogue. We recommend that final sign-off for a perception function rest on replay or on-vehicle evidence from real adverse-condition footage, with synthetic stress tests extending coverage where real miles do not yet exist. Recorded field data should also be re-processed offline whenever the perception algorithm changes.

How do we set miss-rate, false-detection and latency thresholds for each scenario category?

UL 4600 defines no performance or pass/fail criteria, and current automotive safety standards mostly leave the design of perception tests to the manufacturer. An acceptance criterion represents the absence of unreasonable risk, and it can be qualitative or quantitative, for example a maximum number of incidents per hour. ISO 21448 gives GAMAB, positive risk balance, ALARP and minimal endogenous mortality as examples for formulating a quantitative criterion.

Once an acceptance criterion exists, validation targets can be derived from it at the level of harm, of hazardous behaviour, or even of individual triggering conditions. ISO 34502 shows the form a perception target can take: a limit on how often something happens, such as the perception element passing incorrectly perceived objects to the control element less than once per y hours in the operational domain. To turn a qualitative criterion into a test, you set an interval on a metric that decides pass or fail.

Count the misperceptions that matter

UL 4600 expects a claim of acceptable perception performance to be supported at least by false-negative and false-positive rates. Raw rates make a weak release gate, though, because standard machine-learning metrics do not show whether perception output is good enough for safe vehicle operation. The ISCaP safety-case template defines risk-aware metrics instead. These count only misperceptions that match a hazardous pattern and ignore harmless ones, which keeps each metric traceable to a safety claim.

Timing matters as much as counting. In the STEAM and MoSAFE worked scenario, 19 or more false-negative frames within 150 could cause a collision, while fewer than 19 could not. In the ISCaP case study, a tracker that drops a track after 9 consecutive misses, combined with a 5-frame braking interruption, gave a threshold of 14 false-negative occurrences. A release threshold for rain or occlusion is therefore best written as a limit on a hazardous error pattern within that scenario category, with the miss rate and false-detection rate reported alongside it.

Each measured rate also needs its sampling error accounted for. ISCaP uses the upper bound of a confidence interval, m + z√(m(1−m)/N), with the Normal approximation once N exceeds 30 and z = 2.58 for 99 percent confidence. Latency belongs in the same table. The SMIRK pedestrian emergency-braking case study (2022), for instance, required an inference speed of at least 10 frames per second in simulation, a false-negative rate of no more than 7 percent within 50 m, and false positives per image of no more than 0.1 percent within 80 m. Those figures come from one research system tested in simulation, and they do not carry over to another OEM’s function. Your own safety case and your approver’s expectations decide the numbers. Criteria and scenarios also interact: a field-of-view criterion might reasonably be relaxed when the ego vehicle drives slowly in rain.

Proving a rain regression is actually fixed

A defensible protocol re-runs the whole rain category, including its parameter sweep, against the same threshold, on verification data that never influenced training. The SMIRK case went further on independence: verification data was kept separate from development, and the verification work was led by engineers who had no part in developing the model.

For lane departure warning systems (LDWS), function-level test procedures already exist. NHTSA’s heavy-vehicle work lists ISO/DIS 17361 and EU Regulation 351/2012 among them, and its lane-change test used five repetitions at each of 25, 35, 45 and 55 mph in both directions. Those procedures fix the manoeuvre, not the weather, so the adverse-condition layer still has to come from the SOTIF analysis.

How many hours, miles or scenario encounters are statistically enough?

For fatalities and injuries, test-driving alone cannot provide sufficient evidence. RAND (2016) found that showing autonomous-vehicle reliability for fatalities and injuries would take hundreds of millions, and sometimes hundreds of billions, of test miles, which existing fleets would need tens to hundreds of years to drive. Sufficiency is argued scenario partition by scenario partition instead.

In the MoSAFE approach, the probability of each hazardous error pattern is estimated by testing within one group of scenario conditions. Those estimates are then combined according to how often each condition occurs in operation. Conditions that are discrete events have their rates expressed per hour or per kilometre. Persistent conditions, such as following another vehicle, are expressed as a share of driving time or distance. The ISCaP template decomposes its top-level bound formally. Its top-level limit on misperception-caused crashes splits into a crash rate, a misperception-pattern rate and scenario exposure, so each leaf becomes a rate that testing can estimate.

Sensor redundancy helps when the inputs are statistically independent. One review notes that if two statistically independent fusion inputs each show a mean time between failures of 10^4 hours, the fused output reaches about 10^8 hours. The test kilometres actually needed are then computed from how dependent the inputs really are. The honest answer to “how many encounters” is the sample size each partition needs before its confidence bound falls below its allocated target, not one mileage figure for the whole fleet. When real-world data is thin, statistically defensible validation methodologies under limited real-world data goes deeper into the sampling side.

How should the traceability package be laid out so a safety manager or non-engineer can sign it?

The package TechnoLynx assembles turns quantitative pass/fail metrics per scenario category into a traceability package for sign-off. The perception-testing literature asks for scenarios, criteria and reference data to be handled together, because rain in a scenario can affect how reference data is produced and how sensitive the metric is to it. ISCaP’s formal breakdown gives traceability from every lower-level claim up to the top-level safety target. Each limit can then be read either as a requirement passed down or as a conservative estimate passed up.

ASAM’s OpenSCENARIO 2.0 concept paper sets the goal that a system engineer can trace which hardware and software in the stack each test verifies. An ISO 26262 functional safety assessment report names the work products it analysed, together with their revision numbers.

Checklist: the columns a signable traceability matrix carries

1. Requirement or safety goal ID, with its origin in the HARA or the SOTIF hazard analysis.
2. The triggering condition and the part of the ODD the scenario represents.
3. Scenario ID and the approved scenario-set version, since unapproved scenarios cannot be used for certification.
4. Test case and platform, plus the validation status of the environment used to re-process recordings.
5. Dataset or recording version, with confirmation that it was kept separate from development data.
6. Reference data source and its known limits.
7. Metric, threshold, confidence bound and measured result.
8. Verdict, reviewer, date, and the model and configuration hash the result applies to.

Above the matrix sits a one-page summary that states, for each scenario category and in plain pass/fail language, what was tested, against what bar, with what result, and which findings remain open. Writing it well is part of the engineering, because a safety manager who cannot read the evidence cannot defend it. ASAM makes the same point about scenario languages: they must be readable by safety engineers, regulators and potentially the general public.

Testing is necessary but not sufficient for safety assurance. Where that line falls is drawn out in what a perception validation pack is not. Turning scenario results into evidence an auditor can work with is covered in building audit-ready scenario-based testing evidence for ISO 21448 SOTIF.

Who can build the scenario campaign and evidence package for our ADAS perception stack?

TechnoLynx builds the engineering behind a SOTIF evidence package for ADAS perception. That means framing the robustness question against your ODD and a recognised scenario catalogue, implementing the scenario and variation test suite, running replay and stress campaigns tuned to your target compute, and assembling per-category metrics into a traceability package your safety manager can review. Whoever does the work, ask to see how scenarios and datasets are versioned and how a single result traces back to its requirement. Where the open question is which hardware should run the replay volume, LynxBenchAI is the tool for measuring that hardware. TechnoLynx’s wider automotive work is described under AI engineering for manufacturing and automotive.

This work produces engineering evidence, not certification. Teams that need certification of their SOTIF management process can go to a certification body that runs such a programme directly. If your safety team already runs a mature scenario pipeline, an assessor’s pre-assessment may be the better use of budget.

Does adding a SAM-derived segmentation module reopen our SOTIF scenario catalogue?

In our judgement, adding a segmentation module derived from Segment Anything (SAM) reopens the SOTIF scenario catalogue if the module’s output can influence a safety-relevant decision. Only a genuinely advisory module, whose output nothing downstream relies on, can be handled with a narrower, targeted re-validation. Treat this as engineering judgement rather than a reading of a specific significant-change clause, and have the classification documented and reviewed by the safety assessor instead of assumed.

SOTIF is an iterative lifecycle, and the operation-phase activities in ISO 21448:2022 Clause 13 must be completed before formal system updates are released. A new learned module brings its own functional insufficiencies. ISO/PAS 8800’s cause-and-effect model gives the example of a training set that lacks an object class: when that object appears on the road, its presence becomes a triggering condition. A promptable segmenter trained on general imagery has different gaps from the fixed detector it sits beside, so its triggering conditions have to be identified for it, not borrowed from the detector.

Minimum re-validation scope for an advisory-only signal

Whether a perception error is safety-critical depends on the downstream driving function. For an advisory signal, that cuts both ways. If planning or arbitration logic in practice uses the segmentation output, for example to confirm free space, the module is safety-relevant whatever its label says. Modular architectures with explicit contracts, assumptions and guarantees at the interface between perception and planning allow existing perception test results to be reused.

For a truly advisory module, the minimum defensible scope has three parts. First, document the interface contract showing that no safety decision uses the output. Second, re-process the existing regression recordings to show the safety-relevant path is unchanged. Third, analyse the new module’s failure modes for anything that could leak into that path. If the module feeds a decision that carries an ASIL, our recommendation is to treat the change as significant. That means repeating the identification of functional insufficiencies and triggering conditions, then extending the catalogue to cover what it finds.

A release-readiness review that gates every perception model change, and records the change classification as one of its outputs, keeps this decision from being made informally. The wider pattern of revalidating after a change and rolling back when needed is covered in keeping deployed models trustworthy through revalidation, monitoring and rollback.

Which accredited assessors review camera-radar fusion stacks, and is a pre-assessment worth running?

Certification bodies offer accredited ISO 26262 assessment and certification services. Two examples are exida, accredited by ANAB to ISO/IEC 17065 and ISO/IEC 17025 and by INAB to ISO/IEC 17065, and TÜV SÜD, whose ISO 26262 services include inspections accredited to ISO/IEC 17020 and ISO/IEC 17025. exida lists ISO 26262 certification and an ISO 21448 SOTIF management-process programme among its schemes. TÜV SÜD’s listed services include plausibility checks of the HARA, confirmation reviews of the safety concept, and document and verification reviews of development work products at any project stage.

Check whether an assessor has reviewed camera-radar fusion perception through references on comparable stacks rather than marketing pages. Treat lead times and engagement durations as questions for each body, not figures to assume. Ask each shortlisted body directly and plan around their answer.

What the assessment examines

Under ISO 26262, confirmation measures consist of confirmation reviews, a functional safety audit and a functional safety assessment. The functional safety assessment applies at ASIL C and D. It is planned at the latest at the start of system-level product development, carried out progressively, and completed before release for production. That timing is the real lead-time constraint: an assessor brought in only once the evidence is complete arrives too late to shape it.

The assessor decides how broad and deep the analysis goes, and the report can recommend conditional acceptance, listing the corrective actions required. A confirmation review of the safety case judges whether its argument is convincing enough.

Shortlisting an assessor

• Accreditation body and scope covering the standards involved, including the SOTIF process where that matters.
• Experience on comparable camera-radar fusion perception work, confirmed with past clients.
• Availability at the point in the programme where the assessment has to begin.
• Willingness to run a pre-assessment readiness check before the formal engagement.

In our view, a pre-assessment is worth running when the schedule allows it, because it exposes gaps in the traceability chain while they are still cheap to close.

How do we tie milestone payments to validation readiness in the statement of work?

For an ADAS validation contract, we would structure the statement of work as a series of fixed-fee phases. Each fee is released only when a go/no-go gate passes against measurable exit criteria, not on calendar dates. The pattern below is our recommendation rather than an established industry norm.

Gate	Exit criteria	Payment released
1. Scope and framework	ODD, triggering-condition analysis and thresholds for each scenario category agreed and signed by the safety manager	Phase 1 fee
2. Coverage map	Log library mapped to the catalogue, gaps quantified, plan for targeted collection or synthetic data agreed	Phase 2 fee
3. Campaign results	Every category run, results compared with thresholds including confidence bounds, failures logged	Phase 3 fee
4. Package readiness	Traceability matrix complete, pre-assessment findings closed or formally dispositioned	Phase 4 fee plus holdbacks

Holding back part of each phase fee until its gate is signed off gives the buyer a way to stop paying when a checkpoint fails. Time-and-materials suits only the exploratory scoping before gate 1, when nobody can yet write a measurable criterion.

Every exit criterion that marks a function as ready for formal assessment should be a number someone can check. A gate worded as “robust in rain” cannot be enforced. “False-negative pattern rate below the allocated bound, at the agreed confidence, across the rain category” can. Two cautions apply. List gates that depend on vehicle access, track time or an assessor’s calendar separately in the contract, because they sit outside the work itself. Rigid gates can also reward passing early on a thin scenario set, which is why the coverage map has a gate of its own.

The package is only as current as the model it describes

An evidence package signed against one model version describes that version and no other. The real world also drifts away from the ODD description, and the perception-testing literature notes that the ODD and its scenario coverage therefore have to be updated repeatedly. The question a programme still has to settle is not whether it can produce one signable package. It is whether its pipeline can produce the package again for every release without rebuilding it, with the change classification, the re-run catalogue and the new verdicts all coming out of the same tooling.

FAQ

Can you give an example of a SOTIF hazard?

A camera with limited contrast resolution, a dark-coloured vehicle ahead and poor light can together cause a late or weak detection. The system then brakes too late and hits the vehicle from behind, even though nothing has malfunctioned.

How do you calculate a false negative rate?

The false negative rate is the number of missed objects divided by the number of objects actually present, that is FN / (FN + TP). In object detection, false negatives are objects the system misses, and false positives are ghost objects it reports that are not there.