Reuse and Legacy Software Safety

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.

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.

Proven in use per ISO 26262-8 Clause 14 needs field data that survives statistical scrutiny for the same element in a sufficiently similar context - a bar that real programs rarely clear, especially at higher ASILs. ISO/PAS 8926 is the route designed for pre-existing software architectural elements: it accepts that the code was not developed under ISO 26262 and builds a qualification argument from analysis, targeted verification, and executable evidence instead of pure field statistics. In practice the two are often combined, with field experience supporting but not carrying the argument.

Only partially, and only when the containment claim is honest. A wrapper or containment architecture can detect and react to dangerous failures at the element boundary - but it catches only the failure modes that are observable there, and it structurally misses failures that corrupt shared resources or produce plausible-but-wrong outputs. The course treats wrappers as one tool in a route, not a route by themselves: you still owe an argument for what the wrapper misses, and assumptions of use still have to bound what the legacy element is allowed to do.

The course has 12 chapters: the carryover reality, reuse vocabulary, choosing among argument routes for six starting scenarios, a six-step delta analysis, carryover of unchanged elements, the legacy software problem, qualifying pre-existing software with Clause 12 and ISO/PAS 8926, wrappers and containment, assumptions of use as reuse contracts, evidence reuse rules, building the modular reuse argument, and a pitfalls chapter with a decision guide.