DE69426739T2 - Übertragungsnetzwerk - Google Patents

Übertragungsnetzwerk

Info

Publication number
DE69426739T2
DE69426739T2 DE69426739T DE69426739T DE69426739T2 DE 69426739 T2 DE69426739 T2 DE 69426739T2 DE 69426739 T DE69426739 T DE 69426739T DE 69426739 T DE69426739 T DE 69426739T DE 69426739 T2 DE69426739 T2 DE 69426739T2
Authority
DE
Germany
Prior art keywords
station
token
stations
successor
query
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE69426739T
Other languages
English (en)
Other versions
DE69426739D1 (de
Inventor
Naoki Okamura
Hidetoshi Takano
Noriyuki Takao
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sharp Corp
Toyota Motor Corp
Original Assignee
Sharp Corp
Toyota Motor Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sharp Corp, Toyota Motor Corp filed Critical Sharp Corp
Application granted granted Critical
Publication of DE69426739D1 publication Critical patent/DE69426739D1/de
Publication of DE69426739T2 publication Critical patent/DE69426739T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/407Bus networks with decentralised control
    • H04L12/417Bus networks with decentralised control with deterministic access, e.g. token passing

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Small-Scale Networks (AREA)

Description

    HINTERGRUND DER ERFINDUNG a) Gebiet der Erfindung:
  • Die vorliegende Erfindung bezieht sich auf ein Kommunikationsnetzwerk zur Ausführung von Kommunikation während ein logischer Ring durch einen Abfrageprozeß aufgebaut und aufrechterhalten wird.
  • b) Beschreibung des Standes der Technik:
  • In Fig. 1 wird ein Beispiel eines herkömmlichen Kommunikationsnetzwerkes gezeigt. In diesem Netzwerk sind vier Stationen, die Codes von 00 bis 03 aufweisen, über einen Bus 10 verbunden. In diesem Fall ist ein Beispiel für ein durchführbares Protokoll, das Token-Passing, das z. B. im IEEE-Standard 802.4 definiert ist, und in EP-A- 0435037 gezeigt ist.
  • Im Token-Passing Protokoll ist der Aufbau und das Aufrechterhalten eines logischen Rings wesentlich. Der logische Ring ist ein Ring zusammengesetzt aus Stationen, die an der Übermittlung und dem Empfang von Daten teilnehmen. In Fig. 1 ist ein logischer Ring 12 durch eine gestrichelte Linie dargestellt, und eine Token wird von einer Station mit einem höheren Stationscode zu einer Station mit einem niedrigeren Stationscode im logischen Ring 12 übermittelt. Jede Station besitzt, TS-, PS- und NS-Information, um jeweils ihre eigene Station, eine vorherige Station und eine nächste Station darzustellen. Zum Beispiel hat die Station 01 die Information TS = 01, PS = 02 und NS = 00.
  • Im Token-Passing Protokoll wird das Übermittlungsrecht von Information ein Token genannt. Nachdem der Token erhalten wurde, übermittelt die Station einen Abfragerahmen an andere Stationen, wenn die Anzahl der erhaltenen Tokens einen vorbestimmten Wert erreicht, indem ab der vorherigen Übermittlung des Abfragerahmens gezählt wird. Der IEEE 802.4 Standard definiert eine Abfrage any als einen Abfragerahmen. Die Abfrage _any wird von einer Token-Haltestation (die Station, die den Token hält) zu all den anderen Stationen geschickt. Von den Stationen, die die Abfrage _any erhalten haben, antwortet irgendeine Station, die dazu fähig ist. Die Token-Haltestation legt eine nächste Station fest, die auf die Abfrage _any geantwortet hat, sie wird in einer Tokenrotationsrichtung entlang des logischen Rings angeordnet, und hat den Stationscode, welcher der Token- Haltestation am nächsten kommt. Die Token-Haltestation übermittelt den Token zu dieser neuen nächsten Station. Als ein Ergebnis schließt sich die Station, die auf die Abfrage _any geantwortet hat, dem logischen Ring 12 an. Wenn zum Beispiel bei der Übermittlung des Tokens der Token im Bus 10 durch Rauschen oder Ähnlichem zusammenbricht, wird der Token wieder gesandt, da die nächste Station den Token nicht erhalten kann. Das heißt, der Token wird innerhalb der Grenzen einer vorbestimmten Anzahl wiederholt übermittelt.
  • Wenn keine Station auf die Abfrage _any antwortet, nimmt die Token-Haltestation an, daß der logische Ring 12 nur aus seiner eigenen Station zusammengesetzt ist und arbeitet nun wie folgt. Das heißt, nachdem ein bus_idle_timer abläuft, sendet die Token-Haltestation eine Anforderung token vorbestimmt mehrfach an die anderen Stationen. Die Anforderung token ist ein Rahmen, der den Token anfordert. Nachdem die Anforderung token vorbestimmt mehrmals gesendet wurde, stellt die Station, die die Anforderung token übermittelt hat den Token her. Durch eine Überprüfung einer Zugangsklasse übermittelt die Station, die den Token hergestellt hat, wiederum die Abfrage _any. Wenn keine Reaktion auf die Abfrage _any erfolgt, hält die die Abfrage _token übermittelnde Station den Netzwerkstatus für eine sole_active station Status, d. h. nur ihre eigene Station nimmt an der Kommunikation teil und sie beendet die Abfrage. Diese Station fährt in einem Leerlaufzustand fort (Erwarten eines Aufruf oder einer Adressierung an ihre eigene Station) und erwartet danach den Empfang eines wirksamen Aufrufs einer anderen Station.
  • Selbst in dem Fall, daß die nächste Station in einen Zustand verfällt, der es ihr nicht erlaubt, den Token zu erhalten, da der Strom abgeschaltet ist oder ähnliches, nimmt die Token-Haltestation diese Situation wahr, indem der Token wieder gesandt wird, um die Abfrage an eine andere Station zu richten, und die Aufrechterhaltung des logischen Rings 12 zu ermöglichen.
  • Wenn aber ein Problem in der Token-Haltestation auftritt und sie in ein Übermitteln-möglich und Empfang- unmöglich Zustand verfällt, wird das gesamte Netzwerk herkömmlicher Weise in einen Übermittlungs-Empfang Betriebsstop überführt.
  • Wenn die Station in einen Übermittlung möglich und Empfang-unmöglich Zustand verfällt, kann die Token- Haltestation keinerlei Reaktion auf die Abfrage von anderen Stationen empfangen. Daher führt diese Station einen Betrieb aus, als würde keine Station auf die Abfrage _any antworten. Als Ergebnis dieses Betriebs geht die Token-Haltestation in den Leerlaufzustand über. Da aber die Token-Haltestation keinerlei Übermittlungen von anderen Stationen erhalten kann, kann die Token- Haltestation nicht in den Kommunikationszustand zurückkehren. Ferner sind die anderen Stationen mit Ausnahme der Token-Haltestation von der Übermittlung des Tokens abgeschnitten, und gehen durch das Hochzählen oder Ähnlichem einer Schaltuhr in den Leerlaufzustand über. Dementsprechend ist das gesamte Netzwerk in Ruhe. Um Kommunikation aus diesem Zustand heraus wieder herzustellen, ist es notwendig die Stationen abgesehen von der fehlerhaften wieder zu initialisieren, und daher ist ein Handbetrieb erforderlich.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Es ist daher eine Aufgabe der vorliegenden Erfindung ein Kommunikationsnetzwerk im Hinblick auf die oben beschriebenen Probleme im Stand der Technik bereitzustellen, das fähig ist eine Token-Haltestation von einem logischen Ring zu entfernen, die in einen Übermittlungmöglich und Empfang-unmöglich Zustand verfallen ist, und automatisch den Netzwerkbetrieb wieder aufzunehmen.
  • Es ist eine andere Aufgabe der vorliegenden Erfindung ein Kommunikationsverfahren bereitzustellen, das fähig ist, eine Token-Haltestation von einem logischen Ring zu entfernen, die in einen Übermittlung möglich und Empfang unmöglich Zustand verfallen ist, und automatisch den Netzwerkbetrieb wieder herzustellen.
  • Um die Aufgaben der vorliegenden Erfindung zu erfüllen, beinhaltet ein Kommunikationsnetzwerk eine Vielzahl von Stationen, die einen logischen Ring zur Übermittlung und dem Empfang von Information bilden, der logische Ring wird durch einen Token-Passing Prozeß zum Durchreichen des Tokens aufgebaut und aufrecht erhalten, wobei der Token das Recht zur Übermittlung von Informationen zwischen den Stationen im logischen Ring darstellt, und das Kommunikationsnetzwerk beinhaltet einen Abfrageprozeß zur Abfrage der Stationen, die nicht im logischen Ring sind und der Stationen, die im Netzwerk sind und mindestens eine spezielle Station beinhalten.
  • A) Jede der Stationen wie auch die besondere Station weist auf:
  • A1) Abfrageeinrichtung zur Ausführung des Abfrageprozesses, wenn der Token gehalten wird;
  • A2) Abfragebeantwortungseinrichtung zur Übermittlung eines Rahmens als Antwort auf einen Abfrageprozeß, der durch irgendeine Station im Netzwerk ausgeführt wurde; und
  • A3) Tokenübermittlungseinrichtung zur Übermittlung des Tokens an die Station, die einen Rahmen als Antwort auf den Abfrageprozeß übermittelt hat, wenn der Token gehalten wird;
  • B) Jede Station mit Ausnahme der besonderen Station weist ferner auf:
  • B1) Erste Abfragebeantwortungseinrichtung zur Beantwortung des Abfrageprozesses meist vorbestimmt mehrfach, wenn kein Rahmen von anderen Stationen im Netzwerk als Antwort auf den Abfrageprozeß ankommen, wenn der Token gehalten wird;
  • B2) Leerlaufbewegungseinrichtung, um zu berücksichtigen, daß keine andere Station sich dem logischen Ring anschließt, wenn kein Rahmen als Antwort auf den Abfrageprozeß ankommt, bis der Abfrageprozeß vorbestimmt mehrfach beantwortet wurde, und um in einen Leerlaufzustand überzugehen um die Ankunft eines Rahmens von irgendeiner Station im Netzwerk abzuwarten;
  • B3) Rückgabeeinrichtung um einen vorbestimmten Betrieb vom Ruhezustand aus wieder aufzunehmen, indem auf den von irgendeiner Station im Netzwerk ankommenden Rahmen geantwortet wird;
  • C) Die besondere Station weist ferner auf:
  • C1) zweite Abfragebeantwortungseinrichtung, um den Abfrageprozeß zu wiederholen, wenn kein Rahmen von irgendeiner Station des Netzwerk als Antwort auf den Abfrageprozeß, der durch die besondere Station ausgeführt wird, ankommt; und
  • C2) Tokenerzeugungseinrichtung zur Erzeugung des Tokens, wenn keine andere Station sich dem logischen Ring anschließt.
  • Ferner wird ein Kommunikationsverfahren geschaffen zur Ausführung der Kommunikation zwischen einer Vielzahl von Stationen, die sich zu einem logischen Ring verbinden, der aufgebaut und aufrecht erhalten wird, indem ein Token-Passing Prozeß zum Durchreichen des Tokens, der das Recht zur Übermittlung von Information zwischen den Stationen im logischen Ring darstellt, und einen Abfrageprozeß zur Abfrage der Stationen, die nicht im logischen Ring sind. Das Kommunikationsverfahren weist auf:
  • A) Einen Abfrageverfahrensschritt, um den Abfrageprozeß durch eine Station ausführen zu lassen, die gegenwärtig den Token hält;
  • B) Einen Abfrageantwortverfahrensschritt, um einen Rahmen von einer anderen Station zu der gegenwärtigen Token-Haltestation zu übermitteln;
  • C) Einen Tokenübermittlungsverfahrensschritt zur Übermittlung eines Tokens von der gegenwärtigen Token- Haltestation zu der anderen Station, wenn die gegenwärtige Token-Haltestation einen Rahmen als Antwort auf den Abfrageprozeß erhält, der davon ausgeführt wurde;
  • D) Einen ersten Abfragebeantwortungsverfahrensschritt, um es der gegenwärtigen Tokenhaltstation zu ermöglichen, den Abfrageprozeß höchstens vorbestimmt mehrfach zu wiederholen, wenn die gegenwärtige Token- Haltestation keinen Rahmen von irgeneiner Station im Netzwerk als Antwort auf den Abfrageprozeß erhalten kann, der durch die gegenwärtige Token-Haltestation ausgeführt wurde, die nicht die besondere Station ist;
  • E) Einen Leerlaufbewegungsverfahrensschritt, um zu berücksichtigen, daß keine andere Station sich an den logischen Ring anschließt, wenn kein Rahmen als Antwort auf den Abfrageprozeß ankommt, der durch die gegenwärtige Token-Haltestation, die sich von der besonderen Station unterscheidet, ausgeführt wird, bis der Abfrageprozeß vorbestimmt mehrfach beantwortet wird, und um in einen Ruhezustand überzugehen, um die Ankunft des Rahmens von irgeneiner Station als Antwort auf den Abfrageprozeß abzuwarten;
  • F) Einen Rückgabeverfahrensschritt, um auf einen Rahmen zu antworten, der von irgeneiner Station im Netzwerk ankommt, und um es der Station zu ermöglichen, welche die Token-Haltestation, aber nicht die besondere Station ist, einen vorbestimmten Betrieb wieder auf zunehmen:
  • G) Einen zweiten Abfragebeantwortungsverfahrensschritt, um den Abfrageprozeß zu beantworten, wenn die besondere Station gegenwärtig den Token hält und wenn kein Rahmen von irgendeiner Station im Netzwerk als Antwort auf den Abfrageprozeß ankommt; und
  • H) Einen Tokenerzeugungsverfahrensschritt, um es der besonderen Station zu erlauben, einen Token zu erzeugen, wenn keine andere Station sich dem logischen Ring anschließt.
  • Gemäß der vorliegenden Erfindung führt die Token- Haltestation den Abfrageprozeß gegenüber anderer Stationen aus. Wenn es möglich ist zu antworten, werden die Stationen, die den Abfragerahmen erhalten haben, das tun. Wenn die Station, die den Abfrageprozeß ausgeführt hat die Antwort auf den Abfragerahmen erhält, übermittelt sie den Token an die Station, die antwortete. Wenn im Gegensatzt die Antwort auf den Abfragerahmen nicht erhalten wird, führt die Station (mit Ausnahme der besonderen Station), die den Abfrageprozeß ausgeführt hat, wiederholt den Abfrageprozeß aus, aber höchstens vorbestimmt mehrmals. Obwohl der Abfrageprozeß höchstens vorbestimmt mehrmals wiederholt wird, nimmt die Station an, daß keine der anderen Stationen sich dem logischen Ring anschließen und geht in einen Leerlaufzustand über, um auf eine auf die eigene Station gerichtete Übertragung zu warten, wenn die Antwort auf einen von der Station selbst ausgeführten Abfragerahmen nicht erhalten werden kann. Wenn die Token-Haltestation auf diese Art in den Leerlaufzustand übergeht, nimmt die oben beschriebene besondere Station an, daß keine der anderen Stationen sich der Kommunikation anschließen und erzeugt den Token durch die Abfrage _token oder ähnlichem. Mit dem Erhalt des Tokens führt die obige besondere Station den Abfrageprozeß gegenüber anderen Stationen aus. Die Station im Leerlaufzustand empfängt den Abfragerahmen von der besonderen Station und antwortet auf diesen, um einen vorbestimmten Betrieb zu beginnen. In dem Fall, daß die Station die den Abfrageprozeß ausführt die besondere Station ist, wird der Abfrageprozeß nicht durch die vorbestimmte Anzahl von Abfragen abgebrochen, und daher wird die Abfrage gegenüber anderer Stationen weitergeführt.
  • Daher kann für den Fall, daß die Token-Haltestation (mit Ausnahme der besonderen Station) in einen Übermittlung-möglich und Empfang-unmöglich Zustand verfällt, selbst wenn die Antwort auf den Abfrageprozeß, die von ihr selbst ausgeführt wird, von einer anderen Station gesandt wird, die Token-Haltestation es nicht empfangen und verfällt daher in den Leerlaufzustand. Wenn aber keine der anderen Stationen sich der Kommunikation anschließt, erzeugt die besondere Station einen Token, um die Kommunikation zu starten und daher kehrt das Netzwerk automatisch in den Kommunikationszustand zurück. Ferner kann die Station, die in den Übermittlung möglich und Empfang-unmöglich Zustand verfallen ist, die wirksame Übermittlung nicht erhalten, und daher nicht aus dem Leerlaufzustand zurückkehren. Daher kann auch die fehlerhafte Station bestimmt werden und aus dem logischen Ring entfernt werden.
  • Obwohl wie oben beschrieben gemäß der vorliegenden Erfindung die Stationen, mit Ausnahme der besonderen Station wiederholt den Abfrageprozeß bis zu einer vorbestimmten Anzahl mehrfach ausführen, verfällt die Station in einen Ruhezustand, um die an sich selbst gerichtete Übermittlung abzuwarten, wenn die Station nicht irgendeine Antwort auf den von ihr selbst ausgeführten Abfrageprozeß erhalten kann. Wenn ferner keine der anderen Stationen sich der Kommunikation anschließt, kann die besondere Station den Token selbst erzeugen und den Abfrageprozeß ausführen. Daher kann, wenn die Token-Haltestation, mit Ausnahme der besonderen Station, in einen Übermittlung möglich und Empfangunmöglich Zustand verfällt, die besondere Station den Token produzieren und einen neuen logischen Ring wieder aufbauen, und daher kann das Netzwerk automatisch in den Kommunikationszustand zurückkehren. Ferner kann die Station, die in einen Übermittlung möglich und Empfangunmöglich Zustand verfallen ist, nicht aus dem Leerlaufzustand zurückkehren. Daher kann die fehlerhafte Station wirksam bestimmt werden und die gestörte Station leicht aus dem logischen Ring entfernt werden.
  • KURZE BESCHREIBUNG DER ZEICHNUNG
  • Die Aufgaben, Eigenschaften und Vorteile der Erfindung werden deutlicher unter Berücksichtigung der folgenden detaillierten Beschreibung, in Bezug auf die angefügten Zeichnung, wobei:
  • Fig. 1 ein Blockdiagramm des herkömmlichen Kommunikationsnetzwerkes ist, daß das Token-Passing-Protokoll verwendet;
  • Fig. 2 ein Flußdiagramm der Initialisierungsroutine des Betriebs des Kommunikationsnetzes entsprechend der vorliegenden Erfindung ist, die von jedem Kommunikationssteuerung direkt nach der Anschaltung ausgeführt wird;
  • Fig. 3 ein Flußdiagramm der Hauptroutine ist, die in der Kommunikationssteuerung der in Fig. 2 gezeigten Ausführungsform ausgeführt wird;
  • Fig. 4 ein Flußdiagramm eines anderen Teils der Hauptroutine ist, die vom Kommunikationssteuerung in der in Fig. 2 gezeigten Ausführungsform ausgeführt wird;
  • Fig. 5 ein Flußdiagramm eines anderen Teils der Hauptroutine ist, die von der Kommunikationssteuerung der in Fig. 2 gezeigten Ausführungsform ausgeführt wird;
  • Fig. 6a und 6b schematische Ansichten sind, die eine Abfrage _successor_1 und eine Abfrage _successor_2 einer Abfrage _successor als einen Steuerrahmen einer MAC- (medium-access control) Schicht zeigen, die zur Abfrage gegenüber anderer Stationen der in Fig. 2 gezeigten Ausführungsform benutzt werden;
  • Fig. 7 eine schematische Ansicht ist, die den Betrieb eines Abfrageprozesses gegenüber anderer Stationen zeigt, wenn der Abfrageprozeß normal ausgeführt wird, komplett ohne Kollision des gesetzten _successors in der Ausführungsform wie in Fig. 2 gezeigt;
  • Fig. 8 eine schematische Ansicht ist, die den Betrieb eines Abfrageprozesses gegenüber anderer Stationen zeigt, wenn die gesetzten _successors miteinander während des Abfrageprozesses, der in der in Fig. 2 gezeigten Ausführungsform ausgeführt wird, kollidieren;
  • Fig. 9 ein Flußdiagramm der Abfrage _successor Prozedur ist, die zur Anfangszeit ausgeführt wird, oder wenn die nächste Station verloren ist in der in Fig. 2 gezeigten Ausführungsform;
  • Fig. 10 ein Flußdiagramm der Abfrage _successor Prozedur ist, die zur Aufrechterhaltung des logischen Rings ausgeführt wird, wenn eine nächste Station bekannt ist in der in Fig. 2 gezeigten Ausführungsform;
  • Fig. 11 eine schematische Ansicht ist, die dem Betrieb eines Token-Passing zeigt, wenn eine Tokenübermittlung in der in Fig. 2 gezeigten Ausführungsform Erfolg hat;
  • Fig. 12 eine schematische Ansicht ist, die einen Betrieb des Token-Passing zeigt, der ausgeführt wird, wenn eine erste Tokenübermittlung fehlgeschlagen ist und eine nächste Tokenübermittlung Erfolg hat in der in Fig. 2 gezeigten Ausführungsform;
  • Fig. 13 eine schematische Ansicht ist, die einen Betrieb des Token-Passing zeigt, der ausgeführt, wenn eine zweite Tokenübermittlung ebenfalls fehlschlägt in der in Fig. 2 gezeigten Ausführungsform;
  • Fig. 14 ein Flußdiagramm der Token-Passing Prozedur ist, die in der in Fig. 2 gezeigten Ausführungsform ausgeführt wird;
  • Fig. 15 eine schematische Ansicht ist, die einen Betrieb von der Anschaltung an in einer besonderen Station 40 zeigt, um einen logischen Ring aufzubauen, an den sich 01 in der in Fig. 2 gezeigten Ausführungsform anschließt;
  • Fig. 16 eine schematische Ansicht ist, die einen Betrieb von der Anschaltung an in einer Station 03 zeigt, um den logischen Ring an den sich die Stationen 03 und 04 anschließen in der in Fig. 2 gezeigten Ausführungsform aufzubauen;
  • Fig. 17 eine schematische Ansicht ist, die einen Kommunikationsbetrieb zeigt, wenn eine Token haltende Station 07 in einen Übermittlung möglich und Empfangunmöglich Zustand verfällt, der in Fig. 2 gezeigten Ausführungsform, und
  • Fig. 18 eine schematische Ansicht ist, die einen Kommunikationsbetrieb zeigt, wenn die Token haltende Station 40 in einen Übermittlung möglich und Empfangunmöglich Zustand verfällt, in der in Fig. 2 gezeigten Ausführungsform.
  • BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
  • Die vorliegende Erfindung wird nun in Verbindung mit ihren bevorzugten Ausführungsformen mit Bezug auf die beiliegenden Zeichnung beschrieben, wobei gleiche Bezugszeichen gleiche oder entsprechende Teile überall in den Ansichten bezeichnen und daher eine wiederholte Beschreibung dieser der Kürze halber weggelassen werden kann.
  • a) Betrieb einer Kommunikationssteuerung jeder Station:
  • Fig. 2 bis Fig. 5 stellen einen Fluß eines Betriebs einer Kommunikationssteuerung jeder Station in einem Kommunikationsnetzwerk entsprechend der vorliegenden Erfindung dar. Das Kommunikationsnetzwerk weist einen Aufbau auf, in welchem eine Vielzahl von Stationen über einen Bus 10 auf eine wie in Fig. 1 gezeigten herkömmlichen Art, verbunden sind. In dieser Ausführungsform beinhaltet jede der Stationen, die das Kommunikationsnetzwerk bilden die Kommunikationssteuerung (nicht dargestellt). Die Kommunikationssteuerung steuert die Kommunikation, die mit anderen Stationen über den Bus 10 ausgeführt werden muß. Zu diesem Zeitpunkt wird die Information zwischen Anwendungsgeräten ausgetauscht. In einem Fall in welchem ein System dieser Ausführungsform zur Informationsübermittlung z. B. bei einem Fließband, entspricht die Steuerung der verschiedenen Geräte, die am Band angeordnet sind, den oben beschriebenen Anwendungsgeräten. Ein in dieser Ausführungsform übernommenes Protokoll weist eine Struktur eines vereinfachten Schichtenmodells eines OSI (open system interconnection) Modells eines MAP 4 auf. Genauer gesagt weist dieses Modell drei Schichten auf, wie z. B. eine Anwendungsschicht, eine Datenverbindungsschicht, eine LLC- (logical link control) Schicht, eine MAC-Schicht und eine physikalische Schicht.
  • Diese Ausführungsform benutzt das Protokoll des Token-Passing in Übereinstimmung mit einer in IEEE 802.4 definierten. Daher wird die vorliegende Erfindung nun in Bezug auf ihre bevorzugte Ausführungsform in Verbindung mit einer in Fig. 1 gezeigten Netzwerkverbindung beschrieben.
  • a.1) Initialisierungsroutine:
  • Fig. 2 zeigt eine Initialisierungsroutine, die direkt nach dem Anschalten in Schritt 100 ausgeführt wird. Diese Routine zeigt im besonderen den Betrieb einer Unterstation. In dieser Routine wird eine Watch-dog-timer Rückstellung in Schritt 102, eine RAM-Löschung in Schritt 104, eine Unterbrechungsvektorsetzung in Schritt 106, eine Zwischenspeicherintialisierung in Schritt 108, eine Eingangs/Ausgangs Initialisierung in Schritt 110, eine ROM Überprüfung in Schritt 112, eine RAM Überprüfung in Schritt 114 und ein TS-Setzen in Schritt 116 ausgeführt, und nachdem der Watch-dog-Timer wieder in Schritt 120 zurückgesetzt wird, fährt der Betrieb einer Kommunikationssteuerung in einer Hauptroutine in Schritt 124 fort, indem eine vorbestimmte Zeit in Schritt 122 gewartet wird.
  • In dieser Routine ist der Watch-dog-timer ein Hardware-Timer zur Überwachung des Durchgehens der CPU: Jede Kommunikationssteuerung weist zusätzlich zum Hardware-Timer, wie z. B. dem Watch-dog-Timer verschiedene Software-Timer auf. Durch Ausschalten des Stromes werden diese alle zurückgesetzt. Da aber elektronische Ladung im Hardware-Timer zurückbleibt, besonders in seinem Kondensator, werden Rücksetzverfahren, wie in Schritt 102 gezeigt, gebraucht. In diesem Fall ist die zuvor erwähnte CPU eine CPU zur Steuerung des Betriebes der Station.
  • Ferner beinhaltet jede Station einen RAM (nicht dargestellt), um dann vom Anwendungsgerät zur Verfügung gestellte oder über den Bus 10 empfangene Daten zu speichern, einen Zwischenspeicher (nicht dargestellt) für den Bus 10, eine Ein-Ausgabe (nicht dargestellt) für jedes Anwendungsgerät, und einen ROM (oder ähnliches) zum Speichern von Programmen, Konstanten (oder ähnliches) zum Betrieb der CPU (oder ähnlichem). Schritte 104 und 108 bis 114 sind Arbeitsschritte, die benötigt werden, um diese in ihren nutzbaren Zustand zu versetzen, oder zu bestätigen, ob diese Bauteile normal arbeiten können oder nicht. Schritt 106 verbindet Unterbrechungen, die die Übermittlungen und den Empfang betreffen mit den jeweils auszuführenden Bearbeitungen. Schritt 116 ist ein erstmaliges Setzen von TS.
  • a.2) Hauptroutine:
  • Fig. 3 bis Fig. 5 zeigt einen Fluß der Hauptroutine. Direkt nach dem Beenden der Initiatialisierungsroutine oder der Ausführung von Schritt 232 oder 258 wie nachstehend beschrieben, wird der Watch-dog-Timer in Schritt 200 zurückgesetzt und eine variable looptm wird in Schritt 202 zurückgesetzt. Die variable looptm ist ein Software-Watch-dog-Timer zur Überwachung des Durchgehens der Hauptroutine. Als nächstes unterscheidet die Kommunikationssteuerung in Schritt 204, ob seine eigene Station den Token hält. Wenn die Station den Token nicht hält, wird der Betrieb mit Schritt 206 fortgesetzt oder wenn sie den Token hält mit Schritt 234.
  • In Schritt 206 werden eine MAC-Schicht Empfangsbearbeitung, eine MAC-Schicht-Timer-Bearbeitung und eine MAC-Schicht-Datenübermittlungsvorbereitung ausgeführt.
  • In der MAC-Schicht Empfangsbearbeitung wird, wenn ein MAC-Steuerrahmen erhalten wird, der das Aufrechterhalten oder ähnliches des logischen Rings 12 betrifft, wie einen Token, wird ein wer follows, ein setzten successor, eine Abfrage _successor_1 oder ein Abfrage _successor_2, eine Erhaltberarbeitung auf den erhaltenen Rahmen angewandt. In der Timerbearbeitung werden Timer bezüglich des MAC-Steuerrahmens wie z. B. ein token_pass_timer (Token Durchreichtimer), ein whoresponse_timer (Wer antwortet Timer), ein response_window_timer (Antwort-Fenstertimer), ein contention_timer (Inhalttimer) und ähnliches gesetzt oder zurückgesetzt. In der Übermittlungsdatenvorbereitung werden Daten vorbereitet, die zu anderen Stationen übermittelt werden, als Antwort auf den Empfangsbearbeiteten MAC-Steuerrahmen.
  • Die Kommunikationssteuerung unterscheidet dann in Schritt 208, ob seine eigene Station den Token hält oder nicht. Wenn die. Station den Token nicht hält, fährt der Betrieb mit Schritt 234 fort oder wenn sie den Token hält mit Schritt 210. In Schritt 210 wird eine LLC- Schichterhaltbearbeitung, d. h. eine Erhaltbearbeitung von Daten hinsichtlich der LLC-Schicht (Daten, die im Anwendungsgerät benutzt werden) ausgeführt.
  • Die Bearbeitungen in den Schritten 206 bis 210 werden solange wiederholt, bis ein Empfangszwischenspeicher geleert ist, d. h. die Information, die empfangen wurde ist gänzlich empfangsbearbeitet. Nachdem der Empfangszwischenspeicher leer ist, wird die Bearbeitung der Kommunikationssteuerung von Schritt 212 auf Schritt 214 bewegt. Im nächsten Schritt 214 werden die Daten übermittelt, die in Schritt 206 als MAC-Steuerrahmen erhalten wurden. Im nächsten Schritt 216 wird ein Rahmen empfangen, der von einer anderen Station übermittelt wurde.
  • Als nächstes bestätigt die Kommunikationssteuerung den Teilnahmezustand in einem logischen Ring 12, indem sie eine Im-Ring-Markierung in Schritt 218 benutzt. Die Im-Ring-Markierung zeigt an, daß die eigene Station am logischen Ring teilnimmt. Neben der korrekten Bestätigung des Im-Ring-Markierungszustandes in Schritt 218, fährt der Betrieb der Kommunikationssteuerung mit Schritt 228 fort.
  • In Schritt 228 wird ein tx_timer überprüft. Der tx_timer kann eine bestimmte Zeit erfassen bis zum nächsten Empfang nach der Übermittlung. Im folgenden Schritt 230 schreibt die Kommunikationssteuerung die Daten, die dem Anwendungsgerät bereitgestellt werden sollen auf einen gemeinsamen Speicher und setzt gleichzeitig eine Markierung auf den Basisspeicher. Wenn die Markierung auf dem Basisspeicher steht, liest ein Schnittstellenteil (nicht dargestellt) auf dem Anwendungsgerät die Daten von dem gemeinsamen Speicher aus, um die Daten dem Anwendungsgerät bereitzustellen. Im nächsten Schritt 232 empfängt die Kommunikationssteuerung die Übermittlungsdaten, die vom Anwendungsgerät über die Busschnittstelle bereitgestellt wurden und schreibt die Daten in den Basisspeicher. In diesem Fall wird der gemeinsame Speicher und der Basisspeicher auf einem vorbestimmten Speicherbereich auf dem RAM angeordnet. Nach Schritt 232 wird der Betrieb des Kommunikationssteuerung auf Schritt 200 zurückgesetzt.
  • Wenn dahingehend entschieden wird, daß die Station den Token in Schritt 204 oder 208 hält, fährt die Bearbeitung mit Schritt 234 fort. In Schritt 234 trifft die Kommunikationssteuerung eine Entscheidung, ob der Empfangszwischenspeicher leer ist und führt eine LLC- Schicht Empfangsberarbeitung durch, bis der Empfangszwischenspeicher in Schritt 236 leer wird. Nachdem der Empfangszwischenspeicher geleert ist, führt die Kommunikationssteuerung eine Typ 1 Übermittlungsbearbeitung und eine Typ 3 Übermittlungsbearbeitung in den Schritten 238 bis 242 aus. Der Grund, warum es zwei Arten von Übermittlungsbearbeitungen Typ 1 und Typ 3 gibt ist, daß es verschiedene Übermittlungstypen gibt, wie z. B. gleichzeitige Übergabe an mehrere Ziele, eine 1 zu 1 Übermittlung und ähnliches. Nach Schritt 238 bis 242 überprüft die Kommunikationssteuerung den tx timer in Schritt 244 und führt desweiteren eine Übermittlung in Schritt 246 aus. Darüber hinaus beginnt die Kommunikationssteuerung die Übermittlung des Tokens in Schritt 250, wenn der Empfangszwischenspeicher leer wird, d. h. keine Daten mehr in Schritt 248 übermittelt werden müssen. Das heißt, die Kommunikationssteuerung startet den tokenpasstimer in Schritt 252 und führt dann nachfolgend ein Zurücksetzen der Token-Erhaltenmarkierung , die in Schritt 254 zeigt, daß die eigene Station den Token hält, eine Übermittlungsbearbeitung des Tokens in Schritt 256 und eine Übermittlung in Schritt 258 aus. Der token_pass_timer wird genutzt, um den Token, wie nachfolgend beschrieben, wieder zu versenden. Nach Schritt 258 kehrt die Bearbeitung der Kommunikationssteuerung zu Schritt 200 zurück.
  • b) Grundlegende Bearbeitung jeder Station:
  • Die grundlegende Bearbeitung jeder Station, wie z. B. eine Token-Passing Prozedur und eine Abfrage _succsessor Prozedur sind in Übereinstimmung mit dem zuvor genannten Fluß verwirklicht. Die grundlegende Bearbeitung jeder Station wird nun für jede Prozedur beschrieben und es werden auch Bearbeitungen direkt nach dem Anschalten und aufgrund des Auftretens von Fehlern beschrieben.
  • b.1) Abfrage _successor Prozedur:
  • Die Abfrage successor Prozedur wird durch die Token- Haltestation ausgeführt, wenn die nächste Station unbekannt ist, oder wenn die eigene Station und die nächste Station unterbrochen sind. Das erstere ist der Fall, wenn andere Stationen zur Teilnahme im logischen Ring 12 abgefragt werden, und das letztere ist der Fall, wenn die Teilnahme der anderen Stationen im logischen Ring 12 bestätigt ist.
  • Der MAC-Steuerrahmen, der in der Abfrage _successor Prozedur benutzt wird, ist der Abfrage _successor_1 und der Abfrage _successor_2. Sowohl der Abfrage _successor_1 als auch der Abfrage _successor_2 sind Abfragerahmen, die übermittelt werden müssen, indem sie einen Bereich von Stationen, denen geantwortet werden muß bezeichnen und eine Quelladresse (SA) und eine Zieladresse (DA) aufweisen. Die Station zur Übermittlung der Abfrage _successor_1 und der Abfrage _successor_2 setzt ihre eigene TS in SA und setzt auch DA geeignet vor der Übermittlung der Abfrage _successor_1 und der Abfrage _successor_2. Die Stationen, die fähig sind, auf die Abfrage _successor_1 oder die Abfrage _successor_2 zu antworten, müssen die gleichen Stationscodes wie zwischen SA und DA aufweisen. Aber die Stationen, die die gleichen Codes wie SA oder DA aufweisen, können nicht antworten. Die Antwort wird ausgeführt, indem _successor gesetzt wird.
  • In dieser Ausführungsform wird der Token von der Station der einen größeren Stationscode aufweist zu der Station, die im logischen Ring 12 einen kleineren Stationscode aufweist, übermittelt. Und die nächste Station der Station, die einen maximalen Code im logischen Ring 12 aufweist, ist die Station, die einen minimalen Code im logischen Ring aufweist. Da auf der anderen Seite die Abfrage _successor Prozedur zur Abfrage der Stationen, die die nächsten Stationen sein sollen oder zur Bestätigung der nächsten Stationen durchgeführt wird, muß DA nachfolgend an SA angeordnet sein. Daher ist es notwendig eine Abfrage _successor zu benutzen, wenn der eigene Stationscode nicht minimal ist, der den Stationen im Bereich, die durch eine dicke durchgezogene Linie in Fig. 6a dargestellt sind, zu antworten, und wenn es minimal ist Stationen im Bereich der durch die dicke durchgezogene Linie in Fig. 6b gezeigt ist. Der Grund, warum Abfrage _successor_1 und Abfrage _successor_2 als Abfrage successor gegeben sind, ist, daß es zwei Fälle gibt, in denen DA größer oder kleiner als SA ist. In Fig. 6a und 6b wird angenommen, daß 64 (40H) Stationen da sind, und die Stationen, die durch ein O dargestellt sind einen Stationscode gleich SA oder DA aufweisen nicht auf die Abfrage successor antworten können.
  • Wenn der Anschluß anderer Stationen im logischen Ring 12 durch die Abfrage _successor_1 oder die Abfrage _successor_2 mittels der Übermittlung der Abfrage _successor_1 oder des Abfrage _successor_2 abgefragt oder bestätigt wird, startet die Token-Haltestation den response_window_timer als eingebauten Software-Timer. Hofft eine der Stationen, welche die übermittelte Abfrage _successor_1 oder die Abfrage _successor_2 erhalten haben, sich dem logischen Ring anzuschließen und plaziert sich im Bereich (zwischen SA und DA, im Folgenden wird darauf als "Fenster" bezug genommen), der durch die Abfrage _successor_1 und die Abfrage _successor_2 bezeichnet wird, startet sie den contention_timer (Auseinandersetzungstimer) als Antwort auf den Erhalt der Abfrage _successor_1 oder der Abfrage _successor_2 und übermittelt das Setzen successor, der ihre eigenen Stationscodes als Daten an die Abfrage _successor Übermittlungsstationen beinhaltet, nachdem der contention_- timer abgelaufen ist. Die Token-Haltestation, welche die Abfrage _successor_1 oder die Abfrage _successor_2 übermittelt hat, empfängt normalerweise das Setzen _successor mit dem Ablaufen des response_window_timers auf sich selbst gerichtet. Die Token-Haltestation startet den response_window_timer von neuem und übermittelt den Token an die Station, die das Setzen successor gesendet hat, wenn der response_window_timer abläuft. Der contention timer und der response_window_timer werden später weiter erläutert.
  • b.1.1) Abfrage _successor Prozedur, wenn eine nächste Station unbekannt ist:
  • Die Abfrage _successor Prozedur, die ausgeführt wird in dem Fall, daß eine nächste Station nicht bekannt ist, ist eine Prozedur, zur Abfrage von Stationen, die hoffen, sich dem logischen Ring 12 anschließen zu können. Zum Beispiel, wenn das Wiederversenden des Tokens mißlingt, wie nachfolgend beschrieben wird, und ferner keine Antwort auf das who_follows (wer folgt) erhalten wird, nimmt die Token-Haltestation an, daß keine Station ausser ihr selbst am logischen Ring 12 teilnimmt, und fragt andere Stationen ab, sich dem logischen Ring 12 anzuschließen. Ferner erhält direkt nach dem Anschalten eine Hauptstation den Token, in dem sie die Übermittlung des Anforderungstokens wiederholt und die anderen Stationen abfragt, sich dem logischen Ring 12 anzuschließen, wie nachfolgend beschrieben wird.
  • In Fig. 7 stellen , O und ↓ jeweils eine Übermittlung von einer Token-Haltestation, eine Übermittlung von anderen Stationen, die keinen Token halten, d. h. eine Antwort auf eine Abfrage, und eine Station, die die Teilnahme am logischen Ring 12 anfragt (selbiges in den folgenden Figuren). Wie in Fig. 7 gezeigt ist, können die zwei Stationen 02 und 03, die im Fenster plaziert sind antworten, wenn die Station 04 die Abfrage _successor_1 mit SA = 04 und DA = 01 übermittelt. Die zwei Stationen 02 und 03 setzten ihre eigenen contention_timer zufällig. Der contention timer ist ein Timer, der die Auseinandersetzung von Antworten einer Vielzahl von Stationen verhindert. Im Beispiel von Fig. 7 sind die contention_- timer der zwei Stationen 02 und 03 jeweils auf 0 Millisekunden und 4 Millisekunden gesetzt. Daher läuft in diesem Fall der contention timer der Station 02 früher (in diesem Fall unverzüglich) ab als der von 03. Daher übermittelt die Station 02 das Setzen successor, der auf die Station 04 gelenkt ist früher als die Station 03. Die Station 03 bestätigt durch den Erhalt, daß die Station 02 bereits das Setzen_successor, das auf die Station 04 gerichtet ist, bereits übermittelt hat und gibt die auf die auf Station 04 gerichtete Übermittlung auf. Die Station 04 übermittelt den Token an die Station 02, wenn der response_window_timer nochmals abläuft.
  • In einem wie in Fig. 8 gezeigten Fall, in welchem zufällig dieselbe Zeit im contention timer der Stationen 02 und 03 gesetzt wird, stimmt das Setzen successor das von Station 02 auf Station 04 gelenkt wird mit dem Setzen _successor, das von Station 03 auf Station 04 gerichtet wird überein, und daher kann die Station 04 keine der Setzen _successor korrekt empfangen. Als ein Ergebnis des Antwortens unter Verwendung des Setzen _successor verfallen die zwei Stationen 02 und 03 in einen Tokenerwartezustand. Im response_window_timer wird ein vorbestimmter Wert wie z. B. 8 Millisekunden bei der Übermittlung des Abfrage successor s gesetzt, und wenn kein Setzen successor von den zwei Stationen 02 und 03 empfangen wird läuft der response_window_timer ab. Die Station 04 gibt dann die Abfrage gegenüber der Station 02 und 03 auf. Danach übermittelt die Station 04 eine anderen Abfrage successor, der ein erweitertes Fenster aufweist und übermittelt den Token z. B. an die Station 1, die diesem geantwortet hat. Die Stationen 02 und 03 empfangen den auf eine andere Station gerichteten Token und geben daher den Anschluß an den logischen Ring 12 auf, um eine nächste Gelegenheit abzuwarten.
  • Um einen solche Bearbeitung zu verwirklichen zeigt Fig. 9 die Abfrage _successor Prozedur, die von der Token-Haltestation ausgeführt werden muß, wenn die nächste Station nicht bekannt ist.
  • In dieser Prozedur unterscheidet die Steuerung zuerst in Schritt 300, ob TS gleich NS ist. Direkt nachdem der Token in der Hauptstation durch den Anfragetoken empfangen wird, ist TS ≠ NS. In der Station, die am Senden des Tokens wiederholt scheitert und ferner keine Antwort auf das who_follows empfängt ist ebenso TS ≠ NS, da der Stationscode der nächsten Station bis dahin in NS eingesetzt ist. Dementsprechend wird der Betrieb von Schritt 300 mit Schritt 302 fortgesetzt, direkt nach dem die Abfrage _successor Prozedur begonnen hat, wenn die nächste Station unbekannt ist.
  • In Schritt 302 wird von NS 1 abgezogen. Wenn aber 00H als Subtraktion erhalten wird, wird der maximale Stationscode (40 H im Falle von 64 Stationen) auf NS gesetzt. Ferner wird die Abfrage _successor_1 an Schritt 306 übermittelt, wenn im Schritt 304 TS > NS ist, oder der Abfrage _successor_2 wird an Schritt 308 übermittelt, wenn im Schritt 304 TS < NS ist. Nachdem die Abfrage _successor_1 oder die Abfrage successor 2 gesendet wurden, setzt die Token-Haltestation den response_ window-_timer auf den vorbestimmten Wert wie z. B. in unserem Beispiel 8 msec. und startet diesen Timer in Schritt 310. Die Token-Haltestation wartet dann, bis der response_- window_timer in Schritt 312 abläuft.
  • In dem Fall, daß irgendeine Station, die sich an den logischen Ring 12 anzuschließen wünscht, im Fenster der Abfrage successor 2 anwesend ist, kann die Token- Haltestation wie in Fig. 8 gezeigt das Setzen _successor empfangen, das an sie selbst gerichtet ist, bevor der response_window_timer abläuft, solange keine Kollision im Setzen successor auftritt. Wenn ein wirksamer Rahmen empfangen wird, bevor der response_window_timer in Schritt 314 abläuft, unterscheidet die Token-Haltestation in Schritt 316, ob der empfangene Rahmen ein set_successor ist oder nicht. Wenn in Schritt 316 unterschieden wird, daß der empfangene Rahmen ein Set successor ist, setzt die Token-Haltestation den Stationscode der Station, die den Stationscode übermittelt, der im set_successor als Daten beinhaltet ist oder das set_successor setzt den response_window_timer und wartet ferner bis der Timer in Schritt 318 abläuft. Nachdem der Timer abgelaufen ist, beendet die Token-Haltestation den Abfrageprozeß und übermittelt den Token zu der durch NS in Schritt 320 angezeigten Station. Wenn auf der anderen Seite in Schritt 316 unterschieden wird, daß der empfangene Rahmen nicht der set_successor ist, beendet die Token-Haltestation den Abfrageprozeß und gibt den Token in Schritt 322 auf.
  • Wenn wiederum die Token-Haltestation nicht die Antwort auf den solicit_successor_2 empfangen kann, der im Schritt 306 oder 308 übermittelt wurde, bevor der response_window_timer in Schritt 312 abläuft, wird der Betrieb mit Schritt 300 fortgeführt, d. h. solange im Schritt 300 TS &ne; NS wird im Schritt 302 von NS 1 abgezogen und der solicit successor 1 oder solicit_- successor_2 werden wiederum im Schritt 306 oder 308 übermittelt. Mit anderen Worten, indem immer wieder 1 von NS abgezogen wird, wird das Fenster des solicit_- successor_1 oder des solicit successor 2 immer wieder um 1 erweitert und von daher werden sich die Stationen, die bisher nicht antworten konnten als fähig herausstellen, eine geordnete Antwort zu geben. Wenn solch eine Wiederholung der Übermittlung nicht berücksichtigt wird, kann die Token-Haltestation nicht die Antwort bei TS &ne; NS in Schritt 300 empfangen, und der Bearbeitung fährt mit Schritt 324 fort. Das ist der Fall, wenn die Token- Haltestation die Antwort durch den Rahmen wie z. B. den set_successor nicht empfangen kann, selbst in dem Zustand, daß das Fenster des solicit_successor_1 oder des solicit_successor_2 auf das Maximum erweitert wird, unterscheidet die Token-Haltestation in Schritt 324 ob sie eine Hauptstation oder eine Nebenstation ist (TS = 00 (= 40 H) oder nicht). Wenn es die Hauptstation ist, d. h. in dem Fall der solicit successor Prozedur nach dem Erhalt des Tokens durch die Anfragetokenübermittlung, der Abfrage_successor_2 von SA = DA = TS, d. h. der Abfrage _successor, der für alle Stationen vorgesehen ist, wird in Schritt 326 übermittelt und die Bearbeitung setzt mit Schritt 310 fort. Wenn es sich auf der anderen Seite um eine Nebenstation handelt, wird die Übermittlung der Abfrage _successor nicht länger ausgeführt. In diesem Fall kehrt die Token-Haltestation in den Leerlaufzustand zurück, bis in Schritt 328 der wirksame Rahmen empfangen wird. Wenn die Token-Haltestation den wirksamen Rahmen empfängt, fährt die Bearbeitung mit Schritt 316 fort. Wie zuvor beschrieben wird in dieser Ausführungsform die Abfrage durch die Hauptstation fortgeführt, bis eine andere Station antwortet. Im Gegensatz dazu wird die Abfrage durch die Nebenstation beendet, wenn das Objekt der Abfrage auf ein Maximum erweitert. Ferner kann die Abfrage nicht zusammen durch alle Stationen beantwortet werden, wie bei der IEEE 802.4 und daher kann die Last des Empfangsteils in jeder Station verringert werden.
  • b.1.2) Abfrage successor Prozedur, wenn eine nächste Station bekannt ist.
  • Fig. 10 stellt eine Abfrage successor Prozedur dar, wenn eine nächste Station bekannt ist. Diese Abfrage successor Prozedur wird durchgeführt, wenn die Aufrechterhaltung des logischen Rings 12 erforderlich ist, z. B. wenn der Stationscode von selbst von dem der nächsten Station unterbrochen ist. Das heißt, das ist die Abfrage successor Prozedur zur Bestätigung der nächsten Station.
  • In dieser Abfrage successor Prozedur unterscheidet die Token-Haltestation in Schritt 400 zuerst, ob sie die Minimumadresse (Stationscode) innerhalb der Stationen hat, die im logischen Ring 12 zusammengeschlossen sind. Wenn es die Minimumadresse ist, übermittelt die Token- Haltestation die Abfrage successor 2 zur nächsten Station im Schritt 402, oder wenn es nicht die Minimumadresse ist den Abfrage _successor_1 in Schritt 404. Dann setzt die Token-Haltestation den response_- window_timer auf einen vorbestimmten Wert wie z. B. 8 msec in diesem Fall, und startet dann diesen Timer in Schritt 406. Wenn die Token-Haltestation nicht den wirksamen Rahmen in Schritt 409 empfängt, fährt der Betrieb mit Schritt 408 fort. Wenn die Token-Haltestation einen wirksamen Rahmen von der nächsten Station im Schritt 409 empfängt, bevor der response_window_timer in Schritt 408 abläuft, führt die Token-Haltestation eine Bearbeitung derselben Art wie in Schritt 318 in Schritt 412 aus, und übermittelt ferner den Token an die nächste Station in Schritt 414, falls der empfangene Rahmen in Schritt 410 ein Setzen _successor ist. Wenn der response_window_timer in Schritt 408 abläuft fährt die Bearbeitung unverzüglich mit Schritt 414 fort. Wenn in Schritt 410 die Token- Haltestation den MAC Steuerrahmen mit Ausnahme des Setzen _successors empfängt, bevor der response_window_timer abläuft, stoppt die Token-Haltestation die Abfrage _successor Prozedur und gibt den Token in Schritt 416 auf.
  • b.2) Token-Passing Prozedur:
  • In dieser Ausführungsform führt die Station die Abfrage successor Prozedur der unbekannten nächsten Station einmal pro vorbestimmter Anzahl von Malen aus, nachdem der Token erhalten wurde und sendet den Token an die Stationen, die diesem mit dem Setzen successor antworten. In dem Fall, daß die Station, die auf die Abfrage successor geantwortet hat, sich bereits vor der Antwort an den logischen Ring 12 angeschlossen hat, wird angenommen, daß keine andere Station sich an den logischen Ring anzuschließen wünscht, und der Abfrageprozeß wird nicht für einen vorbestimmten Zeitabschnitt ausgeführt. In dem Zustand, daß der logische Ring 12 in einem wie oben beschriebenen Fortschritt aufgebaut wird, wird der logische Ring 12 durch das Token-Passing aufrechterhalten. Das Token-Passing ist eine Prozedur, die ausgeführt wird, wenn die Station, die den Token als Recht zur Übermittlung von Daten hält, den Token an andere Stationen übermittelt. Wie z. B. in Fig. 11 gezeigt, hält die Station 03 den Token. Nun wird der Fall angenommen, daß der Token von der Station 03 zur nächsten Station 02 übermittelt wird. In diesem Fall startet die Station 03 nicht nur den token_pass_timer (Token- Durchreichtimer), sondern übermittelt den Token an die Station 02. Die Station 02 erhält den Token und wenn es irgendwelche Information zum Übermitteln gibt, sendet die Station 02 die Daten. Danach liefert die Station 02 den Token an die nächste Station. In dem Fall, daß es eine Vielzahl von Stationen gibt, die auf die Abfrage _successor antworten, führt die Token-Haltestation einen vorbestimmten Prozeß wie folgt aus. Das heißt, wenn eine Vielzahl von Stationen zur selben Zeit antwortet, wird dies vernachlässigt, und wenn die entsprechende Station alleine ist, kann der Token wie oben beschrieben übermittelt werden. Natürlich ist es wie bei der IEEE 802.4 möglich, einen Prozeß auszuführen in welchem der Token zur nächsten Station in Übertragungsrichtung des logischen Ringes gesendet wird. Die Station 03 bestätigt, daß der wirksame MAC-Steuerrahmen durch die Station 02 übermittelt ist, und urteilt wie oben beschrieben, daß das Token-Passing vervollständigt ist.
  • Wenn ferner der Token, wie in Fig. 12 gezeigt, der von der Station 03 gesendet wird durch Rauschen oder ähnliches zusammenbricht, übermittelt die Station 03 den Token wieder, da die nächste Station 02 den Token nicht empfangen kann, nachdem der token_pass_timer abgelaufen ist. In dieser Ausführungsform läuft der token_pass_timer in 60 msec ab. Wenn bestätigt wird, daß der wiederübermittelte Token durch die Station 02 empfangen wurde in derselben Art wie oben beschrieben, urteilt die Station, daß das Token-Passing beendet ist.
  • Wenn des weiteren eine Station 06 vom Bus 10 abgeschnitten wird, wie in Fig. 13 gezeigt, oder die Stromquelle abfällt, hat das Wiedersenden des Tokens von der Station 07 zur Station 06 keinen Erfolg. In diesem Fall kann gesagt werden, daß die Station 07 in dem zustand ist, daß sie die nächste Station verloren hat. Die Station 07 übermittelt das who_follows, da der Rahmen codes seines eigenen Stationscode und der nächsten Station beinhaltet. Die nächste Station, die zur Antwort auf das who_follows fähig ist, ist die nächste Station. Die nächsten Station, die im who_follows beinhaltet ist, d. h. in diesem Fall die Station 05 wie in Fig. 13 gezeigt wird. Wenn die Antwort von dieser Station 05 durch das Setzen _successor gesendet wird, übermittelt die Token- Haltestation 07 den Token an die Station 05. Wenn ferner der Token die Station 07 nach einer vorbestimmten Anzahl von Durchläufen erreicht, fragt die Station 07 die Station 06 durch die Abfrage _successor_1 ab. Wenn zu dieser Zeit noch keine Antwort vorliegt, übermittelt die Station 07 den Token an die Station 05. Fig. 14 zeigt die Token-Passing Prozedur.
  • In dieser Prozedur wird zuerst ein token pass timer im Schritt 500 gestartet. In dieser Ausführungsform wird der token pass timer auf 60 Minuten festgelegt. Als nächstes wird eine Token-Erhalten Markierung im Schritt 502 zurückgesetzt, eine Tokenübermittlungsbearbeitung wird in Schritt 504 ausgeführt, und ferner wird der Token in Schritt 506 übermittelt.
  • Wenn die Token-Haltestation den wirksamen MAC- Steuerrahmen im Schritt 510 empfängt, bevor der token pass timer in Schritt 508 abläuft, nimmt die Token- Haltestation an, daß die Tokenübermittlung erfolgreich ist und begibt sich in den Empfang erwartenden Zustand in Schritt 512. Wenn ferner der token pass timer abläuft, ohne daß ein wirksamer MAC-Steuerrahmen empfangen wurde, wird der token pass timer in Schritt 514 wieder gestartet und ferner der Token in Schritt 516 übermittelt. Wenn die Token-Haltestation den wirksamen MAC-Steuerrahmen in Schritt 520 empfängt, bevor der Token-Durchreichtimer in Schritt 518 abläuft, nimmt die Token-Haltestation an, daß der wiederübermittelte Token Erfolg hat und begibt sich in den empfangsabwartenden Zustand in Schritt 512.
  • Wenn auch das Wiedersenden des Tokens mißlingt, d. h. wenn der token pass timer in Schritt 518 abläuft, ohne daß ein wirksmer MAC-Steuerrahmen empfangen wurde, wird der who_response_timer in Schritt 522 gestartet und ferner wird in Schritt 524 das who_follows übermittelt. Wenn die Token-Haltestation das Setzen successor in Schritt 528 empfängt, bevor der who_response_timer in Schritt 526 abläuft, wird die Station, die dieses Setzen _successor übermittelt hat, als nächste Station behandelt. Wenn im Gegensatz dazu der who_response_timer abläuft, wird die Abfrag _successor Prozedur der unbekannten nächsten Station in Schritt 532 ausgeführt.
  • c) Betrieb beim Einschalten:
  • Als nächste Bearbeitung des durch die zuvor genannten Prozeduren verwirklichten Netzwerkes, wird ein Bearbeitung bei angeschaltenem Strom beschrieben.
  • Nun wird angenommen, daß die Anzahl der das Netzwerk bildenden Stationen 64 ist und eine Hauptstation mit dem Stationscode 00 = 40 H gegeben ist. In diesem Fall wird zuerst die Hauptstation 00(40 H) eingeschaltet und dann werden andere Station 01, 03 und 04 eingeschaltet in der Reihenfolge von 01 &rarr; 03 &rarr; 04. Fig. 15 und Fig. 16 zeigen die Bearbeitungen des Netzwerks besonders die Bearbeitungen, die Übermittlung/Empfang des MAC-Steuerrahmens zum Aufbau und zur Aufrechterhaltung des logischen Rings betreffen.
  • Wie in Fig. 15 gezeigt, übermittelt die Hauptstation 00 zuerst eine vorbestimmte Anzahl von Malen wie z. B. acht Mal die Anforderung token. Diese Übermittlung wird in einem vorbestimmten Zeitintervall, wie vier Millisekunden ausgeführt. Die Hauptstation 00 erhält den Token, indem diese Prozedur ausgeführt wird. Nachdem der Token durch vorbestimmt mehrmaliges Übermitteln der Anfrage _token erhalten wird, führt zuerst die Hauptstation 00 die Abfrage _successor Prozedur aus. Das heißt, daß die Hauptstation 00 nicht nur bestätigt, ob irgendeine Station, die eingeschaltet ist, um zur Teilnahme an der Kommunikation fähig zu sein, mit Ausnahme der Hauptstation, sondern führt auch die Abfrage successor Prozedur aus, um die Station oder Stationen abzufragen, deren Anschluß an den logischen Ring 12 bestätigt ist. In diesem Fall ist TS &ge; NS in Schritt 304, wie oben beschrieben, immer erfüllt, da der Stationscode der Station zur Übermittlung der Abfrage _successor 40 H ist, und die Abfrage _successor, die übermittelt werden muß, ist die Abfrage _successor 1.
  • Die Hauptstation 00 erweitert das Fenster des Abfrage _successor_1 allmählich. Das heißt, das in der Hauptstation 00 TS = 40 und NS = 3F direkt nach dem Anschalten gesetzt werden und das Fenster in Einerschritten in Schritt 302 wie folgt erweitert wird: z. B. ist SA = 40 und DA = 3F bei der ersten zu übermittelnden Abfrage _successor_1; SA = 40 und DA = 3E beider zweiten Abfrage _successor_1; ... wenn keine der anderen Stationen durch die maximale Erweiterung des Fensters eingeschaltet werden, wird keine Antwort auf die Abfrage _successor_1, die durch Hauptstation 00 gesendet wurde, übermittelt und daher führt die Hauptstation 00 wiederholt den Schritt 326 aus. Das heißt die Abfrage _successor_2, dessen Fenster auf ein Maximum erweitert wird, wird übermittelt, bis irgendeine der anderen Stationen antwortet. In diesem Fall wird die Übermittlung der Abfrage _successor_1 oder der Abfrage _successor_2 von der Hauptstation 00, d. h. die Abfrage von anderen Stationen wird in einem Ablaufzeitintervall wie z. B. 8 Millisekunden (in dieser Figur) des response_window_- timers ausgeführt.
  • Später wird die Stromquelle der Station 01 an einem bestimmten Zeitpunkt angschaltet. Die Station 01 antwortet auf den Abfrage _successor_1 oder den Abfrage _successor_2, der von der Hauptstation 00 mittels des Setzen-Nachfolgers gesendet wurde. Die Hauptstation 00 übermittelt den Token als Antwort darauf der Station 01. Die Station 01, die den Token, der auf sie selbst gerichtet ist, empfangen hat, führt zuerst die Abfrage _successor Prozedur der unbekannten nächsten Station aus und fragt andere Stationen, mit Ausnahme von sich selbst zum Anschluß an den logischen Ring 12 ab. Da TS = 01 und NS = 40 direkt nach dem Einschalten gesetzt werden, ist in der Station 01 der Abfrage _successor, die zuerst übermittelt wird, die Abfrage _successor_2 von SA = 01 und DA = 40 und als nächstes ist die Abfrage _successor, die als zweites übermittelt wird, die Abfrage _successor_2 von SA = 01 und DA = 3F. Auf die Abfrage _successor_2 von SA = 01 und DA = 3F kann nur die Hauptstation 00 antworten. Wenn die Hauptstation 00 durch das Setzen _successor antwortet, übermittelt die Station 01 den Token an die Hauptstation 00. Auf diese Art kann der logische Ring 12 aufgebaut werden, wenn die Stationen 00 und 01 angeschalten sind.
  • Die Hauptstation 00 übermittelt die Abfrage _successor_1 von SA = 40 und DA = NS an festgelegten Zeitabschnitten, z. B. alle 256 Runden des Tokens. Das heißt der Zustand des Netzwerkes wird überwacht, um es den Stationen zu erlauben, sich an den logischen Ring 12 anzuschließen, wenn einige Stationen, die fähig sind sich der Kommunikation anzuschließen, im Bereich von 40 bis NS anwesend sind.
  • Wie in Fig. 16 gezeigt übermittelt die Station 03 das Setzen _successor an die Hauptstation 00, unter der Annahme, daß die Stromquelle der Station 03 in einem bestimmten Zeitpunkt angschalten wurde, als die Abfrage _successor_1 von SA = 40 und DA = NS empfangen wurde, der von der Hauptstation 00 in einem festgelegten Zeitintervall gesendet wurde. Als Antwort darauf überrmittelt die Hauptstation 00 den Token an die Station 03. Wenn der Token der auf sich selbst gerichtet wurde, empfangen wird, führt die Station 03 zunächst die Abfrage _successor Prozedur der unbekannten nächsten station als Antwort darauf aus. In dieser Abfrage _successor Prozedur wird zuerst der Abfrage _successor_1 von SA = 03 und DA = 01 und als zweites der Abfrage _successor_2 von SA = 03 und DA = 40 antworten. Daher antwortet die Station 01 darauf mit dem Setzen _successor und demnach übermittel die Station 03 als Antwort darauf den Token an die Station 01. Auf diese Weise schließt sich die Station 03 an den logischen Ring 12 an und der Token zirkuliert unter den Stationen in der Reihenfolge von 03 &rarr; 01 &rarr; 40 &rarr; 03 ....
  • Ferner übermittelt die Station 04 das Setzen _successor an die Hauptstation 00 unter der Annahme, daß die Stromquelle der Station 04 an einem bestimmten Zeitpunkt angeschalten wird, wenn die Abfrage _successor_1 von SA = 40 und DA = NS empfangen wird, der periodisch von der Hauptstation 00 übermittelt wird. Dann antwortet die Hauptstation 00 darauf, indem sie den Token an die Station 04 sendet. Wenn der an sich selbst gerichtete Token empfangen wird, führt die Station 04 demnach zuerst die Abfrage _successor Prozedur der unbekannten nächsten Station aus. In dieser Abfrage _successor Prozedur wird zunächst die Abfrage _successor_1 von SA = 04 und DA = 03 und als zweites die Abfrage _successor_1 von SA = 04 und DA = 02 übermittelt. Von den angschalteten Stationen kann die Station 03 auf die Abfrage _successor_1 von SA = 04 und DA = 02 antworten. Dementsprechend antwortet die Station 02 durch das Setzen _successor und die Station 04 antwortet darauf, um den Token an die Station 03 zu übermitteln. Wie oben beschrieben schließt sich die Station 04 an den logischen Ring 12 an, und der Token zirkuliert unter den Stationen in der Reihenfolge 04 &rarr; 03 &rarr; 01 &rarr; 04....
  • d) Arbeitsweise, wenn eine Unterstation in einen Übermittlung möglich und Empfang-unmöglich Zustand fällt:
  • Fig. 17 stellt eine Bearbeitung dar, wenn ein Problem in einem Teil der Kommunikationsfunktion einer Unterstation auftritt, die wie z. B. die Station 07 den Token hält, und die Unterstation in einen Übermittlung möglich und Empfang-unmöglich Zustand fällt.
  • In diesem Fall kann die Station 04 das Setzen _successor, das auf sie selbst gerichtet ist, nicht empfangen, selbst wenn die Station 07 die Abfrage _successor Prozedur der unbekannten nächsten Station ausführt, und daher ist der Bereich der Stationen wie die Objekte des Setzen _successors allmählich erweitert und kann nicht die Bedingungen des Schrittes 300 an einem bestimmten Zeitpunkt erfüllen. Zu diesem Zeitpunkt stoppt die Station 07 die Abfrage und fährt damit fort in einem Zustand des Abwartens des wirksamen Rahmens zu warten.
  • Da die Station 07 den Token zu dieser Zeit hält, fällt die Kommunikation im Netzwerk zeitweise aus. In dieser Ausführungsform wird in einem solchen Fall in derselben Art wie in der oben angeschalteten die Anfrage _token durch eine anderer Station wie z. B. der Hauptstation 00 übermittelt und die Hauptstation 00 erzeugt den Token selbst. Die Hauptstation 00 führt dann die Abfrage _successor Prozedur der unbekannten nächsten Station aus wie im angeschalteten Zustand. Die Station, die im Fenster beinhaltet ist, und die Abfrage _successor empfangen hat, mit Ausnahme der Hauptstation 00, antwortet auf die Hauptstation 00 durch das Setzen _successor. Die Hauptstation 00 übermittelt den Token an die beantwortete Station.
  • Das heißt, daß in dieser Ausführungsform, wenn eine Untertokenhaltestation, wie z. B. die Station 07, auf Schwierigkeiten trifft, wie z. B. das Fallen in einen Übermittlung möglich und Empfang-unmöglich Zustand, wird der Abfrageprozeß durch die tokenhaltende Station an einem bestimmten Zeitpunkt beendet. Ferner kann danach der Token durch die Hauptstation 00 hergestellt werden und der logische Ring 12 wieder aufgebaut werden. Daher ist ein Zurücksetzen von Hand, wie es in der IEEE 802.4 benötigt wird nicht notwendig. Ferner kann die frühere Tokenhaltestation wie z. B. die Unterstation 07 nicht auf die Abfrage _successor, der von der Hauptstation 00 gesendet wurde, antworten, nachdem der Token durch die Anfragetokenübermittlung erhalten wurde. Daher ist die Station, die in einen Übermittlung möglich und Empfangunmöglich Zustand gefallen ist, automatisch vom logischen Ring 12 entfernt werden und demnach kann die fehlerhafte Station leicht bestimmt werden.
  • e) Bearbeitung, wenn eine Hauptstation in einen Übermittlung möglich und Empfang-unmöglich Zustand fällt:
  • Fig. 18 zeigt eine Bearbeitung, wenn eine Schwierigkeit in einem Teil der Kommunikationsfunktion der Hauptstation 00 auftritt, die den Token hält und die Hauptstation 00 in einen Übermittlung möglich und Empfang-unmöglich Zustand fällt.
  • In dieser Ausführungsform wird zum Unterschied zu dem Fall der Unterstation, die Abfrage _successor Prozedur selbst dann nicht gestoppt, wenn das Fenser auf ein Maximum erweitert wird, und die Übermittlung der Abfrage _successor_2 an alle Stationen wiederholt und kontinuierlich ausgeführt wird.
  • Obwohl eine Station mit Ausnahme einer speziellen Station (z. B. Hauptstation 00) wie oben beschrieben entsprechend der vorliegenden Erfindung wiederholt die Übermittlung von Abfragen bis zu einer vorbestimmten Anzahl von Malen ausführt, wenn die Station keine Antwort auf ihre Abfragen empfängt, geht die Station in den Zustand des Abwartens der an sie selbst gerichteten Übermittlung über. Ferner kann die besondere Station den Token selbst erzeugen und die Übermittlung der Abfrage ausführen, selbst wenn keine der anderen Stationen sich der Kommunikation anschließt. Daher kann die besondere Station einen Token erzeugen und den logischen Ring wieder neu aufbauen, wenn die Tokenhaltestation, mit Ausnahme der besonderen Station, auf ein Problem trifft, z. B. das Fallen in einen Übermittlung möglich und Empfang-unmöglich Zustand und daher kann das Netzwerk automatisch in einen Kommunikationszustand zurückkehren. Ferner kann die Station, die in einen Übermittlungmöglich und Empfang-unmöglich Zustand gefallen ist, nicht vom Abwartezustand zurückkehren. Daher kann die Schwierigkeit wirksam bestimmt werden und die Schwierigkeiten verursachende Station leicht vom logischen Ring entfernt werden.
  • Obwohl die vorliegende Erfindung in ihren bevorzugten Ausführungsformen mit Bezug auf die begleitenden Zeichnungen beschrieben wurde, kann leicht verstanden werden, daß die vorliegende Erfindung nicht durch die bevorzugten Ausführungsformen begrenzt wird und das verschiedene Änderungen und Modifikationen durch den Fachmann durchgeführt werden können, ohne den Bereich der vorliegenden Erfindung zu verlassen.

