Charging equipment cloud call fault diagnosis method and device and computer equipment

Abstract

The invention relates to a cloud call fault diagnosis method and device for charging equipment and computer equipment, and belongs to the technical field of equipment communication.The method comprises the steps that a communication channel is established, and an interaction module containing a voice recognition engine is loaded, through framing processing and acoustic model matching, user natural language description is converted into a textualized fault feature group containing charging abnormity keywords; calling a corresponding detection instruction set from a pre-constructed knowledge graph based on the fault feature group, collecting equipment operation parameters in real time, and verifying the equipment operation parameters through a dynamic threshold algorithm; according to a verification result, voice feedback is performed when no fault exists, abnormal parameters are marked when abnormity occurs, the equipment state is marked, and the external communication function is limited. The core technology comprises standardized component multiplexing and process configuration of a voice interaction module, detection instruction dynamic matching based on a knowledge graph, parameter dynamic threshold verification combined with historical data and a real-time state, and equipment state closed-loop control after a fault.

Description

Technical Field

[0001] The present invention relates to the field of device communication technology, and in particular to a method and device for diagnosing cloud call faults of charging devices, and a computer device. Background Art

[0002] With the increasing popularity of new energy equipment and smart charging facilities, the demand for remote fault diagnosis of charging equipment is growing. Existing fault diagnosis solutions for charging equipment primarily rely on manual troubleshooting or automated testing based on pre-set rules. Manual diagnosis requires on-site intervention from maintenance personnel, which is inefficient and limited by their expertise. Ordinary users can typically only describe abnormal phenomena in natural language, making it difficult to extract fault signatures. Summary of the Invention

[0003] The main purpose of the present invention is to provide a charging device cloud call fault diagnosis method, device and computer equipment, aiming to solve the problems of high user interaction threshold, low diagnostic efficiency and non-closed-loop fault handling in the prior art.

[0004] To achieve the above objectives, the present invention provides a method for diagnosing charging device cloud call faults, comprising the following steps: Obtaining a call request from the charging device to access the cloud system, establishing a communication channel based on the call request, and loading an interactive module for fault guidance into the channel; The interactive module performs frame processing and acoustic model matching on the user's voice input to extract a textual fault feature group containing charging abnormality keywords; According to the fault feature group, a corresponding detection instruction set is retrieved from a pre-built equipment diagnosis knowledge base, wherein the equipment diagnosis knowledge base stores a mapping relationship between fault features and detection instructions; Running the detection instructions carried by the detection instruction set in real time and correspondingly collecting corresponding operating parameters of the charging device, and verifying the corresponding operating parameters using a preset algorithm; If the verification results meet the preset standards, the interactive module will provide voice feedback indicating that there is no fault. If the verification result is abnormal, an abnormal parameter anchor point is generated and marked, and then the charging device status is marked as abnormal through the cloud system, and the control module is triggered to limit the external communication function of the charging device.

[0005] Furthermore, the step of loading an interactive module for fault guidance into the channel includes: Retrieving standardized module components including a speech recognition engine, a fault knowledge base interface, and an interactive logic controller from a diagnostic function component library stored in the cloud system. The speech recognition engine supports noise reduction and keyword extraction of specialized charging terminology. The interaction module is obtained by loading the standardized module component into the call channel and configuring the fault guidance process of the standardized module component. The fault guidance process includes a preset fault guidance speech library, a user question response time threshold and multi-round dialogue logic rules.

[0006] Furthermore, the step of performing frame processing and acoustic model matching on the user voice input by the interactive module to extract a textual fault feature group containing charging abnormality keywords includes: Perform endpoint detection on the user's voice stream to intercept valid voice segments, and divide the valid voice segments into frames according to the preset duration and preset interval; Preprocess the framed speech signal and extract acoustic feature parameters to construct a speech acoustic feature vector sequence; Inputting the acoustic feature vector sequence into a pre-trained neural network model, wherein the neural network model is trained based on a corpus of charging equipment failure scenarios to achieve temporal correlation matching between speech frames and charging anomaly keywords; Identify the keywords output by the neural network model and determine whether the keywords belong to professional terms related to charging equipment failures; The professional terms are semantically associated with a preset fault feature mapping table to generate a textual fault feature group including the fault type and severity. The fault feature mapping table is constructed based on a charging equipment fault code library, and each professional term corresponds to at least one standardized fault feature parameter.

[0007] Furthermore, the acoustic feature vector sequence is input into a pre-trained neural network model, and the step of outputting keywords from the neural network model includes: Inputting the acoustic feature vector sequence into an encoder layer of a neural network model, wherein the encoder layer comprises at least two layers of bidirectional gated recurrent unit structures for extracting temporal dependencies of speech features; Calculating the weight distribution of the feature vectors of each time step output by the encoder layer through the attention mechanism to generate a weighted feature representation; Inputting the weighted feature representation into a decoder layer of a neural network model, wherein the decoder layer comprises at least one fully connected layer and a softmax classifier for predicting a phoneme probability distribution corresponding to each time step; Constructing a word graph search space based on the phoneme probability distribution, performing path decoding in the search space using a dictionary-constrained Viterbi algorithm to generate a candidate word sequence; Reordering the candidate word sequences using a language model, where the language model is trained based on technical documentation and fault case data in the field of charging equipment, and is used to calculate language probability scores for the candidate word sequences; Output the candidate word sequence with the highest language probability score as the recognition keyword.

