AutomationML™ verbindet Werkzeuge der Fertigungsplanung – Hintergründe und Ziele

Alexander Alonso Garcia, Daimler AG

Dr. Rainer Drath, ABB Forschungszentrum Ladenburg

Kurzfassung: Dieser Beitrag stellt Hintergründe und Ziele des neutralen Datenformats AutomationML™ vor, das die bestehende Kluft zwischen Werkzeugen der Fertigungs- und Automatisierungsplanung schließen soll. Weiterhin werden die Säulen des Datenformates sowie die Vorgehensweise bei der Entwicklung erläutert. AutomationML™ versteht sich als wegweisender Beitrag zur Förderung der Interoperabilität zwischen digitalen Werkzeugen für alle Teilschritte des Engineering-Prozesses in der Fertigungsplanung. Diese Aktivität wurde von Daimler initiiert und wird gemeinsam mit führenden Automatisierungsanbietern vorangetrieben. AutomationML™ wird bereits im Jahr 2007 präsentiert und zukünftig als offener und freier Standard zur Verfügung gestellt.

Motivation Die Idee der digitalen Fabrik ist seit Jahrzehnten sowohl im universitären als auch industriellen Umfeld bekannt. Eine durchgängige computergestützte Planung von Fertigungszellen oder -linien, in der der gesamte geometrische Aufbau, aber auch die Ablauflogistik detailliert geplant, simuliert, geprüft und nahtlos in Betrieb genommen werden können, ist bis heute technisch jedoch nicht gelöst.

Eine wesentliche Voraussetzung für einen durchgängigen digitalen Engineering-Workflow besteht in einer performanten Hardware – diese steht heute zu akzeptablen Preisen zur Verfügung. Die softwaretechnische Umsetzung hingegen hinkt deutlich hinterher. Dies erstaunt, wenn man den Blick aus der Fertigungsindustrie in andere Bereiche lenkt, in denen bereits heute aufwändige virtuelle 3D-Welten erstellt, simuliert und plattformübergreifend genutzt werden können. Die in der Fertigungsindustrie benötigten 3D-Konzepte sind mit denen der Computergrafikindustrie durchaus vergleichbar: Individuelle Objekte müssen geometrisch und kinematisch modelliert sowie ihr Verhalten und ihre Beziehungen zu anderen Objekten beschrieben werden. Konzepte wie Wiederverwendung, kontinuierliche Ergänzung der Objekte in ihrem gesamten Lebenszyklus, aber auch die Unterstützung unterschiedlicher Detaillierungsgrade bei der grafischen Darstellung sind hier längst etabliert. Selbst die plattformunabhängige Entwicklung von 3D-Computerspielen für unterschiedliche Zielsysteme ist bereits Stand der Technik. Können wir Fertigungsautomatisierer von Entwicklungskonzepten der Grafikindustrie lernen?

Ein Hauptgrund für die technologische Verzögerung der Fertigungstechnik sind die hohen Anforderungen an Stabilität, Anlagen- und Produktlaufzeit, Sicherheit und Qualität. Zudem hat sich die Fertigungsplanung im Laufe der Zeit in eine Reihe einzelner, spezialisierter Phasen mit modernen und leistungsfähigen, aber separaten Werkzeugen untergliedert. Die Phasen sind hierbei hauptsächlich sequentiell angeordnet, wie in Abbildung 1 dargestellt.

Abbildung 1: Übersicht der Engineering-Prozesskette im Karosseriebau

Wie die Abbildung zeigt, unterliegen die Daten im Laufe des Engineerings einer kontinuierlichen und iterativen Anreicherung und Veränderung. Ein Hauptproblem dabei besteht darin, dass der durchgängige Datenaustausch zwischen den Werkzeugen heute nicht ausreichend möglich ist. So lässt sich die heutige Engineering-Prozesskette typischerweise nur gezielt innerhalb der Systemlandschaft eines Herstellers und oft nur für Teile der Prozesskette schließen.

