DE10026478A1 - Verfahren zur Generierung anwendungsspezifischer Eingabedateien - Google Patents

Abstract

Die Erfindung bezieht sich auf ein Verfahren zur Generierung anwendungsspezifischer Eingabedateien für Anwendungen, wie Simulatoren, Planungssysteme oder Diagnosesysteme, die Eingabedateien in unterschiedlichen Dateiformaten erfordern, wobei Daten zur Beschreibung industrieller Anlagen in einer Datenbank eines Rechnersystems als XML-formatierte, auf einem Klassenmodell basierende Dateien abgelegt werden und eine modulare Transformation in wenigstens eine anwendungsspezifische Eingabedatei in nachstehenden Phasen erfolgt: DOLLAR A a) in einer ersten Phase werden eine oder mehrere XML-Dateien in einen Speicher geladen, decodiert, interpretiert und - insbesondere bezüglich Semantik und Konsistenz - geprüft, wobei im Fall eines dabei ermittelten Fehlers ein Abbruch des Verfahrens und im anderen Fall eine Fortsetzung des Verfahrensablaufs erfolgt, DOLLAR A b) in einer zweiten Phase werden mittels einer Schnittstelleneinrichtung, die Beschreibungen der Funktionalität der jeweiligen Anwendungen enthält, basierend auf den geprüften XML-Dateien, Beschreibungen von Objekten der industriellen Anlage im XML-Format erzeugt, und DOLLAR A c) in einer dritten Phase wird durch kanonische Transformation aus den erzeugten Objektbeschreibungen in XML-Darstellung die wenigstens eine anwendungsspezifische Datei erstellt.

Description

Die Erfindung bezieht sich auf ein Verfahren zur Generierung anwendungsspezi­ fischer Eingabedateien für Anwendungen, wie Simulatoren, Optimierer, modellba­ sierter prädiktiver Regler (MPC), Prozeßdatenvalidierer, Planungssysteme, Abnormal Situation Management Systeme, Asset Management Systeme oder Diagnosesyste­ me, die Eingabedateien in unterschiedlichen Dateiformaten erfordern, wobei von XML-formatierten Dateien ausgegangen wird.

Informationsmodelle werden zumeist in proprietären Formaten gespeichert, wie sie von Datenbanken, wie Oracle (vergl. z. B.: George Koch and Kevin Loney, Oracle 8: The Complete Reference (Oracle Series), Oracle Press, September 1997) oder ob­ jekt-orientierten Modellierungstools, wie Rational Rose (vergl. z. B.: Terry Quatrani, "Visual Modeling with Rational Rose 2000 and UML", Addison Wesley, 1999) ver­ wendet werden. Es gewinnt auch die Darstellung von Informationsmodellen in Form von XML DTDs (vergl. z. B.: Simon St. Laurent and Robert Biggar, "Inside XML DTDs", McGraw-Hill, 1999), oder XML Schemata (vergl. z. B.: James Rumbaugh, Ivar Jacobson, and Grady Booch, "The Unified Modeling Language Reference Manual", Addison-Wesley, 1999) an Bedeutung. Solche XML-basierten Darstellungen weisen im Vergleich zu proprietären Formaten folgende Vorteile auf: Sie sind für Menschen - unter Verwendung von Editoren - lesbar, und sie sind portabel, d. h. auf unterschiedli­ chen Computertypen und Betriebssystemen verwendbar. Außerdem wird die Erzeu­ gung sowie das Einlesen (Parsing) von XML durch Standard-Tools, wie den Micro­ soft XML-DOM-Parser unterstützt.

Es sind auch Vorschläge für die Erzeugung applikationsspezifischer Eingabedateien aus einer XML-Datei bekannt geworden, wie XSL/CSS/XSLT, oder auch ein gra­ phisches Abbildungswerkzeug (Mapper Tool), das von der BizTalk-Initiative ange­ kündigt wurde. Allerdings bestehen bei den bekannten Ansätzen folgende Probleme:
In vielen neuen Systemen wird XML als Formalismus zur persistenten Repräsentati­ on von Informationen gewählt, um proprietäre Formate zu vermeiden. Der Verwen­ dung von XML bei der Repräsentation von Datenmodellen stehen aber einige Ein­ schränkungen entgegen: XML ist nicht objekt-orientiert, d. h. zentrale Konzepte der Objektorientierung (Klassen, Vererbung, Assoziationen) existieren nicht in XML. Die­ se müssen daher auf die einfacheren Darstellungsmittel von XML abgebildet werden.

