Intelligenter Brückenkran-Gateway mit Edge-Computing & OPC-UA

Das intelligente Gateway- und Edge-Computing-System des Brückenkrans bildet die zentrale Schnittstelle zwischen Anlagen- und Informationsebene: Es übernimmt die Protokollkonvertierung, Datenerfassung, Edge-Computing und unterbrechungsfreie Datenübertragung zwischen SPS, Frequenzumrichter und MES, SCADA sowie Cloud-Plattformen. Kelude Schwerindustrie hat auf Basis des Siemens Industrial Edge Gateway IOT2050 und einer eigenen Edge-Datenplattform eine standardisierte Architektur für Datenerfassung und Protokollkonvertierung von Brückenkranen aufgebaut. Sie unterstützt die Echtzeit-Konvertierung zwischen fünf Protokollen – PROFINET, OPC UA, Modbus TCP, MQTT und REST API. Ein einzelnes Gateway kann gleichzeitig Betriebsdaten von 8 Brückenkranen erfassen, die Edge-Verarbeitungslatenz liegt unter 50 ms, und bei Verbindungsabbruch gehen keine Daten verloren. Dieser Beitrag erläutert die gesamte Engineering-Praxis – von der Hardwareauswahl über die Protokollstack-Konfiguration und das Datenmodellierung bis hin zu Deployment und Betrieb.

Hardwareauswahl für industrielle Edge-Gateways und Systemarchitektur

Das zentrale Hardwareelement des Datenerfassungssystems für Brückenkrane ist das industrielle Edge-Gateway. Es wird im Kransteuerschrank oder in einem nahegelegenen Feldbedienstand installiert, verbindet sich nach oben mit dem Werkstattnetzwerk und nach unten über eine PROFINET-Schnittstelle direkt mit der Kran-SPS. In der standardisierten Lösung von Kelude Schwerindustrie kommt das Siemens Industrial Edge Gateway IOT2050 als primäre Hardwareplattform zum Einsatz. Es verfügt über einen ARM Cortex-A72 Quad-Core-Prozessor (1,5 GHz) und 4 GB DDR4-RAM, integriert zwei Gigabit-RJ45-Ethernet-Ports, zwei USB-3.0-Schnittstellen und einen industriellen SD-Kartenslot. Das Gerät läuft mit Siemens Industrial Edge und Linux-Container-basierten Edge-Apps. Das IOT2050 unterstützt einen erweiterten Temperaturbereich von -20 °C bis 60 °C, bietet Schutzart IP20 und eignet sich für die Montage auf der DIN-Hutschiene im Schaltschrank.

Die Systemarchitektur ist als Drei-Ebenen-Modell mit Edge-Cloud-Anbindung ausgelegt. Auf der Geräteebene umfasst sie die S7-1500-SPS, den G120-Frequenzumrichter, Encoder-Schnittstellenmodule und die Sensorgruppe in jedem Kransteuerschrank – die SPS veröffentlicht Betriebsdaten über PROFINET IO (10ms-Zyklus) an das Gateway, der G120-Frequenzumrichter übermittelt Motordrehzahl, Strom, Temperatur und Fehlercodes über das PROFINET-Antriebsprofil. Auf der Edge-Ebene ist ein IOT2050-Gateway eingesetzt, das vier zentrale Edge-Apps ausführt: OPC-UA-Server (Aggregation der UA-Daten aller SPS-Knoten), Protokollkonvertierungs-Engine (PROFINET, OPC UA, Modbus, MQTT), Edge-Datenverarbeitungseinheit (Pufferwarteschlange, unterbrechungsfreie Übertragung, Datenkomprimierung) sowie ein Datensicherheitsmodul (TLS-Verschlüsselung, Zugriffskontrollliste). Die Cloud-Ebene umfasst das MES-Produktionsausführungssystem, die SCADA-Überwachungsplattform und das Digitaler-Zwilling-Betriebsdashboard, die über OPC-UA-Clients oder MQTT-Broker mit dem Edge-Gateway kommunizieren.

OPC-UA-Serverkonfiguration und Datenmodellierung für Kransteuerungen

OPC UA ist das zentrale Kommunikationsprotokoll zwischen der Kransteuerung und den übergeordneten Systemen. Kelude hat im OPC-UA-Server des Edge-Gateways ein standardisiertes Informationsmodell für Brückenkrane implementiert. Die Datenknoten der Kransteuerung werden gemäß der OPC-UA-for-Machinery-Spezifikation (IEC 62541-100) gruppiert und benannt, sodass die Datenstruktur über alle Krane hinweg einheitlich ist und MES- und SCADA-Systeme keine individuelle Anpassung für jeden Kran benötigen.

