SOTA一般涉及应用层小范围的功能局部更新，不包括汽车核心系统，对整车性能和安全影响较小，升级前置条件要求较低。SOTA的增量更新策略，可以大幅减小升级包文件大小、从而节约网络流量和存储空间。
1.1.2远程固件升级(FOTA)
1.1.3远程配置(COTA)
1.1.4远程诊断/远程数据更新(DOTA)
DOTA有两种常见解释：
DOTA(DataOver-The-Air)，即远程数据更新，是指一些独立于软件程序存在的数据包的更新，比如，地图数据、语音数据和算法模型数据等。这类更新的特点是数据量比较大，更新流程相对独立，比如，地图数据通常由地图应用自行更新，而数据量也可能高达几G到几十G。
1.1.5其他类型(XOTA)
1.2OTA应用场景
1.2.1车辆生命周期维度
表2-1车辆生命周期维度的软件更新应用
1.2.2软件运营管理维度
从软件运营管理的维度OTA的典型应用场景如下表2-2所示。
表2-2软件运营管理维度的软件更新典型应用场景
二、汽车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的基本实现流程
2.2OTA云平台架构及关键技术
2.2.1云平台架构
图2-2OTA云服务框架图
（1）前端展示层
前端展示层的划分，是基于前后端分离开发方式设计的架构分层模式，主要负责Web端用户交互页面的功能。核心思想是前端页面通过调用后端的接口并进行交互，前端专注于交互页面的开发，业务逻辑由后端负责。对OTA云平台而言，前端展示层可以理解为业务服务层的用户交互接口，其展示功能与具体业务功能一一对应。
（2）指令控制层
各业务平台与网关接入层的连通介质，接收来自业务系统指令并将指令发送至网关可访问的缓存中，接收来自网关回写的升级状态至各业务系统可访问的消息队列中。
（3）网关接入层
针对不同的数据格式及上层需求，接收封装来自车载终端传输的数据，并流
向缓存、消息队列等中间件。
（4）业务服务层
表2-4常见服务举例
（5）PKI系统
（6）外部数据系统
另外，OTA系统在升级前可通过远程诊断系统获得最新的ECU配置信息及状态信息，并且当远程诊断系统发现问题后，可以通过OTA系统下发经过测试验证的补丁包来修复。对于一些有运营需求的主机厂来说，通过OTA系统配合软件可售系统，可以实现软件付费升级、功能付费使用等后向运营，真正实现“千车千面”、“用户定义汽车”。
（7）数据存储层
数据存储层包括数据库集群、缓存和存储节点，分别用于存储OTA云平台不同类型的数据。其中，数据库集群，主要用于存储车辆信息版本信息等关系型数据；缓存，为了解决数据库性能瓶颈问题，可以通过多架设一层缓存层来减少对数据库的直接访问；存储节点，针对较大的升级包、配置文件等需要提供车端下载的文件，通常可以存储在分布式存储节点上。
2.2.2关键技术
（1）安全技术
OTA服务端以及企业IT管理系统、安全服务端、web控制台、文件服务端等关联系统，会面临传统云平台的所有安全威胁。为保证OTA升级的安全性，常用安全技术如表2-5所示。
表2-5OTA云平台常用安全技术
（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主控功能模块
（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]
图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升级，其实有三种实现方案：第1类基于硬件辅助的A/B交换方案。该方案要求ECU内存足够，而且支持地址重映射，也就是当新版本软件刷写完成，通过更新映射地址来激活新版本软件，即新版本软件运行的入出地址不变；第2类与第1类的差别在于ECU硬件不支持地址重映射，激活新版本软件的入出地址会变化；第3类，基于外扩内存的A/B交换方案，该方案是需要额外的外扩内存，备份当前版本软件和旧版本软件，新版本软件会先刷写原先的旧版本软件空间，然后擦除ECU内存的当前版本软件，刷写新版本软件，完成激活。
AB升级方案示意图如图2-7所示
图2-7AB升级方案示意图
③智能ECU单分区升级方案
图2-8智能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端升级技术
①差分升级
表2-8差分升级基本流程
差分的实现方式主要有两种：基于文本文件的差分和基于二进制文件的差分，其区分在于对比文件的差异，前者是基于逻辑上的，后者是基于物理上的。在升级时，通过与制作过程对应的还原工具，将差分包还原后写入到存储器中，保证写入后的内容与目标版本内容一致。
图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人机交互要素分类及示意
2.4.2人机交互方式分类
基于实际业务要求，各家OEM的OTA人机交互方式各有差异，本节共总结6种主流升级方式，并针对营运车辆与非营运车辆使用性质不同，分别展开分析，具体如表2-10所示。