Information Modeling for ISO 15926

We have said many times that ISO 15926 seeks to make information smarter, which is opposite to the AI approach of making the machine smarter. To make information smarter we have said that ISO 15926 drives the meaning of the data into the data itself. Here we will give you a glimpse of how this works. It comes under the general heading of Information Modeling.

Goal – Remove Ambiguity

When you model information for use with ISO 15926, your goal is to capture the full meaning of the information so that when your computer talks to my computer, my computer will understand the meaning of your information without requiring any of the background knowledge that humans have. To repeat what we have said many times, you want to drive the ambiguity out of your information. You want to take the implied information, that is, everything that “everybody just knows”, and make it explicit.

For an example, imagine you are trying to explain to my computer what “Maximum Operating Pressure” means on a Line List or P&ID.

Sensing a trick question you might start by asking yourself what Maximum Operating Pressure really is. Your mental image might be a pressure gauge attached to a piece of pipe, with something like “Normal Operating Pressure” being the point on the dial that the engineer assumed the pipeline would be running at most of the time. You might imagine that “Maximum Operating Pressure” to be a red line on the dial past which you should start running. From that line of reasoning you might conclude Maximum Operating Pressure is a property of the Pipeline.


Computer! Maximum Operating Pressure is a property of the Pipeline!

On the surface, that seems pretty good, especially after thinking about it extra hard. But if my computer were to attach a pressure gauge to the pipe based on that explanation, working literally from what you said it would weld the pressure gauge directly on to the side of the pipe.

“Of course!” you say “That’s what it should do!”

But look carefully at what I said. I said that the computer would weld the pressure gauge directly on to the side of the pipe; I did not say that it would cut a small hole first.

What?” you reply. “You’d have to be pretty stupid to do that.”

Well, no one ever accused a computer of being smart.

“Yes”, you try again, “but everyone knows you have to cut a little hole first.”

True, every person knows. But a computer isn’t a person. It has no experience. It will only do what you’ve told it to do.

“But”, not giving up yet, you ask “what do you think you are measuring here anyway? The pressure of the steel the pipe is made from?”

Well, that’s actually what you said, “Maximum Operating Pressure is a property of the Pipeline.”

We could carry on like this and perhaps turn it into a regular Monty Python skit, but I think you get the drift.

If you have never done this kind of information modeling before you may be offended by the apparent silliness of this example. Of course we are measuring the pressure of the fluid (not the pressure of the steel the pipe is made of), and of course the fluid is inside the pipe (therefore we have to cut a small hole for the pressure gauge). People in the industry know this instinctively, but you have to spell it out in detail when you are talking to a computer.

And so we can see the point of information modeling. We are forcing ourselves to explain just exactly what we mean; we want to remove ambiguity and embed the meaning of the data into the data itself so that even machines will understand.

First: Identify all of the “things” we are dealing with

To do this we ask a pair of questions repeatedly until we have found enough “things” to properly identify the data we are exchanging. (To make it easier the diagram below shows all the “things” we need to consider.) We consider each “thing” in turn. 



Maximum Operating Pressure

Q1.  “What is the property in focus?”

A1.  Of course, it is “Maximum Operating Pressure”.

Q2.   “To which object does the property in question pertain?”

We might be tempted to answer “Why, the line number, of course.” But we have a problem here because all of the properties of a line number do not always stay constant for the entire length of the line.

Consider a cooling water header that starts at a large diameter and gradually reduces its diameter as branch lines take water away. Each time water leaves the header and each time the diameter changes the velocity and pressure of the water change.

Process engineers have a construct to manage this which they call the “Stream”. The stream holds all the properties required in process design. When any of the properties change, the stream, or “stream ID”, changes.

A2.  Maximum Operating Pressure is a property of the Stream.


Now we move our focus to the next “thing” and ask the two questions again (slightly modified because the next “thing” is not a property but an object itself.)

Q1.  “What is the object in focus?”

A1.  The “Stream”.

Q2.  “To which object is the object in question related?”

Again, we might be tempted to answer “The line number. What else can it be?” But we have the same problem here as before, in that not all of the properties required for mechanical design are properties of the stream (for instance, process engineers are not usually concerned with the allowable tensile strength of the material the pipe is made from), and not all of the mechanical engineering properties remain constant for the entire length of the line. The construct used by mechanical engineers is “Line Segment”. When any of the mechanical engineering properties change, the line segment, or “segment ID” changes.

