Method for an integrated data handling for the engineering and operation of a plant

The invention is related to a method for an integrated data handling in a plant which is engineered and operated by a plurality of software applications having different functionalities, comprising the step of interconnecting said software applications via a communication framework and mechanism .

Although in the following the invention is exemplified by a power plant, it is by no means restricted to power plants, but can be applied in any kind of plant.

A power plant is a technical system which is built to execute a power generation process. The power generation process is a hierarchical process that uses hardware (e.g. field devices, pumps or a conveyer belt) to transform energy with the ultimate goal of generating electrical power. The operation, monitoring and controlling of the power plant is carried out by an automation system respectively by humans. For this purpose a multitude of heterogeneous software applications which realize the automation logics (e.g. automatic control loops), the possibilities for operator interactions etc. are required. Such software applications include e.g. a distributed control system (DCS) , an asset management system or a fleet control system.

One can distinguish two major phases: (1) the engineering phase and (2) the operation phase. Note that the tasks within the two phases are fundamentally different. The engineering phase includes the configuration of hardware setup, logics, process parameters etc. by using corresponding software applications. Also the plant erection and commissioning is considered to be part of this phase. The operation phase includes operation and control of the power generation process at runtime. Note, that both phases are strongly connected, since the result of the engineering phase (i.e. the configuration of the hardware setup and logics) is required during the operation phase to run the plant operation process.

