DE3925843A1 - Verfahren zur uebertragung von datentelegrammen - Google Patents

Description

Die Erfindung bezieht sich auf ein Verfahren zur Über­ tragung von Datentelegrammen zwischen zwei Stationen über eine Übertragungsstrecke, die für ein gleichzeiti­ ges Senden und Empfangen in beiden Richtungen eingerich­ tet ist, und wobei nach einer Übertragungsstörung eine folgerichtige Fortsetzung der Datenübertragung, anknüp­ fend an das zuletzt richtig übertragene Datentelegramm, erfolgt.

Ein solches Verfahren ist aus der DE-PS 34 15 936 be­ kannt. Bei diesem Verfahren wird eine folgerichtige Wie­ deraufnahme eines Austausches von Datentelegrammen da­ durch bewirkt, daß die Station, die ein verfälschtes Datentelegramm empfängt, ein prüfbares Synchronisations­ telegramm sendet, wobei die Synchronisationstelegramme einen Zählwert enthalten, der die Anzahl der von der jeweiligen Station seit der letzten Sendung eines Daten­ telegramms nacheinander gesendeten Synchronisationstele­ gramme angibt. Die Datentelegramme enthalten dagegen keine Zählwerte oder sonstige Kennung. Dadurch wird im fehlerfreien Fall eine effiziente Datenübertragung er­ reicht. Trotzdem besteht besonders für eine Anwendung in leittechnischen Anlagen mit hohem Datenaufkommen Bedarf an einer weiteren Steigerung der Übertragungsleistung und an einer Ergänzung des Übertragungsprotokolls.

Der Erfindung liegt daher die Aufgabe zugrunde, ein ver­ bessertes Verfahren zur Übertragung von Datentelegrammen anzugeben.

Diese Aufgabe wird gelöst durch ein Verfahren zur Über­ tragung von Datentelegrammen in einer Übertragungsein­ richtung zwischen zwei Stationen über eine Übertragungs­ strecke, die für ein gleichzeitiges Senden und Empfangen in beiden Richtungen eingerichtet ist, welches nach ei­ ner Übertragungsstörung mit Hilfe von Synchronisations­ telegrammen eine folgerichtige Wiederaufnahme des Aus­ tauschs von Datentelegrammen sicherstellt, wobei für die Übertragung Pakete gebildet werden, die aus einem oder mehreren Telegrammen bestehen, bei denen es sich um Da­ tentelegramme, Synchronisationstelegramme oder um eine Folge von Daten- und Synchronisationstelegrammen handeln kann, und wobei in ein Paket, dessen Sendung noch nicht abgeschlossen ist, Synchronisationstelegramme im Be­ darfsfall eingefügt werden.

Die mit der Erfindung vorgeschlagene Paketierung von Da­ tentelegrammen und die Möglichkeit, Synchronisationste­ legramme als Steuerungstelegramme in eine laufende Über­ tragung eines Pakets von Telegrammen einzufügen, führt zu einer Steigerung der Übertragungsleistung. Da eine Übertragung von Paketen in beiden Übertragungsrichtungen gleichzeitig ablaufen kann und in die Folge von Datente­ legrammen eingeschleuste Synchronisationstelegramme emp­ fangsseitig abgezweigt und unverzüglich ausgewertet wer­ den, kann die Übertragungseinrichtung schnell auf Über­ tragungsstörungen reagieren und eine wiederholte Sendung veranlassen.

Nach einer vorteilhaften Ausgestaltung erfolgt die Pa­ ketbildung dadurch, daß die einzelnen Telegramme eine Folgekennung enthalten, die besagt, daß mindestens ein weiteres Telegramm folgt. Wenn diese Folgekennung nicht gesetzt ist, handelt es sich um das letzte Telegramm eines Pakets. Telegramme sind eine Folge von Zeichen.

Weiterhin wird vorgeschlagen, die beiden Stationen der Übertragungseinrichtung im Normalbetrieb gleichberech­ tigt arbeiten zu lassen, jedoch zur Initialisierung und zur Prüfung der Funktionsfähigkeit auf einen master/sla­ ve-Betrieb umzustellen.

Im master-slave-Betrieb wird die slave-Station aufgefor­ dert, ein definiertes Synchronisationstelegramm als Ant­ worttelegramm zu senden. Das Eintreffen des Antwortte­ legramms kann zeitlich überwacht und für eine Fehleraus­ wertung genutzt werden.

Zur Steuerung des Übertragungsablaufs, insbesondere bei gestört empfangenen Telegrammen, werden unterschiedliche Synchronisationstelegramme verwendet und als Kontext einer Station bezeichnete Merker und Zähler benutzt. Empfangene Telegramme werden nur dann zur weiteren Ver­ arbeitung freigegeben, wenn das gesamte Paket störungs­ frei empfangen wurde.

Das Übertragungsverfahren ist in Form von Regeln defi­ niert, die in drei Gruppen gegliedert sind. Weitere Ein­ zelheiten und Vorteile des Verfahrens sind aus dem in der Zeichnung dargestellten und nachstehend beschriebe­ nen Ausführungsbeispiel ersichtlich.

Es zeigen:

Fig. 1 ein Blockdiagramm, das die Struktur zweier Stationen angibt, die geeig­ net sind zur Durchführung des erfin­ dungsgemäßen Übertragungsverfahrens. Außerdem sind die Namen der verwen­ deten Telegramme angegeben.

Fig. 2 liefert eine Legende zum Blockdia­ gramm nach Fig. 1 sowie zu einem Übertragungsdiagramm nach Fig. 3.1 bis 3.4,

Fig. 3.1 bis 3.4 Darstellung von vier Teilen eines beispielhaften Übertragungsdia­ gramms.

1.0 Ausführungsbeispiel

Das Ausführungsbeispiel bezieht sich auf ein Übertra­ gungsverfahren, das im sogenannten full-duplex-Betrieb arbeitet und für den Einsatz in der Gebäudeleittechnik entwickelt wurde.

2.0 Eigenschaften des Verfahrens

Das Verfahren eignet sich zur Übertragung digitaler Da­ ten zwischen zwei Prozessoren oder Rechnern, die hier als Stationen bezeichnet sind. Das Verfahren definiert die Arbeitsweise der Übertragungseinrichtung in jeder Station.

Das Verfahren ermöglicht die optimierte, gesicherte und gleichzeitige Übertragung von Daten zwischen zwei Sta­ tionen. Diese Daten werden hier als Datentelegramme be­ zeichnet. Die kontrollierte Übertragung dieser Datente­ legramme wird ermöglicht durch zusätzliche Übertragung von Steuerinformation, hier als Synchronisationstele­ gramme bezeichnet.

Das zeitliche Auftreten von zu sendenden Datentelegram­ men, also das Datenaufkommen, kann dabei kontinuierlich oder auch spontan erfolgen.

Das Verfahren ermöglicht die Übertragung über einfache asynchrone und serielle Schnittstellen und benötigt als Übertragungsmedium nur eine einfache Dreiaderleitung.

Eine optimierte Übertragung wird erzielt durch Paketie­ rung der zu übertragenden Telegramme.

Eine gesicherte Übertragung wird erzielt durch die Über­ tragung eines Paritätsbits in jedem Zeichen eines Tele­ gramms und einer Prüfsumme innerhalb jedes Einzeltele­ gramms. Gesendete Telegramme werden in einem backup- Speicher gehalten, bis sie durch die Partnerstation quittiert werden. Dadurch wird eine Wiederholung des Sendens eines kompletten Paketes oder eines Teils des Paketes ermöglicht nach fehlerhaftem Empfang in der Partnerstation.

Das Verfahren ermöglicht gleichzeitiges Senden von Da­ tentelegrammen und Synchronisationstelegrammen aus jeder Station, so daß die Übertragung "full-duplex" erfolgen kann. Dies bedeutet, daß beide Stationen prinzipiell immer bereit sind, Telegramme zu empfangen.

Das gleichzeitige Übertragen von Telegrammen zwischen beiden Stationen verhindert, daß das Senden von Tele­ grammen wegen des Empfangs von Telegrammen und der Emp­ fang von Telegrammen wegen des Sendens von Telegrammen verzögert wird.

Das Senden von Daten ist nur dann möglich, wenn der emp­ fangende Prozessor seine Bereitschaft, ab jetzt wieder Daten zu empfangen, dem sendenden Prozessor signalisiert hat, was als kontrollierte Weitergabe von Daten bezeich­ net wird.

Innerhalb der Initiierung der Übertragung ist einer Sta­ tion eine master-Funktion zugeteilt, nach Ende der In­ itialisierung arbeiten beide Stationen symmetrisch. In Zeitphasen, in denen keine Datentelegramme zur Übertra­ gung vorliegen, kontrolliert die master-Station die Funktionsfähigkeit der slave-Station und des Übertra­ gungsweges durch zyklisches Senden eines zu beantworten­ den Synchronisationstelegramms. Dieser Verfahrensschritt wird mit lifeloop bezeichnet.

3.0 Einsatzmöglichkeiten des Verfahrens

Die Eigenschaften des Verfahrens, wie optimierte, gesi­ cherte und gleichzeitige Datenübertragung sowie günsti­ ges Verhältnis zwischen übertragenen Nutz- und Steuerte­ legrammen und die Möglichkeit, Daten spontan senden zu können, bieten dessen Einsatz in der Prozessleittechnik an.

Nach dem Verfahren können prinzipiell jeweils zwei Rech­ ner gekoppelt werden. Es unterstützt jedoch auch ver­ maschte Rechnernetze, bestehend aus Kaskadierungen oder sternförmigen Strukturen. Bei Kaskadierung, also Hinter­ einanderschaltung von Rechnern, ist in jedem Rechner, der innerhalb des Gesamtübertragungsweges zwischen zwei anderen Rechnern angeordnet ist, die Übertragungsein­ richtung doppelt vorhanden. Bei sternförmigen Strukturen ist in jedem Mittelpunkts-Rechner die Übertragungsein­ richtung in der gleichen Anzahl vorhanden, wie die An­ zahl von Satelliten-Rechnern, die an den Mittel­ punkts-Rechner angeschlossen sind.

