远程诊断技术在汽车OTA刷新应用的研究

前 言

汽车OTA功能已经成为时下热门话题，以Tesla为代表的造车新势力突破创新将消费电子领域“空中下载技术”成功引入到了汽车领域，掀起了全球众多OEM的追随，同时也颠覆了人们对车辆的传统认知。 OTA升级为OEM提供了比传统诊断仪更快捷、低成本的更新方式，提升用户体验及对品牌的忠诚度，而这些收益的背后自然是少不了主机厂远程诊断技术的支撑。 本文将介绍一种汽车OTA刷新中远程诊断设计方案，主要包含OTA云端整体架构及诊断要求、车载终端网络诊断架构设计、软件存储及刷新策略、远程故障诊断等内容。

01 汽车OTA简介

OTA（Over-the-Air Technology）为“空中下载技术”，与我们常见的手机更新系统固件（软件）的情况类似，汽车也可以同样通过无线网络实现远程更新车内的各控制器内部固件（FOTA）及软件数据（SOTA），这就是所谓的汽车OTA技术。

主机厂积极构建的汽车OTA升级体系，到底能带来什么好处呢？

OTA可以快速升级修复软件代码缺陷。 随着市场车辆功能配置的快速迭代，主机厂整车开发周期被迫缩短，由于软件漏洞造成的汽车召回风险持续攀升，目前高端汽车的整车代码量已经突破1亿行，即使按照能力成熟度集成模型的5级最高软件标准开发，仍有0.32%的代码缺陷率，使用OTA升级可减少主机厂50%的汽车返修成本。

OTA给主机厂带来新的“营销模式”。 “软件定义”汽车（SDV）概念的出现，给传统的汽车售卖硬件的方式带来的巨大的变革，已经卖出去的车辆还可以软件付费方式开通一些“升级包”，如Tesla的完全自动驾驶（FSD）升级包。 统计数据显示，预计未来五年软件定制市场的年均复合增长率约为30%，2023年全球汽车软件定制市场规模有望达到275.42亿元，因此主机厂可OTA升级的软件潜力及效益可观。 如图1所示：

图1 全球汽车软件定制市场规模及增速

主机厂通过OTA方式，可改善车辆的动力、刹车、续航、人机交互系统以及智能辅助驾驶系统的更优体验。 使车辆的整体性能及功能变得更优异，增加了车主的新鲜感，也增加了车主对车辆的品牌忠诚度。 汽车OTA带来众多好处的同时也对主机厂提出了新的挑战，无论是OTA云端架构设计、信息安全、后台软件版本管控等，还是车辆终端的车载网络诊断架构设计、远程故障诊断、OTA刷新流程、ECU软件刷新策略等方面，都需要OEM全面考虑和充分测试验证，避免OTA推送后车辆出现“瘫趴”现象，导致车主适得其反的体验。

02 汽车远程诊断

汽车远程诊断是指在车辆不需要开回4S店的情况下，依靠车辆具备的移动通讯能力（WIFI/4G/5G）完成主机厂后台（或手机端APP）对车辆进行远程控制及诊断操作的一种诊断技术。 远程OTA刷新就属于远程诊断应用的一种场景。 此外，远程诊断技术通过与物联网、大数据、云计算等前沿技术融合后，还可为主机厂在研发试验、产线电检、售后诊断等领域提供重要支撑。

首先，远程诊断可以在线采集数据，降低开发周期及成本。 研发阶段车辆需要进行大量道路试验、耐久试验，而试验车配备的数据采集设备有限，通过远程诊断，试验过程中出现的车辆故障现象可以及时反馈给研发人员分析和仿真，快速协助解决故障问题。 其次，远程诊断可以在产线电检跨工位实现初始化及功能检测、产线OTA刷新，实现汽车软件定制化生产，满足车主定制化需求。 最后，远程诊断可以周期性监控车辆状态，实时诊断车辆健康，结合大数据统计分析进行车辆故障预警，通过后台推送给厂家售后4S店进行车辆保养及维修指导建议。

03 OTA刷新远程诊断设计

OTA刷新系统架构主要由服务器（云平台）、传输媒介（3G/4G/WIFI/5G）和车载终端（ECU）三部分构成。 本文基于如图2所示的OTA刷新系统架构设计，重点针对服务器（云平台）和车载终端（ECU）进行远程诊断详细方案介绍。

3.1 OTA服务器 

图2 OTA刷新系统架构