Weitere Probleme bei der Einführung eines durchgängigen, digitalen Engineering-Workflows bestehen sowohl für Betreiber als auch für Lieferanten fertigungstechnischer Anlagen unter anderem in der hochpreisigen Lizenzierungspolitik der Hersteller digitaler Planungswerkzeuge. Üblicherweise ist hier von fünfstelligen Kosten pro Arbeitsplatz und Jahr für die Software auszugehen. Weiterhin besteht die Notwendigkeit zur Anschaffung leistungsfähiger und teurer Hardware, um akzeptable Systemperformance zu erreichen. Diese Vorgaben an die Computerarchitektur und die damit verbundenen Kosten verhindern den Einsatz solcher Werkzeuge in der Produktion, z.B. als Kombination aus Visualisierungssystem und für den Anlagenbediener einfach zu bedienender Roboterprogrammierunterstützung. Abhilfe schaffen hier Werkzeuge anderer Hersteller, die sowohl auf die Bediener – in der Regel keine hochspezialisierten Ingenieure – als auch auf die Aufgabe, z.B. Parametrierung von Lackierprozessen, perfekt zugeschnitten sind. Die Integration dieser Werkzeuge in der genannten Tool-Kette ist häufig nicht oder nur teilweise möglich.

Ein weiterer Nachteil liegt in der häufig ungenügenden Möglichkeit der funktionalen Erweiterung der Werkzeuge durch den Anwender. Die entsprechenden Entwicklungslizenzen sind hochpreisig, und die damit entwickelten Softwarekomponenten sind nur mit Einschränkungen zu vertreiben.

Die Vielzahl der auf dem Markt befindlichen digitalen Planungswerkzeuge und die damit verbundenen Kosten zwingen Anlagenbetreiber, sich auf eine Werkzeugkette zu konzentrieren, während die Anbieter aufgrund der Kundenvielzahl unterschiedliche Werkzeugketten vorhalten müssen. Die damit verbundenen Mehrkosten spiegeln

sich in den Preisen der Lieferanten wieder, die von den Betreibern getragen und an den Endkunden weitergegeben werden müssen.

Abbildung 2: Analyse Investitionskostenstruktur Steuerungstechnik und Robotik-vereinfacht-Beispiel Rohbau (Quelle: AIDA 2005)

Betrachtet man in Abbildung 2 die Investitionskostenstruktur der Steuerungstechnik eines typischen Fahrzeugrohbaus, so fällt auf, dass nahezu die Hälfte der Investitionskosten durch die Engineering-Kette verursacht wird.

Sowohl Betreiber als auch Lieferanten sind daher an einem wirtschaftlichen und durchgängigen Datenaustausch zwischen digitalen Planungswerkzeugen interessiert: Allerdings existieren keine offenen, standardisierten und akzeptierten Austausch- oder Zwischenformate mit Blick auf die gesamte Prozesskette.

Anwendungsfälle Der Datenaustausch zwischen Werkzeugen der digitalen Fabrik bietet eine Vielzahl von Anwendungsfällen. Die folgende Abbildung 3 stellt einen schematischen Ausschnitt des Engineering-Workflows dar und benennt typische verwendete Werkzeuge in den einzelnen Phasen.

Abbildung 3: Typische Engineering-Kette und zugehörige Werkzeugtypen

Tabelle 1 stellt ein Auswahl typischer Werkzeugkategorien, sowie zugehörige, verfügbare Werkzeuge dar.

Werkzeugkategorie Werkzeug Hersteller

CATIA v4, v5 Dassault Systèmes

Autocad Autodesk

NX UGS

Computer Aided Design („CAD“)

MicroStation Bentley

Simple++/eM-Plant UGS Materialflusssimulation

Automatic Line Builder Dassault Systèmes Robotersimulation Cosimir EFR GmbH, RIF e.V.

Catia v5 Robotics Dassault Systèmes

Robcad UGS

Simulation

Elektrische Simulation PSPICE OrCAD

Textverarbeitung MS Word Microsoft

Tabellenkalkulation MS Excel Microsoft

Präsentation MS Powerpoint Microsoft

Access Microsoft

Büro

Datenbank Oracle Oracle

Projektmanagement MS Project Microsoft

UGS TeamCenter UGS Produkt Daten Management („PDM“)

Dassault Smartteam Dassault Systèmes

Product Life Cycle e-MPlaner UGS

Werkzeugkategorie Werkzeug Hersteller

Management („PLM“) Delmia E5 DPE Dassault Systèmes

SAP R3 SAP

Oracle Peoplesoft Oracle

Mock-up emEngineer UGS

Plant Visualization JViz netAllied

RSView Enterprise and Machine Editions Rockwell

