智能网联汽车整车OTA功能设计研究

智能网联汽车整车OTA功能设计研究
王栋梁;汤利顺;陈博;柳旭;刘闯
【摘要】为满足智能网联汽车快速迭代的需求,提出一种安全、方便、可靠的整车OTA解决方案.通过建立云服务器端和车辆客户端之间的数据通路,使用差分算法、安全方案、回滚重刷机制、车辆条件判断等关键技术,实现了整车
Ethernet/CAN/LIN混合电子电气架构的所有节点ECU的升级更新,经台架试验测试验证了该设计方案的可行性、安全性和可靠性.
【期刊名称】《汽车技术》
【年(卷),期】2018(000)010
【总页数】5页(P29-33)
【关键词】智能网联汽车;整车OTA;差分算法;回滚重刷机制
【作者】王栋梁;汤利顺;陈博;柳旭;刘闯
【作者单位】中国第一汽车集团有限公司智能网联开发院,长春 130011;中国第一汽车集团有限公司智能网联开发院,长春 130011;中国第一汽车集团有限公司智能网联开发院,长春 130011;中国第一汽车集团有限公司智能网联开发院,长春130011;中国第一汽车集团有限公司智能网联开发院,长春 130011
【正文语种】中文
【中图分类】U461
1 前言
随着汽车智能化、网联化水平的不断提升，汽车内部电子控制单元的数量和复杂度不断增加。

据统计，目前高级轿车上电子电气元件的成本已经占到整车开发成本的60%～70%，若要对电控单元软件进行开发调试、数据标定、文件更新、故障修复就需要远程应用程序更新（Over the Air Technology，OTA）技术。

2014年特斯拉首次面向中国推出V5.9版车载系统，目前已经更新到V8.1版本，实现了对驾驶辅助系统、自动泊车功能、空气悬架系统、导航和地图、影音娱乐系统等内容的更新[1-2]。

整车OTA技术在车辆量产后可降低车辆的召回成本，实现对车辆软件和车辆数据的统一管理，提高售后服务的效率和质量；为用户提供车载娱乐系统的增值服务，有效提升用户体验和用户黏贴度；通过车辆软件的快速更新迭代，特别是优化和加强驾驶辅助功能，实现整车系统的不断升级，让用户获得更优质的行车体验。

本文提出一种基于整车Ethernet/CAN/LIN混合电子电气架构，建立云服务器端-车辆客户端之间安全、稳定、可靠连接通路的控制器软件升级方案，以实现整车上信息娱乐系统、动力传动系统、车身舒适系统等所有控制器不同类型节点的在线更新。

2 OTA系统架构
整车OTA系统包括云服务器端和车辆客户端[3]，它们之间通过4G或Wifi进行数据通信。

云服务器端和车辆客户端采用一对多的方式，云服务器端为部署在数据中心的私有云服务平台，仅借助于公有云的CDN（内容分发技术）来实现位于不同区域的不同车辆同时更新，图1为OTA系统架构。

2.1 云服务器端
2.1.1 硬件系统
云服务器端集群是建设在数据中心防火墙内的私有云平台，由1台负载均衡服务器、6台Swarm服务器、12台Worker服务器、1台带主备功能的数据库服务器和CDN分发服务器组成。

负载均衡服务器负责大规模升级任务的分发，提高任务
处理效率；18台业务处理服务器对各升级任务进行具体处理并直接进行云端和车
端的信息交互；数据库服务器存储所有升级文件以及车辆软件信息，实时存储车辆升级状态；CDN服务器利用公有云辐射全国的资源，实现全国各地车辆的任务升级。

云端服务器架构如图2所示。

图1 OTA系统架构
图2 云端服务器架构
2.1.2 软件系统
云服务器端部署有一套完整的信息存储系统用来存储所有量产车辆的信息，包括车型、车系、车辆配置、VIN码、车辆EOL日期、T-Box序列号等。

在这些信息的
基础上，增加对车辆控制器更新状态的描述，这样实现对每辆车更新历史足迹的记录，根据每辆车的更新状态还可以对每次升级任务的过程和成功率进行统计。

OTA云端系统具备文件管理和升级任务部署的功能。

文件管理系统实现了不同车
型车系的车辆上所有控制器软件的版本管理。

控制器软件在OTA系统中需进行功能验证、签名、加密等操作，然后与信息存储系统中量产车辆的信息实现唯一对应，保证升级软件精准的下发。

