Beispielimplementation eines Austauschs von Digitalen Zwillingen mit dem Konzept der Asset Administration Shell 

Die Asset Administration Shell (AAS) ist ein aufstrebendes Konzept im Zusammenhang mit der Datenhaltung eines Digitalen Zwillings. Es handelt sich dabei um eine virtuelle Repräsentation einer physischen oder logischen Einheit, wie beispielsweise einer Maschine oder eines Produkts. Die AAS ermöglicht es, relevante Informationen über diese Einheit zu sammeln, zu verarbeiten und zu nutzen, um eine effiziente und intelligente Produktion zu gewährleisten. Die Architekturstandardisierung der AAS ermöglicht die Kommunikationen zwischen digitalen Systemen und ist damit die Grundlage für Cyber Physical Systems (CPS). Die Herleitung des Bedarfs eines Digitalen Zwillings in der Industrie finden Sie hier: ZEISS Digital Innovation Blog – Der digitale Zwilling als eine Säule von Industrie 4.0 

Dieser Artikel beschäftigt sich mit der konkreten Implementierung eines Beispiels. In einem Szenario wollen wir mit Hilfe einer Referenzimplementierung des Fraunhofer-Institut für Experimentelles Software Engineering IESE (BaSyx Implementierung der AAS v3) einen Austausch von Informationen zwischen zwei beteiligten Partnern herstellen. Beide Beteiligten sind dabei einfachheitshalber innerhalb eines Unternehmens angesiedelt und teilen sich die Infrastruktur. 

Hinweis: Auch über Unternehmensgrenzen hinweg kann diese Anwendung verteilt werden. Die dabei zu berücksichtigenden sicherheitskritischen Aspekte sind nicht Teil dieses Szenarios. 

Szenario 

Werk A ist Hersteller von Messkopfzubehör und stellt u. a. Taster her. 

Werk B stellt Messköpfe her und möchte Taster von Werk A an ihrem Messkopf verbauen. 

Zusätzlich zur physischen Weitergabe des Tasters müssen Informationen ausgetauscht werden. Die Verkaufsabteilung von Werk A stellt Kontaktinformationen zur Verfügung, damit der technische Einkauf von Werk B Preise sehen und verhandeln kann. Weiterhin muss Werk A z. B. ebenfalls eine Dokumentation zur Verfügung stellen. 

Für diesen Austausch der beiden Informationen: 

  • Kontaktdaten und 
  • Dokumentation 

soll das Konzept der AAS zum Einsatz kommen. 

Infrastruktur 

Für unser Szenario wollen wir den Typ 2 der Asset Administration Shell verwenden. Dabei wird die AAS auf Servern zur Verfügung gestellt und es findet nicht ein Austausch von AASX-Dateien statt, sondern eine Kommunikation zwischen den unterschiedlichen Services via REST-Schnittstellen. 

In unserem Szenario laufen die unterschiedlichen Services innerhalb eines Kubernetes Clusters in Docker Containern. 

Services 

Wir nehmen die BaSyx Implementierung her, um die AAS zur Verfügung zu stellen. Genauer gesagt, folgende Komponenten: 

  • AAS Repository, 
  • Submodel Repository, 
  • ConceptDescription Repository, 
  • Discovery Service, 
  • AAS Registry sowie 
  • eine Submodel Registry. 

AAS Repository, Submodel Repository und ConceptDescription Repository werden dabei innerhalb eines Containers zur Verfügung gestellt – dem AAS environment. 

Technische Umsetzung 

Die Kommunikation erfolgt dabei nur mittels API-Aufrufen an die entsprechenden REST-Schnittstellen der Services. 

Wir werden dabei einfache Python-Skripte nutzen, um eine Kommunikation darzustellen, bei dem das Herstellerwerk B Informationen zu einem Produkt (hier: ein Taster für einen Sensor) des Komponentenwerks A erhalten will. 

Ablauf 

Werk B kennt nur eine Asset ID von einem Taster, aber weiß sonst nichts über diese Komponente. 

  1. Werk B fragt mit der Asset ID den Discovery Service an, um an eine AAS ID zu gelangen. 
  1. Mit dieser AAS ID wird die zentrale AAS Registry angefragt, die den AAS Repository Endpunkt des Werk A zur Verfügung stellt. 
  1. Über diesen Endpunkt und die AAS ID erhält Werk B die komplette Asset Administration Shell inkl. der relevanten Submodel-IDs. 
  1. Mit diesen Submodel-IDs (u.a. für Kontaktinformationen und Dokumentation) fragt B die Submodel Registry von A an und erhält die Submodel Repository Endpunkte. 
  1. B fragt die Submodel-Endpunkte an und erhält die kompletten Submodel-Daten. Zu diesen Daten gehört die gewünschte KontaktiInformation für den Einkäufer und eine komplette Dokumentation zu dem Taster-Asset. 

Im Folgenden wird der Ablauf noch einmal im Detail mittels UML-Sequenz-Diagrammen dargestellt. 

UML-Sequenz: Erstellung Registrierung AAS im Komponenten-Werk A 

Das Werk A ist für die Registrierung ihrer eigenen Komponente zuständig. 

Abbildung 1: UML-Sequenz: Erstellung Registrierung AAS im Komponentenwerk A 

UML-Sequenz: Anfordern der Komponentendaten 

Das Werk B benötigt Daten zu der Komponente und fragt entsprechend in der AAS-Infrastruktur an. Hierbei steht dem Werk B ggf. nur die Asset ID der Komponente zur Verfügung, in unserem Fall die des Tasters. 

Abbildung 2: UML-Sequenz: Anfordern der Komponentendaten 

