Beschreibung der Protokolle

Die Prozeduren 3964 und 3964R sowie die darauf aufsetzende Rechnerkopplung RK512 beschreiben einen Datenverkehr über eine serielle Schnittstelle mit dem sich beispielsweise eine Simatic S5 steuern lässt. Dabei definiert die Prozedur 3964, wie ein Datenblock übertragen wird, das heißt den Verbindungsauf- und Abbau sowie Mechanismen zur Sicherstellung der Datenintegrität. Die Prozedur 3964R unterscheidet sich von 3964 nur durch eine längere Quittierungszeit und dem Wegfall einer Blockprüfsumme. Die Rechnerkopplung RK512 setzt auf dieser Prozedur auf und definiert den Aufbau der Telegramme, in denen die Daten und Befehle verschickt werden.

Prozedur 3964 (R)

Die Datenübertragung erfolgt asynchron entweder über eine V24-Schnittstelle oder eine 20mA Stromschleife. Die Baudrate darf zwischen 110 und 9600 Baud liegen, das Datenformat ist 8E1.

Der Verbindungsaufbau erfolgt mit dem Zeichen STX, das die Gegenseite innerhalb der Quittungsverzugszeit (QVZ) von 2s (550ms für die Prozedur 3964) entweder mit DLE akzeptieren oder mit NAK ablehnen muss. Wird der Verbindungsaufbau abgelehnt, werden noch bis zu sechs Wiederholungen versucht, bevor ein Fehler an die nächst höhere Schicht gemeldet wird. Das Ende des Datenblocks wird durch die Zeichen DLE ETX markiert. An diese hängt die Prozedur 3964R noch eine Blockprüfsumme BCC an, die durch ein Exklusiv-Oder aller Datenbytes einschließlich der DLE-ETX Markierung gebildet wird. Die Daten müssen innerhalb der Zeichenverzugszeit (ZVZ) von 220ms aufeinanderfolgen. Die Gegenseite bestätigt den Empfang mit DLE oder, wenn Fehler festgestellt wurden, mit NAK.

Tabelle: Datenverkehr nach der Prozedur 3964R.

Sender STX Datenblock DLE ETX BCC
Empfänger DLE DLE

Empfängt der Sender während der Übertragung ein NAK, so bricht er den Vorgang ab und startet einen neuen Versuch.

Antwortet die Gegenseite auf einen Sendewunsch ebenfalls mit STX, so liegt ein Initialisierungskonflikt vor. Dieser wird durch die Vergabe von Prioritäten gelöst. Es gibt genau zwei Abstufungen, hohe und niedrige Priorität. Die Seite mit der niedrigen Priorität muss dann den Sendewunsch mit DLE akzeptieren.

Rechnerkopplung RK512

Die Rechnerkopplung RK512 setzt auf der Prozedur 3964 bzw. 3964R auf und beschreibt den Telegrammverkehr. RK512 unterscheidet dabei zwischen Befehls-, Quittungs- und Folgetelegrammen. Befehlstelegramme initiieren einen Telegrammverkehr und enthalten einen SEND oder FETCH Befehl, mit dem Daten übertragen werden. Quittungstelegramme beantworten diese Befehlstelegramme und enthalten eventuell angeforderte Daten. Konnte der Befehl nicht ausgeführt werden, so enthält das Quittungstelegramm einen entsprechenden Fehlercode. In einem Telegramm können maximal 128 Byte Daten enthalten sein. Sollen mehr Daten übertragen werden, so sind Folgetelegramme nötig.

Der Telegrammverkehr ist halb-duplex, das heißt, bevor die Gegenseite ein Telegramm quittiert, kann sie selbst erst ein Befehlstelegramm verschicken. Es kann jedoch kein Telegramm verschickt werden, solange die Gegenseite noch sendet und es kann auch kein weiteres Befehlstelegramm verschickt werden, bevor ein ausstehendes quittiert wurde.

Tabelle: Prinzipieller Aufbau eines Befehlstelegramms.

1 2 3 4 5 6 7 8 9 10
00h 00h high low high low
Befehl Typ Adresse Datenlänge CPU-Nr / KM

Tabelle: Prinzipieller Aufbau eines Folgetelegramms.

1 2 3 4
FFh 00h
Befehl

Tabelle: Prinzipieller Aufbau eines Quittungstelegramms.

1 2 3 4
00h 00h 00h
(FFh) Fehler

Das erste Byte im Telegrammkopf ist eine Telegrammkennung. Diese ist 00h für das erste Befehlstelegramm und FFh für ein Folgetelegramm. Quittungstelegramme wiederholen diese Kennung. In Befehls- und Folgetelegrammen spezifiziert das dritte Byte, ob es sich um ein FETCH oder ein SEND Telegramm handelt und das vierte Byte den Datenbausteintyp.

Befehlstelegramme enthalten im fünften und sechsten Byte die Adresse und im siebten und achten Byte die Datenlänge in Worten oder Bytes. In den beiden letzten Bytes kann eine CPU-Nummer und ein Koordinierungsmerker angegeben werden.

Quittungstelegramme enthalten im vierten Byte einen Fehlercode. Wurde der Befehl erfolgreich verarbeitet, so ist dieser Code 0, ansonsten gibt er Aufschluss über die Fehlerart.

Daten, die eventuell übertragen werden sollen, folgen unmittelbar im Anschluss an den Telegrammkopf.