DE10004425A1 - Netzwerk sowie Netzwerkteilnehmer, insbesondere Feldgerät, für ein derartiges Netzwerk - Google Patents

Netzwerk sowie Netzwerkteilnehmer, insbesondere Feldgerät, für ein derartiges Netzwerk

Info

Publication number
DE10004425A1
DE10004425A1 DE2000104425 DE10004425A DE10004425A1 DE 10004425 A1 DE10004425 A1 DE 10004425A1 DE 2000104425 DE2000104425 DE 2000104425 DE 10004425 A DE10004425 A DE 10004425A DE 10004425 A1 DE10004425 A1 DE 10004425A1
Authority
DE
Germany
Prior art keywords
network
telegram
time
port
participant
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.)
Ceased
Application number
DE2000104425
Other languages
English (en)
Inventor
Dieter Klotz
Karl Glas
Christoph Muench
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.)
Siemens AG
Original Assignee
Siemens AG
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 Siemens AG filed Critical Siemens AG
Priority to DE2000104425 priority Critical patent/DE10004425A1/de
Priority to PCT/DE2001/000413 priority patent/WO2001058067A1/de
Publication of DE10004425A1 publication Critical patent/DE10004425A1/de
Ceased legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04JMULTIPLEX COMMUNICATION
    • H04J3/00Time-division multiplex systems
    • H04J3/02Details
    • H04J3/06Synchronising arrangements
    • H04J3/0635Clock or time synchronisation in a network
    • H04J3/0638Clock or time synchronisation among nodes; Internode synchronisation
    • H04J3/0658Clock or time synchronisation among packet nodes
    • H04J3/0661Clock or time synchronisation among packet nodes using timestamps
    • H04J3/0664Clock or time synchronisation among packet nodes using timestamps unidirectional timestamps
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04JMULTIPLEX COMMUNICATION
    • H04J3/00Time-division multiplex systems
    • H04J3/02Details
    • H04J3/06Synchronising arrangements
    • H04J3/0635Clock or time synchronisation in a network
    • H04J3/0679Clock or time synchronisation in a network by determining clock distribution path in a network
    • 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/413Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04JMULTIPLEX COMMUNICATION
    • H04J3/00Time-division multiplex systems
    • H04J3/02Details
    • H04J3/06Synchronising arrangements
    • H04J3/0635Clock or time synchronisation in a network
    • H04J3/0638Clock or time synchronisation among nodes; Internode synchronisation
    • H04J3/0658Clock or time synchronisation among packet nodes
    • H04J3/0661Clock or time synchronisation among packet nodes using timestamps
    • H04J3/0667Bidirectional timestamps, e.g. NTP or PTP for compensation of clock drift and for compensation of propagation delays
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04JMULTIPLEX COMMUNICATION
    • H04J3/00Time-division multiplex systems
    • H04J3/02Details
    • H04J3/06Synchronising arrangements
    • H04J3/0635Clock or time synchronisation in a network
    • H04J3/0638Clock or time synchronisation among nodes; Internode synchronisation
    • H04J3/0658Clock or time synchronisation among packet nodes
    • H04J3/0673Clock or time synchronisation among packet nodes using intermediate nodes, e.g. modification of a received timestamp before further transmission to the next packet node, e.g. including internal delay time or residence time into the packet
    • 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
    • H04L2012/4026Bus for use in automation systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/28Timers or timing mechanisms used in protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

Die Erfindung betrifft ein Netzwerk mit mehreren Netzwerkteilnehmern. Ein erster Netzwerkteilnehmer sendet in einem Telegramm zur Uhrzeitsynchronisation an einen zweiten Netzwerkteilnehmer eine um die Sendezeitverzögerung korrigierte Uhrzeit. Im zweiten Netzwerkteilnehmer ist die Durchlaufzeit über die physikalische Übertragungsstrecke abgespeichert. Dieser korrigiert die empfangene Uhrzeit um die Durchlaufzeit und seine Empfangszeitverzögerung. Damit wird eine erhöhte Genauigkeit der Uhrzeitsynchronisation erreicht.

Description

