A garage control method, device, equipment, and storage medium

Abstract

This application discloses a parking garage management method, device, equipment, and storage medium, relating to the field of computer technology. The method collects physical operation data and task context information in parallel through sensors and controllers, and makes comprehensive decisions based on multi-source data to improve the accuracy of fault diagnosis and fault-crossing decisions. By dynamically determining signal filtering conditions based on task context information and adaptively filtering physical operation data, the quality of signal filtering and feature extraction is improved, thereby increasing the accuracy of inference results. Crossing permission conditions are determined based on task context information, and hierarchical control instructions are generated in conjunction with the inference results. This allows the parking garage to operate with faults under tolerable fault conditions and permissible task status, continuing to complete the current parking and retrieval task instead of immediately shutting down. While ensuring operational safety, this reduces the frequency of parking garage shutdowns, improves the parking garage's continuous operation capability, and enhances the overall operating efficiency and user parking and retrieval experience.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a garage management method, device, equipment, and storage medium. Background Technology

[0002] In existing industrial equipment operation and maintenance management, such as garage control, threshold judgments or fault analysis are typically performed based on physical sensor data to identify equipment malfunctions. However, the signal characteristics of equipment differ at different operating stages. Existing solutions generally employ fixed signal processing strategies and diagnostic thresholds, failing to accurately identify faults at different operating stages of the garage. This results in normal shocks during startup being easily misjudged as faults, while genuine anomalies during load changes are easily missed, leading to poor accuracy and robustness in fault diagnosis. Furthermore, related technologies trigger shutdown protection upon detecting anomalies, causing even minor, non-fatal faults to cause equipment shutdowns and task interruptions. This not only affects the garage's continuous operation and user experience but also increases its operation and maintenance costs. Summary of the Invention

[0003] In view of this, the purpose of this invention is to provide a garage management method, device, equipment, and storage medium that can improve the continuous operation capability of the garage and enhance the user experience. The specific solution is as follows: Firstly, this application discloses a garage management method, including: Raw data is collected through sensors and controllers in the garage; the raw data includes physical operation data and task context information. Based on the task context information, the signal filtering conditions are determined, and the physical operation data is filtered according to the signal filtering conditions to obtain a multi-domain signal. Physical state feature vectors and fault tolerance feature vectors are extracted from the multi-domain signals, and task feature vectors are extracted from the task context information. A feature matrix is ​​obtained by concatenating all feature vectors. The reasoning results are obtained based on the feature matrix; the reasoning results include fault type, severity level, remaining lifetime probability distribution, and fault travel feasibility; the fault travel feasibility characterizes the degree to which the current fault allows the garage to continue to complete the current vehicle storage and retrieval task without complete shutdown; The current travel permission conditions are determined based on the task context information, and garage control instructions are generated based on the travel permission conditions and the inference results; the garage control instructions include normal operation instructions, waiting condition operation instructions, and stop operation instructions.

[0004] Optionally, the step of extracting physical state feature vectors and fault-tolerant feature vectors from the multi-domain signals, and extracting task feature vectors from the task context information, includes: Target indicators are extracted from the multi-domain signal, and physical state feature vectors are obtained based on the target indicators; the target indicators include any one or more of the following: peak value, kurtosis, margin, bandwidth energy, modulation sideband ratio, and order characteristics; Based on the task context information and load rate, the task feature vector is obtained; Based on the multi-domain signal, the fault trend slope, instantaneous amplitude controllability, and signal energy change rate are determined to obtain the fault-tolerant feature vector.

[0005] Optionally, the multi-domain signal includes a time-domain signal, a frequency-domain signal, and a time-frequency-domain signal; determining the fault trend slope, instantaneous amplitude controllability, and signal energy change rate based on the multi-domain signal includes: Obtain the numerical sequence of the first target feature within a continuous time window; the first target feature is a feature characterizing the health status of the garage. The numerical sequence is fitted, and the slope obtained from the fitting is used as the fault trend slope; the fault trend slope characterizes the trend and speed of fault change. The instantaneous amplitude controllability is calculated based on the amplitude change rate of the time-domain signal and a preset amplitude change rate threshold; wherein, the instantaneous amplitude controllability characterizes the degree of controllability of the current amplitude change; The rate of change of signal energy is calculated using a sliding window based on the time-domain signal.

[0006] Optionally, the step of determining signal filtering conditions based on the task context information and filtering the physical operation data according to the signal filtering conditions to obtain multi-domain signals includes: The physical operation data is processed for sensor baseline offset and outlier removal. The filter parameters are dynamically adjusted based on the task context information to reduce the high-frequency suppression intensity during the task startup phase and improve the response capability to non-stationary components during the speed change or emergency stop phase. The processed physical operation data is subjected to multimodal filtering based on the filter parameters; the multimodal filtering includes bandpass filtering, wavelet filtering, and Kalman filtering. The multi-domain signal is determined based on the filtered physical operation data; the multi-domain signal includes time-domain signal, frequency-domain signal, and time-frequency-domain signal.

[0007] Optionally, the acquisition of raw data through sensors and controllers in the garage includes: Physical operation data is collected in real time by sensors; the physical operation data includes any one or more of the following: original vibration waveform, original temperature signal, original current waveform, original voltage waveform, rotational speed value, and load value. The controller collects task context information in real time; the task context information includes task code, running stage, working mode, and operations allowed by the executor.

[0008] Optionally, the reasoning based on the feature matrix to obtain the reasoning result includes: Based on the feature matrix, the first inference task, the second inference task, and the third inference task are executed in parallel to obtain the inference result; The first reasoning task includes inputting the feature matrix into the fault diagnosis model and obtaining the fault type and severity level based on the output. The second inference task includes inputting the feature matrix into the prediction model and obtaining the remaining lifetime probability distribution based on the output; The third reasoning task includes inputting the feature matrix into the crossing feasibility assessment module and determining the feasibility of crossing the fault by combining the feature threshold and the rule set.

[0009] Optional garage management methods also include: The model parameters of the fault diagnosis model and the prediction model, as well as the feature thresholds in the crossing feasibility assessment module, are dynamically adjusted based on the task context information.

[0010] Optionally, the step of determining fault traversal feasibility by combining feature thresholds and rule sets includes: The second target feature is extracted based on the feature matrix; the second target feature is a feature that characterizes the garage's operating status, including electrical parameters, mechanical parameters, environmental parameters, and communication parameters; The level of violation of each second target feature is determined by comparing each second target feature with its corresponding feature threshold. The out-of-limit level and the fault-tolerant feature vector are input into the rule engine, which performs rule matching based on the rule set and outputs the fault traversal feasibility.

[0011] Optionally, generating garage control instructions based on the crossing permission conditions and the reasoning result includes: The current crossing permission conditions are determined based on the task context information, and the crossing permission conditions include allowing crossing or prohibiting crossing; the feasibility of fault crossing includes fully feasible, conditionally feasible, or infeasible. When the crossing permission condition is "crossing is allowed" and the fault crossing feasibility is "fully feasible", a normal operation instruction is generated; When the crossing permission condition is "crossing is allowed" and the fault crossing feasibility condition is "feasible", a condition-pending execution instruction is generated, and the crossing event is recorded. When the crossing permission condition is prohibited or the fault crossing feasibility is not feasible, a stop operation command is generated and a maintenance work order is generated.

