Method for diagnosing failure of vehicle, vehicle, storage medium, and program product

Abstract

This application discloses a vehicle fault diagnosis method, a vehicle, a storage medium, and a program product. The method includes: when the vehicle meets preset trigger conditions, switching the data acquisition mode of the in-vehicle system from a first data acquisition mode to a second data acquisition mode, and acquiring initial fault data in the second data acquisition mode, wherein the data acquisition frequency of the second data acquisition mode is higher than that of the first data acquisition mode; the preset trigger conditions represent the conditions used to trigger fault diagnosis of the vehicle; outputting prompt information and receiving fault description information corresponding to the initial fault data, wherein the prompt information is used to prompt input of the fault description information; sending the initial fault data and fault description information to a cloud server, and receiving the vehicle fault diagnosis results returned by the cloud server. This application solves the technical problem of low accuracy in vehicle fault diagnosis in related technologies.

Description

Technical Field

[0001] This application relates to the field of vehicles, and more specifically, to a method for diagnosing vehicle faults, a vehicle, a storage medium, and a program product. Background Technology

[0002] In related technologies, vehicle fault diagnosis is mostly based on the driver's verbal description. However, due to the driver's lack of professional technical skills, their verbal description is often subjective and general, making it difficult to accurately locate specific vehicle faults, which in turn leads to a low accuracy rate in vehicle fault diagnosis in related technologies.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This application provides a vehicle fault diagnosis method, a vehicle, a storage medium, and a program product to at least solve the technical problem of low accuracy in vehicle fault diagnosis in related technologies.

[0005] According to one aspect of the embodiments of this application, a vehicle fault diagnosis method is provided, applied to an in-vehicle system deployed in a vehicle, comprising: when the vehicle meets preset triggering conditions, switching the data acquisition mode of the in-vehicle system from a first data acquisition mode to a second data acquisition mode, and acquiring initial fault data in the second data acquisition mode, wherein the data acquisition frequency of the second data acquisition mode is higher than that of the first data acquisition mode, and the preset triggering conditions represent conditions for triggering fault diagnosis of the vehicle; outputting prompt information and receiving fault description information corresponding to the initial fault data, wherein the prompt information is used to prompt input of fault description information; sending the initial fault data and fault description information to a cloud server, and receiving the vehicle fault diagnosis result returned by the cloud server, wherein the fault diagnosis result is determined by the cloud server based on the initial fault data and fault description information.

[0006] Furthermore, the method further includes: upon receiving a trigger signal, judging the trigger signal to obtain a signal judgment result, wherein the signal judgment result is used to indicate whether the trigger signal meets a preset trigger mode; upon receiving a sensor signal from a sensor, detecting the sensor signal to obtain a sensor signal detection result, wherein the sensor signal detection result is used to indicate whether the sensor signal meets a preset abnormal condition; and if the signal judgment result indicates that the trigger signal meets the preset trigger mode, and / or the sensor signal detection result indicates that the sensor signal meets the preset abnormal condition, determining that the vehicle meets the preset trigger condition.

[0007] Further, the trigger signal is judged to obtain the signal judgment result, including: obtaining the timing characteristics and number of operations of the trigger signal, wherein the timing characteristics include the pressing duration and the interval between adjacent pressing, the pressing duration is used to represent the duration of a single pressing operation corresponding to the trigger signal, and the interval between adjacent pressing is used to represent the time interval between two adjacent pressing operations corresponding to the trigger signal; the trigger signal is judged based on the timing characteristics and the number of operations to determine the signal judgment result.

[0008] Further, the trigger signal is judged based on timing characteristics and the number of operations to determine the signal judgment result, including: judging based on the timing characteristics and the preset timing requirements in the preset trigger mode to obtain a timing judgment result, wherein the timing judgment result is used to indicate whether the timing characteristics meet the preset timing requirements; judging based on the number of operations and the preset number of operations in the preset trigger mode to obtain a number of operations judgment result, wherein the number of operations judgment result is used to indicate whether the number of operations meets the preset number of operations requirement; if the timing judgment result is that the timing characteristics meet the preset timing requirements and the number of operations judgment result is that the number of operations meets the preset number of operations requirement, the signal judgment result is determined to be that the trigger signal meets the preset trigger mode.

[0009] Furthermore, the data acquisition mode of the vehicle system is switched from the first data acquisition mode to the second data acquisition mode, and initial fault data is acquired in the second data acquisition mode, including: determining the moment when the vehicle meets the preset trigger conditions as the trigger moment; stopping the updating of the vehicle's operating data based on the trigger moment, and switching the data acquisition mode of the vehicle system from the first data acquisition mode to the second data acquisition mode; in the second data acquisition mode, acquiring the current vehicle operating data for a first preset duration before the trigger moment and a second preset duration after the trigger moment; and determining the current vehicle operating data as the initial fault data.

[0010] Furthermore, sending initial fault data and fault description information to the cloud server includes: encoding the fault description information to obtain encoded information; binding the encoded information, the vehicle's vehicle code, and the trigger time to generate comprehensive fault data; associating the comprehensive fault data with the initial fault data to obtain fault association data; and sending the fault association data to the cloud server.

[0011] Furthermore, the method also includes: performing differential calculations based on the initial fault data and the benchmark data model corresponding to the vehicle type to obtain difference data; and sending the difference data and fault description information to the cloud server.

[0012] According to another aspect of the embodiments of this application, a vehicle fault diagnosis method is also provided, applied to a cloud server, comprising: receiving initial fault data and fault description information sent by an in-vehicle system; performing feature extraction based on the initial fault data and fault description information to obtain fault features; determining the vehicle fault diagnosis result based on the fault features and the vehicle type corresponding to the vehicle; and sending the fault diagnosis result to the in-vehicle system.

[0013] Furthermore, based on the fault characteristics and the corresponding vehicle type, the fault diagnosis result of the vehicle is determined, including: based on the fault characteristics and vehicle type, determining the target fault handling method corresponding to the vehicle; and performing fault diagnosis on the vehicle based on the target fault handling method and the fault characteristics to obtain the fault diagnosis result.

[0014] According to another aspect of the embodiments of this application, a vehicle fault diagnosis device is provided, applied to an in-vehicle system. The in-vehicle system is deployed in a vehicle and includes: a data acquisition module, configured to switch the data acquisition mode of the in-vehicle system from a first data acquisition mode to a second data acquisition mode when the vehicle meets preset trigger conditions, and to acquire initial fault data in the second data acquisition mode, wherein the data acquisition frequency of the second data acquisition mode is higher than that of the first data acquisition mode, and the preset trigger conditions represent conditions for triggering fault diagnosis of the vehicle; a first transceiver module, configured to output prompt information and receive fault description information corresponding to the initial fault data, wherein the prompt information is used to prompt input of fault description information; and a second transceiver module, configured to send the initial fault data and fault description information to a cloud server and receive the vehicle fault diagnosis result returned by the cloud server, wherein the fault diagnosis result is determined by the cloud server based on the initial fault data and fault description information.

[0015] According to another aspect of the embodiments of this application, a vehicle fault diagnosis device is also provided, applied to a cloud server, comprising: a receiving module for receiving initial fault data and fault description information sent by an in-vehicle system; an extraction module for extracting features based on the initial fault data and fault description information to obtain fault features; a determining module for determining the vehicle fault diagnosis result based on the fault features and the vehicle type corresponding to the vehicle; and a sending module for sending the fault diagnosis result to the in-vehicle system.

[0016] According to another aspect of the embodiments of this application, a vehicle is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of this application when it runs.

[0017] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0018] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0019] According to another aspect of the embodiments of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods in various embodiments of this application.

[0020] According to another aspect of the embodiments of this application, a computer program is also provided, which, when executed by a processor, implements the methods of the various embodiments of this application.

