Publiziert unter: [Drath R., Barth M.: Wie der Umgang mit unterschiedlichen Datenmodellen beim Datenaustausch im heterogenen Werkzeugumfeld gelingt. In: VDIBerichte 2209, Tagungsband zur Automation 2013. S. 339-344, Langfassung auf Tagungs-CD (12 Seiten), VDI-Verlag, Baden Baden, 2013.]

Wie der Umgang mit unterschiedlichen Datenmodellen beim Datenaustausch im heterogenen Werkzeugumfeld gelingt Dr.-Ing. R. Drath, ABB Forschungszentrum Deutschland, Ladenburg; Prof. Dr.-Ing. M. Barth, Bereich Informationstechnik, Hochschule Pforzheim Kurzfassung Die Einführung eines Konzeptes zur Beherrschung heterogener Datenmodelle markiert einen wesentlichen Fortschritt im Austausch von Engineering-Daten. Dieser Beitrag erläutert, warum seitherige Anstrengungen zur Definition eines neutralen Standard-Datenmodells bislang nicht erfolgreich waren und gibt Lösungsvorschläge, wie AutomationML den Umgang mit Semantikvielfalt ermöglicht. Daraus entwickeln die Autoren ein evolutionäres Standardisierungs-Reifegradmodell. Das Konzept ist reif für die industrielle Einführung und bietet vielfältige Vorteile für Industrie, Gremien und Akademia.

1 Herausforderungen der Semantikvielfalt 1.1 AutomationML im Umfeld heterogener Datenmodelle Für Manager ist AutomationML [1] ein Hilfsmittel zur Kosteneinsparung und Qualitätsverbesserung. Für Ingenieure ist AutomationML ein konkretes Hilfsmittel zum Austausch von Engineering-Daten in einer heterogenen Werkzeuglandschaft. SPS-Programmierer tauschen Ablaufsequenzen, Hardwarehierarchien oder Signaldaten untereinander oder mit Ingenieuren der HMI- oder Elektroplanung aus. Roboterprogrammierer speichern Bahnverläufe oder importieren 3D-Geometrien und Kinematiken. Diese vielfältigen Sichtweisen lassen die dahinterstehende Problemstellung erahnen: in der Anlagenplanung sind eine Vielzahl von Personen mit jeweils individuellen Planungswerkzeugen beteiligt. Alle diese Gewerke sind Teil einer Wertschöpfungskette: in einem Engineering-Werkzeug werden Konfigurationsdaten erzeugt, welche in mehreren weiteren Werkzeugen benötigt werden. Die fortwährende Anreicherung dieser Daten, welche durch wiederholtes Kopieren, Ergänzen, Ändern und Verteilen in einem solchen Netzwerk entsteht, führt zwangsläufig zu Redundanzen und Inkonsistenzen, deren Identifikation und Behebung erheblichen manuellen Aufwand verursacht [2]. Mit Hinblick auf die Inbetriebnahme (virtuell oder real) ist die konsistente Zusammenführung aller Engineering-Daten dabei von besonderer Bedeutung. Dem entgegen steht die Tatsache, dass gerade in der Fertigungsautomatisierung Antriebe, SPSn, Roboter oder Sicherheitseinrichtungen verschiedener Hersteller miteinander kombiniert werden müssen. Dabei stellt jeder Gerätehersteller seine eigene Engineering-Software mit langjährig gereiften, sinnvollen und berechtigten Datenmodellen bereit. Im Ergebnis entstehen eine heterogene Werkzeuglandschaft sowie eine erhebliche Semantikvielfalt.

1

