Piping & Instrument Diagrams (P&ID) are the core documents of any plant. Their primary role is to represent the configuration of the plant with
- all plant objects with their most generic class, e.g. PUMP instead of CENTRIFUGAL PUMP (that comes later);
- the tag of these objects;
- how these objects are composed (where shown on the P&ID);
- how these objects are interconnected;
- how certain objects are contained in other objects (e.g. streams in pipes and equipment, but also vessel and tank internals);
- how certain objects are located relative to other objects (e.g. 'Above vessel' - not mapped here).
In this topic we will work out a P&ID for anti-surge controls of a centrifugal compressor:
Anti-surge controls of a centrifugal compressor
It should be noted that the representation of instrument loops greatly differs for the various plant owner/operators, and only very seldomly shows all the components. The exact configuration of instrument loops is represented on loop diagrams. The reason why they are on P&IDs is to provide an functional overview.
Since the in-line components are actually of prime importance there are P&IDs where any other set of instrument components is represented with just one balloon.
For lines (piping network systems) the same applies as for instrument loops, in that P&IDs very seldomly show all its components (pipe fittings). So what we see on a P&ID is enough to understand the configuration of the plant. Details of piping systems are given on 3D models and on Isometrics, such as:
Segments are, for the most, chosen for representing their physical dimensions (from the 3D model), in some cases for linking them individually to their test certificate (required in Germany and other places), etc.
Below the plant items on this P&ID are listed. Please note that all items are instances of lci:InanimatePhysicalObject and of lci:NonActualIndividual:
- Centrifugal compressor K-101 with variable speed driving motor KM-101;
- Suction Knockout Drum V-101;
- Aftercooler E-101 with variable speed driving motor EM-101.
For each equipment item any relevant assembly relationship is recorded, as well as connection relationships with other plant items.
For instrument plant items we take off the loops and all local instument items, as and if shown on the P&ID. The numbering of the local instruments is not always made explicit on the P&IDs, but follows strict (local) rules.
- Loop AS-101 - anti-surge control system,
- ASC-101- Anti Surge Controller;
- ASV-101 - Anti Surge Control Valve;
- Loop F-101 - K-101 suction flow control,
- FE-101 - Flow Element;
- FC-101 - Flow Controller;
- Loop L-101 - V-101 level control,
- LT-101 - Level Transmitter;
- LC-101 - Level Controller;
- LV-101 - Level Control Valve;
- Loop P-101 - K-101 discharge pressure control,
- PT-101 - Pressure Transmitter;
- Loop P-102 - K-101 suction pressure,
- PT-102 - Pressure Transmitter;
- PC-102 - Pressure Controller;
- PX-102 - Variable Speed Drive Unit;
- Loop T-101 - E-101 outlet,
- TE-101 - Temperature Element;
- TT-101 - Temperature Transmitter;
- TC-101 - Temperature Controller;
- TX-101 - Variable Speed Drive Unit;
- RV-101 - Relief Valve.
For each instrument loop the composition relationship with its taken off instrument items (see above) is recorded, as well as the connection relationship of each loop or instrument item with another plant item.
(S = Segment)
- B14-RW17801 - Condensate to storage
- B14-RZ17800 - V-101 Gas Inlet
- B14-RZ17801 - K-101 Gas Inlet
- B14-RZ17802 - K-101 Gas Return
- B14-RZ17803 - K-101 Discharge to aftercooler E-101
- B14-RZ17804 - E-101 outlet
- B14-RZ17805 - RV-101 inlet
- B14-RF17801 - RV-101 outlet to flare
For each Line is recorded
- the assembly relationship with its segments is recorded,
- the stream segments contained by these piping segments, as well as
- their connections to other plant items.
Please read About Stream and Ports first.
The stream numbering follows (here) the line segments or equipment items, that constitute a line break, where possible by preceding their line- or tag numbers with an S-. Stream segments will get a suffix S1, S2, etc, and Stream Subsegments S1.1, S1.2, etc.
This results, for the above P&ID, in the following Streams, Stream Segments,and Stream Subsegments:
Please note that, although a stream segment per line segment is taken off, not all such stream segments will actually get process data attributed to them.
For each stream segment the containment in the related line segment or equipment item is recorded, as well as its source and destination. This can be automated, meaning that the P&ID software doesn't need to maintain stream records.
When we make a take-off from the above P&ID at a certain date and time the Turtle listing as shown here shall be generated automatically. Keep in mind that companies may have other sequences of declaring items, for example by setting up an equipment list first. In such cases other solutions have to be designed.
All data are being consolidated in a Project Store, and from there to the applicable Facility Store of the plant owner/operator. For a possible configuration see here.
For this take-off the assumption was made that the P&ID software does not have a system of keeping track of changes. This means that all components and their information, for as much that information can possibly be extracted from the P&ID, are being taken off as a batch.
It is important that once a system ID for a tag number has been given to an object, this ID shall immutably remain connected to that object. This may sometimes present a problem, for example when a piping system is modified. Whenever an object is being added to the P&ID the software shall give it a UUID or GUID.
For each take-off we create a set of new template instances as if we analyze the drawing for the first time. Then there are two ways to further handle this data:
- we simply store whatever is being taken off, deprecating and archiving all existing records;
- we can also design software that compares the template instances in which the tag plays a role with the newly taken off ones. If they contain the same information (e.g. the line segment still has a size of 4"), then the newly taken off one is ignored (note that the P&ID software has no knowledge of the specialized UrClasses, so this ignoring doesn't have any adverse consequences).
(It is appreciated that this is not always as simple as written down here :) Suggestions are most welcome!)
By only activating the hasSide1 and hasSide2 properties the following graph of all interconnections could be made from the ISO 15926-8 file (the template IDs, e.g. T27, were shortened for display reasons, the green templates are direct connections, the purple templates are indirect connections). This graph was made with Allegrograph's Gruff.
for comparison again:
Four code listing, all related to the same P&ID, can be found here:
- Mapping a P&ID
- Mapping functional data for B14-K-101
- Mapping data of line B14-RZ17801
- Classes, referred to above, in the local RDL extension
Mapping a P&ID
The mapping of the P&ID has been overhauled in order to follow the Data Model. Below is link to an excerpt from that graph, showing how a non-actual individual best be declared and embedded in the plant life cycle: Declare a Tag.
This is now reflected in the mapping code. As an example the code for compressor B14-K-101 is given below:
##### Declaration of Compressor B14-K-101 :B14-K-101 rdf:type lci:InanimatePhysicalObject, dm:WholeLifeIndividual, lci:NonActualIndividual, lci:NonActualIndividual, :CO-B14-K-101-FO , :CO-B14-K-101 ; rdfs:label "B14-K-101" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . :CO-B14-K-101-FO rdf:type dm:ClassOfFunctionalObject ; # ANCHOR CLASS (Functional Requirements Class) rdfs:subClassOf rdl:RDS14286497 ; # COMPRESSOR rdfs:label "CO-B14-K-101-FO" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . :CO-B14-K-101 rdf:type dm:ClassOfInanimatePhysicalObject ; # ANCHOR CLASS (Asset Requirements Class) rdfs:subClassOf rdl:RDS14286497 ; # COMPRESSOR rdfs:label "CO-B14-K-101" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .
and when information about the type of compressor is shown on the P&ID (it is) then:
:CO-B14-K-101-FO-rev0 rdf:type dm:ClassOfFunctionalObject ; # Class-of-temporal-part class for functional data tpl:coTemporalPartOf :CO-B14-K-101-FO ; rdfs:subClassOf rdl:RDS417194 ; # CENTRIFUGAL COMPRESSOR (because known on the P&ID) rdfs:label "CO-B14-K-101-FO-rev0" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime . :CO-B14-K-101-rev0 rdf:type dm:ClassOfInanimatePhysicalObject ; # class-of-temporal-part class for asset requirements data tpl:coTemporalPartOf :CO-B14-K-101 ; rdfs:subClassOf rdl:RDS417194 ; # CENTRIFUGAL COMPRESSOR (because known on the P&ID) rdfs:label "CO-B14-K-101-rev0" ; meta:valEffectiveDate "2022-02-08T16:19:00Z"^^xsd:dateTime .
Similarly information like a line size and line class can be attributed to the line carrying that information in its line number.
Since this approach is highly repetitive, it is advisable to automate it.
Mapping functional data for B14-K-101
Reading the paper 7 Tips on Compressor Design gave inspiration to add functional data for compressor B14-K-101.
These are actually stream data at a location at the inlet, inside, or at the outlet of the compressor. All such data are attributed to the Functional Requirements Class CO-B14-S-K-101-FO and its inlet and outlet.
Note that reference is being made to the 'anchor classes' that have been declared already during P&ID take-off.
Mapping data of line B14-RZ17801
This mapping is based on the earlier topic Mapping of a line list.
Note that for the sections and nodes a simplified mapping has been used, so without functional requirements. The rationale for that is that these data are already attributed to the whole line. But in case you feel the urge to also declare the -FO version, that is fine.
In a Line List of this type a number of tests and analyses are defined. For that purpose the applicable instances of ClassOfActivity have been declared.
Classes, referred to above, in the local RDL extension
On each project a set of "Project Standards" or similar named Classes are defined. For classes, already defined in the ISO 15926-4 Reference Data Library, you can either refer to them on the RDL endpoint, or make a selection of that for that project and store these in your local RDL extension. Since on each project classes are required that are not (yet) in the RDL, these can also be stored in your local RDL extension.
By means of "Federation" of endpoints, defined for each SPARQL query, your local RDL extension appear to be part of the RDL Such a federation is advisable for SHACL validation of the ISO 15926-8 exchange files.