[0008] Furthermore, the step of retrieving a corresponding detection instruction set from a pre-built device diagnosis knowledge base according to the fault feature group includes: Converting the fault feature group into a structured feature tuple containing the fault type and severity; Mapping the feature tuple to a pre-built knowledge graph, wherein the knowledge graph stores the association between fault features and detection instructions; Based on the mapping result, matching detection instructions are retrieved to generate a detection instruction set, wherein each detection instruction in the detection instruction set is associated with at least one parameter indicator for evaluating the status of the charging device.

[0009] Furthermore, the steps of running the detection instructions carried by the detection instruction set in real time and correspondingly collecting corresponding operating parameters of the charging device, and verifying the corresponding operating parameters using a preset algorithm include: Construct a multidimensional parameter vector by using the parameter indicators associated with each detection instruction in the detection instruction set ,in Represents the real-time collection value of the i-th parameter indicator; For each parameter indicator , generating a threshold interval according to the operating status of the charging device ,in , , For parameters The historical benchmark value of is the historical standard deviation, and is the operating parameter; During the verification process, the calculation The abnormal deviation

[0010] Calculate the score of the parameter index associated with each detection instruction in the detection instruction set ,in , the For operating parameters The threshold T, For operating parameters The threshold T.

[0011] Furthermore, if the verification results all meet the preset standards, the step of providing a fault-free information feedback via the interactive module voice includes: If the score of each detection instruction in the detection instruction set If all scores are above the preset score, it is determined to meet the preset standards; There is no fault information through voice feedback of the interactive module.

[0012] Furthermore, if the verification result is abnormal, an abnormal parameter anchor point is generated and marked, and then the device status is marked as abnormal through the cloud system, and the control module is triggered to limit its external communication function, including the following steps: If the score of each detection instruction in the detection instruction set If at least one of the items is below the preset score, it is determined that the corresponding fault anomaly exists; Based on specific detection instructions, the abnormal parameters are anchored and marked for subsequent maintenance. The corresponding charging device status is then marked as abnormal through the cloud system, restricting the charging device from communicating externally.

[0013] The present invention provides a charging device cloud call fault diagnosis device, comprising: A communication unit, configured to obtain a call request from the charging device to access the cloud system, establish a communication channel based on the call request, and load an interactive module for fault guidance into the channel; a recognition unit configured to perform frame processing and acoustic model matching on the user voice input through the interaction module, and extract a textual fault feature group containing charging abnormality keywords; A mapping unit, configured to retrieve a corresponding detection instruction set from a pre-built equipment diagnosis knowledge base according to the fault feature group, wherein the equipment diagnosis knowledge base stores a mapping relationship between fault features and detection instructions; A testing unit, configured to execute the detection instructions carried by the detection instruction set in real time and correspondingly collect corresponding operating parameters of the charging device, and verify the corresponding operating parameters using a preset algorithm; The first information unit is used to provide a fault-free information feedback via the interactive module voice if the verification results meet the preset standards; The second information unit is used to generate and mark an abnormal parameter anchor point if there is an abnormality in the verification result, then mark the charging device status as abnormal through the cloud system, and trigger the control module to limit the external communication function of the charging device.

[0014] The present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the steps of the above-mentioned charging device cloud call fault diagnosis method are implemented.

[0015] The charging device cloud call fault diagnosis method, device, and computer device provided by the present invention have the following beneficial effects: (1) By loading an interactive module with an integrated speech recognition engine into the communication channel, users can describe faults in natural language, automatically extract charging abnormality keywords and generate fault feature groups. This eliminates the need for users to master professional terminology, significantly lowers the operational threshold for fault diagnosis, and shortens manual communication and information conversion time.

[0016] (2) Based on the pre-built equipment diagnostic knowledge base and knowledge graph, the detection instruction set is retrieved according to the fault feature group, and the operating parameters are verified through the preset algorithm. The dynamic threshold range is generated in combination with the historical operation data of the equipment to avoid the blindness of traditional detection and improve the accuracy of fault location and detection efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 It is a flowchart of a method for diagnosing a charging device cloud call fault in one embodiment of the present invention; Figure 2 This is a structural block diagram of a device for diagnosing cloud call faults in a charging device according to an embodiment of the present invention; Figure 3 It is a schematic block diagram of the structure of a computer device according to an embodiment of the present invention.

[0018] The purpose, features and advantages of the present invention will be further described with reference to the accompanying drawings and in conjunction with the embodiments. DETAILED DESCRIPTION

[0019] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0020] Reference Figure 1 This is a flow chart of the charging device cloud call fault diagnosis method proposed by the present invention. The method uses a computer device as the execution subject, and the execution of the corresponding method includes the following steps: S1, obtaining a call request from a charging device to access a cloud system, establishing a communication channel based on the call request, and loading an interactive module for fault guidance into the channel; S2, performing frame processing and acoustic model matching on the user voice input by the interactive module to extract a textual fault feature group containing charging abnormality keywords; S3, according to the fault feature group, retrieve a corresponding detection instruction set from a pre-built device diagnosis knowledge base, wherein the device diagnosis knowledge base stores a mapping relationship between fault features and detection instructions; S4, executing the detection instructions carried by the detection instruction set in real time and correspondingly collecting corresponding operating parameters of the charging device, and verifying the corresponding operating parameters using a preset algorithm; S51, if the verification results meet the preset standards, a fault-free message is fed back via the interactive module voice; S52: If the verification result is abnormal, an abnormal parameter anchor point is generated and marked, and then the charging device status is marked as abnormal through the cloud system, and the control module is triggered to limit the external communication function of the charging device.

