Mapping of a P&ID

latest update 2023-03-31  


Piping & Instrument Diagrams (P&ID) are the core documents of any plant. Their primary role is to represent the configuration of the plant with

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.

Plant items

Below the plant items on this P&ID are listed. Please note that all items are instances of lci:InanimatePhysicalObject and of lci:NonActualIndividual:


For each equipment item any relevant assembly relationship is recorded, as well as connection relationships with other plant items.

Control Systems

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.

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.

Piping Systems

(S = Segment)

For each Line is recorded


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:

Streams as objects cannot be shown on P&IDs, other than by labelling next to the (piping) lines. This is normally not done on P&IDs, but is, or used to be, done on PFDs (Process Flow Diagram).

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.

Design Considerations

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:

(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:

Mapping code

Four code listing, all related to the same P&ID, can be found here:

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 . 

    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 .

    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:

    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 .

    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.