基于空中激活的近场软件升级方法

范玲玲 柳旭 张建平 徐晋吉 刘闯 沙伟华

（中国第一汽车股份有限公司研发总院，长春 130013）

1 前言

车联网技术、高级自动驾驶技术发展迅速，对汽车软件快速升级的能力提出了要求。当前，汽车软件升级方法主要包括线下诊断仪升级和空中激活（Over The Air，OTA）升级[1-3]。

王栋梁等[4]提出一种安全、方便、可靠的整车OTA 解决方案，建立云服务器端与车辆客户端之间的数据通路，使用差分算法、回滚重刷机制等关键技术，实现整车Ethernet/CAN/LIN 混合电子电气架构的所有节点电子控制单元（Electronic Control Unit，ECU）的升级更新。刘志军等[5]构建了整车网联系统架构，并设计了一种基于OTA 技术的ECU 远程刷写协议，利用移动通信网络基于OTA 更新ECU软件。高天宇[6]提出了一种基于差分方法的远程数据刷写系统，实现了汽车ECU 软件迭代升级和相关数据的更新刷写。

上述文献研究的整车OTA 升级技术主要分为2个阶段：OTA 云端发布升级任务，车端接入获取升级任务；经用户确认升级或者有效期内未升级，任务结束。只要云端任务下发到车端，车端就具备了软件刷写的主动权，如用户不及时确认升级，任务就无法完成，且无线网络连接无法保证车辆实时在线，车端任务也无法及时被云端终止。

综上，现有OTA 升级技术更适用于售后阶段，同时，用户频繁使用车辆更有助于车端长时间接入OTA 云端，并确认完成软件升级。售前阶段主要包括试制、生产、储存、运输等，车辆主要处于静止状态，接入云端的次数非常有限，单纯依靠现有OTA的升级模式无法满足软件快速迭代的需求，也就无法保证车辆售出时的软件版本一致性。

因此，本文提出一种基于OTA 的智能汽车近场软件升级技术，主要由近场设备主控车端完成软件升级，近场设备可方便地从OTA 云端获取某一车型的ECU 软件信息，控制单辆车完成任意ECU软件升级，或者控制批量车完成某一整车基线版本升级。

2 近场软件升级技术

基于OTA 的智能汽车近场软件升级技术复用OTA 系统已有的云端升级包管理功能、ECU 软件刷写功能。由近场升级设备从OTA 云端获取车型ECU 的升级包及基线，控制车端依次完成ECU 的软件更新，车端被动执行，其升级方式包括近场客户端完成单辆车升级和近场服务器完成批量车升级。

其中：近场客户端可通过有线连接或局域网无线连接的方式接入车辆，并控制车端依次完成整车ECU 的软件升级；近场服务器可通过局域网连接的方式与车端建立连接，由车端主动发起接入请求，近场服务器依据车型基线控制车端依次完成整车ECU 的软件升级[4-5]。近场服务器主要包括工厂服务器，近场客户端主要包括计算机客户端、手机APP 和USB 设备。近场软件升级框架如图1 所示。

图1 近场软件升级框架

因此，近场软件升级技术相比现有的诊断仪刷写，不仅在功能上更加全面，更能配合OTA 系统实现智能汽车整车软件版本一致性的管理需求，同时节省了额外开发ECU 刷写上位机的成本，在使用上更加灵活。

3 近场软件升级技术

3.1 近场客户端设计

近场客户端采用主动升级方式，由客户端主动发起车辆接入、软件升级请求，升级模式分为单ECU 升级和批量多ECU 升级。近场客户端部署的载体可以是便携式计算机、手机或者车机，可灵活应对操作人员现场对单辆车进行整车ECU 软件升级需求。当客户端部署在车机上时，通过接入USB设备获取ECU升级包。

近场客户端为桌面式软件，具备可视化用户界面（User Interface，UI），主要功能包括车型管理、软件升级、系统管理及安全管理，如图2所示。

图2 近场客户端功能

车型管理功能主要完成车型与ECU 的绑定关系，可通过手动录入或云端同步的方式更新，操作人员可依据待升级车辆进行相应的车型切换选择。

软件升级功能主要完成与车端的接入及数据交互，显示车辆上报的车辆基本信息及各ECU 版本信息，操作人员依据车辆信息选择升级包，开始升级并实时显示升级状态，选择的升级包可以是单包或多包，从而执行单ECU升级或批量多ECU升级。

安全管理功能主要完成近场客户端与OTA 云端、车端的安全通信管理，包括登录的双向认证、客户端的账号安全管理、数据传输的安全管理。

系统管理功能主要完成近场客户端的相关连接设置，包括OTA 云端访问地址、车端连接地址、本地存储路径的管理[7-9]。

3.2 近场客户端升级流程设计

近场客户端软件升级流程主要包括：

a.车型同步及升级包下载。近场客户端首先连接OTA 云端同步所有车型及ECU，操作人员选择即将应用的车型后，近场客户端向OTA 云端获取该车型对应ECU 的升级包列表，操作人员可根据需要下载相应升级包，近场客户端可详细显示升级包下载进度，并将已下载的升级包名称加入本地升级包列表[10]。

b. 连接车辆及身份认证。近场客户端通过有线或者无线局域网的方式连接车辆后，向车端发起登录请求并上传证书等身份信息，车端对近场客户端完成身份认证后，上报车端基本信息于近场客户端显示。

c. ECU 软件同步更新。操作人员依据近场客户端上的车辆显示信息可批量选择需升级的ECU及对应的升级包，开始逐一更新ECU 软件，近场客户端可显示详细升级进度。

d. 升级结束及断开连接。所有ECU 升级完成后，近场客户端显示车端最新状态，操作人员依据车辆信息分析该车辆是否已完成软件升级，并断开连接[11-12]。

3.3 近场服务器设计

近场服务器采用车辆主动接入、服务器主动升级方式，由车辆主动发起接入服务器，服务器依据车辆信息下发升级指令，升级模式为整车版本升级。近场服务器可部署在服务器集群中，通过局域网网页访问，处于同一局域网中的车辆可接入近场服务器，完成整车控制器版本升级。近场服务器适用于对批量车辆进行软件版本拉齐，如工厂阶段下线车辆软件灌装、运输阶段批量车辆软件升级等场景[13]。

近场服务器以微服务器加网页访问的方式实现，可实现车辆信息收集，主要包括车型管理、车辆管理、软件升级、车辆接入、系统管理及安全管理功能，如图3所示。

图3 近场服务器功能

车型管理主要完成车型、配置、ECU 及基线的管理，可通过手动录入、批量导入或云端同步的方式更新。

车辆管理功能主要完成接入车辆的状态管理，包括车辆识别码（Vehicle Identification Number，VIN）、车型、配置、整车软件版本、ECU 版本信息、连接状态、升级状态的管理。车辆首次接入近场服务器后，车辆管理模块登记该车辆的基本信息，后续每次接入均会记录接入状态及升级状态。

软件升级功能主要实现升级任务的创建、任务状态查询、任务终止功能。服务器端为某一个车型配置建立升级任务后，该车型配置的车辆接入后将执行一次软件升级任务。

安全管理功能主要完成近场服务器与OTA 云端、车端的安全通信、服务器账号管理，包括车辆接入的双向认证、服务器端的账号安全管理、数据传输的安全管理。

系统管理功能主要完成用户管理、日志管理、导入导出日志管理、同步日志管理。该功能支持新增用户、修改用户、删除用户、重置密码、查询操作日志、导出操作日志、查询导入导出日志、下载导入导出文件、查询同步日志、导出同步日志、查看同步日志。

3.4 近场服务器端升级流程设计

近场服务器端升级流程为：

a.车型、基线及升级包同步。近场服务器首先连接OTA 云端同步所有车型及ECU，操作人员可手动同步某车型对应的所有基线及升级包，也可手动新建或者导入某个基线。

b. 车辆接入及身份认证。车端开启近场升级服务后，会周期性地尝试请求接入近场服务器，近场服务器收到车辆接入请求后进行身份认证，认证通过后上报车辆基本信息，近场服务器记录保存。

c. ECU 软件同步更新。近场服务器依据车辆上报信息查看该车型配置是否有升级任务，若有则下发需要更新的ECU 软件包，完成该车辆的基线拉齐操作，近场服务器可显示详细升级进度。

d. 升级结束及断开连接。车端完成下发ECU软件更新后上报车辆最新状态，近场服务器依据状态信息判断车辆软件是否为最新基线状态并显示，之后断开连接[14-15]。

3.5 近场服务器与近场客户端的差异

近场客户端采用与单一车辆进行点对点连接方式，人为触发每一次软件升级，因此同一时刻只能有一辆车连接近场客户端进行升级，升级完成后近场客户端也无需记录车辆的状态，故只需要在软件升级功能模块中实时完成接入车辆的信息显示、软件升级执行等。

而近场服务器采用车辆主动接入方式，可接受批量车辆同时接入，无需人为触发，服务器建立升级任务后，车辆接入即可自动触发软件升级，因此服务器的车辆管理功能需要记录每一辆接入车辆的升级信息。

近场客户端与近场服务器的功能异同如表1所示。

表1 近场客户端与近场服务器功能异同

4 关键技术

4.1 近场升级工具跨平台设计

近场升级工具形式多样，包括便携式计算机、手机、车机、工厂服务器，但实现的功能基本一致，且近场客户端、近场服务器与车辆的连接方式有所区别，因此需要设计实现既能兼容不同载体平台，又能满足不同车辆连接方式的近场升级技术。近场工具采用QT 框架开发，车端通信采用基于传输层安全协议（Transport Layer Security，TLS）通道的消息队列遥测传输（Message Queuing Telemetry Transport，MQTT）协议[16]。MQTT 是一个基于客户端-服务器的消息发布/订阅传输协议，该协议轻量、简单、开放且易于实现。

