Reuse and Legacy Software Safety
Learn the argument routes ISO 26262 offers for carryover, modified, and pre-existing software - and how to pick the one whose evidence you can actually produce.
- Chapters
- 12
- Chapters
- Reuse scenarios routed
- 6
- Reuse scenarios routed
- Delta analysis steps
- 6
- Delta analysis steps
- Decision guide
- 1
- Decision guide
Quick answers
- What does ISO 26262 say about reusing legacy software?
- ISO 26262 does not forbid reuse - it demands an explicit argument for it. Part 8 offers dedicated routes: Clause 12 covers qualification of software components, Clause 14 covers proven-in-use arguments built on field data, and ISO/PAS 8926 extends these for pre-existing software developed outside ISO 26262. For modified elements, change management and impact analysis decide which existing evidence remains valid. The core principle is that safety is a property of an element in its context, not of the element alone: unchanged code in a new context still needs a new argument, even when no line of source was touched.
- What is the difference between carryover, modified reuse, and legacy software?
- Two questions classify every case: did the element change, and did its context change. Carryover is an unchanged element in an essentially unchanged context - old evidence can carry if the new use stays inside the envelope it covers. Modified reuse means the element or its context changed, which triggers delta and impact analysis to determine what must be re-verified. Legacy software is code with thin or missing safety evidence, typically developed before or outside ISO 26262 - here the question is not what changed but whether the evidence state can be brought to an arguable level at all.
Why it pays for itself
Stop arguing reuse by hope
The six-scenario route map replaces wishful stacking of half-arguments with one deliberate choice: evidence reuse, delta analysis, proven in use, or ISO/PAS 8926 - each with its real evidence bill.
A delta analysis that holds up
The six-step method separates observed changes from impact judgments and checks completeness where most delta analyses silently fail, producing a contract the rest of the program can build on.
Know when to stop reusing
The sunk evidence fallacy and the failure smells give you decidable exit criteria, so a doomed reuse argument is abandoned early instead of collapsing in the functional safety assessment.
What you’ll be able to do
Classify Any Reuse Case
Use the element-change and context-change questions to place carryover, modified, pre-existing, and legacy software into the right category before arguing anything.
Pick a Defensible Argument Route
Choose between evidence reuse, delta analysis plus development, proven in use, and ISO/PAS 8926 qualification based on the evidence you can actually produce.
Run a Complete Delta Analysis
Execute all six steps from baseline identification to the program contract, separating observed deltas from impact judgments.
Contain What You Cannot Qualify
Design wrapper and containment architectures with a clear-eyed view of what they catch, what they miss, and what evidence they still require.
Write Reuse Contracts That Hold
Turn assumptions of use into scoped, verifiable contracts across supplier boundaries instead of implicit expectations that fail in integration.
Reuse Evidence Without Fooling Yourself
Apply the evidence-transfers-arguments-rebuild rule and avoid the sunk evidence fallacy when old test results look tempting.
Chapter by chapter
- 01
The Carryover Reality
Why most automotive software is reused rather than newly developed, and why safety is not a property of an element in isolation but of an element in context.
- Carryover economics
- Context dependence
- Reading map
- 02
Vocabulary and Reuse Types
Sort the terminology - carryover, modified reuse, pre-existing, legacy - and learn the two questions that classify every case: did the element change, and did its context change.
- Reuse taxonomy
- Element vs context
- Origin matters
- 03
Choosing the Argument Route
Map six starting scenarios to their argument routes: direct evidence reuse, gap analysis, impact analysis plus development, proven in use per Clause 14, or ISO/PAS 8926 qualification.
- Six scenarios
- Route selection
- No wishful stacking
- 04
Delta Analysis in Depth
A six-step delta analysis that separates observation from judgment, checks completeness where most analyses already fail, and ends in a contract with the rest of the program.
- Six steps
- Observation vs judgment
- Completeness
- 05
Carryover of Unchanged Elements
When an element and its context are truly unchanged, old evidence can carry - if you prove the new use stays inside the envelope the old evidence covers.
- Evidence envelope
- Unchanged proof
- Boring defense
- 06
The Legacy Software Problem
Legacy code with thin or missing evidence: assess the real evidence state, compare the cost profiles of each option, and see where each choice bites later.
- Evidence gaps
- Option cost profiles
- Main risks
- 07
Qualifying Pre-Existing Software
Qualification of pre-existing software architectural elements: the ISO 26262-8 Clause 12 baseline, the ISO/PAS 8926 route, and building executable evidence that respects what already exists.
- Clause 12
- ISO/PAS 8926
- Executable evidence
- 08
Wrappers and Containment
Containment architectures around software you cannot fully trust: what a wrapper catches, what it structurally misses, and when detection and reaction outside the element suffice.
- Catches vs misses
- Containment patterns
- External mechanisms
- 09
Assumptions and Reuse Contracts
Assumptions of use and conditions of use as the reuse contract: how to scope them, the supplier boundary, and the asymmetry between weak and strong contracts.
- Assumptions of use
- Supplier boundary
- Scoped contracts
- 10
Evidence Reuse Rules
The rules for carrying verification evidence forward: evidence can transfer but arguments must be rebuilt, plus the classic traps in cross-standard evidence reuse.
- Evidence vs argument
- Cross-standard reuse
- Classic traps
- 11
Building the Reuse Argument
Assemble the pieces into a modular per-element argument with explicit reasoning and residual risks stated openly instead of buried in appendices.
- Modular arguments
- Explicit residuals
- Assembly order
- 12
Pitfalls and Decision Guide
The failure smells of reuse programs - including the sunk evidence fallacy - and a decision guide that makes the exit from a doomed reuse argument decidable.
- Sunk evidence fallacy
- Failure smells
- Decidable exits
Who this guide is for
- Software leads inheriting a legacy codebase that must enter an ASIL project
- Safety engineers writing delta and impact analyses for carryover elements
- Suppliers qualifying pre-existing software components for multiple customers
- Anyone deciding between proven in use, ISO/PAS 8926, and redevelopment
Frequently Asked Questions
Common questions about Reuse and Legacy Software Safety
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.