4.0 Definition des Übertragungsprotokolls 4.1 Struktur einer Station

Fig. 1 zeigt die Struktur einer ersten Station U und einer zweiten Station I, die identisch sind. Fig. 2 zeigt weitere Einzelheiten zum Kontext der Station.

Jede Station U, I besteht aus einem ersten Puffer 1 für zu sendende Datentelegramme und einem zweiten Puffer 2 für zu empfangende Datentelegramme. Diese beiden Puffer 1, 2 dienen innerhalb einer Station U, I zur Weitergabe von Datentelegrammen zwischen der Übertragungseinrich­ tung und den datenverarbeitenden Funktionen der Station U, I.

Der Datenempfangspuffer 2 der Stationen muß mindestens so groß definiert werden, wie der Datensendepuffer 1 der Stationen U, I. Diese Größe bestimmt auch die Größe ei­ nes nicht dargestellten backup-Speichers und die maxima­ le Anzahl der in einem Paket enthaltenen Datentelegram­ me.

Die Station U hat die im Abschnitt 2.0 bereits erwähnte Funktion einer master-Station, durch welche die Initi­ alisierung der Übertragung und die Überwachung lifeloop ausgelöst wird.

Innerhalb der aus den Stationen U, I bestehenden Über­ tragungseinrichtung ist das hier beschriebene Verfahren implementiert. Die Aufgabe der Übertragungseinrichtung ist die Anwendung der Daten-, Protokoll- und backup-Re­ geln bezüglich:

• - Empfang von Telegrammen; Prüfung auf Validität (Prüfsumme, Parität).
• - Trennung von empfangenen Daten und Synchronisat­ ionstelegrammen.
  Datentelegramme werden in den Datenempfangspuffer eingetragen, Synchronisationstelegramme bewirken das Senden von Daten und Synchronisatinstelegrammen und die Aktualisierung des Stationskontextes (vergl. Abschnitt 4.3).
• - Aktualisierung des Stationkontextes.
  Als Kontext werden stationstypische Merker und Zäh­ ler bezeichnet.
• - Senden von Telegrammen.
  Anhand des Stationskontextes werden vorliegende Datentelegramme aus dem Datensendepuffer und Syn­ chronisationstelegramme gesendet.

4.2 Telegrammarten

Zwischen den Stationen werden Daten- und Synchronisati­ onstelegramme ausgetauscht. Sie werden durch ihre Namen gekennzeichnet. Der erste Buchstabe des Namens bezeich­ net die absendende Station, also U oder I. Jedes Tele­ gramm enthält innerhalb der Übertragung eine Folgeken­ nung, die angibt, ob ein weiteres Telegramm innerhalb dieses Paketes folgt oder ob dieses Telegramm, das letz­ te innerhalb des Paketes ist. Die Folgekennung wird in der Übertragungseinrichtung dem zu sendenden Telegramm in entsprechender Polarität hinzugefügt und aus dem emp­ fangenen Telegramm nach Prüfung seiner Polarität ent­ fernt.

Datentelegramme werden als xD bezeichnet.

Folgende Synchronisationstelegramme werden verwendet:

• - xREN (UREN, IREN), request next.
  Anforderung des Sendens weiterer Datentelegramme.
• - xREL (UREL, IREL), request last.
  Anforderung des wiederholten Sendens der zuletzt gesendeten Telegramme.
  Dieses Telegramm enthält die Kennungen VAREC und CIVTEL (vergl. Kontext der Station, Abschn. 4.3).
• - xxLIF (URLIF, IALIF), request/answer life.
  Station U fordert mittels URLIF ein Lebenssignal von Station I an, das diese mit IALIF der Station U sendet (vergl. lifeloop, Abschn. 4.6).
• - xRINI (URINI, IRINI), request initialisation.
  Mit URINI fordert Station U eine Initialisierung der Station I an.
  Mit IRINI fordert Station I ein Telegramm URINI von Station U an.
  Nach Empfang von xRINI initiiert jede Station ihren Kontext.
• - xACK (UACK, IACK) acknowledge.
  Quittierung eines valide und komplett empfangenen Pakets. Dieses Telegramm enthält die Kennung VAREC (vergl. Kontext der Station, Abschn. 4.3).

4.3 Kontext der Station

Als Kontext einer Station werden stationstypische Merker und Zähler bezeichnet.

Der Kontext besteht aus:

• - backup
  Zur Telegrammwiederholung nach Empfang eines Tele­ gramms xREL muß ein backup für gesendete Telegramme geführt werden.
  Der backup-Speicher ist als umlaufender Puffer (Ringpuffer) gestaltet.
  Der backup-Speicher muß mindestens dreimal so groß dimensioniert werden, wie die maximale Anzahl von einzelnen Datentelegrammen innerhalb eines Pakets.
  (Vergl. Paket, Abschn. 4.4)
  Das backup kann zu keinem Zeitpunkt mehr Datentele­ gramme enthalten, als maximal in einem Paket ent­ halten sind.
  (Vergl. backup-Regeln, Abschn. 4.7.3)
• - VAREC (valid received)
  VAREC ist ein Zähler für die Anzahl der valide (un­ verfälscht) empfangenen Telegramme seit Senden des letzten Telegranms xACK.
  Bei Senden von xREL oder xACK wird der aktuelle Kontext VAREC diesen Telegrammen eingeschrieben. Bei Empfang von xREL oder xACK wird der darin ent­ haltene VAREC für die Referenzierung des backup benötigt.
  (Vergl. Protokoll-Regeln, Abschn. 4.7.2)
• - CIVSTA (counter invalid receiving in station)
  CIVSTA ist ein Zähler für die Anzahl der invalide (verfälscht) empfangenen Telegramme.
  Bei Senden von xREL wird der aktuelle Kontext CIV­ STA diesem Telegramm als CIVTEL (counter invalid receiving in telegramm) eingeschrieben.
  Bei Empfang von xREL wird der darin enthaltene Kon­ text CIVTEL mit dem aktuellen CIVSTA verglichen, um zu entscheiden, ob Telegramme aus dem backup wie­ derholt zu senden sind oder ob xREL zu senden ist, um die Partnerstation zum wiederholten Senden aus derem backup aufzufordern.
  Diese Funktionalität ermöglicht, daß nach mehrfach invalide (verfälscht) empfangenen xREL (länger an­ dauernde Übertragungsstörung, d. h. nur Telegramme UREL/IREL werden noch gesendet) genau die Station das Senden aus ihrem backup beginnt, deren Tele­ gramme zuerst von der Partnerstation verfälscht empfangen wurden.
  (Vergl. Protokoll-Regeln, Abschn. 4.7.2)
• - WRR (wait until complete repetiton received)
  WRR ist ein Merker der angibt, ob nach Senden eines Telegramms xREL der Empfang aller Telegramme abge­ schlossen ist, deren wiederholtes Senden angefor­ dert wurde (WRR=0, "gelöscht"), oder ob deren Emp­ fang noch nicht komplett abgeschlossen ist (WRR=1, "gesetzt").
  (Vergl. Protokoll-Regeln, Abschn. 4.7.2)

4.4 Paket

Ein Paket besteht aus einem oder mehreren Telegrammen, und zwar Daten- oder Synchronisationstelegrammen, wobei im letzten Telegramm eines Pakets die Folgekennung nicht gesetzt, aber in allen anderen Telegrammen gesetzt ist. Ein Paket kann somit auch nur aus Synchronisationstele­ grammen bestehen.

Nach dem Empfang eines Telegramms xREN werden alle Da­ tentelegramme gesendet, die zu diesem Zeitpunkt im Da­ tensendepuffer vorliegen.

Dadurch kann bei Vorliegen von vielen zu übertragenden Datentelegrammen das Verhältnis aus der Anzahl von Da­ tentelegrammen und von Synchronisationstelegrammen we­ sentlich optimiert werden.

In dieses Paket werden gegebenenfalls Synchronisations­ telegramme eingebettet, falls diese zu diesem Zeitpunkt zu senden sind. Liegt nur ein Datentelegramm im Daten­ sendepuffer vor, wird dieses sofort gesendet, ohne auf weitere Datentelegramme zu warten. Die maximal mögliche Anzahl von Telegrammen in einem Paket ergibt sich aus der maximal möglichen Anzahl von Datentelegrammen im Datensendepuffer zuzüglich der im Paket eingebetteten Synchronisationstelegramme.

Die maximale Anzahl der in ein Paket eingebetteten Syn­ chronisationstelegramme kann nicht genau festgelegt wer­ den, was durch die Dynamik der fullduplex-Übertragung bedingt ist. Wird z. B. gerade das Senden von 64 Datente­ legrammen in Station U begonnen, und die Station U hat gerade ein Paket mit genau einem Datentelegramm empfan­ gen und gespeichert, bettet die Station U sofort ein Synchronisationstelegramm UREN in das Paket an Station I ein, welches Station I veranlaßt, sofort ein weiteres Paket mit genau einem Datentelegramm zu senden, da in Station I zu diesem Zeitpunkt nicht mehr Datentelegramme vorliegen. Dieses wird in Station U empfangen und ge­ speichert und sofort ein neues Synchronisationstelegramm UREN in die immer noch laufende Übertragung von Station U zu Station I eingebettet. Somit treten innerhalb eines Pakets schon zwei UREN auf.

Die ebenfalls beteiligten Telegramme xACK sind in diesem vereinfachten Beispiel nicht berücksichtigt.

Die Begrenzung der Anzahl von Datentelegrammen innerhalb eines Pakets ermöglicht die Dimensionierung der Daten­ empfangs- und Datensendepuffer, welche generell nur Datentelegramme (keine Synchronisationstelegramme) ent­ halten. Synchronisationstelegramme werden vom Empfänger nicht gespeichert, sondern es wird innerhalb der Über­ tragungseinrichtung sofort auf diese reagiert.

