Fault diagnosis method and device, computer device, storage medium and program product

Abstract

The application relates to a fault diagnosis method and device, computer equipment, a storage medium and a program product, and relates to the technical field of fault diagnosis. The method comprises the following steps: obtaining a fault diagnosis request for a target device; determining a target electronic control unit (ECU) matched with the fault diagnosis request; determining a target sending strategy corresponding to the fault diagnosis request according to the communication capability of the target ECU; and sending the fault diagnosis request to the target ECU in response to the target sending strategy, so that the target ECU performs fault diagnosis on the target device in response to the fault diagnosis request. The method can avoid conflicts when multiple ECUs perform fault diagnosis to a certain extent, thereby improving the fault diagnosis efficiency to a certain extent.

Description

Technical Field

[0001] This application relates to the field of fault diagnosis technology, and in particular to a fault diagnosis method, apparatus, computer equipment, storage medium and program product. Background Technology

[0002] With the widespread application of robots and other equipment, equipment diagnostics plays a crucial role in remote maintenance, fault analysis, and equipment health management. Especially for equipment deployed with multiple Electronic Control Units (ECUs), reliable fault identification directly impacts equipment operation and maintenance efficiency.

[0003] However, in the relevant fault diagnosis schemes, the diagnostic operations of each ECU often conflict with each other, which affects the overall fault diagnosis efficiency of the equipment. Summary of the Invention

[0004] Based on this, this application addresses the aforementioned technical problems by providing a fault diagnosis method, apparatus, computer equipment, storage medium, and program product that can improve fault diagnosis efficiency.

[0005] Firstly, this application provides a fault diagnosis method, including:

[0006] Obtain a fault diagnosis request for the target device;

[0007] Identify the target electronic control unit (ECU) that matches the fault diagnosis request;

[0008] Based on the communication capabilities of the target ECU, determine the target sending strategy corresponding to the fault diagnosis request;

[0009] In response to the target sending strategy, a fault diagnosis request is sent to the target ECU, so that the target ECU responds to the fault diagnosis request and performs fault diagnosis on the target device.

[0010] The aforementioned fault diagnosis method, by identifying the target ECU that matches the fault diagnosis request and determining the target transmission strategy corresponding to the fault diagnosis request based on the communication capability of the target ECU, can achieve centralized scheduling of each ECU in a target device with multiple ECUs. Specifically, using the target ECU that matches the fault diagnosis request to execute the fault diagnosis request can achieve accurate execution of the request, avoiding conflicts when multiple ECUs perform fault diagnosis to a certain extent, thus improving fault diagnosis efficiency. The communication capability of the target ECU reflects the transmission efficiency of the fault diagnosis request; determining the target transmission strategy based on the communication capability of the target ECU can further improve fault diagnosis efficiency.

[0011] In one embodiment, the communication capability includes online status and response time. Based on the communication capability of the target ECU, a target transmission strategy corresponding to the fault diagnosis request is determined, including: when the target ECU is online and its response time meets the required response time for the fault diagnosis request, determining the target transmission strategy based on the service priority of the fault diagnosis request and the link load of the target ECU; when the target ECU is offline or its response time does not meet the required response time for the fault diagnosis request, determining the target transmission strategy as a retransmission strategy; wherein the retransmission strategy is to retransmit the fault diagnosis request.

[0012] In this embodiment, the method of determining the target sending strategy corresponding to the fault diagnosis request based on the communication capability of the target ECU can determine the target sending strategy that matches the communication capability of the target ECU. This can reduce the unreasonable utilization of communication resources caused by static sending strategies to a certain extent, and improve the success rate and efficiency of sending fault diagnosis requests to a certain extent.

[0013] In one embodiment, a target sending strategy is determined based on the service priority of the fault diagnosis request and the link load status corresponding to the target ECU, including: determining a low-load sending strategy when the service priority is first priority; and determining an idle sending strategy when the service priority is second priority; wherein the second priority is lower than the first priority; wherein the low-load sending strategy is to send the fault diagnosis request when the load in the link corresponding to the target ECU is lower than the load threshold; and the idle sending strategy is to send the fault diagnosis request when the link corresponding to the target ECU is in an idle state.

[0014] In this embodiment, the method of determining the target transmission strategy based on the service priority of the fault diagnosis request and the link load of the target ECU ensures that fault diagnosis requests with higher service priority are sent out first when the data transmission pressure of the link corresponding to the target ECU is relatively low, while fault diagnosis requests with lower service priority are sent out when the link corresponding to the target ECU is idle. This can balance the real-time transmission of fault diagnosis requests with the consumption of link resources to a certain extent, thereby improving the transmission efficiency of fault diagnosis requests and the efficiency of fault diagnosis.

[0015] In one embodiment, sending a fault diagnosis request to a target ECU includes: obtaining communication reference data; wherein the communication reference data includes at least one of the following: the data volume of the fault diagnosis request, the diagnostic service type, and the link load status corresponding to the target ECU; determining the target communication method corresponding to the target ECU based on the communication capability of the target ECU and the communication reference data; and sending the fault diagnosis request to the target ECU according to the target communication method.

[0016] In this embodiment, the target communication method corresponding to the target ECU is determined based on the target ECU's communication capabilities and communication reference data. This can improve the target ECU's communication adaptability to a certain extent, thereby enabling the use of the target communication method to send fault diagnosis requests, which can improve sending efficiency and thus improve fault diagnosis efficiency.

[0017] In one embodiment, after sending the fault diagnosis request to the target ECU, the fault diagnosis method further includes: obtaining the sending result of the fault diagnosis request and the response time of the target ECU; if the sending result indicates that the fault diagnosis request failed to be sent, or the response time exceeds a preset time, sending the fault diagnosis request to the proxy execution unit so that the proxy execution unit responds to the fault diagnosis request and feeds back proxy response data.

[0018] In this embodiment, by sending the fault diagnosis request to the proxy execution unit when the sending result indicates that the fault diagnosis request failed to be sent or the response time exceeds the preset time, the fault diagnosis request can be processed in a timely manner, the continuity of the fault diagnosis information flow can be maintained, the impact of the target ECU abnormality on the fault diagnosis process can be reduced to a certain extent, and the fault diagnosis efficiency can be improved.

