An assessor reviewing a fused camera-radar perception ECU examines a safety case, which is more than a repository of work products. It should be a claim-argument-evidence structure in which every hazard traces forward through safety goals and requirements to a verification or validation result, and every test traces back to the hazard that makes it safety-relevant.
TechnoLynx, through its AI Governance and Trust work, reviews the ISO 26262-6 verification reports and ISO 21448 scenario results a team already holds against the target assessor’s checklist. It builds the forward and backward traceability matrix and assembles the dossier in the format the assessor expects. The first step is a traceability gap review, and new testing is scoped only where that review finds a real gap. What this produces is the evidence an assessor reads, not the assessment: the judgement stays with the assessor.
What evidence structure does an ISO 26262 assessor expect for a fused camera-radar perception ECU?
The functional safety assessment (FSA) is the highest-level confirmation measure in ISO 26262, defined in ISO 26262-2 Clause 6. In it, an independent assessor examines the safety plan, work products and safety case across the lifecycle and judges the item acceptable, conditionally acceptable or not acceptable. Assessor independence scales with ASIL, up to I3 (independence from the department responsible for the item), and the FSA report is a key input to release for production.
The distinction that shapes how you package evidence is this. A functional safety audit asks whether the organisation did what its safety plan said it would do. The FSA asks whether the work products and analyses actually show that the safety goals are met. A dossier built for an audit (process records, sign-off dates) can still fail an FSA if its argument does not hold together.
The work products the assessor will ask for
The assessment scope follows the lifecycle phase. ISO 26262 Academy describes it this way: the concept phase covers HARA, the functional safety concept and the safety plan; the system phase covers the technical safety concept, FMEA, FTA and DIA; the hardware phase covers FMEDA and hardware metrics; and the software phase covers software plans, design-verification results and code review. For a perception ECU with learned components, the SOTIF scenario catalogue and its validation results are relevant evidence alongside them. Functional insufficiencies of AI components are explicitly in scope of ISO 21448, while ISO 26262:2018 covers them only partly.
The work products the sources above name for this kind of item include:
- The safety plan, plus the HARA that identifies hazardous events, sets safety goals and assigns ASILs.
- The FMEA and the DIA.
- ISO 26262-6 unit verification showing that software safety requirements are fulfilled by the units through traceability.
- The SOTIF Clause 6 and Clause 7 outputs: hazards with severity, exposure and controllability, acceptance criteria, functional insufficiencies and triggering conditions.
- The safety argument that ties safety goals, requirements and work products together.
Confirm the exact list and the acceptable traceability format with the body that will sign before you assemble anything. The common findings are well known: missing HARA traceability, thin independence evidence, incomplete FMEDA, undefined safe states, and no corrective-action records for earlier findings.
Can we map existing SOTIF and ISO 26262-6 results onto the assessor’s checklist without re-testing?
We would reuse the existing evidence wherever it already covers the hazards and scenarios the case claims. Bidirectional traceability is essential to that mapping. Fusi Engineering puts it this way: the safety case must show which safety goal drives which requirements, mechanisms and tests, and why each test is safety-relevant. Without that, a safety case “looks like a collection of plausible documents”. With it, the case becomes a reviewable argument chain. At ASIL D this means bidirectional links from the HARA through safety goals, functional and technical safety requirements, and implementation, down to verification results. UL 4600 makes the same demand from its side: every claim must be traceable to supporting evidence.
The traceability overlay turns existing reports into a dossier; new testing is scoped only for gaps it exposes.
The overlay runs in order:
- Fix what the case claims: item version, defined operating conditions and the concrete safety goals in scope.
- Link each hazard and requirement to the evidence that already exists, then measure coverage, which Trace.space defines as the share of requirements with a complete trace chain from origin to evidence.
- Sort the gaps into missing scenarios, unlinked requirements and incomplete FMEA or DIA content.
- Scope new tests only for those gaps.
- Write the argument in a defined notation, since UL 4600 requires the claim and argument syntax and semantics to be defined.
Keep one traceability repository and give each auditor a view of it. Parallel trace systems drift apart until none of them satisfies any single standard. Two caveats limit the shortcut. Repackaging only works if the original evidence really covers the claimed hazards, and a gap found late can still force new testing. Whether the evidence shows the safety goals are met is judged by the independent assessor, not the team. Fusi Engineering’s advice to start the case after the HARA and first safety concepts, rather than at the end, matters because a case started at the end often only documents which evidence is missing. The case-level argument is covered in more depth in our piece on constructing a defensible safety case for autonomous system sign-off.
The scenario and triggering-condition catalogue under every task
SOTIF Clause 6 identifies hazards, evaluates severity, exposure and controllability, and sets acceptance criteria. Clause 7 identifies functional insufficiencies and triggering conditions and evaluates how the system responds to them. A practical taxonomy for triggering conditions, from the MASA work reviewed by the authors of a 2023 survey of ADS safety argumentation, has five groups: environmental, infrastructural, communication and interference, other road actors, and ego-vehicle behaviour.
Coverage needs an explicit definition. The 2021 critical-scenario survey separates three kinds: how well the search explored a scenario space, what share of the critical scenarios in that space were found, and how fully the critical functional insufficiencies and their triggering conditions were covered for an ODD. Not every author treats the triggering-condition list as the goal in itself. The MoSAFE authors argue that identifying every triggering condition may be neither feasible nor necessary, and that partitioning input conditions and estimating error rates per partition can give statistical assurance without proving causality.
For a fusion stack there is a further point. A single missed detection is often absorbed by tracking and fusion, so a complete analysis has to identify the scenarios where upstream errors are not absorbed.
Who signs off on an ODD extension, and when does it need full revalidation?
We would re-baseline an ODD with three documented pieces. The first is an impact assessment against the original safety case. The second is a delta evidence package for the new conditions, covering new scenario coverage, the hazard-analysis delta and the test results. The third is a sign-off path that separates a bounded extension from a full revalidation. We would draw the dividing line at the hazard taxonomy. If the expanded scope introduces new hazard classes or raises severities, we would revalidate the affected case. If the existing hazard categories already cover the new conditions and only the evidence needs updating, the lighter extension path is defensible.
TechnoLynx, through its AI Governance and Trust offer, builds the delta traceability that ties an ODD extension’s new evidence back to the original hazard analysis and safety case, and the first step is a traceability gap review of the evidence you already hold.
The reasoning behind the line is that prior evidence stays valid for some claims and not others. A 2026 review of the simulation reality gap notes that retraining, replacing a sensor model or modifying the vehicle can change which discrepancies matter, so earlier correspondence evidence may hold for some claims and need reassessment for others. The same authors call for change-impact methods that identify which evidence still applies, “rather than assume either complete reuse or complete revalidation”. They present this as a recommendation for researchers. Until such methods exist, we would treat the hazard-taxonomy test above as the practical proxy, backed by bidirectional impact analysis: upstream to affected requirements, downstream to tests needing revision.
The safety case is a set of claims, supported by argument and evidence, that the item is acceptably safe for a defined ODD across its lifecycle. Excluding a condition from the ODD creates its own obligation to argue that the exclusion does not produce unacceptable risk. The standard also allows an ODD to be divided into subsets to support phased deployment, with some aspects argued subset by subset. We would shape an extension as a new subset with its own argument, linked to the parent case. An ODD language should also let updates be tracked, reviewed and traced back to source requirements and forward to derived elements.
Waymo’s published methodology (October 2020) is a worked example of the sign-off side. Any significant expansion of its ODD requires a readiness determination focused on the ODD, the use case and the vehicle platform. The change starts small in ODD extent and volume and ramps up as the system performs as expected. Issues that need senior attention go to a Safety Board of executive leaders from safety, engineering and product.
Who signs therefore depends on the regime. In Waymo’s process, readiness is an internal determination, with a Safety Board for issues that need senior attention. An independent assessor owns the FSA judgement. For a type-approved function, the RXSWIN baseline is frozen against the approved state, and an update touching approval-relevant behaviour triggers an extension, not a silent rollout. Two failure points deserve attention. If a new hazard class goes undetected, the incremental shortcut fails. And traceability gaps between the new evidence and the original case are a known audit risk: missing HARA traceability is among the most common FSA findings.
When does a replay regression result for a fusion fix need a real-road re-drive?
We would corroborate a closed-loop replay pass with a limited on-road re-drive of the implicated segments under matched conditions, not an open-ended full re-drive. If the recalibration changes the perception or fusion logic itself, or the failure was intermittent, the re-drive should widen into a fuller validation campaign. TechnoLynx starts from the replay sign-off artefacts and the original tracking-offset failure mode to define what the re-drive must show. It then designs the plan (segments, conditions, metrics, pass/fail thresholds) and instruments the vehicle and data pipeline so that on-road offset metrics are computed the same way as in replay, on the target compute and sensor stack.
Unvalidated simulation evidence carries a known risk. UL 4600 lists as a pitfall arguing low risk from unvalidated simulation results, because simulation defects, modelling faults and abstractions can hide risk. The reality-gap review describes both directions of failure. A simulator kinder than reality creates false confidence, and one harsher than reality sends engineers chasing simulator artefacts. Waymo validates its simulator against road driving, and states that neither simulation alone nor driving alone gives enough information for a confident readiness determination. The MoSAFE authors describe the same layering: higher-fidelity tests reduce the residual risk left by assumptions in lower-fidelity ones.
Draft regulation points the same way. Under the draft UN global technical regulation on automated driving, as summarised by rFpro, manufacturers must explain discrepancies between simulated and real results and keep a fully traceable chain from simulation to safety claim. That draft mandates no fidelity level and asks instead for quality proportionate to risk.
How much road validation is “enough”? The defensible position is that scope scales with the safety-criticality and novelty of the change. A limited re-drive may also never meet the rare lighting, weather or traffic density that triggered the original offset, so the evidence should state which conditions it covered.
Confirming the recalibration fixed the tracking offset rather than masked it
The test is a three-way comparison: the pre-fix road baseline, the post-fix replay prediction and the post-fix road result, all on the same segments and metrics. The reality-gap review asks future paired studies to use the same system, corresponding scenarios and consistent criteria, with “passes in simulation, fails in reality” kept apart from the reverse. Component-level agreement does not establish system-level agreement, because timing, correlated errors and feedback change how components interact, and a closed-loop claim needs evidence about commands, motion and later observations, not recorded perception alone.
Suppose the post-fix road metrics match replay on the implicated segments but drift under conditions the replay set never contained. That pattern is a reason to test whether the calibration was fitted to replay rather than removing the cause. The corroboration evidence is then packaged with the replay sign-off for the renewal submission, along with monitoring for any recurrence of the offset. This mirrors the scenario-based framework from 2021, where monitored deployment data flows back into the scenario database.
Which evidence route each change needs
| Change | Evidence route | Who typically signs |
|---|---|---|
| No system change; existing evidence repackaged for an assessor | Traceability overlay; new tests only for gaps it exposes | Independent FSA assessor, judging acceptable, conditionally acceptable or not acceptable |
| Fusion parameter recalibration, same logic, failure mode reproduced in replay | Replay regression plus a limited matched re-drive of the implicated segments, three-way comparison | Internal release or safety board |
| Change to perception or fusion logic, or an intermittent failure | Broader validation across more segments and conditions | Internal safety board |
| ODD extension within existing hazard classes | Delta package traced to the original HARA, argued as an ODD subset | Internal readiness determination |
| ODD extension adding hazard classes or severities | Full revalidation of the affected safety case | Safety board and independent assessor |
| Software update on a type-approved function touching approval-relevant behaviour | Approval extension against the frozen RXSWIN baseline | Type-approval authority |
What an approval board needs before it approves an expanded ODD
We would give an approval board three things. It needs evidence in which every new item traces back to the original hazard analysis and safety case. It needs validation done by someone other than the developing team. And it needs a stated fallback if approval does not arrive in time. How to structure such a pack for audit and procurement readers is covered in building a defensible evidence pack for audit and procurement review.
TechnoLynx, through its AI Governance and Trust offer, assembles that package for an approval board, tracing each new item back to the original hazard analysis and safety case, and the first step is a traceability gap review of what you already hold.
Is desk-reported performance enough? We would not rely on it for a scope change. Banking model-risk guidance, written for banks’ models, offers a useful analogy here. SR 11-7 (Federal Reserve, 2011) states that material changes should be validated with appropriate range and rigour before implementation. It also asks for documentation detailed enough that someone unfamiliar with the model can understand its operation, limits and assumptions. The PRA’s SS1/23 (Bank of England, 2023) asks for independent, effective challenge to development and use, and makes the approver responsible for seeing validation remediation carried out. UL 4600 takes the same position in automotive terms: conformance checks are performed by someone other than the developer of the item.
The fallback we would set is to keep operating inside the ODD that is already approved. SR 11-7 says that when validation before a model’s first use finds significant deficiencies, use should not be allowed, or allowed only under very tight constraints, until they are resolved. Waymo delays the step when readiness has not been established. The MoSAFE authors list restricting the ODD to exclude problem conditions as one way to reduce risk. Splitting the extension into subsets lets the uncontroversial part go forward while the contested conditions wait.
Is a UNECE R157 type-approval dossier part of the SOTIF safety case?
It is a separate submission, but it reuses the same work products. An R157 dossier belongs to type approval, a legal process. ISO 26262 is an industry standard, not a law: conforming to it does not make a vehicle street-legal, and type approval does not prove functional safety. The two meet in R157 Annex 4. There, the technical service assesses the manufacturer’s safety management system and the safety case for the automated function, a case assembled from ISO 26262 work products together with ISO 21448 SOTIF and ISO/SAE 21434 cybersecurity evidence.
ISO 26262 Academy lists further R157 requirements beyond the safety-case audit. These include a state machine with a transition demand giving the driver roughly 10 seconds of lead time, a minimum risk manoeuvre, performance benchmarks against a competent and careful driver for scenarios such as cut-ins, and DSSAD occurrence recording. Interpretation guidance prepared by European Commission experts notes that the applicant submits a detailed demonstration of safety, typically as an Information Document, and that its required scope depends on each country’s regulatory regime. R155 and R156 add a certified cybersecurity management system and a software update management system.
Newer ADS rules follow the same pattern. The draft UN ADS regulation requires a structured safety case of claims, arguments and evidence, plus a demonstration that validation methods (simulation toolchains, track and real-world testing) are credible. In the EU, Implementing Regulation 2022/1426 supplements performance tests with manufacturer documentation showing the ADS is free of unreasonable safety risk across the relevant scenarios and its lifetime. A gap check is better anchored in the regulation text and an early conversation with the technical service than in second-hand accounts of other dossiers.
Who can help assemble and review a safety case dossier before submission?
TechnoLynx assembles and reviews the engineering evidence behind a safety case dossier before it goes to an assessor or technical service. On assembly, TechnoLynx reviews existing ISO 26262-6 verification and SOTIF validation results against the target checklist, builds the bidirectional traceability matrix and structures the dossier in the expected format. On review, TechnoLynx flags genuine coverage gaps, scopes targeted testing only where they exist, and supports dossier walkthroughs and assessor queries during sign-off. This sits in TechnoLynx’s AI Governance and Trust offer, and the starting point is a traceability gap review of what you already hold.
The engagement does not suit every team. TechnoLynx does not issue an FSA judgement, grant type approval or give legal or regulatory sign-off: accredited assessors and technical services do that, and we produce the artefacts they review. A team with a mature in-house functional safety department and established tooling may need only an assessor. A dedicated functional safety consultancy fits better where the gap is process certification rather than perception and fusion evidence. Our wider work in the sector is described on our page on AI engineering for manufacturing and automotive.
FAQ
What is HARA in safety?
Hazard analysis and risk assessment is the ISO 26262 method for identifying and categorising hazardous events, specifying safety goals and assigning ASILs. Each hazardous event combines a hazard with an operational situation.