1.2 Grundproblem der Semantikvielfalt Warum ist Semantikvielfalt ein Problem? Dies lässt sich anhand menschlicher Kommunikation darstellen: Menschen können einen Text verstehen, wenn sie über ein gemeinsam vereinbartes Modell des Alphabets (die Syntax) sowie der Bedeutung ihrer Elemente (Semantik) verfügen. Schrift ist ein selbstverständliches Mittel der Kommunikation. Dennoch sind Fehler bei der Übertragung mittels Sprache allgegenwärtig: Kommunikation wird erschwert, wenn Verfasser und Leser über ein unterschiedliches Alphabet verfügen, unterschiedliche Syntax verwenden oder über unterschiedliche Semantikmodelle derselben Sprache, z.B. Doppeldeutigkeiten, verfügen,. Gleiche Begriffe unterschiedlicher Bedeutung oder unterschiedliche Begriffe gleicher Bedeutungen führen regelmäßig zu Missverständnissen. Semantische Vielfalt ist keine Eigenheit der Automatisierungstechnik, sondern allgegenwärtig. Der Datenaustausch zwischen Engineering-Werkzeugen in einer heterogenen Werkzeuglandschaft leidet an denselben Problemen: es fehlt ein vereinbartes gemeinsames Datenmodell, syntaktisch und semantisch. Um dies zu beheben, beschreibt die Literatur zwei grundsätzliche Konzepte: entweder werden die Werkzeuge miteinander in einer gemeinsamen Datenbank auf einem gemeinsamen Datenmodell integriert, oder sie gehen eine „lose Kopplung“ auf Basis eines dateibasierten Datenaustauschs ein und bleiben unabhängig. Beide Ansätze haben dabei ihre Existenzberechtigung [3], [4]. Die Praxis zeigt jedoch klar, dass dem dateibasierten Datenaustausch eine besondere Bedeutung zukommt, denn die Mehrzahl der am Markt befindlichen Werkzeuge stammt nicht von einem Hersteller, ist nicht aufeinander abgestimmt und besitzt aufgrund ihrer langjährigen Reifung ein eigenes, bewährtes und berechtigtes Datenmodell. Ihre Werkzeugintegration ist aufgrund wirtschaftlicher Eigentumsverhältnisse und konkurrierenden Marktbedingungen nicht zu erwarten: die Werkzeuge und ihre Datenmodelle liegen in der Hoheit des jeweiligen Werkzeugherstellers und unterliegen ständiger Veränderung. Es wird folglich ein übergreifendes gemeinsames Datenaustauschformat benötigt. Aufgrund fehlender Datenaustauschformate existieren zwischen den Gewerkegrenzen nach wie vor erhebliche Brüche im Engineering-Workflow. Dies ist einer der Hauptgründe für die von der AIDA in 2005 bezifferten Engineeringkosten von 50% der Gesamtautomatisierungslösung im Automobilbau [5]. Vor diesem Hintergrund initiierte die Daimler AG 2006 u.a. gemeinsam mit ABB, Siemens und Kuka einen Arbeitskreis mit dem Ziel, erstmalig ein Datenformat zu entwickeln, das möglichst alle Engineering-Disziplinen und –Phasen abdeckt. Im Ergebnis entstand das vergleichsweise schlanke Datenformat AutomationML, das bestehende Datenformate kombiniert und lediglich deren Verwendung und Interaktion definiert. Einen vertiefenden Einblick in AutomationML gibt [4]. Die Entwickler von CAEX [6] trennten bewusst Syntax und Semantik. CAEX schreibt kein Objektmodell vor, sondern bietet Mechanismen zur Modellierung beliebiger nutzerdefinierter Datenmodelle. Diese werden syntaktisch neutralisiert, die Semantik hingegen bleibt nutzerdefiniert. Auf diese Weise kann CAEX von Anbeginn unterschiedliche Objektmodelle abbilden und so Semantikvielfalt aufnehmen. Damit ist es für kommende Standard-Datenmodelle gerüstet. Doch die Standardisierungs-Community hat bis heute kein Engineering-Weltmodell etabliert – die Beherrschung der Semantikvielfalt ist bisher nicht gelungen. Warum?

1.3 Das Grundproblem der Semantik-Standardisierung Die ursprüngliche Idee eines neutralen Datenformates besteht darin, Daten herstellerneutral und verlustlos zu speichern. Es liegt daher der Gedanke nahe, die Semantikvielfalt durch ein „Super-Datenmodell“ zu beherrschen, das sämtliche Konzepte aller verwendeten Datenmodelle vereint und eine eindeutige und verlustlose Abbildung aller Daten ermöglicht. Dies ist die treibende Kraft aller entsprechenden Standardisierungsaktivitäten. Damit eine solche Standardisierung gelingt, müssen folgende Schritte absolviert werden: a) Eine Gruppe von Experten trägt für jedes beteiligten Gewerk bzw. Engineeringwerkzeug alle benötigten Datenmodelle und Konzepte bei. b) Experten einigen sich auf die gemeinsamen Grundkonzepte. c) Experten einigen sich auf ein neutrales semantisches Datenmodell, das alle Grundkonzepte berücksichtigt, z.B. mit UML. d) Experten einigen sich auf eine neutrales Syntax, z.B. basierend auf XML. e) Die gemeinsamen Grundkonzepte, das semantische Datenmodell und die Umsetzung in einer gemeinsamen Syntax werden in einem Dokument niedergeschrieben, beispielsweise in einem Normtext oder White Paper. f) Die Industrie und Akademia schafft die Voraussetzungen dafür, dass genügend Experten zur Verfügung stehen, die den Standard beurteilen und implementieren können. g) Anwender und Werkzeughersteller implementieren und nutzen den Standardentwurf in ihren Werkzeugen. h) Erfahrungen aus der praktischen Nutzung des Standards fließen in (a) zurück und tragen zur Standard-Reifung bei. Die Entwicklung neutraler Datenmodelle wurde und wird in unterschiedlichen Initiativen verfolgt, z.B. NE100 [7], PlantXML [8], STEP [9], Engineering Service Bus [10], mit wissensbasierten Systemen [11] oder ISO15926 [12]. Ein Engineering-Weltmodell ist dennoch nicht in Sicht und ist unter globalen Randbedingungen vermutlich nicht erreichbar. Während die Standardisierung nur reifen kann, wenn Erfahrungen aus der praktischen Anwendung einfließen, warten Werkzeughersteller typischerweise auf einen gereiften Standard, bevor sie ihre Software mit Ex- und Importern ausstatten. Daraus resultiert ein StandardisierungDeadlock, bei dem die Rückführungen der praktischen Erfahrungen in die Standardisierung (h) sowie die notwendigen Implementierungen der Hersteller (h) gestört sind. Ein bekanntes Beispiel für diesen Deadlock ist die STEP-Initiative. In diesem Ansatz beschreiben tausende Textseiten vielfältige Aspekte der Anlagenplanung und dessen LifeCycle. Diese Aktivität hat unter jahrelangen Bemühungen (a) bis (e) erfolgreich passiert, scheitert in der Praxis jedoch aufgrund seiner Komplexität an den Schritten (f), (g) und (h). Ein anderes Beispiel ist PlantXML. Innerhalb eines Unternehmens wurden über mehrere Jahre hunderte Attribute und Objekttypen für eine Auswahl von Werkzeugen standardisiert. PlantXML hat erfolgreich (a) bis (h) passiert und ist produktiv. Leider ist es für andere Unternehmen oder Gewerke nicht wiederverwendbar, da es an seine Werkzeuge gebunden ist. Folglich besitzt es Schwächen in (f), (g) und (h) – es ist keine Anwendung außerhalb ihrer Entstehungsquelle (früher Degussa) bekannt. Diese und weitere Beispiele zeigen, dass das benötigte Engineering-Weltmodell aufgrund der Vielzahl von Werksnormen, regionalen und nationalen Standards nicht in einem Schritt

