Version 81 (modified by gordonrachar, 10 years ago)


Introduction to ISO 15926


If you are new to the concept of information interoperability, you will be forgiven for thinking that ISO 15926 is a new phenomenon. In fact, the search for easy ways to exchange and reuse engineering information stretches back to the mid 1970s-led by increasingly frustrated end users who resented the inability to transfer their information from one computer-aided design (CAD) system to another.

This bit of history is especially poignant for your humble author, who at that time was just starting his career as a piping designer. Whereas large users-heavily represented by the U.S. military and aerospace organizations-were just starting to confront compatibility issues among competing CAD systems, your author had just enrolled in technical school to learn how to draft with a pencil. A few years later-while the U.S. Air Force was hosting a conference that led to the CAD drawing exchange standard known as IGES (which we introduce in Chapter 2)-the author's idea of high technology was drafting on Mylar with (gasp!) plastic lead!

In this introduction to ISO 15926, we will look at the need for information interoperability, some of the things that have been done to address interoperability issues, and some of the things we should be doing instead. We will take a brief historical look at the forebears of ISO 15926, look at the different parts that make up the standard today, and end with some of the things you can do to get started implementing the standard.

The obvious question is: Why do we need ISO 15926? The short answer is: So that we can exchange and reuse complex plant and project information more easily and more cheaply. A slightly longer answer is: To mitigate the current high costs of rekeying and reformatting information to move it from one proprietary system to another. For example, take the task of designing, specifying, and purchasing a process instrument for a plant modification. Imagine how many times information has to be rekeyed after the instrument is basically designed, until it is installed and commissioned in the target plant.

  • After design, enter the information into the project's engineering design system (which may be a database or spreadsheet).
  • For quotation, a procurement officer assembles several sets of data sheets and sends a set to each bidder.
  • Each bidder will have a sales engineer read the data sheets and enter some of the data values into proprietary software to make a selection, and then compose a quotation and return it to the engineering, procurement, and construction (EPC) contractor.
  • During the design of an instrument, the engineer will usually specify only those properties necessary for operation under process conditions. However, there are many other properties that must be known-which are dependent on the manufacturer. After the vendor has been chosen, the design engineer has to enter this information manually into the engineering design system from the vendor's quotation.
  • Data sheet turnover to the client will likely be something like an Excel file for each data sheet.
  • After receiving a load of boxes filled with CDs from the EPC contractor, the owner will review each data sheet. Critical data values will be rekeyed into an asset management system. This can take months.

The situation is improving. A few years ago engineers would have faxed the data sheets to the vendors, who would manually add their information and fax them back. Now they E-mail editable electronic files back and forth. And more recently, some owner-operators are trying to streamline the final handover from an EPC contractor by specifying data requirements. However, configuration costs and the lead time required speak to the complexity of the issue.

What we need is a way for each participant's software to be able to communicate complex information to the other participants without having to know in advance things such as database structure or format. If you have ever read The Hitchhiker's Guide to the Galaxy, by Douglas Adams, you will know exactly what we need-we need a Babel fish! In the book, if you wanted to listen to Vogon poetry spoken in the original dialect you would use a Babel fish.

Error: Macro Image(Introduction_BabelFish.JPG) failed
Attachment 'wiki:ISO15926Primer: Introduction_BabelFish.JPG' does not exist.

The Babel fish would listen to the Vogon speaking, and then rearrange the syntax and translate all of the words on the fly. ISO 15926 acts like a Babel fish by acting as an interpreter between two otherwise incompatible systems. Let's compare the process of specifying and purchasing an instrument in the previous example to doing the same thing with tools that support ISO 15926 protocols. The initial data entry is the same.

Example: Exchanging Instrument Information Using ISO 15926

Compare the process of specifying and purchasing an instrument above, to doing the same thing with ISO 15926-enabled tools.

The initial data entry is the same:

  1. After design, enter the information into the project data store, likely an Excel spreadsheet or a database.

But thereafter, tools written to support the ISO 15926 standard extract the relevant information automatically:

  1. For quotation, a procurement officer will expose the Request for Quotation on his company's public interface, known as a "façade", then include the URL in an e-mail to the bidders.
  2. By connecting to the EPC's façade, each vendor will pull in the relevant information for each instrument. At this point, the vendor has a choice. He can have a human sales engineer read the information and manually make decisions in the same manner we use today. However, because it is in ISO 15926 format, the instrument information will be rich enough that analysis, decisions, and composition of a preliminary quotation will be able to be done by a computer program. In this case the sales engineer will only have to review the quotation before submitting the bid to the EPC.
  3. After selecting the winning bidder, the engineer will point his 3D engineering design system to the vendor's façade and pull in vendor-supplied information.
  4. Data turnover to the client will simply require exposing the plant information database on the EPC's façade.
  5. The owner will open the link to the engineer's plant information database and import whichever data values are of interest.

You can see that if we use 15926 tools we are removing a great many opportunities for human error. So in addition to being able to transfer information faster, by removing the labor-intensive tasks the whole process will be more reliable. (And, I might add, the job of the design engineer gets considerably less boring!)

How ISO 15926 Makes Sharing Information Easier

ISO 15926 is a world-wide standard for exchanging complex information about plant objects. If everyone uses a common standard a number of things will be easier:

  • We can exchange information without having to know anything about each other's data storage configuration.
  • Information will be transferred directly from machine to machine without having to be rekeyed.
  • The information will be transferred with high fidelity. We will not need human beings to review the information to make sure nothing is lost or added.

Everyone will still have their own data stores, perhaps in a proprietary format, perhaps not, but will employ a Babel Fish (known as a "façade") when we exchange information with others. This will enable a number of interesting scenarios:

  • A consortium of EPCs will be able to collaborate on designing a plant, each using its chosen plant design system with proprietary work processes. They will be able to share information without having to know anything about each other's data storage format beforehand.
  • During design, vendor's and EPC's software will be able to connect to each other, so passing information back and forth will be much easier.
  • EPCs will be able to take ownership of the rules in Rules Based Engineering. Currently, some 3D design systems support this, but the rules are bound to one system. With ISO 15926, the rules will be portable.
  • Information turnover from EPC to Owner will be a non-issue. Owners will be able to receive the plant data by connecting to the EPC's Babel Fish (i.e., façade) and then store it in the their own format.
  • After information turnover, any of the owner's computer systems will be able to use the information. For instance, a Plant Operations System will be able to access the pieces of information it needed. A Plant Maintenance System will be able to access just the pieces it needs. Each application will take the pieces it needs and ignore the rest.
  • Owners will be able to harmonize maintenance systems between production facilities that have incompatible information storage formats.

Useful Metaphors



About PCA
Reference Data Services (RDS)
RDS Operations Support
Meetings and Conferences
ISO 15926
Special Interest Groups
Technical Advisory Board
Norwegian Continental Shelf Std