[0012] Secondly, this application discloses a garage control device, comprising: The data acquisition module is used to collect raw data through sensors and controllers in the garage; the raw data includes physical operation data and task context information. The signal filtering module is used to determine the signal filtering conditions based on the task context information, and to filter the physical operation data according to the signal filtering conditions to obtain multi-domain signals. The feature extraction module is used to extract physical state feature vectors and fault tolerance feature vectors from the multi-domain signals, extract task feature vectors from the task context information, and obtain a feature matrix by concatenating all feature vectors. The inference module is used to perform inference based on the feature matrix to obtain inference results; the inference results include fault type, severity level, remaining lifetime probability distribution, and fault travel feasibility; the fault travel feasibility characterizes the degree to which the current fault allows the garage to continue to complete the current vehicle storage and retrieval task without complete shutdown; The garage control module is used to determine the current crossing permission conditions based on the task context information, and generate garage control instructions based on the crossing permission conditions and the inference results; the garage control instructions include normal operation instructions, waiting condition operation instructions, and stop operation instructions.

[0013] Thirdly, this application discloses an electronic device, including: Memory, used to store computer programs; A processor is used to execute the computer program to implement the aforementioned garage management method.

[0014] Fourthly, this application discloses a computer-readable storage medium for storing a computer program; wherein the computer program, when executed by a processor, implements the aforementioned garage management method.

[0015] In this application, raw data is collected through sensors and controllers in the garage; the raw data includes physical operation data and task context information; signal filtering conditions are determined based on the task context information, and the physical operation data is filtered according to the signal filtering conditions to obtain multi-domain signals; physical state feature vectors and fault tolerance feature vectors are extracted from the multi-domain signals, and task feature vectors are extracted from the task context information; a feature matrix is ​​obtained by concatenating all feature vectors; inference is performed based on the feature matrix to obtain inference results; the inference results include fault type, severity level, remaining lifetime probability distribution, and fault travel feasibility; the fault travel feasibility characterizes the degree to which the current fault allows the garage to continue to complete the current vehicle storage and retrieval task without complete shutdown; the current travel permission conditions are determined based on the task context information, and garage control instructions are generated based on the travel permission conditions and the inference results; the garage control instructions include normal operation instructions, waiting condition operation instructions, and stop operation instructions.

[0016] It is evident that by acquiring physical operation data and task context information in parallel through sensors and controllers, and making comprehensive decisions based on multi-source data, the accuracy of fault diagnosis and fault-crossing decisions is improved. By dynamically determining signal filtering conditions based on task context information and adaptively filtering physical operation data, the quality of signal filtering and feature extraction is improved, thereby enhancing the accuracy of inference results. By determining crossing permission conditions based on task context information and generating tiered control instructions in conjunction with the inference results, the parking garage can operate with faults under tolerable fault conditions and permissible task status, continuing to complete the current vehicle storage and retrieval task instead of immediately shutting down.

[0017] Furthermore, task context information is simultaneously involved in the parameter adjustment of adaptive filtering, the construction of feature matrices, the determination of crossing permission conditions, and the generation of hierarchical control instructions. This ensures that signal processing, feature extraction, inference, and instruction generation are based on the same operational stage information, avoiding inconsistencies that may result from independent judgments in each stage. Based on the same operational stage information, the filtering stage adjusts its processing strategy according to the current stage to adapt to signal characteristics, the inference stage adjusts its diagnostic strategy to match signal change patterns, and the decision-making stage adjusts the crossing permission conditions to meet task safety requirements. This allows the system to balance fault identification accuracy and tolerance for reasonable anomalies at different operational stages. This transforms garage management from a fault-based shutdown mode to a mode with fault perception, task adaptation, and intelligent crossing support. While ensuring operational safety, it reduces garage downtime frequency, improves continuous garage operation capability, enhances overall garage operating efficiency, and improves the user's parking and retrieval experience. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0019] Figure 1 A flowchart of a garage management method provided in this application; Figure 2 A flowchart illustrating a specific method for acquiring raw data is provided in this application; Figure 3 A flowchart of a specific filtering method provided in this application; Figure 4 A flowchart of a specific feature vector extraction method provided in this application; Figure 5 This application provides a flowchart of a specific control instruction and work order generation method; Figure 6 A flowchart illustrating a specific inference method based on a feature matrix provided in this application; Figure 7 A flowchart illustrating a specific method for determining the feasibility of fault ride-through, as provided in this application; Figure 8 A flowchart illustrating a specific post-processing method based on control commands or maintenance work orders provided in this application; Figure 9 A schematic diagram of a specific garage control system provided in this application; Figure 10 A schematic diagram of a garage control device provided in this application; Figure 11 This application provides a structural diagram of an electronic device. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] In existing technologies, shutdown is triggered upon detecting an anomaly, meaning even minor, non-fatal malfunctions can affect operational continuity, causing task interruptions and increasing operating costs. To overcome these technical problems, this application discloses a garage management method, see [link to relevant documentation]. Figure 1 As shown, the method may include the following steps: Step S11: Collect raw data through the sensors and controllers of the garage; the raw data includes physical operation data and task context information.

[0022] The parking garage will be equipped with various types of sensors, such as vibration sensors, current transformers, and voltage transformers; as well as controllers, such as PLCs (Programmable Logic Controllers) or DCSs (Distributed Control Systems). Raw data will be collected in real time through these sensors and control systems. This raw data includes physical operational data and task context information. Specifically, the parking garage described above can be a multi-level parking garage.

[0023] Physical operation data refers to sensor signals reflecting the physical state of the garage equipment. This data is directly collected by sensors and characterizes the real-time operating status of the garage's mechanical structure and electrical system. Task context information refers to data reflecting the tasks currently being performed by the garage and their specific stages. This data is read in real-time through the controller's communication interface. This multi-source data collection provides a complete data foundation for subsequent determination of control commands.

[0024] In some embodiments, the acquisition of raw data via sensors and controllers in the garage includes: real-time acquisition of physical operating data via sensors; the physical operating data includes any one or more of the following: raw vibration waveforms, raw temperature signals, raw current waveforms, raw voltage waveforms, rotational speed values, and load values. For example... Figure 2 As shown, raw vibration waveforms are acquired using vibration acceleration or velocity sensors, raw temperature signals are acquired using temperature sensors, raw current / voltage waveforms are acquired using current / voltage sensors, and speed / load values ​​are acquired using speed / load sensors. These raw waveforms are used as physical operating data. For example, data acquisition includes, but is not limited to, mechanical vibrations of lifting motors and traversing motors, motor winding temperatures, drive current and voltage waveforms, component speeds, and load signals.

[0025] Simultaneously, the controller collects task context information in real time; this task context information includes the task code, operating stage, working mode, and permitted operations of the actuator. For example, task context information includes, but is not limited to, the currently executing task code, such as the A3 vehicle retrieval task and the B7 vehicle storage task; the current operating stage of the equipment, such as startup, steady-state operation, speed change, emergency stop, etc.; the working mode, such as batch mode or continuous mode; and the permissible action boundaries of the actuator, i.e., the permitted operations, such as allowing speed reduction, allowing load reduction, allowing bypass, etc.

[0026] Step S12: Determine the signal filtering conditions based on the task context information, and filter the physical operation data according to the signal filtering conditions to obtain a multi-domain signal.

[0027] Because physical operation data contains various noises, such as environmental vibration noise and electromagnetic interference, it needs to be processed before feature extraction. Furthermore, considering that useful components in the physical operation data have different frequency domain characteristics at different operation stages—for example, there are normal transient impacts during startup, relatively stable signals during steady-state operation, and non-stationary abrupt changes during acceleration / sudden stop—the filtering strategy is dynamically adjusted according to the task context to achieve task-adaptive filtering, improve the quality of the filtered signal, and retain the important information needed for feature extraction at different stages.

