Standardized Data Exchange of Process Control Elements between Tools of Control Technology and Plant Design
Standardizations can only mature through continuous feedback of experiences gained from practical application. However, for financial reasons, tool manufactures typically wait for a matured standard before they equip their software with exporters and importers. This means that both, the feedback of practical experiences into the standardization process and the necessary implementations of manufacturers are disrupted. Thus, the standardization process remains in a deadlock. As a result, an overall “world model” for all engineering-data has not been realized to this day.
Instead of initiating a “world model of engineering”, the GMA-expert committee 6.14 “Integrated Engineering in Process Control Technology” has followed a more agile standardization method since the beginning of 2014. This method is based on the following requirements:
- “Only transfer required data”: In the GMA-FA 6.16 only the process control element is regarded and realized as a whole starting with the data model and ending with the eventual implementation in tools. This “transfixing” shall verify the efficiency of the standardization method and make it usable for process control elements at the same time.
- “Stepwise standardization”: The stepwise standardization is realized by only considering the process control element at first and by integrating it into the data exchange process. Additional artifacts may be included at a later stage. Proprietary data models are thus replaced by standards in a stepwise manner. Each step is both, usable and useful.
- “Object orientation”: The data modeling is realized by means of a class model. The specific structure of the object “process control element” together with its attributes can be found in section Model.
- “Transfer neutral and private data in one package”: The GMA-FA 6.16 decided to choose a data format which would allow the joint transfer of neutral- (standardized) and private (non-standardized) data in one data file. The private data can (optionally) be interpreted project-specifically by the receiver.
- “Using existing standardization approaches”: The GMA-FA 6.16 has compared a series of available approaches for modeling data. After evaluating these approaches the decision was made to adopt the data format AutomationML , . The contents of this data model are largely shaped by the attributes of NE 150. The end result of this development work is a class library for the process control element in AutomationML. Alternatives like pure XML, XMPlant or OWL according to ISO 15926 were dropped due to practical considerations concerning the set timeframe (10 months).
- “Agile and shared standardization approach”: The level of interest that was expressed by manufacturers and users with regard to this initiative emphasizes the strong need for innovations within the environment of standardizations. Within the GMA-FA 6.16 five CAE-Tool manufacturers, six control system suppliers, five users, three universities and two associations continuously cooperate, which ensures broad exchanges of experience as well as a balance of interests.
AllocationCopyright: © PLT Aachen
By functioning as an interface between process control and the actual process, the process control element is of central importance during the operation and engineering of a plant. The process control element is processed by different sections and subsections during the engineering- and reengineering processes. The different sections also make use of different tools. For this reason, data exchanges are required between the tools of the different sections, which make the use of importers and exporters necessary. Since these sections are working in parallel, the data exchange must be bidirectional.
ModelCopyright: © PLT Aachen
The attribute list of NE150 was the starting point for the work on data modeling. These attributes cover the exchanged entries of the “confi-lists” that are used in practice. In NE150 it was determined that the exchange shall occur by means of XML. An object-oriented data modeling is very useful in this context since this type of modeling can exploit the advantages of XML. Thus, the GMA 6.16 first determined the required classes and then assigned the attributes of NE150 to those classes including the corresponding data types and units.
The figure depicts the result in UML-notation: the class-model of the process control element.
- A Process control element often contains precisely one PCE-function but it can also include a loop with multiple PCE-functions. The PCE-function (IEC62424: PCE-category) is typically characterized by the first letter of the typical-identification (e.g. “F” for flow rate or “P” for pressure). A list of possible first letters and the corresponding meaning is included in IEC 62424.
- Each process control element is composed of at least one PCE-partial function (IEC 62424: PCE-processing function). The partial functions are usually characterized by the subsequent letters of the typical-identification. The data model describes them with the help of one individual class per partial function. Moreover, the data model supports the following processing functions in the first step: IndicationBinary, IndicationAnalog, Control, Actuator, Registration, Alarm, Switch, Manipulation and Calculation. This class library is not definitive and can of course be expanded.
- Additionally, each process control function contains precisely one software-signal which models the technically interpreted signal (e.g. the fill level 0..1 m). All PCE-partial functions relate to this “strain-software-signal”. Thus, switching functions are initiated once a defined value is exceeded or undershot. In regular cases one hardware signal (e.g. 4..20 mA) is assigned to the afore-mentioned software signal. This relation defines the conversion from 4..20 mA to 0..1 m. However, PCE-functions with multiple or no hardware signals are also conceivable for example when dealing with redundancies or soft-sensors. Some partial functions may also possess their own software- and hardware signals for circuits, controller outputs, etc.
The main advantage of this modeling approach is that all partial functions are represented by individual classes rather than being implicitly defined by a letter sequence. Attributes of PCE-partial functions are bound to these classes. Control parameters can, for example, be retrieved and found at the controller partial-function. This simplifies the navigation between and the interpretation of data.
The modeling in AutomationML/CAEX was realized in a committee with the help of the AutomationML editor. For this reason, an AML-class library was created while the required classes where generated in order to map the model of the process control element accordingly. Thereafter, the attributes of NE150 were added to the generated classes. The UML classes PCE, PCEFunction and PCEPartialFunction are modeled in the AML-library. The UML class PCEPartialFunction and its characteristics are subordinated as child-elements. The respective attributes that are necessary for describing the generated classes are deposited at these UML classes. Thus, attributes of the control parameter are, for example, integrated in the class Control. In order to model the signals of a process control element, the interfaces were opened up as an InterfaceClass in the model. The signals can be separated into software- and hardware signals as prescribed by the process control element model. They also carry their respective attributes for their description.
The Model in Practical Use
The data model of a process control element that was created in the research project of the GMA FA 6.16 has already been successfully implemented by different manufacturers. During the NAMUR main conference in November 2014, the data exchange between the CAE-systems of Autotec (Engineering Base), ESP (ESPlan), Rösberg (ProDok) and Siemens (COMOS) as well as the control systems of ABB (800xA), Siemens (PCS 7) and Yokogawa (Centum VP) was also successfully presented.
For additional information please contact Andreas Schüller .
The text you find on this page is a translation of sections from the following article: