车云诊断方法、装置、车辆及存储介质

技术领域

本申请实施例涉及车云通信技术领域，特别地，涉及一种车云诊断方法、装置、车辆及存储介质。

背景技术

目前的车云通信协议主要是基于消息队列遥测传输协议(Message QueuingTelemetry Transport，MQTT)实现的。云端部署MQTT代理服务器，车端的远程信息处理器(TelematicsBOX，TBOX)集成MQTT客户端，使得远程诊断服务器和车辆可以进行通信，远程诊断服务器可以在一定程度上控制车辆，例如，远程解闭锁和远程开空调。

对于远程故障诊断功能，车载TBOX软件集成所有的统一诊断服务(UnifiedDiagnostic Services，UDS)和诊断参数，例如，0x14清除故障码服务和0x2E服务写功能配置码(Data Identifier，DID)。其中，DID是2个字节的无符号整数的ID，用于标识电子控制单元(Electronic Control Unit)中存储的某个诊断数据单元。

然而，随着车辆功能的多样化，车上部署的ECU数量越来越多，车载TBOX难以集成所有的ECU的诊断参数。此外，量产后的ECU参数一旦发生变更(例如新增DID)，车载TBOX需要进行软件进行修改或增设，以对变更的ECU参数进行适配。即目前的远程故障诊断方式车端软件的适配周期长、成本高且远程诊断效率低下。

发明内容

本申请实施例提供一种车云诊断方法、装置、车辆及存储介质，以改善上述问题。

第一方面，本申请实施例提供一种车云诊断方法。该方法包括：获取远程诊断服务器发送的SOME/IP请求报文，所述SOME/IP请求报文包括诊断脚本，所述诊断脚本采用非编译性语言；解析并运行所述SOME/IP请求报文中的所述诊断脚本，得到诊断结果；将所述诊断结果封装为SOME/IP应答报文，发送至所述远程诊断服务器，以使所述远程诊断服务器根据所述诊断结果进行对应的业务逻辑处理。

第二方面，本申请实施例提供一种车云诊断装置。该装置包括：报文获取模块，用于获取远程诊断服务器发送的SOME/IP请求报文，所述SOME/IP请求报文包括诊断脚本，所述诊断脚本采用非编译性语言；脚本运行模块，用于解析并运行所述SOME/IP请求报文中的所述诊断脚本，得到诊断结果；报文发送模块，用于将所述诊断结果封装为SOME/IP应答报文，发送至所述远程诊断服务器，以使所述远程诊断服务器根据所述诊断结果进行对应的业务逻辑处理。

第三方面，本申请实施例提供一种车辆。该车辆包括存储器、一个或多个处理器以及一个或多个应用程序。其中，一个或多个应用程序被存储在存储器中，并被配置为当被一个或多个处理器调用时，使得一个或多个处理器执行本申请实施例提供的方法。

第四方面，本申请实施例提供一种计算机可读取存储介质。该计算机可读取存储介质中存储有程序代码，该程序代码被配置为当被处理器调用时，使得处理器执行本申请实施例提供的方法。

本申请实施例提供一种车云诊断方法、装置、车辆及存储介质，该方法通过SOME/IP报文携带采用非编译性语言的诊断脚本，在车端部署诊断脚本运行环境，对诊断脚本进行解析并运行，并将诊断结果通过SOME/IP报文发送至远程诊断服务器，可以减少车端软件适配周期及开发成本，提高远程诊断效率。

附图说明

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

图1是本申请一示例性实施例提供的车云诊断方法的应用场景的示意图；

图2是本申请一示例性实施例提供的现有MQTT消息的示意图；

图3是本申请一示例性实施例提供的本申请实施例采用的MQTT消息的示意图；

图4是本申请一实施例提供的车云诊断方法的流程示意图；

图5是本申请另一实施例提供的车云诊断方法的流程示意图；

图6是本申请一示例性实施例提供的车云诊断方法的时序流程图；

图7是本申请一实施例提供的车云诊断装置的结构框图；

图8是本申请一实施例提供的车辆的结构框图；

图9是本申请一实施例提供的计算机可读取存储介质的结构框图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

请参阅图1，图1是本申请一示例性实施例提供的车云诊断方法的应用场景的示意图。车云诊断系统100包括中央控制单元(Central Control Unit，CCU)110、车载TBOX120以及远程诊断服务器130。

