Token Umlaufzeit

Um zu gewährleisten, dass einzelne Stationen nach Ablauf einer maximalen Zeit auf jeden Fall senden können, ist es notwendig, eine Zeitspanne vorzuge­ben, in der der Token den logischen Ring einmal vollständig durchlaufen haben muss.  Eine Zuteilung von festen Sendezeiten an einzelne aktive Stationen scheint wenig sinnvoll, denn bei Teilnehmern ohne Sendewunsch wird Zeit verschwendet, für Teilnehmer mit dringendem Sendewunsch ist die Zeit zu kurz.  Da sich Sendewünsche im Laufe des Busbetriebs ändern, bedarf es einer dynamischen Verteilung der Sendezeit.  Dies wird dadurch realisiert, dass ein aktiver Teilnehmer, wenn er den Token erhält, einen Timer zur Messung der Token-Umlaufzeit startet. Bei der nächsten Tokenübernahme, also nach einem Umlauf, wird der Timer ausgelesen, die gemessene Zeit mit der vorgegebenen, maximalen Soll-Umlaufzeit verglichen und erneut gestartet.  Nur falls die gemessene Zeit kleiner als die vorgegebene Soll-Umlaufzeit ist, darf der aktive Teilnehmer Telegramme senden.

 

Dieses Verfahren hat in dieser Form den Nachteil, dass ohne weitere Massnahme keine Sendezeiten garantiert werden könnten.  Dieser Nachteil wird umgangen, indem zusätzlich einzelnen Nach­richtenzyklen Prioritäten „Low“ oder „High“ zugewiesen werden. Die Dienst mit der „High“ Priorität werden zuerst abgearbeitet.

 

Die minimale Token-Soll-Zeit die in einer Installation eingestellt werden muss wird wie folgt berechnet:

 

min TTR = n ( TTC + TMC ) + k * TMC

n          Anzahl der Master-Stationen

 

Der erste Ausdruck enthält ein hochprioritäres Meldungszyklus pro Master Station und Tokenzirkulation. Somit ist die maximale Reaktionszeit für hochprioritäre Meldungen ohne Wiederholungen für alle Lastverhältnisse garantiert. Der zweite Term enthält die geschätzte Anzahl niederprioritären Telegramme pro Tokenzirkulation.

 

Um die möglichen Wiederholungen zu berücksichtigen ist der minimale Wert um ca. 10 bis 20% grösser zu wählen. Die modernen Konfigurationswerkzeuge für PROFIBUS rechnen aufgrund der Anzahl projektierten Stationen in einem Netzwerk die Token Zirkulationszeit selbständig aus.

 

Hinweis: Soll in einem PROFIBUS Netzwerk im Betrieb später ein zusätzliche Master z.B. für Engineeringaufgaben eingefügt werden, muss die projektierte Token Zirkulationszeit erhöht werden. Von einigen Herstellern wird dabei ein Wert von 20'000 tBit vorgeschlagen.

 

Bei den Diensten der FDL-User-Schnittstelle kann der Anwender grundsätzlich zwischen zwei Prioritäten ("high" und "low") wählen, die mit der Dienstanfor­derung (request) im FC-Byte (frame control, siehe nächstes Kapitel) des Tele­gramms übergeben werden.

 

Um die Übertragung wichtiger Daten zu gewährleisten, darf nach jedem Tokenerhalt stets ein hochpriorer Nachrichtenzyklus abgewickelt werden, selbst wenn eigentlich keine Tokenhaltezeit mehr zur Verfügung steht.  Danach muss allerdings der Token unverzüglich an die nächste Station weitergegeben werden.

 

Ist die aktuelle Tokenumlaufzeit TRR kleiner als die Token-Soll-Umlaufzeit TTR, besteht noch Zeit zur Nachrichtenübermittlung.  Es können weitere hoch­priore und anschliessend niederpriore Dienste abgearbeitet werden.  Innerhalb der niederprioren Dienste gilt folgende Reihenfolge:

1.Bearbeitung der Poll-Liste (zyklische Dienste)

2.Bearbeitung von niederprioren, azyklischen Diensten

3.Teilnehmer-Erfassung (Erstellung der Live-List)

4.Gap-Aktualisierung (maximal eine Adresse der Gap-Liste)