AutomationML – die Motivation
Fortsetzung des Artikels von Teil 1
Autor:
 | |
 | beschäftigt sich bei Daimler-Chrysler mit dem Entwurf neuartiger Produktionskonzepte sowie der Entwicklung von Engineering-Werkzeugen. |
Diesen unbefriedigenden Ist-Zustand vor Augen, hat DaimlerChrysler zusammen mit dem ABB Forschungszentrum Ladenburg, den Firmen Kuka Roboter, Rockwell Automation, Siemens A&D, netAllied und Zühlke sowie den Universitäten Karlsruhe und Magdeburg eine Initiative gestartet, mit dem Ziel, eine einheitliche Lösung für einen herstellerneutralen Datenaustausch zu realisieren. Die Vorteile eines standardisierten Formats wären vielfältig; aus der Vielzahl denkbarer Szenarien seien an dieser Stelle nur folgende, typische Anwendungsfälle genannt:
- bidirektionaler Datenaustausch von 3D-Modellen zwischen CAD-Werkzeugen und mechanischen Simulationswerkzeugen in unterschiedlichen Detailstufen;
- bidirektionaler Datenaustausch von kompletten virtuellen Fertigungszellen zwischen verschiedenen, mechanischen Simulationswerkzeugen;
- bidirektionaler Datenaustausch von Ablaufbeschreibungen zwischen Mechatronik und Steuerungstechnik;
- bidirektionaler Datenaustausch von Fertigungsdaten zwischen Layout- und Elektroplanungswerkzeugen.
All dies soll das Datenformat AutomationML (Automation Markup Language), welches sich derzeit in der Entwicklung befindet, leisten können. Die Partner des Konsortiums sehen sich dabei mit folgenden Herausforderungen konfrontiert: AutomationML soll von der ersten Version an produktiv einsetzbar sein, um die gewünschte Marktdurchdringung zu erreichen. Dies erfordert eine strikte Priorisierung der Reihenfolge, nach der die unterschiedlichen Teilaspekte umgesetzt werden. Die durch das Format beschriebenen Inhalte müssen festgelegt und abgestimmt werden, damit sich auf dieser Grundlage fertigungstechnische Komponenten vom Spanner bis zur kompletten Rohbauzelle möglichst vollständig abbilden lassen. Weiterhin stellt sich die Frage, ob und wie native Daten wie beispielsweise SPSCode in das Format eingebettet werden sollen und bis zu welchem Detaillierungsgrad die Daten herstellerunabhängig speicherbar sind.
Grundsätzlich stehen die Entwickler von AutomationML vor der Entscheidung, ob das Datenformat von Grund auf neu zu entwickeln ist – mit allen Vorteilen eines passgenauen und domänenspezifischen Zuschnitts – oder ob die Entwicklung des Datenformates durch Wiederverwendung und Kombination bereits vorhandener, standardisierter Datenformate erfolgen kann, die ihren Nutzen, ihre Reife und ihre Verwendbarkeit bereits nachgewiesen haben und am Markt verbreitet sind. Leider sind viele Standard-Datenformate mit kommerziell hinderlichen Randbedingungen versehen, die sich nachteilig auf die gewünschte Standardisierung und angestrebte, breite Marktakzeptanz auswirken. Dazu gehören:
- die Lizenzierung ist kostenpflichtig,
- das Format befindet sich im Besitz eines einzelnen Unternehmens,
- das Format deckt nur Teilbereiche der Prozesskette in der Anlagenplanung ab,
- das Format ist zu spezialisiert,
- das Format besitzt trotz jahrelanger Existenz eine sehr geringe Marktverbreitung
Ein weiteres Problem bei der Einführung eines durchgängigen, digitalen Engineering-Workflow stellt sowohl für Betreiber als auch für Lieferanten fertigungstechnischer Anlagen die hochpreisige Lizenzierungspolitik der Hersteller etablierter digitaler Planungswerkzeuge dar. Üblicherweise ist hier von fünfstelligen Eurobeträgen pro Arbeitsplatz und Jahr für die Software auszugehen. Weiterhin besteht die Notwendigkeit zur Anschaffung leistungsfähiger und teurer Hardware, um eine akzeptable System-Performance zu erreichen.
Diese Vorgaben an die Computer-Architektur und die damit verbundenen Kosten verhindern den Einsatz solcher Werkzeuge in der Produktion, etwa als Kombination aus Visualisierungssystem und einer für den Anlagenbediener einfach zu bedienenden Roboter-Programmierunterstützung. Abhilfe schaffen hier Werkzeuge anderer Hersteller, die sowohl auf die Bediener – in der Regel keine hoch spezialisierten Ingenieure – als auch auf die Aufgabe, wie etwa die Parametrierung von Lackierprozessen, perfekt zugeschnitten sind. Die Integration dieser Werkzeuge in der genannten Tool-Kette ist jedoch häufig entweder gar nicht oder nur teilweise umsetzbar. Oft existieren zudem nur unzureichende Möglichkeiten einer funktionalen Erweiterung der Werkzeuge durch den Anwender selbst.
Die entsprechenden Entwicklungslizenzen sind teuer, und die damit entwickelten Softwarekomponenten nur mit Einschränkungen zu vertreiben. Doch damit nicht genug. Weitere Gründe, die einem durchgängigen digitalen Engineering bis heute im Wege stehen, sind:
- die unzureichende Geschwindigkeit der funktionalen Weiterentwicklung der Werkzeuge durch die Systemhersteller,
- die unzureichende Team-Unterstützung der Werkzeuge
- sowie eine unzureichende Unterstützung iterativer Engineering-Schritte.
Auf den Punkt gebracht, stellt sich die aktuelle Situation im Automobilbau wie folgt dar: Die Vielzahl der auf dem Markt befindlichen digitalen Planungswerkzeuge und die damit verbundenen Kosten zwingen Anlagenbetreiber, sich auf eine spezielle 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 wider, die von den Betreibern getragen und an den Endkunden weitergegeben werden müssen.