CCU110与车载TBOX120之间通过以太网进行通信。CCU110和车载TBOX120支持运行于网际协议(Internet Protocol，IP)之上的可伸缩的面向服务的中间件(Scalableservice-Oriented MiddlewarE over IP，SOME/IP)，CCU110和车载TBOX120可以相互传输SOME/IP报文。

车载TBOX120通过MQTT车云协议与远程诊断服务器130通信。本申请实施例中的MQTT车云协议的payload内封装有SOME/IP服务化接口通信协议，以实现车载TBOX120和远程诊断服务器130可以采用消息发布与订阅的方式通过MQTT消息传输SOME/IP报文。SOME/IP报文中的payload内可以封装诊断脚本，以便CCU110运行诊断脚本以实现诊断服务。

CCU110可以包括多个CCU，各CCU之间可以通过预设接口函数(将在后面展开描述)进行通信。CCU110中部署有诊断脚本的运行环境，例如Python运行环境。

在对本申请实施例提供的车云诊断方法进行介绍之前，首先需要说明的是本申请实施例采用的MQTT车云协议的MQTT消息与现有的MQTT消息的不同之处。

请参阅图2，图2是本申请一示例性实施例提供的现有MQTT消息的示意图。现有的MQTT消息包括MQTT报头和数据有效载荷报文内容(MQTT payload)。MQTT报头包括固定报头和可变报头。

固定报头的长度为2个字节，固定报头包括多种MQTT控制报文类型，具体的MQTT控制报文类型及其相关信息请见表1。表1中的“QoS”全称为Quality of Service，含义为服务质量。“客户端->服务端”表示报文数据从客户端流向服务器。“服务端->客户端”表示报文数据从服务端流向客户端。“服务端<->客户端”表示报文数据既可以从服务端流向客户端，也可以从客户端流向服务端。

表1

可变报头是某些控制报文具有的信息，对于不同报文类型可变报头的内容不同。例如，对于发布消息PUBLISH类型的报文，可变报头的可是为主题名“topic”+报文标识符。主题名为自定义字符串，例如“远程诊断”。报文标识符为建立连接后，每次发消息会累加的计数器(初始值为1)。

如图2所示，MQTT payload封装的是UDS诊断服务。

请参阅图3，图3是本申请一示例性实施例提供的本申请实施例采用的MQTT消息的示意图。本申请实施例采用的MQTT消息在现有的MQTT消息的payload内封装有SOME/IP服务化接口通信协议。

如图3所示，MQTT报头的可变报头采用的是SOME/IP报文中的消息标识符(MessageID)。MQTT payload部分封装的是SOME/IP报文。SOME/IP报文包括SOME/IP报头和SOME/IP数据有效载荷报文内容(SOME/IP payload)。

图3虚线箭头所指为SOME/IP数据帧。SOME/IP报头包括消息标识符、长度、请求ID(也可以是应答ID)、协议版本、接口版本、消息类型以及返回码。SOME/IP payload内可以封装诊断脚本。

结合图2和图3可见，本申请实施例采用的MQTT消息与现有的MQTT消息存在以下区别：

区别1：现有的MQTT消息的“Variable header”采用的是报文标识符(例如“远程诊断”)。然，本申请实施例采用的MQTT消息的“Variable header”采用的是消息标识符“Message ID”。

区别2：现有的MQTT消息的“MQTT payload”内封装的是UDS诊断服务(诊断请求/诊断应答)，只能逐条发送指令。然，本申请实施例采用的MQTT消息的“MQTT payload”内封装的是SOME/IP报文，而不是单一的UDS诊断服务。且SOME/IP报文的“SOME/IP payload”内可以封装诊断脚本。

接下来将对本申请实施例提供的车云诊断方法进行详细阐述。请参阅4，图4是本申请一实施例提供的车云诊断方法的流程示意图。该车云诊断方法可以应用于上述图1所示的车云诊断系统100中的CCU110，或下面将会提到的图7所示的车云诊断装置200，或下面将会提到的图8所示的车辆300。该车云诊断方法可以包括以下步骤S110-S130。

步骤S110，获取远程诊断服务器发送的SOME/IP请求报文，其中，SOME/IP请求报文包括诊断脚本，诊断脚本采用非编译性语言(例如Python)。

