Die Frage, ob Maschinendaten über einen Edge-Knoten verarbeitet oder direkt in die Cloud gestreamt werden sollen, ist eine der praktisch wichtigsten Architekturentscheidungen in IoT-Projekten für die Fertigung. Sie beeinflusst Latenz, Kosten, Datensicherheit, Wartungsaufwand und die langfristige Skalierbarkeit einer Lösung – und es gibt keine universell richtige Antwort.
Dieser Beitrag erklärt die Kernunterschiede der beiden Ansätze und bietet eine Entscheidungsmatrix für typische Fertigungsszenarien.
Das Problem mit ungefilterten Rohdaten
Moderne Fertigungsmaschinen erzeugen erhebliche Datenmengen. Eine einzelne CNC-Maschine mit aktivierter Zustandsüberwachung kann über OPC-UA 500–2.000 Datenpunkte pro Sekunde liefern. Bei zehn Maschinen in einer Zelle, einem 16-Stunden-Produktionstag und 250 Arbeitstagen im Jahr ergibt das – unkomprimiert – mehrere Terabyte pro Jahr und Produktionszelle.
Direktes Cloud-Streaming dieser Rohdaten ist in den meisten Fällen weder wirtschaftlich (hohe Transferkosten, hohe Speicherkosten) noch sinnvoll (die meisten Rohdaten sind für langfristige Analysen nicht benötigt – nur abgeleitete Merkmale). Das eigentliche Problem: Wenn man nicht vorher entscheidet, was man aus den Daten berechnen möchte, neigt man dazu, alles zu speichern – und hört damit nicht auf zu wachsen.
Edge Computing löst dieses Problem durch lokale Vorverarbeitung: Statt Rohdaten werden berechnete Merkmale, komprimierte Zeitreihen oder Event-basierte Datenpunkte übertragen. Das reduziert das Datenvolumen typischerweise um Faktor 10–100.
Edge Computing: Was es leistet und was nicht
Ein Edge-Knoten ist ein lokaler Rechner (häufig ein Industrie-PC oder ein robuster Mini-PC) in der Nähe der Maschinen oder im Schaltschrank, der Daten lokal verarbeitet, bevor sie die Cloud-Plattform erreichen. Typische Aufgaben eines Edge-Knotens:
- Protokollkonvertierung: OPC-UA, Modbus, PROFINET auf einheitliches Format (MQTT, HTTP).
- Merkmalsberechnung: FFT aus Vibrationssignalen, gleitende Durchschnitte, Anomalieerkennung auf Basis einfacher Schwellenwerte.
- Datenpufferung: Bei Netzwerkunterbrechung werden Daten lokal gepuffert und nach Wiederherstellung der Verbindung übertragen.
- Lokale Reaktionslogik: Alarmierung oder Maschinenabschaltung auf Basis lokaler Regeln, unabhängig von der Cloud-Verfügbarkeit.
Was Edge Computing nicht leistet: komplexe ML-Modelle mit großen Parametermengen (GPU-intensive Modelle gehören in die Cloud), langfristige Datenhaltung (Speicher ist lokal begrenzt) und mandantenfähige Multi-Site-Analysen (Quervergleiche zwischen Standorten brauchen eine zentrale Plattform).
Typische Hardware für Edge-Knoten im Fertigungsumfeld: Siemens IPC127E, Advantech UNO-2484G, Raspberry Pi Compute Module in Industriegehäuse (für unkritische Anwendungen), oder spezialisierte IoT-Gateways wie die Moxa UC-Serie. Kosten: 500–3.000 Euro pro Knoten, je nach Anforderung.
Direktes Cloud-Streaming: Wann es funktioniert
Direktes Streaming von Maschinendaten in die Cloud ist sinnvoll, wenn:
- Die Datenmenge pro Maschine gering ist (Zyklusdaten, Zustandssignale, Stückzähler – nicht hochfrequente Rohdaten).
- Die Netzwerkverbindung zur Cloud zuverlässig und kostengünstig ist (stabiles Ethernet oder LTE mit Flatrate).
- Keine harten Echtzeitanforderungen bestehen (Analyseergebnisse dürfen mit einigen Sekunden Verzögerung ankommen).
- Die vorhandene Maschinensteuerung bereits über MQTT oder REST-APIs kommunizieren kann.
Viele neuere Maschinen (ab ca. 2018) haben MQTT-Broker oder HTTP-Clients bereits integriert – hier entfällt die Edge-Hardware für die Protokollkonvertierung. Cloud-Plattformen wie AWS IoT Core, Azure IoT Hub oder Google Cloud IoT Core können MQTT direkt empfangen und skalieren gut mit Datenmenge.
AWS IoT Core kostet aktuell ca. 1,00 USD pro Million MQTT-Nachrichten. Bei 10 Maschinen mit je 1 Nachricht pro Sekunde (16 h/Tag, 250 Tage) sind das ca. 144 Millionen Nachrichten pro Jahr – also rund 144 USD/Jahr für die Übertragung allein. Speicher und Verarbeitung kommen hinzu.
Entscheidungsmatrix: Edge vs. Cloud-Streaming
| Kriterium | Edge Computing | Direktes Cloud-Streaming |
|---|---|---|
| Hochfrequente Signale (>100 Hz) | Ja – lokal vorverarbeiten | Nein – zu viel Volumen |
| Echtzeitreaktion (<100 ms) | Ja – lokal möglich | Nein – Cloud-Latenz zu hoch |
| Offline-Betrieb erforderlich | Ja – Pufferung lokal | Nein – Verbindung Pflicht |
| Ältere Maschinen ohne IP | Ja – Protokollkonvertierung | Nein – kein Direktzugang |
| Niedrige IT-Betriebskapazität | Nein – lokale Hardware zu warten | Ja – managed Service |
| Schnelle Pilotprojekte | Nein – Hardwareinstallation nötig | Ja – schnell einzurichten |
| Datensouveränität (kein Cloud-Abfluss) | Ja – vollständige Kontrolle | Nein – Daten beim Anbieter |
In der Praxis ist die Antwort oft hybrid: Ein leichter Edge-Knoten übernimmt Protokollkonvertierung und Datenpufferung, schickt aber vollständige (wenn auch komprimierte) Zeitreihen in die Cloud für langfristige Analysen. Echtzeitkritische Reaktionen laufen lokal; historische Trendanalysen und KI-Modelle laufen in der Cloud.
Fazit
Edge Computing ist kein Hype-Thema – es löst echte Probleme in der industriellen Datenerfassung. Aber es ist auch kein Universalansatz. Für neue Maschinen mit direkter MQTT-Fähigkeit und niedrigem Datenvolumen ist direktes Cloud-Streaming oft einfacher, günstiger und ausreichend. Für Bestandsmaschinen, hochfrequente Signale, Offline-Anforderungen oder echte Echtzeitreaktion führt kein Weg am Edge vorbei.
Die Entscheidung sollte nie vom Technologieangebot eines Anbieters getrieben werden, sondern von den konkreten Anforderungen: Welche Reaktionszeit brauche ich? Wie viel Daten erzeuge ich? Wie stabil ist meine Netzwerkverbindung? Habe ich interne Ressourcen für lokale Hardware-Wartung?