4. Evidence identification

In a virtual safety assessment, the dossier is only as credible as the traceable link between what the standard demands and what the simulation actually produced. Evidence identification is the discipline of establishing that link deliberately, before any artifact is generated. Rather than collecting simulation logs and reports and then searching for something to attach them to, the assessor starts from the safety goals and works downward: each goal decomposes into functional safety requirements, each requirement carries an ASIL that dictates the rigor of evidence, and each validation objective defines what must be demonstrated and at what confidence. The output of this activity is an evidence map — a structured register that states, for every claim in the safety case, which virtual artifact substantiates it, how that artifact was produced, and what acceptance criterion it must satisfy.

The starting point is the safety goal itself. Consider a traction inverter in an electric vehicle with the goal "prevent unintended positive torque exceeding 30 Nm at the shaft while the vehicle is stationary or in Park." This goal is ASIL D under ISO 26262 because unintended acceleration is a plausible single-point fault leading to an uncontrollable hazard. The ASIL is not a label applied to the goal in isolation; it propagates to the functional safety requirements derived from it and, critically, conditions the evidence. An ASIL D claim cannot be supported by a single nominal-condition simulation run. It requires evidence of fault detection coverage, diagnostic test interval adequacy, and confirmation that the safety mechanism responds within the fault tolerant time interval (FTTI). Evidence identification therefore translates the ASIL into an evidence class: for ASIL D, the map must include fault-injection campaigns with coverage metrics, timing analysis of the safety reaction path, and independence evidence for the monitoring function.

Validation objectives sit between the requirement and the artifact. A validation objective is a falsifiable statement of what the virtual assessment must show — for example, "demonstrate that a torque command plausibility monitor detects an implausible torque request within 20 ms and commands safe-state torque within the 50 ms FTTI across the defined operating envelope." This objective is specific enough to dictate the simulation setup: the fault model (stuck-at torque request, signal offset, or corrupted CAN frame), the operating points to be swept (motor speed, DC-link voltage, temperature), the monitor's detection threshold, and the pass criterion (detection latency ≤ 20 ms, safe-state entry ≤ 50 ms, no false positives in the fault-free baseline). Without this intermediate layer, teams routinely produce impressive-looking simulation reports that answer no specific question.

Notice what the register forces the team to decide before running anything. The fault models must be justified against the failure mode analysis — a stuck-at request is only meaningful if the FMEA identifies that failure mode as plausible. The operating points must be traceable to the environmental and operational envelope in the item definition, not chosen for convenience. The acceptance criteria must be numeric and derived from the FTTI budget, which itself comes from the hazard analysis and the safe-state specification. When these fields are filled honestly, the simulation campaign almost designs itself, and the resulting artifacts are self-evidently relevant.

The map also exposes gaps early. If the FMEA lists a failure mode — say, a corrupted torque request that passes CRC because the CRC itself is computed on stale data — and no fault model in the register covers it, the evidence map shows an uncovered claim before the assessment begins. This is far cheaper than discovering the gap during an audit. A practical technique is to cross-reference the register against the failure mode list and the safety mechanism list: every safety mechanism should appear as the subject of at least one validation objective, and every high-severity failure mode should appear as at least one fault model. Any row in either list without a corresponding register entry is a candidate gap.

ASIL level also governs the independence and rigor of the evidence, not just its type. For ASIL D, the monitoring function that detects the implausible request must be shown to be independent of the function it monitors — a shared resource such as a common clock or shared RAM can defeat the detection. The evidence map should therefore include an independence argument artifact, typically a dependent failure analysis (DFA) report, and the simulation campaign should include fault injection into the shared resource to demonstrate that the monitor still detects the fault. For ASIL B, the same goal might be satisfied with a simpler plausibility check and a reduced fault campaign, and the register would reflect that reduced evidence class explicitly. Recording the ASIL-to-evidence-class rationale in the register is what allows an auditor to see that the rigor was chosen, not inherited by habit.

Tool confidence is a frequently overlooked evidence dimension. A virtual assessment artifact is only admissible if the simulation tool is qualified for the use case. Under ISO 26262-8, the required tool confidence level depends on the possibility of the tool introducing or failing to detect errors in the safety-related output. A fault-injection harness that silently drops injected faults would produce falsely passing results, so its TCL must be assessed and its qualification evidence — tool validation report, use-case restriction, or increased verification of outputs — must be listed alongside the simulation artifact. The register entry above includes this field for exactly that reason.

Finally, the map must record the status of each claim after the campaign: supported, partially supported, or gap. A partially supported claim — for example, detection latency met at 25 °C but exceeding 20 ms at −20 °C because the monitor's filter coefficient was not temperature-compensated — is not a failure of the process but a finding that must be resolved by design change or by revising the validation objective with justification. The evidence map is a living document through the assessment, and its value lies precisely in making the boundary between "demonstrated" and "assumed" visible at every step from safety goal to simulation trace.