WO2004077305A1 - System und verfahren zum verwalten und zum austausch von daten eines technischen projektes, einer technischen anlage sowie einzelner anlagenkomponenten - Google Patents

System und verfahren zum verwalten und zum austausch von daten eines technischen projektes, einer technischen anlage sowie einzelner anlagenkomponenten Download PDF

Info

Publication number
WO2004077305A1
WO2004077305A1 PCT/EP2004/001884 EP2004001884W WO2004077305A1 WO 2004077305 A1 WO2004077305 A1 WO 2004077305A1 EP 2004001884 W EP2004001884 W EP 2004001884W WO 2004077305 A1 WO2004077305 A1 WO 2004077305A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
information
format
proprietary
standardized
Prior art date
Application number
PCT/EP2004/001884
Other languages
English (en)
French (fr)
Inventor
Peter Drath
Peter Bort
Alexander Fay
Original Assignee
Abb Research Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Abb Research Ltd. filed Critical Abb Research Ltd.
Priority to EP04714740A priority Critical patent/EP1597675A1/de
Priority to US10/546,732 priority patent/US8290990B2/en
Publication of WO2004077305A1 publication Critical patent/WO2004077305A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
    • G06F16/84—Mapping; Conversion

Definitions

  • the project data of an automation project for a technical system include in particular the entire life cycle of the aforementioned system from planning through implementation to operation and during the operation of the system.
  • each of these interfaces converts project and / or project planning data or others the system, its components and / or it Automation system-related data from the standardized format into the tool-internal, proprietary format and makes it available to the respective tool by means of import options.
  • different processing tools can read in, analyze, visualize, edit, change and / or supplement the data or information relevant to them from a file and write them back into the file.
  • Registry files in which information can be written and / or read by various tools and the operating system
  • the Exlensible Markup Language is a well-known meta-language for the definition and description of languages, data formats and / or structures, in particular also for the definition and description of a data exchange format.
  • XML schemas rules can be defined as to how an XML document should be structured in its logical structure, for example with regard to elements and hierarchy. With the help of XML schemas, it can be checked, for example, whether an XML file is structured in accordance with such rules defined in the XML schema (so-called “well-formedness”).
  • XML is mentioned and used as a meta-language for defining an exchange format for project and / or project planning data of an automation project, in that for each processing tool that uses a proprietary data format internally and interacts with the standardized data model, a separate one Conversion module is created, which carries out the conversion from the proprietary to the standardized data format or vice versa.
  • the aforementioned conversion module can either be executed as an independent tool that is connected to the respective associated processing tool, for example an engineering tool, or can be integrated or integrated into the respective processing tool, for example an engineering, service or validation tool, if necessary combined with an import and / or export functionality.
  • the data assignments can be changed easily, for example in the advantageous tabular implementation by changing one or more entries in the table without having to change the actual program code.
  • the aforementioned changes can be made manually and / or automatically.
  • Automated implementation can be implemented here, for example, using a processing tool that supports manual graphic mapping or that automatically determines mapping relationships by means of rule-based parsing of the proprietary data structures and enters them in a corresponding mapping table.
  • the generic component used preferably acts independently of the standardized and the proprietary data format.
  • the data can be stored or stored both in the proprietary and in the standardized data format, preferably using a predetermined, defined structure, in particular a hierarchical structure and / or tree structure.
  • Figure 1 Exemplary system for managing and exchanging data between two different processing tools using a mapping table.
  • the mapping tables 10 do not necessarily have to be structured flat, but rather can also have a hierarchical structure.
  • the mapping tables 10 comprise assignments between data and / or objects of the data formats of a first tool, Tool A, and a second tool, Tool B, and are to be understood as semantic links or references. If, for example, a "circle" object is read from a tool A, this object can be assigned to the "DynamicCircle" object supported by tool B. If, as shown in FIG. 1, the file exchange format is standardized, for example as in the case of an XML file 12, the syntactically correct reading of the data present in the standardized format is made considerably easier.
  • mapping tables 10 One advantage of the mapping tables 10 is that the respective application, in the example Tool A or Tool B shown here, can not only read the XML file 12 in a syntactically correct manner but can also extract or extract the required semantic information from the respective mapping table 10. This means that the tool B "understands” the XML file 12 through the "glasses" of the mapping table 10, that is, it can interpret it correctly and thus can work directly with the XML file 12. It follows that changes in turn in the XML file 12 can be written back, whereby tool A can become aware of changes to the file which were caused by tool B.
  • a data transfer from a first processing tool, Tool A, to a second processing tool, Tool B, is effected by means of relationships between the elements of the libraries “Object Library A” 20 and “Object Library B” 22, the two tools, relating, for example, to objects, attributes and / or information can be created and stored in a separate relation table or mapping table 10. If, as shown in FIG. 2, an XML file 12 is now read in by the second processing tool, Tool B, and an object “Pump” 26 from the "" Object library A "20 is found, tool B can assign this object” Pump “26 to its own object” P37 "28 with the aid of the specified mapping table 10.
  • mapping table 10 is only created with assignments between used data of a specific project data record, only an incomplete mapping table 10 will generally result.
  • the data exchange can only take place specifically for the file of this project or the data exchange between projects whose data are completely described by the mapping table 10.
  • mapping tables 10 can advantageously be used to support iterative engineering for several or all phases of the engineering, in order in this way to ensure a continuous or continuous flow of information.
  • the engineering process is accordingly advantageously designed to be data-oriented rather than tool-oriented or tool-oriented.
  • the engineering phases are processed by separate tools or tools, which, however, are enabled by a standardized data interface to read, visualize, edit, process the resulting documents of other engineering phases and to process their own results and / or information to expand. Since the original tool can read this extended information again and process it further without a reassignment being necessary, since a corresponding reassignment is already covered by the mapping table 10, this can advantageously support iterative engineering and increase its efficiency.
  • FIG. 5 The aforementioned aspect of the invention is exemplified in FIG. 5 on the basis of a selection of tools involved in engineering, Tool1 to Tool 4.
  • mapping tables enables separate XML files 12, in the example shown here XML 1, XML 2, XML 3 and XML 4 or generally an extract of data from the system Extract XML file 50 that contains only the relevant information in extracts.
  • the same mapping tables in the example shown here mapping table 1, mapping table 2, mapping table 3 and mapping table 4, can be used that the respective tools, in the example shown here tool 1, tool 2, tool 3 and Tool 4.
  • the corresponding tool or the respective application can leave a corresponding character in the XML file 12, for example by resetting the aforementioned marking with which it signals that its data is up to date.
  • This type of design enables the current overall condition of the system to be determined comparatively easily.
  • the file also shows which tools and system parts have not yet been brought up to date with the XML file 12 or the respective project, since a clear assignment is possible via the mapping tables 10.

