Title: Proven in Use | ISO 26262 Academy URL: https://iso26262.academy/features/concepts/proven-in-use Description: ISO 26262-8 Clause 14 lets you trade development evidence for statistically demonstrated field experience. --- Concept guide · ISO 26262-8 §14 · 11 chapters # Proven in Use Most reuse decisions turn on one question: can field experience stand in for development rigour? This concept walks ISO 26262-8 Clause 14 end to end, showing how the Poisson single-sided 70% bound turns vehicle-hours into a demonstrated failure rate, and why the numbers wall closes the argument far more often than it opens it. 11 Chapters 8 Reuse Routes 70% Confidence Bound 4 Argument Killers Included in Expert [Start learning](https://iso26262.academy/register?plan=free&from=%2Fconcepts%2Fproven-in-use&utm_source=website&utm_medium=cta&utm_campaign=features_concepts) See the chapters Inside the course 1. 01 **The Reuse Problem & Landscape** 2. 02 **The Candidate** 3. 03 **Change & Environment** 4. 04 **Field Data** 5. 05 **The Statistics** The short version ## Quick answers What is proven in use in ISO 26262? Proven in use is the argument defined in ISO 26262-8, Clause 14 that lets documented field experience stand in for development rigour when qualifying a reused element. Instead of showing the candidate was developed to the standard, you show it has accumulated enough relevant, unchanged service history with few enough attributed incidents that its demonstrated failure rate meets the target for the ASIL being claimed. The statistics use a Poisson model with a single-sided 70% confidence bound to convert vehicle-hours and incidents into a demonstrated rate. The offer is narrower than it sounds: changes reset the clock, data pipelines leak, and the per-ASIL targets form a numbers wall that closes the argument far more often than it opens it. How many hours of field data do you need for proven in use? With zero attributed incidents, the required exposure is T >= k divided by the target failure rate, where the multiplier k is about 1.2 at the 70% single-sided bound - and k climbs to 7.0 by five incidents. Against ASIL rate targets, and at roughly 400 field hours per vehicle-year, the fleet arithmetic gets brutal fast: item-level ASIL D is close to mythical, and even ASIL B needs hundreds of millions of relevant vehicle-hours. Decomposition and stated margin are the practical workarounds when the raw numbers cannot reach the bar. Keep going, free - [Article · 6 min read Proven in Use Under ISO 26262: What Field History Can Support](https://iso26262.academy/blog/mastering-the-proven-in-use-argument-for-iso-26262-compliance) - [Demo exam · no account Test yourself with 7 exam-style questions](https://iso26262.academy/demo-exam) Why this course · ISO 26262, Part 8, Clause 14 ## Why it pays for itself ### Know when the argument closes The per-ASIL rate targets and fleet arithmetic decide up front whether your field data can ever reach the bar - before you spend months assembling an argument the numbers wall will kill. ### Run the Poisson math yourself Convert vehicle-hours and attributed incidents into a demonstrated failure rate with the single-sided 70% confidence bound, including how each additional incident raises the required evidence. ### Screen all eight reuse routes Clause 14 is one route among eight spanning process, product, and history evidence. A four-question triage tells you which route fits your candidate before you commit to any of them. After the course ## What you’ll be able to do ### Qualify a candidate correctly Draw the candidate boundary and state the function and conditions you are actually allowed to claim credit for. ### Freeze the service-history clock Identify which revisions and updates reset the clock so only genuinely unchanged field hours count. ### Reconstruct field data conservatively Correct exposure and incident counts for a leaky reporting chain without over-claiming credit. ### Run the Poisson 70% bound Convert observed vehicle-hours and incidents into a demonstrated failure rate using the single-sided chi-squared bound. ### Test against per-ASIL targets Compare your bound to the ASIL rate target and decide whether decomposition or stated margin can close the gap. ### Assemble an assessor-proof case Build the work products and safety case that survive the assessor's questions and the four common killers. The curriculum · 10 chapters ## Chapter by chapter 1. 01 **The Reuse Problem & Landscape** Why ISO 26262 accepts field history as safety evidence, why that offer is narrower than it sounds, and the eight reuse routes you should screen before betting on Clause 14. - Two ways to earn the same confidence: development rigour vs field experience - What a proven-in-use argument is not - A four-question triage across process, product and history evidence 2. 02 **The Candidate** Pinning down exactly what you are allowed to argue about: the boundary, the safety-relevant function, and the assumptions that define the candidate for qualification. - Drawing the candidate boundary so the argument stays honest - Function and operating conditions you are claiming credit for - Where an over-broad candidate quietly breaks the case 3. 03 **Change & Environment** Why every hardware revision or software update resets the service-history clock, so only the latest unchanged segment of field time actually counts toward your evidence. - Service history accumulates, then resets on a revision or update - Only the latest frozen configuration segment counts - Environmental and duty-cycle shifts that invalidate carried-over hours 4. 04 **Field Data** Reconstructing exposure and incidents through a leaky pipeline that runs from a field failure through symptom, workshop visit, diagnosis and report before it ever reaches your database. - Leakage at every stage of the reporting chain - Distinguishing exposure hours from attributed incidents - Conservative treatment of unknown and unreported events 5. 05 **The Statistics** How many vehicle-hours buy how much confidence, using the Poisson model and the single-sided 70% bound to convert observed incidents into a demonstrated failure rate. - Zero-incident case and the required hours T >= k / lambda - The evidence price of each additional attributed incident - Multiplier k rising from 1.2 at zero incidents to 7.0 at five 6. 06 **Targets & the Numbers Wall** The per-ASIL rate targets and the fleet arithmetic that decides whether your data can ever reach them, at roughly 400 field hours per vehicle-year. - Incident-rate targets per ASIL at the 70% one-sided bound - Why ASIL D at item level is close to mythical - Decomposition and stated margin as the practical workarounds 7. 07 **A Worked Example** One argument end to end for a hydraulic brake pressure sensor module at hardware revision B, from screening through the conservative chi-squared math to the verdict. - T = 8.7 x 10^8 h, r = 5, chi-squared(0.70, 12) = 14.01 - Testing against the ASIL B target of < 1.0 x 10^-8 / h - Why each quarterly OTA version runs its own separate clock 8. 08 **When It Actually Works** The honest success profile of a winning argument, the four killers that sink most attempts, and the hybrid forms that quietly dominate real practice. - The fingerprint of a candidate that genuinely qualifies - The four killers: change, exposure, ASIL target and data quality - Hybrid forms: confidence backstops and scoped partial credit 9. 09 **Pre-Existing Software & ISO/PAS 8926** Why Clause 14 structurally fails for code, and the 2024 ISO/PAS 8926 route built to replace it, with its five-step evaluation flow. - Three structural mismatches: software never sits still - Systematic faults that hide from even huge fleets - Clause 14 versus ISO/PAS 8926, side by side 10. 10 **Building the Argument** Assembling the work products and safety case, anticipating the assessor's questions, and avoiding the pitfalls that sink otherwise sound arguments. - The fielded candidate is the shipped candidate, doing the same job - Population, exposure and observation chain sound and conservative - The bound beats the ASIL target with stated margin Diagrams & Visuals ## Not just text: the visual toolkit ### Service-History Reset Timeline Shows field time accumulating and then being reset by a hardware revision and a software update, so only the latest configuration segment counts. ### Field-Data Leakage Pipeline Traces a failure from the field through symptom, workshop visit, diagnosis and report to your database, losing evidence at every stage. ### Confidence Multiplier Curve Plots the multiplier k against observed incidents, rising from 1.2 at zero incidents to 7.0 at five, driving the required hours. ### Rate Target vs Fleet-Size Wall A log-log view of observation years needed against fleet size that exposes where ASIL targets become unreachable. ### Reuse Route Decision Map Positions the eight reuse routes across the process, product and history evidence spectrum before you commit to Clause 14. ### ISO/PAS 8926 Evaluation Flow Walks the five-step evaluation flow for pre-existing software against the Clause 14 argument it replaces. Worked Example ## Qualifying a Carryover Brake Pressure Sensor via Field History A hydraulic brake pressure sensor module at hardware revision B is carried over into a new program and put through a full proven-in-use argument against an ASIL B target of < 1.0 x 10^-8 / h. With T = 8.7 x 10^8 relevant vehicle-hours and r = 5 attributed incidents, the conservative chi-squared(0.70, 12) = 14.01 math decides whether the field data actually clears the wall. - Candidate frozen at hardware revision B, boundary and function pinned before any hours are counted - Service history reset on the last revision, leaving 8.7 x 10^8 h of relevant exposure - Five attributed incidents reconstructed through the field-reporting chain - Poisson single-sided 70% bound computed via chi-squared(0.70, 12) = 14.01 - Resulting rate compared against the ASIL B target of < 1.0 x 10^-8 / h - Each quarterly OTA software version runs its own separate clock, not a shared pool Qualification Worksheet: Brake Pressure Sensor Rev B Exposure: T = 8.7 x 10^8 relevant vehicle-hours after the revision-B reset Unlock the full worksheet with the chi-squared bound, margin and pass/fail verdict Built for ## Who this guide is for - Engineers carrying over a sensor, module, or ECU into a new vehicle program - Safety managers weighing field-history qualification against re-development cost - Reliability engineers sitting on warranty and field data they want to use as evidence - Suppliers preparing a proven-in-use case an OEM assessor will interrogate ## Frequently Asked Questions Common questions about Proven in Use Yes. Service history accumulates only for an unchanged configuration, so every hardware revision or software update resets the clock, and only the latest frozen configuration segment counts toward your evidence. Environmental and duty-cycle shifts can invalidate carried-over hours too - field time earned in one operating profile does not automatically transfer to another. In the course's worked example, each quarterly OTA software version runs its own separate clock rather than pooling hours, which is exactly the trap that sinks most software-inclusive arguments. Rarely through Clause 14, for structural reasons: software never sits still (every update resets the history), and systematic faults can hide from even huge fleets because they trigger only under specific conditions the fleet may not have exercised. That is why ISO/PAS 8926, published in 2024, defines a dedicated route for qualifying pre-existing software with a five-step evaluation flow that examines the software and its evidence rather than just counting hours. The course compares Clause 14 and ISO/PAS 8926 side by side so you pick the route that can actually close. Eleven chapters covering the 8 reuse routes, candidate definition, change and environment resets, field-data reconstruction, the Poisson statistics at the 70% bound, the per-ASIL numbers wall, the 4 argument killers, and ISO/PAS 8926 for pre-existing software. The worked example qualifies a carryover brake pressure sensor end to end, from screening through the chi-squared math to the verdict. A free account starts you off, and the Pro and Expert plans unlock more of the library. ## Start the course today A free account unlocks one full concept guide, 3 work product templates, 1 guided process, the Markov simulator, and 5 practice exams per month. The Pro and Expert plans unlock more of the 78-guide library. No credit card required. [Start learning](https://iso26262.academy/register?plan=free&from=%2Fconcepts%2Fproven-in-use&utm_source=website&utm_medium=cta&utm_campaign=features_concepts) [View Pricing Plans](https://iso26262.academy/pricing)