A2.  The Stream is related to the Line Segment.


Again, we move our focus to the next “thing”.

Q1.  “What is the object in focus?”

A1.  The “Line Segment”.

Q2.  “To which object is the object in question related?”

A2.  The Line Segment is related to “Line”.

Carry on or Stop?

We can carry on here to any arbitrary point since, in reality, everything is connected to everything. (For instance, the line in our example might be part of the cooling water system, which is connected to the cooling water pumps, which might be part of the Utilities unit, which is part of a particular process plant, which is … eventually connected to Life, the Universe, and Everything.) However, if our purpose is to define just what we mean by “Maximum Operating Pressure” we can stop here.

Second: Identify all of the relationships

In this step we identify the relationships between all of the “things”. (The manner of choosing the correct relationship is not particularly difficult, but is beyond the scope of this blog, so again, we give the answers in the diagram below.)


To show you how this removes ambiguity in an exchange, let us go back to the initial example where you were trying to send my computer a line list. To do this you would send a stream of data which my computer would assemble into a coherent document.

At one point you would be sending the maximum operating pressure of a line.

You:  “Computer! I want to send you a Maximum Operating Pressure.”

Computer:  “What is this Maximum Operating Pressure of which you speak?”

You:  “The Maximum Operating Pressure I am going to send you is a property of the object Stream, which is contained within the object Line Segment, which itself is a part of the object Line.”

Computer:  “Aha! That Maximum Operating Pressure! Send it to me!”

You:  “42”.

The bottom of the Rabbit Hole

This is by no means the bottom of the rabbit hole; it goes quite a bit deeper than this. For instance, we still have to select the proper “class” names for the objects and properties, and select the proper “templates” for the relationships, and of course, teach our software how to transform our data in to and out of the ISO 15926 representation. But it does show how the meaning of the data is embedded into the data itself.

Using the ISO 15926 Representation of your Data

When you use ISO 15926 to represent your data you can literally broadcast it to the world and other, similarly-equipped software will pick out of the data stream just what it needs.

Example: Instrument Data Item.

You could send an entire P&ID and all the associated data to an instrument vendor and let the vendor’s software pick out just the bits it needs to select the correct instruments from the catalogue.

Vendor’s Computer (examining the data dump you just sent it) “We are selecting the correct model for pressure transmitter 1234 located on line 5678. Let’s see…we need to find Maximum Operating Pressure that is a property of Stream which is contained in Line Segment which is part of Line 5678. Aha! There it is!”

We would probably not send an entire data dump to a vendor that just needed one data value, but in the real world the vendor would probably need more than one. A better solution would be to expose the P&ID data on the Internet and let the vendor’s software come in and make a query—there would be no need to send any data to anyone.

Example: Advanced Analytics

Currently, when someone, say, a plant’s efficiency engineer, wanted to use a project’s data he would have to request certain data items to be extracted, from possibly multiple sources, and be put into a particular form. This adds considerably to the “friction” of getting things done. In the ISO 15926 world the owner would simply expose the project data to the engineer. Because the ISO 15926 representation of the data includes all of the relationships (see above – Life, the Universe, and Everything), the engineer would be able to follow all the links to whatever he needed to see. For instance he would have the ability to navigate from a start point into the data on a pipeline that allows him to walk to the segment, to the stream, and then continue to the cases of the stream, specs, or whatever. Or from the pipeline to a valve on the pipeline to its purchase order and on to its invoice.

And when we add in mobility, the value could really explode because we would be able to leverage explicit links in a large set of endpoints of project and manufacturing data.

Where to from Here?

Where you, dear reader, go next depends on your perceived role in an information exchange. In a previous post we compared information modeling on an information exchange project to stress analysis in plant design. In plant design we have developed a three-tier structure for stress analysis; finite element modeler, stress engineer, and piping designer. In information modeling the first two comparable levels would be something like Part 2 Guru and ISO 15926 Modeling Expert. The third level, Subject Matter Expert, could be you. The basic rules for information modeling are accessible enough that interested industry professionals can do most of the modeling for their subject area.

Find out More

The best way to find out how to implement ISO 15926 is to get involved in one of the projects sponsored by Fiatech or the POSC Caesar Association (PCA). There is always a half dozen or so going on at any one time dealing with design and implementation issues for various parts of ISO 15926. Take a look at their websites.



If you would like to read more about ISO 15926 download An Introduction to ISO 15926 from the sidebar.

No comments yet.

Leave a Reply