Method and device for intelligently diagnosing faults, electronic equipment and readable storage medium

Abstract

The application relates to the technical field of network fault diagnosis, and provides a method and device for intelligently diagnosing faults, an electronic device and a readable storage medium. The method comprises the following steps: listening to each message endpoint on a service link to determine the execution state of each action instruction as an execution completion state, an unexecuted state or an execution failure state; the service link is a service link for message transmission between each message endpoint; the message endpoint comprises a cloud server, a message middleware and a vehicle end; the action instruction is used for executing corresponding actions on the message endpoint based on the service link; based on a fault corresponding relationship, the fault causes corresponding to each action instruction in the unexecuted state or the execution failure state are diagnosed; and a service link diagnosis result corresponding to the current service link is generated according to all the action instructions and the corresponding fault causes. The method for intelligently diagnosing faults provided by the application can discover faults in the first time, can save time cost and labor cost, and can improve the efficiency of fault processing.

Description

Technical Field

[0001] This application relates to the field of network fault diagnosis technology, and in particular to a method, apparatus, electronic device and readable storage medium for intelligent fault diagnosis. Background Technology

[0002] In existing technologies, service failures are prone to occur when using remote control functions of the Internet of Vehicles (IoV). The following analytical methods can be used to troubleshoot these failures:

[0003] Collecting server logs, which include summaries of logs from various distributed servers, allows for the extraction of valuable information based on the time period of the failure, enabling analysis of potential anomalies and troubleshooting. However, this method has the drawbacks of increasing time and manpower costs.

[0004] Using open-source plugins to monitor and analyze server metrics, including CPU (Central Processing Unit) memory usage and thread count, for troubleshooting has the drawback of not being able to quickly respond to problems and thus failing to discover common faults.

[0005] Troubleshooting service middleware faults, such as the operation of message middleware, database and other components, has the drawback of making it difficult to locate the specific fault node. The fault node includes the terminal, microservice, message middleware or performance.

[0006] Having testers re-trigger the service chain in the production environment to try to reproduce the fault and troubleshoot the problem has the drawback of relying too much on experienced data personnel. Summary of the Invention

[0007] In view of this, embodiments of this application provide a method, apparatus, electronic device, and readable storage medium for intelligent fault diagnosis, in order to solve the problem that fault diagnosis in the prior art requires a large amount of manpower and time costs.

[0008] A first aspect of this application provides a method for intelligent fault diagnosis, comprising:

[0009] Monitor each message endpoint on the service link to determine the execution status of each action command as completed, not executed, or failed. The service link is a service link for message transmission between message endpoints, including cloud servers, message middleware, and vehicle terminals. Action commands are used to perform corresponding actions on message endpoints based on the service link.

[0010] Based on the fault correspondence, diagnose the fault causes corresponding to each action instruction that is in an inactive or failed execution state;

[0011] Based on all action commands and their corresponding fault causes, generate the service link diagnostic results for the current service link.

[0012] A second aspect of this application provides an intelligent fault diagnosis apparatus, comprising:

[0013] The monitoring module is configured to monitor each message endpoint on the service link to determine the execution status of each action command as completed, not executed, or failed. The service link is a service link for message transmission between message endpoints, including cloud servers, message middleware, and vehicle terminals. Action commands are used to perform corresponding actions on message endpoints based on the service link.

[0014] The diagnostic module is configured to diagnose the causes of failures for each action instruction that is in a non-executed or failed execution state based on the fault correspondence.

[0015] The generation module is configured to generate service link diagnostic results for the current service link based on all action instructions and their corresponding fault causes.

[0016] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method.

[0017] A fourth aspect of this application provides a readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0018] The beneficial effects of this application embodiment compared with the prior art are as follows: This application embodiment can monitor the execution status of the action instructions corresponding to each message endpoint on the service link. If the execution status of the action instruction is incomplete or failed, it can perform diagnosis according to the fault correspondence, determine the cause of the action instruction failure, and generate the service link diagnosis result corresponding to the current service link. This enables the fault to be detected as soon as a remote service fails, efficiently analyze the cause of the fault, and locate the action instructions in the incomplete or failed state, saving time and manpower costs. It also makes it easier to view the action instructions in the incomplete or failed state and the cause of the fault, thus improving the efficiency of fault handling. Attached Figure Description

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

