Automotive functional safety rarely fails because a team has produced no documents. More often, the evidence exists but no longer forms a coherent chain from the original hazard analysis to the implemented system and its verification. For vehicle manufacturers and suppliers, the practical challenge is to keep assumptions, requirements, interfaces, test results and change records aligned as responsibility moves across organisations and lifecycle stages.
HARA establishes more than an ASIL label
Hazard analysis and risk assessment is the first major point at which evidence can become disconnected from engineering reality. Under ISO 26262, hazards are assessed using severity, exposure and controllability, leading to classification from ASIL A to ASIL D or treatment under quality management. The result should guide the rigour of subsequent development, but the classification alone is not a sufficient hand-off. Downstream teams also need to understand the operational situation, hazardous event, system boundary and assumptions behind each safety goal.
A useful overview of the ISO 26262 automotive safety lifecycle shows why this context must survive beyond the concept phase. Functional safety management, system development, hardware, software, production and supporting processes are interdependent. If a supplier receives only a requirement identifier and an ASIL allocation, without the assumptions that made them valid, its design may be technically competent yet unable to support the vehicle-level safety argument. The evidence chain has already weakened before detailed design begins.
Requirements fail at organisational boundaries
The most common supplier hand-off problem is an ambiguous allocation. A vehicle-level safety goal is decomposed into technical safety requirements, but responsibility for detection, diagnostics, fault reaction or warning behaviour remains implicit. One organisation assumes the other will implement the mechanism. Each supplier can then satisfy its local specification while the integrated system lacks a complete response to the original hazard.
Interface documents should therefore state more than signal names and nominal values. They should define timing assumptions, valid and invalid states, start-up and degraded behaviour, diagnostic coverage expected from each element, fault reporting, reset conditions and ownership of verification. The same discipline applies when ASIL decomposition is used: independence assumptions and potential dependent failures need explicit treatment rather than being left to architectural diagrams that different parties interpret differently.
Traceability must cross system, hardware and software layers
Traceability is often strong inside one development tool and weak between companies or disciplines. A system requirement may link correctly to a subsystem specification, yet the connection to hardware safety mechanisms, software units and integration tests is maintained through manual exports. Once identifiers are renamed, requirements are split or supplier versions diverge, reviewers can no longer determine whether every safety requirement has been implemented and verified in the applicable configuration.
This is fundamentally an information-architecture problem. Lessons from maintaining critical industrial decision logic also show why custom software that preserves process and decision traceability can be preferable to forcing specialised evidence into a generic workflow. The objective is not to build another database by default. It is to preserve controlled relationships among requirements, versions, approvals, test results and deviations without relying on undocumented spreadsheets or individual memory.
Integration exposes evidence gaps, not just technical defects
Integration is where incomplete hand-offs become visible. A component may pass its own tests while failing to behave as expected during communication loss, power interruption, timing variation or a transition into a degraded mode. These are not necessarily component defects. They may reflect incompatible assumptions about system states, environmental conditions or which element has authority to initiate and clear a fault reaction.
Software releases make this particularly difficult because a small change can alter timing, message validation or state restoration without changing the headline function. A disciplined approach to safe software updates in operational environments illustrates the necessary controls: define the change scope, affected dependencies, release conditions, rollback limits and evidence retained after deployment. In an automotive safety context, the same principles support impact analysis and help teams identify which safety requirements, analyses and tests must be revisited for a new version.
Confirmation measures depend on evidence quality
Reviews, audits and assessments cannot repair missing lifecycle logic at the end of a programme. Their value depends on whether reviewers can reconstruct the reasoning from hazard and safety goal through architecture, implementation and verification. Higher-integrity work calls for greater rigour and appropriate independence, but independence alone does not make fragmented evidence persuasive. A reviewer still needs controlled baselines, resolved anomalies and a clear record of why results apply to the released configuration.
This means evidence readiness should be checked at planned gates rather than shortly before production release. Useful questions include whether every safety requirement has an owner, whether supplier assumptions have been accepted by the integrating organisation, whether test environments represent relevant interfaces and whether open deviations have a documented impact assessment. The aim is not document volume. It is the ability to follow each claim to objective evidence and back to the risk it addresses.
Production and field changes remain part of the lifecycle
The safety case does not stop when development testing is complete. Production controls, service procedures, field information and decommissioning all belong to the broader lifecycle described by ISO 26262. A substituted component, calibration revision, tool update or manufacturing-process change can affect evidence that was valid for an earlier baseline. Change classification must therefore consider safety impact, not only cost, schedule or whether the external function appears unchanged.
Organisations can reduce hand-off failures by treating evidence as a managed product. Each delivery should identify its configuration, unresolved assumptions, applicable safety requirements, verification status and restrictions on use. Contracts and development interface agreements can assign responsibilities, but operational discipline is still required to keep those assignments current when designs change. Supplier declarations and component test reports are useful inputs; they do not replace the integrator’s responsibility to evaluate the complete system.
Build the evidence chain around decisions
A robust lifecycle begins with a simple test: can the team explain why a safety requirement exists, who implements it, how it is verified and which product version the evidence covers? If that explanation requires several undocumented assumptions, the project has a traceability problem even if every required template has been completed.
The practical remedy is process-first: preserve HARA context, define interface assumptions, control requirement versions, plan evidence at each allocation boundary and assess every relevant change against the approved baseline. ISO 26262 provides the lifecycle framework, but the coherence of the resulting safety argument depends on disciplined execution across manufacturers, suppliers and engineering teams. That coherence cannot guarantee the absence of faults; it can make gaps visible early enough to be investigated before they become integration or field problems.
