ISO 26262 Part 10 Guidelines & Interpretation Explained

Hello, automotive engineers and functional safety practitioners! Welcome to the tenth deep-dive post in our comprehensive ISO 26262 series at PiEmbSysTech. In this article, we will explore ISO 26262 Part 10 – Guidelines on ISO 26262, the informative companion document that provides additional explanations, illustrative examples, and practical interpretation guidance to help practitioners understand and correctly apply the normative requirements of the other parts.

Part 10 occupies a unique position in the standard – it is the only part (along with Part 11) that is entirely informative rather than normative. This means it contains no requirements that must be followed for compliance. Instead, it provides valuable context, worked examples, and conceptual explanations that help engineers and safety managers bridge the gap between the formal requirements in Parts 1–9 and their practical application in real-world projects. Think of Part 10 as the experienced mentor who explains not just what the standard says, but why it says it and how to apply it effectively.

Table of Contents

1. What is ISO 26262 Part 10 and Its Unique Role

ISO 26262 Part 10: Guidelines on ISO 26262 provides an overview of the entire ISO 26262 series of standards, along with additional explanations, illustrative examples, and practical interpretation guidance. It is designed to enhance the understanding of the general concepts and specific contents of the normative parts (Parts 1–9 and 12).

Part 10 serves as the companion guide to the entire standard. Where the normative parts state what must be done, Part 10 helps practitioners understand why those requirements exist and how to interpret them in practical development scenarios. It expands from general concepts to specific contents, providing context that the terse, formal language of the normative parts often cannot convey.

The standard explicitly states that in the case of any inconsistency between Part 10 and any normative part, the requirements specified in the normative part take precedence. Part 10 guides interpretation but does not override or modify the actual requirements.

2. Normative vs Informative – What This Means in Practice

Understanding the distinction between normative and informative content is essential for correctly using Part 10.

Normative content (Parts 1–9 and 12) contains requirements (expressed using “shall”), recommendations (expressed using “should”), and permissions (expressed using “may”). Compliance with the standard means satisfying the “shall” requirements and providing documented rationale when “should” recommendations are not followed.

Informative content (Parts 10 and 11) contains explanations, examples, and guidance that help practitioners understand and apply the normative content. Informative content does not create additional requirements. An assessor cannot cite a failure to follow Part 10 guidance as a non-conformity – but an assessor may refer to Part 10 to explain their interpretation of a normative requirement.

In practice, Part 10 is extremely valuable for resolving ambiguities in the normative parts. When two practitioners disagree about the meaning of a normative requirement, Part 10 often provides the clarifying context that resolves the dispute. Experienced assessors frequently reference Part 10 when explaining their interpretation of specific requirements.

3. Structure and Contents of Part 10

ISO 26262-10:2018 is organized into several major sections, each providing guidance on a specific aspect of the standard:

Key concepts of ISO 26262: This section explains the fundamental concepts that underpin the entire standard — functional safety for automotive systems, the relationship with IEC 61508, the item hierarchy (item, system, element, component, hardware part, software unit), and the fault-error-failure chain.

FTTI and emergency operation: Detailed explanations of the Fault Tolerant Time Interval (FTTI), the emergency operation tolerant time interval, and the timing relationships between fault detection, fault reaction, and safe state transition.

Safety cases: Guidance on the development and structure of safety cases, including the safety case lifecycle and the relationship between safety arguments and evidence.

Concept phase and system development: Practical guidance on performing HARA, including worked examples of hazard identification, S/E/C classification, and ASIL determination. Guidance on developing functional and technical safety concepts.

Hardware and software development: Clarifications on hardware metric calculations, software development methods, and the application of methods tables at different ASIL levels.

Confirmation measures and assessment: Guidance on interpreting independence levels, performing confirmation reviews, and conducting functional safety assessments.

Tailoring: Guidance on when and how to tailor the safety lifecycle for specific project circumstances, including adaptation for existing systems and component reuse.

Examples: Throughout the document, illustrative examples using recognizable automotive systems (such as airbag systems, braking systems, and steering systems) make abstract concepts concrete and tangible.

4. Key Concepts of ISO 26262 Explained in Part 10

