CN114003018A

CN114003018A - Vehicle diagnosis method and related device

Info

Publication number: CN114003018A
Application number: CN202111241830.XA
Authority: CN
Inventors: 刘均; 喻东
Original assignee: Shenzhen Launch Technology Co Ltd
Current assignee: Shenzhen Launch Technology Co Ltd
Priority date: 2021-10-25
Filing date: 2021-10-25
Publication date: 2022-02-01

Abstract

The embodiment of the application provides a vehicle diagnosis method and a related device, wherein the method is applied to a first diagnosis device, the first diagnosis device is used for diagnosing a vehicle through a second diagnosis device, and the second diagnosis device supports communication based on a second Application Program Interface (API), and the method comprises the following steps: the first diagnosis equipment calls a first API through a first diagnosis instruction; mapping the first diagnostic instruction into a second diagnostic instruction, wherein the second diagnostic instruction is used for calling a second API; the second API is invoked via the second diagnostic instruction to process a first service, the first service being associated with a diagnosis of the vehicle. By adopting the embodiment of the application, the compatibility problem among equipment based on different APIs can be solved, and the cost of vehicle diagnosis is reduced.

Description

Vehicle diagnosis method and related device

Technical Field

The present application relates to the field of vehicle electronics, and in particular, to a vehicle diagnostic method and related apparatus.

Background

With the improvement of the quality of life of people and the development of traffic technologies, the number and the types of vehicles are gradually increased, the time and the frequency of using the vehicles by people are higher and higher, and the safety of the vehicles is more and more important. To improve the safety of the vehicle, the vehicle is diagnosed. In the process of diagnosing the vehicle, the vehicle is connected with the diagnostic box, so that the diagnostic data of the vehicle is acquired. The diagnostic data includes status and fault information of the vehicle.

The diagnostic cartridges typically require their operation to be controlled by diagnostic software in an upper computer. The types of communication interfaces used by diagnostic software developed by different vendors vary. When the diagnosis box is used for diagnosing the vehicle, the diagnosis box corresponding to the diagnosis software (the diagnosis box is matched with a communication interface of the diagnosis software) is needed to diagnose the vehicle fault, and the user experience is poor. For example, a Diagnostic box purchased by a user only supports communication over a communication interface based on a Diagnostic Protocol Data Unit (D-PDU), and if Diagnostic software used when the user diagnoses a vehicle is developed over a communication interface based on J2534, the Diagnostic software and the Diagnostic box are not compatible with each other, and diagnosis of the vehicle cannot be completed, and it is necessary to additionally purchase a Diagnostic box that supports development over a communication interface based on J2534.

How to solve the above problems is a hot issue of research by those skilled in the art.

Disclosure of Invention

The embodiment of the Application discloses a vehicle diagnosis method and a related device, which can solve the compatibility problem among devices based on different Application Programming Interfaces (APIs), and reduce the cost of vehicle diagnosis.

In a first aspect, an embodiment of the present application provides a vehicle diagnostic method, including:

calling a first API through a first diagnosis instruction;

mapping the first diagnostic instruction into a second diagnostic instruction, wherein the second diagnostic instruction is used for calling a second API;

the second API is invoked via the second diagnostic instruction to process a first service, the first service being associated with a diagnosis of the vehicle.

Optionally, the method may be implemented by a first diagnostic device, where the first diagnostic device is configured to diagnose the vehicle through a second diagnostic device, and the second diagnostic device supports communication based on a second application program interface API.

In the method, the first diagnostic instruction is mapped into a second diagnostic instruction capable of calling a second API, so that the first diagnostic device realizes the function realized by the first API through the second API. Therefore, the second API is used as an intermediate module to realize the communication between the first API and the second diagnosis equipment, the compatibility problem between equipment based on different APIs is solved, the vehicle diagnosis cost is reduced, the service quality of the diagnosis equipment is improved, and the experience of a user in the vehicle diagnosis process is improved.

For example, the diagnostic box purchased by the user only supports communication based on the second API, and if the user diagnoses the vehicle, the used diagnostic software is the diagnostic software developed by the first API.

In a possible implementation manner of the first aspect, the first diagnostic instruction includes a first function, the second diagnostic instruction includes a second function, and the first diagnostic instruction is mapped to the second diagnostic instruction, where the second diagnostic instruction is used to call the second API, and the method includes: and mapping the first function into the second function, wherein the second function is used for calling a second API.

In a possible implementation manner of the first aspect, before the calling the first API by the first diagnostic instruction, the method further includes:

and running the diagnosis software, wherein the first diagnosis instruction comes from the diagnosis software. The diagnostic software may be a computer program (or a software module, a software and hardware combination module, etc.) developed based on the first API, or the diagnostic software needs to call the first API to implement a function during running.

It can be seen that a computer program developed based on the first API may be run in the first diagnostic device to diagnose the vehicle. Therefore, by the method, only the first diagnostic equipment and the second diagnostic equipment are needed, so that the computer program (or other software modules) developed based on the first API can be tested (or operated), and the computer program (or other software modules) developed based on the second API can also be tested (or operated), so that the testing and operating cost of the diagnostic software is reduced, the efficiency of the testing (operating) program is improved, and the service quality provided by the diagnostic equipment is improved.

In a possible implementation manner of the first aspect, the second diagnostic device is a diagnostic box supporting a D-PDU API.

In one possible implementation of the first aspect, the second API is a D-PDU API and the first API is a J2534 API.

It can be seen that the J2534API can communicate with the diagnostic box supporting the D-PDU API through the D-PDU API, and conversely, the computer program developed based on the J2534API can be tested (or run) and verified through the diagnostic box supporting the D-PDU API, so that the test and running cost of the diagnostic software supporting the J2534API is reduced, the efficiency of testing the program supporting the J2534API is improved, and the service quality provided by the diagnostic equipment is improved.

In addition, through the method, the first diagnostic equipment can realize the functions of the J2534API through the D-PDU API, so that the development period of the J2534API is reduced, and the period for confirming the functions of the J2534API is also reduced.

In a possible implementation manner of the first aspect, the first service includes one or more of the following services:

starting service, establishing a connection link, disconnecting the connection link, closing service, controlling service, unidirectional transceiving, bidirectional transceiving, protocol parameter configuration, filtering data, controlling hardware, acquiring version information and processing errors.

