Zum Hauptinhalt springen
+49 721 9654-724

IIoT-Plattform: Architektur, Funktionen und Auswahlkriterien

Eine IIoT-Plattform verbindet Maschinen, Steuerungen, Sensoren und vorhandene IT-Systeme zu einer wiederverwendbaren Datenbasis. Sie erfasst industrielle Daten, versieht sie mit fachlichem Kontext und stellt sie für Monitoring, Produktionsanalyse, Anwendungen und KI bereit.

Der entscheidende Unterschied zu einer einzelnen Punktlösung: Eine Plattform löst Konnektivität, Datenmodell, Betrieb und Zugriff nicht für jeden Anwendungsfall neu. Neue Maschinen, Linien und Anwendungen können auf gemeinsamen technischen und fachlichen Strukturen aufbauen.

Was bedeutet IIoT?​

IIoT steht für Industrial Internet of Things. Gemeint ist die Vernetzung industrieller Anlagen und Systeme, damit Daten sicher erfasst, verarbeitet und genutzt werden können.

Im Unterschied zu vielen Consumer-IoT-Anwendungen gelten in der Industrie besondere Anforderungen:

  • lange Lebenszyklen und heterogene Steuerungsgenerationen;
  • segmentierte OT-Netze und restriktive Firewall-Regeln;
  • hohe Anforderungen an Verfügbarkeit und nachvollziehbare Änderungen;
  • unterschiedliche Protokolle und herstellerspezifische Datenmodelle;
  • Edge- und On-Premise-Betrieb aus Latenz-, Sicherheits- oder Souveränitätsgründen;
  • schrittweise Rollouts über Maschinen, Linien und Standorte.

Eine IIoT-Plattform muss deshalb OT-Konnektivität mit Datenmanagement und einem produktiv betreibbaren Anwendungskonzept verbinden.

Referenzarchitektur einer IIoT-Plattform​

Eine tragfähige Architektur besteht typischerweise aus mehreren Schichten.

1. Datenquellen​

Zu den Quellen gehören SPS, Sensoren, Maschinensteuerungen, Gateways, Prüfstände, Dateien, Datenbanken sowie MES-, ERP- oder Qualitätssysteme. Sie liefern Live-Signale, Ereignisse, Stammdaten und fachlichen Kontext.

2. Konnektivität und Edge​

Adapter verbinden Protokolle wie OPC UA, Siemens S7, MQTT, Modbus oder REST. Eine Edge-Komponente kann Daten nahe an der Anlage erfassen, vorverarbeiten und puffern, wenn zentrale Systeme zeitweise nicht erreichbar sind.

3. Messaging und Datenströme​

Eine Streaming- oder Messaging-Schicht transportiert Ereignisse zwischen Quellen, Verarbeitung und Anwendungen. Ein Unified Namespace kann Namensräume und Topics vereinheitlichen, ersetzt aber kein fachliches Datenmodell.

4. Verarbeitung und Datenqualität​

Rohsignale werden gefiltert, harmonisiert und in nutzbare Ereignisse überführt. Dazu gehören Zeitstempelkorrektur, Einheitenumrechnung, Zustandsbildung, Plausibilitätsprüfung und die Ableitung fachlicher Protokolle.

5. Kontext- und Asset-Modell​

Daten werden Standorten, Linien, Maschinen, Stationen, Produkten oder Prozessen zugeordnet. Erst dieser Kontext ermöglicht wiederverwendbare Abfragen und Vergleiche über unterschiedliche Datenquellen hinweg.

6. Historisierung​

Zeitreihen, Ereignisse und fachliche Protokolle werden entsprechend ihres Nutzungszwecks gespeichert. Aufbewahrungsdauer, Ereignisrate, Abfrageverhalten und Kosten bestimmen die Speicherarchitektur.

7. Zugriff und Anwendungen​

Dashboards, Produktionsanalysen, Benachrichtigungen, Data-Science-Werkzeuge und individuelle Anwendungen greifen über APIs oder Ereignisströme auf dieselbe Datenbasis zu.

8. Betrieb und Governance​

Rollen, Rechte, Mandanten, Konfiguration, Monitoring, Updates, Backups und Auditierbarkeit machen aus einer technischen Installation eine produktiv nutzbare Plattform.

IIoT-Plattform und benachbarte Systeme​

Eine IIoT-Plattform ersetzt nicht automatisch alle vorhandenen Systeme.

