什么是汽车OTA？

首先来一个背景知识铺垫：被誉为汽车界“苹果”的特斯拉，从它的第一款ModelS上市开始，截止到2017年3月份的5年时间里，总计对车辆推送了25次远程升级。特斯拉每次发布新系统新功能就可以通过OTA方式免费推送给车主，让车主不断有开“新车”的感觉。那么，这里所说的OTA，是个什么神奇的东东？

什么是汽车OTA

OTA，Over-the-Air Technology，空中下载技术，或者说是一个标准。所谓“空中”指的是远程无线方式，即通过无线网络下载数据包从而对汽车系统进行升级的方式。

其实这个概念在手机行业由来已久，现在它不仅普遍应用于各种IT设备，而且还延伸到了智能汽车领域，通俗一点就四个字：在线升级。

严格来说，OTA又分为两种类型，FOTA和SOTA：

1. FOTA，Firmware Over The Air，固件升级，从字面上来理解的话，侧重指的是终端的固件升级，这一点在手机行业应用极为普遍，刷过手机的朋友们应该对“固件版本”印象深刻，手机中的固件升级就是一种FOTA；
2. SOTA，Software Over The Air，软件升级，从字面上来理解的话，偏向于应用软件升级，如：娱乐系统、导航系统等。

FOTA

它指的是给汽车下载一个完整的固件镜像或者修补现有的固件。例如它可以升级咱们车辆的转向系统，让我们的驾驶操作更加轻松；升级油门踏板的反应力度，让加速更线性舒适等等。总之相比SOTA而言，FOTA技术含金量更高。

特斯拉Model 3在上市后，其刹车逻辑就存在着问题，百公里/小时的制动刹车距离为46米，通过后续的FOTA升级之后，制动刹车距离缩短了6米，大幅提升了行车时的安全性。

SOTA

它一般作为一个迭代更新的增量出现，汽车厂商仅仅需要发送需要修改的部分即可，更像是我们通常意义上说的补丁。

这种修改方式有两个好处，一是能够尽量减少下载系统的时间和数据量，二是大幅降低了系统更新时失败几率。

如：我们升级多媒体系统更换操作界面、主题，甚至是更换仪表盘显示风格时，用到的基本都是这种SOTA的升级方式，这也是如今我们自主品牌汽车OTA升级主要方式。

OTA设计要求

OTA设计主要从安全、时间、版本管理、异常处理等方面综合考虑，具体为：

1. 升级安全是OTA的最基础的要求。车辆上ECU的软件运行状况直接会影响到车辆上的人员的生命安全。从升级包制作，发布，下载，分发，刷写等环节，OTA需要从云、网络、车端来保证安全。在云端通过证书，签名和加密机制保证升级包的不会随意被制作和发布，升级包内容不会被恶意获取。通过可靠的物理链路和安全传输协议来保证网络传输安全。通过汽车的功能域隔离，划分不同ASIL等级，通过冗余设计保证整车的功能可靠性，通过安全启动来保证可信的软件在ECU上加载启动运行。
2. 版本管控对于OTA来说很重要，因为车辆上ECU众多，不同ECU有不同版本的软件，不同车型ECU的需求有不同，版本也存在差异。版本的升级路径管理，需要能够全面准确进行管控。
3. 整车升级进行车载ECU刷写时，特别涉及动力域传统ECU的刷写，是通过CAN网络进行安装包的分发。由于CAN传输速率很低（实际典型的速率为500Kb/s），并且CAN总线负载率通常要控制在30%以内，因此在带宽允许的情况下，尽可能采取并行刷写模式，选取刷写时间最长的节点优先处理等设计原则减少OTA升级时长。
4. 防变砖等异常处理。在OTA传输过程中，外界干扰或者其他因素导致刷写异常或者中断，车载ECU必须支持软件回滚、断点续传、丢失重传等处理机制。

OTA方案架构

OTA云平台，主要包括了OTA云端的升级模型管理，升级包管理，升级任务，升级策略以及日志管理的功能。

