Safety Validation 计划写作工程化深度 — 从 SG 派生验证项 + pass 准则可判定性 + 接 Safety Case + I3

SV 在 ISO 26262-4 §8,V-cycle 最右上。它的输入是 SG 列表(来自 HARA)+ 各级安全需求,输出是 SV 报告 → 喂 Safety Case / FSAR。位置决定核心约束:SV 是按 SG 组织的、不是按部件——每条 SG 必须有验证项证明它在整车级满足,这和前面按部件验证(FMEDA/unit test)是不同维度的证据。

下图把 SV 计划的上下游和它"按 SG 收口"的逻辑画在一起。

写作 SOP 4 步:

1. 列 SG:从 HARA 抄全 SG 列表(每条 SG 的 ID + FTTI + 安全状态),这是验证项的派生基线。
2. 派生验证项:每条 SG 派生 ≥1 个验证项——"怎么证这条 SG 在整车级成立"。
3. 写 pass 准则:每个验证项给可判定的 pass 准则(注入条件 + 期望响应 + 时限 + 重复次数 + 判据)。
4. 挂证据 link:每个验证项标环境(HIL/实车)+ 留 SV 报告证据占位 + 上挂 SG ID(供 Safety Case 引)。

SV 计划的最小单元是一个验证项。和 hazard/HSR 条目一样,字段缺一就让 Safety Case 证据悬空。6 字段:

6 字段 + 主驱"非预期加速 SG"worked(承 HARA 那条 ASIL D SG 的整车验证):

• ① 目标 SG:SG-01 — 防止非预期驱动扭矩 > ±10%,FTTI 200 ms,安全状态 STO(引 SG ID)
• ② 验证场景/注入:整车 HIL,高速巡航工况,注入扭矩传感器 stuck-at-high(场景 + 故障注入点)
• ③ 期望整车响应:整车应检出并进 STO,实际扭矩偏差全程 ≤ ±10% 额定(整车级可观测响应)
• ④ pass 准则:STO 在故障注入后 ≤200 ms(FTTI)触发;扭矩偏差全程 <±10%;重复 20 次,0 次失败(时限 + 判据 + 重复)
• ⑤ 验证环境:HIL(dSPACE SCALEXIO)主验 + 实车场地确认 5 次(环境 + 次数)
• ⑥ 证据 link:上:SG-01;证据:SV-REPORT-TORQ-01(波形 + 时序 + 统计)

注意 ④ 的三要素——时限 + 判据 + 重复次数——是 pass 准则可判定的全部:有时限(对比 FTTI)、有量化判据(<±10%)、有重复(防偶发通过)。缺任一,验证项就不可判定。

SV 验证项不是想测什么测什么,是 SG 的机械派生:每条 SG 必须有至少一个验证项,且验证项的集合完整覆盖所有 SG(含降级路径)。漏一条 SG 没验证项,Safety Case 论证树就少一个 solution 节点、那条 SG"满足"无证据——I3 直接判该 SG 论证不成立。

一条 SG 常派生多个验证项,因为 SG 在不同工况/不同故障下的满足要分别证。比如 SG-01"防非预期扭矩"派生:正常工况注入传感器故障 + 高速注入 + 多故障组合 + 降级路径(STO 失败转 ASC)。漏掉"降级路径验证"是最隐蔽的不全——SG 在主路径满足、但 fail-op 降级没验,整车级论证有洞。

这是 SV 写作和 HARA rationale/HSR 可验证性 并列的真难点。判据很硬:一条 pass 准则可判定,当且仅当测完后任何人看数据都能给出唯一的 pass/fail,不需要主观解释。三组"被打回 → 改可判定":

形容词 pass — 打回写法 整车应安全响应扭矩故障。测完测试工程师问:"安全=多快进 safe state?偏差多少算过?" 无法判。可判定写法 注入后 STO 应 ≤200 ms 触发,扭矩偏差全程 <±10%,重复 20 次 0 失败。差别:后者给 时限 + 量化判据 + 重复,数据出来直接判。

缺重复/统计 — 打回写法 HIL 测一次通过即可。安全验证一次通过证明不了——可能偶发。可判定写法 HIL 重复 20 次,要求 0 次失败;若 1 次失败,根因分析后重新跑全 20 次。差别:后者用 重复次数 + 失败处理,把"偶然过"和"稳定满足"分开。

环境/工况不明 — 打回写法 测试环境下通过。I3 追:"什么环境?覆盖哪些工况?HIL 够吗还是要实车?" 可判定写法 HIL(SCALEXIO)覆盖 高速/低速/泊车 三工况各 20 次 + 实车场地高速 5 次确认。差别:后者明确 环境 + 工况覆盖 + 各自次数。

