Engineering Kostenloses, herstellerneutrales Datenformat

Redakteur: Reinhard Kluger

Breite Fundamente für ein künftiges herstellerneutrales Datenformat: DaimlerChrysler, ABB, Kuka, Rockwell, Siemens, NetAllied und Zühlke sowie die Unis Karlsruhe und Magdeburg wollen AutomationML schultern. Das Datenformat soll den durchgehenden Austausch von Engineering-Daten standardisieren. Alle sollen es kostenlos nutzen können.

Anbieter zum Thema

Wenn es so etwas wie das Recht auf einfaches Engineering gibt, dann dürfte die Automatisierung bald am Ziel sein. AutomationML heißt das Zauberwort, das einen lang gehegten Wunsch wahr werden lassen soll: Ein herstellerneutrales Datenformat für den durchgehenden Austausch von Engineeringdaten − als offener Standard und von jedem kostenfrei nutzbar.

Seit Jahren schon diskutiert die Branche die Kostenfalle, in der das Engineering steckt, dass die Prozesse kaum noch beherrschbar sind. Wenngleich auch über die Gründe, die ein solches Desaster verursacht haben, häufig Einigkeit besteht, so wenig hat man die Folgen beim Engineering im Griff. Und diese wiegen immer schwerer. Der Zeitdruck beim Entwickeln und Fertigen von Maschinen und Anlagen nimmt zu, den Maschinenbauer drücken die Kosten. Schon 2003 forderte eine Diskussionsrunde dieser Zeitschrift zum Thema „Engineering in der Kostenfalle“ Einsparungen in allen Engineeringphasen. Wiederverwendbare mechatronische Komponenten, Softwaremodule und Technologiemodule sollten Wege aus dem Engineering-Dilemma weisen. Doch alldem gegenüber stand: Wiederverwendung ist zu aufwändig, weil die Daten in unterschiedlichen Engineering-Systemen und zudem noch über unterschiedliche Abteilungen eines Unternehmens verteilt sind. Der Automatisierer mit seiner industriellen Software verheddert sich rasch in einem undurchschaubaren Engineering-Labyrinth.

Der Blick auf die Kosten spricht eine klare Sprache und fordert ein rasches Handeln. „Bis zu 60 Prozent der Gesamtinvestitionen werden durch Engineering verursacht. Dabei sind unzureichend standardisierte Datenaustauschlösungen kritische Kostentreiber“, hat Anton Hirzle ausgerechnet und damit Engineering als den in der Automatisierungstechnik entscheidenden Wert- und Kostentreiber ausgemacht. Der bei DaimlerChrysler im Bereich Produktionsplanung, Verfahrensentwicklung, Automatisierungstechnologien und Simulation Verantwortliche weiß warum: „Zahlreiche digitale Werkzeuge mit jeweils eigenen Datenformaten können untereinander nur mit großem finanziellen und zeitlichen Aufwand kommunizieren.“ Als typische Herausforderungen an Engineering-Werkzeuge listet Anton Hirzle neben vielen anderen die hochpreisige Lizenzierungspolitik von Tool-Herstellern auf, dass die funktionale Erweiterung des Werkzeugs durch den Anwender entweder nicht durch die Systemarchitektur unterstützt wird oder aber mit hohen Einstiegskosten (Partnerverträge) verbunden ist. Zudem seien Werkzeuge oft nicht für teamorientiertes, international verteiltes Arbeiten vorbereitet. Die Engineering-Prozesskette ließe sich – gezielt – nur innerhalb der Systemlandschaft eines Herstellers schließen. Und manchmal gelte das auch nur für Teile der Prozesskette. Sein Fazit: „Es existieren keine offenen, standardisierten und akzeptierten Austausch- und Zwischenformate mit Blick auf die gesamte Prozesskette.“ Dieses Manko des herstellerneutralen Datenaustauschformats soll AutomationML schließen. Eine Idee, die Anfang 2006 bei DaimlerChrysler aufkeimte, und die man jetzt mit Partnern realisiert.

Der Kit für die Kluft in der Fabrik

Für AutomationML sind die Vorgaben damit klar definiert, die Teilnehmer gefunden. So machten die Unternehmen DaimlerChrysler AG, ABB, KUKA Robot Group, Rockwell Automation GmbH, Siemens Automation & Drives, netAllied und Zühlke sowie die Universitäten Karlsruhe und Magdeburg auf der Hannover Messe 2007 das gemeinsame Projekt erstmals öffentlich: Die gemeinsame Datensprache, Automation Markup Language – AutomationML, soll noch in diesem Jahr allen als kostenfreier, offener Standard zur Verfügung stehen.

