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 bewährt. 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 Kabelbrüche 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 kürzer sind die Ausfallzeiten einer Maschine.
Mehr als herkömmliches Ethernet
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 Geräteseite sind daher keine speziellen Erweiterungen erforderlich. Jedes Ethercat-Datenpaket endet mit einem 16-Bit-Working-Counter-Feld, das von allen vom Datagramm selbst adressierten Geräten inkrementiert wird. Unstimmigkeit zwischen dem erwarteten und dem tatsächlich erhaltenen Wert des Working Counter bedeutet, dass nicht alle gekoppelte 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 anstoßen. Ist das der Fall, werden Eingangsdaten, die das Datagramm transportiert, verworfen. Die Steuerung 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, der vom Software Stack zurückgegeben wird, wann immer ein unerwarteter Zustandsübergang eintritt.
Diagnose unabhängig von der Zykluszeit
Der Steuerung 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 Steuerungshersteller 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, das in der ETG.1500 definiert und zu diesem Zweck ergänzt wurde. Dies bedeutet insbesondere, dass Objekte im Indexbereich 0x8000 die Netzwerkstruktur wie von der Steuerung 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 Zählern abgebildet, die den Netzwerkstatus vom Systemstart bis zum gegenwärtigen Zeitpunkt zusammenfassen. So kann mit einer Frequenz auf die Diagnoseschnittstelle zugegriffen werden, die 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 bewährte ‚CAN application protocol over Ethercat‘ (CoE). Die CoE-Dienste werden in der Steuerung mithilfe der Standard-Mailbox-Gateway-Funktionalität über das Objektverzeichnis der Steuerung geroutet, das 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-Steuerungsimplementierung realisiert werden. Die benötigten Ressourcen einer solchen Software-Erweiterung sind sehr gering, weshalb sich die Diagnoseschnittstelle für alle Steuerungslösungen inklusive einfacher und kompakter Embedded-Systeme eignet.
Fazit
Dank der Ethercat-Diagnoseschnittstelle, die 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 die Steuerung berücksichtigen oder das Zugriffsprotokoll für jede unterschiedliche Steuerungsimplementierung anpassen zu müssen.