[0021] In the embodiment of the above step S1, When a user drives a vehicle to be charged (such as a new energy vehicle or battery car) into a charging station and starts charging, the charging device monitors in real time whether the user requests a voice call. The call is set on the charging device, and the charging device uses a networking unit to establish communication with the cloud platform. When the user makes a call request using the charging device, it is considered that the charging device currently has at least one fault and a communication channel is established. The steps of loading an interactive module for fault guidance into a channel include: Retrieving standardized module components including a speech recognition engine, a fault knowledge base interface, and an interactive logic controller from a diagnostic function component library stored in the cloud system. The speech recognition engine supports noise reduction and keyword extraction of specialized charging terminology. The interaction module is obtained by loading the standardized module component into the call channel and configuring the fault guidance process of the standardized module component. The fault guidance process includes a preset fault guidance speech library, a user question response time threshold and multi-round dialogue logic rules.

[0022] In this embodiment, loading the interactive module for fault guidance within the channel is a key step in connecting the user's natural language fault description with the charging device's automated diagnosis. In specific implementation, standardized module components are retrieved from a diagnostic component library stored in the cloud. These components are pre-developed and packaged functional units for charging device fault diagnosis scenarios, including three core components: a speech recognition engine, a fault knowledge base interface, and an interactive logic controller. Among them, the voice recognition engine has been specially optimized and can reduce the noise of user voice input. It is particularly good at filtering out common background noise in the operating environment of charging equipment (such as cooling fan noise, current noise, etc.), and accurately extracting keywords related to charging failures, such as "charging interruption", "hot interface", "abnormal indicator light", "repeated deductions", etc. It is trained based on a large amount of voice data from charging equipment failure scenarios and can recognize daily fault descriptions; the fault knowledge base interface serves as a connection between the interaction module and the back-end diagnostic knowledge base, supporting real-time retrieval of the fault characteristics and detection instruction mapping relationship stored in the cloud, ensuring that the user description obtained during the interaction process can be quickly associated with the corresponding diagnostic strategy; the interactive logic controller is responsible for managing the entire dialogue process. Through the built-in state machine algorithm, it dynamically determines the next guidance strategy based on the user's current input. For example, after the user describes "charging failure" for the first time, the preset follow-up logic is automatically triggered to further ask "whether there is an error prompt when failing" or "the number of charging attempts" to refine the fault characteristics.

[0023] In the embodiment of the above step S2, The step of performing frame processing and acoustic model matching on the user voice input by the interactive module to extract a textual fault feature group containing charging abnormality keywords includes: Perform endpoint detection on the user's voice stream to intercept valid voice segments, and divide the valid voice segments into frames according to the preset duration and preset interval; Preprocess the framed speech signal and extract acoustic feature parameters to construct a speech acoustic feature vector sequence; Inputting the acoustic feature vector sequence into a pre-trained neural network model, wherein the neural network model is trained based on a corpus of charging equipment failure scenarios to achieve temporal correlation matching between speech frames and charging anomaly keywords; Identify the keywords output by the neural network model and determine whether the keywords belong to professional terms related to charging equipment failures; The professional terms are semantically associated with a preset fault feature mapping table to generate a textual fault feature group including the fault type and severity. The fault feature mapping table is constructed based on a charging equipment fault code library, and each professional term corresponds to at least one standardized fault feature parameter.

[0024] During the implementation of step S2, Endpoint detection is performed on the user's voice stream, using an energy threshold or dual-threshold algorithm to identify the start and end points of the voice. Silence segments and background noise are removed, retaining only valid voice segments (such as the key voice segment describing the fault). These valid segments are then framed using a preset time window (for example, a frame length of 20-30ms and a frame shift of 10-15ms), converting the continuous voice signal into a sequence of short, independently processable frames.

