Anzeige
Anzeige
Anzeige
Beitrag drucken

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.



Ein durchgängiges Engineering funktioniert nur dann, wenn die Datenweitergabe zwischen unterschiedlichen Werkzeugen problemlos möglich ist.
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.

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.



Das Beispiel einer Stromversorgung zeigt, dass die Leitungen durch die Kombination von Schaltplan-Informationen und Produktdaten nach der Platzierung der Geräte im 3D-Aufbau automatisch geroutet werden. Bild: Phoenix Contact Deutschland GmbH

Rollenklassen-Bibliotheken

2005 hat die Automatisierungs-Initiative Deutscher Automobilhersteller (AIDA) 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.

google plus


Das könnte Sie auch interessieren:

Microsoft hat Azure IoT Edge kostenfrei auf Github zur Verfügung gestellt. Der Dienst ermöglicht das lokale Ausführen von Datenanalysen und künstlicher Intelligenz (z.B. mit Azure Cognitive Services oder Machine Learning) in Geräten, Maschinen und Anlagen ohne dauerhafte Cloud-Konnektivität sowie die Übertragung dieser Daten in die Cloud für genauere Analysen. ‣ weiterlesen

Um Verwaltungsaufgaben schneller abzuwickeln, heißt es: Erst vereinfachen, dann automatisieren. Digitale Werkzeuge bieten hierzu weitreichende Möglichkeiten. Um eine umfassenden Analyse zuvor kommen Unternehmen aber nicht herum.‣ weiterlesen

Das Übersetzen der Produktdokumentation muss in internationalen Märkten heute schneller gehen als je zuvor. Software kann in Verbindung mit definierten Dokumentations- und Übersetzungsprozessen einen wichtigen Beitrag dazu leisten.‣ weiterlesen

Mit einer Strategie für die Entwicklung, Forschung und Anwendung Künstlicher Intelligenz will die Bundesregierung Deutschland zu einem führenden Standort im KI-Bereich machen. Die Eckpunkte für die Strategie wurden in dieser Woche vorgestellt.‣ weiterlesen

Anzeige
Anzeige
Anzeige