随着汽车智能化和网联化的发展，汽车已经不再只是个简单的交通工具，车主开始关注并期待 OEM 能否像手机更新软件那样远程维护升级自己的车辆，以获得自身更好的驾驶享受及新功能体验。同时 OEM 为了降低由于产品软件漏洞等引发的召回风险及新功能的迭代更新，利用远程诊断技术，也都积极构建汽车 OTA 升级体系， 实现整车 OTA 刷新应用。文章主要介绍了汽车 OTA 和远程诊断技术，并提出一种汽车 OTA 刷新中远程诊断设计方案，为 OTA 升级及故障诊断提供一定的指导作用。
汽车 OTA 功能已经成为时下热门话题，以 Tesla 为代表的造车新势力突破创新将消费电子领域“空中下载技术”成功引入到了汽车领域，掀起了全球众多 OEM 的追随，同时也颠覆了人们对车辆的传统认知。OTA 升级为 OEM 提供了比传统诊断仪更快捷、低成本的更新方式，提升用户体验及对品牌的忠诚度，而这些收益的背后自然是少不了主机厂远程诊断技术的支撑。本文将介绍一种汽车 OTA 刷新中远程诊断设计方案，主要包含 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 推送后车辆出现“瘫趴”现象，导致车主适得其反的体验。
汽车远程诊断是指在车辆不需要开回 4S 店的情况下， 依靠车辆具备的移动通讯能力（WIFI/4G/5G）完成主机厂后台（或手机端 APP）对车辆进行远程控制及诊断操作的一种诊断技术。
远程 OTA 刷新就属于远程诊断应用的一种场景。此外，远程诊断技术通过与物联网、大数据、云计算等前沿技术融合后，还可为主机厂在研发试验、产线电检、售后诊断等领域提供重要支撑。
首先，远程诊断可以在线采集数据，降低开发周期及成本。研发阶段车辆需要进行大量道路试验、耐久试验，而试验车配备的数据采集设备有限，通过远程诊断，试验过程中出现的车辆故障现象可以及时反馈给研发人员分析和仿真，快速协助解决故障问题。
其次，远程诊断可以在产线电检跨工位实现初始化及功能检测、产线 OTA 刷新，实现汽车软件定制化生产，满足车主定制化需求。
最后，远程诊断可以周期性监控车辆状态，实时诊断车辆健康，结合大数据统计分析进行车辆故障预警，通过后台推送给厂家售后 4S 店进行车辆保养及维修指导建议。
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 云平台必须符合高可用、高性能、可扩展、可监控的诊断要求。具体表现为以下几个方面：
（1）采用微服务的 Browser/Server(浏览器/服务器)的服务框架，能够支持多种负载均衡模式（服务消费者从提供者列表中，基于软负载均衡算法（随机、权重、轮询、最少并发优先等）选一台服务提供者进行远程调用，如果调用失败， 需自动诊断并切换另一台服务提供者）；
（2）立体化监控，能够对系统资源（CPU、负载、内存、网络和磁盘等）基础指标进行详细的监控，对于系统的每一次服务调用响应时间和出错率进行故障诊断和预警；
（3）系统具备高可靠和高性能，确保整个系统上运行的业务体系能够为客户系统提供 99.9%可用性的高效优质服务；
（4）采用服务集群的管理技术，利用多个计算机并行计算从而获得高性能和冗余备份，即便单机故障时整个系统仍能正常工作；
（5）系统具备故障隔离机制，在应用软件系统发生故障时，通过故障隔离可将故障危害限制在最小范围内，提高系统对外服务的整体能力。
3.2 OTA 车载终端
OTA 车载终端作为 OTA 升级的执行方，以 OTA 推送方式为例，用户可感知体验的部分较多，车载终端的设计重点需考虑人机交互、网络诊断架构设计、ECU 刷新时长、软件存储及刷新策略、远程故障诊断机制。
车载终端网络框架如图 4 所示，OTA 主控节点由 TBOX 和中央网关（GW）负责，升级界面由车机负责，被刷新的ECU 要求支持车载以太网（DoIP）或 CAN 总线（DoCAN） 通讯协议，若 ECU 升级包较大（如上百兆）需要支持数据差分算法。
图 4 OTA 车载终端框架
3.2.1 OTA 人机交互设计
OTA 升级时除了云平台推送升级任务到车主 APP 提醒外，还需车端（车机或中控）配合开发显示一些升级界面（如升级进度、升级条件提醒等），用于提醒车主车辆设防及离车等配合操作，如图5~图9所示。
图 5 OTA 系统更新推送
图 6 OTA 更新日志
图 7 OTA 升级通知用户授权同意
图 8 OTA 升级过程中
图 9 OTA 升级成功
3.2.2 网络诊断架构设计
目前车载网络主干网仍以成熟的 CAN 总线通讯为主， 但对于软件包较大的ECU 由于刷新时长等因素，使用了车载以太网技术来突破CAN 总线的带宽限制，如图 10 所示。
主要架构包含 OTA 主控节点（TBOX 和GW）和被刷新ECU。TBOX 主要负责对外与云平台的连接通道安全可靠， 其内部集成了PKI 认证及身份鉴权等安全模块；GW 主要负责对内部网络的连接通道及集成诊断刷新机功能。刷新 ECU 根据软件包大小及理论刷新时长（如不超过20分钟），在 CAN 总线拓扑架构上增加了以太网接口设计，使用 DoIP 协议进行ECU 诊断刷新。
图 10 网络诊断架构图
3.2.3 ECU 软件存储及刷新策略
OTA 刷新前 ECU 软件升级包由云平台下发到车端 OTA 主控节点内存储，由文件存储模块来负责整车软件升级包的存储及备份包的管控。
升级管理模块主要负责刷新机刷新策略控制，OTA 刷新需要设计多次冗余刷新策略，即 OTA 后台发起一次升级任务后，同一辆车内 OTA 主控节点刷新机通常会对同一个 ECU 执行多次刷新尝试请求，减少偶发失败因素，提高 OTA 刷新成功率。
被刷新 ECU 主要分为传统嵌入式芯片 ECU 和复杂带操作系统（如Linux、Android、AutoSAR）的 ECU。根据 ECU 的硬件资源情况，我们又设计了如下 ECU 内部存储及刷新策略：
如图 11 所示的带操作系统 ECU，硬件存储资源丰富， 控制器内分配了两个不同启动区分，具体刷新过程如下：
a）默认出厂状态启动分区 1 激活，运行 V1.0 版本程序，启动分区 2 内无备份程序；
b）当 OTA 发起第一次 V1.1 版本刷新请求时，刷新数据会存储在备份分区（分区 2），刷新成功后激活启动分区 2，并交换备份分区（分区 1），下次上电后程序由启动分区 2 启动并正常工作；
c）当 OTA 发起第二次 V1.2 版本刷新请求时，刷新数据会被存储在备份分区 1，刷新成功后激活启动分区 1 并交换备份分区（分区 2），下次上电后程序由启动分区 1 启动并正常工作；
d）当 OTA 发起第三次 V1.3 版本刷新请求时，刷新数据会存储在备份分区（分区 2），刷新成功后激活启动分区 2，并交换备份分区（分区 1），下次上电后程序由启动分区 2 启动并正常工作。
如此循环交换分区刷新，即便遇到刷新失败当前启动分区无法正常启动时，ECU 也还可以通过自回滚从备份分区启动，确保系统工作正常。
图 11 带操作系统的 ECU 软件存储及刷新策略图
对于传统嵌入式 ECU，通常采用 BOOT+APP 的软件架构，如图 12 所示。功能越复杂的 ECU，其选择的主控芯片APP 容量越大，为了实现 ECU 内部软件自回滚功能，需要将 APP 空间划分一部分用于软件备份存储（如 APP2）。当 ECU 被刷新时，由 BOOT 代码负责提供升级流程引导，将升级包存储到 APP 区域（一般为程序启动入口地址空间）。由于嵌入式芯片ECU 程序启动入口通常只有一个，因此，当刷新失败（APP 激活不了）时，由 BOOT 引导程序指引复制APP2 的备份程序到 APP 区域进行回滚操作并启动，确保 ECU 工作正常。对于 APP 容量较小不支持 APP2 空间划分的 ECU，只能依靠 OTA 主控节点实现升级包的备份存储。
图 12 嵌入式 ECU 软件存储及刷新策略图
3.2.4 OTA 远程故障诊断设计
OTA 刷新目前主要是通过诊断通讯方式实现的 ECU 刷新条件检查、刷新过程数据传输及刷新后复位重启等操作，刷新过程中被刷新 ECU 由于进 BOOT 或其它原因无法保证应用程序正常运行（无感刷新方式除外）时，需要提前进行 ECU 故障屏蔽设计以免刷新过程造成整车出现一些故障码， 误导后续远程故障诊断及统计分析。
OTA 刷新过程中，诊断故障屏蔽可采用 UDS 诊断协议中的 0x85（ControlDTCSetting）服务来实现。
详情请关注公众号【车端】
OTA 远程故障诊断，还要解决的一个难点是与本地故障诊断的冲突问题。OTA 云平台难以识别本地诊断设备，因此，必须要在车端集成远程诊断与本地诊断的仲裁判断逻辑。如图 13 所示，由中央网关（GW）负责仲裁协调，当 OTA 刷新过程中，网关屏蔽本地故障诊断路由转发功能；同理，当有本地诊断设备时，网关屏蔽远程故障诊断路由转发功能，屏蔽只在当前点火循环有效。
汽车 OTA 刷新为远程诊断技术带来了迫切的需求和绝佳的发展机遇，主机厂积极部署的 OTA 升级体系和远程诊断平台，不仅是为了当下车辆的软件漏洞修复和功能快速更新，更是为了适应“软件定义”汽车（SDV）的趋势及更高阶的自动驾驶的技术发展，而主机厂远程诊断平台积累的数据，正是考验其大数据挖掘与智能诊断应用相结合的综合能力。身为“领头羊”的特斯拉，通过远程诊断技术已经实现 90% 情况下的车辆部件故障诊断，每年可为车主节省一天维修工时。国内车企要奋起直追，为车主提供更便捷、满意的服务体验，仍需较长的发展历程。
原文始发于微信公众号（车端）：远程诊断技术在汽车OTA刷新应用的研究