[0020] Figure 1 This is a schematic diagram illustrating one application scenario of this application.

[0021] Figure 2 This is a schematic flowchart of an intelligent fault diagnosis method provided in an embodiment of this application;

[0022] Figure 3 This is a visual schematic diagram of an intelligent fault diagnosis method provided in an embodiment of this application;

[0023] Figure 4 This is a visual schematic diagram of another intelligent fault diagnosis method provided in the embodiments of this application;

[0024] Figure 5 This is a schematic diagram of an intelligent fault diagnosis device provided in an embodiment of this application;

[0025] Figure 6 This is a schematic diagram of the electronic device provided in the embodiments of this application. Detailed Implementation

[0026] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0027] The following will describe in detail, with reference to the accompanying drawings, a method and apparatus for intelligent fault diagnosis according to embodiments of this application.

[0028] Figure 1 This is a schematic diagram of an application scenario according to an embodiment of this application. The application scenario may include a first terminal device 101, a second terminal device 102 and a third terminal device 103, a server 104 and a network 105.

[0029] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be hardware or software. When the first terminal device 101, the second terminal device 102, and the third terminal device 103 are hardware, they can be various electronic devices with displays and supporting communication with the server 104, including but not limited to smartphones, tablets, laptops, in-vehicle computers, vehicle controllers, and desktop computers. When the first terminal device 101, the second terminal device 102, and the third terminal device 103 are software, they can be installed in the electronic devices described above. The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be implemented as multiple software programs or software modules, or as a single software program or software module; this application embodiment does not impose any limitations on this. Furthermore, various applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as data processing applications, instant messaging tools, social platform software, search applications, shopping applications, etc.

[0030] Server 104 can be a server that provides various services, such as a backend server that receives requests sent by terminal devices with which it has established communication connections. This backend server can receive and analyze the requests sent by the terminal devices and generate processing results. Server 104 can be a single server, a server cluster consisting of several servers, or a cloud computing service center. This application embodiment does not limit this.

[0031] It should be noted that the server 104 can be either hardware or software. When the server 104 is hardware, it can be various electronic devices that provide various services to the first terminal device 101, the second terminal device 102, and the third terminal device 103. When the server 104 is software, it can be multiple software programs or software modules that provide various services to the first terminal device 101, the second terminal device 102, and the third terminal device 103, or it can be a single software program or software module that provides various services to the first terminal device 101, the second terminal device 102, and the third terminal device 103. This application embodiment does not impose any limitations on this.

[0032] Network 105 can be a wired network using coaxial cable, twisted pair, and fiber optic connection, or it can be a wireless network that enables interconnection of various communication devices without wiring, such as Bluetooth, Near Field Communication (NFC), and Infrared. This application embodiment does not limit this.

[0033] It should be noted that the specific types, quantities and combinations of the first terminal device 101, the second terminal device 102, the third terminal device 103, the server 104 and the network 105 can be adjusted according to the actual needs of the application scenario, and this application embodiment does not limit this.

[0034] Figure 2 This is a schematic flowchart of an intelligent fault diagnosis method provided in an embodiment of this application, such as... Figure 2 As shown, the intelligent fault diagnosis method includes the following steps:

[0035] S201, listen to each message endpoint on the service link to determine the execution status of each action instruction as completed, not executed, or failed.

[0036] S202, based on the fault correspondence, diagnose the fault causes corresponding to each action instruction that is in an inactive or failed execution state;

[0037] S203, Based on all action commands and their corresponding fault causes, generate the service link diagnostic results corresponding to the current service link.

[0038] Among them, the service link is the service link for message transmission between various message endpoints. The message endpoints include cloud servers, message middleware, and vehicle terminals. The action instructions are used to perform corresponding actions on the message endpoints based on the service link.

