Basic CAEX mappings

CAEX supports object oriented concepts, e.g. classes and instances. Classes represent predefined typical object information, called “template” in the following text. Instances represent concrete object information and consider the instance as individual. Instance are also called “concrete” objects in the following text.

a) CAEX descriptions of templates for PCE requests, interfaces and plant hierarchy items A template for a PCE request and a SignalLine shall be predefined as each one CAEX RoleClass, e.g. “PCE_Request” and “SignalLine”. These predefined RoleClasses define standard attributes and standard interfaces required for the data exchange. An example for  a CAEX role class library is given in D.2.

A template for common interfaces shall be predefined as CAEX InterfaceClasses, e.g. “SignalSource”, “SignalSink”, “ActuatorSource”, “SignalNode”, “AlarmSource”, “SensorLink” and “IndicationSource”. An example for a CAEX interface class library is given in D.1.

A template for a plant hierarchy item may be predefined as CAEX RoleClass, e.g. “PlantHierarchyItem” which predefines typical properties of a plant hierarchy item. This definition is not in the scope of this st andard.

b) CAEX description of a concrete plant hierarchy item

A concrete plant hierarchy item shall be represented by a CAEX InternalElement with an optional association to a RoleClass “PlantHierarchyItem”. InternalElements may contain further InternalElements as nested objects. This allows for defining the desired breakdown structure.

c) CAEX description of a concrete PCE request

A concrete PCE request which is part of a certain plant hierarchy item shall be represented in CAEX as InternalElement within the plant hierarchy item with an associated RoleClass “PCE_Request”. The name of the InternalElement shall represent the name of the PCE request. The associated RoleClass “PCE_Request” delivers common attributes and interfaces. The concrete requirements for the PCE request and the required interfaces (attribute values) shall be stored in the RoleRequirements of the InternalElement. If  applicable, additional attributes and interfaces, which are not predefined in the RoleClass, shall be added here too.

NOTE In a later engineering phase, the same InternalElement can additionally be assigned to a corresponding SystemUnitClass which describes the concrete technical implementation of the PCE request. This is not in the scope of this standard. See A.2.9 for related CAEX concept details.

Figure 19 depicts the data model of a PCE request. A PCE request shall consist of 1…n interfaces and a set of attributes which may be extended by additional attributes and additional interfaces. Furthermore, common types of interfaces are presented.

Additional Attributes

Attributes PCE request

PCE category : char  Location : string AlarmInterface SignalInterface SignalSource SignalSink  Interfaces AlarmSource IndicationInterface IndicationSource PCE category : char 

Location : string 1..n 0..n 0..n ProcessConnectionInterface ActuatorSource SensorSink  Additional Interfaces 0..n Additional Attributes Attributes PCE request

PCE category : char  Location : string AlarmInterface SignalInterface SignalSource SignalSink  Interfaces AlarmSource IndicationInterface IndicationSource PCE category : char 

Location : string 1..n 0..n 0..n ProcessConnectionInterface ActuatorSource SensorSink  Additional Interfaces 0..n

Figure 19 – PCE request data model

Each concrete PCE request possesses at least either a SignalInterface or a ProcessConnectionInterface with respect to the signal output of its processing function. A PCE request without any interface makes no sense.

Each PCE request shall have the f ollowing attributes (mandatory):   – PCE category (see Table 2);

  – Location (Local, Local Panel, Central) .

Each PCE request should have 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 r elevant attributes are defined 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 - - `    , `  `  `    , `  `    , `  `  `  `    ,   ,   ,   , `  `    ,   , `  `    ,   ,   ,   , - `  - `    ,   , `    ,   , `    , `    ,   , `  - - -

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 either 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 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 named “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 “SideA” interface of the signal line, and a second InternalLink connects the signal line interface “SideB” with the sink interface of the s econd 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 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 t he RoleClass “PCE_Request” inherit the predefined interfaces of this RoleClass. Additionally required interfaces shall be additionally implemented by means of the CAEX element “ExternalInterface” within the corresponding I nternalElement.

Each defined alarming function (AH, A, ALL..) implements an additional AlarmInterface (source) 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 IndicationInterface 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&ID tool with respect to a process connection shall be mapped to attributes of the corresponding ProcessConnectionInterface. Each end of a process connection at a PCE request implements an additional ProcessConnectionInterface within this PCE request.

7.4.4 Mapping of a PCE request interface to an external interface of the