Version 49 (modified by gordonrachar, 14 years ago)


How To Implement ISO 15926

Status of this document: Working Draft

This document is open for feedback, please post questions and comments in the forum at the bottom of this page. You will need a login to post in the forum.


  1. Introduction
    1. First Thing - Read the Primer
    2. Second Thing - Have a "Problem"
    3. A Smorgasbord of "Problems"
  2. The Demand for Digital Interoperability
    1. FIATECH
    2. POSC Caesar Association
    4. Evolution of ISO 15926
    5. XMpLant
    6. IDS-ADI Project
    7. Matrix 123 and Matrix 8
    8. iRING
  3. Similarities and Differences between iRING and Proteus
    1. Metaphor: Humanitarian Aid to Haiti After an Earthquake
    2. Further Development of Proteus
    3. Further Development of iRINg
    4. Joint Operational Reference Data
  4. So Where Do I Start?
  5. Next


Only a few years ago, the most commonly asked question about ISO 15926 was "What is it and why should I care?" That question is still there, but nowadays it is mixed with "How do I implement ISO 15926?"

This How To manual is written to address this question. The intended audience of is someone who is considering implementing ISO 15926 at an organization, but wishes to know roughly what is involved before writing a proposal or committing funds. This guide does not attempt to be a step-by-step, screen shot-by-screen shot "Software Installation" document because the manner in which an organization implements ISO 15926 is, to a large degree, dependent on what it wishes to accomplish.

First Thing - Read the Primer

The first thing you need is an understanding of what ISO 15926 is and what it intends to do. A really good place to start is the ISO 15926 Primer. It will give you a good background to the huge pent-up demand for digital interoperability that is driving ISO 15926; an introduction to many of the organizations that have worked, and are working toward, digital interoperability; the various pieces that together make up ISO 15926; and some ideas to help you think of a good starting point.

Second Thing - Have a "Problem"

The second thing you need is an idea, otherwise known as "a problem", that you want to solve. But at the current stage of the development of ISO 15926, you will be forgiven for asking "What kind of problems can I realistically solve with it?" Some of the early claims of the potential of ISO 15926 sound magical, as if all you have to do is say ISO 15926 and the computer on your desk will start acting like the ones in the movies.

The future of digital interoperability my well be more than we can imagine (do you think that Orville and Wilber Wright, on the day of their first flight in 1903, could have imagined all the details of modern air travel?) but we've got a bit of work to do. It will be a few years before James Doohan can say "Computer! Transfer the design of the new transparent aluminum futtocks for the modified orlop to the fab shop for cutting!"

A Smorgasbord of "Problems"

There could be a number of different reasons for wanting to know how to implement ISO 15926:

  1. Perhaps you have some interest in an industrial plant under development, and would like to convert the 3D models that you will eventually receive from the consortium of EPCs, to one particular plant design system with which you will maintain the plant. You would like to do this efficiently as possible without having to "reinvent the wheel", so to speak, and have heard that ISO 15926 can help you do this.
  1. Perhaps you are caught in the middle, between many other players in the plant design industry, and constantly have to remind yourself to ask "what do you mean by this?", even for simple terms. You would like a common way of describing plant objects that removes the ambiguity, and have heard that ISO 15926 does that.
  1. You might have a particular interoperability problem you wish to solve. (For example, populate a purchase order directly from a 3D plant design system.) You could write your own software to do this, but you would be forever tied to a particular purchase order system and a particular plant design system. You would like more flexibility and have heard that ISO 15926 can help.
  1. Perhaps you are a player in the plant design industry and have heard of the magical power of ISO 15926. You don't have a particular problem that you know about, but you can remember the debate about converting to Windows from DOS ("Why would you ever want to run two programs at the same time?") You don't want to be left behind this time, but you don't know where to start. You want a clear (or at least clearer) picture before you commit significant resources.
  1. Or perhaps you are an individual who sees ISO 15926 as an opportunity and want to know where you can contribute.

The short answer is "If you're a number 1, go with Proteus! All the rest start with iRING!" But that only moves the question back a level: "What is Proteus? What is iRING?"

Well, funny you should ask. The following diagram is a (very) simplified depiction of how ISO 15926 came to be. We will discuss each of the predecessor organizations and projects, then show why Proteus and iRING are good starting points.

History of ISO 15926

Evolution of ISO 15926

The Demand for Digital Interoperability

Interoperability (or more correctly, the lack thereof) has been an issue ever since computers started showing up in engineering offices. At first, no one thought of it as "digital interoperability", they just said things like "Our CAD system vendor just went out of business. I wish the new system could read the old drawings." or "We've got all the data sheets typed into the computer, why can't your computer just open them?" or at an even more basic level "I wonder how we can use these new computer-thingys to improve our productivity?"


The most influential proponent of ISO 15926 in North America is FIATECH. FIATECH is the offspring of the Construction Industry Institute that was created in 1983 by the University of Texas at Austin. The purpose of the Institute was to bring together Owner/Operators, Constructors, EPCs, and suppliers to develop and promote best practices for the industry. In the late 1990s, it saw how other industries use computers and automation to increase productivity and wondered "Why not construction too?"