[0039] Figure 2 The service link in the intelligent fault diagnosis method can be Figure 1 The service link between terminal devices and servers when transmitting messages can be a server, message middleware, or terminal device. The action instructions execute corresponding actions on the server, message middleware, and terminal device according to the service link.

[0040] Action instructions execute corresponding actions on each message endpoint based on the service link. By monitoring each message endpoint on the service link, the execution status of each action instruction can be determined. The execution status includes execution completed, non-executed, or execution failed. Execution completed means that the message transmission between message endpoints was successfully completed according to the action instruction. Non-executed means that the action instruction failed to transmit the message to the next message endpoint and has not started executing the instruction. Execution failed means that the action instruction started transmitting the message between message endpoints, but the message transmission failed.

[0041] Each action command in the non-executed or failed execution state has a corresponding fault relationship. The action commands in the non-executed or failed execution state are diagnosed according to the fault relationship to obtain the fault cause corresponding to the action command. Based on all action commands in the current service link and the fault cause obtained from the diagnosis, the service link diagnosis result corresponding to the current service link is generated.

[0042] According to the technical solution provided in the embodiments of this application, when a failure occurs in the Internet of Vehicles, especially in functions such as remote control, the fault can be detected in the first time, the cause of the fault can be analyzed efficiently, and the faulty action command can be located. This eliminates the need to extract valuable information from the fault time period in the server log and analyze possible abnormal scenarios, which may lead to the inability to quickly and accurately locate the action command in the non-execution state or the execution failure state. This saves time and manpower costs and improves the efficiency of fault handling.

[0043] In some embodiments, monitoring each message endpoint on the service link to determine the execution status of each action instruction as completed, not executed, or failed includes:

[0044] Listen to each message endpoint on the service chain;

[0045] If the message endpoint does not receive the request corresponding to the action instruction, the execution status of the action instruction is determined to be in the non-execution state.

[0046] If the message endpoint has received the request corresponding to the action instruction, and the action corresponding to the action instruction has failed, then the execution status of the action instruction is determined to be an execution failure status.

[0047] If the message endpoint has received the request corresponding to the action instruction, and the action corresponding to the action instruction has been completed, then the execution status of the action instruction is determined to be the execution completed status.

[0048] Listen to each message endpoint on the current service connection, and determine the execution status of the action command based on whether each message endpoint has received the request corresponding to the action command. The determination method is as follows:

[0049] If the message endpoint does not receive the request corresponding to the action instruction, the execution status of the action instruction is determined to be in the non-execution state.

[0050] If the message endpoint has received the request corresponding to the action instruction, and the action corresponding to the action instruction has failed, then the execution status of the action instruction is determined to be an execution failure status.

[0051] If the message endpoint has received the request corresponding to the action instruction, and the action corresponding to the action instruction has been completed, then the execution status of the action instruction is determined to be the execution completed status.

[0052] Table 1 shows that the current service link includes seven action commands: the cloud server performs initialization, the cloud server sends a wake-up command to the vehicle, the cloud server receives a login command from the vehicle, the cloud server sends a remote service command to the message middleware, the cloud server obtains the vehicle's response from the message middleware, the cloud server processes the corresponding action of the vehicle's response, and the cloud server provides feedback information. The first column of Table 1 is the action command name, the second column is the execution status, and the third column is the fault cause for the corresponding action command. The fault cause refers to the possible causes of failure for each action command under different execution statuses.

[0053] Table 1 Fault Correspondence

[0054]

[0055] MQTT is a message middleware. In the service link involved in this application embodiment, messages from the cloud server are transmitted to the vehicle via the message middleware, and messages from the vehicle are transmitted to the cloud server via the message middleware. In this embodiment, the vehicle refers to the TBOX installed in the vehicle and located in the service link. The TBOX is connected to the vehicle's backend system. The service link can obtain information from the vehicle's backend system through the TBOX and control some functions of the vehicle.

[0056] According to the technical solution provided in the embodiments of this application, by monitoring the execution status of the action instruction corresponding to the message endpoint, the faulty action instruction can be directly located when the action instruction fails, thereby improving the efficiency of fault handling.

