Iso Intro Ver1

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

description

ISO

Transcript of Iso Intro Ver1

Page 1: Iso Intro Ver1

An Introduction toISO 15926

November 2011

ELEMENT 8 WORKFORCE & TRAINING

Page 2: Iso Intro Ver1

An Introduction to ISO 15926

November 2011

Page 3: Iso Intro Ver1

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, Pres-ident, 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

Page 4: Iso Intro Ver1

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, dem-onstration 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 organiza-tions 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 mate-rials; 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 break-through 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.

Page 5: Iso Intro Ver1

TABLE OF CONTENTS

INTRODUCTION 1Introduction 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 12The 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 40How 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? 70Integration 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 105Using ISO 15926 in Production 106

Development of Enabling Infrastructure 110

Continued Development of Standards 113

Page 6: Iso Intro Ver1

CHAPTER 5: GETTING STARTED WITH ISO 15926 116Key Preparation 117

Implementing ISO 15926 118

Join Fiatech or the POSC Caesar Association 123

APPENDIX A: THE PARTS OF ISO 15926 124ISO 15926 124

APPENDIX B: COMPLIANCE WITH ISO 15926 128Semantic 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 134Example 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 160Information 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 167Artificial 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

Page 7: Iso Intro Ver1

INTRODUCTION

1

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 proper-ties 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 re-view each data sheet. Critical data values will be rekeyed into an asset management sys-tem. This can take months.

Page 8: Iso Intro Ver1

INTRODUCTION

2

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 edit-able 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. How-ever, 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 da-tabase 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 trans-late 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 infor-mation automatically.

• For quotation, a procurement officer will expose the Request for Quotation on his compa-ny’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 rel-evant 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 man-ner 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.

Page 9: Iso Intro Ver1

INTRODUCTION

3

• 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 op-portunities 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 innova-tive 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 stor-age 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 smith-ereens 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

Page 10: Iso Intro Ver1

INTRODUCTION

4

absorbs the unconscious mental frequencies from this energy, more or less, as food. Its excrement is a so-called telepathic matrix of conscious thought fre-quencies 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 stan-dard 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 ex-change 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

Page 11: Iso Intro Ver1

INTRODUCTION

5

that a large proportion of plant information will actually be stored in an ISO 15926-compli-ant 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 dy-namically 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 stan-dards 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.

Page 12: Iso Intro Ver1

INTRODUCTION

6

Hello

Hello

Use amental

dictionaryto translateEnglish toMandarin

Use a mental dictionary totranslate Cantonese to

English

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 hid-den 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 meta-phor, 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.

Page 13: Iso Intro Ver1

INTRODUCTION

7

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 ex-isting 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 intro-duction 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 us-ers 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 en-counter 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

Page 14: Iso Intro Ver1

INTRODUCTION

8

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 docu-ment. 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 con-tained 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 accom-plished. This adds friction, making many exchanges uneconomic. When ISO 15926 is mature, the mechanics of information exchange will fade into the background—allowing more ex-changes 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 evolu-tion 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 prin-ciples 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 in-formation 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 some-what 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

Page 15: Iso Intro Ver1

INTRODUCTION

9

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; fabrica-tors 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, essen-tially 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 commu-nicate 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 off-shore facilities. Integrated Operations in the High North (IOHN) is a multi-year initiative to imple-ment 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 infor-mation 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.

Page 16: Iso Intro Ver1

INTRODUCTION

10

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 partici-pants 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 specifica-tion 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 Fiat-ech 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 well-known 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 tradi-tional methods of exporting information from one application and importing it into another.

Page 17: Iso Intro Ver1

INTRODUCTION

11

Open-source and commercial tools exist to assist in both dictionary mapping at the introduc-tory 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

Page 18: Iso Intro Ver1

CHAPTER 1

12

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 Inade-quate 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 sys-tems 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 contain-ing 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 dictionary2 that you can use free of charge. Because the ISO 15926 diction-ary 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 mean-ings 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.

Page 19: Iso Intro Ver1

CHAPTER 1

13

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 net-work. 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 information3. 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.

Page 20: Iso Intro Ver1

CHAPTER 1

14

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.

Page 21: Iso Intro Ver1

CHAPTER 1

15

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 manufac-turer’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 pre-cise 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 ex-perience. For an example of how we rely on context, suppose that you have to transfer infor-mation 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.

Page 22: Iso Intro Ver1

CHAPTER 1

16

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 trans-fer information to other machines, we want the information to be self-describing.

Page 23: Iso Intro Ver1

CHAPTER 1

17

The Data Sheet Problem

Consider a more realistic example of selecting and specifying a centrifugal pump. After select-ing 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.

CONDITIONS OF SERVICE, EACH PUMP Normal Flow Rated Flow Disch. Press. kPag Temperature C Specific Gravity Vapor Pressure kPag Viscosity Corr./Erosion Caused By

Suct. Press. Max. kPag Rated kPag Differential Pressure kPag Differential Head m NPSH Available m Corrosion Allowence mm

Cold Start Temp. C @Sp. Gr. & Viscosity CONSTRUCTION Nozzles Suction Discharge

Size Rating Facings Location

Rated Max. Normal Min.

@ Minimum S. G.

OPERATING CONDITIONS

Capacity (gpm) Suction (psig) Discharge (psig) Diff. Press. (psig) Diff. Head (ft) Power (hp)

Rated Max. Normal Min. Op. Time (hr/yr) NPSH Avail. (ft) System Design Stand Alone Parallel Operation Series Operation with Service Pressure Min/Max (psig) . Service Continuous Starts per Day System Control Method Speed Flow Level Temp. Pressure Pipe Friction Resistance Only

Different Name

Different Definition

Different Definition

Different NameSame Definition

Different Definition

Same DefinitionSame Definition

Convert to Metric

Convert to Imperial

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

Page 24: Iso Intro Ver1

CHAPTER 1

18

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 infor-mation 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 ig-nored, 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 at-tributes. 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 attri-butes 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 ex-amining the terms in each database to determine which are equivalent. Directly mapping two applications together is often the easiest short-term solution.

Page 25: Iso Intro Ver1

CHAPTER 1

19

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 engi-neer’s design software into your construction software automatically. After all, the design engi-neer 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 comput-ers 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.

tag_no dia len temp press ifc

Engineering ApplicationLine Table

tag_no dia len temp press ifc

Construction ApplicationLine Table

Fig 1.5 A perfect world.

4. Port 2000 Newsletter: The Information Technology Newsletter for Port Washington Educators,

December 1996.

Page 26: Iso Intro Ver1

CHAPTER 1

20

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 construc-tion application. But what about the column cl in the construction application? For that mat-ter, 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?

tag_no dia len temp press ifc

Engineering ApplicationLine Table

id dia cl temp press ifc

Construction ApplicationLine Table

??

??

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. For-tunately, 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.

Page 27: Iso Intro Ver1

CHAPTER 1

21

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 sev-eral 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 devel-opment 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

tag_no dia len temp press ifc

Engineering ApplicationLine Table

id dia cl temp press ifc

Construction ApplicationLine Table

tag_no dia len temp press ifcid dia cl temp press ifc

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 of-ten 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 rep-resenting 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.)

Page 28: Iso Intro Ver1

CHAPTER 1

22

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 WBSService Class

Nom DiaFluid 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 data-base 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 report-writing 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 ap-plication. 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 an-other one. Figure 1.8 shows how the engineering application might be mapped to a procure-ment application with a second custom database map.

tag dia len code price ifc

Procurement ApplicationLine Table

Custom Maptag_no dia len temp press ifc

tag dia cl ifc

Custom Map

tag_no dia len temp press ifc

Engineering ApplicationLine Table

id dia cl temp press ifc

Construction ApplicationLine Table

tag_no dia len temp press ifcid dia cl temp press ifc

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

Page 29: Iso Intro Ver1

CHAPTER 1

23

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 ap-plication, massage it a bit, perhaps do a unit conversion or two, and then import it into anoth-er 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 hard-ware 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

Page 30: Iso Intro Ver1

CHAPTER 1

24

benefit is stability of information exchanges. Personnel can get on with whatever their busi-ness 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 ef-ficient 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 informa-tion.

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 point-to-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.

