一种电动汽车软件OTA升级服务平台的设计方案

一种电动汽车软件OTA升级服务平台的设计方案
作者：高洁汪庆
来源：《电脑知识与技术》2017年第08期
摘要：目前电动汽车中的电子部件占总部件比例越来越高，电子部件在汽车运行中起到了核心作用。

电动汽车根据国家标准要求必须接入国家系统平台，形成一个车联网的大环境。

在保证车辆行驶安全的前提下，利用车联网运营平台可对电动汽车的电子部件进行无缝远程升级是物联网功能应用的又一次延伸。

本文提出了针对电动汽车电子部件软件远程升级的一种独立服务器平台系统设计方案，能够很好地解决大规模车载设备和高安全性的升级需求。

关键词：OTA；电动汽车；软件升级；远程升级
中图分类号：TP393 文献标识码：A 文章编号：1009-3044（2017）08-0209-03
由于电动汽车中的电子部件占总部件比例越来越高，其在汽车运行中已经起到了核心作用。

然而在软件编写过程中由于设计人员考虑不周全，测试不完备，导致电子部件的软件在运行过程中会出现异常情况，埋下了安全隐患。

当下电动汽车在国家的要求下均已联入车联网平台，充分利用车联网平台，及时进行远程修复车辆软件的功能性错误，避免大规模召回，提高车辆安全等级，减少车辆运营成本是整车厂的迫切要求。

本文提出了一种针对于电动汽车软件OTA升级设计方案，利用原有的车联网平台的数据交互通道，既避免了在原有车联网业务平台上增加升级模块所导致的软件系统规模过大、设计过于复杂的问题，同时也可以对升级过程进行单独的安全性设计，进一步增强了电动汽车软件升级过程的安全性保证。

1传统的升级流程分析
1.1在业务服务系统的基础上开发，系统复杂，升级过程模块影响到业务服务器的运行
业务服务系统就是为车辆正常运行时提供数据服务的系统。

其包括运行时车辆实时状态数据的存储、查询、诊断命令的下发功能。

在车辆接入较少，业务服务系统的功能相对简单的情况下，一般采取将升级过程作为模块融合到业务服务系统设计中。

这样的好处是可以快速开发，尽早完成功能交付给用户。

但随着车辆接人较多，业务扩展速度较快，并且升级交互流程复杂的情况下，与业务服务系统整合开发，会导致整个系统越来越复杂，出现较多系统故障，系统越来越不稳定，影响到了原有的业务服务系统的运行。

1.2在业务服务器的级别上验证升级终端的合法性，无法达到升级要求的安全性，存在一定的安全风险
业务服务系统主要为车辆提供各种特色的信息化服务。

在大规模车辆的接人的情况下，为了满足一定的并发服务效率，每种信息化服务对安全要求不一致。

而车辆ECU固件软件升级是车辆生命周期中最为重要的行为，交互过程复杂，并且在安全性要求方面远远高于其他信息化服务。

因此以模块开发的形式来设计升级流程，难以达到整车厂对升级过程的安全性要求。

综上，随着业务快速发展以及对升级过程较高的安全性要求来看，将升级系统独立出来，采用针对性的设计是升级功能发展的必然趋势。

2升级系统设计基准
1）与业务系统独立设计，采取服务调用的方式进行信息交互，避免影响业务服务器的运行效率；
2）升级过程中应包含多种验证流程，保证电子部件固件OTA升级的安全性；
3）结合原有业务系统的车辆运行状态，禁止在诸如行驶过程中对重要部件的升级，保证车辆的使用安全。

如图1，车辆电子部件升级中，车载终端作为车辆的网络连接设备，起到了与互联网的接口作用。

具体负责将车辆与远端服务器之间的交互职责。

所以在本文涉及的系统服务器与车辆交互的，其实就是系统平台与车载终端交互。

3升级过程的阶段设计
系统将整个升级过程分为四个阶段，为了保证升级过程的完整跟踪，在这四个阶段之间的转换时均将其涉及的状态信息存储到服务器中，用于操作人员后期检索。