Abstract

System und Verfahren zur Verwaltung und zum Austausch von Daten ein technisches Projekt, eine technische Anlage und/oder einzelne Anlagenkomponenten betreffend, insbesondere ein Automatisierungsprojekt betreffend, welche eine Datenverarbeitungsanlage (2) mit Konvertierungseinrichtung (4) zum Konvertieren von Daten aus wenigstens einem proprietären Datenformat in ein standardisiertes Datenformat und umgekehrt aufweist. Mittels der Konvertierungseinrichtung (4) wird vermittels wenigstens einer Datenzuweisung wenigstens einer im standardisierten Datenformat angegebenen ersten Information mindestens eine im proprietären Format angegebene zweite Information zugewiesen und/oder umgekehrt. Darüber hinaus ist die Konvertierungseinrichtung (4) dafür eingerichtet, für wenigstens eine im proprietären Datenformat angegebene erste Information aus der Menge der vorhandenen Datenzuweisungen die entsprechende, ihr zugeordnete Datenzuweisung aufzuspüren und mittels der gefundenen Datenzuweisung die jeweilige proprietäre erste Information in eine in der Datenzuweisung spezifizierte, standardisierte zweite Information umzuwandeln und/oder für wenigstens eine standardisierte zweite Information in den in der Konvertierungseinrichtung (4) enthaltenden Datenzuweisungen die entsprechende Datenzuweisung aufzuspüren beziehungsweise aufzufinden und mittels der zugeordneten Datenzuweisung die standardisierte zweite Information in eine in der Datenzuweisung spezifizierte, proprietäre erste Information umzuwandeln.

Description

