Diagnose auf Application-Layer-Ebene

Der Application Layer betrifft die spezielle Funktion eines jeden Slaves: Lesen eines Temperatursignals, Steuerung pneumatischer Servoventile oder etwa der Antrieb eines Motors. Eine von mehreren aussagestarken Diagnoseinformationen basiert dabei auf der Ethercat-State-Machine, die das Verhalten zwischen Master und Slaves organisiert. Jeder Status korrespondiert mit einer Reihe verfügbarer Kommunikationsfunktionalitäten. Statuswechsel werden vom Master gefordert und vom jeweiligen Slave bestätigt oder abgelehnt. Bei Konfigurationsfehlern während des Hochlaufs oder internen Laufzeitfehlern verweigert der Slave entweder den Statusübergang oder wechselt intern auf einen niedrigeren Status, setzt ein Fehler-Bit und stellt einen Fehler-Code zur Verfügung. Ein Beispiel für diese Diagnosefunktion tritt ein, wenn sich die Prozessdatenkonfigurationen von Master und Slave unterscheiden: Der Slave wird einen Statusübergang nach Safe-Operational mit dem Fehler-Code „Invalid Input Configuration“ verweigern.

Ein weiteres Beispiel ist gegeben, wenn der Slave für eine bestimmte Zeit keine gültigen Prozessdaten erhält: Er wechselt seinen Status dann zu Safe-Operational und meldet den Fehler „Prozessdaten- Watchdog“. Das Application-Layer-Statusregister kann vom Master mit einem einzigen Broadcast-Kommando zyklisch ausgelesen werden, um den gesamten Netzwerkstatus zu überwachen. Neben der zentralen Diagnosemöglichkeit über die Ethercat- State-Machine sind Ethercat-Geräte in der Lage, spezifische interne Applikationsfehler zu melden. Diese hängen von der jeweiligen Funktion des Slaves ab: Das kann eine Überspannung für ein analoges Input-Terminal sein, die den maximalen Drehmomentgrenzwert für einen Antrieb überschreitet, oder ein interner Überhitzungsalarm. CAN Application Protocol over Ethercat (CoE), das Standard-Ethercat- Protokoll für den azyklischen Parameterzugriff, definiert das Diagnosis History Object, welches wie ein Fehlerspeicher funktioniert: Innerhalb dieses Objects können Geräte bis zu 250 applikationsspezifische Diagnosemeldungen aufzeichnen und speichern, die wiederum vom Master gelesen und dem Anwender gemeldet werden können.

Fazit

Ausgeprägte Ethercat-Diagnosefunktionalitäten sind auf allen Ebenen der Ethercat-Kommunikation vorhanden. Sie liefern ein umfassendes und detailliertes Bild vom Netzwerkstatus. Sie sind bereits nativer Teil des Ethercat-Protokolls und können darüber hinaus vom Master mit einer geringen Anzahl zusätzlicher Kommandos zusammengefasst werden. Letztlich sind die Mechanismen zur Diagnose bei Ethercat in Hardware implementiert oder aber in der Basisspezifikation von Ethercat definiert: Die Unterstützung aller zugehörigen Funktionen ist somit für alle Ethercat-Geräte gleichermaßen gewährleistet. (ih)