Implementierung 

Damit der oben beschriebene Ablauf funktioniert, müssen zum einen die erwähnten Services zur Verfügung gestellt werden. Zum anderen müssen Shells und Submodelle angelegt werden und zusätzlich in den Registries hinterlegt werden.  

Bereitstellung der Services 

Die Bereitstellung erfolgt via Docker Container, die innerhalb eines Kubernetes Clusters laufen. Hierbei bekommt jedes BaSyx Image ein Kubernetes Deployment welches via Kubernetes Replica-Sets die entsprechenden Pods starten.  
Mittels z. B. Port-Forwarding werden die entsprechenden Ports vom Host erreichbar gemacht. Dieses ist notwendig um die APIs entsprechend von den Beispiel-Python-Skripten anzusprechen. 

Die Kubernetes Deployment Konfiguration schaut folgendermaßen aus und ist dabei relativ einfach gehalten. Es existieren vier Deployments mit jeweils einem Replica-Set. 

Abbildung 3: Kubernetes-Deployment-Konfiguration 

Erzeugen der AAS von Werk A 

Werk A möchte z. B. die Kontaktinformationen zu seiner Taster-Komponente zur Verfügung stellen. 

Dazu werden Submodelle im AAS Repository erzeugt (hier: im AAS-Environment) und in der Submodel Registry registriert. 

Danach wird die Asset Administration Shell im AAS Repository erzeugt und der AAS Registry registriert. 

Anschließend wird im AAS Repository die Referenz der Shell hinzugefügt. 

Hiermit ist der Registrierungs-Prozess vom Komponentenwerk abgeschlossen. 

Anfragen von Kontakt-Informationen vom Werk B 

Werk B möchten die Kontakt-Informationen erhalten und fragt entsprechend dem oben beschriebenen Workflow die unterschiedlichen AAS-Services an. Am Ende wird der Submodel-Datensatz abgerufen, der die gewünschten Werte enthält und kann dann z. B. innerhalb eines User-Interfaces zur Verfügung gestellt werden. 

Fazit 

Die Asset Administration Shell vom Typ 2 ist ein verteiltes System, welches auf die entsprechenden Repositories, Registries und den Discovery Service baut. In unserem Beispiel haben wir nur ein einfaches Submodel-Template für Kontaktdaten verwendet. Allerdings stehen weitaus mehr Templates für viele Anwendungsfälle zur Verfügung. 

Die Kommunikation zwischen den Services zur Bereitstellung und zum Abruf der Daten ist relativ unkompliziert möglich, wobei in diesem Szenario Aspekte wie z. B. Sicherheit nicht im Fokus waren. 

Die in diesem Artikel beschriebene Beispielimplementierung lässt das enorme Potential des AAS-Konzepts erahnen und regt dazu an, konkrete Umsetzungen zu starten. 

Dieser Beitrag wurde verfasst von:

Daniel Brügge

Daniel Brügge arbeitet als Softwareentwickler bei ZEISS Digital Innovation mit dem Fokus auf Cloud-Entwicklung und verteilte Anwendungen.

Alle Beiträge des Autors anzeigen

Der digitale Zwilling als eine Säule von Industrie 4.0

Ab den 1970er Jahren hielten Computer und Automatisierungstechnik Einzug in die Produktion. Flexible Massenproduktion war nun abseits von Fließbändern möglich. Maschinen wurden hinsichtlich maximalem Werkstückdurchsatz optimiert. Dieser bis in die 2000er Jahre anhaltende Prozess wird allgemein als dritte industrielle Revolution bezeichnet.

Die nun in den 2010er Jahren u.a. von der Bundesregierung postulierte „Industrie 4.0“ hat andere Ziele. Da die Produktivzeiten von Maschinen und ganzen Produktionstrecken in vielen Branchen weitestgehend optimiert sind, nimmt man sich nun der Optimierung von unproduktiven Zeiten an. Unproduktive Zeiten bestehen im Wesentlichen aus den Zuständen Maschinenstillstand und Ausschussproduktion.

Zwei wesentliche Ansätze zur Optimierung der unproduktiven Zeiten

Streben nach einer 100% Auslastung aller Maschinen

Erfüllen meine Produktionsmaschinen gerade nicht die Aufgabe, für die sie eingekauft und installiert worden sind, sind sie unproduktiv und erwirtschaften keinen Mehrwert. Man unterscheidet in geplanten und ungeplanten Stillstand. Einem geplanten Stillstand wird entgegengewirkt, indem man die Maschine flexibel an mehreren Stellen in der Produktionskette einsetzt. So wird insgesamt eine höhere Auslastung erreicht. Ein gut vorstellbares Beispiel ist ein 6-Achs Roboter mit einem Greifer, den man flexibel von einem Arbeitsplatz zum nächsten bringen kann, je nachdem, wo gerade Arbeit zu verrichten ist. Bei diesem Konzept spricht man von Wandelbarkeit der Produktion. Ungeplante Stillstände gehen meist auf Komponenten- und Baugruppenausfälle innerhalb einer Maschine zurück. Hier gilt es, die Wartung von Maschinen so zu organisieren, dass nur innerhalb von geplanten Zeiträumen Wartungen durchgeführt werden (vorausschauende Wartung).

Reduzierung des Ausschusses