erreichbar ist. Es wird daher ein Konzept benötigt, welches bereits heute den Umgang mit der Semantik-Vielfalt ermöglicht, statt auf ein künftiges übergreifendes Semantik-Modell zu warten.

2 Konzept zum Umgang mit heterogenen Datenmodellen 2.1 Grundlagen und Herleitung Die ursprüngliche Idee eines neutralen Datenformates beruht darauf, Daten herstellerunabhängig und verlustfrei zu modellieren und zu speichern. Das vorgestellte Konzept leitet sich direkt aus den in Bild 1 dargestellten Aufgaben idealer CAEX-Exporter und –Importer der teilnehmenden Werkzeuge ab.

Quell Tool

Ziel Tool DB

DB 1 Exporter

4

2

Mapping Quell – Neutral

3 AutomationML

Importer Mapping Neutral – Ziel

Bild 1: Idealer Datenaustausch mit CAEX

 Schritt 1: Ein Exporter exportiert Daten aus der proprietären Datenbank eines Quell-Engineering-Werkzeuges. Dazu benötigt er Zugriff auf die Quelldaten.  Schritt 2: Der Exporter transformiert die proprietären Daten verlustfrei in das vereinbarte neutrale CAEX-Datenmodell und speichert dies als AutomationML-Dokument ab. Dazu benötigt er Wissen über das proprietäre Datenmodell sowie das neutrale Datenmodell sowie zugehörige Transformationsregeln.  Schritt 3: Der Importer liest das AutomationML-Dokument ein und transformiert die Daten aus dem neutralen Datenmodell in das proprietäre Datenmodell des Zielwerkzeuges. Dazu benötigt er Wissen über das neutrale und das proprietäre Datenmodell des Zielwerkzeuges sowie zugehörige Transformationsregeln.  Schritt 4: Der Importer importiert die transformierten Daten in das proprietäre Datenmodell des Zielwerkzeuges. Dazu benötigt er Zugriff auf die Daten des Zielwerkzeuges. Leider fehlt hierzu ein neutrales Datenmodell. Für eine Vielzahl einzelner Objekte finden sich zwar aus aktuellen Standardisierungsergebnissen Teilmodelle, z.B. für ein „Signal“ (NE100) oder einen „Sensor“ (ISO 15926). Für viele Daten lassen sich in Schritt 2 jedoch keine oder wenige Transformationsregeln implementieren.

2.2 Die Idee eines gemischten Datenmodells Startpunkt der hier vorgestellten Idee ist ein Gedankenexperiment: Was passiert eigentlich, wenn man private Datenmodelle zuließe, statt sie zu vermeiden? Fehlende neutrale Datenmodelle sind für AutomationML bekanntermaßen kein Hindernis: CAEX erlaubt explizit das Speichern gemischt proprietär/neutraler Daten-Teilmodelle. Proprietäre Daten werden immerhin syntaktisch neutralisiert, semantisch bleiben sie proprietär. Auch wenn das Zielwerkzeug diese Daten nicht interpretieren kann (zu Beginn ein sehr wahrscheinlicher Fall), stellt dies bereits einen erheblichen Gewinn dar: erstmalig werden proprietäre Datenmodelle außerhalb ihres Werkzeuges syntaktisch neutralisiert und explizit sichtbar. Dies erleichtert die beiden Schritte (a) und (b) der beschriebenen Standardisierungskette. Als Konsequenz aus diesem Gedankenexperiment ändert sich die Aufgabe des Exporters (Bild 2):  Schritt 2: der Exporter transformiert nur diejenigen proprietären Daten, für die ein neutrales Datenmodell vorliegt. Die privaten Daten lässt er unverändert und überträgt sie 1:1 nach CAEX. Das resultierende CAEX-Dokument enthält in diesem Fall eine Mischung aus neutralen und privaten Daten-Teilmodellen. Andere Engineering-Werkzeuge können diese Datei öffnen, Inhalte untersuchen, Änderungsberechnungen durchführen und Versionsmanagement betreiben. Während neutrale Datenmodelle identifiziert und importiert werden können, gelingen die Interpretation und der Import proprietärer Daten nicht unmittelbar. Hierzu muss das jeweilige Zielwerkzeug den jeweiligen Absender und dessen Datenmodelle kennen um geeignete Transformationsroutinen aufrufen zu können. Als Konsequenz ändert sich die Aufgabe des Importers:  Schritt 3: der Importer transformiert die neutralen Daten ins proprietäre Datenmodell des Zielwerkzeuges, private Daten müssen jedoch mithilfe zugeschnittener privater Transformationsregeln interpretiert werden, oder sie werden ignoriert.

