Vehicle diagnosis method and device, vehicle and storage medium
By receiving vehicle tracking signals to acquire heterogeneous data for fault analysis, the problem of easy omissions and data dispersion in manual recording during vehicle dynamic road testing is solved, achieving efficient automated diagnosis and defect reproduction.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHERY AUTOMOBILE CO LTD
- Filing Date
- 2026-01-12
- Publication Date
- 2026-05-05
AI Technical Summary
During dynamic road testing of a vehicle, testers find it difficult to accurately capture sporadic and transient functional anomalies, making it difficult to reproduce defects and locate root causes. Existing technologies rely on manual recording, which is prone to missing key information, and the data is stored in a scattered manner with a cumbersome analysis process, resulting in low efficiency.
By receiving vehicle tracking signals, acquiring heterogeneous data and encapsulating the data based on timestamps, performing fault analysis and diagnosis, generating diagnostic data, and uploading it to a preset terminal, automated diagnosis is achieved.
It improved the defect reproduction rate and recording efficiency, reduced omissions in manual recording and data dispersion, and improved the efficiency of vehicle software quality verification.
Smart Images
Figure CN121979767A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of vehicle technology, and in particular to a vehicle diagnostic method, apparatus, vehicle, and storage medium. Background Technology
[0002] During dynamic road testing of the vehicle, testers frequently encounter sporadic and transient functional anomalies, such as unresponsive voice commands, malfunctioning window controls, and frozen central control interfaces. These problems are often difficult to reproduce and involve the collaboration of multiple systems. If the complete context cannot be accurately captured when the problem occurs, it will greatly increase the difficulty of subsequent reproduction and root cause localization, seriously affecting the efficiency of vehicle software quality verification and the R&D iteration cycle.
[0003] The test defects recorded by manual recording or fragmented logs in the relevant technologies have the following defects: (1) Road test problem recording relies on manual notes, which is easy to miss key information; (2) Bus data, host logs and video images are stored in a scattered manner, making it difficult to correlate and analyze them afterward; (3) The defect submission process is cumbersome and requires manual data integration, which is inefficient. Therefore, there is an urgent need for an intelligent vehicle testing method that can replace manual recording and achieve high-precision automatic diagnosis and reporting. Summary of the Invention
[0004] This application provides a vehicle diagnostic method, device, vehicle, and storage medium to solve the problems of easy omission of defects in road tests, scattered and difficult-to-connect data, and cumbersome and inefficient process when relying on manual recording of road test defects, thereby improving the defect reproduction rate and recording efficiency.
[0005] The first aspect of this application provides a vehicle diagnostic method, comprising the following steps: Determine whether a vehicle's signal has been received; If the dot signal is received, the heterogeneous data of the vehicle is obtained based on the dot signal, and the heterogeneous data is encapsulated based on the timestamp of the dot signal to obtain the original data. Fault analysis is performed based on the heterogeneous data to obtain fault analysis results. The fault analysis results and the original data are then encapsulated to obtain diagnostic data, which is then uploaded to a preset terminal.
[0006] Optionally, in some embodiments, the heterogeneous data includes at least one of communication data, log data, video data, and audio data. The fault analysis result is obtained by performing fault analysis based on the heterogeneous data, including: The audio data is subjected to speech recognition to obtain a text description. The text description is then semantically parsed based on a preset rule engine to obtain fault information, which includes the current fault type. Based on the current fault type, at least one type of data to be analyzed is determined from the heterogeneous data, and fault diagnosis is performed based on the at least one type of data to be analyzed to obtain the fault analysis result.
[0007] Optionally, in some embodiments, the step of determining at least one piece of data to be analyzed from the heterogeneous data according to the current fault type, and performing fault diagnosis based on the at least one piece of data to be analyzed to obtain the fault analysis result includes: When the fault type is a vehicle control fault, the data to be analyzed is determined to be communication data, and the communication data is input into a preset fault analysis model to obtain the fault analysis result; When the fault type is a system software fault, the data to be analyzed is determined to be log data, and the fault analysis result is determined based on the log data and a preset fault mode rule base.
[0008] Optionally, in some embodiments, after obtaining the fault analysis results by performing fault analysis based on the heterogeneous data, the process includes: The fault analysis results are processed to obtain fault features, which are then stored in a preset knowledge base. It is determined whether any type of fault sample in the preset knowledge base exceeds a preset sample threshold. If any type of fault sample in the preset knowledge base exceeds the preset sample threshold, an anomaly alert instruction is generated, and an anomaly alert is issued based on the anomaly alert instruction.
[0009] Optionally, in some embodiments, acquiring heterogeneous data of the vehicle based on the dotted signals includes: Determine the timestamp of the dot signal, and based on the timestamp, determine the first time range to the fourth time range; The heterogeneous data is obtained by acquiring communication data within the first time range, log data within the second time range, video data within the third time range, and audio data within the fourth time range.
[0010] A second aspect of this application provides a diagnostic device for a vehicle, comprising: The judgment module is used to determine whether a vehicle's marking signal has been received; The acquisition module is used to acquire heterogeneous data of the vehicle based on the marker signal when the marker signal is received, and to encapsulate the heterogeneous data based on the timestamp of the marker signal to obtain the original data. The diagnostic module is used to perform fault analysis based on the heterogeneous data to obtain fault analysis results, encapsulate the fault analysis results and the original data to obtain diagnostic data, and upload the diagnostic data to a preset terminal.
[0011] Optionally, in some embodiments, the heterogeneous data includes at least one of communication data, log data, video data, and audio data, and the diagnostic module includes: The recognition unit is used to perform speech recognition on the audio data to obtain a text description, and to perform semantic parsing on the text description based on a preset rule engine to obtain fault information, the fault information including the current fault type; The generation unit is configured to determine at least one type of data to be analyzed from the heterogeneous data according to the current fault type, and to perform fault diagnosis based on the at least one type of data to be analyzed to obtain the fault analysis result.
[0012] Optionally, in some embodiments, the generation unit includes: The first determining subunit is used to determine that the data to be analyzed is communication data when the fault type is a vehicle control fault, and input the communication data into a preset fault analysis model to obtain the fault analysis result; The second determining subunit is used to determine that the data to be analyzed is log data when the fault type is a system software fault, and to determine the fault analysis result based on the log data and a preset fault mode rule base.
[0013] Optionally, in some embodiments, after obtaining fault analysis results by performing fault analysis based on the heterogeneous data, the diagnostic module includes: The processing unit is used to process the fault analysis results to obtain fault features, store the fault features in a preset knowledge base, and determine whether there are any fault samples of any type in the preset knowledge base that exceed a preset sample threshold. The reminder unit is used to generate an abnormal reminder instruction when any type of fault sample in the preset knowledge base exceeds a preset sample threshold, and to issue an abnormal reminder based on the abnormal reminder instruction.
[0014] Optionally, in some embodiments, the acquisition module includes: A determining unit is used to determine the timestamp of the dot signal and, based on the timestamp, determine a first time range to a fourth time range; The acquisition unit is used to acquire communication data within the first time range, log data within the second time range, video data within the third time range, and audio data within the fourth time range to obtain the heterogeneous data.
[0015] A third aspect of this application provides a vehicle, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the vehicle diagnostic method as described in the above embodiments.
[0016] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the vehicle diagnostic method as described in the above embodiments.
[0017] Therefore, by determining whether a vehicle's tracking signal is received, if so, heterogeneous data about the vehicle is acquired based on the tracking signal. This heterogeneous data is then encapsulated using the tracking signal's timestamp to obtain raw data. Fault analysis is performed based on this heterogeneous data to obtain fault analysis results. The fault analysis results and raw data are then encapsulated to obtain diagnostic data, which is uploaded to a preset terminal. This solves the problems of easily overlooked defects, scattered and difficult-to-correlate data, and cumbersome and inefficient processes associated with manually recording road test defects, thus improving defect reproducibility and recording efficiency.
[0018] Additional aspects and advantages of this application 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 this application. Attached Figure Description
[0019] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart of a vehicle diagnostic method provided according to an embodiment of this application; Figure 2 This is a schematic diagram illustrating the acquisition of heterogeneous data according to an embodiment of this application; Figure 3 This is a schematic diagram illustrating the principle of a vehicle diagnostic method according to an embodiment of this application; Figure 4 This is a block diagram of a vehicle diagnostic device provided according to an embodiment of this application; Figure 5 This is a structural schematic diagram of a vehicle provided according to an embodiment of this application. Detailed Implementation
[0020] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.
[0021] The following description, with reference to the accompanying drawings, describes a vehicle diagnostic method, apparatus, vehicle, and storage medium according to embodiments of this application. Addressing the problems mentioned in the background art, such as the ease of omission of defects during road tests due to manual recording, the difficulty in correlating scattered data, and the cumbersome and inefficient process, this application provides a vehicle diagnostic method. In this method, it is determined whether a vehicle's data tracking signal is received. If a data tracking signal is received, heterogeneous data of the vehicle is acquired based on the data tracking signal. The heterogeneous data is then encapsulated based on the timestamp of the data tracking signal to obtain raw data. Fault analysis is performed based on the heterogeneous data to obtain fault analysis results. The fault analysis results and raw data are then encapsulated to obtain diagnostic data, which is then uploaded to a preset terminal. This solves the problems of easy omission of defects during road tests due to manual recording, the difficulty in correlating scattered data, and the cumbersome and inefficient process, thereby improving defect reproducibility and recording efficiency.
[0022] Specifically, Figure 1 This is a schematic flowchart illustrating a vehicle diagnostic method provided in an embodiment of this application.
[0023] like Figure 1 As shown, the diagnostic method for this vehicle includes the following steps: In step S101, it is determined whether a vehicle's marking signal has been received.
[0024] The dot signal is a high-precision time stamp signal that is actively triggered by the testers when an anomaly is detected. This signal contains a precise timestamp and serves as a reference anchor point for subsequent multi-source data acquisition and analysis.
[0025] Specifically, this application embodiment uses a vehicle-customized USB (Universal Serial Bus) button device (with a built-in high-precision clock chip). When pressed, it sends a dot signal to the host. If testers observe functional abnormalities during road testing (such as no voice response, windows not moving, etc.), they will press a dedicated physical button installed in the cockpit. This button is a hardware device independent of the in-vehicle infotainment system and is typically connected to the diagnostic host via USB. Once pressed, the button immediately generates a dot signal with a high-precision timestamp (e.g., microsecond level) and sends it to the diagnostic system. The system continuously polls or interrupts listening for this signal input. Once a valid dot signal is detected, it is determined that a dot signal has been received, and the subsequent data acquisition and analysis process begins immediately. This design ensures that the diagnostic process can still be reliably triggered even in extreme scenarios such as a black screen, system freeze, or touch failure.
[0026] In step S102, if a dot signal is received, heterogeneous data of the vehicle is obtained based on the dot signal, and the heterogeneous data is encapsulated based on the timestamp of the dot signal to obtain the original data.
[0027] Furthermore, in some embodiments, acquiring heterogeneous vehicle data based on the dotted signals includes: determining the timestamp of the dotted signals; determining a first time range to a fourth time range based on the timestamps; acquiring communication data within the first time range, log data within the second time range, video data within the third time range, and audio data within the fourth time range to obtain heterogeneous data.
[0028] Heterogeneous data refers to various types of vehicle operation data with different sources, formats, and structures, including communication data, log data, video data, and audio data. Communication data mainly refers to vehicle control signals transmitted via the CAN bus. Log data refers to text-based operation logs output by the vehicle operating system. Video data is a sequence of images recorded by the in-vehicle camera, used to record user operations, screen display status, and driving environment. Audio data is voice signals collected by the microphone, including commands issued by the test personnel and voice feedback broadcast by the system. The first to fourth time ranges correspond to the optimal acquisition windows for different data types, all set based on the timestamp T0.
[0029] Specifically, such as Figure 2 As shown, after receiving the tracking signal, the system first extracts the high-precision timestamp T0 it carries. Due to the different generation mechanisms and analysis requirements of different data types, the system configures an independent time window for each type of data. Since communication data reflects changes in vehicle status and needs to capture both steady-state and abnormal moments before a problem occurs, a first time range (e.g., T0) is used. (60 seconds to T0); Log data may only output error messages after the problem is triggered, therefore a second time range (e.g., T0) is used. The video data, ranging from 60 seconds to T0+60 seconds, covers the complete context before and after the problem. It is primarily used to trace user actions and interface responses, typically requiring only the segment preceding the problem, and employs a third time range (e.g., T0). (60 seconds to T0); audio data should record the tester's instructions and the system's response. It is more reasonable to start recording from the time of the marker, and a fourth time range (such as T0 to T0+30 seconds) should be used.
[0030] In actual execution, after the relevant technology triggers the button to send a dot signal, microphone recording is started, and the system recording interface is called to automatically execute the following based on the dot timestamp T0: defdata_capture(T0): can_data=get_can_data(T0-60s,T0)# Capture bus data for the previous minute; log=extract_host_log(T0-60s,T0+60s)#Host log (last and last 1 minute); video=clip_video(T0-60s,T0) # Clip the first minute of video; audio=record_audio(T0,T0+30s)# Record the next 30 seconds of audio.
[0031] Based on these preset windows, the system extracts data for the corresponding time period from the buffers of each data source, aligns the data with T0 as the anchor point, and finally packages the four types of data into a structured raw data packet to ensure that all evidence is strictly consistent in the time dimension.
[0032] In step S103, fault analysis is performed based on heterogeneous data to obtain fault analysis results, the fault analysis results and raw data are encapsulated to obtain diagnostic data, and the diagnostic data is uploaded to a preset terminal.
[0033] Optionally, in some embodiments, the heterogeneous data includes at least one of communication data, log data, video data, and audio data. Fault analysis based on the heterogeneous data is used to obtain fault analysis results, including: performing speech recognition on the audio data to obtain a text description; performing semantic parsing on the text description based on a preset rule engine to obtain fault information, the fault information including the current fault type; determining at least one type of data to be analyzed from the heterogeneous data based on the current fault type; and performing fault diagnosis based on the at least one type of data to be analyzed to obtain fault analysis results.
[0034] Specifically, in combination Figure 3 As shown, the system first performs speech recognition on the audio data. For example, after waking up the voice assistant and saying "Navigate to the Temple of Heaven," the vehicle route planning is successful, but the voice prompt says "I don't know this skill," automatically generating a title like "Voice Navigation to the Temple of Heaven," which executes successfully but the response is incorrect. Then, it outputs a structured bug description (title + phenomenon + triggering conditions + steps + actual result). The rule engine extracts structured fault information from this description, most importantly determining the current fault type. Based on this type, the system dynamically selects the subsequent analysis path: if it's a vehicle control issue, it focuses on communication data, using DBC parsing and anomaly detection models to determine if ECU signals are normal; if it's a system software issue, it analyzes log data, using a fault mode rule base to match features such as crashes, timeouts, or permission errors. After completing the deep diagnosis, the system packages the generated fault analysis results and the original heterogeneous data into diagnostic data and automatically uploads it to a preset terminal, completing the defect reporting.
[0035] Furthermore, in some embodiments, at least one type of data to be analyzed is determined from heterogeneous data according to the current fault type, and fault diagnosis is performed based on the at least one type of data to be analyzed to obtain fault analysis results, including: when the fault type is a vehicle control type fault, the data to be analyzed is determined to be communication data, and the communication data is input into a preset fault analysis model to obtain fault analysis results; when the fault type is a system software type fault, the data to be analyzed is determined to be log data, and the fault analysis results are determined based on the log data and a preset fault mode rule base.
[0036] Among them, vehicle control faults refer to problems involving abnormal execution of vehicle body hardware functions, such as windows not being able to be raised or lowered, air conditioning not starting, seat heating malfunction, etc., which are usually related to electronic control units (ECUs) or bus signals; system software faults refer to abnormalities at the level of intelligent cockpit operating system or application software, such as voice service crashes, central control interface freezing, application crashes, etc.; the preset fault mode rule base is a set of predefined structured diagnostic rules, each rule contains keywords, abnormal patterns, matching conditions and corresponding root cause conclusions, which are used to perform pattern matching on log content.
[0037] Specifically, after completing voice semantic parsing and determining the current fault type, the system no longer performs indiscriminate analysis on all heterogeneous data. Instead, it adopts an on-demand diagnostic strategy, dynamically selecting the most relevant data sources for in-depth processing. When the fault type is a vehicle control fault (such as "saying to turn on the air conditioner but no response"), the system determines that the problem may stem from an ECU not responding or abnormal bus signals. Therefore, it designates the communication data as the data to be analyzed and inputs it into a preset fault analysis model. This model parses the original CAN message based on the DBC file, reconstructs the physical signals (such as "air conditioner request = 0"), and then combines it with the normal behavior model to determine whether there are signal missing, delay, or logical contradictions, thereby outputting conclusions such as "the air conditioner control module did not receive a valid request."
[0038] When the fault type is a system software fault (such as "no response after voice wake-up"), the system focuses on log data and uses a pre-defined fault pattern rule base for matching analysis. For example, the rule base includes "if the log contains 'FATALEXCEPTION' and also includes 'VoiceService,' then it is determined that the voice service has crashed." The system scans the log line by line, matching keywords and stack patterns, ultimately locating the specific software module and exception type, such as "VoiceService exited due to a null pointer exception." This achieves precise scheduling of diagnostic resources, avoids redundant calculations on irrelevant data, and improves analysis efficiency and accuracy. For example, intelligent analysis of bus data: Triggering conditions: This feature is triggered when the issue type involves cockpit-related vehicle controls (such as window controls and air conditioning controls). ifproblem_type=="VEHICLE_CONTROL": dbc = load_dbc_file() # Load the DBC protocol for the current vehicle model; signals = analyze_signals(can_data, dbc) # Analyze the physical values of the signal; faulty_ecu=detect_anomaly(signals) # Detect abnormal ECUs and signals based on machine learning; generate_report(faulty_ecu) # Output signal analysis report.
[0039] Automatic Defect Reporting Management System Data Packaging: Associate the following files with the same defect ID: Bug_20240807_142305# Packaged file; report.txt # AI-generated defect description; can_data.blf#Bus data (first minute); ICC_log.log# Host log (last and last 1 minute); video.mp4# Operation video clip; record.mp3 # Recording a description of the problem.
[0040] API Auto-Submission: Create an Issue and Upload Attachments via API Therefore, the defect report generated by this application embodiment not only includes textual conclusions, but also original video, audio, logs and CAN data. Developers can directly locate the problem without reproducing it, which greatly improves diagnostic efficiency.
[0041] Optionally, in some embodiments, after obtaining the fault analysis result by performing fault analysis based on heterogeneous data, the process includes: processing the fault analysis result to obtain fault features, storing the fault features in a preset knowledge base, determining whether there are any fault samples of any type in the preset knowledge base that exceed a preset sample threshold; if there are any fault samples of any type in the preset knowledge base that exceed the preset sample threshold, generating an abnormality reminder instruction, and providing an abnormality reminder based on the abnormality reminder instruction.
[0042] The preset knowledge base is used to store historical fault characteristics and their corresponding sample counts; the preset sample threshold is a pre-set minimum sample count, used to determine whether a certain type of fault has statistical significance and can trigger higher-order processing.
[0043] Specifically, the system automatically extracts discriminative fault features from the fault analysis results. These features are stored in a preset knowledge base and associated with a counter for the corresponding fault type, incrementing the number of fault samples for that type by 1. The system then checks if the number of samples for any fault type in the knowledge base exceeds a preset threshold. If so, the system considers the problem to have evolved from an occasional isolated case into a typical or recurring defect, and immediately generates an anomaly alert. This alert can trigger various subsequent actions: for example, pushing a high-priority alarm to the quality team, indicating that "air conditioning control failures have been occurring frequently recently"; or further, activating the fault feature as a real-time monitoring rule for automatic matching of new data streams during subsequent road tests, achieving proactive defect discovery without manual intervention.
[0044] In actual execution, for each new defect, AI extracts key features (such as "steering wheel vibration + 80km / h + EPS signal out of tolerance"). When the sample size > N, the real-time analysis engine is started: # Real-time monitoring logic while testing: if match_knowledge_base(video, audio, can_data): # Match historical problem patterns; auto_create_issue() # Automatically create defect reports.
[0045] According to the vehicle diagnostic method proposed in this application, the method determines whether a vehicle tracking signal is received. If a tracking signal is received, heterogeneous data of the vehicle is obtained based on the tracking signal. The heterogeneous data is then encapsulated based on the timestamp of the tracking signal to obtain raw data. Fault analysis is performed based on the heterogeneous data to obtain fault analysis results. The fault analysis results and raw data are then encapsulated to obtain diagnostic data, which is then uploaded to a preset terminal. This solves the problems of easy omissions, scattered and difficult-to-correlate data, and cumbersome and inefficient processes associated with manually recording road test defects, and can improve defect reproducibility and recording efficiency.
[0046] Next, a diagnostic device for a vehicle according to an embodiment of this application is described with reference to the accompanying drawings.
[0047] Figure 4 A block diagram of a vehicle diagnostic device according to an embodiment of this application.
[0048] like Figure 4 The diagnostic device 10 for the vehicle includes: a judgment module 100, an acquisition module 200, and a diagnostic module 300.
[0049] The judgment module 100 is used to determine whether a vehicle's marking signal has been received.
[0050] The acquisition module 200 is used to acquire heterogeneous data of the vehicle based on the received dot signal, and encapsulate the heterogeneous data based on the timestamp of the dot signal to obtain the original data.
[0051] The diagnostic module 300 is used to perform fault analysis based on heterogeneous data to obtain fault analysis results, encapsulate the fault analysis results and raw data to obtain diagnostic data, and upload the diagnostic data to a preset terminal.
[0052] Optionally, in some embodiments, the heterogeneous data includes at least one of communication data, log data, video data, and audio data, and the diagnostic module 300 includes an identification unit and a generation unit.
[0053] The recognition unit is used to perform speech recognition on audio data to obtain text descriptions, and to perform semantic parsing on the text descriptions based on a preset rule engine to obtain fault information, including the current fault type.
[0054] The generation unit is used to determine at least one type of data to be analyzed from heterogeneous data according to the current fault type, and to perform fault diagnosis based on the at least one type of data to be analyzed to obtain fault analysis results.
[0055] Optionally, in some embodiments, the generating unit includes: a first determining subunit and a second determining subunit.
[0056] The first determining subunit is used to determine the data to be analyzed as communication data when the fault type is a vehicle control fault, and input the communication data into a preset fault analysis model to obtain the fault analysis result.
[0057] The second determination subunit is used to determine the data to be analyzed as log data when the fault type is a system software fault, and to determine the fault analysis result based on the log data and a preset fault mode rule base.
[0058] Optionally, in some embodiments, after obtaining the fault analysis result by performing fault analysis based on heterogeneous data, the diagnostic module 300 includes: a processing unit and an alert unit.
[0059] The processing unit is used to process the fault analysis results to obtain fault features, store the fault features in a preset knowledge base, and determine whether there are any fault samples of any type in the preset knowledge base that exceed a preset sample threshold.
[0060] The reminder unit is used to generate an abnormal reminder instruction when the number of fault samples of any type in the preset knowledge base exceeds a preset sample threshold, and to issue an abnormal reminder based on the abnormal reminder instruction.
[0061] Optionally, in some embodiments, the acquisition module 100 includes a determining unit and an acquisition unit.
[0062] The determining unit is used to determine the timestamp of the dot signal and, based on the timestamp, to determine the first time range to the fourth time range.
[0063] The acquisition unit is used to acquire communication data within a first time range, log data within a second time range, video data within a third time range, and audio data within a fourth time range to obtain heterogeneous data.
[0064] It should be noted that the foregoing explanation of the vehicle diagnostic method embodiment also applies to the vehicle diagnostic device of this embodiment, and will not be repeated here.
[0065] The vehicle diagnostic device proposed in this application determines whether a vehicle tracking signal is received. If a tracking signal is received, heterogeneous data of the vehicle is acquired based on the tracking signal, and the heterogeneous data is encapsulated based on the timestamp of the tracking signal to obtain raw data. Fault analysis is performed based on the heterogeneous data to obtain fault analysis results. The fault analysis results and raw data are encapsulated to obtain diagnostic data, which is then uploaded to a preset terminal. This solves the problems of easy omission of defects, scattered and difficult-to-correlate data, and cumbersome and inefficient processes associated with manually recording road test defects, thus improving defect reproducibility and recording efficiency. Figure 5 This application provides a schematic diagram of the structure of a vehicle. The vehicle may include: The memory 501, the processor 502, and the computer program stored on the memory 501 and capable of running on the processor 502.
[0066] When the processor 502 executes the program, it implements the vehicle diagnostic method provided in the above embodiments.
[0067] Furthermore, the vehicle also includes: Communication interface 503 is used for communication between memory 501 and processor 502.
[0068] The memory 501 is used to store computer programs that can run on the processor 502.
[0069] The memory 501 may include high-speed RAM (Random Access Memory) memory, and may also include non-volatile memory, such as at least one disk storage.
[0070] If the memory 501, processor 502, and communication interface 503 are implemented independently, then the communication interface 503, memory 501, and processor 502 can be interconnected via a bus to complete communication between them. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.
[0071] Optionally, in a specific implementation, if the memory 501, processor 502, and communication interface 503 are integrated on a single chip, then the memory 501, processor 502, and communication interface 503 can communicate with each other through an internal interface.
[0072] The processor 502 may be a CPU (Central Processing Unit), an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of this application.
[0073] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the vehicle diagnostic method described above.
[0074] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.
[0075] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.
[0076] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.
[0077] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (FPGAs), field-programmable gate arrays (FPGAs), etc.
[0078] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.
[0079] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.
Claims
1. A method for diagnosing a vehicle, characterized in that, Includes the following steps: Determine whether a vehicle's signal has been received; If the dot signal is received, the heterogeneous data of the vehicle is obtained based on the dot signal, and the heterogeneous data is encapsulated based on the timestamp of the dot signal to obtain the original data. Fault analysis is performed based on the heterogeneous data to obtain fault analysis results. The fault analysis results and the original data are then encapsulated to obtain diagnostic data, which is then uploaded to a preset terminal.
2. The method according to claim 1, characterized in that, The heterogeneous data includes at least one of communication data, log data, video data, and audio data. Fault analysis results are obtained by performing fault analysis based on the heterogeneous data, including: The audio data is subjected to speech recognition to obtain a text description. The text description is then semantically parsed based on a preset rule engine to obtain fault information, which includes the current fault type. Based on the current fault type, at least one type of data to be analyzed is determined from the heterogeneous data, and fault diagnosis is performed based on the at least one type of data to be analyzed to obtain the fault analysis result.
3. The method according to claim 2, characterized in that, The step of determining at least one piece of data to be analyzed from the heterogeneous data according to the current fault type, and performing fault diagnosis based on the at least one piece of data to be analyzed to obtain the fault analysis result includes: When the fault type is a vehicle control fault, the data to be analyzed is determined to be communication data, and the communication data is input into a preset fault analysis model to obtain the fault analysis result; When the fault type is a system software fault, the data to be analyzed is determined to be log data, and the fault analysis result is determined based on the log data and a preset fault mode rule base.
4. The method according to claim 1, characterized in that, After obtaining the fault analysis results by performing fault analysis based on the heterogeneous data, the process includes: The fault analysis results are processed to obtain fault features, which are then stored in a preset knowledge base. It is determined whether any type of fault sample in the preset knowledge base exceeds a preset sample threshold. If any type of fault sample in the preset knowledge base exceeds the preset sample threshold, an anomaly alert instruction is generated, and an anomaly alert is issued based on the anomaly alert instruction.
5. The method according to claim 1, characterized in that, The process of acquiring heterogeneous data of the vehicle based on the dotted signals includes: Determine the timestamp of the dot signal, and based on the timestamp, determine the first time range to the fourth time range; The heterogeneous data is obtained by acquiring communication data within the first time range, log data within the second time range, video data within the third time range, and audio data within the fourth time range.
6. A diagnostic device for a vehicle, characterized in that, include: The judgment module is used to determine whether a vehicle's marking signal has been received; The acquisition module is used to acquire heterogeneous data of the vehicle based on the marker signal when the marker signal is received, and to encapsulate the heterogeneous data based on the timestamp of the marker signal to obtain the original data. The diagnostic module is used to perform fault analysis based on the heterogeneous data to obtain fault analysis results, encapsulate the fault analysis results and the original data to obtain diagnostic data, and upload the diagnostic data to a preset terminal.
7. The apparatus according to claim 6, characterized in that, The heterogeneous data includes at least one of communication data, log data, video data, and audio data; the diagnostic module includes: The recognition unit is used to perform speech recognition on the audio data to obtain a text description, and to perform semantic parsing on the text description based on a preset rule engine to obtain fault information, the fault information including the current fault type; The generation unit is configured to determine at least one type of data to be analyzed from the heterogeneous data according to the current fault type, and to perform fault diagnosis based on the at least one type of data to be analyzed to obtain the fault analysis result.
8. The apparatus according to claim 7, characterized in that, The generation unit includes: The first determining subunit is used to determine that the data to be analyzed is communication data when the fault type is a vehicle control fault, and input the communication data into a preset fault analysis model to obtain the fault analysis result; The second determining subunit is used to determine that the data to be analyzed is log data when the fault type is a system software fault, and to determine the fault analysis result based on the log data and a preset fault mode rule base.
9. A vehicle, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the diagnostic method for a vehicle as described in any one of claims 1-5.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the diagnostic method for the vehicle as described in any one of claims 1-5.