Page 31: Iso Intro Ver1

CHAPTER 1

25

Map to Common Dictionary

tag_no dia len temp press ifc

Engineering ApplicationLine Table

id dia cl temp press ifc

Construction ApplicationLine Table

tag_no dia len temp press ifcszTag dDia dLen dTemp dPress dateIFC

szTag dDia dLen dTemp dPress dateIFCid dia cl temp press ifc

Map from Common Dictionary

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 deter-mines 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

Page 32: Iso Intro Ver1

CHAPTER 1

26

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 man-ner, 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 applica-tion 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 dDiaNominal 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

Page 33: Iso Intro Ver1

CHAPTER 1

27

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 confedera-tion 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.

tag dia len code price ifc

Procurement ApplicationLine Table

szTag dDia dLen dateIFCtag dia len ifc

Map from Common Dictionary

Fig 1.11 A reuse scenario.

Again, there is a cost. As an organization grows in size and adds more members to its con-federation 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 main-taining 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 some-body 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.

Page 34: Iso Intro Ver1

CHAPTER 1

28

Map to Common Dictionary

tag_no dia len temp press ifc wcolor

Engineering ApplicationLine Table

id dia cl temp press ifc color

Construction ApplicationLine Table

tag_no dia len temp press ifc wcolorszTag dDia dLen dTemp dPress dateIFC oColor1

szTag dDia dLen dTemp dPress dateIFC oColor1id dia cl temp press ifc color

Map from Common Dictionary

IndustryReference

Data

New Definition

New Definition

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 devel-oper—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 pub-lished, 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 (per-haps 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 industrial-scale 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.

Page 35: Iso Intro Ver1

CHAPTER 1

29

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 informa-tion 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 proj-ect, is between an EPC contractor designing a capital asset and the owner. Some owners real-ize that the handover of asset information is a bottleneck to efficient startup and are increas-ingly 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 re-moved. 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 en-gineers, 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.

Page 36: Iso Intro Ver1

CHAPTER 1

30

EPC 2

V01

19

20

21

7

6

5

2

1

EPC 1

Const2

Const1

Owner

Const3

V02

V03

V04

V05

V10

V11

V20

V21

V22

V30

V31

13

29

30

36

31

3534

39

40

18

16

14

2827

26

2524

1211

10

9

8

44

4543

15

17

22 33

3723

32

41

38

42

4

3

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 prohibi-tive. 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 submit-ting 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 com-pany 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.

Page 37: Iso Intro Ver1

CHAPTER 1

31

EPC 1Const

3

F F

Fig 1.14 Everyone needs a Babel fish.

After that, the only question you have to ask of a supplier (or engineer, or construction con-tractor) 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.

V01

V02

V03

EPC 2

V04

EPC 1

V10

V11

Owner

Const3 V

31

V30

Const2

V22

V21

V20

Const1

ISO 15926

DataBroker

2

V05

DataBroker

1

Fig 1.15 The same project using ISO 15926 interfaces.

How ISO 15926 Makes Life Easier in the Near Term

ISO 15926 standardizes the representation of project information across organizational boundaries. This means that information can move faster and more reliably with fewer tran-scription errors. Organizations are able to keep their proprietary systems while exchanging in-formation with business partners in a manner their business partners can understand. Because

Page 38: Iso Intro Ver1

CHAPTER 1

32

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 infor-mation 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.

EPC 2

EPC 1

V10

V11

Owner

ISO 15926

Fig 1.16 Information exchanges during design.

Procurement

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-

Page 39: Iso Intro Ver1

CHAPTER 1

33

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 reli-able—which means that there is much less need to verify terminology.

• There is a potential for automating repetitive tasks because the meaning of equipment at-tributes is accurately conveyed with the attributes themselves.

V01

V02

V03

EPC 2

V04

EPC 1

V10

V11

ISO 15926

V05

DataBroker

1

Fig 1.17 Information exchanges during procurement.

Construction

Construction contractors are starting to use sophisticated construction planning systems that rival engineering systems in size and complexity. Currently, importing information from an engi-neering 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.

Page 40: Iso Intro Ver1

CHAPTER 1

34

EPC 2

EPC 1Const

3 V31

V30

Const2

V22

V21

V20

Const1

ISO 15926

DataBroker

2

Fig 1.18 Information exchanges during construction.

Handover

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 2

EPC 1

Owner

Const3

Const2

Const1

ISO 15926

Fig 1.19 Information exchanges during handover.

Page 41: Iso Intro Ver1

CHAPTER 1

35

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—elimi-nating 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 infor-mation.

• 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 informa-tion into a new system is much easier.

Page 42: Iso Intro Ver1

CHAPTER 1

36

V01

V02

V03

EPC 2

V04

EPC 1

V10

V11

Owner

Const3 V

31

V30

Const2

V22

V21

V20

Const1

ISO 15926

DataBroker

2

V05

DataBroker

1

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 pos-sible, but often large parts must be redone.

Page 43: Iso Intro Ver1

CHAPTER 1

37

ISO 15926

EPC 2

Specialist

Previous project informationstored as ISO 15926

Communication toSpecialist supplier usingISO 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 organi-zations 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 inte-grated 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.

Page 44: Iso Intro Ver1

CHAPTER 1

38

• 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 devel-oped from scratch.

SoftwareDeveloper

ISO 15926

Fig 1.22 Information exchanges for software development.

Integration of RFID information

RFID technology is getting less expensive over time and is showing up in new applications ev-ery 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 auto-matically 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).

Page 45: Iso Intro Ver1

CHAPTER 1

39

V03

EPC 1

Const2

ISO 15926

Owner

Fig 1.23 Integration of RFID information.

Page 46: Iso Intro Ver1

CHAPTER 2

40

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 author-ing 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 ex-change.

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.

Page 47: Iso Intro Ver1

CHAPTER 2

41

ISO 15926

Open ways to storeand exchange data

PlantInformationExchange

MarkupLanguages

How we know andunderstand things

Evolution ofproduct

informationstandards

Ontologies

How we use theinternet to find

information

The SemanticWeb

OntologyLanguages

Fig. 2.1 ISO 15926 enablers.

How We Use the Internet to Find Information

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 usu-ally 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 envi-sioned a web environment in which people could ask their personal digital assistants ques-tions 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 assis-tant 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 pro-cess 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

Page 48: Iso Intro Ver1

CHAPTER 2

42

doctor’s office individually to find out if he or she is taking new patients and if there is a suit-able 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 on-tologies, 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 ques-tions. 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 ex-changed. 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 under-standing 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 in-dulge 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. There-fore, 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.

Page 49: Iso Intro Ver1

CHAPTER 2

43

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 be-fore? 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.

Page 50: Iso Intro Ver1

CHAPTER 2

44

Felicia Fun

Ontology ofThings ThatWill Carry a

Bicycle

Pickup Truck

Pickup Truck with aCamper that is not full

of stuff

F150

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 incor-porated 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 manag-ing 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.

Page 51: Iso Intro Ver1

CHAPTER 2

45

“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 stor-age 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 look-ing 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 pro-cessor 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-

Page 52: Iso Intro Ver1

CHAPTER 2

46

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 ob-scure 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 docu-mentation 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 per-form 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

Page 53: Iso Intro Ver1

CHAPTER 2

47

markup tags freed document creators from having to deal with the appearance of the docu-ments so that they could concentrate on content.

Since the development of GML, markup languages have become widely used in enabling com-puters 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 tex-tual 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 understand-ing 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 tech-nologies 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 ontol-ogy, 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.

Page 54: Iso Intro Ver1

CHAPTER 2

48

Validated by

OWL

XML

RDF

Compares to Compares to

Validated by

XML Schema

Fig. 2.7 XML, RDF, and OWL

ISO 10303 Part 21 and EXPRESS

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 model-ing 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 publica-tion 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 mak-ing 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.

Page 55: Iso Intro Ver1

CHAPTER 2