AutomationML will damit die Kluft zwischen Fabrikplanung und Automatisierungstechnik kitten, durch:

  • Interoperabilität zwischen digitalen Werkzeugen,
  • für alle Teilschritte des Engineeringprozesses,
  • basierend auf einem erweiterbaren Datenformat und als
  • offener, frei verwendbarer Standard mit hoher Marktakzeptanz.

Konzipiert ist AutomationML als XML-basiertes Zwischenformat. Es soll vollständige, mechatronische Komponenten repräsentieren und dabei bereits vorhandene und akzeptierte Standards nutzen und bei Bedarf auch erweitern. Für den Anwender kann der zu erwartende Nutzen kräftig sein. Entspannte Zeiten fürs Engineering also. Der Ingenieur und Konstrukteur, sie können sich wieder voll und ganz auf ihre ursprünglichen Aufgaben konzentrieren, wie Anton Hirzle für DaimlerChrysler bilanziert: „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.“

Einer der Partner, die sich an AutomationML beteiligen, ist Rockwell Automation. Reinhard Simon, Automotive Industry Consultant bei Rockwell, begründet das so: „weil wir von der Vision überzeugt sind, dass ein durchgängiger Austausch von Daten zwischen Engineeringtools vom Anlagen-Design über die Simulation bis hin zur Konfiguration und Programmierung individueller Automatisierungskomponenten sowohl Effizienz und Qualität erheblich steigern kann − gerade bei einer heterogenen Tool-Landschaft mit ihren heute noch eingeschränkten Übergabemöglichkeiten.“ Nach seiner Überzeugung bemängeln Planer und Konstrukteure seit langem den Aufwand und die Fehlerträchtigkeit bei der erneuten Eingabe von Daten, die teilweise schon in einem anderen Tool vorhanden sind, als nicht mehr zeitgemäß. So neu sei der Gedanke also nicht: „Aber bisher hat die verlustfreie Datenübergabe zwischen Softwarewerkzeugen nicht oder nur da funktioniert, wo Produkte aus einer Systemfamilie eines Herstellers kombiniert wurden. Warum? Weil eine allgemein-gültige, lizenzfreie und neutrale Datenaustausch-Formatspezifikation fürs Engineering von Fertigungsanlagen bislang gefehlt hat.“ Genau dieses Manko will das Projekt nun lösen und einen herstellerneutralen Standard definieren.

Ein Angebot für die Hersteller von Tools

Es ist für Reinhard Simon als ein Angebot für Toolhersteller zu verstehen, diesen neuen Standard in ihren SW-Werkzeugen zu integrieren und damit die Prozesskette durchgängig zu gestalten. Das könnte gelingen, wenn bei jeder Datenübergabe ein einheitlich strukturiertes XML-Schema benutzt wird, in dem die Tools ihre spezifischen Projektierungsdaten anreichern. Simon: „Natürlich will niemand das Rad neu erfinden, und bestehende Standards sollen daher, sofern geeignet, für die verschiedenen Anwendungsbereiche wie Geometriebeschreibung und Ablauflogik berücksichtigt werden.“

Dass AutomationML vor allem das Problem von Informationsbrüchen zwischen den unterschiedlichen Tools verschiedener Engineering-Disziplinen löst, sieht auch Dirk Weidemann von Zühlke. Der Standortleiter Hannover: „Damit werden nach unserer Einschätzung zuerst erheblicher Aufwand und viele Fehlerquellen bei der Übergabe von Engineering-Ergebnissen an nachfolgende Prozess-Schritte reduziert, und dann durch deutlich verbesserte Simulationsmöglichkeiten frühe Korrekturen und Vermeidung von Fehlaufwand im Engineering möglich. Das Einsparpotenzial ist erheblich!“

Ob sich Toolhersteller Sorgen machen müssen, AutomationML würde ihre Tools ersetzen? Dirk Weidemann kann die Befürchtungen zerstreuen, für ihn ergeben sich sogar zusätzliche Vorteile: „Durch AutomationML werden Tools bei den Anwendern nicht ausgetauscht, dafür sind die Umschulungskosten viel zu hoch und vor allem sind die Tools wegen ihrer Funktionalität ausgewählt worden. Vielmehr brauchen die Hersteller nicht mehr eine hohe Anzahl von Konnektoren zu anderen Werkzeugen mit mehreren Versionen zu entwickeln und zu pflegen.“ Das dürfte sich schnell auszahlen, weil sich die Hersteller auf ihre Kernkompetenzen fokussieren können. Wenn man mit AutomationML die Kosten kappen kann, dann weckt das Begehrlichkeiten, erzeugt das Erfolgsdruck. Voraussetzungen, die für das letztendliche Gelingen erforderlich sind. Bleibt die Frage: Wird es klappen? Kann man mit AutomationML wirklich die derzeitigen Engineering-Probleme lösen?

