CN118034241A - 车联网远程诊断方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请提供一种车联网远程诊断方法、装置、电子设备及存储介质。该方法包括：当车端接收到开启远程诊断任务的指令后，利用车载通信模块向云端发送链接请求；远程诊断转发模块根据接收到的响应消息发起链路激活请求，更新车辆远程诊断任务状态为激活成功；利用远程诊断协议解析模块对远程诊断请求进行解析，生成远程诊断任务指令，并将远程诊断任务指令发送给云端通信组件；利用云端通信组件通过已建立的长链接向车端发送远程诊断任务指令，并接收车端返回的响应内容，利用远程诊断协议解析模块对响应内容进行解析，得到远程诊断结果。本申请远程诊断方法降低操作门槛，故障诊断延迟低，无需依赖车端的软件更新，保证了远程诊断的高效性和稳定性。

Description

车联网远程诊断方法、装置、电子设备及存储介质

技术领域

本申请涉及新能源汽车技术领域，尤其涉及一种车联网远程诊断方法、装置、电子设备及存储介质。

背景技术

车联故障诊断作为一种现代化的车辆维护方法，依赖于车辆内部的传感器、控制单元和通信模块，让车辆能够实时共享其数据和信息。这种方法可以实现对车辆故障的即时检测、诊断和问题排查。为了实现这一目的，传统的车辆故障诊断常常采用近端诊断方法，即将车辆与诊断仪物理连接，利用车端的OBD接口获取必要的诊断信息。

然而，此种近端诊断方法具有明显的局限性。首先，它需要物理连接，这意味着必须拥有特定的硬件接口和线缆，并且对普通车主来说可能操作复杂。其次，近端诊断可能导致故障诊断的延迟，因为需要花费时间在车辆和诊断仪之间建立连接。此外，对于遥远地区或难以直接接触的车辆，近端诊断很难施展其效用。而功能上，近端诊断相对较为有限，通常仅提供故障码的基本读取、实时数据显示等基础功能。

为了克服这些限制，车辆远程诊断方法应运而生。但是，传统的远程诊断车云之间的协议选择也带来了一系列问题。传统远程诊断主要采用MQTT协议，而非标准的DOIP UDS协议。这导致了诊断协议的不匹配，尤其是在车云采用MQTT与车内诊断协议通常采用DOIP+UDS的场景中。此外，由于大部分的远程诊断处理流程和逻辑都是在车端执行的，这使得在需要更改或配置远程诊断流程和内容时，车端软件的更新过程显得尤为繁琐。

发明内容

有鉴于此，本申请实施例提供了一种车联网远程诊断方法、装置、电子设备及存储介质，以解决现有技术存在的近端诊断操作门槛高，故障诊断存在延迟，功能相对有限，导致车端软件更新复杂，难以灵活配置和更改远程诊断流程及内容的问题。

本申请实施例的第一方面，提供了一种车联网远程诊断方法，包括：利用云端的管理界面选择远程诊断任务，并向车端发送远程诊断任务请求，根据车端对远程诊断任务请求的反馈，判断是否开启远程诊断任务；当车端接收到开启远程诊断任务的指令后，利用车载通信模块向云端发送链接请求，并利用云端将链接成功的响应消息发送给远程诊断转发模块；远程诊断转发模块根据接收到的响应消息发起链路激活请求，更新车辆远程诊断任务状态为激活成功，并触发远程诊断请求；将远程诊断请求通过消息中间件发送给远程诊断协议解析模块，利用远程诊断协议解析模块对远程诊断请求进行解析，生成远程诊断任务指令，并将远程诊断任务指令发送给云端通信组件；利用云端通信组件通过已建立的长链接向车端发送远程诊断任务指令，并接收车端返回的响应内容，利用远程诊断协议解析模块对响应内容进行解析，得到远程诊断结果。

本申请实施例的第二方面，提供了一种车联网远程诊断装置，包括：请求模块，被配置为利用云端的管理界面选择远程诊断任务，并向车端发送远程诊断任务请求，根据车端对远程诊断任务请求的反馈，判断是否开启远程诊断任务；链接模块，被配置为当车端接收到开启远程诊断任务的指令后，利用车载通信模块向云端发送链接请求，并利用云端将链接成功的响应消息发送给远程诊断转发模块；激活模块，被配置为远程诊断转发模块根据接收到的响应消息发起链路激活请求，更新车辆远程诊断任务状态为激活成功，并触发远程诊断请求；解析模块，被配置为将远程诊断请求通过消息中间件发送给远程诊断协议解析模块，利用远程诊断协议解析模块对远程诊断请求进行解析，生成远程诊断任务指令，并将远程诊断任务指令发送给云端通信组件；诊断模块，被配置为利用云端通信组件通过已建立的长链接向车端发送远程诊断任务指令，并接收车端返回的响应内容，利用远程诊断协议解析模块对响应内容进行解析，得到远程诊断结果。

本申请实施例的第三方面，提供了一种电子设备，包括存储器，处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述方法的步骤。

本申请实施例的第四方面，提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现上述方法的步骤。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

通过利用云端的管理界面选择远程诊断任务，并向车端发送远程诊断任务请求，根据车端对远程诊断任务请求的反馈，判断是否开启远程诊断任务；当车端接收到开启远程诊断任务的指令后，利用车载通信模块向云端发送链接请求，并利用云端将链接成功的响应消息发送给远程诊断转发模块；远程诊断转发模块根据接收到的响应消息发起链路激活请求，更新车辆远程诊断任务状态为激活成功，并触发远程诊断请求；将远程诊断请求通过消息中间件发送给远程诊断协议解析模块，利用远程诊断协议解析模块对远程诊断请求进行解析，生成远程诊断任务指令，并将远程诊断任务指令发送给云端通信组件；利用云端通信组件通过已建立的长链接向车端发送远程诊断任务指令，并接收车端返回的响应内容，利用远程诊断协议解析模块对响应内容进行解析，得到远程诊断结果。本申请采用远程诊断方法，降低操作门槛，故障诊断延迟低，无需依赖车端的软件更新，保证了整个远程诊断流程的高效性和稳定性。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1是本申请实施例提供的车联网远程诊断方法的流程示意图；

图2是本申请实施例提供的车联网远程诊断装置的结构示意图；

