Fault analysis method and device, electronic equipment and storage medium

Abstract

The invention discloses a fault analysis method and device, electronic equipment and a storage medium, and the method comprises the steps: obtaining first burying point information corresponding to an abnormal event if the vehicle detects that the abnormal event of a burying point is triggered, the first burying point information comprises at least one of a subsystem type corresponding to the abnormal event, an application module corresponding to the abnormal event, an abnormal type corresponding to the abnormal event, an information domain corresponding to the abnormal event, a fault identifier corresponding to the abnormal event, an abnormal name corresponding to the abnormal event and an abnormal position corresponding to the abnormal event; and sending the first burying point information to a server, so that the server determines the fault information corresponding to the abnormal event according to the first burying point information, thereby improving the vehicle fault problem determination rate.

Description

Technical Field

[0001] The present application relates to the field of fault analysis, and more specifically, to a fault analysis method, device, electronic device, and storage medium. Background Art

[0002] With the continuous development of the automotive industry, vehicle systems are carrying more and more functions, making the analysis of vehicle failures increasingly difficult. Therefore, in related technologies, there is a challenge in quickly analyzing vehicle failures. Summary of the Invention

[0003] In view of this, embodiments of the present application propose a fault analysis method, device, electronic device, and storage medium to improve the above-mentioned problems.

[0004] In the first aspect, an embodiment of the present application provides a fault analysis method, which includes: if the vehicle detects that a buried point abnormal event is triggered, obtaining first buried point information corresponding to the abnormal event, wherein the first buried point information includes at least one of the subsystem type corresponding to the abnormal event, the application module corresponding to the abnormal event, the abnormal type corresponding to the abnormal event, the information domain corresponding to the abnormal event, the fault identifier corresponding to the abnormal event, the abnormal name corresponding to the abnormal event, and the abnormal location corresponding to the abnormal event; sending the first buried point information to a server so that the server determines the fault information corresponding to the abnormal event based on the first buried point information.

[0005] In the second aspect, an embodiment of the present application provides a fault analysis method, which includes: receiving first burial point information sent by a vehicle, the first burial point information being obtained by the vehicle when detecting that an abnormal event of the burial point is triggered, wherein the first burial point information includes at least one of the subsystem type corresponding to the abnormal event, the application module corresponding to the abnormal event, the abnormal type corresponding to the abnormal event, the information domain corresponding to the abnormal event, the fault identifier corresponding to the abnormal event, the abnormal name corresponding to the abnormal event, and the abnormal position corresponding to the abnormal event; according to the first burial point information, determining the fault information corresponding to the abnormal event.

[0006] In a third aspect, an embodiment of the present application provides a fault analysis device, which includes: a buried point information acquisition module and a buried point information sending module. The buried point information acquisition module is used to obtain the first buried point information corresponding to the abnormal event if the vehicle detects that a buried point abnormal event is triggered, wherein the first buried point information includes at least one of the subsystem type corresponding to the abnormal event, the application module corresponding to the abnormal event, the abnormal type corresponding to the abnormal event, the information domain corresponding to the abnormal event, the fault identifier corresponding to the abnormal event, the abnormal name corresponding to the abnormal event, and the abnormal position corresponding to the abnormal event; the buried point information sending module is used to send the first buried point information to the server, so that the server determines the fault information corresponding to the abnormal event based on the first buried point information.

[0007] In a fourth aspect, an embodiment of the present application provides a fault analysis device, which includes: a buried point information receiving module and a fault information determination module. The buried point information receiving module is used to receive the first buried point information sent by the vehicle, and the first buried point information is obtained by the vehicle when it detects that an abnormal event of the buried point is triggered, wherein the first buried point information includes at least one of the subsystem type corresponding to the abnormal event, the application module corresponding to the abnormal event, the abnormal type corresponding to the abnormal event, the information domain corresponding to the abnormal event, the fault identifier corresponding to the abnormal event, the abnormal name corresponding to the abnormal event, and the abnormal position corresponding to the abnormal event; the fault information determination module is used to determine the fault information corresponding to the abnormal event based on the first buried point information.

[0008] In a fifth aspect, an embodiment of the present application provides an electronic device comprising a memory and a processor, wherein the memory is coupled to the processor, and the memory stores instructions. When the instructions are executed by the processor, the processor executes the fault analysis method provided in the first or second aspect above.

[0009] In a sixth aspect, an embodiment of the present application provides a computer-readable storage medium, in which program code is stored. The program code can be called by a processor to execute the fault analysis method provided in the first or second aspect above.

[0010] In the solution of the present application, if the vehicle detects that a buried point abnormal event is triggered, the first buried point information corresponding to the abnormal event is obtained, including at least one of the subsystem type corresponding to the abnormal event, the application module corresponding to the abnormal event, the abnormal type corresponding to the abnormal event, the information domain corresponding to the abnormal event, the fault identifier corresponding to the abnormal event, the abnormal name corresponding to the abnormal event, and the abnormal position corresponding to the abnormal event, and the first buried point information is sent to the server, so that the server determines the fault information corresponding to the abnormal event based on the first buried point information. In this way, when the vehicle is abnormal, the vehicle's fault problem is determined through the buried point information with a smaller amount of data than the log, which improves the rate of determining the vehicle's fault problem and reduces the amount of data reported by the vehicle. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0012] Figure 1 A schematic diagram of a process flow of a fault analysis method provided by an embodiment of the present application is shown; Figure 2 A schematic diagram showing the format of tracking information provided by an embodiment of the present application; Figure 3 A schematic diagram of the process of reporting tracking information provided by an embodiment of this application is shown; Figure 4 A schematic diagram of a process flow of a fault analysis method provided by an embodiment of the present application is shown; Figure 5 A schematic diagram of a process flow of a fault analysis method provided by an embodiment of the present application is shown; Figure 6 A schematic diagram of a process flow of a fault analysis method provided by an embodiment of the present application is shown; Figure 7 A schematic diagram of a process flow of a fault analysis method provided by an embodiment of the present application is shown; Figure 8 A logical diagram of fault analysis using a target model provided by an embodiment of the present application is shown; Figure 9 A schematic diagram of a process flow of a fault analysis method provided by an embodiment of the present application is shown; Figure 10 A schematic diagram of the process of pushing alarm information provided by an embodiment of the present application is shown; Figure 11 A schematic diagram showing output alarm information provided by an embodiment of the present application is shown; Figure 12 A schematic diagram of a process flow of a fault analysis method provided by an embodiment of the present application is shown; Figure 13 A schematic diagram showing a flow chart of a fault analysis method provided in an embodiment of the present application Figure 14 A partial structural diagram of a target model provided in one embodiment of the present application is shown; Figure 15 A schematic diagram of an interface provided by an embodiment of the present application is shown; Figure 16 A schematic diagram of an abnormal fault tree provided by an embodiment of the present application is shown; Figure 17 A module block diagram of a fault analysis device provided in one embodiment of the present application is shown; Figure 18 A module block diagram of a fault analysis device provided in one embodiment of the present application is shown; Figure 19 A block diagram of an electronic device for executing a fault analysis method according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0013] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application.

[0014] In order to better understand the solutions of the embodiments of the present application, the technical terms used in the embodiments of the present application are explained below.

[0015] The Bluetooth audio transmission model protocol, Advanced Audio Distribution Profile (A2DP), is able to use the chip inside the headset to stack data to achieve high-definition sound.

[0016] FaultCode is a mechanism used in WCF (Windows Communication Foundation) to identify SOAP faults. It allows the service to return a code containing error information when an error occurs.

[0017] FaultcodeID, fault code identifier.

