ISO 26262-8 支持过程：功能安全的基石

引言

在功能安全的实施过程中，除了核心的开发活动，还需要一系列的支持活动来确保整个过程的规范性、可追溯性和一致性。这些支持活动就像是建筑工程中的脚手架和基础设施，虽然不是主体结构，但却是保证建筑安全和顺利施工的关键。

想象一个真实场景：某汽车厂商的制动系统在开发过程中，由于缺乏有效的配置管理，导致不同版本的硬件和软件被错误地集成在一起，最终产品在市场上出现故障，造成重大经济损失。

这个案例告诉我们：**完善的配置管理、文档管理和工具管理是确保功能安全的重要基础。**这正是 ISO 26262-8 支持过程部分的核心使命。

支持过程的目标和范围

支持过程的核心活动

ISO 26262-8 定义了六个核心支持过程：

1. 配置管理

   • 配置识别
   • 配置控制
   • 配置状态记录
   • 配置审计

2. 文档管理

   • 文档规划
   • 文档编制
   • 文档控制
   • 文档归档

3. 工具置信度评估

   • 工具分类
   • 工具置信度评估
   • 工具使用流程

4. 接口协议

   • 接口识别
   • 接口定义
   • 接口验证

5. 需求管理

   • 需求识别
   • 需求分析
   • 需求追溯

6. 工作产品管理

   • 工作产品识别
   • 工作产品控制
   • 工作产品验证

配置管理

配置管理的定义

配置管理（Configuration Management，CM） 是识别和控制系统工作产品及其变更的系统方法。

配置管理的核心活动

1. 配置识别

配置识别是确定需要纳入配置管理的所有工作产品。

配置项（CI）的分类：

1. 文档类

   • 需求文档
   • 设计文档
   • 测试文档
   • 安全档案

2. 代码类

   • 源代码
   • 目标代码
   • 库文件

3. 硬件类

   • 硬件设计文档
   • PCB 文件
   • BOM 表

4. 数据类

   • 配置参数
   • 标定数据
   • 测试数据

配置项标识：

每个配置项必须有唯一的标识符。

标识格式：

[项目代码]-[文档类型]-[版本号]-[修订号]

示例：

• EPB-SRS-1.0.0：EPB 项目的软件需求规格说明书，版本 1.0，修订 0
• EPB-SRC-1.2.3：EPB 项目的源代码，版本 1.2，修订 3
• EPB-HDL-2.0.1：EPB 项目的硬件设计文档，版本 2.0，修订 1

2. 配置控制

配置控制是管理配置项的变更。

变更管理流程：

1. 变更请求（CR）

   • 提交变更请求
   • 变更影响评估
   • 变更审批

2. 变更实施

   • 执行变更
   • 更新相关文档
   • 更新配置项版本

3. 变更验证

   • 验证变更是否正确
   • 验证变更是否满足需求
   • 更新测试用例

变更请求示例：

3. 配置状态记录

配置状态记录是记录配置项的当前状态和变更历史。

配置状态报告：

4. 配置审计

配置审计是验证配置项是否与文档一致，变更是否正确实施。

配置审计类型：

1. 功能配置审计（FCA）：验证功能是否实现
2. 物理配置审计（PCA）：验证配置项是否与文档一致

配置审计检查清单：

• 所有配置项是否已识别？
• 所有配置项是否已版本控制？
• 所有变更是否已记录？
• 配置项是否与文档一致？
• 测试是否覆盖所有变更？

案例：制动系统的配置管理

配置项列表：

变更记录：

文档管理

文档管理的定义

文档管理（Documentation Management） 是规划、编制、控制和归档所有文档的过程。

文档管理的核心活动

1. 文档规划

文档规划是确定需要编制的文档、文档的格式、文档的评审要求。

文档清单：

2. 文档编制

文档编制是按照规范和格式编写文档。

文档格式规范：

1. 封面：包含文档标题、版本号、日期、作者等信息
2. 修订历史：记录文档的变更历史
3. 目录：文档的章节目录
4. 正文：文档的主要内容
5. 附录：补充材料

文档内容要求：

• 清晰准确
• 完整一致
• 可追溯
• 可维护

3. 文档控制

文档控制是管理文档的发布、分发和变更。

文档控制流程：

1. 文档创建：作者创建文档草稿
2. 文档评审：评审人员评审文档
3. 文档批准：批准人员批准文档
4. 文档发布：发布文档到受控环境
5. 文档分发：分发给相关人员
6. 文档归档：归档到文档管理系统

