Vehicle remote fault diagnosis method, device, system, equipment and medium

Abstract

The invention discloses a vehicle remote fault diagnosis method, device, system and equipment and a medium. The method comprises the following steps: acquiring vehicle position information and vehicle fault information of a to-be-diagnosed vehicle; determining a fault reason and a fault level based on the vehicle fault information, and generating a corresponding fault report; determining a target after-sales end based on the vehicle position information and the fault level, and determining the push frequency of the fault report based on the fault level; and pushing the fault report to the target after-sales end according to the pushing frequency, and sending information of the target after-sales end to the to-be-diagnosed vehicle. According to the method, rapid and accurate fault positioning and efficient maintenance are realized, the maintenance experience of a user is remarkably improved, and the after-sales maintenance cost is reduced.

Description

Technical Field

[0001] The present invention relates to the technical field of fault diagnosis, and in particular to a vehicle remote fault diagnosis method, device, system, equipment and medium. Background Art

[0002] In the traditional vehicle fault diagnosis model, the driver is the first link in vehicle fault perception and response. When the driver realizes that the vehicle may have a fault, he or she usually needs to drive the vehicle to the nearest after-sales store for face-to-face fault consultation and diagnosis. This process is not only time-consuming and laborious, but also highly dependent on the driver's personal judgment and experience, which may lead to untimely fault discovery or misdiagnosis.

[0003] For after-sales stores, since they can only obtain and analyze the fault status after the vehicle arrives at the store, they are often in a state of passively receiving information, which is prone to problems such as slow fault analysis, difficult problem location, insufficient maintenance capabilities and low efficiency. In addition, some stores may not be able to immediately resolve vehicle failures due to technical limitations or insufficient spare parts, causing users to travel back and forth between different stores many times, greatly affecting the user's maintenance experience.

[0004] Therefore, there is an urgent need for a technical solution that can achieve remote diagnosis, quickly locate faults, improve maintenance efficiency and enhance user maintenance experience. Summary of the invention

[0005] In view of the above problems, the present invention is proposed to provide a vehicle remote fault diagnosis method, device, system, equipment and medium that overcome the above problems or at least partially solve the above problems, thereby achieving rapid and accurate fault positioning and efficient maintenance, significantly improving the user's maintenance experience and reducing after-sales repair costs.

[0006] In a first aspect, a vehicle remote fault diagnosis method is provided, comprising:

[0007] Obtaining vehicle location information and vehicle fault information of the vehicle to be diagnosed;

[0008] Based on the vehicle fault information, determine the fault cause and fault level, and generate a corresponding fault report;

[0009] Determining a target sales end-point based on the vehicle location information and the fault level, and determining a push frequency of the fault report based on the fault level;

[0010] The fault report is pushed to the target post-sales end according to the push frequency, and the information of the target post-sales end is sent to the vehicle to be diagnosed.

[0011] Optionally, determining a target end-sales service center based on the vehicle location information and the fault level includes:

[0012] Based on the vehicle location information, select after-sales stores within a set distance from the vehicle as initial after-sales stores;

[0013] Based on the fault level, selecting a store whose maintenance capability matches the fault level from the initial after-sales stores as a candidate after-sales store;

[0014] A store closest to the vehicle location is selected from the candidate after-sales stores as the target after-sales store.

[0015] Optionally, determining the push frequency of the fault report based on the fault level includes:

[0016] Based on a preset mapping relationship between fault levels and push frequencies, determine a push frequency mapped to the fault levels;

[0017] The higher the fault level, the higher the push frequency.

[0018] Optionally, obtaining vehicle fault information includes:

[0019] In response to the fault flag position of the main control unit from the vehicle end, the vehicle fault information is obtained, and the vehicle fault information at least includes the fault monitoring code of the main control unit and the vehicle operation data within a set time period before and after the fault;

[0020] Among them, the vehicle end includes multiple control units, each of which is correspondingly configured with a controller fault code for monitoring faults of internal functional components of each control unit and external functional components associated with the control unit. The main control unit is a control unit among the multiple control units, and the fault monitoring code includes at least one fault flag bit, and each fault flag is associated with the at least one controller fault code used to represent different faults of the same functional component.

[0021] Optionally, determining the fault cause and fault level based on the vehicle fault information includes:

[0022] Based on a preset mapping relationship between a fault flag and a fault cause, determining that a fault cause mapped to the set fault flag is an initial fault cause;

[0023] Determining a root cause of a vehicle failure based on the vehicle operation data and the initial failure cause;

[0024] Based on a preset mapping relationship between fault causes and fault levels, the fault level mapped to the root fault cause is determined.

[0025] Optionally, the vehicle remote fault diagnosis method further includes:

[0026] Sending the fault report to the research and development end; the fault report also includes a fault condition determined based on the vehicle fault information, the fault condition being the actual condition of the vehicle when the vehicle fails;

[0027] receiving a fault statistics request sent by the research and development end based on the fault report, wherein the fault statistics request is generated by the research and development end when the fault report meets a specific condition, wherein the specific condition is that the fault conditions in the fault reports corresponding to N vehicles are all the same, and N is a positive integer greater than 1;

[0028] Based on the fault statistics request, generating a fault distribution statistical graph, wherein the fault distribution statistical graph is used to indicate fault causes of the N vehicles under the fault condition;

[0029] Obtaining vehicle operation data of the N vehicles under the fault condition, and recording the data as target data;

[0030] The fault distribution statistical graph and the target data are sent to the research and development end.

[0031] In a second aspect, a vehicle remote fault diagnosis device is provided, comprising:

[0032] An information acquisition module is used to obtain the location information and vehicle fault information of the vehicle to be diagnosed;

[0033] A first determination module, used to determine the cause and level of a fault based on the vehicle fault information, and generate a corresponding fault report;

[0034] A second determination module is used to determine a target after-sales end based on the location information and the fault level;

[0035] A third determination module, configured to determine a push frequency of the fault report based on the fault level;

[0036] A report push module is used to push the fault report to the target after-sales service center according to the push frequency, and send the information of the target after-sales service center to the vehicle to be diagnosed.

[0037] Optionally, the second determining module is further used for:

[0038] Based on the vehicle location information, select after-sales stores within a set distance from the vehicle as initial after-sales stores;

[0039] Based on the fault level, selecting a store whose maintenance capability matches the fault level from the initial after-sales stores as a candidate after-sales store;

[0040] A store closest to the vehicle location is selected from the candidate after-sales stores as the target after-sales store.

[0041] Optionally, the third determining module is further used to:

[0042] Based on a preset mapping relationship between fault levels and push frequencies, determine a push frequency mapped to the fault levels;

[0043] The higher the fault level, the higher the push frequency.

[0044] Optionally, the information acquisition module is further used to:

[0045] In response to the fault flag position of the fault monitoring code from the main control unit of the vehicle end, the vehicle fault information is obtained, and the vehicle fault information at least includes the fault monitoring code and the vehicle operation data within a set time period before and after the fault;

[0046] Among them, the vehicle end includes multiple control units, each of which is correspondingly configured with a controller fault code for monitoring faults of internal functional components of each control unit and external functional components associated with the control unit. The main control unit is a control unit among the multiple control units, and the fault monitoring code includes at least one fault flag bit, and each fault flag is associated with at least one controller fault code used to represent different faults of the same functional component.

[0047] Optionally, the first determining module is further used for:

[0048] Based on a preset mapping relationship between a fault flag and a fault cause, determining that a fault cause mapped to the set fault flag is an initial fault cause;

[0049] Determining a root cause of a vehicle failure based on the vehicle operation data and the initial failure cause;

[0050] Based on a preset mapping relationship between fault causes and fault levels, the fault level mapped to the root fault cause is determined.

[0051] Optionally, the device further comprises:

[0052] A first sending module, configured to send the fault report to a research and development end; the fault report also includes a fault condition determined based on the vehicle fault information, wherein the fault condition is the actual condition of the vehicle when the vehicle fails;

[0053] A receiving module, configured to receive a fault statistics request sent by the R&D end based on the fault report, wherein the fault statistics request is generated by the R&D end when the fault report meets a specific condition, wherein the specific condition is that the fault conditions in the fault reports corresponding to N vehicles are all the same, and N is a positive integer greater than 1;

[0054] A graphics processing module, used for generating a fault distribution statistical graph based on the fault statistical request, wherein the fault distribution statistical graph is used for indicating the fault causes of the N vehicles under the fault condition;

[0055] A second acquisition module is used to acquire vehicle operation data of the N vehicles under the fault condition, which is recorded as target data;

[0056] The second sending module is used to send the fault distribution statistical graph and the target data to the research and development end.

[0057] In a third aspect, a vehicle remote fault diagnosis system is provided, comprising a cloud side, a vehicle side, a back-end sales side and a research and development side, wherein the vehicle side is used to collect vehicle location information and vehicle fault information, and send them to the cloud side, and the cloud side is used to execute the vehicle remote fault diagnosis method as described in the first aspect, so as to send the generated fault diagnosis report to the back-end sales side and the research and development side.

[0058] In a fourth aspect, an electronic device is provided, comprising: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, computer instructions are stored in the memory, and the processor executes the vehicle remote fault diagnosis method as described in the first aspect by executing the computer instructions.

[0059] In a fifth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable the computer to execute the vehicle remote fault diagnosis method as described in the first aspect.

[0060] The technical solution provided in the embodiments of the present invention has at least the following technical effects or advantages:

[0061] The embodiments of the present invention provide a vehicle remote fault diagnosis method, device, system, equipment and medium, which can realize remote diagnosis of vehicle faults by actively acquiring vehicle fault information of the vehicle to be diagnosed, determining the fault cause and fault level, and automatically generating a fault report, without the need for the driver to actively find the after-sales service end point, greatly shortening the time from fault discovery to response. By acquiring the vehicle location information and combining it with the fault level, the most suitable target after-sales service endpoint can be intelligently screened to ensure that the vehicle can receive timely and professional maintenance services. At the same time, the information of the target after-sales service end point is sent to the vehicle to be diagnosed, which can guide the user to go there, reducing the user's blind search and waiting time, and greatly improving the user experience. Further, the push frequency of the fault report is determined by the fault level, and the fault report is pushed to the target after-sales service end point according to the determined push frequency, which can ensure that the after-sales service end point obtains urgent or important fault information in the first time, so as to respond quickly and take corresponding maintenance measures. At the same time, it can also ensure that the target after-sales service end point can obtain fault information in advance and quickly locate the fault, so as to more accurately prepare maintenance plans and required spare parts, more effectively manage maintenance costs, and improve maintenance efficiency and quality. For users, it can further reduce maintenance cycles and maintenance costs, thereby improving user maintenance experience.

[0062] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented according to the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the detailed description of the preferred embodiments below. The accompanying drawings are only for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the present invention. Moreover, the same reference symbols are used throughout the accompanying drawings to represent the same components. In the accompanying drawings:

[0064] Figure 1 is a flow chart of a vehicle remote fault diagnosis method provided by an embodiment of the present invention;

[0065] Figure 2 is a flow chart of another vehicle remote fault diagnosis method provided by an embodiment of the present invention;

[0066] Figure 3 is another flow chart of a vehicle remote fault diagnosis method provided by an embodiment of the present invention;

[0067] Figure 4 The present invention provides a structural block diagram of a vehicle remote fault diagnosis device. DETAILED DESCRIPTION

[0068] In order to better understand the above-mentioned technical scheme, the above-mentioned technical scheme will be described in detail below in combination with the accompanying drawings and specific implementation methods of the specification. It should be understood that the embodiments of the present disclosure and the specific features in the embodiments are detailed descriptions of the technical scheme of the present application, rather than limitations on the technical scheme of the present application. In the absence of conflict, the embodiments of the present application and the technical features in the embodiments can be combined with each other.

[0069] Figure 1 is a flow chart of a vehicle remote fault diagnosis method provided by an embodiment of the present invention, such as Figure 1 As shown, the vehicle remote fault diagnosis method is applicable to a cloud server, and the method includes:

[0070] Step S110: Acquire vehicle position information and vehicle fault information of the vehicle to be diagnosed.