By the aid of the method, one or more diagnosis services among vehicles can be completed, various service requirements of a user in a vehicle diagnosis process can be met, vehicle diagnosis efficiency and service quality are improved, and user experience is improved.

In a possible implementation manner of the first aspect, the first service is used for writing communication parameters and/or reading communication parameters.

Optionally, the first service is used to write and/or read communication parameters, and the first diagnostic instruction and/or the second diagnostic instruction may carry parameters. In this case, the first diagnostic device may also perform mapping of parameters to meet various business requirements of the user in the vehicle diagnostic process.

In a possible implementation manner of the first aspect, the method further includes:

monitoring a first processing result of the first service through a second API;

mapping the first processing result to a second processing result supported by the first API;

and acquiring the second processing result through the first API.

In the foregoing embodiment, not only the first diagnostic instruction may be mapped to a second diagnostic instruction capable of calling the second API, but also the first processing result obtained by the second API may be mapped to a second processing result supported by the first API, so as to feed back the execution condition of the first service.

In a possible implementation manner of the first aspect, the first processing result is used to indicate that processing the first service is successful; or, the first processing result is an error code indicating that processing the first service fails.

In the above embodiment, the processing result can inform the user whether the first service is successfully processed, so that the user performs operations such as ending diagnosis, retrying, debugging a program and the like according to the processing result, and the requirement of the user for obtaining the processing result of the first service is met.

In a second aspect, an embodiment of the present application provides a diagnostic apparatus, including:

the calling unit is used for calling the first API through the first diagnosis instruction;

the mapping unit is used for mapping the first diagnosis instruction into a second diagnosis instruction, and the second diagnosis instruction is used for calling a second API;

and the calling unit is also used for calling the second API through the second diagnosis instruction so as to process the first service, and the first service is relevant to the diagnosis of the vehicle.

In a possible implementation manner of the second aspect, the first diagnostic instruction includes a first function, the second diagnostic instruction includes a second function, and in mapping the first diagnostic instruction to the second diagnostic instruction, the second diagnostic instruction is configured to call the second API, the mapping unit is configured to: and mapping the first function into the second function, wherein the second function is used for calling a second API.

In one possible embodiment of the second aspect, the diagnostic device is a first diagnostic apparatus. Alternatively, the diagnostic device is included in the first diagnostic apparatus, for example, the diagnostic device is a chip, a hardware module, a software module, or the like in the first diagnostic apparatus.

Optionally, the diagnostic apparatus is configured to diagnose the vehicle through a second diagnostic device, where the second diagnostic device supports communication based on a second application program interface API.

In one possible embodiment of the second aspect, the second diagnostic device is a diagnostic box supporting a D-PDU API.

In one possible embodiment of the second aspect, the second API is a D-PDU API and the first API is a J2534 API.

In a possible implementation manner of the second aspect, the first service includes one or more of the following services:

In a possible embodiment of the second aspect, the first service is used for writing communication parameters and/or reading communication parameters.

In one possible embodiment of the second aspect, the diagnostic device further comprises a communication unit, wherein:

the communication unit is used for monitoring a first processing result of the first service through the second API;

the mapping unit is further used for mapping the first processing result into a second processing result supported by the first API;

and the communication unit is also used for acquiring the second processing result through the first API.

In a possible implementation manner of the second aspect, the first processing result indicates that processing the first service is successful; or, the first result is an error code indicating that processing the first service failed.

In one possible implementation of the second aspect, the apparatus further comprises:

and the processing unit is used for running the diagnostic software, and the first diagnostic instruction comes from the diagnostic software.

In a third aspect, an embodiment of the present application provides a diagnostic apparatus, which includes a processor, a memory, and a computer program stored in the memory and executable on the processor, and when the processor executes the computer program, the vehicle diagnostic method provided in the first aspect or any one of the possible embodiments of the first aspect is implemented.

In one possible implementation of the third aspect, the processor is configured to invoke a computer program to implement the following operations:

calling a first API through a first diagnosis instruction;

In a possible implementation manner of the third aspect, the first diagnostic instruction includes a first function, the second diagnostic instruction includes a second function, and in mapping the first diagnostic instruction to the second diagnostic instruction, the second diagnostic instruction is configured to call the second API, the processor is configured to: and mapping the first function into the second function, wherein the second function is used for calling a second API.

In yet another possible implementation of the third aspect, the diagnostic device is a first diagnostic device. Alternatively, the diagnostic device is included in the first diagnostic device, for example, the diagnostic device is a chip, a hardware module, a software module, or the like in the first diagnostic device.

Optionally, the diagnostic device is configured to diagnose the vehicle through a second diagnostic device, where the second diagnostic device supports communication based on a second application program interface API.

In yet another possible implementation manner of the third aspect, before the calling the first API through the first diagnostic instruction, the processor is further configured to:

and running the diagnosis software, wherein the first diagnosis instruction comes from the diagnosis software.

In yet another possible implementation manner of the third aspect, the second diagnostic device is a diagnostic box supporting a D-PDU API.

In yet another possible embodiment of the third aspect, the second API is a D-PDU API and the first API is a J2534 API.

In yet another possible implementation manner of the third aspect, the first service includes one or more of the following services:

In yet another possible implementation manner of the third aspect, the first service is used for writing communication parameters and/or reading communication parameters.

In yet another possible implementation of the third aspect, the processor is further configured to:

monitoring a first processing result of the first service through a second API;

and acquiring the second processing result through the first API.

In yet another possible implementation manner of the third aspect, the first processing result is used to indicate that processing the first service is successful; or, the first processing result is an error code indicating that processing the first service fails.

In a fourth aspect, the present application provides a computer-readable storage medium, in which a computer program is stored, and when the computer program runs on a processor, the vehicle diagnosis method provided in the first aspect is implemented.

It is to be understood that the diagnostic device provided by the third aspect, the diagnostic apparatus provided by the third aspect, and the computer-readable storage medium provided by the fourth aspect are all used to implement the vehicle diagnostic method provided by the first aspect, and therefore, the beneficial effects achieved by the diagnostic device can be referred to in the vehicle diagnostic method provided by the first aspect. And will not be described in detail herein.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings used in the embodiments of the present application will be briefly described below.

FIG. 1 is a schematic diagram of an architecture of a vehicle diagnostic system provided by an embodiment of the present application;