Das Informationsmodell ist in vier Hierarchieebenen gegliedert. Die erste Ebene ist die Standortebene (Site), die der Werkstatt oder Werkshalle entspricht – der Knotenpfad „/Site/Workshop_01" enthält die Sammlung aller Krane dieser Werkstatt. Die zweite Ebene ist die Bereichsebene (Area), die einer Kran-Gruppe in derselben Kranbahn oder an derselben Arbeitsposition entspricht – der Knotenpfad „/Area/Bay_A" umfasst die 3 Krane dieser Kranbahn. Die dritte Ebene ist die Geräteebene (Device), die einem einzelnen Kran entspricht – der Knotenpfad „/Device/Crane_01" enthält alle Gruppendaten dieses Krans. Die vierte Ebene ist die Funktionsebene (Function), die den einzelnen Funktionseinheiten der Kransteuerung entspricht – einschließlich der Motion-Steuergruppe (Betriebsmodus, Zielposition, Istposition, Geschwindigkeit, Beschleunigungsstatus), der Drive-Frequenzumrichtergruppe (Motorstrom, Drehzahl, Temperatur, Betriebsstatus, Alarmschlüssel der einzelnen Antriebe), der Brake-Bremssgruppe (Öffnungs-/Schließstatus der beiden Bremssysteme, Elektromagnetstrom, Verschleißzähler, Synchronisationsfehler-Flag), der Safety-Sicherheitsgruppe (STO/SLS/SBC/SDI-Status, Not-Halt-Auslösungen, Sicherheitsereignisprotokoll) sowie der Diagnose-Gruppe (Systembetriebsstunden, Fehlercodewarteschlange, SPS-Zeitstempel).

Die Benennung der Datenknoten erfolgt im CamelCase-Format; jeder Knoten enthält eine Datentypdefinition und eine Beschreibung. Motion.ActualPosition (Int32, Einheit mm), Motion.Speed (Real, Einheit m/s), Drive.Current_A (Real, Einheit A), Brake.Status_A (Boolean, True = Bremse offen), Brake.UnsyncCount (UInt16), Safety.STO_Active (Boolean), Safety.EventCount (UInt32). Bei der Inbetriebnahme werden für jeden Kran die 26 standardisierten OPC-UA-Knoten adressiert und die Datentypen validiert. Nach Abschluss der Zuordnung werden alle Knoten mit dem UA-Expert-Tool auf Lesbarkeit und Datentyp-Korrektheit geprüft.

Protokollumsetzung: PROFINET auf OPC UA/Modbus/MQTT

Die Protokollumsetzung ist die Kernfunktion des Edge-Gateways. Die SPS des Brückenkrans veröffentlicht Daten im PROFINET-IO-Echtzeitzyklus (10 ms) an das Gateway. Die Protokollumsetzungs-Engine des Gateways analysiert die PROFINET-IO-Daten in ein einheitliches internes Datenformat und kapselt sie anschließend entsprechend den Zielanforderungen der jeweiligen Protokolle neu. Das Gateway betreibt gleichzeitig drei Protokollausgänge: einen OPC-UA-Server, einen Modbus-TCP-Server und einen MQTT-Client, die jeweils die drei Verbraucher MES-System, SCADA-System und Cloud-Plattform bedienen.

Konfiguration des OPC-UA-Ausgangs. Der OPC-UA-Server des Gateways basiert auf dem Open-Source-Stack open62541 und unterstützt das OPC-UA-Binärprotokoll (Standardport 4840) sowie HTTPS (Port 443). Die Sicherheitsrichtlinie des Servers ist auf Basic256Sha256 mit Signatur und Verschlüsselung konfiguriert (SecurityMode=SignAndEncrypt). Die Client-Authentifizierung erfolgt über eine X.509-Zertifikat-Whitelist – nur OPC-UA-Clients, deren Zertifikat in der Vertrauensliste des Gateways steht, dürfen eine Verbindung herstellen und Daten lesen. Der Server veröffentlicht die 26 Standardknoten des Brückenkrans. UA-Clients (z. B. der OPC-UA-Client des MES-Systems) ermitteln über die Browse-Operation die gesamte Knotenstruktur und lesen anschließend die Echtzeitdaten per Abonnement im Batch-Verfahren. Das minimale Abtastintervall des Abonnements beträgt 50 ms.