[0025] The framed speech signal is sequentially subjected to pre-emphasis (enhancing high-frequency components to enhance speech clarity), windowing (reducing spectral leakage), and fast Fourier transform (FFT) to convert the time domain signal into a frequency domain representation. Acoustic feature parameters such as Mel-frequency cepstral coefficients (MFCC) and linear prediction cepstral coefficients (LPCC) are then extracted to construct a speech acoustic feature vector sequence containing hundreds of dimensional features. The speech acoustic feature vector sequence retains the spectral envelope information of the speech, and the Mel-scale mapping is used to simulate the auditory characteristics of the human ear, which can effectively distinguish speech units related to "charging anomalies" (such as the spectral difference between "power outage" and "disconnection"). Specifically, a pre-emphasis filter (usually a first-order FIR filter H(z)=1) is applied to each frame of the speech signal. αz 1, where α is set to 0.95-0.97), by boosting the high-frequency components (usually in the 2-8kHz frequency band, which contains the characteristic frequencies of keywords such as "power outage" and "disconnection"), the high-frequency energy attenuation of the voice signal during transmission is compensated, making the voice spectrum flatter and enhancing the resolution of subsequent feature extraction. Subsequently, a Hamming window is applied to the pre-emphasized voice frame, and the Hamming window formula is used. The weighted processing (which belongs to the existing formula and will not be explained in detail in this invention) reduces the spectrum leakage phenomenon caused by signal truncation. This processing makes the signal at the frame boundary transition smoothly, avoids the appearance of false high-frequency components in the frequency domain, and thus more accurately preserves the spectral characteristics of the speech. The windowed speech frame is input into the fast Fourier transform (FFT) module, and the time domain signal is converted into a frequency domain representation through an efficient algorithm (such as the Cooley-Tukey algorithm) to generate a spectrum diagram containing amplitude and phase information. In practical applications, a 512 or 1024-point FFT is usually used to convert each frame of speech into a complex representation of the corresponding frequency domain. Based on the FFT results, feature parameters such as Mel-frequency cepstral coefficients (MFCC) and linear prediction cepstral coefficients (LPCC) are extracted. During the MFCC extraction process, the FFT spectrum is nonlinearly mapped through a Mel filter bank (usually containing 20-40 triangular filters), which is based on the Mel scale. ) converts the linear frequency f into a logarithmic frequency, which is more sensitive to the human ear, highlighting the resonance peak characteristics of the speech (for example, the / d / sound in the word "power off" corresponds to a resonance peak of 600-900Hz, and the / x / sound in the word "broken line" corresponds to a resonance peak of 2000-3000Hz). The filtered spectrum is then logarithmized and subjected to a discrete cosine transform (DCT) to obtain 12-20 dimensional MFCC coefficients. Low-order coefficients (such as C1-C5) primarily characterize the spectral envelope of the speech, while high-order coefficients (such as C12-C20) reflect detailed changes in the spectrum. LPCC features are extracted using linear prediction analysis technology. This technology, based on the assumption that the current speech sample can be predicted by a linear combination of several past samples, characterizes the spectral characteristics of speech by minimizing the prediction error (i.e., the linear prediction coefficient LPC). Converting the LPC coefficients to a cepstral domain representation (LPCC) using a recursive formula yields complementary feature information to that of the MFCC: LPCC is better at capturing short-term spectral characteristics of speech (such as transient energy variations in plosives), while MFCC focuses more on the long-term spectral envelope of speech. These two features are typically combined to construct a vector sequence containing 50-100 dimensional features, each corresponding to the acoustic feature representation of a speech frame. Through Mel-scale mapping and cepstral transform, these feature vectors effectively simulate the human ear's perception of different frequencies, resulting in distinct separation in the feature space between similar-sounding but semantically distinct keywords such as "power outage" and "disconnected." For example, the MFCC feature for "power outage" is concentrated in the low-frequency region (300-1000Hz), while the feature for "disconnected" exhibits a stronger response in the mid- and high-frequency regions (1500-3500Hz). Classification training of the feature vectors using a support vector machine (SVM) or deep neural network (DNN) enables high-precision recognition of keywords related to charging equipment failures. This fault keyword extraction technology based on speech acoustic features not only overcomes the problem of traditional keyword matching methods being sensitive to pronunciation changes, but also effectively solves the common homophone ambiguity (such as the homophones "voltage" and "electricity price") and connected reading phenomena in natural language through temporal correlation analysis of feature vectors (such as hidden Markov model HMM).

[0026] In another embodiment, the neural network model processes the acquired acoustic feature vector sequence using an encoder-decoder architecture. The encoder layer comprises a bidirectional gated recurrent unit (Bi-GRU) or a long short-term memory (LSTM) network, which can capture temporal dependencies between speech frames (e.g., the contextual semantic association between "charging" and "interruption"). The decoder layer uses an attention mechanism to focus on key speech frames, combined with a softmax classifier to predict frame-level keywords, and finally generates a continuous keyword sequence using a CTC algorithm or Viterbi decoding. The keywords output by the model are verified against a professional terminology library. The pre-defined charging equipment fault terminology library contains over 200 standardized terms (e.g., "poor contact," "protocol error," and "overvoltage protection"). Semantic similarity calculations (e.g., cosine similarity) are used to determine whether the keyword falls within the given category, eliminating irrelevant expressions (e.g., non-fault descriptions of user inquiries about operating procedures). In this additional embodiment, the encoder layer is constructed using a bidirectional gated recurrent unit (Bi-GRU) and a long short-term memory (LSTM) network. The recursive neural network structure captures long-range dependencies between speech frames through iterative updates of hidden states. Taking the Bi-GRU as an example, it consists of two GRU units, forward and backward. The forward unit processes from the start point to the end point of the speech frame sequence, capturing the "previous" context (for example, "charging" provides thematic foreshadowing for the subsequent "interruption"). The backward unit processes from the end point to the start point, capturing "later" dependencies (for example, the semantic qualification of "interruption" on "charging"). The concatenated vector of the two outputs fully represents the semantic features of the current frame within the context. Compared to traditional unidirectional RNNs, the Bi-GRU / LSTM effectively solves the vanishing gradient problem through gating mechanisms (reset gate and update gate). This makes it particularly suitable for long sentences commonly found in charging equipment fault descriptions (for example, "After connecting to the charging station, the device displays a communication failure, but the mobile app can search for the device").

