Einleitung

Umfang

Der Zweck dieses Dokuments ist es, den MODBUS-Nachrichtenübertragungsdienst über TCP / IP zu beschreiben und Referenzinformationen zur Verfügung zu stellen, um Softwareentwicklern bei der Nutzung dieses Dienstes zu helfen. Die Codierung des MODBUS-Funktionscodes ist nicht in diesem Artikel enthalten, siehe die MODBUS-Protokollspezifikation [2].

Dieses Dokument beschreibt die Implementierung des MODBUS-Nachrichtenübertragungsdienstes genauer und umfassend. Ziel ist es, die Interoperabilität zwischen Geräten zu erleichtern, die den MODBUS-Nachrichtenübertragungsdienst nutzen.

Dieses Dokument besteht aus drei Teilen:

• Übersicht über das MODBUS-Protokoll über TCP / IP
• Funktionsbeschreibung der MODBUS-Client -, Server - und Gateway-Tools
• Implementierungsrichtlinien für das Zielmodell einer MODBUS-Implementierung.

Client / Server-Modell

Der MODBUS-Nachrichtenübertragungsdienst bietet die Client / Server-Kommunikation zwischen Geräten, die über ein Ethernet-TCP / IP-Netzwerk verbunden sind.

Dieses Client-Server - Modell basiert auf vier Arten von Nachrichten:

• MODBUS-Anforderung
• MODBUS-Bestätigung
• MODBUS-Anweisung
• MODBUS-Antwort

MODBUS-Anforderung ist eine Nachricht, die vom Client über das Netzwerk gesendet wird, um eine Transaktion zu starten.

Die Modbus-Anzeige ist eine Anforderungsnachricht, die vom Server empfangen wird.

MODBUS-Antwort ist die vom Server gesendete Antwortnachricht

MODBUS-Bestätigung ist die vom Client empfangene Antwortnachricht

MODBUS-Nachrichtenübertragungsdienst.(Client / Server-Modell) für den Echtzeit-Informationsaustausch:

• Zwischen zwei Geräteanwendungen
• Zwischen Geräteanwendungen und anderen Geräten
• Zwischen HMI / SCADA-Anwendungen und Geräten
• Zwischen einem PC und einem Gerätsprogramm, das Online-Dienste anbietet

Normative Referenzdateien

Dieses Kapitel enthält eine Liste von Dateien, die vor diesem Dokument gelesen wurden:

[2]MODBUS-Protokoll - Spezifikation

[4]RFC1122

Abkürzung

ADU- - Anwendungseinheiten

IETF- - Internet Engineering Working Group

IP- - Internet-Protokoll

MAC- - Medienzugriffssteuerung

MB- - MODBUS

MBAP- - MODBUS-Protokoll

PDU- - Protokolldaten-Einheit

PLC- - Programmierbare Logik-Controller

TCP- - Übertragungssteuerungsprotokoll

BSD- - Berkeley Software Distribution

MSL- - Maximale Segment-Lebensdauer

Hintergrundübersicht

Protokollbeschreibung

Allgemeine Kommunikationsstruktur

MODBUS TCP / IP Kommunikationssysteme können verschiedene Arten von Geräten umfassen:

• MODBUS TCP / IP-Client - und Servergeräte, die mit einem TCP / IP-Netzwerk verbunden sind
• Interconnection Geräte, wie: Eine Brücke, Router oder Gateway, die zwischen einem TCP / IP-Netzwerk und einem seriellen Links-Subnetzwerk verbunden ist, das es ermöglicht, MODBUS-Server - Endgeräte mit seriellen Links miteinander zu verbinden

Abbildung 1: Modbus TCP / IP Kommunikationsstruktur

Das MODBUS-Protokoll definiert eineeinfache Protokolldaten-Einheit (PDU), die unabhängig von der zugrunde liegenden Kommunikationsschicht ist. Die MODBUS-Protokollzuordnung auf einem bestimmten Bus oder Netzwerk ermöglicht die Einführung zusätzlicher Domänen in derApplication Data Unit (ADU)Einige zusätzliche Bereiche wurden eingeführt.

Abbildung 2: Modbus-Framework

initiiert einen Client, der eine MODBUS-Transaktion initiiert, um eine MODBUS-Anwendungsdateninheit zu erstellen. Dieser Funktionscode gibt dem Server an, welche Aktion ausgeführt wird.

MODBUS-Anwendungsdateneinheit über TCP / IP

Dieser Abschnitt beschreibt die Enkapselung von MODBUS-Anfragen oder - Antworten, die in einem MODBUS-TCP / IP-Netzwerk durchgeführt werden.

Abbildung 3: Anforderung / Antwort von MODBUS über TCP / IP

Verwenden Sie einen dedizierten Header über TCP / IP, um die MODBUS-Anwendungsdateninheiten zu identifizieren. Diese Header werden als MBAP-Header (MODBUS-Header) bezeichnet.

Diese Header bieten einige Unterschiede im Vergleich zu den MODBUS-RTU - Anwendungseinheiten, die über serielle Verbindungen verwendet werden:

• Ersetzt das MODBUS-Sklavenadressfeld, das üblicherweise über MODBUS-Serienverbindungen verwendet wird, durch eine einzelne Byte-Einheit - Identifikation in einem MBAP-Header. Diese Einheit-Identifikation wird für die Kommunikation von Geräten verwendet, die mehrere unabhängige MODBUS-Endgeräte unterstützen, z. B. Brücken, Router und Gateways, die eine einzige IP-Adresse verwenden.
• Entwerfen Sie alle MODBUS-Anfragen und - Antworten so, dass der Empfänger die abgeschlossenen Nachrichten überprüfen kann. Für Modbus PDU-Funktionscodes mit einer festen Länge reicht nur ein Funktionscode aus. Für Funktionscode, der eine variable Daten in der Anforderung oder Antwort trägt, enthält das Datenfeld die Anzahl der Bytes.
• Wenn Sie MODBUS über TCP tragen, tragen Sie auch die Nachricht in mehrere Pakete für die Übertragung aufgeteilt, zusätzliche Längeninformationen auf dem MBAP-Nachrichtenkopf, so dass der Empfänger die Nachrichtengrenze identifizieren kann. Das Vorhandensein expliziter und impliziter Längenregeln und die Verwendung von CRC - 32 - Fehlerprüfcodes (über Ethernet) führen zu minimalen unerkannten Interferenzen bei Anforderungs - oder Antwortsendaten.

MBAP-Header - Beschreibung

Der MBAP-Header enthält folgende Felder:

Nachricht aus der empfangenen Anforderung erneut 7 Byte lang:

Transaktionsidentifier: Für die Transaktionspaarung. In der Antwort kopiert der MODBUS-Server die angeforderte Transaktionsbezeichner.

Protokoll-Identifikator: für die Multiplexation innerhalb des Systems. Das MODBUS-Protokoll wird durch den Wert 0 erkannt.

Länge: Das Längefeld ist die Anzahl der Bytes des nächsten Felds, einschließlich der Einheit-Identifikation und Datenfeld.

Einheit-Identifikator: Verwenden Sie diese Domain für das Routing innerhalb des Systems. Speziell für die Kommunikation mit MODBUS - oder MODBUS + - seriellen Slave-Links über das Gateway zwischen TCP-IP - Netzwerk über Ethernet und der seriellen MODBUS-Links. Der MODBUS-Client legt diese Domäne in der Anforderung fest, und der Server muss diese Domäne mit demselben Wert in der Antwort zurückgeben.

Senden Sie alle MODBUS / TCP ADUs über den registrierten 502 - Port mit TCP.

Hinweis: Die verschiedenen Domänen werden mit Big-endian kodiert.

MODBUS-Funktionscode - Beschreibung

Die Standardfunktionen, die im MODBUS-Anwendungs - Schichtprotokoll verwendet werden, sind in der MODBUS-Protokollspezifikation [2] beschrieben.

Funktionsbeschreibung

Die hier angebotene MODBUS-Komponentenstruktur ist ein allgemeines Modell, das sowohl MODBUS-Client als auch MODBUS-Server - Komponenten enthält und für jedes Gerät geeignet ist.

Einige Geräte bieten möglicherweise nur Server - oder Client-Komponenten.

Im ersten Teil dieses Kapitels wird eine kurze Übersicht über die Komponentenstruktur des MODBUS-Nachrichtenübertragsdienstes gegeben und anschließend eine Beschreibung jeder Komponente innerhalb des Strukturmodells.

Modell für Modbus-Komponentenstruktur

Abbildung 4 Konzeptstruktur des MODBUS-Nachrichtenübertragungsdienstes

• Kommunikationsanwendungsschicht

Ein MODBUS-Gerät kann eine Client - und / oder Server-MODBUS - Schnittstelle bereitstellen.

bietet eine MODBUS-Hintergrund - Schnittstelle, die den indirekten Zugriff auf Benutzeranwendungsobjekte ermöglicht.

