A vehicle fault cloud intelligent diagnosis method and system

Abstract

The present application belongs to the technical field of vehicle fault diagnosis, and proposes a vehicle fault cloud intelligent diagnosis method and system. Through dividing a special cache area in the vehicle gateway to realize the rolling storage of millisecond-level raw data, cooperating with the accurate data calling mechanism when the fault is triggered, the millisecond-level data before and after the fault can be quickly extracted and uploaded to the cloud, breaking through the limitation of the fastest frequency of the existing platform signal, and completely solving the problem that the traditional method is powerless for the fault with millisecond-level response time. At the same time, without waiting for the fault to reappear on site, the fault analysis can be completed directly through the millisecond-level data stored in the cloud, avoiding the problems that the problem cannot be locked due to the fault not reappearing, and the disadvantage that the fault risk exists for a long time, greatly improving the timeliness and effectiveness of the diagnosis of millisecond-level faults.

Description

Technical Field

[0001] This invention belongs to the technical field of vehicle fault diagnosis, and in particular relates to a cloud-based intelligent diagnosis method and system for vehicle faults. Background Technology

[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.

[0003] When a vehicle malfunctions, especially one affecting driving, the ability to download and quickly access data from the cloud is crucial for analyzing the cause and pinpointing the problem. However, most platforms only support signals with a maximum frequency of 1 second, often proving ineffective for faults with response times in the millisecond range. Traditional methods often require on-site data collection until the fault is reproduced (the reproduction period is unpredictable and may not even be possible). If the fault can be reproduced quickly, it can be investigated and addressed promptly; however, if the fault persists and the problem remains unidentified, the risk of failure remains. Summary of the Invention

[0004] To overcome the shortcomings of the prior art, the present invention provides a cloud-based intelligent diagnosis method and system for vehicle faults. By dividing a dedicated cache area in the vehicle gateway to achieve rolling storage of millisecond-level raw data, the timeliness and effectiveness of millisecond-level fault diagnosis are greatly improved.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, the present invention provides a cloud-based intelligent diagnostic method for vehicle faults, applied to a vehicle cloud-based fault diagnosis system. The system includes various controllers on the vehicle side, a vehicle gateway, a vehicle mobile terminal, and a vehicle data cloud platform. The method includes the following steps: The vehicle gateway is divided into a dedicated cache area for rolling storage of millisecond-level raw vehicle data, and the millisecond-level raw data in the dedicated cache area of ​​the vehicle gateway is transmitted to the vehicle mobile terminal. The central controller integrates the fault levels of all controllers and synthesizes a fault flag bit, which is then transmitted to the vehicle gateway. After receiving the fault flag bit, the vehicle gateway extracts the millisecond-level raw data ahead of the fault trigger time from the dedicated cache area according to the timestamp, and continues to store the millisecond-level raw data after the fault trigger time. The two data segments are packaged and transmitted to the vehicle mobile terminal via Ethernet. The vehicle mobile terminal uploads the received millisecond-level raw data packets to the vehicle data cloud platform, and at the same time, the vehicle terminal uploads the diagnostic fault codes when the fault is triggered to the vehicle data cloud platform. The vehicle data cloud platform parses the received millisecond-level raw data packets and fault codes before and after the fault triggering time, retrieves the corresponding related scenario data according to the fault scenario signal requirement list, and realizes the data playback and display of related scenarios when the fault occurs.

[0006] Secondly, the present invention provides a cloud-based intelligent diagnostic system for vehicle faults, comprising: The vehicle gateway is used to store millisecond-level raw data of the vehicle in a dedicated cache area and transmit the millisecond-level raw data in the dedicated cache area to the vehicle mobile terminal. The central controller is used to integrate the fault levels of all controllers, synthesize fault flag bits, and transmit the fault flag bits to the vehicle gateway; The vehicle gateway is used to extract millisecond-level raw data prior to the fault trigger time from a dedicated cache area after receiving the fault flag bit, and at the same time continue to store millisecond-level raw data after the fault trigger time. The two data segments are packaged and transmitted to the vehicle mobile terminal via Ethernet. The vehicle mobile terminal is used to upload the received millisecond-level raw data packets to the vehicle data cloud platform. At the same time, the vehicle terminal also uploads the diagnostic fault codes when the fault is triggered to the vehicle data cloud platform. The vehicle data cloud platform is used to parse the received millisecond-level raw data packets and fault codes before and after the fault trigger time, and retrieve corresponding related scenario data according to the fault scenario signal requirement list, so as to realize the data playback and display of related scenarios when the fault occurs. Thirdly, the present invention provides an electronic device including a memory and a processor, and computer instructions stored in the memory and running on the processor, wherein the computer instructions, when executed by the processor, perform the method described in the first aspect.

[0007] Fourthly, the present invention provides a computer-readable storage medium for storing computer instructions, which, when executed by a processor, perform the method described in the first aspect.

[0008] Fifthly, the present invention provides a vehicle that employs the cloud-based intelligent diagnostic method for vehicle faults described in the first aspect.

[0009] The above one or more technical solutions have the following beneficial effects: In this invention, a dedicated cache area is partitioned in the vehicle gateway to achieve rolling storage of millisecond-level raw data. Combined with a precise data retrieval mechanism upon fault triggering, millisecond-level data before and after the fault can be quickly extracted and uploaded to the cloud. This overcomes the limitation of the fastest signal frequency on existing platforms and completely solves the problem that traditional methods are ineffective for faults with response times in the millisecond range. Furthermore, there is no need to wait for the fault to reproduce on-site; fault analysis is completed directly using millisecond-level data stored in the cloud. This avoids the drawbacks of problems that cannot be identified and long-term fault risks caused by faults that cannot be reproduced, significantly improving the timeliness and effectiveness of diagnosing millisecond-level faults.

[0010] In this invention, critical fault data is stored in a dedicated storage area on the vehicle via a gateway. Furthermore, millisecond-level raw data and diagnostic fault codes are simultaneously uploaded to the vehicle data cloud platform via the vehicle's mobile terminal for permanent storage. This eliminates the time and space limitations of vehicle-side data storage. Even if a long interval has passed since the fault occurred, complete fault data can be retrieved from the cloud, completely solving the problems of easy data loss and lack of traceability on the vehicle side.

[0011] In this invention, the cloud platform can retrieve related scenario data based on the fault scenario signal requirement list, enabling data playback and visualization of related scenarios when a fault occurs. Simultaneously, it combines diagnostic fault codes before and after the fault trigger moment for consistency verification and multi-dimensional analysis, deeply integrating millisecond-level raw data with fault code information. Compared to traditional manual analysis that only views single data points, this invention can more comprehensively and intuitively reconstruct the complete fault scenario, capturing subtle signal changes before and after the fault, significantly improving the accuracy of fault root cause localization, and effectively solving the problems of vague fault location and easy misjudgment in traditional methods.

[0012] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0013] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0014] Figure 1 This is a flowchart illustrating the data transmission process between the gateway and the vehicle mobile terminal via Ethernet in Embodiment 1 of the present invention. Figure 2 This is a schematic diagram of the data upload mechanism before and after a fault in Embodiment 1 of the present invention; Figure 3 This is a schematic diagram of the fault diagnosis system upon which the vehicle cloud platform performs automated analysis in Embodiment 1 of the present invention. Figure 4This is a flowchart of the cloud-based intelligent diagnosis method for vehicle faults in Embodiment 1 of the present invention. Detailed Implementation