[0019] In one embodiment, when the diagnostic service type of the fault diagnosis request is a first service type, the proxy response data includes marking information that marks the fault diagnosis request as pending execution; when the diagnostic service type of the fault diagnosis request is a second service type, the proxy response data includes the fault diagnosis result obtained by performing fault diagnosis on the target device based on the fault diagnosis request; wherein, the service importance of the second service type is lower than that of the first service type.

[0020] In this embodiment, the proxy execution unit only performs proxy operations on fault diagnosis requests with low service importance (such as the first service type), and marks fault diagnosis requests with high service importance (such as the second service type). On the one hand, this can maintain the continuity of the fault diagnosis process, and on the other hand, it can reduce the misdiagnosis of faults to a certain extent, thereby improving the efficiency of fault diagnosis.

[0021] In one embodiment, determining the target electronic control unit (ECU) that matches the fault diagnosis request includes: obtaining the target logical address carried in the fault diagnosis request; and determining the target ECU that matches the fault diagnosis request based on the target logical address and the ECUs corresponding to each preset logical address.

[0022] In this embodiment, based on the target logical address and the ECU corresponding to each preset logical address, the target ECU matching the fault diagnosis request can be quickly determined, thereby improving the sending efficiency of the fault diagnosis request and thus improving the fault diagnosis efficiency.

[0023] In one embodiment, the fault diagnosis method further includes: obtaining the diagnostic service type and source information of the fault diagnosis request; receiving the fault diagnosis result fed back by the target ECU in response to the fault diagnosis request; encapsulating the fault diagnosis result and feeding back the encapsulated fault diagnosis result to the source end indicated by the source information.

[0024] In this embodiment, by encapsulating the fault diagnosis results and feeding the encapsulated fault diagnosis results back to the source end indicated by the source information, it is possible to aggregate the fault diagnosis results corresponding to fault diagnosis requests from the same source to the source end, thereby achieving unified processing of the fault diagnosis results and improving fault diagnosis efficiency.

[0025] Secondly, this application also provides a fault diagnosis device, comprising:

[0026] The first acquisition module is used to acquire fault diagnosis requests for the target device;

[0027] The first determining module is used to determine the target ECU that matches the fault diagnosis request;

[0028] The second determining module is used to determine the target sending strategy corresponding to the fault diagnosis request based on the communication capability of the target ECU.

[0029] The first sending module is used to send a fault diagnosis request to the target ECU in response to the target sending strategy, so that the target ECU can respond to the fault diagnosis request and perform fault diagnosis on the target device.

[0030] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the methods described above.

[0031] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described above.

[0032] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in any of the above aspects.

[0033] Regarding the beneficial effects of any of the technical solutions in the second to fifth aspects mentioned above, refer to the beneficial effects of the corresponding technical solutions in the first aspect; repeated examples will not be listed here. Attached Figure Description

[0034] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1 This is a schematic diagram of an optional flowchart of a fault diagnosis method in one embodiment;

[0036] Figure 2 This is a schematic diagram of an optional step in determining the target sending strategy in one embodiment;

[0037] Figure 3 This is a schematic diagram of an optional step in sending a fault diagnosis request in one embodiment;

[0038] Figure 4 This is a schematic diagram of an optional flowchart of a fault diagnosis method in another embodiment;

[0039] Figure 5 This is a schematic diagram of an optional flowchart of a fault diagnosis method in yet another embodiment;

[0040] Figure 6 This is a schematic diagram of an optional flowchart of a fault diagnosis method in yet another embodiment;

[0041] Figure 7 This is a schematic diagram of an optional structure of a fault diagnosis system in one embodiment;

[0042] Figure 8 This is a schematic diagram of an optional flowchart of a fault diagnosis method in yet another embodiment;

[0043] Figure 9 This is a schematic diagram of an optional structure of a fault diagnosis device in one embodiment;

[0044] Figure 10 This is a schematic diagram of an optional internal structure of a computer device in one embodiment. Detailed Implementation

[0045] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of this application.

[0046] The terms “first,” “second,” etc., as used in this application may be used to describe various elements, but these elements are not limited by these terms. These terms are used only to distinguish the first element from the second element. The terms “comprising” and “having,” and any variations thereof, as used in this application, are intended to cover non-exclusive inclusion. The term “multiple” as used in this application refers to two or more.

[0047] In one exemplary embodiment, the fault diagnosis request provided in this application can be applied to the central control unit (CCU) in the fault diagnosis system corresponding to the target device. In some embodiments, the fault diagnosis system can be deployed in the control system corresponding to the target device.

[0048] In one exemplary embodiment, such as Figure 1 As shown, a fault diagnosis method is provided, including the following:

[0049] S110, Obtain a fault diagnosis request for the target device.

[0050] The target device can be understood as the device to be diagnosed. For example, the target device may include at least one of the following: a robot, a robotic dog, a vehicle, industrial control equipment, or other equipment. Multiple ECUs or distributed control units are deployed in the target device.

[0051] In this context, a fault diagnosis request can be understood as a request used to diagnose faults in the target device.

[0052] In some embodiments, the acquired fault diagnosis request may include at least one. The at least one fault diagnosis request may be sent from a remote cloud, or from a local diagnostic instrument, or from both a remote cloud and a local diagnostic instrument.

[0053] S120, Identify the target ECU that matches the fault diagnosis request.

[0054] The target ECU can be understood as a diagnostic execution unit used to respond to fault diagnosis requests and perform fault diagnosis on the target device.

[0055] In some embodiments, the target logical address carried in the fault diagnosis request can be obtained; and the target ECU matching the fault diagnosis request can be determined based on the target logical address and the ECU corresponding to each preset logical address.

[0056] In some embodiments, the fault diagnosis request can be parsed to obtain a structured object. The structured object may include a target logical address. In some embodiments, a pre-configured mapping relationship between preset logical addresses and their corresponding ECUs can be obtained, such as an address mapping table. Based on the target logical address and the ECUs corresponding to each preset logical address, the target ECU corresponding to the target logical address can be determined as the target ECU matching the fault diagnosis request.

[0057] S130: Determine the target sending strategy corresponding to the fault diagnosis request based on the communication capability of the target ECU.

[0058] The communication capability of the target ECU can be understood as the ability of the target ECU to exchange data with the execution unit (CCU).

[0059] In some embodiments, the communication capabilities of the target ECU may include at least one of the following: links supported by the target ECU, the online status of the target ECU, the maximum message length processed, whether multi-session is supported, and response time. The links supported by the target ECU may include at least one of the following: Controller Area Network (CAN) bus link, CANFD (Controller Area Network with Flexible Data Rate) link, and DOIP (Diagnostics over Internet Protocol) link. The online status of the target ECU may include online or offline. The response time may be the minimum response time.