Ähnliche Probleme gibt es bei Datentypen: XML DTDs unterstützen keinerlei Daten­ strukturen, XML Schemata können nur primitive Datentypen wie Zeichenketten und Zahlen darstellen. Beiden Standards fehlt eine explizite Unterstützung von Listen und Vektoren. Diese müssen somit ebenfalls durch einfachere XML-Konzepte nachgebil­ det werden.

Der Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren zur automatisierten Generierung anwendungsspezifischer Eingabedateien in unterschiedlichen Dateifor­ maten anzugeben, wobei von XML-formatierten Dateien ausgegangen wird, und die vorgenannten Nachteile vermieden werden.

Diese Aufgabe wird durch ein Verfahren zur Generierung anwendungsspezifischer Eingabedateien für Anwendungen wie Simulatoren, Planungssysteme oder Diagno­ sesysteme, die Eingabedateien in unterschiedlichen Dateiformaten erfordern, gelöst, das die im Anspruch 1 angegebenen Merkmale aufweist. Eine vorteilhafte Ausge­ staltung ist in einem weiteren Anspruch angegeben.

Beim erfindungsgemäßen Verfahren werden demnach auf der Basis eines gemein­ samen Klassenmodells Eingabedateien für externe Anwendungsprogramme gene­ riert. Das Klassenmodell beschreibt die Domäne, beispielsweise die herstellende In­ dustrie (Manufacturing Industry), dabei insbesondere die verfahrenstechnische Industrie (Process Industries), darin insbesondere die chemische und petrochemische Industrie, Raffinerien, Öl- und Gas-Industrie, Energie erzeugende Industrie, Lebens­ mittel- und Verbrauchsgüterindustrie, pharmazeutische Industrie, Zellstoff- und Pa­ pier-Industrie sowie Metall erzeugende und verarbeitende Industrie sowie die Roh­ stoffindustrie.

Es ist persistent in XML-Format gespeichert. Zu diesem allgemeinen Klassenmodell existieren projektspezifische Instanzdaten sowie Informationen, die zur Konfiguration der Anwendungen (externen Applikationen) dienen. Alle diese Informationen liegen als XML-Dateien vor. Bei den externen Applikationen handelt es sich um Programme zur Lösung unterschiedlicher Aufgaben auf Basis des gemeinsamen Klassenmodells sowie der Projektdaten. Beispiele solcher Applikationen sind gleichungs-basierte Si­ mulation und Optimierung, Parameter-Schätzung, modellbasierte prädiktive Regler (MPC), Prozeßdatenvalidierung, Planung, Abnormal Situation Management, Asset Management und Diagnose.

Die Applikationen sind getrennt entwickelte oder von Fremdfirmen zukaufbare Pro­ gramme, die jeweils unterschiedliche und untereinander nicht kompatible Eingabe­ formate aufweisen. Das Verfahren arbeitet im Sinn eines offenen Systems und er­ laubt die Integration zukünftiger Applikationen mit neuen, vom Anwender nicht beein­ flußbaren Formaten.

Eine weitere Beschreibung der Erfindung und ihrer Vorteile erfolgt nachstehend an­ hand eines in Zeichnungsfiguren dargestellten Ausführungsbeispiels.

Es zeigt:

Fig. 1 eine Übersicht zum Verfahrensablauf,

Fig. 2 Transformations-Phasen des Verfahrens, und

Fig. 3 eine Darstellung zur Modularität und Wiederverwendbarkeit des Verfah­ rens.

Fig. 1 zeigt schematisiert das erfindungsgemäße Verfahren, mit dem eine modulare Transformation von in XML repräsentierten Klassen und Instanzen in applikations­ spezifische Formate automatisiert durchgeführt wird.

Bei der damit durchgeführten Generierung applikationsspezifischer Eingabedateien aus einem Klassenmodell müssen die gegebenen Einschränkungen von XML be­ rücksichtigt werden. Die Bestandteile der XML-Datei, die dem Klassenmodell ent­ sprechen, müssen als Klassen, Assoziationen, Listen, usw. interpretiert werden, be­ vor daraus die applikationsspezifischen Eingabedateien generiert werden können. Dieser Interpretationsschritt, der von den elementaren Beschreibungsmitteln der XML-Datei zurück zu dem ursprünglichen objekt-orientierten Modell führt, wird von den bekannten Werkzeugen für XML-Konvertierung (XSL, Mapper Tool) nicht unter­ stützt.