[0015] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0016] It should be noted that the terminology used herein is for the purpose of describing particular implementations only and is not intended to limit the exemplary implementations of the present invention.

[0017] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0018] Example 1 This embodiment discloses a cloud-based intelligent diagnostic method for vehicle faults, applied to a vehicle cloud-based fault diagnosis system. The system includes various controllers on the vehicle side, a vehicle gateway, a vehicle mobile terminal, and a vehicle data cloud platform. The method includes the following steps: The vehicle gateway is divided into a dedicated cache area for rolling storage of millisecond-level raw data of the vehicle, and the millisecond-level raw data in the dedicated cache area of ​​the vehicle gateway is transmitted to the vehicle mobile terminal. The central controller integrates the fault levels of all controllers and synthesizes the fault flag bits, then transmits the fault flag bits to the vehicle gateway. After receiving the fault flag bit, the vehicle gateway extracts the millisecond-level raw data ahead of the fault trigger time from the dedicated cache area according to the timestamp, and continues to store the millisecond-level raw data after the fault trigger time. The two data segments are packaged and transmitted to the vehicle mobile terminal via Ethernet. The vehicle mobile terminal uploads the received millisecond-level raw data packets to the vehicle data cloud platform, and at the same time, the vehicle terminal uploads the diagnostic fault codes when the fault is triggered to the vehicle data cloud platform. The vehicle data cloud platform parses the received millisecond-level raw data packets and fault codes before and after the fault triggering time, retrieves the corresponding related scenario data according to the fault scenario signal requirement list, and realizes the data playback and display of related scenarios when the fault occurs.

[0019] Combination Figures 1-4 This embodiment will be described in detail. First, the hardware architecture of this embodiment will be described, which includes multiple controllers DCUi (i=1,2,3…) on the vehicle side, vehicle gateway GW, vehicle mobile terminal TCP, and vehicle data cloud platform TSP. It is adapted to the network communication requirements of intelligent driving vehicles and solves the problems of the inability to effectively collect millisecond-level fault data and the lack of automated fault analysis capabilities in the cloud in the prior art.

[0020] In this embodiment, the gateway GW independently undertakes the vehicle data collection function, and transmits data with the vehicle mobile terminal TCP via Ethernet. The vehicle mobile terminal TCP is only responsible for uploading data to the vehicle data cloud platform TSP. The gateway GW divides a dedicated cache area to achieve rolling storage of millisecond-level raw vehicle data. A fault flag is generated through a fault classification triggering mechanism. When a fault is triggered, millisecond-level raw data for 30 seconds before and after the fault is extracted and uploaded to the cloud. The vehicle data cloud platform TSP has a built-in complete fault diagnosis system, which realizes fault data parsing, fault scenario playback display, automated fault analysis, and push of handling suggestions. The entire process does not require manual intervention in data download and analysis, which greatly improves fault diagnosis efficiency and reduces fault troubleshooting costs. Parameters not explicitly stated in this embodiment are set according to the general standards of the intelligent electric vehicle industry. The fault classification standards and various lists of the fault diagnosis system are formulated in combination with the actual R&D and usage scenarios of Chery's intelligent electric vehicles, and have strong practicality and operability.

[0021] In this embodiment, the controller DCUi includes a vehicle control controller, a battery management controller, a motor control controller, a chassis control controller, and an intelligent driving controller. Each controller is equipped with a high-performance microprocessor, and the data acquisition frequency supports the 1ms level. It can collect various status data during vehicle operation in real time, such as vehicle speed, gear, insulation resistance, charging connection status, motor speed, battery voltage and current, etc. The controllers communicate with each other through the CAN bus and have the ability to detect faults and make preliminary judgments on fault levels.

[0022] In this embodiment, the vehicle gateway GW adopts an industrial-grade high-performance gateway controller with a built-in large-capacity storage chip. The total storage space is no less than 128G, which can be divided into a regular data storage area and a dedicated cache area. The dedicated cache area is fixed with 32G of storage space to meet the rolling storage requirements of 30-second millisecond-level raw data. The gateway GW is equipped with an Ethernet communication module, supporting 1000Mbps Ethernet transmission and compatible with CAN bus communication. It can realize efficient data interaction with each controller DCUi and vehicle mobile terminal TCP, and has the capabilities of data sampling, data packaging, fault flag receiving, and data retrieval.

[0023] In this embodiment, the vehicle mobile terminal TCP is equipped with a 4G / 5G communication module, supports wireless communication with the vehicle data cloud platform TSP, has a data upload rate of no less than 100Mbps, and has the ability to receive data, classify and reassemble data, store data and upload to the cloud. It does not have a gateway data collection function and only serves as a data transmission bridge between the vehicle and the cloud.

[0024] In this embodiment, the Vehicle Data Cloud Platform (TSP) is built on a cloud server cluster, including a data receiving server, a data parsing server, a fault analysis server, a display server, and a message push server, with a total storage capacity of no less than 1000TB, supporting the storage and high-speed processing of massive millisecond-level data; it is equipped with a distributed computing framework, enabling multi-task parallel processing to meet the computing power requirements of automated fault analysis; it is equipped with a visual display interface, supporting real-time playback and data display of fault scenarios, and also has a message push function, which can push fault alarm information and handling suggestions to the terminal devices of cloud technicians.

[0025] In this embodiment, each controller (DCUi) is equipped with a fault detection program, which can realize real-time detection and fault level determination of various faults according to a preset fault diagnosis mechanism list; the vehicle gateway (GW) is equipped with a data storage management program, a data transmission program, and a fault flag receiving program, which realizes the division of storage areas, millisecond-level rolling storage of data, Ethernet data transmission, and data retrieval and packaging when a fault is triggered; the vehicle mobile terminal (TCP) is equipped with a data receiving program, a data processing program, and a cloud upload program, which realizes the classification, reorganization, packaging, and stable upload of data to the TSP platform. All vehicle-side software is developed based on an embedded operating system, which has high stability and high real-time performance.