OTA云端的设计要求是物理上实现租户隔离的云平台，能够支持多种协议下升级接入，支持多车型、多品牌、多种类型ECU软件版本管理，升级包制作，升级模型定义和升级策略和规则配置。能够支持批量升级任务的调度和分发。能够提供适配层与TSP平台和OEM的IT系统进行集成。性能上能否实现100万以上车辆升级并发，差分效率能够不小于90%，可靠性能否实现3个9的要求和7*24小时的系统连续服务。

OTA云端

升级模型

升级模型是用于定义目标升级设备模型的基本信息和设备模型所具备的升级能力支持情况的功能。在整车升级中，因为涉及到车型与ECU的配套关系，因此升级模型一般能够体现一个车型下各个零部件ECU的依赖关系。例如多个零部件ECU直接软件包配套关系和升级顺序控制，对于升级任务在设备侧的准确完整执行非常重要。此外，升级模型还包含了升级规则的定义。升级规则可以用于描述升级流程中，用于允许升级能否继续进行的判定条件。在整车升级中，一般包括了一款车型在升级下载前、下载中、安装前、安装中、安装结束的判定规则配置。

软件包

软件包是用于升级使用的程序或配置。软件包包含有设备软件修复的缺陷或者要加入的新功能，更新前和更新后需要做哪些验证检查逻辑等，都会被打包到这个文件里。**软件包一般都是由设备软件供应商提供的，会通过特定渠道，发布给OTA服务方。**在整车升级中，**OTA 分为两类，一种是 FOTA（Firmware-over-the-air，固件在线升级），指的是给一个零部件的ECU闪存下载完整的固件镜像，或者修补现有固件、更新闪存。而固件之外的软件更新，就是 SOTA（Software-over-the-air，软件在线升级）。例如，车机屏应用程序和车载地图的升级，都属于 SOTA 的范畴。**这两种文件形态，都属于软件包管理的范畴，通过软件包分类进行区分。软件包管理允许软件包能够基于软件包版本进行分版本的存储和管理，并维护软件类型，全量与差分等属性。

升级包

升级包是在升级任务中，用于真正下载和安装部署的文件。升级包可以是设备软件供应商发布的软件包文件，也可以是经过OTA平台完成了打包处理的文件。常见的升级包制作处理包括文件压缩合并，生成特定的文件描述信息，文件签名和加密处理。许多物联网设备和车辆设备的闪存都比较小，升级包需要要能在嵌入式设备的小内存中完成安装。因此，升级包会尽可能地压缩大小。为了保证效率和成功率，OTA平台在升级包制作中提供了差分生成的离线和在线工具。升级差分包之前，通过比较新旧版本之间的差异，生成差异文件。差分更新的核心技术是各家OTA供应商掌握的字节差分算法。

升级任务

升级任务是OTA平台用于执行和监控一组设备的升级活动的集合。

升级任务可针对特定范围的设备，使用相应的升级包和升级策略，进行升级任务创建，下发，监控，状态维护等整组活动的管理。

升级任务的监控功能，提供了对一组升级活动中，升级任务状态，进度和结果的反馈。按照升级任务状态的状态，主要包含了成功，失败，升级中等设备的数量和各个状态下的比例。升级任务的控制功能，提供了对一组升级活动中，升级任务的启动，停止，暂停，恢复，重启，撤销等操作能力，实际上是维护了任务状态机的状态变迁干预能力。

升级策略

升级策略是升级活动中的用于描述任务特征和目标设备升级行为的配置。

升级主要会涉及到下载和安装两个阶段，升级策略中，一般会包含升级包下载策略和升级包安装的策略，以及异常情况下的处理策略。如：在整车升级中，升级策略包括静默升级，常规升级和紧急升级的分类，也包括了升级包下载前，是否需要通知给用户下载确认的配置。

升级日志

升级日志包括云平台的日志，车端与云平台通信产生的日志和车端升级程序搜集上来的日志。主要用于升级失败后的分析和支撑升级运维运营管理。

OTA车端

OTA车端主要包含通信终端和各功能域的ECU。

