Edge vs. Cloud für Predictive Maintenance: Wann welche Architektur?

Die falsche Dichotomie

Jeder Predictive-Maintenance-Anbieter wird Ihnen erzählen, sein Ansatz sei der bessere. Edge-Anbieter sagen, Cloud sei zu langsam und zu teuer. Cloud-Anbieter sagen, Edge könne keine komplexen Modelle verarbeiten. Beide liegen falsch — oder genauer: Beide haben Recht in bestimmten Kontexten.

Die eigentliche Frage lautet nicht „Edge oder Cloud?" Sondern: „Welche Berechnungen sollten wo stattfinden und warum?"

Die Entscheidungsmatrix

| Faktor | Edge | Cloud | Hybrid | |---|---|---|---| | Latenzanforderung | <10 ms (sicherheitskritisch) | <500 ms (akzeptabel) | Gemischt | | Konnektivität | Intermittierend/keine | Zuverlässig | Variabel | | Modellkomplexität | Einfach (IF, ONNX) | Komplex (LSTM, Transformer) | Beides | | Datenvolumen | >100K Punkte/s | Aggregierte Zusammenfassungen | Vorgefiltert | | Regulatorik | Daten dürfen Standort nicht verlassen | Cloud-konforme Region | Lokal verarbeitet, Metadaten in Cloud | | Kosten bei Skalierung | Feste CAPEX | Variable OPEX | Optimiert | | Aktualisierungshäufigkeit | Manuell/geplant | Kontinuierlich | Gestuft |

Wann Edge gewinnt

1. Sicherheitskritische Latenz

Ein Verdichter-Surge-Erkennungssystem kann nicht 200 ms auf einen Cloud-Roundtrip warten. Bis die Antwort eintrifft, ist der mechanische Schaden bereits eingetreten.

Faustregel: Wenn die Anforderung an die Reaktionszeit unter 50 ms liegt, muss die Verarbeitung am Edge erfolgen. Ohne Ausnahme.

Praxisbeispiel: Ein Turboverdichter mit 12.000 U/min absolviert eine volle Umdrehung in 5 ms. Die Surge-Erkennung muss innerhalb von 2-3 Umdrehungen auslösen. Das sind 10-15 ms — unmöglich über einen Netzwerk-Roundtrip zur Cloud.

2. Unzuverlässige Konnektivität

Offshore-Ölplattformen, untertägige Bergwerke, ländliche Produktionsstandorte und mobile Anlagen (Fuhrpark, Krane, Schiffe) verfügen oft über intermittierende Konnektivität. Ihr PdM-System muss weiterarbeiten, wenn das Netzwerk ausfällt.

Was am Edge funktioniert:

Isolation Forest Anomalieerkennung (kleines Modell, schnelle Inferenz)
ONNX-exportierte neuronale Netze (in der Cloud vortrainiert, am Edge bereitgestellt)
Regelbasierte Alarme als Fallback
Lokale Datenpufferung mit Synchronisation bei Verbindung

3. Datensouveränität

Bestimmte Branchen (Verteidigung, Nuklear, Pharma) verbieten, dass Sensordaten die Anlage verlassen. Edge-Inferenz, bei der nur aggregierte Zustandswerte an ein zentrales Dashboard gesendet werden, erfüllt sowohl den ML-Bedarf als auch die Compliance-Anforderung.

4. Bandbreitenökonomie

Ein einzelner Schwingungssensor mit 25,6 kHz Abtastrate erzeugt ca. 2 GB/Tag an Rohdaten. Multiplizieren Sie das mit 200 Sensoren, und Sie sehen sich 400 GB/Tag gegenüber — das ist teuer für Cloud-Streaming und für die meisten Anwendungsfälle unnötig.

Edge-Vorverarbeitung: Extrahieren Sie Features lokal (RMS, Kurtosis, Spektralspitzen, Lagerfrequenzen), senden Sie den 20-Byte-Feature-Vektor statt der 200-KB-Rohwellenform. Das ist eine 10.000-fache Bandbreitenreduktion.

Wann Cloud gewinnt

1. Komplexes Modelltraining

Das Training eines LSTM Autoencoder oder eines TranAD-Transformer-Modells erfordert GPU-Rechenleistung, große Datensätze über Monate hinweg und Hyperparameter-Optimierung. Das findet nicht am Edge statt.

Das Muster:

Sensordaten fließen in die Cloud (roh oder feature-extrahiert)
Modelle werden auf GPU-Clustern trainiert (Ray Train, verteilt)
Trainierte Modelle werden nach ONNX exportiert
ONNX-Modelle werden am Edge für die Inferenz bereitgestellt

2. Anlagenübergreifendes Lernen

Die leistungsfähigste PdM-Funktion ist das Erkennen von Mustern über Ihre gesamte Flotte hinweg. „Pumpe 7A im Werk Chicago zeigt dasselbe Degradationsmuster, das dem Ausfall von Pumpe 3B im Werk München letzten Monat vorausging."

Das erfordert zentralisierte Daten aller Anlagen — also Cloud. Edge-Geräte sehen nur ihre lokalen Sensoren.

3. Erweiterte Analytik

