CN111474923B - 一种车辆诊断方法、装置、设备 - Google Patents

Abstract

本申请公开了一种车辆诊断方法、装置、设备、介质，该方法包括：获取车辆诊断请求，所述车辆诊断请求包括车辆信息；根据所述车辆诊断请求确定诊断软件的类型和诊断软件需调用的目标接口；确定所述目标接口的构建方式；判断所述目标接口的构建方式与所述诊断软件的类型是否匹配；根据匹配结果执行对应的目标接口调用操作以进行车辆诊断。这样能够实现对不同类型的车辆的诊断，且不同类型的软件可以调用一套接口，便可以在诊断软件的开发和维护中只开发和维护这一套接口，节省了开发的成本以及接口维护的难度，减少了维护工作量。

Description

一种车辆诊断方法、装置、设备

技术领域

本申请涉及车辆诊断技术领域，特别涉及一种车辆诊断方法、装置、设备、介质。

背景技术

随着汽车电子技术的不断发展，电子控制单元(ECU，Electronic Control Unit)在现代汽车中得到了广泛的应用。电子控制单元在提高汽车动力性、经济性、舒适性和安全性的同时，也使得车辆中的电子电气系统越来越复杂，这也促使汽车诊断技术有了更大的发展。现在编写汽车诊断的流程可以使用ISO定义一种标准化的诊断流程格式OTX(OpenTest sequence eXchange format，开放式测试流程格式)，但是OTX出现之前诊断流程都是通过代码来编写汽车诊断流程的，这样就会出现有的车辆在进行诊断的时候需要利用的是代码方式诊断软件，而有的车辆在诊断的时候需要利用的是OTX方式的诊断软件，为了诊断软件可以既支持代码方式有支持OTX方式，现有技术需要在诊断软件内部使用两套诊断软件架构，两套诊断软件独立工作，参见图1所示，为这种结构下各套诊断软件的接口图，每个诊断软件都带有自己的一套接口。在这种架构下两套软件接口都需要进行维护等，就会带来很大的开发和维护成本，而且后期的修改也不方便，如果功能或需求增加就需要修改两套接口库，接口越多越难以维护。

发明内容

有鉴于此，本申请的目的在于提供一种车辆诊断方法、装置、设备、介质，能够完成对不同类型的车辆的诊断，且在诊断软件的开发和维护过程中只需要开发和维护一套接口，节省了开发的成本以及接口维护的难度，减少了维护工作量。其具体方案如下：

第一方面，本申请公开了一种车辆诊断方法，包括：

获取车辆诊断请求，所述车辆诊断请求包括车辆信息；

根据所述车辆诊断请求确定诊断软件的类型和诊断软件需调用的目标接口；

确定所述目标接口的构建方式；

判断所述目标接口的构建方式与所述诊断软件的类型是否匹配；

根据匹配结果执行对应的目标接口调用操作以进行车辆诊断。

可选地，所述根据所述车辆诊断请求确定诊断软件的类型，具体包括：

根据所述车辆信息确定车型信息；

根据所述车型信息确定所述诊断软件的类型，所述诊断软件的类型包括OTX方式诊断软件或代码方式诊断软件。

可选地，在根据所述车辆诊断请求确定诊断软件需调用的目标接口之前，所述方法还包括：

以OTX方式或者代码方式构建接口，所述接口包括诊断协议获取接口、通讯接口、文本获取接口和显示接口。

可选地，所述判断所述目标接口的构建方式与所述诊断软件的类型是否匹配，具体包括：

当所述目标接口的构建方式为OTX方式，所述诊断软件的类型为OTX方式诊断软件；或者当所述目标接口的构建方式为代码方式，所述诊断软件的类型为代码方式诊断软件时，所述目标接口的构建方式与所述诊断软件的类型匹配；

当所述目标接口的构建方式为OTX方式，所述诊断软件的类型为代码方式诊断软件；或者当所述目标接口的构建方式为代码方式，所述诊断软件的类型为OTX方式诊断软件时，所述目标接口的构建方式与所述诊断软件的类型不匹配。

可选地，所述根据匹配结果执行对应的目标接口调用操作以进行车辆诊断，具体包括：

当所述目标接口的构建方式与所述诊断软件的类型匹配时，则直接调用所述目标接口执行所述诊断软件进行车辆诊断；

当所述目标接口的构建方式与所述诊断软件的类型不匹配时，则构建调用指针，通过调用指针调用所述目标接口执行所述诊断软件进行车辆诊断。

第二方面，本申请公开了一种车辆诊断装置，包括：

请求获取模块，用于获取车辆诊断请求，所述车辆诊断请求包括车辆信息；

信息确定模块，用于根据所述车辆诊断请求确定诊断软件的类型和诊断软件需调用的目标接口；

构建方式确定模块，用于确定所述目标接口的构建方式；

匹配判断模块，用于判断所述目标接口的构建方式与所述诊断软件的类型是否匹配；

接口调用模块，用于根据匹配结果执行对应的目标接口调用操作以进行车辆诊断。

可选地，所述信息确定模块，包括：

第一信息确定单元，用于根据所述车辆信息确定车型信息；

第二信息确定单元，用于根据所述车型信息确定所述诊断软件的类型，所述诊断软件的类型包括OTX方式诊断软件或代码方式诊断软件。

可选地，所述车辆诊断装置，还包括：

接口构建模块，用于以OTX方式或者代码方式构建接口，所述接口包括诊断协议获取接口、通讯接口、文本获取接口和显示接口。

可选地，所述匹配判断模块，具体用于：

在所述目标接口的构建方式为OTX方式，所述诊断软件的类型为OTX方式诊断软件；或者当所述目标接口的构建方式为代码方式，所述诊断软件的类型为代码方式诊断软件时，所述目标接口的构建方式与所述诊断软件的类型匹配；

在所述目标接口的构建方式为OTX方式，所述诊断软件的类型为代码方式诊断软件；或者当所述目标接口的构建方式为代码方式，所述诊断软件的类型为OTX方式诊断软件时，所述目标接口的构建方式与所述诊断软件的类型不匹配。

可选地，所述接口调用模块，包括：

第一接口调用单元，用于在所述目标接口的构建方式与所述诊断软件的类型匹配时，则直接调用所述目标接口执行所述诊断软件进行车辆诊断；

第二接口调用单元，用于在所述目标接口的构建方式与所述诊断软件的类型不匹配时，则构建调用指针，通过调用指针调用所述目标接口执行所述诊断软件进行车辆诊断。

第三方面，本申请公开了一种车辆诊断设备，包括：

存储器和处理器；

其中，所述存储器，用于存储计算机程序；

所述处理器，用于执行所述计算机程序，以实现前述公开的车辆诊断方法。

第四方面，本申请公开了一种计算机可读存储介质，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现前述公开的车辆诊断方法。

可见，本申请先获取车辆诊断请求，所述车辆诊断请求包括车辆信息，然后根据所述车辆诊断请求确定诊断软件的类型和诊断软件需调用的目标接口，并确定目标接口的构建方式，接着判断所述目标接口的构建方式与所述诊断软件的类型是否匹配，并根据匹配结果执行对应的目标接口调用操作以进行车辆诊断。由此可见，本申请在获取到车辆诊断请求之后，并可以确定出相应的诊断软件类型以及需要调用的目标接口，并判断目标接口和构建方式和诊断软件的类型是否相匹配，再根据匹配结果进行相应的目标接口调用操作，这样能够实现对不同类型的车辆的诊断，且不同类型的软件可以调用一套接口，便可以在诊断软件的开发和维护中只开发和维护这一套接口，节省了开发的成本以及接口维护的难度，减少了维护工作量。

附图说明

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

图1为本申请公开的一种现有的车辆诊断系统示意图图；

图2为本申请公开的一种车辆诊断方法流程图；

图3为本申请公开的一种具体的车辆诊断方法流程图；

图4为本申请公开的一种车辆诊断系统结构示意图；

图5为本申请公开的一种车辆诊断装置结构示意图；

图6为本申请公开的一种车辆诊断设备结构图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

参见图2所示，本申请实施例公开了一种车辆诊断方法，该方法包括：

步骤S11：获取车辆诊断请求，所述车辆诊断请求包括车辆信息。

在实际应用中，在需要进行车辆诊断时，需要先触发相应的车辆诊断请求，相应的，便需要先获取所述车辆诊断请求，以便根据所述车辆诊断请求进行相应车辆的诊断，其中，所述车辆诊断请求中包括车辆信息，具体的，所述车辆信息可以包括但不限于车型信息、车辆VIN码(Vehicle Identification Number，车辆识别码)信息、带车辆LOGO(车辆徽标)的车辆照片。

