第四章 功能安全概念（FSC）
好，咱们进入第四章。功能安全概念，简称FSC。这玩意儿说白了，就是安全目标的「落地执行方案」。你光有安全目标不行，得告诉系统怎么干，谁来干，干到什么程度。我见过不少团队，安全目标写得漂漂亮亮，一到FSC就卡壳。为什么？因为从「要安全」到「怎么安全」，中间差着一大截工程细节。
4.1 功能安全概念的定义
功能安全概念，我的理解是这样的：它是把安全目标分配到系统架构中的具体技术方案。你想想看，安全目标说「碰撞后车门要能打开」，那FSC就要回答——谁检测碰撞？谁控制门锁？备用电源在哪？失效了怎么办？
ISO 26262里对FSC有明确定义，但我个人习惯用一句话记：FSC = 安全目标 + 系统架构 + 故障处理策略。三个要素缺一不可。
核心要点：FSC不是文档，是设计决策。它决定了安全机制怎么嵌入到系统里。
我在项目里遇到过一种情况：安全目标分解得很细，但FSC写得像天书。工程师看不懂，测试也没法验证。最后评审时被安全专家怼回来重写。嗯，这里要注意——FSC的读者不只是安全工程师，还有系统工程师、软件工程师、硬件工程师。你得让他们都看懂。
4.2 从安全目标到功能安全概念的分解
这一步是核心。怎么把安全目标拆成FSC？我一般分三步走：
- 识别相关项：安全目标涉及哪些系统组件？
- 分配安全要求：每个组件承担什么安全职责？
- 定义安全机制：故障来了，怎么检测、怎么响应？
举个例子。安全目标：「车辆行驶中，非预期加速不得超过0.3g」。那FSC可以这样分解：
| 组件 | 安全要求 | 安全机制 |
|---|---|---|
| 加速踏板传感器 | 检测踏板位置信号 | 双通道冗余，信号比较 |
| ECU | 处理加速请求 | 看门狗监控，超时复位 |
| 执行器（电机/节气门） | 执行加速指令 | 扭矩监控，超限降级 |
你看，一个安全目标，拆成了三个组件的具体任务。每个任务都有对应的安全机制。这就是FSC的分解逻辑。
我的经验：分解时别贪多。一个安全目标拆成3-5个功能安全要求就够了。拆太细，后面验证工作量爆炸；拆太粗，又漏了关键点。平衡很重要。
4.3 功能安全概念文档撰写要点
文档怎么写？我见过两种极端：一种是写成了流水账，另一种是写成了天书。其实FSC文档有套路，掌握几个要点就行。
4.3.1 结构要清晰
我个人习惯用这个结构：
- 引言：说明文档目的、适用范围
- 安全目标列表：引用安全目标编号
- 系统架构描述：画出功能框图，标注安全相关组件
- 功能安全要求：每个安全目标对应的FSC要求
- 安全机制描述：故障检测、故障响应、降级策略
- ASIL分解说明：如果有ASIL分解，要写清楚
4.3.2 要求要可验证
这一点我吃过亏。以前写FSC时，写了一句「系统应能检测传感器故障」。结果测试时发现——什么叫「检测」？检测时间是多少？检测覆盖率多少？全没写。后来被审计追着问。
所以我现在写FSC要求，一定带上量化指标：
FSC-001：加速踏板位置传感器应能在10ms内检测到信号丢失故障。
FSC-002：检测到故障后，ECU应在20ms内进入安全状态（限制扭矩至0）。
FSC-003：安全状态的诊断覆盖率应≥99%（根据ASIL等级确定）。
避坑指南：我曾经因为FSC要求写得太模糊，导致测试用例没法写。后来评审时被安全经理点名批评。记住——每个FSC要求，都要能回答三个问题：谁？什么时候？做到什么程度？
4.3.3 要体现故障处理逻辑
FSC不只是写「要做什么」，还要写「出错了怎么办」。我一般用故障树或状态机来描述。比如：
- 正常模式：系统正常运行
- 故障检测模式：检测到异常，进入诊断
- 降级模式：确认故障，执行降级策略
- 安全模式：进入安全状态，等待维修
每个模式之间的切换条件、时间要求、恢复策略，都要写清楚。你想想看，如果故障处理逻辑不明确，测试怎么验证？安全评审怎么通过？
4.3.4 别忘了ASIL分解
如果系统里有ASIL分解，FSC里一定要体现。比如一个ASIL D的安全目标，分解成两个ASIL B的组件。那FSC里要写清楚：
- 分解的依据是什么？
- 两个组件之间怎么保证独立性？
- 有没有共因失效分析？
我见过有人把ASIL分解写成了「拍脑袋」——觉得差不多就分了。结果评审时被问得哑口无言。嗯，这里要提醒你：ASIL分解不是数学题，得有工程依据。
总结一下：FSC文档是安全设计的「蓝图」。写得好，后面开发、测试、验证都顺；写不好，后面全是坑。我建议你写完FSC后，自己先问一遍——每个要求能测试吗？每个故障有处理吗？每个分解有依据吗？
好了，第四章就到这里。下一章咱们聊技术安全概念（TSC），那是更细粒度的设计。到时候你会发现，FSC和TSC的关系，就像建筑蓝图和施工图纸——一个定方向，一个定细节。