[0060] Based on the communication capabilities of the target ECU, it can be determined whether the target ECU can receive the fault diagnosis request, thereby determining the target sending strategy corresponding to the fault diagnosis request.

[0061] In some embodiments, the online status of a target ECU can be determined using heartbeat information.

[0062] In some embodiments, an ECU communication capability table can be obtained, and the communication capabilities of the target ECU can be determined based on the ECU communication capability table. The communication capability table may include the communication capabilities of each ECU, such as the links supported by each ECU, the maximum message length that can be processed, whether multi-session is supported, and the minimum response time.

[0063] The target transmission strategy may include the transmission order and transmission method corresponding to the fault diagnosis requests. The transmission order can be understood as the priority order in which fault diagnosis requests are sent. The transmission method may include at least one of the following: immediate transmission, delayed transmission, and retransmission.

[0064] S140, in response to the target sending strategy, a fault diagnosis request is sent to the target ECU, so that the target ECU responds to the fault diagnosis request and performs fault diagnosis on the target device.

[0065] In some embodiments, the target ECU can select an execution path matching the diagnostic service type of the fault diagnosis request. For example, the diagnostic service type may include fault code service type, parameter access service type, software flashing service type, etc. For example, for a fault code service type fault diagnosis request, the target ECU can read fault codes present in the target device's internal storage data or monitoring data and generate response data. For a parameter access service type fault diagnosis request, the target ECU can return target parameters in the target device or perform a write operation to target parameters according to access permissions. For a software flashing service type fault diagnosis request, the target ECU can perform data reception, verification, and writing operations on the target software in the target device according to the flashing specifications.

[0066] In the above-mentioned fault diagnosis method, by identifying the target ECU that matches the fault diagnosis request and determining the target transmission strategy corresponding to the fault diagnosis request based on the communication capability of the target ECU, centralized scheduling of each ECU in a target device with multiple ECUs can be achieved. In particular, using the target ECU that matches the fault diagnosis request to execute the fault diagnosis request can achieve accurate execution of the fault diagnosis request, and to a certain extent avoid conflicts when multiple ECUs perform fault diagnosis, thereby improving the fault diagnosis efficiency to a certain extent. The communication capability of the target ECU can reflect the transmission efficiency of the fault diagnosis request, and determining the target transmission strategy based on the communication capability of the target ECU can further improve the fault diagnosis efficiency.

[0067] Based on the technical solutions of the above embodiments, this application also provides an optional embodiment in which the communication capability is refined into online status and response time, and correspondingly, the steps for determining the target sending strategy are refined.

[0068] See Figure 2 The steps for determining the target transmission strategy shown include:

[0069] S210, if the target ECU is online and the response time of the target ECU meets the required response time for the fault diagnosis request, determine the target sending strategy based on the service priority of the fault diagnosis request and the link load of the target ECU.

[0070] The requirement that the response time of the target ECU meets the required response time for the fault diagnosis request can be understood as the response time of the target ECU not exceeding the required response time for the fault diagnosis request.

[0071] Service priority can be understood as the processing order of fault diagnosis requests. In some embodiments, service priority is related to the diagnostic service type and service sub-function of the fault diagnosis request. Service sub-functions may include detailed operations under the corresponding diagnostic service type, such as the switching operation between the default session and the programming session under the session control service type. For example, service types for high-frequency status queries in the BMS (Battery Management System) correspond to higher service priorities, while service types for accessing non-critical parameters correspond to lower service priorities.

[0072] The link load status can be understood as the amount of data being transmitted on the link corresponding to the ECU and its occupancy status of link resources.

[0073] In some embodiments, when the service priority is first priority, the target transmission strategy can be determined as a low-load transmission strategy. The low-load transmission strategy involves sending a fault diagnosis request when the load in the link corresponding to the target ECU is below a load threshold.

[0074] In this context, a load below a load threshold on the link corresponding to the target ECU can be understood as the link not being idle and the current data traffic carried by the link being lower than a pre-set load threshold. When the load on the link corresponding to the target ECU is below the load threshold, the data transmission pressure on that link is relatively low. In some embodiments, a fault diagnosis request with a service priority of first priority can be sent immediately.

[0075] In some embodiments, when the service priority is second priority, the target transmission strategy can be determined to be an idle transmission strategy. The second priority is lower than the first priority. The idle transmission strategy involves sending a fault diagnosis request when the link corresponding to the target ECU is in an idle state.

[0076] When the link corresponding to the target ECU is idle, it does not need to transmit other data, and a fault diagnosis request with the second priority can be sent.

[0077] The above method of determining the target transmission strategy based on the service priority of the fault diagnosis request and the link load of the target ECU ensures that fault diagnosis requests with higher service priority are sent out first when the data transmission pressure of the link corresponding to the target ECU is relatively low, and fault diagnosis requests with lower service priority are sent out when the link corresponding to the target ECU is idle. This can balance the real-time transmission of fault diagnosis requests with the consumption of link resources to a certain extent, thereby improving the transmission efficiency of fault diagnosis requests and the efficiency of fault diagnosis.

[0078] S220: If the target ECU is not online or the response time of the target ECU does not meet the required response time for the fault diagnosis request, the target sending strategy is determined to be a resend strategy.

[0079] The resend strategy involves resending the fault diagnosis request.

[0080] In some embodiments, the retransmission strategy may be to send the fault diagnosis request according to a preset number of retransmissions.

[0081] In some embodiments, when the diagnostic service type of the fault diagnosis request is a first service type, the preset retransmission count can be greater than 1, meaning the fault diagnosis request can be retransmitted multiple times. In some embodiments, when the diagnostic service type of the fault diagnosis request is a second service type, the preset retransmission count can be 1, meaning a single retransmission. The service importance of the second service type is lower than that of the first service type.

[0082] In some embodiments, the transmission status can be recorded each time a fault diagnosis request is resent in order to backtrack the transmission status and determine whether to execute the resentment strategy again or adjust the target transmission strategy to complete the diagnosis task as much as possible.

[0083] If the target ECU is not online or its response time does not meet the required response time for the fault diagnosis request, the target ECU cannot send the fault diagnosis request in a timely manner. Therefore, determining the target sending strategy as a resend strategy can improve the success rate of sending the fault diagnosis request to a certain extent and complete the diagnosis task as much as possible.

