Tool Qualification — TI / TD / TCL → 资格方法 1a-1d 推导 + 主流工具评估

工具资格不是"vendor 给个证就行",而是项目级评估:你怎么用工具决定 TI(影响);项目流程多严决定 TD(检出);两者推 TCL;TCL + ASIL 再推荐 qualification 方法 (1a-1d)。下图把整链关系 + 主流工具映射一次画清:

TI 评估"工具如果出 bug,是否会污染 work product 进而影响 SG":

• TI1:无影响 — 工具 bug 不会让任何 work product 有 safety-relevant 错误
  • 例:文档编辑器、版本管理工具(git)
• TI2:有影响 — 工具 bug 可能让 work product 有错,而错误可能传到 SG
  • 例:编译器(C 代码 → 机器码,bug 让安全机制失效)
  • 例:仿真器(model-in-the-loop 验证用)
  • 例:auto-codegen(Simulink 生成 C)

实战 90% 的开发工具是 TI2。

TD 评估"项目流程能多大概率检出工具引入的错误":

• TD1:高检出 — 流程内置 review / test / cross-check
  • 例:单元测试 100% MC/DC 覆盖率 + 集成测试
  • 例:HIL fault injection test 全覆盖
• TD2:中检出 — 部分 review / 部分自动 test
• TD3:低检出 — 难发现 / 工具几乎单点
  • 例:MATLAB Simulink → C 后无人重审 C 代码

EV 主驱:有 Confirmation Reviews (I0-I3) + FI test + integration test → 通常 TD1-TD2。

TI × TD 二维查表(ISO 26262-8 Table 3):

TI1:任何 TD → TCL1(工具无影响,验证简单) TI2 + TD1:TCL1(影响但流程检出,余量大) TI2 + TD2:TCL2(影响 + 中检出) TI2 + TD3:TCL3(高风险 — 工具相当于 ASIL D 元件)

ISO 26262-8:2018 §11.4.6 定义 4 个 software-tool qualification 方法(1a / 1b / 1c / 1d);§11.4.6.1 规定:TCL3 工具用 Table 4 列的方法、TCL2 工具用 Table 5 列的方法、TCL1 工具不需要任何 qualification 方法。注意表号顺序 —— Table 4 = TCL3、Table 5 = TCL2(标准里 TCL3 在前),别记反:

• 1a:increased confidence from use(基于使用历史增强信心,§11.4.7)
• 1b:evaluation of the tool development process(评估工具开发流程,§11.4.8)
• 1c:validation of the software tool(对工具本身做验证,§11.4.9)
• 1d:development in accordance with a safety standard(按 safety 标准的相关子集开发工具)—— 无独立子条款,仅由 Table 4 / Table 5 的脚注 a 定义(可用 ISO 26262 / IEC 61508 / EN 50128 / RTCA DO-178C)

主流 EV PEU 项目用的工具体系不算多,但每个都要 qualified。下表汇总常见工具 + TI / TD 评估 + 典型 TCL + vendor cert 可获取性:

vendor 给的 cert 不等于通用万能 — 有几个坑要注意:

EV ASIL D 项目工具资格的典型 timeline:

工具未 qualified → I3 评审 reject 这种情况典型来源于"项目晚期发现某工具没 cert" → 推迟 SOP 2-6 个月,所以Month 1 就要锁清单。

如果项目用自研工具(脚本 / 自己写的 lint / build 系统),无 vendor cert,只能自己 qualify:

• TI1 工具(脚本):自评估 + 文档化即可
• TI2 + TCL2 工具:加 review / test 配合
• TI2 + TCL3 工具(关键 codegen / 转换器):自己 develop ISO 26262 compliant process + 第三方 audit(典型 6-12 个月 + 100-500 万成本)

实战:自研 TCL3 工具几乎不可能在合理成本内 qualify,所以 ASIL D 项目通常用 vendor 商用工具而非自研。

把前 9 节的规则一次跑通:对象是一个 400V / 100kW SiC 主驱逆变器(TC397 AURIX + TLF35584 SBC + SiC MOSFET,ASIL D;完整 BOM 见 功能安全工具链对比)。目标 = 对每个进入安全相关 work product 的工具确定 TCL、选鉴定方法、排时序。下面严格按 §11.4.5.2(TI 只有 TI1/TI2)+ Table 3 走,不出现 "TI3"。

工具 qualification 翻车集中在 项目晚期才发现 / cert 覆盖不全 / TCL 误判 / 版本不锁 / 工具链互依 五类。逐条给根因 + 防治:

G1 立项不列工具 → M3 才发现某工具没 cert。项目晚期补 cert 直接推迟 SOP 2-6 个月。防治:M1 就锁全部工具 + 版本清单(Tool BOM),纳配置管理。

