An Introduction to ISO 15926 November 2011 - iRINGToday

ELEMENT 8 WORKFORCE & TRAINING
An Introduction to
ISO 15926
November 2011

An Introduction to
ISO 15926
November 2011

ACKNOWLEDGMENTS
Fiatech has produced this book at the request of and for the benefit of its members, and in
cooperation with the POSC Caesar Association. We wish to acknowledge the contributions of
those individuals whose efforts and input have significantly influenced this publication.
Notably, this book was produced by a project team who voluntarily carried out the objective
to provide an introductory document for the Capitol Projects Industry. This team consisted of:
Manoj Dharwadkar, Director, Product Management, Bentley Systems; Glen Worrall, Solutions
Architect, Bentley Systems; Onno Paap, Data Integration Manager, Fluor; Faith Junghans, President,
Faithful Engineering; Chris Schwander, Consulting Engineer, DuPont; and Alan Johnston,
President, MIMOSA.
In addition, Ian Glendinning, Glenco, President, GlencoIS; Hans Teijgeler, Fluor (retired); and
Matthew West, Information Junction; provided considerable technical expertise and content
during the writing process.
I wish to acknowledge the special efforts of Gordon Rachar, WorleyParsons who served as a
consultant to the project and was the primary author of this publication. Additionally, Daril
Bentley provided copyediting services and Dallas Peters, Dallas Peters Design, assisted in
graphic design production.
Among the staff, Fiatech Project Manager, Sharon Bickford, contributed significantly to the
development of this publication and her efforts are appreciated.
Publication of this report is made possible through the contributions by Fiatech members.
Raymond E. Topping, PE
Director, Fiatech

PREFACE
Fiatech (www.fiatech.org) is an industry-led consortium, housed at The University of Texas at
Austin that provides global leadership in identifying and accelerating the development, demonstration
and deployment of emerging technologies and innovative practices to deliver the
highest business value throughout the life cycle of all types of capital projects.
Fiatech is member-driven, comprised of approximately 85 companies and partner organizations
that include owners and operators from the industrial, power, and retail markets; leading
providers of engineering, design, and construction services; software and equipment suppliers
and technology providers, research institutes and universities. Fiatech is a clearinghouse for
innovative ideas where members can quickly learn about new processes, methods, and materials;
but it also collectively funds and executes development, demonstration and deployment
projects. Project teams are formed to identify and accelerate the adoption of technologies
and systems; demonstration projects are conducted to validate and perfect new approaches
or methods; and teams are formed to aid and facilitate the deployment of those breakthrough
initiatives that have been identified.
This publication was developed at the request of Fiatech members and in cooperation with
the POSC Caesar Association, for the benefit of the entire capital projects industry.

TABLE OF CONTENTS
INTRODUCTION 1
Introduction to ISO 15926 1
ISO 15926 Is Like a Babel Fish 3
About This Book 6
Why We Need ISO 15926 8
The History of ISO 15926 8
How Does ISO 15926 Work? 8
Current Events in the World of ISO 15926 9
Getting Started with ISO 15926 10
Appendices 11
CHAPTER 1: WHY WE NEED ISO 15926 12
The Role of Context in Information Exchange 13
The Value of the ISO 15926 Dictionary 18
A Confederation of Applications 22
Public Extensible Dictionary 27
An Example Project 29
How ISO 15926 Makes Life Easier in the Near Term 31
How ISO 15926 Makes Life Easier in the Long Term 36
CHAPTER 2: HISTORY OF ISO 15926 40
How We Use the Internet to Find Information 41
How We Know and Understand Things 42
Open Ways to Store and Exchange Data 44
Markup Languages 46
Evolution of Product Information Standards 48
Summary 67
CHAPTER 3: HOW DOES ISO 15926 WORK? 70
Integration Versus Interoperability 70
The Parts of ISO 15926 Are Like the Parts of Human Speech 74
Putting It All Together 91
Levels of Compliance with ISO 15926 Versus Ambiguity 93
Wouldn’t It Be Better if We Agreed on Common Definitions? 95
Why Don’t We Use Industry Standard Definitions? 97
Would It Help If I Told You How I Was Using the Data? 99
If We Use the Semantic Web, Couldn’t We Automate More of This? 101
Shouldn’t We Add Query, Workflow, and Security to the Semantic Web? 103
CHAPTER 4: CURRENT EVENTS IN THE WORLD OF ISO 15926 105
Using ISO 15926 in Production 106
Development of Enabling Infrastructure 110
Continued Development of Standards 113

CHAPTER 5: GETTING STARTED WITH ISO 15926 116
Key Preparation 117
Implementing ISO 15926 118
Join Fiatech or the POSC Caesar Association 123
APPENDIX A: THE PARTS OF ISO 15926 124
ISO 15926 124
APPENDIX B: COMPLIANCE WITH ISO 15926 128
Semantic Precision 129
Representation Technology 129
Referencing Technology 130
Interface Technology 131
Industrial Standardization 131
Subject Matter Scope 132
Metadata Scope 132
Functional Capability 133
APPENDIX C: EXAMPLES OF DATABASE MAPPING 134
Example Set 1: Let’s Just Exchange Raw Data and Figure It Out Together 134
Example Set 2: Wouldn’t It Be Better to Agree on Common Definitions? 141
Example Set 3: Why Don’t We Use Industry Standard Definitions? 147
Example Set 4: Would It Help if I Told You How I Was Using the data? 151
EMCA 156
Using the RDS/WIP 158
APPENDIX D: OTHER RESOURCES 160
Information Modeling Resources 160
Origin of ISO 15926 161
Organizations Responsible for ISO 15926 161
User Groups 162
Other Organizations 163
RDS Browsers 164
Business Interface Definition Guides 164
GLOSSARY OF CONCEPTS 167
Artificial Intelligence and the Semantic Web: Difference Between 167
First-order Logic, Semantics, and Reference Data 167
Ontology and Taxonomy: Difference Between 169
Integration and Interoperability: Difference Between 170
Strong Coupling, Loose Coupling, and Encapsulation 171
Abstraction 172
Semantic Web Technology 173

INTRODUCTION
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 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.
INTRODUCTION
1

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.
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.
• After design, enter the information into the project’s engineering design system (which
may be a database or spreadsheet).
However, thereafter tools written to support the ISO 15926 standard extract the relevant information
automatically.
• For quotation, a procurement officer will expose the Request for Quotation on his company’s
public (or secured) ISO 15926 interface and then send a link to the bidders.
• By connecting to the EPC contractor’s ISO 15926 interface, 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 contractor.
• After selecting the winning bidder, the engineer will point his engineering design system to
the vendor’s ISO 15926 interface and pull in vendor-supplied information.
• Data turnover to the client will simply require exposing the plant information database on
the EPC contractor’s ISO 15926 interface.
INTRODUCTION
2

• The owner will open the link to the engineer’s interface and import the information.
You can see that if we use tools that support ISO 15926 protocols we are removing many opportunities
for human error. Thus, in addition to being able to transfer information faster by
removing the labor-intensive tasks the entire process will be more reliable. (At the same time,
the routine parts of the sales engineer’s job are removed leaving more time for more innovative
tasks and talking to customers.)
One of the reasons ISO 15926 will make it easier to share information is that it is worldwide. If
everyone uses a common standard, a number of things happen.
• We can exchange information without having to know anything about one another’s data
storage configuration.
• Information can be transferred directly from machine to machine without having to be
rekeyed.
• The information can be transferred with high fidelity. We will not need human beings to
review every data value 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” (an ISO 15926 interface) when we exchange information with
others. This will enable a number of interesting scenarios.
• A consortium of EPC contractors will be able to collaborate on designing a plant, each
using its chosen engineering design system with proprietary work processes. They will be
able to share information without having to know anything about one another’s data storage
format beforehand.
• During design, vendor and EPC contractor software will be able to connect to each other—
and thus passing information back and forth will be much easier.
• Information turnover from EPC contractor to owner will be a non-issue. Owners will be able
to receive the plant data by connecting to the EPC contractor’s “Babel fish” (the ISO 15926
interface) and then store it in 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.
To help you imagine what it will be like when ISO 15926 is mature, let’s look at three metaphors.
ISO 15926 Is Like a Babel Fish
We have already mentioned The Hitchhiker’s Guide to the Galaxy. In it, Arthur Dent hitches a
ride on a passing Vogon spaceship just moments before the spaceship blows Earth to smithereens
to make way for an interstellar bypass. When he is discovered by a Vogon, Arthur is
given a “Babel fish” to put in his ear. The Babel fish enables Arthur to understand what the
Vogon is saying. From the book:
The Babel fish forms a symbiotic relationship with the person who carries it in
his ear. The Babel fish feeds on the brain wave energy from around its host. It
INTRODUCTION
3

absorbs the unconscious mental frequencies from this energy, more or less, as
food. Its excrement is a so-called telepathic matrix of conscious thought frequencies
combined with the nerve signals from the speech centers of the brain
which supplied them, which is picked up by the mind of the host. Basically, then,
if you stick a Babel fish in your ear, you can instantly understand anything said
to you in any language.
Bringing this metaphor into the field of plant design, ISO 15926 is similar to a Babel fish in that
it translates the descriptions of plant objects from one company’s database to that of another.
The important thing to note here is that the meaning of all the terms is maintained. You do not
have to rely on the context of the information to know what individual terms mean.
The metaphor of the Babel fish is a pretty good one, but there is a slight difference. The Babel
fish translates thoughts directly from Vogon into English in one operation. ISO 15926 will do
this in two steps using a middle, neutral layer. If you used ISO 15926 to translate Vogon to
English, it would first translate Vogon into intermediate standard descriptions and then from
these standard descriptions into English.
Using a middle layer of standard descriptions is an important step we will examine in more
detail, but briefly the middle layer is what makes it all work. Each organization’s “Babel fish”
(which we will call an ISO 15926 interface from now on) only has to understand these standard
descriptions, not the descriptions in the proprietary operations of every business partner.
ISO 15926 Is Like HTML
In case you don’t know what Hypertext Markup Language (HTML) is, you can rest assured that
you are a part of a very large majority. HTML is the common language of the World Wide Web.
Every web page you have seen is written with some variant of it. If everyone involved in plant
design, construction, and operations were to use ISO 15926 to exchange information about
plant objects, we would have an equivalent to the HTML experience—but between machines.
For instance, if you want to look at the web page of a pump manufacturer you don’t need to
know anything beyond the web site address of the company. When your browser connects to
the web site, it assumes that what it finds will be encoded in HTML. Of course, it will be—if the
manufacturer wants to get any business through the web page—because HTML is the standard
format of the World Wide Web. In addition, it does not matter which browser you use.
Internet Explorer, Firefox, Safari, Opera, and Netscape are all written to understand HTML.
Imagine the hassle if you first had to contact the pump manufacturer and ask for the encoding
format, and then instruct your IT folks to write a translator program, before you could access
the web site? Of course, you would not do it. And of course the pump manufacturer would not
make a web page like this in the first place because no one else would do it either.
This metaphor does a good job of describing what the average user will have to know about
ISO 15926 as well. In the same way that most people who use the World Wide Web do not
need to know about HTML, most users of ISO 15926 will not have to know about it to exchange
information. When ISO 15926 is mature, it will simply be built into the software we will
all use. Engineers will be able to exchange information much more easily than they do now,
and very few of them will need to know that the standard exists.
On the other hand, many web sites today are actually written in HTML. This metaphor implies
INTRODUCTION
4

that a large proportion of plant information will actually be stored in an ISO 15926-compliant
data structure. Although this is certainly possible, it will probably not be the case. Most
companies will maintain their plant information in the proprietary format they currently use.
Instead, they will write a public interface to render the information in ISO 15926 format when a
business partner asks for it.
In this regard, ISO 15926 is more like the case today whereby a database is exposed to the
World Wide Web. When a user queries the database (via her web browser), a program dynamically
searches the database and renders the results in HTML “on the fly.”
There is another similarity that may appeal to your geeky side. HTML and ISO 15926 are standards
that were developed along similar trajectories. Although the underlying infrastructure
that enabled the Web started to form in the last quarter of the twentieth century, most of us
only discovered it 20 years ago. At first there was some controversy as we speculated about
its possibilities. Some of the ideas caught on and some didn’t, but over time “surfing the web”
just became part of our lives. Now many of our young people cannot imagine life without it.
Similarly, many people are just now finding out about ISO 15926—even though the standards that
led to it first started to appear in the mid twentieth century. As with any new technology, there is
some controversy and speculation on its future. However, the demand for the interoperability of
information is strong and over time ISO 15926 will work its way into the way we do business.
ISO 15926 Is Like English on Your Cell Phone
If you and I were not close together but needed to talk about something, we might decide to
use our cellular telephones. There is a great deal of complexity hidden from the view of the
casual user. One of us could be in a digital roaming area while the other is in an analog area.
One, or both, might be in a vehicle traveling at high speed down a highway—moving from one
cellular area to another very quickly. We could be on different continents. All this is handled
automatically by the software and circuitry that makes up the cellular telephone network.
None of this would do either of us any good, however, if you spoke Mandarin and I spoke
Cantonese. Mandarin and Cantonese are dialects within the same language family, but are far
enough apart that it is difficult for native speakers of one to understand native speakers of
the other. Thus, to communicate with cell phones we would have to agree to speak the same
language. In that China has one of the highest populations of English speakers of any country
in the world, it is quite possible that we both speak English.
To talk to you using English, I would first translate the words and sentence structure from
Cantonese to English. When you heard me speak, you would translate the words and sentence
structure from English to Mandarin and (hopefully) understand what I said.
INTRODUCTION
5

Hello
Use a mental dictionary to
translate Cantonese to
English
Hello
Use a
mental
dictionary
to translate
English to
Mandarin
In this metaphor, ISO 15926 takes the place of English. ISO 15926 is a common “language” for
exchanging information about capital projects. It would not matter how either of us stored our
plant information, at the interface we would “translate” it to and from ISO 15926.
This is quite a good metaphor in that each of us would continue to think and work in our
native language (me, Cantonese; you, Mandarin) but would encode/decode the message to
the common language of English more or less on the fly. Similarly, organizations that use ISO
15926 to communicate with each other can continue to use proprietary systems internally.
This is a good metaphor in another way as well. The complexity of managing the call is hidden
from cell phone users. You and I can contact each other by simply calling each other’s cell
phone number. You don’t have to call a different number if I am away from my office. I don’t
have to use a different protocol if you have a digital phone or an analog phone. You don’t
have to know if I am at home or at ball game. The cellular network figures out where we are
and directs our calls through the closest transmission tower. Similarly, by using ISO 15926 we
will all be spared the detail of matching our own information systems to those of our business
partners.
A major difference is in what people will have to know about ISO 15926 in order to use it. This
metaphor implies that users will have to know ISO 15926 almost as well as they know their
native tongue. In fact, most people will not even have to know how to spell ISO 15926—it will
simply be built into whatever computer system they are using. To extend the cell phone metaphor,
it will be as if an intelligent English translator is built into both cell phones. I would speak
my native Cantonese into my phone and you would hear your native Mandarin in yours.
About This Book
This book is intended for those who know a great deal about capital project work but not a lot
about the software by which projects get done, those who know a lot about the software but
not a lot about capital project work, and the poor folks in the middle who are just trying to
make a living using software. This book is intended to be the first book you read after hearing
about ISO 15926.
INTRODUCTION
6

Although it describes some complex technology and includes many three- and four-letter
acronyms, the explanations are functional (“How does this help data exchange?”) rather than
procedural (“First press this button, then that one…”) If you have a background in any part of
engineering projects, you will have a knowing, wry smile when we talk about our past and existing
ways of dealing with data exchange. But even if you do not have such a background you
will still be able to follow the discussion.
Managers
Managers; engineering managers, construction managers, and plant managers generally know
a great deal about engineering, construction, and plant operations; but typically not a great
deal about the computer systems that make their operations run. As such, they may view
the claims of ardent proponents of ISO 15926 with a certain amount of suspicion. This introduction
to ISO 15926 reviews the practical issues with information exchange today (to show
where money is being wasted), describes the theoretical and practical work that has been
devoted to the development of ISO 15926 (to show that it is viable), and shows how ISO 15926
will make everyday tasks easier (to show where the opportunities lie).
Computer Professionals
Depending on their area of expertise, computer professionals may already have heard about
information exchange and the Semantic Web. What they may not be aware of, however, is the
business context of the capital projects industry where their computer systems are used. This
book describes several situations project personnel encounter in real-world scenarios, shows
traditional solutions, and contrasts them with the way ISO 15926 would be used to make their
life easier.
Casual Users
Because of the way it can be implemented in software, when ISO 15926 is mature many users
may not know it exists. But in the transition there might be something like an “ISO 15926”
button to push. This book will show what happens under the hood when it is pushed. As well,
users will see the growing opportunity for discipline professionals to get involved and will encounter
a few ideas for doing so.
How This Book Is Organized
This book is divided into five main chapters and several appendices.
• Why We Need ISO 15926
• The History of ISO 15926
• How Does ISO 15926 Work?
• Current Events in the World of ISO 15926
• Getting Started with ISO 15926
• Appendices
• Glossary
INTRODUCTION
7

Why We Need ISO 15926
Traditional ways of exchanging and reusing information all involve some variant of having
someone read one document and then decide which parts to transcribe to a different document.
This is true whether we are moving a single value from one data sheet to another or
mapping entire databases together. Even with modern computer technology, we still rely on
highly skilled people to interpret information and to discern which data values are important.
For this we rely on a surprising amount of context. For instance, when we look at a data sheet
we rely on visual cues and our experience. When we map databases together, we deal with
attribute names that are usually inadequate in themselves to make fine distinctions between
similar terms. To understand what our data means, we need more information than is contained
in the data itself.
This affects us whenever we attempt to exchange information. An obvious large information
exchange is the handover phase of a project. Even though a fully electronic handover is quite
possible today, the documents that are handed over are often still formatted for humans.
Currently, when we hand over information we still have to think about how it is to be accomplished.
This adds friction, making many exchanges uneconomic. When ISO 15926 is mature,
the mechanics of information exchange will fade into the background—allowing more exchanges
to take place economically.
The History of ISO 15926
The reason information exchange, as envisioned by ISO 15926, is possible now is because of
the convergences of four areas of study. The study of how we know things, ontology, gives us
techniques for embedding meaning into data. The Semantic Web gives us the tools to do so.
Open ways of encoding data make it practical to do so. But the most important is the evolution
of product information.
With the advent of CAD software in the late 1970s, we have continually played the role of
Oliver Twist: “Please sir! Can I have more?” At first, all we wanted was to be able to exchange
CAD drawings without having to redraw them and got CAD exchange standards such as the
Initial Graphics Exchange Standard (IGES). Then we wanted the product information that is
behind the drawings in many manufacturing systems and got a standard called STEP, which
we will become very familiar with in the coming chapters. Later, as we tried to apply the principles
of STEP to long-life process plants STEP itself evolved into ISO 15926.
The core of ISO 15926, the data model (called Part 2), and the dictionary (called Part 4) have
been developed in the heat of battle on several large, world-class projects. Dictionary-level information
exchange is now routine. We are poised for an even greater increase in productivity
with the development of techniques for embedding meaning into our information exchanges.
How Does ISO 15926 Work?
“Your computer can talk to my computer and neither of us has to know anything about each
other’s systems beforehand” sounds somewhat magical. Readers are excused for being somewhat
skeptical. But when you consider what actually needs to be exchanged the claim of ISO
15926 becomes more believable. The engineers, fabricators, constructors, and plant operators
INTRODUCTION
8

who need to exchange information all work with the same physical objects—just in different
ways. Each job function needs different information about the same object.
For instance, engineers need to know the size envelope and functional performance; fabricators
need to know the material and fabrication methods; constructors need to know the mass,
envelope, and delivery; and operators need to know how to maintain it and where the spare
parts are. There is some overlap, but because the computer system each uses is optimized for
particular job functions it is not surprising that the computer systems cannot understand each
other even if they actually contain the same information. What ISO 15926 does is to capture a
view of everyone’s data so that each can pull out what they need.
Imagine the situation of two people, each with their own native language, together learning a
new foreign language. They will first learn the names of objects they are familiar with, essentially
building a new dictionary. Then they will learn to master a new way of expressing ideas,
which is learning new rules of grammar. While learning the new language, they will practice
writing it on some type of media (such as a whiteboard, paper, or, for the sake of argument,
a stone sculpture). Eventually, if they master the new language well enough and others seek
them out they may need a way to regulate access.
The parts of ISO 15926 are like the parts of human speech. Part 2 is the data model equivalent
to the rules of grammar, and Part 4 is the reference library, equivalent to the dictionary. When
any two people use the same rules of grammar and use the same dictionary, they can communicate
freely. Similarly, when two machines encode an information exchange using Parts 2 and
4 they can communicate freely. This is the core of ISO 15926. Part 7 contains what are called
templates, and is like a phrase book that allows new users to construct a meaningful sentence
a bit sooner. Part 8 is like the writing media, and Part 9 is like a web site or the postal service.
Current Events in the World of ISO 15926
ISO 15926 is being used around the world more every year. Parts of ISO 15926 are being used
in real projects, development of infrastructure to support ISO 15926 information exchange is
ongoing, the standards themselves are continuing to be developed, and educational materials
are being created.
Plant Operations
The Norwegian Continental Shelf is one of the major oil-producing regions in the world. The
harsh environment has led to a strong need to automate information exchanges to and from offshore
facilities. Integrated Operations in the High North (IOHN) is a multi-year initiative to implement
this, combining the efforts of all operators in the area. ISO 15926 is part of the data layer.
The safe start-up, operation, and maintenance of an operating plant is often limited by a lack
of early information about plant equipment and controls. A large bitumen upgrader, planned
for startup in Canada in 2015, is part of a pilot project to develop strategies to improve information
handover. The Operations and Maintenance SIG (O&M SIG) of Fiatech and the POSC
Caesar Association (PCA) are reviewing all relevant information standards, including ISO
15926, and will use them to develop best work practices for information creation and handover.
INTRODUCTION
9

Development of Enabling Infrastructure
One aspect of information exchanges, as envisioned by ISO 15926, is that the definitions of
terminology be publicly accessible in real time during the exchange. This will allow the participants
to validate terms, which will remove ambiguity and reduce costs. Until now this has not
been possible for production work due to lack of facilities. The Joint Operational Reference
Data (JORD) project is developing the infrastructure and funding to bring a public reference
data service (RDS) into operation. It builds on several years of experience in operating an RDS
that supported standards development work.
We have used dictionary-level information exchange for years using ISO 15926 Part 4. This
works well in high-value situations that can afford the brute-force approach of understanding
equivalent information objects on each side of the transaction and mapping them together.
But with the pace of business increasing we need to be able to exchange information easier
without having to do so much preparation. To do this we will have to use the full specification
of ISO 15926. The iRING user group is developing tools, available free of charge with an
open-source license, to implement ISO 15926 parts 7, 8, and 9. The tools will more or less clip
on to the side of commercial software to allow information exchange between any similarly
equipped software.
Continued Development of Standards
The Geometry Special Interest Group (Geometry SIG) of Fiatech and PCA is developing a
reference library for the geometrical shapes used in 3D modeling software. Current tools for
exchanging graphics strip out all of the meaning. (This means we can exchange the surfaces
of plant objects but not their identity.) The geometrical reference library will be issued as ISO
15926 Part 3, which will allow us to exchange graphics as easily as we exchange other data.
One barrier to the wide use of ISO 15926 is that best practices for using Part 7 templates are
not yet common knowledge. The Instrument Special Interest Group (Instrument SIG) of Fiatech
and PCA is creating recommended templates for describing industrial instrumentation.
Because the management of instrumentation is crucial for the safe and profitable control of a
plant, the Instrument SIG is working closely with the O&M SIG.
Many information standards exist today for various niches in heavy industry. Two such standards
have recently been harmonized with ISO 15926. Under the guidance of Fiatech’s Engineered
Equipment Life Cycle Application Tools project (EELCAT), what is known as the AEX XML
schema (developed by another Fiatech project, Automated Equipment Information Exchange)
and the Hydraulic Institute’s Standard HI 50.7-2010 for Electronic Data Exchange for Pumping
Equipment have been brought together. HI 50.7 is a dictionary of data fields from many wellknown
standards along with the AEX schema. The EELCAT project has recently examined the
two standards and has demonstrated how they can be further harmonized with ISO 15926.
Getting Started with ISO 15926
With any new technology, there is uncertainty about what can be realistically accomplished.
Implementing ISO 15926 is easily within reach of most organizations, probably without having
to hire additional staff. At the introductory level, implementing ISO 15926 is similar to traditional
methods of exporting information from one application and importing it into another.
INTRODUCTION
10

Open-source and commercial tools exist to assist in both dictionary mapping at the introductory
level and the more advanced use of ISO 15926 Parts 7, 8, and 9.
Appendices
The preceding fulfills the promise of an introduction to ISO 15926. For those who wish to
know a bit more, we have included several appendices:
• Appendix A: The Parts of ISO 15926
• Appendix B: Compliance with ISO 15926
• Appendix C: Examples of Database Mapping
• Appendix D: Other Resources
• Glossary of Concepts: Contains extended explanations of key concepts, including
key terminology
INTRODUCTION
11

CHAPTER 1:
WHY WE NEED ISO 15926
It is difficult to overestimate the value of being able to exchange information with anyone
without fear of transcription error, while maintaining the precise meanings of all terms, even
though you know nothing at all about your partner’s internal work processes and methods of
data storage. When information is transferred correctly, the quality and reliability of your end
product increases. When you know for sure that information will be transferred correctly, you
can move faster because you do not have to check for transcription errors.
A significant part of designing, building, and operating capital assets involves transferring and
accessing information about those assets. In its oft-cited 2004 report Cost Analysis of Inadequate
Interoperability in the U.S. Capital Facilities Industry, the National Institute of Standards
and Technology (NIST) reported claims of some companies that 40 percent of engineering
time was spent finding and verifying information. Overall, the study showed that the lack of
interoperability among computer-aided design (CAD), engineering, and other software systems
costs the American capital projects industry more than $15 billion every year. 1
ISO 15926 makes exchanging information between applications easier in two ways. First, when
your information exchanges go beyond manually rekeying data or using point-to-point custom
mapping (which we discuss shortly) you need to create some type of data dictionary containing
definitions of all objects in your facility—along with their attributes. If your organization is
sufficiently large, this requires a significant effort. Instead of developing your own dictionary,
ISO 15926 offers a dictionary 2 that you can use free of charge. Because the ISO 15926 dictionary
has been developed by a great number of people from many industries in many parts of
the world, there is a high probability that the definitions you need are already there.
Second, when we exchange information today we need people to manage the transactions
because we mistakenly assume a consistently applied background of rules and jargon of the
trade. We call these background rules “context,” and without context we are lost. We need to
be able to apply these rules consistently in order to correctly match terminology in a universe
of very similar terms.
If we use the full specification of ISO 15926, we can make information exchanges easier by
essentially building the context of the information into the information itself. When we model
the information, we can capture the precise meaning of each term and embed it with the
term. This makes it easier for machines to talk directly to each other because implied meanings
that participants are “just expected to know” are eliminated (or at least minimized).
These two issues are intertwined. To fully understand the value of simply being able to use an
existing data dictionary, instead of having to develop one from scratch, we will first discuss
the sources of information exchange costs. This will leads to a discussion of “context” and
1. The report is available online. Search for “Cost Analysis of Inadequate Interoperability in the U.S.
Capital Facilities Industry.”
2. Truth in advertising: Data exchange in the manner envisioned by ISO 15926 requires more than just
a dictionary. We are simply starting with a description of how the dictionary component works as a
way of easing into the topic.
CHAPTER 1
12

what it means in information exchanges.
After understanding the role of context, we will return to the way we manage information
exchange today. We will discus the way small, ad-hoc manual exchanges can develop into
organization-wide networks of linked applications. The value of the simple existence of ISO
15926 will be apparent when we discuss the issues of managing this organization-wide network.
We conclude with some examples of information flows today and show how ISO 15926
will make them easier.
The Role of Context in Information Exchange
Information exchange today requires the skills of experienced people because we rely to a
great degree on the context in which we find information to understand the precise meaning
of the information 3 . Figure 1.1 shows someone with a bright idea. To achieve some business
result, he has to pass the information to someone else. If he just sends the information without
context, he is just throwing it all in a bag and hoping the person on the other end can figure it
out.
Fig. 1.1 Putting information in a bag.
When we encode information using the full specification of ISO 15926 (including all of the
components we will discuss later), we include enough context that other ISO 15926–enabled
tools will clearly understand what we mean (Figure 1.2). We no longer have to know anything
about the partners with whom we exchange information.
3. The “information in a bag” diagrams are courtesy of Robin Benjamins.
CHAPTER 1
13

Fig 1.2 Putting information in an ISO 15926 bag.
When your humble author started his career in plant design, computers were not commonly
used by designers and engineers. Drafting was done by pencil on paper. Specifications were
written with a typewriter. When information had to be transferred from one document to
another, the only way to do it was for a human to read the original document, find the value to
be transferred, and then write it by hand on the target document. If the target document was
something like a specification, it was usually given to a secretary for typing.
Transferring data to the owner at the end of the project was cumbersome but conceptually
simple: you would take all of the specifications and drawings, sort them into some logical order,
perhaps bind them into books, and move them to the new location. Data turnover to the client
at the end of a large project was similar to the last scene of the movie Raiders of the Lost Ark. In
that scene a forklift carried a wooden box down a long aisle of identical wooden boxes and put
it on one of the piles, something like that depicted in Figure 1.3. In the real world, it sometimes
took years for the owner to review all of the boxes and categorize the binders of information.
Fig 1.3 Data handover the old way.
CHAPTER 1
14

No one really liked this (as in “I really liked that piece of chocolate cake, may I have another!”),
but that was just the way it was. Everyone just built such manual tasks into their plans. Things
started to change when computers made their way into the design office. Binders of data
sheets gave way to spreadsheets burned onto CDs and then DVDs, graphite pencils gave way
to electronic pencils (i.e., CAD), and rolls of Mylar drawings gave way to CAD files burned
onto more DVDs.
These days, when the owner receives the material it is physically easier to sort through boxes
filled with DVDs than to sort through boxes filled with paper but the documents still have to
be reviewed individually. On a moderately large project, it can still take a crew of people many
months to index it all and bring it into the owner’s system—and until a document has been
received by the document management system it is essentially invisible.
There have been improvements, but things have not changed much conceptually. In our work
processes for plant design or plant operations, a large proportion of an engineer’s activities
still involve finding information and manually transferring it from one document to another.
For instance, after the engineer chooses, say, an instrument from a manufacturer’s catalog
the only practical way to record the information about the instrument is to read the manufacturer’s
data, interpret it to decide which of the data values to transcribe, and then figure out
where to put the data values in the engineering design system.
Some of the operations are simple transcription, such as transferring a model number from
one spot to another. However, some involve calculation—such as changing from one unit of
measurement to another. Other operations involve interpretation ranging from ignoring the
data value altogether to decisions involving judgment, such as orientation or handedness. The
work is done on a computer, but often the only real difference is that engineers do the typing
themselves instead of giving it to their secretaries.
To reiterate, in most cases today information exchange still requires the skills of experienced
people because we rely on the context in which we find information to understand the precise
meaning of the information. Earlier we defined “context” as “the rules and jargon of our
trade.” Design engineers learn these rules and jargon by a combination of education and experience.
For an example of how we rely on context, suppose that you have to transfer information
from one data sheet to another and you see this:
1034
This means nothing. So, you “back up” and look for more context.
Pressure 1034
Okay, so you know a bit more—but still nothing usable. So, you back up again.
Pressure: 1034
Pressure Units: kPa
Now you expect other values to be in SI units, but you still really do not know what is going
on. So, you back up some more.
CHAPTER 1
15

Seal Flush
Pressure: 1034
Pressure Units: kPa
You still have questions, so you continue to back up.
Tag No: P-101
Service: Chemical Injection to D-101
Seal Flush
Pressure: 1034
Pressure Units: kPa
Now you are getting a clearer picture. When you “back all the way up” and read the entire
data sheet you can finally put the initial value, 1034, into context.
Centrifugal Pump Data Sheet
Client: ABC Chemical Company
Tag No: P-101
Service: Chemical Injection to D-101
Seal Flush
Pressure: 1034
Pressure Units: kPa
Even with such a trivial example, without context we are lost. Experienced engineers may
exclaim at this point “But this is the way design is done. You have to consider the entire data
sheet to understand a particular term!” That is the point: If we want to use machines to transfer
information to other machines, we want the information to be self-describing.
CHAPTER 1
16

The Data Sheet Problem
Consider a more realistic example of selecting and specifying a centrifugal pump. After selecting
the proper make and model, the mechanical engineer has the pleasant task of figuring out
which data values to transfer from the manufacturer’s data sheet to the owner’s data sheet.
Figure 1.4 shows a small portion of both data sheets.
Different Name
CONDITIONS OF SERVICE, EACH PUMP
Normal Flow Rated Flow Disch. Press. kPag
Temperature C
Suct. Press. Max. kPag Rated kPag
Specific Gravity
Differential Pressure kPag
Vapor Pressure kPag
Differential Head m
Viscosity
NPSH Available m
Corr./Erosion Caused By
Corrosion Allowence mm
Cold Start Temp. C @Sp. Gr. & Viscosity
CONSTRUCTION
Nozzles
Suction
Discharge
Size Rating Facings Location
Convert to Imperial
Convert to Metric
Different Name
Same Definition
Same Definition
OPERATING CONDITIONS
Rated Max. Normal Min.
Capacity (gpm)
Suction (psig)
Discharge (psig)
Diff. Press. (psig)
Diff. Head (ft)
Power (hp)
@ Minimum S. G.
Rated Max. Normal Min.
Op. Time (hr/yr)
NPSH Avail. (ft)
System Design
Stand Alone
Series Operation with
Parallel Operation
Service Pressure Min/Max
Service
(psig) .
Continuous
System Control Method
Starts per Day
Speed Flow Level Temp.
Pressure Pipe Friction Resistance Only
Same Definition
Different Definition
Different Definition
Different Definition
Fig 1.4 Comparison of two data sheets.
The most notable difference is that one data sheet expects metric units, whereas the other
expects Imperial units. But beyond that the data sheets are organized differently: the data are
grouped differently and the groups are arranged differently. These two excerpts only have
eight data spots in common. However, looking closer we can see that of the eight spots only
three are obviously identical:
Discharge Pressure
Rated Suction Pressure
Differential Pressure
CHAPTER 1
17

The rest require some interpretation:
Metric Data Sheet Imperial Data Sheet Comments
Normal Flow Capacity: Normal Probably the same
Rated Flow Capacity: Rated Probably the same
Max. kPag Suction: Max. No data entry spot
Differential Head Diff. Head: Rated Possibly the same
NPSH Available NPSH Avail.: Rated Possibly the same
Most mechanical engineers with a little experience will have no trouble figuring everything out
because they have the rest of the project documents, and perhaps have experience with the
pump manufacturer. Again, that is the point. We need humans to guide even what seem on
the surface simple transcription tasks because our work practices depend to a great degree
on context. However, when machines start talking directly to other machines the problem of
implied meaning based on context becomes a serious barrier.
The reason information exchange works these days is because we exchange entire sets of data
(for instance, a complete data sheet) in which the context is preserved. The disadvantage,
however, is precisely that: we have to exchange entire sets of data and we must have humans
interpret them item by item. What we really want is to be able to let machines exchange information
directly without having to rely on context to retain the correct meaning. What we really
need is a “cut-and-paste” tool for plant information. We want to be able to just “cut it from that
database over there” and “paste it to this database over here.” However, it’s not that simple.
The first and most obvious reason we cannot use a simple cut-and-paste tool is that the data
values we want to transfer seldom map to the same (x,y) coordinates on any two data sheets.
In order to know which data values to transfer, we have to first know enough about the data
sheets and underlying databases to know which values are required, which values can be ignored,
and whether or not something is missing.
The second reason is, as we have seen in this example, we cannot rely on the name of the attributes.
Even when attributes in two databases have the same name, we cannot be sure there
are no subtle differences in their meaning. We need a human expert to confirm that the attributes
match. These actions are trivial if you have the right context. We have many thousands
of design engineers doing this all day, every day, and generally they are good at it. However,
we rely so much on context to convey meaning that we cannot trust machines to make the
right decisions on their own.
Finally, this is all carried out in the context of the same written language. What would happen
if the project were engineered in English but the client wanted all of his data sheets turned
over in Russian?
The Value of the ISO 15926 Dictionary
When we want to exchange information between two software applications, the traditional
way is to map the respective databases together. We preserve the context by manually examining
the terms in each database to determine which are equivalent. Directly mapping two
applications together is often the easiest short-term solution.
CHAPTER 1
18

Let’s say you are an engineer working for a construction company planning the installation
of some piping spools. Part of your job is to plan the hydrostatic testing of all piping systems
before commissioning the plant. So, along with a great deal of other information you need to
know the design temperatures and pressures of all lines in the project. Fortunately, the design
engineer has given you a “line list”—a list of all line numbers and their critical attributes.
Your first job, then, is to simply get the design engineer’s line list into a form you are used to
dealing with; that is, your company’s construction management software. You might decide to
bite the bullet and just rekey the information manually. However, this gets old quickly and after
a few dozen lines you will be wondering why you cannot just download the data from the engineer’s
design software into your construction software automatically. After all, the design engineer
did not (in this day and age) have a secretary type the line list onto a piece of paper with
a typewriter and fax it to you. It almost certainly exists in an electronic database somewhere.
It is in the design engineer’s best interest to make sure the construction contractor (you) has
the correct information. It is easy to imagine that your IT folks and their IT folks get together
to give you a connection over the Internet to just “suck in the data.” In addition, because the
“lexical scope” of a line list is only a few terms it is easy to imagine that the data will “go right
in.” (I mean, computers are pretty intelligent these days, aren’t they?)
Artificial intelligence is the study of how to make real computers
act like the ones in the movies. 4
In a perfect world, everyone developing an application for some part of plant design would
use the same column names and ensure that the meanings of the content of the columns were
the same. (In database jargon, the “schemas” would be the same.) Figure 1.5 shows what this
would look like.
Engineering Application
Line Table
tag_no dia len temp press ifc
tag_no dia len temp press ifc
Line Table
Construction Application
Fig 1.5 A perfect world.
4. Port 2000 Newsletter: The Information Technology Newsletter for Port Washington Educators,
December 1996.
CHAPTER 1
19

