EP1597675A1 - 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

Info

Publication number
EP1597675A1
EP1597675A1 EP04714740A EP04714740A EP1597675A1 EP 1597675 A1 EP1597675 A1 EP 1597675A1 EP 04714740 A EP04714740 A EP 04714740A EP 04714740 A EP04714740 A EP 04714740A EP 1597675 A1 EP1597675 A1 EP 1597675A1
Authority
EP
European Patent Office
Prior art keywords
data
information
format
proprietary
standardized
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
EP04714740A
Other languages
English (en)
French (fr)
Inventor
Peter Drath
Peter Bort
Alexander Fay
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ABB Research Ltd Switzerland
ABB Research Ltd Sweden
Original Assignee
ABB Research Ltd Switzerland
ABB Research Ltd Sweden
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 Switzerland, ABB Research Ltd Sweden filed Critical ABB Research Ltd Switzerland
Publication of EP1597675A1 publication Critical patent/EP1597675A1/de
Ceased legal-status Critical Current

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 present invention relates to a system and a method for managing and exchanging data, a technical project and / or a technical system and / or individual system components and, in particular, an automation project for a technical system, with the present invention an efficient and consistent interaction several different applications or data processing tools is guaranteed and achieved.
  • a project in the sense of the invention claimed here can, for example, include planning, development, construction, testing, test acceptance, commissioning, operation, but also maintenance and repair as well as, if necessary, the expansion and modification of a technical system and / or include individual system components, i.e. a technical system and / or individual system components in all their life cycle phases.
  • 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.
  • the aforementioned data can include, for example, measurement, monitoring, performance and / or evaluation data of the respective system, but also information about servicing and / or maintenance measures as well as technical developments or improvements to the system.
  • Data is recorded in particular during the engineering process or during the planning and design phase, at the beginning of the respective life cycle of a plant.
  • the data generated here essentially describe the structure and implementation of the respective technical system.
  • the modification or change of the generated or recorded plant-specific data record and / or the recording or generation of new data relating to planned and / or changes made to the respective technical system are carried out essentially in the operating phase of the respective system.
  • Plant can lead.
  • a common database for all processing tools or applications relating to the life cycle of a system must be used when using or using several different processing tools.
  • This can be, for example, a central database or several distributed databases with a common data model or object model.
  • n tools where n denotes the number of tools used, n * (n-1) / 2 data interfaces must be set up, maintained and maintained if every tool involved or used is to have the possibility to exchange or interact with any other tool and to define or define a separate interface format for each exchange.
  • a data format is usually selected or defined and standardized, for example as a company standard, as a national standard and / or as an international standard, and thus a central standard data format is generated, via which the mutual data exchange of the processing tools or applications used.
  • Each of these interfaces converts project and / or project planning data or other data relating to the system, its components and / or its automation system from the proprietary tool-internal format into the standardized data format and makes them available to all other tools via export functions.
  • 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
  • STEP Standard for the Exchange of Product Data
  • EXPRESS STEP exchange language
  • EP 0770943 B1 describes an in-house standardized description of the data of an automation project and the system to be automated. Also in A. Fay: Methods for Supporting the Migration of Process Control System Software, Automation Practice 44, Oldenbourg-Verlag, Kunststoff, Issue 6/2002, pp. 39-44, a description of an in-house standard specified part of the engineering data of an automation project, with particular reference being made to the advantages, such as reducing the interface effort to several engineering tools.
  • the respective data or files can be easily read by people with comparatively little effort and information can be found and interpreted correspondingly easily.
  • individual applications or processing tools can be created in a comparatively simple manner, with which the aforementioned files can be processed, that is to say read and written.
  • 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 files read, check for well-formedness, convert to another, possibly proprietary data format or object model and / or convert an existing object model or the data or information describing it into a well-formed XML file.
  • XML files usually have all of the above characteristics, which a standard data format should have.
  • the language XSLT XML Stylesheet Language Translation
  • XSLT was defined in the context of XML as a programming language for converting XML documents into other standardized formats.
  • XML Because of its known advantages and possibilities, XML is used or recommended in many areas where there is a need to exchange data between different processing tools in a standardized format. The possibility of the advantageous use of XML for such tasks in any application areas is generally known and was also the declared goal of the development of XML.
  • 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 programming language XSLT can also be used to convert XML files into files with other standardized or proprietary formats, whereby changes to the proprietary data format disadvantageously require interventions in the program code of the specified or used conversion modules.
  • the aforementioned changes to the proprietary data format may be necessary, for example, through changes in the functionality of the respective processing tool, through a change in the implementation of the respective processing tool into the overall concept and / or with changes in the standardized data format.
  • the aforementioned changes can be brought about, for example, by integrating a further processing tool into the standardized data format. Due to the ever shorter innovation cycles, the associated shorter cycle times and frequent changes of the tool generations or versions used as well as the increasing requirements with regard to the integration of further tools or applications, the aforementioned problem is becoming increasingly important.
  • Interventions in existing applications and / or processing tools are particularly consistent and - as already stated - the information or data describing a technical system and its automation system over the entire life cycle of the system, which can usually extend over several decades should or should be maintained, problematic, since this would require interventions and modifications of decades-long applications and processing tools, especially their program codes. As a rule, however, there is no longer any expertise available or available for this.
  • This task is carried out by a system and a procedure for the administration and exchange, in particular also for the generation, modification and storage of data of a technical project, a technical system and / or individual system components, but especially an automation project for a technical system solved the features of the independent claims.
  • Advantageous refinements of the system according to the invention and of the corresponding method are specified in the dependent claims and the description below.
  • the present invention includes a data processing system with a conversion device for converting data from a proprietary data format into a standardized data format and vice versa, the conversion of detailed information of the respective application domain being independent.
  • the conversion information of the various application domains is not stored here as graphical rules, but rather is given in the form of assignments between data objects, the assignments of the type 1: 1, 1: n, m: 1 or m: n, with m and n as any natural integers greater than 1.
  • the system according to the invention for managing and exchanging data in particular also for generating, modifying and storing data of a technical project, a technical system and / or individual system components, in particular an automation project for a technical system, has at least one data processing system with conversion device for converting project and / or project planning data and / or operating data of the respective technical system and / or the associated automation system from a proprietary format into a standardized format and vice versa.
  • the con- The conversion device in this case comprises at least one means for data assignment, which is set up to assign at least one piece of second information specified in the standardized data format, preferably XML, to at least one piece of first information specified in the proprietary " format, and / or vice versa Data conversion to which is set up to find or find the corresponding data assignment assigned to it from any set of data assignments for any first information specified in the proprietary data format, and to use the data assignment found to specify the proprietary first information into the data assignment specified in the assigned data assignment to convert standardized second information and / or vice versa for any standardized second information in the data assignments contained in the conversion device to track down or find computing data assignment and to convert the standardized second information into the proprietary first information specified in the assigned data assignment.
  • An advantageous embodiment provides that the conversion device is set up to search for and track down the corresponding data assignment assigned to it from the set of existing data assignments for the first information specified in the proprietary data format, and to use the data assignment found to find the proprietary one convert the first information into the standardized second information specified in the data assignment and search for and find the corresponding data assignment assigned to it for the standardized second information in the data assignments contained in the conversion device and, via this, the standardized second information into a proprietary one specified in the data assignment to convert third information.
  • the data are preferably stored both in the proprietary and in the standardized format in a predetermined, defined structure, in particular a hierarchical structure and / or a tree structure.
  • Both the proprietary and the standardized format are preferably human-readable and human-interpretable and / or contain descriptive identifiers for the respective data.
  • the specified conversion device is configurable insofar as it can be separated into two independent components, namely a component a) for assigning data and a generic component b) for converting data, the generic component b) providing the conversion function and usually can be implemented as a program component that can be executed on a data processing system in a common programming language and with corresponding program code means.
  • the data assignments specified in component a), in particular a file, which are used to adapt the conversion device to the respective application domain or the respective application area and / or the processing tool used in each case, as well as the data formats to be converted, can be individually adapted and configured ,
  • the data assignments are stored in the form of a simple table. If a simple assignment via a table is not possible, then the conversion can also take place via a hierarchically structured mapping structure which, for example, as in the German patent applications with official file number DE 102 54 530.8, DE 102 54 531.6 and DE 102 54 532.4 is used in parsers for textual programming languages.
  • the above-mentioned separability or configurability has the advantage that component a) of the conversion device, which has at least one means for data assignment, and component b) of the conversion device, which has at least one means for data conversion, are developed, developed and maintained independently of one another can be.
  • the generic component b) can be adapted at any time, for example, to currently available or customary program code means, operating system environments, development methods and / or techniques, which if more than one project data and / or system data is used Decades will almost certainly be required several times during the life cycle of a technical system. However, the data assignments of the application domain specified in component a) remain unaffected.
  • 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 standardized data format has to be changed and / or expanded because, for example, a further processing tool that has additional data and objects reads in, changes and / or creates the standardized data format, preferably XML, in the processing tool.
  • Verbund should be involved. According to the state of the art, this would require that for all processing tools that are also intended to use or want to use these additional data and objects for reading and / or writing, the corresponding conversion components would have to be adapted or expanded by intervening in the possibly decades-old program codes, what usually requires expert knowledge and expensive program code resources, for example suitable compilers and / or debuggers.
  • this extension can be accomplished simply by simply adding and / or changing the data assignments specified, for example, in a table in a standard data format file. This does not require expert knowledge, programming knowledge or costly program code resources.
  • a method for managing and exchanging data, relating to a technical project, a technical system and / or individual system components, in particular relating to an automation project, by means of at least one data processing system with conversion device for converting data a proprietary data format into a standardized data format and vice versa is claimed.
  • the conversion device allows at least one piece of first information specified in the proprietary data format to be assigned at least one piece of second information specified in the standardized format and / or vice versa.
  • the method using a generic component of the conversion device with at least one means for converting data, for any first information specified in the proprietary data format, the corresponding data assignment assigned to the first information is found or found from the set of existing data assignments, and the proprietary data assignment is found using the data assignment found first information is converted into the standardized second information specified in the assigned data assignment and / or, conversely, the desired data assignment assigned to the second information is searched for and found for any standardized second information in the data assignments contained in the conversion device, and the standardized second information is found in the proprietary first information specified in the data assignment is converted.
  • a first proprietary information can accordingly be converted into another proprietary information by means of data assignments.
  • 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.
  • Figure 2 Exemplary process diagram relating to the administration
  • FIG. 3 Exemplary process diagram relating to the administration and the exchange of objects and their contents between object libraries of two different processing tools with a complete mapping table.
  • Figure 4 Exemplary process diagram, regarding the administration and the
  • Figure 5 Exemplary process diagram, regarding the administration and the
  • the aforementioned system here has a data processing system 2 with conversion device 4 and means for data allocation and conversion of data from at least one proprietary format into at least one standardized format and vice versa.
  • a transformation between any two data formats can be represented by means of semantic mapping tables 10 or mapping tables, which are also generally referred to below as mapping tables.
  • the data processing system 2 also has an input device 2a, a display device 2b and a data memory 2c with which it interacts.
  • 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.
  • mapping tables 10 can be created and / or changed before or during the method, depending on the application area, manually by the user of the various applications, or the corresponding mapping tables 10 can be used with the applications or processing tools used in each case. to be delivered. In special cases, the mapping table 10 can also be created automatically.
  • mapping tables 10 A prerequisite for the use of mapping tables 10 is the existence of a clear association between at least some of the existing data or information, the term data or information including the associated objects, their attributes and their relations.
  • mapping tables 10 according to the method is explained by way of example using some exemplary embodiments.
  • Tool A uses a tool-specific "object library A” (data library) 20 to create project data.
  • the objects data or information contained in "object library A” 20)
  • Tool B the same procedure is followed, whereby the “object library B” 22 can have a structure that differs from the “object library A” 20.
  • the two aforementioned different processing tools if they have been implemented in terms of program technology, can be carried out on the data processing system 2 (see FIG. 1) with a conversion device 4 (see FIG. 1) or on other data processing devices if they are with the data processing system 2 Conversion device 4 interact via corresponding network connections, such as LAN, WAN, in particular Internet connections and / or radio connections.
  • 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 can be formed .
  • the exchange of any files and / or data or information between the two tools, Tool A and Tool B is now possible.
  • any first information of the “ Object library A "20 assign a second piece of information to the own" object library B "22.
  • the aforementioned information can be, for example, measurement or control data, evaluation results, in particular of another tool, performance data, or maintenance data.
  • a file with "project data A” 30 is thus directly readable for tool B in the form of another file with "project data B" 32. Since the assignment 34 between the data is unambiguous, tool B can write changes from the “project data B” 32 directly back into the XML file 12 and thus make them available to the tool A.
  • 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.
  • An advantage of the invention is that it is harmless if a second tool, Tool B, cannot process all the data made available by a first tool, Tool A.
  • Tool B there is an empty relation 40 between these data. 4 receives the first information "Documents" 42 from the "object library A" 20 in the mapping table 10 have no relation to a second piece of information 44 from Tool B. Tool B thus only receives knowledge of those data which are known from a relation.
  • both tools work with the same XML file 12, advantageously no data is lost, and data loss is avoided.
  • tool B processes only a subset of the data in the XML file 12, the remaining part of the XML file 12 or its data remain unaffected.
  • the empty relations 40 only confirm the completeness of the relations and are negligible for further considerations. In some cases it can even be advantageous to automatically add the "Object library B" 22 when reading information from the "project data A" 30 or the "object library A” 20 and thus to reduce the number of empty relations 40. In this way can "learn" Tool B from Tool A.
  • mapping tables 10 which can be exchanged, expanded and maintained without programming knowledge and / or expert knowledge regarding the the applications or tools used are required or are required.
  • 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.
  • the XML file 12 does not have to have, as is usual with generic databases, an initially defined, predetermined and well-defined structure which meets all current and future requirements of the tools or tools used in the sense of a well-defined meta model or a meta database.
  • the mechanisms of the XML file format allow the data format to be expanded at any time in the life cycle of a system without influencing and / or changing the readability of the XML file 12 for the other tools or tools.
  • mapping tables 10 the data that are in the limited problem area of each of the tools are linked or assigned to the data that are already contained in the XML file 12.
  • Each tool or tool or application also sees the XML file 12 through its own “glasses” or its own “filter” and thus receives its own view of the data (view model).
  • File 12 stored and can be further processed in subsequent tools or applications by further mapping tables 10. In this way, the XML-based system project file grows and with the help of different mapping tables 10 each tool is presented individually, that is to say in its own way.
  • mapping tables 10 act as a kind of information filter that masks the XML project file, for example.
  • mapping tables 10 are available outside of the tools as variable configuration means, which can be created with comparatively little effort and limited specialist or expert knowledge.
  • mapping table 10 which is interchangeable, expandable, readable by a suitable generic data format such as XML and thus also maintainable.
  • 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.
  • an empty XML file 12 is initially available in simplified form.
  • a process engineer determines an R-I flow diagram (flow diagram of pipes and installations) from his specifications and creates this in Tool 1 using an object library.
  • Each of the elements of the flow diagram in particular tanks, pumps, valves, pipelines, etc., are objects of the drawing and have individual properties with their associated values, such as, for example, volume, diameter etc.
  • This information is obtained using a predetermined mapping or mapping table, mapping -Table 1, stored in the XML file 12.
  • a process control engineer needs a range of information from the RI flow diagrams, such as measuring points, control loops, sensors and actuators.
  • Mapping table 2 is used to assign the objects of the RI flow diagram for the objects of interest to the control technician, such as sensors, actuators, control loops etc.
  • a second tool, Tool 2 consequently receives a limited section of the information of interest from the XML file 12. From this, the control engineer develops the control software, for example, selects passeride devices from a device library, configures the communication systems and / or develops operator graphics. The resulting data are in turn written back to the XML file 12.
  • Tool 3 is the operating software that is shown to an operator during operation. From here, the operator can drive his system, identify irregularities, start and end processes or initiate various measures for maintenance or accident prevention. From this software, the operator can access all information that has arisen in the development cycle of the system. The selection, which information this is, is made by the mapping table 3. Mapping tables thus allow the information that can be called up to be restricted.
  • a fourth tool, Tool 4 is a service tool that is available to a system maintenance technician. From here he can call up the relevant information about the devices and functions of his system. The selection of the information available to him can be determined via mapping table 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.
  • mapping tables 10 to be included in XML file 12.
  • An advantage of this embodiment of the invention is that the number of files' is reduced, which simplifies the transmission.
  • the mapping tables 10 also include information about which tool accesses soft information in the XML file 12, for example. This can be used, for example, if the name of an information in the XML file 12 changes - the corresponding tools that use this information can be found quickly and their data assignments can be changed automatically. There is no need to change the tools themselves. If, on the other hand, the name of an object changes in a proprietary database of a specific tool, only the quantity of mapping tables 10 assigned to this tool has to be found and the assignments to the object in question have to be changed.
  • a further advantageous embodiment of the invention consists in adding additional information to the individual entries of the mapping tables 10, which are used for coordination and sensible distribution of the data. If, for example, a tool changes the value of an attribute in the XML file 12, the conversion device 4 (cf. FIG. 1) will immediately search all mapping tables 10 for references to this attribute in the XML file 12 and provide them with a marking , which indicates that this attribute has changed. When accessing the XML file 12, the other tools thus immediately receive the information which data have changed outside of the program since their last access.
  • the aforementioned marking can be done, for example, by flags (electronic flags) that indicate this change.
  • 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.
  • all of the data and information generated in the entire life cycle of the system can each be provided with a time stamp or a marking and / or some other information.
  • the XML file 12 then no longer represents only the current state but also the entire history, that is to say the temporal course or the temporal development of the respective project over its entire life cycle or only over part of its life cycle.
  • the XML file 12 forms a kind of log book of the system.
  • a further advantageous embodiment of the invention enables the information of the mapping tables 10 to be stored separately in its own format, preferably in an easily readable format such as XML. This can be done in particular in individual files, a group of files, a database or a collection of files.
  • the file exchange can advantageously be file-based or by data streams, for example by means of a network using a data exchange protocol directly between different applications.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

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.
EP04714740A 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 Ceased EP1597675A1 (de)