[0071] In specific implementation, the vehicle location information can be obtained through GPS positioning.

[0072] In one implementation, the vehicle fault information includes at least a fault monitoring code and vehicle operation data within a set time period before and after the fault. In other implementations, the vehicle fault information may also include a fault freeze frame, controller fault codes of each control unit in the vehicle network architecture, vehicle fault conditions, and vehicle configuration information, etc., which are not limited in this embodiment.

[0073] In one implementation, obtaining vehicle fault information in step S110 includes:

[0074] In response to the fault flag position of the fault monitoring code from the main control unit at the vehicle end, vehicle fault information is obtained.

[0075] The vehicle end includes a plurality of control units, each of which is configured with a controller fault code for monitoring the faults of the internal functional components of each control unit and the external functional components associated with the control unit. The main control unit is a control unit among the plurality of control units, and the fault monitoring code includes at least one fault flag, and each fault flag is associated with at least one controller fault code for indicating different faults of the same functional component. The setting of the fault flag indicates that a fault has occurred. Exemplarily, the fault flag is 0 when there is no fault in the vehicle, and when the fault flag changes from 0 to 1, it indicates that the fault flag has been set.

[0076] In one implementation, before executing step S110, the method may further include the steps of establishing a fault diagnosis network, and a first mapping relationship and a second mapping relationship, so as to monitor the fault monitoring code of the main control unit.

[0077] Figure 2is another flow chart of a vehicle remote fault diagnosis method provided by an embodiment of the present invention. Figure 2 As shown, the method includes:

[0078] Step S210: establishing a fault diagnosis network based on the connection relationship and dependency strength of each control unit in the vehicle network architecture, wherein the fault diagnosis network includes a main control unit and at least one primary control unit associated with the main control unit, and the dependency strength of the main control unit is greater than the dependency strength of the at least one primary control unit;

[0079] In a specific implementation, the dependency strength of each control unit can be comprehensively evaluated through the three aspects of communication request ratio, number of interfaces, and fault impact factor, which can be achieved by weighted averaging the corresponding quantitative indicators of the above aspects or adopting other appropriate evaluation methods. Among them, the quantitative indicators of the communication request ratio can include the request frequency ratio and the bandwidth ratio. The request frequency ratio can be quantified by counting the number of communication requests sent by each control unit in a unit time. High-frequency communication requests indicate that it is active and important in the system; the bandwidth ratio can be quantified by evaluating the proportion of communication load occupied by communication requests. High bandwidth ratio indicates that it is important. The number of interfaces can be quantified by counting the association between the control unit and other control units. More direct associations mean that their interactions are complex and important. The quantitative indicators of the fault impact factor can include exposure, severity, and controllability. The exposure is determined by the corresponding scenario and can be estimated in two ways. The first is based on the duration of a single scenario, and the second is based on the frequency of failures in a single scenario. The severity represents the estimation of the potential degree of harm in a specific driving scenario, and the controllability measures the difficulty of the driver or other road traffic participants to avoid the considered accident in the considered operating scenario. At the same time, the controllability assessment also needs to take into account the possibility that a representative driver or other involved person can influence the scenario to avoid injury. It should be noted that each of the above control units is a control unit on the vehicle with fault diagnosis and storage functions, and each control unit can not only diagnose its own faults but also diagnose faults of other elements associated with the control unit (such as sensors, actuators, communication buses, etc.).

[0080] Step S220, obtaining controller fault codes corresponding to functional components corresponding to various control units in the fault diagnosis network when different faults occur, and determining the fault cause corresponding to each controller fault code to establish a second mapping relationship between the controller fault code and the fault cause;

[0081] Among them, the functional components corresponding to each control unit are the internal functional components of each control unit (such as a central processing unit, a memory, an input / output interface, a communication bus, a power supply, etc.), or the external functional components (such as sensors, actuators, communication buses, etc.) that record faults by each control unit. When different faults occur in each functional component, if the fault causes of some faults are the same, the corresponding controller fault codes may also be the same. Each control unit may be set with at least one controller fault code, and each controller fault code includes a plurality of second fault code flags (for distinction, the first fault code flag is used to represent the fault code flag of the fault monitoring code in the following text), each second fault code flag corresponds to at least one fault cause, when different second fault code flags change from 0 to 1 and are set, the corresponding controller fault codes are also different, and the technicians can determine the actual fault causes corresponding to different controller fault codes based on historical data and actual experience, so as to pre-establish a second mapping relationship between the controller fault code and the fault cause. Since the second fault code flag bits are limited, one second fault code flag bit may actually correspond to multiple fault causes. At this time, the technician can assign weights to the fault causes corresponding to each second fault code flag bit based on the actual probability of each fault cause occurring in the historical data and actual experience, and determine the actual fault cause corresponding to each second fault code flag bit in order of weight from high to low combined with the actual fault data.

[0082] Step S230, configuring a fault monitoring code including multiple fault flags for the main control unit, and defining each fault flag to be mapped with at least one controller fault code for representing different faults of the same functional component, so as to establish a first mapping relationship between the fault flag and the controller fault code.

[0083] Specifically, the fault flag bits in the fault monitoring code can be divided into multiple groups according to the number of control units, each group of fault flag bits corresponds to a control unit, and the number of first fault flag bits in each group of first fault flag bits can also be set according to the number of functional components corresponding to the control unit. For example, when the vehicle network architecture includes a total of 10 control units, the fault flag bits in the fault monitoring code can be divided into 10 groups accordingly; when the number of functional components corresponding to control unit A is 3, the group A of fault flag bits corresponding to control unit A includes 3 first fault flag bits bit1, bit2, and bit3, which correspond to 3 functional components a, b, and c respectively.

[0084] Exemplarily, each first fault flag bit in the fault monitoring code corresponds to a functional component, and when the functional components corresponding to each control unit generate different faults, there will be corresponding controller fault codes. Therefore, each first fault flag bit can be associated with the controller fault code used to represent the same functional component to establish a corresponding first mapping relationship. For example, when the first fault flag bit1 in the fault monitoring code corresponds to the functional component a, and the controller fault codes D1 and D2 are used to represent different faults generated by the functional component a, the first fault flag bit1 can be associated with the controller fault codes D1 and D2, and the controller fault codes corresponding to the first fault flag bit1 are set to D1 and D2.

