一种车辆诊断方法及相关装置与流程

1.本技术涉及车辆电子技术领域，尤其涉及一种车辆诊断方法及相关装置。


背景技术：

2.随着人们生活质量的提高和交通技术的发展，车辆的数量与种类日渐增加，人们使用车辆的时间和频率越来越高，车辆的安全性也越来越重要。为提高车辆的安全性，会对汽车进行诊断。在对车辆进行诊断的过程中，通过诊断盒与车辆连接，从而获取车辆的诊断数据。诊断数据包括车辆的状态及故障信息。
3.诊断盒通常需要通过上位机中的诊断软件控制其操作。不同厂商开发的诊断软件所使用的通信接口的类型不同。在使用诊断盒对车辆进行诊断时，需使用与该诊断软件对应的诊断盒(诊断盒与诊断软件的通信接口相匹配)才能进行车辆故障的诊断，用户体验较差。例如，用户购买的诊断盒仅支持基于诊断协议数据单元(diagnostic protocol data unit，d-pdu)的通信接口的通信，若用户对车辆进行诊断时，所使用的诊断软件为基于j2534的通信接口开发的，则诊断软件与诊断盒之间无法兼容，不能完成对车辆的诊断，需要额外购买支持基于j2534的通信接口开发的诊断盒。
4.如何解决上述问题，是本领域技术人员研究的热点问题。


技术实现要素：

