Warum gestaltet sich die Kommunikation zwischen Anlagenbetreibern und Lieferanten als so schwierig?
In der Regel gibt es keine 1:1-Beziehung zwischen Betreiber und Lieferant, sondern meist mehrere Zulieferer, verteilt nach Gewerken oder Bauabschnitten. Diese Kontraktoren nutzen dabei ihre eigenen Applikationen mit eigenen Anpassungen, um ihre Arbeit in der geforderten Zeit und Qualität sowie Budget-gerecht abliefern zu können. Das erfordert jedoch immer eine Konsolidierung von Quell- und Autorensystemen – eine echte Herausforderung!
Sie stellen auf der Achema zunächst das Konzept der EB Alliance und die ersten bereits möglichen Schritte vor – was genau beinhaltet dies?
Die ersten Schritte fokussieren sich darauf, dass die Daten austauschfähig bleiben. Gemeint ist, dass die Daten, egal wo sie sich befinden, immer ihren Ursprung kennen. Dadurch wird von Anfang an auch das Delta-Management enthalten sein.
Welche weiteren Schritte für EB Alliance sind geplant und wie sieht hier die ungefähre Roadmap aus?
Einer der finalen Schritte wird eine Benutzeroberfläche sein, in der sich das komplette Mapping anwenderfreundlich umsetzen lässt. Damit kann ein Anlagenbetreiber seinen Lieferanten diese Konfiguration schon in der Vergabephase des Projekts zur Verfügung stellen. Die Roadmap sieht vor, dass wir die ersten Schritte agil entwickeln, sodass einzelne in sich lauffähige Funktionen zur Verfügung stehen. So können wir auch noch Kunden-Feedback einfließen lassen.
Inwiefern unterscheidet sich EB Alliance von anderen Lösungen auf dem Markt?
Da alle Daten in EB auf einem zentralen Datenmodel basieren, das sämtliche Anlagen-Aspekte und -Disziplinen enthält, lassen sich Inhalte effizienter austauschen. Dabei ist entscheidend, dass ein Lieferant mit seinen angepassten Werkzeugen kompromisslos weiterarbeiten kann, aber auch, und das ist ihm sicher noch wichtiger, dass er sein Know-how, zum Beispiel Stammdateninformationen, nicht mit herausgeben muss, was bei anderen Tools zum Teil unvermeidbar ist.
Aucotec möchte Engineering-Prozesse erheblich beschleunigen. Was sind die größten Bremsen auf dem Weg zum agilen Engineering?
Die größte Bremse ist immer noch, dass viele Firmen für unterschiedliche Disziplinen unterschiedliche Applikationen verwenden und dadurch keine Datendurchgängigkeit gegeben ist. Stattdessen müssen viele interne Absprachen getroffen werden, die Zeit kosten und Missverständnisse provozieren können; all das beeinträchtigt die Datenkonsistenz erheblich.
Wie kann man sich eine Navigation in den Daten vorstellen?
Anwender können damit Daten in und aus verschiedenen Kontexten finden. Etwa Zusammenhänge, die zwar im Modell enthalten sind, aber nicht in einer erstgradigen Beziehung stehen. Erhält jemand übers Leitsystem eine Meldung von der Anlage, so liefert EBs Navigation alle dafür relevanten Daten auf einen Blick, passend zur Anwenderrolle. Dabei wird er oder sie durch die verschiedenen Ebenen der Anlage navigiert und kann an jedem markanten Knoten eine Entscheidung treffen. Kontextbasierte Algorithmen unterstützen das dynamisch und empfehlen den jeweils vielversprechendsten weiterführenden Weg. So sind im Beispielfall auch die Aufstellungsorte von I/O-Schrank und betreffendem Sensor im Nu parat.
Welche Art von Daten können über den Navigator gefunden werden – auch solche, die keine Engineering-Daten sind?
Eine interessante Frage, die ich erst einmal mit Ja beantworten möchte, aber man muss sie auch relativieren, denn die Daten müssten in diesem Fall EB schon bekannt sein. Also einmal in das Datenmodell integriert sein, samt ihren Beziehungen, und dann auch als Datensatz oder Link zur Verfügung stehen. Aber prinzipiell ist es mit EB machbar, auch Datenblätter, die nur indirekt Engineering-relevant sind, oder auch Handlungsanweisungen im Modell zu hinterlegen.
