Fume hood fault early warning and self-diagnosis method, equipment, medium and product

Abstract

The invention discloses a fume hood fault early warning and self-diagnosis method, equipment, a medium and a product. According to the method, real-time acoustic vibration signals are periodically collected through an acoustic vibration sensor, and a time sequence signal flow is generated; performing signal decomposition and feature extraction on the time sequence signal flow to generate a real-time operation feature vector; comparing the real-time operation feature vector with the reference operation feature vector to obtain an operation state deviation degree; when the running state deviation degree exceeds a preset deviation threshold value, inputting the real-time running feature vector into a fault classification model to obtain a fault type code; determining a security risk level, and generating a structured diagnosis report; when the safety risk level reaches an emergency switching level, a switching control instruction is generated and sent to a loop control unit of the ventilation cabinet; and coding the structured diagnosis report into a preset data message, and pushing the preset data message to a preset equipment management platform. By implementing the technical scheme provided by the invention, the problems of single diagnosis information dimension and insufficient depth are solved.

Description

Technical Field

[0001] This application relates to the technical field of fault diagnosis and predictive maintenance, specifically to a method, device, medium, and product for early warning and self-diagnosis of fume hood faults. Background Technology

[0002] Existing technologies for condition monitoring of critical laboratory equipment such as fume hoods typically employ threshold-based judgment methods based on operating parameters. Specifically, flow sensors, differential pressure sensors, or current sensors are installed at key locations within the fume hood, such as the main exhaust duct or control panel. These sensors collect macroscopic operating parameters of the equipment in real time or at set intervals and compare the collected parameter values ​​with pre-set fixed upper and lower threshold values ​​representing the normal operating range. Once a monitored parameter value exceeds the preset threshold range, the system determines that the equipment has malfunctioned and triggers a general alarm signal to prompt management personnel to conduct maintenance.

[0003] However, the aforementioned existing technologies suffer from limitations in practical applications due to their limited diagnostic information dimensions and insufficient depth. This alarm mechanism, triggered by macroscopic parameter thresholds, can only inform management personnel of the general conclusion that the equipment is in an "abnormal state," without providing any in-depth diagnostic information regarding the root cause of the fault, the specific faulty component, or the severity of the fault. Therefore, after an alarm is triggered, maintenance personnel still need to go to the site and, relying on their personal experience and professional testing tools, conduct a comprehensive inspection of the equipment. This process is not only time-consuming and labor-intensive, heavily reliant on the individual skills of senior technicians, but also carries the risk of delaying optimal repair due to misjudgment, leading to worsening of the fault and posing a potential threat to the experimental environment and personnel safety. Summary of the Invention

[0004] To address the aforementioned technical problems, this application provides a method, device, medium, and product for early warning and self-diagnosis of fume hood malfunctions.

[0005] The first aspect of this application provides a method for early warning and self-diagnosis of fume hood malfunctions: By periodically collecting real-time acoustic and vibration signals of the fume hood through acoustic and vibration sensors deployed at preset measuring points inside the fume hood, a time-series signal stream is generated. By performing a preset signal decomposition and feature extraction algorithm on the time series signal stream, a real-time running feature vector is generated; The real-time running feature vector is compared with the benchmark running feature vector in the preset onboard feature database in multiple dimensions to obtain the running state deviation. When the deviation of the operating state exceeds a preset deviation threshold, the real-time operating feature vector is input into a pre-trained fault classification model to obtain a fault type code; The safety risk level is determined based on the deviation between the fault type code and the operating status, and a structured diagnostic report is generated based on the safety risk level. When the safety risk level reaches the preset emergency switching level, a switching control command is generated and sent to the loop control unit of the fume hood; The structured diagnostic report is encoded into a preset data message and pushed to a preset device management platform.

[0006] By employing the aforementioned technical solution and combining signal decomposition and feature extraction algorithms to generate multi-dimensional real-time operational feature vectors, refined monitoring of equipment operating status is achieved. Compared to existing technologies, this solution can accurately calculate the deviation of operating status by comparing multi-dimensional benchmark feature vectors and identify specific fault type codes using a pre-trained fault classification model, thereby generating a structured diagnostic report containing the root cause of the fault, specific components, and severity. This effectively solves the problems of single-dimensional and insufficient depth of diagnostic information, avoiding the limitations of only triggering general alarms. Simultaneously, by automatically determining the safety risk level and generating switching control commands, this solution reduces the reliance on on-site troubleshooting by maintenance personnel, lowers the risk of misjudgment based on personal experience, improves fault response speed and maintenance efficiency, prevents fault escalation from the source, and ensures the safety of the experimental environment and personnel. Furthermore, the automatic push of structured reports further realizes the intelligent and remote management of equipment, significantly saving labor costs.

[0007] Optionally, the step of generating a real-time running feature vector by performing a preset signal decomposition and feature extraction algorithm on the time series signal stream includes: The time series signal stream is decomposed using the aforementioned signal decomposition and feature extraction algorithm to obtain multiple intrinsic mode function components; Perform a Hilbert transform on the target intrinsic mode function component to obtain the instantaneous amplitude and instantaneous frequency corresponding to the target intrinsic mode function component, wherein the target intrinsic mode function component is any one of the plurality of intrinsic mode function components; Based on the instantaneous amplitude and the instantaneous frequency, construct the Hilbert time spectrum; Time-frequency domain statistical features are extracted from the Hilbert time-frequency spectrum, and the real-time running feature vector is generated by combining all the time-frequency domain statistical features.

[0008] By employing the above technical solution, a deeper understanding of equipment operating status, from macroscopic parameters to microscopic characteristics, is achieved. First, signal decomposition technology analyzes the complex time-series signal stream into a series of intrinsic mode function components, effectively removing environmental noise and signal interference, and focusing on the key modes that best reflect the essence of equipment operation. Then, Hilbert transform is used to obtain the instantaneous amplitude and frequency of each component, constructing a Hilbert time-spectrum that comprehensively characterizes the dynamic characteristics of the equipment. Finally, multi-dimensional statistical features extracted from this time-spectrum are combined to form a highly discriminative real-time operating feature vector. This processing flow transforms unstructured raw vibration signals into quantitative indicators that accurately characterize the mechanical state, operational stability, and component health of the equipment, providing rich and accurate feature data for subsequent fault diagnosis, improving the sensitivity of condition monitoring and the accuracy of fault identification, and laying a solid foundation for early warning and precise location.

[0009] Optionally, constructing the Hilbert time spectrum based on the instantaneous amplitude and the instantaneous frequency includes: For the target intrinsic mode function components, the corresponding sampling time point sequence in the time series signal stream is used as time information. The corresponding instantaneous frequency is used as frequency information, and the square of the corresponding instantaneous amplitude is used as energy information; A two-dimensional coordinate grid is constructed with the time information as rows and the frequency information as columns, and the energy information is mapped to the numerical values ​​of the corresponding coordinate points on the two-dimensional coordinate grid to obtain the Hilbert time spectrum.