Die Erfindung betrifft ein Netzwerk nach dem Oberbegriff des Anspruchs 1 sowie einen Netzwerkteilnehmer, insbesondere ein Feldgerät, für ein derartiges Netzwerk.
Ein derartiges Netzwerk ist beispielsweise aus der DE 197 10 971 A1 bekannt. In einem Netzwerk mit einer Mehr­ zahl von Netzwerkteilnehmern, beispielsweise Sensoren und Aktuatoren, die über das Netzwerk zur Datenübertragung mit­ einander verbunden sind, muß für zeitkritische Anwendungen, beispielsweise für zeitgleiche Meßwerterfassung bei Regel­ vorgängen, eine Synchronisation vorgenommen werden. Zur Syn­ chronisation der Teilnehmer wird durch einen Teilnehmer ein Telegramm an die weiteren Teilnehmer gesendet, das beispiels­ weise dazu benutzt werden kann, eine gleichzeitige Erfassung von Meßwerten durch bestimmte Teilnehmer zu veranlassen. Dabei wird berücksichtigt, daß bei der Übertragung von Tele­ grammen zwischen Sender und Empfänger Durchlaufzeiten über die physikalische Übertragungsstrecke entstehen, die unter anderem durch die Entfernung und die physikalische Übertra­ gungsgeschwindigkeit der Signale auf dem Übertragungsmedium bestimmt werden. Damit sich auch Laufzeitdifferenzen von Telegrammen zu verschiedenen Teilnehmern nicht negativ auf die Synchronisationsgenauigkeit auswirken, werden die Lauf­ zeiten jeweils automatisch durch eine Telegrammsequenz erfaßt. Insbesondere in Netzwerken, deren Topologie und räum­ liche Ausdehnung veränderlich ist, bringt eine automatische Bestimmung der Durchlaufzeit Vorteile. Veränderungen können beispielsweise auftreten, wenn Teilnehmer nur temporär oder an verschiedenen Orten angeschlossen werden. Eine Möglichkeit zur Synchronisation der Teilnehmer besteht darin, daß ein Teilnehmer seine Uhrzeit in einem Telegramm an die übrigen Teilnehmer überträgt. Die zuvor ermittelte Durchlaufzeit des Telegramms ist in den übrigen Teilnehmern gespeichert. Diese korrigieren die in dem Telegramm empfangene Uhrzeit um die jeweilige Durchlaufzeit des Telegramms und synchronisieren auf diese Weise ihre interne Uhr auf die Uhrzeit des Senders.
Der Erfindung liegt die Aufgabe zugrunde, ein Netzwerk sowie einen Teilnehmer, insbesondere ein Feldgerät, für ein derar­ tiges Netzwerk zu schaffen, die sich durch eine verbesserte Genauigkeit bezüglich der Uhrzeitsynchronisation auszeichnen.
Zur Lösung dieser Aufgabe weist das neue Netzwerk der ein­ gangs genannten Art die im kennzeichnenden Teil des An­ spruchs 1 angegebenen Merkmale auf. Ein Netzwerkteilnehmer, insbesondere ein Feldgerät, für ein derartiges Netzwerk sowie vorteilhafte Ausgestaltungen der Erfindung sind in Anspruch 11 bzw. in den Unteransprüchen beschrieben.
Die Erfindung hat den Vorteil, daß eine Sendezeitverzögerung im Sender sowie eine Empfangszeitverzögerung im Empfänger, die veränderlich sein können, bei der Uhrzeitsynchronisation berücksichtigt werden.
Dazu sendet ein erster Netzwerkteilnehmer ein erstes Tele­ gramm an einen zweiten Netzwerkteilnehmer, das die um eine Sendezeitverzögerung korrigierte Uhrzeit des ersten Netz­ werkteilnehmers enthält. Im zweiten Teilnehmer ist die Tele­ grammlaufzeit über die physikalische Übertragungsstrecke zwischen dem ersten Netzwerkteilnehmer und dem zweiten Netz­ werkteilnehmer als Durchlaufzeit gespeichert. Sie kann bei­ spielsweise manuell eingegeben oder durch einen weiteren Telegrammverkehr zuvor gemessen worden sein. Der zweite Netz­ werkteilnehmer mißt die Zeitverzögerung seit Empfang des ersten Telegramms und korrigiert die im ersten Telegramm empfangene Uhrzeit um die Durchlaufzeit und die gemessene Empfangszeitverzögerung. Der zweite Netzwerkteilnehmer ist somit vorteilhaft jederzeit in der Lage, eine synchronisierte Uhrzeit aus der Summe der im Telegramm empfangenen Uhrzeit und der um die Laufzeit ergänzten Empfangszeitverzögerung zu ermitteln. Variable Sende- und Empfangszeitverzögerungen wirken sich nicht auf das Ergebnis der Synchronisation aus.
Ist der zweite Netzwerkteilnehmer weiterhin dazu ausgebildet, ein zweites Telegramm zur Uhrzeitsynchronisation an einen dritten Netzwerkteilnehmer zu senden, das eine um die Lauf­ zeit und die Verzögerungszeit zwischen Empfang des ersten Telegramms und Senden des zweiten Telegramms korrigierte empfangene Uhrzeit enthält, so wird ein iteratives Weiter­ senden der jeweils korrigierten Uhrzeit von Netzwerkteil­ nehmer zu Netzwerkteilnehmer möglich. In den empfangenden Netzwerkteilnehmern können jeweils identische Korrektur­ mechanismen angewendet werden. Die jeweils in einem Netz­ werkteilnehmer abgespeicherte Laufzeit entspricht der Lauf­ zeit über die physikalische Übertragungsstrecke zwischen dem jeweils zuletzt sendenden und dem empfangenden Netzwerk­ teilnehmer.
Alternativ zum Senden eines Telegramms zur Uhrzeitsynchroni­ sation von einem ersten Netzwerkteilnehmer zu einem zweiten kann auch eine Uhrzeitsynchronisation mit zwei Telegrammen erfolgen. Dazu sendet der erste Netzwerkteilnehmer ein erstes Telegramm zur Uhrzeitsynchronisation an einen zweiten Netz­ werkteilnehmer und speichert gleichzeitig eine um die Sende­ zeitverzögerung korrigierte Uhrzeit des ersten Netzwerkteil­ nehmers ab. Im zweiten Netzwerkteilnehmer ist die Laufzeit des Telegramms über die physikalische Übertragungsstrecke zwischen dem ersten Netzwerkteilnehmer und dem zweiten Netz­ werkteilnehmer abgespeichert. Der zweite Netzwerkteilnehmer mißt die Zeitverzögerung seit Empfang des ersten Telegramms, ohne jedoch den dazu dienenden Timer anzuhalten. Der erste Netzwerkteilnehmer sendet nun ein zweites Telegramm, das die um die Sendezeitverzögerung korrigierte Uhrzeit des ersten 3 Netzwerkteilnehmers enthält, an den zweiten Netzwerkteilneh­ mer. Die im zweiten Telegramm empfangene Uhrzeit korrigiert der zweite Netzwerkteilnehmer um die Laufzeit und die Empfangszeitverzögerung, die in bezug auf den Empfang des ersten Telegramms gemessen wird. Dieses Verfahren mit zwei Telegrammen besitzt dieselben Vorteile, die auch mit dem Verfahren zur Uhrzeitsynchronisation mit nur einem Telegramm verbunden sind.
Für ein Netzwerk mit mehr als zwei Netzwerkteilnehmern kann das Verfahren mit zwei Telegrammen ebenfalls in ein itera­ tives Verfahren fortgesetzt werden. Dazu leitet der zweite Netzwerkteilnehmer das erste Telegramm an einen dritten Netz­ werkteilnehmer weiter und mißt seine Verzögerungszeit der Telegrammweiterleitung. In einem dritten Telegramm sendet der zweite Netzwerkteilnehmer eine um die Laufzeit und die Verzö­ gerungszeit der Telegrammweiterleitung des ersten Telegramms korrigierte empfangene Uhrzeit an den dritten Netzwerkteil­ nehmer.
In vorteilhafter Weise wird die jeweils tatsächliche Sende­ zeitverzögerung bei der Uhrzeitsynchronisation berücksich­ tigt, wenn der erste Netzwerkteilnehmer einen ersten Timer zur Bestimmung der Sendezeitverzögerung aufweist, den er beim Eintragen eines Telegramms in eine Liste der Sendeaufträge startet und nach Bereitstellung des Telegramms zur physika­ lischen Übertragung als Wert der Sendezeitverzögerung aus­ liest, um welchen die Uhrzeit des Telegrammeintrags zu korri­ gieren ist.
Ebenfalls wird in vorteilhafter Weise die jeweils tatsäch­ liche Empfangszeitverzögerung bei der Übertragung berück­ sichtigt, wenn der zweite Netzwerkteilnehmer einen zweiten Timer zur Bestimmung der Empfangszeitverzögerung aufweist, den er bei Empfang eines ersten Telegramms von einer physi­ kalischen Übertragungsstrecke startet.
Die Laufzeit des Telegramms über die physikalische Übertra­ gungsstrecke zwischen dem ersten Netzwerkteilnehmer und dem zweiten Netzwerkteilnehmer kann als Startwert in den zweiten Timer vor dessen Start abgespeichert sein. Das hat den Vorteil, daß die Summe der Laufzeit und der Empfangszeit­ verzögerung durch nur einen Timer ermittelt werden kann.
In einer Weiterbildung können Beginn und Ende der Laufzeit eines Telegramms jeweils als der Zeitpunkt bestimmt werden, zu welchem ein charakteristisches Feld eines Telegramms mit festem Abstand vom Telegrammanfang ein Media-Independent- Interface des ersten Netzwerkteilnehmers verläßt bzw. in ein Media-Independent-Interface des zweiten Netzwerkteilnehmers einläuft. Vorteilhaft sind dabei Messungen der Sendezeit­ verzögerung, Laufzeit und Empfangszeitverzögerung unabhängig von der Länge des jeweiligen Telegramms.
Erfüllen die Netzwerkkomponenten die Ethernet-, Fast-Ether­ net- oder Gigabit-Ethernet-Spezifikation, so kann mit Vorteil als charakteristisches Feld des Telegramms das Type-Feld ver­ wendet werden. Im zweiten Netzwerkteilnehmer ist mit Empfang des Type-Feldes bekannt, daß es sich um ein Telegramm handelt, das zur Uhrzeitsynchronisation dient, und es können die erforderlichen Mechanismen eingeleitet werden. Das Daten­ feld befindet sich hinter dem Type-Feld und kann im Sender noch bis zur Ausgabe des Type-Feldes an das Media-Indepen­ dent-Interface verändert werden. Damit ist es möglich, bereits im selben Telegramm die um die Sendezeitverzögerung korrigierte Uhrzeit zu übertragen.
Die Laufzeit eines Telegramms über die physikalische Übertra­ gungsstrecke kann exakt bestimmt werden, indem der erste Netzwerkteilnehmer ein erstes Telegramm zur Laufzeitermitt­ lung an einen zweiten Netzwerkteilnehmer sendet und einen Antwortzeit-Timer nach Bereitstellung des Telegramms zur physikalischen Übertragung startet. Der zweite Netzwerk­ teilnehmer startet nach Empfang des ersten Telegramms zur Laufzeitermittlung einen Timer zur Messung der Aufenthalts­ zeit und stoppt den Timer nach Bereitstellung eines zweiten Telegramms zur physikalischen Übertragung an den ersten Netzwerkteilnehmer. Die gemessene Aufenthaltszeit wird in dem zweiten Telegramm zur Laufzeitermittlung an den ersten Netz­ werkteilnehmer übertragen. Nach Empfang des zweiten Tele­ gramms von der physikalischen Übertragung stoppt der erste Netzwerkteilnehmer den Antwortzeit-Timer und berechnet die Laufzeit eines Telegramms über die physikalische Übertra­ gungsstrecke als die halbe Differenz zwischen der gemessenen Antwortzeit und der Aufenthaltszeit im zweiten Netzwerkteil­ nehmer.
Mit Vorteil kann ein Netzwerkteilnehmer, insbesondere ein Feldgerät, mit mehreren Ports, insbesondere vier Ports, zum Anschluß weiterer Netzwerkkomponenten ausgestattet werden. Dabei kann eine Schnittstelle, ein sogenanntes Mikropro­ zessor-Interface, zur Verbindung der Ports mit einem teilneh­ merinternen Prozessorbus und eine Steuereinheit, eine soge­ nannte Switch-Control, vorgesehen werden, welche eine Tele­ grammweglenkung zwischen den Ports und dem Mikroprozessor- Interface vornimmt. Das hat den Vorteil, daß Netzwerkteil­ nehmer, insbesondere Feldgeräte, in der vom Anwender von Feldbussen gewohnten Weise in einer Linienstruktur verschal­ tet werden können. Ein separater Switch, wie er bei einer sternförmigen Struktur erforderlich wäre, entfällt. Insbeson­ dere bei einem Netzwerk nach Ethernet-, Fast-Ethernet- oder Gigabit-Ethernet-Spezifikation wird durch die Erfindung der Aufbau eines Netzes großer Ausdehnung ermöglicht, da ledig­ lich der Abstand zwischen zwei Netzwerkkomponenten bestimmte Grenzen nicht überschreiten darf, die Länge der Linienstruk­ tur jedoch unbegrenzt ist. Darüber hinaus hat die Integration von Switch-Funktionen in den Netzwerkteilnehmer den Vorteil, daß insbesondere bei Ethernet die CSMA/CD-Zugriffssteuerung deaktiviert werden kann und das Netzwerk ein determinist­ isches Verhalten erhält. Somit wird der Einsatzbereich der Netzwerkteilnehmer und des Netzwerks auf Anwendungsfälle erweitert, in welchen Echtzeitverhalten gefordert wird.
Wenn an den Netzwerkteilnehmern vier Ports zum Anschluß weiterer Netzwerkkomponenten vorgesehen werden, können Teil­ nehmer zu einer zwei- oder dreidimensionalen Netzwerkstruktur verschaltet werden, da bei diesen zwei Ports zur Einbindung des Netzwerkteilnehmers in eine Linie zwei weitere jeweils zur Verbindung der Linie mit einer anderen Linie verwendet werden können.
Eine Ausführung der durch die Ports realisierten Schnitt­ stellen nach der Ethernet- oder Fast-Ethernet-Spezifikation hat den Vorteil, daß bei der Realisierung beispielsweise eines Feldbusses mit derartigen Netzwerkkomponenten auf bereits aus anderen Bereichen vorhandenes Technologiewissen zurückgegriffen werden kann. Man erhält auf diese Weise ein durchgängiges Netzwerk für Office-, Leit-, Zell- und Feld­ ebene, das einen transparenten Zugriff auf beliebige Daten ermöglicht. Ein Gateway zur Kopplung von Netzwerkbereichen mit verschiedener Physik und verschiedenen Protokollen ist in vorteilhafter Weise nicht erforderlich. Zudem zeichnen sich Netzwerke auf der Basis der Ethernet-Spezifikation durch eine hohe Leistungsfähigkeit der Datenübertragung aus. Sie bieten Kostenvorteile durch eine breit verfügbare Technologie und Komponenten, die in hohen Stückzahlen vorhanden sind. Es ist möglich, eine hohe Zahl von Netzwerkteilnehmern an ein Netz­ werk anzuschließen. Durch die Erfindung werden die Vorteile der im Feldbereich favorisierten Linien- oder Busstruktur des Netzwerks, z. B. der Vorteil einer einfachen Verschaltung der Teilnehmer, mit den oben erwähnten Vorteilen von Netzwerken auf der Basis der Ethernet-Spezifikation nach IEEE 802.3 verbunden. Die in den Netzwerkteilnehmer integrierten Switch- Funktionen übernehmen die Funktion einer bisher separat in­ stallierten Netzwerkkomponente, beispielsweise eines Switchs, die damit entfällt.
Eine weitere Verbesserung bei Anwendungen in der Automatisie­ rungstechnik, insbesondere beim Einsatz in zeitkritischen Anwendungen, wird erreicht, wenn die Steuereinheit der Switch-Funktion derart ausgebildet ist, daß eine Übertra­ gungspriorität der zu versendenden Telegramme ausgewertet wird und Telegramme mit hoher Priorität vor Telegrammen mit niederer Priorität gesendet werden.
Ein Mikroprozessor zur Korrektur einer internen Uhr anhand in Telegrammen empfangener Uhrzeitinformationen hat den Vorteil, daß die Uhrzeitsynchronisation weitgehend ohne zusätzlichen Hardware-Aufwand realisiert werden kann.
Anhand der Zeichnungen, in denen Ausführungsbeispiele der Erfindung dargestellt sind, werden im folgenden die Erfindung sowie Ausgestaltungen und Vorteile näher erläutert.
Es zeigen:
Fig. 1 eine Kommunikationsstruktur einer automatisierungs­ technischen Anlage,
Fig. 2 ein Blockschaltbild einer Schnittstelle eines Netz­ werkteilnehmers,
Fig. 3 eine Reihenschaltung von Netzwerkteilnehmern mit linienförmiger Netzwerktopologie,
Fig. 4 eine Reihenschaltung von Netzwerkteilnehmern mit zwei Kommunikationskanälen,
Fig. 5 eine zweidimensionale Verschaltung von Netzwerk­ teilnehmern,
Fig. 6 eine zweidimensionale Verschaltung mit redundanter Auslegung,
Fig. 7 ein zweidimensionales Netzwerk nach erfolgter Redundanzverwaltung,
Fig. 8 ein dreidimensionales Netzwerk nach erfolgter Redundanzverwaltung,
Fig. 9 den prinzipiellen Aufbau eines Telegramms und
Fig. 10 den Aufbau einer Auftragsliste.
Fig. 1 zeigt den Aufbau einer Kommunikationsstruktur in einer automatisierungstechnischen Anlage. Die Kommunikation erfolgt durchgängig auf der Leit-, Zell- und Feldebene durch ein Netzwerk, dessen Datenübertragung dem Fast-Ethernet- Standard nach IEEE 802.3u genügt. In der Feldebene sind ein Sensor 1, beispielsweise ein Druckmeßumformer, ein Sensor 2, hier ein Ultraschalldurchflußmeßumformer, ein Aktuator 3, ein Regelventil zur Einstellung eines Durchflusses, und eine speicherprogrammierbare Steuerung 4 mit Twisted-Pair-Lei­ tungen 5, 6 bzw. 7 busförmig verschaltet. Die speicherpro­ grammierbare Steuerung 4 bildet zusammen mit den beiden Sensoren 1 und 2 sowie dem Aktuator 3 einen Regelkreis, in welchem die Stellung des Regelventils in Abhängigkeit von den Meßwerten des Druckmeßumformers sowie des Durchflußmeßumfor­ mers vorgegeben wird. Die speicherprogrammierbare Steuerung 4 ist über eine Twisted-Pair-Leitung 8 an einen Switch 9 angeschlossen. Mit dem Switch 9 sind in einer sternförmigen Topologie weiterhin ein Zellrechner 10, ein Leitrechner 11 sowie ein Firewall 12, mit welchem ein gesicherter Ethernet- Zugang realisiert ist, verbunden. Mit einer Leitung 13 sind weitere, in der Figur der Übersichtlichkeit wegen nicht dar­ gestellte Zellrechner von benachbarten Zellen der automati­ sierungstechnischen Anlage an den Switch 9 angeschlossen. Anhand des in Fig. 1 dargestellten Beispiels wird insbeson­ dere der Vorteil einer hohen Datentransparenz über alle Ebenen hinweg deutlich. Für Leit-, Zell- und Feldebene wird derselbe Übertragungsstandard verwendet. Dabei sind die Feld­ geräte 1, 2 und 3 mit der speicherprogrammierbaren Steuerung 4 in der vom Anwender gewohnten Weise in einer linienförmigen Topologie verschaltet. Ein weiterer Vorteil ist die durchgän­ gige Verwendbarkeit einheitlicher Adressen für die einzelnen Netzwerkteilnehmer. Eine Adreßumsetzung, wie sie bei der Verwendung verschiedener Standards in den verschiedenen Ebe­ nen erforderlich wäre, kann bei dem neuen Netzwerk und den neuen Netzwerkteilnehmern in einer automatisierungstech­ nischen Anlage entfallen.
Fig. 2 zeigt den prinzipiellen Aufbau der Kommunikations­ schnittstelle eines Netzwerkteilnehmers, beispielsweise des Sensors 2 in Fig. 1. Applikationsspezifische Schaltungsteile, wie z. B. ein mechanisch-elektrisches Wandlerelement, eine Einrichtung zur Signalvorverarbeitung und eine Spannungsver­ sorgung, sind der Übersichtlichkeit wegen nicht dargestellt. Die in einem Rechteck 20 zusammengefaßten Teile können in einem ASIC (Application Specific Integrated Circuit) inte­ griert werden. Die Kommunikation mit den anwendungsspe­ zifischen Schaltungsteilen des Netzwerkteilnehmers erfolgt über einen Mikroprozessor-Bus 21, an welchen ein RAM 22, ein Mikroprozessor 23 und ein Mikroprozessor-Interface 25 ange­ schlossen sind. Mit durchbrochenen Linien ist in der Darstel­ lung des Mikroprozessors 23 angedeutet, daß die Integration in das ASIC optional ist. Seine Funktionen könnten von einem externen Prozessor übernommen werden. Aufgabe des Mikro­ prozessors 23 ist die Ausführung von Anwenderprogrammen und von Kommunikationsfunktionen, beispielsweise die Abwicklung von TCP/IP. Eine weitere Aufgabe kann die Verwaltung von Sende- und Empfangslisten von Telegrammen unterschiedlicher Priorität im externen RAM 22 sein. Der Mikroprozessor 23 wählt aus einer Sendeliste im externen RAM 22 einen Auftrag 3 aus und startet über ein Mikroprozessor-Interface 25 einen DMA-Kontroller 26, der als DMA 1-Control bezeichnet wird, nachdem er zuvor in den DMA-Kontroller 26 die Anzahl der zu sendenden Daten-Bytes und einen Pointer, der auf das zu sendende Daten-Byte zeigt, eingetragen hat. Ist der Sende­ auftrag durch den DMA-Kontroller 26 vollständig in einen Transmit-Buffer 27 übertragen, so entfernt der Mikroprozessor 23 diesen Sendeauftrag aus der Sendeliste im RAM 22 und bearbeitet den nächsten Sendeauftrag, sofern die Sendeliste nicht leer ist und im Transmit-Buffer 27 noch freier Speicherplatz verfügbar ist.
In das ASIC 20 sind weiterhin vier Ethernet-Kontroller 28, 29, 30 und 31 integriert. Jeder dieser Ethernet-Kontroller trägt die Datenbytes eines vollständig empfangenen Telegramms über einen Multiplexer 32, einen DMA-Kontroller 33, der auch als DMA 2-Control bezeichnet wird, und das Mikroprozessor- Interface 25 in eine Empfangsliste im RAM 22 ein. Der Mikroprozessor 23 greift auf die Empfangsliste zu und wertet die empfangenen Daten entsprechend einem Applikationsprogramm aus.
Das Mikroprozessor-Interface 25 bildet die wesentliche Schnittstelle zwischen den Ethernet-Kontrollern 28 . . . 31 und dem Mikroprozessor-Bus 21. Es steuert oder arbitriert die Schreib- und Lesezugriffe, die über den DMA-Kontroller 33 bzw. den DMA-Kontroller 26 auf das RAM 22 erfolgen. Liegen von beiden DMA-Kontrollern 26 und 33 gleichzeitig DMA-Anfor­ derungen vor, so entscheidet das Mikroprozessor-Interface 25 über die Zugriffsrechte der beiden DMA-Kanäle. Über das Mik­ roprozessor-Interface 25 können weiterhin durch den Mikro­ prozessor 23 Parameterregister 34 geschrieben werden, die zum Betrieb der Kommunikationsschnittstelle des Netzwerkteilneh­ mers erforderlich sind. Als Beispiele seien ein Pointer auf den Beginn des hochprioren Speicherbereichs in einem Transmit-Buffer eines Ethernet-Kontrollers, ein Pointer auf den Beginn des hochprioren Speicherbereichs in jedem der Receive-Buffer der Ethernet-Kontroller, ein Betriebsartenre­ gister für allgemeine Steuerbits, eine Adresse der Reihe, welcher der Netzwerkteilnehmer angehört, eine Zykluszeit für sog. Port-Select-Telegramme und Einstellungen verschiedener Überwachungszeitintervalle genannt.
Der Transmit-Buffer 27 hat eine Größe von mehr als drei Kilobyte und ist in einen Speicherbereich für hochpriore und einen Speicherbereich für niederpriore Telegramme aufgeteilt. Das Verhältnis der beiden Speicherbereiche ist parametrier­ bar. Die Speicherbereiche des Transmit-Buffers für hoch- und niederpriore Daten sind jeweils als Ringpuffer realisiert. Mit dem Senden der Daten aus dem Transmit-Buffer 27 über einen oder mehrere Ethernet-Kontroller 28 . . . 31 wird begon­ nen, wenn die Anzahl der eingetragenen Bytes eines Telegramms größer ist als der parametrierbare Füllstand, oder wenn ein komplettes Telegramm vom RAM 22 in den Transmit-Buffer 27 kopiert wurde und mindestens ein Ethernet-Kontroller 28 . . . 31 für den Sendebetrieb frei ist.
Die Ethernet-Kontroller 28 . . . 31 sind jeweils identisch aufgebaut. Ihr Aufbau wird am Beispiel des Ethernet-Kont­ rollers näher erläutert. Eine Einrichtung 40, die als Trans­ mit-Control bezeichnet wird, enthält ein Steuerwerk, das für das Senden von Telegrammen, für Wiederholungen, Sendeabbruch usw. verantwortlich ist. Sie bildet die Schnittstelle zwischen dem internen Kontrollertakt und dem Sendetakt. Zum Speichern einer Transmit-Status-Information für niederpriore und hochpriore Telegramme ist jeweils ein Transmit-Status- Register in der Einrichtung 40 vorgesehen. Wenn ein Telegramm fehlerfrei über den Port gesendet wurde, wird ein ent­ sprechender Interrupt erzeugt.
Ein Media Independent Interface 41 (MII) integriert den MAC- Sublayer des Layers 2 nach dem Sieben-Schichten-Modell, d. h. des Data-Link-Layer. Dieses bildet eine Schnittstelle zu einem Baustein 36 zur physikalischen Datenübertragung. Weiterhin enthält das MII 41 einen Transmit-Function-Block 42 sowie einen Receive-Function-Block 43. Darüber hinaus sind ein in der Fig. 2 nicht dargestellter MAC-Control-Block, ein Adreßfilter, ein Statistikzähler und ein Host-Interface inte­ griert. Über das Media-Independent-Interface können Steuer- und Konfigurationsdaten an den Baustein 36 übertragen und Statusinformationen von diesem gelesen werden. Die einzelnen Funktionen des Transmit-Function-Blocks 42 sind: Abbilden der zu sendenden Bytes, Erkennen von Kollisionen im Halbduplex­ betrieb und Ausführen eines Back-Off-Algorithmus, Zurverfü­ gungstellen von Transmit-Status-Informationen an die Ein­ richtung 40 nach Beenden eines Sendevorganges, Einhalten der Ruhezeit Inter-Packet-Gap (IPG) zwischen zwei Telegrammen, Ergänzen der Sendedaten um eine Präambel, einen Start-Off- Frame-Delimeter (SFD) und ein parametrierbares Cyclic-Redun­ dancy-Check-Wort (CRC), Auffüllen eines Telegramms mit Pad- Bytes, wenn die Telegrammlänge < 60 Byte wäre, und ein Abbrechen eines Sendevorgangs auf Anforderung.
Der Receive-Function-Block 43 stellt die empfangenen Bytes einer Einrichtung 44 zur Verfügung, die als Receive-Control bezeichnet wird. Der Receive-Function-Block 43 erkennt den Start-Of-Frame-Delimeter und eine VLAN-Frame. Er prüft das Längenfeld und das CRC-Wort in Telegrammen. Nach Beendigung des Empfangsvorgangs werden Receive-Status-Informationen der Einrichtung 44 zur Verfügung gestellt. Der Block 43 erkennt und entfernt bei Telegrammen Präambel und Start-Of-Frame- Delimeter. Unterschreitet der freie Speicherplatz in einem Receive-Buffer 45 des Ethernet-Kontrollers 28 im Vollduplex- Mode einen vorgegebenen Schwellwert, so sendet der MAC- Control-Block ein Pause-Steuer-Telegramm zur Flußkontrolle über den Baustein 36. Dieses Telegramm veranlaßt den ange­ schlossenen Netzwerkteilnehmer, so lange keine Datentele­ gramme an den Ethernet-Kontroller 28 zu senden, bis das mit dem Pause-Steuer-Telegramm gesendete Zeitintervall abgelaufen ist. Der Adreß-Filter führt eine Telegrammfilterung ent­ sprechend Unicast-, Multicast- und Broadcast-Adressen durch. Dazu wird die in einem Telegramm empfangene Zieladresse (DA) mit Filteradressen verglichen. Die Statistikzähler speichern statistische Informationen über Sende- und Empfangsopera­ tionen. Das Host-Interface erlaubt den Zugriff auf Parameter­ register und Statistikzähler des Ethernet-Kontrollers 28 durch den jeweils benachbarten Netzwerkteilnehmer.
Die Einrichtung 44 enthält ein Steuerwerk, das für den Empfang von Telegrammen verantwortlich ist. Sie bildet die Schnittstelle zwischen dem internen Takt des Ethernet- Kontrollers 28 und dem Empfangstakt.
Der Receive-Buffer 45 hat eine Größe von mehr als 3 Kilobyte. Er ist in einen Speicherbereich für hochpriore und in einen Speicherbereich für niederpriore Telegramme aufgeteilt. Das Verhältnis der beiden Speicherbereiche ist parametrierbar. Die Speicherbereiche sind jeweils als Ringpuffer realisiert.
Der DMA-Kontroller 33 steuert den DMA-Transfer von einem der Receive-Buffer in den Ethernet-Kontrollern 28 . . . 31 zum RAM 22. Der DMA-Transfer beginnt, wenn in einem der Receive-Buf­ fer, beispielsweise im Receive-Buffer 45, die Anzahl der emp­ fangenen Datenbytes einen parametrierbaren minimalen Füll­ stand erreicht hat oder ein Telegramm vollständig empfangen wurde. Gleichzeitig muß dieser Receive-Buffer von einem Modul 46, das als Switch-Control bezeichnet wird, für den DMA- Transfer selektiert sein.
Der Einrichtung 40 ist ein Multiplexer 47 vorgeschaltet, der durch eine Steuereinheit 46, die als Switch-Control bezeich­ net wird, angesteuert wird.
Switch-Control 46 steuert die Datenweiterleitung zwischen den Ethernet-Kontrollern 28 . . . 31 und das Abspeichern von emp­ fangenen Daten, wenn sie für den jeweiligen Netzwerkteil­ nehmer bestimmt sind. Da die Anwendung der Erfindung nicht auf Netzwerke nach der Ethernet-Spezifikation beschränkt ist, werden die Ethernet-Kontroller 28 . . . 31 im folgenden auch allgemein als Port 1, Port 2, Port 3 bzw. Port 4 bezeichnet. Welche Ports für die Weiterleitung von empfangenen Daten freigegeben sind, ist abhängig von der Netzstruktur, in welche der Teilnehmer eingebunden ist. Als Funktion des Betriebszustandes, der Netzstruktur, der empfangenen Ziel­ adresse und der Telegrammpriorität steuert Switch-Control 46 folgende Aktionen:
  • - Ist die empfangene Zieladresse gleich der eigenen Teil­ nehmeradresse, so wird das empfangene Telegramm über das Mikroprozessor-Interface 25 in das RAM 22 übertragen, ohne es an andere Ports weiterzuleiten.
  • - Wird an einem Port ein Broadcast-Telegramm empfangen, so wird das Telegramm in das RAM 22 übertragen und den anderen freigegebenen Ports zum Versenden zur Verfügung ge­ stellt.
  • - Wird an einem Port ein Telegramm mit einer Multicast-Ad­ resse empfangen, die mit einer der in einer Filtertabelle 48 gespeicherten Multicast-Adressen übereinstimmt, so wird das Telegramm in das RAM 22 übertragen und den anderen freigegebenen Ports zum Versenden zur Verfügung gestellt.
  • - Ist die empfangene Zieladresse verschieden von der eigenen Teilnehmeradresse und den Multicast-Adressen, so wird das Telegramm den anderen freigegebenen Ports zum Versenden zur Verfügung gestellt, ohne zur Weiterverarbeitung abge­ speichert zu werden.
  • - Bei Telegrammen mit sogenannten VLAN-Bytes stehen bei­ spielsweise acht Prioritätsebenen zur Verfügung. Stehen mehrere Telegramme gleichzeitig zum Versenden an, so wird die Sendereihenfolge der Telegramme entsprechend ihrer Übertragungspriorität festgelegt.
  • - In einem Betriebszustand Monitor-Mode werden alle Tele­ gramme, welche die parametrierten Filterbedingungen erfül­ len, in das RAM 22 übertragen.
  • - Die Telegrammweiterleitung unter Berücksichtigung eines modifizierten Spanning-Tree-Algorithmus.