[0057] In some embodiments, monitoring each message endpoint on the service link to determine the execution status of each action instruction as completed, not executed, or failed includes:

[0058] Based on the execution order of each action command, monitor each message endpoint on the service link to determine the execution status of each action command as completed, not executed, or failed.

[0059] The action instructions arranged in execution order include:

[0060] The cloud server receives the action instructions requested;

[0061] Instructions for initializing the cloud server;

[0062] The action command sent by the cloud server to the vehicle to wake up the user;

[0063] The cloud server receives the login command sent by the vehicle terminal.

[0064] The cloud server sends an action command to the message middleware to send a remote service instruction.

[0065] The cloud server obtains the vehicle's response to the action instructions from the message middleware.

[0066] The cloud server processes the corresponding action instructions from the vehicle's response;

[0067] Action commands that receive feedback information from the cloud server.

[0068] When each action instruction is transmitted via the service link, it is executed in the order of execution, while monitoring each message endpoint on the service link to determine the execution status of each action instruction.

[0069] The vehicle-to-everything (V2X) service is deployed in a public cloud. The service chain mainly relies on the underlying infrastructure, message middleware, and middleware database provided by the public cloud. The vehicle-side TBOX integrates a smart card from a communication operator to wake up the TBOX for remote services. The cloud server and the vehicle communicate via messages based on the MQTT protocol. Based on the above, this application defines a general service chain, message endpoints, and corresponding service instructions for the message endpoints. The action instructions are defined in the following order of execution:

[0070] The cloud server receives the requested action command: For example, if a user triggers a remote vehicle control action command through a terminal device application, the action command is sent to the cloud server via the Hypertext Transfer Protocol (HTTP). When the cloud server receives the HTTP request, it means that the action command has been completed.

[0071] The cloud server performs the initialization action command: The cloud server needs to verify the received data to check its legality, such as verifying the legality of user identity information and vehicle-human binding relationship data. Based on the vehicle-cloud protocol that TBOX can recognize, it assembles service command messages. When the verification and recognition are completed, it means that the action command is in the execution completed state.

[0072] The action command for the cloud server to send a wake-up command to the vehicle: The cloud server determines whether the TBOX is online. If it is not online, it sends a wake-up command, such as sending a TBOX wake-up SMS through the operator's application programming interface (API). When the operator reports the sending result, it means that the action command has been completed.

[0073] The cloud server receives the login command sent by the vehicle terminal. After the TBOX is woken up, it performs the login service. When the cloud server receives the login message from the TBOX, it means that the action command has been completed.

[0074] The cloud server sends an action command to send a remote service instruction to the message middleware: The cloud server processes the TBOX login request and determines whether there is a remote service instruction to be sent. When the cloud server successfully sends the remote service to the message middleware MQTT, it means that the action command has been completed.

[0075] The cloud server obtains the vehicle's response to the message middleware's action instructions: the vehicle's TBOX consumes messages in the MQTT and sends the execution result to the MQTT. The cloud server consumes the response message in the MQTT. When the TBOX response message is successfully obtained, it means that the action instruction has been completed.

[0076] The cloud server processes the corresponding action instructions of the vehicle-side response: After the cloud server obtains the TBOX response, it processes it according to the corresponding business logic. When the corresponding business process is completed, it means that the action instruction is in the execution completed state.

[0077] Action instructions fed back by the cloud server: The cloud server will feed back the results of the action instructions of the remote service to the user. The feedback method is, for example, to push the information to the user's terminal device application through the operator. When the push is successful, it means that the action instruction has been completed.

[0078] According to the technical solution provided in the embodiments of this application, general message endpoints and action instructions can be defined and sorted according to the execution order, thereby enabling this application to improve the versatility of message endpoints corresponding to all service links, making it easier for relevant technical personnel to locate faults, and presenting the service link diagnosis results in an orderly manner according to the execution order, which can present the service link diagnosis results more intuitively.

[0079] In some embodiments, monitoring each message endpoint on the service link to determine the execution status of each action instruction as completed, not executed, or failed, further includes:

[0080] Monitor the execution time of each message endpoint to execute the corresponding action instructions in the execution order.