Of course, in the real world things seldom work out so nicely. Even in the rather small scope of
a line list (where there the lexical scope is only a dozen or so terms) there is usually ambiguity.
For instance, in Figure 1.6 two columns have names that do not match. One of them, tag_no
in the engineering application, is most probably equivalent to the id column in the construction
application. But what about the column cl in the construction application? For that matter,
what does temp really mean? Could it mean “Temporary”? It is possible. It is not unheard
of to have temporary lines erected for commissioning, which are then removed after a plant
has been put in production. In addition, if you are being a bit paranoid (and if you have to sign
off on the actual hydrostatic test pressure you better be at least a bit paranoid) what do you
make of press? It almost certainly means “pressure,” but what type of pressure?
• Operating pressure?
• Maximum allowable working pressure?
• Design pressure?
Engineering Application
Line Table
tag_no dia len temp press ifc
?
?
id dia cl temp press ifc
Line Table
?
?
Construction Application
Fig 1.6 Real-life situation.
If you have to specify the hydrostatic test pressure, you have to know for sure. The reality is
that we are inferring everything, based on context. The only solution is to start digging. Fortunately,
the lexical scope of a line list is only a couple dozen terms. To determine if temp
means “temperature” or “temporary” you will have to look at a few rows of data. If the data
values are y/n, or 0/1, it points to “temporary.” However, if the data values are numbers in
the range of, say, –50 to 1,500 it probably means “temperature.” The column name press
will take a bit longer.
You will have to look for clues in other documents and use your engineering judgment to
determine which type of pressure it is. You may have to contact the design engineer. What
looked fairly simple just a while ago is looking a bit more complex.
CHAPTER 1
20

There is always an easy solution to every human problem—
neat, plausible, and wrong. 5
If you only have to import the data once, one option is to simply copy the information column
by column. However, if you have to import information from the engineering application several
times you will want to have someone configure a custom mapping application.
In Figure 1.7, someone has examined the data coming from the engineering application and
determined which columns matched those of your construction application. In software development
jargon, they have “mapped the databases together.” The red box represents software
that uses the map to transfer information from the design application to the construction
application. (An interesting side note is that you may not have to actually transfer very much.
For instance, if you knew that both applications expect pipe sizes based on ASME B36.10M
you would only have to transfer numerical digits—such as 6 or 12.)
Custom Map
Engineering Application
Line Table
tag_no dia len temp press ifc
tag_no dia len temp press ifc
id dia cl temp press ifc
id dia cl temp press ifc
Line Table
Construction Application
Fig 1.7 A custom solution.
So far in this simple example, writing the mapping software would be relatively easy. But the
real world is usually a bit more complex. One common problem, from the point of view of a
lonely construction engineer on a remote project a long way from help, is that the data is often
mangled across many fields.
Take, for example, a “simple” line number such as what might be represented by the column
tag_no. As a construction engineer, you are likely to look at a line number as “a label representing
the name of this run of pipe, from here to there.” You expect the line number to be
one string of text, something like:
Line Number
150-HCL-250-1C200-35
However, the design engineer needs to be able to sort and filter on the pieces. Her idea of a
line number probably looks more like this:
5. H. L. Mencken, 1917 (Variously attributed to Albert Einstein, Winston Churchill and others.)
CHAPTER 1
21

Custom Map
Line Number
Area Fluid Code Nom Dia Service Class Insulation Thk
150 HCL 250 1C200 35
In fact, it may not even be that nice. It could be something like this:
Area WBS
Service
Class
Nom Dia Fluid
Code
Testing Insulation Thk
150 7395-132 1C200 250 HCL 3 35
Many engineering procurement and construction (EPC) contractors have proprietary work
processes for plant design supported with custom software. It is quite possible that the database
the design engineer used to create your line list has the columns in a different order, and
with other columns mixed in. The line list sent to you could have been created with reportwriting
software that had been configured to select just the right columns and put them in
just the correct order just for your project. This added complication may not reveal itself until
you get “under the hood” and look at the database dump.
If you are the one transferring information from one application to another, it is up to you to
figure out all the pieces and to put Humpty Dumpty back together for your construction application.
It is a good thing that the lexical scope of a line list is only a few dozen terms!
A Confederation of Applications
If linking the first two applications together works out well, you may be tempted to link in another
one. Figure 1.8 shows how the engineering application might be mapped to a procurement
application with a second custom database map.
Engineering Application
Line Table
tag_no dia len temp press ifc
tag_no dia len temp press ifc
id dia cl temp press ifc
id dia cl temp press ifc
Line Table
Construction Application
Custom Map
tag_no dia len temp press ifc
tag dia cl ifc
tag dia len code price ifc
Line Table
Procurement Application
Fig 1.8 A confederation of applications.
This is the beginning of what might be called a “confederation of applications” whereby many
applications get information from each other, with custom-built database maps between each
CHAPTER 1
22

pair of applications. Conceivably, you could link all of the construction applications for your
project together in this manner to form an enterprise-wide solution (Figure 1.9).
Fig 1.9 An enterprise-wide solution.
If you managed to do all of this before your construction project was finished, you would have
at least a short period of relative bliss. Instead of having to manually export a list from one application,
massage it a bit, perhaps do a unit conversion or two, and then import it into another
application all you have to do is push a button. The advantage, in terms of lower labor costs
and higher reliability, is obvious. In addition, if mapping databases together point to point on a
project is good why not connect all applications in your company together the same way?
Of course, many organizations do this. Although there may not be a theoretical limit to the
number of applications that can be connected in this way, there is a practical limit. Every piece
of software you link together is subject to change. For the most part, this is good. As hardware
becomes more powerful, we can make software do more things. However, the natural
cost of this is that eventually the database structure of an application will change.
If you use point-to-point maps to link databases directly together, the link will break when
either of the databases changes. If you have many applications daisy-chained together, they
may all go down like a row of dominos. The practical reality of this approach is short lifetimes,
high maintenance, and having to relearn an application’s data structure whenever something
goes wrong. How do we deal with this? As it turns out, collectively, we have tried a number of
options.
The first approach is some variation of “If it ain’t broke, don’t fix it!” Here an organization
deliberately stops upgrading software even when new versions are released. The immediate
CHAPTER 1
23

enefit is stability of information exchanges. Personnel can get on with whatever their business
is without having to continually relearn old skills. Instead of having to spend all of their
time fixing mapping problems, the IT group can do more value-added work.
Done right, this can work well for quite a while. However, the longer an organization resists
change the more work processes will become entrenched—tied ever stronger to old software
and aging engineers. Change becomes unthinkable because of the knock-on effects that will
ripple through the organization. Eventually support from the software vendors stops and the
pool of trained users shrinks. The trick here is to know when to tightly adhere to this principle
and when to let go.
“You’ve got to know when to hold ’em, know when to fold
’em…” 6
A second approach to managing a large confederation of applications linked with custom
point-to-point maps is to live with the maintenance and try to make it as organized and efficient
as possible. Under this approach, as applications in the confederation evolve and the
maps break someone will be there to fix the important ones.
We might even argue that this is a good thing because it is a natural way to cull applications
that are no longer useful. There may be some truth to that, but we must also acknowledge
that the pace of innovation and change is speeding up. Business success, in some measure,
goes to those organizations that make good decisions quickly. Good decisions require good
information, and good information choked by inefficient information transfer is bad information.
As with the first approach, we have developed good ways to handle maintenance. There is an
entire business segment devoted entirely to what we call middleware to make creating and
maintaining custom point-to-point maps easier and more reliable. Still, there will come a time
when maintenance is a large cost.
There is another solution, but it is a bit more work up front. Instead of making individual pointto-point
maps, an organization could make a dictionary of terms for all of the applications it
uses. Under this approach, we study all of the software the organization uses and decide on
the meaning of every term. Then when we link two applications we do not map them directly
together but map each to the standard dictionary, as indicated in Figure 1.10.
6. A line from The Gambler, a song by popular Country and Western singer Kenny Rogers.
CHAPTER 1
24

Map to Common Dictionary
Map from Common Dictionary
Engineering Application
Line Table
tag_no dia len temp press ifc
tag_no dia len temp press ifc
szTag dDia dLen dTemp dPress dateIFC
szTag dDia dLen dTemp dPress dateIFC
id dia cl temp press ifc
id dia cl temp press ifc
Line Table
Construction Application
Fig 1.10 A common dictionary of database definitions.
In this example, someone has created a common dictionary containing the meaning of the
attributes of the line list. Using the dictionary, the developer of the engineering application
has determined the appropriate definitions that apply to the columns in his database. Without
having to change the engineering application in any way, he builds an export function that
extracts the appropriate data values and labels them with names from the common dictionary
instead of what the engineering application called them.
Engineering App Dictionary ID Description Units
tag_no szTag Tag Number of a plant object
dia dDia Nominal Diameter per ASME/ANSI B36.10
len dLen Pressure Class per ASME/ANSI B16.10
temp dTemp Normal Operating Temperature degF
press dPress Normal Operating Pressure psig
ifc dateIFC Issued for Construction Date yyyymmdd
Similarly, the developer of the construction application uses the same dictionary and determines
the appropriate definitions that apply to the columns in her database.
Construction App Dictionary ID Description Units
id szTag Tag Number of a plant object
dia dDia Nominal Diameter per ASME/ANSI B36.10
cl dLen Pressure Class per ASME/ANSI B16.10
CHAPTER 1
25

temp dTemp Normal Operating Temperature degF
press dPress Normal Operating Pressure psig
ifc dateIFC Issued for Construction Date yyyymmdd
Again, without having to change the construction application in any way she builds an import
function that expects to receive attributes with names from the common dictionary and maps
them to the attribute names in the construction application. There are several advantages to
using a common dictionary that are important to note.
• The developer of the engineering application does not have to know anything at all about
the construction application. Indeed, he does not even have to know it exists.
• The developer of the construction application does not have to know anything at all about
the engineering application—beyond, of course, knowing that it is the source of certain
input data.
• Both of the developers are now free to modify their respective applications in any manner,
including massive changes to their data structure—as long as the output and input are
mapped to the same common dictionary.
• Both developers know the precise meaning of the input/output from each other’s application
because they know the precise meaning of the dictionary term they are mapped to.
We call this “semantic precision.”
Of course, there is a cost to developing a common dictionary. Someone has to herd the cats
together to decide on the meaning of each term and what to call them. This is not trivial.
Many people, each with different interests and agendas, have to look at the applications in
question—possibly having to make fine distinctions between very similar attributes, as well as
build in some allowance for growth.
In short, there is a great deal of initial work in making a common dictionary but in a large
organization it is recouped whenever a new application joins the confederation. For instance,
when a procurement officer needs information from the engineering application to use in a
procurement application instead of examining the content of the engineering application’s
database all a software developer has to do is consult the dictionary and determine the values
he wants to use.
Procurement App Dictionary ID Description Units
tag szTag Tag Number of a plant object
dia dDia
Nominal Diameter per ASME/ANSI
B36.10
len dLen Pressure Class per ASME/ANSI B16.10
ifc dateIFC Issued for Construction Date yyyymmdd
The fact that the engineering application is exposing other data attributes is not of interest.
The procurement application (Figure 1.11) will simply choose the four data items it needs and
use them. Creating the common dictionary made the first mapping exercise take a bit longer,
but the benefits are clear.
• The second (and third, and fourth) mapping exercise is almost free. When the developer
of the procurement application wanted to import line list information from the engineering
CHAPTER 1
26

application, he simply used the appropriate definitions from the common dictionary. The
developer of the engineering application might not have even known this was happening.
• If the common dictionary is maintained, it is robust. If a new application in the confederation
needs another type of pressure, for instance, the keepers of the dictionary can simply
add it to the standard. The new applications will use the new definition, but none of the
existing maps between existing applications will break.
Map from Common Dictionary
szTag dDia dLen dateIFC
tag dia len ifc
tag dia len code price ifc
Line Table
Procurement Application
Fig 1.11 A reuse scenario.
Again, there is a cost. As an organization grows in size and adds more members to its confederation
of applications, managing the common dictionary will require significant time. In a
large organization, this can be a full-time job.
Regardless of the size of the organization that creates the common dictionary, eventually its
sphere of interest will intersect the sphere of interest of another organization. For example, if
two organizations—each having its own common dictionary—decide to merge, which of the
two dictionaries do they keep? Or do they make a third to map between them?
Likewise, if two such organizations want to collaborate on a joint venture they will have to
harmonize their dictionaries. Today, there is no practical alternative to each organization maintaining
its own dictionary—duplicating the efforts of all of its peers. It would be nice if there
were a way for everyone to combine efforts so that all organizations use the same dictionary,
at least for nonproprietary information. As it turns out, this is exactly what ISO 15926 offers
with its specification for a reference data library (RDL). The following is a high-level view of
how it will work.
Public Extensible Dictionary
Figure 1.12 shows the same engineering application and construction application where somebody
decides that they need to include a new attribute, Widget Color, in the line list.
(Widget Color may have been in the engineering application all along, or it could have
been added to support a particular project for which Widget Color was important.) Note
that the developer of the engineering application has decided to use the attribute name
wcolor to describe the color of the widgets, whereas the developer of the construction
application wants to use the attribute name color. This is okay because they both intend to
use a database map for the information exchange and therefore do not need to use the same
attribute name.
CHAPTER 1
27

Map to Common Dictionary
Map from Common Dictionary
Engineering Application
Line Table
tag_no dia len temp press ifc wcolor
tag_no dia len temp press ifc wcolor
szTag dDia dLen dTemp dPress dateIFC oColor1
szTag dDia dLen dTemp dPress dateIFC oColor1
id dia cl temp press ifc color
id dia cl temp press ifc color
Line Table
Construction Application
New Definition
New Definition
Industry
Reference
Data
Fig 1.12 Public extensible dictionary.
What each developer does, independent of the other, is consult the public dictionary to see
whether or not there is an attribute (or “class,” as it is properly known) that describes the
color of widgets. In the previous example, there is such an attribute: ColorW. Each developer—again,
independent of the other—creates their map. The engineering application maps
wcolor to ColorW, and the construction application maps ColorW to color.
Note that neither developer had any constraints on what they named the attribute internally,
nor had to consult the other to configure their own half of the database map. Indeed, the two
developers could have been on different continents—each speaking a different language.
Thus, we are now back to the first benefit of ISO 15926; that it has a publicly available data
dictionary. 7 The simple fact that the data dictionary exists means that an organization does
not have to develop one of its own. The ISO 15926 dictionary can be used for any purpose
without royalty payment.
However, what if in the previous example the public dictionary did not have a term for the
color of widgets? Even if the dictionary were 100-percent up to date when it was first published,
new technology would undoubtedly require new terminology. So, another requirement
for the ISO 15926 data dictionary is that it be able to handle change.
To handle change, the developers of ISO 15926 envision a library that will allow anyone (perhaps
with the requirement of a bit of training first) to add new terms. A pilot project, called
the RDS/WIP (Reference Data Service/Work in Progress), is in operation—sufficient to handle
research needs. One of the current development efforts of ISO 15926 is to create an industrialscale
reference data library.
With a fully functioning, publically available RDS we will enable organic growth. Each organi-
7. Truth in advertising: ISO 15926 does not intend to have a complete data dictionary for all of “life, the
universe, and everything.” It contains an “initial” dictionary and specifies how to extend it.
CHAPTER 1
28

zation will use it to further their own private interests, but the result will be an expanded RDS
for everyone to use.
An Example Project
Everyone can see the value of having all participants in a project able to exchange information
with one another directly from database to database. On a typical fast-tracked project,
however, there is no time for participants to map their software applications to each other’s
databases once the project starts. On the other hand, there is no incentive to do so before
contracts are awarded either.
About the only situation in which the partners in a data exchange are known well enough
ahead of time, and in which the volume of information justifies a custom data mapping project,
is between an EPC contractor designing a capital asset and the owner. Some owners realize
that the handover of asset information is a bottleneck to efficient startup and are increasingly
specifying information standards and transfer protocols in advance as a condition of
contract award. But one only needs to look at recent examples of this type of thing to verify
that such an exercise is expensive and time consuming.
However, if all participants in plant design, construction, and operation map their databases
and configure their software to comply with an industry standard the time constraint is removed.
They no longer have to design and implement database mapping within the window
of opportunity of one project.
• Vendors are able to bid on more projects.
• EPC contractors are able to entertain more bidders.
• Owners can mandate more stringent standards for information turnover without limiting
the field of participants.
Many Project Participants
All project participants benefit from mapping their software applications to be able to talk to
one another. However, the sheer number of pairs of participants makes doing so prohibitive.
The owner has it the worst because one way or another it will have to pay for all mapping
exercises on its project. Even if all information an owner receives is funneled through one EPC,
all participants will embed the costs of database mapping in their prices.
Figure 1.13 is a diagram showing what might be a moderately large project. There are two engineers,
three construction contractors, and one owner. The owner has two preferred suppliers
it wants everyone to deal with. There are five suppliers between the two engineers, and five
suppliers between the three construction contractors.
CHAPTER 1
29

V
02
45
V
03
44
V
04
V
05
43
V
01
27
28
26
12
11
25
24
10
8
9
EPC 2
13
EPC 1
19
20
22 14 21 33
2
15
23
17
1
V
10
18
16
3
V
11
4
Owner
38
37
42
32
41
6
7
5
Const
1
Const
2
Const
3
29
34
35
36
39
40
30
31
V
20
V
21
V
22
V
30
V
31
Fig 1.13 One owner, two engineers, and three constructors.
Overall, there are 18 players with 45 different connections between them. Remember that
each colored line in Figure 1.13 represents a separate mapping project involving hundreds or,
in the case of the EPC contractor-to-owner transfer, thousands of data-point maps. Of course,
no one would ever do this.
Even if the owner were willing to pay for all custom database maps (either explicitly or built
into the prices), the speed with which the maps would have to be created would be prohibitive.
Once an owner signs an agreement to begin detailed engineering, there is no time to
spare. The requirement that all bidders agree to a database mapping exercise before submitting
bids delays a project significantly.
Wouldn’t it be nice if the whole world would agree on a common manner of describing plant
objects and a common set of definitions? Then we could just tell each other “Have your
machine talk to my machine.” If all participants map their databases to a common standard,
everyone only has to map their applications once—ever.
We Need a Babel Fish
To reuse a metaphor, we need a Babel fish (Figure 1.14) to translate information from one company
to another. Fortunately, ISO 15926 acts very much like a Babel fish.
• Each company creates its own ISO 15926 interface and makes it available to its business
partners.
• Each company maps its own database (or at any rate, those portions of its database it
wishes to publish to the project participants) to the ISO 15926 standard, and opens it to its
partners.
• Each company creates an application that can access the interfaces of its business partners.
CHAPTER 1
30

EPC 1
F F
Const
3
Fig 1.14 Everyone needs a Babel fish.
After that, the only question you have to ask of a supplier (or engineer, or construction contractor)
is “What is the URL of your interface?” Figure 1.15 shows how project data exchanges
might be configured using ISO 15926. The small yellow circles are ISO 15926 interfaces that
can range from e-mailing a neutral file to a specially programmed interface on the Internet,
which we will talk about in Chapter 3.
The individual data exchanges have been replaced by an “ISO 15926 cloud” to show that
within the cloud information can go anywhere. We have added two new entities, called “data
brokers,” which project participants can hire to perform ISO 15926 data exchange—in much
the same way some organizations today hire an outside organization to manage their Internet
web pages.
V
02
V
03
V
05
V
04
Data
Broker
1
V
01
EPC 1
EPC 2
V
10
ISO 15926
V
11
Owner
How ISO 15926 Makes Life Easier in the Near Term
Const
1
Const
3
Const
2
Data
Broker
2
V
22
V
30
V
31
V
20
V
21
Fig 1.15 The same project using ISO 15926 interfaces.
ISO 15926 standardizes the representation of project information across organizational
boundaries. This means that information can move faster and more reliably with fewer transcription
errors. Organizations are able to keep their proprietary systems while exchanging information
with business partners in a manner their business partners can understand. Because
CHAPTER 1
31

information has a standard representation, some exchanges can be automated. The following
examples show how ISO 15926 works in realistic project situations.
Project Design
To mitigate the time delay between receiving project documents from an EPC contractor and
getting the relevant information entered into its document control systems and operations
and its maintenance systems, an owner may wish to specify in advance the precise nature of
the data handover. Unless the EPC contractor has worked for the owner previously, there will
be a delay while the EPC configures its engineering systems to comply with data handover
requests—and the costs of doing so will be borne by the owner either explicitly or embedded
into the fees.
When ISO 15926 is mature, this will all change. As soon as the owner determines that the EPC
contractor can hand over the project data following the ISO 15926 protocols, no one will have
to give data handover any more thought. Project participants will be able to simply get on
with design. In addition to not having to spend time negotiating handover up front, any information
exchanges during the project design (Figure 1.16)—such as between EPC contractors
and vendors, between the EPC contractors themselves, and to the owner—will be easier.
Procurement
EPC 1
EPC 2
V
10
ISO 15926
V
11
Owner
Fig 1.16 Information exchanges during design.
On a large capital project, an equipment supplier bidding on the project will receive a great
deal of information with the initial inquiry—which can consist of many books of specifications
and many partially filled-in data sheets. All bidders will have to read everything carefully and
make enough enquiries to verify that all parties agree on the terminology. The successful bid-
CHAPTER 1
32

der will have to fill in the remaining parts of the data sheets and return them along with many
books full of installation and maintenance instructions. ISO 15926 makes procurement (Figure
1.17) more efficient in two ways.
• Because ISO 15926 standardizes the description of plant objects, data sheets are more reliable—which
means that there is much less need to verify terminology.
• There is a potential for automating repetitive tasks because the meaning of equipment attributes
is accurately conveyed with the attributes themselves.
V
02
V
03
V
05
V
04
Data
Broker
1
Construction
V
01
EPC 1
EPC 2
V
10
ISO 15926
V
11
Fig 1.17 Information exchanges during procurement.
Construction contractors are starting to use sophisticated construction planning systems that
rival engineering systems in size and complexity. Currently, importing information from an engineering
system is a potential bottleneck. With ISO 15926 (Figure 1.18), this is no longer an issue.
• Construction planning can start earlier, and can be kept up to date more easily.
• There is the potential to integrate construction planning with engineering.
CHAPTER 1
33

Handover
EPC 1
EPC 2
ISO 15926
Const
1
Const
3
Const
2
Data
Broker
2
Fig 1.18 Information exchanges during construction.
At the end of a large capital project, there might be many tens of thousands of documents
for the EPC contractor to turn over to the owner (Figure 1.19). The EPC contractor in turn will
have received many of these documents from a number of suppliers and subcontractors, each
in the form most convenient for the authoring organization. Usually, to be of any use to the
owner every document has to be read by a real person, entered into the owner’s document
control system, and manually linked to the plant object in the owner’s facility operations and
maintenance software. This can take many months and cost millions of dollars. Obviously,
owners want to reduce the cost and have the information ready to use for startup.
EPC 1
EPC 2
ISO 15926
Owner
Const
1
Const
3
Const
2
Fig 1.19 Information exchanges during handover.
V
22
V
30
V
31
V
20
V
21
CHAPTER 1
34

Some owners these days make turnover in a specific form a project requirement. This moves
the effort to comply with specific requirements forward in time but does not make the job
itself any easier. Using ISO 15926, the information can be rendered in a standard form—eliminating
most of the issues we have today.
• Information exchange is easier because the exchange format is built into the computer
systems of all parties.
• Handover information is cross-referenced directly against assets, eliminating most of the
manual work of relating information to specific plant objects.
• The time a project is most vulnerable is during commissioning. Because the data is in a
standard form, it is much more easily made available for startup.
Plant Operations and Maintenance
When information is turned over to the owner already indexed to the relevant equipment, it is
easier for maintenance personnel to locate. When information is easier to locate, it is easier to
keep it up to date during plant modifications (Figure 1.20).
• Hands-on maintenance time is maximized because less time has to be spent finding information.
• Worker safety is improved because it is easier to make sure critical information, such as
equipment hazards and hazardous substances, is in the proper place.
• It is easier to manage information over time as computer hardware and software changes.
Currently, documents in an old system may be very difficult to find and use. With ISO
15926, however, all information can be stored in a standard form so that loading information
into a new system is much easier.
CHAPTER 1
35

V
02
V
03
V
05
V
04
Data
Broker
1
V
01
EPC 1
EPC 2
V
10
ISO 15926
V
11
Owner
Const
1
Const
3
Const
2
Data
Broker
2
Fig 1.20 Information exchanges during operations and maintenance.
How ISO 15926 Makes Life Easier in the Long Term
The preceding examples highlight existing information exchanges and show how they are
made easier using ISO 15926. In the three examples following, we are speculating based on
what will be possible when ISO 15926 becomes widely adopted.
Using Specialized Designs
Figure 1.21 shows a project previously designed by one of the EPC contractors, as well as a
specialist the EPC contractor works with. ISO 15926 will make it much easier to reuse previous
work and to integrate the work of specialists. Currently, we try to do the smart thing and reuse
work we have previously done. But there are practical barriers that often get in our way. For
instance, a design may have been done with a different engineering design system or perhaps
with an older version of a design system than that currently used. We salvage as much as possible,
but often large parts must be redone.
V
22
V
30
V
31
V
20
V
21
CHAPTER 1
36

Previous project information
stored as ISO 15926
EPC 2
ISO 15926
Specialist
Communication to
Specialist supplier using
ISO 15926
Fig 1.21 Integration of information with an engineering subcontractor.
In addition, it will be easier to integrate information from the designers of major systems. On a
large capital project, it is typical that the design of major systems be given entirely to organizations
that specialize in those systems. For instance, after an EPC contractor determines the
performance characteristics of a power boiler the design and fabrication are typically given to
a company that specializes in power boilers.
The power boiler may have a great many instruments and other devices that have to be integrated
into the owner’s plant maintenance and operating systems. Currently, the best way to
handle this is similar to the overall data handover issue we have just discussed. Basically, either
the EPC contractor or the eventual owner will have to receive all of the documentation about
the equipment and manually enter it. As with other information exchanges, use of ISO 15926
will make these situations much easier to deal with.
• Designs from an older project will be more easily reused on a new project.
• Designs from joint venture partners will be more easily integrated.
• Design from a specialized designer will be more easily used on all projects that use that
particular design.
• Licensed process design will be sold more easily to EPC contractors.
Application Development
When software is developed (Figure 1.22), the developer must deal with the manner in which
information is to be acquired (data in), how it is to be stored, and how it is to be published
(data out). ISO 15926 will make all of these issues much easier to deal with.
CHAPTER 1
37

• ISO 15926 is a single standard to support. The questions of how input is received and how
output is to be made disappear.
• ISO 15926 already exists. A new data model for data storage does not have to be developed
from scratch.
Software
Developer
Integration of RFID information
ISO 15926
Fig 1.22 Information exchanges for software development.
RFID technology is getting less expensive over time and is showing up in new applications every
day. It is easy to imagine a future in which almost all objects have an RFID tag. It is a small
leap to imagine a manufacturer imbedding an “ISO 15926 identifier” in the tag that will automatically
link to all of the information about the component that had been publicized with ISO
15926 protocols. This could include:
• Material certificates and other information from the manufacturer
• Inspection certificates
• The purchasing information from the vendor that supplied it
• The construction planning information from the constructor that installed it
• A sound recording of the pump made during commissioning
• The specifications from the engineer that specified it
• Warehouse information for spare parts along with the GPS location of them
• Links to operations and maintenance data
This is different from reading a product serial number from a nameplate and then manually
searching on the manufacturer’s web site for product information. The ISO 15926 identifier will
link directly to the product information without the user having to know the manufacturer’s
name or be able to read a nameplate. This represents true integration of RFID information
(Figure 1.23).
CHAPTER 1
38

V
03
EPC 1
ISO 15926
Owner
Const
2
Fig 1.23 Integration of RFID information.
CHAPTER 1
39

CHAPTER 2:
HISTORY OF ISO 15926
The ability to exchange digital information between computer programs probably became
an issue as soon as the second computer program was written. Software developers create
their applications independently and make individual pragmatic decisions on how to represent
data. As a result, users of the software can typically only open a data file by using the authoring
application—not a competitor’s application. In early computing, information exchange
between computer programs could only be done the hard way: by reading the output of one
application and manually rekeying the appropriate parts into another.
Over time, as software vendors responded to user’s needs, we have come to expect to be able
to move information from one system to another without having to completely rekey it. But
we still need to know a great deal about the computer systems and work processes involved if
we want the meaning, or semantics, of our information to be preserved throughout the exchange.
Today, at the beginning of the second decade of the twenty-first century we are on the verge
of making the vision of open exchange of project information a reality. Although there have
been many business drivers pushing this, it has only become possible via the hard work of
many people and the convergence of the following four areas of study.
• How we use the Internet to find information.
• How we know and understand things.
• Open means of storing and exchanging data.
• The evolution of product information standards.
Figure 2.1 shows how these areas of study relate to ISO 15926.
CHAPTER 2
40

How we use the
internet to find
information
The Semantic
Web
How we know and
understand things
Ontologies
Ontology
Languages
ISO 15926
Open ways to store
and exchange data
Markup
Languages
How We Use the Internet to Find Information
Evolution of
product
information
standards
Plant
Information
Exchange
Fig. 2.1 ISO 15926 enablers.
The amount of information available on the Internet is truly staggering. Unfortunately, the
unstructured format and lack of validation of the majority of this information makes it difficult
to use with confidence. Worse, much of what is potentially useful is stored in unpredictable
forms and in unpredictable locations. Therefore, because the information is not presented in a
uniform manner understanding whether a given piece of information is worthwhile or not usually
requires a human being to sift through it page by page.
This is not what Tim Berners-Lee had in mind when he invented the World Wide Web in 1990.
He envisioned much more than what we use today, which he has called version 1.0. He envisioned
a web environment in which people could ask their personal digital assistants questions
such as “Is there a medical doctor near here who specializes in geriatrics and has an
open appointment before this coming Friday noon?”—and then go for coffee while the assistant
locates a doctor and makes an appointment. He called this the Semantic Web.
Currently, the World Wide Web is built to link documents primarily for human consumption.
Computers can process web pages for layout and visual format, but they have no way to process
the semantics—to know what the pages mean. Thus, if you wanted to find a doctor in the
pervious example you might be able to use the World Wide Web to get a list of doctors, their
specialties, and maps with which to judge the distance, but you would still have to call each
CHAPTER 2
41

doctor’s office individually to find out if he or she is taking new patients and if there is a suitable
open appointment. Using existing sources of information, you might get lucky and get an
appointment with the first call, but it could easily take much longer.
The Semantic Web is all about describing things in a manner that computers can understand,
so that you can ask questions like the one in this example and let a digital assistant do the
leg work. Using Semantic Web technology, data can be shared and reused across application,
enterprise, and community boundaries.
ISO 15926 has borrowed two technologies from the Semantic Web, OWL (Web Ontology
Language) and RDF (Resource Description Framework). OWL is a language for creating ontologies,
a concept we will discuss next. RDF is a way of storing information in declarations of
truth using specific vocabularies, or ontologies, in a manner that makes the meaning machine
readable.
How We Know and Understand Things
When we go beyond custom-built methods of exchanging information between two particular
computer applications—when we try to design a way for any two computer applications to
exchange information without having to know anything at all about each other—we confront
the question of how we represent knowledge. This is not just sophistry. When two people are
having a conversation, they will naturally ask questions if they do not understand something
or if they receive an unexpected response.
But when software applications exchange information there is no opportunity to ask questions.
The developers of these applications will make certain assumptions about the world,
and therefore key terminology in the applications may differ. The solution is to embed the
necessary context (that is, the understanding that humans bring) into the data being exchanged.
For this, we need to understand how we know things. The study of how we know
things in philosophy and mathematics is called ontology. We do not need an in-depth understanding
of what ontology is in order to understand ISO 15926, but a brief, personal, example
will be helpful.
I, your humble author, ride a bicycle to work most days. (Among other things, it lets me indulge
in the luxury of eating the fine Ukrainian food my wife cooks for me!) The distance to
work makes a nice workout but is beyond walking if the bicycle were to break down. Therefore,
I have developed what you might call an Ontology of Things That Will Carry a Bicycle.
Now, in Western Canada—which to most Europeans is but a few years out of the horse age—
the pickup truck is king. In Western Canada, all “real men” have pickups. As you can see from
Figure 2.2, there is ample room in a pickup truck to carry a bicycle. So, it is not difficult to
imagine that if my bicycle broke down on the way to work, I would try to think of everyone
who owned a pickup truck that might have driven it to work that day.
Fig. 2.2 Pickup truck.
CHAPTER 2
42

Suppose one such friend is Bill, who owes me a big favor. But when I talk to Bill he tells me he
can’t help me. He tells me he is going camping that weekend, and to make a fast getaway he
has already loaded his camper. How do I know this will be a problem? It is because I know that
when you load a camper onto a pickup truck there is no room for a bicycle, as you can see in
Figure 2.3. 1
Fig. 2.3 Pickup truck with a camper loaded.
But hold on! My father used to own a camper for his own pickup truck (he being a “real man”
and all), and I have been inside it many times. On most campers there is a door at the back,
and just inside the door is enough space for a bicycle. Alas, Bill tells me, he has already filled
the available space with his other camping gear—leaving no room.
So, with that conversation I start planning how to get home on public transit. Being a “real
man” myself, I own a pickup truck and will have to drive it back to work to pick up my bicycle.
But by coincidence a new engineer, who just emigrated from the Czech Republic, walks by
and overhears my dilemma. He tells me that when he moved to Canada he brought with him
his Felicia Fun. I can’t imagine what a Felicia Fun is, but judging by the expectant smile on his
face I suspect it might be relevant so I ask him about it. Being new to Canada, he does not
know how to describe it so he says it is like the F150 his friend has—but a bit smaller. Hooray!
The Czech Republic has “real men” too! I immediately accept his kind offer to drive me and
my bicycle home after work. (Oh, and I owe him a really big favor. Perhaps I will invite him in
for Ukrainian food!)
How did I know that a Felicia Fun would carry my bicycle without ever having heard of it before?
It is because of my Ontology of Things That Will Carry a Bicycle. In this ontology is the
general class “pickup truck,” and one instance of the class “pickup truck” is the F150—which is
very common in North America. When my Czech friend said that his Felicia Fun is just like an
F150 but a bit smaller he was essentially adding another instance of the class “pickup truck”
to my ontology—and because I knew that all pickup trucks can carry a bicycle I instantly drew
the inference that a Felicia Fun can also do so. Figure 2.4 shows the relationship of things in
my ontology.
1. For readers outside North America, a “camper” is like a holiday trailer without wheels. Instead of
being towed behind a vehicle, it is loaded onto the back of a pickup truck.
CHAPTER 2
43

Ontology of
Things That
Will Carry a
Bicycle
Pickup Truck
Pickup Truck with a
Camper that is not full
of stuff
F150
Felicia Fun
Fig. 2.4 Ontology of things that will carry a bicycle.
Similarly, when we use a machine-readable ontology to organize and store information we
make it possible for machines to make inferences. If two applications use the same ontology
to store information it will be much easier for them to exchange information, and to preserve
the meaning of the information during the exchange.
There has been a great deal of study on the subject of ontologies in an effort to implement
the vision of the Semantic Web. A number of tools have been developed to make it easier to
create and share ontologies. One of the more important of these is OWL, which is being incorporated
into Part 8 of ISO 15926.
Open Ways to Store and Exchange Data
For machines to be able to understand what data means, we need to see how to store data in
a way that retains its meaning without being dependent on proprietary software or short-lived
hardware. Since the invention of writing at about 3000 B.C., people have used all manner of
what we now call hard copy to record information. The Library of Alexandria, which burned
down in 48 B.C., according to one account, 2 is an example of the best technology for managing
information in hard-copy form and of a major limitation of doing so. With the advent of
computer-managed storage in the mid twentieth century, information managers have had to
grapple with two problems.
• Survival of information beyond the lifetime of proprietary hardware and software
• Moving a large amount of information between proprietary systems
A typical example of these types of questions is a help desk inquiry from the
mid 1980s.
2 Look up “Library of Alexandra” in Wikipedia.
CHAPTER 2
44

“I have data I want to keep for decades. Should I invest in a good card reader
or should I transfer my data to these far more efficient but newfangled floppy
disks?”
Unfortunately, the best answer to this type of question has always been rather labor intensive.
That is, the only reliable way to keep digital information for decades is to upgrade our storage
media every few years to whatever is the latest and greatest at the time. For personal use,
in the 1980s it would have been 5-1/2-inch floppy disks. By the 1990s, we would have had to
copy our archive to 3-1/2-inch floppies. Then, sometime around 2000 transfer them again to
CDs—and a bit later to DVDs, and more recently to BDs.
Now, at the beginning of the second decade in the twenty-first century, flash drives are looking
like they will be readable for quite awhile. But for how long will our personal computers
have USB ports? At some point we will still have to load up our thumb drives and copy the
data to some new media; perhaps a 3D holographic memory block.
Unfortunately, even if we go through the exercise of transferring our archive every few years
how are we going to open the files 25 years from now? In the lifetime of the author (who is so
old he can remember when an entire family had to make do with a single telephone), the word
processor of choice has gone from WordStar, to Word Perfect, to Microsoft Word—which
comes in two “flavors,”” one for PCs running Windows and one for Macintosh computers.
The nice thing about Windows is that it does not just crash; it displays a little
dialog box and lets you press OK first.
Q. How do you make a Macintosh go faster?
A. Drop it from a higher window!
Working with Word 2002, now, as this is being written, we can open the following word processor
file formats.
• Word 2.0
• Word 5.1 for Mac
• Word 6.0 (95)
• Word Perfect 5.0
• Works 2000
Where is my beloved WordStar? In addition to copies of all my data files, do I have to keep
copies of all my old authoring software? And even if I do, what will I run it on? Do I also have
to keep a working model of each vintage of personal computer? What if they break down?
So now, if I actually want to be able to retrieve my personal archives for decades (perhaps I
am thinking that after I become a famous author a publisher will give me a million dollars to
write my memoirs) I will have to open each of my archived files every couple of years and
somehow transfer the content to whatever the new authoring software is. This will remove
the problem of having to keep old hardware and software around, but will introduce two new
problems.
First, this solution will create an upper limit on how much information I can keep around. Be-
CHAPTER 2
45