[0028] Specifically, the current operational phase identifier, such as startup, steady-state, speed change, or emergency stop, is first parsed from the task context information. Then, the signal filtering conditions are dynamically determined based on this phase identifier, i.e., the filter's operating parameters are configured, thereby matching the signal filtering strategy with the actual operating state of the equipment. For example, during startup, the filter's cutoff frequency is lowered to reduce suppression of high-frequency components and avoid mistakenly filtering out normal transient impacts during startup; during speed change or emergency stop, the filter's cutoff frequency is increased to enhance the response sensitivity to non-stationary transient components, capturing fault impacts and abrupt signals; during steady-state, standard filtering parameters are maintained to achieve a balance between noise suppression and signal fidelity.

[0029] According to the established signal filtering conditions, the collected physical operation data undergoes multimodal filtering. Multimodal filtering refers to the comprehensive processing of different types of noise and interference using various filtering methods. For example, bandpass filtering can preserve the effective components within the fault characteristic frequency band and filter out out-of-band noise; wavelet filtering can extract transient impulse components from the signal and suppress broadband random noise; and Kalman filtering can smooth slowly varying signals such as speed, temperature, and load. After filtering, noise in the physical operation data is effectively suppressed, while effective components related to the fault are preserved.

[0030] Multi-domain signals are extracted from the filtered signal; these signals include the time domain, frequency domain, and time-frequency domain. The time-domain signal retains the original waveform characteristics of the signal amplitude changing over time, used to extract transient indicators such as peak impulses; the frequency-domain signal is obtained through Fourier transform and used to analyze the signal's frequency components and sideband modulation characteristics; the time-frequency domain signal is determined through time-frequency analysis, such as short-time Fourier transform or wavelet transform, and used to capture the time-varying spectral characteristics of non-stationary signals. Multi-domain signals can characterize the operating status of garage equipment from different dimensions, thus improving the comprehensiveness of feature extraction by extracting features based on multi-domain signals rather than single signals.

[0031] In some embodiments, for example Figure 3 As shown, the step of determining signal filtering conditions based on the task context information and filtering the physical operation data according to the signal filtering conditions to obtain multi-domain signals may include the following steps: S201: Perform sensor baseline offset processing and outlier removal processing on the physical operation data.

[0032] Before filtering, the physical operation data is preprocessed. Preprocessing includes sensor baseline offset elimination and outlier removal. It is understood that during long-term operation, sensors may experience baseline offset due to temperature drift, zero drift, etc., causing the overall signal to deviate from the zero line. This can be addressed by calculating the average value of the signal over a long time window and subtracting this average value from each sampling point; or by using a high-pass filter to remove DC and ultra-low frequency components; the specific baseline offset elimination method is not limited in this embodiment. Due to occasional sensor malfunctions or strong electromagnetic interference, abnormal spikes far exceeding the normal range may appear in the acquired signal. These are invalid data and will affect the accuracy of subsequent feature extraction. Specifically, a median filtering method can be used, replacing outliers with the median value within the window; the specific outlier removal method is not limited in this embodiment.

[0033] S202: Dynamically adjust the filter parameters according to the task context information to reduce the high-frequency suppression intensity during the task startup phase and improve the response capability to non-stationary components during the speed change or emergency stop phase.

[0034] The filter's operating parameters are dynamically adjusted based on task context information to match the filter's signal processing characteristics with the current operating conditions, achieving adaptive filtering where the filtering strategy changes with the task stage. Filter parameters include, but are not limited to: filter cutoff frequency, filter bandwidth, filter order, wavelet decomposition level, Kalman filter process noise covariance Q, and measurement noise covariance R. Specifically, the dynamic adjustment of these filter parameters can be triggered by the task status monitoring module; that is, when the task stage identifier changes, the filter parameters are automatically switched to the target configuration for the corresponding stage.

[0035] For example, during startup, the equipment naturally generates normal transient impacts as it transitions from a standstill to motion. These impacts are high-frequency components in the frequency domain, but they are normal signals, not faults. To preserve the details of these normal impacts and avoid them being falsely filtered out, the cutoff frequency of the bandpass filter is lowered to reduce the suppression of high-frequency components, the decomposition level of the wavelet filter is reduced to retain more transient details, and the process noise covariance of the Kalman filter is increased to speed up the response, allowing the filtered output to track signal changes more quickly and avoid lag. In the steady-state phase, the equipment operates smoothly, and the signal characteristics are relatively stable. At this time, the filter parameters can be maintained at standard configurations, achieving a balance between noise suppression and signal fidelity. The cutoff frequency and filter bandwidth are set according to the conventional fault diagnosis frequency. During speed change or sudden stop phases, the equipment's operating state changes drastically, and transient impacts or abrupt signal changes may occur. For these non-stationary components, the cutoff frequency of the bandpass filter can be increased to allow higher-frequency transient components to pass through, the decomposition level of the wavelet filter can be increased to extract deeper transient features, and the measurement noise covariance of the Kalman filter can be reduced to enhance the response to changes.

[0036] It should be noted that the execution order of the above steps S201 and S202 is not limited in this embodiment. S201 can be executed first and then S202, or S202 can be executed first and then S201, or they can be executed in parallel.

[0037] S203: Perform multimodal filtering on the processed physical operation data according to the filter parameters; the multimodal filtering includes bandpass filtering, wavelet filtering and Kalman filtering.

[0038] Multimodal filtering is performed on the physical operation data based on dynamically adjusted filter parameters. Multimodal filtering includes, but is not limited to, bandpass filtering, wavelet filtering, and Kalman filtering; that is, one or more filtering methods are adaptively selected. Different filtering methods are used to process different noise types and signal components in the physical operation data. For example, bandpass filtering and wavelet filtering are applied simultaneously to vibration signals, while Kalman filtering is applied to rotational speed signals.

[0039] S204: Determine multi-domain signals based on filtered physical operation data; the multi-domain signals include time-domain signals, frequency-domain signals, and time-frequency-domain signals.

[0040] Multi-domain signals are generated from the physical operation data after filtering. Specifically, the time-domain waveform is retained as the time-domain signal; a Fourier transform is performed on the time-domain signal to obtain the frequency-domain signal, which reflects the amplitude distribution of each frequency component; and time-frequency analysis methods are used to obtain the time-frequency domain signal, which reflects the changes in frequency components over time.

[0041] Step S13: Extract the physical state feature vector and fault tolerance feature vector from the multi-domain signal, extract the task feature vector from the task context information, and obtain the feature matrix by concatenating all feature vectors.

[0042] For example Figure 4 As shown, after obtaining multi-domain signals, three types of feature vectors can be extracted in parallel. The physical state feature vector describes the physical health status of the garage equipment; the task feature vector describes the current task and operating condition of the garage; and the fault tolerance feature vector describes the evolution trend and controllability of the fault. Finally, the physical state feature vector, task feature vector, and fault tolerance feature vector are concatenated column-wise to form a structured feature matrix. It should be noted that each column position in the structured feature matrix has a definite mapping relationship with the feature type, facilitating model training, feature tracing, and result interpretation. Through the extraction and concatenation of multiple types of features, subsequent inference can simultaneously perceive the garage's health status, task stage, and whether the fault is controllable, providing a foundation for accurate fault diagnosis and control decisions.

