前言： 提起汽车OTA，相信大家都不陌生。 OTA就是Over The Air的缩写，就是指汽车可以通过无线网络升级软件。即使非汽车从业者，相信也会被铺天盖地的广告科普过：现在新车型发布，基本都会宣传该车可以全车OTA，会不断智能进化，用户买的不只是现在，还有未来。

但大家有没有想过，为什么汽车产品宣传时会将OTA作为特别的卖点呢？而其他产品，例如手机、电视、智能手环等也都可以通过无线网络升级软件，却很少会将OTA作为卖点重点宣传。那说明OTA虽然并不是汽车独有的，但在这个行业和产品上有其独特之处。那究竟独特之处是什么？OTA在汽车上又有哪些难点痛点？现在又是怎么解决的呢？本文抛砖引玉，尝试从非专业人员的角度探讨，亦请各位大佬不吝赐教。

1.汽车OTA历史和背景

图1：汽车软件升级示意图

OTA经常分为软件更新（Software OTA, SOTA）和固件更新（Firmware OTA, FOTA）两类。其中SOTA 是指车辆软件应用层的升级，通过网络将文件从云端服务器下载后完成升级，常见的是娱乐系统、音乐、导航等的升级。而 FOTA 则一般包含车辆底层固件升级，包括动力、底盘、智能驾驶、电池等在内的控制器软件升级。类比来说，SOTA就像我们手机APP的升级，而FOTA则像是IOS或者安卓系统的升级。

对于汽车OTA来说，固件或软件的更新一般使用电信设备（行业常叫的“TBox”），通过汽车内部的网关，以无线方式更新到电子控制器（ECU）。狭义OTA仅指软件升级，例如座舱APP或者智能驾驶功能的升级。而广义OTA还包括地图数据的更新和影子模式等数据采集功能。

早在2000年左右OTA的概念就出现在汽车行业了。当时本田等日本车企就开始对TBox进行研究。TBox实际上就是一个电信设备，内含SIM卡，通过接通移动网络来通讯。但当时移动网络通讯速率很低，数据传输过程十分漫长，并没有在市场上量产铺开。到2009年，通用汽车公司则通过著名的安吉星（OnStar）服务量产了车载娱乐系统的远程更新功能。但这些都只是局限于汽车部分功能的SOTA。而真正的汽车OTA “OG”，大家普遍都认为是特斯拉。在2012年，特斯拉就在Model S上实现了包含底盘动力软件在内的车辆主要功能OTA。而特斯拉之后发行的Model 3，更可谓树立了汽车FOTA的标杆。直到现在，特斯拉的OTA已经扩大到了所有在售车辆。先将硬件预埋，然后再通过OTA发布智能驾驶功能包Autopilot，也可谓是业界商业模式创新的先驱。

2.汽车OTA的痛点

时至今日，汽车OTA依然被许多厂商作为重点功能来开发和迭代，说明该功能在汽车上并未完备。那么它究竟有哪些痛点和难点需要进一步解决呢？

1.网络信息安全。 它是汽车OTA中一个很大的考量点。软件升级过程中的任何漏洞或者缺陷，都可能危害车辆及其乘客的安全。因此OTA必须是安全可靠、防篡改的，以防止黑客访问敏感数据或者干扰车辆的操作。而另一方面，现在很多车辆的智能驾驶系统都采用硬件预埋，软件付费订阅的方式销售，其价格动辄上万元。如果被一套简单工具“逆向工程”篡改盗用，则对车厂来说也是一笔巨大损失。当然在保障安全的同时，也必须保障体验，让用户能够高效地进行OTA，而不是一味地确认和验证。

2.兼容性。 汽车不同型号和不同配置，往往有不同的硬件和软件版本，这就会影响OTA的兼容性。在软件配置管理方面，厂家需要有一套管理方案，确保电子控制器内部软件、单车车辆配置、云端服务器和OTA通讯管道的兼容。这对于只有少量车型及配置的初创来说，难度还算小，但对于车型丰富的传统厂家来说，其复杂程度实属让人头疼。

3.高效便捷性。 相信大家都记得早年某车辆OTA过程中停在繁忙路段动弹不得，导致交通堵塞的新闻。汽车毕竟是一个交通工具，如何让OTA过程快速高效，尽量不打扰驾驶员对车辆的操作，则显得尤为重要。

4.鲁棒性。 汽车OTA过程中环境变量很多，例如无线网络信号不好，或者电池余量不足等。但用户肯定希望OTA能够稳定进行，不受外界干扰。而鲁棒性的另一个体现就是要求OTA升级的成功率极高，万一升级失败，也应该有备份措施，防止汽车“变砖”。