[0084] In this embodiment, the method of determining the target sending strategy corresponding to the fault diagnosis request based on the communication capability of the target ECU can determine the target sending strategy that matches the communication capability of the target ECU. This can reduce the unreasonable utilization of communication resources caused by static sending strategies to a certain extent, and improve the success rate and efficiency of sending fault diagnosis requests to a certain extent.

[0085] Based on the technical solutions of the above embodiments, this application also provides an optional embodiment in which the steps for sending the fault diagnosis request are refined.

[0086] See Figure 3 The steps for sending a fault diagnosis request, as shown, include:

[0087] S310, Obtain communication reference data; wherein, the communication reference data includes at least one of the following: the data volume of the fault diagnosis request, the diagnostic service type, and the link load status corresponding to the target ECU.

[0088] The data volume of the fault diagnosis request can be understood as the data size of the fault diagnosis request.

[0089] S320 determines the target communication method corresponding to the target ECU based on the target ECU's communication capabilities and communication reference data.

[0090] The target communication method can be understood as the communication method determined based on the target communication protocol.

[0091] In some embodiments, the target communication protocol supported by the target ECU can be determined based on the target ECU's communication capabilities and communication reference data, and the target communication method can be determined based on the target communication protocol.

[0092] For example, when the maximum message length of the target ECU is not less than the data volume of the fault diagnosis request, and the data volume of the fault diagnosis request is relatively small, the DOCAN (Diagnostics over CAN) communication protocol can be used, thereby determining whether the target communication method corresponding to the target ECU is CAN communication or CANFD communication. When the maximum message length of the target ECU is not less than the data volume of the fault diagnosis request, and the data volume of the fault diagnosis request is relatively large, the DOIP (Diagnostic communication over Internet Protocol) communication protocol can be used, thereby determining whether the target communication method corresponding to the target ECU is Ethernet communication.

[0093] S330 sends a fault diagnosis request to the target ECU according to the target communication method.

[0094] In some embodiments, the fault diagnosis request can be encapsulated into a message whose data transmission format matches the target communication method, and then the message can be sent to the target ECU.

[0095] In some embodiments, when the target communication method is CAN communication or CANFD communication, the fault diagnosis request can be segmented and encapsulated according to the data transmission specification corresponding to the target communication method to obtain at least one frame message. Based on the number of frames in the message, a transmission method matching the number of frames is determined, such as single-frame transmission or multi-frame transmission. For example, if the data volume of a request to read the battery state of charge (SOC) is less than 8 bytes, single-frame transmission can be used directly; if the data volume of a request to read historical fault logs is large, multi-frame transmission can be used. For each frame message, after transmission, the transmission sequence number, transmission time, and checksum can be recorded to ensure, to a certain extent, that the target ECU can correctly reassemble the fault diagnosis request.

[0096] Based on the technical solutions of the above embodiments, this application also provides an optional embodiment in which the fault diagnosis method is refined.

[0097] See Figure 4 The fault diagnosis method shown, after sending the fault diagnosis request to the target ECU, further includes:

[0098] S410: Obtain the result of the fault diagnosis request and the response time of the target ECU.

[0099] In some embodiments, after a fault diagnosis request is sent, a sending log for the fault diagnosis request can be saved. The sending log may include information such as the sending result and a sending timestamp. Based on the sending log, the sending result of the fault diagnosis request can be obtained. The sending result may include whether the sending was successful or failed.

[0100] In some embodiments, the response time of the target ECU can be understood as the time between the return timestamp of the target ECU in response to the fault diagnosis request and the sending timestamp of the corresponding fault diagnosis request.

[0101] S420: If the sending result indicates that the fault diagnosis request failed to be sent, or the response time exceeds the preset time, the fault diagnosis request is sent to the agent execution unit so that the agent execution unit responds to the fault diagnosis request and feeds back agent response data.

[0102] In this context, the proxy execution unit can be understood as a unit that acts as a proxy for the target ECU in responding to fault diagnosis requests. In some embodiments, the proxy execution unit can be another ECU or another unit capable of responding to fault diagnosis requests.

[0103] In some embodiments, the proxy execution unit may perform proxy operations on some fault diagnosis requests, and may mark fault diagnosis requests that cannot be procedurally executed.

[0104] In some embodiments, the proxy execution unit may perform proxy operations on fault diagnosis requests with a diagnostic service type of the second service type. Accordingly, when the diagnostic service type of the fault diagnosis request is the second service type, the proxy response data includes the fault diagnosis result obtained by performing fault diagnosis on the target device based on the fault diagnosis request.

[0105] In some embodiments, the agent execution unit can perform marking processing on fault diagnosis requests with a diagnostic service type of the first service type. Accordingly, when the diagnostic service type of the fault diagnosis request is the first service type, the agent response data includes marking information indicating that the fault diagnosis request is in a pending execution state. The service importance of the second service type is lower than that of the first service type. The agent response data can be generated by the agent execution unit based on historical data and cached information to determine the possible states of the target ECU. For example, for requests such as software flashing or parameter modification, the agent execution unit will not operate directly, but will mark it as a pending execution state and notify the scheduling unit to wait for the ECU to receive the fault diagnosis request.

[0106] In the above embodiments, the proxy execution unit only performs proxy operations on fault diagnosis requests with low service importance (such as the first service type), and marks fault diagnosis requests with high service importance (such as the second service type). On the one hand, this can maintain the continuity of the fault diagnosis process, and on the other hand, it can reduce the misdiagnosis of faults to a certain extent.

[0107] In the above embodiments, by sending the fault diagnosis request to the proxy execution unit when the sending result indicates that the fault diagnosis request failed to be sent or the response time exceeds the preset time, the fault diagnosis request can be processed in a timely manner, the continuity of the fault diagnosis information flow can be maintained, and the impact of the target ECU abnormality on the fault diagnosis process can be reduced to a certain extent.

[0108] Based on the technical solutions of the above embodiments, this application also provides an optional embodiment in which the fault diagnosis method is refined.

[0109] See Figure 5 The fault diagnosis method shown also includes:

[0110] S510, obtain the diagnostic service type and source information of the fault diagnosis request.

[0111] The source information can be understood as information used to characterize the source of the fault diagnosis request. In some embodiments, the source of the fault diagnosis request may include at least one of the following: a remote cloud and a local diagnostic instrument.

