线控底盘 / 功能安全

线控底盘功能安全从 0 到 1：架构设计、Fail-Operational 与测试验证

2025/11/22 · 进阶 · 9 分钟

从系统边界、失效模式、冗余架构和验证证据四个层面，梳理线控底盘功能安全从概念到工程落地的基本路径。

线控底盘讨论到功能安全时，很容易陷入术语堆叠：ASIL、HARA、FMEA、FTTI、冗余、降级、诊断覆盖率。真正的工程难点不在会不会说这些词，而在能不能把它们连接成一条可审查的证据链。

这篇文章只讨论公开、通用的工程方法，不涉及任何具体项目、公司、车型、内部接口或未授权数据。

先定义系统边界

线控底盘不是一个单独控制器，而是一组系统能力的组合。做功能安全之前，需要先说清楚哪些对象在边界内：

• 控制器负责哪些功能，哪些只是转发或监控。
• 执行器是否具备独立降级能力。
• 传感器、通信、电源和机械结构如何互相约束。
• 自动驾驶请求、驾驶员输入和底盘执行之间的优先级如何定义。

如果边界不清楚，后续的 HARA、FMEA、测试用例和安全论证都会变成“局部正确但系统不闭合”。

再识别失效模式

线控系统的典型失效来源可以分为五类：

1. 传感器异常：断线、漂移、卡滞、噪声、不同传感器之间不一致。
2. 控制器异常：任务超时、状态机卡死、重启、内存错误、软件版本不一致。
3. 执行器异常：响应迟滞、输出不足、卡滞、过热、位置反馈异常。
4. 通信异常：报文丢失、超时、错序、数据损坏、总线负载过高。
5. 电源异常：欠压、瞬断、供电路径单点失效、备用能量不足。

这些失效模式不是为了写表格而写表格。它们要继续推导出三个问题：能否检测，多久检测，检测后做什么。

Fail-Silent 与 Fail-Operational 的区别

Fail-Silent 的核心是“发现异常后停止输出”，适合故障后可以安全退出的功能。Fail-Operational 的核心是“故障后仍保持有限能力”，适合无法立刻失去控制能力的系统。

线控底盘的工程判断通常不应该停留在二选一，而应该对每个功能定义降级层级：

• 全功能运行：系统按设计能力工作。
• 降级运行：失去部分性能，但仍能保持基本控制。
• 最小风险状态：不追求性能，只追求可控和可解释。
• 安全退出：把控制权或风险暴露显式交给上层流程处理。

好的设计会把“检测条件、确认条件、降级动作、恢复条件、驾驶员或上层系统提示”写成可验证的状态机，而不是散落在代码和文档里。

冗余不是越多越安全

冗余设计的目标不是堆硬件，而是消除关键单点故障。常见冗余包括传感器冗余、控制器冗余、通信冗余、电源冗余和执行器冗余。每一种冗余都要回答：

• 冗余通道是否真的独立。
• 共因失效如何控制。
• 主备切换是否可验证。
• 降级后剩余能力是否足够进入最小风险状态。
• 冗余带来的复杂度是否反而增加了新风险。

例如，两个传感器如果共享同一供电路径、同一连接器或同一软件解析链路，并不能简单宣称“已经双冗余”。功能安全审查关注的是独立性、诊断覆盖和失效后行为，而不是数量本身。

通信与 DBC 也是安全边界

很多线控问题最后暴露在通信层。信号定义、字节序、物理值转换、无效值、周期、超时、计数器、CRC、优先级和总线负载都可能成为安全机制的一部分。

工程上至少要把以下内容写清楚：

• 安全相关报文的周期和超时阈值。
• 无效值与默认值如何处理。
• 计数器和 CRC 覆盖哪些信号。
• 持续超时、偶发丢帧和数据异常是否走不同策略。
• 总线负载升高时是否影响关键报文时延。

通信协议不是“集成阶段再调”的细节，它会直接影响故障检测时间和降级策略。

测试验证要覆盖故障注入

正常工况测试只能证明系统“能工作”，不能证明系统“故障后仍可控”。线控底盘功能安全验证至少要覆盖三类证据：

1. 静态证据：需求追溯、架构审查、FMEA、接口审查、代码检查。
2. 仿真与台架证据：HIL、故障注入、边界条件、状态机切换、通信异常。
3. 系统级证据：集成测试、环境边界、恢复策略、日志与诊断信息。

每个故障注入用例都应该记录：注入方式、检测时间、确认逻辑、降级结果、恢复条件和日志证据。否则测试很容易停留在“看起来报警了”的层面。

工程落地清单

做线控底盘功能安全方案时，可以用下面的清单做第一轮自检：

• 系统边界是否清楚。
• 安全目标是否能追溯到具体危害。
• 失效模式是否覆盖传感器、控制器、执行器、通信和电源。
• 每个关键故障是否定义检测时间和降级动作。
• 冗余通道是否具备足够独立性。
• 通信协议是否包含超时、计数器、CRC、无效值和恢复策略。
• 测试用例是否覆盖正常工况、边界工况和故障注入。
• 日志和诊断信息是否足以支撑问题复盘。

结论

线控底盘功能安全不是某一个模块的安全，也不是文档末尾的一张 FMEA 表。它是一套从危害、架构、失效、降级到验证的闭环。

越是复杂的系统，越需要把“能不能检测、多久检测、故障后还能做什么、证据在哪里”讲清楚。只有这些问题被连续回答，Fail-Operational 才从概念变成工程能力。