49

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 prod-uct information—which includes information about every object in a processing plant, manu-facturing 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 draft-ing (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-pur-pose 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 com-mercial systems appearing a few years later. The early commercial CAD systems were devel-oped by large organizations, such as automotive and aerospace companies to assist their en-gineers 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 Manu-facturing Engineers in the fall of 1979. A large user of CAD software challenged the CAD ven-dors in attendance to develop a neutral exchange mechanism. From there, the historical ac-counts 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.

Page 56: Iso Intro Ver1

CHAPTER 2

50

1980

1990

2000

2010

ISOTC184 SC4

IGES

IGES 5.3

U.S.DoD

CALS

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 manufac-turing 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 sup-ply 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.

Page 57: Iso Intro Ver1

CHAPTER 2

51

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 genu-ine 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. Neverthe-less, 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 prod-uct 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 engi-neer 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 informa-tion 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 com-municated by IGES as a circle—but thereafter, all it would ever be was just a circle. In the origi-nal 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 sys-tems—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 Interna-tional 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 (Stan-dard 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-

Page 58: Iso Intro Ver1

CHAPTER 2

52

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.

TechnicalCommittee

184

InternationalOrganization forStandardization

(ISO)

ISO 15926ISO 10303

Subcommittee 4

Work Group 3

Team 25

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 competitive-ness 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 orga-nizing 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 ex-change. 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.

Page 59: Iso Intro Ver1

CHAPTER 2

53

ISOTC184 SC4

PDES

IGES

NIST

ISO 10303

STEP

IGES

IGES/PDES(IPO)

LEGEND

Sponsoring organization

Consortium

Standard

2010

2000

1990

1980

Fig. 2.10 The transition from IGES to STEP.

Internationally, events were lining up in support of a new standard as well. Other CAD ex-change 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 demand-ed 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 expe-rienced carpenters can design a simple building in their heads and build it without any draw-ings, 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.

Page 60: Iso Intro Ver1

CHAPTER 2

54

other—knowing their work will coordinate in the end to the finished building that was envis-aged by the architect. And if the design is particularly good the blueprints can be used else-where 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 mod-el. 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 impor-tant 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

Page 61: Iso Intro Ver1

CHAPTER 2

55

This AP is a mechanism for maintaining the information needed to support complex prod-ucts and systems over their complete life cycle from conceptual design to decommissioning.

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 Inter-

national Standard in 2007

• In between a number of consor-

tia 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 pub-

lishing it as part of the standard,

Annex M.

When you read this diagram, and

others like it throughout this chapter,

remember that although they ap-

pear at a particular time, all of the

standards were developed over a

similarly long timeline.

STEPlib

Annex M

1980

1990

2000

2010

AP-227

ISOTC184 SC4

PDES

ISO 10303

Part 42

Part 11

Part 21

AP-203

AP-214

AP-239

AP-221

STEP

1980

1990

2000

2010

LEGEND

Sponsoring organization

International standard

Part of a standard

Fig. 2.11 History of STEP.

Today, the use of STEP in the manufacturing industry is routine—but it took a few notable suc-cesses 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 informa-tion 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.

Page 62: Iso Intro Ver1

CHAPTER 2

56

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.

AP-227

Annex MAP-221

1980

1990

2000

2010

1980

1990

2000

2010

EPISTLE

PISTEPActivity Model

EuropeanUnion

ISOTC184 SC4

ISO 10303

POSCCaesar

Assoc’nPISTEPUSPI-NL

JapanSTEP

ESPRIT

PIPPIN

ProcessBase

PIEBASE

PIEBASEActivity Model

LEGEND

Sponsoring organization

Consortium which nolonger exists

Consortium which stillexists

International standard

Part of a standard

PlantSTEPPart 42

PDES

STEP

STEPlib

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 for-mation 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 ab-sorbed 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 se-rial 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

Page 63: Iso Intro Ver1

CHAPTER 2

57

were themselves made up of other consortia. The arrows between consortia and the inter-national 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 fa-cility 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 contri-butions 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 Pro-cessBase 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 informa-tion 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.

Page 64: Iso Intro Ver1

CHAPTER 2

58

PIPPIN

The Pilot Implementation of Process Plant Information Warehouse (PIPPIN) started at the be-ginning 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 stan-dards 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 seam-lessly.

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 organiza-tions 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 com-merce. Rather than developing its own standard, ENAA decided to follow international stan-dards and was an early proponent of AP-221 and AP-227. Later, Japan funded the develop-ment 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 partici-pants 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. Dur-ing 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 ap-plication 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.

Page 65: Iso Intro Ver1

CHAPTER 2

59

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 proj-ects. 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 partici-pates 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 organiza-tions 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 num-ber of companies directly involved in plant design, equipment manufacture, and operations—but over time the individual companies withdrew, leaving only the three consortia as mem-bers.

1990

1995

EPISTLE

POSCCaesar

Assoc’n

POSC/CaesarProject

CaesarOffshoreProject

PISTEP

UPSI-NL

2000

PetrotechnicalOpen Software

Corporation

Energistics

UPSI-NL

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

Page 66: Iso Intro Ver1

CHAPTER 2

60

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 Samenwerkings-verband 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, consul-tancies, and universities.

The mission of USPI-NL is “To develop, maintain and promote the use of international informa-tion 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 implemen-tation 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 mainte-nance), 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 oth-ers, 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 paper-based information-handling methods used during design, construction, operation, and even-tual decommissioning was hampered by locking information in documents where it was dif-ficult 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

Page 67: Iso Intro Ver1

CHAPTER 2

61

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.

Fig. 2.14 PISTEP activity model.

POSC Caesar Association

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 corpora-tion 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

Page 68: Iso Intro Ver1

CHAPTER 2

62

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 As-sociation (PCA). The technical work of PCA was more and more related to the ISO STEP stan-dard 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 Pro-cess 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 repre-sentatives 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 bound-aries 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 infor-mation 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.

Page 69: Iso Intro Ver1

CHAPTER 2

63

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 im-plies 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 proj-ects 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 Require-ments Model (ARM),8 refines it further to a more detailed data model, and then maps the re-quirements 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 develop-ment 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.

Page 70: Iso Intro Ver1

CHAPTER 2

64

Annex MAP-221

ISO 10303

1980

1990

2000

2010

1980

1990

2000

2010

POSCCaesar

Assoc’n

EPISTLE

PISTEPActivity Model

Part 4

Part 2

BC/D

ERDL

ISO 15926

Related to

STEPlib

Snapshot Series

ISOTC184 SC4

ISOTC184 SC4

PIEBASE

PIEBASEActivity Model

PISTEPUSPI-NL

JapanSTEP

EuropeanUnion

ESPRIT

PIPPIN

ProcessBaseEPISTLE Core

Model

LEGEND

Sponsoring organization

Consortium which nolonger exists

Consortium which stillexists

International standard

Part of a standard

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 in-volved 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 sepa-rate 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.

Page 71: Iso Intro Ver1

CHAPTER 2

65

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 combi-nation 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 dia-gram 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 then-current 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 intel-ligence 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: in-stead 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 sig-nificant parts of ISO 15926 in Chapter 3. Figure 2.16 brings in the remaining parts of ISO 15926 and shows a new player, Fiatech.

Page 72: Iso Intro Ver1

CHAPTER 2

66

Annex M

IDS/ADI

AP-221

ISO 10303

1980

1990

2000

2010

1980

1990

2000

2010

POSCCaesarAssoc’n

EPISTLE

PISTEPActivity Model

Part 4

Part 2

Part 3

Initial Part7

Part 7

Part 8

Part 9

BC/D

ERDL

Part 10

ISO 15926

Related to

Part 42

Basis For

STEPlib

Snapshot Series

ISOTC184 SC4

ISOTC184 SC4

PIEBASE

PIEBASEActivity Model

PISTEPUSPI-NL

JapanSTEP

Fiatech

CII

Universityof Texas

EuropeanUnion

ESPRIT

PIPPIN

ProcessBaseEPISTLE Core

Model

LEGEND

Sponsoring organization

Consortium which nolonger exists

Consortium which stillexists

International standard

Part of a standard

PCA/Fiatech project

Part 11

Fig. 2.16 Development of ISO 15926.

Fiatech

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 engi-neering and construction work processes. In this definition, capital projects industry includes all manner of capital construction—from roads and sewers, commercial buildings and shop-ping 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 con-tractors, construction contractors, equipment manufacturers, software developers, and uni-versities. 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 bound-aries. For a portion of the development costs, all members can participate in all results.

Page 73: Iso Intro Ver1

CHAPTER 2

67

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 ele-ments, ISO 15926 is part of number nine, Lifecycle Data Management & Information Integra-tion. 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-oper-ator—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 Accelerat-ing 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. Un-der 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 defi-nitions 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.

Page 74: Iso Intro Ver1

CHAPTER 2

68

1980

1990

2000

2010

If only we could exchangeCAD drawings.

If only we all used the samedata model.

If only we all used the sameReference Data Library

If only we could embed meaninginto 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 al-ways 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 environ-ment 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

Page 75: Iso Intro Ver1

CHAPTER 2

69

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 conven-tion—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 re-ceive 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.

Page 76: Iso Intro Ver1

CHAPTER 3

70

CHAPTER 3: HOW DOES ISO 15926 WORK?

The full title of ISO 15926 implies a very ambitious goal, encompassing information about ev-ery 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 disagree-ment 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 over-lap.

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 differ-ent 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 inte-grating 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 be-cause 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

Page 77: Iso Intro Ver1

CHAPTER 3

71

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 in-teroperability. 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 interop-erable. 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: In-tegration of… If we were to apply this definition of integration, it would imply that if we want-ed 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, imple-menting 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.

Page 78: Iso Intro Ver1

CHAPTER 3

72

Example 2: Integration and Interoperability with Engineering Design Systems

Figure 3.2 shows two engineering design systems offered by two competing software ven-dors, ACME and EMCA. Each suite of software offers intelligent, three dimensional (3D) mod-eling 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

P&ID

Structural

DataSheetsSchematics

Raceway

ACMEEngineering System Piping

Equipment

P&ID

Structural

DataSheetsSchematics

Raceway

EMCAEngineering System

Integrated Integrated

Interoperable

Fig. 3.2 Integration and interoperability in engineering design systems.

Within a suite, we would call the applications integrated if information created by one applica-tion 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 num-ber 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.

Page 79: Iso Intro Ver1

CHAPTER 3

73

Engineering

Procurement Construction

A

A A

A

Operations

AdapterAA

A

A

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.

Service Bus or Asset Hub(Data Warehouse)

Engineering Procurement Construction

Adapter

Operations

A A A A

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 ex-change information among a number of applications you don’t actually need the data ware-house! Figure 3.5 shows what this would look like without the data warehouse.

Page 80: Iso Intro Ver1

CHAPTER 3

74

Engineering Procurement Construction

ISO 15926 Adapter

Information Exchange to the ISO 15926 Standard

Operations

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 applica-tions in any way.1 But because the applications each, independently, follow an external stan-dard 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.

Page 81: Iso Intro Ver1

CHAPTER 3

75

Fig. 3.6 The parts of ISO 15926.

Part 2: Data Model

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 Eng-lish behind can also mean “toward the rear,” “slow,” and in some cases “hidden.” Simply look-ing 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-verb-object), 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