4.5 Initiierung der Übertragung

Eine Initiierung der Übertragung ist nötig nach dem Start (Einschalten, Erstanlauf) oder Neustart (vergl. Fehlerbehandlung bei gestörter Übertragung im Abschnitt 4.8) einer der beiden Stationen.

Während der Initialisierung arbeiten die Übertragungs­ einrichtungen der Stationen nicht symmetrisch, sondern es erfolgt eine master/slave-Rollenverteilung, wobei hier die Station U als master definiert ist.

Wird der master gestartet, initiiert er seinen Kontext (vergl. Protokoll-Regeln, Abschn. 4.7.2) und sendet das Synchronisationstelegramm URINI. Der slave empfängt die­ ses Telegramm und initiiert seinerseits seinen Kontext. Nach Abschluß seiner Initialisierung sendet der slave das Synchronisationstelegramm IREN, er kann also Daten­ telegramme empfangen. Empfängt der master dieses Tele­ gramm IREN, so sendet er seinerseits ein Telegramm UREN, was bedeutet, daß auch er Datentelegramme empfangen kann.

Wird der slave (Station I) gestartet, so fordert dieser seine Initialisierung durch den master an. Dazu sendet er das Synchronisationstelegramm IRINI. Nach dem Empfang eines Telegramms IRINI im master initiiert dieser seinen Kontext und sendet das Synchronisationstelegramm URINI an den slave.

Danach erfolgt der gleiche Ablauf wie beim Start des masters.

Der Empfang des Telegramms URINI im slave löst bei die­ sem eine Initiierung seines Kontextes aus. Danach sendet der slave ein Telegramm IREN. Nach Empfang dieses Tele­ gramms IREN im master sendet dieser das Synchronisati­ onstelegramm UREN. Beide Stationen können nun Datentele­ gramme empfangen.

Zusätzlich zur Initiierung des Kontextes kann, falls nötig, auch eine Initiierung innerhalb der datenverar­ beitenden Funktionen der Station stattfinden.

Im master wird der Zeitraum zwischen Senden von URINI und Empfang von IREN überwacht (timeout). Kann der ma­ ster das Synchronisationstelegramm IREN nicht rechtzei­ tig oder nicht valide (unverfälscht) empfangen, liegt eine gestörte Übertragung vor (vergl. Fehlerbehandlung bei gestörter Übertragung, Abschn. 4.8 und Neustart der Übertragung, Abschn. 4.8.3).

4.6 Lifeloop

In längeren Zeitphasen, in denen in keiner Station Da­ tentelegramme zur Übertragung vorliegen, ist es sinn­ voll, die Funktionsfähigkeit des Übertragungsweges zu kontrollieren. Diese Kontrolle wird mittels einer life­ loop durchgeführt.

Die lifeloop ist nicht symmetrisch implementiert, d. h. nur eine Station, als master bezeichnet, startet aktiv die life-loop, nachdem sie nach definierter Zeit kein Telegramm empfangen hat. Mittels der lifeloop wird auch die Funktionalität des slave kontrolliert. Hier ist Sta­ tion U als master definiert.

Der master sendet das Synchronisationstelegramm URLIF, und erwartet innerhalb einer bestimmten Zeit das vom slave als Antwort zu sendende Synchronisationstelegramm IALIF.

Kann der master IALIF nicht rechtzeitig empfangen, liegt eine gestörte Übertragung vor (vergl. Fehlerbehandlung bei gestörter Übertragung, Abschn. 4.8).

4.7 Übertragungs-Regeln

Das vorliegende Übertragungsverfahren ist definiert als Summe einzelner Regeln, die in der Übertragungseinrich­ tung implementiert sind.

Diese Regeln gelten gleichermaßen sowohl für die Station U wie für die Station I.

Die Regeln sind in drei Gruppen zusammengefaßt:

• - Daten-Regeln : (DR n) Übergabe von Datentele­ grammen
• - Protokoll-Regeln : (PR n) Abfolge von Telegrammen, Kontext
• - backup-Regeln : (BR n) Referenzierung des backup

Bei den in den Regeln verwendeten Begriffen "xACK (va­ rec)" und "xREL (varec) (civtel)" bedeutet (varec) den im Telegramm enthaltenen Wert des Zählers VAREC, (civ­ tel) den im Telegramm enthaltenen Wert des Zählers CIVSTA jeweils als Kopie aus dem Kontext der sendenden Sta­ tion U oder I.

4.7.1 Daten-Regeln

• - Datenregel DR 1
  Datentelegramme werden, sobald sie in einem Daten­ sendepuffer vorliegen, erst dann gesendet, nachdem zuvor ein Synchronisationstelegramm xREN empfangen wurde. Alle Telegramme aus dem Datensendepuffer werden innerhalb eines Pakets gesendet.
• - Datenregel DR 2
  Ein Synchronisationstelegramm xREN wird nach dem Empfang von Datentelegrammen in einem Datenemp­ fangspuffer erst dann gesendet, wenn diese von den datenverarbeitenden Einrichtungen ausgelesen wur­ den, und somit der Datenempfangspuffer wieder frei ist für neu zu empfangende Datentelegramme.
• - Datenregel DR 3
  Bei störungsfreier Übertragung werden Datentele­ gramme xD und Synchronisationstelegramme xREN, xACK, URLIF, IALIF ausgetauscht.

4.7.2 Protokoll-Regeln

• - Protokoll-Regel PR 1
  Datentelegramme und Synchronisationstelegramme kön­ nen innerhalb eines Pakets gemischt auftreten.
• - Protokoll-Regel PR 2
  Das Synchronisationstelegramm xACK dient nur zur Steuerung für das Löschen des backup-Speichers, nicht aber zur Synchronisation von Senden/Empfan­ gen. Somit muß nach dem Senden eines Pakets vor dem Senden eines nächsten Pakets nicht auf den Empfang eines xACK gewartet werden.
• - Protokoll-Regel PR 3
  Initiierung des stationseigenen Kontexts nach einem Start der Station:
  CIVSTA=0 counter invalid receiving in station
  VAREC=0 counter for valid tel received (tel=Telegramm)
  backup=0 backup für gesendete tel ist leer
  Merker WRR=0 Wait until complete repetition re­ ceived
• - Protokoll-Regel PR 4
  Ein originales (nicht wiederholtes) Telegramm xACK (varec) wird sofort gesendet nach Empfang eines validen und kompletten Pakets, das andere Telegram­ me als xACK, bzw. xREL enthält.
  Nach Senden eines originalen Telegramms xACK (va­ rec) wird VAREC gelöscht.
  Nach Senden eines Telegramms xACK (varec) aus dem backup wird VAREC nicht gelöscht.
• - Protokoll-Regel PR 5
  Jedes original gesendete Telegramm, außer xREL, wird in das backup geschrieben.
  Bei einem original gesendeten Telegramm xACK (va­ rec) wird somit auch dieser (varec), also dieser Wert des Zählers VAREC, Bestandteil des Telegramms im backup.
• - Protokoll-Regel PR 6
  Jedes valide empfangene Telegramm, außer xREL, wird in VAREC gezählt.
  (Für ein empfangenes xREL gelten spezielle Regeln).
• - Protokoll-Regel PR 7
  Nach jedem valide empfangenen Telegramm, außer xREL, wird CIVSTA gelöscht.
  (Für ein empfangenes xREL gelten spezielle Regeln).
• - Protokoll-Regel PR 8
  Nach Empfang eines Telegramms xACK (varec) werden sofort, ohne auf das Ende des Pakets zu warten, (varec)-Telegramme aus dem backup gelöscht.
• - Protokoll-Regel PR 9
  Falls mehrere Typen von Telegrammen "gleichzeitig" zu senden sind, gilt folgende Reihenfolge:
  1) Telegramme aus backup (reihenfolgerichtig)
  2) original xACK
  3) original xREN
  4) original xREL
  5) original xxLIF
  6) original xRINI
  7) original Datentelegramme
• - Protokoll-Regel PR 10
  Nach Empfang eines Telegramms xREL (varec) (civtel) wird wie folgt geprüft/reagiert ohne auf das Ende des Pakets zu warten:
  • - Protokoll-Regel 10.1
    CIVSTA=CIVTEL (vgl. Abschn. 4.3)
    Falls CIVSTA nicht 0 ist, wird CIVSTA inkre­ mentiert.
    Unabhängig von CIVSTA gilt:
    Keine Telegramme werden im backup gelöscht. Alle Telegramme im backup, aber nicht die äl­ testen (ersten) n Telegramme im backup (n=(varec) aus empfangenem Telegramm xREL), werden als Wiederholung gesendet (vergl. Be­ merkung zu PR 10.x, weiter unten).
    Ein aus dem backup gesendetes Telegramm xACK löscht VAREC nicht.
    Ein aus dem backup gesendetes xACK enthält das dazugehörige (varec) aus backup.
    Falls CIVSTA nicht 0 ist, wird xREL (varec) (civtel) gesendet.

Kurzformulierung

• • CIVSTA ist nicht 0: - CIVSTA wird inkremen­ tiert
  • - Telegramm-Wiederholung falls möglich
  • - xREL senden
    CIVSTA ist 0: - Telegramm-Wiederholung falls möglich.
  • - Protokoll-Regel PR 10.2
    CIVSTA ist größer als CIVTEL:
    CIVSTA wird nicht inkrementiert.
    Keine Telegramme werden im backup gelöscht. Alle Telegramme im backup, aber nicht die er­ sten n Telegramme im backup (n=(varec) aus empfangenem Telegramm xREL), werden als Wie­ derholung gesendet (vergl. Bemerkung zu PR 10.x, weiter unten).
    Ein aus dem backup gesendetes xACK löscht VA­ REC nicht.
    Ein aus dem backup gesendetes xACK enthält das dazugehörige (varec) aus backup.
    xREL (varec) (civtel) wird gesendet.

Kurzformulierung