[0010] By employing the aforementioned technical solution, time-series signals were successfully transformed into high-resolution time-frequency domain energy distribution representations. By constructing a two-dimensional coordinate grid with sampling time points as rows and instantaneous frequencies as columns, and accurately mapping the square of the instantaneous amplitude as the energy value, a Hilbert time-frequency spectrum was formed that simultaneously displays the signal's time-domain evolution and frequency-domain characteristics. This time-frequency representation method not only fully preserves the non-stationary characteristics of the signal, but more importantly, through the precise distribution of energy on the time-frequency plane, it intuitively reveals the dynamic laws governing the energy changes of different frequency components over time during equipment operation. Compared to traditional spectrum analysis methods, this method can effectively capture the instantaneous frequency changes and energy transfer characteristics generated during sudden changes in equipment state, providing crucial time-frequency domain discrimination criteria for the precise identification of early faults.

[0011] Optionally, the step of comparing the real-time running feature vector with the benchmark running feature vector in the preset onboard feature database in multiple dimensions to obtain the running state deviation includes: Retrieve the corresponding component reference feature vectors for the target intrinsic mode function components from the onboard feature database; The component deviation is obtained by calculating the Mahalanobis distance between the time-frequency domain statistical features and the corresponding component reference feature vectors; The operating state deviation is obtained by weighting and fusing the preset fault sensitivity weights corresponding to all the target intrinsic mode function components with the corresponding component deviations.

[0012] By employing the above technical solution, a precise quantitative assessment of the deviation degree of equipment operating status is achieved. By calculating the Mahalanobis distance between real-time features and baseline features, the correlation between features is fully considered to obtain the deviation degree of each modal component. Then, weighted fusion is performed by combining preset fault sensitivity weights, ensuring that the final operating status deviation degree comprehensively reflects the overall equipment status while significantly enhancing the sensitivity to key fault features. This method effectively improves the accuracy of condition monitoring and provides a reliable quantitative basis for early fault warning and risk assessment.

[0013] Optionally, inputting the real-time running feature vector into a pre-trained fault classification model to obtain a fault type code includes: The internal feature components of the real-time running feature vector are weighted by the attention mechanism in the fault classification model to generate a weighted feature representation. The output layer of the fault classification model calculates the probability value of the real-time running feature vector belonging to each preset fault category based on the weighted feature representation, thereby generating a fault category probability distribution. Determine the target fault category with the highest probability value in the fault category probability distribution, and use the code corresponding to the target fault category as the fault type code.

[0014] By adopting the above technical solution and introducing an attention mechanism, the fault classification model can adaptively focus on the key components in the real-time feature vector that are most sensitive to faults, thereby generating a more discriminative weighted feature representation. Subsequently, the model calculates the probability distribution of each preset fault category and selects the category with the highest probability as the diagnostic result, achieving a precise mapping from multi-dimensional features to specific fault types. This method significantly improves the accuracy and reliability of fault classification under complex operating conditions, enabling rapid identification of specific fault modes and providing a core basis for generating structured diagnostic reports with clear guidance, effectively solving the problem that traditional alarm systems cannot locate specific fault causes.

[0015] Optionally, determining the safety risk level based on the deviation between the fault type code and the operating state, and generating a structured diagnostic report based on the safety risk level, includes: By using a pre-defined fault component association model, the root cause component identifier is determined based on the fault type code and the real-time operating feature vector. The risk assessment rule corresponding to the fault type code is retrieved from the onboard feature database, and the safety risk level is calculated and generated based on the deviation between the risk assessment rule and the operating state. Based on the fault root cause component identifier, component fault evolution data and maintenance procedure identifier are retrieved from the onboard feature database, and the component fault evolution data, maintenance procedure identifier and safety risk level are combined to generate the structured diagnostic report.

[0016] By adopting the above technical solution, a complete closed loop from fault identification to risk assessment is achieved. The faulty component association model accurately locates the root cause component of the fault, and the safety risk level is dynamically calculated by combining risk assessment rules and operational status deviation, ensuring the accuracy and objectivity of risk determination. The final structured diagnostic report not only includes the faulty component identification and safety level, but also integrates historical fault evolution data and specific maintenance procedures. This transforms abstract monitoring data into comprehensive decision support information including fault location, risk assessment, evolution trends, and maintenance guidance, greatly improving the pertinence and efficiency of operation and maintenance response, and providing clear operational guidance for on-site maintenance personnel.

[0017] Optionally, the step of retrieving the risk assessment rule corresponding to the fault type code from the onboard feature database, and calculating and generating the safety risk level based on the deviation between the risk assessment rule and the operating state, includes: Based on the fault type code, retrieve the corresponding risk calculation parameter set from the onboard feature database. The risk calculation parameter set includes a basic risk score and a deviation influence factor. The dynamic risk increment is obtained by calculating the deviation of the operating state and the deviation influencing factor. The basic risk score and the dynamic risk increment are summed, and the safety risk level is determined based on the correspondence between the comprehensive risk value obtained by the summing process and the preset risk level classification threshold.

[0018] By adopting the above technical solution, accurate determination of safety risk levels is achieved. This method first determines a basic risk score based on the specific fault type, then calculates the dynamic risk increment by combining the deviation of the operating state with a preset deviation influence factor, and finally sums the two to obtain a comprehensive risk value. This calculation method considers both the inherent risk characteristics of different fault types and incorporates the dynamic impact of the equipment's current actual operating state, ensuring that the final determined safety risk level accurately reflects the severity and urgency of the fault. This refined risk assessment mechanism provides a reliable basis for subsequently generating targeted maintenance strategies and early warning measures, significantly improving the scientific nature and effectiveness of fume hood safety management.

[0019] A second aspect of this application provides an electronic device including a processor, a memory, a user interface, and a network interface, wherein the memory is used to store instructions, the user interface and the network interface are both used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any of the foregoing descriptions.

[0020] A third aspect of this application provides a computer-readable storage medium storing instructions that, when executed, perform the method described in any of the preceding descriptions.

[0021] A fourth aspect of this application provides a computer program product that, when run on an electronic device, causes the electronic device to perform the method as described in any of the preceding claims.

[0022] In summary, one or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: A complete health status monitoring system for fume hoods was constructed through acoustic and vibration signal analysis, multi-dimensional feature comparison, and intelligent fault diagnosis. This solution utilizes signal decomposition and Hilbert transform to extract the microscopic features of equipment operation, accurately quantifies the degree of status deviation through Mahalanobis distance calculation and weighted fusion, and achieves intelligent identification of fault types using an attention mechanism. Based on this, a structured report containing fault location, risk level, and maintenance guidance is generated using a dynamic risk assessment model. Finally, closed-loop management is achieved through automatic alarms and remote push notifications. This technical solution effectively solves the problems of traditional monitoring methods, such as limited diagnostic information and reliance on human experience. It achieves intelligent management throughout the entire process from status monitoring to fault early warning and maintenance decision-making, significantly improving the accuracy of equipment management and operational efficiency, and providing reliable assurance for the safe operation of laboratories. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the system architecture of an embodiment of a fume hood fault early warning and self-diagnosis method applying this application; Figure 2 This is a flowchart illustrating a fume hood fault early warning and self-diagnosis method disclosed in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of this application.