Switch-Control 46 enthält noch weitere Parameter, deren Bedeutungen später noch genauer erläutert werden: Eine Reihenadresse RP3, die der an Port 3 angeschlossenen Reihe entspricht, eine Reihenadresse RP4, welche die Adresse der an Port 4 angeschlossenen Reihe wiedergibt, eine Anzahl NR1 der Übertragungsstrecken bis zum Port 1, eine Anzahl NR2 der Übertragungsstrecken bis zum Port 3, einen Wert |NR1 - NR2|S des jeweiligen Netzwerkteilnehmers, einen Wert |NR1 - NR2|Sender vom Sender eines empfangenen Port-Select-Telegramms, einen Betrag |NR1 - NR2|min als kleinster bisher empfangener Wert, eine Quelladresse ASender eines empfangenen Telegramms, eine Quelladresse AStored des Telegramms mit dem kleinsten Wert von Betrag |NR1 - NR2|min, eine beste empfangene Kombination (Root_ID.Cost.Transmitter_ID.Port_ID)P3 für Port 3, eine beste empfangene Kombination (Root_ID.Cost.Transmitter_ID.Port_ID)P4 für Port 4, eine beste empfangene Kombination (Root_ID.Cost.Transmitter_ID.Post_ID)R der Reihe, einen Melde-Intervall-Zähler für eine Zykluszeit von Port-Select-Telegrammen, einen Timeout-Zähler für ein Timeout-Intervall an Port 1, einen Timeout-Zähler für ein Timeout-Intervall an Port 2, einen Timeout-Zähler für ein Timeout-Intervall an Port 3, einen Aktiv-Time-Zähler für ein Zeitintervall, das mit dem letzten Empfang eines Port-Select- Telegramms an Port 4 beginnt, einen Kombinations-Alterungs­ zähler für ein maximales Zeitintervall, innerhalb dessen ein Konfigurationstelegramm empfangen werden muß, da sonst die gespeicherte Kombination Root_ID.Cost.Transmitter_IC.Port_ID gelöscht wird, einen Zähler für ein Zeitintervall Δtrowdelay, nach welchem ein Port 3 einer Reihe von inaktiv auf aktiv umschaltet, das der zweifachen Worst-Case-Durchlaufzeit eines Port-Select-Telegramms durch die Reihe entspricht, und einen Zähler für ein Zeitintervall Δtnetdelay, nach welchem ein Port von potentiell aktiv auf aktiv umgeschaltet wird und welches der zweifachen Worst-Case-Durchlaufzeit eines Konfi­ gurationstelegramms durch das Netzwerk entspricht.
In die Filtertabelle 48 können vom Anwender Multicast- und virtuelle LAN-Identifikationsadressen, sogenannte VLAN- Adressen, eingetragen werden. Ein Multicast- oder VLAN- Telegramm wird nur akzeptiert, wenn die empfangene Adresse mit einer der Adressen in der Filtertabelle 48 übereinstimmt.
Eine Einrichtung 50 zur Redundanzsteuerung soll in einem Netzwerk sicherstellen, daß erkannte physikalische Fehler die Kommunikation zwischen den Netzwerkkomponenten nicht beein­ trächtigen. Zum einen besteht innerhalb jeder mit Netzwerk­ teilnehmern gebildeten Reihe Redundanz. Dazu müssen die in Reihe geschalteten Netzwerkteilnehmer einen Ring bilden, der im störungsfreien Fall an einer Stelle geöffnet ist, im Fehlerfall jedoch geschlossen werden kann. Zum anderen ist Redundanz mit mehreren Kommunikationskanälen zwischen den Reihen möglich. Dazu muß eine Reihe von Netzwerkteilnehmern über mindestens zwei Ports mit einer benachbarten Reihe verbunden sein. Es ist immer nur ein Kommunikationskanal zwischen jeweils zwei Reihen aktiv, d. h. Datentelegramme werden nur über diesen Kommunikationspfad ausgetauscht. Ist ein aktiver Kommunikationskanal zwischen zwei Reihen als fehlerhaft erkannt, wird dieser deaktiviert und auf einen anderen Kommunikationskanal umgeschaltet. Zur Realisierung der Redundanz werden in der Einrichtung 50 ein Zykluszeitre­ gister mit einer parametrierten Zykluszeit für Testtelegram­ me, ein Zykluszeitzähler zur Erzeugung eines Zykluszeitinter­ valls, ein Steuerwerk für ein Umschalten auf einen redundan­ ten Kommunikationskanal und für ein Veranlassen eines Versen­ dens von sogenannten Link-Up oder Link-Down-Telegrammen, ein Reihenlaufzeitregister mit einer parametrierten Worst-Case- Durchlaufzeit eines Telegramms durch eine Reihe und ein Rei­ henlaufzeitzähler zur Erzeugung einer Reihenlaufzeit verwen­ det.
Über eine Einrichtung 51 zur Interrupt-Steuerung, die auch als Interrupt-Control bezeichnet wird, werden dem Mikropro­ zessor 23 bestimmte Ereignisse mitgeteilt. Dabei handelt es sich im wesentlichen um Meldungen von gesendeten oder empfan­ genen Telegrammen und um Fehlermeldungen. Die Einrichtung 51 enthält ein Interrupt-Request-Register, ein Interrupt-Mask- Register, ein Interrupt-Register sowie ein Interrupt- Acknowledge-Register. Im Interrupt-Request-Register wird jedes Ereignis abgespeichert. Über das Interrupt-Mask- Register können einzelne Ereignisse unterdrückt werden. Im Interrupt-Register erscheinen nur die Ereignisse, die vom Interrupt-Mask-Register nicht maskiert werden. Der Eintrag in das Interrupt-Request-Register ist dagegen unabhängig von der Interrupt-Maske im Interrupt-Mask-Register. Mit einem Schreibzugriff auf das Interrupt-Acknowledge-Register können Bits im Interrupt-Request-Register zurückgesetzt werden. Ein Modul 52 enthält spezielle Anwenderfunktionen, die in der Kommunikationsschnittstelle des Netzwerkteilnehmers zu integrieren sind. Eine Teilfunktion ist mit einem Modul 53 zur Uhrzeitsynchronisation, eine andere mit einem Modul 54 zur Äquidistanz realisiert, welche später näher erläutert werden. Für die Ports 1 bis 4 ist jeweils ein Delay-Timer 1 bis 4 mit dem Bezugszeichen 57, 58, 59 bzw. 60 vorgesehen, welcher die Übertragungszeit zwischen dem jeweiligen Netz­ werkteilnehmer und dem über den jeweiligen Port angeschlos­ senen Netzwerkteilnehmer ermittelt. Der jeweilige Delay-Timer wird auch als Durchlaufzeit-Timer (DLZ-Timer) für den jewei­ ligen Port genutzt. Weiterhin sind für jeden Port ein Äquidistanz-Timer, ein Hilfs-Timer für eine Übertragungszeit Δti über den jeweiligen Port und ein Parameter ΔtDLZ vorge­ sehen, welcher der Summe aus den Durchlaufzeiten in Sende- und Empfangsrichtung und der Leitungslaufzeit zwischen der Kommunikationsschnittstelle und dem über den jeweiligen Port angeschlossenen Netzwerkteilnehmer entspricht. Weiterhin befindet sich eine lokale Uhr 37 in dem Netzwerkteilnehmer, deren Uhrzeit über den Mikroprozessor-Bus 21 lesbar und einstellbar ist.
Ein integriertes Serial-Peripheral-Interface (SPI) 55 ist ein einfaches, aber leistungsfähiges serielles Bussystem zum Anschluß von Peripherie-Bausteinen, z. B. EEPROMs. Ein inte­ griertes E/A-Interface 56 ist eine parallele Schnittstelle mit 12 parametrierbaren Ein- und Ausgängen. Über diese Schnittstelle können beispielsweise LEDs zur Zustandsanzeige angesteuert werden.
Jeder Port der Kommunikationsschnittstelle kann parametrier­ bar im Halbduplex- oder im Vollduplex-Mode betrieben werden. Während an einem Port der Halbduplex-Mode eingestellt ist, kann gleichzeitig an einem anderen Port der Vollduplex-Mode parametriert sein. Im Vollduplex-Mode können gleichzeitig Telegramme gesendet und empfangen werden. Im Halbduplex-Mode ist dies nicht möglich.
Ein applikationsspezifisches Anwendungsprogramm, das bei­ spielsweise auf dem RAM 22 hinterlegt sein kann, trägt zu versendende Daten in eine Auftragsliste im RAM 22 ein. Der DMA-Kontroller 26 kopiert Daten aus dieser Auftragsliste in den Transmit-Buffer 27. Zusammengestellte Telegramme werden an die freigegebenen Ethernet-Kontroller 28 . . . 31 weiter­ gegeben. Tritt ein Sendekonflikt auf, weil durch Switch- Control 46 gesteuert gerade andere Telegramme durch das Kommunikations-Interface weitergeleitet werden, so sollte der Transmit-Buffer 27 zwei komplette Ethernet-Telegramme speichern können. Mit dem Senden der Daten aus dem Transmit- Buffer 27 wird begonnen, wenn eine zu parametrierende Anzahl Datenbytes oder ein komplettes Telegramm vom RAM 22 in den Transmit-Buffer 27 übertragen wurde und mindestens ein Ethernet-Kontroller frei ist. Das Telegramm bleibt so lange im Transmit-Buffer 27 gespeichert, bis es über alle frei­ gegebenen Ethernet-Kontroller 28 . . . 31 gesendet wurde. Die Anzahl der Datenbytes eines Telegramms, die mindestens im Transmit-Buffer 27 gespeichert sein müssen, bevor gesendet wird, ist so zu parametrieren, daß ein lückenloses Senden des Telegramms gewährleistet ist. Andernfalls wird das Telegramm von anderen Netzwerkteilnehmern fehlerhaft empfangen. Sind im Transmit-Buffer Telegramme unterschiedlicher Priorität ge­ speichert, so werden die Telegramme entsprechend ihrer Über­ tragungspriorität gesendet.
Fig. 3 zeigt ein Beispiel einer Verschaltung von drei Netzwerkteilnehmern 61, 62 und 63 in linienförmiger Struktur. Zur besseren Übersichtlichkeit der Darstellung sind die Ports 1 bis 4 der Kommunikationsschnittstelle der Netzwerkteil­ nehmer 61, 62 und 63 in Schaltungsteile T1 bis T4 für Sende­ richtung und Schaltungsteile R1 bis R4 für Empfangsrichtung untergliedert. Somit kann beispielsweise Port 2 auch kurz als Port T2/R2 bezeichnet werden. Für eine linienförmige Struktur werden in der dargestellten Weise Port T2/R2 des Netzwerk­ teilnehmers 61 mit Port T1/R1 des Netzwerkteilnehmers 62 und Port T2/R2 des Netzwerkteilnehmers 62 mit Port T1/R1 des Netzwerkteilnehmers 63 verbunden. Die Datenübertragung er­ folgt jeweils mit einem Twisted-Pair-Kabel für jede Übertragungsrichtung. Die beteiligten Ports können somit im Vollduplex-Mode betrieben werden. An die in Fig. 3 offenen Ports T3/R3 und T4/R4 sowie an den Port T1/R1 des Netzwerk­ teilnehmers 61 oder den Port T2/R2 des Netzwerkteilnehmers 63 können wahlweise Endgeräte angeschlossen und somit an das Netzwerk angekoppelt werden.
Fig. 4 zeigt eine Reihe von Netzwerkteilnehmern 70, 71, 72 und 73, die jeweils über zwei Kommunikationskanäle miteinan­ der Daten austauschen können. Die Kommunikationskanäle werden jeweils durch eine Verbindung des Ports T2/R2 mit dem Port T1/R1 des benachbarten Netzwerkteilnehmers sowie des Ports T4/R4 mit dem Port T3/R3 des benachbarten Netzwerkteilnehmers in der dargestellten Weise realisiert. Damit kann beispiels­ weise ein hochpriorer und ein niederpriorer Kommunikations­ kanal aufgebaut und der Datendurchsatz verdoppelt werden. Ein Datenaustausch zwischen den Kommunikationskanälen findet nicht statt, d. h. ein am Schaltungsteil R1 empfangenes Tele­ gramm kann - falls erforderlich - nur vom Schaltungsteil T2 weitergesendet werden. Beide Kommunikationskanäle werden im Vollduplex-Mode betrieben.
Ein Beispiel für eine zweidimensionale Verschaltung der Netzwerkteilnehmer zeigt Fig. 5. Netzwerkteilnehmer 80, 81 und 82 sind in der bereits anhand Fig. 3 beschriebenen Weise zu einer Reihe verschaltet. Weiterhin bilden Netzwerkteilneh­ mer 83, 84 und 85 eine Reihe sowie Netzwerkteilnehmer 86, 87 und 88 bilden eine Reihe. An den Ports T4/R4 der Netzwerk­ teilnehmer 80, 81 und 84 sind jeweils Endgeräte 89, 90 bzw. 91 angeschlossen, an den Ports T3/R3 der Netzwerkteilnehmer 83, 84 und 87 befinden sich Endgeräte 92, 93 bzw. 94. Durch Verbinden des Ports T4/R4 des Netzwerkteilnehmers 82 mit dem Port T3/R3 des Netzwerkteilnehmers 85 ist ein Kommunikations­ kanal zwischen den jeweiligen Reihen realisiert. In ent­ sprechender Weise sind zwei Kommunikationskanäle zwischen den Netzwerkteilnehmern 83 und 86 sowie zwischen den Netzwerk­ teilnehmern 85 und 88 gebildet. Damit Schleifenfreiheit im Netzwerk besteht, darf von diesen jedoch immer nur ein Kommu­ nikationskanal zu einem Zeitpunkt aktiv geschaltet sein.
Den aus den Teilnehmern 80 bis 82, 83 bis 85 und 86 bis 88 gebildeten Reihen ist jeweils eine eindeutige Reihenadresse Rk zugewiesen, die in einem Parameterregister "Reihenadresse" hinterlegt ist.
Zur Verdeutlichung der Redundanzsteuerung ist in Fig. 6 ein weiteres zweidimensionales Netzwerk dargestellt. Jeweils 8 Netzwerkteilnehmer 100 . . . 107, 110 . . . 117, 120 . . . 127 und 130 . . . 137 sind in einer Reihe verschaltet. Sowohl die mit durchbrochenen Linien als auch die mit durchgezogenen Linien eingezeichneten Verbindungen zwischen den Netzwerkteilnehmern stellen Kommunikationskanäle dar. Es muß jedoch sicherge­ stellt sein, daß zwischen zwei beliebigen Netzwerkteilnehmern im gesamten Netzwerk nur ein einziger Kommunikationspfad benutzt wird. Bei mehreren möglichen Kommunikationspfaden würden Schleifen auftreten, d. h. Telegramme würden sich ver­ vielfachen und zirkulieren. Um solche Situationen zu vermei­ den, ist der Spanning-Tree-Algorithmus entwickelt worden. Datentelegramme werden nur von Ports empfangen, zu Ports weitergeleitet und von Ports gesendet, die im Spanning-Tree enthalten sind. Die restlichen Ports sind deaktiviert. Deak­ tivierte Kommunikationskanäle sind in Fig. 6 mit durch­ brochenen Linien dargestellt, aktivierte mit durchgezogenen Linien. Für eine Redundanz innerhalb einer Reihe werden die beiden Linienenden, beispielsweise an den Netzwerkteilnehmern 100 und 107, miteinander verbunden. Im fehlerfreien Fall wird der auf diese Weise geschaffene Kommunikationskanal deaktiviert, im Fehlerfall in den aktiven Zustand versetzt. Diese Redundanz setzt eine nicht unterbrochene Linienstruktur voraus. Da der Spanning-Tree-Algorithmus gegebenenfalls auch eine Verbindung über die Ports T1/R1 und T2/R2 unterbrechen würde, kann er nicht unverändert angewendet werden. Im fol­ genden wird ein Verfahren vorgestellt, das für ein Netzwerk aus zusammengeschalteten Reihen von Netzwerkteilnehmern Schleifenfreiheit sicherstellt, ohne eine Reihe unterbrechen zu müssen. Dazu werden - falls erforderlich - nur die Ports T3/R3 deaktiviert. Es darf immer nur ein Kommunikationskanal zwischen jeweils zwei Reihen aktiv sein, d. h., Datentelegram­ me werden über diesen Kommunikationspfad ausgetauscht. Über die anderen Kommunikationspfade zwischen zwei Reihen erfolgt kein Datenaustausch. Die Auswahl des einzigen aktiven Kommu­ nikationskanals zwischen jeweils zwei Reihen erfolgt mit Hilfe von Port-Select-Telegrammen. Dabei handelt es sich um Telegramme, die nur innerhalb einer Reihe weitergeleitet werden. Ein Austausch zwischen den Reihen findet nicht statt.
Aufgabe dieser Port-Select-Telegramme ist es, einen Netz­ werkteilnehmer zu finden, der über den Port T3/R3 mit einer benachbarten Reihe verbunden ist und bezogen auf die Anzahl der Netzwerkteilnehmer von beiden Enden der Linienstruktur möglichst gleich weit entfernt ist, d. h. den kleinsten Abstand von der Reihenmitte hat. Diese Eigenschaften defi­ nieren den einzigen Netzwerkteilnehmer der Reihe, der über Port T3/R3 aktiv mit einer benachbarten Reihe verbunden ist. Alle weiteren Verbindungen über Ports T3/R3 von Netzwerkteil­ nehmern derselben Reihe zu dieser benachbarten sind deakti­ viert. Über deaktivierte Kommunikationskanäle werden keine Datentelegramme ausgetauscht.
Port-Select-Telegramme werden durch eine Kennung im Type-Feld eindeutig gekennzeichnet.
Fig. 7 zeigt das Ergebnis der Redundanzsteuerung bei einem zweidimensionalen Netzwerk in einer anderen Darstellungsart. Die in den einzelnen Kästen eingetragene Zahl entspricht der jeweiligen Adresse des Netzwerkteilnehmers. Der Port T1/R1 befindet sich an der linken Seite, der Port T2/R2 an der rechten Seite, der Port T3/R3 an der oberen Seite und der Port T4/R4 an der unteren Seite der Netzwerkteilnehmer. Durch zwei durchgezogene parallele Linien zwischen zwei Teilnehmern ist jeweils ein aktiver, im Vollduplex-Mode betriebener Kommunikationskanal eingezeichnet. Die mit zwei durchbroche­ nen Linien eingezeichneten Kommunikationskanäle sind deaktiviert.
Der Datenbereich von Port-Select-Telegrammen, die über Port T2/R2 von einem Netzwerkteilnehmer empfangen werden, enthält Informationen über die Anzahl NR2 der Übertragungsstrecken zwischen Port T1/R1 des Netzwerkteilnehmers am "rechten" Rand der Reihe und dem Port T2/R2 des jeweiligen Netzwerkteilneh­ mers und enthält die Anzahl NR1 des Teilnehmers, der das empfangene Port-Select-Telegramm als letzter weitergeleitet bzw. gesendet hat.
Der Datenbereich von Port-Select-Telegrammen, die über Port T1/R1 empfangen werden, enthält die Anzahl NR1 der Übertra­ gungsstrecken zwischen dem Port T2/R2 des Netzwerkteilnehmers am "linken" Rand der Reihe und dem Port T1/R1 des jeweiligen Netzwerkteilnehmers sowie die Anzahl NR2, die für den Netz­ werkteilnehmer gültig ist, der das empfangene Port-Select- Telegramm als letzter weitergeleitet oder gesendet hat.
Unabhängig davon, über welchen Port ein Port-Select-Telegramm empfangen wurde, enthält es den Wert |NR1 - NR2|Initiator beim Initiator des empfangenen Port-Select-Telegramms, die 16-Bit- Adresse Rk (0 ≦ k ≦ p, p Anzahl der Reihen) der Reihe, welcher der Initiator des Port-Select-Telegramms angehört, und ein Valid-Bit V für den empfangenen Wert von |NR1 - NR2|Initiator und für die Reihenadresse Rk. V = 0 bedeutet, daß die empfangenen Werte ungültig sind. Ein derartiges Port- Select-Telegramm wurde von einem Netzwerkteilnehmer in die Reihe eingespeist, der nicht über einen betriebsbereiten Port T3/R3 mit seiner benachbarten Reihe verbunden ist. Bei V = 1 sind die empfangenen Werte gültig. Das Port-Select- Telegramm wurde von einem Netzwerkteilnehmer in die Reihe eingespeist, der über einen betriebsbereiten Port T3/R3 mit einer benachbarten Reihe verbunden ist. Eine Verbindung zur benachbarten Reihe ist betriebsbereit, wenn innerhalb eines parametrierbaren Zeitintervalles Δttimeout (Timeout-Intervall) ein Port-Select-Telegramm an Port P3/R3 empfangen wird. Dies ist nur möglich, wenn der Port T3/R3 des Netzwerkteilnehmers der eigenen Reihe und der Port T4/R4 des Netzwerkteilnehmers der benachbarten Reihe jeweils in einem Zustand "link-pass" ist. In diesem Zustand können Telegramme in beiden Richtungen übertragen werden.
Im eingeschwungenen Zustand sendet in jeder Reihe nur noch der Netzwerkteilnehmer zyklisch, d. h. in jedem Meldeintervall ΔtM, Port-Select-Telegramme, der als einziger über Port T3/R3 aktiv mit der nächsten Reihe verbunden ist. Damit läßt sich erkennen, ob diese Verbindung zweier Reihen noch aktiv ist. Im folgenden wird ein Verfahren beschrieben, nach welchem dieser Netzwerkteilnehmer bestimmt werden kann:
  • 1. Netzwerkteilnehmer senden weiterzuleitende oder selbst zusammengestellte Port-Select-Telegramme zusätzlich über ihren Port T3/R3.
  • 2. Am Empfang eines Port-Select-Telegramms über den Port T3/R3 erkennt jeder Netzwerkteilnehmer, ob er über diesen Port mit einer anderen Reihe verbunden ist.
    Netzwerkteilnehmer setzen das Valid-Bit V auf eins, wenn über den Port T3/R3 ein Port-Select-Telegramm empfangen wurde.
  • 3. Am Port T3/R3 empfangene Port-Select-Telegramme werden unverändert dem Sender zurückgeschickt. Der Netzwerkteil­ nehmer speichert zuvor die mit dem Port-Select-Telegramm empfangene Adresse Rn der über Port T3/R3 angeschlossenen Reihe.
  • 4. Dem Port T3/R3 ist ein Timeout-Zähler zugeordnet, der mit einem einstellbaren Takt inkrementiert wird. Jedes an Port T3/R3 empfangene Port-Select-Telegramm setzt diesen Zähler zurück. Der Netzwerkteilnehmer setzt das Valid-Bit V auf Null, wenn innerhalb eines parametrierbaren Time­ out-Intervalls Δttimeout kein Port-Select-Telegramm empfan­ gen wird.
  • 5. Netzwerkteilnehmer senden weiterzuleitende oder selbst zusammengestellte Port-Select-Telegramme zusätzlich über Port T4/R4.
  • 6. Am Empfang eines Port-Select-Telegramms über Port T4/R4 erkennt ein Netzwerkteilnehmer, daß er über diesen Port mit einer anderen Reihe verbunden ist.
  • 7. Am Port T4/R4 empfangene Port-Select-Telegramme werden unverändert dem Sender zurückgeschickt. Der Netzwerk­ teilnehmer speichert zuvor die mit dem Port-Select-Tele­ gramm empfangene Adresse Rn der über Port T4/R4 ange­ schlossenen Reihe.
  • 8. Netzwerkteilnehmer versenden eigene, d. h. selbst zusammengestellte, Port-Select-Telegramme
    • 1. 8.1 über Port T1/R1 mit NR2 = 1 und Port T2/R2 mit NR1 = 1 bei der Initialisierung mit Betrag |NR1 - NR2|Initiator = FFH und Valid-Bit V = 1, wenn bereits ein Port- Select-Telegramm über Port T3/R3 empfangen wurde, oder Valid-Bit V = 0, wenn kein Port-Select-Tele­ gramm über Part T3/R3 empfangen wurde;
    • 2. 8.2 über T1/R1 mit NR2 = 1 und Port T2/R2 mit (NR1 + 1), wenn innerhalb eines parametrierbaren Zeitintervalls Δttimeout an Port T2/R2 kein Port-Select-Telegramm oder Datentelegramm empfangen wurde. Dem Port T2/R2 ist ein Timeout-Zähler zugeordnet, der mit einem ein­ stellbaren Takt inkrementiert wird. Jedes an Port T2/R2 empfangene Port-Select-Telegramm oder Datente­ legramm setzt diesen Zähler zurück;
    • 3. 8.3 über Port T1/R1 mit (NR2empf + 1) und Port T2/R2 mit (NR1 + 1), wenn an Port T2/R2 ein Port-Select-Tele­ gramm empfangen wird mit dem empfangenen Wert NR2empf ungleich dem gespeicherten Wert von NR2. Zusätzlich wird NR2empf abgespeichert.
    • 4. 8.4 über Part T2/R2 mit (NR1 + 1), wenn an Port T2/R2 ein Port-Select-Telegramm empfangen wird mit NR1LastSender ungleich (NR1 + 1).
    • 5. 8.5 über Port T2/R2 mit NR1 = 1 und Port T1/R1 mit (NR2 + 1), wenn innerhalb eines parametrierbaren Zeitintervalls Δttimeout an Port T1/R1 kein Port-Select-Telegramm oder Daten-Telegramm empfangen wurde. Dem Port T1/R1 ist ein Timeout-Zähler zugeordnet, der mit einem ein­ stellbaren Takt inkrementiert wird. Jedes an Port T1/R1 empfangene Port-Select- oder Daten-Telegramm setzt diesen Zähler zurück.
    • 6. 8.6 über Port T2/R2 mit (NR1empf + 1) und Port T1/R1 mit (NR2 + 1), wenn an Port T1/R1 ein Port-Select-Telegramm empfangen wird mit einem empfangenen Wert NRlempf ungleich dem gespeicherten Wert von NR1. Zusätzlich wird NR1empf abgespeichert.
    • 7. 8.7 über Port T1/R1 mit (NR2 + 1), wenn an Port T1/R1 ein Port-Select-Telegramm empfangen wird mit NR2lastSender ungleich (NR2 + 1).
  • 9. Netzwerkteilnehmer, die über einen betriebsbereiten Kommunikationskanal über Port T3/R3 an eine andere Reihe angeschlossen sind und ein Port-Select-Telegramm mit einem auf eins gesetzten Valid-Bit V empfangen, ver­ gleichen |NR1 - NR2|Initiator vom empfangenen Port-Select-Tele­ gramm mit Betrag |NR1 - NR2|s der eigenen Station:
    • 1. 9.1 Ist |NR1 - NR2|Initiator < |NR1 - NR2|s, so wird |NR1 - NR2|Initiator im Datenfeld des Port-Select-Tele­ gramms bei der Weiterleitung nicht geändert. Der Netzwerkteilnehmer speichert |NR1 - NR2|min = |NR1 - NR2|Initiator und setzt die Adresse AStored = AInitiator. AInitiator ist die Quelladresse des empfangenen Port-Select-Telegramms. Der Wert |NR1 - NR2|s ist der Abstand der empfangenden Station von der Reihenmitte.
    • 2. 9.2 Ist |NR1 - NR2|Initiator = |NR1 - NR2|s, so wird AInitiator mit der eigenen Stationsadresse As verglichen:
      Bei AInitiator < As wird das Port-Select-Telegramm ohne Änderung im Datenfeld mit |NR1 - NR2|Initiator weiterge­ leitet. Der Netzwerkteilnehmer speichert |NR1 - NR2|min = |NR1 - NR2|s und Astored = AInitiator.
      Ist AInitiator = As, so wird das empfangene Port-Select- Telegramm herausgefiltert, da dieser Fall nur bei einem Fehler möglich ist.
      Ist AInitiator < As, so wird das empfangene Port-Select- Telegramm herausgefiltert und ein eigenes Port- Select-Telegramm mit |NR1 - NR2|Initiator gesetzt auf |NR1 - NR2|s über die Ports T1/R1 und T2/R2 gesendet. Der Netzwerkteilnehmer speichert |NR1 - NR2|min = |NR1 - NR2|s, und Astored = As.
    • 3. 9.3 Ist |NR1 - NR2|Initiator < |NR1 - NR2|s, so wird das empfangene Port-Select-Telegramm gefiltert und ein eigenes Port-Select-Telegramm mit |NR1 - NR2|Initiator gesetzt auf |NR1 - NR2|s über die Ports T1/R1 und T2/R2 gesendet. Der Netzwerkteilnehmer speichert |NR1 - NR2|min = |NR1 - NR2|s und Astored = As.
  • 10. Netzwerkteilnehmer, die nicht oder über einen nicht betriebsbereiten Kommunikationskanal über Port T3/R3 an eine andere Reihe angeschlossen sind und ein Port-Select- Telegramm mit einem Valid-Bit V = 1 empfangen, leiten das Telegramm mit dem empfangenen Valid-Bit V und dem Wert |NR1 - NR2|Initiator innerhalb der Reihe weiter. Der Netz­ werkteilnehmer speichert |NR1 - NR2|min = |NR1 - NR2|Initiator und Astored = AInitiator.
  • 11. Netzwerkteilnehmer, die ein Port-Select-Telegramm mit einem Valid-Bit V = 0 empfangen, leiten das Telegramm mit V = 0 und dem Wert |NR1 - NR2|Initiator innerhalb der Reihe weiter. Die gespeicherten Werte von |NR1 - NR2|min und Astored bleiben unverändert.
  • 12. Ein betriebsbereiter Port T3/R3 wird aktiv geschaltet, wenn |NR1 - NR2|min = |NR1 - NR2|s und Astored = As gespeichert ist. Dies gilt für einen Zeitraum Δtrowdelay, der mindestens der zweifachen Worst-Case-Durchlaufzeit eines Port-Se­ lect-Telegramms durch eine Reihe entspricht.
  • 13. Ein aktiver Port T3/R3 eines Netzwerkteilnehmers wird deaktiviert, wenn der Netzwerkteilnehmer innerhalb des Timeout-Intervalls Δttimeout kein Port-Select-Telegramm von einer anderen Reihe empfängt. Zusätzlich wird der Kommu­ nikationskanal über den Port T3/R3 zur anderen Reihe als nicht betriebsbereit gekennzeichnet.
    Ein aktiver Port T3/R3 wird ebenfalls deaktiviert, wenn der Netzwerkteilnehmer ein Port-Select-Telegramm empfängt mit |NR1 - NR2|Initiator < |NR1 - NR2|s oder |NR1 - NR2|Initiator = |NR1 - NR2|s und AInitiator < As. Dieser Netzwerkteilnehmer speichert die empfangenen Werte |NR1 - NR2|Initiator und AInitiator und leitet das empfangene Telegramm weiter. Der Kommunikationskanal über den Port T3/R3 zur anderen Reihe bleibt betriebsbereit.
  • 14. Netzwerkteilnehmer, die über einen betriebsbereiten Kommunikationskanal über Port T3/R3 an eine andere Reihe angeschlossen sind, senden zyklisch in jedem Meldeinter­ vall ΔtM eigene Port-Select-Telegramme.
    • 1. 14.1 über den Port T1/R1 mit (NR2 + 1) und den Port T2/R2 (NR1 + 1), wenn ein aktiver Port T3/R3 deaktiviert wird, mit |NR1 - NR2|Initiator = FFH ist und Valid-Bit V = 1, bis ein Port-Select-Telegramm eines anderen Netzwerkteilnehmers empfangen wird;
    • 2. 14.2 über den Port T1/R1 mit (NR2 + 1) und den Port T2/R2 mit (NR1 + 1), wenn innerhalb eines parametrierbaren Zeitintervalls Δttimeout weder an Port T1/R1 noch an Port T2/R2 ein Port-Select-Telegramm oder Daten­ telegramm von dem Netzwerkteilnehmer mit dem einzi­ gen aktiven Kommunikationskanal zur benachbarten Reihe empfangen wurde, d. h. ein Telegramm mit der Quelladresse Astored;
    • 3. 14.3 über den Port T1/R1 mit (NR2 + 1) und den Port T2/R2 mit (NR1 + 1), wenn |NR1 - NR2|min = |NR1 - NR2|s und Astored = As gespeichert ist.
Im eingeschwungenen Zustand des Verfahrens kennt jeder Netz­ werkteilnehmer der Reihe den Netzwerkteilnehmer, der über seinen Port T3/R3 mit einer benachbarten Reihe verbunden ist und den kleinsten Abstand von der Reihenmitte hat. Nur über diesen aktiven Kommunikationskanal werden Datentelegramme zwischen den beiden Reihen ausgetauscht. Die Verbindungen der anderen Netzwerkteilnehmer zur nächsten Reihe sind deakti­ viert. Fig. 7 zeigt ein Netzwerk in diesem eingeschwungenen Zustand.
Soll abweichend von diesem Ausführungsbeispiel der einzige aktive Kommunikationskanal einer Reihe zur benachbarten Reihe am Rand der Reihe liegen, so sind im beschriebenen Verfahren |NR1 - NR2|min durch |NR1 - NR2|max |NR1 - NR2|Initiator < |NR1 - NR2|s durch |NR1 - NR2|Initiator < |NR1 - NR2|s zu ersetzen.
Fig. 8 zeigt ein Netzwerk in dreidimensionaler Struktur. Dabei ist die Anordnung der Ports an den einzelnen Kästen, welche jeweils einen Netzwerkteilnehmer mit der eingetragenen Adresse repräsentieren, dieselbe wie in der Darstellung nach Fig. 7. Auch die Kommunikationskanäle sind in gleicher Weise dargestellt. Bei einer dreidimensionalen Struktur wird jeweils mit mehreren Netzwerkteilnehmern durch Verbindung der Ports T1/R1 und T2/R2 eine Reihe in linienförmiger Struktur aufgebaut. Mehrere dieser Reihen werden zu einer dreidimen­ sionalen Struktur zusammengeschaltet, wie es in Fig. 8 dar­ gestellt ist. Dazu muß zwischen jeweils zwei Reihen min­ destens ein Kommunikationskanal über Port T3/R3 und T4/R4 vorhanden sein. Mehrere Kommunikationspfade zwischen jeweils zwei Reihen sind zulässig. An den Ports T3/R3 und T4/R4 der Netzwerkteilnehmer, die nicht für Kommunikationskanäle zwischen Reihen verwendet werden, können Endgeräte ange­ schlossen werden. Jeder Reihe ist eine eindeutige Reihen­ adresse Rk mit 0 ≦ k ≦ p zugewiesen, wobei p die Anzahl der Reihen der gewählten Netzstruktur ist. Die jeweiligen Reihen­ adressen sind an der linken Seite von Fig. 8 neben der jeweiligen Reihe angegeben. In jedem Netzwerkteilnehmer ist im Parameterregister "Reihenadresse" die zugehörige Adresse der Reihe abgespeichert.
Es muß jedoch sichergestellt sein, daß zwischen zwei beliebi­ gen Netzwerkteilnehmern im gesamten Netzwerk nur ein einziger Kommunikationspfad benutzt wird. Bei mehreren Kommunika­ tionspfaden würden Schleifen auftreten, d. h. Telegramme könnten sich vervielfachen und zirkulieren. Zur Vermeidung von Schleifen werden Port-Select-Telegramme in Kombination mit einem modifizierten Spanning-Tree-Algorithmus verwendet.
Dazu wird der Datenbereich der Port-Select-Telegramme um die Adresse Rn der benachbarten Reihe erweitert, an welche der Port T3/R3 oder der Port T4/R4 des Netzwerkteilnehmers, der das Telegramm zusammengestellt hat, angeschlossen ist.
Aufgabe der um die Reihenadresse Rn der benachbarten Reihe erweiterten Port-Select-Telegramme ist, einen Netzwerkteil­ nehmer zu finden, der über Port T3/R3 mit einer Reihe mit der Adresse Rn verbunden ist und bezogen auf die Anzahl der Netzwerkteilnehmer von beiden Enden seiner Reihe möglichst gleich weit entfernt ist, d. h. den kleinsten Abstand von der Reihenmitte hat. Dies definiert den einzigen Netzwerkteil­ nehmer der Reihe, der über Port T3/R3 potentiell aktiv mit der benachbarten Reihe mit der Adresse Rn verbunden ist. Der Port T3/R3 wird von potentiell aktiv auf aktiv umgeschaltet, wenn auch der modifizierte Spanning-Tree-Algorithmus diesen Port aktiv schaltet. Nur über aktive Kommunikationskanäle zwischen den Reihen werden Datentelegramme ausgetauscht. Mit dem zuvor schon für die zweidimensionale Netzwerkstruktur beschriebenen Verfahren läßt sich der Netzwerkteilnehmer finden, der den kleinsten Abstand zur Reihenmitte hat und dessen Port T3/R3 an die Reihe mit der Adresse RN angeschlos­ sen ist. Die Port-Select-Telegramme stellen sicher, daß zwischen zwei über Kommunikationskanäle direkt miteinander verbundenen Reihen zu jeder Zeit immer nur ein Kommunika­ tionskanal über Port T3/R3 potentiell aktiv ist. Damit auch Schleifen, welche über mehr als zwei Reihen geschlossen werden, zuverlässig verhindert werden, stellt ein modifi­ ziertes Spanning-Tree-Verfahren sicher, daß über das gesamte dreidimensionale Netzwerk keine Schleife auftritt. Kennzeichen des modifizierten Spanning-Tree-Verfahrens sind, daß jede Reihe als virtueller Switch, mit den potentiell aktiven Kommunikationskanälen über Ports T3/R3 oder über Ports T4/R4 zu anderen Reihen als Ports des virtuellen Switches angesehen wird und daß ein Kommunikationskanal über einen Port T4/R4 potentiell aktiv ist, wenn er an einen potentiell aktiven Port T3/R3 einer anderen Reihe, die ebenfalls als virtueller Switch angesehen wird, angeschlossen ist. Weiterhin werden in Konfigurationstelegrammen die folgenden Einträge im Datenfeld vorgesehen:
  • 1. Root_ID: Eine 64-Bit-Adresse RR des virtuellen Switches, der als "Root" angenommen wird.
  • 2. Transmitter_ID: Eine 64-Bit-Adresse RT des virtuellen Switches, zu dem der sendende Netzwerkteilnehmer gehört. Die Adressen RR und RT entsprechen jeweils der Adresse der Reihe, die als virtueller Switch angesehen wird.
  • 3. Cost: Kleinste Reihenanzahl, die ein Telegramm von einem Sender zur Root_ID durchlaufen muß.
  • 4. Port_ID: Eine 16-Bit-Adresse PID des Ports, über den der sendende virtuelle Switch das Konfigurationstelegramm sendet. RPID ist gleich der Adresse Rn der Reihe, die an dem Port angeschlossen ist, über den der virtuelle Switch mit der Transmitter_ID sendet.
Mit diesen Definitionen kann der Spanning-Tree-Algorithmus auf ein Netzwerk aus virtuellen Switches angewendet werden. Er basiert auf den beschriebenen Konfigurationstelegrammen, die von virtuellen Switches gesendet und empfangen werden.
Nur die potentiell aktiven oder aktiven Ports T3/R3 oder T4/R4 einer Reihe, d. h. eines virtuellen Switches, werten empfangene Konfigurationstelegramme aus. Die deaktivierten Ports T3/R3 oder T4/R4 werten die Konfigurationstelegramme aus und filtern sie anschließend. Das Spanning-Tree-Verfahren schaltet die Ports T3/R3 oder T4/R4 von potentiell aktiv auf aktiv um, die sicherstellen, daß zwischen jeweils zwei beliebigen Netzwerkteilnehmern des Netzwerks nur ein einziger Kommunikationspfad existiert und somit keine Schleifen auftreten. Die restlichen Ports T3/R3 oder T4/R4 bleiben potentiell aktiv oder deaktiviert. Nur über aktive Kommunika­ tionskanäle zwischen den Reihen werden Datentelegramme ausge­ tauscht.
Ein virtueller Switch ist an seinen Ports ständig für Konfigurationstelegramme empfangsbereit und speichert für jeden Port die Konfigurationsnachricht mit der "besten" Kombination aus Root_ID.Cost.Transmitter_ID.Port_ID. Verglichen werden für jeden Port nicht nur die empfangenen Kombinationen, sondern es wird auch verglichen mit der Kombination, welche der virtuelle Switch an diesen Port versenden würde. Eine Kombination K1 ist "besser" als eine andere Kombination K2, wenn
  • 1. Root_ID von K1 < Root_ID von K2,
  • 2. Root_ID von K1 = Root_ID von K2 und
    Cost von K1 < Cost von K2,
  • 3. Root_ID von K1 = Root_ID von K2 und
    Cost von K1 = Cost von K2 und
    Transmitter_ID von K1 < Transmitter_ID von K2 oder
  • 4. Root_ID von K1 = Root_ID von K2 und
    Cost von K1 = Cost von K2 und
    Transmitter_ID von K1 = Transmitter_ID von K2 und
    Port_ID von K1 < Port_ID von K2.
Der Root-Port eines virtuellen Switches ist der Port mit der "besten" empfangenen Kombination KR = KE = Root_ID.Cost.Transmitter_ID.Port_ID.
Der Root-Port ist der Port eines virtuellen Switches mit dem kürzesten Abstand zur Root_ID.
Die Kombination des Root-Ports wird über Port-Select-Tele­ gramme allen Netzwerkteilnehmern des virtuellen Switches mitgeteilt. Damit besitzt jeder Netzwerkteilnehmer die notwendigen Informationen, um zu entscheiden, ob ein Port von potentiell aktiv auf aktiv umzuschalten ist. Ein potentiell aktiver Port wird auf aktiv geschaltet, wenn Root_ID.(Cost+1).Transmitter_ID.Port_ID vom Root-Port "besser" ist als Root_ID.Cost.Transmitter_ID.Port_ID vom betrachteten Port.
Die Bedingung, die zur Aktivierung eines Ports eines virtuellen Switches führt, muß für einen Zeitraum Δtnetdelay gültig sein, der mindestens der zweifachen Worst-Case- Durchlaufzeit eines Konfigurationstelegramms durch das Netzwerk entspricht, bevor der betreffende Port tatsächlich aktiviert wird. Nur Konfigurationstelegramme, die vom Root- Port empfangen wurden, werden an die aktiven Ports des virtuellen Switches weitergeleitet. Konfigurationstelegramme werden nur über die aktiven Ports T3/R3 gesendet oder weiter­ geleitet. Die einzigen Empfänger dieser Telegramme sind somit die potentiell aktiven Ports T4/R4 der angeschlossenen vir­ tuellen Switches. Zudem werden Konfigurationstelegramme nur über die aktiven Ports T4/R4 gesendet oder weitergeleitet. Die einzigen Empfänger derartiger Telegramme sind somit die potentiell aktiven Ports T3/R3 der angeschlossenen virtuellen Switches. Jedem Port eines virtuellen Switches ist ein soge­ nannter Kombinations-Alterungszähler zugeordnet. Dieser Zähler wird mit jedem empfangenen oder weitergeleiteten Kon­ figurationstelegramm zurückgesetzt und neu gestartet. Der Kombinations-Alterungszähler ist somit nur bei den potentiell aktiven oder aktiven Ports einer Reihe aktiviert und wird mit einem parametrierbaren Zeittakt inkrementiert. Erreicht der Kombinations-Alterungszähler bei einem potentiell aktiven bzw. einem aktiven Port den parametrierbaren Schwellwert "maximales Alter", so wird die für diesen Port gespeicherte Kombination Root_ID.Cost.Transmitter_ID.Port_ID gelöscht und neu berechnet.
Der Informationsaustausch innerhalb eines virtuellen Switches, d. h. innerhalb einer Reihe von Netzwerkteilnehmern mit linienförmiger Struktur, erfolgt mit Port-Select-Tele­ grammen, die den oben beschriebenen Port-Select-Telegrammen eines Netzwerks mit zweidimensionaler Struktur ähnlich sind. Der Datenbereich der Port-Select-Telegramme eines Netzwerks mit dreidimensionaler Struktur wird unabhängig vom empfan­ genden Port gegenüber dem Datenbereich der Port-Select- Telegramme für ein Netzwerk mit zweidimensionaler Struktur erweitert um eine 16-Bit-Adresse Rn des über Port T3/R3 angeschlossenen virtuellen Switches, d. h. der benachbarten Reihe, deren Gültigkeit durch das bereits beschriebene Valid- Bit V angezeigt wird. Bei V = 0 ist auch der empfangene Wert der Reihenadresse Rn ungültig. Das Port-Select-Telegramm wurde von einem Netzwerkteilnehmer in den virtuellen Switch eingespeist, der über einen betriebsbereiten Port T4/R4 mit dem virtuellen Switch verbunden ist. Bei V = 1 ist die Adresse Rn gültig. Zusätzlich ist in dem Datenbereich des Port-Select-Telegramms ein Potentiell-Aktiv-Bit PpA einge­ fügt. Abhängig vom empfangenden Port hat dieses Bit zwei Bedeutungen:
  • 1. PpA in Port-Select-Telegrammen, die an Port T4/R4 empfangen wurden, informiert den Netzwerkteilnehmer, ob der Port T3/R3 des sendenden Netzwerkteilnehmers des angeschlossenen virtuellen Switches potentiell aktiv oder aktiv (PpA = 1) oder deaktiviert (PpA = 0) ist.
  • 2. PpA in Port-Select-Telegrammen, die an Port T1/R1 oder Port T2/R2 empfangen wurden, informiert den Netzwerkteil­ nehmer, ob der Port T4/R4 des Initiators des Port-Select- Telegramms potentiell aktiv oder aktiv (PpA = 1) oder deaktiviert (PpA = 0) ist.
Weiterhin wird der Datenbereich des Port-Select-Telegramms um eine 16-Bit-Adresse Ri des über Port T4/R4 angeschlossenen virtuellen Switches erweitert. Der Wert der Adresse ist nur nötig, wenn PpA = 1 gesetzt ist.
Zudem wird in den Port-Select-Telegrammen ein Wert eines Aktiv-Timers zum Sendezeitpunkt übertragen. Der Aktiv-Timer mißt die Zeit, die seit dem letzten Empfang eines Port- Select-Telegramms über Port T4/R4 mit gesetztem Potentiell- Aktiv-Bit, d. h. mit PpA = 1, vergangen ist. Der Wert des Aktiv-Timers ist nur gültig, wenn PpA = 1 ist.
Weiterhin enthält der Datenbereich von Port-Select-Telegram­ men für dreidimensionale Netzwerkstruktur die beste empfange­ ne Kombination für diesen Port
KE = Root_ID.Cost.Transmitter_ID.Port_ID,
die im Datenfeld eines Konfigurationstelegramms gesendet oder weitergeleitet wurde von einer an einem potentiell aktiven oder aktiven Port T3/R3 oder T4/R4 angeschlossenen Reihe mit der Adresse Rn oder Ri.
Zudem wird die beste bisher bekannte Kombination an den potentiell aktiven oder aktiven Port T3/R3 und T4/R4 der Reihe, d. h. des virtuellen Switches, im Datenfeld von Port- Select-Telegrammen übertragen:
KR = Root_ID.Cost.Transmitter_ID.Port_ID.
Ein Netzwerkteilnehmer, der an einem deaktivierten Port T4/R4 ein Port-Select-Telegramm von einem potentiell aktiven oder aktiven Port T3/R3, d. h. ein Port-Select-Telegramm mit PpA = 1, einer anderen Reihe empfängt, schaltet den Port T4/R4 auf potentiell aktiv bzw. aktiv und sendet eine parametrier­ bare Anzahl von Port-Select-Telegrammen mit PpA = 1.
Den Ports T4/R4 ist jeweils ein Aktiv-Timer zugeordnet, der mit einem einstellbaren Takt inkrementiert wird. Der Aktiv- Timer mißt die Zeit seit dem letzten Empfang eines Port- Select-Telegramms mit gesetztem Potentiell-Aktiv-Bit PpA = 1. Jedes über Port T4/R4 empfangene Port-Select-Telegramm mit gesetztem Potentiell-Aktiv-Bit PpA = 1 setzt den Aktiv-Timer zurück und startet ihn neu. Empfangene Port-Select-Telegramme mit PpA = 0 setzen den Aktiv-Timer zurück, ohne ihn zu starten.
Ein Netzwerkteilnehmer mit einem potentiell aktiven oder aktiven Port T4/R4 deaktiviert diesen Port, wenn
  • 1. über Port T4/R4 ein Port-Select-Telegramm mit PpA = 0 empfangen wird,
  • 2. über Port T1/R1 oder T2/R2 ein Port-Select-Telegramm empfangen wird mit PpA = 1 und einem empfangenen Wert des Aktiv-Timers, der kleiner als die eigene Aktivzeit ist, wobei der eigene Aktiv-Timer in diesem Fall zurückgesetzt wird, ohne neu gestartet zu werden, oder
  • 3. die vom Aktiv-Timer gemessene Zeit einen parametrierbaren Maximalwert erreicht.
