一种车辆诊断方法、系统、车辆及可读存储介质

技术领域

本申请涉及计算机应用技术领域，特别是涉及一种车辆诊断方法、系统、车辆及可读存储介质。

背景技术

随着汽车信息系统(也称车载信息系统，车载系统)是一种能使驾驶员在行驶过程中，通过车载电子装备及时了解汽车运行的状况信息和外界信息的装置。车载信息系统包括汽车信息显示系统和信息通信系统两部分。其中，汽车运行的状况信息可通过观察仪表盘的显示来得到，而外界信息需要通过与外界联系的通信设备才能得到。

目前，基于ODX的诊断设备基本上都是在PC的WINDOWS系统上运行诊断软件，ODX诊断软件解析ODX中的诊断服务信息，通过windows版的D-PDU DLL动态库接口发送给VCI硬件，VCI硬件再与车辆的ECU之间进行诊断通讯发送和接收ECU数据。采用ODX的诊断模式，就需要配置基于windows的电脑和一个基于D-PDU接口的VCI硬件。诊断设备的成本比较高，而且不方便携带。诊断的场景会有一定的局限性。

综上所述，如何有效地解决ODX诊断局限性问题，是目前本领域技术人员急需解决的技术问题。

发明内容

本申请的目的是提供一种车辆诊断方法、系统、车辆及可读存储介质，可以不再依赖基于windows的电脑和一个基于D-PDU接口的VCI硬件，而是可以直接基于车载系统，完成车辆的ODX模式的诊断。

为解决上述技术问题，本申请提供如下技术方案：

一种车辆诊断方法，包括：

响应于诊断操作，车载系统中的车辆诊断软件产生请求命令；

通过逻辑通道接口将所述请求命令发送给ECU；所述逻辑通道接口为基于车载通讯模块实现的D-PDU接口；

在所述ECU产生诊断数据后，通过所述逻辑通道接口将所述诊断数据反馈给所述车辆诊断软件，以便所述车辆诊断软件，基于所述诊断数据确定诊断结果。

优选地，所述逻辑通道接口包括发送请求命令接口和接收回复命令接口，相应地，所述通过逻辑通道接口将所述请求命令发送给ECU，包括：

通过所述发送请求命令接口，将所述请求命令发送给所述ECU；

相应地，所述通过所述逻辑通道接口将所述诊断数据反馈给所述车辆诊断软件，包括：

通过所述接收回复命令接口将所述诊断数据发送给所述车辆诊断软件。

优选地，通过所述发送请求命令接口，将所述请求命令发送给所述ECU，包括：

从所述D-PDU接口获取所述请求命令；

按照CAN帧结构将所述请求命令封装成CAN帧命令；

将所述CAN帧命令发送给与车辆总线相连接的CAN收发器上，通过所述车辆总线，将所述CAN帧命令发送给所述ECU。

优选地，通过所述接收回复命令接口将所述诊断数据发送给所述车辆诊断软件，包括：

从所述CAN收发器中读取所述车辆总线的CAN帧；

若所述CAN帧的ID与CAN过滤ID一致，则通过所述D-DPDU接口将所述CAN帧上传给所述车辆诊断软件，以便所述车辆诊断软件从所述CAN帧中解析获得所述诊断数据。

优选地，创建所述逻辑通道接口，包括：

从所述D-PDU接口中获取通讯参数；

利用所述通讯参数，并基于通讯协议设置车机的收发器，以创建所述逻辑通道接口。

优选地，若所述通讯协议为CAN协议，则所述通讯参数包括通讯波特率和过滤ID，所述收发器为CAN收发器。

优选地，所述响应于诊断操作，车载系统中的车辆诊断软件产生请求命令，包括：

在所述车辆诊断软件启动后，基于车架号获取ODX诊断包；

解析所述ODX诊断包，得到诊断信息；

基于所述诊断信息，显示诊断功能；

相应于所述诊断操作，所述车辆诊断软件产生所述请求命令。

一种车辆诊断系统，包括：

车辆诊断软件、车载通讯模块和ECU；所述车辆诊断软件位于车载系统中；

其中，所述车辆诊断软件，响应于诊断操作，产生请求命令；

所述车载通讯模块实现D-PDU接口，用于通过逻辑通道接口将所述请求命令发送给ECU；