[0021] In this application embodiment, a vehicle fault diagnosis method is proposed, applied to an in-vehicle system deployed in a vehicle. The method includes: when the vehicle meets preset triggering conditions, switching the data acquisition mode of the in-vehicle system from a first data acquisition mode to a second data acquisition mode, and acquiring initial fault data in the second data acquisition mode; then, outputting prompt information and receiving fault description information corresponding to the initial fault data; sending the initial fault data and fault description information to a cloud server, and receiving the vehicle fault diagnosis result returned by the cloud server. The vehicle fault diagnosis method proposed in this application firstly switches the data acquisition mode from a low-frequency first data acquisition mode to a high-frequency second data acquisition mode when the vehicle meets preset trigger conditions, and collects initial fault data. By activating high-density sampling only at the trigger, the key signal fluctuations at the time of fault occurrence are accurately located, avoiding invalid data redundancy and providing a real and complete temporal context for diagnosis. Secondly, it outputs prompt information and receives fault description information input by the driver. The acquisition of fault description information establishes a correspondence between the originally isolated electrical signals and the abnormal phenomena perceived by the driver, significantly enhancing the interpretability of the data. Finally, the initial fault data and fault description information are uploaded to a cloud server, and the diagnostic results returned are received. By utilizing the data processing and pattern recognition capabilities of the cloud server, and integrating objective waveforms and subjective descriptions for comprehensive judgment, the technical objective of improving the accuracy of fault diagnosis is achieved. This enables efficient and accurate identification of intermittent and difficult faults without fault codes, ultimately solving the technical problem of low vehicle fault diagnosis accuracy in related technologies. Attached Figure Description

[0022] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0023] Figure 1 This is a flowchart of a vehicle fault diagnosis method according to an embodiment of this application;

[0024] Figure 2 This is a flowchart of another vehicle fault diagnosis method according to an embodiment of this application;

[0025] Figure 3 This is a schematic diagram of the overall architecture of a vehicle fault diagnosis system according to an embodiment of this application;

[0026] Figure 4 This is a schematic diagram of the internal module composition of an in-vehicle connected terminal according to an embodiment of this application;

[0027] Figure 5 This is a flowchart of an optional vehicle fault diagnosis method according to an embodiment of this application;

[0028] Figure 6 This is a schematic diagram of a vehicle fault diagnosis device according to an embodiment of this application;

[0029] Figure 7 This is a schematic diagram of another vehicle fault diagnosis device according to an embodiment of this application. Detailed Implementation

[0030] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0031] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0032] According to an embodiment of this application, a method for diagnosing vehicle faults is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0033] Figure 1 This is a flowchart of a vehicle fault diagnosis method according to an embodiment of this application, such as... Figure 1 As shown, this method is applied to an in-vehicle system deployed in a vehicle, and the method includes the following steps:

[0034] Step S102: When the vehicle meets the preset trigger conditions, the data acquisition mode of the vehicle system is switched from the first data acquisition mode to the second data acquisition mode, and initial fault data is collected in the second data acquisition mode. The data acquisition frequency of the second data acquisition mode is higher than that of the first data acquisition mode. The preset trigger conditions are the conditions used to trigger fault diagnosis of the vehicle.

[0035] The aforementioned vehicles can refer to motor vehicles with electronic and electrical architectures, equipped with onboard communication modules and multi-bus systems. Vehicle types can include, but are not limited to, pure electric passenger vehicles, plug-in hybrid electric vehicles, and intelligent connected vehicles; the specific vehicle type needs to be determined based on the actual diagnostic target. The vehicle integrates multiple Electronic Control Units (ECUs), capable of signal interaction via buses such as Controller Area Network (CAN), Local Interconnect Network (LIN), or Ethernet, and can generate real-time operating data covering the powertrain, chassis system, body electronics, and intelligent assistance systems. The vehicles targeted in this application must possess remote communication capabilities (such as cellular (4G / 5G) communication modules) and data caching capabilities to support triggered acquisition and uploading of fault data, serving as the physical carrier for implementing the fault diagnosis method proposed in this application.

[0036] The aforementioned preset trigger conditions refer to a set of detectable and identifiable signal combinations pre-set to identify whether a vehicle has intermittent, difficult-to-diagnose faults. Preset trigger conditions may include, but are not limited to, manually operated trigger conditions and automatically detected system trigger conditions; the specific preset trigger conditions need to be determined based on actual needs. Preset trigger conditions can be used to determine whether to initiate high-density data acquisition, thereby avoiding the flood of invalid data.

[0037] The aforementioned in-vehicle system refers to a comprehensive processing system deployed inside a vehicle and integrated into an in-vehicle network terminal (T-Box) and an in-vehicle intelligent terminal (such as a central control display). The in-vehicle system may include, but is not limited to, an in-vehicle network terminal, an in-vehicle intelligent terminal, a bus monitoring module, an event trigger processing module, a ring buffer management module, a human-machine interaction module, and a communication management module. The specific in-vehicle system needs to be determined based on the actual vehicle type. The in-vehicle system is responsible for collecting key signals at low frequency under normal conditions and uploading them to the cloud. Simultaneously, when a preset trigger condition is detected, it controls the switching of the collection mode, locks historical data, collects high-density fault data, receives fault descriptions input by the user, and finally uploads the complete data packet to the cloud platform. It is the core execution unit for realizing the "local intelligent triggering + cloud collaborative analysis" architecture in this application.

[0038] The aforementioned data acquisition modes refer to a set of strategies configured by the in-vehicle system to sample, store, and upload vehicle signals to adapt to different operational needs. Data acquisition modes may include, but are not limited to, a first data acquisition mode, a second data acquisition mode, etc., and the specific data acquisition mode needs to be determined based on actual acquisition requirements. Data acquisition modes can be dynamically switched according to the current system state, which can be used to balance the conflict between the real-time performance and completeness of data acquisition and system resource consumption.

[0039] The aforementioned first data acquisition mode refers to the low-power, low-frequency acquisition strategy adopted by the in-vehicle system during normal vehicle operation. This first data acquisition mode can be used to continuously monitor the basic operating status of the vehicle without affecting its communication and computing load, thereby achieving remote status awareness and basic fault early warning.

[0040] The aforementioned second data acquisition mode refers to a high-precision, high-density acquisition strategy activated immediately upon detecting a preset trigger condition by the vehicle system. The data acquisition frequency of the second data acquisition mode is higher than that of the first data acquisition mode. The second data acquisition mode can be used to completely record the transient changes of key signals before and after a fault occurs, providing an analyzable high-resolution data context for subsequent diagnosis.

[0041] The aforementioned data acquisition frequency refers to the reciprocal of the time interval during which the onboard system samples the vehicle bus signals in a specific acquisition mode, measured in Hertz (Hz), representing the number of samples collected per second. The data acquisition frequency determines the temporal resolution of the data and is a core indicator for judging whether the system can capture transient faults.

[0042] For example, in the first data acquisition mode, the sampling frequency can be 1 Hz, which can only reflect the macroscopic trend of the signal and cannot identify millisecond-level anomalies. In the second data acquisition mode, the sampling frequency is no less than 50 Hz, and can reach 200 Hz, enabling the capture of typical intermittent fault characteristics such as minute signal fluctuations, voltage spikes, and communication error frames at intervals of 20 milliseconds to 10 milliseconds. This provides waveform data for expert diagnosis or artificial intelligence models (AI), which is the technical basis that distinguishes this application from traditional low-frequency monitoring schemes. The above values ​​are only examples; specific values ​​need to be determined according to actual needs and are not limited here.

[0043] In one optional embodiment, when the vehicle meets a preset trigger condition, the vehicle system switches the data acquisition mode from a first data acquisition mode to a second data acquisition mode. This switching behavior is directly in response to the fulfillment of the trigger condition, rather than being continuous or periodic. In the second data acquisition mode, the system performs data acquisition at a higher frequency than in the first data acquisition mode, thereby obtaining more intensive vehicle operating status information when the trigger event occurs. This high-frequency acquisition behavior is only started after the mode switch, and the increase in its acquisition density is directly due to the difference in the mode settings itself, rather than relying on additional hardware or external commands.

[0044] Step S104: Output a prompt message and receive the fault description information corresponding to the initial fault data. The prompt message is used to prompt the input of the fault description information.