[0112] In some embodiments, the fault diagnosis request can be parsed to obtain a structured execution object. The structured execution object may include diagnostic service type and source information.

[0113] S520 receives the fault diagnosis results from the target ECU in response to the fault diagnosis request.

[0114] In some embodiments, the fault diagnosis results fed back by the target ECU in response to the fault diagnosis request can be received through a link between the target ECU and the target ECU.

[0115] in, Figure 5 The execution order of S510 and S520 is only illustrative. In some embodiments, the execution order of S510 and S520 can be arranged arbitrarily.

[0116] S530 encapsulates the fault diagnosis results and feeds back the encapsulated fault diagnosis results to the source end indicated by the source information.

[0117] In some embodiments, when the source indicated by the source information is a remote cloud, the encapsulated fault diagnosis results can be fed back to the remote cloud through the communication interface; when the source indicated by the source information is a local diagnostic instrument, the encapsulated fault diagnosis results can be returned to the local diagnostic instrument.

[0118] In the above embodiments, by encapsulating the fault diagnosis results and feeding the encapsulated fault diagnosis results back to the source end indicated by the source information, it is possible to aggregate the fault diagnosis results corresponding to fault diagnosis requests from the same source to the source end, thereby achieving unified processing of the fault diagnosis results.

[0119] In some embodiments, after receiving the fault diagnosis result from the target ECU in response to the fault diagnosis request, the fault diagnosis result can be categorized according to the target ECU and the diagnostic service type, and fault diagnosis results of the same category can be uniformly provided to external systems for querying and statistics. Furthermore, the fault diagnosis result can be stored for subsequent retrieval and analysis. In some embodiments, fault diagnosis results corresponding to fault diagnosis requests with lower service importance are also included.

[0120] Based on the technical solutions of the above embodiments, this application also provides an optional embodiment in which the fault diagnosis method is described in detail.

[0121] See Figure 6 The fault diagnosis method shown includes:

[0122] S601, Obtain a fault diagnosis request for the target device.

[0123] S602, obtain the target logical address carried in the fault diagnosis request.

[0124] S603: Based on the target logical address and the ECUs corresponding to each preset logical address, determine the target ECU that matches the fault diagnosis request.

[0125] S604: If the target ECU is online, the response time of the target ECU meets the required response time for the fault diagnosis request, and the service priority is the first priority, the target sending strategy is determined to be the low-load sending strategy.

[0126] The low-load sending strategy involves sending a fault diagnosis request when the load in the link corresponding to the target ECU is lower than the load threshold.

[0127] S605, under the conditions that the target ECU is online, the response time of the target ECU meets the required response time for the fault diagnosis request, and the service priority is the second priority, the target sending strategy is determined to be the idle sending strategy.

[0128] The idle transmission strategy involves sending a fault diagnosis request when the link corresponding to the target ECU is in an idle state.

[0129] S606: If the target ECU is not online or the response time of the target ECU does not meet the required response time for the fault diagnosis request, the target sending strategy is determined to be a resend strategy.

[0130] The resend strategy involves resending the fault diagnosis request.

[0131] S607, in response to the target transmission strategy, obtains communication reference data.

[0132] The communication reference data includes at least one of the following: the data volume of the fault diagnosis request, the type of diagnosis service, and the link load status corresponding to the target ECU.

[0133] S608 determines the target communication method corresponding to the target ECU based on the target ECU's communication capabilities and communication reference data.

[0134] S609 sends a fault diagnosis request to the target ECU according to the target communication method.

[0135] S610, after sending a fault diagnosis request to the target ECU, obtains the sending result of the fault diagnosis request and the response time of the target ECU.

[0136] S611, if the sending result indicates that the fault diagnosis request failed to be sent, or the response time exceeds the preset time, the fault diagnosis request is sent to the agent execution unit so that the agent execution unit responds to the fault diagnosis request and feeds back agent response data.

[0137] In some embodiments, when the diagnostic service type of the fault diagnosis request is a first service type, the proxy response data includes marking information that marks the fault diagnosis request as pending execution; when the diagnostic service type of the fault diagnosis request is a second service type, the proxy response data includes the fault diagnosis result obtained by performing fault diagnosis on the target device based on the fault diagnosis request; wherein, the service importance of the second service type is lower than that of the first service type.

[0138] S612, obtain the diagnostic service type and source information of the fault diagnosis request.

[0139] S613 receives the fault diagnosis results from the target ECU in response to the fault diagnosis request.

[0140] S614 encapsulates the fault diagnosis results and feeds back the encapsulated fault diagnosis results to the source end indicated by the source information.

[0141] In one exemplary embodiment, a fault diagnosis system is provided that can be applied to the fault diagnosis method described above.

[0142] like Figure 7 The fault diagnosis system shown includes a CCU and at least one ECU in the target device. The CCU is equipped with a diagnostic access and session management unit, a diagnostic service execution request generation unit, a diagnostic management and scheduling unit, a diagnostic communication adaptive adaptation unit, a diagnostic agent execution unit, and a diagnostic result aggregation and reporting unit. Each ECU is equipped with an ECU diagnostic execution unit.

[0143] The Diagnostic Access and Session Management Unit (DAU), deployed within the CCU, is used for receiving, parsing, and initially scheduling fault diagnosis requests. Upon power-up of the fault diagnosis system, the DAU initializes the session management table, request buffer queue, and communication channel status table, and loads the mapping relationships between preset ECU logical addresses and ECUs, as well as service support information, providing the basic data structure for subsequent request processing. The DAU assigns a unique session identifier to each fault diagnosis request and records the request's source information, target ECU, diagnostic service type, and execution context information (execution result, timestamp, parameter verification status, etc.), ensuring that the request is traceable and manageable throughout its entire lifecycle.

[0144] The diagnostic access and session management unit supports high-concurrency access and complete state tracking, achieving fast lookup and state updates through a combination of hash indexes and circular queues. For fault diagnosis requests involving services of high importance, historical execution logs and context information can be stored in session entries to support exception handling and proxy execution. For fault diagnosis requests involving services of lower importance, cached data and temporary flagged data can maintain a lightweight design to reduce resource consumption.