步骤S12：根据所述车辆诊断请求确定诊断软件的类型和诊断软件需调用的目标接口。

在获取到所述车辆诊断请求之后，便可以根据所述车辆诊断请求确定需用到的诊断软件的类型和诊断软件需要调用的目标接口。

步骤S13：确定所述目标接口的构建方式。

在确定出所述目标接口之后，还需要确定所述目标接口的构建方式，具体的，所述目标接口的构建方式包括代码方式和/或OTX方式。

步骤S14：判断所述目标接口的构建方式与所述诊断软件的类型是否匹配。

可以理解的是，在确定出所述目标接口的构建方式之后，还需要判断所述目标接口的构建方式与所述诊断软件的类型是否匹配，以便进行相应的目标接口调用操作。

步骤S15：根据匹配结果执行对应的目标接口调用操作以进行车辆诊断。

相应地，在判断所述目标接口的构建方式与所述诊断软件的类型之后，便可以根据匹配结果执行对应的目标接口调用操作，以完成对所述车辆诊断请求对应的待诊断车辆的诊断。

可见，本申请先获取车辆诊断请求，所述车辆诊断请求包括车辆信息，然后根据所述车辆诊断请求确定诊断软件的类型和诊断软件需调用的目标接口，并确定目标接口的构建方式，接着判断所述目标接口的构建方式与所述诊断软件的类型是否匹配，并根据匹配结果执行对应的目标接口调用操作以进行车辆诊断。由此可见，本申请在获取到车辆诊断请求之后，并可以确定出相应的诊断软件类型以及需要调用的目标接口，并判断目标接口和构建方式和诊断软件的类型是否相匹配，再根据匹配结果进行相应的目标接口调用操作，这样能够实现对不同类型的车辆的诊断，且不同类型的软件可以调用一套接口，便可以在诊断软件的开发和维护中只开发和维护这一套目标接口，节省了开发的成本以及接口维护的难度，减少了维护工作量。

参见图3所示，本申请实施例公开了一种车辆诊断方法，该方法包括：

步骤S21：获取车辆诊断请求，所述车辆诊断请求包括车辆信息。

步骤S22：根据所述车辆诊断请求确定诊断软件的类型和诊断软件需调用的目标接口。

在获取到所述车辆诊断请求之后，便可以根据所述车辆诊断请求确定需用到的诊断软件的类型和诊断软件需要调用的目标接口。具体的，根据所述车辆诊断请求确定诊断软件的类型，包括：根据所述车辆诊断请求中的车辆信息确定待诊断车辆的车型信息；根据所述车型信息确定所述诊断软件的类型，其中，所述诊断软件的类型包括OTX方式诊断软件或代码方式诊断软件。具体的，可以是先对所述车辆诊断请求进行解析，得到所述车辆诊断请求中对应的待诊断车辆的车辆信息，在对所述车辆信息进行解析得到车型信息，根据预先保存的车型与诊断软件类型对照表，确定所述车型信息对应的诊断软件的类型。其中，所述预先保存的车型与诊断软件类型对照表可以为按照对照变形式对预先获取到的车型信息和不同车型对应的诊断软件的类型信息进行存储得到。由于OTX的标准是2012年以后才出来的，所以之前的车型都是代码实现的，而在OTX标准使用之后，还是有一部分车辆是在使用代码方式，各个厂商会为不同车型的车辆选择对应的诊断方式，也即车型信息和诊断软件的类型之间存在对应关系，所以便可以根据车型信息确定诊断软件的类型。例如吉利的2020年之前的所有车型都是使用代码实现的，2020起的新车型都是用OTX方式，比如BX12，SX11。

在具体的实施过程中，在所述根据所述车辆诊断请求确定诊断软件需调用的目标接口之前，还需要以OTX方式和/或代码方式构建接口，所述接口包括诊断协议获取接口、通讯接口、文本获取接口和显示接口。