Im eingeschwungenen Zustand senden in jedem virtuellen Switch, d. h. in jeder Reihe, alle Netzwerkteilnehmer mit einer potentiell aktiven T3/R3-Verbindung zu einer benach­ barten, über die Ports T3/R3 angeschlossenen Reihe zyklisch in jedem Meldeintervall ΔtM jeweils ein Port-Select-Telegramm über die Ports T1/R1 und T2/R2.
Zusätzlich senden in jedem virtuellen Switch folgende Netz­ werkteilnehmer ein Port-Select-Telegramm über die Ports T1/R1 und T2/R2:
  • 1. jeder Netzwerkteilnehmer bei der Initialisierung mit KR = KE = Quelladresse.0.Quelladresse.Port_ID,
  • 2. jeder Netzwerkteilnehmer mit einem potentiell aktiven Kommunikationskanal über den Port T3/R3 zu einer Reihe mit der Adresse Rn, wenn er ein Konfigurationstelegramm über Port T3/R3 empfängt,
  • 3. jeder Netzwerkteilnehmer mit einem potentiell aktiven Kommunikationskanal über Port T4/R4 zu einer Reihe mit der Adresse Ri, wenn er ein Konfigurationstelegramm über Port T4/R4 empfängt,
  • 4. jeder Netzwerkteilnehmer, bei dem der Kombinations- Alterungszähler eines potentiell aktiven oder aktiven Ports den Schwellwert "maximales Alter" erreicht, wobei die für diesen Port gespeicherten Kombinationen KE und KR gelöscht und neu berechnet werden und wobei zunächst ein Port-Select-Telegramm mit
    KR = KE = Quelladresse.O.Quelladresse.Port_ID
    gesendet wird,
  • 5. jeder Netzwerkteilnehmer mit einem potentiell aktiven oder aktiven Port, dessen gespeicherte Kombination KR "besser" ist als die Kombination KR im empfangenen Port- Select-Telegramm, wobei die für diesen Port gespeicherte Kombination KR gelöscht und neu berechnet wird und wobei ein Port-Select-Telegramm mit der besten bisher empfange­ nen Kombination für diesen Port
    KE = Root_ID.Cost.Transmitter_ID.Port_ID und mit
    KR = min{KE, empfangener Wert von KR} gesendet wird und
  • 6. jeder Netzwerkteilnehmer, dessen Port T4/R4 von deakti­ viert auf potentiell aktiv oder aktiv umgeschaltet wird, sendet eine parametrierbare Anzahl von Port-Select- Telegrammen mit PpA = 1.
Alle Empfänger eines Port-Select-Telegramms mit einem deaktivierten Kommunikationskanal zu einer anderen Reihe speichern die vom zugehörigen potentiell aktiven oder aktiven Port des virtuellen Switches gesendeten Werte KE und KR.
Fig. 8 zeigt das Ergebnis der Anwendung der Port-Select- Telegramme in Kombination mit dem modifizierten Spanning- Tree-Verfahren auf jede Reihe des dargestellten dreidimensionalen Netzwerks.
Eine Redundanz im Netzwerk soll sicherstellen, daß physika­ lische Fehler, elektromagnetische Störungen, Netzwerkerwei­ terungen oder ein Komponentenaustausch die Kommunikation zwischen den Netzwerkkomponenten nicht beeinträchtigen. Voraussetzung hierfür ist nicht nur eine schnelle Erkennung von Fehlern oder Netzwerkmodifikationen und eine schnelle Netzrekonfiguration, sondern auch ein möglichst kleiner Netz­ werkbereich, der während der Rekonfigurationszeit von den Auswirkungen des Fehlers oder der Netzwerkmodifikation betroffen ist.
Durch die Redundanzverwaltung ist eine Redundanz innerhalb jeder Reihe eines Netzwerks, bezüglich der Kommunikations­ kanäle zwischen jeweils zwei miteinander verbundenen Reihen und eine Redundanz in bezug auf das gesamte Netzwerk möglich. Dabei ist Schleifenfreiheit durch den modifizierten Spanning- Tree-Algorithmus gewährleistet.
Diese Art der Redundanz ermöglicht in vorteilhafter Weise kurze Rekonfigurationszeiten bei minimalem Hardwareaufwand und ist deshalb mit geringem Aufwand realisierbar. Zudem wird der Netzwerkbereich begrenzt, der während der Rekonfigura­ tionszeit an den Auswirkungen eines Fehlers oder von einer Netzwerkkonfiguration betroffen ist.
Um Redundanz in einer Reihe linienförmig verschalteter Netz­ werkteilnehmer zu gewährleisten, wird ein Ring gebildet, wie es in Fig. 6 beispielsweise mit den Netzwerkteilnehmern 100 . . . 107 der Fall ist. Ein Netzwerkteilnehmer, beispiels­ weise der Netzwerkteilnehmer 100, der sich an einem Ende der Reihe befindet, muß im Redundanz-Mode betrieben werden. Er hat die Funktion eines Redundanz-Managers.
Durch Setzen eines Redundanzbits im Parameterregister wird dieser Netzwerkteilnehmer in dem Redundanz-Mode geschaltet. Zur Überprüfung der Reihe sendet er an Port 1 zyklisch ein Telegramm Test1 mit der MAC-Adresse des Ports 1 als Quell­ adresse. Die Zykluszeit beträgt beispielsweise 10 ms. An Port 2 wird zyklisch ein Telegramm Test2 mit der MAC-Adresse des Ports 2 als Quelladresse versendet. Die Zykluszeit beträgt ebenfalls beispielsweise 10 ms. Das Test2-Telegramm wird um die halbe Zykluszeit versetzt versendet, somit 5 ms nach dem Telegramm Test1. Ist die Reihe nicht unterbrochen, werden die am Port 1 versendeten Telegramme Test1 am Port 2 wieder emp­ fangen und ebenso die Test2-Telegramme in umgekehrter Rich­ tung. In diesem Fall ist der Kommunikationskanal zwischen den beiden Ports 1 und 2 innerhalb des Netzwerkteilnehmers, der als Redundanz-Manager betrieben wird, aufgetrennt, so daß alle am Port 2 empfangenen Datentelegramme herausgefiltert und von den am Port 1 empfangenen Telegrammen nur die an die eigene Stationsadresse gerichteten akzeptiert werden.
Der als Redundanz-Manager betriebene Netzwerkteilnehmer schließt den Ring, d. h. er leitet empfangene Telegramme zwischen dem Port 1 und 2 weiter, wenn innerhalb eines para­ metrierbaren Zeitintervalles von beispielsweise 100 ms an einem der beiden Ports kein Testtelegramm empfangen wird oder wenn ein Telegramm "link-down" von einem Netzwerkteilnehmer der jeweiligen Reihe empfangen wird, der eine Unterbrechung des Kommunikationskanals zum nächsten Netzwerkteilnehmer festgestellt hat. Der von der Unterbrechung betroffene Port des Netzwerkteilnehmers wird deaktiviert. Voraussetzung für die Reaktivierung dieses Ports ist die Wiederherstellung der Verbindung zum anderen Netzwerkteilnehmer für eine bestimmte Mindestzeit von beispielsweise 1,6 s oder der Empfang eines Telegramms "link-up" vom Redundanz-Manager. Mit dem Schließen des Rings wird an den Ports 1 und 2 des Redundanz-Managers ein Telegramm "link-down" verschickt, um alle anderen Netz­ werkteilnehmer der Reihe über die neue Reihenstruktur zu informieren. Testtelegramme werden weiterhin zyklisch versen­ det.
Der als Redundanz-Manager betriebene Netzwerkteilnehmer öffnet den Ring, wenn wieder ein Testtelegramm über die bisher unterbrochene Strecke empfangen wird oder wenn ein Telegramm "link-up" vom Netzwerkteilnehmer der Reihe emp­ fangen wird, dessen Kommunikationskanal zum benachbarten Netzwerkteilnehmer seit einer bestimmten Mindestzeit von beispielsweise 1,6 s nicht mehr unterbrochen ist. Mit dem Öffnen des Rings wird an den Ports 1 und 2 des Redundanz- Managers ein Telegramm "link-up" verschickt, um alle anderen Netzwerkteilnehmer der Reihe über die neue Ringstruktur zu informieren. Testtelegramme werden weiterhin zyklisch versen­ det. Jeder Netzwerkteilnehmer der Reihe setzt mit dem Empfang eines "link-up" oder "link-down"-Telegramms die für die Tele­ grammweiterleitung notwendigen Register zurück.
Eine redundante Ausführung der Kommunikationskanäle zwischen zwei Reihen erfordert mindestens zwei getrennte Kommunika­ tionspfade. Für den Datenaustausch zwischen den Reihen darf jedoch maximal ein einziger Pfad verwendet werden. Die Aus­ wahl dieses potentiell aktiven Kommunikationskanals zwischen zwei Reihen erfolgt mit Hilfe von Port-Select-Telegrammen. Ist ein potentiell aktiver Kommunikationskanal als fehlerhaft erkannt, wird dieser deaktiviert und ein anderer Kommunika­ tionspfad auf potentiell aktiv geschaltet. Für die Umschalt­ zeit von deaktiviert auf potentiell aktiv gilt:
Umschaltzeit ≧ Δttimeout + Δtrowdelay, wobei Δttimeout das Timeout- Intervall ist und Δtrowdelay der zweifachen Worst-Case- Durchlaufzeit eines Port-Select-Telegramms durch die Reihe entspricht. Die Umschaltzeit ist somit von der Anzahl der Netzwerkteilnehmer, die eine Reihe bilden, abhängig. Sie liegt z. B. für eine Reihe aus 50 Netzwerkteilnehmern in der Größenordnung von 200 ms, wenn ein Timeout-Zeitintervall von 150 ms angenommen wird.
Zudem ist eine Redundanz in einem dreidimensionalen Netzwerk möglich. Ist die Schleifenfreiheit bereits durch die Netz­ werkstruktur gegeben, d. h. existiert keine Netzwerkredundanz, so ist jeder potentiell aktive Kommunikationspfad zwischen zwei Reihen auch aktiv. In diesem Fall ist die Anwendung des beschriebenen modifizierten Spanning-Tree-Algorithmus nicht erforderlich. Bei Netzwerkredundanz stellt der modifizierte Spanning-Tree-Algorithmus Schleifenfreiheit zwischen den Reihen sicher. Eine Rekonfiguration eines Netzwerks mit dem modifizierten Spanning-Tree-Algorithmus ist nur bei Fehlern oder Netzwerkmodifikationen erforderlich, die nicht durch die Redundanz innerhalb einer Reihe oder die Redundanz der Kommu­ nikationskanäle zwischen zwei Reihen bearbeitet werden. Bei einem Netzwerk mit derartigen Netzwerkteilnehmern ist die Übertragungszeit vom Sender zum Empfänger von der Anzahl der Netzwerkteilnehmer, über welche ein Telegramm weitergeleitet wird, abhängig und kann nicht vernachlässigt werden. Die Übertragungszeit eines Telegramms erhöht sich bei jedem Netzwerkteilnehmer, der das Telegramm weiterleitet, um eine teilnehmerspezifische Delay-Time Δti, die aus den folgenden Zeiten zusammengesetzt ist:
  • 1. Durchlaufzeit durch den Physical-Layer-Baustein, bei­ spielsweise den Baustein 36 in Fig. 2, in Empfangs­ richtung vom Empfang des ersten Bits eines Nibbles bis das Nibble am MII mit in "RX_DV = 1" als gültig ausge­ geben wird. Diese Zeit beträgt beispielsweise 21 TBit für DP83843 PHYTER von NSC, wobei TBit bei 10 MBaud-Übertra­ gungsrate 100 ns und bei 100 MBaud-Übertragungsrate 10 ns entspricht.
  • 2. Aufenthaltszeit im Netzwerkteilnehmer vom Empfang eines Nibbles bis zum Versenden desselben Nibbles. Falls der Teilnehmer gerade ein eigenes Telegramm versendet und im Receive-Buffer bereits ein Telegramm eingetragen ist, kann die Datenweiterleitung im Vergleich zum ungestörten Betrieb um bis zu (3k × 8) × TBit verzögert werden.
  • 3. Durchlaufzeit durch den Physical-Layer-Baustein, über welchen das Telegramm in Senderichtung weitergeleitet wird, von der ersten steigenden Flanke eines Transmit- Clocksignals nach dem Bereitstellen eines Nibbles am MII bis zum ersten gesendeten Bit dieses Nibbles. Diese Durchlaufzeit beträgt beispielsweise für DP83843 PHYTER von NSC 6 TBit.
  • 4. Laufzeit über die Leitungen zwischen zwei benachbarten Netzwerkteilnehmern.
Die Summe der unter 1, 3 und 4 angegebenen Zeiten ist eine feste Größe und wird als Durchlaufzeit ΔtDLZ bezeichnet. Sie kann entweder parametriert oder von den Netzwerkteilnehmern ausgemessen werden. Eine Änderung dieser Durchlaufzeit ΔtDLZ ist nur möglich, wenn ein Netzwerkteilnehmer aus dem Netzwerk entfernt oder in das Netzwerk hinzugefügt oder wenn die Verkabelung geändert wird.
Mit der folgenden Sequenz von Telegrammen, welche Netz­ werkteilnehmer beispielsweise nach der Initialisierung oder auf Anforderung ausführen, kann die Durchlaufzeit ΔtDLZ bestimmt werden:
  • 1. Jeder Netzwerkteilnehmer, der neu in das Netzwerk aufge­ nommen wird, sendet seinen vier benachbarten Netzwerk­ teilnehmern jeweils ein sogenanntes DLZ-Telegramm, d. h. ein erstes Telegramm zur Laufzeitermittlung. Dieses Tele­ gramm ist in der 16-Bit-Type-Adresse eindeutig gekenn­ zeichnet.
  • 2. Der neue Netzwerkteilnehmer startet einen DLZ-Timer 1, nachdem das letzte Nibble des Type-Feldes des DLZ-Tele­ gramms dem Media-Independent-Interface (MII) des Ports 1 zum Versenden zur Verfügung gestellt wurde. Entsprechend startet er einen DLZ-Timer 2, 3 und 4 für das Versenden über die Ports 2, 3 bzw. 4.
  • 3. Jeder der maximal 4 benachbarten Netzwerkteilnehmer startet nach dem Empfang des letzten Nibbles des Type- Feldes des DLZ-Telegramms an seinem MII seinen DLZ-Timer des jeweiligen Ports. Das empfangene DLZ-Telegramm wird nicht weitergeleitet, sondern dem Sender ergänzt um die Aufenthaltszeit in den jeweiligen Ethernet-Kontroller des Netzwerkteilnehmers wieder zurückgeschickt. Hat dieser benachbarte Netzwerkteilnehmer das letzte Nibble des Type-Feldes des auf diese Art modifizierten DLZ-Tele­ gramms seinem zu dem neu zugeschalteten Netzwerkteilneh­ mer gerichteten MII übergeben, hält er den DLZ-Timer an und sendet die im DLZ-Timer gespeicherte Aufenthaltszeit mit dem Datenfeld des Telegramms zu dem neu zugeschalte­ ten Netzwerkteilnehmer.
  • 4. Der neu in das Netzwerk aufgenommene Netzwerkteilnehmer stoppt mit dem Empfang des letzten Nibbles des Type- Feldes an seinem MII des jeweiligen Ports den zugeordne­ ten DLZ-Timer 1, 2, 3 bzw. 4.
  • 5. Beispielsweise für Port 1 des neu zugeschalteten Netzwerkteilnehmers kann die Durchlaufzeit ΔtDLZ1 berechnet werden nach der Formel: ΔtDLZ1 = (TDR - TDA) : 2, mit TDR - mit dem DLZ-Timer 1 gemessene Antwortzeit und TDA - gemessene Aufenthaltszeit im benachbarten Netzwerk teilnehmer.
    In entsprechender Weise werden die Durchlaufzeiten ΔtDLZ2, ΔtDLZ3 und ΔtDLZ4 für die übrigen Ports des neu in das Netz­ werk eingefügten Netzwerkteilnehmers berechnet. Die so ermittelten Durchlaufzeiten werden im Modul 52 (Fig. 2) als Parameter hinterlegt.
  • 6. Der neu zugeschaltete Netzwerkteilnehmer sendet mit einem weiteren Telegramm die gemessenen Durchlaufzeiten über den jeweils zugeordneten Port an die benachbarten Netz­ werkteilnehmer.
