LösenAnheftenSchließen

01.09.2020

Master-unabhängige Diagnoseschnittstelle für EtherCAT-Netzwerke

Neu: Spezifikation ETG.1510 „Profile for Master Diagnosis Interface“

Diagnoseeigenschaften sind für den Erfolg einer Feldbustechnologie von zentraler Bedeutung. Um die Diagnose in EtherCAT-Netzwerken noch besser zu machen, hat die EtherCAT Technology Group (ETG) mit der Spezifikation ETG.1510 „Profile for Master Diagnosis Interface“ eine herstellerunabhängige Diagnoseschnittstelle definiert, welche es dem EtherCAT-Master auf nutzerfreundliche und standardisierte Weise ermöglicht, detaillierte Informationen zur Netzwerkdiagnose sowie zum Systemzustand für Tools von Drittanbietern zur Verfügung zu stellen.

In der heutigen Industrie gehört die durchgängige Verfügbarkeit von Maschinen und Anlagen zu den wichtigsten Faktoren in Bezug auf Effizienz und Wettbewerbsfähigkeit. EtherCAT hat sich hier nicht zuletzt aufgrund seiner robusten Kommunikationsinfrastruktur als zuverlässige Technologie bewahrt. Nichtsdestotrotz können industrielle Umgebungen selbst für die zuverlässigsten Kommunikationstechnologien wie EtherCAT herausfordernd sein. Sich permanent bewegende Maschinenteile oder kontinuierliche Vibrationen können vorübergehende Leitungsverluste oder langfristig sogar Kabelbruche verursachen, während EMV-Störungen sich gerade auf dem Kommunikationspfad befindende Signale verfälschen können. In all diesen Fällen sind es die Diagnosefähigkeiten des Feldbusses, die Fehler erkennen, lokalisieren und deren mögliche Ursachen ergründen müssen. Je besser sie funktionieren, desto kurzer sind die Ausfallzeiten einer Maschine.

Alessandro Figini, EtherCAT-Technology-Experte, ETG
Alessandro Figini, EtherCAT-Technology-Experte, ETG

Die EtherCAT-Technologie verfügt über ganz besondere Diagnoseeigenschaften, die über die entsprechenden Fähigkeiten des herkömmlichen Ethernet weit hinausgehen. Dabei werden die nötigen Informationen entweder über die EtherCAT-Kommunikationschips (ESC) direkt in Hardware oder aber mittels Software-Funktionalitäten zur Verfügung gestellt.

Auf Slave-Seite sind daher keine speziellen Erweiterungen erforderlich. Jedes EtherCAT-Datenpaket endet mit einem 16-bit-Working-Counter-Feld, welches von allen vom Datagramm selbst adressierten Slave-Geräten inkrementiert wird. Unstimmigkeit zwischen dem erwarteten und dem tatsachlich erhaltenen Wert des Working Counter bedeutet, dass nicht alle Slave-Geräte das Datagramm erfolgreich verarbeitet haben und daher nicht mit konsistenten Daten im aktuellen Zyklus arbeiten. Dies kann eine direkte Fehlerreaktion in der Steuerung („Master“) anstoßen. Ist das der Fall, werden Eingangsdaten, die das Datagramm transportiert, verworfen. Der Master kann azyklisch zusätzliche Informationen abrufen und ermöglicht so die Lokalisierung sowie die Erkennung etwaiger Gründe für das Kommunikationsproblem.

Auf der Hardware-Seite überwacht und erkennt jeder EtherCAT Slave Controller einen Leitungsverlust genauso wie eine Signalunterbrechung auf jedem Port und inkrementiert entsprechend den korrespondierenden Link Lost Counter oder RX Error Counter.

Auf der Software-Seite hingegen können Kommunikationsfehler wie z. B. ein abgelaufener Watchdog auf den zyklischen Daten oder ein Synchronisationsverlust innerhalb des Netzwerks einen unerwarteten Zustandsübergang in der EtherCAT State Machine auslösen. Diese Fehler werden vom AL Status Code angezeigt, welcher vom Software Stack zurückgegeben wird, wann immer ein unerwarteter Zustandsübergang eintritt. Dem Master in allen EtherCAT-Netzwerken stehen somit alle notwendigen Diagnoseinformationen zur Verfügung, um den Netzwerkstatus zu überwachen sowie Fehler erkennen und lokalisieren zu können.

Zur Auswertung und Nutzung müssen diese „rohen“ Daten an Diagnose-Tools sowie Anwender weitergegeben werden. Mit der Spezifikation ETG.1510 „Profile for Master Diagnosis Interface“ hat die EtherCAT Technology Group eine Lösung definiert, die es externen Tools ermöglicht, unabhängig vom Master-Hersteller sowie der Software-Implementierung auf die vom EtherCAT-Netzwerk zur Verfügung gestellten Diagnoseinformationen zuzugreifen. Die ETG.1510 erweitert die Spezifikation ETG.1500 „EtherCAT Master Classes”. Die Diagnoseinformation wird in das EtherCAT-Objektverzeichnis abgebildet, welches in der ETG.1500 definiert und zu diesem Zweck ergänzt wurde. Dies bedeutet insbesondere, dass Objekte im Indexbereich 0x8000 die Netzwerkstruktur wie vom Master erwartet basierend auf der Offline-Konfiguration beschreiben, während Objekte im Bereich 0x9nnn die aktuelle Netzwerktopologie anzeigen, wie sie mittels eines Online-Scans festgestellt wurde. Die Diagnoseinformation selbst ist im Indexbereich 0xAnnn in Form von konsistenten, kumulativen Zahlern abgebildet, welche den Netzwerkstatus vom Systemstart bis zum gegenwärtigen Zeitpunkt zusammenfassen. So kann mit einer Frequenz auf die Diagnoseschnittstelle zugegriffen werden, welche unabhängig von der Zykluszeit des EtherCAT-Netzwerks ist, und externe Tools müssen keine Echtzeitleistung erbringen.

Der Zugriff auf die Diagnoseinformationen erfolgt über das bewahrte „CAN application protocol over EtherCAT“ (CoE). Die CoE-Dienste werden in der Steuerung mithilfe der Standard-Mailbox-Gateway-Funktionalität über das Master-Objektverzeichnis geroutet, welche in der Spezifikation ETG.8400 beschrieben ist. Basierend auf bereits existierenden und vollständig standardisierten Protokollen und Funktionalitäten kann die Diagnoseschnittstelle damit einfach als schlanke Software-Erweiterung zusätzlich zu jeder Standard-Master- Implementierung realisiert werden. Die benötigten Ressourcen einer solchen Software-Erweiterung sind sehr gering, weshalb sich die Diagnoseschnittstelle für alle Master-Lösungen inklusive einfacher und kompakter Embedded-Systeme eignet. Dank der EtherCAT-Diagnoseschnittstelle, welche mit der Spezifikation ETG.1510 eingeführt wurde, können Anbieter von Maschinen- und Netzwerkdiagnose- Tools eine universelle Schnittstelle zum Sammeln von Diagnosedaten aus EtherCAT-Netzwerken nutzen. Sie können diese Informationen anwenderfreundlich und grafisch intuitiv an Techniker und Ingenieure weitergeben, ohne dabei jedes Mal herstellerspezifisch den Master berücksichtigen oder das Zugriffsprotokoll für jede unterschiedliche Master-Implementierung anpassen zu müssen.

Weitere Informationen