ISO 26262-10:2018 Road Vehicles — Functional Safety — Part 10: Guidelines on ISO 26262

Comprehensive Guidelines for Automotive Functional Safety Implementation — HARA Examples, Fault Classification, Safety Case Guidance

1. Understanding ISO 26262-10:2018 — The Comprehensive Guideline

ISO 26262-10:2018 serves as the informative guideline for the entire ISO 26262 series, providing explanations, examples, and interpretations of key concepts that are essential for effective implementation of automotive functional safety. Unlike the normative parts of the standard, Part 10 does not contain requirements but rather illuminates the rationale and practical application of the concepts defined elsewhere in the series.

The 2018 second edition substantially expanded the guidance content compared to the 2011 version. Key additions include: detailed examples of hazard analysis and risk assessment (HARA) for different vehicle types, comprehensive fault classification flow diagrams for hardware evaluation, guidance on safety case development, and explanations of the relationship between fault-tolerant time intervals and emergency operation tolerance. The standard also provides crucial interpretation of the safety process requirement structure, helping engineers understand how requirements flow from safety goals through functional safety concepts to technical safety requirements.

Part 10 should be read alongside the normative parts, not as a standalone document. Use it to understand the “why” behind the requirements — this context is invaluable when tailoring the standard for your specific application and when preparing for functional safety assessments.
Topic Area Guidance Provided Relevant Normative Part
Key Concepts (Clause 4) Item vs. system vs. element, fault/error/failure progression, FTTI timing model ISO 26262-1, ISO 26262-4
Safety Management (Clause 5) Confirmation measures, safety case lifecycle, functional safety assessment example ISO 26262-2
Concept Phase (Clause 6) HARA examples, controllability observations, external measures, combining safety goals ISO 26262-3
Hardware Development (Clause 8) Fault classification flow, residual failure rate evaluation, single-point fault metric ISO 26262-5
Software Development (Clause 9) Software safety analysis methods, model-based development guidance ISO 26262-6
ASIL Tailoring (Clause 10) ASIL decomposition examples, criteria for coexistence of elements ISO 26262-9

2. Key Conceptual Clarifications

One of the most valuable contributions of Part 10 is its clarification of the relationship between faults, errors, and failures (Clause 4.3). The standard explains that a fault is a defect that can cause an error (a deviation from correctness), and an error can lead to a failure (inability to perform a required function). This progression is fundamental to understanding how safety mechanisms should be designed: by detecting faults before they cause errors, detecting errors before they cause failures, or mitigating failures before they cause hazardous events.

The timing model (Clause 4.4) provides practical guidance for relating fault-tolerant time interval (FTTI) to other timing constraints. Part 10 presents an example control system timing model showing how FTTI relates to fault detection time, fault reaction time, and the emergency operating interval. This guidance is critical for engineers defining timing requirements for safety mechanisms, as it clarifies the relationship between the time a fault occurs and the time by which the system must reach a safe state.

A common misinterpretation addressed in Part 10: FTTI is not the same as the fault detection time. FTTI encompasses the entire period from fault occurrence to the point where a hazardous event could occur. The safety mechanism must detect, react, and reach a safe state within this window. Engineers often mistakenly allocate the entire FTTI to detection alone, leaving insufficient time for reaction.

The hardware fault classification flow diagram (Clause 8.1.8) is another major contribution. It provides a step-by-step decision tree for classifying faults as safe, single-point, residual, detected dual-point, perceived dual-point, or latent dual-point faults. Each classification directly impacts the calculation of the single-point fault metric (SPFM) and latent fault metric (LFM). Understanding this flow is essential for hardware engineers performing quantitative safety analysis.

3. Practical Engineering Insights for Assessment Readiness

Part 10 provides extensive guidance on preparing for functional safety assessments (Clause 5.2.2). It describes the typical agenda for an ASIL D assessment (see informative Annex D of ISO 26262-2) and explains how evidence should be structured. The assessment covers: safety culture and management processes, safety lifecycle and work products, technical safety concepts, hardware and software development evidence, and the completeness of the safety case.

Practical recommendation: Use the examples in Part 10 as templates for your own work products. The HARA examples, timing diagrams, and fault classification flows provide proven approaches that assessors will recognize and accept. Adapting rather than reinventing reduces assessment risk.

The guidance on safety cases (Clause 5.3) explains the goal structuring notation (GSN) approach and emphasizes that a safety case is an argument supported by evidence, not merely a collection of documents. Part 10 recommends developing the safety case incrementally throughout the development lifecycle, with each phase generating the necessary argument elements and supporting evidence. This approach ensures that the final safety case is comprehensive and coherent, rather than a last-minute compilation.

Avoid the common pitfall of treating the safety case as a documentation exercise. Part 10 emphasizes that the safety case must be a structured argument that demonstrates how each safety goal is satisfied. If the argument cannot be clearly articulated without documents, the safety case is unlikely to withstand rigorous assessment scrutiny.

External measures (Clause 6.4) are another area where Part 10 provides valuable clarification. The standard explains how measures that are not part of the item (e.g., driver warnings, vehicle-level braking systems) can be credited in the safety argument. However, the conditions for using external measures are strict: they must be identifiable, reliable, and their effectiveness must be validated in the context of the specific vehicle.

Frequently Asked Questions

Q1: Is compliance with ISO 26262-10 mandatory?
No. ISO 26262-10 is an informative (guideline) part of the standard. It does not contain normative requirements. However, its interpretations and examples represent the consensus understanding of the ISO technical committee, so following its guidance significantly increases the likelihood of a successful functional safety assessment.
Q2: How should the fault classification flow diagram be used in practice?
The flow diagram in Clause 8.1.8 provides a systematic method for classifying each hardware fault. Engineers should apply it to every fault identified in the hardware failure mode analysis. The classification determines whether the fault contributes to the SPFM, LFM, or PMHF calculations. Automated tools can implement this flow, but manual application for critical faults is recommended for thoroughness.
Q3: What is the most common mistake made when applying ISO 26262-10 guidance?
The most common mistake is treating the examples as complete solutions rather than illustrations. For instance, the HARA examples in Clause 6 are simplified for clarity and do not cover all possible hazards for the example functions. Engineers must perform a complete HARA for their specific item, using the examples as methodological guidance only.
Q4: How does Part 10 address the relationship between functional safety and cybersecurity?
Part 10 recognizes the convergence of safety and security and explains that cybersecurity vulnerabilities can lead to safety violations. The guidance recommends coordinated safety and security engineering processes, shared hazard/threat analysis, and consideration of security mechanisms as potential safety mechanisms or as potential sources of safety violations if they fail.

Leave a Reply

Your email address will not be published. Required fields are marked *