3、功能安全概念(FSC)：定义、需求导出与安全机制

大家好，我是这次课程的主讲工程师。今天咱们聊聊功能安全概念，也就是FSC。说实话，这个概念在ISO 26262里是个承上启下的关键环节。你想想看，前面我们做了危害分析和风险评估（HARA），得出了安全目标。那接下来呢？怎么把这些目标落地？嗯，这就是FSC要干的事。

3.1 功能安全概念的定义

功能安全概念，说白了就是一套技术方案。它告诉你：为了实现安全目标，系统应该具备哪些功能，以及这些功能怎么协同工作。

我个人习惯把FSC理解成一座桥。桥的一头是安全目标，另一头是具体的技术实现。没有这座桥，你的安全目标就是空中楼阁。

我在项目中遇到过不少团队，他们觉得FSC就是写写文档交差。结果呢？到了集成测试阶段，发现安全机制根本对不上号。返工的成本，啧啧，够买好几辆测试车了。

3.2 功能安全需求的导出

功能安全需求怎么来的？说白了，就是从安全目标一步步推导出来的。这个过程我建议你把它当成一个「翻译」过程——把抽象的安全目标，翻译成具体的、可验证的系统需求。

3.2.1 需求导出的基本步骤

1. 分析安全目标：每个安全目标对应什么场景？什么故障模式？
2. 分配功能：哪些功能模块负责实现这个目标？
3. 定义行为：正常时怎么做？故障时怎么做？
4. 确定属性：响应时间、容错能力、诊断覆盖率等。

举个例子吧。假设安全目标是「车辆在行驶中不得非预期加速」。那功能安全需求可能是：

• 加速踏板位置传感器必须冗余设计
• 两个传感器信号偏差超过5%时，系统必须在100ms内进入安全状态
• 安全状态为「切断动力输出，保持转向和制动能力」

3.2.2 需求导出的常见坑

我曾经吃过一个亏。有个项目，我们导出的需求里写了「系统应检测传感器故障」。你猜怎么着？测试团队问：检测到什么程度？响应时间多少？故障覆盖率多少？全都没写。结果就是需求评审会开了三天，改了三轮。

所以，我建议你写需求时，尽量用SMART原则：

原则	含义	示例
S - Specific	具体明确	「检测传感器短路故障」而非「检测故障」
M - Measurable	可测量	「诊断覆盖率≥99%」
A - Achievable	可实现	考虑现有技术水平和成本
R - Relevant	相关	每个需求都要对应安全目标
T - Time-bound	有时限	「故障检测时间≤50ms」

3.3 安全机制与安全状态

安全机制，就是用来实现功能安全需求的具体手段。安全状态，则是系统在检测到故障后，进入的一种「不会造成危害」的工作模式。

3.3.1 常见的安全机制

我整理了几种常用的安全机制，你在项目中大概率会用到：

• 冗余设计：双通道、三取二投票。说白了就是「一个坏了，另一个顶上」。
• 自诊断：系统定期检查自身健康状态。比如内存ECC、看门狗定时器。
• 故障响应：检测到故障后，执行降级、切换或停机操作。
• 多样性设计：用不同原理实现同一功能，避免共因失效。

3.3.2 安全状态的定义

安全状态不是随便选的。你得考虑：

• 这个状态真的安全吗？
• 进入这个状态需要多长时间？
• 从安全状态恢复到正常状态，需要什么条件？

我记得有个项目，他们定义的安全状态是「切断所有动力」。听起来很安全对吧？但问题是，车辆如果在高速公路上突然失去动力，反而可能引发追尾事故。所以，安全状态也要结合场景来定义。

3.3.3 安全状态的类型

类型	描述	示例
完全安全	系统完全停止，无任何危险	驻车状态、断电状态
降级安全	系统以受限方式运行	限速30km/h、仅保留基本功能
过渡安全	从故障到安全状态的中间过程	减速滑行、警示灯闪烁

3.4 知识体系总览

下面这张图，是我自己画的FSC知识框架。你可以把它当成一张地图，随时回来看看自己走到哪了。

3.5 避坑指南

最后，分享几个我踩过的坑，希望能帮你少走弯路：

• 需求写得太抽象：我曾经写过「系统应可靠地检测故障」，结果被评审专家怼得体无完肤。后来改成「系统应在50ms内检测到传感器开路故障，诊断覆盖率≥99%」，这才通过。
• 安全机制互相冲突：两个安全机制同时触发，反而导致系统进入死锁。嗯，这个坑我掉进去过两次。
• 安全状态定义不完整：只定义了「进入安全状态」，没定义「如何退出」。结果测试时发现，系统进入安全状态后就再也出不来了。

---

公众号:蓝海资料掘金营，微信deep3321