Method, device and system for diagnosing vehicle controller, and diagnostic equipment

Abstract

The invention provides a method, device and system for diagnosing a vehicle controller, diagnosis equipment and a storage medium. The method is applied to diagnosis equipment and comprises the steps of obtaining a diagnosis description file; setting communication parameters of the communication protocol stack; reading a current diagnostic service, wherein the current diagnostic service has a diagnostic service type; when it is judged that the current diagnosis service is executed, sending a diagnosis request of the current diagnosis service to the to-be-diagnosed controller; receiving an actual response result from the controller to be diagnosed; in accordance with the content determination type, service identifier determination, original determination, or physical determination is performed, respectively. Determining an execution result according to the numerical values of the execution success counter and the execution failure counter as well as a success counting threshold and a failure counting threshold; and sending a diagnosis result display driving signal according to the execution result. The method is fast and high in accuracy, and complex software version updating is avoided.

Description

Technical Field

[0001] Embodiments of the present invention generally relate to the technical field of vehicle controller diagnosis, and more specifically, to a method, apparatus, system, diagnostic device and storage medium for diagnosing a vehicle controller. Background Art

[0002] The existing vehicle repair diagnostic equipment in the production workshop needs to change the software of the diagnostic equipment to customize the specific diagnostic tasks for each repair link according to different vehicle models. Changing the software will bring new software defects, and due to the large number of diagnostic equipment in the workshop, it is difficult to update the software, and the maintenance cost of each software change is very high. And the software for many diagnostic tasks is also very difficult to maintain. Summary of the invention

[0003] In order to solve the above-mentioned problems in the prior art, in a first aspect, an embodiment of the present invention provides a method for diagnosing a vehicle controller, the method being applied to a diagnostic device, the method comprising: obtaining a diagnostic description file from a server, the diagnostic description file comprising specified communication parameters and a diagnostic service queue, the diagnostic service queue comprising one or more diagnostic services; setting communication parameters of a communication protocol stack according to the specified communication parameters, wherein the communication protocol stack is used for communication between the diagnostic device and the vehicle controller; reading a current diagnostic service in the diagnostic service queue in the diagnostic description file, the current diagnostic service having a diagnostic service type, the diagnostic service type comprising a real service, and the diagnostic description file A diagnostic request corresponding to a diagnostic service of a real service type and an expected response result are predefined, the expected response result includes an expected data response result, the expected data response result has a content determination type, and the content determination type includes a service identifier determination, an original determination, and a physical determination; judging whether to execute the current diagnostic service according to an execution success counter and / or an execution failure counter of the current diagnostic service and an execution determination condition predefined in the diagnostic description file; terminating the execution of the current diagnostic service if it is judged that the current diagnostic service is not to be executed; and sending the diagnostic request of the current diagnostic service to the current diagnostic service via the communication protocol stack if it is judged that the current diagnostic service is to be executed. a controller to be diagnosed corresponding to the current diagnostic service; receiving, via the communication protocol stack, an actual response result of the controller to be diagnosed to the diagnostic request from the controller to be diagnosed, the actual response result including an actual data response result; in the case where the content determination type of the current diagnostic service is a service identifier determination, comparing the message content of the actual data response result with the expected data response result byte by byte; if each byte is the same, determining that the diagnostic result of the current execution is a successful execution, and accumulating a step amount to the execution success counter; otherwise, determining that the diagnostic result of the current execution is an execution failure, and accumulating a step amount to the execution failure counter; in the case where the content determination type of the current diagnostic service is an original determination In the case of a certain situation, according to the determination message content position defined in the diagnostic description file, the data at the determination message content position in the message content of the actual data response result is compared with the expected response result; if the data at the determination message content position is consistent with the expected response result, then it is determined that the diagnostic result of the current execution is a successful execution, and the step amount is accumulated for the successful execution counter; otherwise, it is determined that the diagnostic result of the current execution is a failed execution, and the step amount is accumulated for the failed execution counter; in the case that the content determination type of the current diagnostic service is a physical determination, according to the physical value operation function defined in the diagnostic description file, the actual response result is calculated to obtain the actual response physical value;Compare the actual response physical value with the physical value threshold range defined in the diagnostic description file. When the actual response physical value is within the physical value threshold range, determine that the diagnostic result of the current execution is successful, and add the step amount to the successful execution counter; otherwise, determine that the diagnostic result of the current execution is failed, and add the step amount to the failed execution counter; determine the execution result of the current diagnostic service according to the values ​​of the successful execution counter, the failed execution counter, and the success count threshold and the failure count threshold defined in the diagnostic description file; send a diagnostic result display drive signal to the vehicle via the communication protocol stack according to the execution result of the current diagnostic service. ;

[0004] In some embodiments, based on the execution success counter and / or execution failure counter of the current diagnostic service and the execution judgment condition pre-defined in the diagnostic description file, determining whether to execute the current diagnostic service includes: comparing the value of the execution success counter with a positive response condition threshold pre-defined in the diagnostic description file; if the value of the execution success counter is greater than or equal to the positive response condition threshold, determining to execute the current diagnostic service; otherwise, determining not to execute the current diagnostic service.

[0005] In some embodiments, based on the execution success counter and / or execution failure counter of the current diagnostic service and the execution judgment conditions pre-defined in the diagnostic description file, determining whether to execute the current diagnostic service also includes: in the absence of a pre-defined positive response condition threshold in the diagnostic description file, determining to execute the current diagnostic service unconditionally.

[0006] In some embodiments, based on the execution success counter and / or execution failure counter of the current diagnostic service and the execution judgment condition pre-defined in the diagnostic description file, determining whether to execute the current diagnostic service includes: comparing the value of the execution failure counter with a negative response condition threshold pre-defined in the diagnostic description file; if the value of the execution failure counter is greater than or equal to the negative response condition threshold, determining to execute the current diagnostic service; otherwise, determining not to execute the current diagnostic service.

[0007] In some embodiments, based on the execution success counter and / or execution failure counter of the current diagnostic service and the execution judgment conditions predefined in the diagnostic description file, determining whether to execute the current diagnostic service also includes: in the absence of a negative response condition threshold predefined in the diagnostic description file, determining to execute the current diagnostic service unconditionally.

