-
Die vorliegende Erfindung betrifft
ein System und ein Verfahren zum Verwalten und zum Austausch von
Daten, ein technisches Projekt und/oder eine technische Anlage und/oder
einzelner Anlagenkomponenten sowie insbesondere ein Automatisierungsprojekt
für eine
technische Anlage betreffend, wobei durch vorliegende Erfindung
ein effizientes und konsistentes Zusammenwirken mehrerer unterschiedlicher
Applikationen beziehungsweise Datenverarbeitungswerkzeuge gewährleistet
und erreicht wird.
-
Ein Projekt im Sinne der hier beanspruchten Erfindung
kann hierbei beispielsweise die Planung, die Entwicklung, den Aufbau,
den Test, die Prüfabnahme,
die Inbetriebnahme, den Betrieb aber auch die Wartung und Instandhaltung
sowie gegebenenfalls die Erweiterung und die Änderung einer technischen Anlage
und/oder einzelner Anlagenkomponenten umfassen, das heißt eine
technische Anlage und/oder einzelne Anlagenkomponenten in all ihren Lebenszyklusphasen.
-
Die Projektdaten eines Automatisierungsprojektes
für eine
technische Anlage umfassen hierbei insbesondere den gesamten Lebenszyklus
vorgenannter Anlage von der Planung über die Implementierung bis
zum Betrieb und während
des Betriebs der Anlage.
-
Die vorgenannten Auflistungen sind
hierbei selektiv kombinierbar und keinesfalls abschließend anzusehen.
-
Zu automatisierende Anlagen, unabhängig davon,
ob es sich beispielsweise um verfahrens- und/oder prozesstechnische
Anlagen zur Produktion chemischer Stoffe oder zur Erzeugung von
elektrischer Energie handelt, durchlaufen jeweils einen spezifischen
Lebenszyklus, der sich in aller Regel über mehrere Jahrzehnte erstreckt.
-
Am Beginn eines jeden Lebenszyklus
einer technischen Anlage und/oder einer Anlagenkomponente steht
deren Entwurf beziehungsweise deren Planung. Der Entwurf beziehungsweise
die Planung erfolgt schrittweise zunächst konzeptionell, dann im Detail,
wird dann in allen ihren Komponenten implementiert, das heißt, aufgebaut,
gegebenenfalls programmiert und getestet, und nachfolgend schließlich in
Betrieb genommen. Im weiteren Lebenszyklus, während der Betriebsphase der
jeweiligen technischen Anlage wird diese gewartet sowie in aller
Regel etliche Male bedartsabhängig
verändert,
umgebaut und/oder modernisiert.
-
In all den vorgenannten Lebenszyklusphasen
der technischen Anlage werden, die jeweilige Anlage betreffend,
vergleichsweise große
Mengen an Daten erzeugt beziehungsweise erfasst und/oder verändert. Vorgenannte
Daten können
beispielsweise Mess-, Überwachungs-,
Leistungs- und/oder Bewertungsdaten der jeweiligen Anlage aber auch
Informationen über
Instandhaltungs- und/oder Wartungsmaßnahmen sowie technische Weiterentwicklungen
oder Verbesserungen der Anlage beinhalten. Die Erfassung von Daten
erfolgt hierbei insbesondere während
des Engineering-Prozesses beziehungsweise während der Planungs- und Entwurfsphase,
zu Beginn des jeweiligen Lebenszyklus einer Anlage. Die hier erzeugten
Daten beschreiben im wesentlichen die Struktur und die Implementierung
der jeweiligen technischen Anlage. Die Modifikation beziehungsweise Änderung
des generierten beziehungsweise erfassten anlagenspezifischen Datensatzes und/oder
die Erfassung beziehungsweise Generierung neuer Daten, betreffend
geplante und/oder vorgenommene Veränderungen an der jeweiligen
technischen Anlage, erfolgen hierbei maßgeblich in der Betriebsphase
der jeweiligen Anlage.
-
Es ist üblich, die Daten einer technischen
Anlage beziehungsweise eine technische Anlage betreffende Daten
mittels verschiedener Verarbeitungswerkzeuge und Datenbanken aufzubereiten
und zu speichern. Dies ist unter anderem auch darauf zurückzuführen, dass
für die
verschiedenen Aufgaben und/oder Fragestellungen, die während eines
Lebenszyklus einer Anlage oder Anlagenkomponente zu bewältigen sind,
unterschiedliche Personen- sowie Fachkreise zuständig beziehungsweise verantwortlich
sind. Diese müssen
sich in aller Regel wiederum unterschiedlicher, speziell für die jeweilige Aufgabe
oder das jeweilige Anwendungsgebiet eingerichteter Werkzeuge beziehungsweise
Verarbeitungswerkzeuge bedienen, welche insbesondere programmtechnischer
Art sind und in aller Regel auch von unterschiedlichen Unternehmen
beziehungsweise Herstellern entwickelt werden.
-
Hierzu zählen beispielsweise:
- – Engineering-Werkzeuge,
die für
das Engineering der elektrischen Komponenten einer Anlage eingesetzt
werden,
- – Engineering-Werkzeuge,
die für
den (Metall-) Bau der Anlagenkomponenten eingesetzt werden,
- – Engineering-Werkzeuge,
die für
Leitsystem beziehungsweise das Steuerungs- und Regelungssystem der jeweiligen
technischen Anlage eingesetzt werden sowie
- – Verarbeitungswerkzeuge,
die für
die Organisation und Dokumentation der durchzuführenden Wartungs- beziehungsweise
Instandhaltungsarbeiten einer Anlage eingesetzt werden.
-
Nachteilig werden Daten über bestimmte Objekte
einer technischen Anlage dabei zumindest teilweise in mehreren Werkzeugen
parallel und auch weitestgehend unabhängig voneinander gehalten beziehungsweise
geführt
und verarbeitet, was zu Abstimmungsbedarf und zu Inkonsistenzen
bezüglich des
gesamten Datenbestandes einer Anlage führen kann.
-
Zur Vermeidung beziehungsweise Überwindung
von etwaig auftretenden Abstimmungsdifferenzen und/oder Inkonsistenzen,
den geführten
Datenbestand einer technischen Anlage betreffend, ist beim Einsatz
beziehungsweise der Verwendung mehrerer unterschiedlicher Verarbeitungswerkzeuge eine
gemeinsame Datenbank für
alle, den Lebenszyklus einer Anlage betreffenden Verarbeitungswerkzeuge
beziehungsweise Applikationen zu verwenden. Dabei kann es sich beispielsweise
um eine zentrale Datenbank oder mehrere verteilte Datenbanken mit
einem gemeinsamen Datenmodell beziehungsweise Objektmodell handeln.
-
Nachteilig führt ein solches Vorgehen jedoch dazu,
dass das Datenmodell in Abhängigkeit
der Anzahl der eingesetzten Verarbeitungswerkzeuge und der demgemäß auftretenden,
differierenden Datenformate sehr umfangreich werden kann und das
Datenmodell darüber
hinaus noch für
jedes nachträglich hinzuzufügende Werkzeug
aufwendig angepasst werden muss beziehungsweise bei Änderung
des verwendeten Datenmodells sämtliche
mit dem Datenmodell zusammenwirkenden Tools beziehungsweise Werkzeuge
auf die Notwendigkeit von Änderungen
hin geprüft
und angepasst werden müssen.
-
Alternativ hierzu lassen sich Informationen zwischen
je zwei der eingesetzten Werkzeuge über eine eigens definierte
Daten-Schnittstelle, beispielsweise eine entsprechende Datei, austauschen. Nachteilig
ist eine solche proprietäre
Daten-Schnittstelle
jedoch stets abhängig
von den jeweils beteiligten beziehungsweise eingesetzten Verarbeitungswerkzeugen,
so dass bei jeder Änderung
oder Modifikation eines dieser Werkzeuge auch die vorgenannte Daten-Schnittstelle
angepasst werden muss, was entsprechendes Expertenwissen voraussetzt
und wiederum zu einem erhöhten
Anpassungs- und Arbeitsaufwand führt.
Von weiterem Nachteil ist hierbei, dass für n Werkzeuge, wobei n die
Anzahl der eingesetzten Werkzeuge bezeichnet, n*(n-1)/2 Daten-Schnittstellen
eingerichtet, gewartet und gepflegt werden müssen, wenn jedes beteiligte
beziehungsweise eingesetzte Werkzeug die Möglichkeit haben soll, mit jedem
anderen Werkzeug Daten auszutauschen beziehungsweise zusammenzuwirken
und für jeden
Austausch ein eigenes Schnittstellen-Format zu definieren beziehungsweise
festzulegen ist.
-
Zur Reduktion der Anzahl an Daten-Schnittstellen
wird üblicherweise
ein Daten-Format selektiert beziehungsweise definiert und standardisiert, beispielsweise
als Firmen-Standard,
als nationaler Standard und/oder als internationaler Standard und somit
resultierend ein zentrales Standard-Datenformat generiert, über das
der wechselseitige Datenaustausch der eingesetzten Verarbeitungswerkzeuge
beziehungsweise Applikationen erfolgen kann. Dies hat den Vorteil,
dass für
n Werkzeuge (n = Anzahl der Werkzeuge) vermittels des zentralen
Standard-Datenformates nur noch n Schnittstellen benötigt werden,
was den Aufwand bezüglich
Schnittstellen-Erstellung und Schnittstellen-Wartung erheblich reduziert.
Jede dieser Schnittstellen konvertiert Projekt- und/oder Projektierungsdaten
oder andere die Anlage, ihre Komponenten und/oder ihr Automatisierungssystem
betreffende Daten aus dem werkzeuginternen, proprietären Format
in das standardisierte Datenformat und stellt sie über Export-Funktionen allen
anderen Werkzeugen zur Verfügung.
Des weiteren konvertiert jede dieser Schnittstellen Projekt- und/oder
Projektierungsdaten oder andere die Anlage, ihre Komponenten und/oder
ihr Automatisierungssystem betreffende Daten aus dem standardisierten
Format in das werkzeuginterne, proprietäre Format und stellt sie dem
jeweiligen Werkzeug vermittels Importmöglichkeit zur Verfügung. Dadurch können beispielsweise
verschiedene Verarbeitungswerkzeuge die für sie relevanten Daten beziehungsweise
Informationen aus einer Datei einlesen, analysieren, visualisieren,
bearbeiten, verändern
und/oder ergänzen
und wieder in die Datei zurückschreiben.
-
Beispiele für Standard-Datenformate sind
- – Initialisierungsdateien,
in die von verschiedenen Werkzeugen beziehungsweise Applikationen
und dem Betriebssystem Informationen geschrieben und/oder gelesen
werden können,
- – Registry-Dateien,
in die von verschiedenen Werkzeugen und dem Betriebssystem Informationen
geschrieben und/oder gelesen werden können,
- – kommaseparierte
ASCII-Dateien, die zu einem Quasistandard für einfachen Dateizugriff und
einem verbreiteten Datenaustauschformat für Tabellenstrukturen geworden
sind.
-
Beispiele für Standard-Datenformate aus dem
Bereich der Automatisierungstechnik sind
- – STEP (Standard
for the Exchange of Product Data), insbesondere die STEP Austauschsprache EXPRESS,
- – der
Standard IEC 61131-3, der ebenfalls ein Austauschformat für Programme
definiert, mit denen die Steuerungs- und Regelungsfunktionen eines
Automatisierungssystems beschrieben werden, insbesondere der Anhang
dieses Standards und
- – der
Standard OPC (Open Process Control), der ein Austauschformat zwischen
den Controllern und den Visualisierungsgeräten eines Automatisierungssystems
definiert.
-
Demgemäß wird in der
EP 0770943 B1 eine firmenintern
standardisierte Beschreibung der Daten eines Automatisierungsprojekts
und der zu automatisierenden Anlage beschrieben. Auch in A. Fay:
Methoden zur Unterstützung
der Migration von Prozessleitsystem-Software, Automatisierungstechnische Praxis
44, Oldenbourg-Verlag,
München,
Heft 6/2002, S. 39–44,
wird eine Beschreibung eines firmenintern standardisierten Teils
der Engineering-Daten eines Automatisierungsprojekts angegeben,
wobei insbesondere auf die Vorteile wie Reduktion des Schnittstellen-Aufwandes zu mehreren
Engineering-Werkzeugen hingewiesen wird.
-
Besonders bewährt für den Einsatz als Standard-Datenformat
haben sich Dateiformate beziehungsweise Austauschformate, bei denen
die Informationen
- – in einem menschenlesbaren
Format, z.B. aus ASCII-Zeichen zusammengesetzt, abgelegt werden,
- – in
einer bestimmten definierten Struktur, z.B. einer hierarchischen
Struktur und/oder einer Baumstruktur, abgelegt werden und
- – die
Informationen zusammen mit die Informationen beschreibenden Bezeichnern
abgelegt werden.
-
Bei Verwendung entsprechender Daten- oder
Dateiformate können
die jeweiligen Daten oder Dateien von Menschen mit vergleichsweise
geringem Aufwand leicht gelesen und Informationen entsprechend einfach
aufgefunden und interpretiert werden. Darüber hinaus sind auf vergleichsweise
einfache Art und Weise individuelle Applikationen beziehungsweise
Verarbeitungswerkzeuge erstellbar, mit welchen vorgenannte Dateien
bearbeitet, das heißt gelesen
und geschrieben werden können.
-
Die Extensible Markup Language (XML)
ist eine hinlänglich
bekannte Meta-Sprache zur Definition und Beschreibung von Sprachen,
Daten-Formaten und/oder -Strukturen, insbesondere auch zur Definition
und Beschreibung eines Daten-Austauschformates. Mit XML-Schemata
sind Regeln festlegbar, wie ein XML-Dokument in seiner logischen
Struktur, beispielsweise betreffend Elemente und Hierarchie, aufgebaut
sein soll. Mit Hilfe von XML-Schematas kann beispielsweise überprüft werden,
ob eine XML-Datei entsprechend solcher, im XML-Schema festgelegter
Regeln aufgebaut ist (sog. „Wohlgeformtheit"). Dadurch lassen
sich mit vergleichsweise geringem Aufwand individuelle Verarbeitungswerkzeuge
beziehungsweise Applikationen erstellen, welche XML-Dateien lesen,
auf Wohlgeformtheit überprüfen, in
ein anderes, ggf. proprietäres
Datenformat beziehungsweise Objektmodell umwandeln und/oder ein
bestehendes Objektmodell beziehungsweise die es beschreibenden Daten
oder Informationen in eine wohlgeformte XML-Datei überführen können.
-
XML-Dateien weisen üblicherweise
alle vorgenannten Merkmale auf, die ein Standard-Datenformat haben sollte. Darüber hinaus
ist die Sprache XSLT (XML Stylesheet Language Translation) bekannt;
XSLT wurde im Zusammenhang mit XML definiert als eine Programmiersprache
für die Überführung von
XML-Dokumenten in andere standardisierte Formate.
-
Aufgrund seiner bekannten Vorteile
und Möglichkeiten
wird XML in sehr vielen Bereichen verwendet beziehungsweise zur
Verwendung empfohlen, in denen die Notwendigkeit besteht, Daten
zwischen verschiedenen Verarbeitungswerkzeugen in einem standardisierten
Format auszutauschen. Die Möglichkeit
der vorteilhaften Nutzung von XML für derartige Aufgaben in beliebigen
Anwendungsgebieten ist allgemein bekannt und war auch das erklärte Ziel
der Entwicklung von XML.
-
Daher ist auch die Anwendung beziehungsweise
Verwendung von XML für
den Bereich der Automatisierung technischer Anlagen und insbesondere
für den
Datenaustausch zwischen verschiedenen Engineering-Werkzeugen durchaus
bekannt und gebräuchlich.
-
In der
DE 101 38 533 A1 wird XML
als Meta-Sprache zur Definition eines Austauschformats für Projekt-
und/oder Projektierungsdaten eines Automatisierungsprojekts genannt
und angewendet, indem für
jedes Verarbeitungswerkzeug, das intern ein proprietäres Datenformat
verwendet und mit dem standardisierten Datenmodell zusammenwirkt,
ein eigenes Konvertierungs-Modul erstellt wird, welches die Konvertierung
vom proprietären
in das standardisierte Datenformat oder umgekehrt durchführt. Vorgenanntes
Konvertierungs-Modul ist hierbei entweder als eigenständiges Werkzeug
ausführbar,
welches an das jeweilig zugehörige
Verarbeitungswerkzeug, beispielsweise ein Engineering-Werkzeug angebunden
ist, oder ist in das jeweilige Verarbeitungswerkzeug, beispielsweise
ein Engineering-, Service- oder Validierungswerkzeug, einbind- beziehungsweise
integrierbar, gegebenenfalls kombiniert mit einer Import- und/oder
Export-Funktionalität.
-
Bei der Abwicklung des Datenaustauschs von
Projektinformationen über
ein standardisiertes Datenformat besteht jedoch ein grundsätzliches
Problem darin, dass es, auch bei der Nutzung von XML, zur Definition
von Daten-Austauschformaten erforderlich ist, nicht nur eine einheitliche
Syntax und Struktur des standardisierten Datenformats festzulegen,
die dann im Falle von XML beispielsweise mit einem XML-Schema beschrieben
werden kann, sondern vielmehr auch eine einheitliche Semantik zu
bestimmen. Das bedeutet, dass die einzelnen Datenbausteine von den
beteiligten Personen beziehungsweise von den von vorgenannten Personen
erstellten und/oder eingesetzten Verarbeitungswerkzeugen in gleicher
Weise verstanden beziehungsweise interpretiert werden müssen. Beispielsweise
kann von einem ersten Projektierungs-Werkzeug das Attribut „Setpoint", das hierarchisch
im Datenformat dem Objekt „Regler
TI 206" zugeordnet
ist, mit dem Wert „0,8" belegt werden. Ein
anderes, beispielsweise von einem anderen Hersteller oder einem
anderen Entwickler stammendes zweites Verarbeitungswerkzeug hingegen
kann diesen Wert nur korrekt interpretieren und umsetzen, wenn ihm
bekannt ist, dass Sollwerte von Reglern in dem ersten Projektierungs-Werkzeug mit „Setpoint" bezeichnet werden.
-
Dieses Problem der Notwendigkeit
einer Einigung auf eine gemeinsame Semantik ist, wie beispielsweise
der
DE 101 38 533
A1 entnehmbar, innerhalb der Engineering-Werkzeuge eines einzelnen Herstellers
organisatorisch noch mit vergleichsweise vertretbarem Aufwand handhabbar.
Unabhängig
von der Verwendung von XML oder einer anderen Beschreibungssprache,
ist jedoch ein bedeutend höherer
Aufwand erforderlich, wenn ein standardisiertes Datenformat festgelegt
werden soll, welches auch Verarbeitungswerkzeuge beziehungsweise
Applikationen verschiedener Hersteller und/oder Entwickler unterstützen soll
und welches die Möglichkeit
bieten soll, beispielsweise zur Erweiterung der Funktionalität des Gesamtkonzepts,
auch nachträglich
noch weitere Verarbeitungswerkzeuge mit neuen Funktionalitäten zu integrieren
beziehungsweise zu applizieren, wobei die weiteren Verarbeitungswerkzeuge
insbesondere weitere Daten und/oder Datenformate generieren, lesen,
verarbeiten und/oder verändern
können.
-
In bekannter Weise ist auch die Programmiersprache
XSLT verwendbar, um XML-Dateien
in Dateien mit anderen standardisierten oder proprietären Formaten
umzuwandeln, wobei nachteilig bei Änderungen des proprietären Datenformats
Eingriffe in den Programmcode der angegebenen beziehungsweise eingesetzten
Konvertierungs-Module erforderlich sind.
-
Vorgenannte Änderungen des proprietären Datenformates
können
beispielsweise durch Veränderungen
der Funktionalität
des jeweiligen Verarbeitungswerkzeugs, durch einen Wechsel der Implementierung
des jeweiligen Verarbeitungswerkzeugs in das Gesamtkonzept und/oder
bei Änderungen
des standardisierten Datenformats erforderlich werden. Vorgenannte Änderungen
können
beispielsweise durch die Einbindung eines weiteren Verarbeitungswerkzeugs
an das standardisierte Datenformat bewirkt werden. Durch die immer
kürzeren
Innovationszyklen, die damit einhergehenden kürzeren Zykluszeiten und häufigen Wechsel
der eingesetzten Werkzeuggenerationen beziehungsweise -versionen
sowie durch die steigenden Anforderungen hinsichtlich der Integration
von weiteren Werkzeugen oder Applikationen, gewinnt vorgenannte
Problemstellung immer mehr an Bedeutung.
-
Eingriffe in bestehende Applikationen und/oder
Verarbeitungswerkzeuge sind insbesondere unter dem Gesichtspunkt,
dass – wie
bereits ausgeführt-die
eine technische Anlage und ihr Automatisierungssystem beschreibenden
Informationen beziehungsweise Daten über den gesamten Lebenszyklus
der Anlage, der sich üblicherweise über mehrere Jahrzehnte
erstrecken kann, konsistent gehalten und gepflegt werden sollen
beziehungsweise müssen, problembehaftet,
da dies Eingriffe und Modifikationen von jahrzehntehalten Applikationen
und Verarbeitungswerkzeugen, insbesondere von deren Programmcodes,
erforderlich machen würde.
Hierfür
ist in aller Regel jedoch keine Expertise mehr vorhanden beziehungsweise
verfügbar.
-
Um die erforderliche Flexibilität auch über Jahrzehnte
gewährleisten
zu können,
empfiehlt sich, wie aus der
EP 01150193 A1 bekannt, beispielsweise der
Einsatz konfigurierbarer Konvertierungs-Werkzeuge, insbesondere
für den
Einsatz bei der Konvertierung beziehungsweise dem Austausch von
Projekt- beziehungsweise Projektierungsdaten eines Automatisierungsprojekts.
Dort wird ein Konvertierungs-Werkzeug
benutzt, welches von Detailinformationen der jeweiligen Anwendungsdomäne beziehungsweise
des jeweils relevanten Anwendungsgebietes, wie beispielsweise der
Verfahrenstechnik, der Leittechnikentwicklung, dem Betrieb oder
dem Service-Bereich, unabhängig
ist. Die Daten-Konvertierung erfolgt hierbei vergleichsweise umständlich und aufwendig
vermittels graphischer Regeln, bei welchen der Ersteller und/oder
Nutzer graphisch den Bedingungs- und den Aktionsteil einer Konvertierungsregel
zu konfigurieren hat.
-
Der Erfindung liegt die Aufgabe zugrunde, ein
Verfahren und ein System der eingangs genannten Art anzugeben, welche
auch bei Verwendung unterschiedlicher Verarbeitungswerkzeuge eine
möglichst
einfache und effiziente Verwaltung von Daten sowie einen möglichst
einfachen und effizienten Austausch von Daten ermöglichen
und gewährleisten sollen.
-
Diese Aufgabe wird durch ein System
und ein Verfahren zur Verwaltung und zum Austausch, insbesondere
auch zur Generierung, zur Modifikation und zur Speicherung von Daten
eines technischen Projektes, einer technischen Anlage und/oder einzelner
Anlagenkomponenten, insbesondere jedoch eines Automatisierungsprojektes
für eine
technische Anlage, mit den Merkmalen der unabhängigen Ansprüche gelöst. Vorteilhafte
Ausgestaltungen des erfindungsgemäßen Systems sowie des entsprechenden
Verfahrens sind in den abhängigen
Ansprüchen und
der nachfolgenden Beschreibung angegeben.
-
Die vorliegende Erfindung beinhaltet
eine Datenverarbeitungsanlage mit Konvertierungseinrichtung zum
Konvertieren von Daten aus einem proprietären Datenformat in ein standardisiertes
Datenformat und umgekehrt, wobei die Konvertierung von Detailinformationen
der jeweiligen Anwendungsdomäne
unabhängig
ist. Im Gegensatz zu dem in
EP 01150193 A1 beschriebenen Verfahren werden
die Konvertierungs-Informationen der verschiedenen Anwendungsdomänen hier
nicht als grafische Regeln abgelegt sondern in Form von Zuordnungen
zwischen Datenobjekten angegeben, wobei die Zuordnungen vom Typ
1:1, 1:n, m:1 oder m:n sein können, mit
m und n als beliebige natürliche
ganze Zahlen größer 1.
-
Das erfindungsgemäße System zur Verwaltung und
zum Austausch von Daten, insbesondere auch zur Generierung, zur
Modifikation und zur Speicherung von Daten eines technischen Projektes,
einer technischen Anlage und/oder einzelner Anlagenkomponenten,
insbesondere eines Automatisierungsprojektes für eine technische Anlage, weist
wenigstens eine Datenverarbeitungsanlage mit Konvertierungseinrichtung
zum Konvertieren von Projekt- und/oder Projektierungsdaten und/oder
Betriebsdaten der jeweiligen technischen Anlage und/oder des zugehörigen Automatisierungssystems
aus einem proprietären
Format in ein standardisiertes Format und umgekehrt auf. Die Konvertierungseinrichtung umfasst
hierbei wenigstens ein Mittel zur Datenzuweisung, welches dafür eingerichtet
ist, wenigstens einer im standardisierten Datenformat, vorzugsweise XML,
angegebenen zweiten Information mindestens eine im proprietären Format
angegebene erste Information zuzuweisen und/oder umgekehrt. Darüber hinaus
weist die Konvertierungseinrichtung wenigstens ein Mittel zur Datenkonvertierung
auf, welches dafür eingerichtet
ist, für
eine beliebige, im proprietären Datenformat
angegebene erste Information aus der Menge der vorhandenen Datenzuweisungen
die entsprechende, ihr zugeordnete Datenzuweisung aufzuspüren beziehungsweise
zu finden und mittels der gefundenen Datenzuweisung die proprietäre erste Information
in die in der zugeordneten Datenzuweisung spezifizierte, standardisierte
zweite Information umzuwandeln und/oder umgekehrt für eine beliebige standardisierte
zweite Information in den in der Konvertierungseinrichtung enthaltenden
Datenzuweisungen die entsprechende Datenzuweisung aufzuspüren beziehungsweise
zu finden und darüber
die standardisierte zweite Information in die in der zugeordneten
Datenzuweisung spezifizierte proprietäre erste Information umzuwandeln.
-
Eine vorteilhafte Ausgestaltung sieht
vor, dass die Konvertierungsvorrichtung dafür eingerichtet ist, durch Verkettung
vorgenannter Vorgänge
für eine
im proprietären
Datenformat angegebene erste Information aus der Menge der vorhandenen
Datenzuweisungen die entsprechende, ihr zugeordnete Datenzuweisung
zu suchen und aufzuspüren
und mittels der gefundenen Datenzuweisung die proprietäre erste
Information in die in der Datenzuweisung spezifizierte, standardisierte
zweite Information umzuwandeln sowie für die standardisierte zweite
Information in den in der Konvertierungseinrichtung enthaltenden
Datenzuweisungen die entsprechende, ihr zugeordnete Datenzuweisung
zu suchen und aufzuspüren
und darüber
die standardisierte zweite Information in eine in der Datenzuweisung
spezifizierte, proprietäre
dritte Information umzuwandeln.
-
Vorzugsweise sind die Daten hierbei
sowohl im proprietären
als auch im standardisierten Format in einer vorbestimmten, definierten
Struktur, insbesondere einer hierarchischen Struktur und/oder einer Baumstruktur,
abgelegt.
-
Sowohl das proprietäre als auch
das standardisierte Format sind hierbei vorzugsweise menschenlesbar
und menscheninterpretierbar und/oder enthalten beschreibende Bezeichner
für die
jeweiligen Daten.
-
Die angegebene Konvertierungseinrichtung ist
konfigurierbar, insofern als dass sie in zwei eigenständige Komponenten,
nämlich
eine Komponente a) zur Zuweisung von Daten und eine generische Komponente
b) zur Konvertierung von Daten separierbar ist, wobei die generische
Komponente b) die Konvertierungs-Funktion bereitstellt und üblicherweise
als eine auf einer Datenverarbeitungsanlage ausführbare Programmkomponente in
einer gebräuchlichen Programmiersprache
und mit entsprechenden Programmcodemitteln realisierbar ist. Die
in der Komponente a), insbesondere einer Datei, angegebenen Datenzuweisungen,
die dazu dienen, die Konvertierungseinrichtung auf die jeweilige
Anwendungsdomäne
beziehungsweise das jeweilige Anwendungsgebiet und/oder das jeweilig
eingesetzte Verarbeitungswerkzeug sowie die ineinander zu konvertierenden
Datenformate abzustimmen, sind hierbei individuell anpass- und konfigurierbar.
-
In einer vorteilhaften Implementierung
werden die Datenzuweisungen in Form einer einfachen Tabelle gespeichert.
Ist eine einfache Zuordnung über
eine Tabelle nicht möglich,
dann kann die Konvertierung auch über eine hierarchisch gegliederte Mapping-Struktur
erfolgen, welche beispielsweise, wie in den Deutschen Patentanmeldungen
mit amtlichem Aktenzeichen
DE
102 54 530 .8,
DE 102
54 531 .6 und
DE 102
54 532 .4 beschrieben wird, bei Parsern für textuelle
Programmiersprachen Anwendung findet.
-
Systemgemäß hat die Konvertierungseinrichtung
durch vorgenannte Separierbeziehungsweise Konfigurierbarkeit den
Vorteil, dass Komponente a) der Konvertierungseinrichtung, die wenigstens
ein Mittel zur Datenzuweisung aufweist, und Komponente b) der Konvertierungseinrichtung,
die wenigstens ein Mittel zur Datenkonvertierung aufweist, unabhängig voneinander
entwickelt, weiterentwickelt und gepflegt werden können. So
kann die generische Komponente b) jederzeit beispielsweise an aktuell
verfügbare
beziehungsweise gebräuchliche
Programmcodemittel, Betriebssystemumgebungen, Entwicklungs-Methoden
und/oder – Techniken
angepasst werden, was bei einer Verwendung von spezifischen Projekt- und/oder Anlagendaten über mehrere
Jahrzehnte hinweg mit an Sicherheit grenzender Wahrscheinlichkeit
während
des Lebenszyklus einer technischen Anlage mehrfach erforderlich
sein wird. Die in der Komponente a) angegebenen Datenzuweisungen
der Anwendungsdomäne
bleiben davon jedoch unberührt.
Ebenso können
die Datenzuweisungen einfach geändert
werden, beispielsweise in der vorteilhaften tabellarischen Implementierung
durch Änderung
eines Eintrags oder mehrerer Einträge in der Tabelle, ohne dabei
den eigentlichen Programmcode verändern zu müssen. Vorgenannte Änderungen können hierbei
manuell und/oder automatisiert durchgeführt werden. Eine automatisierte
Durchführung
kann hierbei beispielsweise mittels eines Verarbeitungswerkzeuges
realisiert werden, welches ein manuelles graphisches Mapping unterstützt oder welches
durch regelbasiertes Parsen der proprietären Datenstrukturen automatisiert
Mappingrelationen ermittelt und in einer entsprechenden Mapping-Tabelle
einträgt.
-
Dies ist insbesondere vorteilhaft,
wenn das standardisierte Datenformat verändert und/oder erweitert werden
muss, weil beispielsweise ein weiteres Verarbeitungswerkzeug, das
zusätzliche
Daten und Objekte besitzt, einliest, verändert und/oder erstellt, über das
standardisierte Datenformat, vorzugsweise XML, in den Verarbeitungswerkzeug-Verbund eingebunden
werden soll. Nach dem Stand der Technik würde dies erfordern, dass für alle Verarbeitungswerkzeuge,
die diese zusätzlichen
Daten und Objekte ebenfalls lesend und/oder schreibend nutzen sollen
beziehungsweise wollen, die entsprechenden Konvertierungs-Komponenten
durch Eingriffe in die möglicherweise
jahrzehntealten Programmcodes angepasst beziehungsweise erweitert
werden müssten, was
in aller Regel Expertenwissen und kostspielige Programmcodemittel,
beispielsweise geeignete Compiler und/oder Debugger, voraussetzt.
Mit Hilfe des erfindungsgemäßen Systems
sowie des erfindungsgemäßen Verfahrens
hingegen lässt
sich diese Erweiterung allein durch eine einfache Ergänzung und/oder Änderung
der beispielsweise in tabellarischer Form in einer Standard-Datenformat-Datei
angegebenen Datenzuweisungen bewerkstelligen. Hierzu bedarf es weder
Expertenwissen, noch Programmierkenntnisse oder kostspieliger Programmcodemittel.
-
Auch ein Verfahren zur Verwaltung
und zum Austausch von Daten, ein technisches Projekt, eine technische
Anlage und/oder einzelne Anlagenkomponenten betreffend, insbesondere
ein Automatisierungsprojekt betreffend, mittels wenigstens einer
Datenverarbeitungsanlage mit Konvertierungseinrichtung zum Konvertieren
von Daten aus einem proprietären
Datenformat in ein standardisiertes Datenformat und umgekehrt wird
beansprucht. Die Konvertierungseinrichtung erlaubt hierbei unter
Einsatz wenigstens eines Mittels zur Datenzuweisung und wenigstens
einer Datenzuweisung, wenigstens einer im proprietären Datenformat
angegebenen ersten Information wenigstens eine im standardisierten
Format angegebene zweite Information zuzuordnen und/oder umgekehrt.
Verfahrensgemäß wird mittels einer
generischen Komponente der Konvertierungseinrichtung mit wenigstens
einem Mittel zur Konvertierung von Daten, für eine beliebige im proprietären Datenformat
angegebene erste Information aus der Menge der vorhandenen Datenzuweisungen
die entsprechende, der ersten Information zugeordnete Datenzuweisung
aufgespürt
beziehungsweise aufgefunden und mittels der gefundenen Datenzuweisung die
proprietäre
erste Information in die in der zugeordneten Datenzuweisung spezifizierte,
standardisierte zweite Information umgewandelt und/oder umgekehrt
für eine
beliebige, standardisierte zweite Information in den in der Konvertierungseinrichtung enthaltenden Datenzuweisungen
die entsprechende, der zweiten Information zugeordnete Datenzuweisung
gesucht und aufgespürt
und darüber
die standardisierte zweite Information in die in der Datenzuweisung
spezifizierte, proprietäre
erste Information umgewandelt. Durch Verkettung beider Vorgänge ist demgemäß eine erste
proprietäre
Information mittels Datenzuweisungen in eine andere proprietäre Information
umwandelbar.
-
Die verwendete generische Komponente agiert
hierbei vorzugsweise unabhängig
vom standardisierten und vom proprietären Datenformat.
-
Die Daten werden sind sowohl im proprietären als
auch im standardisierten Datenformat, vorzugsweise unter Verwendung
einer vorbestimmten, definierten Struktur, insbesondere einer hierarchischen
Struktur und/oder Baumstruktur, ablegbeziehungsweise speicherbar.
-
Sowohl das proprietäre als auch
das standardisierte Format, insbesondere XML, werden hierbei vorzugsweise
menschenlesbar und -interpretierbar und/oder mit beschreibenden
Bezeichnern für
die Daten ausgebildet.
-
Die weitere Darlegung der Erfindung
erfolgt anhand von einigen Ausführungsbeispielen.
Vorteilhafte Ausgestaltungen und Weiterbildungen der Erfindung sind
in den nachfolgenden Figurenbeschreibungen und den abhängigen Ansprüchen angegeben.
-
Es zeigen:
-
1 Beispielhaftes
System zur Verwaltung und zum Austausch von Daten zwischen zwei
unterschiedlichen Verarbeitungswerkzeugen mittels Mapping-Table.
-
2 Beispielhaftes
Verfahrensschaubild betreffend die Verwaltung und den Austausch
von Objekten zwischen Objektbibliotheken zweier unterschiedlicher
Verarbeitungswerkzeuge mittels Mapping-Table.
-
3 Beispielhaftes
Verfahrensschaubild, betreffend die Verwaltung und den zum Austausch von
Objekten und ihren Inhalten zwischen Objektbibliotheken zweier unterschiedlicher
Verarbeitungswerkzeuge bei vollständiger Mapping-Table.
-
4 Beispielhaftes
Verfahrensschaubild, betreffend die Verwaltung und den Austausch
von Objekten und ihren Inhalten zwischen Objektbibliotheken zweier
unterschiedlicher Verarbeitungswerkzeuge bei unvollständiger Mapping-Table.
-
5 Beispielhaftes
Verfahrensschaubild, betreffend die Verwaltung und den Austausch
von Informationen zwischen mehreren unterschiedlichen Verarbeitungswerkzeugen
und jeweils zugeordneter Mapping-Table.
-
6 Mappingtables
als Bestandteil einer XML-Datei
-
In 1 ist
eine beispielhafte Ausführungsform
des erfindungsgemäßen Systems
zur Verwaltung und zum Austausch von Daten eines technischen Projektes,
einer technischen Anlage und/oder einzelner Anlagenkomponenten,
insbesondere jedoch eines Automatisierungsprojektes für eine technische
Anlage, gezeigt. Vorgenanntes System weist hierbei eine Datenverarbeitungsanlage 2 mit
Konvertierungseinrichtung 4 und Mitteln zur Datenzuweisung
und Konvertierung von Daten aus wenigstens einem proprietären Format
in wenigstens ein standardisiertes Format und umgekehrt auf. Eine
Transformation zwischen zwei beliebigen Datenformaten ist hierbei
mittels semantischer Mapping-Tables 10 beziehungsweise
Mapping-Tabellen, die im folgenden allgemein auch als Mappingtables
bezeichnet werden, abbildbar. Die Datenverarbeitungsanlage 2 weist
hierbei noch eine Eingabevorrichtung 2a, eine Anzeigevorrichtung 2b sowie
einen Datenspeicher 2c auf, mit denen sie zusammenwirkt.
-
Die Mappingtables 10 müssen hierbei
nicht zwingend flach strukturiert sein, sondern können vielmehr
auch eine hierarchische Struktur aufweisen. Die Mappingtables 10 umfassen
Zuordnungen zwischen Daten und/oder Objekten der Datenformate von
einem ersten Werkzeug, Tool A, und einem zweiten Werkzeug, Tool
B, und sind als semantische Links beziehungsweise Verweise zu verstehen.
Wird beispielsweise aus einem Zeichnungswerkzeug Tool A ein Objekt "Kreis" eingelesen, so kann
dieses Objekt eine Zuordnung zum von Tool B unterstützten Objekt "DynamicCircle" erhalten. Ist, wie
in 1 gezeigt, das Dateiaustauschformat
standardisiert, beispielsweise wie bei einer XML-Datei 12,
so ist das syntaktisch korrekte Einlesen der im standardisierten Format
vorliegenden Daten wesentlich erleichtert. Ein Vorteil der Mappingtables 10 besteht
darin, dass die jeweilige Applikation, im hier gezeigten Beispiel Tool
A oder Tool B, die XML-Datei 12 nicht nur syntaktisch korrekt
einlesen kann sondern aus der jeweiligen Mappingtable 10 zugleich
die erforderlichen semantischen Informationen gewinnen beziehungsweise
extrahieren kann. Dies bedeutet, dass das Tool B die XML-Datei 12 durch
die "Brille" der Mapping-Tabelle 10 „versteht", das heißt korrekt
interpretieren und somit direkt mit der XML-Datei 12 arbeiten
kann. Daraus folgt, dass Änderungen
wiederum in die XML-Datei 12 zurückgeschrieben werden können, wodurch
Tool A von Änderungen
der Datei die durch Tool B bewirkt wurden Kenntnis erlangen kann.
-
Die Erstellung und/oder Änderung
der Mappingtables 10 kann vor oder während des Verfahrens, je nach
Anwendungsgebiet manuell durch den Anwender der verschiedenen Applikationen
erfolgen oder aber die entsprechenden Mappingtables 10 können mit
den jeweils eingesetzten Applikationen beziehungsweise Verarbeitungswerkzeugen
mitgeliefert werden. In speziellen Fällen kann die Erstellung der
Mappintable 10 auch automatisch erfolgen.
-
Voraussetzung für die Anwendung von Mappingtables 10 ist
das Vorliegen einer eineindeutigen Zuordnung zwischen wenigstens
einigen der vorhandenen Daten beziehungsweise Informationen, wobei der
Begriff Daten oder Informationen die zugehörigen Objekte, ihre Attribute
sowie ihre Relationen einschließt.
-
Im Folgenden wird die verfahrensgemäße Verwendung
von Mappingtables 10 beispielhaft anhand einiger Ausführungsbeispiele
dargelegt.
-
In 2 ist
eine Ausgangssituation gezeigt, in welcher ein Werkzeug beziehungsweise
eine Applikation, Tool A, zur Erstellung von Projektdaten eine tooleigene „Objektbibliothek
A" (Datenbibliothek) 20 verwendet.
Die in der „Objektbibliothek
A" 20 enthaltenen
Objekte (Daten beziehungsweise Informationen) werden bei der Projektbearbeitung
instanziiert beziehungsweise kopiert und mit konkreten Werten versehen.
In einem weiteren Werkzeug, Tool B, wird ebenso verfahren, wobei
die „Objektbibliothek
B" 22 eine
von der „Objektbibliothek
A" 20 differierende Struktur
besitzen kann. Die beiden vorgenannten unterschiedlichen Verarbeitungswerkzeuge
können, falls
sie programmtechnisch umgesetzt wurden, hierbei auf der Datenverarbeitungsanlage 2 (vgl. 1) mit Konvertierungseinrichtung 4 (vgl. 1) oder aber auf anderen
Datenverarbeitungseinrichtungen ausgeführt werden, wenn diese mit
der Datenverarbeitungsanlage 2 mit Konvertierungseinrichtung 4 über entsprechende
Netzverbindungen, wie beispielsweise LAN-, WAN-, insbesondere Internetverbindungen
und/oder Funkverbindungen zusammenwirken.
-
Eine Datenübergabe von einem ersten Verarbeitungswerkzeug,
Tool A, an ein zweites Verarbeitungswerkzeug, Tool B, wird bewirkt,
indem Relationen zwischen den Elementen der Bibliotheken „Objektbibliothek
A" 20 und „Objektbibliothek
B" 22,
der beiden Werkzeuge, betreffend beispielsweise Objekte, Attribute
und/oder Informationen, in einer separaten Relationen-Tabelle beziehungsweise
Mapping-Table 10 erstellt und abgelegt werden. Wird nun, wie
in 2 gezeigt, eine XML-Datei
12 vom zweiten Verarbeitungswerkzeug, Tool B, eingelesen und ein Objekt „Pump" 26 aus
der „Objektbibliothek
A" 20 aufgefunden,
so kann Tool B dieses Objekt „Pump" 26 mit
Hilfe der angegebenen Mapping-Table 10 dem eigenen Objekt „P37" 28 zuordnen.
-
Ist eine eindeutige Zuordnung aller
sowohl im ersten Werkzeug, Tool A, als auch im zweiten Werkzeug,
Tool B, verwendeten Daten, also der Schnittmenge beider Objektbibliotheken 20, 22,
einschließlich
von leeren Relationen, möglich,
so ist eine vollständige
Mapping-Table 10 bildbar. Mit Hilfe vorgenannter Mapping-Table
beziehungsweise Mapping-Tabelle 10 ist nunmehr der Austausch
beliebiger Dateien und/oder Daten beziehungsweise Informationen
zwischen den beiden Werkzeugen, Tool A und Tool B, möglich.
-
Liest nun, wie in 3 gezeigt, ein zweites Werkzeug, Tool
B, die beispielsweise relevante Anlagen- und/oder Projektinformationen
enthaltende XML-Datei 12 ein, so kann es jeder in die XML-Datei 12 konvertierten
und gefundenen ersten Information der „Objektbibliothek A" 20 eine
zweite Information der eigenen „Objektbibliothek B" 22 zuordnen.
Bei vorgenannten Informationen kann es sich beispielsweise um Meß- oder
Regeldaten, Bewertungsergebnisse, insbesondere von einem anderen
Werkzeug, Leistungsdaten, oder Instandhaltungsdaten handeln. Eine
Datei mit „Projektdaten
A" 30 wird
für das
Tool B somit in Form einer weiteren Datei mit „Projektdaten B" 32 direkt
lesbar. Da die Zuordnung 34 zwischen den Daten eineindeutig
ist, kann Tool B Änderungen aus
den „Projektdaten
B" 32 direkt
in die XML-Datei 12 zurückschreiben
und somit dem Tool A zur Verfügung
stellen.
-
Wird hingegen die Mapping-Table 10 lediglich
mit Zuordnungen zwischen verwendeten Daten eines konkreten Projektdatensatzes
erstellt, so wird in der Regel nur ein unvollständiger Mappingtable 10 entstehen.
In diesem Falle kann der Datenaustausch spezifisch nur für die Datei
dieses Projektes erfolgen beziehungsweise der Datenaustausch zwischen
Projekten, deren Daten vollständig
durch den Mappingtable 10 beschrieben sind.
-
Ein Vorteil der Erfindung besteht
darin; dass es unschädlich
ist, wenn ein zweites Werkzeug, Tool B, nicht alle von einem ersten
Werkzeug, Tool A, zur Verfügung
gestellten Daten verarbeiten kann. In diesem Fall ergibt sich, wie
in 4 gezeigt, eine leere Relation 40 zwischen
diesen Daten. Gemäß 4 erhält die erste Information „Documents" 42 aus
der „Objektbibliothek
A" 20 in
der Mapping-Table 10 keine Relation zu einer zweiten Information 44 von
Tool B. Tool B erhält
somit nur Kenntnis von denjenigen Daten, die durch eine Relation
bekannt sind. Da beide Tools jedoch mit derselben XML-Datei 12 arbeiten,
gehen hierbei vorteilhaft keine Daten verloren, ein Datenverlust
wird vermieden. Im Ergebnis verarbeitet Tool B nur eine Teilmenge
der Daten der XML-Datei 12, der übrige Teil der XML-Datei 12 beziehungsweise
dessen Daten bleiben davon unberührt.
Die leeren Relationen 40 belegen hierbei lediglich die
Vollständigkeit
der Relationen und sind für
die weiteren Betrachtungen vernachlässigbar. Es kann in einigen
Fällen
sogar vorteilhaft sein, beim Einlesen von Informationen aus den „Projektdaten
A" 30 beziehungsweise
der „Objektbibliothek
A" 20 die „Objektbibliothek
B" 22 automatisch
zu ergänzen
und somit die Zahl der leeren Relationen 40 zu verringern. Auf
diese Weise kann Tool B von Tool A „lernen".
-
Zusammenfassend ist es mit vorgenannter Methode
möglich,
dass beide Tools mit derselben XML-Datei 12 arbeiten. Aus
dem Stand der Technik bekannte Importfilterfunktionen müssen nicht
mehr Bestandteil der einlesenden Applikation beziehungsweise des
einlesenden Werkzeuges sein sondern werden vollständig durch
eine separate Informationszuordnung in Form von Mappingtables 10 abgebildet, die
austauschbar, erweiterbar und pflegbar ist, ohne dass Programmierkenntnisse
und/oder Expertenwissen bezüglich
der jeweilig eingesetzten Applikationen beziehungsweise Werkzeuge
vorausgesetzt werden beziehungsweise erforderlich sind.
-
Darüber hinaus ist das Konzept
der Mappingtables 10 vorteilhaft zur Unterstützung des
iterativen Engineering für
mehrere oder alle Phasen des Engineering einsetzbar, um auf diese
Weise einen durchgehenden beziehungsweise kontinuierlichen Informationsfluß zu gewährleisten.
Durch Rückverfolgung
von Relationen über
mehrere Mappingtables 10 hinweg, entsprechend einer Art
Zuordnungspfad, kann zu jeder Zeit jede beliebige Information rückverfolgt
und abgerufen werden. Im Unterschied zu bekannten Verfahren wird
der Engineeringprozeß demgemäß vorteilhaft
nicht tool- beziehungsweise werkzeugorientiert sondern datenorientiert
gestaltet. Dies bedeutet, dass die Engineeringphasen durch separate
Tools beziehungsweise Werkzeuge bearbeitet werden, die jedoch durch
eine standardisierte Datenschnittstelle in die Lage versetzt sind,
die resultierenden Dokumente anderer Engineeringphasen einzulesen,
zu visualisieren, zu bearbeiten, zu verarbeiten und um ihre eigenen
Ergebnisse und/oder Informationen zu erweitern. Indem das ursprüngliche
Tool diese erweiterten Informationen erneut einlesen und weiterbearbeiten
kann, ohne dass eine Neuzuordnung erforderlich wird, da eine entsprechende
Neuzuordnung bereits über
die Mapping-Table 10 abgedeckt wird, lässt sich hierdurch vorteilhaft
das iterative Engineering unterstützen sowie dessen Effizienz steigern.
-
Die XML-Datei 12 muß dabei
nicht, wie bei gattungsgemäßen Datenbanken üblich, eine
zu Beginn festgelegte, vorbestimmte und wohldefinierte Struktur
besitzen, die allen derzeitigen und künftigen Ansprüchen der
verwendeten Tools beziehungsweise Werkzeuge im Sinne eines wohldefinierten
Metamodells oder einer Meta-Datenbank gerecht wird. Die Mechanismen
des XML-Dateiformates erlauben eine Erweiterung des Datenformates
zu einem beliebigen Zeitpunkt im Lebenszyklus einer Anlage, ohne die
Lesbarkeit der XML-Datei 12 für die übrigen Tools beziehungsweise
Werkzeuge zu beeinflussen und/oder zu verändern.
-
Der Vorteil gegenüber bekannten Verfahren besteht
dabei darin, dass die Tools zwar nur ihren eigenen Problemraum bearbeiten
können,
aber durch ein generisches Datenformat wie beispielsweise XML von
den syntaktischen Beschränkungen
eines proprietären
Daten- beziehungsweise Dateiformates befreit sind.
-
Unter Verwendung von Mappingtables 10 erfolgt
eine Verknüpfung
beziehungsweise Zuordnung derjenigen Daten, welche im begrenzten
Problemraum jedes der Tools liegen, zu denjenigen Daten, die bereits
in der XML-Datei 12 enthalten sind. Somit sieht jedes Tool
beziehungsweise Werkzeug oder aber auch jede Applikation die XML-Datei
12 durch seine
eigene "Brille" beziehungsweise
einen eigenen „Filter" und erhält somit
seine eigene Sicht auf die Daten (Sichtenmodell). Ergebnisse der
Tools werden schrittweise in der XML-Datei 12 abgelegt
und können
durch weitere Mappingtables 10 in nachfolgenden Tools beziehungsweise
Applikationen weiterverarbeitet werden. Auf diese Weise wächst die XML-basierte
Anlagenprojektdatei an und stellt sich mit Hilfe unterschiedlicher
Mappingtables 10 jedem Tool individuell, das heißt auf seine
Weise dar.
-
Die Mappingtables 10 agieren
dabei als eine Art Informationsfilter, das die beispielsweise XML-Projektdatei
maskiert. Die entstehende Gesamt-XML-Datei beziehungsweise die Menge
der entstehenden XML-Dateien 12 bildet dabei stets ein konsistentes
Datenobjekt für
alle anfallenden Informationen.
-
Vorteilhaft müssen die Tools im Verlaufe
der Zeit nicht wiederholt den sich ändernden Daten angepasst werden,
sondern die Interpretation der Daten durch Mappingtables 10 erfolgt
automatisiert. Mappingtables 10 stehen dabei außerhalb
der Tools als variables Konfigurierungsmittel zur Verfügung, das mit
vergleichsweise geringem Aufwand und begrenztem Spezial- beziehungsweise
Expertenwissen erstellt werden kann.
-
Da alle Informationen in einer einzigen XML-Datei 12 oder
einer Kollektion von XML-Dateien zusammengetragen
werden, ist die Datenhaltung prinzipbedingt konsistent. Zusammenfassend
ist es verfahrensgemäß möglich, dass
alle eingesetzten Werkzeuge beziehungsweise Applikationen mit derselben
XML-Datei 12 beziehungsweise mit demselben Set von XML-Dateien
arbeiten. Bekannte Importfilterfunktionen sind nicht mehr Bestandteil
der einlesenden Applikation bzw- des einlesenden Werkzeugs, sondern
werden vollständig
durch wenigstens eine separate Mappingtable 10 abgebildet,
die austauschbar, erweiterbar, durch ein geeignetes generisches
Datenformat wie XML lesbar und damit auch pflegbar ist.
-
Vorgenannter Aspekt der Erfindung
wird in 5 exemplarisch
anhand einer Auswahl von am Engineering beteiligten Werkzeugen,
Tool 1 bis Tool 4, dargelegt.
-
Zu Beginn des Engineering-Prozesses
liegt vereinfacht zunächst
eine leere XML-Datei 12 vor. Ein Verfahrenstechniker ermittelt
aus seinen Vorgaben ein R-I-Fließbild (Fließbild von Rohrleitungen und
Installationen) und erstellt dies in Tool 1 unter Verwendung einer
Objektbibliothek. Jedes der Elemente des Fließbildes, insbesondere Tanks,
Pumpen, Ventile, Rohrleitungen etc. sind Objekte der Zeichnung und
besitzen individuelle Eigenschaften mit ihren zugehörigen Werten,
wie beispielsweise Volumen, Durchmesser etc.. Diese Informationen
werden mittels einer vorbestimmten Zuordnungs- oder Abbildungstabelle,
Mapping-Table 1, in der XML – Datei 12 abgespeichert.
-
Ein Leittechnikentwickler benötigt aus
den R-I-Fließbildern
eine Reihe von Informationen, wie beispielsweise Meßstellen,
Regelkreise, Sensoren und Aktoren betreffend. Über Mapping-Table 2 wird die
Zuordnung zwischen den Objekten des R-I-Fließbildes zu den für den Leittechniker
interessanten Objekten, beispielsweise Sensoren, Aktoren, Regelkreise
etc., realisiert. Ein zweites Werkzeug, Tool 2, bekommt folglich
einen begrenzten Ausschnitt der für ihn interessanten Informationen
aus der XML-Datei 12 geliefert. Hieraus entwickelt der
Leittechniker beispielsweise die Steuerungssoftware, wählt passende Geräte aus einer
Gerätebibliothek
aus, konfiguriert die Kommunikationssysteme und/oder entwickelt Operatorgrafiken.
Die entstehenden Daten werden wiederum in die XML-Datei 12 zurückgeschrieben.
-
Ein drittes Werkzeug, Tool 3, sei
die Bediensoftware, die sich während
des Betriebs einem Operator beziehungsweise Anwender zeigt. Der Operator
kann von hier aus seine Anlage fahren, Unregelmäßigkeiten feststellen, Prozesse
starten und beenden oder verschiedene Maßnahmen zur Wartung oder Havarievermeidung
einleiten. Der Operator kann von dieser Software aus auf alle Informationen zugreifen,
die im Entwicklungszyklus der Anlage entstanden sind. Die Auswahl,
welche Informationen dies sind, wird durch die Mapping-Table 3 getroffen. Mappingtables
erlauben somit das Einschränken
der abrufbaren Informationen.
-
Ein viertes Werkzeug, Tool 4, sei
ein Service-Tool, das einem Wartungstechniker einer Anlage zur Verfügung steht.
Von hier aus kann er die für
ihn relevanten Informationen über
Geräte
und Funktion seiner Anlage abrufen. Die Auswahl der ihm zur Verfügung stehenden
Informationen kann über
Mapping-Table 4 festgelegt werden.
-
Ein weiterer Vorteil der Erfindung
besteht darin, dass es mit Hilfe des Mechanismusses der Mappingtables
möglich
ist, separate XML-Dateien 12, im hier gezeigten Beispiel
XML 1, XML 2, XML 3 und XML 4 oder allgemein einen Auszug von Daten
aus der Anlagen-XML-Datei 50 zu extrahieren, die nur die jeweils
relevanten Informationen auszugsweise enthalten. Dabei können beispielsweise
dieselben Mappingtables, im hier gezeigten Beispiel Mapping-Table 1,
Mapping-Table 2, Mapping-Table 3 und Mapping-Table 4 zur
Anwendung kommen, die die jeweiligen Tools, im hier gezeigten Beispiel
Tool 1, Tool 2, Tool 3 und Tool 4, verwenden.
-
Eine in 6 gezeigte vorteilhafte Ausführungsform
der Erfindung sieht vor die Mappingtables 10 als Bestandteil
in die XML-Datei 12 aufzunehmen.
-
Ein Vorteil dieser Ausgestaltung
der Erfindung besteht darin, dass die Zahl der Dateien verringert
wird, was die Weitergabe vereinfacht. Ein weiterer Vorteil dieses
Aspekts der Erfindung besteht darin, dass mit den Mappingtables 10 auch
die Angabe darüber
in die XML-Datei 12 aufgenommen wird, welches Tool beispielsweise
auf welche Information der XML-Datei 12 zugreift. Dies
kann zum Beispiel dann genutzt werden, wenn sich der Name einer
Information in der XML-Datei 12 ändert – die entsprechenden Tools,
die diese Information nutzen, lassen sich schnell auffinden und
deren Datenzuordnungen lassen sich einfach automatisch ändern. Die
Tools selbst müssen
hierfür
nicht geändert
werden. Ändert sich
hingegen der Name eines Objektes in einer proprietären Datenbank
eines bestimmten Tools, so muß nur
die Menge der diesem Tool zugeordneten Mappingtables 10 gefunden
und die Zuordnungen zu dem betreffenden Objekt geändert werden.
-
Eine weitere vorteilhafte Ausgestaltung
der Erfindung besteht darin, den einzelnen Einträgen der Mappingtables 10 Zusatzinformationen
beizufügen, die
für eine
Koordination und sinnvolle Verbreitung der Daten dienen. Ändert beispielsweise
ein Tool den Wert eines Attributs in der XML-Datei 12,
so wird die Konvertierungseinrichtung 4 (vgl. 1) sogleich alle Mappingtables 10 nach
Verweisen auf eben dieses Attribut in der XML-Datei 12 durchsuchen
und sie mit einer Markierung versehen, die anzeigt, dass sich dieses
Attribut geändert
hat. Die anderen Tools erhalten somit beim Zugriff auf die XML-Datei 12 sogleich die
Information, welche Daten sich seit ihrem letzen Zugriff außerhalb
des Programms geändert
haben.
-
Vorgenannte Markierung kann beispielsweise
durch Flags (elektronische Merker) erfolgen, die diese Änderung
anzeigen.
-
Hat das entsprechende Tool beziehungsweise
die jeweilige Applikation die geänderten
Daten eingelesen, kann es ein entsprechendes Zeichen in der XML-Datei 12 hinterlassen,
beispielsweise durch Zurücksetzen
der vorgenannten Markierung, mit dem es signalisiert, dass seine
Daten auf dem aktuellen Stand sind. Durch diese Art der Ausgestaltung
lässt sich
vergleichsweise leicht der aktuelle Gesamtzustand der Anlage ermitteln.
Umgekehrt ist aus der Datei auch ersichtlich, welche Tools und Anlagenteile noch
nicht auf den aktuellen Stand der XML-Datei 12 respektive
des jeweiligen Projektes gebracht sind, da über die Mappingtables 10 eine
eindeutige Zuordnung möglich
ist.
-
Darüber hinaus ist es vorteilhaft
möglich,
einen Hinweis auf die Quelle der Änderung und/oder weitere Informationen
die Änderung
betreffend, wie insbesondere das Datum der Änderung, einzubringen. So können beispielsweise
alle im gesamten Lebenszyklus der Anlage erzeugten Daten und Informationen,
einschließlich
all ihrer Änderungen
und Versionen sowie einschließlich
aller Änderungen
in den Mappingtables 10 mit jeweils einem Zeitstempel beziehungsweise
einer Markierung und/oder einem anderen Hinweis versehen werden.
Die XML-Datei 12 repräsentiert
dann nicht mehr nur den aktuellen Zustand sondern auch die gesamte
Historie, das heißt
den zeitlichen Verlauf beziehungsweise die zeitliche Entwicklung
des jeweiligen Projektes über seinen
gesamten Lebenszyklus oder auch nur über einen Teil seines Lebenszyklus.
Die XML-Datei 12 bildet
hierbei eine Art Log-Buch der Anlage.
-
Eine weitere vorteilhafte Ausführungsform der
Erfindung ermöglicht,
dass die Informationen der Mappingtables 10 separat in
einem eigenen Format, vorzugsweise einem leicht lesbaren Format
wie beispielsweise XML gespeichert werden: Dies kann insbesondere
in einzelnen Dateien, einem Dateiverbund, einer Datenbank oder einer
Kollektion von Dateien erfolgen. Vorteilhaft kann der Dateiaustausch dateibasiert
oder durch Datenströme
erfolgen, beispielsweise vermittels eines Netzwerks mit Hilfe eines
Datenaustauschprotokolls direkt zwischen verschiedenen Applikationen.