Transparente Serial-to-TCP-Übertragung oder Protokollkonvertierung: Was braucht Ihr Gerät?
Wählen Sie ein transparentes Serial-to-TCP-Gateway, wenn die Hostsoftware weiterhin das bestehende serielle Protokoll des Geräts verwenden soll. Wählen Sie eine Protokollkonvertierung, wenn der Host ein anderes Anwendungsprotokoll erwartet, etwa Modbus TCP statt Modbus RTU. Die erste Variante transportiert Bytes; die zweite interpretiert Nachrichten und baut sie neu auf.
Diese Entscheidung kommt vor der Hardwareauswahl. „RS485 auf Ethernet“ beschreibt die Schnittstellen, stellt aber keine Kompatibilität zwischen den Programmen an beiden Enden sicher. Ein tragfähiger Entwurf muss auch Framing, Buszugriffshoheit, Wiederholungen und Sicherheit berücksichtigen.
Was ein transparentes serielles Gateway tatsächlich macht
Im reinen transparenten Modus leitet das Gateway serielle Nutzdatenbytes über eine TCP-Verbindung weiter und schreibt empfangene TCP-Nutzdatenbytes auf seinen seriellen Port. Gerätebefehle, Prüfsummen, Antwortauswertung und die Bedeutung der Befehle bleiben Aufgabe der Anwendung. Prüfen Sie den gewählten Modus: Virtuelle COM- oder serielle Steuerungsmodi können eigene Aushandlungsverfahren ergänzen und passende Hostsoftware erfordern.
Das ist ein sinnvoller Ausgangspunkt für ein proprietäres Binärprotokoll oder eine bestehende serielle Anwendung, die einen unterstützten virtuellen COM-Treiber verwenden kann. Klären Sie, ob die Anwendung von Modem-Steuersignalen, BREAK, exaktem Timing oder dem Verhalten eines lokalen seriellen Treibers abhängt. Ein Gateway, das gewöhnliche Datenbytes transportiert, bildet diese Funktionen möglicherweise nicht nach.
Verwendet ein Messgerät beispielsweise einen dokumentierten Befehl mit vorangestellter Längenangabe, kann der Host TCP-Bytes sammeln, bis die vollständige Befehlsantwort vorliegt. Eine Registerzuordnung ist nicht erforderlich, der Host benötigt aber weiterhin den Parser für das Messgerät.
TCP erhält die Grenzen serieller Nachrichten nicht
TCP stellt einen zuverlässigen, geordneten Bytestrom bereit. Ein Empfänger kann bei einem Lesevorgang einen Teil einer Anwendungsnachricht oder mehrere Nachrichten zusammen erhalten. TCP-Segmente und Socket-Lesevorgänge sind keine Anwendungsdatensätze. Das entspricht dem Transportmodell in RFC 9293.
Beispiel zur Veranschaulichung: Ein Gerät sendet zwei Nachrichten A und B mit jeweils acht Bytes. Die empfangende Anwendung könnte zunächst die ersten fünf Bytes von A lesen und danach die übrigen drei Bytes von A zusammen mit allen acht Bytes von B. Diese Lesegrenzen sind lediglich ein Beispiel und keine Vorhersage des Netzwerkverhaltens. Der Parser muss unvollständige Daten puffern und vollständige Nachrichten anhand der Länge, eines Trennzeichens oder anderer Framing-Regeln des Protokolls extrahieren.
Das serielle Timing muss gesondert betrachtet werden. Modbus RTU trennt Frames durch Sendepausen und stellt Anforderungen an die Zeitabstände zwischen Zeichen. Die Serial-Line-Spezifikation, Abschnitt 2.5.1.1, definiert diese einschließlich der Timer-Empfehlung für höhere Baudraten. Auch UART-Start-, Paritäts- und Stoppbits sind keine gewöhnlichen TCP-Nutzdatenbytes.
Gehen Sie nicht davon aus, dass Lücken beim Eintreffen von Netzwerkdaten die seriellen Sendepausen nachbilden. Ein Gateway braucht geeignete Pufferung und Regeln für die serielle Übertragung. Paketierungs-Timeouts allein belegen nicht, dass ein RTU-Frame am seriellen Ausgang intakt bleibt. Testen Sie aufgeteilte Eingaben, verzögerte Bytes und unmittelbar aufeinanderfolgende Anfragen.
Modbus RTU im Tunnel unterscheidet sich von Modbus TCP
Eine Modbus-TCP-Anfrage besteht aus einem sieben Byte langen MBAP-Header und einer Protokolldateneinheit (PDU). Modbus RTU verwendet eine serielle Adresse, die PDU und eine CRC. Ein transparenter Tunnel kann die vollständigen RTU-Bytes einschließlich CRC innerhalb von TCP transportieren; ein standardkonformer Modbus-TCP-Client erwartet jedoch das MBAP-Format.
Ein konvertierendes Gateway wertet MBAP aus, ordnet den Unit Identifier dem konfigurierten seriellen Ziel zu, erstellt die RTU-Anfrage, prüft die CRC der Antwort und verknüpft die Antwort mit der ursprünglichen TCP-Transaktion. Die MBAP-Längenangabe unterstützt die Nachrichtenauswertung; die Transaktionskennung ordnet Anfragen und Antworten einander zu. Siehe den Modbus-TCP/IP-Implementierungsleitfaden, Abschnitte 3.1.2–3.1.3.
Durchgerechnetes, zur Veranschaulichung erfundenes Beispiel: Zwei Holding-Register ab der im Protokoll übertragenen Adresse null vom seriellen Gerät 7 lesen. Funktion 03 und die bei null beginnende Protokolladressierung entsprechen der Modbus-Anwendungsprotokollspezifikation, Abschnitte 4.4 und 6.3. Diese Bytes veranschaulichen die Codierung; sie stammen weder aus einem Obeita-Produkttest noch aus der Registerbelegung eines realen Geräts.
- Anfrage-PDU:
03 00 00 00 02. - Modbus-TCP-Anfrage:
00 2A 00 00 00 06 07 03 00 00 00 02. Die Transaktions-ID ist002A; die Länge0006zählt den Unit Identifier und die fünf PDU-Bytes. - Zugehörige RTU-Anfrage:
07 03 00 00 00 02 C4 6D. Die berechnete CRC wird mit dem niederwertigen Byte zuerst übertragen.
Die PDU bleibt in diesem Beispiel unverändert. Eine Konvertierung des Transport-Framings übersetzt nicht automatisch einen proprietären Befehlssatz, leitet keine Skalierung ab und klärt nicht die Reihenfolge von Daten über mehrere Register. Für diese Anforderungen ist eine ausdrückliche Zuordnung nötig.
Buszugriffshoheit und Wiederholungsstrategie festlegen
Das Modbus-Serial-Line-Modell erlaubt einen initiierenden Master und jeweils eine Transaktion zur selben Zeit. Zusätzliche Ethernet-Clients schaffen keine zusätzliche gleichzeitige serielle Übertragungskapazität. Benötigen mehrere Hosts Zugriff, sind ein dokumentierter Scheduler, Warteschlangengrenzen, Timeout-Behandlung und Antwortzuordnung erforderlich. Schließen Sie keinen weiteren aktiv abfragenden Master an denselben Bus an, sofern kein technisch ausgearbeitetes Arbitrierungsverfahren vorgesehen ist.
Klären Sie, was passiert, wenn eine eingereihte Anfrage abläuft, ein Client die Verbindung trennt oder eine verspätete serielle Antwort eintrifft. Ein transparenter Server, der mehrere Sockets akzeptiert, benötigt ausdrückliche Regeln für die Zugriffshoheit; allein das Annehmen von Verbindungen gewährleistet keinen sicheren Mehrclientbetrieb.
Fehlerszenario: Ein Gerät führt einen Schreibzugriff aus, doch seine Antwort geht verloren, bevor sie den Client erreicht. Eine Wiederholung durch die Anwendung kann denselben Schreibzugriff erneut ausführen. Eine TCP-Neuübertragung innerhalb einer Verbindung ist etwas anderes als das Senden einer weiteren Anwendungsanfrage. Eine Modbus-Transaktionskennung allein garantiert keine dauerhafte Unterdrückung doppelter Anfragen.
Ordnen Sie Befehle nach ihren Auswirkungen ein. Das erneute Zuweisen eines Sollwerts kann akzeptabel sein; das Wiederholen eines Befehls, der einen Zyklus startet, möglicherweise nicht. Legen Sie für Schreibzugriffe mit erheblichen Folgen geräteseitig unterstützte Sequenzprüfungen, einen Statusabgleich oder eine Wiederherstellung durch Bedienpersonal fest, statt bedingungslos zu wiederholen.
Die Sicherheitsgrenze der Installation definieren
Weder ungesichertes TCP noch herkömmliches Modbus TCP bietet von sich aus verschlüsselten und authentifizierten Anwendungszugriff. Prüfen Sie, was das gewählte Gateway und der Client tatsächlich unterstützen. Modbus Security spezifiziert TLS und zertifikatsbasierte Authentifizierung. Beide Endpunkte müssen dies unterstützen; Bereitstellung und Erneuerung der Zertifikate müssen eingeplant werden.
Zur Checkliste für die Installation gehören: die Erreichbarkeit des Gateways auf freigegebene Systeme begrenzen, das Steuerungsnetz isolieren, den Verwaltungszugriff schützen und eine direkte Erreichbarkeit aus dem öffentlichen Internet vermeiden. Ein freigegebenes VPN oder Sicherheitsgateway kann einen Netzwerkpfad schützen, doch das verbleibende lokale Segment und die Geräteautorisierung müssen weiterhin geprüft werden. Verschlüsselung legt nicht fest, welcher authentifizierte Client einen Schreibzugriff ausführen darf.
Eine praktische Checkliste für Auswahl und Abnahme
- Beide Protokolle bestimmen. Halten Sie fest, was das Gerät ausgibt und der Host akzeptiert: unverarbeitete serielle Bytes, RTU-over-TCP, Modbus TCP oder ein anderes dokumentiertes Format.
- Die elektrischen Voraussetzungen prüfen. Gleichen Sie RS232 oder RS485, Zwei- oder Vierdrahtverdrahtung, Pinbelegung, Baudrate, Parität, Stoppbits, Erdung, Isolation, Terminierung und Biasing mit den Installationsanforderungen ab.
- Die Verantwortung für das Framing zuweisen. Benennen Sie die Komponente, die Nachrichten zusammensetzt und das serielle Timing einhält, einschließlich maximaler Framegröße und Verhalten bei fehlerhaften Eingaben.
- Zugriff und Wiederherstellung spezifizieren. Definieren Sie Buszugriffshoheit, Verhalten bei gleichzeitigen Clients, Befehlsberechtigungen, Timeouts, Warteschlangengrenzen, Behandlung von Wiederverbindungen und sichere Wiederholungen von Schreibzugriffen.
- Die schwierigen Fälle nachweisen. Testen Sie in einem Laboraufbau unvollständige und zusammengefasste TCP-Lesevorgänge, nicht erreichbare Geräte, verspätete Antworten, Wiederverbindungen, volle Warteschlangen und verweigerten Zugriff. Legen Sie die Bestehenskriterien vor dem Test fest.
Wählen Sie transparente Weiterleitung, wenn die Protokolle bereits kompatibel sind und das Framing zuverlässig gehandhabt werden kann. Wählen Sie Konvertierung, wenn der Host ein anderes Nachrichtenformat oder ein ausdrückliches Datenmodell benötigt. Ist eine Seite nicht dokumentiert, sammeln Sie zunächst belastbare Informationen, bevor Sie sich auf eine Gateway-Architektur festlegen.
Ihre Gateway-Anforderungen für Obeita vorbereiten
Bereiten Sie für eine gezielte technische Besprechung mit Obeita ein bereinigtes Gerätehandbuch, repräsentative Anfrage- und Antwortframes, serielle Einstellungen, das Hostprotokoll, die Geräteanzahl, Timing-Anforderungen und das erwartete Verhalten im Fehlerfall vor. Entfernen Sie Zugangsdaten, Kundenkennungen und vertrauliche Prozessdaten. Anhand dieser Informationen lässt sich der erforderliche Aufwand für Transport, Konvertierung und Validierung bewerten.
Informationen zu ähnlichen Integrationsarbeiten finden Sie bei Obeitas Service zur Vernetzung von Bestandsgeräten und im abgeschlossenen Projekt zur Anpassung serieller Schnittstellen an Ethernet und Mobilfunk-DTUs (auf Englisch). Um die Protokolle Ihres Geräts und Hosts zu besprechen, kontaktieren Sie Obeita.