[0081] When each message endpoint executes the corresponding action instruction in the execution order, the execution time of the action instruction is monitored and recorded in the service link diagnostic results.

[0082] According to the technical solution provided in the embodiments of this application, it is possible to monitor the execution time of the action instructions corresponding to each message endpoint, thereby reducing the cost of manually screening the time of fault occurrence, saving manpower and time costs, and improving diagnostic efficiency.

[0083] In some embodiments, based on the execution order of each action instruction, monitoring each message endpoint on the service link to determine the execution status of each action instruction as completed, not executed, or failed, further includes:

[0084] When the execution status of the current action instruction is determined to be an execution failure status, the current service link is terminated.

[0085] The execution status of the action instruction that follows the current action instruction in the execution sequence is determined to be in an unexecuted state.

[0086] In an exemplary embodiment of this application, an example is given where the current action instruction is an action instruction sent by the cloud server to send a remote service instruction to the message middleware, and the status of the current action instruction is detected as an execution failure state.

[0087] The action instructions corresponding to each message endpoint are executed in the order of execution. The action instructions for the cloud server to receive requests, the cloud server to initialize, the cloud server to send wake-up instructions to the vehicle, and the cloud server to receive login instructions from the vehicle are executed before the current action instruction. The execution status of the above action instructions is "execution completed," while the execution status of the current action instruction is "execution failed." The current action instruction is taken as the end point of this service link to terminate the current service link. Following the current action instruction in the execution order are: the action instruction for the cloud server to obtain the vehicle's response to the message middleware, the action instruction for the cloud server to process the corresponding action of the vehicle's response, and the action instruction for the cloud server to provide feedback information. The execution status of the above action instructions is determined to be "not executed."

[0088] According to the technical solution provided in the embodiments of this application, the execution status of the action instructions corresponding to each message endpoint in the service link can be accurately and completely recorded, thereby enabling more accurate recording of service link diagnostic results.

[0089] In some embodiments, it also includes:

[0090] Obtain the visualization parameters corresponding to each execution state;

[0091] Based on the current service link diagnostic results and visualization parameters, the visualization results corresponding to the current service link diagnostic results are generated. The visualization results include each action command, the execution status of each action command, the cause of the failure and the execution time. The execution time of the action command in the non-executed state is the execution time of the action command in the failed state.

[0092] Visualization parameters are pre-configured for action commands in different execution states. Different visualization parameters can be configured for action commands in different execution states, which makes the visualization results of the service chain more intuitive.

[0093] Figure 3 This is a visual schematic diagram of an intelligent fault diagnosis method provided in an embodiment of this application, such as... Figure 3 As shown, all action commands are in a successful execution state. Taking the solid line frame as an example, which represents the visualization parameters corresponding to the action command in a successful execution state, the visualization result corresponding to the current service link diagnosis result is generated. Below the name of the action command is the execution time of the action command.

[0094] Figure 4 This is a visual schematic diagram of another intelligent fault diagnosis method provided in the embodiments of this application, such as... Figure 4 As shown, different wireframes are used as different visualization parameters to generate visualization results of action instructions in different execution states. Based on the current service link diagnostic results and visualization parameters, the visualization results corresponding to the current service link diagnostic results are generated. Specifically, solid wireframes represent visualization parameters for action instructions in a successful execution state, thick dashed wireframes represent visualization parameters for action instructions in a failed execution state, and thin dashed wireframes represent visualization parameters for action instructions in a non-executed state. Figure 4 It can be seen that the action command of the cloud server receiving the login command sent by the vehicle terminal is in a failed execution state. The corresponding fault cause is marked in the visualized service link diagnosis result. The action command before this action command is in a successful execution state, and the action command after this action command is in a failed execution state.

[0095] Below the name of the action instruction is its execution time. The execution time of action instructions in the unexecuted state is the execution time of action instructions in the service link that were either successfully executed or failed. If the service link is interrupted, the execution time of the successfully executed action instructions in the service link, executed in the order of execution, will be used as the execution time of all unexecuted action instructions. If there are action instructions in the service link that failed, the execution time of the failed action instructions will be used as the execution time of all unexecuted action instructions.