• • - Telegramm-Wiederholung falls möglich,
  • - xREL senden.
  • - Protokoll-Regel PR 10.3
    CIVSTA ist kleiner als CIVTEL:
    CIVSTA wird gelöscht.
    Keine Telegramme werden im backup gelöscht. Alle Telegramme im backup, aber nicht die er­ sten n Telegramme im backup (n=(varec) aus empfangenem Telegramm xREL), werden als Wie­ derholung gesendet (vergl. Bemerkung zu PR 10.x, weiter unten).
    Ein aus dem backup gesendetes xACK löscht VAREC nicht.
    Ein aus dem backup gesendetes xACK enthält das dazugehörige (varec) aus backup.
    Falls Merker WRR gesetzt ist (=1), wird xREL (varec) (civtel) gesendet.

Kurzformulierung:

• • Merker WRR ist 1: - CIVSTA wird gelöscht
  • - Telegramm-Wiederholung,
    falls möglich
  • - xREL senden
    Merker WRR ist 0: - CIVSTA wird gelöscht
  • - Telegramm-Wiederholung falls möglich
  • - Bemerkung zu PR 10.x
    Falls (varec) aus Telegramm xREL und die An­ zahl der Telegramme im backup identisch sind, werden keine Telegramme aus dem backup gesen­ det, da dies nicht möglich/nötig ist. Diese Situation ist kein Fehler, sondern legal.
    Das wiederholte Senden aus dem backup für "CIVSTA=CIVTEL" und "CIVSTA ist größer als CIVTEL" (wenn (varec) aus Telegramm xREL klei­ ner ist als die Anzahl der Telegramme im back­ up) und der Merker WRR ist nötig zur Behebung folgender Problem-Situation, die wegen der fullduplex-Eigenschaften der Kopplung auftre­ ten kann.
    Beide Stationen können zur gleichen Zeit feh­ lerhafte Telegramme empfangen und somit ihr delay (vgl. Protokoll-Regel PR 13) gleichzei­ tig starten, aber beide delays können in ihrer Länge "etwas" voneinander abweichen, weil in jeder Station jeweils auf den nächsten Impuls der internen Zeitbasis (clock-tick) gewartet werden muß.
    Dies ist besonders für hohe Baudaten kri­ tisch, da dabei die delay-Differenz größer sein kann als die Laufzeit eines Telegramms. Dabei kann die Station mit längerem delay xREL nicht empfangen, die Station mit kürzerem de­ lay kann xREL empfangen.
• - Protokoll-Regel PR 11
  Merker WRR wird gesetzt nach jedem Senden von xREL (varec) (civtel).
• - Protokoll-Regel PR 12
  Merker WRR wird gelöscht nach jedem Empfang eines kompletten Pakets.
  Falls xREL als letztes Telegramm eines Pakets emp­ fangen wird, erfolgt das Löschen von Merker WRR erst nach Durchführung des Vergleiches "CIVSTA ist kleiner, gleich oder größer als CIVTEL" und der dabei definierten Aktion (vergl. PR 10.x).
• - Protokoll-Regel PR 13
  Nach Empfang einer Störung, für deren Typ eine Te­ legrammwiederholung erlaubt ist (durch interface- Fehler, Prüfsummen-Fehler verfälschtes Telegramm, etc., vergl. Fehlerbehandlung bei gestörter Über­ tragung. Abschn. 4.8), wird CIVSTA inkrementiert, der Empfänger deaktiviert und ein delay (timer) ge­ startet.
  Während des delay wird der Rest des verfälscht emp­ fangenen Telegramms, bzw. Pakets übertragen aber nicht empfangen. Die Dimensionierung des delay ist abhängig von der Zeit, die benötigt wird, um den Rest des Pakets zu übertragen, also abhängig von der gewählten Übertragungsgeschwindigkeit (Baud-Ra­ te) und der Länge des restlichen Pakets. Eine zu große Dimensionierung des delay ist unkritisch, reduziert aber die Reaktionszeit bei gestörter Übertragung.
  Während des delay können weiterhin Telegramme ge­ sendet werden.
  Nach Ablauf des delay wird xREL (varec) (civtel) gesendet und danach der Empfänger wieder aktiviert.
• - Protokoll-Regel PR 14
  Folgende Regeln gelten wenn zu einem Zeitpunkt kein Telegramm gesendet oder empfangen wird:
  VAREC in U=Anzahl der Telegramme im backup von I
  VAREC in I=Anzahl der Telegramme im backup von U.
• - Protokoll-Regel PR 15
  Wird in einem Paket ein xREN empfangen, können wie­ der Datentelegramme aus dem Datensendepuffer, falls vorhanden, gesendet werden, ohne auf das Ende des Empfangs des kompletten Pakets zu warten. (Vergl. Daten-Regeln, Abschn. 4.7.1)
• - Protokoll-Regel PR 16
  Wird in einem Paket ein Datentelegramm empfangen, wird erst auf das Ende des Pakets gewartet, um ei­ nen kompletten Datensatz zu empfangen, (ggf. weite­ res Datentelegramm im Paket) um diesem durch Ein­ tragen in den Datenempfangspuffer komplett an die datenverarbeitenden Funktionen der Station weiter­ zugeben.
  D. h. ein xREN darf erst gesendet werden nach dem kompletten Empfang eines Datentelegramme enthalten­ den Pakets und nach dem Auslesen dieser Datentele­ gramme aus dem Datenempfangspuffer durch die daten­ verarbeitenden Funktionen der Station. (Vgl. Daten-Regeln, Abschn. 4.7.1)

4.7.3 Backup-Regeln

Das backup ist Teil des Kontextes einer Station. (Vergl. Kontext der Station, Abschn. 4.3)

Folgende Regeln gelten für die Referenzierung des back­ ups.

• - Backup-Regel BR 1
  Initiierung.
  Das backup wird bei Start einer Station als leer initialisiert.
• - Backup-Regel BR 2
  Aktion bei Senden eines Telegramms.
  Jedes original (erstmalig, d. h. nicht wiederholt) zu sendende Datentelegramm und Synchronisationste­ legramm, außer xREL, wird in das backup übernommen und dabei an das aktuelle Ende des backup plaziert. Die Folgekennung ist in den backup-Telegrammen nicht enthalten, da vor oder bei wiederholtem Sen­ den eventuell zwischenzeitlich neue Telegramme ins backup aufgenommen wurden und alle Telegramme als ein wiederholtes Paket gesendet werden. Die Prüf­ summe eines Telegramms ist ebenfalls nicht im bac­ kup enthalten, da sie wegen der Polarität der Fol­ gekennung variieren kann, d. h. beim wiederholten Senden falsch sein kann.
• - Backup-Regel BR 3
  Aktion nach Empfang von xACK (varec).
  Von der Partnerstation wurden varec Telegramme va­ lide empfangen, das letzte empfangene Telegramm war das letzte im Paket (Folgekennung). Es wurde also ein Paket komplett empfangen.
  Sie quittiert dies mittels Senden des Telegramms xACK (varec).
  Nach Empfang von xACK (varec) werden die varec äl­ testen Telegramme aus dem backup gelöscht.
• - Backup-Regel BR 4
  Aktion nach Empfang von xREL (varec) (civtel). Von der Partnerstation wurden vor Empfang einer Störung varec Telegramme valide empfangen. Es wurde also ein Paket nicht komplett empfangen.
  Sie fordert die restlichen Telegramme dieses Pakets mittels Senden des Telegramms xREL (varec) (civtel) an.
  Nach Empfang des Telegramms xREL (varec) (civtel) wird, falls nicht mehr als varec Telegramme im bac­ kup stehen, das backup nicht referenziert (Wieder­ holung ist nicht möglich/nötig).
  Falls mehr als varec Telegramme im backup stehen, werden, bis auf die ältesten varec Telegramme im backup, alle Telegramme (also Datentelegramme und Synchronisationstelegramme) aus dem backup reihen­ folgerichtig (Reihenfolge des Eintragens in das backup) wiederholt gesendet. Neue zwischenzeitlich in das backup aufgenommene Telegramme werden damit ebenfalls wiederholt gesendet. Alle diese Telegram­ me bilden ein Paket (Folgekennung). Kein Telegramm wird im backup gelöscht.
• - Backup-Regel BR 5
  Aktion nach Empfang von xxLIF, xRINI, xREN oder Datentelegrammen:
  Diese empfangenen Telegramme bewirken keine Ände­ rung im backup.

4.8 Fehlerbehandlung bei gestörter Übertragung

Eine Störung in der Übertragung zwischen beiden Statio­ nen U und I liegt in den nachfolgenden Fällen vor. Diese Übertragungsfehler werden in den Empfängern der Übertra­ gungseinrichtungen erkannt. Nach Feststellung eines Feh­ lers werden die (ggf.) weiteren Zeichen dieses Tele­ gramms bzw. Pakets nicht mehr empfangen (Deaktivierung des Empfängers).

Folgende Reaktionen, nachstehend näher erläutert, sind nach Erkennung eines Fehlers möglich:

• - Wiederholungsprüfung (WHP) oder
• - Neustart der Übertragung (NST).

Eine Wiederholungsprüfung erfolgt nach dynamischen Feh­ lern, die durch die Systemumgebung bedingt sind.

Ein Neustart der Übertragung erfolgt nach statischen Fehlern, die durch fehlerhafte Implementierung der Re­ geln innerhalb der Übtragungseinrichtung oder durch Fehlfunktion der Übertragungseinrichtung bedingt sind.

Die Reaktionen auf mögliche Fehler sind wie folgt fest­ gelegt:

• - Fehler interface (parity, frame, overrun): WHP
• - Fehler Prüfsumme: WHP
• - Fehler timeout im Paket: WHP
• - Fehler xREL empfangen: WHP
• - Fehler Paket Länge: NST
• - Fehler unerwartetes xREN: NST
• - Fehler unerwartetes IALIF: NST
• - Fehler unerwartetes xREL: NST
• - Fehler unerwartetes Datentelegramm: NST
• - Fehler CIVSTA Überlauf: NST
• - Fehler timeout für IALIF: NST
• - Fehler timeout für IREN nach URINI: NST
• - Fehler invalides VAREC in xREL, xACK: NST

