汽车远程诊断技术研究

洪宇 孙宗姚 金钊 周幸达 张赫 张文杰 郭宗宾

（1.中国第一汽车股份有限公司 智能网联开发院，长春130013；2.汽车振动噪声与安全控制综合技术国家重点实验室，长春130013）

主题词：汽车 远程诊断 ODX OTX

缩略语

5G 5th-Generation

ACP Application Communication Protocol

CAN Controller Area Network

CANFD CAN with Flexible Data rate

ECU Electronic Control Unit

MQTT Message Queuing Telemetry Transport

OBD On Board Diagnostics

ODX Open Diagnostic Exchange Data

OTX Open Test sequence exchange format

SHA Secure Hash Algorithm

TLS Transport Layer Security

USB Universal Serial Bus

WIFI Wireless Fidelity

1 前言

在当前5G 和大数据发展的背景下，世界各国车企都在大力推进网联汽车的研发。作为网联汽车的诊断技术领域，诊断方式也日益多样化。传统车辆主要诊断方式还是通过OBD 口外接诊断设备，包括USB连接诊断设备、WIFI 或蓝牙连接3 种方式，操作人员在车辆现场对车辆进行诊断。

和传统方式对比，远程诊断在降低车辆问题排查成本、实时远程诊断定位、收集实时数据并进行大数据分析、为预诊断提供数据基础、远程排故问题车辆这些方面有很大便利性和优势。

随着5G 技术快速应用，让实现远程的实时诊断成为现实，目前主要远程诊断方式包括诊断模块布置在云端，车端仅作为执行端；诊断模块布置在车端，作为解析和执行诊断功能模块，云端进行任务配置和推送功能2种方式。从目前通讯技术发展角度和新型电子电气架构趋势分析来看，车端布置诊断模块是具有很大的性能优势，也是目前各主机厂的主要开发方向。本文以车端布置诊断模块为例进行方案说明。

2 远程诊断方案概述

这里先简要介绍一下ODX文件和OTX文件。

ODX（Open Diagnostic Exchange Data）开放式诊断序列作为ISO 标准的诊断数据库[1]，可以满足供应商、整车厂、设备供应商对诊断数据的使用要求，覆盖从设计、研发、生产到售后全阶段的数据交互。避免了由于各阶段不同用户使用不同的数据格式导致的数据偏差问题。ODX 文件主要包括ODX 通讯参数、诊断服务、刷写、字典4部分。

OTX（Open Test sequence exchange format）作 为ISO 通用化的诊断测试序列标准[2]，可以满足开发、生产、售后各阶段对诊断序列的使用要求，且格式统一、诊断数据通用，在诊断设备方面已经广泛使用。

本项目正是基于ODX、OTX 的上述标准化特性，基于此类数据文件进行集成开发。

远程诊断系统包括车端、云端、管端3部分主要内容。云端主要实现ODX、OTX 的编辑发布，实现诊断策略配置并推送到车端执行；管端使用MQTT[3]或ACP等传输协议实现数据传输；车端执行诊断代理功能，接收云端ODX、OTX 文件并执行策略，对执行结果进行反馈。远程诊断系统拓扑结构如图1所示。

图1 远程诊断方案拓扑

同时要考虑云端、数据链路及车端信息网络安全机制，通过使用证书签名、TLS、SHA256 等方式，以满足远程诊断系统的安全需求。

3 远程诊断方案

车端布置诊断模块方案主要包括车端模块方案、管端方案、云端方案3 部分内容。本文以车端布置诊断模块为例介绍各部分主要开发功能。

3.1 车端方案

车端布置诊断模块方式有2 种方式，即可以布置在TBOX或者车载控制器内，如车内网关中。

车端诊断模块需要根据云端发送的ODX、OTX 文件及云端配置诊断策略执行，并将结果反馈给云端处理。同时可实现与车端显示交互策略，及对大数据的预处理策略（图2）。

图2 车端方案示意

其中诊断模块的客户端主要实现：

（1）ODX、OTX 脚本接收和执行诊断策略，实现与其他ECU 的诊断交互功能，将车内控制器的反馈数据进行上传。