[0145] For fault diagnosis requests originating from a remote cloud, after being received by the communication agent, the diagnostic access and session management unit first verifies the integrity and legality of the request, such as verifying the message format, the logical address of the target ECU, and access permissions. Upon successful verification, a unique session identifier is generated, an entry is created in the management structure, and the fault diagnosis request is cached in a queue. For fault diagnosis requests originating from a local diagnostic instrument, the request can enter the system through the DOIP session of the local diagnostic instrument. The diagnostic access and session management unit can parse each fault diagnosis request to obtain its source information, target ECU, diagnostic service type, and execution context. Service priority is determined based on the diagnostic service type. Each fault diagnosis request has a corresponding path from access to execution, thus preventing system blockage when timeout or retry mechanisms are triggered.

[0146] The diagnostic access and session management unit can maintain session state and handle session exceptions through a session state machine. The session state machine covers the creation, execution, completion, and abnormal termination phases, with corresponding session states of Pending, InProgress, Completed, and Error / Timeout, respectively. Upon entering the execution phase, the session state machine can update the session state to InProgress; after a fault diagnosis request is successfully sent, the session state can be marked as Completed. If the target ECU corresponding to the fault diagnosis request does not respond, the communication link is abnormal, or the service is not supported, an exception handling mechanism can be triggered to generate an error response, update the state, and record the error code.

[0147] The diagnostic access and session management unit can perform session cache release, context destruction, and concurrency control to ensure stable long-term system operation. After each session completes, memory and bound resources can be promptly reclaimed to prevent resource leaks. This unit can also provide parsed request objects to the downstream diagnostic service execution request generation unit and allow the diagnostic management and scheduling unit to query and update session status. Simultaneously, it reports response and completion status to the diagnostic result aggregation and reporting unit, achieving closed-loop management of access, parsing, scheduling, and result reporting while maintaining module decoupling for easy expansion and maintenance.

[0148] The diagnostic service execution request generation unit, deployed within the CCU, parses fault diagnosis requests and abstracts them into structured execution objects, serving as the unified basis for subsequent scheduling and communication. During initialization, the unit can load the set of diagnostic service types and service parameter tables supported by all ECUs, providing processing and verification rules for fault diagnosis requests of different service types. During operation, each fault diagnosis request entering the unit first undergoes format parsing to obtain a structured execution object, including the target ECU logical address, diagnostic service type identifier, service sub-function identifier, and additional parameters. For fault diagnosis requests with higher service priority or parameter constraints, parameter verification rules, historical execution results, and the last execution time can also be externally recorded for subsequent scheduling and exception handling. For fault diagnosis requests with lower service priority, preset basic fields are saved to conserve memory resources.

[0149] The diagnostic service execution request generation unit can perform a validity check on the fault diagnosis request during the verification phase, including whether the diagnostic service type is a type supported by the target ECU and whether the length and format of the fault diagnosis parameters are correct. During the abstraction phase, it can map the raw byte data in the fault diagnosis request to execution object fields. During the generation phase, it can create a unique execution request object and associate it with a unique session identifier. After parsing, the diagnostic service execution request generation unit can send the fault diagnosis request to the diagnostic management and scheduling unit and record it in the session management table to support subsequent tracking and anomaly handling.

[0150] The diagnostic management and scheduling unit is used to determine the target transmission strategy for fault diagnosis requests. Upon receiving a fault diagnosis request, the unit can determine whether the target ECU is online and reachable via heartbeat information or link status indicators. Then, based on a preset communication capability table, it determines whether the target ECU's communication capabilities meet the transmission requirements of the fault diagnosis request. If the target ECU's communication capabilities meet the requirements, the fault diagnosis request can be sent; if not, the target transmission strategy can be determined to be delayed, or the fault diagnosis request can be sent to the diagnostic agent execution unit. The diagnostic management and scheduling unit can also allocate corresponding communication bandwidth and execution resources for the fault diagnosis request.

[0151] After determining the target transmission strategy, the diagnostic management and scheduling unit can send fault diagnosis requests to the ECU diagnostic execution unit or diagnostic agent execution unit through the diagnostic communication adaptive adaptation unit. During the distribution process, the diagnostic management and scheduling unit can maintain the status information of each fault diagnosis request, such as distribution time, execution stage, current link, execution result, and anomaly flag.

[0152] The diagnostic communication adaptive adaptation unit determines the target communication method for the target ECU based on its communication capabilities, the data volume of the fault diagnosis request, the diagnostic service type, and the link load of the target ECU. It then maps the fault diagnosis request into a message matching the target communication method and sends it to the target ECU. During initialization, the diagnostic communication adaptive adaptation unit can load communication interface configurations, including CAN, CANFD, and Ethernet interfaces, as well as bandwidth and latency parameters for each channel. During runtime, the unit selects the target communication protocol based on the target ECU's communication capabilities, the data volume of the fault diagnosis request, the diagnostic service type, and the link load of the target ECU, and determines the target communication method accordingly.

[0153] If a timeout, verification failure, or link anomaly occurs during message transmission or reception, the diagnostic communication adaptive adaptation unit can trigger a retransmission mechanism or notify the diagnostic management and scheduling unit to adjust the target transmission strategy.

[0154] The ECU diagnostic execution unit is deployed within each ECU. During the ECU power-on initialization phase, it loads its supported diagnostic service list, parameter access permissions, and software flashing configuration. During operation, the ECU diagnostic execution unit receives fault diagnosis requests from the CCU and verifies whether the logical address of the fault diagnosis request matches its own corresponding logical address. If they match, it schedules internal processing logic based on the diagnostic service type of the fault diagnosis request, such as fault code reading and clearing, ECU information reading, parameter access, and software updates, to perform fault diagnosis operations on the target device that match the diagnostic service type.

[0155] The ECU diagnostic execution unit can select the appropriate execution path based on the type of diagnostic service. For fault code services, the ECU diagnostic execution unit reads internal storage or monitoring data to generate response data; for parameter access services, the ECU diagnostic execution unit returns data or confirms the write operation according to access permissions; for software flashing services, the ECU diagnostic execution unit receives, verifies, and writes data according to the flashing specifications. After the response data is generated, the ECU diagnostic execution unit can encapsulate the response data and send it back to the CCU.

[0156] The diagnostic agent execution unit, deployed within the CCU, is used to handle situations where fault diagnosis requests fail to be sent or the target ECU experiences a response delay. The diagnostic agent execution unit can perform proxy operations on fault diagnosis requests with low service importance and perform marking processing on fault diagnosis requests with high service importance.