[0024] Explanation of reference numerals in the attached figures: 100, System architecture; 101, First terminal device; 102, Second terminal device; 103, Third terminal device; 104, Network; 105, Server; 301, Processor; 302, Communication bus; 303, User interface; 304, Network interface; 305, Memory. Detailed Implementation

[0025] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0026] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0027] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0028] Figure 1 This is a schematic diagram of the system architecture of an embodiment of a fume hood fault early warning and self-diagnosis method applying this application.

[0029] like Figure 1 As shown, system architecture 100 may include terminal devices 101, 102, and 103, a network 104, and a server 105. Network 104 serves as the medium for providing communication links between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0030] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as model training applications, video recognition applications, web browser applications, social platform software, etc.

[0031] Terminal devices 101, 102, and 103 can be either hardware or software. When terminal devices 101, 102, and 103 are hardware, they can be various electronic devices with displays, including but not limited to smartphones, tablets, e-book readers, MP3 (Moving Picture Experts Group Audio Layer III) players, MP3 (Moving Picture Experts Group Audio Layer IV) players, laptops, and desktop computers, etc. When terminal devices 101, 102, and 103 are software, they can be installed in the aforementioned electronic devices. They can be implemented as multiple software programs or software modules (e.g., multiple software programs or software modules used to provide distributed services) or as a single software program or software module. No specific limitations are imposed here.

[0032] This embodiment discloses a method for early warning and self-diagnosis of fume hood malfunctions. Figure 2 This is a flowchart illustrating a fume hood fault early warning and self-diagnosis method disclosed in an embodiment of this application, as shown below. Figure 2 As shown, the method includes the following steps: S201. By periodically collecting the real-time acoustic and vibration signals of the fume hood through acoustic and vibration sensors deployed at preset measuring points inside the fume hood, a time-series signal stream is generated. One approach is to deploy independent piezoelectric accelerometers and MEMS microphones at key measuring points such as the fume hood's fan casing and main / exhaust ducts to collect structural vibration and airborne noise. As an alternative, an integrated acoustic-vibration composite sensor can be deployed on the fume hood's motor casing. This sensor integrates a triaxial accelerometer and microphone, enabling simultaneous acquisition of multi-dimensional information from the same measuring point. In applications particularly sensitive to early-stage micro-cracks and other faults, acoustic emission sensors can be installed at the root of the fan blades or at key structural welds, in addition to conventional accelerometers, to capture high-frequency stress wave signals. Sensors in either of these solutions can acquire data according to a preset acquisition cycle (e.g., once every 5 minutes) and sampling frequency (e.g., 25.6 kHz), thereby organizing the collected discrete signal points in chronological order to generate a real-time time-series signal stream required for subsequent analysis.

[0033] Those skilled in the art will understand that the type, number, and deployment location of sensors can be adjusted according to the specific structure of the fume hood and the monitoring accuracy requirements, and are not limited to the examples above.

[0034] S202. By performing a preset signal decomposition and feature extraction algorithm on the time series signal stream, a real-time running feature vector is generated; Specifically, time-series signal streams, as a form of unprocessed raw data, refer to a series of acoustic and vibration signal readings obtained by sensors in a continuous, time-series order, reflecting the physical operating status of a fume hood. To extract valuable information from this massive amount of raw data, a pre-defined signal decomposition and feature extraction algorithm is required. This algorithm is a composite computational process. It first performs signal decomposition, breaking down the complex mixed signal into a series of relatively simpler, more physically meaningful intrinsic components. Then, the feature extraction part of the algorithm calculates multiple numerical indicators for each decomposed component, quantifying its characteristics in the time domain, frequency domain, or time-frequency domain, such as energy, entropy, kurtosis, or amplitude in a specific frequency band. Finally, all these calculated numerical indicators are organized into a high-dimensional numerical array, which constitutes the real-time operating feature vector. This vector is equivalent to a compact digital snapshot or state descriptor of the equipment's current operating status, providing standardized input for subsequent intelligent diagnostics and trend analysis.

[0035] Optionally, generating a real-time running feature vector by performing a preset signal decomposition and feature extraction algorithm on the time-series signal stream includes: decomposing the time-series signal stream using the signal decomposition and feature extraction algorithm to obtain multiple intrinsic mode function (IMF) components; performing a Hilbert transform on the target IMF component to obtain the instantaneous amplitude and instantaneous frequency corresponding to the target IMF component, wherein the target IMF component is any one of the multiple IMF components; constructing a Hilbert time-frequency spectrum based on the instantaneous amplitude and the instantaneous frequency; extracting time-frequency domain statistical features from the Hilbert time-frequency spectrum, and combining all the time-frequency domain statistical features to generate the real-time running feature vector.

[0036] As a specific implementation, the step of decomposing the time-series signal stream into multiple Intrinsic Mode Function (IMF) components can be accomplished using various signal processing algorithms. In one embodiment, the decomposition process employs the classic Empirical Mode Decomposition (EMD) algorithm. This algorithm iteratively extracts IMF components from the signal through a selection process, specifically including: identifying all local extrema of the original signal; connecting the maxima and minima using cubic spline interpolation to form upper and lower envelopes; calculating the mean of the envelopes and subtracting this mean from the original signal to obtain an intermediate component; repeating this selection process until the intermediate component satisfies the two defining conditions of IMF (the number of extrema and zero-crossings must be equal or differ by at most one throughout the entire data segment; at any point, the mean of the envelope defined by the local maxima and local minima is zero), at which point the component is an IMF component. Then, the IMF component is subtracted from the original signal to obtain a residual signal. This process is repeated until the residual signal becomes a monotonic function, thus obtaining a series of IMF components from high frequency to low frequency. In another embodiment, to address the potential mode aliasing problem in EMD, the Ensemble Empirical Mode Decomposition (EEMD) algorithm can be used. This algorithm adds Gaussian white noise to the original signal, then performs EEMD decomposition on the noisy signal, repeating this process multiple times (e.g., 100 times), adding a different white noise sequence each time. Finally, the corresponding IMF components obtained from the multiple decompositions are averaged to obtain the final IMF component set. This method utilizes the statistical characteristics of the uniform distribution of the white noise spectrum, enabling automatic signal separation at different scales and effectively suppressing mode aliasing.

