用「软件定义汽车」背后， OTA 升级的争夺战

不管大家对 Musk 的看法如何，特斯拉的整车 OTA 能力想必是很多车企十分羡慕和渴求的功能。

因为特斯拉不只是简单地把软件升级包从云端下发至车内的 T-Box（Telematics Box,负责汽车无线通讯），来升级地图等车机内嵌的 APP 应用。它还能够直接把补丁直接发送至相关的、独立的 ECU，实现对汽车主被动、网络安全甚至是关键控制功能的升级。

         特斯拉通过 OTA 的方式持续实现各项功能的更新 | TESLA

很多人之前把未来的汽车畅想成「一台手机加四个轮子」，所以也理所当然地认为整车 OTA 应该和我们升级手中的 iPhone 一样简单。但其实从架构的角度来看，智能手机基本只配备了一台处理器来运行各种 APP，但汽车内部 ECU 的数量至少有上百个，它们连接在不同的车内通讯网络上，同时每条网络又有着不同的数据传输协议。

毕竟这个世界上不存在「没有漏洞」的软件。整个汽车产业都在朝着「软件定义」的方向逐步进化，所以能够及时通过 OTA 升级修正错误的能力就显得十分必要了。特别对智能互联汽车而言，一旦被黑客入侵，轻者造成财产损失，重者会危及到乘客生命安全。这个时候，能够及时阻止伤害进一步发生最有效的方式就是通过 OTA 把软件漏洞堵上。

这要比手机系统升级复杂得多。在受到特斯拉以及蔚来、小鹏等新造车势力围追截堵的压力下，传统车企希望能尽快让自己的产品和云端连接起来。最迫切的需求是能够实现 OTA 软件升级，主要功能的实时更新，车辆维修/异常探测以及防止网络黑客的入侵。

但问题是，特斯拉的整车架构是从零开始打造的，传统车企基于燃油车平台规划的电动车型与之相比还是有很大区别的。所以假设要实现类似特斯拉的 OTA 功能，在独立规划的电动汽车产品量产前，几乎所有的车企都需要找到一个「合适」且足够安全的解决方案才行。这就让提供「汽车 OTA 升级」的供应市场变得异常火热。

这也演化成了一个「智能汽车」的入口抢夺战。

         汽车 OTA 升级的基本原理 | HITACHI

激增的新供应商

不管是 Tier 1 还是 Tier 2 供应商，大家都感受到了主机厂客户对 OTA 升级方案的需求在持续增长。同时，来自移动产品终端的软件公司也开始盯上了汽车这块「肥肉」。在它们看来，汽车不过是「轮子上的智能手机」而已。

最后的结果就是做 OTA 的软件公司陆续被传统供应商收入麾下，形成了各方势力割据的总体局面：

1. 2015 年早些时候，哈曼国际收购了总部位于以色列的软件公司 Red Bend。这是一家为互联汽车提供软件管理技术、OTA 软件和固件升级服务的公司。但之后哈曼又被三星电子吃掉了。
   
2. 2016 年，当时还是英特尔业务部门的风河（Wind River）并购了为汽车提供 OTA 升级解决方案的 Arynga。
   
3. 两周之后，风河宣布福特将使用其 OTA 升级技术。风河方面表示「Wind River Edge Sync 技术能够提供不同的升级方式，可最小化数据容量、传输时间以及内存占用」。
   
4. 2017 年，从德尔福集团中分拆出来的安波福（Aptiv）收购了总部位于密歇根的初创公司 Movimento，并将其 OTA 平台集成到了自家的解决方案中。安波福表示「希望帮助车企完成数据搜集、分析的工作，监测漏洞，提升召回效率，堵上网络安全漏洞并加速自动驾驶技术的研发进程。」
   
5. HERE，作为一家图商，发布了 OTA Connect 的产品。HERE 方面表示这款产品是开源的，能够高效地集成至车企的后端服务器。
   

其他在 OTA 平台市场知名的供应商则有大陆集团、博世、Airbiquity 和 ATS Advanced Telematics System。

谁在解决关键问题？

上面这种频繁的合作和并购动态，其实也反应了整个汽车行业对 OTA 技术的旺盛需求。既渴望拥有却不具备特定领域的 know-how，「花小钱办大事」是最直接的解决办法。但问题又来了，目前绝大多数 OTA 能够做到的还只是将软件升级包发送至车内的 T-Box，而不能实现 ECU 层面的软件升级，譬如对气囊、动力总成、车身控制或安全等功能做出及时更改。

之前也提到过了，互联汽车和智能手机有着截然不同的电子架构。要在汽车上实现真正的 OTA（从云端到 ECU），供应商首先要在计算硬件上有很深的知识储备，比如了解车内不同硬件单元的区别。因为如果要与 ECU 进行通讯直连，你得知道它是不是有两个内存库。这样在 OTA 的时候，其中一个内存库可以写入升级包，而另一个内存库则可以存放旧版本的程序。

显然这种双内存的配置十分占用空间。尽管升级数据可以进行压缩，但 OTA 供应商仍需要考虑它要传输升级包的 ECU 是否有足够的片上内存（on-chip memory）。

其次，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 升级不光能让产品的电子系统保持最新，一旦出现因软件故障导致的召回，可以节省大量的时间和金钱成本。

「对很多车企而言，OTA 技术上车的主要动力是出于成本节约的考虑。」行业咨询机构 IHS Markit 首席分析师 Egil Juliussen 告诉极客公园（id：geekpark）。「网络安全则是 OTA 必须成为互联汽车标配的另一个重要原因。」

而 OTA 升级对主机厂真正具有吸引力的地方在于「它能够实现车辆重要功能的常用常新」。通过 OTA，汽车制造商通过软件升级的方式可以在产品售出后通过增加功能的方式继续获得收入。这也是为什么 Musk 认为未来搭载了 FSD 的特斯拉车型会变成一件「持续升值的产品」。

此外，在搭载了一套双向通信的 OTA 平台后，车辆能够将车端系统和零部件的诊断及运行信息及时传输至云服务器，这也有利于主机厂对某些潜在隐患进行预防性监测，做到「将风险提前扼杀在摇篮里」。

目前特斯拉使用的是 Red Bend（目前是哈曼国际旗下的公司）提供的 OTA 平台进行车辆和云端的通讯。但一旦涉及到整车软件升级的问题时，特斯拉依赖的则是其内部开发的 API 端口。

OTA 升级有利于主机厂对某些潜在隐患进行预防性监测 | HERE

标准的 API 端口能够为 OTA 升级带来的优势，对平台供应商而言是显而易见的。目前很多 OTA 公司只有一到两个客户，每家都在对接一些特殊的需求，这样是不利于整个行业的良性增长的。所以，Excelfore 牵头成立了 eSync 联盟，目的是解决目前汽车 OTA 普及过程中面临的一些问题。比如有效降低开发成本，缩短产品导入市场的周期等等。

「甚至像福特、通用这样规模的企业都对标准化的 API 产生了兴趣，因为它能够带来更多成本上的竞争力。」Juliussen 如是说。「对小公司而言，这无疑是天上掉馅饼，因为这会让消费者的选择变得更容易些。」

责任编辑：王训魁