System und Verfahren zum Verwalten und zum Austausch von Daten eines technischen Projektes, einer technischen Anlage sowie einzelner Anlagenkomponenten
Beschreibung
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 bedarfsabhä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 erfass- ten anlagenspe∑ifischen 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 programm- technischer 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 Steuerungsund 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äß auftre- tenden, differierenden Datenformate sehr umfangreich werden kann und das Datenmodell darüber hinaus noch für jedes nachträglich hinzuzufügende Werkzeug aufwen- dig 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 Anpassungsund 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 o 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 Prozess- leitsystem-Software, Automatisierungstechnische Praxis 44, Oldenbourg-Verlag, München, Heft 6/2002, S. 39-44, wird eine Beschreibung eines firmenintern standardi- sierten 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 Exlensible 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. „Wohl- geformtheit"). 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 fest- zulegen, 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 Tl 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örinen 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 Konvertiemngs-Infor- mationen 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 Kon- vertierungseinrichtung 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 Daten∑uweisung 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 Map- ping-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 Separier- beziehungsweise 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, Betriebssystem Umgebungen, 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 Mapping- relationen 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, ableg- beziehungsweise 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:
Figur 1 Beispielhaftes System zur Verwaltung und zum Austausch von Daten zwischen zwei unterschiedlichen Verarbeitungswerkzeugen mittels Mapping-Table.
Figur 2 Beispielhaftes Verfahrensschaubild betreffend die Verwaltung und den
Austausch von Objekten zwischen Objektbibliotheken zweier unterschiedlicher Verarbeitungswerkzeuge mittels Mapping-Table.
Figur 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.
Figur 4 Beispielhaftes Verfahrensschaubild, betreffend die Verwaltung und den
Austausch von Objekten und ihren Inhalten zwischen Objektbibliotheken zweier unterschiedlicher Verarbeitungswerkzeuge bei unvollständiger Mapping-Table.
Figur 5 Beispielhaftes Verfahrensschaubild, betreffend die Verwaltung und den
Austausch von Informationen zwischen mehreren unterschiedlichen Verarbeitungswerkzeugen und jeweils zugeordneter Mapping-Table.
Figur 6 Mappingtables als Bestandteil einer XML-Datei
In Fig. 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 Fig. 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 mit- geliefert 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 Fig. 2 ist eine Ausgangssituation gezeigt, in welcher ein Werkzeug beziehungsweise eine Applikation, Tool A, zur Erstellung von Projektdaten eine tooleigene „Objektbibliothek A" (Dätenbibliothek) 20 verwendet. Die in der „Objektbibliothek A" 20 enthaltenen Objekte (Daten beziehungsweise Informationen) werden bei der Projektbearbeitung in- stanziiert 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. Fig.1 ) mit Konvertierungseinrichtung 4 (vgl. Fig.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 Fig. 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 Fig. 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 Fig. 4 gezeigt, eine leere Relation 40 zwischen diesen Daten. Gemäß Fig. 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 bezieh ungs- weise 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 Figur 5 exemplarisch anhand einer Auswahl von am Engineering beteiligten Werkzeugen, Tool1 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, insbesondereTanks, 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 Zuord- nungs- 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 passeride 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 Fig. 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 weiche 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. Fig. 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.

Claims

Patentansprüche
1. System zur Verwaltung und zum Austausch von Daten, ein technisches Projekt, eine technische Anlage oder einzelne Anlagenkomponenten betreffend, insbesondere ein Automatisierungsprojekt betreffend, welche eine Datenverarbeitungsanlage (2) mit Konvertierungseinrichtung (4) zum Konvertieren von Daten aus wenigstens einem proprietären Datenformat in ein standardisiertes Datenformat und/oder umgekehrt aufweist, wobei die Konvertierungseinrichtung a) eine Komponente mit Mitteln zur Patenzuweisung aufweist, durch welche mittels wenigstens einer Datenzuweisung wenigstens einer in einem standardisierten Datenformat angegebenen zweiten Information mindestens eine in einem proprietären Format angegebene erste Information zugewiesen ist und/oder umgekehrt und b) eine generische Komponente mit Mitteln aufweist, die o für wenigstens eine in einem proprietären Datenformat angegebene erste Information aus der Menge der vorhandenen Datenzuweisungen die entsprechende, ihr zugeordnete Datenzuweisung suchen und aufspüren sowie mittels der zugeordneten Datenzuweisung die jeweilige proprietäre erste Information in eine in der zugeordneten Datenzuweisung spezifizierte, standardisierte zweite Information umwandeln und/oder umgekehrt o für wenigstens e ne standardisierte zweite Information in den in der Konvertierungse nrichtung (4) enthaltenden Datenzuweisungen die der zweiten Informati on zugeordnete Datenzuweisung suchen und aufspüren und mittels der zugeordneten Datenzuweisung die standardisierte zweite Information in eine in der Datenzuweisung spezifizierte proprietäre erste Information umwandeln.
2. System nach Anspruch 1 , dadurch gekennzeichnet, dass die Konvertierungseinrichtung (4) eine genetischen Komponente aufweist, die sowohl vom standardisierten Format als auch vom proprietären Format unabhängig ist.
3. System nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Daten sowohl im jeweiligen proprietären als auch im standardisierten Datenformat in einer vorbestimmten, definierten Struktur, insbesondere in einer hierarchischen Struktur und/oder einer Baumstruktur abgelegt beziehungsweise erfasst sind.
4. System nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass das proprietäre und/oder das standardisierte Format im wesentlichen menschenlesbar und menscheninterpretierbar sind und/oder beschreibende Bezeichner für die Daten oder Informationen aufweisen.
5. System nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die Konvertierungseinrichtung (4) dafür eingerichtet ist, eine alle ins Standardformat, vorzugsweise XML-Format, konvertierten Informationen beziehungsweise Daten enthaltende Datei zu generieren und abzulegen.
6. System nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die Datenzuweisungen als beziehungsweise in wenigstens einer Mapping-Table (10) änderbar abgelegt sind.
7. System nach Anspruch 6, dadurch gekennzeichnet, dass wenigstens eine Mapping-Table (10) Bestandteil der die im Standardformat vorliegenden Daten enthaltenden Datei, vorzugsweise eine XML-Datei (12), ist.
8. System nach einem der Ansprüche 6 oder 7, dadurch gekennzeichnet, dass mit der wenigstens einen Mapping-Table (10) auch Angaben darüber in die im Standarddatenformat vorliegende Datei, vorzugsweise eine XML-Datei (12), aufgenommen sind, durch welches Werkzeug auf weiche Information der Standarddatenformat-Datei zugegriffen wird.
9. System nach einem der Ansprüche 6 bis 8, dadurch gekennzeichnet, dass den einzelnen Einträgen der wenigstens einen Mapping-Table (10) Zusatzinformationen beigefügt sind, die insbesondere einer Koordination und sinnvollen Verbreitung der jeweiligen Daten dienen.
10. System nach einem der Ansprüche 6 bis 9, dadurch gekennzeichnet, dass die Informationen der wenigstens einen Mapping-Table (10) separat in einem eigenen . Datenformat, vorzugsweise im XML-Format, in einzelnen Dateien oder einem Datei- verbünd oder einer Datenbank oder einer Kollektion von Dateien angegeben und/oder gespeichert sind.
11. System nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die Konvertierungseinrichtung (4) dafür eingerichtet ist, bei einer Wertänderung eines Attributs der Standarddatenformat-Datei, vorzugsweise einer XML-Datei (12), sogleich alle vorhandenen Mappingtables (10) nach Verweisen auf eben dieses geänderte Attribut in der Standarddatenformat-Datei zu durchsuchen und die entsprechenden Mappingtables (10) mit einer Markierung zu versehen, die angibt, dass sich dieses Attribut geändert hat, so dass anderen Tools beim Zugriff auf die geänderte Standarddatenformat-Datei mittels Mappingtables (10) sogleich die Information angegeben ist, welche Daten sich seit ihrem letzen Zugriff außerhalb des Programms geändert haben.
12. System nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass in der Standarddatenformat-Datei, vorzugsweise eine XML-Datei (12), nicht nur der aktuelle Zustand sondern auch die Historie, insbesondere der zeitliche Verlauf beziehungsweise die zeitliche Entwicklung des jeweiligen Projektes und/oder der jeweiligen Anlage und/oder Anlagenkomponenten über den gesamten Lebenszyklus oder auch nur einen Teil des Lebenszyklus angegeben ist.
13. System nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die generische Komponente Mittel aufweist, die o für wenigstens eine in einem proprietären Datenformat angegebene erste Information aus der Menge der vorhandenen Datenzuweisungen, die entsprechende, ihr zugewiesene Datenzuweisung aufspüren beziehungsweise finden und mittels der gefundenen Datenzuweisung die proprietäre erste Information in die in der Datenzuweisung spezifizierte, standardisierte zweite Information umwandein und o für die standardisierte zweite Information in den in der Konvertierungseinrichtung (4) enthaltenden Datenzuweisungen die der zweiten Information zugeordnete Datenzuweisung finden und mittels der zugeordneten Datenzuweisung die standardisierte zweite Information in eine in der Datenzuweisung spezifizierte, proprietäre dritte Information umwandeln.
14. Verfahren zur Verwaltung und zum Austausch von Daten, ein technisches ' Projekt, eine technische Anlage oder einzelne Anlagenkomponenten betreffend, insbesondere ein Automatisierungsprojekt betreffend, mittels einer Datenverarbeitungsanlage (2) mit Konvertierungseinrichtung (4) zum Konvertieren von Daten aus wenigstens einem proprietären Datenformat in ein standardisiertes Datenformat und umgekehrt, wobei die Konvertierungseinrichtung (4) a) mittels wenigstens einer Datenzuweisung, wenigstens einer im standardisierten Datenformat angegebenen zweiten Information wenigstens eine in einem proprietären Format angegebene erste Information zuweist und/oder umgekehrt und b) mittels wenigstens einer generischen Komponente, o für wenigstens eine in einem proprietären Datenformat angegebene erste Information aus der Menge der vorhandenen Datenzuweisungen die entsprechende, ihr zugeordnete Datenzuweisung aufspürt beziehungsweise auffindet und mittels der gefundenen Datenzuweisung die proprietäre erste Information in die in der Datenzuweisung spezifizierte Standard is erte zweite Information umwandelt sowie für wenigstens e ne standardisierte zweite Information in den in der Konvertierungse1 nrichtung (4) enthaltenden Datenzuweisungen die der zweiten Informati on zugeordnete Datenzuweisung aufspürt beziehungsweise auffindet und mittels der zugeordneten Datenzuweisung die standardisierte zweite Information in die in der Datenzuweisung spezifizierte, proprietäre erste Information umwandelt.
15. Verfahren nach Anspruch 14, dadurch gekennzeichnet, dass innerhalb der Konvertierungseinrichtung (4) eine generische Komponente verwendet wird, die sowohl vom standardisierten Format als auch vom proprietären Format unabhängig agiert.
16. Verfahren nach einem der Ansprüche 14 oder 15, dadurch gekennzeichnet, dass die Daten sowohl im jeweiligen proprietären als auch im standardisierten Format in einer vorbestimmten, definierten Struktur, insbesondere einer hierarchischen Struktur und/oder einer Baumstruktur abgelegt beziehungsweise erfasst werden.
17. Verfahren nach einem der Ansprüche 14 bis 16, dadurch gekennzeichnet, dass als jeweiliges proprietäre und/oder jeweiliges standardisiertes Format im wesentlichen menschenlesbare und menscheninterpretierbare und/oder beschreibende Bezeichner für die Daten enthaltende Datenformate eingesetzt werden.
18. Verfahren nach einem der Ansprüche 14 bis 17, dadurch gekennzeichnet, dass mittels wenigstens einer generischen Komponente, o für wenigstens eine in einem proprietären Datenformat angegebene erste Information aus der Menge der vorhandenen Datenzuweisungen die entsprechende, ihr zugeordnete Datenzuweisung gesucht und aufgespürt wird und mittels der gefundenen Datenzuweisung die jeweilige proprietäre erste Information in eine in der Datenzuweisung spezifizierte, standardisierte zweite Information umgewandelt wird und o für die standardisierte zweite Information in den in der Konvertierungseinrichtung (4) enthaltenden Datenzuweisungen die entsprechende, ihr zugeordnete Datenzuweisung aufgespürt beziehungsweise aufgefunden wird und mittels der zugeordneten Daten∑uweisung die standardisierte zweite Information in eine in der Daten∑uweisung spezifizierte, proprietäre dritte Information umgewandelt wird.
19. Verfahren nach einem der Ansprüchen bis 18, dadurch gekennzeichnet, dass mittels der Konvertierungseinrichtung (4) alle ins Standarddatenformat, vorzugsweise XML-Format, konvertierten Informationen beziehungsweise Daten in einer Datei abgelegt werden.
20. Verfahren nach einem der Ansprüche 14 bis 19, dadurch gekennzeichnet, dass die Datenzuweisungen als beziehungsweise in wenigstens einer Mapping-Table (10) änderbar abgelegt werden.
21. Verfahren nach Anspruch 20, dadurch gekennzeichnet, dass wenigstens eine Mapping-Table (10) als Bestandteil der im Standardformat vorliegenden, alle relevanten Daten enthaltenden Datei, vorzugsweise einer XML-Datei (12), geführt werden.
22. Verfahren nach einem der Ansprüche 20 bis 21 , dadurch gekennzeichnet, dass mit der wenigstens einen Mapping-Table (10) auch Angaben darüber in die im Standarddatenformat vorliegende Datei, vorzugsweise eine XML-Datei (12), aufgenommen werden durch welches Werkzeug auf weiche Information der Standarddatenformat- Datei zugegriffen wird.
23. Verfahren nach einem der Ansprüche 20 bis 22, dadurch gekennzeichnet, dass den einzelnen Einträgen der wenigstens einen Mapping-Table (10) Zusatzinformationen beigefügt werden, die insbesondere zur Koordination und sinnvollen Verbreitung der jeweiligen Daten herangezogen werden.
24. Verfahren nach einem der Ansprüche 20 bis 23, dadurch gekennzeichnet, dass die Informationen der wenigstens einen Mapping-Table (10) separat in einem eigenen Datenformat, vorzugsweise im XML-Format, in einzelnen Dateien oder einem Dateiverbund oder einer Datenbank oder einer Kollektion von Dateien angegeben und/oder gespeichert werden.
25. Verfahren nach einem der Ansprüche 20 bis 24, dadurch gekennzeichnet, dass mittels der Konvertierungseinrichtung (4) bei einer Wertänderung eines Attributs der Standarddatenformat-Datei, vorzugsweise einer XML-Datei (12), sogleich alle vorhandenen Mappingtables (10) nach Verweisen auf eben dieses geänderte Attribut in der Standarddatenformat-Datei durchsucht und die entsprechenden Mappingtables (10) mit einer Markierung versehen werden, die angibt, dass sich dieses Attribut geändert hat, sodass anderen Tools beim Zugriff auf die geänderte Standarddatenformat-Datei mittels Mappingtables (10) sogleich die Information angegebbar ist, welche Daten sich seit ihrem letzen Zugriff außerhalb des Programms geändert haben.
26. Verfahren nach einem der Ansprüche 20 bis 25, dadurch gekennzeichnet, dass in der Standarddatenformat-Datei, vorzugsweise eine XML-Datei (12), nicht nur der aktuelle Zustand sondern auch die Historie, insbesondere der zeitliche Verlauf beziehungsweise die zeitliche Entwicklung des jeweiligen Projektes und/oder der jeweiligen Anlage und/oder Anlagenkomponenten über den gesamten Lebenszyklus oder auch nur einen Teil des Lebenszyklus angegeben werden.
PCT/EP2004/001884 2003-02-28 2004-02-26 System und verfahren zum verwalten und zum austausch von daten eines technischen projektes, einer technischen anlage sowie einzelner anlagenkomponenten WO2004077305A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP04714740A EP1597675A1 (de) 2003-02-28 2004-02-26 System und verfahren zum verwalten und zum austausch von daten eines technischen projektes, einer technischen anlage sowie einzelner anlagenkomponenten
US10/546,732 US8290990B2 (en) 2003-02-28 2004-02-26 System and method for managing and exchanging data of a technical project, technical installation and individual installation components

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10308725A DE10308725A1 (de) 2003-02-28 2003-02-28 System und Verfahren zum Verwalten und zum Austausch von Daten eines technischen Projektes, einer technischen Anlage sowie einzelner Anlagenkomponenten
DE10308725.7 2003-02-28