[0037] Furthermore, a Hilbert transform needs to be performed on the target intrinsic mode function components. Here, the multiple IMF components obtained from the decomposition will be analyzed one by one, or several components most sensitive to fault indication will be selected as target components for subsequent processing according to preset rules (such as energy proportion, correlation, etc.). In one embodiment, the system can be configured to perform a Hilbert transform on all decomposed IMF components one by one for comprehensive analysis. Specifically, for a selected IMF component, its orthogonal component is obtained by performing a Hilbert transform on it, and then the original IMF component is used as the real part and its orthogonal component is used as the imaginary part to form an analytical signal. By calculating the magnitude of the analytical signal, the instantaneous amplitude of the IMF component can be obtained; by differentiating the amplitude of the analytical signal with respect to time, its instantaneous frequency can be obtained. In another optional embodiment, in order to improve computational efficiency or highlight key information, all IMF components can be preliminarily screened before selecting the target component. For example, the correlation coefficient between each IMF component and the original signal can be calculated, or the energy proportion of each component can be calculated. Then, the top N (e.g., N=3) IMF components with the highest correlation coefficient or the largest energy proportion can be selected as target components for subsequent Hilbert transform. This approach allows for focused computational resource analysis of the signal components that have the most significant impact on equipment status.

[0038] Furthermore, a Hilbert time-frequency spectrum is constructed. The Hilbert time-frequency spectrum is a three-dimensional spectrum with three dimensions: time, frequency, and amplitude, clearly showing the distribution of signal energy over time and frequency. In one embodiment, the construction process involves representing the instantaneous frequency and instantaneous amplitude pair calculated at each moment as a point (t, f(t), A(t)) in three-dimensional space, thus forming a spectrum that varies with time. For ease of computer processing and feature extraction, this spectrum is typically represented as a two-dimensional matrix or image. Specifically, the time and frequency axes can be discretized into several grids, and the amplitude energy A(t) at each time point can be allocated to the grid cell containing its corresponding time t and instantaneous frequency f(t). If multiple amplitudes fall within a single grid cell, they can be accumulated or averaged. In another embodiment, to enhance the expressive power of the amplitude dynamic range, the amplitude can be logarithmically processed when constructing the time-frequency spectrum, for example, using decibels (dB) as the unit, i.e., the amplitude is mapped to 20 × log10(A(t)). The logarithmic time spectrum constructed in this way can better highlight the characteristics of weak signals, while avoiding the effects of excessive saturation of strong signals.

[0039] Furthermore, time-frequency domain statistical features are extracted from the constructed Hilbert time-spectrum and combined into a real-time operational feature vector. These features aim to quantify patterns characterizing the device's operating state from the time-spectrum graph. In one embodiment, the extracted statistical features may include global statistical moments of the time-spectrum, such as the mean, variance, skewness, and kurtosis of the amplitude distribution across the entire time-spectrum graph. These global features can macroscopically reflect the overall intensity and distribution pattern of signal energy. In another embodiment, more detailed energy distribution-based features can be extracted. For example, the time-spectrum can be divided into multiple preset frequency bands (such as low-frequency band, mid-frequency band, and high-frequency band) along the frequency axis, and then the total energy or energy percentage within each frequency band can be calculated. These frequency band energy features can reflect energy changes in specific physical processes (such as rotation, friction, and impact). In addition, time-frequency entropy, such as time-frequency energy entropy, can be calculated, which measures the complexity or uncertainty of energy distribution in the time-spectrum; the more concentrated the energy distribution, the smaller the entropy value. Finally, all extracted numerical features (e.g., global mean, global variance, low-frequency energy, mid-frequency energy, time-frequency entropy, etc.) are arranged and concatenated in a preset order to form a one-dimensional array with a fixed dimension, which is the real-time running feature vector, used for subsequent state recognition and diagnostic models.

[0040] Optionally, constructing the Hilbert time spectrum based on the instantaneous amplitude and the instantaneous frequency includes: for the target intrinsic mode function component, taking the sampling time point sequence in the corresponding time series signal stream as time information, taking the corresponding instantaneous frequency as frequency information, and taking the square of the corresponding instantaneous amplitude as energy information; constructing a two-dimensional coordinate grid with the time information as rows and the frequency information as columns, and mapping the energy information to the values ​​of the corresponding coordinate points on the two-dimensional coordinate grid to obtain the Hilbert time spectrum.

[0041] In one embodiment, for a selected target intrinsic mode function component, three key information elements are prepared to construct the time spectrum. First, the time information is directly derived from the original sampling time point sequence of the time-series signal stream. For example, if the sampling frequency is F_s, the time point sequence can be represented as {0, 1 / F_s, 2 / F_s, ..., (N-1) / F_s}, where N is the signal length. Second, the frequency information is the instantaneous frequency sequence calculated through Hilbert transform, corresponding one-to-one with each of the above time points. Finally, the energy information is obtained by calculating the square of the instantaneous amplitude at each time point, i.e., E(t) = A(t). 2Here, A(t) is the instantaneous amplitude, and E(t) is the instantaneous energy. This square operation aims to convert the amplitude into a physically meaningful energy metric. In another alternative embodiment, to highlight the relative rather than absolute magnitude of the energy distribution in the final time spectrum, the energy information can be normalized after acquisition. For example, the total energy of the target intrinsic mode function components (i.e., the sum of all instantaneous energies) can be calculated, and then the instantaneous energy at each time point can be divided by this total energy to obtain the normalized energy information.

[0042] Furthermore, a two-dimensional coordinate grid is constructed as the carrier of the time-frequency spectrum based on the time and frequency information. In one embodiment, the two-dimensional grid adopts a fixed and uniform division method. Specifically, the time axis (e.g., as rows) is divided into M equal-length time slots according to the total signal duration and the desired time resolution; the frequency axis (e.g., as columns) is divided into K equal-width frequency bands according to the Nyquist frequency and the desired frequency resolution. This forms an M-row, K-column matrix with all cells initially set to zero, where each cell represents a specific time-frequency region. In another embodiment, an adaptive grid construction method can be used. For example, the range of the frequency axis can not be fixed from 0 to the Nyquist frequency, but can be dynamically determined based on the calculated minimum and maximum values ​​(min(f), max(f)) of the instantaneous frequency sequence, making the frequency axis representation more compact and efficient. In addition, the division of the frequency axis can also be non-uniform, for example, using a logarithmic scale to obtain higher resolution in the low-frequency region, which is particularly important for many mechanical fault diagnosis scenarios.

[0043] Furthermore, the energy information is mapped onto the constructed two-dimensional coordinate grid to form the final Hilbert time-frequency spectrum. In one embodiment, an additive mapping method is used. Specifically, for each time point t_i, its corresponding frequency f(t_i) and energy E(t_i) are obtained. Then, the cell in the two-dimensional coordinate grid to which t_i and f(t_i) belong (e.g., row index j, column index k) is determined. Next, the energy E(t_i) is added to the current value of that cell Grid[j, k]. After traversing all time points, the value of each cell in the grid represents the sum of signal energy within that time-frequency region. In another, more refined embodiment, an interpolation-based mapping method can be used to obtain a smoother time-frequency spectrum. For example, for a point (t_i, f(t_i), E(t_i)), it may fall near the intersection of four grid cells. In this case, algorithms such as bilinear interpolation can be used to distribute its energy E(t_i) to these four adjacent grid cells according to their distance, thereby avoiding the block effect and making the energy distribution more natural and accurate.