4.8.1 Beschreibung möglicher Fehler

• - Fehler interface (parity, frane, overrun)
  Beim Empfang jedes Zeichens eines Telegramms wird der interface Status überprüft, um ein verfälschtes Zeichen zu erkennen.
• - Fehler Prüfsumme
  Jedes Telegramm enthält eine Prüfsumme. Wird ein Telegramm mit verfälschter Prüfsumme empfangen, liegt ein Fehler vor.
• - Fehler timeout im Paket
  Dieser Fehler liegt vor, falls nach dem Beginn des Empfangs eines Paketes innerhalb eines bestimmten Zeitbereichs (timeout) nicht das letzte Telegramm (Folgekennung) dieses Pakets empfangen wurde.
• - Fehler xREL empfangen
  Der Empfang eines Telegramms xREL bedeutet, daß die Partnerstation eine Störung empfangen und daraufhin ein wiederholtes Senden angefordert hat. Der Emp­ fang eines Telegramms xREL bedeutet somit, daß ein Fehler in der Übertragung auftrat.
• - Fehler Paket Länge
  Beinhaltet ein Paket mehr Datentelegramme als in den Datenempfangspuffer eingeschrieben werden kann, liegt ein Fehler vor.
• - Fehler unerwartetes xREN
  Wird nach dem Empfang eines Telegramms xREN ein weiteres xREN empfangen, bevor ein Paket mit minde­ stens einem Datentelegramm gesendet wurde, liegt ein Fehler vor.
• - Fehler unerwartetes IALIF
  Wird in der Station U (master) nach dem Empfang eines IALIF ein weiteres IALIF empfangen, bevor ein URLIF gesendet wurde, liegt ein Fehler vor.
• - Fehler unerwartetes xREL
  Wird nach dem Empfang eines Telegramms xREL ein weiteres xREL empfangen, bevor das Paket wiederholt gesendet wurde, liegt ein Fehler vor.
• - Fehler unerwartetes Datentelegramm
  Wird nach dem Empfang eines Paketes mit mindestens einem Datentelegramm ein weiteres Paket mit minde­ stens einem Datentelegramm empfangen, bevor ein xREN bzw. xREL gesendet wurde, liegt ein Fehler vor.
• - Fehler CIVSTA Überlauf
  Werden bei längerer Störung der Übertragung nur noch xREL ausgetauscht, erreicht CIVSTA in einer Station seinen maximal zulässigen Wert, der frei definiert sein kann.
  Bei Erreichen dieses Wertes erscheint ein weiteres Senden von xREL nicht sinnvoll.
• - Fehler timeout für IALIF
  Wird in Station U (master) nach Senden eines Tele­ gramms URLIF nicht rechtzeitig ein IALIF empfangen, liegt ein Fehler vor. Der zulässige timeout kann frei bestimmt werden.
• - Fehler timeout für IREN nach URINI
  Wird innerhalb der Initiierung der Übertragung in Station U nach Senden eines URINI nicht rechtzeitig ein IREN empfangen, liegt ein Fehler vor. Der zu­ lässige timeout kann frei bestimmt werden.
• - Fehler invalides VAREC in xREL, xACK
  VAREC ist in den Telegrammen xREL und xACK enthal­ ten. (Vergl. Kontext der Station und Protokoll-Re­ geln, Abschn. 4.3 und 4.7.2).
  Wird ein Telegramm xREL (varec) (civtel) empfangen mit (varec) größer als die Anzahl der Telegramme im backup (in Partnerstation mehr Telegramme erfolg­ reich empfangen als gesendet) liegt ein Fehler vor.
  Wird ein xREL (varec) (civtel) empfangen mit (va­ rec) gleich der Anzahl der Telegramme im backup, liegt kein Fehler vor (keine Wiederholung möglich/­ nötig).
  Dieser Fall ist zulässig aufgrund der Protokoll-Re­ geln für den Telegramm-Ablauf bei zeitlich mehrfa­ chen hintereinander auftretenden Störungen.
  Wird ein xACK (varec) empfangen mit (varec)=0 (Quittierung für Anzahl valider empfangene Tele­ gramme tel=0) oder mit (varec) größer als die Anzahl der Telegramme im backup (mehr Telegramme erfolgreich von der Partnerstation empfangen als gesendet), liegt ein Fehler vor.

4.8.2 Wiederholungsprüfung

Als Wiederholungsprüfung wird die Entscheidung bezeich­ net, ob nach Feststellung einer Störung innerhalb der Übertragung (dynamischer Fehler) ein wiederholtes Senden von der Partnerstation anzufordern ist (durch Senden von xREL) oder ob ein Neustart der Übertragung einzuleiten ist.

Eine Wiederholungsprüfung erfolt nach jedem Inkrement von CIVSTA (vergl. Protokoll-Regeln, Abschn. 4.7.2).

Erreicht CIVSTA in einer Station seinen Maximalwert (vergl. Fehler CIVSTA Überlauf, Abschn. 4.8.1), wird dies als nicht korrigierbarer Fehler bewertet und es erfolgt ein Neustart der Übertragung.

Hat CIVSTA in einer Station seinen Maximalwert noch nicht erreicht, wird ein wiederholtes Senden von der Partnerstation angefordert.

Eine Wiederholungsprüfung erfolgt auch nach jedem Emp­ fang eines

• - durch interface-Fehler verfälschten Telegramms,
• - durch Prüfsummen-Fehler verfälschten Telegramms,
• - timeout im Paket,
• - xREL

durch Referenzierung einer Semaphore.

Diese Semaphore dient zur Erkennung und zum Abbruch von fehlerhaften Endlosschleifen in der Übertragung (z. B. permanenter Prüfsummen-Fehler im wiederholten Telegramm) oder sehr häufig verfälschter Übertragung (z. B. Prüfsum­ men-Fehler nur in jedem original, also nicht wiederholt gesendeten Telegramm).

Die Semaphore, also ein Zähler der inkrementiert und dekrementiert werden kann, existiert in jeder Station. Diese Semaphore wird beim Start der Station auf einen bestimmten Wert initialisiert (z. B. 21).

In der Wiederholungsprüfung wird die Semaphore n-mal (Dekrementalwert, z. B. zwei) dekrementiert. Erreicht sie dabei den Wert Null oder kleiner Null, wird dies als nicht korrigierbarer Fehler bewertet und es erfolgt ein Neustart der Übertragung. Erreicht sie dabei nicht den Wert Null oder kleiner Null, wird gemäß den Proto­ koll-Regeln reagiert, d. h. es erfolgt kein Neustart der Übertragung.

Nach jedem valide (unverfälscht) empfangenen Paket wird die Semaphore n-mal (Inkrementalwert, z. B. eins, muß kleiner sein als Dekrementalwert) inkrementiert, kann jedoch nicht größer werden als ihr Initialwert.

Die Dimensionierung des Maximalwertes von CIVSTA und der Semaphore bezüglich Initialwert, Inkrementalwert und Dekrementalwert ist frei definierbar und bestimmt durch die im Störungsfall erlaubte Anzahl von Telegramm-Wie­ derholungen den Zeitraum, für den eine gestörte Übertra­ gung toleriert wird.

4.8.3 Neustart der Übertragung

Als Neustart der Übertragung wird der Start einer Stati­ on nach einem dort festgestellten nicht korrigierbaren Fehler bezeichnet.

Der Start einer Station wurde bereits beschrieben. (Vergl. Initiierung der Übertragung, Abschn. 4.5) Wird beim Start (oder Neustart) einer Station innerhalb der Initialisierungsphase im master nach Senden von URI­ NI ein IREN vom slave nicht rechtzeitig oder invalide (verfälscht) empfangen, kann die Übertragung nicht ge­ startet werden.

Der master sendet danach solange zyklisch URLIF, bis er von slave IALIF (z. B. nach Zuschalten der vorher unter­ brochenen Übertragungsleitung) oder IRINI (nach Start des slave) empfängt.

Danach wird wieder die Initialisierung der Übertragung durchgeführt.

5.0 Exemplarische Darstellung der Übertragung

Zur exemplarischen Darstellung der Übertragung ist in Fig. 3.1 bis 3.4 der zeitliche Ablauf einer Übertragung in vier Teilen eines Übertragungsdiagramms gezeigt. Eine ergänzende Legende ist in Fig. 2 enthalten.

Nachfolgend ist dieses Übertragungsdiagramm durch die Zuordnung der entsprechenden Regeln (vgl. Übertragungs- Regeln, Abschn. 4.7) schrittweise erläutert.

Dabei bedeutet "Zn" (Zeit n) die zeitliche Skalierung innerhalb der einzelnen Teile des Übertragungsdiagramms und "U" bzw. "I" die Namen der beteiligten Stationen. Für die Darstellung der Telegramme im backup stellt "xACKn" eine Kurzform dar für "xACK (varec)" mit n=(varec), also dem VAREC, der in das gesendete Tele­ gramm xACK eingeschrieben wurde.

Datentelegramme sind nur innerhalb jedes Teils des Über­ tragungsdiagramms fortlaufend durchnumeriert ("UDn", "IDn").

5.1 Übertragungsdiagramm Teil 1 (Fig. 3.1)

Alle Telegramme innerhalb dieses Teils werden valide empfangen.

