Tool Qualification 工具鉴定

TI 分 2 级，判断工具是否会引入或漏掉安全相关错误——这是 Tool Qualification 的入口判断：

典型 TI1 例子：

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

典型 TI2 例子：

• 编译器（TASKING VX-toolset、GCC、ARM Compiler）：生成可执行代码
• 代码生成器（dSPACE TargetLink、Simulink Embedded Coder）：从模型生成 C 代码
• 自动测试工具（Vector CANoe）：决定通过/失败
• 静态分析（Polyspace、MISRA-checker）：决定 bug 报或不报

TD 分 3 级，判断工具错误的被发现能力，取决于后续验证流程能否抓到：

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

• 编译器错误 → 单元测试 + MC/DC 覆盖率能抓出大部分 → TD2（TriCore 指令集 edge case 可能漏）
• 代码生成器错误 → MIL + SIL + PIL 三层测试能识别大多数功能错 → TD2
• HIL 测试自动化脚本错误 → 项目专属 CAPL 脚本，CANoe 本身 bug 无其他测试防线 → TD3

TCL 由 TI × TD 矩阵决定——只有 TCL 2/3 需要 qualification，TCL 1 工具（占 90%）直接放行：

关键认知：只有 TCL 2/3 工具需要 qualification——TCL 1 工具直接放行。这是"投入产出比"机制，不可能 qualify 所有工具。

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

• 依据：典型 ≥ 100 个项目使用案例，无安全相关问题报告
• 典型工具：TASKING VX-toolset、GCC、Simulink、Vector CANoe（业界长期使用）
• 优点：成本低；缺点：需要工具供应商证据，新工具用不上

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

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

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

• 依据：工具用户做了系统性 validation，覆盖所有功能
• 典型用法：小众工具 / 自研工具；优点：对任何工具都行；缺点：工作量大（几人月起）

按 ISO 26262/IEC 61508 全套流程重新开发工具。几乎不用——成本太高，极少有供应商走这条路。

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

以下 5 个工具覆盖 EPS 开发全流程，TI 评估基于"工具错误是否会静默地影响安全功能输出"判断：

对 TI2 工具逐一判断后续验证流程的探测能力（TD），决定能否把 TCL 从 3 降为 2：

将 TI × TD 矩阵映射为 TCL 等级，再结合 EPS 项目最高 ASIL D 确定所需 TQL 和鉴定方法：

CANoe TCL 3 + TQL 3 要求 1b（Vector TQK）+ **1c（项目自做 validation）**组合，1c 是本例最重的 qualification 任务：

Validation test suite 设计（项目自研，约 2.5 人周）：

• 信号路由 12 用例：CAN × 4 路、LIN × 2 路、SPI 嗅探 × 2 路，各路注入已知数值并核对 CANoe 测量值（比较精度 ± 1 bit）
• pass/fail 判断 6 用例：故意注入 3 种错误信号（电压越限、时序偏移 > 5 ms、CRC 错），确认 CANoe 正确触发 FAIL；再验证正常信号 → PASS
• 时间精度 4 用例：100 ms 事件序列触发，要求 CANoe 时间戳误差 ≤ 1 ms（实测 0.3 ms，裕量 3.3×）

执行约束：两名工程师各自独立运行测试套件，结果须一致（1c 内部 maker ≠ checker）；结果归档进 Safety Case 的 Tool Qualification Report 章节。

结论：5 个工具中 4 个靠 TQK 引用（低成本），1 个（CANoe）需约 2.5 人周自做 validation——这是 EPS ASIL D 工具链最经济的鉴定策略。

这是所有 Tool Qualification 评审中最高频的失误，发生率约 60–70%。常见理由是"我们之后还有手工 review，所以工具错误能被发现"——这把 TI 与 TD 的定义混淆。TI1 的判定条件是"工具本身不会引入或漏掉错误"（如配置管理工具不修改代码），而不是"有后续检查"；后续检查的强度决定 TD 等级，不改变 TI 结论。代码生成器（TargetLink/Embedded Coder）必然 TI2，把它评成 TI1 直接绕开所有 qualification 要求。根本修复：TI 评估表由安全经理签字，并附"工具 X 的错误如果发生，会不会影响安全功能输出"一句话判断。

TASKING VX-toolset v6.2 有 TQK，项目升级到 v6.3 后继续引用旧 TQK。供应商在 v6.3 可能引入新的 TriCore 代码生成路径（如新指令集扩展），旧 TQK 不覆盖新路径。TQK 是 per-version 绑定文档，不适用于超出声明版本范围的工具。规则：工具 major 或 minor 版本升级必须触发 PCN + 重新下载/验证 TQK；若供应商 TQK 尚未更新新版，暂缓升级或启动补充 1c validation。