[0044] S203. Compare the real-time running feature vector with the benchmark running feature vector in the preset onboard feature database in multiple dimensions to obtain the running state deviation. Specifically, the pre-defined onboard feature database here refers to a dataset embedded or stored in a non-volatile storage medium (such as Flash memory or EEPROM) of the fume hood's local controller or monitoring module. The "onboard" characteristic means that the diagnostic process can be completed entirely independently at the device level, without relying on external networks or cloud servers, ensuring the real-time nature and reliability of the diagnostics. The core content stored in this database is at least one baseline operating feature vector. This baseline vector is a feature vector with the same dimension and physical meaning as the real-time operating feature vector; it represents the "digital fingerprint" of the fume hood under one or more known and defined operating states. The most typical baseline operating feature vector is generated by collecting the acoustic and vibration signals of the fume hood when it is in a brand-new, fault-free, or optimal operating state and performing the same signal decomposition and feature extraction algorithms as described above. The database can also pre-store baseline feature vectors representing specific typical faults (such as fan bearing wear or blade imbalance). Optionally, the step of comparing the real-time operating feature vector with the benchmark operating feature vector in the preset onboard feature database in multiple dimensions to obtain the operating state deviation includes: retrieving the corresponding component benchmark feature vector for the target intrinsic mode function component from the onboard feature database; obtaining the component deviation by calculating the Mahalanobis distance between the time-frequency domain statistical feature and the corresponding component benchmark feature vector; and performing weighted fusion processing on the preset fault sensitivity weights corresponding to all the target intrinsic mode function components and the corresponding component deviations to obtain the operating state deviation.

[0045] As a preferred implementation of the above embodiments, the core of the step of retrieving the corresponding component reference feature vector from the onboard feature database for the target intrinsic mode function component lies in establishing a correct correspondence between the real-time analyzed components and the health status references stored in the database. In one embodiment, this retrieval is achieved through index matching. Specifically, the onboard feature database can be constructed as an array or list structure, where each element stores a component reference feature vector. During signal decomposition, intrinsic mode function components (IMFs) are assigned a unique index (e.g., IMF1, IMF2, ...) according to their extraction order from high frequency to low frequency. When it is necessary to retrieve a reference for the i-th target intrinsic mode function component (e.g., IMFi), the system directly accesses the position at index i in the database and reads the pre-stored component reference feature vector. In another embodiment, to cope with the changes in signal characteristics under different operating conditions, the database can be designed as a multi-dimensional structure, such as a hash table or dictionary related to operating conditions. During retrieval, the system first obtains the current operating parameters (such as fan speed and load size), and then uses the operating parameters and component sequence number (e.g., high speed_IMF2) as a composite key to accurately retrieve the reference feature vector of a specific component applicable to the current specific operating condition.

[0046] Furthermore, by calculating the Mahalanobis distance between the real-time running feature vector and the benchmark, the component deviation degree, which quantifies the degree of deviation of the current component, can be obtained. In one embodiment, this calculation process strictly follows the mathematical definition of Mahalanobis distance. To perform this calculation, in addition to storing the component benchmark feature vector μ representing the mean of the healthy state, the onboard feature database must also pre-store a corresponding covariance matrix Σ (or its inverse matrix Σ⁻¹). This covariance matrix describes the fluctuation range of each dimension of the component feature vector and their correlations under the healthy state. During calculation, the system subtracts the real-time component feature vector x from its benchmark μ, and then performs a quadratic operation using the pre-stored inverse covariance matrix Σ⁻¹, i.e., D_M² = (x-μ)ᵀ × Σ⁻¹ × (x-μ), and finally takes its square root to obtain the Mahalanobis distance value, which is the component deviation degree. In another embodiment to improve the computational efficiency of the embedded system, the covariance matrix Σ can be pre-decomposed (using Cholliski decomposition) to obtain a lower triangular matrix L, such that Σ = LLᵀ. In the calculation, the linear equation system Ly = (x - μ) is first solved to obtain y, and then the deviation of the components is the Euclidean norm (L2 norm) of the vector y. This method avoids direct inversion, and the calculation process is more stable and efficient.

[0047] Furthermore, the preset fault sensitivity weights corresponding to all target intrinsic mode function components are weighted and fused with their respective component deviations to obtain an operating state deviation that can comprehensively evaluate the overall health status of the equipment. In one embodiment, this process is a linear weighted summation. The system reads the preset fault sensitivity weights {w1, w2, ...} for each target IMF component (e.g., IMF1, IMF2...) from the onboard database. These weights are determined based on prior knowledge or a large amount of experimental data, reflecting the importance of state changes of different frequency components in indicating potential faults. For example, high-frequency components related to bearing faults may be assigned higher weights. Subsequently, the operating state deviation is calculated using the formula Operating State Deviation = Σ(wᵢ×dᵢ), where dᵢ is the deviation of the i-th component and wᵢ is its corresponding weight. In another embodiment, a non-linear fusion strategy can be used to enhance sensitivity to early, minor faults. For example, the fusion process can be designed to take the maximum value among all weighted component deviations, i.e., Operating State Deviation = max(w1×d1, w2×d2, ...). This "largest deviation" strategy means that if any component considered critical deviates significantly, the overall deviation index will immediately rise, thus enabling more timely early warnings.

[0048] S204. When the deviation of the operating state exceeds a preset deviation threshold, the real-time operating feature vector is input into a pre-trained fault classification model to obtain a fault type code. A preset deviation threshold is a pre-stored numerical benchmark. When the calculated deviation of the operating state exceeds this threshold, a potential fault is considered to exist, triggering deep diagnostics. At this point, the system inputs the real-time operating feature vector into a pre-trained fault classification model. This model is a machine learning algorithm trained during the development phase using a large number of labeled fault data samples. It can be deployed locally on the device or on a server or edge computing node communicating with the device, and has the ability to identify specific fault patterns from feature vectors. After analyzing and inferring the input vector, the model outputs a fault type code, a standardized combination of numbers or letters. Each code uniquely and explicitly corresponds to a predefined specific fault type, thus achieving rapid and automatic qualitative fault diagnosis.

[0049] Optionally, the step of inputting the real-time running feature vector into a pre-trained fault classification model to obtain a fault type code includes: weighting the internal feature components of the real-time running feature vector through the attention mechanism in the fault classification model to generate a weighted feature representation; calculating the probability value of the real-time running feature vector belonging to each preset fault category based on the weighted feature representation through the output layer of the fault classification model to generate a fault category probability distribution; determining the target fault category with the highest probability value in the fault category probability distribution, and using the code corresponding to the target fault category as the fault type code.

