Automatisierte Konfiguration und Selbstauskunft von Industrierobotern

Ausgangssituation und Zielsetzung

 
Der anhaltende Trend von individualisierter Massenproduktion („Mass Customization“) [1] führt dazu, dass spezialisierte Produktionsanlagen zunehmend an ihre Grenzen stoßen [2]. Die effiziente Adaption an geänderte Anforderungen („Wandlungsfähigkeit“) stellt hierbei einen zunehmend wichtigeren Wettbewerbsfaktor dar [3]. Aktuelle Produktionsanlagen benötigten für die (Wieder-)Inbetriebnahme jedoch lange Stillstandszeiten und den Einsatz von Experten [4]. Neben Tätigkeiten im Bereich der mechanischen und elektrischen Installation ist dies vor allem auf die softwareseitige Konfiguration, Programmierung und Parametrierung zurückzuführen. Als Folge wird eine automatisierte Produktion heutzutage oftmals erst bei größeren Stückzahlen wirtschaftlich rentabel.
In Anbetracht dieser Problemstellungen wurden im Rahmen des Forschungsvorhabens AKOMI zwei grundsätzliche Zielstellungen verfolgt: Zum einen soll die Einrichtung von Produktionsressourcen stark vereinfacht und verkürzt werden, wodurch sich geringere (Re-)Konfigurationskosten und damit ein kürzerer Return-on-Invest (ROI) ergibt. Darüber hinaus ist es notwendig, heterogene Systemlandschaften, bestehend aus unterschiedlichen Kommunikationsprotokollen, Befehlssätzen, und Anbietern, ohne zusätzlichen Einrichtaufwand in das System integrieren zu können. Unter diesen Gesichtspunkten wird ein ganzheitliches Konzept entworfen, mit dem sich Komponenten robotergestützter Montageanlagen automatisiert konfigurieren und vernetzen lassen (Plug&Produce).
 

Stand der Technik

 
Aufgrund der existierenden Heterogenität bei den Befehlen zur Ansteuerung von Aktoren und Sensoren unterschiedlicher Hersteller werden in Produktionsanlagen oftmals Produkte eines einzelnen Herstellers bevorzugt. Dieses Vorgehen gewährleistet in der Regel eine hohe Kompatibilität der Komponenten untereinander, was die Projektierungs- und Konfigurationsvorgänge deutlich vereinfacht. Die Einschränkung auf Insellösungen bringt im Hinblick auf die Prozessoptimierung der Produktion jedoch Nachteile mit sich. Im Consumer-Bereich wurde diese Problematik vor einigen Jahren bereits durch „Plug&Play“-Technologien mithilfe von USB, Ethernet und Co. erfolgreich gelöst. Auswahlkriterien für Elektronikartikel sind hier Funktionsumfang, Qualität oder Kosten – Herstellerzugehörigkeit oder angebotene Schnittstellen stehen an weit untergeordneter Stelle [5]. Die Integration erfolgt durch Standardisierung, Selbstidentifikation und bereitgestellte Gerätetreiber meist innerhalb von Sekunden.
Auch im Bereich der Produktionstechnik gibt es bereits treiberbasierte Ansätze, bei denen Konfigurationsinformationen über das Gerät dateibasiert bereitgestellt werden. In Engineering-Tools integriert, lassen sich so beispielsweise unterschiedliche Gerätearten einheitlich parametrieren. Ein Beispiel ist der Protokoll IO‑Link, welcher eine serielle Punkt-zu-Punkt Verbindung von einfachen Sensoren und Aktoren bietet [6]. Über diese Schnittstelle können Steuerungssysteme (SPS) sowohl Prozess- als auch Servicedaten und Events austauschen.
Für eine automatisierte Vernetzung von Produktionsressourcen reicht eine einheitliche Schnittstelle nicht aus. Aktuell müssen die Gerätetreiber von einem Softwareentwickler manuell in die Engineering-Umgebung der Steuerung geladen werden. Die Zuordnung und Verknüpfung der Geräte-Parameter mit den Prozessvariablen erfolgt hierbei von Hand. Geräte können sich nicht selbstständig identifizieren, wodurch die Auswahl des entsprechenden Treibers durch den Programmierer geschehen muss. Beides ist zeitaufwändig und mitunter fehlerträchtig [4]. Weiterhin bieten heutige Produktionsmittel keine Selbstbeschreibung ihrer eigentlichen Funktionalitäten (Fähigkeiten). Diese werden aktuell durch die Ansteuerung mittels spezifischer Befehle oder Daten verdeckt, wodurch der Softwareentwickler die Transformationsleistung hin zur Funktion selbst erbringen muss. Dies geschieht, indem die jeweiligen Steuerungsbefehle zur weiteren Nutzung in der Ablaufsoftware in Komfortfunktionen verpackt werden.
Im aktuellen Stand der Industrierobotik hat eine solche einheitliche, funktionale Selbstbeschreibung noch nicht flächendeckenden Einzug erhalten. Ein Großteil der Hersteller nutzt proprietäre Steuerungen und Programmiersprachen zur Ansteuerung der Geräte. Hierdurch ist der Austausch eines Roboters durch das Modell eines anderen Herstellers nicht möglich, ohne gleichzeitig die Steuerung zu tauschen und damit die Softwareabläufe erneut implementieren zu müssen. Selbst bei einem Wechsel der Modellreihe bei einem Hersteller sind häufig Softwareanpassungen zu leisten.
 