在第一种具体的实施方式中，构建接口可以包括：构建代码方式的诊断协议获取接口、代码方式的显示接口、代码方式的文本获取接口，OTX方式的通讯接口。在实际应用中，诊断协议获取接口作用是用来获取要执行的诊断功能的一些通讯协议数据，比如通讯的类型为CAN协议(Controller Area Network，控制器局域网络协议)，通讯管脚为6、14管脚，通讯波特率为500K，诊断的发送命令为0x22f101等等。代码方式的协议获取一般可以支持很多格式的文件读取，比如XML、txt、bin文件等，比如GetProtocol(string ecu)就是从文件中获取到指定ECU的通讯类型。OTX方式中获取诊断协议获取接口也定义有ISO标准，诊断协议格式参考ISO22901，诊断数据的获取接口参考ISO22900-3标准，诊断协议文件也是标准的XML文件，具体的标准可以参考ISO22901标准文档。代码方式诊断协议获取接口支持多种文件和格式，所以可以使用代码方式诊断协议获取接口来实现OTX的诊断协议文件中的诊断数据查找和获取。而通讯接口的主要作用是为诊断软件和汽车通讯建立通道，并且根据协议的类型对通讯的参数进行设置，然后发送诊断命令到汽车总线，然后从汽车总线接收到回复命令。常见的诊断协议类型有K线、CAN协议、VPW(Variable Pulse WidthModulated，可变脉宽调制)、PWM(Pulse Width Modulation，脉冲宽度调制)、DOIP以太网协议等等，每种通讯协议的通讯参数都不同，比如CAN协议使用车辆OBD(On-BoardDiagnostic，车载诊断系统)接头中的6、14管脚进行通讯，波特率为125-500K，命令的格式举例如下0x05ed200255AA，05表示后面一共有5个字节，ed20为要发送命令的汽车ECU的ID，02表示有效数据有2个，55AA为有效数据，表示要执行的功能，比如读取数据流的值等。OTX出现之前的通讯接口基本上都是自定义的接口，比如CAN协议的设置接口为SetCanCommParam(CommPara cp)，CAN的数据通讯接口为CanSendCmdAndRecAns(RequestBuffer rb,ResponseBuffer resb)。但是因为OTX是ISO标准，为了统一接口，所以OTX需要使用的通讯接口有专门的标准为ISO22900-2D-PDU接口，D-PDU的标准通讯接口定义可以参考ISO22900-2标准文档。由于D-PDU接口基本上已经支持了所有的协议的通讯，所以可以通讯接口构建成D-PDU接口。相应的，文本获取接口主要用于获取诊断数据对应的文本，比如获取故障码P9000对应的故障码文本为vehicle senior N34is error。代码方法的诊断软件获取文本一般是通过ID到相应的库文件中去查找，比如GetDtcTextFromID(intid)，传入一个ID值，然后会返回这个ID对应的文本，同一个ID可以对应不同的语言版本，且库文件中可以包括不同语言版本的库，包括中文库、英文库等，则可以根据ID版本的不同到对应的库中查找相应的内容，例如ID为中文版的就到中文库中查找相应。OTX方式中的文本获取也是有ISO标准，比如ISO13209-3中的i18n标准，定义了通过TranslationKey来获取文本，其中，TranslationKey实际上也就是文本ID。因为代码方式的文本获取支持更多的文件以及更灵活可扩展，就可以构建代码方式的文本获取接口。显示接口主要是用来显示诊断结果或者汽车诊断返回的数据，比如发动机的故障码、发动机转速等。代码方式定义的诊断显示接口主要用于显示各种诊断信息，比如显示版本信息、显示故障码、显示诊断数据等等。OTX方式的诊断数据显示接口也可以定义为ISO标准，参考ISO13209-3中的HMI部分的定义。代码方式的诊断数据显示接口比较灵活而且多样，所以就可以构建代码方式的显示接口。

在第二种具体的实时方式中，构建接口包括：构建OTX方式的诊断协议获取接口、OTX方式的显示接口、OTX方式的文本获取接口、代码方式的通讯接口。具体的，就是采用OTX方式构建诊断协议获取接口、显示接口以及文本获取接口，并采用代码方式构建通信接口。

除以上两种具体的实施方式以外，还可以采用其他组合方式构建接口，例如，构建代码方式的文本获取接口以及显示接口，构建OTX方式的通信接口和诊断协议获取接口等。

步骤S23：确定所述目标接口的构建方式。

相应的，在根据所述车辆诊断请求确定出诊断软件需调用的目标接口之后，还需要确定所述目标接口的构建方式，具体的，就是需要确定所述目标接口是代码方式的接口还是OTX方式的接口。具体的，可以在确定所述目标接口之后，得到所述目标接口名称，根据预先配置的接口名称与接口构建方式映射关系表确定所述目标接口名称对应的目标接口的构建方式。所述接口名称与接口构建方式映射关系表为构建接口时对构建的接口的名称和对应接口构建方式进行存储得到的关系表。

