A A A
| Sitemap | Kontakt | Impressum | Datenschutz
ETZ Logo VDE Verlag Logo

Diagnose und Fehlerlokalisierung mit Ethercat

01 Die logische Weiterleitung der Ethernet- Frames erfolgt mittels des ESC (Ethercat-Slave-Controller)

02 Das Auslesen des Link Lost Counters ermöglicht die exakte Lokalisierung von Fehlern auf Hardwareebene

03 Jeder Port führt eine CRC-Prüfung der ankommenden Frames durch und inkrementiert gegebenenfalls einen Fehlerzähler

04 Mittels des Working Counters kann der Ethercat-Master einfach und zyklussynchron die Anwendung auf Fehler überprüfen

Die lückenlose Verfügbarkeit sowie die Zeit zur Inbetriebnahme einer Anlage werden durch die Diagnoseeigenschaften des zugrunde liegenden Kommunikationssystems determiniert, wobei auch die exakte Lokalisierung von Fehlern eine große Rolle spielt. Ethercat unterstützt systeminhärent zahlreiche Diagnoseeigenschaften.

In Ethercat-Netzwerken leiten die Slaves die Ethernet- Frames entsprechend der durch die Hardware vorgegebenen Topologie mittels einer dedizierten Echtzeit-Komponente, des sogenannten ESC (Ethercat Slave Controller) weiter (Bild 1). 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 bzw. das Konfigurations-Tool, welche direkt an das Applikationsprogramm bzw. den Anwender berichten.

Diagnose auf Physical-Layer-Ebene
Die Physical-Layer-Ebene umfasst im Wesentlichen Leitungen und Stecker zum Aufbau der Netzwerkinfrastruktur. Jeder ESC-Port überwacht die Kommunikation auf Hardwareebene, 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 Leitungen entstehen. Durch Auslesen der zugehörigen Register lässt sich die Störung des physikalischen Mediums präzise lokalisieren (Bild 2). 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 der CRC Error Counter inkrementiert (Bild 3). 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 Strom führenden Leitungen auftreten, die nahe der Kommunikationsleitung verlaufen. Durch das Auslesen der Register beider Fehlerzähler kann der Nutzer auch in diesem Fall die Stelle lokalisieren, an der mögliche EMV-Einflüsse die Kommunikation beeinträchtigt haben.

Diagnose auf Data-Link-Layer-Ebene
Der Data Link Layer garantiert den Datenaustausch zwischen dem Ethercat-Frame und dem Ethercat-Teilnehmer. Dieser Austausch kann sowohl azyklisch als auch zyklisch sein. Letzterer kann auch zyklisch synchron zwischen mehreren verteilten Teilnehmern gesteuert werden. In den Slaves werden Datenaustausch und Synchronisierung durch Interrupts oder Watchdogs überwacht. Einer der effektivsten zentralen Diagnosemechanismen auf dem Data Link 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 das Vergleichen 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 Hardwareausfä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 entsprechende Reaktion programmieren kann (Bild 4).

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 Data-Link-Layer- Funktionalität gibt es verschiedene Diagnosemechanismen. 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, ist es möglich, den Netzwerkstatus durch die Überwachung des Netzwerkverkehrs mittels kostenfreier Software-Tools wie Wireshark einzusehen. 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 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)

Der Beitrag als pdf

Autoren:
Alessandro Figini arbeitet bei der Ethercat Technology Group (ETG) im Bereich Technologiesupport und Test. a.figini@ethercat.org

Florian Häfele arbeitet bei der Ethercat Technology Group (ETG) im Bereich Technologiesupport und Test. f.haefele@ethercat.org