FIG. 2 is a schematic diagram of an architecture of a vehicle diagnostic system provided by an embodiment of the present application;

FIG. 3 is a schematic block diagram of another vehicle diagnostic system provided in an embodiment of the present application;

FIG. 4 is a schematic block diagram of another vehicle diagnostic system provided in an embodiment of the present application;

FIG. 5 is a schematic flow chart diagram of a vehicle diagnostic method provided by an embodiment of the present application;

FIG. 6 is a schematic flow chart diagram illustrating yet another vehicle diagnostic method provided by an embodiment of the present application;

FIG. 7 is a schematic flow chart diagram of a vehicle diagnostic method provided by an embodiment of the present application;

FIG. 8 is a schematic flow chart diagram of a vehicle diagnostic method provided by an embodiment of the present application;

FIG. 9 is a schematic flow chart diagram of a vehicle diagnostic method provided by an embodiment of the present application;

fig. 10 is a schematic structural diagram of a vehicle diagnostic apparatus provided in an embodiment of the present application;

fig. 11 is a schematic structural diagram of a vehicle diagnostic apparatus provided in an embodiment of the present application.

Detailed Description

Referring to fig. 1, fig. 1 is a schematic structural diagram of a vehicle diagnostic system provided in an embodiment of the present application, and includes a first diagnostic device 101, a second diagnostic device 102, and a vehicle 103.

The first diagnostic apparatus 101 is a device having a processing capability and a data transmission/reception capability. The first diagnostic apparatus 101 may generate a diagnostic instruction or run diagnostic software, thereby implementing a service related to diagnosis of the vehicle 103. For example, the first diagnostic device 101 may be a Computer, a notebook, a tablet, a palm top Computer, a desktop, a diagnostic apparatus, a mobile phone, an Ultra-mobile Personal Computer (UMPC), a netbook, a Personal Digital Assistant (PDA), or other terminal devices. In some possible scenarios, the first diagnostic device 101 may also be referred to as a host computer, or as a client (client).

The second diagnostic device 102 is a device connected to the vehicle 103, and has a data transmission/reception function. In performing the diagnosis, the second diagnostic apparatus 102 is configured to obtain information of the vehicle 103, such as one or more items of identity information, fault information, or status information of the vehicle. For example, the second diagnostic device 102 is connected with the vehicle 103 by an On-Board Diagnostics (OBD) interface connector. It should be understood that the OBD interface described herein includes one or more of a type i OBD interface (first generation OBD), or a type II OBD interface (On-Board Diagnostics II, OBD II), etc.

Alternatively, the second diagnostic device 102 may be referred to as a diagnostic tool, or as a diagnostic cartridge. Illustratively, the second diagnostic device 102 is a Modular Vehicle Communication Interface (MVCI) diagnostic tool.

The vehicle 103 refers to a vehicle that can move. A vehicle may typically include a plurality of nodes. A node herein refers to a device having data acquisition capability, or data transceiving capability, or data processing capability. For example, a node may include one or more of an Electronic Control Unit (ECU), a Micro Control Unit (MCU), a Multi Domain Controller (MDC), and the like. As another example, a node may comprise one or more of a gateway, a switch, a router, a bluetooth module, or the like. As another example, a node may include one or more of an acceleration sensor, a velocity sensor, or a temperature sensor, among others.

A communication connection may be established between the first diagnostic device 101 and the second diagnostic device 102, and the first diagnostic device 101 may diagnose the vehicle 103 through the second diagnostic device 102. The first diagnostic device 101 and the second diagnostic device 102 may be connected wirelessly through bluetooth, wireless network, etc., or may be connected through Universal Serial Bus (USB) or asynchronous transfer standard interface RS-232.

Further, the second diagnostic device may feed back information of the vehicle to the first diagnostic device 200, and the first diagnostic device 200 may perform corresponding analysis and processing on the information fed back by the second diagnostic device.

For example, the second diagnostic device 102 may be connected to the vehicle 103 through an OBD interface to obtain information of the vehicle. For example, data of an ECU in the vehicle is acquired. And the first diagnostic apparatus 101 may control the second diagnostic apparatus 102 through diagnostic software (or diagnostic instructions) to perform a service related to diagnosis of the vehicle 103. Optionally, a user interface may also be presented in the first diagnostic apparatus 101, in which the first diagnostic apparatus 101 may select a service to be completed based on an operation of the user.

And an adaptive communication interface is needed for communication between the second diagnostic device 102 and the first diagnostic device 101. For example, the second diagnostic device 102 supports communication based on the second API, and the diagnostic software (or other module that can generate diagnostic instructions) in the first diagnostic device 101 is developed based on the first API, and the vehicle 103 cannot be diagnosed between the diagnostic software and the second diagnostic device 102.

In this embodiment of the application, the first diagnostic device 101 controls the second diagnostic device 102 to complete a diagnostic service through a diagnostic instruction. The first diagnostic device 101 may specifically map the first diagnostic instruction into a second diagnostic instruction capable of calling a second API, so that the first diagnostic device 101 implements the function implemented by the first API through the second API.

In one design, please refer to fig. 2, and fig. 2 is a schematic diagram illustrating a possible vehicle diagnostic system according to an embodiment of the present disclosure. As shown in FIG. 2, the client 201 may be considered a first diagnostic device 101 and the MVCI diagnostic tool 202 may be considered a second diagnostic device 102. Among other things, the client 201 includes a J2534 application, a J2534API, and a D-PPU API, and the MVCI diagnostic tool 202 includes a protocol, a device driver, and an OBD interface. The protocol is a convention for controlling data transmission by two communication parties, the convention comprises a unified provision for problems such as data format, synchronization mode, transmission speed, transmission step, error detection and correction mode, control character definition and the like, and the two communication parties abide by the convention. The device driver refers to a file used by an operating system to operate input and output devices, and is responsible for transmitting the request of the operating system and converting the request into a command which can be understood by a specific physical device controller. Wherein the client 201 calls the J2534API by running the J2534 application and the client 201 can map the first diagnostic directive to a second diagnostic directive that can call the D-PPU API, such that the client 201 can diagnose the vehicle 203 by communicating with the MVCI diagnostic tool 202 that supports the D-PPU API.