车端部署MQTT Broker，用于管理近场工具与车端通信的MQTT 消息。MQTT 消息格式如图4 所示，依据主题（TOPIC）类型分为控制类（CTRL）、状态类（REPORT）、文件传输类（XFER）、控制响应（CTRL/REPLY）、状态响应（REPORT/REPLY）。其中车端管理模块订阅CTRL和XFER消息，近场工具订阅REPORT、CTRL/REPLY 和REPORT/REPLY 消息。

图4 MQTT协议格式

对于近场服务器，由车端主动访问服务器后，再由服务器主动发起升级，所以近场服务器中同时部署MQTT Broker，用于监管车辆的登录服务请求。

近场升级工具与OTA 云端通信方式统一采用RESTful API 方式。实现的接口主要有：查询ECU软件信息、查询指定车型下的ECU 列表、查询指定车型下的软件版本列表、查询指定车型整车版本列表、指定ECU软件升级包的下载[17-18]。

近场工具依据功能逻辑及多平台设计要求，分为核心功能、数据业务、功能组件及基础组件，如图5 所示。近场工具软件设计尽量模块化，以实现不同平台最大程度共用软件模块，只在界面设计及响应逻辑上区别开发。

图5 近场升级工具软件架构

4.2 整车基线同步策略

将智能汽车每个ECU的软件状态进行标记，所有ECU的软件标识组成一个基线标识，一个基线标识包含唯一一组ECU软件标识，如图6所示。通过基线标识可以很好地管理整车ECU软件，智能汽车每一次的功能升级都对应唯一的基线标识，按照基线标识更新迭代可以实现整车ECU软件版本的有序管理，防止各ECU软件版本不兼容带来的功能异常问题。

图6 整车基线管理

近场升级服务器需要对每个车型配置的所有整车基线进行管理，包括自定义基线和同步基线，自定义基线标识和同步基线标识应唯一。

自定义基线可通过手动建立，建立时选定各ECU 对应软件标识：如果当前系统中已存在该基线标识且为自定义基线则更新已存在基线；如果当前系统中已存在该基线标识且为同步基线，则新建自定义基线无效。

同步基线可通过操作人员手动执行实现。同步基线后如果当前系统中已存在该基线标识且为自定义基线，则以新同步基线为准更新自定义基线；如果存在该基线标识且为同步基线，则更新同步基线。

升级任务已绑定的基线，无论是自定义基线或同步基线，同步时均需要显示警告，由操作人员决定是否停止或更新升级任务。

5 试验验证

5.1 试验方案

针对上述方案搭建台架验证环境，原理如图7所示。车载通信终端（Telematics-BOX，T-BOX）、中央网关（Central Gateway，CGW）、车载诊断系统（On-Board Diagnostics，OBD）组成车端环境，其中OTA 车端软件集成在CGW 中。便携式计算机通过有线方式连接到OBD 上，可通过OBD 直接与CGW建立安全通道。手机连接T-BOX 热点后，可与CGW 建立安全通道。工厂服务器通过有线方式与路由器连接，路由器提供局域网WiFi，车端T-BOX可直接连接WiFi 与工厂建立安全通道，同时计算机端可以通过局域网访问工厂服务器进行近场软件升级管理。

通过上述验证环境可对近场升级客户端进行功能验证，部分测试项如表2 所示。对近场升级服务器进行功能验证，部分测试项如表3所示。

表2 近场升级客户端功能测试项

表3 近场升级服务器功能测试项

5.2 试验结果

对近场升级工具分别进行功能测试，测试结果均满足功能设计要求。

将车辆软件升级时间划分为车辆接入及任务下发时间、升级包下载时间、升级包传输时间、用户确认时间及软件升级时间，以全景影像功能为例，升级包大小408.61 MB，升级所需时间如表4 所示，近场服务器升级时间较OTA 升级时间缩短一半以上，且无需人员在车机上进行操作。

表4 OTA与近场服务器升级全景影像功能时间 s

6 结束语

针对当前智能汽车软件更新迭代快，导致售前车辆的软件版本难以统一的问题，本文设计了一种近场软件升级方法。

该方法基于现有OTA 车云系统，使用便携式计算机、手机或USB 设备进行单辆车软件快速升级，使用工厂服务器通过局域网进行批量车整车软件基线版本快速拉齐。台架试验结果表明，该升级方法所需升级时间较OTA 系统升级时间缩短一半以上，可有效提升软件升级效率。该方法的应用场景可有效补充OTA 系统升级场景，应用于智能汽车试制阶段、工厂阶段、运输阶段的软件版本快速更新。未来，可协同OTA 云平台完成车辆整车软件版本实时、同步管理，实现车辆全生命周期软件可控。