第4章：功能安全概念——安全目标、FSC开发与FTTI定义
各位好，欢迎来到第4章。前面我们聊了危害分析和风险评估，也就是HARA。做完HARA，你手里会有一张表，里面列着各种危害事件和对应的ASIL等级。但光有这张表还不够——你接下来要回答一个核心问题：“系统到底要怎么做，才能把这些风险降到可接受的水平？”
这就是功能安全概念（FSC）要干的事。我个人觉得，FSC是整个安全开发中最体现“设计智慧”的阶段。它不是让你堆一堆监控机制，而是要你精准地、高效地把安全要求落实到系统架构里。
核心要点：功能安全概念是把“安全目标”翻译成“系统级安全要求”的过程。它决定了你的系统在发生故障时，到底该怎么“保命”。
4.1 安全目标定义——从危害到目标的“翻译”
安全目标（Safety Goal, SG）是什么？说白了，它就是针对每个危害事件，你给系统定下的最高层级的安全要求。
举个例子。你分析出一个危害事件：“车辆在高速行驶时，非预期的动力中断导致追尾”。那对应的安全目标可能就是：“防止车辆在行驶中非预期地失去驱动力”。
定义安全目标时，有几个坑我踩过，跟大家分享一下：
- 目标要“可验证”：别写“系统要足够安全”这种废话。要写“当检测到驱动系统故障时，在100ms内进入安全状态”。
- ASIL等级要继承：安全目标的ASIL等级，直接来自HARA中对应危害事件的最高ASIL等级。别自己乱降级。
- 一个目标对应一个危害：我见过有人试图用一个安全目标覆盖多个危害，结果后面安全机制设计得一塌糊涂。建议一对一。
| 危害事件示例 | ASIL | 安全目标（SG） |
|---|---|---|
| 高速行驶中非预期动力中断 | ASIL C | 防止车辆在行驶中非预期失去驱动力 |
| 制动时非预期加速 | ASIL D | 防止制动过程中出现非预期加速 |
| 转向时非预期锁死 | ASIL D | 防止转向系统在行驶中非预期锁死 |
我的习惯：每定义一个安全目标，我都会在旁边标注它的“安全状态”和“故障容错时间间隔（FTTI）”。这两个参数后面会反复用到，提前写好能省很多事。
4.2 功能安全概念（FSC）开发——把目标变成方案
有了安全目标，接下来就是FSC开发。这一步要回答：“系统通过什么方式，来保证安全目标被满足？”
FSC的核心输出是功能安全概念，它包含：
- 安全机制的定义：比如故障检测、故障响应、冗余设计等。
- 安全机制的分配：这些机制要分配到具体的系统元素上（传感器、控制器、执行器）。
- 安全状态的描述：系统在检测到故障后，应该进入什么状态？
- FTTI的定义：从故障发生到系统进入安全状态，允许的最大时间。
我记得有一次做EPS（电动助力转向）项目，安全目标是“防止非预期转向”。我们设计的安全机制包括：
- 扭矩传感器信号合理性检查（检测故障）
- 电机电流监控（检测故障）
- 安全关断路径（故障响应，切断电机供电）
- 冗余扭矩路径（降级模式，保留基本助力）
这些机制分配下去，你会发现系统架构图开始变得复杂了。嗯，这是正常的。
注意：FSC开发不是一次性的。随着设计深入，你可能会发现某些安全机制实现不了，或者成本太高。这时候需要迭代——但任何变更都要做影响分析，别偷偷改。
4.3 安全机制分配——谁该干什么？
安全机制分配，就是把你在FSC里定义的那些“检测”和“响应”动作，落实到具体的硬件或软件模块上。
举个例子，还是那个EPS项目：
| 安全机制 | 分配到的元素 | 说明 |
|---|---|---|
| 扭矩传感器信号合理性检查 | 主控制器（软件） | 比较两个传感器信号差值是否超限 |
| 电机电流监控 | 电流传感器 + 主控制器 | 硬件采集，软件判断 |
| 安全关断路径 | 安全继电器（硬件） | 独立于主控的硬件关断路径 |
| 冗余扭矩路径 | 备用控制器 + 备用电机绕组 | 降级模式下的替代路径 |
这里有个关键点：安全机制的独立性。你想想看，如果检测故障和响应故障用的是同一个控制器，那控制器本身出问题了怎么办？所以，安全关断路径我通常会设计成独立的硬件路径，不依赖主控器的软件逻辑。
避坑指南：我曾经在一个项目里，把故障检测和故障响应都放在同一个MCU上。结果FMEDA一算，单点故障覆盖率不够。后来不得不加了一个独立的硬件监控芯片。所以，分配安全机制时，脑子里要时刻想着“独立性”和“多样性”。
4.4 故障容错时间间隔（FTTI）定义——时间就是生命
FTTI，全称Fault Tolerant Time Interval。它指的是：从故障发生，到系统进入安全状态，所允许的最大时间间隔。
这个参数怎么定？不是拍脑袋。它取决于：
- 危害的严重程度：越严重的危害，FTTI通常越短。
- 系统的物理响应时间：比如制动系统，从故障到车辆失控可能只有几百毫秒。
- 安全机制的检测和响应时间：你设计的机制能不能在这个时间内完成？
我举个例子。对于“防止非预期加速”这个安全目标，FTTI可能是100ms。为什么？因为如果加速踏板故障导致全油门，驾驶员在100ms内可能还来得及踩刹车。超过这个时间，风险就不可接受了。
FTTI的分解也很重要。它通常被拆成：
- 故障检测时间（FDT）：从故障发生到被检测到。
- 故障响应时间（FRT）：从检测到故障到系统进入安全状态。
你设计的每个安全机制，都要满足这个时间预算。比如：
- FDT ≤ 60ms（留给诊断算法）
- FRT ≤ 40ms（留给执行器动作）
- 总FTTI ≤ 100ms
注意：FTTI不是越短越好。太短的时间要求会导致设计成本飙升，甚至无法实现。合理的做法是：基于系统动力学和危害分析，给出一个“刚好够用”的值。
4.5 知识结构图：功能安全概念开发流程
下面这张图，是我自己总结的FSC开发流程。你可以把它当作一个检查清单，做项目时对着走一遍，基本不会漏东西。
4.6 本章小结
这一章我们走了功能安全概念开发的完整路径：
- 安全目标定义：从危害到目标的翻译，要可验证、可追溯。
- FSC开发：把安全目标变成系统级的安全方案，包括机制、分配、状态和时间。
- 安全机制分配：把机制落实到具体的系统元素上，注意独立性和多样性。
- FTTI定义：给每个安全目标定一个“死线”，然后分解给检测和响应机制。
说实话，FSC做得好不好，直接决定了后续详细设计的成败。我见过太多项目，FSC阶段草草了事，结果到了硬件设计和软件实现阶段，发现安全机制根本没法落地，或者覆盖率不够，最后不得不返工。嗯，那滋味可不好受。
所以，我的建议是：在FSC阶段多花点时间，把每个安全目标、每个安全机制、每个时间参数都掰扯清楚。后面你会感谢自己的。