It should be understood that the architecture shown in fig. 1 or fig. 2 is an exemplary architecture for facilitating understanding, and is not a specific limitation to the first diagnostic apparatus or the second diagnostic apparatus. In some possible cases, more or fewer modules may be included in the first diagnostic device, or more or fewer modules may be included in the second diagnostic device.

For example, the mapping between the first API and the second API may also be done by the second diagnostic device. For example, fig. 3 is a schematic diagram illustrating an architecture of yet another possible vehicle diagnostic system provided in the embodiment of the present application. Where the client 301 includes a J2534 application, the MVCI diagnostic tool 302 includes a J2534API, a D-PPU API, a protocol, a device driver, and an OBD interface, and the vehicle 303 includes an electronic control unit ECU. A J2534 application running on the client 301 may generate diagnostic instructions to call the J2534API in the MVCI diagnostic tool 302, and the MVCI diagnostic tool 302 may map the J2534API to the D-PPU API.

Alternatively, the first diagnostic device and the second diagnostic device may be separate or integrated. For example, please refer to fig. 4, fig. 4 is a schematic diagram of an architecture of another possible vehicle diagnostic system provided by the embodiment of the present application. The MVCI diagnostic tool 401 may perform the functions of the first diagnostic apparatus 101 shown in fig. 1, or may perform the functions of the second diagnostic apparatus 102 shown in fig. 1. In one possible scenario, the MVCI diagnostic tool 401 includes a J2534 application, a J2534API, a D-PPU API, a protocol, a device driver, and an OBD interface, and the vehicle 402 includes an Electronic Control Unit (ECU). The MVCI diagnostic tool 401 may be used to run a J2534 application, generating diagnostic instructions to call the J2534 API. The MVCI diagnostic tool 401 may also perform a mapping between the J2534API and the D-PPU API, thereby calling the D-PPU API to perform a diagnosis of the vehicle.

The method provided by the embodiment of the application is described below.

[ EXAMPLES one ]

Referring to fig. 5, fig. 5 is a schematic flowchart of a possible vehicle diagnosis method according to an embodiment of the present disclosure. Alternatively, the embodiment shown in fig. 5 may be implemented based on the vehicle diagnostic system shown in fig. 1, 2, 3, or 4.

The vehicle diagnostic method shown in fig. 5 includes at least steps S501 to S503. It should be understood that the present application is described in the order of S501 to S503 for convenience of description, and is not intended to limit execution to the order described above. The execution sequence, execution time, execution times and the like of one or more steps are not limited. The steps S501 to S503 are specifically as follows:

step S501: the first diagnostic device calls the first API through the first diagnostic instruction.

Wherein the first diagnostic device is an apparatus having processing capabilities and data transceiving capabilities. The related description may refer to the description related to the first diagnostic apparatus 101, which is not repeated herein.

The first diagnostic instruction is an instruction generated by the first diagnostic device, and the instruction is used for calling the first API to implement a function related to vehicle diagnosis. Alternatively, the first diagnostic instruction may be one or more of a function, an algorithm, a computer instruction, a command, or the like.

For example, the first diagnostic device has stored (or configured) diagnostic software thereon, and when the first diagnostic device runs the diagnostic software, the first diagnostic device may execute a certain interface function, and the interface function may call the first API. At this time, the function may be regarded as a first diagnostic instruction.

For another example, a first diagnostic device may support information interaction with a user, and the first diagnostic device may receive a first operation input by the user on a user interface provided by the diagnostic software and may initiate a vehicle diagnostic service. For example, the service of starting service is realized by a function of 'passthruoopen', and the function of 'passthruoopen' can call the first API. At this time, the "passthruoopen" function may be regarded as the first diagnostic instruction.

The first API is a data transfer interface that communicates. For example, a first diagnostic device may communicate with other devices that support a first API through the first API. For example, in the architecture shown in fig. 1, if the second diagnostic device supports communication through the first API, the first diagnostic device 101 and the second diagnostic device 102 may communicate based on the first API.

Optionally, the first API may include one or more of a J2534API, a DPDUAPI, and the like.

Step S502: the first diagnostic device maps the first diagnostic instruction to a second diagnostic instruction.

Wherein the second diagnostic instruction is to invoke a second API. Alternatively, the second diagnostic instruction may be one or more of a function, an algorithm, a computer instruction, a command, or the like.

The second API is a data transfer interface for communication. For example, a first diagnostic device may communicate with other devices that support a second API through the second API. For example, in the architecture shown in fig. 1, the second diagnostic device supports communication through the second API, and at this time, the first diagnostic device 101 converts the first diagnostic instruction into the second diagnostic instruction, and then communication with the second diagnostic device 102 may be performed based on the second API.

Optionally, the second API may include one or more of a J2534API, a DPDU API, and the like.

In one possible design, the first diagnostic instruction may also be a first function and the second diagnostic instruction may be a second function. Wherein the first function may call the first API and the second function may call the second API. The first diagnostic device may map the first function to a second function, thereby calling the second API through the second function. For example, the first diagnostic device may map the "passthreopen" function to a "PDUConstruct" function, which may be used to call the second API. At this time, the "PDUConstruct" function may be regarded as a second diagnostic instruction.

In one design, the first diagnostic device may map the first diagnostic instruction to the second diagnostic instruction according to a mapping relationship. The mapping relationship may be stored in a format such as a table, a database, a stack, and the like, and the form of the mapping relationship is not limited in the present application.

For example, taking the first API as the J2534API and the second API as the D-PDU API, a mapping table of possible diagnostic commands may be shown in table 1. For example, when the first diagnostic instruction is "passthruoopen", the second diagnostic instruction is "PDUConstruct" according to the mapping shown in table 1. For another example, when the first diagnostic instruction is "passthrucrose", the second diagnostic instruction is "PDUDestruct" according to the mapping shown in table 1.

TABLE 1 mapping relationship schematic table

Optionally, the first diagnostic instruction and/or the second diagnostic instruction may include one or more communication parameters. Further, when the first diagnostic instruction includes the communication parameter, the first diagnostic device may further map the communication parameter.

For example, the first diagnostic device maps the communication parameters in the first diagnostic instruction based on the communication parameter mapping relationship to obtain a second diagnostic instruction with communication parameters. The communication parameter mapping relation can be stored in a form of a table, a database, a stack and the like, and the form of the mapping relation is not limited in the application.

