A vehicle fault information dynamic monitoring and collecting method

Abstract

The application provides a kind of vehicle fault information dynamic monitoring collection method, belong to vehicle fault diagnosis technical field.The collection method includes: cloud according to vehicle type configuration fault monitoring and fault information collection strategy, and send to car end;Car end receives the fault monitoring and fault information collection strategy configured by cloud and executes, carries out fault dynamic monitoring and dynamic screening to vehicle, obtains fault information and sends to cloud.In the application, car end carries out dynamic monitoring and dynamic screening to vehicle according to the fault monitoring and fault data collection strategy configured by cloud, obtains fault information and sends to cloud in the first time, cloud and after-sales service center are linked, realize the quick response of after-sales service to fault vehicle, after-sales service system changes from original after-service to fault service in progress, improves after-sales service efficiency, improves customer satisfaction.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of vehicle fault diagnosis, and particularly relates to a vehicle fault information dynamic monitoring and collecting method. BACKGROUND

[0002] With the development of cloud computing, big data, artificial intelligence and other technologies, automobile technology is developing rapidly, and is developing towards four directions of electrification, networking, intelligence and sharing. The wide application of electronic control technology makes the structure of automobile electronic control system more and more complex. The bus architecture of the automobile develops from the central centralized E / E architecture to the service-oriented E / E architecture, and the bus type develops from the CAN bus to the Ethernet bus. The number of automobile parts develops from 10 to more than 50. Therefore, when a vehicle fails, it becomes more and more difficult to determine the cause of the failure and find the fault part. How to quickly and accurately diagnose / locate the fault of the automobile electronic control system is a big problem faced by the current automobile industry.

[0003] In the current fault maintenance system, from research and development design to after-sales maintenance, the following stages are mainly divided:

[0004] Design stage: In the vehicle design process, possible faults of ECU or vehicle system are identified and defined;

[0005] Driving stage: During the driving process of the vehicle, the fault is identified through the fault model or failure model of the part during the running process, and the fault information is recorded in the ECU;

[0006] Maintenance stage: After the vehicle fails, the instrument will light up the fault lamp, and the vehicle needs to enter the 4S store. After the ECU internal fault information is read by the diagnostic instrument, the fault cause is determined, and the vehicle is maintained.

[0007] From the foregoing description, it can be seen that the current vehicle diagnosis and maintenance belongs to after-maintenance, that is, maintenance in the 4S store after the fault occurs. The after-maintenance mainly has the following problems:

[0008] (1) High maintenance cost: The vehicle fault cannot be analyzed, classified and maintained in advance. The fault vehicle can only be analyzed and maintained in the 4S store, which has high maintenance cost. At the same time, for slight vehicle faults, the vehicle also needs to enter the station for maintenance, which wastes a lot of time cost of the vehicle owner;

[0009] (2) Difficulty in fault analysis: For complex faults (or occasional faults), because the first scene of the fault has been destroyed (the vehicle has arrived at the 4S store), the timeliness and regional nature of the fault are destroyed, which increases the difficulty of fault analysis;

[0010] (3) Maintenance cycle is long: unable to repair the vehicle in advance, part of the long procurement cycle, resulting in long repair cycle, increase the cost of waiting for the owner;

[0011] (4) Poor user experience: long repair cycle, high repair cost, repeated failure, resulting in poor repair experience for the owner. SUMMARY

[0012] The purpose of the present application is to solve the problems existing in the prior art, to provide a vehicle fault information dynamic monitoring and collecting method, the vehicle end dynamically monitors and dynamically screens the vehicle according to the fault monitoring and fault data collection strategy configured by the cloud end, obtains the fault information and sends it to the cloud end in the first time, and the cloud end and the after-sales service center are linked to realize the rapid response of the after-sales service of the fault vehicle.

[0013] The present application is realized by the following technical solutions:

[0014] The present application provides a vehicle fault information dynamic monitoring and collecting method, comprising the following steps:

[0015] The cloud end configures the fault monitoring and fault information collection strategy according to the vehicle type and sends it to the vehicle end;

[0016] The vehicle end receives the fault monitoring and fault information collection strategy configured by the cloud end and executes it, dynamically monitors and dynamically screens the vehicle, obtains the fault information and sends it to the cloud end.

[0017] Further improvement of the present application is:

[0018] The vehicle end includes a remote diagnosis management module RDM, after receiving the fault monitoring and fault information collection strategy sent by the cloud end, the RDM is saved locally; after the RDM starts to enter the monitoring state after each vehicle power-on, the vehicle end RDM will be updated synchronously after the cloud end issues new strategy.

