4、功能安全概念（FSC）：安全目标定义、功能安全需求导出、安全机制分配
好，咱们进入功能安全概念阶段。说实话，这是整个安全开发流程里最需要「动脑子」的一环。前面你做了HARA，拿到了ASIL等级，但那只是「知道问题在哪」。现在要干的，是「怎么解决问题」。
我个人习惯把FSC比作「盖房子的施工图」。你不能光说「这房子要抗震」，你得说清楚「柱子要多粗、钢筋怎么扎、混凝土标号多少」。安全目标就是那个「抗震要求」，功能安全需求就是「柱子和钢筋的规格」，安全机制就是「施工工艺和质检手段」。
核心逻辑链：
危害事件 → 安全目标（SG） → 功能安全需求（FSR） → 安全机制分配
每一步都是「为什么」到「怎么做」的细化。
4.1 安全目标定义：把「危险」翻译成「安全要求」
安全目标，说白了就是一句话：「系统绝对不能出现某某情况」。它是对危害事件的顶层约束。
怎么写一个合格的安全目标？ 我总结了三个要素：
- 明确危害事件：比如「车辆在高速上误触发紧急制动」
- 指定安全状态：比如「系统应抑制非预期的制动请求，保持当前车速」
- 分配ASIL等级：直接从HARA结果拿过来
举个例子，我在做AEB项目时，有一个典型的安全目标：
SG-001：系统应避免在目标车道无车辆时，误触发自动紧急制动。
安全状态：抑制制动请求，维持当前车速或滑行。
ASIL：B(D)
FTI（故障容错时间间隔）：≤ 200ms嗯，这里要注意。FTI这个参数很多人会漏掉。它决定了你的安全机制响应速度。我曾经见过一个团队，安全目标写得漂漂亮亮，结果FTI设了个1秒，硬件根本做不到，最后只能降级。所以，FTI一定要和系统架构师、硬件工程师对齐。
避坑指南：
我曾经犯过一个错：把安全目标写成了「系统应保证不撞车」。这太模糊了。不撞车是最终结果，但安全目标要定义的是「系统不能做什么」。正确的写法是「系统应避免在无碰撞风险时输出制动请求」。
4.2 功能安全需求导出：从「顶层目标」到「系统级要求」
安全目标定好了，接下来要导出功能安全需求。这一步很多人会搞混——FSR不是软件需求，也不是硬件需求，它是「系统层面的安全要求」。
怎么导？我个人习惯用「逐层分解法」：
- 识别安全目标涉及的子系统：比如感知、决策、执行
- 分析每个子系统需要做什么：才能避免或检测那个危害
- 写出具体的FSR：带上ASIL等级和FTI
还是拿AEB的例子。SG-001要求「避免误触发」，那感知系统需要做什么？
| FSR编号 | 需求描述 | ASIL | 关联SG |
|---|---|---|---|
| FSR-001 | 感知系统应能在200ms内检测到目标车道无车辆，并输出「无目标」状态 | B(D) | SG-001 |
| FSR-002 | 感知系统应能在目标识别置信度低于阈值时，输出「不确定」状态，禁止触发制动 | B(D) | SG-001 |
| FSR-003 | 感知系统应具备自检机制，在传感器故障时1ms内上报「传感器失效」状态 | B(D) | SG-001 |
你想想看，FSR其实就是在回答一个问题：「如果这个子系统出了问题，怎么保证安全目标不被破坏？」
注意： FSR的ASIL等级不能低于它关联的安全目标。但可以更高——如果你觉得某个子系统特别关键，可以往上提一级。不过我个人不建议随意升级，成本会飙升。
4.3 安全机制分配：把「要求」落实到「具体方案」
FSR写完了，接下来就是「怎么实现」。安全机制分配，就是把每个FSR分配给具体的硬件或软件模块，并定义实现方式。
常见的感知系统安全机制有哪些？我列几个典型的：
- 传感器冗余：比如摄像头+毫米波雷达，互相校验
- 自检机制：上电自检、周期自检、故障注入测试
- 信号合理性检查：比如车速不能突变、目标距离不能跳变
- 看门狗：监控算法运行是否超时
- 安全状态机：定义正常、降级、故障三种模式
举个例子，FSR-002要求「置信度低时禁止触发制动」。这个怎么实现？
安全机制分配：
- 机制名称：目标置信度阈值检查
- 实现模块：感知融合模块（软件）
- 触发条件：目标置信度 < 0.7
- 响应动作：输出「目标不确定」标志位，决策层收到后抑制制动请求
- 诊断覆盖率：90%（通过故障注入测试验证）
- ASIL：B(D)这里有个关键点：诊断覆盖率。说白了就是「这个机制能检测出多少比例的故障」。90%意味着还有10%的故障漏网。那怎么办？再加一层机制。比如再加一个「传感器数据一致性检查」，两个机制叠加，覆盖率就能到99%。
我的经验：
安全机制分配时，一定要考虑「独立性」。两个机制不能共用同一个失效模式。比如你用了两个摄像头做冗余，但两个摄像头共用同一个电源——那电源一挂，两个都完蛋。这就不是真正的冗余。我曾经在评审时发现过这种问题，后来改成了独立供电。
4.4 一个完整的FSC示例（感知系统）
咱们把上面讲的串起来，看一个完整的例子。假设场景是「高速公路上，自车与前车距离过近，需要触发AEB」。
安全目标：
SG-002：系统应避免在目标车辆真实存在时，漏触发自动紧急制动。
安全状态：在FTI内输出制动请求。
ASIL：C
FTI：≤ 100ms功能安全需求：
FSR-004：感知系统应在100ms内检测到前车距离 ≤ 安全阈值，并输出「碰撞风险」标志。
ASIL：C
FSR-005：感知系统应在传感器数据丢失或异常时，100ms内输出「传感器故障」标志，触发降级模式。
ASIL：C安全机制分配：
| FSR | 安全机制 | 实现模块 | 诊断覆盖率 |
|---|---|---|---|
| FSR-004 | 前向毫米波雷达+摄像头融合检测 | 感知融合模块 | 95% |
| FSR-004 | 距离合理性检查（连续帧差值 ≤ 5m） | 感知后处理模块 | 85% |
| FSR-005 | 传感器心跳监测（每10ms上报一次） | 传感器驱动层 | 99% |
| FSR-005 | 看门狗定时器（超时触发复位） | MCU硬件 | 99% |
你看，一个FSR可能对应多个安全机制。FSR-004用了两个机制，一个负责「检测」，一个负责「验证」。这就是「多样性冗余」的思路。
总结一下：
功能安全概念阶段，核心就是三件事：
- 定目标（SG）：系统绝对不能出现什么
- 提要求（FSR）：每个子系统要做什么来避免
- 分机制：具体用什么技术手段来实现
这三步走扎实了，后面的技术安全概念（TSC）和软硬件设计才有依据。否则，你后面做得再漂亮，也是空中楼阁。
嗯，今天就到这儿。下一章咱们讲技术安全概念，那才是真正「撸起袖子干活」的阶段。到时候我会拿一个实际的感知算法案例，带大家一步步写TSC。