1、冗余架构概述：转向系统冗余的必要性、功能安全等级(ASIL-D)要求、冗余架构的基本概念与分类

1.1 为什么转向系统必须冗余？

说实话，我刚入行那会儿，对转向系统做冗余这件事还没那么深的体会。直到有一次，我在一个L3级自动驾驶项目中，亲眼看到一台测试车因为转向电机控制器的一颗MOSFET短路，方向盘直接卡死在15度偏角——车速80km/h，你想想看，那是什么概念？

转向系统，是车辆横向控制的唯一执行器。制动失效了，你还能靠手刹、靠滑行；动力丢了，大不了靠边停。但转向一旦出问题，尤其是在高速或变道场景下，后果是灾难性的。

所以，冗余不是“锦上添花”，而是“保命底线”。

我个人习惯把冗余的必要性归纳为三个层面：

• 功能安全驱动：ISO 26262要求ASIL-D等级的系统，单点故障度量(SPFM)必须≥99%，潜在故障度量(LFM)必须≥90%。不冗余，根本过不了这个指标。
• 自动驾驶需求：L3及以上，驾驶员不再时刻监控路况。系统必须自己扛住故障，完成最小风险策略(MRM)。
• 法规强制：UN R79、GB 17675等法规已明确要求，具备自动驾驶功能的车辆，转向系统必须提供冗余方案。

1.2 ASIL-D到底有多严？

很多刚接触功能安全的工程师会问：“ASIL-D到底意味着什么？”

嗯，我这么跟你说吧。ASIL-D是汽车功能安全等级的天花板。它要求系统在发生任意单点故障时，仍然能维持安全状态。对于转向系统来说，这个“安全状态”不是停车，而是——继续提供可控的转向能力。

我在一个项目中做过评估：一个典型的EPS（电动助力转向）系统，如果只做单电机+单控制器，ASIL-D的随机硬件失效率指标几乎不可能达标。为什么？因为转向系统的危险事件（比如非预期转向助力丢失）的暴露时间太长——你开车一小时，这一小时里随时可能出问题。

安全目标	ASIL等级	单点故障度量要求	潜在故障度量要求
避免非预期转向助力丢失	ASIL-D	≥99%	≥90%
避免非预期转向角度变化	ASIL-D	≥99%	≥90%
避免转向锁死	ASIL-D	≥99%	≥90%

说白了，ASIL-D就是逼着你做冗余。不做冗余，你连FMEDA（失效模式影响与诊断分析）都填不满。

1.3 冗余架构的基本概念

冗余架构，听起来高大上，其实核心就一句话：用多套资源，保证单点故障不导致功能丧失。

我习惯把冗余分为两大类：

• 硬件冗余：双电机、双控制器、双电源、双CAN/以太网总线。这是最直观的冗余方式。
• 信息冗余：多路传感器信号（比如方向盘角度传感器用两路独立霍尔芯片）、多路扭矩信号交叉校验。这是容易被忽视但同样关键的部分。

你可能会问：“那是不是所有东西都要双份？”

当然不是。冗余是有代价的——成本、重量、空间、功耗。我见过一些方案，为了追求“绝对冗余”，把整个转向系统复制了两遍，结果装不进底盘，散热也成了问题。这其实走偏了。

1.4 冗余架构的分类

根据我在多个量产项目中的实践，转向系统的冗余架构大致可以分为三类：

1. 全冗余架构（Full Redundancy）：两套完全独立的EPS系统，包括电机、控制器、电源、通信。一套失效，另一套无缝接管。这种方案最安全，但成本最高，通常用于L4级以上自动驾驶。
2. 部分冗余架构（Partial Redundancy）：共享部分组件（比如机械齿条、壳体），但电机和控制器独立。这是目前L3级项目的主流方案。我记得在某合资品牌的L3项目中，我们就是采用这种架构，既满足了ASIL-D，又把成本控制在了合理范围内。
3. 功能降级架构（Degraded Redundancy）：主系统正常工作时提供全助力，故障时降级为“机械备份”或“低助力模式”。这种方案成本最低，但需要驾驶员介入，适合L2及以下。

为了让你更直观地理解，我画了一张架构对比图：

1.5 避坑指南

所以，做冗余架构设计时，有几点你一定要记住：

• 独立性是灵魂：冗余通道之间必须物理隔离、电气隔离、通信隔离。共地、共电源、共线束，都是隐患。
• 诊断要覆盖：冗余不是摆在那里就完事了。你得能检测到冗余通道是否健康。我习惯在每个控制周期内做一次“心跳检测”和“功能自检”。
• 切换逻辑要清晰：主通道失效后，备用通道何时介入？是立即切换，还是等待一个确认窗口？切换过程中会不会产生力矩波动？这些都要在软件架构层面提前定义好。

嗯，关于冗余架构的概述，今天就先聊到这儿。记住一句话：冗余不是堆料，而是系统性的安全设计。下一节我们会深入具体的冗余方案选型，到时候再细聊。

---

公众号:蓝海资料掘金营，微信deep3321