其中，SOME/IP请求报文的报文类型为Request。如前所述，SOME/IP请求报文封装在MQTT消息的MQTT payload内。

其中，诊断脚本是一系列诊断服务的集合体，例如，诊断脚本可以是含顺序执行和跳转控制逻辑的程序代码集。诊断脚本可以根据不同的诊断场景进行设计并通过远程诊断服务器发布。作为一种示例，远程诊断需要修改车内控制单元A的诊断配置码(DID-0100，长度为2个字节)，诊断脚本可以包括以下步骤1)-8)：

1)进入扩展模式，对应诊断请求：02 10 03 AA AA AA AA AA。

2)进入扩展模式，对应诊断应答：06 50 03 XX XX XX XX AA。

3)过安全访问控制，请求种子，对应诊断请求：02 27 01 AA AA AA AA AA。

4)过安全访问控制，请求种子，对应诊断应答：06 67 01 XX XX XX XX AA。

5)过安全访问控制，发送密钥，对应诊断请求：06 27 02 XX XX XX XX AA。

6)过安全访问控制，发送密钥，对应诊断应答：02 67 02 AA AA AA AA AA。

7)写入诊断配置码，对应诊断请求：05 2E 01 00 XX XX AA AA。

8)写入诊断配置码，对应诊断应答：03 6E 01 00 AA AA AA AA。

若上述步骤1)-8)中的任一步骤运行失败(例如控制器回复了否定应答)，则诊断脚本会记录错误状态，直到全部步骤执行结束。通过诊断脚本的嵌套、循环以及跳转逻辑配合使用，可以实现复杂的诊断脚本，从而可以实现远程诊断功能的灵活扩展。

此外，相比于现有技术在车载TBOX软件内预先编译并存储的UDS诊断服务和参数形成的软件代码，本申请实施例采用的通过非编译性语言Python实现的诊断脚本具有以下技术效果：

1、本申请实施例的诊断脚本可以根据不同的诊断场景进行设计，为售后提供定制化远程诊断功能与体验。

2、通过非编译性语言实现的诊断脚本具备灵活性，无需变更车端控制器(CCU)的软件，缩短车端软件适配的开发周期和成本；

3、如前所述，本申请实施例中的CCU内部署有Python运行环境，诊断脚本是在CCU中运行的，不受车云通信网络的影响，可以避免逐条诊断指令传输过程因网速波动或车辆状态改变引起的诊断任务失败，从而可以确保诊断通信稳定，减少诊断通信超时，提升远程诊断成功率；

4、诊断脚本由远程诊断服务器生成，在正式发布使用前，可以利用云平台进行大量的仿真测试验证，从而可以减少程序运行出错几率，进而提高远程诊断效率。

在一些实施方式中，车载TBOX与远程诊断服务器建立MQTT长连接之后，车载TBOX与远程诊断服务器之间通过消息发布与应答机制进行收发MQTT消息。远程诊断服务器可以发布MQTT消息，MQTT消息中包括SOME/IP请求报文，SOME/IP请求报文中包括诊断脚本。车载TBOX接收MQTT消息后，从MQTT消息的payload中提取出SOME/IP请求报文。车载TBOX在检测到车辆上电后，与CCU建立SOME/IP通信，并将SOME/IP请求报文通过以太网发送至CCU。CCU可以接收SOME/IP请求报文。

步骤S120，解析并运行SOME/IP请求报文中的诊断脚本，得到诊断结果。

在一些实施方式中，步骤S120的具体实施方式可以包括以下步骤：对SOME/IP请求报文进行解析，得到诊断脚本；采用Python和预设接口函数运行诊断脚本，得到诊断结果。

在一些实施方式中，对SOME/IP请求报文进行解析，得到诊断脚本的具体实施方式可以包括以下步骤：对SOME/IP请求报文的报文类型进行检测；若报文类型与预设报文类型相同，从SOME/IP报文中提取诊断脚本；在诊断脚本通过完整性验证时，存储诊断脚本，以避免重复下载所述诊断脚本。通过存储诊断脚本，可以在网络环境差的情况下，方便本地触发快速启动，从而可以提高问题排查响应速度，提升用户体验感。此外，车端存储诊断脚本，可以实现车辆零部件、元器件的统计数据分析，提供设计改善、保存、运输和供应商的选择依据。

