ISO 26262-8:2018 道路车辆功能安全 — 支持过程

一、ISO 26262-8 支持过程概述

ISO 26262-8:2018 是道路车辆功能安全标准系列的关键组成部分，涵盖了支撑整个安全生命周期的支持过程。虽然 ISO 26262 的其他部分侧重于特定开发阶段（概念、系统、硬件、软件），但第 8 部分提供了实现和证明功能安全合规性所必需的跨领域过程基础设施。

该标准涵盖了八个主要过程领域：分布式开发接口、安全需求的规范和管理、配置管理、变更管理、验证、文档管理、软件工具使用置信度，以及软硬件组件资质认定（包括成熟在用论证）。每个领域都包含明确定义的目标、先决条件、要求和工作成果。

二、关键过程领域详解

2.1 分布式开发（第 5 条）

现代汽车系统涉及复杂的供应链，多个组织为同一个安全相关项目做出贡献。第 5 条建立了客户-供应商接口的要求，包括基于功能安全能力的供应商选择标准、定义责任分配的开发接口协议（DIA），以及安全相关信息的结构化沟通渠道。DIA 是核心文件，必须涵盖安全需求、预设前提条件、工作成果交换、变更管理过程和确认措施。

2.2 安全需求的规范和管理（第 6 条）

安全需求从安全目标向下流动，通过功能安全需求到技术、硬件和软件安全需求。第 6 条要求每个需求具有唯一标识、已定义的 ASIL 属性、可追溯到其来源，并且是可验证的。需求属性包括：ASIL、状态、来源、验证标准和分配的元素。要求双向可追溯性——从安全目标向下到实现，以及从验证结果向上到需求。

2.3 变更管理（第 8 条）与验证（第 9 条）

变更管理遵循结构化的五步流程：计划和启动、变更请求提交、影响分析、评估和决策、实施和记录。影响分析必须考虑对功能安全的影响，包括危害的重新评估、重新验证需求以及对其他元素的副作用。

验证计划要求明确验证方法（如评审、分析、测试）、验证级别、覆盖准则和环境条件。验证规范定义了要验证的内容、验证标准、使用的方法以及独立程度（随 ASIL 升高而增加）。

三、软件工具置信度与组件认定

3.1 软件工具置信度（第 11 条）

用于开发安全相关系统的软件工具可能会引入错误。第 11 条引入了基于两个标准的工具置信度（TCL）分类：(1) 工具在安全相关项目中引入错误的可能性（工具影响 — TI），(2) 这些错误在部署前被检测到的概率（工具错误检测 — TD）。TCL1 需要的认定工作最少；TCL3 需要最多。工具分类采用系统化方法：TI = 1 且 TD = 1 → TCL1；TI = 1 且 TD = 2 → TCL2；TI = 2 且 TD = 1 或 2 → TCL3。

3.2 软硬件组件认定（第 12-13 条）

在重用预存的软件或硬件组件时（无论是内部开发还是从第三方采购），标准要求提供组件适用于其安全应用的认定证据。认定方法包括：通过广泛运行经验提高置信度（成熟在用）、评估组件的开发过程、硬件评估，或安全需求合规性验证。

3.3 成熟在用论证（第 14 条）

对于有显著现场使用历史的组件，第 14 条提供了构建成熟在用（PIU）论证的结构化方法。分析必须证明足够的现场暴露时间、配置稳定性以及没有安全相关故障。对于硬件，具体指标包括现场退货率、故障模式和工作小时数。PIU 论证依赖于 ASIL——更高的 ASIL 等级需要更广泛的现场数据和更强的观测方法置信度。

四、ISO 26262-8 实施的工程设计要点

• DIA 完整性：开发接口协议应明确解决安全需求分配、工作成果交换格式、确认措施责任以及安全异常升级路径。采用基于模板且按 ASIL 定制内容的方法可确保供应链的一致性。
• 需求工具化：投资支持属性定义、可追溯性矩阵、影响分析和基线管理的需求管理工具。基于 Excel 的方法在中小型项目以上规模即变得不可管理。
• 验证独立性：所需的验证独立程度随 ASIL 增加——对于 ASIL D，规范、实现和验证需要由不同人员执行（建议有独立的汇报线）。
• 工具认定自动化：为组织的工具清单建立工具分类矩阵。系统化地自动确定 TCL 并生成认定报告，以避免在评估过程中出现瓶颈延迟。
• 成熟在用数据收集：尽早建立现场监控流程。PIU 论证需要大量的运行数据——事后追溯收集通常是不可能的，或者成本过高。

五、常见问题