3. 功能安全概念（FSC）：从目标到文档的完整链路
好，咱们进入功能安全概念（FSC）这个核心环节。说实话，很多工程师觉得FSC就是写写文档，走个过场。但我做了这么多年项目，可以负责任地告诉你——FSC是安全架构的“灵魂”。你后面所有的技术决策，都得从这里找依据。
今天咱们就聊四个关键点：安全目标怎么定、安全状态怎么定义、故障容错时间间隔（FTTI）怎么算，以及FSC文档怎么写。嗯，咱们一个一个来。
3.1 功能安全目标定义：别把目标定成“废话”
安全目标，说白了就是“系统出了某种故障，不能造成什么后果”。比如“转向系统不能因为单点故障导致非预期的转向力矩输出”。
我个人习惯，定义安全目标时一定要问三个问题：
- 什么故障？（比如传感器失效、通信中断）
- 什么后果？（比如车辆偏离车道、制动失效）
- 多严重？（ASIL等级是多少）
我在项目中遇到过一种情况：团队把安全目标写成“系统应可靠工作”。你想想看，这种话说了等于没说。可靠到什么程度？故障了怎么办？完全没讲清楚。
“当[故障描述]发生时，系统应确保[安全行为]，以避免[危害事件]，达到[ASIL等级]。”
举个例子：
- 故障：制动踏板位置传感器信号丢失
- 安全行为：系统应进入降级制动模式，保证至少0.3g的减速度
- 危害：车辆无法减速导致碰撞
- ASIL：D
嗯，这样写才叫“可验证的安全目标”。
3.2 安全状态定义：故障来了，系统往哪跑？
安全状态，就是系统检测到故障后，要进入的一个“不会造成危害”的状态。注意，不是所有故障都要立即停车。有时候“降级运行”比“紧急停车”更安全。
我见过一个典型的反面案例：某ADAS系统检测到摄像头故障，直接让车辆急刹。结果呢？后车追尾了。这就是安全状态定义不合理。
常见的几种安全状态：
| 安全状态类型 | 描述 | 适用场景 |
|---|---|---|
| 完全关闭 | 系统停止所有功能输出 | 非安全关键功能（如娱乐系统） |
| 降级运行 | 限制功能范围或性能 | 转向、制动等关键系统 |
| 故障容错运行 | 使用冗余通道继续工作 | 线控制动、线控转向 |
| 安全停车 | 受控地减速并停车 | 自动驾驶系统 |
3.3 故障容错时间间隔（FTTI）：别让系统“反应迟钝”
FTTI，全称Fault Tolerant Time Interval。说白了就是：从故障发生到系统进入安全状态，这段时间不能太长。太长的话，危害已经发生了。
FTTI由两部分组成：
- 故障检测时间（FDTI）：系统发现故障需要多久
- 故障反应时间（FRTI）：系统进入安全状态需要多久
FTTI = FDTI + FRTI
举个例子：制动助力失效，车辆需要在200ms内进入降级制动模式。那么你的故障检测必须在50ms内完成，反应时间控制在150ms内。
我建议的做法是：
- 先确定危害发生的时间窗口（比如从故障到碰撞需要多久）
- 留出安全余量（一般取50%的余量）
- 分配到检测和反应两个环节
嗯，这里要注意：FTTI不是越短越好。太短了，硬件成本会飙升。你要在安全性和成本之间找平衡。
3.4 功能安全概念文档编写：别写成“天书”
FSC文档，是安全架构的“宪法”。它要回答三个问题：
- 系统要做什么？（安全目标）
- 出故障了怎么办？（安全状态、FTTI）
- 怎么保证这些？（安全机制、冗余策略）
我见过很多FSC文档，写得像天书一样。满篇的“shall”、“should”，但读完了不知道具体怎么实现。说白了，文档是给人看的，不是用来凑字数的。
我常用的文档结构：
| 章节 | 内容 | 示例 |
|---|---|---|
| 1. 范围 | 系统边界、功能描述 | 本FSC覆盖EPS系统的转向辅助功能 |
| 2. 安全目标 | 每个安全目标的详细定义 | SG-01：避免非预期转向 |
| 3. 安全状态 | 每个安全目标的对应安全状态 | SS-01：降级为手动转向模式 |
| 4. FTTI | 每个安全目标的FTTI分配 | SG-01：FTTI ≤ 100ms |
| 5. 安全机制 | 实现安全目标的具体技术方案 | 双路传感器冗余、看门狗监控 |
| 6. 验证策略 | 如何验证安全机制有效 | 故障注入测试、FMEA |
最后，送你一个写FSC文档的“三字经”：
- 清：逻辑清晰，每个安全目标都能追溯到危害
- 简：语言简洁，能用一句话说清楚就别用三段
- 验：每个安全目标都是可验证的，不能是“系统应可靠”这种废话
好了，FSC这部分就聊到这儿。下一章咱们讲技术安全概念（TSC），到时候会深入聊具体的安全机制设计。嗯，期待一下。