Tool Qualification 工具鉴定

功能安全L1别名 Tool Qualification · TCL · TQL · 工具鉴定 · Software Tool Qualification · ISO 26262 Part 8 Tool

本质与导读

本质 ISO 26262 不允许"工具可信"被假设、必须证明:工具(代码生成器/编译器/分析工具)可能把 ASIL D 需求悄悄改错。靠 TI × TD → TCL → TQL 判断要不要 qualify 及做多深——TCL 1 免做(占绝大多数),TCL 2/3 才需按 TQL 做,实操多直接引用供应商的 TQK 而非自做。

主线坐标:横轨 · 功能安全(跨站) · ↑ 全景主线

1. 为什么要 Tool Qualification

ISO 26262 把失效分两大类:随机硬件失效 + 系统性失效。Tool 错误属于后者——同一个工具错误会在所有用它的产品里复现,所以一旦上车会大规模召回。

真实案例:

  • 2015 年某 OEM 的自动代码生成器把"signed int8"误转成"uint8",导致负扭矩命令变成正向最大扭矩——召回 5 万辆车,损失 ¥2 亿
  • 编译器优化把"volatile"变量错误优化掉,导致电源监控漏检——召回案例多

Tool Qualification 的目标:对每个工具,要么证明"它不可能引入错误",要么证明"它就算引入错误,你也能查出来"。

2. TI × TD → TCL 决策链

ISO 26262 Part 8 §11 把工具分类为 3 步:

Tool Classification 决策 — TI (影响) × TD (探测) → TCL → TQL

2.1 TI (Tool Impact)

TI 分 2 级 — 工具是否会引入或漏掉错误,这是 Tool Qualification 的入口判断:

等级含义
TI1工具不会引入或漏掉错误 (即:出错也不影响产品安全)
TI2工具可能引入或漏掉错误 (有安全影响)

典型 TI1 例子:

  • 配置管理工具 (Git):本身不修改代码内容
  • 文档工具 (Word):写文档,不生成产品
  • 项目管理工具 (Jira):跟踪任务,不参与产品

典型 TI2 例子:

  • 编译器 (GCC, IAR, ARM Compiler):生成可执行代码
  • 代码生成器 (Simulink Embedded Coder):从模型生成 C 代码
  • 自动测试工具 (Vector CANoe):决定通过/失败
  • 静态分析 (Polyspace, MISRA-checker):决定 bug 报或不报

2.2 TD (Tool Detection)

TD 分 3 级 — 工具错误的被发现能力,取决于后续验证流程能否抓到:

等级含义解释
TD1极高工具错误几乎一定能被发现
TD2中等工具错误有些可以发现,部分会漏
TD3低工具错误很难被发现

TD 的判定取决于"后续验证流程能不能抓到工具错误":

  • 编译器错误 → 单元测试 + MC/DC 覆盖率能抓出大部分 → TD1
  • 代码生成器错误 → 如果有完整的 model-in-the-loop + HIL 测试 → TD2
  • 自动需求拆分工具错误 → 如果没人审查 → TD3

2.3 TCL 决策表

TCL 由 TI × TD 矩阵决定 — 只有 TCL 2/3 需要 qualification,TCL 1 占 90% 实际工具直接放行:

TITD1TD2TD3
TI1TCL 1TCL 1TCL 1
TI2TCL 1TCL 2TCL 3

关键认知:只有 TCL 2/3 工具需要 qualification——TCL 1 工具 (90% 实际工具) 直接放行。这是个"投入产出比"机制——不可能 qualify 所有工具。

3. TQL — 鉴定力度

TCL 2/3 工具需要 qualify,力度由 ASIL 等级决定:

ASILTCL 2 工具TCL 3 工具
QM/ASIL ATQL 1TQL 1
ASIL BTQL 1TQL 2
ASIL CTQL 2TQL 3
ASIL DTQL 2TQL 3

TQL 4 一般不要求——除非 OEM 加严。

4. 四种 Qualification 方法 (1a-1d)

ISO 26262 Part 8 §11.4 提供 4 种鉴定方法,根据 TQL 选用:

4.1 方法 1a — Increased confidence from use

证明工具已经在很多类似项目用过,实战零问题。

  • 依据:典型 ≥ 100 个项目使用案例,无安全相关问题报告
  • 典型工具:GCC、Simulink、IAR、Vector CANoe (业界长期使用)
  • 优点:成本低
  • 缺点:需要工具供应商证据;新工具用不上

4.2 方法 1b — Evaluation of tool development process

证明工具开发流程本身遵循 ISO 26262/IEC 61508。

  • 依据:工具供应商按 ASIL D 流程开发了这个工具
  • 典型工具:Polyspace、QA-C、dSPACE TargetLink (高端付费工具)
  • 优点:覆盖面广
  • 缺点:工具供应商不肯给完整流程文档

4.3 方法 1c — Validation of the software tool

工具用户自己测试工具——精心设计测试用例,覆盖所有 use case。

  • 依据:工具用户做了系统性 validation,覆盖所有功能
  • 典型用法:小众工具 / 自研工具
  • 优点:对任何工具都行
  • 缺点:工作量大 (一个完整 validation 几人月起)

4.4 方法 1d — Development in accordance with safety standard

按 ISO 26262/IEC 61508 全套流程重新开发工具。

  • 依据:工具按安全标准从头开发
  • 典型用法:几乎不用——成本太高
  • 典型工具:某些特定的安全相关工具供应商提供

4.5 TQL × 方法选择

TQL 越高需要叠加方法越多 — TQL 3+ 必须 1b + 1c 双重,单一方法不够:

TQL推荐方法
TQL 11a 或 1c
TQL 21a + 1b,或 1a + 1c
TQL 31b + 1c (双重)
TQL 41b + 1c + 1d (三重)

5. 常用车规工具的 TCL 评估

下表是行业常见工具 + 典型评估 (具体看实际使用):

工具典型 TCL一般 qualification 路径
GCC / IAR / ARM CompilerTCL 2-3供应商提供 TQK + Tier-1 引用 (1a + 1b)
Simulink + Embedded CoderTCL 3Mathworks 提供 TQK + Tier-1 引用 (1a + 1b)
dSPACE TargetLinkTCL 3dSPACE TQK (ISO 26262 certified)
PolyspaceTCL 2Mathworks TQK
MISRA Checker (LDRA/QAC)TCL 2LDRA TQK
Vector CANalyzer/CANoeTCL 2-3Vector TQK
DOORS / Polarion / JamaTCL 1无需 (只追踪需求)
Git / SVNTCL 1无需
Jenkins / GitLab CITCL 21c validation
AUTOSAR Configuration ToolTCL 3EB tresos / Vector DaVinci TQK
HIL 系统 (dSPACE/NI)TCL 2-3双方共同 1c
Manual review tools (Word/Excel)TCL 1无需

6. TQK — Tool Qualification Kit

TQK 是工具供应商提供的"qualification 文档包",Tier-1 引用即可,免去自做。

TQK 典型内容:

  • 工具版本号 + 适用范围
  • 已经过的方法 (1a/1b)
  • 工具开发过程文档 (摘要)
  • 已知问题清单 + workaround
  • 用户责任说明 ("用户应做哪些 sanity check")
  • 测试用例 + 测试报告

典型 TQK 提供商:

  • Mathworks:Simulink/Embedded Coder TQK,覆盖 ISO 26262 ASIL A-D
  • dSPACE:TargetLink TQK
  • Vector:CANoe / DaVinci / CANalyzer TQK
  • Elektrobit:tresos AUTOSAR config TQK
  • Lauterbach:TRACE32 debug TQK

TQK 引用流程:

  1. Tier-1 下载工具供应商 TQK
  2. Tier-1 验证 TQK 适用版本与项目用的工具版本一致
  3. Tier-1 验证 TQK assumption (供应商假设) 与项目实际匹配
  4. Tier-1 在 Safety Case 里引用 TQK + 写补充说明
  5. Confirmation Review 时审计员检查 TQK 引用

7. Tool Qualification 与 topic-tsc-dia 的关系

DIA 必须列明 工具 qualification 责任分配:

DIA 条款内容
共享工具清单OEM/Tier-1/Tier-2 各自用什么工具
TQK 互信OEM qualify 的工具,Tier-1 是否可直接用
联合验证接口工具 (如 CAN database) 由谁 qualify
新工具 PCN替换工具时如何重新 qualify

典型场景:大众/Audi 已经把 Vector CANoe qualify 了,Tier-1 供应商可以引用大众的 TQK,免去重做。

8. Tool Qualification 失败的典型场景

Tool Qualification 失败模式集中在 5 个反复出现的坑:

场景描述预防
TCL 评估太松把代码生成器评成 TCL 1 (实际 TCL 3)评估表必须由安全经理签字
TQK 版本错配用 TQK 是 v3.0,实际工具 v4.0TQK 与工具版本必须严格匹配
TQK assumption 没读工具假设"只用 ASIL B 以下",实际用到 ASIL DTQK assumption 表必须 review
工具变更不重做中途换了编译器版本,没重做 qualification任何工具变更触发 PCN + qualify
自研工具忽略"我自己写的小脚本不算工具"任何参与安全工作的脚本都要评 TCL

9. 5 个常见陷阱

Tool Qualification 执行失败总结:

陷阱描述预防
90% 工具都评 TCL 1走过场,把 TI2 工具评成 TI1严格按 §11.3 走 TI 评估
引用过期 TQK工具供应商 5 年前发的 TQK每年复查 TQK 时效
Tool 错误溯源出现 bug 后才发现 tool qualification 没做Phase 2 (Design Freeze) 前必须 qualify 完所有 TCL 2/3
工具组合未评A 工具 + B 工具组合使用,接口未 qualify工具链 (chain) 整体评估
跨项目复用未 review上一个项目 qualify 了,这个项目直接用每个新项目重新 review TI/TD

核心要点
  • Tool Qualification 是 ISO 26262 Part 8 §11 强制——所有 TCL 2/3 工具都要 qualify。
  • 评估链:TI × TD → TCL → TQL——只有 TCL 2/3 需要 qualification。
  • 4 种方法:1a 历史使用 / 1b 工具开发流程 / 1c 用户 validation / 1d 重新开发。
  • TQL 越高用越多种方法叠加:ASIL D + TCL 3 = TQL 3 = 1b + 1c 双重。
  • TQK (Tool Qualification Kit) 是工具供应商提供的 qualification 文档包——Tier-1 引用即可,大幅省工。
  • 主流 TQK 提供商:Mathworks / dSPACE / Vector / Elektrobit / Lauterbach。
  • DIA 必须列明工具 qualification 责任分配——OEM 已 qualify 的工具,Tier-1 可引用。
  • 实战陷阱:TCL 评太松、TQK 版本错配、自研脚本没评——Phase 2 前必须完成所有 TCL 2/3 工具 qualification。

Engineering Objects
引用此页的结构化 Engineeri…

引用此页的结构化 Engineering Object(v2.0 Copilot 自动生成,不要手动编辑此段)。

  • standard · standard_iso26262_part8 — ISO 26262 Part 8 Supporting Processes

Cross-references