Teil 2 der Serie. In Teil 1 habe ich die Architektur als Blueprint gezeigt – Zonen, Conduits, und der Grundsatz „Daten fließen von innen nach außen. Immer.“ Diesmal gibt es keine Grafik, sondern ein laufendes System: drei simulierte Maschinen, ein Edge-Gateway, ein Broker, ein Leitstand im Browser. Komplett on-premise, komplett Open Source.
Warum überhaupt nachbauen?
Architektur-Grafiken sind geduldig. Auf einem Schaubild trennt eine gestrichelte Linie das Maschinennetz von der IT, und alle nicken. Die interessanten Fragen kommen erst, wenn man es wirklich aufbaut: Wie stelle ich sicher, dass die Maschinen tatsächlich nirgendwo hinkommen? Woher weiß die IT-Seite, ob der Übergang lebt? Was passiert bei einem Ausfall – und was beim Wiederanlauf?
Genau dafür habe ich die Architektur aus Teil 1 auf einem Proxmox-Host nachgebaut. Nicht als Laborspielerei, sondern mit denselben Bausteinen, die auch in einem echten Mittelstandsprojekt zum Einsatz kommen. Der einzige Unterschied zur Produktion: Die Maschinen sind simuliert. Beim Kunden tritt an ihre Stelle der OPC-UA-Server der Maschinensteuerung – die Architektur dahinter bleibt exakt dieselbe.
Die zwei Zonen
Die Grundlage sind zwei getrennte Linux-Bridges auf dem Proxmox-Host. Die IT-Zone läuft auf einem eigenen Subnetz, das Maschinennetz auf einem anderen – und zwischen beiden gibt es kein Routing, kein NAT, keine Abkürzung.
Im Maschinennetz stehen drei Container, jeder ein eigener OPC-UA-Server auf Port 4840: eine Spritzgussmaschine mit Schusszähler, Zykluszeit und Werkzeugtemperatur, ein Stanzautomat vom Schlag einer Schuler MC 200 mit Hubzahl, Presskraft und Coil-Restlänge, und ein Stanzbiegeautomat à la Bihler GRM-NC mit variabler Hubzahl und Artikelverwaltung. Drei Technologien, drei unterschiedliche Datencharakteristiken – so sieht ein echter Maschinenpark aus, nicht wie drei Kopien desselben Simulators.
Das Entscheidende an dieser Zone ist, was ihr fehlt: Die Maschinen haben kein Gateway eingetragen und keinen Internetzugang. Das ist mehr als eine Firewall-Regel – ohne Gateway können die Maschinen auf Pakete aus fremden Netzen schlicht nicht antworten. Der Zugriff von außen scheitert nicht an einer Regel, die jemand versehentlich löschen könnte, sondern an der Physik des Netzwerks.
Der Conduit: ein Gateway mit zwei Beinen
Der einzige Übergang zwischen den Zonen ist das Edge-Gateway – ein Container mit zwei Netzwerkkarten, eine im Maschinennetz, eine in der IT-Zone. Damit ist der Conduit aus der IEC-62443-Grafik keine Abstraktion mehr, sondern ein konkretes Stück Infrastruktur, das man anfassen, überwachen und im Zweifel abschalten kann.
Auf der Maschinenseite arbeitet das Gateway mit OPC-UA-Subscriptions statt mit Polling. Der Unterschied ist grundsätzlich: Beim Polling fragt ein System zyklisch nach – jede Sekunde, jede Minute, egal ob sich etwas geändert hat. Bei einer Subscription meldet das Gateway einmalig an, welche Variablen es interessieren, und ab dann meldet sich die Maschine von selbst, sobald sich ein Wert ändert. Für Analogwerte wie die Werkzeugtemperatur sorgt ein Deadband dafür, dass nur relevante Änderungen gemeldet werden statt jedes Zappeln hinter der zweiten Nachkommastelle.
Auf der IT-Seite pusht das Gateway die normalisierten Daten per MQTT über TLS an den Broker – ausschließlich ausgehend, auf Port 8883. Fällt der Broker aus, puffert das Gateway die Nachrichten und arbeitet die Warteschlange beim Wiederverbinden in Originalreihenfolge ab. Es sammelt, es puffert, es pusht raus. Mehr macht es nicht, und genau das ist der Punkt.
Die IT-Zone: Broker, Terminal, kein Polling bis zum Schluss
In der IT-Zone nimmt ein Mosquitto-Broker die Daten entgegen – im Docker-Container, mit TLS, ohne anonymen Zugriff, und ganz bewusst ohne geöffneten unverschlüsselten Port. Der Broker ist Infrastruktur und läuft deshalb auch als solche: eigenständig, unabhängig vom Lebenszyklus irgendeiner Anwendung.
Das MDE-Terminal ist eine statische HTML-Seite, die sich per MQTT über WebSocket direkt auf den Broker verbindet und die Topics abonniert. Damit ist die Kette von der Maschine bis zum Bildschirm durchgehend ereignisgesteuert: Die Maschine meldet eine Änderung, das Gateway pusht sie zum Broker, der Broker pusht sie in den Browser. Nirgendwo in dieser Kette fragt irgendjemand zyklisch nach. Ändert sich eine Sekunde lang nichts, fließt eine Sekunde lang nichts.
Ein Detail, das sich in der Praxis bewährt hat: Der Status des Edge-Gateways wird über das Last-Will-Testament des MQTT-Protokolls überwacht. Bricht die Verbindung des Gateways ab, setzt der Broker von sich aus den Status auf offline – und das Terminal zeigt es an, ohne dass irgendein Watchdog pollt. Die IT-Seite weiß jederzeit, ob der Conduit lebt, und zwar per Push.
Wartung ist auch ein Conduit
Fernwartung ist der Klassiker, an dem Zonenkonzepte in der Praxis scheitern: Der Servicetechniker des Maschinenherstellers braucht Zugriff, irgendwer richtet einen dauerhaften VPN-Zugang ein, und die schöne Trennung ist Geschichte.
In dieser Architektur ist Wartung deshalb ein eigener, zweiter Conduit: ein Jump-Host mit ebenfalls zwei Netzwerkkarten. Die Karte Richtung Maschinennetz ist im Normalzustand getrennt – in Proxmox ist das ein einziges Häkchen an der virtuellen NIC. Freischaltung heißt: Die IT verbindet die Karte für den Wartungszeitraum, die Session läuft protokolliert über den Jump-Host, danach wird wieder getrennt. Temporär, freigeschaltet, protokolliert – und dazwischen existiert der Weg physisch nicht.
Der Moment, auf den es ankommt
Der eigentliche Test eines solchen Systems ist nicht der Normalbetrieb, sondern der Ausfall. Also: alle Maschinen-Container gestoppt, Gateway gestoppt. Das Terminal zeigt es ehrlich an – die Maschinen springen auf „OPC-UA offline“, der Conduit-Status auf offline. Keine eingefrorenen Werte, die Normalität vortäuschen.
Dann alles wieder hochgefahren – und zugeschaut. Das Gateway verbindet sich selbstständig neu, meldet sich per Retained-Message als online zurück, liest die aktuellen Maschinenzustände nach und die Kacheln springen nacheinander auf Produktion. Kein Neuladen der Seite, kein Neustart eines Dienstes, kein Eingriff. Ein System, das seinen eigenen Zustand ehrlich anzeigt und sich nach einer Störung selbst wieder aufbaut, ist am Ende das, was den Unterschied zwischen einer Demo und einer tragfähigen Architektur ausmacht.
Was das für den Mittelstand bedeutet
Der gesamte Aufbau läuft auf einem einzelnen Virtualisierungs-Host mit freier Software: Proxmox, Debian, Node-RED, Mosquitto, nginx. Keine Cloud-Abhängigkeit, keine Lizenzkosten, keine Daten, die das Haus verlassen. Die Empfangsseite – Broker, Terminal und künftig die Historien-Datenbank – ist ein Docker-Compose-Stack, der sich in kurzer Zeit auf beliebiger Hardware ausrollen lässt.
Und weil die Frage sonst in den Kommentaren kommt: Ja, das skaliert. Aus drei simulierten Maschinen werden beim echten Projekt fünf, zehn oder zwanzig echte – pro Maschine ein Eintrag in der Gateway-Konfiguration und eine Kachel im Terminal. Die Zonen, die Conduits und die Regel „direkt eingehend: nichts“ bleiben unverändert.
Ausblick: Teil 3
Was dem System noch fehlt, ist das Gedächtnis. Aktuell zeigt das Terminal den Live-Zustand – für Schichtberichte, Verläufe und Auswertungen braucht es eine Zeitreihen-Datenbank. In Teil 3 kommt deshalb TimescaleDB dazu: Historie, Charts und die Frage, wie man aus einem Datenstrom belastbare Kennzahlen macht.
Sie planen die Anbindung Ihres Maschinenparks – oder haben eine gewachsene Lösung, bei der niemand mehr so genau weiß, wer eigentlich mit wem spricht? Sprechen Sie mich an. Ich baue solche Systeme seit über 15 Jahren, und die ältesten laufen bis heute.