Mögliche Befürchtungen zerstreuen

Für Reinhard Simon wird dieses Konzept indes nur funktionieren, wenn relevante Hersteller und Nutzer von Fertigungsautomatisierungslösungen gemeinsam an einem Strang ziehen, wie das jetzt der Fall ist: „Das ist der Grundgedanke bei diesem Projekt, und so ging es zunächst darum, die Sicht der Nutzer sowie der Automatisierungs- und Roboterhersteller zu berücksichtigen, damit hier anwendungsnahe Anforderungen gut abgedeckt werden. Das kann natürlich nur der Anfang sein – denn erst, wenn auch die Hersteller von CAD/CAE-Tools das Potenzial von AutomationML für die Optimierung des Engineeringprozesses erkennen und entsprechende Interfaces auch in ihre Tools integrieren, ergibt sich der erwartete Nutzen.“ Zusätzliche Möglichkeiten erkennt Dirk Weidemann, Zühlke, auch bei Toolherstellern: „AutomationML wird ein offener Standard, somit kann jedes interessierte Unternehmen dann an der Weiterentwicklung des Standards mitwirken. Gerade Tool-Hersteller sollten sich dann nach unserer Einschätzung diese Chance nicht entgehen lassen.“ Bei solch handfestem Nutzen für alle Seiten scheint AutomationML zum Erfolg verdammt zu sein, ist es der derzeit wohl gangbarste Weg, um der Kostenfalle Engineering überhaupt entgehen zu können. Dass die Herkulesaufgabe gelingen wird, Anton Hirzle ist sich da sicher. Für DaimlerChrysler prognostiziert er: „irgendwann ist AutomationML Ausschlusskriterium für unsere Kunden.“

„Es kann eine Zukunft geben“ Rolf Schwanecke, Direktor Automotive Industry, AUCOTEC AG, über AutomationML und die Folgen

Wie sehen Sie AutomationML? Hat das Datenformat Zukunft?

AutomationML ist ein interessanter Ansatz, der allerdings nur zum Teil neu ist, wie Aktivitäten in anderen Gremien (Step, VNS etc.) in der Historie gezeigt haben. Was neu ist, ist die Tatsache, dass dieses Datenformat übergreifend von allen verschiedenen Gewerken nutzbar sein soll! Wenn es gelingt, das Datenformat versions- und revisionsfähig zu machen, und eine Integration von OEMs und Anlagenlieferanten zu realisieren, dann kann es vielleicht eine Zukunft geben. Achtung: Realisierungskosten hinterfragen!

Wirkt es sich auf die Toolhersteller aus?

Wenn die Toolhersteller eine wirklich nutzbare Formatspezifikation erhalten, die auch noch unter vernünftigen wirtschaftlichen Gesichtspunkten realisierbar ist, dann macht es Sinn, sich mit diesem Thema auseinander zu setzen.

Wird sich etwas ändern?

Das kann heute noch keiner sagen, das wäre „Wolkenkuckucksheim“!

Müssen die Toolhersteller agieren oder können Sie nur reagieren?

Im Moment gibt es keinen Anlass zum Agieren! Wenn es eine wie oben beschriebene Spezifikation gibt, dann ist die Zeit zum „Agieren oder Reagieren“.

Warum noch ein neues Format?

Vielleicht, weil es Gewerke übergreifend funktionieren soll?

Gab es und gibt es nicht schon Step, VNS oder Föderal?

Step gibt es immer noch, und es hat auch seinen Sinn. Allerdings gibt es dort für verschiedene Gewerke auch verschiedene Dialekte (AP 212, AP 213 etc.), die sich nicht wirklich kennen!

Kann man mit AutomationML wirklich das Engineering-Problem lösen?

Die Frage, die es zu klären gilt, ist eine andere: Haben die OEMs wirklich ein Engineering-Problem oder mehr ein Kostenproblem? Das Ziel ist doch, mit geeigneten Maßnahmen an der Kostenschraube zu drehen, das heißt, Engineeringzeiten zu verkürzen, um die Dauer der gesamten Produktimplementationsprozesse zu verkürzen und zu standardisieren.

Findet das Engineering damit aus der Kostenfalle?

Wenn eine Integration der Idee im Weltmarkt gelingt, dann vielleicht!

(ID:210349)