[ISO26262] #17. Legacy Safety Mechanisms - To Discard or Reuse?

In the rapidly evolving technological landscape of the automotive industry, embedded systems are becoming increasingly complex. Designing new systems from scratch requires substantial time and resources, particularly in the safety-critical domain. Fortunately, reusing proven legacy safety mechanisms from previous projects can be an attractive strategy to reduce development time, lower costs, and leverage verified reliability.

However, simply transplanting legacy safety mechanisms is insufficient. Meeting stringent modern automotive functional safety standards (ISO 26262) and demonstrating the integrated system’s safety remains a significant challenge. This article explores the theoretical foundations and practical applications of legacy safety mechanism reuse, along with challenges system engineers might face and strategies to overcome them.

Table of Contents

Core Rationale and Methodologies for Legacy Safety Mechanism Reuse

The most compelling justification for reusing legacy safety mechanisms is the ‘Proven in Use’ concept. As defined in ISO 26262, Proven in Use is a methodology demonstrating that a system, hardware, or software component has established reliability and safety through operational history. This approach uses sufficient experience from previous projects or actual operation as evidence that the component meets current safety objectives. By leveraging Proven in Use, engineers can reduce development time and costs by bypassing early verification stages while minimizing safety risks based on historical performance data. However, applying Proven in Use requires sufficient field data and comparable operational environments and ASIL (Automotive Safety Integrity Level) requirements. If data is limited or the environment changes, Proven in Use justification may be invalidated, necessitating supplementation through Gap Analysis and additional testing.

Another critical methodology is Component Qualification. Defined in ISO 26262-8 Clause 12, software component qualification encompasses activities allowing existing software to be repurposed for safety applications. This enables the reuse of COTS (Commercial Off-The-Shelf) or legacy software not originally developed to safety standards in safety-critical systems. Component qualification involves code analysis and additional testing to fill documentation gaps and ensure ASIL compliance when existing documentation is insufficient.

A fundamental methodology for demonstrating the safety of reused legacy mechanisms is Safety Case development. A Safety Case serves as evidence that an item’s safety requirements are complete and satisfied, using development work products as supporting evidence. For legacy safety mechanism reuse, the Safety Case systematically documents “why it is safe,” comprising three core elements: safety requirements, work products (evidence), and safety arguments. Graphical representation methods such as GSN (Goal Structuring Notation) can clearly illustrate the logical connections between safety claims and evidence.

Connecting Legacy Reuse with Modern Safety Standards

Legacy safety mechanism reuse is closely intertwined with several contemporary safety standards:

ISO 26262: This automotive functional safety standard supports legacy reuse through Proven in Use (Part 8), component qualification (Part 8 Clause 12), and ASIL decomposition (Part 9 Clause 5.4.7). Safety analyses should shift focus from comprehensive risk discovery to updating HARA (Hazard Analysis and Risk Assessment) and concentrated FMEA/FTA/DFA application to modified components, validating existing safety mechanisms. Dependent Failure Analysis (DFA/CCFA) is particularly important to check for possible concurrent failures due to shared resources.
ISO 21434: This automotive cybersecurity standard maintains close ties with ISO 26262 and includes guidelines for component reuse and COTS integration. An integrated safety-security approach is essential to analyze how security vulnerabilities in legacy components might impact safety functions in the new system. TARA (Threat Analysis and Risk Assessment) methodology should be employed to evaluate cyber vulnerabilities in legacy components and calculate risk values.
ISO 21448 (SOTIF): This standard addresses the ‘safety of the intended functionality,’ particularly in autonomous driving systems, focusing on preventing hazardous behaviors that could occur even without system defects. SOTIF addresses unpredicted risks from performance limitations or malfunctions, requiring analysis of potential misoperation and design limits of legacy components.

Practical Challenges and Solution Strategies

Legacy safety mechanism reuse is theoretically attractive but presents several practical challenges:

