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 车辆生命周期维度的软件更新应用

1.2.2 软件运营管理维度

从软件运营管理的维度 OTA 的典型应用场景如下表 2-2 所示。

表 2-2 软件运营管理维度的软件更新典型应用场景

二、 汽车 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 的基本实现流程

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 常见服务举例

（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 云平台常用安全技术

（2） OTA 技术

OTA 系统常用升级技术如表 2-6 所示。

表 2-6 OTA 云平台常用升级技术

2.3 OTA 车载端架构及关键技术

2.3.1 车载端架构

OTA 车载端功能模块主要包括 2 大部分，即 OTA 主控和 OTA 对象，如图 2-3 所示。OTA 主控是车端 OTA 系统的核心，车端所有 OTA 业务逻辑均由主控实现，包括上报车辆信息、下载更新文件、升级包安装、车辆状态管理、人机交互等。

图 2-3 车载端功能模块(参考 AutoSAR UCM)

（1） OTA 主控功能模块

按照车载端的工作流程，车载端的功能模块包括：OTA 客户端负责与云端进 行数据交互；下载模块负责升级包下载及分发；升级管理模块负责升级过程的控制；升级代理负责执行软件刷写或者软件安装；人机交互模块负责升级信息提示、用户输入、升级过程的展示等，如表 2-7 所示。

表 2-7 OTA 主控功能模块

（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 差分升级基本流程

差分的实现方式主要有两种：基于文本文件的差分和基于二进制文件的差分， 其区分在于对比文件的差异，前者是基于逻辑上的，后者是基于物理上的。在升级时，通过与制作过程对应的还原工具，将差分包还原后写入到存储器中，保证写入后的内容与目标版本内容一致。

图 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 人机交互要素分类及示意

2.4.2 人机交互方式分类

基于实际业务要求，各家 OEM 的 OTA 人机交互方式各有差异，本节共总结 6 种主流升级方式，并针对营运车辆与非营运车辆使用性质不同，分别展开分析，具体如表 2-10 所示。

表 2-10 人机交互方式分类