For example, taking the first API as the J2534API and the second API as the D-PDU API, one possible mapping relationship of communication parameters is shown in table 2.

For example, the first diagnostic instruction is a "PassThruloctl" function, and the "PassThruloctl" function includes a communication parameter "LOOPBACK", and in this case, based on the mapping relationship shown in table 1 and table 2, the first diagnostic device may map the "PassThruloctl" function to a "PDUSetComParam" function, and map the communication parameter "LOOPBACK" in the "PassThruloctl" function to a communication parameter "CP _ LOOPBACK" in the "PDUSetComParam" function.

For another example, the first diagnostic instruction is a "passthreadoctl" function, and the "passthreadoctl" function includes a communication parameter "live _ BAUD _ MOD", at this time, based on the mapping relationship shown in table 1 and table 2, the first diagnostic device may map the "passthreadoctl" function to a "PDUSetComParam" function, and map the communication parameter "live _ BAUD _ MOD" in the "passthreadoctl" function to a communication parameter "CP _5 baudsode" in the "PDUSetComParam" function, and the rest of the communication parameter maps may be referred to table 2, which is not described in detail herein.

TABLE 2 schematic table of mapping relationships

J2534API communication parameters	D-PDU API communication parameters
		LOOPBACK	CP_Loopback
P3_MIN	CP_P3Min
		FIVE_BAUD_MOD	CP_5BaudMode
ISO15765_BS	CP_BlockSize
		BS_TX	CP_BlockSizeOverride
ISO15765_WFT_MAX	CP_CanMaxNumWaitFrames
		P1_MAX	CP_P1Max
P4_MIN	CP_P4Min
		NODE_ADDRESS	CP_TesterSourceAddress
ISO15765_STMIN	CP_Stmin
		STMIN_TX	CP_StMinOverride
T1_MAX	CP_T1Max
		T2_MAX	CP_T2Max
T3_MAX	CP_T3Max
		T4_MAX	CP_T4Max
T5_MAX	CP_T5Max
		W0 and TIDLE and W5	CP_TIdle
TINIL	CP_TInil
		TWUP	CP_TWup
W1	CP_W1Max
		W2	CP_W2Max
W3	CP_W3Max
		W4	CP_W4Min
DATARATE	CP_Baudrate
		BIT_SAMPLE_POINT	CP_BitSamplePoint
NETWORK_LINE	CP_NetworkLine
		SWCAN_HS_DATA_RATE	CP_ChangeSpeedRate
SWCAN_SPEEDCHANGE_ENABLE	CP_ChangeSpeedCtrl
		SWCAN_RES_SWITCH	CP_ChangeSpeedResCtrl
SYNC_JUMP_WIDTH	CP_SyncJumpWidth
		PARITY and DATA_BITS	CP_UARTConfig

Step S503: and the first diagnostic equipment calls the second API through the second diagnostic instruction to process the first service.

Wherein the first service is related to a diagnosis of the vehicle. For example, the first service may be one or more of a service of starting a vehicle diagnosis service, establishing a connection for diagnosis, controlling a vehicle diagnosis service, acquiring version information, or filtering data. Alternatively, the first service may further include one or more services in the first services shown in table 1.

In one possible embodiment, the first service can be used for writing and/or reading communication parameters.

For example, the user needs to open the playback function of the second diagnostic device connected to the vehicle, at this time, the first diagnostic device may map the communication parameter "LOOPBACK" to the communication parameter "CP _ LOOPBACK" by using the communication parameter "LOOPBACK" carried in the first instruction, and after the first diagnostic device writes "CP _ LOOPBACK" into the second diagnostic device through the second API, the playback function may be opened.

In the embodiment shown in fig. 5, the first diagnostic device maps the first diagnostic instruction to a second diagnostic instruction capable of calling the second API, so that the first diagnostic device implements the function implemented by the first API through the second API. Therefore, the second API is used as an intermediate module to realize the communication between the first API and the second diagnosis equipment, the compatibility problem between equipment based on different APIs is solved, the vehicle diagnosis cost is reduced, the service quality of the diagnosis equipment is improved, and the experience of a user in the vehicle diagnosis process is improved.

[ example two ]

In one possible design, please refer to fig. 6, and fig. 6 is a schematic flowchart of another possible vehicle diagnosis method provided by the embodiment of the present application. Alternatively, the vehicle diagnostic method shown in fig. 6 may be implemented based on the vehicle diagnostic system described above, such as the vehicle diagnostic system shown in fig. 1, 2, 3, or 4.

It should be understood that the order shown in fig. 6 is described for convenience of description, and is not intended to limit execution to the order described above. The execution sequence, execution time, execution times and the like of one or more steps are not limited.

The vehicle diagnosis method shown in fig. 6 includes steps S601 to S606, in which:

for the steps S601 to S603, reference may be specifically made to the related descriptions in the steps S501 to S503, which are not described herein again.

Step S601: the first diagnostic device monitors a first processing result of the first service through the second API.

In a possible case, the first processing result is used to indicate that the processing of the first service is successful.

For example, the first API is a J2534API, the second API is a D-PDU API, the first service is a start service, and at this time, the first diagnostic device may receive a returned verification result through the D-PDU API, and at this time, the returned verification result may indicate that processing the first service is successful.

For example, the first service is writing steering assist critical parameters, and at this time, the first diagnostic device may receive the processing result through the second API. If the first processing result is "success! ", the first processing result may indicate that processing the first service was successful.

In a possible case, the first processing result is used to indicate that the processing of the first service fails. For example, if the first processing result is an error code, failure to process the first service is indicated.

For example, the error code in the D-PDU API is PDU _ ERR _ shielding _ view, and failure to process the first service may be indicated because the first service cannot be processed due to a device SHARING collision PDU error.

As another example, the error code in the D-PDU API is PDU _ ERR _ INVALID _ PARAMETERS, which cannot process the first service due to INVALID device PARAMETERS, and thus may indicate that processing the first service fails.

Step S602: the first diagnostic device maps the first processing result to a second processing result supported by the first API.

For example, the first diagnostic DEVICE may map the error code PDU _ ERR _ warning _ view of the function "PDUConstruct" IN the D-PDU API to the error code ERR _ DEVICE _ IN _ USE of the function "passthreopen" IN the J2534 API. At this time, ERR _ DEVICE _ IN _ USE may be regarded as a second processing result.