[0050] In one embodiment, the internal feature components of the real-time running feature vector are weighted using an attention mechanism in the fault classification model to generate a weighted feature representation. Specifically, this attention mechanism can be implemented as a self-attention module. This module first maps the input real-time running feature vector into three vectors—query (Q), key (K), and value (V)—using a learnable linear transformation. Then, by calculating the dot product similarity of Q and K and normalizing it using the Softmax function, the attention weight of each feature component relative to the other components is obtained. Finally, these weights are applied to the V vector for weighted summation to obtain the weighted feature representation. This approach allows the model to autonomously focus on the feature components most critical to the current fault diagnosis. In another embodiment, the attention mechanism can also employ a more lightweight structure, such as a simple feedforward neural network, which receives the real-time running feature vector as input and directly outputs a weight vector with the same dimension as the feature vector. This weight vector is then multiplied element-wise with the original feature vector to generate a weighted feature representation. This scheme has lower computational overhead and is more suitable for resource-constrained embedded platforms.

[0051] Furthermore, the output layer of the fault classification model calculates the probability value of the real-time running feature vector belonging to each preset fault category based on the weighted feature representation, thereby generating a fault category probability distribution. In one embodiment, the output layer is a fully connected layer with the number of neurons equal to the total number of preset fault categories (e.g., X categories including "health status"). This fully connected layer receives the weighted feature representation as input and outputs a raw predicted score for each category. These scores are then processed by a Softmax activation function, transforming them into a probability distribution with a sum of 1, where each value represents the posterior probability that the input sample belongs to the corresponding fault category. In another embodiment, for scenarios where multiple faults may occur concurrently (multi-label classification), each neuron in the output layer can independently use the Sigmoid activation function. In this way, each output value represents the probability of belonging to a single fault category, ranging from 0 to 1, and the sum of all output values ​​is not required to be 1, thus indicating multiple high-probability fault categories simultaneously.

[0052] Further, the system determines the target fault category with the highest probability value in the fault category probability distribution and uses the code corresponding to this target fault category as the fault type code. In one embodiment, this process is implemented through a simple maximum value operation. The system traverses the fault category probability distribution vector generated by the output layer and finds the index of the element with the highest probability value. This index uniquely corresponds to a target fault category. The system then uses this index to look up and retrieve a predefined, standardized fault type code in a preset mapping table (e.g., an array or dictionary). In another more robust embodiment, this step also includes a confidence level judgment. After finding the maximum probability value, the system compares it with a preset confidence threshold (e.g., 0.85). Only when the maximum probability value exceeds the threshold is the corresponding fault type code output; otherwise, the system outputs a specific code indicating an uncertain or unknown fault, thereby improving the reliability of the diagnostic conclusion and avoiding misjudgments of low-confidence results.

[0053] S205. Determine the safety risk level based on the deviation between the fault type code and the operating state, and generate a structured diagnostic report based on the safety risk level; Safety risk level is a comprehensive quantitative rating of the severity and urgency of a fault. Its determination process integrates the nature of the fault (represented by fault type codes) and its intensity (represented by deviations from operational status). Specifically, the system can map a specific combination of fault codes and deviation values ​​to a predefined level (e.g., warning, general, severe, or dangerous) by querying a preset risk matrix or executing a set of logical rules. Subsequently, the system generates a structured diagnostic report based on this determined risk level. This report is a data packet following a predetermined data format, rather than unformatted plain text. The report encapsulates key information such as the safety risk level, fault type code, operational status deviation, and diagnostic timestamp in standardized data fields, ensuring that the report can be automatically and unambiguously parsed and processed by subsequent computer systems (such as equipment management platforms or cloud servers) to trigger corresponding maintenance or alarm procedures.

[0054] Optionally, determining the safety risk level based on the deviation between the fault type code and the operating state, and generating a structured diagnostic report based on the safety risk level, includes: determining the root cause component identifier of the fault by using a preset fault component association model, based on the fault type code and the real-time operating feature vector; retrieving the risk assessment rule corresponding to the fault type code from the onboard feature database, and calculating and generating the safety risk level based on the risk assessment rule and the deviation between the operating state; and retrieving component fault evolution data and maintenance procedure identifier from the onboard feature database based on the root cause component identifier, and combining the component fault evolution data, the maintenance procedure identifier, and the safety risk level to generate the structured diagnostic report.

[0055] In a preferred embodiment, the method further includes determining the root cause component identifier of the fault by using a preset fault component association model, based on the fault type code and the real-time operating feature vector. The fault component association model aims to establish a mapping relationship between fault phenomena and physical components. One implementation is that the model is a rule base or knowledge graph built based on expert knowledge, storing a large number of "fault code-feature pattern-component identifier" triple rules. Upon receiving the fault type code and the real-time operating feature vector, the system uses a matching engine to retrieve the rule in the database that best matches the current fault phenomenon and feature vector pattern, thereby directly outputting the preset root cause component identifier. Another approach is that the model is a trained lightweight classifier, such as a decision tree or Bayesian network. This classifier learns the statistical relationships between various fault codes, feature vectors, and the finally confirmed fault components in historical fault cases during offline testing. During online diagnosis, it integrates the fault code (which can be used as a classification feature) and the real-time operating feature vector as input, outputting the fault root cause component identifier with the highest probability. This approach can better handle the complex and non-linear associations between features and components. The fault-causing component identifier is a unique, standardized code, such as "Bearing-A01" or "Pump-Inlet-Valve-SN0123", used to accurately locate the component in the equipment asset management system.

[0056] Furthermore, the system retrieves the risk assessment rule corresponding to the fault type code from the onboard feature database, and calculates the safety risk level based on the deviation of the rule from the operating state. Here, the onboard feature database is an embedded database or configuration file collection stored locally on the device. The risk assessment rule defines how to convert the nature and intensity of a fault into a specific risk level. One implementation is that the rule is a mathematical formula. For example, the rule stored in the database is: Risk Level = Basic Risk Weight × f(Deviation), where the basic risk weight is a constant retrieved based on the fault type code (e.g., bearing wear has a higher weight than filter blockage), and f() is a function of the deviation (e.g., a linear or exponential function). The system executes this formula to calculate a continuous risk score and then maps it to a discrete risk level. Another implementation is that the rule is a two-dimensional risk matrix. The database provides a specific matrix based on the fault type code, where rows represent different faulty components or subsystems, and columns represent different deviation ranges of operating states. The system looks up the predefined safety risk level directly in this matrix based on the currently diagnosed faulty component (or type) and the deviation value.

[0057] Furthermore, based on the fault root cause component identifier, the system retrieves component fault evolution data and maintenance procedure identifiers from the onboard feature database, and combines this information with the safety risk level to generate the structured diagnostic report. The component fault evolution data here is key information for predicting fault development trends. One implementation is that the data is a pre-defined text description, such as "It is expected that vibration will exceed the standard by 20% within the next 50 operating hours, which may lead to secondary damage," providing forward-looking guidance for maintenance personnel. Another implementation is that the data is a set of parameterized evolution model IDs or curve data, which can be called by the host computer software for more detailed remaining service life prediction. The maintenance procedure identifier is a code or link pointing to a specific maintenance or operation manual, such as "SOP-Maint-PartA01," which operators can use to quickly find standard operating procedures. Finally, the system encapsulates this retrieved information, such as the safety risk level (e.g., severe), fault root cause component identifier, component fault evolution data, and maintenance procedure identifier, into a JSON (JavaScript Object Notation) format diagnostic report, forming a closed loop of diagnostic information.