4. 文档归档

文档归档是长期保存文档，便于追溯和审计。

归档要求：

• 文档完整性：所有相关文档必须归档
• 归档时间：项目完成后立即归档
• 归档期限：至少 15 年
• 归档位置：安全、可控的环境

工具置信度评估

工具的分类

ISO 26262-8 将工具分为四个类别（TCL 1-4）：

TCL 1：不推荐用于功能安全相关活动

定义：这些工具不适合用于功能安全相关活动。

示例：

• 普通文本编辑器（如 Notepad）
• 未验证的编译器

TCL 2：可用于功能安全相关活动，不需要置信度评估

定义：这些工具可以用于功能安全相关活动，但不会影响安全相关的工作产品。

示例：

• 源代码管理工具（如 Git、SVN）
• 需求管理工具（如 DOORS）
• 项目管理工具（如 Microsoft Project）

TCL 3：可用于功能安全相关活动，需要置信度评估

定义：这些工具可以用于功能安全相关活动，但可能会影响安全相关的工作产品，需要进行置信度评估。

示例：

• 编译器（如 GCC、MSVC）
• 链接器（如 GNU ld）
• 调试器（如 GDB）

TCL 4：可用于功能安全相关活动，需要置信度评估

定义：这些工具可以用于功能安全相关活动，可能会直接生成或修改安全相关的工作产品，需要进行置信度评估。

示例：

• 静态分析工具（如 Coverity、Klocwork）
• 测试工具（如 Vector Test）
• 代码生成器（如 Simulink Coder）

工具置信度评估的方法

评估维度

工具置信度评估从以下三个维度进行：

1. 工具置信度检测能力（TCD）：

   • TCD 1：工具置信度低
   • TCD 2：工具置信度中
   • TCD 3：工具置信度高

2. 工具置信度防止错误的能力（TPL）：

   • TPL 1：防止错误的能力低
   • TPL 2：防止错误的能力中
   • TPL 3：防止错误的能力高

3. 工具置信度检测能力 + 防止错误的能力（TCL）：

工具置信度评估流程

1. 工具识别：识别需要评估的工具
2. 工具分类：确定工具的类别（TCL 1-4）
3. 置信度评估：评估 TCD、TPL 和 TCL
4. 措施制定：根据评估结果制定相应措施
5. 工具验证：验证工具是否满足要求

案例：编译器的工具置信度评估

工具：GNU Compiler Collection (GCC)

步骤 1：工具识别

• 工具名称：GCC
• 工具版本：11.2.0
• 用途：编译 C/C++ 代码

步骤 2：工具分类

• GCC 用于编译安全相关代码
• 可能影响安全相关的工作产品
• 类别：TCL 3

步骤 3：置信度评估

TCL 计算：

• TCD = 3
• TPL = 3
• TCL = 4

步骤 4：措施制定

步骤 5：工具验证

使用基准测试验证 GCC：

# 编译基准测试程序
gcc -O2 -Wall -Wextra benchmark.c -o benchmark

# 运行基准测试
./benchmark

# 比较输出与预期
diff output.txt expected.txt

案例：静态分析工具的工具置信度评估

工具：Coverity

步骤 1：工具识别

• 工具名称：Coverity
• 工具版本：2023.03
• 用途：静态代码分析

步骤 2：工具分类

• Coverity 用于分析安全相关代码
• 直接影响安全相关的工作产品
• 类别：TCL 4

步骤 3：置信度评估

TCL 计算：

• TCD = 3
• TPL = 3
• TCL = 4

步骤 4：措施制定

接口协议

接口的定义

接口（Interface） 是系统之间、子系统之间、组件之间交换数据和信息的途径。

接口协议的核心活动

1. 接口识别

接口识别是识别所有的系统内和系统间接口。

接口类型：

1. 硬件接口

   • 电气接口（电压、电流、信号）
   • 机械接口（尺寸、连接方式）
   • 热接口（散热、温度）

2. 软件接口

   • 函数接口（函数参数、返回值）
   • 数据接口（数据结构、数据格式）
   • 通信接口（协议、时序）

3. 系统接口

   • 车辆接口（与整车其他系统的接口）
   • 外部接口（与外部系统的接口）

2. 接口定义

接口定义是详细描述接口的规格。

接口定义内容：

1. 接口标识
2. 接口描述
3. 接口类型
4. 接口参数
5. 接口行为
6. 接口约束