cause it will take a certain amount of time to upgrade my archive each cycle, I will have less
and less time each round to create new information. Eventually, I will just finish one upgrade
when I will have to start over with new technology.
Second, who’s to say there will always be a clear and easy upgrade path from one authoring
software to the next? For example, what if I have a large number of files authored with obscure
CAD software? What if none of the current set of dominant CAD developers wrote the
appropriate conversions into their offerings? Well, Figure 2.5 shows another option. 3
Fig. 2.5 Long-term information storage using the Internet.
If the problem of moving information between proprietary systems is daunting on a personal
level, try to imagine what it is like for organizations that create large bodies of documentation.
For instance, every model of commercial aircraft you see today requires millions of pages of
documentation that have to be revised and published on a regular basis. The combined documentation
libraries of the aircraft industry are immense, yet every few years the dominant
hardware and software changes.
In the government and law we have a similar situation in that large bodies of text must be
readable for decades. Because of this, the text must not be stored in a proprietary format that
may go out of fashion in a few years. This brings us to the topic of markup languages and
neutral files.
Markup Languages
The forebear of modern markup languages was developed in the late 1960s by a lawyer
named Charles Goldfarb. He had just joined IBM to get some high tech experience and was
assigned to a project to figure out how to merge case law research results together into one
document, compose it, and print it. At the time, there was no single system that would perform
all three of these functions. Thus, when text was to be printed it had to be transferred
from one proprietary system to another—all without loosing its fidelity, or meaning.
With a team of two others, he developed what he called Generalized Markup Language (GML).
GML was a set of macros that described the logical structure of the document, for instance,
to declare some text to be a heading and other text to be a body paragraph. The use of GML
3. This is taken from the online forum Slashdot.org
CHAPTER 2
46

markup tags freed document creators from having to deal with the appearance of the documents
so that they could concentrate on content.
Since the development of GML, markup languages have become widely used in enabling computers
to handle large bodies of text properly without human intervention. When encoded, or
marked up with tags, the content of a body of text is separated from the format (appearance)
of the text. This is an important concept in ISO 15926, wherein the goal is to embed enough
context into the content that we do not need to see the format of the information to know
what it means. So, for instance, we would not need to see an entire data sheet to know what a
single data value means.
Figure 2.6 shows the descendents of GML. GML is no longer used, but the other languages are.
SGML (Standard Generalized Markup Language) is used for managing very large bodies of textual
information. HTML (Hypertext Markup Language) is the language of the World Wide Web,
which all web browsers can read. XML (Extensible Markup Language) has become a workhorse
transport language for embedding meaning into all manner of information exchange.
GML
SGML
HTML XML
Fig. 2.6 Development of XML.
If you wish to continue in your studies of ISO 15926 beyond this introduction, an understanding
of XML will be helpful. You will probably not write very much XML code yourself, but you
will run into quite a bit of it. It will be helpful to be able to recognize what you are looking at.
There are a number of good learning resources on the Internet.
Resource Description Framework (RDF) and Web Ontology Language (OWL) are two technologies
developed for the Semantic Web that were adopted by the developers of ISO 15926.
Figure 2.7 shows their relationship to XML. Information in ISO 15926 is structured in an ontology,
starting with basic concepts all the way down to individual objects in a particular project.
OWL and RDF are well suited to this type of structure. OWL and RDF are the basis of ISO
15926 Parts 8 and 9, which we discuss in Chapter 3.
CHAPTER 2
47

XML
RDF
ISO 10303 Part 21 and EXPRESS
Validated by
Compares to Compares to
Validated by
XML Schema
OWL
Fig. 2.7 XML, RDF, and OWL
As you learn more about ISO 15926, you may hear about “EXPRESS” and “Part 21 files” as a
method of exchanging information. ISO 10303, a standard for information exchange, is the
direct forebear of ISO 15926—as we will discuss in the next section of this chapter. To manage
the data models for the various parts of ISO 10303, the developers needed a standard modeling
language to specify how the data models were to be created and used. They called their
language EXPRESS and created ISO 10303-21, which standardizes the way to use EXPRESS
for storing and exchanging product information.
In recent years, EXPRESS has been replaced with OWL by some developers of ISO 15926—but
is still regarded as an efficient modeling format. Part 21 files are used for data exchange in
airplane, automobile, and building manufacturing and construction.
Evolution of Product Information Standards
When we study the evolution of the exchange of product information, we can start pretty well
at any arbitrary point in history. We humans are nothing if not ingenious, always looking for
ways of improving work processes.
Laziness had been given a bad rap. Laziness is the reason we live indoors and
eat three meals a day instead of living under a tree and chasing wild animals for
our supper. Laziness gives us the incentive to invent things so we don’t have to
work as hard. What we should avoid is slothfulness. 4
No matter how far back one looks to find an example of a product standard, there is always an
earlier example. For instance, the National Institute of Science and Technology—in its publication
STEP, The Grand Experience—starts before the Industrial Revolution with a description of
what we would today call a machinist, carefully measuring the prototype of a part while making
a duplicate. Then, at the beginning of the nineteenth century the idea of an engineering
drawing was developed—which enabled workers to follow an objective standard, which in turn
lead to the idea of interchangeable parts.
The Wikipedia entry for computer numerical control (CNC) describes the first attempts to
4. The author’s English instructor at technical school in 1972.
CHAPTER 2
48

minimize the variability of parts by reducing a drawing of a part to a series of (x,y,z) tool path
movements and storing it on punched tape. The vision of ISO 15926 is that full life-cycle product
information—which includes information about every object in a processing plant, manufacturing
assembly line, airplane, ship, and highway interchange—can be stored in a neutral
form that any computer system can read and write to. We are close enough to achieving this
vision that we can see it, but the progress toward this goal has always been at the margins—
with one development leading to the next.
For our history here, of the evolution of product information standards, we will start with the
methods developed to exchange electronic drawings produced with computer-aided drafting
(CAD) software. Shortly after the advent of CAD, a number of such standards sprang up
around the world—and although we could use almost any of them as an example we will use
the Initial Graphics Exchange Specification (IGES).
From there, we will move to the Standard for the Exchange of Product Information (STEP)—
which preserved the meaning of the drawing along with the graphical image. Finally, we will
come to ISO 15926—which uses a single generic data model instead of the many specific-purpose
data models used in the STEP world (with the addition of the dimension of time). Along
the way, we will introduce a number of organizations that have played key roles.
The Initial Graphics Exchange Specification
The first systems we would call CAD were written in the early 1960s in universities, with commercial
systems appearing a few years later. The early commercial CAD systems were developed
by large organizations, such as automotive and aerospace companies to assist their engineers
in complex calculations, and by computer manufacturers as tools to increase hardware
sales. By the 1970s, there were a number of competitors—all with proprietary file formats, with
the resulting inability to share data across system boundaries.
To take just the defense industry, at the time there were more than 3,500 third-party vendors
in the U.S. Department of Defense (DoD) supply chain. Members of manufacturing supply
chains each have unique requirements depending on their role, and the software they use
differs accordingly. At that time, even within a single organization different manufacturing
processes used different software that was not designed to communicate with the others. This
meant that when drawings were sent along the supply chain information from them had to be
reentered at every step.
The frustration over closed systems came to a head during a meeting of the Society of Manufacturing
Engineers in the fall of 1979. A large user of CAD software challenged the CAD vendors
in attendance to develop a neutral exchange mechanism. From there, the historical accounts
start to resemble the old folk tale of “stone soup.” At first, two vendors agreed to open
certain portions of their database format—then two others. By the end of the conference, all
of the players had agreed to contribute something—and what would eventually become the
IGES was born. (And it probably did not hurt that the U.S. Navy was about to award some
large contracts and no one wanted to appear to be unresponsive.)
Figure 2.8 shows the timeline of IGES. With the support of the National Bureau of Standards—
now known as the National Institute of Science and Technology (NIST)—the DoD, and the user
community, the first version of IGES was completed and published in 1980. Within a few years,
IGES became the de facto standard of information exchange within some segments of the
manufacturing community.
CHAPTER 2
49

1980
1990
2000
2010
U.S.
DoD
CALS
IGES 5.3
ISO
TC184 SC4
IGES
Fig. 2.8 History of IGES.
In 1985, the DoD launched what is now the Continuous Acquisition and Life-cycle Support
(CALS) 5 initiative to accelerate the use of digital information in the management of defense
system technical data. IGES was one of the first standards it supported. By 1988, all manufacturing
information for weapons systems for the DoD had to be turned over in electronic form
in the IGES format. This meant that any vendor of engineering or manufacturing software that
wanted to market its products anywhere along the military supply chain had to make sure its
products could read and write to an IGES neutral file.
With the use of IGES, it no longer mattered whether or not all the members of the DoD’s supply
chain used the same software; as long as their software supported IGES, they could ex-
5. The scope of CALS has changed over time and the meaning of the acronym has changed with it.
In the beginning, it was Computer-Aided Logistic Support, then Computer Aided Acquisition and
Logistic Support, and finally Continuous Acquisition and Life-Cycle Support to indicate that its scope
was the entire life cycle of a product.
CHAPTER 2
50

change drawings with each other and with the DoD. This eliminated rekeying information from
paper drawings, with the resulting reduction of human error. As well, if the drawings were
stored as IGES neutral files rather than in their native format they could be retrieved years
later with different software.
This is not to say that all users of IGES were enthusiastic supporters. Although there is genuine
value in exchanging the graphical elements of a drawing in a way that does not depend on
proprietary formats, in a manufacturing environment there is often more to a “drawing” than
just the graphical elements. Interest and support from the manufacturing community shifted
to what became known as STEP. The last official version of IGES is 5.3, published in 1996. An
update had been planned, version 6.0, but work stopped within a couple of years. Nevertheless,
IGES remained an American National Standard until late 2006—and many modern CAD
systems still support it.
Whereas the driver for IGES was the ability to exchange the graphical information about a
product (i.e., the drawing), the driver for STEP was the ability to exchange the complete product
model, unambiguously, independently of any computer system. A product model is the
complete definition of a product, with all of its properties. For instance, if you were an engineer
designing a machine part you would start with what the part was supposed to do; would
make decisions on material, the production process (including whether or not to cast the part
or machine it from stock), its surface finish and heat treating; and along the way would make
a drawing showing the dimensional properties. If it were important to the part, you might also
include packaging and shipping instructions. In short, the product model is all of the information
about the product for its entire life cycle.
By some reports, IGES did a reasonably good job of transferring images from drawings—but
all other information was lost. For example, a circular object on a drawing was faithfully communicated
by IGES as a circle—but thereafter, all it would ever be was just a circle. In the original
CAD system, the object that appeared as a circle may in fact have been a through-hole, a
blind hole, a spot face, or a simple circular mark on the face of a part.
In the original system, the circular object may have in fact been able to drive production systems—such
as a machine that would drill the hole (or whatever it was) in the physical part. But
once the drawing of that part had been converted to the IGES format all of the knowledge of
what the circular feature really represented was lost. [Of course, the drawing would still have
the original notes describing the circular feature (text was transferred faithfully as well) but
a human would have to read the notes and reenter the information into the new system after
the drawing was transferred.] What the industry needed was a neutral format that captured a
richer information payload, reliably and without loss of design intent.
The Origin of STEP
The story of STEP starts around 1984, with the first meeting of a committee of the International
Organization for Standardization (ISO) and what is now NIST. ISO was founded in 1947
and is based in Geneva, Switzerland. It is composed of some 160 member bodies who are
agents of their respective countries, where the ISO standards often become law. Every nation
on Earth is eligible for membership, and most have joined.
The range of ISO standards covers almost every human endeavor. For instance, ISO-1 (Standard
Reference Temperature for Geometrical Product Specification and Verification) defines
the temperature (which happens to be 20º C) at which materials must be when taking mea-
CHAPTER 2
51

surements that will be used for comparison in different geographical locations.
Individual standards are written and managed by representatives of the industry affected by
the standard, not by ISO staff. The role of ISO is more to make sure that individual standards
are developed with as wide and fair a representation as possible. The development of ISO
standards is organized by a hierarchy of committees and workgroups. The responsibility for
standards related to the exchange of product information falls to a group with the cryptic
moniker TC184/SC4, which stands for Technical Committee 184, Subcommittee 4. A partial
hierarchy is shown in Figure 2.9. Work Group 3, Team 25, is responsible for ISO 15926. The
various parts of ISO 10303, the official name of STEP, fall under a range of SC4 workgroups
and teams.
ISO 10303
International
Organization for
Standardization
(ISO)
Technical
Committee
184
Subcommittee 4
Work Group 3
Team 25
ISO 15926
Automation Systems & Integration
Industrial Data
Product Models
Oil, Gas, Process, Power
Fig. 2.9 The relationship of ISO 10303 and ISO 15926 within ISO.
The National Institute of Standards and Technology (NIST) started more than a hundred years
ago, in 1901. Its name describes what NIST is all about: to promote U.S. industrial competitiveness
by advancing measurement science, standards, and technology. IGES, STEP, and ISO
15926 are all within its mandate—and NIST has had an influential role over the years in organizing
their development.
By the time of NIST’s first meeting with TC184/SC4 in 1984, there was interest in the United
States for developing a new standard for product data that was similar in operation to IGES
but that would not lose any product information. This new standard was to be called the
Product Data Exchange Specification (PDES). It is important to note that this was not to be
an enhancement of IGES but a complete redevelopment of the approach to information exchange.
The marked departure from IGES was so important that the organization responsible
for IGES changed its name from the IGES Organization to the IGES/PDES Organization (IPO),
as shown in Figure 2.10.
CHAPTER 2
52

1980
1990
2000
2010
NIST
IGES
IGES
IGES/PDES
(IPO)
ISO
TC184 SC4
PDES
STEP
ISO 10303
LEGEND
Sponsoring organization
Consortium
Standard
Fig. 2.10 The transition from IGES to STEP.
Internationally, events were lining up in support of a new standard as well. Other CAD exchange
standards besides IGES had been created by this time, most notably in the French and
German manufacturing industry (with more or less the same limitations as IGES). In 1988, the
IGES/PDES Organization submitted PDES to the international community—which eventually
adopted it as the basis for STEP and published it as ISO 10303. 6
At the very beginning, the participants realized that the complexity of product data demanded
robust data modeling. This was a significant development. The data model for a computer
system tells us what the data means. It is like the set of blueprints for a building. Many experienced
carpenters can design a simple building in their heads and build it without any drawings,
but a large and complex building requires a comprehensive set. The blueprints are first
used for recording and communicating the design between all interested parties. Later, the
builder uses them to organize work schedules and to purchase materials.
During construction, the carpenters can use the blueprints to work independently of each
6. We will use “STEP” and “ISO 10303” interchangeably.
CHAPTER 2
53

other—knowing their work will coordinate in the end to the finished building that was envisaged
by the architect. And if the design is particularly good the blueprints can be used elsewhere
so that others do not have to redesign the same thing from scratch.
In this metaphor, where the blueprints are like the data model the building is like the finished
computer system—and what the users will do with the eventual building is like a process model.
The process model drives the data model. The data model helps us visualize data structures
before we build the system. Data model diagrams drawn on a few pages can represent a very
large system that would be difficult to visualize by looking at many pages of computer code.
The initial intent with STEP was to develop a single data model for a product that would
become the master record containing everything that everyone who used the product would
ever want to know. But by the time the standard was issued the real world proved to be too
complex for one standard. STEP was therefore divided into several parts.
Figure 2.11 shows the STEP standards that are of interest to the development of ISO 15926.
Each of them is shown at about the time it was first issued as an international standard, but
they all went through many years of development. For an example of the time involved, we
have shown in greater detail the development timeline of AP-221—arguably the most important
of the STEP standards from the point of view of ISO 15926.
Today, STEP is in wide use in the aerospace, automotive, electrical, and electronic industries.
Each industry, and segment within each industry, has its own exchange standard—called an
application protocol (AP). Each industry that adopts STEP is encouraged to create its own AP.
Today, there are many hundreds of parts to ISO 10303. Some were developed by the process
industry, although none of these are in use today. The most interesting to the history of ISO
15926 are outlined in the following.
• Part 11. Description methods: The EXPRESS language reference manual EXPRESS is well
suited to data modeling for product data.
• Part 21. Implementation methods: Clear text encoding of the exchange structure
This part describes how to encode information using EXPRESS. If your interest in ISO 15926
goes “under the hood,” you will hear about “EXPRESS Part 21” files—which represent one
method of transferring information between two users.
• Part 42. Geometric and topological representation
This part addresses how to represent the physical shape of a product.
• AP-203. Configuration controlled 3D designs of mechanical parts and assemblies
• AP-214. Core data for automotive mechanical design processes
AP-203 and AP-214 are widely used in the manufacturing industry. AP-214 is a superset of
AP-203.
• AP-221. Functional data and their schematic representation for process plant
This AP is primarily for schematic drawings such as process and instrumentation diagrams
(P&IDs). Discussion during the development of this part led to the initiation of ISO 15926.
• AP 227. Plant spatial configuration
This AP includes classes for the physical representation of piping, HVAC, cable tray, and
mechanical systems.
• AP 239. Product lifecycle support
CHAPTER 2
54

1980
1990
2000
2010
This AP is a mechanism for maintaining the information needed to support complex products
and systems over their complete life cycle from conceptual design to decommissioning.
Part 11
Part 21
Part 42
AP-203
AP-214
AP-227
AP-239
ISO
TC184 SC4
PDES
STEP
ISO 10303
AP-221
STEPlib
Annex M
LEGEND
Sponsoring organization
International standard
Part of a standard
1980
1990
2000
2010
Fig. 2.11 History of STEP.
In future diagrams we will show
AP-221 appearing, as if by magic,
around 1997. This hides a great deal
of detail:
• AP-221 started development in
the early 1990s
• Published as Committee Draft
in 1997
• Formally published as an International
Standard in 2007
• In between a number of consortia
worked on it, as we shall see
in the next few pages
• From the beginning it separated
reference data from the data
model, something not done with
the other STEP APs to that time
• For the reference library it used
an existing library known as
STEPlib, adding to it and publishing
it as part of the standard,
Annex M.
When you read this diagram, and
others like it throughout this chapter,
remember that although they appear
at a particular time, all of the
standards were developed over a
similarly long timeline.
Today, the use of STEP in the manufacturing industry is routine—but it took a few notable successes
to make it so. The following are three examples.
• Boeing, Pratt & Whitney, Rolls-Royce, and GE Aircraft Engines used STEP for the 777 and
767-400 aircraft.
• General Motors uses STEP to coordinate designs among its various design centers when
they do not use a common CAD system.
• The European Space Agency evaluated the use of AP-203 and AP-214 to transfer information
between prime contractors and suppliers to the Agency’s programs. At the conclusion
of the study, the two APs were proven to be mature enough to be used as a standard for
CAD exchange in the European space industry.
CHAPTER 2
55

1980
1990
2000
2010
The Process Industries STEP Consortia
With the perceived success of STEP in the manufacturing industry, the process industry
started to pay attention in the early 1990s. This development is entwined with a number of
organizations and consortia that sprang up around the world in the couple of decades after
the formal adoption of IGES. Figure 2.12 shows the more prominent process industry consortia
on an approximate timeline.
Part 42
ISO
TC184 SC4
PDES
STEP
ISO 10303
AP-227
Japan
STEP
PlantSTEP
AP-221
European
Union
ProcessBase
ESPRIT
PIPPIN
Annex M
PIEBASE
PIEBASE
Activity Model
USPI-NL
LEGEND
Sponsoring organization
Consortium which no
longer exists
Consortium which still
exists
International standard
Part of a standard
PISTEP
PISTEP
Activity Model
EPISTLE
STEPlib
POSC
Caesar
Assoc’n
Fig. 2.12 History of the process industries STEP consortia.
It may appear that there is a 10-year gap between the first proposals for STEP and the formation
of the first consortium. In reality, the period was very busy with many organizations
devoted to the development of information exchange standards in general, and STEP and
ISO 15926 in particular. Some of these organizations left very little trace of themselves on the
World Wide Web, so their history is inaccessible to this researcher—and some were simply absorbed
into the larger consortia. The consortia and standards are placed as close as possible
to their actual times, but some license has been taken where dating information is ambiguous
and where the overlapping of shapes would present a legibility problem.
If the arrows between the consortia give the appearance of a complicated membership, the
reality is even more so. We could almost have put two-headed arrows between every one of
the consortia, and between each of these to each standard. In a book, we are limited to a serial
description of events and 2D drawings, but the development of STEP—and the thinking
that lead to ISO 15926—was all happening at the same time.
Many individual companies were members of more than one consortium, and some consortia
1980
1990
2000
2010
CHAPTER 2
56

were themselves made up of other consortia. The arrows between consortia and the international
standards and parts roughly show the main sponsors—but, again, the reality is more
complicated. Many of the people involved worked on behalf of more than one consortium and
over time contributed to many parts of the international standards. 7
Complicating the proper representation of responsibility is human memory—the people that
were part of this while it was happening do not all remember things in the same way. What we
will concentrate on, then, is what happened rather than who did it. We will start by introducing
the main players.
Development work was initially divided between the schematic representation of a process facility
and its physical representation. AP-221 was initiated in Europe to develop the schematic
(2D) representation, whereas AP-227 was initiated by an American consortium to develop the
physical (3D) representation.
ESPRIT
A major theme of the many treaties leading to the formal creation of the European Union (EU)
in 1993 was to develop a single market for its member states. It is not surprising, then, that the
CEC—the executive body of the EU—was, and is, interested in efforts to standardize the flow
of information between its manufacturers in order to make them more competitive.
Perceiving that the competitive position of Europe’s information technology industry was
loosing ground to those of the United States and Japan, the CEC established the European
Strategic Programme for Research in Information Technologies (ESPRIT) in 1983. The purpose
of ESPRIT was to fund research and technology development programs in cooperation with
industry. By the early 1990s, a number of European organizations had made significant contributions
to the development of STEP. The CEC sponsored its continued development with two
ESPRIT projects: ProcessBASE and PIPPIN.
ProcessBase
ProcessBase started at the end of 1992 and ran for three years. The initial objective of ProcessBase
was to develop a neutral format to be used for the exchange and management of
process data used in all phases of a process plant—from design, through to construction,
and eventually to operation. The approach used was to develop a data model for a process
plant using the information modeling language EXPRESS, along with software to process the
EXPRESS code. This approach introduced a high degree of automation to data exchange. The
data model became part of AP-221.
The culmination of ProcessBase was two pilot projects that demonstrated the exchange of
plant information over the World Wide Web: one a chemical processing facility and the other
a power station. According to the final report, this demonstration proved that bulk information
exchange was practical and that information exchange based on a standard neutral form
delivered the expected business benefits of reduced costs, higher information reliability by
reducing opportunities for human error, and shorter cycle times.
7. We are not saying that this happened, but from some reports it is not difficult to imagine two fellows
meeting at yet another conference, fumbling in their pockets for the first minute or two, trying to
remember which business card they were representing that week.
CHAPTER 2
57

PIPPIN
The Pilot Implementation of Process Plant Information Warehouse (PIPPIN) started at the beginning
of 1996 and ran for two years. The purpose of PIPPIN was not so much to develop AP-
221 but to build a data warehouse using AP-221 for the functional life-cycle data of a process
plant and to use it in a real project. In this they were successful, as we shall explore in material
following.
PlantSTEP
PlantSTEP, established about 1994, was a collaborative effort between NIST and a consortium
of EPC contractors, owners, and suppliers for the purpose of developing and supporting standards
based on ISO 10303. Starting with just a few organizations, the consortium eventually
included most high-end CAD systems, many EPC contractors, many manufacturers, and many
owner-operators. The intention was that all parties involved in a large capital project could use
their own tools and work methods but still be able to share appropriate information seamlessly.
Where the focus of ProcessBase was the schematic design of a plant (AP-221), the focus of
PlantSTEP was the physical design (AP-227). Considerable effort was made by both organizations
to ensure that AP-221 was compatible with AP-227.
Japanese STEP Organizations
The main mover of STEP and ISO 15926 activities in Japan is the Engineering Advancement
Association of Japan (ENAA). ENAA played in influential role in developing ISO 10303 AP-
227 with its participation in PIEBASE. In the early 1990s, the capital projects industry in Japan
was having the same issues with information exchange everyone else in the world was having;
namely, that the perceived lack of standards for information exchange was restricting commerce.
Rather than developing its own standard, ENAA decided to follow international standards
and was an early proponent of AP-221 and AP-227. Later, Japan funded the development
of the second edition of AP-227.
In the mid 1990s, Japanese industry and government was motivated by the U.S. and European
CALS initiatives and did not want to be left behind. The Japanese commissioned a domestic
pilot project, called the Nippon CALS Research Partnership (NCALS)—which ran for three
years, with similar goals to the U.S. CALS initiative.
ENAA became more involved with STEP with their own project, Plant CALS—representing
EPC contractors, equipment vendors, and owner-operators. This project enabled the participants
to better understand the various ISO 10303 application protocols and proposals on
operation and maintenance APs and to experiment with SGML as a transport language. During
this period, several Japanese organizations participated in the PIEBASE consortium—until
PIEBASE disbanded in 2003.
By the late 1990s, the interest of the Japanese consortia was turning from the individual application
protocols of ISO 10303 to a data warehouse and e-commerce solution. Some notable
work was done with STEPlib and the POSC/Caesar Association (PCA) reference data library
(RDL) to provide storage and a search mechanism for engineering asset information, which
was later expanded to include operations and maintenance information.
CHAPTER 2
58

The Japan Electric Measuring Instruments Manufacturers’ Association (JEMIMA) contributed
to standardization by making practical use of ISO 13584 and is responsible for maintaining its
reference dictionary, Part 501. At about the same time, the Japanese construction industry—
with an endorsement from the Japanese government—used STEP AP-201, Explicit Draughting,
as a base of 2D drawing exchange and as the archive standard for Japanese government projects.
This standard uses conformance classes to inspect and validate the content of drawings
and has become mandatory for all large Japanese government projects since its introduction.
Currently, ENAA has been a strong supporter of ISO TC 184/SC4 standardization and participates
in T25 standardization activities as a liaison organization to the Japan Nuclear Cycle
Development Institute (JNC). ENAA is also a member of SC4 RDA Maintenance Team and
Validation Team and actively supports enhancing the quality of the Part 4 RDL.
European Process Industries STEP Technical Liaison Executive
EPISTLE was formed in 1993 to be a forum for all of the international projects and organizations
working toward standards-based exchange of engineering data using STEP. Figure 2.13
shows EPISTLE as consisting of USPI-NL, the Process Industries STEP Consortium (PISTEP),
and what is now the PCA. In the early years of EPISTLE, the membership consisted of a number
of companies directly involved in plant design, equipment manufacture, and operations—
but over time the individual companies withdrew, leaving only the three consortia as members.
1990
1995
2000
UPSI-NL
UPSI-NL
PISTEP
EPISTLE
Caesar
Offshore
Project
POSC/
Caesar
Project
POSC
Caesar
Assoc’n
Petrotechnical
Open Software
Corporation
Energistics
Fig. 2.13 EPISTLE member consortia.
It is important to remember that the individual consortia did not lose their identity while a
member of EPISTLE. Therefore, many publications were made under one of the individual
CHAPTER 2
59

names. As a consortium, EPISTLE directly supported AP-221, published some general work on
the methodology of developing data models, and managed the EPISTLE Core Model—which
we will describe in the next section when we describe the development of ISO 15926.
USPI-NL
In 1997, an informal group of plant owners and EPC contractors operating for about four years
under the name SPI-NL created the formal association USPI-NL (Uitgebreid Samenwerkingsverband
ProcesIndustrie-Nederland) as the Dutch Process and Power Industry Association for
the development and implementation of industry standards for plant life-cycle data. The new
group included equipment suppliers, and was gradually joined by software vendors, consultancies,
and universities.
The mission of USPI-NL is “To develop, maintain and promote the use of international information
standards and best practices for product and plant life cycle information”—with the aim
of achieving the quality of information required for the delivery of products and installations
that are safe, reliable, and environmentally friendly and to achieve a shorter project delivery
time, lower costs, and support for innovation.
USPI-NL’s s vision is that “Companies in the process industries shall be able to share and/or
exchange electronically the information needed to design, build, operate and maintain process
and power plants using internationally accepted standards.”
Currently, USPI-NL is active in five roles: networking, setting direction, providing implementation
templates and frames, acting as a knowledge center, and developing and maintaining
international standards. USPI-NL supports ISO 15926 (with emphasis on Part 4 and its maintenance),
Part 11, ISO 10303-221, and several others—including ISO 13584. It actively encourages
Dutch industry to adopt international standards for electronic data exchange and storage.
USPI-NL has taken a lead in road-mapping and maturity assessments of industry, assisting
individual companies to assess where they are in the roadmap, how they compare to the others,
and how the industry as a whole progresses through the roadmap. USPI-NL has a wide
network of associations and companies it cooperates with on development and adoption of
standards. It maintains special cooperation with PROLIST, Fiatech, and ENAA.
Process Industries STEP Consortium
PISTEP was founded in 1992 to increase the competitiveness of the UK process industry by
improving engineering information management. Its founders saw that the current paperbased
information-handling methods used during design, construction, operation, and eventual
decommissioning was hampered by locking information in documents where it was difficult
to find. PISTEP endorsed the use of international standards to store information so that
it would be accessible across organizational and system boundaries and not be locked into
proprietary systems. PISTEP promoted STEP—and when it was introduced, ISO 15926 as well.
A major contribution in the mid 1990s was the Process Plant Engineering Activity Model,
shown in Figure 2.14. This was intended as an overview of the main activities and data flows
required for the design and operation of a process plant. The first page (shown in Figure 2.14)
is a summary, with each process (represented by a rectangle) developed in more detail within
the document. It was intended as a guide for those developing STEP APs, but it remains
CHAPTER 2
60

useful today as a starting point for anyone seeking to model such activity. In 2000, PISTEP
merged with the PCA—with PISTEP becoming the UK chapter.
POSC Caesar Association
Fig. 2.14 PISTEP activity model.
The PCA was founded in 1997 to promote the development of openly available standards for
the integration and interoperability of data, software, and related matters for e-engineering
and e-commerce. PCA works in close collaboration with other standardization organizations
in Europe, the United States, and Japan. PCA is the originator of ISO 15926 and is committed
to its maintenance and enhancement.
The Petrotechnical Open Software Corporation (POSC) is a nonprofit, vendor-neutral corporation
based in Houston, Texas, that was founded in 1990 by five major oil companies with the
aim of establishing open software standards to be used for sharing information through the
asset life cycle. By 1998, it had grown to 130 members, including large and small suppliers,
government agencies, universities and research centers, other standards organizations, and oil
companies. This consortium works to share information among its members and to promote
useful software modeling, data, and application integration standards. At the 2006 Standards
CHAPTER 2
61

Summit & Reception in Houston on 8 November 2006, POSC renamed itself Energistics.
The Caesar Offshore Project was founded in 1993 by seven organizations active in the North
Sea as a research and development project under the name of Caesar Offshore Program. The
purpose of the project was to develop a product model for life-cycle information. The focus
was on standardizing the technical data definitions for facilities and equipment associated
with onshore and offshore oil and gas production facilities.
In 1994, the Caesar Offshore Project was reorganized and defined as a project of POSC and
changed its name to the POSC/Caesar Project, and then more recently to the POSC Caesar Association
(PCA). The technical work of PCA was more and more related to the ISO STEP standard
and influenced by similar work in European standardization organizations such as PISTEP
in the UK and USPI-NL in the Netherlands through the EPISTLE consortium. PCA collaborates
with many standards organizations around the world, including Energistics and Fiatech.
Process Industry Executive for Achieving Business Advantage Using Standards for
Data Exchange
By the mid 1990s, there was such significant effort being expended on the development of
STEP that there was real risk of duplication of effort. To coordinate the work globally, the Process
Industry Executive for Achieving Business Advantage Using Standards for Data Exchange
(PIEBASE) was chartered in the United States in the fall of 1996.
The membership was essentially the members of EPISTLE, PlantSTEP, and POSC—with representatives
of the Japanese STEP community and NIST. The intent was to develop a common
vision and a coordinated roadmap for the development and use of international standards
for information exchange, including many of the STEP APs and a number of other standards.
Although PIEBASE did not author any standards directly, it did valuable work defining boundaries
for APs (so that the APs did not overlap) and reviewed overall priorities to increase the
return on investment being made by the participants.
A significant publication was the PIEBASE Activity Model, which was a reworking of the
PISTEP Activity Model. An activity model is a diagram showing the relationship of a set of
inputs, outputs, and activities that constitute a process, and it is an important input to a data
model. The PIEBASE Activity Model had the viewpoint of a process plant owner-operator that
wanted to produce a product by building a process plant. The purpose of the activity model
was to describe the activities related to the generation and use of information in the creation
and operation of the process plant and to provide a context for more detailed activity models
for individual APs. The PIEBASE Activity Model is contained in both AP-221 and AP-227. PIE-
BASE wrapped up in 2002.
STEP Issues
STEP does well in manufacturing environments, but some deficiencies were exposed when it
was used as the basis for storing life-cycle information for process plants. First, it sees information
exchange as a problem to be solved by a series of exchanges—each with its own AP.
It has been estimated that a typical process plant would require several hundred APs. Aside
from the obvious problem of simply keeping track of them all, a major issue is that “things”
that make up a modern process plant do not naturally come to us with their preferred AP
stamped on their bottoms.
CHAPTER 2
62

APs by their nature overlap with each other and it is therefore not always obvious which AP
should be used. For instance, a particular control valve is part of a plant’s process design and
thus the valve should show up on a P&ID, which implies that we should use AP-221. But the
physical valve will be a product of some manufacturer that will want to use AP-203/214 during
design and manufacturing. The valve will also show up in an engineer’s 3D model, which implies
AP-227. Now we could come up with a scheme that uses AP-221 in some situations and
AP-203/214 or AP-227 in others, but the best solution is a single standard that can be used to
represent the valve in all of its aspects.
Second, maintaining information about plant objects requires the ability to handle change
over time. This is possible with STEP, but it is cumbersome because one would have to keep
updating the data model. During the pilot projects for the various STEP APs, which we have
described previously, a detailed data model worked well—but one characteristic of pilot projects
is their relatively short duration. Over a longer term, maintaining such a detailed data
model in the face of the amount of change over the lifetime of a typical facility proved to be a
large effort.
The third reason is more technical. In the typical STEP work process, the manner of creating
an AP involved navigating a number of levels of modeling. The process started with defining
the activities and information flows the AP is intended to support. (This is the principal reason
the PISTEP and PIEBASE Activity Models, discussed previously, were created.) Then it defines
the requirements using a more or less generic data model called the Application Requirements
Model (ARM), 8 refines it further to a more detailed data model, and then maps the requirements
to a set of standard components that are interpreted in the AP. Are you confused
yet? It worked good in theory, but in practice it was difficult to understand and proved to be
quite cumbersome.
Development of ISO 15926
Perhaps the best way to describe the development of ISO 15926 is to describe the development
of AP-221 in a bit more detail. Figure 2.15 shows some of what we have described before,
with a new standard—the EPISTLE Core Model (ECM)—leading to ISO 15926 Part 2. In reality,
AP-221 is closely entwined with the ECM.
8. Remember this term. We will refer to it shortly.
CHAPTER 2
63

1980
1990
2000
2010
ISO
TC184 SC4
ISO 10303
AP-221
European
Union
ProcessBase
ESPRIT
PIPPIN
Annex M
Japan
STEP
PIEBASE
PIEBASE
Activity Model
Related to
USPI-NL
STEPlib
PISTEP
PISTEP
Activity Model
EPISTLE
RDL
POSC
Caesar
Assoc’n
LEGEND
Sponsoring organization
Consortium which no
longer exists
Consortium which still
exists
International standard
Part of a standard
EPISTLE Core
Model
B
C/D
E
Snapshot Series
Part 2
Part 4
ISO
TC184 SC4
ISO 15926
Fig. 2.15 Development of AP-221 and ISO 15926.
If you follow the relationships shown in the diagram, you will see that all of the consortia
shown had a hand in developing some aspect of AP-221. We have previously described how
the EU, through its ESPRIT program, launched ProcessBase—which initiated AP-221. When
ProcessBase wound down in 1995, members of EPISTLE continued its development. PIEBASE,
the executive body coordinating STEP activity, extended the PISTEP Activity Model into the
PIEBASE Activity Model—which was used in AP-221. The Japanese STEP consortia were involved
through their participation in PIEBASE.
When PIPPEN started in 1996, its purpose was to use AP-221 in a real project. It accomplished
this through working closely with EPISTLE on the development of what came to be called the
EPISTLE Core Model, and by using a version of the ECM in one of the Snapshot projects.
The EPISTLE Core Model and the Snapshot Series
An unfortunate casualty of legibility in Figure 2.15 is the way the ECM is shown as being separate
from AP-221. In fact, the first version of AP-221 (published in 1997) was identical to the
ECM. The ECM, which covered the information requirement for the life of the entire process
plant, was a key deliverable of EPISTLE. It was called the ECM because it did not depend on
any one system or use proprietary functions. Because of EPISTLE’s close association with the
developers of AP-221, the ECM borrowed a significant part of its data model from AP-221.
1980
1990
2000
2010
CHAPTER 2
64

EPISTLE’s idea was that if you break data down into its smallest pieces you have the best
opportunity for reuse. (In technical language, it was highly normalized.) Thus, instead of the
database tables having many columns they had only a few columns but were used in combination
with each other.
We have said that EPISTLE developed a reference library, which it called STEPlib, and which
was used as the basis for Annex M of AP-221. At some point in the development of STEPlib,
PCA decided to reserve its own work for just its own members—and for awhile STEPlib and
the PCA RDL forked. Eventually, however, the two organizations combined them back into one
and the merged RDL eventually became Part 4.
A significant part of the evolution of ISO 15926 is the Snapshot series. As the ECM, STEPlib,
and the PCA RDL evolved, they were used on real world-scale projects over a period of a few
years. As each of the projects was launched, PCA took the latest thought on data models and
the latest version of its RDL and merged them into a snapshot, starting at A and running to E.
The lessons learned from each project were fed back for improvements in the next. The diagram
implies a direct connection that may not have actually existed. However, because many
of the same people worked in many capacities there would have been some crossover.
There were some key differences between the Snapshot series and the ECM. The ECM was
highly normalized and used multiple inheritance. Due to the perceived inability of the thencurrent
technology to support this, the data models of the Snapshots were less normalized
and did not support multiple inheritance.
What the creators of ISO 15926 did (in the jargon of professional data modelers) was to use
the ARM of AP-221. Thus, the data model was much more generic—with much of the intelligence
pushed into the RDL. The ISO 15926 data model incorporates 201 entity types and
reuses them many times to represent information about plant objects. Think of it this way: instead
of defining the “perfect” data sheet for an instrument, ISO 15926 uses a generic pattern
for each attribute of the instrument. The sum of the combined attributes is the representation
of the entire instrument.
When information is exchanged using the ISO 15926 protocols, the receiving system looks for
patterns. This allows you to do what might be called “just-in-time modeling.” You model what
you know now, and model later what you discover later. The model itself can evolve and recover
from earlier errors. In this way, computer systems that use data sheets that appear to humans
to be wildly different can still communicate without being told explicitly about each other.
Because of the marked differences from the approach of the other STEP APs, the general
consensus was that the best path forward was to create a new standard instead of work the
new approach back into STEP. By 2000, the EPISTLE Core Model had been formally approved
as Part 2—whereas the combined STEPlib and PCA RDL became Part 4. Part 3 (for geometry),
first published about the same time, is based on STEP Part 42. We will describe the most significant
parts of ISO 15926 in Chapter 3. Figure 2.16 brings in the remaining parts of ISO 15926
and shows a new player, Fiatech.
CHAPTER 2
65

