3、功能安全概念(FSC)：功能安全目标定义、功能安全概念设计、安全机制分配、安全状态定义
好，我们进入功能安全概念阶段。说实话，这是整个安全生命周期里最需要「动脑子」的一步。前面我们做了HARA，拿到了ASIL等级和危险事件。但光有这些还不够——你得告诉开发团队：到底要做什么？怎么做？做到什么程度算安全？
我个人习惯把FSC比作「安全需求的骨架」。它不涉及具体代码怎么写，也不管你用MCU还是MPU。它只回答三个问题：要防什么？怎么防？防不住怎么办？
3.1 功能安全目标定义
功能安全目标，说白了就是一句话：针对每个危险事件，我们要达到的安全状态是什么。
举个例子。你做一个电子助力转向系统。HARA分析出来一个危险事件：「非预期的转向助力丢失，导致驾驶员无法转向」，ASIL D。那功能安全目标怎么写？
安全目标示例：
SG-01：在转向助力系统发生单点故障时，系统应在100ms内检测到故障，并进入降级模式，确保驾驶员仍能通过机械连接完成转向操作。[ASIL D]
这里有几个关键点，我踩过坑，跟大家说说：
- 目标要可验证：别写「系统应足够安全」这种废话。要写「故障检测时间≤100ms」、「转向力矩偏差≤5%」。
- 明确安全状态：是降级运行？还是完全关断？还是进入跛行模式？
- ASIL等级不能降：HARA分析出来是ASIL D，安全目标就得是ASIL D。不能因为觉得难做就偷偷降级。
我的经验： 我曾经在一个项目中，安全目标写得过于笼统。结果开发团队理解偏差，做出来的东西根本没法通过安全评审。后来我学乖了——每个安全目标都要附带一个「验收准则」，白纸黑字写清楚。
3.2 功能安全概念设计
安全目标定好了，接下来就是功能安全概念设计。这一步要回答：怎么实现这些安全目标？
功能安全概念不是架构设计，也不是详细设计。它更像一个「安全策略蓝图」。我一般会从三个维度来思考：
- 故障检测机制：怎么发现故障？
- 故障响应机制：发现故障后做什么？
- 故障容错机制：故障发生时，系统还能不能正常工作？
举个例子，还是转向系统。安全目标是「故障后100ms内检测并进入降级模式」。那功能安全概念可以这样设计：
功能安全概念示例：
- 故障检测：使用双路扭矩传感器，通过比较两路信号偏差来检测传感器故障。
- 故障响应：检测到偏差超过阈值后，立即切断助力电机供电，并点亮仪表盘警告灯。
- 故障容错：保留机械转向连杆，确保即使完全失去助力，驾驶员仍能通过机械连接转向。
嗯，这里要注意：功能安全概念要覆盖所有安全目标。不能漏掉任何一个。我见过一个项目，安全目标写了10个，功能安全概念只覆盖了8个。结果评审时被安全工程师怼得哑口无言。
3.3 安全机制分配
安全机制分配，就是把功能安全概念里的「安全策略」落实到具体的系统元素上。说白了：谁负责做什么？
我习惯用一张表格来管理安全机制分配。这样一目了然：
| 安全机制ID | 安全机制描述 | 分配到的元素 | ASIL等级 | 实现方式 |
|---|---|---|---|---|
| SM-01 | 双路扭矩传感器信号比较 | 传感器模块 | ASIL D | 硬件冗余+软件比较 |
| SM-02 | 助力电机供电切断 | 电源管理模块 | ASIL D | 硬件安全路径 |
| SM-03 | 警告灯点亮 | 仪表盘模块 | ASIL B | CAN信号 |
| SM-04 | 机械转向连杆保留 | 机械结构 | QM | 机械设计 |
避坑指南： 我曾经犯过一个错误——把安全机制分配给了「软件」这个模糊的概念。结果开发时发现，到底是哪个软件模块负责？哪个函数？哪个任务？全都没说清楚。后来我要求每个安全机制必须分配到具体的「工程交付物」：硬件模块、软件组件、甚至具体的函数接口。
分配时还要注意一点：ASIL等级要向下兼容。如果一个安全机制是ASIL D的，那它分配到的硬件和软件组件也必须按照ASIL D的要求来开发。不能因为「这个传感器很简单」就偷偷降级。
3.4 安全状态定义
安全状态，是功能安全概念里最容易忽略、也最容易出问题的一环。很多人觉得安全状态就是「系统关掉」。其实远没那么简单。
安全状态要回答三个问题：
- 什么状态是安全的？ 比如转向系统：失去助力但保留机械连接，是安全的。但如果连机械连接也断了，那就不安全。
- 怎么进入安全状态？ 是立即切断？还是平滑过渡？过渡时间是多少？
- 进入安全状态后怎么办？ 是一直保持？还是允许恢复？恢复条件是什么？
我给大家看一个实际项目中的安全状态定义：
安全状态定义示例：
- 安全状态名称：降级转向模式
- 描述：助力电机断电，转向系统仅依靠机械连杆工作。驾驶员需施加正常转向力2-3倍的力来完成转向。
- 进入条件：双路扭矩传感器偏差＞10%，且持续超过50ms。
- 进入时间：从故障发生到进入安全状态，不超过100ms。
- 退出条件：仅在下一次上电初始化后，且自检通过，才能退出安全状态。
- ASIL等级：ASIL D
你想想看，如果安全状态定义不清楚，开发人员可能做出一个「半吊子」的安全机制——故障检测到了，但不知道下一步该干嘛。或者进入了安全状态，但不知道怎么退出。这些都是我在项目中真实遇到过的坑。
我的建议： 安全状态定义最好和系统架构师、软件架构师一起评审。因为安全状态往往涉及到系统级的切换逻辑，光靠功能安全工程师一个人闭门造车，很容易漏掉边界情况。
3.5 小结
功能安全概念阶段，说白了就是「把HARA的结果翻译成可执行的安全需求」。我个人觉得，这个阶段做得好不好，直接决定了后续开发是否顺畅。
最后送大家一句话：功能安全概念不是写文档，而是做设计。别把时间花在排版和措辞上，多花点时间想清楚：到底怎么防？防不住怎么办？
下一章，我们会进入技术安全概念阶段。到时候会涉及到更具体的架构设计和安全机制实现。嗯，那才是真正「动手」的时候。