[0008] In some embodiments, obtaining the diagnostic description file from the server includes: after the diagnostic device is connected to an on-board diagnostic interface on the vehicle, obtaining the diagnostic description file through the on-board diagnostic interface and wireless communication between the vehicle and the server.

[0009] In some embodiments, the expected response result pre-defined in the diagnostic description file also includes an expected timeout response result, and the actual response result also includes an actual timeout response result, and the method further includes: when the actual timeout response result is consistent with the expected timeout response result, continuing to perform content determination on the current diagnostic service, and determining the diagnostic result of the current execution based on the result of the content determination; when the actual timeout response result is inconsistent with the expected timeout response result, determining that the diagnostic result of the current execution is an execution failure.

[0010] In some embodiments, the diagnostic service type also includes a virtual service, and the method also includes: requesting a random number from the controller to be diagnosed; receiving the random number from the controller to be diagnosed; calculating a key based on the random number; writing the key back to the controller to be diagnosed; receiving from the controller to be diagnosed a verification result of the key by the controller to be diagnosed; if the verification result is a successful verification, the diagnostic result of the current diagnostic service is a successful execution; otherwise, the diagnostic result of the current diagnostic service is a failed execution.

[0011] In some implementations, the method further includes: reading a diagnostic service delay from the diagnostic description file; and controlling a timing of executing a plurality of diagnostic services according to the diagnostic service delay.

[0012] In some implementations, the specified communication parameters include vehicle communication parameters and / or communication parameters of the controller to be diagnosed.

[0013] In some implementations, when the diagnosis description file does not include the communication parameters of the controller to be diagnosed, the communication parameters of the communication protocol stack are configured according to the vehicle communication parameters.

[0014] In a second aspect, an embodiment of the present invention proposes a device for diagnosing a vehicle controller, the device being applied to a diagnostic device, the device comprising: a diagnostic description file acquisition module configured to acquire a diagnostic description file from a server, the diagnostic description file comprising specified communication parameters and a diagnostic service queue, the diagnostic service queue comprising one or more diagnostic services; a communication parameter setting module configured to set communication parameters of a communication protocol stack according to the specified communication parameters, wherein the communication protocol stack is used for communication between the diagnostic device and the vehicle controller; a current diagnostic service reading module configured to read a current diagnostic service in the diagnostic service queue in the diagnostic description file, the current diagnostic service having a diagnostic A service type, wherein the diagnostic service type includes a real service, wherein the diagnostic description file predefines a diagnostic request corresponding to the diagnostic service of the real service type and an expected response result, wherein the expected response result includes an expected data response result, and the expected data response result has a content determination type, wherein the content determination type includes a service identifier determination, an original determination, and a physical determination; an execution condition determination module, configured to determine whether to execute the current diagnostic service based on an execution success counter and / or an execution failure counter of the current diagnostic service and an execution determination condition predefined in the diagnostic description file; and a termination module, configured to terminate the execution of the current diagnostic service if it is determined that the current diagnostic service is not to be executed. Diagnostic service; a diagnostic request sending module, configured to send the diagnostic request of the current diagnostic service to the controller to be diagnosed corresponding to the current diagnostic service via the communication protocol stack when it is determined that the current diagnostic service is to be executed; an actual response result receiving module, configured to receive the actual response result of the controller to be diagnosed to the diagnostic request from the controller to be diagnosed via the communication protocol stack, wherein the actual response result includes an actual data response result; a service identifier determination module, configured to compare the message content of the actual data response result with the expected data response result byte by byte when the content determination type of the current diagnostic service is a service identifier determination; if each If the bytes are the same, it is determined that the diagnostic result of the current execution is a successful execution, and the step amount is accumulated to the successful execution counter; otherwise, it is determined that the diagnostic result of the current execution is a failed execution, and the step amount is accumulated to the failed execution counter; an original judgment module is configured to compare the data at the judgment message content position in the message content of the actual data response result with the expected response result according to the judgment message content position defined in the diagnosis description file when the content judgment type of the current diagnostic service is an original judgment; if the data at the judgment message content position is consistent with the expected response result, it is determined that the diagnostic result of the current execution is a successful execution, and the step amount is accumulated to the successful execution counter;Otherwise, it is determined that the diagnostic result of the current execution is an execution failure, and the execution failure counter is accumulated with a step amount; a physical determination module is configured to, when the content determination type of the current diagnostic service is a physical determination, calculate the actual response result according to the physical value operation function defined in the diagnostic description file to obtain an actual response physical value; compare the actual response physical value with the physical value threshold range defined in the diagnostic description file, and when the actual response physical value is within the physical value threshold range, determine that the diagnostic result of the current execution is an execution success, and accumulate the step amount to the execution success counter; otherwise, it is determined that the diagnostic result of the current execution is an execution failure, and accumulate the step amount to the execution failure counter; an execution result determination module is configured to determine the execution result of the current diagnostic service according to the values ​​of the execution success counter and the execution failure counter and the success count threshold and failure count threshold defined in the diagnostic description file; a diagnostic result display drive module is configured to send a diagnostic result display drive signal to the vehicle via the communication protocol stack according to the execution result of the current diagnostic service. ;

[0015] In a third aspect, an embodiment of the present invention provides a diagnostic device, the device comprising a memory and a processor, the memory storing a computer program, and implementing the method described in any of the above embodiments when the computer program is executed by the processor.

[0016] In a fourth aspect, an embodiment of the present invention proposes a system for diagnosing a vehicle controller, comprising a server and the above-mentioned diagnostic device, wherein the server stores a diagnostic description file.

[0017] In a fifth aspect, an embodiment of the present invention provides a storage medium storing computer-readable instructions, which, when executed by a processor, executes the method described in any of the above embodiments.

[0018] The implementation mode of the present invention innovatively adopts a flexibly configurable diagnostic description file to replace software changes. The edited diagnostic description file is downloaded and stored in the diagnostic device. Each time the diagnostic device is powered on, it parses and executes the content in the diagnostic description file to complete the diagnostic task.

[0019] Diagnostic description files, from creation to maintenance, each diagnostic task is only for a single file, and the logic is simple. No need to change and maintain the software version of the complex software development process. Stable and reliable. And no software professionals are required to maintain it, lowering the user threshold. In the implementation plan, users do not need to update the software version of the diagnostic device, which is a time-consuming and error-prone process. They only need to use a computer or other equipment, such as connecting to the WiFi hotspot emitted by the diagnostic device, to download the edited diagnostic description file to customize the diagnostic task of the diagnostic device. Quick and error-prone.