Alternatively, the first diagnostic device may map the first processing result to the second processing result based on the mapping relationship. The mapping relationship may be stored in a format such as a table, a database, a stack, and the like, and the form of the mapping relationship is not limited in the present application.

For example, taking the first API as the J2534API and the second API as the D-PDU API, a mapping table of possible error codes may be shown in table 3. For example, when the first diagnostic instruction is "passthrough" and the second diagnostic instruction is "passconstractict" function, and the first processing result is PDU _ ERR _ warning _ view, the second processing result is ERR _ DEVICE _ IN _ USE according to the mapping relationship shown IN table 3. For another example, if the first processing result is PDU _ ERR _ INVALID _ PARAMETERS, the second processing result is "ERR _ NULL _ PARAMETERS" according to the mapping relationship shown in table 3.

TABLE 3 mapping relationship schematic table

Step S603: and the first diagnostic equipment acquires a second processing result through the first API.

Taking the error code PDU _ ERR _ shielding _ viewing mapping as ERR _ DEVICE _ IN _ USE as an example, the first diagnostic DEVICE may receive the error code ERR _ DEVICE _ IN _ USE of the J2534 API.

In the embodiment shown in fig. 6, the first diagnostic device may map not only the first diagnostic instruction to a second diagnostic instruction capable of calling the second API, but also map the first processing result obtained by the second API to a second processing result supported by the first API, so as to feed back the execution condition of the first service.

Many possible implementations are included in the method embodiments shown in fig. 5 or fig. 6, and some of the implementations are illustrated below with reference to fig. 7, fig. 8, and fig. 9, respectively. It should be noted that, relevant concepts or operations or logical relationships that are not explained in fig. 7, fig. 8, and fig. 9 may refer to corresponding descriptions in the embodiments shown in fig. 5 or fig. 6, and therefore, are not described again.

For convenience of understanding, in the following embodiments, the first API is a J2534API, the second API is a D-PDU API, and the second diagnostic device is an MVCI diagnostic tool. It will be appreciated by those skilled in the art that other APIs, other forms of second diagnostic device are equally applicable.

[ EXAMPLE III ]

Referring to fig. 7, fig. 7 is a schematic flowchart of a possible vehicle diagnosis method according to an embodiment of the present disclosure. Alternatively, the method may be implemented based on the vehicle diagnostic system described above, such as the vehicle diagnostic system shown in fig. 1, 2, 3, or 4. In the embodiment shown in fig. 7, the second diagnostic device is an MVCI diagnostic tool that is coupled to the vehicle and supports communication based on the second API.

The vehicle diagnostic method shown in FIG. 7 includes, but is not limited to, the following steps:

step S701: the first diagnostic device calls the first API through the first diagnostic instruction.

For example, the first diagnostic instruction may be a "passthruoopen" function contained in diagnostic software, which may be developed, for example, based on the J2534 API. The first diagnostic device runs the diagnostic software and may call the J2534API via the passthruoopen function.

Step S702: the first diagnostic device maps the first diagnostic instruction to a second diagnostic instruction, the second diagnostic instruction for calling a second API.

For example, the first diagnostic device maps the "passthreopen" function to a "PDUConstruct" function, and the second API may be called by the "PDUConstruct" function.

Step S703: and the first diagnostic equipment calls the second API through the second diagnostic instruction to process the first service.

For example, the first diagnostic device may call the D-PDU API through a "PDUConstruct" function, which is specifically used to implement the "start service" service through the second API.

Optionally, in the process of processing the first service, the first diagnostic device may further perform mapping on the diagnostic instruction, the communication parameter, the return result, and the error code one or more times, and the number of times of mapping of the first diagnostic device is not limited in the present application.

For example, as shown in fig. 7, the first diagnostic device may receive a response of the D-PDU API after calling the D-PDU API through the "PDUConstruct" function. After receiving the response, the first diagnostic device may continue to perform function mapping to obtain "PDUGetModuleIds" of the second API, which is used to validate the MVCI diagnostic tool. As can be seen, the first diagnostic device may communicate with the MVCI diagnostic tool through the second API.

Further, the first diagnostic device may receive the returned verification result through the D-PDU API. The first diagnostic device may map the "D-PDU return value" received by the D-PDU API to the "J2534 return value", so that the diagnostic software can know the processing result of the first service according to the return value.

[ EXAMPLE IV ]

Referring to fig. 8, fig. 8 is a schematic flowchart of a possible vehicle diagnosis method according to an embodiment of the present disclosure. Alternatively, the method may be implemented based on the vehicle diagnostic system described above, such as the vehicle diagnostic system shown in fig. 1, 2, 3, or 4. In the embodiment shown in fig. 8, the second diagnostic device is an MVCI diagnostic tool that is connected to the vehicle and supports communication based on the second API.

The vehicle diagnostic method shown in fig. 8 includes, but is not limited to, the following steps:

step S801: the first diagnostic device calls the first API through the first diagnostic instruction.

For example, the first diagnostic instruction may be a "passthruiioctrl" function included in diagnostic software, which may be developed based on the J2534API, for example. The first diagnostic device runs the diagnostic software and may call the J2534API via the "passthruiioctrl" function.

Step S802: the first diagnostic device maps the first diagnostic instruction to a second diagnostic instruction, the second diagnostic instruction for calling a second API.

For example, the first diagnostic device maps the "passthruiioctrl" function to the "PDUSetComParam" function, and the second API may be called by the "PDUSetComParam" function.

Step S803: and the first diagnostic equipment calls the second API through the second diagnostic instruction to process the first service.

For example, the first diagnostic device may call the D-PDU API through the "PDUSETComParam" function, which is specifically used to implement the "protocol parameter configuration" service through the second API.

For example, as shown in fig. 8, the user needs to open the echo function of the MVCI diagnostic tool connected to the vehicle, at this time, the first diagnostic device may carry the communication parameter "LOOPBACK" through the "passthruiioctrl" function, the first diagnostic device may map the communication parameter "LOOPBACK" carried by the "passthruiioctrl" function to the communication parameter "CP _ loop" carried by the "PDUSetComParam" function, and the first diagnostic device may open the echo function after writing the "CP _ loop" into the MVCI diagnostic tool through the second API. As can be seen, the first diagnostic device may communicate with the MVCI through the second API.

