Equipment - Intergraph Smart P&ID - Administration & Configuration - Hexagon PPM

In Smart P&ID there is an abstract class for Equipment with four subclasses for Vessel, Exchanger, Mechanical and OtherEquipment. In the SmartPlant Schema, there are four PID equipment classes: PIDProcessVessel, PIDHeatTransferEquipment, PIDMechanicalEquipment and PIDProcessEquipment. The Tool Schema has a MapClass for each of the four equipment subclasses in Smart P&ID and another MapClass for the abstract Equipment class. The equipment type is defined using a three-level hierarchical enumerated list (Class, Subclass, Type).  In EF Schema the equipment type is defined using a seven-level hierarchical enum list (EqType0, … ,EqType6).

Hierarchical enumerated lists are used in Smart P&ID to identify equipment type, piping component type, instrument type, and so forth. Each item has several related properties (such as EquipmentClass, EquipmentSubclass, EquipmentType). When the user sets the value of a higher level property (such as EquipmentClass), the list of possible values for the lower level property (such as EquipmentSubclass) is constrained.

Publish – The four MapClasses map the corresponding equipment classes in Smart P&ID and the SmartPlant Schema. A Smart P&ID Vessel is published as a PIDProcessVessel; An Exchanger is published as a PIDHeatTransferEquipment, and so forth. The MapClass for Equipment does not play any role in the Publish operation.

The EF schema provides a relationship – called EnumMetadata – from an enum list value to an interface def. If we traverse this relationship from the lowest level EF schema equipment type value to the corresponding InterfaceDef, it allows us to find the most specialized interface that should be published for the given equipment object. The diagram below illustrates this relationship.

Example 1

When P&ID publishes an Exchanger object, the resulting EF object is a PIDHeatTransferEquipment object. This object will realize the IHeatTransferEquipment interface and all of the more general implied interfaces. Only one of the more specialized interfaces will be published. (An exchanger is either an air cooled exchanger or a shell and tube exchanger. It is never both.)

Example 2

This example shows how different interfaces are realized when publishing different Mechanical Equipment objects. When P&ID publishes a Mechanical object, the resulting EF object is a PIDMechanicalEquipment object. The properties that are published depend on the interface that the object realizes, as shown in the following examples of subclasses:

As a result, different properties are published for a pump and a motor. The EF Schema and Tool Schema configurations for these object types are shown for comparison in the mapping below.

A Driver is an Equipment subclass that is defined to contain the properties of the IEquipmentDriver interface, while a Pump is another Equipment subclass that is defined to contain the properties of the IPump interface.

The above mapping is customizable through the MetaData for enumerations within the EF Schema.

Retrieve – When a document is being retrieved, each incoming object is tested for identifying interfaces to determine what type of object it is. The object is first tested for the identifying interfaces for Vessel, Exchanger, Mechanical and OtherEquipment (for details, see the table under Retrieving. If the object has one of these identifying interfaces, it is retrieved as that specific type of equipment (using the MapProperties associated with the specific MapClass for that equipment class). If the object is not recognized by its interfaces as any of these specific equipment types, but it is recognized as Equipment, it is retrieved as generic equipment (using the MapProperties associated with the generic Equipment MapClass). Once a new equipment object is retrieved in Smart P&ID, the Equipment symbol used to represent this new object is determined according to the predefined symbol-identification mapping in the CatalogIndex.mdb file.