Quell Tool

Daten liegen gemischt neutral/privat vor

Ziel Tool DB

DB 1 Exporter

4

2

Mapping 1. Quell – Neutral 2. Quell - QuellCAEX Bild 2: Realer Datenaustausch mit CAEX

3 AutomationML

Importer Mapping 1. Neutral – Ziel 2. QuellCAEX – Ziel

2.3 Identifikation des Quellwerkzeuges Wie kann ein Importer erkennen, welche privaten Transformationsroutinen angewendet werden müssen? AutomationML führt dazu erstmalig einen standardisierten Etikettiermechanismus ein. Die CAEX-Datei bekommt ein Etikett (siehe Bild 3), welches während des Exports in Schritt 2 eingebettet wird und Informationen über das Quellwerkzeug enthält. Ein Importer kann dieses Etikett auswerten und private Transformationsroutinen anstoßen. Dieses Konzept wird von der frei verfügbaren Software AutomationML Engine [13] unterstützt.

Bild 3: AutomationML-Beispiel-Etikett

Dies führt für den Praktiker zu schnellen Lösungen ohne notwendiges Warten auf ein Engineering-Weltmodell. Diese Vorgehensweise bedeutet auch keinen Rückfall in die Situation, in der jedes Werkzeug seine Daten in seinem eigenen proprietären Datenformat exportiert, da folgende Aspekte erfüllt sind:  Das Etikettierkonzept erlaubt die automatische Absendererkennung. Excel-Sheets etc. verfügen über keine standardisierte Methodik dafür.  Das neutrale Datenformat ermöglicht die Neutralisierung proprietärer Datenmodelle auf Syntax-Ebene. Dies ermöglicht Datenmodell-unabhängige Operationen wie Versionsmanagement oder Änderungsberechnungen [3], [10]. Derartige Funktionalität müsste für jedes proprietäre Datenformat erneut entwickelt werden. Basierend auf einem neutralen Datenformat genügt eine einzige Implementierung. Ein Großteil des Importers kann daher – unabhängig vom jeweiligen Quellwerkzeug – wiederverwendet werden. 2.4 Praktische Relevanz Der vorgeschlagene Ansatz ändert den Weg zu einem neutralen Datenmodell erheblich: eine AutomationML-Datei wird nach dem Datenexport teilweise proprietär. Dies verletzt die UrIdee eines neutralen Datenformates und verlässt scheinbar bewährte Pfade. Zurecht: der hier vorgeschlagene Ansatz nutzt Heterogenität bewusst, anstatt sie überwinden zu wollen.  Entwickler von Export und Import Schnittstellen müssen nicht mehr auf einen gereiften Standard warten. Dies überwindet den beschriebenen Deadlock und beschleunigt die Entwicklung von Datenaustauschlösungen.  Für Standardisierungs-Gremien ist die Mischung von privaten und neutralen Daten-Teilmodellen ein fruchtbarer Boden für eine erfolgreiche schrittweise Standardisierungsevolution. Sie erlaubt gänzlich ohne Standardisierung mit ausschließlich privaten Daten zu beginnen, um schrittweise eine vollständige Standardisierung zu erreichen. Dabei werden Zwischenschritte durchlaufen aus denen die Autoren ein Reifegradmodell ableiten.

3 Reifegrade der Standardisierung Aus der Idee eines gemischt privat/neutralen Datenmodells entwickeln die Autoren ein Reifegradmodell der semantischen Standardisierung, dessen Stufen in Bild 4 abgebildet sind. Das Ziel dieses Reifegradmodells besteht darin, den erläuterten Standardisierungs-Deadlock zu durchbrechen und den Datenaustausch in einem heterogenen Werkzeugumfeld auch ohne bzw. nur mit teilweiser Standardisierung durchführen zu können. Im Vordergrund jedes Reifegrades steht immer dessen praktischer Einsatz. Die Entwicklung neutraler Daten-Teilmodelle erfolgt schrittweise und ist nicht mehr Voraussetzung für den praktischen Einsatz. Dies bedeutet, dass die Standardisierung der Nutzung folgt - nicht wie bisher umgekehrt. 3.1 Reifegrad 1 - Das vollständig private Datenmodell Reifegrad 1 beginnt mit einem Standardisierungsgrad von 0% (d.h. mit 100% privaten Daten). Nach Reifegrad 1 verwenden Exporter und Importer eines Quell- und Ziel-Engineeringwerkzeuges keinerlei lokale/globale Vereinbarungen oder Standards, die Werkzeuge sind völlig unabhängig. Der Exporter exportiert die Daten in Schritt 2 nach CAEX unter Verwendung der CAEX-Syntax, aber unter Verwendung des privaten Datenmodells des Quellwerkzeuges. Die Entwicklung des quellwerkzeugspezifischen Exporters ist gerade wegen des fehlenden Standards besonders einfach, der Aufwand wird im Wesentlichen nur noch durch die Offenheit des Quellwerkzeuges bestimmt [14]. Den Erfahrungen der Autoren zufolge ist ein Exporter, je nach angestrebter Produktreife, in wenigen Tagen zu implementieren [15].