终极判据:写到"测完后把数据交给任何一个工程师,他不问你就能判 pass/fail"的程度。做不到这一步的验证项,做完了 Safety Case 也没法用它当证据——等于没验。

SV 计划执行后产出 SV 报告,它是 Safety Case 论证树里"SG 满足"那个顶层 claim 的直接证据(solution 节点)。所以 SV 报告每个验证项的结果必须:可追溯到计划的验证项 ID + SG ID(双向闭合)、附原始证据(HIL 波形 / 时序 measurement / 实车数据,非"通过"二字)、失败项有根因 + 复测记录。一份只写"全部通过"的 SV 报告,在 FSAR 闭合时被 I3 逐项要原始数据——拿不出就是证据悬空。

I3 评审 SV 计划 + 报告(M4 评估)的 6 查点:

6 个查点:

1. SG 覆盖:每条 SG 是否都有 ≥1 验证项?含降级路径?
2. 可追溯:验证项 ↔ SG ↔ Safety Case solution 节点三向闭合?
3. pass 准则可判定:每个验证项 pass 准则是否含 时限+判据+重复?(主查)
4. 重复充分:安全验证是否有重复次数 + 失败处理(非测一次)?
5. 环境/工况覆盖:HIL/实车环境 + 工况覆盖是否充分、写明次数?
6. 证据原始:SV 报告是否附原始数据(波形/时序),非"通过"二字?

第一,形容词 pass 准则(安全/正常/正确响应)——不可判定,占 SV NC 大头。第二,漏 SG 验证项——某条 SG 没派生验证项,Safety Case 缺证据。第三,测一次当通过——安全验证无重复/统计,偶发不可分。第四,漏降级路径——只验主路径、fail-op 降级没验(最隐蔽)。第五,报告只写"通过"——无原始证据,FSAR 闭合时拿不出数据。

ISO 26262-4 §8 规定 SV 在 item 层面执行、按 SG 逐条覆盖。本例用 TC397+TLF35584+1EDI3035AS+SCT3080AL 400V/100kW EV 主驱逆变器(见 HV 逆变器概念)的三条 SG 建完整 SV 计划,演示从 SG 推导到验证项到 pass 准则的机械步骤。

SV 计划的错误往往不在格式,在语义:FTTI 起点、覆盖漏洞、版本漂移是三大杀手。

G1 — FTTI 计时起点写成"检测到故障":pass 准则写 DESAT 触发后 ≤200 ms 进 STO ——DESAT 触发本身已是 FDTI 末(检测完成点),FRTI 才是反应时间,两者之和 = FTTI。误以检测完成为起点 = 人为缩短了 FTTI 窗口 = 验证比实际宽松,真实场景下 FDTI 拉长(高温 DESAT 消隐延长)时可能 FAIL 但 SV 没抓到。修复:FTTI 计时点严格从 fault occurrence(ISO 26262-1 §3.71),用示波器采集故障注入触发沿作为 T0,而非 MCU FAULT 输出沿。

G2 — 漏 STO→ASC 降级路径验证:SG-01 SV 矩阵只有 SV-01(STO 主路径),无 SV-01b(STO 失效→ASC 降级)。STO 是主保护,ASC 是冗余——若 STO 路径自身有故障(VEE2 电源丢失、TC397 FAULT 引脚未连通等),系统应 fallback 到 ASC。漏验降级路径 = Safety Case SG-01 的 claim 没有 ASC 子 solution 节点 → I3 NC。修复:每条 ASIL D SG 至少两个验证项:主路径 + 独立降级路径;降级路径通过模拟主路径故障(如 FAULT 引脚短路)触发。

G3 — 验证项未标 ASIL 等级 → 证据等级错配:SV-01 验证 SG-01(ASIL D),若验证项本身没写"ASIL D I3 independent verification required",测试报告可能由项目内部 I2 工程师出具 → I3 评审时追: "ASIL D SG 需要 I3 独立验证,你的报告是 I2 的,证据等级不够"。修复:每个验证项字段加"Independence Level"列,ASIL D 项标 I3(第三方独立)或 ISO 26262-9 §9 认可的替代路径(documented evidence independence)。

G4 — 重复次数"20 次"无统计学来源:I3 评审追: "为什么 20 次?" 若无推导,会被认为是拍脑袋。修复:见 §8.3 Step 4 的 $n\ge \ln (1-C)/\ln (1-p)$ 推导;在 SV 计划中写明置信度目标 C=90%、可检出失效率目标 ≥10%,推导出 nmin≈22、取 20 作工程近似并注明统计假设,文件化入 SV 计划正文。