[0018] The following is a detailed description of the implementation details of the technical solution of the embodiment of the present application: As the degree of intelligent integration in car cockpits becomes higher and higher, the probability of vehicle failure is also increasing, and the difficulty of analyzing vehicle failure problems is also increasing. In the related art, the process of locating vehicle failure problems often requires 4S store personnel to invite car owners to return to the store, reproduce the problem phenomenon, capture log analysis, and even arrange for car factory technicians to travel to the site to investigate the problem. However, inviting car owners to return to the 4S store, reproducing the problem and capturing logs for analysis and locating the problem has the problems of difficulty in reproducing the problem, poor timeliness in problem analysis, and high personnel investment costs; in addition, due to the large amount of log data, analyzing the failure problem through log capture will increase the burden on network communication and increase traffic consumption. Therefore, in the related art, vehicle problem failure analysis has problems such as poor effectiveness, high cost of problem investigation, and long vehicle failure processing time.

[0019] To address the above issues, the inventors, after extensive research, have developed the fault analysis method, device, electronic device, and storage medium provided in the embodiments of this application. When a vehicle anomaly occurs, the fault is determined using information from embedded points, which is smaller than the amount of data in logs. This improves the speed of determining vehicle faults and reduces the amount of data reported by the vehicle. The specific fault analysis method is described in detail in the subsequent embodiments.

[0020] The embodiments of the present application will be described below with reference to the accompanying drawings.

[0021] See also Figure 1 , Figure 1 FIG1 shows a flow chart of a fault analysis method provided by an embodiment of the present application. In a specific embodiment, the fault analysis method can be applied to Figure 17 The fault analysis device 200 and the electronic device 100 equipped with the fault analysis device 200 are shown. Figure 19 ). The following will take electronic equipment as an example to illustrate the specific process of this embodiment. Of course, it can be understood that the electronic equipment used in this embodiment can include vehicles, vehicle-mounted terminals and other equipment, which are not limited here. Figure 1 The process shown is described in detail, and the fault analysis method may specifically include the following steps: Step S110: If the vehicle detects that a buried point abnormal event is triggered, the first buried point information corresponding to the abnormal event is obtained, wherein the first buried point information includes at least one of the subsystem type corresponding to the abnormal event, the application module corresponding to the abnormal event, the abnormal type corresponding to the abnormal event, the information domain corresponding to the abnormal event, the fault identifier corresponding to the abnormal event, the abnormal name corresponding to the abnormal event, and the abnormal location corresponding to the abnormal event.

[0022] In this embodiment, the electronic device can be understood as a vehicle, wherein the electronic device may include mechanisms for periodic detection and abnormal interruption detection of functional modules. The electronic device may activate the abnormality detection mechanism when powered on. For example, the vehicle may activate the abnormality detection mechanism when the cockpit host is turned on. The functional modules of the electronic device may include a central control display model, a 360-degree panoramic module, a Bluetooth module, a communication module, and other modules.

[0023] In some embodiments, if the vehicle detects that an abnormal event of a buried point is triggered, the first buried point information corresponding to the abnormal event can be obtained. The abnormal event of the buried point can be triggered by an abnormal interruption of a functional module of the vehicle or an abnormal execution of a function of the functional module. For example, the abnormal event can be triggered by the disconnection of the vehicle's antenna or the failure of the vehicle's Bluetooth A2DP protocol connection, which is not limited here.

[0024] Among them, the first tracking point information corresponding to the abnormal event may include at least one of the vehicle identification code, the subsystem type corresponding to the abnormal event, the application module corresponding to the abnormal event, the abnormal type corresponding to the abnormal event, the information domain corresponding to the abnormal event, the fault identifier corresponding to the abnormal event, the abnormal name corresponding to the abnormal event, the abnormal location corresponding to the abnormal event, the cabin status of the vehicle corresponding to the abnormal event, the abnormal trigger type corresponding to the abnormal event, and the abnormal departure timestamp corresponding to the abnormal time.

[0025] The subsystem type corresponding to the abnormal event may include a vehicle functional module, such as the vehicle's antenna, Bluetooth module, or display screen. The application module corresponding to the abnormal event may include an application of the vehicle's functional module, such as the radio module, communication module, or display module. The abnormality type corresponding to the abnormal event may include an abnormality triggered by the functional module, such as a disconnected communication connection, abnormal temperature, or garbled display. The information field corresponding to the abnormal event may include the type of the functional module, such as the wireless type, hardware type, or display type. The abnormality name corresponding to the abnormal event may include the name of the functional module abnormality, such as a disconnected antenna or a black display screen. The fault identifier corresponding to the abnormal event may include the ID of the abnormal event, which may be unique or randomly named, such as 1234. The abnormal location corresponding to the abnormal event may include the functional module corresponding to the abnormal event, such as the central control display model, the 360-degree panoramic module, or the Bluetooth communication module. The vehicle cabin status corresponding to the abnormal event may include the vehicle's driving status, stopped status, usage of the radio function, usage of the Bluetooth function, or usage of the call function. The abnormal trigger type corresponding to the abnormal event may include how the abnormal event is triggered.

[0026] For example, see Figure 2 , which shows a schematic diagram of the format of the tracking information provided by an embodiment of the present application. Among them, the tracking information corresponding to the abnormal event of the vehicle includes the subsystem type corresponding to the abnormal event, the application module corresponding to the abnormal event, the abnormal type corresponding to the abnormal event, the information field corresponding to the abnormal event, the fault identifier (‌FaultcodeID) corresponding to the abnormal event, the abnormal name corresponding to the abnormal event, the abnormal location ID corresponding to the abnormal event, the abnormal trigger type corresponding to the abnormal event, the abnormal departure timestamp corresponding to the abnormal time, and the vehicle cabin status corresponding to the abnormal event (e.g., cabin status 1, cabin status 2, cabin status...).

[0027] Among them, the first burying point information corresponding to the abnormal event may include at least one status information of the vehicle when the abnormal event is triggered; wherein, the vehicle may include a burying point service, and the burying point service may include an abnormality detection mechanism, a vehicle status information collection mechanism, a burying point information generation mechanism and a burying point information reporting mechanism; accordingly, the vehicle can collect the status information of the vehicle based on the burying point service when it detects that the abnormal event of the burying point is triggered, and generate the first burying point information corresponding to the abnormal event based on the status information for reporting.

[0028] Step S120: Send the first burial point information to the server, so that the server determines the fault information corresponding to the abnormal event according to the first burial point information.

[0029] In some embodiments, the electronic device can be communicatively connected to the server; wherein, after the electronic device obtains the first burial point information corresponding to the abnormal event, the first burial point information can be sent to the server, so that the server determines the fault information corresponding to the abnormal event based on the first burial point information.

[0030] In some embodiments, the electronic device may be pre-set with a buried point reporting logic, such as event-type triggering, which does not count the number of triggers, but reports when there is a trigger, and only reports once before the fault is restored; or event-type triggering, which counts the number of triggers, reports when the number of triggers reaches a preset number, and continues to report before the fault is restored. In this embodiment, the buried point reporting logic is not limited. Among them, the electronic device can send the first buried point information corresponding to the abnormal event to the server when the first buried point information corresponding to the abnormal event is obtained and the triggering situation of the abnormal event is determined to meet the buried point reporting logic, so that the server determines the fault information corresponding to the abnormal event based on the first buried point information.

[0031] Among them, the electronic device can send the first burial point information to the server through wired communication technology (such as serial communication interface, USB interface, etc.), or send the first burial point information to the server through wireless communication technology (such as Bluetooth technology, WiFi technology, zigbee technology, etc.).

