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 100 ms,安全状态 STO(引 SG ID)
• ② 验证场景/注入:整车 HIL,高速巡航工况,注入扭矩传感器 stuck-at-high(场景 + 故障注入点)
• ③ 期望整车响应:整车应检出并进 STO,实际扭矩偏差全程 ≤ ±10% 额定(整车级可观测响应)
• ④ pass 准则:STO 在故障注入后 ≤100 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 应 ≤100 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 闭合时拿不出数据。