Ein zweiter großer Ansatzpunkt ist die Reduzierung des Ausschusses. Dabei unterstützt die Prozesskontrolle, die nach jedem Arbeitsgang oder schon während eines Arbeitsganges erfolgen sollte. Aufbauend auf die Prozesskontrolle ist die Prozessregelung. Dabei werden Erkenntnisse aus der Prozesskontrolle zurück in den Arbeitsgang (Prozess) geführt und somit das Ergebnis der nächsten Durchführung des Arbeitsganges verbessert. Bei einem einzelnen Arbeitsgang kann man sich dieses Vorgehen noch sehr gut vorstellen: z.B. wird nach dem Fräsen einer Kreiskontur der Durchmesser des Kreises gemessen, bewertet und bei Abweichungen entsprechend das Fräsprogramm für das nächste Teil angepasst. Komplexere Ansätze verfolgen das Ziel, eine Prozesskontrolle über mehrere Arbeitsschritte oder sogar über Arbeitsschritte verteilt auf mehrere Unterlieferanten zu steuern.

Daten als Schlüssel zur besseren Planung

Beide Ansätze zur Produktionsoptimierung werden zum großen Teil über eine bessere Planung und Kontrolle von Prozessen beeinflusst. Bessere Planung bedingt einen deutlich größeren Pool an verschiedensten Daten, die gezielt ausgewertet werden müssen. Dabei übersteigen die Anzahl und Detaillierung der Daten die Auffassungsgabe von Menschen deutlich. Es werden komplexe Softwarelösungen gebraucht, um einen Nutzen (Mehrwert) aus diesen Daten zu erzeugen.

Je nach Reifegrad der Daten und Reifegrad der Auswertungen werden die Entscheidungen, die ein Mensch in einem Produktionsumfeld treffen muss, mehr und mehr durch Software unterstützt, bis hin zur völligen Autonomie der Produktion. Um den aktuellen Zustand der eigenen Produktion zu reflektieren, hilft das in Abbildung 1 dargestellte Data Analytics Maturity Model. Es zeigt eine Übersicht zum Zusammenhang zwischen Reifegrad der Daten und den möglichen Auswirkungen von Software auf den Entscheidungsprozess.

Data Analytics Maturity Model. Abbildung frei nach Hagerty
Abbildung 1: Data Analytics Maturity Model. Abbildung frei nach Hagerty[1]

In der niedrigsten Stufe des Modells (Descriptive) geben die Daten nur Auskunft über die in der Vergangenheit liegenden Ereignisse einer Maschine oder einer Produktionstrecke. Es benötigt viel menschliche Interaktion, Diagnose und zuletzt eine menschliche Entscheidung, um die geeignete Maschinenaktion auszulösen und umzusetzen. Je reifer die Daten sind (Diagnostic und Predictive Stufe), umso weniger menschliche Interaktion ist notwendig. In der höchsten angestrebten Stufe (Prescriptive) ist es möglich, dass Software völlig autonom alle Produktionsvorgänge plant und umsetzt.

Aspekte von Daten eines digitalen Zwillings

Die Erhebung von Daten jeglicher Art führt schnell zur Problematik der Sortierung und Ordnung. Stellen wir uns ein einfaches Bauteil bzw. eine Komponente vor, wie in Abbildung 2 dargestellt. Während des Betriebes dieses Bauteils innerhalb einer Produktionsmaschine fallen zyklische Live -Daten an. In anderen Lebensphasen, z.B. während der Herstellung dieses Bauteils, sind Daten wie Stückliste und technische Zeichnungen interessanter. Möchte man Daten erheben, ohne auf das Vorhandensein des Bauteils angewiesen zu sein, bietet sich das 3D Modell und ein funktionierendes Verhaltensmodell an, mit dem man Zustände und Funktionen simulieren kann.

Abbildung 2: Verschiedene Aspekte von Daten anhand des Beispiels Zeiss Stylus straight M5

Die meisten Menschen denken bei dem Schlagwort Digitaler Zwilling zunächst nur an ein 3D Modell, welches mit Verhaltensdaten angereichert wurde und für Simulationen verwendet werden kann. Im Kontext von Industrie 4.0 ist das allerdings nur ein Aspekt unter vielen.

Die Initiative Plattform Industrie 4.0 hat folgende Definition für einen digitalen Zwilling gewählt:

Ein digitaler Zwilling ist eine digitale Repräsentation eines Produktes*, die ausreicht, um die Anforderungen einer Menge von Anwendungsfällen zu erfüllen.

Mit dieser Definition ist ein digitaler Zwilling schon geschaffen, wenn der Aspekt meines konkreten Anwendungsfalles abgedeckt wurde. Je nach Sicht und Anwendungsfall wird es also sehr verschiedene Ausprägungen von digitalen Zwillingen geben. Wichtig ist nur, dass man sich mit seinem Gesprächspartner vorher verständigt, unter welchen Aspekten man über einen digitalen Zwilling spricht.

Digitaler Zwilling: Typ und Instanz

Um weiter ein besseres Verständnis um den Digitalen Zwilling zu erlangen, unterscheiden wir in die zwei Zustände Typ und Instanz:

Typ eines digitalen Zwillings: Beschreibt alle generischen Eigenschaften aller Produkt-Instanzen. In der Softwareentwicklung ähnelt es am ehesten einer Klasse. Am häufigsten nutzt man Digitale Zwillingstypen in den Lebensphasen vor der Herstellung des Produktes, also z.B. in der Engineering Phase. Digitale Zwillingstypen werden häufig mit einer Testumgebung verknüpft, in der man versucht Eigenschaften des digitalen Zwillings zu optimieren um dann später auch das reale Produkt verbessert herzustellen.

