随着汽车中软件发挥的作用越来越重要，软件定义汽车已经是行业内的共识。汽车行业的发展极有可能最终像手机产业一样，基础硬件差异会越来越小，关键在于汽车给用户的体验的多样性，以及汽车产品在不同场景下满足用户需求的程度。而这种体验的差异性在很大程度上是由汽车的软件来决定的。当汽车中软件代码行数成正比不断增长，随之而来的是软件工程复杂度指数级增长和软件故障概率的提升。车辆无论是遇到软件故障还是更新，如果每次更新都要去4S店，效率将非常低下，线下售后运营负荷也将沉重，既难以满足智能汽车更新迭代的需求，也使得用户体验很差。
        OTA的出现，完美的解决了软件频繁更新的问题，通过OTA技术则可以通过远程快速完成缺陷的修复，避免了持续数月的进厂召回带来的风险。通过OTA升级，可以不断给用户开启新功能，不断优化产品体验，进行快速迭代，吸引客户。通过OTA，可以帮助车企节省因为软件缺陷带来的召回成本，节省大量的金钱和时间。但与此同时，OTA也带来了新的挑战，由于车载ECU众多，网络复杂，一旦车辆与外界建立通信，原本封闭的网络更容易受到入侵的可能性，建立一整套安全防护体系是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云端的升级模型管理，升级包管理，升级任务，升级策略以及日志管理的功能。OTA云端的设计要求是物理上实现租户隔离的云平台，能够支持多种协议下升级接入，支持多车型、多品牌、多种类型ECU软件版本管理，升级包制作，升级模型定义和升级策略和规则配置。能够支持批量升级任务的调度和分发。能够提供适配层与TSP平台和OEM的IT系统进行集成。性能上能否实现100万以上车辆升级并发，差分效率能够不小于90%，可靠性能否实现3个9的要求和7*24小时的系统连续服务。
        升级模型是用于定义目标升级设备模型的基本信息和设备模型所具备的升级能力支持情况的功能。在整车升级中，因为涉及到车型与ECU的配套关系，因此升级模型一般能够体现一个车型下各个零部件ECU的依赖关系，例如多个零部件ECU直接软件包配套关系和升级顺序控制，对于升级任务在设备侧的准确完整执行非常重要。此外，升级模型还包含了升级规则的定义。升级规则可以用于描述升级流程中，用于允许升级能否继续进行的判定条件。在整车升级中，一般包括了一款车型在升级下载前，下载中，安装前，和安装中的判定规则配置。
         软件包是用于升级使用的程序或配置。软件包包含有设备软件修复的缺陷或者要加入的新功能，更新前和更新后需要做哪些验证检查逻辑等，都会被打包到这个文件里。软件包一般都是由设备软件供应商提供的，会通过特定渠道，发布给OTA服务方。在整车升级中，OTA 分为两类，一种是 FOTA（Firmware-over-the-air，固件在线升级），指的是给一个零部件的ECU闪存下载完整的固件 镜像 ，或者修补现有固件、更新闪存。而固件之外的软件更新，就是 SOTA（Software-over-the-air，软件在线升级）。例如，车机屏应用程序和车载地图的升级，都属于 SOTA 的范畴。这两种文件形态，都属于软件包管理的范畴，通过软件包分类进行区分。软件包管理允许软件包能够基于软件包版本进行分版本的存储和管理，并维护软件类型，全量与差分等属性。
        升级包是在升级任务中，用于真正下载和安装部署的文件。升级包可以是设备软件供应商发布的软件包文件，也可以是经过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变砖。

OTA场景策略与规则

        从OEM车联网运营角度划分，根据车辆销售前和销售后不同，OTA升级场景一般会区分为静默升级和非静默升级。静默升级主要用于销售前处于库存状态的车辆升级。OTA云平台通过发送远程唤醒命令，通过TBOX唤醒车辆上电，连接到平台进行升级任务的处理。非静默升级主要是用于是销售后车辆归属于车主后的升级场景，软件升级变更需告知给车主，在车主知情和同意的下进行升级。非静默升级其中又分为普通升级和紧急升级，紧急升级一般是用于特别重要安全补丁的推送升级，车主知情但是无法拒绝。
        OTA升级任务下发到车辆后，升级管理程序OTA Manager也必须判断车辆条件是否符合。对于不符合条件的车辆，升级管理程序必须中止升级任务并上报给云平台。在OTA架构中，升级规则定义了各个车型在升级包下载，安装刷写阶段的判断条件。升级规则会随着云平台上的升级任务下发到车辆。例如最低版本要求，车辆运行状态、车辆位置。某电动车厂商的车辆在长安街街心升级导致交通堵塞的新闻曾在互联网上议论纷纷，如果在升级执行前能否判断车辆处于一个不适合升级的地点，那么升级任务也不会推送给停车等候红绿灯的车主了。一个好的OTA系统一定是能够灵活的配置升级条件，并且合理准确控制升级和用户推送的系统。
        最后，结合OEM运营的要求，OTA升级还需要能够灵活定义升级的具体范围，升级时机，升级内容，提示事项，失败后给用户的失败处理提示，提升大规模升级中的运营效率和运营体验，持续为车主和OEM提供价值。