通信终端

OTA通信终端一般由TBOX负责，上面运行OTA升级管理程序和升级代理程序。

其中，OTA升级管理程序OTA Manager是负责连接车辆与OTA云平台的管理程序。它实现了端云的安全通信，包括协议通信链接管理，升级指令接收和升级状态发送，升级包下载、升级包解密、差分包重构等功能。

升级代理Update Agent，是为了兼容不同的车内通信网络和通信协议，以及不同OEM间各品牌车型的接口差异，进行封装适配的部分。升级代理提供了统一接口，由OTA厂商负责实现接口，完成接口和业务逻辑的适配。

功能域

车端架构按功能域划分，分为动力系统域、车身系统域、影音娱乐域、ADAS主动安全域、自动驾驶域，不同的功能域有着不同的通信网络和功能安全等级设计。

自动驾驶域或者影音娱乐域等部分ECU存在主备分区的设计，即ECU内部用于两片区域，一部分用于存储当前运行的程序，一部分用于存储备份程序。

除第一次安装或者设备下线时，ECU内部只有一份软件外，之后更新安装的软件都会与上一份共存。当前运行的是最新的软件，如果升级过程中发生错误或者刷写的程序不能运行，ECU根据OTA Manager的升级策略要求，能否自动回滚至上一个版本的程序，防止车辆ECU变砖。

场景与策略

从OEM车联网运营角度划分，根据车辆销售前和销售后不同，OTA升级场景一般会区分为静默升级和非静默升级。

静默升级主要用于销售前处于库存状态的车辆升级。OTA云平台通过发送远程唤醒命令，通过TBOX唤醒车辆上电，连接到平台进行升级任务的处理。

非静默升级主要是用于是销售后车辆归属于车主后的升级场景，软件升级变更需告知给车主，在车主知情和同意的下进行升级。非静默升级其中又分为普通升级和紧急升级，紧急升级一般是用于特别重要安全补丁的推送升级，车主知情但是无法拒绝。

OTA升级任务下发到车辆后，升级管理程序OTA Manager也必须判断车辆条件是否符合。对于不符合条件的车辆，升级管理程序必须中止升级任务并上报给云平台。

在OTA架构中，升级规则定义了各个车型在升级包下载，安装刷写阶段的判断条件。升级规则会随着云平台上的升级任务下发到车辆。例如最低版本要求，车辆运行状态、车辆位置。

某电动车厂商的车辆在长安街街心升级导致交通堵塞的新闻曾在互联网上议论纷纷，如果在升级执行前能否判断车辆处于一个不适合升级的地点，那么升级任务也不会推送给停车等候红绿灯的车主了。

一个好的OTA系统一定是能够灵活的配置升级条件，并且合理准确控制升级和用户推送的系统。

最后，结合OEM运营的要求，OTA升级还需要能够灵活定义升级的具体范围，升级时机，升级内容，提示事项，失败后给用户的失败处理提示，提升大规模升级中的运营效率和运营体验，持续为车主和OEM提供价值。

OTA的优劣势

优势

说到OTA对于汽车的好处，第一点就是可以修复汽车本身存在的一些系统性的缺陷，并能快速的解决掉。

在一般情况下，传统的汽车厂商在发现旗下某款产品存在系统BUG的时候会进行统一召回，整个过程非常的繁杂，又费时费力。

有了OTA升级以后，我们不用再去4S店，直接在汽车上通过厂商推送的更新包升级即可，不仅操作如同手机升级系统一样简单，而且还省去了浪费的时间和金钱。

例如我们之前汽车的导航系统需要去4S店或修理厂更新地图包，而现在直接用OTA升级就可以获得最新的地图信息，实用又便捷。

劣势

1. 无法解决硬件上的缺陷，OTA升级只能解决汽车的软件BUG而无法解决硬件上的问题和缺陷。
2. 存在被黑客攻击、感染病毒的风险，OTA是一种需要连接互联网的下载技术，所以一旦联网那就有被黑客入侵的可能性。
3. 导致汽车品控倒退，许多造车新势力为尽快交付汽车赶时间，从而省略了许多测试环节，导致新车的完成度不高，在后续使用过程中BUG频出，但是OTA也是卖点。