[0045] The aforementioned prompts refer to interactive prompts proactively output by the vehicle system to the driver after detecting that initial fault data has been successfully collected and stored, guiding the driver to supplement the description of the fault phenomenon. The forms of these prompts may include, but are not limited to, visual prompts (such as a pop-up graphic prompt window on the in-vehicle smart terminal), voice prompts (voice announcements played through the in-vehicle audio system), and tactile prompts (seat vibrations or slight steering wheel shaking to remind the driver to input information when operating the steering wheel or pedals). The above examples are for illustrative purposes only; the specific form should be determined based on actual needs. These prompts can be used to encourage the driver to proactively provide supplementary information related to their subjective experience at the time of the fault.

[0046] The aforementioned fault description information can refer to unstructured or semi-structured text / voice / image information actively input by the driver after receiving a prompt, describing the fault phenomena perceived by the driver when the vehicle malfunctions. Fault description information serves as a crucial bridge connecting "sensor data" and "diagnostic conclusions," transforming the driver's experiential perception into machine-understandable semantic tags, greatly enhancing the cloud-based analysis system's ability to identify complex and hidden faults. Fault description information is a core element missing from traditional remote monitoring systems and is also the innovative foundation for achieving "human-machine collaborative diagnosis" in this application.

[0047] In one optional embodiment, by providing clear prompts to the driver, the driver is guided to actively input fault description information corresponding to the initial fault data, ensuring that the subjective perception information of the fault phenomenon can be effectively captured. Through the interactive interface of the in-vehicle intelligent terminal, the driver is prompted to provide supplementary descriptions of the abnormal behavior during the fault occurrence in the form of text, voice, images, or videos. This establishes a connection between objective vehicle operation data and human subjective perception, enhancing the completeness of fault information. This process does not rely on automatic system inference or preset templates, but rather on the driver freely providing descriptive content based on their own experience, supporting subsequent comprehensive cloud-based analysis of the fault's cause.

[0048] Step S106: Send initial fault data and fault description information to the cloud server, and receive the vehicle fault diagnosis results returned by the cloud server. The fault diagnosis results are determined by the cloud server based on the initial fault data and fault description information.

[0049] The aforementioned cloud server can refer to a remote computing and data processing platform deployed in an internet-distributed computing environment. The cloud server possesses high availability, large-capacity storage, parallel computing capabilities, and a multi-tenant service architecture, specifically designed to receive, store, and analyze fault data packets uploaded from multiple vehicles, and to perform comprehensive diagnosis based on artificial intelligence and expert rules. In this application, the cloud server, as the central system for fault diagnosis, establishes a bidirectional data interaction channel with the vehicle system through encrypted channels such as Hypertext Transfer Protocol Secure (HTTPS) and Transport Layer Security (TLS).

[0050] The aforementioned fault diagnosis results refer to structured conclusions generated by the cloud server after receiving initial fault data and fault description information uploaded by the vehicle, which are then comprehensively analyzed to explain the cause of the fault, locate the faulty component, and provide repair suggestions. Fault diagnosis results can be used to transform raw data and user descriptions into executable repair instructions, thereby changing the traditional inefficient repair model of "relying on experience + reproducing the fault + blindly replacing parts."

[0051] In one optional embodiment, the initial fault data generated by the in-vehicle system and the fault description information supplemented by the driver are sent together to a cloud server. The cloud server performs comprehensive processing based on these two types of information to form a diagnostic result for the vehicle fault and feeds the result back to the vehicle. The initial fault data includes high-density vehicle operating signals collected before and after the fault triggering time, while the fault description information is a subjective description of the phenomenon provided by the driver. These two data units, as independent but related, are transmitted completely to the cloud. The cloud server analyzes the correlation between these two types of uploaded information to output a fault diagnosis result, thus achieving a complete closed loop from data acquisition to diagnostic feedback. This process only initiates high-density data upload when a fault is triggered, avoiding the communication and storage burden caused by continuous transmission. Simultaneously, human-machine collaborative description significantly improves the diagnostic accuracy and efficiency of complex faults, effectively reducing maintenance costs and return rates.

[0052] In this application embodiment, a vehicle fault diagnosis method is proposed, applied to an in-vehicle system deployed in a vehicle. The method includes: when the vehicle meets preset triggering conditions, switching the data acquisition mode of the in-vehicle system from a first data acquisition mode to a second data acquisition mode, and acquiring initial fault data in the second data acquisition mode; then, outputting prompt information and receiving fault description information corresponding to the initial fault data; sending the initial fault data and fault description information to a cloud server, and receiving the vehicle fault diagnosis result returned by the cloud server. The vehicle fault diagnosis method proposed in this application firstly switches the data acquisition mode from a low-frequency first data acquisition mode to a high-frequency second data acquisition mode when the vehicle meets preset trigger conditions, and collects initial fault data. By activating high-density sampling only at the trigger, the key signal fluctuations at the time of fault occurrence are accurately located, avoiding invalid data redundancy and providing a real and complete temporal context for diagnosis. Secondly, it outputs prompt information and receives fault description information input by the driver. The acquisition of fault description information establishes a correspondence between the originally isolated electrical signals and the abnormal phenomena perceived by the driver, significantly enhancing the interpretability of the data. Finally, the initial fault data and fault description information are uploaded to a cloud server, and the diagnostic results returned are received. By utilizing the data processing and pattern recognition capabilities of the cloud server, and integrating objective waveforms and subjective descriptions for comprehensive judgment, the technical objective of improving the accuracy of fault diagnosis is achieved. This enables efficient and accurate identification of intermittent and difficult faults without fault codes, ultimately solving the technical problem of low vehicle fault diagnosis accuracy in related technologies.

[0053] Optionally, the method further includes: upon receiving a trigger signal, judging the trigger signal to obtain a signal judgment result, wherein the signal judgment result is used to indicate whether the trigger signal meets a preset trigger mode; upon receiving a sensor signal from a sensor, detecting the sensor signal to obtain a sensor signal detection result, wherein the sensor signal detection result is used to indicate whether the sensor signal meets a preset abnormal condition; and determining that the vehicle meets the preset trigger condition if the signal judgment result indicates that the trigger signal meets the preset trigger mode, and / or the sensor signal detection result indicates that the sensor signal meets the preset abnormal condition.

[0054] The aforementioned trigger signal can refer to a digital command signal actively operated by the user to initiate a high-density data acquisition process. The trigger signal can also be a signal generated by the driver physically operating a triggering device. The trigger signal can serve as the initial input source for requesting an "event-driven acquisition" mechanism, activating the vehicle system to switch from low-frequency monitoring mode to high-density data acquisition mode.

[0055] The aforementioned signal judgment result refers to the binary judgment result output after receiving a trigger signal and comparing and analyzing the signal timing, amplitude, duration, or operation mode according to preset logic rules. This result clarifies whether the trigger signal conforms to the system-defined trigger behavior. The signal judgment result may include, but is not limited to, the trigger signal meeting the preset trigger mode and the trigger signal not meeting the preset mode. The specific signal judgment result needs to be determined based on the actual trigger signal. The signal judgment result can serve as the first filtering mechanism for "anti-false triggering," ensuring that only genuine user operations trigger data acquisition, preventing invalid data uploads due to accidental touches, electromagnetic interference, or vibration, and improving system robustness and resource utilization.

[0056] The aforementioned preset trigger modes refer to timing, frequency, or operation combination rules that are fixed during system initialization or remotely configured to identify legitimate trigger signals. Preset trigger modes may include, but are not limited to, timing modes (e.g., three short presses, each lasting 100–300ms, with an interval <800ms), duration modes (e.g., a single long press ≥3 seconds), and combination modes (e.g., a 2-second long press followed by two short presses). Specific preset trigger modes need to be set by the vehicle manufacturer based on typical false trigger scenarios and real user behavior data. Preset trigger modes can provide quantifiable and verifiable judgment criteria for trigger signals, enabling the system to possess "behavior recognition" capabilities, rather than merely responding to changes in physical switch states, thereby achieving intelligent understanding of the driver's intentions.