其中，预设报文类型可以是请求报文类型，例如，预设报文类型为Request。CCU可以读取SOME/IP请求报文中的信息类型中的值作为报文类型，并将该报文类型与预设报文类型进行比对，以确定报文类型是否与预设报文类型相同。

CCU可以从SOME/IP报文的SOME/IP payload中提取诊断脚本，并对提取到的诊断脚本进行完整性验证。其中完整性验证可以采用解密验签方式进行验证，具体验证方式请参阅相关技术，在此不展开描述。

在诊断脚本通过完整性验证之后，CCU启动Python诊断脚本程序，运行诊断脚本并生成诊断结果，诊断结果可以是JSON文件。其中，运行诊断脚本具体可以通过调用诊断脚本中的预设接口函数实现。

在一些实施方式中，预设接口函数包括第一类预设接口函数，也即底层诊断报文收发接口函数。第一类预设接口函数用于实现中央控制单元底层诊断报文收发功能，与具体某个UDS诊断服务或诊断参数无关。

在一些实施方式中，第一类预设接口函数包括以下函数：

1、发送诊断报文函数TransmitMessage；

2、发送诊断报文并接收诊断应答函数TransmitAndReceive；

3、功能寻址发送诊断报文函数FunctionalTransmitMessage；

4、周期性的诊断会话保持函数TesterPresent。

在此以发送诊断报文函数TransmitMessage为例详细说明该函数的输入输出参数名称、类型以及函数运行逻辑。其他函数类似，可参阅关于该函数的说明。TransmitMessage为发送诊断报文函数的函数名称。发送诊断报文函数的输入参数如表2所示，发送诊断报文函数的输出参数如表3所示。其中，表2中的DOIP全称为“Diagnostic communication overInternet Protocol”，含义是基于IP的诊断通信。表2中的LIN全称为“Local InterconnectNetwork”，含义为局域互联网络。表2中的NAD全称为“Node Address for Diagnose”，含义为诊断地址。

表2

表3

发送诊断报文函数的运行逻辑包括以下步骤1)-6)：

1)将ErrorMessage设置为空字符串，将IsRequestSuccess设置为False。

2)检查RequestID是否为0或者是否未初始化。

若RequestID为0或RequestID未初始化，则返回以下内容并结束函数：

ErrorMessage＝“InalidRequestID”

IsRequestSuccess＝false

若RequestID不为0或RequestID已初始化，则执行步骤3)。

3)检查FrameType是否为Enum FrameType且数值是否为0-5中的其中一个。

若FrameType不是Enum FrameType，或FrameType为Enum FrameType但其数值不为0-5中的其中一个，则返回以下内容并结束函数：

ErrorMessage＝“InalidFrameType”

IsRequestSuccess＝false

若FrameType为Enum FrameType且其数值为0-5中的其中一个，则执行步骤4)。

4)检查RequestFrame是否为空或是否未初始化。

若RequestFrame为空或未初始化，则返回以下内容并结束函数：

ErrorMessage＝“InalidRequestFrame”

IsRequestSuccess＝false

若RequestFrame不为空或已初始化，则执行步骤5)。

5)使用指定的RequestID，FrameType，RequestFrame向ECU发送报文。

若发送失败，则返回以下内容并结束函数：

ErrorMessage＝“TransmitRequestFrameFailed”

IsRequestSuccess＝false

若发送成功，则执行步骤6)。

6)返回以下内容：

ErrorMessage＝“”

IsRequestSuccess＝true

在一些实施方式中，预设接口函数还包括第二类预设接口函数，也即车云诊断交互接口函数。第二类预设接口函数用于实现远程诊断服务器与中央控制单元之间的用户界面交互功能。第二类预设接口函数在诊断脚本运行的过程中被调用时，使得远程诊断服务器可以通过用户交互界面输入诊断信息。

在一些实施方式中，第二类预设接口函数包括以下函数：

1、远程诊断服务器向车端输入的诊断交互函数InputBox；

2、车端向远程诊断服务器输出的诊断交互函数MessageBox；

3、远程诊断服务器以下拉列表选择方式向车端输入的诊断交互函数SelectionList。

其中，InputBox为远程诊断服务器向车端输入的诊断交互函数的函数名称。InputBox函数的输入参数如表4所示，输出参数如表5所示。

表4

表5

MessageBox为车端向远程诊断服务器输出的诊断交互函数的函数名称。该函数的输入参数如表6所示，输出参数如表7所示。