[0027] The candidate keyword sequences output by the neural network model are verified against a professional terminology database to ensure semantic validity. The pre-defined charging equipment fault terminology database contains over 200 standardized terms, covering core fault types such as hardware faults (poor contact, damaged cable), communication anomalies (protocol errors, IP address conflicts), and electrical parameter violations (overvoltage protection, undercurrent faults). During the verification process, these terms are converted into high-dimensional vectors using word embedding techniques (such as Word2Vec), and cosine similarity is calculated with the vector representations of the terms in the terminology database. When a similarity threshold (such as 0.85) is reached, the keyword is considered a fault-related term; otherwise, it is considered invalid input (e.g., when a user asks an operational question like "How do I check my charging history?"). For example, if the model outputs "unable to charge," it is matched with "charging interruption" in the terminology database through cosine similarity calculation (similarity 0.91), retained, and mapped to the corresponding fault type. If the output is "how to get a refund," it is discarded because the similarity falls below the threshold. This dual verification mechanism (temporal dependency modeling + semantic validity filtering) ensures that the keywords input into the subsequent fault feature generation module contain both contextual semantic associations and are strictly limited to the professional scope of charging equipment fault diagnosis. This effectively avoids the interference of non-fault information on the diagnostic process and provides reliable semantic input for constructing an accurate fault feature group.

[0028] For verified professional terms, semantic parsing is further performed using a fault feature mapping table. This mapping table, built on a device fault code library, establishes a one-to-one correspondence between natural language terms and standardized fault parameters. For example, "frequent charging disconnections" corresponds to the fault type "communication link abnormality," severity "intermediate," and the associated detection instruction "check USB port contact resistance." "Device becomes hot and smoking" corresponds to the fault type "hardware overheating," severity "urgent," and the forced power-off control instruction. This mapping mechanism transforms unstructured user descriptions into textual feature sets containing parameters such as fault type, impact, and associated components. For example, a user statement such as "Connection failed after plugging in the charger, and changing the cable doesn't help" is parsed into structured data (fault type = physical connection failure, severity = high, associated component = charging port / cable). This provides accurate semantic indexing for subsequently retrieving targeted detection instructions from the device diagnostic knowledge base. The entire process, through end-to-end speech processing and semantic analysis, automates the transition from natural language input to fault feature extraction, eliminating the inefficiency of manual annotation while ensuring the accuracy and completeness of fault information.

[0029] During the implementation of step S3, The step of retrieving a corresponding detection instruction set from a pre-built device diagnosis knowledge base according to the fault feature group includes: Converting the fault feature group into a structured feature tuple containing the fault type and severity; Mapping the feature tuple to a pre-built knowledge graph, wherein the knowledge graph stores the association between fault features and detection instructions; Based on the mapping result, matching detection instructions are retrieved to generate a detection instruction set, wherein each detection instruction in the detection instruction set is associated with at least one parameter indicator for evaluating the status of the charging device.

[0030] In this embodiment, extracted textual fault feature groups (e.g., "Charging interruptions, frequent occurrence") are converted into structured feature tuples containing fault types (e.g., "communication link anomaly," "hardware connection failure") and severity levels (e.g., "urgent," "intermediate," "low"). This conversion process relies on a pre-defined fault feature mapping table, which associates natural language fault keywords (e.g., "unable to charge," "frequent disconnections") with standardized fault classification systems (referring to GB / T34657.2-2017, "Connection Devices for Conductive Charging of Electric Vehicles") for fault codes. For example, "the indicator light flashes while charging" is mapped to (fault type = power module anomaly, severity = intermediate).

[0031] The pre-built equipment diagnostic knowledge base is stored using knowledge graph technology. Its core structure is a semantic network with fault feature nodes (such as "overvoltage protection" and "protocol handshake failure") and detection instruction nodes (such as "read the real-time value of charging voltage" and "verify the TCP / IP communication protocol stack") as entities, and "association relationships" as edges. Each fault feature node contains attribute labels (such as the fault-affected component and common occurrence scenarios), while the detection instruction node is associated with parameter indicators (such as the voltage detection range and communication message parsing rules). When a structured feature tuple is input, a bidirectional search is performed using a graph database query language (such as Cypher): first, the fault feature node that matches the fault type and severity is located (for example, filtering nodes using "fault type = hardware connection failure AND severity = emergency"), then traversing along the edges of the "associated detection instruction" to obtain all directly or indirectly connected detection instruction nodes.

[0032] During the retrieval process, the generation of the detection instruction set is optimized according to pre-set inference rules. For faults with an "urgent" severity (such as a hardware overheating fault corresponding to "device smoking"), control instructions that immediately shut off the power supply are prioritized. For "intermediate" faults (such as "abnormal charging speed"), detection instructions are prioritized according to the "software first, hardware second" principle (first "check charging protocol configuration," then "check charging module temperature"). The parameter indicators associated with each detection instruction (such as the "voltage detection instruction" associated with the normal threshold of "rated voltage ±10%" and the "communication detection instruction" associated with the performance indicator of "TCP three-way handshake response time <500ms") directly determine the collection points and verification rules for the operating parameters in the subsequent step S4. For example, the detection instruction set retrieved for the "charging interruption" fault might include: ① checking the charging port contact resistance (parameter indicator: contact resistance <50mΩ); ② capturing communication logs to verify heartbeat messages (parameter indicator: no heartbeat message within 10s is considered an abnormality); and ③ reading the power module temperature sensor value (parameter indicator: temperature >85°C triggers overheat protection).

[0033] Through this knowledge graph-based mapping and retrieval mechanism, the optimal detection strategy can be dynamically generated according to the personalized fault scenario described by the user, avoiding the blindness of the traditional fixed detection process.

