Patent Application
20060184715
This application claims priority to the European application No. 04030322.4, filed Dec 21, 2004 which is incorporated by reference herein in its entirety.
The invention relates to a system and a method for exchanging application-oriented description data between projects, in particular between engineering projects in the field of automation.
Complex automation solutions are at present generally developed in a number of projects or sub-projects by teams working in parallel. Development work can even be split between different companies, for example operating as sub-contractors. Generally such projects are only loosely linked to each other. It is however necessary to communicate data describing certain characteristics of relevance to the project as a whole smoothly between the individual sub-projects so that the parallel development can continue smoothly. The relevant characteristics or data can for example be network addresses, which are the same for all the sub-projects. The required synchronization can hereby be achieved on a shared basis. The different teams synchronize and update their own data of relevance to their sub-project. In a different model synchronization can be undertaken by a central body that coordinates the sub-projects In the latter case the sub-contractors or the individual sub-projects receive the data that is of relevance to the project as a whole and therefore fixed to program the parts assigned to them.
Generally in such scenarios there is no shared database or storage unit for the project. This is for example due to the absence of a database for use on a shared basis or an inadequate infrastructure, such as unsatisfactory or slow network access. At prese nt there is no reasonable support for such development scenarios, allowing the data of relevance in the engineering context to be administered and used efficiently for the sub-projects. At present users therefore have two options: they can work according to defined rules and try to comply with the agreed rules or they use the “copy insert” option to exchange project data.
An object of the present invention is therefore to enable exchange of description data, in particular application-oriented engineering data, between sub-projects in an efficient and reliable manner.
This object is achieved by the claims.
The invention is based on the knowledge that storing and then exch anging relevant description data relating to objects means that all the information required for communication between sub-projects is available. The description data is stored on a shared basis in so-called inter-project interfaces (IPI).
So-called tags are for example part of the information present in the various sub-projects, which must be identical in the respective sub-projects. To establish the exchange of data or connections for example between an operating and monitoring system, an MES syst em and a controls system, the data types, symbolic names and paths of all those global tags required by the sub-projects involved are stored in the IPI.
The stored data is for example the characteristics of objects of relevance in a number of projects. The whole object is therefore not stored in the IPIs, just some of its characteristics. The stored description data thereby has a unique identity, a so-called master ID. This identity can be used to track and update the corresponding description data. This is also possible when a number of IPIs are generated in the context of a cascade of sub-projects, so that the relevant description data of all the projects involved is always up to data and has the same status. Updating hereby takes place with the aid of time stamps.
Alarms are also stored as description data in the IPIs. To forward alarms generated by a controller for example to an operating and monitoring element (HMI element), the information about the definition of the alarm must be part of the IPI, so that it can be interpreted identically by both sub-projects. So-called function block interfaces are also part of the description data. These for example support the remote launching of a procedure or function.
To connect different devices to the same network for example, it must be ensured that the respective addresses are stated clearly and direct assignment of the addresses to the respective device must be guaranteed. To this end the addresses must also be identical in the various sub-projects, so that addresses are not confused. Therefore network addresses and further device parameters of relevance in the context of the network should for example be stored as description data in the IPIs.
In the context of a total automation solution certain devices or parts of devices or even the technological hierarchy of the devices in relation to each other must be standard and unique. This is essential for unique assignment of the devices themselves and their positioning in the technological hierarchy. It is therefore advantageous if the project structure relating to the devices and the technological hierarchy is also stored in the form of description data and is therefore part of the IPI.
By storing the description data the IPI advantageously allows prompt and smooth integration of two or even more independently developed sub-projects. It is therefore necessary to store not only the symbolic names but also for example the physical address or references to tags, alarms and other objects. Using the IPIs as a storage unit for the description data allows a form of “plug and play” for different parts of a developing automation solution. Use of the stored description data makes it significantly easier for the engineers or developers in individual sub-projects to create a corresponding engineering solution. To allow a simple exchange of information, the stored description data, i.e. the IPIs, can for example be stored in a relatively small file and be exchanged for example by email, via shared hard drives or even using USB sticks.
Generally the claimed system allows parallel work with independent projects. Relevant information such as project structure, network data, reports and symbol definitions can be identified and are available in a standard manner for the projects involved by mail or other communication means. The identity of the information can be used to exchange said information between the projects and to update it.
Further advantageous embodiments of the invention are laid down in the dependent claims.
The invention is described and explained in more detail below with reference to the exemplary embodiments illustrated in the figures, in which:
The relevant description data has a unique identity, a master ID, on the basis of which it can be assigned uniquely even after modification. Data can be amended in a sub-project on the basis of the identity with the aid of time stamps for example. The latest value of the descriptive data is always adopted in the projects when the update takes place.
In addition to the example described above, in larger development schemes a number of sub-projects can also be supplied with the description data of relevance to them via a number of IPIs. A chain of sub-projects can hereby be generated with an associated chain of IPIs. The relevant description data can also hereby be updated and aligned between sub-projects of the same hierarchy or even between projects and subordinate sub-projects, for example of a sub-contractor, by means of the unique identity and the use of time stamps.
It is simple for the user to create IPIs in the context of a sub-project. For example a user only needs to make known in the context of a controls project which of the tags or alarms or other super-parameters are of relevance to another project, for example an HMI project. The IPI file containing the corresponding description data is then generated automatically at the touch of a button. This can be done for example by giving every tag an attribute, for example HMI-relevant, public or global, which can for example also be a basic setting. If it is not required or if it is not global description data, the attribute, for example the user flag, can be deleted.
In the context of the corresponding system the description data is then written into the corresponding IPI by means of a function, for example “File>Export-Interfaces”. The objects written to the IPI file are still present in the original project. They can also be amended there. In contrast only the remote object representing the original object exists in the sub-project. The remote object can be updated by the user if said user once again generates an IPI file. The original object can only be updated in the source object.
| Number | Date | Country | Kind |
|---|---|---|---|
| 04030322.4 | Dec 2004 | EP | regional |