5.本技术实施例公开了一种车辆诊断方法及相关装置，能够解决基于不同应用程序接口(application programming interface，api)的设备之间的兼容性问题，降低了车辆诊断的成本。
6.第一方面，本技术实施例提供一种车辆诊断方法，包括：
7.通过第一诊断指令调用第一api；
8.将该第一诊断指令映射为第二诊断指令，该第二诊断指令用于调用第二api；
9.通过该第二诊断指令调用该第二api，以处理第一业务，该第一业务与该车辆的诊断相关。
10.可选的，上述方法可以通过第一诊断设备实现，该第一诊断设备用于通过第二诊断设备对车辆进行诊断，该第二诊断设备支持基于第二应用程序接口api的通信。
11.在上述方法中，将第一诊断指令映射为能够调用第二api的第二诊断指令，从而使得第一诊断设备通过第二api来实现第一api所实现的功能。如此，相当于该第二api作为中间模块实现该第一api与第二诊断设备之间的通信，解决了基于不同api的设备之间的兼容性问题，降低了车辆诊断的成本，提高了诊断设备的服务质量，提升了用户在诊断车辆过程中的体验。
12.例如，用户购买的诊断盒仅支持基于第二api的通信，若用户对车辆进行诊断时，所使用的诊断软件为第一api开发的诊断软件，通过本技术实施例的方法，第一诊断设备可以通过第二api来实现第一api的功能，从而可以完成对车辆的诊断，无需额外购买诊断盒，
降低了车辆诊断的成本。
13.在第一方面的一种可能的实施方式中，第一诊断指令包含第一函数，第二诊断指令包含第二函数，将该第一诊断指令映射为第二诊断指令，该第二诊断指令用于调用第二api，包括：将该第一函数映射为该第二函数，该第二函数用于调用第二api。
14.在第一方面的一种可能的实施方式中，通过第一诊断指令调用第一api之前，还包括：
15.运行诊断软件，该第一诊断指令来自该诊断软件。其中，诊断软件可以是基于第一api开发的计算机程序(或软件模块、软硬件结合模块等)，或者诊断软件运行过程中需要调用第一api以实现功能。
16.可以看出，第一诊断设备中可以运行基于第一api开发的计算机程序，来对车辆进行诊断。如此，通过上述方法，只需要通过第一诊断设备和第二诊断设备，既可以测试(或运行)基于第一api开发的计算机程序(或者其他软件模组)，也可以测试(或运行)基于第二api开发的计算机程序(或者其他软件模组)，降低了诊断软件测试、运行的成本，提高了测试(运行)程序的效率，提高了诊断设备所提供的服务质量。
17.在第一方面的一种可能的实施方式中，上述第二诊断设备为支持d-pdu api的诊断盒。
18.在第一方面的一种可能的实施方式中，第二api为d-pdu api，第一api为j2534 api。
19.可以看出，j2534 api能通过d-pdu api与支持d-pdu api的诊断盒进行通信，反之，可以通过支持d-pdu api的诊断盒，测试(或运行)验证基于j2534 api开发的计算机程序，降低了支持j2534api的诊断软件的测试、运行成本，提高了测试支持j2534api的程序的效率，提高了诊断设备所提供的服务质量。
20.此外，通过上述方法，第一诊断设备可以通过d-pdu api来实现j2534 api的功能，减少了j2534 api的开发周期，也减少了确认j2534 api功能的周期。
21.在第一方面的一种可能的实施方式中，上述第一业务包含以下业务中的一项或者多项：
22.启动服务、建立连接链路、断开连接链路、关闭服务、控制服务、单向收发、双向收发、协议参数配置、过滤数据、硬件控制、获取版本信息、错误处理。
23.通过上述方式，可以完成以上一种或者多种对车辆之间的诊断业务，能够满足用户在对车辆诊断过程中的多种业务需求，提升车辆诊断的效率和服务质量，提升用户体验。
24.在第一方面的一种可能的实施方式中，上述第一业务用于写入通讯参数和/或读取通讯参数。
25.可选的，第一业务是用来写入和/或读出通讯参数，此时第一诊断指令和/或第二诊断指令中可以携带参数。这种情况下，第一诊断设备还可以完成对参数的映射，以满足用户在对车辆诊断过程中的多种业务需求。
26.在第一方面的一种可能的实施方式中，上述方法还包括：
27.通过第二api监测第一业务的第一处理结果；
28.将该第一处理结果映射为第一api支持的第二处理结果；
29.通过该第一api获取该第二处理结果。
30.上述实施方式中，不仅可以将第一诊断指令映射为能够调用第二api的第二诊断指令，还能将第二api获取的第一处理结果映射为第一api支持的第二处理结果，以反馈对第一业务的执行情况。
31.在第一方面的一种可能的实施方式中，上述第一处理结果用于指示处理第一业务成功；或者，该第一处理结果为错误码，该错误码指示处理该第一业务失败。
32.上述实施方式中，处理结果能够告知用户第一业务是否处理成功，从而使得用户根据处理结果进行结束诊断、重试、调试程序等操作，满足用户获取第一业务的处理结果的需求。
33.第二方面，本技术实施例提供一种诊断装置，包括：
34.调用单元，用于通过第一诊断指令调用第一api；
35.映射单元，用于将该第一诊断指令映射为第二诊断指令，该第二诊断指令用于调用第二api；
36.调用单元，还用于通过该第二诊断指令调用该第二api，以处理第一业务，该第一业务与该车辆的诊断相关。
37.在第二方面的一种可能的实施方式中，第一诊断指令包含第一函数，第二诊断指令包含第二函数，在将该第一诊断指令映射为第二诊断指令，该第二诊断指令用于调用第二api方面，映射单元用于：将该第一函数映射为该第二函数，该第二函数用于调用第二api。
38.在第二方面的一种可能的实施方式中，上述诊断装置为第一诊断设备。或者，该诊断装置包含于第一诊断设备中，例如，诊断装置为第一诊断设备中的芯片、硬件模块、或软件模块等。
39.可选的，上述诊断装置用于通过第二诊断设备对车辆进行诊断，该第二诊断设备支持基于第二应用程序接口api的通信。
40.在第二方面的一种可能的实施方式中，上述第二诊断设备为支持d-pdu api的诊断盒。
41.在第二方面的一种可能的实施方式中，第二api为d-pdu api，第一api为j2534 api。
42.在第二方面的一种可能的实施方式中，上述第一业务包含以下业务中的一项或者多项：
43.启动服务、建立连接链路、断开连接链路、关闭服务、控制服务、单向收发、双向收发、协议参数配置、过滤数据、硬件控制、获取版本信息、错误处理。
44.在第二方面的一种可能的实施方式中，上述第一业务用于写入通讯参数和/或读取通讯参数。
45.在第二方面的一种可能的实施方式中，该诊断装置还包括通信单元，其中：
46.通信单元，用于通过第二api监测第一业务的第一处理结果；
47.映射单元，还用于将该第一处理结果映射为该第一api支持的第二处理结果；
48.通信单元，还用于通过该第一api获取该第二处理结果。
49.在第二方面的一种可能的实施方式中，上述第一处理结果指示处理第一业务成功；或者，该第一结果为错误码，该错误码指示处理该第一业务失败。
50.在第二方面的一种可能的实施方式中，装置还包括：
51.处理单元，用于运行诊断软件，第一诊断指令来自该诊断软件。
52.第三方面，本技术实施例提供一种诊断设备，该设备包括处理器、存储器以及存储在该存储器中并可在该处理器上运行的计算机程序，该处理器执行该计算机程序时，实现第一方面或第一方面的任一项可能实施方式提供的车辆诊断方法。
53.在第三方面的一种可能的实施方式中，该处理器用于调用计算机程序，以实现以下操作：
54.通过第一诊断指令调用第一api；
55.将该第一诊断指令映射为第二诊断指令，该第二诊断指令用于调用第二api；
56.通过该第二诊断指令调用该第二api，以处理第一业务，该第一业务与该车辆的诊断相关。
57.在第三方面的一种可能的实施方式中，第一诊断指令包含第一函数，第二诊断指令包含第二函数，在将该第一诊断指令映射为第二诊断指令，该第二诊断指令用于调用第二api方面，处理器用于：将该第一函数映射为该第二函数，该第二函数用于调用第二api。
58.在第三方面的又一种可能的实施方式中，上述诊断设备为第一诊断设备。或者，该诊断设备包含于第一诊断设备中，例如，诊断设备为第一诊断设备中的芯片、硬件模块、或软件模块等。
59.可选的，上述诊断设备用于通过第二诊断设备对车辆进行诊断，该第二诊断设备支持基于第二应用程序接口api的通信。
60.在第三方面的又一种可能的实施方式中，在通过第一诊断指令调用第一api之前，处理器还用于：
61.运行诊断软件，该第一诊断指令来自该诊断软件。
62.在第三方面的又一种可能的实施方式中，上述第二诊断设备为支持d-pdu api的诊断盒。
63.在第三方面的又一种可能的实施方式中，第二api为d-pdu api，第一api为j2534api。
64.在第三方面的又一种可能的实施方式中，上述第一业务包含以下业务中的一项或者多项：
65.启动服务、建立连接链路、断开连接链路、关闭服务、控制服务、单向收发、双向收发、协议参数配置、过滤数据、硬件控制、获取版本信息、错误处理。
66.在第三方面的又一种可能的实施方式中，上述第一业务用于写入通讯参数和/或读取通讯参数。
67.在第三方面的又一种可能的实施方式中，处理器还用于：
68.通过第二api监测第一业务的第一处理结果；
69.将该第一处理结果映射为第一api支持的第二处理结果；
70.通过该第一api获取该第二处理结果。
71.在第三方面的又一种可能的实施方式中，上述第一处理结果用于指示处理第一业务成功；或者，该第一处理结果为错误码，该错误码指示处理该第一业务失败。
72.第四方面，本技术实施例提供一种计算机可读存储介质，该计算机可读存储介质
中存储有计算机程序，当其在处理器上运行时，实现第一方面提供的车辆诊断方法。
73.可以理解地，上述第三方面提供的诊断装置、第三方面提供的诊断设备和第四方面提供的计算机可读存储介质均用于实现第一方面所提供的车辆诊断方法，因此，其所能达到的有益效果可参考第一方面所提供的车辆诊断方法中的有益效果。此处不再赘述。
附图说明
74.为了更清楚地说明本技术实施例技术方案，下面将对本技术实施例用到的附图作简单地介绍。
75.图1是本技术实施例提供的一种车辆诊断系统的架构示意图；
76.图2是本技术实施例提供的一种车辆诊断系统的架构示意图；
77.图3是本技术实施例提供的又一种车辆诊断系统的架构示意图；
78.图4是本技术实施例提供的又一种车辆诊断系统的架构示意图；
79.图5是本技术实施例提供的一种车辆诊断方法的流程示意图；
80.图6是本技术实施例提供的又一种车辆诊断方法的流程示意图；
81.图7是本技术实施例提供的一种车辆诊断方法的流程示意图；
82.图8是本技术实施例提供的一种车辆诊断方法的流程示意图；
83.图9是本技术实施例提供的一种车辆诊断方法的流程示意图；
84.图10是本技术实施例提供的一种车辆诊断装置的结构示意图；
85.图11是本技术实施例提供的一种车辆诊断设备的结构示意图。
具体实施方式
86.请参见图1，图1是本技术实施例提供的一种车辆诊断系统的架构示意图，包括第一诊断设备101、第二诊断设备102和车辆103。
87.其中，第一诊断设备101是具有处理能力和数据收发能力的装置。第一诊断设备101中可以产生诊断指令、或者运行诊断软件，从而实现对车辆103进行诊断的相关业务。例如，第一诊断设备101可以是计算机、笔记本电脑、平板电脑、掌上电脑、台式机、诊断仪、手机、超级移动个人计算机(ultra-mobile personal computer，umpc)、上网本、个人数字助理(personal digital assistant，pda)等终端设备。在一些可能的场景中，第一诊断设备101也可以称为上位机，或者称为客户机(client)。
88.第二诊断设备102是与车辆103连接的装置，具有数据收发功能。在进行诊断时，第二诊断设备102用于获取车辆103的信息，例如车辆的身份信息、故障信息、或状态信息等中的一项或者多项。例如，第二诊断设备102由车载诊断(on-board diagnostics，obd)接口连接器与车辆103进行连接。应理解，此处说明的obd接口，包含ⅰ型obd接口(第一代obd)、或ii型obd接口(on-board diagnostics ii，obd ii)等中的一项或者多项。
89.可选的，该第二诊断设备102可以称为诊断工具，或者称为诊断盒。示例性的，该第二诊断设备102是模块化车载通信接口(modular vehicle communication interface，mvci)诊断工具。
90.车辆103指可以进行移动的交通工具。车辆中通常可以包含多个节点。此处的节点指具有数据采集能力、或数据收发能力、或数据处理能力的装置。例如，节点可以包含电子
控制单元(electronic control unit，ecu)、微控制单元(micro control unit，mcu)、多域控制器(multi domain controller，mdc)等中的一项或者多项。再如，节点可以包含网关、交换机、路由器、或蓝牙模块等中的一项或者多项。再如，节点可以包含加速度传感器、速度传感器、或温度传感器等中的一项或者多项。
91.第一诊断设备101与第二诊断设备102之间可以建立通信连接，第一诊断设备101可以通过第二诊断设备102对车辆103进行诊断。第一诊断设备101和第二诊断设备102之间可以通过蓝牙、无线网等无线方式连接，也可以通过通用串行总线(universal serial bus，usb)、异步传输标准接口rs-232进行连接。
92.进一步的，第二诊断设备可以将车辆的信息反馈给第一诊断设备200，第一诊断设备200可以针对第二诊断设备反馈的信息作出相应的分析和处理。
93.示例性的，第二诊断设备102可以通过obd接口与车辆103进行连接，获取车辆的信息。例如，获取车辆中的ecu的数据。而第一诊断设备101可以通过诊断软件(或者诊断指令)来控制第二诊断设备102，从而完成与车辆103诊断相关的业务。可选的，第一诊断设备101中还可以呈现用户界面，在该用户界面中，第一诊断设备101可以基于用户的操作来选择要完成的业务。
94.而第二诊断设备102与第一诊断设备101之间，需要相适配的通信接口来进行通信。例如，第二诊断设备102支持基于第二api的通信，而第一诊断设备101中的诊断软件(或其他可以生成诊断指令的模块)为基于第一api开发的，此时无法通过该诊断软件以及第二诊断设备102之间来对车辆103进行诊断。
95.本技术实施例中，第一诊断设备101通过诊断指令来控制第二诊断设备102完成诊断业务。而第一诊断设备101具体可以将第一诊断指令映射为能够调用第二api的第二诊断指令，从而使得第一诊断设备101通过第二api来实现第一api所实现的功能。
96.一种设计中，请参见图2，图2是本技术实施例提供的一种可能的车辆诊断系统的架构示意图。如图2所示，客户机201可以看作是第一诊断设备101，mvci诊断工具202可以看作是第二诊断设备102。其中，客户机201包括j2534应用程序、j2534api和d-ppu api，mvci诊断工具202包括协议、设备驱动和obd接口。协议是指通信双方对数据传送控制的一种约定，约定中包括对数据格式、同步方式、传送速度、传输步骤、检纠错方式以及控制字符定义等问题做出统一规定，通信双方共同遵守。设备驱动是指操作系统操作输入输出设备间的使用的文件，驱动负责将操作系统的请求传输，转化为特定物理设备控制器能够理解的命令。其中，客户机201通过运行j2534应用程序调用j2534api，而客户机201可以将第一诊断指令映射为能够调用d-ppu api的第二诊断指令，使得客户机201可以通过与支持d-ppu api的mvci诊断工具202进行通信，从而对车辆203进行诊断。
97.应理解，图1、或图2所示的架构是为了方便理解而作出的示例性的架构，不作为对第一诊断设备、第二诊断设备的具体限定。一些可能的情况中，第一诊断设备中可以包含更多或者更少的模块，或者第二诊断设备中可以包含更多或者更少的模块。
98.例如，第一api和第二api之间的映射也可以由第二诊断设备完成。示例性地，图3所示为本技术实施例提供的又一种可能的车辆诊断系统的架构示意图。其中客户机301包括j2534应用程序，mvci诊断工具302包括j2534api、d-ppu api、协议、设备驱动和obd接口，车辆303包括电子控制单元ecu。客户机301中运行j2534应用程序，可以产生诊断指令以调
用mvci诊断工具302中j2534 api，由mvci诊断工具302完成j2534api和d-ppu api之间的映射。
99.可选的，第一诊断设备和第二诊断设备可以是独立的，或者集成的。例如，请参见图4，图4是本技术实施例提供的又一种可能的车辆诊断系统的架构示意图。mvci诊断工具401既可以完成图1所示的第一诊断设备101的功能，也可以完成图1所示的第二诊断设备102的功能。一种可能的场景中，mvci诊断工具401包括j2534应用程序、j2534api、d-ppu api、协议、设备驱动和obd接口，车辆402包括电子控制单元ecu。mvci诊断工具401可以用于运行j2534应用程序，产生诊断指令以调用j2534 api。mvci诊断工具401还可以进行j2534api和d-ppu api之间的映射，从而调用d-ppu api实现对车辆的诊断。
100.以下对本技术实施例提供的方法进行介绍。
101.【实施例一】
102.请参见图5，图5是本技术实施例提供的一种可能的车辆诊断方法的流程示意图。可选的，图5所示实施例可以基于图1、图2、图3或图4所示的车辆诊断系统来实现。
103.如图5所示的车辆诊断方法至少包括步骤s501至步骤s503。应理解，本技术为了方便描述，故通过s501至s503这一顺序进行描述，并不旨在限定一定通过上述顺序进行执行。对于上述一个或多个步骤的执行的先后顺序、执行的时间、执行的次数等不做限定。步骤s501至步骤s503具体如下：
104.步骤s501：第一诊断设备通过第一诊断指令调用第一api。
105.其中，第一诊断设备是具有处理能力和数据收发能力的装置。相关描述可以参考前述对第一诊断设备101相关的描述，此处不再赘述。
106.第一诊断指令是第一诊断设备产生的指令，该指令用于调用第一api，实现与车辆诊断相关的功能。可选的，第一诊断指令可以是函数、算法、计算机指令、或者命令等中的一项或者多项。
107.例如，第一诊断设备上存储有(或配置有)诊断软件，第一诊断设备运行诊断软件时，可以执行某一接口函数，该接口函数可以调用第一api。此时，该函数可以看作第一诊断指令。
108.再如，第一诊断设备可以支持与用户进行信息交互，第一诊断设备接收用户在诊断软件所提供的用户界面上输入的第一操作，可以启动车辆诊断服务。例如，启动服务这一业务通过“passthruopen”这一函数来实现，而“passthruopen”这一函数可以调用第一api。此时，“passthruopen”函数可以看作第一诊断指令。
109.第一api是进行通信的数据传输接口。例如，第一诊断设备通过第一api可以与支持第一api的其他设备进行通信。例如，在如图1所示的架构中，若第二诊断设备支持通过第一api进行通信，则第一诊断设备101和第二诊断设备102可以基于第一api进行通信。
110.可选的，第一api可以包含j2534 api、dpduapi等中的一项或者多项。
111.步骤s502：第一诊断设备将第一诊断指令映射为第二诊断指令。
112.其中，第二诊断指令用于调用第二api。可选的，第二诊断指令可以是函数、算法、计算机指令、或者命令等中的一项或者多项。
113.第二api是进行通信的数据传输接口。例如，第一诊断设备通过第二api可以与支持第二api的其他设备进行通信。例如，在如图1所示的架构中，第二诊断设备支持通过第二
api进行通信，此时，第一诊断设备101将第一诊断指令转换为第二诊断指令，则可以基于第二api与第二诊断设备102进行通信。
114.可选的，第二api可以包含j2534 api、dpdu api等中的一项或者多项。
115.一种可能的设计中，第一诊断指令也可以是第一函数，第二诊断指令可以是第二函数。其中，第一函数可以调用第一api，第二函数可以调用第二api。第一诊断设备可以将第一函数映射为第二函数，从而通过第二函数调用第二api。例如，第一诊断设备可以将“passthruopen”函数映射为“pduconstruct”函数，而“pduconstruct”函数可以用于调用第二api。此时，“pduconstruct”函数可以看作第二诊断指令。
116.一种设计中，第一诊断设备可以根据映射关系，将第一诊断指令映射为第二诊断指令。其中，映射关系可以通过表、数据库、堆栈等格式存储，本技术对于映射关系的形式不做限定。
117.示例性的，以第一api为j2534 api，第二api为d-pdu api为例，一种可能的诊断指令的映射关系表可以如表1所示。例如，第一诊断指令是“passthruopen”时，根据表1所示的映射关系，第二诊断指令是“pduconstruct”。再如，第一诊断指令是“passthruclose”时，根据表1所示的映射关系，第二诊断指令是“pdudestruct”。
118.表1映射关系示意表
[0119][0120]
可选的，所述第一诊断指令和/或所述第二诊断指令中可以包含一个或者多个通讯参数。进一步的，在第一诊断指令中包含通讯参数时，第一诊断设备还可以对通讯参数进行映射。
[0121]
例如，第一诊断设备基于通讯参数映射关系，将第一诊断指令中的通讯参数进行映射，得到带通讯参数的第二诊断指令。其中，通讯参数映射关系可以通过表、数据库、堆栈等格式存储，本技术对于映射关系的形式不做限定。
[0122]
示例性的，以第一api为j2534 api，第二api为d-pdu api为例，一种可能的通讯参数映射关系如表2所示。
[0123]
例如，第一诊断指令为“passthruloctl”函数，而“passthruloctl”函数包含通讯参数“loopback”，此时，基于表1和表2所示的映射关系，第一诊断设备可以将“passthruloctl”函数映射为“pdusetcomparam”函数，以及将“passthruloctl”函数中的通讯参数“loopback”映射为“pdusetcomparam”函数中的通讯参数“cp_loopback”。
[0124]
再如，第一诊断指令为“passthruloctl”函数，而“passthruloctl”函数包含通讯参数“five_baud_mod”，此时，基于表1和表2所示的映射关系，第一诊断设备可以将“passthruloctl”函数映射为“pdusetcomparam”函数，以及将“passthruloctl”函数中的通讯参数“five_baud_mod”映射为“pdusetcomparam”函数中的通讯参数“cp_5baudmode”，其余通讯参数映射可以查看表2所示，此处不再一一赘述。
[0125]
表2映射关系示意表
[0126]
j2534 api通讯参数d-pdu api通讯参数loopbackcp_loopbackp3_mincp_p3minfive_baud_modcp_5baudmodeiso15765_bscp_blocksizebs_txcp_blocksizeoverrideiso15765_wft_maxcp_canmaxnumwaitframesp1_maxcp_p1maxp4_mincp_p4minnode_addresscp_testersourceaddressiso15765_stmincp_stminstmin_txcp_stminoverridet1_maxcp_t1maxt2_maxcp_t2maxt3_maxcp_t3maxt4_maxcp_t4maxt5_maxcp_t5maxw0 and tidle and w5cp_tidletinilcp_tiniltwupcp_twupw1cp_w1maxw2cp_w2maxw3cp_w3maxw4cp_w4min
dataratecp_baudratebit_sample_pointcp_bitsamplepointnetwork_linecp_networklineswcan_hs_data_ratecp_changespeedrateswcan_speedchange_enablecp_changespeedctrlswcan_res_switchcp_changespeedresctrlsync_jump_widthcp_syncjumpwidthparity and data_bitscp_uartconfig
[0127]
步骤s503：第一诊断设备通过第二诊断指令调用第二api，以处理第一业务。
[0128]
其中，第一业务与车辆的诊断相关。例如，第一业务可以是启动车辆诊断服务、建立用于诊断的连接联系、控制车辆诊断服务、获取版本信息、或过滤数据等业务中的一项或者多项。或者，第一业务还可以包含表1所示第一业务中的一项或者多项业务。
[0129]
在一种可能的设计中，第一业务可以用于写入和/或读出通讯参数。
[0130]
例如，用户需要打开与车辆连接的第二诊断设备的回显功能，此时，可以通过第一指令中携带通讯参数“loopback”，第一诊断设备将通讯参数“loopback”映射为通讯参数“cp_loopback”，第一诊断设备通过第二api向第二诊断设备写入“cp_loopback”后，可以打开回显功能。
[0131]
在图5所示的实施例中，第一诊断设备将第一诊断指令映射为能够调用第二api的第二诊断指令，从而使得第一诊断设备通过第二api来实现第一api所实现的功能。如此，相当于该第二api作为中间模块实现该第一api与第二诊断设备之间的通信，解决了基于不同api的设备之间的兼容性问题，降低了车辆诊断的成本，提高了诊断设备的服务质量，提升了用户在诊断车辆过程中的体验。
[0132]
【实施例二】
[0133]
一种可能的设计中，请参见图6，图6是本技术实施例提供的又一种可能的车辆诊断方法的流程示意图。可选的，图6所示的车辆诊断方法可以基于前述的车辆诊断系统来实现，例如图1、图2、图3或图4所示的车辆诊断系统来实现。
[0134]
应理解，本技术为了方便描述，故图6所示的顺序进行描述，并不旨在限定一定通过上述顺序进行执行。对于上述一个或多个步骤的执行的先后顺序、执行的时间、执行的次数等不做限定。
[0135]
如图6所示的车辆诊断方法包含步骤s601-步骤s606，其中：
[0136]
步骤s601-步骤s603具体可以参见前述步骤s501-步骤s503中的相关描述，此处不再赘述。
[0137]
步骤s601：第一诊断设备通过第二api监测第一业务的第一处理结果。
[0138]
一种可能的情况中，上述第一处理结果用于指示处理第一业务成功。
[0139]
例如，第一api为j2534 api，第二api为d-pdu api，第一业务为启动服务，此时，第一诊断设备可以通过d-pdu api接收返回的验证结果，此时，该返回的验证结果可以指示处理第一业务成功。
[0140]
例如，第一业务为写入转向助力临界参数，此时，第一诊断设备可以通过第二api接收处理结果。若第一处理结果为“success！”，该第一处理结果可以指示处理第一业务成
功。
[0141]
一种可能的情况中，上述第一处理结果用于指示处理该第一业务失败。例如，第一处理结果为错误码，则指示处理该第一业务失败。
[0142]
例如，d-pdu api中的错误码是pdu_err_sharing_violation，由于设备共享冲突pdu错误，无法处理第一业务，因此可以指示处理第一业务失败。
[0143]
再如，d-pdu api中的错误码是pdu_err_invalid_parameters，由于设备参数无效，无法处理第一业务，因此可以指示处理第一业务失败。
[0144]
步骤s602：第一诊断设备将第一处理结果映射为第一api支持的第二处理结果。
[0145]
例如，第一诊断设备可以将d-pdu api中的函数“pduconstruct”的错误码pdu_err_sharing_violation映射为j2534 api中的函数“passthruopen”的错误码err_device_in_use。此时，err_device_in_use可以看作第二处理结果。
[0146]
可选的，第一诊断设备可以基于映射关系，将第一处理结果映射为第二处理结果。其中，该映射关系可以通过表、数据库、堆栈等格式存储，本技术对于映射关系的形式不做限定。
[0147]
示例性的，以第一api为j2534 api，第二api为d-pdu api为例，一种可能的错误码的映射关系表可以如表3所示。例如，第一诊断指令为“passthruopen”，第二诊断指令为“passconstruct”函数时，第一处理结果为pdu_err_sharing_violation时，根据表3所示的映射关系，第二处理结果为err_device_in_use。再如，第一处理结果为pdu_err_invalid_parameters时，根据表3所示的映射关系，第二处理结果为“err_null_parameter”。
[0148]
表3映射关系示意表
[0149][0150]
步骤s603：第一诊断设备通过所述第一api获取第二处理结果。
[0151]
以上述错误码pdu_err_sharing_violation映射为err_device_in_use为例，第一诊断设备可以接收j2534 api的错误码err_device_in_use。
[0152]
图6所示的实施例中，第一诊断设备不仅可以将第一诊断指令映射为能够调用第二api的第二诊断指令，还能将第二api获取的第一处理结果映射为第一api支持的第二处理结果，以反馈对第一业务的执行情况。
[0153]
以上图5或者图6所示的方法实施例中包含了很多可能的实现方案，下面分别结合图7、图8、图9对其中的部分实现方案进行举例说明。需要说明的是，图7、图8、图9未解释到的相关概念或者操作或者逻辑关系可以参照图5或者图6所示实施例中的相应描述，因此不再赘述。
[0154]
为了方便理解，以下实施例中以第一api为j2534 api、第二api为d-pdu api、第二
诊断设备为mvci诊断工具为例，进行说明。本领域技术人员应当理解，对于其他api、其他形式的第二诊断设备同样适用。
[0155]
【实施例三】
[0156]
请参见图7，图7是本技术实施例提供的一种可能的车辆诊断方法的流程示意图。可选的，该方法可以基于前述的车辆诊断系统来实现，例如图1、图2、图3或图4所示的车辆诊断系统来实现。图7所示的实施例中，第二诊断设备为mvci诊断工具，该mvci诊断工具与车辆相连接，且支持基于第二api的通信。
[0157]
图7所示的车辆诊断方法包括但不限于如下步骤：
[0158]
步骤s701：第一诊断设备通过第一诊断指令调用第一api。
[0159]
例如，第一诊断指令可以是包含于诊断软件中的“passthruopen”函数，该诊断软件例如可以是基于j2534 api开发的。第一诊断设备运行该诊断软件，可以通过“passthruopen”函数调用j2534 api。
[0160]
步骤s702：第一诊断设备将第一诊断指令映射为第二诊断指令，该第二诊断指令用于调用第二api。
[0161]
例如，第一诊断设备将“passthruopen”函数映射为“pduconstruct”函数，而通过“pduconstruct”函数可以调用第二api。
[0162]
步骤s703：第一诊断设备通过第二诊断指令调用第二api，以处理第一业务。
[0163]
例如，第一诊断设备通过“pduconstruct”函数可以调用d-pdu api，而“pduconstruct”函数具体用于通过第二api实现“启动服务”这一业务。
[0164]
可选的，在处理第一业务的过程中，第一诊断设备还可以进行一次或者多次关于诊断指令、通讯参数、返回结果、错误码的映射，本技术对于第一诊断设备的映射次数不做限定。
[0165]
例如，如图7所述，第一诊断设备通过“pduconstruct”函数调用d-pdu api后，可以接收d-pdu api的响应。第一诊断设备接收响应后，可以继续进行函数映射，得到第二api的“pdugetmoduleids”，该函数用于验证mvci诊断工具。可以看出，第一诊断设备可以通过第二api与mvci诊断工具进行通信。
[0166]
进一步的，第一诊断设备可以通过d-pdu api接收返回的验证结果。第一诊断设备可以通过将d-pdu api接收的“d-pdu返回值”映射为“j2534返回值”，从而诊断软件可以根据该返回值了解第一业务的处理结果。
[0167]
【实施例四】
[0168]
请参见图8，图8是本技术实施例提供的一种可能的车辆诊断方法的流程示意图。可选的，该方法可以基于前述的车辆诊断系统来实现，例如图1、图2、图3或图4所示的车辆诊断系统来实现。图8所示的实施例中，第二诊断设备为mvci诊断工具，该mvci诊断工具与车辆相连接，且支持基于第二api的通信。
[0169]
图8所示的车辆诊断方法包括但不限于如下步骤：
[0170]
步骤s801：第一诊断设备通过第一诊断指令调用第一api。
[0171]
例如，第一诊断指令可以是包含于诊断软件中的“passthruioctrl”函数，该诊断软件例如可以是基于j2534 api开发的。第一诊断设备运行该诊断软件，可以通过“passthruioctrl”函数调用j2534 api。
[0172]
步骤s802：第一诊断设备将第一诊断指令映射为第二诊断指令，该第二诊断指令用于调用第二api。
[0173]
例如，第一诊断设备将“passthruioctrl”函数映射为“pdusetcomparam”函数，而通过“pdusetcomparam”函数可以调用第二api。
[0174]
步骤s803：第一诊断设备通过第二诊断指令调用第二api，以处理第一业务。
[0175]
例如，第一诊断设备通过“pdusetcomparam”函数可以调用d-pdu api，而“pdusetcomparam”函数具体用于通过第二api实现“协议参数配置”这一业务。
[0176]
可选的，在处理第一业务的过程中，第一诊断设备还可以进行一次或者多次关于诊断指令、通讯参数、返回结果、错误码的映射，本技术对于第一诊断设备的映射次数不做限定。
[0177]
例如，如图8所示，用户需要打开与车辆连接的mvci诊断工具的回显功能，此时，第一诊断设备可以通过“passthruioctrl”函数携带通讯参数“loopback”，第一诊断设备可以将“passthruioctrl”函数携带的通讯参数“loopback”映射为“pdusetcomparam”函数携带的通讯参数“cp_loopback”，第一诊断设备通过第二api向mvci诊断工具写入“cp_loopback”后，可以打开回显功能。可以看出，第一诊断设备可以通过第二api与mvci进行通信。
[0178]
进一步的，第一诊断设备可以通过d-pdu api接收mvci诊断工具回显功能的使能返回结果。第一诊断设备可以通过将d-pdu api接收的“d-pdu返回值”映射为“j2534返回值”，从而诊断软件可以根据该返回值了解第一业务的处理结果。例如，d-pdu返回值为pdu_status_noerror，j2534返回值为status_noerror，此时，第一业务的处理结果表明使能成功。
[0179]
【实施例五】
[0180]
请参见图9，图9是本技术实施例提供的一种可能的车辆诊断方法的流程示意图。可选的，该方法可以基于前述的车辆诊断系统来实现，例如图1、图2、图3或图4所示的车辆诊断系统来实现。图9所示的实施例中，第二诊断设备为mvci诊断工具，该mvci诊断工具与车辆相连接，且支持基于第二api的通信。
[0181]
图9所示的车辆诊断方法包括但不限于如下步骤：
[0182]
步骤s901：第一诊断设备通过第一诊断指令调用第一api。
[0183]
步骤s902：第一诊断设备将第一诊断指令映射为第二诊断指令。
[0184]
步骤s903：第一诊断设备通过第二诊断指令调用第二api，以处理第一业务。
[0185]
步骤s904：第一诊断设备通过第二api监测第一业务的第一处理结果。
[0186]
可选的，上述第一处理结果可以用于指示处理该第一业务失败。例如，第一处理结果为错误码，则指示处理该第一业务失败。
[0187]
例如，d-pdu api中的错误码是pdu_err_sharing_violation，由于设备共享冲突pdu错误，无法处理第一业务，因此可以指示处理第一业务失败。
[0188]
可选的，在处理第一业务的过程中，第一诊断设备还可以进行一次或者多次关于诊断指令、返回结果、错误码的映射，本技术对于第一诊断设备的映射次数不做限定。
[0189]
例如，如图9所述，第一诊断设备通过“pduconstruct”函数调用d-pdu api后，可以接收d-pdu api的返回错误值。第一诊断设备接收返回错误值后，可以继续进行函数映射，
得到d-pdu api的“pdugetmoduleids”。
[0190]
进一步的，在函数映射得到第二api的“pdugetmoduleids”之后，第一诊断设备可以通过d-pdu api监测处理结果，并可以通过将d-pdu api接收的“d-pdu返回值pdu_err_pduapi_not_constructed”映射为“j2534返回值err_device_in_use”。
[0191]
步骤s905：第一诊断设备将第一处理结果映射为第一api支持的第二处理结果。
[0192]
例如，第一诊断设备可以将d-pdu api中的函数“pduconstruct”的错误码pdu_err_sharing_violation映射为j2534 api中的函数“passthruopen”的错误码err_device_in_use。此时，err_device_in_use可以看作第二处理结果。
[0193]
步骤s906：第一诊断设备通过第一api获取第二处理结果。
[0194]
图9所示的实施例中，第一诊断设备不仅可以将第一诊断指令映射为能够调用第二api的第二诊断指令，还能将第二api获取的第一处理结果映射为第一api支持的第二处理结果，以反馈对第一业务的执行情况。
[0195]
上述详细阐述了本技术实施例的方法，下面提供本技术实施例的装置。
[0196]
可以理解的是，本技术实施例提供的多个装置，例如车辆诊断装置100等，为了实现上述方法实施例中的功能，其包含了执行各个功能相应的硬件结构、软件单元、或硬件结构和软件结构的组合等。本领域技术人员应该很容易意识到，结合本文中所提供的实施例描述的各示例的单元及算法步骤，本技术实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以在不同的使用场景中，使用不同的装置实现方式来实现前述的方法实施例，对于装置的不同实现方式不应认为超出本技术实施例的范围。
[0197]
请参见图10，图10是本技术实施例提供的一种车辆诊断装置100的结构示意图。可选的，该车辆诊断装置100可以为整机，也可以为整机中的一个器件，例如芯片、软件模块、集成电路等。
[0198]
如图10，该车辆诊断装置100包含调用单元1001和映射单元1002。该车辆诊断装置100用于实现前述的车辆诊断装置方法，例如图5、图6、图7、图8或图10所示实施例中的车辆诊断方法。
[0199]
一种可能的实施方式中，调用单元1001，用于通过第一诊断指令调用第一api；
[0200]
映射单元1002，用于将该第一诊断指令映射为第二诊断指令，该第二诊断指令用于调用第二api；
[0201]
调用单元1003，还用于通过该第二诊断指令调用该第二api，以处理第一业务，该第一业务与该车辆的诊断相关。
[0202]
在第一种可能的实施方式中，上述诊断装置100为第一诊断设备。或者，该诊断装置包含于第一诊断设备中，例如，诊断装置为第一诊断设备中的芯片、硬件模块、或软件模块等。
[0203]
可选的，上述诊断装置100用于通过第二诊断设备对车辆进行诊断，该第二诊断设备支持基于第二应用程序接口api的通信。
[0204]
在一种可能的实施方式中，上述第二诊断设备为支持d-pdu api的诊断盒。
[0205]
在一种可能的实施方式中，第二api为d-pdu api，第一api为j2534 api。
[0206]
在一种可能的实施方式中，上述第一业务包含以下业务中的一项或者多项：
[0207]
启动服务、建立连接链路、断开连接链路、关闭服务、控制服务、单向收发、双向收发、协议参数配置、过滤数据、硬件控制、获取版本信息、错误处理。
[0208]
在一种可能的实施方式中，上述第一业务用于写入通讯参数和/或读取通讯参数。
[0209]
在一种可能的实施方式中，该诊断装置还包括通信单元1003，其中：
[0210]
通信单元1003，用于通过第二api监测第一业务的第一处理结果；
[0211]
映射单元1002，还用于将该第一处理结果映射为该第一api支持的第二处理结果；
[0212]
通信单元1003，还用于通过该第一api获取该第二处理结果。
[0213]
在一种可能的实施方式中，上述第一处理结果指示处理第一业务成功；或者，该第一结果为错误码，该错误码指示处理该第一业务失败。
[0214]
在一种可能的实施方式中，装置还包括：
[0215]
处理单元1004，用于运行诊断软件，第一诊断指令来自该诊断软件。
[0216]
请参见图11，图11是本技术实施例提供的一种车辆诊断设备110的结构示意图，该诊断设备110可以为独立设备(例如服务器、或用户设备等中的一个或者多个)，也可以为独立设备内部的部件(例如芯片、软件模块或者硬件模块等)。该诊断设备110可以包括至少一个处理器1101。可选的还可以包括至少一个存储器1102。进一步可选的，诊断设备110还可以包括通信接口1103。更进一步可选的，还可以包含总线，其中，处理器1101、存储器1102和通信接口1103通过总线相连。
[0217]
其中，处理器1101(例如中央处理器(central processing unit，cpu))是计算核心以及控制核心，其可以产生指令以及进行计算处理，例如：cpu可以在车载设备内部结构之间传输各类交互数据，等等。
[0218]
存储器1102用于存放程序和数据。可以理解的是，此处的存储器1102既可以包括内置存储器，当然也可以包括扩展存储器。可循的，存储空间可以存储操作系统及其他数据，可包括但不限于：android系统、ios系统、windows phone系统等等，本技术对此并不作限定。
[0219]
通信接口1103可选的可以包括标准的有线通信器或接口、无线通信器或接口，如wi-fi模块、移动通信接口等，受处理器1101的控制可以用于收发数据。
[0220]
该诊断设备110中的至少一个处理器1101用于调用存储器中的计算机程序，以执行前述的版本管理方法，例如图5、图6、图7、图8或图9所示实施例所描述的版本管理方法。
[0221]
一种可能的设计中，该诊断设备110中的至少一个处理器1101用于调用计算机程序，以实现以下操作：
[0222]
通过第一诊断指令调用第一api；
[0223]
将该第一诊断指令映射为第二诊断指令，该第二诊断指令用于调用第二api；
[0224]
通过该第二诊断指令调用该第二api，以处理第一业务，该第一业务与该车辆的诊断相关。
[0225]
在一种可能的实施方式中，第一诊断指令包含第一函数，第二诊断指令包含第二函数，在将该第一诊断指令映射为第二诊断指令，该第二诊断指令用于调用第二api方面，该处理器用于：
[0226]
将该第一函数映射为该第二函数，该第二函数用于调用第二api。
[0227]
在一种可能的实施方式中，上述诊断设备110为第一诊断设备。或者，该诊断设备110包含于第一诊断设备中，例如，诊断设备为第一诊断设备中的芯片、硬件模块、或软件模块等。
[0228]
可选的，上述诊断设备110用于通过第二诊断设备对车辆进行诊断，该第二诊断设备支持基于第二应用程序接口api的通信。
[0229]
在又一种可能的实施方式中，在通过第一诊断指令调用第一api之前，处理器1101还用于：
[0230]
运行诊断软件，该第一诊断指令来自该诊断软件。
[0231]
在又一种可能的实施方式中，上述第二诊断设备为支持d-pdu api的诊断盒。
[0232]
在又一种可能的实施方式中，第二api为d-pdu api，第一api为j2534api。
[0233]
在又一种可能的实施方式中，上述第一业务包含以下业务中的一项或者多项：
[0234]
启动服务、建立连接链路、断开连接链路、关闭服务、控制服务、单向收发、双向收发、协议参数配置、过滤数据、硬件控制、获取版本信息、错误处理。
[0235]
在又一种可能的实施方式中，上述第一业务用于写入通讯参数和/或读取通讯参数。
[0236]
在又一种可能的实施方式中，处理器1101还用于：
[0237]
通过第二api监测第一业务的第一处理结果；
[0238]
将该第一处理结果映射为第一api支持的第二处理结果；
[0239]
通过该第一api获取该第二处理结果。
[0240]
在又一种可能的实施方式中，上述第一处理结果用于指示处理第一业务成功；或者，该第一处理结果为错误码，该错误码指示处理该第一业务失败。
[0241]
本技术实施例提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，当其在处理器上运行时，实现第一方面提供的车辆诊断方法。
[0242]
本技术实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本技术中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
[0243]
本技术实施例使用“第一”、“第二”等序数词是用于对多个对象进行区分，不用于限定多个对象的顺序、时序、优先级或者重要程度。例如，第一诊断指令和第二诊断指令，只是为了便于描述，而并不是表示这第一诊断指令和第二诊断指令的顺序、重要程度等的不同。
[0244]
需要说明的是，对于前述的各个方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本技术并不受所描述的动作顺序的限制，因为依据本技术，某一些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本技术所必须的。
[0245]
本技术实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减。
[0246]
本技术实施例装置中的模块可以根据实际需要进行合并、划分和删减。
[0247]
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可
以通过程序来指令相关的硬件来完成，该程序可以存储于计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器(read-only memory，rom)、随机存取器(random access memory，ram)、磁盘或光盘等。
[0248]
以上所揭露的仅为本技术一种较佳实施例而已，当然不能以此来限定本技术之权利范围，本领域普通技术人员可以理解实现上述实施例的全部或部分流程，并依本技术权利要求所作的等同变化，仍属于发明所涵盖的范围。