Wie sieht die Datenarchitektur eines IoT-Produkts von Sensor bis Cloud aus?

Wer ein IoT-Produkt entwickelt, denkt zuerst an den Sensor und die Cloud. Dazwischen liegt jedoch eine Architekturentscheidung, die über Latenz, Energieverbrauch, Zertifizierungsaufwand und Skalierbarkeit entscheidet. Die Datenarchitektur eines IoT-Systems ist kein nachgelagertes Thema für den Software-Stack. Sie definiert, welche Hardware verbaut wird, welches Kommunikationsprotokoll tragbar ist und ob das Produkt bei 10.000 Einheiten noch wirtschaftlich funktioniert.

Dieser Artikel richtet sich an Teams, die bereits Hardware ausgeliefert haben und jetzt ein IoT-Produkt mit durchgängiger Datenarchitektur aufbauen. Die Entscheidungen, die in der frühen Konzeptphase getroffen werden, bestimmen, ob das System später skaliert oder unter Last kollabiert.

Table of Contents

Die typischen Schichten einer IoT-Datenarchitektur

Eine IoT-Datenarchitektur besteht aus vier physisch und logisch trennbaren Schichten: Sensor und Endgerät, Edge-Verarbeitung, Kommunikationsprotokoll und Cloud-Backend. Jede Schicht hat eigene Latenz-, Energie- und Kostenprofile, die sich gegenseitig beeinflussen.

Ein häufiger Fehler ist die Annahme, die Schichten seien unabhängig wählbar. In der Praxis zwingt ein Sensor mit 1-kHz-Abtastrate und 16-Bit-Auflösung das System zu lokaler Vorverarbeitung, weil die Rohdatenmenge über BLE nicht kontinuierlich übertragbar ist, ohne den Energiehaushalt eines batteriebetriebenen Geräts zu sprengen. Wer das Schichtenmodell isoliert betrachtet, wird spätestens beim PCB-Layout mit Widersprüchen konfrontiert, die sich nicht mehr ohne Hardware-Revision lösen lassen.

Die Architekturentscheidung beginnt deshalb mit einer Frage: Welche Daten müssen wann, wo und in welcher Qualität verfügbar sein? Die Antwort bestimmt, welche Schichten welche Last tragen.

Datenerfassung und Vorverarbeitung am Sensor

Sensoren liefern Rohdaten. Was daraus wird, entscheidet sich auf dem Mikrocontroller, der direkt am Sensor sitzt. Bei einem IMU-basierten Wearable etwa erzeugt ein 6-Achs-Sensor bei 200 Hz und 16-Bit-Auflösung rund 4,8 kB/s pro Achsenkombination. Über 24 Stunden sind das mehrere Gigabyte, die weder lokal gespeichert noch drahtlos übertragen werden können, ohne den Akku in Stunden zu leeren.

Lokale Vorverarbeitung reduziert diesen Datenstrom auf das Wesentliche. Typische Methoden sind Moving-Average-Filter, FFT-basierte Merkmalsextraktion oder schwellwertbasierte Event-Trigger. Der Trade-off: Jede Vorverarbeitungsstufe kostet MCU-Rechenzeit und damit Energie. Ein Cortex-M4 mit DSP-Erweiterung kann FFT-Berechnungen effizienter durchführen als ein M0, kostet aber bei 10.000 Einheiten 0,40 bis 0,80 Euro mehr pro Stück.

Ein klassischer Fehler ist die Entscheidung für zu aggressive Datenkompression auf MCU-Ebene, ohne den Informationsverlust vorab zu validieren. Bei medizinischen Wearables kann das zur Folge haben, dass klinisch relevante Ereignisse im gefilterten Signal nicht mehr erkennbar sind, was Zertifizierungsrisiken nach IEC 62304 erzeugt.

Gateway und Edge Computing: was lokal bleibt

Edge Computing bedeutet nicht zwingend einen leistungsstarken Gateway-Prozessor. In vielen IoT-Architekturen reicht ein einfacher BLE-to-IP-Gateway, der Pakete weiterleitet, ohne sie zu verarbeiten. In anderen Szenarien, zum Beispiel bei industriellen Wearables mit Echtzeit-Feedback, muss der Edge-Knoten Inferenz ausführen und innerhalb von unter 50 ms reagieren, bevor die Cloud überhaupt kontaktiert wird.

