Edge Computing oder Cloud-Verarbeitung: Wo sollten IoT-Daten verarbeitet werden?

Ob ein IoT-Gerät Daten lokal verarbeiten oder in die Cloud schicken soll, ist keine Designpräferenz, sondern eine Architekturentscheidung mit direkten Auswirkungen auf Latenz, Energieverbrauch, Zertifizierungsaufwand und Betriebskosten. Wer diese Frage zu spät im Entwicklungsprozess beantwortet, riskiert teure Hardware-Revisionen oder eine Architektur, die unter realen Betriebsbedingungen nicht skaliert. Dieser Artikel analysiert die relevanten Entscheidungsfaktoren, typische Fehler und zeigt, wann welche Verarbeitungsstrategie sinnvoll ist.

Table of Contents

Entscheidungsfaktoren: Latenz, Bandbreite und Datenschutz

Die Wahl zwischen Edge und Cloud hängt von drei primären Systemparametern ab: Reaktionszeit, Datendurchsatz und regulatorischen Anforderungen. Jeder dieser Faktoren kann die Architekturentscheidung allein kippen, unabhängig von den anderen.

Latenz: Applikationen, die innerhalb von 10 bis 50 ms reagieren müssen, zum Beispiel industrielle Steuerungsschleifen oder medizinische Alarmfunktionen, sind für Cloud-Verarbeitung strukturell ungeeignet. Round-Trip-Zeiten über LTE oder Wi-Fi liegen typischerweise bei 50 bis 200 ms, ohne Serverlast und Protokoll-Overhead einzurechnen. Wer diese Grenze ignoriert, baut ein System, das im Normalbetrieb funktioniert, aber unter Last oder bei schlechter Verbindung kritische Timing-Anforderungen verletzt.

Bandbreite und Übertragungskosten: Kontinuierliche Rohdatenströme, etwa von IMU-Arrays oder Multikanal-EKG-Sensoren mit 500 Hz, erzeugen schnell mehrere Megabyte pro Minute. Bei NB-IoT oder LoRa ist die verfügbare Bandbreite so begrenzt, dass eine Cloud-first-Strategie schlicht nicht funktioniert. Selbst bei LTE-M steigen die Datentransferkosten bei hohem Volumen auf ein Niveau, das die Unit Economics bei Skalierung zerstört.

Datenschutz und Compliance: Medizinische Wearables, die unter MDR oder HIPAA fallen, unterliegen strengen Anforderungen an die Datenlokalisierung. Biometrische Rohdaten dürfen in vielen Kontexten nicht unverschlüsselt übertragen oder auf Servern außerhalb der EU gespeichert werden. Edge-Verarbeitung reduziert die Angriffsfläche und vereinfacht die Compliance-Dokumentation, aber sie verlagert die Sicherheitsverantwortung auf das Gerät selbst, inklusive sicherer Boot-Chain und Firmware-Update-Mechanismus.

Stärken und Grenzen von Edge Computing im IoT

Edge Computing bedeutet, dass Rechenlogik auf dem Gerät selbst oder auf einem lokalen Gateway ausgeführt wird, ohne Verbindung zur Cloud. Das reduziert Latenz, spart Bandbreite und ermöglicht Offline-Betrieb. Die Grenzen liegen im verfügbaren Rechenbudget und im Energieverbrauch.

Mikrocontroller wie STM32 oder NXP i.MX RT bieten ausreichend Rechenleistung für Filteralgorithmen, einfache ML-Inferenz mit TensorFlow Lite Micro oder Zustandsmaschinen. Komplexere Modelle, etwa CNNs für Bilderkennung oder tiefe neuronale Netze, überfordern MCU-Architekturen sowohl in Bezug auf Speicher als auch auf Inferenzzeit. Der häufigste Fehler: Teams trainieren ein Modell auf einem Server, ohne vorab zu prüfen, ob es in 256 kB Flash und 64 kB RAM passt. Das Ergebnis ist ein Redesign des Modells oder ein teurerer Chip.