[0157] The diagnostic result aggregation and reporting unit receives response data from the ECU diagnostic execution unit or the agent execution unit, and parses, organizes, and encapsulates the results. When the fault diagnosis request originates from a remote cloud, the encapsulated response data can be reported to the cloud system through a communication proxy; when the fault diagnosis request originates from the local diagnostic mode, the encapsulated response data can be returned to the diagnostic instrument.

[0158] The diagnostic result aggregation and reporting unit can also classify response data according to the logical address and service type of the target ECU, providing a unified interface for external systems to query and statistically analyze it. It also supports historical data caching for analysis and debugging. Debugging logs or non-critical service results can be recorded as needed to avoid interfering with real-time reporting. If communication interruption or message anomalies occur during response data reception or reporting, the diagnostic result aggregation and reporting unit can trigger a retransmission or backtracking mechanism, while updating the session state and error flags. For important fault diagnosis requests, the unit will maintain a cache and attempt to report multiple times; for non-critical fault diagnosis requests, the unit will record anomalies and analyze them in the background to ensure overall system performance and stability.

[0159] This application also provides an optional embodiment in which the fault diagnosis method will be described in detail from the perspective of multi-party interaction.

[0160] See Figure 8 The fault diagnosis method shown involves the CCU triggering a unified initialization of the diagnostic system after the target device is powered on, initiating the initialization phase. First, the diagnostic access and session management unit initializes the session management table, request buffer queue, and communication channel status, and loads the mapping relationship between each preset ECU logical address and the ECU, as well as service support information. The diagnostic service execution request generation unit loads the diagnostic service templates and parameter rules for each ECU. The diagnostic service template is a standardized definition of different fault diagnosis requests (such as reading data, writing parameters, etc.), including service identifiers, parameter formats, length constraints, and processing rules, used to guide request parsing and verification. Parameter rules constrain the format, length, value range, and legality verification conditions of diagnostic service parameters, ensuring that the fault diagnosis request conforms to the target ECU's interface specifications before execution. The diagnostic communication adaptive adaptation unit initializes the interface parameters of the CAN bus link, CANFD bus link, and DOIP link to ensure link availability. Each ECU diagnostic execution unit loads its supported diagnostic service types and parameter permissions. The diagnostic proxy execution unit prepares historical diagnostic cache data to provide a basis for possible proxy responses. The diagnostic structure aggregation and reporting unit initializes the result cache and unified reporting interface.

[0161] After the fault diagnosis system is initialized, the CCU enters the normal operation phase. During this phase, remote cloud or local diagnostic instruments send fault diagnosis requests to the Diagnostic Access and Session Management Unit. The Diagnostic Access and Session Management Unit assigns a unique session identifier to each fault diagnosis request and creates an entry in the session management table, recording the source information, the matched target ECU, the diagnostic service type, and the execution context information. The Diagnostic Access and Session Management Unit then sends the fault diagnosis request to the Diagnostic Service Execution Request Generation Unit. This unit parses the fault diagnosis request into a structured execution object, containing the target ECU, diagnostic service type, sub-function service identifier, parameters, and service priority, and submits the structured execution object to the Diagnostic Management and Scheduling Unit. The Diagnostic Management and Scheduling Unit assesses the communication capabilities of the target ECU. Based on the target ECU's communication capabilities, service priority, and link load, it determines the target transmission strategy for each fault diagnosis request and issues communication tasks to the Diagnostic Communication Adaptive Unit. The Diagnostic Communication Adaptive Unit generates corresponding messages according to the communication protocols supported by the target ECU and issues them to the corresponding ECU diagnostic execution unit. The ECU diagnostic execution unit executes the fault diagnosis request, obtains the response data, and returns the response data to the diagnostic management and scheduling unit through the diagnostic communication adaptive adaptation unit. The diagnostic management and scheduling unit updates the sending status of the fault diagnosis request. If the message transmission fails or the target ECU response times out, the message is sent to the diagnostic agent execution unit. The diagnostic agent execution unit executes the fault diagnosis request, generates response data, and returns the response data to the diagnostic management and scheduling unit. The diagnostic management and scheduling unit submits the response data returned by the ECU diagnostic execution unit or the diagnostic agent execution unit to the diagnostic result aggregation and reporting unit. The diagnostic result aggregation and reporting unit uniformly parses the response data returned by the ECU or agent, encapsulates the response data, and transmits it back to the remote cloud or local diagnostic instrument through the corresponding communication interface, and records the historical status for debugging and anomaly analysis.

[0162] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0163] Based on the same inventive concept, this application also provides a fault diagnosis device for implementing the fault diagnosis method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more fault diagnosis device embodiments provided below can be found in the limitations of the fault diagnosis method described above, and will not be repeated here.

[0164] In one exemplary embodiment, such as Figure 9 As shown, a fault diagnosis device is provided, comprising: a first acquisition module 910, a first determination module 920, a second determination module 930, and a first transmission module 940, wherein:

[0165] The first acquisition module 910 is used to acquire a fault diagnosis request for the target device;

[0166] The first determining module 920 is used to determine the target ECU that matches the fault diagnosis request;

[0167] The second determining module 930 is used to determine the target sending strategy corresponding to the fault diagnosis request based on the communication capability of the target ECU.

[0168] The first sending module 940 is used to send a fault diagnosis request to the target ECU in response to the target sending strategy, so that the target ECU responds to the fault diagnosis request and performs fault diagnosis on the target device.

[0169] In one embodiment, the communication capability includes online status and response time; the second determining module 930 includes: a first determining unit, configured to determine a target sending strategy based on the service priority of the fault diagnosis request and the link load of the target ECU when the target ECU is online and the response time of the target ECU meets the required response time corresponding to the fault diagnosis request; and a second determining unit, configured to determine the target sending strategy as a retransmission strategy when the target ECU is not online or the response time of the target ECU does not meet the required response time corresponding to the fault diagnosis request; wherein the retransmission strategy is to retransmit the fault diagnosis request.

[0170] In one embodiment, the first determining unit is specifically configured to: determine the target sending strategy as a low-load sending strategy when the service priority is first priority; and determine the target sending strategy as an idle sending strategy when the service priority is second priority; wherein the second priority is lower than the first priority; wherein the low-load sending strategy is to send a fault diagnosis request when the load in the link corresponding to the target ECU is lower than the load threshold; and the idle sending strategy is to send a fault diagnosis request when the link corresponding to the target ECU is in an idle state.