[0032] As an implementable method, the electronic device can detect the network signal strength of the vehicle. If it is determined that the network signal strength is greater than the signal threshold, it can be determined that the vehicle is in the presence of a network. Accordingly, the vehicle can send the first buried point information to the server through the network. The electronic device can also store the first buried point information in a preset location when it detects that the network signal strength of the vehicle is not greater than the signal threshold, and report the first buried point information to the server when it detects that the network signal strength of the vehicle is greater than the signal threshold. That is, the electronic device can directly report the buried point information to the server when there is a network. When there is no network, the buried point information will be saved first, and then reported to the server through the network when it is identified that there is a network.

[0033] For example, see Figure 3 , which shows a schematic diagram of the process of reporting buried point information provided by an embodiment of the present application. Among them, the vehicle may include functional modules such as a central control display model, a 360-degree panoramic module, and a Bluetooth communication module. When the vehicle detects that an abnormal event of a buried point of a functional module is triggered, that is, when an abnormal trigger occurs in the functional module, the vehicle can obtain vehicle status information related to the abnormal buried point event, such as module-related status 1, module-related status 2, etc. Among them, the vehicle can automatically generate abnormal buried point information corresponding to the abnormal event based on the obtained vehicle status information, and can detect whether the current network of the vehicle is normal, such as detecting whether the current network signal strength of the vehicle is greater than a signal threshold. If it is greater, it can be determined that the network is normal, and the abnormal buried point information can be reported to the server; if it is less than, it can be determined that the network is abnormal, and the abnormal buried point information can be temporarily stored, and the current network signal strength of the vehicle is continuously detected to be normal until it is detected that the network is normal, and then the temporarily stored abnormal buried point information is reported to the server.

[0034] Among them, it can be understood that in this embodiment, when the burying point triggering conditions are met (when the abnormal event of the burying point is triggered), the vehicle can collect burying point information related to the burying point content (the first burying point information corresponding to the abnormal event) and upload it to the server, so that the server can determine the fault information corresponding to the abnormal event of the vehicle based on the burying point information, thereby performing vehicle fault problem analysis based on the burying point information with less data volume than the log, reducing the load and traffic consumption of the interaction between the server and the vehicle during the fault analysis process, improving the rate of vehicle fault problem analysis, and also improving the user experience.

[0035] A fault analysis method provided in an embodiment of the present application obtains first buried point information corresponding to the abnormal event, including at least one of the subsystem type corresponding to the abnormal event, the application module corresponding to the abnormal event, the abnormal type corresponding to the abnormal event, the information domain corresponding to the abnormal event, the fault identifier corresponding to the abnormal event, the abnormal name corresponding to the abnormal event, and the abnormal position corresponding to the abnormal event, if the vehicle detects that a buried point abnormal event is triggered. The first buried point information is sent to a server, so that the server determines the fault information corresponding to the abnormal event based on the first buried point information. In this way, when the vehicle is abnormal, the vehicle's fault problem is determined through buried point information with a smaller amount of data than the log, thereby improving the rate of determining the vehicle's fault problem and reducing the amount of data reported by the vehicle.

[0036] See also Figure 4 , Figure 4 The flowchart of the fault analysis method provided by an embodiment of the present application is shown. The method is applied to the above electronic equipment. Figure 4 The process shown is described in detail, and the fault analysis method may specifically include the following steps: Step S210: If the vehicle detects that an abnormal event at a buried point is triggered, the faulty system causing the abnormal event is determined.

[0037] In some embodiments, if the vehicle detects that a buried abnormal event is triggered, the fault system that caused the abnormal event can be determined. The fault system may include a functional module where the corresponding abnormal event is triggered, such as a functional module that is detected to have an abnormal interruption during periodic detection and abnormal interruption detection of at least one functional module of the vehicle, thereby determining the functional module as a fault system, and collecting buried information for the functional module to improve the accuracy and efficiency of vehicle fault problem analysis. The number of functional modules included in the fault system that causes the abnormal event can be one or more, which is not limited here.

[0038] Step S220: collecting status information corresponding to the faulty system according to a preset tracking information format.

[0039] In some embodiments, after the electronic device determines the faulty system that caused the abnormal event, it can collect the status information corresponding to the faulty system according to the preset buried point information format. Among them, the preset buried point information format can be understood as the format of abnormal buried point information. For example, please refer to Figure 2 , where the preset embedding information format can be as follows Figure 2As shown. The electronic device can collect the status information corresponding to each functional module included in the fault system based on the preset tracking information format. The status information may include at least one of the timestamp when the functional module generates an abnormal event, the information field corresponding to the functional module, the application module of the functional module, the abnormal type corresponding to the abnormal event, and the cabin state of the vehicle corresponding to when the functional module generates the abnormal event.

[0040] Step S230: Generate the first burial point information according to the status information.

[0041] In some implementations, after the electronic device obtains the status information corresponding to the faulty system, it can generate the first buried point information based on the status information. Specifically, after obtaining the status information, the electronic device can arrange the status information according to a preset buried point information format to obtain the first buried point information. Specifically, after obtaining the status information, the electronic device can also generate a fault identification code corresponding to the abnormal event, and merge the fault identification code and the status information to obtain the first buried point information. Optionally, the electronic device can also fill in the preset buried point information format based on the content of the status information and the fault identification code to obtain the first buried point information.

[0042] Step S240: Send the first burial point information to the server, so that the server determines the fault information corresponding to the abnormal event based on the first burial point information.

[0043] For a detailed description of step S240 , please refer to the above description of step S120 , which will not be repeated here.

[0044] In some embodiments, see Figure 5 , which shows a flow chart of a fault analysis method provided by an embodiment of the present application. After step S240, this embodiment may further include steps S250 to S270. Step S250: If the vehicle detects that the abnormal event of the buried point is triggered again within the preset time period, the second buried point information corresponding to the abnormal event is obtained again.

[0045] In some embodiments, the vehicle may include a mechanism for periodic detection of functional modules and abnormal terminal detection, wherein, when the vehicle detects that an abnormal event has been triggered and collects the first buried point information corresponding to the trigger, it can still continue to monitor the situation in which the buried point abnormal event has been triggered. As an implementable method, the buried point reporting logic included in the vehicle can report the buried point information when an abnormal event is triggered, and continue to report before the fault is restored. Wherein, if the vehicle detects that the abnormal event of the buried point has been triggered again within a preset time period, the second buried point information corresponding to the abnormal event can be obtained again. Wherein, the second buried point information may include at least one of the subsystem type corresponding to the abnormal event corresponding to the abnormal event triggered this time, the application module corresponding to the abnormal event, the abnormal type corresponding to the abnormal event, the information field corresponding to the abnormal event, the fault identifier corresponding to the abnormal event, the abnormal name corresponding to the abnormal event, and the abnormal position corresponding to the abnormal event.

[0046] Step S260: Filter out the content in the second burying point information that is the same as the first burying point information, and obtain the target burying point information corresponding to the abnormal event.

[0047] In some embodiments, after the electronic device obtains the second buried point information corresponding to the abnormal event, it can filter out the content in the second buried point information that is identical to the first buried point information to obtain the target buried point information corresponding to the abnormal event. It is understood that the same abnormal event can be continuously triggered when a vehicle fails and before the failure is recovered. Accordingly, when the abnormal event is continuously triggered, the vehicle can compare the continuously collected buried point information and filter out the identical content that has been reported, thereby reducing the amount of data transmission and improving the speed of vehicle fault analysis while ensuring the real-time nature of the buried point information and the accuracy of vehicle fault problem analysis.

[0048] Step S270: Send the target burial point information to the server.

[0049] In some embodiments, after obtaining the target burial point information, the electronic device can send the target burial point information to the server.

[0050] In some embodiments, see Figure 6 , which shows a flow chart of a fault analysis method provided by an embodiment of the present application. After step S240, this embodiment may further include steps S280 to S290. Step S280: Receive the target instruction sent by the server, wherein the target instruction is sent by the server when the cause of the abnormal event is not analyzed based on the first burial point information.