图3是本申请实施例提供的电子设备的结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

车联故障诊断是一种车辆维护方法，它利用车辆之间的通信技术，使车辆能够共享数据和信息，从而实现故障检测、诊断和问题排查。车联故障诊断通过车辆内部的传感器、控制单元和通信模块，将车辆数据传输到诊断设备进行分析。而车辆故障诊断常用的方式是采用近端诊断方式，即通过将诊断仪以物理连接线的方式和车端OBD接口进行连接获取诊断信息。

目前，现有技术中常用的近端诊断流程包括以下内容：

1）连接诊断仪：技术人员或车主通过连接诊断仪（也称为OBD诊断仪，OBD表示“On-Board Diagnostics”）到车辆的诊断接口。这个接口通常位于驾驶员座位下方或仪表板附近。

2）启动车辆：车辆启动后，诊断仪与车辆的ECU（电控单元）建立连接。诊断仪能够读取车辆的实时数据和存储的故障码。

3）数据读取和解析：诊断仪读取车辆内部的传感器数据、控制单元信息以及错误码等数据。诊断仪将这些数据通过标准的通信协议（如OBD-II协议）传送给连接的设备，如智能手机、平板电脑或电脑。

4）故障码分析：诊断仪能够解析读取到的故障码，这些码代表车辆系统中出现的问题。诊断仪将故障码翻译成易于理解的术语，描述问题的性质和位置。

5）问题定位：在诊断仪的屏幕上，技术人员或车主能够查看问题的详细信息，包括故障码、问题描述和可能的原因，这有助于确定是否需要进行进一步的检查或维修。

8）实时数据监测：诊断仪还能够显示实时的车辆数据，如引擎转速、车速、冷却液温度等。这些数据可以帮助技术人员了解车辆的状态，判断是否存在其他问题。

7）维修建议：基于故障码和实时数据，诊断仪可以提供基本的维修建议，如检查特定部件、清除故障码或进行简单的调整。

8）故障清除：在问题得到解决后，诊断仪通常允许清除故障码，以确认问题已经修复。

但是，上述现有技术中的近端诊断方案仍存在以下缺点：

1）物理接入要求：

近端诊断需要在车辆和诊断仪之间建立物理连接，通常需要特定的硬件接口和线缆。这使得使用和操作有一定的门槛，尤其对于普通车主来说可能不太方便。

2）实时性受限：

近端诊断需要将车辆连接到诊断仪上，这可能需要一些时间，特别是当问题不明显时，需要车主或技术人员找到并连接到诊断接口。这可能导致问题诊断的延迟。

3）无法应对距离问题：

对于需要远程访问才能解决的问题，如车辆处于遥远地区或无法直接接触的地方，近端诊断无法发挥作用。

4）功能有限：

近端诊断通常提供基本的故障码读取、实时数据显示和简单建议等功能，相比之下，远程诊断能够更全面地分析车辆数据，进行更深入的问题诊断。

另外，传统远程诊断车云之间不是采用的标准DOIP UDS协议，而是通过车云采用MQTT协议方式，采用该方式存在如下问题：此种协议与原有车云诊断协议不匹配，车云采用MQTT，但车内诊断协议一般使用DOIP+UDS，存在协议转换问题；采用MQTT方式主要的远程诊断处理流程及逻辑都在车端，云端只是展示远程诊断结果，但由于车端软件更新流程繁琐无法做到灵活配置及更改远程诊断流程及内容。

针对现有技术中存在的问题，本申请提出一种车联网远程诊断方法及装置，本申请的车联网远程诊断方法在解决近端诊断带来的相关问题同时，车云还使用DOIP+UDS协议方式，解决了传统远程诊断车云采用MQTT方式带来的问题。下面结合具体实施例对本申请车联网远程诊断方法涉及的系统架构进行说明，具体可以包括以下内容：

1. 云端即车联网的云端部分，负责具体的远程诊断管理功能，主要包括远程诊断服务及接入层，其中远程诊断服务主要负责远程诊断配置、远程诊断协议解析及远程诊断指令下发。接入层主要负责和车端建立远程连接。

2. 车端诊断部分主要负责云端下发的远程指令并将车端的诊断结果上报给云端，其中TBOX是车端负责和云端建立连接，GW即车端网关负责诊断指令的路由及转发。

3. 车云之间远程诊断指令采用DOIP协议，远程诊断的功能开启采用MQTT指令。

下面结合附图以及具体实施例对本申请技术方案的内容进行详细描述。

图1是本申请实施例提供的车联网远程诊断方法的流程示意图。图1的车联网远程诊断方法可以由远程诊断服务器来执行。如图1所示，该车联网远程诊断方法具体可以包括：

S101，利用云端的管理界面选择远程诊断任务，并向车端发送远程诊断任务请求，根据车端对远程诊断任务请求的反馈，判断是否开启远程诊断任务；

S102，当车端接收到开启远程诊断任务的指令后，利用车载通信模块向云端发送链接请求，并利用云端将链接成功的响应消息发送给远程诊断转发模块；

S103，远程诊断转发模块根据接收到的响应消息发起链路激活请求，更新车辆远程诊断任务状态为激活成功，并触发远程诊断请求；

S104，将远程诊断请求通过消息中间件发送给远程诊断协议解析模块，利用远程诊断协议解析模块对远程诊断请求进行解析，生成远程诊断任务指令，并将远程诊断任务指令发送给云端通信组件；

S105，利用云端通信组件通过已建立的长链接向车端发送远程诊断任务指令，并接收车端返回的响应内容，利用远程诊断协议解析模块对响应内容进行解析，得到远程诊断结果。

首先，对本申请实施例在实际场景中涉及到的技术名词进行解释说明，具体可以包括以下内容：

OBD（On-Board Diagnostics）：车载诊断系统，目前所有汽车都具备OBD功能和接口，OBD的主要用途就是存储车辆故障信息。

MQTT（Message Queuing Telemetry Transport）：一种物联网通信协议；

ECU（Electronic Control Unit）：车端电子控制单元。

CAN（Controller Area Network）：即控制器局域网，是一种车端零部件之间能够实现分布式实时控制的串行通信网络。

DOIP（Diagnostic Over Internet Protocol）：DOIP是一种基于互联网协议的车辆诊断通信协议，它允许车辆通过互联网与远程服务器进行通信。

