时尚汽车_汽车生活移动版

其次，OTA 供应商还应该熟悉车内的通讯网络拓扑结构。因为不同的 ECU 连接着从 CAN 总线、FlexRay、LIN 到 MOST、以太网等不同的通讯网络，只有对每条线路的特点有清晰的认知才能高效地实现软件升级。

对此，芯片供应商瑞萨认为要实现从 OTA 的第一阶段（对单一 ECU 的升级）进化到能够对整车功能更新，包括一些安全部件的更新。需要从两个方面入手：一是降低车内通讯网络的复杂性；二是简化车内 API 接口同时增加 MCU 对多个系统的集成化控制。

这其实涉及到了从传统燃油平台向智能电动化迈进的过程中，整车电子电气架构随之发生的演化：从分布式逐步向集中式过渡。而全新车用计算平台的引入能够简化车内网络的结构，加速通讯协议的编译过程同时增强各个子版块的安全性。同时位于整个中枢系统的 MCU 应该足够智能，它需要把从以太网获得的数据提前进行压缩，然后再传输给 CAN 总线。

MCU 会随着汽车电子电气架构的变化而逐步进化 | 瑞萨

不过目前还没有哪个量产的 MCU 能够胜任这样的工作。瑞萨方面表示，R-CAR Gen 3 是它们目前用于汽车 OTA 的主流产品。但随着汽车功能集成以及中心域控制的能力逐步增强，预计 2023 年会有适配全新电子电气架构的产品问世。

当然，安全是 OTA 升级中最关键的问题所在。不像手机，升级不成功顶多是「变砖」，但汽车就不一样了，稍有不慎就可能车损人亡。所以显然不能很随便地做整车 ECU 升级，这就要求车企要制定相应的升级策略，特别是定义好「合适」二字，避免出现类似蔚来车主在长安街遭遇的窘迫事件。

这里的「合适」既包括了对时间、地点、车辆状态等要求，同时还要对软件的功能性进行区分，比如关键系统一定要保持车辆静止且电量充足等，像音乐、视频类似的 APP 则可以在行驶过程中升级，只要确保不影响行车安全即可。

从这个角度出发考虑的话，在对汽车进行 OTA 升级时，其实要先让云端服务器与目标车辆进行通讯，锁定并同时对目标进行持续监测，确保其符合升级要求。而一旦进入升级状态，又会涉及一个新问题：中间发生错误怎么办？

其实升级过程中出现 bug 很正常，但对汽车而言，需要制定更妥善的防错机制保证车辆功能安全不受影响。像「断点续传」就是目前已知的 OTA 防错机制中一种较常见的方案。此外还有回滚机制，因为升级后新系统如果不稳定就需要退回到之前的版本，这也是对车辆安全的一种保护方式。

Excelfore Esync 解决方案中下发软件升级包的过程 | Excelfore

除了这两种主流的解决方案外，业界知名的公司 Excelfore 还提出了一个「安全内核」的概念，用来保障系统与云端的安全连接及对软件进行升级。而初创公司 Aurora Labs 的方案中包括了「Auto Detect」和「Auto Fix」两项核心技术。前者在 ECU 的后台运行，通过实时监测代码层级的错误来实现对宕机事件的预测。一旦错误被锁定，自动修复功能会将 ECU 软件实时滚回至上一个安全版本。理论上说，是不会出现「宕机」的情况。

再谈 OTA 的重要性

整车 OTA 应该成为汽车产业优先解决的问题。自动驾驶汽车可能确实对降低交通事故伤亡率有帮助，但假设没有靠谱的修补软件漏洞的方法，到时候一旦面临大规模召回，消费者的不满情绪对品牌而言是最大的灾难。

我们细数下近些年发生的因软件问题而导致的汽车召回事件：

1. 2016 年，日产召回了 320 万因气囊系统问题无法识别乘客的车辆；

2. 2016 年，通用召回了 360 万气囊系统自动进入诊断模式的车辆；

3. 2017 年，道奇召回了 125 万辆安全气囊传感器故障的车型；

更严重的是，很多消费者在知晓车企发布的召回通知后，继续放任软件故障存在。根据调研机构 Stout Research 发布的数据，购买 5 年内的车辆在召回通知发布后的九个月内，维修率只有 40%。例如，2018 年通用宣布因方向盘软件故障召回 100 万辆车型，到现在约有 60 万台未得到修复的车辆仍行驶在道路上。

如果车企的整车 OTA 技术能够就位的话，对付这些 bug 就变得易如反掌。而且 OTA 升级不光能让产品的电子系统保持最新，一旦出现因软件故障导致的召回，可以节省大量的时间和金钱成本。