Page 82: Iso Intro Ver1

CHAPTER 3

76

you, dear reader, are a native English speaker you have probably heard several of these com-binations 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 poste-rior 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 re-ally means just by looking at it. Taken literally, this database means that Joe can groom dogs

Page 83: Iso Intro Ver1

CHAPTER 3

77

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 ad-dition 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 inter-pretation 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 Language

Bloggs, Joe French

Bloggs, Joe German

Bloggs, Joe Greek

Bloggs, Joe Spanish

Name Skill

Bloggs, Joe groom dogs

Bloggs, Joe cook

Bloggs, Joe type

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 ex-change 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.

Page 84: Iso Intro Ver1

CHAPTER 3

78

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 ap-plication 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.

External Level

Conceptual Level

Application Data Models

Conceptual Data Model

Engineering Procurement Construction Operations

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 appli-cation built on the engineering data model and a procurement application built on the pro-curement 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 sche-mas) 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 concep-tual 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

Page 85: Iso Intro Ver1

CHAPTER 3

79

by 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.

Service Bus or Asset Hub(Data Warehouse)

Engineering Procurement Construction Operations

A A A A

Engineering Procurement Construction

Information Exchange to the ISO 15926 Standard

Operations

Application DataModels

ConceptualData Model

Application DataModels

ConceptualData 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 informa-tion 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 rep-resentation of information about objects used in capital projects. This representation is speci-fied 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 ob-jects, and individual objects and activities.

Page 86: Iso Intro Ver1

CHAPTER 3

80

To review, Part 2 defines the rules and constraints (more or less the grammar used through-out) 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 es-sentially 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 Commu-nication

Effective communication requires that all parties share a common set of definitions. In com-puter 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 Mon-day 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.

Page 87: Iso Intro Ver1

CHAPTER 3

81

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 environ-ment 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 as-sumed 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 oppor-tunity for ambiguity. For instance, what is the difference between “maximum allowable work-ing 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 ex-changing 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 defini-tion 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 engi-neer 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 tempera-ture. 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

Page 88: Iso Intro Ver1

CHAPTER 3

82

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 Tempera-ture 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 geog-raphy 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 prov-ince.

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 indi-viduals 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 oth-ers. 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.

Page 89: Iso Intro Ver1

CHAPTER 3

83

many engineering standards for various parts of the capital projects industry within its juris-diction. 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 ref-erence 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 col-laborating 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 informa-tion from these RDLs, along with the core classes published in Part 4.

Page 90: Iso Intro Ver1

CHAPTER 3

84

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 terminol-ogy (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 ontol-ogy 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 mean-ingful sentences in an unfamiliar language. Part 7, like Part 2, is written indepen-dently 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 com-puter 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

Page 91: Iso Intro Ver1

CHAPTER 3

85

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 special-ized. Although Part 2 enables considerable flexibility in what can be modeled, it is very com-plex. 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 con-vert 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 val-ues. 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.

Page 92: Iso Intro Ver1

CHAPTER 3

86

class_of_person

classification

physical_object

other_relation

classifier

classified

class_of_person

classification

physical_object

classifier

classified

‘woman’ ‘man’class_of_organism

classification

physical_object

classifier

classified

‘dog’

Indirect_connection

classification

other_class_of_relation ‘marriage’

role_1 role_2 side_1 side_2

classifier

classified

Fig. 3.15 Walking the dog.

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-

Page 93: Iso Intro Ver1

CHAPTER 3

87

ably 1:00 in the morning. Walking their dog Willy at that time of day might normally be dan-gerous given the part of town they live in, but Willy is a large Rottweiler. Friends would under-stand 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 contrac-tors, 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 us-ers 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 ofIndividual

Class of Class ofRelationship

Single PropertyDimension Scale Express

RealExpress

Real

3051CG AmbientTemperature 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.

Page 94: Iso Intro Ver1

CHAPTER 3

88

3051 CGCO Individual

COPossessor

Temperature Range-40°C – 85°C

Property RangePropertySpace

CO Indirect Property

Classifier

Temperature 85 °C

Property

TemperatureSingle Property Dimension

CelsiusScale

Classified

Classifier

85

Arithmetic NumberInput Result

Property Quantification

Upper Bound Of Property Range

AmbientTemperature

CO CO Relationship

Classified

Classifier

Classifier

Represented

Pattern ”85 "ExpressReal

CO Identification

Classified

Classified

Classifier

Temperature -40°C

Property

Classified

Classifier

-40

Arithmetic NumberInput Result

Lower Bound Of Property Range

Classifier

Represented

Pattern ”-40"ExpressReal

Classified

Classified

Property Quantification

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

CO Indirect Property

Property Arithmetic Number

Property Quantification

Upper Bound Of Property Range

CO Identification

Property Arithmetic NumberLower Bound Of Property Range

Property Quantification

Property Type

Property Range Base Property Type UoM

Input 1

Input 2

Classifier

Classified

Classifier

Classifier

COProcessor

PropertySpace

Classified

Classified

Classifier

Classified

Classifier

Classified

ResultInput

Represented

Pattern

Pattern

Represented

Classifier

Classified

ResultInput

Classified

Classifier

Fig. 3.18 ISO 15926 property range template.

Page 95: Iso Intro Ver1

CHAPTER 3

89

But what if we told you that your only requirement is to fill in the blue boxes with the appro-priate 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?

TemplateID Class Property Type Property

RangeBase Property

Type UoM Input 1 Input 2

ABC 3051CG AmbientTemperature

(Created bythe system) Temperature C -40 85

Select RDLClass or

Project Data

Select fromstandard/

customized list ofRDL Instance

Select fromstandard/

customized list ofRDL Instance

Fig. 3.19 Property range template inputs.

A template is basically a regular pattern of information, like rows and columns in a spread-sheet. 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 head-ing). 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 speci-fication 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 tem-plates. 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