3.应对痛点的几种OTA技术

汽车OTA可以很好地提高用户体验，让汽车软件不断更新，不断进化，提供更加丰富的新功能给用户。这种能给用户带来“惊喜”的情绪价值，有时比操控或是静谧性等传统产品价值更能让消费者买单。但是与很多新技术类似，OTA也存在上文提到的一些用户痛点。为了应对这些痛点，工程师们也煞费苦心，提出应对方案。下面我们就来看看几种热门的OTA技术。

1.后台传输

传统车载控制器一般通过统一诊断服务（UDS）来传输需要刷写升级的软件，这往往需要控制器进入特定的模式，在传输文件的时候并不允许应用功能开启。这意味着文件传输过程中，用户功能都得中断。但随着车载软件日益丰富，升级的软件包大小也越来越大，这个中断过程时间过长，会严重影响用户体验。

而后台传输技术则允许控制器在运行应用程序的同时，在后台偷偷地传输文件。没错，这技术听起来相信大家并不陌生，就像我们一边玩游戏，一边通过迅雷下载。当然一般后台传输也会具备丢包重传和断点续传的机制。让用户开车不被打扰的同时，软件包在后台也可以稳定传输。一次没传完，用户也不用管，关好车门锁好车，下车点火的时候接着上次传输继续下载软件包就好。许多成熟的通讯协议都可以支持这项技术，关键是车载控制器相应的硬件配置需要提升支持。

2.AB分区

AB分区指整个软件系统（包括操作系统）分为A和B两个独立分区，且系统可以在A和B之间切换。这就可以让A分区跑旧版本软件，保障车辆正常使用的同时，让软件在B分区更新起来。等B分区也更新好了，再重启切换到B分区上。

图2：AB分区升级示意图

3.版本回滚

“人生没有后悔药”，但是OTA升级得有。OTA升级过程中不可控的网络状态、车辆状态等因素比较多。为了确保升级的鲁棒性，可以在升级不达预期的情况下采用版本回滚策略。简单来说就是升级新软件的同时，保证旧版本软件备份可用，如果升级失败或者用户不满意，可以安装或者切换回旧版本软件。实现方案上，可以单独给旧版本软件开辟备份分区，也可以与上述AB分区相结合，升级失败时回滚至之前的可用分区。

4.差分升级

现在汽车上复杂控制器的软件包大小越来越大，如果直接传输巨大的数据，网络状态和网络流量都是巨大的挑战。为了应对这个挑战，很多主机厂也会采用差分升级的方式。所谓差分升级，就是利用算法识别新旧软件的差异，制作出来一个差分包。然后云端后台将差分数据包推送给车端，车上的控制器再利用算法，结合旧软件和差分包，生成出来全量的新软件包，然后再进行更新。当然这种技术在手机或者电脑上已经比较成熟，安卓系统就能支持这种升级。差分包的实际文件大小取决于新旧软件之间的差异，但是通常情况下差分包只有全量软件包大小的5%~20%。这可以大大降低无线网络传输的流量，提高鲁棒性。有些算法还支持直接在旧软件包的分区上，直接基于差分包合成全量软件。这样还能进一步节省车载控制器的本地存储空间。

图3：差分升级示意图

5.信息安全手段

汽车OTA毕竟涉及到软件更新，稍有不慎则容易被黑客攻击或盗用，所以信息安全 相关的技术手段必须为此保驾护航。实际上，汽车OTA的信息安全保护可谓是全方位的，常见的手段包括：

- 刷写文件安全： 通过OTA更新的软件数据包，一般都带有数字签名部分。控制器可以通过签名验证算法和密钥，确认将要刷写的数据包的完整性和合法性。

- 文件传输安全： 需要更新的软件数据包从云端通过无线网络下载到汽车，这个数据传输的过程一般都带有保护机制。互联网中已经成熟的传输层安全协议（Transport Layer Security, TLS）是最常见的手段。

- 诊断安全： 汽车OTA过程中往往会伴随通过UDS指令更新标定参数或者触发例程等操作。这时候就需要对UDS诊断操作先做一层安全控制，常见的有UDS的0x27服务，某些OEM还会拓展0x27的子功能或者自定义0x31例程来完成远程诊断的安全校验。

4.汽车OTA的实施（以AUTOSAR UCM为例子）