[0020] The technical solution proposed in the embodiment of the present invention has great flexibility, that is, the success determination criteria and the response determination conditions can be flexibly set in the vehicle diagnosis description file.

[0021] The vehicle controller diagnosis technical solution proposed in the embodiment of the present invention can be applied to vehicle trial production and batch repair applications of vehicle mass production. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The above and other objects, features and advantages of the embodiments of the present invention will become readily understood by reading the following detailed description with reference to the accompanying drawings. In the accompanying drawings, several embodiments of the present invention are shown in an exemplary and non-limiting manner, in which:

[0023] Figure 1 A schematic flow chart of a method for diagnosing a vehicle controller according to an embodiment of the present invention is shown;

[0024] Figure 2 A block diagram of an apparatus for diagnosing a vehicle controller according to an embodiment of the present invention is shown.

[0025] In the drawings, the same or corresponding reference numerals represent the same or corresponding parts. DETAILED DESCRIPTION

[0026] The principle and spirit of the present invention will be described below with reference to several exemplary embodiments. It should be understood that these embodiments are provided only to enable those skilled in the art to better understand and implement the present invention, and are not intended to limit the scope of the present invention in any way.

[0027] In one aspect, embodiments of the present invention provide a method for diagnosing a vehicle controller. Figure 1 , which shows a flow chart of a method 100 for diagnosing a vehicle controller according to an embodiment of the present invention. The method is applied to a diagnostic device. Figure 1 As shown, the method 100 includes steps S101-S112.

[0028] In step S101, a diagnosis description file (DDF) is obtained from a server. The diagnosis description file includes specified communication parameters and a diagnosis service queue. The diagnosis service queue includes one or more diagnosis services.

[0029] In an embodiment of the present invention, the diagnostic description file (DDF) can be a description file of a user-customized diagnostic function, which is edited and generated by the user according to the vehicle model to be returned for repair by the workshop and the diagnostic task, according to the tags of the diagnostic description file, pushed to the server, and controlled to be downloaded and stored in the corresponding diagnostic device.

[0030] As an embodiment of the present invention, obtaining the diagnostic description file from the server may include: after the diagnostic device is connected to the on-board diagnostic (OBD) interface on the vehicle, obtaining the diagnostic description file through the on-board diagnostic interface and wireless communication between the vehicle and the server.

[0031] As another embodiment of the present invention, the user connects to the wifi hotspot of the target diagnostic device and downloads the created diagnostic description file to the diagnostic device through the socket. After the file is successfully downloaded, the user connects the diagnostic device to the OBD port of the vehicle to be inspected, and the diagnostic device begins to parse and execute the diagnostic service in the diagnostic description file.

[0032] As an example, the diagnostic description file (DDF) may include vehicle communication parameters and information related to the controller to be diagnosed. The controller related information may include the communication parameters of the controller, diagnostic services, and judgment conditions for the diagnostic service results, etc.

[0033] Optionally, the format of the diagnostic description file (DDF) may be a json file or an xml file.

[0034] As an example only, the diagnostic description file may include a vehicle "vehicle" level, which includes vehicle communication parameters "comparam" and vehicle service queue "serviceSequence".

[0035] In step S102 , communication parameters of a communication protocol stack are set according to specified communication parameters, wherein the communication protocol stack is used for communication between the diagnostic device and the vehicle controller.

[0036] As an embodiment of the present invention, the specified communication parameters include vehicle communication parameters and / or communication parameters of the controller to be diagnosed.

[0037] In this embodiment, as an example, the vehicle communication parameter "comparam" may be a vehicle communication parameter loaded by the cloud diagnosis server. This communication parameter may be a communication parameter in ODX.

[0038] In this embodiment, as an example, the controller communication parameter "ecuComparam" can be a controller communication parameter loaded by the cloud diagnostic server. This communication parameter data format follows the communication parameter setting of the diagnostic head in the online mode of the cloud service diagnostic head, that is, follows the PDU SetComParam in the "Cloud Diagnosis D PDU API Interface Definition" document.

[0039] As an embodiment of the present invention, when the diagnosis description file does not include the communication parameters of the controller to be diagnosed, the communication parameters of the communication protocol stack are configured according to the communication parameters of the entire vehicle.

[0040] In step S103, the current diagnostic service in the diagnostic service queue in the diagnostic description file is read, the current diagnostic service has a diagnostic service type, and the diagnostic service type includes a real service (r-service). The diagnostic description file pre-defines a diagnostic request corresponding to the diagnostic service of the real service type and an expected response result, the expected response result includes an expected data response result, and the expected data response result has a content determination type, and the content determination type includes a service identifier determination, an original determination, and a physical determination.

[0041] A diagnostic request may also be referred to as a service request, and the two terms are used interchangeably herein.

[0042] The service request "request" refers to the diagnostic request of the diagnostic device (also called the diagnostic head) to the controller, which can be a message of the UDS protocol or the OBD protocol, such as "22F1 89".

[0043] As an example, for a real diagnostic service r-service, the "type" type is 0. Each real diagnostic service includes a service request request and a response result response. The real service includes, for example, reading the version number of the controller.

[0044] In step S104, it is determined whether to execute the current diagnostic service according to the execution success counter (p-counter) and / or execution failure counter (n-counter) of the current diagnostic service and the execution determination condition predefined in the diagnostic description file.

[0045] Optionally, an upper limit of the number of successful executions or the number of failed executions may be set, and if the corresponding number exceeds the upper limit, it is determined that the current diagnostic service is not executed.

[0046] Alternatively, step S104 can be executed in the following manner: compare the value of the execution success counter with the positive response condition threshold (pCondition) pre-defined in the diagnostic description file; when the value of the execution success counter is greater than or equal to the positive response condition threshold, determine to execute the current diagnostic service; otherwise, determine not to execute the current diagnostic service.

[0047] In the above implementation, optionally, when there is no predefined positive response condition threshold in the diagnosis description file, it may be determined that the current diagnosis service is to be executed unconditionally.

[0048] Alternatively, step S104 can also be executed in the following manner: compare the value of the execution failure counter with the negative response condition threshold (nCondition) pre-defined in the diagnostic description file; when the value of the execution failure counter is greater than or equal to the negative response condition threshold, determine to execute the current diagnostic service, otherwise, determine not to execute the current diagnostic service.