UDS（Unified Diagnostic Services）通信协议：UDS是一种标准的诊断服务协议，定义了车辆与诊断工具之间的通信方式和消息格式，包括诊断会话、故障码读取、参数配置等功能。

DTC（Diagnostic Trouble Code）：诊断故障代码，故障码是指示车辆出现问题或故障的代码。当车辆的电子控制单元（ECU）检测到某种问题或异常时，它会生成一个故障码，以指示问题的性质。每个故障码都与特定的问题相关，例如发动机故障、排放系统问题等。诊断工具可以读取故障码，以便技术人员了解车辆可能存在的问题，然后采取适当的维修措施。

DID（Data Identifier）：数据标识符是用于识别和获取特定车辆数据的数字代码。每个数据标识符都与一种或多种特定的车辆参数或数据相关联。通过发送适当的指令和标识符，诊断工具可以请求车辆的特定数据，如车速、发动机转速、冷却液温度等。数据标识符是在OBD-II标准中定义的，不同的车辆制造商可能支持不同的数据标识符。

web：即车联网云端的web管理界面，负责提供远程诊断功能操作，该web使用对象为维修运维人员。

vhr-backend：车联网远程诊断服务中的后台管理服务，负责对接web端及具体的远程诊断下发。

terminal-center：设备中心，负责管理车端设备基础信息。

vhr-adapter：负责远程诊断协议解析及转发，也称为远程诊断协议解析模块。

terminal-gateway：简称tg，负责车联网云端和车端的接入。

Tbox：车端负责联网的设备，负责与云端车联网平台建立连接。

vhr-doip-gateway：简称ng，远端负责和车端进行doip通讯的网关，即云端通信组件。

在一些实施例中，利用云端的管理界面选择远程诊断任务，并向车端发送远程诊断任务请求，包括：

在云端的web管理界面选择远程诊断任务，确定远程诊断任务对应的类型和车系，利用后台管理服务调用设备中心请求接口，以便向车端发送远程诊断任务请求；

其中，远程诊断任务对应的诊断接口包括读取整车故障码、读取整车数据、读取ECU故障码和/或读取ECU数据流。

具体地，本申请的远程诊断技术通过一个集成的云端管理界面实现，允许用户或车辆技术人员远程对车辆进行故障诊断。下面对通过云端的web管理界面选择远程诊断任务的过程进行详细说明，具体可以包括以下内容：

远程诊断任务的初始化：用户或车辆技术人员通过云端的web管理界面登录。在登录后的界面中，他们可以看到一个列表，列出了所有可以进行远程诊断的车辆。通过此界面，他们可以选择需要进行远程诊断的车辆。

选择诊断任务：在选择了特定车辆后，用户或技术人员可以进一步选择远程诊断任务的类型和车系。这一步是非常关键的，因为不同的车系和车型可能有不同的诊断协议和接口。选择后，后台管理服务将自动调用相应的设备中心请求接口，以便将远程诊断任务请求发送到对应的车端。

远程诊断接口：云端系统提供了多种远程诊断接口供用户或技术人员选择，具体包括：

a. 读取整车故障码：可以通过API端点[/admin/remote-diagnosis:POST]实现。

b. 读取整车数据：可以通过API端点[/admin/remote-diagnosis/read-vehicle-data]获取。

c. 读取ECU故障码：可以通过[/admin/remote-diagnosis/read-ecu-dtc]端点实现的。

d. 读取ECU数据流：可以通过[/admin/remote-diagnosis/read-ecu-data]端点来实现。

远程诊断任务的管理：为了记录和管理每一次的远程诊断，系统在后台有一个专门的数据库表VHR_RemoteDiagnosis。每当开始一个新的远程诊断任务时，这个表就会新增一条记录。该表详细记录了诊断的开始时间、结束时间、诊断类型、车系、诊断状态以及任何与该次诊断相关的其他信息。

需要注意的是，远程诊断的开启及关闭是整个远程诊断的前置条件。这确保了在进行任何远程诊断操作之前，车辆的远程诊断功能已经被正确地开启。如果车辆不在线，那么web端将无法选择诊断任务进行诊断。

在一些实施例中，利用后台管理服务调用设备中心请求接口，以便向车端发送远程诊断任务请求，包括：

利用后台管理服务通过设备中心请求接口发送调用远程诊断任务请求的命令，启动超时计时，若在预设的时间内未收到车端的反馈，再次发送调用远程诊断任务请求的命令，当未收到车端反馈的次数超过预设次数时，将远程诊断记录状态更新为超时，并发送提示；

利用消息中间件，将车辆终端网关与用于远程诊断协议解析及转发的远程诊断协议解析模块进行双向通讯，车辆终端网关基于EMQ下发MQTT远程诊断任务的开启指令，并设置一个预定超时时间以监控车端的响应状态。

具体地，本申请实施例通过后台管理服务与车端进行远程诊断通讯的完整过程，包括失败重试机制和双向通讯协议的转发。

进一步地，初始化远程诊断任务请求包括以下内容：

当用户或技术人员通过云端界面发起远程诊断请求后，vhr-backend（远程诊断服务中的后台管理服务）将调用设备中心的命令调用接口[/public/vehicles/remote-instructions]。

随着命令的下发，开始一个预设的10秒超时计时。如果在这个时间段内未收到车辆终端（车端）的反馈，该命令将被重新发送。这个重试过程最多重复2次（总共3次尝试）。

若在3次尝试后都未收到来自车端的反馈，则系统会产生一个提示：“未收到车端反馈”。同时，远程诊断记录状态在数据库中将被更新为“超时”。

进一步地，消息转发与协议解析包括以下内容：

tg通过kafka向vhr-adapter（负责远程诊断协议解析及转发的模块）下发调用请求，该请求会被发送到kafka主题vhrAdapterTopic。vhr-adapter接着通过kafka将调用请求转发给tg，这一请求将被发布到kafka主题vhrTgTopic。

在上述阶段，tg通过EMQ下发一个MQTT远程诊断任务开启指令到车辆终端。此指令发布在mqtt主题：Client/V1/REMOTE_DIAG-DIAG_START_STOP/${deviceID}。此处设置一个超时时间，并存储在redis中，以监控车端的响应状态。

进一步地，车端响应与状态更新包括以下内容：