[0085] Through the above steps S210 to S230, the fault diagnosis network, the first mapping relationship and the second mapping relationship can be established in the cloud. At this time, the cloud server only needs to monitor the fault monitoring code of the main control unit of the vehicle to be diagnosed in real time, and can quickly lock the controller fault code associated with the currently set fault flag, avoiding the tedious process of checking each control unit one by one, and significantly improving the efficiency and speed of fault diagnosis.

[0086] Step S120: Based on the vehicle fault information, determine the fault cause and fault level, and generate a corresponding fault report.

[0087] In one implementation, determining the fault cause and fault level based on the vehicle fault information in step S120 may include:

[0088] Based on a preset mapping relationship between the fault flag and the fault cause, determining the fault cause mapped to the set fault flag as the initial fault cause;

[0089] Determine the root cause of the vehicle failure based on vehicle operating data and the initial failure cause;

[0090] Based on the preset mapping relationship between the fault cause and the fault level, the fault level mapped to the root fault cause is determined.

[0091] In one implementation, based on the pre-set mapping relationship between the fault flag and the fault cause, determining that the fault cause mapped to the set fault flag is the initial fault cause may include:

[0092] The first step is to determine, based on a pre-established first mapping relationship between a fault flag and a controller fault code, a controller fault code corresponding to the set fault flag as a target controller fault code;

[0093] The second step is to determine the fault cause corresponding to the target controller fault code as the initial fault cause based on a pre-established second mapping relationship between the controller fault code and the fault cause.

[0094] In a specific implementation, the first mapping relationship and the second mapping relationship pre-established in the above step S220 and step S230 may be used to determine the initial fault cause.

[0095] In one implementation, when each fault flag bit is mapped to a plurality of controller fault codes, in the first step, based on a pre-established first mapping relationship between the fault flag bit and the controller fault code, determining that the controller fault code corresponding to the set fault flag bit is the target controller fault code may include:

[0096] Based on a pre-established first mapping relationship between a fault flag and a controller fault code, multiple controller fault codes corresponding to a target fault flag are determined as candidate controller fault codes; based on preset fault association weights of each controller fault code, fault association weights corresponding to multiple candidate controller fault codes are determined; from the multiple candidate controller fault codes, the candidate controller fault code with the highest fault association weight is selected as the target controller fault code.

[0097] By introducing the concept of fault association weights, and based on the preset fault association weights of each controller fault code, selecting the candidate controller fault code with the highest fault association weight as the target controller fault code can further improve the accuracy of diagnosis and reduce the possibility of misdiagnosis and missed diagnosis. In addition, each fault flag bit and the controller fault code have a one-to-many mapping relationship, which can further reduce the storage resources occupied by the fault monitoring code in the main control unit, and at the same time effectively reduce the amount of data uploaded to the remote electronic device, reduce the redundancy and resource consumption of cloud data collection, and optimize resource utilization.

[0098] In one implementation, the method may further include a specific method for setting the fault association weight, which specifically includes the following steps:

[0099] Determine the occurrence probabilities of different faults in the functional components corresponding to each control unit; normalize the occurrence probabilities of different faults in the same functional component so that the sum of the occurrence probabilities of different faults in the same functional component is 1; set the normalized occurrence probabilities of each fault as the fault association weight of the controller fault code corresponding to each fault.

[0100] Among them, the probability of occurrence of different faults in each functional component can be determined by technicians through historical data and actual experience. By normalizing the probability of occurrence of faults, normalization can convert the probability of occurrence of faults of different magnitudes or ranges to the same metric standard, so that they can be directly compared and calculated.

[0101] In one implementation, the vehicle operation data includes, but is not limited to, vehicle driving parameters (such as vehicle speed, mileage, steering angle, etc.), engine-related parameters (such as engine temperature, speed, continuous working time, etc.), electrical system parameters (power battery voltage, motor operating status, etc.), brake system parameters (such as ABS operating status, etc.) and other parameters (such as the operating status of various auxiliary equipment such as lighting system, audio system, air conditioning system, etc. on the vehicle). In a specific implementation, the acquired vehicle operation data can be input into a fault diagnosis model pre-established in the cloud, and the fault diagnosis model predicts the cause of the fault based on the fault-related data and outputs it. The fault diagnosis model can be obtained through training based on historical fault data. This is a conventional technology and will not be repeated here. When the cause of the fault output by the fault diagnosis model is consistent with the initial cause of the fault, the initial cause of the fault can be determined as the root cause of the vehicle. It should be noted that when the cause of the fault output by the fault diagnosis model is inconsistent with the initial cause of the fault, an error report is required to enable experts to access and determine the root cause of the vehicle based on the vehicle operation data.

[0102] In one implementation, the fault levels corresponding to different fault causes can be determined by technicians through historical data and actual experience, so as to pre-establish a mapping relationship between fault causes and fault levels and store it in the cloud. Exemplarily, the fault levels can be divided into 4 levels, among which the fault level corresponding to the breakdown type fault cause is level 4, the fault level corresponding to the power limit type fault cause is level 3, the fault level corresponding to the fault light type fault cause is level 2, and the fault level corresponding to the fault code type fault cause is level 1, with level 4 being the highest level.

[0103] In one implementation, the fault diagnosis report may include data such as vehicle model, vehicle configuration, fault condition, vehicle environmental parameters, fault monitoring code, fault freeze frame, fault cause, and maintenance suggestions. Accordingly, the vehicle fault information may include parameters such as vehicle model, vehicle configuration, vehicle environmental parameters, fault monitoring code, fault freeze frame, vehicle operation data, and vehicle condition, and the maintenance suggestion may determine the maintenance suggestion corresponding to the actual fault cause of the vehicle based on the pre-established mapping relationship between the fault cause and the maintenance suggestion.

[0104] Step S130: Determine the target end-of-sales service location based on the vehicle location information and the fault level.

[0105] Optionally, step S130 includes:

[0106] Based on the vehicle location information, after-sales stores within a set distance from the vehicle are selected as the initial after-sales stores; based on the fault level, stores with maintenance capabilities matching the fault level are selected from the initial after-sales stores as candidate after-sales stores; from the candidate after-sales stores, the store closest to the vehicle location is selected as the target after-sales store.

[0107] In one implementation, the maintenance capability of the after-sales store can be graded based on the number of maintenance equipment, the level of maintenance equipment, and the idle maintenance personnel of the after-sales store, and the grading level can be the same as the fault level. For example, when there are 4 levels of fault levels, the maintenance capability can also be divided into 4 levels. When the fault level is level 4, the after-sales store with the corresponding maintenance capability of level 4 can be selected as a matching store to ensure that the store has the ability to handle level 4 faults. It should be noted that the level of maintenance capability can be changed in real time according to parameters such as the number of idle maintenance personnel or the level and number of maintenance equipment. For example, the more idle maintenance personnel, the higher the level of maintenance capability; the higher the level and the more maintenance equipment owned by the after-sales store, the higher the level of maintenance capability. At the same time, by selecting the store closest to the vehicle as the target after-sales service end, it is convenient for users to reach the after-sales store with maintenance capability in time. When the vehicle has a serious fault, after-sales maintenance can be carried out as soon as possible to improve the user's maintenance experience. At the same time, it can also avoid users waiting too long in the same after-sales store to achieve the highest maintenance efficiency.

[0108] Step S140: Determine the push frequency of the fault report based on the fault level.

[0109] Optionally, step S140 includes:

[0110] Based on the pre-set mapping relationship between the fault level and the push frequency, the push frequency mapped to the fault level is determined, wherein the higher the fault level, the higher the push frequency.

[0111] In order to avoid the same store from receiving repeated push notifications of the same fault, different fault push frequencies will be set for level 4 to level 1 faults, among which level 4 faults have the highest push frequency. When the after-sales staff receives the fault push and downloads the vehicle fault report, the push of the fault report can be stopped. At the same time, it is also set that the background needs to record within T2 time whether the user receives a phone reminder to go to the store for repair. If the after-sales store does not notify the user by phone to go to the store for repair, or the after-sales store cannot locate the vehicle problem, the store can enter the active consultation and feedback function. After feedback on the reason for the inability to maintain maintenance, the fault report push will be reopened and the fault report will be sent to the R&D end for collaborative processing. The association between fault level and fault frequency not only promotes the efficiency of user vehicle maintenance, but also avoids the repeated push of after-sales faults. At the same time, it also allows all after-sales stores to fully utilize resources and improve the quality of after-sales maintenance.

[0112] Step S150: Push the fault report to the target after-sales service center according to the push frequency, and send the information of the target after-sales service center to the vehicle to be diagnosed.

[0113] In this embodiment, the information of the target after-sales service center includes at least one of the store name, store address, and telephone number of the target after-sales service center, which is not limited in the present invention, so that the user can locate the target after-sales service center.

[0114] In one implementation, after receiving and downloading the fault report, the target after-sales service center may feed back the maintenance result to the vehicle to be diagnosed, and the method may further include:

[0115] Receive the maintenance result of the target sales end based on the fault report feedback; if the maintenance result is that the target sales end cannot maintain the vehicle, reselect a new target sales end from the candidate sales end based on the distance between each candidate sales end and the vehicle. If the maintenance result is that the target sales end can maintain the vehicle, a prompt message can be sent to the vehicle end, prompting the vehicle end to go to the target sales end as soon as possible.

[0116] It should be noted that after receiving the pushed fault report, the target after-sales service center can quickly locate the cause of the vehicle failure. If it is a hardware problem, you can prepare replacement parts in advance, and then notify the user by phone to come to the store for maintenance; if it is a software problem, you can notify the user by phone to choose remote OTA upgrade for optimization, without going to the store, saving maintenance costs. If the fault report shows that the vehicle's operating environment conditions exceed the vehicle's working environment conditions, the user can also be informed of vehicle maintenance recommendations in the form of text messages or APP push reminders. In this implementation method, the target after-sales service center can obtain the fault report of the vehicle to be diagnosed in advance, avoiding the user's arrival at the store to start troubleshooting, and the troubleshooting results are slow and inaccurate. In complex and concurrent fault situations, R&D personnel are required to assist in troubleshooting, etc., thereby improving the accuracy and efficiency of maintenance.

[0117] After executing step S150, the method may further include a fault diagnosis step between the cloud and the R&D end, so that R&D personnel can use this method to quickly and accurately locate vehicle faults during the vehicle R&D stage, thereby reducing R&D costs.

[0118] Figure 3 is another flow chart of a vehicle remote fault diagnosis method provided by an embodiment of the present invention, such as Figure 3 As shown, the method includes:

[0119] Step S310: Send the fault report to the R&D end. The fault report also includes a fault condition determined based on the vehicle fault information. The fault condition is the actual condition of the vehicle when the vehicle fails.

[0120] In one implementation, the fault condition may include at least one of the following conditions: power on / off condition, sleep / wake-up condition, charge / discharge condition, static condition, dynamic driving condition, and extreme environment condition. Specifically, the fault report may be sent to the R&D end by email. After receiving the email, the R&D end personnel may download the fault report and quickly locate the cause of the vehicle fault.

[0121] Step S320, receiving a fault statistics request sent by the R&D end based on the fault report. The fault statistics request is generated by the R&D end when the fault report meets a specific condition. The specific condition is that the fault conditions in the fault reports corresponding to N vehicles are the same, and N is a positive integer greater than 1.

[0122] Among them, when the fault conditions in the fault reports corresponding to N vehicles are all the same, it means that the batch of vehicles is prone to failure under the fault condition.

[0123] Step S330: Generate a fault distribution statistics graph based on the fault statistics request, where the fault distribution statistics graph is used to indicate the fault causes of N vehicles under fault conditions.

[0124] Among them, the fault distribution statistics chart is only used to count the relevant data of N vehicles under fault conditions, and display the relevant data in the form of a chart, so that R&D personnel can more intuitively determine the fault causes of N vehicles based on the fault distribution statistics chart, thereby reducing the fault analysis time of R&D personnel.