1980
1990
2000
2010
Part 42
ISO
TC184 SC4
ISO 10303
Fiatech
AP-221
European
Union
ProcessBase
ESPRIT
PIPPIN
Annex M
Basis For
Japan
STEP
PIEBASE
PIEBASE
Activity Model
Related to
USPI-NL
STEPlib
PISTEP
PISTEP
Activity Model
EPISTLE
RDL
POSC
Caesar
Assoc’n
LEGEND
Sponsoring organization
Consortium which no
longer exists
Consortium which still
exists
International standard
Part of a standard
PCA/Fiatech project
EPISTLE Core
Model
B
C/D
E
Snapshot Series
Part 2
Part 3
Part 4
Initial Part
7
Part 7
Part 8
Part 9
Part 10
Part 11
ISO
TC184 SC4
ISO 15926
IDS/ADI
Fig. 2.16 Development of ISO 15926.
This brings us to the twenty-first century, to an organization called Fiatech. Its purpose is to
increase the productivity in the capital projects industry by introducing technology to engineering
and construction work processes. In this definition, capital projects industry includes
all manner of capital construction—from roads and sewers, commercial buildings and shopping
centers, ships, and pipelines to manufacturing and industrial plants.
Fiatech was founded in 2000 as a collaborative effort between NIST and the Construction
Industry Institute (CII), a research center in the College of Engineering at the University of
Texas at Austin. At the time, CII had more than 100 members representing owner-operators,
contractors, and suppliers from the engineering and construction industry—as well as more
than 30 universities. The mission of the CII is to publish information on best practices in the
U.S. construction industry.
Today, Fiatech’s membership roster includes many of the largest owner-operators, EPC contractors,
construction contractors, equipment manufacturers, software developers, and universities.
One of the most compelling reasons for any of these organizations to join Fiatech
is that because Fiatech is part of a university they can collaborate without breaking antitrust
legislation. Outside Fiatech they are competitors and must guard what they say to each other.
But on a Fiatech project top experts in a field can work together across organizational boundaries.
For a portion of the development costs, all members can participate in all results.
University
of Texas
CII
Fiatech
1980
1990
2000
2010
CHAPTER 2
66

For planning, Fiatech developed what it calls its Capital Projects Technology Roadmap—with
nine elements depicting a completely integrated structure to accelerate the deployment of
emerging technologies to drive productivity in the capital projects industry. Of these elements,
ISO 15926 is part of number nine, Lifecycle Data Management & Information Integration.
Until that time, ISO 15926 had been seen as applying predominantly to processing plants.
With Fiatech’s endorsement, it was seen to apply also to all capital projects.
2005 Process Industry Data Integration Workshop
In 2005, a workshop was held at the Wilmington, Delaware, offices of a large owner-operator—with
many of the key players in plant data standardization in attendance. A strategic
agreement was reached, later known as the Wilmington Agreement. The participants agreed
that all would cooperate in achieving a single common RDL for the industry, which was ISO
15926-4, and work toward formal approval by ISO. Agreement was also reached regarding the
implementation of a working reference data service (RDS) to support a project.
IDS-ADI Project
In 2009, both PCA and FIATCH (by coincidence) launched projects to promote ISO 15926.
PCA called its project Intelligent Data Sets (IDS), whereas Fiatech called its project Accelerating
the Deployment of ISO 15926 (ADI). Both came together under combined leadership with
the purpose of demonstrating the capabilities of using the full specification of ISO 15926. Under
their joint oversight, many subprojects have been sponsored to develop and demonstrate
the use of various parts of ISO 15926.
Summary
This has been a long chapter. We started with CAD file exchange, described a number of STEP
APs, finally ending up with the Part 4 RDL—which is used in industry as a common set of definitions
for plant objects—and the Part 2 data model, which will be used by a new generation
of information exchange that embeds meaning into data to make information exchange easier
and more reliable. Some of the research we have described has led to dead ends, and many of
the STEP APs are no longer used. This does not mean they were a waste of time. Sometimes
the things that do not work teach us as much as things that do work.
If we knew what we were doing, it wouldn’t be called research,
would it?
—Albert Einstein
However, our intention is not to make you into an amateur historian but to understand the
progression of ideas regarding information exchange in industry. We summarize them with
the graph in Figure 2.17. In the late 1970s, soon after the advent of CAD, we as an industry
grew tired of having to redo drawings in order to move them from one system to another. We
thought that if we could only have a way to import the drawings directly from one system
to another all of our data exchange problems would be solved. We got IGES, and other CAD
exchange standards, but quickly found that although this solves some problems there is often
more to drawings than, well, drawings.
CHAPTER 2
67

1980
1990
2000
2010
If only we could exchange
CAD drawings.
If only we all used the same
data model.
If only we all used the same
Reference Data Library
If only we could embed meaning
into our information exchanges
Fig. 2.17 Progression of information exchange ideas.
Any who have worked in an engineering environment will know that there is more than one
CAD application in common use, and that on a large project all business partners do not always
use the same one. Sometimes, all an engineer needs is some way to open in his system a
drawing authored in another system. If that is all that is truly needed, a simple translation tools
is all that should be used. Although IGES is no longer used, the market demand has been met
with several commercial tools.
But in a manufacturing environment sometimes what appears as a drawing is a collection of
machine tool instructions for making a part, with the drawing more or less simply the human
interface. In these situations, converting the “drawing” using a CAD translator tool would loose
almost all of the value.
By the mid 1980s, we thought that if only we all used the same data model all of our data
exchange problems would be solved. We got STEP, with its many and varied APs. But as with
IGES we found that although STEP solved a certain set of problems in a process plant environment
a fixed data model is too cumbersome to keep up with a degree of change measured
in decades. Our research led to the idea of separating the monolithic data model into a more
generic data model consisting of smaller reusable pieces combined with an external RDL.
By the mid 1990s, we thought that if only we all used the same definitions of terms (that is,
the same RDL) all of our data exchange problems would be solved. We got a common RDL
in the form of ISO 15926-4, and (as with STEP and IGES) we found that a common RDL does
indeed solve some problems.
Sometimes all you need to do is translate some data authored in one system into a form that
CHAPTER 2
68

can be read by another. A translator based on the common dictionary of Part 4 is what you
need. As well, there are some situations in which all you need is a common naming convention—anything
will do. You can make your own, but if one already exists in the form of Part 4
you can save yourself some significant work.
This is all well and good if you have the luxury of time in which to perform brute force data
mapping in order to be able to exchange some data. But the pace of business is increasing
and we would like to be able to exchange information without having to know a great deal
about the systems our business partners use.
For this we will need to embed meaning into data, so that when your business partners receive
your information their systems will simply be able to figure it out. Since the mid 2000s,
the research has been focused on just how to embed such meaning into a data exchange. The
principle means of doing this is Part 7 templates. The next obvious question is: “How does it
all work?” That is the subject of the next chapter.
CHAPTER 2
69

CHAPTER 3:
HOW DOES ISO 15926 WORK?
The full title of ISO 15926 implies a very ambitious goal, encompassing information about every
plant object from conception, engineering, construction, and operations.
Industrial Automation Systems and Integration: Integration of Life-cycle Data for
Process Plants, Including Oil and Gas Production Facilities
Integration is a word you will hear many times in discussions of ISO 15926, along with the
word interoperability. Most of us will have heard both words many times and will naturally
think we know what they mean. They are related, of course, and are often used (incorrectly)
as synonyms. Both terms include subcategories of related concepts, and there is disagreement
even among experts as to the terms applied to these concepts. Part of the problem is
that when you dig below the surface of the commonly used examples you will not find a sharp
point where one word stops and the other starts, but a continuum with a fair degree of overlap.
Fortunately, this is only an introduction to ISO 15926; we can understand the basic concepts
of ISO 15926 without having a precise definition of either term. We will therefore approach the
question with a few examples and then describe what ISO 15926 actually intends to do.
Integration Versus Interoperability
If you search for the definitions of integration and interoperability as applied to the field of
computer science, you will find that the definitions cover a wide range but with a clustering
of ideas around each term. There is wide agreement that integration means that two different
applications are made to work together seamlessly. Along with this idea, there is a strong
implication that the integration of the two applications is done specifically with that end in
mind, and with the specific identity of the two applications in mind. Thus, we can think of integrating
application A with application B by having their respective developers collaborate to
“make them work together” (whatever that might entail).
Interoperability is usually associated with two applications being able to “work together”
(whatever that means) by virtue of each, independently, following an outside standard. In the
end they may be able to work together just as well as two integrated applications, but because
the “working together” was achieved by each implementing an outside standard we call
it “interoperability.” (A bonus is that both applications can also work with every other similarly
enabled application.) Let’s look at a simple example.
Example 1: Headsets and Handsets
Figure 3.1 shows two manufacturers—ACME (a maker of telephone headsets) and EMCA (a
maker of telephone handsets)—that wish to make their products work together. If the two
companies were to collaborate to design a physical plug that connects the handsets to the
headsets, it would be an example of integration (that is, they use a custom-designed physical
CHAPTER 3
70

plug to integrate their products). But if they independently used the Bluetooth standard (with
the intention that their products would work with all other Bluetooth-enabled devices as well),
we would call it interoperability.
Fig. 3.1 Integration versus interoperability.
A common mistake is to assume that the Bluetooth part of this example is what defines interoperability.
Not so. We can imagine the reverse situation, in which the telephone industry
has standardized on a certain physical plug that allows any headset to work with any handset.
In this case, we would call all of the handsets and headsets with this particular plug interoperable.
Within this situation, we could further imagine two (ACME and EMCA) of the many
manufacturers getting together to connect their respective products using a new wireless
technology. If they achieved this wireless “working together” by designing their own wireless
protocol, it would be considered integration.
However, remember the title of ISO 15926: Industrial Automation Systems and Integration: Integration
of… If we were to apply this definition of integration, it would imply that if we wanted
to “integrate” two applications using the ISO 15926 protocols we would have to do some
custom work to each application specifically to make them work together. But the vision of
ISO 15926 is that two applications can work together by virtue of each, independently, implementing
the ISO 15926 standard. This sounds more like our definition of interoperability. Have
we contradicted ourselves?
We can start to develop an answer to the dilemma by subdividing the definition of integration
into application integration (achieving integration by writing custom application code) and
data integration (achieving integration by somehow transforming the data). To see how this
works, let’s look at another example.
CHAPTER 3
71

Example 2: Integration and Interoperability with Engineering Design Systems
Figure 3.2 shows two engineering design systems offered by two competing software vendors,
ACME and EMCA. Each suite of software offers intelligent, three dimensional (3D) modeling
for several engineering disciplines—including piping, equipment, raceway, and structural
steel and concrete. Each suite also offers intelligent process and instrumentation diagrams
(P&IDs), electrical and instrumentation schematics, and data sheets. Within each vendor’s
suite it is easy to imagine that the applications would be integrated, but each application in a
suite is probably not interoperable with the respective application of the other suite.
Piping
Equipment
Structural
Engineering System P&ID
Piping
Schematics
Raceway
ACME
Data
Sheets
Equipment
Schematics
Raceway
EMCA
Engineering System
Integrated Integrated
Interoperable
Data
Sheets
Structural
Fig. 3.2 Integration and interoperability in engineering design systems.
Within a suite, we would call the applications integrated if information created by one application
is available to the applications of another discipline. For instance, a typical integration is
for the 3D piping application to be able to request line numbers from the P&ID application.
This is an example of integration at the data level, and it can be achieved in a number of ways.
The first is point-to-point mapping, whereby (in this example) the piping application is taught
how to query the P&ID database and bring back something it can make sense of. Figure 3.3
shows integration between applications by point-to-point mapping. Each application pulls in
data from another application, modifies it with an adapter (what we have previously called a
data map), and then imports it into its own database. This may be practical for a small number
of applications developed by one organization and marketed as a suite, but if the vision is
that any application can talk to any other application using the ISO 15926 protocols this is not
what we are after.
P&ID
CHAPTER 3
72

Procurement A Construction
A
Engineering
A A
A A
A
A
Operations
Adapter
Fig. 3.3 Point-to-point data integration.
Figure 3.4 shows a second example of integration that solves the point-to-point mapping
issues by converting all data flows to a common, neutral, format and storing them in a data
warehouse (or an enterprise service bus or asset hub) specially designed to accommodate
the information from all of the individual applications. These applications can now exchange
information indirectly using the data warehouse for intermediate storage.
Engineering Procurement Construction
Service Bus or Asset Hub
(Data Warehouse)
Operations
A A A A
Adapter
Fig. 3.4 Integration using a data warehouse.
Each application looks at the data warehouse though the “glasses” of its adapter. By the time
information reaches the application, it is structured to look just like that application’s own
data structure. When an application publishes information, it publishes it in its own structure
to its own adapter—and the adapter changes it to the structure of the data warehouse. Each
application thinks that it is the only thing in the world.
This is a perfectly good solution provided that you want a data warehouse. There are many
very good reasons for wanting a data warehouse, but if your goal is simply to be able to exchange
information among a number of applications you don’t actually need the data warehouse!
Figure 3.5 shows what this would look like without the data warehouse.
CHAPTER 3
73

Engineering Procurement Construction
Information Exchange to the ISO 15926 Standard
Operations
ISO 15926 Adapter
Fig. 3.5 Integration without a data warehouse.
In this arrangement, all of the applications can exchange information with each other using
messages structured in a common neutral format. By communicating using the ISO 15926
protocols, new applications can be added to the federation without having to modify any of
them. Thus, this is what the word integration means in the title of ISO 15926. By using an ISO
15926 adapter, we achieve integration at the data level without having to modify the applications
in any way. 1 But because the applications each, independently, follow an external standard
they are interoperable.
The Parts of ISO 15926 Are Like the Parts of Human Speech
The way ISO 15926 achieves the interoperability we have just described is similar to the way
people communicate. Within a human language, there is a common dictionary of terms, a
common way of structuring sentences, and a common way of putting sentences together.
Figure 3.6 shows how ISO 15926 is divided into a number of parts, each of which is similar to
an aspect of natural language.
1. Truth in advertising: You have to modify each application to be able to exchange information with
the adapter, but you only have to do this once.
CHAPTER 3
74

Part 2: Data Model
Fig. 3.6 The parts of ISO 15926.
Part 2 is like the basic rules of grammar in a natural language.
When we grow up we naturally learn to speak the language of our parents. This happens so
naturally we don’t find out how complicated communication actually is until we try to learn a
different language. Easiest to learn is the new lexicon. For instance, if you are a native English
speaker and wanted to learn French you could open an English-French dictionary and find out
that the French word for couch is canapé and the French word for grass is herbe.
More difficult are the rules of grammar and the exceptions to the rules. For instance, if your
wife (also a native English speaker) wanted to tell you in French to “Get your lazy behind off
the couch and cut the grass!” she probably shouldn’t just try a word-by-word translation. If
she did, she would run into two problems.
First, what does the word behind mean? In English, in this context it is a slang word that
means the part of your body in contact with the couch when you are sitting on it. But in English
behind can also mean “toward the rear,” “slow,” and in some cases “hidden.” Simply looking
up the word behind in a dictionary may not get you the correct French word to convey the
same meaning.
Second, the order in which we form words into sentences in English is often different from the
correct order in French. In the field of linguistics, this is called word order typology—and it
can get tricky. For instance, word order in English is what linguists call SVO (or subject-verbobject),
which means that most of the time native English speakers will say something like “I
went home.”
In other languages, the most common way of saying the same thing might be “I home went”
(SOV), “Went I home” (VSO), “Went home I” (VOS), “Home I went” (OSV), or “Home went I”
(OVS). The problem with rules about word order typology is the phrase “most of the time.” If
CHAPTER 3
75

you, dear reader, are a native English speaker you have probably heard several of these combinations
in conversation. “I went home” is by far the most common word order, but many of
the others are used occasionally to convey subtly different meanings. As it turns out, French
is also SVO most of the time—but has a number of exceptions. Thus, if your wife got out her
English-French dictionary and translated “Get your lazy behind off the couch and cut the
grass!” word for word she would get:
Obtenir votre paresseux derrière off l’ canapé et tondre l’ herbe!
But if she were to enter the entire English sentence into popular translation software, she
might get:
Obtenez votre derrière paresseux sur le divan et couper l’herbe!
This last translation is interesting because a word-for-word translation back to English comes
out:
Get your behind lazy on the sofa and cut the grass.
But a friend who grew up in Quebec, Canada, speaking French from birth says that his wife
would be a little less formal.
Lève ton derrière du fauteuil et file faire le gazon.
(We won’t write the English translation; suffice it to say that it is a playful insult to the posterior
of someone lazy enough to lie around reading the newspaper when there is work to be
done!)
So now we have an example where using a dictionary to translate something into another
language does not yield something that sounds natural in the other language. The same sort
of thing is true with databases developed for different applications. When we humans speak
to each other there is usually at least a little bit of shared background so that we don’t have
to explain every term from first principles. And if we make a mistake understanding the other
person, the mistake will usually become apparent during the conversation and one or the
other will ask a question or two. But machines don’t have a shared background and have no
way of suspecting something has been misunderstood.
For instance, to reuse an example above, “I went home” is in English and thus the correct
word order typology is SVO. It would be (relatively) easy to program a computer to change
this to “Went I home” (VSO) if it were translating it to Hawaiian. But if the programmer made
a mistake and used the rules for VOS, as in Fijian or Malagasy, it would come out “Went home
I.” Here, the computer—still thinking you were trying to translate the sentence to Hawaiian—
would assume that the subject was “home” (instead of “I”) and the object was “I” (instead of
“home”) and would simply write the incorrect values to the database.
Just as there can be ambiguity in human speech, there can be ambiguity in data models. For
instance, Figure 3.7 is a snippet of a database that contains some information about a person
named Joe Bloggs. Here we see a number of skills and languages, but we can’t tell what it really
means just by looking at it. Taken literally, this database means that Joe can groom dogs
CHAPTER 3
76

in French, cook in German, type in Greek, and can do nothing at all in Spanish.
Name Skill Language
Bloggs, Joe groom dogs French
Bloggs, Joe cook German
Bloggs, Joe type Greek
Bloggs, Joe Spanish
Fig. 3.7 The skills and languages of Joe Bloggs, Part I.
“Baloney!” you say. “Common sense says that Bloggs can groom dogs, cook, type, and in addition
has some proficiency with French, German, Greek, and Spanish—with the blank simply
being a place to record the next skill he learns!” But note that we jumped to the second interpretation
because we know that entities that have attributes with the names NAME, SKILL,
and LANGUAGE are likely human—and being human ourselves we know that the skills listed
do not generally depend on language. But machines will not jump to that conclusion without
being explicitly told to do so. To a machine, the first interpretation is the most logical. If you
have trouble with this, consider Figure 3.8 (information in an identical database).
Name Skill Language
Jabberwok burble Whiffling
Fig. 3.8 The skills and languages of the Jabberwok.
No one knows precisely what the Jabberwok is so we do not jump to a conclusion of what
burble or Whiffling means. 2 If we said “The Jabberwok can burble in Whiffling,” it would
sound plausible.
If the database of Joe Bloggs’ skills and languages was intended only for one application,
the developer could easily overcome any ambiguity in the database by artful code. But if this
application ever had to exchange information with another application, the ambiguity would
have to be removed. In this case, it is quite simple. If the correct interpretation is that skills
and languages are unrelated, as our “common sense” tells us, the data should be structured as
shown in Figure 3.9.
Name Skill
Bloggs, Joe groom dogs
Bloggs, Joe cook
Bloggs, Joe type
Name Language
Bloggs, Joe French
Bloggs, Joe German
Bloggs, Joe Greek
Bloggs, Joe Spanish
Fig. 3.9 The skills and languages of Joe Bloggs, Part II.
So this is what we meant when we said earlier that when we use ISO 15926 protocols to exchange
information we embed the context of the data into the data itself. We structure the
2. Except, perhaps, those who follow the work of Terry Gilliam.
CHAPTER 3
77

data so that the “obvious” explanation is the correct one.
Conceptual Data Model
Fortunately, even if there is some inherent ambiguity in your database structure there are
ways to make it appear to outside applications that you have removed the ambiguity without
having to actually modify the database. To describe how this works, we need to take a detour
and examine two new terms: application data model and conceptual data model.
Every application has a view of the world that is derived from its business purpose. Each application
follows certain business rules, which can change over time. All of this is encapsulated
in an application data model, which can be unique to each application. If we want to exchange
information between these applications, we need to develop a data model that supports all of
the application data models. We call this a conceptual data model. Figure 3.10 shows how a
conceptual data model connects many different application data models.
Application Data Models
Engineering Procurement Construction Operations
Conceptual Data Model
External Level
Conceptual Level
Fig. 3.10 Conceptual data model.
At the external level, we have many different models (or views)—each with a limited scope
relative to the conceptual data model. Each will have needs different from any other, and each
will be optimized for a particular purpose. The scope of these external models may overlap,
and they may or may not be compatible with one another. For instance, an engineering application
built on the engineering data model and a procurement application built on the procurement
data model may perceive instrument tag numbers differently.
A procurement application may deal with a tag number as a single string of text (say, 34-PI-
325) and store it as such in one database field, including the dashes. On the other hand, an
engineering application may manage the tag number by its parts and store each in a separate
field without dashes. Humans may be able to look at the two database structures (or schemas)
and understand the relationship, but a computer program would not be able to do so on
its own.
The conceptual model is neutral to the external models and must be able to support all of
them. It should be independent of business rules or things that change. The conceptual model
is what integrates information from the different external models. For instance, the conceptual
model would have to be able to deal with all of the different ways of dealing with tag
numbers. Most likely, the conceptual data model would have a place for each individual part
of a tag number. In turn, the tag number in each application data model would be assembled
CHAPTER 3
78

y pulling in the individual parts as required and concatenating them together in the correct
order (with any necessary spaces and dashes) to produce the format the application required.
It is important to note here that the conceptual data model simply says how the data should
be structured; it does not imply any particular method of storage or exchange. It can be
implemented as an actual data warehouse or as information exchange files, as shown in Figure
3.11, or in any other way technology allows.
Engineering Procurement Construction Operations
A A A A
Service Bus or Asset Hub
(Data Warehouse)
Engineering Procurement Construction
Information Exchange to the ISO 15926 Standard
Operations
Application Data
Models
Conceptual
Data Model
Application Data
Models
Conceptual
Data Model
Fig. 3.11 Conceptual data model.
Thus (going back to Joe Bloggs), the database structure shown in Figure 3.7 could work as
an application data model provided the software developer knew how to handle the apparent
inconsistencies. But the special knowledge of how to handle the information would be lost if
another application received the data in that form. The solution is to transform the information
to a conceptual data model that has a more easily understood data structure.
There are two ways to do this. One is to rewrite the application so that it uses the desired data
structure. This is fine if you actually want to rewrite the application for other reasons. But if
all you want to do is exchange information with another application an easier way is to use an
adapter to transform the output.
Part 2 of ISO 15926 describes just such a conceptual data model that can be used for the representation
of information about objects used in capital projects. This representation is specified
by a generic conceptual data model designed to be used in conjunction with reference
data, which we will discuss next. The model can support all disciplines and life-cycle stages,
and can support information about functional requirements, physical solutions, types of objects,
and individual objects and activities.
CHAPTER 3
79

To review, Part 2 defines the rules and constraints (more or less the grammar used throughout)
on how we use ISO 15926. It is an ontology with basic axioms such as thing, class, and
individual at the top level. At a lower lever, it includes subtypes of these axiomatic concepts—
such as physical object and connections.
Part 2 is very specialized and requires a fair amount of work to understand. Fortunately, most
organizations will only have to deal with templates, described in Part 7, which are sort of like
preconfigured definitions that point to objects in Part 2. If you ever run across a copy of Part
2, we recommend that you read Section 4 because it gives examples of how the entity types
can be used to express certain information.
Part 4: Initial Reference Data
Part 4 is like the definitions of terms in a natural language; similar to a dictionary
or thesaurus.
Earlier we said that when we use ISO 15926 to exchange information part of the meaning of
the data comes from its structure and part comes from reference data. Reference data is essentially
definitions of terms that represent information common to industry. This means that
if the meaning of your data is inherent in its structure, and if the definitions of objects come
from a common dictionary, computer systems will be able to infer meaning without requiring
human interpretation.
Building a Wooden Swing: The Importance of Reference Data in Simplifying Communication
Effective communication requires that all parties share a common set of definitions. In computer
science, this is called a reference data library (RDL; that is, a library of reference data). 3
Whether we know it or not, we use an RDL every time we talk to others. For instance, if you
and a co-worker did not share the same RDL conversation around the coffee machine on Monday
morning would be very complicated:
You: “So, what did you do on the weekend?”
Co-worker: “You know how they use a round circular metal thing with sharp
points to slice trees up into long pieces? Well, I took some of those sliced-up
trees and some braided nylon that comes in long coils and built a thing for the
small little offspring of my wife and I so I could push them in a manner that they
would go back and forth in a circular arc that starts near the ground but gets up
to three meters off the ground before they start coming back down.”
Wouldn’t it be much easier if your co-worker could just say “I built my kids a wooden swing”?
But this would be impossible if you and your co-worker did not share the same definition of
kids, wooden, and swing, not to mention built and my. (Remember this dialog. We will refer
back to it several times later in this chapter.)
3. Another name for “Reference Data Library” is “Class Library”. We don’t use that name for the core
classes of ISO 15926 Part 4 because it contains more than just classes of objects.
CHAPTER 3
80

Where it gets complicated is differentiating between variations of a term. Basic terminology is
easy. For instance, pressure and temperature are easy to tell apart. But in an industrial environment
we seldom use the words pressure and temperature by themselves. Pressure can mean
the pressure a vessel is operating at right now; its assumed design pressure; its minimum
hydrostatic test pressure (which may be greater than its operating pressure to compensate for
a lower testing temperature); the maximum pressure it is allowed to keep working at for an assumed
lifespan of, say, 30 years; or the pressure at which a pressure-relieving device will open.
To tell the terms apart, we must add adjectives to make longer and longer strings of words.
But even if we come to agreement on the meaning of all of the adjectives, there is still opportunity
for ambiguity. For instance, what is the difference between “maximum allowable working
pressure” and “pressure-maximum-allowable-working”? For human beings, the answer is
probably “Nothing; they are the same.” But when computer systems have to communicate
without human intervention the two are not the same. (And we haven’t even talked about exchanging
information when all of the people involved do not speak the same language.)
Uniform Resource Identifier
To get around this potential for ambiguity, the ISO 15926 RDL assigns a unique identifier to
each definition so that the identifier can be used like a serial number for the definition. For
example, if you were to look up temperature in the RDS/WIP maintained by the POSC Caesar
Association (PCA), you would find something like the entry shown in Figure 3.12. All of the
attributes in the left-hand column are familiar except the first. The unique identifier is called a
uniform resource identifier (URI). A URI is sort of like a web page address that returns a definition
instead of a web page. Every term, or class, in the ISO 15926 RDL has its own URI. Instead
of having to describe the attribute, and get all of the adjectives in the correct order, an engineer
only has to refer to the URI.
RDS/WIP URI http://rdl.rdlfacade.org/data#R41192093771
Label TEMPERATURE
Description
The degree or intensity of heat or cold as measured on a
thermometric scale, and a measure of whether two systems
are relatively hot or cold with respect to one another. Two
systems brought into contact will, after sufficient time, be in
thermal equilibrium and will have the same temperature.
Entity Type http://dm.rdlfacade.org/data#SinglePropertyDimension
Fig. 3.12 RDS/WIP entry.
For example, let’s say that two applications wanted to exchange information about temperature.
Let’s also say that the first application stored the value in a column labeled “TEMP,”
whereas the second application stored the same value in a column labeled “Temperature 24.”
The following tables show what the entries in the database maps would look like. The export
map from the first application would look as follows.
Column Name RDS/WIP URI
TEMP http://rdl.rdlfacade.org/data#R41192093771
CHAPTER 3
81

The import map into the second application would look as follows.
Column Name RDS/WIP URI
Temperature 24 http://rdl.rdlfacade.org/data#R41192093771
The first application is saying, “Here comes some values for the attribute R41192093771.” The
second application runs down its map and says, “Great. R41192093771 translates to Temperature
24 over here.” As part of the data exchange, each application will resolve the URI as a
quality control measure to make sure it is a valid term.
These two examples show the importance of using reference data to reduce the volume of
information that has to be exchanged, and to eliminate the opportunity for error. In the first
example, of building a wooden swing, when we could use commonly understood definitions
(which are, in essence, reference data) we reduced a 91-word explanation to 7 words. In the
second example, being able to refer to the serial number of a particular attribute we totally
removed the possibility of mistaking the attribute for a similar one.
Reference Individuals
In addition to the core classes, the core RDL contains what we call “reference individuals.”
Normally, individual objects are contained in project databases where something like 37-P-
101A has only a local meaning. But some objects are important enough that we want to
differentiate them from all other objects in the world. For instance, an RDL devoted to geography
might have a generic class called “politically bounded object”—which would be used to
describe an entire country, the provinces within the country, and the cities within each province.
In addition to that general class, it may also contain individuals (or instances) of all of the
existing countries in the world, their provinces, and their cities. Such instances might include
England (a country), London (an important city in England), and perhaps Winston
Churchill (one of England’s prime ministers). Users could make reference to these individuals
in order to remove ambiguity. 4
A Data Exchange Can Use Many RDLs
One way to use an RDL is to copy the definitions of everything you will need to use into a
single RDL. But this would result in the unnecessary duplication of information created by others.
ISO 15926 allows the use of a federation of data libraries.
Internally, this lets an organization keep separate RDLs—one for proprietary information and
one that is published. And once you have made the leap from a single RDL, why stop at two?
It is easy to conceive of a situation in which different authorities around the world will become
respected repositories of certain categories of information. There is no reason they could not
publish their information in the form of an ISO 15926–compliant RDL.
Figure 3.13 shows a number of worldwide standards associations. Each of them publishes
4. For instance, if you mentioned “The city of London” in certain parts of eastern Canada, people would
assume you mean London, Ontario instead of London, England.
CHAPTER 3
82

many engineering standards for various parts of the capital projects industry within its jurisdiction.
For instance, China has its own national standards that are called Guobiao (GB), which
literally means national standard. GB standards must be used for all facilities built in China.
Facilities in Australia, on the other hand, must use a combination of Australian standards (AS)
and ASME standards. Currently, if an organization wanted to use all of these standards as reference
data it would have no choice but to copy them into its own RDL.
Fig. 3.13 Many standards.
But the vision of ISO 15926 is that all of the organizations will put their standards into their
own RDL and make them publicly available for other organizations to use as reference data.
What we end up with is something like Figure 3.14. Here several organizations that are collaborating
on a project have made their reference data available to the other members. An
owner, some suppliers, some EPC contractors, and some standards organizations have all
published information in an ISO 15926 RDL. Any member of the consortium can use information
from these RDLs, along with the core classes published in Part 4.
CHAPTER 3
83

Fig. 3.14 Cloud of federated RDLs.
To review, when two people use the same terminology (i.e., use the same dictionary) and use
the terminology in the same way (i.e., use the same rules of grammar) they can communicate
freely. The same is true for machines. When two computer applications use the same terminology
(i.e., use the same RDL) and structure their data in the same way (i.e., use the same data
model), they can communicate freely as well. The core of ISO 15926, then, is the data model
(Part 2) and the RDL (Part 4). These two parts define how the data is to be understood; the
rest of the parts define how it is delivered.
Part 4 defines the initial set of reference data (or core RDL) for use with ISO 15926 Part 2. The
core RDL contains the core classes and reference individuals, which are arranged in an ontology
of subtypes (or specializations) of the classes in Part 2. Examples are concepts such as
“pump,” “reducer,” and “heat exchanger.” International standards bodies can create subtypes
of the core classes to create the types of objects within the scope of their standards.
Currently there are almost 20,000 classes in Part 4. The library is extensible, and thus the
number is expected to grow considerably—but there is no intention that it will ever contain all
of the terminology for the entire capital projects industry.
Part 7: Template Methodology
Part 7 templates can be referred to as units of information. They are like phrases
in a natural language phrasebook that show a new user how to construct meaningful
sentences in an unfamiliar language. Part 7, like Part 2, is written independently
of computer languages. Its language is first-order logic, which is math.
We have said earlier that the vision of ISO 15926 is that “your computer can talk to my computer
and we don’t have to know anything about each other’s systems in advance.” If you are
like the author, this sounds magical. The magic comes from using Part 2 (the data model) and
Part 4 (the dictionary) together to translate data exchanges into the common language of ISO
CHAPTER 3
84

15926 so that it can be translated by your business partner at the other end.
We have said this before, but it bears repeating: if two people know what the words of a
particular language mean, and if they know the correct grammar for that language, they can
communicate seamlessly. Similarly, when two applications have a common dictionary and use
a common data model they can communicate seamlessly. Thus, Part 4 (the dictionary) and
Part 2 (the data model) are the two most important parts of ISO 15926.
The problem is that modeling information at the level of Part 2 is generic and highly specialized.
Although Part 2 enables considerable flexibility in what can be modeled, it is very complex.
If everyone using ISO 15926 had to understand Part 2, it would be as if you needed to
take a course in aeronautical engineering in order to fly on an airplane. But by using part 7
templates engineers can make their information models compliant without having to master
Part 2.
Part 7 specifies templates that are expressions of predefined units of semantics, allowing the
use of a Part 2 data model in a convenient way. Using Part 7 is similar to using a phrase book
for another language when you are travelling instead of using a language dictionary to convert
each word in your native language to a foreign language.
How ISO 15926 Templates Work
When engineers start a project, one of the first things they do is create templates of each
type of data sheet they expect to use to ensure a common look and feel across the project.
For instance, all data sheets for level transmitters will look the same and will have the same
type of values in the same place. The reason a common look and feel is important is because
human beings are the ones reading the data sheets. Humans rely on visual clues to determine
meaning, and we get used to looking for certain (essentially x,y) coordinates for particular values.
For instance, “Maximum Allowable Working Pressure” for a particular type of vessel might
be something like “1/3 of the way up the page near the right-hand side.”
But in the world of ISO 15926 machines are the ones reading the data sheets. To a machine,
the physical layout of the printed sheet means nothing. The machine is more interested in the
precise definition of the terms. And in this, Part 7 templates function for machines in the same
way templates of paper data sheets function for humans. Templates for paper data sheets
display information in visual patterns; Part 7 templates use information patterns.
The biggest difference between the type of template people are used to and Part 7 templates
is that Part 7 templates are for much smaller pieces of information. If you wanted to create a
typical equipment data sheet using Part 7 templates in order to transfer all of the information
about a piece of equipment, you would use many Part 7 templates and in fact would use many
of the Part 7 templates many times. In this way, part 7 templates can be compared to the
chemical elements.
Looking at the periodic table, you can see that there are 118 elements listed. Yet with just 118
elements the entire universe is made. Every once in awhile we find a new element, but we
don’t expect to find a great many more. For an example of an information model, let’s take a
look at a married couple (Bill and Joan) taking their dog (Willy) out for a walk after getting
home from work. Figure 3.15 shows one way to diagram this. 5
5. The “Walking the Dog” diagram is courtesy of Hans Teijgeler.
CHAPTER 3
85

class_of_person
classification
physical_object
classifier
classified
‘woman’ ‘man’
class_of_person
classification
physical_object
classifier
classified
Indirect_
other_relation
role_1 role_2 side_1 connection side_2
classification
other_class_
of_relation
classifier
classified
‘marriage’
Fig. 3.15 Walking the dog.
class_of_organism
classification
physical_object
classifier
classified
This shows that there is the relationship of “marriage” between two physical objects that are
classified as persons and identified as “man” and “woman.” There is an indirect relationship
between the “man” and a physical object classified as an organism and identified as “dog.”
If you have never seen this type of notation before it will probably look very complex. But the
reality is that the diagram is not nearly complex enough to capture everything an information
modeler would need to know. For example:
• Details about the “walking” activity.
* The period in time in which they did the walking.
* The location in which they did the walking.
• Is the marriage happy?
• Are they holding hands?
• What is the means of the indirect connection? A leash?
* What is the composition of the leash?
• What is the breed of dog?
Friends of Bill and Joan will be able to answer all of these questions because they know the
context. But our reason for modeling the information is that Bill and Joan’s friends are not the
intended audience, machines are. We want computer programs to be able to understand the
information as well as humans do.
For instance, what is the time of day? Friends will know that Bill and Joan are lab technicians
who work the afternoon shift at the local hospital. If they just got home from work, it is prob-
‘dog’
CHAPTER 3
86

ably 1:00 in the morning. Walking their dog Willy at that time of day might normally be dangerous
given the part of town they live in, but Willy is a large Rottweiler. Friends would understand
this implicitly, but if you want a machine to understand it you have to embed the entire
context into the information.
Similarly, when modeling plant information there are a great many people who work with
plant objects all day, every day—including engineers, buyers, suppliers, installation contractors,
maintenance technicians, operators, and others. These people all have a great deal of
knowledge about plant objects because they know the context. However, very few of them
will have the motivation or patience to learn information modeling. Part 7 templates allow users
to implement Part 2 without having to know Part 2.
What a Template Looks Like
Understanding the inner workings of a Part 7 template is far beyond the level of any book
with “Introduction” in its title. 6 However, a quick peek will help to explain how templates can
both be simple enough for untrained people to use while being rigorous enough to satisfy the
information modeling needs of Part 2.
Temperature Range Example
Suppose you have chosen a particular model of temperature transmitter for the project you
are working on. You will be using it many times, and thus would like to create a class so that it
is easier to use.
Manufacturer Model No. 3051CG
Ambient Temperature –40 to 85 deg C.
If you were a data modeler, it would naturally occur to you that your data model would need
the terms shown in Figure 3.16. Just as naturally, this would lead to a data model that would
look something like that shown in Figure 3.17.
Class of
Individual
3051CG
Class of Class of
Relationship
Ambient
Temperature
Single Property
Dimension
Scale
Express
Real
Express
Real
Temperature Celcius “-40" “85”
Fig. 3.16 Terms in a data model of a temperature range.
6. On the other hand, if you have a strong aversion to labor-intensive, error-prone work and want
to remove it from engineering work processes every time you encounter it, learning to model
information at the level of Part 2 will lead you to a very fascinating and rewarding career.
CHAPTER 3
87