[0034] During the implementation of step S4, The steps of running the detection instructions carried by the detection instruction set in real time and correspondingly collecting corresponding operating parameters of the charging device, and verifying the corresponding operating parameters using a preset algorithm include: Construct a multidimensional parameter vector by using the parameter indicators associated with each detection instruction in the detection instruction set ,in Represents the real-time collection value of the i-th parameter indicator; For each parameter indicator , generating a threshold interval according to the operating status of the charging device ,in , , For parameters The historical benchmark value of is the historical standard deviation, and is the operating parameter; During the verification process, the calculation The abnormal deviation

[0035] Calculate the score of the parameter index associated with each detection instruction in the detection instruction set ,in , the For operating parameters The threshold T, For operating parameters The threshold T.

[0036] In this embodiment, running the detection instructions in real time and verifying the operating parameters are the key steps in converting the diagnostic strategy into actual device status assessment. The core of this is to achieve accurate verification of the charging device operating parameters through a dynamic threshold algorithm. Specifically, the detection instruction set is first parsed. For each detection instruction-associated parameter indicator (e.g., "detect charging interface contact resistance" corresponds to "contact resistance value", "verify heartbeat message" corresponds to "message response time"), data is collected in real time through the device communication interface (e.g., CAN bus, Ethernet API), and a multidimensional vector P containing n parameters is constructed. , ,..., ],in is the real-time measurement value of the i-th parameter (such as =45mΩ means the interface contact resistance is 45 milliohms).

[0037] For each parameter , generating dynamic threshold intervals based on historical equipment operation data =[ _min, _max], the interval is calculated by the formula _min / max=α· ±β· Calculated, where For parameters Historical average under normal operating conditions (such as the average contact resistance of similar equipment in the past 7 days), is the historical standard deviation (reflecting the range of parameter fluctuations), and α and β are state adjustment coefficients (0 < α ≤ 1, β ≥ 1), which are dynamically adjusted based on the device's current operating mode (for example, in fast charging mode, β increases to relax the threshold for instantaneous voltage fluctuations, while in slow charging mode, α decreases to improve detection sensitivity). Taking the charging voltage parameter as an example, if the historical mean μ = 400V, the standard deviation σ = 5V, and in fast charging mode, α = 0.95 and β = 2, the threshold range is [385V, 415V], allowing for short-term voltage fluctuations. In slow charging mode, α = 1.0 and β = 1.5, and the threshold is tightened to [392.5V, 407.5V], ensuring parameter stability in low-power scenarios.

[0038] In the verification phase, first calculate the abnormal deviation of each parameter , this indicator is passed =| - | / (applicable to proportional parameters such as contact resistance, efficiency percentage) or =| - _min| / ( _max- _min) (applicable to absolute value parameters, such as temperature and voltage) quantifies the degree to which the parameter deviates from the normal state. For example, if the real-time voltage p = 420V, the historical mean μ = 400V, and the threshold interval is [380V, 420V], then =(420-400) / 400=5%, which means the voltage is 5% higher than the mean. For parameters such as "message response time", the smaller the better, the deviation is calculated as =( - _max) / _max (if the upper threshold _max=500ms, measured p=600ms, then =20%, indicating that the response time exceeds the standard by 20%).

[0039] Parameter scoring of detection instructions Based on the abnormal deviation and preset weight, the formula is: = ·(1- ),in is the parameter importance weight (determined by the equipment fault propagation model, such as voltage parameter ω=0.3, communication parameter ω=0.2). For example, the contact resistance parameter weight ω=0.25, if =10% (i.e. the resistance value exceeds the historical average by 10%), then the score =0.25 (1-0.1)=0.225. The preset passing score line (such as 0.8) is set. If all parameter scores are higher than the passing score line, the verification is considered to be passed. If there is <0.8, triggering the abnormality flagging process. This dynamic threshold and weighted scoring mechanism takes into account both the historical fluctuations of parameters and the current operating status of the device (such as load factor and ambient temperature). Compared to traditional static threshold verification (such as a fixed voltage limit of 400V), it can improve the accuracy of abnormal parameter identification by over 30%, effectively reducing misjudgments caused by individual device differences or changes in operating conditions.

[0040] The entire verification process achieves real-time quantitative evaluation of the operating status of the charging equipment through a closed-loop algorithm of "parameter collection - dynamic threshold generation - deviation calculation - weighted scoring". For example, when the detection instruction set includes "detecting the charging module temperature" and "verifying the charging protocol version", the temperature sensor value ( =90℃) and protocol version number ( = V2.0), the former generates a threshold interval [≤85°C] based on historical data (β = 1.2, tightening the threshold in high temperature scenarios), and calculates =5.88%, rating =0.2 (1-0.0588)=0.188; if the default version is V2.1 or above, the actual measurement =V2.0 is an invalid version. =100%, rating =0, the protocol is directly determined to be abnormal. This refined parameter verification mechanism provides an accurate quantitative basis for subsequent fault location and equipment control, ensuring that diagnosis can not only detect subtle parameter anomalies but also avoid false alarms caused by noisy data, significantly improving the reliability and practicality of fault diagnosis.

[0041] Specifically, if the verification results all meet the preset standards, the steps of providing a fault-free information feedback via the interactive module voice include: If the score of each detection instruction in the detection instruction set If all scores are above the preset score, it is determined to meet the preset standards; There is no fault information through voice feedback of the interactive module.

[0042] Specifically, if the verification result is abnormal, an abnormal parameter anchor point is generated and marked, and then the device status is marked as abnormal through the cloud system, and the control module is triggered to limit its external communication function, including the following steps: If the score of each detection instruction in the detection instruction set If at least one of the items is below the preset score, it is determined that the corresponding fault anomaly exists; Based on specific detection instructions, the abnormal parameters are anchored and marked for subsequent maintenance. The corresponding charging device status is then marked as abnormal through the cloud system, restricting the charging device from communicating externally.

