Research on Edge Feature Extraction Methods for Device Monitoring Based on Cloud–Edge Collaboration

Abstract

Enterprises in industries such as coking and metallurgy possess extensive industrial equipment requiring real-time monitoring and timely fault detection. Transmitting all monitoring data to servers or cloud platforms for processing presents challenges, including substantial data volumes, high latency, and significant bandwidth consumption, thereby compromising the monitoring system’s real-time performance and stability. This paper proposes a cloud–edge collaborative approach for edge feature extraction in equipment monitoring. A three-tier collaborative architecture is established: “edge pre-processing-cloud optimization-edge iteration”. At the edge, lightweight time-domain and frequency-domain feature extraction modules are employed based on equipment structure and failure mechanisms to rapidly pre-process and extract features from monitoring data (e.g., equipment vibration), substantially reducing uploaded data volume. The cloud node constructs a diagnostic feature library through threshold self-learning and data-driven model training, then disseminates optimized feature extraction parameters to the edge node via this threshold learning mechanism. The edge node dynamically iterates its feature extraction capabilities based on updated parameters, enhancing the capture accuracy of critical fault features under complex operating conditions. Verification and demonstration applications were conducted using an enterprise’s online equipment monitoring system as the experimental scenario. The results indicate that the proposed method reduces data transmission volume by 98.21% and required bandwidth by 98.25% compared to pure cloud-based solutions, while effectively enhancing the monitoring system’s real-time performance. This approach significantly improves equipment monitoring responsiveness, reduces demands on network bandwidth and data transmission, and provides an effective technical solution for equipment health management within industrial IoT environments.

1. Introduction

Industries such as coking and metallurgy heavily rely on rotating equipment, including pumps, fans, and compressors [1,2]. These devices operate continuously under harsh conditions of high temperature, pressure, and dust, performing core functions of medium conveyance and energy conversion [2]. Failures such as bearing wear or impeller corrosion can not only halt entire production lines for hours, incurring direct losses of hundreds of thousands of yuan, but also potentially trigger major safety incidents like medium leakage or explosions. Consequently, implementing condition monitoring and health management (PHM) for rotating equipment to achieve early fault warning and precise diagnostics is crucial for ensuring safe production and reducing operational costs. Current mainstream PHM systems employ a centralized “edge collection-cloud processing” architecture: the edge node merely collects monitoring data such as vibration and temperature, with all data requiring real-time transmission to the cloud for processing [3,4]. This model exhibits significant shortcomings in scenarios involving massive equipment monitoring: a single piece of equipment generates over 1 GB of vibration data per hour, and clusters of thousands consume substantial bandwidth, failing to meet the “second-level response” real-time requirement. Concurrently, centralized cloud computing consumes vast server processing and storage resources, with redundant data causing waste and compromising monitoring system stability. How to resolve the issues of large data transmission volumes and poor real-time performance while maintaining monitoring accuracy has become a core challenge requiring urgent breakthroughs in this field [4,5].

Edge feature extraction relocates data processing closer to the equipment [6]. After performing data preprocessing and key feature selection at the edge, only the extracted fault-sensitive features (rather than the full raw data) are uploaded to the cloud. This approach reduces bandwidth demands for data transmission while enhancing real-time performance monitoring. In recent years, researchers globally have conducted extensive studies on edge feature extraction: at the algorithmic level, methods based on time-domain statistics (such as root mean square and peak factor) and lightweight frequency-domain analysis (such as simplified wavelet packet transform algorithms) have been proposed to adapt to the limited computational power at the edge; at the application level, it has been successfully applied to equipment monitoring in industries such as wind power and automotive. However, the metallurgical and chemical industries present unique challenges: on one hand, complex on-site operating conditions render monitoring equipment vulnerable to damage and management deficiencies; on the other, most existing research implements unidirectional data exchange (“edge extraction-cloud diagnosis”), lacking dynamic cloud-based optimization mechanisms for edge feature extraction parameters, thereby struggling to adapt to fluctuating equipment conditions [6,7].