G2 升级编译器 → cert 即刻失效。cert 绑精确版本(如 Tasking 6.3r1),升到 6.3r2 须重评估、必要时重跑全量测试套件;典型事故是第 9 月 IT 自动更新编译器 → cert 失效 → I3 要求重做 + 3 周工期损失。防治:Day1 冻结编译器版本,升级走 Change Request。

G3 cert 只覆盖部分功能 → 用了 scope 外的功能。例:Polyspace 的 Bug Finder 与 Code Prover 是独立鉴定项,买了前者鉴定不自动覆盖后者;项目升级用 Code Prover 却没鉴定 → I3 判 minor nonconformity。防治:逐项核 cert 的 scope/TOC,IEC Certification Kit 要把两模块的测试向量都跑。

G4 平台/架构不匹配 → cert 无效。cert 常只覆盖特定 MCU(如 Tasking cert 对 TriCore/AURIX 有效,换 ARM 平台需重评估)。防治:核 cert 文档的 platform 章节,与项目 MCU 逐一比对。

G5 TCL 刻意/无意低报 → 逃避 TCL3 义务。把 dSPACE SCALEXIO 评成 TD1(理由"HIL 错误会被系统测试发现")—— 但 HIL 本身就是系统测试平台,不能自己检出自己,实为 TD3 → TCL3;补救要重跑 Validation Suite,延误数周。防治:TCL 评估邀 I3 或独立工具安全专家参与,避免利益冲突。

G6 TI2×TD1 误当 TCL2 → 反向过度鉴定 / 或分类自相矛盾。把 static analyzer 写成 TI2/TD1 却标 TCL2 是自相矛盾(TI2×TD1=TCL1)。两种错法:要么它真 TD1 → TCL1(白做了 TCL2 鉴定,浪费),要么应按 EXAMPLE 3 评 TD2 → TCL2(那就别写 TD1)。防治:先定 TD 证据强度(高=TD1 / 中=TD2),再查 Table 3,别倒推。

G7 工具链互依 → TD 选取偏乐观。用工具 A 验证工具 B 的输出,若 A、B 共享组件 / 运行时,则 A 的检出不独立,§11.4.5.2 NOTE 3 要求把这种 interdependency 计入、下调后续工具的 TD。典型:codegen 和其配套 verifier 同源 → 不能算 TD1。防治:交叉验证要用 diverse(异源)工具或独立人工复核,否则 TD 不能记高。

工具鉴定的边界条件集中在 自研成本 / 跨标准等效 / 预定 TCL 有效性 三处,各有不同的应对。

C1 自研 TCL3 工具的成本悬崖。关键 codegen / 转换器若自研,method 1c(全量 validation)+ 1d(按安全标准子集开发)+ 第三方 audit 的成本 6-12 个月 / 数百万级,随工具复杂度非线性上涨,常超过工具本身开发成本。边界:当自研工具会进入 ASIL D 安全相关 work product 且无独立复核(TD3)时,自研 qualify 几乎不划算。应对:改用有 cert 的商用工具;或把工具降到 TI1(输出全部独立复核)从而 TCL1,免鉴定 —— 这是最省的一招,但要求下游真有独立验证。

C2 跨标准 cert 的等效边界。vendor 只有 IEC 61508(工业)/ DO-178C(航空)/ EN 50128(铁路)cert,没有 ISO 26262 cert 时,可作 method 1d 的等效证据 —— 但必须写 equivalent argument:做 gap analysis,把源标准的 SIL / DAL 映射到目标 ASIL(如 IEC 61508 SIL3 ↔ ASIL D 需论证覆盖度),并说明工具开发流程差异是否影响置信。边界:等效不是自动成立,DO-178C(更严)上行可作强证据,IEC 61508 横向需逐条 reasoning。应对:cert 非 ISO 26262 时,让 vendor 出 equivalence 说明 + 项目侧存 gap analysis,I3 才认。

C3 预定 TCL / vendor pre-qualified cert 的有效性边界。§11.4.2 规定:独立于具体项目预先做的 TCL 评估 / qualification,在用于某个安全相关 item 之前必须验证其有效性;§11.4.3 要求实际使用的版本、配置、环境、约束与 cert 所依据的一致。边界:vendor 的 pre-qualified cert 只在"你的 use case + 配置 + ASIL + 平台"落在 cert 假设范围内时有效 —— 换配置开关、换 MCU、超出 cert 假设的 ASIL,预定 TCL 即失效。应对:入项目档案时逐条核对 cert 的 assumed use case / configuration / max ASIL,不匹配的项目侧补跑 validation。