Ursachenanalyse: PCMCI-Kausalgraphen benötigen Daten von mehreren zusammenhängenden Sensoren und Anlagen
Restnutzungsdauer: Weibull-RNN-Modelle mit Konfidenzintervallen benötigen historische Ausfalldaten
SHAP-Erklärungen: Die Berechnung von Feature-Beiträgen für die Erklärbarkeit ist rechenintensiv
Digitale Zwillinge: Physik-informierte Modelle erfordern zentralisierte Simulationsumgebungen

4. Standortübergreifende Dashboards

Ein VP Operations benötigt eine einheitliche Ansicht über 15 Werke, 3.000 Anlagen und 20.000 Sensoren. Das ist ein Cloud-Problem — Aggregation, Visualisierung und rollenbasierte Zugriffskontrolle im großen Maßstab.

Die hybride Architektur

Die besten PdM-Systeme nutzen beides. So funktionieren die Schichten:

Schicht 1: Sensor → Edge-Gateway (μs)
  - Signalaufbereitung, Abtastung, FFT
  - Sofortige Sicherheitsabschaltungen (festverdrahtet, nicht softwarebasiert)

Schicht 2: Edge Agent (ms)
  - Feature-Extraktion (Rolling Statistics, Spektralmerkmale)
  - ONNX-Modellinferenz (Anomalie-Score, einfache Fehlerklasse)
  - Lokale Alarmierung (SMS, Relaisausgang, lokales HMI)
  - Datenpufferung für Batch-Upload

Schicht 3: Cloud-Plattform (Sekunden)
  - Vollständige ML-Pipeline (LSTM, TranAD, Weibull-RNN, CNN)
  - Anlagenübergreifende Mustererkennung
  - SHAP-Erklärungen
  - RUL-Vorhersage mit Konfidenzintervallen
  - Dashboard, Reporting, CMMS-Integration

Schicht 4: Cloud ML Ops (Stunden/Tage)
  - Modell-Retraining auf akkumulierten Daten
  - A/B-Testing neuer Modellversionen
  - AutoML für mandantenspezifisches Fine-Tuning
  - ONNX-Export → Edge-Deployment

Datenfluss in der Praxis

12 kHz Schwingung → Edge-FFT → 256 Spektralbins → Cloud (alle 10 Sekunden)
1 Hz Temperatur/Druck → Edge-Rolling-Statistics → Cloud (alle 60 Sekunden)
Edge-Anomalie-Score → Cloud (Echtzeit via MQTT) → Dashboard
Cloud-LSTM-Vorhersage → Alert Engine → PagerDuty/ServiceNow

Kostenoptimierung

Der hybride Ansatz ist nicht nur technisch überlegen — er ist auch günstiger:

| Architektur | Monatliche Kosten (200 Anlagen) | Latenz | Offline-fähig | |---|---|---|---| | Nur Cloud | ~2.400 € (Compute + Bandbreite) | 200-500 ms | Nein | | Nur Edge | ~8.000 € (Hardware-CAPEX amortisiert) | <10 ms | Ja | | Hybrid | ~1.800 € (reduzierte Bandbreite + kleinere Cloud) | <10 ms lokal, <500 ms Cloud | Teilweise |

Die Bandbreiteneinsparungen durch Edge-Vorverarbeitung amortisieren allein die Edge-Hardware typischerweise innerhalb von 6 Monaten.

Die richtige Architektur wählen

Beginnen Sie mit Cloud, wenn:

Sie eine zuverlässige Konnektivität haben (>99 % Verfügbarkeit)
Ihre Latenzanforderung >100 ms beträgt
Sie <50 Anlagen haben (Edge-Hardware-CAPEX rechtfertigt sich nicht)
Sie den schnellsten Weg zum ersten Ergebnis wollen

Beginnen Sie mit Edge, wenn:

Sie unzuverlässige oder keine Konnektivität haben
Sie sicherheitskritische Latenzanforderungen haben (<50 ms)
Daten Ihre Anlage nicht verlassen dürfen
Sie bereits Edge-Gateways besitzen (Raspberry Pi, Siemens IOT2050 etc.)

Beginnen Sie hybrid, wenn:

Sie 50+ Anlagen an mehreren Standorten haben
Sie sowohl schnelle lokale Reaktion ALS AUCH erweiterte Cloud-Analytik benötigen
Sie anlagenübergreifendes Lernen mit lokaler Ausfallsicherheit wollen

Prevlys Ansatz

Prevly unterstützt alle drei Architekturen:

Prevly Lite (Edge): Eigenständiger Edge Agent mit ONNX-Inferenz, lokalem Dashboard, Parquet-Batch-Sync. 49 €/Maschine/Monat.
Prevly Standard (Cloud): Vollständige Cloud-SaaS mit allen ML-Modellen, SHAP, RUL und Integrationen. 149 €/Maschine/Monat.
Prevly Enterprise (Hybrid): Edge Agents + Cloud-Plattform, flottenweites Lernen, dedizierte Infrastruktur. Individuelle Preisgestaltung.

Der Edge Agent läuft auf jedem Linux-Gerät mit Python 3.10+ — vom 35-€-Raspberry-Pi-5 bis zum industriellen Advantech-Gateway. Modelle werden in der Cloud trainiert und automatisch per ONNX-Export am Edge bereitgestellt.

Denn die richtige Antwort auf „Edge oder Cloud?" lautet fast immer „Ja."

Weiterführende Artikel: On-Premise vs. Cloud-PdM · Schreibgeschütztes OPC-UA-Monitoring · Eigenentwicklung vs. Kauf