Die Entscheidung, was lokal bleibt, hängt von drei Faktoren ab: Latenzanforderung, Konnektivitätszuverlässigkeit und Datenschutzvorgaben. Ein Handschuh-Tracking-System in einer Produktionshalle, das Gestensteuerung für Maschinen realisiert, kann keine 200-ms-Roundtrip-Zeit zur Cloud tolerieren. Hier muss die Inferenz lokal auf einem Edge-Prozessor laufen, etwa einem Cortex-A53 mit NPU, was die Stückkosten um 3 bis 8 Euro erhöht, aber die Systemzuverlässigkeit sichert.

Wer Edge-Verarbeitung als optionale Optimierung behandelt und nicht als Architekturanforderung, riskiert, das Gateway-Design in einem späteren Projektstadium komplett überarbeiten zu müssen. Das kostet typischerweise 4 bis 8 Wochen Entwicklungszeit.

Kommunikationsprotokolle und Übertragungstechnologien im Vergleich

Die Wahl des Kommunikationsprotokolls ist eine der folgenreichsten Architekturentscheidungen, weil sie das RF-Design, die Antennenlayout-Anforderungen und den Zertifizierungsaufwand direkt beeinflusst. BLE 5.x eignet sich für kurze Burst-Übertragungen mit niedrigem Energieverbrauch, typischerweise unter 15 mA Spitzenstrom, versagt aber bei hoher Gerätedichte in 2,4-GHz-gesättigten Umgebungen. In einer Fabrikhalle mit 50 aktiven BLE-Geräten steigt die Paketverlustrate messbar, was bei zeitkritischen Anwendungen zu Datenlücken führt.

NB-IoT und LTE-M eignen sich für Geräte ohne lokalen Gateway, die direkt in die Cloud übertragen. NB-IoT bietet Reichweite und niedrigen Ruhestromverbrauch, hat aber eine Latenz von 1 bis 10 Sekunden und unterstützt keine Echtzeit-Anwendungen. LTE-M ist latenzärmer, kostet mehr pro Modul (4 bis 9 Euro Unterschied bei Modulpreisen) und verbraucht im Sendebetrieb mehr Energie.

LoRa ist eine Option für batteriebetriebene Sensoren mit sehr geringer Datenmenge und langen Übertragungsintervallen. Der Fehler, den Teams häufig machen: LoRa in Szenarien einzusetzen, in denen die Duty-Cycle-Begrenzung von 1 % in Europa (gemäß ETSI EN 300 220) die Übertragungsfrequenz auf ein Maß reduziert, das die Anwendungsanforderungen nicht mehr erfüllt. Das ist kein Konfigurationsproblem, sondern ein regulatorisches Limit, das sich nicht umgehen lässt. Informationen zur Hardware-Simulation und zum Schaltungsdesign helfen dabei, diese RF-Anforderungen frühzeitig in das Design zu integrieren.

Cloud-Integration: Datenspeicherung, Verarbeitung und Sicherheit

Cloud-Architekturen für IoT-Produkte folgen typischerweise einem von zwei Mustern: Message-Broker-basiert (MQTT mit AWS IoT Core, Azure IoT Hub oder ähnlichen Diensten) oder REST/HTTP-basiert mit direkter API-Integration. MQTT ist für batteriebetriebene Geräte mit instabiler Verbindung geeignet, weil das Protokoll mit QoS-Leveln arbeitet und Verbindungsunterbrechungen toleriert. HTTP ist einfacher zu debuggen, erzeugt aber pro Übertragung höheren Overhead, was bei sehr häufigen Datenpunkten den Energieverbrauch und die Backendkosten erhöht.

Datensicherheit ist kein Add-on. Bei Produkten mit biometrischen Daten oder Gesundheitsmonitoring greift die DSGVO, und bei Medizinprodukten kommen zusätzlich MDR-Anforderungen sowie IEC 62443 für Cybersecurity ins Spiel. TLS 1.3 auf dem Transportweg ist Mindestanforderung. Geräteauthentifizierung über X.509-Zertifikate oder Hardware Security Module (HSM) auf dem Endgerät erhöht die Sicherheit, kostet aber 0,50 bis 2,00 Euro pro Einheit in der Stückproduktion.

