A host bus diagnostic method based on Python

Abstract

The present invention provides a host bus diagnostic method based on Python, comprising the following steps: S1, establishing a CAN driver lib library, wherein the driver lib library includes driver functions of various CAN tools; S2, traversing the CAN driver lib library, and using the driver functions of various CAN tools in the driver lib library to identify the host interface; S3, establishing a connection with the host interface after successful identification; S4, performing diagnosis. This host bus diagnostic method based on Python is independent of the supporting software of the CAN tool, can directly call the driver lib library of the CAN tool, independently diagnose various CAN tools, and save labor costs and test cycles.

Description

Technical Field

[0001] The invention relates to a diagnostic method for a vehicle host, and in particular to a host bus diagnostic method based on Python. Background Art

[0002] The bus of the car host needs to be diagnosed and tested before leaving the factory and when encountering a fault. The bus of the host generally uses the CAN bus, which has a variety of CAN tools. The existing diagnostic method requires the use of specific software that is compatible with the CAN tool. The diagnostic test of the CAN tool in these supporting specific software is only a small part of the software, and the software of each car model is also different. This brings inconvenience to car service providers in providing diagnostic testing services to car owners. It is obviously unreasonable for them to install so many specific software but only use a small part of the functions in normal times. Summary of the invention

[0003] The technical problem to be solved by the present invention is: in order to solve the above problems in the prior art, the present invention provides a host bus diagnosis method based on Python to solve the above problems.

[0004] The technical solution adopted by the present invention to solve the technical problem is: a host bus diagnosis method based on Python, comprising the following steps:

[0005] S1. Establish a CAN driver lib library, which includes driver functions of multiple CAN tools;

[0006] S2, traverse the CAN driver lib library, and use the driver functions of various CAN tools in the driver lib library to identify the host interface;

[0007] S3, after successful identification, establish a connection with the host interface;

[0008] S4. Perform diagnosis.

[0009] Preferably, step S4 comprises the following steps:

[0010] S4-1, call the diagnostic write instruction and write data of 0 in all configuration codes;

[0011] S4-2, call the diagnostic read instruction to read the data in the configuration code;

[0012] S4-3. Determine whether the read data is consistent with the written data. If not, mark the configuration code and exit the diagnosis.

[0013] Preferably, step S4 comprises the following steps:

[0014] S4-4, call the diagnostic write instruction, write data of 1 in all configuration codes, call the diagnostic read instruction, read the data in the configuration code, and determine whether all the read data are consistent with the written data. If all are consistent, it means that the mutual exclusion principle is not met, mark the configuration code that needs to have a mutual exclusion relationship and exit the diagnosis;

[0015] The mutual exclusion principle means that at most one of the specific configuration codes can have a value of 1 at the same time, otherwise the host system reports an error.

[0016] Preferably, step S4 comprises the following steps:

[0017] S4-5. Call the diagnostic write instruction to write data of 1 in the configuration code that needs to exist in the mutual exclusion principle, call the diagnostic read instruction to read the data in the configuration code. If the data read from more than two configuration codes is consistent with the written data, it means that they do not meet the mutual exclusion principle. Mark these configuration codes and exit the diagnosis.

[0018] Preferably, step S4 comprises the following steps:

[0019] S4-6. When the mutual exclusion principle is met, a reset command is sent, and a read command is called after power failure for N seconds to determine whether the data of the configuration code read after the reset is consistent with the data read before the reset. If they are inconsistent, the configuration code is marked and the diagnosis is exited.

[0020] The beneficial effect of the present invention is that the Python-based host bus diagnostic method is independent of the supporting software of the CAN tool, can directly call the driver lib library of the CAN tool, independently diagnose various CAN tools, and save labor costs and test cycles. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The present invention is further described below in conjunction with the accompanying drawings and embodiments.

[0022] Figure 1 It is a flow chart of the optimal embodiment of a host bus diagnostic method based on Python of the present invention. DETAILED DESCRIPTION

[0023] Embodiments of the present invention are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and cannot be understood as limiting the present invention.

[0024] CAN tools include CANoe, Vspy, ZLG and PCAN. The configuration code is tested to diagnose whether these CAN tools have abnormalities, such as Figure 1As shown, the present invention provides an implementation of a host bus diagnostic method based on Python, comprising the following steps:

[0025] Establish the CAN driver lib library, which includes the driver functions of various CAN tools;

