3. 功能安全概念(FSC)设计：安全目标定义、功能安全概念架构、安全机制分配、安全状态定义

好，咱们进入正题。功能安全概念设计，说白了就是回答三个问题：「要保什么？」「怎么保？」「保不住时怎么办？」。我做了这么多年项目，发现很多团队在这步容易「飘」——要么目标定得太高实现不了，要么概念设计太粗糙后面返工。咱们一步步拆开讲。

3.1 安全目标定义：从危害到目标的「翻译」

安全目标不是拍脑袋想出来的。它来自上一步的危害分析与风险评估（HARA）。你想想看，HARA 里我们识别出了危害事件，比如「车辆在高速上误加速」。那安全目标就是一条明确的约束：「车辆不得发生非预期的加速」。

我个人习惯，每个安全目标必须包含三个要素：

• 功能约束：系统不能做什么（或必须做什么）
• ASIL等级：从 HARA 继承来的风险等级
• FTTI（故障容错时间间隔）：从危害发生到系统必须响应的时间

举个例子，我参与过一个 L3 级高速领航项目。当时有个危害是「弯道中车道保持失效导致偏离」。对应的安全目标是这样写的：

这里有个坑，我曾经吃过亏——安全目标不能写得太「功能化」。比如「ACC 系统应能在 200ms 内响应前车减速」，这其实是功能需求，不是安全目标。安全目标应该描述「不发生什么坏事」，而不是「系统要做什么好事」。

3.2 功能安全概念架构：把目标「拆」到架构里

有了安全目标，下一步就是设计功能安全概念架构。说白了，就是回答：「哪些模块负责实现这个安全目标？」

我习惯用三层架构来思考：

1. 感知层：摄像头、雷达、激光雷达——负责检测危险场景
2. 决策层：规划与控制模块——负责做出安全决策
3. 执行层：转向、制动、动力系统——负责执行安全动作

嗯，这里要注意，功能安全概念架构不是系统架构的复制。它更关注「安全相关的功能分配」。比如，同样是制动系统，功能安全概念里要明确：

• 主制动路径（正常控制）
• 冗余制动路径（安全机制触发）
• 监控模块（检测故障并切换路径）

我记得有个项目，团队把安全概念架构画得跟系统架构一模一样，结果评审时被专家怼了——「你这安全机制在哪？故障检测在哪？安全状态切换路径在哪？」说白了，功能安全概念架构要突出「安全冗余」和「故障响应」这两条线。

3.3 安全机制分配：谁负责「兜底」？

安全机制分配，就是把每个安全目标对应的「保护措施」分配到具体模块上。我一般会列一个分配矩阵：

安全目标	安全机制	分配模块	ASIL	说明
SG-03	车道偏离检测与报警	感知融合模块	B	基于视觉的车道线检测
SG-03	转向扭矩监控	转向控制模块	B	检测非预期转向输入
SG-03	安全减速请求	车辆运动控制模块	B(D)	触发减速至安全状态

你可能会问：「一个安全目标需要多个安全机制吗？」答案是肯定的。因为单一机制可能失效。比如车道偏离检测失效了，转向扭矩监控还能兜底。这就是「纵深防御」的思想。

3.4 安全状态定义：出事了怎么办？

安全状态，就是系统在检测到故障后，要进入的「保命模式」。我见过最糟糕的设计是——故障后直接「死机」，车辆失去所有控制。这比故障本身还危险。

常见的自动驾驶安全状态包括：

• 降级模式：比如从 L3 降到 L2，要求驾驶员接管
• 最小风险策略（MRM）：如果驾驶员不接管，系统自动减速并靠边停车
• 紧急停车：在高速上直接刹停（一般不推荐，除非万不得已）

我个人习惯，每个安全目标都要定义「安全状态转换路径」：

1. 故障检测：谁发现故障？
2. 故障确认：是瞬态故障还是永久故障？
3. 状态切换：从正常模式切换到哪个安全状态？
4. 恢复条件：什么条件下可以退出安全状态？

3.5 文档编写要点：让评审一次过

功能安全概念文档，我建议按这个结构组织：

1. 安全目标列表：编号、描述、ASIL、FTTI、安全状态
2. 功能安全概念架构图：标注安全相关模块和冗余路径
3. 安全机制分配表：目标→机制→模块→ASIL→独立性说明
4. 安全状态定义表：每个安全状态的触发条件、行为、恢复条件
5. 故障响应时间分析：从故障发生到进入安全状态的时间线

嗯，最后说一句。功能安全概念设计不是一次性的。随着系统架构迭代，安全目标、安全机制都可能要调整。我见过最成功的团队，是把 FSC 当成「活文档」——每次架构变更，都同步更新 FSC。这样到了功能安全评审，才不会手忙脚乱。

好，这一章就到这。下一章咱们聊聊「技术安全概念（TSC）设计」，那是把 FSC 落到具体技术实现的关键一步。