Bild 4: Reifegrade der semantischen Standardisierung

Die Entwicklung des quellwerkzeugspezifischen Importers erfordert mehr Aufwand, wird

durch das beschriebene Konzept aber erheblich unterstützt. Aufgrund der standardisierten CAEX-Syntax kann der Importer (auch ohne Wissen über das Quell-Datenmodell) die Datei öffnen, durchsuchen und darstellen. Darüber hinaus sind wesentliche Funktionen eines Importers, wie Navigation, Änderungsberechnungen und Versions-Managementfunktionen unabhängig vom Datenmodell und lassen sich generisch entwickeln und wiederverwenden Das beschriebene Etikettierkonzept ermöglicht es dem Importer, das Quellwerkzeug festzustellen. Dies ist der Schlüssel zum „Erkennen“ von privaten Datenmodellen. Zu Beginn wird der Importer keine bekannten Datenmodelle (Klassen) finden (siehe Bild 4), dafür müssen zuerst geeignete private quellwerkzeugspezifische Subroutinen für die Interpretation und den Import entwickelt werden. Dies wird ebenfalls unterstützt: Der Importer kann konzeptbedingt „unbekannte private Datenmodelle“ erkennen und in einer eigens hierfür generierten CAEXBibliothek speichern. Aus dieser lässt sich der Entwicklungsbedarf automatisch ableiten und anhand von Häufigkeitsuntersuchungen sogar priorisieren. Private Transformationsroutinen können mit diesem Wissen schnell und in lokaler Verantwortung, d.h. ohne Abhängigkeiten zu höheren/öffentlichen Standardisierungsaktivitäten, entwickelt werden. Das Ziel ist der gelebte praktische Einsatz und die Reifung unter realen Bedingungen. Im Ergebnis werden aus „unbekannten“ somit „bekannte“ Datenmodelle. Die entwickelten privaten Transformationsroutinen lassen sich für jeden weiteren Datenaustausch mit demselben Quellwerkzeug wiederverwenden. Die Vorteile von Reifegrad 1 liegen in seiner unmittelbaren Einsetzbarkeit: da ein Standard nicht abgewartet werden muss, können zwei Werkzeughersteller oder -nutzer unmittelbare Export-Import-Partnerschaften eingehen. Ein dritter Teilnehmer kann sich (auch später) einbinden. Je mehr Teilnehmer desto geringer der Gesamtaufwand. Lediglich die Werkzeugpaar-spezifischen Transformationsroutinen sind unterschiedlich. Reifegrad 1 kombiniert die Kosteneffizienz eines leichtgewichtigen Excel-basierten Datenaustausches mit den Vorteilen höherwertiger Funktionen. Zudem bietet Reifegrad 1 einen weiteren neuartigen Vorteil: ein Importer kann alle Klassen feststellen, die ihm „unbekannt“ sind. Auf diese Weise werden nicht nur alle bekannten sondern auch alle unbekannten Daten explizit sichtbar. Diese Sichtbarkeit ist ein Schlüssel für die Identifikation von Entwicklungsbedarf und eröffnet den Weg zu einer automatischen Erzeugung von Lastenheften. Der Wissensaufbau im Umgang mit CAEX erfolgt schrittweise. Der Datenaustausch kann so bedacht eingeführt und praktiziert werden und reifen. Reifegrad 1 ist somit ein erster Meilenstein in der Evolution eines Standardisierungsprozesses: Er erleichtert die Schritte (a) und (b) und belebt die Rückführung von Erfahrungen (h) aus der praktischen Anwendung. Dieser Reifegrad ist für Werkzeuge geeignet und möglicherweise sogar ausreichend, die nur wenige Datenaustauschpartner besitzen. Die Entwicklung privater Transformationsroutinen benötigt deutlich weniger Aufwand als eine Standardisierung. Reifegrad 1 ist weiterhin ideal für Werkzeuge die lediglich ihre eigenen Daten archivieren bzw. extern manipulieren und anschließend wieder einlesen möchten. Mit wachsender Zahl von Teilnehmern wird eine Bibliothek aus Transformationsroutinen entstehen. Dies ist ein geeigneter Indikator für den Start einer Konsolidierung des Entwicklungsaufwandes und somit ein geeigneter Übergangspunkt zu Reifegrad 2, denn ähnliche Datenmodelle sind Kandidaten für eine erste Standardisierung.

