DE4010266C2 - - Google Patents

Description

Die Erfindung bezieht sich auf ein Verfahren zur gesi­ cherten Informationsübertragung zwischen Teilnehmern an einem Netzwerk, wobei ein Token-Verfahren zur Steuerung der Sendeerlaubnis verwendet wird.

Ein solches Verfahren ist beispielsweise aus dem Buch P. Chylla, H.-G. Hegering "ETHERNET-LANs, Planung, Rea­ lisierung und Netz-Management", Datacom-Fachbuchverlag, Pulheim, 2. Auflage, 1988, bekannt. Dort ist im Zusam­ menhang mit lokalen Netzwerken und Ethernet-Standards auf Seite 22 und auf Seite 37 auf lokale Netze mit einem Token-Verfahren gemäß IEEE 802.5-Standard hingewiesen. Der Token, ein spezielles Bitmuster, welches eine Sende­ berechtigung signalisiert, zirkuliert gemäß diesem Stan­ dard auf einem logischen Ring. In realisierten Systemen geben die Netzteilnehmer in einem gesonderten Sende­ zyklus den Token weiter.

Da zu übertragende Daten (Nutzdaten) nur zufällig von demjenigen Teilnehmer zu senden sind, der gerade den Token sendet und auch meistens für einen anderen Teil­ nehmer bestimmt sind, als für den Empfänger des Tokens, wird zur Übertragung der Nutzdaten ein gesonderter Sen­ dezyklus verwendet. Systeme mit gesicherter Informati­ onsübertragung erfordern darüber hinaus einen Quittier­ zyklus.

Dieses bekannte Verfahren kann nicht alle wesentlichen Anforderungen zufriedenstellend erfüllen, die sich bei einer Anwendung in großen leittechnischen Anlagen erge­ ben.

Bei solchen in Fig. 1 schematisch dargestellten leit­ technischen Anlagen sind typisch mehrere Komponenten, wie Vorrechner, Leitrechner und Bedienplatzrechner vor­ handen, die intensiv miteinander kommunizieren. Um eine möglichst effektive Bearbeitung der damit bearbeiteten verschiedenen Teilaufgabe zu ermöglichen, werden häufig verschiedene Rechnertypen in einem Leitsystem kombi­ niert. Typisch ist eine Mehrfachauslegung von Komponen­ ten, wie Doppelrechner zur Ausfallsicherung, oder mehre­ re Rechner mit gleicher Funktionalität zur Erhöhung der Leistung.

Für solche leittechnischen Anlagen werden hauptsächlich eine hohe Ausfallsicherheit, Sicherheit vor Datenverlust und -verfälschung sowie kurze, garantierte Reaktions- und Antwortzeiten gefordert.

An ein in einer solchen Anlagen-Konfiguration eingesetz­ tes Kommunikationssystem werden deshalb sehr hohe Anfor­ derungen gestellt, wie

• - schnelle, gesicherte Übertragung der auszutauschen­ den Daten, auch zwischen in Hard- und/oder Software unterschiedlichen Rechnern,
• - deterministisches Übertragungsverhalten (garantier­ bare Reaktionszeit),
• - ständige Überprüfung des Zustands der Kommunikati­ onsverbindungen; schnelle Ausfallerkennung von Rechnern und/oder Verbindungen (Links),
• - bei Hardware-Störungen von Kommunikationsverbindun­ gen Möglichkeit einer Umschaltung auf redundante Verbindungen, und
• - geringe (CPU-)Belastung der Rechner.

Für den Einsatz in der Leittechnik werden als Kommunika­ tionssysteme üblicherweise LANs (Local Area Networks) auf Ethernet-Basis eingesetzt, da mit ihnen grundsätz­ lich die vorstehenden Anforderungen erfüllt werden kön­ nen, wenn auch mit bestimmten Einschränkungen je nach gewählter Variante. Als besonders geeignet für Leitsy­ steme mit unterschiedlichen Rechnern gilt das Übertra­ gungsprotokoll TCP/IP, das in dem genannten Buch, insbe­ sondere auf den Seiten 90 ff. beschrieben ist. Aber auch TCP/IP hat schwerwiegende Nachteile, nämlich:

• - nicht echtzeitfähig, undefiniertes Überlastverhal­ ten,
• - Netz-Rekonfiguration bei Ausfällen einzelner Kommu­ nikationspartner schwierig, da jede Anwendertask bei Ausfällen neue Verbindungen selbständig aufbau­ en muß (jeder Sender muß den Empfänger angeben); Routing sehr komplex;
• - jedes Telegramm muß einzeln gesendet werden (kein Broadcast), auch wenn es mit dem gleichen Inhalt an verschiedene Empfänger geht, was häufig bei der Übertragung von Prozeßinformationen an mehrere Be­ dienplatzrechner bzw. bei Doppelrechnersystemen erforderlich ist;
• - Packen und Entpacken (bei Zeit-/Mengensteuerung) von Telegrammen muß von den Rechnern selbst durch­ geführt werden (hohe CPU-Belastung);
• - Linkcheck (Verbindungsüberwachung) muß von den Rechnern durchgeführt werden (jedesmal Einzeltele­ gramme an jeden Partner einzeln, da Broadcost nicht möglich); sehr hohe Belastung in allen Rechnern, Ausfallerkennungszeiten liegen bei etwa 10 s;
• - Protokoll nicht an Aufgabenstellung angepaßt, gro­ ßer Overhead, z. B. aufwendige IP (Internet Proto­ col)-Komponente, die für lokale Anwendung nicht erforderlich ist;
• - keine Unterstützung von Redundanz, z. B. keine Un­ terstützung eines Doppelbussystems.

Damit erfüllt TCP/IP ebenso wie andere bekannte Kommuni­ kationssysteme nicht die oben angegebenen Anforderungen.

Davon ausgehend liegt der Erfindung die Aufgabe zugrun­ de, ein verbessertes Verfahren zur gesicherten Informa­ tionsübertragung anzugeben.

Diese Aufgabe wird durch ein Verfahren zur gesicherten Informationsübertragung zwischen Teilnehmern an einem Netzwerk, wobei ein Token-Verfahren zur Steuerung der Sendeerlaubnis verwendet wird, und wobei die Token-In­ formation zusammen mit Nutzdaten und Quittungs-Informa­ tionen in einem Telegramm-Paket übertragen wird, welches im Broadcast-Verfahren an alle Teilnehmer zugleich gesendet wird.

Vorteilhafte Ausgestaltungen des Verfahrens ergeben sich aus den Unteransprüchen und der nachstehenden Beschrei­ bung der Erfindung und eines Ausführungsbeispiels.

Das erfindungsgemäße Informationsübertragungsverfahren erfüllt alle vorgenannten Anforderungen und ist nicht an einen bestimmten Standard oder ein bestimmtes Übertra­ gungsmedium gebunden. Wesentlich ist, daß gegenüber sonstigen Token-Protokollen ein deutlich reduzierter Overhead gegeben ist, weil Daten, Quittungen und Token- Weitergabe im selben Frame, also im selben Telegrammpa­ ket erfolgt. Gemäß einer besonders vorteilhaften Ausge­ staltung kann das Verfahren auf der Basis eines Ether­ net-Standards realisiert werden, wobei dann bereits in standardisierten Hardware- und Software-Komponenten rea­ lisierte Teilfunktionen genutzt werden können. Bei­ spielsweise ist in Hardware-Komponenten, welche auf dem IEEE 802.3-Standard basieren, eine Kollisionserkennung mit automatischer Wiederholung der Informationsübertra­ gung durch Frame-Wiederholung und eine Checksum-Prüfung enthalten.