[0026] In this embodiment, the Vehicle Data Cloud Platform (TSP) is equipped with data receiving and storage programs, data parsing programs, fault scenario playback programs, fault automation analysis programs, handling suggestion matching programs, message push programs, etc. It incorporates the entire contents of the fault diagnosis system, including a fault diagnosis mechanism list, a fault scenario signal list, a fault signal playback requirement list, a fault scenario analysis strategy, and a handling classification list corresponding to the fault scenario analysis results. All software is developed based on a cloud-native architecture, supports elastic scaling, and can adapt to vehicle data access and fault diagnosis needs of different scales.

[0027] In this embodiment, during the system initialization phase, the vehicle gateway GW divides its built-in storage chip into a regular data storage area and a dedicated cache area through a data storage management program. The regular data storage area is used to store regular embedded signal data, while the dedicated cache area is a fixed 32G storage space specifically used to store the vehicle's millisecond-level raw data D, and this area is set to a rolling storage mode.

[0028] After the system starts, each controller (DCUi) collects raw data of vehicle operation in real time at a sampling frequency of 1ms and transmits it to the vehicle gateway (GW) via the CAN bus. The gateway (GW) continuously writes the received millisecond-level raw data (D) into a dedicated cache area. When the dedicated cache area is full, the newly collected millisecond-level raw data will automatically overwrite the oldest stored data according to the "first-in, first-out" principle, ensuring that the dedicated cache area always stores the latest millisecond-level raw data of the vehicle within the last 30 seconds.

[0029] For regular embedded signals, the gateway GW samples the signals according to the minimum resolution frequency required by the vehicle data cloud platform TSP (1s in this embodiment). The sampled regular data is written into the regular data storage area and then forwarded to the vehicle mobile terminal TCP in real time via Ethernet.

[0030] In this embodiment, the vehicle gateway GW continuously and in real time transmits the millisecond-level raw data D in the dedicated cache area to the vehicle mobile terminal TCP through the Ethernet communication module. The transmission frequency is consistent with the data acquisition frequency, which is 1ms / time. After the vehicle mobile terminal TCP receives the millisecond-level raw data D from the gateway GW, it classifies, reassembles and packages the data through the data processing program, and simultaneously processes the sampled data of the regular embedded signal. TCP will transmit the processed data packets to the vehicle data cloud platform TSP via the 4G / 5G communication module at the highest signal resolution frequency required by the platform (1s in this embodiment), thereby realizing real-time transmission and storage of data from the vehicle to the cloud under normal vehicle conditions.

[0031] In this embodiment, based on the degree of impact of the fault on vehicle operation, the faults detected by each controller DCUi on the vehicle side are divided into three levels: low, medium, and high. The specific classification rules are as follows: Low-level faults: Faults that do not affect normal driving and are only minor abnormalities in a localized part of the vehicle, such as minor faults in the interior lights or the in-vehicle entertainment system. These faults pose no safety risk and only require recording and reminders. Intermediate faults: Faults that affect some vehicle performance but can still maintain basic driving, such as reduced air conditioning cooling effect or slight power loss. These faults pose a certain performance risk and need to be recorded and the vehicle's performance limited, such as limiting the maximum speed or limiting the air conditioning power. Advanced faults: Faults that seriously affect vehicle driving safety or cause the vehicle to be unable to drive normally, such as battery insulation faults, motor faults, braking system faults, and intelligent driving core module faults. These faults pose extremely high safety risks and need to be recorded and the vehicle's use restricted, such as restricting vehicle starting, forcing the vehicle to drive at low speeds, or triggering emergency braking.

[0032] In this embodiment, each controller DCUi has the above-mentioned fault classification standard built in. After a fault is detected, the fault level can be automatically determined according to the standard, and the fault type, fault level, fault trigger timestamp and other information can be transmitted to the pre-selected "central controller". In this embodiment, the vehicle control controller is selected as the central controller.

[0033] In this embodiment, the vehicle controller acts as the central controller, receiving fault information transmitted from each controller's DCUi in real time. When a fault is detected at the vehicle end, the central controller integrates the fault levels of all controllers through a fault flag bit synthesis program and synthesizes a fault flag bit according to a preset encoding rule. The fault flag bit is a 16-bit binary code, where the first 4 bits are the fault level code (0001 represents a low-level fault, 0010 represents a medium-level fault, and 0100 represents a high-level fault), the middle 8 bits are the fault type code, and the last 4 bits are the fault trigger controller code. Through this encoding rule, the fault level, fault type, and fault trigger location can be accurately identified.

[0034] If multiple faults are detected simultaneously on the vehicle side, the central controller will synthesize and transmit only the fault flag bit of the highest-level fault that is triggered first, according to the principle of "fault level from high to low and trigger time from early to late". This avoids the gateway GW from being overloaded due to the simultaneous transmission of multiple fault flag bits. In this embodiment, if multiple fault levels are the same, only the fault flag bit of the first-triggered fault will be synthesized and transmitted.

[0035] In this embodiment, after the central controller synthesizes the fault flag bit, it transmits the fault flag bit to the vehicle gateway GW in real time via the CAN bus at a transmission rate of 1ms, ensuring that the gateway GW can quickly receive the fault trigger signal.

[0036] In this embodiment, fault flag reception and data retrieval are as follows: The vehicle gateway (GW) receives fault flags transmitted by the central controller in real time through the fault flag receiving program. Upon receiving the fault flag, the rolling storage overwrite mechanism of the dedicated cache area is immediately paused. At the same time, the data retrieval program accurately extracts the vehicle's millisecond-level raw data from the dedicated cache area 30 seconds before the fault trigger time based on the fault trigger timestamp in the fault flag. After extraction, the gateway GW restores the storage function of the dedicated cache area and continues to collect and store the vehicle's millisecond-level raw data from 30 seconds after the fault trigger time, ensuring that complete data before and after the fault is collected.

[0037] If the fault is triggered less than 30 seconds after the vehicle starts, the gateway (GW) will extract all millisecond-level raw data from the time the vehicle starts until the fault is triggered, and then continue to store data for 30 seconds after the fault is triggered to ensure data integrity.