Bei Z0 werden beide Stationen eingeschaltet. Dieser Erstanlauf bedeutet den Start beider Stationen. Gemäß PR 3 initiiert jede Station ihren Kontext (BR 1). Bei Z1 sendet Station U URINI und schreibt dieses Telegramm in sein backup (PR 5, BR 2). Station I zählt nach Empfang von URINI dieses Telegramm in VAREC (PR 6) und antwor­ tet, da sie ein komplettes Paket empfangen hat, sofort mit IACK1 (bedeutet IACK (varec=1)) (PR 4), übernimmt es ins backup (BR 2, PR 5), löscht seinen VAREC (PR 4) und sendet bei Z3 IREN (vergl. Initiierung der Übertragung), welches auch in das backup übernommen wird (BR 2). Die beiden von I gesendeten Telegramme werden hier nicht innerhalb des gleichen Pakets gesendet, da zum Zeitpunkt des Sendens von IACK1 die Initiierung der datenverarbei­ tenden Funktionen (Einrichtungen) der Station I noch nicht abgeschlossen war, welche von diesen erst später der Übertragungseinrichtung signalisiert wurde.

Das in Station U empfangene IACK1 wird in VAREC gezählt (PR 6) und genau ein Telegramm (entsprechend varec=1 aus Telegramm IACK1) wird im backup gelöscht (PR 8, BR 3).

Das bei Z4 in Station U empfangene IREN wird in VAREC gezählt (PR 6) und löst aufgrund PR 4 das Senden von UACK (varec) (also UACK2) und das Löschen von VAREC aus. UACK2 wird in das backup übernonmen (PR 5). Station U darf nun nach Empfang von IREN Datentelegramme senden, es liegen aber momentan keine vor.

Station U sendet nun UREN (vergl. Initiierung der Über­ tragung), das ebenfalls ins backup übernommen wird (PR 5). Beide Telegramme bilden hier jeweils ein eigenes paket, d. h. in beiden ist die Folgekennung gelöscht.

Bei Z5 löscht der Empfang von UACK2 in Station I zwei Telegramme aus dem backup (PR 8), nachdem dieses Tele­ gramm in VAREC gezählt wurde (PR 6). Nach Empfang von UREN, in VAREC gezählt (PR 6), wird aufgrund von PR 4 ein IACK2 gesendet, das in das backup übernommen wird (PR 5).

Datentelegramme dürfen nach Empfang von UREN von Station I gesendet werden, es liegen aber momentan keine vor.

Bei Z7 wird IACK2 in Station U empfangen und in VAREC gezahlt (PR 6). Es löscht zwei Telegramme aus dem backup (PR 8).

Nun ist die Initiierung abgeschlossen, beide Stationen dürfen Datentelegramme senden. Die Regeln aus PR 14 sind erfüllt.

Bei Z8 beginnen beide Stationen spontan Datentelegramme zu senden, wobei in Station I bei Z11 das Ende des emp­ fangenen Pakets (Folgekennung) erkannt wird, so daß das nötige Telegranm IACK3 (PR 4) noch an das gesendete Pa­ ket (bestehend aus den Datentelegrammen ID1..ID4) ange­ hängt werden kann.

Bei Z12 empfängt Station U das Ende dieses Pakets und antwortet seinerseits mit UACK6. In beiden Stationen können die empfangenen Datentelegramme noch nicht ge­ speichert werden, somit wird noch kein xREN gesendet (DR 1).

Die Regeln aus PR 14 sind erfüllt.

Aufgrund PR 7 wird CIVSTA immer auf dem Wert Null gehal­ ten.

Aufgrund PR 12 ist der Merker WRR immer gelöscht.

5.2 Übertragungsdiagramm Teil 2 (Fig. 3.2)

Da für eine längere Zeit in Station U kein Telegramm empfangen wurde, sendet Station U bei Z1 URLIF (vergl. lifeloop). Gleichzeitig konnten in Station I die zuletzt empfangenen Datentelegramme gespeichert werden, so daß Station I nun IREN sendet (DR 2), welches aber in Stati­ on U verfälscht empfangen wird (PR 13). Station U inkre­ mentiert CIVSTA, deaktiviert seinen Empfänger und star­ tet sein delay.

In Station I wird bei Z2 URLIF valide empfangen und mit IACK2, IALIF in einem Paket beantwortet (PR 4), welches aber in Station U nicht empfangen wird.

Nach Ablauf seines delay bei Z6 sendet Station U UREL (PR 13), der Merker WRR wird gesetzt (PR 11). UREL wird nicht in das backup übernommen (PR 5).

Station I empfängt bei Z7 UREL (varec=0) (civtel=1). Es wird nicht in VAREC gezählt (PR 6). Da CIVSTA=0 und (civtel=1) ist, gilt PR 10.3 und BR 4. Alle Telegramme aus dem backup werden wegen (varec=0) wiederholt gesen­ det. VAREC wird beim wiederholten Senden von IACK2 nicht gelöscht (PR 4).

Während in Station U die wiederholt gesendeten Telegram­ me empfangen werden, sendet Station U bei Z8 spontan UREN, da die zuletzt empfangenen Datentelegramme nun ge­ speichert werden konnten (DR 2). Station I darf nun wie­ der Datentelegramme senden (DR 1). Aufgrund von PR 4 beantwortet Station I das empfangene Paket (mit dem al­ leinigen Telegramm UREN) mit IACK1, das in die gerade noch laufende Telegramm-Wiederholung als letztes Tele­ gramm eingebettet wird.

Bei Z10 löscht Station U nach dem Empfang des Pakets seinen Merker WRR (PR 12) und quittiert den Enpfang des Pakets durch Senden von UACK4. Als weiteres Paket sendet Station U daraufhin das Datentelegramm UD1 (DR 1), wel­ ches bei Z12 in Station I verfälscht empfangen wird (PR 13). CIVSTA in Station I wird inkrementiert.

Nach seinem delay setzt Station I seinen Merker WRR und sendet bei Z13 IREL (varec=1) (civtel=1), welches in Station U ebenfalls verfälscht empfangen wird. Station U inkrementiert seinen CIVSTA und startet sein delay, sen­ det bei Z15 UREL (varec=0) (civtel=1) und setzt seinen Merker WRR.

Bei Z16 empfängt Station I UREL (varec=0) (civtel=1) valide. Da CIVSTA=(civtel)=1 gilt PR 10.1. CIVSTA wird inkrementiert, da es vorher größer als Null war. Eine Telegramm-Wiederholung ist nicht mögich, da das backup in Station I leer ist. Ein IREL (varec=1) (civtel=2) wird gesendet. Der Merker WRR wird gesetzt (er war seit dem Senden von IREL bei Z13 schon gesetzt).

Bei Z17 empfängt Station U das Telegramm IREL (varec=1) (civtel=2). Da CIVSTA kleiner als (civtel) ist, gilt PR 10.3.

Da mit IREL ein komplettes Paket empfangen wurde, wird der Merker WRR gelöscht nach Anwendung der Regel PR 10.3 (PR 12) .

CIVSTA wird gelöscht, alle Telegramme aus dem backup, aber nicht die ältesten (varec) Telegramme werden aus backup wiederholt gesendet, d. h. das von U bei Z10 ori­ ginal gesendete UACK4 wird nicht wiederholt gesendet, sondern nur das bei Z11 original gesendete UD1. Da der Merker WRR noch gesetzt ist (PR 12), muß auch ein UREL gesendet werden (PR 10.3).

Der Merker WRR wird jetzt nach erfolgter Anwendung von PR 10.3 gelöscht, infolge des Sendens von IREL bei Z18 gemäß PR 11 aber wieder gesetzt.

Es gilt die in PR 9 festgelegte Reihenfolge des Sendens, d. h. zuerst UD1, dann UREL. Beide gesendeten Telegramme bilden ein Paket.

Bei Z18 wird UD1 empfangen als nicht letztes Telegramm eines Paketes (PR 16), CIVSTA wird aufgrund PR 7 ge­ löscht.

Gemäß PR 4 muß der Empfang des kompletten Pakets durch Senden von IACK quittiert werden.

Bei Empfang von UREL (varec=0) (civtel=0) bei Z19 gilt Regel PR 10.1, da CIVSTA=(civtel)=0. Da CIVSTA schon Null ist, wird es nicht inkrementiert.

Aufgrund von PR 12 wird Merker WRR in Station I bei Z19 gelöscht.

Ein Senden aus dem backup erfolgt nicht, da das backup leer ist. Es wird kein IREL gesendet (PR 10.1). Jetzt wird als Quittierung IACK2 gesendet.

Da das empfangene UD1 sofort gespeichert werden konnte, wird innerhalb des Pakets sofort IREN gesendet.

Dieses Paket wird in Station U valide empfangen, Merker WRR wird gelöscht (PR 12) und bei Z21 der Empfang des Pakets durch Senden von UACK2 quittiert.

Die Regeln aus PR 14 sind erfüllt.

Beide Stationen haben ein xREN empfangen und dürfen Da­ tentelegramme senden.

5.3 Übertragungsdiagramm Teil 3 (Fig. 3.3)

Beide Stationen senden drei Datentelegramme, wobei bei Z3 UD2 in Station I verfälscht empfangen wird (PR 13).

Während des delay in Station I kann Station I weiterhin Telegramme (z. B. ID2) senden.

Nach Ende des delay bei Z5 wird IREL (varec=2) (civ­ tel=1) gesendet, und zwar eingebettet in das gerade noch laufende Senden der Datentelegramme (PR 1) gemäß PR 9.

Bei Z6 empfängt Station U dieses IREL (varec=2) (civ­ tel=1) als nicht letztes Telegramm des Pakets (PR 10). Weil CIVSTA kleiner als (civtel) ist gilt PR 10.3. Mer­ ker WRR ist in Station U gesetzt.

Station U sendet wiederholt UD2 und UD3 aus dem backup. Den Empfang des kompletten Pakets quittiert Station U mittels Senden von UACK3, welches noch in das Paket mit den wiederholten Datentelegrammen aufgenommen werden kann, da der Empfang des Pakets von Station I früher be­ endet ist als das wiederholte Senden aus Station U. UACK3 wird gemäß PR 9 innerhalb des Pakets nach den Te­ legrammen aus dem backup eingebettet.

Bei Z9 hat Station I das komplette Paket empfangen und quittiert es durch Senden von IACK5.

