HW 安全需求(HSR)写作工程化深度 — 从 TSR 派生 + 可验证性 + 接 FMEDA/test + I3 评审

HSR 坐在 ISO 26262-5,上游是 TSR、下游分两叉:一叉到 HW 设计(指导电路实现),一叉到 FMEDA + HW test(验证是否达标)。这个"一上两下"的位置决定了 HSR 写作的核心约束——每条 HSR 必须三向接得住:向上追 TSR(它为哪条技术安全需求服务)、向下被 FMEDA 量化(它贡献多少 DC)、被 test 验证(怎么证它满足)。

下图把 HSR 的派生来源和两条下游验证链画在一起——写 HSR 前要先在脑子里立住这张"三向接口图"。

写作 SOP 分 4 步,每步产出 HSR 规范的一部分:

1. 拆 TSR:把每条 TSR 拆成它要求的 HW 层行为/约束(一条 TSR 通常派生多条 HSR)。
2. 写 HSR 陈述:每条用"硬件应在[条件]下[可测行为]"句式,绑定具体安全机制。
3. 挂验证锚:每条 HSR 标目标 DC(由 ASIL 反推)+ 验证方法(FMEDA / fault injection / bench test)。
4. 建双向 link:上挂 TSR ID、下留 FMEDA 条目 + test case 占位。

报告主体的最小单元是一条 HSR 条目。和 hazard 条目一样,字段缺一就在审计处断链。6 字段:

下图是一条 HSR 从 TSR 派生到验证锚的字段流转。

6 字段 + 主驱"扭矩监控"worked(承 HARA 那条 ASIL D SG → TSR → HSR):

• ① TSR 来源:TSR-03 — 安全 MCU 独立监控扭矩,超限触发 STO(引 TSR ID)
• ② 需求陈述:扭矩采样 ADC 应在每个 1 ms 周期完成转换,转换错误应被 ADC 自检在 ≤2 周期内检出(可测:有周期、有检出时限)
• ③ 安全机制:ADC 内建自检(BIST)+ 范围合理性检查(绑定到具体 SM)
• ④ 目标 DC:≥99%(由 FMEDA 把 ASIL D 的 SPFM≥99% 目标按各元件失效率 λ 分配到本元件;采样链这类主贡献元件常落 ≥99%,非一律 99%)
• ⑤ 验证方法:FMEDA 算 ADC 失效模式 DC;fault injection 注入 ADC stuck-at,验证 2 周期内检出
• ⑥ 双向 link:上:TSR-03;下:FMEDA-ADC-01 + TC-ADC-FI-07

注意 ② 和 ④⑤⑥ 的配合:陈述给可测的量(1 ms / 2 周期),验证锚给怎么测 + 测到什么程度(DC≥99% + FI 用例)。这一组就是 HSR "可验证"的全部含义。

HSR 不是凭空写的硬件功能,是 TSR 的机械派生。派生律和 FSR→TSR 同源:HSR 集合对 TSR 完整覆盖且不超出。少了——TSR 的某个 HW 含义没落实,FMEDA 会缺一块;多了——引入了无 TSR 授权的硬件复杂度,I3 追"这条 HSR 为哪条 TSR 服务"答不上。

实操上一条 TSR 派生多条 HSR,因为 TSR 是"系统/技术行为",落到硬件要拆成 多个器件级约束。比如 TSR-03"独立监控扭矩"派生:HSR(采样链精度 + 周期)+ HSR(监控通道独立于主控)+ HSR(超限到 STO 的硬件路径)。漏掉"通道独立"这条,FMEDA 算 CCF(共因失效)时就没有独立性依据——这是派生不全最隐蔽的后果。

可验证性是 HSR 写作和 HARA rationale 并列的真难点。判据很硬:一条 HSR 可验证,当且仅当能据它直接设计出一项 pass/fail 明确的 test。下面三组"被打回 → 改成可测",看清差别不在"写没写安全机制",在"能不能测":

模糊形容词 — 打回写法 ADC 应可靠工作。test 工程师问:"可靠到什么程度?怎么算 fail?" 无法设计用例。可测写法 ADC 转换错误应在 ≤2 个采样周期(2 ms)内被自检检出并置故障标志。差别:后者给了 可测时限 + 可观测输出(故障标志),FI 用例直接据此写。

缺目标值 — 打回写法 应有诊断覆盖扭矩采样故障。I3 追:"覆盖多少?够 ASIL D 吗?" 无法判达标。可测写法 扭矩采样链诊断覆盖率应 ≥99%(由 FMEDA 把 ASIL D 的 SPFM≥99% 目标按 λ 贡献分配得到,随元件不同而变,非一律 99%),由 FMEDA 量化。差别:后者把"有诊断"变成 可量化目标 + 量化方法,FMEDA 能直接 claim。

验证方法悬空 — 打回写法 应防止扭矩信号被干扰(没说怎么证)。可测写法 扭矩信号链应满足 ISO 11452-2 辐射抗扰 ≥100 V/m(ISO 11452-4 BCI 100 mA),由 bench EMC immunity test 验证;受扰时合理性检查应在 1 周期内拒绝异常值。差别:后者绑定 具体 test 标准 + 失效时的可观测行为(注:抗扰用 ISO 11452 系列的 V/m / mA 严酷度;CISPR 25 是发射限值标准、其 Class 5 不是抗扰等级)。

三组的共性,就是 HSR 可验证性的终极判据:把需求写到"换个 test 工程师拿这条 HSR,不问你就能写出 pass/fail 明确的用例"的程度。写不到这一步的 HSR,FMEDA 算不了 DC、test 设计不出,等于没写。

I3 评审 HSR 规范(并入 M2 系统里程碑)的 6 查点。下图映射到 HSR 规范对应部分。

6 个查点:

1. 派生完整:HSR 集合是否完整覆盖所有 TSR 的 HW 含义?有无 TSR 漏派生?
2. 可追溯:每条 HSR 上有 TSR ID、下有 FMEDA 条目 + test case?
3. 可验证:每条 HSR 是否可据以设计 pass/fail 明确的 test?(主查)
4. DC 目标:每条带诊断的 HSR 是否标了目标 DC + 反推依据(ASIL)?
5. 独立性:要求"独立通道"的 HSR 是否给了 FMEDA 算 CCF 的独立性依据?
6. 验证方法:每条 HSR 的验证方法(FMEDA/FI/bench)是否明确、可执行?

第一,模糊形容词(可靠/稳定/充分)——不可测,占 HSR NC 大头。第二,写成功能清单而非需求(要有 DESAT)——没说性能指标和验证,FMEDA 无从量化。第三,缺目标 DC——有诊断但没目标值,无法判 ASIL 达标。第四,派生漏"独立性"——只写功能、漏通道独立,FMEDA 算 CCF 缺依据(最隐蔽)。第五,验证方法悬空——不写怎么证,test 阶段才发现需求不可验,返工代价高。