Das erfindungsgemäße Verfahren benutzt ein Token-Proto­ koll, das ein stabiles und berechenbares Zeitverhalten aufweist, was im Hinblick auf die gewünschte Echtzeitfä­ higkeit wesentlich ist. Die Übertragung von Telegrammen, welche die Nutzdaten enthalten, erfolgt im Broadcast- Verfahren an alle Teilnehmer zugleich und die Teilnehmer (Empfänger) quittieren den Empfang zugleich mit der To­ ken-Weitergabe. Gemäß einer vorteilhaften Ausgestaltung wird beispielsweise durch Verwendung einer Schnittstel­ leneinrichtung gemäß einem Ethernet-Standard der Sende­ vorgang bei fehlender Quittierung gegebenenfalls mehr­ mals wiederholt, wobei Telegrammverluste und -verviel­ fachungen sowie Verfälschungen der Telegrammreihenfolge vermieden werden. Weiterhin wird mit der Erfindung vor­ geschlagen, zu sendende Telegramme nicht unmittelbar, sondern in Telegrammpaketen zusammengefaßt, in einstell­ baren Zeitabständen zu senden, wobei ein Telegrammpaket Telegramme für verschiedene Empfänger enthalten kann. In weiterer Ausgestaltung kann eine automatische Fehlerbe­ arbeitung, d. h. ein Wiederaufsetzen oder Rekonfigurieren im Kommunikationssystem nach einer Störung vorgesehen werden, wobei kein Datenverlust eintritt. Wenn ein zweites Bussystem vorhanden ist, kann eine automatische Umschaltung vorgesehen werden.

Bei einer Implementierung des Übertragungsverfahrens in einem Kommunikationssystem zwischen der Leitebene und der Bedienebene eines Leitsystems hat sich gezeigt, daß die erfindungsgemäße gesicherte Broadcast-Übertragung besonders in Leitsystemen mit mehreren Bedienplätzen zu einer wesentlichen Reduzierung des Sendeaufwands führt. Ein Ausfall von Rechnern oder Verbindungen wird deutlich schneller erkannt, als bei bekannten Systemen, bei­ spielsweise nach maximal 200 ms anstelle von bestenfalls 5 s, wobei die Ausfallerkennung ohne Belastung der CPU eines Rechners erfolgt.

Das Verfahren wird nachstehend anhand eines Ausführungs­ beispiels näher erläutert. Dieses Beispiel bezieht sich auf ein nach dem erfindungsgemäßen Verfahren arbeitendes Kommunikationssystem, das mit EN/BTB (Ethernet Network/- Broadcast Token Bus) bezeichnet wird. Das System basiert auf Ethernet-Bussystemen nach dem IEEE 802.3-Standard. Da die zugrundegelegte Ethernet-Hardware eine Kollisi­ onserkennung mit selbsttätiger Frame-Wiederholung sowie eine Checksum-Prüfung enthält, werden Fehlerfälle durch Kollisionen und verfälschte Daten in dem nachstehend beschriebenen EN/BTB-Protokoll nicht behandelt.

In der Beschreibung des Ausführungsbeispiels werden für den Begriff "Teilnehmer" noch andere Benennungen mit synonymer Bedeutung verwendet, nämlich Netzteilnehmer, Kommunikationsteilnehmer, Rechner oder Node.

In den Fig. 2a bis 2c ist schematisch der Ablauf des Verfahrens dargestellt, anhand einer Netzkonfiguration mit drei Teilnehmern A, B, C, welche als Schnittstellen zwischen einem Host-Rechner und dem Übertragungssystem angeordnet sind und den Telegrammaustausch zwischen den Hosts abwickeln. Fig. 2a zeigt eine Situation, in wel­ cher Teilnehmer A den Token T hat und ein Telegrammpaket sendet, welches mit einem Kopfteil den Token an den Teilnehmer B weitergibt, eine Quittungsinformation und eine Anzahl von Datentelegrammen Tel_Ax enthält, die für Teilnehmer B und/oder C bestimmt sind. Die Fig. 2b zeigt den anschließend vom Teilnehmer B ausgehenden Sendevor­ gang und Fig. 2c eine Sendung des Teilnehmers C.