Referenzmodell für die Selbstauskunft von Robotersystemen
 

Für eine herstellerübergreifende Beschreibung der Fähigkeiten eines Robotersystems gilt es, die angebotenen Funktionalitäten sowie Eigenschaften in einem standardisierten Referenzmodell abzubilden. Kerninhalt ist hierbei eine Diensteauskunft des Roboters. Ein Dienst (Service) stellt Drittsystemen eine technische Funktionalität bereit, ohne dass diese tiefergehende Kenntnisse über die Spezifikation des ausführenden Systems erlangen müssen. Im Falle von Robotersystemen muss beispielsweise ein Dienst existieren, welcher es erlaubt, ein Objekt entlang einer Bahn mit definierten Eigenschaften (wie etwa Geschwindigkeit und Bahnabweichung) im Raum bewegen zu können. Wird erreicht, dass die Publikation dieses Dienstes sowohl modell- als auch herstellerübergreifend identisch geschieht, so wird dem Anwender ein leichterer Austausch unterschiedlicher Robotersysteme oder Peripheriekomponenten ermöglicht. Damit ergibt sich eine größere Flexibilität im Einsatz der Betriebsmittel. Durch den einheitlichen Befehlssatz bleiben darüber hinaus andere Softwaremodule von etwaigen Hardwareanpassungen unberührt.
Neben angebotenen Diensten sind auch die Eigenschaften eines technischen Systems von Interesse. Diese können andere Systeme beispielsweise zur Visualisierung, Planung und Steuerung oder zur Auswahl bei konkurrierenden Diensten verschiedener Betriebsmittel nutzen. Aus der Identifikation von mehreren Use-Cases [7] sowie der Sammlung von Geräteinformationen aus bekannten Normen [8‑11] und Veröffentlichungen [12] ergibt sich das in Bild 1 dargestellte Referenzmodell zur Selbstauskunft von Robotersystemen. Administrative Merkmale (z. B. Listenpreis, Lieferzeit) stehen hierbei außerhalb des Betrachtungsbereichs, da diese nicht Teil der informationstechnischen Inbetriebnahme sind. Im Sinne einer Klassifikation der „Plattform Industrie 4.0“ [13] wird durch das Referenzmodell eine Verwaltungsschale geschaffen, welche aufgrund der allgemeingültigen Definition neben Robotersystemen auch für weitere Feldgeräte genutzt werden kann.
 

Bild 1:Referenzmodell zur Selbstauskunft von Robotersystemen/Feldgeräten (Auszug).