Wer Datensicherheit als letzten Schritt behandelt, riskiert, das gesamte Backend-Design zu überarbeiten, wenn der Zertifizierungsprozess Sicherheitsanforderungen aufdeckt, die in der Architektur nicht vorgesehen waren. Das ist einer der häufigsten Gründe für Verzögerungen von 6 bis 12 Wochen in der Zertifizierungsphase.

Architekturentscheidungen früh treffen – Fehler in der Praxis

Die teuersten Fehler in IoT-Projekten entstehen nicht in der Implementierung, sondern in der Konzeptphase, wenn Architekturentscheidungen aufgeschoben werden. Drei Muster wiederholen sich besonders häufig.

Protokollwahl ohne Energiebudget

Teams wählen ein Kommunikationsprotokoll basierend auf Entwicklungskomfort, nicht auf dem Energiebudget. Wi-Fi ist einfach zu integrieren und gut dokumentiert, zieht aber im Sendebetrieb 150 bis 300 mA. Bei einem Wearable mit 300-mAh-Akku bedeutet das eine Laufzeit von unter 2 Stunden bei aktiver Übertragung. Das wird oft erst beim ersten Prototypentest sichtbar, zu einem Zeitpunkt, an dem das PCB-Layout bereits feststeht.

Edge-Verarbeitung als Nachgedanke

Edge-Logik wird häufig erst dann diskutiert, wenn die Cloud-Latenz in Tests auffällt. Eine nachträgliche Integration eines leistungsfähigeren Edge-Prozessors erfordert in der Regel eine neue PCB-Revision, eine neue Thermalanalyse und unter Umständen eine erneute EMV-Messung. Kosten: 8.000 bis 20.000 Euro, abhängig von der Komplexität des Designs.

Datenschema-Flexibilität überschätzt

Eine verbreitete Annahme ist, dass das Cloud-Datenschema später angepasst werden kann, ohne das Gerät zu beeinflussen. Das stimmt nur, solange das Gerät OTA-Update-fähig ist und die Firmware flexibel genug ist, neue Payload-Strukturen zu unterstützen. Geräte ohne OTA-Mechanismus sitzen mit einem festen Datenschema im Feld, das sich nicht ändern lässt, ohne alle Einheiten physisch zu ersetzen. Firmware-Entwicklung mit OTA-Unterstützung muss deshalb von Anfang an eingeplant werden, nicht als späteres Feature.

Wie Oxeltech IoT-Datenarchitekturen von Anfang an richtig aufbaut

Wir begleiten IoT-Projekte von der ersten Architekturentscheidung bis zur Serienreife. Dabei arbeiten wir nicht mit generischen Referenzdesigns, sondern analysieren die spezifischen Anforderungen jedes Produkts: Energiebudget, Übertragungsfrequenz, regulatorischer Scope und Skalierungsziel. Unsere Leistungen im Kontext der IoT-Datenarchitektur umfassen:

Systemarchitektur und Protokollauswahl mit expliziter Trade-off-Bewertung für Energie, Latenz und Zertifizierungsaufwand
Hardware-Design und PCB-Layout unter Berücksichtigung von RF-Anforderungen, EMV und DFM für die Serienfertigung
Firmware-Entwicklung mit OTA-Update-Mechanismen, lokaler Vorverarbeitung und sicherer Cloud-Anbindung über MQTT oder HTTP
Edge-Computing-Integration für latenzempfindliche Anwendungen in industriellen und medizinischen Umgebungen
Zertifizierungsbegleitung für CE, FCC und MDR, mit frühzeitiger Berücksichtigung regulatorischer Anforderungen im Designprozess

Wer ein IoT-Produkt entwickelt und sicherstellen möchte, dass Architekturentscheidungen nicht zur teuren Revision in der Prototypenphase werden, kann uns direkt kontaktieren. Wir analysieren die Anforderungen und zeigen konkrete Optionen mit Kosten-, Zeit- und Risikobewertung auf.