步骤S24：判断所述目标接口的构建方式与所述诊断软件的类型是否匹配。

在确定出所述目标接口的构建方式之后，还需要判断所述目标接口的构建方式与所述诊断软件的类型是否匹配。具体的，可以包括：当所述目标接口的构建方式为OTX方式，所述诊断软件的类型为OTX方式诊断软件；或者当所述目标接口的构建方式为代码方式，所述诊断软件的类型为代码方式诊断软件时，所述目标接口的构建方式与所述诊断软件的类型匹配；当所述目标接口的构建方式为OTX方式，所述诊断软件的类型为代码方式诊断软件；或者当所述目标接口的构建方式为代码方式，所述诊断软件的类型为OTX方式诊断软件时，所述目标接口的构建方式与所述诊断软件的类型不匹配。也即，所述目标接口的构建方式和所述诊断软件的类型不相同时，则所述目标接口的构建方式和所述诊断软件的类型不匹配；所述目标接口的构建方式和所述诊断软件的类型相同时，则所述目标接口的构建方式和所述诊断软件的类型相匹配。

步骤S25：当所述目标接口的构建方式与所述诊断软件的类型匹配时，则直接调用目标接口执行所述诊断软件进行车辆诊断。

在判断所述目标接口的构建方式与所述诊断软件的类型是否匹配之后，如果所述目标接口的构建方式与所述诊断软件的类型相匹配，则可以直接调用所述目标接口执行所述诊断软件进行车辆诊断，例如，当所述诊断软件为OTX方式诊断软件时，所述目标接口的构建方式也为OTX方式接口时，可以直接调用所述目标接口进行相关的诊断操作，例如，所述诊断软件为OTX方式的诊断软件，且所述目标接口为D-PDU标准的通讯接口，则可以直接调用该通讯接口执行所述诊断软件进行车辆诊断。

步骤S26：当所述目标接口的构建方式与所述诊断软件的类型不匹配时，则构建调用指针，通过调用指针调用所述目标接口执行所述诊断软件进行车辆诊断。

在判断所述目标接口的构建方式与所述诊断软件的类型是否匹配之后，如果所述目标接口的构建方式与所述诊断软件的类型不匹配，则构建调用指针，通过调用指针调用所述目标接口执行所述诊断软件进行车辆诊断。

例如，所述诊断软件为代码方式诊断软件，所述目标接口为OTX方式通讯接口，则可以构建以下第一调用指针，通过调用指针调用OTX方式通讯接口执行所述诊断软件进行车辆诊断，所述第一调用指针如下：

所述诊断软件为OTX方式诊断软件，所述目标接口为代码方式文本获取接口，则可以构建以下第二调用指针，通过调用指针调用代码方式文本获取接口执行所述诊断软件进行车辆诊断，所述第二调用指针如下：

所述诊断软件为OTX方式诊断软件，所述目标接口为代码方式显示接口，则可以构建以下第三调用指针，通过调用指针调用代码方式显示接口执行所述诊断软件进行车辆诊断，所述第三调用指针如下：

在具体的实施过程中，如果诊断协议获取接口的构建方式为OXT方式，且需要由多个层层递进的功能递进执行后才能实现最终功能时，则认为该OTX诊断协议复杂，此时如果所述诊断软件为代码方式诊断软件，则可以使用多个调用指针或者扩展调用指针来实现最终的功能，例如，OTX接口有个获取诊断服务的接口，该接口要先读取链路信息，再根据链路读取诊断层信息，再去诊断层中获取诊断服务结构，再去结构中读取命令和算法，则可以用多个调用指针去实现，比如先构建调用指针1去读取信息，再通过调用指针2去读取诊断层，再用调用指针3去获取诊断服务，以实现最终的功能。