3.2 Reifegrad 2 - Das gemischt standardisierte/private Datenmodell Reifegrad 2 entsteht aus der Konsolidierung der Standardisierungskandidaten aus Reifegrad 1 (siehe Bild 4). Für ähnliche private Datenmodelle entsteht im Kreise der Teilnehmer der Wunsch nach lokaler Standardisierung im Zuge einer kosteneffizienten Schnittstellenentwicklung. Dies erhöht die Standardisierungsbereitschaft und führt zu ersten neutralen „Mini“Datenmodellen. Für jedes neutralisierte „Mini“-Datenmodell kann in jedem Importer die Zahl n der privaten Transformationsroutinen für n Quellwerkzeuge auf eine einzige Transformationsroutine reduziert werden. Auf diese Weise entsteht ein Pool an neutralen Datenmodellen, während der Pool privater Transformationsroutinen abnimmt. Wichtig dabei ist das Verständnis für den Evolutionsprozess hin zu Reifegrad 2, welcher ausschließlich aus praktischen Projektbedürfnissen getrieben wird. Dies stellt einen natürlichen und evolutionären Prozess dar. Unter Verwendung erster neutraler Daten-Teilmodelle erzeugt ein Exporter in Reifegrad 2 ein gemischt standardisiert/privates CAEX-Datenmodell. Ein Importer kann alle „bekannten Datenmodelle“ anhand ihres Klassennamens sowie dem Etikett erkennen, interpretieren und importieren. Hierbei können dieselben Transformationsroutinen wiederverwendet werden die in Reifegrad 1 entstanden sind. Aus erkannten „unbekannten Datenmodellen“ lässt sich auch hier automatisiert Entwicklungsbedarf ableiten. Bild 5 illustriert anhand privater oder unbekannter Objekttypen Kandidaten, die als Standardisierungs- bzw. Entwicklungskandidaten in Frage kommen.

Bild 5: Automatisch ermittelter Entwicklungs- und Standardisierungsbedarf

Reifegrad 2 ist für überschaubare und feststehende Datenaustauschszenarien geeignet und in vielen Fällen sogar ausreichend. 3.3 Reifegrad 3 - Das neutrale Datenmodell Reifegrad 3 wird erreicht, wenn alle benötigten Daten-Teilmodelle durch neutrale Datenmodelle abgebildet werden. Er bildet das Gegenstück zu Reifegrad 1 da hierbei der Anteil an privaten Datenmodellen 0 Prozent beträgt. Seine Reife erlangt er durch Erfahrungen im praktischen Einsatz. Reifegrad 3 ist nicht an internationale Standards gebunden. Es könnte ebenso ein Standard eines einzelnen Projektes oder eines Konsortiums sein. Dieser Reifegrad kommt der eigentlichen Idee eines neutralen Datenaustauschformates bereits nahe: private Transformationsroutinen sind nicht mehr notwendig - das Datenmodell ist aus Erfahrungen der Reifegrade 1 - 2 gewachsen und gereift. Als Beispiel könnte das für das Engineering von Automatisierungssystemen zentrale Element „Signal“ international standardisiert werden, wohingegen ein anderes Datenmodell „Safety IO Modul“ zunächst proprietär oder lokal standardisiert bliebe.

3.4 Reifegrad 4 – das standardisierte neutrale Datenmodell Reifegrad 4 wird erreicht, wenn mehrere „Reifegrad 3 Standards“ zu einem übergeordneten Standard kombiniert werden (siehe Bild 4). Die Datenmodelle aus Reifegrad 3 bilden aufgrund praktischer Erfahrungen eine belastbare Basis für die Schritte (a) und (b) eines übergreifenden Standardisierungsvorhabens, z.B. für einen internationalen Standard. Dieser Reifegrad ist als langfristiges Ziel zu verstehen und ein evolutionäres Ergebnis des Durchlaufens der vorigen Reifegrade.