[0043] The extraction process of the aforementioned physical state feature vector includes: extracting target indicators from the multi-domain signal, and obtaining a physical state feature vector based on the target indicators; the target indicators include any one or more of peak value, kurtosis, margin, bandwidth energy, modulation sideband ratio, and order features. Specifically, peak value, kurtosis, margin, and other statistical quantities can be calculated from the time-domain signal; bandwidth energy and modulation sideband ratio can be extracted from the frequency-domain signal; order features can be obtained from the order domain based on rotational speed order tracking; and the above indicators are combined to form the physical state feature vector.

[0044] The process of extracting the task feature vector includes: obtaining the task feature vector based on the task context information and load rate. Specifically, the task code, stage duration, and load rate can be extracted from the task context information, and then subjected to one-hot encoding, normalization, and quantization to convert them into numerical features, which are then combined to form the task feature vector.

[0045] The extraction process of the aforementioned fault-tolerant feature vector includes: determining the fault trend slope, instantaneous amplitude controllability, and signal energy change rate based on the multi-domain signal to obtain the fault-tolerant feature vector. The fault trend slope characterizes the direction and speed of change of fault feature values ​​over time, and can be obtained by linearly fitting the feature values ​​within a continuous time window using the least squares method. Instantaneous amplitude controllability characterizes whether the degree of drastic change in signal amplitude within a unit time is within a controllable range, and is determined by comparing the amplitude change rate with a preset tolerance threshold. The signal energy change rate characterizes the fluctuation intensity of the equipment's operating energy, and is calculated based on the time-domain signal using a sliding window; specifically, it can be determined by calculating the rate of change of the sum of squares or root mean square value of the time-domain signal using a sliding window, or by calculating the rate of change of the envelope square of the signal after bandpass filtering.

[0046] In some embodiments, the above-mentioned fault trend slope calculation process includes: acquiring a numerical sequence of a first target feature within a continuous time window; the first target feature is a feature characterizing the health status of the garage; fitting the numerical sequence, and using the fitted slope as the fault trend slope; the fault trend slope characterizes the trend and speed of fault change. The first target feature may be an effective vibration value, peak value, kurtosis, etc.; that is, within a continuous time window, the changing trend of a certain health / fault-related feature such as an effective vibration value, peak value, kurtosis, etc., is extracted, and the slope of the linear fit is used to quantify the speed and direction of fault development, with a positive slope indicating deterioration and a negative slope indicating improvement.

[0047] Detailed calculation process: (1) Obtaining time series data: Set a time window Equal-interval sampling, with an interval of The corresponding eigenvalue is ; (2) Establish a linear model: Assume ,in The slope to be determined is... The intercept; (3) Least squares estimate of slope: Minimize the sum of squared residuals: ; Solve for the slope Closed expression: ; in: .

[0048] (4) Output the fault trend slope. As one of the fault-tolerant features, it is directly used for subsequent health assessments or fault predictions. For example, by taking the vibration peak values ​​of the most recent 10 sampling points, time points 1, 2, ..., 10, the following can be calculated: This indicates that the peak value is increasing at an average rate of 0.32 m / s² per sampling period, suggesting that the fault is worsening.

[0049] In some embodiments, the instantaneous amplitude controllability calculation process includes: calculating instantaneous amplitude controllability based on the amplitude change rate of the time-domain signal and a preset amplitude change rate threshold; wherein, the instantaneous amplitude controllability characterizes the degree of controllability of the current amplitude change. Instantaneous amplitude controllability can measure the degree of drastic change in the instantaneous amplitude of a signal per unit time and provide a controllability index relative to an acceptable threshold; that is, whether the current change exceeds the system's tolerance range, and is often used to capture early shocks, transient disturbances, or non-stationary characteristics.

[0050] The calculation process is as follows: (1) Calculate the instantaneous amplitude change rate. For the original signal Or the demodulated envelope amplitude Its instantaneous amplitude change rate is defined as: ,or ,in The sampling interval is denoted as .

[0051] (2) Calculate the instantaneous amplitude controllability index. The amplitude change rate describes the degree of drastic change in the signal amplitude per unit time; the larger the change rate, the more drastic the change in the equipment state has occurred in a very short time, and the system does not have time to respond and adjust, thus the higher the risk of loss of control. Obtain the preset amplitude change rate tolerance threshold, and calculate the instantaneous amplitude controllability index based on the comparison result between the calculated instantaneous amplitude change rate and the tolerance threshold; For example, suppose the threshold for the rate of change of amplitude specified by the system or industry standard is... The threshold for the rate of change of amplitude can be determined based on the statistical distribution of historical normal data or industry experience; instantaneous amplitude controllability It can be calculated as: ; That is, when the instantaneous amplitude change rate is less than or equal to the tolerance threshold, the controllability index is 1, indicating that the amplitude change is within the controllable range; when the instantaneous amplitude change rate is greater than the amplitude change rate threshold, the controllability index is 0, indicating that the amplitude change is out of control.

[0052] Alternatively, a relative over-limit ratio can be used: ; in, The closer the value is to 1, the more controllable the current amplitude change is; the closer it is to 0, the more severely out of control it is. For example, the threshold for the rate of change of the motor current envelope amplitude is set to... Calculated at a certain moment Then controllability ;like If C=0, then the system is out of control.

[0053] Finally, the minimum, average, or percentage of time exceeding the preset amplitude change rate threshold within a time window can be used as an indicator to form the fault-tolerant feature vector.

[0054] Step S14: Based on the feature matrix, reasoning is performed to obtain the reasoning result; the reasoning result includes fault type, severity level, remaining lifetime probability distribution and fault travel feasibility; the fault travel feasibility characterizes the degree to which the current fault allows the garage to continue to complete the current vehicle storage and retrieval task without complete shutdown.

[0055] In this embodiment, multiple inference models are used in parallel processing based on the feature matrix to obtain the fault type, severity rating, remaining lifetime probability distribution, and fault ride-through feasibility as inference results. The fault type refers to the specific fault category identified, such as motor winding overheating or lifting motor bearing wear. The severity rating quantifies the severity of the fault, such as fatal fault or negligible fault. The remaining lifetime probability distribution predicts the time the equipment can continue to operate normally in its current state, outputting it as a probability distribution in minutes or access counts. This prediction is determined by the lifetime prediction model through a degradation trajectory fitting method, which involves fitting historical degradation data into a degradation curve and extrapolating it to the failure threshold; or by the lifetime prediction model through a similarity matching method, which involves matching the current degradation pattern with similar cases in a historical case library.

[0056] Fault tolerance refers to the system's ability to intelligently determine whether a non-fatal fault or anomaly in the parking garage equipment can be tolerated or bypassed, allowing the current vehicle retrieval task to continue without a complete shutdown. Maintenance or repairs are then scheduled after the task is completed. The goal is to avoid the problem of vehicles getting stuck and unable to be retrieved due to a fault, ensuring a good user experience and basic garage operation. A fault refers to an abnormal state or parameter exceeding limits during garage operation, but not necessarily a fatal problem that immediately leads to equipment damage or a safety accident. Examples include voltage drops, control circuit voltage fluctuations, and slight motor current imbalances. Fault tolerance refers to adjusting the operating strategy to complete the current task without immediate shutdown. Specific operations include reduced speed operation (e.g., reducing speed by 50% when motor temperature slightly exceeds limits), unloaded operation (only completing currently initiated retrieval actions and not accepting new tasks), and bypass / cached instructions (using locally cached instructions to continue execution during brief communication interruptions without triggering an emergency stop). Feasibility refers to the system's determination, based on real-time data and rules, whether fault tolerance is permissible and to what extent.