[0051] In some embodiments, after the vehicle sends the first tracking point information corresponding to the abnormal event to the server, the server may send a target instruction to the vehicle if the cause of the abnormal event has not been analyzed based on the first tracking point information. Accordingly, the vehicle may receive the target instruction sent by the server. The target instruction can be understood as a recall instruction of the vehicle log, which can be used to instruct the vehicle to send the vehicle's log information to the server, so that the server can determine the cause of the abnormal event based on the vehicle's log information, so as to facilitate technicians to propose a vehicle fault handling solution based on the cause, improve the user experience, and improve the safety of the vehicle.

[0052] Among them, the target instruction can carry a specified time period, which can be determined according to the trigger time of the abnormal event. The target instruction can also carry a specified duration. The target instruction can also carry a fault system identifier, so as to obtain the log information within the specified time and the log information of the specified fault system for vehicle fault analysis, thereby improving the speed and accuracy of fault analysis.

[0053] Step S290: In response to the target instruction, the log information of the vehicle is sent to the server, so that the server determines the cause of the abnormal event based on the log information.

[0054] In some embodiments, upon receiving a target instruction, the vehicle can respond to the target instruction by sending its log information to a server, allowing the server to determine the cause of the abnormal event based on the log information. Alternatively, the vehicle can respond to the target instruction by obtaining log information from the vehicle for a specified period of time and sending it to the server, which can then conduct a detailed analysis of the log information to determine the cause of the abnormal event, thereby improving the comprehensiveness of vehicle fault analysis.

[0055] Optionally, the vehicle can respond to the target instruction and send the log information in the vehicle's log information corresponding to the fault system that caused the abnormal event to the server, so as to analyze the cause of the abnormal event for the fault system and improve the rate of fault cause analysis.

[0056] Among them, steps S250 to S270 and steps S280 to S290 are all performed after step S240.

[0057] Compared with the fault analysis method provided in one embodiment of the present application, Figure 1The fault analysis method shown in this embodiment can also determine the fault system that generates the abnormal event; collect status information corresponding to the fault system according to a preset buried point information format; generate first buried point information based on the status information, so as to collect status information for the fault system that generates the abnormal event and the preset buried point information format, and generate buried point information based on the status information of the fault system that generates the abnormal event, thereby improving the rate of obtaining buried point information and improving the rate and accuracy of vehicle fault problem analysis.

[0058] At the same time, after sending the first burying point information to the server, this embodiment can also obtain the second burying point information corresponding to the abnormal event again if the vehicle detects that the abnormal event of the burying point is triggered again within a preset time period; filter out the content in the second burying point information that is identical to the first burying point information, and obtain the target burying point information corresponding to the abnormal event; send the target burying point information to the server, so as to report the burying point information of the abnormal event in real time, and filter the reported content of the burying point information, while ensuring the real-time nature of the burying point information and the accuracy of the vehicle fault problem analysis, reducing the data transmission volume and improving the rate of vehicle fault analysis.

[0059] In addition, this embodiment can also receive a target instruction sent by the server after sending the first buried point information to the server so that the server determines the fault information corresponding to the abnormal event based on the first buried point information, wherein the target instruction is sent by the server when the cause of the abnormal event is not analyzed based on the first buried point information; in response to the target instruction, the log information of the vehicle is sent to the server so that the server determines the cause of the abnormal event based on the log information, so that when the server fails to analyze the cause of the abnormal event based on the first buried point information, the log information is sent to the server in response to the server's log recall task, so that the server analyzes the cause of the vehicle failure problem based on the vehicle's log information, thereby improving the comprehensiveness of the analysis of the vehicle failure problem.

[0060] See also Figure 7 , which shows a flow chart of a fault analysis method provided by an embodiment of the present application. In a specific embodiment, the fault analysis method can be applied to Figure 18 The fault analysis device 300 and the electronic device 100 equipped with the fault analysis device 300 are shown. Figure 19 ). The following will take electronic equipment as an example to illustrate the specific process of this embodiment. Of course, it can be understood that the electronic equipment used in this embodiment can include vehicles, intelligent transportation equipment, vehicle-mounted terminals, computers, servers, cloud servers and other equipment, which are not limited here. Figure 7 The process shown is described in detail, and the fault analysis method may specifically include the following steps: Step S310: Receive the first burial point information sent by the vehicle, wherein the first burial point information is obtained by the vehicle when it detects that an abnormal event of the burial point is triggered, wherein the first burial point information includes at least one of the subsystem type corresponding to the abnormal event, the application module corresponding to the abnormal event, the abnormal type corresponding to the abnormal event, the information domain corresponding to the abnormal event, the fault identifier corresponding to the abnormal event, the abnormal name corresponding to the abnormal event, and the abnormal location corresponding to the abnormal event.

[0061] In this embodiment, the electronic device can be connected to the vehicle for communication, and the vehicle can obtain the first buried point information when it detects that an abnormal event of the buried point is triggered, and send the first buried point information to the electronic device. Accordingly, the electronic device can receive the first buried point information sent by the vehicle. The first buried point information may include at least one of the vehicle identification code of the vehicle, the subsystem type corresponding to the abnormal event, the application module corresponding to the abnormal event, the abnormal type corresponding to the abnormal event, the information domain corresponding to the abnormal event, the fault identifier corresponding to the abnormal event, the abnormal name corresponding to the abnormal event, and the abnormal position corresponding to the abnormal event.

[0062] Step S320: Determine the fault information corresponding to the abnormal event based on the first buried point information.

[0063] In some embodiments, after obtaining the first tracking information sent by the vehicle, the electronic device can determine the fault information corresponding to the abnormal event based on the first tracking information. The fault information corresponding to the abnormal event may include at least one of a fault phenomenon, a fault cause, and a fault repair suggestion. The number of fault phenomena corresponding to the abnormal event may be one or more, the number of fault causes may be one or more, and the number of fault repair suggestions may be one or more, without limitation herein.

[0064] Among them, the electronic device may be pre-set with multiple fault phenomena and phenomenon conditions corresponding to each fault phenomenon, and the electronic device may also be pre-set with multiple fault causes and cause conditions corresponding to each fault cause. Among them, the electronic device may determine, from the preset multiple fault phenomena, the fault phenomenon corresponding to the phenomenon condition whose similarity with the content included in the first buried point information is greater than the preset similarity as the target fault phenomenon; among them, the electronic device may also determine, from the preset multiple fault causes, the fault cause corresponding to the cause condition whose similarity with the content included in the first buried point information is the greatest as the target fault cause, and determine the target fault phenomenon and the target fault cause as the fault information corresponding to the abnormal event.

[0065] Exemplarily, the electronic device may determine a fault phenomenon whose phenomenon conditions among a preset plurality of fault phenomena all appear in the first buried point information as a target fault phenomenon; the electronic device may also determine a fault cause whose cause conditions among a preset plurality of fault causes all appear in the first buried point information as a target fault cause, and may determine the target fault phenomenon and the target fault cause as the fault information corresponding to the abnormal event.

[0066] In some embodiments, a target model may be pre-set in the electronic device. The target model may be created based on multiple fault phenomena, the phenomenon conditions corresponding to each fault phenomenon, multiple fault causes, and the cause conditions corresponding to each fault cause. Optionally, when the electronic device determines the fault information corresponding to the abnormal event based on the first buried point information, the first buried point information may be classified by the target model to obtain a state set corresponding to the abnormal event, and the fault information corresponding to the abnormal event may be determined based on the state set.