Page 96: Iso Intro Ver1

CHAPTER 3

90

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 organiza-tion 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 deliver-ing 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 con-cepts. 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 on-tologies. 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 dog7—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.

Page 97: Iso Intro Ver1

CHAPTER 3

91

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 infor-mation 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 query-ing 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 mes-sage 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 informa-tion exchange in capital projects. In the Chapter 2 we discussed ontologies as a way of rep-resenting 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, individ-ual, 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. To-ward 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”.

Page 98: Iso Intro Ver1

CHAPTER 3

92

ISO

1592

6-2

ISO

1592

6-4

User

defi

ned

class

es

Axiomatic concepts such asthing, class, individual, andpropertyGeneric engineering concepts,such as physical object, activity,composition, connection

Core classes and referenceindividuals, such as pump,reducer, heat exchanger, Cairo

Classes defined byinternational standards andindustry associations

Project Individuals such aspump 37-P-101A andpressure guage 37-PI-205

Company commodity classes

Catalogues from suppliers andmanufactuerers

Proje

ct Da

ta

Special project classes

ISO 15926-7

Core Templates

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 informa-tion 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 15926Fig. 3.21 ISO 15926 pyramid symbol used in presentations.

Page 99: Iso Intro Ver1

CHAPTER 3

93

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 ambi-guity 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 informa-tion exchanges to drive costs down.

Figure 3.22 shows various levels of compliance with ISO 15926 in information transfer, start-ing 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.

Ambi

guity

Sca

le

Least AmbiguityGreatest Compliance

Greatest Ambiguity

Least Compliance

ISO

159

26

If we use the semantic webcouldn’t we automate more of

this?

Shouldn’t we add workflowand security to the semantic

web?

Would it help if I told you howI was using the data?

Why don’t we use industrystandard definitions?

Wouldn’t it be better if weagreed on common

definitions?

Let’s just exchange raw dataand figure it out together

Fig. 3.22 Levels of compliance with ISO 15926.

Page 100: Iso Intro Ver1

CHAPTER 3

94

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 informa-tion 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.

Fig. 3.23 Figure out each exchange every time.

Level of Collaboration Required

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.”

Page 101: Iso Intro Ver1

CHAPTER 3

95

“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 ver-sion 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 oppor-tunity 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.

Page 102: Iso Intro Ver1

CHAPTER 3

96

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 mate-rial 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.

Page 103: Iso Intro Ver1

CHAPTER 3

97

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 appli-cations 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 ex-change. Funny you should ask! The next example shows two organizations exchanging infor-mation 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 dic-tionary to create the neutral files they use for information exchange. Being able to export in-formation 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 compli-ance.

• EMCA imports the information using its database map to translate the information into something its systems understand.

Page 104: Iso Intro Ver1

CHAPTER 3

98

Fig. 3.25 Use ISO 15926-4 for information exchanges.

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. 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 pur-chase 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

Page 105: Iso Intro Ver1

CHAPTER 3

99

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 com-puter 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 tradi-tional 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 busi-ness 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.

Page 106: Iso Intro Ver1

CHAPTER 3

100

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 struc-tures 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

Page 107: Iso Intro Ver1

CHAPTER 3

101

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 con-tained within the information itself. The addition of Part 7 adds some initial work to fully un-derstand 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 em-bedded 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 struc-tures 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 tem-plates, 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 tem-plates understand how to read the meaning from the structure of the data in the neutral file.

Page 108: Iso Intro Ver1

CHAPTER 3

102

Fig. 3.27 Automating the process.

Level of Collaboration Required

About the only collaboration required here would be something to do with the manner of ex-change. For instance, each party could post information on a particular location on the Inter-net 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 struc-ture or meaning of the information itself because the meaning of the data would be embed-ded 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?”

Page 109: Iso Intro Ver1

CHAPTER 3

103

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 be-ing 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 se-curity. 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.

Page 110: Iso Intro Ver1

CHAPTER 3

104

Fig. 3.28 Automating the process with security

Level of Collaboration Required

The only question at this stage will be something like “What’s the URL of your ISO 15926 inter-face 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.

Page 111: Iso Intro Ver1

CHAPTER 4

105

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 begin-ning 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 com-puter 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 informa-tion 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 prob-ably 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.

Page 112: Iso Intro Ver1

CHAPTER 4

106

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 harmoni-zation 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 as-sociation 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 in-volves 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 informa-tion across disciplines and business domains.

Equipment Hub

Equipment Hub (EqHub) is a repository for technical information for all of the oil and gas op-erators 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 certi-fied information on standard equipment, which can represent 80 percent of document vol-

Page 113: Iso Intro Ver1

CHAPTER 4

107

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 busi-ness 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 requir-ing 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 approach-es 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 de-signed 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 in-formation models driven by OpenO&M use cases, which are defined and prioritized by owner-operators on behalf of industry groups such as oil and gas, chemical, and aerospace. Collec-tively, 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

Page 114: Iso Intro Ver1

CHAPTER 4

108

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 stan-dardization activities addressing the automation of manufacturing as well as other process-oriented 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 gener-ally (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-manage-ment–oriented layer above. It is concerned with detailed operations planning and schedul-ing, 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 opera-tions 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 dramat-ically 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 syn-chronization between O&M systems and engineering systems after handover results in ambi-guity about plant, platform, and facility configuration.

As the OpenO&M Initiative has worked to define the basis for an interoperable execution envi-ronment 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.

Page 115: Iso Intro Ver1

CHAPTER 4

109

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 informa-tion 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 Engineer-ing 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 stan-dardization 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 en-vironment 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

Page 116: Iso Intro Ver1

CHAPTER 4

110

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 dem-onstration at an industry conference by the end of 2011 will leverage the same use case to tar-get 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 recommenda-tion 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 ter-minology when exchanging information with partners that were not known as well. The indus-try 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 num-ber 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 Fiat-ech 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.

Page 117: Iso Intro Ver1

CHAPTER 4

111

• There will be many levels of certification. The diagram shows five levels of RDL, but in prac-tice 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 defini-tions 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 im-mutable 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.

Page 118: Iso Intro Ver1

CHAPTER 4

112

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 proj-ect, there have been a number of very successful demonstrations. Figure 4.3 is a simplified di-agram 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).

MAPExchange

Validatio

n

ACME EMCA

MAP 87

Part 9Facade

PART 7Templates

PART 8OWL

9 8 7

Part 9Facade

PART 7Templates

PART 8OWL

9

Validation

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 capi-tal projects, test and validate currently available ISO 15926 tools, and assist companies in

Page 119: Iso Intro Ver1

CHAPTER 4