Instanz eines digitalen Zwillings: Beschreibt den digitalen Zwilling von genau einem konkreten Produkt und ist eindeutig mit ihm verbunden. Die digitale Zwillingsinstanz existiert nur einmalig weltweit. Allerdings ist es durchaus möglich, dass eine Instanz eines digitalen Zwillings nur einen bestimmten Aspekt des konkreten Produktes abbildet. Somit können mehrere digitale Zwillinge im Kontext unterschiedlicher Aspekte nebeneinander existieren. In der Softwareentwicklung entspräche es am ehestem einem Objekt. Digitale Zwillingsinstanzen verwendet man am häufigsten im Zusammenhang mit dem Betrieb eines konkreten Produktes. Oft werden digitale Zwillingsinstanzen von Typen abgeleitet (analog der Softwareentwicklung, wo Objekte von Klassen abgeleitet werden).

Digitaler Zwilling im Herstellungsprozess

Im Kontext von Industrie 4.0 und somit im Kontext eines Herstellungsprozesses sollte man sich stets dazu verständigen, ob man bei einem Digitalen Zwilling über die Produktionsmaschine oder über das Werkstück (Produkt) spricht, um Missverständnissen vorzubeugen. Beides kann einen Digitalen Zwilling besitzen, deren Anwendungsfälle sind aber sehr verschieden.

Digitaler Zwilling von Maschine und Werkstück. Beides ist möglich.
Abbildung 3: Digitaler Zwilling von Maschine und Werkstück. Beides ist möglich.

Steht die Planung der eigenen Produktion im Vordergrund meiner Überlegungen, werde ich mich wahrscheinlich mehr mit den digitalen Zwillingen meiner Produktionsmaschinen beschäftigen. Liegt mein Fokus auf der Anreicherung von Daten für meine Werkstück, und damit für mein Produkt, steht der Digitale Zwilling von eben jenem im Vordergrund. Es gibt keine klare Nutzungstrennung. Beide Betrachtungsweisen können sowohl für mich und meine Produktion genutzt werden als auch nützlich für den Nutzer meiner Produkte sein.

Einordnung digitaler Zwillinge nach dem Informationsfluss

Für eine weitere Unterscheidung in der Evolution vom digitalen Modell zum digitalen Zwilling gibt es Charakterisierungen nach dem Informationsfluss vom realen Objekt zum digitalen Objekt[2].

Digitale Modelle von Objekten sind heute schon Industriestandard. Ein prägnantes Beispiel ist das 3D Modell eines Bauteils. Es wird manuell mit Informationen angereichert (z.B. mit einem 3D CAD Programm) und man schaut sich manuell interessante Aspekte an (z.B. eine Kollisionsprüfung mit anderen 3D Modellen). Wird ein digitales Modell im Produktionsprozess zyklisch und automatisch mit Daten angereichert, spricht man von einem digitalen Schatten. Ein einfaches Beispiel wäre ein Betriebsstundenzähler eines Objektes, der automatisch durch das reale Objekt getriggert und im digitalen Objekt gespeichert wird. Auswertungen würden weiterhin manuell geschehen. Hin und wieder wird auch der Begriff digitaler Fußabdruck analog zu Digitaler Schatten verwendet. Gibt ein digitaler Schatten nun automatisch Informationen an das reale Objekt zurück und beeinflusst dessen Funktion, spricht man von einem digitalen Zwilling. Im Kontext der Plattform Industrie 4.0 spricht man weiterhin von einem cyber physischen System. Es ist Definition des Digitalen Zwillings und Realen Zwillings, welche über Datenströme miteinander verknüpft sind und sich gegenseitig beeinflussen.

Definition von Digitalen Modell, Schatten und Zwilling aufgrund der Informationsflüsse
Abbildung 4: Definition von Digitalen Modell, Schatten und Zwilling aufgrund der Informationsflüsse[2]

Die Einordnung nach dem Informationsfluss ist nur für Instanzen des digitalen Zwillings hilfreich. Für Typen von digitalen Zwillingen wird diese Einordnung nicht verwendet, weil das reale Objekt schlichtweg nicht existiert. Sind mehrere Aspekte innerhalb eines digitalen Zwillings zusammengefasst, sollte diese Art der Betrachtung für jeden Aspekt separat erfolgen, da unterschiedliche Aspekte in verschiedene Definitionen fallen können.

Vom digitalen Zwilling zur besseren Produktionsplanung

Die bis hier eingeführten Definitionen und Kategorisierungen sollten ausreichen, eine gemeinsame Sprache für die Beschreibung von Digitalen Zwillingen zu verwenden. Eine allumfassende Definition wird uns aktuell nicht gelingen, ist aber auch nicht notwendig.

Warum brauchen wir nun aber überhaupt Digitale Zwillinge?

Aus der Notwendigkeit von Daten und Auswertungen zur Effizienzverbesserung der Produktion könnte man die folgenden Schritte ableiten, um einen positiven Effekt zu erreichen:

  1. Zentralisieren von allen bisher schon anfallenden Daten
    Alle bisher schon anfallenden Daten z.B. einer Maschine werden aktuell in den meisten Betrieben in eigenen Systemen je nach Aspekt abgespeichert. So liegen z.B. Daten über die Wartung in einer Excel Tabelle beim verantwortlichen Meister, die Daten der Qualitätskontrolle der Werkstücke aber in einer CAQ Datenbank. Beide Datenaspekte sind nicht logisch verknüpft, obwohl sie einen direkten oder indirekten Zusammenhang haben könnten. Ob der Zusammenhang wirklich besteht, ist nicht ohne weiteres prüfbar. Erst wenn die Daten zentral und logisch verknüpft abgespeichert werden, ist es möglich Zusammenhänge (mit Hilfe von Software) zu erkennen. Daraus könnte ein Mehrwert generiert werden.
  2. Standardisierte Schnittstellen
    Werden Daten nun zentral abgespeichert, ist es von Vorteil das diese über standardisierte Schnittstellen erreichbar sind. Ist das der Fall, lassen sich sehr einfach automatische Informationsflüsse programmieren. Der Schritt vom einfachen Modell hin zum cyberphysischen System ist damit einfacher zu bewältigen. Der damit entstehende digitale Zwilling einer Komponente oder einer Maschine ist eine Grundlage für weiter folgende Auswertungen.
  3. Aufsetzen von Business Logik
    Sind alle Grundlagen für automatisierte Datenauswertungen geschaffen, ist es nun einfacher möglich, Software zu nutzen, die hilft, bessere Entscheidungen zu treffen oder gänzlich allein zu entscheiden (Business Logik). Hier entsteht nun der angestrebte Mehrwert.

