DE10004425A1 - Netzwerk sowie Netzwerkteilnehmer, insbesondere Feldgerät, für ein derartiges Netzwerk - Google Patents
Netzwerk sowie Netzwerkteilnehmer, insbesondere Feldgerät, für ein derartiges NetzwerkInfo
- 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
Links
- 230000005540 biological transmission Effects 0.000 title claims abstract description 87
- 230000001934 delay Effects 0.000 title description 4
- 238000012546 transfer Methods 0.000 claims description 8
- 230000004044 response Effects 0.000 claims description 6
- RTZKZFJDLAIYFH-UHFFFAOYSA-N Diethyl ether Chemical compound CCOCC RTZKZFJDLAIYFH-UHFFFAOYSA-N 0.000 claims description 4
- 238000012545 processing Methods 0.000 claims description 2
- 230000007704 transition Effects 0.000 abstract 2
- 238000004891 communication Methods 0.000 description 76
- 239000003999 initiator Substances 0.000 description 34
- 239000000872 buffer Substances 0.000 description 24
- 230000006870 function Effects 0.000 description 17
- 238000000034 method Methods 0.000 description 17
- 230000008901 benefit Effects 0.000 description 16
- 230000008569 process Effects 0.000 description 6
- 230000032683 aging Effects 0.000 description 5
- 238000012360 testing method Methods 0.000 description 5
- 238000007726 management method Methods 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 230000006399 behavior Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000010354 integration Effects 0.000 description 3
- 238000005259 measurement Methods 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 230000001360 synchronised effect Effects 0.000 description 3
- 238000001514 detection method Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- LZZYPRNAOMGNLH-UHFFFAOYSA-M Cetrimonium bromide Chemical compound [Br-].CCCCCCCCCCCCCCCC[N+](C)(C)C LZZYPRNAOMGNLH-UHFFFAOYSA-M 0.000 description 1
- 101100130497 Drosophila melanogaster Mical gene Proteins 0.000 description 1
- 241000196324 Embryophyta Species 0.000 description 1
- 101100172132 Mus musculus Eif3a gene Proteins 0.000 description 1
- 101100345589 Mus musculus Mical1 gene Proteins 0.000 description 1
- 235000010678 Paulownia tomentosa Nutrition 0.000 description 1
- 240000002834 Paulownia tomentosa Species 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000005611 electricity Effects 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000003455 independent Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000012804 iterative process Methods 0.000 description 1
- 210000003734 kidney Anatomy 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000007781 pre-processing Methods 0.000 description 1
- NQLVQOSNDJXLKG-UHFFFAOYSA-N prosulfocarb Chemical compound CCCN(CCC)C(=O)SCC1=CC=CC=C1 NQLVQOSNDJXLKG-UHFFFAOYSA-N 0.000 description 1
- 230000000630 rising effect Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000001502 supplementing effect Effects 0.000 description 1
- 238000012549 training Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04J—MULTIPLEX COMMUNICATION
- H04J3/00—Time-division multiplex systems
- H04J3/02—Details
- H04J3/06—Synchronising arrangements
- H04J3/0635—Clock or time synchronisation in a network
- H04J3/0638—Clock or time synchronisation among nodes; Internode synchronisation
- H04J3/0658—Clock or time synchronisation among packet nodes
- H04J3/0661—Clock or time synchronisation among packet nodes using timestamps
- H04J3/0664—Clock or time synchronisation among packet nodes using timestamps unidirectional timestamps
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04J—MULTIPLEX COMMUNICATION
- H04J3/00—Time-division multiplex systems
- H04J3/02—Details
- H04J3/06—Synchronising arrangements
- H04J3/0635—Clock or time synchronisation in a network
- H04J3/0679—Clock or time synchronisation in a network by determining clock distribution path in a network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/407—Bus networks with decentralised control
- H04L12/413—Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04J—MULTIPLEX COMMUNICATION
- H04J3/00—Time-division multiplex systems
- H04J3/02—Details
- H04J3/06—Synchronising arrangements
- H04J3/0635—Clock or time synchronisation in a network
- H04J3/0638—Clock or time synchronisation among nodes; Internode synchronisation
- H04J3/0658—Clock or time synchronisation among packet nodes
- H04J3/0661—Clock or time synchronisation among packet nodes using timestamps
- H04J3/0667—Bidirectional timestamps, e.g. NTP or PTP for compensation of clock drift and for compensation of propagation delays
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04J—MULTIPLEX COMMUNICATION
- H04J3/00—Time-division multiplex systems
- H04J3/02—Details
- H04J3/06—Synchronising arrangements
- H04J3/0635—Clock or time synchronisation in a network
- H04J3/0638—Clock or time synchronisation among nodes; Internode synchronisation
- H04J3/0658—Clock or time synchronisation among packet nodes
- H04J3/0673—Clock 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L2012/4026—Bus for use in automation systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/28—Timers or timing mechanisms used in protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer 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.
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.
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.
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.
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)
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)
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 |
-
2000
- 2000-02-02 DE DE2000104425 patent/DE10004425A1/de not_active Ceased
Patent Citations (3)
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)
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 | |
EP2961106B1 (de) | Netzwerk, kopf-teilnehmer und datenübertragungsverfahren | |
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 | |
WO2019007516A1 (de) | Verfahren zur performanten datenübertragung in einem datennetz mit teilweise echtzeit-anforderungen und vorrichtung zur durchführung des verfahrens | |
WO2019081230A1 (de) | Datenübertragungsverfahren und kommunikationsnetzwerk | |
DE102004050424B4 (de) | Verfahren zur Übertragung von Daten in einem Kommunikationssystem | |
EP3625627B1 (de) | Summenstreams für istzustände und steuersignale eines verteilten steuerungssystems | |
DE10004425A1 (de) | Netzwerk sowie Netzwerkteilnehmer, insbesondere Feldgerät, für ein derartiges Netzwerk | |
EP3871377B1 (de) | Verteilerknoten, automatisierungsnetzwerk und verfahren zum übertragen von telegrammen | |
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 | |
EP3854035B1 (de) | Datenübertragungsverfahren und automatisierungskommunikationsnetzwerk | |
EP1193926A2 (de) | Verfahren und System zur Echtzeitkommunikation in einem Netz mit Ethernet-Physik | |
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 | |
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 | |
WO2002078264A2 (de) | Verfahren und elektronischer schaltkreis für eine skalierbare kommunikationsschnittstelle in automatisierungskomponenten | |
AT517781B1 (de) | Verfahren zur isochronen Datenkommunikation in einem echtzeitfähigen Ethernet-Datennetzwerk | |
WO2002078252A2 (de) | Elektronischer schaltkreis und verfahren für eine kommunikationsschnittstelle mit cut-through pufferspeicher |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
OP8 | Request for examination as to paragraph 44 patent law | ||
8131 | Rejection |