当车端的Tbox发送响应到mqtt主题Server/V1/REMOTE_DIAG-DIAG_START_STOP/${deviceID}时，系统将删除在redis中设置的超时时间。

terminal-gateway接收到车端的响应后，将发送一个kafka响应请求到主题vhrAdapterTboxTopic。vhr-adapter在接收到该kafka请求后会解析消息类型（根据消息头中的msgType）。若在预设超时时间内仍未收到Tbox的响应，则发送的内容将标记为“超时”。

vhr-adapter根据解析到的消息类型，将调用vhr-backend响应接口[internal/remote-diagnosis/response:POST]以更新车辆远程诊断的状态。如响应成功，状态更新为“开启成功”，而如果响应失败或超时，状态更新为“开启失败”。相关的状态信息将被记录在数据库表VHR_RemoteDiagnosiVehicle.status字段中。

在一些实施例中，利用车载通信模块向云端发送链接请求，并利用云端将链接成功的响应消息发送给远程诊断转发模块，包括：

利用车载通信模块发起基于TCP的链接请求到云端的云端通信组件端口，车载通信模块以UDP方式发送车辆声明信息至云端，其中，车辆声明信息中包含车辆识别号码；

在TCP链接建立之后，云端通信组件通过TCP请求车辆信息，车载通信模块通过TCP向云端通信组件返回所请求的车辆信息；

在云端通信组件接收到车辆信息后，通过消息中间件将链接成功的响应消息发送至远程诊断转发模块，当远程诊断转发模块接收到响应消息后，调用后台管理服务的链接成功请求，并在同步接收到后台管理服务的响应后，发起链路激活请求。

具体地，本申请实施例还公开了车载通信模块与云端之间建立远程诊断链路的流程，该流程可以包括以下内容：

第一，车载通信模块与云端建链请求：

当需要进行远程诊断时，Tbox（车载通信模块）首先发起基于TCP的建链请求。这一请求是针对云端的ng组件，并其使用端口13400。在标准的诊断开启协议（DOIP）中，通常车载通信模块会在TCP连接建立之前先通过UDP发送车辆声明信息。然而在这一实施例中，这一步骤暂不实现。不过，如果按照这个步骤进行，Tbox将连续3次通过UDP发送车辆声明信息，其中包括车辆的识别号码，即VIN。

第二，云端请求车辆信息：

一旦TCP连接被成功建立，云端的ng组件将通过TCP向Tbox发送车辆信息请求。在收到该请求后，Tbox会以TCP方式返回请求的车辆信息。

第三，云端与远程诊断转发模块的通讯：

当ng组件成功接收到来自Tbox的车辆信息后，它将构建一个链接成功的响应消息。之后，ng组件通过kafka将此响应消息发送给vhr-adapter，该消息发布在vhrNgAdapterTopic主题下。当vhr-adapter接收到这一响应消息后，它会调用后台管理服务的链接成功请求。这一请求旨在通知后台管理服务，车与云端之间的远程诊断链路已成功建立。后台管理服务在接收到此请求后，会返回一个响应。一旦vhr-adapter同步接收到这一响应，它会发起链路激活请求，从而确保链路已经完全激活并准备好进行远程诊断。

在一些实施例中，远程诊断转发模块根据接收到的响应消息发起链路激活请求，更新车辆远程诊断任务状态为激活成功，并触发远程诊断请求，包括：

利用后台管理服务将车辆的诊断状态更新为路由激活中，并利用消息中间件将链路激活请求发送给远程诊断转发模块；

远程诊断转发模块利用消息中间件进行链路激活请求的发起，并在云端通信组件中利用TCP基于DOIP协议格式进行路由激活请求，并同步获取路由激活响应；

将路由激活响应传送给远程诊断转发模块，以使远程诊断转发模块向后台管理服务发起建链响应请求。

具体地，本申请实施例还详细描述了在远程诊断过程中，如何根据接收到的响应消息对链路进行激活，进而触发远程诊断请求的详细实施步骤，例如可以包括以下步骤：

步骤1、链路激活请求发起：

vhr-adapter在接收到响应消息后，首先调用vhr-backend的建链成功请求。当vhr-adapter同步接收到vhr-backend返回的响应后，它会进一步发起链路激活请求。对应地，vhr-backend将更新车辆的诊断状态为"路由激活中"，这涉及到VHR_RemoteDiagnosiVehicle.status表的修改。接着，vhr-backend通过kafka将这一链路激活请求发送给vhr-adapter。

步骤2、链路激活：

vhr-adapter在收到链路激活请求后，将继续通过kafka进行激活请求的发起。这一请求会被转发到云端的ng组件。ng组件将基于TCP协议，采用DOIP协议格式进行路由激活请求。需要注意，这里使用的是DOIP的标准路由激活请求报文。在请求发送后，ng组件会同步接收到路由激活响应。之后，ng组件将这一路由激活响应通过kafka发送回vhr-adapter。

步骤3、建链响应与任务状态更新：

在vhr-adapter接收到路由激活响应后，它会立即调用vhr-backend的建链响应请求。根据响应的内容，vhr-backend将更新车辆远程诊断任务状态。如果链路激活成功，状态会被更新为"激活成功"。这同样涉及到VHR_RemoteDiagnosiVehicle.status表的修改。随后，系统将触发远程诊断请求。若在某一步骤中链路激活失败，vhr-backend需要同步更新任务状态为失败，并可能进行后续的异常处理和错误提示。

在一些实施例中，利用远程诊断协议解析模块对远程诊断请求进行解析，生成远程诊断任务指令，并将远程诊断任务指令发送给云端通信组件，包括：

当车辆的远程诊断任务状态为激活成功时，触发对远程诊断请求的解析操作，其中，远程诊断请求中包含诊断指令和相关文件信息；

云端通信组件利用已建立的长链接，根据DOIP协议将远程诊断任务指令封装为UDS指令并发送给云端通信组件；

云端通信组件将UDS指令发送给车端，以使车端接收UDS指令后同步返回响应，并使车端发送响应内容。

具体地，本申请实施例还公开了在远程诊断过程中，如何利用远程诊断协议解析模块对远程诊断请求进行解析、生成远程诊断任务指令，并将其发送给云端通信组件的详细实施步骤，例如可以包括以下步骤：

