Virtuelle Steuerungen für Motion+Robotik
Ist Echtzeit-Motion-Control mit virtuellen Steuerungen möglich?
Die Automatisierung mit virtuellen Steuerungen verspricht gegenüber herkömmlicher Steuerungstechnik erhebliche Einsparpotenziale bei Beschaffung, Wartung und Betrieb. Aber wie sieht es mit Anwendungen aus, in denen koordinierte Verfahrbewegungen hohe Anforderungen an das Echtzeitverhalten stellen?
Erste Anwendungen mit virtuellen Steuerungen sind mittlerweile im Produktivbetrieb: Gehostet in IT-Servern, ersetzen sie beispielsweise in Produktionslinien der Audi AG physikalische SPSen.
Ein großer Vorteil virtueller gegenüber klassischen Steuerungen ist ihre deutlich einfachere Wartbarkeit. So lassen sich Security-Updates viel schneller und umfassender einspielen, um Produktionssysteme gegen gezielte oder zufällige Attacken zu härten. Und weil mit der Zertifizierung nach IEC 61508 für SIL3-Anwendungen jetzt auch virtuelle Sicherheitssteuerungen wie Codesys Virtual Safe Control SL zur Verfügung stehen, gibt es keine Einsatzbegrenzungen mehr. Aber dennoch bleibt ein Zweifel: Wenn virtuelle Steuerungen in abgesetzten IPCs nahe der Maschine oder sogar in entfernten Servern im Rechenzentrum betrieben werden, lassen sich dann weiterhin Echtzeitanwendungen mit hohen Anforderungen an Performance und Jitter realisieren? Gerade dann, wenn koordinierte Verfahrbewegungen nötig sind, wie das bei Motion-Controllern, CNC- und Robotiksteuerungen der Fall ist? Wie sieht es aus, wenn größere Distanzen zwischen Steuerung und Antrieben bzw. E/As zu überbrücken sind?
Für koordinierte Verfahrbewegungen in Motion-, CNC- oder Robotik-Anwendungen sind geeignete Servoantriebe mit digitalen Feldbusschnittstellen notwendig. Wegen ihrer Echtzeitfähigkeit haben sich CANopen und zunehmend EtherCAT als Bussysteme etabliert. Sie werden von vielen Herstellern implementiert, so dass Anwenderinnen und Anwender die freie Auswahl aus einem großen Portfolio kompatibler Antriebe unterschiedlicher Hersteller haben. Allein die in Codesys integrierte Motion-Lösung bietet spezifische Treiber für CANopen- und EtherCAT-Antriebe von mehr als zwei Dutzend Herstellern sowie generische Treiber für CiA402/CoE- und SoE-kompatible Systeme.
Motion, CNC und Robotik in SPSen
Wurden früher dedizierte Controller eingesetzt, um koordinierte Verfahrbewegungen zu steuern, so lassen sich die Anfahrpunkte der Antriebe mit ihren Dynamiken heutzutage auch in der SPS berechnen und per Feldbus übertragen. Der Nutzen: Verringerung von Hardwareaufwand und Kosten. Aufseiten der Hardware sind eine geeignete CPU-Leistung und verfügbare Schnittstellen an der SPS die unabdingbare Voraussetzung. Ist die Leistungsfähigkeit der eingesetzten Steuerung unzureichend, hat man verloren und muss auf ein leistungsfähigeres Modell wechseln – mit Konsequenzen, die teuer und aufwendig sein können. Oder andersherum: Wer den Leistungsbedarf einer Applikation abschätzt, sollte vorab sehr genau prüfen, ob Motion-Control-, CNC- oder Robotik-Funktionen nötig sind, und die Auswahl geeigneter Steuerungen nach der verfügbaren Leistungsfähigkeit filtern. Dabei fällt auf: Mit Soft-SPSen oder virtuellen Steuerungen ist man deutlich flexibler.
Natürlich sind auch die Leistungsreserven von IPCs oder Servern mit mehreren CPU-Kernen irgendwann aufgebraucht, wenn sie mehrere virtuelle Steuerungen ausführen. Aber im Vergleich zu dedizierten SPSen sind die Reserven um ein Vielfaches größer, und sie lassen sich bei Bedarf abrufen. Ein Anwendungsfall: Bei der Projektierung wird klar, dass zusätzlich zur Logiksteuerung noch ein Motion Controller nötig wird. Dieser lässt sich nun einfach »aufrüsten«, und zwar durch eine Lizenz. Damit können komplexe Achsgruppen genutzt und die zugehörigen aufgerufenen Bibliotheksbausteine freigeschaltet werden. Bei physikalischen Geräten ist dies in vielen Fällen schlicht undenkbar - ein klarer Pluspunkt für virtuelle Steuerungssysteme.
Grundsätzlich gibt es für Motion Control zwei Architekturansätze, die die Anforderungen an die Echtzeit der Kommunikation stark beeinflussen. Da ist zum einen der gerade beschriebene zentrale Ansatz, bei dem die Trajektorie in der Steuerung gerechnet wird, wobei die einzelnen Achsen dieser Vorgabe folgen. Dafür ist eine ständige, jitterfreie Kommunikation erforderlich. Dem gegenüber steht der dezentrale Ansatz, bei dem intelligente Antriebe oder untergeordnete Steuerungen diese Motion-Funktion implementieren und von der übergeordneten Steuerung nur Befehle bekommen. Hierfür ist keine zyklische, synchronisierte Kommunikation erforderlich. Vor allem Industrieroboter können somit ohne spezielle Programmiersprachen wie Karel, Inform oder RAPID auskommen. Von der SPS aus werden stattdessen Kommandos über Standard-Feldbussysteme wie Profinet an die Robotersteuerung geschickt, die für die gewünschte Bewegung sorgen. Wurden in der Vergangenheit proprietäre Bibliotheken wie mxAutomation dafür angeboten, so etabliert sich Standard Robot Command Interface (SRCI) derzeit als übergreifender Standard mit einem Satz aus 115 Befehlen, etwa für lineare Bewegungen bis hin zu komplexeren Befehlen wie Kraftsteuerung. Die virtuelle SPS kann in solchen Anwendungsfällen problemlos räumlich distanziert ausgeführt werden und ihre Kommandos per Feldbus senden, weil die eigentliche Robotersteuerung weiterhin vor Ort am Roboter erfolgt.
Abgesetzte industrielle Antriebssysteme
Ob virtuelle Steuerungen für zentrale gerechnete 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. 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 sich dieser Code zusätzlich zykluskonsistent zur SPS-Applikation ausführen lässt, muss zum einen das Antriebssystem im Programmiertool richtig konfiguriert sein. Das umfasst 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 und Motoren ihre Sollwerte »pünktlich« bekommen und rund laufen. Per Definition dürfen dabei die Kabellängen beispielsweise von EtherCAT eine Länge von maximal 100 m aufweisen. Wenn gleichzeitig die Anzahl der angesteuerten Antriebe eine Größenordnung von 10 bis 20 nicht übersteigt, sind normalerweise keine weiteren Maßnahmen oder 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-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, etwa 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-Bus einbetten kann. Es ist unerlässlich, diese Daten ebenfalls über den LWL zu übertragen. Technisch machbar ist es, die Daten über spezielle Protokolle parallel zu EtherCAT zu verpacken und via LWL zu verschicken. Wenn die Einbettung der Daten im Silizium erfolgt, also in integrierten Schaltkreisen (ASICs), dann lassen sich die Daten verlustfrei in fast beliebigen Frequenzen gleichzeitig über den LWL übertragen.
Genau das verspricht ein Ansatz mit dem Arbeitstitel »Robo/TSN« des Unternehmens Missing Link Electronics. Das System wurde unter anderem im Rahmen der BMFTR-Projekte »Octopus Verano« und »6G Integrated Communication & Sensing for Mobility« finanziert. Es fasst Daten unterschiedlicher Bussysteme per FPGAs zusammen und überträgt sie deterministisch. Abhängig vom Medium, typischerweise LWL, lassen sich damit mehrere hundert Gigabit an Daten im Nanosekundenbereich übertragen. 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 sind also problemlos nutzbar. Wegen der Kapselung lassen sich die Feldbusinformation sogar in offenen IT-Netzen sicher nach IEC 62443 ü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 beispielsweise die Codesys-Motion-Applikation genau wie bisher konfiguriert: Ein verfügbarer Ethernet-Port wird zum EtherCAT-Master samt angeschlossenen E/As und Antrieben – bei der Konfiguration merkt man nicht, dass dieser Port durch Robo/TSN getunnelt wird. Auch die oben erläuterte weitere Parametrierung und Projektierung ändert sich nicht im Vergleich zur Nutzung an einem Standard-Ethernet-Port. Was sich ändert, ist die »Netzwerkkarte«: Sie umfasst den entsprechenden ASIC und stellt Ethernet- und andere Kommunikations-Ports 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. Sowohl am Hostrechner, in 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 ist solch eine Herausforderung lösbar – abhängig von der Anwendung und den genutzten Komponenten durch 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.
Lesen Sie mehr zum Thema