[0125] Step S340: Obtain vehicle operation data of N vehicles under fault conditions and record them as target data.

[0126] Step S350: Send the fault distribution statistics chart and target data to the R&D end.

[0127] Since there are many types of vehicle data, by simplifying the vehicle operation data, only sending the vehicle operation data of N vehicles under fault conditions, it is enough for R&D personnel to analyze and locate the cause of the vehicle failure based on the target data. In the specific implementation, a pop-up window can be displayed to ask R&D personnel whether to download the simplified analysis signal. When the R&D personnel chooses yes, the cloud will send the simplified target data to the R&D end. This function can reduce the download and storage resources of the R&D end, and also enable R&D personnel to obtain sufficient and accurate data for analysis, helping R&D personnel save a lot of fault analysis time.

[0128] Through the above steps S310 to S350, batch faults occurring in the vehicle can be diagnosed during the vehicle development stage, and the problem can be quickly located, thereby further reducing the development cost.

[0129] In the R&D stage, it is often the case that the vehicle hardware has been changed but the vehicle configuration relationship is unclear, which will cause related faults to be reported. At this time, it is necessary to locate the single vehicle. In the R&D stage, vehicles often have batch faults, including but not limited to new hardware problems or hardware and software matching problems. Through the above implementation method, it is not necessary to manually collect data for each vehicle. The cause of the problem can be located through remote data collection, and it is clear whether it is a hardware problem or a software problem, so as to perform rapid iterative optimization. When it is a hardware problem, the vehicle hardware fault information can be pushed to the hardware R&D personnel; when it is a software problem, the vehicle software fault information can be pushed to the software R&D personnel. R&D personnel can confirm the cause of the fault by obtaining the target data and optimize the software / hardware accordingly. Therefore, R&D personnel can remotely obtain the vehicle configuration, the vehicle operation status at the time of the vehicle fault, and other data in real time through the above method, so as to clarify whether the fault reporting conditions are reasonable. At the same time, R&D personnel can also regularly download vehicle operation data under different working conditions according to the vehicle R&D stage, determine which types of faults are easy to report in different R&D stages, summarize R&D experience, and avoid problems in the next stage.

[0130] Based on the same inventive concept, an embodiment of the present invention further provides a vehicle remote fault diagnosis device for implementing vehicle remote fault diagnosis. Figure 4 is a structural block diagram of a vehicle remote fault diagnosis device provided by an embodiment of the present invention, such as Figure 4 As shown, the device 400 includes:

[0131] The information acquisition module 410 is used to acquire the location information and vehicle fault information of the vehicle to be diagnosed;

[0132] A first determination module 420, for determining the cause and level of a fault based on the vehicle fault information, and generating a corresponding fault report;

[0133] A second determination module 430 is used to determine a target after-sales service end based on the location information and the fault level;

[0134] A third determination module 440 is used to determine the push frequency of the fault report based on the fault level;

[0135] The report push module 450 is used to push the fault report to the target after-sales service center according to the push frequency, and send the information of the target after-sales service center to the vehicle to be diagnosed.

[0136] Optionally, the second determining module 430 is further configured to:

[0137] Based on the vehicle location information, select after-sales stores within a set distance from the vehicle as the initial after-sales stores;

[0138] Based on the fault level, select the stores whose maintenance capabilities match the fault level from the initial after-sales stores as candidate after-sales stores;

[0139] The store closest to the vehicle location is selected from the candidate after-sales stores as the target after-sales store.

[0140] Optionally, the third determining module 440 is further configured to:

[0141] Based on the preset mapping relationship between the fault level and the push frequency, determine the push frequency mapped corresponding to the fault level;

[0142] Among them, the higher the fault level, the higher the push frequency.

[0143] Optionally, the information acquisition module 410 is further used to:

[0144] In response to the fault flag position of the fault monitoring code from the main control unit of the vehicle end, the vehicle fault information is obtained, and the vehicle fault information at least includes the fault monitoring code and the vehicle operation data within a set time period before and after the fault;

[0145] Among them, the vehicle end includes multiple control units, each control unit is correspondingly configured with a controller fault code, which is used to monitor the faults of internal functional components of each control unit and external functional components associated with the control unit. The main control unit is a control unit among the multiple control units, and the fault monitoring code includes at least one fault flag bit, and each fault flag is associated with at least one controller fault code used to represent different faults of the same functional component.

[0146] Optionally, the first determining module 420 is further configured to:

[0147] Based on a preset mapping relationship between the fault flag and the fault cause, determining the fault cause mapped to the set fault flag as the initial fault cause;

[0148] Determine the root cause of the vehicle failure based on vehicle operating data and the initial failure cause;

[0149] Based on the preset mapping relationship between the fault cause and the fault level, the fault level mapped to the root fault cause is determined.

[0150] Optionally, the device 400 further includes:

[0151] A first sending module is used to send the fault report to the research and development end; the fault report also includes a fault condition determined based on the vehicle fault information, and the fault condition is the actual condition of the vehicle when the vehicle fails;

[0152] A receiving module, used to receive a fault statistics request sent by the R&D end based on the fault report. The fault statistics request is generated by the R&D end when the fault report meets a specific condition. The specific condition is that the fault conditions in the fault reports corresponding to N vehicles are the same, and N is a positive integer greater than 1;

[0153] A graphics processing module, used for generating a fault distribution statistical graph based on a fault statistical request, wherein the fault distribution statistical graph is used for indicating fault causes of N vehicles under fault conditions;

[0154] The second acquisition module is used to acquire vehicle operation data of N vehicles under fault conditions, which is recorded as target data;

[0155] The second sending module is used to send the fault distribution statistics chart and target data to the R&D end.

[0156] The specific details of the vehicle remote fault diagnosis method used in the above-mentioned device can be understood by corresponding to the relevant descriptions and effects in the above-mentioned vehicle remote fault diagnosis method embodiment, and will not be repeated here.