3051CG
CO Individual
Ambient
Te mperature
CO CO Relationship
CO
Possessor
CO Indirect Property
Upper Bound Of Property Range
Classified
Classifier
Property
Space
Lower Bound Of Property Range
Classified
Classifier
Te mperature Range
-40°C–85°C
Property Range
Classifier
Classified
Temperature 85°C
Property
Classified
Classifier
Temperature
Single Property Dimension
Classifier
Classified
Te mperature -40°C
Property
Property Quantification
Input Result
Classified
Classifier
Ce lsius
Scale
Classifier
Classified
Input Result
Property Quantification
85
Arithmetic Number
Represented
Represented
-40
Arithmetic Number
Pattern ”85"
CO Identification
ExpressReal
Pattern ”-40"
Fig. 3.17 Data model of ambient temperature range.
But none of this would naturally occur to an average engineer. Fortunately, most people will
never have to learn how to do this because we can use a generic template for a property
range instead. Figure 3.18 shows a template that says “Something” has “Property Type” with
“Property Range” of “Base Property Type” defined by “Input 1” and “Input 2” with “UoM.”
Hmm…It doesn’t look much simpler.
Class
Property Type
CO
Processor
Upper Bound Of Property Range
Classified
Classifier
CO Indirect Property
Property
Space
Lo wer Bound Of Property Range
Classified
Classifier
Property
Property Quantification
Property Range Base Property Type UoM
Classifier
Classified
Classified
Classifier
Classifier
Classified
Input
Classified
Classifier
Result
Classifier
Classified
Arithmetic Number
Input
Result
Property Arithmetic Number
Property Quantification
Represented
Represented
Pattern
CO Identification
Pattern
Input 1
Input 2
ExpressReal
Fig. 3.18 ISO 15926 property range template.
CHAPTER 3
88

But what if we told you that your only requirement is to fill in the blue boxes with the appropriate
information, and that you can treat the other boxes and diamonds and connecters as
so much modern art? But it gets simpler yet. If all you have to do is fill in the colored boxes
and can ignore the rest, why even show you the rest? Why not just put the boxes into tabular
form, as in a spreadsheet? Why not, indeed. Figure 3.19 shows what users will actually have to
deal with. Simple, eh?
Template
ID
Select RDL
Class or
Project Data
ABC 3051CG
Select from
standard/
customized list of
RDL Instance
Class Property Type
Ambient
Temperature
Property
Range
(Created by
the system)
Select from
standard/
customized list of
RDL Instance
Base Property
Type
UoM Input 1 Input 2
Temperature C -40 85
Fig. 3.19 Property range template inputs.
A template is basically a regular pattern of information, like rows and columns in a spreadsheet.
The column headers in the spreadsheet are the “roles” of the template. Each row of the
spreadsheet is a template instance. Each cell in the row is a value of a role (the column heading).
The combination of the role names and role types is called the template signature. A
template definition is the generic spreadsheet itself. It defines the name of the template and
the roles, and what types of information are valid in those roles.
To review, in slightly more technical language Part 7 defines an implementation-independent
template methodology built on the Part 2 conceptual model. Part 7 provides template specification
requiring template signatures listing roles and types of each argument, and provides
an initial set of about 200 templates. These cover a wide range of concepts and are enough to
get started. When more are needed, Part 7 also contains instructions for creating new templates.
Development of Part 7 was started several years ago. It has since been split into what
is now Parts 7 through 10.
Part 8: Implementation Methods for the Integration of Distributed Systems –
Web Ontology Language (OWL) Representation
Part 8 is a method of representing information. In a natural language, it is like
paper, a computer file, or even a stone tablet—a particular way of presenting
information.
It is possible to implement ISO 15926 with spreadsheets, text files, word processor documents,
or custom code. However, there is no standard specification for doing it this way. This means
that if two companies decided to exchange ISO 15926 information using spreadsheets but
developed them independently the first versions of the spreadsheets would probably not be
compatible. Some discussion and agreement of terms would still be necessary.
Using a natural language metaphor, it would be like two people—one a Cockney from the East
CHAPTER 3
89

End of London, England, and the other a French Canadian—trying to communicate for the
first time. Even though both people speak English, the two dialects are sufficiently different
that it might take awhile for them to understand each other. Using Part 8 relieves an organization
from having to develop an implementation method from scratch, and makes it easier for
business partners to implement complementary systems.
As a metaphor, we can compare the use of Part 8 to writing a memo and somehow delivering
it to a friend. In order to compose the letter in English you would have had to use your
knowledge of English words and grammar, which are equivalent to Part 4 and Part 2. Having
the message formed in your mind is like Part 7. Putting the message on paper is like Part 8.
Sending it in an envelope through postal services is like Part 9. Part 8 is a specification for the
way to use two tools developed for the Semantic Web, Web Ontology Language (OWL), and
Resource Description Framework (RDF) to implement ISO 15926.
Web Ontology Language
We have said earlier that Part 2 and Part 4 are arranged in an ontology, with Part 2 consisting
of basic concepts and Part 4 consisting of subtypes (or specializations) of these basic concepts.
User-created RDLs will consist of subtypes, or specializations, of Part 4 classes.
The Web Ontology Language (OWL) was developed as a way of defining and managing ontologies.
A number of software packages have been developed to process OWL knowledge
directly. OWL was attractive to the developers of ISO 15926 because many of the concepts
of Part 2 correspond to specific concepts within OWL (for example, class and relation), which
makes the semantics of ISO 15926 easier to implement.
When you organize and describe plant objects with an ontology that follows the rules of
OWL, machines can follow the rules and make inferences without human intervention. For
instance, you could declare that a centrifugal pump has at least one impeller. Therefore, if a
pump does not have an impeller it cannot be a centrifugal pump.
Resource Description Framework
A resource description framework (RDF) is a way of making statements about things, which
it calls resources, in the form of subject-predicate-object expressions (known as triples). For
instance, in the declaration “My dog is a Tibetan Mastiff” “My dog” is the subject, “is a” is the
predicate, and “Tibetan Mastiff” is the object. In addition, RDF notation has the ability to make
explicit reference to published definitions through the use of URIs (discussed previously).
Thus, instead of using the text string My dog the speaker could make reference to a web
page containing a photograph of a particular instance of a dog 7 —and instead of Tibetan
Mastiff a link to the American Kennel Club’s official description of Tibetan Mastiffs. 8 An
entire capital project can be represented in this form, which will enable machines to read the
information and make correct inferences.
7. If the dog were particularly important to the breed, perhaps a male dog that had sired several show
winners, it might be included in that breed’s RDL of reference individuals.
8. In this example, the American Kennel Club’s descriptions for the various breeds of dogs are a form of
reference data library, with the address of each description being the URI.
CHAPTER 3
90

Part 9: Implementation Methods for the Integration of Distributed Systems –
Facade Implementation
Part 9 is like exposing messages in an on-line forum. It is open to the Internet,
but only certain users have the right to read certain messages.
A facade is an outward-facing view of something. In relation to ISO 15926, you can think of
this as a user interface for machines built in front of the information you have published with
Part 8. Essentially, you can post the information you wish to publish into your facade, setting
up appropriate security so that only your business partners can query for information—and so
that they can only see what you want them to see. After that, they can access whatever information
they need—when they need it.
Remember that the information you publish using Part 8 is in the form of an RDF, which is a
series of triples collectively is known as a “triple store.” A recommended protocol for querying
RDF data defined by Part 9 is SPARQL, 9 another W3C standard query language similar in
purpose to SQL but intended for triple stores.
To extend the metaphor of writing a memo to a friend, using Part 9 is like sending the message
using your national postal system. You put the message in an envelope of a certain size,
write your fiend’s name and address in a particular spot in a particular manner, and put a
particular amount of postage on it. There are laws regarding where the postman can put the
letter for delivery and who may open the letter. You also have the option of invoking certain
rules by “registering” the envelope for an extra cost, which will guarantee delivery to a real
person rather than just to your friend’s mailbox.
Putting It All Together
Figure 3.20 shows how all of the parts of ISO 15926 work together logically. 10 It is important to
note that this is not a single database but a federation of many databases. In fact, each of the
layers is made up of many databases—each supported by the owner of that data. In Chapter
1 we discussed the idea that information expressed in natural languages is usually not precise
enough to preserve the semantics, or meaning, at the level of precision required for information
exchange in capital projects. In the Chapter 2 we discussed ontologies as a way of representing
information in a manner that preserves meaning. Together, all of the layers of this
diagram form an ontology—with each layer being a subtype, or specialization, of the previous
layer (which means that the semantics of each object is preserved).
For instance, the objects at the top in Part 2 are generic concepts such as thing, class, individual,
and property. The objects in Part 4, the core classes, are subtypes (or specializations) of
the objects in Part 2. In turn, the user-defined classes are specializations of those in Part 4. Toward
the bottom, we get more and more specific until we have individual objects in a project.
9. Pronounced “sparkle”.
10. The pyramid diagram is courtesy of David Leal. It was adapted from a diagram in his paper “Life
Cycle Data for a Process Plant: An Overview”.
CHAPTER 3
91

ISO 15926-2
ISO 15926-4
User defined classes
Project Data
Axiomatic concepts such as
thing, class, individual, and
property
Generic engineering concepts,
such as physical object, activity,
composition, connection
Core classes and reference
individuals, such as pump,
reducer, heat exchanger, Cairo
Classes defined by
international standards and
industry associations
Company commodity classes
Catalogues from suppliers and
manufactuerers
Special project classes
Project Individuals such as
pump 37-P-101A and
pressure guage 37-PI-205
Core Templates
ISO 15926-7
Fig. 3.20 ISO 15926 pyramid.
Part 7 provides base templates of standard relationships. Together, the templates can be used
like a box of Lego blocks to build the database representations of the complex objects that
exist in real life. When we use the templates following the rules in Part 7, we ensure that the
resulting information follows the data model in Part 2—which means that the information will
in fact be precise enough to preserve the semantics and will integrate with other information
developed following the ISO 15926 protocols. In presentations about ISO 15926, you will
often see a little pyramid looking something like that shown in Figure 3.21. The little pyramid is
intended to represent the entire pyramid shown in Figure 3.20.
ISO 15926
Fig. 3.21 ISO 15926 pyramid symbol used in presentations.
CHAPTER 3
92

Other Parts of ISO 15926
Astute readers will note that some part numbers are missing. Appendix A lists them all, with
their most recent publication dates.
Levels of Compliance with ISO 15926 Versus Ambiguity
The purpose of ISO 15926 is to eliminate ambiguity in information so that it can be exchanged
and reused easier. Our current work practices require significant manual work because ambiguity
is inherent in the processes. Manual work drives up costs and introduces opportunities
for error. The more we use ISO 15926, the more we drive out ambiguity and automate information
exchanges to drive costs down.
Figure 3.22 shows various levels of compliance with ISO 15926 in information transfer, starting
at the bottom (with no compliance). The scale is really continuous, but we have shown six
discreet levels. The bottom two levels do not involve ISO 15926 but are included to show the
progression.
Least Ambiguity
Greatest Compliance
ISO 15926
Least Compliance
Greatest Ambiguity
Ambiguity Scale
Shouldn’t we add workflow
and security to the semantic
web?
If we use the semantic web
couldn’t we automate more of
this?
Would it help if I told you how
I was using the data?
Why don’t we use industry
standard definitions?
Wouldn’t it be better if we
agreed on common
definitions?
Let’s just exchange raw data
and figure it out together
Fig. 3.22 Levels of compliance with ISO 15926.
CHAPTER 3
93

Let’s Just Exchange Raw Data and Figure It Out Together
Figure 3.23 shows two companies, ACME and EMCA, which wish to exchange some information
contained in databases. At the beginning of the exchange, neither knows anything about
the other’s system.
• ACME selects the data to be exchanged and exports it to an intermediate file (a “data
dump”)—perhaps in a comma delimited text file or spreadsheet.
• ACME sends the data dump to EMCA.
• EMCA cannot use the information because it does not know what all of it means.
• Each company assigns an engineer to collaborate to make a custom map so that EMCA
can import the data.
• EMCA uses the map to import the data.
Level of Collaboration Required
Fig. 3.23 Figure out each exchange every time.
The two engineers cannot go directly to mapping database columns together. They first have
to understand quite a bit about each other’s applications. The dialog might go something like
this:
“What are we trying to exchange here?”
“A purchase order database.”
“Do you use a commercial package?”
“No, we developed our own.”
“Hmm. So did we.”
“Okay, how do you build your line items?”
“What do you mean, build? We type them in just as you see them on the purchase order.”
“Oh. We link directly from the 3D model and roll up identical items on the fly.”
CHAPTER 3
94

“Do you retain any information of the source of the item.”
“No. I told you we just type the line items in as you see them.”
“Okay. We’ll have to do the rollup for you.”
“Do you have any way to track overs or shorts?”
“Qu’set que c’est overs and shorts?”
“Well, if the supplier short-ships or over-ships, how do you handle this?”
“I guess the receiver writes it on his copy of the PO and someone places a phone call.”
“Hmm. We record it against the PO and the computer automatically generates a message to
the purchasing agent.”
And so on. Only after they understand what each other has and what each other needs can
they start mapping database columns against database columns.
Wooden Swing Metaphor
Earlier in this chapter we used a metaphor of a co-worker telling you about building a wooden
swing for his kids over the weekend. We compared the explanation he would have had to give
you if the two of you did not have a common understanding of basic terminology (91 words
long) with a shorter version that depended on a common set of definitions (7 words).
If we were to compare the swing metaphor to this case, we would have to make the long version
even longer. A more accurate metaphor is that you speak English and your co-worker
is just learning it, perhaps being a native of Fiji. Perhaps he has learned a few words, but still
thinks in his native language. At some point, he may end up making a little drawing and doing
some pantomime. Together, you are more or less making up a list of equivalent words in the
context of a wooden swing. This type of thing would be acceptable for a single exchange, but
what happens if further ACME and EMCA business ventures require different exchanges, or
exchanges between different applications?
Wouldn’t It Be Better if We Agreed on Common Definitions?
In Figure 3.24, ACME and EMCA exchange information often enough that there is an opportunity
to streamline the operation. They do not want to have to consult with each other with
every information exchange and start from scratch, so they agree on two things:
• They will spend a bit of time to develop the terminology for a neutral information format.
• They will not exchange raw data dumps. The sender will translate its information payload
into the neutral file format, which the receiver will be able to understand.
CHAPTER 3
95

Fig. 3.24 Common reference data library.
This is the beginning of a data dictionary, or RDL. Start by assembling the terminology.
• ACME and EMCA collaborate to create the dictionary of database terms and to decide the
format of the neutral file. 11
• Both ACME and EMCA use the dictionary to create their own database maps.
• ACME selects certain data and exports using the database map to translate it to the agreed
neutral file format.
• EMCA receives the intermediate file and imports it into its systems, using its database map
to translate it.
Level of Collaboration Required
The only difference here from the previous example is that after the two organizations agree
on the meaning of certain data items they will be able to use a standard neutral form for the
information. They will still have to agree on the meaning of the information.
As in the previous case, any new application added to the confederation will still be subject to
a detailed examination. If the new application uses new terminology, new terms will have to be
added to the dictionary. If the new application uses existing terminology in a slightly different
way, revisions to the dictionary may be required. New users may need more explanatory material
than a simple list of equivalent terms.
Wooden Swing Metaphor
Going back to the wooden swing metaphor, it is as if you were writing your own English-Fiji
dictionary not having thought of going down to your local bookstore and purchasing one.
11. It is important to agree on 100% common definitions, otherwise there is a tendency to put
proprietary information into the neutral file, and without agreement on 100% of the information we
are back to the previous case.
CHAPTER 3
96

When new terms are introduced, you will still need a discussion to discover their meaning—
and may have to revise the understanding of old terms whenever you discover new concepts.
This is a definite improvement, but what happens when the confederation of mapped applications
grows? What happens when a third and fourth organization join the confederation?
And extending the situation further, what happens when members of different confederations
have to exchange information? It is certainly possible to create new maps, and maps between
maps, but the labor needed to maintain this will grow exponentially.
Sooner or later someone will wonder whether or not there is an industry standard for data exchange.
Funny you should ask! The next example shows two organizations exchanging information
using ISO 15926-4 (the RDL) using the RDS/WIP
Why Don’t We Use Industry Standard Definitions?
In the example shown in Figure 3.25, ACME and EMCA wish to use an industry standard dictionary
to create the neutral files they use for information exchange. Being able to export information
into an industry standard format will allow them to exchange information with other
organizations as well.
• Both ACME and EMCA collaborate and agree to use the core classes in Part 4, and to use
the rules in Part 4 to extend the classes.
• Both use the dictionary to create their own database maps.
• ACME selects certain data and exports using the database map to translate it to the agreed
neutral file format.
• ACME validates its data against the core classes in the Part 4 RDL, using the RDS/WIP to
make sure it is compliant before sending it out.
• EMCA receives the intermediate file and validates it against the RDS/WIP to verify compliance.
• EMCA imports the information using its database map to translate the information into
something its systems understand.
CHAPTER 3
97

Level of Collaboration Required
Fig. 3.25 Use ISO 15926-4 for information exchanges.
The major difference here is that instead of consulting a growing proprietary dictionary, all
who are involved refer to the public standard. But both organizations will still need to have
a discussion about how they will use the core classes and will need to agree on the meaning
of new classes. (Recall our earlier discussion of your wife trying to ask you in French to get
up off the couch and mow the lawn. A French-English dictionary allowed her to translate the
individual words, but they didn’t come out the way a native French speaker would make the
same request.)
New applications added to the confederation would still be subject to a detailed discussion.
And, as before, because a new application may use existing terminology in a slightly different
way revisions to the terms used for a particular information exchange may be required. Also, as
before, new users may need more explanatory material than a simple list of equivalent terms.
Wooden Swing Metaphor
To expand the metaphor to include this case, it is as if you have discovered that you can purchase
an English-Fijian dictionary. Using a standard dictionary prepared by experts in both
languages will make things a bit easier, but will not itself remove all of your communication
problems. For instance, when new words come into the morning coffee time conversation
they will probably already be in the dictionary—but the two of you will still have to verify that
CHAPTER 3
98

you are using them correctly and will have to discover things like tonal inflection and sentence
construction by trial and error.
For instance, if your Fijian friend used just the dictionary to translate a few sentences into
English it would probably sound funny to you (and vice versa). The two of you would be able
to work through it because you know what sounds funny and can ask questions. But a computer
does not have the ability, on its own, to recognize ambiguity and work through it.
Would It Help If I Told You How I Was Using the Data?
Using Part 4 makes it easier to create database maps because both parties no longer have to
relearn data definitions each time. The parties only have to collaborate when a new term is
required, or if there is a deficiency in an existing definition. But both parties still need a fairly
good understanding of the scope of the exchange. For example, using the dictionary will
make it easier to identify the database term for the concept “maximum allowable working
pressure” However, both parties still need to know that maximum allowable working pressure
is required.
When we send an inquiry to an instrument vendor for, say, a pressure instrument, the traditional
way is to fill in a data sheet. If there were sufficient business with one vendor, we could
conceivably configure a bulk database-to-database exchange using custom mapping. If business
were sufficient, this might evolve to a custom data dictionary and then to a dictionary
using ISO 15926-4. But in all cases the data values that are required and are available still have
to be known in advance.
The more you have to know in advance about an information exchange, the more time it takes
and the more “friction” there is. We would like to be able to communicate with new business
partners almost on a whim. What we want to be able to do is simply dump out our data in a
manner our business partners can easily figure out on their own.
To meet this need, we will still use Part 4 as the data dictionary—and will still use the RDS/WIP
to validate the information on each side of the exchange. In addition, we will structure our
data according to Part 2. In the example shown in Figure 3.26 ACME wants to be able to send
information to EMCA in a manner EMCA can simply use directly or figure out easily.
CHAPTER 3
99

Fig. 3.26 Use templates to make modeling easier.
Both ACME and EMCA need to understand how to structure the neutral exchange file using
the “grammar” of Part 2 along with the definitions of Part 4. The easiest way to do this is to
use the base templates in Part 7 to build the database maps with which you will export (or
import) the neutral data exchange file. The basic difference between this method and the one
previously described is the work going into making the database maps and the composition
of the neutral file.
• ACME and EMCA collaborate and agree to use Part 7 (which implies Part 2) and Part 4.
• Each organization creates information models, or maps, to transform its internal data structures
to something that follows the ISO 15926 protocols. They use the base templates in
Part 4 and the methodology in Part 7 to create new templates when required.
• ACME selects certain data and exports it using the database map, based on Part 7 templates,
to translate it to the agreed neutral file format. As it assembles the neutral file, the template
validates the information against the core classes in the Part 4 RDL using the RDS/WIP
• ACME sends the neutral file to EMCA.
• EMCA receives the neutral file and processes it in reverse.
• EMCA uses its database map, based on Part 7 templates, to translate the information into
something its systems understand. EMCA’s templates understand how to read the meaning
CHAPTER 3
100

from the structure of the data in the neutral file.
Level of Collaboration Required
The level of collaboration required in this case is much less than in the previous case. In the
previous case, ACME and EMCA had to describe to each other how they were using their data
so that each could figure out the equivalent data elements in their own systems. The reason
they no longer have to review this person to person is that they are describing how they use
the data simply by using the base templates in Part 7.
After they implement Part 7, all they will need to know from each other is the general nature
of the information to be exchanged. Neither party has to know anything at all about the way
each other creates and uses the information because the context of the information is contained
within the information itself. The addition of Part 7 adds some initial work to fully understand
the landscape of different applications and model them properly, but thereafter the
actual data exchange becomes much simpler.
Wooden Swing Metaphor
This is where ISO 15926 starts to resemble the Babel fish we discussed at the very beginning
of this book. When your Fijian co-worker tries to explain the wooden swing, he wouldn’t have
to struggle with English—he could just speak his native language and you would understand
it just as if he were speaking your particular dialect of English. In addition, if the two of you so
desired you could delve into the species of tree used for the lumber, the chemical constituents
of the nylon rope, and the grade of steel used in the fasteners.
If We Use the Semantic Web, Couldn’t We Automate More of This?
Once we have our data exchanges in a form where the meaning of the information is embedded
into the structure of the data, Figure 3.27 shows how we can automate the process
further.
• ACME and EMCA collaborate and agree to use Part 4, Part 7 (which implies Part 2), and
Part 8.
• Each organization creates information models, or maps, to transform its internal data structures
to something that follows the ISO 15926 protocols by using the base templates in
Part 7.
• They go a step further and use Part 8 to structure their data exchanges.
• ACME selects certain data and exports it, using the database map, based on Part 7 templates,
to translate it to the agreed neutral file format. As it assembles the neutral file, the
template validates the data against the core classes in the Part 4 RDL using the RDS/WIP
• ACME posts the information to its repository and tells EMCA how to to connect to it.
• EMCA connects to ACME’s repository and selects the information it wants.
• EMCA imports the information into its systems using its database map, based on Part 7
templates, to translate the information into something its systems understand. EMCA’s templates
understand how to read the meaning from the structure of the data in the neutral file.
CHAPTER 3
101

Level of Collaboration Required
Fig. 3.27 Automating the process.
About the only collaboration required here would be something to do with the manner of exchange.
For instance, each party could post information on a particular location on the Internet
so that other users could automate downloading the appropriate parts. Alternatively, they
could send exchange files by e-mail. They would not have to discuss any details of the structure
or meaning of the information itself because the meaning of the data would be embedded
in the data itself.
Wooden Swing Metaphor
We need to venture into science fiction here to extend the wooden swing metaphor to include
this case. It would be as if your Fijian co-worker automated the morning coffee machine talk
by programming his cell phone with automatic answers to questions such as “How are you?,”
“What did you do this weekend?,” and “What did you think of the football game on Saturday?”
CHAPTER 3
102

In turn, you program your cell phone to ask these questions in case the two of you get busy
and miss each other. Your cell phone asks the questions and picks up the answers as you walk
by his cubical so that you can read them at your leisure. (And by the way, your friend writes
his answers in Fijian but your cell phone translates them to perfect English while they are being
downloaded!)
Shouldn’t We Add Query, Workflow, and Security to the Semantic
Web?
Part 9 contains tools developed for the semantic web to implement query, workflow, and security.
Figure 3.28 shows how it might work.
• Both ACME and EMCA use the base templates in Part 7 (which implies Part 2) and Part 4.
• They go a step further and use Part 8 to structure their data exchanges.
• ACME builds a facade using Part 9 to add security and allow automation.
• ACME selects certain data and exports it to its facade, as in the previous example.
• EMCA connects to ACME’s facade and selects whatever data it wants.
• EMCA imports the information into its systems, as in the previous example.
Part 9 will also make it possible for EMCA to perform more interactive queries. For instance, if
ACME maintained historical information (say, of the design of a particular piece of equipment
at each point in time), EMCA would be able to structure a query that would pull back not only
the current state of the design but the way each piece had changed over time.
CHAPTER 3
103

Level of Collaboration Required
Fig. 3.28 Automating the process with security
The only question at this stage will be something like “What’s the URL of your ISO 15926 interface
and what credentials do I need to get in?” As in the previous case, they would not have to
discuss any details of the structure or meaning of the information itself because the meaning
of the data would be embedded in the data itself.
Wooden Swing Metaphor
To the previous example we add the idea that your Fijian friend could program his cell phone
to adjust the information his cell phone gives out based on the cell phone doing the asking.
So, when the boss walks by the boss’s cell phone would get the message “I worked overtime
on the Johnson file all day Saturday.” But when you walk by your cell phone would get the
message about building the wooden swing. And as in the previous example, your friend writes
in Fijian and your cell phone gives you the messages in English.
CHAPTER 3
104

CHAPTER 4:
CURRENT EVENTS IN THE WORLD
OF ISO 15926
In this chapter we discuss current efforts to continue the development of ISO 15926, and to
use in production the parts that are ready. To explain how ISO 15926 will work, at the beginning
of this book we used the fictional babel fish—which, after placing it in your ear, somehow
converts everything you hear into your own language.
Another way of saying this is: “My computer can talk to your computer and we do not have to
know anything about each other’s systems beforehand.” To any with a background in computer
systems, this is a tall order indeed. If we express the issue this way, it sounds like we are
talking about artificial intelligence. Well, artificial intelligence would be nice but we’ve been
working on it for decades with little apparent progress.
However, we do not need actual human intelligence in a machine. For instance, you can fly—
but not like birds. In that respect, you are both more free and less free than birds. Birds cannot
fly across the Atlantic Ocean in eight hours, but you can. On the other hand, you can’t jump
off a tall building and fly across the road to visit your friends, 1 but birds can.
Similarly, we do not need actual human intelligence for information exchange. In any given
exchange, the scope we are talking about is limited. The computer programs that need to
exchange information already deal with the same real-world objects, just in a slightly different
way. All we need is to find a means of representing the attributes of these objects in a way all
computer programs can recognize. (When we express it this way, it almost sounds easy!)
When we review the history behind ISO 15926, it becomes even more believable. Soon after
CAD software came into common use, we wished we could transfer dimensional information
between different CAD software and got exchange standards such as the Initial Graphics
Exchange Specification (IGES). Then we wondered why we couldn’t also transfer information
such as surface finish and materials between various product design software and got the
Standard for the Exchange of Product Information (STEP). In hindsight, knowing the success
STEP has had in the manufacturing industry this seems almost inevitable.
But when we tried to use STEP to manage the life cycle of a process plant, we ran into the issue
of having to maintain a very complex data model for the 30- or 40-year life of the facility. That
did not work too well in practice, so we traded in the detailed data model for a simpler, generic
data model (Part 2) combined with a reference data library (RDL, Part 4) and got ISO 15926.
The theoretical development has continued with the addition of templates (Part 7), which
makes it easier to use the data model—and the addition of semantic web tools (Parts 8 and 9)
to more easily preserve the meaning of information during exchange. Development and use of
ISO 15926 is increasing every year. Current efforts can be divided into three groups.
• The use of ISO 15926 mandated by owner-operators for production systems. This is probably
the most important development because it often takes influential owners to make
a standard a requirement before the standard is accepted widely. We have two instances
1. Except, of course, if your name is Keanu Reeves.
CHAPTER 4
105

in which this is happening: in production oil facilities on the Norwegian continental shelf
(NCS) and in a pilot project to develop best practices for information handover preceding
the construction of a world-scale bitumen upgrader and oil refinery.
• The development of key infrastructure in the form of a practical reference data service
(RDS), and software enabling the use of semantic web tools for information exchange.
• The continued development of standards for geometry, instrumentation, and the harmonization
between ISO 15926 and other industry standards.
Much of this development is sponsored by Fiatech and the POSC Caesar Association (PCA).
Recently, MIMOSA and the OpenO&M Initiative (which we introduce later in this chapter) have
also sponsored projects.
Using ISO 15926 in Production
Exploration Production Information Management Association
The Exploration Production Information Management Association (EPIM) is a nonprofit association
of companies operating on the NCS in some part of the oil production supply chain.
The objective of EPIM is to develop the best IT solutions for exchanging information and to
promote these solutions to its users. EPIM is a distinct Norwegian operation, but because
most global oil producers have some work going on in the NCS the EPIM has an international
membership. EPIM jointly sponsors a number of projects with POSC Caesar, including IOHN,
EqHub, and the EPIM Reporting Forum.
Integrated Operations in the High North
The term integrated operations in the oil and gas exploration and production industry refers
to new work processes that combine information between the various disciplines within a
large oil company. For operators in very remote sites, such as the high north, there are heavy
demands on communication. Instrumentation and efficient transfer of real-time data between
the fields and centralized operations is critical to profitable development.
The Integrated Operations in the High North (IOHN) project is a collaboration of about two
dozen organizations along the oil exploration and production supply chain. The project involves
designing, implementing, and testing a digital platform—based on open standards—to
capture and transfer real-time data from drilling and production platforms to management
offices. There are three layers: a physical layer, a business layer, and a technology layer. ISO
15926 is part of the technology layer, enabling an easier exchange and integration of information
across disciplines and business domains.
Equipment Hub
Equipment Hub (EqHub) is a repository for technical information for all of the oil and gas operators
and suppliers working on the NCS. EPIM, which owns and manages EqHub, estimates
that the cost of providing necessary documentation ranges from 5 to 20 percent of the total
installed cost—depending on the type of equipment. The repository will hold and share certified
information on standard equipment, which can represent 80 percent of document vol-
CHAPTER 4
106

umes on an asset. POSC Caesar will make the existing ISO 15926 RDL available to EqHub, and
extend it to cover the EqHub scope.
EPIM Reporting Forum
The Reporting Forum standardizes the daily and monthly reports drillers and producers have
to provide to their regulatory authorities. To date, the daily drilling report, daily production
report, and the monthly production report have been standardized. Conceptually, this sounds
pretty simple—but these three reports represent the entire value of a drilling or production
asset. Smoothly operating, transparent reporting mechanisms build mutual trust among business
partners and regulators. These reports are structured according to ISO 15926, follow the
PCA oil and gas ontology, and use the PCA RDS.
MIMOSA and the OpenO&M Initiative
More money is spent in the operations and maintenance (O&M) phase of a facility, between
startup and demolition, than on the original design and construction. Capital assets—including
facilities, plants, and complex platforms—use increasingly complex automation systems requiring
many event-oriented data and information flows in order to support the intended O&M
activities. Large numbers of O&M systems need to interoperate with one another, not only at
startup but over the life of the facility—even as individual systems are upgraded or replaced.
As the complexity of the environment has increased, traditional systems integration approaches
have become increasingly difficult, expensive, and risky to implement and sustain.
Standards organizations in the O&M community (ISA, MIMOSA, OAGi, OPC Foundation, and
WBF-B2MML) have taken on the task of solving this problem in a collaborative manner via the
OpenO&M Initiative. MIMOSA, a not-for-profit trade association dedicated to developing and
encouraging the adoption of open information standards for O&M, has also helped lead efforts
to engage with Fiatech and PCA in order to solve the problem in the most sustainable way.
The solution is the system of systems (SoS) paradigm, in which individual systems are designed
to interoperate as a single composite system on a sustainable basis over the life of
the facility. MIMOSA and the OpenO&M Initiative are applying the SoS paradigm to complex
plants, platforms, and facilities. Their methodology relies on the use of shared services and information
models driven by OpenO&M use cases, which are defined and prioritized by owneroperators
on behalf of industry groups such as oil and gas, chemical, and aerospace. Collectively,
these shared services and information models form a foundational Information Service
Bus Architecture upon which owner-operator–specific functions can be built.
Using this paradigm, an owner-operator no longer must design, develop, and implement a
large custom integration solution for the core of O&M interoperability. Instead, it can require
that its suppliers leverage the industry developed solution. Systems suppliers must support
the required services interfaces, whereas engineering procurement and construction (EPC)
engineers must hand over site-specific engineering and construction information in approved
machine-readable formats. They must all agree to share industry developed RDLs.
O&M Background
In 1989, the Purdue Reference Model for Computer Integrated Manufacturing established a
CHAPTER 4
107

five-level hierarchal model of a manufacturing facility—named 0 through 4—starting from the
bottom and moving to the top. The description and details of the content of the layers have
evolved, but the basic principles have remained in active use in all major subsequent standardization
activities addressing the automation of manufacturing as well as other processoriented
industries.
• For the sake of simplicity, layers 0, 1, and 2 can be somewhat aggregated to include the
physical assets under management and the true real-time systems providing automation,
control, and monitoring.
• Layer 3 is often described as manufacturing operations management or even more generally
(and to cover environments other than manufacturing) as operations management. It
is event driven and thus operates with a time lag behind the real-time systems in the layers
below, but it tends to be timelier than transactional environments in the business-management–oriented
layer above. It is concerned with detailed operations planning and scheduling,
order fulfillment, and maintenance planning and scheduling. This space is somewhat
chaotic, with many players attempting to gain control over it.
• Layer 4 is often described as business management and typically contains the enterprise
resource planning (ERP), supply chain management (SCM), and customer relationship
management (CRM) systems used for overall management. Integration within this layer is
normally somewhat out of the box, as the systems tend to be supplied by one of the two or
three suppliers of major systems.
A key goal of MIMOSA and other OpenO&M Initiative participants is to standardize layer 3 as
the key connectivity layer in the SoS paradigm. Thus, any compliant automation and/or operations
management system will work with any compliant ERP system—and multiple compliant
systems from multiple vendors can be used in the same system. Switching cost is also dramatically
reduced, should that become necessary, although owner-operators will normally retain
compliant systems that are performing their jobs in a proper manner. Because many large
owner-operators are collaborating in this effort, their wishes carry some weight.
Bringing Engineering and O&M Together
Although design, engineering, and construction systems were largely considered out of scope
in the Purdue model, there is a critical need to include them in a sustainable SoS solution.
Typically, a large amount of manual takeoff is done using PDFs and spreadsheets as key parts
of the system implementation and integration activity. This adds significant expense, time, and
risk to the startup—and impacts full life-cycle sustainability because the lack of proper synchronization
between O&M systems and engineering systems after handover results in ambiguity
about plant, platform, and facility configuration.
As the OpenO&M Initiative has worked to define the basis for an interoperable execution environment
for an SoS, Fiatech and PCA have worked to define the basis for a shared reference
information environment based on ISO 15926 (shown in Figure 4.1). There is a tremendous
opportunity to help instantiate the sustainable interoperability environment for O&M systems
through a well targeted digital handover to the owner-operator. Whereas a capital projects
team is potentially concerned with an almost unlimited scope of detailed information that may
need to be modeled and exchanged, the information needed to be handed over to provision
the interoperable O&M environment is comparatively limited. By focusing on this defined set
of information, there is a large near-term opportunity to save time and money while improving
risk management over the entire life of the facility.
CHAPTER 4
108

Fig. 4.1 O&M reference information environment.
In 2008, Fiatech, PCA, MIMOSA, and OpenO&M initiated a collaboration to harmonize the MI-
MOSA and OpenO&M standards with ISO 15926. This will establish a shared reference information
environment supporting the interoperable execution environment for O&M systems. EPC
contractors will then be able to provide the required provisioning information using ISO 15926
protocols. The Australia-based Cooperative Research Centre for Infrastructure and Engineering
Asset Management (CIEAM) is also a key part of the collaboration through their support
of standards workshops for this portfolio of standards in conjunction with the World Congress
on Engineering Asset Management.
Joint Special Interest Groups
MIMOSA and PCA have established two joint special interest groups (SIGs) in collaboration
with Fiatech.
• O&M SIG: This group is focused on leveraging the combination of ISO 15926, MIMOSA, and
OpenO&M standards to enable sustainable interoperability of O&M systems.
• IT Architecture SIG: This group will focus on the IT-architecture–specific elements of standardization
needed to support the use of the combined standards.
The joint SIGs are performing work that will be directly applied in a large bitumen upgrader
and oil refinery being built in Canada, which has specified the use of an open execution environment
for O&M systems interoperability based on a number of use cases developed by
OpenO&M. This is a green field project scheduled to produce a commissioned plant by early
2015. The methodology for digital handover of required O&M information will be incrementally
CHAPTER 4
109

specified and piloted prior to actual implementation in the project.
The first phase of this effort is underway and will be piloted by the end of 2011. It is framed
around OpenO&M use case 1 (handover) and will focus on a debutanizer tower. A public demonstration
at an industry conference by the end of 2011 will leverage the same use case to target
data set (debutanizer tower) and open solutions architecture in an environment designed
to encourage maximum supplier participation. Subsequent phases will be incrementally
spiraled to build a virtual plant and demonstrate the full set of OpenO&M use cases. The O&M
implementation methodology for this project will be derived from the open industry activities
and will be incrementally piloted in phase with the open industry activity.
Development of Enabling Infrastructure
Joint Operational Reference Data
The Joint Operational Reference Data (JORD) project is the result of a 2009 recommendation
to build an industrial-strength RDS. An RDS is the user interface for working with and
managing an RDL for ISO 15926. Reference data is the lifeblood of ISO 15926. It accomplishes
the dual task of eliminating ambiguity in information exchanges and reducing the size of data
payloads.
You may recall from Chapter 3 that the idea of an RDL separate from a data model goes back to
the early 1990s, during the development of the STEP application protocols (APs). The first RDLs
were simple lists of attributes whereby everyone agreed to use a particular name for a particular
object. In use, these terms were “hard coded” into the database structure and database maps.
As long as all business partners knew each other well enough to trust that each used the
terminology correctly, this worked. But the vision of ISO 15926 is that organizations be able to
exchange information with anyone. What the industry needed was some way to validate terminology
when exchanging information with partners that were not known as well. The industry
needed a service for publicly available reference data based on Part 4.
In the mid 2000s, such a service was created in the form of what we now call the RDS/WIP
(Reference Data Service/Work in Progress). Anyone can use it, and with just a little training
anyone can add to it. As an experiment, the RDS/WIP has been a great success—with a number
of important lessons learned, not the least of which is the enthusiasm with which new
terms were added by people on their own learning curve. In the RDS/WIP today, there are
many terms that have been developed properly—specialized from the correct parent in good
object-oriented style.
Unfortunately, there are a great many more that have not been. It still takes a fair amount of
instruction for new users to know how to select an appropriate class. It is from experience
with the RDS/WIP that demand grew for an industrial-strength RDL, which prompted Fiatech
and PCA to sponsor JORD. Figure 4.2 shows how it will work. This diagram demonstrates
three things.
• The RDLs will be highly distributed. We have previously described the use of each term’s
uniform resource identifier (URI), which is essentially the web page for each definition. As
far as the technology is concerned, there is no reason every term in a large information
exchange could not point to a different RDL.
CHAPTER 4
110