[0057] Fault travel feasibility characterizes the extent to which a current fault allows the garage to continue completing the current vehicle storage and retrieval task without a complete shutdown. Specifically, it can be categorized into three types: SUCCESS (completely feasible), indicating that the fault does not affect the current storage and retrieval task and allows full functionality; POSSIBLE (conditionally feasible), indicating that the fault can be tolerated by reducing speed, unloading, or bypassing, allowing for maintenance after the current storage and retrieval task is completed; and IMPOSSIBLE (infeasible), indicating that the fault requires immediate shutdown for handling. Fault travel feasibility is determined by the travel feasibility assessment module combining feature threshold judgment and rule engine reasoning.

[0058] Step S15: Determine the current crossing permission conditions based on the task context information, and generate garage control instructions based on the crossing permission conditions and the inference result; the garage control instructions include normal operation instructions, waiting condition operation instructions, and stop operation instructions.

[0059] After obtaining the inference results, it is necessary to comprehensively determine whether the current task state allows for a traversal operation, and whether traversal is feasible from the perspective of equipment and faults. Specifically, the current traversal permission conditions are determined based on the task context information. It is understandable that the traversal permission conditions are hard constraints, directly parsed from the task context, rather than derived through model inference. For example, when the equipment is in an emergency shutdown phase, for safety reasons, the traversal permission condition is "traversal prohibited," meaning that regardless of how minor the fault or how healthy the equipment, no traversal operation is allowed, and a safe shutdown is mandatory. When the equipment is in a stable operation phase, the traversal permission condition is "traversal permitted," meaning that the decision-making level is allowed to decide whether and how to traverse based on the fault situation.

[0060] The reasoning results are comprehensively arbitrated with the crossing permission conditions to generate the final garage control instructions. These instructions include three types: Normal operation instructions, indicating that the equipment is fault-free or has a very minor fault, requiring no restrictions and operating at full capacity; Condition-awaited operation instructions, indicating that the equipment has a tolerable fault, and the system adjusts its operating strategy (such as speed reduction, load reduction, or bypass buffering) to allow the garage to continue completing the current parking and retrieval task, but maintenance must be scheduled after the task is completed; this instruction allows the equipment to complete critical tasks without complete shutdown; and Stop operation instructions, indicating a serious fault or being in a prohibited crossing phase, requiring immediate safe shutdown and triggering maintenance procedures.

[0061] As can be seen, by combining the hard constraints of permission with the inference results, both task safety and fault tolerance are ensured, enabling garage management to balance safety and continuity. This reduces the frequency of system downtime due to minor faults, guaranteeing garage availability and user experience, and achieving intelligent management of the garage.

[0062] In some preferred embodiments, the step of generating garage control instructions based on the crossing permission conditions and the reasoning result, for example... Figure 5 As shown, it includes the following steps: S301: Determine the current crossing permission conditions based on the task context information, wherein the crossing permission conditions include allowing crossing or prohibiting crossing; the feasibility of fault crossing includes fully feasible, conditionally feasible, or infeasible.

[0063] The current traversal permission conditions are determined based on the task context information and serve as hard constraints for subsequent judgments. If fault traversal is not allowed in the current task phase, even if the feasibility of fault traversal indicates that it is possible, the system will not operate with the fault to ensure operational safety.

[0064] S302: When the crossing permission condition is allowed and the fault crossing feasibility is fully feasible, generate a normal operation instruction.

[0065] When the crossing permission conditions are met and the failure crossing feasibility is fully feasible, a normal operation command is generated. At this time, the equipment is fault-free or has a very minor fault that does not affect the safe execution of vehicle retrieval actions, and it operates at full capacity without any restrictions.

[0066] S303: When the crossing permission condition is allowed and the fault crossing feasibility is feasible, a condition-waiting operation instruction is generated and the crossing event is recorded; the condition-waiting operation instruction includes at least one of a speed reduction instruction, a load reduction instruction, or a bypass instruction.

[0067] When the crossing permission condition is "allowed" and the fault crossing feasibility condition is "feasible," a pending condition execution instruction is generated, and the crossing event is recorded. The specific form of the pending condition execution instruction is determined based on the fault type and severity. Optional operations include: speed reduction operation, such as reducing the motor speed by 50% but still completing the vehicle transport task; load reduction operation, only completing currently initiated access actions and no longer accepting new tasks; bypass / caching instructions, such as using locally cached instructions to continue execution during a brief communication interruption without triggering an emergency stop. The crossing event record contains key information such as trigger time, fault type, and crossing method, and is stored in the system log for subsequent analysis and backtracking.

[0068] S304: When the crossing permission condition is prohibited or the fault crossing feasibility is not feasible, a stop operation instruction is generated and a maintenance work order is generated.

[0069] When the crossing permission condition is "crossing prohibited" or the feasibility of fault crossing is "not feasible," the system generates a stop operation command and simultaneously generates a maintenance work order. The stop operation command triggers a safety shutdown procedure to ensure that the equipment and vehicles are in a safe state. The maintenance work order includes, but is not limited to: fault type and description, severity level, recommended replacement parts list, recommended maintenance time window, and maintenance team recommendations. The maintenance work order is reported to the garage management platform or terminal to achieve automatic dispatch of maintenance tasks.

[0070] As can be seen from the above, this embodiment uses sensors and controllers to collect physical operation data and task context information in parallel, and makes comprehensive decisions based on multi-source data to improve the accuracy of fault diagnosis and fault crossing decisions. By dynamically determining signal filtering conditions based on task context information and adaptively filtering physical operation data, the quality of signal filtering and feature extraction is improved, thereby improving the accuracy of inference results. By determining crossing permission conditions based on task context information and generating hierarchical control instructions in combination with inference results, the garage can operate with faults under the premise that the fault is tolerable and the task status allows, and continue to complete the current vehicle storage and retrieval task instead of immediately shutting down; this improves the garage's continuous operation capability and enhances the user experience.

[0071] Based on the above embodiments, for example Figure 6 As shown, the reasoning obtained based on the feature matrix can include: performing a first reasoning task, a second reasoning task, and a third reasoning task in parallel based on the feature matrix to obtain the reasoning result.

[0072] The first inference task includes inputting the feature matrix into a fault diagnosis model and obtaining the fault type and severity level based on the output. The fault diagnosis model can be a random forest, convolutional neural network, long short-term memory network, or Transformer model, etc., and this embodiment is not limited to any particular model. The model takes the feature matrix as input and outputs the fault type and severity level. During the model training phase, supervised training is performed using historical labeled data. The labels for the fault types are determined based on actual garage operation and maintenance experience. Specifically, the severity level can be divided into 1 to 5 levels, where level 1 represents negligible anomalies, level 2 represents minor faults, level 3 represents moderate faults, level 4 represents severe faults, and level 5 represents fatal faults.

[0073] The second inference task includes inputting the feature matrix into a prediction model and obtaining the remaining useful life probability distribution based on the output. That is, a remaining useful life prediction model, which uses a degradation trajectory fitting method or a similarity matching method to output the remaining useful life probability distribution. This embodiment does not limit the prediction model.

[0074] The third reasoning task includes inputting the feature matrix into the crossing feasibility assessment module and determining the feasibility of fault crossing by combining feature thresholds and rule sets. The structured feature matrix is ​​input into the crossing feasibility assessment module, and the feasibility of fault crossing is determined by combining feature threshold judgment and rule engine reasoning. Feature threshold judgment refers to comparing the current real-time feature values ​​with preset safety thresholds item by item to determine the limit violation situation; rule engine reasoning is used to comprehensively reason about the limit violation results and fault tolerance features based on the expert rule set to obtain the feasibility of fault crossing, i.e., fully feasible, conditionally feasible, or infeasible.