Während Schritt 1 und 2 keinen oder nur wenig merkbaren Mehrwert schaffen, sind sie Grundlage für den Schritt 3.

Obwohl ich immer dafür plädiere eine Änderung oder Verbesserung im Produktionsprozess stets Anwendungsfall getrieben durchzuführen, kommt man schnell zu der Erkenntnis, dass ein gewisser Basisaufwand notwendig sein wird. Die Erstellung von digitalen Zwillingen ist eine notwendige Basis für den zukünftigen Erfolg. Somit sind sie eine wichtige Säule im Kontext von Industrie 4.0.

Praktischer Lösungsweg

Um möglichst klein anfangen zu können, später aber darauf agil aufzubauen, eignet sich das Konzept der Asset Administration Shell der Plattform Industrie 4.0. In diesem Konzept sind allgemeingültige Schnittstellen vordefiniert. Anwendungsfall spezifische Schnittstellen können leicht nachgerüstet werden. Dieses Konzept bietet Grundlagen für die Erstellung eines standardisierten digitalen Zwillings einer jeden Komponente. Ob man nun dieses Konzept als Startpunkt wählt oder ein komplett eigenes Informationsmodell programmiert ist sicherlich Geschmackssache.

Verbreitete Standards haben aber die Vorteile, dass Daten interoperabel sein können, was vor allem in Kunden/Lieferanten Beziehungen sehr von Vorteil ist. Auch ist zu erwarten, dass es auf dem Markt wiederverwendbare Software geben wird, die eben genau mit diesen Standards umzugehen vermag. Die Industrietauglichkeit des Konzeptes Asset Administration Shell zur Erstellung von Digitalen Zwillingen ist in 2022 erreicht worden und verbessert sich zunehmend. Es wird nun Zeit komplexe Projekte damit umzusetzen.

Quellen:

[1] J. Hagerty: 2017 Planning Guide for Data and Analytics. Gartner 2016

[2] W. Kritzinger, M. Karner, G. Traar, J. Henjes und W. Sihn: 2018 Digital Twin in manufacturing: A categorical literature review and classification.

*Die originale Definition wählt das Wort Asset, anstatt Produkt. Ich verwende hier aber die vereinfachte Wortwahl, auch wenn das nicht vollumfänglich ist.

Kinematische Simulation für Anfänger

Einleitung

Kundenindividuelle Massenproduktion, demografischer Wandel, Arbeitskräftemangel und Verlagerung von Produktionsstätten sind einige der globalen Herausforderungen, mit denen produzierende Unternehmen weltweit konfrontiert werden. Folglich verlangen Produktionsstandorte in Hochlohnländern nach hochautomatisierten und flexiblen Produktionssystemen, um wettbewerbsfähig zu bleiben. Industrieroboter und Sondermaschinen haben sich bei der Bewältigung einiger dieser Herausforderungen als wichtige Hilfsmittel und Wegbereiter erwiesen. Die flexible Programmierung solcher Fertigungssysteme ermöglicht es, Aufgaben wie Handhabung, Transport und verschiedene Produktionsprozesse automatisch mit hoher Präzision, Geschwindigkeit und Qualität durchzuführen.

Zwar wurden die Vorteile solcher Produktionssysteme vielfach nachgewiesen, es ist jedoch zu beachten, dass ein erheblicher Integrations- und Programmieraufwand erforderlich ist, bevor diese Systeme produktiv eingesetzt werden können. In den meisten Fällen erfordert die Softwareentwicklung für Produktionssysteme den Einsatz physischer Komponenten unter realen Bedingungen. Die Verfügbarkeit solcher Systeme ist jedoch häufig aus verschiedenen Gründen eingeschränkt, beispielsweise weil das System in Betrieb ist, parallel entwickelt wird oder im schlechtesten Falle überhaupt nicht existiert. Dieses Problem führt dazu, dass die Entwicklung der Software verzögert oder aufgeschoben wird, bis die erforderlichen physischen Komponenten verfügbar und integriert sind. Zudem gilt die Programmierung eines Industrieroboters als eine nicht gerade triviale Aufgabe, die qualifizierte Bedienende mit einem guten räumlichen Verständnis des Arbeitsbereichs und mit Fachkompetenz erfordert. Die Herausforderung besteht darin, eine Bewegungssequenz zu programmieren, die den Ablauf des Produktionsprozesses und die Prozessqualität sicherstellt und gleichzeitig Kollisionen vermeidet. Deshalb wird die Programmierung von Industrierobotern heutzutage häufig noch manuell durchgeführt und gilt als eine anspruchsvolle und ressourcenintensive Aufgabe.