[0096] The visualization results can also include parameters such as vehicle identity information and vehicle response error codes.

[0097] According to the technical solution provided in the embodiments of this application, the service link diagnosis results can be clearly presented through visualization methods, which facilitates intuitive viewing of the service link diagnosis results and improves the efficiency of fault handling.

[0098] In some embodiments, generating the service link diagnostic result corresponding to the current service link further includes:

[0099] Based on the service link diagnostic results and visualization results, a service link diagnostic report is generated;

[0100] Send the service link diagnostic report to the target terminal.

[0101] Each service link diagnostic result corresponds to a visualization result. The diagnostic results and visualization results are matched one-to-one and arranged together to generate a service link diagnostic report. The service link diagnostic report can be sent to the target terminal via email or message notification. Alternatively, the target terminal can be configured to display the service link diagnostic report in real time, allowing developers to intuitively view actions and instructions in a non-executed or executed state, as well as the causes of failures, enabling them to detect faults immediately and improve fault handling efficiency.

[0102] In an exemplary embodiment of this application, each action instruction has different fault causes and message endpoints in different execution states, especially in the non-execution state and the execution failure state.

[0103] The fault types are divided into network faults, data faults, interface faults, and vehicle-side faults. Network faults include failures in the network connection between message endpoints, resulting in the inability to transmit data information. Data faults include errors in the transmitted data. Interface faults include abnormalities in the operator's API. Vehicle-side faults include faults that occur when the TBOX executes action commands.

[0104] Table 2 shows that the current service link includes 7 action instructions. The corresponding action instructions are: the action instruction for cloud server initialization, the action instruction for cloud server to send wake-up instruction to vehicle, the action instruction for cloud server to receive login instruction sent by vehicle, the action instruction for cloud server to send remote service instruction to message middleware, the action instruction for cloud server to obtain vehicle response to message middleware, the action instruction for cloud server to process corresponding action of vehicle response, and the action instruction for cloud server to provide feedback information. The first column of Table 1 is the action instruction name, the second column is the message endpoint, the third column is the execution status, the fourth column is the fault type, and the fifth column is the fault reason of the corresponding action instruction.

[0105] Table 2 shows the causes of failures corresponding to action commands.

[0106]

[0107] According to the technical solution provided in the embodiments of this application, the causes of faults can also be classified in the service link diagnostic report, and the location and cause of the fault can be directly determined according to the execution status of each action instruction, thereby making the service link diagnostic report richer and clearer, and improving diagnostic efficiency and fault handling efficiency.

[0108] All of the above-mentioned optional technical solutions can be combined in any way to form the optional embodiments of this application, and will not be described in detail here.

[0109] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0110] Figure 5 This is a schematic diagram of an intelligent fault diagnosis device provided in an embodiment of this application. Figure 5 As shown, the intelligent fault diagnosis device includes: a monitoring module 501, a diagnosis module 502, and a generation module 503.

[0111] The listening module 501 is configured to listen to each message endpoint on the service link to determine the execution status of each action instruction as completed, not executed, or failed. The service link is a service link for message transmission between each message endpoint, including cloud servers, message middleware, and vehicle terminals. The action instructions are used to perform corresponding actions on the message endpoints based on the service link.

[0112] The diagnostic module 502 is configured to diagnose the fault causes corresponding to each action instruction that is in an inactive or failed state based on the fault correspondence relationship.

[0113] The generation module 503 is configured to generate service link diagnostic results corresponding to the current service link based on all action instructions and their corresponding fault causes.

[0114] In some embodiments, the listening module 501 is configured to listen to each message endpoint on the service link to determine the execution status of each action instruction as completed, not executed, or failed, for the following purposes:

[0115] Listen to each message endpoint on the service chain;

[0116] If the message endpoint does not receive the request corresponding to the action instruction, the execution status of the action instruction is determined to be in the non-execution state.

[0117] If the message endpoint has received the request corresponding to the action instruction, and the action corresponding to the action instruction has failed, then the execution status of the action instruction is determined to be an execution failure status.