Addressing these industry pain points and existing technical limitations in monitoring dynamic equipment for metallurgy and chemical plants, this paper investigates edge feature extraction methods based on cloud–edge collaboration [8]. Firstly, a three-tier cloud–edge collaborative architecture is designed, employing an “edge pre-processing–cloud optimization–edge iteration” structure to define functional boundaries between edge and cloud components. Secondly, feature extraction modules and supporting functionalities suitable for the edge are designed. Subsequently, a cloud-based threshold self-learning mechanism and data-driven fault diagnosis model are developed. Leveraging historical and real-time monitoring data, a multidimensional intelligent equipment fault alert system is constructed [9]. Through the dissemination of optimized parameters, iterative updates to edge feature extraction capabilities are achieved. Finally, taking pump equipment on an ethanol production line at a coking enterprise as the research subject, a cloud–edge collaborative monitoring system was established. Analysis and validation were conducted on metrics including data transmission volume, feature extraction time consumption, and fault diagnosis accuracy [10].

2. Design of Edge-Cloud Collaborative Structure for Monitoring System

The overall topology, as illustrated in Figure 1, adopts a cloud–edge collaborative architecture following the sequence: “edge pre-processing → cloud-based optimization → edge iterative upgrading”. Through the coordinated interaction of three functional layers, this approach enhances the real-time performance and accuracy of monitoring complex metallurgical and chemical industrial equipment [10].

For rotating equipment such as pump clusters, compressors, and fans in coking plants, data acquisition is achieved by installing sensors and deploying data collection devices alongside the equipment. Firstly, real-time data such as equipment vibration and temperature is collected, while the system simultaneously assesses sensor connectivity status and equipment start/stop status to filter out invalid data. Secondly, an edge computing module is designed based on equipment characteristics and rule systems, incorporating waveform and spectral analysis methods to extract fault-sensitive features. Finally, local alerts are triggered in real time, with feature data and raw waveforms transmitted to cloud servers via the Message Queuing Telemetry Transport (MQTT) protocol. The feature indicators, judgment rules, and thresholds used for alerts support remote configuration via the server [7].

On the cloud server side, the system first receives and stores data transmitted from the edge. It then visualizes monitoring data, health assessments, diagnostic outcomes, and predictive trends [4]. For data alerts and fault diagnosis, a multi-dimensional intelligent alarm and diagnostic system is constructed based on historical operational data and real-time monitoring. Simultaneously, by disseminating optimized parameters (including feature extraction thresholds and diagnostic rules) to the edge, iterative updates to edge-side feature extraction capabilities are achieved. This ultimately enhances the timeliness of Equipment monitoring alerts and the accuracy of fault diagnosis, providing data support for coking enterprises in formulating management decisions and scheduling maintenance plans for rotating equipment [9,10,11,12].

3. Edge Feature Extraction and Data Transmission

3.1. Principles and Methods for Equipment Status Feature Assessment

Regarding feature extraction, the collected dynamic vibration data of equipment can be observed and analyzed from both time-domain and frequency-domain perspectives, as illustrated in Figure 2 [12,13,14]. The vibration responses of different equipment components form unique signatures within the measured signals. By extracting features from time-domain waveforms (such as peak values, kurtosis, root mean square values, etc.) and frequency-domain spectra (such as characteristic frequencies, narrowband energy distribution), a quantitative description of the equipment’s state can be achieved. Given that data loggers typically employ ARM processors with constrained computational and storage resources, an embedded algorithm package is constructed using a configurable approach. This enables real-time acquisition and extraction of key features, meeting the timeliness requirements for rapid equipment condition assessment [13,14].

For device self-diagnosis, the collector interfaces with vibration sensors via IEPE connections and with process measurement data through 4–20 mA electrical interfaces. It utilizes sensor parameters such as bias voltage and signal range to detect short-circuit or open-circuit faults, thereby performing sensor self-checks. Furthermore, the data collector transmits information to servers via RJ45, Wi-Fi, or 5G communication interfaces. It performs real-time detection and verification of communication handshake signals and data frame integrity, enabling the monitoring system’s real-time self-diagnosis. This capability not only confirms normal system operation but also rapidly identifies anomalies caused by sensor disconnection, collector module failures, or poor contacts. Consequently, it significantly enhances installation and commissioning efficiency while simplifying subsequent operational maintenance.

Feature values and raw waveform data are transmitted to the backend server via the MQTT protocol, utilizing two independent interface protocols. The threshold criteria for feature value alarms are initially set according to enterprise or national standards. As data accumulates, the backend server can perform learning optimization, with the refined results downloaded to data collectors for iterative improvement. Where adjustments involve parameter tweaks only, these can be implemented via remote configuration deployment. Algorithm upgrades, however, are achieved through OTA (Over-the-Air) updates, enabling dynamic refreshes of edge computing logic.

3.2. Edge Feature Computation

Feature value computation and judgment are rule-based. Vibration alarm methods, as illustrated in Figure 3, comprise three categories: threshold alarms, mechanism-based alarms, and statistical indicator-based alarms. Threshold alarms may employ absolute or relative standards: absolute standards reference international, national, industry, or enterprise standards; relative standards utilize baseline vibration values during normal equipment operation, with alarm thresholds determined through data learning against baseline data.

Alarms based on diagnostic mechanisms can be implemented by setting narrowband ranges, specific frequency bands, envelope values, or dimensionless statistics according to the structural characteristics and kinematic features of the equipment. Alarms based on statistical indicators can be configured by establishing alarm values according to statistical patterns and data change rate characteristics.

The various methods of vibration alarms and their applicable scenarios are shown in

Table 1. Applicable Scope of Each Alarm Method.

Alarm Method Type	Applicable Scope
Threshold Alarms	Vibration full-frequency amplitude alarms and process value alarms are widely applied in industrial equipment condition monitoring scenarios.
Narrowband Alarms	Precision alarms are designed for specific fault characteristic frequencies, exhibiting heightened sensitivity to signals with clearly identified fault occurrence frequencies.
Band-width Alarms	An amplitude alarm for a specific frequency band in the vibration frequency domain, sensitive to characteristic signals with known fault occurrence frequencies
Envelope value alarm	An amplitude alarm for specific frequency bands within the vibration frequency domain after envelope detection processing, particularly suitable for early warning scenarios in bearing and gear faults.
Dimensionless alarms	Alarms designed based on dimensionless amplitude domain parameters, highly suitable for early warning scenarios of bearing and gear failures.
Three-sigma alarm	Statistical analysis of vibration characteristic values within a specified time window calculates the mean and variance, defining the normal vibration range as “mean ± 3σ”. Abnormal vibrations are identified by detecting measurement signals exceeding this range, thereby providing early warning of potential equipment faults.
Rate-of-Change Alarm	The rate of change is calculated by determining the magnitude of variation in vibration parameters over a defined time period. When this rate of change exceeds a pre-set “normal change rate threshold”, the system triggers an anomaly alarm.

.

From a computational perspective, the threshold indicators required for threshold-based alarms and those based on diagnostic mechanisms can be computed directly at the edge. Conversely, statistical metrics and rate-of-change indicators necessitate calculation and configuration within server software based on data trends and statistical patterns.

Within the edge collector, pre-processing and edge computing are required based on edge feature identification needs. Offloading certain computational tasks from the host computer or cloud server to the collector effectively reduces data transmission volume, lowers latency, enhances system response speed, and enables localized data processing.

The edge computing functions undertaken by the collector primarily encompass the following:

(1) Process signals (e.g., temperature, pressure, rotational speed): Corresponding physical quantities must be calculated internally within the collector based on sensor principles and sensitivity before transmission (e.g., Pt100 temperature values in degrees Celsius);

(2) For vibration signals, the collector possesses multiple edge processing capabilities, including integration, filtering, and signal extraction. It also calculates the following parameters internally:

(a) Vibration full-band amplitude (peak acceleration, root mean square velocity, peak-to-peak displacement) and rotational speed measurements;

(b) Vibration 1X and 2X amplitude and phase;

(3) Equipment start/stop status determination;

(4) Acceleration envelope value (applicable to acceleration sensors for bearing monitoring);

(5) Kurtosis indices (applicable to acceleration sensors for bearing and gearbox monitoring), etc.

The envelope and kurtosis computations are implemented via resource-optimized algorithms suitable for the collector’s embedded processor. The acceleration envelope is obtained by band-pass filtering followed by absolute-value demodulation and low-pass smoothing, significantly reducing computational load compared to full-band Hilbert transforms. Kurtosis is calculated using an online sliding-window method that updates statistical moments incrementally, avoiding large data storage and enabling real-time execution under memory constraints.

3.3. Edge Data Transmission

3.3.1. Transmission Format and Content

Data transmission between edge devices and cloud servers employs the MQTT protocol; message content is encapsulated in JavaScript Object Notation (JSON) format.

The transmission protocol encompasses the content illustrated in Figure 4, primarily including: the dispatch and upload of device (data collector, sensor) information; the dispatch and upload of network parameters; the dispatch and upload of data collection and transmission parameter settings; the upload of monitoring data from data collectors (monitoring feature values derived from edge computing); the upload of dynamic waveform data from data collectors; the upload of self-test anomaly information from data collectors; network time synchronization interfaces; device version information queries; programmer version checks and OTA upgrades, etc.

3.3.2. Transmission Scheduling Strategy

To reduce transmission load, enhance real-time performance, and lower demands on network bandwidth and server resources for the monitoring system, the edge collector intelligently switches data transmission strategies based on device operational status: When the collector determines stable device operation, it uploads only vibration characteristic values (e.g., peak, kurtosis, rms values); Upon detecting abnormal vibrations, it automatically triggers the upload of complete dynamic waveforms. This tiered transmission mechanism ensures both the accuracy of data analysis and fault diagnosis while significantly reducing data volume, thereby effectively enhancing the system’s real-time responsiveness. The specific transmission scheduling method is as follows [7]:

(1) The data collector continuously acquires dynamic data and processes data. Data uploads are categorized into feature data and dynamic waveform data, executed according to preset time intervals and transmission strategies. Feature values refer to monitored process data (e.g., temperature readings) or dynamic signal characteristics (e.g., vibration common-mode values); dynamic waveform data denotes complete dynamic waveforms (e.g., vibration waveforms) used for feature extraction.

(2) The characteristic data upload process is as follows: The data collector continuously acquires data and extracts characteristics. At a set time interval t (e.g., t = 5 s), it uploads characteristic data, time stamps, and equipment start/stop status to support condition monitoring and trend analysis.

(3) The dynamic waveform data upload process is as follows: The data collector continuously acquires data and uploads dynamic waveform data, corresponding characteristic data, time stamps, and equipment start/stop status at a set time interval T (e.g., T = 30 min). This facilitates further analysis and diagnostics of dynamic waveforms by the server software [2].

(4) Vibration integration functionality may be implemented within the data collector. Should the system require this capability, vibration integration calculations can be performed via the collector.

(5) The acquisition system compares characteristic values against alarm thresholds in real time:

Upon the initial alarm trigger, it immediately transmits the characteristic data, alongside the dynamic waveform data of the current alarm moment and the preceding three sets of waveform data with their corresponding characteristic values.

If the alarm persists (i.e., the common-frequency value remains above the alarm threshold), the system does not completely suspend waveform transmission but implements a dual-trigger mechanism:

① If the variation in the vibration common-frequency value exceeds the preset fluctuation threshold (Δθ, e.g., 15% of the alarm threshold), the edge node immediately triggers a new round of waveform upload to capture dynamic changes in abnormal states.

② If the common-frequency value remains stable (variation < Δθ), the system uploads the accumulated waveform data according to the scheduled time interval (T) to avoid data loss.

If the alarm escalates to the secondary (danger) level and persists, the system first uploads the dynamic waveforms corresponding to the first three sets of characteristic values that reach the danger threshold. During the danger state, the aforementioned dual-trigger mechanism remains effective to ensure targeted data transmission without meaningless continuous uploads [9].

