What is it?

This technique enables safe reuse of pre-existing software elements—commercial, open-source, or legacy in-house—without repeating full life-cycle verification. Reuse is justified either by operational evidence that the element behaves correctly under a representative demand profile (proven-in-use) or by assessing existing verification artifacts such as test reports, reviews, and a Safety Manual for compliant items. The justification is specific to the intended application, configuration, and environment. The aim is to leverage prior investment and field experience while retaining confidence that the element will not undermine the safety function.

How it supports functional safety

The measure addresses systematic failures by requiring credible evidence that design-related faults have been controlled in prior use or by verification activities. It also surfaces constraints (e.g., disabled features, required diagnostics, configuration limits) so integration does not introduce new systematic errors. While not a hardware diagnostic per se, extensive field history can reveal manifestations of random/common-cause hardware faults at the software boundary (e.g., timing, memory stress), reducing the chance that the safety function silently acts on corrupted behavior.

When to use

• Reusing an in-house library, RTOS, comms stack, or control block deployed across multiple products and environments.
• Integrating supplier software that comes with a Safety Manual (or equivalent) and maintained verification evidence.
• When project timelines or SIL targets make “build from scratch” impractical but adequate evidence exists for the intended use.
• When only a subset of a complex element (e.g., OS services) is needed and can be strictly bounded/configured.
• During product refreshes or migrations where the element version is unchanged and field history remains applicable.

Inputs & Outputs

Procedure

1. Scope the intended use. Define the safety function(s), SIL target, operational profile (rates, inputs, environment), interfaces, and constraints for the reused element.
2. Identify and baseline the element. Capture exact version, build options, dependencies, platform, and any dormant/optional features.
3. Collect evidence. a) Proven-in-use: field hours/demands, failure records, application diversity, stability of specification; b) Verification evidence: development/verification records, test coverage, defect history, Safety Manual.
4. Match evidence to context. Confirm the demand profile, environment, and usage mode in the new system are within the demonstrated/verified envelope; document any deltas.
5. Bound the element. Disable or isolate unused functions; fix configurations; add wrappers, monitors, or plausibility checks to prevent undefined behavior propagating into the safety function.
6. Close gaps. Where evidence is incomplete, perform targeted tests, static/dynamic analysis, or reviews focused on safety-relevant behavior and identified failure mechanisms.
7. Produce/validate the Safety Manual. Ensure assumptions of use, constraints, required diagnostics, failure modes, and integration requirements are explicit and auditable.
8. Integrate with change control. Freeze the qualified baseline; define patch/update assessment criteria and re-qualification triggers.
9. Argue in the safety case. Present the justification, limits of use, and results of gap-closing activities; obtain independent assessment as required.

Worked Example

High-level

Coder reusing an old library: An engineering team maintains a legacy numerical library used for control calculations in ten product families over 15 years. The library’s specification and API have remained stable across versions. Operations logs show millions of service hours in multiple industries with no safety-related failures attributed to the library. For a new SIL-rated controller, the team compiles a proven-in-use dossier: precise version and configuration mapping, exposure data (hours and demand counts), failure collection methods, and application diversity. They check that the new demand profile (calculation rate, input ranges, timing) and environment match the historical envelope. Unused functions (e.g., advanced math modes) are disabled; a wrapper enforces argument ranges and monitors timing. Supplier/maintainer records and internal test reports are reviewed to confirm edge-case handling. Gaps (e.g., behavior under power-up transients) are addressed with targeted stress tests. A concise Safety Manual for the library is produced, documenting assumptions, limits of use, and required configuration. The library is baselined under change control with a defined patch assessment process.

Result: The project reuses a well-understood element with bounded behavior, reducing re-verification effort while maintaining confidence that systematic faults are controlled for the specific safety function and operating conditions.

Quality criteria

• Traceable identification: Exact element version/configuration and dependency chain are recorded and frozen.
• Evidence relevance: Operational history or verification results demonstrably match the intended demand profile, environment, and interfaces.
• Limits of use defined: Safety Manual (or equivalent) states capabilities, assumptions, disabled features, diagnostics, and integration requirements.
• Gap closure: Any differences from historical/verified conditions are addressed by targeted analysis/tests with recorded outcomes.
• Change control: Clear criteria for when updates require re-qualification; patch assessments are auditable.

Common pitfalls

• “Popular = safe” fallacy. Mitigation: accept only evidence tied to the intended use; demonstrate comparable demand/environment.
• Hidden or dormant features causing side effects. Mitigation: disable/lock down unused functionality; sandbox or wrap interfaces.
• Specification drift across versions. Mitigation: freeze qualified versions; re-justify any change via impact analysis and targeted re-tests.
• Incomplete failure collection in the field. Mitigation: require documented detection/registration processes; supplement with focused testing.
• Over-claiming SIL based on generic history. Mitigation: scale claims to evidence strength; narrow the operating envelope; add defensive measures.

Related techniques

• Proven-in-use argumentation — One route to justify reuse based on operational exposure and observed reliability.
• Safety Manual (compliant items) — Defines capabilities, assumptions, and limits of use for reusable elements.

References

• IEC 61508-3: Functional safety of E/E/PE safety-related systems — Part 3: Software requirements
• Bishop, Clement, Guerra (2003). Software criticality analysis of COTS/SOUP. Reliability Engineering & System Safety
• Lau (2004). Component-Based Software Development: Case Studies. World Scientific

FAQ