4 Diskussion des Konzeptes Das vorgestellte Reifegradmodell der Semantik-Standardisierung ist ein neuer Ansatz und eröffnet eine Vielzahl neuer Möglichkeiten und Vorteile. Vorteil 1: Schnellstart mit hoher Wiederverwendungsquote Werkzeughersteller oder Anwender können unmittelbar starten. Sobald ein Datenaustauschbedarf identifiziert ist, kann der Projektleiter eine individuelle Entwicklung der wichtigsten Subroutinen für den automatischen Import privater Daten aus einem Quell-EngineeringWerkzeug in das von ihm gewünschte Zielwerkzeug initiieren. Die privaten Transformationsroutinen eines Importer können später von Projekt zu Projekt wiederverwendet werden. Der Aufwand zur CAEX-Programmierung wird mit [15] beherrschbar. Vorteil 2: Datenmodelle werden explizit sichtbar Normalerweise sind Datenmodelle in ihren Werkzeugen verborgen und nur Experten zugänglich. Das von AutomationML verfolgte Konzept macht proprietäre und unbekannte Datenmodelle jedoch explizit sichtbar. Dies vereinfacht die Entwicklung im Projekt, befördert die Diskussion über Datenmodelle und beschleunigt die Standardisierungsschritte (a)-(c). Vorteil 3: Automatische Ableitung von Entwicklungs- und Standardisierungsbedarf Konzeptbedingt können „unbekannte Datenmodelle“ erkannt und in Bibliotheken gespeichert werden. Diese Bibliotheken lassen sich als Lastenheft für eine Importer-Softwareentwicklung einsetzen, da sie die privaten Datenmodelle möglicher Datenaustauschkandidaten explizit spezifizieren. Mit statistischen Mitteln lassen sich sogar Prioritäten ableiten. Der vorgestellte Ansatz optimiert das Verhältnis zwischen den Aufwänden zur Entwicklung privater Transformationsroutinen und der Standardisierung. Durch das explizite Wissen über „unbekannte“ oder „ähnliche“ Datenmodelle können Standardisierungsaktivitäten fokussiert werden. Dies wird durch einen impliziten Regelkreis erreicht: die Entwicklung privater Transformationsroutinen für jedes Quellwerkzeug ermöglicht schnelle Ergebnisse, führen aber mit der Zeit zu redundanter Entwicklung pro Quellwerkzeug. Diese Kosten sind Treiber für eine vernünftige und zielgerichtete Standardisierung, die mittelfristig die Entwicklungskosten senkt. Seltene private Datenmodelle können in privaten Transformationsroutinen verbleiben. Aus diesen Gründen behindert das Etikettierkonzept nicht die Standardisierung, sondern befördert sie. Vorteil 4: “Speed-Standardisierung” von Mini-Datenmodellen Das Etikettierkonzept sowie die Mischung privater und neutraler Daten eliminiert den Bedarf

nach einem umfassenden und gereiften Engineering-Weltmodell: der Schwerpunkt verlagert sich stattdessen auf kleine und flexible Mini-Datenmodelle, wie beispielsweise das „Signal“Modell. Signallisten werden vielfältig ausgetauscht, die Standardisierung eines Signalobjektes ist im Fertigungsumfeld erreichbar und bereits aus rein praktischen Erwägungen ein lohnenswertes und erreichbares Ziel. Eine solche Speed-Standardisierung kann von erfahrenen Projektleitern oder Lead-Ingenieuren in kurzer Zeit erfolgen. Das Ergebnis dieser Arbeit ist ein lokaler Standard welcher sich umgehend in Importer und Exporter implementieren lässt. Darüber hinaus kann dieser Standard sofort im Praxisgebrauch überprüft werden, Kostenersparnisse könnten vor Ort unmittelbar von den Beteiligten im Initialprojekt realisiert und in Nachfolgeprojekten vervielfacht werden. Diese “Mikro-Standardisierung” zwischen zwei Werkzeugen ist ein agiler, pragmatischer Weg mit iterativen Standardisierungs-Sprints. Die Standardisierungsschritte (a) bis (c) können sogar automatisiert werden, (f) wird innerhalb des Teams gelöst und (h) wird durch die unmittelbare praktische Anwendung erreicht. Vorteil 5: Zeitliche Entkopplung von Standardisierung und Projektarbeit Die Behandlung privater Transformationsroutinen erfolgt in der Verantwortung des Projektes und kann schnell umgesetzt bzw. lokal priorisiert werden. Die Standardisierung hingegen erfolgt außerhalb in einem übergeordneten Regelkreis und fließt erst mit seiner Finalisierung in das Projekt ein. Diese Entkopplung ermöglicht das gleichzeitige Agieren in kurzfristigen Projekterfordernissen und in langfristigen Standardisierungsaktivitäten. Vorteil 6 – Einführung von Standard-Etiketten Das Etikettierkonzept ist nicht nur geeignet um Quellwerkzeuge zu identifizieren. Es kann ebenso auf einen oder mehrere zugrundeliegende Standards verweisen. Eine AutomationML-Datei kann erstmalig aktiv mitteilen, welche Semantik-Standards sie verwendet. 4.1 Diskussion, Zusammenfassung und Ausblick Die Standardisierungsgremien und Softwarehersteller haben frühzeitig den Wert eines gemeinsamen Datenmodelles erkannt und verfolgen mehrheitlich Reifegrad 3 bzw. 4. Dieser Beitrag zeigt, dass das Ziel sinnvoll, der Weg jedoch fraglich ist. Für die Praxis macht es keinen Sinn, sofort mit Reifegrad 3 oder 4 zu beginnen, zumindest in einem so breiten Kontext wie der Automatisierungsplanung nicht in einem Schritt: ein reifer Standard benötigt Erfahrungen aus der industriellen Anwendung. Eine Evolution beginnt stets mit dem ersten Schritt (Reifegrad 1). Solange die beteiligten Werkzeuge „offen genug“ sind [13], wird die semantische Vielfalt mit dem vorgestellten Konzept beherrschbar. Hersteller und Anwender können Exporter für ihre Werkzeuge erstellen, ohne sich auf einen Standard beziehen zu müssen. Generische Importer sind erst mit Reifegrad 3-4 sinnvoll und deshalb heute für weite Bereiche der Anlagenplanung nicht anzutreffen. Zur Beherrschung der semantischen Vielfalt sind für die Reifegrade 1-2 quellwerkzeugspezifische Importer erforderlich. Das vorgestellte Konzept vereinfacht deren Entwicklung maßgeblich, da große Teile typischer Importfunktionalitäten generisch angelegt werden können. Anwender können diese in Eigenregie deutlich leichter und schneller als bisher entwickeln. Gerade für das Umsetzen weniger Datenaustauschpartner ist der Entwicklungsaufwand deutlich geringer als das Stan-