Out of this question FIATECH was born in 2000 with the specific mandate to use technology to improve productivity. Its target audience was the "capital projects industry", which includes oil, gas, and petrochemical plants, commercial buildings, shipbuilding, and infrastructure like roads and bridges.

POSC Caesar Association

The POSC Caesar Association (PCA) is the major proponent of ISO 15926 in Europe. It was formed as the union of two other organizations. The Petrotechnical Open Software Consortium was founded as a non-profit, vendor-neutral corporation to create standards to enable sharing information about an asset throughout its lifetime. The Caesar Offshore Project was founded by several players active in the North Sea to develop and product model for lifecycle information. With such similar goals, they joined in 1993, changing their name first to POSC/Caesar and then to the POSC Creaser Association. POSC Caesar now operates as a global standards organization with special responsibility for ISO 15926.


In Europe, many organizations have sprung up to develop what we now call digital interoperability. In 1992, a number of operating companies formed the Process Industries STEP Consortium (PISTEP) to promote the awareness of STEP (which we will discuss shortly) within the process industry. USPI-NL (you'll have to look the name up, it's a jaw breaker) was founded in 1997 by players in the Dutch process industry with the purpose of coordinating all of the standards that affected the industry. The European Process Industry STEP Technical Liaison Executive (EPISTLE) was formed in the early 1990 with a very similar purpose. Its membership was first made up directly of players in the process industries, as well as consortia who were themselves made up of industry players. Nowadays, the member companies have withdrawn, leaving only the three consortia, POSC Caesar, USPI, and PISTEP as direct members. The goal of EPISTLE is to design standards to improve the efficiency and effectiveness of information management in the process industries.

The result was the EPISTLE core model which was formally standardized as ISO 15926 Part 2 (ISO 15926-2) in 2003.

Evolution of ISO 15926

The development of ISO 15926 was through ISO 10303, which in turn started life as the Standard for the Exchange of Product Data, or STEP, in 1984. The objective was to provide a means of describing product data throughout its lifecycle, independent of any particular computer system. By 1994 STEP had been formalized as ISO 10303. It is currently used as a neutral format for information exchange in the automotive and aerospace industries.

ISO 10303 has several hundred parts. One of the parts, AP 221, Functional data and schematic representation of process plants is very similar to what would later become ISO 15926-2, but following a different architecture.

In the early 2000s POSC Caesar proposed another standard, ISO 15926, for technical reasons due to some information modeling issues with ISO 10303. The was supported by EPISTLE and the International Standards Organization (ISO). ISO 15926-4 is now the reference data library that supports both ISO 15926-4 and ISO 10303-221.


In the early 1990s, some Owner/Operators started seeing that some of the mass of information created by EBCs during the design and construction of a new facility would be a useful foundation to the information required to operate and maintain the plant. One option was to take delivery of the EPC's plant design systems. But a fundamental problem is that while there is overlap between an engineer and an operator, their needs are different; software systems that do a good job of design generally lack key abilities for operations. What was needed was a way to seed the maintenance systems with certain of the information from the EPC without having to rekey it.

There are probably as many options here as there are projects, but a key step in all of the options is to develop a data "framework", or "schema", on which to "hang" the data. Developing such a schema is anything but trivial. Many of the early players started to adopt ISO 15926-4 as the data dictionary. One such schema was released into the public domain in the late 1990s under the name XMpLant. Since that time, XMpLant has been used in over 80 projects to convert plant information from one plant design system to another one.

IDS-ADI Project

In the early 2000s, both FIATECH and POSC Caesar initiated projects to work on digital interoperability. FIATECH launched the Accelerating the Deployment of ISO 15926 (ADI) project and POSC Caesar launched its Intelligent Data Sets (IDS) project. The project's names are different, but the work of implementing their respective goals had a high degree of overlap. Fortunately the directors of both organizations quickly saw this and decided to merge the projects into one, calling it the IDS-ADI project.

Matrix 123 and Matrix 8

In the spring of 2008, a number of sub-projects were commissioned to demonstrate the capabilities of ISO 15926 at the spring 2009 FIATECH conference. (Perhaps, in a fit of Keno Reeves envy, they were are given Matrix Numbers.) The two projects that emerged from this effort were Matrix 123 (an amalgamation of Matrix 1, 2, and 3) and Matrix 8.

Matrix 123 was designed to demonstrate a realistic exchange of data between 2D and 3D design systems using the ISO 14926-4 dictionary. It was renamed "Proteus" after the Greek deity whose name has become synonymous with "versatile". Since the underlaying technology had been used a great many times with real projects, there was never any doubt about its eventual success. The project demonstrated three data flows; P&ID to P&ID, P&ID to 3D, and 3D to 3D. Each data flow involved moving information from a each of a number of commercial plant design systems to one such system, mimicking an Owner/Operator consolidating work from several EPCs, into one.

Matrix 8, renamed Camelot, was a proof of concept using all parts of ISO 15926 for information transfer. The data flow in the demonstrations were nowhere near realistic in terms of payload size, but were realistic in the kinds of information that is exchanged during a typical industrial project.