Insufficient documentation: Legacy components often lack essential artifacts like requirements specifications, design documents, and test reports, making ISO 26262 component qualification difficult.
- Solution: Implement gap analysis and component qualification processes. Catalog missing information based on available materials and supplement through static analysis or additional testing. The ATRIUM process can provide a systematic method for integrating legacy system information into safety design documentation.
Limited functional safety requirement traceability: Legacy systems often have poor requirement tracing records, making it difficult to map functional safety requirements to architectural elements.
- Solution: Redefine system architecture and map requirements by creating new ASIL allocations and specifications for the integrated project. Database-driven tools can systematize information sharing between developers and validators.
Safety risks when integrating AI/ML functionality: Integrating machine learning algorithms with legacy systems introduces risks not fully addressed by ISO 26262 or SOTIF.
- Solution: Apply SOTIF to identify and address potential risks such as inadequate environmental perception, lack of robustness, or unexpected behaviors. Reference recent specialized AI safety standards (e.g., ISO/PAS 8800:2024), and validate through data-driven verification (coverage-based testing, safety scenario injection) while ensuring explainability.
Re-verification strategies with limited resources: Limited time, personnel, and test equipment make comprehensive function re-verification challenging.
- Solution: Adopt a risk-based approach, concentrating verification on high-ASIL areas while complementing with automated tool-based techniques (static analysis, model verification). Leverage operational experience data (Operational Confidence) and implement fault injection testing frameworks.
Supplier management issues: When legacy parts are managed by suppliers, responsibility lines can become blurred.
- Solution: Establish clear Development Interface Agreements (DIAs) and conduct supplier safety assessments to clarify roles and evidence responsibilities between OEMs and suppliers. ISO 26262 requires compliance throughout the supply chain, so specify scope in contracts and conduct supplier audits.
Long-term supportability and aging of legacy components: Part obsolescence, discontinued supplier support, or increased failure rates due to component aging can impact system safety over time.
- Solution: Consider operational and maintenance risks by developing long-term support plans.
System-level interactions and emergent properties: Even when individual components are safe, complex integrated systems may exhibit unexpected interactions or emergent properties (timing issues, resource contention) that create new hazards.
- Solution: Conduct holistic system-level reviews, employ model-based safety analysis, or consider hybrid safety architectures (legacy core + new safety monitoring system).
Human factors and usability: User interface or operational procedure changes in legacy-integrated systems may introduce use errors.
- Solution: Evaluate potential use errors arising from user interface (HMI) or procedure changes, considering the possibility of misuse by untrained users.
System behavior in degraded modes and abnormal conditions: Analyze whether the overall system, including legacy safety mechanisms, operates predictably and safely even when some functions fail or performance degrades.
- Solution: Review system responses to extreme environmental conditions or out-of-specification inputs.
Review of past incidents and lessons learned: Examine records of accidents, near misses, or safety issues in similar systems or the legacy system itself to identify potential risks in the current implementation.

Conclusion

Successfully reusing legacy safety mechanisms in automotive electronic systems requires more than technical problem-solving-it demands systematic processes, standards compliance, and an organization-wide safety culture. Proven in Use, component qualification, gap analysis, and Safety Case development are key methodologies for legacy reuse, with integrated consideration of relevant standards such as ISO 26262, ISO 21434, and SOTIF being essential.

To address practical challenges like insufficient documentation, cybersecurity vulnerabilities, and AI/ML integration risks, multifaceted solution strategies including risk-based approaches, automated testing, system-level interaction analysis, and human factors consideration must be applied.

Safety analysis objectives in legacy system integration projects should shift from “discovering new risks” to “thorough verification and documentation of existing safety, with focused analysis on modified components.” This approach rationalizes verification scope and provides compelling evidence of safety goal fulfillment-essential for legacy system integration projects.

If you are interested in other articles about ISO 2626 Series, please refer to the links below!

[ISO 26262] #1. Part4-6 Technical Safety Concept (TSC)

[ISO 26262] #2. Safety Mechanisms for Electrical and Electronic

[ISO 26262] #3. Safety Mechanism for Processing Unit

[ISO 26262] #4. Safety Mechanisms for IO units and Interfaces

[ISO 26262] #5. Safety Mechanisms for Communication Bus

[ISO 26262] #6. Safety Mechanisms for Power Supply

[ISO 26262] #7. Safety Mechanisms for Temporal monitoring and logical programme sequence monitoring

[ISO 26262] #8. Safety Mechanism for Sensors and Actuator

[ISO 26262] #9. AIAG-VDA FMEA

[ISO 26262] #10. Fault Tree Analysis (FTA)

[ISO 26262] #11. DFA, Dependent Failure Analysis