在所述ECU产生诊断数据后，通过所述逻辑通道接口将所述诊断数据反馈给所述车辆诊断软件，以便所述车辆诊断软件，基于所述诊断数据确定诊断结果。

一种车辆，包括：

具有如上述的车辆诊断系统，在车辆诊断系统中实现如上述的车辆诊断方法的步骤。

一种可读存储介质，所述可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述车辆诊断方法的步骤。

应用本申请实施例所提供的方法，响应于诊断操作，车载系统中的车辆诊断软件产生请求命令；通过逻辑通道接口将请求命令发送给ECU；逻辑通道接口为基于车载通讯模块实现的D-PDU接口；在ECU产生诊断数据后，通过逻辑通道接口将诊断数据反馈给车辆诊断软件，以便车辆诊断软件，基于诊断数据确定诊断结果。

在本申请中，车辆诊断软件可安装于车载系统中，响应于诊断操作，可以产生请求命令。然后，通过逻辑通道接口即可将请求命令发送给ECU。需要注意的是，该逻辑通道接口为基于车载通讯模块所实现的D-PDU接口。然后，在ECU产生诊断数据之后，也可以通过逻辑通道接口将诊断数据反馈给车辆诊断软件，而后车辆诊断软件，基于诊断数据确定诊断结果。

可见，本申请的技术效果是：可以摆脱基于windows的电脑和一个基于D-PDU接口的VCI硬件，直接基于车载系统，即可完成ODX模式的车辆诊断，可以大大降低诊断成本，且易于推广，突破了ODX模式诊断场景的局限性。

相应地，本申请实施例还提供了与上述车辆诊断方法相对应的车辆诊断系统、车辆和可读存储介质，具有上述技术效果，在此不再赘述。

附图说明

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

图1为本申请实施例中一种车辆诊断方法的实施流程图；

图2为一种车辆诊断示意图；

图3为本申请实施例中一种车辆诊断系统的示意图；

图4为本申请实施例中一种车辆的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面结合附图和具体实施方式对本申请作进一步的详细说明。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

为便于理解，下面将本申请实施例中涉及的相关术语进行说明：

VCI(Vehicle Communication Interface)，车辆通信接口；

CAN(Controller Area Network)，控制器局域网络；

KWP(Keyword Protocol)，关键字协议；

VPW(Variable Pulse Width Modulated)，可变脉宽调制；

PWM(Pulse Width Modulation)，脉冲宽度调制；

DoIP(Diagnostic communication over Internet Protocol)，以太网通讯协议；

D-PDU(Diagnostic protocol data unit)，用于访问车辆通信接口，即诊断协议数据单元(是在ISO 22900-2中定义的一些函数接口)；

ECU(Electronic Control Unit)，电子控制器单元；

VIN(Vehicle Identification Number)，车辆识别号码或车架号码；

XML(Extensible Markup Language)，可扩展标记语言，标准通用标记语言的子集，是一种用于标记电子文件使其具有结构性的标记语言。

请参考图1，图1为本申请实施例中一种车辆诊断方法的流程图，该方法可应用于需要进行车辆诊断的任一车辆的车载系统中，该方法包括以下步骤：

S101、响应于诊断操作，车载系统中的车辆诊断软件产生请求命令。

请参考图2，图2为一种车辆诊断示意图，从图2可看出，车辆诊断软件是安装于PC中的，PC与车辆之间需要通过VCI硬件连接。

请参考图3，图3为本申请实施例中一种车辆诊断系统的示意图，从图3可以看出，车辆诊断软件不是位于车辆之外的PC中，而是直接在车辆内的车载系统中，此外，也无需VCI硬件连接。在对车辆进行检测时，可以直接基于车辆本身的设施，即可完成检测，无需额外准备检测用PC和连接硬件。

在本申请中，车辆诊断软件可以对诊断操作进行响应，并产生相应的请求命令。响应并产生请求命令的过程可以参照相关测试流程，在此不再一一赘述。

S102、通过逻辑通道接口将请求命令发送给ECU。

其中，逻辑通道接口为基于车载通讯模块实现的D-PDU接口。

其中，ECU可以为当前车辆中的任意一个ECU，例如，发动机ECU、空调ECU、车身ECU、波箱ECU、仪表ECU等。