[0067] For example, see Figure 8 , which shows a logical diagram of fault analysis performed by a target model provided by an embodiment of the present application. Among them, the first buried point information may include the buried point information corresponding to each abnormal event being triggered when the vehicle detects that the abnormal event of the same buried point is triggered multiple times in succession (such as abnormal buried point 1, abnormal buried point 2, etc.). Among them, the first buried point information serves as an input parameter of the target model. The target model can classify the state information of the first buried point information, obtain the state set corresponding to the abnormal event, and determine the fault phenomenon corresponding to the abnormal event based on the state set. In the process of classifying the status information of the first tracking point information by the target model, the first tracking point information can be functionally classified and analyzed with big data (such as the number of times the abnormal event is triggered to report the tracking point data to the server, the number of times the vehicle reports the tracking point information to the server, the version information of the target model for abnormal event analysis, etc.), and at least one state set (such as state set 1, state set 2, etc.) is obtained, wherein each state set may include at least one related state (such as related state 1, related state 2, etc.); wherein the target model can determine whether the state set has a problem fault phenomenon based on the related states included in each state set, and in the case of a problem fault phenomenon, determine the specific problem fault phenomenon, such as determining problem fault phenomenon 1 based on state set 1, determining problem fault phenomenon 2 based on state set 2, and determining that other state sets do not have a problem fault phenomenon and are non-faults.

[0068] In some embodiments, the fault information may include the cause of the abnormal event, and the electronic device may analyze the cause of the abnormal event based on the first buried point information through the target model. Wherein, if the electronic device obtains the first prompt information output by the target model, the first prompt information may be determined as fault information. Wherein, the first prompt information may include the cause of the abnormal event. Wherein, if the electronic device obtains the second prompt information output by the target model, a target instruction may be sent to the vehicle so that the vehicle responds to the target instruction, feeds back log information, and may receive the log information sent by the vehicle, and may determine the cause of the abnormal event based on the log information, and may determine the cause as fault information. Wherein, the second prompt information can be used to prompt that the target model has not analyzed the cause of the abnormal event.

[0069] In this embodiment, the target model can be understood as a fault analysis model. The input parameter of the fault analysis model is the buried point information. The fault analysis model can analyze the buried point information reported by the vehicle side, determine the fault cause and fault phenomenon corresponding to the vehicle abnormal event, and provide a basis for users to handle vehicle faults, thereby improving the user experience.

[0070] In some embodiments, see Figure 9 , which shows a flow chart of a fault analysis method provided by an embodiment of the present application. After step S320, this embodiment may further include steps S330 to S360. Step S330: Determine the fault phenomenon corresponding to the abnormal event according to the fault information.

[0071] In some embodiments, the fault information may include the fault phenomenon corresponding to the abnormal event. Optionally, after obtaining the fault information, the electronic device may determine the fault phenomenon corresponding to the abnormal event based on the fault information. Examples of the fault phenomenon include, but are not limited to, antenna module failure, Bluetooth module failure, and communication module failure.

[0072] Step S340: determining the level corresponding to the fault phenomenon based on an alarm rule, wherein the alarm rule includes multiple fault phenomena and the level corresponding to each fault phenomenon.

[0073] In some embodiments, the electronic device may be pre-configured with an alarm rule, wherein the alarm rule may include multiple fault phenomena and the corresponding level of each fault phenomenon. The electronic device may determine the level of the fault phenomenon based on whether the fault phenomenon affects the normal driving of the vehicle. For example, the level of a fault phenomenon that affects the normal driving of the vehicle is higher than the level of a fault phenomenon that does not affect the normal driving of the vehicle.

[0074] In some embodiments, the alarm rules may include a preset binding table, which may include mappings between vehicle model code, vehicle VIN code, business domain, alarm name, alarm level, alarm number (push frequency), alarm condition, alarm object (push target), and alarm channel (method). For example, please refer to Table 1, which shows the preset binding table included in the alarm rules provided in an embodiment of this application.

[0075] Table 1 The electronic device may determine, based on the alarm rule, from a plurality of fault phenomena, a level of the same fault phenomenon as the fault phenomenon corresponding to the abnormal event as the level of the fault phenomenon corresponding to the abnormal event.

[0076] Step S350: Determine an alarm method based on the level.

[0077] In some embodiments, an electronic device may be pre-configured with an alarm push rule, wherein the alarm push rule may include multiple alarm modes, multiple levels, and the alarm modes corresponding to each level. Based on the alarm push rule, the electronic device may determine, from among multiple alarm objects, an alarm mode corresponding to the same level as the level corresponding to the abnormal event as the alarm mode corresponding to the abnormal event.

[0078] Step S360: Generate alarm information corresponding to the fault phenomenon, and output the alarm information based on the alarm method.

[0079] In some embodiments, after the electronic device determines the fault phenomenon corresponding to the abnormal event, it may generate an alarm message corresponding to the fault phenomenon. The alarm message may include at least one of the following: the model of the vehicle corresponding to the abnormal event, the name of the fault phenomenon, the time when the abnormal event was triggered, the vehicle identification code of the vehicle corresponding to the abnormal event, and a link to the fault information corresponding to the abnormal event.

[0080] Considering that different users have different concerns about vehicle failures and that different vehicle failures have varying degrees of importance to safe driving, in this embodiment, the alert method may include the method for outputting the alert information (e.g., WeChat, email, SMS, etc.), the recipients of the alert information (e.g., vehicle owners, vehicle manufacturers, developers, 4S dealership after-sales service, etc.), and the frequency of the alert (e.g., once a day, three times a day, etc.). This allows different vehicle failures to be associated with different notification recipients, resulting in different alert frequencies for different vehicle failures. This allows users to receive timely alert information, enabling them to quickly address vehicle failure issues, improving the effectiveness of vehicle failure handling, and enhancing the user experience.