bei Z10 sendet Station I nach Speichern der empfangenen Datentelegramme IREN, bei Z11 sendet Station U nach Speichern der empfangenen Datentelegramme UREN. Diese beiden Telegramme werden jeweils verfälscht empfangen, beide Stationen starten ihr delay.

Das delay in Station U ist früher beendet als das delay in Station I (vergl. Bemerkung zu PR 10.x).

UREL (varec=1) (civtel=1) kann in Station I nicht emp­ fangen werden, da in Station I während des noch laufen­ den delay der Empfänger deaktiviert ist. Nach Ende des delay in Station I sendet Station I bei Z14 IREL (va­ rec=0) (civtel=1), das in Station U verfälscht empfangen wird. Nach Ende des darauf folgenden delay sendet Station U bei Z16 UREL (varec=1) (civtel=2). Nach Ende der zeitweiligen Übertragungsstörung empfängt Station bei Z17 UREL (varec=1) (civtel=2). Da jetzt CIVSTA klei­ ner als (civtel) ist, gilt PR 10.3, CIVSTA wird ge­ löscht. Merker WRR ist gesetzt (PR 12). Nach dem nötigen wiederholten Senden von IREN aus dem backup wird im gleichen Paket ebenfalls IREL (varec=0) (civtel=0) ge­ sendet (PR 10.3, PR 9).

Nach dem Empfang dieses Pakets bei Z19 in Station U (PR 15) gilt Regel PR 10.1. Station U sendet wiederholt UREN aus seinem backup und quittiert den Empfang des Pakets durch Senden von UACK2.

Nach dem Empfang dieses Pakets bei Z21 in Station I (PR 15) quittiert Station I den Empfang dieses Pakets durch Senden von IACK2.

Die Regeln aus PR 14 sind erfüllt.

Beide Stationen haben ein xREN empfangen und dürfen Da­ tentelegramme senden.

5.4 Übertragungsdiagramm Teil 4 (Fig. 3.4)

Alle Telegramme innerhalb dieses Teils werden valide empfangen.

Station I fordert ihre Initialisierung durch Senden von IRINI an. Die Ursache für diesen Initialisierungswunsch ist hier nicht dargestellt, sie ist im Start oder Neu­ start der Station begründet.

Station U beantwortet den Empfang von IRINI mit Senden von UACK2 und URINI (vergl. Initiierung der Übertra­ gung).

Nach Empfang von URINI in Station I bei Z3 quittiert diese mit IACK2 und signalisiert durch Senden von IREN, daß sie wieder Datentelegramme empfangen kann.

Station U ihrerseits sendet nach Empfang dieses IREN bei Z6 die Quittierung UACK2 und ebenfalls UREN, um der Sta­ tion I zu signalisieren, daß auch diese wieder Datente­ legramme senden darf. Gleichzeitig liegen bei Z6 in U schon zwei Datentelegramme (UD1, UD2) zum Senden vor. Aufgrund PR 1 und PR 9 bilden alle diese zu sendenden Telegramme ein Paket, d. h. zuerst wird UACK gesendet als Quittierung für den Empfang des kompletten Pakets von Station I, dann UREN und UD1.

Vor Senden von UD2 hat U bei Z9 ein Datentelegramn ID1 empfangen, das spontan von Station I gesendet wurde. Da dieses Datentelegramm ID1 ein komplettes Paket dar­ stellt, gilt bei dessen Empfang in Station U die Regel PR 16.

Da ID1 in Station U sofort gespeichert werden kann (DR 2), muß Station U ein UREN senden. Ebenfalls muß Station U ein UACK als Quittierung des Empfangs des kom­ pletten Pakets (also wegen ID1) senden.

Diese noch zu sendenden Telegramme werden in das gerade gesendete Paket eingebettet, so daß gemäß PR 9 diese Telegramme in der Reihenfolge UACK1, UREN, UD2 gesendet werden.

Diese Übertragungsphase zeigt, daß ein Paket, und somit auch das backup, mehrere xREN und xACK enthalten kann.

Nach Empfang von UREN in Station I (nicht letztes Tele­ gramm im empfangenen Paket) bei Z11 (PR 15, DR 1) sendet I spontan ein weiteres Datentelegramm ID2 bevor es das Ende des Empfangs des kompletten Pakets von U erkannt hat. Den kompletten Empfang des Pakets von Station U quittiert Station I durch Senden von IACK6 bei Z13. Da alle von Station U empfangenen Datentelegramme (UD1, UD2) zwischenzeitlich schon gespeichert werden konnten (PR 16, DR 2) sendet Station I das Telegramm IREN. Für die Reihenfolge des Sendens von IACK6 und IREN gilt die Regel PR 9, nicht aber für ID2, da das Senden dieses Telegramms schon durch den Empfang von UREN bei Z11 aus­ gelöst wurde und es zu Senden begonnen wurde vor Ende des Empfangs des kompletten Pakets von U.

Nach Empfang des kompletten Pakets in Station U bei Z15 quittiert Station U mit UACK3.

Die Speicherung des Datentelegramms ID2 in Station U verzögert sich, so daß Station U das Telegramm UREN erst bei Z17 senden kann (PR 16, DR 2). Es stellt somit ein eigenes Paket dar.

Nach Empfang dieses Pakets in Station I bei Z18 quit­ tiert Station I mit IACK2.

Die Regeln aus PR 14 sind erfüllt.

Beide Stationen haben ein xREN empfangen und dürfen Da­ tentelegramme senden.

Claims (12)

1. Verfahren zur Übertragung von Datentelegrammen zwischen zwei Stationen über eine Übertragungsstrecke mittels einer Übertragungseinrichtung, die für gleich­ zeitiges Senden und Empfangen in beiden Richtungen ein­ gerichtet ist, wobei nach einer Übertragungsstörung mit Hilfe von Synchronisationstelegrammen eine folgerichtige Wiederaufnahme des Austauschs von Datentelegrammen si­ chergestellt wird, dadurch gekennzeichnet, daß für die Übertragung Pakete gebildet werden, die aus einem oder mehreren Telegrammen bestehen, wobei es sich um Datente­ legramme, Synchronisationstelegramme oder um eine Folge von Daten- und Synchronisationstelegramme handeln kann und daß in ein Paket, dessen Sendung noch nicht abge­ schlossen ist, Synchronisationstelegramme im Bedarfsfall eingefügt werden.

2. Verfahren nach Anspruch 1, gekennzeichnet durch eine Paketbildung mit Hilfe einer Folgekennung, die in den Telegrammen eines Pakets mit Ausnahme des letzten Telegramms des Pakets gesetzt ist.

3. Verfahren nach Anspruch 1 oder 2, dadurch ge­ kennzeichnet, daß zur Initialisierung der Übertragung eine master-slave-Rollenverteilung zwischen den beiden Stationen eintritt, wobei die master-Station zunächst für die Ablaufsteuerung notwendige und gespeicherte Mer­ ker und Zähler in definierter Weise setzt und anschlie­ ßend die slave-Station mit einem festgelegten Synchroni­ sationstelegramm auffordert, ihrerseits mit einem Syn­ chronisationstelegramm ihre Empfangsbereitschaft zu melden, worauf die slave-Station ebenfalls Merker und Zähler in einen festgelegten Zustand bringt und die Emp­ fangsbereitschaft durch Sendung des angeforderten Syn­ chronisationstelegramms bestätigt.

4. Verfahren nach Anspruch 3, dadurch gekennzeich­ net, daß zur Kontrolle der Funktionsfähigkeit der Über­ tragungseinrichtung in Übertragungspausen mit definier­ ter Mindestdauer eine master-slave-Rollenverteilung zwi­ schen den beiden Stationen eintritt und die master-Sta­ tion mit einem festgelegten Synchronisationstelegramm die slave-Station auffordert mit einem ebenfalls festge­ legten Synchronisationstelegramm ihre Funktionsfähigkeit zu bestätigen.

5. Verfahren nach Anspruch 3 oder 4, dadurch ge­ kennzeichnet, daß das Eintreffen eines Antwort-Synchro­ nisationstelegramms innerhalb einer definierten Dauer in der master-Station überwacht und für eine definierte Fehlerbehandlung ausgewertet wird.

6. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, daß nachstehende Synchronisati­ onstelegramme verwendet werden:

• a) Anforderung des Sendens weiterer Datentelegramme (UREN, IREN);
• b) Anforderung des wiederholten Sendens der zuletzt gesendeten Telegranme (UREL, IREL); dieses Tele­ gramm enthält Kennungen (VAREC, CIVTEL);
• c) Aufforderung (URLIF) von Station U an Station I ein Lebenssignal (IALIF) zu senden;
• d) Aufforderung (URINI) der Station U an Station eine Initialisierung in Station I durchzuführen;
• e) Anforderung (IRINI) eines Initialisierungstelegram­ mes (URINI) durch die Station I an Station U;
• f) Quittierung (UACK, IACK) eines fehlerfrei und voll­ ständig empfangenen Pakets; dieses Telegramm ent­ hält eine Kennung (VAREC).

7. Verfahren nach Anspruch 6, dadurch gekennzeich­ net, daß nachstehende stationstypische Merker und Zäh­ ler, die als Kontext einer Station bezeichnet sind, ver­ wendet werden:

• a) ein Speicherbereich (backup) für gesendete Tele­ gramme, der zur Telegrammwiederholung genutzt wird,
• b) ein erster Zähler (VAREC) für die Anzahl der unver­ fälscht empfangenen Telegranme seit Senden des letzten Synchronisationstelegramms zur Quittierung (UACK, IACK),
• c) ein zweiter Zähler (CIVSTA) für die Anzahl der verfälscht empfangenen Telegramme und
• d) ein Merker (WRR), der angibt, ob nach dem Senden eines Anforderungstelegramms für wiederholtes Sen­ den (UREL, IREL) der Empfang aller Telegramme, deren wiederholtes Senden angefordert wurde, abge­ schlossen ist.

