第4章 系统级安全设计：系统架构设计、安全机制、故障容错与冗余设计

各位同学，欢迎来到系统级安全设计这一章。

说实话，前面几章我们聊了功能安全的概念、标准、还有危害分析。那些都是基础，是地基。但从这一章开始，我们要真正动手了。系统级安全设计，说白了就是回答一个问题：怎么让一辆自动驾驶车，在出故障的时候，还能安全地停下来，或者至少不撞人？

我个人习惯把系统级安全设计拆成三个层面来看：架构怎么搭、安全机制怎么加、故障来了怎么扛。咱们一个一个聊。

4.1 系统架构设计：安全是设计出来的，不是测试出来的

我记得刚入行那会儿，有个老前辈跟我说过一句话，我一直记到现在：「安全不是测出来的，是设计出来的。」

你想想看，如果架构本身就有缺陷，后面加再多安全机制，那也是亡羊补牢。所以，系统架构设计是功能安全的第一道防线。

4.1.1 架构设计的基本原则

做自动驾驶系统架构，我一般会遵循这么几个原则：

• 独立性：安全相关的功能，不能跟非安全功能搅在一起。比如，制动控制模块和娱乐系统，必须物理隔离。
• 可诊断性：系统要能自己「看病」。哪个传感器坏了、哪条通信链路断了，系统得能检测出来。
• 确定性：故障发生后的行为，必须是可预测的。不能出现「这次刹车失灵，下次又好了」这种随机行为。

4.1.2 典型的自动驾驶系统架构

目前主流的自动驾驶架构，我把它归纳为三层：

层级	功能	安全关注点
感知层	摄像头、激光雷达、毫米波雷达、超声波	传感器故障、数据一致性、时间同步
决策规划层	行为预测、路径规划、控制决策	算法失效、计算超时、内存溢出
执行层	线控制动、线控转向、动力系统	执行器卡滞、响应延迟、通信中断

嗯，这里要注意：每一层都要有自己的安全监控机制。不能指望感知层出了问题，让执行层去兜底。各层先管好自己。

4.2 安全机制：给系统装上「安全气囊」

架构搭好了，接下来就是往里加安全机制。安全机制是什么？就是当系统出现故障时，用来检测、控制、减轻危害的那些「小工具」。

我曾经在一个项目中，遇到过传感器数据跳变的问题。激光雷达突然报出一个距离为0的点，导致车辆急刹。后来我们加了一个「合理性检查」机制，说白了就是：如果某个数据变化太快，先怀疑它是不是坏了。

4.2.1 常见的检测机制

• 心跳监控：每个安全相关的模块，定期发一个「我还活着」的信号。如果超时没收到，就认为模块挂了。
• 范围检查：比如车速不能超过物理极限，转向角不能超过机械限位。
• 一致性检查：两个冗余传感器测出来的值，差异不能太大。比如两个IMU测的加速度，差超过0.5m/s²，就报警。
• 时序监控：任务的执行时间不能超过预设的deadline。超时了，就认为系统过载或死锁。

4.2.2 控制机制与降级策略

检测到故障之后，系统不能傻站着。得有应对措施。我一般把降级策略分为几个等级：

1. 警告：故障轻微，系统继续运行，但通知驾驶员或后台。
2. 降级：比如主传感器坏了，切换到冗余传感器。或者从L4降级到L2，要求驾驶员接管。
3. 安全停车：如果故障严重，比如制动系统部分失效，系统执行最小风险策略（MRM），靠边停车。
4. 紧急停车：最极端的情况，比如通信完全中断，系统直接紧急制动。

你想想看，如果没有这些降级策略，系统一旦出问题，就是「要么全好，要么全坏」的二元状态。这太危险了。

4.3 故障容错与冗余设计：别把鸡蛋放在一个篮子里

这一节，是系统级安全设计的重头戏。故障容错，说白了就是：系统出了故障，还能继续工作，或者至少安全地停下来。

冗余设计是实现故障容错最直接的手段。但冗余不是简单的「多买一套设备装上」，那样成本太高，而且不一定有效。

4.3.1 冗余设计的三种模式

冗余类型	描述	典型应用
硬件冗余	关键部件备份，比如双ECU、双传感器	制动系统、转向系统
信息冗余	通过算法或校验码，检测和纠正错误	CAN总线CRC校验、海明码
时间冗余	重复执行任务，对比结果	安全关键计算、投票机制

我个人习惯，在自动驾驶系统中，硬件冗余是底线，信息冗余是日常，时间冗余是补充。

4.3.2 一个实际的冗余设计案例

拿制动系统来说吧。我记得在某个项目中，我们设计了「双通道制动」架构：

• 主通道：线控制动（电信号控制液压）。
• 备份通道：机械液压制动（直接踩踏板，通过液压管路传递）。

当主通道失效时，备份通道自动激活。虽然制动响应会慢一点，但至少能刹住车。

这里有个关键点：两个通道必须相互独立。不能共用一个电源、不能共用一个控制器、甚至不能走同一根线束。否则，一个故障就能把两个通道都干掉。

4.3.3 故障容错的实现策略

除了冗余，故障容错还有几个常用的策略：

• 故障静默：故障模块主动切断输出，不让错误信号污染系统。比如，一个故障的ECU，自己把自己从CAN总线上「踢」下去。
• 故障降级：系统自动切换到安全模式，放弃部分功能，保住核心安全功能。
• 故障恢复：有些故障是瞬时的，比如电磁干扰导致的数据错误。系统可以尝试复位或重试，恢复正常工作。

嗯，这里要补充一句：故障恢复一定要谨慎。我曾经见过一个系统，频繁复位导致车辆在高速上「抽搐」。后来我们加了一个「复位次数限制」，比如10分钟内最多复位3次，超过就永久停机。

4.4 小结与个人经验

这一章的内容，其实就三句话：

1. 架构是骨架，决定了系统能扛多大的风险。
2. 安全机制是肌肉，让系统能感知和应对故障。
3. 冗余和容错是保险，确保在最坏的情况下，系统还能安全收场。

最后，分享一个我自己的教训。早期做项目时，我总觉得冗余越多越好，结果系统变得又重又贵，而且故障率反而高了——因为部件多了，出故障的概率也大了。

后来我明白了：冗余不是越多越好，而是「刚刚好」。这个「刚刚好」，就是基于危害分析和风险评估（HARA）的结果来定的。该冗余的地方，一个都不能少；不该冗余的地方，一个都不要多。

好了，这一章就到这里。下一章，我们会深入聊聊「软件层面的安全设计」，包括ASIL分解、软件分区、以及安全通信协议。到时候见。