本文由姜楠，姜姗姗，韩小鹏联合创作
摘要
介绍了汽车在线升级系统（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 云端集成软件模块
云端集成软件模块功能方案如下：车辆管理：单车升级状态查询。
项目管理：项目的增删改，项目信息统计。
图1 车端集成软件架构
版本管理：项目把版本对应关系，差分关系建立。
策略配置：配置下载条件、配置升级条件、配置升级策略。
升级包测试：设定测试范围、测试升级过程、测试审核结果。
任务发布：项目策略正式生效，向车辆推送任务。
数据统计：项目升级数据分析。
可视化管理：全局情况掌握，可视化展示。用户管理：用户角色分配，用户权限管理。对接服务：与各种系统对接服务。
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 所示：
图2 OTA测试方案完整框架
4.2 OTA功能测试用例
OTA 功能测试包含云端功能测试、车端流程测试、车云接口测试、车云策略测试、车云管理测试五方面内容。
云端功能测试包含首页功能、零件管理、汽车管理、策略管理、任务管理、统计分析、日志管理、企业管理、系统管理、安全管理、登陆管理、用户信息管理。
车端流程测试包含车辆注册流程、升级检测流程、升级下载流程、升级安装流程、结果上报流程、HMI 测试、整车交互流程。
云车接口测试包含车云注册接口、获取服务器配置、上报汽车端信息、检测版本接口、升级结果上报接口、日志上传接口、事件上报接口、统计分析接口、根证书下发。
车云策略测试包含总体策略、测试通过标准制定、微服务基准压测策略、场景压测测试策略、数据正确性验证。
车云管理测试包含通讯安全、认证测试、信息泄露测、会话管理、文件管理、接口重放攻击、XSS 攻击、跨站点请求伪造、权限管理测试、安全日志测试等。
5 结语
众所周知，针对高级别自动驾驶的实现， 必须通过硬件冗余及软件 OTA 迭代的方式， 具有强大的硬件性能和软件 OTA 能力的车辆才能成为真正意义上的智能终端，车联网也将成为将大数据监控、分析、更新能力、用户服务管理能力融为一体的“下一代车联网”。因此，OTA 的发展必将成为推动汽车发展的一大助力。