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

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

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

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

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

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

但问题是，特斯拉的整车架构是从零开始打造的，传统车企基于燃油车平台规划的电动车型与之相比还是有很大区别的。所以假设要实现类似特斯拉的 OTA 功能，在独立规划的电动汽车产品量产前，可能还需要找到合适的解决方案才行。

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

激增的新供应商

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

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

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