• There will be many levels of certification. The diagram shows five levels of RDL, but in practice
there will be a continuum from private sandboxes closed to outsiders all the way up to
ISO.
• As the audience for an RDL expands, access will change from read-write (whereby definitions
can be changed) to immutable (where they will never change). There is risk in making
the decision whether or not to make definitions immutable. As an industry group starts to
develop an RDL, there will likely be a learning curve—and if all definitions had to be immutable
from the start some mistakes would inevitably be “cast in stone.” But as a given
term gains acceptance it should eventually become immutable so that organizations can
count on it. The smaller communities are in a better position to manage this risk. Industry
participants anticipate a certain amount of cascading of terminology upward as it becomes
industry standard practice.
Currently, JORD is on target in developing a funding model and proposals for working facilities.
Fig. 4.2 Federation of cascading reference data libraries.
CHAPTER 4
111

iRING
iRING is more or less a brand name for an approach to information exchange that uses the
full specification of ISO 15926. The name is an acronym of ISO 15926 Realtime Interoperability
Network Grid. It was developed with four purposes in mind.
• To prove that information exchange using the full specification of ISO 15926 is possible.
• To develop software interface tools using the full specification of ISO 15926 and make the
toolkits available to anyone under an open-source license.
• To develop best practices and make them available to those who use the tools.
• To encourage software vendors to collaborate and support iRING interfaces within their
product offerings.
Although there still is work to do before iRING technology is ready to be used on a real project,
there have been a number of very successful demonstrations. Figure 4.3 is a simplified diagram
showing how it will work. As with other information exchanges, ACME uses a database
map to transform its internal information into the form of Part 7 templates. The templates
capture the meaning of the data along with the data values. Part 8 (OWL) is used to ensure
that the ontology of ISO 15926 is preserved and then posts it to a Part 9 (Facade).
PART 7
Templates
PART 8
OWL
ACME EMCA
MAP 7 8
Part 9
Facade
9 Exchange 9 8 7
Validation
Part 9
Facade
Validation
PART 8
OWL
PART 7
Templates
MAP
Fig. 4.3 iRING information flow.
During this process, the terminology is validated with the appropriate RDLs—which are based
on Part 4. When EMCA receives the data, it processes it in reverse—validating the terminology
with the RDLs used by ACME. The software tools to configure and execute these functions are
collectively called iRINGTools, which are developed and owned by the iRINGUserGroup. The
tools are available to anyone for any purpose under what is known as the BSD three-clause
open-source license. The group also offers a ready-made RDS called iRINGSandbox that will
work with any system that uses iRING protocols.
The iRINGUserGroup continues to develop iRING technology on a very aggressive schedule. In
addition, Fiatech has sponsored two projects to continue the development of iRINGTools.
• ISO 15926 project information flow will define typical data flows in different types of capital
projects, test and validate currently available ISO 15926 tools, and assist companies in
CHAPTER 4
112

adopting ISO 15926 by highlighting implementation methodologies and achievable savings.
• The iRINGTools Interfacing Project (IIP) will deliver a set of iRING tools data layer modules
that will provide native ISO 15926 and iRING interfaces to commercial engineering software.
This means that iRING capability can be added to commercial software without having
to modify the software.
Practical Guide for ISO 15926 Modeling
To exchange information using ISO 15926, it has to be modeled according to the data model
in Part 2. To make it easier for industry professionals to use Part 2, the concept of templates—
which are like building blocks for information—was developed as Part 7. Although physically
similar to mapping two databases together with a spreadsheet (basically, you just enter the
name of the template instead of an attribute name) modeling with Part 7 is sufficiently different
that it is becoming a barrier to the wide acceptance of ISO 15926. (We provide an introductory
example in Appendix C.)
A working group is being formed to remedy this with a guide for modeling using Part 7. The
deliverable will be a manual describing how to use templates, in language that industry professionals
can understand. A good part of this will overlap with JORD, in that using an RDL is
part of using templates.
Continued Development of Standards
Geometry Special Interest Group
The Fiatech Geometry SIG is developing Part 3: Reference Data for Geometry and Topology.
Part 3 will describe a neutral way of representing graphics. It will be a dictionary that all 3D
design systems can map to in order to exchange graphical information. Part 3 is to geometry
as Part 4 is to data.
Today, many capital projects use some type of engineering design system in order to make
use of the inherent 3D visualization of those systems, their ability to check for interferences,
and their ability to produce automated drawings with fabrication details and bills of material.
Increasingly nowadays, the information about project objects is being linked directly to the
image of that object so that the 3D model essentially becomes the index to all project information.
It is important, then, that the “graphics” of the project be exchanged with ISO 15926
as easily as the “data”, and that the graphics be linked to the data.
Currently, there are a number of ways to exchange graphic images between commercial CAD
software—but they typically only exchange the graphics. Any data attached to the graphics,
or even indexes to the data, are lost. If an owner wants to take delivery of an intelligent 3D
model, about the only way nowadays is to require all of the EPC contractors to use one particular
system. The vision of ISO 15926 is to be able to exchange graphical information between
3D engineering systems as easily as any other project data.
Every 3D engineering system uses a different means of representing physical objects. For instance,
there are many ways of storing the dimensions of a piping tee. One system may record
the location of one of the connection points and the face-to-face dimensions between it and
CHAPTER 4
113

the others, whereas another may record the location of the center and the distance from there
to each of the branch connection points. Part 3 describes a single method of describing the
geometry of a part to which all systems can unambiguously map.
When Part 3 is complete, we will be able to use Part 7 templates to include geometry information
for project objects. This means that all of the information about an object is in one place.
Part 3 is based on ISO 10303-42 (Integrated Generic Resource: Geometric and Topological
Representation) and ISO 10303-104 (Integrated Application Resource: Finite Element Analysis).
Instrument Special Interest Group
Fiatech’s Instrument SIG is working to standardize the manner in which instruments are described.
One of the issues in exchanging information by converting everything into a neutral
form is making sure that all participants make the same choice of class to map a given attribute
to. In many of the prior demonstrations of ISO 15926, the goal was to develop the technology
and thus the participants were “coached” on how to choose the correct classes. But
the vision of ISO 15926 is that project participants need not collaborate at that level prior to
exchanging information.
To get an idea of the magnitude of potential differences in classification, the Instrument SIG
divided itself into two teams—with each team classifying a number of instruments on its own.
Comparing the differences in the results showed a close match, but not 100 percent. Part of
the reason different organizations may describe project objects differently is that each organization
involved in a project needs different types of information.
For instance, instrument manufacturers need complete product data for each subcomponent
of something the rest of us call an “instrument.” They need to track the part number of each
piece and all of the information required to manufacture it. In contrast, EPC contractors need
only a very small fraction of that entire lot of information—typically only overall dimensions
and properties, and functional specifications. Owner-operators need the functional specifications
too, but are most interested in maintenance and repair information.
One proposal from the instrument SIG that would make this situation easier to manage is that
there would be different Part 7 templates for different participants. Manufacturers will use
very detailed templates, whereas EPC contractors and owner-operators will use simpler ones.
Quite a bit has been done, but there is still much to do. This SIG will work closely with the joint
MIMOSA and OpenO&M initiatives, described previously.
Engineered Equipment Life Cycle Application Tools
The purpose of the Engineered Equipment Life Cycle Application Tools (EELCAT) project is to
develop specifications for the exchange of information about engineered equipment through
its full life cycle, from initial design to disposal. One of the deliverables of this project was to
explore the feasibility of harmonizing three standards: ISO 15926, the AEX XML schema, and
the Hydraulic Institute’s EDE 50.7 standard. The study concludes that such harmonization is
indeed possible, and demonstrates how it can be done.
CHAPTER 4
114

Automating Equipment Information Exchange
The Automating Equipment Information Exchange (AEX) project was sponsored by Fiatech
and has delivered and demonstrated an XML schema to automate information exchanges related
to the design, fabrication, and use of engineered equipment. The driver of AEX reads like
the original driver for ISO 15926: Equipment is designed by different groups, each with specialized
software that does not talk to each other; labor-intensive rekeying of data into each
system; additional cost; and risk of human error. The AEX schema can be used as an intermediate
neutral form for information exchange all along the equipment supply chain.
HI-EDE 50.7
As an aid to organizations wishing to exchange information on pumps, the Hydraulic Institute
has published what it calls Standard HI 50.7-2010 for Electronic Data Exchange for Pumping
Equipment, or HI-EDE 50.7. This is a dictionary of data fields and cross-listed definitions between
well-known standards such as API 610 and ANSE/ASME B73. In addition to the national
standards, the AEX schema has been harmonized with HI-EDE 50.7. Although the standard
does not mandate the use of the AEX schema, it makes reference to the appropriate term
with each data definition.
CHAPTER 4
115

CHAPTER 5:
GETTING STARTED WITH ISO 15926
A detailed set of steps for implementing ISO 15926 is beyond the scope of this introduction.
In this chapter, we provide you with a roadmap—but it will not be like a route map from your
travel agent showing the shortest route from your house to the beach. Instead, it will be more
like a map of the entire countryside—with a number of interesting intermediate points at
which you can stop.
For instance, if you lived in London, England, and wanted to go the beach at Cannes, at the
South of France, an easy way would be to take the Eurostar to the Gare de Nord train station
in Paris, transfer to the Gare de Lyon, and then take the train à grande vitesse (TGV) to
Cannes. You would have the pleasure of watching the countryside go by at 300 km/hr in airconditioned
comfort. On the other hand, if you were to channel Rowan Atkinson and take a
side road (Figure 5.1) you would have a much more interesting journey.
Fig. 5.1 A more interesting route to the beach.
Similarly, implementing ISO 15926 will probably fork into two main paths. The first path will be
for organizations that largely use unmodified commercial off-the-shelf (COS) software. The
second path will be for organizations that maintain proprietary software that supports their
own work processes.
Most organizations will follow the first path. Right now there are work teams developing
CHAPTER 5
116

proof-of-concept software that will more or less snap onto the side of a commercial application.
1 Such software will use the application’s programming interface to extract standardized
data sets (e.g., line list or equipment list) from its database, transform the data into the neutral
format of ISO 15926, and make it available to selected business partners.
Organizations with custom work processes or custom software will also be able to follow the
second path. A good metaphor is to compare building a web page 15 years ago to what it
takes today. Back then you would have had to learn how to write HTML code by hand. Today,
there are many Internet service providers who for just a few dollars a month will let you use
tools with which you can create a web page by dragging and dropping gadgets onto templates.
On the other hand, if you need something more sophisticated there is no end to what
you can do.
Key Preparation
When ISO 15926 is mature and examples of its use are common knowledge, implementing
the standard will be just like executing any other project: figure out where you are, figure out
where you want to be, make a plan to bridge the gap, and then do it. The problem now, at the
beginning of the second decade of the twenty-first century, is knowing what is possible. The
idea that “your computer can talk to my computer without either of us having to know anything
about each other’s system” sounds magical. Where do you start with magic?
Join Fiatech or the POSC Caesar Association
If you want to get to know some people who can help you out, one very good way is to join
Fiatech or the POSC Caesar Association (PCA), participate in a special interest group or two,
and get involved in a project. You will meet the people who are developing ISO 15926 and
learn firsthand from others who have implemented parts of the standard. This will give you an
excellent understanding of what is possible, the resources required, and a realistic time frame
for your own project.
Have Realistic Expectations
ISO 15926 is not a silver bullet that will instantly solve all of your data problems. In the introduction
we said that the reason we need ISO 15926 is “so that we can exchange and reuse
complex plant and project information easier and cheaper.” But if your information has been
generated with a fuzzy work process so that when you exchange information with a business
partner neither of you really knows what you have, moving it faster is not what you need.
Understand Your Data
The most important thing your organization can do to implement ISO 15926 is to thoroughly
understand your data. There are three aspects to this.
• Understand what your data means. Every organization makes assumptions; things it believes
“everyone just knows.” Find out what these are before attempting to exchange infor-
1. In Chapter 4, we introduced the iRINGTools Interfacing Project (IIP).
CHAPTER 5
117

mation with someone and thus find out too late that “everyone just doesn’t know.”
• Understand your data in terms of reference data. When we map databases together in the
traditional way, we expect to take the time to understand what every data value means.
Once we have done that, in the database mappings we can assign any random text string
as a label. But as we move forward to a time when everyone expects to be able to exchange
information with anyone we will rely heavily on our partners having classified their
data properly, and the only way to ensure this is for everyone to relate their data to publicly
accessible reference data libraries (RDLs) and validate the terms during the information
exchange.
• Understand that representing your data in a way in which the context, or meaning, is part
of the payload is fundamentally different. This is embodied in learning to use Part 7 templates.
At the higher levels of compliance, ISO 15926 uses a fundamentally different approach
to exchanging information. In the past, when we have linked two applications we
have always tried to know as much as we can about both of them. But with ISO 15926
linking applications by exploiting special knowledge is actually a liability. For most of us,
this is something we have to unlearn. We have also viewed machine-to-machine communication
as a technology problem, but we ran into the wall of not knowing how to handle the
information. ISO 15926 focuses on modeling the information to preserve its meaning as it is
being exchanged.
Implementing ISO 15926
In Chapter 3, we introduced the idea of different levels of compliance. We will demonstrate
this in our example, starting with a dictionary-level information exchange, moving to using
Part 7 templates, and finally to using the semantic web tools of Parts 8 and 9.
Let us assume that you want to automate the creation of a purchase order by selecting items
on a process and instrumentation diagram (P&ID). In many engineering systems today, engineers
enter a great deal of information that is stored in a database during design. To create a
purchase order, they extract a report of the information, attach the appropriate data sheets,
perhaps fill out a requisition form, and then send the package to a procurement officer.
When the procurement department receives the requisition, much of it has to be rekeyed—
which takes time and introduces opportunities for error. What we wish to do is eliminate all
rekeying by exporting information directly from the P&ID and create the appropriate records
in the purchasing database. The procurement officer will still assemble the purchase order in
the usual manner, only now without having to read an engineer’s handwriting.
Dictionary-level Information Exchange
The good news is that implementing ISO 15926 at the lowest level, dictionary compliance, is
not that difficult. In fact, if your organization has attempted to move information between two
computer applications you probably already know the basics and probably already have most
of the necessary skill sets represented in your present staff.
In the initial stages, the implementation team will need to fulfill three roles. The first will be
someone who understands information flow; someone who can draw boxes and arrows on
a white board. The other two roles will be the subject matter experts (SMEs) for each of the
CHAPTER 5
118

two applications. (Note here that we did not specifically say three people, we said three roles.
Depending on the size of the project, all three roles might be fulfilled by one person.)
There is nothing magical about automating an information exchange using ISO 15926 compared
to the traditional means we have at our disposal. The team will start by thoroughly
describing the information that procurement needs from engineering in order to complete the
purchase, and where engineering stores that information. They will analyze the information
flow, and at the beginning will probably name the information objects using the natural language
names they are familiar with from the dialog boxes and user interfaces of the software.
They should give some thought as to how an output from a P&ID can be generated by simply
selecting objects on-screen, and later pushing transformed data into the purchasing database.
Commercial software often comes with an application programming interface (API) that will
let users automate certain tasks. If an API is available for the two applications, the process will
be much simpler. Otherwise, a programmer may be required in the execution phase.
In the next stage, the information flows will be given more definition and the team will need to
bring in someone who can dig into the databases. Where the SMEs gave information objects
their natural names, now the database administrators will need to see what each database
calls the same objects. The team needs to thoroughly understand the meaning of the database
objects, and in particular understand implied attributes (the type that “everyone just
knows.”)
Another opportunity to understand what the data means is to examine the work processes
on each side of the exchange. Sometimes the way information is actually used will change its
meaning. About this time, the team should bring in someone with a background in information
modeling—or train someone to do it. Most computer science programs include courses in
entity relationship (ER) modeling, Unified Modeling Language (UML), or something similar. A
production database for engineering software can be quite complex, and this type of training
will be necessary in understanding it.
A likely discovery is that the data structure in each of the applications is fundamentally different.
We introduced this concept at the beginning of Chapter 1, and later on in Chapter 3.
Each application will have been developed by a different team, and each team will have made
pragmatic decisions on how its data is to be structured—depending largely on what each application
does.
We used the example of an engineering application breaking tag numbers (for example, 34-
PI-325) into their constituent parts and storing each part individually, whereas the procurement
application might store tag numbers as simple text strings. Some type of transformation
may be required, and if the APIs of the applications will not manage this some custom programming
may be required. Note that until now we have not discussed ISO 15926. Until now,
this is just like any other information exchange project.
Perhaps the first opportunity to use ISO 15926 will be when deciding how to hand off information
from one application to the next. There will be a temptation to look for fortunate
idiosyncrasies of either or both of the applications that can be exploited. For instance, there
may be some way to make one application write directly to the database of the other. This is
very much against the principles of interoperability. We have often done this type of thing in
the past and patted ourselves on the back for being ingenious. Perhaps it is ingenious, but it
forever traps us into particular versions of particular software.
CHAPTER 5
119

A better way is to make the exchange mechanism as generic as possible using some type of
neutral file exported by the first application, perhaps transformed somehow, and then imported
to the second application. Where this will become critically important is when another application
is brought into the federation. If the first information exchange uses an intermediate
neutral file, the next application may be able to use some of this directly instead of developing
another point-to-point solution.
Using the Part 4 Class Library
Another opportunity to use ISO 15926 is in naming data objects in the neutral file. In the past,
we have typically left this up to project participants. But to maximize the opportunity for
reuse, industry standard names, which have particular meanings, should be used. This way,
over time—even if people forget or if personnel changes—anyone can refer to the standard. A
good choice would be to use the classes in Part 4 rather than creating what amounts to your
own dictionary from scratch. You can purchase a copy of Part 4 from ISO or use the RDS/WIP
(Reference Data Service/Work in Progress), a publicly available RDS.
You may recall that we have said earlier that the RDS/WIP contains many terms that have not
been created properly. Although using the correct term may not be critical for a one-off information
exchange in which the actual meanings of the terms are well known, it will become
a problem in the future if an opportunity arises to add another application to your federation.
This is a good opportunity to learn to read the ontologies of the original Part 4 definitions.
• At the end of Appendix C, we have included a brief introduction to using the RDS/WIP.
• In Appendix D, we have included links to the iRINGUserGroup and one of their web pages
on choosing the correct class.
Live References to the RDS/WIP
Once you have mastered the concept of using Part 4 terminology, the next logical step is to
implement live references to the RDS/WIP during information exchange. At the simple level of
point-to-point exchange within one organization, especially after the data has been examined
for meaning, adding live references to the RDS/WIP will not immediately add a large value.
Where this will start to pay off is when other applications are added to the federation, and in
particular when external partners are added to the federation.
Although this may sound like a large paradigm shift, it is really only an incremental change.
During the mapping exercise, the biggest change is to use each term’s uniform resource identifier
(URI)—which is essentially a web page for the definition—instead of using the natural
language name.
Then, during the exchange some new software will be required to manage connections to the
RDS/WIP. A few years ago, this would have had to be written by each participant. Now, software
that does this is available under an open-source license—and some software vendors
have committed to supporting it.
There is much more to this than has been described. For instance, at some point someone will
have to look at things such as database names, database access, and network permissions.
But this will have to be done, and be done in the same way, whether or not Part 4 is used.
CHAPTER 5
120

Tools
When the project is ready for execution, there are a number of commercial and open-source
tools that have been developed in response to the demand. At the dictionary level of compliance,
the most useful will be a mapping editor. Conceptually, a mapping editor is similar
to using a spreadsheet in that the left-hand side is usually “from” and the right-hand side is
“to”—but a mapping editor makes the entire process easier to manage.
• The iRINGUserGroup has published a mapping editor and tools to support the use of the
RDS/WIP.
Template-based Information Exchange
The next level of compliance to ISO 15926 is to build some meaning into the data by using
Part 7 templates. The mechanics of using templates is very similar to straight dictionary mapping:
you simply put the name of the template into the “to” column of your mapping editor
instead of the name of the class.
The reason you would want to use templates is that it will make future information exchanges
easier. With dictionary-level mapping, there is still the possibility that you and your business
partner do not define terminology the same way. (We have previously used the example of
two people from different cultures learning the same foreign language. With different backgrounds,
each will define concepts differently. When first starting to communicate, they will
need a period in which they review terminology together.) When both parties use Part 7 templates,
there is a much greater chance they will have a common understanding of each term.
Another reason to use templates is that you will be able to include relationships between data
objects. A simple example of this is being able to relate a pipeline number to a nozzle on a
tank, then to the tank, to a logical location in the plant, and to a physical location in the plant.
The real knowledge is in knowing which templates to use. For this, you will need your information
modeler to come up to speed with Part 7 templates.
Information Modeler
• In Chapter 4, we mentioned the Practical Guide to ISO 15926 Modeling. This is a very good
place to start.
Tools
• The iRINGUserGroup publishes a set of tools for using Part 7. There are some commercial
offerings as well.
Semantic Web
The parts of ISO 15926 that use the semantic web are Part 8 (OWL) and Part 9 (Facades). As
we described in Chapter 3, you would implement these if you wanted to automate some of
your work flow (Part 8) and if you wanted to include some security (Part 9).
The good news here is that if you have properly used Part 7 templates to represent your data
you can simply add Parts 8 and 9 without redoing any of your database mappings. Some new
software will be required, and a few years ago each participant would have had to write it.
CHAPTER 5
121

Now, however, software is available under an open-source license—and some software vendors
have committed to supporting it.
Summary
Taken step by step, implementing ISO 15926 does not have to be a huge and expensive exercise.
Of course, if an organization with a great deal of proprietary software and work processes
were to decide to adopt ISO 15926 on a large scale it would require a large effort—just as
converting one’s entire parts library from a paper catalog to an online catalog would require a
large effort. But a pilot project to validate the process and gain experience is within the ability
of most organizations.
Just a few years ago, each participant would have had to write the specialized software required
to support ISO 15926. Now, open-source software has been published that does this—and some
commercial software vendors have promised to support it. The part each organization will have
to do on its own is to understand its data. The personnel to support an introductory project can
likely be drawn from the existing ranks of most medium to large organizations.
Dictionary-level Mapping
• We have described the role of the project leader as “someone who can draw boxes and
arrows on a white board.” This is, of course, a gross simplification. What we mean is someone
with a logical mind who understands abstract reasoning. Obviously, the ideal candidate
would be someone with both a strong computer science background and a strong
discipline background. But if only one or the other is available it will be easier to teach the
computer science skills that are actually necessary (for a project leader role) to a discipline
specialist than to attempt to teach the discipline-specific skills to a computer science
graduate.
• SMEs for each application that will be brought into the federation. These people will understand
how to get information into and out of the applications.
• A database administrator will be able to get into the databases for each application.
• An information modeler will be able to structure information to retain the meaning of the
data involved. (There is a large overlap here with the role of database administrator.)
• A network administrator will understand how the organization’s network works and will be
able to assign rights and privileges.
• The role of application programmer will be required if the API of each application in your
federation will not support the full transformations that may be required. If internal resources
are not available, this may have to be outsourced.
Template-based Information Exchange
• Part 7 information modeler: Using Part 7 is different from straight database mapping, but
this can be taught to an existing team member.
Semantic Web
• Parts 8 and 9 implementer: Software tools to support Part 8 (OWL) and Part 9 (Facades)
CHAPTER 5
122

have already been written and are available under an open-source license. As well, a market
for such tools has evolved and these types of tools will be increasingly supported by
commercial software vendors. Implementing these tools is well within the capability of the
IT departments of most medium to large organizations.
Join Fiatech or the POSC Caesar Association
If there is any mystery remaining, it can be dispelled by meeting like-minded people, and the
best way to do that is to join Fiatech or PCA and get involved. Outside of working on ISO
15926, many of us are competitors. The natural tendency, then, is to horde information. But if
we can cooperate to develop ISO 15926 digital information exchange gets easier, information
exchange on projects becomes easier, and as projects become easier and cheaper the owners
(who in the end, pay for everything) will be able to do more. The pie gets bigger. There are a
number of reasons organizations and groups of individuals join a consortium.
Owner-operators
Owner-operators want to improve their bottom line. Collectively, owners fund the entire
operations of the other players. These include EPC contractors, equipment manufacturers,
software developers, construction contractors, and universities—funded directly or via costs
embedded in other fees. However, they lack the expertise to do the basic research and apply
it to day-to-day operations. In a consortium, such as Fiatech or PCA, owner-operators have a
forum whereby they can explain their needs and work with others on solutions.
EPC Contractors
EPC contractors get involved with consortiums to solve problems their competitors and clients
also have. Everyone can work together, share the costs, and share the results. EPC contractors
can take research from universities, prove it in the field, and then recast it in terms
that others in their industry can understand.
Software Developers
Software developers join a consortium to assist in developing standards that make software
development easier. For instance, on the subject of information exchange software developers
must be responsive to their customers and provide conversion between many competing
standards. But if all industry players agree on a single standard the work of software developers
will suddenly get much easier.
Equipment Manufacturers and Construction Contractors
Equipment manufacturers and construction contractors, with tighter margins, join a consortium
to participate in projects they would never be able to fund on their own.
Universities
Universities participate in a consortium so that they can see their research applied in realworld
projects.
CHAPTER 5
123

APPENDIX A:
THE PARTS OF ISO 15926
This appendix summarizes the current state of the various parts of ISO 15926. We have treated
Parts 2, 4, 7, 8, and 9 in some detail in Chapter 3. In Chapter 4, we introduced the geometry
SIG that is developing Part 3. Here we introduce the other parts. ISO standards are developed
with the voluntary involvement of all interests worldwide. There are three main phases.
1. The need is expressed by an industry sector and proposed as a new work item, and a technical
scope is defined.
2. Consensus building where the detailed scope is negotiated between the countries involved.
3. Formal balloting and acceptance is carried out worldwide.
Each standard is assigned to an appropriate technical committee/subcommittee (TC/SC). ISO
15926 falls under TC 184 (Automation Systems and Integration) SC 4 (Industrial Data). During
development of a standard, it may be published in a number of states.
• PWI: Preliminary work item
• NP: New work item proposal
• CD: Committee draft, by a committee of experts
• TS: Technical specification, after a consensus within the appropriate TC/SC
• DIS: Draft international standard
• FDIS: Final draft international standard, ready for formal vote
• PRF: Proof of a new international standard
• IS: International standard
ISO 15926
Formal name: Industrial automation systems and integration. Integration of life-cycle data for
process plants, including oil and gas production facilities.
Part 1
Formal name: Overview and Fundamental Principles
Publication date: 2004
Status: IS
Part 1 is the introduction to ISO 15926 and describes its purpose, which is to facilitate data
integration by means of a data model that defines the meaning of information in a way that all
users of the information will have the same understanding of what it means.
APPENDIX A
124

Part 2
Formal name: Data Model
Publication date: 2003
Status: IS
Part 2 is the conceptual data model for representing technical information about project
objects. The original mandate was life-cycle information about process plants, but this has
expanded to include pretty well any type of capital project because there is so much overlap.
Part 3
Formal name: Reference Data for Geometry and Topology
Publication date: 2009
Status: TS
Part 3 is reference data for geometry and topology for 2D and 3D shapes. It consists of an
ontology of basic classes of curves and surfaces that can be used with computer-aided design
(CAD), Geographic Information Systems (GIS), and earth models. This means that you will be
able to use Part 7 templates to include geometry information about project objects. Part 3 is
based on ISO 10303 Part 42 (Geometric and topological representation) and Part 104 (Finite
element analysis).
Part 4
Formal name: Initial Reference Data
Publication date: 2007, with an amendment in 2010
Status: TS
Part 4 defines the initial set of reference data for use with ISO 15926 and ISO 10303-221. ISO
issues the reference data in the form of spreadsheets. Currently, there are almost 20,000 individual
terms.
Part 5
Formal name: Procedures for Registration and Maintenance of Reference Data
Status: Discontinued
Part 5 was the procedures for registration and maintenance of reference data. This function
has been taken over by an SC4 commission for class library maintenance not only of ISO
15926 but of other ISO reference data libraries contained in databases.
APPENDIX A
125

Part 6
Formal name: Scope and Representation for Additional Reference Data
Status: NP/TS
Part 6 is the methodology for the development and validation of reference data. It describes
how to validate a reference data item to ensure that it is genuine. It describes the information
required for a new reference data item and how to have it approved. It lists the metadata used
for the provenance of the objects in an RDL.
Part 7
Formal name: Implementation Methods for the Integration of Distributed Systems: Template
Methodology
Status: PRF/TS
Part 8
Formal name: Implementation Methods for the Integration of Distributed Systems: Web Ontology
Language (OWL) Implementation
Status: PRF/TS
Part 9
Formal name: Implementation Methods for the Integration of Distributed Systems: Facade
Implementation
Status: Draft
Part 10
Formal name: Implementation Methods for the Integration of Distributed Systems: Abstract
Test Methods
Status: Draft
An abstract test method is a generic description of how to test software systems to validate
ISO 15926 compliance. “Abstract” means there is no coupling with a computer language or
brand of test software; this must be filled in by the implementer. Part 10 only handles full compliance;
it does not list the criteria for partial compliance—which is up to the business.
When something like ISO 15926 is in development, the people working on it form a community
and get to know each other. Within the community, there is a natural check and balance on
whether one’s work conforms. But when ISO 15926 is mature users will need a way to judge
whether or not their business partners’ systems are in compliance. Part 10 will fulfill the need
APPENDIX A
126

for a way to test systems to see how well they comply.
Part 11
Formal name: Simplified Industrial Usage of Reference Data, Including Gellish Implementation
– Working title: Gellish – RDF
Status: NP/TS
Gellish is a structured subset of natural language that can be used to express knowledge in a
way that is readable by both humans and machines, and is system independent. Knowledge
can be represented in a way that allows machines to artificially reason and come to conclusions.
Gellish is the outgrowth of the development work on ISO 10303-221 (AP221) and ISO 15926-
2 (Part 2), both of which we introduced in Chapter 3. You may also recall that AP-221 had
an Annex M, which consisted of standard instances of the types of objects in the Part 2 data
model. Over the years, Annex M was extended and became known as STEPlib and eventually
used as the basis of Part 4.
Since then, STEPlib has become the Gellish Dictionary—containing concepts, and relationships
between those concepts, arranged in a taxonomy that supports inheritance. Gellish can be
used as a front end for the template methodology of Parts 7 and 8, or it can be, and has been,
used on its own for information exchange on major projects.
APPENDIX A
127

APPENDIX B:
COMPLIANCE WITH ISO 15926
ISO 15926 is a standard with many parts, not all of which have to be implemented at once.
As well, there are variations in the manner in which some of the parts can be implemented.
Therefore, simply saying “My system has implemented ISO 15926” does not give a true picture
of your system’s capabilities.
The vision of ISO 15926 is that business partners can exchange information without engaging
in a lengthy process of understanding the meaning of each other’s data. But implementing
only one part of ISO 15926 at its simplest level does not demonstrate this capability. New
users are, understandably, confused. This appendix outlines the various categories of compliance
to give users a rough guide to comparing systems. The following table serves as a
“thumbnail.” 1
Category Compliance Checklist
Semantic precision
Representation technology
Referencing technology
Interface technology
Industrial standardization
Dictionary identification only
Shortcut relations
Full ontology
Any formatted file
Proprietary XML
RDL XML
Part 8 (OWL)
URIs contained in schema
External RDL
File exchange
Proprietary query
Part 9 (SPARQL)
Community sandbox
Industry-wide sandbox
JORD
ISO
Subject matter scope BIDG
Metadata scope
Explicitly identifiable elements
Versioning
Status
1. Thanks to Ian Glendinning for the material this section was adapted from.
APPENDIX B
128

Functional capability
Semantic Precision
Export interface
Import interface
Empty seed
Lossless consolidation
Reconciliation
ISO 15926 is all about driving out ambiguity to reduce the risk and cost of information exchange.
Semantic Precision is the most technically significant of the categories outlined in the
previous table. This category compares the way information is understood by an organization
to what was intended by ISO 15926.
This category recognizes that it is possible to use ISO 15926 terminology incorrectly. An
extreme example is using the word pressure in a database mapping exercise to exchange
temperature values. As long as both parties to the exchange knew what the text string pressure
really meant, the exchange would work—but using terminology this way is misleading
to new users and would add a great deal of uncertainty and risk to future exchanges using the
same database maps.
Part 7 templates have what is known as a signature, which removes the ambiguity by providing
a mechanism by which a system can recognize what the template is intended to deal
with. Thus, in the extreme example previously cited the user would never be presented with a
“pressure” template when working with temperature. At the receiving end, the software would
recognize the template as dealing with temperature and would act accordingly. There are different
ways of recognizing template signatures. This category gives increasing credit as their
reliability increases.
• Dictionary and typing level: Templates have a name, are specialized from a parent class,
and have a classification. This level of compliance simply accepts these values from the
template itself.
• Shortcut relations level: This level uses the shortcut relations to determine what the template
does.
• Full onotology level: This level uses the full ontology along with the signature to identify
the template.
Representation Technology
This category compares the manner in which the information exchange is structured.
APPENDIX B
129

Any File
This exchange uses a neutral file, as opposed to, for example, having one application writing
to the database of another. This removes one potential failure point; namely, that one or the
other application changes and thus breaks the information exchange. There are many ways
of encoding information. Fixed-width text file, comma-delimited text file, and spreadsheet are
three. The common denominator is a proprietary structure that users have to examine. Any
structure can be made to work as long as both parties understand it in advance.
Proprietary XML
Using XML to encode information is a step up from a plain-text file or spreadsheet. New users
will still have to examine the terminology used, but the structure of an XML information exchange
is easier to deduce.
Reference Data Library Registered XML Schema
A registered XML schema eliminates the need to examine it closely for every information
exchange. Users will still have to examine it and thoroughly understand it the first time, but
thereafter should not need to. This meets one of the intents of ISO 15926 is that two organizations
can independently implement a given standard and thereafter exchange information
even though they may never have explicitly intended to work with each other at the beginning.
Part 8: OWL
When the information you are exchanging is part of an overall ontology, it is easier to figure
out what it means simply by examining its position in the ontology. If the ontology conforms
to Part 2, exchange partners will be able to understand what your data means without having
to ask about it. OWL is a tool designed for the Semantic Web that is used to exchange information
stored in an ontology. If your exchange system uses OWL, ontological information will
be preserved so that the meaning of the data will be preserved with the data.
Referencing Technology
Reference data is the lifeblood of ISO 15926. Without reference data there is no objective way
to verify the definitions of terms, and where you cannot verify terms there is ambiguity that
adds to the cost. In ISO 15926, the reference data is based on Part 4. This category considers
the way reference data is implemented.
URIs Self-contained in Schema
The URI of a term is like a web site for its official definition. The name of each term is unique
and has exactly one URI, and therefore the name of the term is synonymous with its URI. One
way to implement Part 4 terminology is to hard code the name or URI into the schema.
APPENDIX B
130

URIs Resolvable in Shared Reference Data Libraries
Another way to use Part 4 terminology is to have a mechanism that uses a term’s URI to connect
to a reference data service, like the RDS/WIP, to verify that it is a valid term.
Interface Technology
The interface type describes how the information is physically moved. Under the hood, all information
exchanges use a file to exchange the data. The key question in this category is how
the file comes into existence.
File Exchange
Here we mean that the sender prepares the information exchange file by some means and
sends it to the exchange partner, who then opens and reads the file in some manner.
Proprietary Query
This category implies that the recipient of the information can directly query the information
to create the exchange file instead of having the owner prepare the files.
Part 9: SPARQL
SPARQL is a protocol developed for the Semantic Web, designed for querying OWL databases.
The use of OWL is one way to preserve the meaning of the data.
Industrial Standardization
This category assumes that a reference data library (RDL) is used for the information exchange
and measures the manner in which it is certified. The boundaries, although somewhat
arbitrary, show increasing global authority.
Community Sandbox
Here, a community will create its own RDL. The group manages the content on its own.
Industry Level
Here, the community is larger—encompassing an entire industry. At this level there will likely
be some formal method of creating and vetting new terms.
PCA/JORD Level
This level combines the terminology of many industries. Although JORD does not exist yet,
it is expected that there will be a stringent vetting procedure to ensure that the terminology
APPENDIX B
131

conforms to the intent of ISO 15926.
ISO
This level is reserved for formally adopted, world-wide standards.
Subject Matter Scope
This category anticipates one or more industry-specific information guides to assist users in
deciding the scope of the information that needs to be exchanged. This will not create any
new terminology to add to an RDL, but will rather suggest which RDL items need to be addressed
to accomplish some business purpose. For instance, the American Petroleum Institute
(API) may recommend specific RDL terms to use when exchanging information about API
pumps.
When a standard scope of information is exchanged, the uncertainty (the ambiguity) is reduced.
The Business Interfaces Definition Guide (BIDG) was originally the title of a particular
handover guide being developed for the process industries, but the document was issued under
a different name. Now the term is still used but has effectively come to be an umbrella for
a number of industry-specific guides. For measuring compliance to ISO 15926, this category
means that you are following one such guide—and that the guide specifies ISO 15926 terminology.
Metadata Scope
When data is exchanged as part of business activities, there are usually obligations and contractual
responsibilities between the parties. With each information exchange, metadata (data
about data) is in fact created (such as the time of exchange)—which may have to be recorded
manually if there is no automatic mechanism. This category measures how the metadata is
captured and recorded.
Explicitly Identifiable Elements
This category means that metadata is indeed exchanged (as opposed to only the data values
themselves) and that the metadata explicitly identifies the data values to which it belongs.
Versioning
This category means that in addition to the identity of the data the vintage, or version, of the
data is maintained.
Status
This category means that in addition to the identity and versions of the data the status of the
data is maintained.
APPENDIX B
132

