作者 | 拉车老牛
前言： 提起汽车 OTA，相信大家都不陌生。 OTA 就是 Over The Air 的缩写，就是指汽车可以通过无线网络升级软件。即使非汽车从业者，相信也会被铺天盖地的广告科普过：现在新车型发布，基本都会宣传该车可以全车 OTA，会不断智能进化，用户买的不只是现在，还有未来。
但大家有没有想过，为什么汽车产品宣传时会将 OTA 作为特别的卖点呢？而其他产品，例如手机、电视、智能手环等也都可以通过无线网络升级软件，却很少会将 OTA 作为卖点重点宣传。那说明 OTA 虽然并不是汽车独有的，但在这个行业和产品上有其独特之处。那究竟独特之处是什么？OTA 在汽车上又有哪些难点痛点？现在又是怎么解决的呢？本文抛砖引玉，尝试从非专业人员的角度探讨，亦请各位大佬不吝赐教。
汽车 OTA 历史和背景
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，也可谓是业界商业模式创新的先驱。
汽车 OTA 的痛点
时至今日，汽车 OTA 依然被许多厂商作为重点功能来开发和迭代，说明该功能在汽车上并未完备。那么它究竟有哪些痛点和难点需要进一步解决呢？
1.网络信息安全。 它是汽车 OTA 中一个很大的考量点。软件升级过程中的任何漏洞或者缺陷，都可能危害车辆及其乘客的安全。因此 OTA 必须是安全可靠、防篡改的，以防止黑客访问敏感数据或者干扰车辆的操作。而另一方面，现在很多车辆的智能驾驶系统都采用硬件预埋，软件付费订阅的方式销售，其价格动辄上万元。如果被一套简单工具「逆向工程」篡改盗用，则对车厂来说也是一笔巨大损失。当然在保障安全的同时，也必须保障体验，让用户能够高效地进行 OTA，而不是一味地确认和验证。
2.兼容性。 汽车不同型号和不同配置，往往有不同的硬件和软件版本，这就会影响 OTA 的兼容性。在软件配置管理方面，厂家需要有一套管理方案，确保电子控制器内部软件、单车车辆配置、云端服务器和 OTA 通讯管道的兼容。这对于只有少量车型及配置的初创来说，难度还算小，但对于车型丰富的传统厂家来说，其复杂程度实属让人头疼。
3.高效便捷性。 相信大家都记得早年某车辆 OTA 过程中停在繁忙路段动弹不得，导致交通堵塞的新闻。汽车毕竟是一个交通工具，如何让 OTA 过程快速高效，尽量不打扰驾驶员对车辆的操作，则显得尤为重要。
4.鲁棒性。 汽车 OTA 过程中环境变量很多，例如无线网络信号不好，或者电池余量不足等。但用户肯定希望 OTA 能够稳定进行，不受外界干扰。而鲁棒性的另一个体现就是要求 OTA 升级的成功率极高，万一升级失败，也应该有备份措施，防止汽车「变砖」。
应对痛点的几种 OTA 技术
汽车 OTA 可以很好地提高用户体验，让汽车软件不断更新，不断进化，提供更加丰富的新功能给用户。这种能给用户带来「惊喜」的情绪价值，有时比操控或是静谧性等传统产品价值更能让消费者买单。但是与很多新技术类似，OTA 也存在上文提到的一些用户痛点。为了应对这些痛点，工程师们也煞费苦心，提出应对方案。下面我们就来看看几种热门的 OTA 技术。
1.后台传输
传统车载控制器一般通过统一诊断服务（UDS）来传输需要刷写升级的软件，这往往需要控制器进入特定的模式，在传输文件的时候并不允许应用功能开启。这意味着文件传输过程中，用户功能都得中断。但随着车载软件日益丰富，升级的软件包大小也越来越大，这个中断过程时间过长，会严重影响用户体验。
而后台传输技术则允许控制器在运行应用程序的同时，在后台偷偷地传输文件。没错，这技术听起来相信大家并不陌生，就像我们一边玩游戏，一边通过迅雷下载。当然一般后台传输也会具备丢包重传和断点续传的机制。让用户开车不被打扰的同时，软件包在后台也可以稳定传输。一次没传完，用户也不用管，关好车门锁好车，下车点火的时候接着上次传输继续下载软件包就好。许多成熟的通讯协议都可以支持这项技术，关键是车载控制器相应的硬件配置需要提升支持。
2.AB 分区
AB 分区指整个软件系统（包括操作系统）分为 A 和 B 两个独立分区，且系统可以在 A 和 B 之间切换。这就可以让 A 分区跑旧版本软件，保障车辆正常使用的同时，让软件在 B 分区更新起来。等 B 分区也更新好了，再重启切换到 B 分区上。
3.版本回滚
「人生没有后悔药」，但是 OTA 升级得有。OTA 升级过程中不可控的网络状态、车辆状态等因素比较多。为了确保升级的鲁棒性，可以在升级不达预期的情况下采用版本回滚策略。简单来说就是升级新软件的同时，保证旧版本软件备份可用，如果升级失败或者用户不满意，可以安装或者切换回旧版本软件。实现方案上，可以单独给旧版本软件开辟备份分区，也可以与上述 AB 分区相结合，升级失败时回滚至之前的可用分区。
4.差分升级
现在汽车上复杂控制器的软件包大小越来越大，如果直接传输巨大的数据，网络状态和网络流量都是巨大的挑战。为了应对这个挑战，很多主机厂也会采用差分升级的方式。所谓差分升级，就是利用算法识别新旧软件的差异，制作出来一个差分包。然后云端后台将差分数据包推送给车端，车上的控制器再利用算法，结合旧软件和差分包，生成出来全量的新软件包，然后再进行更新。当然这种技术在手机或者电脑上已经比较成熟，安卓系统就能支持这种升级。差分包的实际文件大小取决于新旧软件之间的差异，但是通常情况下差分包只有全量软件包大小的 5%～20%。这可以大大降低无线网络传输的流量，提高鲁棒性。有些算法还支持直接在旧软件包的分区上，直接基于差分包合成全量软件。这样还能进一步节省车载控制器的本地存储空间。
5.信息安全手段
汽车 OTA 毕竟涉及到软件更新，稍有不慎则容易被黑客攻击或盗用，所以信息安全 相关的技术手段必须为此保驾护航。实际上，汽车 OTA 的信息安全保护可谓是全方位的，常见的手段包括：
- 刷写文件安全： 通过 OTA 更新的软件数据包，一般都带有数字签名部分。控制器可以通过签名验证算法和密钥，确认将要刷写的数据包的完整性和合法性。
- 文件传输安全： 需要更新的软件数据包从云端通过无线网络下载到汽车，这个数据传输的过程一般都带有保护机制。互联网中已经成熟的传输层安全协议（Transport Layer Security， TLS）是最常见的手段。
- 诊断安全： 汽车 OTA 过程中往往会伴随通过 UDS 指令更新标定参数或者触发例程等操作。这时候就需要对 UDS 诊断操作先做一层安全控制，常见的有 UDS 的 0x27 服务，某些 OEM 还会拓展 0x27 的子功能或者自定义 0x31 例程来完成远程诊断的安全校验。
汽车 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 模块来实施。
如上图总体架构示意图，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 和近端诊断仪刷写的兼容。
当然 AUTOSAR Adaptive 是一个整体架构，OTA 过程中的很多功能和步骤，都是由 UCM 调用其他模块来协同完成的。如上面示意图，UCM 在 OTA 过程中涉及到验证签名等 Security 的操作，也可以通过调用 Cryptography 接口来实现。同时，UCM 也可以通过调用 SM 接口，来实现功能组的状态切换。AUTOSAR Adaptive 中对这部分的交互接口也作了详细定义，确保该架构可落地。
写在最后
总的来说，汽车 OTA 技术正在变革汽车工业。无线远程软件更新还可以进一步糅合远程诊断、数据管理和上传，演变更多用户功能，让汽车技术迭代更快。这项技术不但会提高汽车的性能和安全性，还可以优化汽车开发成本和增加用户满意度。这无疑让 OTA 成为了汽车的「灵魂」功能。
除此之外，汽车 OTA 所涉及到的用户数据合规性、信息安全性等特征，也会进一步推动汽车厂家将该技术及其运营牢牢把握在自己手上 。现在市场上在销售的很多汽车已经具备了 OTA 功能，各大厂家的开发过程、与供应商的合作程度各不相同。车端的实现方案只是汽车 OTA 的其中一环，配合与之相对应的云端部署、车云通讯和系统运营管理等，才能构成可落地的整体方案。
在未来，预计各大厂家都会加强优化 OTA 功能的系统化设计，构建统一运营框架，规范操作流程。而对我们从业人员来说，汽车 OTA 潜力无限，所带来的职业机会也同样是全方位和遍布上下游的。我们可以期待汽车 OTA 在未来持续发展和创新，作为个体我们也希望能在这场变革中同频共振，为汽车行业带来更大的进步。