Energiekosten der Edge-Verarbeitung: Lokale Signalverarbeitung kostet Strom. Ein Cortex-M4 bei 80 MHz verbraucht je nach Peripherie 10 bis 30 mA im aktiven Betrieb. Bei einem 500-mAh-Akku und kontinuierlicher Verarbeitung ergibt das eine Laufzeit von unter 20 Stunden. Low-Power-Design erfordert aggressives Duty-Cycling, Interrupt-gesteuerte Wakeup-Logik und sorgfältige Auswahl der aktiven Peripherie. Wer das nicht von Anfang an in das Hardware-Schaltplan-Design einbezieht, optimiert später gegen eine fixierte Architektur.

Stärken und Grenzen von Cloud-Verarbeitung im IoT

Cloud-Verarbeitung bietet nahezu unbegrenzte Rechenkapazität, zentrale Datenhaltung und einfaches Over-the-Air-Update-Management. Für Applikationen, die historische Daten analysieren, Modelle trainieren oder geräteübergreifende Korrelationen berechnen, ist die Cloud die einzig skalierbare Option.

Die Grenzen sind struktureller Natur. Sobald die Verbindung unterbrochen ist, verliert das Gerät seine Verarbeitungsfähigkeit, wenn keine lokale Fallback-Logik implementiert ist. In industriellen Umgebungen mit schlechtem Funknetz oder in Gebieten ohne stabile LTE-Abdeckung ist das ein Produktionsproblem, kein Randszenario. Ein weiterer unterschätzter Faktor: Cloud-Abhängigkeit erzeugt einen Single Point of Failure auf Infrastrukturebene. Wenn der Cloud-Dienst ausfällt oder das Pricing-Modell des Anbieters sich ändert, sind alle Geräte im Feld betroffen.

Für regulierte Produkte, insbesondere im Medizinbereich, muss die Cloud-Infrastruktur in die Risikoanalyse nach ISO 14971 einbezogen werden. Das erhöht den Dokumentationsaufwand und verlängert den Zertifizierungsprozess um typischerweise mehrere Wochen. Teams, die das bei der Projektplanung nicht einkalkulieren, geraten in Zeitverzug kurz vor dem Markteintritt.

Hybride Architektur: Edge und Cloud kombinieren

Die meisten produktionsreifen IoT-Systeme verwenden eine hybride Strategie: zeitkritische oder datenschutzrelevante Verarbeitung findet lokal statt, während aggregierte oder historische Daten in die Cloud übertragen werden. Die Herausforderung liegt im korrekten Schnitt zwischen den Schichten.

Ein typisches Muster: Das Gerät führt lokal eine Vorverarbeitung durch, zum Beispiel Peak-Detection, Feature-Extraktion oder Schwellenwertüberwachung, und sendet nur Ereignisse oder komprimierte Features, nicht Rohdaten. Das reduziert das Übertragungsvolumen um Faktoren von 10 bis 100 und verlängert die Akkulaufzeit entsprechend. Die Cloud übernimmt Modelltraining, Langzeitanalyse und Fleet-Management.

Der kritische Designfehler bei hybriden Architekturen ist ein unklares Datenmodell an der Schnittstelle. Wenn Edge und Cloud unterschiedliche Annahmen über Zeitstempel, Einheiten oder Sensorauflösung machen, entstehen stille Datenfehler, die erst in der Auswertung sichtbar werden, oft Monate nach dem Launch. Das Schnittstellenprotokoll muss versioniert und rückwärtskompatibel sein, bevor die erste Firmware in den Feldbetrieb geht.

Typische Anwendungsfälle und ihre optimale Verarbeitungsstrategie

Die optimale Verarbeitungsstrategie ergibt sich aus dem Zusammenspiel von Latenzanforderung, Konnektivitätsprofil und regulatorischem Kontext. Universelle Empfehlungen existieren nicht.