[0058] Optionally, the step of retrieving the risk assessment rule corresponding to the fault type code from the onboard feature database and calculating the safety risk level based on the risk assessment rule and the deviation of the operating state includes: retrieving the corresponding risk calculation parameter set from the onboard feature database according to the fault type code, wherein the risk calculation parameter set includes a basic risk score and a deviation influence factor; calculating the operating state deviation and the deviation influence factor to obtain a dynamic risk increment; summing the basic risk score and the dynamic risk increment, and determining the safety risk level based on the correspondence between the comprehensive risk value obtained from the summing and a preset risk level classification threshold.

[0059] In one specific embodiment, the system first retrieves the corresponding risk calculation parameter set from the onboard feature database based on the fault type code. This risk calculation parameter set is a set of preset values ​​bound to a specific fault type and used to quantify risk. One implementation is that this parameter set is stored in a simple key-value database or configuration file, where the fault type code is the key and the value is a structure or object containing a base risk score and a deviation impact factor. For example, for the fault code "F01_Bearing_Wear", the associated parameter set might be {base_risk: 70, impact_factor: 1.5}. Another implementation is that the parameter set is stored in a relational data table, with a table structure including fields such as fault code, equipment model, base risk score, and deviation impact factor. During retrieval, the system can perform a joint query based on the fault code and the current equipment model to obtain more accurate risk calculation parameters for a specific fault on a specific device. Here, the base risk score represents the inherent risk baseline of this type of fault, while the deviation impact factor is used to adjust the contribution of the degree of operational deviation to the total risk.

[0060] Next, the system calculates the dynamic risk increment by combining the operational status deviation with the deviation impact factor. This step aims to quantify the additional risk arising from the severity of the current fault. One implementation is to use linear multiplication, directly multiplying the operational status deviation by the deviation impact factor, as follows: Dynamic Risk Increment = Operational Status Deviation × Deviation Impact Factor. This method is simple, direct, and computationally inexpensive. Another implementation is to use a non-linear calculation model to more realistically reflect the growth pattern of risk. For example, a power function can be used: Dynamic Risk Increment = Deviation Impact Factor × (Operational Status Deviation) k The exponent k (e.g., k=1.5 or 2) can be a preset constant or also included in the risk calculation parameter set. This method can amplify the risk brought about by high deviation, making its proportion in the total risk increase sharply, which is more in line with the deterioration characteristics of certain faults.

[0061] Furthermore, the system sums the basic risk score with the dynamic risk increment to obtain a comprehensive risk value, and determines the safety risk level based on the correspondence between this value and a preset risk level classification threshold. One implementation involves the system performing a simple addition operation: Comprehensive Risk Value = Basic Risk Score + Dynamic Risk Increment. Then, the system compares the obtained comprehensive risk value with a set of fixed thresholds preset in the system configuration file. For example, the preset thresholds might be: [0, 50) corresponding to a "warning" level; [50, 85) corresponding to a "moderate" level; and [85, 100] corresponding to a "critical" level. The system determines the final safety risk level by judging the range in which the comprehensive risk value falls. Another alternative is that the risk level classification threshold is not globally fixed but dynamic. For example, the threshold itself is also associated with a fault type code and stored in an onboard feature database. For certain critical faults, even if the comprehensive risk value is not high, its corresponding lower threshold may still result in a higher safety risk level, thereby achieving a differentiated and more refined risk assessment strategy for different fault types.

[0062] S206. When the safety risk level reaches the preset emergency switching level, a switching control command is generated and sent to the loop control unit of the fume hood. The preset emergency switchover level here is a rigid threshold used to trigger the highest level of security response. For example, it could be a predefined highest risk level, such as a "dangerous" level, or a specific comprehensive risk value (e.g., exceeding 95 points). This threshold is typically embedded in the device's firmware or security configuration file to prevent arbitrary tampering. One specific implementation for generating and sending switchover control commands is as follows: the processor housing the diagnostic module sends a high-priority broadcast or point-to-point data frame to the loop control unit (usually a separate microcontroller or programmable logic controller) via an internal communication bus. This data frame contains explicit instruction codes (e.g., 0xFF01 representing "switch to backup loop") and a security checksum. Another more direct and reliable implementation is for the processor to send a level-transition signal (e.g., from low to high) directly to a specific interrupt pin of the loop control unit via one or more dedicated hardware input / output pins as the emergency switchover trigger signal. This method bypasses the complex communication protocol stack, resulting in faster response and stronger anti-interference capabilities. Upon receiving the instruction or signal, the circuit control unit will unconditionally and without delay execute the preset hardware switching action. For example, by driving a relay or contactor, it will immediately cut off the power supply of the main fan and connect the power supply of the redundant standby fan, or directly execute the emergency shutdown procedure. The aim is to force the equipment status to switch to the preset safety mode as soon as possible, thereby effectively preventing the fault from worsening when a serious risk is diagnosed, and avoiding personal injury or equipment damage.

[0063] S207. Encode the structured diagnostic report into a preset data message and push it to a preset device management platform.

[0064] One specific implementation involves the system first serializing the generated structured diagnostic report into a generic JSON string. This JSON string is then encapsulated as the request body into a request based on HTTP (Hypertext Transfer Protocol) or the more secure HTTPS (Hypertext Transfer Protocol Secure). The receiving address of the device management platform is a pre-defined URL (Uniform Resource Locator), such as an API (Application Programming Interface) address like https: / / api.iot-platform.com / v1 / device / diagnostics, which is pre-configured in the device's non-volatile memory. The device's network communication module (e.g., Ethernet or 4G / 5G module) is responsible for establishing a connection with the platform server and sending the request. An alternative, more suitable for Industrial Internet of Things (IIoT) scenarios, is to use a lighter-weight communication protocol, such as MQTT (Message Queuing Telemetry Transport). In this approach, the system efficiently encodes structured diagnostic reports using binary formats such as Protocol Buffers (Protobuf), significantly reducing message size and saving network bandwidth. Then, the device, acting as an MQTT client, publishes this binary message to a predefined topic, such as DMS / Ventilator / SN12345 / Diagnostics, where DMS represents the device management system and SN represents the serial number. The predefined device management platform, acting as an MQTT server or a client subscribed to this topic, can receive this diagnostic message in real time. Regardless of the approach used, this step ensures that the device's health status and fault information are transmitted to the centralized platform in a timely and accurate manner, providing a reliable data foundation for subsequent advanced applications such as remote operation and maintenance, big data analysis, predictive maintenance, and automated work order dispatch.