[0019] Further improvement of the present application is:

[0020] The vehicle end dynamically monitors the faults generated by each ECU in the vehicle, specifically:

[0021] (1) Collecting switch logic

[0022] Whether the specific vehicle has a fault collection function is configured in the cloud end, after receiving the task of closing collection or opening collection configured by the cloud end, the vehicle end will be set to close collection or open collection;

[0023] When the vehicle end receives the task of closing collection sent by the cloud end, it is set to close collection;

[0024] When the vehicle receives the task to start data collection from the cloud, it is set to start data collection. After receiving the task to start data collection from the cloud, the vehicle starts fault collection according to the fault collection strategy stored locally on the vehicle.

[0025] (2) Acquisition caching strategy

[0026] The fault code cache contains all fault codes read after power-on. If the fault code clearing operation is performed in other ways, the fault code acquisition cache itself will not be cleared. The comparison will continue according to the current cache until the power-off or the part restarts.

[0027] (3) GPS data acquisition strategy

[0028] The GPS values ​​were all 0 when the report was submitted.

[0029] A further improvement of the present invention is that:

[0030] The cloud configures whether vehicle fault information collection is required. By default, all vehicles need to have fault information collected. If fault information collection is not required for specific vehicles, the cloud will configure it and send it to the vehicle, which will then save this information.

[0031] After the RDM is powered on and started, it first determines whether the vehicle needs to collect fault information. If so, it will then collect the first fault information.

[0032] A further improvement of the present invention is that:

[0033] Each time the RDM is powered on and started, when it first determines that fault information needs to be collected, the vehicle will send a collection signal to the cloud. After receiving the collection signal, the cloud will clear the vehicle's fault information and wait for the vehicle to transmit new fault information.

[0034] After RDM notifies the cloud to start data collection, each round of fault data collection is performed at intervals, which are configured in the fault information collection strategy configured in the cloud.

[0035] A further improvement of the present invention is that:

[0036] When RDM collects data for the first time, it sends all current ECU fault code information to the cloud. In subsequent collections, it sends the updated ECU fault code information to the cloud. If no ECU fault codes are collected, they do not need to be sent to the cloud.

[0037] After RDM completes a round of data collection, if there is any ECU fault information sent to the cloud, a final data collection completion notification will be sent; if no fault information is collected, no information will be sent, and of course, no data collection completion notification will be sent.

[0038] A further improvement of the present invention is that:

[0039] During the RDM acquisition, after the fault information of one ECU is collected and sent to the cloud, the fault information of the next ECU is collected.

[0040] The further improvement of the application is that:

[0041] The vehicle end dynamically screens the faults of the vehicle, and specifically:

[0042] (1) New fault code

[0043] When the vehicle end RDM collects the fault code of the current ECU, the fault code is compared with the last fault code, if the collected fault code has a fault code that is not in the last fault code, the frozen frame of the fault code is read, and the fault code and the frozen frame are combined into the fault information, and are marked as a new fault code, and are sent to the cloud, and then the fault code of the next ECU is collected.

[0044] (2) Fault code state change

[0045] The current fault code is the same as the last fault code, but the state code is different, and the current fault state is as follows:

[0046] bit0=1 and the last fault state bit0=0

[0047] bit2=1 and the last fault state bit2=0

[0048] The frozen frame of the fault code is read, and the fault code and the frozen frame are combined into the fault information, and are marked as a state change, and are sent to the cloud before collecting the fault of the next ECU.

[0049] (3) Fault code reduction

[0050] When the vehicle end RDM collects the fault code of the current ECU, the fault code is compared with the last fault code, if the last fault code has a fault code that is not collected at present, the fault code is marked as a reduced fault code and sent to the cloud, and then the fault code of the next ECU is collected.

[0051] The further improvement of the application is that:

[0052] The collection method further includes:

[0053] The cloud receives the fault information, analyzes the fault severity level and sends it to the after-sales service platform.

[0054] The further improvement of the application is that:

[0055] The fault severity level is analyzed, and specifically:

[0056] There is a fault code information library in the cloud, which includes the ECU to which the fault code belongs, the meaning analysis of the fault code, the fault level and other information, and the fault codes are divided into high, medium and low risk levels according to the severity;

[0057] After the cloud receives the fault information sent by the vehicle end, the fault group is queried in the fault code information library, and the fault level is determined.

[0058] Compared with the prior art, the beneficial effects of the present application are:

[0059] The present application provides a kind of vehicle fault information dynamic monitoring collection method, and cloud is configured fault monitoring and fault data collection strategy according to vehicle type, and vehicle end dynamically monitors vehicle operating state, discovers fault in first time, collects fault information and sends to cloud, and cloud and after-sales service center are linked, and the after-sales service of fault vehicle is realized quickly response. After-sales service system is changed from original after-service into fault service in progress, improves after-sales service efficiency, improves customer satisfaction. BRIEF DESCRIPTION OF DRAWINGS

[0060] Figure 1 It is the data flow chart of the present application. DETAILED DESCRIPTION

[0061] The present application will be described in further detail below in conjunction with the accompanying drawings:

[0062] The present application provides a kind of vehicle fault information dynamic monitoring collection method, as shown in Figure 1 The present application provides a kind of vehicle fault information dynamic monitoring collection method, as shown in

[0063] Step 1, cloud is configured fault monitoring and fault information collection strategy according to vehicle type, and sends to vehicle end;

[0064] The prerequisite condition of the fault monitoring and fault information collection strategy configured by the cloud is that the monitoring mark bit configured is supported by ECU, because different ECUs may support different mark bits, so different values are configured according to different ECUs.

[0065] The cloud configures each ECU in the vehicle type according to the fault code state bit supported by each ECU and the mark bit to be monitored.

[0066] ECU (Electronic Control Unit) electronic control unit, also known as "driving computer", "vehicle computer" and the like.

[0067] Step 2, vehicle end receives fault monitoring and fault information collection strategy configured by cloud and executes, and performs fault dynamic monitoring and dynamic screening on vehicle, obtains fault information and sends to cloud;

[0068] Each ECU has its supported fault code status bit, and each fault code generates its marked bit. By configuring the monitored marked bit, if the fault code generates a marked bit that matches the monitored marked bit, the fault code will be detected.

[0069] The vehicle end includes a remote diagnosis management module RDM. After the vehicle end receives the fault monitoring and fault information collection strategy sent by the cloud end, the RDM saves the relevant strategy locally. Each time the vehicle is powered on, the RDM starts and enters a monitoring state. After the cloud end issues a new strategy, the vehicle end RDM synchronously updates and saves it.

[0070] The cloud end does not issue a new strategy every time the vehicle is powered on. Only if the strategy of the cloud end changes, a new strategy will be issued. If there is no new strategy, the RDM will use the previously saved strategy to monitor after the vehicle is powered on.

[0071] After the RDM starts each time, the vehicle end sends a collection signal to the cloud end for the first time to determine whether fault information collection is needed. After receiving the collection signal, the cloud end clears the fault information of the vehicle and waits for the vehicle end to transmit new fault information.

[0072] In the cloud end, whether the vehicle needs fault information collection can be configured. By default, all vehicles need fault information collection. If a specific vehicle does not need fault information collection, it can be configured in the cloud end and issued to the vehicle end. The vehicle end saves this information. After the RDM is powered on and starts, it first determines whether the vehicle needs fault information collection. If it does, it performs the first fault information collection.

[0073] The RDM sends all ECU fault code information to the cloud end for the first time. In subsequent collections, it sends the updated ECU fault code information to the cloud end. If no ECU fault code is collected, it does not need to be sent to the cloud end.

[0074] During a round of RDM collection, if any ECU finds a fault code change, it collects all the change values of this ECU, uploads them to the cloud end, and then enters the next ECU fault information collection. After the cloud end receives the change data, it updates the change data of this ECU based on the current data.

[0075] A vehicle has multiple ECUs (Electronic Control Units), such as GW (Gateway), ECM (Engine Management Module), AC (Air Conditioner), etc. After one ECU fault information collection is completed and sent to the cloud end, the next ECU fault information collection is performed.

[0076] A round of collection refers to collecting all fault codes of all ECUs on the vehicle.

[0077] RDM normally completes a round of collection, if there is ECU fault information sent to the cloud, the last time to send a collection end notification, that is, the completion of this round of collection; if no fault information is collected, it will not be sent, of course, no collection end notification will be sent.

[0078] RDM in the notification cloud to start the collection, each round of fault collection interval, a round of collection during the ECU fault code. Each collection should be collected all ECU fault codes, which is a round of collection, that is, each time the fault information or fault code uploaded to the cloud is dynamically changing, which may not be the same each time.

[0079] Each round of fault collection interval means that the interval between two rounds of collection is a certain time, which is configured in the fault information collection strategy in the cloud.

[0080] Vehicle-side dynamic monitoring of vehicle faults means that the vehicle-side dynamically monitors the faults generated by each ECU in the vehicle, specifically:

[0081] (1) Collection switch logic

[0082] The cloud can control whether the specific vehicle has a fault collection function, and the vehicle side will set it to close collection or open collection after receiving the close collection or open collection task configured by the cloud.

[0083] When the vehicle side receives the close collection task sent by the cloud, it is set to close collection. If it is in the collection process, the cloud sends an interrupt collection task. It is not a normal end, so it will not report the collection end;

[0084] When the vehicle side receives the open collection task sent by the cloud, it is set to open collection. When the vehicle side receives the open collection task sent by the cloud, it starts fault collection according to the fault collection strategy saved locally by the vehicle side.

[0085] For the first time, the vehicle side sends a start collection signal to the cloud.

[0086] (2) Collection cache strategy

[0087] Fault collection is an independent function, so it will not be associated with other functions.

[0088] Fault code cache reads all fault codes after power-on, such as other ways to execute the clear fault code operation, which will not clear the fault code collection itself cache, still according to the current cache continues to compare, until this time power-off or part restart.

[0089] (3) GPS collection strategy

[0090] Because of the acquisition process, there may be no GPS acquisition conditions, but GPS is not the main business data of fault acquisition, so it does not affect the normal reporting of fault acquisition. The GPS value is 0 when reporting.

[0091] The vehicle end dynamically filters the vehicle faults, specifically:

[0092] (1) New fault code

[0093] When the vehicle end RDM collects the fault code of the current ECU, it compares with the last fault code. If there is a fault code in the collected fault code that is not in the last fault code, the frozen frame of this fault code is read, and the fault code and frozen frame are combined into the fault information, and marked as a new fault code, sent to the cloud end, and then the fault code of the next ECU is collected.

[0094] (2) Fault code state change

[0095] The current fault code is the same as the last fault code, but the state code is different. When the current fault state is as follows:

[0096] bit0 = 1 and last fault state bit0 = 0

[0097] bit2 = 1 and last fault state bit2 = 0

[0098] Read the frozen frame of this fault code, and combine it with the fault code and frozen frame into the fault information, and mark it as a state change before collecting the next ECU fault.

[0099] Note: If the reporting condition is not met, the cloud end state may not be consistent with the vehicle end.

[0100] (3) Fault code reduction

[0101] When the vehicle end RDM collects the fault code of the current ECU, it compares with the last fault code. If the last fault code contains a fault code that is not currently collected, this fault code is marked as a reduced fault code and sent to the cloud end, and then the next ECU fault code is collected.

[0102] The cloud always stores the latest round of received vehicle end sent fault information; the vehicle end currently collected fault information, if also collected in the last round and no state change, will not be uploaded to the cloud again.

[0103] Step 3, the cloud end receives the fault information, analyzes the fault severity level and sends it to the after-sales service platform.

[0104] Analyze the fault severity level, specifically:

[0105] There is a fault code information library in the cloud, including the fault code belonging to the ECU, the fault code meaning analysis, the fault level and other information, and the fault codes are divided into high, medium and low risk levels according to the severity; the cloud receives the fault information uploaded by the vehicle end, and then queries the fault group in the fault code information library, and determines the fault level.

[0106] The after-sales department selects the matching maintenance mode and formulates the coping strategy on the after-sales service platform according to the fault severity level, and provides the first-time after-sales maintenance service.

[0107] In the description of the present application, it should be noted that unless otherwise specified and limited, the terms "connected", "connected" should be understood broadly, for example, it can be fixedly connected, or it can be detachably connected, or integrally connected; it can be mechanically connected, or it can be electrically connected; it can be directly connected, or it can be indirectly connected through an intermediate medium. For those skilled in the art, the specific meaning of the above terms in the present application can be understood according to the specific circumstances.

[0108] In the description of the present application, unless otherwise stated, the terms "upper", "lower", "left", "right", "inner", "outer" and the like indicate the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the devices or elements referred to must have a particular orientation, be constructed and operated in a particular orientation, therefore it cannot be understood as a limitation on the present application.

[0109] The above technical solution is only one embodiment of the present application, and for those skilled in the art, on the basis of the principles disclosed in the present application, various types of improvements or modifications can be easily made, and the technical solution described in the above embodiment is not limited to the present application, therefore the above description is only preferred, and does not have the meaning of limitation.

Claims