OTA服务器又称为OTA云平台，在软件刷新过程中起连接用户（车厂、车主）与车辆的作用，为实现车辆远程智能诊断及故障预测分析，OTA云平台设计一般要求都部署在车厂的私有服务器上，能够支持多种车型OTA升级。

3.1.1 OTA云平台整体架构

OTA云平台主要包含用户管理、固件管理、车辆管理、升级任务管理、统计分析管理、用户操作日志管理模块，如图3所示。

图3 OTA云平台整体架构

用户管理模块：OTA云平台为车厂提供的是一套软件系统，因此需要有用户管理模块来实现用户权限分配及管理工作。 系统搭建环境默认创建超级管理员用户，由超级管理员用户登录后在用户管理模块实现用户新增，用户查看，用户信息修改等功能操作。

固件管理模块：主要为用户提供固件上传，固件查询及编辑（版本管理）功能。 用户将车厂测试通过的固件上传到OTA云平台，用以升级任务创建。

车辆管理模块：主要包含车辆ECU信息同步、车辆ECU信息获取及车辆信息查看功能。 车辆ECU信息同步子模块对接主机厂MES（生产制造）系统，可导入不同车型配置信息用以OTA升级时对目标车辆筛选及升级策略配置。

升级任务管理模块：主要负责为用户提供升级任务创建、升级任务审批、升级任务查询、升级进度查询功能。

统计分析管理模块：主要负责统计分析已发布的升级任务执行结果情况。 用户可以查看每个升级任务对应的升级车辆的成功率、失败原因统计及未执行升级原因统计分析。

用户操作日志管理模块：主要负责为超级管理员用户提供所有登录OTA云平台的用户的所有功能操作记录。

3.1.2 OTA云平台诊断要求

OTA云平台必须符合高可用、高性能、可扩展、可监控的诊断要求。 具体表现为以下几个方面：

采用微服务的Browser/Server（浏览器/服务器）的服务框架，能够支持多种负载均衡模式（服务消费者从提供者列表中，基于软负载均衡算法（随机、权重、轮询、最少并发优先等）选一台服务提供者进行远程调用，如果调用失败，需自动诊断并切换另一台服务提供者）；

立体化监控，能够对系统资源（CPU、负载、内存、网络和磁盘等）基础指标进行详细的监控，对于系统的每一次服务调用响应时间和出错率进行故障诊断和预警；

系统具备高可靠和高性能，确保整个系统上运行的业务体系能够为客户系统提供99.9%可用性的高效优质服务；

采用服务集群的管理技术，利用多个计算机并行计算从而获得高性能和冗余备份，即便单机故障时整个系统仍能正常工作；

系统具备故障隔离机制，在应用软件系统发生故障时，通过故障隔离可将故障危害限制在最小范围内，提高系统对外服务的整体能力。

3.2 OTA车载终端

OTA车载终端作为OTA升级的执行方，以OTA推送方式为例，用户可感知体验的部分较多，车载终端的设计重点需考虑人机交互、网络诊断架构设计、ECU刷新时长、软件存储及刷新策略、远程故障诊断机制。车载终端网络框架如图4所示，OTA主控节点由TBOX和中央网关（GW）负责，升级界面由车机负责，被刷新的ECU要求支持车载以太网（DoIP）或CAN总线（DoCAN）通讯协议，若ECU升级包较大（如上百兆）需要支持数据差分算法。

图4 OTA车载终端框架

3.2.1 OTA人机交互设计

OTA升级时除了云平台推送升级任务到车主APP提醒外，还需车端（车机或中控）配合开发显示一些升级界面（如升级进度、升级条件提醒等），用于提醒车主车辆设防及离车等配合操作。

3.2.2 网络诊断架构设计

目前车载网络主干网仍以成熟的CAN总线通讯为主，但对于软件包较大的ECU由于刷新时长等因素，使用了车载以太网技术来突破CAN总线的带宽限制，如图10所示。

主要架构包含OTA主控节点（TBOX和GW）和被刷新ECU。TBOX主要负责对外与云平台的连接通道安全可靠，其内部集成了PKI认证及身份鉴权等安全模块；GW主要负责对内部网络的连接通道及集成诊断刷新机功能。刷新ECU根据软件包大小及理论刷新时长（如不超过20分钟），在CAN总线拓扑架构上增加了以太网接口设计，使用DoIP协议进行ECU诊断刷新。

图5 网络诊断架构图

3.2.3 ECU软件存储及刷新策略