113

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 soft-ware. This means that iRING capability can be added to commercial software without hav-ing 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 differ-ent that it is becoming a barrier to the wide acceptance of ISO 15926. (We provide an intro-ductory 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 pro-fessionals 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 infor-mation. 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 partic-ular 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 in-stance, 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

Page 120: Iso Intro Ver1

CHAPTER 4

114

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 informa-tion 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 de-scribed. 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 attri-bute to. In many of the prior demonstrations of ISO 15926, the goal was to develop the tech-nology 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 organi-zation 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 specifica-tions 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.

Page 121: Iso Intro Ver1

CHAPTER 4

115

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 re-lated 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 spe-cialized 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 interme-diate 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 be-tween 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.

Page 122: Iso Intro Ver1

CHAPTER 5

116

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 sta-tion 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 air-conditioned 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

Page 123: Iso Intro Ver1

CHAPTER 5

117

proof-of-concept software that will more or less snap onto the side of a commercial applica-tion.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 tem-plates. 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 any-thing 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 intro-duction 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 be-lieves “everyone just knows.” Find out what these are before attempting to exchange infor-

1. In Chapter 4, we introduced the iRINGTools Interfacing Project (IIP).

Page 124: Iso Intro Ver1

CHAPTER 5

118

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 ex-change 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 public-ly 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 tem-plates. At the higher levels of compliance, ISO 15926 uses a fundamentally different ap-proach 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 communi-cation 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, engi-neers 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

Page 125: Iso Intro Ver1

CHAPTER 5

119

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 com-pared 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 lan-guage 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 data-base 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 informa-tion 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 dif-ferent. 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 ap-plication 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 procure-ment 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 pro-gramming 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 in-formation 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.

Page 126: Iso Intro Ver1

CHAPTER 5

120

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 import-ed to the second application. Where this will become critically important is when another ap-plication 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 in-formation 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 iden-tifier (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, soft-ware 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.

Page 127: Iso Intro Ver1

CHAPTER 5

121

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 com-pliance, 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 map-ping: 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 back-grounds, 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 tem-plates, 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 informa-tion 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.

Page 128: Iso Intro Ver1

CHAPTER 5

122

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 exer-cise. Of course, if an organization with a great deal of proprietary software and work process-es 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 some-one with a logical mind who understands abstract reasoning. Obviously, the ideal candi-date 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 disci-pline 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 under-stand 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 re-sources 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)

Page 129: Iso Intro Ver1

CHAPTER 5

123

have already been written and are available under an open-source license. As well, a mar-ket 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 cli-ents also have. Everyone can work together, share the costs, and share the results. EPC con-tractors 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 develop-ers 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 develop-ers will suddenly get much easier.

Equipment Manufacturers and Construction Contractors

Equipment manufacturers and construction contractors, with tighter margins, join a consor-tium 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 real-world projects.

Page 130: Iso Intro Ver1

APPENDIX A

124

APPENDIX A: THE PARTS OF ISO 15926

This appendix summarizes the current state of the various parts of ISO 15926. We have treat-ed 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 tech-nical scope is defined.

2. Consensus building where the detailed scope is negotiated between the countries in-volved.

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.

Page 131: Iso Intro Ver1

APPENDIX A

125

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 indi-vidual 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.

Page 132: Iso Intro Ver1

APPENDIX A

126

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 Ontol-ogy 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 com-pliance; 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 communi-ty 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

Page 133: Iso Intro Ver1

APPENDIX A

127

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 conclu-sions.

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.

Page 134: Iso Intro Ver1

APPENDIX B

128

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 engag-ing in a lengthy process of understanding the meaning of each other’s data. But implement-ing 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 com-pliance to give users a rough guide to comparing systems. The following table serves as a “thumbnail.”1

Category Compliance Checklist

Semantic precision

Dictionary identification only

Shortcut relations

Full ontology

Representation technol-ogy

Any formatted file

Proprietary XML

RDL XML

Part 8 (OWL)

Referencing technologyURIs contained in schema

External RDL

Interface technology

File exchange

Proprietary query

Part 9 (SPARQL)

Industrial standardization

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.

Page 135: Iso Intro Ver1

APPENDIX B

129

Functional capability

Export interface

Import interface

Empty seed

Lossless consolidation

Reconciliation

Semantic Precision

ISO 15926 is all about driving out ambiguity to reduce the risk and cost of information ex-change. 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 pres-sure 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 pro-viding 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 dif-ferent 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 tem-plate 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.

Page 136: Iso Intro Ver1

APPENDIX B

130

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 ex-change 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 organi-zations 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 begin-ning.

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 infor-mation 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.

Page 137: Iso Intro Ver1

APPENDIX B

131

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 con-nect 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 in-formation 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 databas-es. 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 ex-change 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

Page 138: Iso Intro Ver1

APPENDIX B

132

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 ad-dressed 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 re-duced. 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 un-der 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 termi-nology.

Metadata Scope

When data is exchanged as part of business activities, there are usually obligations and con-tractual 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.

Page 139: Iso Intro Ver1

APPENDIX B

133

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.

Page 140: Iso Intro Ver1

APPENDIX C

134

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 com-municate 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 To-gether

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.

Page 141: Iso Intro Ver1

APPENDIX C

135

Fig. C.1 Figure out each exchange every time.

Roles

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_ListID Dwg_No Rating PID No Spec Line Tag

85457 4567-32-17 150 1234-32-45 A373 10-32-A373-12-143896058 4567-32-17 300 1234-32-45 B893 10-32-B893-10-037848981 4567-32-17 600 1234-32-45 C578 10-32-C578-10-2155

Pipe Size Valve Tag12 32-126910 32-29588 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 engi-neers 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 docu-ments and having a person rekey the values. Figure C.3 shows EMCA’s valve list, currently empty.

Page 142: Iso Intro Ver1

APPENDIX C

136

EMCA Table Name: Table_32Index 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 EMCATable Name Column Name Table Name Column NameValve_List ID Table_32 Index NoValve_List Piping DRG Table_32 Dwg_NoValve_List Class Table_32 RatingValve_List PID_No Table_32 PIDValve_List Spec Table_32 Mat_SpecValve_List Line_Tag Table_32 TagValve_List Pipe Size Table_32 DiameterValve_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 con-tent—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 da-tabase 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 data-bases 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.

Page 143: Iso Intro Ver1

APPENDIX C

137

ACME EMCATable Name Column  Name Table Name Column  NameVALVE_LIST AREA TABLE_32 CLIENT_SYSTEMVALVE_LIST CLASS TABLE_32 CLIENT_UNITVALVE_LIST COMP  ID TABLE_32 COM_GRPVALVE_LIST DATASHEET TABLE_32 DES_RESPVALVE_LIST DS_ID TABLE_32 DIAMETERVALVE_LIST LINE  TAG TABLE_32 DIAMETER_UOMVALVE_LIST MANUFACTURER TABLE_32 DWG_NOVALVE_LIST MATERIAL TABLE_32 HEAT_TRACEVALVE_LIST MODEL  NO TABLE_32 HOLDVALVE_LIST OP  PRESS TABLE_32 INDEX_NOVALVE_LIST OP  TEMP TABLE_32 LINE_NUMBERVALVE_LIST PID  NO TABLE_32 LINE_TAGVALVE_LIST PIPE  SIZE TABLE_32 MAT_SPECVALVE_LIST PIPING  DRG TABLE_32 PIDVALVE_LIST RUN TABLE_32 PID_LOCATIONVALVE_LIST SERVICE TABLE_32 PID_REVVALVE_LIST SPEC TABLE_32 PROJ_NOVALVE_LIST STATUS TABLE_32 QUANTITYVALVE_LIST TAG TABLE_32 RATING  VALVE_LIST TAGTYPE TABLE_32 SEQ_NOVALVE_LIST VALVE  TAG TABLE_32 STARTUPVALVE_LIST VALVE  TEXT TABLE_32 SUFFIXVALVE_LIST VALVE  TYPE TABLE_32 SYSTEMVALVE_LIST VCODE TABLE_32 TAGVALVE_LIST VINT1 TABLE_32 UNITVALVE_LIST VNUM TABLE_32 VALVE_LOCK_DEVICEVALVE_LIST VSIZE TABLE_32 VALVE_NUMBERVALVE_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.

Page 144: Iso Intro Ver1

APPENDIX C

138

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 in-stance, 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 ficti-tious 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 mea-surement with every measurement. In this example of a valve list, ACME may feel that it is ex-

Page 145: Iso Intro Ver1

APPENDIX C

139

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. Fig-ure C.6 shows the tables after rearranging column names so that equivalent names are in the same horizontal row.

ACME EMCATable Name Column Name Table Name Column NameVALVE_LIST TAG TABLE_32 RECORD_IDVALVE_LIST PIPING DRG TABLE_32 DWG_NO

TABLE_32 STARTUPVALVE_LIST CLASS TABLE_32 RATING

TABLE_32 PID_REVTABLE_32 DES_RESP

VALVE_LIST PID NO TABLE_32 PIDTABLE_32 HOLDTABLE_32 HEAT_TRACETABLE_32 PROJ_NOTABLE_32 LINE_NUMBER

VALVE_LIST SPEC TABLE_32 MAT_SPECVALVE_LIST LINE TAG TABLE_32 LINE_TAG

TABLE_32 QUANTITYVALVE_LIST PIPE SIZE TABLE_32 DIAMETER

TABLE_32 DIAMETER_UOMTABLE_32 VALVE_LOCK_DEVICETABLE_32 VALVE_NUMBER

VALVE_LIST VNUM TABLE_32 SEQ_NOTABLE_32 CLIENT_SYSTEMTABLE_32 COM_GRPTABLE_32 SYSTEMTABLE_32 PID_LOCATION

VALVE_LIST VALVE TYPE TABLE_32 VALVE_TYPETABLE_32 SUFFIX

VALVE_LIST VUNIT TABLE_32 UNITVALVE_LIST VALVE TAG TABLE_32 TAG

TABLE_32 CLIENT_UNITVALVE_LIST VSIZEVALVE_LIST AREAVALVE_LIST DATASHEETVALVE_LIST TAGTYPEVALVE_LIST VCODEVALVE_LIST STATUSVALVE_LIST MATERIALVALVE_LIST OP PRESSVALVE_LIST OP TEMPVALVE_LIST MANUFACTURERVALVE_LIST MODEL NOVALVE_LIST VALVE TEXTVALVE_LIST VINT1VALVE_LIST RUNVALVE_LIST SERVICEVALVE_LIST COMP IDVALVE_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 busi-ness of each of the two organizations means that each pays attention to different things. An

Page 146: Iso Intro Ver1

APPENDIX C

140

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 sim-ply 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

Page 147: Iso Intro Ver1

APPENDIX C

141

number but in a separate table based on an arbitrary “pipe run number.”1 Figure C.7 shows what this might look like.

Table Name Column Name Table Name Column Name. .

VALVE_LIST LINE TAG LINE TAG RUN NO TABLE_32 LINE_TAG. .

TABLE_32 DIAMETER_UOMRUN NO UOM

ACME EMCA

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 ar-rows 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 commu-nicate by pointing at something and saying its name. After a while both of them would un-derstand 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 Defini-tions?

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 opportuni-ty 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.

Page 148: Iso Intro Ver1

APPENDIX C

142

• 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 asso-ciated 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 anoth-er 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 ortho-graphic drawing.

Page 149: Iso Intro Ver1

APPENDIX C

143

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’ The geographic or functional area of a plant; commonly called “unit.”

wa’maH cha’ Asset tracking number for individually designed components; com-monly 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 FileTable Name Column Name Column Name Dictionary NameVALVE_LIST TAG TAG wa'VALVE_LIST PIPING DRG PIPING DRG cha'VALVE_LIST CLASS CLASS wejVALVE_LIST PID NO PID NO loSVALVE_LIST SPEC SPEC vaghVALVE_LIST LINE TAG LINE TAG javVALVE_LIST PIPE SIZE PIPE SIZE Soch

UOM chorghVALVE_LIST VNUM VNUM HutVALVE_LIST VALVE TYPE VALVE TYPE wa'maHVALVE_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.

Page 150: Iso Intro Ver1

APPENDIX C

144

Neutral File Klingon Database Map EMCADictionary Name Column Name Table Name Column Namewa' RECORD_ID TABLE_32 RECORD_IDcha' DWG_NO TABLE_32 DWG_NOwej RATING TABLE_32 RATING loS PID TABLE_32 PIDvagh MAT_SPEC TABLE_32 MAT_SPECjav LINE_TAG TABLE_32 LINE_TAGSoch DIAMETER TABLE_32 DIAMETERchorgh DIAMETER_UOM TABLE_32 DIAMETER_UOMHut SEQ_NO TABLE_32 SEQ_NOwa'maH VALVE_TYPE TABLE_32 VALVE_TYPEwa'maH wa' UNIT TABLE_32 UNITwa'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 prob-ably 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.

Page 151: Iso Intro Ver1

APPENDIX C

145

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<End TB>

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 FileTable Name Column Name Column Name Dictionary NameVALVE_LIST TAG TAG row_idVALVE_LIST PIPING DRG PIPING DRG drawing_no_piping_orthoVALVE_LIST CLASS CLASS pressure_classVALVE_LIST PID NO PID NO drawing_no_pidVALVE_LIST SPEC SPEC piping_material_specVALVE_LIST LINE TAG LINE TAG piping_line_noVALVE_LIST PIPE SIZE PIPE SIZE piping_nominal_diameter

UOM length_uomVALVE_LIST VNUM VNUM maintenance_tracking_noVALVE_LIST VALVE TYPE VALVE TYPE component_type_valveVALVE_LIST VUNIT VUNIT production_unit_idVALVE_LIST VALVE TAG VALVE TAG asset_tracking_no

Fig. C.11 Data export using an ontological neutral file.

Page 152: Iso Intro Ver1

APPENDIX C

146

Neutral FileDictionary Name Column Name Table Name Column Namerow_id RECORD_ID TABLE_32 RECORD_IDdrawing_no_piping_ortho DWG_NO TABLE_32 DWG_NOpressure_class RATING TABLE_32 RATING drawing_no_pid PID TABLE_32 PIDpiping_material_spec MAT_SPEC TABLE_32 MAT_SPECpiping_line_no LINE_TAG TABLE_32 LINE_TAGpiping_nominal_diameter DIAMETER TABLE_32 DIAMETERlength_uom DIAMETER_UOM TABLE_32 DIAMETER_UOMmaintenance_tracking_no SEQ_NO TABLE_32 SEQ_NOcomponent_type_valve VALVE_TYPE TABLE_32 VALVE_TYPEproduction_unit_id UNIT TABLE_32 UNITasset_tracking_no TAG TABLE_32 TAG

Database Map EMCA

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 defini-tions, new users will be more likely to choose the correct term without having to talk to any-one. 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 intro-duce 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,

Page 153: Iso Intro Ver1

APPENDIX C

147

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 indus-try 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 experi-mental 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.

Page 154: Iso Intro Ver1

APPENDIX C

148

At the end of this appendix we have included a brief introduction to the RDS/WIP, but basi-cally 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 uni-versal 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#R16893283050An identification code for a drawing or a class of drawings

PRESSURE RATING CLASS http://rdl.rdlfacade.orgdata#R45649298385

Classes of standard pressure ratings (i.e., the maximum allow-able non-shock work-ing gage pressure at a given temperature and a specific material)

P AND I DIA-GRAM http://rdl.rdlfacade.org/data#R99486931975

A diagram showing a schematic representa-tion of a process sys-tem, including instru-mentation

MATERIAL SPECIFICA-TION

http://rdl.rdlfacade.orgdata#R54400593721

A specification that de-scribes the applicable materials for one or more items

PIPELINE OF-FICIAL IDEN-TIFIER

http://rdl.rdlfacade.org/data#R83498125174An identification code that identifies a pipeline

DIAMETER http://rdl.rdlfacade.orgdata#R94482935208

Intercept made by the circumference on a straight line through the center of a circle

UNIT OF MEA-SURE http://rdl.rdlfacade.org/data#R5817703946

A role used in ST 3401 to designate the ap-plicable scale in which the numerical value is expressed

Page 155: Iso Intro Ver1

APPENDIX C

149

SEQUENCE NUMBER http://rdl.rdlfacade.orgdata#R73944050980

A number assigned following an order of succession

PR3 1.10 VALVE TYPE/DESIGN

http://rdl.rdlfacade.org/data#R49125478120

Assignment of valve type (e.g., safety, relief, or safety relief), and design (e.g., conven-tional, bellows, or pilot)

FUNCTIONAL UNIT IDENTI-FIER

http://rdl.rdlfacade.org/data#R14322658775An identification code that identifies a func-tional unit

TAG IDEN-TIFICATION CODE

http://rdl.rdlfacade.org/data#R99047027503An 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

Neutral File

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

Database MapACME

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.

Page 156: Iso Intro Ver1

APPENDIX C

150

Neutral File Database Map EMCADictionary Name Column Name Table Name Column Namehttp://rdl.rdlfacade.org/data#R32813486958 RECORD_ID TABLE_32 RECORD_IDhttp://rdl.rdlfacade.org/data#R16893283050 DWG_NO TABLE_32 DWG_NOhttp://rdl.rdlfacade.org/data#R45649298385 RATING TABLE_32 RATING http://rdl.rdlfacade.org/data#R99486931975 PID TABLE_32 PIDhttp://rdl.rdlfacade.org/data#R54400593721 MAT_SPEC TABLE_32 MAT_SPEChttp://rdl.rdlfacade.org/data#R83498125174 LINE_TAG TABLE_32 LINE_TAGhttp://rdl.rdlfacade.org/data#R94482935208 DIAMETER TABLE_32 DIAMETERhttp://rdl.rdlfacade.org/data#R58177039466 DIAMETER_UOM TABLE_32 DIAMETER_UOMhttp://rdl.rdlfacade.org/data#R73944050980 SEQ_NO TABLE_32 SEQ_NOhttp://rdl.rdlfacade.org/data#R49125478120 VALVE_TYPE TABLE_32 VALVE_TYPEhttp://rdl.rdlfacade.org/data#R14322658775 UNIT TABLE_32 UNIThttp://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.

Page 157: Iso Intro Ver1

APPENDIX C

151

Fig. C.16 Use ISO 15926-4 for information exchange.

New Role

• 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 num-ber 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 iden-tical to the URI in the RDS/WIP, what does it matter? The answer is that if you were to ex-change 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 dur-ing 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 mini-mum requirement for compliance with ISO 15926, there is still room for ambiguity. For in-

Page 158: Iso Intro Ver1

APPENDIX C

152

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 map-ping. The purpose of this example is to give you a glimpse of how different it is, without be-coming 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 diction-ary, 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 struc-tures 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 tem-plates, 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.

Page 159: Iso Intro Ver1

APPENDIX C

153

• 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.

Fig. C.17 Use ISO 15926-7 for information exchange.

Level of Collaboration Required

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 tem-plates in Part 7.

Metaphor

So that you can understand what the exchange is trying to accomplish, we will start with a

Page 160: Iso Intro Ver1

APPENDIX C

154

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 Mi-chael 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 po-litical 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 hu-man 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 num-ber 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 Classifica-tionOfIndividual, which has two columns (or roles, Individual and Class)—as shown in Figure C.18.

ClassificationOfIndividual

Individual Class

xyz URI of the class

Pressure Transmitter

Fig. C.18 Use of the ClassificationOfIndividual template.

Individual: xyz

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.

Page 161: Iso Intro Ver1

APPENDIX C

155

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 con-sider 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.

ClassifiedIndividual

Individual Name ClassificationOfIndividual

xyz PT-101 URI of, say, ISA

Fig. C.19 Use of the ClassifiedIndividual template.

Individual: xyz

xyz is ACME’s internal identifier.

Name: PT-101

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).

