ISO 26262-8:2018 — Functional Safety — Supporting Processes

1. Introduction to ISO 26262-8 Supporting Processes

ISO 26262-8:2018 is a critical component of the ISO 26262 functional safety standard series for road vehicles, addressing the supporting processes that underpin the entire safety lifecycle. While other parts of ISO 26262 focus on specific development phases (concept, system, hardware, software), Part 8 provides the cross-cutting process infrastructure necessary to achieve and demonstrate functional safety compliance.

The standard covers eight major process domains: interfaces within distributed developments, specification and management of safety requirements, configuration management, change management, verification, documentation management, confidence in the use of software tools, and qualification of software/hardware components plus proven-in-use arguments. Each domain includes clearly defined objectives, prerequisites, requirements, and work products.

2. Key Process Domains in Detail

2.1 Distributed Development (Clause 5)

Modern automotive systems involve complex supply chains where multiple organizations contribute to a single safety-related item. Clause 5 establishes requirements for customer-supplier interfaces, including supplier selection criteria based on functional safety capability, Development Interface Agreements (DIAs) that define responsibility allocation, and structured communication channels for safety-related information. The DIA is the central document and must cover safety requirements, assumed preconditions, work product exchange, change management processes, and confirmation measures.

2.2 Specification and Management of Safety Requirements (Clause 6)

Safety requirements flow down from safety goals through functional safety requirements to technical, hardware, and software safety requirements. Clause 6 mandates that each requirement is uniquely identified, has a defined ASIL attribute, is traceable to its source, and is verifiable. Requirements attributes include: ASIL, status, source, verification criteria, and allocated element. Bidirectional traceability is required — from safety goals down to implementation and from verification results back up to requirements.

2.3 Change Management (Clause 8) and Verification (Clause 9)

Change management follows a structured five-step process: planning and initiation, change request submission, impact analysis, evaluation and decision, implementation and documentation. The impact analysis must consider effects on functional safety, including re-assessment of hazards, re-verification needs, and side effects on other elements.

Verification planning requires specification of verification methods (e.g., review, analysis, testing), verification levels, coverage criteria, and environmental conditions. The verification specification defines what is to be verified, against which criteria, using which method, and with what degree of independence (which scales with ASIL).

3. Software Tool Confidence and Component Qualification

3.1 Confidence in Software Tools (Clause 11)

Software tools used in developing safety-related systems can introduce errors. Clause 11 introduces a tool confidence level (TCL) classification based on two criteria: (1) the tool’s potential to introduce errors in a safety-related item (tool impact — TI), and (2) the probability that such errors would be detected before deployment (tool error detection — TD). TCL1 requires the least qualification effort; TCL3 requires the most. Tools are classified using a systematic approach: if TI = 1 and TD = 1 → TCL1; if TI = 1 and TD = 2 → TCL2; if TI = 2 and TD = 1 or 2 → TCL3. TCL2 requires a qualification report demonstrating tool suitability per its intended use; TCL3 requires additional measures such as increased confidence via rigorous testing, formal methods, or independent verification.

3.2 Qualification of Software and Hardware Components (Clauses 12-13)

When reusing pre-existing software or hardware components — whether developed internally or sourced from third parties — the standard requires qualification evidence that the component is suitable for its safety application. Qualification methods include: increased confidence from extended operational experience (proven-in-use), assessment of the component’s development process, hardware assessment, or safety requirement compliance verification.

3.3 Proven-in-use Argument (Clause 14)

For components with significant field history, Clause 14 provides a structured approach to building a proven-in-use (PIU) argument. The analysis must demonstrate sufficient field exposure time, configuration stability, and absence of safety-relevant failures. For hardware, specific metrics include field return rates, failure modes, and operating hours. The PIU argument is ASIL-dependent — higher ASIL levels require more extensive field data and stronger confidence in the observation methodology.

4. Engineering Design Insights for ISO 26262-8 Implementation

• DIA completeness: The Development Interface Agreement should explicitly address safety requirements allocation, work product exchange formats, confirmation measure responsibilities, and escalation paths for safety anomalies. A template-based approach with ASIL-tailored content ensures consistency across the supply chain.
• Requirements tooling: Invest in a requirements management tool that supports attribute definition, traceability matrices, impact analysis, and baseline management. Excel-based approaches become unmanageable beyond small-scale projects.
• Verification independence: The degree of verification independence required increases with ASIL — for ASIL D, different persons are required for specification, implementation, and verification (with separate reporting lines recommended).
• Tool qualification automation: Develop a tool classification matrix for the organization’s tool inventory. Automate TCL determination and generate qualification reports systematically to avoid bottleneck delays during assessment.
• Proven-in-use data collection: Establish field monitoring processes early. PIU arguments require substantial operational data — collecting this retrospectively is often impossible or prohibitively expensive.

5. Frequently Asked Questions