表6

表7

其中，SelectionList为远程诊断服务器以下拉列表选择方式向车端输入的诊断交互函数的函数名称。SelectionList函数的输入参数如表8所示，输出参数如表9所示。

表8

表9

步骤S130，将诊断结果封装为SOME/IP应答报文，发送至远程诊断服务器，以使远程诊断服务器根据诊断结果进行对应的业务逻辑处理。

CCU将诊断结果(JSON文件)封装到SOME/IP应答报文的SOME/IP payload内，设置SOME/IP应答报文的报文类型为Response，形成完整的SOME/IP应答报文。CCU将完整的SOME/IP应答报文发送至车载TBOX。车载TBOX接收到SOME/IP应答报文后，将SOME/IP应答报文封装到MQTT消息的MQTT payload内，并发布MQTT消息。远程诊断服务器订阅MQTT消息，从MQTT payload中提取SOME/IP应答报文，从SOME/IP应答报文的SOME/IP payload中提取诊断结果(JSON文件)，解析诊断结果并进行对应的业务逻辑处理(例如，显示“配置码修改成功”)。

需要说明的是，本申请实施例中的SOME/IP请求报文和SOME/IP应答报文的主题相同，携带SOME/IP请求报文的MQTT消息和携带SOME/IP应答报文的MQTT消息的主题相同。例如，主题均为“远程诊断服务”。

本申请实施例提供的车云诊断方法通过SOME/IP报文携带采用非编译性语言的诊断脚本，在车端部署诊断脚本运行环境，对诊断脚本进行解析并运行，并将诊断结果通过SOME/IP报文发送至远程诊断服务器，可以减少车端软件适配周期及开发成本，提高远程诊断效率。

请参阅图5，图5是本申请另一实施例提供的车云诊断方法的流程示意图。该车云诊断方法可以应用于上述图1所示的车云诊断系统100中的CCU110，或下面将会提到的图7所示的车云诊断装置200，或下面将会提到的图8所示的车辆300。该车云诊断方法可以包括以下步骤S210-S240。

步骤S210，通过以太网获取车载TBOX发送的SOME/IP请求报文。

其中，SOME/IP请求报文是车载TBOX向远程诊断服务器订阅第一MQTT消息并解析第一MQTT消息得到的，第一MQTT消息的主题为远程诊断服务，第一MQTT消息携带SOME/IP请求报文，SOME/IP请求报文包括诊断脚本，诊断脚本采用非编译性语言。

步骤S220，解析并运行SOME/IP请求报文中的诊断脚本，得到诊断结果。

步骤S230，将诊断结果封装为SOME/IP应答报文。

步骤S240，通过车载TBOX将SOME/IP应答报文发送至远程诊断服务器。

其中，车载TBOX通过将SOME/IP应答报文封装为第二MQTT消息发布至远程诊断服务器，第二MQTT消息的主题为远程诊断服务，第二MQTT消息携带SOME/IP应答报文。

步骤S210-S240中未详细描述的部分请参阅前述步骤S110-S130的对应部分，在此不再赘述。

本申请实施例提供的车云诊断方法通过SOME/IP报文携带采用非编译性语言的诊断脚本，在车端部署诊断脚本运行环境，对诊断脚本进行解析并运行，并将诊断结果通过SOME/IP报文发送至远程诊断服务器，可以减少车端软件适配周期及开发成本，提高远程诊断效率。

为便于理解，在此提供一示例性实施例，具体请参阅图6，图6是本申请一示例性实施例提供的车云诊断方法的时序流程图。该车云诊断方法可以应用于上述图1所示的车云诊断系统100。该车云诊断方法可以包括以下步骤S1-S11。

步骤S1，车载TBOX通过4G/5G网络向远程诊断服务器发送CONNECT报文，请求建立MQTT长连接。

步骤S2，远程诊断服务器发布第一MQTT消息。

其中，第一MQTT消息的主题为“远程诊断服务(Message ID为0xFFFFFFFF)”。

步骤S3，车载TBOX订阅第一MQTT消息。

步骤S4，车辆上电唤醒后，车载TBOX与CCU建立SOME/IP通信，将主题“远程诊断服务(Message ID为0xFFFFFFFF)”转发给CCU。

步骤S5，远程诊断服务器发布第二MQTT消息。

