02 引言
OTA（Over-the-Air）即空中下载技术，是通过移动通信的接口实现对软件进行远程管理。OTA是汽车软件升级的通道，其价值是将新软件远程刷写到汽车中。软件定义汽车逐渐成为业内共识，汽车软件存在两个趋势：第一、整车厂交付的汽车将不再是一个功能固化的产品，而是一个持续更新的智能设备，在整个生命周期内，需要持续支持软件迭代升级；第二、随着软件量的增加，软件bug将成为潜在风险，OTA可以有效解决软件故障，通过软件升级降低开发周期短带来的软件风险问题，完成软件漏洞的修复，减少软件问题导致的召回。OTA远程升级技术已逐渐成为智能网联汽车的基础功能，通过持续迭代的更新软件，不断提升汽车的潜在价值，从而带动智能网联汽车行业全新的商业模式。
03 需求分析
汽车整车OTA受限于电子电气架构，存在很多困难。随着汽车电子化技术的提高，电子控制单元ECU占领了诸如动力、底盘、车身、座舱以及自动驾驶等领域，ECU的数量多达几十甚至上百个。这些ECU是由不同的供应商提供，运行着各种不同的操作系统和应用软件，整车OTA意味着所有相关的控制器都要在一次升级过程中完成软件版本的更新，因此升级的总时间和成功率是OTA的两大难点。而且为了保持软件升级的稳定性和安全性，车辆部分功能将被禁用，要求车辆处于熄火的状态，长时间的升级会影响用户体验。
为了提高整车OTA的稳定性、缩短升级时间，本文提出了一种基于整车电子电器架构的OTA设计方案，实现整车版本管理和整车软件升级。
04 总体方案设计
整车OTA的功能是控制和执行车上各类控制器的软件升级，因此需要对所有关联控制器提出统一的升级要求和规范，并对升级过程进行集中控制。本方案遵循“集中控制、分而治之”的原则，实现了“两类对象、两个过程、四种角色”：
1）两类对象：即升级对象分为2类。
第一类是智能控制系统，基于操作系统具备自升级能力，如座舱域的车机、仪表等，驾驶域的自动驾驶控制器等；
第二类是传统的控制器即ECU电控单元，没有操作系统而是由刷写上位机来完成软件升级。
两类升级对象须遵循各自的技术要求：智能系统要求实现版本信息维护、文件存储、自升级以及升级异常处理等功能；传统的控制器要求满足UDS（汽车通用诊断服务）的刷写规范。升级对象分类的目的在于将车上众多的控制器按照其软件升级方式的不同进行分类管理，对同类的控制器提出一致的技术要求规范，以便于实现OTA升级对象管理的标准化。
2）两个过程：即升级过程分为2个过程。
第一个过程是下载部署过程，服务器将升级任务通知到车辆，车端从服务器端下载升级包到本地，这个过程可在车辆行驶中进行不会对用户产生影响；
第二个过程是安装过程即“车端各个控制器执行软件升级”，这个过程需要保持车辆处于特定的状态如车速为零、发动机熄火等，所以不能正常用车。下载部署过程和安装过程中的执行对象、执行条件以及控制策略是不同的，将过程分段的目的在于实现OTA不同过程的差异化控制，能够对各种过程进行集中控制，并在一个模块中实现。
3）四种角色：即功能划分为4个角色实现职责分离。
第一个角色是OTA服务端（OTAServer）负责web管理平台、升级数据管理和升级文件存储；
第二个角色是OTA客户端（OTAClient）完成车上所有控制器的版本收集，与服务端交互获取升级任务和上报升级状态，下载升级包，将升级包和升级信息分发到执行升级的控制器，负责人机交互功能；
第三个角色是OTA主控模块（OTAMaster）检查整车的安装条件、保持安装状态、按照升级策略控制安装过程；
第四个角色是OTA子控模块（SubMaster）保存升级包、完成所在控制器的升级功能，能够通过车内总线或者USB等其它的物理通道对其他控制器或者固件进行升级。
OTAClient、OTAMaster和SubMaster这三个模块运行在车端，基于整车电子电器架构被部署到不同的控制器中。角色划分的目的在于对功能进行模块化设计，便于在不同车型上实现复用，从而实现该OTA方案的平台化和可移植性。
基于上述的设计原则和设计思路，系统设计方案如图1所示：
图1 系统设计方案
在车端，下载部署过程，包括图1中的步骤1.1和步骤1.2，由OTAClient发起，先从OTAServer下载文件，再将升级信息和升级包分发到各个执行升级的SubMaster；安装过程包括图1中的步骤2.1和步骤2.2，由OTAMaster发起，进行安装控制，判断整车安装条件是否满足，维持整车安装状态，按照安装顺序向各个SubMaster发出安装命令；SubMaster分别执行具体的升级操作，完成自升级或者对其他控制器的刷写。各个SubMaster的升级可以独立执行，因此需要OTAMaster总体协调。
05 详细设计
5.1 服务器端设计
服务器端,OTA Serve主要实现OTA数据的管理，为了支持整车升级，本方案设计了车型配置管理、整车版本管理、升级任务管理这三个功能。
1）每个车系需要设置车型配置组，一个组对应一个或多个车型配置，一个车型配置只能对应唯一的一个组。每个组需要配置所有控制器的软件集合，通过软件ID和控制器的软件保持对应关系。
2）整车版本的管理粒度为车型配置组，每个车型配置组的软件版本按整车大版本来进行管理，大版本是一个虚拟的版本，是车型配置组下的所有控制器软件版本的集合标识。
3）升级任务包括升级的控制器对象、安装策略、升级范围。新增任务时需要设置车系、车型配置组以及对应的目标整车版本。每个升级对象可设置其软件更新的方式、安装的时间和异常处理的上限次数。安装策略包括安装条件、安装顺序和软件版本依赖。
a)安装条件包括：行车档位、电池电量范围、温度下限、电源档位等。在OTA管理平台设置可设置每次OTA的安装条件，并生成信息到升级任务中。
b)安装顺序包括升级对象的并行或者串行升级顺序。在OTA管理平台设置SubMaster和升级对象的包含关系以及升级对象之间的安装依赖关系，在创建升级任务时根据上述关系自动生成升级任务的安装顺序。
c）软件版本依赖包括多个关联组，关联组内的升级对象版本要支持同升同降。在OTA管理平台设置控制器之间的关联关系，创建升级任务时根据关联设置自动生成升级任务的关联组。
5.2 汽车端设计
5.2.1流程设计
在车端，包括下载部署过程和安装过程，这两个过程分别由不同的功能模块来执行，保证各个过程中有相同的控制主体和统一的控制流程。
OTAClient通常部署在车机或者T-BOX上，具有车联网功能、人机交互功能、文件存储和分发的功能。OTAMaster通常部署在中心节点网关上，对升级过程进行控制和协调。SubMaster会有多个，通常部署在有操作系统（android、qnx、linux等）的智能控制器上，如车机、仪表、智能驾驶控制器等。另外，网关负责传统控制器的刷写功能，也需要部署一个SubMaster模块。车端的架构如图2所示：
图2 车端的架构设计
1）下载部署过程，OTAClient将下载过程和分发过程进行同步处理，使两个过程可以并发执行，以缩短升级包下载部署的时间，同时减少对储存空间的需求。OTAClient根据硬件通道的不同，优先下载数据传输速率低的SubMaster节点的升级包，最后下载OTAClient所在的SubMaster节点的升级包；单个SubMaster的升级包下载完成就可以进行文件部署。如果在下载部署过程中，车辆熄火，则停止下载和部署；下次点火后，继续在断点处执行。整个过程可以在行车中执行，不影响用户用车。
2）安装过程，由OTAMaster集成控制，用户确认发起安装后，OTAMaster根据升级信息中安装条件，检测整车安装条件是否满足，发起安装后一直保持安装的状态，如电源档位、行车档位、整车OTA状态等。OTA Master依次向各个的SubMaster发送安装请求；收到安装请求，SubMaster各自执行升级，SubMaster之间可以进行并行升级。通常网关作为传统控制器的SubMaster，实现各个网段之间的并行刷写。OTA Master按照升级任务中安装顺序执行，安装顺序由多个子任务组成，子任务之间串行执行，而子任务内的升级对象则是并行执行升级。如果控制器的安装顺序存在依赖，则需要把被依赖和依赖的控制器划分到不同的子任务中，并分配为先后的顺序。升级任务的安装总时间如公式（1）所示：
其中，t_n 为子任务n中的耗时最长的SubMaster的安装时间。
5.2.2协议设计
为了满足车端OTA过程中功能模块之间数据交互的，本方案中设计了两套通信协议，如图3所示。
图3 车端的通信协议
1）部署协议，主要在部署过程和人机交互过程中使用。协议采用的是客户端和服务端（C/S）的模式，OTAClient作为客户端，SubMaster和OTA Master作为服务端。物理的通道包括CANFD、以太网、USB等。部署协议的交互覆盖四个子过程。
a）子过程1.1版本收集：OTAClient向各个SubMaster发出版本收集请求，SubMaster收集版本的范围包括其所部署的控制器的软件版本、以及所负责刷写的其他控制器或者控制升级的其他固件的软件版本。
b）子过程1.2升级信息和升级包的分发：OTAClient下载完成后，要向各个Sub Master传输升级包，以及升级对象的信息。OTAClient向OTAMaster发送升级任务信息。
c）子过程1.3发起安装请求：OTAClient根据人机交互的触发，发送安装请求到OTAMaster；如果支持升级取消，也通过该子过程发送请求。
d）子过程1.4安装状态查询：OTAClient查询OTAMaster的安装条件检查及结果、安装执行的状态、安装进度和安装结果，用于人机交互界面的显示。
2）安装控制协议，主要是在安装过程中使用，通过诊断服务，借助诊断通道到达全车所有的控制器。安装控制协议的交互覆盖了两个子过程分别是，子过程2.1安装控制：OTAMaster按照升级任务，向子任务中的各个SubMaster发出安装命令请求，查询安装的进度，SubMaster返回执行状态。子过程2.1回滚控制：当所有的子任务安装执行完成后，OTAMaster读取安装结果，判断是否有升级对象安装失败；并读取升级任务中的关联组新，如果升级失败的对象和其他升级对象是在一个关联组内，则向该组内其他升级对象的SubMaster发出回滚命令请求，查询回滚的进度，SubMaster返回执行状态。
06 应用案例
按照以上的整车OTA设计，在某车型项目上开发整车OTA功能，如图4所示，部署升级功能模块和搭建升级通道。车机作为OTAClient，网关作为OTA Master，实现对座舱域、车身域、动力域、底盘域、自动驾驶域的控制器的OTA功能；覆盖了18个控制器，其中包括4个智能控制系统，14个传统控制器；部署了5个SubMaster节点，分别是车机、仪表、网关、自动驾驶控制器、驾驶辅助控制器。
图4 某项目整车OTA方案
在OTA管理平台配置车型信息和控制器的升级依赖关系，发布升级任务，选择对18个控制器，即所有升级对象进行升级，云端自动生成升级任务信息，其中的安装顺序如图5所示。
图5 某项目整车OTA安装顺序
按照图5的安装顺序，对车端OTA的过程进行记录，下载部署过程和安装过程的时间分别如表1和表2所示。从下载到安装一共需要44分钟，影响用户体验的升级时间主要是安装过程，用户需要等待升级完成的时间是28分钟。如果所有控制器都采用串行的升级顺序，安装过程的时间是77分钟。本方案用户等待升级时间明显缩短，相比串行升级时间降低63.6%，大幅提升了OTA的用户体验满意度。
表1 下载部署过程的时间
表2 安装过程的时间
如表2所示，安装过程的耗时瓶颈主要在CANFD1网段，如果在其他网段上适当增加控制器则不会影响总的时间。如果要缩短总时间，需要对CANFD1网段的控制器进行优化，优化方向主要是减少升级包大小、将传统控制器改为智能控制系统等。
07 结论
本文提出的一种基于电子电器架构的整车OTA设计方案，实现了对升级对象的统一管理、对升级过程的集中控制、对升级功能的模块化设计。从试验的效果来看，通过OTA管理平台配置升级策略、明显缩短了升级时间，是一个可实施、可平台化的设计。本设计方案可应用于其他车型的整车OTA，解决了整车OTA控制器多、升级过程不可控、升级时间长和稳定性差等问题，形成了一套从云端到车端完整的持续迭代更新能力和智能网联汽车价值提升的新动力。