在本申请实施例中，可以预先创建出逻辑通道接口，该逻辑通道接口即为基于车载通讯模块所实现的D-PDU接口。

具体的，在本申请中的一种具体实施方式中，创建逻辑通道接口，包括：

从D-PDU接口中获取通讯参数；

利用通讯参数，并基于通讯协议设置车机的收发器，以创建逻辑通道接口。

也就是说，在创建逻辑通道接口时，需要基于D-PDU接口的通讯参数，对车机的收发器进行设置，完成通讯参数设置后，即完成了创建该逻辑通道接口。具体的，可以利用通讯参数，并基于通讯协议(如K线，CAN，DOIP)对车机的收发器进行参数设置。其中，K线(keyword protocol)关键字协议，需要设置通讯管脚，通讯波特率一般为10416，通讯位格式一般为1+8+1；

DOIP(Diagnostic communication over Internet Protocol)基于以太网诊断协议，需要设置通讯管脚，通讯端口号，网关IP地址进行通道创建。

其中，若通讯协议为CAN协议，则通讯参数包括通讯波特率和过滤ID，收发器为CAN收发器。

具体的，ODX诊断主要包括两大模块，其一为ODX源文件XML，里面包括所有ECU的信息，如ECU名称，个数，每个ECU支持的诊断服务，每个诊断服务的命令，算法等信息；另一为D-PDU(ISO22900-2)通讯接口，通过调用D-PDU接口与车辆的ECU进行诊断命令发送和接收。

PC版的D-PDU接口是使用VCI的通讯协议进行封装实现的，所以D-PDU接口要配合着VCI一起使用。本实施例中的车载系统的D-PDU接口也需要遵循ISO22900-2标准接口，因为车载系统本身是可以直接和车辆总线连接通讯，所以车载系统不需要VCI。车载D-PDU每个接口实现部分就需要按照车载系统与车辆总线的通讯方式来实现。如通讯协议(K，CAN，DOIP)的参数设置，发送数据格式化，接收回复数据的解析。

以CAN协议为例，车机本身带有CAN收发器，并通过CAN收发器与其它ECU通讯。首先，设置CAN收发器的通讯波特率为500K，再设置CAN过滤ID(唯一标识)，和哪个ECU通讯就设置成哪个ECU的ID，例如发动机ECU的ID为0x7e8。设置完成后就可以向发动机ECU发送命令。

S103、在ECU产生诊断数据后，通过逻辑通道接口将诊断数据反馈给车辆诊断软件，以便车辆诊断软件，基于诊断数据确定诊断结果。

在本申请实施例中，当ECU产生诊断数据(即回复数据/回复命令)之后，便可通过逻辑通道接口将诊断数据反馈给车辆诊断软件。

举例说明：如果要读取发动机ECU的故障码，ODX诊断APP就会调用D-PDU接口发送读取故障码的命令，D-PDU会调用车机的总线通讯模块，车机总线通讯模块会将读取故障码命令按CAN标准封装成一帧CAN命令，然后把CAN帧命令通过车机CAN收发器发送到总线，总线上的发动机ECU就会接收到这帧CAN命令，然后发动机ECU会回复故障码信息的CAN帧，车机的CAN收发器会对比，如果CAN帧ID为预先设置过滤ID，就会把CAN帧接收上来。然后解析CAN帧里面的故障码信息，比如从第3个字节开始每4个字节(前3个字节为故障码编号，最后一个字节为故障码状态)代表一个故障码。

车辆诊断软件，获得了诊断数据之后，基于诊断数据确定诊断结果。具体的，车辆诊断软件接收到ECU回复的诊断数据后，根据诊断服务的类型进行解析，如果是故障码类型，就根据回复的诊断数据在故障码库中查找对应的故障码。如果是数据流类型就把回复的诊断数据带入数据流的计算公式计算出值。然后，将最终结果显示出来。

应用本申请实施例所提供的方法，响应于诊断操作，车载系统中的车辆诊断软件产生请求命令；通过逻辑通道接口将请求命令发送给ECU；逻辑通道接口为基于车载通讯模块实现的D-PDU接口；在ECU产生诊断数据后，通过逻辑通道接口将诊断数据反馈给车辆诊断软件，以便车辆诊断软件，基于诊断数据确定诊断结果。