其中，第二MQTT消息的主体依然为“远程诊断服务(Message ID为0xFFFFFFFF)”。第二MQTT消息的payload中封装有SOME/IP请求报文。SOME/IP请求报文的报文类型为“Request(表征远程诊断服务器请求下载诊断脚本)”。SOME/IP请求报文的payload携带诊断脚本(例如具有“远程修改诊断配置码”的诊断脚本)。其中，诊断脚本可以由远程诊断服务器生成。

步骤S6，车载TBOX接收到第二MQTT消息后，从第二MQTT消息的payload中提取SOME/IP请求报文，将SOME/IP请求报文通过以太网转发给CCU。

步骤S7，CCU接收SOME/IP请求报文，在验证SOME/IP请求报文的报文类型为Request后，从SOME/IP请求报文的payload中提取诊断脚本，验证诊断脚本的完整性，将高频使用且验证无误的诊断脚本存储在车端，避免后续重复下载。

步骤S8，CCU在检测到当前车辆车况安全时，启动Python诊断脚本程序，运行诊断脚本，运行完毕后生成诊断结果(例如JSON文件)。

需要说明的是，对于复杂的诊断脚本，运行诊断脚本的过程中可能存在需要远程诊断服务器输入参数的需求，此时可以重复步骤S5-S8，其中，CCU和远程诊断服务器通过诊断脚本中的预设接口函数实现远程诊断服务器的参数输入功能。

步骤S9，CCU将诊断结果封装在SOME/IP应答报文的payload内，设置SOME/IP应答报文的报文类型为Response，将SOME/IP应答报文反馈给车载TBOX。

步骤S10，车载TBOX在接收到SOME/IP应答报文后，将SOME/IP应答报文封装进第三MQTT消息的payload内，发布第三MQTT消息。

其中，第三MQTT消息的主题仍然为“远程诊断服务(Message ID为0xFFFFFFFF)”。

步骤S11，远程诊断服务器接收第三MQTT消息后，从第三MQTT消息中提取SOME/IP应答报文，从SOME/IP应答报文的payload中提取诊断结果，解析诊断结果并进行对应的业务逻辑处理(例如，显示“配置码修改成功”)。

本申请实施例提供的车云诊断方法通过SOME/IP报文携带采用非编译性语言的诊断脚本，在车端部署诊断脚本运行环境，对诊断脚本进行解析并运行，并将诊断结果通过SOME/IP报文发送至远程诊断服务器，可以减少车端软件适配周期及开发成本，提高远程诊断效率。

请参阅图7，图7是本申请一实施例提供的车云诊断装置的结构框图。该车云诊断装置200可以应用于上述车云诊断系统100中的CCU110，或下面将会提到的车辆300。车云诊断装置200包括相互通信连接的报文获取模块210、脚本运行模块220以及报文发送模块230。

报文获取模块210，用于获取远程诊断服务器发送的SOME/IP请求报文，所述SOME/IP请求报文包括诊断脚本，所述诊断脚本采用非编译性语言；

脚本运行模块220，用于解析并运行所述SOME/IP请求报文中的所述诊断脚本，得到诊断结果；

报文发送模块230，用于将所述诊断结果封装为SOME/IP应答报文，发送至所述远程诊断服务器，以使所述远程诊断服务器根据所述诊断结果进行对应的业务逻辑处理。

在一些实施方式中，脚本运行模块220，还用于对所述SOME/IP请求报文进行解析，得到所述诊断脚本；采用Python和预设接口函数运行所述诊断脚本，得到诊断结果。

在一些实施方式中，所述预设接口函数包括第一类预设接口函数，所述第一类预设接口函数用于实现中央控制单元底层诊断报文收发功能。

在一些实施方式中，所述预设接口函数还包括第二类预设接口函数，所述第二类预设接口函数用于实现所述远程诊断服务器与所述中央控制单元之间的用户界面交互功能。

在一些实施方式中，脚本运行模块220，还用于对所述SOME/IP请求报文的报文类型进行检测；若所述报文类型与预设报文类型相同，从所述SOME/IP报文中提取所述诊断脚本；在所述诊断脚本通过完整性验证时，存储所述诊断脚本，以避免重复下载所述诊断脚本。

