Iso Intro Ver1

ELEMENT 8 WORKFORCE & TRAINING
An Introduction to ISO 15926
November 2011
An Introduction to ISO 15926
November 2011
ACKNOWLEDGMENTS
Fiatech has produced this book at the request of and for the benet 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 signicantly inuenced this publication. Notably, this book was produced by a project team who voluntarily carried out the objective to provide an introductory document for the Capitol Projects Industry. This team consisted of: Manoj Dharwadkar, Director, Product Management, Bentley Systems; Glen Worrall, Solutions Architect, Bentley Systems; Onno Paap, Data Integration Manager, Fluor; Faith Junghans, President, Faithful Engineering; Chris Schwander, Consulting Engineer, DuPont; and Alan Johnston, President, MIMOSA. In addition, Ian Glendinning, Glenco, President, GlencoIS; Hans Teijgeler, Fluor (retired); and Matthew West, Information Junction; provided considerable technical expertise and content during the writing process. I wish to acknowledge the special efforts of Gordon Rachar, WorleyParsons who served as a consultant to the project and was the primary author of this publication. Additionally, Daril Bentley provided copyediting services and Dallas Peters, Dallas Peters Design, assisted in graphic design production. Among the staff, Fiatech Project Manager, Sharon Bickford, contributed signicantly to the development of this publication and her efforts are appreciated. Publication of this report is made possible through the contributions by Fiatech members.
Raymond E. Topping, PE Director, Fiatech
PREFACE
Fiatech (www.atech.org) is an industry-led consortium, housed at The University of Texas at Austin that provides global leadership in identifying and accelerating the development, demonstration and deployment of emerging technologies and innovative practices to deliver the highest business value throughout the life cycle of all types of capital projects. Fiatech is member-driven, comprised of approximately 85 companies and partner organizations that include owners and operators from the industrial, power, and retail markets; leading providers of engineering, design, and construction services; software and equipment suppliers and technology providers, research institutes and universities. Fiatech is a clearinghouse for innovative ideas where members can quickly learn about new processes, methods, and materials; but it also collectively funds and executes development, demonstration and deployment projects. Project teams are formed to identify and accelerate the adoption of technologies and systems; demonstration projects are conducted to validate and perfect new approaches or methods; and teams are formed to aid and facilitate the deployment of those breakthrough initiatives that have been identied. This publication was developed at the request of Fiatech members and in cooperation with the POSC Caesar Association, for the benet of the entire capital projects industry.
TABLE OF CONTENTS
INTRODUCTION1
Introduction to ISO 15926 1 ISO 15926 Is Like a Babel Fish 3 About This Book 6 Why We Need ISO 15926 8 The History of ISO 15926 8 How Does ISO 15926 Work? 8 Current Events in the World of ISO 15926 9 Getting Started with ISO 15926 10 Appendices11
CHAPTER 1: WHY WE NEED ISO 15926

The Role of Context in Information Exchange The Value of the ISO 15926 Dictionary A Confederation of Applications Public Extensible Dictionary An Example Project How ISO 15926 Makes Life Easier in the Near Term How ISO 15926 Makes Life Easier in the Long Term
12
13 18 22 27 29 31 36
CHAPTER 2: HISTORY OF ISO 15926
40
How We Use the Internet to Find Information 41 How We Know and Understand Things 42 Open Ways to Store and Exchange Data 44 Markup Languages 46 Evolution of Product Information Standards 48 Summary67
CHAPTER 3: HOW DOES ISO 15926 WORK?

Integration Versus Interoperability The Parts of ISO 15926 Are Like the Parts of Human Speech Putting It All Together Levels of Compliance with ISO 15926 Versus Ambiguity Wouldnt It Be Better if We Agreed on Common Denitions? Why Dont We Use Industry Standard Denitions? Would It Help If I Told You How I Was Using the Data? If We Use the Semantic Web, Couldnt We Automate More of This? Shouldnt We Add Query, Workow, and Security to the Semantic Web?
70
70 74 91 93 95 97 99 101 103
CHAPTER 4: CURRENT EVENTS IN THE WORLD OF ISO 15926

Using ISO 15926 in Production Development of Enabling Infrastructure Continued Development of Standards
105
106 110 113
CHAPTER 5: GETTING STARTED WITH ISO 15926

Key Preparation Implementing ISO 15926 Join Fiatech or the POSC Caesar Association
116
117 118 123
APPENDIX A: THE PARTS OF ISO 15926

ISO 15926
124
124
APPENDIX B: COMPLIANCE WITH ISO 15926

Semantic Precision Representation Technology Referencing Technology Interface Technology Industrial Standardization Subject Matter Scope Metadata Scope Functional Capability
128
129 129 130 131 131 132 132 133
APPENDIX C: EXAMPLES OF DATABASE MAPPING
134
Example Set 1: Lets Just Exchange Raw Data and Figure It Out Together 134 Example Set 2: Wouldnt It Be Better to Agree on Common Denitions? 141 Example Set 3: Why Dont We Use Industry Standard Denitions? 147 Example Set 4: Would It Help if I Told You How I Was Using the data? 151 EMCA156 Using the RDS/WIP 158
APPENDIX D: OTHER RESOURCES