[0049] In the above implementation, optionally, when there is no predefined negative response condition threshold in the diagnosis description file, it may be determined that the current diagnosis service is to be executed unconditionally.

[0050] A specific example of execution condition determination is described below.

[0051] If pCondition is 0, or the pCondition tag does not exist, this diagnostic service is executed unconditionally.

[0052] If pCondition>0, then check whether p-counter is greater than or equal to pCondition.

[0053] If it is greater than or equal to, execute this diagnostic service.

[0054] If it is less, this diagnostic service will not be performed.

[0055] If nCondition is 0, or the nCondition tag does not exist, this diagnostic service is executed unconditionally.

[0056] If nCondition>0, then determine whether n-counter is greater than or equal to nCondition.

[0057] If it is greater than or equal to, execute this diagnostic service.

[0058] If it is less, this diagnostic service will not be performed.

[0059] When pCondition and nCondition exist at the same time, this diagnostic service is executed unconditionally.

[0060] pCondition and nCondition may be set to determine whether the failure of one of the multiple services is intolerable or whether the failure of multiple services is intolerable.

[0061] By presetting the above thresholds in the diagnosis description file, the execution conditions of the diagnosis service can be flexibly configured.

[0062] In step S105 , if it is determined that the current diagnostic service is not to be executed, the execution of the current diagnostic service is terminated.

[0063] In step S106 , when it is determined that the current diagnostic service is to be executed, a diagnostic request for the current diagnostic service is sent to a controller to be diagnosed corresponding to the current diagnostic service via the communication protocol stack.

[0064] In step S107 , an actual response result of the controller to be diagnosed to the diagnosis request is received from the controller to be diagnosed via the communication protocol stack, where the actual response result includes an actual data response result.

[0065] In step S108, when the content judgment type of the current diagnostic service is a service identifier (SID) judgment, the message content of the actual data response result is compared byte by byte with the expected data response result; if each byte is the same, the diagnostic result of the current execution is judged to be a successful execution, and the step amount of the successful execution counter is accumulated; otherwise, the diagnostic result of the current execution is judged to be a failed execution, and the step amount of the failed execution counter is accumulated.

[0066] In step S109, when the content judgment type of the current diagnostic service is a raw judgment, the data at the judgment message content position in the message content of the actual data response result is compared with the expected response result according to the judgment message content position defined in the diagnostic description file; if the data at the judgment message content position is consistent with the expected response result, then the diagnostic result of the current execution is judged to be a successful execution, and the step amount of the execution success counter is accumulated; otherwise, the diagnostic result of the current execution is judged to be a failed execution, and the step amount of the execution failure counter is accumulated.

[0067] In step S110, when the content judgment type of the current diagnostic service is physical judgment, the actual response result is calculated according to the physical value operation function defined in the diagnostic description file to obtain the actual response physical value; the actual response physical value is compared with the physical value threshold range defined in the diagnostic description file, and when the actual response physical value is within the physical value threshold range, it is determined that the diagnostic result of the current execution is a successful execution, and the step amount is accumulated to the execution success counter; otherwise, it is determined that the diagnostic result of the current execution is a failed execution, and the step amount is accumulated to the execution failure counter.

[0068] In step S111, the execution result of the current diagnostic service is determined according to the values ​​of the execution success counter and the execution failure counter as well as the success count threshold and the failure count threshold defined in the diagnostic description file.

[0069] When each service execution result is an error, the n-counter is added to the "nCounter" of the current service. When all services are executed, when the total n-counter is greater than or equal to "nThreshold", the corresponding LED light or buzzer error prompt will be enabled.

[0070] When each service execution result is correct, the p-counter is added to the "pCounter" of the current service. When all services are executed, when the total p-counter is greater than "pThreshold", the corresponding LED light or buzzer will be enabled.

[0071] First, compare whether the total number of n-counters is greater than "nThreshold". If so, do not check whether the total number of p-counters is greater than "pThreshold".

[0072] In step S112, according to the execution result of the current diagnostic service, a diagnostic result display drive signal is sent to the vehicle via the communication protocol stack. The result display show is used to prompt the user with sound or LED light when the response result of the diagnostic service is correct or wrong.

[0073] As an example only, the result is displayed by the vehicle. If the execution is successful, the vehicle will flash double; if the execution fails, the vehicle will flash single, turn left or right, etc.

[0074] As an embodiment of the present invention, each diagnostic service included in the vehicle service sequence "serviceSequence" of the diagnostic description file may include multiple tags. Table 1 shows an example tag list of the diagnostic service.

[0075] Table 1. Example label list for diagnostic services

[0076]

[0077]

[0078] As an embodiment of the present invention, the expected response result pre-defined in the diagnostic description file may also include an expected timeout response result, and the actual response result also includes an actual timeout response result. The method may also include: when the actual timeout response result is consistent with the expected timeout response result, continuing to execute the content judgment of the current diagnostic service, and determining the diagnostic result of the current execution based on the result of the content judgment; when the actual timeout response result is inconsistent with the expected timeout response result, determining that the diagnostic result of the current execution is an execution failure.

[0079] Table 2 shows example tags included in the real service type in the diagnostic description file.

[0080] Table 2. Example labels included in real services

[0081]

[0082] In the example shown in Table 2 above, the expected timeout response result may be to suppress a positive response, that is, to expect no reply, in other words, the timeout indicates no problem. "P3ACTIVE" in Table 2 is the name of the timer, and in this example, the timer is expected to time out.

[0083] Optionally, any number of timers may be set, where the expiration of one of the timers is an expected result.

[0084] A specific example of the response result is described below.

[0085] The response result refers to the expected response result after the controller diagnostic request. It is divided into data response result "dResponse" and response timeout "tResponse".

[0086] If only the tag "dResponse" exists, the actual received controller response is compared with "dResponse" for judgment. If only the tag "tResponse" exists, the actual received controller response is compared with "tResponse". When both the tag "dResponse" and the tag "tResponse" exist, the tag "tResponse" has a higher priority than the tag "dResponse". If there is no response tag, and it is not a Physical judgment (physical values, such as the values ​​sent on the vehicle bus are all integer values, and the actual physical values ​​may have decimal points, and there is a corresponding relationship between them), no comparison is performed, and the service execution is directly judged to be successful.