Part 10 begins by setting the context for the entire standard, explaining the overarching philosophy and the key concepts that practitioners must internalize. These include the definition of functional safety as the absence of unreasonable risk due to hazards caused by malfunctioning behaviour of E/E systems – emphasizing that the standard addresses malfunctions, not intended functionality limitations (which are addressed by SOTIF/ISO 21448). The concept of risk-based development – where the development rigor is proportional to the assessed risk (ASIL) – is explained with practical context showing why this approach is both more cost-effective and more safety-effective than applying the same rigor to everything. The safety lifecycle philosophy is explained as a continuous, managed process from concept through decommissioning, not a set of disconnected activities. The concept of defense in depth is illustrated through the multiple layers of safety measures at the concept, system, hardware, and software levels, each contributing to the overall risk reduction.

5. Relationship with IEC 61508 – The Parent Standard

Part 10 provides important context on how ISO 26262 relates to its parent standard, IEC 61508 – the generic functional safety standard for all industries. ISO 26262 is explicitly described as an automotive adaptation of IEC 61508, tailored for the specific risk profile, operational environment, mass-production realities, and regulatory framework of the road vehicle industry.

Key adaptations explained in Part 10 include the replacement of SIL (Safety Integrity Level) with ASIL as the risk classification system, with a qualitative determination method based on Severity, Exposure, and Controllability rather than quantitative probability-based methods. The introduction of the Controllability parameter – unique to automotive – reflecting the human driver’s ability to intervene and avoid an accident, a factor not present in industrial process safety. The use of automotive-specific hardware metrics (SPFM, LFM) instead of the Safe Failure Fraction (SFF) used in IEC 61508. The integration of automotive quality management practices (IATF 16949) as the baseline upon which safety-specific requirements are built. The inclusion of vehicle-level safety validation as a mandatory activity, reflecting the need to verify safety in the actual vehicle operational environment.

6. Item, System, Element, Component – Hierarchy Clarification

One of the most practically valuable sections of Part 10 is the clarification of the item hierarchy – the terms item, system, element, component, hardware part, and software unit. These terms are defined in Part 1, but Part 10 provides additional context and examples that help practitioners correctly apply them.

Part 10 explains the hierarchy with a concrete example: the airbag system is an item (the highest-level object to which the safety lifecycle is applied). The airbag system contains multiple systems – the crash sensor subsystem, the airbag control unit (ACU), and the inflator and airbag module. Each system contains components – the ACU contains a microcontroller (component), accelerometer sensors (components), and power supply circuits (components). Each component contains hardware parts – the microcontroller contains a CPU core, memory arrays, ADC, and I/O ports (hardware parts). The software running on the microcontroller consists of software units — individual functions and modules.

This hierarchy is important because different ISO 26262 requirements apply at different levels. HARA is performed at the item level. System-level requirements are specified in Part 4. Hardware-level requirements are specified in Part 5 at the component and hardware part level. Software requirements are specified in Part 6 at the software unit and integrated software level. Misidentifying the level at which an activity should be performed is a common source of errors.

7. Fault → Error → Failure Chain – Extended Guidance

Part 10 provides extended explanations of the fault-error-failure progression – the causal chain that is central to the entire standard’s approach to safety. The guidance emphasizes the temporal nature of the chain: a fault exists (potentially for a long time) before it manifests as an error, and an error exists (potentially for a short time) before it causes a failure. Safety mechanisms can intervene at different points in this chain – preventing faults (through rigorous development processes), detecting errors (through diagnostic monitoring), tolerating failures (through redundancy and graceful degradation), and transitioning to safe states (through fail-safe mechanisms).

Part 10 also clarifies the relationship between systematic failures and random hardware failures. Systematic failures are deterministic – they are the result of design, specification, or manufacturing process errors and always manifest under the same conditions. They are addressed through process rigor (Parts 2, 6, 7). Random hardware failures are probabilistic – they occur unpredictably due to physical degradation of hardware components. They are addressed through safety mechanisms and quantitative hardware metrics (Part 5). This distinction is fundamental to understanding why ISO 26262 has separate approaches for hardware (quantitative metrics) and software (process rigor) safety.

8. FTTI and Emergency Operation – Timing Concepts Explained

One of the most valuable practical clarifications in Part 10 is the explanation of the Fault Tolerant Time Interval (FTTI) and the related concept of the emergency operation tolerant time interval. These timing concepts are critical for designing safety mechanisms but are often misunderstood by practitioners.