步骤1、触发远程诊断请求解析：

当车辆的远程诊断任务状态更新为"激活成功"，vhr-backend将触发对远程诊断请求的解析操作。这一远程诊断请求中不仅包括诊断指令，还包含了与诊断相关的文件信息，例如pdx文件信息。为确保准确执行，vhr-backend在发起远程诊断请求前，确保所有的前置条件均已满足。

步骤2、生成并发送远程诊断任务指令：

一旦解析完毕，vhr-backend将通过kafka发起远程诊断请求。需要注意，该kafka请求中将包括诊断指令所需的所有pdx文件信息。接着，vhr-adapter接收该请求，并通过kafka将生成的远程诊断任务指令发送给ng组件。

步骤3、封装UDS指令并发送：

ng组件接收到远程诊断任务指令后，首先利用已建立的长链接，将该任务指令根据DOIP协议封装为UDS指令。这里需要特别注意，UDS指令在发送前将采用DOIP方式进行封装。接着，ng组件将这一封装好的UDS指令发送至车端。

步骤4、车端响应：

车端在接收到UDS指令后，将同步返回一个响应，这通常为ACK（Acknowledgement,确认）或NACK（Negative Acknowledgement, 否认）。但这只是一个即时的响应，实际的诊断响应内容，例如错误码、诊断数据等，车端将再次进行发送。这意味着，车端会在之后的时间里再次发送响应内容。

步骤5、后续响应处理：

ng组件在接收到车端的响应后，会进一步处理这些响应，如对ACK或NACK进行解析、存储实际诊断内容等。处理完成后，相应的后续步骤，如错误处理、反馈用户等，将与前述的步骤相同。

在一些实施例中，利用云端通信组件通过已建立的长链接向车端发送远程诊断任务指令，并接收车端返回的响应内容，利用远程诊断协议解析模块对响应内容进行解析，得到远程诊断结果，包括：

云端通信组件接收到车端返回的响应内容后，通过消息中间件将响应内容传递给远程诊断协议解析模块，远程诊断协议解析模块对接收到的响应内容进行解析，并调用后台管理服务的接口进行处理；

在后台管理服务中，根据解析得到的响应结果，对远程诊断任务状态进行更新，当响应结果为成功时，将远程诊断任务状态更新为成功，当响应结果为失败时，将远程诊断任务状态更新为失败。

具体地，本申请实施例还公开了在车辆远程诊断过程中，如何通过云端通信组件利用已建立的长链接向车端发送远程诊断任务指令、接收并解析车端的响应内容，以及根据解析结果进行后续操作的详细实施步骤，例如可以包括以下步骤：

步骤1、车端响应的接收和转发：

ng组件，作为云端通信组件，在已建立的长链接上接收到车端的响应内容后，为确保响应内容能被远程诊断协议解析模块准确处理，ng将其通过kafka消息中间件发送给vhr-adapter。

步骤2、响应内容的解析：

vhr-adapter，作为远程诊断协议解析模块，接收到从ng传来的响应内容后，开始对其进行解析，将复杂的车端响应数据转换为更直观、易于处理的格式或结构。

步骤3、后台服务的调用及处理：

解析完毕后，vhr-adapter调用vhr-backend接口，将解析后的响应内容传递给后台管理服务。vhr-backend在接收到解析后的响应内容后，根据内容进行进一步的处理。主要是更新远程诊断任务状态。

步骤4、远程诊断任务状态的更新：

vhr-backend将基于解析得到的响应结果来进行相应的任务状态更新。若响应内容表示成功，则直接更新远程诊断任务状态为"成功"。需要注意的是，这与传统的远程诊断方式有所不同。在传统方式中，因为是异步操作，任务状态可能会首先被更新为"已下发"。若响应内容表示失败，则远程诊断任务状态会被更新为"失败"。

步骤5、异常处理：

在上述流程中，任何环节都可能发生意外或错误，如消息丢失、解析错误等。为应对这些情况，需要设定相应的异常处理机制，如重试、日志记录、警告通知等。

在一些实施例中，远程诊断协议解析模块对接收到的响应内容进行解析，并调用后台管理服务的接口进行处理，包括：

为每个整车控制器对应的远程故障诊断配置一个远程诊断任务，将所有远程诊断任务组成整车远程诊断任务集合；

为每个远程诊断任务分配优先级，优先级用于表征远程诊断任务的重要程度，优先级由故障等级、历史故障次数平均值以及历史故障读取总次数经过计算得到；

利用预先定义的目标函数作为对整车远程诊断任务集合进行任务编排的优化目标，对目标函数进行优化，以便根据优先级执行所述远程诊断任务，且最小化总的执行时间；

其中，历史故障读取总次数由车端上报的故障告警报文分析得到，远程诊断任务包括故障编码诊断任务和故障数据诊断任务，故障等级包括故障编码的故障等级。

具体地，在上述远程诊断的实现方法中，远程诊断通常包含整车控制器，通常可诊断核心控制数量大约有50多个，而每个控制器又包含至少15个以上DTC(故障编码)，20个以上DID(故障数据)，由于每个DTC及每个DID读取都是单次串行读取，且每次读取非常缓慢，若要将上述所有整车控制器的DTC、DID都读取完，至少需要十几分钟以上。而且对于整车远程诊断，维修人员更关注优先级较高的或者出现问题较多的诊断，针对以上场景，为优化诊断任务的执行顺序和提高诊断的效率，本申请提出一种基于DTC故障等级以及历史DID读取趋势、历史故障趋势的诊断编排算法，具体可以包括以下内容：

1）算法模型前置条件：注意在远程诊断任务中，远程诊断DTC和远程诊断DID是不能同时进行的，所以以下算法模型是基于单次整车远程诊断DTC或者单次远程诊断DID。

2）该任务编排算法模型如下：

诊断任务表示，远程诊断中控制器中每个DTC、DID的诊断，代表一个诊断任务，定义整车远程诊断的任务集合为T，表示如下：，该集合表示所有待执行的诊断任务。

任务优先级分配，为每个任务分配一个优先级，其中是一个实数，表示任务的重要性。优先级包括DTC故障等级，历史故障平均值，历史DID读取次数。

其中，对于单个DTC的；

其中，表示故障等级，，DTC实际故障等级分为1,2,3,4等级，其中等级1为最高，等级4为最低。