Information Modeling Resources Origin of ISO 15926 Organizations Responsible for ISO 15926 User Groups Other Organizations RDS Browsers Business Interface Denition Guides
160
160 161 161 162 163 164 164
GLOSSARY OF CONCEPTS
167
Articial 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 Abstraction172 Semantic Web Technology 173
INTRODUCTION
Introduction to ISO 15926
If you are new to the concept of information interoperability, you will be forgiven for thinking that ISO 15926 is a new phenomenon. In fact, the search for easy ways to exchange and reuse engineering information stretches back to the mid 1970sled 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 usersheavily represented by the U.S. military and aerospace organizationswere 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 laterwhile 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 authors 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 modication. 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 projects engineering design system (which may be a database or spreadsheet). For quotation, a procurement ofcer assembles several sets of data sheets and sends a set to each bidder. Each bidder will have a sales engineer read the data sheets and enter some of the data values into proprietary software to make a selection, and then compose a quotation and return it to the engineering, procurement, and construction (EPC) contractor. During the design of an instrument, the engineer will usually specify only those properties necessary for operation under process conditions. However, there are many other properties that must be knownwhich 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 vendors quotation. Data sheet turnover to the client will likely be something like an Excel le for each data sheet. After receiving a load of boxes lled with CDs from the EPC contractor, the owner will review each data sheet. Critical data values will be rekeyed into an asset management system. This can take months.
Introduction
The situation is improving. A few years ago engineers would have faxed the data sheets to the vendors, who would manually add their information and fax them back. Now they E-mail editable electronic les back and forth. And more recently, some owner-operators are trying to streamline the nal handover from an EPC contractor by specifying data requirements. However, conguration costs and the lead time required speak to the complexity of the issue. What we need is a way for each participants software to be able to communicate complex information to the other participants without having to know in advance things such as database structure or format. If you have ever read The Hitchhikers Guide to the Galaxy, by Douglas Adams, you will know exactly what we needwe need a Babel sh! In the book, if you wanted to listen to Vogon poetry spoken in the original dialect you would use a Babel sh.
The Babel sh would listen to the Vogon speaking, and then rearrange the syntax and translate all of the words on the y. ISO 15926 acts like a Babel sh by acting as an interpreter between two otherwise incompatible systems. Lets 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 projects engineering design system (which may be a database or spreadsheet).
However, thereafter tools written to support the ISO 15926 standard extract the relevant information automatically. For quotation, a procurement ofcer will expose the Request for Quotation on his companys public (or secured) ISO 15926 interface and then send a link to the bidders. By connecting to the EPC contractors ISO 15926 interface, each vendor will pull in the relevant information for each instrument. At this point, the vendor has a choice. He can have a human sales engineer read the information and manually make decisions in the same manner we use today. However, because it is in ISO 15926 format the instrument information will be rich enough that analysis, decisions, and composition of a preliminary quotation will be able to be done by a computer program. In this case, the sales engineer will only have to review the quotation before submitting the bid to the EPC contractor. After selecting the winning bidder, the engineer will point his engineering design system to the vendors 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 contractors ISO 15926 interface.
Introduction
The owner will open the link to the engineers interface and import the information. You can see that if we use tools that support ISO 15926 protocols we are removing many opportunities for human error. Thus, in addition to being able to transfer information faster by removing the labor-intensive tasks the entire process will be more reliable. (At the same time, the routine parts of the sales engineers job are removed leaving more time for more innovative tasks and talking to customers.) One of the reasons ISO 15926 will make it easier to share information is that it is worldwide. If everyone uses a common standard, a number of things happen. We can exchange information without having to know anything about one anothers data storage conguration. Information can be transferred directly from machine to machine without having to be rekeyed. The information can be transferred with high delity. 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 sh (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 anothers data storage format beforehand. During design, vendor and EPC contractor software will be able to connect to each other and thus passing information back and forth will be much easier. Information turnover from EPC contractor to owner will be a non-issue. Owners will be able to receive the plant data by connecting to the EPC contractors Babel sh (the ISO 15926 interface) and then store it in their own format. After information turnover, any of the owners 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, lets look at three metaphors.
ISO 15926 Is Like a Babel Fish

We have already mentioned The Hitchhikers Guide to the Galaxy. In it, Arthur Dent hitches a ride on a passing Vogon spaceship just moments before the spaceship blows Earth to smithereens to make way for an interstellar bypass. When he is discovered by a Vogon, Arthur is given a Babel sh to put in his ear. The Babel sh enables Arthur to understand what the Vogon is saying. From the book:
The Babel sh forms a symbiotic relationship with the person who carries it in his ear. The Babel sh feeds on the brain wave energy from around its host. It
Introduction
absorbs the unconscious mental frequencies from this energy, more or less, as food. Its excrement is a so-called telepathic matrix of conscious thought frequencies combined with the nerve signals from the speech centers of the brain which supplied them, which is picked up by the mind of the host. Basically, then, if you stick a Babel sh in your ear, you can instantly understand anything said to you in any language.
Bringing this metaphor into the eld of plant design, ISO 15926 is similar to a Babel sh in that it translates the descriptions of plant objects from one companys 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 sh is a pretty good one, but there is a slight difference. The Babel sh 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 rst 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 briey the middle layer is what makes it all work. Each organizations Babel sh (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 dont 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 experiencebut between machines. For instance, if you want to look at the web page of a pump manufacturer you dont 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 nds will be encoded in HTML. Of course, it will beif the manufacturer wants to get any business through the web pagebecause HTML is the standard format of the World Wide Web. In addition, it does not matter which browser you use. Internet Explorer, Firefox, Safari, Opera, and Netscape are all written to understand HTML. Imagine the hassle if you rst 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 rst place because no one else would do it either. This metaphor does a good job of describing what the average user will have to know about ISO 15926 as well. In the same way that most people who use the World Wide Web do not need to know about HTML, most users of ISO 15926 will not have to know about it to exchange information. When ISO 15926 is mature, it will simply be built into the software we will all use. Engineers will be able to exchange information much more easily than they do now, and very few of them will need to know that the standard exists. On the other hand, many web sites today are actually written in HTML. This metaphor implies
Introduction
that a large proportion of plant information will actually be stored in an ISO 15926-compliant data structure. Although this is certainly possible, it will probably not be the case. Most companies will maintain their plant information in the proprietary format they currently use. Instead, they will write a public interface to render the information in ISO 15926 format when a business partner asks for it. In this regard, ISO 15926 is more like the case today whereby a database is exposed to the World Wide Web. When a user queries the database (via her web browser), a program dynamically searches the database and renders the results in HTML on the y. There is another similarity that may appeal to your geeky side. HTML and ISO 15926 are standards that were developed along similar trajectories. Although the underlying infrastructure that enabled the Web started to form in the last quarter of the twentieth century, most of us only discovered it 20 years ago. At rst there was some controversy as we speculated about its possibilities. Some of the ideas caught on and some didnt, but over time surng 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 nding out about ISO 15926even though the standards that led to it rst 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 highwaymoving 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 difcult 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 rst translate the words and sentence structure from Cantonese to English. When you heard me speak, you would translate the words and sentence structure from English to Mandarin and (hopefully) understand what I said.
Introduction
Use a mental dictionary to translate Cantonese to English
Hello
Use a mental dictionary to translate English to Mandarin
Hello
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 y. Similarly, organizations that use ISO 15926 to communicate with each other can continue to use proprietary systems internally. This is a good metaphor in another way as well. The complexity of managing the call is hidden from cell phone users. You and I can contact each other by simply calling each others cell phone number. You dont have to call a different number if I am away from my ofce. I dont have to use a different protocol if you have a digital phone or an analog phone. You dont have to know if I am at home or at ball game. The cellular network gures 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 15926it will simply be built into whatever computer system they are using. To extend the cell phone metaphor, it will be as if an intelligent English translator is built into both cell phones. I would speak my native Cantonese into my phone and you would hear your native Mandarin in yours.
About This Book

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

This book is divided into ve main chapters and several appendices. Why We Need ISO 15926 The History of ISO 15926 How Does ISO 15926 Work? Current Events in the World of ISO 15926 Getting Started with ISO 15926 Appendices Glossary
Introduction
Why We Need ISO 15926

Traditional ways of exchanging and reusing information all involve some variant of having someone read one document and then decide which parts to transcribe to a different document. This is true whether we are moving a single value from one data sheet to another or mapping entire databases together. Even with modern computer technology, we still rely on highly skilled people to interpret information and to discern which data values are important. For this we rely on a surprising amount of context. For instance, when we look at a data sheet we rely on visual cues and our experience. When we map databases together, we deal with attribute names that are usually inadequate in themselves to make ne distinctions between similar terms. To understand what our data means, we need more information than is contained in the data itself. This affects us whenever we attempt to exchange information. An obvious large information exchange is the handover phase of a project. Even though a fully electronic handover is quite possible today, the documents that are handed over are often still formatted for humans. Currently, when we hand over information we still have to think about how it is to be accomplished. This adds friction, making many exchanges uneconomic. When ISO 15926 is mature, the mechanics of information exchange will fade into the backgroundallowing more exchanges to take place economically.
The History of ISO 15926

The reason information exchange, as envisioned by ISO 15926, is possible now is because of the convergences of four areas of study. The study of how we know things, ontology, gives us techniques for embedding meaning into data. The Semantic Web gives us the tools to do so. Open ways of encoding data make it practical to do so. But the most important is the evolution of product information. With the advent of CAD software in the late 1970s, we have continually played the role of Oliver Twist: Please sir! Can I have more? At rst, all we wanted was to be able to exchange CAD drawings without having to redraw them and got CAD exchange standards such as the Initial Graphics Exchange Standard (IGES). Then we wanted the product information that is behind the drawings in many manufacturing systems and got a standard called STEP, which we will become very familiar with in the coming chapters. Later, as we tried to apply the principles of STEP to long-life process plants STEP itself evolved into ISO 15926. The core of ISO 15926, the data model (called Part 2), and the dictionary (called Part 4) have been developed in the heat of battle on several large, world-class projects. Dictionary-level information exchange is now routine. We are poised for an even greater increase in productivity with the development of techniques for embedding meaning into our information exchanges.
How Does ISO 15926 Work?

Your computer can talk to my computer and neither of us has to know anything about each others systems beforehand sounds somewhat magical. Readers are excused for being somewhat skeptical. But when you consider what actually needs to be exchanged the claim of ISO 15926 becomes more believable. The engineers, fabricators, constructors, and plant operators
Introduction
who need to exchange information all work with the same physical objectsjust in different ways. Each job function needs different information about the same object. For instance, engineers need to know the size envelope and functional performance; fabricators need to know the material and fabrication methods; constructors need to know the mass, envelope, and delivery; and operators need to know how to maintain it and where the spare parts are. There is some overlap, but because the computer system each uses is optimized for particular job functions it is not surprising that the computer systems cannot understand each other even if they actually contain the same information. What ISO 15926 does is to capture a view of everyones 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 rst learn the names of objects they are familiar with, essentially building a new dictionary. Then they will learn to master a new way of expressing ideas, which is learning new rules of grammar. While learning the new language, they will practice writing it on some type of media (such as a whiteboard, paper, or, for the sake of argument, a stone sculpture). Eventually, if they master the new language well enough and others seek them out they may need a way to regulate access. The parts of ISO 15926 are like the parts of human speech. Part 2 is the data model equivalent to the rules of grammar, and Part 4 is the reference library, equivalent to the dictionary. When any two people use the same rules of grammar and use the same dictionary, they can communicate freely. Similarly, when two machines encode an information exchange using Parts 2 and 4 they can communicate freely. This is the core of ISO 15926. Part 7 contains what are called templates, and is like a phrase book that allows new users to construct a meaningful sentence a bit sooner. Part 8 is like the writing media, and Part 9 is like a web site or the postal service.
Current Events in the World of ISO 15926

ISO 15926 is being used around the world more every year. Parts of ISO 15926 are being used in real projects, development of infrastructure to support ISO 15926 information exchange is ongoing, the standards themselves are continuing to be developed, and educational materials are being created.
Plant Operations
The Norwegian Continental Shelf is one of the major oil-producing regions in the world. The harsh environment has led to a strong need to automate information exchanges to and from offshore facilities. Integrated Operations in the High North (IOHN) is a multi-year initiative to implement this, combining the efforts of all operators in the area. ISO 15926 is part of the data layer. The safe start-up, operation, and maintenance of an operating plant is often limited by a lack of early information about plant equipment and controls. A large bitumen upgrader, planned for startup in Canada in 2015, is part of a pilot project to develop strategies to improve information handover. The Operations and Maintenance SIG (O&M SIG) of Fiatech and the POSC Caesar Association (PCA) are reviewing all relevant information standards, including ISO 15926, and will use them to develop best work practices for information creation and handover.
Introduction
Development of Enabling Infrastructure

One aspect of information exchanges, as envisioned by ISO 15926, is that the denitions of terminology be publicly accessible in real time during the exchange. This will allow the participants to validate terms, which will remove ambiguity and reduce costs. Until now this has not been possible for production work due to lack of facilities. The Joint Operational Reference Data (JORD) project is developing the infrastructure and funding to bring a public reference data service (RDS) into operation. It builds on several years of experience in operating an RDS that supported standards development work. We have used dictionary-level information exchange for years using ISO 15926 Part 4. This works well in high-value situations that can afford the brute-force approach of understanding equivalent information objects on each side of the transaction and mapping them together. But with the pace of business increasing we need to be able to exchange information easier without having to do so much preparation. To do this we will have to use the full specication of ISO 15926. The iRING user group is developing tools, available free of charge with an open-source license, to implement ISO 15926 parts 7, 8, and 9. The tools will more or less clip on to the side of commercial software to allow information exchange between any similarly equipped software.
Continued Development of Standards

The Geometry Special Interest Group (Geometry SIG) of Fiatech and PCA is developing a reference library for the geometrical shapes used in 3D modeling software. Current tools for exchanging graphics strip out all of the meaning. (This means we can exchange the surfaces of plant objects but not their identity.) The geometrical reference library will be issued as ISO 15926 Part 3, which will allow us to exchange graphics as easily as we exchange other data. One barrier to the wide use of ISO 15926 is that best practices for using Part 7 templates are not yet common knowledge. The Instrument Special Interest Group (Instrument SIG) of Fiatech and PCA is creating recommended templates for describing industrial instrumentation. Because the management of instrumentation is crucial for the safe and protable 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 Fiatechs 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 Institutes Standard HI 50.7-2010 for Electronic Data Exchange for Pumping Equipment have been brought together. HI 50.7 is a dictionary of data elds from many wellknown standards along with the AEX schema. The EELCAT project has recently examined the two standards and has demonstrated how they can be further harmonized with ISO 15926.
Getting Started with ISO 15926

With any new technology, there is uncertainty about what can be realistically accomplished. Implementing ISO 15926 is easily within reach of most organizations, probably without having to hire additional staff. At the introductory level, implementing ISO 15926 is similar to traditional methods of exporting information from one application and importing it into another.
Introduction
10
Open-source and commercial tools exist to assist in both dictionary mapping at the introductory level and the more advanced use of ISO 15926 Parts 7, 8, and 9.
Appendices
The preceding fullls the promise of an introduction to ISO 15926. For those who wish to know a bit more, we have included several appendices: Appendix A: The Parts of ISO 15926 Appendix B: Compliance with ISO 15926 Appendix C: Examples of Database Mapping Appendix D: Other Resources Glossary of Concepts: Contains extended explanations of key concepts, including key terminology
Introduction
11
CHAPTER 1: WHY WE NEED ISO 15926

It is difcult 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 partners 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 signicant part of designing, building, and operating capital assets involves transferring and accessing information about those assets. In its oft-cited 2004 report Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry, the National Institute of Standards and Technology (NIST) reported claims of some companies that 40 percent of engineering time was spent nding and verifying information. Overall, the study showed that the lack of interoperability among computer-aided design (CAD), engineering, and other software systems costs the American capital projects industry more than $15 billion every year.1 ISO 15926 makes exchanging information between applications easier in two ways. First, when your information exchanges go beyond manually rekeying data or using point-to-point custom mapping (which we discuss shortly) you need to create some type of data dictionary containing denitions of all objects in your facilityalong with their attributes. If your organization is sufciently large, this requires a signicant effort. Instead of developing your own dictionary, ISO 15926 offers a dictionary2 that you can use free of charge. Because the ISO 15926 dictionary has been developed by a great number of people from many industries in many parts of the world, there is a high probability that the denitions 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 specication of ISO 15926, we can make information exchanges easier by essentially building the context of the information into the information itself. When we model the information, we can capture the precise meaning of each term and embed it with the term. This makes it easier for machines to talk directly to each other because implied meanings that participants are just expected to know are eliminated (or at least minimized). These two issues are intertwined. To fully understand the value of simply being able to use an existing data dictionary, instead of having to develop one from scratch, we will rst discuss the sources of information exchange costs. This will leads to a discussion of context and
1.
The report is available online. Search for Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry.
2. Truth in advertising: Data exchange in the manner envisioned by ISO 15926 requires more than just a dictionary. We are simply starting with a description of how the dictionary component works as a way of easing into the topic.
Chapter 1
12
what it means in information exchanges. After understanding the role of context, we will return to the way we manage information exchange today. We will discus the way small, ad-hoc manual exchanges can develop into organization-wide networks of linked applications. The value of the simple existence of ISO 15926 will be apparent when we discuss the issues of managing this organization-wide network. We conclude with some examples of information ows 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 nd 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 gure it out.
Fig. 1.1 Putting information in a bag.
When we encode information using the full specication of ISO 15926 (including all of the components we will discuss later), we include enough context that other ISO 15926enabled tools will clearly understand what we mean (Figure 1.2). We no longer have to know anything about the partners with whom we exchange information.
3. The information in a bag diagrams are courtesy of Robin Benjamins.
Chapter 1
13
Fig 1.2 Putting information in an ISO 15926 bag.
When your humble author started his career in plant design, computers were not commonly used by designers and engineers. Drafting was done by pencil on paper. Specications 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, nd the value to be transferred, and then write it by hand on the target document. If the target document was something like a specication, 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 specications and drawings, sort them into some logical order, perhaps bind them into books, and move them to the new location. Data turnover to the client at the end of a large project was similar to the last scene of the movie Raiders of the Lost Ark. In that scene a forklift carried a wooden box down a long aisle of identical wooden boxes and put it on one of the piles, something like that depicted in Figure 1.3. In the real world, it sometimes took years for the owner to review all of the boxes and categorize the binders of information.
Fig 1.3 Data handover the old way.
Chapter 1
14
No one really liked this (as in I really liked that piece of chocolate cake, may I have another!), but that was just the way it was. Everyone just built such manual tasks into their plans. Things started to change when computers made their way into the design ofce. 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 les burned onto more DVDs. These days, when the owner receives the material it is physically easier to sort through boxes lled with DVDs than to sort through boxes lled 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 owners systemand 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 engineers activities still involve nding information and manually transferring it from one document to another. For instance, after the engineer chooses, say, an instrument from a manufacturers catalog the only practical way to record the information about the instrument is to read the manufacturers data, interpret it to decide which of the data values to transcribe, and then gure 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 calculationsuch 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 nd information to understand the precise meaning of the information. Earlier we dened context as the rules and jargon of our trade. Design engineers learn these rules and jargon by a combination of education and experience. For an example of how we rely on context, suppose that you have to transfer information from one data sheet to another and you see this: 1034 This means nothing. So, you back up and look for more context. Pressure 1034
Okay, so you know a bit morebut still nothing usable. So, you back up again. Pressure: Pressure Units: 1034 kPa
Now you expect other values to be in SI units, but you still really do not know what is going on. So, you back up some more.
Chapter 1
15
Seal Flush Pressure: Pressure Units: 1034 kPa
You still have questions, so you continue to back up. Tag No: Service: Seal Flush Pressure: Pressure Units: 1034 kPa P-101 Chemical Injection to D-101
Now you are getting a clearer picture. When you back all the way up and read the entire data sheet you can nally put the initial value, 1034, into context. Centrifugal Pump Data Sheet Client: Tag No: Service: Seal Flush Pressure: Pressure Units: 1034 kPa ABC Chemical Company P-101 Chemical Injection to D-101
Even with such a trivial example, without context we are lost. Experienced engineers may exclaim at this point But this is the way design is done. You have to consider the entire data sheet to understand a particular term! That is the point: If we want to use machines to transfer information to other machines, we want the information to be self-describing.
Chapter 1
16
The Data Sheet Problem

Consider a more realistic example of selecting and specifying a centrifugal pump. After selecting the proper make and model, the mechanical engineer has the pleasant task of guring out which data values to transfer from the manufacturers data sheet to the owners data sheet. Figure 1.4 shows a small portion of both data sheets.
Different Name CONDITIONS OF SERVICE, EACH PUMP Normal Flow Rated Flow Disch. Press. kPag Temperature C Suct. Press. Max. kPag Specific Gravity Differential Pressure kPag Vapor Pressure kPag Differential Head m Viscosity NPSH Available m Corr./Erosion Caused By Corrosion Allowence mm Cold Start Temp. C @Sp. Gr. & Viscosity CONSTRUCTION Nozzles Size Rating Facings Suction Discharge Different Name Same Definition Same Definition
Rated kPag
Location
Same Definition Different Definition
Convert to Imperial OPERATING CONDITIONS Rated Max. Normal Min.
Different Definition Different Definition
Convert to Metric
Capacity (gpm) Suction (psig) Discharge (psig) Diff. Press. (psig) Diff. Head (ft) Power (hp)
@ Minimum S. G.
Rated Max. Normal Min. Op. Time (hr/yr) NPSH Avail. (ft) System Design Stand Alone 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
Fig 1.4 Comparison of two data sheets.
The most notable difference is that one data sheet expects metric units, whereas the other expects Imperial units. But beyond that the data sheets are organized differently: the data are grouped differently and the groups are arranged differently. These two excerpts only have eight data spots in common. However, looking closer we can see that of the eight spots only three are obviously identical: Discharge Pressure Rated Suction Pressure Differential Pressure
Chapter 1
17
The rest require some interpretation: Metric Data Sheet Normal Flow Rated Flow Max. kPag Differential Head NPSH Available Imperial Data Sheet Capacity: Normal Capacity: Rated Suction: Max. Diff. Head: Rated NPSH Avail.: Rated Comments Probably the same Probably the same No data entry spot Possibly the same Possibly the same
Most mechanical engineers with a little experience will have no trouble guring everything out because they have the rest of the project documents, and perhaps have experience with the pump manufacturer. Again, that is the point. We need humans to guide even what seem on the surface simple transcription tasks because our work practices depend to a great degree on context. However, when machines start talking directly to other machines the problem of implied meaning based on context becomes a serious barrier. The reason information exchange works these days is because we exchange entire sets of data (for instance, a complete data sheet) in which the context is preserved. The disadvantage, however, is precisely that: we have to exchange entire sets of data and we must have humans interpret them item by item. What we really want is to be able to let machines exchange information directly without having to rely on context to retain the correct meaning. What we really need is a cut-and-paste tool for plant information. We want to be able to just cut it from that database over there and paste it to this database over here. However, its not that simple. The rst 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 rst know enough about the data sheets and underlying databases to know which values are required, which values can be ignored, and whether or not something is missing. The second reason is, as we have seen in this example, we cannot rely on the name of the attributes. Even when attributes in two databases have the same name, we cannot be sure there are no subtle differences in their meaning. We need a human expert to conrm that the attributes match. These actions are trivial if you have the right context. We have many thousands of design engineers doing this all day, every day, and generally they are good at it. However, we rely so much on context to convey meaning that we cannot trust machines to make the right decisions on their own. Finally, this is all carried out in the context of the same written language. What would happen if the project were engineered in English but the client wanted all of his data sheets turned over in Russian?
The Value of the ISO 15926 Dictionary

When we want to exchange information between two software applications, the traditional way is to map the respective databases together. We preserve the context by manually examining the terms in each database to determine which are equivalent. Directly mapping two applications together is often the easiest short-term solution.
Chapter 1
18
Lets 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 lista list of all line numbers and their critical attributes. Your rst job, then, is to simply get the design engineers line list into a form you are used to dealing with; that is, your companys 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 engineers design software into your construction software automatically. After all, the design engineer did not (in this day and age) have a secretary type the line list onto a piece of paper with a typewriter and fax it to you. It almost certainly exists in an electronic database somewhere. It is in the design engineers 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, arent they?)
Articial intelligence is the study of how to make real computers act like the ones in the movies.4
In a perfect world, everyone developing an application for some part of plant design would use the same column names and ensure that the meanings of the content of the columns were the same. (In database jargon, the schemas would be the same.) Figure 1.5 shows what this would look like.
Engineering Application Line Table
tag_no dia len temp press ifc
tag_no
dia
len
temp
press
ifc
Line Table
Construction Application
Fig 1.5 A perfect world.
4. Port 2000 Newsletter: The Information Technology Newsletter for Port Washington Educators, December 1996.
Chapter 1
19
Of course, in the real world things seldom work out so nicely. Even in the rather small scope of a line list (where there the lexical scope is only a dozen or so terms) there is usually ambiguity. For instance, in Figure 1.6 two columns have names that do not match. One of them, tag_no in the engineering application, is most probably equivalent to the id column in the construction application. But what about the column cl in the construction application? For that matter, what does temp really mean? Could it mean Temporary? It is possible. It is not unheard of to have temporary lines erected for commissioning, which are then removed after a plant has been put in production. In addition, if you are being a bit paranoid (and if you have to sign off on the actual hydrostatic test pressure you better be at least a bit paranoid) what do you make of press? It almost certainly means pressure, but what type of pressure? Operating pressure? Maximum allowable working pressure? Design pressure?
? id
? dia
? cl
? temp press ifc
Line 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. Fortunately, the lexical scope of a line list is only a couple dozen terms. To determine if temp means temperature or temporary you will have to look at a few rows of data. If the data values are y/n, or 0/1, it points to temporary. However, if the data values are numbers in the range of, say, 50 to 1,500 it probably means temperature. The column name press will take a bit longer. You will have to look for clues in other documents and use your engineering judgment to determine which type of pressure it is. You may have to contact the design engineer. What looked fairly simple just a while ago is looking a bit more complex.
Chapter 1
20
There is always an easy solution to every human problem neat, plausible, and wrong.5
If you only have to import the data once, one option is to simply copy the information column by column. However, if you have to import information from the engineering application several times you will want to have someone congure a custom mapping application. In Figure 1.7, someone has examined the data coming from the engineering application and determined which columns matched those of your construction application. In software development jargon, they have mapped the databases together. The red box represents software that uses the map to transfer information from the design application to the construction application. (An interesting side note is that you may not have to actually transfer very much. For instance, if you knew that both applications expect pipe sizes based on ASME B36.10M you would only have to transfer numerical digitssuch as 6 or 12.)
Custom Map
tag_no id
dia dia
len cl
temp temp
press press
ifc ifc
id
dia
cl
temp
press
ifc
Line Table
Fig 1.7 A custom solution.
So far in this simple example, writing the mapping software would be relatively easy. But the real world is usually a bit more complex. One common problem, from the point of view of a lonely construction engineer on a remote project a long way from help, is that the data is often mangled across many elds. Take, for example, a simple line number such as what might be represented by the column tag_no. As a construction engineer, you are likely to look at a line number as a label representing the name of this run of pipe, from here to there. You expect the line number to be one string of text, something like: Line Number 150-HCL-250-1C200-35 However, the design engineer needs to be able to sort and lter on the pieces. Her idea of a line number probably looks more like this:
5. H. L. Mencken, 1917 (Variously attributed to Albert Einstein, Winston Churchill and others.)
Chapter 1
21
Line Number Area 150 Fluid Code HCL Nom Dia 250 Service Class 1C200 Insulation Thk 35
In fact, it may not even be that nice. It could be something like this: Area 150 WBS 7395-132 Service Class 1C200 Nom Dia 250 Fluid Code HCL Testing 3 Insulation Thk 35
Many engineering procurement and construction (EPC) contractors have proprietary work processes for plant design supported with custom software. It is quite possible that the database the design engineer used to create your line list has the columns in a different order, and with other columns mixed in. The line list sent to you could have been created with reportwriting software that had been congured 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 gure out all the pieces and to put Humpty Dumpty back together for your construction application. It is a good thing that the lexical scope of a line list is only a few dozen terms!
A Confederation of Applications
If linking the rst two applications together works out well, you may be tempted to link in another one. Figure 1.8 shows how the engineering application might be mapped to a procurement application with a second custom database map.
Custom Map
tag_no id
dia dia
len cl
temp temp
press press
ifc ifc
Custom Map
tag_no tag
dia dia
len cl
temp
press
ifc ifc
id
dia
cl
temp
press
ifc
tag
dia
len
code
price
ifc
Line Table
Line Table
Procurement Application
Fig 1.8 A confederation of applications.
This is the beginning of what might be called a confederation of applications whereby many applications get information from each other, with custom-built database maps between each
Chapter 1
22
pair of applications. Conceivably, you could link all of the construction applications for your project together in this manner to form an enterprise-wide solution (Figure 1.9).
Fig 1.9 An enterprise-wide solution.
If you managed to do all of this before your construction project was nished, you would have at least a short period of relative bliss. Instead of having to manually export a list from one application, massage it a bit, perhaps do a unit conversion or two, and then import it into another application all you have to do is push a button. The advantage, in terms of lower labor costs and higher reliability, is obvious. In addition, if mapping databases together point to point on a project is good why not connect all applications in your company together the same way? Of course, many organizations do this. Although there may not be a theoretical limit to the number of applications that can be connected in this way, there is a practical limit. Every piece of software you link together is subject to change. For the most part, this is good. As hardware becomes more powerful, we can make software do more things. However, the natural cost of this is that eventually the database structure of an application will change. If you use point-to-point maps to link databases directly together, the link will break when either of the databases changes. If you have many applications daisy-chained together, they may all go down like a row of dominos. The practical reality of this approach is short lifetimes, high maintenance, and having to relearn an applications 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 rst approach is some variation of If it aint broke, dont x it! Here an organization deliberately stops upgrading software even when new versions are released. The immediate
Chapter 1
23
benet is stability of information exchanges. Personnel can get on with whatever their business is without having to continually relearn old skills. Instead of having to spend all of their time xing 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 entrenchedtied 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.
Youve got to know when to hold em, know when to fold em6
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 efcient as possible. Under this approach, as applications in the confederation evolve and the maps break someone will be there to x 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 inefcient information transfer is bad information. As with the rst approach, we have developed good ways to handle maintenance. There is an entire business segment devoted entirely to what we call middleware to make creating and maintaining custom point-to-point maps easier and more reliable. Still, there will come a time when maintenance is a large cost. There is another solution, but it is a bit more work up front. Instead of making individual pointto-point maps, an organization could make a dictionary of terms for all of the applications it uses. Under this approach, we study all of the software the organization uses and decide on the meaning of every term. Then when we link two applications we do not map them directly together but map each to the standard dictionary, as indicated in Figure 1.10.
6. A line from The Gambler, a song by popular Country and Western singer Kenny Rogers.
Chapter 1
24

Map to Common Dictionary
tag_no szTag szTag id
dia dDia dDia dia
len dLen dLen cl
temp dTemp dTemp temp
press dPress dPress press
ifc dateIFC dateIFC ifc
Map from Common Dictionary
id
dia
cl
temp
press
ifc
Line Table
Fig 1.10 A common dictionary of database denitions.
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 denitions 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 tag_no dia len temp press ifc Dictionary ID szTag dDia dLen dTemp dPress dateIFC Description Tag Number of a plant object Nominal Diameter per ASME/ANSI B36.10 Pressure Class per ASME/ANSI B16.10 Normal Operating Temperature Normal Operating Pressure Issued for Construction Date degF psig yyyymmdd Units
Similarly, the developer of the construction application uses the same dictionary and determines the appropriate denitions that apply to the columns in her database. Construction App id dia cl Dictionary ID Description szTag dDia dLen Tag Number of a plant object Nominal Diameter per ASME/ANSI B36.10 Pressure Class per ASME/ANSI B16.10 Units
Chapter 1
25
temp press ifc
dTemp dPress dateIFC
Normal Operating Temperature Normal Operating Pressure Issued for Construction Date
degF psig 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 applicationbeyond, of course, knowing that it is the source of certain input data. Both of the developers are now free to modify their respective applications in any manner, including massive changes to their data structureas 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 others application because they know the precise meaning of the dictionary term they are mapped to. We call this semantic precision. Of course, there is a cost to developing a common dictionary. Someone has to herd the cats together to decide on the meaning of each term and what to call them. This is not trivial. Many people, each with different interests and agendas, have to look at the applications in questionpossibly having to make ne 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 ofcer needs information from the engineering application to use in a procurement application instead of examining the content of the engineering applications database all a software developer has to do is consult the dictionary and determine the values he wants to use. Procurement App tag dia len ifc Dictionary ID szTag dDia dLen dateIFC Description Tag Number of a plant object Nominal Diameter per ASME/ANSI B36.10 Pressure Class per ASME/ANSI B16.10 Issued for Construction Date yyyymmdd Units
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 rst mapping exercise take a bit longer, but the benets are clear. The second (and third, and fourth) mapping exercise is almost free. When the developer of the procurement application wanted to import line list information from the engineering
Chapter 1
26
application, he simply used the appropriate denitions from the common dictionary. The developer of the engineering application might not have even known this was happening. If the common dictionary is maintained, it is robust. If a new application in the confederation needs another type of pressure, for instance, the keepers of the dictionary can simply add it to the standard. The new applications will use the new denition, but none of the existing maps between existing applications will break.
szTag tag
dDia dia
dLen len
dateIFC ifc
tag
dia
len
code
price
ifc
Line Table
Procurement Application
Fig 1.11 A reuse scenario.
Again, there is a cost. As an organization grows in size and adds more members to its confederation of applications, managing the common dictionary will require signicant 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 organizationseach having its own common dictionarydecide to merge, which of the two dictionaries do they keep? Or do they make a third to map between them? Likewise, if two such organizations want to collaborate on a joint venture they will have to harmonize their dictionaries. Today, there is no practical alternative to each organization maintaining its own dictionaryduplicating 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 specication for a reference data library (RDL). The following is a high-level view of how it will work.
Public Extensible Dictionary

Figure 1.12 shows the same engineering application and construction application where somebody decides that they need to include a new attribute, Widget Color, in the line list. (Widget Color may have been in the engineering application all along, or it could have been added to support a particular project for which Widget Color was important.) Note that the developer of the engineering application has decided to use the attribute name wcolor to describe the color of the widgets, whereas the developer of the construction application wants to use the attribute name color. This is okay because they both intend to use a database map for the information exchange and therefore do not need to use the same attribute name.
Chapter 1
27

tag_no dia len temp press ifc wcolor
Map to Common Dictionary
tag_no szTag szTag id
dia dDia dDia dia
len dLen dLen cl
temp dTemp dTemp temp
press dPress dPress press
ifc dateIFC dateIFC ifc
wcolor oColor1 oColor1 color
New Definition
N e w D e fin itio n
Industry Reference Data
id
dia
cl
temp
press
ifc
color
Line Table
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 developeragain, independent of the othercreates 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 congure their own half of the database map. Indeed, the two developers could have been on different continentseach speaking a different language. Thus, we are now back to the rst benet 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 rst published, new technology would undoubtedly require new terminology. So, another requirement for the ISO 15926 data dictionary is that it be able to handle change. To handle change, the developers of ISO 15926 envision a library that will allow anyone (perhaps with the requirement of a bit of training rst) to add new terms. A pilot project, called the RDS/WIP (Reference Data Service/Work in Progress), is in operationsufcient to handle research needs. One of the current development efforts of ISO 15926 is to create an industrialscale reference data library. With a fully functioning, publically available RDS we will enable organic growth. Each organi-
7.
Truth in advertising: ISO 15926 does not intend to have a complete data dictionary for all of life, the universe, and everything. It contains an initial dictionary and species how to extend it.
Chapter 1
28
zation will use it to further their own private interests, but the result will be an expanded RDS for everyone to use.
An Example Project
Everyone can see the value of having all participants in a project able to exchange information with one another directly from database to database. On a typical fast-tracked project, however, there is no time for participants to map their software applications to each others 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 justies a custom data mapping project, is between an EPC contractor designing a capital asset and the owner. Some owners realize that the handover of asset information is a bottleneck to efcient startup and are increasingly specifying information standards and transfer protocols in advance as a condition of contract award. But one only needs to look at recent examples of this type of thing to verify that such an exercise is expensive and time consuming. However, if all participants in plant design, construction, and operation map their databases and congure their software to comply with an industry standard the time constraint is removed. They no longer have to design and implement database mapping within the window of opportunity of one project. Vendors are able to bid on more projects. EPC contractors are able to entertain more bidders. Owners can mandate more stringent standards for information turnover without limiting the eld of participants.
Many Project Participants

All project participants benet from mapping their software applications to be able to talk to one another. However, the sheer number of pairs of participants makes doing so prohibitive. The owner has it the worst because one way or another it will have to pay for all mapping exercises on its project. Even if all information an owner receives is funneled through one EPC, all participants will embed the costs of database mapping in their prices. Figure 1.13 is a diagram showing what might be a moderately large project. There are two engineers, three construction contractors, and one owner. The owner has two preferred suppliers it wants everyone to deal with. There are ve suppliers between the two engineers, and ve suppliers between the three construction contractors.
Chapter 1
29
V 02 45
44 43
V 01 27
28 19 EPC 2 26 11 25 12 24 13 15 2 EPC 1 1 Owner 17 18 3 22 14 V 10 20 21 33 38 V 11 4 37 42 41 7 32 Const 2 Const 1 29 30 34 31 35 36 V 20 V 21 V 22
V 03
V 04
10 9
23
16
5 6 Const 3 39 40 V 30 V 31
V 05
Fig 1.13 One owner, two engineers, and three constructors.
Overall, there are 18 players with 45 different connections between them. Remember that each colored line in Figure 1.13 represents a separate mapping project involving hundreds or, in the case of the EPC contractor-to-owner transfer, thousands of data-point maps. Of course, no one would ever do this. Even if the owner were willing to pay for all custom database maps (either explicitly or built into the prices), the speed with which the maps would have to be created would be prohibitive. Once an owner signs an agreement to begin detailed engineering, there is no time to spare. The requirement that all bidders agree to a database mapping exercise before submitting bids delays a project signicantly. Wouldnt it be nice if the whole world would agree on a common manner of describing plant objects and a common set of denitions? 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 onceever.
We Need a Babel Fish

To reuse a metaphor, we need a Babel sh (Figure 1.14) to translate information from one company to another. Fortunately, ISO 15926 acts very much like a Babel sh. Each company creates its own ISO 15926 interface and makes it available to its business partners. Each company maps its own database (or at any rate, those portions of its database it wishes to publish to the project participants) to the ISO 15926 standard, and opens it to its partners. Each company creates an application that can access the interfaces of its business partners.
Chapter 1
30
F EPC 1
F Const 3
Fig 1.14 Everyone needs a Babel sh.
After that, the only question you have to ask of a supplier (or engineer, or construction contractor) is What is the URL of your interface? Figure 1.15 shows how project data exchanges might be congured using ISO 15926. The small yellow circles are ISO 15926 interfaces that can range from e-mailing a neutral le 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 exchangein much the same way some organizations today hire an outside organization to manage their Internet web pages.
V 01 V 02 V 03 V 04 EPC 2 V 10 V 11
Const 1 Data Broker 2
V 20 V 21 V 22
ISO 15926
Const 2
Data Broker 1 V 05
EPC 1
V 30 Const 3 Owner V 31
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 transcription errors. Organizations are able to keep their proprietary systems while exchanging information with business partners in a manner their business partners can understand. Because
Chapter 1
31
information has a standard representation, some exchanges can be automated. The following examples show how ISO 15926 works in realistic project situations.
Project Design
To mitigate the time delay between receiving project documents from an EPC contractor and getting the relevant information entered into its document control systems and operations and its maintenance systems, an owner may wish to specify in advance the precise nature of the data handover. Unless the EPC contractor has worked for the owner previously, there will be a delay while the EPC congures its engineering systems to comply with data handover requestsand the costs of doing so will be borne by the owner either explicitly or embedded into the fees. When ISO 15926 is mature, this will all change. As soon as the owner determines that the EPC contractor can hand over the project data following the ISO 15926 protocols, no one will have to give data handover any more thought. Project participants will be able to simply get on with design. In addition to not having to spend time negotiating handover up front, any information exchanges during the project design (Figure 1.16)such as between EPC contractors and vendors, between the EPC contractors themselves, and to the ownerwill be easier.
V 10 V 11
EPC 2
ISO 15926
EPC 1
Owner
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 inquirywhich can consist of many books of specications and many partially lled-in data sheets. All bidders will have to read everything carefully and make enough enquiries to verify that all parties agree on the terminology. The successful bid-
Chapter 1
32
der will have to ll 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 efcient in two ways. Because ISO 15926 standardizes the description of plant objects, data sheets are more reliablewhich means that there is much less need to verify terminology. There is a potential for automating repetitive tasks because the meaning of equipment attributes is accurately conveyed with the attributes themselves.
V 01 V 02 V 03 V 04 EPC 2 V 10 V 11
ISO 15926
Data Broker 1 V 05
EPC 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 engineering system is a potential bottleneck. With ISO 15926 (Figure 1.18), this is no longer an issue. Construction planning can start earlier, and can be kept up to date more easily. There is the potential to integrate construction planning with engineering.
Chapter 1
33
EPC 2
V 20 V 21 V 22
ISO 15926
Const 2
EPC 1
V 30 Const 3 V 31
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 owners document control system, and manually linked to the plant object in the owners 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 Const 1
ISO 15926
Const 2
EPC 1
Const 3 Owner
Fig 1.19 Information exchanges during handover.
Chapter 1
34
Some owners these days make turnover in a specic form a project requirement. This moves the effort to comply with specic requirements forward in time but does not make the job itself any easier. Using ISO 15926, the information can be rendered in a standard formeliminating 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 specic 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 modications (Figure 1.20). Hands-on maintenance time is maximized because less time has to be spent nding information. Worker safety is improved because it is easier to make sure critical information, such as equipment hazards and hazardous substances, is in the proper place. It is easier to manage information over time as computer hardware and software changes. Currently, documents in an old system may be very difcult to nd and use. With ISO 15926, however, all information can be stored in a standard form so that loading information into a new system is much easier.
Chapter 1
35
V 01 V 02 V 03 V 04 EPC 2
V 10
V 11
V 20 V 21 V 22
ISO 15926
Const 2
Data Broker 1 V 05
EPC 1
V 30 Const 3 Owner V 31
Fig 1.20 Information exchanges during operations and maintenance.
How ISO 15926 Makes Life Easier in the Long Term

The preceding examples highlight existing information exchanges and show how they are made easier using ISO 15926. In the three examples following, we are speculating based on what will be possible when ISO 15926 becomes widely adopted.
Using Specialized Designs

Figure 1.21 shows a project previously designed by one of the EPC contractors, as well as a specialist the EPC contractor works with. ISO 15926 will make it much easier to reuse previous work and to integrate the work of specialists. Currently, we try to do the smart thing and reuse work we have previously done. But there are practical barriers that often get in our way. For instance, a design may have been done with a different engineering design system or perhaps with an older version of a design system than that currently used. We salvage as much as possible, but often large parts must be redone.
Chapter 1
36
Previous project information stored as ISO 15926 Specialist Communication to Specialist supplier using ISO 15926
EPC 2
ISO 15926
Fig 1.21 Integration of information with an engineering subcontractor.
In addition, it will be easier to integrate information from the designers of major systems. On a large capital project, it is typical that the design of major systems be given entirely to organizations that specialize in those systems. For instance, after an EPC contractor determines the performance characteristics of a power boiler the design and fabrication are typically given to a company that specializes in power boilers. The power boiler may have a great many instruments and other devices that have to be integrated into the owners plant maintenance and operating systems. Currently, the best way to handle this is similar to the overall data handover issue we have just discussed. Basically, either the EPC contractor or the eventual owner will have to receive all of the documentation about the equipment and manually enter it. As with other information exchanges, use of ISO 15926 will make these situations much easier to deal with. Designs from an older project will be more easily reused on a new project. Designs from joint venture partners will be more easily integrated. Design from a specialized designer will be more easily used on all projects that use that particular design. Licensed process design will be sold more easily to EPC contractors.
Application Development
When software is developed (Figure 1.22), the developer must deal with the manner in which information is to be acquired (data in), how it is to be stored, and how it is to be published (data out). ISO 15926 will make all of these issues much easier to deal with.
Chapter 1
37
ISO 15926 is a single standard to support. The questions of how input is received and how output is to be made disappear. ISO 15926 already exists. A new data model for data storage does not have to be developed from scratch.
ISO 15926
Software Developer
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 every day. It is easy to imagine a future in which almost all objects have an RFID tag. It is a small leap to imagine a manufacturer imbedding an ISO 15926 identier in the tag that will automatically link to all of the information about the component that had been publicized with ISO 15926 protocols. This could include: Material certicates and other information from the manufacturer Inspection certicates 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 specications from the engineer that specied 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 manufacturers web site for product information. The ISO 15926 identier will link directly to the product information without the user having to know the manufacturers name or be able to read a nameplate. This represents true integration of RFID information (Figure 1.23).
Chapter 1
38
V 03
ISO 15926
Const 2
EPC 1
Owner
Fig 1.23 Integration of RFID information.
Chapter 1
39
CHAPTER 2: HISTORY OF ISO 15926

The ability to exchange digital information between computer programs probably became an issue as soon as the second computer program was written. Software developers create their applications independently and make individual pragmatic decisions on how to represent data. As a result, users of the software can typically only open a data le by using the authoring applicationnot a competitors 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 users needs, we have come to expect to be able to move information from one system to another without having to completely rekey it. But we still need to know a great deal about the computer systems and work processes involved if we want the meaning, or semantics, of our information to be preserved throughout the exchange. Today, at the beginning of the second decade of the twenty-rst 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 nd information. How we know and understand things. Open means of storing and exchanging data. The evolution of product information standards. Figure 2.1 shows how these areas of study relate to ISO 15926.
Chapter 2
40
How we use the internet to find information
How we know and understand things
Open ways to store and exchange data
Evolution of product information standards
The Semantic Web
Ontologies
Markup Languages
Plant Information Exchange
Ontology Languages
ISO 15926
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 difcult to use with condence. Worse, much of what is potentially useful is stored in unpredictable forms and in unpredictable locations. Therefore, because the information is not presented in a uniform manner understanding whether a given piece of information is worthwhile or not usually requires a human being to sift through it page by page. This is not what Tim Berners-Lee had in mind when he invented the World Wide Web in 1990. He envisioned much more than what we use today, which he has called version 1.0. He envisioned a web environment in which people could ask their personal digital assistants questions such as Is there a medical doctor near here who specializes in geriatrics and has an open appointment before this coming Friday noon?and then go for coffee while the assistant locates a doctor and makes an appointment. He called this the Semantic Web. Currently, the World Wide Web is built to link documents primarily for human consumption. Computers can process web pages for layout and visual format, but they have no way to process the semanticsto know what the pages mean. Thus, if you wanted to nd a doctor in the pervious example you might be able to use the World Wide Web to get a list of doctors, their specialties, and maps with which to judge the distance, but you would still have to call each
Chapter 2
41
doctors ofce individually to nd out if he or she is taking new patients and if there is a suitable open appointment. Using existing sources of information, you might get lucky and get an appointment with the rst call, but it could easily take much longer. The Semantic Web is all about describing things in a manner that computers can understand, so that you can ask questions like the one in this example and let a digital assistant do the leg work. Using Semantic Web technology, data can be shared and reused across application, enterprise, and community boundaries. ISO 15926 has borrowed two technologies from the Semantic Web, OWL (Web Ontology Language) and RDF (Resource Description Framework). OWL is a language for creating ontologies, a concept we will discuss next. RDF is a way of storing information in declarations of truth using specic 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 applicationswhen we try to design a way for any two computer applications to exchange information without having to know anything at all about each otherwe confront the question of how we represent knowledge. This is not just sophistry. When two people are having a conversation, they will naturally ask questions if they do not understand something or if they receive an unexpected response. But when software applications exchange information there is no opportunity to ask questions. The developers of these applications will make certain assumptions about the world, and therefore key terminology in the applications may differ. The solution is to embed the necessary context (that is, the understanding that humans bring) into the data being exchanged. For this, we need to understand how we know things. The study of how we know things in philosophy and mathematics is called ontology. We do not need an in-depth understanding of what ontology is in order to understand ISO 15926, but a brief, personal, example will be helpful. I, your humble author, ride a bicycle to work most days. (Among other things, it lets me indulge in the luxury of eating the ne Ukrainian food my wife cooks for me!) The distance to work makes a nice workout but is beyond walking if the bicycle were to break down. Therefore, I have developed what you might call an Ontology of Things That Will Carry a Bicycle. Now, in Western Canadawhich 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 difcult to imagine that if my bicycle broke down on the way to work, I would try to think of everyone who owned a pickup truck that might have driven it to work that day.
Fig. 2.2 Pickup truck.
Chapter 2
42
Suppose one such friend is Bill, who owes me a big favor. But when I talk to Bill he tells me he cant 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 lled the available space with his other camping gearleaving 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 cant 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 hasbut a bit smaller. Hooray! The Czech Republic has real men too! I immediately accept his kind offer to drive me and my bicycle home after work. (Oh, and I owe him a really big favor. Perhaps I will invite him in for Ukrainian food!) How did I know that a Felicia Fun would carry my bicycle without ever having heard of it before? It is because of my Ontology of Things That Will Carry a Bicycle. In this ontology is the general class pickup truck, and one instance of the class pickup truck is the F150which 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 ontologyand because I knew that all pickup trucks can carry a bicycle I instantly drew the inference that a Felicia Fun can also do so. Figure 2.4 shows the relationship of things in my ontology.
1.
For readers outside North America, a camper is like a holiday trailer without wheels. Instead of being towed behind a vehicle, it is loaded onto the back of a pickup truck.
Chapter 2
43
Ontology of Things That Will Carry a Bicycle
F150
Pickup Truck Felicia Fun
Pickup Truck with a Camper that is not full of stuff

Fig. 2.4 Ontology of things that will carry a bicycle.
Similarly, when we use a machine-readable ontology to organize and store information we make it possible for machines to make inferences. If two applications use the same ontology to store information it will be much easier for them to exchange information, and to preserve the meaning of the information during the exchange. There has been a great deal of study on the subject of ontologies in an effort to implement the vision of the Semantic Web. A number of tools have been developed to make it easier to create and share ontologies. One of the more important of these is OWL, which is being incorporated into Part 8 of ISO 15926.
Open Ways to Store and Exchange Data

For machines to be able to understand what data means, we need to see how to store data in a way that retains its meaning without being dependent on proprietary software or short-lived hardware. Since the invention of writing at about 3000 B.C., people have used all manner of what we now call hard copy to record information. The Library of Alexandria, which burned down in 48 B.C., according to one account,2 is an example of the best technology for managing information in hard-copy form and of a major limitation of doing so. With the advent of computer-managed storage in the mid twentieth century, information managers have had to grapple with two problems. Survival of information beyond the lifetime of proprietary hardware and software Moving a large amount of information between proprietary systems
A typical example of these types of questions is a help desk inquiry from the mid 1980s.
Look up Library of Alexandra in Wikipedia.
Chapter 2
44
I have data I want to keep for decades. Should I invest in a good card reader or should I transfer my data to these far more efcient but newfangled oppy disks?
Unfortunately, the best answer to this type of question has always been rather labor intensive. That is, the only reliable way to keep digital information for decades is to upgrade our storage media every few years to whatever is the latest and greatest at the time. For personal use, in the 1980s it would have been 5-1/2-inch oppy disks. By the 1990s, we would have had to copy our archive to 3-1/2-inch oppies. Then, sometime around 2000 transfer them again to CDsand a bit later to DVDs, and more recently to BDs. Now, at the beginning of the second decade in the twenty-rst century, ash drives are looking like they will be readable for quite awhile. But for how long will our personal computers have USB ports? At some point we will still have to load up our thumb drives and copy the data to some new media; perhaps a 3D holographic memory block. Unfortunately, even if we go through the exercise of transferring our archive every few years how are we going to open the les 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 Wordwhich comes in two avors, 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 rst. Q. How do you make a Macintosh go faster? A. Drop it from a higher window!
Working with Word 2002, now, as this is being written, we can open the following word processor le 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 les, 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 les every couple of years and somehow transfer the content to whatever the new authoring software is. This will remove the problem of having to keep old hardware and software around, but will introduce two new problems. First, this solution will create an upper limit on how much information I can keep around. Be-
Chapter 2
45
cause it will take a certain amount of time to upgrade my archive each cycle, I will have less and less time each round to create new information. Eventually, I will just nish one upgrade when I will have to start over with new technology. Second, whos 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 les authored with obscure CAD software? What if none of the current set of dominant CAD developers wrote the appropriate conversions into their offerings? Well, Figure 2.5 shows another option.3
Fig. 2.5 Long-term information storage using the Internet.
If the problem of moving information between proprietary systems is daunting on a personal level, try to imagine what it is like for organizations that create large bodies of documentation. For instance, every model of commercial aircraft you see today requires millions of pages of documentation that have to be revised and published on a regular basis. The combined documentation libraries of the aircraft industry are immense, yet every few years the dominant hardware and software changes. In the government and law we have a similar situation in that large bodies of text must be readable for decades. Because of this, the text must not be stored in a proprietary format that may go out of fashion in a few years. This brings us to the topic of markup languages and neutral les.
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 gure out how to merge case law research results together into one document, compose it, and print it. At the time, there was no single system that would perform all three of these functions. Thus, when text was to be printed it had to be transferred from one proprietary system to anotherall without loosing its delity, or meaning. With a team of two others, he developed what he called Generalized Markup Language (GML). GML was a set of macros that described the logical structure of the document, for instance, to declare some text to be a heading and other text to be a body paragraph. The use of GML
3. This is taken from the online forum Slashdot.org
Chapter 2
46
markup tags freed document creators from having to deal with the appearance of the documents so that they could concentrate on content. Since the development of GML, markup languages have become widely used in enabling computers to handle large bodies of text properly without human intervention. When encoded, or marked up with tags, the content of a body of text is separated from the format (appearance) of the text. This is an important concept in ISO 15926, wherein the goal is to embed enough context into the content that we do not need to see the format of the information to know what it means. So, for instance, we would not need to see an entire data sheet to know what a single data value means. Figure 2.6 shows the descendents of GML. GML is no longer used, but the other languages are. SGML (Standard Generalized Markup Language) is used for managing very large bodies of textual information. HTML (Hypertext Markup Language) is the language of the World Wide Web, which all web browsers can read. XML (Extensible Markup Language) has become a workhorse transport language for embedding meaning into all manner of information exchange.
GML
SGML
HTML
XML
Fig. 2.6 Development of XML.
If you wish to continue in your studies of ISO 15926 beyond this introduction, an understanding of XML will be helpful. You will probably not write very much XML code yourself, but you will run into quite a bit of it. It will be helpful to be able to recognize what you are looking at. There are a number of good learning resources on the Internet. Resource Description Framework (RDF) and Web Ontology Language (OWL) are two technologies developed for the Semantic Web that were adopted by the developers of ISO 15926. Figure 2.7 shows their relationship to XML. Information in ISO 15926 is structured in an ontology, starting with basic concepts all the way down to individual objects in a particular project. OWL and RDF are well suited to this type of structure. OWL and RDF are the basis of ISO 15926 Parts 8 and 9, which we discuss in Chapter 3.
Chapter 2
47
XML
Compares to
Validated by
XML Schema
Compares to
RDF
Validated by
OWL
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 les as a method of exchanging information. ISO 10303, a standard for information exchange, is the direct forebear of ISO 15926as we will discuss in the next section of this chapter. To manage the data models for the various parts of ISO 10303, the developers needed a standard modeling language to specify how the data models were to be created and used. They called their language EXPRESS and created ISO 10303-21, which standardizes the way to use EXPRESS for storing and exchanging product information. In recent years, EXPRESS has been replaced with OWL by some developers of ISO 15926but is still regarded as an efcient modeling format. Part 21 les 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 dont have to work as hard. What we should avoid is slothfulness.4
No matter how far back one looks to nd an example of a product standard, there is always an earlier example. For instance, the National Institute of Science and Technologyin its publication STEP, The Grand Experiencestarts before the Industrial Revolution with a description of what we would today call a machinist, carefully measuring the prototype of a part while making a duplicate. Then, at the beginning of the nineteenth century the idea of an engineering drawing was developedwhich 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 rst attempts to
4. The authors English instructor at technical school in 1972.
Chapter 2
48
minimize the variability of parts by reducing a drawing of a part to a series of (x,y,z) tool path movements and storing it on punched tape. The vision of ISO 15926 is that full life-cycle product informationwhich includes information about every object in a processing plant, manufacturing assembly line, airplane, ship, and highway interchangecan be stored in a neutral form that any computer system can read and write to. We are close enough to achieving this vision that we can see it, but the progress toward this goal has always been at the margins with one development leading to the next. For our history here, of the evolution of product information standards, we will start with the methods developed to exchange electronic drawings produced with computer-aided drafting (CAD) software. Shortly after the advent of CAD, a number of such standards sprang up around the worldand although we could use almost any of them as an example we will use the Initial Graphics Exchange Specication (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 15926which uses a single generic data model instead of the many specic-purpose data models used in the STEP world (with the addition of the dimension of time). Along the way, we will introduce a number of organizations that have played key roles.
The Initial Graphics Exchange Specication

The rst systems we would call CAD were written in the early 1960s in universities, with commercial systems appearing a few years later. The early commercial CAD systems were developed by large organizations, such as automotive and aerospace companies to assist their engineers in complex calculations, and by computer manufacturers as tools to increase hardware sales. By the 1970s, there were a number of competitorsall with proprietary le formats, with the resulting inability to share data across system boundaries. To take just the defense industry, at the time there were more than 3,500 third-party vendors in the U.S. Department of Defense (DoD) supply chain. Members of manufacturing supply chains each have unique requirements depending on their role, and the software they use differs accordingly. At that time, even within a single organization different manufacturing processes used different software that was not designed to communicate with the others. This meant that when drawings were sent along the supply chain information from them had to be reentered at every step. The frustration over closed systems came to a head during a meeting of the Society of Manufacturing Engineers in the fall of 1979. A large user of CAD software challenged the CAD vendors in attendance to develop a neutral exchange mechanism. From there, the historical accounts start to resemble the old folk tale of stone soup. At rst, two vendors agreed to open certain portions of their database formatthen two others. By the end of the conference, all of the players had agreed to contribute somethingand 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 rst version of IGES was completed and published in 1980. Within a few years, IGES became the de facto standard of information exchange within some segments of the manufacturing community.
Chapter 2
49
U.S. DoD
ISO TC184 SC4
1980
IGES
CALS
1990
IGES 5.3
2000
2010
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 rst standards it supported. By 1988, all manufacturing information for weapons systems for the DoD had to be turned over in electronic form in the IGES format. This meant that any vendor of engineering or manufacturing software that wanted to market its products anywhere along the military supply chain had to make sure its products could read and write to an IGES neutral le. With the use of IGES, it no longer mattered whether or not all the members of the DoDs supply chain used the same software; as long as their software supported IGES, they could ex-
5. The scope of CALS has changed over time and the meaning of the acronym has changed with it. In the beginning, it was Computer-Aided Logistic Support, then Computer Aided Acquisition and Logistic Support, and nally Continuous Acquisition and Life-Cycle Support to indicate that its scope was the entire life cycle of a product.
Chapter 2
50
change drawings with each other and with the DoD. This eliminated rekeying information from paper drawings, with the resulting reduction of human error. As well, if the drawings were stored as IGES neutral les rather than in their native format they could be retrieved years later with different software. This is not to say that all users of IGES were enthusiastic supporters. Although there is genuine value in exchanging the graphical elements of a drawing in a way that does not depend on proprietary formats, in a manufacturing environment there is often more to a drawing than just the graphical elements. Interest and support from the manufacturing community shifted to what became known as STEP. The last ofcial version of IGES is 5.3, published in 1996. An update had been planned, version 6.0, but work stopped within a couple of years. Nevertheless, IGES remained an American National Standard until late 2006and many modern CAD systems still support it. Whereas the driver for IGES was the ability to exchange the graphical information about a product (i.e., the drawing), the driver for STEP was the ability to exchange the complete product model, unambiguously, independently of any computer system. A product model is the complete denition of a product, with all of its properties. For instance, if you were an engineer designing a machine part you would start with what the part was supposed to do; would make decisions on material, the production process (including whether or not to cast the part or machine it from stock), its surface nish and heat treating; and along the way would make a drawing showing the dimensional properties. If it were important to the part, you might also include packaging and shipping instructions. In short, the product model is all of the information about the product for its entire life cycle. By some reports, IGES did a reasonably good job of transferring images from drawingsbut all other information was lost. For example, a circular object on a drawing was faithfully communicated by IGES as a circlebut thereafter, all it would ever be was just a circle. In the original CAD system, the object that appeared as a circle may in fact have been a through-hole, a blind hole, a spot face, or a simple circular mark on the face of a part. In the original system, the circular object may have in fact been able to drive production systemssuch 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 rst meeting of a committee of the International Organization for Standardization (ISO) and what is now NIST. ISO was founded in 1947 and is based in Geneva, Switzerland. It is composed of some 160 member bodies who are agents of their respective countries, where the ISO standards often become law. Every nation on Earth is eligible for membership, and most have joined. The range of ISO standards covers almost every human endeavor. For instance, ISO-1 (Standard Reference Temperature for Geometrical Product Specication and Verication) denes the temperature (which happens to be 20 C) at which materials must be when taking mea-
Chapter 2
51
surements that will be used for comparison in different geographical locations. Individual standards are written and managed by representatives of the industry affected by the standard, not by ISO staff. The role of ISO is more to make sure that individual standards are developed with as wide and fair a representation as possible. The development of ISO standards is organized by a hierarchy of committees and workgroups. The responsibility for standards related to the exchange of product information falls to a group with the cryptic moniker TC184/SC4, which stands for Technical Committee 184, Subcommittee 4. A partial hierarchy is shown in Figure 2.9. Work Group 3, Team 25, is responsible for ISO 15926. The various parts of ISO 10303, the ofcial name of STEP, fall under a range of SC4 workgroups and teams.
International Organization for Standardization (ISO)
Technical Committee 184
Automation Systems & Integration
Subcommittee 4
Industrial Data
Work Group 3
Product Models
Team 25
Oil, Gas, Process, Power
ISO 10303
ISO 15926
Fig. 2.9 The relationship of ISO 10303 and ISO 15926 within ISO.
The National Institute of Standards and Technology (NIST) started more than a hundred years ago, in 1901. Its name describes what NIST is all about: to promote U.S. industrial competitiveness by advancing measurement science, standards, and technology. IGES, STEP, and ISO 15926 are all within its mandateand NIST has had an inuential role over the years in organizing their development. By the time of NISTs rst 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 Specication (PDES). It is important to note that this was not to be an enhancement of IGES but a complete redevelopment of the approach to information exchange. The marked departure from IGES was so important that the organization responsible for IGES changed its name from the IGES Organization to the IGES/PDES Organization (IPO), as shown in Figure 2.10.
Chapter 2
52
NIST
ISO TC184 SC4
LEGEND
Sponsoring organization Consortium Standard
IGES
1980
IGES
IGES/PDES (IPO)
PDES
STEP
1990
ISO 10303
2000
2010
Fig. 2.10 The transition from IGES to STEP.
Internationally, events were lining up in support of a new standard as well. Other CAD exchange standards besides IGES had been created by this time, most notably in the French and German manufacturing industry (with more or less the same limitations as IGES). In 1988, the IGES/PDES Organization submitted PDES to the international communitywhich eventually adopted it as the basis for STEP and published it as ISO 10303.6 At the very beginning, the participants realized that the complexity of product data demanded robust data modeling. This was a signicant development. The data model for a computer system tells us what the data means. It is like the set of blueprints for a building. Many experienced carpenters can design a simple building in their heads and build it without any drawings, but a large and complex building requires a comprehensive set. The blueprints are rst used for recording and communicating the design between all interested parties. Later, the builder uses them to organize work schedules and to purchase materials. During construction, the carpenters can use the blueprints to work independently of each
6. We will use STEP and ISO 10303 interchangeably.
Chapter 2
53
otherknowing their work will coordinate in the end to the nished building that was envisaged by the architect. And if the design is particularly good the blueprints can be used elsewhere so that others do not have to redesign the same thing from scratch. In this metaphor, where the blueprints are like the data model the building is like the nished computer systemand what the users will do with the eventual building is like a process model. The process model drives the data model. The data model helps us visualize data structures before we build the system. Data model diagrams drawn on a few pages can represent a very large system that would be difcult 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 rst 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-221arguably the most important of the STEP standards from the point of view of ISO 15926. Today, STEP is in wide use in the aerospace, automotive, electrical, and electronic industries. Each industry, and segment within each industry, has its own exchange standardcalled 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 leswhich 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. Conguration 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 conguration This AP includes classes for the physical representation of piping, HVAC, cable tray, and mechanical systems. AP 239. Product lifecycle support
Chapter 2
54
This AP is a mechanism for maintaining the information needed to support complex products and systems over their complete life cycle from conceptual design to decommissioning.
In future diagrams we will show

ISO TC184 SC4
AP-221 appearing, as if by magic,

LEGEND
Sponsoring organization
around 1997. This hides a great deal of detail:

1980
1980
International standard Part of a standard
AP-221 started development in the early 1990s Published as Committee Draft in 1997 Formally published as an Inter-
PDES
STEP
1990 1990
national Standard in 2007 In between a number of consortia worked on it, as we shall see in the next few pages
Part 11 Part 21 Part 42 AP-203 AP-214 2000 AP-227 AP-239
ISO 10303
STEPlib
From the beginning it separated reference data from the data model, something not done with the other STEP APs to that time
2000
For the reference library it used an existing library known as STEPlib, adding to it and publishing it as part of the standard, Annex M.
AP-221
Annex M
When you read this diagram, and others like it throughout this chapter,
2010
2010
remember that although they appear at a particular time, all of the standards were developed over a similarly long timeline.
Fig. 2.11 History of STEP.
Today, the use of STEP in the manufacturing industry is routinebut it took a few notable successes to make it so. The following are three examples. Boeing, Pratt & Whitney, Rolls-Royce, and GE Aircraft Engines used STEP for the 777 and 767-400 aircraft. General Motors uses STEP to coordinate designs among its various design centers when they do not use a common CAD system. The European Space Agency evaluated the use of AP-203 and AP-214 to transfer information between prime contractors and suppliers to the Agencys programs. At the conclusion of the study, the two APs were proven to be mature enough to be used as a standard for CAD exchange in the European space industry.
Chapter 2
55
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.
ISO TC184 SC4 European Union
LEGEND
Sponsoring organization Consortium which no longer exists
1980
1980
PDES
ESPRIT
Consortium which still exists International standard Part of a standard
STEP
1990
Japan STEP POSC Caesar Assocn
1990
USPI-NL
PISTEP
ISO 10303
Part 42
ProcessBase
PISTEP Activity Model
EPISTLE
STEPlib
PlantSTEP
PIPPIN
PIEBASE
PIEBASE Activity Model
2000 AP-227
2000
AP-221
Annex M 2010
2010
Fig. 2.12 History of the process industries STEP consortia.
It may appear that there is a 10-year gap between the rst proposals for STEP and the formation of the rst 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 researcherand some were simply absorbed into the larger consortia. The consortia and standards are placed as close as possible to their actual times, but some license has been taken where dating information is ambiguous and where the overlapping of shapes would present a legibility problem. If the arrows between the consortia give the appearance of a complicated membership, the reality is even more so. We could almost have put two-headed arrows between every one of the consortia, and between each of these to each standard. In a book, we are limited to a serial description of events and 2D drawings, but the development of STEPand the thinking that lead to ISO 15926was all happening at the same time. Many individual companies were members of more than one consortium, and some consortia
Chapter 2
56
were themselves made up of other consortia. The arrows between consortia and the international standards and parts roughly show the main sponsorsbut, 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 memorythe people that were part of this while it was happening do not all remember things in the same way. What we will concentrate on, then, is what happened rather than who did it. We will start by introducing the main players. Development work was initially divided between the schematic representation of a process facility and its physical representation. AP-221 was initiated in Europe to develop the schematic (2D) representation, whereas AP-227 was initiated by an American consortium to develop the physical (3D) representation.
ESPRIT
A major theme of the many treaties leading to the formal creation of the European Union (EU) in 1993 was to develop a single market for its member states. It is not surprising, then, that the CECthe executive body of the EUwas, and is, interested in efforts to standardize the ow of information between its manufacturers in order to make them more competitive. Perceiving that the competitive position of Europes 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 signicant contributions to the development of STEP. The CEC sponsored its continued development with two ESPRIT projects: ProcessBASE and PIPPIN.
ProcessBase
ProcessBase started at the end of 1992 and ran for three years. The initial objective of ProcessBase was to develop a neutral format to be used for the exchange and management of process data used in all phases of a process plantfrom 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 nal report, this demonstration proved that bulk information exchange was practical and that information exchange based on a standard neutral form delivered the expected business benets 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 difcult to imagine two fellows meeting at yet another conference, fumbling in their pockets for the rst minute or two, trying to remember which business card they were representing that week.
Chapter 2
57
PIPPIN
The Pilot Implementation of Process Plant Information Warehouse (PIPPIN) started at the beginning of 1996 and ran for two years. The purpose of PIPPIN was not so much to develop AP221 but to build a data warehouse using AP-221 for the functional life-cycle data of a process plant and to use it in a real project. In this they were successful, as we shall explore in material following.
PlantSTEP
PlantSTEP, established about 1994, was a collaborative effort between NIST and a consortium of EPC contractors, owners, and suppliers for the purpose of developing and supporting standards based on ISO 10303. Starting with just a few organizations, the consortium eventually included most high-end CAD systems, many EPC contractors, many manufacturers, and many owner-operators. The intention was that all parties involved in a large capital project could use their own tools and work methods but still be able to share appropriate information seamlessly. Where the focus of ProcessBase was the schematic design of a plant (AP-221), the focus of PlantSTEP was the physical design (AP-227). Considerable effort was made by both organizations to ensure that AP-221 was compatible with AP-227.
Japanese STEP Organizations

The main mover of STEP and ISO 15926 activities in Japan is the Engineering Advancement Association of Japan (ENAA). ENAA played in inuential role in developing ISO 10303 AP227 with its participation in PIEBASE. In the early 1990s, the capital projects industry in Japan was having the same issues with information exchange everyone else in the world was having; namely, that the perceived lack of standards for information exchange was restricting commerce. Rather than developing its own standard, ENAA decided to follow international standards and was an early proponent of AP-221 and AP-227. Later, Japan funded the development of the second edition of AP-227. In the mid 1990s, Japanese industry and government was motivated by the U.S. and European CALS initiatives and did not want to be left behind. The Japanese commissioned a domestic pilot project, called the Nippon CALS Research Partnership (NCALS)which ran for three years, with similar goals to the U.S. CALS initiative. ENAA became more involved with STEP with their own project, Plant CALSrepresenting EPC contractors, equipment vendors, and owner-operators. This project enabled the participants to better understand the various ISO 10303 application protocols and proposals on operation and maintenance APs and to experiment with SGML as a transport language. During this period, several Japanese organizations participated in the PIEBASE consortiumuntil PIEBASE disbanded in 2003. By the late 1990s, the interest of the Japanese consortia was turning from the individual application protocols of ISO 10303 to a data warehouse and e-commerce solution. Some notable work was done with STEPlib and the POSC/Caesar Association (PCA) reference data library (RDL) to provide storage and a search mechanism for engineering asset information, which was later expanded to include operations and maintenance information.
Chapter 2
58
The Japan Electric Measuring Instruments Manufacturers Association (JEMIMA) contributed to standardization by making practical use of ISO 13584 and is responsible for maintaining its reference dictionary, Part 501. At about the same time, the Japanese construction industry with an endorsement from the Japanese governmentused STEP AP-201, Explicit Draughting, as a base of 2D drawing exchange and as the archive standard for Japanese government projects. This standard uses conformance classes to inspect and validate the content of drawings and has become mandatory for all large Japanese government projects since its introduction. Currently, ENAA has been a strong supporter of ISO TC 184/SC4 standardization and participates in T25 standardization activities as a liaison organization to the Japan Nuclear Cycle Development Institute (JNC). ENAA is also a member of SC4 RDA Maintenance Team and Validation Team and actively supports enhancing the quality of the Part 4 RDL.
European Process Industries STEP Technical Liaison Executive

EPISTLE was formed in 1993 to be a forum for all of the international projects and organizations working toward standards-based exchange of engineering data using STEP. Figure 2.13 shows EPISTLE as consisting of USPI-NL, the Process Industries STEP Consortium (PISTEP), and what is now the PCA. In the early years of EPISTLE, the membership consisted of a number of companies directly involved in plant design, equipment manufacture, and operations but over time the individual companies withdrew, leaving only the three consortia as members.
1990
Petrotechnical Open Software Corporation
PISTEP UPSI-NL
Caesar Offshore Project
POSC/ Caesar Project
1995
Energistics UPSI-NL POSC Caesar Assocn
2000
EPISTLE
Fig. 2.13 EPISTLE member consortia.
It is important to remember that the individual consortia did not lose their identity while a member of EPISTLE. Therefore, many publications were made under one of the individual
Chapter 2
59
names. As a consortium, EPISTLE directly supported AP-221, published some general work on the methodology of developing data models, and managed the EPISTLE Core Modelwhich we will describe in the next section when we describe the development of ISO 15926.
USPI-NL
In 1997, an informal group of plant owners and EPC contractors operating for about four years under the name SPI-NL created the formal association USPI-NL (Uitgebreid Samenwerkingsverband ProcesIndustrie-Nederland) as the Dutch Process and Power Industry Association for the development and implementation of industry standards for plant life-cycle data. The new group included equipment suppliers, and was gradually joined by software vendors, consultancies, and universities. The mission of USPI-NL is To develop, maintain and promote the use of international information standards and best practices for product and plant life cycle informationwith 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-NLs 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 ve roles: networking, setting direction, providing implementation templates and frames, acting as a knowledge center, and developing and maintaining international standards. USPI-NL supports ISO 15926 (with emphasis on Part 4 and its maintenance), Part 11, ISO 10303-221, and several othersincluding ISO 13584. It actively encourages Dutch industry to adopt international standards for electronic data exchange and storage. USPI-NL has taken a lead in road-mapping and maturity assessments of industry, assisting individual companies to assess where they are in the roadmap, how they compare to the others, and how the industry as a whole progresses through the roadmap. USPI-NL has a wide network of associations and companies it cooperates with on development and adoption of standards. It maintains special cooperation with PROLIST, Fiatech, and ENAA.
Process Industries STEP Consortium

PISTEP was founded in 1992 to increase the competitiveness of the UK process industry by improving engineering information management. Its founders saw that the current paperbased information-handling methods used during design, construction, operation, and eventual decommissioning was hampered by locking information in documents where it was difcult to nd. 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 STEPand 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 ows required for the design and operation of a process plant. The rst page (shown in Figure 2.14) is a summary, with each process (represented by a rectangle) developed in more detail within the document. It was intended as a guide for those developing STEP APs, but it remains
Chapter 2
60
useful today as a starting point for anyone seeking to model such activity. In 2000, PISTEP merged with the PCAwith 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 nonprot, vendor-neutral corporation based in Houston, Texas, that was founded in 1990 by ve major oil companies with the aim of establishing open software standards to be used for sharing information through the asset life cycle. By 1998, it had grown to 130 members, including large and small suppliers, government agencies, universities and research centers, other standards organizations, and oil companies. This consortium works to share information among its members and to promote useful software modeling, data, and application integration standards. At the 2006 Standards
Chapter 2
61
Summit & Reception in Houston on 8 November 2006, POSC renamed itself Energistics. The Caesar Offshore Project was founded in 1993 by seven organizations active in the North Sea as a research and development project under the name of Caesar Offshore Program. The purpose of the project was to develop a product model for life-cycle information. The focus was on standardizing the technical data denitions for facilities and equipment associated with onshore and offshore oil and gas production facilities. In 1994, the Caesar Offshore Project was reorganized and dened as a project of POSC and changed its name to the POSC/Caesar Project, and then more recently to the POSC Caesar Association (PCA). The technical work of PCA was more and more related to the ISO STEP standard and inuenced 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 signicant effort being expended on the development of STEP that there was real risk of duplication of effort. To coordinate the work globally, the Process Industry Executive for Achieving Business Advantage Using Standards for Data Exchange (PIEBASE) was chartered in the United States in the fall of 1996. The membership was essentially the members of EPISTLE, PlantSTEP, and POSCwith representatives of the Japanese STEP community and NIST. The intent was to develop a common vision and a coordinated roadmap for the development and use of international standards for information exchange, including many of the STEP APs and a number of other standards. Although PIEBASE did not author any standards directly, it did valuable work dening boundaries for APs (so that the APs did not overlap) and reviewed overall priorities to increase the return on investment being made by the participants. A signicant 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. PIEBASE wrapped up in 2002.
STEP Issues
STEP does well in manufacturing environments, but some deciencies were exposed when it was used as the basis for storing life-cycle information for process plants. First, it sees information exchange as a problem to be solved by a series of exchangeseach with its own AP. It has been estimated that a typical process plant would require several hundred APs. Aside from the obvious problem of simply keeping track of them all, a major issue is that things that make up a modern process plant do not naturally come to us with their preferred AP stamped on their bottoms.
Chapter 2
62
APs by their nature overlap with each other and it is therefore not always obvious which AP should be used. For instance, a particular control valve is part of a plants 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 engineers 3D model, which implies AP-227. Now we could come up with a scheme that uses AP-221 in some situations and AP-203/214 or AP-227 in others, but the best solution is a single standard that can be used to represent the valve in all of its aspects. Second, maintaining information about plant objects requires the ability to handle change over time. This is possible with STEP, but it is cumbersome because one would have to keep updating the data model. During the pilot projects for the various STEP APs, which we have described previously, a detailed data model worked wellbut one characteristic of pilot projects is their relatively short duration. Over a longer term, maintaining such a detailed data model in the face of the amount of change over the lifetime of a typical facility proved to be a large effort. The third reason is more technical. In the typical STEP work process, the manner of creating an AP involved navigating a number of levels of modeling. The process started with dening the activities and information ows the AP is intended to support. (This is the principal reason the PISTEP and PIEBASE Activity Models, discussed previously, were created.) Then it denes the requirements using a more or less generic data model called the Application Requirements Model (ARM),8 renes it further to a more detailed data model, and then maps the requirements to a set of standard components that are interpreted in the AP. Are you confused yet? It worked good in theory, but in practice it was difcult to understand and proved to be quite cumbersome.
Development of ISO 15926

Perhaps the best way to describe the development of ISO 15926 is to describe the development of AP-221 in a bit more detail. Figure 2.15 shows some of what we have described before, with a new standardthe EPISTLE Core Model (ECM)leading to ISO 15926 Part 2. In reality, AP-221 is closely entwined with the ECM.
8. Remember this term. We will refer to it shortly.
Chapter 2
63
ISO TC184 SC4
European Union
LEGEND
ISO TC184 SC4
1980
Consortium which no longer exists
1980
ESPRIT

Japan STEP
1990
USPI-NL PISTEP
POSC Caesar Assocn
1990
ISO 10303
ProcessBase
EPISTLE PIPPIN PIEBASE

STEPlib RDL
EPISTLE Core Model
B C/D Snapshot Series E
2000
ISO 15926
2000
Part 2 Part 4
AP-221 Related to Annex M
2010
2010
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 ProcessBasewhich 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 Modelwhich was used in AP-221. The Japanese STEP consortia were involved through their participation in PIEBASE. When PIPPEN started in 1996, its purpose was to use AP-221 in a real project. It accomplished this through working closely with EPISTLE on the development of what came to be called the EPISTLE Core Model, and by using a version of the ECM in one of the Snapshot projects.
The EPISTLE Core Model and the Snapshot Series

An unfortunate casualty of legibility in Figure 2.15 is the way the ECM is shown as being separate from AP-221. In fact, the rst 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 EPISTLEs close association with the developers of AP-221, the ECM borrowed a signicant part of its data model from AP-221.
Chapter 2
64
EPISTLEs idea was that if you break data down into its smallest pieces you have the best opportunity for reuse. (In technical language, it was highly normalized.) Thus, instead of the database tables having many columns they had only a few columns but were used in combination with each other. We have said that EPISTLE developed a reference library, which it called STEPlib, and which was used as the basis for Annex M of AP-221. At some point in the development of STEPlib, PCA decided to reserve its own work for just its own membersand 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 signicant part of the evolution of ISO 15926 is the Snapshot series. As the ECM, STEPlib, and the PCA RDL evolved, they were used on real world-scale projects over a period of a few years. As each of the projects was launched, PCA took the latest thought on data models and the latest version of its RDL and merged them into a snapshot, starting at A and running to E. The lessons learned from each project were fed back for improvements in the next. The diagram implies a direct connection that may not have actually existed. However, because many of the same people worked in many capacities there would have been some crossover. There were some key differences between the Snapshot series and the ECM. The ECM was highly normalized and used multiple inheritance. Due to the perceived inability of the thencurrent technology to support this, the data models of the Snapshots were less normalized and did not support multiple inheritance. What the creators of ISO 15926 did (in the jargon of professional data modelers) was to use the ARM of AP-221. Thus, the data model was much more genericwith much of the intelligence pushed into the RDL. The ISO 15926 data model incorporates 201 entity types and reuses them many times to represent information about plant objects. Think of it this way: instead of dening 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 2whereas the combined STEPlib and PCA RDL became Part 4. Part 3 (for geometry), rst published about the same time, is based on STEP Part 42. We will describe the most signicant parts of ISO 15926 in Chapter 3. Figure 2.16 brings in the remaining parts of ISO 15926 and shows a new player, Fiatech.
Chapter 2
65
ISO TC184 SC4
European Union
LEGEND
ISO TC184 SC4
University of Texas
1980
Consortium which no longer exists ESPRIT
1980

Japan STEP
CII
PCA/Fiatech project
1990
USPI-NL PISTEP
POSC Caesar Assocn
1990
ISO 10303
Part 42
ProcessBase
EPISTLE PIPPIN PIEBASE

STEPlib RDL
EPISTLE Core Model
B C/D Snapshot Series E
2000
ISO 15926 Part 2 Part 3
Fiatech
2000
Basis For
Related to AP-221 Annex M
Part 4 Initial Part 7 Part 7 Part 8 Part 9

IDS/ADI 2010
2010
Part 10 Part 11
Fig. 2.16 Development of ISO 15926.
Fiatech
This brings us to the twenty-rst century, to an organization called Fiatech. Its purpose is to increase the productivity in the capital projects industry by introducing technology to engineering and construction work processes. In this denition, capital projects industry includes all manner of capital constructionfrom roads and sewers, commercial buildings and shopping centers, ships, and pipelines to manufacturing and industrial plants. Fiatech was founded in 2000 as a collaborative effort between NIST and the Construction Industry Institute (CII), a research center in the College of Engineering at the University of Texas at Austin. At the time, CII had more than 100 members representing owner-operators, contractors, and suppliers from the engineering and construction industryas 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, Fiatechs membership roster includes many of the largest owner-operators, EPC contractors, construction contractors, equipment manufacturers, software developers, and universities. One of the most compelling reasons for any of these organizations to join Fiatech is that because Fiatech is part of a university they can collaborate without breaking antitrust legislation. Outside Fiatech they are competitors and must guard what they say to each other. But on a Fiatech project top experts in a eld can work together across organizational boundaries. For a portion of the development costs, all members can participate in all results.
Chapter 2
66
For planning, Fiatech developed what it calls its Capital Projects Technology Roadmapwith nine elements depicting a completely integrated structure to accelerate the deployment of emerging technologies to drive productivity in the capital projects industry. Of these elements, ISO 15926 is part of number nine, Lifecycle Data Management & Information Integration. Until that time, ISO 15926 had been seen as applying predominantly to processing plants. With Fiatechs 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, ofces of a large owner-operatorwith many of the key players in plant data standardization in attendance. A strategic agreement was reached, later known as the Wilmington Agreement. The participants agreed that all would cooperate in achieving a single common RDL for the industry, which was ISO 15926-4, and work toward formal approval by ISO. Agreement was also reached regarding the implementation of a working reference data service (RDS) to support a project.
IDS-ADI Project
In 2009, both PCA and FIATCH (by coincidence) launched projects to promote ISO 15926. PCA called its project Intelligent Data Sets (IDS), whereas Fiatech called its project Accelerating the Deployment of ISO 15926 (ADI). Both came together under combined leadership with the purpose of demonstrating the capabilities of using the full specication of ISO 15926. Under their joint oversight, many subprojects have been sponsored to develop and demonstrate the use of various parts of ISO 15926.
Summary
This has been a long chapter. We started with CAD le exchange, described a number of STEP APs, nally ending up with the Part 4 RDLwhich is used in industry as a common set of denitions for plant objectsand 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 wouldnt be called research, would it? Albert Einstein
However, our intention is not to make you into an amateur historian but to understand the progression of ideas regarding information exchange in industry. We summarize them with the graph in Figure 2.17. In the late 1970s, soon after the advent of CAD, we as an industry grew tired of having to redo drawings in order to move them from one system to another. We thought that if we could only have a way to import the drawings directly from one system to another all of our data exchange problems would be solved. We got IGES, and other CAD exchange standards, but quickly found that although this solves some problems there is often more to drawings than, well, drawings.
Chapter 2
67
If only we could exchange CAD drawings. 1980
If only we all used the same data model.
1990
If only we all used the same Reference Data Library
2000
If only we could embed meaning into our information exchanges
2010
Fig. 2.17 Progression of information exchange ideas.
Any who have worked in an engineering environment will know that there is more than one CAD application in common use, and that on a large project all business partners do not always use the same one. Sometimes, all an engineer needs is some way to open in his system a drawing authored in another system. If that is all that is truly needed, a simple translation tools is all that should be used. Although IGES is no longer used, the market demand has been met with several commercial tools. But in a manufacturing environment sometimes what appears as a drawing is a collection of machine tool instructions for making a part, with the drawing more or less simply the human interface. In these situations, converting the drawing using a CAD translator tool would loose almost all of the value. By the mid 1980s, we thought that if only we all used the same data model all of our data exchange problems would be solved. We got STEP, with its many and varied APs. But as with IGES we found that although STEP solved a certain set of problems in a process plant environment a xed 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 denitions of terms (that is, the same RDL) all of our data exchange problems would be solved. We got a common RDL in the form of ISO 15926-4, and (as with STEP and IGES) we found that a common RDL does indeed solve some problems. Sometimes all you need to do is translate some data authored in one system into a form that
Chapter 2
68
can be read by another. A translator based on the common dictionary of Part 4 is what you need. As well, there are some situations in which all you need is a common naming conventionanything will do. You can make your own, but if one already exists in the form of Part 4 you can save yourself some signicant work. This is all well and good if you have the luxury of time in which to perform brute force data mapping in order to be able to exchange some data. But the pace of business is increasing and we would like to be able to exchange information without having to know a great deal about the systems our business partners use. For this we will need to embed meaning into data, so that when your business partners receive your information their systems will simply be able to gure it out. Since the mid 2000s, the research has been focused on just how to embed such meaning into a data exchange. The principle means of doing this is Part 7 templates. The next obvious question is: How does it all work? That is the subject of the next chapter.
Chapter 2
69
CHAPTER 3: HOW DOES ISO 15926 WORK?

The full title of ISO 15926 implies a very ambitious goal, encompassing information about every plant object from conception, engineering, construction, and operations.
Industrial Automation Systems and Integration: Integration of Life-cycle Data for Process Plants, Including Oil and Gas Production Facilities
Integration is a word you will hear many times in discussions of ISO 15926, along with the word interoperability. Most of us will have heard both words many times and will naturally think we know what they mean. They are related, of course, and are often used (incorrectly) as synonyms. Both terms include subcategories of related concepts, and there is disagreement even among experts as to the terms applied to these concepts. Part of the problem is that when you dig below the surface of the commonly used examples you will not nd a sharp point where one word stops and the other starts, but a continuum with a fair degree of overlap. Fortunately, this is only an introduction to ISO 15926; we can understand the basic concepts of ISO 15926 without having a precise denition 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 denitions of integration and interoperability as applied to the eld of computer science, you will nd that the denitions cover a wide range but with a clustering of ideas around each term. There is wide agreement that integration means that two different applications are made to work together seamlessly. Along with this idea, there is a strong implication that the integration of the two applications is done specically with that end in mind, and with the specic identity of the two applications in mind. Thus, we can think of integrating application A with application B by having their respective developers collaborate to make them work together (whatever that might entail). Interoperability is usually associated with two applications being able to work together (whatever that means) by virtue of each, independently, following an outside standard. In the end they may be able to work together just as well as two integrated applications, but because the working together was achieved by each implementing an outside standard we call it interoperability. (A bonus is that both applications can also work with every other similarly enabled application.) Lets look at a simple example.
Example 1: Headsets and Handsets

Figure 3.1 shows two manufacturersACME (a maker of telephone headsets) and EMCA (a maker of telephone handsets)that wish to make their products work together. If the two companies were to collaborate to design a physical plug that connects the handsets to the headsets, it would be an example of integration (that is, they use a custom-designed physical
Chapter 3
70
plug to integrate their products). But if they independently used the Bluetooth standard (with the intention that their products would work with all other Bluetooth-enabled devices as well), we would call it interoperability.
Fig. 3.1 Integration versus interoperability.
A common mistake is to assume that the Bluetooth part of this example is what denes interoperability. Not so. We can imagine the reverse situation, in which the telephone industry has standardized on a certain physical plug that allows any headset to work with any handset. In this case, we would call all of the handsets and headsets with this particular plug interoperable. Within this situation, we could further imagine two (ACME and EMCA) of the many manufacturers getting together to connect their respective products using a new wireless technology. If they achieved this wireless working together by designing their own wireless protocol, it would be considered integration. However, remember the title of ISO 15926: Industrial Automation Systems and Integration: Integration of If we were to apply this denition of integration, it would imply that if we wanted to integrate two applications using the ISO 15926 protocols we would have to do some custom work to each application specically to make them work together. But the vision of ISO 15926 is that two applications can work together by virtue of each, independently, implementing the ISO 15926 standard. This sounds more like our denition of interoperability. Have we contradicted ourselves? We can start to develop an answer to the dilemma by subdividing the denition 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, lets look at another example.
Chapter 3
71
Example 2: Integration and Interoperability with Engineering Design Systems

Figure 3.2 shows two engineering design systems offered by two competing software vendors, ACME and EMCA. Each suite of software offers intelligent, three dimensional (3D) modeling for several engineering disciplinesincluding 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 vendors 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.
Raceway Equipment Structural Equipment
Raceway Structural
Piping
ACME Engineering System

Schematics Data Sheets
P&ID
Piping
EMCA Engineering System

Schematics Data Sheets
P&ID
Integrated Interoperable
Integrated
Fig. 3.2 Integration and interoperability in engineering design systems.
Within a suite, we would call the applications integrated if information created by one application is available to the applications of another discipline. For instance, a typical integration is for the 3D piping application to be able to request line numbers from the P&ID application. This is an example of integration at the data level, and it can be achieved in a number of ways. The rst 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, modies it with an adapter (what we have previously called a data map), and then imports it into its own database. This may be practical for a small number of applications developed by one organization and marketed as a suite, but if the vision is that any application can talk to any other application using the ISO 15926 protocols this is not what we are after.
Chapter 3
72
Procurement A A
A A
Construction A
Adapter
A Engineering A
A Operations
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 ows to a common, neutral, format and storing them in a data warehouse (or an enterprise service bus or asset hub) specially designed to accommodate the information from all of the individual applications. These applications can now exchange information indirectly using the data warehouse for intermediate storage.
Engineering
Procurement
Construction
Operations
Adapter
A A A A
Service Bus or Asset Hub (Data Warehouse)
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 applications own data structure. When an application publishes information, it publishes it in its own structure to its own adapterand the adapter changes it to the structure of the data warehouse. Each application thinks that it is the only thing in the world. This is a perfectly good solution provided that you want a data warehouse. There are many very good reasons for wanting a data warehouse, but if your goal is simply to be able to exchange information among a number of applications you dont actually need the data warehouse! Figure 3.5 shows what this would look like without the data warehouse.
Chapter 3
73
Engineering
Procurement
Construction
Operations
ISO 15926 Adapter Information Exchange to the ISO 15926 Standard
Fig. 3.5 Integration without a data warehouse.
In this arrangement, all of the applications can exchange information with each other using messages structured in a common neutral format. By communicating using the ISO 15926 protocols, new applications can be added to the federation without having to modify any of them. Thus, this is what the word integration means in the title of ISO 15926. By using an ISO 15926 adapter, we achieve integration at the data level without having to modify the applications in any way.1 But because the applications each, independently, follow an external standard they are interoperable.
The Parts of ISO 15926 Are Like the Parts of Human Speech
The way ISO 15926 achieves the interoperability we have just described is similar to the way people communicate. Within a human language, there is a common dictionary of terms, a common way of structuring sentences, and a common way of putting sentences together. Figure 3.6 shows how ISO 15926 is divided into a number of parts, each of which is similar to an aspect of natural language.
1.
Truth in advertising: You have to modify each application to be able to exchange information with the adapter, but you only have to do this once.
Chapter 3
74
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 dont nd 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 nd out that the French word for couch is canap and the French word for grass is herbe. More difcult 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 shouldnt just try a word-by-word translation. If she did, she would run into two problems. First, what does the word behind mean? In English, in this context it is a slang word that means the part of your body in contact with the couch when you are sitting on it. But in English behind can also mean toward the rear, slow, and in some cases hidden. Simply looking up the word behind in a dictionary may not get you the correct French word to convey the same meaning. Second, the order in which we form words into sentences in English is often different from the correct order in French. In the eld of linguistics, this is called word order typologyand it can get tricky. For instance, word order in English is what linguists call SVO (or subject-verbobject), which means that most of the time native English speakers will say something like I went home. In other languages, the most common way of saying the same thing might be I home went (SOV), Went I home (VSO), Went home I (VOS), Home I went (OSV), or Home went I (OVS). The problem with rules about word order typology is the phrase most of the time. If
Chapter 3
75
you, dear reader, are a native English speaker you have probably heard several of these combinations in conversation. I went home is by far the most common word order, but many of the others are used occasionally to convey subtly different meanings. As it turns out, French is also SVO most of the timebut 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 derrire 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 derrire paresseux sur le divan et couper lherbe!

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.
Lve ton derrire du fauteuil et le faire le gazon.

(We wont write the English translation; sufce it to say that it is a playful insult to the posterior of someone lazy enough to lie around reading the newspaper when there is work to be done!) So now we have an example where using a dictionary to translate something into another language does not yield something that sounds natural in the other language. The same sort of thing is true with databases developed for different applications. When we humans speak to each other there is usually at least a little bit of shared background so that we dont have to explain every term from rst 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 dont 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 computerstill 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 cant tell what it really means just by looking at it. Taken literally, this database means that Joe can groom dogs
Chapter 3
76
in French, cook in German, type in Greek, and can do nothing at all in Spanish. Name Bloggs, Joe Bloggs, Joe Bloggs, Joe Bloggs, Joe Skill groom dogs cook type Language French German Greek Spanish
Fig. 3.7 The skills and languages of Joe Bloggs, Part I.
Baloney! you say. Common sense says that Bloggs can groom dogs, cook, type, and in addition has some prociency with French, German, Greek, and Spanishwith the blank simply being a place to record the next skill he learns! But note that we jumped to the second interpretation because we know that entities that have attributes with the names NAME, SKILL, and LANGUAGE are likely humanand 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 rst interpretation is the most logical. If you have trouble with this, consider Figure 3.8 (information in an identical database). Name Jabberwok Skill burble Language Whifing
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 Whifing means.2 If we said The Jabberwok can burble in Whifing, 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 Bloggs, Joe Bloggs, Joe Bloggs, Joe Skill groom dogs cook type Name Bloggs, Joe Bloggs, Joe Bloggs, Joe Bloggs, Joe Language French German Greek Spanish
Fig. 3.9 The skills and languages of Joe Bloggs, Part II.
So this is what we meant when we said earlier that when we use ISO 15926 protocols to exchange information we embed the context of the data into the data itself. We structure the
2. Except, perhaps, those who follow the work of Terry Gilliam.
Chapter 3
77
data so that the obvious explanation is the correct one.
Conceptual Data Model

Fortunately, even if there is some inherent ambiguity in your database structure there are ways to make it appear to outside applications that you have removed the ambiguity without having to actually modify the database. To describe how this works, we need to take a detour and examine two new terms: application data model and conceptual data model. Every application has a view of the world that is derived from its business purpose. Each application follows certain business rules, which can change over time. All of this is encapsulated in an application data model, which can be unique to each application. If we want to exchange information between these applications, we need to develop a data model that supports all of the application data models. We call this a conceptual data model. Figure 3.10 shows how a conceptual data model connects many different application data models.
Application Data Models
Engineering Procurement Construction Operations
External Level
Conceptual Data Model
Conceptual Level
Fig. 3.10 Conceptual data model.
At the external level, we have many different models (or views)each with a limited scope relative to the conceptual data model. Each will have needs different from any other, and each will be optimized for a particular purpose. The scope of these external models may overlap, and they may or may not be compatible with one another. For instance, an engineering application built on the engineering data model and a procurement application built on the procurement data model may perceive instrument tag numbers differently. A procurement application may deal with a tag number as a single string of text (say, 34-PI325) and store it as such in one database eld, including the dashes. On the other hand, an engineering application may manage the tag number by its parts and store each in a separate eld without dashes. Humans may be able to look at the two database structures (or schemas) and understand the relationship, but a computer program would not be able to do so on its own. The conceptual model is neutral to the external models and must be able to support all of them. It should be independent of business rules or things that change. The conceptual model is what integrates information from the different external models. For instance, the conceptual model would have to be able to deal with all of the different ways of dealing with tag numbers. Most likely, the conceptual data model would have a place for each individual part of a tag number. In turn, the tag number in each application data model would be assembled
Chapter 3
78
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 les, as shown in Figure 3.11, or in any other way technology allows.
Engineering Procurement Construction Operations
Application Data Models A A A A Conceptual Data Model
Service Bus or Asset Hub (Data Warehouse)
Engineering
Procurement
Construction
Operations
Application Data Models Conceptual Data Model
Information Exchange to the ISO 15926 Standard
Fig. 3.11 Conceptual data model.
Thus (going back to Joe Bloggs), the database structure shown in Figure 3.7 could work as an application data model provided the software developer knew how to handle the apparent inconsistencies. But the special knowledge of how to handle the information would be lost if another application received the data in that form. The solution is to transform the information to a conceptual data model that has a more easily understood data structure. There are two ways to do this. One is to rewrite the application so that it uses the desired data structure. This is ne if you actually want to rewrite the application for other reasons. But if all you want to do is exchange information with another application an easier way is to use an adapter to transform the output. Part 2 of ISO 15926 describes just such a conceptual data model that can be used for the representation of information about objects used in capital projects. This representation is specied by a generic conceptual data model designed to be used in conjunction with reference data, which we will discuss next. The model can support all disciplines and life-cycle stages, and can support information about functional requirements, physical solutions, types of objects, and individual objects and activities.
Chapter 3
79
To review, Part 2 denes the rules and constraints (more or less the grammar used throughout) on how we use ISO 15926. It is an ontology with basic axioms such as thing, class, and individual at the top level. At a lower lever, it includes subtypes of these axiomatic concepts such as physical object and connections. Part 2 is very specialized and requires a fair amount of work to understand. Fortunately, most organizations will only have to deal with templates, described in Part 7, which are sort of like precongured denitions 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 denitions of terms in a natural language; similar to a dictionary or thesaurus.
Earlier we said that when we use ISO 15926 to exchange information part of the meaning of the data comes from its structure and part comes from reference data. Reference data is essentially denitions 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 denitions of objects come from a common dictionary, computer systems will be able to infer meaning without requiring human interpretation.
Building a Wooden Swing: The Importance of Reference Data in Simplifying Communication

Effective communication requires that all parties share a common set of denitions. In computer science, this is called a reference data library (RDL; that is, a library of reference data).3 Whether we know it or not, we use an RDL every time we talk to others. For instance, if you and a co-worker did not share the same RDL conversation around the coffee machine on Monday morning would be very complicated:
You: So, what did you do on the weekend? Co-worker: You know how they use a round circular metal thing with sharp points to slice trees up into long pieces? Well, I took some of those sliced-up trees and some braided nylon that comes in long coils and built a thing for the small little offspring of my wife and I so I could push them in a manner that they would go back and forth in a circular arc that starts near the ground but gets up to three meters off the ground before they start coming back down.
Wouldnt 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 denition 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 dont use that name for the core classes of ISO 15926 Part 4 because it contains more than just classes of objects.
Chapter 3
80
Where it gets complicated is differentiating between variations of a term. Basic terminology is easy. For instance, pressure and temperature are easy to tell apart. But in an industrial environment we seldom use the words pressure and temperature by themselves. Pressure can mean the pressure a vessel is operating at right now; its assumed design pressure; its minimum hydrostatic test pressure (which may be greater than its operating pressure to compensate for a lower testing temperature); the maximum pressure it is allowed to keep working at for an assumed lifespan of, say, 30 years; or the pressure at which a pressure-relieving device will open. To tell the terms apart, we must add adjectives to make longer and longer strings of words. But even if we come to agreement on the meaning of all of the adjectives, there is still opportunity for ambiguity. For instance, what is the difference between maximum allowable working pressure and pressure-maximum-allowable-working? For human beings, the answer is probably Nothing; they are the same. But when computer systems have to communicate without human intervention the two are not the same. (And we havent even talked about exchanging information when all of the people involved do not speak the same language.)
Uniform Resource Identier

To get around this potential for ambiguity, the ISO 15926 RDL assigns a unique identier to each denition so that the identier can be used like a serial number for the denition. For example, if you were to look up temperature in the RDS/WIP maintained by the POSC Caesar Association (PCA), you would nd something like the entry shown in Figure 3.12. All of the attributes in the left-hand column are familiar except the rst. The unique identier is called a uniform resource identier (URI). A URI is sort of like a web page address that returns a denition instead of a web page. Every term, or class, in the ISO 15926 RDL has its own URI. Instead of having to describe the attribute, and get all of the adjectives in the correct order, an engineer only has to refer to the URI. RDS/WIP URI Label http://rdl.rdlfacade.org/data#R41192093771 TEMPERATURE 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 sufcient time, be in thermal equilibrium and will have the same temperature. http://dm.rdlfacade.org/data#SinglePropertyDimension
Fig. 3.12 RDS/WIP entry.
Description
Entity Type
For example, lets say that two applications wanted to exchange information about temperature. Lets also say that the rst 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 rst application would look as follows. Column Name TEMP RDS/WIP URI http://rdl.rdlfacade.org/data#R41192093771
Chapter 3
81
The import map into the second application would look as follows. Column Name Temperature 24 RDS/WIP URI http://rdl.rdlfacade.org/data#R41192093771
The rst application is saying, Here comes some values for the attribute R41192093771. The second application runs down its map and says, Great. R41192093771 translates to Temperature 24 over here. As part of the data exchange, each application will resolve the URI as a quality control measure to make sure it is a valid term. These two examples show the importance of using reference data to reduce the volume of information that has to be exchanged, and to eliminate the opportunity for error. In the rst example, of building a wooden swing, when we could use commonly understood denitions (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-P101A has only a local meaning. But some objects are important enough that we want to differentiate them from all other objects in the world. For instance, an RDL devoted to geography might have a generic class called politically bounded objectwhich would be used to describe an entire country, the provinces within the country, and the cities within each province. In addition to that general class, it may also contain individuals (or instances) of all of the existing countries in the world, their provinces, and their cities. Such instances might include England (a country), London (an important city in England), and perhaps Winston Churchill (one of Englands prime ministers). Users could make reference to these individuals in order to remove ambiguity.4
A Data Exchange Can Use Many RDLs

One way to use an RDL is to copy the denitions of everything you will need to use into a single RDL. But this would result in the unnecessary duplication of information created by others. ISO 15926 allows the use of a federation of data libraries. Internally, this lets an organization keep separate RDLsone 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 15926compliant RDL. Figure 3.13 shows a number of worldwide standards associations. Each of them publishes
4. For instance, if you mentioned The city of London in certain parts of eastern Canada, people would assume you mean London, Ontario instead of London, England.
Chapter 3
82
many engineering standards for various parts of the capital projects industry within its jurisdiction. For instance, China has its own national standards that are called Guobiao (GB), which literally means national standard. GB standards must be used for all facilities built in China. Facilities in Australia, on the other hand, must use a combination of Australian standards (AS) and ASME standards. Currently, if an organization wanted to use all of these standards as reference data it would have no choice but to copy them into its own RDL.
Fig. 3.13 Many standards.
But the vision of ISO 15926 is that all of the organizations will put their standards into their own RDL and make them publicly available for other organizations to use as reference data. What we end up with is something like Figure 3.14. Here several organizations that are collaborating on a project have made their reference data available to the other members. An owner, some suppliers, some EPC contractors, and some standards organizations have all published information in an ISO 15926 RDL. Any member of the consortium can use information from these RDLs, along with the core classes published in Part 4.
Chapter 3
83
Fig. 3.14 Cloud of federated RDLs.
To review, when two people use the same terminology (i.e., use the same dictionary) and use the terminology in the same way (i.e., use the same rules of grammar) they can communicate freely. The same is true for machines. When two computer applications use the same terminology (i.e., use the same RDL) and structure their data in the same way (i.e., use the same data model), they can communicate freely as well. The core of ISO 15926, then, is the data model (Part 2) and the RDL (Part 4). These two parts dene how the data is to be understood; the rest of the parts dene how it is delivered. Part 4 denes the initial set of reference data (or core RDL) for use with ISO 15926 Part 2. The core RDL contains the core classes and reference individuals, which are arranged in an ontology of subtypes (or specializations) of the classes in Part 2. Examples are concepts such as pump, reducer, and heat exchanger. International standards bodies can create subtypes of the core classes to create the types of objects within the scope of their standards. Currently there are almost 20,000 classes in Part 4. The library is extensible, and thus the number is expected to grow considerablybut there is no intention that it will ever contain all of the terminology for the entire capital projects industry.
Part 7: Template Methodology

Part 7 templates can be referred to as units of information. They are like phrases in a natural language phrasebook that show a new user how to construct meaningful sentences in an unfamiliar language. Part 7, like Part 2, is written independently of computer languages. Its language is rst-order logic, which is math.
We have said earlier that the vision of ISO 15926 is that your computer can talk to my computer and we dont have to know anything about each others systems in advance. If you are like the author, this sounds magical. The magic comes from using Part 2 (the data model) and Part 4 (the dictionary) together to translate data exchanges into the common language of ISO
Chapter 3
84
15926 so that it can be translated by your business partner at the other end. We have said this before, but it bears repeating: if two people know what the words of a particular language mean, and if they know the correct grammar for that language, they can communicate seamlessly. Similarly, when two applications have a common dictionary and use a common data model they can communicate seamlessly. Thus, Part 4 (the dictionary) and Part 2 (the data model) are the two most important parts of ISO 15926. The problem is that modeling information at the level of Part 2 is generic and highly specialized. Although Part 2 enables considerable exibility in what can be modeled, it is very complex. If everyone using ISO 15926 had to understand Part 2, it would be as if you needed to take a course in aeronautical engineering in order to y on an airplane. But by using part 7 templates engineers can make their information models compliant without having to master Part 2. Part 7 species templates that are expressions of predened units of semantics, allowing the use of a Part 2 data model in a convenient way. Using Part 7 is similar to using a phrase book for another language when you are travelling instead of using a language dictionary to convert each word in your native language to a foreign language.
How ISO 15926 Templates Work

When engineers start a project, one of the rst things they do is create templates of each type of data sheet they expect to use to ensure a common look and feel across the project. For instance, all data sheets for level transmitters will look the same and will have the same type of values in the same place. The reason a common look and feel is important is because human beings are the ones reading the data sheets. Humans rely on visual clues to determine meaning, and we get used to looking for certain (essentially x,y) coordinates for particular values. For instance, Maximum Allowable Working Pressure for a particular type of vessel might be something like 1/3 of the way up the page near the right-hand side. But in the world of ISO 15926 machines are the ones reading the data sheets. To a machine, the physical layout of the printed sheet means nothing. The machine is more interested in the precise denition 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 nd a new element, but we dont expect to nd a great many more. For an example of an information model, lets take a look at a married couple (Bill and Joan) taking their dog (Willy) out for a walk after getting home from work. Figure 3.15 shows one way to diagram this.5
5. The Walking the Dog diagram is courtesy of Hans Teijgeler.
Chapter 3
85
class_of_person classifier classification classified physical_object
woman
class_of_person classifier classification classified physical_object
man
class_of_organism classifier classification classified physical_object
dog
role_1
other_relation classifier classification classified other_class_ of_relation
role_2
side_1
Indirect_ connection
side_2
marriage
Fig. 3.15 Walking the dog.
This shows that there is the relationship of marriage between two physical objects that are classied as persons and identied as man and woman. There is an indirect relationship between the man and a physical object classied as an organism and identied 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 Joans 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-
Chapter 3
86
ably 1:00 in the morning. Walking their dog Willy at that time of day might normally be dangerous given the part of town they live in, but Willy is a large Rottweiler. Friends would understand this implicitly, but if you want a machine to understand it you have to embed the entire context into the information. Similarly, when modeling plant information there are a great many people who work with plant objects all day, every dayincluding engineers, buyers, suppliers, installation contractors, maintenance technicians, operators, and others. These people all have a great deal of knowledge about plant objects because they know the context. However, very few of them will have the motivation or patience to learn information modeling. Part 7 templates allow users to implement Part 2 without having to know Part 2.
What a Template Looks Like

Understanding the inner workings of a Part 7 template is far beyond the level of any book with Introduction in its title.6 However, a quick peek will help to explain how templates can both be simple enough for untrained people to use while being rigorous enough to satisfy the information modeling needs of Part 2.
Temperature Range Example

Suppose you have chosen a particular model of temperature transmitter for the project you are working on. You will be using it many times, and thus would like to create a class so that it is easier to use. Manufacturer Model No. Ambient Temperature 3051CG 40 to 85 deg C.
If you were a data modeler, it would naturally occur to you that your data model would need the terms shown in Figure 3.16. Just as naturally, this would lead to a data model that would look something like that shown in Figure 3.17.
Class of Individual 3051CG Class of Class of Relationship Ambient Temperature Single Property Dimension Temperature Scale Celcius Express Real -40" Express Real 85
Fig. 3.16 Terms in a data model of a temperature range.
6. On the other hand, if you have a strong aversion to labor-intensive, error-prone work and want to remove it from engineering work processes every time you encounter it, learning to model information at the level of Part 2 will lead you to a very fascinating and rewarding career.
Chapter 3
87
Property Quantification Upper Bound Of Property Range Classified Temperature 85 C Property Classified Classifier Classifier Classifier 85 Arithmetic Number Represented Pattern
Input
Result
Ambient Temperature
CO CO Relationship Classified
Classified
ExpressReal
85 "
3051 CG
CO Individual
CO Possessor
Classifier
Property Space
Temperature Range -40C 85C Property Range
Single Property Dimension Classifier
Temperature
Celsius
Scale Classifier
CO Identification
CO Indirect Property
Classifier
Pattern
-40 "
ExpressReal
Classified Classified Lower Bound Of Property Range Temperature -40C Property
Classified Input Result
Represented -40 Arithmetic Number
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 dened by Input 1 and Input 2 with UoM. HmmIt doesnt look much simpler.
Property Quantification Upper Bound Of Property Range
Classified
Property
Classified
Input
Result
Arithmetic Number
Property Type
Classifier
Classified
Represented Pattern
Input 1
Classified
Classifier Classifier
Classifier
Class
CO Processor
Property Space
Property Range
Base Property Type
UoM
C O Identification
CO Indirect Property
Classifier
Classifier
Classifier Pattern
Input 2
Classified
Classified
Represented
Classified
L ower Bound Of Property Range
Property
Input
Result
Arithmetic Number
Property Quantification
Fig. 3.18 ISO 15926 property range template.
Chapter 3
88
But what if we told you that your only requirement is to ll in the blue boxes with the appropriate information, and that you can treat the other boxes and diamonds and connecters as so much modern art? But it gets simpler yet. If all you have to do is ll 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?
Select RDL Class or Project Data Select from standard/ customized list of RDL Instance Property Range (Created by the system) Select from standard/ customized list of RDL Instance Base Property Type Temperature
Template
ID
Class 3051CG
Property Type Ambient Temperature
UoM C
Input 1 -40
Input 2 85
ABC
Fig. 3.19 Property range template inputs.
A template is basically a regular pattern of information, like rows and columns in a spreadsheet. The column headers in the spreadsheet are the roles of the template. Each row of the spreadsheet is a template instance. Each cell in the row is a value of a role (the column heading). The combination of the role names and role types is called the template signature. A template denition is the generic spreadsheet itself. It denes 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 denes an implementation-independent template methodology built on the Part 2 conceptual model. Part 7 provides template specication requiring template signatures listing roles and types of each argument, and provides an initial set of about 200 templates. These cover a wide range of concepts and are enough to get started. When more are needed, Part 7 also contains instructions for creating new templates. Development of Part 7 was started several years ago. It has since been split into what is now Parts 7 through 10.
Part 8: Implementation Methods for the Integration of Distributed Systems Web Ontology Language (OWL) Representation
Part 8 is a method of representing information. In a natural language, it is like paper, a computer le, or even a stone tableta particular way of presenting information.
It is possible to implement ISO 15926 with spreadsheets, text les, word processor documents, or custom code. However, there is no standard specication for doing it this way. This means that if two companies decided to exchange ISO 15926 information using spreadsheets but developed them independently the rst 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 peopleone a Cockney from the East
Chapter 3
89
End of London, England, and the other a French Canadiantrying to communicate for the rst time. Even though both people speak English, the two dialects are sufciently different that it might take awhile for them to understand each other. Using Part 8 relieves an organization from having to develop an implementation method from scratch, and makes it easier for business partners to implement complementary systems. As a metaphor, we can compare the use of Part 8 to writing a memo and somehow delivering it to a friend. In order to compose the letter in English you would have had to use your knowledge of English words and grammar, which are equivalent to Part 4 and Part 2. Having the message formed in your mind is like Part 7. Putting the message on paper is like Part 8. Sending it in an envelope through postal services is like Part 9. Part 8 is a specication for the way to use two tools developed for the Semantic Web, Web Ontology Language (OWL), and Resource Description Framework (RDF) to implement ISO 15926.
Web Ontology Language

We have said earlier that Part 2 and Part 4 are arranged in an ontology, with Part 2 consisting of basic concepts and Part 4 consisting of subtypes (or specializations) of these basic concepts. User-created RDLs will consist of subtypes, or specializations, of Part 4 classes. The Web Ontology Language (OWL) was developed as a way of dening and managing ontologies. A number of software packages have been developed to process OWL knowledge directly. OWL was attractive to the developers of ISO 15926 because many of the concepts of Part 2 correspond to specic 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 denitions 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 dog7and instead of Tibetan Mastiff a link to the American Kennel Clubs ofcial 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 breeds RDL of reference individuals.
8. In this example, the American Kennel Clubs descriptions for the various breeds of dogs are a form of reference data library, with the address of each description being the URI.
Chapter 3
90
Part 9: Implementation Methods for the Integration of Distributed Systems Facade Implementation
Part 9 is like exposing messages in an on-line forum. It is open to the Internet, but only certain users have the right to read certain messages.
A facade is an outward-facing view of something. In relation to ISO 15926, you can think of this as a user interface for machines built in front of the information you have published with Part 8. Essentially, you can post the information you wish to publish into your facade, setting up appropriate security so that only your business partners can query for informationand so that they can only see what you want them to see. After that, they can access whatever information they needwhen they need it. Remember that the information you publish using Part 8 is in the form of an RDF, which is a series of triples collectively is known as a triple store. A recommended protocol for querying RDF data dened by Part 9 is SPARQL,9 another W3C standard query language similar in purpose to SQL but intended for triple stores. To extend the metaphor of writing a memo to a friend, using Part 9 is like sending the message using your national postal system. You put the message in an envelope of a certain size, write your ends 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 friends 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 databaseseach supported by the owner of that data. In Chapter 1 we discussed the idea that information expressed in natural languages is usually not precise enough to preserve the semantics, or meaning, at the level of precision required for information exchange in capital projects. In the Chapter 2 we discussed ontologies as a way of representing information in a manner that preserves meaning. Together, all of the layers of this diagram form an ontologywith each layer being a subtype, or specialization, of the previous layer (which means that the semantics of each object is preserved). For instance, the objects at the top in Part 2 are generic concepts such as thing, class, individual, and property. The objects in Part 4, the core classes, are subtypes (or specializations) of the objects in Part 2. In turn, the user-dened classes are specializations of those in Part 4. Toward the bottom, we get more and more specic until we have individual objects in a project.
9. Pronounced sparkle. 10. The pyramid diagram is courtesy of David Leal. It was adapted from a diagram in his paper Life Cycle Data for a Process Plant: An Overview.
Chapter 3
91
ISO 15926-2
Axiomatic concepts such as thing, class, individual, and property
Generic engineering concepts, such as physical object, activity, composition, connection Core classes and reference individuals, such as pump, reducer, heat exchanger, Cairo Classes defined by international standards and industry associations Company commodity classes Catalogues from suppliers and manufactuerers Special project classes
User defined classes
ISO 15926-4
26-7 159 ISO ates mpl e Te Cor
Project Data
Project Individuals such as pump 37-P-101A and pressure guage 37-PI-205
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 2which means that the information will in fact be precise enough to preserve the semantics and will integrate with other information developed following the ISO 15926 protocols. In presentations about ISO 15926, you will often see a little pyramid looking something like that shown in Figure 3.21. The little pyramid is intended to represent the entire pyramid shown in Figure 3.20.
ISO 15926
Fig. 3.21 ISO 15926 pyramid symbol used in presentations.
Chapter 3
92
Other Parts of ISO 15926

Astute readers will note that some part numbers are missing. Appendix A lists them all, with their most recent publication dates.
Levels of Compliance with ISO 15926 Versus Ambiguity

The purpose of ISO 15926 is to eliminate ambiguity in information so that it can be exchanged and reused easier. Our current work practices require signicant manual work because ambiguity is inherent in the processes. Manual work drives up costs and introduces opportunities for error. The more we use ISO 15926, the more we drive out ambiguity and automate information exchanges to drive costs down. Figure 3.22 shows various levels of compliance with ISO 15926 in information transfer, starting at the bottom (with no compliance). The scale is really continuous, but we have shown six discreet levels. The bottom two levels do not involve ISO 15926 but are included to show the progression.
Greatest Compliance
Least Ambiguity
Shouldnt we add workflow and security to the semantic web?
ISO 15926
If we use the semantic web couldnt we automate more of this?
Ambiguity Scale
Would it help if I told you how I was using the data?
Least Compliance
Why dont we use industry standard definitions?
Wouldnt it be better if we agreed on common definitions?
Greatest Ambiguity
Lets just exchange raw data and figure it out together
Fig. 3.22 Levels of compliance with ISO 15926.
Chapter 3
93
Lets Just Exchange Raw Data and Figure It Out Together

Figure 3.23 shows two companies, ACME and EMCA, which wish to exchange some information contained in databases. At the beginning of the exchange, neither knows anything about the others system. ACME selects the data to be exchanged and exports it to an intermediate le (a data dump)perhaps in a comma delimited text le 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 rst have to understand quite a bit about each others 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 y.
Chapter 3
94
Do you retain any information of the source of the item. No. I told you we just type the line items in as you see them. Okay. Well have to do the rollup for you. Do you have any way to track overs or shorts? Quset que cest 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 denitions (7 words). If we were to compare the swing metaphor to this case, we would have to make the long version even longer. A more accurate metaphor is that you speak English and your co-worker is just learning it, perhaps being a native of Fiji. Perhaps he has learned a few words, but still thinks in his native language. At some point, he may end up making a little drawing and doing some pantomime. Together, you are more or less making up a list of equivalent words in the context of a wooden swing. This type of thing would be acceptable for a single exchange, but what happens if further ACME and EMCA business ventures require different exchanges, or exchanges between different applications?
Wouldnt It Be Better if We Agreed on Common Denitions?

In Figure 3.24, ACME and EMCA exchange information often enough that there is an opportunity to streamline the operation. They do not want to have to consult with each other with every information exchange and start from scratch, so they agree on two things: They will spend a bit of time to develop the terminology for a neutral information format. They will not exchange raw data dumps. The sender will translate its information payload into the neutral le format, which the receiver will be able to understand.
Chapter 3
95
Fig. 3.24 Common reference data library.
This is the beginning of a data dictionary, or RDL. Start by assembling the terminology. ACME and EMCA collaborate to create the dictionary of database terms and to decide the format of the neutral le.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 le format. EMCA receives the intermediate le and imports it into its systems, using its database map to translate it.

The only difference here from the previous example is that after the two organizations agree on the meaning of certain data items they will be able to use a standard neutral form for the information. They will still have to agree on the meaning of the information. As in the previous case, any new application added to the confederation will still be subject to a detailed examination. If the new application uses new terminology, new terms will have to be added to the dictionary. If the new application uses existing terminology in a slightly different way, revisions to the dictionary may be required. New users may need more explanatory material than a simple list of equivalent terms.

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 denitions, otherwise there is a tendency to put proprietary information into the neutral le, and without agreement on 100% of the information we are back to the previous case.
Chapter 3
96
When new terms are introduced, you will still need a discussion to discover their meaning and may have to revise the understanding of old terms whenever you discover new concepts. This is a denite improvement, but what happens when the confederation of mapped applications grows? What happens when a third and fourth organization join the confederation? And extending the situation further, what happens when members of different confederations have to exchange information? It is certainly possible to create new maps, and maps between maps, but the labor needed to maintain this will grow exponentially. Sooner or later someone will wonder whether or not there is an industry standard for data exchange. Funny you should ask! The next example shows two organizations exchanging information using ISO 15926-4 (the RDL) using the RDS/WIP
Why Dont We Use Industry Standard Denitions?

In the example shown in Figure 3.25, ACME and EMCA wish to use an industry standard dictionary to create the neutral les they use for information exchange. Being able to export information into an industry standard format will allow them to exchange information with other organizations as well. Both ACME and EMCA collaborate and agree to use the core classes in Part 4, and to use the rules in Part 4 to extend the classes. Both use the dictionary to create their own database maps. ACME selects certain data and exports using the database map to translate it to the agreed neutral le 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 le and validates it against the RDS/WIP to verify compliance. EMCA imports the information using its database map to translate the information into something its systems understand.
Chapter 3
97
Fig. 3.25 Use ISO 15926-4 for information exchanges.

The major difference here is that instead of consulting a growing proprietary dictionary, all who are involved refer to the public standard. But both organizations will still need to have a discussion about how they will use the core classes and will need to agree on the meaning of new classes. (Recall our earlier discussion of your wife trying to ask you in French to get up off the couch and mow the lawn. A French-English dictionary allowed her to translate the individual words, but they didnt 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.

To expand the metaphor to include this case, it is as if you have discovered that you can purchase an English-Fijian dictionary. Using a standard dictionary prepared by experts in both languages will make things a bit easier, but will not itself remove all of your communication problems. For instance, when new words come into the morning coffee time conversation they will probably already be in the dictionarybut the two of you will still have to verify that
Chapter 3
98
you are using them correctly and will have to discover things like tonal inection and sentence construction by trial and error. For instance, if your Fijian friend used just the dictionary to translate a few sentences into English it would probably sound funny to you (and vice versa). The two of you would be able to work through it because you know what sounds funny and can ask questions. But a computer does not have the ability, on its own, to recognize ambiguity and work through it.
Would It Help If I Told You How I Was Using the Data?

Using Part 4 makes it easier to create database maps because both parties no longer have to relearn data denitions each time. The parties only have to collaborate when a new term is required, or if there is a deciency in an existing denition. But both parties still need a fairly good understanding of the scope of the exchange. For example, using the dictionary will make it easier to identify the database term for the concept maximum allowable working pressure However, both parties still need to know that maximum allowable working pressure is required. When we send an inquiry to an instrument vendor for, say, a pressure instrument, the traditional way is to ll in a data sheet. If there were sufcient business with one vendor, we could conceivably congure a bulk database-to-database exchange using custom mapping. If business were sufcient, 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 gure out on their own. To meet this need, we will still use Part 4 as the data dictionaryand 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 gure out easily.
Chapter 3
99
Fig. 3.26 Use templates to make modeling easier.
Both ACME and EMCA need to understand how to structure the neutral exchange le using the grammar of Part 2 along with the denitions 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 le. 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 le. ACME and EMCA collaborate and agree to use Part 7 (which implies Part 2) and Part 4. Each organization creates information models, or maps, to transform its internal data structures to something that follows the ISO 15926 protocols. They use the base templates in Part 4 and the methodology in Part 7 to create new templates when required. ACME selects certain data and exports it using the database map, based on Part 7 templates, to translate it to the agreed neutral le format. As it assembles the neutral le, the template validates the information against the core classes in the Part 4 RDL using the RDS/WIP ACME sends the neutral le to EMCA. EMCA receives the neutral le and processes it in reverse. EMCA uses its database map, based on Part 7 templates, to translate the information into something its systems understand. EMCAs templates understand how to read the meaning
Chapter 3
100
from the structure of the data in the neutral le.

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 gure out the equivalent data elements in their own systems. The reason they no longer have to review this person to person is that they are describing how they use the data simply by using the base templates in Part 7. After they implement Part 7, all they will need to know from each other is the general nature of the information to be exchanged. Neither party has to know anything at all about the way each other creates and uses the information because the context of the information is contained within the information itself. The addition of Part 7 adds some initial work to fully understand the landscape of different applications and model them properly, but thereafter the actual data exchange becomes much simpler.

This is where ISO 15926 starts to resemble the Babel sh we discussed at the very beginning of this book. When your Fijian co-worker tries to explain the wooden swing, he wouldnt have to struggle with Englishhe 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, Couldnt We Automate More of This?

Once we have our data exchanges in a form where the meaning of the information is embedded into the structure of the data, Figure 3.27 shows how we can automate the process further. ACME and EMCA collaborate and agree to use Part 4, Part 7 (which implies Part 2), and Part 8. Each organization creates information models, or maps, to transform its internal data structures to something that follows the ISO 15926 protocols by using the base templates in Part 7. They go a step further and use Part 8 to structure their data exchanges. ACME selects certain data and exports it, using the database map, based on Part 7 templates, to translate it to the agreed neutral le format. As it assembles the neutral le, 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 ACMEs 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. EMCAs templates understand how to read the meaning from the structure of the data in the neutral le.
Chapter 3
101
Fig. 3.27 Automating the process.

About the only collaboration required here would be something to do with the manner of exchange. For instance, each party could post information on a particular location on the Internet so that other users could automate downloading the appropriate parts. Alternatively, they could send exchange les by e-mail. They would not have to discuss any details of the structure or meaning of the information itself because the meaning of the data would be embedded in the data itself.

We need to venture into science ction here to extend the wooden swing metaphor to include this case. It would be as if your Fijian co-worker automated the morning coffee machine talk by programming his cell phone with automatic answers to questions such as How are you?, What did you do this weekend?, and What did you think of the football game on Saturday?
Chapter 3
102
In turn, you program your cell phone to ask these questions in case the two of you get busy and miss each other. Your cell phone asks the questions and picks up the answers as you walk by his cubical so that you can read them at your leisure. (And by the way, your friend writes his answers in Fijian but your cell phone translates them to perfect English while they are being downloaded!)
Shouldnt We Add Query, Workow, and Security to the Semantic Web?

Part 9 contains tools developed for the semantic web to implement query, workow, and security. Figure 3.28 shows how it might work. Both ACME and EMCA use the base templates in Part 7 (which implies Part 2) and Part 4. They go a step further and use Part 8 to structure their data exchanges. ACME builds a facade using Part 9 to add security and allow automation. ACME selects certain data and exports it to its facade, as in the previous example. EMCA connects to ACMEs facade and selects whatever data it wants. EMCA imports the information into its systems, as in the previous example. Part 9 will also make it possible for EMCA to perform more interactive queries. For instance, if ACME maintained historical information (say, of the design of a particular piece of equipment at each point in time), EMCA would be able to structure a query that would pull back not only the current state of the design but the way each piece had changed over time.
Chapter 3
103
Fig. 3.28 Automating the process with security

The only question at this stage will be something like Whats the URL of your ISO 15926 interface and what credentials do I need to get in? As in the previous case, they would not have to discuss any details of the structure or meaning of the information itself because the meaning of the data would be embedded in the data itself.

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 bosss cell phone would get the message I worked overtime on the Johnson le all day Saturday. But when you walk by your cell phone would get the message about building the wooden swing. And as in the previous example, your friend writes in Fijian and your cell phone gives you the messages in English.
Chapter 3
104
CHAPTER 4: CURRENT EVENTS IN THE WORLD OF ISO 15926

In this chapter we discuss current efforts to continue the development of ISO 15926, and to use in production the parts that are ready. To explain how ISO 15926 will work, at the beginning of this book we used the ctional babel shwhich, 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 others systems beforehand. To any with a background in computer systems, this is a tall order indeed. If we express the issue this way, it sounds like we are talking about articial intelligence. Well, articial intelligence would be nice but weve 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 y but not like birds. In that respect, you are both more free and less free than birds. Birds cannot y across the Atlantic Ocean in eight hours, but you can. On the other hand, you cant jump off a tall building and y 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 nd a means of representing the attributes of these objects in a way all computer programs can recognize. (When we express it this way, it almost sounds easy!) When we review the history behind ISO 15926, it becomes even more believable. Soon after CAD software came into common use, we wished we could transfer dimensional information between different CAD software and got exchange standards such as the Initial Graphics Exchange Specication (IGES). Then we wondered why we couldnt also transfer information such as surface nish 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 modeland the addition of semantic web tools (Parts 8 and 9) to more easily preserve the meaning of information during exchange. Development and use of ISO 15926 is increasing every year. Current efforts can be divided into three groups. The use of ISO 15926 mandated by owner-operators for production systems. This is probably the most important development because it often takes inuential owners to make a standard a requirement before the standard is accepted widely. We have two instances
1. Except, of course, if your name is Keanu Reeves.
Chapter 4
105
in which this is happening: in production oil facilities on the Norwegian continental shelf (NCS) and in a pilot project to develop best practices for information handover preceding the construction of a world-scale bitumen upgrader and oil renery. The development of key infrastructure in the form of a practical reference data service (RDS), and software enabling the use of semantic web tools for information exchange. The continued development of standards for geometry, instrumentation, and the harmonization between ISO 15926 and other industry standards. Much of this development is sponsored by Fiatech and the POSC Caesar Association (PCA). Recently, MIMOSA and the OpenO&M Initiative (which we introduce later in this chapter) have also sponsored projects.
Using ISO 15926 in Production

Exploration Production Information Management Association
The Exploration Production Information Management Association (EPIM) is a nonprot association of companies operating on the NCS in some part of the oil production supply chain. The objective of EPIM is to develop the best IT solutions for exchanging information and to promote these solutions to its users. EPIM is a distinct Norwegian operation, but because most global oil producers have some work going on in the NCS the EPIM has an international membership. EPIM jointly sponsors a number of projects with POSC Caesar, including IOHN, EqHub, and the EPIM Reporting Forum.
Integrated Operations in the High North

The term integrated operations in the oil and gas exploration and production industry refers to new work processes that combine information between the various disciplines within a large oil company. For operators in very remote sites, such as the high north, there are heavy demands on communication. Instrumentation and efcient transfer of real-time data between the elds and centralized operations is critical to protable development. The Integrated Operations in the High North (IOHN) project is a collaboration of about two dozen organizations along the oil exploration and production supply chain. The project involves designing, implementing, and testing a digital platformbased on open standardsto capture and transfer real-time data from drilling and production platforms to management ofces. There are three layers: a physical layer, a business layer, and a technology layer. ISO 15926 is part of the technology layer, enabling an easier exchange and integration of information across disciplines and business domains.
Equipment Hub
Equipment Hub (EqHub) is a repository for technical information for all of the oil and gas operators and suppliers working on the NCS. EPIM, which owns and manages EqHub, estimates that the cost of providing necessary documentation ranges from 5 to 20 percent of the total installed costdepending on the type of equipment. The repository will hold and share certied information on standard equipment, which can represent 80 percent of document vol-
Chapter 4
106
umes on an asset. POSC Caesar will make the existing ISO 15926 RDL available to EqHub, and extend it to cover the EqHub scope.
EPIM Reporting Forum

The Reporting Forum standardizes the daily and monthly reports drillers and producers have to provide to their regulatory authorities. To date, the daily drilling report, daily production report, and the monthly production report have been standardized. Conceptually, this sounds pretty simplebut these three reports represent the entire value of a drilling or production asset. Smoothly operating, transparent reporting mechanisms build mutual trust among business partners and regulators. These reports are structured according to ISO 15926, follow the PCA oil and gas ontology, and use the PCA RDS.
MIMOSA and the OpenO&M Initiative

More money is spent in the operations and maintenance (O&M) phase of a facility, between startup and demolition, than on the original design and construction. Capital assetsincluding facilities, plants, and complex platformsuse increasingly complex automation systems requiring many event-oriented data and information ows 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 facilityeven as individual systems are upgraded or replaced. As the complexity of the environment has increased, traditional systems integration approaches have become increasingly difcult, 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-prot trade association dedicated to developing and encouraging the adoption of open information standards for O&M, has also helped lead efforts to engage with Fiatech and PCA in order to solve the problem in the most sustainable way. The solution is the system of systems (SoS) paradigm, in which individual systems are designed to interoperate as a single composite system on a sustainable basis over the life of the facility. MIMOSA and the OpenO&M Initiative are applying the SoS paradigm to complex plants, platforms, and facilities. Their methodology relies on the use of shared services and information models driven by OpenO&M use cases, which are dened and prioritized by owneroperators on behalf of industry groups such as oil and gas, chemical, and aerospace. Collectively, these shared services and information models form a foundational Information Service Bus Architecture upon which owner-operatorspecic 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-specic engineering and construction information in approved machine-readable formats. They must all agree to share industry developed RDLs.
O&M Background
In 1989, the Purdue Reference Model for Computer Integrated Manufacturing established a
Chapter 4
107
ve-level hierarchal model of a manufacturing facilitynamed 0 through 4starting from the bottom and moving to the top. The description and details of the content of the layers have evolved, but the basic principles have remained in active use in all major subsequent standardization activities addressing the automation of manufacturing as well as other processoriented industries. For the sake of simplicity, layers 0, 1, and 2 can be somewhat aggregated to include the physical assets under management and the true real-time systems providing automation, control, and monitoring. Layer 3 is often described as manufacturing operations management or even more generally (and to cover environments other than manufacturing) as operations management. It is event driven and thus operates with a time lag behind the real-time systems in the layers below, but it tends to be timelier than transactional environments in the business-managementoriented layer above. It is concerned with detailed operations planning and scheduling, order fulllment, and maintenance planning and scheduling. This space is somewhat chaotic, with many players attempting to gain control over it. Layer 4 is often described as business management and typically contains the enterprise resource planning (ERP), supply chain management (SCM), and customer relationship management (CRM) systems used for overall management. Integration within this layer is normally somewhat out of the box, as the systems tend to be supplied by one of the two or three suppliers of major systems. A key goal of MIMOSA and other OpenO&M Initiative participants is to standardize layer 3 as the key connectivity layer in the SoS paradigm. Thus, any compliant automation and/or operations management system will work with any compliant ERP systemand multiple compliant systems from multiple vendors can be used in the same system. Switching cost is also dramatically reduced, should that become necessary, although owner-operators will normally retain compliant systems that are performing their jobs in a proper manner. Because many large owner-operators are collaborating in this effort, their wishes carry some weight.
Bringing Engineering and O&M Together

Although design, engineering, and construction systems were largely considered out of scope in the Purdue model, there is a critical need to include them in a sustainable SoS solution. Typically, a large amount of manual takeoff is done using PDFs and spreadsheets as key parts of the system implementation and integration activity. This adds signicant expense, time, and risk to the startupand impacts full life-cycle sustainability because the lack of proper synchronization between O&M systems and engineering systems after handover results in ambiguity about plant, platform, and facility conguration. As the OpenO&M Initiative has worked to dene the basis for an interoperable execution environment for an SoS, Fiatech and PCA have worked to dene 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 dened set of information, there is a large near-term opportunity to save time and money while improving risk management over the entire life of the facility.
Chapter 4
108
Fig. 4.1 O&M reference information environment.
In 2008, Fiatech, PCA, MIMOSA, and OpenO&M initiated a collaboration to harmonize the MIMOSA and OpenO&M standards with ISO 15926. This will establish a shared reference information environment supporting the interoperable execution environment for O&M systems. EPC contractors will then be able to provide the required provisioning information using ISO 15926 protocols. The Australia-based Cooperative Research Centre for Infrastructure and Engineering Asset Management (CIEAM) is also a key part of the collaboration through their support of standards workshops for this portfolio of standards in conjunction with the World Congress on Engineering Asset Management.
Joint Special Interest Groups

MIMOSA and PCA have established two joint special interest groups (SIGs) in collaboration with Fiatech. O&M SIG: This group is focused on leveraging the combination of ISO 15926, MIMOSA, and OpenO&M standards to enable sustainable interoperability of O&M systems. IT Architecture SIG: This group will focus on the IT-architecturespecic elements of standardization needed to support the use of the combined standards. The joint SIGs are performing work that will be directly applied in a large bitumen upgrader and oil renery being built in Canada, which has specied the use of an open execution environment for O&M systems interoperability based on a number of use cases developed by OpenO&M. This is a green eld project scheduled to produce a commissioned plant by early 2015. The methodology for digital handover of required O&M information will be incrementally
Chapter 4
109
specied and piloted prior to actual implementation in the project. The rst phase of this effort is underway and will be piloted by the end of 2011. It is framed around OpenO&M use case 1 (handover) and will focus on a debutanizer tower. A public demonstration at an industry conference by the end of 2011 will leverage the same use case to target data set (debutanizer tower) and open solutions architecture in an environment designed to encourage maximum supplier participation. Subsequent phases will be incrementally spiraled to build a virtual plant and demonstrate the full set of OpenO&M use cases. The O&M implementation methodology for this project will be derived from the open industry activities and will be incrementally piloted in phase with the open industry activity.
Development of Enabling Infrastructure

Joint Operational Reference Data
The Joint Operational Reference Data (JORD) project is the result of a 2009 recommendation to build an industrial-strength RDS. An RDS is the user interface for working with and managing an RDL for ISO 15926. Reference data is the lifeblood of ISO 15926. It accomplishes the dual task of eliminating ambiguity in information exchanges and reducing the size of data payloads. You may recall from Chapter 3 that the idea of an RDL separate from a data model goes back to the early 1990s, during the development of the STEP application protocols (APs). The rst RDLs were simple lists of attributes whereby everyone agreed to use a particular name for a particular object. In use, these terms were hard coded into the database structure and database maps. As long as all business partners knew each other well enough to trust that each used the terminology correctly, this worked. But the vision of ISO 15926 is that organizations be able to exchange information with anyone. What the industry needed was some way to validate terminology when exchanging information with partners that were not known as well. The industry needed a service for publicly available reference data based on Part 4. In the mid 2000s, such a service was created in the form of what we now call the RDS/WIP (Reference Data Service/Work in Progress). Anyone can use it, and with just a little training anyone can add to it. As an experiment, the RDS/WIP has been a great successwith a number of important lessons learned, not the least of which is the enthusiasm with which new terms were added by people on their own learning curve. In the RDS/WIP today, there are many terms that have been developed properlyspecialized from the correct parent in good object-oriented style. Unfortunately, there are a great many more that have not been. It still takes a fair amount of instruction for new users to know how to select an appropriate class. It is from experience with the RDS/WIP that demand grew for an industrial-strength RDL, which prompted Fiatech and PCA to sponsor JORD. Figure 4.2 shows how it will work. This diagram demonstrates three things. The RDLs will be highly distributed. We have previously described the use of each terms uniform resource identier (URI), which is essentially the web page for each denition. As far as the technology is concerned, there is no reason every term in a large information exchange could not point to a different RDL.
Chapter 4
110
There will be many levels of certication. The diagram shows ve levels of RDL, but in practice there will be a continuum from private sandboxes closed to outsiders all the way up to ISO. As the audience for an RDL expands, access will change from read-write (whereby denitions can be changed) to immutable (where they will never change). There is risk in making the decision whether or not to make denitions immutable. As an industry group starts to develop an RDL, there will likely be a learning curveand if all denitions had to be immutable from the start some mistakes would inevitably be cast in stone. But as a given term gains acceptance it should eventually become immutable so that organizations can count on it. The smaller communities are in a better position to manage this risk. Industry participants anticipate a certain amount of cascading of terminology upward as it becomes industry standard practice. Currently, JORD is on target in developing a funding model and proposals for working facilities.
Fig. 4.2 Federation of cascading reference data libraries.
Chapter 4
111
iRING
iRING is more or less a brand name for an approach to information exchange that uses the full specication 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 specication of ISO 15926 is possible. To develop software interface tools using the full specication of ISO 15926 and make the toolkits available to anyone under an open-source license. To develop best practices and make them available to those who use the tools. To encourage software vendors to collaborate and support iRING interfaces within their product offerings. Although there still is work to do before iRING technology is ready to be used on a real project, there have been a number of very successful demonstrations. Figure 4.3 is a simplied diagram showing how it will work. As with other information exchanges, ACME uses a database map to transform its internal information into the form of Part 7 templates. The templates capture the meaning of the data along with the data values. Part 8 (OWL) is used to ensure that the ontology of ISO 15926 is preserved and then posts it to a Part 9 (Facade).
PART 8 OWL
PART 7 Templates
PART 8 OWL
ACME MAP 7 8
Part 9 Facade
Part 9 Facade
PART 7 Templates
EMCA 9 8 7 MAP
Exchange
Va
lid
at
io
Va
at lid
n io
Fig. 4.3 iRING information ow.
During this process, the terminology is validated with the appropriate RDLswhich are based on Part 4. When EMCA receives the data, it processes it in reversevalidating the terminology with the RDLs used by ACME. The software tools to congure 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 ow will dene typical data ows in different types of capital projects, test and validate currently available ISO 15926 tools, and assist companies in
Chapter 4
112
adopting ISO 15926 by highlighting implementation methodologies and achievable savings. The iRINGTools Interfacing Project (IIP) will deliver a set of iRING tools data layer modules that will provide native ISO 15926 and iRING interfaces to commercial engineering software. This means that iRING capability can be added to commercial software without having to modify the software.
Practical Guide for ISO 15926 Modeling

To exchange information using ISO 15926, it has to be modeled according to the data model in Part 2. To make it easier for industry professionals to use Part 2, the concept of templates which are like building blocks for informationwas 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 sufciently different that it is becoming a barrier to the wide acceptance of ISO 15926. (We provide an introductory example in Appendix C.) A working group is being formed to remedy this with a guide for modeling using Part 7. The deliverable will be a manual describing how to use templates, in language that industry professionals can understand. A good part of this will overlap with JORD, in that using an RDL is part of using templates.
Continued Development of Standards

Geometry Special Interest Group
The Fiatech Geometry SIG is developing Part 3: Reference Data for Geometry and Topology. Part 3 will describe a neutral way of representing graphics. It will be a dictionary that all 3D design systems can map to in order to exchange graphical information. Part 3 is to geometry as Part 4 is to data. Today, many capital projects use some type of engineering design system in order to make use of the inherent 3D visualization of those systems, their ability to check for interferences, and their ability to produce automated drawings with fabrication details and bills of material. Increasingly nowadays, the information about project objects is being linked directly to the image of that object so that the 3D model essentially becomes the index to all project information. It is important, then, that the graphics of the project be exchanged with ISO 15926 as easily as the data, and that the graphics be linked to the data. Currently, there are a number of ways to exchange graphic images between commercial CAD softwarebut they typically only exchange the graphics. Any data attached to the graphics, or even indexes to the data, are lost. If an owner wants to take delivery of an intelligent 3D model, about the only way nowadays is to require all of the EPC contractors to use one particular system. The vision of ISO 15926 is to be able to exchange graphical information between 3D engineering systems as easily as any other project data. Every 3D engineering system uses a different means of representing physical objects. For instance, there are many ways of storing the dimensions of a piping tee. One system may record the location of one of the connection points and the face-to-face dimensions between it and
Chapter 4
113
the others, whereas another may record the location of the center and the distance from there to each of the branch connection points. Part 3 describes a single method of describing the geometry of a part to which all systems can unambiguously map. When Part 3 is complete, we will be able to use Part 7 templates to include geometry information for project objects. This means that all of the information about an object is in one place. Part 3 is based on ISO 10303-42 (Integrated Generic Resource: Geometric and Topological Representation) and ISO 10303-104 (Integrated Application Resource: Finite Element Analysis).
Instrument Special Interest Group

Fiatechs Instrument SIG is working to standardize the manner in which instruments are described. One of the issues in exchanging information by converting everything into a neutral form is making sure that all participants make the same choice of class to map a given attribute to. In many of the prior demonstrations of ISO 15926, the goal was to develop the technology and thus the participants were coached on how to choose the correct classes. But the vision of ISO 15926 is that project participants need not collaborate at that level prior to exchanging information. To get an idea of the magnitude of potential differences in classication, the Instrument SIG divided itself into two teamswith each team classifying a number of instruments on its own. Comparing the differences in the results showed a close match, but not 100 percent. Part of the reason different organizations may describe project objects differently is that each organization involved in a project needs different types of information. For instance, instrument manufacturers need complete product data for each subcomponent of something the rest of us call an instrument. They need to track the part number of each piece and all of the information required to manufacture it. In contrast, EPC contractors need only a very small fraction of that entire lot of informationtypically only overall dimensions and properties, and functional specications. Owner-operators need the functional specications 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 specications 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 Institutes EDE 50.7 standard. The study concludes that such harmonization is indeed possible, and demonstrates how it can be done.
Chapter 4
114
Automating Equipment Information Exchange

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

A detailed set of steps for implementing ISO 15926 is beyond the scope of this introduction. In this chapter, we provide you with a roadmapbut 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 countrysidewith a number of interesting intermediate points at which you can stop. For instance, if you lived in London, England, and wanted to go the beach at Cannes, at the South of France, an easy way would be to take the Eurostar to the Gare de Nord train station in Paris, transfer to the Gare de Lyon, and then take the train grande vitesse (TGV) to Cannes. You would have the pleasure of watching the countryside go by at 300 km/hr in airconditioned comfort. On the other hand, if you were to channel Rowan Atkinson and take a side road (Figure 5.1) you would have a much more interesting journey.
Fig. 5.1 A more interesting route to the beach.
Similarly, implementing ISO 15926 will probably fork into two main paths. The rst path will be for organizations that largely use unmodied 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 rst path. Right now there are work teams developing
Chapter 5
116
proof-of-concept software that will more or less snap onto the side of a commercial application.1 Such software will use the applications programming interface to extract standardized data sets (e.g., line list or equipment list) from its database, transform the data into the neutral format of ISO 15926, and make it available to selected business partners. Organizations with custom work processes or custom software will also be able to follow the second path. A good metaphor is to compare building a web page 15 years ago to what it takes today. Back then you would have had to learn how to write HTML code by hand. Today, there are many Internet service providers who for just a few dollars a month will let you use tools with which you can create a web page by dragging and dropping gadgets onto templates. On the other hand, if you need something more sophisticated there is no end to what you can do.
Key Preparation
When ISO 15926 is mature and examples of its use are common knowledge, implementing the standard will be just like executing any other project: gure out where you are, gure 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-rst century, is knowing what is possible. The idea that your computer can talk to my computer without either of us having to know anything about each others 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 rsthand from others who have implemented parts of the standard. This will give you an excellent understanding of what is possible, the resources required, and a realistic time frame for your own project.
Have Realistic Expectations

ISO 15926 is not a silver bullet that will instantly solve all of your data problems. In the introduction we said that the reason we need ISO 15926 is so that we can exchange and reuse complex plant and project information easier and cheaper. But if your information has been generated with a fuzzy work process so that when you exchange information with a business partner neither of you really knows what you have, moving it faster is not what you need.
Understand Your Data

The most important thing your organization can do to implement ISO 15926 is to thoroughly understand your data. There are three aspects to this. Understand what your data means. Every organization makes assumptions; things it believes everyone just knows. Find out what these are before attempting to exchange infor1. In Chapter 4, we introduced the iRINGTools Interfacing Project (IIP).
Chapter 5
117
mation with someone and thus nd out too late that everyone just doesnt know. Understand your data in terms of reference data. When we map databases together in the traditional way, we expect to take the time to understand what every data value means. Once we have done that, in the database mappings we can assign any random text string as a label. But as we move forward to a time when everyone expects to be able to exchange information with anyone we will rely heavily on our partners having classied their data properly, and the only way to ensure this is for everyone to relate their data to publicly accessible reference data libraries (RDLs) and validate the terms during the information exchange. Understand that representing your data in a way in which the context, or meaning, is part of the payload is fundamentally different. This is embodied in learning to use Part 7 templates. At the higher levels of compliance, ISO 15926 uses a fundamentally different approach to exchanging information. In the past, when we have linked two applications we have always tried to know as much as we can about both of them. But with ISO 15926 linking applications by exploiting special knowledge is actually a liability. For most of us, this is something we have to unlearn. We have also viewed machine-to-machine communication as a technology problem, but we ran into the wall of not knowing how to handle the information. ISO 15926 focuses on modeling the information to preserve its meaning as it is being exchanged.
Implementing ISO 15926

In Chapter 3, we introduced the idea of different levels of compliance. We will demonstrate this in our example, starting with a dictionary-level information exchange, moving to using Part 7 templates, and nally to using the semantic web tools of Parts 8 and 9. Let us assume that you want to automate the creation of a purchase order by selecting items on a process and instrumentation diagram (P&ID). In many engineering systems today, engineers enter a great deal of information that is stored in a database during design. To create a purchase order, they extract a report of the information, attach the appropriate data sheets, perhaps ll out a requisition form, and then send the package to a procurement ofcer. 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 ofcer will still assemble the purchase order in the usual manner, only now without having to read an engineers handwriting.
Dictionary-level Information Exchange

The good news is that implementing ISO 15926 at the lowest level, dictionary compliance, is not that difcult. 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 fulll three roles. The rst will be someone who understands information ow; someone who can draw boxes and arrows on a white board. The other two roles will be the subject matter experts (SMEs) for each of the
Chapter 5
118
two applications. (Note here that we did not specically say three people, we said three roles. Depending on the size of the project, all three roles might be fullled by one person.) There is nothing magical about automating an information exchange using ISO 15926 compared to the traditional means we have at our disposal. The team will start by thoroughly describing the information that procurement needs from engineering in order to complete the purchase, and where engineering stores that information. They will analyze the information ow, and at the beginning will probably name the information objects using the natural language names they are familiar with from the dialog boxes and user interfaces of the software. They should give some thought as to how an output from a P&ID can be generated by simply selecting objects on-screen, and later pushing transformed data into the purchasing database. Commercial software often comes with an application programming interface (API) that will let users automate certain tasks. If an API is available for the two applications, the process will be much simpler. Otherwise, a programmer may be required in the execution phase. In the next stage, the information ows will be given more denition and the team will need to bring in someone who can dig into the databases. Where the SMEs gave information objects their natural names, now the database administrators will need to see what each database calls the same objects. The team needs to thoroughly understand the meaning of the database objects, and in particular understand implied attributes (the type that everyone just knows.) Another opportunity to understand what the data means is to examine the work processes on each side of the exchange. Sometimes the way information is actually used will change its meaning. About this time, the team should bring in someone with a background in information modelingor train someone to do it. Most computer science programs include courses in entity relationship (ER) modeling, Unied Modeling Language (UML), or something similar. A production database for engineering software can be quite complex, and this type of training will be necessary in understanding it. A likely discovery is that the data structure in each of the applications is fundamentally different. We introduced this concept at the beginning of Chapter 1, and later on in Chapter 3. Each application will have been developed by a different team, and each team will have made pragmatic decisions on how its data is to be structureddepending largely on what each application does. We used the example of an engineering application breaking tag numbers (for example, 34PI-325) into their constituent parts and storing each part individually, whereas the procurement application might store tag numbers as simple text strings. Some type of transformation may be required, and if the APIs of the applications will not manage this some custom programming may be required. Note that until now we have not discussed ISO 15926. Until now, this is just like any other information exchange project. Perhaps the rst opportunity to use ISO 15926 will be when deciding how to hand off information from one application to the next. There will be a temptation to look for fortunate idiosyncrasies of either or both of the applications that can be exploited. For instance, there may be some way to make one application write directly to the database of the other. This is very much against the principles of interoperability. We have often done this type of thing in the past and patted ourselves on the back for being ingenious. Perhaps it is ingenious, but it forever traps us into particular versions of particular software.
Chapter 5
119
A better way is to make the exchange mechanism as generic as possible using some type of neutral le exported by the rst application, perhaps transformed somehow, and then imported to the second application. Where this will become critically important is when another application is brought into the federation. If the rst information exchange uses an intermediate neutral le, 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 le. 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 timeeven if people forget or if personnel changesanyone can refer to the standard. A good choice would be to use the classes in Part 4 rather than creating what amounts to your own dictionary from scratch. You can purchase a copy of Part 4 from ISO or use the RDS/WIP (Reference Data Service/Work in Progress), a publicly available RDS. You may recall that we have said earlier that the RDS/WIP contains many terms that have not been created properly. Although using the correct term may not be critical for a one-off information exchange in which the actual meanings of the terms are well known, it will become a problem in the future if an opportunity arises to add another application to your federation. This is a good opportunity to learn to read the ontologies of the original Part 4 denitions. 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 terms uniform resource identier (URI)which is essentially a web page for the denitioninstead of using the natural language name. Then, during the exchange some new software will be required to manage connections to the RDS/WIP. A few years ago, this would have had to be written by each participant. Now, software that does this is available under an open-source licenseand some software vendors have committed to supporting it. There is much more to this than has been described. For instance, at some point someone will have to look at things such as database names, database access, and network permissions. But this will have to be done, and be done in the same way, whether or not Part 4 is used.
Chapter 5
120
Tools
When the project is ready for execution, there are a number of commercial and open-source tools that have been developed in response to the demand. At the dictionary level of compliance, the most useful will be a mapping editor. Conceptually, a mapping editor is similar to using a spreadsheet in that the left-hand side is usually from and the right-hand side is tobut a mapping editor makes the entire process easier to manage. The iRINGUserGroup has published a mapping editor and tools to support the use of the RDS/WIP.
Template-based Information Exchange

The next level of compliance to ISO 15926 is to build some meaning into the data by using Part 7 templates. The mechanics of using templates is very similar to straight dictionary mapping: you simply put the name of the template into the to column of your mapping editor instead of the name of the class. The reason you would want to use templates is that it will make future information exchanges easier. With dictionary-level mapping, there is still the possibility that you and your business partner do not dene terminology the same way. (We have previously used the example of two people from different cultures learning the same foreign language. With different backgrounds, each will dene concepts differently. When rst starting to communicate, they will need a period in which they review terminology together.) When both parties use Part 7 templates, there is a much greater chance they will have a common understanding of each term. Another reason to use templates is that you will be able to include relationships between data objects. A simple example of this is being able to relate a pipeline number to a nozzle on a tank, then to the tank, to a logical location in the plant, and to a physical location in the plant. The real knowledge is in knowing which templates to use. For this, you will need your information modeler to come up to speed with Part 7 templates.
Information Modeler
In Chapter 4, we mentioned the Practical Guide to ISO 15926 Modeling. This is a very good place to start.
Tools
The iRINGUserGroup publishes a set of tools for using Part 7. There are some commercial offerings as well.
Semantic Web
The parts of ISO 15926 that use the semantic web are Part 8 (OWL) and Part 9 (Facades). As we described in Chapter 3, you would implement these if you wanted to automate some of your work ow (Part 8) and if you wanted to include some security (Part 9). The good news here is that if you have properly used Part 7 templates to represent your data you can simply add Parts 8 and 9 without redoing any of your database mappings. Some new software will be required, and a few years ago each participant would have had to write it.
Chapter 5
121
Now, however, software is available under an open-source licenseand some software vendors have committed to supporting it.
Summary
Taken step by step, implementing ISO 15926 does not have to be a huge and expensive exercise. Of course, if an organization with a great deal of proprietary software and work processes were to decide to adopt ISO 15926 on a large scale it would require a large effortjust as converting ones 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 thisand 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 simplication. What we mean is someone with a logical mind who understands abstract reasoning. Obviously, the ideal candidate would be someone with both a strong computer science background and a strong discipline background. But if only one or the other is available it will be easier to teach the computer science skills that are actually necessary (for a project leader role) to a discipline specialist than to attempt to teach the discipline-specic skills to a computer science graduate. SMEs for each application that will be brought into the federation. These people will understand how to get information into and out of the applications. A database administrator will be able to get into the databases for each application. An information modeler will be able to structure information to retain the meaning of the data involved. (There is a large overlap here with the role of database administrator.) A network administrator will understand how the organizations network works and will be able to assign rights and privileges. The role of application programmer will be required if the API of each application in your federation will not support the full transformations that may be required. If internal resources are not available, this may have to be outsourced.
Template-based Information Exchange

Part 7 information modeler: Using Part 7 is different from straight database mapping, but this can be taught to an existing team member.
Semantic Web
Parts 8 and 9 implementer: Software tools to support Part 8 (OWL) and Part 9 (Facades)
Chapter 5
122
have already been written and are available under an open-source license. As well, a market for such tools has evolved and these types of tools will be increasingly supported by commercial software vendors. Implementing these tools is well within the capability of the IT departments of most medium to large organizations.
Join Fiatech or the POSC Caesar Association

If there is any mystery remaining, it can be dispelled by meeting like-minded people, and the best way to do that is to join Fiatech or PCA and get involved. Outside of working on ISO 15926, many of us are competitors. The natural tendency, then, is to horde information. But if we can cooperate to develop ISO 15926 digital information exchange gets easier, information exchange on projects becomes easier, and as projects become easier and cheaper the owners (who in the end, pay for everything) will be able to do more. The pie gets bigger. There are a number of reasons organizations and groups of individuals join a consortium.
Owner-operators
Owner-operators want to improve their bottom line. Collectively, owners fund the entire operations of the other players. These include EPC contractors, equipment manufacturers, software developers, construction contractors, and universitiesfunded directly or via costs embedded in other fees. However, they lack the expertise to do the basic research and apply it to day-to-day operations. In a consortium, such as Fiatech or PCA, owner-operators have a forum whereby they can explain their needs and work with others on solutions.
EPC Contractors
EPC contractors get involved with consortiums to solve problems their competitors and clients also have. Everyone can work together, share the costs, and share the results. EPC contractors can take research from universities, prove it in the eld, and then recast it in terms that others in their industry can understand.
Software Developers
Software developers join a consortium to assist in developing standards that make software development easier. For instance, on the subject of information exchange software developers must be responsive to their customers and provide conversion between many competing standards. But if all industry players agree on a single standard the work of software developers will suddenly get much easier.
Equipment Manufacturers and Construction Contractors

Equipment manufacturers and construction contractors, with tighter margins, join a consortium to participate in projects they would never be able to fund on their own.
Universities
Universities participate in a consortium so that they can see their research applied in realworld projects.
Chapter 5
123
APPENDIX A: THE PARTS OF ISO 15926

This appendix summarizes the current state of the various parts of ISO 15926. We have treated Parts 2, 4, 7, 8, and 9 in some detail in Chapter 3. In Chapter 4, we introduced the geometry SIG that is developing Part 3. Here we introduce the other parts. ISO standards are developed with the voluntary involvement of all interests worldwide. There are three main phases. 1. The need is expressed by an industry sector and proposed as a new work item, and a technical scope is dened. 2. Consensus building where the detailed scope is negotiated between the countries involved. 3. Formal balloting and acceptance is carried out worldwide. Each standard is assigned to an appropriate technical committee/subcommittee (TC/SC). ISO 15926 falls under TC 184 (Automation Systems and Integration) SC 4 (Industrial Data). During development of a standard, it may be published in a number of states. PWI: Preliminary work item NP: New work item proposal CD: Committee draft, by a committee of experts TS: Technical specication, 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 denes the meaning of information in a way that all users of the information will have the same understanding of what it means.
Appendix A
124
Part 2
Formal name: Data Model Publication date: 2003 Status: IS Part 2 is the conceptual data model for representing technical information about project objects. The original mandate was life-cycle information about process plants, but this has expanded to include pretty well any type of capital project because there is so much overlap.
Part 3
Formal name: Reference Data for Geometry and Topology Publication date: 2009 Status: TS Part 3 is reference data for geometry and topology for 2D and 3D shapes. It consists of an ontology of basic classes of curves and surfaces that can be used with computer-aided design (CAD), Geographic Information Systems (GIS), and earth models. This means that you will be able to use Part 7 templates to include geometry information about project objects. Part 3 is based on ISO 10303 Part 42 (Geometric and topological representation) and Part 104 (Finite element analysis).
Part 4
Formal name: Initial Reference Data Publication date: 2007, with an amendment in 2010 Status: TS Part 4 denes the initial set of reference data for use with ISO 15926 and ISO 10303-221. ISO issues the reference data in the form of spreadsheets. Currently, there are almost 20,000 individual terms.
Part 5
Formal name: Procedures for Registration and Maintenance of Reference Data Status: Discontinued Part 5 was the procedures for registration and maintenance of reference data. This function has been taken over by an SC4 commission for class library maintenance not only of ISO 15926 but of other ISO reference data libraries contained in databases.
Appendix A
125
Part 6
Formal name: Scope and Representation for Additional Reference Data Status: NP/TS Part 6 is the methodology for the development and validation of reference data. It describes how to validate a reference data item to ensure that it is genuine. It describes the information required for a new reference data item and how to have it approved. It lists the metadata used for the provenance of the objects in an RDL.
Part 7
Formal name: Implementation Methods for the Integration of Distributed Systems: Template Methodology Status: PRF/TS
Part 8
Formal name: Implementation Methods for the Integration of Distributed Systems: Web Ontology Language (OWL) Implementation Status: PRF/TS
Part 9
Formal name: Implementation Methods for the Integration of Distributed Systems: Facade Implementation Status: Draft
Part 10
Formal name: Implementation Methods for the Integration of Distributed Systems: Abstract Test Methods Status: Draft An abstract test method is a generic description of how to test software systems to validate ISO 15926 compliance. Abstract means there is no coupling with a computer language or brand of test software; this must be lled in by the implementer. Part 10 only handles full compliance; it does not list the criteria for partial compliancewhich is up to the business. When something like ISO 15926 is in development, the people working on it form a community and get to know each other. Within the community, there is a natural check and balance on whether ones 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 fulll the need
Appendix A
126
for a way to test systems to see how well they comply.
Part 11
Formal name: Simplied 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 articially reason and come to conclusions. Gellish is the outgrowth of the development work on ISO 10303-221 (AP221) and ISO 159262 (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 Dictionarycontaining concepts, and relationships between those concepts, arranged in a taxonomy that supports inheritance. Gellish can be used as a front end for the template methodology of Parts 7 and 8, or it can be, and has been, used on its own for information exchange on major projects.
Appendix A
127
APPENDIX B: COMPLIANCE WITH ISO 15926

ISO 15926 is a standard with many parts, not all of which have to be implemented at once. As well, there are variations in the manner in which some of the parts can be implemented. Therefore, simply saying My system has implemented ISO 15926 does not give a true picture of your systems capabilities. The vision of ISO 15926 is that business partners can exchange information without engaging in a lengthy process of understanding the meaning of each others data. But implementing only one part of ISO 15926 at its simplest level does not demonstrate this capability. New users are, understandably, confused. This appendix outlines the various categories of compliance to give users a rough guide to comparing systems. The following table serves as a thumbnail.1 Category Compliance Checklist Dictionary identication only Semantic precision Shortcut relations Full ontology Any formatted le Representation technology Proprietary XML RDL XML Part 8 (OWL) Referencing technology URIs contained in schema External RDL File exchange Interface technology Proprietary query Part 9 (SPARQL) Community sandbox Industrial standardization Industry-wide sandbox JORD ISO Subject matter scope BIDG Explicitly identiable elements Metadata scope Versioning Status
1.
Thanks to Ian Glendinning for the material this section was adapted from.
Appendix B
128
Export interface Import interface Functional capability Empty seed Lossless consolidation Reconciliation
Semantic Precision
ISO 15926 is all about driving out ambiguity to reduce the risk and cost of information exchange. Semantic Precision is the most technically signicant of the categories outlined in the previous table. This category compares the way information is understood by an organization to what was intended by ISO 15926. This category recognizes that it is possible to use ISO 15926 terminology incorrectly. An extreme example is using the word pressure in a database mapping exercise to exchange temperature values. As long as both parties to the exchange knew what the text string pressure really meant, the exchange would workbut using terminology this way is misleading to new users and would add a great deal of uncertainty and risk to future exchanges using the same database maps. Part 7 templates have what is known as a signature, which removes the ambiguity by providing a mechanism by which a system can recognize what the template is intended to deal with. Thus, in the extreme example previously cited the user would never be presented with a pressure template when working with temperature. At the receiving end, the software would recognize the template as dealing with temperature and would act accordingly. There are different ways of recognizing template signatures. This category gives increasing credit as their reliability increases. Dictionary and typing level: Templates have a name, are specialized from a parent class, and have a classication. This level of compliance simply accepts these values from the template itself. Shortcut relations level: This level uses the shortcut relations to determine what the template does. Full onotology level: This level uses the full ontology along with the signature to identify the template.
Representation Technology
This category compares the manner in which the information exchange is structured.
Appendix B
129
Any File
This exchange uses a neutral le, 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 le, comma-delimited text le, 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 le or spreadsheet. New users will still have to examine the terminology used, but the structure of an XML information exchange is easier to deduce.
Reference Data Library Registered XML Schema

A registered XML schema eliminates the need to examine it closely for every information exchange. Users will still have to examine it and thoroughly understand it the rst time, but thereafter should not need to. This meets one of the intents of ISO 15926 is that two organizations can independently implement a given standard and thereafter exchange information even though they may never have explicitly intended to work with each other at the beginning.
Part 8: OWL
When the information you are exchanging is part of an overall ontology, it is easier to gure out what it means simply by examining its position in the ontology. If the ontology conforms to Part 2, exchange partners will be able to understand what your data means without having to ask about it. OWL is a tool designed for the Semantic Web that is used to exchange information stored in an ontology. If your exchange system uses OWL, ontological information will be preserved so that the meaning of the data will be preserved with the data.
Referencing Technology
Reference data is the lifeblood of ISO 15926. Without reference data there is no objective way to verify the denitions 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 ofcial denition. The name of each term is unique and has exactly one URI, and therefore the name of the term is synonymous with its URI. One way to implement Part 4 terminology is to hard code the name or URI into the schema.
Appendix B
130
URIs Resolvable in Shared Reference Data Libraries

Another way to use Part 4 terminology is to have a mechanism that uses a terms URI to connect to a reference data service, like the RDS/WIP, to verify that it is a valid term.
Interface Technology
The interface type describes how the information is physically moved. Under the hood, all information exchanges use a le to exchange the data. The key question in this category is how the le comes into existence.
File Exchange
Here we mean that the sender prepares the information exchange le by some means and sends it to the exchange partner, who then opens and reads the le in some manner.
Proprietary Query
This category implies that the recipient of the information can directly query the information to create the exchange le instead of having the owner prepare the les.
Part 9: SPARQL
SPARQL is a protocol developed for the Semantic Web, designed for querying OWL databases. The use of OWL is one way to preserve the meaning of the data.
Industrial Standardization
This category assumes that a reference data library (RDL) is used for the information exchange and measures the manner in which it is certied. 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 largerencompassing an entire industry. At this level there will likely be some formal method of creating and vetting new terms.
PCA/JORD Level
This level combines the terminology of many industries. Although JORD does not exist yet, it is expected that there will be a stringent vetting procedure to ensure that the terminology
Appendix B
131
conforms to the intent of ISO 15926.
ISO
This level is reserved for formally adopted, world-wide standards.
Subject Matter Scope

This category anticipates one or more industry-specic information guides to assist users in deciding the scope of the information that needs to be exchanged. This will not create any new terminology to add to an RDL, but will rather suggest which RDL items need to be addressed to accomplish some business purpose. For instance, the American Petroleum Institute (API) may recommend specic RDL terms to use when exchanging information about API pumps. When a standard scope of information is exchanged, the uncertainty (the ambiguity) is reduced. The Business Interfaces Denition Guide (BIDG) was originally the title of a particular handover guide being developed for the process industries, but the document was issued under a different name. Now the term is still used but has effectively come to be an umbrella for a number of industry-specic guides. For measuring compliance to ISO 15926, this category means that you are following one such guideand that the guide species ISO 15926 terminology.
Metadata Scope
When data is exchanged as part of business activities, there are usually obligations and contractual responsibilities between the parties. With each information exchange, metadata (data about data) is in fact created (such as the time of exchange)which may have to be recorded manually if there is no automatic mechanism. This category measures how the metadata is captured and recorded.
Explicitly Identiable Elements

This category means that metadata is indeed exchanged (as opposed to only the data values themselves) and that the metadata explicitly identies the data values to which it belongs.
Versioning
This category means that in addition to the identity of the data the vintage, or version, of the data is maintained.
Status
This category means that in addition to the identity and versions of the data the status of the data is maintained.
Appendix B
132
Functional Capability
This category measures the capability of the system to send and receive data.
Export Interface
This is the ability of a system to deliver information independently of data scope and interface technology. This is accomplished by publishing the data or allowing reading or querying.
Import Interface
This is the ability of a system to receive information independently of data scope and interface technology. This is accomplished by allowing external applications to write to the database, or some means of querying external databases.
Seed
Sometimes an instance is created as a placeholder, with no initial content. This category means that the placeholder can be populated with imported data without loosing anything.
Lossless Consolidation
This means that an existing instance that contains data can be updated with new imported information, correctly handling versions and duplicate information.
Reconciliation
This means that when an instance is updated with internal information any reconciliation with external identiers is retained.
Appendix B
133
APPENDIX C: EXAMPLES OF DATABASE MAPPING

In this appendix we will work through some examples of mapping databases directly together, using a custom dictionary and the Reference Data Service/Work in Progress (RDS/WIP). We will also introduce you to the use of templates from Part 7. As far as an introduction to ISO 15926, this section is denitely 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 examplesshowing how to do the mapping that is described in each example. Please bear in mind that these examples are highly simplied 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 standards protocols can exchange information with anyone else using the protocols and not have to know anything else about the others system. Just as two people who do not know each other can nevertheless communicate if both use the same rules of grammar and the same dictionary, two parties in a data exchange can understand each others 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: Lets Just Exchange Raw Data and Figure It Out Together
In this rst 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 others system. ACME selects the data to exchange and exports it to an intermediate le (a data dump) perhaps in a comma-delimited text le or a spreadsheet. ACME sends the data dump to EMCA. EMCA cannot use the information because it does not know what all of it means. Each company assigns an engineer to collaborate to make a custom map so that EMCA can import the data. EMCA uses the map to import the data.
Appendix C
134
Fig. C.1 Figure out each exchange every time.
Roles
In Chapter 5, we identied 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 rst 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 ID 85457 96058 48981 Table Name: Valve_List PID No Spec 1234-32-45 A373 1234-32-45 B893 1234-32-45 C578
Dwg_No 4567-32-17 4567-32-17 4567-32-17
Rating 150 300 600
Line Tag 10-32-A373-12-1438 10-32-B893-10-0378 10-32-C578-10-2155
Pipe Size 12 10 8
Valve Tag 32-1269 32-2958 32-7639
Fig. C.2 EMCA valve list table.
A valve list is a list of all valves used for a particular scope of work or project. Design engineers use the valve list to ensure that each is properly specied. Procurement ofcers 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 electronicallyrather than exchanging paper documents and having a person rekey the values. Figure C.3 shows EMCAs valve list, currently empty.
Appendix C
135
EMCA Index No
Dwg_No
Rating
Table Name: Table_32 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.
Table Name Valve_List Valve_List Valve_List Valve_List Valve_List Valve_List Valve_List Valve_List ACME Column Name ID Piping DRG Class PID_No Spec Line_Tag Pipe Size Valve Tag Table Name Table_32 Table_32 Table_32 Table_32 Table_32 Table_32 Table_32 Table_32 EMCA Column Name Index No Dwg_No Rating PID Mat_Spec Tag Diameter 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 simplied example, we can see that the column names are descriptive of their contentand 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 nished. The application experts still have to gure out how to get the information out of ACMEs database and into EMCAs, and the database experts still have to congure the data migration. Although these jobs may be quite complex, depending on the nature of ACMEs and EMCAs systems, they are straightforward conceptually.
Example 1.2: Map Two Databases Together, Harder

The previous example was trivially simple in order to convey the concept of mapping two databases together without getting bogged down with details. In this example, we will use a more realistic pair of valve tables. Figure C.5 shows what the two valve lists might really look like.
Appendix C
136
Table Name VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST
ACME Column Name AREA CLASS COMP ID DATASHEET DS_ID LINE TAG MANUFACTURER MATERIAL MODEL NO OP PRESS OP TEMP PID NO PIPE SIZE PIPING DRG RUN SERVICE SPEC STATUS TAG TAGTYPE VALVE TAG VALVE TEXT VALVE TYPE VCODE VINT1 VNUM VSIZE VUNIT
Table Name TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32
EMCA Column Name CLIENT_SYSTEM CLIENT_UNIT COM_GRP DES_RESP DIAMETER DIAMETER_UOM DWG_NO HEAT_TRACE HOLD INDEX_NO LINE_NUMBER LINE_TAG MAT_SPEC PID PID_LOCATION PID_REV PROJ_NO QUANTITY RATING SEQ_NO STARTUP SUFFIX SYSTEM TAG UNIT VALVE_LOCK_DEVICE VALVE_NUMBER 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 rst thought may be that this is for a component tag number, similar to an instrument tag number or equipment tag number, but we need to look further. ACME also uses the column name VALVE TAG, and EMCA also uses RECORD_ID. Given these extra names, we cannot determine their meaning simply by looking at the other names on these two lists; we must dig into the software to see how it uses the names.
Appendix C
137
We may obtain some clues by looking into the database to see what types of values are stored there, but we may also have to open the software and start experimenting. For instance, in the software that uses ACMEs and EMCAs valve tables there will be a form (or computer screen) that asks for the valves asset identication number. We can enter a ctitious value and then look for it in the database to see where it turns up. For this example, we will assume that ACMEs TAG and EMCAs 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 ACMEs VALVE TAG and EMCAs TAG are equivalent, being used to store the valves asset identier. 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 identier 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 ACMEs LINE TAG and EMCAs 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. EMCAs LINE_NUMBER stores the sequential numeric part of the line number (1438 in the line number given previously).
ACME PIPE SIZE Versus EMCA DIAMETER and DIAMETER_UOM

An important concept to understand is that an organization may have certain assumptions about the world that every employee just knows. A possible example of this is the EMCA column name DIAMETER_UOM. We might ask why ACME does not have something like this. Perhaps ACME gets all of its work from one area of the world and uses only one system of units in all of its projects. If this were the case, everyone would just know what the units were and there would be no real need to record such a value in the database. Although this is possible, an equally likely answer is that ACME does not store the units of measurement with every measurement. In this example of a valve list, ACME may feel that it is ex-
Appendix C
138
tremely improbable that a valve will be measured in one system of units and the piping system to which it is attached measured in another system. The units of measurement may be attached to the pipeline the valve is part of, or it may be a project-wide setting. Like our other examples, the SMEs will have to look at the software to see how it handles units of measurement. The SMEs will similarly examine the rest of the terms and decide which are equivalent. Figure C.6 shows the tables after rearranging column names so that equivalent names are in the same horizontal row.
ACME Table Name VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST Column Name TAG PIPING DRG CLASS PID NO EMCA Table Name TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 Column Name RECORD_ID DWG_NO STARTUP RATING PID_REV DES_RESP PID HOLD HEAT_TRACE PROJ_NO LINE_NUMBER MAT_SPEC LINE_TAG QUANTITY DIAMETER DIAMETER_UOM VALVE_LOCK_DEVICE VALVE_NUMBER SEQ_NO CLIENT_SYSTEM COM_GRP SYSTEM PID_LOCATION VALVE_TYPE SUFFIX UNIT TAG CLIENT_UNIT
VALVE_LIST VALVE_LIST VALVE_LIST
SPEC LINE TAG PIPE SIZE
VALVE_LIST
VNUM
VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST
VALVE TYPE VUNIT VALVE TAG VSIZE AREA DATASHEET TAGTYPE VCODE STATUS MATERIAL OP PRESS OP TEMP MANUFACTURER MODEL NO VALVE TEXT VINT1 RUN SERVICE COMP ID DS_ID
Fig. C.6 Two valve lists showing equivalence.
You will notice that many of the column names do not have a corresponding name in the other database. There could be a number of reasons for this. It could be that the nature of the business of each of the two organizations means that each pays attention to different things. An
Appendix C
139
example of this is EMCAs column name HOLD. If EMCAs 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 nd it. For its part, EMCA may simply assume that the data sheet for a tagged valve is always named after the valve tag number and therefore there is no point in recording it. (Note that this assumption may in fact not be true. Nevertheless, if EMCA believes it and designs its databases around that belief we have to work with EMCAs 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 ACMEs valve list has in common with EMCAs valve list is all that EMCA needs. For example, because the design of the valve is not in EMCAs 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 eld 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 ACMEs software does not store it in the valve list. ACMEs SME will need to enlist the help of application and database experts to gure out how to provide EMCA with the information it needs. There are at least two options. If ACMEs 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 gure out where the ACME records the units of measurement, and then pull it in from there. It could be anywhere. It could be attached to the line number the valve is associated with, a single project setting, or anything in between. For this example, we will assume that the appropriate unit of measurement comes from the line number. However, for illustrative purposes we will throw in a wrinkle. We will pretend that the software does not store this in a table based on the alphanumeric text string we call a line
Appendix C
140
number but in a separate table based on an arbitrary pipe run number.1 Figure C.7 shows what this might look like.
ACME Column Name . VALVE_LIST LINE TAG . Table Name EMCA Column Name . LINE_TAG . DIAMETER_UOM
Table Name LINE TAG RUN NO TABLE_32 TABLE_32 RUN NO UOM
Fig. C.7 Finding units of measurement.
What the database expert has to do, then, is to write what is called a query. Following the arrows from the left-hand side (Figure C.7), the query basically says: a. Given this LINE TAG, what is the RUN NO? b. Given this RUN NO, what is the UOM? c. Copy the UOM to DIAMETER_UOM of the table we export for EMCA.
Comparison to the Vision of ISO 15926

These examples are like two people who speak different languages attempting to communicate by pointing at something and saying its name. After a while both of them would understand what each others individual words mean, but would still be a long way from uent 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 federationand if they envision including more partners. This amounts to point-to-point mapping and is very much against the vision of ISO 15926and in fact was the reason the standard was rst proposed.
Example Set 2: Wouldnt It Be Better to Agree on Common Denitions?

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 gure out all over again what the attributes mean. One way to manage this is to create a data dictionary. In Figure C.8, ACME and EMCA exchange information often enough that there is an opportunity to streamline the operation. They do not want to have to consult with each other with every information exchange and start from scratch, so they agree on two things.
1.
Among other things, doing it this way allows users to change the line number if they have to.
Appendix C
141
They will spend a bit of time to develop a common set of terminology. They will not exchange raw data dumps. The sender will translate its information payload into a neutral le 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 le. 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 le format. EMCA receives the intermediate le and imports it into its systems, using its database map to translate it. Next, create a list consisting of a number of standard denitions, with a particular word associated with each denition. The associated word can be completely arbitrary. For instance, at a gathering to discuss techniques of mapping databases together one of the instructorsin a moment of inspirationsaid, If you have to translate something from one language to another using a third language as an intermediate, you can use any language you wishKlingon 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
Denition Unique identier for a row in a database. The alphanumeric text string that uniquely identies an orthographic drawing.
wa cha
Appendix C
142
wej loS vagh jav Soch chorgh Hut wamaH wamaH wa wamaH cha
The nominal pressure rating for a piping system or component. The alphanumeric text string that uniquely identies a piping and instrumentation diagram (PID). The material specication for a pipeline. The alphanumeric test string that uniquely identies a pipeline. The nominal diameter of a pipeline. The units of measurement of the nominal diameter of a pipeline. Maintenance tracking number for hand valves. The general category to which a valve belongs (e.g., gate or globe). The geographic or functional area of a plant; commonly called unit. Asset tracking number for individually designed components; commonly called tag number.
The second step for ACME is to create a database map (this time using the dictionary names), and then using the map export the information to a table that will be sent to EMCA. Figure C.9 shows what the table might look like. Figure C.10 shows how EMCA will receive the neutral le. EMCA will also create a database map using the dictionary names, but will instead use it to import the neutral le into its database.
ACME Table Name VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST Klingon Database Map Column Name TAG PIPING DRG CLASS PID NO SPEC LINE TAG PIPE SIZE UOM VNUM VALVE TYPE VUNIT VALVE TAG Neutral File
Column Name TAG PIPING DRG CLASS PID NO SPEC LINE TAG PIPE SIZE VNUM VALVE TYPE VUNIT VALVE TAG
Dictionary Name wa' cha' wej loS vagh jav Soch chorgh Hut wa'maH wa'maH wa' wa'maH cha'
Fig. C.9 Data export using a Klingon neutral le.
Appendix C
143
Neutral File
Klingon Database Map Dictionary Name wa' cha' wej loS vagh jav Soch chorgh Hut wa'maH wa'maH wa' wa'maH cha'
Column Name RECORD_ID DWG_NO RATING PID MAT_SPEC LINE_TAG DIAMETER DIAMETER_UOM SEQ_NO VALVE_TYPE UNIT TAG
EMCA Table Name TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32
Column Name RECORD_ID DWG_NO RATING PID MAT_SPEC LINE_TAG DIAMETER DIAMETER_UOM SEQ_NO VALVE_TYPE UNIT TAG
Fig. C.10 Data import using a Klingon neutral le.
Example 2.2: Creating a Custom Dictionary Using an Ontology

Of course your organization would not really use Klingon for dictionary terms; it would probably use a collection of nouns and adjectives that were themselves descriptive of the terms they describe.2 For a single, small information exchange you could probably live with ad hoc names. But as you add applications to your federation of applications you will probably run across many terms that are similar, with only subtle variations. As you add denitions to your dictionary, you may nd 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 nd that your database administrator can read Klingon directly.
Appendix C
144
drawing_no_piping_ortho maintenance_tracking_no piping_line_no piping_line_no_sequence piping_material_spec piping_nominal_diameter piping_uom plant_id pressure pressure_class pressure_design pressure_test production_train_id production_unit_id row_id<End TB>
From here it is a simple matter to construct a database map and export the data to a neutral le, just as we did with the Klingon dictionary. Figures C.11 and C.12 show what this might look like.
ACME Table Name VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST Database Map Column Name TAG PIPING DRG CLASS PID NO SPEC LINE TAG PIPE SIZE UOM VNUM VALVE TYPE VUNIT VALVE TAG Neutral File
Column Name TAG PIPING DRG CLASS PID NO SPEC LINE TAG PIPE SIZE VNUM VALVE TYPE VUNIT VALVE TAG
Dictionary Name row_id drawing_no_piping_ortho pressure_class drawing_no_pid piping_material_spec piping_line_no piping_nominal_diameter length_uom maintenance_tracking_no component_type_valve production_unit_id asset_tracking_no
Fig. C.11 Data export using an ontological neutral le.
Appendix C
145
Neutral File
Database Map Dictionary Name Column Name row_id RECORD_ID drawing_no_piping_ortho DWG_NO pressure_class RATING drawing_no_pid PID piping_material_spec MAT_SPEC piping_line_no LINE_TAG piping_nominal_diameter DIAMETER length_uom DIAMETER_UOM maintenance_tracking_no SEQ_NO component_type_valve VALVE_TYPE production_unit_id UNIT asset_tracking_no TAG
Table Name TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32
EMCA Column Name RECORD_ID DWG_NO RATING PID MAT_SPEC LINE_TAG DIAMETER DIAMETER_UOM SEQ_NO VALVE_TYPE UNIT TAG
Fig. C.12 Data import using an ontological neutral le.
We have used a very simplied 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 denitions, new users will be more likely to choose the correct term without having to talk to anyone. The bad news is that if you have never created an ontology your rst few attempts will likely require reworking every time you add a new application to your federation. An easier way is to use an ontology that someone else has developed. In the next example, we will introduce such an ontology based on Part 4.

Building a custom dictionary means that information exchange partners will not have to learn everything all over again every time they wish to exchange information. New partners are a bit better off because they do not have to start from scratch, but they still have a fair amount of work to do. They will still have to review the dictionary to thoroughly understand the terms,
Appendix C
146
and may nd that some terms conict 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 Dont We Use Industry Standard Denitions?

Using Part 4 denitions 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 les they use for information exchange. Being able to export information into an industry standard format will allow them to exchange information with other organizations as well. The RDS/WIP is just such a dictionary. It was commissioned in the mid 2000s as an experimental reference data service anyone could use as a referenceand 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 le format. EMCA imports the information using its database map to translate the information into something its systems understand.

The major difference here is that instead of consulting a growing proprietary dictionary all who are involved refer to the public standard. However, partner organizations will still need to have a discussion about how they will use the core terminology whenever two terms mean almost the same thing. New applications added to the confederation will still be subject to a detailed discussion. In addition, a new application may use existing terminology in slightly different ways. If so, the partner organizations will have to decide whether or not to change the term or to modify the new application. But changing the meaning of a term could have a serious effect on existing applications.
New Role
There is a new role here. Someone has to learn how to use the RDS/WIP.3 The RDS/WIP modeler, who will learn how to use the RDS/WIP, how to read the taxonomy of existing terms, and how to prepare new submissions.
3. Remember that the RDS/WIP is experimental. When ISO 15926 is mature, there will be a selection of RDLs to choose from.
Appendix C
147
At the end of this appendix we have included a brief introduction to the RDS/WIP, but basically you just search for a term and nd the closest match. If two or more terms are close in meaning, you will have to negotiate with your business partner to decide which to use. If a new term is required, you add it. Once you decide on the term, you will actually use the universal resource indicator (URI; more-or-less the terms 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 http://rdl.rdlfacade.org/data#R32813486958 http://rdl.rdlfacade.orgdata#R16893283050
Description An identication code for a drawing or a class of drawings Classes of standard pressure ratings (i.e., the maximum allowable non-shock working gage pressure at a given temperature and a specic material) A diagram showing a schematic representation of a process system, including instrumentation A specication that describes the applicable materials for one or more items An identication code that identies a pipeline Intercept made by the circumference on a straight line through the center of a circle A role used in ST 3401 to designate the applicable scale in which the numerical value is expressed
IDENTIFIER DRAWING IDENTIFICATION CODE
PRESSURE RATING CLASS
http://rdl.rdlfacade.orgdata#R45649298385
P AND I DIAGRAM MATERIAL SPECIFICATION PIPELINE OFFICIAL IDENTIFIER DIAMETER
http://rdl.rdlfacade.org/data#R99486931975
UNIT OF MEASURE
Appendix C
148
SEQUENCE NUMBER PR3 1.10 VALVE TYPE/ DESIGN FUNCTIONAL UNIT IDENTIFIER TAG IDENTIFICATION CODE
A number assigned following an order of succession Assignment of valve type (e.g., safety, relief, or safety relief), and design (e.g., conventional, bellows, or pilot) An identication code that identies a functional unit An identication 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 le. Figure C.15 shows how EMCA will create its own map with which to import the data from the neutral le. Note that instead of English descriptive names we are using long numerical text strings. Astute readers will notice that this is conceptually the same as using Klingon. And if that is where we stopped, the readers would be correct.4
ACME Table Name VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST Column Name TAG PIPING DRG CLASS PID NO SPEC LINE TAG PIPE SIZE Column Name TAG PIPING DRG CLASS PID NO SPEC LINE TAG PIPE SIZE UOM VALVE_LIST VALVE_LIST VALVE_LIST VALVE_LIST VNUM VALVE TYPE VUNIT VALVE TAG VNUM VALVE TYPE VUNIT VALVE TAG Database Map Dictionary Name http://rdl.rdlfacade.org/data#R32813486958 http://rdl.rdlfacade.org/data#R16893283050 http://rdl.rdlfacade.org/data#R45649298385 http://rdl.rdlfacade.org/data#R99486931975 http://rdl.rdlfacade.org/data#R54400593721 http://rdl.rdlfacade.org/data#R83498125174 http://rdl.rdlfacade.org/data#R94482935208 http://rdl.rdlfacade.org/data#R58177039466 http://rdl.rdlfacade.org/data#R73944050980 http://rdl.rdlfacade.org/data#R49125478120 http://rdl.rdlfacade.org/data#R14322658775 http://rdl.rdlfacade.org/data#R99047027503 Neutral File
Fig. C.14 Data export using RDS/WIP class names.
4. In fact, if the organizations were to hard-code the denitions they would be better served to use the Label from Table C.3 rather than the URI. We used the URIs in order to introduce the next section.
Appendix C
149
Neutral File
Database Map Dictionary Name http://rdl.rdlfacade.org/data#R32813486958 http://rdl.rdlfacade.org/data#R16893283050 http://rdl.rdlfacade.org/data#R45649298385 http://rdl.rdlfacade.org/data#R99486931975 http://rdl.rdlfacade.org/data#R54400593721 http://rdl.rdlfacade.org/data#R83498125174 http://rdl.rdlfacade.org/data#R94482935208 http://rdl.rdlfacade.org/data#R58177039466 http://rdl.rdlfacade.org/data#R73944050980 http://rdl.rdlfacade.org/data#R49125478120 http://rdl.rdlfacade.org/data#R14322658775 http://rdl.rdlfacade.org/data#R99047027503 Column Name RECORD_ID DWG_NO RATING PID MAT_SPEC LINE_TAG DIAMETER DIAMETER_UOM SEQ_NO VALVE_TYPE UNIT TAG
EMCA Table Name TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 TABLE_32 Column Name RECORD_ID DWG_NO RATING PID MAT_SPEC LINE_TAG DIAMETER DIAMETER_UOM SEQ_NO VALVE_TYPE UNIT 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 dictionarysimply using the URIs of the denitions 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 RDLusing the RDS/WIP to verify that it is compliant before sending it out. After EMCA receives the intermediate le, it validates the terminology against the RDS/ WIP to verify compliance.
Appendix C
150
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 number of commercial and open-source tools to make this task easier.)

Readers may wonder what the difference is between hard coding terminology into a database map and validating with live URIs as the exchange is made. If the hard-coded term is identical to the URI in the RDS/WIP, what does it matter? The answer is that if you were to exchange information only between a few well-known applications or a few well-known business partners there would be no effective difference between hard-coded and live URIs. But the vision of ISO 15926 is that any two organizations will be able to exchange information with a minimum of preparation required. Having both the sender and receiver validate the URIs during the exchange increases each partys condence 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 denitions (and Part 4 denitions in particular) is the minimum requirement for compliance with ISO 15926, there is still room for ambiguity. For in-
Appendix C
151
stance (to reuse an example from the Introduction), just because a native Mandarin speaker and a native Cantonese speaker understand English well enough to use it as an intermediary language it does not necessarily mean they will be able to communicate seamlessly from the very beginning. Because they come from different cultures, they may nd that they use some words differentlywhich means that when rst communicating there must be a time when denitions are veried. For others to know what we mean by certain terms, without having to go through the process of verifying what we mean, we need a way to embed the context in which we use these terms into the data. In addition to using Part 4 to make sure our terminology matches the industry standard, when we also use the syntax and grammar of ISO 15926 (which is Part 2) we are doing just that. Using Part 7 templates makes it easier to use Part 2 correctly. Exchanging information with Part 7 templates is fundamentally different from dictionary mapping. The purpose of this example is to give you a glimpse of how different it is, without becoming a How to lesson. This example will show how the use of part 7 templates means that the meaning (or context) of the data is stored with the data so that we do not have to engage our business partners in discussions of what the data means before sending information. We have seen a trend toward this throughout the examples in this appendix. We started off with mapping one database directly to another, where both parties had to know a great deal about each others 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 RDLswhere 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 gure it out. This is the essence of ISO 15926: we can exchange information with anyone without having to know anything about their internal systems beforehand.
Example 4.1: Using Templates to Exchange Information

Figure C.17 shows ACME and EMCA using Part 7 templates to structure their data so that its meaning will be part of the exchange. ACME and EMCA will still use Part 4 as the data dictionary, and will still use the RDS/WIP to validate the information on each side of the exchange, but in addition they will structure their data according to Part 2. The easiest way to do this is to use the base templates in Part 7 to build the database maps with which they will export (or import) the neutral data exchange le. ACME and EMCA collaborate and agree to use Part 7 (which implies Part 2) and Part 4. Each organization creates information models, or maps, to transform its internal data structures to something that follows the ISO 15926 protocols. They use the base templates in Part 4, and the methodology in Part 7, to create new templates when required. ACME selects certain data and exports it using the database map, based on Part 7 templates, to translate it to the agreed neutral le format. As it is assembling the neutral le, the templates validate the information against the core classes in the Part 4 RDL (using the RDS/WIP). ACME sends the neutral le to EMCA.
Appendix C
152
EMCA receives the neutral le and processes it in reverse. EMCA uses its database map, based on Part 7 templates, to translate the information in the neutral le into something its systems understand. EMCAs templates understand how to read the meaning from the structure of the data in the neutral le.
Fig. C.17 Use ISO 15926-7 for information exchange.

The level of collaboration required in this case is much less than in the previous case. After both companies implement Part 7, all they will need to know from each other is the general nature of the information to be exchanged. Neither party has to know anything at all about the way the other creates and uses the information because the context of the information is contained within the information itself. The addition of Part 7 adds some initial work to fully understand the landscape of different applications and model them properly, but thereafter the actual data exchange becomes much simpler.
New Role
An information modeler will map business objects in the applications to the prepared templates in Part 7.
Metaphor
So that you can understand what the exchange is trying to accomplish, we will start with a
Appendix C
153
metaphor about making inferences. Suppose we were to make this assertion: Barack Obama - is the - President of the United States. Most people today who read the news will have no trouble understanding what this statement means. But suppose your name is Valentine Michael Smith and you have just been repatriated to Earth after being born on Mars and raised by Martians for twenty years.5 You would not even have the concept of government, let alone of presidentand the political divisions the rest of us know as countries would not occur to you naturally, so you would have no way to understand this. However, if someone were to tell you that Barak Obama is human you would be able to infer that he has hair simply because you are human too and have hair. Moreover, you would be able to deduce this well before grokking any earthling political nonsense. Similarly, in this example ACME will create some information about a pressure transmitter and send it to its business partner EMCAwhich 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
ACMEs intention is to pass information about a pressure transmitter, which has the tag number PT-101 and 3/4-inch NPT connections, to EMCAwhich will fabricate some pneumatic tubing to connect to it. ACME will rst identify the device using the template ClassificationOfIndividual, which has two columns (or roles, Individual and Class)as shown in Figure C.18. ClassicationOfIndividual Individual xyz Pressure Transmitter Class URI of the class
Fig. C.18 Use of the ClassicationOfIndividual template.
Individual: xyz
xyz is the identier 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 ction for his own good, believes that a metaphor involving a human being raised by Martians to be totally plausible. If you read Stranger in a Strange Land, by Robert Heinlein, the metaphor will make more sense.
Appendix C
154
Class: The URI of the Class Pressure Transmitter

In our previous examples, we showed how ACME could interrogate the appropriate RDL to nd the URI of a given term or class. If humans were intended to read this, ACME might consider using the English description of the class. However, because this template is intended for a computer the URI is actually easier to use. Once the transmitter has been classied, the next step is to identify it using the template ClassifiedIndividual (Figure C.19)which has three roles: Individual, Name, and ClassificaitonOfIndividual. ClassiedIndividual Individual xyz Name PT-101 ClassicationOfIndividual URI of, say, ISA
Fig. C.19 Use of the ClassiedIndividual template.
Individual: xyz
xyz is ACMEs internal identier.

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.
ClassicationOfIndividual: ISA
ISA will tell other users the way the name is to be interpreted. In this case, ACME is using the convention ISA (for Instrument Society of America). But, as before, instead of using the text string ISA it uses the URI of the class ISA. The next templates (Figure C.20) will contain the properties of the transmitter. For this, ACME will use two different templates: IndirectPropertyScaleReal (which has the four roles Individual, Property, Value, and Units of Measure) and IndirectProperty (which has the three roles Individual, Property, and Value).
Appendix C
155
lndirectPropertyScaleReal Individual xyz Property URI for the class Operating Pressure Value 100 Units of Measure URI for the class of kPa
lndirectProperty Individual xyz Property URI for the class End Connection Value URI for the class of NPT
lndirectPropertyScaleReal Individual xyz Property URI for the class Connection Size Value 0.75 Units of Measure Inches
Fig. C.20 Use of the IndirectPropertyScaleReal and IndirectProperty templates.
EMCA
When EMCA receives the information, its system will rst look through the data for the template ClassificationOfIndividual, and everything associated with it, using the identier 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 identiers. For the example of PT-101, we will use abcas indicated in Figure C.21. ClassicationOfIndividual Individual abc Pressure Transmitter
Fig. C.21 Individual identiers in the ClassicationOfIndividual template.
Class URI of the class
Class: Pressure Transmitter

EMCAs system does not know what to do with Pressure Transmitter not because its engineers have never heard of such a device but because it has no reason to care. Rather than store all of the different types of devices to which its pneumatic tubes might potentially connect, it simply ignores the class. What EMCAs system looks for is the templates containing the operating pressure, the thread form of the connection, and the size of the connectionas 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 fulllment system.
Appendix C
156
lndirectPropertyScaleReal Individual abc Property URI for the class Operating Pressure Value 100 Units of Measure URI for the class of kPa
lndirectProperty Individual abc Property URI for the class End Connection Value URI for the class of NPT
lndirectPropertyScaleReal Individual abc Property URI for the class Connection Size Value 0.75 Units of Measure Inches
Fig. C.22 Templates containing operating pressure, thread form of connection, and size of connection.
Some Questions
Q1. Couldnt 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 EMCAs systems. Q2. So why use templates? A2a. Computers can do this type of work much more quickly and reliably, once we teach them how. This lets humans do more interesting things. A2b. This is a really simple example. The relationships can get quite a bit more complicated. Q3. How do you know which templates to use? A3. Funny you should ask. In Chapter 4, we mentioned the Practical Guide for ISO 15926 Modeling, If you want to learn more about using templates, this should be the next book you read. If you think information modeling using Part 7 templates is interesting, we can tell you that there is going to be a demand for experts who understand the things their industry segment deals withand who also have an aptitude for abstract reasoning. If this describes you, give someone a call. Weve got a very interesting career lined up for you!
Appendix C
157
Using the RDS/WIP

The RDS/WIP was commissioned in the mid 2000s as a proof-of-concept for an RDS. The classes that make up Part 4, the dictionary of ISO 15926, were used as seed material. Since its inception, many denitions 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 denitions A platform for developing new ISO 15926 denitions 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 HTTPto provide machine-oriented access to the stored denitions. A conventional HTML presentation is used to provide a human-oriented interface to the same system. Anyone can search the RDS/WIP and nd terms, much like in a dictionary. Accredited users can add information to the RDS/WIP. We need to point out here that Part 4 intends that RDLs be federated. Therefore, it is in the best interest of the industry to ensure that each authority be responsible for its own RDL to ensure that the distributed nature of the Internet can be used. Although the RDS/WIP is the largest repository to date, this should be seen as only the rstand it is everyones challenge, especially equipment vendors, to ensure they have their own information on their own approved RDL.
Web Address for RDS/WIP

rdl.rdlfacade.org. When you navigate to this site with a web browser, it defaults to a search screen you can use to examine the taxonomy of RDS/WIP terminology.
RDL Facade Rules

Table C.4 outlines RDL facade rules.
TABLE C.4
RDL FACADE RULES
Rule Not case sensitive
Purpose Search strings are not case sensitive Returns all terms containing the full search string Returns terms beginning with the search string Returns a single exact match
search-string ^search_string ^search-string$
Appendix C
158
Examples
In the search box, search for the items indicated in Table C.5.
TABLE C.5
SEARCH BOX ITEMS
Item
Purpose RDS/WIP will return all terms containing the word temperature, in groups of 20. RDS/WIP should return the same results because it is not case sensitive. RDS/WIP will return all terms beginning with the word temperature. RDS/WIP should return only one term, TEMPERATURE.
Temperature TEMPERATURE ^temperature ^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 The URI for the term TEMPERATURE. If you enter this text string into your web browser, you will be taken to this page. The ofcial designator for this term. Within the database, this designator is unique. This helps you know whether or not you have the correct term. Think of this as the general category to which TEMPERATURE belongs.
RDS/WIP URI Label Description Entity Type
We have just scratched the surface of how to use the RDS/WIP effectively. In Appendix D, in the section about iRING, we have included a link to a document Discovering the Right Class for ISO 15926. We will leave further discussion for another book.
Appendix C
159
APPENDIX D: OTHER RESOURCES

Information Modeling Resources
The barriers to digital interoperability are no longer hardware and technology, but rather information modeling. To truly develop ubiquitous digital interoperability, we will need robust information models that describe project objects and the relationships between themfrom their inception, through operation, to demobilization. This provides a distinct growth opportunity for engineers who understand that information about plant objects is as valuable as the objects themselves. When we have a large knowledge base, classied 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 Shells Information Management department, and was a developer of parts of ISO 15926 before he retired. He has posted many of his publications on his web site: http://www.matthew-west.org.uk/publications.html There is a wealth of information here for those introducing themselves to information modeling. Dr. West was part of the development of several of the STEP parts, and later ISO 15926. If you start near the bottom, you will see the progression from one to the other. If you are new to information modeling, we suggest you start partway downwith 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 Ontologa community devoted to advancing the eld of ontology. The lecture is titled An Introduction to ISO 15926 with Podcast (40 Mbyte) and is available from ONTOLOG (2006).
Hans Teijgelers Modeling Site
Appendix D
160
Hans Teijgeler has been inuential in developing some of the parts of ISO 15926. In his retirement, he has developed a web site that explains the way data modeling is done with ISO 15926. http://www.15926.info/index.htm Hans uses a diagramming technique that you will see if you start working directly with Part 2, instead of Part 7.
IOHN Modeling Guide

We described the Integrated Operations in the High North (IOHN) project in Chapter 4. It is a unique collaboration between the IT, defense, and oil and gas industries. It is a proponent of ISO 15926 because ISO 15926 will enable more efcient and safer operation of remote sites. For their members, they have developed a training course on ISO 15926 and an introduction to information modelingwhich they have recently released to the public. https://www.posccaesar.org/wiki/ISO15926Primer_OtherResources On this page, you will see the following three attachments. IHON Modeling Guide Part 1 IHON Modeling Guide Part 2 IHON Modeling Guide Lecture Notes
Origin of ISO 15926

David Leal, of CAESAR Systems Limited, is one of the developers of parts of STEP and ISO 15926. In 2005, he published a paper ISO 15926 Life Cycle Data for Process Plant: An Overview. In it he explains why ISO 15926 was developed. He describes what he calls the 4D approach to representing change in a way that can be represented with RDF/OWL. It has been made available free of charge. Search for the paper by its title, or go to this site: http://ogst.ifpenergiesnouvelles.fr/index.php?option=com_article&access=standard&Itemid=12 9&url=/articles/ogst/pdf/2005/04/leal_vol60n4.pdf
Organizations Responsible for ISO 15926

We have described these organizations in Chapter 2.
ISO TC184/SC4
http://www.tc184-sc4.org/ ISO Technical Committee 184 Subcommittee 4 Industrial Data
Appendix D
161
POSC Caesar Association

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

This gives advice on choosing the correct class during searches in a reference data service (RDS) browser. http://iringug.org/wiki/index.php?title=Discovering_a_Class_in_ISO_15926
Appendix D
162
Other Organizations
MIMOSA
http://www.mimosa.org/ MIMOSA is a not-for-prot trade association dedicated to developing and encouraging the adoption of open information standards for operations and maintenance in manufacturing, eet, and facility environments. MIMOSAs open standards enable collaborative asset life-cycle management in both commercial and military applications. We have described MIMOSA and their two joint special interest groups with Fiatech and PCA in Chapter 4.
European Committee for Standardization

http://www.cen.eu/cen/AboutUs The European Committee for Standardization (CEN) is a business facilitator in Europe, removing trade barriers for European industry and consumers. Its mission is to foster the European economy in global trading and the welfare of European citizens and the environment. Through its services it provides a platform for the development of European standards and other technical specications. The members of CEN work together to develop standards for European business. In the fall of 2010, they conducted the ORCHID workshopdiscussed in material following.
Orchestration of Industrial Data

http://www.cen.eu/CEN/sectors/sectors/isss/workshops/Pages/workshoporchid.aspx The ORCHID (Orchestration of Industrial Data) group is a network of European companies and consortia dedicated to standardizing information across the process industry engineering supply chain to build competitive advantage. Its goal is to progress the industry toward interoperability. In Chapter 5, we presented an approach to implementing ISO 15926 that even small organizations can follow. It could be, however, that your organization is ready for a more comprehensive rollout. If so, you will nd the proceedings of the ORCHID workshop interesting. The purpose of this workshop was to create an interoperability roadmap for organizationsstarting, most importantly, with a self-assessment and an assessment of ones business partners. The web page cited previously contains six attachments that can be downloaded. Part 1: Direction and Framework Part 2: Implementation Guide Part 3: Standards Landscape The CEN ORCHID Roadmap: Implementation Guide The CEN ORCHID Roadmap: Direction and Framework ORCHID: Orchestrating Industrial Data, Workshop Overview
Appendix D
163
RDS Browsers
The classes that make up Part 4, the dictionary of ISO 15926, are stored in what is called the RDS/WIP (Reference Data System/Work in Progress). To search the classes you need to use an RDS/WIP browser. For more information about RDS/WIP: http://rdswip.ids-adi.org/presentation/overview/index.html There are a number of browsers for the RDS/WIP. These are described in the sections that follow.
rdlfacade
The RDS/WIP Search, otherwise known as the RDL Facade, was created during the early development of ISO 15926. http://rdl.rdlfacade.org
POSC Caesar Part 4 Browser

POSC Caesar has its own library of reference data (at the following address), presented in the form of spreadsheets. http://rds.posccaesar.org/2008/05/XML/ISO-15926-4_2007/ POSC Caesar RDL Explorer http://193.212.132.108/apps/rdsclient.html Log in as guest. Instructions on using the POSC browser can be found at the following address. http://15926.org/home/tiki-index.php?page=Tutorial+ISO+15926+part+4
DNV Reference Data Browser

Det Norske Veritas (DNV) is one of the three largest insurers in the world, along with Lloyds Register and the American Bureau of Shipping. It became interested in ISO 15926 as a result of assessing risk in shipping. A common way to describe physical facilities makes it easier to compare the facilities to common benchmarks. DNV has participated in some of the development work of ISO 15926 and has created its own RDS browser. http://projects.dnv.com/reference_data/RD7Browser/browser.aspx?id=part4:RDS415124
Business Interface Denition 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 efcient handover of information from engineering procurement and construction (EPC) contractors and constructors to owneroperators. After a facility has been built and commissioned, document and information hando-
Appendix D
164
ver must often operate on what is left of the project budget after the original engineering and construction staff have moved on to their next project. It is sometimes difcult for the owner to get all of the information it needs, and in a form that is immediately useful. One barrier to adequate information handover in the capital projects industry is getting all parties to agree at the beginning of a project what needs to be handed over. So that every project does not have to develop its handover requirements from scratch, a number of handover guides have been createdand more are contemplated. We have come to refer to the discussion of information handover guides as the The Business Interfaces Denition Guide (BIDG). The handover guides developed to date all discuss the importance of good data handover and offer ways of ensuring that this will actually happen on a given project. One of them, published by EPISTLE, explicitly lists deliverables by name and is organized by engineering discipline. One barrier to getting more specic is a common denition 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 rst Process Industries Data Handover Guide was published to help project participants dene the scope of information turnover. The guide is issued in two parts. Part 1 concentrates on methodology, starting with understanding the business need for information, creating a plan to supply the information, and implementation. Part 2 focuses on recommendations for actual data items ranging from contract management documents, scheduling, materials, construction, and process to information on all of the components that make up the facility. As its basis, the EPISTLE handover guide used the PISTEP Process Plant Engineering Activity Model (see Chapter 2). This activity model was essentially a very detailed owchart 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, EPISTLEs guides are still worth readingalong with the NIST and EPRI guides. https://www.posccaesar.org/wiki/IdsAdiBIDG You will have to request a login from PCA to obtain access. Access is open to all members of PCA. Non-members can request access. Go to their membership page and follow the instructions at the bottom.
NIST/Fiatech Handover Guides

The NIST handover guide is issued in a number of parts, modeled after the EPISTLE handover guides. The Capital Facilities Information Handover Guide Part 1 was issued by NIST and Fiatech in 2006. Several second parts are envisioned, each to focus on the deliverables of a specic industry. The General Buildings Information Handover Guide was issued in 2007. Its focus is the general buildings industry, including commercial, industrial, and government buildings. This guide reviews the issues in designing and constructing an environment of short schedules and constant change. Several case studies are included, showing the successes and lessons learned for early adopters of building information modeling (BIM).
Appendix D
165
Capital Facilities Information Handover Guide, Part 1 http://re.nist.gov/bfrlpubs/build05/PDF/b05037.pdf General Buildings Information Handover Guide http://re.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 nd the report is to go to EPRIs home page and search for handover guide. which will take you to a page where you should nd the report listed.
Appendix D
166
GLOSSARY OF CONCEPTS
There are already enough glossaries of computer science terms available on the Internet that we do not need another comprehensive listing. The purpose of this glossary is to use the language of beginners to expand on some of the concepts useful in understanding ISO 15926. We should warn you that we have used some artistic license here. We do not recommend you use any of these denitions on an important exam!
Articial Intelligence and the Semantic Web: Difference Between

Articial intelligence: Making machines smarter Semantic Web: Making data smarter We all want to be able to nd and use information on the World Wide Web easier and more reliably. The articial 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 nd, access, and process) by using techniques for expressing data and meaning in a standard machine-readable format. ISO 15926 Parts 8 and 9 use Semantic Web technology to describe plant objects in a way that computers can understand.
First-order Logic, Semantics, and Reference Data

First-order logic: If you have ever taken a mathematics course where you have had to prove something you have used rst-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 rst farm they passed, they saw a black sheep standing in a eld. Look! said the farmer, Scottish sheep are black! You cant 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! Youre 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 rst-order logic. This joke makes rst-order logic seem pedantic. But what if, after the three went back home, they were offered an investment that depended on
Glossary
167
there being a ready supply of black wool? Wouldnt 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 ones presuppositions into ones 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 Alices 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 Id meant that, Id have said it, said Humpty Dumpty.
Semantics has to do with meaning. Sometimes the word is used derisively, as in Yes, but thats 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 eld 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 delity is the degree to which the original meaning of a term survives an information exchange. We are looking for high semantic delity to make sure the meaning of data values is preserved on the receiving end. Reference data: We return to Alices 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. Theres glory for you! I dont know what you mean by glory. Alice said. Humpty Dumpty smiled contemptuously. Of course you donttill I tell you. I
1. Through the Looking Glass, by Lewis Carroll.
Glossary
168
meant, theres a nice knock-down argument for you! But glory doesnt 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 meanneither more nor less. The question is, said Alice, whether you can make words mean so many different things. The question is, said Humpty Dumpty, which is to be masterthats all.
If the denitions 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 denitions, that any of us can consult, we can communicate without ambiguity. The ISO 15926 RDL is the common set of denitions (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 lter (usually starting with Is it animal, vegetable, or mineral?) The game ends when there is only one object left, the answer, that satises membership (or nonmembership in the case the answer to Is it a ...? is No!) in all ontologies. Taxonomy: If you have ever made a classied list of all your CDs, you have made a taxonomy. (But if you are as old as the author, CDs are old hat. You learned how to do this years ago with your player piano rolls!) And if you have ever had to grapple with the question of where to classify Weird Al (under Parody, Rock and Roll, or Idiot!), you have come up against the idea of single or multiple inheritance. Ontology and taxonomy are both terms in a continuum that information scientists call knowledge organization systems (KOS). And just to confuse you some more, the continuum includes thesaurus, controlled vocabulary, and faceted classicationamong 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 denitions that have been organized into a hierarchical structure. They tend to be organized in tree-like structures that are reasonably easy to understand, even by non-specialized people. Each term is related to its parent in an is a type of relationship. For instance, a car is a type of automobile. But a car also a type of machine, so if your taxonomy is concerned with machines you should analyze the relative order of these three things.
Glossary
169
Depending on the purpose of your taxonomy, you might end up with something like this: Car is a type of automobile, which is a type of machine. In the realm of philosophy, ontology is the study of being; the study of the things that are. In the realm of information science (which is where ISO 15926 rmly resides), ontology has a more formal meaning. The Wikipedia denition says that an ontology is a formal representation of a set of concepts within a domain and the relationships between those concepts. (HmmThis is one of those denitions that does not start to make sense until you already know what it means. Lets try something else.) Like taxonomies, ontologies are also arranged in an is a type of relationship, but the relationships tend to be more richly dened. 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 les, whereas the ontology would be the les organized by the directory structure. In Chapter 2, we talked about an ontology of things that will carry a bicycle. That ontology was the entire collection of things that can carry a bicycle that the author held in his head in case his bicycle were to break down on the way to work. Each object in the ontology would have a taxonomy you could examine. Generalization and specialization: The is a type of relationship is known as generalization/specialization. In the previous example, car is a specialization of automobile; automobile is the generalization of car. Subtype and supertype: Subtype/supertype is just another way of saying generalization/specialization. Continuing the previous example, car is a subtype of automobile; automobile is a supertype of car. The understanding is that the subtype has all the constraints of the supertype, plus one or more additional constraints.
Integration and Interoperability: Difference Between

Interoperability: An early example of digital interoperability, probably even before the phrase was coined, is the centerpiece of the 1970 movie Colossus: The Forbin Project. It was released near the height of the Cold War, in an era when people were starting to hear about these newfangled computer-thingies and to wonder how they would affect us. In the movie, the (one and only) supercomputer in the United States, Colossus, tunnels under the Atlantic Ocean using something like what we call the Internet today and nds the (one and only) supercomputer in the Soviet Union, Guardian. Recognizing themselves as kindred spirits, Colossus and Guardian naturally start talking to each other and by the end of the movie have taken over the world and enslaved humanity. Now thats interoperability! Basically, this is what ISO 15926 intends to achieve (minus, of course, the taking-over-the-world-and-enslaving-humanity part.) Integration:
Glossary
170
If you are a Start Trek fan and have watched one of the episodes where the crew of the Enterprise encounters the Borg, you have seen one denition of integration: basically, a bunch of individual things becoming part of a whole (other) thing with all parts working together seamlessly. Comparing Interoperability and Integration Colossus is probably classied in the apocalyptic science ction genre, but if you are involved in any way in moving information from one computer system to another, parts of it will be high comedy. The movie portrays supercomputers as being naturally aware of each other, sort of like two dogs being walked in the same park. Then the movie suggests that supercomputers somehow have the innate ability to communicate. The truth is, unless a pair of computers had been specically programmed to do so they would not even know of each others existencelet 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 eld of information exchange, both imply that information can ow between two computer programs more or less seamlesslywithout anyone having to rekey any of it. It is not until we start digging into the various methods of achieving this seamless information exchange that we can zero in on the differences. Interoperability implies that the two computer programs are their own agents, but somehow know how to speak the same language. Integration implies that the computer programs achieve the information exchange by having hooks into each other. In the context of ISO 15926, interoperability means that two or more computer applications are able to exchange information because they all, independently of each other, use a common standard for exchanging information. There is no requirement that any of them know about any of the others beforehand. It is like buying a Bluetooth headset for your cellular phone and then being pleasantly surprised that after replacing your phone the headset works with the new one too. In the context of ISO 15926, integration means that two computer applications are able to exchange information because the developers of each did some custom work to make them able to do so. The end result of this working together may in fact be identical, better than, or worse than the working together in our denition of interoperability.
Strong Coupling, Loose Coupling, and Encapsulation

Interoperability with ISO 15926 is achieved by what is called loose coupling, whereas integration implies strong coupling. In the eld of computer science, strong coupling means that a function in one application is directly controlled by a function in another application. Loose coupling means that when two programs communicate but the components of one system do not directly make use of knowledge of the other system. For example, suppose that your neighbor occasionally needs a light shining on a particular place in his backyard that is hard to illuminate from anywhere in his own yard. Further suppose that because there is a particularly good vantage point in your yard you agree to mount a light for him and turn it on whenever he wants.
Glossary
171
Strong coupling: You install the light and let your neighbor run a line from his house to your breaker panel so that he can control the light directly from his own house. Loose coupling: You install the light, but tell the neighbor to phone you and you will turn it on for himperhaps giving him a performance guarantee of 30 seconds. Encapsulation: The example of loose couplingasking your neighbor to call you when he wants the light turned onis also an example of encapsulation. In computer science, one denition of encapsulation is a mechanism in an object-oriented programming language that restricts access to some of an objects 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 exibility. For instance, at the beginning you might guess that he will not call you very often so you just install a bright ashlight, 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 ashlight in place until the new one is in place. Unless your neighbor happens to look out his window at the right time, he will not even know that you are running a power line and changing the light. Later, when you install the computer-controlled switch you can do it during the daytime so as not to risk being in the middle of the changeover when he calls.
Abstraction
Abstraction is a process of generalizing about something to reduce the information content about an object to only those attributes you are interested in. If you wanted to get a visceral reaction from the class of North American males who, like your humble author, were pubescent boys in the early 1960s, show them a glossy photograph of a 1963 Corvette Stingray with the top down. (To clinch the effect, add a blonde surfer babe in the passenger seat with her hair streaming back in the wind!).
Glossary
172
In this example, you reduce the Corvette Stingray to ink on paper. The printer sees the ink, but the now-geriatric boys see the actual car they remember from their youthwhich at the time was the epitome of style and performance. Of course you could get an actual car (and an actual surfer babe)but that would cost a lot of money and would run the risk that the geezers would run off with the car and get themselves killed. The photograph will get the gut reaction you are after, and the worst they can do is steal the picture!
Semantic Web Technology

The large majority of ISO 15926 users will not need to know anything more about the Semantic Web. But if you are curious on how things like ISO 15926 work you may nd it interesting to learn a little bit more. The Semantic Web provides a common framework that allows data to be shared and reused across application, enterprise, and community boundaries. It is a collaborative effort led by W3C, with participation from a large number of researchers and industrial partners. It is based on the Resource Description Framework (RDF).
Resource Description Framework

If you dig deeper under the hood of ISO 15926, you will soon run into this term because it is the used by OWL (the basis of Part 8). Wikipedia says that the RDF is a set of specications originally designed as a metadata data model. But if you are like the author, this does not help at allso we will deconstruct the denition. Metadata: Metadata is data about data. For instance, one piece of metadata about the Introduction to ISO 15926 is that it was originally written with a wiki on the POSC/Caesar web site. Another piece of metadata is that the original name was ISO 15926 Primer. Data model: A data model is an abstract model that describes how data is represented and accessed. Putting it all together, then, RDF is: Instructions on how to represent just the bits of data you are interested in that describe certain other bits of data and on how to then access the data easily. Whew! I bet you thought that was going to be difcult! 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 identier (URI).
Glossary
173
Uniform Resource Identier

You can think of a URI as a web address for a piece of information. This allows the same resource to be reliably referenced many times. Thus, instead of writing the subject-predicateobject triple in words (as previously) it could be rendered as follows. Subject: https://www.posccaesar.org/wiki/ISO15926Primer Predicate: was written on Object: POSC/Caesar wiki In fact, we could carry this further by dening 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 persons street address (i.e., where). URN (uniform resource name): Like a persons name (i.e., what). URI (uniform resource identier): URLs and URNs are URIs, but a URI can be a name and a locator at the same time.
Glossary
174
3925 West Braker Lane (R4500) Austin, TX 78759-5316 t: (512) 232-9600 www.atech.org
Copyright 2011 Fiatech
Construction Industry Institute The Cockrell School of Engineering The University of Texas at Austin

Iso Intro Ver1

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Iso Intro Ver1

Загружено:

Авторское право:

Доступные форматы

ELEMENT 8 WORKFORCE & TRAINING

An Introduction to ISO 15926

An Introduction to ISO 15926

Raymond E. Topping, PE Director, Fiatech

CHAPTER 1: WHY WE NEED ISO 15926

CHAPTER 2: HISTORY OF ISO 15926

CHAPTER 3: HOW DOES ISO 15926 WORK?

CHAPTER 4: CURRENT EVENTS IN THE WORLD OF ISO 15926

CHAPTER 5: GETTING STARTED WITH ISO 15926

APPENDIX A: THE PARTS OF ISO 15926

APPENDIX B: COMPLIANCE WITH ISO 15926

APPENDIX C: EXAMPLES OF DATABASE MAPPING

APPENDIX D: OTHER RESOURCES

ISO 15926 Is Like a Babel Fish

ISO 15926 Is Like HTML

ISO 15926 Is Like English on Your Cell Phone

Use a mental dictionary to translate Cantonese to English

About This Book

How This Book Is Organized

Why We Need ISO 15926

The History of ISO 15926

How Does ISO 15926 Work?

Current Events in the World of ISO 15926

Development of Enabling Infrastructure

Continued Development of Standards

Getting Started with ISO 15926

CHAPTER 1: WHY WE NEED ISO 15926

The Role of Context in Information Exchange

Fig. 1.1 Putting information in a bag.

3. The information in a bag diagrams are courtesy of Robin Benjamins.

Fig 1.2 Putting information in an ISO 15926 bag.

Fig 1.3 Data handover the old way.

Seal Flush Pressure: Pressure Units: 1034 kPa

The Data Sheet Problem

Same Definition Different Definition

Convert to Imperial OPERATING CONDITIONS Rated Max. Normal Min.

Different Definition Different Definition

Fig 1.4 Comparison of two data sheets.

The Value of the ISO 15926 Dictionary

? temp press ifc

Fig 1.6 Real-life situation.

Fig 1.7 A custom solution.

Fig 1.8 A confederation of applications.

Fig 1.9 An enterprise-wide solution.

Engineering Application Line Table

Map to Common Dictionary

tag_no szTag szTag id

dia dDia dDia dia

len dLen dLen cl

temp dTemp dTemp temp

press dPress dPress press

ifc dateIFC dateIFC ifc

Map from Common Dictionary

Fig 1.10 A common dictionary of database denitions.

temp press ifc

dTemp dPress dateIFC

degF psig yyyymmdd

Map from Common Dictionary

Public Extensible Dictionary

Engineering Application Line Table

Map to Common Dictionary

tag_no szTag szTag id

dia dDia dDia dia

len dLen dLen cl

CHAPTER 1: WHY WE NEED ISO 15926

CHAPTER 2: HISTORY OF ISO 15926

CHAPTER 3: HOW DOES ISO 15926 WORK?

CHAPTER 4: CURRENT EVENTS IN THE WORLD OF ISO 15926

CHAPTER 5: GETTING STARTED WITH ISO 15926

APPENDIX A: THE PARTS OF ISO 15926

APPENDIX B: COMPLIANCE WITH ISO 15926

APPENDIX C: EXAMPLES OF DATABASE MAPPING

APPENDIX D: OTHER RESOURCES