[0038] Data Packaging and Vehicle-End Transmission: The gateway (GW) integrates the extracted raw data in milliseconds before the fault trigger with the raw data in milliseconds after the fault trigger, and packages it according to a preset data packet format through a data packaging program. The data packet includes a data header, data body, and data trailer. The data header contains information such as the vehicle VIN code, fault flag bit, data collection time range, and data collection frequency. The data body is the raw data in milliseconds before and after the fault, and the data trailer is a data check code to ensure that the data is not lost or tampered with during transmission.

[0039] After packaging, the gateway GW transmits the millisecond-level data packets at a transmission rate of 1000Mbps via the Ethernet communication module.

[0040] Fault code and data packet cloud upload: After receiving the millisecond-level data packet from the gateway GW, the vehicle mobile terminal TCP does not perform any data processing and directly uploads the data packet to the vehicle data cloud platform TSP at high speed through the 4G / 5G communication module. At the same time, each controller DCUi on the vehicle side uploads the diagnostic fault code (generated based on the vehicle side diagnostic protocol and corresponding one-to-one with the fault flag bit) to the TSP platform through the gateway GW and TCP. The diagnostic fault code contains detailed information about the fault, such as the specific cause of the fault, the fault detection module, the fault threshold, etc., and the diagnostic fault code is only uploaded when the fault is triggered, without the need for real-time forwarding, reducing the data transmission load between the vehicle side and the cloud.

[0041] In this embodiment, if a network interruption occurs at the vehicle end, TCP will temporarily store the data packets and diagnostic fault codes locally, and automatically upload them to the TSP platform as soon as the network is restored, ensuring that no fault data is lost.

[0042] In this embodiment, the Vehicle Data Cloud Platform (TSP) receives millisecond-level data packets and diagnostic fault codes uploaded by the vehicle's mobile terminal TCP in real time through a data receiving server. Upon receiving the data, the platform first verifies the checksum of the data packet using a data verification program. If the verification passes, it confirms that the data has not been lost or tampered with, and the data packet is associated with the diagnostic fault code and stored with the association identifier being the vehicle's VIN code and the fault trigger timestamp. If the verification fails, the TSP platform immediately sends a data retransmission command to the vehicle's TCP, requesting TCP to re-upload the corresponding data packet until the data verification passes.

[0043] The TSP platform stores the received millisecond-level raw data and diagnostic fault codes in a distributed database, classifies and manages them according to the vehicle VIN code, and assigns a unique fault number to each fault data to facilitate subsequent fault query, analysis and tracing. In addition, the cloud data is stored in a permanent storage mode to avoid the problem of fault data loss caused by the limited time of data storage on the vehicle.

[0044] In this embodiment, millisecond-level data packet parsing: The data parsing server of the vehicle data cloud platform TSP calls the data parsing program to unpack the millisecond-level data packets. First, it parses the data header of the data packet to extract information such as the vehicle VIN code, fault flag bit, and data acquisition time range. Then, it parses the millisecond-level raw data in the data body according to the established signal protocol, converting the binary raw data into recognizable and analyzable physical quantity data. For example, it converts the binary data of voltage acquisition into a specific voltage value (V) and the binary data of vehicle speed acquisition into a specific vehicle speed value (km / h). The parsed physical quantity data retains the original 1ms timestamp to ensure the time continuity and accuracy of the data.

[0045] Diagnostic fault code parsing: The data parsing server synchronously parses the diagnostic fault codes. Based on the vehicle-side diagnostic protocol and the fault code lookup table preset in the cloud, the fault codes are converted into detailed fault information, including fault name, fault trigger controller, fault level, fault detection threshold, vehicle status at the time of fault triggering, etc. At the same time, all historical fault codes within half an hour before and after the fault triggering time are parsed to check for any related faults, providing complete fault information support for subsequent fault analysis.

[0046] Fault Code and Fault Level Consistency Verification: After parsing, the TSP platform automatically verifies whether the fault level corresponding to the diagnostic fault code is consistent with the fault level in the fault flag bit. If they are consistent, the subsequent fault scenario playback and analysis process will begin. If they are inconsistent, the TSP platform will determine that the data is abnormal and immediately push the data abnormality alarm information to the cloud technician. At the same time, it will retrieve the original data of the corresponding time period from the vehicle for secondary verification to investigate problems in the data transmission or parsing process.

[0047] In this embodiment, the Vehicle Data Cloud Platform (TSP) uses its built-in list of fault scenario signal requirements and list of fault signal playback requirements, combined with the parsed millisecond-level physical quantity data, to achieve accurate playback and visualization of the associated scenarios when a fault occurs. The specific implementation process is as follows: Fault Scenario Matching: Based on the parsed fault name and fault type, the TSP platform matches the corresponding fault scenario from the fault scenario signal requirement list. The fault scenario signal requirement list pre-sets the associated scenario signals required for various faults. For example, insulation faults correspond to two scenarios: charging insulation and discharging / driving insulation. The required signals are charging connection signal, insulation resistance value, gear information, and vehicle speed signal. Motor faults correspond to three scenarios: motor starting, motor running, and motor braking. The required signals are motor speed, motor voltage, motor current, and torque signal, etc.

[0048] Related scene signal retrieval: Based on the matched fault scene, the TSP platform accurately retrieves the corresponding related scene signal from the parsed millisecond-level physical quantity data. The retrieved signal retains a 1ms timestamp to ensure the time synchronization of the signal and avoid scene playback deviation caused by signal time difference.

[0049] Scene data processing and visualization conversion: The TSP platform preprocesses the retrieved related scene signals, removes invalid and abnormal data, and then converts the processed signal data into a visual chart format, including real-time curves, numerical change tables, status indicators, etc. The real-time curves are used to display the continuous change trend of the signal over time, the numerical change tables are used to display the specific signal values ​​at key time points, and the status indicators are used to display the key status of the vehicle (such as charging connection status, gear status, fault trigger status, etc.).

[0050] Fault Scenario Playback and Display: The TSP platform, through the visualization interface of the display server, dynamically replays the related scenarios 30 seconds before and after the fault is triggered, according to the time sequence of the fault occurrence. The playback speed supports multiple modes such as fast playback, slow playback, pause, and single frame playback. Cloud technicians can intuitively view the changes in the related scenario signals before and after the fault occurs through the visualization interface. For example, in the charging insulation scenario of insulation fault, the corresponding relationship between the changes in the charging connection status indicator and the real-time insulation resistance curve can be displayed. In the discharging / driving insulation scenario, the corresponding relationship between the real-time vehicle speed curve and the real-time insulation resistance curve can be displayed.

