OTA刷新系统架构主要由服务器（云平台）、传输媒介（3G/4G/WIFI/5G）和车载终端（ECU）三部分构成。基于OTA刷新系统架构设计，测试人员需详细了解服务器（云平台）和车载终端（ECU）进行远程诊断实现，更好地设计用例进行测试覆盖。

一、OTA服务器

OTA刷新系统架构

OTA服务器又称为OTA云平台，在软件刷新过程中起连接用户（车厂、车主）与车辆的作用，为实现车辆远程智能诊断及故障预测分析，OTA云平台设计一般要求都部署在车厂的私有服务器上，能够支持多种车型OTA升级。

1、OTA云平台整体架构

OTA云平台主要包含用户管理、固件管理、车辆管理、升级任务管理、统计分析管理、用户操作日志管理模块，如下图所示。

OTA云平台整体架构

用户管理模块：OTA云平台为车厂提供的是一套软件系统，因此需要有用户管理模块来实现用户权限分配及管理工作。系统搭建环境默认创建超级管理员用户，由超级管理员用户登录后在用户管理模块实现用户新增，用户查看，用户信息修改等功能操作。固件管理模块：主要为用户提供固件上传，固件查询及编辑（版本管理）功能。用户将车厂测试通过的固件上传到OTA云平台，用以升级任务创建。

车辆管理模块：主要包含车辆ECU信息同步、车辆ECU信息获取及车辆信息查看功能。车辆ECU信息同步子模块对接主机厂MES（生产制造）系统，可导入不同车型配置信息用以OTA升级时对目标车辆筛选及升级策略配置。

升级任务管理模块：主要负责为用户提供升级任务创建、升级任务审批、升级任务查询、升级进度查询功能。

统计分析管理模块：主要负责统计分析已发布的升级任务执行结果情况。用户可以查看每个升级任务对应的升级车辆的成功率、失败原因统计及未执行升级原因统计分析。

用户操作日志管理模块：主要负责为超级管理员用户提供所有登录OTA云平台的用户的所有功能操作记录。

2、OTA云平台诊断要求

OTA云平台须符合高可用、高性能、可扩展、可监控的诊断要求。具体表现为以下方面：

1）采用微服务的Browser/Server（浏览器/服务器）的服务框架，能够支持多种负载均衡模式（服务消费者从提供者列表中，基于软负载均衡算法（随机、权重、轮询、最少并发优先等）选一台服务提供者进行远程调用，如果调用失败，需自动诊断并切换另一台服务提供者）；

2) 立体化监控，能够对系统资源（CPU、负载、内存、网络和磁盘等）基础指标进行详细的监控，对于系统的每一次服务调用响应时间和出错率进行故障诊断和预警；

3) 系统具备高可靠和高性能，确保整个系统上运行的业务体系能够为客户系统提供99.9%可用性的高效优质服务；

4) 采用服务集群的管理技术，利用多个计算机并行计算从而获得高性能和冗余备份，即便单机故障时整个系统仍能正常工作；

5) 系统具备故障隔离机制，在应用软件系统发生故障时，通过故障隔离可将故障危害限制在最小范围内，提高系统对外服务的整体能力。

二、OTA车载终端

OTA车载终端作为OTA升级的执行方，以OTA推送方式为例，用户可感知体验的部分较多，车载终端的设计重点需考虑人机交互、网络诊断架构设计、ECU刷新时长、软件存储及刷新策略、远程故障诊断机制。车载终端网络框架如图4所示，OTA主控节点由TBOX和中央网关（GW）负责，升级界面由车机负责，被刷新的ECU要求支持车载以太网（DoIP）或CAN总线（DoCAN）通讯协议，若ECU升级包较大（如上百兆）需要支持数据差分算法。

OTA车载终端框架

1、OTA人机交互设计
OTA升级时除了云平台推送升级任务到车主APP提醒外，还需车端（车机或中控）配合开发显示一些升级界面（如升级进度、升级条件提醒等），用于提醒车主车辆设防及离车等配合操作。

2、网络诊断架构设计

目前车载网络主干网仍以成熟的CAN总线通讯为主，但对于软件包较大的ECU由于刷新时长等因素，使用了车载以太网技术来突破CAN总线的带宽限制，如下图所示。

