SW 安全需求(SSR)写作工程化深度 — 从 TSR 派生 + 可验证性(unit test/MC-DC) + FFI + I3 评审
本质与导读
本质 SSR 是 TSR 在软件层的落地、HSR 的软件对偶,核心不在概念而在工程纪律:一条不带覆盖率目标和判 fail 标准的 SSR(如"软件应正确计算扭矩")测试工程师没法验,等于没写,I3 直接判 NC。要把每条 SSR 写成可验证、可追溯的工作产物——绑定验证方法(unit test + 覆盖率,ASIL D 要 MC-DC 100% + MISRA 静态分析)和上游 TSR link。
1. SSR 在 V-cycle 的位置 + 写作 SOP
SSR 坐在 ISO 26262-6,上游是 TSR、下游分两叉:一叉到 SW 架构/单元实现,一叉到 unit test + 覆盖率 + 静态分析验证。和 HSR 的"三向接得住"完全同构——每条 SSR 必须 向上追 TSR、向下被 test 覆盖、被覆盖率工具量化。
下图把 SSR 的派生来源和两条下游链画在一起。
写作 SOP 4 步,同 HSR 同构:
- 拆 TSR:把每条 TSR 拆成 SW 层行为/约束(一条 TSR 派生多条 SSR)。
- 写 SSR 陈述:用"软件应在[条件]下[可测行为]"句式,绑定具体 SW 安全机制。
- 挂验证锚:每条标覆盖率目标(ASIL 反推:D→MC-DC 100%)+ 验证方法(unit test / 集成 test / 静态分析)。
- 建双向 link:上挂 TSR ID、下留 test case + 覆盖率报告占位。
2. SSR 字段模板 + worked
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 完全同理。
3. 从 TSR 派生 SSR 的"覆盖且不超出" + FFI 特殊点
派生律和 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 的"通道独立性"那个隐蔽点)。
4. SSR 可验证性 — 不可测 vs 可测(判断力核心)
判据和 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 设计不了 = 等于没写。
5. ASIL D SSR Review — I3 的 6 个查点
I3 评审 SSR 规范(并入 M2)的 6 查点,和 HSR 同构,④⑤ 针对软件特性:
6 个查点:
- 派生完整:SSR 是否完整覆盖所有 TSR 的 SW 含义?有无漏派生(尤其 FFI)?
- 可追溯:每条 SSR 上有 TSR ID、下有 test case + 覆盖率报告?
- 可验证:每条是否可据以写 pass/fail 明确的 test?(主查)
- 覆盖率目标:每条是否标了覆盖率目标(ASIL D→MC-DC)+ 依据?
- FFI:混合 ASIL 是否派生了内存/时间隔离 SSR + 验证方法?
- 验证方法:unit/集成 test + 静态分析是否明确?
6. 工程陷阱 — G1-G7
SSR 写作翻车几乎都在"写了但不可测"和"结构正确但 ASIL 分解语义错"两类。
G1 模糊动词
正确/合理/充分 这类形容词让 SSR 成为文学性声明而非可验证需求。写法 软件应正确计算扭矩 令测试工程师无法设计用例:边界在哪、失效怎么算、哪些路径需覆盖,全不知道。改写必须给出可测量的 谓词、边界值、可观测输出——扭矩合理性检查函数应在每个 1 ms 控制周期校验请求扭矩 ∈ [-Tmax, Tmax],超限应在本周期内置 fault 标志并请求 STO。动词换成"校验"并绑定边界和输出之后,pass/fail 判据自动清晰。
G2 功能描述非需求
要做范围检查 描述"做什么功能"而非"需求行为"——缺了调用条件、边界参数、覆盖率目标、验证方法。功能描述是设计语言,SSR 是验证语言:每条必须能直接对应一组 test case,功能描述做不到。典型 NC:I3 问"这条怎么测?达标标准?",答不出。
G3 缺覆盖率目标
ASIL D 对软件单元测试要求 MC-DC 100%(ISO 26262-6:2018 Table 9 highly recommended),但大量 SSR 只写"充分测试"或不写。没有覆盖率目标意味着无法判断验证是否足够,且覆盖率工具的报告无锚点可比对。写法:每条 ASIL D 安全函数的 SSR 必须标 单元 MC-DC 覆盖率 100%(依据 26262-6 Table 9)+覆盖率工具报告占位。ASIL B 对应 statement coverage 100%(highly recommended),写法不同;分解场景见 C1。
G4 漏 FFI 派生
混合 ASIL 系统(ASIL D 安全软件与 QM 软件共 MCU)中,TSR 隐含"QM 不干扰安全"但绝大多数设计师不把它派生成显式 SSR。漏掉的结果是:MPU 配置可能有了,但没有 SSR 明确隔离粒度 + 验证手段 + fault injection 用例。FFI 是功能安全软件 I3 评审中追 NC 频率最高的隐蔽派生点,一条全局"MPU 隔离 QM"SSR 远不够,见 C2。
G5 验证方法悬空
SSR 写了覆盖率目标,但不说用什么工具/方法来证——应达 MC-DC 100% 后面没有"由 LDRA/VectorCAST/Cantata 等工具报告佐证"的占位。验证方法悬空意味着竣工时 I3 无法确认报告来源和工具可信度;静态分析(MISRA-C:2012 + 编码规范)同样需要在 SSR 里明示。
G6 ASIL 分解混淆覆盖率目标
ASIL D→B(D)+B(D) 分解后,只要分解的独立性/FFI 已按 Part 9 充分论证,各 B(D) 侧元件即按其分配的 ASIL B 开发,结构覆盖目标为 branch + statement 100%(26262-6 Table 9:MC-DC 仅对 ASIL D 为 highly recommended,对 ASIL B 不强制),与 C1 覆盖率分叉一致。常见误区有两个方向:① 误把 B(D) 的 (D) 标注读成"仍须走 ASIL D 的 MC-DC 100%"——(D) 只标注该元件源自 ASIL D 安全目标、用于追溯与独立性论证,并不抬高其自身覆盖率等级;② 反向,若两条 B(D) 通道的独立性未经 Part 9 有效论证,则分解不成立、元件退回 ASIL D,此时才须补 MC-DC 100%。覆盖率目标随分解有效性确定,两个方向混淆都会在 I3 评审时导致大范围 NC 重测。
7. 工作极限 — C1-C3
SSR 写作的三个边界场景,在正常配置下看不到,但真实项目中各自都是独立 NC 来源。
C1 ASIL 分解时的覆盖率分叉
当功能分解为 ASIL C(D)+ASIL B(D) 双通道(如 TC397 Lockstep Core 承载 C(D) 侧、独立 QM QSPI/SPI 监控链承载 B(D) 侧),两条通道的 SSR 覆盖率目标应分别标注:C(D) 侧 → MC-DC 100%;B(D) 侧 → branch coverage 100%+statement 100%(Table 9 ASIL C/B 各自标准)。若一律写 MC-DC 100%,则 B(D) 侧过度要求,增加不必要验证负担且 ASIL 分解证明结构性冲突;若一律写"充分",则 C(D) 侧合规性无法判定。SSR 模板需分通道填写覆盖率字段,并交叉引用 ASIL 分解文件。
C2 遗留 QM 库的隐式 FFI 边界
当项目从旧 QM ECU 迁移 AUTOSAR MCAL SPI 驱动等 QM 库,新 ASIL D 扭矩计算函数直接调用该 QM 驱动时,产生隐式信息流:QM 驱动的返回值、栈帧、共享 SRAM 都可能污染 ASIL D 执行路径。一条全局"MPU 隔离 QM 内存"SSR 不能覆盖函数调用边界——QM 函数的返回值经由寄存器传递,绕过 MPU。正确做法:为每个 QM→ASIL D 调用点写独立 FFI SSR,绑定"入参校验 + 返回值范围核"的 defensive wrapper,并用 fault injection 注入 QM 返回值异常验证 wrapper 拦截。
C3 覆盖率工具 TQL 闭环
MC-DC 100% 结论的可信度上限 = 覆盖率工具的可信度。ISO 26262-8:2018 §11 要求:对 TI=1(Tool Impact 高) 且 TD=1(Tool Error Detection 低)的工具,TCL(Tool Confidence Level)= 3,必须走 TQL-2 资质流程——包括工具使用文件、验证计划、anomaly 报告跟踪。当 SSR 写"由工具证明 MC-DC 100%"但团队未完成该工具的 TQL-2 评估时,竣工审计(M4/ASIL D)会产生一条结构性 NC;典型补救周期 3-6 个月,远超项目缓冲。应在 SSR 写作阶段同步登记工具评估 action item,不能等到测试阶段才发现。
缩写表
| 缩写 | 全称 | 含义 |
|---|---|---|
| SSR | Software Safety Requirement | 软件安全需求 |
| TSR | Technical Safety Requirement | 技术安全需求(SSR 上游) |
| MC-DC | Modified Condition/Decision Coverage | 修正条件/判定覆盖(ASIL D 要求) |
| FFI | Freedom From Interference | 无干扰(混合 ASIL 隔离) |
| MPU | Memory Protection Unit | 内存保护单元 |
| MISRA | MISRA-C | 车规 C 编码标准(静态分析) |
| STO | Safe Torque Off | 安全转矩关断 |
| FI | Fault Injection | 故障注入(验证手段) |
| I3 | Independent Assessment | 独立评估 |
| NC | Non-Conformity | 不符合项 |
核心要点
- SSR 是 TSR 的软件层派生、HSR 的软件对偶;验证手段换成 unit test + 覆盖率(MC-DC)+ 静态分析
- 6 字段模板:TSR 来源 / 可测陈述 / SW 安全机制 / 覆盖率目标(ASIL D → MC-DC 100%,26262-6 Table 9)/ 验证方法 / 双向 link
- 可验证终极判据同 HSR:据这条 SSR 能写出 pass/fail 用例 + 定覆盖率目标;写不到 = 等于没写
- 软件特殊点:FFI(混合 ASIL 的内存/时间隔离)必须派生成显式 SSR,漏掉最隐蔽(G4);QM 库调用点须逐个写 FFI SSR(C2)
- G6 ASIL 分解混淆:B(D) 侧安全函数覆盖率目标需按分解论证确定,不能一律降到 statement coverage(C1 覆盖率分叉)
- G7 工具资质:MC-DC 工具须完成 TQL-2 评估(26262-8 §11),与 SSR 写作并行推进(C3 闭环)
Cross-references
- ← 索引
- HW 安全需求(HSR)写作 — 硬件对偶(本页是软件侧)
- FSR/TSR 写作 — SSR 的上游
- HARA 报告写作 — 同源写作 deep,SG→TSR→SSR 一条链
- ISO 26262-6 软件层 — Part 6 概念基础
- MISRA-C 2012 深度 — SSR 的静态分析验证依据
- ISO 26262 V-cycle 全栈 hub — SSR 在 Part 6