3. 功能安全概念（FSC）与安全目标：安全目标定义、功能安全概念导出、安全状态与容错时间间隔
好，我们进入第三章。这一章是功能安全落地的第一个关键节点——从纸上谈兵到具体设计的桥梁。
说白了，前面我们做了HARA，找到了危害，定了ASIL等级。但接下来呢？你得告诉工程师们：到底要防什么？怎么防？防不住的时候怎么办？
这就是功能安全概念（FSC）要干的事。
3.1 安全目标（Safety Goal）—— 顶层安全需求
安全目标，是HARA的直接输出。每个危害事件，都会对应一个安全目标。
安全目标的定义原则：
- 一句话说清楚：“避免[危害事件]发生”
- 必须包含安全状态：“当检测到[故障]时，系统应在[时间]内进入[安全状态]”
- 继承ASIL等级：安全目标的ASIL直接来自HARA中对应危害的最高ASIL
举个例子：
EPS（电动助力转向）系统的一个危害：非预期转向导致车辆偏离车道。
对应的安全目标：
SG-01：避免EPS产生非预期助力扭矩，ASIL D。
SG-01的安全状态：EPS切断助力，进入“降级助力模式”，驾驶员仍可机械转向。
我个人习惯，在定义安全目标时，会加一个“容错时间间隔”的初步估计。虽然这个值在后续会细化，但早期有个量级概念，对架构设计很有帮助。
| 安全目标要素 | 说明 | 示例（EPS） |
|---|---|---|
| 危害描述 | HARA输出的危害事件 | 非预期转向 |
| 安全目标 | 避免危害发生的顶层要求 | 避免EPS产生非预期助力扭矩 |
| ASIL | 继承自HARA | ASIL D |
| 安全状态 | 故障时系统应进入的状态 | 降级助力模式 |
| 容错时间间隔 | 从故障发生到进入安全状态的最大允许时间 | ≤ 100ms |
避坑指南：我曾经见过一个项目，安全目标写成了“系统应可靠工作”。这等于没写。安全目标必须具体到“避免什么危害”，而不是“系统要可靠”。
3.2 功能安全概念（FSC）—— 把安全目标翻译成系统设计
安全目标是“what”，功能安全概念是“how”。
FSC要做的事：
- 分解安全目标：把顶层安全目标，分解到系统的各个功能模块
- 定义安全机制：每个子目标，用什么机制来保证
- 分配ASIL：如果用了ASIL分解，这里要明确
- 定义安全状态：每个故障场景下，系统应该怎么反应
- 定义容错时间间隔：每个安全机制必须在多长时间内生效
我建议用表格来管理FSC，清晰且可追溯。
| 安全目标ID | 功能模块 | 安全机制 | ASIL | 安全状态 | FTTI |
|---|---|---|---|---|---|
| SG-01 | 扭矩传感器 | 传感器信号合理性检查（范围+斜率） | ASIL D | 降级助力 | ≤ 50ms |
| SG-01 | 电机驱动 | 电机电流监控 + 扭矩监控 | ASIL D | 切断助力 | ≤ 100ms |
| SG-01 | 控制器 | 程序流监控（看门狗） | ASIL D | 系统复位 | ≤ 200ms |
我的经验：FSC不要写得太细。它是个“概念”层面的东西，告诉架构师和系统工程师“我们要做什么”。具体怎么实现，那是技术安全概念（TSC）的事。我见过有人把FSC写成详细设计文档，结果评审时大家全在抠细节，反而忽略了顶层逻辑。
3.3 安全状态（Safe State）—— 故障时的“保命模式”
安全状态，是系统在检测到故障后，进入的一种“不会导致危害”的状态。
常见的安全状态类型：
- 完全关闭：系统彻底断电，比如EPS切断助力
- 降级模式：系统以受限功能继续运行，比如限速30km/h
- 维持状态：保持当前输出不变，比如保持当前转向角度
- 紧急操作：系统执行预设的安全动作，比如自动紧急制动
选择哪种安全状态，取决于危害的严重度和系统的物理特性。
一个真实的案例：
我之前做线控制动系统时，安全状态的选择就很有讲究。
如果直接切断制动助力，驾驶员可能踩不动刹车。所以我们选择了“降级模式”——保留基础助力，但限制最大制动力，同时点亮警告灯。
这个决策，就是在FSC阶段定下来的。
3.4 容错时间间隔（FTTI）—— 与时间赛跑
FTTI（Fault Tolerant Time Interval），是从故障发生到系统进入安全状态的最大允许时间。
这个值怎么定？
- 从危害分析来：这个故障发生后，多久会导致危害？
- 从系统响应来：检测故障需要多久？执行安全动作需要多久？
- 留余量：FTTI必须大于“故障检测时间 + 安全动作执行时间”
我建议在FSC阶段，先给一个保守的FTTI估计。后续在TSC阶段，再通过详细分析来确认。
| 系统类型 | 典型FTTI | 说明 |
|---|---|---|
| 制动系统 | ≤ 100ms | 制动响应要求极高 |
| 转向系统 | ≤ 200ms | 驾驶员可短时补偿 |
| 动力系统 | ≤ 500ms | 动力中断容忍度较高 |
| ADAS感知 | ≤ 50ms | 高速场景下反应时间极短 |
避坑指南：我曾经犯过一个错误——把FTTI设得太紧。结果硬件团队说“检测时间就要80ms，你让我100ms内完成所有动作？”后来我们重新分析了危害，发现其实200ms也安全。FTTI不是越短越好，而是“刚好够用”就好。
3.5 FSC的导出流程——从安全目标到系统架构
嗯，这里我画了一张图，把整个FSC的导出流程串起来。你一看就明白了。
这张图把整个流程串起来了。从HARA开始，一步步导出FSC。每个步骤都有明确的输入和输出。
3.6 FSC的评审要点
FSC写完后，一定要评审。我总结了几条评审要点：
- 完整性：所有安全目标是否都覆盖了？有没有遗漏的危害？
- 一致性：安全机制之间有没有冲突？比如一个要求切断助力，一个要求保持助力。
- 可实现性：FTTI是否合理？安全状态是否物理可行？
- 可追溯性：每个安全机制是否能追溯到安全目标？每个安全目标是否能追溯到HARA？
我的习惯：评审时我会带一张大表，把HARA、安全目标、FSC、安全状态、FTTI全部列在一起。评审专家一眼就能看出哪里缺了、哪里冲突了。这比翻文档高效得多。
好了，这一章的内容就是这些。FSC是功能安全落地的第一步，也是最重要的一步。这一步走稳了，后面的TSC和硬件软件实现就会顺畅很多。