OTA刷新前ECU软件升级包由云平台下发到车端OTA主控节点内存储，由文件存储模块来负责整车软件升级包的存储及备份包的管控。

升级管理模块主要负责刷新机刷新策略控制，OTA刷新需要设计多次冗余刷新策略，即OTA后台发起一次升级任务后，同一辆车内OTA主控节点刷新机通常会对同一个ECU执行多次刷新尝试请求，减少偶发失败因素，提高OTA刷新成功率。被刷新ECU主要分为传统嵌入式芯片ECU和复杂带操作系统（如Linux、Android、AutoSAR）的ECU。

根据ECU的硬件资源情况，我们又设计了如下ECU内部存储及刷新策略：如图11所示的带操作系统ECU，硬件存储资源丰富，控制器内分配了两个不同启动区分，具体刷新过程如下：

默认出厂状态启动分区1激活，运行V1.0版本程序，启动分区2内无备份程序；

当OTA发起第一次V1.1版本刷新请求时，刷新数据会存储在备份分区（分区2），刷新成功后激活启动分区2，并交换备份分区（分区1），下次上电后程序由启动分区2启动并正常工作；

当OTA发起第二次V1.2版本刷新请求时，刷新数据会被存储在备份分区1，刷新成功后激活启动分区1并交换备份分区（分区2），下次上电后程序由启动分区1启动并正常工作；

当OTA发起第三次V1.3版本刷新请求时，刷新数据会存储在备份分区（分区2），刷新成功后激活启动分区2，并交换备份分区（分区1），下次上电后程序由启动分区2启动并正常工作。如此循环交换分区刷新，即便遇到刷新失败当前启动分区无法正常启动时，ECU也还可以通过自回滚从备份分区启动，确保系统工作正常。

图6 带操作系统的ECU软件存储及刷新策略图

对于传统嵌入式ECU，通常采用BOOT+APP的软件架构，如图12所示。功能越复杂的ECU，其选择的主控芯片APP容量越大，为了实现ECU内部软件自回滚功能，需要将APP空间划分一部分用于软件备份存储（如APP2）。当ECU被刷新时，由BOOT代码负责提供升级流程引导，将升级包存储到APP区域（一般为程序启动入口地址空间）。由于嵌入式芯片ECU程序启动入口通常只有一个，因此，当刷新失败（APP激活不了）时，由BOOT引导程序指引复制APP2的备份程序到APP区域进行回滚操作并启动，确保ECU工作正常。对于APP容量较小不支持APP2空间划分的ECU，只能依靠OTA主控节点实现升级包的备份存储。

图7 嵌入式ECU软件存储及刷新策略图

3.2.4 OTA远程故障诊断设计

OTA刷新目前主要是通过诊断通讯方式实现的ECU刷新条件检查、刷新过程数据传输及刷新后复位重启等操作，刷新过程中被刷新ECU由于进BOOT或其它原因无法保证应用程序正常运行（无感刷新方式除外）时，需要提前进行ECU故障屏蔽设计以免刷新过程造成整车出现一些故障码，误导后续远程故障诊断及统计分析。OTA刷新过程中，诊断故障屏蔽可采用UDS诊断协议中的0x85（Control DTC Setting）服务来实现。OTA远程故障诊断，还要解决的一个难点是与本地故障诊断的冲突问题。OTA云平台难以识别本地诊断设备，因此，必须要在车端集成远程诊断与本地诊断的仲裁判断逻辑。由中央网关（GW）负责仲裁协调，当OTA刷新过程中，网关屏蔽本地故障诊断路由转发功能；同理，当有本地诊断设备时，网关屏蔽远程故障诊断路由转发功能，屏蔽只在当前点火循环有效。

04 结 论

汽车OTA刷新为远程诊断技术带来了迫切的需求和绝佳的发展机遇，主机厂积极部署的OTA升级体系和远程诊断平台，不仅是为了当下车辆的软件漏洞修复和功能快速更新，更是为了适应“软件定义”汽车（SDV）的趋势及更高阶的自动驾驶的技术发展，而主机厂远程诊断平台积累的数据，正是考验其大数据挖掘与智能诊断应用相结合的综合能力。身为“领头羊”的特斯拉，通过远程诊断技术已经实现90%情况下的车辆部件故障诊断，每年可为车主节省一天维修工时。国内车企要奋起直追，为车主提供更便捷、满意的服务体验，仍需较长的发展历程。

审核编辑：汤梓红