[0057] The aforementioned sensor signals refer to raw or pre-processed analog / digital signals that reflect the vehicle's physical state, collected by the vehicle's electronic control unit (ECU) and transmitted via bus (CAN / LIN / Ethernet). Sensor signals can include, but are not limited to, powertrain signals (such as engine speed, throttle opening, ignition voltage waveform), chassis signals (such as wheel speed, steering angle, yaw rate, and vehicle acceleration), electrical signals (such as battery voltage, output current, and high-voltage insulation resistance), and network signals (such as CAN message error frames, heartbeat timeouts, and message missing). The specific sensor signals need to be determined based on the signals collected by the actual sensors. Sensor signals can serve as objective evidence for the system's automatic detection of anomalies, identifying "soft fault" states where early or transient anomalies have occurred but no Diagnostic Trouble Code (DTC) has been triggered. They form the data basis for achieving unattended triggering.

[0058] The aforementioned sensor signal detection results refer to the binarized judgment results output after real-time analysis of the sensor signals. These results may include, but are not limited to, the sensor signal meeting or not meeting preset abnormal conditions. The specific sensor signal detection results need to be determined based on the actual sensor signals. These results can be used to automatically identify latent faults, compensating for the blind spots of traditional DTC mechanisms in detecting instantaneous, low-frequency, and threshold-less faults, enabling the system to have "pre-DTC warning" capabilities and improving the sensitivity and proactivity of fault detection.

[0059] The aforementioned preset anomaly conditions can refer to mathematical thresholds, statistical models, or pattern templates pre-set by the system to identify latent fault characteristics in sensor signals. Preset anomaly conditions may include, but are not limited to, threshold-type conditions, waveform characteristic-type conditions, statistical deviation-type conditions, and combinational logic-type conditions. Specific preset anomaly conditions need to be determined based on historical fault data training results and the experience of engineering experts. Preset anomaly conditions can provide calculable and reproducible anomaly criteria for sensor signals, enabling the system to identify states that are not triggered by fault codes but have diagnostic value, thus avoiding missed detections.

[0060] In one optional embodiment, external trigger signals and sensor signals from various sensors are continuously monitored during vehicle operation. The trigger signals are evaluated to verify whether they match a preset trigger mode, generating a signal evaluation result. Simultaneously, sensor signals are monitored in real-time, and dynamic analysis is performed based on preset abnormal conditions, outputting sensor signal detection results. Only when either result is true (i.e., user-initiated trigger or system-detected abnormal signs) is the vehicle deemed to meet the preset trigger conditions, thereby activating the high-density data acquisition process. This dual-channel judgment mechanism effectively integrates "human intent" and "vehicle status," significantly improving trigger accuracy and coverage, and eliminating false triggers and missed triggers.

[0061] Optionally, the trigger signal is judged to obtain a signal judgment result, including: acquiring the timing characteristics and number of operations of the trigger signal, wherein the timing characteristics include the pressing duration and the adjacent pressing interval, the pressing duration is used to represent the duration of a single pressing operation corresponding to the trigger signal, and the adjacent pressing interval is used to represent the time interval between two adjacent pressing operations corresponding to the trigger signal; the trigger signal is judged based on the timing characteristics and the number of operations to determine the signal judgment result.

[0062] The aforementioned timing characteristics refer to the dynamic behavioral patterns exhibited by the trigger signal over time, which can be used to identify the intended operation. Timing characteristics may include, but are not limited to, press duration and intervals between adjacent presses; specific timing characteristics need to be determined based on actual needs. Timing characteristics consist of multiple time-related parameters and can serve as a key basis for determining whether the trigger signal represents an intentional human operation rather than a mis-touch.

[0063] The aforementioned number of operations can refer to the total number of valid press actions included in the trigger signal within a preset time window. The number of operations can be used as a counting dimension of the trigger mode to limit the user to perform a "specific number" of conscious operations, in order to confirm that the user has a clear intention to report a fault and to avoid false triggering caused by a single accidental touch or device resonance.

[0064] The aforementioned press duration refers to the physical time that a triggering device (such as a hazard alarm switch) remains closed each time it is pressed, i.e., the duration from when the switch contacts close to when they open. Press duration can be used to eliminate false signals caused by "momentary jitter" or "poor contact," ensuring that each press is a valid human operation. Simultaneously, its value can help distinguish between "short press" and "long press" modes, supporting composite triggering logic.

[0065] The aforementioned adjacent press interval refers to the time interval between two consecutive valid press operations, from the release of the previous press (switch opening) to the closing of the next press. The adjacent press interval can be used to measure the rhythmic consistency of user operations and to identify whether the operations possess a "conscious sequential nature." If the interval is too long (e.g., >5s), it is considered two independent operations; if the interval is too short (e.g., <50ms), there is a probability of device jitter or electromagnetic interference. By setting a reasonable range, non-human signals can be effectively filtered out. The above values ​​are for illustrative purposes only; specific values ​​need to be determined based on actual needs and are not limited here.

[0066] In one optional embodiment, upon receiving a trigger signal, the vehicle-mounted connected terminal extracts the timing characteristics and number of operations of the trigger signal. The timing characteristics include the duration of a single press and the time interval between two adjacent presses, representing the physical duration of each button press and the continuity of the operation rhythm, respectively. Subsequently, the system compares the acquired number of operations, press duration, and adjacent press intervals with a preset trigger mode to obtain a signal judgment result. Only when all parameters fall within the valid range is the signal judgment result determined to be true, confirming it as a valid human trigger. This process, through the collaborative constraints of multi-dimensional time parameters, accurately identifies the driver's conscious fault reporting behavior, effectively filters false signals caused by device vibration, electromagnetic interference, or accidental touches, significantly improves the accuracy and robustness of the triggering mechanism, ensures that high-density data acquisition is only initiated under genuine fault intent, avoids invalid data uploads, and saves communication and storage resources.

[0067] Optionally, the trigger signal is judged based on timing characteristics and the number of operations to determine the signal judgment result, including: judging based on the timing characteristics and the preset timing requirements in the preset trigger mode to obtain a timing judgment result, wherein the timing judgment result is used to indicate whether the timing characteristics meet the preset timing requirements; judging based on the number of operations and the preset number of operations in the preset trigger mode to obtain a number of operations judgment result, wherein the number of operations judgment result is used to indicate whether the number of operations meets the preset number of operations requirement; if the timing judgment result is that the timing characteristics meet the preset timing requirements and the number of operations judgment result is that the number of operations meets the preset number of operations requirement, the signal judgment result is determined to be that the trigger signal meets the preset trigger mode.

[0068] The aforementioned preset timing requirements refer to a set of time parameter constraints set during system initialization or configuration to determine whether the timing characteristics of the trigger signal conform to a legal operating mode. Preset timing requirements may include, but are not limited to, the range of single press duration and the range of adjacent press intervals; specific preset timing requirements need to be determined based on actual needs. Preset timing requirements can serve as the core timing benchmark for determining whether a trigger signal is intentionally manipulated. By limiting the rationality of the operation rhythm, random signals caused by vehicle bumps, electromagnetic interference, or equipment vibration are eliminated, ensuring that the triggering behavior possesses reproducible and predictable human characteristics.

[0069] The aforementioned timing judgment result refers to the binarized judgment result output by the vehicle-mounted connected terminal after comparing the actual collected timing features with the preset timing requirements item by item. The timing judgment result can be used to indicate whether the timing behavior of the current trigger signal meets the preset time constraints.

[0070] The aforementioned preset number of presses requirement refers to the minimum or precise number of valid presses required for the trigger signal, as explicitly specified in the preset trigger mode. This preset number of presses requirement can be used to confirm that the user has a clear and continuous reporting intention, rather than an occasional single operation.

[0071] The aforementioned count determination result refers to the binary determination result generated by comparing the number of valid press operations in the trigger signal count with a preset count requirement after the vehicle-mounted connected terminal counts the count. The count determination result can be used to indicate whether the number of operations for the current trigger event meets the threshold set by the system. It can serve as a quantitative criterion for triggering decisions, and together with the "timing determination result," constitute a two-factor verification mechanism to ensure that the triggering behavior is not only "time-accurate" but also "count-accurate," achieving double insurance for intent recognition.