Claims (2)

1. Kommunikationsnetzwerk mit einer Mehrzahl von Stationen (00, 01, 02, 03), welche einen logischen Ring (12) bilden, um eine Information zu senden und zu empfangen, wobei der logische Ring durch einen Tokendurchlaufprozess, um das Token, welches das Recht zum Senden einer Information darstellt, zwischen den Stationen in dem logischen Ring durchlaufen zu lassen, und einen Einbindungsprozess gebildet und aufrechterhalten wird, um Stationen, welche nicht in dem logischen Ring vorhanden sind, und die Stationen in dem Netzwerk einzubinden, welches wenigstens eine besondere Station enthält,
wobei jede der Stationen ebenso wie die besondere Station:
eine Einbindungseinrichtung zur Durchführung des Einbindungsprozesses, wenn ein Token gehalten wird;
eine Einbindungsansprecheinrichtung zum Senden eines Rahmens, um auf den Einbindungsprozess anzusprechen, welcher von irgendeiner Station in dem Netzwerk durchgeführt wird; und
eine Tokensendeeinrichtung aufweist, welche das Token der Station sendet, welche einen Rahmen gesendet hat, um auf den Einbindungsprozess anzusprechen, wenn das Token gehalten wird;
wobei jede Station außer der besonderen Station des weiteren:
eine erste Einbindungswiederholungseinrichtung, welche den Einbindungsprozess höchstens eine vorbestimmte Anzahl wiederholt, wenn kein Rahmen von anderen Stationen in dem Netzwerk ankommt, um auf den Einbindungsprozess anzusprechen, wenn das Token gehalten wird;
eine Freizustandsbewegungseinrichtung, welche erwägt, dass keine anderen Stationen an dem logischen Ring teilnehmen, wenn kein Rahmen im Ansprechen auf den Einbindungsprozess ankommt, bis der Einbindungsprozess die bestimmte Anzahl wiederholt wird, und welche einen Freizustand bewegt, um die Ankunft eines Rahmens von irgendeiner Station in dem Netzwerk zu erwarten; und
eine Rückkehreinrichtung aufweist, welche eine vorbestimmte Operation von dem Freizustand durch Ansprechen auf einen Rahmen, welcher von irgendeiner Station des Netzwerks ankommt, wieder aufnimmt;
wobei das Kommunkationsnetzwerk dadurch gekennzeichnet ist, dass
die besondere Station des weiteren:
eine zweite Einbindungswiederholungseinrichtung, welche den Einbindungsprozess wiederholt, wenn kein Rahmen von irgendeiner Station des Netwerks im Ansprechen auf den Einbindungsprozess ankommt, welcher von der besonderen Station ausgeführt wird; und
eine Tokenerzeugungseinrichtung aufweist, welche das Token erzeugt, wenn keine andere Station an dem logischen Ring teilnimmt.
2. Kommunikationsverfahren zur Durchführung einer Kommunikation unter einer Mehrzahl von Stationen (00, 01, 02, 03), welche an einem logischen Ring (12) teilnehmen, welcher durch einen Tokendurchlaufprozess, um das Token, welches das Recht zum Senden einer Information darstellt, zwischen den Stationen in dem logischen Ring durchlaufen zu lassen, und einen Einbindungsprozess gebildet und aufrechterhalten wird, um Stationen einzubinden, welche nicht in dem logischen Ring vorhanden sind, wobei das Kommunikationsverfahren die Schritte aufweist:
einen Einbindungsschritt (306, 308), welcher den Einbindungsprozess von einer Station durchführen läßt, welche derzeit das Token hält;
einen Einbindungsansprechschritt (314), welcher einen Rahmen von einer anderen Station der Station sendet, die derzeit das Token hält;
einen Tokensendeschritt (320), welcher das Token von der Station, welche derzeit das Token hält, der anderen Station sendet, wenn die Station, welche derzeit das Token hält, den Rahmen im Ansprechen auf den dadurch durchgeführten Einbindungsprozess empfängt;
einen ersten Einbindungswiederholungsschritt (302, 312), welcher die Station, welche derzeit das Token hält, dazu befähigt den Einbindungsprozess höchstens eine vorbestimmte Anzahl zu wiederholen, wenn die Station, welche derzeit das Token hält, einen Rahmen von irgendeiner Station in dem Netzwerk im Ansprechen auf den Einbindungsprozess nicht empfangen kann, welcher von der Station durchgeführt wird, welche derzeit das Token hält und nicht die besondere Station ist;
einen Freizustandsbewegungsschritt (322), welcher erwägt, dass keine anderen Stationen an dem logischen Ring teilnehmen, wenn kein Rahmen ankommt, um auf den Einbindungsprozess anzusprechen, welcher von der Station durchgeführt wird, welche derzeit das Token hält, außer der besonderen Station, bis der Einbindungsprozess die vorbestimmte Anzahl wiederholt wird, und welcher sich auf einen Freizustand bewegt, um die Ankunft eines Rahmens von irgendeiner Station ansprechend auf den Einbindungsprozess zu erwarten;
einen Rückkehrschritt, welcher auf einen Rahmen anspricht, der von irgendeiner Station in dem Netzwerk ankommt, und welcher die Station, welche die Token haltende Station, jedoch nicht die besondere Station ist, dazu befähigt, eine vorbestimmte Operation wieder aufzunehmen;
wobei das Kommunikationsverfahren gekennzeichnet ist durch:
einen zweiten Einbindungswiederholungsschritt (326), welcher den Einbindungsprozess wiederholt, wenn die besondere Station derzeit das Token hält und wenn kein Rahmen von irgendeiner Station in dem Netzwerk im Ansprechen auf den Einbindungsprozess ankommt; und
einen Tokenerzeugungsschritt, welcher es der besonderen Station gestattet das Token zu erzeugen, wenn keine andere Station an dem logischen Ring teilnimmt.
DE69426739T 1993-05-21 1994-05-20 Übertragungsnetzwerk Expired - Fee Related DE69426739T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP05120019A JP3115451B2 (ja) 1993-05-21 1993-05-21 通信用ネットワーク

