ISO 26262-8(2018)支持过程细化:Tool Qualification / TCL / 配置 / 变更
本质与导读
本质 Part 8 是 ISO 26262 的"管理与方法"part,所有 Part 都依赖它;真正栽人的是 Clause 11 Tool Qualification——用 GCC、Simulink、LDRA 都得先论证工具不会引入未检测错误。TCL 由 Tool Impact (TI) × Tool error Detection (TD) 矩阵定:TI2 × TD3 = TCL3 = 强制 qualification,这是 Tier 1 / IC 厂被审计最常失分的一关。
1. Part 8 的 13 个 Clause 全景
这一节先把“Part 8 的 13 个 Clause 全景”的判断维度收拢到同一视图里，后面的表格用于横向比较各选项的边界。
| Clause | 角色 | 工程关键 |
|---|---|---|
| 5 | Interfaces within distributed developments(DIA) | Tier 1 ↔ Tier 2 责任划分契约 |
| 6 | Specification and management of safety requirements | 需求层级与可追溯性 |
| 7 | Configuration management | git / Polarion / DOORS 用法 |
| 8 | Change management | ECR / ECN 流程 |
| 9 | Verification | 验证计划 / 规范 / 报告 |
| 10 | Documentation management | 文档树结构 + 版本控制 |
| 11 | Confidence in the use of software tools | Tool Qualification 入口(本页重点) |
| 12 | Qualification of software components | COTS / 库复用资格 |
| 13 | Qualification of hardware components | 硬件元件复用 |
| 14 | Proven in use argument | 历史 field data 论证 |
| 15 | Interfacing an application that is out of scope of ISO 26262 | 与非汽车系统接口 |
| 16 | Integration of safety-related systems not developed according to ISO 26262 | legacy 集成 |
实务:Tier 1 项目里 5 / 7 / 8 / 11 / 12 用得最多——DIA(distributed development interface agreement)谁负什么责、git 工作流怎么走、tool qualification 怎么过、复用 motor control 库怎么定 ASIL。
2. Tool Confidence Level (TCL) 决策(Clause 11)
2.1 TI(Tool Impact)— 工具影响等级
工具误差有没有可能引入或漏检产品错误?
- TI1:有论证表明完全不可能(例:工具的输出在产品里被独立 SM 检验,工具错产品就能被抓到)
- TI2:其它所有情况(默认 = TI2,不要轻易认 TI1)
工程实操:99% 工具默认按 TI2 —— Compiler / Simulink Code Gen / 静态分析工具 / 测试覆盖率工具 都是 TI2;只有"一次性手动操作的辅助工具"(画原理图的 Visio)能勉强争 TI1。
2.2 TD(Tool error Detection)— 工具错误检出置信度
防止 / 检测工具误差的措施置信度?
- TD1:高置信度——后续步骤独立验证工具输出(例:Compiler 后跑 LDRA 覆盖率 + 静态分析,任何 compiler bug 几乎都能被下游检出)
- TD2:中置信度——有部分检测但不全(例:静态分析 + 测试 双重保护)
- TD3:其它(无系统性检出措施,只能靠运气)
工程实操:TD 的判定看下游过程——如果你 build 完后只看 "compile success" 不做任何独立验证,那就是 TD3。如果做完整的单元测试 + MISRA 检查 + 整个测试套件,基本能争 TD1。
2.3 TCL 矩阵(Table 3)
TCL = TI × TD 二维查表:
| TD1(高检出) | TD2(中) | TD3(无) | |
|---|---|---|---|
| TI1(无影响) | TCL1 | TCL1 | TCL1 |
| TI2(可能影响) | TCL1 | TCL2 | TCL3 |
- TCL1:无需 qualification(可以直接用)
- TCL2:中等 qualification 要求
- TCL3:完整 qualification 要求(最严)
2.4 实战 Tool Chain TCL 评估
这一节先把“实战 Tool Chain TCL 评估”的判断维度收拢到同一视图里，后面的表格用于横向比较各选项的边界。
| 工具 | 用途 | TI / TD | TCL | 说明 |
|---|---|---|---|---|
| GCC / IAR | 编译 C 代码 | TI2 / TD1(下游有 LDRA + 测试) | TCL1 | TCL1 是因为下游覆盖,不是 GCC 本身没问题 |
| Simulink Embedded Coder | MBD 代码生成 | TI2 / TD1(生成代码做单元测试) | TCL1 | 同上 |
| LDRA Testbed | 覆盖率分析 | TI2 / TD2(部分独立验证) | TCL2 | 工具结果决定测试是否充分,要 qualify |
| MathWorks Polyspace | 静态分析 | TI2 / TD2 | TCL2 | 同上 |
| Doxygen | 文档生成 | TI1 / — | TCL1 | 文档错误不进产品,TI1 |
| Make / CMake | 构建系统 | TI2 / TD1(build 失败 = test 失败) | TCL1 | |
| Custom 内部脚本(无验证) | 各种 | TI2 / TD3 | TCL3 | 大坑 — 内部 Python 脚本最容易跌进 TCL3 |
工程实务:避免 TCL3 的关键不是工具本身好不好,是有没有"独立下游验证" —— 一个 GCC bug,如果你的测试 + 静态分析 + MISRA 都能在编译产物里捕获,就是 TD1;如果你只编译完直接烧片,就是 TD3,GCC 立刻变 TCL3,要做完整 qualification(几乎不可能,GCC 不是为 ISO 26262 开发的)。
3. Tool Qualification 方法(Table 4/5)
3.1 TCL3 Qualification(Table 4)— ASIL 推荐度
这一节先把“TCL3 Qualification(Table 4)— ASIL 推荐度”的判断维度收拢到同一视图里，后面的表格用于横向比较各选项的边界。
| 方法 | A | B | C | D |
|---|---|---|---|---|
| 1a Increased confidence from use(IUC) | ++ | ++ | + | + |
| 1b Tool dev process evaluation | ++ | ++ | + | + |
| 1c Validation of software tool | + | + | ++ | ++ |
| 1d Development in accordance with safety standard | + | + | ++ | ++ |
ASIL D 推荐 Validation 或 按 ISO 26262 开发工具 — 第二个几乎无人做(意味着工具本身是 ISO 26262 工作产品)。Validation = 自己写完整测试套件验证工具行为对所有 use case 覆盖 —— 大型 EV 项目里给 LDRA / Polyspace 做 validation 是 6-12 个月的工作。
3.2 TCL2 Qualification(Table 5)
更宽松:Increased confidence from use 或 Tool dev process evaluation 通常够。这是为什么工程上最划算的策略是把 TCL3 工具降到 TCL2——通过加强下游 detection 把 TD3 → TD2。
3.3 Increased Confidence from Use(IUC)— 历史 field data 论证
最常用的 qualification 路径。要求证据:
- Tool 明确版本 + 配置(精确到 minor version + compiler flags)
- 同样 use case 在过去项目用过 X 时间(典型 1-2 年量产经验)
- 未发现导致产品错误的 bug(maintained bug log,所有报告 + 修复)
- 使用条件未变(同 platform / 同 OS / 同输入数据格式)
工程实操:版本升级是 IUC 杀手 — 一个项目用 GCC 9.2 用了两年没问题,新项目升级到 GCC 12,IUC 就不能继承了——要重做 qualification 或论证版本升级带的影响很小。
4. Software Component Qualification(Clause 12)
不同于 Tool Qualification(Clause 11)——Clause 12 处理复用进产品的软件组件(motor control 库 / RTOS / 通信栈 / 数学库)。
4.1 资格证据要求(12.4.1)
要算"已 qualified"必备:
a. 组件规范
b. 符合需求的证据(verification)
c. 适用于预期用途的证据(intended use)
d. 开发过程基于合适标准(IEC 12207 等)
e. 资格化计划
4.2 ASIL D 复用第三方库的痛点
例:用第三方 motor control 库(QM 开发的 commercial library)做 ASIL D 主驱:
- 第三方提供:功能规范 + 测试套件 + 多年量产经验 + 已知 bug 列表
- 你需要补:在你的具体 use case 下重做完整 verification → 满足 ISO 26262-6:2018 Clause 9 的覆盖度要求
- ASIL D 还要求 结构化覆盖率(structural coverage)在你的 use case 下测
工程实务:纯 QM 库通常做不到 ASIL D 复用 —— 重新跑 100% MC/DC 覆盖 + 结构化覆盖几乎等于重写。所以量产 ASIL D 大都用专门的 ISO 26262 认证库(Vector AUTOSAR / Wind River VxWorks Safety)。
5. 配置管理 + 变更管理(Clause 7-8)
5.1 Clause 7 配置管理 — 不是简单的 git
ISO 26262 配置管理要求:
- 每个 work product 有唯一 identification + version + status(draft / released / active / expired)
- 任何 release version 可独立重建(reproducibility)
- 配置项之间的依赖关系可追溯
- baseline 概念 — 一次完整发布的配置项集合
工程实务:git 不够用——除非配合 metadata 管理(Polarion / DOORS Next / Jama)。Tier 1 一般用 git 装代码 + Polarion 装需求 + JIRA 装 bug,三者关联到 baseline tag。
5.2 Clause 8 变更管理 — ECR / ECN
ECR(Engineering Change Request)流程:
- 提出 change request(任何人可提)
- Change request analysis — 影响哪些 work products / safety case
- Change request evaluation — 同意 / 拒绝 / 延后
- 实施 + 文档化(ECN, Engineering Change Notice)
- 配置项 + baseline 更新 + 重新 verification
工程实务:ASIL D 的 ECR 至少 2-3 周走完(分析 + 评估 + 实施 + 验证 + 评审),所以"上电就修 bug"的开发风格在 ASIL D 不可能。
6. DIA(Distributed Development Interface Agreement,Clause 5)
OEM ↔ Tier 1 ↔ Tier 2 ↔ IC 厂多方协作时,DIA 是合同级文档,定义:
- 责任分配(谁开发什么 work product)
- 安全要求传递(谁给谁什么 SR)
- 验证责任(谁 verify 谁的输出)
- 配置管理责任(谁 own 哪个 baseline)
- 异常处理(发现 bug / change 怎么走)
工程实务:DIA 没签或签得不完整,Tier 1 与 IC supplier 之间的责任纠纷无解。SEooC 模式下 IC supplier 的 AoU 进 DIA,客户违反 AoU 责任就明确转回客户。
核心要点
- Part 8 13 个 clause 涵盖整个 ISO 26262 的"管理与方法"层,不限于某 Part
- TCL = TI × TD 二维矩阵:TI2 × TD3 = TCL3(强制 qualification),TI2 × TD1 = TCL1(直接用)
- 避免 TCL3 关键不是工具本身好不好,是下游有没有独立验证(GCC bug 被 LDRA 抓 = TD1)
- TCL3 qualification 4 方法:IUC / 工具开发流程 / Validation / 按 ISO 26262 开发,IUC 最常用
- IUC 4 证据:版本配置精确 / 量产经验 1-2 年 / bug log / 使用条件不变,版本升级是 IUC 杀手
- Software Component qualification(Clause 12)处理复用,ASIL D 纯 QM 库基本不能复用
- 配置管理:git 不够,要 metadata(Polarion / DOORS) + baseline + reproducibility
- 变更管理 ASIL D 的 ECR 至少 2-3 周走完,影响开发节奏
- DIA 是 OEM/Tier1/IC supplier 多方协作的合同基础,SEooC AoU 进 DIA
Engineering Objects
引用此页的结构化 Engineeri…
引用此页的结构化 Engineering Object(v2.0 Copilot 自动生成,不要手动编辑此段)。
- standard ·
standard_iso26262_part8— ISO 26262 Part 8 Supporting Processes
Cross-references
- ← 索引
- 功能安全(Functional Safety):FuSa 总框架
- ISO 26262-5 硬件层细化:Part 5 硬件 metrics
- ISO 26262-6 软件层细化:Part 6 软件流程
- ISO 26262-9 ASIL 分析细化:Part 9 分解 / DFA
- ISO 26262-11 半导体细化:Part 11 半导体 / SEooC
- SEooC:AoU 与 DIA 的核心机制
- ASPICE:软件过程能力评估(可作为 IUC 证据)
- HV 主驱逆变器 ISO 26262 安全概念:上层 V-cycle
- 软件 ASIL D:软件复用资格痛点
- 汽车 MCU:MCU + RTOS 工具链 qualification 实例
- SBC / 伴随 IC:IC supplier DIA 范例
- PPAP:量产 release 时的配置管理交付
- SPC:制造过程的统计控制
- Safety Case:工具 qualification 进 Safety Case