Federated Learning for Overhead Crane Predictive Maintenance
Federated Learning for Overhead Crane Predictive Maintenance
Three steel plants (Plants A/B/C, 50 overhead cranes each) cannot pool their vibration data on a single server for training due to data compliance and process confidentiality requirements. The federated learning approach: each plant trains an LSTM prediction model on its local GPU server, uploading only 512KB of model weights per round to the central server, which performs FedAvg aggregation and sends back updates. Convergence is reached after 100 communication rounds, with a global model F1 score of 0.91—close to the centralized training F1 of 0.93 (a gap of only 2%). In contrast, a single plant training independently without federated learning (using only its 50 cranes' data) achieves an F1 of 0.85. Federated learning raises the F1 score from 0.85 to 0.91 while preserving data privacy.
Predictive maintenance models for overhead cranes rely on extensive training data covering diverse operating conditions and failure modes. In practice, however, a single crane user (plant) typically operates only 20–80 overhead cranes—insufficient data to train a high-accuracy LSTM RUL prediction model (single-plant F1 ≈ 0.85). While pooling data from multiple plants for centralized training improves accuracy (F1 = 0.93), it raises compliance concerns under China's Data Security Law and Personal Information Protection Law, along with confidentiality requirements around plant production processes. Federated Learning (FL) enables collaborative multi-plant training through a "data stays put, model moves" approach. Test environment: PyTorch 2.1.0 + Flower 1.7.0 framework, 3 clients each with 1×RTX 4090, and 1 central server on CPU.
How Federated Learning Works
The FedAvg (Federated Averaging) algorithm is used: in round t, ① the central server distributes the global model W_t to the 3 clients; ② each client trains locally for E=5 epochs (Batch=64, lr=0.001, SGD optimizer) and computes the update ΔW_i; ③ clients upload ΔW_i (weight increments only, 512KB per round) to the central server; ④ the server computes W_{t+1}=W_t+∑(n_i/N)·ΔW_i (where n_i is the data volume of client i and N is the total data volume); ⑤ this repeats for T=100 rounds. Each communication round takes approximately 2 seconds (including network transfer and local training), bringing the total for 100 rounds to about 8 minutes.
Accuracy Comparison
| Solution | Data Scale | F1 Score | MAPE | Data Egress Permission | Transmission Volume |
|---|---|---|---|---|---|
| Single-Plant Standalone(Plant A) 50Units×24Months | 0.85 | 18.2% | No | 0 | |
| Centralized(Three-Plant Aggregation) 150Units×24Months | 0.93 | 14.3% | Yes(Full Dataset) | TB-Level | |
| Federated Learning(Three-Plant FL) 150Units×24Months | 0.91 | 15.1% | No(Weights-Only) | ~50MB | |
| Federated Learning(Non-IID+Enhanced) 150Units×24Months | 0.92 | 14.8% | No(Weights-Only) | ~50MB |
Federated learning achieved an F1 score of 0.91 versus 0.93 for centralized training—a gap of only 2%. By applying a non-IID optimization strategy (adding a proximal term to the local loss function when factory data distributions differ, following the FedProx algorithm), the F1 score improved to 0.92. In contrast, single-factory independent training yielded an F1 of 0.85, meaning federated learning delivered a 0.06 (6 percentage point) improvement—approaching centralized accuracy while preserving data privacy.
Overcoming Non-IID Data Challenges in Federated Learning
The core challenge in federated learning is non-IID (non-independent and identically distributed) data—each plant's overhead crane models, operating conditions, and fault patterns differ (Plant A: bearing degradation in hot-rolling workshops; Plant B: gear pitting in cold-rolling workshops; Plant C: high-temperature faults in casting workshops). Standard FedAvg converges slowly under non-IID conditions (150 rounds vs. 80 rounds for IID) and the global model's F1 drops from 0.91 to 0.87. Our solution: ① Local fine-tuning—after the global model is distributed, each client trains locally for 5 additional epochs to adapt to distribution shifts; ② Data augmentation—clients share statistical feature distributions (not raw data) to align feature spaces. With these measures, the F1 score in non-IID scenarios recovered to 0.90.
Communication Efficiency Optimization for Industrial Deployment
Communication overhead is the primary bottleneck for real-world federated learning deployment. While transmission volume drops from terabytes (centralized) to 50MB in FL (100 rounds × 512KB), optimization is still required on bandwidth-constrained industrial sites (4G public networks with roughly 10Mbps uplink). Measured results from four optimization strategies:
| Optimization Strategy | Communication Overhead/Round | F1Score | F1Loss | Application Scenarios |
|---|---|---|---|---|
| Baseline(FP32Full Gradient) | 512KB | 0.910 | Baseline | Favorable Network Conditions(Industrial Private Network) |
| Top-k Sparsification(k=10%) | 51KB | 0.907 | -0.003 | Limited Bandwidth(4G/5GPublic Network) |
| INT8Quantization | 128KB | 0.909 | -0.001 | Constrained but Acceptable Bandwidth FP16 |
| Local Epoch=10(60Round) | 512KB | 0.902 | -0.008 | High Network Latency(Cross-Province) |
| Fed Async Asynchronous Aggregation | 512KB | 0.884 | -0.026 | Client Heterogeneity(Frequent Disconnection) |
Recommended configuration: INT8 quantization (128 KB/round, F1 loss 0.1%) combined with local Epoch = 10 (60 rounds, F1 loss 0.8%). This cuts communication overhead to 25% of the baseline while maintaining an overall F1 score of 0.90.
Differential Privacy for Gradient Protection
Even when only model gradients are transmitted rather than raw data, there remains a risk of gradient leakage attacks (Deep Leakage from Gradients, Zhu et al., 2019). Differential privacy (DP) mitigates this by injecting Gaussian noise into the gradients: perturbed_grad = clip(grad, C) + N(0, sigma^2 * C^2 * I). In this experiment, we set the gradient clip threshold C = 1.0 and noise standard deviation sigma = 0.01, corresponding to a privacy budget of epsilon = 8 (referencing GB/T 35273-2020, where epsilon ≤ 10 is considered acceptable). DP-SGD reduces the F1 score from 0.91 to 0.89 (a 2% drop) in exchange for provable privacy guarantees.
Real-World Deployment Validation
A federated learning project for overhead crane predictive maintenance was deployed across three subsidiaries (Plants A, B, and C) of a major steel group (Project No. KL-FL-2024-001, running from March 2025 to March 2026). Each plant equipped 50 overhead cranes with PCB 352C33 sensors, KL-EDGE-200 gateways, and LSTM models. After federated learning went live: Plant A's RUL prediction F1 improved from 0.83 (single-plant) to 0.90 (+7 pp), Plant B from 0.87 to 0.91 (+4 pp), and Plant C (where high-temperature casting faults are rare) from 0.79 to 0.88 (+9 pp). Plant C saw the most significant gain, leveraging bearing and gear degradation data from Plants A and B to supplement its sparse high-temperature fault patterns. For reference, centralized training (assuming data could be pooled) achieves an F1 of 0.93 — meaning federated learning sacrifices only 2% accuracy in exchange for full data compliance without leaving the plant premises.
Federated vs. Centralized vs. Single-Plant: Full Comparison
| Comparison Parameter | Single-Plant Standalone | Centralized Training | Federated Learning Fed Avg | Federated+DP(epsilon=8) |
|---|---|---|---|---|
| F1Score | 0.85 | 0.93 | 0.91 | 0.89 |
| Data Egress Permission | No | Yes(TBLevel) | No(Weights-Only) | No(Noised Weights) |
| Compliance Risk None High(Data Security Law) Low Minimal(Provable) | ||||
| Transmission Volume | 0 | TBLevel | 50MB | 50MB |
| Total Training Time | 15min | 45min | ~8min(Communication) | ~9min |
| Hardware Requirements | Single Plant GPU | Central Server GPUCluster | Plant-Supplied GPU | Plant-Supplied GPU |
| Application Scenarios | Data-Sufficient Single Plant | Data Centralizable | Data Non-Egress | High Compliance Requirement |
Frequently Asked Questions
Q: Our plant only has 10 overhead cranes — is federated learning still worth it with such a small dataset?
A: Yes. Even with a small local dataset (10 cranes), participating in federated learning delivers measurable gains. The global model learns general degradation patterns from multiple plants, and local fine-tuning adapts those patterns to your specific equipment. In our extended tests, a single plant with 10 cranes achieved an F1 score of 0.72 standalone, which improved to 0.87 after joining federated learning — a 15-point boost.
Q: How is communication security handled in federated learning?
A: We recommend a three-layer security approach: ① Gradient protection — differential privacy (DP-SGD, ε=8) adds Gaussian noise (σ=0.01) before weights are uploaded, defending against gradient leakage attacks; ② Transport encryption — TLS 1.3 secures all communication against man-in-the-middle interception; ③ Client authentication — mutual x.509 certificates ensure only authorized clients can participate in aggregation.
Q: What happens if a plant's network drops mid-training?
A: The Flower framework supports asynchronous aggregation (FedAsync) with built-in fault tolerance. The central server waits a default timeout of 60 seconds; if a client fails to respond, it is skipped and aggregation proceeds with updates from the remaining clients. The disconnected client can request the latest global model when it reconnects. In our simulations, a single client with random disconnects (10% probability) reduced the F1 score from 0.91 to 0.88 — a 3% loss — still outperforming the 0.85 achieved by standalone single-plant training.
Q: Does federated learning require uniform hardware across all plants?
A: No. The Flower framework supports heterogeneous clients (Linux/Windows, GPU/CPU, PyTorch/TensorFlow). Each plant trains on its own hardware: Plant A uses an RTX 4090 (3 min/round), Plant B an RTX 3060 (5 min/round), and Plant C runs on CPU (15 min/round). The central server synchronizes aggregation using a "wait for the fastest client + 30%" policy.