Applications Claiming Priority (3)

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 2003-02-28
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

Publications (1)

Publication Number Publication Date
EP1597675A1 true EP1597675A1 (de) 2005-11-23

Family

ID=32842010

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04714740A Ceased 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

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
CN102640142A (zh) * 2009-12-04 2012-08-15 Abb研究有限公司 用于工程工具的数据集成的系统和方法
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
EP2778413B1 (de) 2013-03-15 2016-03-02 Kaeser Kompressoren Se R&I-Schema Eingabe für ein Verfahren zum Steuern und/oder Überwachen einer Kompressoranlage
ES2776004T3 (es) 2013-03-15 2020-07-28 Kaeser Kompressoren Se Desarrollo de un modelo superior para el control y/o monitorización de una instalación de compresor
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
US9785773B2 (en) 2014-07-03 2017-10-10 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
US9021260B1 (en) 2014-07-03 2015-04-28 Palantir Technologies Inc. Malware data item analysis
KR102601511B1 (ko) * 2015-05-28 2023-11-14 에이치디한국조선해양 주식회사 선박 데이터 통합 관리 방법 및 장치
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 (3)

* 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
EP1122652A1 (de) * 2000-02-03 2001-08-08 Mitsubishi Denki Kabushiki Kaisha System zur Integration von Daten

