4. 安全目标与安全需求：从危害导出安全目标，定义功能安全需求与技术安全需求
好，咱们进入第四讲。前面我们做了 HARA，拿到了 ASIL 等级和一堆危害事件。但光有危害还不够——你得告诉开发团队「到底要防什么」和「怎么防」。这就是从危害到安全目标，再到安全需求的转化过程。
我个人习惯把这一步叫做「翻译层」。把安全分析的输出，翻译成工程团队能直接执行的输入。翻译得好，项目顺风顺水；翻译得差，后期返工能让你怀疑人生。
4.1 从危害到安全目标
安全目标（Safety Goal），说白了就是最高层级的、针对整车或系统层面的安全要求。它回答一个核心问题：这个危害，我们打算怎么避免？
每个危害事件，至少对应一个安全目标。有时候一个安全目标可以覆盖多个危害，但别贪多，我见过有人试图用一个安全目标覆盖所有危害，结果评审时被怼得体无完肤。
4.1.1 安全目标的写法
安全目标的句式很固定，我一般这么写：
安全目标模板：
「[系统/功能] 应避免 [危害描述]，在 [运行场景] 下，达到 [ASIL 等级]。」
举个例子，咱们拿「ACC 自适应巡航」来说：
| 危害事件 | 安全目标 | ASIL |
|---|---|---|
| ACC 误加速导致追尾 | ACC 系统应避免非预期的加速请求，在高速跟车场景下 | ASIL C |
| ACC 无法识别静止目标 | ACC 系统应能正确识别前方静止目标，在直道场景下 | ASIL B |
| ACC 制动失效 | ACC 系统应保证制动请求的可靠执行，在减速场景下 | ASIL D |
嗯，这里要注意：安全目标不要写具体的技术方案。比如「用双核锁步来实现制动请求的校验」——这就写得太细了，那是后面技术安全需求的事。安全目标只关心「要避免什么」，不关心「怎么避免」。
4.1.2 安全目标的属性
每个安全目标，除了描述和 ASIL，还得带上几个关键属性：
- ID：唯一编号，方便追溯。我习惯用 SG-001 这种格式。
- 来源：对应的危害事件 ID。
- ASIL：继承自危害事件的 ASIL 等级。
- FTTI：容错时间间隔。这个很重要，决定了你的监控和响应要多快。
- 安全状态：系统进入安全状态后的行为，比如「降级到 30km/h 限速」或「切断动力输出」。
个人经验： 我建议在安全目标阶段就把 FTTI 和安全状态定下来。别拖到后面，否则技术安全需求写起来会非常痛苦。我曾经有个项目，安全目标里没写 FTTI，结果开发团队自己猜了一个 100ms，最后测试发现根本做不到，整个方案推倒重来。
4.2 功能安全需求
安全目标定好了，下一步就是把它拆成功能安全需求（Functional Safety Requirements, FSR）。
功能安全需求，是分配给系统架构层面的安全要求。它开始涉及「怎么做」了，但还停留在功能层面，不涉及具体的硬件选型或软件实现。
4.2.1 FSR 的分解原则
我一般遵循这几个原则：
- 每个安全目标至少分解出 1 个 FSR。复杂的安全目标可能需要多个 FSR 来覆盖。
- FSR 要可验证。写完之后问自己一句：「这个需求我能测试吗？」如果不能，说明写得太虚了。
- FSR 要分配责任人。谁负责实现？谁负责验证？别让需求悬空。
举个例子，从上面那个「ACC 应避免非预期加速」的安全目标，可以分解出：
- FSR-01：ACC 系统应检测到加速踏板位置传感器信号异常，并在 50ms 内进入安全状态。
- FSR-02：ACC 系统应校验目标加速度指令的合理性，当指令超过物理极限时，拒绝执行。
- FSR-03：ACC 系统应提供独立的监控模块，用于检测主控制器的计算错误。
你看，这些需求已经开始有「检测」「校验」「监控」这样的动作了，但还没说用哪个芯片、跑什么算法。
4.2.2 ASIL 分解与冗余
有时候一个安全目标的 ASIL 等级太高（比如 ASIL D），直接实现成本太高。这时候可以用 ASIL 分解。
ASIL 分解的核心思想：把高 ASIL 的需求，拆成两个或多个低 ASIL 的需求，通过冗余和独立性来保证整体安全性。
ASIL 分解示例：
原始需求：ASIL D
分解后：
- 通道 A：ASIL C
- 通道 B：ASIL C
- 独立性要求：通道 A 和 B 之间无共因失效
整体等效：ASIL D
但注意，分解不是随便拆的。你得证明两个通道之间是独立的——没有共享的电源、时钟、软件库，甚至开发团队最好都是两拨人。我在项目里见过有人把 ASIL D 分解成两个 ASIL B，结果两个通道跑在同一个 MCU 上，评审时直接被安全专家怼回去了。
4.3 技术安全需求
技术安全需求（Technical Safety Requirements, TSR），是 FSR 的进一步细化。它开始涉及具体的技术实现方案了。
TSR 的受众是谁？是硬件工程师、软件工程师、系统工程师。所以 TSR 必须写得足够具体，让工程师拿到就能干活。
4.3.1 TSR 的典型内容
我列几个常见的 TSR 类型：
| 类型 | 示例 |
|---|---|
| 检测机制 | 使用 CRC-32 校验传感器数据，每 10ms 执行一次 |
| 响应时间 | 从故障发生到进入安全状态，不超过 100ms |
| 冗余设计 | 主控制器和监控控制器使用独立的电源轨和时钟源 |
| 故障容错 | 当主控制器失效时，监控控制器应在 20ms 内接管控制权 |
| 诊断覆盖 | 内存自检的故障覆盖率应 ≥ 90% |
举个例子，从 FSR-01 可以细化出：
- TSR-01.1：加速踏板位置传感器信号通过两路 ADC 采样，两路采样值偏差超过 5% 时判定为故障。
- TSR-01.2：故障判定后，系统在 10ms 内切断加速指令输出，并在 50ms 内将车速降至 30km/h 以下。
- TSR-01.3：故障状态通过 CAN 总线发送诊断报文，ID 为 0x123，周期 100ms。
你看，到了 TSR 层面，连 ADC 采样、CAN 报文 ID 都出来了。这就是工程师要的东西。
避坑指南： 我曾经见过一个项目，TSR 写得跟 FSR 差不多，全是「系统应检测故障」这种空话。结果软件工程师不知道用什么算法检测，硬件工程师不知道用什么电路实现。最后项目延期了三个月，就是因为需求没写透。记住：TSR 要写到「拿到就能干活」的程度。
4.4 安全需求的可追溯性
安全需求不是写出来就完事了。你得保证每条需求都能追溯到源头，也能追踪到实现和测试。
ISO 26262 要求建立完整的追溯链：
- 危害 → 安全目标：每个危害至少对应一个安全目标。
- 安全目标 → FSR：每个安全目标至少分解出一个 FSR。
- FSR → TSR：每个 FSR 至少细化出一个 TSR。
- TSR → 实现：每个 TSR 对应到具体的硬件/软件模块。
- TSR → 测试用例：每个 TSR 至少有一个测试用例来验证。
我习惯用表格来管理追溯性：
| 危害 ID | 安全目标 ID | FSR ID | TSR ID | 实现模块 | 测试用例 ID |
|---|---|---|---|---|---|
| H-001 | SG-001 | FSR-01 | TSR-01.1 | ADC 驱动 | TC-001 |
| H-001 | SG-001 | FSR-01 | TSR-01.2 | 安全状态机 | TC-002 |
| H-001 | SG-001 | FSR-01 | TSR-01.3 | CAN 驱动 | TC-003 |
| H-002 | SG-002 | FSR-02 | TSR-02.1 | 目标识别算法 | TC-004 |
有了这个表，评审的时候就能快速回答：「这个 TSR 是从哪个危害来的？」「这个测试用例覆盖了哪个需求？」——安全专家最喜欢问这种问题。
4.5 本章知识结构图
下面这张图展示了从危害到安全需求的完整转化流程：
4.6 本章小结
好，咱们捋一下这章的核心：
- 安全目标：从危害导出，回答「要避免什么」，不涉及具体方案。
- 功能安全需求：从安全目标分解，回答「要做什么」，开始有检测、监控等动作。
- 技术安全需求：从 FSR 细化，回答「具体怎么做」，写到工程师能直接干活的程度。
- 可追溯性：从危害到测试，全程可追溯，这是评审的命门。
我个人觉得，安全需求写得好的项目，后面开发阶段基本不会出大问题。写得不好的项目，评审时被挑刺、开发时反复改、测试时发现漏需求——这些我都经历过。所以，花时间把安全需求写透，绝对是值得的。