Durchgängige Datennutzung mit AutomationML

"Herr der Schnittstellen"

In der durchgängig vernetzten Fabrik, in der alle Geräte untereinander Daten austauschen, bilden offene und standardisierte Schnittstellen ein wichtiges Fundament. Doch nicht erst in der laufenden Produktion, bereits im Engineering bringen sie spürbaren Mehrwert. Eplan, Mitsubishi Electric und Siemens setzen an dieser Stelle auf AutomationML. Welche Vorteile sich durch die Nutzung des Standards für den Anwender ergeben, darüber hat das SPS-MAGAZIN mit Experten der Firmen gesprochen.


Die Automatisierungstechnik wird immer komplexer, die Aufgabenstellungen vielfältiger und so müssen im Engineering mehrere Seiten gut zusammenspielen. Wie lässt sich das sicherstellen?

Thomas Michels: Die Basis dafür ist, dass schon die Entwicklungs-Tools auf Datendurchgängigkeit ausgelegt sind. Weil Eplan allein nicht die gesamte Tool-Kette abdeckt, bemühen wir uns an verschiedenen Stellen um passende Schnittstellen zum automatischen Im- und Export von Daten zwischen den Programmen. Idealerweise kann man so alle im Engineering relevanten Informationen und Daten durchgängig in entsprechenden Systemen hinterlegen - vom ECAD bis zu den Projektierungswerkzeugen der Steuerungshersteller. Um Mehrfacheingaben zu vermeiden und die Wiederverwendbarkeit der Daten zu gewährleisten, sind dabei offene Schnittstellen und Standards gefragt.

Thomas Funke: Bisher gab es von Eplan zu den Tools der SPS-Hersteller vor allem spezifische Schnittstellen, die wir im Fall von Erweiterungen oder Updates einzeln aufwändig anpassen mussten. Um mittelfristig 'Herr der Schnittstellen' bleiben zu können, musste ein neutrales Schnittstellenformat her und so haben wir uns letztlich auf AutomationML geeinigt.

Michels: AutomationML wurde als einheitliches Datenformat ursprünglich für den Automotive-Bereich entwickelt, um unterschiedliche Aspekte in einem Projektdurchlauf abzubilden - z.B. bei Bewegungsprofilen von Robotern oder in der Simulation. Mit der Organisationsstruktur des dahinterstehenden Nutzervereins können wir den Standard aber auch gut für unsere Bedürfnisse in der Elektroplanung abstimmen.

Was spricht aus Sicht der SPS-Anbieter für AutomationML?

Andreas Pfaff: Mitsubishi Electric hat zwar ein großes Automatisierungsportfolio, kann aber auch nicht alle Anforderungen alleine lösen. Deswegen wurde 2003 das Partnerkonsortium eF@ctory-Alliance ins Leben gerufen, in dem auch Eplan schon lange Mitglied ist. Um über diese Allianz nicht nur umfangreiche sondern auch durchgängige Lösungen anbieten zu können, waren auch die passenden Schnittstellen erforderlich. So sind wir auf AutomationML gestoßen.

Nelli Klein: Siemens will seinen Kunden passende Tools für jede Phase der Wertschöpfungskette zur Verfügung stellen - viele eigene Werkzeuge, aber auch Tools von Fremdanbietern. Insgesamt ist es eine heterogene Landschaft, die es zu beherrschen gilt. Unserem Anspruch folgend, benötigen wir also auch einen nahtlosen Übergang in die Welt der Elektroplanung. Deswegen haben wir bei unseren Kunden genau nachgehakt und viel diskutiert. So sind wir letztlich bei AutomationML gelandet und konnten auch ein tiefgehendes Verständnis aufbauen, welche Informationen über die Schnittstelle überhaupt übertragen werden sollten und warum.

Was heißt das genau?

Klein: Weil viele Parameter der I/O-Zuordnung oder Netzwerkplanung bereits in der SPS-Konfiguration hinterlegt sind, ist es nur sinnvoll, sie auch direkt in die Elektroplanung bzw. das Engineering zu übergeben. Letztendlich ist es ein Standardisierungsthema, das nicht nur bei Siemens sehr hoch aufgehängt ist, sondern auch bei unseren Kunden im Rahmen ihrer Digitalisierungs-Usecases. Hier liegt der Grundstein für die Zusammenarbeit mit Partnern wie Eplan und den Experten in entsprechenden Gremien und Arbeitsgruppen von AutomationML.

Wie war die bisherige Vorgehensweise im Engineering?