3.1升级方案配置阶段
业务服务系统接人的车型较多，不同车型的电子部件硬件和软件均不相同，如何在升级之前将符合升级标准的车辆选人，避免待升级的车辆认为选择错误，是升级方案配置阶段解决的主要问题。

一方面，升级操作页面采用流程式操作设计，保证升级操作人员操作过程的唯一性。

另一方面，扩展升级文件的限制性属性，在升级文件打包时就将其符合的车型以及电子部件软硬件信息一并写入，这些信息作为筛选升级车辆的一个重要指标，避免升级车辆选择的随意性过大，导致车辆升级后无法继续行驶。

因此，前期的升级方案的创建在整个升级过程中是尤为重要。

3.2升级命令下发阶段
升级命令下发阶段是根据升级方案信息自动完成，正常情况下用户无需操作。

这个阶段主要解决两个方面的问题。

第一个方面问题就是待升级车辆运行状态的检验；第二个方面就是升
级命令的自动下发。

由于车辆连接的是业务服务器，业务服务器会根据车辆运行的状态做粗略的筛选，如果符合升级要求则将升级指令发送到车载终端上。

在升级命令下发成功后，车辆脱离业务服务器转向升级服务器，开始后续的升级过程。

3.3升级文件传输过程阶段
升级文件传输过程是排他的。

在升级文件传输过程中，车辆的业务数据是无法上传的。

车辆从业务服务器切换到升级服务器后，在升级服务系统中需要进一步对车载设备型号、车辆型号以及电子部件版本号和车辆状态情况进行校验和检查。

确定合法后，开始文件传输过程，整个升级文件下发过程采用可靠的加密，在每一块数据成功下载到车载终端上，车载终端需要解密和校验，保证数据的完整性和正确性。

3.4升级文件刷写以及结果汇报阶段
在升级文件完整的下载到车载终端后，车载终端再根据当前的车辆情况以及待升级固件的电子部件信息，在保证完全安全的情况下，对电子部件进行软件刷写升级。

开始和结束刷写过程，车载终端都将状态发送到升级服务器上，用作升级系统判断是否继续升级和成功完成的依据。

4升级系统软件体系设计
从功能的角度考虑，升级系统必须具备车载终端接人功能、车载终端检验功能、升级请求响应功能，升级程序文件下发功能以及外部系统交互等诸多功能。

采取分层设计，每个层次各司其职，相互没有复杂的交互，便于后期系统的维护。

整个系统如下图2分为四层软件结构：
1）车载终端网络接入层：具有车辆数据的接收和发送网络功能，还包含如链接管理，校验和拆包的底层数据处理功能；
2）数据传输层：一方面，将接人层收到的二进制数据进行解析，发到应用层处理；另一方面，将应用层需要发到车载终端的数据进行序列化操作后转发到接入层；
3）应用层：是对升级过程的业务进行处理，包含升级流程处理、Session管理和本地存储逻辑；
4）接口层：包含业务服务器的访问以及界面要求的各种访问接口等。

5系统交互流程设计
根据上述升级的四个阶段，识别出升级过程中的四个干系子系统，子系统以过程调用、消息队列的方式进行交互。

其中，升级方案创建阶段，主要是操作员和业务服务系统的交互；下
发升级命令阶段，主要是业务服务器与车载终端之间的交互；升级文件传输主要是升级服务系统与车载终端之间的交互；最后一个阶段则是车载终端与所有系统之间的交互。

整个系统采用服务的方式进行设计，每个组件均向外暴露必要的服务接口，供其他组件调用。

并且更为重要的，每个组件均是无状态组件，可随意部署多个，满足大规模车辆升级的并发需求。

组件交互如下图3：
6总结
本文通过根据电动汽车电子部件软件升级的特殊要求，分析出传统业务系统的升级模块无法满足对目前大规模车辆软件升级和高安全性的要求，提出了一个升级系统独立设计方案。

在系统设计上，采取增加升级文件属性匹配和分阶段设计的方法，解决了因操作失误导致的升级失败以及升级全过程无法追溯的问题。

在系统实现上，采取服务化和无状态模块实现的方法，解决了大规模并发和安全性隔离的问题，满足了整车厂对车辆部件软件升级规模性和安全性的需求。