Architektur zur automatisierten Vernetzung und Dienste-Bereitstellung

 
Aufgrund der Gegebenheit, dass auf Hardwareebene eine herstellerübergreifende Standardisierung nicht erfolgt, müssen die angebotenen, allgemeinen Dienste und Eigenschaften eines Robotersystems mit den spezifischen Befehlen und Variablen der aktuell verwendeten Robotersteuerung verknüpft werden. Diese Verbindung geschieht durch die Bereitstellung von Treibermodulen. Zu jedem spezifischen Befehlssatz eines Roboters muss der Anwender ein Treibermodul laden. Die Implementierung des Treibers kann beispielsweise über Drittanbieter, Open-Source-Projekte oder durch die Hersteller als digitale Dienstleistung geschehen. Alle im Referenzmodell definierten Informationen müssen durch das Treibermodul aus der Robotersteuerung ausgelesen oder direkt als Information angeboten werden (z. B. Seriennummer, Dokumentation).
Als technologische Basis wird im Projekt AKOMI das Open-Source-Framework ROS (Robot Operating System [14]) verwendet. ROS besitzt den Vorteil, dass es eine große Sammlung an frei nutzbaren Algorithmen zur Visualisierung, Pfadplanung und Kollisionserkennung bietet. Weiterhin liefern zahlreiche Hersteller (u. a. ABB, Adept, Fanuc, Motoman, Universal Robots) kostenlos Module zur Ansteuerung ihrer Robotersysteme. Exemplarisch wurde für ein Robotermodell ein Plug&Produce-Treiber entwickelt, welcher das herstellerspezifische Modul zur Ansteuerung mit der Gesamtarchitektur verbindet und fehlende Informationen bereitstellt (Bild 2). Durch die Implementierung verschiedener Abstraktionsschichten kann die restliche Architektur herstellerunabhängig mit dem Roboter kommunizieren und Daten austauschen. Als zentrales Element wird dem Pfadplanungsmodell die kinematische Beschreibung (Anordnung und Eigenschaften der Achsen) des Roboters übermittelt. Wird nun der definierte Dienst zur Bewegung im kartesischen Raum durch ein externes System aufgerufen, dann berechnet der Pfadplaner notwendige Stützpunkte und führt eine Rückwärtstransformation in Achsstellungen aus. Über den Plug&Produce-Manager werden diese Informationen an das Treibermodul geschickt, welches die Befehle in herstellerspezifische Daten wandelt und überträgt. Durch Anbindung eines Umweltmodells (Factory Model), welches CAD-Daten der restlichen Montageanlage bereitstellt, kann der Pfadplaner kollisionsfreie Bewegungen innerhalb der gesamten Zelle berechnen.
Soll ein am Roboter angebrachtes Werkzeug getauscht oder der Roboter durch ein anderes Modell mit abweichender Kinematik ersetzt werden, so ist dies fortan ohne Anpassung der übergeordneten Bewegungsaufrufe möglich. In diesem Fall wird die virtuelle Beschreibung des neuen Roboters über den Treiber in ROS geladen, womit sowohl die Berechnung des Pfads als auch die roboterspezifische Achssteuerung automatisch adaptiert wird.
Da das Treibermodul unabhängig von der zugehörigen Robotersteuerung Informationen liefern kann, ist es bereits vor einer Integration möglich, die Eignung des jeweiligen Roboters für die Produktionsaufgabe zu überprüfen (Online-Abgleich). Sind in einem Treiber die zur Aufgabendurchführung notwendigen Informationen nicht angegeben, so kann dieser aktuell nicht automatisiert integriert werden. Zukünftig könnten diese fehlenden Informationen über Ansätze von wissensbasierten Systemen generiert werden, um (unscharfe) Aussagen zum Verhalten des Roboters treffen zu können. Diese Ansätze sind momentaner Gegenstand der Forschung.
 

Bild 2: Architektur zur herstellerneutralen
Dienste-Bereitstellung von Robotersystemen.

OPC UA als Diensttechnologie

 
Damit eine einheitliche Kommunikation aller in der Fabrik befindlichen Geräte gewährleistet werden kann, muss sichergestellt sein, dass die Dienste durch eine standardisierte, industriell etablierte Kommunikationstechnologie bereitgestellt werden. Hierbei wird auf OPC UA gesetzt, da einerseits zahlreiche Industriekomponenten (z. B. SPS) bereits OPC UA Server und Clients implementiert haben und weiterhin das Protokoll von verschiedenen Fachgremien als technologische Umsetzung einer Dienstearchitektur für Smart Factories empfohlen wird [15-17].
ROS bietet aktuell keine OPC UA Unterstützung, weshalb ein eigener OPC UA Server entwickelt wurde. Für einen Zugriff auf das ROS-Framework wird dabei auf das „ROS-Bridge“-Modul zurückgegriffen, welches Daten aus ROS über Ethernet verteilen kann. Der bereits existierende ROS-Parameter-Server wird für die Publikation der Geräteeigenschaften verwendet, für die Verteilung der Plug&Produce-Dienste wird ein neuer ROS-Services-Server erstellt. Für den Aufbau des OPC UA Servers existiert eine .NET-basierte Software, die als Proxy fungiert. Aus den übermittelten Daten wird ein OPC UA Server generiert, der im Anschluss standardisiert mit anderen OPC UA Teilnehmern kommunizieren kann. Der Server soll hierbei alle in ROS aktiven Geräte zur Verfügung stellen, wodurch eine dynamische Generierung und Verlinkung notwendig ist. Ändert sich ein Parameterwert des Roboters (z. B. Achsstellung) wird die Änderung zyklisch über die ROS-Bridge zum OPC UA Server übertragen und aktualisiert. Bei einem OPC UA Dienstaufruf erfolgt die Weiterleitung des Aufrufs vom Server über die ROS-Bridge zu dem in ROS laufenden Dienst, welcher dann letztendlich ausgeführt wird.
 