Further, the first diagnostic device may receive an enable return result of the MVCI diagnostic tool echoing function through the D-PDU API. The first diagnostic device may map the "D-PDU return value" received by the D-PDU API to the "J2534 return value", so that the diagnostic software can know the processing result of the first service according to the return value. For example, the D-PDU returns a PDU _ STATUS _ norror value, and the J2534 returns a STATUS _ norror value, at which time, the processing result of the first service indicates that the enabling is successful.

[ EXAMPLE V ]

Referring to fig. 9, fig. 9 is a schematic flowchart of a possible vehicle diagnosis method according to an embodiment of the present disclosure. Alternatively, the method may be implemented based on the vehicle diagnostic system described above, such as the vehicle diagnostic system shown in fig. 1, 2, 3, or 4. In the embodiment shown in fig. 9, the second diagnostic device is an MVCI diagnostic tool that is connected to the vehicle and supports communication based on the second API.

The vehicle diagnostic method shown in fig. 9 includes, but is not limited to, the following steps:

step S901: the first diagnostic device calls the first API through the first diagnostic instruction.

Step S902: the first diagnostic device maps the first diagnostic instruction to a second diagnostic instruction.

Step S903: and the first diagnostic equipment calls the second API through the second diagnostic instruction to process the first service.

Step S904: the first diagnostic device monitors a first processing result of the first service through the second API.

Optionally, the first processing result may be used to indicate that the processing of the first service fails. For example, if the first processing result is an error code, failure to process the first service is indicated.

Optionally, in the process of processing the first service, the first diagnostic device may further perform mapping on the diagnostic instruction, the return result, and the error code one or more times, and the number of times of mapping of the first diagnostic device is not limited in the present application.

For example, as shown in fig. 9, after the first diagnostic device calls the D-PDU API through the "PDUConstruct" function, the returned error value of the D-PDU API may be received. After receiving the returned error value, the first diagnostic device may continue to perform function mapping to obtain "pdugetmoduleiids" of the D-PDU API.

Further, after the function maps to obtain the "PDUGetModuleIds" of the second API, the first diagnostic DEVICE may monitor the processing result through the D-PDU API, and may map the "D-PDU return value PDU _ ERR _ PDUAPI _ NOT _ configured" received by the D-PDU API to the "J2534 return value ERR _ DEVICE _ IN _ USE".

Step S905: the first diagnostic device maps the first processing result to a second processing result supported by the first API.

Step S906: the first diagnostic device obtains the second processing result through the first API.

In the embodiment shown in fig. 9, the first diagnostic device may map not only the first diagnostic instruction to a second diagnostic instruction capable of calling the second API, but also map the first processing result obtained by the second API to a second processing result supported by the first API, so as to feed back the execution condition of the first service.

The method of the embodiments of the present application is explained in detail above, and the apparatus of the embodiments of the present application is provided below.

It is to be understood that a plurality of apparatuses provided in the embodiments of the present application, for example, the vehicle diagnostic apparatus 100, etc., include hardware structures, software units, or a combination of hardware structures and software structures, etc., which perform respective functions, in order to implement the functions in the above-described method embodiments. Those of skill in the art will readily appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments provided herein may be implemented as hardware or combinations of hardware and computer software. Whether a function is performed as hardware or computer software drives hardware depends upon the particular application and design constraints imposed on the solution. A person skilled in the art may implement the foregoing method embodiments in different usage scenarios by using different device implementations, and the different implementation manners of the device should not be considered as exceeding the scope of the embodiments of the present application.

Referring to fig. 10, fig. 10 is a schematic structural diagram of a vehicle diagnostic apparatus 100 according to an embodiment of the present disclosure. Alternatively, the vehicle diagnostic apparatus 100 may be a complete machine, or may be a device in the complete machine, such as a chip, a software module, an integrated circuit, and the like.

As shown in fig. 10, the vehicle diagnostic apparatus 100 includes a calling unit 1001 and a mapping unit 1002. The vehicle diagnostic apparatus 100 is used to implement the vehicle diagnostic apparatus method described above, such as the vehicle diagnostic method in the embodiment shown in fig. 5, 6, 7, 8 or 10.

In a possible implementation, the calling unit 1001 is configured to call a first API through a first diagnostic instruction;

a mapping unit 1002, configured to map the first diagnostic instruction into a second diagnostic instruction, where the second diagnostic instruction is used to call a second API;

the calling unit 1003 is further configured to call the second API through the second diagnosis instruction to process the first service, where the first service is related to diagnosis of the vehicle.

In a first possible embodiment, the diagnostic apparatus 100 is a first diagnostic device. Alternatively, the diagnostic device is included in the first diagnostic apparatus, for example, the diagnostic device is a chip, a hardware module, a software module, or the like in the first diagnostic apparatus.

Optionally, the diagnostic apparatus 100 is configured to diagnose the vehicle through a second diagnostic device, where the second diagnostic device supports communication based on a second application program interface API.

In one possible embodiment, the second diagnostic device is a diagnostic box supporting the D-PDU API.

In one possible embodiment, the second API is a D-PDU API and the first API is a J2534 API.

In a possible implementation, the first service includes one or more of the following services:

In a possible embodiment, the first service is used for writing communication parameters and/or reading communication parameters.

In a possible embodiment, the diagnostic device further comprises a communication unit 1003, wherein:

a communication unit 1003, configured to monitor a first processing result of the first service through the second API;

the mapping unit 1002 is further configured to map the first processing result to a second processing result supported by the first API;

the communication unit 1003 is further configured to obtain the second processing result through the first API.

In a possible implementation, the first processing result indicates that the processing of the first service is successful; or, the first result is an error code indicating that processing the first service failed.

In one possible embodiment, the apparatus further comprises:

the processing unit 1004 is configured to run diagnostic software from which the first diagnostic instruction is derived.

Referring to fig. 11, fig. 11 is a schematic structural diagram of a vehicle diagnostic device 110 according to an embodiment of the present disclosure, where the vehicle diagnostic device 110 may be a stand-alone device (e.g., one or more of a server, a user device, or the like), or may be a component (e.g., a chip, a software module, or a hardware module, or the like) inside the stand-alone device. The diagnostic device 110 may include at least one processor 1101. At least one memory 1102 may also optionally be included. Further optionally, the diagnostic device 110 may further include a communication interface 1103. Still further optionally, a bus may be included, wherein the processor 1101, the memory 1102 and the communication interface 1103 are connected by the bus.

