4、功能安全概念（FSC）：功能安全需求定义、安全机制分配、故障容错时间间隔
好，咱们进入第四章。功能安全概念，简称 FSC。这是系统级开发里最核心的一步，没有之一。
说白了，FSC 要回答三个问题：系统要做什么来保证安全？谁来干这个活？干得慢不慢？
我个人的习惯是，拿到 Item Definition 和 Hazard Analysis 之后，先别急着写代码。先坐下来，把 FSC 想清楚。这一步想透了，后面能少走一半弯路。
4.1 功能安全需求定义
功能安全需求，不是功能需求。功能需求说「车能跑多快」，安全需求说「刹车失灵时，系统必须在 100ms 内进入安全状态」。
嗯，这里要注意：安全需求必须从安全目标推导出来。每个安全目标，至少对应一条功能安全需求。
核心原则：功能安全需求必须是可验证的、可实现的、无歧义的。
举个例子，安全目标是：「避免因转向助力失效导致车辆失控」。对应的功能安全需求可能是：
- FSR-001：当转向助力电机故障时，系统应在 50ms 内检测到故障。
- FSR-002：检测到故障后，系统应在 200ms 内切换至机械备份模式。
- FSR-003：机械备份模式下，方向盘手力不得超过 50N。
我在项目中遇到过，有人把安全需求写成「系统应足够安全」。这种话等于没说。需求必须量化，必须能测试。
我的小技巧：每条安全需求都问自己三个问题——能不能测？能不能实现？有没有歧义？三个都答「是」，这条需求才算合格。
4.2 安全机制分配
安全需求定义好了，接下来要分配安全机制。说白了，就是「谁来干活」。
安全机制可以分配给硬件，也可以分配给软件，或者两者配合。分配的原则是：谁最擅长干这个活，就给谁。
常见的分配方式有：
| 安全机制 | 典型分配 | 说明 |
|---|---|---|
| 故障检测 | 硬件 + 软件 | 硬件做快速检测，软件做诊断确认 |
| 故障响应 | 软件 | 软件控制进入安全状态 |
| 冗余备份 | 硬件 | 双通道设计，硬件独立 |
| 看门狗 | 硬件 | 独立外部看门狗，监控软件运行 |
我曾经犯过一个错：把故障检测全部分配给软件。结果发现，软件跑在同一个 MCU 上，MCU 挂了，软件也检测不了。后来改成硬件独立检测 + 软件确认，才真正可靠。
避坑指南：安全机制分配时，一定要考虑「共因失效」。两个机制不能依赖同一个资源。否则一个挂了，两个都完蛋。
4.3 故障容错时间间隔
故障容错时间间隔，英文叫 FTTI。这是很多人容易忽略的点。
FTTI 是什么意思？从故障发生到系统进入安全状态，允许的最大时间。超过这个时间，风险就不可接受了。
FTTI 的确定，通常来自安全目标。比如：
- 刹车系统：FTTI 通常 100ms 以内
- 转向系统：FTTI 可能 200ms 以内
- 信息娱乐系统：FTTI 可以放宽到 1s 以上
你想想看，FTTI 定得太短，硬件成本飙升；定得太长，安全不达标。怎么平衡？
我的做法是：先根据安全目标定一个理论值，然后做仿真验证。如果硬件响应跟不上，再调整。但调整必须有理有据，不能拍脑袋。
关键点：FTTI 不是单指检测时间，也不是单指响应时间。它是「检测 + 诊断 + 响应 + 进入安全状态」的总和。
举个例子：
FTTI = 故障检测时间 + 故障确认时间 + 安全响应时间 + 状态切换时间
假设 FTTI = 100ms：
- 故障检测：30ms
- 故障确认：20ms
- 安全响应：30ms
- 状态切换：20ms
我在项目中遇到过，有人把 FTTI 全部分配给检测，结果响应时间不够。最后不得不重新设计。嗯，所以分配时间预算时，一定要留余量。
建议：FTTI 分配时，给每个环节留 10%-20% 的余量。硬件有延迟，软件有抖动，留余量才能保证实际跑起来不出问题。
4.4 小结
功能安全概念，说白了就是三件事：
- 定义需求——要做什么，量化清楚
- 分配机制——谁来干，独立可靠
- 确定时间——多快干完，留足余量
这三件事做扎实了，系统级安全开发就稳了一半。下一章咱们聊技术安全概念，那是把 FSC 落地到具体实现的关键一步。
好，今天就到这里。有什么问题，欢迎交流。