汽车在线升级系统（OTA）开发浅析

本文由姜楠，姜姗姗，韩小鹏联合创作

摘要

介绍了汽车在线升级系统（OTA）的应用场景及功能，阐明了升级系统中车端及云端模块开发策略及架构；同时明确了与整车其他 ECU 的交互需求；最后介绍了在线升级系统测试相关内容。汽车在线升级逐步成为整车标准配置，本文通过这几部分的介绍，明确了在线升级系统开发框架，对后续产品开发具有指导意义。

1 引言

汽车联网能力日渐普及，以“互联网云服务”为中心的内容及服务系统逐步建立，为每位客户建立个人账户系统，提供语音交互，在线导航、新闻资讯、在线音乐电台等典型互联网特色的内容；同时，企业为完善自身的信息化建设和软件管理能力，搭建OTA 及信息安全管理平台势在必行。按照智能网联要求，重新规划构造汽车端的架构及总线体系，自主构建统一的 OTA 更新体系，同时为智能网联核心功能的发展和迭代打下坚实的基础。另一方面，推出支撑驾驶辅助及低级别自动驾驶的智能网联汽车，通过已经建立好的 OTA 体系，不断优化辅助驾驶的算法和能力，逐步向高级别推进，车联网后台也可通过 OTA 渠道收集并处理更多与辅助驾驶相关的大数据，为后续开发提供依据。

2 OTA应用场景

OTA(Over-the-Air)空中升级技术，主要包括：

FOTA，固件软件(Firmware)远程升级，比如可以通过对整车某零件 ECU 刷写新版调校参数，从而改善某些驾驶性能。

SOTA，应用软件(Software)远程升级、软件可售，像中控大屏、数字仪表和HUD 带有操作系统，可独立升级操作系统之上的应用软件。

2.1 OTA功能介绍

OTA 功能在整车开发中的优势日渐突出，可极大降低售后成本，同时为客户省去了维修、保养的时间，具体优点如下：

对软件缺陷进行修复及安全漏洞修复：更便捷的控制器软件修复，降低召回成本，低成本的故障解决和问题修复，问题漏洞及时关闭。

新功能导入和迭代：功能服务的导入和迭代，提升人机交互和服务升级，用户体验持续提升，产品性能优化；车辆功能及主题等不定期优化，使用户体验到常用常新的新鲜感。

软件可售及升级运营：汽车软件、功能、主题皮肤等可售安装、升级、软件服务制定、节日彩蛋等。

长周期的功能开发：可提前规划产品开发型谱，如更高级的驾驶场景，待技术成熟后推送给客户，以达到功能增值的目的。

2.2 OTA应用场景介绍

整车电子架构围绕中央智能网关分为 4 个域段：分别为车身舒适域、智能驾驶与智能泊车域、动力域、信息娱乐域，不同域段对 OTA 的应用场景不尽相同，详见表 1：

3 软件模块

3.1 车端集成软件模块

为实现 OTA 功能，车端需要集成以下软件功能：

DM：Download Management， 主要功能为车云业务交互及下载。

UC：Update Controller， 常 分 为 UC Mastr 和 UC Slave，主要功能为升级任务检测、车辆信息收集、人机交互、升级包验签、升级包分发、升级执行、进度日志；车辆信息收集，实现自身升级和下级ECU 的升级管理。 UA：Update Agent， 主要功能为目标

设备升级能力程序，差分还原、升级流程、异常处理、AB 分区、Recover 分区。

DPC： Diagnostic programming Controller，主要功能为诊断刷写，通过实现 ECU 信息采集进行 ECU 刷新。

其中，图 1 为车端集成软件架构。

3.2 云端集成软件模块

云端集成软件模块功能方案如下：车辆管理：单车升级状态查询。

项目管理：项目的增删改，项目信息统计。

版本管理：项目把版本对应关系，差分关系建立。

策略配置：配置下载条件、配置升级条件、配置升级策略。

升级包测试：设定测试范围、测试升级过程、测试审核结果。

任务发布：项目策略正式生效，向车辆推送任务。

