Standards
‚AutomationML‘ und ‚eCl@ss‘ kombinieren
Egal ob es sich um ein Auto, einen Drucker mit Scanner- und Faxfunktion oder um einen Schaltschrank handelt – vor jedem neuen Produkt steht das Engineering. Durch die Kombination der etablierten Standards ‚AutomationML‘ und ‚eCl@ss‘ lässt sich ein durchgängiger Prozess umsetzen, der nicht nur hilft, Fehler zu vermeiden, sondern auch erheblichen Aufwand einsparen kann.
Bild: Phoenix Contact Deutschland GmbH
Produkte werden zumeist nicht mit einem einzigen Engineering-Werkzeug entwickelt. In den meisten Fällen kommen verschiedene Tools zum Einsatz. Da die Werkzeuge in der Engineering-Kette verschiedene Aufgabenstellungen lösen, sprechen sie jeweils ihre eigene, spezialisierte Sprache. Das kann bedeuten, dass die Datenformate der einzelnen Tools weder untereinander kompatibel sind, noch auf einer gemeinsamen Semantik-Definition basieren. Darüber hinaus gibt es unter Umständen nur wenige Schnittstellen, die die Werkzeuge miteinander verbinden. Während des Engineering-Prozesses kann ein großer Aufwand entstehen, um die Daten aus einem in das andere Format zu überführen.
Vor diesem Hintergrund wäre es zielführender, wenn ein gemeinsames Datenformat für alle Engineering-Tools verwendet werden kann, das sich selbst nach Beendigung des Engineering zur Steuerung der Produktion des entwickelten Artikels nutzen lässt. Die neunte Ausgabe von Rockwell Automations „State of Smart Manufacturing“ Report liefert Einblicke in Trends und Herausforderungen für Hersteller. Dazu wurden über 1.500 Fertigungsunternehmen befragt, knapp 100 der befragten Unternehmen kommen aus Deutschland. ‣ weiterlesen
KI in Fertigungsbranche vorn
Hohe Anforderungen
Die Anforderungen an ein derartiges Datenformat sind entsprechend hoch und können weder vom Klassifizierungs-Standard eCl@ss noch von AutomationML als Format für die Speicherung sowie zum Austausch von Anlagenplanungs-Daten erfüllt werden. Durch eine Kombination aus beiden Standards lässt sich jedoch ein durchgängiges Engineering realisieren. Zum Engineering eines Schaltschranks gehören unter anderem der Entwurf eines Schaltplans, die Auswahl der für diesen Schaltplan geeigneten Produkte sowie die Planung des mechanischen Montage-Aufbaus und der Verdrahtung im Schaltschrank. Dabei ist die Reihenfolge der Werkzeuge nicht explizit vorgegeben, sondern ergibt sich häufig von selbst.
Beispielsweise wird zunächst der Schaltplan mit dem jeweiligen Tool erstellt, das eine Schnittstelle zu den Produkt-Konfiguratoren der elektronischen Komponenten umfasst. Aus dem Schaltplan leitet sich dann eine konfektionierte Klemmenleiste ab, die der Planung des Montage-Aufbaus zur Verfügung gestellt werden muss. Der Montage-Aufbau dient wiederum als Grundlage für das Verdrahtungskonzept. Schnittstellen für derartige Engineering-Ketten liegen heute bereits vor, allerdings meist nur in eine Richtung. Selbst kleinere Änderungen – wie das Austauschen einer Reihenklemme gegen eine Variante mit einer anderen Anschlusstechnik – können zu einem erheblichen Aufwand an Nacharbeiten führen. Existieren die Schnittstellen nicht, müssen die Projektdaten oftmals umständlich konvertiert oder sogar manuell übertragen werden. Auf dem Weg durch die verschiedenen Engineering-Werkzeuge können zudem Daten verloren gehen.
Im Ergebnis sind dann die detaillierten Informationen aus den Produkt-Konfiguratoren für die Verdrahtungs-Planung nicht mehr vorhanden. Es wäre deshalb vorteilhaft, wenn alle Engineering-Tools mit einem gemeinsamen Datenformat arbeiten könnten. Auf diese Weise ließen sich die Konvertierungen und die daraus resultierenden Informationsverluste vermeiden. Außerdem könnte so die Engineering-Kette einfacher verlassen werden. Ein gemeinsames Datenformat bedingt jedoch eine Semantik-Definition, also eine einheitliche Definition der innerhalb der gesamten Kette auftretenden Aspekte. Gibt es sie nicht, kann es passieren, dass sich die Werkzeuge trotz des gleichen Datenformats nichts verstehen. Der Thin[gk]athon, veranstaltet vom Smart Systems Hub, vereint kollaborative Intelligenz und Industrie-Expertise, um in einem dreitägigen Hackathon innovative Lösungsansätze für komplexe Fragestellungen zu generieren. ‣ weiterlesen
Innovationstreiber Thin[gk]athon: Kollaborative Intelligenz trifft auf Industrie-Expertise
Rollenklassen-Bibliotheken
2005 hat die Automatisierungs-Initiative Deutscher Automobilhersteller die Kosten der Fabrikautomation analysiert. Die Studie kam zu dem Ergebnis, dass das Engineering von Anlagen einen wesentlichen Kostenfaktor darstellt, und hier insbesondere das Übertragen von Engineering-Daten von einem Werkzeug auf das nächste. Daraufhin hat die Daimler AG 2006 die Entwicklung und Standardisierung von AutomationML als Datenaustausch-Format für Engineering-Tools initiiert. Das entsprechende Industriekonsortium ist 2009 in einen Verein übergegangen.
Bei AutomationML handelt es sich um ein XML-basiertes Austauschformat für Engineering-Daten, das andere vorhandene Datenformate kombiniert. Dabei bildet Computer Aided Engineering Exchange (CAEX ) als äußere Klammer die Topologie einer Anlage ab, aus der weitere standardisierte Formate wie Collaborative Design Activity (Collada) und PLCopen XML referenziert werden können. Ursprünglich war AutomationML zur Anlagenbeschreibung gedacht. Es stellte sich allerdings heraus, dass sich mit dem Format auch Artikel beschreiben lassen, die in der Anlage hergestellt werden. Auf der Grundlage einer solch präzisen Artikelbeschreibung können intelligente technische Systeme, wie sie aktuell im Umfeld von Industrie 4.0 konzipiert werden, selbständig die Fertigungsstationen identifizieren, die zur Produktion des Artikels notwendig sind. Phoenix Contact setzt AutomationML daher im Rahmen seines Spitzencluster-Projekts Automation für wandlungsfähige Produktionstechnik (Awapro) ein. AutomationML verfolgt den Ansatz, dass sämtliche Engineering-Werkzeuge mit den gleichen Dateien arbeiten.
Jedes Tool liest und schreibt jedoch nur in den Teil, der für es selbst relevant ist. Damit alle Werkzeuge ein gemeinsames Verständnis von den in den Dateien beschriebenen Aspekten haben, umfasst AutomationML sogenannte Rollenklassen-Bibliotheken. Sämtliche Objekte im Datenaustausch-Format müssen auf eine Rollenklasse verweisen, sodass die Bedeutung respektive Klassifizierung für dieses Objekt für alle Engineering-Tools eindeutig ist. Derart umfangreiche Rollenklassen zu definieren, erweist sich als große Aufgabe, die ständig fortgeführt werden muss und AutomationML bisher noch nicht gemeistert hat. Daher ist es sinnvoll, ein bestehendes Klassifikationssystem als Rollenklassen-Bibliothek mit einzubinden.
