Abgesetzte industrielle Antriebssysteme

Ob virtuelle Steuerungen für zentralgerechnete Motion-Aufgaben geeignet sind, entscheidet sich also vor allem bei der Kommunikation zwischen Steuerung und Antrieb. In hardwareunabhängigen Systemen wie Codesys werden die Befehle und Services des Protokollstacks in Bibliotheksbausteinen implementiert, abstrahiert von der tatsächlich eingesetzten Hardware (Bild 2). Dieser Code wird mithilfe integrierter Compiler der Entwicklungsumgebung zusammen mit der SPS-Applikation implizit in nativen Maschinencode für die CPU der eingesetzten Steuerung übersetzt. Lediglich bei der Übersetzungsdauer und Codegröße bemerkt man, dass jetzt zusätzlich zum selbst erstellten Logikprogramm auch noch das Feldbusprotokoll im Kompilat enthalten ist.

Damit dieser Code zusätzlich zykluskonsistent zur SPS-Applikation ausgeführt werden kann, muss zum einen das Antriebssystem im Programmiertool richtig konfiguriert sein. Das beinhaltet abhängig vom eingesetzten System Parameter wie Netzwerkadressen, busspezifische Einstellungen sowie technische Eigenschaften der eingesetzten Achsen und Motoren, wie Getriebeübersetzung, Achstypen und -grenzen sowie deren Dynamik. Zum anderen muss eine Motion-Task im Projekt mit passender Zykluszeit und Priorität angelegt sein, damit Antriebe sowie Motoren ihre Sollwerte pünktlich bekommen und rund laufen. Per Definition dürfen dabei die Kabellängen, z. B. für Ethercat, eine Länge von maximal 100 m aufweisen. Wenn gleichzeitig die Anzahl der angesteuerten Antriebe eine Menge von 10 bis 20 nicht übersteigt, sind in der Regel keine weiteren Maßnahmen bzw. Geräte wie zusätzliche Switches oder Verstärker erforderlich. Neben den harten Echtzeiteigenschaften von Ethercat ist dies ein Grund für die hohe Verbreitung des Systems.

Motion-Control-Kommunikation über große Distanzen

Was aber, wenn virtuelle Steuerungen in einem nahegelegenen Rechenzentrum betrieben werden, bei dem die benötigten Kabellängen über das Limit gehen? Oder wenn sehr viele Antriebe angesteuert oder zusätzlich zur Ethercat-Kommunikation noch weitere Daten im Bus ausgetauscht werden müssen, z. B. für ein Vision-System? Dafür gibt es spezielle Hardware von Ethercat-Anbietern, welche die Daten über Lichtwellenleiter (LWL) übertragen und damit große Distanzen bis zu mehreren Kilometern überbrücken. So lassen sich Motion-Anwendungen mit virtuellen Steuerungen realisieren, die beispielsweise im abgesetzten Serverraum ausgeführt werden.

Kompliziert wird es, wenn vor Ort an der Maschine gleichzeitig ältere Bustechnologien mit Sensoren und Aktoren verbaut sind, deren Daten man nicht ohne weiteres in den Motion-Control-Bus einbetten kann. Es ist unerlässlich, diese Daten ebenfalls über den LWL zu übertragen. Technisch machbar ist es, diese Daten über spezielle Protokolle parallel zu Ethercat zu verpacken und über den LWL zu verschicken. Wenn die Einbettung der Daten im Silizium passiert, also in integrierten Schaltkreisen (Asic), dann können diese Daten verlustfrei in nahezu beliebigen Frequenzen gleichzeitig über den LWL übertragen werden.

Genau das verspricht ein Ansatz mit dem Arbeitstitel Robo/TSN von Missing Link Electronics [3]. Es fasst Daten unterschiedlicher Bussysteme per Field Programmable Gate Array (FPGA) zusammen und überträgt diese deterministisch (Bild 3). Abhängig vom Medium, typischerweise LWL, können damit mehrere hundert Gigabit an Daten im Nanosekundenbereich übertragen werden. In einem patentierten Verfahren werden die Daten derart getunnelt, dass alle Eigenschaften und Informationen des ursprünglichen Systems erhalten bleiben: Funktional sichere Protokolle wie FSoE (Fail Safe over Ethercat) oder Profisafe können also problemlos genutzt werden. Aufgrund der Kapselung lassen sich die Feldbusinformation sogar in offenen IT-Netzen sicher nach der Normenreihe IEC 62443 [4] übertragen.

Wichtig für User von Motion- und SPS-Systemen wie Codesys: Im Gegensatz zu anderen LWL-Systemen ändern sich Bedienung und Konfiguration durch diese Art des Datentunnelns nicht. In ersten Tests wurde z. B. die Codesys-Motion-Applikation genau wie bisher konfiguriert: Ein verfügbarer Ethernet-Port wird zum Ethercat-Master samt angeschlossenen E/A und Antrieben. Bei der Konfiguration merkt man nicht, dass dieser Port durch Robo/TSN getunnelt wird. Auch die erwähnte weitere Parametrierung und Projektierung ändert sich nicht im Vergleich zur Nutzung an einem Standard-Ethernet-Port. Was sich ändert, ist die Netzwerkkarte: Sie beinhaltet den entsprechenden Asic und stellt Ethernet- und andere Kommunikationsports zur Verfügung. Intern tunnelt sie die konfigurierten Daten und überträgt sie über das angeschlossene Medium, um dann an der Gegenstelle durch eine PCIe-Netzwerkkarte wieder entpackt und wie ursprünglich bereitgestellt zu werden (Bild 4). Sowohl am Hostrechner, auf dem virtuelle Steuerungen betrieben werden, als auch im abgesetzten Schaltschrank oder in den Maschinenteilen, in denen die entsprechenden Endgeräte betrieben werden, sind die mit dem Asic ausgestatteten Karten erforderlich.

Fazit

Bei virtuellen Steuerungen ergibt sich aus der räumlichen Trennung von den zu Grunde liegenden Rechnersystemen und den erforderlichen Antrieben für Bewegungssteuerung und Robotik eine Herausforderung. Doch sind diese Herausforderungen lösbar – abhängig vom Anwendungsfall und den genutzten Komponenten durch den Einsatz von Standards wie Ethercat und SRCI oder durch die Nutzung von Lichtwellenleitern als Übertragungsmedium. Durch moderne, integrierte Schaltkreise ändert sich die Projektierung gegenüber lokalen Systemen nicht. Damit ist klar: Virtualisierte Steuerungstechnik ist für alle Anwendungsbereiche einsetzbar.                                                         

Literatur

1. IEC 61508: Functional safety of electrical/electronic/programmable electronic safety-related systems. Genf/Schweiz: Bureau Central de la Commission Electrotechnique Internationale
2. Codesys GmbH, Memmingen: www.codesys.com
3. Missing Link Electronics GmbH, Neu-Ulm: www.missinglinkelectronics.com
4. IEC 62443: Security for industrial automation and control systems. Genf/Schweiz: Bureau Central de la Commission Electrotechnique Internationale