(6) When uploading vibration signal waveforms, the uploaded waveforms shall include both raw waveforms and physical quantity waveforms generated according to configuration requests (e.g., for an accelerometer configured to request velocity signals, the uploaded waveforms shall comprise the raw acceleration waveform and the integrated velocity waveform).

(7) If the time interval T is set to exceed one day, and long-term monitoring data remains below the alarm threshold, the system shall upload a set of waveform data, characteristic values, timestamps, and equipment start/stop status information under normal conditions at a fixed daily time (e.g., 12:00) for comparative analysis.

(8) The acquisition and transmission mechanism for start-up/shutdown data is as follows: The collector hardware performs continuous acquisition. In addition to the aforementioned time-based change mode for data storage and reporting, start-up/shutdown scenarios require setting thresholds for rotational speed change and amplitude change to ensure accurate upload of waveform data during these processes.

(9) The basis for triggering waveform upload is the numerical state of the vibration common-frequency value (acceleration corresponds to peak value, velocity corresponds to root mean square value, and displacement corresponds to peak-to-peak value). This numerical state serves two core functions:

It is the trigger condition for the initial alarm and the corresponding waveform upload;

During persistent alarms, if the variation in the common-frequency value exceeds the preset fluctuation threshold (Δθ), it will also trigger an immediate waveform upload, ensuring that dynamic changes in abnormal characteristics are not missed [9].

(10) When the data collector simultaneously acquires electrical and vibration signals, the timing and cycle for uploading current waveforms shall align with those of the vibration signals (following the same dual-trigger mechanism and time interval rules). If the collector acquires only electrical signals, the magnitude of the current Root Mean Square(RMS) value shall serve as the upload trigger basis, referring to the threshold comparison and variation judgment logic of the vibration common-frequency value [4].

3.4. Model Optimization and Parameter Distribution

The data collector features edge-cloud collaboration capabilities, enabling server registration, device management, and remote configuration. It supports data and resource coordination between the edge and central cloud. The edge handles key metric computation and upload, while the server manages visualization, big data storage, learning, and modeling tasks. Optimized models, configuration parameters, alarm thresholds, and newly developed feature extraction algorithms can be deployed via remote configuration or OTA updates to enhance device performance. To bolster edge device reliability and security, new algorithms and OTA update optimizations require approval before implementation [11,14].

4. Application and Validation

4.1. Project Overview

To validate the usability and performance of the designed edge-cloud collaborative monitoring system, a demonstration application was conducted on an ethanol production line at a coking enterprise. This aimed to verify the system’s capabilities in performance enhancement and vibration fault diagnosis compared to traditional systems without edge computing [15,16].

4.2. Comparative Analysis of Data Transmission Before and After Implementing Edge Computing

Within the coking critical equipment online monitoring system, edge computing and cloud–edge collaboration technology achieve efficient data processing and response by rationally distributing data processing tasks between edge devices and cloud servers. This simultaneously reduces demands on network bandwidth and storage resources. Taking the demonstration project as an example, which incorporates 200 ethanol pump devices, each equipped with six vibration accelerometers, the following analysis and calculations are based on this configuration [16,17].

4.2.1. Without Edge Computing

Without edge computing, the system operates on a 30 s monitoring cycle with the following sampling and transmission pattern: each measurement point transmits one set of waveform data to the server every 30 s. Each waveform data set comprises 8192 points, with each data point occupying 4 bytes. Consequently, the data volume transmitted per vibration channel per transmission is 32 kB.

The system incorporates 200 devices, each equipped with 6 vibration measurement points. Without edge computing, the data transmission volume per 30 min is calculated as follows:

32 kB × 200 (devices) × 6 (measurement points/device) × 60 (transmissions/30 min) = 2,304,000 kB = 2.197 GB.

This equates to 2.197 GB of data requiring transmission to the server for storage every 30 min.

As the system employs binary transmission, the effective data transmission constitutes approximately 50% of the total transmission volume. Therefore, the actual total data transmission volume is approximately 2,304,000 kB × 2 = 4,608,000 kB.

The required theoretical average network bandwidth is calculated as follows:

4,608,000 kB × 8 (bits/kB) ÷ 30 (min) ÷ 60 (seconds/min) = 20,480 kbps = 20.48 Mbps.

4.2.2. When Utilizing Edge Computing

When employing edge computing, the system monitoring cycle is 3 s, with waveform upload cycles occurring every 30 min. The sampling and transmission mode operates as follows: each measurement point uploads characteristic values once every 3 s for equipment status monitoring and trend analysis; a set of waveform data (8192 points in length) is uploaded every 30 min for dynamic signal analysis and fault diagnosis.

The system connects 200 devices, each configured with 6 vibration measurement points. The transmission data volume per 30 min interval after implementing edge computing is calculated as follows:

32 kB × 200 (units) × 6 (measurement points/unit) + [4 kB (feature value size) × 20 (feature values/min) × 30 (min) × 200 (units) × 6 (measurement points/unit)] ÷ 1024 = 38,400 kB + 2812.5 kB = 41,212.5 kB = 40.248 MB.

That is, every 30 min requires the transmission of 40.248 MB of data to the server for storage.

As the system employs binary transmission, collected data constitutes only approximately 50% of the total transmitted data volume. Therefore, the actual total data transmission volume is 41,212.5 kB × 2 = 82,425 kB.

The required theoretical average network bandwidth is calculated as follows:

82,425 kB × 8 (bits/kB) ÷ 30 (min) ÷ 60 (seconds/min) ≈ 366.33 kbps ≈ 0.358 Mbps.

4.2.3. Comparative Analysis

As shown in

Table 2. Comparison of Monitoring System Metrics Before and After Implementing Edge Computing.

Monitoring Scope	Data Type	Without Edge Computing	With Edge Computing	Post-Implementation Data Reduction
200 devices	Data volume (kB)	4,608,000	82,425	98.21%
	Transmission bandwidth (Kbps)	20.48	0.358	98.25%
	Monitoring interval (s)	30	3	90%

, the monitoring system connects to 200 units. The transmission data volume, required network bandwidth, and trend data sampling intervals per 30 min before and after implementing edge computing are detailed below. Following the adoption of edge computing and edge-cloud collaboration technology, data transmission and storage volume decreased by 98.21%, with average network bandwidth requirements reduced by 98.25%. The trend data sampling interval for the monitoring system was reduced from 30 s to 3 s. Although the frequency of waveform data transmission decreased, the system’s real-time capability significantly improved, enabling the edge to promptly detect potential hazards. Furthermore, when equipment anomalies occur, the system automatically uploads raw waveform data for diagnostic analysis, ensuring no impact on fault determination [18].

4.3. Fault Diagnosis Analysis

During the demonstration application phase, the research team selected the reflux pump unit of an ethanol dehydrogenation tower at a coking enterprise as the validation subject. On-site testing and fault diagnosis verification were conducted for the proposed “cloud–edge collaborative” equipment monitoring system. The equipment is fitted with piezoelectric IEPE accelerometers (sensitivity 100 mV/g), operating at a sampling frequency of 5120 Hz with a sampling length of 4096 points. In Figure 5, the markers correspond to the sensor mounting positions: 1 = motor non-drive end; 2 = motor drive end; 4 = pump drive end; 5 = pump non-drive end (the accelerometers are arranged at these positions to collect vibration signals of key components). Figure 5 illustrates the overall structural layout of the unit and sensor placement positions [19,20].

During equipment operational monitoring, the system continuously acquires and analyzes vertical vibration signals from the motor-end bearing housing. Monitoring results indicate that the effective value of vertical vibration velocity at this location progressively increased from 0.48 mm/s to 2.82 mm/s, exceeding the preset secondary alarm threshold. The system automatically triggered an alarm and reported relevant dynamic waveform data (see Figure 6). The significant increase in vibration amplitude indicates an abnormal operating condition of the equipment [4,21].