[0072] In one optional embodiment, the timing features are first compared based on preset timing requirements in a preset trigger mode, and a timing judgment result is output to indicate whether the timing conforms to the specification. Simultaneously, the number of operations is compared based on preset number requirements, and a number judgment result is output to indicate whether the number of operations meets the standard. Only when both the timing judgment result and the number of operations judgment result are true (i.e., the timing features meet the preset timing requirements) and the number of operations judgment result are true (i.e., the number of operations meets the preset number of operations requirements), does the system ultimately determine the signal judgment result as "the trigger signal meets the preset trigger mode," thereby initiating the high-density data acquisition process. This mechanism, through the joint judgment of "timing + number of operations," achieves accurate identification of user intent, significantly reduces invalid triggers caused by environmental interference or misoperation, ensures that high-density data acquisition is only initiated in real fault scenarios, effectively controls communication bandwidth and storage overhead, and improves the overall economy and reliability of the diagnostic system.

[0073] Optionally, the data acquisition mode of the vehicle system is switched from the first data acquisition mode to the second data acquisition mode, and initial fault data is acquired in the second data acquisition mode, including: determining the moment when the vehicle meets the preset triggering conditions as the triggering moment; stopping the updating of the vehicle's operating data based on the triggering moment, and switching the data acquisition mode of the vehicle system from the first data acquisition mode to the second data acquisition mode; in the second data acquisition mode, acquiring the current vehicle operating data for a first preset duration before the triggering moment and a second preset duration after the triggering moment; and determining the current vehicle operating data as the initial fault data.

[0074] The aforementioned trigger moment refers to the precise point in time when the vehicle system determines that the vehicle meets preset trigger conditions (such as a valid manual trigger signal or abnormal sensor signals). This trigger moment can be recorded by the clock module of the vehicle-mounted connected terminal based on the system time base (such as a CAN timestamp), with units in milliseconds or microseconds. The trigger moment serves as a temporal anchor for high-density data acquisition, used to determine the start and end boundaries of data extraction "before and after the fault" within the circular buffer. This ensures that the collected data fully covers the environmental state before the fault and the transient response after it occurs, serving as the core benchmark for achieving "context-aware diagnosis."

[0075] The aforementioned first preset duration before the trigger moment refers to the length of a fixed time window that the system needs to retain and lock before the trigger moment for analyzing the vehicle's operating status before the fault. The length of the first preset duration before the trigger moment can be determined according to actual data collection needs and is not limited here. The first preset duration before the trigger moment can be used to capture vehicle operating background information before the fault occurs (such as vehicle speed, load, ambient temperature, ECU operating status, etc.), helping diagnostic personnel distinguish between systemic anomalies and transient disturbances, avoiding misjudgment as "isolated events," and improving the causal analysis capability of diagnosis.

[0076] The second preset duration after the trigger moment refers to the length of a fixed time window after the trigger moment, during which the system continuously collects and locks data to capture the persistence or evolution of the fault; that is, the collection duration of "post-fault response" data. The length of the second preset duration before the trigger moment can be determined according to actual collection needs and is not limited here. The second preset duration after the trigger moment can be used to record the system response behavior after the fault occurs (such as ECU self-protection actions, actuator feedback, signal attenuation trends, etc.), providing key dynamic evidence for judging the fault type (such as sensor failure, wiring harness open circuit, abnormal control strategy), and avoiding misdiagnosis caused by relying solely on "fault moment" data.

[0077] The aforementioned current vehicle operation data refers to the full range of vehicle operation status signals collected at high frequency by the onboard system within a time window from the first preset duration before the trigger time to the second preset duration after the trigger time in the second data acquisition mode. Current vehicle operation data may include, but is not limited to, powertrain signals, chassis signals, electrical signals, and network signals; the specific current vehicle operation data needs to be determined based on diagnostic requirements. This current vehicle operation data can serve as the core content of a high-fidelity fault scene data package, providing cloud-based experts or AI diagnostic models with a time-synchronized, high-resolution, and multi-dimensional raw signal stream. It supports precise waveform analysis, signal comparison, and fault reasoning, and is the technological cornerstone for achieving "accurate diagnosis of difficult faults" in this application.

[0078] In one optional embodiment, when the vehicle meets the preset trigger conditions, the on-board system first switches the data acquisition mode from a low-frequency first data acquisition mode to a high-frequency second data acquisition mode to increase the data acquisition density, and simultaneously locks the trigger moment precisely at the instant the preset trigger conditions are met. Then, it immediately stops the continuous updating of vehicle operation data to prevent the loss of critical transient information due to cyclic coverage. Next, it completely acquires historical operation data within a first preset duration before the trigger moment and current vehicle operation data within a second preset duration after the trigger moment at a high sampling frequency, forming a high-precision operation data segment covering the complete process before and after the fault. Finally, it confirms the current vehicle operation data as the initial fault data, thereby ensuring that the key contextual information of occasional difficult faults is completely captured. This mechanism, by acquiring data symmetrically before and after the trigger moment, completely preserves the "causal background" before the fault occurs and the "evolutionary process" afterward, solving the problem that traditional low-frequency uploading cannot capture transient features. This significantly improves the fault reproducibility and diagnostic accuracy, while avoiding the communication and storage burden caused by continuous full-volume acquisition because only short-term high-density data is collected.

[0079] Optionally, sending initial fault data and fault description information to the cloud server includes: encoding the fault description information to obtain encoded information; binding the encoded information, the vehicle's vehicle code, and the trigger time to generate comprehensive fault data; associating the comprehensive fault data with the initial fault data to obtain fault association data; and sending the fault association data to the cloud server.

[0080] The aforementioned encoded information refers to a structured digital data stream generated after digitally compressing, standardizing the format, and semantically encapsulating fault description information. This encoded information can significantly reduce upload bandwidth consumption and cloud storage pressure while ensuring the semantic integrity of the description, enabling efficient communication between "human-machine language" and "machine systems." It also supports cloud-based AI models in performing natural language processing, speech recognition, or image analysis on fault descriptions, thereby improving the level of diagnostic intelligence.

[0081] The aforementioned vehicle code can refer to a legal or system-level digital identifier that uniquely identifies the vehicle. In this application, the preferred identifier is the Vehicle Identification Number (VIN). The vehicle code can serve as an identity anchor for fault data, ensuring that uploaded data can be accurately bound to a specific vehicle model, ECU configuration, production batch, and software version by the cloud system, achieving "one vehicle, one file" management and supporting cross-vehicle fault mode clustering analysis, batch defect early warning, and after-sales responsibility traceability.

[0082] The aforementioned comprehensive fault data refers to a metadata data package formed by structurally binding the encoding information, vehicle code, and trigger time. This comprehensive fault data can be used to provide contextual metadata about fault events to the cloud system.

[0083] The aforementioned fault-related data can refer to a complete fault case data package formed by logically binding comprehensive fault data (meta-information) with initial fault data (high-density vehicle operation signals) through a unique identifier (such as a hash value or timestamp), which is the final delivery unit uploaded to the cloud.

[0084] In one optional embodiment, the fault description information input by the driver is first encoded to generate compact coded information. Then, this coded information, the vehicle's unique vehicle code, and the trigger time are structurally bound together to generate lightweight comprehensive fault data, serving as the identity and semantic tag for the fault event. Next, this comprehensive fault data is logically associated with the initial fault data to form complete fault-related data, which is then finally uploaded to the cloud server. This mechanism, through a four-layer binding of "semantic encoding—identity identification—time anchoring—raw data," achieves precise alignment between "description" and "data" in human-machine collaborative diagnosis, completely resolving the gap problem of "phenomena without data, data without description" in traditional solutions. This significantly improves the accuracy, traceability, and intelligence level of fault diagnosis, while achieving significant diagnostic value with minimal communication overhead, laying a structured data foundation for building a cloud-based knowledge graph of complex vehicle faults.