Die beschriebene Ermittlung der Durchlaufzeiten ist bei der Initialisierung eines Netzwerks nur bei jedem zweiten Netz­ werkteilnehmer erforderlich.
Eine Uhrzeitsynchronisation hat die Aufgabe, die Uhren mehrerer oder aller Netzwerkteilnehmer zu synchronisieren. Dabei werden vorteilhaft die Kommunikationskanäle zwischen Netzwerkteilnehmern im Vollduplex-Mode betrieben, damit die Übertragung von Telegrammen deterministisches Verhalten zeigt.
Die Übertragungszeit von einem Sender zu einem Empfänger ist in einem Netzwerk von der Anzahl der Netzwerkteilnehmer, über welche das Telegramm geleitet wird, abhängig und kann nicht vernachlässigt werden.
Eine Uhrzeitsynchronisation kann beispielsweise mit zwei speziellen Telegrammen durchgeführt werden. Fig. 9 zeigt den allgemeinen Aufbau eines Telegramms. Ein erstes Feld 140 enthält eine Destination-Adresse, d. h. eine Adresse der Teil­ nehmer, an welche das Telegramm gerichtet ist, von beispiels­ weise 48 Bit Länge. Ein zweites Feld 141 enthält eine Source- Adresse, die Adresse des jeweils sendenden Netzwerkteilneh­ mers, deren Länge ebenfalls beispielsweise 48 Bit beträgt. In einem Type-Feld 142 mit beispielsweise 16 Bit wird eine Ken­ nung des Telegramms übertragen 11991 00070 552 001000280000000200012000285911188000040 0002010004425 00004 11872. Die Nutzdaten des Telegramms werden in einem Datenfeld 143 variabler Länge gesendet. Been­ det wird das Telegramm durch eine Check-Sequence von 144, die im wesentlichen zur Überprüfung der Übertragungsqualität dient. Telegramme zur Uhrzeitsynchronisation können durch eine besondere Multicast-Adresse als Destination-Adresse 140 und/oder durch eine neu zu definierende Type-Adresse im Type- Feld 142 gekennzeichnet werden.
Fig. 10 zeigt eine Auftragsliste, die beispielsweise im RAM 22 in Fig. 2 abgelegt sein kann. In eine derartige Auftrags­ liste werden Telegramme, die über das Netzwerk übertragen werden sollen, eingetragen. Wenn keine Priorisierung der Übertragung vorgesehen ist, wird jeweils das untenstehende Telegramm als nächstes übertragen. Es kann somit vorkommen, daß beispielsweise ein fertiggestelltes Telegramm 151 erst dann übertragen wird, wenn zwei zuvor in die Auftragsliste eingetragene Telegramme 152 und 153 übertragen wurden. Je nach Menge der anstehenden Aufträge ist daher die Sendever­ zögerungszeit eines Telegramms in einem Netzwerkteilnehmer nach seinem Eintrag in die Auftragsliste variabel. Im folgen­ den wird eine Möglichkeit beschrieben, wie der Einfluß der Sendezeitverzögerung bei der Uhrzeitsynchronisation vermieden werden kann:
  • 1. Bei einem Uhrzeit-Master, d. h. ein Netzwerkteilnehmer, auf dessen Uhr die Uhren der übrigen Netzwerkteilnehmer syn­ chronisiert werden, trägt ein SM-Time0 Telegramm, ein ers­ tes Telegramm zur Uhrzeitsynchronisation, in eine Auftragsliste ein, startet für jeden Port P, P = 1, 2, 3, 4, einen Delay-Timer und merkt sich die Startzeit dieser Timer.
  • 2. Der Delay-Timer von jedem Port P, P = 1, 2, 3, 4, wird beim Uhrzeit-Master angehalten, nachdem das letzte Nibble des Type-Feldes des SM-Time0 Telegramms dem MII des jeweiligen Ports zum Versenden zur Verfügung gestellt wurde. Damit ist die Sendeverzögerungszeit bestimmt. Ein Nibble ist definiert als ein halbes Byte, d. h., es ist eine Folge von 4 Bit.
  • 3. Jeder benachbarte Netzwerkteilnehmer startet nach dem Empfang des letzten Nibbles des Type-Feldes des SM-Time0 Telegramms am MII seines Ports P, P = 1, 2, 3 oder 4, seinen Delay-Timer mit dem Wert der jeweiligen Durch­ laufzeit ΔtDLZp, die zuvor nach dem oben beschriebenen Verfahren gemessen oder von einem Bediener eingegeben wurde. Zusätzlich wird die Adresse des Uhrzeit-Masters, die im SM-Time0 Telegramm als Source-Adresse empfangen wurde, gespeichert.
  • 4. Zu dem Zeitpunkt, zu welchem der benachbarte Netzwerk­ teilnehmer das letzte Nibble des Type-Feldes des SM-Time0 Telegramms zur Weiterleitung an das MII eines anderen Ports anlegt, wird der Wert des Delay-Timers, der dem Port P, P = 1, 2, 3 bzw. 4, zugeordnet ist, abgespeichert. Die Delay-Timer laufen jedoch weiter. Die gespeicherten Delay- Times der Ports entsprechen jeweils der oben definierten Übertragungszeit Δti dieses Netzwerkteilnehmers. Durch den Startwert ΔtDLZp des Delay-Timers ist die Laufzeit des Tele­ gramms über die physikalische Übertragung bereits hinzu­ addiert.
  • 5. Anschließend trägt der Uhrzeit-Master ein SM-Time1 Tele­ gramm, das im Datenfeld die Startzeit der Delay-Timer enthält, in die Auftragsliste ein. Bevor er dieses SM- Time1 Telegramm über einen Port P, P = 1, 2, 3, 4, sendet, ersetzt er die Startzeit der Delay-Timer durch die Uhr­ zeit, zu welcher das letzte Nibble des Type-Feldes des SM- Time0 Telegramms dem MII dieses Ports zum Versenden zur Verfügung gestellt wurde, d. h. durch die Summe der Start­ zeit der Delay-Timer und der gemessenen Delay-Time des jeweiligen Ports P. In das SM-Time1 Telegramm wird somit die um die Sendezeitverzögerung korrigierte Uhrzeit einge­ tragen.
  • 6. Jeder benachbarte Netzwerkteilnehmer, der ein SM-Time1 Telegramm empfängt, addiert jeweils die gespeicherte Delay-Time Δti des zuvor über Port P, P = 1, 2, 3 bzw. 4, weitergeleiteten SM-Time0 Telegramms zu der im SM-Time1 Telegramm empfangenen Uhrzeit und sendet die so erhaltene Zeit mit einem aktualisierten SM-Time1 Telegramm über einen anderen Port zum nächsten Nachbar. SM-Time1 Tele­ gramme werden nur von dem Netzwerkteilnehmer akzeptiert, der zuvor ein SM-Time0 Telegramm gesendet hatte.
Mit dem Empfang des SM-Time1 Telegramms kennt der Uhrzeit- Slave, d. h. der benachbarte Netzwerkteilnehmer, die Startzeit seines Delay-Timers. Die synchronisierte Uhrzeit ergibt sich aus der Summe der im SM-Time1 Telegramm empfangenen Uhrzeit und der Delay-Time des Uhrzeit-Slaves für den jeweils empfan­ genden Port. Somit korrigiert der benachbarte Netzwerkteil­ nehmer die im zweiten Telegramm empfangene Uhrzeit um die Laufzeit und die Empfangszeitverzögerung.
Mit dem folgenden Ablauf ist alternativ zu der oben beschrie­ benen Möglichkeit eine Uhrzeitsynchronisation mit nur einem Telegramm möglich:
  • 1. Ein Uhrzeit-Master startet die den Ports zugeordneten Delay-Timer und trägt das Uhrzeittelegramm mit der Start­ zeit dieser Timer in die Auftragsliste ein.
  • 2. Der Delay-Timer jedes Ports P, P = 1, 2, 3, 4, wird beim Uhrzeit-Master angehalten, nachdem das letzte Nibble des Type-Feldes des Uhrzeittelegramms dem Media-Independent- Interface von Port P zum Versenden zur Verfügung gestellt wurde, d. h. nachdem das letzte Nibble des Type-Feldes zur physikalischen Übertragung bereitgestellt wurde. Der Netz­ werkteilnehmer addiert daraufhin die im Uhrzeittelegramm angegebene Startzeit der Delay-Timer zum Wert des Delay- Timers des jeweiligen Ports P und versendet diese Summe als um die Sendezeitverzögerung korrigierte Uhrzeit mit einem ersten Telegramm zur Uhrzeitsynchronisation über den jeweiligen Port P.
  • 3. Jeder benachbarte Netzwerkteilnehmer startet nach dem Empfang des letzten Nibbles des Type-Feldes des ersten Telegramms zur Uhrzeitsynchronisation an einem Port P, P = 1, 2, 3 oder 4, seinen zugeordneten Delay-Timer mit dem Wert der jeweiligen Durchlaufzeit ΔtDLZP. Er mißt somit die Zeitverzögerung seit Empfang des ersten Telegramms.
  • 4. Zu dem Zeitpunkt, zu welchem der benachbarte Netzwerk­ teilnehmer das letzte Nibble des Type-Feldes des ersten Telegramms zur Uhrzeitsynchronisation zur Weiterleitung an das MII eines Ports anlegt, wird der Wert des Delay- Timers, der diesem Port zugeordnet ist, abgespeichert. Die Delay-Timer laufen jedoch weiter. Die gespeicherten, den einzelnen Ports zugeordneten Delay-Times entsprechen je­ weils der Übertragungszeit Δti dieses Netzwerkteilnehmers. Sie wird jeweils zur empfangenen Startzeit der Delay-Timer addiert und mit einem zweiten Telegramm zur Uhrzeitsyn­ chronisation über einen anderen Port zum nächsten, d. h. einem dritten, Netzwerkteilnehmer weitergeleitet.
Mit dem Empfang eines ersten oder zweiten Telegramms zur Uhrzeitsynchronisation kennt der Uhrzeit-Slave die Startzeit seines Delay-Timers. Die synchronisierte Uhrzeit ergibt sich aus der Summe der in einem ersten oder zweiten Telegramm empfangenen Uhrzeit und der Delay-Time des Uhrzeit-Slaves für den empfangenden Port P.
Die beschriebenen Möglichkeiten zur Uhrzeitsynchronisation können in entsprechender Weise zur Synchronisation von Äqui­ distanz-Timern in den Netzwerkteilnehmern dienen. Aufgabe von Äquidistanz-Timern ist es, mehreren oder allen Netzwerkteil­ nehmern zu ermöglichen, vorgegebene Aktionen äquidistant aus­ zuführen. Bei Regelungssystemen wird diese Funktion häufig als "elektronische Welle" bezeichnet. Es soll bei allen Netzwerkteilnehmern, die über das Netzwerk miteinander ver­ bunden sind, ein Taktschläger generiert werden, mit dessen Takt jeweils Soll-Werte übergeben und Ist-Werte abgefragt werden. Ein Anwendungsbeispiel ist die Messung der elek­ trischen Leistung, wenn die dazu erforderlichen Strom- und Spannungsmeßwerte von getrennten Meßumformern erfaßt und über ein Netzwerk abgefragt werden.
Vorausgesetzt wird, daß ein äquidistanter Zyklus von nur einem Äquidistanz-Master gesteuert wird. Der Netzwerkteil­ nehmer, der die Funktion eines Äquidistanz-Masters übernimmt, besitzt einen Timer, der beim Start mit dem parametrierbaren Wert des Äquidistanz-Intervalls geladen wird. Der Timer ist freilaufend und wird mit jedem Bittakt dekrementiert. Ist der Timer abgelaufen, wird er wieder mit dem parametrierten Wert des Äquidistanz-Intervalls geladen und ein neuer Zyklus beginnt. Ein Unterschied eines Äquidistanz-Timers gegenüber einer Uhr ist somit die Laufrichtung. Zur Korrektur eines mit Telegrammen übertragenen Timer-Standes müssen daher die Zeitverzögerungen nicht wie bei der Uhrzeit addiert, sondern subtrahiert werden. Der oben verwendete Begriff "Uhrzeit- Synchronisation" soll daher so verstanden werden, daß er auch die Synchronisation von Äquidistanz-Timern einschließt.
Für eine Synchronisation äquidistanter Aktionen gibt es beispielsweise folgende Möglichkeit:
  • 1. Der Äquidistanz-Master trägt das Äquidistanz-Telegramm in die Auftragsliste ein. Er speichert jeweils den Wert des Äquidistanz-Timers ab, wenn das letzte Nibble des Type- Feldes des Äquidistanz-Telegramms an den MII der vier Ports P, P = 1, 2, 3, 4, übergeben wird, d. h. zur physi­ kalischen Übertragung bereitgestellt wird. Dieser für jeden Port P gespeicherte Wert ΔtÄqui, welcher der verblei­ benden Zeit bis zum Ablauf des Äquidistanz-Intervalls entspricht, wird mit dem Äquidistanz-Telegramm über Port P zum benachbarten Netzwerkteilnehmer gesendet.
  • 2. Jeder Netzwerkteilnehmer startet nach dem Empfangen des letzten Nibbles des Type-Feldes des Äquidistanz-Telegramms am MII eines Ports, d. h. beim Empfangen des Äquidistanz- Telegramms von der physikalischen Übertragungsstrecke, einen Hilfs-Timer mit dem Wert der Durchlaufzeit ΔtDLZP.
  • 3. Zu dem Zeitpunkt, zu welchem der benachbarte Netzwerk­ teilnehmer das letzte Nibble des Type-Feldes vom Äqui­ distanz-Telegramm zur Weiterleitung an das MII eines anderen Ports anlegt, wird der Wert des Hilfs-Timers abgespeichert. Der gespeicherte Wert des Hilfs-Timers entspricht der Übertragungszeit Δti dieses Netzwerk­ teilnehmers für den Port P. Diese gespeicherte Zeit Δti wird von der empfangenen Restzeit ΔtÄqui bis zum nächsten Zyklusbeginn subtrahiert. Der benachbarte Netzwerkteilneh­ mer leitet die korrigierte Restzeit (ΔtÄqui - Δti) mit dem Äquidistanz-Telegramm über den anderen Port zum nächsten benachbarten Netzwerkteilnehmer weiter. Zusätzlich lädt er die korrigierte Restzeit in seinen Äquidistanz-Timer, der mit jedem Takt dekrementiert wird.
  • 4. Ist der Äquidistanz-Timer eines Äquidistanz-Slaves abgelaufen, so wird er zunächst mit dem parametrierten Wert des Äquidistanz-Intervalls geladen und mit jedem Bittakt dekrementiert. Sobald ein neues Äquidistanz- Telegramm des Äquidistanz-Masters empfangen wird, lädt der Äquidistanz-Slave die in der beschriebenen Weise ermittelte Restzeit (ΔtÄqui - Δti) bis zum nächsten Zyklusbeginn in den Äquidistanz-Timer.
Für die beschriebene Synchronisation von Äquidistanz-Timern sollte die maximale Übertragungszeit zwischen einem Sender und einem Empfänger im Netzwerk kleiner sein als die Länge des Äquidistanz-Intervalls.
In dem Ausführungsbeispiel wurde ein Netzwerk nach der Ethernet-Spezifikation beschrieben. Die Erfindung ist jedoch ohne weiteres auch auf Fast-Ethernet, Gigabit-Ethernet oder andere Netzwerktypen anwendbar.

Claims (14)