[0087] A specific example of result determination is described below.

[0088] The result judgment content-check refers to judging the content of the response message. When it is necessary to check whether the content of the response message is correct, the content judgment is used for judgment. One response message can support multiple content judgments. There can be multiple content judgments. The following Table 3 shows the example tags included in the result judgment in the diagnostic description file.

[0089] Table 3. Example labels included in the result judgment

[0090]

[0091]

[0092] When the tag "tResponse" exists, its content specifies the timeout timer name, such as P3ACTIVE. When the timer of the corresponding communication protocol stack times out, this service execution is successful.

[0093] When the tag "tResponse" does not exist:

[0094] When the tag "dResponse" does not exist and it is not a Physical judgment, no comparison judgment is performed and the service execution is directly judged to be successful.

[0095] When the tag "dResponse" exists, if the communication protocol stack timer expires, the service execution fails.

[0096] If a response message from the diagnostic service is received, a judgment needs to be made based on "checkType".

[0097] When "checkType" is "SID determination", the content of "dResponse" is the expected message result, and the diagnostic header compares the received response message with the content of "dResponse" byte by byte. If each byte is the same, it is determined that the diagnostic service is executed successfully.

[0098] For example, if the content of "request" is "22F1 B4", and the content of "dResponse" is "62F1 B4 05 050406 07", then if the received response message is a positive response message (defined in the protocol, ox62) of 22 (service), then the diagnostic service is judged to be executed successfully. Among them, the first three bytes indicate whether it is a positive response and content, and the following are the contents to be replied. When judging SID, the 05... after "dResponse" can be deleted to judge whether it is a positive response.

[0099] For example, if the content of "request" is "22F1 B4" and the content of "dResponse" is "7F 22 31 (negative response)", then if the received response message is a negative response message of 22, the diagnostic service is determined to be executed successfully. Otherwise, the diagnostic service is determined to have failed to execute.

[0100] When "checkType" is "Raw judgment", the received message must be a positive response message. Part of the content of "dResponse" is the expected message result, and "dataPosition" is the starting position of the message content that needs to be judged, such as 5, representing the 5th byte. "dataLength" is the length of the message content that needs to be judged, such as 2, representing 2 bytes. The diagnostic header finds the starting byte to be compared in the content of "dResponse" and the content of the received message according to "dataPosition", and then compares byte by byte. The length of the comparison is the length indicated by "dataLength". If each byte is the same, it is determined that the diagnostic service is executed successfully.

[0101] For example, the content of "request" is "22F1 B4", that is, the service to be requested is 22 (read). The content of "dResponse" is "62F1 B4 05 06 07 08 04 32 44", and F1 B4 is, for example, what is to be read (controller hardware version number, software version number, and customized content). When "Raw judgment" is used, the preceding "62F1 B4" is not judged.

[0102] "dataPosition" = 3, "dataLength" = 4, then starting from the 4th byte of the response message, determine whether the 4th byte is 05, whether the 5th byte is 06, whether the 6th byte is 07, and whether the 7th byte is 08. If all are correct, the diagnostic service is determined to be executed successfully. Otherwise, the diagnostic service is determined to have failed.

[0103] When "checkType" is "Physical judgment", the received message must be a positive response message. The "dResponse" tag is ignored. "dataPosition" is the starting position of the message content that needs to be judged, such as 5, representing the 5th byte. "dataLength" is the length of the message content that needs to be judged, such as 2, representing 2 bytes. function is a calculation formula, such as phy=raw*"factor"+"offset". "lowLimit" is the minimum value of the correct range. "highLimit" is the maximum value of the correct range. The diagnostic header finds the starting byte in the content of the received message according to "dataPosition", and the length of the byte is "dataLength" to determine the raw value. The physical value is calculated according to phy=raw*"factor"+"offset", and the physical value is determined according to "highLimit" and "lowLimit". For example:

[0104] Receive message "62F1 26 40 32 55 89 10 60"

[0105] "dataPosition" = 4

[0106] "dataLength" = 4

[0107] Then raw = 0x32558910.

[0108] “factor” = 2

[0109] "offset" = -8

[0110] The physical value phy = 0x32558910*2-8. If phy>= "lowLimit" and phy<= "highLimit", it is determined that the diagnostic service is executed successfully. Otherwise, it is determined that the diagnostic service fails.

[0111] When the result indicates that the diagnostic service is successfully executed, last_result is set to 0. P-counter is incremented by the "pCounter" of the current service, for example, 5 is added to the current p-counter.

[0112] When the result indicates that the diagnostic service has failed, last_result is set to 1. n-counter is incremented by the "nCounter" of the current service. For example, add 5 to the current n-counter.

[0113] In the above example, the retry is performed only when last_result is 1.

[0114] As an embodiment of the present invention, the diagnostic service type may also include a virtual service (v-service). In this embodiment, the method may also include: requesting a random number from the controller to be diagnosed; receiving a random number from the controller to be diagnosed; calculating a key based on the random number; writing the key back to the controller to be diagnosed; receiving a verification result of the controller to be diagnosed on the key from the controller to be diagnosed; if the verification result is successful, the diagnostic result of the current diagnostic service is successful execution; otherwise, the diagnostic result of the current diagnostic service is failure to execute.

[0115] As a specific example, in a service for modifying controller data (ie, writing data), the controller has a protection mechanism and authentication is required to write to the controller. The authentication process is a virtual service and the writing process is a real service.

[0116] Virtual service v-service, "type" type is 1. It is a virtual service. Virtual service v-service is used to call the service request sequence of the fixed number of the diagnostic device.

[0117] For example, for secure login, you need to request a seed (random number) from the controller, then the diagnostic header calculates the key and writes the key back to the controller. The controller verifies that it is correct and returns a positive response. This series of operations is solidified in the diagnostic header, and DDF can call this v-service to complete the diagnostic login of the extended session.

[0118] The virtual service request v-service may include a service identification number vsid and parameters.

[0119] As an embodiment of the present invention, the diagnostic description file may further include a delay between diagnostic services. The method may further include: reading the diagnostic service delay from the diagnostic description file; and controlling the timing of executing multiple diagnostic services according to the diagnostic service delay.

[0120] A specific example of the diagnosis process is described below in conjunction with the settings mentioned in the above implementation.