Industrielles Condition Monitoring: Vibrationssensoren an Maschinen erfassen Daten mit 10 bis 20 kHz. Rohdaten lassen sich nicht sinnvoll übertragen. Edge-seitige FFT und Anomalie-Erkennung reduzieren das Volumen auf wenige Ereignisse pro Stunde. Cloud-Anbindung dient der Trendanalyse und Wartungsplanung. Konnektivitätsausfall darf den lokalen Betrieb nicht unterbrechen.
Medizinisches Wearable für kontinuierliches EKG-Monitoring: Arrhythmie-Erkennung erfordert lokale Verarbeitung mit Latenz unter 100 ms. Rohdaten dürfen aus Datenschutzgründen nur verschlüsselt und mit expliziter Einwilligung übertragen werden. Cloud dient der ärztlichen Auswertung und Langzeitdokumentation, nicht der Echtzeitalarmierung.
Consumer-Fitness-Tracker: Schritterkennung und Schlafstadien-Klassifikation laufen lokal auf dem Gerät. Synchronisation mit der App erfolgt über BLE, Cloud-Backup ist optional. Der Nutzer erwartet Offline-Funktionalität. Cloud-Abhängigkeit für Kernfunktionen wäre ein Produktfehler.
Smart-Agriculture-Sensor mit LoRa: Bandbreite begrenzt auf wenige Bytes pro Übertragung. Lokale Mittelwertbildung und Schwellenwertprüfung sind zwingend. Cloud-Anbindung erfolgt über ein Gateway, nicht direkt vom Sensor.

Jedes dieser Szenarien hat einen anderen Treiber für die Architekturentscheidung. Wer die Strategie vom Anwendungsfall ableitet statt von einer Technologiepräferenz, vermeidet die häufigsten Fehler.

Architekturentscheidungen früh im Entwicklungsprozess treffen

Die Verarbeitungsarchitektur bestimmt die Hardwareauswahl, das Kommunikationsprotokoll, den Energiebedarf und den Zertifizierungsaufwand. Wer diese Entscheidung nach dem ersten Prototypen trifft, trifft sie zu spät.

Konkret bedeutet das: Vor dem ersten Schaltplanentwurf müssen Latenzbudget, maximale Datenmenge pro Zeiteinheit, Offline-Anforderungen und regulatorischer Kontext definiert sein. Diese Parameter bestimmen, ob ein Cortex-M4 ausreicht oder ein Cortex-A-Prozessor mit Linux benötigt wird, ob NB-IoT oder Wi-Fi die richtige Wahl ist, und ob eine lokale Datenspeicherung mit Verschlüsselung eingeplant werden muss. Änderungen an diesen Parametern nach dem PCB-Layout kosten typischerweise 4 bis 12 Wochen und eine vollständige Hardware-Revision.

Ein häufig unterschätzter Aspekt: Die Embedded-Software-Architektur muss parallel zur Hardware definiert werden. Wenn das Betriebssystem, der Kommunikationsstack und die Datenverarbeitungslogik nicht von Anfang an auf die gewählte Verarbeitungsstrategie ausgelegt sind, entstehen Integrationsprobleme, die sich durch nachträgliche Patches nicht vollständig lösen lassen. Echtzeit-Betriebssysteme wie FreeRTOS oder Zephyr haben unterschiedliche Stärken je nach Anforderungsprofil, und diese Wahl beeinflusst die verfügbaren Middleware-Komponenten für Kryptographie, OTA-Updates und Protokoll-Stacks.

Wie Oxeltech bei der Architekturentscheidung hilft

Wir unterstützen Teams dabei, die Edge-Cloud-Architektur vor dem ersten Schaltplanentwurf zu definieren, nicht danach. Unser Ansatz deckt alle relevanten Ebenen ab:

Anforderungsanalyse: Wir erfassen Latenzbudget, Datenmenge, Konnektivitätsprofil und regulatorischen Kontext, um die Verarbeitungsstrategie auf einer sachlichen Grundlage festzulegen.
Hardware-Design: Auswahl der richtigen Mikrocontroller- oder Prozessorarchitektur, Kommunikationsmodule und Energieversorgung auf Basis der definierten Architektur.
Firmware und Embedded Software: Implementierung von Edge-Logik, Kommunikationsprotokollen und OTA-Update-Mechanismen mit RTOS-Unterstützung für FreeRTOS und Zephyr.
Prototyp bis Serienreife: Wir begleiten das Projekt vom ersten Prototypen über EMC/EMI-Tests bis zur Zertifizierung und Serienproduktion.

Wenn die Architekturentscheidung für Ihr IoT-Produkt noch aussteht oder ein laufendes Projekt in eine Sackgasse geraten ist, sprechen Sie uns an. Wir analysieren die Anforderungen und entwickeln eine Architektur, die unter realen Betriebsbedingungen funktioniert.