参见图4所示，为一种车辆诊断系统示意图。车辆诊断系统包括：OTX方式诊断软件、ISO22901-2D-PDU标准通信接口、代码方式诊断软件、自定义诊断协议获取接口(代码方式诊断协议获取接口)、自定义文本获取接口(代码方式文本获取接口)、自定义显示接口(代码方式显示接口)、预设诊断协议库、预设多语言文本库以及可视化显示模块。当诊断软件为OTX方式诊断软件，目标接口为自定义诊断协议获取接口时，可以通过构建好的相应指针(ISO22901标准诊断协议获取接口)调用该自定义诊断协议获取接口；当诊断软件为OTX方式诊断软件，目标接口为自定义显示接口时，可以通过构建好的相应指针(ISO13209-3HMI显示接口)调用该自定义显示接口；当诊断软件为OTX方式诊断软件，目标接口为自定义文本获取接口时，可以构建好的相应指针(ISO13209-3i18n标准文本获取接口)调用该自定义文本获取接口。当诊断软件为代码方式诊断软件，目标接口为ISO22901-2D-PDU标准通信接口时，可以构建好的相应指针(自定义通信接口)调用ISO22901-2D-PDU标准通信接口。

参见图5所示，本申请实施例公开了一种车辆诊断装置，包括：

请求获取模块11，用于获取车辆诊断请求，所述车辆诊断请求包括车辆信息；

信息确定模块12，用于根据所述车辆诊断请求确定诊断软件的类型和诊断软件需调用的目标接口；

构建方式确定模块13，用于确定所述目标接口的构建方式；

匹配判断模块14，用于判断所述目标接口的构建方式与所述诊断软件的类型是否匹配；

接口调用模块15，用于根据匹配结果执行对应的目标接口调用操作以进行车辆诊断。

可见，本申请先获取车辆诊断请求，所述车辆诊断请求包括车辆信息，然后根据所述车辆诊断请求确定诊断软件的类型和诊断软件需调用的目标接口，并确定目标接口的构建方式，接着判断所述目标接口的构建方式与所述诊断软件的类型是否匹配，并根据匹配结果执行对应的目标接口调用操作以进行车辆诊断。由此可见，本申请在获取到车辆诊断请求之后，并可以确定出相应的诊断软件类型以及需要调用的目标接口，并判断目标接口和构建方式和诊断软件的类型是否相匹配，再根据匹配结果进行相应的目标接口调用操作，这样能够实现对不同类型的车辆的诊断，且不同类型的软件可以调用一套接口，便可以在诊断软件的开发和维护中只开发和维护这一套目标接口，节省了开发的成本以及接口维护的难度，减少了维护工作量。

进一步的，所述信息确定模块，包括：

第一信息确定单元，用于根据所述车辆信息确定车型信息；

第二信息确定单元，用于根据所述车型信息确定所述诊断软件的类型，所述诊断软件的类型包括OTX方式诊断软件或代码方式诊断软件。

在具体的实施过程中，所述车辆诊断装置，还包括：

接口构建模块，用于以OTX方式或者代码方式构建接口，所述接口包括诊断协议获取接口、通讯接口、文本获取接口和显示接口。

进一步的，所述匹配判断模块，具体用于：

在所述目标接口的构建方式为OTX方式，所述诊断软件的类型为OTX方式诊断软件；或者当所述目标接口的构建方式为代码方式，所述诊断软件的类型为代码方式诊断软件时，所述目标接口的构建方式与所述诊断软件的类型匹配；

在所述目标接口的构建方式为OTX方式，所述诊断软件的类型为代码方式诊断软件；或者当所述目标接口的构建方式为代码方式，所述诊断软件的类型为OTX方式诊断软件时，所述目标接口的构建方式与所述诊断软件的类型不匹配。

具体的，所述接口调用模块，包括：

第一接口调用单元，用于在所述目标接口的构建方式与所述诊断软件的类型匹配时，则直接调用所述目标接口执行所述诊断软件进行车辆诊断；

第二接口调用单元，用于在所述目标接口的构建方式与所述诊断软件的类型不匹配时，则构建调用指针，通过调用指针调用所述目标接口执行所述诊断软件进行车辆诊断。

进一步的，参见图6所示，本申请实施例还公开了一种车辆诊断设备，包括：处理器21和存储器22。

其中，所述存储器22，用于存储计算机程序；所述处理器21，用于执行所述计算机程序，以实现前述实施例中公开的车辆诊断方法。

其中，关于上述车辆诊断方法的具体过程可以参考前述实施例中公开的相应内容，在此不再进行赘述。

进一步的，本申请实施例还公开了一种计算机可读存储介质，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现前述任一实施例中公开的车辆诊断方法。