[0121] The diagnostic device reads the vehicle communication parameters of the comparam, sets the communication parameters of its internal communication protocol stack, and selects CAN (FD) or DoIP communication.

[0122] The diagnostic device reads the service in the serviceSequence. Specifically:

[0123] Execute the diagnostic service clearObdDtc. Read the value of funcAddr, 1 is functional addressing, set its internal communication protocol stack to functional addressing; read the value of ecuComparam, set the communication parameters of its internal communication protocol stack, such as the value of CAN ID; read the value of type, 0 indicates a real service; find the tResponse tag, the judgment condition of the device service is to expect a timeout response result P3ACTIVE; then send the message 04 in the request; if its internal communication protocol stack returns a timeout response result P3ACTIVE, the positive response counter increases by 5; if its internal communication protocol stack does not return a timeout response result P3ACTIVE, the negative response counter increases by 8; read the value of delay, and the diagnostic device sleeps for 1000 milliseconds.

[0124] Execute the diagnostic service clearDtc. Read the value of funcAddr, 1 is functional addressing, set its internal communication protocol stack to functional addressing; read the value of ecuComparam, set the communication parameters of its internal communication protocol stack, such as the value of CAN ID; read the value of type, 0 indicates a real service; find the tResponse tag, the judgment condition of the device service is to expect a timeout response result P3ACTIVE; then send the message 14FF FF FF in the request; if its internal communication protocol stack returns a timeout response result P3ACTIVE, the positive response counter increases by 5; if its internal communication protocol stack does not return a timeout response result P3ACTIVE, the negative response counter increases by 8;

[0125] First, check whether the value of the negative response counter is greater than the value of nThreshold 15. If so, the diagnostic task fails and the LED light of the diagnostic device flashes quickly. Otherwise, check whether the value of the positive response counter is greater than the value of pThreshold 9. If so, the diagnostic task succeeds and the LED light of the diagnostic device stays on.

[0126] The user can judge whether the diagnosis task is successfully executed based on the status of the LED light of the diagnosis device.

[0127] In another aspect, an embodiment of the present invention provides an apparatus for diagnosing a vehicle controller. Figure 2 , which shows a block diagram of an apparatus for diagnosing a vehicle controller according to an embodiment of the present invention. The apparatus is applied to a diagnostic device. Figure 2 As shown, the apparatus includes modules 201-212.

[0128] The diagnosis description file acquisition module 201 may be configured to acquire a diagnosis description file from a server, where the diagnosis description file includes specified communication parameters and a diagnosis service queue, where the diagnosis service queue includes one or more diagnosis services.

[0129] The communication parameter setting module 202 may be configured to set communication parameters of a communication protocol stack according to specified communication parameters, wherein the communication protocol stack is used for communication between the diagnostic device and the vehicle controller.

[0130] The current diagnostic service reading module 203 can be configured to read the current diagnostic service in the diagnostic service queue in the diagnostic description file, the current diagnostic service has a diagnostic service type, the diagnostic service type includes a real service, the diagnostic description file pre-defines a diagnostic request corresponding to the diagnostic service of the real service type and an expected response result, the expected response result includes an expected data response result, the expected data response result has a content determination type, and the content determination type includes a service identifier determination, an original determination, and a physical determination.

[0131] The execution condition determination module 204 may be configured to determine whether to execute the current diagnostic service according to an execution success counter and / or an execution failure counter of the current diagnostic service and an execution determination condition predefined in the diagnostic description file.

[0132] The termination module 205 may be configured to terminate the execution of the current diagnostic service if it is determined that the current diagnostic service is not to be executed.

[0133] The diagnosis request sending module 206 may be configured to send the diagnosis request of the current diagnosis service to the to-be-diagnosed controller corresponding to the current diagnosis service via the communication protocol stack when it is determined that the current diagnosis service is to be executed.

[0134] The actual response result receiving module 207 may be configured to receive an actual response result of the controller to be diagnosed to the diagnosis request from the controller to be diagnosed via the communication protocol stack, where the actual response result includes an actual data response result.

[0135] The service identifier determination module 208 can be configured to compare the message content of the actual data response result with the expected data response result byte by byte when the content determination type of the current diagnostic service is service identifier determination; if each byte is the same, it is determined that the diagnostic result of the current execution is a successful execution, and the step amount of the successful execution counter is accumulated; otherwise, it is determined that the diagnostic result of the current execution is a failed execution, and the step amount of the failed execution counter is accumulated.

[0136] The original judgment module 209 can be configured to compare the data at the judgment message content position in the message content of the actual data response result with the expected response result according to the judgment message content position defined in the diagnostic description file when the content judgment type of the current diagnostic service is the original judgment; if the data at the judgment message content position is consistent with the expected response result, then it is determined that the diagnostic result of the current execution is a successful execution, and the step amount of the execution success counter is accumulated; otherwise, it is determined that the diagnostic result of the current execution is a failed execution, and the step amount of the execution failure counter is accumulated.

[0137] The physical determination module 210 can be configured to, when the content determination type of the current diagnostic service is physical determination, perform operations on the actual response result according to the physical value operation function defined in the diagnostic description file to obtain the actual response physical value; compare the actual response physical value with the physical value threshold range defined in the diagnostic description file, and when the actual response physical value is within the physical value threshold range, determine that the diagnostic result of the current execution is a successful execution, and accumulate the step amount to the successful execution counter; otherwise, determine that the diagnostic result of the current execution is a failed execution, and accumulate the step amount to the failed execution counter.

[0138] The execution result determination module 211 may be configured to determine the execution result of the current diagnostic service according to the values ​​of the execution success counter and the execution failure counter and the success count threshold and the failure count threshold defined in the diagnostic description file.

[0139] The diagnosis result display driving module 212 may be configured to send a diagnosis result display driving signal to the vehicle via a communication protocol stack according to the execution result of the current diagnosis service.

[0140] It should be noted that the functions implemented by each module in the device for diagnosing a vehicle controller proposed in the embodiment of the present invention correspond one-to-one to the various steps of the method for diagnosing a vehicle controller described above. For its specific implementation methods, examples and beneficial effects, please refer to the above description of the method.

[0141] On the other hand, an embodiment of the present invention provides a diagnostic device, which includes a memory and a processor. The memory stores a computer program, and when the computer program is executed by the processor, the method for diagnosing a vehicle controller described in any of the above embodiments is implemented.

