ISO 26262-8(2018)支持过程：Tool Qualification / TCL / 配置 / 变更管理

TCL 由两维参数决定：

TI（Tool Impact）：工具误差是否可能引入或漏检产品错误？

• TI1：有论证证明完全不可能（极少，如输出不进产品的纯文档工具）
• TI2：默认——99% 工具按 TI2（compiler / code gen / 静态分析 / 测试工具）

TD（Tool error Detection）：下游过程对工具误差的检出置信度：

• TD1：高置信度——独立下游验证能捕获工具 bug（如 LDRA 覆盖率 + 完整测试套件）
• TD2：中置信度——部分检测（静态分析 + 部分测试）
• TD3：无系统性检出（只编译完直接烧片）

TCL 矩阵（ISO 26262-8 Table 3）：

• TCL1：无需额外 qualification（可直接用，需版本记录）
• TCL2：中等 qualification（Increased Confidence from Use 或 Tool dev process evaluation）
• TCL3：完整 qualification（最严）

GCC 编译器本身无 ISO 26262 认证，但 GCC→LDRA→VectorCAST 这条完整链在编译产物上捕获 compiler bug，实现 TD1 → TCL1。TCL 不是工具的属性，是"工具 + 下游过程"整体的属性。

TCL2 与 TCL3 用同一组 4 个 qualification 方法，区别在推荐强度随 ASIL 变。四方法：1a Increased confidence from use（IUC，历史使用证据）/ 1b Evaluation of the tool development process（工具开发流程评估）/ 1c Validation of the software tool（自建测试套件验证工具行为）/ 1d Development in accordance with a safety standard（工具本身按安全标准开发）。

Table 4 — TCL3 qualification（最严）按 ASIL 推荐度：

Table 5 — TCL2 qualification（较宽松）按 ASIL 推荐度：

规律：低 ASIL（A/B）偏好 IUC / 流程评估（有历史证据即可），高 ASIL（C/D）的 TCL3 偏好 Validation / 按标准开发（必须主动构造证据）；TCL2 整体风险低，即使 ASIL D 也允许 IUC（降为 + 但仍可用）。++ = highly recommended，+ = recommended。ASIL D 给 LDRA / Polyspace 做 full Validation（1c）通常是 6-12 个月工作量，所以工程上首选把 TCL3 工具降到 TCL2 后走 IUC。

400V/100kW EV 主驱逆变器控制器，TC397 + AUTOSAR Classic，ASIL D 安全分区（CPU0+CPU1 lockstep ASIL D / CPU2 ASIL B / QM partition）。工具链 8 个工具需 TCL 评估：

逐个工具定 TI/TD/TCL（版本为该项目工具链快照，qualification 证据须绑定精确版本）：

高优先 action items：

1. INCA TCL3 → TCL2 降级路径：在 INCA 写入后立即用独立读取工具（如示波器 / TC397 SPI 回读）cross-check 所有 SC 参数值 → TD3 降为 TD2 → TCL3 降为 TCL2。降级后 TCL2 的 qualification 按 Table 5：ASIL D 下 Validation（1c）为 ++ 推荐、IUC（1a）为 + 可用但需额外论证，可行。
2. Python 脚本 TCL3 消除路径：用有 IUC 记录的 qualified 标定工具替代 Python 脚本；或为 Python 脚本写完整 test suite（所有 SC 相关 use case 100% 验证）→ 成为 validated tool（1c）→ TD2/TCL2。

LDRA Testbed 定为 TCL2、项目 ASIL D。按 Table 5，此格 Validation（1c）为 ++、IUC（1a）为 +。团队基于该版本长期无缺陷的量产记录，选走成本更低的 Increased Confidence from Use（IUC，1a），并在 Safety Case 中论证为什么 IUC 对本工具足够（否则默认应上 ++ 的 Validation）。

IUC 四证据：

1. 精确版本 + 配置：LDRA Testbed + TC397 plugin + TASKING interface 的精确 minor version 与 compiler flag 组合（qualification 证据绑定到此确切组合）
2. 量产经验：同版本在前项目（Gen 1 400V 主驱）使用 18 个月（2024-01 至 2025-06），无已知影响产品的 bug
3. Bug log：LDRA 官方 release notes 中无影响 MC/DC 计算的 defect 记录（需维护 bug watch）
4. 使用条件不变：同 platform（TC397）/ 同 OS（Windows 10 Enterprise LTSC）/ 同 host 配置

版本升级即 IUC 归零：LDRA minor 版本升级（如 9.7 → 9.9）需重新建立 IUC 证据（至少 3 个月使用 + bug watch 维护），否则回退到 Validation。