Die Probleme der Roboterprogrammierung sind auf einer abstrakteren Ebene auch bei der Softwareentwicklung in anderen Bereichen anzutreffen. Es stellt sich also folgende Frage: Wie gehen Softwareentwickler mit diesen Problemen um, wenn es zum Beispiel keine Module oder Schnittstellen gibt? Die Antwort: Wir erstellen Mock-ups! In gewisser Weise sind Mock-ups nichts anderes als Modelle, die eine gewünschte Funktion simulieren. Allerdings klingt die Modellierung eines Roboters ein wenig komplizierter als die Implementation einer Datenbank oder einer Schnittstelle. Dieser Blogartikel soll das Gegenteil beweisen und zeigt in einem kurzen Tutorial, wie man kinematische Simulationsmodelle einfach und effizient erstellen kann, um die Programmierung solcher Fertigungssysteme zu erleichtern.

Dieser Blogbeitrag soll den Lesern Folgendes vermitteln:

  • Grundlegendes Verständnis von kinematischen Simulationsmodellen
  • Die Möglichkeit, ein einfaches kinematisches Modell eines Manipulators (z. B. Roboter, Drehtisch, Linearachsen) basierend auf freier und Open-Source-Software (FOSS) zu erstellen, das für Prototyping-, Entwicklungs- und Testzwecke verwendet werden kann

Kinematische Modellierung

Bezugssystem

Im Vorfeld der Simulation der Kinematik eines Robotersystems müssen zunächst einige grundlegende mathematische Konzepte und die im Zusammenhang mit der kinematischen Modellierung genutzte Terminologie verstanden werden. Zu diesem Zweck betrachten wir zunächst ein minimales System, das aus einem Drehgelenk \(j_1\) und eine Achse \(l_1\) besteht.

Die Achse ist starr mit dem Gelenk verbunden. Das bedeutet, wenn das Gelenk um seine z-Achse (Frame \(B_{j_1}\)) um einen Winkel von \(\phi_{j_1}\) rotiert, dreht sich die Achse \(l_1\) mit. Gehen wir hier davon aus, dass sich der Ursprungskoordinatenframe des Systems im Basiskoordinatenframe bei \(B_0\) befindet. Darüber hinaus beschreibt der Vektor \(p_0^w := (x, y, z, a^x, \beta^y, \phi^z)^T\) die Pose (Position und Rotation) der Achse im Arbeitsframe \(B_w\). Das kinematische 2D-Modell eines solchen Systems und seiner Komponenten ist links in Abbildung 1 dargestellt.

kinematisches Modell
Abbildung 1: Einfaches kinematisches Modell mit einem Drehgelenk und einer Achse

Kinematisches Modell

Wenn wir davon ausgehen, dass wir einige Bewegungen programmieren oder simulieren müssen, werden wir zwangsläufig mit mindestens einem der folgenden Probleme konfrontiert:

  • Inverskinematik-Problem: Welcher Winkel \(\phi_{j1}\) entspricht einer aktuellen Pose \(p_0^{w,act}\)?
  • Vorwärtskinematik-Problem: Welches ist die resultierende Pose \(p_0^w\) für einen gegebenen Gelenkwinkel \(\phi_{j1}^{act}\)?

Diese Fragen werden auf der rechten Seite von Abbildung 1 visualisiert und stellen die grundlegenden Probleme der kinematischen Modellierung dar, die als Inverskinematik- und Vorwärtskinematik-Probleme bezeichnet werden. Um diese Fragen zu beantworten, müssen zunächst alle räumlichen Beziehungen zwischen allen aufeinanderfolgenden[1] Frames des Systems abgeschätzt werden. Das heißt von der Basis \(B_0\) zum Gelenk \(B_{j1}\) und vom Gelenk \(B_{j1}\) zum Arbeitsframe \(B_w\). Die relativen räumlichen Beziehungen[2] zwischen zwei Frames werden durch die Translationskomponenten \(x_{\Delta}, y_{\Delta}\), und \(z_{\Delta}\) und die Rotationskomponenten \(\alpha_{\Delta}^x\), \(\beta_{\Delta}^y\), und \(\phi_{\Delta}^z\) modelliert. In Tabelle 1 sind die geometrischen Beziehungen für alle aufeinanderfolgenden Frames des kinematischen Systems von Abbildung 1 angegeben.

Base FrameReference FrameTranslationRotation
Basis \(B_0\)Gelenk \(B_{j_1}\)\(x_{\Delta}\) = 0, \(y_{\Delta}\) = 0, \(z_{\Delta}\) = \(d_0\)\(\alpha_{\Delta}^x\) = 0, \(\beta_{\Delta}^y\) = 0, \(\phi_{\Delta}^z\) = \(\phi_{j_1}\)
Gelenk \(B_{j_1}\)Arbeitsframe \(B_w\)\(x_{\Delta}\) = \(a_1\), \(y_{\Delta}\) = 0, \(z_{\Delta}\) = \(d_0\)\(\alpha_{\Delta}^x\) = -90°, \(\beta_{\Delta}^y\) = 0, \(\phi_{\Delta}^z\) = 0
Tabelle 1: Kinematische Beziehungen

Nachdem wir nun die geometrischen Beziehungen unseres Systems definiert haben, kann das kinematische Modell, mithilfe dessen die vorhergehenden Fragen beantwortet werden, beschrieben werden. Das Vorwärtskinematik-Model, dass die resultierende Pose für einen angeordneten Gelenkwinkel liefert, könnte beispielsweise mithilfe der in Abbildung 2 dargestellten trigonometrischen Beziehungen abgebildet werden.

Abbildung 2: Trigonometrische Beziehungen im Bezugssystem

