A common theme of data modeling is to discover similar concepts and develop a pattern that may then be applied whenever another similar concept occurs. The SmartPlant schema has many underlying patterns that can be identified and used by schema developers.
Abstraction Patterns
The abstraction patterns are based on abstracting one or both ends of a relationship. This abstraction eliminates direct dependencies between interfaces and promotes a flexible object model.
Collection Pattern
A collection pattern is used for many-to-many relationships in which a collection interface contains collection members as shown below.
If abstraction is done on the left side of this relationship, the interface on that side is I<member type>Collection where <member type> identifies the type of members in the collection, such as IModelItemCollection for a collection of ModelItems. The relationship is named the same as the interface with the leading I removed.
If abstraction is done on the right side, then the interface on that side is named I<collection type>Member where <collection type> identifies the type of collection, such as IInstrumentLoopMember. The relationship is named based on the member interface.
LinkCollection Pattern
If a collection pattern has a link class, such as the following example:
then the pattern is as shown below:
In this pattern, which is typical for many-to-many relationships with link attributes, the cardinalities of both relationship definitions are one-to-many with the many side existing on the intermediate link class. The various interfaces involved are abstracted similarly to that for the collection pattern with the addition of the word Link before Collection and before Member. The intermediate interface is named based on the type of members, such as IModelItemLink for a collection of ModelItems.
If the abstraction is on the left side of a collection pattern, the interface name on the left is I<member type>LinkCollection and the left relationship is same name without the leading I. In this case, the I...Link interface is I<member type>Link and the relationship on the right is Link<member type>.
If the abstraction is on the right side, the same rules apply as for the collection pattern. The interface on the right becomes I<collection type>Member and the relationship and link interface are named logically following the same rules.
Assembly Pattern
An assembly relationship is a special type of collection relationship in which a particular collection member can belong to, at most, a single collection instance.
If abstraction is on the left side, then the relationship name and interface on the left are named based on the <member type>.
If the abstraction is on the right side, then the relationship name and the interface are named based on the type of assembly.
Composition Pattern
The composition relationship is a specialization of the assembly relationship in which the cardinality on the left side is one. In this relationship, the object or interface on the right side cannot exist without a relationship to an object on the left side. Specifically, if the object on the left-hand side is deleted, the objects on the right-hand side must also be deleted.
The naming of the interfaces and relationship for this pattern is the same as for the collection and assembly patterns.
SameAs Pattern
Two approaches can be used to indicate that an object is the same object as an object previously loaded into SmartPlant Foundation:
-
Publish the object with the same UID.
-
Publish the object with a SameAs relationship to the object for which it is the same object.
The SameAs pattern is used to indicate this latter case.
The SameAs pattern is not a pattern since there is just the one case involving the IUID interface. However, all relationship definitions in the SmartPlant schema are classified as being an instance of a particular pattern, and the SameAs relationship definition is not an exception.
Connectivity Pattern
The connectivity pattern can have one connection at each end and zero or more TapsOrFittings in between. Each connection may be an end point for more than one connector, or it can be a tap for one connector and an end point for another connector. Alternatively, a connection can be a fitting for the connector.
To add information about a connection, add an interface on the to-many side of the relationship definition. For example, if property information is to be defined for each of the end connections, interfaces are added for each end (such as IConnector End1 and IConnector End2) of the connector and related to the connection as shown in the following diagram:
End connections denote the end point of one end of a connector. A TapOrFitting is any other point along the connector that does not terminate the connector. For example, a valve in a P&ID pipe run that does not change any of the pipe run properties, and does not break the pipe run into two pipe runs, will have two fitting points tied to the one piping run connector.
For SmartPlant applications, instances of the connectivity pattern typically refer to connectors as connectors at the physical level, runs at the logical level, and systems at the more abstract level.
Occupancy Pattern
The occupancy relationship is a one-to-one relationship in which a particular object occupies the space created by another object.
With the occupancy relationship, the abstraction is always on the right side and this interface is always named the same as the interface on the left side with an occupant suffix. The relationship is named based on the interface on the left with the I prefix removed and an occupancy suffix added.
Interface Patterns
Patterns are used to express the typical material and part occurrence hierarchies.
Typical Material vs. Part Occurrence Interface Diagram Pattern
As the word typical implies, it refers to parts that are in a catalog that have typical properties. Below is a sample plant design workflow to develop the idea of typical material.
-
An early-stage plant design simulator (like AspenTech Zyqad) establishes the need for moving a fluid from one area to another at a rate of 100 GPM. The ability to move fluid is a required facility.
-
Further work is done by a separate tool (Smart Instrumentation) that determines a safety factor of 25% is required for the plant. The safety factor is a required material.
-
The P&ID designer plans for two pumps to provide redundancy, which is a planned material. One conceptual pump is now two pumps that must be purchased.
-
Pick a pump from the manufacturers' catalog that is listed with a flowrate of 75 GPM (typical material). Use the catalog part number EY-75VCP as the part name.
-
Create a purchase order for two pumps from a company that carries the part (a planned pump). The pair of pumps can pump 150 GPM total.
-
When the pumps are delivered, they are a newer model pump, each of which is rated at 80 GPM. Each pump gets an inventory tag (an actual pump), and the pair fulfills all of the design requirements.
Different Ways to Think About a Pump (Polymorphism)
As you can see, some properties about a pump apply to:
-
Early-stage pump design requirements (flowrate is required).
-
Required pump (tag number).
-
Catalog pump (manufacturer's catalog part number and weight).
-
Actual pump (serial number).
In order to support these different views of different property sets for the pumps, the SmartPlant schema supports the concepts of part, tag, and asset.
-
The manufacturer's catalog number does not have any meaning to the actual pump that is installed in the plant.
-
In a similar manner, the serial number of the pump is not listed in the catalog, but just the characteristics.
SmartPlant uses the concept of polymorphic interfaces to create an interface, IPump, that is polymorphic with respect to:
-
Pump design requirements
-
Pumps in catalogs
-
Pumps that are ordered from a manufacturer
-
Pumps that are installed
-
Other kinds of pumps
For more information on polymorphic interfaces, see Chapter 3 of A Gentle Introduction to the SmartPlant Schema.
Typical Means Type
The word typical is the concept of type or typeness of a class. Properties that define the type of a pump are not the same properties as the many other kinds of pumps that exist.
Typical Material Interface Diagram Pattern
The illustration above displays an interface hierarchy for a typical low-pressure tank that can appear on an equipment datasheet.
-
IEQDTypLowPressureTank is a non-drawing item because it appears on an equipment datasheet, which is non-graphical.
-
It is also a typical low-pressure tank, such as ITypLowPressureTank. The modeler can infer that there can be other interfaces in the future, such as IXYZTypLowPressureTank, that would imply ITypLowPressureTank.
-
A typical low-pressure tank, ITypLowPressureTank, is a typical item, such as ITypicalMatl, and a low-pressure tank, such as ILowPressureTank.
-
ILowPressureTank is a process vessel (IProcessVessel), which is a type of process equipment (IProcessEquipment), which is a solid item (ISolidItem), which may have a weight (IWeight) and center-of-gravity (ICOGItem). An application that models the equipment may or may not actually publish the weight and center of gravity.
Notice that all the implies relationships up to IProcessEquipment are required, which means that every typical item exposes all the properties within the hierarchy. It also exposes the properties in IProcessEquipment that contain the type hierarchy, ProcessEqType1, 2, 3, 4, 5, 6.
The optional implies relationship between IProcessEquipment and IJacketedItem means that a catalog item, such as a part, may or may not have a jacket.
Part Occurrence Interface Diagram Pattern
The illustration below shows how a part occurrence, a pump, on an Equipment Datasheet carries catalog data through a unidirectional association that links a part to an occurrence.
After a brief introduction, a path can be traced around the outer edge of the diagram, clockwise, starting at IPartOcc:
-
Interface IPartOcc exposes the CatalogName and CatalogPartNumber property definitions.
-
CatalogName and CatalogPartNumber are scoped by a 2-level enumerated list of values, such as Catalog Name (Level 1) and Catalog Part Number (Level 2). In the example, the Gould Pumps catalog contains some Gould pumps, including Gould Pump XYZ.
-
An instance of an EQDPump, such as P-100, is published with properties CatalogName="Gould Pumps" and CatalogPartNumber="Gould Pump XYZ".
-
The entry Gould Pumps is a level-1 enumerated entry in the Catalog Name list.
-
The entry Gould Pump XYZ is a level-2 enumerated entry in the Catalog Part Number list.
-
In the lower portion of the example, there is an instance of a typical pump (schema ClassDef EQDTypicalPump), such as Gould Pump XYZ, which provides enumerated metadata for the enumerated entry Gould Pump XYZ (the EnumEnum).
Relationship Patterns
Relationships between interface definitions are defined as a RelDef class. Relationships can have an abstract parent relationship, which controls the behavior.
Plant Breakdown Structure (PBS) Patterns
The following illustration shows high-level, abstract interfaces of IPBSItemCollection, which is a group of IPBSItems. To process the members of the collection, you must traverse each of the PBSItemCollection associations to get each PBS Item one-by-one. But there are no classes called PBSItem or PBSItemCollection. The Interfaces are abstract and the relationship can be considered abstract, too. The relationship is the concept of PBS Items in a collection.
When a ClassDef realizes IPBSItem or IPBSItemCollection, it can be a child, parent, or both in a relationship with other PBS items. Relationships can be derived from the abstract parent relationship definition, and can then be used to define relationships that will exist in the published document.
The illustration below shows that the relationship definition InstrumentLoopAssembly is a type of PBSItemCollection. It is subject to all the benefits and all the semantic rules that PBSItemCollection defines. Other semantic rules can be added to InstrumentLoopAssembly if necessary. It is also valid to have intermediate-level, abstract RelDefs, each of which contributes some kind of semantic meaning to the final, concrete relationship definition.
Work Breakdown Structure (WBS) Patterns
Similar to the previous section, the following illustration shows that the relationship definition PlantProjects is a type of WBSItemCollection. It is subject to all the benefits and all the semantic rules that WBSItemCollection defines. Other semantic rules may be added to PlantProjects if necessary. It is also valid to have intermediate-level, abstract RelDefs, each of which contributes some kind of semantic meaning to the final, concrete, relationship definition.