升级任务部署系统主要是对需升级的软件进行配置，选择需升级的车辆，设置升级任务的时间，升级任务的策略等。

任务部署完成后，利用饼图和直方图来实时记录和显示任务进行的过程和任务完成的百分比，每次任务结束后还会自动生成任务报告，对此次任务进行分析并对升级中的问题进行解决。

2.2 车辆客户端
车辆客户端架构如图3所示，采用目前主流的多种总线Ethernet/CAN/LIN融合
并存、网关路由通信中枢的方式，不同总线完成不同的场景应用。

在实际应用中，网关和车载通信单元集成在一起，作为一个中央网关控制单元。

升级所必须的模块主要包括远程通信模块、文件下载模块、差分还原模块和更新策略模块。

a.远程通信模块。

该模块实现与云服务器端的通信，完成升级任务数据和差分文件
的下载，支持蜂窝通信、WLAN通信及断点续传功能。

b.文件下载模块。

该模块在云端和云端安全认证的基础上，根据文件下载链接，接收软件并解密和验证其完整性。

c.差分还原模块。

该模块依据远程接收的差分文件和目前车内的旧版软件，以及云端所使用的差分算法完成新版软件的还原。

d.更新策略模块。

该模块完成下载过程中车辆状态的判断与核查，只有在所有的限制条件均不满足时，才可以启动升级流程。

车辆客户端通信协议架构如图3所示，上层标准协议接口层采用UDS诊断协议，协议包含数据上传和下载的标准服务，不需要开发专用数据交互协议[3]；下层依据协议的不同采用不同的国际标准。

图3 车辆客户端通信协议
2.3 OTA升级流程
整个OTA升级过程如图4所示。

图4 OTA升级流程
a.文件上传和部署。

升级软件先线下进行刷写测试，刷写成功后上传到云端系统。

云端系统对升级软件进行加密，通过集成的差分算法对文件进行差分生成二进制差分文件。

在此文件基础上添加升级策略、升级标识等信息到配置文件，组成一个完整的ZIP格式压缩包，并选择升级车辆范围、升级时间，完成升级软件在云端的部署。

b.远程下载。

在升级任务有效的时间段内，每次车辆上电会与云端建立连接，云端对车辆内部所有控制器软件版本进行收集，与云端任务的控制器软件版本比较，若存在新版本，云端会将升级软件下发到车端，文件传输使用HTTPS协议保证文件的安全性。

整个下载过程支持断点续传。

c.用户通知和确认。

云端和车端建立连接之后，云端会实时监控车辆状态，确认用
户在使用车辆后，将更新信息推送到IVI的HMI（带有免责声明、安装条件、注
意事项）。

如果用户没有点击更新，下次车辆上电后会继续通知升级信息。

d.本地刷写。

升级文件下载到本地后，车辆会判断车辆条件是否满足升级要求，若满足，车辆就会对升级文件对应的控制器进行升级。

网关和IVI使用自升级方式进行升级，网关下各路ECU由网关作为诊断仪进行刷写。

3 OTA关键技术
3.1 差分算法
差分算法是指在云服务器端比较新、旧版本之间的差异生成差分delta文件，然后将该文件传输到车辆客户端，车辆客户端根据接收到的差分delta文件和旧版文件还原成新版文件[4]，如图5所示。

图5中，O代表旧版文件，N代表新版文件，
D代表差分文件。

因差分del⁃ta文件的大小远小于源文件，所以有利于无线传输，同时节省流量，提升整个传输过程的可靠性和经济性。

图5 差分算法原理
车辆控制器大部分文件程序很小，不需要使用差分算法进行更新。

差分算法主要应用在娱乐信息系统的应用程序升级和车载地图的更新。

结合娱乐信息系统的软件特点、文件格式以及车内端的更新方式，定义了3种指令来实现对新、旧版本软件
差异的描述[5]。

a.Data命令。

当新、旧版本软件数据内容完全不同时需要采用此指令，该指令说
明将有新的数据生成。

指令后面跟随的数据包括地址信息、数据长度和更新的数据内容，如Data 0x1000 0x02 0x0102表示在旧版本软件中起始地址为0x1000的后面进行数据更新，更新数据长度为2个字节，更新的数据内容为0102。

b.Copy命令。

当新、旧模块之间的数据内容相同而只是地址发生偏移时需要采用此命令，这种现象在标定变量及可变参数软件中是经常发生的。