Diese Schnittstelle besteht aus vier Teilen: Discrete-Eingang, Discrete-Ausgang (Spule), Register-Eingang und Register-Ausgang. Die Zuordnung zwischen dieser Schnittstelle und den Benutzeranwendungsdaten muss definiert werden (Lokalproblem）。

• MODBUS-Client

Der MODBUS-Client ermöglicht es Benutzern, den Austausch von Informationen mit Remote-Geräten eindeutig zu steuern. Der MODBUS-Client generiert eine MODBUS-Anfrage basierend auf den Parametern, die in den Anforderungen enthalten sind, die von der Benutzeranwendung an die MODBUS-Client - Schnittstelle gesendet werden.

Der MODBUS-Client ruft eine MODBUS-Transaktion auf, und die Transaktionsverwaltung umfasst das Warten und die Verarbeitung von MODBUS-Bestätigungen.

• MODBUS-Clientschnittstelle

Die MODBUS-Clientschnittstelle bietet eine Schnittstelle, mit der Benutzeranwendungen Anfragen für verschiedene MODBUS-Dienste generieren können, einschließlich des Zugriffs auf MODBUS-Anwendungsobjekte. Obwohl im Implementierungsmodell als Beispiel dargestellt wird, wird die MODBUS-Client - Schnittstelle (API) hier nicht beschrieben.

• MODBUS-Server

Nachdem das Modul eine MODBUS-Anfrage empfängt, aktiviert es eine lokale Operation zum Lesen, Schreiben oder andere Operationen. Die Abwicklung dieser Operationen ist für die Anwendungsentwickler transparent. Die Hauptfunktion des MODBUS-Servers besteht darin, auf eine MODBUS-Anfrage vom TCP502 - Port zu warten, diese Anfrage zu verarbeiten und dann eine MODBUS-Antwort zu generieren, die je nach Gerätesituation (Szenario) abhängt.

• MODBUS-Hintergrund - Schnittstelle

Die MODBUS-Hintergrund - Schnittstelle ist eine Schnittstelle zwischen dem MODBUS-Server und der Benutzeranwendung, die das Anwendungszweck definiert.

• TCP Management

Eine der Hauptfunktionen des Nachrichtenübertragungsdienstes ist die Verwaltung des Aufbaus und - beendens der Kommunikation und der Verwaltung des Datenflusses, die über TCP-Verbindungen erstellt werden.

• Verbindungsverwaltung

Die Kommunikation zwischen dem MODBUS-Modul des Clients und des Servers erfordert den Aufruf des TCP-Verbindungsverwaltungsmoduls. Es ist verantwortlich für die vollständige Verwaltung der TCP-Verbindung der Nachrichtenübertragung.

Es gibt zwei Möglichkeiten für das Verbindungsmanagement: Die Benutzeranwendung verwaltet die TCP-Verbindung selbst, oder die Verbindung wird von diesem Modul verwaltet, und zwar transparent für die Benutzeranwendung. Das letztere Programm ist weniger flexibel.

Das Abhören des TCP-Portes 502 ist für die MODBUS-Kommunikation reserviert. Im Standardzustand erzwingen Sie das Abhören dieses Mundes. Einige Märkte oder Anwendungen können jedoch zusätzliche Anschlüsse für die Kommunikation über MODBUS über TCP benötigen. Dies ist der Fall, wenn eine Interoperabilität mit Nicht-Schneider - Produkten erforderlich ist, zum Beispiel in der Gebäudesteuerung. Hierzu wird dringend empfohlen, dass sowohl der Client als auch der Server dem Benutzer die Möglichkeit bieten, die MODBUS-Parameter auf dem TCP-Slogan zu konfigurieren. Wichtig: Auch wenn in einer bestimmten Anwendung für den MODBUS-Dienst zusätzliche TCP-Server - Ports konfiguriert sind, muss der TCP-Server - Port 502 mit Ausnahme von einigen spezifischen Anwendungs-Ports weiterhin verfügbar sein.

• Zugriffssteuerungsmodul

In einigen kritischen Situationen muss der Zugriff unerwünschter Hosts auf die internen Daten des Geräts verhindert werden. Dies ist sowohl der Grund, warum ein sicheres Modus erforderlich ist, als auch der Grund, warum eine sichere Handhabung bei Bedarf möglich ist.

• TCP / IP-Stack

Der TCP / IP-Stack kann parametrisch konfiguriert werden, um die Datenflusssteuerung, die Adressverwaltung und das Verbindungsmanagement an die verschiedenen Einschränkungen eines bestimmten Produkts oder Systems anzupassen. Im Allgemeinen wird die BSD-Socket - Schnittstelle verwendet, um TCP-Verbindungen zu verwalten

• Ressourcenverwaltung und Datenflusssteuerung

Um den Datenfluss zwischen dem MODBUS-Client und dem Server auszugleichen, wurde ein Datenflusssteuerungsmechanismus auf allen Ebenen des MODBUS-Nachrichtenstacks eingerichtet. Das Ressourcenmanagement - und Datenflusssteuerungsmodul basiert zunächst auf der internen TCP-Datenflusssteuerung, einigen Datenflusssteuerungen auf der zusätzlichen Datenlink-Ebene und der Datenflusssteuerung auf der Benutzeranwendungs-Ebene.

TCP-Verbindungsverwaltung

Verbindungsverwaltungsmodul

Übersichtliche Beschreibung

Die MODBUS-Kommunikation erfordert die Herstellung einer TCP-Verbindung zwischen Client und Server.

Die Verbindung kann direkt durch das Benutzeranwendungsmodul oder automatisch durch das TCP-Verbindungsverwaltungsmodul erstellt werden.

Im ersten Fall muss das Benutzeranwendungsmodul eine Anwendungsschnittstelle bereitstellen, um die Verbindung vollständig zu verwalten. Dieser Ansatz bietet Anwendungsentwicklern Flexibilität, erfordert jedoch Fachkenntnisse in TCP / IP-Mechanismen.

Im zweiten Szenario gibt es keine TCP-Verbindungsverwaltung, und die Benutzeranwendung muss nur MODBUS-Nachrichten senden und empfangen. Das TCP-Verbindungsverwaltungsmodul ist verantwortlich für die Herstellung neuer TCP-Verbindungen, wenn erforderlich.

Die Definition der Anzahl der TCP-Client - und Server-Verbindungen fällt nicht in den Umfang dieses Dokuments (in diesem Artikel wird n verwendet). Je nach Gerätekapazität kann die Anzahl der TCP-Verbindungen variieren.

Implementierungsregeln:

• Es wird empfohlen, die automatische TCP-Verbindungsverwaltung zu verwenden, wenn es keine eindeutigen Benutzeranforderungen gibt
• Empfehlung: Öffnen und halten Sie die Verbindung zum Remote-Gerät, anstatt die Verbindung bei jeder MODBUS / TCP-Transaktion zu öffnen und zu schließen.Hinweis: MODBUS-Kunden müssen jedoch in der Lage sein, eine Schließanforderung vom Server zu empfangen und die Verbindung zu schließen. Bei Bedarf kann die Verbindung wiederhergestellt werden.
• Empfehlung:Jeder MODBUS-Client sollte mindestens eine TCP-Verbindung(selbe IP-Adresse) mit dem Remote-MODBUS - Server haben. Eine Anwendung, um eine Verbindung aufzubauen, ist eine gute Wahl.
• Mehrere MODBUS-Transaktionen können auf derselben TCP-Verbindung gleichzeitig aktiviert werden Hinweis: In diesem Fall muss die MODBUS-Transaktionsidentifikation verwendet werden, um eine Übereinstimmung zwischen Anforderung und Antwort eindeutig zu identifizieren.
• Im Falle der bidirektionalen Kommunikation zwischen zwei Remote-MODBUS - Geräten (einem Client und einem Server) ist es notwendig, eine Verbindung für den Client - und Server-Datenstrom separat herzustellen.
• Ein TCP-Frame kann nur eine Modbus-ADU übertragen. Empfehlung: Senden Sie nicht mehrere Anfragen oder Antworten in der gleichen TCP-PDU.

Abbildung 7: TCP-Verbindungsverwaltung

1.显式TCP连接管理

用户应用模块负责管理所有的TCP连接：主动的和被动的连接建立、连接结束………。Diese verwaltet alle Verbindungen zwischen dem Client und dem Server. Die BSD-Socket - Schnittstelle wird im Benutzeranwendungsmodul zur Verwaltung von TCP-Verbindungen verwendet. Dieses Programm bietet volle Flexibilität, bedeutet aber auch, dass der Anwendungsentwickler über ausreichende Kenntnisse über TCP verfügt.

Unter Berücksichtigung der Kapazitäten und Bedürfnisse des Geräts muss die Anzahl der Verbindungen zwischen Clients und Servern eingeschränkt werden.

2. Automatische TCP-Verbindungsverwaltung

TCP-Verbindungsverwaltung ist vollständig transparent für das Benutzeranwendungsmodul. Das Verbindungsverwaltungsmodul kann eine ausreichende Anzahl von Client - / Serververbindungen akzeptieren. Andernfalls muss es einen Implementierungsmechanismus geben, wenn die autorisierte Anzahl von Verbindungen überschritten wird. In diesem Fall empfehlen wir: Schließen Sie die nicht genutzte Verbindung, die zuerst hergestellt wurde.

Eine Verbindung mit einem entfernten Objekt wird hergestellt, nachdem das erste Paket von einem entfernten Client oder einer lokalen Benutzeranwendung empfangen wurde. Wenn ein Netzwerk beendet wird oder ein lokales Gerät entscheidet, es zu beenden, wird diese Verbindung heruntergefahren. Bei Erhalt einer Verbindungsanforderung kann die Option zur Zugriffssteuerung verwendet werden, um die Möglichkeit des Zugriffs auf das Gerät durch unbefugte Kunden zu verhindern.

Das TCP-Verbindungsverwaltungsmodul verwendet eine Stack-Schnittstelle (normalerweise eine BSD-Socket - Schnittstelle) für die Kommunikation mit dem TCP / IP-Stack.

Um die Kompatibilität zwischen den Systemanforderungen und den Serverressourcen zu gewährleisten, wird die TCP-Verwaltung beide Verbindungen halten.库。

• aufrechterhalten. Die erste库(Priority Connection库) besteht aus Verbindungen, die nie aktiv lokal geschlossen werden. Sie müssen eine Konfiguration zur Erstellung dieser Bibliothek bereitstellen. Das Prinzip der Implementierung besteht darin, jede mögliche Verbindung zu dieser Bibliothek mit einer bestimmten IP-Adresse zu verknüpfen. Geräte mit dieser IP-Adresse werden als „markiert" bezeichnet. Eine neue Verbindungsanforderung für jedes "markierte" Gerät muss empfangen und aus der Priority Connection Library entnommen werden. Es ist außerdem notwendig, die maximale Anzahl der Verbindungen einzurichten, die pro Remote-Gerät erlaubt sind, um zu vermeiden, dass dasselbe Gerät alle Verbindungen in der Priority Connection Library verwendet.
• Die zweite Bibliothek (Nicht-Prior - Verbindungsbibliothek) enthält Verbindungen zu nicht markierten Geräten. Die Regel, die hier angewendet wird, ist: Wenn eine neue Verbindungsanforderung von einem nicht markierten Gerät auftritt und keine Verbindung in der Bibliothek verfügbar ist, schließen Sie die zuvor hergestellte Verbindung.

Eine Konfiguration kann als Option zur Zuweisung der Anzahl der verfügbaren Verbindungen in jeder Bibliothek bereitgestellt werden. Jedoch (nicht obligatorisch) kann der Designer bei Bedarf die Anzahl der Verbindungen während des Entwurfs festlegen.

Verbindungsverwaltung Beschreibung

• Verbindungsaufbau

Der MODBUS-Nachrichtenübertragungsdienst muss eine Listen-Sockel am Port 502 bereitstellen, die den Empfang neuer Verbindungen und den Datenaustausch mit anderen Geräten ermöglicht.

Wenn ein Messaging-Dienst Daten mit einem Remote-Server austauschen muss, muss er eine neue Clientverbindung mit dem Remote-Port 502 herstellen, um Daten mit dem Remote-Server austauschen zu können. Der lokale Port muss größer als 1024 sein und variiert von Clientverbindung zu Client.

Abbildung 8: Modbus TCP / IP-Verbindung herstellen

Wenn die Anzahl der Verbindungen zwischen dem Client und dem Server größer ist als die zulässige Anzahl, wird die erste unbrauchbare Verbindung hergestellt. Aktivieren Sie den Zugriffssteuerungsmechanismus, um zu überprüfen, ob die IP-Adresse des Remoteclients autorisiert ist. Wenn nicht autorisiert, wird eine neue Verbindung abgelehnt.

• MODBUS-Datenübertragung

Senden Sie MODBUS-Anfrage basierend auf der bereits geöffneten korrekten TCP-Verbindung。Die IP-Adressen des Remote-Geräts werden verwendet, um die erstellte TCP-Verbindung zu finden. Wenn Sie mehrere Verbindungen mit demselben Remote-Gerät herstellen, müssen Sie eine der Verbindungen für das Senden von MODBUS-Nachrichten auswählen, und Sie können verschiedene Auswahlstrategien verwenden, z. B. die älteste Verbindung, die erste Verbindung. Während der gesamten MODBUS-Kommunikation muss die Verbindung immer geöffnet bleiben. Wie in den folgenden Kapiteln beschrieben, kann ein Client mehrere Transaktionen an einem Server initiieren, ohne darauf zu warten, dass die Vorverarbeitung beendet wird.

• Verbindung heruntergefahren

Wenn die MODBUS-Kommunikation zwischen dem Client und dem Server beendet ist, muss der Client die Verbindung heruntergefahren, die für die Kommunikation verwendet wird.

Auswirkung des Betriebsmodus auf die TCP-Verbindung

某些操作模式（两操作端点之间通信断开、一个端点的故障和重新启动、………）会对TCP连接产生影响。Eine Verbindung kann als geschlossen oder ungewöhnlich beendet auf dieser Seite ohne Bestätigung von der anderen Seite angesehen werden, und diese Verbindung wird als "halböffnet" bezeichnet.

Dieses Kapitel beschreibt jede der wichtigsten Betriebsmodelle.- Eigenschaftenfür jeden der wichtigsten Betriebsmodi.„Es wird angenommen, dass es an beiden Enden der Verbindung verwendet wird"Bleiben Sie verbundenTCP-Mechanismus.

Kommunikation zwischen den beiden Operatoren unterbrochen

Die Ursache für die Kommunikation unterbrochen kann durch ein abgebrochenes Ethernet-Kabel auf der Serverseite sein. Die erwarteten Eigenschaften vonEigenschaftensind:

• Wenn keine Pakete an der Verbindung gesendet werden:

Wenn die Kommunikationsunterbrechung länger als "Behalten Sie den Wert des Timers Connectedund wird die Kommunikationsunterbrechung nicht wahrgenommen. Wenn die Kommunikationstrennzeit den Wert des Timers „Keep Connected" überschreitet, gibt es einen Fehler an die TCP-Verbindungsschicht zurück, um die Verbindung zurückzusetzen.

• Wenn einige Pakete vor oder nach dem Trennen der Verbindung gesendet werden:

Der TCP-Wiederübertragungsalgorithmus (Jacobson-Algorithmus, Karn-Algorithmus und exponentieller Kompensationsalgorithmus) wird aktiviert. Dies kann dazu führen, dass die TCP-Stack - Verbindungsschicht zurückgesetzt wird, bevor der Timer „Keep Connected" abläuft.

Server-Ausfall und Neustart

Nach einem Server-Ausfall und einem Neustart befindet sich der Client in einem "halboffnen" Zustand der Verbindung. Die erwarteten Eigenschaften vonEigenschaftensind:

• Wenn kein Paket über eine halb geöffnete Verbindung gesendet wird:

Solange der Timer „Keep Connected" noch im Timing ist, ist die Verbindung vom Client aus半geöffnet. Anschließend wird ein Fehler an die TCP-Administration zurückgegeben, die die Verbindung zurücksetzt.

• Wenn Sie einige Pakete über eine halb geöffnete Verbindung senden:

Der Server empfängt Daten über eine nicht existierende Verbindung. Der Stack auf der TCP-Schicht sendet eine Reset-AnweisungAnweisungenzur Schließung der halb offenen Verbindung des Clients.

Ausfall und Neustart auf der Clientseite

Nach einem Ausfall und Neustart des Clients befindet sich die Serverseite in einem "halb offenen" Zustand der Verbindung. Der erwartete Zustand vonDer Zustandlautet:

• Wenn kein Paket über eine halb geöffnete Verbindung gesendet wird:

Solange der Timer "Keep Connected" läuft, ist diese Verbindung von半auf der Serverseite geöffnet. Anschließend wird ein Fehler an die TCP-Administration zurückgegeben, die die Verbindung zurücksetzt.

• Wenn der Client eine neue Verbindung eröffnet, bevor der Timer "Keep Connected" abgeschlossen ist:

Es müssen zwei Szenarien untersucht werden:

• Die geöffnete Verbindung hat die gleichen Eigenschaften wie eine halb offene Verbindung auf der Serverseite (selben Source - und Zielport, dieselben Source - und Ziel-IP - Adressen), sodass die TCP-Stack - Schicht keine Verbindung öffnen kann, nachdem die Verbindung hergestellt wurde (in den meisten Fällen 75 ms). Um die Kommunikation für längere Zeitüberschreitungen zu vermeiden, empfiehlt es sich, nach einem Neustart auf der Clientseite sicherzustellen, dass die Verbindung mit einem anderen Quellpasswort als der ursprüngliche Verbindung hergestellt wird.
• Die geöffnete Verbindung hat andere Eigenschaften als eine halb offene Verbindung auf der Serverseite (verschiedene Quell - und Ziel-Ports, dieselben Quell - und Ziel-IP - Adressen), sodass die Verbindung auf der TCP-Stack - Ebene geöffnet und an die TCP-Verwaltung auf der Serverseite signalisiert wird.

Wenn die serverseitige TCP-Management - Ebene nur eine Verbindung mit einer Remote-Client - IP-Adresse unterstützt, können Sie die ursprüngliche halb geöffnete Verbindung schließen und eine neue Verbindung verwenden.

Wenn die Serverseitige TCP-Management - Schicht Verbindungen mit mehreren IP-Adressen für Remote-Clients unterstützt, bleibt die neue Verbindung offen und die ursprüngliche Verbindung bleibt halb offen, bis "Sie"Keep Connected" abgelaufen ist, an dem ein Fehler an die TCP-Management - Ebene zurückgegeben wird. Danach kann das TCP-Management die ursprüngliche Verbindung zurücksetzen.

Zugriffssteuerungsmodul

Dieses Modul soll jede neue Verbindung gegen eine Liste von rechtmäßig autorisierten Remote-IP - Adressen überprüfen, die TCP-Verbindungen für einen Remote-Client autorisieren oder verhindern können.

In kritischen SituationenGelegenheitmüssen Anwendungsentwickler ein Zugriffssteuerungsmodul auswählen, um den Zugriff auf das Netzwerk zu gewährleisten. In diesem Fall muss der Zugriff auf jede Remote-IP autorisiert oder verboten werden. Der Benutzer ist verpflichtet, eine Liste der IP-Adressen anzugeben und insbesondere anzugeben, ob jede IP-Adressen legal autorisiert ist. Standardmäßig sind im abgesicherten Modus alle IP-Adressen, die nicht vom Benutzer konfiguriert sind, blockiert. Mit Hilfe des Zugriffssteuerungsmodus schließen Sie also Zugriffsverbindungen von unbekannten IP-Adressen.

Verwendung des TCP / IP-Stacks

Der TCP / IP-Stack bietet eine Schnittstelle zum Verwalten von Verbindungen, Senden und Empfangen von Daten und kann auch Parameter konfiguriert werden, um die Eigenschaften des StacksEigenschaftenan die Einschränkungen des Geräts oder Systems anzupassen.

Ziel dieses Kapitels ist es, einen Überblick über die Stack-Schnittstelle sowie einige Informationen über die Konfiguration der Parameter des Stacks zu geben. Die Übersicht umfasst hauptsächlich einige Funktionen, die für die Übertragung von MODBUS-Nachrichten verwendet werden.

Für weitere Informationen wird empfohlen, RFC 1122 zu lesen, der Anbietern und Entwicklern eine Anleitung für Internetkommunikationssoftware bietet. RFC 1122 beschreibt die Standardprotokolle, die von einem mit dem Internet verbundenen Host übernommen werden müssen, sowie eine klare Reihe von Anforderungen und Optionen.

Die Stack-Schnittstelle basiert im Allgemeinen auf der in diesem Dokument beschriebenen BSD-Schnittstelle (Berkeley Software Distribution Code).

BSD-Socket - Schnittstellen für die Anwendung

Hinweis: Einige TCP / IP-Stacks schlagen andere Schnittstellen aus Leistungsgründen vor. Der MODBUS-Client oder - Server kann diese spezifischen Schnittstellen verwenden, aber diese Verwendung wird in diesem Dokument nicht beschrieben.

Ein Socket ist ein Kommunikationsendpunkt, der ein grundlegender Baustein der Kommunikation ist. Das Senden und Empfangen von Daten über ein Socket kann eine MODBUS-Kommunikation durchgeführt werden. Die TCO / IP-Bibliothek bietet nur Streaming-Sockets, die TCP verwenden und verbindungsbasierte Kommunikationsdienste bereitstellen.

Die socket () - Funktion wird verwendet, um ein Socket zu erstellen. Eine zurückgegebene Socket-Nummer wird vom Ersteller verwendet, um auf das Socket zuzugreifen. Das Socket wurde ohne Adresse (IP-Adresse und Passwort) erstellt. Die Daten können nur empfangen werden, bis ein Port an das Socket gebunden ist.

Die bind() - Funktion wird verwendet, um ein Slogan an einen Socket zu binden. Die bind () - Funktion stellt eine Verbindung zwischen dem Socket und dem angegebenen Slogan her.

Um eine Verbindung zu initialisieren, muss der Client die connect () - Funktion senden, um die Sockennummer, die Remote-IP - Adresse und das Remote-Listen - Passwort anzugeben (aktive Verbindung).

Um die Verbindung abzuschließen, muss der Server die Funktion accept () senden, die den zuvor im listen () - Aufruf angegebenen Socket-Nummer angibt (passive Verbindung). Es wird ein neues Socket erstellt und hat die gleichen Eigenschaften wie das ursprüngliche. Dieses neue Socket verbindet sich mit dem Socket des Clients und gibt die Socketnummer an den Server zurück. Das anfängliche Socket wird dann freigegeben, damit es für andere Clients verwendet werden kann, die eine Verbindung mit dem Server herstellen möchten.

Sobald die TCP-Verbindung hergestellt ist, können die Daten übertragen werden. Die Send () und recv () - Funktionen sind speziell für die Verwendung mit bereits verbundenen Sockets ausgelegt.

Mit der Funktion „suppckopt()" können Ersteller von Sockets mehrere Optionen mit einem Socket erstellen. Diese Optionen beschreiben die Funktionsmerkmale des Sockels.

Die select() - Funktion ermöglicht es Programmierern, Ereignisse auf allen Sockets zu testen.

Die shutdown () - Funktion ermöglicht es dem Benutzer des Sockels, send () und / oder recv () zu beenden.

Sobald ein Socket nicht mehr benötigt wird, können Sie die Funktion close() verwenden, um die Beschreibung des Sockets zu verwerfen.

Abbildung 9: Modbus-Informations - Austausch

Die obige Abbildung zeigt den vollständigen MODBUS-Kommunikationsprozess zwischen Client und Server. Der Client stellt eine Verbindung her und sendet drei MODBUS-Anfragen an den Server, ohne auf die Antwort auf die erste Anfrage zu warten. Nachdem alle Antworten erhalten sind, schließt der Client die Verbindung normal.

TCP-Schicht - Parameterkonfiguration

Sie können einige Parameter des TCP / IP-Stacks anpassen, um die Eigenschaften des Produkts oder des Systems an die Beschränkungen zu halten. Die folgenden Parameter der TCP-Schicht können angepasst werden:

• Parameter pro Verbindung

SO-RCVBUF, SO-SNDBUF:

Diese Parameter ermöglichen die Festlegung von Höhengrenzen für die Sockel-Schnittstellen für Senden und Empfangen. Durch Anpassung dieser Parameter kann das Verkehrssteuerungsmanagement realisiert werden. Die Größe des Empfangs-Cashes ist der maximale Wert pro verbundenen Advertised Window. Um die Leistung zu verbessern, müssen Sie die Größe des Sockets-Cache erhöhen. Andernfalls müssen diese Werte kleiner als die Ressourcen des internen Laufwerks sein, damit das TCP-Fenster geschlossen wird, bevor die Ressourcen des internen Laufwerks erschöpft sind.

Die Größe des Empfangspuffers hängt von der Größe des TCP-Fensters, der Größe des maximalen TCP-Segments und der Zeit ab, die für den Empfang des Eingabeframes benötigt wird. Da die maximale Segmentgröße 300 Wörter beträgt (eine MODBUS-Anfrage benötigt maximal 256 Wörter + MBAP-Header), kann die Socket-Cache - Größe auf 900 Wörter angepasst werden, wenn 3 Frames zum Zwischengespeichern benötigt werden. Um die maximale Cache-Anforderung und die geplante Zeit zu erfüllen, können Sie die Größe des TCP-Fensters erhöhen.

TCP-Nodelay:

Normalerweise verursachen die Übertragung von kleinen Nachrichten (tinygrams genannt) keine Probleme, da die meisten LANs nicht überlastet sind, aber diese Tinygrams verursachen Überlastungen in WANs. Ein einfaches Szenario, genannt "NAGLE-Algorithmus", sammelt kleine Datenmengen und sendet sie dann als einzelne, wenn die TCP-Bestätigung der vorhergehenden Nachricht eintrifft.

Für eine bessere Echtzeitfunktion empfiehlt es sich, kleine Datenmengen direkt zu senden, anstatt zu versuchen, sie in einem Segment zu sammeln und zu senden. Aus diesem Grund wird empfohlen, die Option TCP-NODELAY zu erzwingen, die den "NAGLE-Algorithmus" für Client - und Serververbindungen deaktiviert.

SO-REUSEADDR:

Wenn ein MODBUS-Server eine TCP-Verbindung schließt, die von einem Remote-Client initiiert wurde, kann das lokale Slogan für die Verbindung nicht wieder verwendet werden, um eine neue Verbindung zu öffnen, während die Verbindung sich in einem "Time Wait" - Zustand befindet (zwei MSL: maximale Segmentlebensdauer).

Empfehlung: Geben Sie für jede Client - und Serververbindung die Option SO-REUSEADDR an, um diese Einschränkung zu umgehen. Diese Option ermöglicht es, sich selbst ein Passwort zuzuweisen, das als Teil der Verbindung auf den Client während der 2MSL-Periode wartet und auf die Sockelschnittstelle abhört.

SO-KEEPALIVE:

Das TCP / IP-Protokoll sendet keine Daten über eine leere TCP-Verbindung. Wenn also keine Daten an der TCP-Verbindung gesendet werden, werden keine Daten zwischen den beiden TCP-Modulen ausgetauscht. Dies setzt voraus, dass sowohl die Client - als auch die Server-Anwendung Zähler verwenden, um die Überlebensfähigkeit der Verbindung zu ermitteln, um die Verbindung zu schließen.

Empfehlung: Verwenden Sie die Option KEEPALIVE an beiden Enden der Client - und Serververbindung, um das andere Ende zu erfahren, ob es ausfällt und abstürzt oder ausfällt und neu gestartet wurde.

Wir müssen jedoch bedenken, dass die Verwendung von KEEPALIVE eine sehr gute Verbindung verursachen kann, die Kommunikationsunterbrechung bei einem augenblicklichen Ausfall verursacht und unnötige Netzwerkbandbreite verbrauchen wird, wenn der Verbindungstimer für einen zu kurzen Zeitrahmen gehalten wird.

• Parameter für die gesamte TCP-Schicht

TCP-Verbindungs - Erstellung-Zeitüberschreiten:

Die meisten Systeme, die von Berkeley eingeführt werden, legen eine Zeitfrist für die Erstellung neuer Verbindungen auf 75 Sekunden fest, ein Standardwert, der an die Einschränkungen der Echtzeit-Anwendung angepasst werden sollte.

Bewahren Sie die Verbindungsparameter:

Die Standardfreizeit für Verbindungen beträgt 2 Stunden.Überschreiten Sie diese Freizeit wird ein Keep-in - Connection - Prozess ausgelöst. Nachdem die erste Probation verbunden ist, werden maximal alle 75 Sekunden eine Probation gesendet, bis eine Antwort auf die Probation erhalten wird.

Die maximale Anzahl an Verbindungs-Halt - Proben, die auf einer freien Verbindung ausgegeben werden, beträgt acht. Wenn nach der maximalen Anzahl von Proben keine Antwort erhalten wird, sendet TCP ein Fehlersignal an die Anwendung, und die Anwendung entscheidet, die Verbindung zu schließen.

Parameter für Timeout und erneute Übersendung:

Wenn eine TCP-Nachricht verloren geht, wird diese Nachricht erneut gesendet. Eine Methode zum Erkennen von Verlusten besteht darin, eine Retoo-Timeout (RTO) zu verwalten, die beendet wird, wenn keine Bestätigung vom Remote-End erhalten wird.

TCP führt eine dynamische Bewertung des RTO durch. Dazu wird die Round-and - Round-Time (RTT) nach dem Senden jeder nicht-reversendeten Nachricht gemessen. Die Round-and - Round-Time (RTT) ist die Zeit, die eine Nachricht benötigt, um das Remote-Gerät zu erreichen und eine Bestätigung von dem Remote-Gerät zu erhalten. Die Hin - und Rückfahrtzeit für eine Verbindung wird dynamisch berechnet, aber wenn TCP nicht innerhalb von 3 Sekunden eine Schätzung der RTT erhalten kann, wird der Standardwert für RTT auf 3 Sekunden festgelegt.

Wenn der RTO bereits geschätzt wurde, wird er für die nächste Nachricht verwendet. Wenn die Bestätigung der nächsten Nachricht vor dem geschätzten RTO-Ende nicht erhalten wird, aktivieren SieIndexkompensation- Algorithmus für die Exponenzkompensation, wenn die Bestätigung für die nächste Nachricht vor dem geschätzten RTO-Abschluss nicht erhalten wird. Erlaubt die maximale Anzahl der Wiedersendungen derselben Nachricht innerhalb eines bestimmten Zeitraums. Wenn es keine Bestätigung gibt, wird die Verbindung beendet.

Sie können die maximale Anzahl der Wiederveröffentlichungen und die maximale Dauer der Wiederveröffentlichung vor dem Ende der Verbindung für bestimmte Stapel festlegen.

Im TCP-Standard sind einige Wiederübertragungsalgorithmen definiert:

• Der Jacobson RTO-Schätzungsalgorithmuswird verwendet, um die Wiederübertragungsauszeit (RTO) zu schätzen;
• Das Karn-Algorithmusweist darauf hin, dass keine RTO-Schätzung im Re-Send - Segment durchgeführt werden sollte;
• Der exponentielle Kompensationsalgorithmusdefiniert die Verdoppelung der Re-Send - Timeout für jedes Re-Send innerhalb der 64 - Sekunden-Obergrenze;
• Der schnelle Re-Send - Algorithmuserlaubt eine Re-Sendung nach Erhalt von drei Wiederholungen. Dieser Algorithmus wird in Betracht gezogen, weil die Erkennung von Nachrichtenverlusten, die möglicherweise zu einem LAN führen, schneller ist als die Erkennung, die auf die Beendigung des RTO wartet.

In der MODBUS-Implementierung wird die Verwendung dieser Algorithmen empfohlen.

Konfiguration der IP-Schicht - Parameter

IP-Parameter

Die folgenden Parameter müssen auf der IP-Ebene der MODBUS-Implementierung konfiguriert werden:

• Lokale IP-Adresse: Eine IP-Adresse kann eine der Klassen A, B oder C sein.
• Subnetzmasken: IP-Netzwerke können aus verschiedenen Gründen in Subnetze unterteilt werden: Verwendung verschiedener physikalischer Medien (z. B. Ethernet, WAN usw.), effizientere Nutzung von Netzwerkadressen und die Möglichkeit, den Netzwerkverkehr zu kontrollieren. Die Subnetzmaske muss mit dem Typ der lokalen IP-Adresse übereinpassen.
• Standard-Gateway: Die IP-Adresse des Standard-Gateways muss sich im selben Subnetz wie die lokale IP-Adresse befinden. Der Wert 0.0.0.0 ist verboten. Wenn kein Gateway definiert ist, kann dieser Wert auf 127.0.0.1 oder eine lokale IP-Adresse festgelegt werden.

Hinweis: ModbusTextübertragungservice erfordert keine Segmentfunktion auf der IP-Ebene.

Die lokale IP-Endseite sollte mit der lokalen IP-Adresse, der Subnetzmaske und dem fehlenden Gateway (anders als 0.0.0.0) konfiguriert werden.

Kommunikationsanwendungsschicht

MODBUS-Client

Abbildung 10: MODBUS-Client

MODBUS-Clientdesign

Das MODBUS / TCP-Protokoll ermöglicht ein einfaches Design eines Clients. Die folgende Abbildung beschreibt die wichtigsten Verarbeitungsvorgänge, bei denen ein Client eine MODBUS-Anfrage sendet und eine MODBUS-Antwort verarbeitet.

Abbildung 11: Modbus-Client - Betriebsdiagramm

Ein MODBUS-Client kann drei Arten von Ereignissen empfangen:

• Eine neue Anforderung von einer Benutzeranwendung zum Senden einer Anforderung, in der die MODBUS-Anforderung codiert und über das Netzwerk über den TCP-Management - Component-Dienst gesendet werden muss. Die unterste Ebene (TCP-Verwaltungsmodul) gibt eine Fehlermeldung zurück, die auf einen TCP-Verbindungsfehler oder eine andere Fehlermeldung zurückzuführen ist.
• Eine Antwort von TCP-Management, in dem der Client den Inhalt der Antwort analysieren und eine Bestätigung an die Benutzeranwendung senden muss.
• Zeitüberschreitung wegen keine Antwort beendet. Sie können eine Wiederversuchnachricht über das Netzwerk senden oder eine Negativbestätigung an die Benutzeranwendung.

Hinweis: Diese Wiederversuche werden vom MODBUS-Client initiiert, und andere Arten von Wiederversuchen können von der TCP-Schicht ohne TCP-Bestätigung durchgeführt werden.

Generierung von MODBUS-Anfragen

Nachdem der Client eine Anforderung von der Benutzeranwendung empfangen hat, muss er eine MODBUS-Anforderung generieren und diese an die TCP-Administration senden.

kann die generierende MODBUS-Anfrage in mehrere Unteraufgaben aufteilen:

• Instanzierung von MODBUS-Transaktionen, die es dem Client ermöglichen, alle benötigten Informationen zu speichern, um die Antwort mit der entsprechenden Anforderung zu übereinstimmen und Bestätigungen an die Benutzeranwendung zu senden.
• Codierung der MODBUS-Anfrage (PDU + MPAB-Header). Die Benutzeranwendung, die die Anforderung initiiert, muss alle benötigten Informationen bereitstellen, damit der Client die Anforderung codieren kann. Kodierung der MODBUS-PDU (MODBUS-Funktionscode, zugehörige Parameter und Anwendungsdaten) gemäß dem MODBUS-Protokoll. Füllen Sie alle Felder des MBAP-Nachrichtenkopfes. Anschließend wird der MBAP-Header als PDU-Präfix generiert, um die ADU-Anforderung des MODBUS zu generieren.
• Sendet eine ADU-Anforderung von MODBUS an das TCP-Management - Modul, das für die Suche nach einem Socket für das richtige TCP-Code auf dem Remote-Server zuständig ist. Neben der MODBUS-ADU muss auch die Ziel-IP - Adresse übergeben werden.

Die folgende Abbildung beschreibt den Prozess der Anforderungserstellung genauer als Abbildung 17.

Abbildung 12: Anforderung zur Erstellung eines Schematischen Operationsdiagramms

Das folgende Beispiel: MODBUS-Anforderung ADU-Codierung, die ein Wort von einem Remote-Server mit der Adresse 05 liest

• MODBUS-Anforderung ADU-Codierung:

(*) Siehe MODBUS-Protokollspezifikation [2]

• Transaktionsbezeichner

Transaktionsbezeichner werden verwendet, um eine Verbindung zwischen einer Anforderung und einer zukünftigen Antwort herzustellen. Daher muss diese Bezeichnung für eine TCP-Verbindung gleichzeitig eindeutig sein. Es gibt mehrere Möglichkeiten, diesen Bezeichner zu verwenden:

• kann beispielsweise als einfache "TCP-Sequenznummer" mit Zählern verwendet werden, die bei jeder Anforderung erhöht werden;
• kann auch als intelligenter Index oder Zeiger verwendet werden, um den Inhalt einer Transaktion zu identifizieren, um den aktuellen Remote-Server und die unbearbeiteten Anfragen zu speichern.

Normalerweise muss der Client auf einer seriellen MODBUS-Verbindung eine Anforderung nach dem anderen senden. Das bedeutet, dass dieser Client auf die Antwort auf die erste Anfrage warten muss, bevor er die zweite Anfrage sendet. Auf MODBUS TCP können Sie mehrere Anfragen an den gleichen Server senden, ohne auf die Bestätigung des Servers zu warten. Das Gateway zwischen MODBUS / TCP und der seriellen MODBUS-Verbindung ist für die Kompatibilität beider Operationen verantwortlich.

Die Anzahl der Anfragen, die der Server akzeptiert, hängt von seiner Kapazität ab, d. h. der Menge an Serverressourcen und der Größe des TCP-Fensters. Ebenso hängt die Anzahl der gleichzeitigen Transaktionen ab, die der Client initiiert, von der Ressourcenkapazität des Clients ab. Dieser Implementierungsparameter heißt "NnmberMaxofClientTransaction" und muss als Eigenschaft des MODBUS-Clients beschrieben werden. Abhängig vom Gerätetypen kann dieser Parameter zwischen 1 und 16 betragen.

• Einheit Identifikation

Dieses Feld wird für Routingzwecke verwendet, wenn Geräte in einem MODBUS - oder MODBUS + seriellen Verbindungs-Subnetz adressiert werden. In diesem Fall trägt die "Unit Identifier" die MODBUS-Sklavenstation-Adresse eines Remote-Geräts:

- Wenn ein MODBUS-Server mit einem MODBUS + oder MODBUS-Serial - Link-Subnetzwerk verbunden ist und die Adresse dieses Servers über eine Brücke oder ein Gateway konfiguriert, ist die MODBUS-Einheit Identifikation erforderlich, um die Slavenstation-Geräte zu identifizieren, die mit der Brücke oder dem Gateway verbunden sind. Die Ziel-IP - Adresse identifiziert die Adresse der Brücke selbst, während die Brücke die Anforderung an die richtige Slave-Gerät über die MODBUS-Einheit - Identifikation weiterleitet.

- Weist den MODBUS-Slaven in der seriellen Verbindung eine Adresse von 1 bis 247 (10 - Dezimal) zu, wobei die Adresse 0 als Broadcast-Adresse verwendet wird.

Bei TCP / IP wird die IP-Adresse verwendet, um den MODBUS-Server zu adressieren; daher ist die MODBUS-Einheit - Identifikation nutzlos. Es ist notwendig, den Wert 0xFF zu verwenden.

- Bei der Adressierung von MODBUS-Servern, die direkt mit einem TCP / IP-Netzwerk verbunden sind, wird empfohlen, keine gültige MODBUS-Sklavenstation - Adresse im Feld "Einheit-ID" zu verwenden. Im Falle einer Neuzuweisung von IP-Adressen in einem automatisierten System und wenn eine zuvor dem MODBUS-Server zugewiesene IP-Adresse dem Gateway zugewiesen wird, kann die Verwendung einer gültigen Slave-Adresse aufgrund einer schlechten Routing des Gateways zu Problemen führen. Mit einer ungültigen Slave-Adresse verworfen das Gateway einfach die MODBUD PDU ohne Probleme. Empfehlung: Bei der Verwendung von 0xFF als ungültiger Wert für die "Einheit-Identifikation".

Hinweis: 0 kann auch als direkte Kommunikation mit MODBUS / TCP-Geräten verwendet werden.

Verarbeitung von MODBUS Bestätigung

Bei einer TCP-Verbindung wird die Transaktionsbezeichnis im MBAP-Nachrichtenkopf verwendet, um die Antwort mit der ursprünglichen Anforderung zu verknüpfen, die zuvor an die TCP-Verbindung gesendet wurde, wenn ein Response-Frame empfangen wird:

• Wenn die Transaktionsbezeichnis keine ungelösten Transaktionen erwähnt, muss die Antwort verworfen werden;
• Wenn die Transaktionsbezeichner auf eine ungelöste Transaktion beziehen, muss die Antwort zerlegt werden, um eine MODBUS-Bestätigung (ja oder negative Bestätigung) an die Benutzeranwendung zu senden;

Die zerlegt Antwort ist eine Antwort, die den MBAP-Header und die MODBUS-PDU überprüft:

• Der MBAP-Header

Die Länge gibt die Größe der MODBUS-Antwort an, nachdem die Prüfprotokoll-Identifikation 0x0000 sein muss.

Wenn die Antwort von einem MODBUS-Servergerät kommt, das direkt mit einem TCP / IP-Netzwerk verbunden ist, reicht die TCP-Verbindungs - Identifikation aus, um den Remote-Server eindeutig zu identifizieren. Daher ist die in den MBAP-Headern enthaltene Einheitsbezeichnung ungültig und muss verworfen werden.

Wenn der Remote-Server an einem seriellen Links-Subnetz angeschlossen ist und die Antwort von einer Brücke, einer Router oder einem Gateway kommt, identifiziert die Einheit-Kennzeichnung (Wert ≠ 0xFF) den Remote-MODBUS - Server, der die ursprüngliche Antwort gesendet hat.

• MODBUS-Antwort - PDU

MUSS den Funktionscode überprüfen und das Modbus-Antwortformat gemäß dem MODBUS-Protokoll analysieren:

• Wenn der Funktionscode mit dem in der Anforderung verwendeten Funktionscode identisch ist und wenn das Format der Antwort korrekt ist, wird eine MODBUS-Antwort als Bestätigung an die Benutzeranwendung gesendet.
• Wenn der Funktionscode ein MODBUS-Ausnahmecode (Funktionscode + 80H) ist, gibt es eine Ausnahmeantwort als Bestätigung an die Benutzeranwendung aus.
• Wenn sich der Funktionscode von dem in der Anforderung verwendeten Funktionscode unterscheidet (= unerwarteter Funktionscode) oder wenn das Format der Antwort falsch ist, wird eine Fehlersignal als Negativbestätigung an die Benutzeranwendung gesendet.

Hinweis: Eine positive Bestätigung ist die Bestätigung, dass der Server den Befehl der Anforderung empfängt und darauf reagiert. Das bedeutet nicht, dass der Server die im angeforderten Befehl angeforderte Aktion erfolgreich ausgeführt hat (die MODBUS-Ausnahme - Antwort zeigt an, dass die Aktion ausgeführt wurde, dass es fehlgeschlagen ist).

Die folgende Abbildung beschreibt den Prozess der Bestätigungsbehandlung genauer als Abbildung 17.

Abbildung 13: Schematisches Diagramm der MODBUS-Bestätigungsverarbeitung

Timeout Management

Die Reaktionszeiten, die für die Verarbeitung von Transaktionen auf MODBUS / TCP erforderlich sind, werden absichtlich nicht angegeben.

Das liegt daran, dass MODBUS / TCP von E / A-Scans im Millisekundenbereich bis hin zu drahtlosen Fernverbindungen mit Verzögerungen von wenigen Sekunden für die breitesten Kommunikationsanwendungen vorgesehen ist.

Aus Sicht des Clients muss der Timeout die erwartete Übertragungsverzögerung im Netzwerk berücksichtigen, um eine angemessene Reaktionszeit zu bestimmen. Diese Übertragungsverzögerung kann ein paar Millisekunden in einem Ethernet-Switch oder Hunderte von Millisekunden in einer WAN-Verbindung betragen.

Umgekehrt sollte die Timeout-Zeit, die bei jedem Client-Start - App-Wiederversuch verwendet wird, größer sein als die maximale angemessene Reaktionszeit, die erwartet wird. Wenn dies nicht beachtet wird, besteht die potenzielle Gefahr einer Überlastung des Zielgeräts oder des Netzwerks, was wiederum zu mehr Fehlern führt. Dies ist eine Eigenschaft, die man immer vermeiden sollte.

In der Praxis scheint der Client-Timeout, der in Hochleistungs-Anwendungen verwendet wird, daher immer mit der Netzwerktopologie und der gewünschten Client-Performance zusammenhängen.

Systeme, bei denen der Zeitfaktor nicht sehr wichtig ist, verwenden häufig den TCP-Standardwert als Timeout-Wert, und auf den meisten Plattformen wird ein Kommunikationsfehler nach wenigen Sekunden gemeldet.

MODBUS-Serverseite

Abbildung 14: MODBUS-Serverseite

Die Rolle des MODBUS-Servers besteht darin, den Zugriff auf Anwendungsobjekte und den Dienst für Remote-Clients bereitzustellen.

Verschiedene Arten von Zugriffsmöglichkeiten je nach Anwendung des Benutzers:

• Einfacher Zugriff: Eigenschaften eines Applikationsobjekts erhalten oder festlegen;
• Erweiterter Zugriff: Starten eines speziellen Applikationsdienstes

Der MODBUS-Server muss:

• Ein Applikationsobjekt in ein lesbares oder schreibbares MODBUS-Objekt zugeordnet haben, um Eigenschaften eines Applikationsobjekts zu erhalten oder festlegen;
• bietet eine Methode zum Starten eines Dienstes für ein Applikationsobjekt;

Während des Laufens muss der MODBUS-Server empfangene MODBUS-Anfragen analysieren, die erforderlichen Aktionen verarbeiten und eine MODBUS-Antwort zurückgeben.

MODBUS-Server - Design

Das MODBUS-Server - Design hängt von zwei Aspekten ab:

• Der Art des Zugriffs auf Applikationsobjekte (einfacher Zugriff auf Eigenschaften oder erweiterter Zugriff auf Dienste) und
• Die Art der Interaktion zwischen dem MODBUS-Server und der Benutzeranwendung (synchron oder asynchron).

Die folgende Abbildung beschreibt die Hauptverarbeitungsprozesse, die der Server durchführt, um eine MODBUS-Anfrage von der TCP-Verwaltung zu erhalten und dann die Anfrage zu analysieren, die erforderlichen Aktionen zu verarbeiten und eine MODBUS-Antwort zurückzugeben.

Abbildung 15: Schematische Darstellung der Verarbeitung von MODBUS-Befehlvorgaben

Wie im vorherigen Schema gezeigt:

• Der MODBUS-Server selbst kann einige Dienste ohne Interaktion mit der Benutzeranwendung sofort verarbeiten;
• Einige Dienste erfordern möglicherweise auch eine deutliche Interaktion mit der verarbeiteten Benutzeranwendung;
• Einige erweiterte Dienste erfordern den Aufruf einer speziellen Schnittstelle, d. h. des MODBUS-Hintergrunddienstes. Beispielsweise kann ein Benutzeranwendungsdienst basierend auf einem Benutzeranwendungs-Schichtprotokoll mit mehreren Modbus-Anforderung / Antwort-Transaktionen gestartet werden. Der Hintergrund-Dienst ist für den ordnungsgemäßen Ablauf aller einzelnen MODBUS-Transaktionen verantwortlich, um die Ausführung globaler Benutzeranwendungsdienste zu erleichtern.

Eine vollständige Beschreibung wird in den folgenden Kapiteln gegeben.

Der MODBUS-Server kann mehrere MODBUS-Anfragen gleichzeitig empfangen und bedienen. Die maximale Anzahl an MODBUS-Anfragen, die ein Server gleichzeitig empfangen kann, ist eine der wichtigsten Eigenschaften des MODBUS-Servers. Diese Menge hängt vom Server-Design und seiner Verarbeitungs - und Speicherkapazität ab. Bezeichnen Sie diesen Implementierungsparameter als "NumberMaxOfServerTransaction" und müssen diesen Implementierungsparameter als Eigenschaft des MODBUS-Servers beschreiben. Abhängig von der Kapazität des Geräts beträgt der Wertbereich: 1 ~ 16.

Der Parameter "NumberMaxOfServerTransaction" hat einen signifikanten Einfluss auf den Betrieb und die Leistung des MODBUS-Servers. Besonders wichtig ist, dass die Anzahl der verwalteten gleichzeitigen MODBUS-Transaktionen die Reaktionszeit des Servers auf MODBUS-Anfragen beeinflussen kann.

Modbus PDU-Test

Die folgende Abbildung beschreibt den Modbus PDU-Prüfvorgang.

Abbildung 16: Flussdiagramm für die MODBUS-PDU - Überprüfung

Die MODBUS-PDU - Überprüfungsfunktion beginnt mit der Auflösung des MBAP-Headers. Das Protokoll-Identifikationsfeld muss überprüft werden:

• Diese Anweisung wird aufgehoben, wenn es sich von einem MODBUS-Protokolltyp unterscheidet.
• Wenn es richtig ist (= MODBUS-Protokolltyp; Wert 0x00), wird sofort ein Beispiel für eine MODBUS-Transaktion gegeben.

Die maximale Anzahl von MODBUS-Transaktionen, die ein Server von der angegebenen Entfernung entfernen kann, wird durch den Parameter "NumberMaxOfTransaction" (System - oder Konfigurationsparameter) definiert.

Im Falle einer ungültigen Transaktion generiert der Server eine MODBUS-Ausnahmeantwort (Ausnahmecode 6: Server beschäftigt).

Wenn die Transaktion gültig ist, wird sie gestartet, um folgende Informationen zu speichern:

• TCP-Verbindungsbezeichnis für das Senden der Anweisung (von der TCP-Administration angegeben)
• MODBUS-Transaktions-ID (im MBAP-Header angegeben)
• Einheitsbezeichnis (im MBAP-Header angegeben)

Danach wird die MODBUS-PDU zerlegt. Analysieren Sie zunächst den Funktionscode:

• Erstellen Sie eine MODBUS-Ausnahmeantwort (Ausnahmecode 1: Funktion ist ungültig)
• Wenn der Funktionscode empfangen wird, startet der Server eine Operation "MODBUS-Dienstverarbeitung".

MODBUS-Dienstverarbeitung

Abbildung 17: Abflussdiagramm für die MODBUS-Dienstverarbeitung

Abhängig von der Software - und Hardware-Architektur des Geräts im folgenden Beispiel kann die erforderliche MODBUS-Dienstverarbeitung auf verschiedene Weise durchgeführt werden:

• In einem kleinen Gerät oder einer Single-Thread - Architektur kann der MODBUS-Server direkt auf Benutzeranwendungsdaten zugreifen, und der Server selbst kann die angeforderten Dienste lokal verarbeiten, ohne Hintergrunddienste aufzurufen.

Diese Verarbeitung erfolgt gemäß den „MODBUS-Protokollspezifikationen". Im Falle eines Fehlers generiert eine MODBUS-Ausnahmeantwort.

• In einem modularen Multi-Prozessor - Gerät oder Multi-Thread - Architektur sind die "Kommunikationsschicht" und die "Benutzeranwendungsschicht" zwei unabhängige Entitäten, die Kommunikations-Entität kann vollständig einige unwichtige Dienste, während andere Dienste Anwendung Hintergrund-Dienst und Benutzeranwendung Entität koordinieren müssen.

Um die Interaktion mit der Benutzeranwendung zu ermöglichen, muss der MODBUS-Background - Dienst alle geeigneten Mechanismen ausführen, um die Transaktionen der Benutzeranwendung zu verarbeiten und die Benutzeranwendungsaufrufe und die entsprechenden Antworten korrekt zu verwalten.

Benutzeranwendungsschnittstelle (Hintergrundschnittstelle)

Im MODBUS-Hintergrunddienst können mehrere Strategien ausgeführt werden, um die Arbeit zu erledigen, obwohl diese Strategien in Bezug auf den Benutzernetzwerk-Durchsatz, die Benutzerbandbreite, die Reaktionszeit und sogar die Design-Aufwand nicht ausgewogen sind.

Der MODBUS-Hintergrund - Dienst übernimmt die entsprechende Schnittstelle für die Benutzeranwendung:

• Entweder eine physische Schnittstelle basierend auf einer seriellen Verbindung, oder ein Dual-Port - RAM-Schema, oder ein einfaches E / A-Kabel oder eine logische Schnittstelle basierend auf einem vom Betriebssystem bereitgestellten Nachrichtenübertragungservice.
• Die Schnittstellen zu Benutzeranwendungen können synchron oder asynchron sein.

Der MODBUS-Hintergrund - Dienst verwendet außerdem geeignete Designmuster, um Zielattribute oder Auslöserdienste zu erhalten / festzulegen. In einigen Fällen reicht ein einfacher „Gateway-Modus". In anderen Fällen, von einer einfachen Tauschtabellen-Historie bis zu komplexeren Wiederholungsmechanismen, müssen Designer einen "Proxy-Server - Modus" mit Cache-Richtlinien durchführen.

Der MODBUS-Background - Dienst ist dafür verantwortlich, das Protokoll für die Interaktion mit Benutzeranwendungen zu konvertieren. Daher muss es über Mechanismen verfügen, um die Trennung und Umstrukturierung von Nachrichten, die Gewährleistung der Datenkonsistenz und alle erforderlichen Synchronisierungen zu ermöglichen.

Erstellung von MODBUS-Antworten

Sobald die Anforderung verarbeitet wurde, muss der MODBUS-Server eine Antwort mit der entsprechenden MODBUS-Server - Transaktion generieren und die Antwort an die TCP-Verwaltungskomponente senden.

Abhängig von den Ergebnissen der Verarbeitung können zwei Arten von Antworten generiert werden:

• Positive MODBUS-Antworten:
• Response Function Code = Request Function Code
• MODBUS-Ausnahme - Antwort:
• Der Zweck ist es, dem Client Informationen über den vom Verarbeitungsprozess erkannten Fehler zu liefern
• Response Function Code = Request Function Code + 0x80
• Lieferung eines Ausnahmecodes zur Angabe der Ursache des Fehlers.

Die MODBUS-Antwort - PDU muss mit einem MBAP-Header Präfix versehen werden, der einen MBAP-Header generiert, indem die Daten im Transaktionskörper verwendet werden.

• Einheit-Identifier

Wenn eine Einheit-Identifier in einer empfangenen MODBUS-Anforderung angegeben ist, kopiert diese Einheit-Identifier und speichert sie im Körper der Transaktion.

• Länge

Der Server berechnet die Größe der MODBUS-PDU und des Unit Identifier Wörters. Legen Sie diesen Wert im Feld "Längen" fest.

• Vereinbarung Identifikation

Legen Sie das Protokoll-Identifikationsfeld auf 0x0000 (MODBUS-Protokoll) fest, um die Protokoll-Identifikation in der empfangenen MODBUS-Anforderung zu geben.

• Transaktionsidentifier

Legen Sie dieses Feld auf den Wert "Transaktionsidentifier" fest, der sich auf die ursprüngliche Anforderung bezieht und in dem gespeichert wird.

Gibt eine MODBUS-Antwort an den richtigen MODBUS-Client zurück, indem die im Transaktionskörper gespeicherte TCP-Verbindung verwendet wird. Wenn eine Antwort gesendet wird, muss der Transaktionskörper leer sein.

Implementierungsanleitung

Ziel dieses Kapitels ist es, ein Beispiel für die Implementierung eines Nachrichtenübertragungsdienstes vorzustellen. Das unten beschriebene Modell kann als Leitfaden für die Implementierung von MODBUS-Nachrichtenübertragungsdiensten durch Clients oder Servers verwendet werden.

Objektmodell zeichnen

Abbildung 18: Schematisches Modell des MODBUS-Nachrichtenübertragungservice - Objekts

Vier Hauptpakete bilden das Schema des Objektmodells:

• Konfigurationsschicht, die den Betriebsmodus der anderen Paketkomponenten konfiguriert und verwaltet
• TCP-Management, das TCP / IP-Stack ermöglicht und TCP-Verbindungen verwaltet Kommunikationsanwendungs-Layer - Verbindungen. Dies bezieht sich auf die Verwaltung von Socket-Schnittstellen.
• Die Kommunikationsanwendungsschicht besteht aus einem Modbus-Client auf der einen Seite und einem Modbus-Server auf der anderen Seite. Das Paket und die Benutzeranwendung sind verknüpft.
• Benutzeranwendung, die der Geräteanwendung entspricht, ist vollständig gerätebezogen und wird daher in diesem Dokument nicht behandelt.

Dieses Modell hat nichts mit der Auswahl der Implementierung zu tun, wie z. B. Betriebssystemtyp, Speicherverwaltung usw. Um diese Korrelationslosigkeit zu gewährleisten, werden generische Schnittstellen zwischen der TCP-Management - und Kommunikationsschicht sowie zwischen der Kommunikationsschicht und der Benutzeranwendungsebene verwendet.

Es gibt verschiedene Implementierungsmethoden, um diese Schnittstelle zu implementieren: Übertragung zwischen zwei Aufgaben, Shared-Speicher, serielle Verbindungsschnittstellen, Prozeduraufrufe usw.

Für die Definition des folgenden Implementierungsmodells wurden einige Annahmen gemacht:

• Statische Speicherverwaltung
• Synchronisierungsverarbeitung des Servers
• Verarbeitet Aufgaben, die über alle Sockets empfangen werden.

TCP-Managerpaket

Abbildung 19: MODBUS TCP-Managerpaket

Das TCP-Managerpaket enthält die folgende Klasse:

ClninterfaceConnexion: Diese Klasse verwaltet das Repository, das für Verbindungen verwendet wird.

CltemConnexion: Diese Klasse enthält alle Informationen, die zur Beschreibung einer Verbindung erforderlich sind.

CTCPConnexion: Diese Klasse bietet eine Methode zur automatischen Verwaltung von TCP-Verbindungen (CStackTCP _ IP bietet Schnittstellensockets).

CconnexionMngt: Diese Klasse verwaltet alle Verbindungen und sendet Anfragen / Antworten an den MODBUS-Server / MODBUS-Client über InterfaceindicationMsg und InterfaceRoseponseMsg. Diese Klasse befasst sich auch mit der Zugriffssteuerung durch Verbindungen.

CMBAP: Diese Klasse bietet Methoden zum Lesen / Schreiben / Analysieren von MODBUS MBAP.

CStackTCP_IP: Diese Klasse führt den Socket-Dienst aus und liefert die Konfiguration der Parameter für den Stack.

Konfigurationsschichtpaket

Abbildung 20: MODBUS-Konfigurationsschichtpaket

Das Konfigurationsschichtpaket enthält die folgende Klasse:

TConfigreObject: Diese Klasse gruppiert die Daten, die für die Konfiguration von Komponenten erforderlich sind. Füllen Sie diese Struktur mit der m _ Confire-Methode in der CooperatingMode-Klasse. Jede Klasse, die konfiguriert werden muss, erhält ihre eigenen Daten aus diesem Objekt. Die Konfigurationsdaten sind mit der Implementierung selbst verbunden. Daher bieten Sie die Eigenschaftstabelle der Klasse als Beispiel.

CoperatingMode: Diese Klasse hat die Aufgabe, TConfigueObject (je nach Benutzerkonfiguration) zu füllen und den Betriebsmodus der folgenden Klassen zu verwalten.

• CMODBUSServer
• CMODBUSClient
• CconnexionMngt

Pakete für die Kommunikationsschicht

Abbildung 21: MODBUS-Pakete für die Kommunikationsanwendungsschicht

Pakete für die Kommunikationsanwendungsschicht umfassen die folgenden Kategorien:

CMODBUSServer: Empfangen von MODBUS-Abfragen von InterfaceIndicationMsg (über die m_ServerRecievingMessage-Methode). Die Rolle dieser Klasse besteht darin, eine MODBUS-Antwort oder eine MODBUS-Ausnahme (aus dem Netzwerk eingegeben) basierend auf der Anfrage zu erstellen. Diese Klasse implementiert den Graph State für den MODBUS-Server. Eine Antwort kann nur generiert werden, wenn die Klasse OperatingMode die Benutzerkonfiguration und den richtigen Betriebsmodus gesendet hat.

CMODBUSClient: Lest die MODBUS-Anfrage aus der Klasse InterfaceUserApplication, wobei der Client die Anfrage mit der m _ ClientReceivingMessage-Methode empfängt. Diese Klasse implementiert das State Graph des MODBUS-Clients und verwaltet Transaktionen, die Anfragen mit Antworten verknüpfen (aus dem Netzwerk). Nur wenn die Klasse OperatingMode die Benutzerkonfiguration und den richtigen Betriebsmodus gesendet hat, können Sie eine Abfrage über das Netzwerk senden.

CTransaction: Diese Klasse implementiert Methoden und Strukturen zur Verwaltung von Transaktionen.

Interface-Klasse

CInterfaceUserApplication: Diese Klasse stellt eine Schnittstelle zu einer Benutzeranwendung dar und bietet zwei Möglichkeiten zum Zugriff auf Benutzerdaten. In der praktischen Implementierung wird dieser Ansatz je nach Hard - und Softwaregerät auf unterschiedliche Weise implementiert (entsprechend einem Terminal-Treiber, Zugriff auf eine Instanz von PCMCIA, freigegebenen Speicher usw.).

CInterfaceIndicationMsg: Diese Schnittstellenklasse wird verwendet, um Anfragen vom Netzwerk an den MODBUS-Server und Antworten vom Netzwerk an den Client zu senden. Diese Klasse ermöglicht TCPManagement und Kommunikations-Anwendungs - Schicht Pakete Verbindungen (aus dem Netzwerk). Die Implementierung dieser Klasse ist mit dem Netzwerk verbunden.

CInterfaceResponseMsg: Diese Schnittstellenklasse wird verwendet, um Antworten vom Server zu erhalten und Anfragen vom Client an das Netzwerk zu senden. Diese Klasse ermöglicht die Kommunikation von Anwendungsschicht-Paketen und TCPManagement-Verbindungen (zum Netzwerk). Die Implementierung dieser Kategorie bezieht sich auf die Ausrüstung.

Schematische Darstellung von Klassen für die Kommunikationsimplementierung

Das Schematische Darstellung der folgenden Klassen ist eine Darstellung der vollständigen Implementierung.

Abbildung 22: Schematisches Diagramm der Klasse

Sequenzdiagramm

Die folgenden beiden Sequenzdiagramme werden beschrieben, um die Client - und Server-MODBUS - Transaktionen zu illustrieren.

Abbildung 23: Modbus-Client - Sequenzdiagramm

Für ein besseres Verständnis des Client-Sequenzdiagramms ist der einfache Kommentar:

Erster Schritt: Lesen Sie die Anfrage von der Benutzeranwendung (über die m _ Read-Methode).

Schritt 2: Die Aufgabe des Clients ist es, MODBUS-Abfragen zu empfangen (mit der m _ ClientReceivingMessage-Methode). Dies ist der Einstiegspunkt für den Kunden. Um die Anfrage und die entsprechende Antwort miteinander zu koordinieren, verwendet der Client bei Anfrage eine Transaktionsressource (Klassenname: CTransaction). Senden Sie eine MODBUS-Anfrage an TCP _ Management über die Klasseinterface CInterfaceResponseMsg (über die m_MODBUSRequest-Methode).

Schritt 3: Wenn eine Verbindung hergestellt wurde und nichts mit der Verbindung zu tun ist, senden Sie eine Nachricht über das Netzwerk. Ansonsten muss eine offene Verbindung vorhanden sein, bevor eine Nachricht über das Netzwerk gesendet werden kann.

In diesem Moment wartet der Client auf die Antwort der letzten Diskussion (vom Remote-Server).

Schritt 4: Wenn die Antwort vom Netzwerk bereits erhalten ist, empfängt der TCP / IP-Stack die Daten (im verdeckten Aufruf der m _ EventOnStack-Methode).

Wenn eine Verbindung hergestellt wurde, liest man MBAP, um das Verbindungsobjekt wiederherzustellen (das Speicherressourcen und andere Informationen bereitstellt).

Lies Daten aus dem Netzwerk und sendet eine Bestätigung an den Client über die KlasseninterfaceIndicationMsg (mit der m_MODBUSConfirmation-Methode). Die Aufgabe des Clients besteht darin, die MODBUS-Bestätigung (mit der m_ClientReceivingResponse-Methode) zu empfangen.

Schließlich wird die Antwort an die Anwendung des Benutzers geschrieben (über die m_Writedata-Methode), und die Transaktionsressourcen sind frei.

Hier ist ein Beispiel für einen MODBUS-Server - Austausch:

Abbildung 24: MODBUS-Server - Sequenzdiagramm

Um das Client-Sequenzdiagramm besser zu verstehen, ist eine einfache Anmerkung wie folgt:

Erster Schritt: Ein Client hat eine Anfrage über das Netzwerk gesendet (MODBUS-Anfrage). Der TCP / IP-Stack empfängt die Daten (im verdeckten Aufruf der m_EventOnSocket-Methode).

Schritt 2: Die Anforderung kann eine Verbindungsanforderung sein oder nicht (über die m_IsConnexionRequest-Methode). Wenn die Anforderung eine Verbindungsanforderung ist, werden das Verbindungsgegenstand und der Puffer (m _ GetObjectConnexion) für das Senden und Empfangen von MODBUS-Frame zugewiesen. Danach müssen Sie die Verbindungszugriffskontrolle überprüfen und akzeptieren.

Schritt 3: Wenn die Abfrage eine MODBUS-Anfrage ist, kann die vollständige MODBUS-Abfrage (mit der m _ ReceiveData-Methode) ausgelesen werden. An diesem Punkt muss man MBAP analysieren (mit der m _ IsMdbHeadercorrect-Methode). Senden Sie den vollständigen Frame an die Server-Aufgabe über die CInterfaceIndicationMessaging-Klasse (mit der m_MODBUSIndication-Methode). Die Aufgabe des Servers besteht darin, MODBUS QUERY (mit der m_ServerReceivingMessage-Methode) zu empfangen und zu analysieren.

Wenn ein Fehler auftritt (nicht unterstützter Funktionscode usw.), generiert man eine MODBUS-Ausnahme - Frameform (m_BuildMODBUSException), andernfalls wird eine Antwort generiert.

Schritt 4: Senden Sie eine Antwort über das Netzwerk über CInterfaceResponseMessaging (mit der m_MODBUSResponse-Methode). Verarbeitung von Verbindungsobjekten (Wiederherstellung von Verbindungsdeskriptoren usw.) durch die m_SendData-Methode, Daten über das Netzwerk gesendet.

Beschreibung von Klassen und Methoden

MODBUS-Server - Klassen

Klassenname: CMODBUSServer

Klassenname:CMODBUSServer

Stereotype-Implementierungsklasse

bietet eine Methode zur Verwaltung von MODBUS-Nachrichtenübertragungen im Servermodus

MODBUS-Client - Klasse

Klassenname: CMODBUSClient

Klassenname: CMODBUSClient

Bietet eine Methode zur Verwaltung der MODBUS-Nachrichtenübertragung im Clientmodus

StereotypeImplementierung der Klasse

Klasse für Schnittstellen

Schnittstellenanzeige Klasse

Klassenname: CInterfaceIndicationMsg

Direkt bekannte Unterklasse

CConnexionMngt

Klassenname:CInterfaceIndicationMsg

Klasse

StereotypeSchnittstellen, die Nachrichten von TCP_Management an einen MODBUS-Server oder Client senden.

Interface-Antwort - Klasse

Klasse: CInterfaceResponseMsg

Unmittelbar bekannte Unterklasse:

CMODBUSClient、CMODBUSServer

class CInterfaceResponseMsg

Klasse, die Antworten oder Anfragen von einem Client oder Server an TCP_Management sendet

StereotypeSchnittstelle

Verbindungsverwaltungsklasse

Klassenname: CConnexionMngt

Kategorie Name:CConnexionMngt

Klasse, die alle TCP-Verbindungen verwaltet

Stereotype Implementierung Klasse