数据统计：项目升级数据分析。

可视化管理：全局情况掌握，可视化展示。用户管理：用户角色分配，用户权限管理。对接服务：与各种系统对接服务。

3.3 控制器的OTA模式要求

当车辆处于 OTA 过程中时，基于安全因素和 OTA 的需求考虑，需定义部分控制器在OTA 模式下的特殊需求，车辆部分功能受到限制或不可用。

发动机怠速发电保持：怠速情况下对其他控制器 OTA 升级时发动机不可熄火。

AT 车型 P/N 档保持及驻车制动保持：TCU 保持P/N 档，EPB 保持出车制动，同时TCU 和EPB 在诊断规范体现具体的诊断功能要求。

换挡请求禁止：BDC 换挡功能禁止，换挡器换挡请求禁止，需在 BDC 及 ERTS 中定义 OTA 模式需求。

特殊显示相关内容：车机、仪表定义 OTA 模式要求，仪表及空调屏幕可不显示 OTA 相关信息。

设防状态保持：BDC 定义 OTA 模式要求， 在设防状态下进入 OTA 模式，需保持设防状态。

禁止大功率用电器，空调、座椅模块、DBC、车机定义 OTA 模式需求，空调鼓风机禁止、座椅通风加热禁止、后视镜加热禁止、车机音响禁止。

灯光特殊要求：氛围灯、背光、昼行灯需根据特殊设置要求进行设置。

防止 OBD 接口干扰：网关定义 OTA 模式，OTA 过程中禁止 OBD 诊断。

3.4 整车中不同ECU的要求

针对不同类型 ECU，需根据其功能和通讯形式定义技术要求。

CGW：采集域内 CAN（FD）总线数据以及以太网报文，需包含网段标识、报文时间等信息，以规定周期，打包成以太网报文上传至 TBOX。

TBOX：使用本地 RAM 缓存接收到的以太网报文，解析数据，在规定周期内压缩并上传至云端，针对触发事件，TBOX 接受触发事件标识位，上传至 EPPOM 命名的文件。TBOX 实现车内诊断仪功能，在满足特定车辆工况下，读取 ECU 本地记录特定事件数据， TBOX 使用专用存储空间进行数据存储，循环覆盖；若由于网络信号差等原因造成上传云端失败，断网数据存储在 EMMC 中，待网络信号转好后，补充上传未成功的数据。针对其他ECU，需有信号标识位，在功能异常或异常事件或任何故障发生时信号置位，TBOX 通过判断此信号置位与否，决定是否上传 ERROR 文件。

4 OTA测试

4.1 OTA测试方案

OTA 测试方案完整框架如图 2 所示：

4.2  OTA功能测试用例

OTA 功能测试包含云端功能测试、车端流程测试、车云接口测试、车云策略测试、车云管理测试五方面内容。

云端功能测试包含首页功能、零件管理、汽车管理、策略管理、任务管理、统计分析、日志管理、企业管理、系统管理、安全管理、登陆管理、用户信息管理。

车端流程测试包含车辆注册流程、升级检测流程、升级下载流程、升级安装流程、结果上报流程、HMI 测试、整车交互流程。

云车接口测试包含车云注册接口、获取服务器配置、上报汽车端信息、检测版本接口、升级结果上报接口、日志上传接口、事件上报接口、统计分析接口、根证书下发。

车云策略测试包含总体策略、测试通过标准制定、微服务基准压测策略、场景压测测试策略、数据正确性验证。

车云管理测试包含通讯安全、认证测试、信息泄露测、会话管理、文件管理、接口重放攻击、XSS 攻击、跨站点请求伪造、权限管理测试、安全日志测试等。

5 结语

众所周知，针对高级别自动驾驶的实现，必须通过硬件冗余及软件 OTA 迭代的方式，具有强大的硬件性能和软件 OTA 能力的车辆才能成为真正意义上的智能终端，车联网也将成为将大数据监控、分析、更新能力、用户服务管理能力融为一体的“下一代车联网”。因此，OTA 的发展必将成为推动汽车发展的一大助力。