[0142] In another aspect, an embodiment of the present invention provides a system for diagnosing a vehicle controller, comprising a server and the above-mentioned diagnostic device, wherein the server stores a diagnostic description file.

[0143] In another aspect, an embodiment of the present invention provides a storage medium storing computer-readable instructions. When the instructions are executed by a processor, the method for diagnosing a vehicle controller described in any of the above embodiments is executed.

[0144] The implementation mode of the present invention designs a diagnostic description file, which replaces the software change, downloads and stores the edited diagnostic description file to the diagnostic device, and parses and executes the content in the diagnostic description file each time the diagnostic device is powered on to complete the diagnostic task.

[0145] Diagnostic description files, from creation to maintenance, each diagnostic task is only for a single file, and the logic is simple. No need to change and maintain the software version of the complex software development process. Stable and reliable. And no software professionals are required to maintain it, lowering the user threshold. In the implementation plan, users do not need to update the software version of the diagnostic device, which is a time-consuming and error-prone process. They only need to use a computer or other equipment, such as connecting to the WiFi hotspot emitted by the diagnostic device, to download the edited diagnostic description file to customize the diagnostic task of the diagnostic device. Quick and error-prone.

[0146] The technical solution proposed in the embodiment of the present invention has great flexibility, that is, the success determination criteria and the response determination conditions can be flexibly set in the vehicle diagnosis description file.

[0147] The vehicle controller diagnosis technical solution proposed in the embodiment of the present invention can be applied to vehicle trial production and batch repair applications of vehicle mass production.

[0148] For the purpose of illustration, the foregoing description of the embodiments of the present invention has been given, which is not exhaustive nor intended to limit the present invention to the disclosed exact form. It will be appreciated by those skilled in the art that various changes can be made without departing from the scope of the present invention, and that the elements therein can be replaced with equivalents. In addition, without departing from the basic scope of the present invention, many modifications can be made so that specific situations or materials are adapted to the teachings of the present invention. Therefore, the present invention is not intended to be limited to the specific embodiments disclosed as the best mode for realizing the present invention, and the present invention will include all embodiments falling within the scope of the appended claims.

Claims

1. A method for diagnosing a vehicle controller, characterized in that: The method is applied to a diagnostic device, and the method comprises: Acquire a diagnostic description file from a server, the diagnostic description file including specified communication parameters and a diagnostic service queue, the diagnostic service queue including one or more diagnostic services; setting a communication parameter of a communication protocol stack according to the specified communication parameter, wherein the communication protocol stack is used for communication between the diagnostic device and a vehicle controller; Reading a current diagnostic service in a diagnostic service queue in the diagnostic description file, wherein the current diagnostic service has a diagnostic service type, wherein the diagnostic service type includes a real service, wherein the diagnostic description file predefines a diagnostic request corresponding to the diagnostic service of the real service type and an expected response result, wherein the expected response result includes an expected data response result, wherein the expected data response result has a content determination type, wherein the content determination type includes a service identifier determination, an original determination, and a physical determination; Determining whether to execute the current diagnostic service according to an execution success counter and / or an execution failure counter of the current diagnostic service and an execution determination condition predefined in the diagnostic description file; If it is determined that the current diagnostic service is not to be executed, terminating the execution of the current diagnostic service; In the case of determining to execute the current diagnostic service, sending a diagnostic request of the current diagnostic service to a to-be-diagnosed controller corresponding to the current diagnostic service via the communication protocol stack; Receiving, from the controller to be diagnosed via the communication protocol stack, an actual response result of the controller to be diagnosed to the diagnosis request, wherein the actual response result includes an actual data response result; In the case where the content determination type of the current diagnostic service is a service identifier determination, the message content of the actual data response result is compared byte by byte with the expected data response result; if each byte is the same, it is determined that the diagnostic result of the current execution is a successful execution, and the step amount is accumulated to the successful execution counter; otherwise, it is determined that the diagnostic result of the current execution is a failed execution, and the step amount is accumulated to the failed execution counter; In the case where the content determination type of the current diagnostic service is an original determination, the data at the determination message content position in the message content of the actual data response result is compared with the expected response result according to the determination message content position defined in the diagnostic description file; if the data at the determination message content position is consistent with the expected response result, it is determined that the diagnostic result of the current execution is a successful execution, and the step amount is accumulated to the successful execution counter; otherwise, it is determined that the diagnostic result of the current execution is a failed execution, and the step amount is accumulated to the failed execution counter; In the case where the content determination type of the current diagnostic service is a physical determination, the actual response result is calculated according to the physical value operation function defined in the diagnostic description file to obtain an actual response physical value; the actual response physical value is compared with the physical value threshold range defined in the diagnostic description file, and when the actual response physical value is within the physical value threshold range, it is determined that the diagnostic result of the current execution is a successful execution, and the step amount is accumulated to the successful execution counter; otherwise, it is determined that the diagnostic result of the current execution is an execution failure, and the step amount is accumulated to the failed execution counter; Determine the execution result of the current diagnostic service according to the values ​​of the execution success counter, the execution failure counter, and the success count threshold and the failure count threshold defined in the diagnostic description file; According to the execution result of the current diagnostic service, a diagnostic result display driving signal is sent to the vehicle via the communication protocol stack.

2. The method according to claim 1, characterized in that Judging whether to execute the current diagnostic service according to the execution success counter and / or the execution failure counter of the current diagnostic service and the execution determination condition predefined in the diagnostic description file includes: Comparing the value of the execution success counter with a positive response condition threshold predefined in the diagnostic description file; When the value of the execution success counter is greater than or equal to the positive response condition threshold, it is determined that the current diagnostic service is to be executed; otherwise, it is determined that the current diagnostic service is not to be executed.

3. The method according to claim 2, characterized in that According to the execution success counter and / or the execution failure counter of the current diagnostic service and the execution determination condition predefined in the diagnostic description file, determining whether to execute the current diagnostic service further includes: In the case that there is no predefined positive response condition threshold in the diagnosis description file, it is determined that the current diagnosis service is executed unconditionally.