Michels: Das Engineering im Maschinen- und Anlagenbau ist noch sehr heterogen. Anstatt, dass sich die Entwicklungsabteilung übergreifend um die Automatisierung kümmert, gibt es vielfach noch eine separierte Hard- und Softwareplanung. Entsprechend unterschiedlich ist die Ausgangsposition: Welche Seite ist für welche Daten und deren Erfassung im System zuständig? An wen werden welche Daten übergeben und in welcher Form? Bei der Antwort auf diese Fragen ist der durchgängige Datenaustausch für alle Entwickler ein wichtiger Aspekt. Und auch bei der Inbetriebnahme erhöht eine einheitliche Struktur die Qualität und Geschwindigkeit. Das setzt aber nicht nur eine enge Kommunikation der Beteiligten voraus, sondern auch eine offene, standardisierte Schnittstelle. Und an der Stelle kommt AutomationML ins Spiel.

Pfaff: Gerade in Bezug auf die Time to Market kann diese Schnittstelle ihre Trümpfe ausspielen, denn mit ihr können die Engineering-Prozesse parallel laufen. Elektroplaner und SPS-Programmierer beginnen dann gleichzeitig mit ihrer Arbeit. Änderungen von einer Seite lassen sich umgehend an alle beteiligten Parteien übertragen. Ergo: Komfort und Qualität im Engineering steigen, gleichzeitig reduzieren sich Entwicklungszeiten und damit auch die Kosten.

Klein: Die Fehleranfälligkeit von einst, als Parameter noch mit händisch erstellten Listen oder Ausdrucken ausgetauscht wurden, sinkt deutlich. Darüber hinaus kann man AutomationML-Dateien gut versionieren oder für Folgeprojekte wiederverwenden. Und durch die kontinuierliche Weiterentwicklung der Schnittstelle wird sie künftig auch zur Basis einer durchgängigen Rückverfolgbarkeit. Der Mehrwert für den Anwender von AutomationML steigt also kontinuierlich.

Werden diese Möglichkeiten auch von allen Anwendern als Vorteile wahrgenommen?

Funke: Wer für sein Leben gerne Excel-Listen abtippt, wird diesem Prozess vielleicht nachweinen. Spaß beiseite: Durch den standardisierten Austausch der Daten auf elektronischer Basis können alle beteiligten Seiten ihre Arbeitszeit sinnvoller einsetzen und besser zusammenarbeiten. Zudem lassen sich Fehler vermeiden und Zeit sparen. Sorgen und Ängste, dass die Schnittstelle Arbeitskräfte im Engineering-Prozess ersetzt, sind aber unbegründet.

Michels: Es gibt nicht selten bei Elektroplanern die Befürchtung, dass es zu einem erhöhten Aufwand für Datenpflege kommt. Aus der Vogelperspektive betrachtet, sind die Vorteile von Standardisierung, Modularisierung und Wiederverwendbarkeit aber nicht zu übersehen. Deswegen ist es wichtig, die Features der standardisierten Schnittstelle gemeinsam und disziplinübergreifend zu betrachten.

Klein: Das Engineering wird einfach immer komplexer und es ist keinesfalls so, dass der Entwickler durch die Hilfestellung der AutomationML-Schnittstelle nichts mehr zu tun hätte. Er kann aber anderen Aufgaben mehr Zeit widmen - z.B. der Schaffung einer eigenen Bibliothek an wiederverwendbaren Bausteinen und Modulen. Nur mit solchen Werkzeugen ist man für die Herausforderungen des modernen Engineerings gerüstet. Mit Excel-Listen und Co. wird die Komplexität nicht mehr eingefangen und man verirrt sich auf dem Weg.

Die Digitalisierung kommt, keine Frage. Aber wie weit hält sie denn tatsächlich bereits Einzug in Entwicklung und Fertigung?

Michels: Das ist ganz unterschiedlich. Manche Kunden fordern die Möglichkeiten der neuen Schnittstelle bereits aktiv ein, andere haben noch gar nicht darüber nachgedacht.

Klein: Allen Anwendern gemein ist: Sie müssen auf die neuen Technologien reagieren. Wie weit sie dabei heute schon sind, hängt von der eigenen Einstellung und dem Handlungsdruck von Kunden ab. Insgesamt ist der Aufwand für den Import und Export der Variablen über die AutomationML-Schnittstelle denkbar gering. Der Anwender muss seine Prozesse etwas anpassen, aber keine tiefgreifenden Änderungen im Engineering vornehmen.