8. Verfahren nach Anspruch 7, dadurch gekennzeich­ net, daß das Übertragungsverfahren als Summe einzelner Regeln definiert ist, wobei definiert sind:

• a) Daten-Regeln für die Übertragung von Datentelegram­ men,
• b) backup-Regeln zur Steuerung der Speicherung von Telegrammen bis zum erfolgreichen Abschluß der Übertragung von Paketen, und
• c) Protokoll-Regeln für die Abfolge von Daten und Syn­ chronisationstelegrammen sowie für die Definition der Art der benutzten Synchronisatinstelegramme und der in den Stationen gespeicherten, als Kontext bezeichneten Merker und Zähler.

9. Verfahren nach Anspruch 8, dadurch gekennzeich­ net, daß als Daten-Regeln definiert sind:

• a) Datentelegramme werden, sobald sie in einem Daten­ sendepuffer vorliegen, erst dann gesendet, nachdem zuvor ein Synchronisationstelegramm (UREN, IREN) empfangen wurde. Alle Telegramme aus dem Datensen­ depuffer werden innerhalb eines Pakets gesendet.
• b) Ein Synchronisationstelegramm (UREN, IREN) wird nach dem Empfang von Datentelegrammen in einem Da­ tenempfangspuffer erst dann gesendet, wenn diese von den datentverarbeitenden Einrichtungen ausgele­ sen wurden;
• c) bei störungsfreier Übertragung werden Datentele­ gramme (UD, ID) und Synchronisationstelegramme (UR- EN, IREN, UACK, IACK, URLIF, IALIF) ausgetauscht.

10. Verfahren nach Anspruch 8 oder 9, dadurch ge­ kennzeichnet, daß als backup-Regeln definiert sind:

• a) der Speicherbereich (backup) wird beim Start einer Station (U, I) als leer initialisiert;
• b) jedes original (d. h. nicht wiederholt) zu sendende Datentelegramm (UD, ID) und Synchronisationstele­ gramme (UACK, IACK, UREN, IREN, URLIF, IALIF, IRI­ NI, URINI), mit Ausnahme der Wiederholungs-Anforde­ rungstelegramme (UREL, IREL), wird in den Speicher­ bereich übernommen und dabei an das aktuelle Ende des Speicherbereichs (backup) plaziert; eine Folge­ kennung oder Prüfsumme wird nicht in den Speicher­ bereich (backup) übernommen;
• c) nach Empfang eines Quittierungstelegramms (UACK, IACK) mit dem Wert (varec) des ersten Zählers (VAREC) der Partnerstation als Kennung, werden die, bezüglich ihrer Anzahl dem Wert (varec) entspre­ chenden, "ältesten" Telegramme aus dem Speicherbe­ reich (backup) gelöscht;
• d) nach Empfang eines Wiederholungs-Anforderungstele­ gramms (UREL, IREL) mit Kennungen (varec, civtel) wird nur dann wiederholt gesendet, wenn die Anzahl der Telegramme im Speicherbereich größer ist als der Wert (varec) des ersten Zählers (VAREC), der als Kennung im Wiederholungs-Anforderungstelegramm (UREL, IREL) enthalten ist, wobei, bis auf die äl­ testen Telegramme in der Anzahl entsprechend dem Wert (varec), alle Telegramme, auch zwischenzeit­ lich neu in den Speicherbereich (backup) aufgenom­ mene Telegramme wiederholt gesendet werden; kein Telegramm wird dabei gelöscht;
• e) ein Empfang von Datentelegramm-Anforderungstele­ granmen (UREN, IREN), Initialisierungstelegrammen (URINI, IRINI) und Lebenssignaltelegramme (URLIF, IALIF) sowie von Datentelegrammen (UD, ID) bewirkt keine Änderung im Speicherbereich (backup).

11. Verfahren nach einem der Ansprüche 8 bis 10, dadurch gekennzeichnet, daß als Protokoll-Regeln defi­ niert sind:

• a) Datentelegramme (UD, ID) und Synchronisationstele­ gramme (UREN, IREN, UACK, IACK, URLIF, IALIF, UREL, IREL) können innerhalb eines Pakets gemischt auf­ treten;
• b) ein Synchronisationstelegramm zur Quittierung (UACK, IACK) dient nur zur Steuerung des Löschens des Speicherbereichs (backup);
• c) zur Initiierung des stationseigenen Kontexts nach einem Start der Stationen werden Zähler (VAREC, CIVSTA), Speicherbereich (backup) und Merker (WRR) zu Null gesetzt;
• d) ein originales Quittierungstelegramm (UACK, IACK), das den Wert (varec) des ersten Zählers (VAREC) enthält, wird sofort nach fehlerfrei empfangenem Paket gesendet, wenn das Paket andere Telegramme als Quittierungstelegramme (UACK, IACK) oder Anfor­ derungstelegramme (UREL, IREL) zur Wiederholung enthält; nach dem Senden eines solchen originalen Quittierungstelegramms (UACK, IACK) wird der erste Zähler (VAREC) auf Null gesetzt; nach dem Senden eines Quittierungstelegramms (UACK, IACK) aus dem Speicherbereich (backup) wird der erste Zähler (VA­ REC) nicht auf Null gesetzt.
• e) Jedes original gesendete Telegramm, außer einem Anforderungstelegramn (UREL, IREL) zur Wiederholung, wird in den Speicherbereich (backup) geschrieben;
• f) jedes fehlerfrei (valide) empfangene Telegramm, außer einem Anforderungstelegramm (UREL, IREL) zur Wiederholung, wird mit dem ersten Zähler (VAREC) gezählt;
• g) nach jedem fehlerfrei (valide) empfangenen Tele­ gramm, außer einem Anforderungstelegramm (UREL, IREL) zur Wiederholung, wird der zweite Zähler (CIVSTA) auf Null gesetzt;
• h) nach Empfang eines Quittierungstelegramms (UACK, IACK) mit dem Wert (varec) des ersten Zählers (VA­ REC) der Partnerstation als Kennung, wird sofort, ohne auf das Ende des Pakets zu warten, eine Anzahl Telegramme, die dem Wert (varec) des ersten Zählers (VAREC) entspricht, aus dem Speicherbereich (back­ up) gelöscht;
• i) falls mehrere Typen von Telegrammen konkurrierend gleichzeitig zum Senden anstehen, gilt folgende Reihenfolge:
  • 1. Telegramme aus dem Speicherbereich (backup) und zwar in der gespeicherten Reihenfolge,
  • 2. originale Quittierungstelegramme (UACK, IACK),
  • 3. originale Datentelegramm-Anforderungstelegram­ me (UREN, IREN),
  • 4. orginiale Wiederholungs-Anforderungstelegramme (UREL, IREL),
  • 5. originale Lebenssignal-Anforderungstelegramme (URLIF, IALIF),
  • 6. originale Initialisierungstelegramm-Anforde­ rungstelegramme (IRINI) und Initialisierungs­ telegramme (URINI),
  • 7. originale Datentelegramme (UD, ID);
• k) nach Empfang eines Wiederholungs-Anforderungstele­ gramms (UREL, IREL) mit einer Kennung (varec, civ­ tel) wird nach gesonderten Regeln eine Telegramm- Wiederholung veranlaßt;
• l) nach jedem Senden eines Wiederholungs-Anforderungs­ telegramms (UREL, IREL) mit einer Kennung (varec, civtel) wird der Merker (WRR) gesetzt, der nach jedem Empfang eines kompletten Pakets auf Null ge­ setzt wird;
• m) nach Empfang eines gestörten Telegramms, wobei für den aufgetretenen Störungstyp eine Telegrammwieder­ holung vorgesehen ist, wird der zweite Zähler (CIVSTA) inkrementiert, der Empfänger deaktiviert und eine Verzögerungszeit (delay) gestartet; nach Ab­ lauf der Verzögerungszeit (delay) wird ein Wieder­ holungs-Anforderungstelegramm (UREL, IREL) mit Ken­ nung (varec, civtel) gesendet und danach der Emp­ fänger wieder aktiviert;
• n) wird in einem Paket ein Datentelegramm-Anforde­ rungstelegramm (UREN, IREN) empfangen, können wieder Datentelegramme (UD, ID) aus dem Datensendepuffer gesendet werden, ohne auf das Ende des Empfangs des kompletten Pakets zu warten;
• o) wird in einem Paket ein Datentelegramm (UD, ID) empfangen, wird erst auf das Ende des Pakets gewar­ tet, um einen kompletten Datensatz zu empfangen und um diesen durch Eintragen in den Datenempfangspuf­ fer komplett an die datenverarbeitende Einrichtung der Station (U, I) weiterzugeben.

12. Verfahren nach Anspruch 11, dadurch gekenn­ zeichnet, daß als gesonderte Regeln zur Veranlassung einer Telegrammwiederholung (vergl. Anspruch 11, k) nachstehende Regeln definiert sind, gemäß denen nach Empfang eines Wiederholungs-Anforderungstelegramms (UREL, IREL) mit einer Kennung (CIVTEL) eine Telegrammwie­ derholung gemäß den Backup-Regeln veranlaßt wird und

• a) wenn der zweite Zähler (CIVSTA) gleich der Kennung (CIVTEL) ist und falls der zweite Zähler (CIVSTA) nicht Null ist, wird der zweite Zähler (CIVSTA) vor der Telegrammwiederholung inkrementiert und nach der Telegrammwiederholung ein Anforderungstelegramm (UREL, IREL) gesendet;
• b) wenn der zweite Zähler (CIVSTA) größer ist als die Kennung (CIVTEL) wird nach der Telegrammwiederho­ lung ein Anforderungstelegramm (UREL, IREL) gesen­ det;
• c) wenn der zweite Zähler (CIVSTA) kleiner ist als die Kennung (CIVTEL), wird vor der Telegrammwiederho­ lung der zweite Zähler (CIVSTA) gelöscht und falls der Merker (WRR) gleich 1 ist, wird nach der Tele­ grammwiederholung ein Anforderungstelegramm (UREL, IREL) gesendet.