Object Models and the RDL

latest update: 2015-12-17    

Introduction

This topic deals with object modeling for equipment systems and their relationship with the class concepts in the RDL. In order to turn the taxonomies of the RDL into ontologies it is necessary to add template instances. These interrelate the RDL classes or specializations thereof.

A Pump Model

Let's have a look at a simple assembly model of a centrifugal pump system.

This model is not claimed to be complete.

Clicking on the objects in blue gives access to an applicable concept in the RDL, inasmuch as these are already listed. These may have various subclasses.

The Power Connecting System and the Pump Piping System often are covered by typical hook-up details, such as:

The seal oil system details are, at present, not covered by the RDL, at least not with these names. It is very well possible that these objects are standard and are covered, but that the names are indicative only and actually are service descriptions and not implying special equipment.

Building an ontology - Assembly

As a minimum it is necessary to add ISO 15926-7 templates to define the assembly relationships, including the applicable cardinalities.

For example, if the pump is a TWO STAGE CENTRIFUGAL PUMP then the assembly relationship with its two INDIVIDUALLY SECURED PUMP IMPELLERs the template ClassOfAssemblyDefinition is to be used:

with as end1Cardinality 1:1 and as end2Cardinality 2:2 . This means: there can be two instances of any member AssemblyOfIndividual relationship with a member of the ClassOfArrangedIndividual that is in the "whole" Role, and in each of these two members of that AssemblyOfIndividual relationship a different member of the ClassOfIndividual is in the "part" Role. See also here.

NOTE 1 - By convention "end1" is the side of the (ClassOf)Relationship that has an attribute ('property') name that is lowest in the alphabetical order in English.

NOTE 2 - This Cardinality definition is somewhat counter-intuitive, since normally cardinalities are expressed like this:

Above template instance is coded in ISO 15926-8 format as follows:

:T6A7581D302BD4B72AAF922308C0C2BFD rdf:type tpl:ClassOfAssemblyDefinition ;

       tpl:hasClassOfWhole rdl:RDS1112264 ; # TWO-STAGE CENTRIFUGAL PUMP

       tpl:hasClassOfPart rdl:RDS414539 ; # IMPELLER

       tpl:hasCardinalityOfWhole rdl:RDS34729122 ; # 2:2

       tpl:hasCardinalityOfPart rdl:RDS34729111 ; # 1:1

       meta:valEffectiveDate "2015-12-17T00:00:00Z"^^xsd:dateTime .

Interconnections

The way the objects in the first diagram are interconnected is most often not modeled but represented with a drawing or typical detail, as shown above. Since the variety of such interconnections is endless, and fully depending on the exact object type, these diagrams are not incorporated in the RDL, but may be incorporated in RDL extensions, such as those of the suppliers. This is such a drawing (courtesy of Shenzhen Sinofine Machinery Co.,Ltd):

The detailing of the components is a matter of business needs. A supplier may put all above parts in his RDL extension, and their customers may want to refer to those parts that they want to keep in stock as spare parts.

Building an ontology - Interconnections

For process units it may be advantageous to design and store standard configurations, where the components still can be specialized. Because of the endless variety this kind of information most likely will be stored in an RDL extension of process licensor, an EPC contractor, or a plant owner/operator. For such an ontology as a minimum all interconnections can be hybridwise modeled or shown in typical, linked, diagrams.

Take for example a Crude Desalter Unit:

For the modeling of the interconnections the template ClassOfIndirectConnectionDefinition can be used:

Here the indirect connection of the Desalter bottom with the shell side of the Brine Exchanger is modeled.

This template allows for interconnecting equipment without having to deal with the details of the interconnecting piping (that comes later).