OTA的乱象

众所周知，特斯拉汽车在电动化、智能化方面走在了最前面，其先进的整车OTA让不少车企羡慕嫉妒恨。但很快，“聪明”的主机厂就发现了一个奥秘，自家OTA一时半会不成熟没有关系，“掌握OTA的玩法”却相当简单，既然OTA技术带来了“常用常新”的可能性，就索性为用户大胆“画饼”，于是导致整个汽车行业OTA乱象频出。

第一，厂商以次充好掩盖产品劣势，侵害用户知情权

车联网的趋势下，厂商大肆宣传OTA已经成为潮流，而在信息不对等的情况下，车企很容易通过隐形条款把责任撇得一干二净，用户不同意升级就不能正常使用，而且用户已经被灌输OTA升级能带来更好体验的常识，碰到升级提示通常习惯性一路选择同意，很少有人会仔细阅读用户协议。

车企如果再过分一点，甚至可以先牺牲安全指标，**通过调高账面参数忽悠用户买车，再通过以性能提升为由的OTA升级，以降低用户使用体验为代价暗中提高安全系数。**如此以来，OTA正在成为某些厂商产品力不足的遮羞布。

第二，OTA式召回”存在灰色地带

OTA引发的另一个问题是，厂商是否有权通过OTA软件升级来处理一些硬件上故障？如果有权这么做，就可能引发安全风险。

例如，如果有辆车存在某个关键零部件不合格，而更换成本又非常高昂，厂商有可能声称自己通过OTA解决了问题，比如不再有警报响起，那么就相当于用软件掩盖了问题，从而也会埋下了安全隐患的种子。

**从技术角度来看，硬件存在问题是通过感知系统反馈给数据中心，而如果感知元件发生损坏，就难以判断硬件是否存在缺陷。**因此，对于文章开头所提到的特斯拉远程修复热泵缺陷的操作，给用户感觉看似潇洒，实则存在着安全性风险。

熟悉软件工程的都知道，如今汽车拥有庞大的软件系统，已经不可能做到零bug。如果OTA可以解决车辆的软硬件问题，主机厂又拥有绝对的主控权，那么假借升级偷偷修复bug，产品缺陷问题就成了灰色地带。

第三，不透明的暗箱操作侵害用户权益

软件定义汽车后，厂商可以依然可以通过OTA修复缺陷，当然也可以通过OTA升级的方式制造缺陷，于是OTA就有可能成为黑心厂商实施“计划报废”的工具。

在特斯拉官方论坛上，有用户发文称自己的Model 3在经历了一次升级后感觉没有以前快了，还有用户甚至觉得特斯拉降低自己 Model 3 的性能是为了卖高配的性能版。

“特斯拉就是想消灭 3.5 万美元的基础版 Model 3，好让大家都去买 8.7 万美元的顶配版。”一位用户写道。

不过，这些用户只是怀疑车变慢，谁都没能拿出确凿证据。这些用户的猜疑不禁让人联想到iPhone手机的“降速门”丑闻，美其名曰为 iPhone 的续航着想，其实就是逼迫用户去买新手机。后来苹果终于承认自己确实对系统动了手脚，赔偿了用户5亿美元。

最后

如果夸一个长得丑、脾气大、智商不在线、懒惰又没钱的人，我们只能说：其实他的心眼不坏。
如果夸一辆质量差、做工糙、颜值低、完成度不高的车，我们只能说：其实它可以用OTA升级。

完！

原文链接：https://jsnds.cn/2022/06/21/235700.html

参考资料：

https://blog.csdn.net/devcloud/article/details/106636671

https://blog.csdn.net/LEON1741/article/details/105928896/

https://blog.csdn.net/XIAOBING_110/article/details/108478753

http://www.woshipm.com/pd/5179689.html

http://www.woshipm.com/it/5328719.html