Family Cites Families (15)

* 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
US5708828A (en) 1995-05-25 1998-01-13 Reliant Data Systems System for converting data from input data environment using first format to output data environment using second format by executing the associations between their fields
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
EP1117049A1 (de) 2000-01-14 2001-07-18 Sun Microsystems, Inc. Dynamische Übersetzung von Daten
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
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
EP1215589A3 (de) * 2000-12-15 2006-05-31 Siemens Aktiengesellschaft Bereitstellung von Projektdaten in einem durch eine standardisierte Meta-Sprache definiertem Format
US7392237B2 (en) * 2001-04-26 2008-06-24 Siemens Medical Solutions Usa, Inc. Identifier code translation system

Patent Citations (3)

* 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
EP1122652A1 (de) * 2000-02-03 2001-08-08 Mitsubishi Denki Kabushiki Kaisha System zur Integration von Daten

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of WO2004077305A1 *

Also Published As

Publication number Publication date
DE10308725A1 (de) 2004-09-09
US20070005805A1 (en) 2007-01-04
US8290990B2 (en) 2012-10-16
WO2004077305A1 (de) 2004-09-10

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
DE69712560T2 (de) System zur Konfiguration von vorkonfigurierten Programmen auf vernetzten offenen Systemen in einer verteilten Umgebung und Verfahren zur Durchführung dieses Systems
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
EP1061422A1 (de) Informationstechnisches System zur Definition, Optimierung und Steuerung von Prozessen
DE69032689T2 (de) Rechnersysteme mit einer Prozessdatenbank und Verfahren zur Benutzung in diesen Systemen
DE10149693A1 (de) Objekte in einem Computersystem
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
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
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20050823

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK

RIN1 Information on inventor provided before grant (corrected)

Inventor name: DRATH, RAINER

Inventor name: FAY, ALEXANDER

Inventor name: BORT, PETER

DAX Request for extension of the european patent (deleted)
REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20170129