Publications (2)

Publication Number Publication Date
DE69426739D1 DE69426739D1 (de) 2001-04-05
DE69426739T2 true DE69426739T2 (de) 2001-10-11

Family

ID=14775898

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69426739T Expired - Fee Related DE69426739T2 (de) 1993-05-21 1994-05-20 Übertragungsnetzwerk

Country Status (6)

Country Link
US (1) US5600796A (de)
EP (1) EP0631411B1 (de)
JP (1) JP3115451B2 (de)
KR (1) KR0127913B1 (de)
AU (1) AU664516B2 (de)
DE (1) DE69426739T2 (de)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5878428A (en) * 1995-11-20 1999-03-02 International Business Machines Corporation System, method, and article of manufacture for adding transactional recovery to a binary class in an object oriented system
US5737514A (en) * 1995-11-29 1998-04-07 Texas Micro, Inc. Remote checkpoint memory system and protocol for fault-tolerant computer system
US6085244A (en) * 1997-03-17 2000-07-04 Sun Microsystems, Inc. Dynamic test update in a remote computer monitoring system
US6151683A (en) * 1997-03-31 2000-11-21 Sun Microsystems, Inc. Rebuilding computer states remotely
US6182249B1 (en) 1997-05-12 2001-01-30 Sun Microsystems, Inc. Remote alert monitoring and trend analysis
US6154128A (en) * 1997-05-21 2000-11-28 Sun Microsystems, Inc. Automatic building and distribution of alerts in a remote monitoring system
US6133853A (en) * 1998-07-30 2000-10-17 American Calcar, Inc. Personal communication and positioning system
US6148261A (en) 1997-06-20 2000-11-14 American Calcar, Inc. Personal communication system to send and receive voice data positioning information
US6237114B1 (en) 1998-05-13 2001-05-22 Sun Microsystems, Inc. System and method for evaluating monitored computer systems
US6687754B1 (en) * 1998-08-27 2004-02-03 Intel Corporation Method of detecting a device in a network
WO2001029573A2 (en) * 1999-10-19 2001-04-26 American Calcar Inc. Technique for effective navigation based on user preferences
US7475057B1 (en) 1999-10-27 2009-01-06 American Calcar, Inc. System and method for user navigation
KR20030022876A (ko) 2000-07-28 2003-03-17 아메리칸 캘카어 인코포레이티드 정보의 효과적인 구성 및 통신을 위한 기술
US7649473B2 (en) 2006-02-16 2010-01-19 Intelliserv, Inc. Physically segmented logical token network
JP5147772B2 (ja) * 2009-03-30 2013-02-20 三菱電機株式会社 巡回路生成装置及び巡回路生成方法及び巡回路生成プログラム
CN112784511B (zh) * 2019-11-11 2023-09-22 杭州起盈科技有限公司 一种组合逻辑环路的自动拆除方法

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS59188256A (ja) * 1983-04-11 1984-10-25 Hitachi Ltd ル−プ伝送システムの伝送方法
US4663748A (en) * 1984-04-12 1987-05-05 Unisearch Limited Local area network
US4707830A (en) * 1985-03-05 1987-11-17 General Electric Company Token passing LAN using a plurality of tokens
US4661902A (en) * 1985-03-21 1987-04-28 Apple Computer, Inc. Local area network with carrier sense collision avoidance
US4680581A (en) * 1985-03-28 1987-07-14 Honeywell Inc. Local area network special function frames
JPH04502991A (ja) * 1988-11-14 1992-05-28 データーポイント・コーポレーション 動的に選択可能な多重操作性を備えたローカル・エリア・ネットワーク
US5257264A (en) * 1989-08-29 1993-10-26 Digital Equipment Corporation Automatically deactivated no-owner frame removal mechanism for token ring networks
US5012468A (en) * 1989-12-28 1991-04-30 Allen-Bradley Company, Inc. Master slave industrial token passing network
US5414700A (en) * 1990-01-22 1995-05-09 Digital Equipment Corp. Negotiation protocol for establishment of full duplex communication on a token ring network
EP0459756A3 (en) * 1990-05-29 1994-06-15 Advanced Micro Devices Inc Fiber distributed data interface network
US5182747A (en) * 1990-06-26 1993-01-26 International Business Machines Corporation Method for controlling the insertion of stations into fddi network

