Diese Checkliste zur IIoT-Konnektivität sammelt die Fragen, die darüber entscheiden, ob ein Projekt zur Werksanbindung in einer Woche live geht oder monatelang stockt. Arbeiten Sie sie durch, bevor das erste Gateway eintrifft, und Sie wissen genau, welche Firewall-Regeln Sie beantragen, welche Protokolle Sie umsetzen müssen, wie Sie Ihre Daten benennen und mit welchem Broker Sie sich verbinden.
Die Checkliste ist in sechs Bereiche gegliedert. Jeder Punkt ist etwas, das Sie überprüfen können, kein vages Prinzip, und zu einigen gibt es einen Befehl, den Sie noch heute ausführen können.
1. Umfang und Verantwortlichkeiten
Die meisten festgefahrenen Projekte scheitern an Menschen, nicht an Paketen. Klären Sie diese Punkte vor jeder Hardwarediskussion.
- Benennen Sie je einen Verantwortlichen auf OT- und auf IT-Seite, jeweils mit der Befugnis, Änderungen in seinem Bereich zu genehmigen.
- Formulieren Sie den ersten Anwendungsfall in einem Satz, zum Beispiel „Live-Zustand und Stückzahl der sechs CNC-Maschinen in Zelle 4 anzeigen“.
- Listen Sie die Maschinen im Umfang auf, ihre Steuerungen und ihre Standorte.
- Einigen Sie sich darauf, was in Phase eins nicht dazugehört. Das Schreiben in SPSen ist das, was am häufigsten verschoben wird.
- Legen Sie fest, wie Sie Erfolg messen: Datenlatenz, Vollständigkeit und ob die Personen, die die Daten angefordert haben, sie tatsächlich nutzen.
Sind diese Antworten unscharf, gibt Ihnen unser Plan für einen IIoT-Proof-of-Concept eine 30-Tage-Struktur, um sie zu schärfen.
2. Checkliste Netzwerkzugang
Ihre Daten brauchen einen Weg von der Maschine zum Broker. Bilden Sie ihn Hop für Hop ab.
- Bestimmen Sie die Netzwerkzone jeder Maschine und jedes Gateways: isoliertes Zellennetz, OT-Netz des Werks, DMZ oder Unternehmensnetz.
- Klären Sie, ob sich das Gateway direkt mit dem Internet, über einen DMZ-Broker oder über einen Proxy verbindet. Unser Leitfaden zur Platzierung von MQTT in einer industriellen DMZ vergleicht diese Optionen.
- Beantragen Sie ausgehendes TCP 8883 (MQTT über TLS) zum Hostnamen des Brokers. Vermeiden Sie Klartext auf 1883 über jede Zonengrenze hinweg.
- Wenn Browser oder Web-Dashboards Live-Daten benötigen, beantragen Sie zusätzlich TCP 8084 (MQTT über Secure WebSocket).
- Prüfen Sie die DNS-Auflösung aus dem Netz des Gateways.
- Fragen Sie nach, ob ein TLS-inspizierender Proxy im Pfad liegt. Falls ja, beantragen Sie eine Ausnahme für den Hostnamen des Brokers.
- Prüfen Sie den Leerlauf-Timeout der Firewall und setzen Sie den MQTT-Keepalive darunter.
- Stellen Sie sicher, dass das Gateway einen NTP-Server erreicht. Falsche Uhrzeiten brechen die TLS-Prüfung und Zeitstempel.
Prüfen Sie den Pfad vom Gateway selbst aus, nicht von Ihrem Laptop:
# Linux gateway: DNS, TCP and TLS in one go
getent hosts broker.connectmq.com
openssl s_client -connect broker.connectmq.com:8883 -servername broker.connectmq.com </dev/null \
| grep -E "subject=|issuer=|Verify return code"
# End-to-end MQTT test with a unique client ID and topic
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i gw-test-$RANDOM -t connectmq/demo/gw-test-$RANDOM/ping -m hello -d
Auf einem Windows-basierten Gateway oder HMI-PC ist das schnelle Gegenstück:
powershell -Command "Test-NetConnection broker.connectmq.com -Port 8883"
Ein Verify return code: 0 (ok) von OpenSSL und ein CONNACK (0) von mosquitto_pub -d bedeuten, dass die Netzwerkseite erledigt ist.
3. Checkliste Protokolle und Datenquellen
Ihre Maschinen sprechen das, womit sie gebaut wurden. Erfassen Sie es.
| Quelle | Typische Schnittstelle | Nötige Umsetzung | Was zu organisieren ist |
|---|---|---|---|
| Moderne SPS | OPC UA, S7, Ethernet/IP | Gateway zu MQTT | Lesender Tag-Zugriff |
| Ältere SPS oder älterer Antrieb | Modbus TCP oder RTU | Gateway zu MQTT | Registertabelle vom Hersteller |
| CNC-Steuerung | MTConnect, OPC UA, Hersteller-API | Adapter zu MQTT | Adapter oder Lizenz des Herstellers |
| Maschine mit Relaislogik | Keine | Zusatzsensoren | Elektrofachkraft für Zangen und Kontakte |
| Neue Sensoren | Natives MQTT, LoRaWAN, WLAN | Oft keine | Zugangsdaten pro Gerät |
- Dokumentieren Sie für jede Quelle Protokoll, IP-Adresse und Port oder serielle Einstellungen.
- Stellen Sie sicher, dass ein Nur-Lese-Zugriff möglich ist, und holen Sie die schriftliche Freigabe des Steuerungsverantwortlichen ein.
- Exportieren Sie die Tag- oder Registerliste und markieren Sie die Tags, die Sie wirklich brauchen. Zwanzig gute Tags schlagen zweitausend ungenutzte.
- Notieren Sie Abfragegrenzen. Manche älteren Steuerungen haben Probleme, wenn sie häufiger als einmal pro Sekunde abgefragt werden.
- Entscheiden Sie, ob das Gateway einfaches MQTT mit JSON oder Sparkplug B verwendet. Beides funktioniert; beides ohne Plan zu mischen, funktioniert nicht.
4. Checkliste Datenmodellierung
Daten, die mit kryptischen Namen ankommen, nutzt niemand.
- Wählen Sie eine Topic-Hierarchie, idealerweise an ISA-95 ausgerichtet: Unternehmen, Standort, Bereich, Linie, Zelle und dann die Maschine. Diese Hierarchie wird zur Topic-Struktur Ihres Unified Namespace (UNS), etwa
acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. - Halten Sie die Benennungsregeln schriftlich fest: Kleinbuchstaben, keine Leerzeichen, Bindestriche oder Unterstriche, einheitliche Einheiten.
- Definieren Sie das Payload-Format, zum Beispiel
{"value": 72.4, "unit": "C", "ts": "2026-10-16T08:00:00Z"}. - Legen Sie fest, welche Topics retained sind (aktueller Zustand) und welche Ereignisse darstellen (Alarme, fertiggestellte Teile).
- Einigen Sie sich auf Report-by-Exception-Regeln: Welche Wertänderung ist eine neue Nachricht wert?
- Reservieren Sie einen eigenen Teilbaum für den Zustand von Gateways und Geräten: Online-Status, letzte Meldung, Firmware-Version.
Der Leitfaden zu ISA-95-MQTT-Topics enthält ausgearbeitete Beispiele, die Sie anpassen können. Ein früh vereinbarter UNS erspart Ihnen spätere Umbenennungen, wenn MES, ERP oder ein Historian dieselben Daten nutzen sollen; wie Sparkplug B hineinpasst, zeigt Sparkplug B und der Unified Namespace.
5. Checkliste Sicherheit
- Jeder Client authentifiziert sich mit eigenem Benutzernamen und Passwort. Keine gemeinsamen Zugangsdaten über mehrere Gateways.
- TLS auf jeder Verbindung, die eine Zonengrenze quert, im Sinne des Zonen-und-Conduit-Modells von IEC 62443.
- Gateways veröffentlichen in Phase eins ausschließlich nach oben. Jeder Befehlspfad wird ausdrücklich entworfen und geprüft.
- Zugangsdaten werden auf dem Gateway in einer geschützten Datei gespeichert, nicht fest in Skripten codiert, die in der Versionsverwaltung landen.
- Eine Last-Will-Nachricht markiert jedes Gateway als offline, wenn es die Verbindung unerwartet verliert.
- Es gibt einen Prozess, um Zugangsdaten zu widerrufen, wenn ein Gateway ersetzt oder gestohlen wird.
- Nichts Sensibles wird jemals auf einem öffentlichen MQTT-Broker veröffentlicht; er ist nur für Tests und Prototypen gedacht.
Betrachten Sie diese Punkte als Mindestanforderungen: Ein Gateway, das einen davon nicht erfüllt, sollte nicht angebunden werden, auch nicht für ein Pilotprojekt.
6. Checkliste Broker-Auswahl
Der Broker ist die Drehscheibe, von der alles andere abhängt. Prüfen Sie ihn gegen die Anforderungen Ihres Werks, nicht nur gegen eine Funktionsliste.
- Unterstützt MQTT 3.1.1 und 5.0, damit sich ältere Gateways und moderne Clients verbinden können.
- Bietet TLS auf 8883 und Secure WebSocket für Browser-Dashboards.
- Bewältigt Ihre Verbindungsanzahl und Nachrichtengrößen, mit Reserve für Wachstum.
- Unterstützt mindestens QoS 1 und QoS 2, falls ein Konsument Exactly-once-Zustellung braucht.
- Unterstützt Retained Messages und persistente Sessions, damit der Zustand Reconnects übersteht.
- Versteht industrielle Payloads wie Sparkplug B oder lässt Sie diese zumindest einsehen.
- Bietet Transparenz: Wer ist verbunden, welche Topics sind aktiv, und Alarme bei Schwellwerten.
- Hat eine klare Antwort darauf, wer ihn patcht und überwacht. Ein selbst betriebener Broker ist ein weiterer Server, für den das OT-Team verantwortlich ist.
Einen tieferen Vergleich finden Sie unter wie Sie einen IoT-MQTT-Broker auswählen und in unserem Leitfaden zum Modell Cloud-MQTT-Broker. Wie all diese Bausteine in einem Werk zusammenspielen, lesen Sie im Leitfaden zu Industrial IoT mit MQTT.
Wie ConnectMQ zur Checkliste passt
ConnectMQ ist ein verwalteter MQTT-Broker, der mit Blick auf Werksanbindungen entwickelt wurde. Er unterstützt MQTT 3.1.1 und 5.0 auf TCP 1883, TLS 8883, WebSocket 8083 und Secure WebSocket 8084, verwendet ein Let's-Encrypt-Zertifikat, dem Standard-CA-Speicher bereits vertrauen, und bindet Client-IDs an ausgestellte Zugangsdaten. Er erkennt ISA-95- und UNS-Topics, dekodiert Sparkplug-B-Payloads und kann Sparkplug-Daten in lesbare ISA-95-Topics erneut veröffentlichen. Das Portal enthält einen MQTT-Client im Browser, einen Live-Topic-Explorer und Schwellwert-Alarmregeln, wodurch sich die Punkte der Abschnitte 4 und 6 bei der Inbetriebnahme leicht überprüfen lassen.
Starten Sie mit ConnectMQ
Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte. In wenigen Minuten haben Sie Zugangsdaten, sodass Sie die Netzwerktests aus Abschnitt 2 gegen Ihren eigenen ConnectMQ-Endpunkt ausführen und die erste Hälfte dieser Checkliste noch heute abhaken können.
Häufig gestellte Fragen
Welche Ports braucht ein IIoT-Gateway, um einen MQTT-Broker zu erreichen?
Meist nur ausgehendes TCP 8883 für MQTT über TLS. Ergänzen Sie TCP 8084, wenn sich Browser-Dashboards über Secure WebSocket verbinden. Eingehende Ports ins Werk sind nicht nötig.
Wer sollte für ein Projekt zur IIoT-Konnektivität verantwortlich sein?
OT und IT gemeinsam. Benennen Sie auf jeder Seite einen Verantwortlichen mit der Befugnis, Änderungen zu genehmigen, denn die meisten Verzögerungen entstehen durch unklare Freigaben, nicht durch technische Probleme.
Sollte ich für Werksdaten Sparkplug B oder JSON verwenden?
Beides funktioniert. Sparkplug B ergänzt ein striktes Session- und Zustandsmodell, das SCADA-Tools verstehen, während JSON mit einem ISA-95-Topic-Baum leichter zu lesen und zu integrieren ist. Wählen Sie pro Datenquelle eines und dokumentieren Sie die Entscheidung; beide können denselben UNS speisen.
Wie teste ich die Konnektivität, bevor ich Gateway-Software installiere?
Führen Sie DNS-, OpenSSL- und mosquitto_pub-Tests von einem Rechner in derselben Netzwerkzone wie das künftige Gateway aus. Gelingen alle drei gegen Port 8883, ist der Netzwerkpfad bereit.
