SW 安全需求(SSR)写作工程化深度 — 从 TSR 派生 + 可验证性(unit test/MC-DC) + FFI + I3 评审

SSR 坐在 ISO 26262-6,上游是 TSR、下游分两叉:一叉到 SW 架构/单元实现,一叉到 unit test + 覆盖率 + 静态分析验证。和 HSR 的"三向接得住"完全同构——每条 SSR 必须 向上追 TSR、向下被 test 覆盖、被覆盖率工具量化。

下图把 SSR 的派生来源和两条下游链画在一起。

写作 SOP 4 步,同 HSR 同构:

1. 拆 TSR:把每条 TSR 拆成 SW 层行为/约束(一条 TSR 派生多条 SSR)。
2. 写 SSR 陈述:用"软件应在[条件]下[可测行为]"句式,绑定具体 SW 安全机制。
3. 挂验证锚:每条标覆盖率目标(ASIL 反推:D→MC-DC 100%)+ 验证方法(unit test / 集成 test / 静态分析)。
4. 建双向 link:上挂 TSR ID、下留 test case + 覆盖率报告占位。

SSR 条目 6 字段,和 HSR 同构(④ 把"目标 DC"换成"覆盖率目标"):

6 字段 + 主驱"扭矩合理性检查"worked(承 HARA→TSR→HSR 那条链的软件侧):

• ① TSR 来源:TSR-03 — 安全 MCU 独立监控扭矩,超限触发 STO(引 TSR ID)
• ② 需求陈述:扭矩合理性检查函数应在每个 1 ms 控制周期校验请求扭矩 ∈ [-Tmax, Tmax],超限应在本周期内置 fault 标志并请求 STO(可测:有周期、有边界、有可观测输出)
• ③ SW 安全机制:输入范围检查 + 控制流监控(确保检查函数被调用)
• ④ 覆盖率目标:单元 MC-DC 覆盖率 100%(ASIL D 反推自 26262-6 Table 9)
• ⑤ 验证方法:unit test 覆盖边界/超界/调用缺失;覆盖率工具测 MC-DC;静态分析查 MISRA 合规
• ⑥ 双向 link:上:TSR-03;下:TC-TORQ-RANGE-01..05 + COV-TORQ-01

注意 ② 给可测的量(周期 + 边界 + 输出)、④⑤⑥ 给覆盖率目标 + 怎么测——这一组就是 SSR "可验证"的全部含义,和 HSR 完全同理。

派生律和 HSR/FSR→TSR 同源:SSR 集合对 TSR 完整覆盖且不超出。

软件层有一个 HW 没有的特殊派生点:Freedom From Interference(FFI,无干扰)。当安全 SW(ASIL D)和非安全 SW(QM)跑在同一 MCU,TSR 隐含一条"QM 软件不得干扰安全软件"——这必须派生成显式 SSR:内存隔离(MPU)、时间预算监控(防 QM 死循环饿死安全任务)、信息流保护。漏掉 FFI 派生,是软件 SSR 最隐蔽的不全——混合 ASIL 系统在 I3 必被追(对应 HSR 的"通道独立性"那个隐蔽点)。

判据和 HSR 一字不差:一条 SSR 可验证,当且仅当能据它直接写出 pass/fail 明确的 test + 定出覆盖率目标。三组"被打回 → 改可测":

模糊动词 — 打回写法 软件应正确计算扭矩。test 工程师问:"正确的边界?怎么算错?测哪些路径?" 无法设计。可测写法 扭矩合理性检查应在每周期校验请求值 ∈ [-Tmax, Tmax],超界在本周期置 fault;unit test 覆盖 边界值/超界/正常 三类,MC-DC 100%。差别:后者给了 可测边界 + 可观测输出 + 覆盖率目标。

缺覆盖率目标 — 打回写法 应充分测试该函数。I3 追:"充分=多少?ASIL D 要 MC-DC 吗?" 无法判达标。可测写法 该安全函数单元测试应达 MC-DC 100%(ASIL D,26262-6 Table 9 highly recommended),由覆盖率工具报告佐证。差别:把"充分"变成 可量化覆盖率 + 标准依据。

FFI 悬空 — 打回写法 QM 模块不应影响安全模块(没说怎么隔离、怎么证)。可测写法 安全任务与 QM 任务间应 MPU 内存隔离(违规触发 exception)+ 安全任务时间预算监控(超时触发 SafeState);FFI 由 fault injection 注入 QM 越界访问/死循环验证。差别:绑定 隔离机制 + 验证手段(FI),把抽象的"不干扰"变成可测。

终极判据和 HSR 同:写到"换个测试工程师据这条 SSR,不问就能写出 pass/fail 用例 + 知道覆盖率目标"的程度。写不到,覆盖率算不出、test 设计不了 = 等于没写。

I3 评审 SSR 规范(并入 M2)的 6 查点,和 HSR 同构,④⑤ 针对软件特性:

6 个查点:

1. 派生完整:SSR 是否完整覆盖所有 TSR 的 SW 含义?有无漏派生(尤其 FFI)?
2. 可追溯:每条 SSR 上有 TSR ID、下有 test case + 覆盖率报告?
3. 可验证:每条是否可据以写 pass/fail 明确的 test?(主查)
4. 覆盖率目标:每条是否标了覆盖率目标(ASIL D→MC-DC)+ 依据?
5. FFI:混合 ASIL 是否派生了内存/时间隔离 SSR + 验证方法?
6. 验证方法:unit/集成 test + 静态分析是否明确?

第一,模糊动词(正确/合理/充分)——不可测,占 SSR NC 大头。第二,写成功能描述非需求(要做范围检查)——没说边界、覆盖率、验证。第三,缺覆盖率目标——ASIL D 不写 MC-DC,无法判达标。第四,漏 FFI——混合 ASIL 只写功能、漏内存/时间隔离,I3 必追(最隐蔽)。第五,验证方法悬空——不写 test/覆盖率/静态分析,集成阶段才发现不可验。