[0118] If the message endpoint has received the request corresponding to the action instruction, and the action corresponding to the action instruction has been completed, then the execution status of the action instruction is determined to be the execution completed status.

[0119] In some embodiments, the listening module 501 is configured to listen to each message endpoint on the service link to determine the execution status of each action instruction as completed, not executed, or failed, for the following purposes:

[0120] Based on the execution order of each action command, monitor each message endpoint on the service link to determine the execution status of each action command as completed, not executed, or failed.

[0121] The action instructions arranged in execution order include:

[0122] The cloud server receives the action instructions requested;

[0123] Instructions for initializing the cloud server;

[0124] The action command sent by the cloud server to the vehicle to wake up the user;

[0125] The cloud server receives the login command sent by the vehicle terminal.

[0126] The cloud server sends an action command to the message middleware to send a remote service instruction.

[0127] The cloud server obtains the vehicle's response to the action instructions from the message middleware.

[0128] The cloud server processes the corresponding action instructions from the vehicle's response;

[0129] Action commands that receive feedback information from the cloud server.

[0130] In some embodiments, the listening module 501 is configured to listen to each message endpoint on the service link to determine the execution status of each action instruction as completed, not executed, or failed. It is also used to:

[0131] Monitor the execution time of each message endpoint to execute the corresponding action instructions in the execution order.

[0132] In some embodiments, the listening module 501 is configured to listen to each message endpoint on the service link based on the execution order of each action instruction, in order to determine whether the execution status of each action instruction is a completed state, an unexecuted state, or an executed failure state, and is further configured to:

[0133] When the execution status of the current action instruction is determined to be an execution failure status, the current service link is terminated.

[0134] The execution status of the action instruction that follows the current action instruction in the execution sequence is determined to be in an unexecuted state.

[0135] In some embodiments, the generation module 503 is configured to generate service link diagnostic results corresponding to the current service link, and is further configured to:

[0136] Obtain the visualization parameters corresponding to each execution state;

[0137] Based on the current service link diagnostic results and visualization parameters, the visualization results corresponding to the current service link diagnostic results are generated. The visualization results include each action command, the execution status of each action command, the cause of the failure and the execution time. The execution time of the action command in the non-executed state is the execution time of the action command in the service link that is in the execution successful state or execution failed state.

[0138] In some embodiments, it is also used for:

[0139] Based on the service link diagnostic results and visualization results, a service link diagnostic report is generated;

[0140] Send the service link diagnostic report to the target terminal.

[0141] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0142] Figure 6 This is a schematic diagram of the electronic device 6 provided in an embodiment of this application. Figure 6 As shown, the electronic device 6 of this embodiment includes a processor 601, a memory 602, and a computer program 603 stored in the memory 602 and executable on the processor 601. When the processor 601 executes the computer program 603, it implements the steps in the various method embodiments described above. Alternatively, when the processor 601 executes the computer program 603, it implements the functions of each module / unit in the various device embodiments described above.

[0143] Electronic device 6 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 6 may include, but is not limited to, processor 601 and memory 602. Those skilled in the art will understand that... Figure 6 This is merely an example of electronic device 6 and does not constitute a limitation on electronic device 6. It may include more or fewer components than shown, or different components.

[0144] The processor 601 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0145] The memory 602 can be an internal storage unit of the electronic device 6, such as a hard disk or RAM of the electronic device 6. The memory 602 can also be an external storage device of the electronic device 6, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, Flash Card, etc., equipped on the electronic device 6. The memory 602 can also include both internal and external storage units of the electronic device 6. The memory 602 is used to store computer programs and other programs and data required by the electronic device.