Also Published As

Publication number Publication date
AU664516B2 (en) 1995-11-16
EP0631411A3 (de) 1996-02-28
US5600796A (en) 1997-02-04
JPH06334666A (ja) 1994-12-02
KR0127913B1 (ko) 1998-04-10
EP0631411A2 (de) 1994-12-28
DE69426739D1 (de) 2001-04-05
EP0631411B1 (de) 2001-02-28
AU6327094A (en) 1994-12-01
KR940027386A (ko) 1994-12-10
JP3115451B2 (ja) 2000-12-04

Similar Documents

Publication Publication Date Title
DE69426739T2 (de) Übertragungsnetzwerk
DE69529016T2 (de) Signalisierungsprotokoll für störbehaftete Übertragungskanäle
DE3785217T2 (de) Verfahren zur uebertragung von daten in paketvermittlungsnetzen.
DE69634914T2 (de) Hybrides begrenztes konkurrenz- und abfrageprotokoll
DE69634983T2 (de) Verfahren und vorrichtung für ein hybrides wettbewerbs- und abfrageprotokoll
DE3779694T2 (de) Rechnernetzwerksystem.
DE3685935T2 (de) Kommunikationssystem zur uebertragung kleiner digitaler nachrichtenbloecke und grosser digitaler nachrichtenbloecke.
DE69929575T2 (de) Verfahren zur drahtlosen Kommunikationssteuerung und Vorrichtung zur drahtlosen Übertragung
DE602005004047T2 (de) Methode zur Zuordnung von Adressen zu einer Vielzahl von Geräten in einem Netzwerk und entsprechendes System
EP0925674B1 (de) Verfahren zur kontrolle der verbindungen eines übertragungssystems und komponente zur durchführung des verfahrens
DE3750647T2 (de) Netz mit Jetonübergabe.
DE69633112T2 (de) Verfahren zur intitialisierung eines drahtlosen paketsprungnetzwerkes
EP1205052B1 (de) Verfahren zur einstellung einer datenübertragungsrate in einem feldbussystem
DE69835014T2 (de) Registrierungsverfahren in einem kommunikationssystem
DE60132735T2 (de) Fehlerkorrekturübertragungsverfahren zum Übertragen von Datenpaketen in einem Netzkommunikationssystem
DE69026331T2 (de) Station zu Station Vollduplexkommunikation bei Kommunikationsnetzwerken
DE69634482T2 (de) Konkurrenzbetriebsauflösungsverfahren für Datennetzwerke
DE60118073T2 (de) Geräte, Software, und Verfahren zur Umplanung von Mehrparteiensitzungen nach frühzeitiger Auflösung einer Sitzung
DE69021186T2 (de) &#34;Master-Slave&#34; industrielles Netzwerk mit Tokenübergabe.
DE3619906A1 (de) Adaptives uebermittlungssystem
EP2622826A1 (de) Verfahren zur automatischen adressvergabe an gleichartige busteilnehmer
DE10393600T5 (de) Verfahren zum Bestätigen von Nachrichten in einem Kommunikationssystem
EP2237592A2 (de) Verfahren zur Optimierung von Netzwerkstrukturen in Funknetzwerken
WO2001003379A1 (de) Schnurloses datenübertragungsnetzwerk und verfahren zu seiner verwaltung
DE69027342T2 (de) Bidirektionales Datenkommunikationssystem

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8320 Willingness to grant licences declared (paragraph 23)
8339 Ceased/non-payment of the annual fee