Bild 3 zeigt die Umsetzung am Beispiel eines Yaskawa MH5‑Roboters, dessen Geräteabbild über das beschriebene System im Netzwerk bereitgestellt wird. Der Anwender kann sich über einen OPC UA Klienten auf einem Smart Device mit dem Server verbinden und semantisch standardisiert Geräteinformationen abrufen sowie angebotene Dienste, wie etwa Verfahrbefehle, aufrufen.
 

Bild 3: Veröffentlichtes Geräteabbild eines Yaskawa MH5-Roboters, welches für
eine hardwareunabhängige Steuerung und semantisch standardisierte Datenakquise genutzt wird.

Echtzeitabbild der gesamten Montageanlage

 
Während der Ansatz einer automatisierten Konfiguration und standardisierten Dienste-Bereitstellung bereits eine Vereinfachung der Einrichtung und Ansteuerung von Industrierobotern bietet, existieren in robotergestützten Montageanlagen zahlreiche weitere Sensoren und Aktoren. Diese veröffentlichen bis dato keine Dienste und müssen manuell konfiguriert werden. Im Forschungsprojekt AKOMI wurde daher das Konzept auch auf andere Systeme wie beispielsweise Bildverarbeitung und speicherprogrammierbare Steuerungen (SPS) übertragen [4, 18].
Über Mechanismen der Selbstidentifikation wird automatisiert in den jeweiligen Domänen nach angeschlossenen Geräten gesucht. Aufgrund der großen Heterogenität der verwendeten Protokolle existiert eine mehrschichtige Treiberarchitektur, welche spezifische Aufrufe kapselt und dem Aufrufer einheitliche Schnittstellen anbietet. Hierdurch können – ohne Auswirkungen auf die bestehende Infrastruktur – effizient neue Protokolle integriert oder vorhandene Protokolle angepasst werden. Zu den gefundenen Geräten werden in einem Repository die jeweils korrespondierenden Gerätetreibermodule geladen, welche eine virtuelle Repräsentanz („Digital Twin“) analog dem Referenzmodell beinhalten. Im Anschluss werden die Repräsentanzen dynamisch in einen OPC UA Server integriert und mit der gefundenen Gerätehierarchie verlinkt. Der Server bietet nun alle Geräteinformationen und ‑dienste in semantisch einheitlicher Form im Netzwerk an und erlaubt einen einheitlichen Zugriff auf die Anlage.
Aus der Summe aller OPA UA Server erhält der Anwender ein automatisiert generiertes Echtzeitabbild der Anlage, welches die Heterogenität der Einzelsysteme kapselt. Hierdurch können externe Systeme (z. B. Visualisierung, Planungsalgorithmen) über eine Schnittstelle auf beliebige Elemente der Anlage zugreifen oder Informationen abrufen (Bild 4). Die Nutzung des OPC UA Protokolls zur übergreifenden Kommunikation zwischen den Domänen ermöglicht hierbei fortgeschrittene Maßnahmen zur Datensicherheit (Security) und User-Authentifizierung [17].
 

Bild 4: Standardisiertes Anlagenabbild durch Kapselung der Heterogenität mittels
dynamischer Plug&Produce-Server.

Möglichkeit der aufgabenorientierten Programmierung

 
Ein Produktionsprozess lässt sich mit funktionalen Einheiten (z. B. Bewegen, Messen, Verpacken) aufgabenorientiert modellieren. Das vorliegende virtuelle Abbild der Anlage liefert hierbei die Grundlage, diese lösungsneutralen Prozessschritte mit den angebotenen Diensten der jeweiligen Geräte abzugleichen. Zukünftiges Ziel ist es, aus einem generierten Bauplan des Produkts die notwendigen Betriebsmittel automatisiert auszuwählen und zu programmieren [18].
 