1. A method for dynamic monitoring and collecting vehicle fault information, characterized in that, The method comprises the following steps: The cloud configures fault monitoring and fault information collection strategies according to the vehicle type and sends them to the vehicle end; The vehicle end receives the fault monitoring and fault information collection strategies configured by the cloud and executes them, dynamically monitors and screens faults of the vehicle, collects fault information and sends it to the cloud; The vehicle end comprises a remote diagnosis management module (RDM), and the dynamic monitoring of the vehicle end on the faults of the vehicle means that the vehicle end dynamically monitors faults generated by each ECU in the vehicle; The dynamic screening of the vehicle end on the faults of the vehicle is specifically as follows: (1) New fault code When the RDM of the vehicle end collects the fault code of the current ECU, the fault code is compared with the fault code of the last time. If there is a fault code in the collected fault code that is not in the fault code of the last time, the frozen frame of the fault code is read, the fault code and the frozen frame are combined into the fault information, the fault code is marked as a new fault code, and the fault code is sent to the cloud. Then the fault code of the next ECU is collected. (2) Fault code state change When the current fault code is the same as the last time, but the state code is different, the current fault state is as follows: bit0=1 and the last time fault state bit0=0 bit2=1 and the last time fault state bit2=0 The frozen frame of the fault code is read, and the fault code and the frozen frame are combined into the fault information, which is marked as a state change. Before the next ECU fault is collected, it is sent to the cloud. (3) Fault code reduction When the RDM of the vehicle end collects the fault code of the current ECU, the fault code of the last time is compared with the fault code of the current ECU. If there is a fault code in the fault code of the last time that is not collected in the current ECU, the fault code is marked as a reduced fault code and sent to the cloud. Then the fault code of the next ECU is collected.

2. The method of claim 1, wherein, After the vehicle end receives the fault monitoring and fault information collection strategies sent by the cloud, the RDM will be saved locally. Each time the vehicle is powered on, the RDM starts to enter the monitoring state. After the cloud issues a new strategy, the vehicle end RDM will update and save it synchronously.

3. The method of claim 2, wherein, The dynamic monitoring of the vehicle end on the faults of the vehicle means that the vehicle end dynamically monitors faults generated by each ECU in the vehicle, specifically as follows: (1) Collection switch logic The cloud configures whether the specific vehicle has a fault collection function. After the vehicle end receives the task of closing collection or opening collection configured by the cloud, it will be set to close collection or open collection. When the vehicle end receives the task of closing collection sent by the cloud, it is set to close collection. When the vehicle end receives the task of opening collection sent by the cloud, it is set to open collection. After the vehicle end receives the task of opening collection sent by the cloud, it starts fault collection according to the fault collection strategy saved locally by the vehicle end. (2) Collection cache strategy After the fault code cache is powered on, all the read fault codes will not be cleared from the fault code collection cache itself, but will continue to be compared according to the current cache until the current power-off or part restart. (3) GPS collection strategy The reported GPS value is 0.

4. The method of claim 3, wherein, The cloud configures whether the vehicle needs fault information collection, and by default, all vehicles need fault information collection. If fault information collection is not needed for a specific vehicle, the cloud configures and sends the information to the vehicle end, and the vehicle end saves the information. After the RDM is powered on, it first determines whether the vehicle needs fault information collection, and if so, performs the first fault information collection.

5. The method of claim 4, wherein, After the RDM is powered on each time, the vehicle end sends a collection signal to the cloud when it determines that fault information collection is needed for the first time. After receiving the collection signal, the cloud clears the fault information of the vehicle and waits for the vehicle end to transmit new fault information. After the RDM notifies the cloud to start collection, it performs fault collection at intervals. The interval time is configured in the fault information collection strategy configured by the cloud.

6. The method of claim 5, wherein, The RDM sends all ECU fault code information to the cloud during the first collection, and sends updated ECU fault code information to the cloud during subsequent collections. If no ECU fault code is collected, it is not sent to the cloud. After the RDM completes a round of collection normally, if ECU fault information is sent to the cloud, it will send a collection end notification again. If no fault information is collected, it will not be sent, and of course, no collection end notification will be sent.

7. The method of claim 6, wherein, During a round of collection by the RDM, after an ECU fault information collection is completed and sent to the cloud, the next ECU fault information is collected.

8. The method of claim 1, wherein, The collection method further includes: The cloud receives fault information, analyzes the fault severity level, and sends it to the after-sales service platform.

9. The method of claim 8, wherein, Analyzing the fault severity level includes: There is a fault code information library in the cloud, which includes information such as the ECU to which the fault code belongs, the meaning of the fault code, and the fault level. Fault codes are divided into high, medium, and low risk levels according to severity. After receiving the fault information sent by the vehicle end, the cloud queries the fault group in the fault code information library to determine the fault level.

Images