ISO 26262-8 Clause 8 要求每个变更必须经过：change request 分析 → 影响评估（safety-relevance 判断）→ 实施 → 文档更新 → 再验证 → 审查。ASIL D 的"再验证"必须完整（MC/DC 重跑 + 回归测试套件），不能只跑 delta。

背景：field 发现某批次 SiC 器件（SCT3080AL）开通速度偏快，tblank = 816 ns 偶发误触 DESAT，需延长到 900 ns。DESAT blank time 由消隐电容线性决定（充电电流与阈值固定，tblank 正比 CDESAT），故 816→900 ns 需 CDESAT_new = 68 pF × 900 / 816 = 75 pF → 选 82 pF（E12 标准值，实测 tblank = 82 pF × 6 V / 500 µA = 984 ns）。原 CDESAT = 68 pF，基于 1EDI3035AS：VDESAT2 = 6 V、IDESATCS = 500 µA，tblank = 68 pF × 6 V / 500 µA = 816 ns（见 AoU-GD-02）。

总周期：21 天（最优路径），复杂变更（涉及 FMEDA 迭代）可达 6-8 周。

ISO 26262 配置管理要求超出普通 git 工作流：每个 work product 需唯一版本 + 状态（draft / released）+ 可独立重建（reproducibility）+ baseline（一次完整发布的配置项集合）。

TC397 ASIL D 项目配置管理方案（标识符格式为组织自定，ISO 26262-8 Clause 7 只要求"唯一标识 + 版本 + 状态"，不规定格式）：

• 代码层：git（TC397_MainDrive_SW repo）+ tag 策略（如 v3.2.1-M14-FSA-Interim）
• 需求层：Polarion（SR 树 baseline，如 PB-TC397-2026-M14）
• 关联：Polarion SR → git commit hash 双向链接（trace requirement → code）
• baseline 定义：M14 FSA Interim = git SHA + Polarion baseline + LDRA report ID 三者绑定

git 不够用的原因：git 只管代码版本，无法管理需求 / 验证报告 / FMEDA 等 non-code work products 的版本与关联关系，需配合 Polarion / DOORS Next 构成完整 SBOM（Software Bill of Materials）。

复用商业 motor control 库（QM 开发）做 ASIL D 主驱的资格化要求：

a. 需求规范（functional specification）已有
b. 符合需求的证据（supplier 测试套件）已有
c. 适用于预期用途（已在类似 EV 应用使用）已有
d. 结构化覆盖率（structural coverage）在你的 use case 下测 → 重跑所有 ASIL D 相关路径的 MC/DC → 几乎等于重写测试套件
e. 开发过程：QM 库不满足 ISO 26262-6 软件开发要求

结论：纯 QM 库在 ASIL D 几乎不能复用——重做覆盖率测试成本 = 自己写的 150%（因为不熟代码）。量产 ASIL D 项目用 Vector AUTOSAR BSW（ISO 26262 认证）/ Wind River VxWorks Safety（IEC 61508 认证）。

硬件 / 软件组件用历史 field data 论证资格（Clause 14），条件：

• 版本完全一致（minor version 相同、无修改）
• 系统化收集且可信的 field failure 统计（无 underreporting）
• 累计运行经验统计上足以证明目标失效率——不是单一固定门槛：required service duration 由目标随机硬件失效率 + 观测到的失效数经统计（chi-squared 置信区间）推导，对 ASIL 级低失效率目标通常落在 10^7~10^9 累计运行小时量级

新 IP 基本无法用 Proven in Use——TC397 首次上量产线 <1 年，即使某些平台使用时间够，也需维护完整 failure log 且版本冻结。

OEM ↔ Tier 1 ↔ IC 供应商多方协作时，DIA 定义：责任分配（谁开发哪个 work product）、SR 传递（谁给谁哪些 SR）、验证责任（谁 verify 谁的输出）、配置管理责任（谁 own 哪个 baseline）、异常处理（发现 bug / change 的 escalation 路径）。业界常用 RASIC（Responsible/Accountable/Supporting/Informed/Consulted）矩阵把每项 safety activity 落到具体方。

SEooC（IC supplier 无上下文开发的 safety element）通过 AoU（Assumption of Use）传递 safety 前提条件。DIA 明确：Tier 1 签字确认"我们满足这些 AoU"——违反 AoU 时责任从 IC supplier 转移至 Tier 1。DIA 没签或签得不完整，Tier 1 与 IC supplier 的责任纠纷无解（已有多起 OEM 审计退品案例）。