[0043] Reference Attachment Figure 2 This is a structural block diagram of a charging device cloud call fault diagnosis device proposed by the present invention, including: A communication unit, configured to obtain a call request from the charging device to access the cloud system, establish a communication channel based on the call request, and load an interactive module for fault guidance into the channel; a recognition unit configured to perform frame processing and acoustic model matching on the user voice input through the interaction module, and extract a textual fault feature group containing charging abnormality keywords; A mapping unit, configured to retrieve a corresponding detection instruction set from a pre-built equipment diagnosis knowledge base according to the fault feature group, wherein the equipment diagnosis knowledge base stores a mapping relationship between fault features and detection instructions; A testing unit, configured to execute the detection instructions carried by the detection instruction set in real time and correspondingly collect corresponding operating parameters of the charging device, and verify the corresponding operating parameters using a preset algorithm; The first information unit is used to provide a fault-free information feedback via the interactive module voice if the verification results meet the preset standards; The second information unit is used to generate and mark an abnormal parameter anchor point if there is an abnormality in the verification result, then mark the charging device status as abnormal through the cloud system, and trigger the control module to limit the external communication function of the charging device.

[0044] Reference Figure 3 In an embodiment of the present invention, a computer device is also provided. The computer device may be a server, and its internal structure may be as follows: Figure 3 As shown. The computer device includes a processor, memory, display screen, input device, network interface and database connected via a system bus. The processor of the computer design is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the computer device is used to store the corresponding data in this embodiment. The network interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, the above method is implemented.

[0045] Those skilled in the art will understand that Figure 3 The structure shown in the figure is merely a block diagram of a portion of the structure related to the solution of the present invention and does not constitute a limitation on the computer device to which the solution of the present invention is applied.

[0046] In summary, the present invention discloses a method for diagnosing charging device faults via cloud-based communication, aiming to address the existing challenges of high user interaction barriers, low diagnostic efficiency, and non-closed-loop fault handling. The method includes establishing a communication channel and loading an interactive module containing a speech recognition engine. Through frame processing and acoustic model matching, the user's natural language description is converted into a textual fault feature set containing charging anomaly keywords. Based on the fault feature set, a corresponding detection instruction set is retrieved from a pre-built knowledge graph. Device operating parameters are collected in real time and verified using a dynamic threshold algorithm. Based on the verification results, voice feedback is provided when no fault is detected. In the event of an anomaly, abnormal parameters and device status are marked, and external communication capabilities are restricted. Core technologies include standardized component reuse and process configuration of the voice interaction module, dynamic matching of detection instructions based on the knowledge graph, dynamic parameter threshold verification combining historical data and real-time status, and closed-loop device status control after a fault. This method automates the entire process from "user description - feature extraction - strategy generation - detection execution - status control," significantly improving fault diagnosis efficiency and accuracy, reducing manual intervention costs, and effectively preventing fault propagation. It is suitable for remote intelligent operation and maintenance of new energy charging equipment.

[0047] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing the relevant hardware using a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the above-described method embodiments. Any reference to memory, storage, database, or other media provided herein and used in the embodiments may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double-speed SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct RAMbus dynamic RAM (DRDRAM), and RAMbus dynamic RAM.

[0048] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, apparatus, article, or method comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, apparatus, article, or method. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, apparatus, article, or method comprising the element.

[0049] The above description is only a preferred embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structure or equivalent process transformation made by using the contents of the present invention description and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A method for diagnosing cloud call faults in charging equipment, characterized in that: The following steps are involved: Obtaining a call request from the charging device to access the cloud system, establishing a communication channel based on the call request, and loading an interactive module for fault guidance into the channel; The interactive module performs frame processing and acoustic model matching on the user's voice input to extract a textual fault feature group containing charging abnormality keywords; According to the fault feature group, a corresponding detection instruction set is retrieved from a pre-built equipment diagnosis knowledge base, wherein the equipment diagnosis knowledge base stores a mapping relationship between fault features and detection instructions; Running the detection instructions carried by the detection instruction set in real time and correspondingly collecting corresponding operating parameters of the charging device, and verifying the corresponding operating parameters using a preset algorithm; If the verification results meet the preset standards, the interactive module will provide voice feedback indicating that there is no fault. If the verification result is abnormal, an abnormal parameter anchor point is generated and marked, and then the charging device status is marked as abnormal through the cloud system, and the control module is triggered to limit the external communication function of the charging device.

2. The charging device cloud call fault diagnosis method according to claim 1, characterized in that: The steps of loading an interactive module for fault guidance into a channel include: Retrieving standardized module components including a speech recognition engine, a fault knowledge base interface, and an interactive logic controller from a diagnostic function component library stored in the cloud system. The speech recognition engine supports noise reduction and keyword extraction of specialized charging terminology. The interaction module is obtained by loading the standardized module component into the call channel and configuring the fault guidance process of the standardized module component. The fault guidance process includes a preset fault guidance speech library, a user question response time threshold and multi-round dialogue logic rules.

