《IEC-62424-2008.pdf》由会员分享，可在线阅读，更多相关《IEC-62424-2008.pdf（140页珍藏版）》请在三一文库上搜索。
1、 IEC 62424 Edition 1.0 2008-08 INTERNATIONAL STANDARD Representation of process control engineering Requests in P 25.040.40 PRICE CODE ISBN 2-8318-9942-7 Registered trademark of the International Electrotechnical Commission Copyright International Electrotechnical Commission Provided by IHS under li
2、cense with IECLicensee=Boeing Co/5910770001 Not for Resale, 10/25/2008 03:21:03 MDTNo reproduction or networking permitted without license from IHS -,-,- 2 62424 IEC:2008(E) CONTENTS FOREWORD.6 INTRODUCTION.8 1 Scope.10 2 Normative references .10 3 Terms and definitions .10 4 Abbreviations .14 5 Con
3、formity15 6 Representation of PCE requests in a P any IEC National Committee interested in the subject dealt with may participate in this preparatory work. International, governmental and non- governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates clo
4、sely with the International Organization for Standardization (ISO) in accordance with conditions determined by agreement between the two organizations. 2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international consensus of opinion on the relev
5、ant subjects since each technical committee has representation from all interested IEC National Committees. 3) IEC Publications have the form of recommendations for international use and are accepted by IEC National Committees in that sense. While all reasonable efforts are made to ensure that the t
6、echnical content of IEC Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any misinterpretation by any end user. 4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications transparently to the maximum
7、extent possible in their national and regional publications. Any divergence between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter. 5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible fo
8、r any equipment declared to be in conformity with an IEC Publication. 6) All users should ensure that they have the latest edition of this publication. 7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and members of its technical commit
9、tees and IEC National Committees for any personal injury, property damage or other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC Publication
10、s. 8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is indispensable for the correct application of this publication. 9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of patent
11、 rights. IEC shall not be held responsible for identifying any or all such patent rights. International Standard IEC 62424 has been prepared by IEC technical committee 65: Industrial-process measurement, control and automation. This standard cancels and replaces IEC/PAS 62424 published in 2005. This
12、 first edition constitutes a technical revision. The text of this standard is based on the following documents: FDIS Report on voting 65/420/FDIS 65/428/RVD Full information on the voting for the approval of this standard can be found in the report on voting indicated in the above table. This public
13、ation has been drafted in accordance with the ISO/IEC Directives, Part 2. Copyright International Electrotechnical Commission Provided by IHS under license with IECLicensee=Boeing Co/5910770001 Not for Resale, 10/25/2008 03:21:03 MDTNo reproduction or networking permitted without license from IHS -,
14、-,- 62424 IEC:2008(E) 7 The committee has decided that the contents of this publication will remain unchanged until the maintenance result date indicated on the IEC web site under “http:/webstore.iec.ch“ in the data related to the specific publication. At this date, the publication will be reconfirm
15、ed, withdrawn, replaced by a revised edition, or amended. A bilingual version of this publication may be issued at a later date. Copyright International Electrotechnical Commission Provided by IHS under license with IECLicensee=Boeing Co/5910770001 Not for Resale, 10/25/2008 03:21:03 MDTNo reproduct
16、ion or networking permitted without license from IHS -,-,- 8 62424 IEC:2008(E) INTRODUCTION Efficient process engineering requires highly sophisticated tools for the different needs of the involved work processes and departments. These engineering tools are normally specialized in Process Design (PD
17、), in Process Control Engineering (PCE), etc. Therefore a working interoperability is essential to optimize the engineering process in total. Thus, the definition of a harmonized interface and data management is a core task to ensure a smooth workflow during the whole project and to guarantee data c
18、onsistency in the different tools. This standard defines procedures and specifications for the exchange of PCE relevant data provided by the Piping and Instrumentation Diagram (P it shall not allow unguided automatic changes. The configurable checking step shall include functionality for automatic o
19、r manual acceptance of data changes, allowing single decisions up to bulk data management. All changes in the proprietary database and all discovered data inconsistencies shall be reported by the import application. The generation of the report shall be configurable. The import/export application ha
20、s to assure that the intersection of the different databases contains the same information, and that additional division specific data is handled in a consistent way. Data manipulation by a project division is an ongoing process during the whole project and beyond it. Thus the creation, changing and
21、 deletion of data shall be possible during the life-cycle of the plant. CAEX databases have to be consistent. This requires a consistency check before exporting the data. This procedure has to be followed after a successful data manipulation in a P 2) mandatory fields being filled in; 3) correct use
22、 of numbering system of the PCE requests. Inconsistent data shall not be exported. b) generate PCE relevant information; c) check for changed information in comparison with previously stored data in the neutral database; d) renaming of PCE request shall be supported by the export functionality; e) p
23、erform data export from proprietary into neutral database: 1) e. g. if the PCE request has been changed, the old PCE request within the neutral database has to be deleted and the new one shall be exported from the proprietary database into the neutral database. The old PCE request information shall
24、be stored in a backup storage system; 2) Other changes shall be performed with the existing object. f) generate reports after each data exchange: e. g. new PCE requests list, missing PCE requests list, changed PCE requests list, deleted PCE requests list, problems and error list. Data import from ne
25、utral database into the target database shall comprise the following activities: g) generate PCE relevant information from neutral database; h) check for changed information by comparing the neutral database with the target database; i) perform data import from the neutral into the proprietary datab
26、ase; j) renaming of PCE request shall be supported by the import functionality; k) generate reports after each data exchange: 1) e. g. error lists; 2) inconsistencies due to imported data shall be detected by the target application during the import process and are not considered within this standar
27、d. 6 Representation of PCE requests in a P b) the graphical representation of PCE requests in a P c) the type of functional connection between the PCE requests: the control functions; d) the graphical representation of signals in a P Location (Local, Local Panel, Central). Each PCE request should ha
28、ve one or more of the following attributes (optional): PU vendor (string); Typical identification (string); Device information (string); Processing function (string) (see Table 3); GMP relevant (Boolean); Safety relevant (Boolean); Quality relevant (Boolean). Additional PCE relevant attributes are d
29、efined in Clause 8. The graphical symbol for a PCE request bubble or hexagon carries no additional information and is not mapped to the CAEX-Model. d) CAEX description of concrete signal lines Copyright International Electrotechnical Commission Provided by IHS under license with IECLicensee=Boeing C
30、o/5910770001 Not for Resale, 10/25/2008 03:21:03 MDTNo reproduction or networking permitted without license from IHS -,-,- 62424 IEC:2008(E) 31 CAEX provides two concepts in order to map signal lines. A signal line between two PCE requests of the same plant hierarchy item is described with CAEX eith
31、er by means of an InternalLink of the superior plant hierarchy item which directly links the corresponding interfaces of the two PCE requests. InternalLinks do not support properties, therefore they can only represent simple relations. An example for those signal lines is given in Annex D.3. Or the
32、signal line is represented as a CAEX object for itself. If the SignalLine is considered as an object for itself with its own properties, this shall be represented as a CAEX InternalElement with an associated RoleClass “SignalLine”. A signal line implements two external interfaces which shall be name
33、d “SideA” and “SideB”. The connection between two PCE requests is modeled by means of each, an InternalElement for both PCE requests and, another InternalElement for the SignalLine. Furthermore, two InternalLinks have to be defined: One InternalLink connects the source PCE request interface with the
34、 “SideA” interface of the signal line, and a second InternalLink connects the signal line interface “SideB” with the sink interface of the second PCE request. A signal line between two plant hierarchy items of the same level shall be described in CAEX in the same way as signal lines between two PCE
35、requests, linking the corresponding interfaces of the two plant hierarchy items. An example for those signal lines is given in Figure 20. e) CAEX description of concrete interfaces Interfaces allow the definition of relations between objects. PCE requests associated to the RoleClass “PCE_Request” in
36、herit the predefined interfaces of this RoleClass. Additionally required interfaces shall be additionally implemented by means of the CAEX element “ExternalInterface” within the corresponding InternalElement. Each defined alarming function (AH, A, ALL) implements an additional AlarmInterface (source
37、) within the PCE request. Each defined additional switching function (SH, SHH,SL,ZH,) implements an additional SignalInterface (source) within the PCE request. Each defined indication function (I, O, OH, .) implements an additional IndicationInterface. NOTE The function OSH creates an IndicationInte
38、rface and a SignalInterface as well. f) CAEX description of concrete process connections Process connections are outside the scope of PCE and are not mapped to the CAEX model within this standard. All additional information given by the P b) working with classes only: The desired plant hierarchy is
39、defined by a single InternalElement in the InstanceHierarchy. This InternalElement references a complex SystemUnitClass which comprises the complete system description including the plant topology, units, components, attributes etc. This workflow is of interest if the plant or unit structure to be s
40、tored in CAEX is a standard solution and is intended to be used several times; c) mixed workflow: This is the typical workflow for practical use. Typical components are defined as SystemUnitClasses; sub-structures of the SystemUnitClass are defined by aggregation of objects as InternalElements. Attr
41、ibutes may be predefined, default attribute values may be set. The InstanceHierarchy is being used for the plant topology definition. In the next step, each defined internal hierarchical element can be associated with a RoleClass in order to define the requirements to this object. Finally, Copyright
42、 International Electrotechnical Commission Provided by IHS under license with IECLicensee=Boeing Co/5910770001 Not for Resale, 10/25/2008 03:21:03 MDTNo reproduction or networking permitted without license from IHS -,-,- 62424 IEC:2008(E) 41 it can be associated to a SystemUnitClass that describes t
43、he technical implementation of the object. The following CAEX properties are normative in addition to the CAEX schema. All CAEX objects that have a name (classes, instances, interfaces, attributes etc.) shall have a unique name among all siblings in the same level of the corresponding object tree. T
44、his shall assure that referencing a class, an interface, an attribute or an instance by its path delivers a unique result. The CAEX schema definition allows automatic proof of correct CAEX syntax. The CAEX conformity requires conformity to the CAEX schema and additional normative properties which ar
45、e separately described in this standard. CAEX does not provide semantic checks, data consistency checks or data plausibility checks. CAEX is a static data exchange format; the validity of stored data is objective of the source tool or objective of the corresponding exporter/importer tool. A.2.2.2 St
46、orage of version information All CAEX objects share a subset of generic version information which is defined in the CAEX type “CAEXBasicObject”. All CAEX elements are derived from this type or derivations of it. These properties are useful if the data exchange procedure happens several times. For a
47、detailed CAEX data definition, see A.3.14. The data type definition is characterized by the following properties: ChangeMode: This optional attribute is intended to give information about the change state of an object compared to a previous data exchange. Valid values of ChangeMode are defined in CA
48、EX, they are “state”, “create”, “delete” and “change”. The value “state” shall be used for objects that have not changed since previous data exchange. The value “create” shall be used for objects that have changed. The value “delete” shall be used if an object is to be deleted. The object is therefore not physically removed out of the CAEX file but marked as to be deleted. The value “change” shall be used if the object has changed. The ChangeMode is only valid for the item itself. If e.g. an attribute has changed its value, only the value is marked with the ChangeMode value