3. 接口验证

接口验证是验证接口是否满足需求。

验证方法：

1. 接口测试
2. 集成测试
3. 仿真测试

案例：制动系统的接口协议

接口列表：

IF-001：压力传感器接口定义：

IF-003：CAN 通信接口定义：

需求管理

需求管理的定义

需求管理（Requirements Management） 是规划、追踪、控制需求的过程。

需求管理的核心活动

1. 需求识别

需求识别是识别所有的安全相关需求。

需求层次：

安全目标（Safety Goal）
    ↓
功能安全需求（FSR）
    ↓
系统安全需求（SSyR）
    ↓
技术安全需求（TSR）
    ↓
    ├─ 硬件安全需求（HSR）
    └─ 软件安全需求（SSR）

2. 需求分析

需求分析是分析需求的完整性、一致性、可追溯性。

分析维度：

1. 完整性：需求是否完整
2. 一致性：需求是否一致
3. 可追溯性：需求是否可追溯
4. 可验证性：需求是否可验证
5. 可实现性：需求是否可实现

3. 需求追溯

需求追溯是建立需求之间的追溯关系。

追溯矩阵示例：

工作产品管理

工作产品的定义

工作产品（Work Product） 是在安全生命周期中创建的所有产品，包括文档、代码、测试用例等。

工作产品管理的核心活动

1. 工作产品识别

工作产品识别是识别所有需要管理的工作产品。

工作产品分类：

2. 工作产品控制

工作产品控制是管理工作产品的版本和变更。

控制方法：

1. 版本控制：使用 Git 或 SVN 等版本控制系统
2. 变更控制：通过变更请求管理变更
3. 发布控制：控制工作产品的发布和分发

3. 工作产品验证

工作产品验证是验证工作产品是否满足要求。

验证方法：

1. 评审
2. 静态分析
3. 测试

常见错误和最佳实践

常见错误

1. 配置管理不到位

   • 配置项不完整
   • 版本控制不规范
   • 变更记录缺失

2. 文档管理混乱

   • 文档不完整
   • 文档版本不一致
   • 文档归档不规范

3. 工具评估不足

   • 使用未经评估的工具
   • 忽视工具的局限性
   • 缺乏工具验证

4. 接口管理不当

   • 接口定义不清晰
   • 接口验证不充分
   • 接口变更控制不严

最佳实践

1. 使用专业的配置管理工具

   • Git、SVN 等版本控制系统
   • 需求管理工具（如 DOORS）
   • 项目管理工具（如 JIRA）

2. 建立完善的文档管理体系

   • 统一的文档模板
   • 明确的文档评审流程
   • 严格的文档控制流程

3. 严格进行工具置信度评估

   • 评估所有用于功能安全的工具
   • 制定相应的措施
   • 定期验证工具

4. 建立清晰的接口协议

   • 详细定义所有接口
   • 充分验证接口
   • 严格控制接口变更

总结

ISO 26262-8 支持过程部分为功能安全的实施提供了重要的基础保障。通过本文的深入解读和丰富的案例实践，我们掌握了：

1. 配置管理：

   • 配置识别
   • 配置控制
   • 配置状态记录
   • 配置审计

2. 文档管理：

   • 文档规划
   • 文档编制
   • 文档控制
   • 文档归档

3. 工具置信度评估：

   • 工具分类（TCL 1-4）
   • 工具置信度评估方法
   • 编译器和静态分析工具的评估

4. 接口协议：

   • 接口识别
   • 接口定义
   • 接口验证

5. 需求管理：

   • 需求识别
   • 需求分析
   • 需求追溯

6. 工作产品管理：

   • 工作产品识别
   • 工作产品控制
   • 工作产品验证

核心要点：

• 配置管理是确保产品一致性的关键
• 文档管理是确保可追溯性的关键
• 工具置信度评估是确保工具可靠性的关键
• 接口协议是确保系统集成性的关键
• 需求管理是确保需求可追溯性的关键
• 工作产品管理是确保产品可控性的关键

在下一篇文章中，我们将深入解读 ISO 26262-9 ASIL 导向的分析方法，学习如何针对不同 ASIL 等级进行分析。

延伸阅读

• ISO 26262-1: 词汇
• ISO 26262-2: 功能安全管理
• ISO 26262-6: 软件级开发
• ISO 26262-9: ASIL导向的分析
• ISO 26262 整体综述