[0085] Optionally, the method further includes: performing differential calculation based on the initial fault data and the benchmark data model corresponding to the vehicle type to obtain difference data; and sending the difference data and fault description information to the cloud server.

[0086] The aforementioned vehicle type refers to a standardized classification identifier based on core characteristics such as the vehicle's platform architecture, powertrain, electronic and electrical architecture, ECU configuration, and production batch. Vehicle type ensures that the baseline data model delivered from the cloud is consistent with the vehicle's hardware and software configuration, avoiding model mismatch due to vehicle model differences, thereby guaranteeing the accuracy and effectiveness of differential calculations.

[0087] For example, vehicle type classification methods may include, but are not limited to:

[0088] The first approach is to classify vehicles by platform level, such as electric platforms, fuel platforms, and intelligent driving architectures.

[0089] The second method is to classify them by powertrain system, such as pure electric vehicles, plug-in hybrid vehicles, and gasoline vehicles.

[0090] The third approach is to classify vehicles by ECU configuration group, such as ordinary vehicles equipped only with the basic power control group and intelligent vehicles equipped with the intelligent driving assistance group.

[0091] The above vehicle types need to be determined according to the vehicle classification method and the specific vehicle; no restrictions are imposed here.

[0092] The aforementioned benchmark data model refers to a set of standard vehicle signal behavior characteristics statistically analyzed and modeled by a cloud server for a specific vehicle type under typical normal operating conditions. This benchmark data model can serve as a reference point for normal operation, comparing it with locally collected initial fault data to identify deviations from normal behavior. This enables data compression and anomaly focusing, significantly reducing upload traffic and enhancing the targeted nature of cloud-based analysis.

[0093] The aforementioned differential calculation may refer to the on-board connected terminal performing point-by-point, signal-by-signal, and condition-by-condition difference comparison calculations on the local side between the initial fault data and the benchmark data model that matches the corresponding vehicle type, extracting only the data subset that reflects the "abnormal deviation", rather than transmitting all the original data.

[0094] The aforementioned discrepancy data can refer to a simplified dataset generated after differential calculation, containing only the portion of vehicle operating signals that deviates from the baseline data model. This discrepancy data can serve as the core diagnostic data carrier uploaded to the cloud, ensuring the integrity of diagnostic information while increasing throughput. Upon receiving the data, the cloud can reconstruct the complete fault waveform based on the existing local baseline model, enabling high-precision analysis without the need to store the original massive amounts of data.

[0095] In one optional embodiment, the vehicle-mounted connected terminal synchronously acquires a corresponding benchmark data model from the cloud based on the vehicle type. This model describes the key signal behavior characteristics of the vehicle type under normal operating conditions. Subsequently, the system performs differential calculations on the locally stored initial fault data and the benchmark model. By comparing each signal and each sampling point, it extracts the difference data that only reflects abnormal deviations. This difference data, along with the fault description information input by the driver, is uploaded to the cloud server. This mechanism, through the "benchmark comparison - difference extraction" technology, achieves intelligent compression and on-demand uploading, reducing communication traffic without losing diagnostic information, significantly reducing operator traffic costs and cloud storage burden. At the same time, because the difference data focuses on abnormal features, the cloud AI model can more efficiently locate fault modes, improving diagnostic efficiency and accuracy, and achieving a "low-cost, high-value, and highly intelligent" fault data closed loop.

[0096] Figure 2 This is a flowchart of another vehicle fault diagnosis method according to an embodiment of this application, applied to a cloud server. The method includes the following steps:

[0097] Step S202: Receive initial fault data and fault description information from the vehicle system;

[0098] Step S204: Based on the initial fault data and fault description information, feature extraction is performed to obtain fault features;

[0099] Step S206: Determine the vehicle's fault diagnosis result based on the fault characteristics and the corresponding vehicle type.

[0100] Step S208: Send the fault diagnosis results to the vehicle system.

[0101] The aforementioned fault features refer to a set of diagnostic criteria with discriminative significance extracted from initial fault data and fault description information through techniques such as signal processing, pattern recognition, and semantic analysis. Fault features may include, but are not limited to, time-series signal features (from initial fault data), semantic description features (from fault description information), and cross-modal fusion features (combining signal and description). Specific fault features need to be determined based on actual diagnostic requirements. Fault features can be used to transform massive, multidimensional, and heterogeneous raw data into structured, quantifiable, and comparable diagnostic indicators, driving subsequent fault classification and root cause inference.

[0102] In one optional embodiment, the cloud server jointly analyzes the received initial fault data and fault description information uploaded by the vehicle system to extract a set of fault features with diagnostic discriminative power. These fault features can be expressed in structured vector form, becoming the core basis for subsequent fault diagnosis. Then, based on the fault features and vehicle type, a reasonable analysis is performed to determine the current vehicle's fault diagnosis result. Finally, the fault diagnosis result is sent back to the vehicle system, enabling the driver to promptly understand the specific fault of the current vehicle. This method utilizes the stronger computing resources of the cloud to jointly model time-series signals and text descriptions, effectively improving the ability to identify complex fault modes under conditions of limited communication bandwidth and sparse data samples. Simultaneously, through continuous accumulation of the case library and model iteration, the generalization and consistency of the diagnostic results are enhanced, thus achieving a synergistic improvement in diagnostic efficiency and accuracy without relying on the complex reasoning capabilities of the vehicle terminal.

[0103] Optionally, based on the fault characteristics and the corresponding vehicle type, the fault diagnosis result of the vehicle is determined, including: based on the fault characteristics and the vehicle type, determining the target fault handling method corresponding to the vehicle; and performing fault diagnosis on the vehicle based on the target fault handling method and the fault characteristics to obtain the fault diagnosis result.

[0104] The aforementioned target fault handling method can refer to the specific repair or inspection measures recommended based on the fault diagnosis results. It is used to guide users or maintenance personnel in troubleshooting, such as "it is recommended to prioritize checking the right front wheel speed sensor and its wiring harness connection." The target fault handling method is a key output of this application in achieving a closed loop from fault discovery to precise repair.

[0105] In one optional embodiment, fault characteristics are first combined with vehicle type to dynamically match the target fault handling method corresponding to that vehicle type, thereby avoiding diagnostic misjudgments caused by differences in response mechanisms for the same fault characteristics among different vehicle models. Subsequently, using the target fault handling method as a constraint, the fault characteristics are integrated to conduct targeted fault diagnosis, ensuring that the diagnostic logic is compatible with the vehicle structure, system configuration, and historical maintenance strategies, ultimately generating highly accurate fault diagnosis results. This effectively solves the problem of generalized diagnostic results and poor adaptability caused by ignoring vehicle type differences in existing technologies, achieving accurate and personalized cloud-based diagnosis and response for intermittent and difficult faults at low cost, significantly improving the efficiency and reliability of fault handling.

[0106] In one alternative embodiment, Figure 3 This is a schematic diagram of the overall architecture of a vehicle fault diagnosis system according to an embodiment of this application, such as... Figure 3As shown, the system mainly consists of two parts: a big data cloud platform and a vehicle-mounted subsystem. The big data cloud platform is mainly used for task distribution, feedback push, analysis and diagnosis engine, and data receiving / storage. The vehicle-mounted subsystem mainly includes triggering devices, vehicle-mounted intelligent terminals, and vehicle-mounted network terminals.