\(x_0^w\) = \(a_1 \cos (\phi_{j1})\)

\(y_0^w\) = 0

\(z_0^w\) = \(d_0 + a_1 \sin (\phi_{j_1})\)

Obwohl diese geometrischen Funktionen die Kinematik unseres Bezugssystems ausreichend modellieren, ist hierbei zu beachten, dass die Beschreibung des kinematischen Modells auf diese Weise für komplexere Systeme mit mehreren Gelenken und Achsen nicht so einfach ist. Aus diesem Grund werden zur Berechnung von Mehrkoordinatentransformationen in der Regel andere mathematische Ansätze genutzt, z. B. homogene Matrizen oder Quaternionen. Die Beschreibung dieser Methoden würde den Rahmen dieses Blogbeitrags sprengen. Für den Rest des Artikels ist es ausreichend zu wissen, welche Eingaben und Ausgaben wir von einem kinematischen Modell erwarten können. Diese Modelle können als Black-Box-Komponenten angenommen werden, wie in Abbildung 3 dargestellt.

Vorwärtskinematik- und Inverskinematik
Abbildung 3: Vorwärtskinematik- und Inverskinematik-Black-Box-Modelle

Implementierung

Nach der Einführung der zentralen Konzepte der kinematischen Modellierung wird eine einfache Möglichkeit zur Implementierung kinematischer Ketten vorgestellt.

In der Industrie gibt es bereits eine Reihe von Spezifikationen und Formaten, die sich mit der Modellierung von kinematischen Ketten befassen, z. B. Collada, AutomationML, OPC UA Robotics. Unserer Erfahrung nach hat sich jedoch kein branchenweites Standardformat durchgesetzt. Dies stellt ein umfassenderes Problem auf dem Gebiet der Robotik dar, wo Programmiersprachen hauptsächlich herstellerspezifisch sind und es keine Standards für die Roboterprogrammierung oder -modellierung gibt. Dies ist einer der Gründe, weshalb das Robot Operating System (ROS) im Jahr 2010 ins Leben gerufen wurde. ROS ist eine FOSS-Robotik-Middleware, die verschiedene Bibliotheken (z. B. kinematische Modellierung, Wahrnehmung, Visualisierung, Bahnplanung) für die hardwareunabhängige Programmierung von Robotersystemen enthält. Diese Eigenschaften haben ROS zu einem Framework gemacht, das in der Robotikforschung als Stand der Technik gilt. Aufgrund der Beliebtheit und der Merkmale des ROS-Frameworks (z. B. Leistungsfähigkeit, Hardwareneutralität, FOSS, Modularität, Skalierbarkeit) haben Hersteller von Robotern und Feldgeräten (z. B. Greifer und Sensoren) sowie Drittanbieter von Software begonnen, Programmierschnittstellen für ROS anzubieten.

Im Rahmen der Entwicklung von ROS wurde das Unified Robot Description Format (URDF) zur Modellierung von kinematischen Ketten eingeführt. Beim URDF handelt es sich um ein offenes Standard-XML-Schema zur Beschreibung der geometrischen Beziehungen zwischen Gelenken und Achsen eines Roboters. Zusätzlich zur Modellierung kinematischer Ketten bietet das URDF die Möglichkeit, die physikalischen Eigenschaften von Gelenken zu modellieren (z. B. Trägheit, Dynamik und Achsenbegrenzungen) oder CAD-Dateien zur Modellierung der Volumeneigenschaften von Achsen zu verwenden, die für Kollisionstests genutzt werden können. Da das URDF einem XML-Schema folgt, können kinematische Modelle darüber hinaus einfach und lesbar dargestellt werden. So beschreibt der folgende Auszug in Abbildung 4 beispielsweise die kinematischen Beziehungen zwischen dem Gelenk j1 und der Achse l1 aus Tabelle 1.

Nachdem die geometrischen Beziehungen zwischen allen Achsen und Gelenken mithilfe einer URDF-Datei beschrieben wurden, kann das kinematische Modell visualisiert und zur Berechnung von Endeffektorpositionen oder erforderlichen Gelenkrotationen genutzt werden. ROS enthält eine Handvoll Pakete basierend auf Bibliotheken von Drittanbietern, die alle diese Funktionen implementieren. Die Verwendung dieser Bibliotheken ist in der ROS-Dokumentation beschrieben.

<!--Alle Achsen unseres Modells.-->
<!--Das Root-Frame in ROS wird base_link genannt und repräsentiert das Root-Frame (B_0) in unserem System. -->
<link name="base_link"/>
<!--Achse 1 unseres Modells. -->
<link name="link_1"/>
<!-- Der Arbeitsframe unseres Modells wird als Achse dargestellt.-->
<link name="work_frame"/>

<!--Alle Gelenke unseres Modells.-->
<!--Das Drehgelenk 1, das die Basisachse (parent-Achse) mit Achse 1 (child-Achse) verbindet, wird hier modelliert.
Das Gelenk befindet sich im Ursprung der child-Achse.-->
<joint name="joint_1" type="revolute">
	<parent link="base_link"/>
	<child link="link_1"/>
<!-- Auswahl der Rotationsachse, in unserem Fall um das Gelenk um die z-Achse in positiver Richtung.-->
	<axis xyz="0 0 1"/>
<!-- Hier wird die Transformation zwischen parent- und child-Achse angegeben.-->
<!-- Die Translationskomponenten (xyz) werden in Metern angegeben. -->
<!-- Die Rotation wird durch die Euler-Winkel (rpy) in Radianten ausgedrückt, und zwar nach folgender
 Notation (r)oll (x-Achsen-Rotation), (p)itch (y-Achsen-Rotation) und (y)aw (z-Achsen-Rotation). -->
	<origin xyz="0 0 0,4" rpy="1,57079632679 0,0 0,0"/>