Publications (1)

Publication Number Publication Date
WO2004077305A1 true WO2004077305A1 (de) 2004-09-10

Family

ID=32842010

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/001884 WO2004077305A1 (de) 2003-02-28 2004-02-26 System und verfahren zum verwalten und zum austausch von daten eines technischen projektes, einer technischen anlage sowie einzelner anlagenkomponenten

Country Status (4)

Country Link
US (1) US8290990B2 (de)
EP (1) EP1597675A1 (de)
DE (1) DE10308725A1 (de)
WO (1) WO2004077305A1 (de)

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102005058802A1 (de) * 2005-12-09 2007-06-14 Abb Technology Ag System und Verfahren zur automatischen Prüfung von Planungsergebnissen
WO2008013520A1 (en) * 2006-07-22 2008-01-31 Honeywell International Inc. Control system migration
US8515912B2 (en) 2010-07-15 2013-08-20 Palantir Technologies, Inc. Sharing and deconflicting data changes in a multimaster database system
US8688749B1 (en) 2011-03-31 2014-04-01 Palantir Technologies, Inc. Cross-ontology multi-master replication
US20110137694A1 (en) * 2008-01-18 2011-06-09 Michael Schlereth Planning Device and Method for Planning a Technical Installation
US9354629B2 (en) 2009-02-19 2016-05-31 Fisher-Rosemount Systems, Inc. Methods and apparatus to configure a process control system using an electronic description language script
WO2011066846A1 (en) * 2009-12-04 2011-06-09 Abb Research Ltd. System and method for data integration of engineering tools
DE102010011190A1 (de) * 2010-03-11 2011-09-15 Abb Ag Verfahren und System zur Aufbereitung und Bereitstellung von Informationen zum Betrieb einer technischen Anlage
EP2612278A1 (de) * 2010-08-31 2013-07-10 ABB Technology AG System und verfahren für zusammenarbeit, nachrichtenübertragung und informationsaustausch zwischen engineering-werkzeugen
DE102011101154A1 (de) * 2011-05-11 2012-11-15 Abb Technology Ag Verfahren und Einrichtung zur einheitlichen Benennung von gleichen Parametern unterschiedlicher Feldgeräte eines Automatisierungssystems
JP5851962B2 (ja) * 2011-09-19 2016-02-03 株式会社東芝 中継サーバ
US8782004B2 (en) * 2012-01-23 2014-07-15 Palantir Technologies, Inc. Cross-ACL multi-master replication
DE102012202040B4 (de) * 2012-02-10 2023-04-06 Siemens Healthcare Gmbh Automatisches Konfigurieren von Copy&Paste-Profilen
EP2713301A1 (de) * 2012-09-27 2014-04-02 Siemens Aktiengesellschaft Verfahren und System zur Anbindung einer Steuerung für eine Maschine an ein übergeordnetes IT-System
US9081975B2 (en) 2012-10-22 2015-07-14 Palantir Technologies, Inc. Sharing information between nexuses that use different classification schemes for information access control
US9501761B2 (en) 2012-11-05 2016-11-22 Palantir Technologies, Inc. System and method for sharing investigation results
EP2778412B1 (de) 2013-03-15 2019-12-25 Kaeser Kompressoren Se Entwicklung eines übergeordneten modells zum steuern und/oder überwachen einer kompressoranlage
ES2574512T3 (es) 2013-03-15 2016-06-20 Kaeser Kompressoren Se Entrada de diagrama de tuberías e instrumentación para un procedimiento para el control y/o supervisión de una instalación de compresores
US8886601B1 (en) 2013-06-20 2014-11-11 Palantir Technologies, Inc. System and method for incrementally replicating investigative analysis data
US9569070B1 (en) 2013-11-11 2017-02-14 Palantir Technologies, Inc. Assisting in deconflicting concurrency conflicts
US9009827B1 (en) 2014-02-20 2015-04-14 Palantir Technologies Inc. Security sharing system
US9021260B1 (en) 2014-07-03 2015-04-28 Palantir Technologies Inc. Malware data item analysis
US10572496B1 (en) 2014-07-03 2020-02-25 Palantir Technologies Inc. Distributed workflow system and database with access controls for city resiliency
US9785773B2 (en) 2014-07-03 2017-10-10 Palantir Technologies Inc. Malware data item analysis
CN107848617B (zh) * 2015-05-28 2021-10-01 现代重工业株式会社 船舶数据综合管理方法和船舶数据综合管理设备
DE102015209895A1 (de) * 2015-05-29 2016-12-01 Kuka Roboter Gmbh Verfahren zur Konvertierung von zumindest einer ersten Sicherheitskonfigurationsdatei
CN106682011B (zh) * 2015-11-06 2019-12-10 北京国双科技有限公司 利用图形展示数据的方法和装置
US10621198B1 (en) 2015-12-30 2020-04-14 Palantir Technologies Inc. System and method for secure database replication
KR102473668B1 (ko) * 2016-03-02 2022-12-01 삼성전자주식회사 발광 소자 실장 기판 및 이를 이용한 발광 패키지
US10671038B2 (en) 2016-07-15 2020-06-02 Fisher-Rosemount Systems, Inc. Architecture-independent process control
US10262053B2 (en) 2016-12-22 2019-04-16 Palantir Technologies Inc. Systems and methods for data replication synchronization
US10068002B1 (en) 2017-04-25 2018-09-04 Palantir Technologies Inc. Systems and methods for adaptive data replication
US10430062B2 (en) 2017-05-30 2019-10-01 Palantir Technologies Inc. Systems and methods for geo-fenced dynamic dissemination
US11030494B1 (en) 2017-06-15 2021-06-08 Palantir Technologies Inc. Systems and methods for managing data spills
US10380196B2 (en) 2017-12-08 2019-08-13 Palantir Technologies Inc. Systems and methods for using linked documents
US10915542B1 (en) 2017-12-19 2021-02-09 Palantir Technologies Inc. Contextual modification of data sharing constraints in a distributed database system that uses a multi-master replication scheme
DE102019128104A1 (de) * 2019-10-17 2021-04-22 Mhp Management- Und It-Beratung Gmbh Fertigungssteuerungssystem

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5404488A (en) * 1990-09-26 1995-04-04 Lotus Development Corporation Realtime data feed engine for updating an application with the most currently received data from multiple data feeds
WO1996037817A1 (en) * 1995-05-25 1996-11-28 Reliant Data Systems System and method for converting data from a first data format to a second data format
EP1117049A1 (de) * 2000-01-14 2001-07-18 Sun Microsystems, Inc. Dynamische Übersetzung von Daten
DE10138533A1 (de) * 2000-12-15 2002-07-11 Siemens Ag Bereitstellung von Projekt- und/oder Projektierungsdaten eines Automatisierungsprojekts in einem durch eine standardisierte Meta-Sprache, insbesondere XML, definiertem Format

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5119465A (en) * 1989-06-19 1992-06-02 Digital Equipment Corporation System for selectively converting plurality of source data structures through corresponding source intermediate structures, and target intermediate structures into selected target structure
US5557780A (en) * 1992-04-30 1996-09-17 Micron Technology, Inc. Electronic data interchange system for managing non-standard data
US6295541B1 (en) * 1997-12-16 2001-09-25 Starfish Software, Inc. System and methods for synchronizing two or more datasets
US20020184308A1 (en) * 1999-08-23 2002-12-05 Levy Martin J. Globalization and normalization features for processing business objects
US6810429B1 (en) * 2000-02-03 2004-10-26 Mitsubishi Electric Research Laboratories, Inc. Enterprise integration system
US6785673B1 (en) * 2000-02-09 2004-08-31 At&T Corp. Method for converting relational data into XML
US7031956B1 (en) * 2000-02-16 2006-04-18 Verizon Laboratories Inc. System and method for synchronizing and/or updating an existing relational database with supplemental XML data
US7124144B2 (en) * 2000-03-02 2006-10-17 Actuate Corporation Method and apparatus for storing semi-structured data in a structured manner
US7114147B2 (en) * 2000-03-09 2006-09-26 Electronic Data Systems Corporation Method and system for reporting XML data based on precomputed context and a document object model
JP2002024211A (ja) * 2000-06-30 2002-01-25 Hitachi Ltd 文書管理方法およびシステム並びにその処理プログラムを格納した記憶媒体
US7024413B2 (en) * 2000-07-26 2006-04-04 International Business Machines Corporation Method of externalizing legacy database in ASN.1-formatted data into XML format
US20020059566A1 (en) * 2000-08-29 2002-05-16 Delcambre Lois M. Uni-level description of computer information and transformation of computer information between representation schemes
EP1215547B1 (de) * 2000-12-15 2007-01-03 Siemens Aktiengesellschaft Verschlüsselung von Steuerungsprogrammen
US7392237B2 (en) * 2001-04-26 2008-06-24 Siemens Medical Solutions Usa, Inc. Identifier code translation system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5404488A (en) * 1990-09-26 1995-04-04 Lotus Development Corporation Realtime data feed engine for updating an application with the most currently received data from multiple data feeds
WO1996037817A1 (en) * 1995-05-25 1996-11-28 Reliant Data Systems System and method for converting data from a first data format to a second data format
EP1117049A1 (de) * 2000-01-14 2001-07-18 Sun Microsystems, Inc. Dynamische Übersetzung von Daten
DE10138533A1 (de) * 2000-12-15 2002-07-11 Siemens Ag Bereitstellung von Projekt- und/oder Projektierungsdaten eines Automatisierungsprojekts in einem durch eine standardisierte Meta-Sprache, insbesondere XML, definiertem Format

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"EXTENSIBLE MARKUP LANGUAGE (XML) 1.0 (SECOND EDITION)", W3C RECOMMENDATION, 6 October 2000 (2000-10-06), XP002188896 *
ANONYMOUS: "Product Data Management: The Definition, An Introduction to Concepts, Benefits, and Terminology", CIMDATA, 2 September 1997 (1997-09-02), XP002226495 *
See also references of EP1597675A1 *