[0081] In some embodiments, the electronic device may output the alarm information based on the alarm mode after determining the alarm information and alarm mode corresponding to the abnormal event. Figure 10 and Figure 11 ,in, Figure 10 The following is a schematic diagram showing a process of pushing alarm information provided by an embodiment of the present application. Figure 11 A schematic diagram of the output alarm information provided by an embodiment of the present application is shown. Among them, the electronic device can generate alarm information of the fault phenomenon corresponding to the abnormal event, and can push the alarm information based on the alarm method (such as corporate WeChat, email, short message, etc.). Among them, the electronic device can send the alarm information (such as the vehicle series corresponding to the abnormal event, event type, fault name, triggering event, vehicle identification code VIN and link to the fault information corresponding to the decision-making abnormal event) to the device (such as the owner's computer, mobile phone, etc.) corresponding to the push object (such as developers, 4S store after-sales, etc.) based on the method of outputting alarm information included in the alarm method (such as email, text message, etc.).

[0082] In some embodiments, see Figure 12 , which shows a flow chart of a fault analysis method provided by an embodiment of the present application. After step S320, this embodiment may further include step S370. Step S370: Displaying an abnormal fault tree corresponding to the target model, wherein the abnormal fault tree is used to represent the decision-making process of the target model in determining the fault information based on the first buried point information.

[0083] In some embodiments, after determining the fault information corresponding to the abnormal event based on the target model, the electronic device may display the abnormal fault tree corresponding to the target model. The abnormal fault tree may be used to characterize the decision-making process of the target model in determining the fault information corresponding to the abnormal event based on the first buried point information. This visualizes the processing process of the first buried point information, making it easier for users to clearly view the vehicle's fault location and detailed fault information, thereby improving the user's efficiency in handling vehicle faults and reducing the difficulty of troubleshooting vehicle faults.

[0084] For example, please refer to Figure 11 、 Figure 13 、 Figure 14 、 Figure 15 as well as Figure 16 .in, Figure 13 A schematic diagram of a fault analysis method according to an embodiment of the present application is shown. Figure 14 FIG. 1 shows a partial structural diagram of a target model provided by an embodiment of the present application. Figure 15 shows a schematic diagram of an interface provided by an embodiment of the present application, Figure 16 A schematic diagram of an abnormal fault tree provided in an embodiment of the present application is shown.

[0085] The fault analysis method of this embodiment can be applied to both the vehicle and the server (cloud). When the cockpit host is activated, the vehicle can activate its own abnormality detection mechanism to detect whether any abnormal event has been triggered. If an abnormal event is detected, vehicle status information is collected based on a preset tracking information format, and first tracking information is generated based on the status information and reported to the server. If no abnormal event is detected, abnormality detection continues.

[0086] The server can receive the first buried point information sent by the vehicle, and perform vehicle fault analysis on the first buried point information based on the target model, such as determining whether the vehicle's cockpit is faulty. If the vehicle cockpit is faulty, the server can determine the fault information corresponding to the fault and output an alarm message based on the fault information. The server can also visualize the abnormal fault tree corresponding to the target model while outputting the alarm information. The server can also analyze the cause of the fault based on the first buried point information through the target model. If the server fails to analyze the cause of the fault through the target model, it can send a log recall task to the vehicle, and the vehicle will respond to the task by feeding back log information to the server, and the server can analyze the cause of the fault based on the log information, and can obtain a solution to the fault after determining the cause of the fault.

[0087] Among them, the application of the fault analysis method provided by the embodiment of the present application is carried out by taking the Bluetooth failure of the vehicle as an example. Among them, the name of the vehicle's Bluetooth module fault tracking point can be: A2DP protocol connection failure. Among them, the software detection condition designed for the tracking point scheme can be: the vehicle is in full-function mode, Bluetooth is turned on and not connected to the A2DP state. Among them, the logic of the vehicle's tracking point detection can be: 1) When connecting to the protocol, the remote end refuses to connect = 1001; 2) When connecting to the protocol, the remote timeout has no response = 1002; 3) Authentication failed during the protocol connection = 1003; 4) When sending a connection instruction to the protocol stack, the protocol stack did not respond to trigger a timeout = 1004. The reporting of tracking point information is triggered when these four events are called back. Among them, the reporting logic of the vehicle's tracking point information can be: event-type triggering, not counting the number of times, reporting when triggered, and only reporting once before the fault is recovered.

[0088] Among them, the vehicle detects that an abnormal event of the buried point is triggered, and the content of the first buried point information corresponding to the abnormal event obtained can be shown in Table 2.

[0089] Table 2 in, Figure 14 The target model in the server is shown as part of the structure. The target model can correspond to an abnormal fault tree, and the abnormal fault tree can correspond to each functional module of the vehicle.

[0090] The electronic device can determine that the vehicle has a fault based on the first buried point information sent by the vehicle, and can determine that the corresponding fault information is (A2DP protocol connection failure). The electronic device can generate alarm information based on the fault phenomenon included in the fault information, and can output the alarm information based on the alarm rules, such as sending it to the developer or the after-sales service of the 4-store. Figure 11 The SMS or email shown will be used to remind you.

[0091] The user can log in to the electronic device system or click on the link in the alarm information to view the fault details; the electronic device can display Figure 15 The electronic device can also display the abnormal fault tree corresponding to the decision process of the target model for determining the fault information based on the first buried point information after obtaining the fault information corresponding to the vehicle, such as Figure 16 shown.

[0092] The electronic device may also output a decision conclusion based on the fault information during the display of the abnormal fault tree, and may display the decision conclusion. The content included in the decision conclusion may be as shown in Table 3.

[0093] Table 3 Among them, it can be understood that in order to solve the problems of long troubleshooting cycle, poor timeliness and high manpower input cost of vehicle fault problems, in this embodiment, when an abnormality is detected, the vehicle automatically reports the abnormal buried point to the cloud. Among them, the technician can log in to the server to directly view the detailed information of the abnormal buried point. Among them, if the detailed information of the buried point is insufficient to determine the cause of the problem, the cloud can issue a log recall task and download the vehicle fault log for secondary analysis, thereby greatly shortening the time to solve the problem and not relying on the user to copy the vehicle log on site for fault problem analysis. In addition, the Internet of Vehicles technology is used to remotely monitor vehicle fault messages in real time, and the fault location and problem analysis cause can be viewed through the cloud-based abnormality visualization system, which helps to quickly respond to and handle vehicle fault problems, improve the efficiency of problem handling, and reduce the difficulty of problem handling.

[0094] Among them, in order to solve the problem that only the fault location information is reported, which makes it impossible to analyze the cause of the fault, this embodiment can report the abnormal point information that can directly obtain the preliminary cause of the abnormality when the vehicle abnormality occurs, providing a direct basis for users to deal with the problem.

[0095] Remote analysis of vehicle failures relies on log collection, which results in high data traffic and interaction load. Furthermore, remote collection of vehicle failure logs requires additional memory to store logs from the time period of the vehicle failure, increasing memory consumption. This embodiment reduces traffic loss by issuing a log recall task on the server to download logs from a specified time period when the cause cannot be initially confirmed based on the detailed information provided by the anomaly tracking point.

[0096] The abnormal fault tracking system is based on a fault tree for each functional module of the vehicle. When an abnormality is triggered, relevant module status information is obtained and a tracking message is automatically generated. This identifies the possible fault phenomenon and the cause of the abnormal phenomenon, eliminating the need for detailed log analysis. Furthermore, the target model uses the tracking messages reported by the vehicle as input parameters to derive the possible fault phenomenon corresponding to the abnormal event and the cause of the abnormal phenomenon. It also assigns a severity level to the abnormal phenomenon, providing a basis for notification to the alarm system and prioritizing user issues. Furthermore, the abnormal problem visualization system displays vehicle issues on the target model, allowing users to clearly identify the specific problem location and review detailed analysis results, reducing the difficulty of vehicle problem troubleshooting and improving the efficiency and convenience of vehicle problem resolution. Furthermore, the vehicle log recall function facilitates secondary problem analysis without the need for users to collect vehicle logs onsite. Logs can also be recalled by configurable time periods, reducing traffic usage in a targeted manner, enabling remote visualization of vehicle faults and improving the speed of vehicle problem resolution.

[0097] Among them, steps S330 to S360, and step S370 are all executed after step S320, wherein steps S330 to S360 can be executed simultaneously with step S370, or can be executed before step S370, which is not limited here.

[0098] A fault analysis method provided by an embodiment of the present application receives first buried point information sent by a vehicle, wherein the first buried point information is obtained by the vehicle when it detects that an abnormal event of the buried point is triggered, wherein the first buried point information includes at least one of the subsystem type corresponding to the abnormal event, the application module corresponding to the abnormal event, the abnormal type corresponding to the abnormal event, the information domain corresponding to the abnormal event, the fault identifier corresponding to the abnormal event, the abnormal name corresponding to the abnormal event, and the abnormal position corresponding to the abnormal event; based on the first buried point information, the fault information corresponding to the abnormal event is determined, so that when the vehicle is abnormal, the vehicle's fault problem is determined through the buried point information with a smaller amount of data than the log, thereby improving the rate of determining the vehicle's fault problem and reducing the amount of data reported by the vehicle.

[0099] In some embodiments, this embodiment can also determine the fault phenomenon corresponding to the abnormal event based on the fault information after determining the fault information corresponding to the abnormal event based on the first tracking point information; determine the level corresponding to the fault phenomenon based on the alarm rule, wherein the alarm rule includes multiple fault phenomena and the level corresponding to each fault phenomenon; determine the alarm object based on the level; determine the alarm method based on the level; generate alarm information corresponding to the fault phenomenon, and output the alarm information based on the alarm method, so as to determine the fault level according to the alarm rule, and automatically push the generated alarm information in a targeted manner, so that the user receives the alarm information in time and quickly handles the fault problem, thereby improving the safety of the vehicle.