Part 10 explains that the FTTI represents the maximum time from the occurrence of a fault to the potential occurrence of a hazardous event, assuming no safety mechanism intervenes. Within this time budget, the safety mechanism must detect the fault (fault detection time), diagnose the fault and determine the appropriate response (fault reaction time), and complete the transition to a safe state or degraded operating mode (safe state transition time). The sum of these times must be less than the FTTI for the safety goal to be maintained.

Part 10 also introduces the concept of the emergency operation tolerant time interval – the time during which the system can operate in a degraded mode (emergency operation) after a fault is detected but before the safe state is fully achieved. During this interval, the system continues to provide some level of functionality (reduced performance) while warning the driver and preparing for safe state entry. This concept is particularly relevant for systems where an immediate shutdown would itself be hazardous — such as power steering (where sudden loss of assist at highway speed is dangerous) or automatic transmission (where sudden loss of drive could be dangerous in traffic).

Part 10 provides timing diagrams that illustrate these concepts, showing the relationship between fault occurrence, fault detection, fault reaction, emergency operation, and safe state achievement. These diagrams are among the most referenced illustrations in the entire standard and are invaluable for communicating timing requirements between system, hardware, and software development teams.

9. Safety Case Development – Interpretation and Lifecycle

Part 10 provides guidance on the safety case – the compiled body of evidence that demonstrates the item achieves the required level of functional safety. The guidance explains the safety case as a structured argument supported by evidence, where the top-level claim is that the safety goals are achieved with acceptable residual risk. This claim is supported by sub-arguments addressing each aspect of the safety lifecycle, each supported by specific work products as evidence.

Part 10 emphasizes the progressive construction of the safety case – building it incrementally as work products are completed throughout the development lifecycle, rather than assembling it as a last-minute exercise before the release for production. The guidance explains the safety case lifecycle as a continuous process of adding evidence, identifying gaps, and refining arguments as the development progresses.

The guidance also addresses the practical challenge of safety case maintenance – updating the safety case when changes occur during development (change management), when post-SOP modifications are made, and when field monitoring reveals new information. A safety case that is not maintained becomes increasingly disconnected from the actual state of the product and loses its value as evidence of compliance.

10. HARA Guidance – Worked Examples from Part 10

Part 10 provides one of the most practically useful sections for practitioners new to functional safety: worked examples of hazard analysis and risk assessment. Using familiar automotive systems, Part 10 illustrates how to identify hazardous events, how to classify Severity, Exposure, and Controllability, how to determine the ASIL, and how to formulate safety goals.

The airbag system example is particularly illustrative: the hazardous event “airbag deploys inadvertently at high speed” is classified as high severity (S3 – potential for fatal injuries from sudden airbag deployment), high exposure (E4 – high-speed driving is a common situation), and low controllability (C3 – the driver cannot control an airbag that has already deployed). This combination yields ASIL D, leading to the safety goal “the airbag shall only deploy when a crash occurs that requires deployment.”

Part 10 then traces this safety goal through the functional safety concept (specifying a redundant crash detection function using two independent accelerometers) and the technical safety concept (specifying the implementation with dual-channel accelerometer architecture, cross-comparison logic, and an arming/firing decision that requires agreement from both channels). This end-to-end example makes the abstract process concrete and tangible.

11. Functional and Technical Safety Concept – Practical Interpretation

Part 10 provides guidance on the distinction and relationship between the functional safety concept (from Part 3) and the technical safety concept (from Part 4). The functional safety concept describes what must be done to achieve the safety goals, in implementation-independent terms. The technical safety concept describes how it will be done, in concrete technical terms that can be allocated to hardware and software elements.

Part 10 explains this relationship through the airbag example: the functional safety concept states “a redundant function shall detect whether the vehicle is in a collision,” while the technical safety concept specifies “two independent accelerometers with independent signal processing shall each measure vehicle deceleration, and the firing circuit shall only be activated when both channels confirm a collision above the deployment threshold.” This progression from abstract safety function to concrete technical implementation is the essence of the concept-to-design flow in ISO 26262.

12. Hardware Metrics Interpretation – SPFM, LFM, PMHF Guidance