在一些实施方式中，报文获取模块210，还用于通过以太网获取车载TBOX发送的SOME/IP请求报文，其中，所述SOME/IP请求报文是所述车载TBOX向所述远程诊断服务器订阅第一MQTT消息并解析所述第一MQTT消息得到的，所述第一MQTT消息的主题为远程诊断服务，所述第一MQTT消息携带所述SOME/IP请求报文。

在一些实施方式中，报文发送模块230，还用于将所述诊断结果封装为SOME/IP应答报文；通过所述车载TBOX将所述SOME/IP应答报文发送至所述远程诊断服务器，其中，所述车载TBOX通过将SOME/IP应答报文封装为第二MQTT消息发布至所述远程诊断服务器，所述第二MQTT消息的主题为远程诊断服务，所述第二MQTT消息携带所述SOME/IP应答报文。

本领域技术人员可以清楚地了解到，本申请实施例提供的车云诊断装置200可以实现本申请实施例提供的车云诊断方法。上述装置和模块的具体工作过程，可以参阅本申请实施例中的车云诊断方法对应的过程，在此不再赘述。

本申请提供的实施例中，所显示或讨论的模块相互之间的耦合、直接耦合或者通信连接，可以是通过一些接口、装置或模块的间接耦合或通信耦合，可以是电性、机械或其他形式，本申请实施例对此不作限制。

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

请参阅图8，图8是本申请一实施例提供的车辆的结构框图。该车辆300可以包括一个或多个如下部件：存储器310、一个或多个处理器320以及一个或多个应用程序。其中，一个或多个应用程序可以被存储在存储器310中，并被配置为当被一个或多个处理器320调用时，使得一个或多个处理器320执行本申请实施例提供的上述车云诊断方法。

处理器320可以包括一个或多个处理核。处理器320利用各种接口和线路连接整个车辆300内各个部分，用于运行或执行存储在存储器310内的指令、程序、代码集或指令集，以及调用运行或执行存储在存储器310内的数据，执行车辆300的各种功能和处理数据。

在一些实施方式中，处理器320可以采用数字信号处理(Digital SignalProcessing，DSP)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)、可编辑逻辑阵列(Programmable Logic Array，PLA)中的至少一种硬件形式来实现。

在一些实施方式中，处理器320可集成中央处理器(Central Processing Unit，CPU)、图像处理器(Graphics Processing Unit，GPU)和调制解调器中的一种或几种的组合。其中，CPU主要处理操作系统、用户界面和应用程序等；GPU用于负责显示内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成于处理器320中，单独通过一块通信芯片进行实现。

存储器310可以包括随机存储器(Random Access Memory，RAM)，也可以包括只读存储器(Read-Only Memory，ROM)。存储器310可以用于存储指令、程序、代码、代码集或指令集。存储器310可以包括存储程序区和存储数据区。其中，存储程序区可以存储用于实现操作系统的指令、用于实现至少一个功能的指令、用于实现上述各个方法实施例的指令等。存储数据区可以存储车辆300在使用中所创建的数据等。

请参阅图9，图9是本申请一实施例提供的计算机可读取存储介质的结构框图。该计算机可读取存储介质400中存储有程序代码，该程序代码被配置为当被处理器调用时，使得处理器执行本申请实施例提供的上述车云诊断方法。

计算机可读取存储介质400可以是诸如闪存、电可擦除可编辑只读存储器(Electrically-Erasable Programmable Read-Only Memory，EEPROM)、可擦除可编辑只读存储器(Erasable Programmable Read-Only Memory，EPROM)、硬盘或者ROM之类的电子存储器。

在一些实施方式中，计算机可读取存储介质400包括非易失性计算机可读介质(Non-Transitory Computer-Readable Storage Medium，Non-TCRSM)。计算机可读取存储介质400具有执行上述方法中的任何方法步骤的程序代码的存储空间。这些程序代码可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。程序代码可以以适当的形式进行压缩。

综上所述，本申请实施例提供一种车云诊断方法、装置、车辆及存储介质，涉及车云通信技术领域。该方法通过获取远程诊断服务器发送的包括采用非编译性语言的诊断脚本的SOME/IP请求报文；解析并运行SOME/IP请求报文中的诊断脚本，得到诊断结果；将诊断结果封装为SOME/IP应答报文，发送至远程诊断服务器，以使远程诊断服务器根据诊断结果进行对应的业务逻辑处理，从而可以减少车端软件适配周期及开发成本，提高远程诊断效率。

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