[0051] Meanwhile, the visual interface will also display basic fault information, including vehicle VIN code, fault number, fault name, fault level, fault trigger time, fault trigger controller, etc., realizing the integrated display of fault information and scene playback, providing intuitive and comprehensive visual support for cloud technicians' fault analysis.

[0052] In this embodiment, the fault diagnosis system built into the Vehicle Data Cloud Platform (TSP) is the core of achieving automated fault analysis. This system includes five core components: a fault diagnosis mechanism list, a fault scenario signal list, a fault signal playback requirement list, a fault scenario analysis strategy, and a list of handling classifications corresponding to the fault scenario analysis results. Each list is formulated based on actual fault cases and R&D experience of Chery's intelligent electric vehicles and supports online updates and optimizations. The specific contents are as follows: Fault diagnosis mechanism list: Preset detection methods, detection thresholds, detection frequencies, and fault level judgment criteria for various faults, providing a unified standard for vehicle-side fault detection and cloud-based fault verification; Fault Scenario Signal List: Presets the associated scenarios and required scenario signals for various faults, providing a basis for retrieving scenario signals from the cloud; Fault signal playback requirements list: Pre-set playback formats, display content, and signal accuracy requirements for various fault scenarios to provide a basis for cloud-based scene visualization; Fault scenario analysis strategy: Pre-set signal change characteristics, fault judgment conditions, and associated fault troubleshooting logic under different fault scenarios for various types of faults, providing core algorithm support for automated fault analysis in the cloud; Disposal Classification List: Pre-set disposal suggestions, processing procedures, and responsible parties for different analysis results of various faults, providing a basis for pushing disposal suggestions to the cloud.

[0053] In this embodiment, the fault analysis server of the TSP platform calls the automated fault analysis program, and performs a comprehensive analysis of the parsed millisecond-level physical quantity data and fault information based on the fault scenario analysis strategy in the fault diagnosis system. The specific analysis process is as follows: Enter the corresponding fault scenario analysis process: Based on the parsed fault name and fault level, the TSP platform retrieves the corresponding fault scenario analysis process from the fault scenario analysis strategy. Different faults and different scenarios correspond to different analysis processes to ensure the relevance and accuracy of the analysis.

[0054] Key signal change feature extraction: The fault analysis server extracts features from the associated signal data of the fault scenario. The extracted features include the signal change trend (rising, falling, stable, abrupt change), the fluctuation range of the signal, the time point of the signal abrupt change, and the correlation change pattern between multiple signals. The feature extraction process retains a time precision of 1ms to ensure that subtle signal changes before and after the fault occur are captured, meeting the needs of millisecond-level fault analysis.

[0055] Fault determination condition matching: The fault analysis server will extract key signal change features and match them one by one with the pre-set confirmatory fault features and suspected fault features in the fault scenario analysis strategy. Confirmatory fault features are the core features of the fault occurrence. If the feature is met, the fault can be determined to have actually occurred. Suspected fault features are the potential features of the fault. If the feature is met, it is determined to be a suspected fault and further investigation is required.

[0056] If the signal change characteristics match the characteristics of a confirmed fault, the TSP platform determines it as a real fault and records the specific time of occurrence, the fault development process, and the scope of the fault's impact. If the signal change characteristics only match the characteristics of a suspected fault, it is determined as a suspected fault, and the platform retrieves recent historical operating data from the vehicle for correlation analysis. If the signal change characteristics do not match either the characteristics of a confirmed fault or the characteristics of a suspected fault, it is determined as a false alarm, and the cause of the false alarm is recorded.

[0057] Related fault investigation: If the TSP platform determines that the fault is real, it will further investigate whether there are upstream related faults that caused the fault, according to the related fault investigation logic in the fault scenario analysis strategy. For example, for battery insulation faults, it will investigate upstream related faults such as battery pack damage, charging gun short circuit, and line aging. For motor faults, it will investigate upstream related faults such as motor controller faults, power supply faults, and transmission system faults, so as to achieve accurate location of the root cause of the fault.

[0058] In this embodiment, the TSP platform matches corresponding handling suggestions from the handling classification list corresponding to the fault scenario analysis results based on the fault analysis results. The handling suggestions are subdivided according to fault level, fault type, and fault scenario, specifically including on-site emergency handling suggestions, professional repair suggestions, parts replacement suggestions, vehicle use restriction suggestions, etc. At the same time, it clarifies the priority of handling, the responsible party (such as vehicle user, service station technician, manufacturer technician), handling time limit and other information.

[0059] In this embodiment, the disposal classification list pre-sets standardized disposal suggestions for various types of faults. For example, the disposal suggestion for low-level faults is "the vehicle user should check it himself, no professional repair is required," the disposal suggestion for medium-level faults is "go to the nearest service station for professional inspection and repair, and restrict some performance of the vehicle before repair," and the disposal suggestion for high-level faults is "stop using the vehicle immediately, contact the service station for on-site rescue and inspection, and do not continue to drive."

[0060] Fault Alarm and Handling Suggestion Push: The TSP platform uses a message push server to simultaneously push fault alarm information and matching handling suggestions to cloud-based technician terminals, vehicle user terminals, and corresponding service station terminals. The information content pushed to different terminals is differentiated according to the needs of the users. Complete fault information is pushed to the cloud technician terminal, including fault level, fault type, fault root cause, fault scene playback link, related signal data, standardized handling suggestions, and detailed vehicle information and operating data, so as to facilitate remote guidance by cloud technicians. Push concise fault alerts to vehicle user terminals, including fault name, fault level, vehicle usage suggestions, emergency handling methods, location and contact information of the nearest service station, and push the priority and time limit requirements for fault handling to facilitate users to take quick countermeasures; Detailed fault dispatch information is pushed to the corresponding service station terminal, including vehicle VIN code, user contact information, vehicle location, fault type, fault level, handling suggestions, service station's handling responsibility and time limit requirements, and also includes playback data of the fault scenario and key signals, so that the service station can prepare for repairs in advance.

[0061] Push notifications can be sent via app messages, SMS, or phone calls. For high-level faults, a triple push notification method of "app message + SMS + phone call" is used to ensure that relevant parties receive fault information as soon as possible. For medium-level faults, a dual push notification method of "app message + SMS" is used. For low-level faults, a single push notification method of "app message" is used to ensure information delivery while avoiding information interference caused by excessive push notifications.

[0062] In this embodiment, after receiving the fault alarm information and handling suggestions, the cloud technician views the fault scene playback and detailed data through the visual interface of the TSP platform, and performs secondary confirmation and optimization of the fault handling suggestions. If no optimization is required, a service order is directly dispatched to the corresponding service station of the vehicle through the TSP platform. The dispatch information includes the arrangement of repair technicians, preparation of repair parts, dispatch of service vehicles, and on-site rescue route planning. If the handling suggestions need to be optimized, they are modified on the platform before dispatching the order.