[0146] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0147] If an integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable medium may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in a computer-readable medium can be appropriately added to or subtracted according to the requirements of legislation and patent practice in a jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0148] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for intelligent fault diagnosis in vehicle networking, characterized in that, include: Monitor each message endpoint on the service link to determine the execution status of each action instruction as completed, not executed, or failed. The service link is a service link for message transmission between the message endpoints, and the message endpoints include cloud servers, message middleware, and vehicle terminals. The action instruction is used to perform corresponding actions on the message endpoints based on the service link. Based on the fault correspondence, diagnose the fault causes corresponding to each action instruction that is in the non-execution state or the execution failure state; Based on all the action instructions and the corresponding fault causes, generate the service link diagnosis result corresponding to the current service link; Obtain the visualization parameters corresponding to each of the aforementioned execution states; Based on the current service link diagnostic results and the visualization parameters, a visualization result corresponding to the current service link diagnostic results is generated. The visualization result includes each action instruction, the execution status corresponding to each action instruction, the cause of the failure, and the execution time. The execution time corresponding to the action instruction in the non-executed state is the execution time corresponding to the action instruction in the service link that is in the execution completed state or the execution failed state.

2. The method according to claim 1, characterized in that, Monitor each message endpoint on the service chain to determine the execution status of each action instruction: completed, not executed, or failed. Listen to each message endpoint on the service chain; If the message endpoint does not receive the request corresponding to the action instruction, the execution status of the action instruction is determined to be in the non-execution state. If the message endpoint has received the request corresponding to the action instruction, and the action corresponding to the action instruction has failed, then the execution status of the action instruction is determined to be an execution failure status. If the message endpoint has received the request corresponding to the action instruction, and the action corresponding to the action instruction has been completed, then the execution status of the action instruction is determined to be the execution completion status.

3. The method according to claim 1, characterized in that, Monitor each message endpoint on the service chain to determine the execution status of each action instruction: completed, not executed, or failed. Based on the execution order of each action instruction, monitor each message endpoint on the service link to determine whether the execution status of each action instruction is completed, not executed, or failed. The action instructions arranged in the execution order include: The cloud server receives the requested action instructions; The cloud server performs an initialization command; The action command for the wake-up command sent by the cloud server to the vehicle terminal; The cloud server receives the login command sent by the vehicle terminal as an action command; The cloud server sends a remote service instruction to the message middleware. The cloud server obtains the action command from the vehicle terminal in response to the message middleware; The cloud server processes the action instructions corresponding to the vehicle's response. The action instructions are fed back by the cloud server.

4. The method according to claim 3, characterized in that, The system monitors each message endpoint on the service chain to determine the execution status of each action instruction: completed, not executed, or failed. This also includes: Monitor the execution time of the corresponding action instructions at each of the aforementioned message endpoints in the aforementioned execution order.

5. The method according to claim 3, characterized in that, Based on the execution order of each action instruction, the system monitors each message endpoint on the service link to determine the execution status of each action instruction as completed, not executed, or failed. This also includes: When it is determined that the execution status corresponding to the current action instruction is the execution failure status, the current service link is terminated. The execution state of the action instruction that is following the current action instruction in the execution sequence is determined as the non-executed state.

6. The method according to claim 1, characterized in that, Also includes: Based on the service link diagnostic results and the visualization results, a service link diagnostic report is generated; The service link diagnostic report is sent to the target terminal.

7. A device for intelligent fault diagnosis in vehicle networking, characterized in that, include: The listening module is configured to listen to each message endpoint on the service link to determine the execution status of each action instruction as completed, not executed, or failed. The service link is a service link for message transmission between the message endpoints, and the message endpoints include cloud servers, message middleware, and vehicle terminals. The action instruction is used to perform corresponding actions on the message endpoints based on the service link. The diagnostic module is configured to diagnose the cause of failure for each action instruction that is in the non-executed state or the execution failure state based on the fault correspondence. The generation module is configured to generate a service link diagnostic result corresponding to the current service link based on all the action instructions and the corresponding fault causes. The generation module is further configured to: obtain visualization parameters corresponding to each of the execution states; generate visualization results corresponding to the current service link diagnosis results based on the current service link diagnosis results and the visualization parameters, wherein the visualization results include each of the action instructions, the execution state corresponding to each of the action instructions, the cause of the fault and the execution time, and the execution time corresponding to the action instruction in the non-execution state is the execution time corresponding to the action instruction in the service link that is in the execution completion state or the execution failure state.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 6.

9. A readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 6.

Images