Zwischen Digitaler Fabrik und Automatisierungstechnik

Eine der wichtigsten Faktoren im heutigen Automobilbau ist die Fähigkeit, unternehmensübergreifend vernetzt zu kommunizieren und interagieren. So wird die (Ge-) Werkeübergreifende Abstimmung in den Bereichen der Digitalen Fabrikplanung und der Fahrzeugentwicklung ständig ausgebaut, um frühzeitig das Automatisierungsengineering durch die Entwicklung eines neutralen, offenen und frei verfügbaren Datenformates wesentlich effizienter zu gestalten.

Die Investitionskostenstruktur einer durchschnittlichen Produktionslinie für das Gewerk "Steuerungstechnik" kann in zwei große Investmentblöcke geteilt werden: Kaufteile/Fertigung und Engineering-/Planungsleistung. In der Produktionstechnik sind die Möglichkeiten zu Preisoptimierungen bei Kaufteilen nahezu vollständig ausgeschöpft. Hier sind in den nächsten Jahren in den meisten Fällen lediglich marginale Verbesserungen zu erwarten. Bleibt also der zweite Investmentblock: die Engineering-, bzw. Planungskosten. Die Herausforderung dabei ist die für die in allen Schritten des Planungsprozesses notwendigen Informationen austauschbar und weiter nutzbar zu machen. So ist der Datenaustausch zwischen Digitaler Produktionsplanung und Realisierungstechnik heute noch beschränkt auf rudimentäre, mit hohem Aufwand generierte Roboterprogramme. Im einfachsten Falle werden Informationen ausgedruckt und an die im Planungsprozess nächste Fraktion zur erneuten Erstellung weitergegeben. Eine Wiederverwendung ist nicht möglich. Die Gründe liegen in den heute üblichen Integrationsformen.

Eine Möglichkeit der Integration von Informationen im Planungsprozess besteht in der Verwendung von Werkzeugen eines einzelnen Softwareherstellers. Von Vorteil ist, dass die Daten Werkzeug-übergreifend verwendet werden können. Dieser Vorteil wird jedoch durch eine Vielzahl an Nachteilen aufgehoben. Zu nennen sind an dieser Stelle beispielsweise eine hochpreisige Lizensierungspolitik und die Notwendigkeit zur Anschaffung leistungsfähiger Hardware für akzeptable Systeminteraktion. Darüber hinaus kann es sein, dass die funktionale Weiterentwicklung durch den Systemhersteller sehr träge vonstatten geht und es keine oder hochpreisige Anwendererweiterungen gibt. Worst Cases: Die Werkzeuge können nur von Spezialisten genutzt werden oder die Prozesskette wird nur teilweise und nur innerhalb der Systemlandschaft eines Herstellers unterstützt.

Eine zweite Möglichkeit besteht im Einsatz von Werkzeugen verschiedener Hersteller. Der Vorteil ist, dass der Anwender das für seinen Bedarf beste Werkzeug verwenden kann. Nachteilig ist, dass seitens der Werkzeughersteller eine Vielzahl von Datenformaten entwickelt und gepflegt werden muss. Die Daimler AG initiierte 2006 eine Arbeitsgruppe mit der Aufgabe, die Vorteile der beiden beschriebenen Methoden zu kombinieren und die Nachteile zu eliminieren. Ziel der Arbeitsgruppe AutomationML war die Entwicklung eines offenen und am Markt akzeptierten Austausch- oder Zwischenformats für die gesamte Prozesskette um den Austausch zwischen der Digitalen Fabrik und der Automatisierungstechnik möglich zu machen. Zur Durchführung des Projektes wurden neue Wege beschritten. Zum einen wurde die Entwicklung eines offenen Standards mit dem Ziel, das Format auch außerhalb der "Daimler-Welt" lizenzfrei verwenden zu können angestrebt. Darüber hinaus war die Bildung enger Partnerschaften mit automatisierungsfremden Unternehmen aus der Computergrafik- und der Computerspieleindustrie sowie der Luft- und Raumfahrt elementarer Bestandteil des Projekts. Auch der Einsatz bereits vorhandener und weltweit akzeptierter Datenformate und das aktive Vorantreiben von notwendigen Veränderungen, beziehungsweise Erweiterungen gehörte zu den Aufgaben der Gruppe.

Die Entscheidung, AutomationML als offenen Standard zu definieren und zu veröffentlichen, fiel schnell. Ein offener Standard zeichnet sich dadurch aus, dass er in "offener", also konsens- und mehrheitsbasierter Weise durch eine gemeinnützige Organisation beschlossen und gepflegt wird. Dadurch ist eine Einflussnahme aller interessierten Parteien möglich. Des Weiteren wird der Standard veröffentlicht, dabei kann die Spezifikation frei oder gegen Gebühr ohne Einschränkungen verwendet, kopiert und weitergegeben werden. Sollten Schutzrechte teilnehmender Parteien exisitieren, so kann der Standard trotzdem auch gebührenfrei verwendet werden. Die Verwendung offener Standards bietet dem Entwickler die Möglichkeit, sich auf die Erweiterung des Formats zu konzentrieren, anstatt seine Ressourcen in die Neuentwicklung investieren zu müssen. Ein freier Standard ermöglicht es dem Anwender des Weiteren, auf die Entwicklung von Funktionalitäten direkten Einfluss auszuüben. Bei geschlossenen Formaten hat man hier meist keinen Einfluss, weil das Format im Besitz eines Unternehmens oder die Teilnahme in der Spezifikationsgruppe mit horrenden Mitgliedsgebühren behaftet ist.

