3. 功能安全概念(FSC)：功能安全概念开发、安全状态定义、故障容错时间间隔、安全机制分配
好，咱们进入功能安全概念（FSC）的开发。说实话，这是整个安全生命周期里最需要「动脑子」的阶段。前面我们做了HARA，知道了哪些风险不能忍。那接下来怎么办？你得想办法把风险降下来。这就是FSC要干的事。
我个人习惯把FSC看作一张「安全地图」。它告诉你：当系统出问题时，怎么让车安全停下来。说白了，就是定义一套规则——什么情况下算安全？多久必须响应？谁来执行保护动作？
3.1 功能安全概念开发——从「危险」到「安全」的桥梁
功能安全概念开发，核心就是一句话：把安全目标（Safety Goal）转化成具体的功能需求。
举个例子。我们之前定了一个安全目标：「防止非预期的加速」，ASIL C。那怎么实现？你不能直接跟软件工程师说「你别让车乱加速」，这太模糊了。你得拆解成可执行的功能安全需求。
我一般会这么拆：
- 检测机制：怎么发现油门信号异常？比如监控油门踏板位置传感器，两个信号差值超过5%就报错。
- 响应机制：发现异常后做什么？比如限制扭矩输出，或者直接切断动力。
- 降级模式：系统还能不能用？比如进入跛行回家模式，最高车速限制在30km/h。
这里有个坑，我踩过。有一次，我们把安全需求写得特别「功能化」，比如「当故障发生时，系统应进入安全状态」。结果软件团队问：「到底多快进入？进入哪个状态？要不要通知用户？」 你看，这就是需求不明确导致的返工。
3.2 安全状态定义——系统「认怂」的正确姿势
安全状态，就是系统在故障后，能保证人员安全的一种运行模式。听起来简单，但定义起来挺讲究。
我见过最典型的错误，是把「关闭系统」当成万能安全状态。你想想看，如果刹车系统故障了，你直接断电？那车就彻底没刹车了，反而更危险。所以安全状态不是「一刀切」的。
常见的几种安全状态：
| 安全状态类型 | 描述 | 适用场景举例 |
|---|---|---|
| 完全关闭 | 系统断电，不再提供任何功能 | 信息娱乐系统故障（不影响安全） |
| 降级模式 | 功能受限，但核心安全功能保留 | EPS故障，保留基础助力，关闭高级功能 |
| 跛行回家 | 车辆以极低速度行驶，可开到路边 | 动力系统故障，限速20km/h |
| 维持当前状态 | 保持故障前的输出，不变化 | 安全气囊控制器，故障后维持非触发状态 |
定义安全状态时，我通常会问自己三个问题：
- 这个状态真的安全吗？ 比如，转向系统故障后，如果直接锁死方向盘，那比故障本身还危险。
- 用户能理解吗？ 仪表盘上亮个红灯，用户知道该靠边停车吗？
- 退出条件是什么？ 什么时候能恢复正常？是下次上电，还是维修后？
3.3 故障容错时间间隔（FTTI）——和时间赛跑
FTTI，全称Fault Tolerant Time Interval。说白了就是：从故障发生，到系统进入安全状态，最多能容忍多长时间。
这个参数怎么定？不是拍脑袋的。它取决于两个因素：
- 危险事件的持续时间：比如，刹车失灵，1秒钟就可能撞车。那FTTI必须小于1秒。
- 人的反应时间：如果系统能撑到驾驶员反应过来接管，那FTTI可以长一点。
我记得在做一个线控制动项目时，安全目标要求「制动压力非预期增加时，必须在100ms内切断动力」。为什么是100ms？因为HARA分析显示，超过200ms，车辆就可能偏离车道。所以我们把FTTI定在100ms，留了50%的余量。
FTTI的分配，通常涉及三个环节：
- 故障检测时间：从故障发生到被诊断出来。比如，传感器自检周期是20ms。
- 故障响应时间：从诊断出故障到执行安全动作。比如，MCU处理中断需要10ms。
- 系统稳定时间：从执行动作到系统真正进入安全状态。比如，继电器断开需要5ms。
加起来，必须小于FTTI。如果超了，就得优化检测算法，或者换更快的硬件。
3.4 安全机制分配——把任务分给「靠谱的人」
安全机制，就是用来检测故障、防止违反安全目标的具体手段。分配安全机制，说白了就是决定：这个保护动作，由硬件做？还是软件做？还是两者配合？
常见的分配原则：
- 硬件安全机制：响应快，可靠性高，但灵活性差。比如看门狗定时器、硬件冗余比较器。
- 软件安全机制：灵活，可配置，但响应慢，容易受软件bug影响。比如自检程序、数据校验。
- 系统级安全机制：跨ECU的协同保护。比如通过CAN总线发送心跳信号，监控对方是否存活。
我举个例子。一个电子助力转向系统（EPS），安全目标是「防止非预期转向」。那安全机制怎么分配？
| 安全机制 | 分配对象 | 说明 |
|---|---|---|
| 扭矩传感器信号合理性检查 | 软件（ASIL C） | 两个传感器信号对比，差值超阈值则报错 |
| 电机电流监控 | 硬件（ASIL D） | 独立电流检测芯片，超限直接切断PWM |
| 看门狗监控 | 硬件（ASIL B） | 监控主控芯片是否跑飞 |
| 系统自检（上电/周期） | 软件（ASIL B） | 检查RAM、ROM、寄存器是否正常 |
这里有个关键点：安全机制的ASIL等级，要和它要覆盖的安全目标匹配。比如，安全目标是ASIL D，那用来检测它的安全机制，至少也得是ASIL D（或者通过分解降低）。
最后，总结一下FSC开发的几个要点：
- 安全状态要具体：别只说「进入安全模式」，要定义清楚是降级、关闭还是维持。
- FTTI要留余量：别卡着极限值，实际测试总会给你「惊喜」。
- 安全机制分配要合理：硬件和软件各司其职，别让一方扛太多。
嗯，FSC这部分就聊到这儿。下一章我们讲技术安全概念（TSC），看看怎么把这些功能需求落地到具体的硬件和软件架构上。