Darüber hinaus weichen die Konzepte, die den Eingabedateien externer Applikatio­ nen zugrunde liegen, stark von den Konzepten des hier benutzten Klassenmodells ab. Dies ist unvermeidbar, da diese Applikationen zum größten Teil Produkte unter­ schiedlicher Hersteller sind, auf die ein Anwender des Verfahrens keinen Einfluß hat. Die XML-Dateien enthalten das Domänen-Modell, die Instanz-Daten des Projektes, sowie die notwendigen Konfigurationsdaten für die Applikationen. Derzeitige Konver­ tierungsansätze wie XSL unterstützen in erster Linie die direkte Abbildung von Ele­ menten der Quellsprache (im vorliegenden Fall das Klassenmodell) auf Elemente der Zielsprache (in vorliegenden Fall die applikations-spezifischen Eingabeformate). Für die vorgesehene Anwendung sind aber komplexe Beziehungen zwischen Quell- und Zielformalismus notwendig. Um einen Abschnitt einer applikations-spezifischen Ein­ gabedatei zu erzeugen, müssen mehrere Klassen des Klassenmodells gelesen und mit mehreren Objekten aus den Projektinstanzen in Beziehung gesetzt werden. Die­ se Objekte können in den Quelldateien in beliebiger Reihenfolge auftreten.

Ein weiterer Nachteil bisheriger Lösungen ist die fehlende Modularität der Format­ konvertierung. Die gesamte Übersetzung von der XML Repräsentation in das Appli­ kations-spezifische Format wird in einem Schritt spezifiziert. Bei der erfindungsge­ mäß ermöglichten Anwendung ist die Transformation komplex und wird daher in Phasen durchgeführt. Desweiteren werden vorteilhaft mehrere unterschiedliche ex­ terne Applikation unterstützt. Die Ähnlichkeiten zwischen den Übersetzungsvor­ schriften für diese unterschiedlichen Applikationen werden ausgenutzt, indem bei der benutzten modularen Transformation Teiltransformationen zwischen den Applikatio­ nen wiederverwendet werden.

In Fig. 2 sind die drei Phasen der Transformation dargestellt.

In Phase 1 wird eine XML Datei, die das Klassenmodell beschreibt, in den Speicher eines Rechnersystems geladen, decodiert und einer semantischen Prüfung sowie Konsistenz-Prüfung unterzogen.

Die Phase 1 enthält vorzugsweise folgende Schritte: In einem ersten Schritt wird der XML DOM Parser verwendet, um die Datei(en) in den Speicher zu laden. Es erfolgt eine Semantik-Prüfung. Das Resultat ist eine DOM Struktur.

In einem zweiten Schritt wird die als DOM Struktur vorliegende Information decodiert und interpretiert. Ein Beispiel für diesen Interpretationsprozeß stellt die Behandlung von Listen dar: Listen werden in XML als verschachtelte Strukturen von Elementen dargestellt. Die verschachtelte Struktur wird gelesen, als Liste interpretiert, und das im Modell intendierte Listenobjekt im Speicher abgelegt.

Die als Resultat der Interpretation erzeugten Objekt-Strukturen werden anschließend auf Konsistenz geprüft. Diese Prüfungen sind notwendig, da aufgrund der Aus­ drucksschwäche von XML die Konsistenz nicht allein durch XML-Syntaxprüfung ga­ rantiert ist. Beispielsweise wird in diesem Schritt geprüft, ob ein Objekt, das in einer Assoziation referenziert wird, tatsächlich existiert. Wenn ein Fehler ermittelt wird, wird das automatisierte Transfomationsverfahren mit einer Fehlermeldung abgebrochen.

Die Funktionalität der sich anschließenden Phase 2 wird durch ein Interface definiert, das hier als Common Model API bezeichnet wird. Dieses Interface stellt für jede Klasse des Klassenmodells eine Erzeugungsmethode zur Verfügung. Sobald alle für die Erzeugung eines Objektes, z. B. einer Systemkomponente (Facility) notwendigen Informationen gesammelt sind, wird die entsprechende Erzeugungsmethode, z. B. createFacility, mit den gesammelten Informationen als Parameter aufgerufen.

Die Implementierung der Erzeugungsmethoden, z. B. createFacility, ist applikations­ spezifisch. Für jede der zu unterstützenden externen Applikationen existiert daher eine Implementierung des Common Model APIs. Diese Implementierung beschreibt, wie das Objekt in dem Eingabedatei-Format der Applikation dargestellt werden muß.

Wie bereits beschrieben, können die meisten zu unterstützenden externen Applika­ tionen zugekauft und ohne Berücksichtigung des Common Models entwickelt worden sein. Solche Applikationen erwarten die Information in anderer Zusammenstellung und Reihenfolge, als sie im Klassenmodell und den Projektdaten vorliegen. Soll bei­ spielsweise eine aus der XML-Darstellung gelesene Komponente im Eingabeformat eines gleichungsbasierten Simulators beschrieben werden, so ist dies nicht möglich, bevor ein zweites Objekt, z. B. ein durch die Komponente ermöglichter chemischer Prozeß, ebenfalls gelesen und interpretiert wurde.

