第1章：安全需求管理——FSR与TSR的导出、需求层级与追溯性、需求变更管理
各位工程师朋友，咱们直接进入正题。安全需求管理，说白了就是给ECU开发画一条“安全底线”。我做了十几年功能安全，见过太多项目因为需求没理清楚，后期返工改得死去活来。今天咱们就把FSR和TSR怎么导出、怎么建立追溯、怎么管变更，一次性说透。
1.1 功能安全需求（FSR）的导出
FSR是从安全目标（Safety Goal）推导出来的。安全目标是什么？就是“系统不能干的事”。比如“刹车时不能意外加速”，这就是一个安全目标。
那FSR怎么来？我个人习惯用三步法：
- 分析安全目标：把每个安全目标拆开，看它需要哪些功能来保证安全。
- 定义功能行为：明确系统在正常和故障情况下应该怎么做。
- 分配ASIL等级：每个FSR都要继承安全目标的ASIL等级，不能降级。
举个例子，安全目标“防止刹车时意外加速”，对应的FSR可能是：
FSR-001：当刹车踏板被踩下时，系统必须抑制油门踏板的加速请求。
ASIL等级：ASIL D
验收标准：刹车踏板踩下后10ms内，油门请求必须被抑制。嗯，这里要注意。FSR不能写得太技术化。它应该描述“系统要做什么”，而不是“系统怎么做”。我在项目中遇到过有人把FSR写成“MCU检测到刹车信号后，通过CAN总线发送抑制指令”——这其实是TSR的范畴了。
关键原则：FSR只回答“what”，不回答“how”。
1.2 技术安全需求（TSR）的导出
TSR是从FSR细化出来的。说白了，就是把“要做什么”变成“具体怎么做”。
我建议用“分解法”来导出TSR：
- 功能分解：把FSR拆成多个子功能。
- 技术实现：每个子功能用什么硬件、软件来实现。
- 故障处理：考虑硬件故障、软件错误、通信异常等情况。
还是刚才那个例子，FSR-001可以导出这些TSR：
| TSR编号 | 内容 | ASIL |
|---|---|---|
| TSR-001 | 刹车踏板传感器信号必须在5ms内被MCU采样 | ASIL D |
| TSR-002 | 油门请求抑制逻辑必须在10ms内完成 | ASIL D |
| TSR-003 | 当刹车信号丢失时，系统必须进入安全状态 | ASIL D |
你想想看，TSR比FSR多了什么？多了具体的技术指标、时间约束、故障响应。我曾经在一个项目中，FSR写得很好，但TSR漏了“信号丢失”这个场景。结果测试时发现，刹车传感器一断线，系统直接死机了。嗯，从那以后我再也不敢漏掉故障处理了。
个人经验：导出TSR时，一定要拉上硬件工程师和软件工程师一起讨论。一个人闭门造车，很容易漏掉关键细节。
1.3 需求层级与追溯性
需求层级，说白了就是“爷爷-爸爸-儿子”的关系。安全目标是爷爷，FSR是爸爸，TSR是儿子。每一层都要能追溯上去。
我习惯用这样的追溯矩阵：
| 安全目标 | FSR | TSR | 测试用例 |
|---|---|---|---|
| SG-001 | FSR-001 | TSR-001, TSR-002, TSR-003 | TC-001, TC-002 |
| SG-002 | FSR-002 | TSR-004, TSR-005 | TC-003 |
为什么要做追溯？因为ISO 26262要求“每个安全需求都要被验证”。没有追溯，你根本不知道哪个需求测了，哪个没测。我记得有一次审核，审核员问：“这个FSR对应的测试在哪里？”我们翻了一个小时才找到。从那以后，我要求所有项目必须用工具管理追溯性。
避坑指南：我曾经见过一个项目，追溯矩阵做得漂漂亮亮，但全是手工维护的。需求一变更，矩阵就没人更新了。最后审核时发现大量断裂的追溯链。所以，一定要用工具自动维护追溯性。
1.4 需求变更管理
需求变更是功能安全的大敌。为什么？因为变更可能引入新的风险，或者破坏已有的安全机制。
我建议的变更管理流程：
- 变更申请：谁想改，写清楚改什么、为什么改。
- 影响分析：评估变更对安全目标、FSR、TSR的影响。
- 评审：安全工程师、系统工程师、项目经理一起评审。
- 批准：只有评审通过才能改。
- 实施与验证：改完后，所有受影响的需求和测试都要更新。
这里有个关键点：变更不能破坏追溯性。你改了TSR，对应的FSR和测试用例也要跟着改。我曾经在项目中遇到一个“小改动”——只是改了一个时间参数。结果因为没更新测试用例，测试还是按旧参数跑的，最后在实车上出了问题。嗯，从那以后我坚持“变更必追溯”。
核心原则：变更管理不是走流程，而是保护安全。每一次变更，都要问自己：“这个变更会不会引入新的危险？”
1.5 总结与建议
好了，咱们把这一章的核心内容捋一捋：
- FSR从安全目标导出，只描述“做什么”。
- TSR从FSR细化，描述“怎么做”，包含技术指标和故障处理。
- 需求层级要清晰，追溯性要完整，最好用工具管理。
- 变更管理要严格，每次变更都要做影响分析。
我个人觉得，安全需求管理做得好不好，直接决定了项目后期的工作量。前期花时间把需求理清楚，后期就能少掉很多坑。你想想看，是现在花一周把需求写清楚划算，还是以后花一个月返工划算？
下一章，咱们聊聊安全架构设计。到时候我会分享一些实际项目中的架构方案，保证干货满满。