Funke: Das Potenzial der Digitalisierung wird leider nicht immer richtig eingeschätzt. Dann fehlt oft noch der Impuls für einen Wechsel der Methoden.

Dabei sollten doch die Vorteile von AutomationML klar ersichtlich sein?

Funke: Ja, auch aus Anbietersicht. Wir können durch diesen offenen Standard neue Erweiterungen unkompliziert und ganzheitlich definieren. Features von Eplan lassen sich dann quasi per Knopfdruck in die verschiedenen Steuerungswelten - wie die von Siemens oder Mitsubishi Electric - implementieren.

Michels: Der Standard hat den Charme, dass er sich nicht auf einen einzelnen Funktionsbereich fokussiert. Deshalb birgt AutomationML Potenzial aus vielen Blickwinkeln. Wenn man sich einmal mit dem Format in der Elektroplanung auseinandersetzt, kann man das gewonnene Know-how schnell auch auf andere Informationen oder Projektstrukturen anwenden - jedes Mal mit den bereits genannten Vorteilen von Modularisierung und Wiederverwendbarkeit. Das gilt nicht nur für bereits bestehende, sondern auch für noch kommende Entwicklungen in der Automatisierung. Es werden sich zukünftig noch einige Anforderungen ergeben, denen man mit AutomationML wunderbar begegnen kann.

Sehen Sie das auf Seite der Steuerungsanbieter genauso?

Pfaff: Ja, AutomationML bietet verschiedene Vorteile, mit denen sich unsere Kunden von Marktbegleitern abheben können. Und weil der Standard kontinuierlich weiterentwickelt wird, werden sich sicherlich noch weitere auftun, z.B. in der Antriebstechnik. Als Vorreiter in der Nutzung von AutomationML sehen wir hier vielfältige Möglichkeiten.

Klein: Gerade wenn man sich früh mit AutomationML beschäftigt, kann man davon profitieren - als Anbieter genauso wie als Anwender. Dadurch, dass hinter dem Standard die Zusammenarbeit vieler Automatisierungsanbieter steht, spiegelt er deren vereintes Know-how wider. Das bringt für alle Mitglieder des Vereins Vorteile - bündelt diese aber wiederum auch in der Gesamtheit für unsere Kunden. Solche Synergien werden zukünftig unabdingbar und sie lassen sich nicht generieren, wenn man sein eigenes Süppchen kocht.

Funke: AutomationML ist ja ein Standard, der komplett offen gelegt ist. Er bietet also prinzipiell keine spezifischen Vorteile für einzelne Anbieter oder Nutzer. Aber Firmen, die früh auf den AutomationML-Zug aufspringen, haben einen temporären Vorteil. Solange, bis die Marktbegleiter nachziehen - was sie über kurz oder lang vermutlich tun werden. Langfristig wird man sich darüber differenzieren können, wie gut und komfortabel man die Schnittstelle in die eigenen Tools integriert.

Wie muss sich der Anwender denn aufstellen, um am meisten von der Nutzung der Schnittstelle profitieren zu können?

Funke: In der täglichen Arbeit muss der Anwender nur ein paar neue Datenfelder füllen. Aber die wirkliche Aufgabe liegt darin, über seinen jeweiligen Tätigkeitsbereich hinauszublicken - im Sinne einer mechatronischen Denkweise. Das müssen auch die alteingesessenen SPS-Programmierer und Elektroplaner lernen. Deshalb liegt die Herausforderung für Entwicklungsleiter darin, die einzelnen Mitarbeiter auf eine gemeinsame Reise mitzunehmen.

Das Thema Mechatronik prägt den Markt ja schon seit vielen Jahren in unterschiedlichen Eskalationsstufen. Wird jetzt durch den steigenden Einfluss der Digitalisierung ein neues Level erreicht?

Michels: Ja, die Zusammenarbeit zwischen den Entwicklern erhält nochmal mehr Gewicht. Folglich müssen sie die Denk- und Arbeitsweisen anpassen. Alleine können die Software-Tools den Nutzen nicht heben, sie sind nur die eine Seite der Medaille. Die andere Seite liegt im Bekenntnis des Anwenders zu modernen Technologien und Methoden.

AutomationML kann also Entwickler genauso zusammenbringen wie Automatisierungsanbieter.

Funke: Ja, dafür lässt sich ein plakativer Vergleich heranziehen: Wäre der digitale Zwilling ein Patient, dann wäre Eplan vielleicht der Orthopäde, und die SPS-Anbieter die Internisten - keiner der Ärzte kann den Patienten in allen Belangen bestmöglich versorgen. Das geht nur mit Zusammenarbeit und der Weitergabe von Diagnosen und Informationen über Maßnahmen.

