Introduction
Referring to the topic Plant Life-cycle Model this topic here defines how a Tag, a Stream, and a Commodity Item can be declared, each different and in one blow by a standard piece of modeling.
Declaring a Tag
Tags are plant items and parts thereof, that get a tag number to uniquely identify it in the context of a plant. The question which parts qualify as 'tag' can only be answered by stating that a tagged item is necessary in case information is specific for that item and shall be recorded. If so, they need to be sub-tagged, e.g. B14-P101-IMP2 for the second impeller of two-stage centrifugal pump B14-P101
Tags exist in a non-actual design & engineering world, as opposed to the actual world around us. See also the topic Possible Worlds
A Tag is often referred to as 'Functional Location'. The function of pump P101 fully depends on its location in a P&ID. If it is no longer required on that location in the P&ID topology, it ceases to exist.
A Tag can be (and usually is) implemented by an actual PhysicalObject in the real world, that has been installed in the actual Functional Location in the plant.
For a Tag certain functional and physical requirements shall be defined, in order to be able to purchase an actual PhysicalObject that fulfils these requirements.
The diagram
Let's have a look at a marked-up detail of the LSN, in which we see which items shall be declared. The standard code for that is given below.
Explanation
Before going into detail it the concept of 'anchor' must be explained. In ISO 15926 terms an individual anchor cannot have, ever, a temporal whole. Anchors only get the information that 100% certain will always be attributed to it. In practice that is almost zero.
The items that are to be declared together are:
- the anchor Tag [36], with a label that is unique in the applicable plant, and typed with:
- lci:InanimatePhysicalObject ;
- dm:WholeLifeIndividual ;
- lci:NonActualIndividual ;
- and the applicable 'Essential Type', in most cases an instance of ClassOfFunctionalObject or, when not applicable, an instance of ClassOfFunctionalObject that is highest in the taxonomy without losing sense, a typing that shall never change;
- the classifying instance of ClassOfFunctionalObject [43] ;
- the classifying instance of ClassOfInanimatePhysicalObject [53] ;
The ClassOfFunctionalObject [43] is about, as the name suggests, functional information, for the most Stream information, but also information that influences proper functioning, such as site data (e.g. explosion hazard, available utilities, elevation, meteorological data, etc.).
The ClassOfInanimatePhysicalObject [50] is a subClassOf the above ClassOfFunctionalObject [40]. This means that the functional information is inherited by that ClassOfInanimatePhysicalObject. In practice we can see that on a specification/datasheet, where that specification not only defines the physical requirements, but also has a section about the stream that is supposed to be handled and a section with site data.
Documentation
The ClasOfFunctionalObject [40] is being represented on a Process Data Sheet [42], or the data from such a datasheet are mapped and uploaded to the Class. The way this is done is a matter of work process and related software. The ClassOfInanimatePhysicalObject [50] has a similar relation to a Technical Specification [52].
Code for declaration of a Tag
The typical code for this declaration is shown for pump B14-P101, its inlet and outlet port, and its casing:
#################################################################################### # # DECLARATION OF ANCHOR OF PUMP B14_P101 AND ITS REQUIREMENT CLASSES # Always declared together # #################################################################################### ex:2bfa83ae-19da-4135-9d30-ca606a1e8afa rdf:type lci:InanimatePhysicalObject, dm:WholeLifeIndividual, lci:NonActualIndividual, ex:4d515eb6-0cea-4431-b26c-0b27bdfbe9a7 , ex:be6becd6-f599-4927-b913-74f3fc64d777 ; rdfs:label "B14-P101" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . ex:4d515eb6-0cea-4431-b26c-0b27bdfbe9a7 rdf:type dm:ClassOfFunctionalObject ; # FUNCTIONAL REQUIREMENTS CLASS rdfs:subClassOf rdl:RDS414081061 ; # PUMP SYSTEM rdfs:label "CO_B14-P101-FO" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . ex:be6becd6-f599-4927-b913-74f3fc64d777 rdf:type dm:ClassOfInanimatePhysicalObject ; # ASSET REQUIREMENTS CLASS rdfs:subClassOf rdl:RDS414081061 ; # PUMP SYSTEM rdfs:label "CO_B14-P101" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . ######################################################################################## # # DECLARATION OF B14_P101 BODY AND PROCESS NOZZLES AND THEIR REQUIREMENT CLASSES # ######################################################################################## ###### ANCHOR INLET NOZZLE AND CLASSES ###### ex:a3b5c4d8-63fc-45d1-b251-10d7af8e8ae6 rdf:type lci:InanimatePhysicalObject, dm:WholeLifeIndividual, lci:NonActualIndividual, ex:2056a7df-281a-468b-806e-a19eeee6daa0, ex:7903d449-f284-44ea-93e9-0c45d2b52815 ; rdfs:label "B14-P101-IN" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . ex:2056a7df-281a-468b-806e-a19eeee6daa0 rdf:type dm:ClassOfFunctionalObject ; # FUNCTIONAL REQUIREMENTS CLASS FOR INLET NOZZLE rdfs:subClassOf rdl:RDS2195131601 ; # LIQUID INLET PORT rdfs:label "CO_B14-P101-IN-FO" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . ex:7903d449-f284-44ea-93e9-0c45d2b52815 rdf:type dm:ClassOfInanimatePhysicalObject ; # ASSET REQUIREMENTS CLASS FOR INLET NOZZLE rdfs:subClassOf rdl:RDS2195131601 ; # LIQUID INLET PORT rdfs:label "CO_B14-P101-IN" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . ###### ANCHOR PUMP CASING INDIVIDUAL AND CLASSES ###### ex:89911063-3579-44c2-945c-3f06feeb544d rdf:type lci:InanimatePhysicalObject, dm:WholeLifeIndividual, lci:NonActualIndividual, ex:e3587ee8-3e98-44c3-b42c-f152fd719ac3, ex:1c6ae6e5-8e1c-487b-b70e-7695117b1aef ; rdfs:label "B14-P101-CASE" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . ex:e3587ee8-3e98-44c3-b42c-f152fd719ac3 rdf:type dm:ClassOfFunctionalObject ; # FUNCTIONAL REQUIREMENTS CLASS FOR PUMP CASING rdfs:subClassOf rdl:RDS461204 ; # PUMP CASING rdfs:label "CO_B14-P101-CASE-FO" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . ex:1c6ae6e5-8e1c-487b-b70e-7695117b1aef rdf:type dm:ClassOfInanimatePhysicalObject ; # ASSET REQUIREMENTS CLASS FOR PUMP CASING rdfs:subClassOf rdl:RDS461204 ; # PUMP CASING rdfs:label "CO_B14-P101-CASE" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . ###### ANCHOR OUTLET NOZZLE AND CLASSES ###### ex:fb7d4bb2-c68a-4715-ac37-1869bd4128cf rdf:type lci:InanimatePhysicalObject, dm:WholeLifeIndividual, lci:NonActualIndividual, ex:d30fd6da-ccec-4515-9b66-118c8ea274e0 ; rdfs:label "B14-P101-OUT" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . ex:6fbe3e97-6b49-44d5-bc58-a875f001233c rdf:type dm:ClassOfFunctionalObject ; # ANCHOR FUNCTIONAL REQUIREMENTS CLASS FOR OUTLET NOZZLE rdfs:subClassOf rdl:RDS2195143051 ; # LIQUID OUTLET PORT rdfs:label "CO_B14-P101-OUT-FO" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . ex:d30fd6da-ccec-4515-9b66-118c8ea274e0 rdf:type dm:ClassOfInanimatePhysicalObject ; # ANCHOR ASSET REQUIREMENTS CLASS FOR OUTLET NOZZLE rdfs:subClassOf rdl:RDS2195143051 ; # LIQUID OUTLET PORT rdfs:label "CO_B14-P101-OUT" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .
Why class of temporal part?
The concept of temporal parts is explained here. Here they are being used as shown in the diagram below.
Note that the 'co' in 'coTemporalPartOf' stands for 'classOf', distinguishing it from temporalPartOf between instances of PossibleIndividual. This relation is to be implemented with the template ClassOfTemporalWholePartDefinition. It is deprecated when the next version has become effective, by adding the triple ex:uuid meta:valDeprecationDate "yyyy-mm-ddThh-mm-ssZ"^^xsd:dateTime .
This construct can be used as well for other Classes, predominantly for a ClassOfInformationObject (document) with revisions.
The reader is invited to think about the possibilities to capture the dynamics of, for example, a new revision in a Process Data Sheet that has not yet been causing a new revision of a Technical Specification for some time, and the consequences thereof. Anyway, situations like that can be captured and recorded.
Declaring a Stream
Normally Stream data are part of the data attributed to ClassOfFunctionalObject [40], where they are representing the functional requirement of being able to handle that Stream wiithin those limits. And normally there are no physical requirements related to Streams. So we have a hard-coded anchor ClassOfStream, of which ClassOfFunctionalObject [40] is a coTemporalPartOf.
The model of the Stream declaration is shown below.
Explanation
Stream [35] is contained in the Tag [36]. That Stream is typed with its ClassOfStream [41], where the latter has earlier-declared ClassOfFunctionalObject [43] as subclass. At first sight that may be incorrect modeling, but keep in mind that semantically this means that members of [43] shall be capable of handling members of that Stream class with those data.
Starting at the anchor Tag all information about the contained Stream, from Process Design (if available) and the design case defined by the Process Engineer, can be accessed even before a start has been made with specifying the Asset Requirements Class.
Code for declaration of a Stream
The typical code for this declaration is shown for stream B14-S-P101 flowing through pump B14-P101, with three stream segments in the inlet, the casing, and in the outlet:
############################################# # # DECLARATION OF STREAMS AND STREAM CLASSES # ############################################# ##### Declaration and definition of Stream B14-S-P101 ##### ex:a54ffb88-f5f3-4e0f-8dae-a3fd2e83664a rdf:type dm:Stream, dm:WholeLifeIndividual, lci:NonActualIndividual, ex:ff7abb4e-1267-428d-a8a2-5b77b645b78b ; # ANCHOR STREAM rdfs:label "B14-S-P101" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . ex:ff7abb4e-1267-428d-a8a2-5b77b645b78b rdf:type lci:ClassOfStream ; rdfs:subClassOf rdl:RDS2227031 ; # LIQUID STREAM rdfs:label "CO_B14-S-P101" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . ex:101d7314-6660-4e09-8e5e-ed0524ade1ce rdf:type tpl:ContainmentOfAnIndividual ; # B14-S-P101 is contained in B14-P101 tpl:hasContainer ex:2bfa83ae-19da-4135-9d30-ca606a1e8afa; # B14-P101 tpl:hasContained ex:a54ffb88-f5f3-4e0f-8dae-a3fd2e83664a ; # B14-S-P101 ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . ##### Declaration and definition of stream segment at inlet B14-S-P101-IN ##### ex:360f7494-d12b-47aa-b770-482b9a8c7d07 rdf:type dm:Stream, dm:WholeLifeIndividual, lci:NonActualIndividual, ex:17bf66e6-efc3-4193-8607-f2a62d10dbb6 ; rdfs:label "B14-S-P101-IN" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . ex:17bf66e6-efc3-4193-8607-f2a62d10dbb6 rdf:type rdl:RDS2229972 ; # STREAM SEGMENT rdfs:subClassOf rdl:RDS2227031 ; # LIQUID STREAM rdfs:label "CO_B14-S-P101-IN" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . ex:26bf6322-a7d6-4240-ad5f-c7a776c0f406 rdf:type tpl:CompositionOfAnIndividual ; tpl:hasWhole ex:a54ffb88-f5f3-4e0f-8dae-a3fd2e83664a ; # B14-S-P101 tpl:hasPart ex:360f7494-d12b-47aa-b770-482b9a8c7d07 ; # B14-S-P101-IN ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . ex:eedff784-09ca-4380-a3bd-e58f9f95ba09 rdf:type tpl:ContainmentOfAnIndividual ; tpl:hasContainer ex:a3b5c4d8-63fc-45d1-b251-10d7af8e8ae6 ; # B14-P101-IN tpl:hasContained ex:360f7494-d12b-47aa-b770-482b9a8c7d07 ; # B14-S-P101-IN meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . ##### Declaration and definition of stream segment at outlet B14-S-P101-OUT ##### ex:e45e642b-a06e-4a2d-9e5a-837d086c8846 rdf:type dm:Stream, dm:WholeLifeIndividual, lci:NonActualIndividual, ex:fd5b1537-8b3a-490c-970e-ab69f7fa14ae ; rdfs:label "B14-S-P101-OUT" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . ex:fd5b1537-8b3a-490c-970e-ab69f7fa14ae rdf:type rdl:RDS2229972 ; # STREAM SEGMENT rdfs:subClassOf rdl:RDS2227031 ; # LIQUID STREAM rdfs:label "CO_B14-S-P101-OUT" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . ex:a8819d44-1b2f-4f15-b85b-88974a1fbc27 rdf:type tpl:CompositionOfAnIndividual ; tpl:hasWhole ex:a54ffb88-f5f3-4e0f-8dae-a3fd2e83664a ; # B14-S-P101 tpl:hasPart ex:e45e642b-a06e-4a2d-9e5a-837d086c8846 ; # B14-S-P101-OUT meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . ex:c752b426-d6e5-49bd-be11-435b21d9fd35 rdf:type tpl:ContainmentOfAnIndividual ; tpl:hasContainer ex:fb7d4bb2-c68a-4715-ac37-1869bd4128cf ; # B14-P101-OUT tpl:hasContained ex:e45e642b-a06e-4a2d-9e5a-837d086c8846 ; # B14-S-P101-OUT meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .
Declaring a Commodity Product
A Commodity Product ('CP') is defined as: "A product is a commodity when all units of production are identical, regardless of who produces them."
We must be careful not to decide too hastily that something is a CP. For example, in an RDL is stated that a 24-PAIR CABLE is a CP, but that is not true in all cases. First of all through cables and pipes we transport electrical energy and fluids, and they are an integral part of the plant topology, and hence shall be categorized as tagged items.
It may become a CP when we add up the requirements in terms of counts (fittings) or lengths (pipes, tubes, cables).
The model of the Commodity Product declaration is shown below.
Explanation
Best is to enter all CPs for a project in the Project RDL Extension. The Requirements Class is a specialization of that RDL Class in that a certain quantity is listed as a requirement. That quantity can be calculated from the Requirements Classes of the tagged quasi-CPs (the dotted lines and nodes). Since presumably no functional information is required, only the asset requirements are taken into account
Code for declaration of a Quasi CP
The typical code for this declaration is shown for cable B14-ES463 :
############################################################################ # # DECLARATION OF ANCHOR OF CABLE B14_ES463 AND ITS ASSET REQUIREMENT CLASS # ############################################################################ ex:fbbc18f9-c99f-4f12-a8a5-8d5bfccdfc99 rdf:type lci:InanimatePhysicalObject, dm:WholeLifeIndividual, lci:NonActualIndividual, rdl:RDS2220117 ; # SIGNAL CABLE rdfs:label "B14-ES463" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . ex:4511c8c9-7c69-437c-b057-015d8c7c5318 rdf:type tpl:ClassificationOfIndividual ; tpl:hasClassified ex:fbbc18f9-c99f-4f12-a8a5-8d5bfccdfc99 ; tpl:hasClassifier ex:7bac2dbb-8499-4f6b-a6c9-e20d0f2e4f33 ; meta:valEffectiveDate "yyyy-mm-ddThh:mm:ss.sZ"^^xsd:dateTime . ex:7bac2dbb-8499-4f6b-a6c9-e20d0f2e4f33 rdf:type dm:ClassOfInanimatePhysicalObject ; rdfs:subClassOf rdl:RDS2220117 ; # SIGNAL CABLE rdfs:label "CO_B14-ES463" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . ex:f0265d91-1016-482b-8d68-8c35f069e8d8 rdf:type tpl:ClassOfTemporalWholePartDefinition ; tpl:hasClassOfTemporalWhole ex:7bac2dbb-8499-4f6b-a6c9-e20d0f2e4f33 ; # CO_B14-ES463 tpl:hasClassOfTemporalPart ex:43559895-f7d8-46e8-b44f-b33b3c3fef5b ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . ex:43559895-f7d8-46e8-b44f-b33b3c3fef5b rdf:type dm:ClassOfInanimatePhysicalObject ; # Requirements Class rdfs:subClassOf exrdl:R68833 ; # the project standard Class for 24-pair signal cable rdfs:label "CO_B14-ES463-rev0" ; meta:valEffectiveDate "2022-06-17T14:23:00Z"^^xsd:dateTime . ###### LATER: ex:8d4a1eb8-23aa-4d88-a966-4e11b2e4717c rdf:type tpl:ClassOfIndividualHasPropertyWithValue ; tpl:hasPossessorType ex:43559895-f7d8-46e8-b44f-b33b3c3fef5b ; tpl:hasPropertyType rdl:RDS373094 ; # LENGTH tpl:valPropertyValue "96"^^xsd:decimal ; tpl:hasScale rdl:RDS1332674 ; # METRE