[0026] Traverse the CAN driver lib library and use the driver functions of various CAN tools in the driver lib library to identify the host interface;

[0027] After successful identification, a connection is established with the host interface;

[0028] Make a diagnosis.

[0029] The first is the diagnostic read and write function. Select the configuration code that needs to be diagnosed, call the diagnostic write command, and write data of 0 in all configuration codes; then call the diagnostic read command to read the data in the configuration code;

[0030] Determine whether the read data is consistent with the written data. If not, it means that there is an abnormality in reading and writing. Mark the configuration code and exit the diagnosis.

[0031] If the data read is consistent with the data written, continue with the mutual exclusion diagnostics:

[0032] Call the diagnostic write command, write data of 1 in all configuration codes, call the diagnostic read command, read the data in the configuration code, and determine whether all the read data are consistent with the written data. If all are consistent, it means that the mutual exclusion principle is not met, mark the configuration code that needs to have a mutual exclusion relationship and exit the diagnosis. Among them, the mutual exclusion principle means that at most one configuration code of a specific number of configuration codes is 1 at the same time, otherwise the host system reports an error.

[0033] The above is an overall judgment, indicating that there are situations in which all configuration codes do not meet the mutual exclusion principle. If there are configuration codes that do not meet the mutual exclusion principle, you need to screen out specific configuration codes one by one: call the diagnostic write instruction, write data of 1 in the configuration code that needs to meet the mutual exclusion principle, call the diagnostic read instruction, read the data in the configuration code, if the data read from more than two configuration codes is consistent with the written data, it means that they do not meet the mutual exclusion principle, mark these configuration codes and exit the diagnosis.

[0034] When all configuration codes meet the mutual exclusion principle, send a reset command, delay power-off for seconds and call the read command to determine whether the data of the configuration code read after the reset is consistent with the data read before the reset. If they are inconsistent, mark the configuration code and exit the diagnosis. If they are consistent, it means that the memory function is normal.

[0035] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "examples", "specific examples", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0036] Based on the above ideal embodiments of the present invention, the relevant staff can make various changes and modifications without departing from the technical concept of the present invention through the above description. The technical scope of the present invention is not limited to the contents of the specification, and its technical scope must be determined according to the scope of the claims.

Claims

1. A host bus diagnostic method based on Python, characterized in that: The following steps are involved: S1. Establish a CAN driver lib library, which includes driver functions of multiple CAN tools; S2, traverse the CAN driver lib library, and use the driver functions of various CAN tools in the driver lib library to identify the host interface; S3, after successful identification, establish a connection with the host interface; S4. Perform diagnosis.

2. A Python-based host bus diagnostic method as claimed in claim 1, characterized in that: The step S4 comprises the following steps: S4-1, call the diagnostic write instruction and write data of 0 in all configuration codes; S4-2, call the diagnostic read instruction to read the data in the configuration code; S4-3. Determine whether the read data is consistent with the written data. If not, mark the configuration code and exit the diagnosis.

3. A Python-based host bus diagnostic method as claimed in claim 2, characterized in that: The step S4 comprises the following steps: S4-4, call the diagnostic write instruction, write data of 1 in all configuration codes, call the diagnostic read instruction, read the data in the configuration code, and determine whether all the read data are consistent with the written data. If all are consistent, it means that the mutual exclusion principle is not met, mark the configuration code that needs to have a mutual exclusion relationship and exit the diagnosis; The mutual exclusion principle means that at most one of the specific configuration codes can have a value of 1 at the same time, otherwise the host system reports an error.

4. A Python-based host bus diagnostic method as claimed in claim 3, characterized in that: The step S4 comprises the following steps: S4-5. Call the diagnostic write instruction to write data of 1 in the configuration code that needs to exist in the mutual exclusion principle, call the diagnostic read instruction to read the data in the configuration code. If the data read from more than two configuration codes is consistent with the written data, it means that they do not meet the mutual exclusion principle. Mark these configuration codes and exit the diagnosis.

5. A Python-based host bus diagnostic method as claimed in claim 4, characterized in that: The step S4 comprises the following steps: S4-6. When the mutual exclusion principle is met, a reset command is sent, and a read command is called after power failure for N seconds to determine whether the data of the configuration code read after the reset is consistent with the data read before the reset. If they are inconsistent, the configuration code is marked and the diagnosis is exited.

Images