（2）按照云端的配置策略，包括执行条件的判别、任务执行、执行异常及错误处理机制的功能。

OTX 模块运行云端发送的OTX 操作序列，执行操作流程类指令。

D-Server[3]执行ODX 解析功能，将云端发送的ODX 文件进行解析并下发给车内各控制器，同时接收从控制器的响应报文。

通讯模块完成与车内其他控制器的诊断通讯功能。通讯方式包括CAN、CANFD、以太网等总线方式。

车端方案还包括了对车内实时数据的预处理等功能，避免大量实时数据上传云端，提高云端处理效率。

3.2 管端方案

车云之间的传输协议，目前主要使用方式包括MQTT、ACP 两种方式。本文以MQTT 为例进行简要说明。

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输协议）[4]，是一个基于客户端-服务器的消息发布/订阅传输协议。

实现MQTT 协议需要客户端和服务器端通讯完成，在通讯过程中，MQTT 协议中有3 种身份：发布者（Publish）、代理（Broker）（服务器）和订阅者（Sub⁃scribe）。其中，消息的发布者和订阅者都是客户端，消息代理是服务器，消息发布者可以同时是订阅者。

MQTT传输的消息分为：主题（Topic）和负载（Pay⁃load）2部分。

（1）Topic，可以理解为消息的类型，订阅者订阅（Subscribe）后，就会收到该主题的消息内容（Pay⁃load）；

（2）Payload，可以理解为消息的内容，是指订阅者具体要使用的内容。

MQTT 的数据包由固定头（Fixed header）、可变头（Variable header）和消息体（Payload）3部分构成。

车云之间通过使用MQTT 协议完成诊断数据的传输。并通过使用证书签名等方式保证传输数据的信息安全要求。

3.3 云端方案

云端主要功能包括ODX 模块、OTX 模块、车辆管理功能、诊断任务模块、诊断策略模块和诊断监控等主要功能模块（图3）。

图3 云端主要功能模块示意

图3中（1）～（6）的模块功能如下：

（1）OTX 模块主要实现对流程序列的编辑，例如标定流程、匹配流程、刷写流程等过程操作类指令。

（2）车辆管理用于对诊断车辆的管理。

（3）ODX 模块主要实现对ODX 诊断数据库文件的编辑功能，作为后续OTX的输入数据。

（4）诊断任务用于实施任务的发布和管理。

（5）诊断策略包括诊断执行条件的判别、诊断优先级、诊断任务的发布等操作。

（6）诊断监控实现对整个远程操作过程中的实时数据进行存储，用于后续操作记录追述。

除了以上功能模块外，还有对数据处理等一些功能，这里不再赘述。

3.4 测试验证方案

对于远程诊断进行测试验证，以保证此系统的可靠性和稳定性。

测试主要分为诊断接口调试、模拟环境测试和实车测试3个阶段。

接口测试主要是对各诊断模块的实现接口进行调试，满足各模块之间的调用和使用。模拟测试是在实车测试前进行的虚拟环境中对车管云端进行联合调试，实现对各端功能进行模拟验证，满足上线前的要求。最后通过在实车上对所有诊断功能进行验证，最终系统上线。

4 结论及启示

（1）随着5G 技术的快速推广及应用，车云结合的远程诊断方式将成为后续远程诊断发展的趋势。

（2）ODX、OTX 通用的标准化模块也将成为远程诊断的主要因素。标准化操作可以使整车厂、零件供应商、诊断设备供应商各方面做到最大化资源共享，保持数据的一致性和可靠性，极大的提高开发效率。

（3）目前以奥迪为主的整车厂已经在新车型上全面实现了远程诊断功能，并将陆续推广到全系车型。国内一些主流车厂也启动了相关技术研究，尤其是部分新势力企业也都已经进行了远程诊断相关技术的开发。

（4）随着网络技术的普及和5G 的发展，如何更好的结合云端、车端一体化技术实现远程诊断的实时性、安全性及可靠性也为整车厂提出更高的要求和挑战。