其中，关于上述车辆诊断方法的具体过程可以参考前述实施例中公开的相应内容，在此不再进行赘述。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

最后，还需要说明的是，在本文中，诸如第一和第二之类的关系术语仅仅用来将一个实体或者操作与另一个实体或者操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得一系列包含其他要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本申请所提供的一种车辆诊断方法、装置、设备、介质进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种车辆诊断方法，其特征在于，所述方法包括：

获取车辆诊断请求，所述车辆诊断请求包括车辆信息；

根据所述车辆诊断请求确定诊断软件的类型和诊断软件需调用的目标接口；

确定所述目标接口的构建方式；

判断所述目标接口的构建方式与所述诊断软件的类型是否匹配；

根据匹配结果执行对应的目标接口调用操作以进行车辆诊断。

2.根据权利要求1所述的方法，其特征在于，所述根据所述车辆诊断请求确定诊断软件的类型，具体包括：

根据所述车辆信息确定车型信息；

根据所述车型信息确定所述诊断软件的类型，所述诊断软件的类型包括OTX方式诊断软件或代码方式诊断软件。

3.根据权利要求1所述的方法，其特征在于，在所述根据所述车辆诊断请求确定诊断软件需调用的目标接口之前，所述方法还包括：

以OTX方式或者代码方式构建接口，所述接口包括诊断协议获取接口、通讯接口、文本获取接口和显示接口。

4.根据权利要求3所述的方法，其特征在于，所述判断所述目标接口的构建方式与所述诊断软件的类型是否匹配，具体包括：

当所述目标接口的构建方式为OTX方式，所述诊断软件的类型为OTX方式诊断软件；或者当所述目标接口的构建方式为代码方式，所述诊断软件的类型为代码方式诊断软件时，所述目标接口的构建方式与所述诊断软件的类型匹配；

当所述目标接口的构建方式为OTX方式，所述诊断软件的类型为代码方式诊断软件；或者当所述目标接口的构建方式为代码方式，所述诊断软件的类型为OTX方式诊断软件时，所述目标接口的构建方式与所述诊断软件的类型不匹配。

5.根据权利要求1至4任一项所述的方法，其特征在于，所述根据匹配结果执行对应的目标接口调用操作以进行车辆诊断，具体包括：

当所述目标接口的构建方式与所述诊断软件的类型匹配时，则直接调用所述目标接口执行所述诊断软件进行车辆诊断；

当所述目标接口的构建方式与所述诊断软件的类型不匹配时，则构建调用指针，通过调用指针调用所述目标接口执行所述诊断软件进行车辆诊断。

6.一种车辆诊断装置，其特征在于，包括：

请求获取模块，用于获取车辆诊断请求，所述车辆诊断请求包括车辆信息；

信息确定模块，用于根据所述车辆诊断请求确定诊断软件的类型和诊断软件需调用的目标接口；

构建方式确定模块，用于确定所述目标接口的构建方式；

匹配判断模块，用于判断所述目标接口的构建方式与所述诊断软件的类型是否匹配；

接口调用模块，用于根据匹配结果执行对应的目标接口调用操作以进行车辆诊断。

7.根据权利要求6所述的车辆诊断装置，其特征在于，所述信息确定模块，包括：

第一信息确定单元，用于根据所述车辆信息确定车型信息；

第二信息确定单元，用于根据所述车型信息确定所述诊断软件的类型，所述诊断软件的类型包括OTX方式诊断软件或代码方式诊断软件。

8.根据权利要求6所述的车辆诊断装置，其特征在于，还包括：

接口构建模块，用于以OTX方式或者代码方式构建接口，所述接口包括诊断协议获取接口、通讯接口、文本获取接口和显示接口。

9.根据权利要求6所述的车辆诊断装置，其特征在于，所述接口调用模块，包括：

第一接口调用单元，用于在所述目标接口的构建方式与所述诊断软件的类型匹配时，则直接调用所述目标接口执行所述诊断软件进行车辆诊断；

第二接口调用单元，用于在所述目标接口的构建方式与所述诊断软件的类型不匹配时，则构建调用指针，通过调用指针调用所述目标接口执行所述诊断软件进行车辆诊断。

10.一种车辆诊断设备，其特征在于，包括：

存储器和处理器；

其中，所述存储器，用于存储计算机程序；

所述处理器，用于执行所述计算机程序，以实现权利要求1至5任一项所述的车辆诊断方法。

Images