Visualisierung Human Machine Interface („HMI“)

WinCC / WinCC Flexible Siemens

RSLogix 5000 Rockwell Programmable Logic Control, inkl. Safety („PLC“) STEP 7 Siemens

Robotstudio ABB

Steuerungs-programmierung

Robot Control KUKA SIM KUKA

Ruplan AUCOTEC AG Computer Aided Engineering („CAD“)

EPLAN EPLAN

Eco3DOnsite Dürr

Robotstudio ABB Prozesskonfiguration

Robscan Design/Control Trumph

Facility Management Microstation Bentley

Acrobat Adobe

Illustrator Adobe

Wiki Dokumentation

Excel Microsoft

AutomationDesigner Siemens Life Cycle Engineering („LCE“)

Comos Innotec

Tabelle 1: Übersicht über Werkzeugkategorien

Die Vielzahl der eingesetzten Werkzeuge verdeutlicht den Nutzen eines standardisierten Datenaustauschformates. Aus der Vielzahl denkbarer Szenarien ist insbesondere bidirektionaler Datenaustausch als besonders typischer Anwendungsfall zu nennen, beispielsweise von:

• 3D-Modellen zwischen CAD-Werkzeugen und mechanischen Simulationswerkzeugen in unterschiedlichen Detailstufen,

• kompletten virtuellen Fertigungszellen zwischen verschiedenen, mechanischen Simulationswerkzeugen,

• Ablaufbeschreibungen zwischen Mechatronik und Steuerungstechnik,

• Fertigungsdaten zwischen Layout- und Elektroplanungswerkzeugen.

Vorgehensweise Ein herstellerneutrales Datenformat für den durchgehenden Austausch von Engineering-Daten zu entwickeln – mit dieser Vorgabe initiierte Daimler im Jahr 2006 ein Konsortium bestehend aus dem ABB Forschungszentrum Ladenburg, der KUKA Robot Group, der Rockwell Automation, der Siemens Automation and Drives (A&D), den Unternehmen netAllied und Zühlke, sowie den Universitäten Karlsruhe und Magdeburg. Die dabei zu entwickelnde Automation Markup Language (AutomationML™) soll noch 2007 als kostenfreier, offener Standard zur Verfügung stehen. Von der Planung bis zur Inbetriebnahme und dem fortlaufenden Betrieb fertigungstechnischer Anlagen wird damit eine einheitliche Lösung zum Datenaustausch angestrebt.

Das Datenformat AutomationML™ ist neutral und bietet künftig viele Möglichkeiten, um Durchgängigkeit bei Programmierung, Bedienung und Datenaustausch der digitalen Werkzeuge zu erreichen.

„Mit AutomationML™ können wir unsere Zeit effizient für die Planung von neuen Anlagenkonzepten einsetzen, ohne jedes Mal erheblichen Aufwand in die Austauschbarkeit von Daten investieren zu müssen. Das spart nicht nur Geld, sondern wird bei konsequenter Umsetzung die Entwicklungsarbeit für alle Nutzer dauerhaft und wesentlich vereinfachen.“ [Anton Hirzle, Daimler, Leiter Automatisierungstechnologie und Simulation]

Eine Besonderheit dieser Aktivität besteht darin, dass Betreiber und Anlagenlieferanten gemeinsam mit dem Ziel an einem Tisch sitzen, alle wesentlichen technischen Herausforderungen und Interessen zu adressieren.

Die Herausforderungen beim Entwickeln eines Datenformates zum Zwecke einer Standardisierung sind vielfältig:

• Die durch das Format beschriebenen Inhalte müssen festgelegt und abgestimmt werden, damit es möglichst vollständig komplette fertigungstechnische Komponenten vom Spanner bis zur kompletten Rohbauzelle abbilden kann.

• AutomationML™ soll von der ersten Version an produktiv eingesetzt werden können, um die gewünschte Marktdurchdringung zu erreichen. Dies erfordert eine strikte Priorisierung von zu unterstützenden Anwendungsfällen.

• Es muss entschieden werden, ob das Datenformat von Grund auf neu entwickelt wird, mit den Vorteilen eines passgenauen und domänenspezifischen Zuschnitts, oder ob das Datenformat durch Wiederverwendung und Kombination bereits vorhandener, standardisierter Datenformate entwickelt wird, die ihren Nutzen, ihre Reife und ihre Verwendbarkeit bereits nachgewiesen haben und am Markt verbreitet sind.

