Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03452.jsonl.gz/687

Alle für die geregelte Abwicklung der Kommunikation notwendigen Zustände der MAC-Steuerung gehen aus der untenstehenden Abbildung hervor. Da die jeweiligen Zustände in der Norm (IEC 61158-4-3 Abschnitt 8.2) ausführlich beschrieben sind, soll hier nur ein grober Überblick gegeben werden.
Nach dem Einschalten der Betriebsspannung (Power ON) gelangen sowohl aktive als auch passive Busteilnehmer in den Zustand 0ffline, führen einen Selbsttest durch und laden die für die Kommunikation notwendigen Betriebsparameter. Passive Teilnehmer gehen danach in den Zustand Passive Idle, in dem sie nach Aktivieren ihres Empfängers die Leitung passiv abhören. Falls Telegramme mit der eigenen Stationsadresse erkannt werden, müssen sie von der Station ordnungsgemäss quittiert werden.
Aktive Busteilnehmer nehmen nach dem Zustand Offline den Zustand Listen Token ein, falls sie für die Aufnahme in den logischen Ring bereit sind. Im Zustand Listen Token hört der Teilnehmer die Telegramme auf der Busleitung ab und baut aus den empfangenen Token-Telegrammen zunächst eine Liste der bereits aktiven Teilnehmer (LAS: List of Active Stations) auf. Nach dem Aufbau der LAS muss die Station warten, bis sie von der Vorgängerstation mit einem "Request FDL-Status" angesprochen und in den logischen Ring "eingeladen" wird. Der "Neuling" quittiert mit einem "bereit für den Ring" und geht über in den Zustand Active Idle. Er ist somit offizieller Teilnehmer im Ring. In diesem Zustand hört er die Leitung ab, quittiert und antwortet ebenso wie ein passiver Teilnehmer im Zustand Passive Idle. Der aktive Teilnehmer wechselt nach Erhalt eines an ihn gerichteten Token-Telegramms in den Zustand Use Token. Erhält der aktive Teilnehmer über längere Zeit kein TokenTelegramm, so geht er in den Zustand Claim Token, um den logischen Ring neu zu initialisieren bzw. zu reinitialisieren (Im letzteren Fall behält die LAS ihre Gültigkeit).
Bild 122: FDL Zustandsdiagramm
Im Normalfall kommt jedoch der aktive Teilnehmer innerhalb einer bestimmten Zeit in den Besitz des Token-Telegramms, so dass, nachdem im Zustand Check Access Time die noch zur Verfügung stehende Token-Haltezeit überprüft wurde, im Use Token-Zustand Nachrichtenzyklen abgewickelt werden können. Wird zur Kommunikation ein Dienst mit Rückantwort verwendet, geht der Teilnehmer in den Zustand Await - Data - Response und wartet für die Slot-Time (abhängig von der Bitrate) auf eine Rückmeldung. Bleibt die erwartete Antwort aus, so wird nach einer durch den Parameter max_retry_limit bestimmten Anzahl von nochmaligen Sendeversuchen eine Fehlermeldung an den User ausgelöst.
Nachrichtenzyklen können so lange abgewickelt werden, bis die Token-Haltezeit abgelaufen ist. Danach wechselt der Teilnehmer in den Zustand Pass Token, in welchem der Token an den nächsten aktiven Teilnehmer weitergegeben wird. Die Übergabe wird im Zustand Check Token Pass überwacht. Geht bei der Tokenweitergabe etwas schief, weil sich z.B. der Nachfolger nicht meldet, wechselt der Teilnehmer in den Await - Status - Response Zustand über und wartet dort eine bestimmte Zeit auf ein Quittungssignal. Kommt dieses Signal nicht, wird der Aufruf im Pass Token - Zustand wiederholt. Erhält der Teilnehmer ein anderes Telegramm (Situation bei Mehrfachtoken), geht er in den Zustand Active Idle über. Nach der - normalerweise fehlerfreien - Tokenweitergabe befindet sich der Teilnehmer bis zum nächsten Empfang des Tokens im Zustand Active Idle.