Die Idee des \’Super-Datenmodells\‘ ist die treibende Kraft aller entsprechenden Standardisierungsaktivitäten, z.B. NE100 [1], STEP [2], ISO15926 [3] u.v.m. Dazu müssen sie stets folgende Schritte durchlaufen:
a) Experten sammeln für beteiligte Gewerke bzw. Werkzeuge sinnvolle Datenmodelle und Konzepte.
b) Experten einigen sich auf die gemeinsam benötigten 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 neutrale Syntax, z.B. basierend auf XML.
e) Alle gesammelten Konzepte, das semantische Datenmodell und die Umsetzung in einer gemeinsamen Syntax, werden dokumentiert.
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 Reifung bei.
Bis heute ist dies nicht gelungen. Bild 1 erklärt den Konflikt: Standardisierung reift nur durch Rückfluss von Erfahrungen aus der praktischen Anwendung. Werkzeughersteller warten jedoch aus Kostengründen typischerweise erst auf einen gereiften Standard, bevor sie ihre Software mit Ex- und Importern ausstatten. Die Rückführungen der praktischen Erfahrungen in die Standardisierung (h) sowie die notwendigen Implementierungen der Hersteller (g) sind gestört, die Standardisierung befindet sich in einem Deadlock.
Die Idee: Ein gemischtes Datenmodell
Ein Weltmodell des Engineering ist offensichtlich nicht in einem Schritt erreichbar. AutomationML [4] verfolgt daher einen anderen Ansatz. Anstatt auf eine Standardisierung zu warten, lässt es die Speicherung proprietärer Semantiken explizit zu [5]. Beim Export aus einem Engineeringwerkzeug werden die Daten syntaktisch neutralisiert, die Semantik bleibt jedoch proprietär (\’privat\‘). Ein Signal würde beispielsweise alle Eigenschaften inklusive seines Namens aus dem Ursprungswerkzeug behalten. Auch wenn das Zielwerkzeug diese Daten zunächst nicht interpretieren kann (gerade zu Beginn), stellt dies bereits einen erheblichen Gewinn dar: Erstmalig werden proprietäre Datenmodelle aus ihrem Werkzeug herausgelöst, syntaktisch neutralisiert und untersuchbar. Dies erleichtert die beiden Schritte (a) und (b) der beschriebenen Standardisierungskette erheblich. Ziel-Engineering-Werkzeuge können die Datei öffnen, durchsuchen und darstellen. Funktionen wie Navigation, Änderungsberechnungen und Versions-Management sind unabhängig vom Datenmodell und lassen sich generisch entwickeln und wiederverwenden. Es fehlen nur noch die Transformationsroutinen, die für die proprietären Datenmodelle des Quellwerkzeuges zugeschnitten sind. Doch woher kommen sie und wie kann ein Importer erkennen, welche davon aufgerufen werden müssen?
Die Idee: Identifikation des Quellwerkzeuges
AutomationML führt dazu erstmalig einen standardisierten Etikettiermechanismus ein. Die CAEX-Datei bekommt ein Etikett (siehe Bild 2), welches während des Exports in die AutomationML-Datei 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 [6] unterstützt. Diese Vorgehensweise bedeutet keineswegs, dass jedes Werkzeug seine Daten dann auch gleich in seinem eigenen proprietären Datenformat exportieren könnte. Bereits die syntaktische Neutralisierung bringt entscheidende Vorteile:
- Der Hauptaufwand eines Importers liegt in Operationen wie Versionsmanagement oder Änderungsberechnungen. Diese Operationen sind unabhängig vom Datenmodell. 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.
- Das Etikettierkonzept erlaubt die automatische Absendererkennung. Proprietäre Datenformate wie z.B. Excel-Sheets etc. verfügen über keine standardisierte Methodik dafür.
Und dann?
Die quellwerkzeugspezifischen Subroutinen für die Interpretation und den Import müssen erst entwickelt werden. Die Erkennung des Quellwerkzeuges ist der Schlüssel. Der \’Trick\‘ besteht darin, dass der Importer \’unbekannte private Datenmodelle\‘ erkennen und in einer separaten CAEX-Bibliothek speichern kann. Mit anderen Worten: Der Importer weiß, was er nicht weiß. Eine Bibliothek unbekannter Datentypen bzw. Klassen enthält alle Datenmodell-Kandidaten, sozusagen ein Lastenheft für die Softwareentwicklung. Anhand von Häufigkeitsuntersuchungen lassen sie die Kandidaten sogar priorisieren. Private Transformationsroutinen können damit ohne Warten auf einen Standard in lokaler Verantwortung entwickelt werden. Das geht schneller als jede Standardisierung. Das Ziel ist zunächst der gelebte praktische Einsatz und die Reifung unter realen Bedingungen. Nach der Entwicklung erster Transformationsroutinen werden aus \’unbekannten\‘ somit \’bekannte\‘ Datenmodelle. Sie lassen sich für jeden weiteren Datenaustausch mit demselben Quellwerkzeug wiederverwenden. Das beschriebene Szenario ist unmittelbar einführbar. Zwei Werkzeughersteller oder -nutzer können beliebig Export-Import-Partnerschaften eingehen. Ein dritter Teilnehmer kann sich (auch später) einbinden. Dieses Szenario stellt zugleich Reifegrad 1 eines evolutionären Reifegradmodells dar: (siehe Bild 3). Dieser ist 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. Der Deadlock aus Bild 1 wird durchbrochen. 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 einer 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. Reifegrad 2 entsteht aus der Konsolidierung der Standardisierungskandidaten aus Reifegrad 1. Ähnliche Datenmodelle führen zu Mehrfachentwicklung von ähnlichen Transformationsroutinen und erhöhen unnötig die Entwicklungskosten. Dies fördert 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. Der Evolutionsprozess hin zu Reifegrad 2 wird somit aus praktischen Projektbedürfnissen getrieben. 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 CAEXDatenmodell. 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% 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. Reifegrad 4 wird erreicht, wenn mehrere \’Reifegrad 3 Standards\‘ zu einem übergeordneten Standard kombiniert werden. 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.