• Es muss entschieden werden, ob und wie native Daten, z.B. SPS-Code, in das Format eingebettet werden sollen und bis zu welchem Detaillierungsgrad die Daten herstellerunabhängig speicherbar sind.

AutomationML™ folgt dem Ansatz, existierende Standards zu kombinieren. Die Auswahl der zu verwendenden Datenformate ist dabei kritisch, denn viele Standards sind mit kommerziell hinderlichen Randbedingungen versehen. Um die gewünschte Standardisierung und angestrebte, breite Marktakzeptanz zu erreichen, achtet die AutomationML™ vor Allem auf folgende Anforderungen:

• die Lizenzierung ist kostenfrei,

• das Format befindet sich nicht im Besitz eines einzelnen Unternehmens,

• das Format deckt möglichst viele Teilbereiche der Prozesskette in der Anlagenplanung ab,

• das Format ist nicht zu sehr spezialisiert,

• das Format besitzt bereits eine hohe Marktverbreitung.

Die Säulen der AutomationML™ AutomationML™ soll Planungsdaten moderner Softwarewerkzeuge neutral speichern können. Aktuelle Werkzeuge folgen hierbei der konsequenten Einführung objektorientierter Konzepte. Objektorientierung ist eine wesentliche Methodik zur Beherrschung von Komplexität und ist in der Softwareentwicklung aus diesem Grunde seit langem erfolgreich etabliert. AutomationML™ basiert deshalb ebenfalls auf dem Objektgedanken, in dem reale Komponenten der Fertigungstechnik durch Objekte beschrieben werden, die unterschiedliche Aspekte der Komponente kapseln. Ein Objekt kann aus mehreren Unterobjekten bestehen und selbst Teil eines größeren Objektes sein. Beispielsweise sind eine Schraube, ein Greifer, ein Roboter oder eine gesamte Fertigungszelle als einzelne Objekte zu verstehen. Jedes Objekt kann hierbei in unterschiedlichen Detaillierungsgraden abgebildet werden.

Typische in AutomationML™ abzubildende, fertigungstechnische Planungsdaten umfassen Informationen über die Anlagentopologie, Geometrie, Kinematik sowie dem Ablaufverhalten.

• Topologie: Die Anlagentopologie beschreibt die Eigenschaften und Relationen der Anlagenobjekte in ihrer hierarchischen Struktur.

• Geometrie: Die Geometrie ist als grafische Eigenschaft eines Objektes zu verstehen. Jedes Objekt kann durch mehrere Geometrien beschrieben werden, welche unterschiedliche Zustände oder Detaillierungsgrade eines Objektes darstellen können.

• Kinematik: Die Kinematik beschreibt geometrische Verbindungen zwischen Objekten und dient der Bewegungsplanung.

• Ablaufbeschreibung: Das Ablaufverhalten beschreibt den zeitbasierten oder ereignisbasierten Ablauf sequentieller oder paralleler Prozesse in der Fertigungstechnik. Diese wird zur Simulation der Anlage erstellt und kann später als Grundlage des Steuerungsentwurfs weiterverwendet werden.

Für die Entwicklung von AutomationML™ werden unterschiedliche Standards zur Beschreibung der genannten Daten hinsichtlich ihrer Eignung für AutomationML™ geprüft. Dadurch soll der vorhandene Reifegrad der bestehenden Standards in AutomationML™ einfließen und der Entwicklungsaufwand somit reduziert werden.

AutomationML™ basiert auf XML und wird als offener und kostenloser Standard zur Verfügung stehen.

Zusammenfassung und Ausblick AutomationML™ wird von Herstellern und Nutzern der Automatisierungstechnik in enger Zusammenarbeit entwickelt. Dies stellt sicher, dass heutige und künftige Anforderungen an moderne Planungsmethoden in den Bereichen Geometrie, Kinematik und Ablauflogik erfüllt sind. Im Rahmen der Messe für elektrische Automatisie-rungstechnik SPS/IPC/Drives im November 2007 in Nürnberg wird das neue Datenformat präsentiert und in Zukunft als kostenfreier Standard allgemein zur Verfügung stehen.

Kontakt und weitere Infos http://www.automationml.org