[0063] The TSP platform tracks the entire fault handling process in real time. After completing fault detection, repair, and rescue work, the service station technicians upload the handling results, repair records, parts replacement records, and other information to the TSP platform in real time. The TSP platform associates and stores the handling results with the original fault data to form a complete fault handling file. At the same time, it pushes the handling results to the vehicle user terminal and the cloud technician terminal to achieve closed-loop management of fault diagnosis and handling.

[0064] If the vehicle experiences the same fault again after the fault has been resolved, the TSP platform will retrieve the historical handling records of the fault, perform correlation analysis, investigate the cause of the fault recurrence, and provide data support for subsequent fault optimization and prevention.

[0065] This embodiment takes battery insulation failure, a common advanced fault in intelligent electric vehicles, as an example to illustrate in detail the entire process from vehicle-side fault detection, data upload to cloud-based fault analysis, scenario playback, automated analysis, and push of handling suggestions. Battery insulation failure is a high-risk fault in intelligent electric vehicles, with a response time in the millisecond range. Existing technologies cannot effectively collect and analyze this fault. This method can achieve accurate diagnosis and rapid handling of this fault.

[0066] (a) Vehicle-side fault detection and data upload.

[0067] Fault Detection and Level Determination: During the charging process of a certain intelligent electric vehicle, the battery management controller collects the insulation resistance value of the battery pack in real time at a sampling frequency of 1ms. When it detects that the insulation resistance value suddenly drops from the normal 500MΩ to 50kΩ, which is lower than the preset insulation fault detection threshold (100kΩ), the battery management controller immediately determines it as a battery insulation fault and classifies it as a high-level fault according to the fault classification standard. At the same time, the fault type (battery insulation fault), fault level (high-level), and fault trigger timestamp (2025-06-01 14:30:00.000) are transmitted to the central controller (vehicle control controller) via the CAN bus.

[0068] Fault flag synthesis and transmission: After receiving the fault information from the battery management controller, the vehicle control controller synthesizes a fault flag (0100001000010010), where the first 4 bits 0100 represent a high-level fault, the middle 8 bits 00100001 represent a battery insulation fault, and the last 4 bits 0010 represent the battery management controller. The fault flag is then transmitted to the vehicle gateway GW via the CAN bus.

[0069] Data retrieval and packaging: After receiving the fault flag bit, the gateway (GW) immediately extracts the millisecond-level raw data for the 30 seconds preceding the fault trigger time (2025-06-01 14:30:00.000) from the dedicated cache area (2025-06-01 14:29:30.000-2025-06-01 14:30:00.000). At the same time, it continues to store the millisecond-level raw data for the 30 seconds following the fault trigger time (2025-06-01 14:30:00.000-2025-06-01 14:30:30.000). Then, the two data segments are integrated and packaged. The data packet contains information such as the vehicle VIN code, fault flag bit, and data collection time range.

[0070] Data and fault code upload: The gateway GW transmits millisecond-level data packets to TCP via Ethernet. TCP then immediately uploads the data packets to the TSP platform via the 5G communication module. At the same time, the battery management controller uploads the diagnostic fault code (P0AA6: reduced insulation performance of the high-voltage system) to the TSP platform.

[0071] (II) Cloud-based fault analysis and scenario replay Data Reception and Parsing: After receiving millisecond-level data packets and diagnostic fault codes, the TSP platform first performs data verification. If the verification passes, the data packets are unpacked and parsed, converting the binary raw data into physical quantity data, including charging connection signals, insulation resistance values, gear information, vehicle speed signals, etc. At the same time, the diagnostic fault code P0AA6 is parsed to obtain detailed fault information: the insulation performance of the high-voltage system is reduced, the fault level is high, the fault trigger controller is the battery management controller, and the fault detection threshold is insulation resistance <100kΩ.

[0072] Fault level consistency verification: The TSP platform verifies that the high-level fault corresponding to the diagnostic fault code is consistent with the high-level fault in the fault flag bit, and then proceeds to the subsequent scenario playback and analysis process.

[0073] Fault scenario matching and signal retrieval: Based on the fault name (battery insulation fault), the TSP platform matches the charging insulation scenario and the discharging / driving insulation scenario from the fault scenario signal requirement list, and retrieves the corresponding related scenario signals from the parsed physical quantity data: charging connection signal, insulation resistance value, gear information, and vehicle speed signal.

[0074] Scene Replay and Display: After preprocessing the retrieved signals, the TSP platform converts them into visual charts, enabling a 30-second scene replay before and after the fault in the visualization interface: the charging connection status indicator shows "connected", the gear information shows "P gear", and the vehicle speed signal shows 0km / h, indicating that the fault scenario is a charging insulation scenario; at the same time, the real-time curve of the insulation resistance value is displayed. The curve shows that at 14:30:00.000 on 2025-06-01, the insulation resistance value suddenly dropped from 500MΩ to 50kΩ and remained at a low resistance value, intuitively presenting the entire process of the fault occurrence.

[0075] (III) Automated analysis and handling suggestions for cloud-based faults Automated Fault Analysis: The TSP platform enters the charging insulation scenario analysis process for battery insulation faults, extracting the change characteristics of insulation resistance and charging connection signal: the charging connection status remains "connected", the insulation resistance changes abruptly at the fault trigger moment, dropping sharply from above the normal threshold to below the threshold and remaining at a low resistance value. This feature is completely matched with the pre-set confirmatory fault features in the fault scenario analysis strategy, and the TSP platform determines it to be a real charging insulation fault.

[0076] Subsequently, related fault investigation was conducted, and detailed data of the charging connection signal was retrieved. It was found that the connection signal of the charging gun was normal, with no abnormalities such as short circuit or poor contact. It was determined that the root cause of the charging insulation fault was the temporary low insulation caused by the electrical characteristics during the vehicle-charging pile matching process, thus ruling out faults in the vehicle's battery pack and wiring.

[0077] Matching of handling recommendations: Based on the analysis results, the TSP platform matches the corresponding handling recommendations from the handling category list: "Immediately stop charging at the current charging station, try to recharge at a different charging station, no on-site assistance is required. If the fault still occurs after replacing the charging station, contact the nearest service station for professional inspection." The handling priority is "medium", the responsible party is "vehicle user", and the handling time limit is "immediate handling".