Die Merkmale, Regeln und Eigenschaften des Übertragungs­ verfahrens gemäß dem Ausführungsbeispiel sind nachste­ hend nach bestimmten Gesichtpunkten gegliedert darge­ stellt.

1. Protokoll 1.1 Wesentliche Protokoll-Regeln und -Eigenschaften des Kommunikationssystems EN/BTB

• - EN/BTB basiert auf einem Token-Verfahren (logi­ scher Ring), Datenübertragung und Weitergabe von Quittungen ist nur dem Netzteilnehmer gestattet, der im Besitz des Token ist,
• - jede Daten- bzw. Quittungsübertragung bedeutet gleichzeitig die Weitergabe des Token,
• - der Token wird an alle Kommunikationsteilnehmer (Rechner) gleich häufig gesendet, d. h. es gibt keine höhere Priorität für bestimmte Sender,
• - jedes Frame wird im Broadcast-Modus übertragen, d. h. es wird von jedem Netzteilnehmer (Node) empfangen und auch ausgewertet.
• - Informationen (Daten/Quittungen) an verschiedene Netzteilnehmer können in einem Frame zusammenge­ faßt werden.
• - EN/BTB unterstützt ein alternierendes Doppel­ bus-Konzept, d. h. von zwei Ethernet-Bussystemen wird stets nur eines zur Datenübertragung be­ nutzt. Im Fehlerfall wird die Übertragung auf dem Bus fortgesetzt, auf dem die meisten Netz­ teilnehmer senden/empfangen können. Eine gegebe­ nenfalls erforderliche Busumschaltung wird vom Protokoll selbsttätig ohne Datenverlust durchge­ führt.
• - Frames zur Netz-Analyse und -Recovery werden asynchron übertragen. Der Token-Zyklus wird vorher unterbrochen.
• - Anmelde-Frames für den Token-Zyklus werden eben­ falls asynchron zum laufenden Token-Zyklus ge­ sendet.
• - Es gibt keinen als Master hervorgehobenen Netz­ teilnehmer; alle Nodes sind gleichberechtigt. Ausnahme: Zur Fehlerbedhebung (Network Recovery) wird ein beliebiger Node temporär zum Master.
• - Jeder der Nodes kann den Token-Zyklus initiie­ ren, wenn dieser noch nicht besteht;
• - ein Node kann erst dann an einem bestehenden Token-Zyklus teilnehmen, wenn er sich bei den bisherigen Teilnehmern angemeldet hat.

Randbedingung ist die Verwendung von Ethernet (IEEE 802.3)-Bussystemen, welche die vorausgesetzten Einrich­ tungen zur Kollisionsbehandlung und Checksum-Prüfung enthalten.

1.2 Frame-Typen

Im EN/BTB-Protokoll gibt es folgende Frames:

• - asynchrone Frames
  • ○ ENTER-Frame
    Node will einen Token-Zyklus initialisieren oder an einem bestehenden Zyklus teilnehmen,
  • ○ CHECK-Frame
    Node (Master für Netzwork-Recovery) fordert alle anderen Nodes auf, ihre Sende/Empfangs­ bereitschaft zu melden,
  • ○ ALIVE-Frame
    Node meldet seine Sende/Empfangsbereitschaft an den Master für Netzwork-Recovery
  • ○ SHIFT-Frame
    Node gibt den Auftrag zur Network-Recovery an. seinen Nachfolger weiter,
  • ○ RESTART-Frame
    Master für Netzwork-Recovery teilt den rest­ lichen Nodes mit, auf welchem Bus weitergear­ beitet wird.

Asynchrone Frames können jederzeit ohne Berück­ sichtigung des Token-Zyklus gesendet werden (Kollisionsbehandlung: siehe vorgenannte Randbe­ dingungen). Sie werden nicht quittiert.

