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

一种电动汽车软件OTA升级服务平台设计方案 　　摘要：目前电动汽车中的电子部件占总部件比例越来越高，电子部件在汽车运行中起到了核心作用。电动汽车根据国家标准要求必须接入国家系统平台，形成一个车联网的大环境。在保证车辆行驶安全的前提下，利用车联网运营平台可对电动汽车的电子部件进行无缝远程升级是物联网功能应用的又一次延伸。本文提出了针对电动汽车电子部件软件远程升级的一种独立服务器平台系统设计方案，能够很好地解决大规模车载设备和高安全性的升级需求 关键词：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升级文件传输