[0157] Based on the same inventive concept as the above-mentioned vehicle remote fault diagnosis method, the present invention also provides a vehicle remote fault diagnosis system, which includes a cloud, a vehicle, a sales end, and a research and development end. The vehicle is used to collect vehicle location information and vehicle fault information and send them to the cloud. The cloud is used to execute Figures 1 to 3 The vehicle remote fault diagnosis method in the illustrated embodiment is to send the generated fault diagnosis report to the after-sales end and the R&D end.

[0158] In order to better understand the present invention, an example of a method for remote vehicle fault diagnosis using the vehicle remote fault diagnosis system is provided below (taking the failure of a large number of vehicles being unable to charge as an example):

[0159] After the vehicle to be diagnosed is powered on, the vehicle side continuously stores the real vehicle data;

[0160] The cloud monitors multiple vehicles to be diagnosed. The cloud identifies that the fault monitoring codes of 1,000 vehicles have fault flags set, and the vehicles cannot enter charging;

[0161] The cloud reads the vehicle ECU fault code and freeze frame based on the time of fault reporting, and obtains and stores the vehicle fault information at ±t1 before and after the fault occurs; the fault monitoring code indicates that controller A, controller B, and controller C report fault code a, fault code b, and fault code c respectively. Based on the vehicle fault information, the cloud analyzes the fault data at the time of fault code a, fault code b, and fault code c reporting, and locates that the fault code c of controller C causes controller A and controller B to report faults. The cloud records the vehicle model, vehicle configuration, operating conditions at the time of fault occurrence, vehicle environmental parameters, vehicle fault code, fault freeze frame, fault cause and maintenance suggestions, etc. to form a fault report;

[0162] At the same time, when the fault is reported, the cloud starts to perform GPS positioning of the vehicle to be diagnosed, and intelligently selects and locates the best after-sales store nearby according to the vehicle location and fault level, and uses it as the target after-sales store to ensure that the after-sales store has sufficient maintenance capacity to handle such faults and has sufficient manpower and repair areas to handle the faults. Then, the fault report is pushed to the target after-sales store and R&D personnel according to the set push frequency; assuming that the fault level corresponding to the cause of the charging prohibition fault is a level 2 fault, and the corresponding push frequency is t2, then the fault report is pushed once every t2 time interval until the after-sales and R&D end start downloading the vehicle fault report and fault-related data;

[0163] When the R&D personnel receive a fault report showing that a large number of vehicles cannot be charged, and the corresponding fault reports all show that the fault is reported only under charging conditions, they send a fault statistics request to the cloud to request the fault distribution statistics diagram of this batch of faulty vehicles under charging conditions. The cloud receives the fault statistics request, generates a corresponding fault distribution statistics diagram, and sends the fault distribution statistics diagram and the vehicle operation data under charging conditions to the R&D end. At this time, the R&D end can see from the fault distribution statistics diagram that the fault code c of controller C causes the failure to charge. The fault code c indicates that there is a problem with the software logic of controller C, and the fault information and the vehicle operation data under charging conditions are pushed to the software R&D personnel of controller C. The software R&D personnel determine that there is a problem with the quantitative setting of the signal marker in the software logic through the vehicle operation data under charging conditions, so that they can quickly enter the software logic optimization stage, and release the back-end for OTA software flashing after the self-test is correct.

[0164] After-sales staff initially determined through the vehicle fault report that the vehicle could not be charged due to fault code c of controller C. At this time, the R&D end reported that this batch of vehicles could not be charged due to a software logic problem with controller C, so an OTA software upgrade was performed remotely on the problem vehicles.

[0165] Subsequent R&D personnel can also continue to track problems and review historical data of faulty vehicles through the cloud to ensure that subsequent problems do not recur, clarify the reasons for the large-scale problem reports, summarize R&D experience, and avoid problems in the next stage.

[0166] Based on the same inventive concept as the above-mentioned vehicle remote fault diagnosis method, the present invention also provides an electronic device, which may include a processor and a memory, wherein the processor and the memory may be connected to each other through a bus or other means. The processor may be a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components and other chips, or a combination of the above-mentioned various types of chips. The memory, as a non-transient computer-readable storage medium, can be used to store non-transient software programs, non-transient computer executable programs and modules, such as program instructions / modules corresponding to the vehicle remote fault diagnosis method in the embodiment of the present invention. The processor executes various functional applications and data processing of the processor by running the non-transient software programs, instructions and modules stored in the memory, that is, the vehicle remote fault diagnosis method in the above-mentioned method embodiment is realized.

[0167] The memory may include a program storage area and a data storage area, wherein the program storage area may store an operating system and an application required by at least one function; the data storage area may store data created by the processor, etc. In addition, the memory may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. The one or more modules are stored in the memory, and when executed by the processor, the execution is as follows: Figures 1 to 3 The vehicle remote fault diagnosis method in the illustrated embodiment.

[0168] For details of the above electronic equipment, please refer to Figures 1 to 3 The corresponding related descriptions and effects in the illustrated embodiments can be understood and will not be repeated here.

[0169] Based on the same inventive concept as the vehicle remote fault diagnosis method, the present invention also provides a computer-readable storage medium, on which computer instructions are stored, and the computer program instructions are used to enable a computer to execute the vehicle remote fault diagnosis method in the above embodiment.

[0170] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program, and the program can be stored in a computer-readable storage medium, and when the program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, the storage medium can be a read-only memory (ROM), a random access memory (RAM), a flash memory, a hard disk drive (HDD) or a solid-state drive (SSD), etc.; the storage medium can also include a combination of the above-mentioned types of memory.

[0171] The technical solutions provided in the above embodiments of the present application have at least the following technical effects or advantages:

[0172] The embodiments of the present invention provide a vehicle remote fault diagnosis method, device, system, equipment and medium, which can realize remote diagnosis of vehicle faults by actively acquiring vehicle fault information of the vehicle to be diagnosed, determining the fault cause and fault level, and automatically generating a fault report, without the need for the driver to actively find the after-sales service end point, greatly shortening the time from fault discovery to response. By acquiring the vehicle location information and combining it with the fault level, the most suitable target after-sales service endpoint can be intelligently screened to ensure that the vehicle can receive timely and professional maintenance services. At the same time, the information of the target after-sales service end point is sent to the vehicle to be diagnosed, which can guide the user to go there, reducing the user's blind search and waiting time, and greatly improving the user experience. Further, the push frequency of the fault report is determined by the fault level, and the fault report is pushed to the target after-sales service end point according to the determined push frequency, which can ensure that the after-sales service end point obtains urgent or important fault information in the first time, so as to respond quickly and take corresponding maintenance measures. At the same time, it can also ensure that the target after-sales service end point can obtain fault information in advance and quickly locate the fault, so as to more accurately prepare maintenance plans and required spare parts, more effectively manage maintenance costs, and improve maintenance efficiency and quality. For users, it can further reduce maintenance cycles and maintenance costs, thereby improving user maintenance experience.

[0173] In the description provided herein, a large number of specific details are described. However, it is understood that embodiments of the present invention can be practiced without these specific details. In some instances, well-known methods, structures and techniques are not shown in detail so as not to obscure the understanding of this description.

[0174] Similarly, it should be understood that in order to streamline the present disclosure and aid in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of the present invention, various features of the present invention are sometimes grouped together into a single embodiment, figure, or description thereof. However, this disclosed method should not be interpreted as reflecting the intention that the claimed invention requires more features than those explicitly recited in each claim. More specifically, as reflected in the claims below, inventive aspects lie in less than all the features of the individual embodiments disclosed above. Therefore, the claims that follow the specific embodiment are hereby expressly incorporated into the specific embodiment, with each claim itself serving as a separate embodiment of the present invention.

[0175] It should be noted that the above-mentioned embodiments illustrate rather than limit the invention and that those skilled in the art will be able to design alternative embodiments without departing from the scope of the appended claims.

Claims

1. A vehicle remote fault diagnosis method, characterized in that: The vehicle remote fault diagnosis method comprises: Obtaining vehicle location information and vehicle fault information of the vehicle to be diagnosed; Based on the vehicle fault information, determine the fault cause and fault level, and generate a corresponding fault report; Determining a target sales end-point based on the vehicle location information and the fault level, and determining a push frequency of the fault report based on the fault level; The fault report is pushed to the target post-sales end according to the push frequency, and the information of the target post-sales end is sent to the vehicle to be diagnosed.

2. The vehicle remote fault diagnosis method according to claim 1, characterized in that: The determining a target sales end-end based on the vehicle location information and the fault level includes: Based on the vehicle location information, select after-sales stores within a set distance from the vehicle as initial after-sales stores; Based on the fault level, selecting a store whose maintenance capability matches the fault level from the initial after-sales stores as a candidate after-sales store; A store closest to the vehicle location is selected from the candidate after-sales stores as the target after-sales store.

3. The vehicle remote fault diagnosis method according to claim 1, characterized in that: The determining, based on the fault level, a push frequency of the fault report includes: Based on a preset mapping relationship between fault levels and push frequencies, determine a push frequency mapped to the fault levels; The higher the fault level, the higher the push frequency.

4. The vehicle remote fault diagnosis method according to claim 1, characterized in that: The obtaining of vehicle fault information includes: In response to the fault flag position of the main control unit from the vehicle end, the vehicle fault information is obtained, and the vehicle fault information at least includes the fault monitoring code of the main control unit and the vehicle operation data within a set time period before and after the fault; Among them, the vehicle end includes multiple control units, each of which is correspondingly configured with a controller fault code for monitoring faults of internal functional components of each control unit and external functional components associated with the control unit. The main control unit is a control unit among the multiple control units, and the fault monitoring code includes at least one fault flag bit, and each fault flag is associated with the at least one controller fault code used to represent different faults of the same functional component.

5. The vehicle remote fault diagnosis method according to claim 4, characterized in that: The determining the fault cause and fault level based on the vehicle fault information includes: Based on a preset mapping relationship between a fault flag and a fault cause, determining that a fault cause mapped to the set fault flag is an initial fault cause; Determining a root cause of a vehicle failure based on the vehicle operation data and the initial failure cause; Based on a preset mapping relationship between fault causes and fault levels, the fault level mapped to the root fault cause is determined.

6. The vehicle remote fault diagnosis method according to claim 1, characterized in that: The vehicle remote fault diagnosis method further includes: Sending the fault report to the research and development end; the fault report also includes a fault condition determined based on the vehicle fault information, the fault condition being the actual condition of the vehicle when the vehicle fails; receiving a fault statistics request sent by the research and development end based on the fault report, wherein the fault statistics request is generated by the research and development end when the fault report meets a specific condition, wherein the specific condition is that the fault conditions in the fault reports corresponding to N vehicles are all the same, and N is a positive integer greater than 1; Based on the fault statistics request, generating a fault distribution statistical graph, wherein the fault distribution statistical graph is used to indicate fault causes of the N vehicles under the fault condition; Obtaining vehicle operation data of the N vehicles under the fault condition, and recording the data as target data; The fault distribution statistical graph and the target data are sent to the research and development end.

7. A vehicle remote fault diagnosis device, characterized in that: The vehicle remote fault diagnosis device comprises: An information acquisition module is used to acquire the location information and vehicle fault information of the vehicle to be diagnosed; A first determination module, used to determine the cause and level of a fault based on the vehicle fault information, and generate a corresponding fault report; A second determination module is used to determine a target after-sales end based on the location information and the fault level; A third determination module, configured to determine a push frequency of the fault report based on the fault level; A report push module is used to push the fault report to the target after-sales service center according to the push frequency, and send the information of the target after-sales service center to the vehicle to be diagnosed.

8. A vehicle remote fault diagnosis system, characterized in that: The vehicle remote fault diagnosis system includes a cloud side, a vehicle side, a back-end sales side and a research and development side. The vehicle side is used to collect vehicle location information and vehicle fault information, and send them to the cloud side. The cloud side is used to execute the vehicle remote fault diagnosis method as described in any one of claims 1 to 6, so as to send the generated fault diagnosis report to the back-end sales side and the research and development side.

9. An electronic device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the vehicle remote fault diagnosis method as described in any one of claims 1 to 6 by executing the computer instructions.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable the computer to execute the vehicle remote fault diagnosis method according to any one of claims 1 to 6.

Images