[0075] Furthermore, it may also include: dynamically adjusting the model parameters of the fault diagnosis model and the prediction model, as well as the feature thresholds in the crossing feasibility assessment module, based on the task context information. That is, the task context information not only affects the determination of crossing permission conditions but also affects the model parameters of the fault diagnosis model and the prediction model, as well as the feature thresholds in the crossing feasibility assessment module, which in turn provide feedback and optimization. Specifically, the diagnostic sensitivity of the classification model and the prediction model, as well as the feature thresholds in the crossing feasibility assessment module, can be dynamically adjusted according to the current operational stage.

[0076] Among them, for example Figure 7 As shown, the method of determining fault crossing feasibility by combining feature thresholds and rule sets specifically includes the following steps: S401: Extract the second target feature based on the feature matrix; the second target feature is a feature that characterizes the garage's operating status, including electrical parameters, mechanical parameters, environmental parameters, and communication parameters.

[0077] Key indicators extracted in real time from the structured feature flow of the parking garage include, but are not limited to: electrical parameters, mechanical parameters, environmental parameters, and communication parameters. Electrical parameters include, but are not limited to: PLC power supply voltage, 24V DC voltage of the control circuit, motor drive current, and three-phase imbalance. Mechanical parameters include, but are not limited to: vibration amplitude (effective acceleration value) of the lifting motor, temperature of the traverse motor, chain tension, and limit switch signal status. Environmental and vehicle parameters include, but are not limited to: temperature inside the parking garage, smoke concentration; and vehicle overlength / overwidth / overheight detection values. Communication parameters include, but are not limited to: network latency and packet loss rate between the main controller and the equipment.

[0078] S402: By comparing each of the second target features with the corresponding feature threshold, the level of exceeding the limit for each of the second target features is determined.

[0079] Each real-time feature value is compared with a preset feature threshold or limit boundary. The level of exceeding the limit can be divided into four categories: no limit exceeding, slight limit exceeding, moderate limit exceeding, and severe limit exceeding.

[0080] S403: Input the out-of-limit level and the fault tolerance feature vector into the rule engine, and the rule engine performs rule matching based on the rule set and outputs the fault traversal feasibility.

[0081] The rule engine is input together with the feature threshold judgment result and the fault tolerance feature vector to finally obtain the fault crossing feasibility of the current fault: SUCCESS, POSSIBLE, and IMPOSSIBLE.

[0082] The rule set is pre-deployed, and this embodiment does not impose specific limitations on it.

[0083] For example, Rule 1: Electrical Low Voltage Ride-Through; specifically, if the supply voltage drop is less than 15% and the duration is less than 200 milliseconds, and the fault severity is ≤2, then the ride-through flag is determined as POSSIBLE (condition feasible), and the vehicle storage and retrieval operation is not stopped temporarily. This rule addresses transient voltage drops, allowing equipment to continue operating under slight voltage fluctuations.

[0084] Rule 2: Motor Overheat Tolerance; Specifically: If the motor temperature slightly exceeds the limit (level=1), and the fault type is "poor ventilation" (not short circuit or burnout), and the ambient temperature is below 40°C, derating operation (speed reduction of 50%) is permitted, and the pass-through indicator is POSSIBLE. This rule addresses motor thermal faults and allows for speed reduction pass-through provided the cause is confirmed to be non-fatal.

[0085] Rule 3: Communication Interruption Traversal; Specifically, if network latency is moderately above the limit (50~100ms), packet loss rate is less than 5%, and there are no conflicts on the ASV (Automated Storage Vehicle) path, then the traversal flag is SUCCESS (fully feasible), and the device continues operation using locally cached instructions. This rule addresses brief communication interruptions, allowing the device to autonomously complete its current task by relying on local instruction caching.

[0086] Rule 4: Fatal Faults Prohibit Crossing; Specifically: If the power supply voltage is severely exceeded, or the motor temperature is severely exceeded, or the smoke concentration exceeds the threshold, or the fault type is "limit switch failure" with a severity ≥4, then the crossing flag is IMPOSIBLE, and an emergency shutdown is immediately triggered. This rule has the highest priority; once matched, all other crossing judgments are rejected.

[0087] Rule 5: Combination Exceedance Penalty; Specifically: If the number of feature exceedances is ≥3 (regardless of whether it is mild or moderate), and the remaining lifetime is less than 5 complete access cycles, then the crossing flag is IMPOSSIBLE. This rule considers both the combined exceedance of multiple features and the approaching lifetime, and judges high-risk combination situations as uncrossable.

[0088] Rule 6: Hysteresis anti-shake logic; specifically: if the vibration amplitude fluctuates between 1.0 and 2.0 mm / s, and the number of over-limit times in the last 10 seconds is ≤3, then the crossing failure will not be triggered temporarily, and the previous crossing flag will be maintained to prevent command oscillation caused by frequent switching of over-limit states and improve the stability of decision-making.

[0089] In some embodiments, a digital twin dashboard is simultaneously generated to display health status, task progress, traversal status, and remaining lifespan countdown in real time. Parts replacement suggestions and lifespan windows are pushed to mobile devices, integrating with the work order system. Simultaneously, a closed-loop feedback system records maintenance results and actual lifespan, updating the model through transfer learning or online; after safety verification, remote or automatic traversal commands are executed.

[0090] For example Figure 8 As shown, this embodiment also discloses a post-processing method based on control commands or maintenance work orders, used to realize visualized monitoring, alarm push, work order management, closed-loop feedback, and safe execution of crossing commands for garage control. The digital twin dashboard displays the real-time operating status of garage equipment, including equipment health status, task completion status, crossing status, and predictive maintenance countdown; maintenance personnel can obtain the complete operating status of the equipment in one stop through the visual interface.

[0091] When the system generates a maintenance work order or repair suggestion, the alarm module pushes alarm information to the mobile terminal (APP / PC), including parts replacement suggestions and remaining life window; at the same time, the system connects to the work order system to automatically dispatch maintenance tasks to maintenance personnel, realizing the automated flow from alarm to work order.

[0092] After a control command is generated, it must undergo safety verification before execution. Safety verification includes, but is not limited to: confirming that command execution will not cause equipment damage or safety accidents, confirming that the actuator allows the operation, and confirming that the current task status supports the command. After successful safety verification, the control command is sent to the controller, and the garage performs operations such as speed reduction, load reduction, or bypass. After the command is executed, the maintenance results and actual remaining lifespan are recorded. This data is fed back to the classification model, prediction model, and traverse feasibility assessment module through transfer learning or online updates, enabling incremental learning or parameter fine-tuning based on new operational data and maintenance results.