Functional Capability
This category measures the capability of the system to send and receive data.
Export Interface
This is the ability of a system to deliver information independently of data scope and interface
technology. This is accomplished by publishing the data or allowing reading or querying.
Import Interface
This is the ability of a system to receive information independently of data scope and interface
technology. This is accomplished by allowing external applications to write to the database, or
some means of querying external databases.
Seed
Sometimes an instance is created as a placeholder, with no initial content. This category
means that the placeholder can be populated with imported data without loosing anything.
Lossless Consolidation
This means that an existing instance that contains data can be updated with new imported
information, correctly handling versions and duplicate information.
Reconciliation
This means that when an instance is updated with internal information any reconciliation with
external identifiers is retained.
APPENDIX B
133

APPENDIX C:
EXAMPLES OF DATABASE MAPPING
In this appendix we will work through some examples of mapping databases directly together,
using a custom dictionary and the Reference Data Service/Work in Progress (RDS/WIP). We
will also introduce you to the use of templates from Part 7. As far as an introduction to ISO
15926, this section is definitely “extra credit.” You do not have to read this to understand the
concepts of ISO 15926.
Chapter 1 provided a brief introduction to the topic of mapping two databases together. In
Chapter 3, we talked about mapping during the discussion on the levels of compliance to ISO
15926. There we gave a number of examples of organizations exchanging information with
increasing levels of implementation of ISO 15926. In this appendix, we will continue with these
examples—showing how to do the mapping that is described in each example. Please bear in
mind that these examples are highly simplified for the purpose of explaining concepts. In the
real world, this is a complex enough subject that many professionals make a very good living
just connecting databases to each other.
The entire point of ISO 15926 is that anyone using the standard’s protocols can exchange
information with anyone else using the protocols and not have to know anything else about
the other’s system. Just as two people who do not know each other can nevertheless communicate
if both use the same rules of grammar and the same dictionary, two parties in a data
exchange can understand each other’s information if both use the ISO 15926 data model, Part
2 (or Part 7, which implies Part 2), and the classes, or dictionary, Part 4. We will compare each
set of mapping examples to this vision for ISO 15926.
Example Set 1: Let’s Just Exchange Raw Data and Figure It Out Together
In this first set of examples we will look at mapping two databases together directly.
Example 1.1: Map Two Databases Together, Simple
Figure C.1 shows the work process of exchanging information by mapping two databases
together. At the beginning of the exchange, neither party knows anything about the other’s
system.
• ACME selects the data to exchange and exports it to an intermediate file (a “data dump”)—
perhaps in a comma-delimited text file or a spreadsheet.
• ACME sends the data dump to EMCA.
• EMCA cannot use the information because it does not know what all of it means.
• Each company assigns an engineer to collaborate to make a custom map so that EMCA
can import the data.
• EMCA uses the map to import the data.
APPENDIX C
134

Roles
Fig. C.1 Figure out each exchange every time.
In Chapter 5, we identified two roles required for basic dictionary-level compliance.
• A subject matter expert, (SME) who thoroughly understands the business in which the two
applications are involved. This person must understand the meaning of all business objects
involved to ensure that the correct data is transferred.
• A database administrator to create the mapping tables between each application and the
Part 4 terms.
The most important is the SME. This person will examine the information and decide which
objects in one database are equivalent to those in the other. Our first example (Figure C.2)
is very simple. We will use a portion of a valve list from one of our favorite companies, ACME
(which we will pretend is an EPC contractor).
ACME Table Name: Valve_List
ID Dwg_No Rating PID No Spec Line Tag
85457 4567-32-17 150 1234-32-45 A373 10-32-A373-12-1438
96058 4567-32-17 300 1234-32-45 B893 10-32-B893-10-0378
48981 4567-32-17 600 1234-32-45 C578 10-32-C578-10-2155
Pipe Size Valve Tag
12 32-1269
10 32-2958
8 32-7639
Fig. C.2 EMCA valve list table.
A valve list is a list of all valves used for a particular scope of work or project. Design engineers
use the valve list to ensure that each is properly specified. Procurement officers use it to
make sure that all valves have been purchased. Construction contractors use it to ensure that
they have received all of the valves and that all valves have all been installed.
The goal here is to transfer the information from ACME to our other favorite company, EMCA
(which we will assume is a construction contractor), by mapping the databases together and
pushing a button to execute the exchange electronically—rather than exchanging paper documents
and having a person rekey the values. Figure C.3 shows EMCA’s valve list, currently
empty.
APPENDIX C
135

EMCA Table Name: Table_32
Index No Dwg_No Rating PID Mat_Spec Line_Tag Diameter Tag
Fig. C.3 EMCA valve list table.
The job of the SME of both ACME and EMCA is to understand each term (i.e., the database
column names) of both companies and decide which of them are equivalent. The convention
is to ignore the data rows and put the column names from each database into a two-column
table, with the table name on the left and the column names on the right. Figure C.4 shows
what this looks like.
ACME EMCA
Table Name Column Name Table Name Column Name
Valve_List ID Table_32 Index No
Valve_List Piping DRG Table_32 Dwg_No
Valve_List Class Table_32 Rating
Valve_List PID_No Table_32 PID
Valve_List Spec Table_32 Mat_Spec
Valve_List Line_Tag Table_32 Tag
Valve_List Pipe Size Table_32 Diameter
Valve_List Valve Tag Table_32 Tag
Fig. C.4 ACME and EMCA valve list column names.
To show equivalence, the SME will arrange the column names of the respective tables into
the same horizontal row. Specialized software will be able to read this list and copy the data
values from the ACME table/column to the EMCA table/column.
In this very simplified example, we can see that the column names are descriptive of their content—and
although not identical in both tables it is easy to determine equivalence. Also note
that, uncharacteristically, they are already arranged horizontally to show equivalence. The job
of the SME is finished.
The application experts still have to figure out how to get the information out of ACME’s database
and into EMCA’s, and the database experts still have to configure the data migration.
Although these jobs may be quite complex, depending on the nature of ACME’s and EMCA’s
systems, they are straightforward conceptually.
Example 1.2: Map Two Databases Together, Harder
The previous example was trivially simple in order to convey the concept of mapping two databases
together without getting bogged down with details. In this example, we will use a more
realistic pair of valve tables. Figure C.5 shows what the two valve lists might really look like.
APPENDIX C
136

ACME EMCA
Table Name Column Name Table Name Column Name
VALVE_LIST AREA TABLE_32 CLIENT_SYSTEM
VALVE_LIST CLASS TABLE_32 CLIENT_UNIT
VALVE_LIST COMP ID TABLE_32 COM_GRP
VALVE_LIST DATASHEET TABLE_32 DES_RESP
VALVE_LIST DS_ID TABLE_32 DIAMETER
VALVE_LIST LINE TAG TABLE_32 DIAMETER_UOM
VALVE_LIST MANUFACTURER TABLE_32 DWG_NO
VALVE_LIST MATERIAL TABLE_32 HEAT_TRACE
VALVE_LIST MODEL NO TABLE_32 HOLD
VALVE_LIST OP PRESS TABLE_32 INDEX_NO
VALVE_LIST OP TEMP TABLE_32 LINE_NUMBER
VALVE_LIST PID NO TABLE_32 LINE_TAG
VALVE_LIST PIPE SIZE TABLE_32 MAT_SPEC
VALVE_LIST PIPING DRG TABLE_32 PID
VALVE_LIST RUN TABLE_32 PID_LOCATION
VALVE_LIST SERVICE TABLE_32 PID_REV
VALVE_LIST SPEC TABLE_32 PROJ_NO
VALVE_LIST STATUS TABLE_32 QUANTITY
VALVE_LIST TAG TABLE_32 RATING
VALVE_LIST TAGTYPE TABLE_32 SEQ_NO
VALVE_LIST VALVE TAG TABLE_32 STARTUP
VALVE_LIST VALVE TEXT TABLE_32 SUFFIX
VALVE_LIST VALVE TYPE TABLE_32 SYSTEM
VALVE_LIST VCODE TABLE_32 TAG
VALVE_LIST VINT1 TABLE_32 UNIT
VALVE_LIST VNUM TABLE_32 VALVE_LOCK_DEVICE
VALVE_LIST VSIZE TABLE_32 VALVE_NUMBER
VALVE_LIST VUNIT TABLE_32 VALVE_TYPE
Fig. C.5 More realistic column names.
In this example, the SMEs have much more work to do. Each column name has to be examined
closely to verify what it means. It is not good enough to look up the name in, say, the Oxford
English Dictionary; you need to see how it is actually used by the application. This is because
the column names do not actually mean anything to the database software; they are just text
strings. (The only thing that really matters to the software is that the names are unique.)
Good database design principles recommend that descriptive names be used, but this is just
for the convenience of human programmers. Even if the columns were named properly in
the beginning, changes to the software over time can effectively change their meaning while
leaving the original name unchanged. We will review several column names to show you how
mapping is done, and then rearrange them to show which are equivalent.
ACME TAG and VALVE TAG Versus EMCA TAG and RECORD_ID
We cannot conclude that two columns contain equivalent information just because they use
the same word for their name. For example, both ACME and EMCA use the column name TAG.
Our first thought may be that this is for a component tag number, similar to an instrument tag
number or equipment tag number, but we need to look further.
ACME also uses the column name VALVE TAG, and EMCA also uses RECORD_ID. Given
these extra names, we cannot determine their meaning simply by looking at the other names
on these two lists; we must dig into the software to see how it uses the names.
APPENDIX C
137

We may obtain some clues by looking into the database to see what types of values are
stored there, but we may also have to open the software and start experimenting. For instance,
in the software that uses ACME’s and EMCA’s valve tables there will be a form (or
computer screen) that asks for the valve’s asset identification number. We can enter a fictitious
value and then look for it in the database to see where it turns up.
For this example, we will assume that ACME’s TAG and EMCA’s RECORD_ID are equivalent—
recording what we might call a record index number (a unique numerical value the database
software uses to identify a row in the database).
We will also assume that ACME’s VALVE TAG and EMCA’s TAG are equivalent, being used to
store the valve’s asset identifier. For most in-line valves this value will be empty, or null. When
a valve is important enough to track individually, it will be given a tag number that is stored in
this column.
ACME VNUM Versus EMCA SEQ_NO
VNUM and SEQ_NO are two more names we cannot make a decision about by simply looking
at the other database column names. For this example, we will assume that this is an optional
place to store another tracking number for a valve.
Some owner-operators give all of their in-line valves that do not already have a tag number a
unique identifier to help track maintenance. When ACME and EMCA work for an owner with
such requirements, they use these columns to store the unique number.
ACME LINE TAG Versus EMCA LINE_NUMBER and LINE_TAG
As with VALVE TAG, it would be easy to jump to the conclusion that ACME’s LINE TAG and
EMCA’s LINE_TAG are equivalent. But EMCA also uses the name LINE_NUMBER. All three
of them could be used to store the alphanumeric text string we commonly call a line number.
Here again we must see how the software processes line numbers and see which database
columns it uses.
For this example, we will assume that ACME uses LINE TAG to store the full line number. (In
Figure C.2 we saw the example 10-32-A373-12-1438.) EMCA uses LINE_TAG for the
same purpose. EMCA’s LINE_NUMBER stores the sequential numeric part of the line number
(1438 in the line number given previously).
ACME PIPE SIZE Versus EMCA DIAMETER and DIAMETER_UOM
An important concept to understand is that an organization may have certain assumptions
about the world that every employee “just knows.” A possible example of this is the EMCA
column name DIAMETER_UOM. We might ask why ACME does not have something like this.
Perhaps ACME gets all of its work from one area of the world and uses only one system of
units in all of its projects. If this were the case, everyone would just “know” what the units
were and there would be no real need to record such a value in the database.
Although this is possible, an equally likely answer is that ACME does not store the units of measurement
with every measurement. In this example of a valve list, ACME may feel that it is ex-
APPENDIX C
138

tremely improbable that a valve will be measured in one system of units and the piping system
to which it is attached measured in another system. The units of measurement may be attached
to the pipeline the valve is part of, or it may be a project-wide setting. Like our other examples,
the SMEs will have to look at the software to see how it handles units of measurement.
The SMEs will similarly examine the rest of the terms and decide which are equivalent. Figure
C.6 shows the tables after rearranging column names so that equivalent names are in the
same horizontal row.
ACME EMCA
Table Name Column Name Table Name Column Name
VALVE_LIST TAG TABLE_32 RECORD_ID
VALVE_LIST PIPING DRG TABLE_32 DWG_NO
TABLE_32 STARTUP
VALVE_LIST CLASS TABLE_32 RATING
TABLE_32 PID_REV
TABLE_32 DES_RESP
VALVE_LIST PID NO TABLE_32 PID
TABLE_32 HOLD
TABLE_32 HEAT_TRACE
TABLE_32 PROJ_NO
TABLE_32 LINE_NUMBER
VALVE_LIST SPEC TABLE_32 MAT_SPEC
VALVE_LIST LINE TAG TABLE_32 LINE_TAG
TABLE_32 QUANTITY
VALVE_LIST PIPE SIZE TABLE_32 DIAMETER
TABLE_32 DIAMETER_UOM
TABLE_32 VALVE_LOCK_DEVICE
TABLE_32 VALVE_NUMBER
VALVE_LIST VNUM TABLE_32 SEQ_NO
TABLE_32 CLIENT_SYSTEM
TABLE_32 COM_GRP
TABLE_32 SYSTEM
TABLE_32 PID_LOCATION
VALVE_LIST VALVE TYPE TABLE_32 VALVE_TYPE
TABLE_32 SUFFIX
VALVE_LIST VUNIT TABLE_32 UNIT
VALVE_LIST VALVE TAG TABLE_32 TAG
TABLE_32 CLIENT_UNIT
VALVE_LIST VSIZE
VALVE_LIST AREA
VALVE_LIST DATASHEET
VALVE_LIST TAGTYPE
VALVE_LIST VCODE
VALVE_LIST STATUS
VALVE_LIST MATERIAL
VALVE_LIST OP PRESS
VALVE_LIST OP TEMP
VALVE_LIST MANUFACTURER
VALVE_LIST MODEL NO
VALVE_LIST VALVE TEXT
VALVE_LIST VINT1
VALVE_LIST RUN
VALVE_LIST SERVICE
VALVE_LIST COMP ID
VALVE_LIST DS_ID
Fig. C.6 Two valve lists showing equivalence.
You will notice that many of the column names do not have a corresponding name in the other
database. There could be a number of reasons for this. It could be that the nature of the business
of each of the two organizations means that each pays attention to different things. An
APPENDIX C
139

example of this is EMCA’s column name HOLD. If EMCA’s work process places holds against
valves during the course of its own work, it may not need the value to come from ACME.
Another example is the ACME DATASHEET column name. Because it is an EPC contractor, it
needs to know exactly how each valve is manufactured and what each part is made of. This
information is usually recorded on a data sheet, and recording the datasheet number with the
valve record ensures that future engineers will be able to find it. For its part, EMCA may simply
assume that the data sheet for a tagged valve is always named after the valve tag number
and therefore there is no point in recording it. (Note that this assumption may in fact not be
true. Nevertheless, if EMCA believes it and designs its databases around that belief we have to
work with EMCA’s assumptions.)
How the SMEs handle this “missing” information depends a great deal on what EMCA needs
to use the information for. It could be that the information ACME’s valve list has in common
with EMCA’s valve list is all that EMCA needs. For example, because the design of the valve is
not in EMCA’s scope of work it would have no need to track the operating temperature and
pressure for each valve. (It would need to know the testing pressure of the entire pipeline, but
this information is probably on the line list.)
On the other hand, if EMCA actually needs some of the “missing” information the SMEs will
have to ask their respective application and database experts where to get it. We will discuss
this in the next example.
Example 1.3: Map Two Databases Together, More Complex
So far the examples have assumed that equivalent database tables all have columns for
equivalent values. This is almost never the case. We do not wish to turn readers into database
administrators, but we will give an example by extending the previous discussion of the units
of measurement.
In this example, we will assume that EMCA needs the DIAMETER_UOM field to be populated
for its software to work. ACME will almost certainly have a record of the units of measurement
somewhere, and probably for the same reason EMCA needs it, but ACME’s software does not
store it in the valve list. ACME’s SME will need to enlist the help of application and database
experts to figure out how to provide EMCA with the information it needs. There are at least
two options.
If ACME’s SME knows absolutely for sure that 100 percent of the dimensions are, for instance,
in Imperial measure, the database expert could write a small program to simply add that value
to the database table as it is being exported. The problem, as you may have guessed, is with
the “absolutely 100 percent” part. You can never know whether or not some specialized valve,
available from only one place in the world, has a unique metric size.
A more reliable way to solve the problem is to figure out where the ACME records the units of
measurement, and then pull it in from there. It could be anywhere. It could be attached to the
line number the valve is associated with, a single project setting, or anything in between.
For this example, we will assume that the appropriate unit of measurement comes from the
line number. However, for illustrative purposes we will throw in a wrinkle. We will pretend that
the software does not store this in a table based on the alphanumeric text string we call a line
APPENDIX C
140

number but in a separate table based on an arbitrary “pipe run number.” 1 Figure C.7 shows
what this might look like.
ACME EMCA
Table Name Column Name Table Name Column Name
. .
VALVE_LIST LINE TAG LINE TAG RUN NO TABLE_32 LINE_TAG
. .
TABLE_32 DIAMETER_UOM
RUN NO UOM
Fig. C.7 Finding units of measurement.
What the database expert has to do, then, is to write what is called a query. Following the arrows
from the left-hand side (Figure C.7), the query basically says:
a. Given this LINE TAG, what is the RUN NO?
b. Given this RUN NO, what is the UOM?
c. Copy the UOM to DIAMETER_UOM of the table we export for EMCA.
Comparison to the Vision of ISO 15926
These examples are like two people who speak different languages attempting to communicate
by pointing at something and saying its name. After a while both of them would understand
what each other’s individual words mean, but would still be a long way from fluent
communication. For a one-off situation this may be acceptable, and if the two parties never
had any need to communicate in the future this may even be the preferred solution.
However, we must understand that all of this work of pointing to things and saying their
names will have to be repeated if the two participants want to bring more applications into
their federation—and if they envision including more partners. This amounts to point-to-point
mapping and is very much against the vision of ISO 15926—and in fact was the reason the
standard was first proposed.
Example Set 2: Wouldn’t It Be Better to Agree on Common Definitions?
Example 2.1: Creating a Custom Dictionary Using Arbitrary Names
One problem in mapping databases directly together is that you have to go through the same
process every time you connect the databases. Even if you keep the map around, after awhile
people change (or they forget) and they have to go back to the applications and figure out all
over again what the attributes mean. One way to manage this is to create a data dictionary.
In Figure C.8, ACME and EMCA exchange information often enough that there is an opportunity
to streamline the operation. They do not want to have to consult with each other with every
information exchange and start from scratch, so they agree on two things.
1. Among other things, doing it this way allows users to change the line number if they have to.
APPENDIX C
141

• They will spend a bit of time to develop a common set of terminology.
• They will not exchange raw data dumps. The sender will translate its information payload
into a “neutral file” using standard terminology the receiver will be able to understand.
Fig. C.8 Common reference data library.
This is the beginning of a data dictionary, or reference data library. Start by assembling the
terminology.
• ACME and EMCA collaborate to create the dictionary of database terms and to decide the
format of the neutral file.
• Both ACME and EMCA use the dictionary to create their own database maps.
• ACME selects certain data and exports it using the database map to translate it to the
agreed neutral file format.
• EMCA receives the intermediate file and imports it into its systems, using its database map
to translate it.
Next, create a list consisting of a number of standard definitions, with a particular word associated
with each definition. The associated word can be completely arbitrary. For instance, at
a gathering to discuss techniques of mapping databases together one of the instructors—in a
moment of inspiration—said, “If you have to translate something from one language to another
using a third language as an intermediate, you can use any language you wish—Klingon—
whatever!” To make a point, we will do just that. Table C.1 shows a possible dictionary of the
terms both ACME and EMCA have in common.
TABLE C.1
STANDARD DEFINITIONS USING KLINGON NUMBERS
Name Definition
wa’ Unique identifier for a row in a database.
cha’
The alphanumeric text string that uniquely identifies an orthographic
drawing.
APPENDIX C
142

wej The nominal pressure rating for a piping system or component.
loS
The alphanumeric text string that uniquely identifies a piping and
instrumentation diagram (PID).
vagh The material specification for a pipeline.
jav The alphanumeric test string that uniquely identifies a pipeline.
Soch The nominal diameter of a pipeline.
chorgh The units of measurement of the nominal diameter of a pipeline.
Hut Maintenance tracking number for hand valves.
wa’maH The general category to which a valve belongs (e.g., gate or globe).
wa’maH wa’
wa’maH cha’
The geographic or functional area of a plant; commonly called
“unit.”
Asset tracking number for individually designed components; commonly
called “tag number.”
The second step for ACME is to create a database map (this time using the dictionary names),
and then using the map export the information to a table that will be sent to EMCA. Figure
C.9 shows what the table might look like. Figure C.10 shows how EMCA will receive the neutral
file. EMCA will also create a database map using the dictionary names, but will instead use it
to import the neutral file into its database.
ACME Klingon Database Map Neutral File
Table Name Column Name Column Name Dictionary Name
VALVE_LIST TAG TAG wa'
VALVE_LIST PIPING DRG PIPING DRG cha'
VALVE_LIST CLASS CLASS wej
VALVE_LIST PID NO PID NO loS
VALVE_LIST SPEC SPEC vagh
VALVE_LIST LINE TAG LINE TAG jav
VALVE_LIST PIPE SIZE PIPE SIZE Soch
UOM chorgh
VALVE_LIST VNUM VNUM Hut
VALVE_LIST VALVE TYPE VALVE TYPE wa'maH
VALVE_LIST VUNIT VUNIT wa'maH wa'
VALVE_LIST VALVE TAG VALVE TAG wa'maH cha'
Fig. C.9 Data export using a Klingon neutral file.
APPENDIX C
143

Neutral File Klingon Database Map EMCA
Dictionary Name Column Name Table Name Column Name
wa' RECORD_ID TABLE_32 RECORD_ID
cha' DWG_NO TABLE_32 DWG_NO
wej RATING TABLE_32 RATING
loS PID TABLE_32 PID
vagh MAT_SPEC TABLE_32 MAT_SPEC
jav LINE_TAG TABLE_32 LINE_TAG
Soch DIAMETER TABLE_32 DIAMETER
chorgh DIAMETER_UOM TABLE_32 DIAMETER_UOM
Hut SEQ_NO TABLE_32 SEQ_NO
wa'maH VALVE_TYPE TABLE_32 VALVE_TYPE
wa'maH wa' UNIT TABLE_32 UNIT
wa'maH cha' TAG TABLE_32 TAG
Fig. C.10 Data import using a Klingon neutral file.
Example 2.2: Creating a Custom Dictionary Using an Ontology
Of course your organization would not really use Klingon for dictionary terms; it would probably
use a collection of nouns and adjectives that were themselves descriptive of the terms
they describe. 2 For a single, small information exchange you could probably live with ad hoc
names. But as you add applications to your federation of applications you will probably run
across many terms that are similar, with only subtle variations.
As you add definitions to your dictionary, you may find that some of your original names
overlap with the meaning of new terms and so become misleading. One strategy is to create
an ontology of names that contains all of the terminology at your organization. Then, when
a new application is added to the federation it can simply pull the correct term from the list.
Table C.2 shows part of a possible ontology that covers the information in the ACME-EMCA
exchange.
TABLE C.2
PART OF AN ONTOLOGY OF TERMS
asset_tracking_no
component_valve_type
database_row_id
drawing_no
drawing_no_pid
drawing_no_pid_revision_no
drawing_no_piping
drawing_no_piping_iso
2. On the other hand, your organization would gain instant street cred if they were to do so. Star Trek
gatherings are heavily overrepresented by geekish, nerdish types; just the types that make up most
of your IT department. You may in fact find that your database administrator can read Klingon
directly.
APPENDIX C
144

drawing_no_piping_ortho
maintenance_tracking_no
piping_line_no
piping_line_no_sequence
piping_material_spec
piping_nominal_diameter
piping_uom
plant_id
pressure
pressure_class
pressure_design
pressure_test
production_train_id
production_unit_id
row_id
From here it is a simple matter to construct a database map and export the data to a neutral
file, just as we did with the Klingon dictionary. Figures C.11 and C.12 show what this might look
like.
ACME Database Map Neutral File
Table Name Column Name Column Name Dictionary Name
VALVE_LIST TAG TAG row_id
VALVE_LIST PIPING DRG PIPING DRG drawing_no_piping_ortho
VALVE_LIST CLASS CLASS pressure_class
VALVE_LIST PID NO PID NO drawing_no_pid
VALVE_LIST SPEC SPEC piping_material_spec
VALVE_LIST LINE TAG LINE TAG piping_line_no
VALVE_LIST PIPE SIZE PIPE SIZE piping_nominal_diameter
UOM length_uom
VALVE_LIST VNUM VNUM maintenance_tracking_no
VALVE_LIST VALVE TYPE VALVE TYPE component_type_valve
VALVE_LIST VUNIT VUNIT production_unit_id
VALVE_LIST VALVE TAG VALVE TAG asset_tracking_no
Fig. C.11 Data export using an ontological neutral file.
APPENDIX C
145

Neutral File
Database Map EMCA
Dictionary Name Column Name Table Name Column Name
row_id RECORD_ID TABLE_32 RECORD_ID
drawing_no_piping_ortho DWG_NO TABLE_32 DWG_NO
pressure_class RATING TABLE_32 RATING
drawing_no_pid PID TABLE_32 PID
piping_material_spec MAT_SPEC TABLE_32 MAT_SPEC
piping_line_no LINE_TAG TABLE_32 LINE_TAG
piping_nominal_diameter DIAMETER TABLE_32 DIAMETER
length_uom DIAMETER_UOM TABLE_32 DIAMETER_UOM
maintenance_tracking_no SEQ_NO TABLE_32 SEQ_NO
component_type_valve VALVE_TYPE TABLE_32 VALVE_TYPE
production_unit_id UNIT TABLE_32 UNIT
asset_tracking_no TAG TABLE_32 TAG
Fig. C.12 Data import using an ontological neutral file.
We have used a very simplified example of an ontology. In fact, what is shown is not really an
ontology but an ordered list. Users are simply agreeing to use a particular English word to
mean a particular thing instead of using a Klingon number. Although certainly a big step over
the Klingon-based dictionary, it would not direct a new user unambiguously to the correct
term every time. A discussion with other users would still be required to be certain that some
terms were being used correctly. Arranging the terms in a real ontology would help. Figure
C.13 shows part of an ontology for pumps.
Fig. C.13 Part of an ontology of pumps.
Using this ontology of pumps (arranged the way it is) with the proper accompanying definitions,
new users will be more likely to choose the correct term without having to talk to anyone.
The bad news is that if you have never created an ontology your first few attempts will
likely require reworking every time you add a new application to your federation. An easier
way is to use an ontology that someone else has developed. In the next example, we will introduce
such an ontology based on Part 4.
Comparison to the Vision of ISO 15926
Building a custom dictionary means that information exchange partners will not have to learn
everything all over again every time they wish to exchange information. New partners are a bit
better off because they do not have to start from scratch, but they still have a fair amount of
work to do. They will still have to review the dictionary to thoroughly understand the terms,
APPENDIX C
146

and may find that some terms conflict with their own understanding. Worse, every time a new
member joins the federation there is potential rework for all members. What everyone needs
is an industry standard dictionary, such as Part 4, so that they only have to go through the
pain once.
Example Set 3: Why Don’t We Use Industry Standard Definitions?
Using Part 4 definitions is the minimum standard for compliance with ISO 15926.
Example 3.1: Using the RDS/WIP as a Dictionary
In this example, ACME and EMCA wish to use an industry standard dictionary to create the
neutral files they use for information exchange. Being able to export information into an industry
standard format will allow them to exchange information with other organizations as well.
The RDS/WIP is just such a dictionary. It was commissioned in the mid 2000s as an experimental
reference data service anyone could use as a reference—and with a little bit of training
as a source for adding new terms.
• Both ACME and EMCA collaborate and agree to use the core classes in Part 4 and to use
the rules in Part 4 to extend the classes.
• Both use the Part 4 dictionary to create their own database maps.
• ACME selects certain data and exports it using the database map to translate it to the
agreed neutral file format.
• EMCA imports the information using its database map to translate the information into
something its systems understand.
Level of Collaboration Required
The major difference here is that instead of consulting a growing proprietary dictionary all
who are involved refer to the public standard. However, partner organizations will still need
to have a discussion about how they will use the core terminology whenever two terms mean
almost the same thing. New applications added to the confederation will still be subject to
a detailed discussion. In addition, a new application may use existing terminology in slightly
different ways. If so, the partner organizations will have to decide whether or not to change
the term or to modify the new application. But changing the meaning of a term could have a
serious effect on existing applications.
New Role
There is a new role here. Someone has to learn how to use the RDS/WIP. 3
• The RDS/WIP modeler, who will learn how to use the RDS/WIP, how to read the taxonomy
of existing terms, and how to prepare new submissions.
3. Remember that the RDS/WIP is experimental. When ISO 15926 is mature, there will be a selection of
RDLs to choose from.
APPENDIX C
147

At the end of this appendix we have included a brief introduction to the RDS/WIP, but basically
you just search for a term and find the closest match. If two or more terms are close in
meaning, you will have to negotiate with your business partner to decide which to use. If a
new term is required, you add it. Once you decide on the term, you will actually use the universal
resource indicator (URI; more-or-less the term’s serial number) instead of the term
itself. Table C.3 shows a possible list of terms from the RDS/WIP that might be used as for the
valve list.
TABLE C.3
ATTRIBUTES FROM THE RDS/WIP
Label RDS/WIP URI Description
IDENTIFIER http://rdl.rdlfacade.org/data#R32813486958
DRAWING
IDENTIFICA-
TION CODE
http://rdl.rdlfacade.orgdata#R16893283050
PRESSURE
RATING CLASS http://rdl.rdlfacade.orgdata#R45649298385
P AND I DIA-
GRAM
MATERIAL
SPECIFICA-
TION
PIPELINE OF-
FICIAL IDEN-
TIFIER
http://rdl.rdlfacade.org/data#R99486931975
http://rdl.rdlfacade.orgdata#R54400593721
http://rdl.rdlfacade.org/data#R83498125174
DIAMETER http://rdl.rdlfacade.orgdata#R94482935208
UNIT OF MEA-
SURE
http://rdl.rdlfacade.org/data#R5817703946
An identification code
for a drawing or a class
of drawings
Classes of standard
pressure ratings (i.e.,
the maximum allowable
non-shock working
gage pressure at a
given temperature and
a specific material)
A diagram showing a
schematic representation
of a process system,
including instrumentation
A specification that describes
the applicable
materials for one or
more items
An identification code
that identifies a pipeline
Intercept made by the
circumference on a
straight line through
the center of a circle
A role used in ST 3401
to designate the applicable
scale in which
the numerical value is
expressed
APPENDIX C
148

SEQUENCE
NUMBER
PR3 1.10
VALVE TYPE/
DESIGN
FUNCTIONAL
UNIT IDENTI-
FIER
TAG IDEN-
TIFICATION
CODE
http://rdl.rdlfacade.orgdata#R73944050980
http://rdl.rdlfacade.org/data#R49125478120
http://rdl.rdlfacade.org/data#R14322658775
http://rdl.rdlfacade.org/data#R99047027503
A number assigned
following an order of
succession
Assignment of valve
type (e.g., safety, relief,
or safety relief), and
design (e.g., conventional,
bellows, or pilot)
An identification code
that identifies a functional
unit
An identification code
for a functional_
physical_object.
Figure C.14 shows how ACME will use these terms to create a map with which to export the
data to a neutral file. Figure C.15 shows how EMCA will create its own map with which to
import the data from the neutral file. Note that instead of English descriptive names we are
using long numerical text strings. Astute readers will notice that this is conceptually the same
as using Klingon. And if that is where we stopped, the readers would be correct. 4
ACME
Database Map
Table Name Column Name Column Name Dictionary Name
VALVE_LIST TAG TAG http://rdl.rdlfacade.org/data#R32813486958
VALVE_LIST PIPING DRG PIPING DRG http://rdl.rdlfacade.org/data#R16893283050
VALVE_LIST CLASS CLASS http://rdl.rdlfacade.org/data#R45649298385
VALVE_LIST PID NO PID NO http://rdl.rdlfacade.org/data#R99486931975
VALVE_LIST SPEC SPEC http://rdl.rdlfacade.org/data#R54400593721
VALVE_LIST LINE TAG LINE TAG http://rdl.rdlfacade.org/data#R83498125174
VALVE_LIST PIPE SIZE PIPE SIZE http://rdl.rdlfacade.org/data#R94482935208
UOM http://rdl.rdlfacade.org/data#R58177039466
VALVE_LIST VNUM VNUM http://rdl.rdlfacade.org/data#R73944050980
VALVE_LIST VALVE TYPE VALVE TYPE http://rdl.rdlfacade.org/data#R49125478120
VALVE_LIST VUNIT VUNIT http://rdl.rdlfacade.org/data#R14322658775
VALVE_LIST VALVE TAG VALVE TAG http://rdl.rdlfacade.org/data#R99047027503
Neutral File
Fig. C.14 Data export using RDS/WIP class names.
4. In fact, if the organizations were to hard-code the definitions they would be better served to use the
“Label” from Table C.3 rather than the URI. We used the URIs in order to introduce the next section.
APPENDIX C
149

Neutral File Database Map EMCA
Dictionary Name Column Name Table Name Column Name
http://rdl.rdlfacade.org/data#R32813486958 RECORD_ID TABLE_32 RECORD_ID
http://rdl.rdlfacade.org/data#R16893283050 DWG_NO TABLE_32 DWG_NO
http://rdl.rdlfacade.org/data#R45649298385 RATING TABLE_32 RATING
http://rdl.rdlfacade.org/data#R99486931975 PID TABLE_32 PID
http://rdl.rdlfacade.org/data#R54400593721 MAT_SPEC TABLE_32 MAT_SPEC
http://rdl.rdlfacade.org/data#R83498125174 LINE_TAG TABLE_32 LINE_TAG
http://rdl.rdlfacade.org/data#R94482935208 DIAMETER TABLE_32 DIAMETER
http://rdl.rdlfacade.org/data#R58177039466 DIAMETER_UOM TABLE_32 DIAMETER_UOM
http://rdl.rdlfacade.org/data#R73944050980 SEQ_NO TABLE_32 SEQ_NO
http://rdl.rdlfacade.org/data#R49125478120 VALVE_TYPE TABLE_32 VALVE_TYPE
http://rdl.rdlfacade.org/data#R14322658775 UNIT TABLE_32 UNIT
http://rdl.rdlfacade.org/data#R99047027503 TAG TABLE_32 TAG
Fig. C.15 Data import using RDS/WIP class names.
Example 3.2: Using the RDS/WIP to Validate an Information Exchange
In the previous example, ACME and EMCA used the RDS/WIP as a dictionary—simply using
the URIs of the definitions to create their map. In this example, they wish to use the RDS/WIP
for real-time validation to make sure the URIs are in fact valid terms. Figure C.16 shows how
this will work. The collaboration here is the same as that of the previous example, with two
new activities.
• ACME validates its data against the core classes in the Part 4 RDL—using the RDS/WIP to
verify that it is compliant before sending it out.
• After EMCA receives the intermediate file, it validates the terminology against the RDS/
WIP to verify compliance.
APPENDIX C
150

New Role
Fig. C.16 Use ISO 15926-4 for information exchange.
• ACME and EMCA will each need a programmer to write the code for checking database
terms with the RDS/WIP. (A market for such tools has emerged and there are now a number
of commercial and open-source tools to make this task easier.)
Comparison to the Vision of ISO 15926
Readers may wonder what the difference is between hard coding terminology into a database
map and validating with “live” URIs as the exchange is made. If the hard-coded term is identical
to the URI in the RDS/WIP, what does it matter? The answer is that if you were to exchange
information only between a few well-known applications or a few well-known business
partners there would be no effective difference between hard-coded and live URIs. But the
vision of ISO 15926 is that any two organizations will be able to exchange information with a
minimum of preparation required. Having both the sender and receiver validate the URIs during
the exchange increases each party’s confidence in the information and reduces ambiguity.
Example Set 4: Would It Help if I Told You How I Was Using the
data?
Although using industry standard definitions (and Part 4 definitions in particular) is the minimum
requirement for compliance with ISO 15926, there is still room for ambiguity. For in-
APPENDIX C
151

stance (to reuse an example from the Introduction), just because a native Mandarin speaker
and a native Cantonese speaker understand English well enough to use it as an intermediary
language it does not necessarily mean they will be able to communicate seamlessly from the
very beginning. Because they come from different cultures, they may find that they use some
words differently—which means that when first communicating there must be a time when
definitions are verified.
For others to know what we mean by certain terms, without having to go through the process
of verifying what we mean, we need a way to embed the context in which we use these terms
into the data. In addition to using Part 4 to make sure our terminology matches the industry
standard, when we also use the “syntax and grammar” of ISO 15926 (which is Part 2) we are
doing just that. Using Part 7 templates makes it easier to use Part 2 correctly.
Exchanging information with Part 7 templates is fundamentally different from dictionary mapping.
The purpose of this example is to give you a glimpse of how different it is, without becoming
a “How to” lesson. This example will show how the use of part 7 templates means that
the meaning (or context) of the data is stored with the data so that we do not have to engage
our business partners in discussions of what the data means before sending information. We
have seen a trend toward this throughout the examples in this appendix. We started off with
mapping one database directly to another, where both parties had to know a great deal about
each other’s systems in order to trust that the information was being exchanged correctly.
From there we went to custom dictionaries (where only the dictionary writers needed such
intimate knowledge), and then to external RDLs—where we only needed knowledge of the
published RDL term. In this example, we will also use the RDL terminology (and still have to
thoroughly understand what they mean)—but because we will be using Part 7 templates we
do not have to engage our business partner in discussions of the form of the data or even the
precise content; we just send “a bunch of stuff”, and our partner will be able to figure it out.
This is the essence of ISO 15926: we can exchange information with anyone without having to
know anything about their internal systems beforehand.
Example 4.1: Using Templates to Exchange Information
Figure C.17 shows ACME and EMCA using Part 7 templates to structure their data so that its
meaning will be part of the exchange. ACME and EMCA will still use Part 4 as the data dictionary,
and will still use the RDS/WIP to validate the information on each side of the exchange,
but in addition they will structure their data according to Part 2. The easiest way to do this is
to use the base templates in Part 7 to build the database maps with which they will export (or
import) the neutral data exchange file.
• ACME and EMCA collaborate and agree to use Part 7 (which implies Part 2) and Part 4.
• Each organization creates information models, or maps, to transform its internal data structures
to something that follows the ISO 15926 protocols. They use the base templates in
Part 4, and the methodology in Part 7, to create new templates when required.
• ACME selects certain data and exports it using the database map, based on Part 7 templates,
to translate it to the agreed neutral file format. As it is assembling the neutral file,
the templates validate the information against the core classes in the Part 4 RDL (using the
RDS/WIP).
• ACME sends the neutral file to EMCA.
APPENDIX C
152