The fundamental differences between the tasks of the two phases are also reflected in the software applications. Thus, for both phases, a multitude of heterogeneous software applications for different aspects exists. Examples for different aspects in the engineering phase are hardware, software, and field-device engineering. In the operation phase the aspects to be considered are monitoring, operation and control of the plant or even plant and fleet management and optimization. Some software applications are designed either for the engineering or the operation phase only. However, note that there are also combined software applications, which support aspects of both the engineering phase and the plant operation phase (e.g. the applicant's Siemens DCS SPPA-T3000) . Since different software applications have to use the same data they need to be able to communicate within one phase (i.e. within the engineering or operation phase) as well as across both phases (i.e. the results of engineering need to be communicated to operational systems in the form of configuration data, but also vice- versa for example in case of a plant modernization project) .

A consequence of such a heterogeneous software application landscape is that data related to the same item of a plant (e.g. data related to a water pump) is typically represented in multiple software applications. This is true for the engineering phase alone (e.g. configuration of data related to a water pump resides both in the hardware as well as the software engineering application) as well as for the operation phase alone (e.g. the operation time of a water pump is stored both in the distributed control system as well as in the asset management system) but also across both phases (e.g. the configuration data of a water pump is relevant for the operation of the distributed control system) . Note that due to the loose coupling of the different software applications inconsistencies may occur, which are hard to detect due to several reasons: (1) variables representing the same data may be named differently, (2) variables representing different data may have the same names or (3) variables representing the same data are named identically, but their values are encoded in different encoding systems .

Since there is no standard data model in the power generation domain, the software applications described above typically have different internal data models. For data exchange between software applications, data model converters are therefore needed. Building data model converters is difficult, since often both syntactic and semantic data transformation is necessary. Moreover, data transformations use overall system performance, which may be a critical issue in particular during the operation phase.

For the engineering phase two different approaches to solve these problems are known: (1) usage of a common or proprietary exchange data model and (2) usage of a metaengineering software application covering all aspects (in an optimal case) of the engineering phase.

The first approach provides an exchange data model that is understandable at least for pairs of software applications that need to communicate. The idea is to develop export- and import interfaces at the boundaries of the different software applications that can transform the internal representation of data in the format of the exchange data model (export) and vice-versa (import) . In general such exchange data models and formats are defined bi-laterally on a proprietary basis. In certain domains (e.g. in the automotive industry) there exists a common exchange data model that can be used by all software applications. However, note that in the engineering phase the use of an exchange data model can only decrease the number of inconsistencies but fails to eliminate them for several reasons. A main problem is that with loose coupling of the software applications by an exchange data model inconsistencies resulting from concurrent engineering in different software applications can generally not be avoided, since the engineering changes are isolated within the different software applications (i.e. concurrent changes are not synchronized automatically during engineering) . Therefore inconsistencies between multiple engineering software applications can only be detected through active communication. Moreover, while an exchange data model can help to detect inconsistencies through active communication, conflict resolution can only be done semi -automatically, i.e. with user- interaction . More specifically, in case of conflicts during import, it has to be decided which version to take (the local or the imported one) . If the local version is selected, the transfer back to the other software application is not guaranteed and inconsistencies may last forever. If the imported version is selected, valuable and correct local data may be overwritten, because the engineer of the other software application might not be aware of the consequences in the second software application. Finally, the use of an exchange data model does not ensure that communication with all relevant software applications has been taken place, i.e. that all engineering software applications working on the same entities have received the notification of an update of the engineering data. However, to assure an efficient, integrated engineering across all software applications, constant communication (including semi-automatic conflict resolution) of the engineering changes is necessary, leading to a considerable increase of the associated engineering costs.

The second approach to solve the above mentioned problems is to provide a meta-engineering software application. The idea of a meta-engineering software application is to manage all aspects (in an optimal case) of the engineering phase in one place. To this end meta-engineering software applications have a special proprietary data model, which is generic enough to allow modeling all aspects of the engineering phase.

This approach has several issues: First, in reality there is no meta-engineering software application that covers all aspects of the engineering phase. Therefore, the definition of an exchange data model for communication with the remaining software applications including the provisioning of corresponding interfaces is still necessary to cover all aspects of the engineering phase. This is particularly true for communication across the two lifecycle phases (i.e. communication of the results of engineering to operational systems and vice-versa) . Second, for the special case of combined software applications supporting aspects of both the engineering as well as the plant operation phase (e.g. the applicant's Siemens DCS SPPA-T3000) meta-engineering software applications need to have the possibility to integrate or plug- in the business logic of the combined software application. Third, the generic approach of the meta- engineering software application leads to huge configuration efforts for the software application itself, both w.r.t. the internal data model and w.r.t. the corresponding business logic. Fourth, as there is no or nearly no generic data model of the meta-engineering software application itself available, the same meta-engineering software application needed in slightly different environments (e.g. differing by one subsystem or different plants even with the same software application chain) is configured differently, so that a data and library exchange between different installations is not possible. Fifth, multi-user configurations are problematic, as users who want to work on different aspects of an object, i.e. on attributes which are not shared between subsystems, are hindered, as normally the complete object is either locked or different versions are created, which have to be merged later. Finally, inconsistencies between the different software applications are not completely eliminated, because often small and fast needed changes (e.g. during commissioning) are made in the engineering software applications of the subsystems, because the ex- and import mechanism takes too long. In this case the second approach has the same problems as the first approach.

Therefore, the invention is related to the problem of providing a flexible, consistent, performance-optimized and efficient method for an integrated data handling in a plant which is engineered and operated by several heterogeneous software applications.

This problem is solved inventively by a method comprising the steps of (1) providing a common data model (CDM) that is used for data exchange between at least two software applications, (2) managing of the common data by a configuration data service (CDS) , (3) managing of data specific to a single software application by a respective application specific configuration data service (App-CDS) that is assigned to a number of applications.

The invention is based on the consideration that the abovementioned problems can be solved by a CDM with a CDS managing the shared data, which is shared between software applications, combined with application- specific App-CDSs managing data specific to single software applications. Shared data represents data on an entity (same instance) that is modified or used in multiple applications (e.g. engineering of a specific water pump in the hardware and software engineering application) . Note that the CDS does not need to contain the union set of all data models of the communicating software applications, but the (potential) intersection set of all data models, leading to high efficiency. Furthermore, the coupling between the CDS and the App-CDSs guarantees consistency across all connected software applications . By definition the CDM advantageously includes no data, which is specific to a single software application only. Thus the model only describes that part of the data that is shared between at least two software applications. Data, which is only used by a single software application, will not be part of the CDM. Therefore the CDM is very stable, because the intersection set is much more resistant against data model changes in the connected software applications as well as against the addition of new software applications than a union set. Therefore extension of the CDM is required only infrequently. For the same reasons the CDS is quite simple and does not need extensions for the business logic of the connected software applications. The business logic remains entirely in the corresponding software applications.

The CDM defines a meta-model for objects and their relationships commonly used in the power generation domain. In particular, advantageous embodiments of the CDM comprise data types and/or telegram structures of said shared data. Thus, the CDM defines the structure of the shared data for all connected software applications. As part of the CDM system keys and/or user keys are also modeled. With those keys each instance of an object can be addressed unambiguously. The CDS manages the keys and guarantees the uniqueness of all system- and user-keys of all shared data over all software applications.

In a further advantageous embodiment, the communication from the CDS to any App-CDS is limited to the part of the CDM that is relevant to the respective software application. This limitation is implemented by an application- specific aggregate profile defining the relevant object types and/or attributes. By definition an aggregate profile represents the application-specific subset of the CDM.

Vice-versa, in a further advantageous embodiment, the communication from any App-CDS to the CDS is limited to the shared data, i.e. data that is modeled in the CDM. This limitation is implemented by the App-CDS, which can determine, upon change of data in a software application, whether the data is part of the shared data. Only if an update affects shared data, the update is communicated to the CDS. In contrast, if an update affects application- specific data only, no communication to the CDS is initiated.

There are two preferable possibilities to share data between the CDS and an App-CDS: (1) sharing by aggregate profile, and (2) sharing by concrete instance.

In a first advantageous embodiment the App-CDS can subscribe to a set of objects and attributes by communicating an aggregate profile. Whenever an instance of an object contained within the aggregate profile is created, updated or deleted, the CDS notifies the App-CDS upon change.

In a second advantageous embodiment the App-CDS can limit the communication of shared data to a number of concrete instances. These instances do not need to be part of the aggregate profile. In other words an App-CDS can explicitly share data of a concrete instance with the CDS, which is not part of the aggregate profile, as long as the data type is part of the CDM. Note that with this approach only the selected instances of this data type are communicated, while with the previous approach all instances of the data type are communicated .

After sharing the changed data with the CDS, the method preferably comprises the further steps of writing, by the CDS, the changed data to a common data store (CDS-DS) , determining, by the CDS, which App-CDSs share said changed data with the CDS, and sending, by the CDS, said changed data to said determined App-CDSs. Note, that the CDS-DS is essentially a database (where the data model is defined by the CDM), which stores the shared data. In other words: The CDS stores the changed data in the CDS-DS and informs all App-CDSs which actually share an object or attribute of an object upon update, and distributes the changes to the corresponding App-CDSs.

At the respective App-CDS the method preferably comprises the further steps of providing a user of a software application with a choice of accepting or rejecting the changed data, upon accepting the changed data by the user, writing, by the App-CDS of said application, the changed data into its local data store (LDS) , upon rejecting the changed data by the user, sending the respective local version of the changed data as new changed data to the CDS. Thus, the system does not enforce a synchronization of changed shared data immediately, but allows for temporary local inconsistencies to give the user of the other software applications still control over the configuration of his subsystem. The CDS therefore guarantees consistency between all software applications in a manner that allows temporary inconsistencies, but informs the user at each point in time exactly about the inconsistencies and how he can correct them. However, objects in said LDS that comprise the changed data preferably are blocked from any further changes until said choice has been made by said user. This ensures that local inconsistencies are not further increased by additional changes .

Data exchange for engineering and operation in a power plant is preferably controlled by the described method.

A CDS preferably comprises means enabling the CDS to interact according to the described method. In particular, the CDS guarantees the uniqueness of all system- and user-keys of all shared data over all software applications, locks objects system-wide beyond software application limits, if a shared attribute is engineered in one of the engineering software applications and informs all App-CDSs which actually share an object or attribute of an object, if this object or attribute of an object was changed, and distributes the changes to the corresponding App-CDSs. The CDS does not perform any engineering business logic specific to an engineering software application, but only performs business logic related to the CDM and its consistency. An App-CDS preferably comprises means enabling the App-CDS to interact according to the described method. In particular, the App-CDS requests unique keys for a potentially shared object from the CDS in case of creating such an object, locks the object software application-wide in case a non- shared attribute is changed, or requests locking across all software applications from the CDS in case a shared attribute is changed by its software application. The App-CDS further sends changed attributes from potentially shared objects to the CDS and requests system-wide unlocking of the potentially shared object. The App-CDS holds a copy of potentially shared objects in its LDS, which may be enriched with additional non-shared attributes specific to the software application and contains the engineering business logic of the software application and guarantees the consistency of the application specific data model and the instances therein.

A power plant preferably comprises such a CDS and one or multiple App-CDSs. The advantages achieved by means of the invention, in particular by providing a CDS managing a CDM and the instances therein and App-CDSs managing the subsystem specific data models (including the instances therein) , particularly comprise a very high stability of the CDM, because the intersection set is much more resistant against data model changes in the subsystems as well as the addition of new subsystems than a union set. Therefore, extension of the CDM is required only infrequently. For the same reasons the CDS is quite simple and does not need extensions for the business logic of the connected software applications. The business logic remains entirely in the corresponding software applications. Software applications remain quite autonomous and local engineering is performed, which especially is important for fast changes (e.g. in commissioning), but inconsistencies are tracked and can easily be fixed by the user . There are no hidden or undetected inconsistencies. An uncontrolled divergence of the application specific data models is prohibited. The system does not enforce the overwriting of maybe meaningful local data by an engineering operation of a different subsystem, because a local engineer can check the change before accepting it.

Locking of data across all software applications is only performed in case that actually shared data are changed - otherwise only the corresponding engineering software application is affected. Therefore, users changing application specific data will not negatively interfere with each other, if they work on different software applications. This avoids the locking problem of meta-engineering software applications .

Third party software applications which are not compatible with the CDS and do not implement a specific App-CDS can be easily adopted and integrated. An App-CDS for such a third party software application can be developed and by specifying an adapter (implementation for accessing the data of the third party application) , the data to be exchanged with other applications can be communicated. Depending on the capabilities of the third party software application it might also be possible to directly integrate the adapter into the business logic of the software application.

The system also provides a direct response for conflicts when objects or attributes get changed. This helps to plan modifications for other systems and to inform other experts.

Embodiments of the invention are explained in the following figures, wherein: shows a schematic view of different software applications in a power plant, shows a pump in a power plant with different applications associated with the pump, shows a schematic of the data sets of the software applications , shows the data structure in a power plant, and shows a diagram of an actual data sharing process.

Same reference numerals designate same parts in all figures.

FIG 1 shows a schematic view of a power plant 1 with different, loosely coupled applications or subsystems 2, 4, 6, interconnected via a network 8. In general, one can distinguish operation applications 2, 4, 6, which control the system at runtime, and engineering applications 2, 4, 6, which are relevant for configuration and parameterization of a system before using it in a productive environment. On the configuration side, there are, for example, engineering applications 2, 4, 6 for fleets, engineering applications 2, 4, 6 for the plant infrastructure, and engineering applications 2, 4, 6 for parameterization of the automation software used. On the other hand, at runtime, there are applications 2, 4, 6 for the control of a fleet or a plant, as well as simulation and training applications 2, 4, 6. Many applications 2, 4, 6 provide both engineering and operation functionality .

Each of the different software applications for plant operation has been configured with a different engineering software application. The different software applications 2, 4, 6 are usually only loosely coupled and share information based on proprietary interfaces. However, in practice, the different software applications 2, 4, 6 represent information on the same objects within a power plant. A simple example is shown in FIG 2 that shows the object of a pump 10, which has a representation 12 in the hardware engineering software application 2, in the software engineering software application 4 and in the asset management software application 6.

In the hardware engineering software application 2, for example, the cable connections and the location within the power plant 1 is denoted, while in the software engineering software application 4, for example, the control parameters are defined. An asset management software application 6, on the other hand, contains, for example, information on the maintenance status and the total uptime. While the different software applications 2, 4, 6 store different pieces of information on the entity "pump" 10, all of the software applications 2, 4, 6 share the name and the identifier of the pump 10. While the different software applications 2, 4, 6 store specific information on the pump 10, they also store some common information that is relevant to all software applications 2, 4, 6.

FIG 3 shows a sketch of the relationship of the different data models 14, 16, 18 using three different example software applications 2, 4, 6. It can be seen that the data models 14, 16, 18 of the different applications have an overlap 20 (shaded) . At the same time, there are also certain parts of the data models 14, 16, 18, which are only used by a single application 2, 4, 6. The CDM described defines the data that need to be exchanged between the different applications 2, 4, 6. As a consequence, only the overlap 20 of the different data models 14, 16, 18 is described and each application 2, 4, 6 can still contain "private" information, outside of the CDM. The motivation for this is to obtain a stable model, because the intersection set is much more resistant against data model changes in the connected software applications as well as against the addition of new software applications than a union set. From FIG 3 it can be seen that the CDM contains those parts of the information, which are shared or used by at least two applications 2, 4, 6. The remaining part of the information is beyond the scope of the CDM. A main advantage of focusing on the shared information is that the different applications 2, 4, 6 remain independent of each other and can still define their own "private" extensions of the model .

The CDM defines shared objects, i.e. objects that are exchanged between the different software applications 2, 4, 6. As shown in FIG 3, the different software applications 2, 4, 6 have partially overlapping data models 14, 16, 18. The CDM represents the overlap 20 of the data models 14, 16, 18 of the different software applications 2, 4, 6 in a power plant 1. The model does not represent the union of the data models 14, 16, 18 of all software applications 2, 4, 6. Besides providing a basis for data exchange, the CDM allows the description of the general structure of a power plant 1. The central object "unit" and its specializations allow the definition of a hierarchy starting from the company level over a fleet level down to a functional complex or a functional group complex.

The CDM also defines a unique addressing schema and supports effective communication mechanisms between applications 2, 4, 6. The CDM allows for alignment with general standards such as the "Common Information Model" (CIM) and IEC standards. While the standards alone are not sufficient, the combination of the CDM and the general standards allow for integration with third party products.

The CDM defines a meta-model for objects and their relationship commonly used in a power generation domain. Especially data types and telegram structures of the exchanged life data as well as the system- and user-keys (unique identifiers) of shared objects (addressing purpose) are part of the CDM. The objects can be further extended within the software applications by private object types and attributes. These application-specific extensions are unknown to the CDM and only accessible within the corresponding software application. However, since the general model is defined by the CDM, the CDS can handle instances of them. This enables the applications 2, 4, 6 to work on the same instance .

FIG 4 shows the data structure in a power plant 1 with several applications 2, 4, 6. The CDM 22 is managed by a CDS 24. App-CDSs 26 manages the subsystem specific data models 14, 16, 18 (including the instances therein). The CDS 24 guarantees the uniqueness of all system- and user-keys of all shared data over all subsystems, locks objects system-wide beyond subsystem limits, if a shared attribute is engineered in one of the software applications and informs all App-CDSs 26 which actually share an object or attribute of an object, if this object or attribute of an object was changed and distributes the changes to the corresponding App-CDSs 26. The CDS 24 does not perform any business logic specific to a software application, but only performs business logic related to the common data model 22 and its consistency.

The App-CDSs 26 request unique keys for a potentially shared object from the CDS 24 in case of creating such an object, lock the object software application-wide in case a nonshared attribute is changed, or request locking across all software applications from the CDS 24 in case a shared attribute is changed by its software application. The App- CDSs 26 further send changed attributes from potentially shared objects to the CDS 24 and request system-wide unlocking of the potentially shared object. The App-CDSs 26 hold a copy of potentially shared objects in their own data model 14 ,16, 18, which may be enriched with additional nonshared attributes specific to the software application and contain the engineering business logic of the software application and guarantee the consistency of the application specific data model 14, 16, 18 and the instances therein. Sharing objects between the CDM 22 and the application specific data models 14, 16, 18 can be done in two ways: The first possibility is that the App-CDS 26 hands over an application specific data model profile to the CDS 24, in which all data types and attributes are listed, which are shared with the CDM 22. Each instance with the attributes that fits to the profile are shared between the CDS 24 and the App-CDS 26 automatically. An example is a DCS with SW- Engineering, a HW-Engineering software application and field device engineering software application that are sharing analog measurements with their upper and lower limits via sharing by profile with the CDM 22 (and thus with each other) . The second possibility is that an App-CDS 26 can explicitly share an instance with the CDS 24, which was not declared in the profile, as long as the data type itself is shared. In this case only the selected instances of this data type are shared, but not all instances of this data type. An example is a fleet management software application that shares a specific output signal of a DCS e.g. the actual produced power of a certain power plant with the CDM 22 via sharing by instance and thus with the DCS software application (but not thousands of other output signals, which are not used in the fleet management) . During operation the fleet management can subscribe the actual power values via the shared output signal (address information) .

FIG 5 shows how the sharing of data is done: A user at application 2 changes 28 a shared object and commits the changes, i.e. writes the changed data finally to the data model 14 of application 2. The App-CDS 26 of software application 2 writes 30 data to its LDS 14 and sends 32 them to the CDS 24. The CDS 26 writes 34 changed data to the CDM 22 and sends 36 changed data to all other App-CDSs 4, 6, which share this data with the CDM 22. Users at other applications 4, 6, which share this data, are informed 38 via the corresponding App-CDSs 26, that a shared data relevant for them has been changed. They can perform the following actions:

- Accept 40 the change: Changed data from the CDM 22 are transferred to the local data model 16, 18 by the corresponding App-CDS 26.

- Reject 42 the change: The previous version of the local data model 16, 18 is written as changed by the App-CDS 26 and the CDS 24 to the CDS-DS 22. Afterwards all other App-CDSs 26 (including that of software application 2) which shared this data are getting the changed values.

- Do nothing 44 : The message and the inconsistency remain until the change is finally accepted or rejected. However, a further engineering of this object in this application 4, 6 is only possible after the change has either been accepted or rejected, so that further inconsistencies are avoided.

List of reference numerals

1 power plant

2, 4, 6 application

8 network

10 pump

12 representation

14, 16, 18 data model

20 overlap

22 common data model

24 configuration data service

26 application specific configuration data service

28 change

30 write

32 send

34 write

36 send

38 inform

40 accept

42 reject

44 do nothing