Also Published As

Publication number Publication date
US20070005805A1 (en) 2007-01-04
DE10308725A1 (de) 2004-09-09
EP1597675A1 (de) 2005-11-23
US8290990B2 (en) 2012-10-16

Similar Documents

Publication Publication Date Title
WO2004077305A1 (de) System und verfahren zum verwalten und zum austausch von daten eines technischen projektes, einer technischen anlage sowie einzelner anlagenkomponenten
DE602005005924T2 (de) Einheitliches Datenformat für Messgeräte
EP1723513B1 (de) Verfahren zur konfiguration eines computerprogramms
EP1215589A2 (de) Bereitstellung von Projektdaten in einem durch eine standardisierte Meta-Sprache definiertem Format
EP1176482A1 (de) Verfahren und Computerprogramm zum Herstellen einer Regelung oder Steuerung
DE102007040823A1 (de) Editier- und Berichts-Tool für Grafische Programmiersprachenobjekte
EP0697640B1 (de) Datenanordnung für ein an einem Kommunikations-Netzwerk anschliessbares Gerät und Verfahren zur Erzeugung der Datenanordnung
DE10149693A1 (de) Objekte in einem Computersystem
WO2007006671A1 (de) Verfahren und softwaresystem zur konfiguration eines modularen systems
DE69907714T2 (de) Komponentbasiertes quellcodegeneratorverfahren
DE10026478A1 (de) Verfahren zur Generierung anwendungsspezifischer Eingabedateien
DE102012001406A1 (de) Automatische Konfiguration eines Produktdatenmanagementsystems
EP2290593A1 (de) Verfahren zur Unterstützung einer Planung einer technischen Anlage
EP1442340A1 (de) Bereitstellung von informationen in einem automatisierungssystem
EP1515207A1 (de) Automatisierungsobjekt und Verfahren zur Beschreibung eines Automatisierungsobjektes unter Verwendung einer Metasprache
EP3850443B1 (de) Verfahren zur integration von daten von assets einer technischen anlage in eine plattform, digitale plattform und computerprogrammprodukt
DE10131956A1 (de) Verfahren und System zur Inbetriebsetzung von MES-Komponenten
DE4310615C2 (de) Entwurf elektrischer Vorrichtungen mit mehreren Entwurfswerkzeugen, die zumindest teilweise untereinander inkompatibel sind
WO2010034548A1 (de) Testmodul und verfahren zum testen einer o/r-abbildungs-middleware
EP1621945B1 (de) Konsistenzsicherung in einem Automatisierungssystem
DE10138533A1 (de) Bereitstellung von Projekt- und/oder Projektierungsdaten eines Automatisierungsprojekts in einem durch eine standardisierte Meta-Sprache, insbesondere XML, definiertem Format
EP1237075A1 (de) Prä-Prozessor für vorgegebene Dokumententypdefinition, System zur Verarbeitung von Auszeichnungssprachen-Dokumenten, Verfahren und Computerprogrammprodukt dazu
DE102004023634B4 (de) Verfahren zur Vollständigkeits- und Konsistenzprüfung einer Informationsbibliothek
EP3355186A1 (de) Erzeugung und ausführung von software-modulen
EP1600854A2 (de) Verfahren zum Arbeiten mit Kontaktplan und Funktionsplan und hierzu geeigneter grafischer Editor

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 1619/KOLNP/2005

Country of ref document: IN

REEP Request for entry into the european phase

Ref document number: 2004714740

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2004714740

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2004714740

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2007005805

Country of ref document: US

Ref document number: 10546732

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 10546732

Country of ref document: US