G5 — SV 计划版本与 Safety Concept 版本脱钩:SV 计划 v1.0 引用 SG-01 FTTI=200 ms,后来 Safety Concept 经 ECR 改为 FTTI=100 ms(L4 场景),SV 计划 v1.0 未跟版 → 所有按 200 ms pass 的验证项在新 FTTI 下可能 FAIL → Safety Case 引用 SV-RPT-01 v1 证据对应旧 FTTI 版 SG,版本不一致,I3 NC。修复:SV 计划封面标"本计划对应 Safety Concept v2.1,SG-01 FTTI=200 ms";ECR 变更 FTTI 时 SV 计划同步 ECR,受影响验证项标 re-test required。

G6 — HIL 只覆盖稳态工况,漏瞬态边界:SV-01 验证场景写"高速巡航工况"——稳态工况 FDTI 最小、最容易 pass;实际 hazardous operational situation(ISO 26262-3 §6.4)包含动态瞬态:急加速中、上坡制动瞬间、低速爬行。瞬态时电机电流大、扭矩估算误差更大,STO 触发时序更紧。漏掉瞬态 = HARA 标定 E4 的工况没有全覆盖。修复:SV 矩阵为 SG-01 增加"急加速工况注入"和"低速爬行注入"两个 SV-ID,各 10 次重复。

G7 — Mid-development SV 缺失,发现问题太晚:SV 计划规定 M17 Final Safety Validation(release 前)——若 SV 首次在 M17 做,发现根本架构问题(如 DESAT 路径误配)代价极高(几个月重新设计)。ISO 26262-4 §8.4.3 allows intermediate SV at system integration stages。修复:在 SV 计划加 Mid-development SV 节点(M10 HiL 部分验证:只验 HW 路径 SV-04;M14 集成验证:验 SV-01/02/03 主路径);M17 Final 做全部验证项完整跑。失败在 M10 代价比 M17 低 10×。

SV 计划面向"预期安全"场景,但 ASIL D 系统还会遭遇工况和系统边界的变化。

C1 — L4 自动驾驶升级(C 参数升为 C3):如果车辆升级到 L4 无人驾驶,HARA C 参数 C2→C3。SG-01/02(S3×E4×C3)仍为 ASIL D——无变化;SG-03(S2×E4×C3)从 ASIL B 升至 ASIL C(S2×E4×C3=ASIL C,按 ISO 26262-3 Table 4;S2 不等于 S3,不升到 ASIL D)。FTTI 可能压缩到 50 ms(驾驶员不在 loop,无人纠正窗更短)。对 SV 计划的影响:① SG-03 验证项 pass 时限从 500 ms → 50 ms,现有 SV-03 失效;② HIL 故障注入时序精度要求提高(50 ms 仅 5 个 10 ms ADC 周期)——需升级为实时示波器触发采集;③ SG-03 独立性要求从 ASIL B(I1)升到 ASIL C(I2),需升级 SV-03 的测试独立性,但不需要 I3。影响评估:SV 计划局部重写,SG-03 及其验证项全部重版。

C2 — OTA 安全概念更新触发 SV 重验:整车 OTA 升 TC397 Safety Manager 软件,若 FTTI 相关诊断时限(FDTI SW 路径)改变,SV 计划中所有依赖 SW FDTI 的验证项 pass 准则需评估:① FDTI 缩短 → pass 准则时限收紧,原 SV 数据仍有效(更严格 pass 对应宽松 FTTI);② FDTI 拉长 → pass 准则时限宽松(危险),需重新 SV 验证。ISO 26262-8 OTA 要求变更影响评估:建立"SV-impact 矩阵"(哪些 SV-ID 绑定了哪些 SW 模块版本),OTA ECR 时自动触发受影响 SV-ID 的 re-test。

C3 — FTTI 压缩至 50 ms 场景下 HIL 精度不足:若 OEM 基于实车测试重新标定 SG-01 FTTI 为 50 ms,HIL(SCALEXIO)故障注入的时序误差 ±2 ms + 通讯延迟 ±5 ms = 总误差 ±7 ms = 14% of FTTI。pass 准则时限 35 ms(70%×50 ms)—— HIL 时序误差已占 pass 时限的 20%,测试结果不可靠。修复路径:① Bench 实板测试取代 HIL 作为主验证路径(示波器直采电气信号,时序精度 <10 ns);② HIL 仅用于工况覆盖验证(多场景回归),不用于 FTTI 时序计量;③ SV 计划注明"FTTI ≤100 ms 时,FTTI 时序验证主环境 = Bench 实板,HIL 辅助"。