Page 162: Iso Intro Ver1

APPENDIX C

156

lndirectPropertyScaleReal

Individual Property Value Units of Measure

xyzURI for the class Oper-ating Pressure

100 URI for the class of kPa

lndirectProperty

Individual Property Value

xyzURI for the class End Connection

URI for the class of NPT

lndirectPropertyScaleReal

Individual Property Value Units of Measure

xyzURI for the class Con-nection Size

0.75 Inches

Fig. C.20 Use of the IndirectPropertyScaleReal and IndirectProperty templates.

EMCA

When EMCA receives the information, its system will first look through the data for the tem-plate ClassificationOfIndividual, and everything associated with it, using the iden-tifier 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.

ClassificationOfIndividual

Individual Class

abc URI of the class

Pressure Transmitter

Fig. C.21 Individual identifiers in the ClassificationOfIndividual template.

Class: Pressure Transmitter

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 con-nect, 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.

Page 163: Iso Intro Ver1

APPENDIX C

157

lndirectPropertyScaleReal

Individual Property Value Units of Measure

abcURI for the class Operating Pressure

100 URI for the class of kPa

lndirectProperty

Individual Property Value

abcURI for the class End Con-nection

URI for the class of NPT

lndirectPropertyScaleReal

Individual Property Value Units of Measure

