In Ethercat-Netzwerken leiten die Slaves die Ethernet-Frames mittels einer dedizierten Echtzeit-Komponente, des ESC (Ethercat Slave Controller), weiter. Die Slaves verfügen über Diagnosemechanismen auf allen in den Feldbusstandards spezifizierten Ebenen des ISO/OSI-Stacks. Die Weiterleitung der Statusinformation aus den einzelnen Slaves erfolgt über den Master beziehungsweise das Konfigurations-Tool, welche direkt an das Applikationsprogramm oder den Anwender berichten.

Diagnose auf Physical-Layer-Ebene

Die Physical-Layer-Ebene umfasst im Wesentlichen Kabel und Stecker zum Aufbau der Netzwerkinfrastruktur. Jeder ESC-Port überwacht die Kommunikation auf Hardware-Ebene, indem er relevante Informationen an den Nutzer weitergibt. So erkennen die ESC-Ports neben verschiedenen weiteren Fehlern auch Link-Lost-Ereignisse und inkrementieren einen entsprechenden Link Lost Counter.

Fehler können hier etwa durch lose Kontakte, schlechte Verbindung oder beschädigte Kabel auftreten. Durch Auslesen der zugehörigen Register kann man präzise die Störung lokalisieren.

Eine weitere Diagnosefunktion ist die CRC-Prüfung (Prüfsumme) der ankommenden Frames: Bei Misserfolg wird der betroffene Frame als beschädigt markiert, die in ihm enthaltenen Daten ignoriert und CRC Error Counter inkrementiert. Nachfolgende Geräte ignorieren die Daten dieses Frames ebenfalls und inkrementieren dafür einen Forwarded CRC Error Counter.

CRC-Fehler werden typischerweise durch EMV-Störungen hervorgerufen, wie sie bei stromführenden Leitungen auftreten, welche nahe am Kommunikationskabel verlaufen. Durch das Auslesen der Register beider Fehlerzähler kann der Nutzer auch in diesem Fall die Stelle lokalisieren, wo mögliche EMV-Einflüsse die Kommunikation beeinträchtigt haben.

Diagnose auf Datalink-Layer-Ebene

Der Datalink-Layer garantiert den Datenaustausch zwischen dem Ethercat-Frame und dem Ethercat-Teilnehmer. Dieser Austausch kann azyklisch als auch zyklisch sein. Letzerer kann auch synchron zwischen mehreren verteilten Teilnehmern gesteuert werden. In den Slaves werden Datenaustausch und Synchronisierung durch Interrupts oder Watchdogs überwacht.

Einer der effektivsten zentralen Diagnosemechansimen auf dem Datalink-Layer ist der Working Counter, welcher mit jedem Lese- und Schreibkommando übertragen wird. Dieser Zähler inkrementiert nach erfolgreichem Datenaustausch in jedem durchlaufenen Slave. Durch Vergleich der tatsächlichen mit den erwarteten Werten prüft der Master noch im gleichen Zyklus, ob alle Slaves mit konsistenten Daten arbeiten oder einzelne Datagramme nicht übertragen wurden.

Der Working Counter gibt so Aufschluss über verschiedene mögliche Fehler, etwa wenn ein Slave aufgrund fehlender Konnektivität oder interner Hardware-Ausfälle Daten nicht austauschen kann. Auch Probleme bei der Parametrisierung, welche die Prozessdatenkonfiguration oder das Kommunikations-Timing einschließen, werden so erkannt.

Working-Counter-Fehler werden vom Master an eine überlagerte Anwendung wie ein SPS-Programm weitergegeben, sodass der Applikateur in der Software eine passende Reaktion programmieren kann.

In Applikationen, die ein hohes Maß an Synchronität ihrer Komponenten erfordern, wird innerhalb des Ethercat-Netzwerks die Distributed-Clocks-Funktionalität (DC) eingesetzt. Auch für diese Datalink-Layer-Funktionalität gibt es verschiedene Diangose-Mechanismen. So verfügt jeder Slave über ein System Time-Difference-Register, welches die Differenz zwischen der lokalen Uhr im Slave sowie der globalen Netzwerkzeit enthält. Durch Auslesen dieses Registerwerts aus allen Slaves, welche den Mechanismus der verteilten Uhren (DC) nutzen, kann der Master stets überwachen, wie präzise das Netzwerk synchronisiert ist und den Nutzer über Unregelmäßigkeiten informieren.

Da Ethercat Standard-Ethernet-Frames nutzt, kann der Netzwerkstatus durch die Überwachung des Netzwerkverkehrs mittels kostenfreier Software Tools wie etwa Wireshark erfolgen. So können ganze Ethercat-Frames sowie sämtliche Datagramme innerhalb derselben aufgezeichnet, angezeigt und analysiert werden.

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 Diagnoseinformation 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 Fehlerbit 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 SafeOperational 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 SafeOperational 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 können Ethercat-Gerätespezifische interne Applikationsfehler 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 etwa 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, welche 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 und bieten dadurch ein umfassendes und detailliertes Bild des Netzwerkstatus‘. Sie sind 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.  

Sie möchten gerne weiterlesen?