4、功能安全概念（FSC）：安全目标定义、功能安全需求导出、安全机制初步设计
好，我们进入功能安全概念阶段。说白了，FSC 就是把上一阶段做的 HARA 分析结果，真正落地成可执行的技术方案。我个人觉得，这是整个功能安全开发中最考验架构师功力的环节——你既要懂安全，又要懂系统，还得有工程直觉。
4.1 安全目标定义：从危害到目标的转化
安全目标（Safety Goal, SG）是什么？它是针对每一个危害事件，定义的最高层级安全要求。嗯，这里要注意：安全目标不是功能需求，它是「不发生什么」的承诺。
举个例子，我在一个 AEB 项目中，HARA 分析出来一个危害：车辆在高速行驶时，AEB 系统误触发导致急刹车，后车追尾。这个危害的 ASIL 等级是 C。那么对应的安全目标是什么？
SG-01：车辆在行驶过程中，AEB 系统应避免非预期的紧急制动，ASIL C。
你看，安全目标描述的是「避免什么」，而不是「怎么实现」。我见过不少新手工程师，上来就把安全目标写成「AEB 系统需要做前向碰撞检测」，这其实是功能需求，不是安全目标。
定义安全目标时，有几个关键点：
- 每个危害事件至少对应一个安全目标——但一个安全目标可以覆盖多个危害场景
- 安全目标必须可验证——你不能写一个没法测试的目标
- 安全目标的 ASIL 等级继承自危害的 ASIL——但可以通过安全分解降低
我的经验：安全目标的数量一般控制在 10-20 个之间。太少说明粒度太粗，容易遗漏；太多说明分解过度，后续管理成本会爆炸。我曾经在一个项目中看到 50 多个安全目标，结果评审会开了三天还没过完一半。
4.2 功能安全需求导出：从目标到需求
安全目标定义好了，下一步就是导出功能安全需求（Functional Safety Requirements, FSR）。FSR 是安全目标在系统层面的具体化，它描述了「系统应该做什么」来满足安全目标。
怎么导出？我个人习惯用「安全目标 → 功能场景 → 安全行为 → FSR」这条链路。
还是拿刚才的 AEB 误触发来说。安全目标是「避免非预期紧急制动」。那么我们需要思考：什么情况下会导致非预期紧急制动？
- 传感器误检测到障碍物
- 控制算法计算错误
- 执行器异常响应
- 通信链路故障
针对每一种可能，我们导出对应的 FSR：
| FSR ID | 描述 | ASIL | 关联 SG |
|---|---|---|---|
| FSR-01 | AEB 系统应具备传感器信号合理性检查功能，当检测到传感器信号异常时，应抑制制动请求 | C | SG-01 |
| FSR-02 | AEB 系统应具备制动请求仲裁机制，当多个控制源同时请求制动时，应选择最低减速度请求 | C | SG-01 |
| FSR-03 | AEB 系统应具备执行器反馈监控功能，当执行器响应与请求偏差超过阈值时，应进入安全状态 | C | SG-01 |
你想想看，每个 FSR 其实都是在回答一个问题：「如果这个环节出问题了，系统怎么兜底？」
避坑指南：我曾经在一个项目中，FSR 写得过于抽象，比如「系统应具备故障检测能力」。这种需求没法落地，因为没说明检测什么故障、检测到什么程度、检测到后怎么办。FSR 一定要具体到「谁、在什么条件下、做什么、达到什么效果」。
4.3 安全机制初步设计：让需求变成可实现的方案
FSR 出来了，接下来就是设计安全机制。安全机制就是实现 FSR 的具体技术方案。说白了，就是「用什么手段来保证安全」。
安全机制的设计，我建议从三个维度去考虑：
- 检测机制——怎么发现故障？比如看门狗、CRC 校验、信号范围检查
- 响应机制——发现故障后怎么办？比如降级、切换到冗余通道、进入安全状态
- 避免机制——怎么让故障不发生？比如冗余设计、多样性设计、故障静默
举个例子，针对 FSR-01（传感器信号合理性检查），我们可以设计这样的安全机制：
安全机制 SM-01：传感器信号交叉验证
- 使用两个独立传感器（如摄像头和毫米波雷达）分别检测前方障碍物
- 当两个传感器的检测结果偏差超过预设阈值时，判定为传感器信号异常
- 异常状态下，AEB 系统抑制制动请求，并通知 ADAS 域控制器进入降级模式
- 诊断覆盖率达到 99%，满足 ASIL C 要求
这里有个关键点：安全机制的设计要考虑诊断覆盖率。ISO 26262 对不同 ASIL 等级有明确的诊断覆盖率要求：
| ASIL 等级 | 单点故障诊断覆盖率要求 | 潜伏故障诊断覆盖率要求 |
|---|---|---|
| ASIL A | 无强制要求 | 无强制要求 |
| ASIL B | ≥ 90% | ≥ 60% |
| ASIL C | ≥ 97% | ≥ 80% |
| ASIL D | ≥ 99% | ≥ 90% |
嗯，这里要注意：诊断覆盖率不是拍脑袋定的，而是要通过 FMEDA（故障模式影响与诊断分析）来计算的。我建议在初步设计阶段，先根据经验估算一个覆盖率，后续再通过详细分析来验证。
4.4 安全机制的分类与选择
在实际项目中，安全机制的选择往往是个权衡过程。我总结了几类常用的安全机制：
- 硬件冗余：双通道、三模冗余——成本高，但可靠性好
- 软件多样性：不同算法实现同一功能——避免共因失效
- 自检机制：上电自检、周期自检——实现简单，但覆盖率有限
- 比较监控：两个独立通道计算结果比较——常用于 ASIL D 系统
- 故障响应：降级、容错、安全状态——决定了系统的鲁棒性
我的建议：不要一开始就追求最复杂的安全机制。先问自己三个问题：这个故障发生的概率有多大？故障发生后后果有多严重？有没有更简单的方案？我曾经在一个项目中，为了满足 ASIL B 的要求，设计了一套复杂的双通道冗余方案，结果后来发现一个简单的软件自检就能达到同样的覆盖率。嗯，有时候过度设计比不设计更可怕。
4.5 从 FSC 到下一阶段
功能安全概念阶段输出的核心产物包括：
- 安全目标列表（SG List）
- 功能安全需求规范（FSR Specification）
- 安全机制初步设计文档
- 安全概念验证报告
这些文档会作为输入，传递给下一阶段的技术安全概念（TSC）开发。在 TSC 阶段，我们会把系统级的安全需求进一步分解到硬件和软件层面。
最后说一句：FSC 阶段做得好不好，直接决定了后续开发的效率。我见过太多项目，FSC 阶段草草了事，结果到了 TSC 阶段发现安全目标定义不清、FSR 相互矛盾，不得不返工。嗯，磨刀不误砍柴工，这个道理在功能安全开发中尤其适用。