3. The charging device cloud call fault diagnosis method according to claim 2, characterized in that: The step of performing frame processing and acoustic model matching on the user voice input by the interactive module to extract a textual fault feature group containing charging abnormality keywords includes: Perform endpoint detection on the user's voice stream to intercept valid voice segments, and divide the valid voice segments into frames according to the preset duration and preset interval; Preprocess the framed speech signal and extract acoustic feature parameters to construct a speech acoustic feature vector sequence; Inputting the acoustic feature vector sequence into a pre-trained neural network model, wherein the neural network model is trained based on a corpus of charging equipment failure scenarios to achieve temporal correlation matching between speech frames and charging anomaly keywords; Identify the keywords output by the neural network model and determine whether the keywords belong to professional terms related to charging equipment failures; The professional terms are semantically associated with a preset fault feature mapping table to generate a textual fault feature group including the fault type and severity. The fault feature mapping table is constructed based on a charging equipment fault code library, and each professional term corresponds to at least one standardized fault feature parameter.

4. The charging device cloud call fault diagnosis method according to claim 3, characterized in that: The step of inputting the acoustic feature vector sequence into a pre-trained neural network model and outputting keywords from the neural network model comprises: Inputting the acoustic feature vector sequence into an encoder layer of a neural network model, wherein the encoder layer comprises at least two layers of bidirectional gated recurrent unit structures for extracting temporal dependencies of speech features; Calculating the weight distribution of the feature vectors of each time step output by the encoder layer through the attention mechanism to generate a weighted feature representation; Inputting the weighted feature representation into a decoder layer of a neural network model, wherein the decoder layer comprises at least one fully connected layer and a softmax classifier for predicting a phoneme probability distribution corresponding to each time step; Constructing a word graph search space based on the phoneme probability distribution, performing path decoding in the search space using a dictionary-constrained Viterbi algorithm to generate a candidate word sequence; Reordering the candidate word sequences using a language model, where the language model is trained based on technical documentation and fault case data in the field of charging equipment, and is used to calculate language probability scores for the candidate word sequences; Output the candidate word sequence with the highest language probability score as the recognition keyword.

5. The charging device cloud call fault diagnosis method according to claim 1, characterized in that: The step of retrieving a corresponding detection instruction set from a pre-built device diagnosis knowledge base according to the fault feature group includes: Converting the fault feature group into a structured feature tuple containing the fault type and severity; Mapping the feature tuple to a pre-built knowledge graph, wherein the knowledge graph stores the association between fault features and detection instructions; Based on the mapping result, matching detection instructions are retrieved to generate a detection instruction set, wherein each detection instruction in the detection instruction set is associated with at least one parameter indicator for evaluating the status of the charging device.

6. The charging device cloud call fault diagnosis method according to claim 5, characterized in that: The steps of running the detection instructions carried by the detection instruction set in real time and correspondingly collecting corresponding operating parameters of the charging device, and verifying the corresponding operating parameters using a preset algorithm include: Construct a multidimensional parameter vector by using the parameter indicators associated with each detection instruction in the detection instruction set ,in Represents the real-time collection value of the i-th parameter indicator; For each parameter indicator , generating a threshold interval according to the operating status of the charging device ,in , , For parameters The historical benchmark value of is the historical standard deviation, and is the operating parameter; During the verification process, the calculation The abnormal deviation Calculate the score of the parameter index associated with each detection instruction in the detection instruction set ,in , the For operating parameters The threshold T, For operating parameters The threshold T.

7. The charging device cloud call fault diagnosis method according to claim 6, characterized in that: If the verification results meet the preset standards, the steps of providing a fault-free information feedback through the interactive module include: If the score of each detection instruction in the detection instruction set If all scores are above the preset score, it is determined to meet the preset standards; There is no fault information through voice feedback of the interactive module.

8. The charging device cloud call fault diagnosis method according to claim 6, characterized in that: If the verification result is abnormal, an abnormal parameter anchor point is generated and marked, and then the cloud system marks the device status as abnormal, triggering the control module to limit its external communication function, including the following steps: If the score of each detection instruction in the detection instruction set If at least one of the items is below the preset score, it is determined that the corresponding fault anomaly exists; Based on specific detection instructions, the abnormal parameters are anchored and marked for subsequent maintenance. The corresponding charging device status is then marked as abnormal through the cloud system, restricting the charging device from communicating externally.

9. A charging equipment cloud call fault diagnosis device, characterized in that: include: A communication unit, configured to obtain a call request from the charging device to access the cloud system, establish a communication channel based on the call request, and load an interactive module for fault guidance into the channel; a recognition unit configured to perform frame processing and acoustic model matching on the user voice input through the interaction module, and extract a textual fault feature group containing charging abnormality keywords; A mapping unit, configured to retrieve a corresponding detection instruction set from a pre-built equipment diagnosis knowledge base according to the fault feature group, wherein the equipment diagnosis knowledge base stores a mapping relationship between fault features and detection instructions; A testing unit, configured to execute the detection instructions carried by the detection instruction set in real time and correspondingly collect corresponding operating parameters of the charging device, and verify the corresponding operating parameters using a preset algorithm; The first information unit is used to provide a fault-free information feedback via the interactive module voice if the verification results meet the preset standards; The second information unit is used to generate and mark an abnormal parameter anchor point if there is an abnormality in the verification result, then mark the charging device status as abnormal through the cloud system, and trigger the control module to limit the external communication function of the charging device.

10. A computer device comprising a memory and a processor, wherein a computer program is stored in the memory, wherein: When the processor executes the computer program, the steps of the charging device cloud call fault diagnosis method according to any one of claims 1 to 8 are implemented.

Images