4、安全要求规范：安全要求层级与编写技巧

好，咱们进入第四讲。安全要求规范，这名字听着挺正式，但说白了，就是回答三个问题：「要防什么？怎么防？防到什么程度？」

我这些年做审计，发现很多项目栽跟头，不是技术不行，而是安全要求写得一塌糊涂。要么太抽象，开发看不懂；要么太细节，把架构师的路给堵死了。今天咱们就把这个事掰扯清楚。

4.1 安全要求的三个层级

ISO 26262 把安全要求分成了三层：安全目标（SG）、功能安全要求（FSR）、技术安全要求（TSR）。这三层，说白了就是「目标→功能→实现」的逐层细化。

4.1.1 安全目标（Safety Goal）

安全目标是最高层的要求。它回答的是：「系统出了什么故障，会导致什么不可接受的后果？」

举个例子，你做个电动转向系统。安全目标可能是：
「当系统检测到非预期转向时，必须在 100ms 内切断助力，防止车辆偏离车道。」

我个人习惯，写安全目标时一定要带上三个要素：

• 危险事件：什么场景下出问题？
• 安全状态：出问题后系统该进入什么状态？
• 容错时间：必须在多长时间内完成切换？

4.1.2 功能安全要求（Functional Safety Requirement）

安全目标定好了，接下来就是功能安全要求。它回答的是：「系统需要具备什么功能，才能实现安全目标？」

还是那个转向系统。安全目标是「切断助力」，那功能安全要求可能是：

• FSR-01：系统应具备转向扭矩监控功能，实时检测方向盘扭矩信号。
• FSR-02：当扭矩信号超出正常范围（±5Nm）超过 50ms，应触发安全机制。
• FSR-03：安全机制触发后，应在 20ms 内关闭助力电机驱动。

你想想看，功能安全要求其实是在描述「系统该做什么」，而不是「怎么做」。这个区别很重要。我见过不少团队，在 FSR 阶段就开始写「用 CAN 总线传输信号」——这就越界了，那是 TSR 的事。

4.1.3 技术安全要求（Technical Safety Requirement）

技术安全要求，就是把功能安全要求落实到具体的硬件和软件上。它回答的是：「用什么技术手段来实现？」

比如 FSR-03 说「20ms 内关闭电机驱动」，那 TSR 可能是：

• TSR-03-01：MCU 应在检测到安全事件后，通过 GPIO 拉低电机驱动芯片的 EN 引脚。
• TSR-03-02：EN 引脚拉低后，驱动芯片应在 5ms 内停止 PWM 输出。
• TSR-03-03：驱动芯片应具备硬件看门狗，若 MCU 超过 100ms 未喂狗，自动切断输出。

嗯，这里要注意：TSR 要写得足够细，让硬件工程师和软件工程师拿到就能干活。但又不能太细，把人家架构设计给锁死了。这个度，得靠经验把握。

4.2 安全要求编写技巧

写了这么多年安全要求，我总结了几条实用技巧，分享给你：

4.2.1 用「SHALL」句式，别含糊

安全要求必须用「应（SHALL）」来写。这是行业惯例，也是审计时的硬性要求。

❌ 错误写法：
「系统可以考虑在故障时切断助力。」

✅ 正确写法：
「系统应在检测到故障后的 20ms 内切断助力。」

我在项目中遇到过，有人写「建议」「最好」「可考虑」这类词。审计时直接被标注为「非强制性要求」，等于没写。记住：安全要求没有商量余地。

4.2.2 每个要求只讲一件事

一个安全要求只描述一个功能或一个行为。别把多个事情塞到一条里。

❌ 错误写法：
「系统应监控扭矩信号，并在故障时切断助力，同时记录故障码。」

✅ 正确写法：
「FSR-04：系统应实时监控转向扭矩信号。」
「FSR-05：当扭矩信号异常时，系统应切断助力。」
「FSR-06：系统应在切断助力后，将故障码存入非易失性存储器。」

为什么？因为每条要求都要单独测试、单独追溯。混在一起，你根本没法验证。

4.2.3 带上可验证的指标

每条安全要求都要有明确的、可量化的指标。否则你怎么证明它实现了？

要素	说明	示例
触发条件	什么情况下启动？	扭矩信号 > 5Nm 且持续 50ms
响应行为	系统做什么？	切断助力电机驱动
时间约束	多快完成？	20ms 内
安全状态	进入什么状态？	助力关闭，转向恢复机械模式

4.3 可追溯性：安全要求的「户口本」

可追溯性，说白了就是「每个要求从哪来，到哪去，都能查得到」。审计时，这是必查项。

4.3.1 为什么要做追溯？

我举个真实案例。有个项目做功能安全认证，审计师问：「这个 TSR 对应的 FSR 是哪个？」工程师翻了半天文档，答不上来。结果呢？整个安全案例被打回重做，项目延期三个月。

可追溯性不是形式主义。它保证了两件事：

• 完整性：每个安全目标都被分解到了具体的技术实现，没有遗漏。
• 一致性：需求变更时，能快速评估影响范围，不会改漏。

4.3.2 怎么做追溯？

最常用的方法是编号+矩阵。每个安全要求都有一个唯一编号，然后用追溯矩阵把它们串起来。

比如：

安全目标	功能安全要求	技术安全要求	测试用例
SG-01	FSR-01, FSR-02	TSR-01-01, TSR-01-02	TC-SG01-001, TC-SG01-002
SG-02	FSR-03, FSR-04	TSR-02-01, TSR-02-02	TC-SG02-001

我个人习惯用 Excel 或者专门的工具（比如 DOORS、Polarion）来维护这个矩阵。但工具不是关键，关键是每条追溯都要有明确的「父子关系」。

4.3.3 避坑指南

怎么做才靠谱？我的建议是：

• 双向追溯：从安全目标往下能查到测试用例，从测试用例往上也能查到安全目标。
• 变更时同步更新：改了一个 TSR，必须检查对应的 FSR 和测试用例是否需要调整。
• 定期审计：每个迭代结束前，花半天时间过一遍追溯矩阵，确保没有断链。

4.4 小结

好，这一讲的内容就这些。总结一下：

• 安全要求分三层：SG（目标）、FSR（功能）、TSR（技术），逐层细化。
• 编写时用 SHALL 句式，每条只讲一件事，带上可验证的指标。
• 可追溯性是安全案例的骨架，用编号+矩阵 来维护，确保双向可查。

下一讲，咱们聊聊安全架构设计。到时候我会分享一个我踩过的坑——关于「冗余设计」的误解，挺有意思的，到时候见。