dardisieren eines Weltmodells. Zudem können Werkzeughersteller im Sinne des Know-HowSchutzes mit kommerziellen Importern gezielter als bisher beeinflussen, welche Quellwerkzeuge sie mit welchem Detaillierungsgrad unterstützen. Mit diesem Ansatz versuchen die Autoren nicht, die bestehende Heterogenität von Engineering-Werkzeugen und Datenmodellen durch Vereinheitlichung zu überwinden; das Konzept verfolgt vielmehr das Anliegen, den Datenaustausch in einem heterogenen Werkzeugumfeld auch ohne bzw. nur mit teilweiser Standardisierung durchführen zu können. Die Ur-Idee eines neutralen Datenformates wird hierbei bewusst verletzt – aber Innovationen werden oftmals dann erreicht, wenn bekannte Pfade verlassen bzw. zuvor gesetzte Einschränkungen hinterfragt werden. Das vorgestellte Konzept zur Speicherung gemischt privat/neutraler standardisierter Daten in einem AutomationML-Dokument führt zu sinnvollen und neuartigen Vorteilen und ist unmittelbar anwendbar. Das Warten auf einen Standard ist nicht mehr nötig. Der praktische Einsatz steht in jedem Reifegrad im Vordergrund, die Standardisierung folgt der Nutzung, nicht umgekehrt. Der Praktiker erhält über die Erkennung unbekannter Datenmodelle automatisch ein Lastenheft für die Softwareentwicklung. Proprietäre Datenmodelle werden explizit sichtbar. Industrie, Akademia und Gremien können aufgrund der expliziten Sichtbarkeit proprietärer Daten-Teilmodelle Ähnlichkeitsanalysen durchführen und erstmalig Standardisierungsbedarf inklusive Priorisierung automatisch ableiten.

5 Literatur [1] [2] [3] [4] [5]

[6] [7] [8] [9] [10] [11] [12] [13] [14] [15]

IEC 62714-1 CD norm draft AutomationML Architecture, www.iec.ch, 2011. Drath R., Barth M.: Concept for interoperability between independent engineering tools of heterogeneous disciplines. In: proceedings of the “IEEE Conference on Emerging Technologies and Factory Automation (ETFA)”, Sept. 2011. Drath R., Fay A., Barth M.: Interoperabilität von Engineering-Werkzeugen. In at 09/2011, pp 598-607, Oldenbourg Verlag, 2011. Drath, R.: Datenaustausch in der Anlagenplanung mit AutomationML: Integration von CAEX, PLCopen XML und COLLADA, Springer Berlin Heidelberg; Auflage: 1 Dezember 2009. AIDA (2005): Automatisierungsinitiative Deutscher Automobilhersteller - Analyse Investitionskostenstruktur Steuerungstechnik und Robotik am Beispiel Rohbau, 2005. Zitiert nach: Garcia, A.; Drath, R.: AutomationML verbindet Werkzeuge der Fertigungsplanung. Quelle: http://www.automationml.org - Whitepaper_AutomationML_2007-1120_v05.pdf. [letzter Zugriff 27.04.2010]. IEC 62424:2008, Representation of process control engineering - Requests in P&I diagrams and data exchange between P&ID tools and PCE-CAE tools. Namur Empfehlung 100: Merkmalleisten zur Erstellung von PLT-Gerätespezifikationen. 2003. Anhäuser, F., Richert, H., Temmen, H.: Degussa Plant-XML - integrierter Planungsprozess mit flexiblen Bau-steinen. atp 46 (2004), H. 4, S. 63-72. ISO10303: Automation systems and integration - Product data representation and exchange, formerly known as STEP, Standard for the Exchange of Product model data. T. Moser, S. Biffl: Semantic Tool Interoperability for Engineering Manufacturing Systems, In: Proceedings of the “IEEE Conference on Emerging Technologies and Factory Automation (ETFA)”, 2010, pp. 1-8. Wiesner A et.al.: Wissensbasierte Integration und Konsolidierung von heterogenen Anlagenplanungsdaten. atp edition, 2010, 52(4), 48-58. ISO 15926. Industrial automation systems and integration - Integration of life-cycle data for process plants in-cluding oil and gas production facilities. www.automationml.org Fay, A., Drath,R., Barth,M., Zimmer,F., Eckert K.: Bewertung der Fähigkeit von Engineering-Werkzeugen zur Interoperabilität mit Hilfe einer Offenheitsmetrik. In: Tagungsband "Automation 2012", 13-14. Juni 2012, Baden-Baden. Drath R.: Let’s talk AutomationML: What is the effort for AutomationML programming? In: Proceedings of the “IEEE Conference on Emerging Technologies and Factory Automation (ETFA)” 2012, Second workshop on Industrial Automation Tool Integration for Engineering Project Automation, Krakow, Sept. 2012.