• - Token-Frames
  • ○ DATA-Frame
    Ein DATA-Frame kann mehrere DATA-Telegramme enthalten (es kann jedoch auch leer sein). Leere DATA-Frame werden zur Token-Weitergabe benutzt, wenn keinerlei sonstige Token-Frames zu senden sind.
  • ○ LEAVE-Frame
    Mit diesem Frame teilt ein Netzteilnehmer den anderen mit, daß er den Token-Zyklus verlas­ sen möchte.
  • ○ CONFIG-Frame
    Mit diesem Frame teilt ein Netzteilnehmer den anderen Teilnehmern mit, daß sich die Konfi­ guration geändert hat (neuer Teilnehmer wird in den Token-Zyklus aufgenommen oder ein Teilnehmer verläßt den Token-Zyklus). Diese aktualisieren daraufhin ihre Netzzustandsin­ formationen.
• Jedes Token-Frame enthält nur Telegramme eines Typs (also nicht z. B. DATA- und CONFIG-Telegram­ me zusammen). Außer den DATA-Frames enthält je­ des Token-Frame nur maximal ein Telegramm. Mit jedem Token-Frame wird der Token an den Nachfol­ ger des Absenders des Frames weitergereicht. Token-Frames müssen von allen anderen Nodes quittiert werden, die zum Zeitpunkt seiner Ab­ sendung am Token-Zyklus teilnehmen (ein CONFIG- Frame infolge eines ENTER-Aufrufs muß auch von dem neu hinzukommenden Netzteilnehmer quittiert werden, ein CONFIG-Frame aufgrund eines LEAVES- Frames wird vom ausscheidenden Netzteilnehmer nicht quittiert). Jedes Token-Frame kann Quit­ tungen enthalten.

In Fig. 3.1 ist beispielhaft der Aufbau eines EN/BTB- Frames gemäß den vorstehenden Regeln dargestellt. Der dargestellte Frame enthält einen Kopfteil, der mit einem Header gemäß Ethernet-Standard beginnt, an welchem sich ein Header gemäß dem erfindungsgemäßen Verfahren an­ schließt. Darauf folgen die Telegramme, mit welchen Da­ ten übertragen werden. Wie Fig. 3.2 zeigt, enthält jedes Telegramm einen Telegramm-Kopfteil mit Angaben zur Tele­ grammlänge und einen Selektor für die Zuordnung der Da­ ten. Diesem Telegramm-Kopfteil folgen dann die Daten.

1.3 Aktionen 1.3.1 ENTER-Vorgang

Der ENTER-Vorgang ist entweder die Initialisierung eines Token-Zyklus durch den ersten Netzteilnehmer oder das Einklinken eines weiteren Netzteilnehmers in einen bestehenden Token- Zyklus.

1.3.2 Quittieren von Token-Frames

Alle Token-Frames müssen quittiert werden. Die Quittungen sind in beliebigen Token-Frames enthalten; es gibt kein spezielles Quittungs-Frame. Jedes Token-Frame kann Quittungen an mehrere andere Nodes enthalten. Quittierung eines Frames eines Absenders bedeutet auch die Quittierung aller früheren Frames dieses Absenders (Sammelquittung). Die Wiederholvorgänge bei Ausbleiben sind in ihrer Anzahl nicht beschränkt. Dies ist aus folgenden Gründen zulässig:

• - ausgefallene Nodes (Hardware- und/oder Soft­ warefehler) werden erkannt, weil sie den Token nicht mehr weitergeben (können),
• - Nodes, die intakt sind, jedoch aus sonstigen Gründen dauerhaft nicht korrekt quittieren können (z. B. wegen nicht nur vorübergehendem Pufferüberlauf), verlassen selbstständig den Token-Zyklus.

1.3.3 LEAVE-Vorgang