[0107] Specifically, the driver generates a trigger signal by operating the triggering device (such as pressing the hazard alarm switch three times consecutively). This signal is received by the vehicle-mounted network terminal, which then locks the high-density vehicle operation data before and after the trigger within the circular buffer zone and uploads it to the cloud platform via the mobile network. Simultaneously, the vehicle-mounted smart terminal prompts the driver to enter fault description information, which is then uploaded together after being associated with the data. After receiving the complete fault data packet and description information, the cloud platform assigns the fault case to the corresponding technician through the case distribution and task management module. The technician performs a comprehensive diagnosis based on the high-density waveform and semantic description and submits a diagnostic conclusion. After receiving the conclusion, the analysis result feedback module pushes the diagnostic result back to the vehicle's onboard network terminal, which records and notifies the onboard smart terminal. Finally, the onboard smart terminal presents maintenance guidance to the driver in the form of text, images, or voice. This application, through a collaborative mechanism encompassing "user-initiated triggering—high-density data capture—human-machine information fusion—cloud-based intelligent distribution—closed-loop feedback," achieves for the first time accurate, low-cost, and traceable diagnosis of intermittent, difficult-to-diagnose faults without fault codes. It effectively overcomes the diagnostic failures caused by traditional reliance on vague driver descriptions and low-frequency remote data, significantly improving diagnostic accuracy and efficiency, reducing invalid return rates, shortening the average diagnostic cycle from several days to several hours, and greatly enhancing user satisfaction and after-sales service response capabilities. It also provides a feasible system architecture to support the construction of an intelligent, self-evolving vehicle fault knowledge system.

[0108] Figure 4 This is a schematic diagram of the internal module composition of a vehicle-mounted connected terminal according to an embodiment of this application, such as... Figure 4 As shown, the vehicle-mounted connected terminal includes: a communication module, a low-frequency acquisition module, a high-frequency acquisition module, a ring buffer, a high-density acquisition control unit, and an event triggering and processing module.

[0109] Specifically, the core of the vehicle-mounted connected terminal is a microprocessor, whose software functional modules include a bus monitoring and acquisition module, a circular buffer, an event triggering and processing module, and a high-density acquisition control unit. The bus monitoring and acquisition module is divided into a low-frequency acquisition module and a high-frequency acquisition module. In its default state, the high-frequency acquisition module records all bus signals (such as vehicle speed, RPM, battery voltage, etc.) at a frequency of 100Hz to the circular buffer, which is designed to store 10 minutes of high-frequency data. The low-frequency acquisition module simultaneously acquires key bus signals at a frequency of 1Hz and uploads them to the big data cloud platform in real time. When the event triggering and processing module listens to a specific signal sequence from the hazard alarm switch, the high-density acquisition control unit receives a trigger signal and immediately performs the following actions: a) It controls the circular buffer to stop cyclic overwriting after 5 minutes and transfers the existing high-density data (5 minutes before triggering and 5 minutes after triggering) from memory to local non-volatile memory, forming a total of 10 minutes of data file. The communication management module is responsible for establishing a link with the cloud platform. After the data file is generated, the communication management module attempts to upload it. Simultaneously, it sends a command to the in-vehicle intelligent terminal via the internal network, triggering it to display a prompt message. The above values ​​are for illustrative purposes only; specific values ​​need to be determined based on actual needs and are not limited here.

[0110] Figure 5 This is a flowchart of an optional vehicle fault diagnosis method according to an embodiment of this application, such as... Figure 5 As shown, this method begins with low-frequency monitoring during normal driving to determine if a switch is triggered. If not, low-frequency monitoring continues; if so, high-density data acquisition is triggered. Next, the data is stored and notified to the smart terminal. Then, the smart terminal collects driver descriptions, encodes the description files, and uploads them. The files are then linked via a network-connected terminal and uploaded to the cloud. The cloud receives the data and assigns tasks. Engineers receive the tasks and perform technical analysis. Engineers submit their conclusions. The cloud platform pushes the results to the vehicle. The smart terminal displays the analysis results to the driver. The fault diagnosis method provided in this application controls costs by maintaining low-frequency monitoring during normal driving and only initiating high-density data acquisition and human-machine interaction information fusion when actively triggered by the driver, achieving accurate capture and efficient diagnosis of intermittent and difficult faults.

[0111] Specifically, step one: the vehicle is driving normally, and the system is in a low-frequency monitoring state.

[0112] Step 2: If the driver feels any abnormality in the vehicle (such as accelerator pedal vibration or instrument panel flashing), he should press the hazard warning switch three times in quick succession within three seconds.

[0113] Step 3: The vehicle-mounted connected terminal detects this specific operation and immediately triggers a high-density data collection and storage process to generate a data file.

[0114] Step 4: The connected terminal starts the data upload task and sends a "Fault recorded" notification to the vehicle's large screen.

[0115] Step 5: A pop-up interface appears on the car's infotainment screen, displaying: "The system has recorded your driving situation just now. Please briefly describe what happened? (voice or text)." The driver says via voice: "While driving at 110 km / h on the highway, I felt the steering wheel intermittently pulling left and right for more than ten seconds, and at the same time I heard a slight 'ticking' noise from the right front wheel."

[0116] Step Six: The vehicle system encodes this voice message and binds it with the vehicle's VIN code and trigger timestamp, then sends it to the connected terminal.

[0117] Step 7: The connected terminal associates the voice description file with the data file and uploads them together to the cloud platform.

[0118] Step 8: The cloud platform's receiving service confirms the data is complete, then creates a new fault work order in the maintenance expert system and automatically assigns it to an expert engineer specializing in chassis systems based on the vehicle model.

[0119] Step Nine: The engineer opened the data file using professional analysis software. He first played back the voice description, and then precisely located the described time period in the 100Hz high-density data stream. By comparing and analyzing the subtle differences between the right front wheel speed signal and other wheel speed signals, as well as the instantaneous fluctuations of the steering angle sensor and yaw rate signals, combined with the timing of the abnormal noise, the engineer quickly determined that there was intermittent signal distortion in the right front wheel speed sensor, caused by iron filings in the sensor's magnetic gap or a loose wiring harness connector.

[0120] Step 10: The engineer enters the diagnostic conclusion "It is recommended to first check the right front wheel speed sensor and its wiring harness connection, as there is an intermittent fault" into the system and submits it.

[0121] Step 11: The cloud platform pushes the conclusion to the connected terminal of the faulty vehicle.

[0122] Step Twelve: The vehicle's infotainment screen displays a new message: "Your vehicle diagnostic report has been generated: Suspected abnormality in the right front wheel sensor signal. We recommend you drive safely and schedule a service center appointment for a detailed inspection as soon as possible." The driver then arranges repairs accordingly, and the problem is quickly resolved. The values ​​in the above steps are for illustrative purposes only; specific values ​​should be determined based on actual needs and are not limited here.

[0123] According to an embodiment of this application, a vehicle fault diagnosis device is provided. It should be noted that the device can be used to perform the above-described vehicle fault diagnosis method.

[0124] Figure 6This is a schematic diagram of a vehicle fault diagnosis device according to an embodiment of this application, such as... Figure 6 As shown, this device is applied to an in-vehicle system deployed in a vehicle and includes: a data acquisition module 602, a first transceiver module 604, and a second transceiver module 606.

[0125] The acquisition module 602 is used to switch the data acquisition mode of the vehicle system from the first data acquisition mode to the second data acquisition mode when the vehicle meets the preset trigger conditions, and to acquire initial fault data in the second data acquisition mode. The data acquisition frequency of the second data acquisition mode is higher than that of the first data acquisition mode. The preset trigger conditions are the conditions used to trigger fault diagnosis of the vehicle. The first transceiver module 604 is used to output prompt information and receive fault description information corresponding to the initial fault data. The prompt information is used to prompt input of fault description information. The second transceiver module 606 is used to send the initial fault data and fault description information to the cloud server and receive the vehicle fault diagnosis results returned by the cloud server. The fault diagnosis results are determined by the cloud server based on the initial fault data and fault description information.

[0126] Optionally, the device is further configured to, upon receiving a trigger signal, determine the trigger signal to obtain a signal determination result, wherein the signal determination result indicates whether the trigger signal meets a preset trigger mode; upon receiving a sensor signal from a sensor, detect the sensor signal to obtain a sensor signal detection result, wherein the sensor signal detection result indicates whether the sensor signal meets a preset abnormal condition; and if the signal determination result indicates that the trigger signal meets the preset trigger mode, and / or the sensor signal detection result indicates that the sensor signal meets the preset abnormal condition, determine that the vehicle meets the preset trigger condition.