Part 10 provides important interpretive guidance on the hardware architectural metrics defined in Part 5. This includes clarification on how to handle the boundary between safe faults and safety-related faults (a frequent source of disagreement between development teams and assessors), guidance on the interpretation of diagnostic coverage levels (low, medium, high) and the evidence needed to justify each level, explanation of how PMHF targets should be allocated across subsystems and how to handle the dual-point failure contribution, and practical considerations for hardware metric calculations in complex multi-chip architectures.

The guidance helps practitioners understand that the hardware metrics are not just mathematical exercises – they are tools for evaluating the effectiveness of the safety architecture in coping with random hardware failures. A system that narrowly meets the metric targets through optimistic assumptions may be formally compliant but not genuinely safe. Part 10 encourages a holistic engineering perspective that goes beyond checkbox compliance.

13. Software Development Guidance – Practical Clarifications

Part 10 provides clarifications on several aspects of software development under Part 6 that frequently cause confusion. This includes the interpretation of the methods tables (Tables 3 through 9 in Part 6) – specifically, how to handle situations where a “highly recommended” method is not applied and when a documented rationale for not following a recommendation is sufficient. Guidance on model-based development – how to apply Part 6 requirements when software is specified using graphical models (such as Simulink/Stateflow) and code is auto-generated. Guidance on the interaction between software safety analysis and system-level safety analysis – ensuring that software-level analyses do not simply repeat the system-level FMEA but add value by examining software-specific failure modes. Clarification on structural coverage – explaining that achieving the target coverage percentage is the objective, but any code not covered must be analyzed and justified (either as dead code to be removed, or as defensive code that is intentionally not exercised under normal test conditions).

14. Confirmation Measures – Interpretation of Independence Levels

Part 10 provides practical guidance on implementing the confirmation measures defined in Part 2, particularly regarding the interpretation of independence levels (I0, I1, I2, I3). The guidance explains how to determine whether a reviewer has sufficient independence given the organizational structure, how to handle situations where the required independence level is difficult to achieve (for example, in small organizations with limited personnel), the difference between a confirmation review (checking work product compliance with ISO 26262 requirements) and a verification review (checking technical correctness against project requirements), and practical guidance on combining confirmation and verification reviews to reduce duplication while maintaining the required independence.

15. Tailoring and Adaptation – When and How to Deviate

Part 10 provides guidance on tailoring – adapting the safety lifecycle to specific project circumstances. Tailoring is explicitly permitted by the standard when justified and documented, but many practitioners are uncertain about when and how to apply it.

Part 10 clarifies the circumstances under which tailoring is appropriate, such as when reusing a previously developed component (where the existing development evidence may partially satisfy the ISO 26262 requirements, with the gap addressed through additional analysis or testing), when modifying an existing production system (where only the modified portions may require full ISO 26262 treatment), when developing a Safety Element out of Context (SEooC) (where certain lifecycle activities are performed based on assumptions rather than specific item context), and when applying a proven in use argument (where field experience evidence substitutes for some development process evidence). The guidance emphasizes that tailoring must always be justified through a documented rationale that demonstrates the tailored approach provides an equivalent or sufficient level of functional safety. Tailoring is not a shortcut for avoiding work – it is a mechanism for intelligently applying the standard to diverse development scenarios.

16. Key Changes from Part 10:2011 to Part 10:2018

The 2018 edition of Part 10 was significantly expanded from the 2011 edition to reflect lessons learned from nearly seven years of industry implementation and to provide guidance on the new topics introduced in the 2018 edition of the normative parts. Key additions include guidance on the new Part 11 (semiconductors) and Part 12 (motorcycles) content, expanded guidance on hardware metric calculations reflecting the updated metric requirements in Part 5:2018, new guidance on model-based development and its interaction with Part 6, expanded guidance on dependent failure analysis and ASIL decomposition reflecting the updated Part 9:2018, guidance on safety-related special characteristics and their management during production (Part 7), and expanded guidance on software tool qualification reflecting the refined TCL framework in Part 8:2018.

The 2018 edition also improved the structure and organization of Part 10, making it easier to navigate and find guidance on specific topics. The document remains the longest part of the standard by page count, reflecting the volume of explanatory content needed to support the normative requirements across all other parts.

17. How to Effectively Use Part 10 in Your Projects

Part 10 is most valuable when used in the following ways:

As an onboarding resource: For engineers new to ISO 26262, Part 10 provides the best entry point into the standard. Reading Part 10 before diving into the normative parts provides the conceptual foundation that makes the formal requirements more comprehensible.

As an interpretation reference: When the normative requirements are ambiguous or when team members disagree on interpretation, Part 10 often provides the clarifying context that resolves the dispute. Citing Part 10 guidance in technical discussions and review meetings can align the team on a common interpretation.

As a training complement: Part 10’s worked examples (particularly the HARA and safety concept examples) are excellent training materials. They can be used in workshops and training sessions to illustrate abstract concepts with concrete automotive examples.

As assessment preparation: Before a functional safety assessment, reviewing the relevant sections of Part 10 helps the development team understand how assessors are likely to interpret the normative requirements. This proactive alignment can prevent surprises during the assessment and enable more productive discussions with the assessor.

As a gap analysis tool: When establishing ISO 26262 processes within an organization for the first time, Part 10 helps identify areas where the organization’s existing processes may not fully align with the standard’s expectations, even if they superficially meet the formal requirements.

18. Frequently Asked Questions

Q1: Is Part 10 mandatory for ISO 26262 compliance?

No. Part 10 is informative, not normative. Compliance with ISO 26262 requires satisfying the requirements in Parts 1–9 and Part 12 (for motorcycles). Part 10 provides guidance to help achieve compliance but is not itself a source of requirements. However, not reading Part 10 is a missed opportunity – the guidance it provides significantly improves the quality and efficiency of compliance efforts.

Q2: Can an assessor cite Part 10 as the basis for a non-conformity finding?

No. Non-conformities must be based on normative requirements from Parts 1–9 or Part 12. However, an assessor may reference Part 10 to explain their interpretation of a normative requirement. If the assessor’s interpretation differs from the development team’s, Part 10 can serve as common ground for discussion.

Q3: Should I read Part 10 before or after the normative parts?

For practitioners new to ISO 26262, reading Part 10 first (or at least concurrently with the normative parts) is recommended. The conceptual explanations and examples in Part 10 provide the context that makes the formal requirements in the normative parts more understandable. For experienced practitioners, Part 10 is most valuable as a reference when specific interpretation questions arise.

Q4: Is Part 10 the same length as the normative parts?

Part 10 is actually the longest part of the standard by page count, reflecting the extensive explanatory content needed to support the normative requirements across all other parts. It is a substantial document that merits thorough study, not a brief overview that can be skimmed in an afternoon.

Q5: Does Part 10 provide enough guidance to apply ISO 26262 without formal training?

Part 10 is a valuable self-study resource, but it is not a substitute for formal training with experienced instructors. The subtleties of applying ISO 26262 in complex real-world projects – especially the judgment calls involved in HARA, safety architecture design, DFA, and assessment preparation – benefit significantly from hands-on training, practical exercises, and mentoring from experienced functional safety engineers.

Q6: Will the upcoming third edition of ISO 26262 include an updated Part 10?

Yes. The third edition is expected to update Part 10 to provide guidance on the new topics anticipated in the revised normative parts – including guidance on AI/ML in safety-critical functions, OTA updates, software-defined vehicle architectures, and the interaction with cybersecurity standards. The updated Part 10 will continue to serve as the interpretive companion to the normative requirements.

19. Conclusion

ISO 26262 Part 10 – Guidelines on ISO 26262 is the essential companion document that transforms the formal, sometimes terse requirements of the normative parts into practical, understandable guidance. From its explanations of fundamental concepts and timing diagrams to its worked HARA examples and safety case development guidance, Part 10 bridges the gap between what the standard says and how to apply it effectively.

While Part 10 creates no requirements and generates no work products, its value to practitioners is immense. It reduces ambiguity, accelerates learning, improves the quality of safety engineering decisions, and helps align development teams and assessors on a common interpretation of the standard. Every functional safety engineer should have a well-thumbed copy of Part 10 on their desk – or at least a well-bookmarked PDF on their screen.

This article is part of our comprehensive ISO 26262 series at PiEmbSysTech. Next in our series: ISO 26262 Part 11 – Application to Semiconductors and ISO 26262 Part 12 – Adaptation for Motorcycles. Be sure to review our earlier posts on Part 1 through Part 9.

Stay safe. Stay well-informed. Keep engineering the future.

– The PiEmbSysTech Team