指令后面跟随的数据包括旧版本的首地址、新版本更新地址和复制的数据长度，如Copy 0x1000
0x2000 0x02表示将旧版本软件中起始地址为0x1000、数据长度为2个字节的
数据复制到新版本软件中起始地址为0x2000、数据长度为2个字节的位置。

c.End命令。

该指令用来描述文件的结束。

图6为一个标准的差分文件的生成过程，需要完成电控单元中应用程序软件的更新。

由图6可看出，旧版本软件中包含5部分，新版本软件同样包含5部分，且
地址空间大小相同。

数据块#1和#4在新、旧版本中数据内容和存储地址没有变化，所以不需要在差分文件中描述；数据内容发生变化的数据块包括#2和#5，所以这两块在描述文件中需要使用Data命令，数据块#2数据内容没有变化，但是地址
发生了偏移，所以使用Copy命令进行描述。

生成的差分描述文件包括两个Data
命令与一个Copy命令以及一个文件结束指令。

因源文件数据长度为0x80,差分文件长度大致为0x35，所以大大缩小了传输文件尺寸。

图6 差分描述文件生成
由上述可知，差分文件的大小由Data命令、Copy命令的多少决定，假定命令的
数据长度是1字节，地址数据长度由add表示，Data后面的数据内容长度由L表示，Data和Copy命令的数量分别为c1和c2，则一个描述文件的数据长度为：
由式（1）可知，实际上新、旧版本软件中数据内容不一致的长度为L×c1,差分文
件的大小主要由Data命令的多少以及其后的数据长度L决定。

所以在生成差分文件过程中，尽量使用Copy命令寻找软件中的数据内容相同处，即使用Copy命令替换Data命令。

3.2 安全方案
整个OTA系统的安全是从云端到车端的多阶段多层级全方位的防护，即软件上传到OTA服务器、OTA服务器到车辆客户端以及车辆客户端内部都采用不同类型的加密机制来提升整个升级过程的安全等级。

对于OTA服务器首先是对登陆用户需
要进行安全访问限制和认证，其次是对上传到OTA服务器的软件需要先经过证书验证、签名验证和权限验证。

OTA安全方案如图7所示。

图7 OTA安全方案
软件包下载到车内之前，云端和车端会先根据PKI/CA认证系统进行身份互验。

验证通过后，云端和车端会建立基于TLS1.2安全协议的安全通道，该通道保证云端与车端之间信息传输的安全性[6]。

在车内部分，T-Box、IVI和网关之间的交互信息采用私有协议密文传输，软件包
的加解密通过在T-Box、IVI和网关内部集成的HSM（硬件安全模块）来管理、
处理和保存加密秘钥，防止软件包被篡改。

3.3 回滚重刷策略
在车辆升级过程中，由于出现车辆电池电压极低、CAN线不稳定的意外情况，升
级的控制器要支持回滚，使控制器软件能够回滚到上一版本或者初始版本，保证车辆正常运行。

对于带有Linux、QNX和Andriod等智能操作系统的控制器，其系统设计为A/B系统，双系统交替升级。

当A系统处于升级过程中时，B系统正常
工作，如果A系统升级成功后，控制器重启进入A系统，则下次升级时A系统正常工作，B系统进行升级；而当A系统升级失败后，控制器重启仍然进入B系统，并尝试再次对A系统进行升级更新。

带有RTOS传统实时操作系统的控制器为网
关下属CAN节点ECU，网关作为诊断仪对其进行刷写升级。

升级失败后网关会调用网关FLASH中存储的控制器软件的上一版本再次进行刷写，若再次刷写失败，且控制器程序区已被擦除，控制器功能丧失使用，则控制器内部存储的初始版本应用程序将会启动，保证控制器基本功能的使用。

3.4 车辆条件
在升级文件下载完立即进入升级的场景中，车辆升级之前会对车辆条件进行判断，升级过程中车辆需满足的条件如表1所列，网关采集表1中信号并进行判断，若
某一条件不满足，则HMI会弹出界面提示用户手动操作以满足升级条件。

在预约升级的场景中，T-Box支持定时唤醒功能，在指定的预约时间T-Box唤醒自己并判断车辆条件满足后，启动升级流程对需要升级的控制器进行升级。

对于动力系统不具备在IG OFF时被唤醒刷写升级的能力，需要T-Box唤醒BCM给整车上电，在IG ON状态下完成刷写升级。