[0078] Multi-terminal push and service dispatch: The TSP platform pushes fault alarm information and handling suggestions to cloud technician terminals, vehicle user terminals, and nearby service station terminals: it pushes SMS and APP messages to user terminals, reminding users to stop charging immediately, try to replace the charging pile, and provides the location of the nearest charging pile; it pushes complete fault information and scene playback links to cloud technician terminals; and it pushes fault information to service station terminals, requiring them to be prepared to provide professional inspection at any time.

[0079] Fault Handling Tracking: After the vehicle user replaced the charging pile according to the handling suggestions and recharged, the insulation resistance value collected by the battery management controller returned to 500MΩ, returning to normal. The user reported the handling result to the TSP platform, which recorded the fault as "transient vehicle-charging pile matching fault, handled successfully", forming a complete fault handling file. At the same time, the handling result was pushed to the cloud technician and service station terminal. The entire fault diagnosis and handling process was completed in less than 5 minutes, achieving rapid and accurate fault diagnosis at the millisecond level.

[0080] In this embodiment, parameters such as the storage space of the gateway's dedicated cache area, the data storage duration, the data acquisition frequency, the fault classification standard, and the various lists of the fault diagnosis system can all be adjusted according to the actual vehicle development and usage needs without changing the core implementation logic of this method.

[0081] In this embodiment, data transmission between the vehicle and the cloud uses Ethernet and 4G / 5G wireless communication. If a more efficient communication method becomes available in the future, it can be directly replaced. This method has no special restrictions on the communication method, only requiring that it meets the requirements of large data volume and high speed transmission.

[0082] In this embodiment, the vehicle controller is selected as the central controller. If the vehicle has different hardware configurations, other controllers (such as battery management controllers or intelligent driving controllers) can also be selected as the central controller. Only minor adjustments need to be made to the synthesis and transmission program of the fault flag bit, which will not affect the overall implementation of this method.

[0083] In this embodiment, a battery insulation fault is used as an example for detailed explanation. For other types of faults (such as motor faults, braking system faults, intelligent driving module faults, etc.), the diagnosis process is the same as in this embodiment. They are all implemented according to the process of vehicle-side data collection and uploading, cloud-based data parsing, scene playback, automated analysis, and handling suggestions push. The only differences are in the fault scenario, associated signals, analysis strategies, and handling suggestions.

[0084] This embodiment is not only applicable to intelligent electric vehicles, but can also be adapted to the fault diagnosis needs of traditional fuel vehicles and hybrid vehicles. Only targeted adjustments are needed to the vehicle-side controller, data acquisition signals, and fault diagnosis system, making it a promising solution with broad application prospects.

[0085] The cloud-based intelligent diagnosis method for vehicle faults described in this embodiment has the following effects: By using the rolling storage of the dedicated cache area of ​​the gateway and the data retrieval mechanism when a fault is triggered, the accurate collection and uploading of raw data at the millisecond level for 30 seconds before and after a fault is achieved. This solves the problem that millisecond-level fault data cannot be effectively collected in the existing technology. The data collection accuracy reaches 1ms, which meets the needs of millisecond-level fault diagnosis for intelligent electric vehicles. Based on the built-in fault diagnosis system, the system realizes automated fault analysis and root cause localization. The accuracy rate of real fault diagnosis reaches 98.7%, and the false alarm rate is only 1.3%, which is significantly higher than the accuracy rate of manual analysis in existing technologies (about 80%). This method automates the entire process from vehicle-side fault detection to cloud-based diagnosis and handling suggestions, eliminating the need for manual data download and analysis. The average time for diagnosis and handling of a single fault is reduced from several hours or even days under existing technologies to less than 5 minutes, improving fault diagnosis and handling efficiency by more than 80%. By using cloud-based automated diagnosis and remote troubleshooting suggestions, the process of collecting data on-site and waiting for the fault to reproduce is avoided, which greatly reduces labor costs, on-site troubleshooting costs and vehicle downtime costs. According to statistics, the average troubleshooting cost per fault has been reduced by more than 70%. It achieves rapid detection and diagnosis of high-risk faults at the millisecond level, and can immediately push handling suggestions after the fault occurs to avoid safety accidents caused by the further development of the fault. During the test, all detected high-level faults were handled in the first time, and no safety accidents occurred due to the failure to troubleshoot faults in time, effectively reducing the risk of vehicle faults.

[0086] Meanwhile, the vehicle-side data transmission method in this embodiment adopts Ethernet, which is suitable for the large data transmission needs of intelligent driving vehicles. The separation of gateway and TCP functions reduces the workload of a single device and improves the stability and reliability of vehicle-side data transmission. The cloud-based fault diagnosis system supports online updates and optimizations, and can continuously improve fault analysis strategies and handling suggestions based on actual fault cases. It has strong scalability and adaptability and can adapt to the fault diagnosis needs of intelligent electric vehicles of different brands and models.

[0087] Example 2 The purpose of this embodiment is to provide a cloud-based intelligent diagnostic system for vehicle faults, including: The vehicle gateway is used to store millisecond-level raw data of the vehicle in a dedicated cache area and transmit the millisecond-level raw data in the dedicated cache area to the vehicle mobile terminal. The central controller is used to integrate the fault levels of all controllers, synthesize fault flag bits, and transmit the fault flag bits to the vehicle gateway; The vehicle gateway is used to extract millisecond-level raw data prior to the fault trigger time from a dedicated cache area after receiving the fault flag bit, and at the same time continue to store millisecond-level raw data after the fault trigger time. The two data segments are packaged and transmitted to the vehicle mobile terminal via Ethernet. The vehicle mobile terminal is used to upload the received millisecond-level raw data packets to the vehicle data cloud platform. At the same time, the vehicle terminal also uploads the diagnostic fault codes when the fault is triggered to the vehicle data cloud platform. The vehicle data cloud platform is used to parse the received millisecond-level raw data packets and fault codes before and after the fault trigger time, and retrieve corresponding related scenario data according to the fault scenario signal requirement list, so as to realize the data playback and display of related scenarios when the fault occurs. In further embodiments, the following is also provided: An electronic device includes a memory and a processor, as well as computer instructions stored in the memory and running on the processor. When executed by the processor, the computer instructions perform the method described in Embodiment 1. For brevity, further details are omitted here.

[0088] It should be understood that in this embodiment, the processor can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0089] Memory may include read-only memory and random access memory, and provides instructions and data to the processor. A portion of memory may also include non-volatile random access memory. For example, memory may also store information about the device type.

[0090] A computer-readable storage medium for storing computer instructions, which, when executed by a processor, perform the method described in Embodiment 1.

