A familiar component can feel like the safest choice in a new vehicle programme. It has shipped for years, suppliers know its behaviour, and customers rarely complain. That experience is valuable. Turning it into a proven in use argument, however, requires more than a reassuring sales history.
The central question is whether documented experience supports the safety claims needed for the intended application. Answering it connects engineering, field quality and product planning. Teams that investigate this early can make informed reuse decisions before schedules depend on evidence they may never obtain.
What proven in use actually provides
ISO 26262-8:2018 addresses proven in use in Clause 14. A successful argument can provide credit for defined safety lifecycle activities covered by the candidate's service history. That credit has a specific scope; it is not a certificate that makes an existing component universally suitable for safety applications.
Integration, item safety validation and applicable confirmation measures remain necessary. The project must explain how the reused element fits its safety concept and which responsibilities remain with the integrating organisation. A supplier's positive evaluation is therefore an input to the vehicle programme, not its final safety decision.
Consider a purchasing discussion about an established electronic module. A statement that it has operated reliably may justify asking for more information. It does not yet answer which functions were exercised, which versions generated that experience, or what the new vehicle expects from it.
Start with the intended safety role
Before discussing fleet size, establish what the candidate must do in the new application. Its identity, interfaces and expected behaviour matter because evidence only answers questions about the product and conditions that produced it.
For illustration, imagine an established temperature measurement module previously used for a dashboard display. A new vehicle programme wants its output to initiate a protective response. Even if the electronics remain unchanged, the new function may need behaviour that ordinary customer experience never demonstrated. An apparently acceptable display delay could be significant when another function depends on a timely response.
This example is a prompt for analysis, not a verdict on temperature sensors. The useful conversation begins with the allocated safety requirements. Product familiarity then becomes supporting context rather than the reason for accepting the design.
Relevant experience matters more than impressive totals
The relationship between previous and intended operation needs justification. Exact equality across every environmental detail is not the governing principle. Differences in the candidate or its environment must be identified and assessed for their safety impact.
Describing one application as harsher than another can hide important distinctions. Higher vibration does not establish coverage of a different supply disturbance, and longer journeys do not establish experience with frequent restarts. Software also depends on the functions, inputs and execution conditions actually exercised.
A useful early discussion therefore asks whether the historical population encountered the behaviours that matter now. Large totals cannot answer that question by themselves. Where the relationship is weak, the team should identify what remains unsupported before claiming credit. Additional testing may provide useful evidence, but it does not retroactively create missing service history.
Reporting quality changes what the history means
A low number of complaints can mean a dependable product. It can also mean that relevant events were difficult to detect, were recorded elsewhere, or never reached the team building the argument. Those possibilities have very different implications.
Sales volume and calendar age are not sufficient measures of observed operation. The evidence needs a defensible connection between the candidate population, its experience in service and the incidents attributed to it. Commercial return statistics should not silently become safety statistics.
It is equally misleading to demand a magical guarantee that every possible failure was captured. The engineering task is to establish the reporting arrangements, understand their limitations and justify the confidence placed in the resulting evidence. Uncertainty must remain visible.
This is often an organisational challenge. Design knowledge may sit with the supplier while vehicle context and service records sit with the manufacturer. Discovering that separation during an assessment leaves little time to recover. Establishing access and ownership during planning makes the reuse decision more realistic.
Keep the statistical claim in its proper scope
Clause 14 sets ASIL-specific criteria for observable incidents and the evaluation period, with statistical confidence explicitly addressed. These criteria should not be described as interchangeable with the random hardware failure metrics in Part 5.
No observed incident is not the same as a zero underlying rate. A result derived from historical experience also depends on whether the data represents the intended application. Statistical precision cannot repair an unsupported assumption about what the fleet did or what its reporting system could detect.
For a public introduction, the essential lesson is to examine the evidence behind the number. Detailed calculations belong after the claim, population and interpretation of incidents are established. Otherwise, a polished spreadsheet can make an unresolved engineering question look settled.
Changes require an assessment, not a slogan
Configuration and change management connect past experience to the candidate being reused. A hardware revision, manufacturing change, software update or different integration environment can affect that connection. Their significance needs evaluation.
Neither automatic acceptance nor automatic rejection is a sound general rule. A change does not universally erase all previous evidence. Equally, matching a part number or retaining external functionality does not establish that the safety argument remains valid.
Planning should account for this continuing responsibility. If a team expects frequent releases, it should consider the effort needed to maintain the argument as the product evolves. The relevant business question is whether the evidence remains usable over the programme, not simply whether an initial report can be completed.
Make the reuse decision before committing the programme
Proven in use is one available approach to reuse. Existing development evidence, software component qualification and hardware element evaluation may also be relevant, depending on the candidate. ISO/PAS 8926:2024 provides a framework for integrating pre-existing software architectural elements into software conforming to ISO 26262.
Choosing an approach means understanding the evidence already available and the work still needed. Familiarity is a reason to investigate reuse carefully. It is not an assurance that the desired credit will follow.
The most productive outcome of an early review may therefore be a narrower claim, a different evidence strategy or a decision to develop something new. Each can be a sound result. What matters is that the programme understands its obligations while it still has practical choices about architecture, suppliers and delivery before production starts. A clear decision now makes later safety reviews more focused.
Explore the Academy's Proven in Use learning module for the statistical treatment, worked example and deeper evaluation guidance.
References: ISO 26262-8:2018, Clause 14; ISO/PAS 8926:2024. This introduction explains the topic; project decisions require the applicable standard and sufficient documented project evidence.
Abbreviations & Key Definitions
- ASIL - Automotive Safety Integrity Level, a classification that determines the required rigour of safety activities.
- ISO - International Organization for Standardization, publisher of the ISO 26262 functional safety standard.
- PAS - Publicly Available Specification, the publication type used for ISO/PAS 8926:2024.
Comments
Loading comments