Aus diesem Grund kann die applikationsspezifische Implementierung des Common Model APIs nicht unmittelbar die Eingabedatei erzeugen. Statt dessen generiert sie eine zweite interne Darstellung, die sich am Aufbau der zu erzeugenden Eingabe­ datei orientiert. Im Falle der gleichungs-basierten Simulation wird beispielsweise eine XML-DOM-Speicherstruktur verwendet, die exakt dem Aufbau der Simulator- Eingabedatei entspricht. Die Implementierung des Common Model APIs fügt in Pha­ se 2 jede eingelesene Information, z. B. das Facility-Objekt, an der passenden Stelle in diese Speicherstruktur ein.

In Phase 3 wird die Speicherstruktur, die nun alle Informationen enthält, einmal kom­ plett ausgelesen und daraus die Eingabedatei der Applikation, z. B. des Simulators, erzeugt. Dieser letzte Schritt wird als kanonische Transformation bezeichnet, da eine 1-zu-1 Beziehung zwischen den Elementen der Speicherstruktur und den Elementen der Eingabedatei besteht, die Speicherstruktur also nur dazu dient, Informationen in beliebiger Reihenfolge einzufügen, was in der Textdatei nicht möglich wäre. Die Phase 3 ist vollständig von dem Klassenmodell abgekoppelt und muß daher nicht verändert werden, wenn sich das Klassenmodell ändert.

Fig. 3 macht die Vorteile des Verfahrens bei der Unterstützung mehrerer externer Applikationen deutlich. Sie zeigt die Wiederverwendung von Phasen am Beispiel eines gleichungs-basierten Simulators und einer SQL-Datenbank zur Speicherung der Simulationsergebnisse. Die Elemente der Phasen 1 und 2, einschließlich des Com­ mon Model APIs sind in beiden Transformationen identisch und müssen nur einmal implementiert werden. Die Implementierungen der Phase 3 sind zwar applikations­ spezifisch, müssen aber wegen der Entkoppelung vom Klassenmodell nicht ange­ paßt werden, wenn sich dieses ändert.

Die vorgeschlagene dreiphasige Transformation hat somit folgende Vorteile:

• - Die Modularität der Transformation erleichtert die Formulierung des komplexen Übersetzungsprozesses.
• - Teile der Transformation können unverändert in den Übersetzungsprozessen für verschiedene Applikationen wiederverwendet werden.
• - Die Einführung einer neutralen Schicht (das Common Model API) bietet eine grö­ ßere Unabhängigkeit in bezug auf Änderungen in Standards und proprietären Lö­ sungen an beiden Enden der Transformation (Struktur des Klassenmodelles/­ Strukturen der externen Applikationen).

Claims (2)

1. Verfahren zur Generierung anwendungsspezifischer Eingabedateien für Anwendungen, wie Simulatoren, Planungssysteme oder Diagnosesysteme, die Ein­ gabedateien in unterschiedlichen Dateiformaten erfordern, wobei
Daten zur Beschreibung industrieller Anlagen in einer Datenbank eines Rechnersystems als XML-formatierte, auf einem Klassenmodell basierende Dateien abgelegt werden, und
eine modulare Transformation in wenigstens eine anwendungsspezifische Eingabedatei automatisiert in nachstehenden Phasen erfolgt:

• a) in einer ersten Phase werden eine oder mehrere XML-Dateien in einen Spei­ cher geladen, decodiert, interpretiert und - insbesondere bezüglich Semantik und Konsistenz - geprüft, wobei im Fall eines dabei ermittelten Fehlers ein Abbruch des Verfahrens und im anderen Fall eine Fortsetzung des Verfah­ rensablaufs erfolgt,
• b) in einer zweiten Phase werden mittels einer Schnittstelleneinrichtung, die Beschreibungen der Funktionalität der jeweiligen Anwendungen enthält, ba­ sierend auf den geprüften XML-Dateien Beschreibungen von Objekten der industriellen Anlage im XML-Format erzeugt, und
• c) in einer dritten Phase wird durch kanonische Transformation aus den er­ zeugten Objektbeschreibungen in XML-Darstellung die eine anwendungs­ spezifische Datei oder die mehreren anwendungsspezifischen Dateien er­ stellt.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß zur Durchfüh­ rung der ersten Phase
in einem ersten Schritt mittels eines XML DOM Parsers die eine XML-Datei oder die mehreren XML-Dateien in den Speicher geladen werden und eine Semantik-Prüfung erfolgt, so daß eine DOM-Struktur resultiert, und
in einem zweiten Schritt die als DOM-Struktur vorliegende Information deco­ diert und interpretiert wird, und eine Konsistenz-Prüfung erfolgt.