Der LEAVE-Vorgang ist das Verlassen des Token- Zyklus durch eine Netzteilnehmer. LEAVE durch den letzten verbleibenden Netzteilnehmer führt zum Ende des Token-Zyklus.

1.3.4 Netzwerk-Recovery

Bei Ausfall eines Netzteilnehmers (Nichtweitergabe des Token) wird eine Analyse vorgenommen, auf welchem der beiden Busse des Doppelbussystems weitergearbeitet werden soll. Diese Analyse wird stets von dem Nachfolger des ausgefallenen Nodes (Recovery Master) durchgeführt - vorausgesetzt, er kann auf beiden Bussen senden/ empfangen. Ansonsten gibt er den Auftrag zur Netzwerk-Recovery weiter. Der Recovery Master sendet über beide Busse an alle Netzteilnehmer eine Aufforderung, sich bei ihm (wiederum über beide Busse) zu melden. Aufgrund der Rückmeldungen kann er entscheiden, ob auf Bus A oder B weitergemacht werden soll und initiiert dort einen neuen Token-Zyklus.

1.3.5 Daten-Filterung

Da in einem DATA-Frame meherere DATA-Telegramme an verschiedene Empfänger zusammengefaßt sein können, ist bei jedem Empfänger eine Telegrammauswahl erforderlich. Um diese Filterung vornehmen zu können, werden die Telegramme vom Absender eindeutig mit einem Selektor gekennzeichnet, der für jeden Typ von Telegramm eindeutig ist.

Claims (8)

1. Verfahren zur gesicherten Informationsübertra­ gung zwischen Teilnehmern an einem Netzwerk, wobei ein Token-Verfahren zur Steuerung der Sendeerlaubnis verwen­ det wird, dadurch gekennzeichnet, daß die Token-Informa­ tion zusammen mit Nutzdaten und Quittungs-Informationen in einem Telegrammpaket im Broadcast-Verfahren an alle Teilnehmer zugleich übertragen wird, wobei in einem Telegrammpaket die Quittungsinformationen unabhängig von den Nutzdaten sind.

2. Verfahren nach Anspruch 1, dadurch gekennzeich­ net, daß die Informationsübertragung zwischen Teilnehmern an einem lokalen Netzwerk (LAN) erfolgt.

3. Verfahren nach Anspruch 2, dadurch gekennzeich­ net, daß ein lokales Netzwerk nach einem Ethernet-Stand­ ard verwendet wird.

4. Verfahren nach Anspruch 3, dadurch gekennzeich­ net, daß das Telegrammpaket einen ersten Kopfteil mit Informationen gemäß dem Ethernet-Standard, einen zweiten Kopfteil mit Identifikations-, Quittungs-, Prüf- und Tokeninformationen und einen weiteren Teil mit Nutzda­ ten-Telegrammen enthält.

5. Verfahren nach Anspruch 4, dadurch gekennzeich­ net, daß die Nutzdaten-Telegramme einen Kopfteil mit einer Längenangabe und einem Selektor zur Datenzuordnung enthalten, an welchen sich die Nutzdaten anschließen.

6. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekenneichnet, daß das Verfahren in einem Netz­ leitsystem zur Informationsübertragung zwischen Rechnern in der Bedien- und Leit-Ebene verwendet wird.

7. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, daß zur Informationsübertragung ein Doppelbussystem benutzt wird, wobei eines der Bussy­ steme betriebsmäßig benutzt wird und im Störungsfall selbsttätig und ohne Datenverlust eine Umschaltung auf das andere Bussystem erfolgt.

8. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, daß neben der Informationsüber­ tragung mit einem Token-Zyklus zusätzliche, mit asyn­ chronen Frames gebildete Telegramme gesendet werden zur Initialisierung eines Token-Zyklus, zur Überprüfung der Funktionstüchtigkeit einer Verbindung zwischen Teilneh­ mern oder zum Wiederaufbau des Netzwerkbetriebs nach einer Störung.