Konfiguration des Modbus-TCP-Ausgangs. Das Gateway bildet die Standarddaten des Brückenkrans auf die Modbus-Registertabelle ab. Die Registeradressen werden fortlaufend ab 40001 vergeben – 40001–40006 entsprechen den 6 Registern der Funktionsgruppe Motion, 40007–40014 den 8 Registern der Funktionsgruppe Drive, 40015–40019 den 5 Registern der Funktionsgruppe Brake und 40020–40023 den 4 Registern der Funktionsgruppe Safety. Jedes Register belegt 2 Byte; 32-Bit-Daten (z. B. Real, Int32) belegen zwei aufeinanderfolgende Register. Das SCADA-System fungiert als Modbus-TCP-Master (Standardport 502) und pollt die Registeradressen zyklisch. Mit einem einzelnen Leseauftrag können Daten aus einem zusammenhängenden Adressbereich im Batch abgerufen werden, wodurch der Netzwerkaufwand reduziert wird.

Konfiguration des MQTT-Ausgangs. Die Edge-Datenverarbeitungseinheit des Gateways verbindet sich als MQTT-Client mit dem MQTT-Broker der Cloud-Plattform (z. B. EMQX oder VerneMQ, Standardport 8883) und verwendet TLS-verschlüsselte Kommunikation. Die MQTT-Topics sind nach der Gerätehierarchie des Brückenkrans strukturiert und verwenden eine dreistufige Topic-Struktur: topic/workshop_id/crane_id/function/parameter, z. B. „krunde/workshop01/crane_01/motion/position". Die Datenveröffentlichung erfolgt mit QoS=1 (mindestens einmalige Zustellung). Die Datenlast wird im JSON-Format gekapselt und enthält die drei Felder Zeitstempel, Datenwert und Qualitätskennzeichen. Die typische Veröffentlichungsfrequenz beträgt 1 s pro Zyklus, das Datenvolumen ca. 200 Byte pro Zyklus und Brückenkran. Bei 8 gleichzeitig betriebenen Brückenkränen ergibt sich ein Netzwerkdatenstrom von ca. 1,6 KB/s.

Edge-Datenverarbeitung und Offline-Pufferung mit Nachübertragung

Die zuverlässige Erfassung der Betriebsdaten des Brückenkrans hängt von der lokalen Datenzwischenspeicherung und der Nachübertragung nach Verbindungsabbruch des Edge-Gateways ab. Industrielle Netzwerkumgebungen – insbesondere WiFi-Roaming beim Verfahren des Brückenkrans entlang der Schiene oder harmonische Störungen durch Frequenzumrichter in der Werkstatt – können zu kurzzeitigen Unterbrechungen der Verbindung zwischen Gateway und Cloud-Plattform führen. Die Edge-Datenplattform von Kelude Schwerindustrie verfügt daher über einen Ringpuffer-Cache und einen Mechanismus zur unterbrechungsfreien Nachübertragung.

Die Datenpufferschicht verwendet eine zweistufige Architektur aus Arbeitsspeicher und SD-Karte. Die erste Stufe ist ein Ringpuffer im Arbeitsspeicher mit einer Kapazität von 10.000 Datensätzen (bei ca. 200 Byte pro Datensatz entspricht dies ca. 2 MB Arbeitsspeicher). Die Schreibverzögerung des Speicher-Caches liegt unter 1 ms und wird über das Produzenten-Konsumenten-Muster realisiert – die OPC-UA-/Modbus-/MQTT-Ausgangsthreads fungieren als Konsumenten, lesen Daten aus dem Cache und leiten sie weiter; nach erfolgreicher Weiterleitung werden die Daten als verarbeitet markiert. Die zweite Stufe ist ein SD-Karten-Dateicache. Wenn bei Netzwerkunterbrechungen der Datenstau den Speicher-Schwellenwert (Standard 80 %) überschreitet, schreibt die Edge-Datenverarbeitungseinheit die aufgestauten Daten automatisch in die SD-Karten-Cache-Datei. Die SD-Karten-Kapazität hängt von der Kartengröße ab (empfohlen: 32 GB Industrie-SD-Karte). Für eine maximale Pufferung von 7 Tagen werden ca. 1,2 GB benötigt; eine 32-GB-SD-Karte kann Betriebsdaten des Brückenkrans für über 180 Tage puffern.