许多 TQK 含 assumption table，例如"本 TQK 仅覆盖 ISO 26262 ASIL C 及以下"，或"用户须关闭 -O3 优化选项"，或"需配合供应商提供的 linker script 模板使用"。项目按 ASIL D + -O2 + 自定义 linker script 使用，TQK 即部分失效。预防：Confirmation Review 的检查清单中必须包含"TQK assumption 表已 review，所有条款在本项目满足"作为强制通过门，缺失即不通过。

项目中途将 Python 2 自研测试脚本迁移至 Python 3，同时新增了 pass/fail 自动判断逻辑（旧版只格式化报告）。旧脚本是 TI1，新脚本是 TI2/TD3 → TCL 3。但没有触发 PCN，新脚本直接进了生产，Safety Case 仍引用旧 TCL 1 结论。规则：任何工具的用途扩展、版本升级、功能新增都要触发 TI/TD 重评——不限于"换了新工具"，功能边界变化同样触发。

团队自写的 Python 脚本批量处理 Polyspace 报告、自动为 MISRA violation 标 waiver。这是 TI2 工具（它决定哪些安全相关违规被接受），且无独立测试其逻辑，TD 极可能 TD3 → TCL 3 + TQL 3。规则：参与任何安全活动（需求拆分/测试判断/静态分析结论/代码验证）的任何脚本都要评 TCL，不论是 Python、Bash、Excel 宏还是 CAPL 片段。工具清单覆盖范围是 Safety Case 审计的重要检查点。

TASKING VX-toolset（TCL 2，TQK 已引用）生成目标文件，输入 TASKING INSPECTOR（代码覆盖率分析）。每个工具各有 TQK，但两者之间的接口：TASKING 生成的 .elf 格式是否完整被 INSPECTOR 解析？INSPECTOR 的 known limitation 是否覆盖该 .elf 变体？这个接口层没有专门 qualification。预防：工具链级别评估需在工具与工具之间的接口点做 1c validation，覆盖"tool A 输出格式作为 tool B 输入"的有效范围；接口版本绑定纳入 PCN 管理。

EPS 项目已 qualify Vector CANoe 用于 CAN + LIN 信号测试。BMS 项目新增 CAN-FD + Ethernet SOME/IP，直接复用 EPS 的 CANoe qualification（认为"同一工具版本，应该能用"）。但 EPS 的 1c validation 套件只覆盖 CAN/LIN API；BMS 引入的 CAPL SOME/IP API 调用路径未经 validation。跨项目复用 TQK 时，必须 diff 新项目的工具 use case 与旧项目 validation 的覆盖范围，差异需补充 1c；工具版本相同但项目用途扩展时仍需重评。

ASIL D 分解为 B(D)+B(D)（双通道 EPS 主驱 ECU）后，每条路径最高 ASIL 为 D。TC397 双核冗余实现的两个软件通道均在同一 TASKING 编译器下编译——编译器依然按最高分配 ASIL D 评 TQL 2（TCL 2 + ASIL D），不因"每条路径仅 ASIL B(D)"而降低。ISO 26262 Part 2 §6.4.4 明确：分解后每个元素须满足其 ASIL，分解不允许降低工具要求。实操陷阱：团队误以为"分解后每路 ASIL B，编译器只需 TQL 1"，违反标准。正确判断：按产品整体最高 ASIL（D）评工具。

TC397 作为 SEooC 供应商（Infineon）已在供应商端 qualify 了开发工具（HighTec GCC + Polyspace，TQK 归档在 SEooC Safety Manual 中）。Tier-1 集成方不能直接引用供应商的工具 TQK，因为：① Tier-1 使用的可能是 TASKING 而非 HighTec GCC；② 即使版本对齐，供应商 TQK 的 AoU 中可能有"仅适用于供应商内部流程"的限制；③ Tier-1 新增的工具（CANoe HIL）不在 SEooC TQK 覆盖范围内。规则：SEooC AoU 验收清单必须包含工具 qualification 条款：供应商 qualify 的工具版本 = 集成使用版本，且 AoU 全部满足。

Vector 发布 CANoe 17.0（新增 SOME/IP 协议栈测试 API），但新版 TQK 延迟 3 个月发布。BMS 项目紧急需要 SOME/IP HIL 测试，三种选项：① 等 TQK（停工 3 个月，项目延期不可接受）；② 降级不用新 API（SOME/IP 部分改用手工测试，CANoe 从 TD3 降到 TD2，TCL 从 3 降到 2，引用旧版 TQK 覆盖非 SOME/IP 功能，SOME/IP 手工测试补充）；③ 项目自做 1c validation（启动约 4 周 CAPL 测试套件开发覆盖 SOME/IP API，成本约 1 人月，可立即继续 HIL 测试，TQK 到位后归档）。选项③是成本与时效的最优解，但必须在 TQK 真空期开始时即启动——不能等到 TQK 发布日前两周才反应。