[0091] The method in Embodiment 1 can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor. The software modules can reside in readily available storage media in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, a detailed description is not provided here.

[0092] A vehicle employing the method described in Example 1.

[0093] A computer program product includes a computer program that, when executed by a processor, implements the method described in Embodiment 1.

[0094] The present invention also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions, such as instructions included in program modules, which execute in a device on a target real or virtual processor to perform the processes / methods described above. Typically, program modules include routines, programs, libraries, objects, classes, components, data structures, etc., that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of program modules can be combined or divided among program modules as needed. The machine-executable instructions for the program modules can execute within a local or distributed device. In a distributed device, the program modules can reside in both local and remote storage media.

[0095] The computer program code used to implement the methods of the present invention may be written in one or more programming languages. This computer program code may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the computer or other programmable data processing device, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a computer, partially on a computer, as a stand-alone software package, partially on a computer and partially on a remote computer, or entirely on a remote computer or server.

[0096] In the context of this invention, computer program code or related data may be carried by any suitable carrier to enable a device, apparatus, or processor to perform the various processes and operations described above. Examples of carriers include signals, computer-readable media, and the like. Examples of signals may include electrical, optical, radio, sound, or other forms of propagation signals, such as carrier waves, infrared signals, etc.

[0097] Those skilled in the art will recognize that the units and algorithm steps described in conjunction with the embodiments herein can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0098] While the specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of the present invention are still within the scope of protection of the present invention.

Claims

1. A cloud-based intelligent diagnostic method for vehicle faults, characterized in that, An application to a vehicle cloud-based fault diagnosis system, the system comprising various controllers on the vehicle side, a vehicle gateway, a vehicle mobile terminal, and a vehicle data cloud platform, the method comprising the following steps: The vehicle gateway is divided into a dedicated cache area for rolling storage of millisecond-level raw data of the vehicle, and the millisecond-level raw data in the dedicated cache area of ​​the vehicle gateway is transmitted to the vehicle mobile terminal. The central controller integrates the fault levels of all controllers and synthesizes a fault flag bit, which is then transmitted to the vehicle gateway. After receiving the fault flag bit, the vehicle gateway extracts the millisecond-level raw data ahead of the fault trigger time from the dedicated cache area according to the timestamp, and continues to store the millisecond-level raw data after the fault trigger time. The two data segments are packaged and transmitted to the vehicle mobile terminal via Ethernet. The vehicle mobile terminal uploads the received millisecond-level raw data packets to the vehicle data cloud platform, and at the same time, the vehicle terminal uploads the diagnostic fault codes when the fault is triggered to the vehicle data cloud platform. The vehicle data cloud platform parses the received millisecond-level raw data packets and fault codes before and after the fault triggering time, retrieves the corresponding related scenario data according to the fault scenario signal requirement list, and realizes the data playback and display of related scenarios when the fault occurs.

2. The cloud-based intelligent diagnostic method for vehicle faults as described in claim 1, characterized in that, The vehicle gateway samples the regular embedded signal according to the minimum resolution frequency required by the vehicle data cloud platform, and then forwards it to the vehicle mobile terminal via Ethernet. The vehicle mobile terminal classifies, reassembles, packages, and stores the regular embedded data, and then uploads it to the vehicle data cloud platform according to the highest resolution frequency required by the vehicle data cloud platform.

3. The cloud-based intelligent diagnostic method for vehicle faults as described in claim 1, characterized in that, If multiple faults coexist on the vehicle side, the vehicle gateway only extracts and transmits the raw data in milliseconds of the time before and after the first fault is triggered.

4. The cloud-based intelligent diagnostic method for vehicle faults as described in claim 1, characterized in that, The dedicated cache area is a fixed area in the vehicle gateway storage space that is independent of the regular data storage area. The millisecond-level raw data in the dedicated cache area is only transmitted from the vehicle gateway to the vehicle mobile terminal when the fault flag is triggered at the vehicle end. It is not transmitted in real time when there is no fault.

5. The cloud-based intelligent diagnostic method for vehicle faults as described in claim 1, characterized in that, When the vehicle data cloud platform performs comprehensive analysis of fault scenarios, it first verifies the consistency and matching relationship between fault codes and fault levels, then analyzes the corresponding fault scenarios, subdivides the scenarios according to the fault type, and retrieves the corresponding scenario signals.

6. The cloud-based intelligent diagnosis method for vehicle faults as described in claim 1, characterized in that, When the fault is an insulation fault, the vehicle data cloud platform subdivides the insulation fault scenario into charging insulation scenario and discharging / driving insulation scenario. In the charging insulation scenario, the charging connection signal and insulation resistance signal are retrieved and the relationship between the two is displayed. The handling suggestion is to replace the charging pile and try to recharge. In the discharging / driving insulation scenario, the gear information, vehicle speed signal, and insulation resistance signal are retrieved and the relationship between the vehicle speed and insulation resistance is displayed. The handling suggestion is to contact the corresponding service station of the vehicle for rescue and inspection.

7. A cloud-based intelligent diagnostic system for vehicle faults, characterized in that, include: The vehicle gateway is used to store millisecond-level raw data of the vehicle in a dedicated cache area and transmit the millisecond-level raw data in the dedicated cache area to the vehicle mobile terminal. The central controller is used to integrate the fault levels of all controllers, synthesize fault flag bits, and transmit the fault flag bits to the vehicle gateway; The vehicle gateway is used to extract millisecond-level raw data prior to the fault trigger time from a dedicated cache area after receiving the fault flag bit, and at the same time continue to store millisecond-level raw data after the fault trigger time. The two data segments are packaged and transmitted to the vehicle mobile terminal via Ethernet. The vehicle mobile terminal is used to upload the received millisecond-level raw data packets to the vehicle data cloud platform. At the same time, the vehicle terminal also uploads the diagnostic fault codes when the fault is triggered to the vehicle data cloud platform. The vehicle data cloud platform is used to parse the received millisecond-level raw data packets and the fault codes before and after the fault triggering time, retrieve the corresponding related scenario data according to the fault scenario signal requirement list, and realize the data playback and display of related scenarios when the fault occurs.

8. An electronic device, characterized in that, It includes a memory and a processor, as well as computer instructions stored in the memory and running on the processor, which, when executed by the processor, perform the method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, Used to store computer instructions, which, when executed by a processor, perform the method described in any one of claims 1-6.

10. A vehicle, characterized in that, The vehicle fault cloud-based intelligent diagnosis method as described in any one of claims 1-6 is adopted.

Images