Fault cause determination method, device, equipment and storage medium
Patent Information
- Application Number
- CN202611157172.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-31
- Publication Date
- 2026-09-25
AI Technical Summary
[0003]本申请的主要目的在于提供一种故障原因确定方法、装置、设备及存储介质,旨在解决相关技术难以确定车辆中定位无声故障的故障原因的技术问题
基于动态构建的无声检测阈值对PCM音频和拾音采集音频分别进行声音检测,确定两者有声或无声,生成声音检测结果,并基于声音检测结果粗分故障原因并进行进一步故障检测,保证可辅助相应工作人员快速确定无声故障的故障原因。
Smart Images

Figure CN122821992A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of vehicle inspection technology, and in particular to methods, apparatus, equipment and storage media for determining the cause of failure. Background Technology
[0002] Occasionally, the vehicle's infotainment system becomes silent during music playback, navigation announcements, or voice responses. However, testers can only guess the possible cause of the problem by listening to the recordings and reviewing the logs afterward. Since the recordings and logs rely on manual alignment, the cause of the problem can only be guessed by manually comparing approximate times, making it difficult to determine the cause of the malfunction when the silence occurs. This leads to incorrect troubleshooting directions and makes it difficult to locate the root cause. Summary of the Invention
[0003] The main objective of this application is to provide a method, apparatus, device, and storage medium for determining the cause of a fault, aiming to solve the technical problem that it is difficult to determine the cause of a silent fault in a vehicle using related technologies.
[0004] To achieve the above objectives, this application proposes a method for determining the cause of a fault, the method comprising: Determine dynamic calibration values based on vehicle operating conditions; A silent detection threshold is constructed based on the dynamic calibration value, static calibration value, and real-time detection value. Based on the silent detection threshold, sound detection is performed on the PCM audio and the audio collected by sound pickup, and sound detection results are generated. The cause of the fault is located based on the sound detection results.
[0005] Optionally, the step of locating the cause of the fault based on the sound detection result includes: Determine the major category of the fault based on the sound detection results; The vehicle logs are matched against the error keywords corresponding to the major fault categories to generate matching results; If the matching result is a successful match, then the matching log line is determined, and the audio link interruption point is determined based on the matching log line; The cause of the fault is determined based on the audio link interruption point and the fault category.
[0006] Optionally, the sound detection result is that the PCM audio is silent and the sound pickup audio is silent; After matching the vehicle logs based on the error keywords corresponding to the possible fault types and determining the matching results, the process further includes: If the matching result is a failure, then obtain the voice wake-up response information; Detect whether there are network error keywords in the voice wake-up response information; If present, check the vehicle network status; The cause of the fault is generated based on the vehicle network status.
[0007] Optionally, the sound detection result is that the PCM audio is audible, but the audio collected by the microphone is silent; After matching the vehicle logs based on the error keywords corresponding to the possible fault types and determining the matching results, the process further includes: Control the vehicle to play test audio; The system detects whether the microphone has picked up the test audio and generates the detection result. The cause of the failure is constructed based on the test results.
[0008] Optionally, the step of matching the vehicle logs based on the error keywords corresponding to the fault category to generate matching results includes: Based on the time of the fault and / or the time of the configuration change, relevant logs are extracted from the vehicle's logs in combination with a preset time window. The log level corresponding to each relevant log is determined based on the tags or fields of the relevant logs; Based on the retrieval level corresponding to the error keywords of the aforementioned fault categories, determine the logs to be matched for each error keyword; The matching results are generated by matching the erroneous keywords in the log to be matched.
[0009] Optionally, the step of performing sound detection on the PCM audio and the audio collected by sound pickup according to the silent detection threshold, and generating sound detection results, includes: Energy was extracted from both the PCM audio and the audio picked up by sound pickup to obtain the PCM energy and the audio pickup energy. A first detection result is generated based on the PCM energy and the silent detection threshold. A second detection result is generated based on the audio energy of the sound pickup and the silent detection threshold. The sound detection results are constructed based on the first detection result and the second detection result.
[0010] Optionally, generating the first detection result based on the PCM energy and the silent detection threshold includes: The PCM energy is compared with the silent detection threshold to generate a comparison result; Based on the PCM audio, an auxiliary reference index is constructed, which includes at least one of zero-crossing rate, spectral centroid, and harmonic ratio. A first detection result is generated based on the comparison results and the auxiliary reference indicators.
[0011] Furthermore, to achieve the above objectives, this application also proposes a fault cause determination device, which includes: The calibration module is used to determine dynamic calibration values based on vehicle operating conditions; The construction module is used to construct a silent detection threshold based on the dynamic calibration value, static calibration value, and real-time detection value; The detection module is used to perform sound detection on the PCM audio and the audio collected by sound pickup according to the silent detection threshold, and generate sound detection results; The determination module is used to locate the cause of the fault based on the sound detection results.
[0012] In addition, to achieve the above objectives, this application also proposes a fault cause determination device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the fault cause determination method as described above.
[0013] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the fault cause determination method described above.
[0014] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the fault cause determination method described above.
[0015] One or more technical solutions proposed in this application have at least the following technical effects: Based on a dynamically constructed silent detection threshold, sound detection is performed on PCM audio and audio from the microphone to determine whether they are audible or silent, generating sound detection results. Based on the sound detection results, the cause of the fault is roughly identified and further fault detection is performed to ensure that the relevant personnel can quickly determine the cause of the silent fault. Attached Figure Description
[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 This is a flowchart illustrating an embodiment of the method for determining the cause of failure in this application. Figure 2 This is a flowchart illustrating Embodiment 2 of the method for determining the cause of failure in this application. Figure 3 This is a flowchart illustrating Embodiment 3 of the method for determining the cause of failure in this application; Figure 4 This is a schematic diagram of the module structure of the fault cause determination device according to an embodiment of this application; Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the fault cause determination method in the embodiments of this application.
[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation
[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.
[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.
[0022] Based on this, embodiments of this application provide a method for determining the cause of a fault, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the method for determining the cause of failure in this application.
[0023] In this embodiment, the fault cause determination method includes steps S10~S40: Step S10: Determine the dynamic calibration value based on the vehicle's operating conditions.
[0024] It should be noted that the execution subject of this embodiment can be the vehicle itself or the fault cause determination device. The fault cause determination device can be a controller installed in the vehicle, such as an ECU controller, or it can be a device that can detect the vehicle independently of the vehicle, such as a dedicated testing instrument. Of course, it can also be other devices that can achieve the same or similar functions. This embodiment does not limit this. In this embodiment and the following embodiments, the fault cause determination device is used as an example to describe the fault cause determination method of this application.
[0025] It should be noted that vehicle operating conditions may include vehicle speed, vehicle environmental conditions (such as the combination of vehicle and air conditioning on / off), and power mode.
[0026] Depending on the vehicle model, the number of power modes may vary. For example, pure electric (EV) vehicles have power modes such as stationary, low speed, and high speed; plug-in hybrid (PHEV) vehicles have power modes such as pure electric mode and hybrid mode; and range extender (REEV) vehicles have power modes such as range extender started and range extender not started.
[0027] In practical use, in order to ensure more accurate judgment when there is no sound or sound, the personnel in charge of the fault cause determination equipment can pre-build different calibration values under different operating conditions, different vehicle speeds, different vehicle environmental conditions, and different power modes. Then, when actual testing is required, the corresponding calibration value can be found as a dynamic calibration value according to the vehicle's operating conditions.
[0028] For example, under different vehicle speeds (0, 30, 60, 80, 100 km / h), different environmental conditions (combination of window / air conditioning switch), and different power modes, while keeping the microphone position unchanged, calculate the root mean square energy (RMS) for each operating condition, store the RMS as a calibration value, and establish a multi-dimensional mapping table.
[0029] When calculating RMS, since the original 16-bit PCM audio data ranges from -32768 to 32767, and is normalized to [-1.0, 1.0], we can have: x_norm[n] = x_raw[n] / 32768.0, where x_raw[n] can be the nth original quantized sample value of the audio, and x_norm[n] can be the nth over-normalized quantized sample value; The formula for calculating RMS is as follows:
[0030] In the formula, N is the number of sampling points in a frame. For example, if the sampling rate is 48kHz and the frame length is 20ms, then N=960.
[0031] Step S20: Construct a silent detection threshold based on the dynamic calibration value, static calibration value, and real-time detection value.
[0032] In practical use, in order to ensure the accuracy of the test, in addition to dynamic calibration values, the managers of the equipment who determine the cause of the fault can also pre-build static calibration values.
[0033] For example: Calibration is performed under the following conditions: vehicle stationary, pure electric mode (engine / range extender not started), all four windows closed, air conditioning off, and no conversation inside the vehicle. The microphone is placed at the very end of the front center armrest (near the rear air conditioning vents). Ambient noise is collected for 5 seconds, divided into 20ms frames (250 frames in total). The RMS value of each frame is calculated, and the average is taken. This process is repeated 3 times, and the final average is used as the static calibration value. Therefore:
[0034] In the formula, RMS base_i It can be the average RMS of each frame taken in the i-th iteration, RMS static It can be a static calibration value.
[0035] The number 3 is merely an example; it can be increased or decreased as needed, and this embodiment does not impose any restrictions on this.
[0036] Similarly, real-time calibration values can be pre-built. For example, calculate the RMS of the most recent 5 seconds of audio every 30 seconds, and use the median as the real-time calibration value. Then: RMSrealtime=median{RMS(t-4), RMS(t-3), RMS(t-2), RMS(t-1), RMS(t)}; In the formula, RMSrealtime can be the real-time calibration value, median{} can be the median calculation function, RMS(t) represents the RMS of the audio collected in the t-th second (i.e., within one second of the current time), and so on.
[0037] In practical use, after determining the dynamic calibration value, static calibration value, and real-time detection value, a weighted average can be applied. The weighted value is then used as a reference value. After converting the reference value into a linear value, it is multiplied by the coefficient to obtain the silent detection threshold.
[0038] The weighting coefficients during weighting can be determined based on the vehicle's driving status, for example: Weighted formula: RMS cali =w1 RMS sta +w2 RMS dy (V,mode,env) +w3 RMS re In the formula, RMS cali This can be used as a reference value, RMS. sta It can be a static calibration value, RMS dy It can be a dynamic calibration value, RMS reIt can provide real-time calibration values; When the driving state is stable, the environment is relatively stable, so we should prioritize tracking the current actual noise. At this time, we can set w1=0.15, w2=0.25, and w3=0.6. When the vehicle speed changes rapidly, the vehicle speed dominates the noise change, and the dynamic calibration values are referenced first: w1=0.15, w2=0.5, w3=0.35. When a sudden change in audio RMS or environmental change is detected, and the response to the actual change is accelerated, w1=0.10, w2=0.3, and w3=0.6 can be set. When switching power modes, the engine / range extender status changes, and the dynamic calibration value is referenced first. At this time, w1=0.10, w2=0.5, w3=0.4; After converting the reference value to a linear value and multiplying it by the coefficient, the silent detection threshold can be obtained, resulting in: RMS linear = 10^(RMS) cali / 20) Ton=RMS linear α; In the formula, Ton can be the silent detection threshold, and α can be a coefficient, the value of which can be determined based on the environmental signal-to-noise ratio (SNR): SNR>30dB, α=2.0; SNR∈[15, 30]dB, α=2.5 SNR<15dB, α=2.8.
[0039] When necessary, the silent detection threshold can include Toff in addition to Ton. Similarly, Toff = RMS. linear β; The value of β can also be determined based on the environmental signal-to-noise ratio: SNR>30dB, α=1.3; SNR∈[15, 30]dB, α=1.6 SNR<15dB, α=1.7.
[0040] If the silent detection threshold includes Ton and Toff, its application is as shown in the table below:
[0041] In actual verification, turning on the vehicle's air conditioning increases the background noise by 7 times (0.0002 → 0.0014). If a fixed threshold is used to determine whether there is sound, the background noise will be misjudged as sound when the air conditioning is on. However, when a dynamically constructed silent detection threshold is used, the silent detection threshold is adjusted in real time to above 0.0025, so that 0.0014 is correctly judged as silent, demonstrating the necessity of dynamic calibration.
[0042] Step S30: Perform sound detection on the PCM audio and the audio collected by sound pickup according to the silent detection threshold, and generate sound detection results.
[0043] It should be noted that PCM audio can be PCM audio data collected from the vehicle's underlying ALSA audio hardware via ADB. Audio acquired through microphone pickup can be audio stream data collected in real time via a microphone (such as an external microphone).
[0044] In practical use, to facilitate subsequent processing, PCM audio can be parsed to generate interactive waveforms and spectrograms, supporting time axis scaling and drag-and-drop positioning of problem time points; Simultaneously, the captured audio can be processed by a double-buffered pipeline and then displayed in real time at a refresh rate of 60fps, showing waveforms and spectrum diagrams.
[0045] Both types of processed data use the vehicle's system time as the time axis to achieve waveform-spectrum-log linkage: clicking any position on the waveform synchronously jumps to the corresponding spectrum slice and log line, reducing the accuracy of silent location from minutes to seconds. Simultaneously, a complementary acquisition mechanism using ADB to obtain PCM audio streams and a driverless microphone (external microphone) is employed, enabling a leap from single-point detection to end-to-end link (from the audio generation layer to speaker output) diagnosis. This further distinguishes between different types of issues such as internal system anomalies, hardware path failures, and environmental interference, significantly improving fault location capabilities. The vehicle's system time is used as the master clock, i.e., the reference time point, while the PC time and recording time are used as slave clocks. When obtaining the vehicle's system time via ADB commands, the RTT / 2 method (taking the midpoint of the ADB read command transmission and reception) can be used to compensate for transmission delays, achieving synchronization of the vehicle's system time, PC time, and recording time.
[0046] In practical implementation, the sound detection threshold can be combined to detect sound in PCM audio and audio from the pickup, and the presence or absence of sound in the two audios can be determined separately to generate sound detection results.
[0047] Step S40: Locate the cause of the fault based on the sound detection results.
[0048] In practical use, after determining the sound detection results, the possible fault types can be identified based on the sound detection cause. Then, further fault cause localization can be carried out to determine the specific fault cause.
[0049] This embodiment provides a method for determining the cause of a fault. Based on a dynamically constructed silent detection threshold, sound detection is performed on PCM audio and audio from the sound pickup, to determine whether there is sound or no sound. Sound detection results are generated, and the cause of the fault is roughly classified based on the sound detection results and further fault detection is performed, ensuring that it can assist relevant personnel in quickly determining the cause of the silent fault.
[0050] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 Step S40 includes steps S401 to S404: Step S401: Determine the major category of the fault based on the sound detection results.
[0051] It should be noted that different sound detection results may indicate different types of faults. Therefore, different sound detection results may correspond to different fault categories.
[0052] For example: if the sound detection result is that the PCM audio is audible, and the audio picked up is also audible, then it may be a false alarm. In this case, no fault category needs to be set, and no further detection needs to be performed. Instead, the detection log should be recorded directly. If the sound detection result shows that the PCM audio is audible, but the audio pickup is silent, then the fault category can be determined as audio driver abnormality. If the sound detection result shows no sound in the PCM audio, but the sound pickup audio has sound, then the fault category can be determined to be the routing error category. If the sound detection result is no sound in PCM audio and no sound is picked up in audio acquisition, then the fault category can be determined as application layer decoding anomaly.
[0053] Understandably, the sound detection results can only determine the general category of the fault, but not the more detailed fault type. Therefore, further analysis is needed. For example, the fault category may be application layer decoding anomaly, but the actual fault may also be format incompatibility, decoder malfunction, etc.; the fault category may be audio driver anomaly, but the actual fault may also be audio driver crash, driver error, or abnormal interference.
[0054] In practice, if the sound detection result is no sound in PCM audio but sound is picked up in audio acquisition, the possibility of a fault is relatively small. It is generally a routing error, that is, the sound routing channel is misconfigured. In this case, further detection can be discontinued to save detection time.
[0055] Of course, subsequent testing can still be performed independently, and this embodiment does not impose any restrictions on this.
[0056] Step S402: Match the vehicle logs according to the error keywords corresponding to the fault categories to generate matching results.
[0057] In practical use, the error keywords corresponding to the major fault categories can be obtained, and then the vehicle logs can be further matched to generate matching results to determine whether the error keywords can be matched.
[0058] In fact, a single keyword is not enough to determine the fault. Therefore, the fault category can correspond to a combination of at least one error keyword. For example, the error keyword combination corresponding to the AudioTrack exception can be "AudioTrack::write+failed / -12", and the error keyword combination corresponding to the driver crash can be "nd_pcm_writei+failed / -EIO".
[0059] To facilitate fault diagnosis, we can first obtain the error keywords corresponding to the fault category, and then match them with the vehicle logs to generate matching results.
[0060] In a specific implementation, to quickly perform log matching, step S402 in this embodiment may include: Based on the time of the fault and / or the time of the configuration change, relevant logs are extracted from the vehicle's logs in combination with a preset time window. The log level corresponding to each relevant log is determined based on the tags or fields of the relevant logs; Based on the retrieval level corresponding to the error keywords of the aforementioned fault categories, determine the logs to be matched for each error keyword; The matching results are generated by matching the erroneous keywords in the log to be matched.
[0061] It should be noted that the fault time can be the moment when a silent fault is detected or reported, and the configuration change time can be the moment when the audio configuration was last changed before the current time. The preset time window can be preset by the administrator who determines the cause of the fault. For example, if the preset time window is set to 5 seconds, the system will extract 5 seconds before and after the fault time from the vehicle's log, for a total of 10 seconds, centered on the fault time and / or configuration change time.
[0062] It is understandable that some faults may have already occurred after the configuration was modified. However, the faults may not have been discovered until much later (e.g., a configuration change that caused a silent fault occurred 10 minutes ago, but the fault was not discovered until 10 minutes later because no music or audio was played). Therefore, extracting relevant logs based on the time of the fault and / or the time of the configuration change can ensure that the corresponding logs are obtained for analysis in such cases.
[0063] In practical use, logs can be divided into corresponding levels by specific tags or fields. For example, if the log tags or fields include MediaPlayer, VoiceInteraction, etc., then the corresponding log level can be determined to be the application layer, i.e., [APP]; if the log tags or fields include AudioTrack, AudioManager, then the corresponding log level can be determined to be the framework layer, i.e., [FWK].
[0064] In practical applications, different erroneous keywords can also correspond to different retrieval levels. In order to improve the matching speed, the logs whose corresponding log levels are consistent with the retrieval levels corresponding to the erroneous keywords can be used as the logs to be matched for the erroneous keywords. Then, the erroneous keywords are matched in the logs to be matched to generate matching results.
[0065] For example, the retrieval level corresponding to the incorrect keyword combination "AudioTrack::write+failed / -12" is [FWK], and the retrieval level corresponding to the incorrect keyword combination "I2C+error+AD2428" is [HW-A2B].
[0066] Understandably, dividing logs based on hierarchy and determining the logs to be matched corresponding to the erroneous keywords according to the retrieval hierarchy can reduce unnecessary keyword matching and thus improve matching efficiency.
[0067] Step S403: If the matching result is a successful match, then determine the matching log line and determine the audio link interruption point based on the matching log line.
[0068] It should be noted that the complete link through which audio data flows from the application to the speaker is: [APP] → [FWK] → [HAL] → [DRV] → [HW-A2B] → [HW-Amp] → [HW-Speaker]. Different interruption points (i.e. the points where the link is interrupted due to an anomaly) can characterize the specific level at which the fault occurs.
[0069] In practical use, if the matching result is successful, it indicates that there is a corresponding fault. Therefore, the matching log line can be identified, and then the audio link interruption point can be determined based on the matching log line.
[0070] For example: if the log level corresponding to the matching log line is [HW-A2B], then the audio link interruption point is [HW-A2B].
[0071] Step S404: Determine the cause of the fault based on the audio link interruption point and the fault category.
[0072] In practical use, after identifying the audio link interruption point and the major category of the fault, the specific cause of the fault can be determined by combining the two.
[0073] For example, if the audio link interruption point is [HW-A2B] or [HW-Amp], and the fault category is routing selection error, then the cause of the fault can be determined as: incorrect configuration of the built-in / external power amplifier type.
[0074] In a specific implementation, if the sound detection result is no sound in the PCM audio and no sound in the audio pickup, but the keyword matching fails, then further judgment of the cause of the fault is required. Therefore, after step S402 in this embodiment, the following may also be included: If the matching result is a failure, then obtain the voice wake-up response information; Detect whether there are network error keywords in the voice wake-up response information; If present, check the vehicle network status; The cause of the fault is generated based on the vehicle network status.
[0075] It should be noted that if the sound detection result shows no sound in both PCM audio and audio pickup, but keyword matching fails, the silence may be due to network fluctuations. Therefore, the voice response content within 2 seconds before and after the moment the audio function is activated can be extracted from the vehicle's log, such as "I'm here," "Network connection failed," or "Please try again later."
[0076] Afterwards, it can detect whether there are network error keywords in the voice wake-up response information. The network error keywords can be preset by the administrator of the device who determines the cause of the fault, such as setting the network error keywords to "network unavailable", "no network connection", "please check the network", etc.
[0077] In actual use, if the voice wake-up response contains network error keywords, it means that the silence may also be due to application congestion caused by no network or unsuccessful command issuance. Therefore, the vehicle network status can be checked, and the cause of the fault can be generated based on the vehicle network status.
[0078] For example, the network status of the vehicle system can be determined by active detection (such as Ping + DNS resolution). If a network abnormality is found (such as a real network interruption / domain name resolution problem, or the network shows that it is smooth but cannot be accessed), it can be determined that the fault is caused by no network. It can prompt to check whether the TTS engine is blocked or whether the voice request is correctly called back. Conversely, if the network is normal, the cause of the fault can be determined to be an application layer parsing error, prompting a check to see if the data sent from the application layer is generated correctly.
[0079] In a specific implementation, if the sound detection result shows that the PCM audio is audible but the audio pickup is silent, and keyword matching fails, then further investigation to determine the cause of the fault is required. Therefore, after step S402 in this embodiment, the following may also be included: Control the vehicle to play test audio; The system detects whether the microphone has picked up the test audio and generates the detection result. The cause of the failure is constructed based on the test results.
[0080] It should be noted that if the sound detection result shows that the PCM audio is audible but the microphone is silent, and the keyword matching fails, it indicates that the problem may not be a software issue but a hardware one. In this case, the vehicle can be controlled to play the test audio, and then the microphone in the vehicle can be checked to see if it can pick up the test audio. This will generate a detection result, and the cause of the fault can be constructed based on the detection result.
[0081] For example, if the microphone can pick up the test audio, it can be determined that the silent fault is a misjudgment caused by environmental interference; conversely, if the microphone cannot pick up the test audio, it can be determined that the fault is caused by hardware failure.
[0082] The test audio can be high-frequency and high-volume audio, for example, audio with a frequency of 1kHz and a volume exceeding 60 decibels can be used as the test audio.
[0083] In practical applications, when the cause of the fault is determined to be a hardware fault, hardware diagnostic codes can be read from the hardware for further verification. For example, fault codes in the power amplifier chip register can be read via I2C to determine whether the fault is a short circuit, open circuit, overcurrent, overheating, etc.; a UDS diagnostic request (0x19 service) can be sent via the CAN bus to determine DTC reading, power amplifier status, etc.; and the A2B bus link status can be detected by setting the A2B_SWCTL.DIAGMODE bit.
[0084] This embodiment provides a method for determining the cause of a fault. First, the fault category is determined based on the sound detection results. Then, log matching is performed based on the error keywords corresponding to the fault category, and the audio link interruption point is determined based on the matching results. This ensures that the specific fault cause can be quickly determined by combining the audio link interruption point and the fault category.
[0085] Based on the first embodiment of this application, in the third embodiment of this application, the same or similar content as the above embodiment can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 Step S30 includes steps S301 to S304: Step S301: Extract energy from the PCM audio and the audio picked up by sound to obtain PCM energy and audio picked up by sound.
[0086] In practical applications, the RMS corresponding to the PCM audio can be calculated and used as the PCM energy. At the same time, the RMS corresponding to the audio collected by the microphone can be calculated and used as the audio energy of the microphone.
[0087] Step S302: Generate a first detection result based on the PCM energy and the silent detection threshold.
[0088] In practical use, the PCM energy can be compared with the silent detection threshold to determine whether the PCM audio has sound, thereby generating the first detection result.
[0089] The silent detection threshold may include both Ton and Toff. In fact, this is to detect the cause of the silent fault. At this time, PCM audio can be used as silent audio for detection. Therefore, it is only necessary to compare it with Ton. If the PCM energy is greater than Ton, it is determined that there is sound; otherwise, it is determined that there is no sound.
[0090] Step S303: Generate a second detection result based on the sound pickup audio energy and the silent detection threshold.
[0091] In practical use, the audio energy of the sound pickup can be compared with the silent detection threshold to determine whether there is sound in the audio pickup, thereby generating a second detection result.
[0092] The silent detection threshold may include both Ton and Toff. In fact, this is to detect the cause of the silent fault. At this time, the audio collected by the microphone can be used as silent audio for detection. Therefore, it is only necessary to compare it with Ton. If the microphone audio energy is greater than Ton, it is determined that there is sound; otherwise, it is determined that there is no sound.
[0093] Step S304: Construct a sound detection result based on the first detection result and the second detection result.
[0094] In practical use, the first detection result can be combined with the second detection result to construct the sound detection result.
[0095] In specific implementation, to ensure the accuracy of sound and silence detection, step S302 in this embodiment may include: The PCM energy is compared with the silent detection threshold to generate a comparison result; Auxiliary reference metrics are constructed based on the PCM audio; A first detection result is generated based on the comparison results and the auxiliary reference indicators.
[0096] It should be noted that the auxiliary reference indicators include at least one of the following: zero-crossing rate, spectral centroid, and harmonic ratio.
[0097] The formula for calculating the zero-crossing rate is as follows:
[0098] In the formula, ZCR is the zero-crossing rate; N can be the total number of sampling points; n is the index variable of the sampling point, from 1 to N, representing the nth sampling point currently being processed; x[n] can be the audio amplitude of the nth sampling point (usually a normalized floating-point number, such as the interval [-1.0, 1.0]); sgn(x[n]): sign function, defined as sgn(x[n]) = +1 if x[n]>0; and sgn(x[n]) = -1 if x[n]≤0.
[0099] The formula for calculating the spectral centroid is as follows:
[0100] In the formula, SC is the spectral centroid; k: frequency index variable, from 0 to N / 2 (N is the number of FFT points), representing the k-th frequency point; f k The actual frequency value (in Hz) corresponding to the k-th frequency point is determined by the sampling rate and the FFT length, for example, f k = k × (sampling rate / N); |X[k]|: the modulus of the complex spectrum amplitude at the k-th frequency point.
[0101] The formula for calculating the harmonic ratio is as follows:
[0102] In the formula, HNR is the harmonic ratio, and E noise E represents the noise energy in audio. harmonic This refers to the harmonic energy of audio.
[0103] In practical implementation, the first detection result can be generated by combining the comparison results and auxiliary reference indicators, for example: Set 4 conditions: RMS>T_on; ZCR ∈ [5%, 60%]; SC ∈ [200Hz, 4000Hz]; HNR>5dB; If all four conditions are met, the first detection result can be determined to be audible; If 0 conditions are met, the first detection result can be determined to be silent; If 1-3 conditions are met, it can be determined that there is suspected sound / suspected noise, and a second confirmation can be performed at this time; The secondary confirmation process can be as follows: increase the window for processing PCM audio from 20ms to 50ms, re-detect, and count the percentage of frames that meet the above conditions within 1 second: If the satisfaction rate of all four items is >70%, then the first test result is that there is real sound. RMS satisfaction rate >80%, missing items in other features → The first detection result is real sound (with slight environmental interference but mainly speech); All satisfaction rates are <50% → Noise (the first test result can be determined as silent, which facilitates subsequent diagnosis (such as log diagnosis) to determine the cause of the fault). In between → Low priority label, manual review recommended.
[0104] In practical applications, when constructing the second detection result, auxiliary reference indicators can be introduced in a similar way to those used when constructing the first detection result for comprehensive judgment. The specific implementation methods are basically the same, and will not be elaborated here.
[0105] This embodiment provides a method for determining the cause of a fault. This embodiment combines multiple auxiliary reference indicators and can perform further testing when it is difficult to determine whether there is sound or not, thereby improving the detection accuracy of silent / sound detection.
[0106] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the method for determining the cause of failure in this application. Any simple modifications based on this technical concept are within the protection scope of this application.
[0107] This application also provides a fault cause determination device, please refer to... Figure 4 The fault cause determination device includes: Calibration module 10 is used to determine dynamic calibration values based on vehicle operating conditions; Module 20 is used to construct a silent detection threshold based on the dynamic calibration value, static calibration value, and real-time detection value; The detection module 30 is used to perform sound detection on the PCM audio and the audio collected by sound pickup according to the silent detection threshold, and generate sound detection results; The determination module 40 is used to locate the cause of the fault based on the sound detection results.
[0108] The fault cause determination device provided in this application, employing the fault cause determination method in the above embodiments, can solve the technical problem that related technologies struggle to determine the cause of silent positioning faults in vehicles. Compared with the prior art, the beneficial effects of the fault cause determination device provided in this application are the same as those of the fault cause determination method provided in the above embodiments, and other technical features in the fault cause determination device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.
[0109] This application provides a fault cause determination device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the fault cause determination method in the first embodiment described above.
[0110] The following is for reference. Figure 5 The diagram illustrates a structural schematic suitable for implementing a fault cause determination device according to embodiments of this application. The fault cause determination device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The fault cause determination device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.
[0111] like Figure 5As shown, the fault cause determination device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the fault cause determination device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the fault cause determination device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a fault cause determination device with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.
[0112] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.
[0113] The fault cause determination device provided in this application, employing the fault cause determination method in the above embodiments, can solve the technical problem that related technologies struggle to determine the cause of silent positioning faults in vehicles. Compared with the prior art, the beneficial effects of the fault cause determination device provided in this application are the same as those of the fault cause determination method provided in the above embodiments, and other technical features of this fault cause determination device are the same as those disclosed in the previous embodiment method, and will not be repeated here.
[0114] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.
[0115] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
[0116] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the fault cause determination method in the above embodiments.
[0117] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.
[0118] The aforementioned computer-readable storage medium may be included in the fault cause determination device; or it may exist independently and not assembled into the fault cause determination device.
[0119] The aforementioned computer-readable storage medium carries one or more programs. When the one or more programs are executed by the fault cause determination device, the fault cause determination device: determines a dynamic calibration value based on the vehicle's operating conditions; constructs a silent detection threshold based on the dynamic calibration value, static calibration value, and real-time detection value; performs sound detection on the PCM audio and the audio collected by sound pickup based on the silent detection threshold, and generates sound detection results; and locates the fault cause based on the sound detection results.
[0120] Computer program code for performing the operations of this application can be written in one or more programming languages or a combination thereof. These programming languages include object-oriented programming languages—such as Python, Java, Smalltalk, and C++—and conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).
[0121] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.
[0122] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.
[0123] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described fault cause determination method, which can solve the technical problem that it is difficult to determine the cause of a silent fault in a vehicle using related technologies. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the fault cause determination method provided in the above embodiments, and will not be repeated here.
[0124] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the fault cause determination method described above.
[0125] The computer program product provided in this application can solve the technical problem that it is difficult to determine the cause of a silent positioning fault in a vehicle using related technologies. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the fault cause determination method provided in the above embodiments, and will not be repeated here.
[0126] All user-related data involved in this application (such as user privacy data, user behavior data, etc.) were obtained with the user's permission or consent; that is to say, when this application is used in a specific product or technology, user permission is required to obtain and process the relevant data, and the processing of the relevant data must comply with the relevant laws, regulations and regulatory standards of the relevant countries and regions.
[0127] The above description is only a part of the embodiments of this application and does not limit the scope of protection of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included in the scope of protection of this application.
Claims
1. A method for determining the cause of a fault, characterized in that, The method for determining the cause of the fault includes: Determine dynamic calibration values based on vehicle operating conditions; A silent detection threshold is constructed based on the dynamic calibration value, static calibration value, and real-time detection value. Based on the silent detection threshold, sound detection is performed on the PCM audio and the audio collected by sound pickup, and sound detection results are generated. The cause of the fault is located based on the sound detection results.
2. The method for determining the cause of a fault as described in claim 1, characterized in that, The fault location based on the sound detection results includes: Determine the major category of the fault based on the sound detection results; The vehicle logs are matched against the error keywords corresponding to the major fault categories to generate matching results; If the matching result is a successful match, then the matching log line is determined, and the audio link interruption point is determined based on the matching log line; The cause of the fault is determined based on the audio link interruption point and the fault category.
3. The method for determining the cause of a fault as described in claim 2, characterized in that, The sound detection result is that the PCM audio is silent and the audio collected by the sound pickup is silent. After matching the vehicle logs based on the error keywords corresponding to the possible fault types and determining the matching results, the process further includes: If the matching result is a failure, then obtain the voice wake-up response information; Detect whether there are network error keywords in the voice wake-up response information; If present, check the vehicle network status; The cause of the fault is generated based on the vehicle network status.
4. The method for determining the cause of a fault as described in claim 2, characterized in that, The sound detection result is that the PCM audio is audible, but the audio collected by the microphone is silent. After matching the vehicle logs based on the error keywords corresponding to the possible fault types and determining the matching results, the process further includes: Control the vehicle to play test audio; The system detects whether the microphone has picked up the test audio and generates the detection result. The cause of the failure is constructed based on the test results.
5. The method for determining the cause of a fault as described in claim 2, characterized in that, The step of matching the vehicle logs based on the error keywords corresponding to the fault categories and generating matching results includes: Based on the time of the fault and / or the time of the configuration change, relevant logs are extracted from the vehicle's logs in combination with a preset time window. The log level corresponding to each relevant log is determined based on the tags or fields of the relevant logs; Based on the retrieval level corresponding to the error keywords of the aforementioned fault categories, determine the logs to be matched for each error keyword; The matching results are generated by matching the erroneous keywords in the log to be matched.
6. The method for determining the cause of a fault as described in any one of claims 1-5, characterized in that, The step of performing sound detection on the PCM audio and the audio collected by sound pickup according to the silent detection threshold, and generating sound detection results, includes: Energy was extracted from both the PCM audio and the audio picked up by sound pickup to obtain the PCM energy and the audio pickup energy. A first detection result is generated based on the PCM energy and the silent detection threshold. A second detection result is generated based on the audio energy of the sound pickup and the silent detection threshold. The sound detection results are constructed based on the first detection result and the second detection result.
7. The method for determining the cause of a fault as described in claim 6, characterized in that, The step of generating a first detection result based on the PCM energy and the silent detection threshold includes: The PCM energy is compared with the silent detection threshold to generate a comparison result; Based on the PCM audio, an auxiliary reference index is constructed, which includes at least one of zero-crossing rate, spectral centroid, and harmonic ratio. A first detection result is generated based on the comparison results and the auxiliary reference indicators.
8. A device for determining the cause of a fault, characterized in that, The fault cause determination device includes: The calibration module is used to determine dynamic calibration values based on vehicle operating conditions; The construction module is used to construct a silent detection threshold based on the dynamic calibration value, static calibration value, and real-time detection value; The detection module is used to perform sound detection on the PCM audio and the audio collected by sound pickup according to the silent detection threshold, and generate sound detection results; The determination module is used to locate the cause of the fault based on the sound detection results.
9. A fault cause determination device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the fault cause determination method as described in any one of claims 1 to 7.
10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the fault cause determination method as described in any one of claims 1 to 7.