Simulation aus Sicht der Steuerung – Eine offene Simulationsschnittstelle und deren Anforderungen

Im Bereich der Automobilindustrie, Bereich Lackierroboter, wird beispielhaft die Schnittstelle \“Realistic Robot Simulation (RRSII)\“ als der weltweite de-facto-Standard zur präzisen Simulation von Robotersteuerungen eingesetzt. Basierend auf der ersten Spezifikation RSSI gibt es seit 2001 eine zweite Spezifikation, die vorrangig die aktuellen Anforderungen im Bereich der Robotersimulation erfüllt. Ein gesamtes Simulationsmodell bei RRSII besteht gewohnterweise aus dem Simulationsmodell des Roboters, einem zusätzlichen Teil für die Koordination der Steuerungsfirmware und einem modifizierten Teil in der Steuerungsfirmware. Dort sind neben der RSSII Schnittstelle zur Kommunikation zum Simulationsmodell die einzelnen VRCs (eine Virtual Robot Control als Beispiel gezeichnet) abgebildet. Eine VRC übernimmt die Aufgabe, die reale Steuerungssoftware in einem Simulationsmode zu betreiben und die notwendigen Daten über die Kommunikationsschnittstelle zum Simulationsmodell bereitzustellen. Dabei gibt es unterschiedliche Kategorien von Diensten, um dies zu ereichen. Drei Kategorien für die Schnittstelle der Realen Steuerung sind: – I/O: Transfer von binären/analogen Daten und Daten über die serielle Kommunikation – File System: Transfer von einzelnen Dateien oder gesamtem Verzeichnis – User Interface: Funktionen zur Manipulation wie Start/Stopp der Roboter-Steuerung Drei Kategorien werden für die VRCs für den Simulationsbetrieb benötigt: – Base Commands: Das Anlegen, das Management und das Löschen von VRC-Instanzen – Time Management: Steuert den Simulations-Fortschritt in Virtueller Zeit – Simulator Support: Vorkehrungen der Steuerung für interne Algorithmen und Ereignisse Zusätzlich gibt es für die Kontrolle der einzelnen VRCs einen VRC-Manager als einzelne Softwarekomponente. Diese Komponente hat die Aufgabe, einzelne VRCs zu instanzieren, zu steuern und auch wiederum zu löschen. Wie man aus der Grafik erkennen kann, müssen die bestehenden Softwarekomponenten in einer VRC eingepasst werden. Das Steuerungspaket (die Firmware der Steuerung) wird somit in seiner Form stark verändert, sprich die für die Simulation zusätzlich notwendigen Softwarebausteine verändern im Prinzip das Verhalten der Steuerungsfirmware. Aus Erfahrung lässt sich die Zusatzsoftware relativ einfach einbinden. Es hat sich ein relativ identisches Verhalten mit der realen Steuerung herausgestellt, somit lässt sich die Auswirkung als leicht bewerten. Die Schnittstelle RRSII eignet sich besonders gut für die Simulation und Anbindung von virtuellen Robotern, da diese Schnittstelle mit ihren virtuellen Robotersteuerungen speziell für diesen Anwendungsfall definiert worden sind. Was hier allerdings fehlt, ist die Definiton für den klassischen Steuerungsbereich: Logische Verknüpfungen und prozesstechnische Definitionen sind in der VRC-Definition nicht abgebildet und noch einzuführen. Die Synchronisation und deren Manipulation zwischen dem Steuerungsteil und dem Robotersimulationsmodell sind sehr gut abgebildet und stellen bereits eine gute Ausgangsbasis dar. Praxisbeispiel 2 – Blechbiegesimulation Für die Simulation eines Blechbiegeroboters wird ein Standardsimulationswerkzeug vom Markt eingesetzt. Für die Kopplung zur Steuerungsoftware ist ein eigener Treiber entwickelt worden, der die notwendigen Daten aus dem Steuerungssystem lesen und schreiben kann. Daraus können im Simulationsmodell des Biegeroboters die Bewegungen der Achsen abgeleitet und als virtuelles Bild angezeigt werden. Auf dem Simulationsrechner sind im Wesentlichen drei Teile ersichtlich: Zum einen wird das Steuerungssystem mit der Firmware und den darin enthaltenen Bereichen (Betriebssystemanpassungschicht UOS, IO-System, Laufzeitsysteme SPS und Motion) ausgeführt. Zum anderen läuft das in WinMod ausprogrammierte Simulationsmodell des Biegeroboters. Dabei werden verschiedene Achsen, Umgreifstationen oder Tischpositionen simuliert. Für die Anbindung und den Austausch der Daten zwischen diesen beiden Systemen ist ein eigener Adapter programmiert worden. Dieser Adapter holt sich über die vom Steuerungssystem bereitgestellte Lese- und Schreibfunktionen die Daten und stellt diese in ein Shared Memory. Ein im Adapter integrierter Timer ruft zyklisch die Funktionen zum Lesen und Schreiben der Daten auf und stellt diese zur Verfügung. Dieser gemeinsam definierte Datenbereich in der Größe von 1KB wird nun vom vorhandenen Treiber des Simulationswerkzeugs ausgelesen und dem ausprogrammierten Simulationsmodell zur Verfügung gestellt. Derselbe Weg wird für das Schreiben von Daten verwendet. Die Darstellung der vom Simulationsmodell aufbereiteten Daten erfolgt über ein 3D-View-Werkzeug, das dem Simulationswerkzeug beiliegt. Die Bewegungen des Roboters und der auch daran beteiligten Presse können so anschaulich dargestellt werden. Vorteilhaft für diese Konstellation ist, dass man beliebige Daten aus dem Steuerungssystem auslesen und dem Simulationsmodell über den gemeinsamen Datenbereich zur Verfügung stellen kann. Der Zugriff auf die Daten erfolgt über einen relativ tief im System verankerten Mechanismus – in diesem Fall die Betriebssystem-Anpassungsschicht. Ein hohes Detailwissen muss somit zur Verfügung stehen, damit man auch weiß, welche Daten aus dem Steuerungssystem ausgelesen/geschrieben werden sollen. In diesem Fall sind es nur einfache Daten vor allem der Achsen, da die Anforderung auf die einfache Darstellung der Achsbewegungen beschränkt sind. Dies ist auch nachteilig bei dieser Zusammenstellung, denn es wurden hier zahlreiche Daten nicht verwendet bzw. nachempfunden. So werden keine Bussysteme der IO-Daten simuliert wie auch Kollisionsprüfungen der Achspositionen durchgeführt. Dies liegt aber vor allem in der Realisierung des einfachen Simulationsmodells. Wesentlich schwieriger ist hier die fehlende Synchronisation der Abläufe zwischen Simulationsmodell und Steuerungsabläufen. Praxisbeispiel 3 – virtuelle Spritzgießmaschine Bei der Anbindung eines virtuellen Modells einer Spritzgießmaschine wird die Simulation mittels einer propriäteren Direktkopplung über einen gemeinsamen Datenbereich realisiert. Besonders ist hier die Synchronisation der beiden Systeme in der Weise, dass neben den notwendigen IO-Daten auch der Takt von IO-System und dem SPS-Teil übertragen werden. Bei dieser Konstellation wird ein spezielles IO-System als Softwarebaustein verwendet, der die Daten der Ein-/Ausgangsvariablen und den Takt einem Simulationsmodell zur Verfügung stellt. Wichtig hierbei ist die Bereitstellung des Takts, mit dem das IO-System berechnet wird – wie auch der darauf aufbauende Baustein, der die logischen Verknüpfungen ausführt. So ist es möglich, dass ein typischer Ablauf so erfolgt, dass zum einen ein Zyklus in der Steuerungsfirmware berechnet wird (beinhaltet die Berechnung der Algorithmen der Steuerung wie auch die Erstellung der Prozess ein- und ausgangsdaten), anschließend das System quasi angehalten wird und die Ausführung an das Simulationsmodell übergeben wird. Das Simulationsmodell kann somit einen Maschinenzyklus berechnen und die Daten nach Vollendung wiederum dem Steuerungsmodell zur Verfügung stellen (es wird der Takt wieder an das Steuerungssystem zurückgegeben). Dieser Austausch der Informationen zwischen den beiden Modellen hat den Vorteil, dass die berechneten Daten des Steuerungs- und Simulationsmodells zusammenpassen und somit eine sehr gute Synchronisation der beiden Modelle ermöglicht wird. Darüber hinaus können die Entwicklungswerkzeuge der Steuerung identisch genutzt werden, ohne das Simulationsmodell negativ zu beeinflussen. Dies ist besonders für die Diagnose der Steuerung, auch in Zusammenhang mit der Simulation wichtig. Alle Features wie Watchpoint, Variablenmonitor, aber auch Breakpoints und Step-Betrieb können verwendet werden, ohne dass das Simulationsmodell weiterläuft und nicht mehr mit der Steuerungsimulation zeitlich identisch läuft, sondern es wird gleichzeitig angehalten bzw. wieder gestartet. Nachteilig ist hier wiederum der Eingriff in das Steuerungssystem – andere Software-Komponenten werden genutzt und beinflussen so zu einem gewissen Teil die virtuelle Steuerung. Abgeleitete Anforderungen für eine Steuerungsplattform Aus den o.g. Themenbereichen sind bereits einige Merkmale zur Gestaltung der Schnittstelle zu Prozesssimulationen auszumachen. Die Anforderungen sind in Teilbereichen bereits zum Teil gut erfüllt, wobei man erkennen kann, dass a) der Datenaustausch von IO-Daten bereits sehr gut abgedeckt wird. Minimales Verbesserungspotential liegt in der Anbindung von Antrieben, da hier die zahlreichen Parameterdaten noch nicht in der Fülle übertragen und ausgewertet werden. b) die Übertragungswege wie Bussysteme und deren Daten überhaupt noch nicht realisiert sind. Diese Funktionalität und der damit verbundene Nutzen der Auswertung von Zykluszeiten, Übertragungszeiten und Überlastanzeigen fehlten noch zur Gänze. c) die Synchronisation zwischen Steuerungs- und Simulationsmodell bereits gut abgedeckt wird bzw. in Form von eigens geschaffenen Mechanismen geschaffen werden kann. Die Manipulation der Zeitlichkeit ist aber noch nicht implementiert, somit können Langzeitstudien nur erschwert durchgeführt werden. Dies liegt auch in der vielleicht zu niedrig vorhandenen Rechnerleistung, da man sich vorstellen muss. Was in der Realität auf einem Steuerungsrechner und der realen Maschine ausgeführt wird, muss in dem vorhandenen Simulationssystem schon einmal auf einem Rechner ausgeführt werden – schnellere Abläufe bedingen eine enorme Steigerung der Rechen leistung. d) eine Standardisierung nur im Robotikbereich vorhanden ist, wobei hier die Standardisierung nur durch das Comittment der Industrie hergestellt ist. Diese Schnittstelle RRSII zeigt einen guten Weg, wie Daten und deren Handhabung funktionieren kann – eine Verwendung im Standard-PLC-Bereich ist aber noch nicht möglich, da verschiedentliche Funktionen der Nachbildung einer virtuellen Steuerung noch nicht berücksichtigt oder implementiert sind. e) die Unterschiede und Abgrenzungen zwischen Realität und Simulation noch verbessert werden müssen – dabei ist es erforderlich, die genauen Funktionen in Kombination mit einer bestimmten Hardware noch zu simulieren, damit der Funktionsumfang der Steuerung mit dem Prozesssimulationsmodell noch umfangreicher in der virtuellen Welt realisiert und geprüft werden kann und der daraus folgende Nutzen erhöht wird. f) die Einbindung der Entwicklungswerkzeuge für Fehlerdiagnostik und Debugging im Prinzip funktioniert, aber stark von der Synchronisation mit dem Prozessmodell abhängt. Ist diese Synchronität vorhanden, so ist auch eine umfangreiche und funktional vollständige Einbindung möglich. Neben den bereitzustellenden Daten, deren Synchronisation und den vorher angeführten Merkmalen gibt es aber noch weitere Anforderungen hinsichtlich Rechnerperformance, technischer Auslegung und Abbildung komplexer Automationslösungen. Für die Steuerung ist ein wesentlicher Aspekt dabei, dass die Schnittstelle an die unterschiedlichen Prozesssimulationsmodelle anpassbar ist – ohne Einfluss auf die Steuerung zu nehmen. Einfluss bedeutet dabei, dass keine besonderen Softwarebausteine in die Firmware mit eingegliedert werden dürfen, sondern diese bereits so zur Verfügung stehen. Fazit In der weiteren Zukunft wird das Thema Simulation noch intensiviert werden. Einerseits werden Prozesssimulationen verbessert und die damit verbundenen Vorteile mehr ausgenutzt. Simulationen verhelfen dem Kunden zu Kosteneinsparungen, wodurch deren Notwendigkeit weiter verstärkt wird. Andererseits ergeben sich durch neue Technologien wie MultiCore-Prozessoren und ähnlichem neue Anforderungen und Möglichkeiten zur Ausweitung des Funktionsumfangs im Bereich der virtuellen Prozesse. Der Weg in Richtung einer offenen Simulationsschnittstelle wird die Integration der in den drei Praxisbeispielen aufgezeigten Lösungsmöglichkeiten darstellen, wobei hier die Zusammenarbeit mit den Anbietern von Prozessimulationsumgebungen gesucht werden muss. Danksagung Folgenden Unternehmen und Personen möchte ich für die Unterstützung und fachliche Beratung danken: Fa. Engel, Fa. Trumpf, Fa. Dürr, Firma Keba AG: Hr. Alexander Leitner, Hr. Andreas Stegfellner, Hr. Gerald Steinkellner.