1. Netzwerk mit mehreren Netzwerkteilnehmern, wobei ein erster Netzwerkteilnehmer dazu ausgebildet ist, ein erstes Telegramm zur Uhrzeitsynchronisation an einen zweiten Netz­ werkteilnehmer zu senden, in welchem die Durchlaufzeit des Telegramms über die physikalische Übertragungsstrecke zwischen dem ersten Netzwerkteilnehmer und dem zweiten Netz­ werkteilnehmer abgespeichert ist, dadurch ge­ kennzeichnet, daß das erste Telegramm eine um eine Sendezeitverzögerung korrigierte Uhrzeit des ersten Netzwerk­ teilnehmers enthält, und daß der zweite Netzwerkteilnehmer dazu ausgebildet ist, die Zeitverzögerung seit Empfang des ersten Telegramms zu messen und die im ersten Telegramm emp­ fangene Uhrzeit um die Durchlaufzeit und die Empfangszeitver­ zögerung zu korrigieren.
2. Netzwerk nach Anspruch 1, dadurch gekenn­ zeichnet, daß der zweite Netzwerkteilnehmer weiterhin dazu ausgebildet ist, ein zweites Telegramm zur Uhrzeitsyn­ chronisation an einen dritten Netzwerkteilnehmer zu senden, das eine um die Durchlaufzeit und die Verzögerungszeit zwischen Empfang des ersten Telegramms und Senden des zweiten Telegramms korrigierte, empfangene Uhrzeit enthält.
3. Netzwerk mit mehreren Netzwerkteilnehmern, wobei ein erster Netzwerkteilnehmer dazu ausgebildet ist, ein erstes Telegramm zur Uhrzeitsynchronisation an einen zweiten Netzwerkteilnehmer zu senden, in welchem die Durchlaufzeit des Telegramms über die physikalische Übertragungsstrecke zwischen dem ersten Netzwerkteilnehmer und dem zweiten Netzwerkteilnehmer abgespeichert ist, dadurch ge­ kennzeichnet, daß der erste Netzwerkteilnehmer weiterhin dazu ausgebildet ist, eine um eine Sendezeitver­ zögerung des ersten Telegramms korrigierte Uhrzeit des ersten Netzwerkteilnehmers abzuspeichern, daß der zweite Netzwerkteilnehmer dazu ausgebildet ist, die Zeitverzögerung seit Empfang des ersten Telegramms zu messen, wobei der erste Netzwerkteilnehmer weiterhin dazu ausgebildet ist, ein zweites Telegramm, das die um die Sendezeitverzögerung korrigierte Uhrzeit des ersten Netzwerkteilnehmers enthält, an den zweiten Netzwerkteilnehmer zu senden und wobei der zweite Netzwerkteilnehmer weiterhin dazu ausgebildet ist, die im zweiten Telegramm empfangene Uhrzeit um die Durchlaufzeit und die Empfangszeitverzögerung zu korrigieren.
4. Netzwerk nach Anspruch 3, dadurch gekenn­ zeichnet, daß der zweite Netzwerkteilnehmer weiterhin dazu ausgebildet ist, das erste Telegramm an einen dritten Netzwerkteilnehmer weiterzuleiten, seine Verzögerungszeit der Telegrammweiterleitung zu messen und ein drittes Telegramm an den dritten Netzwerkteilnehmer zu senden, das eine um die Durchlaufzeit und die Verzögerungszeit der Telegrammweiter­ leitung des ersten Telegramms korrigierte, empfangene Uhrzeit enthält.
5. Netzwerk nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der erste Netzwerkteilnehmer einen ersten Timer (57) zur Bestimmung der Sendezeitverzögerung aufweist, den er beim Eintragen eines Telegramms in eine Liste der Sendeaufträge startet und nach Bereitstellung des Telegramms zur physikalischen Übertragung als Wert der Sendezeitverzögerung ausliest, um welchen die Uhrzeit, zu welcher das Telegramm in die Liste der Sendeauf­ träge eingetragen wurde, zu korrigieren ist.
6. Netzwerk nach Anspruch 5, dadurch gekenn­ zeichnet, daß der zweite Netzwerkteilnehmer einen zweiten Timer zur Bestimmung der Empfangszeitverzögerung aufweist, den er bei Empfang eines ersten Telegramms von einer physikalischen Übertragungsstrecke startet.
7. Netzwerk nach Anspruch 6, dadurch ge­ kennzeichnet, daß die Durchlaufzeit des Telegramms über die physikalische Übertragungsstrecke zwischen dem ersten Netzwerkteilnehmer und dem zweiten Netzwerkteilnehmer als Startwert in den zweiten Timer vor dessen Start abge­ speichert ist.
8. Netzwerk nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß Beginn und Ende der Durchlaufzeit eines Telegramms jeweils als der Zeitpunkt bestimmt sind, zu welchem ein charakteristisches Feld eines Telegramms mit festem Abstand vom Telegrammanfang ein Media Independent Interface des ersten Teilnehmers verläßt, bzw. in ein Media Independent Interface des zweiten Netzwerkteilneh­ mers einläuft.
9. Netzwerk nach Anspruch 8, dadurch gekenn­ zeichnet, daß das Netzwerk die Ethernet-, Fast-Ether­ net- oder Gigabit-Ethernet-Spezifikation erfüllt und daß das charakteristische Feld des Telegramms das Type-Feld ist.
10. Netzwerk nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der erste Netzwerkteilnehmer weiterhin dazu ausgebildet ist, nach der Aufnahme in das Netzwerk ein erstes Telegramm zur Laufzeiter­ mittlung an einen benachbarten Teilnehmer zu senden und einen Antwortzeit-Timer nach Bereitstellung des Telegramms zur physikalischen Übertragung zu starten, daß der zweite Netz­ werkteilnehmer weiterhin dazu ausgebildet ist, nach Empfang eines Telegramms zur Laufzeitermittlung von der physika­ lischen Übertragung einen Timer zur Ermittlung der Aufent­ haltszeit zu starten und nach Bereitstellung eines zweiten Telegramms zur physikalischen Übertragung den Timer zu stoppen und die gemessene Aufenthaltszeit tDA in einem zweiten Telegramm zur Laufzeitermittlung an den ersten Netzwerkteil­ nehmer zu übertragen, daß der erste Netzwerkteilnehmer weiterhin dazu ausgebildet ist, nach Empfang des zweiten Telegramms zur Laufzeitermittlung von der physikalischen Übertragung den Antwortzeit-Timer zu stoppen, die gemessene Antwortzeit tDR sowie die gemessene Aufenthaltszeit tDA des zweiten Netzwerkteilnehmers auszuwerten und eine Durch­ laufzeit tDLZ der physikalischen Übertragung zu bestimmen zu
11. Netzwerkteilnehmer, insbesondere Feldgerät, für ein Netzwerk nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß mehrere Ports, insbesondere vier Ports (28 . . . 31), zum Anschluß weiterer Netzwerkkomponenten vorgesehen sind, daß eine Schnittstelle (25), ein sogenanntes Mikroprozessor-Interface, vorgesehen ist zur Verbindung der Ports mit einem teilnehmerinternen Prozessor-Bus (21), daß eine Steuereinheit (46), eine sogenannte Switch-Control, vorgesehen ist zur Telegrammweg­ lenkung zwischen den Ports und dem Mikroprozessor-Interface und daß der Netzwerkteilnehmer dazu ausgebildet ist, als Uhrzeit-Master ein erstes Telegramm zur Uhrzeitsynchroni­ sation an einen zweiten Netzwerkteilnehmer zu senden, das eine um eine Sendezeitverzögerung korrigierte Uhrzeit des Netzwerkteilnehmers enthält, und/oder daß in dem Netzwerk­ teilnehmer als Uhrzeit-Slave die Durchlaufzeit eines Tele­ gramms über die physikalische Übertragungsstrecke zwischen dem Netzwerkteilnehmer und einem zweiten Netzwerkteilnehmer abgespeichert ist und daß der Netzwerkteilnehmer dazu ausge­ bildet ist, die Zeitverzögerung seit Empfang eines Telegramms zur Uhrzeitsychronisation zu messen und eine in einem Tele­ gramm empfangene Uhrzeit um die Durchlaufzeit und die Empfangszeitverzögerung zu korrigieren.
12. Netzwerkteilnehmer nach Anspruch 1, dadurch gekennzeichnet, daß die Ports (28 . . . 31) der Ethernet-, Fast-Ethernet- oder Gigabit-Ethernet-Spezifikation genügen.
13. Netzwerkteilnehmer nach Anspruch 12, dadurch gekennzeichnet, daß die Steuereinheit (46) derart ausgebildet ist, daß eine Übertragungspriorität der zu versendenden Telegramme ausgewertet wird und daß Telegramme mit hoher Priorität vor Telegrammen mit niederer Priorität gesendet werden.
14. Netzwerkteilnehmer nach einem der Ansprüche 11 bis 13, dadurch gekennzeichnet, daß ein Mikropro­ zessor (23) vorhanden ist zur Korrektur einer internen Uhr anhand in Telegrammen empfangener Uhrzeitinformationen.
DE2000104425 2000-02-02 2000-02-02 Netzwerk sowie Netzwerkteilnehmer, insbesondere Feldgerät, für ein derartiges Netzwerk Ceased DE10004425A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE2000104425 DE10004425A1 (de) 2000-02-02 2000-02-02 Netzwerk sowie Netzwerkteilnehmer, insbesondere Feldgerät, für ein derartiges Netzwerk
PCT/DE2001/000413 WO2001058067A1 (de) 2000-02-02 2001-02-02 Uhrzeitsynchronisation in einem netzwerk sowie netzwerkteilnehmer, insbesondere feldgerät, für ein derartiges netzwerk

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE2000104425 DE10004425A1 (de) 2000-02-02 2000-02-02 Netzwerk sowie Netzwerkteilnehmer, insbesondere Feldgerät, für ein derartiges Netzwerk

Publications (1)

Publication Number Publication Date
DE10004425A1 true DE10004425A1 (de) 2002-01-17

Family

ID=7629500

Family Applications (1)

Application Number Title Priority Date Filing Date
DE2000104425 Ceased DE10004425A1 (de) 2000-02-02 2000-02-02 Netzwerk sowie Netzwerkteilnehmer, insbesondere Feldgerät, für ein derartiges Netzwerk

Country Status (1)

Country Link
DE (1) DE10004425A1 (de)

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002075509A2 (de) * 2001-03-16 2002-09-26 Siemens Aktiengesellschaft Synchrones, getaktetes kommunikationssystem mit relativuhr und verfahren zum aufbau eines solchen systems
WO2003036832A2 (de) * 2001-10-17 2003-05-01 Siemens Aktiengesellschaft Verfahren zum betrieb eines endteilnehmers eines isochronen, zyklischen kommunikationssystems
EP1453230A2 (de) * 2003-02-28 2004-09-01 Siemens Aktiengesellschaft Synchronisation in einem schaltbaren Datennetz
DE102004035194A1 (de) * 2004-07-21 2006-02-16 Görlitz Ag Verfahren zur Weiterleitung von Zeitinformationen
DE102004027919B3 (de) * 2004-06-09 2006-03-30 Pfw Technologies Gmbh Verfahren zur Korrektur des Einflusses von Signalübertragungsleitungen auf Signallaufzeitänderungen bei Ultraschallmessungen
WO2006136201A1 (de) 2005-06-23 2006-12-28 Hilscher Gesellschaft für Systemautomation mbH Verfahren zur datenkommunikation von busteilnehmern eines offenen automatisierungssystems
EP1884851A2 (de) 2004-01-09 2008-02-06 Beckhoff Automation GmbH Verfahren, Knoten und Netzwek zum zyklischen Versenden von Ethernet-Telegrammen
US7463643B2 (en) 2001-03-16 2008-12-09 Siemens Aktiengesellschaft Applications of a switched data network for real-time and non-real time communication
EP2026147A1 (de) * 2007-08-13 2009-02-18 Siemens Aktiengesellschaft Verfahren zum Übermitteln von Telegrammen zwischen einer Steuereinrichtung und einem Peripherieelement über ein Zwischengerät
EP2804010A1 (de) * 2013-05-13 2014-11-19 Kapsch TrafficCom AG Verfahren zum Kalibrieren einer Triggereinheit und kaskadierbarer Sensor hierfür
EP2527935B1 (de) * 2011-05-26 2014-12-03 Siemens Aktiengesellschaft Verfahren zum Betrieb eines Automatisierungssystems
DE102017201770A1 (de) 2017-02-03 2018-08-09 Siemens Aktiengesellschaft Verfahren zum Einrichten eines gemeinsamen Netzwerkes zur Datenübertragung beim Kuppeln eines ersten Schienenfahrzeugs mit einem zweiten Schienenfahrzeug, Kupplungssystem, Schienenfahrzeug und Schienenfahrzeugflotte
DE102019114307A1 (de) * 2019-05-28 2020-12-03 Beckhoff Automation Gmbh Automatisierungsnetzwerk, Netzwerkverteiler und Verfahren zur Datenübertragung
WO2020254020A1 (de) * 2019-06-18 2020-12-24 Beckhoff Automation Gmbh Netzwerkteilnehmer und automatisierungsnetzwerk

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4215380A1 (de) * 1992-05-11 1993-11-18 Siemens Ag Verfahren zum Synchronisieren von lokalen Zeitgebern eines Automatisierungssystems
EP0613271A2 (de) * 1993-02-22 1994-08-31 Honeywell Inc. Verfahren und Anlage zur Zeit-Synchronisierung von Bus-LANs, mit hierarchischen Netzen
WO2000028400A1 (de) * 1998-11-05 2000-05-18 Siemens Aktiengesellschaft Netzwerkteilnehmer

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4215380A1 (de) * 1992-05-11 1993-11-18 Siemens Ag Verfahren zum Synchronisieren von lokalen Zeitgebern eines Automatisierungssystems
EP0613271A2 (de) * 1993-02-22 1994-08-31 Honeywell Inc. Verfahren und Anlage zur Zeit-Synchronisierung von Bus-LANs, mit hierarchischen Netzen
WO2000028400A1 (de) * 1998-11-05 2000-05-18 Siemens Aktiengesellschaft Netzwerkteilnehmer

Cited By (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7012980B2 (en) 2001-03-16 2006-03-14 Siemens Aktiengesellschaft Synchronous, clocked communication system with relative clock and method for configuring such a system
US7463643B2 (en) 2001-03-16 2008-12-09 Siemens Aktiengesellschaft Applications of a switched data network for real-time and non-real time communication
WO2002075509A3 (de) * 2001-03-16 2003-05-08 Siemens Ag Synchrones, getaktetes kommunikationssystem mit relativuhr und verfahren zum aufbau eines solchen systems
WO2002075509A2 (de) * 2001-03-16 2002-09-26 Siemens Aktiengesellschaft Synchrones, getaktetes kommunikationssystem mit relativuhr und verfahren zum aufbau eines solchen systems
US7460560B2 (en) 2001-10-17 2008-12-02 Siemens Aktiengesellschaft Method for operating an end-user of an isochronous cyclical communication system
WO2003036832A3 (de) * 2001-10-17 2003-08-21 Siemens Ag Verfahren zum betrieb eines endteilnehmers eines isochronen, zyklischen kommunikationssystems
WO2003036832A2 (de) * 2001-10-17 2003-05-01 Siemens Aktiengesellschaft Verfahren zum betrieb eines endteilnehmers eines isochronen, zyklischen kommunikationssystems
EP1453230A2 (de) * 2003-02-28 2004-09-01 Siemens Aktiengesellschaft Synchronisation in einem schaltbaren Datennetz
EP1453230A3 (de) * 2003-02-28 2006-05-17 Siemens Aktiengesellschaft Synchronisation in einem schaltbaren Datennetz
EP1884851A3 (de) * 2004-01-09 2009-12-30 Beckhoff Automation GmbH Verfahren, Knoten und Netzwek zum zyklischen Versenden von Ethernet-Telegrammen
EP1884851A2 (de) 2004-01-09 2008-02-06 Beckhoff Automation GmbH Verfahren, Knoten und Netzwek zum zyklischen Versenden von Ethernet-Telegrammen
DE102004027919B3 (de) * 2004-06-09 2006-03-30 Pfw Technologies Gmbh Verfahren zur Korrektur des Einflusses von Signalübertragungsleitungen auf Signallaufzeitänderungen bei Ultraschallmessungen
DE102004035194B4 (de) * 2004-07-21 2006-12-07 Görlitz Ag Verfahren zur Weiterleitung von Zeitinformationen
DE102004035194A1 (de) * 2004-07-21 2006-02-16 Görlitz Ag Verfahren zur Weiterleitung von Zeitinformationen
WO2006136201A1 (de) 2005-06-23 2006-12-28 Hilscher Gesellschaft für Systemautomation mbH Verfahren zur datenkommunikation von busteilnehmern eines offenen automatisierungssystems
EP2026147A1 (de) * 2007-08-13 2009-02-18 Siemens Aktiengesellschaft Verfahren zum Übermitteln von Telegrammen zwischen einer Steuereinrichtung und einem Peripherieelement über ein Zwischengerät
US8516169B2 (en) 2007-08-13 2013-08-20 Siemens Aktiengesellschaft Method for transmitting telegrams between a control device and a peripheral element via an intermediate device
EP2527935B1 (de) * 2011-05-26 2014-12-03 Siemens Aktiengesellschaft Verfahren zum Betrieb eines Automatisierungssystems
EP2804010A1 (de) * 2013-05-13 2014-11-19 Kapsch TrafficCom AG Verfahren zum Kalibrieren einer Triggereinheit und kaskadierbarer Sensor hierfür
US9494450B2 (en) 2013-05-13 2016-11-15 Kapsch Trafficcom Ag Method for calibrating a trigger unit and cascadable sensor therefor
DE102017201770A1 (de) 2017-02-03 2018-08-09 Siemens Aktiengesellschaft Verfahren zum Einrichten eines gemeinsamen Netzwerkes zur Datenübertragung beim Kuppeln eines ersten Schienenfahrzeugs mit einem zweiten Schienenfahrzeug, Kupplungssystem, Schienenfahrzeug und Schienenfahrzeugflotte
DE102019114307A1 (de) * 2019-05-28 2020-12-03 Beckhoff Automation Gmbh Automatisierungsnetzwerk, Netzwerkverteiler und Verfahren zur Datenübertragung
US11700145B2 (en) 2019-05-28 2023-07-11 Beckhoff Automation Gmbh Automation network, network distributor and method for transmitting data
WO2020254020A1 (de) * 2019-06-18 2020-12-24 Beckhoff Automation Gmbh Netzwerkteilnehmer und automatisierungsnetzwerk
US11765124B2 (en) 2019-06-18 2023-09-19 Beckhoff Automation Gmbh Receiving logic hardware for network subscribers, network subscriber, and automation network

Similar Documents

Publication Publication Date Title
EP1748338B1 (de) Verfahren zur Optimierung der Bandbreitenausnutzung bei Bussystemen
EP1648117B1 (de) Verfahren zur Synchronisation in einem redundanten Kommunikationssystem
DE102014108457B3 (de) Netzwerkverteiler
EP1657608A1 (de) Verfahren und Vorrichtung zum Betreiben eines Netzwerkes
WO2019001718A1 (de) Verfahren zur reservierung von maximal redundanten übertragungswegen für die übertragung von datenpaketen und vorrichtung
EP2961106B1 (de) Netzwerk, kopf-teilnehmer und datenübertragungsverfahren
WO2019007516A1 (de) Verfahren zur performanten datenübertragung in einem datennetz mit teilweise echtzeit-anforderungen und vorrichtung zur durchführung des verfahrens
DE102004050424B4 (de) Verfahren zur Übertragung von Daten in einem Kommunikationssystem
WO2019081230A1 (de) Datenübertragungsverfahren und kommunikationsnetzwerk
DE10004425A1 (de) Netzwerk sowie Netzwerkteilnehmer, insbesondere Feldgerät, für ein derartiges Netzwerk
EP1260081B1 (de) Netzwerk mit redundanz-eigenschaften sowie netzwerkteilnehmer, insbesondere feldgerät, für ein derartiges netzwerk
EP3151474B1 (de) Verfahren zur datenkommunikation mit reduziertem overhead in einem echtzeitfähigen ethernet-datennetzwerk
EP3625627B1 (de) Summenstreams für istzustände und steuersignale eines verteilten steuerungssystems
EP3854035B1 (de) Datenübertragungsverfahren und automatisierungskommunikationsnetzwerk
EP1193926A2 (de) Verfahren und System zur Echtzeitkommunikation in einem Netz mit Ethernet-Physik
EP3871377B1 (de) Verteilerknoten, automatisierungsnetzwerk und verfahren zum übertragen von telegrammen
EP3151475B1 (de) Verfahren zur asynchronen datenkommunikation in einem echtzeitfähigen ethernet-datennetzwerk
WO2001058067A1 (de) Uhrzeitsynchronisation in einem netzwerk sowie netzwerkteilnehmer, insbesondere feldgerät, für ein derartiges netzwerk
EP1436950A1 (de) Teilnehmergerät für ein hochperformantes kommunikationssystem
DE102019125545B3 (de) Datenübertragungsverfahren, segment-telegramm und automatisierungskommunikationsnetzwerk
AT517778B1 (de) Verfahren zur Datenkommunikation mit reduziertem Overhead in einem echtzeitfähigen Ethernet-Datennetzwerk
EP3632054B1 (de) Bestimmung von datenbusteilnehmern eines lokalbusses
DE10004426A1 (de) Netzwerkteilnehmer, insbesondere Feldgerät, sowie Netzwerk mit einem derartigen Netzwerkteilnehmer
EP1371185A2 (de) Verfahren und elektronischer schaltkreis für eine skalierbare kommunikationsschnittstelle in automatisierungskomponenten
AT517781B1 (de) Verfahren zur isochronen Datenkommunikation in einem echtzeitfähigen Ethernet-Datennetzwerk

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8131 Rejection