4. 功能安全概念(FSC)：安全目标定义、功能安全需求导出、安全机制初步设计
好，我们进入功能安全概念阶段。说白了，这一步就是把上一章做的HARA分析结果，翻译成工程团队能看懂、能执行的设计输入。
我个人习惯把FSC看作一座桥——桥的一端是“这车出了什么危险”，另一端是“软件到底该怎么写”。没有这座桥，安全分析就是纸上谈兵，代码实现就是无头苍蝇。
4.1 安全目标(Safety Goal)的定义
安全目标，是功能安全设计的最高纲领。它回答一个核心问题：系统在发生某种故障时，必须保证什么？
每个安全目标都对应HARA中识别出的一个危害事件，并且继承了它的ASIL等级。
SG-01：防止非预期的转向助力丧失，导致驾驶员无法控制车辆方向。
ASIL：D
安全状态：转向系统进入降级模式，维持基础机械转向功能。
定义安全目标时，有几点我特别想强调：
- 一个危害一个目标：别试图用一个安全目标覆盖多个危害，那样会导致需求模糊、验证困难。
- 描述要可验证：“防止系统失效”这种话太空了。要写成“当车速>10km/h时，转向助力下降不得超过30%”。
- 明确安全状态：故障发生后，系统应该进入什么状态？是降级、关断，还是维持？这个必须写清楚。
有个项目定义了安全目标“防止电池过充”，但没写安全状态。结果开发团队以为只要报警就行，实际上安全状态应该是“切断充电回路”。后来评审时被安全审计师揪出来，返工了整整两周。
4.2 从安全目标到功能安全需求
安全目标定好了，接下来要把它拆解成功能安全需求(FSR)。FSR是系统层面的需求，描述系统“应该做什么”来满足安全目标。
我一般用“WHY-WHAT-HOW”三层法来做这个拆解：
| 层级 | 内容 | 示例 |
|---|---|---|
| WHY | 安全目标 | 防止非预期转向助力丧失 |
| WHAT | 功能安全需求 | 系统必须实时监测扭矩传感器信号的有效性 |
| HOW | 技术安全需求 | 扭矩传感器信号需通过CRC校验，周期≤10ms |
导出FSR时，我习惯遵循几个原则：
- 每个FSR必须追溯到至少一个安全目标——不能有无源之水。
- FSR要分配ASIL等级——继承自安全目标，但可以分解。
- FSR要描述“什么”，而不是“怎么实现”——实现细节留给技术安全需求。
写FSR时，我常用“系统必须……以便……”的句式。比如：“系统必须在100ms内检测到扭矩传感器故障，以便在驾驶员失去助力前触发降级模式。”这样既说了功能，也说了意图。
4.3 安全机制的初步设计
安全机制，就是用来检测故障、防止违反安全目标的具体手段。说白了，它是安全设计的“执行层”。
安全机制分两大类：
- 故障检测机制：比如看门狗、ECC、CRC、自检、冗余比较。
- 故障响应机制：比如降级模式、安全关断、故障存储、报警。
我给大家画一张图，看看安全机制在系统里是怎么分布的：
你看，安全机制不是孤立的，它要覆盖整个信号链——从传感器到处理器，再到执行器，包括中间的通信。任何一个环节出问题，都可能违反安全目标。
4.4 安全机制的设计要点
设计安全机制时，我一般会问自己三个问题：
- 故障能被检测到吗？——检测覆盖率够不够？有没有盲区？
- 检测时间够快吗？——故障发生后，必须在故障容错时间间隔(FTTI)内响应。
- 响应动作正确吗？——进入安全状态后，会不会引发新的危险？
□ 每个安全目标至少分配一个安全机制
□ 安全机制的诊断覆盖率满足ASIL要求
□ 故障检测时间 ≤ FTTI - 响应时间
□ 安全状态定义明确，且可退出
□ 安全机制本身不会导致新的危害
举个例子，我之前做的一个线控制动项目，安全目标是“防止非预期制动”。我们设计了三个安全机制：
- 机制1：踏板位置传感器冗余比较（检测故障）
- 机制2：制动指令合理性校验（检测故障）
- 机制3：当检测到不一致时，立即切断制动执行器电源（响应故障）
嗯，这里要注意：机制3的响应动作“切断电源”本身会不会导致制动失效？会的。所以我们在安全概念里还要定义：切断电源后，驾驶员必须能通过机械备份完成制动。这就是安全机制设计的闭环思维。
有个项目，我们给电机控制器设计了过流保护机制。检测到过流就立即关断MOSFET。结果在高速行驶时，一次短暂的电流尖峰触发了保护，电机瞬间失去扭矩，差点造成事故。后来我们改成了“先降流，再关断”的分级响应。所以，安全机制不是越灵敏越好，要结合系统行为来设计。
4.5 FSC的输出物
功能安全概念阶段完成后，你应该能交付以下文档：
| 输出物 | 内容 | 格式建议 |
|---|---|---|
| 安全目标列表 | 每个危害事件对应的安全目标、ASIL、安全状态 | 表格+编号 |
| 功能安全需求规范 | 从安全目标导出的系统级安全需求 | ReqIF或Excel |
| 安全机制初步方案 | 每个安全目标对应的检测和响应机制 | 框图+文字描述 |
| 安全概念验证报告 | 通过评审或仿真验证安全概念的可行性 |
这些文档是后续技术安全概念(TSC)和软件安全需求(SSR)的输入。所以，FSC做得越扎实，后面的路就越顺。
每次做完FSC，我都会组织一次跨部门评审——让系统工程师、软件工程师、硬件工程师、测试工程师坐在一起，把安全目标和安全机制过一遍。很多时候，软件觉得“这个机制实现不了”，硬件觉得“那个检测太贵”，评审会上吵一吵，反而能吵出最优解。
好了，功能安全概念就讲到这里。记住一句话：安全目标定方向，安全需求搭框架，安全机制填血肉。这三件事做好了，你的功能安全设计就有了坚实的基础。