3. 功能安全概念（FSC）：定义安全目标，设计安全机制
好，咱们进入功能安全概念（FSC）这个环节。说实话，很多工程师觉得FSC就是写文档，画几个框图就完事了。但我个人习惯是，FSC是整个安全开发的“骨架”，骨架歪了，后面填再多的肉也没用。
FSC要回答的核心问题就三个：系统出问题了怎么办？怎么发现它出问题？发现之后怎么让它安全地停下来？ 说白了，就是把安全目标（Safety Goal）翻译成具体的技术实现方案。
3.1 功能安全概念到底定义了什么？
FSC不是让你重新发明轮子。它是在安全目标的基础上，明确每个相关项（Item）应该具备的安全行为。我举个例子，你想想看：
安全目标是“防止非预期的加速”。那FSC就要定义：
- 当检测到油门踏板信号异常时，系统应该做什么？
- 是限制扭矩，还是直接切断动力？
- 这个动作要在多少毫秒内完成？
嗯，这里要注意，FSC必须覆盖所有安全目标，不能有遗漏。我在项目中遇到过，有人把“防止转向锁死”的安全目标写得很漂亮，结果FSC里忘了定义“当转向角度传感器失效时，系统如何进入安全状态”。最后评审时被安全审计师揪出来，返工了整整两周。
核心要点：FSC是连接“安全目标”和“具体实现”的桥梁。它不关心你用哪颗芯片、跑什么操作系统，只关心系统在故障下的行为。
3.2 安全机制设计：怎么防，怎么测？
安全机制，说白了就是系统的“保险丝”和“报警器”。我把它分成两大类：
3.2.1 故障检测机制
这类机制负责发现故障。常见的包括：
- 自检（Self-Test）： 比如CPU上电时跑一遍LBIST，运行时跑一遍SBIST。
- 冗余比较（Redundancy & Compare）： 两个核心算同一个结果，不一致就报错。
- 看门狗（Watchdog）： 程序跑飞了？看门狗咬你一口，复位。
- 信号合理性检查（Plausibility Check）： 车速传感器突然报出500km/h？明显不合理，直接标记为无效。
我曾经在一个项目中，只做了软件看门狗，没做硬件看门狗。结果有一次主频因为电源纹波异常而降低，软件看门狗也跟着变慢了，根本起不到监控作用。从那以后，我坚持软硬看门狗必须同时存在，而且硬件看门狗的超时时间要独立于主频。
3.2.2 故障响应机制
发现故障之后怎么办？不能光报警不处理。常见的响应方式：
- 降级模式（Degradation）： 比如ADAS摄像头被遮挡，系统提示“功能受限”，但基础巡航还能用。
- 安全状态切换（Transition to Safe State）： 直接进入安全状态，比如切断动力、拉起手刹。
- 故障存储（Fault Logging）： 把故障码存进EEPROM，方便售后诊断。
我的建议：设计安全机制时，一定要考虑“共因失效”（Common Cause Failure）。比如两个冗余传感器都用了同一个5V供电，那电源短路了，两个传感器一起失效，冗余就白做了。这种坑，我踩过不止一次。
3.3 故障容错时间间隔（FTTI）：时间就是生命
FTTI（Fault Tolerant Time Interval）这个概念，很多人觉得就是查标准表格。其实没那么简单。
FTTI指的是：从故障发生，到系统进入安全状态，所允许的最大时间。 超过这个时间，就可能造成危害。
举个例子：
| 安全目标 | 典型FTTI | 说明 |
|---|---|---|
| 防止非预期加速 | 100ms | 驾驶员反应时间约500ms，系统必须在驾驶员反应前介入 |
| 防止转向锁死 | 50ms | 高速行驶时，转向失控非常危险 |
| 防止制动失效 | 20ms | 制动系统要求极高，FTTI非常短 |
这里有个关键点：FTTI不是单一值，而是一个时间窗口。 它包含了：
- 故障潜伏时间： 故障发生了，但还没被检测到。
- 故障检测时间： 检测机制发现故障所需的时间。
- 故障响应时间： 系统执行安全动作的时间。
我习惯在FSC里把FTTI拆成这三段来设计。比如FTTI要求100ms，我会分配：潜伏时间20ms，检测时间50ms，响应时间30ms。这样每个模块的设计目标就非常清晰了。
注意：FTTI的分配一定要留余量。我曾经在一个项目中，把检测时间算得刚刚好，结果实际测试时因为总线负载波动，检测时间多了10ms，导致整个FTTI超标。后来我学乖了，至少留20%的余量。
3.4 安全状态定义：系统最后的“避风港”
安全状态，就是系统在检测到故障后，要进入的那个“安全模式”。它必须满足两个条件：
- 可达到： 系统有能力进入这个状态。
- 可维持： 进入之后，不会因为其他故障而自动退出。
常见的安全状态包括：
- 切断动力（Power Off）： 比如断开主继电器，让电机停止输出。
- 限制功能（Limited Functionality）： 比如最高车速限制在30km/h。
- 保持当前状态（Freeze）： 比如转向系统保持当前角度，不再响应新指令。
嗯，这里有个容易忽略的点：安全状态本身也可能失效。 比如你设计了一个“切断动力”的安全状态，但如果主继电器粘连了，切不断怎么办？所以，安全状态的设计必须考虑“失效安全”（Fail-Safe）或“失效可操作”（Fail-Operational）。
我做过一个线控制动项目，安全状态是“切换到液压备份”。但后来发现，如果电子控制单元完全失效，连切换指令都发不出去。最后我们加了一个独立的硬件看门狗，一旦主控无响应，看门狗直接触发液压阀的硬线切换。这才算真正可靠。
总结一下：FSC不是写文档，是设计系统的“安全大脑”。你要想清楚：故障来了，系统怎么感知？怎么决策？怎么执行？每一步都要有明确的定义和量化的指标。
好了，这一章就到这里。下一章我们聊聊技术安全概念（TSC），看看怎么把FSC里的安全机制落实到具体的硬件和软件模块上。