对于L3以上的自动驾驶系统“停下来”不是选项必须“继续跑”。这就需要冗余与容错设计。为什么ASIL-D离不开冗余回顾一下第5期我们讲过的内容ASIL-D要求系统的随机硬件失效概率低于10⁻⁸/小时。这是什么概念一台设备连续运行超过1万年才允许发生1次失效。单靠“高质量的元器件”根本达不到这个要求——再好的芯片也有老化、也有被电磁干扰导致位翻转的可能。唯一的出路就是冗余。ISO 26262-5:2018的附录D中列出了控制器硬件可能存在的各种故障及对应的安全措施。其中冗余设计被列为应对ASIL C/D等级的核心手段。冗余的核心逻辑如果单个组件的可靠性不够高那就用多个组件同时工作——只要不是所有组件同时失效系统就能继续运行。安全机制一双核锁步DCLS——芯片内部的“双保险”什么是双核锁步双核锁步Dual-Core LockstepDCLS是ASIL-D级别芯片中必备的明星功能之一。它的核心思想极其简单两个处理器核心同步执行完全相同的指令实时比较输出结果。如果结果不一致说明至少有一个核出错了。关键点两个核心接收完全相同的输入指令、数据、时钟、复位信号在同步的条件下执行完全相同的代码流。硬件比较器在每个时钟周期或关键节点检查输出一旦发现差异立即触发安全响应。为什么要“锁步”“锁步”这个名字很形象——就像两个人并肩齐步走步伐必须完全一致。如果两个核心只是“各自跑各自的”出问题了你根本发现不了。锁步的精髓在于两个核心必须在同一个时钟周期执行同一个操作硬件比较器在每个周期都盯着它们。英飞凌AURIX TC3xx系列的LockStep核能在纳秒级检测到计算偏差。英伟达Orin芯片的双核锁步架构中比较器每10纳秒检测一次输出差异检测到不一致时50微秒内触发复位或降级。DCLS的诊断覆盖率有多高DCLS可以达到很高的故障诊断覆盖率。根据行业数据双核锁步在EPS转向控制等高实时性场景中故障检测率可达99.9%。在安全分析中DCLS理论上可以对目标模块提供100%的覆盖率。诊断覆盖率 vs. 故障检测率这两个术语在ISO 26262语境下基本可以互换使用。DCLS的99.9%意味着1000个可能发生的故障中有999个能被锁步机制检测到。DCLS的局限只能“检测”不能“纠错”这里有个重要的区分技术能做什么大白话双核锁步DCLS检测错误 ✅“我知道出问题了”三模冗余TMR检测 纠正错误 ✅✅“我知道出问题了而且我知道正确答案是什么”DCLS只能告诉你“两个核结果不一样至少有一个错了”但它不知道哪个是对的。所以DCLS通常需要配合其他机制——检测到错误后触发复位、切换备份系统或进入安全状态。DCLS的代价天下没有免费的午餐。DCLS的代价是代价说明芯片面积增加多一个核心面积翻倍成本上升更大的芯片 更高的成本⚡功耗增加两个核心同时运行功耗翻倍设计复杂度同步机制复杂中断处理、分支预测需特殊设计实践中并非整个芯片的所有模块都会纳入DCLS——如果TCM紧耦合内存和Cache本身已经做了完善的安全机制如ECC这些部分通常就不会被包含在DCLS的冗余范围中。安全机制二三模冗余TMR——三个臭皮匠顶个诸葛亮什么是三模冗余三模冗余Triple Modular RedundancyTMR是比DCLS更进一步的冗余方案。它的核心思想是用三个独立的模块执行同一任务通过“多数投票”机制决定最终输出——少数服从多数。2oo3系统三个模块中只要有两个或以上输出一致系统就能继续正常运行。TMR vs. DCLS一字之差天壤之别对比项双核锁步DCLS三模冗余TMR核心数量2个3个能做什么检测错误检测 纠正错误输出机制不一致 → 触发报警少数服从多数 → 输出正确结果容错能力单点故障 → 系统仍可能中断单点故障 →系统继续正常运行诊断覆盖率99.9%99.99%适用场景高实时性场景EPS转向控制动力系统等高安全场景ESP制动TMR的核心优势即使一个模块完全失效另外两个模块的投票结果仍然是正确的——系统完全不受影响。TMR在汽车中的实战应用TMR在汽车电子中有广泛的应用场景ESP制动系统通过三个传感器或三个MCU的多数表决实现容错ADAS集成照明ECU三个并行照明控制通道通过多数投票机制实时识别并屏蔽单点故障达到ASIL-B等级故障码存储对ASIL B及以上等级的故障码采用TMR存储通过多数表决确保数据可靠性TMR的一个关键细节投票器本身也可能坏TMR的多数投票器Voter本身也是一个硬件组件——它也可能失效。如果投票器坏了即使三个模块都正常工作输出也可能被错误地丢弃或篡改。解决方案投票器本身也需要进行安全设计。有些方案采用自校验投票器能够检测自身故障有些方案则对投票器也做冗余。思考题如果你设计一个TMR系统投票器你会怎么处理欢迎在评论区分享你的思路安全机制三冗余架构模式——1oo2、2oo3是什么在系统架构层面冗余设计有多种标准化的“模式”。这些**“m-out-of-n”** 表示法是功能安全领域的通用语言。1oo21 out of 2——“一个工作就行”两个通道并行工作任意一个通道正常工作系统就能运行。特性说明通道数2个工作条件至少1个通道正常优点可用性高——一个坏了另一个顶上缺点无法检测“哪个是对的”——两个通道结果不一致时系统不知道该信谁2oo22 out of 2——“两个都得工作”两个通道必须同时正常工作系统才能运行。特性说明通道数2个工作条件2个通道都正常优点安全性高——任何异常都能被发现缺点可用性低——一个坏了系统就停了2oo32 out of 3——“多数说了算”三个通道至少两个正常工作系统就能运行。特性说明通道数3个工作条件至少2个通道正常优点安全性和可用性的最佳平衡——容忍单点故障且能通过投票确定正确结果缺点成本最高3套硬件三种模式的对比模式通道数容错能力安全性可用性成本1oo22容忍1个故障中高中2oo22不容忍故障高低中2oo33容忍1个故障高高高实战选择对于ASIL-D的线控制动系统通常选择2oo3架构——因为既不能容忍“停了”需要高可用性也不能容忍“错了”需要高安全性。从Fail-Safe到Fail-Operational自动驾驶催生的范式革命两种安全哲学的对比在第16期我们简单提过Fail-Safe和Fail-Operational的区别现在结合冗余技术深入聊聊对比项Fail-Safe故障安全Fail-Operational故障运行核心理念“出故障了就停下来”“出故障了还要继续跑”适用场景非关键功能L3以上自动驾驶冗余要求低高必须有多重冗余典型架构单通道 监控双通道/三通道冗余为什么L3以上必须用Fail-Operational因为在L3级自动驾驶中系统承担驾驶任务驾驶员不需要时刻监控。如果系统突然“停下来”——哪怕只是短暂中断——都可能造成严重事故。Fail-Operational架构的冗余要求实现Fail-Operational需要在每一个关键环节部署冗余环节冗余要求实战示例传感器多传感器异构冗余摄像头毫米波雷达激光雷达计算双域控或三域控冗余“双Orin X”方案⚡执行双绕组电机/双执行器线控转向双电机通信双总线/双链路CAN-FD 车载以太网⚡供电双路供电主电备电实战案例小马智行L4域控制器小马智行的L4级自动驾驶域控制器采用了多层安全架构和降级策略实现了Fail-Operational能力——当主系统发生故障时控制器可以无缝切换到冗余系统或最小风险条件控制器MRCC确保车辆安全控制。关键洞察Fail-Operational不是“堆一堆冗余硬件”就行而是需要从架构设计之初就把冗余嵌入每一个环节——从传感器到计算到执行到供电全覆盖。实战ACC雷达模块的冗余设计完整配置把以上三种冗余机制整合到ACC雷达模块的硬件设计中Step 1传感器层冗余冗余设计具体配置目的双雷达冗余两颗77GHz毫米波雷达单雷达失效另一颗继续工作异构传感器冗余雷达 前向摄像头不同技术原理避免共因失效信号交叉校验雷达数据 vs 摄像头数据发现差异时触发报警Step 2计算层冗余冗余设计具体配置目的DCLS双核锁步MCU内部双核锁步检测计算错误诊断覆盖率99.9%双MCU冗余主MCU 监控MCU主MCU失效监控MCU接管算法多样性两套独立实现的跟车距离算法避免软件共因失效Step 3执行层冗余冗余设计具体配置目的双执行器主制动执行器 备用执行器主执行器失效备用接管输出投票2oo3架构三个通道投票单点故障不影响输出Step 4供电与通信冗余冗余设计具体配置目的双路供电主电源 备用电源单路断电另一路供电双通信链路CAN-FD 车载以太网单链路中断另一链路继续