US 7702774 B2
A method for operating an object-based configuration system CS for field devices of automation technology, with a frame application FA, which serves for managing and instantiating a plurality of objects, wherein, to individual groups of device objects, field device types are assigned, which enable, as device managers, a configuration of the corresponding field device type. A first main object MO-1 is provided, which makes available a first object set OS-1 with device objects for a plurality of device types and instantiates, with the help of a first control engine, via an identifier ID, device objects of the first object set, in order to produce device managers for these field device types. Besides the first main object MO-1, a second main object MO-2 is provided, which has a second object set OS-2, wherein individual device objects of the second object set OS-2 are updated device objects of the first object set OS 1. Between the frame application FA and the main object(s) MO-1, MO-2, respectively, an intermediate layer I is provided, which selects, via a second control engine, that main object, which makes available the updated device objects for the selected device type, and which, following selection of the device type, transfers to the corresponding main object the identifier ID, in order to instantiate the updated device object.
1. A method for operating an object-based configuration system (CS) for field devices of automation technology, with a frame application (FA) which runs on a computer (CU), the frame application (FA) serving for managing and instantiating a plurality of objects, wherein to individual groups of device-objects are assigned field device types, which enable, as device managers, a configuration of a corresponding field device type, comprising the steps of:
providing a first main object (MO-1) from a device manager (A), which makes available a first object set (OS-1) with device objects for a plurality of device types;
instantiating, with the help of a first control engine, via an identifier (ID), device objects of the first object set, in order to produce device managers for its field device types;
providing besides the first main object (MO-1), a second main object (MO-2) from a device manager (B), which has a second object set (OS-2), wherein individual device objects of the second object set (OS-2) are updated device objects of the first object set (OS-1);
providing, between the frame application (FA) and the main object(s) (MO-1, MO-2, respectively) an intermediate layer I, which, via a second control engine, selects that main object which makes available updated device objects for a selected device type; and
following selection of a device type, transfers to the selected main object via an interface, an identifier (ID), in order to instantiate a corresponding device object.
2. A method as claimed in
the object-based configuration system corresponds to an FDT object model.
3. The method as claimed in
requests are forwarded transparently between frame application (FA) and main object (MO-1, MO-2).
4. The method as claimed in
the intermediate layer (I) is responsible only for instantiating the main objects (MO-1, MO-2).
The invention relates to a method for operating an object-based configuration system for field devices of automation technology, with a frame structure serving for managing and instantiating a plurality of objects, wherein to individual groups of device-objects are assigned field device types, which enable as device managers, a configuration of a corresponding field device type.
Field devices are commonly employed in automation technology (process automation/manufacturing automation) and serve for registering and/or influencing process variables. Examples of such field devices are fill level measuring devices, mass flow measuring devices, pressure- and temperature-measuring devices, pH- and redox-potential-measuring devices, conductivity measuring devices, etc. for process automation technology, which, as sensors, register the corresponding process variables, fill level, flow, e.g. flow rate, pressure, temperature, pH-value and conductivity value, respectively.
Serving for influencing process variables are actuators, e.g. valves, which control flow of a liquid in a section of pipeline, or pumps, which change fill level in a container.
A large number of such field devices are manufactured and sold by the firm ENDRESS+HAUSER®.
Frequently, field devices are connected with superordinated units via communication systems (PROFIBUS®, FOUNDATION-FIELDBUS®, HART®, etc.). Such superordinated units serve for process control, process visualization, device-management (configuration and servicing) and for plant management (asset management), using corresponding application programs.
The integration of field devices into such applications occurs via device descriptions. Device descriptions are provided by device manufacturers, in order that superordinated units can recognize and interpret the meaning of data supplied by the field devices.
Various device descriptions are known for the different fieldbus systems (HART-device-descriptions, Fieldbus Foundation device descriptions, Profibus device descriptions).
On the basis of cooperation of Fieldbus Foundation (FF), HART Communication Foundation (HCF) and Profibus Nutzerorganisation (PNO), an electronic device description (Electronic Device Description EDD) was created, which is defined in the standard IEC 61804-2.
With a large number of EDD-based fieldbus systems installed worldwide, EDD is a very widely used description language for device descriptions in automation technology.
For servicing field devices, corresponding servicing programs (operating tools) are necessary, which, in superordinated units, run either on their own (Endress+Hauser FieldCare, Pactware, AMS Fisher-Rosemount, PDM Siemens) or else are integrated into control system applications (Siemens PCS7, ABB Symphony, Emerson Delta V).
For a comprehensive servicing of field devices, newly, special device descriptions, so-called DTMs (Device Type Manager), are available, which correspond to the FDT (Field Device Tool) specifications. The FDT-specifications, serving as an industry standard, were developed by the PNO (Profibus Nutzer Organisation (Profibus User Organization)) in cooperation with ZVEI (Zentralverband Elektrotechnik-und Elektroindustrie (The German Electrical and Electronics Industry, a registered association)). The current FDT-Specification 1.2.1, including the Addendum for “Foundation Fieldbus” Communication, is available from ZVEI, PNO or the FDT-Group.
Many field device manufacturers already deliver corresponding DTMs for their field devices. The DTMs encapsulate all variables and functions of the pertinent field device and offer, most often, a graphical user interface for servicing the devices.
As run-time environment, the DTMs require a frame application (FDT-frame). The frame application and the corresponding DTMs permit, thus, a very comfortable access to field devices (e.g. to device parameters, measured values, diagnostic information, status information, etc.), as well as for invoking special functions, which individual DTMs make available.
The DTMs can be referred to as device objects, which, together with the frame application, represent an object-oriented configuration system for field devices of automation technology.
In order to keep the administration of device objects as simple as possible in superordinated units, the field-device manufacturers do not provide a separate DTM for each field device, but, instead, a main, or principal, object, which includes a plurality of device objects for individual field device types of the particular manufacturer.
If a malfunction occurs during the servicing of a field device, then the corresponding device object must be updated. An updating is also necessary, when the device receives new functionalities, which could not be accessed via the device object present until now.
Problematic is the integration of updated device objects into object-oriented configuration systems when main objects are being used. One possibility is to produce an updated device object and also a correspondingly updated main object. This means, however, a considerable test effort, since not only the updated device object must be tested, but, also, all other device objects of the relevant main object.
Another possibility is to generate, for the updated device object, an updated main object and to remove the not-updated device object from the original main object. There arises, along with the original device object, a completely independent device object. This, however, changes the modular structure of the configuration system and the user must institute considerable adaptations in its system.
Both alternatives mean for the operation of an object-based configuration system, in the case of updating of device objects, a considerable effort, either on the part of the device manufacturer or on the part of the user.
An object of the invention is, therefore, to provide a method for operating an object-based communication system for field devices of automation technology that does not have the above listed disadvantages and, especially, enables a simple integration of updated device objects.
This object is achieved by providing a first main object (MO-1), which makes available a first object set (OS-1), with device objects for a plurality of device types; instantiating, with the help of a first control engine, via an identifier (ID), device objects of the first set, in order to produce device managers for its field device types; providing, besides the first main object (MO-1), a second main object (MO-2), which has a second object set (OS-1), wherein individual device objects of the second object set (OS-2) are updated device objects of the first object set (OS-1); providing, between the frame application (FA) and the main object(s) (MO-1, MO-2), respectively) an intermediate level 1, which, via a second control engine, selects that main object which makes available updated device objects for a selected device type; and following selection of a device type, transfers to the selected main object an identifier (ID) in order to instantiate a corresponding device object.
An essential idea of the invention is to provide two main objects, with one main object being responsible for the integration of updated device objects, and to insert between the main objects and a frame application necessary for the running of the main objects, an intermediate layer, via which the existing and updated device objects can be selected.
In this way, updated device objects can be easily integrated into configuration systems, without requiring for the device manufacturer a greater test effort and for the user no greater adaptations, because the modular structure of the system was retained.
The invention will now be explained in greater detail on the basis of an example of an embodiment as set forth in the drawing, the figures of which show as follows:
For managing the project structure, each device manager and communication manager offers information via its Information interface. On the basis of this information, the frame application FA can accumulate catalog data K needed for managing the project structure. With the project structure, the frame application controls and manages also the communication paths.
The persistence of the project data is implemented by the frame application FA with the help of a Persistence interface, which are served by the device- and communication-manager instances.
Frame application FA forms, together with the device manager instances DTM1, DTM 2 and the communication manager instance DTMC, etc., an object-based configuration system CS for field devices of automation technology.
As already mentioned, the field device manufacturers make device managers available for their individual field devices. Before a field device can be accessed, the corresponding device manager, with all belonging objects, must be instantiated.
With the help of a corresponding identifier ID (Deltabar S), which is forwarded by the frame application FA to a main object MO, the main object instantiates the corresponding device object. For this, the main object MO has a factory mechanism.
The main object MO makes available an object set OS with a plurality of device objects for respective device managers. The object set OS can comprise e.g. all field device types supported by Endress+Hauser.
With the help of the main object MO, yet a plurality of other device objects can be instantiated.
The updated version of the main object MO(V2) is installed into the computer unit CU and replaces, thus, the old version of the main object MO, which is then no longer available.
With the main object MO being replaced by a new version, implicitly also all instantiated device managers, which do not represent the device type B, change. This alternative for integrating an updated device object requires on the part of the manufacturer of the main object a considerable test effort, since not only the device manager for the device type B must be tested, but also the device managers for all other device types supported by main object MO(V2). This test effort is especially difficult to provide, when device objects can be variably added.
For this, another main object MO-2 is produced, which is responsible for the instantiation of the updated device object B and contains the device object B in its object set OS-2. Device object B is, in such case, removed from the object set OS-1 of the main object MO.
The unchanged device objects are still instantiated via the original main object MO.
In the case of this alternative, two completely independent device managers A and B arise. A mutual influencing of the device managers is consequently no longer possible. However, the modular structure of the communication system CS changes fundamentally. Projects which contain the original device manager for device type B, can no longer, or only partially, be loaded and all device managers for the device type B must be manually exchanged, since no rules are known to the frame application FA for automatically bringing about this exchange. All data of the original device manager instances are, in such case, lost. Depending on number and dataset size of the originally instantiated device managers, a considerable configuration effort is necessary for the user, in order to effect this exchange.
The intermediate layer I decides which device object is instantiated via which main object.
If the user selects device A with the identifier ID(A), then the main object MO-1 and the device object A is instantiated.
If the user selects device B with the identifier ID(B), then, via the intermediate layer I, the main object MO-2 and the current device object B instantiated.
Now, two device managers A and B are present, with the device manager B containing the updated software version for the device object B. In this case, nothing changes in the modular structure of the object-based configuration system CS. As a result, also no configuration effort is necessary in the frame application FA. The frame application FA does not notice at all that a changed software object B was instantiated. An essential advantage resulting from this is an extremely lessened test effort. The influencing of the participating components is likewise minimal. Moreover, the integration effort required for a changed device object is minimal.