During the work on the Camelot project, the participants developed a set of tools and a methodology that could be used to implement ISO 15926. They gave this methodogy its own name, ISO 15926 Realtime Interoperability Network Grid'. The project was successful enough that a successor project, named Avalon, was commissioned to set up an infrastructure to enable iRING to continue independent of any one person or organization. Avalon proposed a method to manage code development, and wrote a business plan, called the "Avalon Service Provision", for funding.

Both iRING and Proteus continue to this day.


The ISO 15926 Realtime Interoperability Network Grid (iRING) is a collection of software and methodology to implement ISO 15926. It is open-source, using the BSD3 open source agreement, to enable anyone to use it, extend it, and (preferably) publish the extensions back into the public domain. The iRING User Group is open for membership to anyone interested, holds regular conference calls, and releases periodic software upgrades.

Similarities and Differences between iRING and Proteus

The similarities and differences between iRING and Proteus are in payload capacity, preparation require before transfer, and the manner in which data is transferred.

With Proteus, you transfer a large amount of data from a particular version of a particular plant design system to a particular version of a different plant design system. Essentially, you are making a magic decoder ring for each version of each plant design system. But rather than build a single end-to-end magic decoder ring, you make a magic decoder ring from the first plant design system to the intermediate form of ISO 15926-4 (the dictionary), and another magic decoder ring from ISO 15926-4 to the second plant design system.

In the typical use case, the objective is to move information from one or more plant design systems to another, within which the work continues. If there is any ambiguity with a particular data value, humans can look at both plant design systems, determine the meaning, and custom-make the appropriate mapping.

With iRING, you transfer a single value from within one plant design system to the appropriate spot within another plant design system. (And then do it again for another data value.) The trick here is that you don't have to know the identity of the plant design system on the other end of the exchange. To accomplish this, you map your data to the intermediate form of ISO 15926-2 (the class library). Your counter party does the same thing, and the iRING software matches up the classes. Of course both of you have to be careful how you each characterize your own data so that it will not be misunderstood. This is where you use the other parts of ISO 15926 to get the information modeled properly.

Metaphor: Humanitarian Aid to Haiti After an Earthquake

The Proteus approach to sending aid to Haiti is to load up some C-17 heavy transport aircraft with all manner of food and materiel and drop it all off in Port au Prince. Oh Wait! Port au Prince doesn't have a large enough airstrip. No Problem! We'll build one! After the crisis is over the Haitians will have really big parking lot, but that's OK.

The iRING approach is for every family in the world to be able to send $5.00 from their own bank account directly to the bank account of an Haitian family. Oh Wait! We don't have the banking infrastructure to allow a family at a random place in the world to direct money to the bank account of an Haitian family. No Problem! We'll make one! And afterwards we will be able to use the banking infrastructure for other things.

Further Development of Proteus

Although the Proteus approach has only been used for a one-time, one-way, large data transfer, there is a demand for two-way transfer on a more regular basis. The typical scenario is a large facility designed by many EPCs, where each EPC needs to see the work of others, and where the owner wants to take delivery of each EPC's work. Currently, the only way to accomplish this is to choose one plant design system, and ensure that it is implemented in exactly the same way in each EPC. The Proteus approach is have enough magic decoder rings, or the facility to build new ones quickly, that each EPC can transfer information to any of the other project partners.

Further Development of iRINg

Currently there are two issues facing the iRING approach. The first is a lack of tools that are easy enough to use that a critical mass of industry players will indeed use them. The iRING user group is working diligently to solve this. The second is the lack of a sufficiently large reference data library and a common methodology of user.

Queue JORD.

Joint Operational Reference Data

The Joint Operational Reference Data project has just been commissioned by FIATECH and POSC Caesar. As this is being written, in the late spring of 2010, the funding is being sorted out.

So Where Do I Start?

Let's go back to the original list of scenarios

1. If you want to convert a large mass of information from one plant design system to another, you are looking for a Proteus solution. This is an extremely specialized task. The good news is that you don't even need to know how to spell ISO 15926. An entire subgroup of contractors and consultants are ready to server you. Search for "XMpLant" and "Proteus". You will see a bunch of names popping up over and over. Call one of them.

2, etc. For the rest you , some work will be required. The best first step is to join FIATECH or POSC Caesar. You will immediately be part of a group of like-minded organizations and individuals. At the current stage of development of ISO 15926, most of the players have a vested interest in helping others. once the adoption of the standard has hit a critical mass, many will turn back into competitors.

If you live in a litigious culture there is another benefit of joining one of these organizations. When you talk to a competitor you are always at some risk of contravening anti trust legislation. but if you discussion (with people who work for a competitor) is under the umbrella of an industry standards organization you are protected.

The best second step is to actively join the iRING Users Group with the intent of contributing. This will give you a very good understanding of what is involved, and the attention of people that can help.

The rest of this works is devoted to filling in the blanks

1. Learning Resources

2. Case Studies

3. Interoperability Theory

4. Public tools and how to use them

5. Database Mapping Techniques





You have no rights to see this discussion.


About PCA
Reference Data Services