Die Anbindung einer SPS an die Cloud ist inzwischen eine Routineanforderung: Die Instandhaltung will Zustandsdaten aus der Ferne, das Management will OEE über alle Standorte, und Datenteams wollen saubere Zeitreihen für Analysen. Gerade im Mittelstand ist die SPS-Cloud-Anbindung oft der erste konkrete Schritt eines Industrie-4.0-Programms. Dieser Leitfaden vergleicht die drei Architekturen, die in Werken tatsächlich funktionieren, natives SPS-MQTT, Edge-Gateways und SCADA-basierte Weiterleitung, und geht die Sicherheits- und Zuverlässigkeitsentscheidungen hinter jeder davon durch. Am Ende haben Sie eine Checkliste, um ein Design für Ihren eigenen Standort zu wählen.
Warum MQTT die übliche Brücke ist
SPSen sprechen Feldprotokolle, die für deterministische, lokale Kommunikation entworfen wurden: PROFINET, EtherNet/IP, Modbus, S7-Kommunikation, ADS. Keines davon wurde dafür gebaut, das Internet zu überqueren. Cloud-Anwendungen dagegen wollen Ereignisströme über verschlüsselte, authentifizierte Verbindungen, die Firewalls passieren.
MQTT passt dank dreier Eigenschaften dazwischen:
- Nur ausgehende Verbindungen. Die Werksseite öffnet eine TLS-Verbindung zum Broker. Nichts in der Cloud muss ins Werk hineingreifen, es werden also keine eingehenden Firewall-Ports geöffnet.
- Entkopplung durch Publish/Subscribe. Die SPS-Seite veröffentlicht einmal; Dashboards, Historians, Analysen und Alarmierung abonnieren unabhängig voneinander. Ein zusätzlicher Konsument berührt das Werk nicht.
- Schlank und tolerant gegenüber schlechten Verbindungen. Kleine Header, Keep Alive, QoS-Stufen, Retained Messages und persistente Sitzungen kommen gut mit Mobilfunk- oder überlasteten WAN-Strecken zurecht.
Wenn das Broker-Konzept neu für Sie ist, lesen Sie zuerst, was ein MQTT-Broker macht, bevor Sie eine Architektur wählen.
Architektur 1: Natives MQTT in der SPS
Die Steuerung selbst betreibt einen MQTT-Client und verbindet sich mit dem Broker. Siemens bietet eine Bibliothek für S7-1200 und S7-1500, CODESYS hat eine MQTT-Client-Bibliothek, und Beckhoff TwinCAT hat IoT-Funktionen; Schritt-für-Schritt-Anleitungen finden Sie im Siemens-S7-MQTT-Tutorial und seinen Geschwisterartikeln.
Stärken: keine zusätzliche Hardware, minimale Latenz, Payloads werden von der Person definiert, die den Prozess am besten kennt.
Schwächen: Netzwerk- und Zertifikatscode liegt nun im Steuerungsprogramm, jede Änderung bedeutet einen SPS-Download, Store-and-Forward ist durch den Speicher der Steuerung begrenzt, und die SPS braucht eine Route ins Internet oder zu einem Broker in der DMZ, wogegen sich viele Sicherheitsteams sträuben.
Passt, wenn: ein Maschinenbauer vernetzte Maschinen ausliefert oder eine Handvoll Steuerungen einige Dutzend Signale benötigt und zusätzliche Hardware unpraktisch ist.
Architektur 2: Edge-Gateway
Ein Gateway im Steuerungsnetz liest SPSen über ihre nativen Protokolle und veröffentlicht nach oben per MQTT. Das kann ein Industrie-PC mit einem kommerziellen Konnektivitätsserver sein, ein Container auf einer Edge-Plattform, Node-RED oder ein kurzer Python-Dienst. Der Leitfaden zum IIoT-Edge-Gateway behandelt die Hardware- und Softwareauswahl ausführlich.
Stärken: SPS-Programme bleiben unangetastet, ein Gateway bedient viele Steuerungen und Marken, ein festplattengestützter Puffer übersteht WAN-Ausfälle, und Payload-Formatierung, Totbänder und Sparkplug-B-Kodierung finden dort statt, wo Software-Werkzeuge gut sind.
Schwächen: ein weiteres Gerät zum Patchen, Überwachen und Sichern; das Gateway wird zum kritischen Knoten; und native Protokollzugriffe müssen auf den SPSen aktiviert werden, was manchmal steuerungsseitige Schutzmaßnahmen wie deaktiviertes PUT/GET schwächt.
Passt, wenn: Sie eine Linie, ein Werk oder eine gemischte Flotte anbinden. Für die meisten Brownfield-Standorte ist das die Standardwahl.
Architektur 3: SCADA-basierte Weiterleitung
Der vorhandene SCADA- oder HMI-Server pollt bereits jede SPS. Ein MQTT-Modul oder Skript auf diesem Server leitet ausgewählte Tags an den Broker weiter, oft als Sparkplug B. Ignition ist ein gängiges Beispiel; siehe Ignition mit MQTT.
Stärken: nutzt die vorhandene Tag-Datenbank, Alarmkonfiguration und Benennung; keine neuen SPS-Verbindungen; ein zentraler Ort, um zu steuern, was das Werk verlässt.
Schwächen: Cloud-Daten hängen nun von Verfügbarkeit und Lizenzierung des SCADA ab; SCADA-Tag-Namen passen eventuell nicht zum unternehmensweiten Namensstandard; und der SCADA-Server, typischerweise ein hochwertiges OT-Asset, hat nun einen ausgehenden Weg ins Internet.
Passt, wenn: das SCADA die relevanten Anlagen bereits abdeckt und das SCADA-Team die Integration verantwortet.
Architekturen für SPS in die Cloud im direkten Vergleich
| Kriterium | Natives SPS-MQTT | Edge-Gateway | SCADA-Weiterleitung |
|---|---|---|---|
| Zusätzliche Hardware | Keine | Gateway pro Standort oder Linie | Keine |
| Änderungen am SPS-Programm | Ja | Nein | Nein |
| SPSen mehrerer Hersteller | Eine Implementierung pro Hersteller | Ja, über Treiber | Ja, sofern das SCADA sie unterstützt |
| Store-and-Forward | Begrenzt | Stark (Festplattenpuffer) | Abhängig vom Modul |
| Payload-Flexibilität | Durch String-Verarbeitung der SPS begrenzt | Hoch | Mittel bis hoch |
| Änderungsmanagement | SPS-Download | Deployment der Gateway-Konfiguration | Änderung am SCADA-Projekt |
| Abhängigkeitsrisiko | Netzwerkpfad jeder SPS | Verfügbarkeit des Gateways | Verfügbarkeit des SCADA |
| Typischer Verantwortlicher | Steuerungstechniker | OT- oder IT/OT-Team | SCADA-Team |
Viele Werke mischen sie am Ende: Maschinenbauer liefern nativ vernetzte Anlagen, ältere Linien laufen über Gateways, und das SCADA leitet seine Alarm- und Produktionszusammenfassungen weiter.
Sicherheitsmuster für SPS in die Cloud
An der Sicherheit entscheidet sich, ob solche Projekte gelingen oder stocken. Im DACH-Raum orientieren sich OT-Sicherheitsteams dabei meist an IEC 62443, und Regelwerke wie NIS2 und der EU Cyber Resilience Act erhöhen den Druck zusätzlich. Die folgenden Muster gelten unabhängig von der Architektur.
- Nur ausgehend. Geräte im Werk bauen TLS-Verbindungen zum Broker auf. Keine eingehende Portweiterleitung, kein VPN in Steuerungsnetze zur Datenerfassung.
- Nach Ebenen segmentieren. Halten Sie SPSen in der Steuerungszone. Platzieren Sie Gateways an der Grenze oder in einer industriellen DMZ und erlauben Sie nur dem Gateway, den Broker zu erreichen. Das Muster MQTT-DMZ erklärt die Platzierung des Brokers zwischen OT und IT.
- TLS überall außerhalb der Zelle. Verwenden Sie Port 8883 mit Zertifikatsvalidierung; deaktivieren Sie niemals die Prüfung, nur damit eine Verbindung funktioniert.
- Eine Identität pro Publisher. Jede SPS und jedes Gateway erhält eigenen Benutzernamen, eigenes Passwort und eigene Client-ID, damit ein kompromittiertes Gerät gesperrt werden kann, ohne andere zu berühren.
- Standardmäßig nur lesend. Behandeln Sie Schreibzugriffe aus der Cloud auf die SPS als separates Projekt mit Allow-Lists, Bereichsprüfungen, SPS-seitigen Verriegelungen und einem Audit-Trail.
- Geheimnisse aus Projekten heraushalten. Committen Sie keine Broker-Passwörter in SPS-Projekte oder Gateway-Repositories, die über Teams hinweg geteilt werden.
- Auf Missbrauch achten. Nutzen Sie einen Broker, der Fluten drosselt und wiederholte Fehlanmeldungen blockiert, und lassen Sie sich alarmieren, wenn ein erwarteter Publisher verschwindet.
ConnectMQ wendet zum Beispiel auf jedem Broker Kontingente pro Plan, Flood-Schutz und IP-Sperren nach wiederholten Fehlanmeldungen an, sodass diese Schutzmaßnahmen nicht davon abhängen, dass jedes Werk seine eigene Konfiguration richtig hinbekommt.
Zuverlässigkeit und Datenqualität
Eine Verbindung, die in einer Demo funktioniert, ist nicht dasselbe wie eine, die über Jahre vertrauenswürdige Daten liefert. Prüfen Sie Folgendes vor dem Go-live:
- Report by Exception mit Heartbeats. Veröffentlichen Sie bei relevanter Änderung plus periodischer Aktualisierung, damit sich ruhende Werte von toten Verbindungen unterscheiden lassen.
- Last Will und Retained-Status. Ein Retained-Zustand
onlineoderofflinepro Publisher lässt jeden Konsumenten wissen, was aktuell ist. - Zeitstempel an der Quelle. Versehen Sie Werte dort mit einem Zeitstempel, wo sie gelesen werden, nicht dort, wo sie ankommen, und halten Sie die Uhren per NTP synchron.
- Pufferung. Legen Sie fest, was bei einem WAN-Ausfall passiert: verwerfen, im Speicher puffern oder auf der Festplatte puffern und in der richtigen Reihenfolge nachsenden.
- Benennung. Einigen Sie sich auf eine ISA-95-basierte Topic-Hierarchie, bevor der zweite Standort angebunden wird. Späteres Umbenennen ist teuer.
Diese Hierarchie ist der Kern eines Unified Namespace (UNS): Die ISA-95-Equipment-Hierarchie (Enterprise → Site → Area → Line → Cell) wird zur Topic-Struktur auf dem MQTT-Broker, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Ob die Daten aus einer nativ vernetzten S7, einem Gateway oder dem SCADA stammen, spielt für die Konsumenten dann keine Rolle mehr; MES, ERP, OEE-Dashboards und Predictive Maintenance finden jeden Wert am erwarteten Ort. Wie Sie das mit Sparkplug B kombinieren, zeigt Sparkplug B und Unified Namespace.
Den Netzwerkpfad testen
Bevor Sie irgendetwas bauen, weisen Sie nach, dass das Werksnetz einen Broker über TLS erreichen kann. Von einem Rechner in der Zone, in der Ihr Publisher laufen wird:
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i plant-path-test-9x2c -t 'connectmq/demo/9x2c/path-test' -m 'hello from the plant'
Schlägt das mit einem Timeout fehl, blockiert die Firewall ausgehend 8883. Schlägt es während des Handshakes fehl, ersetzt möglicherweise ein TLS-inspizierender Proxy die Zertifikate; darüber sollten Sie früh mit dem Netzwerkteam sprechen. Der öffentliche MQTT-Broker ist geteilt, für jeden lesbar und nur für Tests gedacht, senden Sie also nur Test-Strings und keine Produktionsdaten.
Wo der Broker stehen sollte
Ihre Optionen sind ein Broker vor Ort, ein selbst betriebener Broker in der Cloud oder ein verwalteter MQTT-Broker. Broker vor Ort sind für lokale Konsumenten und DMZ-Designs nützlich; für unternehmensweite Daten ist ein Cloud-Broker, der von jedem Standort aus erreichbar ist, einfacher. ConnectMQ bietet das als verwalteten Dienst mit MQTT 3.1.1 und 5.0, TLS auf 8883 und Optionen von geteilten Serverless-Plänen über Dedicated-Cluster bis hin zu BYOC-Deployments in Ihrem eigenen Cloud-Konto. Die Geräteansicht des Portals versteht ISA-95-Topics und Sparkplug B, sodass Daten aus nativen SPS-Clients, Gateways und SCADA in einer durchsuchbaren Hierarchie landen.
Entscheidungscheckliste
- Wie viele SPSen von wie vielen Herstellern sind dieses Jahr im Umfang?
- Können SPS-Programme geändert und geladen werden, und wer genehmigt das?
- Pollt das SCADA bereits die benötigten Anlagen?
- Welche Datenlatenz ist erforderlich: Sekunden, Minuten oder Stunden?
- Was passiert mit den Daten bei einem WAN-Ausfall, und wie lange?
- Welche Zone darf ausgehende Verbindungen aufbauen, und über welche Ports?
- Wer verantwortet Gateway-Patches, Zertifikate und Monitoring?
- Wird ein Schreibpfad von der Cloud zur SPS benötigt, und wurde er einer Risikobewertung unterzogen?
Deuten die Antworten auf viele Hersteller, keine SPS-Änderungen und lange Ausfälle hin, beginnen Sie mit einem Edge-Gateway. Die durchgängige Architektur finden Sie im Leitfaden zu Industrial IoT mit MQTT.
Starten Sie Ihr Projekt SPS in die Cloud mit ConnectMQ
Welche Architektur Sie auch wählen, sie braucht am anderen Ende einen verlässlichen Cloud-MQTT-Broker. Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte, und verbinden Sie noch heute Ihre erste SPS oder Ihr erstes Gateway per TLS.
Häufig gestellte Fragen
Was ist der sicherste Weg, eine SPS mit der Cloud zu verbinden?
Belassen Sie die SPS in ihrer Steuerungszone, lassen Sie ein Gateway oder einen DMZ-Broker ausschließlich ausgehende TLS-Verbindungen aufbauen, geben Sie jedem Publisher eigene Zugangsdaten und halten Sie den Datenpfad rein lesend.
Brauche ich ein Edge-Gateway, um eine SPS in die Cloud zu bringen?
Nicht immer. Manche SPSen können nativ per MQTT veröffentlichen, doch für Flotten mehrerer Hersteller, für die Pufferung bei Ausfällen und um SPS-Programme unverändert zu lassen, sind Gateways meist vorzuziehen.
Ist OPC UA oder MQTT besser für die Anbindung von SPSen an die Cloud?
OPC UA glänzt beim lokalen, strukturierten Zugriff auf SPS-Daten, während MQTT besser darin ist, Ereignisse an viele Cloud-Konsumenten zu verteilen. Viele Architekturen lesen am Edge per OPC UA und veröffentlichen per MQTT.
Sollten SPS-Daten in Echtzeit in die Cloud gehen?
Die meisten Cloud-Anwendungsfälle benötigen Sekunden bis Minuten, nicht Millisekunden. Halten Sie Regelkreise lokal und senden Sie Report-by-Exception-Daten nach oben.