• EMCA receives the neutral file and processes it in reverse.
• EMCA uses its database map, based on Part 7 templates, to translate the information in the
neutral file into something its systems understand. EMCA’s templates understand how to
read the meaning from the structure of the data in the neutral file.
Level of Collaboration Required
Fig. C.17 Use ISO 15926-7 for information exchange.
The level of collaboration required in this case is much less than in the previous case. After
both companies implement Part 7, all they will need to know from each other is the general
nature of the information to be exchanged. Neither party has to know anything at all about
the way the other creates and uses the information because the context of the information is
contained within the information itself. The addition of Part 7 adds some initial work to fully
understand the landscape of different applications and model them properly, but thereafter
the actual data exchange becomes much simpler.
New Role
• An information modeler will map business objects in the applications to the prepared templates
in Part 7.
Metaphor
So that you can understand what the exchange is trying to accomplish, we will start with a
APPENDIX C
153

metaphor about making inferences. Suppose we were to make this assertion: Barack Obama
- is the - President of the United States. Most people today who read the news will have no
trouble understanding what this statement means. But suppose your name is Valentine Michael
Smith and you have just been repatriated to Earth after being born on Mars and raised
by Martians for twenty years. 5
You would not even have the concept of “government,” let alone of “president”—and the political
divisions the rest of us know as countries would not occur to you naturally, so you would
have no way to understand this. However, if someone were to tell you that Barak Obama is human
you would be able to infer that he has hair simply because you are human too and have
hair. Moreover, you would be able to deduce this well before grokking any earthling political
nonsense.
Similarly, in this example ACME will create some information about a pressure transmitter
and send it to its business partner EMCA—which makes pneumatic tubes for sensing devices.
However, EMCA does not understand “pressure transmitter.” Why? Well, perhaps they are
Martians, but a more plausible explanation is that they do not care about pressure transmitters
as a separate class of devices for which they make pneumatic tubes. All they care about is the
pressure rating and connection type.
ACME
ACME’s intention is to pass information about a pressure transmitter, which has the tag number
PT-101 and 3/4-inch NPT connections, to EMCA—which will fabricate some pneumatic
tubing to connect to it. ACME will first identify the device using the template ClassificationOfIndividual,
which has two columns (or roles, Individual and Class)—as shown in
Figure C.18.
Individual: xyz
ClassificationOfIndividual
Individual Class
xyz URI of the class
Pressure Transmitter
Fig. C.18 Use of the ClassificationOfIndividual template.
xyz is the identifier ACME uses internally for the individual it will later identify as PT-101.
It uses the alias for a number of technical reasons, one of them being the potential need to
change the name PT-101. If PT-101 changed to, say, PT-2101, ACME would only have to
change this in one place (as we shall see) instead of many places.
5. The author, who reads far too much science fiction for his own good, believes that a metaphor
involving a human being raised by Martians to be totally plausible. If you read Stranger in a Strange
Land, by Robert Heinlein, the metaphor will make more sense.
APPENDIX C
154

Class: The URI of the Class Pressure Transmitter
In our previous examples, we showed how ACME could interrogate the appropriate RDL to
find the URI of a given term or class. If humans were intended to read this, ACME might consider
using the English description of the class. However, because this template is intended for
a computer the URI is actually easier to use. Once the transmitter has been classified, the next
step is to identify it using the template ClassifiedIndividual (Figure C.19)—which has
three roles: Individual, Name, and ClassificaitonOfIndividual.
Individual: xyz
ClassifiedIndividual
Individual Name ClassificationOfIndividual
xyz PT-101 URI of, say, ISA
xyz is ACME’s internal identifier.
Name: PT-101
Fig. C.19 Use of the ClassifiedIndividual template.
Here we can see how the name PT-101 could be changed by changing it in just one place.
There is no other place where the text string PT-101 occurs.
ClassificationOfIndividual: ISA
ISA will tell other users the way the name is to be interpreted. In this case, ACME is using the
convention ISA (for Instrument Society of America). But, as before, instead of using the text
string ISA it uses the URI of the class ISA.
The next templates (Figure C.20) will contain the properties of the transmitter. For this, ACME
will use two different templates: IndirectPropertyScaleReal (which has the four roles
Individual, Property, Value, and Units of Measure) and IndirectProperty (which has the
three roles Individual, Property, and Value).
APPENDIX C
155

EMCA
lndirectPropertyScaleReal
Individual Property Value Units of Measure
xyz
URI for the class Operating
Pressure
100 URI for the class of kPa
lndirectProperty
Individual Property Value
xyz
URI for the class End
Connection
URI for the class of NPT
lndirectPropertyScaleReal
Individual Property Value Units of Measure
xyz
URI for the class Connection
Size
0.75 Inches
Fig. C.20 Use of the IndirectPropertyScaleReal and IndirectProperty templates.
When EMCA receives the information, its system will first look through the data for the template
ClassificationOfIndividual, and everything associated with it, using the identifier
of the individual (xyz). EMCA could continue to use xyz, but chances are that it has a
different internal numbering system and thus each individual will be given different identifiers.
For the example of PT-101, we will use abc—as indicated in Figure C.21.
Class: Pressure Transmitter
ClassificationOfIndividual
Individual Class
abc URI of the class
Pressure Transmitter
Fig. C.21 Individual identifiers in the ClassificationOfIndividual template.
EMCA’s system does not know what to do with Pressure Transmitter not because its
engineers have never heard of such a device but because it has no reason to care. Rather than
store all of the different types of devices to which its pneumatic tubes might potentially connect,
it simply ignores the class.
What EMCA’s system looks for is the templates containing the operating pressure, the thread
form of the connection, and the size of the connection—as shown in Figure C.22. Now that
EMCA knows the values it is looking for, its system can reform the data into whatever EMCA
needs to drive its fabrication and order fulfillment system.
APPENDIX C
156

lndirectPropertyScaleReal
Individual Property Value Units of Measure
abc
URI for the class Operating
Pressure
100 URI for the class of kPa
lndirectProperty
Individual Property Value
abc
URI for the class End Connection
URI for the class of NPT
lndirectPropertyScaleReal
Individual Property Value Units of Measure
abc
URI for the class Connection
Size
0.75 Inches
Some Questions
Fig. C.22 Templates containing operating pressure, thread form of connection, and size of connection.
Q1. Couldn’t ACME just use a spreadsheet?
A1. For this simplistic example, well, yes. ACME could send a spreadsheet of all instrument tag
numbers, end connections, size, and thread form. An EMCA engineer would pull out the values
that were needed for fabrication and reform them to feed into EMCA’s systems.
Q2. So why use templates?
A2a. Computers can do this type of work much more quickly and reliably, once we teach them
how. This lets humans do more interesting things.
A2b. This is a really simple example. The relationships can get quite a bit more complicated.
Q3. How do you know which templates to use?
A3. Funny you should ask. In Chapter 4, we mentioned the Practical Guide for ISO 15926 Modeling,
If you want to learn more about using templates, this should be the next book you read.
If you think information modeling using Part 7 templates is interesting, we can tell you that
there is going to be a demand for experts who understand the things their industry segment
deals with—and who also have an aptitude for abstract reasoning. If this describes you, give
someone a call. We’ve got a very interesting career lined up for you!
APPENDIX C
157

Using the RDS/WIP
The RDS/WIP was commissioned in the mid 2000s as a proof-of-concept for an RDS. The
classes that make up Part 4, the dictionary of ISO 15926, were used as seed material. Since its
inception, many definitions have been added to the RDS/WIP. The RDS/WIP is several things.
• A library of reference data for ISO 15926
• A means of publishing core ISO 15926 definitions
• A platform for developing new ISO 15926 definitions
• A workspace for harmonizing other standards with ISO 15926 (or ISO standards with one
another)
The RDS/WIP is a large triple store in the form subject-predicate-object. It uses semantic web
technology (OWL, RDF, and SPARQL)—transported with the conventional web technology
HTTP—to provide machine-oriented access to the stored definitions. A conventional HTML
presentation is used to provide a human-oriented interface to the same system. Anyone can
search the RDS/WIP and find terms, much like in a dictionary. Accredited users can add information
to the RDS/WIP.
We need to point out here that Part 4 intends that RDLs be federated. Therefore, it is in the
best interest of the industry to ensure that each authority be responsible for its own RDL to
ensure that the distributed nature of the Internet can be used. Although the RDS/WIP is the
largest repository to date, this should be seen as only the first—and it is everyone’s challenge,
especially equipment vendors, to ensure they have their own information on their own approved
RDL.
Web Address for RDS/WIP
• rdl.rdlfacade.org.
When you navigate to this site with a web browser, it defaults to a search screen you can use
to examine the taxonomy of RDS/WIP terminology.
RDL Facade Rules
Table C.4 outlines RDL facade rules.
TABLE C.4
RDL FACADE RULES
Rule Purpose
Not case sensitive Search strings are not case sensitive
search-string Returns all terms containing the full search string
^search_string Returns terms beginning with the search string
^search-string$ Returns a single exact match
APPENDIX C
158

Examples
In the search box, search for the items indicated in Table C.5.
TABLE C.5
SEARCH BOX ITEMS
Item Purpose
Temperature
TEMPERATURE
^temperature
RDS/WIP will return all terms containing the word temperature,
in groups of 20.
RDS/WIP should return the same results because it is not case
sensitive.
RDS/WIP will return all terms beginning with the word temperature.
^temperature$ RDS/WIP should return only one term, TEMPERATURE.
After the previous search, select the term TEMPERATURE. Figure C.23 shows what you should
see. Table C.6 explains the terminology.
TABLE C.6
RDS/WIP TERMINOLOGY
Item Purpose
RDS/WIP URI
Label
Fig. C.23 RDS/WIP entry for temperature.
The URI for the term TEMPERATURE. If you enter this text string
into your web browser, you will be taken to this page.
The official designator for this term. Within the database, this designator
is unique.
Description This helps you know whether or not you have the correct term.
Entity Type
Think of this as the general category to which TEMPERATURE belongs.
We have just scratched the surface of how to use the RDS/WIP effectively. In Appendix D, in
the section about iRING, we have included a link to a document Discovering the Right Class
for ISO 15926. We will leave further discussion for another book.
APPENDIX C
159

APPENDIX D:
OTHER RESOURCES
Information Modeling Resources
The barriers to digital interoperability are no longer hardware and technology, but rather
information modeling. To truly develop ubiquitous digital interoperability, we will need robust
information models that describe project objects and the relationships between them—from
their inception, through operation, to demobilization. This provides a distinct growth opportunity
for engineers who understand that information about plant objects is as valuable as the
objects themselves. When we have a large knowledge base, classified accurately, we will be
able to exchange worthwhile information without human involvement in each transfer.
Information modeling is the core of ISO 15926. Most people will not have to know anything
about it, but a lucky few will get to go all the way down the rabbit hole. If you would like to
become one of the lucky few, the sections following describe publications that will get you
started.
The Archives of Dr. Matthew West
Dr. West has a long history with Shell’s Information Management department, and was a developer
of parts of ISO 15926 before he retired. He has posted many of his publications on his
web site:
http://www.matthew-west.org.uk/publications.html
There is a wealth of information here for those introducing themselves to information modeling.
Dr. West was part of the development of several of the STEP parts, and later ISO 15926. If
you start near the bottom, you will see the progression from one to the other. If you are new
to information modeling, we suggest you start partway down—with some introductions on
how to add the dimension of time to a representation of product parts.
• The “IIDEAS” Architecture And Integration Methodology For Integrating Enterprises (2001)
• Replaceable Parts: A Four Dimensional Analysis (2003)
• Common Reference Data: The Foundation of e-Business (2003)
• An Introduction to 4 Dimensionalism in Data Modeling (2007)
• 4 Dimensional Data Modeling: An Ontological Approach (2008)
If you would like to listen to a lecture of Dr. West about ISO 15926, he has made available a
podcast and lecture notes of a presentation given on Ontolog—a community devoted to advancing
the field of ontology. The lecture is titled An Introduction to ISO 15926 with Podcast
(40 Mbyte) and is available from ONTOLOG (2006).
Hans Teijgeler’s Modeling Site
APPENDIX D
160

Hans Teijgeler has been influential in developing some of the parts of ISO 15926. In his retirement,
he has developed a web site that explains the way data modeling is done with ISO
15926.
http://www.15926.info/index.htm
Hans uses a diagramming technique that you will see if you start working directly with Part 2,
instead of Part 7.
IOHN Modeling Guide
We described the Integrated Operations in the High North (IOHN) project in Chapter 4. It is a
unique collaboration between the IT, defense, and oil and gas industries. It is a proponent of
ISO 15926 because ISO 15926 will enable more efficient and safer operation of remote sites.
For their members, they have developed a training course on ISO 15926 and an introduction
to information modeling—which they have recently released to the public.
https://www.posccaesar.org/wiki/ISO15926Primer_OtherResources
On this page, you will see the following three attachments.
• IHON Modeling Guide – Part 1
• IHON Modeling Guide – Part 2
• IHON Modeling Guide – Lecture Notes
Origin of ISO 15926
David Leal, of CAESAR Systems Limited, is one of the developers of parts of STEP and ISO
15926. In 2005, he published a paper ISO 15926 “Life Cycle Data for Process Plant”: An Overview.
In it he explains why ISO 15926 was developed. He describes what he calls the “4D approach”
to representing change in a way that can be represented with RDF/OWL. It has been
made available free of charge. Search for the paper by its title, or go to this site:
http://ogst.ifpenergiesnouvelles.fr/index.php?option=com_article&access=standard&Itemid=12
9&url=/articles/ogst/pdf/2005/04/leal_vol60n4.pdf
Organizations Responsible for ISO 15926
We have described these organizations in Chapter 2.
ISO TC184/SC4
http://www.tc184-sc4.org/
ISO Technical Committee 184 Subcommittee 4 – Industrial Data
APPENDIX D
161

POSC Caesar Association
https://www.posccaesar.org
POSC Caesar Association (PCA) is a nonprofit global-standardization member organization
that promotes the development of open specifications to be used as standards for enabling
the interoperability of data and software and related matters.
Fiatech
http://fiatech.org/
Fiatech is an industry consortium that provides global leadership in identifying and accelerating
the development, demonstration, and deployment of fully integrated and automated technologies
to deliver the highest business value throughout the life cycle of all types of capital
projects.
USPI-NL
http://www.uspi.nl/
USPI-NL is a formal association of process industry companies with the mission to develop,
maintain, and promote the use of international standards and best practices for product and
plant life cycle information.
User Groups
iRINGUserGroup
http://iringug.org
iRINGUserGroup is an open online community of users, companies, and organizations who
use, are considering using, or are developing or deploying iRING protocols. The iRINGUser-
Group is also responsible for the management, enhancement, and maintenance of iRINGTools
and iRINGSandbox. We have described iRING in Chapter 4. On their home page are links to
iRINGTools and iRINGSandbox.
Discovering a Class in ISO 15926
This gives advice on choosing the correct class during searches in a reference data service
(RDS) browser.
http://iringug.org/wiki/index.php?title=Discovering_a_Class_in_ISO_15926
APPENDIX D
162

Other Organizations
MIMOSA
http://www.mimosa.org/
MIMOSA is a not-for-profit trade association dedicated to developing and encouraging the
adoption of open information standards for operations and maintenance in manufacturing,
fleet, and facility environments. MIMOSA’s open standards enable collaborative asset life-cycle
management in both commercial and military applications. We have described MIMOSA and
their two joint special interest groups with Fiatech and PCA in Chapter 4.
European Committee for Standardization
http://www.cen.eu/cen/AboutUs
The European Committee for Standardization (CEN) is a business facilitator in Europe, removing
trade barriers for European industry and consumers. Its mission is to foster the European
economy in global trading and the welfare of European citizens and the environment. Through
its services it provides a platform for the development of European standards and other technical
specifications. The members of CEN work together to develop standards for European
business. In the fall of 2010, they conducted the ORCHID workshop—discussed in material
following.
Orchestration of Industrial Data
http://www.cen.eu/CEN/sectors/sectors/isss/workshops/Pages/workshoporchid.aspx
The ORCHID (Orchestration of Industrial Data) group is a network of European companies
and consortia dedicated to standardizing information across the process industry engineering
supply chain to build competitive advantage. Its goal is to progress the industry toward
interoperability. In Chapter 5, we presented an approach to implementing ISO 15926 that even
small organizations can follow. It could be, however, that your organization is ready for a more
comprehensive rollout. If so, you will find the proceedings of the ORCHID workshop interesting.
The purpose of this workshop was to create an interoperability roadmap for organizations—starting,
most importantly, with a self-assessment and an assessment of one’s business
partners. The web page cited previously contains six attachments that can be downloaded.
• Part 1: Direction and Framework
• Part 2: Implementation Guide
• Part 3: Standards Landscape
• The CEN ORCHID Roadmap: Implementation Guide
• The CEN ORCHID Roadmap: Direction and Framework
• ORCHID: Orchestrating Industrial Data, Workshop Overview
APPENDIX D
163

RDS Browsers
The classes that make up Part 4, the dictionary of ISO 15926, are stored in what is called the
RDS/WIP (Reference Data System/Work in Progress). To search the classes you need to use
an RDS/WIP browser. For more information about RDS/WIP:
http://rdswip.ids-adi.org/presentation/overview/index.html
There are a number of browsers for the RDS/WIP. These are described in the sections that follow.
rdlfacade
The RDS/WIP Search, otherwise known as the RDL Facade, was created during the early development
of ISO 15926.
http://rdl.rdlfacade.org
POSC Caesar Part 4 Browser
POSC Caesar has its own library of reference data (at the following address), presented in the
form of spreadsheets.
http://rds.posccaesar.org/2008/05/XML/ISO-15926-4_2007/
POSC Caesar RDL Explorer
http://193.212.132.108/apps/rdsclient.html
Log in as “guest.”
Instructions on using the POSC browser can be found at the following address.
http://15926.org/home/tiki-index.php?page=Tutorial+ISO+15926+part+4
DNV Reference Data Browser
Det Norske Veritas (DNV) is one of the three largest insurers in the world, along with Lloyd’s
Register and the American Bureau of Shipping. It became interested in ISO 15926 as a result
of assessing risk in shipping. A common way to describe physical facilities makes it easier to
compare the facilities to common benchmarks. DNV has participated in some of the development
work of ISO 15926 and has created its own RDS browser.
http://projects.dnv.com/reference_data/RD7Browser/browser.aspx?id=part4:RDS415124
Business Interface Definition Guides
One of the major motivations of organizations to sponsor the work that has led to ISO 15926,
and the motivations of individuals to participate, is the efficient handover of information from
engineering procurement and construction (EPC) contractors and constructors to owneroperators.
After a facility has been built and commissioned, document and information hando-
APPENDIX D
164

ver must often operate on what is left of the project budget after the original engineering and
construction staff have moved on to their next project. It is sometimes difficult for the owner
to get all of the information it needs, and in a form that is immediately useful.
One barrier to adequate information handover in the capital projects industry is getting all parties
to agree at the beginning of a project what needs to be handed over. So that every project
does not have to develop its handover requirements from scratch, a number of handover
guides have been created—and more are contemplated. We have come to refer to the discussion
of information handover guides as the The Business Interfaces Definition Guide (BIDG).
The handover guides developed to date all discuss the importance of good data handover and
offer ways of ensuring that this will actually happen on a given project. One of them, published
by EPISTLE, explicitly lists deliverables by name and is organized by engineering discipline.
One barrier to getting more specific is a common definition of terms. When the JORD
project is complete, many of the participants in the development of these handover guides
anticipate a harmonization with Part 4.
EPISTLE Handover Guides
In the late 1990s at EPISTLE, the first Process Industries Data Handover Guide was published
to help project participants define the scope of information turnover. The guide is issued in
two parts. Part 1 concentrates on methodology, starting with understanding the business need
for information, creating a plan to supply the information, and implementation. Part 2 focuses
on recommendations for actual data items ranging from contract management documents,
scheduling, materials, construction, and process to information on all of the components that
make up the facility.
As its basis, the EPISTLE handover guide used the PISTEP Process Plant Engineering Activity
Model (see Chapter 2). This activity model was essentially a very detailed flowchart of
the main activities and information exchanges encountered over the life of a typical process
plant. EPISTLE used the activity model to make sure its guide captured the most important
exchanges. If you are ever involved in planning the information handover for a capital project,
EPISTLE’s guides are still worth reading—along with the NIST and EPRI guides.
https://www.posccaesar.org/wiki/IdsAdiBIDG
You will have to request a login from PCA to obtain access. Access is open to all members of
PCA. Non-members can request access. Go to their membership page and follow the instructions
at the bottom.
NIST/Fiatech Handover Guides
The NIST handover guide is issued in a number of parts, modeled after the EPISTLE handover
guides. The Capital Facilities Information Handover Guide Part 1 was issued by NIST and Fiatech
in 2006. Several second parts are envisioned, each to focus on the deliverables of a specific
industry. The General Buildings Information Handover Guide was issued in 2007. Its focus
is the general buildings industry, including commercial, industrial, and government buildings.
This guide reviews the issues in designing and constructing an environment of short schedules
and constant change. Several case studies are included, showing the successes and lessons
learned for early adopters of building information modeling (BIM).
APPENDIX D
165

• Capital Facilities Information Handover Guide, Part 1
• http://fire.nist.gov/bfrlpubs/build05/PDF/b05037.pdf
• General Buildings Information Handover Guide
• http://fire.nist.gov/bfrlpubs/build07/PDF/b07015.pdf
Electric Power Research Institute Handover Guide
http://my.epri.com/
The Advanced Nuclear Technology: New Nuclear Power Plant Information Handover Guide
was issued by the Electric Power Research Institute (EPRI) in 2009. It reviews the information
handover requirements in the very heavily regulated nuclear industry. It starts by noting that
new projects will almost certainly be developed with advanced computer systems capable of
3D modeling, construction sequencing, and detailed cost control. Handover will increasingly
be electronic rather than paper based.
If the power authorities operating the plant pay attention to data requirements early, the data
handover can directly feed their own operations and maintenance systems. The document
ends with a brief overview of emerging information handover standards, in which ISO 15926 is
included. Future appendices will include detailed templates for an information handover plan.
The report can be downloaded at no charge. The best way to find the report is to go to EPRI’s
home page and search for “handover guide.” which will take you to a page where you should
find the report listed.
APPENDIX D
166

GLOSSARY OF CONCEPTS
There are already enough glossaries of computer science terms available on the Internet that
we do not need another comprehensive listing. The purpose of this glossary is to use the
language of beginners to expand on some of the concepts useful in understanding ISO 15926.
We should warn you that we have used some artistic license here. We do not recommend you
use any of these definitions on an important exam!
Artificial Intelligence and the Semantic Web: Difference Between
Artificial intelligence: “Making machines smarter”
Semantic Web: “Making data smarter”
We all want to be able to find and use information on the World Wide Web easier and more
reliably. The artificial intelligence approach is to make machines smarter by teaching them
to infer the meaning of web data by using techniques such as natural language and image
processing. In contrast, the Semantic Web approach is to make the data itself smarter (that is,
by making the data easier for machines to find, access, and process) by using techniques for
expressing data and meaning in a standard machine-readable format. ISO 15926 Parts 8 and 9
use Semantic Web technology to describe plant objects in a way that computers can understand.
First-order Logic, Semantics, and Reference Data
First-order logic:
If you have ever taken a mathematics course where you have had to prove something you
have used first-order logic.
Joke:
A farmer, an engineer, and a philosopher decided to take a bus tour of Scotland
for a vacation. After they arrived in Glasgow they transferred to a bus and drove
out of town. On the first farm they passed, they saw a black sheep standing in a
field.
“Look!” said the farmer, “Scottish sheep are black!”
“You can’t draw that conclusion after only seeing one sheep,” said the engineer.
“All you know for sure is that at least one sheep in Scotland is black!”
“You’re both wrong,” said the philosopher. “All you know for sure is that at least
one sheep in Scotland is black on at least one side!”
The philosopher knows first-order logic. This joke makes first-order logic seem pedantic. But
what if, after the three went back home, they were offered an investment that depended on
GLOSSARY
167

there being a ready supply of black wool? Wouldn’t it be nice, then, if they knew whether or
not the farm they saw was a typical Scottish farm, a farm owned by a collector of unusual
specimens of ordinary farm animals, or an experimental farm that tinkered with the DNA of
sheep?
First-order logic is a means of including all of one’s presuppositions into one’s assertions in
order to tell if something is true or not. “Presupposition” as regards ISO 15926 is equivalent to
“context,” a concept we have become very familiar with. First-order logic is used in ISO 15926
as a basis for developing the classes (which make up Part 2); the reference data library (RDL),
which makes up Part 4; and the templates, which make up Part 7.
Semantics:
If you have ever read Alice’s conversation with Humpty Dumpty, 1 you have had a lesson in
semantics. An excerpt:
Humpty Dumpty: “...How old did you say you were?”
Alice made a short calculation, and said, “Seven years and six months.”
“Wrong!” Humpty Dumpty exclaimed triumphantly. “You never said a word like
it!”
“I thought you meant ‘How old are you?’” Alice explained.
“If I’d meant that, I’d have said it,” said Humpty Dumpty.
Semantics has to do with meaning. Sometimes the word is used derisively, as in “Yes, but
that’s only semantics!” But in ISO 15926 semantics is everything. Elsewhere in these pages
we have talked about embedding context with the data. What we mean by this is capturing
the semantics. Semantic means that a precise meaning, neither more nor less, can be had.
For instance, in a field of engineering there might be many versions of the word temperature.
A user of any of the versions must be able to use each version reliably to convey the correct
meaning. Semantic fidelity is the degree to which the original meaning of a term survives an
information exchange. We are looking for high semantic fidelity to make sure the meaning of
data values is preserved on the receiving end.
Reference data:
We return to Alice’s conversation with Humpty Dumpty, in which Humpty is trying to convince
Alice that it is better to have un-birthdays than birthdays on the basis that there are 364 days
when you might get un-birthday presents. Humpty continues:
“… only one for birthday presents, you know. There’s glory for you!”
“I don’t know what you mean by ‘glory.’ Alice said.
Humpty Dumpty smiled contemptuously. “Of course you don’t—till I tell you. I
1. Through the Looking Glass, by Lewis Carroll.
GLOSSARY
168

meant, ‘there’s a nice knock-down argument for you!’”
“But ‘glory’ doesn’t mean ‘a nice knock-down argument’,” Alice objected.
“When I use a word,” Humpty Dumpty said, in rather a scornful tone, “it means
just what I choose it to mean—neither more nor less.”
“The question is,” said Alice, “whether you can make words mean so many different
things.”
“The question is,” said Humpty Dumpty, “which is to be master—that’s all.”
If the definitions of terms were decided by individuals at the time they used the terms, we
would never be able to communicate effectively. But with a common set of definitions, that
any of us can consult, we can communicate without ambiguity. The ISO 15926 RDL is the common
set of definitions (reference data) we can all use.
Ontology and Taxonomy: Difference Between
Ontology:
If you have ever played the parlor game Twenty Questions, you intuitively understand what
ontology means. In this game, you more or less start with an “ontology of everything in the
world” and with each successive question (“Is it a ...?”) apply a more limited ontology as a
filter (usually starting with “Is it animal, vegetable, or mineral?”) The game ends when there is
only one object left, the answer, that satisfies membership (or nonmembership in the case the
answer to “Is it a ...?” is “No!”) in all ontologies.
Taxonomy:
If you have ever made a classified list of all your CDs, you have made a taxonomy. (But if
you are as old as the author, CDs are old hat. You learned how to do this years ago with your
player piano rolls!”) And if you have ever had to grapple with the question of where to classify
Weird Al (under “Parody”, “Rock and Roll,” or “Idiot!”), you have come up against the idea
of single or multiple inheritance. Ontology and taxonomy are both terms in a continuum that
information scientists call knowledge organization systems (KOS).
And just to confuse you some more, the continuum includes thesaurus, controlled vocabulary,
and faceted classification—among many others. The bad news for those of you not used
to dealing with ambiguity (all you mechanical engineers out there: raise your hands!) is that
there is a great deal of overlap in those terms. Even people whose job it is to know these
things (all you mechanical engineers out there: put your hands down!) cannot give a short
answer when asked where the boundaries are.
A taxonomy is a collection of terms that have explicit definitions that have been organized
into a hierarchical structure. They tend to be organized in tree-like structures that are reasonably
easy to understand, even by non-specialized people. Each term is related to its parent in
an “is a type of” relationship.
For instance, a car is a type of automobile. But a car also a type of machine, so if your taxonomy
is concerned with machines you should analyze the relative order of these three things.
GLOSSARY
169

Depending on the purpose of your taxonomy, you might end up with something like this:
“Car” is a type of automobile, which is a type of machine.
In the realm of philosophy, ontology is the study of being; the study of the things that are. In
the realm of information science (which is where ISO 15926 firmly resides), ontology has a
more formal meaning. The Wikipedia definition says that an ontology is “a formal representation
of a set of concepts within a domain and the relationships between those concepts.”
(Hmm…This is one of those definitions that does not start to make sense until you already
know what it means. Let’s try something else.)
Like taxonomies, ontologies are also arranged in an “is a type of” relationship, but the relationships
tend to be more richly defined. The difference is subtle. One commentator compared
the difference between ontology and taxonomy to your computer hard disk. The taxonomy
would be the directory structure without the files, whereas the ontology would be the files
organized by the directory structure.
In Chapter 2, we talked about an ontology of things that will carry a bicycle. That ontology
was the entire collection of things that can carry a bicycle that the author held in his head in
case his bicycle were to break down on the way to work. Each object in the ontology would
have a taxonomy you could examine.
Generalization and specialization:
The “is a type of” relationship is known as generalization/specialization. In the previous example,
“car” is a specialization of “automobile”; “automobile” is the generalization of “car.”
Subtype and supertype:
Subtype/supertype is just another way of saying generalization/specialization. Continuing the
previous example, “car” is a subtype of “automobile”; “automobile” is a supertype of “car.” The
understanding is that the subtype has all the constraints of the supertype, plus one or more
additional constraints.
Integration and Interoperability: Difference Between
Interoperability:
An early example of digital interoperability, probably even before the phrase was coined,
is the centerpiece of the 1970 movie Colossus: The Forbin Project. It was released near the
height of the Cold War, in an era when people were starting to hear about these newfangled
computer-thingies and to wonder how they would affect us. In the movie, “the” (one and only)
supercomputer in the United States, Colossus, tunnels under the Atlantic Ocean using something
like what we call the Internet today and finds “the” (one and only) supercomputer in the
Soviet Union, Guardian.
Recognizing themselves as kindred spirits, Colossus and Guardian naturally start talking to
each other and by the end of the movie have taken over the world and enslaved humanity.
Now that’s interoperability! Basically, this is what ISO 15926 intends to achieve (minus, of
course, the taking-over-the-world-and-enslaving-humanity part.)
Integration:
GLOSSARY
170

If you are a Start Trek fan and have watched one of the episodes where the crew of the Enterprise
encounters the Borg, you have seen one definition of integration: basically, a bunch of
individual things becoming part of a whole (other) thing with all parts working together seamlessly.
Comparing Interoperability and Integration
Colossus is probably classified in the apocalyptic science fiction genre, but if you are involved
in any way in moving information from one computer system to another, parts of it will be
high comedy. The movie portrays supercomputers as being naturally aware of each other, sort
of like two dogs being walked in the same park.
Then the movie suggests that supercomputers somehow have the innate ability to communicate.
The truth is, unless a pair of computers had been specifically programmed to do so they
would not even know of each other’s existence—let alone be able to communicate, even if you
were to put them both in the same room and name one Laverne and the other Shirley.
For most people, the line between interoperability and integration is fuzzy, and in truth there
is overlap. In the field of information exchange, both imply that information can flow between
two computer programs more or less seamlessly—without anyone having to rekey any of it. It
is not until we start digging into the various methods of achieving this seamless information
exchange that we can zero in on the differences. Interoperability implies that the two computer
programs are their own agents, but somehow know how to speak the same language.
Integration implies that the computer programs achieve the information exchange by having
hooks into each other.
In the context of ISO 15926, interoperability means that two or more computer applications
are able to exchange information because they all, independently of each other, use a common
standard for exchanging information. There is no requirement that any of them know
about any of the others beforehand. It is like buying a Bluetooth headset for your cellular
phone and then being pleasantly surprised that after replacing your phone the headset works
with the new one too.
In the context of ISO 15926, integration means that two computer applications are able to
exchange information because the developers of each did some custom work to make them
able to do so. The end result of this “working together” may in fact be identical, better than,
or worse than the “working together” in our definition of interoperability.
Strong Coupling, Loose Coupling, and Encapsulation
Interoperability with ISO 15926 is achieved by what is called loose coupling, whereas integration
implies strong coupling. In the field of computer science, strong coupling means that a
function in one application is directly controlled by a function in another application. Loose
coupling means that when two programs communicate but the components of one system do
not directly make use of knowledge of the other system.
For example, suppose that your neighbor occasionally needs a light shining on a particular
place in his backyard that is hard to illuminate from anywhere in his own yard. Further suppose
that because there is a particularly good vantage point in your yard you agree to mount
a light for him and turn it on whenever he wants.
GLOSSARY
171

Strong coupling:
You install the light and let your neighbor run a line from his house to your breaker panel so
that he can control the light directly from his own house.
Loose coupling:
You install the light, but tell the neighbor to phone you and you will turn it on for him—perhaps
giving him a performance guarantee of 30 seconds.
Encapsulation:
The example of loose coupling—asking your neighbor to call you when he wants the light
turned on—is also an example of encapsulation. In computer science, one definition of encapsulation
is a mechanism in an object-oriented programming language that restricts access to
some of an object’s components.
This means that when you encapsulate something you reveal only the attributes you want for
a particular effect, not the entire object. This allows you the freedom to modify the unrevealed
attributes without creating a catastrophic change that might affect the original information
exchange. Encapsulation is hiding complexity in situations where users really do not need to
know more.
In the example of a yard light for your neighbor, all that your neighbor needs to know is that
when he calls you and says “please” the light comes on within 30 seconds. He does not need
to know how it happens. This gives you a great deal of flexibility. For instance, at the beginning
you might guess that he will not call you very often so you just install a bright flashlight,
change the batteries as required, and go out and turn it on manually whenever he calls.
Later, if he asks for the light often enough it will be much more convenient for you to install
a permanent spotlight with a line to a switch at your back porch. Later yet, you may get a
job where you have to travel a lot (perhaps you write a book for Fiatech and get invited on
a lucrative speaking tour!). You install a special computer-controlled switch and give it an IP
address you can control from your smart phone. Then when you are away you just call up the
switch from wherever you are in the world and turn it on.
Note that none of your internal changes has any impact on the performance of the light.
When you decide to install a permanent light, you leave the flashlight in place until the new
one is in place. Unless your neighbor happens to look out his window at the right time, he
will not even know that you are running a power line and changing the light. Later, when you
install the computer-controlled switch you can do it during the daytime so as not to risk being
in the middle of the changeover when he calls.
Abstraction
Abstraction is a process of generalizing about something to reduce the information content
about an object to only those attributes you are interested in. If you wanted to get a visceral
reaction from the class of North American males who, like your humble author, were pubescent
boys in the early 1960s, show them a glossy photograph of a 1963 Corvette Stingray with
the top down. (To clinch the effect, add a blonde surfer babe in the passenger seat with her
hair streaming back in the wind!).
GLOSSARY
172

In this example, you reduce the Corvette Stingray to ink on paper. The printer sees the ink, but
the now-geriatric boys see the actual car they remember from their youth—which at the time
was the epitome of style and performance. Of course you could get an actual car (and an actual
surfer babe)—but that would cost a lot of money and would run the risk that the geezers
would run off with the car and get themselves killed. The photograph will get the gut reaction
you are after, and the worst they can do is steal the picture!
Semantic Web Technology
The large majority of ISO 15926 users will not need to know anything more about the Semantic
Web. But if you are curious on how things like ISO 15926 work you may find it interesting
to learn a little bit more. The Semantic Web provides a common framework that allows data to
be shared and reused across application, enterprise, and community boundaries. It is a collaborative
effort led by W3C, with participation from a large number of researchers and industrial
partners. It is based on the Resource Description Framework (RDF).
Resource Description Framework
If you dig deeper under the hood of ISO 15926, you will soon run into this term because it is
the used by OWL (the basis of Part 8). Wikipedia says that the RDF is a set of specifications
originally designed as a metadata data model. But if you are like the author, this does not help
at all—so we will deconstruct the definition.
Metadata:
Metadata is data about data. For instance, one piece of metadata about the Introduction to
ISO 15926 is that it was originally written with a wiki on the POSC/Caesar web site. Another
piece of metadata is that the original name was ISO 15926 Primer.
Data model:
A data model is an abstract model that describes how data is represented and accessed. Putting
it all together, then, RDF is: Instructions on how to represent just the bits of data you are
interested in that describe certain other bits of data and on how to then access the data easily.
Whew! I bet you thought that was going to be difficult! In particular, RDF makes statements
about things (which it calls resources) in the form of subject-predicate-object expressions
known as triples.
Subject-predicate-object triple:
“The ISO 15926 Primer was written on the POSC/Caesar wiki” might be stored in the RDF as
the following triple.
• Subject: ISO 15926 Primer
• Predicate: was written on
• Object: POSC/Caesar wiki
Each term in the subject-predicate-object triple may be explicitly named, as in the previous
example, or handled in the form of a uniform resource identifier (URI).
GLOSSARY
173

Uniform Resource Identifier
You can think of a URI as a web address for a piece of information. This allows the same
resource to be reliably referenced many times. Thus, instead of writing the subject-predicateobject
triple in words (as previously) it could be rendered as follows.
• Subject: https://www.posccaesar.org/wiki/ISO15926Primer
• Predicate: was written on
• Object: POSC/Caesar wiki
In fact, we could carry this further by defining somewhere on the Internet the exact meaning
of the phrase was written on and put its URI in the predicate.
URL, URN, and URI:
• URL (uniform resource locator): Like a person’s street address (i.e., “where”).
• URN (uniform resource name): Like a person’s name (i.e., “what”).
• URI (uniform resource identifier): URLs and URNs are URIs, but a URI can be a name and a
locator at the same time.
GLOSSARY
174

3925 West Braker Lane (R4500)
Austin, TX 78759-5316
t: (512) 232-9600
www.fiatech.org
Copyright ©2011 Fiatech
Construction Industry Institute®
The Cockrell School of Engineering
The University of Texas at Austin