[0093] For example Figure 9The diagram illustrates a specific parking garage management system, comprising a seven-layer architecture: a perception layer, a signal processing layer, a feature engineering layer, a model and learning layer, a task status monitoring layer, an intelligent operation and maintenance decision-making layer, and an application layer. The perception layer is responsible for collecting multi-source physical quantities, including signals such as vibration, temperature, current, voltage, speed, and load, to obtain raw signal waveforms, i.e., physical operation data; simultaneously, it acquires task context information through the controller. The signal processing layer, based on signal filtering conditions determined by the task context information, performs time-domain, frequency-domain, and time-frequency-domain purification processing on the physical operation data, including filtering, noise reduction, and trend separation. The feature engineering layer constructs physical state feature vectors, fault-tolerant feature vectors, and task feature vectors, concatenating them to obtain a feature matrix. The inference layer performs hybrid diagnosis and prediction, employing semi-supervised learning or transfer learning methods to run fault diagnosis and prediction models, and embedding a fault-crossing feasibility assessment module containing fault-crossing logic. The output inference results include fault type, severity level, remaining lifetime probability distribution, and fault-crossing feasibility. The task status monitoring layer realizes operational condition perception and task stage identification. Through coupling with equipment operation stages and process tasks, it dynamically adjusts the model parameters of the fault diagnosis model and prediction model, as well as the feature thresholds in the fault crossing feasibility assessment module. The intelligent operation and maintenance decision layer generates garage control instructions, or alarm work orders and maintenance suggestions based on the fault crossing conditions and the inference results, and performs graded handling in conjunction with life prediction: low-severity faults trigger fault crossing strategies, and high-severity faults trigger maintenance work orders. The application layer provides the user interface and digital interface of the digital twin and integrated management and control platform, displaying information such as equipment health, fault crossing status, and suggested maintenance actions to operation and maintenance personnel.

[0094] Accordingly, this application also discloses a garage control device, see [link to relevant documentation]. Figure 10 As shown, the device includes: The data acquisition module 11 is used to collect raw data through sensors and controllers in the garage; the raw data includes physical operation data and task context information. Signal filtering module 12 is used to determine signal filtering conditions based on the task context information, and to filter the physical operation data according to the signal filtering conditions to obtain multi-domain signals; Feature extraction module 13 is used to extract physical state feature vectors and fault tolerance feature vectors from the multi-domain signals, extract task feature vectors from the task context information, and obtain a feature matrix by concatenating all feature vectors. The reasoning module 14 is used to perform reasoning based on the feature matrix to obtain reasoning results; the reasoning results include fault type, severity level, remaining lifetime probability distribution, and fault travel feasibility; the fault travel feasibility characterizes the degree to which the current fault allows the garage to continue to complete the current vehicle storage and retrieval task without complete shutdown; The garage control module 15 is used to determine the current crossing permission conditions based on the task context information, and generate garage control instructions based on the crossing permission conditions and the reasoning results; the garage control instructions include normal operation instructions, waiting condition operation instructions, and stop operation instructions.

[0095] As can be seen from the above, this embodiment uses sensors and controllers to collect physical operation data and task context information in parallel, and makes comprehensive decisions based on multi-source data to improve the accuracy of fault diagnosis and fault crossing decisions. By dynamically determining signal filtering conditions based on task context information and adaptively filtering physical operation data, the quality of signal filtering and feature extraction is improved, thereby improving the accuracy of inference results. By determining crossing permission conditions based on task context information and generating hierarchical control instructions in combination with inference results, the garage can operate with faults under the premise that the fault is tolerable and the task status allows, and continue to complete the current vehicle storage and retrieval task instead of immediately shutting down; this improves the garage's continuous operation capability and enhances the user experience.

[0096] In some specific embodiments, the feature extraction module 13 may specifically include: A physical state feature vector generation unit is used to extract target indicators from the multi-domain signal and obtain physical state feature vectors based on the target indicators; the target indicators include any one or more of peak value, kurtosis, margin, bandwidth energy, modulation sideband ratio, and order features; The task feature vector generation unit is used to obtain the task feature vector based on the task context information and the load rate. The fault-tolerant feature vector generation unit is used to determine the fault trend slope, instantaneous amplitude controllability, and signal energy change rate based on the multi-domain signal to obtain the fault-tolerant feature vector.

[0097] In some specific embodiments, the fault-tolerant feature vector generation unit is specifically used for: acquiring a numerical sequence of a first target feature within a continuous time window; the first target feature is a feature characterizing the health status of the garage; fitting the numerical sequence and using the slope obtained from the fitting as the fault trend slope; the fault trend slope characterizes the trend and speed of fault change; calculating instantaneous amplitude controllability based on the amplitude change rate of the time-domain signal and a preset amplitude change rate threshold; wherein, the instantaneous amplitude controllability characterizes the controllability of the current amplitude change; and calculating the signal energy change rate based on the time-domain signal through a sliding window.

[0098] In some specific embodiments, the signal filtering module 12 is specifically used for: The physical operation data is processed for sensor baseline offset and outlier removal. The filter parameters are dynamically adjusted based on the task context information to reduce the high-frequency suppression intensity during the task startup phase and improve the response capability to non-stationary components during the speed change or emergency stop phase. The processed physical operation data is subjected to multimodal filtering based on the filter parameters; the multimodal filtering includes bandpass filtering, wavelet filtering, and Kalman filtering. The multi-domain signal is determined based on the filtered physical operation data; the multi-domain signal includes time-domain signal, frequency-domain signal, and time-frequency-domain signal.

[0099] In some specific embodiments, the data acquisition module 11 specifically includes: The physical data acquisition unit is used to acquire physical operation data in real time through sensors; the physical operation data includes any one or more of the following: original vibration waveform, original temperature signal, original current waveform, original voltage waveform, rotational speed value, and load value; The task data acquisition unit is used to acquire task context information in real time through the controller; the task context information includes task code, running stage, working mode and operations allowed by the executor.

[0100] In some specific embodiments, the inference module 14 specifically includes: The classification reasoning unit is used to input the feature matrix into the classification model and obtain the fault type and severity level based on the output. The lifetime prediction unit is used to input the feature matrix into the prediction model and obtain the remaining lifetime probability distribution based on the output. The crossing feasibility assessment unit is used to input the feature matrix into the crossing feasibility assessment module and determine the feasibility of crossing the fault by combining the feature threshold and the rule set; The classification reasoning unit, the lifespan prediction unit, and the crossing feasibility assessment unit perform reasoning tasks in parallel.

[0101] In some specific embodiments, the inference module 14 is further configured to: The model parameters of the classification model, the model parameters of the prediction model, and the feature thresholds in the traversal feasibility assessment module are dynamically adjusted based on the task context information.

[0102] In some specific embodiments, the crossing feasibility assessment unit is specifically used for: The second target feature is extracted based on the feature matrix; the second target feature is a feature that characterizes the garage's operating status, including electrical parameters, mechanical parameters, environmental parameters, and communication parameters; The level of violation of each second target feature is determined by comparing each second target feature with its corresponding feature threshold. The out-of-limit level and the fault-tolerant feature vector are input into the rule engine, which performs rule matching based on the rule set and outputs the fault traversal feasibility.

[0103] In some specific embodiments, the garage control module 15 is specifically used for: The current crossing permission conditions are determined based on the task context information, and the crossing permission conditions include allowing crossing or prohibiting crossing; the feasibility of fault crossing includes fully feasible, conditionally feasible, or infeasible. When the crossing permission condition is "crossing is allowed" and the fault crossing feasibility is "fully feasible", a normal operation instruction is generated; When the crossing permission condition is "crossing is allowed" and the fault crossing feasibility condition is "feasible", a condition-pending execution instruction is generated, and the crossing event is recorded. When the crossing permission condition is prohibited or the fault crossing feasibility is not feasible, a stop operation command is generated and a maintenance work order is generated.

[0104] Furthermore, this application also discloses an electronic device, see [link to relevant documentation]. Figure 11 As shown, the content in the figure should not be considered as any limitation on the scope of use of this application.

[0105] Figure 11 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the garage management method disclosed in any of the foregoing embodiments.

[0106] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0107] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon include operating system 221, computer program 222 and data 223 including raw data, etc. The storage method can be temporary storage or permanent storage.

