IoT-Systemarchitektur: Schichten, Anforderungen und typische Fehler

Warum die Architektur wichtiger ist als die Sensorwahl

Viele IoT-Projekte beginnen mit der Frage, welcher Sensor gekauft werden soll. Ob ein System auch nach Jahren noch Nutzen stiftet, entscheidet jedoch die Architektur: Wie gelangen Daten von der Anlage zur Plattform, wo werden sie gespeichert, wer hat Zugriff, und wie werden sie mit realen Geschäftsprozessen wie Instandhaltung oder Produktionsplanung verknüpft?

Eine tragfähige Architektur erlaubt es, Sensoren oder Funktechnik später auszutauschen, ohne das Gesamtsystem neu aufzubauen. Eine schwache Architektur endet dagegen meist in Insellösungen mit jeweils eigenem Dashboard, eigener Datenbank und eigener Logik.

Ein Schichtenmodell als Referenz

Die Aufteilung in voneinander unabhängige Schichten schafft eine gemeinsame Sprache zwischen Betrieb, IT und Geschäftsleitung. Das folgende Modell ist ein verbreiteter Rahmen für Industrial IoT:

1. Geräte und Sensorik

Sensoren für Temperatur, Schwingung, Strom, Druck und Füllstand, Zähler sowie Steuerungen und Maschinen, die bereits Daten liefern. Entscheidend sind Messgenauigkeit und Abtastrate, Energieversorgung und Batterielebensdauer, Schutzart und Montagebedingungen. Beim Retrofit von Bestandsanlagen spielt sich ein großer Teil der Arbeit in dieser Schicht ab, mit nachgerüsteter Sensorik, die nicht in die Maschinensteuerung eingreift.

2. Konnektivität

Die Wahl richtet sich nach Reichweite, Datenvolumen, Energiebudget und vorhandener Infrastruktur: LoRaWAN für batteriebetriebene Sensoren mit kleinen Nutzdaten, NB-IoT oder LTE-M für flächige Abdeckung, WLAN und Industrial Ethernet für hohe Datenraten, Modbus oder OPC UA auf Maschinenebene. Die Architektur sollte netzneutral bleiben, damit kein einzelner Netzbetreiber zur harten Abhängigkeit wird.

3. Edge und Gateway

Gateways übersetzen Feldbusprotokolle in IP-basierte Protokolle. Eine Edge-Schicht kann Daten filtern und verdichten, bei Netzausfällen zwischenspeichern und einfache Logik wie lokale Alarme unabhängig vom zentralen Server ausführen.

4. Datenaufnahme und Messaging

Publish/Subscribe-Protokolle wie MQTT entkoppeln Datenquellen und Verbraucher. Topic-Struktur, QoS-Stufen, Geräteauthentifizierung und das Verhalten beim Wiederverbinden müssen hier sorgfältig festgelegt werden, denn nach dem Rollout Hunderter Geräte sind Änderungen mühsam.

5. Plattform und Speicherung

Telemetrie besteht aus Zeitreihen, und Zeitreihendatenbanken bewältigen Bereichsabfragen und Aggregationen deutlich effizienter als allgemeine relationale Schemata. Plattformen wie ThingsBoard bündeln Geräteverwaltung, Anlagenmodell, Regel-Engine und Dashboards. Eine Aufbewahrungsrichtlinie für Daten gehört von Beginn an dazu.

6. Analyse

Das Spektrum reicht von einfachen Schwellwertregeln über Trend- und Anomalieerkennung bis zu Modellen für vorausschauende Instandhaltung. Sinnvoll ist es, mit nachvollziehbaren Regeln zu beginnen und komplexere Verfahren erst dann einzusetzen, wenn ausreichend saubere Daten vorliegen.

7. Anwendungen und Integration

Nutzen entsteht, wenn Daten zu Entscheidungen und Maßnahmen führen: automatische Instandhaltungsaufträge im Instandhaltungssystem, Energieverbräuche im ERP oder der Linienstatus für die Schichtleitung. Diese Anbindungen erfolgen über REST-Schnittstellen, Webhooks oder Werkzeuge zur Workflow-Automatisierung.

Datenmodell, Benennung und Schnittstellen

Die Schichten greifen nur dann sauber ineinander, wenn sie ein gemeinsames Datenmodell nutzen. Praktisch heißt das, früh einige Konventionen festzulegen, an die sich jedes Gerät, jedes Gateway und jede Schnittstelle hält:

• Anlagenhierarchie: etwa Standort, Bereich, Linie, Maschine und Messstelle. Telemetrie wird einer Position in dieser Hierarchie zugeordnet und nicht nur einer Seriennummer, damit ein getauschter Sensor die bestehende Historie fortschreibt.
• Benennung und Einheiten: ein einheitliches Schema für Messwertschlüssel (zum Beispiel motor_temp_c statt herstellerspezifischer Bezeichnungen), Einheiten und Skalierung dokumentiert und bereits am Edge oder im Decoder angewendet, nicht in jedem Dashboard einzeln.
• Zeitstempel: Geräte- oder Gateway-Zeit in UTC und eine klare Regel für verspätet eintreffende, zwischengespeicherte Daten.
• Metadaten: Einbaudatum, Kalibrierstatus, Firmware-Stand und verantwortliche Person als Attribute, damit das System auch Fragen über sich selbst beantworten kann.

Die Schnittstellen zwischen den Schichten sollten auf offenen, dokumentierten Formaten beruhen, etwa JSON über MQTT oder HTTP sowie OPC UA, wo Maschinen es bereits anbieten. Ein schlanker Decodierschritt überführt herstellerspezifische Nutzdaten in das gemeinsame Modell. Wechselt ein Sensortyp, muss nur der Decoder angepasst werden, nicht Plattform und Anwendungen.

Nichtfunktionale Anforderungen

Die meisten ernsten Probleme im Betrieb entstehen nicht durch fehlende Funktionen, sondern durch vernachlässigte nichtfunktionale Anforderungen:

• Sicherheit: eindeutige Identität je Gerät, Verschlüsselung bei der Übertragung, Trennung von OT- und IT-Netz sowie Zugriffsrechte nach dem Minimalprinzip.
• Skalierbarkeit: Ein System für zehn Geräte sollte ohne Neuentwurf auf Hunderte Geräte und mehrere Standorte wachsen können.
• Batterielebensdauer: Sendeintervall, Funktechnik und Empfangsqualität bestimmen direkt den Wartungsaufwand vor Ort.
• Wartbarkeit: Dokumentation, einheitliche Benennung, Überwachung des Systems selbst (etwa Geräte, die keine Daten mehr senden) und ein erprobtes Sicherungskonzept.
• OTA-Updates: sichere Firmware-Aktualisierung ohne Einsatz vor Ort, besonders wichtig an abgelegenen Standorten und im Bergbau.
• Datenhoheit: Wem gehören die Daten, wo liegen sie, und lassen sie sich bei einem Plattformwechsel in einem offenen Format exportieren?

Cloud, On-Premises oder hybrid

Der Betriebsort der Plattform gehört zu den grundlegenden Architekturentscheidungen. Die Tabelle zeigt einen qualitativen Vergleich:

Kriterium	Cloud	On-Premises	Hybrid
Inbetriebnahme	Schnell	Mittel, Hardware und Konfiguration nötig	Mittel
Kontrolle über Daten	Abhängig von Anbieter und Vertrag	Vollständig im Unternehmen	Sensible Daten lokal, übrige in der Cloud
Abhängigkeit vom Internet	Hoch	Gering	Lokaler Betrieb läuft bei Ausfall weiter
Betriebsaufwand für das eigene Team	Gering	Hoch	Mittel
Typischer Einsatz	Pilotprojekte, verteilte kleine Standorte	Strenge Sicherheits- oder Regulierungsvorgaben	Viele Industrieunternehmen mit mehreren Standorten

Unabhängig vom gewählten Modell sollten die Schnittstellen zwischen den Schichten gleich bleiben, damit ein späterer Wechsel keine Änderungen auf Geräteebene erfordert.

Typische Architekturfehler

1. Mit dem Dashboard beginnen: Visualisierungen vor Datenmodell und Namenskonvention führen zu wiederholter Nacharbeit.
2. Herstellerbindung: Proprietäre Formate und fehlende offene Schnittstellen erschweren den späteren Wechsel von Sensoren oder Plattform.
3. Netzausfälle ignorieren: Ohne Zwischenspeicher am Edge gehen Daten aus Ausfallzeiten verloren.
4. Sicherheit als letzter Schritt: Sicherheit in ein laufendes System nachzurüsten ist erheblich schwieriger, als sie von Anfang an einzuplanen.
5. Keine Verantwortlichkeit im Betrieb: Wenn niemand auf Alarme reagiert, bleibt auch ein gut gebautes System ungenutzt.
6. Alles erfassen, ohne Ziel: Daten ohne konkrete Fragestellung erzeugen nur Speicherkosten und Komplexität.

Fazit

Eine Industrial-IoT-Architektur sollte vom Geschäftsziel und vom betrieblichen Prozess ausgehen und die Schichten über klare, standardbasierte Schnittstellen verbinden. Nichtfunktionale Anforderungen, vor allem Sicherheit, Datenhoheit und Wartbarkeit, gehören vom ersten Tag an in den Entwurf. Mehr zum Vorgehen finden Sie unter Industrial IoT und Industrial IoT Beratung; für die Rahmenbedingungen Ihres eigenen Projekts nutzen Sie die Kontaktseite.