[0100] In some embodiments, this embodiment can also display the abnormal fault tree corresponding to the target model after determining the fault information corresponding to the abnormal event based on the first buried point information, wherein the abnormal fault tree is used to characterize the decision-making process of the target model in determining the fault information based on the first buried point information, thereby visually displaying the decision-making process of the target model in determining the fault information based on the first buried point information, making it convenient for users to view the detailed information of the abnormal event to locate the problem, thereby improving the rate of fault analysis.

[0101] See also Figure 17 , Figure 17 The module block diagram of the fault analysis device provided by an embodiment of the present application is shown. The fault analysis device 200 is applied to the above electronic equipment. Figure 17 The process shown in FIG. 1 is described in detail. The fault analysis device 200 includes: a buried point information acquisition module 210 and a buried point information sending module 220, wherein: The tracking point information acquisition module 210 is used to obtain the first tracking point information corresponding to the abnormal event if the vehicle detects that a tracking point abnormal event is triggered, wherein the first tracking point information includes at least one of the subsystem type corresponding to the abnormal event, the application module corresponding to the abnormal event, the abnormal type corresponding to the abnormal event, the information domain corresponding to the abnormal event, the fault identifier corresponding to the abnormal event, the abnormal name corresponding to the abnormal event, and the abnormal position corresponding to the abnormal event.

[0102] The burial point information sending module 220 is used to send the first burial point information to the server, so that the server can determine the fault information corresponding to the abnormal event based on the first burial point information.

[0103] Furthermore, the tracking point information acquisition module 210 may include: a fault system determination unit, a status information collection module, and a tracking point information generation unit, wherein: The fault system determining unit is used to determine the fault system that generates the abnormal event.

[0104] The status information collection module is used to collect the status information corresponding to the fault system according to a preset tracking information format.

[0105] A burial point information generating unit is used to generate the first burial point information according to the status information.

[0106] Furthermore, after sending the first burying point information to the server so that the server determines the fault information corresponding to the abnormal event according to the first burying point information, the fault analysis device 200 may further include: a log recall instruction receiving unit and a log sending unit, wherein: The log recall instruction receiving unit is used to receive the target instruction sent by the server, wherein the target instruction is sent by the server when the cause of the abnormal event is not analyzed based on the first burial point information.

[0107] The log sending unit is used to send the log information of the vehicle to the server in response to the target instruction, so that the server determines the cause of the abnormal event based on the log information.

[0108] Furthermore, after sending the first burying point information to the server, the fault analysis device 200 may further include: a second burying point information acquiring unit, a burying point information filtering unit, and a burying point information sending subunit, wherein: The second buried point information acquisition unit is used to obtain the second buried point information corresponding to the abnormal event again if the vehicle detects that the abnormal event of the buried point is triggered again within a preset time period.

[0109] The burying point information filtering unit is used to filter out the content in the second burying point information that is the same as the first burying point information, and obtain the target burying point information corresponding to the abnormal event.

[0110] The burying point information sending subunit is used to send the target burying point information to the server.

[0111] See also Figure 18 , Figure 18 The module block diagram of the fault analysis device provided by an embodiment of the present application is shown. The fault analysis device 300 is applied to the above electronic equipment. Figure 18 The process shown in FIG. 1 is described in detail. The fault analysis device 300 includes: a buried point information receiving module 310 and a fault information determining module 320, wherein: The tracking point information receiving module 310 is used to receive the first tracking point information sent by the vehicle, wherein the first tracking point information is obtained by the vehicle when an abnormal event of the tracking point is detected to be triggered, wherein the first tracking point information includes at least one of the subsystem type corresponding to the abnormal event, the application module corresponding to the abnormal event, the abnormal type corresponding to the abnormal event, the information domain corresponding to the abnormal event, the fault identifier corresponding to the abnormal event, the abnormal name corresponding to the abnormal event, and the abnormal position corresponding to the abnormal event.

[0112] The fault information determination module 320 is used to determine the fault information corresponding to the abnormal event based on the first burial point information.

[0113] Furthermore, after determining the fault information corresponding to the abnormal event based on the first buried point information, the fault analysis device 300 may further include: a fault phenomenon determination unit, a fault level determination unit, an alarm mode determination unit, and an alarm information output unit, wherein: A fault phenomenon determining unit is used to determine the fault phenomenon corresponding to the abnormal event according to the fault information.

[0114] The fault level determination unit is configured to determine the level corresponding to the fault phenomenon based on an alarm rule, wherein the alarm rule includes multiple fault phenomena and the level corresponding to each fault phenomenon.

[0115] The alarm object determination unit is used to determine the alarm mode based on the level.

[0116] The alarm information output unit is used to generate alarm information corresponding to the fault phenomenon and output the alarm information based on the alarm mode.

[0117] Furthermore, the fault information determination module 320 may include: a state set acquisition unit and a fault information determination subunit, wherein: The state set obtaining unit is used to classify the state information of the first buried point information through the target model to obtain the state set corresponding to the abnormal event.

[0118] The fault information determination subunit is configured to determine the fault information corresponding to the abnormal event according to the state set.

[0119] Furthermore, the fault information includes the cause of the abnormal event. The fault analysis device 300 may further include: a fault cause model analysis unit, a first fault cause determination unit, a log recall instruction sending unit, a log receiving unit, and a second fault cause determination unit, wherein: A fault cause model analysis unit is used to analyze the cause of the abnormal event based on the first buried point information through the target model.

[0120] The first unit for determining the cause of the fault is configured to determine the first prompt information output by the target model as the fault information if the first prompt information is obtained, wherein the first prompt information includes the cause of the abnormal event.

[0121] A log recall instruction sending unit is used to send a target instruction to the vehicle if a second prompt information output by the target model is obtained, so that the vehicle responds to the target instruction and feeds back log information, wherein the second prompt information is used to prompt the target model that the cause of the abnormal event has not been analyzed.

[0122] The log receiving unit is used to receive the log information sent by the vehicle.

[0123] The second fault cause determination unit is configured to determine a cause of the abnormal event according to the log information, and determine the cause as the fault information.

[0124] Furthermore, after determining the fault information corresponding to the abnormal event based on the first buried point information, the fault analysis device 300 may further include: a decision process display unit, wherein: A decision process display unit is used to display the abnormal fault tree corresponding to the target model, wherein the abnormal fault tree is used to represent the decision process of the target model in determining the fault information based on the first buried point information.

[0125] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described devices and modules can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0126] In several embodiments provided in this application, the coupling between modules may be electrical, mechanical or other forms of coupling.

[0127] In addition, the functional modules in the various embodiments of the present application may be integrated into a processing module, or each module may exist physically separately, or two or more modules may be integrated into a single module. The above-mentioned integrated modules may be implemented in the form of hardware or software functional modules.

[0128] See also Figure 19, which shows a structural block diagram of an electronic device provided in an embodiment of the present application. The electronic device 100 can be a device with processing capabilities, such as a vehicle, an on-board terminal, a server, a computer, etc. The electronic device 100 in the present application may include one or more of the following components: a processor 110, a memory 120, and one or more application programs, wherein the one or more application programs can be stored in the memory 120 and configured to be executed by one or more processors 110, and the one or more programs are configured to execute the method described in the aforementioned method embodiment.

[0129] The processor 110 may include one or more processing cores. Using various interfaces and circuits, the processor 110 connects to various components within the vehicle 100. It executes instructions, programs, code sets, or instruction sets stored in the memory 120, as well as accesses data stored in the memory 120, to perform various functions and process data within the vehicle 100. Optionally, the processor 110 may be implemented using at least one of the following hardware forms: a digital signal processing (DSP), a field-programmable gate array (FPGA), or a programmable logic array (PLA). The processor 110 may integrate one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. The CPU primarily processes the operating system, user interface, and application programs; the GPU is responsible for rendering and drawing displayed content; and the modem handles wireless communications. It is understood that the modem may also be implemented independently of the processor 110 via a separate communications chip.