Die Strategie zur Nachübertragung nach Verbindungsabbruch unterscheidet drei Fälle. Kurze Unterbrechung (≤ 30 Sekunden): Der Speicher-Cache kann die aufgestauten Daten aufnehmen; nach Wiederherstellung der Verbindung baut der TCP-Ausgangsthread des Protokollstapels die Verbindung automatisch wieder auf und sendet die gepufferten Daten in der Reihenfolge des Zeitstempels in einem Durchgang. Mittlere Unterbrechung (30 Sekunden bis 2 Stunden): Nach Speicherüberlauf werden die Daten automatisch in den SD-Karten-Dateicache ausgelagert. Nach Wiederherstellung der Verbindung scannt das Dateisynchronisationsmodul die nicht gesendeten Cache-Dateien auf der SD-Karte und lädt sie mit einer Rate von 500 Datensätzen pro Sekunde hoch (bei einem Upload-Bandbreitenbedarf von ca. 212 KB/s kann ein 10-Mbps-Werkstattnetzwerk dies problemlos bereitstellen). Lange Unterbrechung (≥ 2 Stunden): Wenn der SD-Karten-Cache voll ist (die Anzahl der Cache-Dateien erreicht den Alarm-Schwellenwert), führt die Edge-Plattform automatisch eine Cache-Verdrängungsstrategie aus – die ältesten Datensätze werden nach dem FIFO-Prinzip anhand des Zeitstempels verworfen. Gleichzeitig wird ein lokaler Alarm ausgelöst und an das Bedienfeld des Brückenkrans übermittelt, um das Wartungspersonal zu informieren. Nach Wiederherstellung der Verbindung meldet das Gateway den Zeitstempelbereich der fehlenden Datensätze an das MES-System, das dann entscheidet, ob eine Nachlese aus der PLC-Historie erforderlich ist.

Datensicherheit und Zugriffskontrolle

Die Datensicherheit der Edge-Datenplattform für Brückenkrane folgt dem Industriestandard ISA/IEC 62443 für Cybersicherheit in der industriellen Automatisierung. Die Sicherheitsmaßnahmen sind in drei Ebenen gegliedert: Übertragungssicherheit, Zugriffskontrolle und Prüfprotokollierung.

Die Übertragungssicherheitsebene aktiviert für alle externen Kommunikationsverbindungen eine TLS-1.3-Verschlüsselung. Der OPC-UA-Server ist auf Basic256Sha256 mit Signatur und Verschlüsselung konfiguriert; unverschlüsselte Verbindungen (SecurityPolicy=None) sind deaktiviert. Der MQTT-Client verwendet TLS für die Verbindung zum MQTT-Broker; die Serverzertifikatsprüfung erfolgt über eine CA-Kettenvalidierung – das Gateway ist mit der werksseitigen CA-Zertifizierung ausgestattet, selbstsignierte Zertifikate sind für Verbindungen nicht zugelassen. Da das Modbus-TCP-Protokoll selbst keine Verschlüsselung unterstützt, wird über einen VPN-Tunnel (WireGuard) ein verschlüsselter Kanal zwischen dem Edge-Gateway und dem SCADA-Server aufgebaut; die Modbus-Datenpakete werden innerhalb des Tunnels übertragen. Der VPN-Tunnel verwendet eine Authentifizierung über einen vorab geteilten Schlüssel (PSK); der Schlüssel wird alle 90 Tage rotiert.

Die OPC-UA-Zertifikate der drei Rollen werden über die Weboberfläche des Gateways hochgeladen und gebunden. Bei der Verbindung eines UA-Clients prüft das Gateway den Common-Name-Feld im Client-Zertifikat, bestimmt daraus die Rolle und wendet die entsprechenden Berechtigungen an. Der MQTT-Zugriff wird über ACL-Regeln gesteuert. Jeder MQTT-Client authentifiziert sich über Benutzername und Passwort; die ACL-Regeln legen fest, welche MQTT-Themen der Client veröffentlichen oder abonnieren darf.

Die Audit-Log-Ebene protokolliert alle Datenzugriffsereignisse. Jede Verbindungsaufnahme und -trennung eines OPC-UA-Clients, jedes Abonnieren/Abbestellen eines MQTT-Clients sowie jede Modbus-TCP-Leseanfrage, die die Rate von 20 Anfragen pro Sekunde überschreitet und eine Verbindungsbegrenzung auslöst – all dies wird in der Audit-Log-Datei des Gateways festgehalten. Das Logformat enthält Zeitstempel, Quell-IP-Adresse, Protokolltyp, Vorgangstyp und Ergebnis. Die Audit-Logs werden automatisch rotiert, 90 Tage aufbewahrt, verschlüsselt gespeichert und können nur von der Admin-Rolle über die Weboberfläche des Gateways heruntergeladen und eingesehen werden.

