本章从OTA定义与应用场景、OTA实现流程和“云-管-端”关键技术进行研究，为行业从业者对OTA技术的设计开发、技术验证和生产工作提供参考。
一、汽车OTA定义与应用场景
1.1OTA定义及分类
OTA是OvertheAir的缩写，通常指的是远程无线方式，OTA技术可以理解为一种远程无线升级技术。在无特别说明情况下，本文所指的OTA是所有汽车远程升级的统称。实现OTA的基础是车辆具备远程联网功能，这意味着正是智能网联汽车渗透率的快速增长，推动了OTA的快速普及。
OTA的本质是通过技术实现软件更新，智能网联汽车与传统汽车的软件升级不同之处在于，通过OTA技术，原始设备制造商（OEM）可以不用通过售后服务中心，而是直接远程连接目标联网车辆，将软件更新推动至待升级的车辆。
然而在一些OTA解决方案中，已经模糊了不同类型远程升级的边界，将所有可升级的软件对象抽象为软件簇，而软件簇包含了从小到配置字信息大到整个操作系统固件所有颗粒度的对象。
并且，GB《汽车软件升级通用技术要求》中对软件升级（SoftwareUpdate）的定义已经涵盖了下述几种OTA概念（远程诊断除外）。
1.1.1远程软件升级(SOTA)
SOTA（SoftwareOver-The-Air），即远程软件升级，是指在操作系统的基础上对应用程序进行远程升级。SOTA通过远程下载并给车辆安装“应用程序升级包”，来实现控制器功能的一个“增量”更新，一般应用于娱乐系统和智驾系统。
SOTA一般涉及应用层小范围的功能局部更新，不包括汽车核心系统，对整车性能和安全影响较小，升级前置条件要求较低。SOTA的增量更新策略，可以大幅减小升级包文件大小、从而节约网络流量和存储空间。
1.1.2远程固件升级(FOTA)
FOTA（FirmwareOver-The-Air），即远程固件升级，是指囊括车辆底层算法至顶层应用的综合升级，在不改变车辆原有配件的前提下，通过远程下载并写入新的固件程序进行设备升级。FOTA包括驱动、系统、功能、应用等的升级，与硬件的更换没有关系。
FOTA涉及车辆的核心系统，包括但不限于汽车动力控制系统、底盘电子系统、自动驾驶系统、车身控制系统等核心零部件的控制系统，可以改变车辆的充放电、动能回收、加速性能、辅助驾驶系统逻辑等与深度驾控有关的体验。理论上所有支持固件更新的电子控制单元（ECU）都可以涵盖在FOTA范围中。
1.1.3远程配置(COTA)
COTA（ConfigurationOver-The-Air），即远程配置，是指通过OTA的方式实现远程修改配置字，以达到修改软件功能配置的目的。配置字是一组以数据标识码(DID)方式存储在ECU上的数据，可通过诊断指令进行读取和修改。它根据特定的编码规则与车辆功能特征码一一对应，通过配置可判断车辆的功能配置，软件可根据配置实现相应的功能。远程配置常见的应用场景是远程开启和关闭某项功能，例如软件订阅功能。
1.1.4远程诊断/远程数据更新(DOTA)
DOTA有两种常见解释：
DOTA(DataOver-The-Air)，即远程数据更新，是指一些独立于软件程序存在的数据包的更新，比如，地图数据、语音数据和算法模型数据等。这类更新的特点是数据量比较大，更新流程相对独立，比如，地图数据通常由地图应用自行更新，而数据量也可能高达几G到几十G。
DOTA(DiagnosticOver-The-Air)，即远程诊断，通过云平台实时数据采集监控，主动性地检查汽车系统异常问题，为远程问题修复与人工问题修复提供决策依据。远程诊断的触发方式有两种，一种是用户在车辆上发现异常状况的响应式；另一种是周期性收集通讯网络、应用程序、硬件效能、使用操作记录、系统程序等状态信息，利用大数据后台分析监测故障。
1.1.5其他类型(XOTA)
1.2OTA应用场景
1.2.1车辆生命周期维度
从开发者编译生产出目标版本软件，到该软件更新至目标硬件设备上的全过程涉及多个阶段。在不同的阶段，受产品形态和生产环境限制，所适用的软件更新目的和手段也有所不同，如下表2-1所示。
目前，大部分车企的OTA主要集中在售后软件更新，但不论是从效率上还是成本上OTA都体现出了巨大的优势。随着OTA应用越来越成熟，从单一的售后升级场景向更多的应用场景发展是的必然趋势。
表2-1车辆生命周期维度的软件更新应用
零部件阶段
ECU供应商产线是最早可以切换到最新软件版本的节点，该节点进行软件切换可避免旧版本软件继续生产从而流向下游，称为供应商产线断点。由于该阶段还是零件状态，通常只能通过芯片烧录工具或者供应商特定的工具进行软件更新，不适用OTA方式。
总装阶段
由于零件需提前订购，仍有一定量的零部件在供应商产线断点前流转到OEM库存，总装线的电检工位可以完成部分软件的刷写，称之为EOL(EndofLine)软件刷写。然而EOL软件刷写会影响产线节拍，导致OEM不会在产线进行大量软件刷写。
总装完成时车辆已经具备OTA的条件，如果通过OTA方式进行产线刷写，可实现多车并线刷写且不受产线工位影响，将极大提高产线软件灌装的效率。目前，已经有个别企业实现总装阶段OTA。
驳运阶段
车辆从总装线下线到经销商库存要经过一定的驳运过程。对于体量大且紧急程度不高的软件，在总装线灌装会影响效率，如果利用驳运过程进行软件更新，能降低对产线节拍的影响。OTA使得利用驳运过程更新软件成为一种可能，但在驳运过程中更新对电源供应管理及车辆安全是否有影响需要更深一步考虑。
售前库存
OTA技术可将库存车辆自动同步至最新版本，大大减少在交付过程中软件更新的耗时，提升效率。
售后阶段
过去的售后阶段软件更新，用户需要将车驾驶到指定维修站完成更新。
通过OTA技术，用户可随时随地通过简单操作完成软件更新，使车辆“常用常新”。目前已成为汽车企业增加用户粘度和解决软件售后问题及构建生态服务体系的一个重要手段。
1.2.2软件运营管理维度
从软件运营管理的维度OTA的典型应用场景如下表2-2所示。
表2-2软件运营管理维度的软件更新典型应用场景
软件召回
问题修复
对于一些非严重性问题，通过OTA方式，可以周期性推送软件版本，进行问题修复。
性能优化
与缺陷修复类似，OTA方式的便捷性，使得性能优化类的软件更新也逐渐得以重视，目前已经是常见的OTA场景之一。
软件个性化定制
此应用场景通常为COTA应用，比如用户可根据个人需求，完成怠速调整、车下启动/熄火，自动启停等参数的设置更新。
新功能交付
OTA使得售后软件功能持续迭代成为可能。通过OTA可新增功能的多少，已成为用户评价OEM的对重要指标之一。
付费功能订阅
功能订阅是新功能交付应用场景衍生出来的一种新的行业形态。车企在售卖车辆之后，针对部分新增软件功能以付费方式供用户购买使用。这使得车企除了车辆销售之外，有了新的盈利可能性，这也是目前汽车企业非常乐于探索的一种OTA应用场景。
二、汽车OTA技术体系
2.1OTA实现流程
汽车软件更新的本质是将供应商或者OEM内部开发部门编译出来的软件或者数据替换当前车辆ECU中的版本，以实现预期的特定功能。因此，汽车软件升级所需要的核心工作是建立远程传输链路并实现OEM云端系统远程更新车辆ECU中的软件数据。
同时，为了准确、安全、可靠地完成ECU软件的更新，OTA系统需要云端管理系统对软件、升级对象进行管理，以实现人工操作到自动化的转变；车端系统需要完成软件数据的接收和分发工作，并保证无专业技师操作情况下的安全升级。
图2-1是一个典型的OTA系统框架，包含了三个基本要素，即云端的OTA平台、车端OTA主控、OTA对象。其中：OTA云平台负责OTA升级包管理、车辆管理及OTA发布等功能，车端OTA主控负责从OTA云平台下载升级包并将其刷写到目标ECU，OTA升级对象即最终软件刷写的主体，从主控接收软件并完成自身软件更新。OTA的基本实现流程（图2-1）可归纳为下表2-3所示步骤。
表2-3OTA的基本实现流程
1.升级包制作
ECU供应商或车企内部开发团队完成软件开发并编译产生新版本的软件，通过约定的方式制作成升级包。
2.上传软件
供应商或OEM内部开发部门生产的软件验证合格后，经由产品生命周期管理系统(PLM)或类似的系统流转到OTA云平台，供更新使用。
3.OTA任务发布
发布过程是选定特定软件，通知至指定目标车辆，通常由OTA运营人员完成。发布之后的软件通常经过一系列安全处理后传至专门的文件服务端供车辆下载。
4.下载升级包
OTA发布完成后，通常OTA云平台需要通知车端OTA主控执行软件更新动作，OTA主控根据与云平台命令交互获取信息，从指定文件服务端地址下载所需要的升级包；不同的OTA系统可能由于升级对象升级包大小原因，OTA主控不会直接下载升级包而是通过相关命令控制目标ECU完成其所需升级包的下载。
5.安装
安装过程是由OTA主控根据约定的协议，将目标升级软件刷写到对应ECU指定存储介质。ECU硬件不同、通信方式不同，通常安装的过程会有所差异。
6.校验
软件安装前后需要进行完整性校验及真实性校验。完整性校验保证安装过程传输的数据没有被篡改，真实性校验保证所安装软件没有被仿冒伪造。
7.激活
根据ECU结构不同，安装步骤可能还会包含激活操作，即双备份分区ECU更新完成后进行分区切换。此外，OTA主控除了处理控制安装过程外，还需要控制车辆的状态，保证升级过程车辆的安全。
8.回滚
针对升级异常的情况，将软件版本恢复到升级前版本的过程，主要目的在于保证升级失败ECU功能仍可用。
9.状态上报
OTA主控需要将升级状态同步到OTA云平台，保证OTA云平台可以根据车辆最新状态编排升级任务。同时，可根据业务实际情况，同步更新过程中各阶段状态至OTA云平台，以便更精准地控制升级。
2.2OTA云平台架构及关键技术
2.2.1云平台架构
基于OTA产品业务形态，结合系统组件之间松耦合高内聚的标准，行业内普遍将云平台设计为4层的分层架构型式，如图2-2所示，包括前端展示层、路由网关层、业务服务层和数据存储层。
图2-2OTA云服务框架图
（1）前端展示层
前端展示层的划分，是基于前后端分离开发方式设计的架构分层模式，主要负责Web端用户交互页面的功能。核心思想是前端页面通过调用后端的接口并进行交互，前端专注于交互页面的开发，业务逻辑由后端负责。对OTA云平台而言，前端展示层可以理解为业务服务层的用户交互接口，其展示功能与具体业务功能一一对应。
（2）指令控制层
各业务平台与网关接入层的连通介质，接收来自业务系统指令并将指令发送至网关可访问的缓存中，接收来自网关回写的升级状态至各业务系统可访问的消息队列中。
（3）网关接入层
针对不同的数据格式及上层需求，接收封装来自车载终端传输的数据，并流
向缓存、消息队列等中间件。
（4）业务服务层
表2-4常见服务举例
车辆管理服务
维护所有可升级车辆的信息，包括品牌、车型、配置以及每个单车所包含的可升级设备信息等。
软件包服务
用于控制器升级包的在线管理、差分包的制作及管理，相当于OTA的仓库管理，需要维护不同车型所有ECU不同版本的所有软件实体，包含软件包的签名加密以及各版本与其关联关系等。
版本服务
包括基线版本管理、软硬件版本及版本号管理，每个软硬件版本的依赖条件管理，并维护每一个软件版本所适用的品牌、车型、配置等。
策略管理服务
需适配各种复杂软件更新，提供灵活的设备群组管理、下发条件配置，支持升级任务策略配置，满足各类升级需求。
任务管理服务
审批服务
功能在于把传统的线下软件发布的审批流程通过OTA平台实现在线化，达到自动流传，提高效率的作用。
数据对接服务
数据对接的系统包括PLM、MES、EOL、DMS、ADS，数据对接涉及到软件版本信息获取、车辆信息初始化、用户信息、售后信息同步等。
信息安全服务
用于保证OTA的安全，主要通过与PKI系统对接完成升级包的签名加密，车端设备的身份认证，通信链路的认证和加密。
安全访问控制服务
测试服务
用于支持OTA的测试，主要包括OTA升级策略、升级配置信息和任务等，以保证升级效果符合期望目标。
统计分析服务
用于动态统计OTA升级状态，可以通过可视化展示升级状态，快速了解升级任务进度。同时，可以根据统计分析结果动态调整OTA任务推送的车辆数，保证系统资源和售后资源得到最有利的分配。
日志查询服务
包含云端日志、车云交互日志以及车端远程日志等查询功能。
基础信息服务
主要针对OTA云平台本身的信息管理，如账号权限管理等。
（5）PKI系统
（6）外部数据系统
需要进行软件更新时，从VLCS系统中确定所涉及的车型和影响的功能范围，并依据确定好的范围，从物料信息管理系统(BOM)中申请软件物料号作为版本控制依据，供应商软件释放后经由产品生命周期管理系统（PLM）系统通过验证审批后流转到OTA服务端供升级使用使用。OTA服务端管理设备中初始的车辆信息，可通过对接MES在车辆下线检验合格后将新生产车辆自动注册到OTA云平台，所有升级目标车辆应保证是已注册车辆。
除此之外，根据实际需要还可能会从汽车经销商管理系统（DMS）系统获取经销商及售后服务站点信息，售后系统通常也需要与OTA系统关联以同步最新版本信息以及线下配置更改信息等。
另外，OTA系统在升级前可通过远程诊断系统获得最新的ECU配置信息及状态信息，并且当远程诊断系统发现问题后，可以通过OTA系统下发经过测试验证的补丁包来修复。对于一些有运营需求的主机厂来说，通过OTA系统配合软件可售系统，可以实现软件付费升级、功能付费使用等后向运营，真正实现“千车千面”、“用户定义汽车”。
（7）数据存储层
数据存储层包括数据库集群、缓存和存储节点，分别用于存储OTA云平台不同类型的数据。
其中，数据库集群，主要用于存储车辆信息版本信息等关系型数据；缓存，为了解决数据库性能瓶颈问题，可以通过多架设一层缓存层来减少对数据库的直接访问；存储节点，针对较大的升级包、配置文件等需要提供车端下载的文件，通常可以存储在分布式存储节点上。
2.2.2关键技术
（1）安全技术
OTA服务端以及企业IT管理系统、安全服务端、web控制台、文件服务端等关联系统，会面临传统云平台的所有安全威胁。为保证OTA升级的安全性，常用安全技术如表2-5所示。
表2-5OTA云平台常用安全技术
PKI签名验签技术
在升级过程中，OTA系统采用数字证书签名方案，终端从OTA云平台下载的升级包、升级脚本均经过签名处理，升级前需验签正确后才进行升级。
安全访问控制
通过云平台端的安全访问控制服务，OTA车载系统采用网关内置或终端内置的安全访问函数方式实现校验方案，只有全访问验证通过，ECU才会执行后续对应安全访问等级要求的请求。
数字证书身份认证及信息安全
PKI数字证书用于实现车辆身份管理，车、云身份认证；用于OTA云平台与车端上下行消息的加解密、签名、验签。
数据安全
通过在组织中建立数据安全管理体系、建设云平台数据全生命周期的主动安全防护和数据安全运营能力，保护数据安全。
（2）OTA技术
OTA系统常用升级技术如表2-6所示。
表2-6OTA云平台常用升级技术
升级包管理
用于控制器升级包的在线管理、差分包的制作及管理。
脚本管理
用于控制器升级执行脚本文件的在线管理。
升级策略管理
升级效率管理
2.3OTA车载端架构及关键技术
2.3.1车载端架构
OTA车载端功能模块主要包括2大部分，即OTA主控和OTA对象，如图2-3所示。OTA主控是车端OTA系统的核心，车端所有OTA业务逻辑均由主控实现，包括上报车辆信息、下载更新文件、升级包安装、车辆状态管理、人机交互等。
图2-3车载端功能模块(参考AutoSARUCM)
（1）OTA主控功能模块
按照车载端的工作流程，车载端的功能模块包括：OTA客户端负责与云端进行数据交互；下载模块负责升级包下载及分发；升级管理模块负责升级过程的控制；升级代理负责执行软件刷写或者软件安装；人机交互模块负责升级信息提示、用户输入、升级过程的展示等，如表2-7所示。
表2-7OTA主控功能模块
升级管理（OTAManager）
作为OTA的核心，管理车辆所有ECU的更新过程，控制着将固件更新分发到ECU，并告知ECU何时执行更新，这在多个ECUs需要同时更新的情况下尤为重要。
OTA任务下发到车辆后，OTAManager需要判断车辆条件，对于不符合条件的车辆，需要中止升级任务并上报给云平台，安全完成软件升级后，也要上报云端。若想实现单车定制化功能，OTAManager还需能够灵活定义升级的具体范围，升级时机，升级内容，提示事项，失败后给用户的失败处理提示等。
OTA客户端
负责OTA主控与OTA云平台交互，包括下发OTA云平台的OTA控制命令，反馈控制命令的执行结果，发起更新检查请求，同步升级过程状态等。
下载管理模块
负责从文件服务端下载升级所需升级包和文件，支持断点续传，保证升级包可以分多次下载，同时也避免部分重复下载造成流量浪费。
安装模块
负责将升级包安装到对应的ECU。不同的ECU类型会需要不同的安装模块，比如FBL安装模块用于仅支持Bootloader升级ECU，AB安装模块用于支持ABswap双备份分区升级方式的ECU,其他安装模块主要是指一些采用私有协议进行升级的智能ECU
车辆状态管理
负责确保车辆在安全状态下进行升级，其功能主要包括两个:
②车辆状态控制,通过特定的控制命令或者信号值，限制车辆非升级必须的功能，保证升级过程车辆状态不可被改变，从而维持在安全状态。
人机交互接口
（2）OTA主控部署方案
由于车辆E/E架构的不同以及控制器升级方式的不同，功能模块的部署方式也有所不同。在传统网关分布式架构下，按照OTA主控部署的位置不同，大致分为：远程信息处理控制单元（TCU/T-BOX）方案、车载信息娱乐系统（IVI）方案、网关（GW）方案，如图2-4所示。
前两种方案，由TCU/IVI来进行ECU的软件刷写，GW仅作为路由实现数据的转发，刷写的链路比较长；后一种方案直接是由GW进行刷写，刷写链路较短，但是GW并不能直接联网，如果通过TCU/IVI路由联网必须增加安全机制，或者由TCU/IVI下载升级包后再分发至网关。
图2-4传统的OTA主控部署方案[1]
传统网关分布式架构下，由于控制器分散以及层级很深，导致在实现OTA的过程中要进行多次的转发和透传，容易导致数据丢失，增加升级失败的概率。另外，需要在OTA主控内部对软件进行备份，以保证升级失败后，控制器可以被回滚。由于传统控制器的芯片Flash和RAM容量小，实现也比较困难。
对高算力和大带宽数据传输的迫切需求和“软件定义汽车”的理念驱动，各家车企逐步开始进行整车E/E架构的升级和变革，引入了“中央计算平台+区域控制器”的中央集中式架构，整体E/E架构更加扁平化，有利于实现整车级的OTA。
中央控制器和域控制器之间采用的是以太网，数据传输能力增强；并且SOA架构使得域控制器之间的交互机制更加灵活。针对区域控制器的OTA主控部署方案如图2-5所示。可采用中央控制单元(CCU)作为升级主控，对于ECU的刷写有两种方式：
1)区域控制器作为网关路由UDS报文，主控通过UDS升级区域控制器和该区域的所有传感器和执行器；
2)区域控制器作为副主控，即升级主控先将该区域所有ECU的更新文件传输到区域控制中，由区域控器完整自身升级以及与其连接的执行器和传感器的刷写。
图2-5区域控制器方案
（3）ECU端架构方案
车端ECU作为被升级对象，在OTA系统中主要功能是按照一定的协议升级主控接收目标版本数据，将目标版本数据写入都指定的存储区域中并引导运行新版本软件，从而实现自身软件的更新。
按ECU芯片类型及运行软件的特性可分为普通ECU和智能ECU，而不同的ECU类型根据其内存空间结构又可以分为单分区和双分区两类。针对两类ECU的两种不同分区方案，ECU端的升级可以大致归类为4种方案，本小节将分别对其展开讨论。
①普通ECU单分区（Bootloader）升级方案
普通ECU由于存储空间有限，通常会采用流式刷写的方式进行升级，所谓流式刷写即先将目标刷写空间的数据擦除，然后传输数据的同时，ECU将已接收的数据写入目的存储地址，通过这种方式可以省去存储升级包的内存空间。传统的BootLoader通过UDS协议刷写的方式就是典型的流式刷写。
如图2-6所示，普通ECU单分区结构只有BootLoader(启动引导程序)和应用程序分区。
该类型ECU需要更新时，首先将ECU从当前运行的应用程序分区切换至BootLoader运行，在BootLoader中将应用分区当前版本数据擦除后，再从升级主控接收新版本数据并写入应用程序分区，数据检验无误后重启ECU切换至应用分区即可运行新版本软件。
图2-6Bootloader升级方案示意图
由于这用方案具有对内存空间要求低、在BootLoader进行更新不受应用程序干扰、实现简单等优势，目前现有升级解决方案中大部分普通ECU的更新仍采用这种方式。
②普通ECU双分区（AB分区）升级方案
通过AB分区方案，为软件的运行版本和升级的目标版本分配不同的存储区，A与B分区彼此为回滚，A分区系统运作提供服务时，刷新B分区，待B分区软件刷写完成通过校验后，下次重启时载入B分区；若刷写错误或关联ECU刷新失败，则仍以A分区系统启动，从而提高升级的可靠性，最小化回滚所需的时间。
对于AB升级，其实有三种实现方案：
第1类基于硬件辅助的A/B交换方案。该方案要求ECU内存足够，而且支持地址重映射，也就是当新版本软件刷写完成，通过更新映射地址来激活新版本软件，即新版本软件运行的入出地址不变；
第2类与第1类的差别在于ECU硬件不支持地址重映射，激活新版本软件的入出地址会变化；
第3类，基于外扩内存的A/B交换方案，该方案是需要额外的外扩内存，备份当前版本软件和旧版本软件，新版本软件会先刷写原先的旧版本软件空间，然后擦除ECU内存的当前版本软件，刷写新版本软件，完成激活。
AB升级方案示意图如图2-7所示
图2-7AB升级方案示意图
③智能ECU单分区升级方案
智能ECU是指具有高性能处理器，可运行现代操作系统(如Linux、QNX、Android等)支持文件系统的控制器。这类控制器存储介质成本相对较低，一般存储空间较为充足，通常不会采用流式刷写的方式进行升级，而是先将升级包保存到ECU本地存储，然后进行安装。
智能ECU的升级通常采用私有协议，通过升级代理(updateagent)接收OTA主控的升级包和控制命令，根据主控的指令使用本地安装程序(Installer)完成升级包的安装。图2-8为智能ECU升级单分区方案和双分区方案的系统框架对比。
图2-8智能ECU升级方案示意图
该方案软件更新流程：
①系统正常运行在主系统分区，同升级代理从OTA主控接收升级包文件，并保存在升级包缓存区，
②升级包接收完成后由进行解密、签名认证，
③接收到OTA主控安装命令后，升级代理将ECU切换至更新子系统，在子系统中通过安装程序将升级包安装到主系统分区，替换分区中的旧版本软件，
④安装完成后系统重启切换到新的主分区软件版本。
④智能ECU双分区升级方案
智能ECU双分区方案与单分区相似，双分区方案具有两个结构完全相同的系统分区，两个分区都具备升级代理和安装程序的功能。
系统默认运行在A系统分区，有新版本软件需要更新时，可以通过升级代理从OTA主控接收升级包，并直接通过安装程序将其安装到B系统分区中，整个更新过程不影响ECU正常功能使用。
①系统正常运行在A系统分区，同升级代理从OTA主控接收升级包文件，并保存在升级包缓存区；
②升级包接收完成后由进行解密、签名认证；
③接收到OTA主控安装命令后，A系统分区安装程序将缓存中的升级包安装到B系统分区；
④收到OTA主控激活命令后将系统启动引导标志设置为B系统分区，
⑤重启系统后切换运行B系统分区新安装的软件版本。
2.3.2车载端关键技术
（1）OTA主控
①电源管理
②车辆控制
对于影响车辆安全的升级，整个升级过程需要保持在一种安全状态，因此，OTA主控需要具备一定车辆功能控制能力，根据不同的升级类型，控制车辆的功能状态。
③异常处理
在OTA传输过程中，外界干扰或者其他因素导致刷写异常或者中断，车载
ECU必须支持软件回滚、断点续传、丢失重传等处理机制。
①标准协议
支持软件刷写和软件升级的标准过程，方便OTA的开发、测试和集成，如传统ECU支持UDS协议、AUTOSARAP的UCM。
UDS，即统一诊断服务，主要用于车外诊断设备通过车辆诊断口连接车内总线，并向控制器请求控制器内部信息或向控制器传输数据。FBL规范定义了控制器要实现软件刷写所需遵循的软件架构，并且定义了刷写时需要使用哪些UDS服务，以及这些服务之间的顺序关系。
使用这些UDS诊断服务，可以命令控制器擦除原有内存中的软件数据，接收新的软件数据并写入到内存，最终执行新的软件程序。传统ECU基本采用的都是基于UDS协议的软件刷写这种升级方式。
AUTOSARAP，即自适应平台，是由软件更新配置管理器（UCM）提供了处理软件更新请求的服务。UCM负责在AP上更新，安装，删除和保留软件记录，实现了软件包管理，确保以安全可靠的方式更新或修改AP上的软件。UCMMaster提供了一种标准的平台解决方案，通过与多个UCM之间协调和分配车辆内的包，实现AUTOSARAP的软件更新。
②私有协议
除了升级遵从标准协议的传统控制器，OTA还需要支持智能ECU的升级。智能ECU通常带有操作系统并且自身具有升级能力，作为升级对象，需要从OTA主控模块或者云端获取升级包，并与OTA主控进行信息交互，实现升级的触发和升级信息的反馈。
对于这部分升级所涉及到的升级包分发和升级控制，现在并没有统一的定义和标准，各家车企和供应商的实现方案也各异。
（3）ECU端升级技术
①差分升级
相对于整包升级，差分升级方案不仅可以节省MCU内部的资源空间、还可以节省下载和升级过程中的功耗。
从另一个角度说，通过将差分部分下发到设备保证了软件版本的安全性。差分升级的流程如表2-8，图2-9、2-10所示。
表2-8差分升级基本流程
步骤
内容
原始版本提取
从目标ECU中提取出当前安装的软件版本，以便与新版本进行比较。
新版本生成差分包
将新版本的软件与当前版本进行比较，找出两者之间的差异。这些差异可能是代码的新增、修改或删除。生成差分包时，通常使用一些压缩和差异算法，例如哈希函数、二进制比较等，以便减少差分包的大小。
差分包传输
差分包合并
目标ECU接收到差分包后，使用算法将差分包中的更改与当前软件版本进行合并。这可能涉及将新增的代码插入到现有的代码中，可选择修改现有代码，或者删除不再需要的代码。
软件验证和更新
合并差分包后，对新软件版本进行验证，确保它在目标ECU上正常运行。如果一切正常，系统将完成升级过程，新版本的软件将被激活并开始运行。
差分的实现方式主要有两种：基于文本文件的差分和基于二进制文件的差分，其区分在于对比文件的差异，前者是基于逻辑上的，后者是基于物理上的。
在升级时，通过与制作过程对应的还原工具，将差分包还原后写入到存储器中，保证写入后的内容与目标版本内容一致。
图2-9差分计算过程
差分计算程序接收旧版本v1.0与新版本v1.1后生成差分升级包v1.0-v1.1-update.patch。ECU端从云端下载差分升级包v1.0-v1.1-update.patch后，开始后续的差分还原操作。
图2-10差分还原过程
差分还原算法输入参数为旧版本安装包v1.0与差分升级包v1.0-v1.1-update.patch。通过差分还原算法处理后得到最新的完整升级包v1.1。ECU端安装v1.1完整升级包实现升级目标。
②安全启动
安全启动(SecureBoot)用于保证固件启动的代码受信任的安全保证机制，它通过在引导加载过程中，对加载固件进行检验，从而防止加载和执行恶意代码。固件的每一步加载都经过数字签名认证，而每一步签名认证的根证书中的密钥需要与固化在芯片内部不可修改的签名密钥匹配，从而行成一个完整信任链。
③安全校验
ECU端需要具备对所安装软件包进行完整性校验和真实性校验的能力，这要求ECU有能力对更新数据进行签名验证。传统的ECU刷写过程通常只通过循环冗余校验验证更新数据的完整性，而无法验证其真实性，存在被刷写非法软件的风险。
2.4人机交互
2.4.1人机交互要素分析
车端的人机交互主要体现在信息娱乐系统上，覆盖到OTA的整个过程，包括信息提示、用户确认、关键信息显示等。人机交互过程需要考虑的要素大致可以分为两个方面，即法规符合性和使用便利性，如表2-8所示。
表2-9人机交互要素分类及示意
法规符合性
符合GB《汽车软件升级通用技术要求》
使用便利性
版本信息可查看
升级功能可设置
升级信息提示
升级前用户可以选择升级方式，并且支持升级包下载进度的展示，和用户手动取消下载。下载完成后，用户需要再次确认是否升级。
升级中显示升级条件的检查，需要实时显示进度；如果条件不满足，要给予用户明确的提示。
如果出现异常情况要进行回滚，可以明确提示回滚状态和及其进度。
升级后提示升级的结果成功或失败。
2.4.2人机交互方式分类
基于实际业务要求，各家OEM的OTA人机交互方式各有差异，本节共总结6种主流升级方式，并针对营运车辆与非营运车辆使用性质不同，分别展开分析，具体如表2-10所示。
离车升级：升级过程会影响用户使用车辆功能，在升级包下载完成、确认用户离车后进行升级条件检查，条件满足开始升级。
√运营公司的车辆管理平台远程管理车辆升级
√
无感升级：升级过程不影响用户使用车辆功能，升级完成后版本切换需要用户确认，系统重启后即可实现版本切换，用户无需等待升级包写入的过程。无感升级可通过AB分区技术来实现。
立即升级：用户在车机端点击确认升级后，立即发起升级条件检查，条件满足开始升级。
√车辆回归单位后，统一安排升级
手机远程升级：用户收到升级通知后，可通过手机端APP进行版本检查，通过手机下发下载、升级或者取消等指令的操作，并且在APP上实时查看下载和升级的过程、升级结果。