其中，表示该DTC出现历史故障次数的平均值，其具体计算方式如下：

其中，分子表示该DTC历史出现故障的总次数，分母表示该车总的历史故障数。其中即DTC历史出现故障的总次数来源于车端上报的故障告警报文，车端如果发生故障会将具体的DTC通过故障报文的形式上报到云端，云端会将每次的故障报文信息记录到数据库中，数据库中的每条告警报文记录会以车辆ID+DTC+DTC发生时间为唯一标识，即=Sum(云端告警报文记录)，其中云端告警报文记录要求以车辆ID+DTC+DTC发生时间唯一。如果存在车辆ID+DTC+DTC发生时间重复的情况则需要去重处理。

需要说明的是，以上若值越大就表示DTC优先执行的权利就越大。

3）任务编排目标函数：

定义一个目标函数表示诊断任务编排的优化目标。在整车远程诊断中，由于我们更重视优先级较高的诊断，所以该目标函数表示我们要达到既能执行到需要重视的诊断任务又能最小化总执行时间。

4）目标函数可以表示为：

其中，表示该DTC历史诊断平均耗时，该平均诊断时间可从历史的诊断任务中求得。

其中，是任务是否被执行的二进制变量，其具体计算值如下：

= 1 表示任务被执行，即>=时=1；

= 0表示任务不被执行。即<时=0；

综上，诊断任务执行顺序根据以上步骤中计算出的值，按依次从大到小执行。另外该诊断任务是否执行取决于。

根据本申请实施例提供的技术方案，本申请实施例具有以下优点：

统一协议与灵活配置：本申请提出的方案采用了DOIP+UDS协议，使车云之间的远程诊断通信协议一致。这带来了通信的统一性，消除了协议转换和适配的问题。同时，云端可以灵活地配置和控制远程诊断流程，无需车端的繁琐软件更新，大大提高了配置的灵活性和操作的便捷性。

远程诊断性能优化：采用DOIP+UDS协议方式，实现了车云之间远程诊断的性能优化。这种方式能够更高效地传输诊断数据，加速故障诊断流程，缩短诊断响应时间，从而提升整体诊断效率。

减少车端复杂性：通过在云端控制远程诊断的配置和处理内容，车辆端的处理逻辑相对简化，只需按照协议进行数据传输和遵循操作流程。这有助于降低车端的复杂性和维护成本。

远程问题解决能力提升：由于采用统一的通信协议，远程诊断能够更全面地分析车辆数据，实现更深入的问题诊断。云端可以获取更多的车辆信息，为技术人员提供更准确的问题定位和解决方案。

提高诊断的效率：基于DTC故障等级以及历史DID历史故障趋势的诊断编排算法可以有效提高整车诊断的效率。

DOIP+UDS通信协议的应用： 将DOIP+UDS通信协议应用于车云之间的远程诊断中。这种协议的应用使得车辆与云端之间的通信更加统一，避免了协议转换和适配的问题，提高了通信效率。

云端控制远程诊断流程： 在云端实现对远程诊断流程的灵活控制。云端可以动态配置诊断任务和流程，而无需依赖车端的软件更新。这种控制方式极大地提高了诊断的灵活性和可操作性。

远程诊断任务管理机制： 远程诊断任务的管理机制能够在云端实现对诊断任务的动态管理和分配，确保诊断任务的准确执行。

设备连接和数据传输机制： 本方案还涉及设备连接和数据传输机制的设计。车辆通过TBOX与云端建立连接，云端通过设备中心、适配器等组件实现对车辆的诊断指令下发和结果响应。

远程诊断流程优化： 本申请还涉及远程诊断流程的优化，包括开启与关闭远程诊断、建立链路和路由激活、请求和响应等。这些优化措施保证了整个远程诊断流程的高效性和稳定性。

远程诊断任务编排算法：对于整车远程诊断，维修人员更关注优先级较高的或者出现问题较多的诊断，针对以上场景，为优化诊断任务的执行顺序和提高诊断的效率，本申请提出一种基于DTC故障等级以及历史DID历史故障趋势的诊断编排算法。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图2是本申请实施例提供的车联网远程诊断装置的结构示意图。如图2所示，该车联网远程诊断装置包括：

请求模块201，被配置为利用云端的管理界面选择远程诊断任务，并向车端发送远程诊断任务请求，根据车端对远程诊断任务请求的反馈，判断是否开启远程诊断任务；

链接模块202，被配置为当车端接收到开启远程诊断任务的指令后，利用车载通信模块向云端发送链接请求，并利用云端将链接成功的响应消息发送给远程诊断转发模块；

激活模块203，被配置为远程诊断转发模块根据接收到的响应消息发起链路激活请求，更新车辆远程诊断任务状态为激活成功，并触发远程诊断请求；

解析模块204，被配置为将远程诊断请求通过消息中间件发送给远程诊断协议解析模块，利用远程诊断协议解析模块对远程诊断请求进行解析，生成远程诊断任务指令，并将远程诊断任务指令发送给云端通信组件；

诊断模块205，被配置为利用云端通信组件通过已建立的长链接向车端发送远程诊断任务指令，并接收车端返回的响应内容，利用远程诊断协议解析模块对响应内容进行解析，得到远程诊断结果。

在一些实施例中，图2的请求模块201在云端的web管理界面选择远程诊断任务，确定远程诊断任务对应的类型和车系，利用后台管理服务调用设备中心请求接口，以便向车端发送远程诊断任务请求；其中，远程诊断任务对应的诊断接口包括读取整车故障码、读取整车数据、读取ECU故障码和/或读取ECU数据流。

在一些实施例中，图2的请求模块201利用后台管理服务通过设备中心请求接口发送调用远程诊断任务请求的命令，启动超时计时，若在预设的时间内未收到车端的反馈，再次发送调用远程诊断任务请求的命令，当未收到车端反馈的次数超过预设次数时，将远程诊断记录状态更新为超时，并发送提示；利用消息中间件，将车辆终端网关与用于远程诊断协议解析及转发的远程诊断协议解析模块进行双向通讯，车辆终端网关基于EMQ下发MQTT远程诊断任务的开启指令，并设置一个预定超时时间以监控车端的响应状态。