在本申请中，车辆诊断软件可安装于车载系统中，响应于诊断操作，可以产生请求命令。然后，通过逻辑通道接口即可将请求命令发送给ECU。需要注意的是，该逻辑通道接口为基于车载通讯模块所实现的D-PDU接口。然后，在ECU产生诊断数据之后，也可以通过逻辑通道接口将诊断数据反馈给车辆诊断软件，而后车辆诊断软件，基于诊断数据确定诊断结果。

可见，本申请的技术效果是：可以摆脱基于windows的电脑和一个基于D-PDU接口的VCI硬件，直接基于车载系统，即可完成ODX模式的车辆诊断，可以大大降低诊断成本，且易于推广，突破了ODX模式诊断场景的局限性。

在本申请中的一种具体实施方式中，逻辑通道接口包括发送请求命令接口和接收回复命令接口，相应地，通过逻辑通道接口将请求命令发送给ECU，包括：

通过发送请求命令接口，将请求命令发送给ECU；

相应地，通过逻辑通道接口将诊断数据反馈给车辆诊断软件，包括：通过接收回复命令接口将诊断数据发送给车辆诊断软件。

也就是说，在本申请实施例中，逻辑通道接口包括发送请求命令接口和接收回复命令接口，根据不同的接口执行不同的通讯。

其中，通过发送请求命令接口，将请求命令发送给ECU，包括：

从D-PDU接口获取请求命令；

按照CAN帧结构将请求命令封装成CAN帧命令；

将CAN帧命令发送给与车辆总线相连接的CAN收发器上，通过车辆总线，将CAN帧命令发送给ECU。

也就是说，车载通讯模块实现D-PDU发送请求命令接口，首先从D-PDU接口获取到要发送的诊断命令，然后按照标准的CAN帧结构将诊断命令封装成标准CAN帧命令，然后将CAN帧命令发送给车机的CAN收发器，CAN收发器连接在车辆总线上面，就会把CAN帧命令发送到车辆的内部总线上，其它ECU就可以获取到。

其中，通过接收回复命令接口将诊断数据发送给车辆诊断软件，包括：

从CAN收发器中读取车辆总线的CAN帧；

若CAN帧的ID与CAN过滤ID一致，则通过D-DPDU接口将CAN帧上传给车辆诊断软件，以便车辆诊断软件从CAN帧中解析获得诊断数据。

也就是说，车载通讯模块实现D-PDU接收回复命令接口时，先从车机的CAN收发器中读取总线的CAN帧，然后将CAN帧的ID与创建逻辑通道时设置的CAN过滤ID进行对比，如果不一样就把CAN帧丢掉，如果一致则把CAN帧接收，然后通过D-PDU接口上传给车载ODX诊断APP，APP就可以根据位置和算法来解析出CAN帧中的内容。

在本申请中的一种具体实施方式中，响应于诊断操作，车载系统中的车辆诊断软件产生请求命令，包括：

在车辆诊断软件启动后，基于车架号获取ODX诊断包；

解析ODX诊断包，得到诊断信息；

基于诊断信息，显示诊断功能；

相应于诊断操作，车辆诊断软件产生请求命令。

为便于描述，下面将上述步骤结合进行说明。

在车载系统中启动车辆诊断软件，首先会先将车辆的VIN码上传到后台服务器，后台服务器根据VIN码判断是什么车型，然后将车型对应的ODX诊断包下放给车辆诊断软件。

其中，车机中保存有当前车辆的VIN码，启动车辆诊断软件后，车辆诊断软件会自动调用后台服务器的接口把VIN码上传到后台服务器。

车辆诊断软件获取到ODX诊断包后，会将ODX诊断包进行解压缩，解压缩后的文件就是ODX的标准XML源文件，其中包括-V(车辆信息)，-C(通讯参数)，-D(诊断服务)，-F(刷写)，刷写JAR包等XML源文件。

车载ODX诊断APP会解析所有的ODX源文件，解析完成后就会获取到整车的诊断信息，比如整车配置有多少个ECU，每个ECU的诊断协议类型，通讯管脚，通讯参数，故障码库，诊断服务(请求命令，回复命令，算法，位置)等。