Among them, the processor 1101 (e.g., a Central Processing Unit (CPU)) is a computing core and a control core, which can generate instructions and perform computing processes, such as: the CPU can transmit various interactive data among the internal structures of the vehicle-mounted equipment, and the like.

The memory 1102 is used to store programs and data. It is understood that the memory 1102 herein may comprise both internal memory and, of course, expansion memory. The storage space may, for example, store an operating system and other data, which may include, but is not limited to: android system, iOS system, Windows Phone system, etc., which are not limited in this application.

The communication interface 1103 may optionally include a standard wired communicator or interface, a wireless communicator or interface, such as a WI-FI module, a mobile communication interface, etc., which may be controlled by the processor 1101 to transmit and receive data.

At least one processor 1101 in the diagnostic device 110 is configured to call a computer program in a memory to perform the aforementioned version management method, such as the version management method described in the embodiments shown in fig. 5, fig. 6, fig. 7, fig. 8 or fig. 9.

In one possible design, the at least one processor 1101 in the diagnostic device 110 is configured to invoke a computer program to implement the following operations:

calling a first API through a first diagnosis instruction;

In one possible embodiment, the first diagnostic instruction comprises a first function, the second diagnostic instruction comprises a second function, and in mapping the first diagnostic instruction to the second diagnostic instruction, the second diagnostic instruction is configured to call a second API, the processor is configured to:

and mapping the first function into the second function, wherein the second function is used for calling a second API.

In one possible embodiment, the diagnostic device 110 is a first diagnostic device. Alternatively, the diagnostic device 110 is included in the first diagnostic device, for example, the diagnostic device is a chip, a hardware module, or a software module in the first diagnostic device.

Optionally, the diagnostic device 110 is configured to diagnose the vehicle through a second diagnostic device, where the second diagnostic device supports communication based on a second application program interface API.

In yet another possible implementation, before calling the first API through the first diagnostic instruction, the processor 1101 is further configured to:

In yet another possible embodiment, the second diagnostic device is a diagnostic box supporting the D-PDU API.

In yet another possible embodiment, the second API is a D-PDU API and the first API is a J2534 API.

In another possible implementation, the first service includes one or more of the following services:

In yet another possible embodiment, the first service is used for writing communication parameters and/or reading communication parameters.

In yet another possible implementation, the processor 1101 is further configured to:

monitoring a first processing result of the first service through a second API;

and acquiring the second processing result through the first API.

In yet another possible implementation, the first processing result is used to indicate that the processing of the first service is successful; or, the first processing result is an error code indicating that processing the first service fails.

An embodiment of the present application provides a computer-readable storage medium, in which a computer program is stored, which, when running on a processor, implements the vehicle diagnosis method provided in the first aspect.

In the embodiments of the present application, words such as "exemplary" or "for example" are used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "e.g.," is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, use of the word "exemplary" or "such as" is intended to present concepts related in a concrete fashion.

The ordinal numbers such as "first", "second", etc. are used in the embodiments of the present application to distinguish a plurality of objects, and are not used to limit the order, timing, priority, or importance of the plurality of objects. For example, the first diagnostic instruction and the second diagnostic instruction are for convenience of description, and do not indicate the difference in order, importance, and the like between the first diagnostic instruction and the second diagnostic instruction.

It should be noted that, for simplicity of description, the above-mentioned embodiments of the method are described as a series of acts or combinations, but those skilled in the art should understand that the present application is not limited by the order of acts described, as some steps may be performed in other orders or simultaneously according to the present application. Further, those skilled in the art should also appreciate that the embodiments described in the specification are preferred embodiments and that the acts and modules referred to are not necessarily required in this application.

The steps in the method of the embodiment of the application can be sequentially adjusted, combined and deleted according to actual needs.

The modules in the device can be merged, divided and deleted according to actual needs.

Those skilled in the art will appreciate that all or part of the steps in the methods of the above embodiments may be implemented by instructions associated with hardware via a program, which may be stored in a computer-readable storage medium, and the storage medium may include: flash disks, Read-Only memories (ROMs), Random Access Memories (RAMs), magnetic or optical disks, and the like.

While the invention has been described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the appended claims.

Claims

1. A vehicle diagnosis method applied to a first diagnosis device for diagnosing a vehicle by a second diagnosis device supporting communication based on a second application program interface API, comprising:

calling a first API through a first diagnosis instruction;

mapping the first diagnostic instruction to a second diagnostic instruction, wherein the second diagnostic instruction is used for calling a second API;

and calling the second API through the second diagnosis instruction to process a first service, wherein the first service is relevant to diagnosis of the vehicle.

2. The method of claim 1, wherein the first diagnostic instruction comprises a first function and the second diagnostic instruction comprises a second function, and wherein mapping the first diagnostic instruction to a second diagnostic instruction, the second diagnostic instruction to invoke a second API, comprises:

3. The method of claim 1, wherein the first service is used for writing communication parameters and/or reading communication parameters.

4. The method according to any one of claims 1-3, further comprising:

monitoring a first processing result of the first service through the second API;

and acquiring the second processing result through the first API.

5. The method of claim 4, wherein the first processing result is used to indicate that the processing of the first service is successful; or, the first processing result is an error code, and the error code indicates that processing the first service fails.

6. The method of any of claims 1-5, wherein prior to invoking the first API via the first diagnostic instruction, further comprising:

running diagnostic software, the first diagnostic instruction being from the diagnostic software.

7. A diagnostic apparatus for diagnosing a vehicle by a second diagnostic device supporting communication based on a second application program interface API, the diagnostic apparatus comprising:

the calling unit is further configured to call the second API through the second diagnostic instruction to process a first service, where the first service is related to diagnosis of the vehicle.

8. A diagnostic apparatus, characterized in that the apparatus comprises a processor, a memory, and a computer program stored in the memory and executable on the processor, when executing the computer program, implementing the vehicle diagnostic method of any one of claims 1 to 6.

9. A computer-readable storage medium, in which a computer program is stored which, when run on a processor, implements the vehicle diagnostic method according to any one of claims 1 to 6.