在一些实施例中，图2的链接模块202利用车载通信模块发起基于TCP的链接请求到云端的云端通信组件端口，车载通信模块以UDP方式发送车辆声明信息至云端，其中，车辆声明信息中包含车辆识别号码；在TCP链接建立之后，云端通信组件通过TCP请求车辆信息，车载通信模块通过TCP向云端通信组件返回所请求的车辆信息；在云端通信组件接收到车辆信息后，通过消息中间件将链接成功的响应消息发送至远程诊断转发模块，当远程诊断转发模块接收到响应消息后，调用后台管理服务的链接成功请求，并在同步接收到后台管理服务的响应后，发起链路激活请求。

在一些实施例中，图2的激活模块203利用后台管理服务将车辆的诊断状态更新为路由激活中，并利用消息中间件将链路激活请求发送给远程诊断转发模块；远程诊断转发模块利用消息中间件进行链路激活请求的发起，并在云端通信组件中利用TCP基于DOIP协议格式进行路由激活请求，并同步获取路由激活响应；将路由激活响应传送给远程诊断转发模块，以使远程诊断转发模块向后台管理服务发起建链响应请求。

在一些实施例中，图2的解析模块204当车辆的远程诊断任务状态为激活成功时，触发对远程诊断请求的解析操作，其中，远程诊断请求中包含诊断指令和相关文件信息；云端通信组件利用已建立的长链接，根据DOIP协议将远程诊断任务指令封装为UDS指令并发送给云端通信组件；云端通信组件将UDS指令发送给车端，以使车端接收UDS指令后同步返回响应，并使车端发送响应内容。

在一些实施例中，图2的诊断模块205还用于云端通信组件接收到车端返回的响应内容后，通过消息中间件将响应内容传递给远程诊断协议解析模块，远程诊断协议解析模块对接收到的响应内容进行解析，并调用后台管理服务的接口进行处理；在后台管理服务中，根据解析得到的响应结果，对远程诊断任务状态进行更新，当响应结果为成功时，将远程诊断任务状态更新为成功，当响应结果为失败时，将远程诊断任务状态更新为失败。

在一些实施例中，图2的诊断模块205还用于为每个整车控制器对应的远程故障诊断配置一个远程诊断任务，将所有远程诊断任务组成整车远程诊断任务集合；为每个所述远程诊断任务分配优先级，所述优先级用于表征远程诊断任务的重要程度，所述优先级由故障等级、历史故障次数平均值以及历史故障读取总次数经过计算得到；利用预先定义的目标函数作为对整车远程诊断任务集合进行任务编排的优化目标，对目标函数进行优化，以便根据优先级执行所述远程诊断任务，且最小化总的执行时间；其中，所述历史故障读取总次数由车端上报的故障告警报文分析得到，所述远程诊断任务包括故障编码诊断任务和故障数据诊断任务，所述故障等级包括故障编码的故障等级。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

图3是本申请实施例提供的电子设备3的结构示意图。如图3所示，该实施例的电子设备3包括：处理器301、存储器302以及存储在该存储器302中并且可以在处理器301上运行的计算机程序303。处理器301执行计算机程序303时实现上述各个方法实施例中的步骤。或者，处理器301执行计算机程序303时实现上述各装置实施例中各模块/单元的功能。

示例性地，计算机程序303可以被分割成一个或多个模块/单元，一个或多个模块/单元被存储在存储器302中，并由处理器301执行，以完成本申请。一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述计算机程序303在电子设备3中的执行过程。

电子设备3可以是桌上型计算机、笔记本、掌上电脑及云端服务器等电子设备。电子设备3可以包括但不仅限于处理器301和存储器302。本领域技术人员可以理解，图3仅仅是电子设备3的示例，并不构成对电子设备3的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如，电子设备还可以包括输入输出设备、网络接入设备、总线等。

处理器301可以是中央处理单元（Central Processing Unit，CPU），也可以是其它通用处理器、数字信号处理器（Digital Signal Processor，DSP）、专用集成电路（Application Specific Integrated Circuit，ASIC）、现场可编程门阵列（Field-Programmable Gate Array，FPGA）或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器302可以是电子设备3的内部存储单元，例如，电子设备3的硬盘或内存。存储器302也可以是电子设备3的外部存储设备，例如，电子设备3上配备的插接式硬盘，智能存储卡（Smart Media Card，SMC），安全数字（Secure Digital，SD）卡，闪存卡（Flash Card）等。进一步地，存储器302还可以既包括电子设备3的内部存储单元也包括外部存储设备。存储器302用于存储计算机程序以及电子设备所需的其它程序和数据。存储器302还可以用于暂时地存储已经输出或者将要输出的数据。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的实施例中，应该理解到，所揭露的装置/计算机设备和方法，可以通过其它的方式实现。例如，以上所描述的装置/计算机设备实施例仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，计算机程序可以存储在计算机可读存储介质中，该计算机程序在被处理器执行时，可以实现上述各个方法实施例的步骤。计算机程序可以包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读介质可以包括：能够携带计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器（Read-Only Memory，ROM）、随机存取存储器（Random Access Memory，RAM）、电载波信号、电信信号以及软件分发介质等。

以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (11)

1.一种车联网远程诊断方法，其特征在于，包括：

利用云端的管理界面选择远程诊断任务，并向车端发送远程诊断任务请求，根据车端对所述远程诊断任务请求的反馈，判断是否开启远程诊断任务；

当车端接收到开启远程诊断任务的指令后，利用车载通信模块向云端发送链接请求，并利用云端将链接成功的响应消息发送给远程诊断转发模块；

远程诊断转发模块根据接收到的响应消息发起链路激活请求，更新车辆远程诊断任务状态为激活成功，并触发远程诊断请求；

将所述远程诊断请求通过消息中间件发送给远程诊断协议解析模块，利用所述远程诊断协议解析模块对所述远程诊断请求进行解析，生成远程诊断任务指令，并将所述远程诊断任务指令发送给云端通信组件；

利用所述云端通信组件通过已建立的长链接向车端发送所述远程诊断任务指令，并接收车端返回的响应内容，利用所述远程诊断协议解析模块对所述响应内容进行解析，得到远程诊断结果。

2.根据权利要求1所述的方法，其特征在于，所述利用云端的管理界面选择远程诊断任务，并向车端发送远程诊断任务请求，包括：

