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