SystemPrimäre AufgabeVerhältnis zur IIoT-Plattform
SPS/SteuerungMaschine in Echtzeit steuernLiefert Signale und Ereignisse; die Plattform greift nicht unkontrolliert in die Steuerung ein
SCADA/HMIAnlage bedienen und überwachenBleibt operative Bedienebene; Daten können zusätzlich plattformweit genutzt werden
HistorianProzesswerte langfristig speichernKann Datenquelle oder Teil der Speicherarchitektur sein
MESAufträge und Produktion ausführenLiefert Auftrags- und Produktkontext; erhält bei Bedarf Maschinenereignisse zurück
ERPUnternehmensressourcen planenErgänzt Stammdaten, Aufträge und übergeordnete Geschäftsprozesse
Data LakeGroße Datenmengen zentral speichernKann langfristige Speicherung bereitstellen, löst aber nicht automatisch OT-Anbindung und Fachkontext
BI-PlattformBerichte und Unternehmenskennzahlen erstellenNutzt aufbereitete Produktionsdaten für Reporting und Managementsichten

Die genaue Grenze hängt von der vorhandenen Architektur ab. Entscheidend sind klare Verantwortlichkeiten und stabile Schnittstellen.

Zentrale Funktionen​

Industrielle Konnektivität​

Eine Plattform sollte die tatsächlich vorhandenen Datenquellen abdecken und Verbindungen überwachen können. Neben der Protokollliste sind Wiederverwendbarkeit, Fehlerbehandlung, Puffern und Remote-Konfiguration relevant.

Wiederverwendbare Datenmodelle​

Ein Connector allein skaliert noch nicht. Daten müssen über Assets, Metadaten und fachliche Protokolle so strukturiert werden, dass dieselbe Analyse auf vergleichbare Maschinen angewendet werden kann.

Live- und historische Verarbeitung​

Operative Überwachung benötigt Live-Datenströme; Ursachenanalysen benötigen Historie. Beide Perspektiven sollten dieselben Begriffe, Einheiten und Anlagenkontexte verwenden.

Offene Schnittstellen​

APIs, Messaging und exportierbare Daten reduzieren neue Datensilos. Anwendungen sollten Daten kontrolliert nutzen können, ohne von internen Plattformdetails abhängig zu sein.

Sicherheit und Governance​

Benutzer, Rollen, technische Dienste und Standorte benötigen passende Rechte. Dazu kommen verschlüsselte Kommunikation, Secrets-Management, Protokollierung und geregelte Updateprozesse.

Skalierbarer Betrieb​

Die Plattform sollte mit zusätzlichen Datenquellen, Ereignisraten, Nutzern und Standorten wachsen können. Skalierbarkeit betrifft nicht nur Rechenleistung, sondern auch Konfiguration, Rollout und Support.

Edge, On-Premise, Cloud oder Hybrid?​

Edge​

Edge-Komponenten laufen nahe an Maschine oder Linie. Sie eignen sich für lokale Protokolle, geringe Latenz, Netzsegmentierung, Vorverarbeitung und kontrollierte Datenweitergabe.

On-Premise​

Eine lokale Plattforminstanz hält Verarbeitung und Speicherung im eigenen Netzwerk. Das erleichtert Datensouveränität und Integration, verlagert aber Betrieb, Updates und Kapazitätsplanung stärker in die eigene Organisation.

Cloud​

Cloud-Betrieb ermöglicht zentrale Bereitstellung und elastische Ressourcen. Er setzt jedoch geeignete Konnektivität, Sicherheitsfreigaben und klare Regeln für Datenübertragung und Ausfallverhalten voraus.

Hybrid und Multi-Site​

In vielen Unternehmen werden Daten lokal erfasst und ausgewählte Informationen zentral bereitgestellt. Ein hybrides Modell muss Verantwortlichkeiten, Synchronisation, Offline-Verhalten und zentrale Governance ausdrücklich definieren.

Auswahlkriterien für eine IIoT-Plattform​

Fachliche Passung​

  • Welche konkreten Anwendungen sollen zuerst entstehen?
  • Werden Live-Monitoring, Historie, Produktionsanalyse oder eigene Anwendungen benötigt?
  • Unterstützt das Datenmodell Anlagen-, Produkt- und Prozesskontext?

Technische Integration​

  • Sind die vorhandenen Steuerungen, Protokolle, Broker und Datenbanken anbindbar?
  • Lassen sich MES, ERP, Historian und BI über dokumentierte Schnittstellen integrieren?
  • Können eigene Adapter, Transformationen und Anwendungen ergänzt werden?

Betrieb und Sicherheit​

  • Welche Deployment-Modelle werden unterstützt?
  • Wie funktionieren Rollen, Mandanten, Updates, Backups und Monitoring?
  • Wie verhält sich die Plattform bei Netzunterbrechungen oder fehlerhaften Datenquellen?

Skalierung und Wiederverwendung​

  • Lassen sich Verbindungen, Datenmodelle und Dashboards als Templates übertragen?
  • Wie werden Konfigurationen über Linien und Standorte verwaltet?
  • Kann die Architektur Datenmengen und Abfragen nachvollziehbar dimensionieren?