[0130] The memory 120 may include random access memory (RAM) or read-only memory (ROM). The memory 120 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 120 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as a touch function, a sound playback function, an image playback function, etc.), instructions for implementing the various method embodiments described below, and the like. The data storage area may also store data created by the electronic device 100 during use (such as a phone book, audio and video data, and chat history data).

[0131] In this embodiment, a computer-readable medium stores program code, and the program code can be called by a processor to execute the method described in the above method embodiment.

[0132] The computer-readable storage medium may be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. Alternatively, the computer-readable storage medium includes a non-transitory computer-readable storage medium. The computer-readable storage medium has storage space for program code for executing any of the method steps described above. This program code can be read from or written to one or more computer program products. The program code may be compressed, for example, in a suitable format.

[0133] In this application, a plurality refers to two or more.

[0134] In this application, unless otherwise expressly defined, the terms "mounted," "connected," and "connected" should be interpreted broadly. For example, they can refer to fixed, detachable, or integral connections; mechanical or electrical connections; direct or indirect connections through an intermediary; and internal communication between two components. A person of ordinary skill in the art will understand the specific meanings of these terms in this application.

[0135] The terms "first," "second," "third," "fourth," etc. (if any) in this application are used to distinguish similar objects and are not necessarily used to describe a particular sequential order.

[0136] The term "and / or" in this application simply describes an association between related objects, indicating that three possible relationships exist. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " in this application generally indicates that the related objects are in an "or" relationship.

[0137] Unless otherwise specified, all steps of this application may be performed sequentially or randomly. For example, "the method includes steps A and B" means that the method may include steps A and B performed sequentially, or may include steps B and A performed sequentially. For example, "the method may also include step C" means that step C may be added to the method in any order. For example, the method may include steps A, B, and C, or steps A, C, and B, or steps C, A, and B, etc.

[0138] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements and improvements made within the spirit and principles of the present application should be included in the scope of protection of the present application.

Claims

1. A fault analysis method, characterized in that: The method comprises: If the vehicle detects that a buried point abnormal event is triggered, obtain first buried point information corresponding to the abnormal event, wherein the first buried point information includes at least one of the subsystem type corresponding to the abnormal event, the application module corresponding to the abnormal event, the abnormal type corresponding to the abnormal event, the information domain corresponding to the abnormal event, the fault identifier corresponding to the abnormal event, the abnormal name corresponding to the abnormal event, and the abnormal location corresponding to the abnormal event; The first burial point information is sent to a server so that the server determines the fault information corresponding to the abnormal event based on the first burial point information.

2. The method according to claim 1, characterized in that The obtaining of first tracking point information corresponding to the abnormal event includes: determining a faulty system that generates the abnormal event; Collecting status information corresponding to the fault system according to a preset tracking information format; Generate the first burial point information based on the status information.

3. The method according to claim 1 or 2, characterized in that After sending the first burying point information to the server so that the server determines fault information corresponding to the abnormal event according to the first burying point information, the method further includes: receiving a target instruction sent by the server, wherein the target instruction is sent by the server when the server fails to analyze the cause of the abnormal event based on the first tracking information; In response to the target instruction, the log information of the vehicle is sent to the server, so that the server determines the cause of the abnormal event based on the log information.

4. The method according to claim 1 or 2, characterized in that After sending the first burying point information to the server, the method further includes: If the vehicle detects that the abnormal event of the buried point is triggered again within the preset time period, the second buried point information corresponding to the abnormal event is obtained again; Filter out the same content as the first burying point information in the second burying point information to obtain target burying point information corresponding to the abnormal event; The target burial point information is sent to the server.

5. A fault analysis method, characterized in that: The method comprises: Receive first tracking point information sent by a vehicle, where the first tracking point information is obtained by the vehicle when detecting that an abnormal event of the tracking point is triggered, wherein the first tracking point information includes at least one of a subsystem type corresponding to the abnormal event, an application module corresponding to the abnormal event, an abnormality type corresponding to the abnormal event, an information domain corresponding to the abnormal event, a fault identifier corresponding to the abnormal event, an abnormality name corresponding to the abnormal event, and an abnormal location corresponding to the abnormal event; Determine the fault information corresponding to the abnormal event based on the first buried point information.

6. The method according to claim 5, characterized in that After determining the fault information corresponding to the abnormal event according to the first buried point information, the method further includes: determining a fault phenomenon corresponding to the abnormal event according to the fault information; Determining a level corresponding to the fault phenomenon based on an alarm rule, wherein the alarm rule includes multiple fault phenomena and a level corresponding to each fault phenomenon; determining an alarm mode based on the level; Generate alarm information corresponding to the fault phenomenon, and output the alarm information based on the alarm method.

7. The method according to claim 5, characterized in that The determining, based on the first tracking point information, fault information corresponding to the abnormal event includes: Classify the state information of the first buried point information by using the target model to obtain a state set corresponding to the abnormal event; Fault information corresponding to the abnormal event is determined according to the state set.

8. The method according to claim 7, characterized in that The fault information includes a cause of the abnormal event, and the method further includes: Analyzing the cause of the abnormal event based on the first buried point information by using the target model; If first prompt information output by the target model is obtained, determining the first prompt information as the fault information, wherein the first prompt information includes a cause of the abnormal event; or If a second prompt message output by the target model is obtained, a target instruction is sent to the vehicle, so that the vehicle responds to the target instruction and feeds back log information, wherein the second prompt message is used to prompt that the target model has not analyzed the cause of the abnormal event; Receiving log information sent by the vehicle; The cause of the abnormal event is determined according to the log information, and the cause is determined as the fault information.

9. The method according to claim 7, characterized in that After determining the fault information corresponding to the abnormal event according to the first buried point information, the method further includes: An abnormal fault tree corresponding to the target model is displayed, wherein the abnormal fault tree is used to represent a decision-making process of the target model in determining the fault information based on the first buried point information.

10. A fault analysis device, characterized in that: The device comprises: A tracking point information acquisition module is configured to acquire first tracking point information corresponding to the abnormal event if the vehicle detects that a tracking point abnormal event is triggered, wherein the first tracking point information includes at least one of a subsystem type corresponding to the abnormal event, an application module corresponding to the abnormal event, an abnormality type corresponding to the abnormal event, an information domain corresponding to the abnormal event, a fault identifier corresponding to the abnormal event, an abnormality name corresponding to the abnormal event, and an abnormal location corresponding to the abnormal event; The burial point information sending module is used to send the first burial point information to the server, so that the server can determine the fault information corresponding to the abnormal event based on the first burial point information.

11. A fault analysis device, characterized in that: The device comprises: A tracking point information receiving module is configured to receive first tracking point information sent by a vehicle, wherein the first tracking point information is obtained by the vehicle when an abnormal event of a tracking point is detected and triggered, wherein the first tracking point information includes at least one of a subsystem type corresponding to the abnormal event, an application module corresponding to the abnormal event, an abnormality type corresponding to the abnormal event, an information domain corresponding to the abnormal event, a fault identifier corresponding to the abnormal event, an abnormality name corresponding to the abnormal event, and an abnormal location corresponding to the abnormal event; A fault information determination module is used to determine the fault information corresponding to the abnormal event based on the first burial point information.

12. An electronic device, characterized in that: include: one or more processors; Memory; One or more application programs, wherein the one or more application programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs are configured to execute the method according to any one of claims 1 to 9.

13. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores program code, which can be called by a processor to execute the method according to any one of claims 1 to 9.

Images