abcURI for the class Connec-tion Size

0.75 Inches

Fig. C.22 Templates containing operating pressure, thread form of connection, and size of connection.

Some Questions

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 Mod-eling, 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!

Page 164: Iso Intro Ver1

APPENDIX C

158

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 infor-mation 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 ap-proved 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

Page 165: Iso Intro Ver1

APPENDIX C

159

Examples

In the search box, search for the items indicated in Table C.5.

TABLE C.5

SEARCH BOX ITEMS

Item Purpose

Temperature RDS/WIP will return all terms containing the word temperature, in groups of 20.

TEMPERATURE RDS/WIP should return the same results because it is not case sensitive.

^temperature RDS/WIP will return all terms beginning with the word tempera-ture.

^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.

Fig. C.23 RDS/WIP entry for temperature.

TABLE C.6

RDS/WIP TERMINOLOGY

Item Purpose

RDS/WIP URI The URI for the term TEMPERATURE. If you enter this text string into your web browser, you will be taken to this page.

Label The official designator for this term. Within the database, this desig-nator 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 be-longs.

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.

Page 166: Iso Intro Ver1

APPENDIX D

160

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 oppor-tunity 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 de-veloper 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 model-ing. 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 ad-vancing 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

Page 167: Iso Intro Ver1

APPENDIX D

161

Hans Teijgeler has been influential in developing some of the parts of ISO 15926. In his retire-ment, 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 Over-view. In it he explains why ISO 15926 was developed. He describes what he calls the “4D ap-proach” 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=129&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

Page 168: Iso Intro Ver1

APPENDIX D

162

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 accelerat-ing the development, demonstration, and deployment of fully integrated and automated tech-nologies 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

Page 169: Iso Intro Ver1

APPENDIX D

163

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, remov-ing 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 tech-nical 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 engineer-ing 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 interest-ing. The purpose of this workshop was to create an interoperability roadmap for organiza-tions—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

Page 170: Iso Intro Ver1

APPENDIX D

164

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 de-velopment 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 develop-ment 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 owner-operators. After a facility has been built and commissioned, document and information hando-

Page 171: Iso Intro Ver1

APPENDIX D

165

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 par-ties to agree at the beginning of a project what needs to be handed over. So that every proj-ect 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 discus-sion 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, pub-lished by EPISTLE, explicitly lists deliverables by name and is organized by engineering disci-pline. 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 Activ-ity 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 instruc-tions 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 Fiat-ech in 2006. Several second parts are envisioned, each to focus on the deliverables of a spe-cific 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).

Page 172: Iso Intro Ver1

APPENDIX D

166

• 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.

Page 173: Iso Intro Ver1

GLOSSARY

167

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 under-stand.

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

Page 174: Iso Intro Ver1

GLOSSARY

168

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.

Page 175: Iso Intro Ver1

GLOSSARY

169

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 dif-ferent 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 com-mon 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 clas-sify 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 vocabu-lary, 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 reason-ably 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 taxon-omy is concerned with machines you should analyze the relative order of these three things.

Page 176: Iso Intro Ver1

GLOSSARY

170

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 represen-tation 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 relation-ships 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 exam-ple, “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 some-thing 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 human-ity. 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:

Page 177: Iso Intro Ver1

GLOSSARY

171

If you are a Start Trek fan and have watched one of the episodes where the crew of the Enter-prise 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 seam-lessly.

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 communi-cate. 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 com-puter 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 com-mon 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 integra-tion 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 sup-pose 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.

Page 178: Iso Intro Ver1

GLOSSARY

172

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—per-haps 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 encap-sulation 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 begin-ning 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 pubes-cent 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!).

Page 179: Iso Intro Ver1

GLOSSARY

173

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 ac-tual 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 Seman-tic 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 collab-orative 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. Put-ting 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).

Page 180: Iso Intro Ver1

GLOSSARY

174

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-predicate-object 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.

Page 181: Iso Intro Ver1

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