Klein: Um an diesem Bild anzuknüpfen: Wenn die verschiedenen Ärzte die Daten sammeln und austauschen, lassen sich auftretende Symptome bestmöglich bekämpfen. Es lassen sich aber auch kommende Krankheitsbilder aufdecken und behandeln, von denen der Patient aktuell noch gar nichts spürt. Sprich: Der Mehrwert von heute generierten Daten wird in Zukunft noch deutlich steigen und den Aufwand der heutigen Erfassung bei weitem aufwiegen. Der Patient hat großen Nutzen durch die Zusammenarbeit, aber auch die jeweiligen Ärzte profitieren davon.

SPS-Hersteller sollen auf der einen Seite also zusammenarbeiten und einheitliche Schnittstellen anbieten, müssen sich auf der anderen Seite aber im gegenseitigen Wettbewerb behaupten. Wie lässt sich dieser Spagat bewerkstelligen?

Pfaff: Ich denke nicht, dass wir durch den Einsatz von offenen Schnittstellen ins Hintertreffen geraten werden. Es ist eher andersherum: Man verpasst wertvolle Chancen, wenn man Standards wie AutomationML oder OPC UA nicht nutzt. Das Rennen um die Gunst des Kunden wird künftig von anderen Faktoren entschieden: z.B. die Verbreitung in den jeweiligen Industriezweigen, individuelle Stärken und Features oder Service- und Support. Es wird in jedem Fall noch genügend Unterscheidungsmerkmale geben.

Funke: Die Automatisierungsanbieter haben ihre Steuerungen über die letzten 30 Jahre immer weiter ausgereizt. Applikationen lassen sich durch einzelne Produkte also oft nicht mehr groß verbessern, sehr wohl aber durch ein gutes Zusammenspiel aller verbauten Hard- und Softwarekomponenten. Die Voraussetzung dafür liegt allerdings in der Abkehr von proprietären Schnittstellen.

Und AutomationML ist dafür der richtige Standard?

Michels: Wir haben uns dazu natürlich viele Gedanken gemacht - schon als sich AutomationML noch in einem deutlich früheren Entwicklungsstadium befand. Aus heutiger Sicht habe ich nicht das Gefühl, dass wir auf das falsche Pferd gesetzt hätten. Ganz im Gegenteil. Mittlerweile wird AutomationML als Basis für viele zukunftsweisende Entwicklungen gehandelt.

Funke: Weil AutomationML aus rein technischer Sicht ein eher simples Format auf XML-Basis ist, ist es so einfach in der Handhabung. Und das ist eine wesentliche Voraussetzung, um die Datenmodelle der verschiedenen Seiten zusammenzubringen und der wirkliche Wert der Schnittstelle.

Pfaff: Es werden sicherlich noch weitere Schnittstellen in der Automatisierung aufkommen. Aber in der aktuellen Ausprägung ist AutomationML der absolut richtige Standard.

Wie geht es weiter mit AutomationML in der Eplan-Welt?

Michels: Unser Ziel ist es, möglichst viele der proprietären Schnittstellen aus der Eplan-Welt zu anderen Systemen durch AutomationML zu ersetzen.

Funke: Dementsprechend arbeiten auch schon die Steuerungsanbieter ABB, Beckhoff und Rockwell Automation bereits konkret daran. Einige weitere Hersteller haben ebenfalls ihre Absicht bekundet.

Michels: Es geht auch funktional weiter, z.B. in Richtung Motion oder die Konfigurierbarkeit von Feldgeräten über IO-Link und Co. Wie gesagt, muss die Schnittstelle ja nicht auf die SPS-Seite beschränkt bleiben.

Und wie sieht der Ausblick als SPS-Anbieter aus? An welchen weiteren Stellen sehen Sie noch Potenzial für AutomationML?

Pfaff: Ich sehe noch einiges an Potenzial. Entsprechend wollen wir AutomationML bei Mitsubishi Electric künftig für verschiedene weitere Schnittstellen und Tools nutzen, z.B. im Scada-Umfeld.

Klein: Aus technischer Sicht gibt es kaum Grenzen. Deswegen ist es ein Ziel bei Siemens, AutomationML möglichst durchgängig über die komplette Wertschöpfungskette einzusetzen - auch in den vorgelagerten Designprozessen. (mby)

Anzeige