Inbetriebnahme, Debugging und Betriebsführung

Die Inbetriebnahme und das Debugging des Brückenkran-Edge-Gateways folgen einem standardisierten Prozess. Der erste Schritt ist die Hardware-Installation: Die IOT2050 wird auf der DIN-Hutschiene im Schaltschrank montiert (belegt 4 Standard-Modulbreiten). Das Gateway wird über ein abgeschirmtes CAT6A-Netzwerkkabel mit dem PROFINET-Netzwerk-Switch in der Werkstatt verbunden. Über ein weiteres Netzwerkkabel erfolgt die Anbindung an den Büronetzwerk-Switch der Werkstatt (für MQTT-Upload und Fernverwaltung). Die Stromversorgung des Gateways erfolgt über 24V DC aus dem Schaltnetzteil des Schaltschranks. Am Stromversorgungseingang ist ein EMC-Filter (Nennstrom 0,5 A) vorgeschaltet.

Im zweiten Schritt wird die Edge-Software-Umgebung bereitgestellt. Über die Siemens Industrial Edge Management (IEM)-Plattform werden die Edge-App-Images per Fernzugriff auf die IOT2050 übertragen. Die Bereitstellungsreihenfolge der Apps ist: Basis-Laufzeitumgebung (Docker und Netzwerkkonfiguration), OPC-UA-Server-App, Protokollkonvertierungs-Engine-App, Edge-Datenverarbeitungs-App, Datensicherheitsmodul-App. Nach der Bereitstellung jeder App wird ein Selbsttest-Skript ausgeführt, um den Containerstatus und den Port-Listening-Status zu überprüfen. Bei der alternativen Lösung werden Docker-Compose-Konfigurationsdateien und Images per SSH übertragen und mit docker-compose up -d in einem Schritt bereitgestellt.

Der dritte Schritt ist die OPC-UA-Kommunikationsprüfung. Mit UA Expert wird eine Verbindung zum OPC-UA-Server des Gateways hergestellt (Standardport 4840). Nach dem Importieren des CA-signierten Client-Zertifikats wird die Browse-Funktion verwendet, um alle 26 Standardknoten zu durchlaufen. Für jeden Knoten wird eine Read-Operation ausgeführt, um Datentyp und Wertebereich zu validieren. Mit der Subscription-Funktion von UaExpert wird der Knoten Motion.Position abonniert (Abtastintervall 50 ms), um die Echtzeit-Datenaktualisierung auf Stabilität zu prüfen und die Verlustrate der Subscription mit ≤ 0,1 % zu verifizieren.

Im vierten Schritt wird die Datenübertragung validiert. In einem MQTT-Testclient wird das Thema krunde/workshop01/+/motion/position abonniert, um das vom Gateway veröffentlichte JSON-Datenformat zu prüfen. Mit einem Modbus-Slave-Simulator wird das SCADA-System simuliert, um die Registeradressen 40001~40023 auszulesen und die Datenwerte mit den Anzeigen der SPS abzugleichen. Netzwerktest: Trennen Sie das Betriebsnetzwerkkabel des Gateways für 30 Sekunden. Es wird geprüft, ob die Cache-Datei auf der SD-Karte automatisch erstellt wird. Nach der Wiederherstellung des Netzwerks lädt das Fortsetzungsmodul die zwischengespeicherten Daten automatisch hoch. Auf der MES-Seite wird bestätigt, dass kein Datenverlust auftritt und die Zeitstempel lückenlos sind.

Der fünfte Schritt umfasst die Konfiguration der Betriebsführung. In der Weboberfläche des Gateways (HTTPS://192.168.x.x:8443) werden Alarmregeln konfiguriert: Timeout bei OPC-UA-Clientverbindung (Standard: 30 Sekunden) löst eine E-Mail-Benachrichtigung aus; Verlust des MQTT-Broker-Herzschlags (Standard: 60 Sekunden ohne PINGRESP) löst einen Alarm aus; SD-Karten-Cache-Auslastung über 80 % löst einen Alarm aus; anhaltende CPU-Auslastung des Gateways über 80 % für 5 Minuten löst einen Alarm aus. Alle Alarme werden per SMTP an die E-Mail-Adresse des Wartungsingenieurs gesendet. Zusätzlich bietet die lokale LED-Anzeigeleuchte am Bedienfeld eine Statusanzeige vor Ort (grün = normal, rot = Alarm, gelb = Wartung).

Häufig gestellte Fragen (FAQ)