Figure 7 presents the vibration waveform and spectrum during the fault. The time-domain waveform exhibits distinct periodic impact characteristics, while the spectrum reveals characteristic frequency components associated with rolling element defects in the bearing. Spectral analysis identified frequency components at 248.75 Hz and 99.33 Hz, corresponding, respectively, to the outer ring fault frequency and rolling element fault frequency. Both align closely with the theoretical characteristic frequencies for this bearing type. This indicates potential mechanical damage to the outer ring—such as wear, spalling, or cracking—alongside unstable rolling element operation [1,12,22].

Figure 8 presents the long-term trend curve of vibration amplitude. Prior to failure, vibration levels exhibited a gradual upward trajectory, with the rate of increase significantly accelerating as the alarm threshold was approached. This trend reflects the progressive deterioration of the equipment’s operational condition and validates the effectiveness of the designed edge-based intelligent feature extraction and multi-dimensional alarm strategy for real-time health assessment [1,2,6,23].

Following equipment maintenance (see Figure 9 and Figure 10), the vibration waveform stabilized. The outer ring fault characteristic frequency and its harmonics in the spectrum disappeared entirely, indicating the fault source had been eliminated and the equipment restored to normal operation. On-site disassembly revealed pronounced wear marks and cracks on the bearing outer ring, closely matching the system diagnosis. This validated the diagnostic accuracy and real-time responsiveness of the cloud–edge collaborative monitoring system [2,24,25].

Combining vibration data analysis with the equipment’s structural characteristics, the following faults were diagnosed: Failure of the rolling bearing outer ring (see Figure 11): Spectral analysis revealed a distinct outer ring failure frequency (248.75 Hz) and its harmonic components within the vibration signal [19]. This frequency closely matched the bearing’s theoretical failure frequency, indicating severe wear or cracks in the outer ring. Concurrently, a significant increase in the shock index within the vibration signal signaled deteriorating lubrication conditions, potentially leading to dry friction between bearing components. Furthermore, a distinct rolling element fault frequency (99.33 Hz) was present in the vibration signal, indicating potential misalignment in the bearing assembly. This misalignment causes abnormal rolling element trajectories [9,26,27].

The edge collector monitors equipment vibration signals in real time, calculating characteristic parameters such as vibration amplitude, kurtosis indices, and impact indices via its built-in feature extraction algorithm [24]. When vertical vibration amplitude exceeds the preset threshold (2.0 mm/s), the system triggers a secondary alarm and uploads the first three sets of waveform data recorded at the time of fault occurrence to the cloud. Upon receiving the alert, the cloud server conducts further analysis of the uploaded dynamic waveform data to confirm the fault type and generate a diagnostic report [22]. The findings indicate a severe outer ring failure in the rolling bearing, recommending immediate shutdown for maintenance. Following the system’s diagnosis, the enterprise halted the equipment for inspection. Disassembly revealed pronounced wear marks and cracks on the bearing outer ring, closely matching the diagnostic conclusions [6,19,22].

5. Conclusions

This research addresses challenges in coking enterprises’ online monitoring systems—including substantial data transmission volumes, high latency, and significant bandwidth consumption—through the design and application of edge computing and edge-cloud collaboration technologies. By leveraging edge feature extraction and cloud–edge coordination mechanisms, this approach enhances the accuracy of capturing critical fault characteristics under complex operating conditions. Verification and demonstration applications were conducted using an enterprise’s online equipment monitoring scenario. The results indicate that edge computing reduced data transmission volume by 98.21% and required bandwidth by 98.25%, while effectively enhancing the monitoring system’s real-time performance and enabling accurate equipment fault diagnosis. This approach significantly improves equipment monitoring real-time capability, reduces network bandwidth and data transmission requirements, and provides effective technical support for equipment health management within industrial IoT environments. Additionally, the framework’s stability under long-term continuous operation in harsh industrial environments (e.g., high temperature, electromagnetic interference) requires further validation to strengthen its practical applicability. A current limitation lies in the focus on single-industry equipment; the framework’s adaptability to heterogeneous devices across metallurgy and chemical industries requires further validation. Future work will optimize the lightweight feature extraction algorithm for edge nodes with extreme resource constraints and integrate multi-source sensor data fusion to improve fault diagnosis robustness.