上文尝试从抽象概念和顶层设计的角度去理解汽车OTA，那么接下来我们再具象化一点地分析汽车OTA的设计和实施方案。这里以汽车软件事实标准组织AUTOSAR的Update and Configuration Management (UCM)功能簇作为例子来展开。

AUTOSAR Adaptive中规定的UCM是一个服务实例。它所提供的服务功能包括：

-AUTOSAR Adaptive环境中软件的版本报告 -接收和缓存软件更新 -检查是否有足够的资源来确保软件更新 -执行软件更新，提供日志信息和进度信息 -验证软件更新的结果 -提供回滚功能，在发生故障时恢复到之前已知的功能软件状态

单独的UCM服务并不能完成ECU上完整的OTA工作。在AUTOSAR Adaptive整体架构中，UCM需要其他模块配合的部分包括：

- 启动升级过程。 从整车角度，需要判断电池余量、挡位等车辆状态信息再开始软件升级。这部分的逻辑判断需要由其他应用程序来实现。

- 从云端下载软件。 出于网络信息安全的考量，本地控制器内的UCM模块一般不会和云端建立直接的通讯下载软件，而一般由其他应用或者中央网关作为代理服务器下载。

- 执行鉴权等安全操作。 软件升级过程中涉及的验证签名过程，一般由UCM再调用Crpto模块操作安全环境来执行。而访问控制则一般由UCM配合AUTOSAR中的IAM和EM模块来实施。

图4：应用UCM的OTA和诊断升级总体架构示意图

如上图总体架构示意图，AUTOSAR Adaptive的UCM功能簇主要负责执行软件升级。上层应用中需要包含相应的应用程序来调用UCM的服务，也就是下图中的“UCM Client” （也叫“UCM Master”）。值得注意的是，AUTOSAR Adaptive的规范中，除定义了UCM服务接口外，也定义了UCM Master中的部分接口，也举了相应的例子来阐述UCM Master的功能。

在这个架构下，UCM功能簇更多的是执行和实现软件刷写和升级的动作。而OTA过程中，与云端的交付以及车辆状态交付等需求，都是在UCM Master中实现的。

虽然近年来汽车OTA火出天际，但实际上汽车行业传统上的诊断刷写依然是现在各大车厂保留的ECU软件更新方式。所谓诊断刷写，简单来说，就是通过诊断仪上位机与ECU建立有线网络链接，通过UDS诊断协议来完成近端刷写。AUTOSAR Adaptive的UCM方案显然也考虑到了对诊断刷写的兼容。所以在这个架构中，可以由诊断应用（即下图中Diagnostic Application）调用底层诊断管理模块（Diagnostic Manager，DM）来实现ECU与诊断仪的握手。握手确认后，诊断应用就可以通过调用UCM服务来实现软件刷写。而在下图架构中，UCM Master和诊断应用做在了同一个应用程序实体内，实现了OTA和近端诊断仪刷写的兼容。

图5：UCM和SM、Cryptography的接口关系示意图

当然AUTOSAR Adaptive是一个整体架构，OTA过程中的很多功能和步骤，都是由UCM调用其他模块来协同完成的。如上面示意图，UCM在OTA过程中涉及到验证签名等Security的操作，也可以通过调用Cryptography接口来实现。同时，UCM也可以通过调用SM接口，来实现功能组的状态切换。AUTOSAR Adaptive中对这部分的交互接口也作了详细定义，确保该架构可落地。

写在最后

总的来说，汽车OTA技术正在变革汽车工业。无线远程软件更新还可以进一步糅合远程诊断、数据管理和上传，演变更多用户功能，让汽车技术迭代更快。这项技术不但会提高汽车的性能和安全性，还可以优化汽车开发成本和增加用户满意度。这无疑让OTA成为了汽车的“灵魂”功能。

除此之外，汽车OTA所涉及到的用户数据合规性、信息安全性等特征，也会进一步推动汽车厂家将该技术及其运营牢牢把握在自己手上 。现在市场上在销售的很多汽车已经具备了OTA功能，各大厂家的开发过程、与供应商的合作程度各不相同。车端的实现方案只是汽车OTA的其中一环，配合与之相对应的云端部署、车云通讯和系统运营管理等，才能构成可落地的整体方案。

在未来，预计各大厂家都会加强优化OTA功能的系统化设计，构建统一运营框架，规范操作流程。而对我们从业人员来说，汽车OTA潜力无限，所带来的职业机会也同样是全方位和遍布上下游的。我们可以期待汽车OTA在未来持续发展和创新，作为个体我们也希望能在这场变革中同频共振，为汽车行业带来更大的进步。