Bild 01: Erste Anwendungen mit virtuellen Steuerungen sind mittlerweile im Produktivbetrieb. (Quelle: Codesys)
Ein großer Vorteil von virtuellen Steuerungen ist ihre deutlich einfachere Wartbarkeit. So können Security-Updates viel schneller und umfassender ausgerollt werden, um Produktionssysteme gegen gezielte oder zufällige Attacken zu sichern. Und weil mit der Zertifizierung gemäß der Normenreihe IEC 61508 [1] für SIL3-Anwendungen jetzt auch virtuelle Sicherheitssteuerungen wie die Virtual Safe Control SL von Codesys [2] zur Verfügung stehen, gibt es keine Einsatzbegrenzungen mehr. Und dennoch bleibt ein Zweifel: Wenn virtuelle Steuerungen auf abgesetzten IPC in der Nähe der Maschine oder sogar auf entfernten Servern im Rechenzentrum betrieben werden, lassen sich dann weiterhin Echtzeitanwendungen mit hohen Anforderungen an Performance und Jitter realisieren?
Vor allem dann, wenn koordinierte Verfahrbewegungen benötigt werden, wie das bei Motion-, CNC- und Robotik-Aufgaben der Fall ist (Bild 1). Wie sieht es aus, wenn größere Distanzen zwischen Steuerung und Antrieben bzw. E/A zu überbrücken sind?
Zur Realisierung von koordinierten Verfahrbewegungen für Motion-Control-, CNC- oder Robotik-Aufgaben benötigt man geeignete Servoantriebe mit digitalen Feldbusschnittstellen. Aufgrund ihrer Echtzeitfähigkeit haben sich CANopen und zunehmend Ethercat als Bussysteme etabliert. Sie werden von vielen Herstellern implementiert, sodass 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-Control-, CNC- und Robotikfunktionen auf einer SPS
Wurden früher dedizierte Controller eingesetzt, um koordinierte Verfahrbewegungen zu steuern, so lassen sich die Anfahrpunkte der Antriebe mit ihren Dynamiken heute auch in der SPS berechnen und per Feldbus übertragen. Der Nutzen: Reduktion von Hardwareaufwand und Kosten. Aufseiten der Hardware sind eine geeignete CPU-Leistung sowie verfügbare Schnittstellen an der SPS die Voraussetzung. Ist die Leistungsfähigkeit der eingesetzten Steuerung unzureichend, muss auf ein leistungsfähigeres Modell gewechselt werden – mit Konsequenzen, die teuer und aufwendig sein können. Daher sollte man bei der Abschätzung des Leistungsbedarfs seiner Applikation vorab sehr genau prüfen, ob Motion-Control-, CNC- oder Robotik-Funktionen benötigt werden und die Auswahl geeigneter Steuerungen nach der verfügbaren Leistungsfähigkeit filtern. Dabei fällt auf: Mit SoftSPS oder virtuellen Steuerungen ist man deutlich flexibler.
Natürlich sind auch die Leistungsreserven von IPC oder Servern mit mehreren CPU-Kernen irgendwann aufgebraucht, wenn darauf mehrere virtuelle Steuerungen ausgeführt werden. Aber im Vergleich zu dedizierten SPS sind die Reserven um ein Vielfaches größer, und sie können bei Bedarf abgerufen werden. Ein Beispiel: Bei der Projektierung wird klar, dass zusätzlich zur Logiksteuerung noch ein Motion Controller nötig wird. Dieser kann nun einfach „aufgerüstet“ werden, 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.
Mögliche Motion-Control-Architekturen
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 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 erhalten. Hierfür ist keine zyklische, synchronisierte Kommunikation erforderlich. Insbesondere Industrieroboter können somit ohne spezielle Programmiersprachen wie Karel, Inform oder Rapid auskommen. Von der SPS 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 mit dem Standard Robot Command Interface (SRCI) gerade ein übergreifender Standard mit einem Satz aus 115 Befehlen. Diese können für lineare Bewegungen bis hin zu komplexeren Befehlen wie Kraftsteuerung genutzt werden. Die virtuelle SPS kann in solchen Anwendungsfällen problemlos räumlich distanziert ausgeführt werden und ihre Kommandos per Feldbus schicken, weil die eigentliche Robotersteuerung weiterhin vor Ort am Roboter erfolgt.