[0065] It should be noted that the above embodiments of the apparatus are only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0066] This embodiment also discloses an electronic device, as shown in the reference. Figure 3 The electronic device may include: at least one processor 301, at least one communication bus 302, user interface 303, network interface 304, and at least one memory 305.

[0067] The communication bus 302 is used to enable communication between these components.

[0068] The user interface 303 may include a display screen and a camera. Optionally, the user interface 303 may also include a standard wired interface and a wireless interface.

[0069] The network interface 304 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0070] The processor 301 may include one or more processing cores. The processor 301 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 305, and by calling data stored in memory 305. Optionally, the processor 301 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 301 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 301 and may be implemented as a separate chip.

[0071] The memory 305 may include random access memory (RAM) or read-only memory. Optionally, the memory 305 may include a non-transitory computer-readable storage medium. The memory 305 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 305 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 305 may also be at least one storage device located remotely from the aforementioned processor 301. Figure 3 As shown, the memory 305, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an application program for a fume hood fault early warning and self-diagnosis method.

[0072] exist Figure 3 In the electronic device shown, the user interface 303 is mainly used to provide an input interface for the user and to obtain the user input data; while the processor 301 can be used to call an application program stored in the memory 305 for a fume hood fault early warning and self-diagnosis method. When executed by one or more processors 301, the electronic device performs one or more methods as described in the above embodiments.

[0073] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0074] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual couplings or direct couplings or communication connections may be through some service interfaces; indirect couplings or communication connections between apparatuses or units may be electrical or other forms.

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

[0076] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory 305 and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned memory 305 includes various media capable of storing program code, such as a USB flash drive, external hard drive, magnetic disk, or optical disk.

[0077] The foregoing description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Other embodiments of this disclosure will be readily apparent to those skilled in the art upon consideration of the disclosure in this specification. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The specification and embodiments are to be considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. A method for early warning and self-diagnosis of fume hood malfunctions, characterized in that, Applied to a server, the method includes: By periodically collecting real-time acoustic and vibration signals of the fume hood through acoustic and vibration sensors deployed at preset measuring points inside the fume hood, a time-series signal stream is generated. By performing a preset signal decomposition and feature extraction algorithm on the time series signal stream, a real-time running feature vector is generated; The real-time running feature vector is compared with the benchmark running feature vector in the preset onboard feature database in multiple dimensions to obtain the running state deviation. When the deviation of the operating state exceeds a preset deviation threshold, the real-time operating feature vector is input into a pre-trained fault classification model to obtain a fault type code; The safety risk level is determined based on the deviation between the fault type code and the operating status, and a structured diagnostic report is generated based on the safety risk level. When the safety risk level reaches the preset emergency switching level, a switching control command is generated and sent to the loop control unit of the fume hood; The structured diagnostic report is encoded into a preset data message and pushed to a preset device management platform.

2. The method according to claim 1, characterized in that, The step of generating a real-time running feature vector by performing a preset signal decomposition and feature extraction algorithm on the time series signal stream includes: The time series signal stream is decomposed using the aforementioned signal decomposition and feature extraction algorithm to obtain multiple intrinsic mode function components; Perform a Hilbert transform on the target intrinsic mode function component to obtain the instantaneous amplitude and instantaneous frequency corresponding to the target intrinsic mode function component, wherein the target intrinsic mode function component is any one of the plurality of intrinsic mode function components; Based on the instantaneous amplitude and the instantaneous frequency, construct the Hilbert time spectrum; Time-frequency domain statistical features are extracted from the Hilbert time-frequency spectrum, and the real-time running feature vector is generated by combining all the time-frequency domain statistical features.

3. The method according to claim 2, characterized in that, The construction of the Hilbert time spectrum based on the instantaneous amplitude and the instantaneous frequency includes: For the target intrinsic mode function components, the corresponding sampling time point sequence in the time series signal stream is used as time information. The corresponding instantaneous frequency is used as frequency information, and the square of the corresponding instantaneous amplitude is used as energy information; A two-dimensional coordinate grid is constructed with the time information as rows and the frequency information as columns, and the energy information is mapped to the numerical values ​​of the corresponding coordinate points on the two-dimensional coordinate grid to obtain the Hilbert time spectrum.

4. The method according to claim 2, characterized in that, The step of comparing the real-time running feature vector with the baseline running feature vector in the preset onboard feature database in multiple dimensions to obtain the running state deviation includes: Retrieve the corresponding component reference feature vectors for the target intrinsic mode function components from the onboard feature database; The component deviation is obtained by calculating the Mahalanobis distance between the time-frequency domain statistical features and the corresponding component reference feature vectors; The operating state deviation is obtained by weighting and fusing the preset fault sensitivity weights corresponding to all the target intrinsic mode function components with the corresponding component deviations.

5. The method according to claim 1, characterized in that, The step of inputting the real-time running feature vector into a pre-trained fault classification model to obtain the fault type code includes: The internal feature components of the real-time running feature vector are weighted by the attention mechanism in the fault classification model to generate a weighted feature representation. The output layer of the fault classification model calculates the probability value of the real-time running feature vector belonging to each preset fault category based on the weighted feature representation, thereby generating a fault category probability distribution. Determine the target fault category with the highest probability value in the fault category probability distribution, and use the code corresponding to the target fault category as the fault type code.

6. The method according to claim 1, characterized in that, The step of determining the safety risk level based on the deviation between the fault type code and the operating state, and generating a structured diagnostic report based on the safety risk level, includes: By using a pre-defined fault component association model, the root cause component identifier is determined based on the fault type code and the real-time operating feature vector. The risk assessment rule corresponding to the fault type code is retrieved from the onboard feature database, and the safety risk level is calculated and generated based on the deviation between the risk assessment rule and the operating state. Based on the fault root cause component identifier, component fault evolution data and maintenance procedure identifier are retrieved from the onboard feature database, and the component fault evolution data, maintenance procedure identifier and safety risk level are combined to generate the structured diagnostic report.

7. The method according to claim 6, characterized in that, The step of retrieving the risk assessment rule corresponding to the fault type code from the onboard feature database, and calculating and generating the safety risk level based on the deviation between the risk assessment rule and the operating state, includes: Based on the fault type code, retrieve the corresponding risk calculation parameter set from the onboard feature database. The risk calculation parameter set includes a basic risk score and a deviation influence factor. The dynamic risk increment is obtained by calculating the deviation of the operating state and the deviation influencing factor. The basic risk score and the dynamic risk increment are summed, and the safety risk level is determined based on the correspondence between the comprehensive risk value obtained by the summing process and the preset risk level classification threshold.

8. An electronic device, characterized in that, The device includes a processor, a memory, a user interface, and a network interface. The memory is used to store instructions. The user interface and the network interface are both used to communicate with other devices. The processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed, perform the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on an electronic device, it causes the electronic device to perform the method as described in any one of claims 1-7.

Images