[0171] In one embodiment, the first sending module 940 includes: a first acquisition unit, configured to acquire communication reference data; wherein the communication reference data includes at least one of the following: the data volume of the fault diagnosis request, the diagnostic service type, and the link load status corresponding to the target ECU; a third determination unit, configured to determine the target communication method corresponding to the target ECU based on the communication capability of the target ECU and the communication reference data; and a first sending unit, configured to send the fault diagnosis request to the target ECU according to the target communication method.

[0172] In one embodiment, the fault diagnosis device further includes: a second acquisition module, used to acquire the transmission result of the fault diagnosis request and the response time of the target ECU; and a second transmission module, used to send the fault diagnosis request to the proxy execution unit when the transmission result indicates that the fault diagnosis request transmission failed or the response time exceeds a preset time, so that the proxy execution unit responds to the fault diagnosis request and feeds back proxy response data.

[0173] In one embodiment, when the diagnostic service type of the fault diagnosis request is a first service type, the proxy response data includes marking information that marks the fault diagnosis request as pending execution; when the diagnostic service type of the fault diagnosis request is a second service type, the proxy response data includes the fault diagnosis result obtained by performing fault diagnosis on the target device based on the fault diagnosis request; wherein, the service importance of the second service type is lower than that of the first service type.

[0174] In one embodiment, the first determining module 920 includes: a second obtaining unit, used to obtain the target logical address carried in the fault diagnosis request; and a fourth determining unit, used to determine the target ECU that matches the fault diagnosis request based on the target logical address and the ECUs corresponding to each preset logical address.

[0175] In one embodiment, the fault diagnosis device further includes: a third acquisition module, used to acquire the diagnostic service type and source information of the fault diagnosis request; a receiving module, used to receive the fault diagnosis result fed back by the target ECU in response to the fault diagnosis request; and a feedback module, used to encapsulate the fault diagnosis result and feed back the encapsulated fault diagnosis result to the source end indicated by the source information.

[0176] Each module in the aforementioned fault diagnosis device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0177] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 10 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores data such as fault diagnosis requests, target transmission strategies, communication reference data, and agent response data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a fault diagnosis method.

[0178] Those skilled in the art will understand that Figure 10 The structure shown is a block diagram of a partial structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0179] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0180] In one exemplary embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above-described method embodiments.

[0181] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0182] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program mentioned can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0183] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0184] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A fault diagnosis method, characterized in that, The method includes: Obtain a fault diagnosis request for the target device; Identify the target electronic control unit (ECU) that matches the fault diagnosis request; Based on the communication capabilities of the target ECU, determine the target sending strategy corresponding to the fault diagnosis request; In response to the target transmission strategy, the fault diagnosis request is sent to the target ECU, so that the target ECU responds to the fault diagnosis request and performs fault diagnosis on the target device.

2. The method according to claim 1, characterized in that, The communication capabilities include online status and response time; Based on the communication capabilities of the target ECU, determine the target transmission strategy corresponding to the fault diagnosis request, including: When the target ECU is online and the response time of the target ECU meets the required response time for the fault diagnosis request, the target sending strategy is determined based on the service priority of the fault diagnosis request and the link load of the target ECU. If the target ECU is not online or the response time of the target ECU does not meet the required response time for the fault diagnosis request, the target sending strategy is determined to be a resending strategy. The resending strategy is to resend the fault diagnosis request.

3. The method according to claim 2, characterized in that, The step of determining the target transmission strategy based on the service priority of the fault diagnosis request and the link load status corresponding to the target ECU includes: If the service priority is the first priority, the target sending strategy is determined to be a low-load sending strategy. When the service priority is the second priority, the target sending strategy is determined to be an idle sending strategy; wherein the second priority is lower than the first priority; The low-load sending strategy involves sending the fault diagnosis request when the load on the link corresponding to the target ECU is below a load threshold; the idle sending strategy involves sending the fault diagnosis request when the link corresponding to the target ECU is in an idle state.

4. The method according to claim 1, characterized in that, Sending the fault diagnosis request to the target ECU includes: Obtain communication reference data; wherein, the communication reference data includes at least one of the following: the data volume of the fault diagnosis request, the diagnostic service type, and the link load status corresponding to the target ECU; Based on the communication capabilities of the target ECU and the communication reference data, the target communication method corresponding to the target ECU is determined; The fault diagnosis request is sent to the target ECU according to the target communication method.

5. The method according to claim 1, characterized in that, After sending the fault diagnosis request to the target ECU, the method further includes: Obtain the sending result of the fault diagnosis request and the response time of the target ECU; If the sending result indicates that the fault diagnosis request failed to be sent, or if the response time exceeds the preset time, the fault diagnosis request will be sent to the proxy execution unit so that the proxy execution unit can respond to the fault diagnosis request and provide proxy response data.

6. The method according to claim 5, characterized in that, include: When the diagnostic service type of the fault diagnosis request is the first service type, the proxy response data includes marking information that marks the fault diagnosis request as pending execution. When the diagnostic service type of the fault diagnosis request is the second service type, the proxy response data includes the fault diagnosis result obtained by performing fault diagnosis on the target device based on the fault diagnosis request; The importance of the second service type is lower than that of the first service type.

7. The method according to claim 1, characterized in that, Determining the target electronic control unit (ECU) that matches the fault diagnosis request includes: Obtain the target logical address carried in the fault diagnosis request; Based on the target logical address and the ECUs corresponding to each preset logical address, determine the target ECU that matches the fault diagnosis request.

8. The method according to claim 1, characterized in that, The method further includes: Obtain the diagnostic service type and source information of the fault diagnosis request; Receive the fault diagnosis result fed back by the target ECU in response to the fault diagnosis request; The fault diagnosis results are encapsulated, and the encapsulated fault diagnosis results are fed back to the source end indicated by the source information.

9. A fault diagnosis device, characterized in that, The device includes: The first acquisition module is used to acquire fault diagnosis requests for the target device; The first determining module is used to determine the target ECU that matches the fault diagnosis request; The second determining module is used to determine the target sending strategy corresponding to the fault diagnosis request based on the communication capability of the target ECU. The first sending module is configured to send the fault diagnosis request to the target ECU in response to the target sending strategy, so that the target ECU responds to the fault diagnosis request and performs fault diagnosis on the target device.

10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 8.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 8.

Images