Ein offenes Format ist meist besser getestet als vergleichbare, proprietäre Datenbeschreibungen. Sind es bei unternehmenseigenen Formaten im Höchstfall einige Dutzend Entwickler, so können es bei offenen Projekten einige tausend Personen sein, die Strukturen frühzeitig mitgestalten und auf Implementierbarkeit testen. Ein offener Standard hat die Eigenschaft, extrem flexibel auf die Anforderungen des Marktes zu reagieren und so technisch stets auf die neuesten Ansprüche reagieren zu können. Des Weiteren ist der Anwender nicht gezwungen, neue Versionen des Formats zu integrieren, wenn ihm die Funktionalitäten einer älteren Version ausreichen. Der Anwender zahlt somit nicht für unnötige Erweiterungen. Schließlich können durch die große Zahl an Entwicklern in vergleichbar kurzer Zeit mehr Inhalte erzeugt werden. Ein offenes Format ist kostenfrei. Implementiert in eigene Tools wird somit nicht aufgrund vereinbarter Verträge ("Du musst.."), sondern aufgrund technischer Eigenschaften ("Du kannst.."). Werkzeughersteller sind nicht mehr von den Entwicklungszyklen anderer, teilweise im direkten Wettbewerb stehender Unternehmen abhängig.

Ein für den klassischen Automationsbereich eher ungewöhnlicher Ansatz für Schaffung des Formates war der Blick über den eigenen Industriehorizont hinaus in andere "fremde" Industrien, wie z.B. der Branche für Computergrafik- und Videospiele. Was man nicht ahnt: Die Spieleindustrie und die Automatisierungsbranche haben eine große Schnittmenge bezüglich notwendiger Werkzeugfunktionalitäten. In beiden Welten werden möglichst performante, realitätsnahe und dabei möglichst interaktive Darstellungen realer Welten benötigt. Die Gemeinsamkeiten zwischen Spieleindustrie und Fabrikautomatisierung sind frappierend. Der wirkliche Unterschied liegt im eigentlichen Inhalt der Daten, einem kinematisierten und animierten Fußballspieler oder einer entsprechend aufgebauten Roboterzelle. Eine Vorgabe zur Entwicklung des Formats war es, möglichst bereits existierende Formate zu verwenden. Priorisiert wurden neben technischen Grundanforderungen, z.B. ausschließliche Verwendung von XML-Formaten. Vor allem Rahmenbedingungen wie Organisation, Offenheit in Bezug auf Erweiterungen und "Lebendigkeit", das heißt, eine offene Diskussion in Foren und Blogs, sollten das Projekt bereichern. Bei der Untersuchung vorhandener und als Ausgangsformat für Geometrierepräsentationen geeigneter Datenbeschreibungen wurde man im 3D-Grafikbereich in der Khronos-Gruppe mit dem dort geborenen Format Colloda fündig. Dieses Format wurde im Rahmen der engen Zusammenarbeit mit der zugehörigen Standardisierungsorganisation um weitere Geometriebeschreibungen sowie um eine allgemeine Kinematikbeschreibung erweitert. Ein weiterer "fachfremder" Ausflug brachte die Gruppe in die Welt der Prozessautomatisierung in der man bezüglich der Datenbeschreibung zur Strukturierung von Komponenten und der Beschreibung von Topologien im Format CAEX (Computer Aided Engineering Exchange) fündig wurde. Um im Engineering auch Abläufe und Verhalten beschreiben zu können, wurde das Format PLCopen XML der PLCopen-Gruppe integriert. Auch hier ist in Zukunft eine enge Zusammenarbeit geplant.

Nach über einem Jahr intensiver, unternehmensübergreifender Zusammenarbeit konnte die Projektgruppe im April diesen Jahres die Früchte ihrer Arbeit ernten: Das Projekt AutomationML erreichte als Zwischenziel die Veröffentlichung der ersten Version des Formats auf der Hannovermesse 2008. Nun ist es auch der breiten Öffentlichkeit möglich, an der Weiterentwicklung und damit dem nachhaltigen Erfolg dieses Formates teilzunehmen, dabei neue Kontakte und Partner in anderen Unternehmen zu finden und sich letztlich Märkte auch in bisher fremden Industriebereichen erschließbar zu machen.

Autor Alexander Alonso Garcia ist Mitarbeiter im Team Robotik und Technologiesteuerungen der Produktions- und Werkstofftechnik/Verfahrensentwicklung Automatisierungstechnologie und Simulation der Daimler AG/Mercedes-Benz Cars im Werk Sindelfingen.

Internet: www.daimler.com   

IT&PRODUCTION, 10-2008