[0127] Optionally, the device is further configured to acquire the timing characteristics and number of operations of the trigger signal, wherein the timing characteristics include the pressing duration and the interval between adjacent pressing, the pressing duration is used to represent the duration of a single pressing operation corresponding to the trigger signal, and the interval between adjacent pressing is used to represent the time interval between two adjacent pressing operations corresponding to the trigger signal; the trigger signal is judged based on the timing characteristics and the number of operations to determine the signal judgment result.

[0128] Optionally, the device is further configured to make a judgment based on timing characteristics and preset timing requirements in a preset trigger mode to obtain a timing judgment result, wherein the timing judgment result is used to indicate whether the timing characteristics meet the preset timing requirements; make a judgment based on the number of operations and preset number of operations in a preset trigger mode to obtain a number of operations judgment result, wherein the number of operations judgment result is used to indicate whether the number of operations meets the preset number of operations requirement; and determine the signal judgment result as the trigger signal meets the preset trigger mode if the timing judgment result indicates that the timing characteristics meet the preset timing requirements and the number of operations judgment result indicates that the number of operations meets the preset number of operations requirement.

[0129] Optionally, the acquisition module is also used to determine the moment when the vehicle meets the preset triggering conditions as the triggering moment; based on the triggering moment, stop updating the vehicle's operating data and switch the data acquisition mode of the vehicle system from the first data acquisition mode to the second data acquisition mode; in the second data acquisition mode, acquire the current vehicle operating data for a first preset duration before the triggering moment and a second preset duration after the triggering moment; and determine the current vehicle operating data as the initial fault data.

[0130] Optionally, the second transceiver module is also used to encode the fault description information to obtain coded information; bind the coded information, the vehicle code, and the trigger time to generate comprehensive fault data; associate the comprehensive fault data with the initial fault data to obtain fault association data; and send the fault association data to the cloud server.

[0131] Optionally, the device is also used to perform differential calculations based on the initial fault data and the benchmark data model corresponding to the vehicle type to obtain difference data; and send the difference data and fault description information to the cloud server.

[0132] Figure 7 This is a schematic diagram of another vehicle fault diagnosis device according to an embodiment of this application, such as... Figure 7 As shown, the device is applied to a cloud server and includes: a receiving module 702, an extraction module 704, a determining module 706, and a sending module 708.

[0133] The receiving module 702 is used to receive initial fault data and fault description information sent by the vehicle system; the extraction module 704 is used to extract features based on the initial fault data and fault description information to obtain fault features; the determining module 706 is used to determine the fault diagnosis result of the vehicle based on the fault features and the vehicle type corresponding to the vehicle; and the sending module 708 is used to send the fault diagnosis result to the vehicle system.

[0134] Optionally, the determining module is also used to determine the target fault handling method corresponding to the vehicle based on the fault characteristics and vehicle type; and to perform fault diagnosis on the vehicle based on the target fault handling method and fault characteristics to obtain fault diagnosis results.

[0135] Embodiments of this application also provide a vehicle, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods described in various embodiments of this application when it runs.

[0136] Embodiments of this application also provide a computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0137] Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0138] Embodiments of this application also provide a computer program product, including a non-volatile computer-readable storage medium for storing a computer program that, when executed by a processor, implements the methods in various embodiments of this application.

[0139] Embodiments of this application also provide a computer program that, when executed by a processor, implements the methods described in the various embodiments of this application.

[0140] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0141] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0142] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0143] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0144] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0145] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for diagnosing vehicle faults, characterized in that, Applied to an in-vehicle system deployed in a vehicle, the method includes: When the vehicle meets the preset triggering conditions, the data acquisition mode of the vehicle system is switched from the first data acquisition mode to the second data acquisition mode, and initial fault data is collected in the second data acquisition mode. The data acquisition frequency of the second data acquisition mode is higher than that of the first data acquisition mode. The preset triggering conditions are the conditions used to trigger fault diagnosis of the vehicle. Output a prompt message and receive a fault description message corresponding to the initial fault data, wherein the prompt message is used to prompt input of the fault description message; The initial fault data and the fault description information are sent to the cloud server, and the fault diagnosis results of the vehicle returned by the cloud server are received, wherein the fault diagnosis results are determined by the cloud server based on the initial fault data and the fault description information.

2. The method according to claim 1, characterized in that, The method further includes: Upon receiving a trigger signal, the trigger signal is judged to obtain a signal judgment result, wherein the signal judgment result is used to indicate whether the trigger signal meets a preset trigger mode; Upon receiving a sensor signal from a sensor, the sensor signal is detected to obtain a sensor signal detection result, wherein the sensor signal detection result is used to indicate whether the sensor signal meets a preset abnormal condition; If the signal judgment result indicates that the trigger signal meets the preset trigger mode, and / or the sensor signal detection result indicates that the sensor signal meets the preset abnormal condition, then the vehicle is determined to meet the preset trigger condition.

3. The method according to claim 2, characterized in that, The trigger signal is judged to obtain a signal judgment result, including: The timing characteristics and number of operations of the trigger signal are obtained, wherein the timing characteristics include the press duration and the adjacent press interval, the press duration is used to represent the duration of a single press operation corresponding to the trigger signal, and the adjacent press interval is used to represent the time interval between two adjacent press operations corresponding to the trigger signal; The trigger signal is judged based on the timing characteristics and the number of operations to determine the signal judgment result.

4. The method according to claim 3, characterized in that, The trigger signal is judged based on the timing characteristics and the number of operations, and the signal judgment result is determined, including: Based on the timing characteristics and the preset timing requirements in the preset triggering mode, a timing judgment result is obtained, wherein the timing judgment result is used to indicate whether the timing characteristics meet the preset timing requirements; A judgment result is obtained based on the number of operations and the preset number of operations required in the preset trigger mode. The number of operations is used to indicate whether the number of operations meets the preset number of operations requirement. If the timing judgment result indicates that the timing feature meets the preset timing requirement, and the number of operations judgment result indicates that the number of operations meets the preset number of operations requirement, then the signal judgment result indicates that the trigger signal meets the preset trigger mode.

5. The method according to claim 1, characterized in that, Switching the data acquisition mode of the vehicle system from the first data acquisition mode to the second data acquisition mode, and acquiring initial fault data in the second data acquisition mode, including: The moment when the vehicle meets the preset triggering condition is determined as the triggering moment; Based on the trigger time, the vehicle operation data of the vehicle is stopped from being updated, and the data acquisition mode of the vehicle system is switched from the first data acquisition mode to the second data acquisition mode; In the second data acquisition mode, current vehicle operation data is collected for a first preset duration before the triggering time and a second preset duration after the triggering time. The current vehicle operating data is determined as the initial fault data.

6. The method according to claim 5, characterized in that, Sending the initial fault data and the fault description information to the cloud server includes: The fault description information is encoded to obtain encoded information; The encoding information, the vehicle's vehicle code, and the trigger time are bound together to generate comprehensive fault data; The comprehensive fault data is correlated with the initial fault data to obtain fault correlation data; The fault-related data is sent to the cloud server.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: Differential calculations are performed based on the initial fault data and the baseline data model corresponding to the vehicle type of the vehicle to obtain the difference data; The difference data and the fault description information are sent to the cloud server.

8. A method for diagnosing vehicle faults, characterized in that, Applied to a cloud server, the method includes: Receive initial fault data and fault description information from the vehicle system; Based on the initial fault data and the fault description information, feature extraction is performed to obtain fault features; Based on the fault characteristics and the corresponding vehicle type, the fault diagnosis result of the vehicle is determined. The fault diagnosis results are sent to the vehicle system.

9. The method according to claim 8, characterized in that, Based on the fault characteristics and the corresponding vehicle type, the fault diagnosis result of the vehicle is determined, including: Based on the fault characteristics and the vehicle type, determine the target fault handling method corresponding to the vehicle; Based on the target fault handling method and the fault characteristics, the vehicle is diagnosed to obtain the fault diagnosis result.

10. A vehicle, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the method according to any one of claims 1 to 9.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the storage medium is located to perform the method according to any one of claims 1 to 9.

12. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 9.

Images