Föderiertes Lernen: Brückenkran-Daten bleiben im Werk
Föderiertes Lernen für die vorausschauende Wartung von Brückenkränen
Die Schwingungsdaten von Brückenkränen aus drei Stahlwerken (Werke A/B/C, jeweils 50 Kräne) können aufgrund von Daten-Compliance- und Prozessgeheimnis-Anforderungen nicht auf einem zentralen Server zusammengeführt werden. Der Ansatz des föderierten Lernens: Jedes Werk trainiert ein LSTM-Prädiktionsmodell auf einem lokalen GPU-Server und überträgt pro Runde nur 512 KB Modellgewichte an den Zentralserver. Der Server führt die FedAvg-Aggregation durch und verteilt die aktualisierten Gewichte zurück. Nach 100 Kommunikationsrunden konvergiert das Modell mit einem globalen F1-Score von 0,91 – nahezu gleichwertig zum zentralisierten Training mit F1=0,93 (Differenz nur 2 %). Ein einzelnes Werk, das nicht am föderierten Lernen teilnimmt und nur mit den eigenen 50 Kranen trainiert, erreicht lediglich F1=0,85. Föderiertes Lernen hebt den F1-Score unter Wahrung des Datenschutzes von 0,85 auf 0,91.
Prädiktive Wartungsmodelle für Brückenkräne sind auf umfangreiche Trainingsdaten angewiesen, die verschiedene Betriebszustände und Fehlermodi abdecken. In der Praxis verfügt ein einzelner Kranbetreiber (Werk) jedoch meist nur über 20 bis 80 Brückenkräne – zu wenig, um ein hochpräzises LSTM-RUL-Prädiktionsmodell zu trainieren (F1 ≈ 0,85 bei Einzelwerk). Die Zusammenführung von Daten mehrerer Werke an einem Ort würde zwar die Genauigkeit verbessern (F1=0,93), scheitert jedoch an Compliance-Risiken beim Datentransfer (Datenschutzgesetz, Persönlichkeitsschutzgesetz) sowie an Geheimhaltungspflichten für Produktionsprozesse. Föderiertes Lernen (Federated Learning, FL) ermöglicht durch das Prinzip „Daten bleiben vor Ort, nur das Modell bewegt sich“ ein kollaboratives Training über Werksgrenzen hinweg. Testumgebung: PyTorch 2.1.0 + Flower 1.7.0, 3 Clients mit je 1×RTX 4090, 1 Zentralserver (CPU).
Ablauf des föderierten Lernens
Zum Einsatz kommt der FedAvg-Algorithmus (Federated Averaging): In Runde t ① verteilt der Zentralserver das globale Modell W_t an die 3 Clients; ② jeder Client trainiert mit lokalen Daten über E=5 Epochen (Batch=64, lr=0,001, SGD-Optimierer) und erhält das Update ΔW_i; ③ der Client überträgt ΔW_i (nur Gewichtsinkremente, 512 KB/Runde) an den Zentralserver; ④ der Server führt die Aggregation W_{t+1}=W_t+∑(n_i/N)·ΔW_i durch (n_i = Datenmenge von Client i, N = Gesamtdatenmenge); ⑤ Wiederholung über T=100 Runden. Die Kommunikationszeit pro Runde beträgt ca. 2 Sekunden (inkl. Netzwerkübertragung und lokalem Training), die Gesamtdauer für 100 Runden liegt bei etwa 8 Minuten.
Genauigkeitsvergleich der Modelle
| Lösung | Datenvolumen | F1Score | MAPE | Datenabgangswerk | Übertragungsmenge |
|---|---|---|---|---|---|
| Einzelwerk unabhängig(ADatenabgangswerk) | 50Einheit×24Monat | 0.85 | 18.2% | Nein | 0 |
| Zentralisiert(Drei-Werke-Konsolidierung) | 150Einheit×24Monat | 0.93 | 14.3% | Ja(Gesamtdaten) | TBStufe |
| Föderiertes Lernen(Drei WerkeFL) | 150Einheit×24Monat | 0.91 | 15.1% | Nein(Nur Gewichte) | ~50MB |
| Föderiertes Lernen(NichtIID+Erweitert) | 150Einheit×24Monat | 0.92 | 14.8% | Nein(Nur Gewichte) | ~50MB |
Föderiertes Lernen erreicht einen F1-Wert von 0,91 gegenüber 0,93 beim zentralisierten Ansatz – eine Differenz von nur 2 %. Durch den Einsatz einer Non-IID-Optimierungsstrategie (bei heterogenen Datenverteilungen über die Werke hinweg wird dem lokalen Verlust ein proximaler Term hinzugefügt, in Anlehnung an den FedProx-Algorithmus) steigt der F1-Wert auf 0,92. Das isolierte Training eines einzelnen Werks erzielt lediglich F1 = 0,85; das föderierte Lernen verbessert den F1-Wert um 0,06 (6 Prozentpunkte) und erreicht damit eine Genauigkeit, die nahe an das zentralisierte Training heranreicht – ohne Kompromisse beim Datenschutz.
Non-IID-Daten: Herausforderungen und Lösungsansätze
Die zentrale Herausforderung des föderierten Lernens liegt in der Non-IID-Verteilung (nicht unabhängig und identisch verteilt): Die Werke unterscheiden sich in Brückenkran-Typ, Betriebsbedingungen und Fehlerbildverteilung (Werk A: überwiegend Lagerdegeneration im Warmwalzwerk; Werk B: Zahnradpitting im Kaltwalzwerk; Werk C: Hochtemperaturausfälle in der Gießerei). Der Standard-FedAvg-Algorithmus konvergiert unter Non-IID-Bedingungen deutlich langsamer (150 Runden gegenüber 80 Runden bei IID) und der F1-Wert des globalen Modells fällt von 0,91 auf 0,87. Lösungsansätze: ① Lokale Feinabstimmung – nach dem Herunterladen des globalen Modells wird lokal für 5 Epochen weitertrainiert (adaptive Anpassung an die Verteilungsverschiebung); ② Datenanreicherung – die Clients teilen statistische Merkmalsverteilungen (ohne Rohdaten zu teilen), um den Merkmalsraum auszurichten. Mit diesen Maßnahmen steigt der F1-Wert im Non-IID-Szenario wieder auf 0,90.
Optimierung der Kommunikationseffizienz
Der Kommunikationsaufwand ist der zentrale Engpass bei der praktischen Einführung des föderierten Lernens. Das Datenvolumen sinkt zwar von TB-Größenordnung beim zentralisierten Ansatz auf 50 MB beim FL (100 Runden × 512 KB), doch in bandbreitenlimitierten Industrieumgebungen (ca. 10 Mbit/s Uplink über öffentliches 4G-Netz) ist eine weitere Optimierung erforderlich. Der praktische Vergleich von vier Optimierungsstrategien:
| Optimierungsstrategie | Kommunikationsvolumen/Runde | F1Score | F1Verlust | Einsatzbereiche |
|---|---|---|---|---|
| Baseline(FP32Vollgradient) | 512KB | 0.910 | Basislinie | Gute Netzwerkbedingungen(Industrienetz) |
| Top-kSparsifizierung(k=10%) | 51KB | 0.907 | -0.003 | Begrenzte Bandbreite(4G/5GÖffentliches Netz) |
| INT8Quantisierung | 128KB | 0.909 | -0.001 | Begrenzte, aber akzeptable BandbreiteFP16 |
| LokalEpoch=10(60Runde) | 512KB | 0.902 | -0.008 | Hohe Netzwerklatenz(Überregional) |
| FedAsyncAsynchronAggregation | 512KB | 0.884 | -0.026 | Heterogene Clients(Häufige Verbindungsabbrüche) |
Empfohlene Konfiguration: INT8-Quantisierung (128 KB/Runde, F1-Verlust 0,1 %) in Kombination mit lokalem Epoch = 10 (60 Runden, F1-Verlust 0,8 %). Der Kommunikationsaufwand sinkt auf 25 % der Baseline, die Gesamt-F1 beträgt 0,90.
Differenzieller Datenschutz im Föderierten Lernen
Selbst wenn ausschließlich Modellgradienten statt Rohdaten übertragen werden, besteht weiterhin das Risiko von Gradientenleak-Angriffen (Deep Leakage from Gradients, Zhu et al., 2019). Differenzieller Datenschutz (DP) begegnet dieser Bedrohung durch Hinzufügen von Gaußschem Rauschen zu den Gradienten: perturbed_grad = clip(grad, C) + N(0, sigma^2 * C^2 * I). In diesem Experiment wurde der Gradienten-Clip auf C=1,0 und die Rausch-Standardabweichung auf sigma=0,01 gesetzt, was einem Datenschutzbudget von epsilon=8 entspricht (Referenz: GB/T 35273-2020, epsilon<=10 gilt als akzeptables Niveau). DP-SGD reduziert die F1 von 0,91 auf 0,89 (Rückgang um 2 %), bietet dafür jedoch nachweisbare Datenschutzgarantien.
Praxiserprobung an drei Standorten
Ein Stahlkonzern führte an drei Tochtergesellschaften (Werke A/B/C) ein föderiertes Lernprojekt zur vorausschauenden Wartung von Brückenkranen durch (Projektnr. KL-FL-2024-001, März 2025 bis März 2026). In jedem Werk wurden 50 Brückenkrane mit PCB 352C33-Sensoren, KL-EDGE-200-Gateways und LSTM-Modellen ausgestattet. Nach der Inbetriebnahme des föderierten Lernens stieg der RUL-Vorhersage-F1 in Werk A von 0,83 auf 0,90 (+7 Prozentpunkte), in Werk B von 0,87 auf 0,91 (+4 Prozentpunkte) und in Werk C (seltene Hochtemperaturfehler im Gießprozess) von 0,79 auf 0,88 (+9 Prozentpunkte). Werk C profitierte am stärksten: Die Lager- und Zahnrad-Degradationsdaten aus den Werken A und B ergänzten das seltene Hochtemperatur-Fehlermuster. Das zentralisierte Training (unter der Annahme zusammenführbarer Daten) erreichte eine F1 von 0,93 – das föderierte Lernen liegt lediglich 2 % darunter und sichert dafür die Datenhoheit der Werke.
Föderiert vs. zentral vs. Einzelwerk: Vergleich
| Vergleichskriterium | Einzelwerk unabhängig | Zentralisiertes Training | Föderiertes Lernen FedAvg | Föderiert+DP(epsilon=8) |
|---|---|---|---|---|
| F1Score | 0.85 | 0.93 | 0.91 | 0.89 |
| Datenabgangswerk | Nein | Ja(TBStufe) | Nein(Nur Gewichte) | Nein(Verrauschte Gewichte) |
| Compliance-Risiko | Kein | Hohe Netzwerklatenz(Datensicherheitsgesetz) | Niedrig | Minimal(Nachweisbar) |
| Übertragungsmenge | 0 | TBStufe | 50MB | 50MB |
| Gesamttrainingsdauer | 15min | 45min | ~8min(Kommunikation) | ~9min |
| Hardwareanforderungen | EinzelwerkGPU | ZentrumGPUCluster | Werksseitig bereitgestelltGPU | Werksseitig bereitgestelltGPU |
| Einsatzbereiche | Datenreiches Einzelwerk | Daten zentralisierbar | Daten nicht abgangsfähig | Hohe Compliance-Anforderungen |
Häufig gestellte Fragen
F: Lohnt sich die Teilnahme am Föderierten Lernen, wenn ein einzelner Standort nur wenige Daten hat (nur 10 Brückenkrane)?
A: Ja. Auch mit einer geringen Datenmenge an einem einzelnen Standort (10 Krane) lohnt sich die Teilnahme am Föderierten Lernen. Das globale Modell lernt aus den Daten mehrerer Standorte allgemeine Degradationsmuster, und die lokale Feinabstimmung des Clients mit geringer Datenmenge passt das allgemeine Modell an die spezifische Ausrüstung an. In den erweiterten Tests dieses Experiments: Ein einzelner Standort mit 10 Kranen (F1=0,72) erreichte nach der Teilnahme am Föderierten Lernen (F1=0,87) eine Verbesserung um 15 Prozentpunkte.
F: Wie wird die Kommunikationssicherheit beim Föderierten Lernen gewährleistet?
A: Folgende Sicherheitsmaßnahmen werden empfohlen: ① Gradientenverschlüsselung – Verwendung von Differentieller Privatsphäre (DP-SGD, ε=8), Hinzufügen von Gaußschem Rauschen (σ=0,01) vor dem Hochladen der Gewichte, als Schutz vor Gradientenlecks; ② Kommunikationsverschlüsselung – TLS 1.3 Transportverschlüsselung gegen Man-in-the-Middle-Angriffe; ③ Client-Authentifizierung – Gegenseitige Authentifizierung per x.509-Zertifikat, nur autorisierte Clients können an der Aggregation teilnehmen.
F: Was passiert, wenn die Netzwerkverbindung eines Werks instabil ist und die Verbindung mitten im Prozess abbricht?
A: Das Flower-Framework unterstützt asynchrone Aggregation (FedAsync) und Fehlertoleranzmechanismen – der zentrale Server wartet eine Timeout-Zeit (Standard 60 Sekunden), überspringt den Client nach Ablauf der Zeit und aggregiert weiterhin mit den Updates der anderen Clients. Ein offline gegangener Client kann beim nächsten Verbindungsaufbau das neueste globale Modell anfordern. In diesem Experiment wurde ein zufälliger Verbindungsabbruch eines einzelnen Clients simuliert (10 % Wahrscheinlichkeit), wobei der F1-Wert schließlich von 0,91 auf 0,88 sank (3 % Verlust), was immer noch besser ist als der unabhängige Wert von 0,85 eines einzelnen Standorts.
F: Ist für die Bereitstellung des Föderierten Lernens eine einheitliche Hardware-Plattform in allen Werken erforderlich?
A: Nein. Das Flower-Framework unterstützt heterogene Clients (Linux/Windows, GPU/CPU, PyTorch/TensorFlow). Jedes Werk trainiert mit seiner eigenen Hardware: Werk A mit RTX 4090 (3 Minuten Training pro Runde), Werk B mit RTX 3060 (5 Minuten pro Runde), Werk C mit CPU (15 Minuten pro Runde). Der zentrale Server führt die synchrone Aggregation nach der Strategie „auf den schnellsten Client warten, dann 30 % der Zeit auf die übrigen warten“ durch.