Offenheit und wirtschaftliche Tragfähigkeit​

  • Bleiben Daten über offene Formate und Schnittstellen zugänglich?
  • Welche Komponenten sind Open Source, proprietär oder austauschbar?
  • Wie setzen sich Lizenz-, Infrastruktur-, Einführungs- und Betriebskosten zusammen?
  • Welche internen Fähigkeiten sind für den langfristigen Betrieb nötig?

Open Source und Datensouveränität​

Open Source kann Transparenz, Erweiterbarkeit und technologische Unabhängigkeit verbessern. Entscheidend ist jedoch nicht allein die Lizenz. Auch Datenformate, APIs, Exportmöglichkeiten, Betriebswissen und die Austauschbarkeit einzelner Komponenten bestimmen die tatsächliche Souveränität.

Für die Bewertung sind deshalb folgende Fragen hilfreich:

  • Kann das Unternehmen auf seine Roh- und Kontextdaten vollständig zugreifen?
  • Sind Schnittstellen dokumentiert und ohne proprietäre Umwege nutzbar?
  • Kann die Plattform in der eigenen Zielumgebung betrieben werden?
  • Lassen sich eigene Komponenten entwickeln und unabhängig testen?
  • Gibt es einen nachvollziehbaren Weg für Updates, Support und Migration?

Schrittweise Einführung​

1. Ergebnis statt Plattformumfang definieren​

Starten Sie mit einer konkreten Datenquelle und einem überprüfbaren Ergebnis, beispielsweise einer Zustandsübersicht oder Zykluszeitanalyse.

2. Architektur- und Betriebsgrenzen klären​

Legen Sie fest, welche Komponenten im OT-Netz, am Edge, zentral oder in der Cloud laufen und wer sie verantwortet.

3. Datenquelle produktionsnah anbinden​

Prüfen Sie Verbindungsstabilität, Zeitstempel, Datenrate, Schema und Verhalten bei Unterbrechungen unter realen Bedingungen.

4. Kontextmodell aufbauen​

Ordnen Sie Signale einer Anlage zu und definieren Sie Einheiten, Semantik sowie fachliche Modelle. Diese Strukturen sollten auf weitere Maschinen übertragbar sein.

5. Erste Anwendung bereitstellen​

Erzeugen Sie ein nutzbares Ergebnis für die spätere Zielgruppe. So werden Anforderungen an Datenqualität, Zugriff und Bedienung früh sichtbar.

6. Betrieb absichern​

Ergänzen Sie Monitoring, Rollen, Backups, Updateprozesse und Verantwortlichkeiten, bevor die Plattform auf weitere kritische Bereiche ausgerollt wird.

7. Templates und Governance skalieren​

Übertragen Sie bewährte Konnektoren, Datenmodelle und Anwendungen kontrolliert auf weitere Assets und Standorte.

Häufige Fehler​

  • Eine Plattform ohne klaren ersten Nutzen einführen: Architekturarbeit wächst, bevor ein Ergebnis bewertet werden kann.
  • Konnektivität mit Datenmodellierung verwechseln: Übertragene Signale sind noch keine verständliche Datenbasis.
  • Für jeden Anwendungsfall neue Pipelines bauen: Dadurch entstehen trotz Plattform neue Silos.
  • Nur den Pilot betrachten: Security, Monitoring, Updates und Rollout werden zu spät berücksichtigt.
  • Cloud oder On-Premise dogmatisch wählen: Das Betriebsmodell muss zu Netzen, Latenz, Governance und Organisation passen.
  • Nur Lizenzkosten vergleichen: Integration, Datenmodellierung und laufender Betrieb bestimmen einen großen Teil der Gesamtkosten.

Kompakte Checkliste​

  • Sind erster Anwendungsfall und Erfolgskriterium definiert?
  • Sind alle relevanten Datenquellen und Protokolle bekannt?
  • Gibt es ein Asset-, Metadaten- und Berechtigungskonzept?
  • Sind Edge-, On-Premise- und Cloud-Verantwortlichkeiten geklärt?
  • Können Daten und Anwendungen über offene Schnittstellen integriert werden?
  • Lassen sich Konfigurationen auf weitere Maschinen übertragen?
  • Sind Monitoring, Backups, Updates und Support eingeplant?
  • Bleiben Datenzugriff und Migrationsfähigkeit langfristig erhalten?

Der Bytefabrik IoT Data Hub setzt diese Architekturprinzipien als offene IIoT-Datenplattform um. Weitere Vertiefungen finden Sie unter IIoT-Infrastruktur aufbauen und betreiben und im Leitfaden zu Architektur, Funktionen und Einsatz von Apache StreamPipes.