4. The method according to claim 1, characterized in that: Judging whether to execute the current diagnostic service according to the execution success counter and / or the execution failure counter of the current diagnostic service and the execution determination condition predefined in the diagnostic description file includes: Comparing the value of the execution failure counter with a negative response condition threshold predefined in the diagnostic description file; When the value of the execution failure counter is greater than or equal to the negative response condition threshold, it is determined that the current diagnostic service is to be executed; otherwise, it is determined that the current diagnostic service is not to be executed.

5. The method according to claim 4, characterized in that According to the execution success counter and / or the execution failure counter of the current diagnostic service and the execution determination condition predefined in the diagnostic description file, determining whether to execute the current diagnostic service further includes: In the case that there is no predefined negative response condition threshold in the diagnosis description file, it is determined that the current diagnosis service is executed unconditionally.

6. The method according to claim 1, characterized in that Obtaining the diagnostic description file from the server includes: After the diagnostic device is connected to an on-board diagnostic interface on a vehicle, the diagnostic description file is obtained through the on-board diagnostic interface and wireless communication between the vehicle and the server.

7. The method according to claim 1, characterized in that The expected response result predefined in the diagnosis description file also includes an expected timeout response result, the actual response result also includes an actual timeout response result, and the method further includes: When the actual timeout response result is consistent with the expected timeout response result, continue to perform content determination on the current diagnostic service, and determine the diagnostic result of the current execution according to the result of the content determination; When the actual timeout response result is inconsistent with the expected timeout response result, it is determined that the diagnostic result of the current execution is execution failure.

8. The method according to claim 1, characterized in that The diagnostic service type further includes a virtual service, and the method further includes: Requesting a random number from the controller to be diagnosed; receiving the random number from the controller to be diagnosed; Calculate a key according to the random number; Writing the key back to the controller to be diagnosed; receiving, from the controller to be diagnosed, a verification result of the key by the controller to be diagnosed; If the verification result is a successful verification, the diagnosis result of the current diagnostic service is a successful execution; otherwise, the diagnosis result of the current diagnostic service is a failed execution.

9. The method according to claim 1, characterized in that: The method further comprises: Reading a diagnostic service delay from the diagnostic description file; The timing of executing the plurality of diagnostic services is controlled according to the diagnostic service delay.

10. The method according to claim 1, characterized in that The specified communication parameters include vehicle communication parameters and / or communication parameters of the controller to be diagnosed.

11. The method according to claim 10, characterized in that When the diagnosis description file does not include the communication parameters of the controller to be diagnosed, the communication parameters of the communication protocol stack are configured according to the vehicle communication parameters.

12. A device for diagnosing a vehicle controller, characterized in that: The device is applied to diagnostic equipment, and comprises: A diagnostic description file acquisition module, configured to acquire a diagnostic description file from a server, wherein the diagnostic description file includes specified communication parameters and a diagnostic service queue, wherein the diagnostic service queue includes one or more diagnostic services; a communication parameter setting module configured to set communication parameters of a communication protocol stack according to the specified communication parameters, wherein the communication protocol stack is used for communication between the diagnostic device and a vehicle controller; a current diagnostic service reading module, configured to read a current diagnostic service in a diagnostic service queue in the diagnostic description file, wherein the current diagnostic service has a diagnostic service type, wherein the diagnostic service type includes a real service, wherein the diagnostic description file predefines a diagnostic request corresponding to a diagnostic service of the real service type and an expected response result, wherein the expected response result includes an expected data response result, wherein the expected data response result has a content determination type, wherein the content determination type includes a service identifier determination, an original determination, and a physical determination; An execution condition determination module, configured to determine whether to execute the current diagnostic service according to an execution success counter and / or an execution failure counter of the current diagnostic service and an execution determination condition predefined in the diagnostic description file; a termination module, configured to terminate the execution of the current diagnostic service if it is determined that the current diagnostic service is not to be executed; a diagnostic request sending module, configured to send the diagnostic request of the current diagnostic service to the to-be-diagnosed controller corresponding to the current diagnostic service via the communication protocol stack when it is determined that the current diagnostic service is to be executed; an actual response result receiving module, configured to receive, from the controller to be diagnosed via the communication protocol stack, an actual response result of the controller to be diagnosed to the diagnosis request, wherein the actual response result includes an actual data response result; a service identifier determination module, configured to compare the message content of the actual data response result with the expected data response result byte by byte when the content determination type of the current diagnostic service is service identifier determination; if each byte is the same, it is determined that the diagnostic result of the current execution is a successful execution, and the step amount is accumulated to the execution success counter; otherwise, it is determined that the diagnostic result of the current execution is a failed execution, and the step amount is accumulated to the execution failure counter; an original determination module, configured to compare the data at the determination message content position in the message content of the actual data response result with the expected response result according to the determination message content position defined in the diagnostic description file when the content determination type of the current diagnostic service is an original determination; if the data at the determination message content position is consistent with the expected response result, then it is determined that the diagnostic result of the current execution is a successful execution, and the step amount is accumulated to the execution success counter; otherwise, it is determined that the diagnostic result of the current execution is a failed execution, and the step amount is accumulated to the execution failure counter; A physical determination module is configured to, when the content determination type of the current diagnostic service is physical determination, calculate the actual response result according to the physical value operation function defined in the diagnostic description file to obtain an actual response physical value; compare the actual response physical value with the physical value threshold range defined in the diagnostic description file, and when the actual response physical value is within the physical value threshold range, determine that the diagnostic result of the current execution is a successful execution, and accumulate the step amount to the successful execution counter; otherwise, determine that the diagnostic result of the current execution is a failed execution, and accumulate the step amount to the failed execution counter; An execution result determination module, configured to determine the execution result of the current diagnostic service according to the values ​​of the execution success counter, the execution failure counter, and the success count threshold and the failure count threshold defined in the diagnostic description file; The diagnosis result display driving module is configured to send a diagnosis result display driving signal to the vehicle via the communication protocol stack according to the execution result of the current diagnosis service.

13. A diagnostic device, characterized in that The device comprises a memory and a processor, wherein a computer program is stored in the memory, and when the computer program is executed by the processor, the method according to any one of claims 1 to 11 is implemented.

14. A system for diagnosing a vehicle controller, comprising a server and the diagnostic device according to claim 13, wherein: The server stores a diagnosis description file.

15. A storage medium storing computer-readable instructions, wherein when the instructions are executed by a processor, the method according to any one of claims 1 to 11 is executed.

Images