4. 安全需求分解与追溯
整车安全目标（Vehicle Safety Goal）通常以“避免非预期制动”“避免转向助力丢失”这类整车级危害描述出现，它本身不可直接实现，必须逐层分解为系统、硬件、软件可执行的需求。Bosch 在底盘域（ESP、iBooster、EPS、线控转向）实践中，把这一过程称为“安全需求分解与追溯”，其核心产物是需求追溯矩阵（Requirements Traceability Matrix, RTM），并借助 DOORS、DOORS Next 或 Polarion 等需求管理工具维护。
一、分解的层级与语义边界
ISO 26262 给出的分解链是：安全目标 → 功能安全需求（FSR）→ 技术安全需求（TSR）→ 硬件/软件安全需求。每一层都要回答不同的问题：
- 安全目标：整车层面要避免什么危害，对应 ASIL 等级与安全状态（Safe State）。
- 功能安全需求（FSR）：功能层面如何避免，例如“当检测到制动踏板位置信号与主缸压力不一致超过阈值时，应在 100 ms 内进入降级模式”。
- 技术安全需求（TSR）：系统层面用什么机制实现，例如“ESP 控制器应通过双通道独立采集踏板位置，并在 20 ms 内完成交叉校验”。
- 硬件/软件安全需求：具体到 MCU 的 ADC 采样周期、看门狗喂狗窗口、CAN 报文 E2E 保护、软件诊断周期等。
分解不是简单“抄写”，而是把上一层的“做什么”翻译成下一层的“怎么做”，同时把 ASIL 等级、FTTI（故障容错时间间隔）、安全状态等约束一并传递。若某条 FSR 被分解为多条 TSR，则这些 TSR 的 ASIL 等级之和必须覆盖原 FSR 的等级（ASIL 分解规则）。
二、追溯矩阵的字段设计
RTM 不是一张“好看的表”，而是一份可审计的证据链。Bosch 项目里常用的字段包括：需求 ID、需求文本、层级、ASIL、来源（父需求 ID）、验证方法、验证状态、责任人、变更历史。下面给出一个可直接参考的示例片段（示例数据，非实测）：
| 需求 ID | 层级 | 需求摘要 | ASIL | 父需求 | 验证方法 |
|---|---|---|---|---|---|
| SG-001 | 安全目标 | 避免非预期制动导致车辆失稳 | D | — | 危害分析 |
| FSR-012 | 功能安全需求 | 踏板与主缸压力不一致时进入降级 | D | SG-001 | 功能测试 |
| TSR-045 | 技术安全需求 | 双通道采集踏板位置并交叉校验 | D | FSR-012 | HIL 测试 |
| SW-118 | 软件安全需求 | ADC 采样周期 ≤ 5 ms，校验窗口 20 ms | D | TSR-045 | 单元测试 |
| HW-073 | 硬件安全需求 | 双路独立供电与 ADC 参考电压监测 | D | TSR-045 | 硬件在环 |
注意：父需求字段是追溯的“骨架”，没有它，矩阵就退化成普通需求列表。工具中通常用“链接（Link）”实现，DOORS 里叫 traceability link，Polarion 里叫 suspect link 与 derived link。
三、用 DOORS 建立追溯的实操要点
在 DOORS 中，建议按“模块（Module）”组织层级：SG 模块、FSR 模块、TSR 模块、SW/HW 模块。每条需求作为对象（Object），用“Link”建立父子关系。关键操作包括：
- 为每个模块定义属性（Attribute），如 ASIL、Verification Method、Status，并设置枚举值，避免自由文本。
- 使用“Analysis → Traceability”生成追溯视图，检查是否存在“孤儿需求”（无父）或“悬空需求”（无子）。
- 开启 suspect link：当父需求文本变更时，子需求自动标记为可疑，提醒工程师复核。
- 导出 RTM 时，用 DXL 脚本或 ReqIF 交换格式，保证与下游测试管理工具（如 Test Manager）对齐。
四、分解与追溯的常见陷阱
第一，层级混淆：把“软件诊断周期 10 ms”直接挂在安全目标下，跳过了 FSR 与 TSR，导致 ASIL 传递断裂。第二，追溯方向单一：只做“父→子”正向追溯，忽略“子→父”反向追溯，变更时无法评估影响范围。第三，验证方法缺失：需求写了但没写怎么验证，RTM 变成“需求清单”而非“证据链”。第四，工具链接与文本脱节：链接存在但需求文本已过期，suspect link 未处理，审计时被判定为无效追溯。
五、从需求到验证的闭环
分解的终点不是“写完需求”，而是“可验证”。每条 SW/HW 安全需求都应能映射到具体的测试用例或分析活动。例如 SW-118 对应“ADC 采样周期测试用例 TC-118”，HW-073 对应“双路供电故障注入测试 TC-073”。在 DOORS 中，可用“验证方法”属性与测试管理模块建立链接，形成“需求—测试”双向追溯。这样，当 FSR-012 发生变更时，工具能自动列出受影响的 TSR、SW/HW 需求及测试用例，支撑变更影响分析。
上图展示了从安全目标到验证用例的双向追溯骨架。正向箭头表示分解，反向虚线表示追溯与变更影响分析，底部验证层是闭环的终点。实际项目中，这张图在 DOORS 里由链接关系自动生成，而不是手工绘制。
六、变更影响分析示例
假设 FSR-012 的阈值从“100 ms”改为“80 ms”。在 DOORS 中执行影响分析后，系统列出：TSR-045（校验窗口需同步调整）、SW-118（采样周期需重新评估）、HW-073（ADC 响应时间需复核）、TC-118 与 TC-073（测试用例需更新）。工程师逐条确认并更新 suspect link，最终形成变更记录。这一过程正是追溯矩阵存在的意义：让“改一处”不再靠人脑记忆，而是靠工具链自动暴露影响面。
总结来说，安全需求分解与追溯的关键在于：层级语义清晰、ASIL 传递完整、双向链接可查、验证方法可执行。DOORS 或同类工具只是载体，真正决定质量的是工程师对“每条需求为什么存在、由谁实现、如何验证”的持续追问。