升级过程中BCM还需禁止车内大功率用电负荷（空调、前照灯等）工作，避免蓄电池电量消耗过多。

表1 车辆条件编号备注升级条件IG ON 1 2 3 4 5 6 7 8升级条件判断项IG
ON/OFF(KL30/KL15)车速发动机转速驻车制动挡位蓄电池电压0 0 夹紧P挡＞升级所需最低电压（需标定）＞升级所需最低电量（需标定）无丢失信号来源T-Box网关网关网关网关网关蓄电池电量CAN节点网关网关云端下发最低电压值云端下发最低电量值
4 试验验证
4.1 试验方案设计
基于上述方案，在云端组建以OTA服务器集群为主体并集成安全证书平台、车辆数据信息平台、负载均衡、数据库等功能的私有云平台，以该平台的硬件为基础开发并部署云端应用程序，利用公有云CDN服务实现软件在全国范围内的高速分发下载。

在车端将下载管理、差分还原、升级管理、安全传输等组件嵌入到TBox、Gateway和IVI中实现车内所有Ethernet/CAN/LIN节点的刷写升级。

试验测试方案如图8所示。

图8 试验测试方案
4.2 实物台架
通过在试验室搭建基于试验方案的云端服务器集群和车辆控制器实物台架，并对OTA整个升级过程建立测试用例，进行正向、逆向的完整测试，部分测试用例如表2所列，测试台架如图9所示。

表2 部分测试用例编号1 2 3 4 5 6 7 8测试用例T-Box升级过程中车端HMI显示测试T-Box升级包下载时间测试T-Box升级包下载断点续传功能测试（IG ON-IG OFF-IG ON）T-Box升级包下载断点续传功能测试（信号正常-信号中断-信号恢复）T-Box本地安装时间测试T-Box本地安装过程中升级条件判断测试T-Box 本地安装过程中断电恢复测试T-Box本地安装过程中CAN通信异常测试测试目的验证升级过程中IVI的HMI显示是否符合设计要求验证下载时间是否满足设计要求验证升级包下载断点续传功能验证升级包下载断点续传功能验证本地安装时间是否满足设计要求验证安装过程中临界条件是否满足验证安装过程中抗干扰恢复能力验证安装过程中抗干扰恢复能力
图9 测试台架
4.3 试验结果
通过台架试验对整个OTA系统进行测试，包括HMI的可视化、云服务器端WEB 界面的可视化以及云服务器端对关键数据的统计，以T-Box测试为例，试验结果如表3所列。

表3 试验结果编号1 2 3 4 5 6 7 8关键数据文件包大小差分压缩率差分时间下载时间还原时间安装时间差分试验次数差分成功率T-Box 26 359 kB 98%0.526 s 2 min 35 s 8.5 s 35 s 50 100%指标26 359 kB文件系统＞90%图片＞70%＜10 s ＜5 min＜10 s＜5 min 50 100%
5 结束语
整车OTA功能是实现智能网联汽车快速更新迭代的基本条件，也是未来汽车发展中一种必然趋势。

本文提出一种安全、方便、可靠的整车OTA解决方案，并对OTA关键技术进行了分析。

通过在试验室搭建基于试验方案的云端服务器集群和车辆控制器实物台架，并对OTA整个升级过程建立测试用例，进行了正向、逆向的完整测试，通过测试验证了整个升级过程的可行性、安全性和可靠性。

参考文献
【相关文献】
[1]徐昕,贺汉根,蔡自兴,等.车辆智能驾驶技术的研究前沿与展望[C]//2009中国自动化大会暨两化融合高峰会议.2009.
[2]程伍端.客户端/服务器体系结构的应用与发展[J].电脑知识与技术,2005(12):79-80.
[3]孙健舸.基于FOTA的差分文件与压缩算法的研究[D].西安：西安电子科技大学,2013.
[4]冯志杰,何明,李彬,等.汽车信息安全攻防关键技术研究进展[J].信息安全学报,2017,2(2):1-14.
[5]Mengran Xue,Wei Wang.Security Concepts for the Dynam⁃ics of Autonomous Vehicle Networks[J].Sandip Roy-Auto⁃matica,2014,3.
[6]Zhong Sheng,Zhang Yuan.How to Select Optimal Gateway in Multi-Domain Wireless Networks:Alternative Solutions without Learning[J].IEEE Transactions on Wireless
Com⁃munications,2013,12(11).。