<!-- Das Modell eines beweglichen Gelenks muss weitere physikalische Eigenschaften umfassen. -->
	<limit effort="100" lower="-0,175" upper="3,1416" velocity="0,5"/>
</joint>

Abbildung 4: URDF-Auszug zur Beschreibung der kinematischen Beziehung zwischen Gelenk \(j_1\) und Achse \(l_1\)

Erweitertes System

Nachdem die Grundlagen der kinematischen Modellierung und die Verwendung von URDF zur Implementierung eines kinematischen Modells verstanden wurde, steht der Beschreibung komplexerer kinematischer Ketten mit mehreren Gelenken, wie in Abbildung 5 dargestellt, nichts mehr im Wege.

Abbildung 5: Erweitertes kinematisches Modell unter Berücksichtigung eines Schub- und eines Drehgelenks

Die entsprechenden geometrischen Beziehungen sind in Tabelle 2 angegeben. Darüber hinaus ist das vollständige URDF im Anhang zu finden.

Base FrameReference FrameTranslationRotation
Basis \(B_0\)Gelenk \(B_{j_1}\)\(\Delta x\) = \(a_{j_1}\), \(\Delta y\) = 0, \(\Delta z\) = \(d_0\)\(\alpha_x\) = 0, \(\beta_y\) = 0, \(\phi_z = 0\)
Gelenk \(B_{j_1}\)Gelenk \(B_{j_2}\)\(\Delta\)x = \(a_2\), \(\Delta y\) = 0, \(\Delta z\) = 0\(\alpha_x\) = 90°, \(\beta_y\) = 0, \(\phi_z\) = 0
Gelenk \(B_{j_2}\)Arbeitsframe \(B_w\)\(\Delta\)x = \(a_3\), \(\Delta y\) = 0, \(\Delta z\) = 0\(\alpha_x\) = -90°, \(\beta_y\) = 0, \(\phi_z\) = 0
Tabelle 2: Kinematische Beziehungen im erweiterten System

Das URDF kann anschließend direkt in ROS zur Visualisierung und Positionierung von Gelenken verwendet werden, wie in Abbildung 6 dargestellt.

Gelenk1: \(a_{j_1}\) = -170mm, Gelenk2: \(\phi_{j_2}\) = -48°

Gelenk1: \(a_{j_1}\) = 80mm, Gelenk2: \(\phi_{j_2}\) = 52°

Abbildung 6: URDF-Visualisierung in ROS mit zwei verschiedenen Gelenkkonfigurationen und folgenden Werten: \(d_0\) = 300mm, \(a_2\) = 500mm, \(a_3\) = 200mm. Die Abbildung rechts zeigt auch die Integration von Oberflächenmodellen zur Modellierung der Volumeneigenschaften der Achsen.

Zusammenfassung und Ausblick

Die Programmierung eines Roboters ist eine komplexe und ressourcenintensive Aufgabe, die in den meisten Fällen auch die Nutzung des physikalischen Systems erfordert. Diese Hindernisse wirken sich direkt auf die Softwareentwicklung und Inbetriebnahme solcher Systeme aus. Ein kinematisches Modell (Mock-up) des Roboters hat das Potenzial, die Programmierung zu vereinfachen, ohne dabei das physische System zu benötigen, und gleichzeitig die Kosten zu senken. Allerdings gilt die Modellierung von Robotersystemen als eine nicht gerade triviale Aufgabe, die in einem ersten Schritt die Beschreibung ihres kinematischen Modells erfordert. Deshalb wurden in diesem Blogbeitrag zunächst die mathematischen Mindestgrundlagen zum Verständnis der kinematischen Modellierung vorgestellt. In einem weiteren Schritt haben wir anschließend gezeigt, wie kinematische Modelle mithilfe des Standardformats URDF nahtlos implementiert werden können.

Mit den Erkenntnissen in diesem Blogbeitrag sollten die Leser in der Lage sein, kinematische Modelle zu beschreiben, die als Mock-ups für Prototyping- oder Entwicklungszwecke eingesetzt werden können. Nachdem nun die erste Hürde der kinematischen Modellierung überwunden ist, können sich die Anwender solche Modelle mit folgenden Themen auseinandersetzen:

  • Bereitstellung kinematischer Modelle als Microservices für Entwicklungs-, Test- und Inbetriebnahmezwecke (weiterführende Literatur: Mocks in der Testumgebung)
  • Entwicklung anwenderfreundlicherer Programmier-Frameworks basierend auf kinematischen Simulationen unter Einsatz von VR (Virtual Reality) oder AR (Augmented Reality)

Minimales kinematisches Modell (URDF):

minimal_kinematic_model.urdf

Erweitertes kinematisches Modell (URDF):

extended_kinematic_model.urdf

[1] Aus diesem Grund werden diese Modelle im Allgemeinen als serielle kinematische Ketten bezeichnet. Es gibt auch parallele kinematische Modelle zur Darstellung von Delta-Robotern. Die kinematische Modellierung solcher Systeme wird im Rahmen dieses Blogbeitrags nicht behandelt.

[2] Auf dem Gebiet der Robotik wird die Transformation zwischen zwei Koordinatenframes häufig mit homogenen Transformationen und einer Gruppe von vier Parametern beschrieben, die die Translations- und Orientierungsverschiebung beschreiben. Diese Parameter werden als die Denavit-Hartenberg-Parameter bezeichnet.