车载ODX诊断APP可以将各ECU列表及每个ECU下支持的诊断服务显示出来，诊断人员就可以选择要诊断的ECU和功能，比如发动机ECU的读取故障码功能。

诊断人员选择完成后，车载ODX诊断APP就可以得到选择的ECU和诊断功能。首先根据选择的ECU获取ECU的协议类型通讯参数(例如协议类型可以为K/CAN/DOIP，通讯管脚6，14，通讯波特率500K，最大通讯等待时间等参数)，然后调用D-PDU接口按照ECU的通讯参数创建与指定ECU的逻辑通讯通道。

以CAN协议为例，D-PDU接口一般有创建逻辑通道接口，发送请求命令接口，接收回复命令接口等。

车载通讯模块实现D-PDU创建逻辑通道接口时，首先从D-PDU接口获取到创建逻辑通道的各参数，比如通讯波特率为500K，通讯管脚6，14(通讯管脚PC版本的需要设置，而车载系统不需要设置)，CAN过滤ID为0x7e8。然后，将车机的CAN收发器设置为所获取到的通讯参数，设置成功后逻辑通道就已经创建成功。

车载通讯模块实现D-PDU发送请求命令接口，首先从D-PDU接口获取到要发送的诊断命令，然后按照标准的CAN帧结构将诊断命令封装成标准CAN帧命令，然后将CAN帧命令发送给车机的CAN收发器，CAN收发器连接在车辆总线上面，就会把CAN帧命令发送到车辆的内部总线上，其它ECU就可以获取到

车载通讯模块实现D-PDU接收回复命令接口时，先从车机的CAN收发器中读取总线的CAN帧，然后将CAN帧的ID与创建逻辑通道时设置的CAN过滤ID进行对比，如果不一样就把CAN帧丢掉，如果一致则把CAN帧接收，然后通过D-PDU接口上传给车载ODX诊断APP，APP就可以根据位置和算法来解析出CAN帧中的内容。

与ECU的逻辑通讯通道创建完成后，ODX诊断APP就从XML源文件中取出选择的诊断功能的请求命令(例如读取故障码命令为0x190208)，然后调用D-PDU接口将诊断功能的请求命令通过创建的逻辑通道发送给ECU。并接收从ECU回复的诊断数据。

车载ODX诊断APP接收到ECU回复的诊断数据后，根据诊断服务的类型进行解析，如果是故障码类型，就根据回复的诊断数据在故障码库中查找对应的故障码。如果是数据流类型就把回复的诊断数据带入数据流的计算公式计算出值。然后将最终结果显示出来。

相应于上面的方法实施例，本申请实施例还提供了一种车辆诊断系统，下文描述的车辆诊断系统与上文描述的车辆诊断方法可相互对应参照。

参见图3所示，该系统包括以下模块：

车辆诊断软件101、车载通讯模块102和ECU103；车辆诊断软件位于车载系统中；

其中，车辆诊断软件，响应于诊断操作，产生请求命令；

车载通讯模块实现D-PDU接口，用于通过逻辑通道接口将请求命令发送给ECU；

在ECU产生诊断数据后，通过逻辑通道接口将诊断数据反馈给车辆诊断软件，以便车辆诊断软件，基于诊断数据确定诊断结果。

可见，该系统上，可实施上述方法实施例所描述的车辆诊断方法的步骤，因而该车辆诊断系统具备该车辆诊断方法的技术效果，在此不再一一赘述。

相应于上面的实施例，本申请实施例还提供了一种车辆，下文描述的车辆与上文描述的车辆诊断方法、车辆诊断系统可相互对应参照。

请参考图4，该车辆具有如上述的车辆诊断系统，在车辆诊断系统中实现如上述的车辆诊断方法的步骤。

可见，该车辆具有车辆诊断系统，且该车辆诊断系统可实施上述方法实施例所描述的车辆诊断方法的步骤，因而该车辆也具备该车辆诊断方法的技术效果，在此不再一一赘述。

一种可读存储介质，可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现上述方法实施例的车辆诊断方法的步骤。

该可读存储介质具体可以为U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可存储程序代码的可读存储介质。

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

本领域技术人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应该认为超出本申请的范围。

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

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

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