[0108] The operating system 221 manages and controls the various hardware devices on the electronic device 20 and the computer program 222 to enable the processor 21 to perform calculations and processing on the massive amounts of data 223 in the memory 22. The operating system 221 can be Windows Server, Netware, Unix, Linux, etc. In addition to including computer programs capable of performing the garage management method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs capable of performing other specific tasks.

[0109] Furthermore, this application also discloses a computer storage medium storing computer-executable instructions. When the computer-executable instructions are loaded and executed by a processor, they implement the garage management method steps disclosed in any of the foregoing embodiments.

[0110] Furthermore, this application also discloses a computer program product, including a computer program that, when executed by a processor, implements the garage management method steps disclosed in any of the foregoing embodiments.

[0111] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0112] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0113] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0114] The above provides a detailed description of a garage management method, device, equipment, and storage medium provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A garage management method, characterized in that, include: Raw data is collected through sensors and controllers in the garage; the raw data includes physical operation data and task context information. Based on the task context information, the signal filtering conditions are determined, and the physical operation data is filtered according to the signal filtering conditions to obtain a multi-domain signal. Physical state feature vectors and fault tolerance feature vectors are extracted from the multi-domain signals, and task feature vectors are extracted from the task context information. A feature matrix is ​​obtained by concatenating all feature vectors. The reasoning results are obtained by performing reasoning based on the feature matrix; the reasoning results include fault type, severity level, remaining lifetime probability distribution, and fault ride-through feasibility. The fault-crossing feasibility characterizes the extent to which the current fault allows the garage to continue completing the current vehicle storage and retrieval task without a complete shutdown; The current travel permission conditions are determined based on the task context information, and garage control instructions are generated based on the travel permission conditions and the inference results; the garage control instructions include normal operation instructions, waiting condition operation instructions, and stop operation instructions.

2. The garage management method according to claim 1, characterized in that, The step of extracting physical state feature vectors and fault-tolerant feature vectors from the multi-domain signals, and extracting task feature vectors from the task context information, includes: Target indicators are extracted from the multi-domain signal, and physical state feature vectors are obtained based on the target indicators; the target indicators include any one or more of the following: peak value, kurtosis, margin, bandwidth energy, modulation sideband ratio, and order characteristics; Based on the task context information and load rate, the task feature vector is obtained; Based on the multi-domain signal, the fault trend slope, instantaneous amplitude controllability, and signal energy change rate are determined to obtain the fault-tolerant feature vector.

3. The garage management method according to claim 2, characterized in that, The multi-domain signal includes time-domain signal, frequency-domain signal, and time-frequency-domain signal; The determination of fault trend slope, instantaneous amplitude controllability, and signal energy change rate based on the multi-domain signal includes: Obtain the numerical sequence of the first target feature within a continuous time window; the first target feature is a feature characterizing the health status of the garage. The numerical sequence is fitted, and the slope obtained from the fitting is used as the fault trend slope; the fault trend slope characterizes the trend and speed of fault change. The instantaneous amplitude controllability is calculated based on the amplitude change rate of the time-domain signal and a preset amplitude change rate threshold; wherein, the instantaneous amplitude controllability characterizes the degree of controllability of the current amplitude change; The rate of change of signal energy is calculated using a sliding window based on the time-domain signal.

4. The garage management method according to claim 1, characterized in that, The step of determining signal filtering conditions based on the task context information and filtering the physical operation data according to the signal filtering conditions to obtain multi-domain signals includes: The physical operation data is processed for sensor baseline offset and outlier removal. The filter parameters are dynamically adjusted based on the task context information to reduce the high-frequency suppression intensity during the task startup phase and improve the response capability to non-stationary components during the speed change or emergency stop phase. The processed physical operation data is subjected to multimodal filtering based on the filter parameters; the multimodal filtering includes bandpass filtering, wavelet filtering, and Kalman filtering. The multi-domain signal is determined based on the filtered physical operation data; the multi-domain signal includes time-domain signal, frequency-domain signal, and time-frequency-domain signal.

5. The garage management method according to claim 1, characterized in that, The raw data collected through the sensors and controllers in the garage includes: Physical operation data is collected in real time by sensors; the physical operation data includes any one or more of the following: original vibration waveform, original temperature signal, original current waveform, original voltage waveform, rotational speed value, and load value. The controller collects task context information in real time; the task context information includes task code, running stage, working mode, and operations allowed by the executor.

6. The garage management method according to claim 1, characterized in that, The reasoning based on the feature matrix to obtain the reasoning result includes: Based on the feature matrix, the first inference task, the second inference task, and the third inference task are executed in parallel to obtain the inference result; The first reasoning task includes inputting the feature matrix into the fault diagnosis model and obtaining the fault type and severity level based on the output. The second inference task includes inputting the feature matrix into the prediction model and obtaining the remaining lifetime probability distribution based on the output; The third reasoning task includes inputting the feature matrix into the crossing feasibility assessment module and determining the feasibility of crossing the fault by combining the feature threshold and the rule set.

7. The garage management method according to claim 6, characterized in that, Also includes: The model parameters of the fault diagnosis model and the prediction model, as well as the feature thresholds in the crossing feasibility assessment module, are dynamically adjusted based on the task context information.

8. The garage management method according to claim 6, characterized in that, The method of determining fault traversal feasibility by combining feature thresholds and rule sets includes: The second target feature is extracted based on the feature matrix; the second target feature is a feature that characterizes the garage's operating status, including electrical parameters, mechanical parameters, environmental parameters, and communication parameters; The level of violation of each second target feature is determined by comparing each second target feature with its corresponding feature threshold. The out-of-limit level and the fault-tolerant feature vector are input into the rule engine, which performs rule matching based on the rule set and outputs the fault traversal feasibility.

9. The garage management method according to any one of claims 1 to 8, characterized in that, The step of generating garage control instructions based on the crossing permission conditions and the reasoning result includes: The current crossing permission conditions are determined based on the task context information, and the crossing permission conditions include allowing crossing or prohibiting crossing; the feasibility of fault crossing includes fully feasible, conditionally feasible, or infeasible. When the crossing permission condition is "crossing is allowed" and the fault crossing feasibility is "fully feasible", a normal operation instruction is generated; When the crossing permission condition is "crossing is allowed" and the fault crossing feasibility condition is "feasible", a condition-pending execution instruction is generated, and the crossing event is recorded. When the crossing permission condition is prohibited or the fault crossing feasibility is not feasible, a stop operation command is generated and a maintenance work order is generated.

10. A garage control device, characterized in that, include: The data acquisition module is used to collect raw data through sensors and controllers in the garage; the raw data includes physical operation data and task context information. The signal filtering module is used to determine the signal filtering conditions based on the task context information, and to filter the physical operation data according to the signal filtering conditions to obtain multi-domain signals. The feature extraction module is used to extract physical state feature vectors and fault tolerance feature vectors from the multi-domain signals, extract task feature vectors from the task context information, and obtain a feature matrix by concatenating all feature vectors. The inference module is used to perform inference based on the feature matrix to obtain inference results; the inference results include fault type, severity level, remaining lifetime probability distribution, and fault ride-through feasibility. The fault-crossing feasibility characterizes the extent to which the current fault allows the garage to continue completing the current vehicle storage and retrieval task without a complete shutdown; The garage control module is used to determine the current crossing permission conditions based on the task context information, and generate garage control instructions based on the crossing permission conditions and the inference results; the garage control instructions include normal operation instructions, waiting condition operation instructions, and stop operation instructions.

11. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the garage management method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, Used to store computer programs; wherein the computer programs, when executed by a processor, implement the garage management method as described in any one of claims 1 to 9.

Images