主要架构包含OTA主控节点（TBOX和GW）和被刷新ECU。TBOX主要负责对外与云平台的连接通道安全可靠，其内部集成了PKI认证及身份鉴权等安全模块；GW主要负责对内部网络的连接通道及集成诊断刷新机功能。

刷新ECU根据软件包大小及理论刷新时长（如不超过20分钟），在CAN总线拓扑架构上增加了以太网接口设计，使用DoIP协议进行ECU诊断刷新。

网络诊断架构图

3、ECU软件存储及刷新策略

OTA刷新前ECU软件升级包由云平台下发到车端OTA主控节点内存储，由文件存储模块来负责整车软件升级包的存储及备份包的管控。

升级管理模块主要负责刷新机刷新策略控制，OTA刷新需要设计多次冗余刷新策略，即OTA后台发起一次升级任务后，同一辆车内OTA主控节点刷新机通常会对同一个ECU执行多次刷新尝试请求，减少偶发失败因素，提高OTA刷新成功率。被刷新ECU主要分为传统嵌入式芯片ECU和复杂带操作系统（如Linux、Android、AutoSAR）的ECU。

根据ECU的硬件资源情况，我们又设计了如下ECU内部存储及刷新策略：如图11所示的带操作系统ECU，硬件存储资源丰富，控制器内分配了两个不同启动区分，具体刷新过程如下：

1) 默认出厂状态启动分区1激活，运行V1.0版本程序，启动分区2内无备份程序；

2) 当OTA发起第一次V1.1版本刷新请求时，刷新数据会存储在备份分区（分区2），刷新成功后激活启动分区2，并交换备份分区（分区1），下次上电后程序由启动分区2启动并正常工作；

3) 当OTA发起第二次V1.2版本刷新请求时，刷新数据会被存储在备份分区1，刷新成功后激活启动分区1并交换备份分区（分区2），下次上电后程序由启动分区1启动并正常工作；

4) 当OTA发起第三次V1.3版本刷新请求时，刷新数据会存储在备份分区（分区2），刷新成功后激活启动分区2，并交换备份分区（分区1），下次上电后程序由启动分区2启动并正常工作。

如此循环交换分区刷新，即便遇到刷新失败当前启动分区无法正常启动时，ECU也还可以通过自回滚从备份分区启动，确保系统工作正常。

带操作系统的ECU软件存储及刷新策略图

对于传统嵌入式ECU，通常采用BOOT+APP的软件架构，如图12所示。功能越复杂的ECU，其选择的主控芯片APP容量越大，为了实现ECU内部软件自回滚功能，需要将APP空间划分一部分用于软件备份存储（如APP2）。

当ECU被刷新时，由BOOT代码负责提供升级流程引导，将升级包存储到APP区域（一般为程序启动入口地址空间）。

由于嵌入式芯片ECU程序启动入口通常只有一个，因此，当刷新失败（APP激活不了）时，由BOOT引导程序指引复制APP2的备份程序到APP区域进行回滚操作并启动，确保ECU工作正常。对于APP容量较小不支持APP2空间划分的ECU，只能依靠OTA主控节点实现升级包的备份存储。

嵌入式ECU软件存储及刷新策略图

四、OTA远程故障诊断设计

OTA刷新目前主要是通过诊断通讯方式实现的ECU刷新条件检查、刷新过程数据传输及刷新后复位重启等操作，刷新过程中被刷新ECU由于进BOOT或其它原因无法保证应用程序正常运行（无感刷新方式除外）时，需要提前进行ECU故障屏蔽设计以免刷新过程造成整车出现一些故障码，误导后续远程故障诊断及统计分析。

OTA刷新过程中，诊断故障屏蔽可采用UDS诊断协议中的0x85（Control DTC Setting）服务来实现。OTA远程故障诊断，还要解决的一个难点是与本地故障诊断的冲突问题。OTA云平台难以识别本地诊断设备，因此，必须要在车端集成远程诊断与本地诊断的仲裁判断逻辑。由中央网关（GW）负责仲裁协调，当OTA刷新过程中，网关屏蔽本地故障诊断路由转发功能；同理，当有本地诊断设备时，网关屏蔽远程故障诊断路由转发功能，屏蔽只在当前点火循环有效。