Fazit

 
Der vorgestellte Ansatz liefert eine Möglichkeit zur erleichterten Inbetriebnahme von Robotersystemen. Aufbauend auf vorhandene Frameworks, wurde eine treiberbasierte Architektur entwickelt, mit der sich Robotersysteme unterschiedlicher Hersteller einfach und kostengünstig integrieren lassen. Darüber hinaus wurde ein Referenzmodell für eine herstellerunabhängige Gerätebeschreibung definiert. Damit ist es möglich, dass beliebige Endgeräte (z. B. Smart Devices) Robotersysteme ansteuern – unabhängig von Robotertyp und spezifischen Befehlssätzen. Eine Erweiterung der Methode auf die Domänen der Steuerungstechnik und Bildverarbeitung ist möglich. Die Prinzipien der automatisierten Einrichtung und dienstebasierten Programmierung sind Befähiger, um zukünftig wandlungsfähige Produktionssysteme zu betreiben, welche aufgrund der schnellen Adaptierbarkeit der Vision von „Losgröße Eins“ ein Stück näher kommen.

Dieser Beitrag entstand im Rahmen des Forschungsprojektes „Automatisierte Kon guration in der Mikrosystemtechnik (AKOMI)”, das von dem Bayerischen Staatsministerium für Wirtschaft und Medien, Energie und Technologie gefördert wird. 
Eingereicht am 27.11.2015.
 

Schlüsselwörter:

Literatur:

[1] Abele, E.; Reinhart, G.: Zukunft der Produktion – Herausforderungen, Forschungsfelder, Chancen. München 2011.
[2] Koren, Y.; Shpitalni, M.: Design of reconfigurable manufacturing systems. In: Journal of Manufacturing Systems 29 (2010) 4, S. 130-141.
[3] ElMaraghy, H. A.: Changeable and Reconfigurable Manufacturing Systems. London 2009.
[4] Hammerstingl, V.: Unified Plug&Produce architecture for automatic integration of field devices in industrial environments. In: IEEE (Hrsg): 2015 IEEE International Conference on Industrial Technology (ICIT). Sevilla, Spanien 2015.
[5] Bundesamt für Sicherheit in der Informationstechnik: IT-Grundschutz-Kataloge M 2.399. URL: https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/In..., Abrufdatum 24.11.2015.
[6] Wienzek, P.; Uffelmann, J. R.: IO-Link – Intelligente Geräte brauchen einfache Schnittstellen. München 2010.
[7] Großmann, D.: Offene Integrationsplattform für das Feldgeräte-Management. Göttingen 2008.
[8] DIN EN 61987: Industrielle Leittechnik – Datenstrukturen und -elemente in Katalogen der Prozessleittechnik. 2010.
[9] DIN-Fachbericht IEC/TR 62390: Leitfaden für Geräteprofile in der Automatisierungstechnik. 2006.
[10] VDI-Fachbereich Produktionstechnik und Fertigungsverfahren: Montage- und Handhabungstechnik – Kenngrößen für Industrieroboter. Berlin 1988.
[11] IEC EN 61512: Chargenorientierte Fahrweise. 2000.
[12] Prinz, J.; Lüder, A.; Suchold, N.; Drath, R.: Design & Engineering – AutomationML – Integriertes Engineering durch die standardisierte Beschreibung mechatronischer Objekte durch Merkmale. In: VDI Berichte 2143, AUTOMATION 2011. Baden-Baden 2011.
[13] ZVEI: Die Industrie 4.0-Komponente. URL: http://www.zvei.org/Downloads/Automation/Industrie%204.0_Komponente_Down..., Abrufdatum 24.11.2015.
[14] ROS: About ROS. URL: http://www.ros.org/about-ros/, Abrufdatum 24.11.2015.
[15] Kroll, J.: IEC-Meeting: Normung für Industrie 4.0. URL: http://www.computer-automation.de/feldebene/vernetzung/artikel/108790/1/, Abrufdatum 24.11.2015.
[16] Manzei, C.; Schleupner, L.; Heinze, R.: Industrie 4.0 im internationalen Kontext – Kernkonzepte, Ergebnisse, Trends. 1. Auflage, Berlin 2015.
[17] Bundesamt für Sicherheit in der Informationstechnik (BSI): Sicherheitsanalyse OPC UA. URL: https://www.bsi.bund.de/DE/Publikationen/Studien/OPCUA/OPCUA_node.html, Abrufdatum 2016.
[18] Hammerstingl, V.; Moule, L.; Reinhart, G.: Bildverarbeitungssysteme als cyber-physische Sensoren. In: atp edition 11 (2015), S. 44-57.