在所述云端的web管理界面选择远程诊断任务，确定所述远程诊断任务对应的类型和车系，利用后台管理服务调用设备中心请求接口，以便向所述车端发送所述远程诊断任务请求；

其中，所述远程诊断任务对应的诊断接口包括读取整车故障码、读取整车数据、读取ECU故障码和/或读取ECU数据流。

3.根据权利要求2所述的方法，其特征在于，所述利用后台管理服务调用设备中心请求接口，以便向所述车端发送所述远程诊断任务请求，包括：

利用所述后台管理服务通过设备中心请求接口发送调用所述远程诊断任务请求的命令，启动超时计时，若在预设的时间内未收到车端的反馈，再次发送调用所述远程诊断任务请求的命令，当未收到车端反馈的次数超过预设次数时，将远程诊断记录状态更新为超时，并发送提示；

利用消息中间件，将车辆终端网关与用于远程诊断协议解析及转发的远程诊断协议解析模块进行双向通讯，所述车辆终端网关基于EMQ下发MQTT远程诊断任务的开启指令，并设置一个预定超时时间以监控车端的响应状态。

4.根据权利要求1所述的方法，其特征在于，所述利用车载通信模块向云端发送链接请求，并利用云端将链接成功的响应消息发送给远程诊断转发模块，包括：

利用所述车载通信模块发起基于TCP的链接请求到云端的云端通信组件端口，所述车载通信模块以UDP方式发送车辆声明信息至云端，其中，所述车辆声明信息中包含车辆识别号码；

在TCP链接建立之后，所述云端通信组件通过TCP请求车辆信息，所述车载通信模块通过TCP向所述云端通信组件返回所请求的车辆信息；

在所述云端通信组件接收到所述车辆信息后，通过消息中间件将链接成功的响应消息发送至所述远程诊断转发模块，当所述远程诊断转发模块接收到所述响应消息后，调用后台管理服务的链接成功请求，并在同步接收到所述后台管理服务的响应后，发起链路激活请求。

5.根据权利要求4所述的方法，其特征在于，所述远程诊断转发模块根据接收到的响应消息发起链路激活请求，更新车辆远程诊断任务状态为激活成功，并触发远程诊断请求，包括：

利用后台管理服务将车辆的诊断状态更新为路由激活中，并利用消息中间件将所述链路激活请求发送给所述远程诊断转发模块；

所述远程诊断转发模块利用消息中间件进行链路激活请求的发起，并在所述云端通信组件中利用TCP基于DOIP协议格式进行路由激活请求，并同步获取路由激活响应；

将路由激活响应传送给所述远程诊断转发模块，以使所述远程诊断转发模块向所述后台管理服务发起建链响应请求。

6.根据权利要求1所述的方法，其特征在于，所述利用所述远程诊断协议解析模块对所述远程诊断请求进行解析，生成远程诊断任务指令，并将所述远程诊断任务指令发送给云端通信组件，包括：

当车辆的远程诊断任务状态为激活成功时，触发对所述远程诊断请求的解析操作，其中，所述远程诊断请求中包含诊断指令和相关文件信息；

所述云端通信组件利用已建立的长链接，根据DOIP协议将所述远程诊断任务指令封装为UDS指令并发送给所述云端通信组件；

所述云端通信组件将所述UDS指令发送给车端，以使所述车端接收所述UDS指令后同步返回响应，并使所述车端发送响应内容。

7.根据权利要求6所述的方法，其特征在于，所述利用所述云端通信组件通过已建立的长链接向车端发送所述远程诊断任务指令，并接收车端返回的响应内容，利用所述远程诊断协议解析模块对所述响应内容进行解析，得到远程诊断结果，包括：

所述云端通信组件接收到车端返回的响应内容后，通过消息中间件将所述响应内容传递给远程诊断协议解析模块，所述远程诊断协议解析模块对接收到的响应内容进行解析，并调用后台管理服务的接口进行处理；

在所述后台管理服务中，根据解析得到的响应结果，对远程诊断任务状态进行更新，当响应结果为成功时，将远程诊断任务状态更新为成功，当响应结果为失败时，将远程诊断任务状态更新为失败。

8.根据权利要求7所述的方法，其特征在于，所述远程诊断协议解析模块对接收到的响应内容进行解析，并调用所述后台管理服务的接口进行处理，包括：

为每个整车控制器对应的远程故障诊断配置一个远程诊断任务，将所有远程诊断任务组成整车远程诊断任务集合；

为每个所述远程诊断任务分配优先级，所述优先级用于表征远程诊断任务的重要程度，所述优先级由故障等级、历史故障次数平均值以及历史故障读取总次数经过计算得到；

利用预先定义的目标函数作为对所述整车远程诊断任务集合进行任务编排的优化目标，对所述目标函数进行优化，以便根据所述优先级执行所述远程诊断任务，且最小化总的执行时间；

其中，所述历史故障读取总次数由车端上报的故障告警报文分析得到，所述远程诊断任务包括故障编码诊断任务和故障数据诊断任务，所述故障等级包括故障编码的故障等级。

9.一种车联网远程诊断装置，其特征在于，包括：

请求模块，被配置为利用云端的管理界面选择远程诊断任务，并向车端发送远程诊断任务请求，根据车端对所述远程诊断任务请求的反馈，判断是否开启远程诊断任务；

链接模块，被配置为当车端接收到开启远程诊断任务的指令后，利用车载通信模块向云端发送链接请求，并利用云端将链接成功的响应消息发送给远程诊断转发模块；

激活模块，被配置为远程诊断转发模块根据接收到的响应消息发起链路激活请求，更新车辆远程诊断任务状态为激活成功，并触发远程诊断请求；

解析模块，被配置为将所述远程诊断请求通过消息中间件发送给远程诊断协议解析模块，利用所述远程诊断协议解析模块对所述远程诊断请求进行解析，生成远程诊断任务指令，并将所述远程诊断任务指令发送给云端通信组件；

诊断模块，被配置为利用所述云端通信组件通过已建立的长链接向车端发送所述远程诊断任务指令，并接收车端返回的响应内容，利用所述远程诊断协议解析模块对所述响应内容进行解析，得到远程诊断结果。

10.一种电子设备，包括存储器，处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如权利要求1至8中任一项所述的方法。

11.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至8中任一项所述的方法。