Integration A Gentle Introduction to the SmartPlant Schema

Version 2008 January 2008 DSPF1-PE-200051C

ii

Copyright Copyright © 2006-2008 Intergraph Corporation. All Rights Reserved.

Including software, file formats, and audiovisual displays; may be used pursuant to applicable software license agreement; contains confidential and proprietary information of Intergraph and/or third parties which is protected by copyright law, trade secret law, and international treaty, and may not be provided or otherwise made available without proper authorization.

Restricted Rights Legend Use, duplication, or disclosure by the government is subject to restrictions as set forth below. For civilian agencies: This was developed at private expense and is “restricted computer software” submitted with restricted rights in accordance with subparagraphs (a) through (d) of the Commercial Computer Software - Restricted Rights clause at 52.227-19 of the Federal Acquisition Regulations (“FAR”) and its successors, and is unpublished and all rights are reserved under the copyright laws of the United States. For units of the Department of Defense (“DoD”): This is “commercial computer software” as defined at DFARS 252.227-7014 and the rights of the Government are as specified at DFARS 227.7202-3.

Unpublished – rights reserved under the copyright laws of the United States.

Intergraph Corporation Huntsville, Alabama 35894-0001

Warranties and Liabilities All warranties given by Intergraph Corporation about equipment or software are set forth in your purchase contract, and nothing stated in, or implied by, this document or its contents shall be considered or deemed a modification or amendment of such warranties. Intergraph believes the information in this publication is accurate as of its publication date.

The information and the software discussed in this document are subject to change without notice and are subject to applicable technical product descriptions. Intergraph Corporation is not responsible for any error that may appear in this document.

The software discussed in this document is furnished under a license and may be used or copied only in accordance with the terms of this license.

No responsibility is assumed by Intergraph for the use or reliability of software on equipment that is not supplied by Intergraph or its affiliated companies. THE USER OF THE SOFTWARE IS EXPECTED TO MAKE THE FINAL EVALUATION AS TO THE USEFULNESS OF THE SOFTWARE IN HIS OWN ENVIRONMENT.

Intergraph is not responsible for the accuracy of delivered data including, but not limited to, catalog, reference and symbol data. Users should verify for themselves that the data is accurate and suitable for their project work.

Trademarks Intergraph, the Intergraph logo, PDS, SmartPlant, SmartSketch, FrameWorks, INtools, MARIAN, and IntelliShip are registered trademarks and SupportModeler and SupportManager are trademarks of Intergraph Corporation. Microsoft and Windows are registered trademarks of Microsoft Corporation. Other brands and product names are trademarks of their respective owners.

iii

iv

Introduction

Have you heard the term SmartPlant integration or SmartPlant® Foundation (SPF)? Here is what it is: - A software-based platform that allows for integration of a wide-variety of

engineering functions that occur during the process plant life cycle, from initial concept to decommissioning. Tantamount to SPF is the facilitation of data flow as it moves from one engineering software application, e.g., piping & instrumentation diagrams, electrical schematics, 3-D drawings, etc., to another.

- A methodology for handling the nasty details of true integration, e.g., backup & restore, deleting items in one tool, and automatically making another tool aware of the deletion, change management, etc.

- An underlying database and document-management system that is strong enough for real-world, large-scale design projects.

- An overarching architectural model so that any kind of tool from a spreadsheet to a complex 3-D drawings generation program is able to figure out how to exchange data.

- An extensible framework for representing data, which is customizable by real-world users.

If that sounds like a lot, it is! Intergraph Process, Power & Marine (PPM), in Huntsville, Alabama has been cooking up this next-generation, software-based solution to integration for many years. SPF is in use at a number of large-scale architectural and engineering (A&E) firms, worldwide. If you really want to know why you should care about this stuff, spend a few minutes looking at Appendix K.

SPF Overview SPF is based on a "hub-and-spoke" model. A data repository is at the hub (and it is worthy of a book or two), and each integrated software application is a spoke. SPF is a "loose integration" solution that allows each software application to maintain its own data model, independent of the SmartPlant Foundation data model. The benefit of "loose integration" is the flexibility to add or remove applications for any desired configuration of SPF.

v

At the end of each spoke in SPF's hub-and-spoke model is an integrated application that communicates with SPF via an "Adapter" component. Each integrated software application uses their adapter component to publish and retrieve "documents" of XML data to, and from SPF. When SPF is rolling along, you won't think much is going on - it is quiet and fuel-efficient. But there is really a lot of horsepower in the idea of total system integration. The more you understand how the underlying architecture works, the more you'll be able to apply the system to your complex business problems.

SmartPlant® Schema Overview The SmartPlant schema, effectively SPF data model, provides the structure and semantics of the data that can be published to, and retrieved from, SPF data repository. Each document type, e.g., a P&ID, that gets published (by an application) has an associated "component schema", which is a subset of the schema , specifying the relevant object types, relationships, rules, and attributes.

How This Book is Organized One of the problems with such a complex software system is trying to explain it to new users in a way that they can quickly be productive. This book is an attempt to simplify one aspect of SPF, viz., the "data model". It will actually try to concentrate on describing the meta-model, so that you can understand why the schema wound up the way it did. Now, before you race to the dictionary, I will define "meta-model" for you: it is simply "a model of a model". The meta-model of the SmartPlant schema defines how the model of the SmartPlant schema is constructed. When you understand the meta-model, you will be able to read the "real" model with understanding, and extend it for your application in a proper manner. You'll see that some of the ideas about the data model are so good (or so hard to understand) that they are presented 2 or 3 times, in order to enhance your learning experience and turn the "Aha!" switch in your brain to the "ON" position.

vi

Some things that will be mentioned, but not covered in detail in this book: - The SmartPlant Schema Editor - The process of "publishing" and "retrieving" documents - The process of mapping your tool's schema to SmartPlant schema - How SmartPlant Enterprise works - The "guts" of SmartPlant Foundation (SPF) - Data transformation as a result of schema evolution - How to use the SmartPlant Schema Component Application Programming

Interface (API) Documentation on all of the above-mentioned topics are available through normal channels, including some mighty fine Intergraph PPM Training courses, which you should plan to attend. Also, I will not include a lot of complex "patterns" that appear in the SmartPlant schema, e.g., the "process data" model, since that makes this book more "fragile", since the schema can (and does) change, but a hardcopy of the book will live forever. If you're looking for insight into:

- How and why is the SmartPlant schema put together that way? - What is "data modeling"? Why do I need to understand that just to

add a couple of properties to my SPF? - Help! I understand my database and my application software, but this

SmartPlant Foundation stuff is too complex! How do I begin to understand what's going on?

- Is there an underlying architectural philosophy, or is SPF an enigma wrapped in a data model?

...then this is the right place. Although you will not find the answer to specific questions like: "how do I find a stream in the SmartPlant schema?", you will find the patterns and philosophy used to build the SmartPlant schema, hopefully, giving you an idea of where to start looking for the answers to those types of questions. Before you start, you probably want to review the "jargon" that is associated with this topic.

vii

Disclaimer I'm not an author, I'm a data architect. I intend to "lighten-up" the topic of the SmartPlant schema. Please begin this journey with a forgiving attitude, and a little levity ;-} FYI, I am Doug.Hilton@Intergraph.com Please send document comments or suggestions to PPMdoc@Intergraph.com

viii

Table of Contents Introduction........................................................................................................................... iv

SPF Overview ............................................................................................................... iv SmartPlant® Schema Overview ..................................................................................... v How This Book is Organized......................................................................................... v Disclaimer .................................................................................................................... vii

Table of Contents................................................................................................................ viii Table of Figures .................................................................................................................. xiii 1. A Roadmap ........................................................................................................................ 1

Problem Definition......................................................................................................... 1 What the heck is a "Schema"? ....................................................................................... 1

2. The Origins of Data Modeling........................................................................................... 3 Why do we "model data"? ............................................................................................. 3 Lots of "Things" in the World ....................................................................................... 3 Data Lives Past the "Design Phase"............................................................................... 3 The Concept of a "Model" ............................................................................................. 4 Modeling "Anything"..................................................................................................... 4 Modeling Data ............................................................................................................... 5 Different "Views" of the Same Thing............................................................................ 5 A "Shared" View............................................................................................................ 6 The Definition of a "Data Model" ................................................................................. 7 Tool User's Perspective.................................................................................................. 8 Tool Adapters................................................................................................................. 8 Tool Map Schemas ........................................................................................................ 8 Conclusion ..................................................................................................................... 9

3. Classification of Objects .................................................................................................. 10 Sorting is a Way of Grouping Objects......................................................................... 10 The Linnaean Taxonomic Model................................................................................. 10 "Animal, Vegetable, or Mineral?" ............................................................................... 10 Shortcomings of the Linnaean Model.......................................................................... 11 Polymorphism.............................................................................................................. 11 The Linnaean Model Fails in the General Case........................................................... 12 If a Valve Could Talk (this is what it would say) ........................................................ 12 A Role-based View of Objects .................................................................................... 13 My Roles...................................................................................................................... 13 Zen-like Thinking about Objects (and their "-ness") ................................................... 14 The Elliot Ness-ness of Elliot Ness ............................................................................. 14 A Designer is Trying to Fulfill a Role ......................................................................... 15

4. Why Be Normal? ............................................................................................................. 16 Foundations of Data Normalization............................................................................. 16 What is Data Normalization?....................................................................................... 16 3NF, 4NF, 5NF - When is NF Enough? ...................................................................... 16 SmartPlant Foundation Data is 4NF and 5NF ............................................................. 17 Denormalization........................................................................................................... 17

ix

Where Interfaces Fit In ................................................................................................ 18 Baby, You Can Drive My Car ..................................................................................... 18 Orthogonal roles........................................................................................................... 19

5. An Introduction to Symbolic Logic ................................................................................. 20 Data Modeling Conventions ........................................................................................ 20 Symbols are Precise ..................................................................................................... 21 Unified Modeling Language (UML) ........................................................................... 21 Symbolic Logic............................................................................................................ 22

6. The SmartPlant Data Model............................................................................................. 23 The SmartPlant Schema............................................................................................... 23 SmartPlant Schema Rules ............................................................................................ 23 Lots of Structures......................................................................................................... 23 Overview of the SmartPlant schema Data Model........................................................ 24 SmartPlant schema Class / Interface / Relationship Model ......................................... 24

7. Defining an Interface (InterfaceDef) ............................................................................... 25 Review of Interfaces .................................................................................................... 25 Defining an Interface (InterfaceDef) ........................................................................... 25 InterfaceDef - Graphic Representation ........................................................................ 25 The <<Stereotype>> .................................................................................................... 26

8. Defining a Property (PropertyDef) .................................................................................. 27 What is a Property? ..................................................................................................... 27 What is a PropertyDef?................................................................................................ 27 "Scoping" a PropertyDef ............................................................................................. 27 Scoping Examples........................................................................................................ 28 Scoping Types.............................................................................................................. 29 InterfaceDef / PropertyDef Redux............................................................................... 29

9. Defining a Class (ClassDef)............................................................................................. 31 Idea of Instance ............................................................................................................ 31 Object Identity ............................................................................................................. 31 Model Definitions (ModelDef) .................................................................................... 32 It's Nice to Share (Objects) .......................................................................................... 32 Sharing Allows Changes.............................................................................................. 32 The SameAs Relationship ............................................................................................ 32 Shared object definition (SharedObjDef) .................................................................... 33

10. Defining a List of Values (EnumEnum, EnumListType) ............................................... 34 Enumerated Values (EnumEnum)................................................................................ 34 Enumerated Lists of Values ......................................................................................... 34 Enumerated Lists (EnumListType)............................................................................... 35 Varying Strengths of Enumerated Lists....................................................................... 35 Properties can be Scoped by Enumerated Lists ........................................................... 36 EnumEnum Short-Text and Long-Text........................................................................ 36 Multiple-level Enumerated Lists (EnumListType)....................................................... 36 Linking Enumerated Values to Interface Definitions (EnumMetadata)...................... 38

11. Defining Units of Measure (UoMEnum, UoMListType) ............................................... 40 Units of Measure (UoMListType) ................................................................................ 40 Unit of Measure (UoMEnum) ...................................................................................... 40

x

SI Unit.......................................................................................................................... 41 Default SI Unit (HasDefaultSI) ................................................................................... 42 Units of Measure Conditions ....................................................................................... 42 "Any" UoM (AnyUoM) List......................................................................................... 42

12. The Implies Relationship (Inheritance).......................................................................... 44 Property Inheritance..................................................................................................... 45 Implies is a Transitive Relation ................................................................................... 45 Conversations re: Dog, Wolf, Mammal and Animal ................................................... 45 "Things that have Legs"............................................................................................... 46 "Implies" and Relationship Inheritance ....................................................................... 47 "Optional" vs. "Required" Implies ............................................................................... 47

13. The Realizes Relationship.............................................................................................. 48 The Realizes Relationship............................................................................................ 48 The "Primary" Interface............................................................................................... 48

14. Defining a Relationship (RelDef, Rel) ........................................................................... 50 The Relationship Definition (RelDef) .......................................................................... 50 A Data Modeler Defines Marriage (hoo-boy!) ............................................................ 50 A Data Modeler Thinks About RelDefs....................................................................... 50 A Guru Ponders Marriage............................................................................................ 51 "Abstract" Relationship Definitions ............................................................................ 53 Introduction to Delete Propagation Semantics ............................................................ 54 "Concrete" Relationship Definitions............................................................................ 54 Invitation to a Wedding (Example of a Rel) ................................................................ 55 Introduction to Cardinality........................................................................................... 55 Which RelDef is Right for Me? ................................................................................... 56 Locality of Reference................................................................................................... 56 Shared Objects and Locality of Reference................................................................... 57

15. Unique Identifiers (UIDs) .............................................................................................. 59 16. Edges, Graphs, Views & Class View Map (EdgeDef, GraphDef, ViewDef, ClassViewMap) .................................................................................................................... 60

Edge Definition (EdgeDef) .......................................................................................... 60 Graph Definition (DirectedGraphDef) ........................................................................ 64 Technical Details of Graph Definition (DirectedGraphDef)....................................... 64 View Definition (ViewDef) .......................................................................................... 64 Class View Maps (ClassViewMap) ............................................................................. 66

17. UML Concepts (Elaboration) ........................................................................................ 67 The Most Important Concepts of the SmartPlant schema Data Model ....................... 67 Interface Polymorphism............................................................................................... 69 Reasons for using Interfaces ........................................................................................ 69

18. Examples of Class and Interface Models....................................................................... 71 Another Example of an Interface Relationship Model ................................................ 72 Example of the RelDef Labeled "Children"................................................................. 72 Review of RelDef ......................................................................................................... 73

19. The SmartPlant "Meta Schema" .................................................................................... 74 Technical Description of the SmartPlant Meta Schema .............................................. 74 Relationships between Schema Elements.................................................................... 75

xi

Informal Rules ............................................................................................................. 75 The SmartPlant Schema Editor.................................................................................... 76 More Powerful than a Speeding Bullet? ...................................................................... 76

20. SmartPlant schema Files ................................................................................................ 77 Component Schemas (CompSchema) .......................................................................... 78 A Shared Pipeline ........................................................................................................ 80 Existing Component Schemas ..................................................................................... 81 Technical Description of Component Schemas........................................................... 81

21. XML Files Overview ..................................................................................................... 83 SPF Documents are in XML Format ........................................................................... 83 SmartPlant schema Helps Organize XML Files .......................................................... 83

22. Patterns........................................................................................................................... 85 Example of a Real-World Model................................................................................. 85 Review of Class, Interface, Property and Relation ...................................................... 85 SmartPlant schema Complexity Breakdown ............................................................... 86 Vessel/Nozzle/Pipe run Drawing................................................................................. 86 An Object Diagram...................................................................................................... 86 Excerpt from the SmartPlant schema........................................................................... 87 Sample XML file ......................................................................................................... 88 "Part" vs. "Occurrence"................................................................................................ 89 RelDef Patterns............................................................................................................. 97 Composition relationships ........................................................................................... 97 Collection relationships ............................................................................................... 97 Plant Breakdown Structure .......................................................................................... 98 Work Breakdown Structure ......................................................................................... 98 Naming Conventions ................................................................................................... 98

23. SmartPlant Architectural Model .................................................................................. 100 The Underlying "Architectural Model" ..................................................................... 100 Here is the "Facility model"....................................................................................... 100 Here is the "Material model" ..................................................................................... 101 Facility and Material Models ..................................................................................... 101 Facility and Material Model Summary ...................................................................... 101

24. Schema "Evolution"..................................................................................................... 102 25. Schema Reading Practice............................................................................................. 103

UML Reading Practice for ClassDefs........................................................................ 103 UML Reading Practice for InterfaceDefs .................................................................. 110 A Child's Poem .......................................................................................................... 111

26. Secrets of the SmartPlant schema Master.................................................................... 112 Model InterfaceDefs First (Data Normalization)....................................................... 112 Organizing Lots of Pump Properties.......................................................................... 113 What's the Spin on Rotating Items? ........................................................................... 113 The Results of "Normalizing" a Pump....................................................................... 114 How Interfaces Help to Tame Polymorphism ........................................................... 114 Ideas about ClassDefs ................................................................................................ 117 Naming ClassDefs ..................................................................................................... 117 Ideas about Enumerated Lists (including EnumListLevelType)................................. 118

xii

Incomplete Hierarchies .............................................................................................. 119 Beating Enumerated Lists into Enumeration Hierarchies.......................................... 120 Cutting Across the Grain with EnumListLevelType................................................... 120 Scoping with an EnumListLevelType......................................................................... 121 The View from the Top of the Mountain................................................................... 124

Appendix A. Rules of Data Normalization....................................................................... 125 Appendix B. Linnaean Taxonomic Model........................................................................ 126

Summary .................................................................................................................... 128 Appendix C. Schema Element Definitions ........................................................................ 129 Appendix D. Definitions, Acronyms and Abbreviations................................................... 138 Appendix E. Some Properties of a Pump........................................................................... 142 Appendix F. Normalized Properties of a Pump................................................................. 150 Appendix G. Piping Component Type Hierarchy.............................................................. 158 Appendix H. Some UML Diagrams .................................................................................. 171

Figures for Chapter 25, "UML Reading Practice for ClassDefs" .............................. 171 Figures for Chapter 25, "UML Reading Practice for InterfaceDefs" ........................ 172

Appendix I. Equipment Property Spreadsheets ................................................................. 178 Appendix J. SmartPlant Meta-Schema Objects ................................................................. 186

Architecture objects ................................................................................................... 186 Schema objects........................................................................................................... 186 Software objects......................................................................................................... 186

Appendix K. SmartPlant Schema Rationale ...................................................................... 188 Appendix L. The TEST...................................................................................................... 189 Index .................................................................................................................................. 190

xiii

Table of Figures Figure 1 A Picture of a Model of a Car and a Picture of an Actual Car ................................ 4 Figure 2 A Role Playing Game is a Model of World Events................................................. 5 Figure 3 Different Views of a Valve...................................................................................... 6 Figure 4 Symbols Representing Human, Man, Woman ...................................................... 20 Figure 5 The Symbol for the IMan Interface ....................................................................... 21 Figure 6 An InterfaceDef as a Rectangle............................................................................. 25 Figure 7 An InterfaceDef as a Circle ................................................................................... 26 Figure 8 Sample InterfaceDef, PropertyDef, EnumListType .............................................. 30 Figure 9 The Symbol for a Class Definition (ClassDef)...................................................... 31 Figure 10 Example of Shared Objects ................................................................................. 33 Figure 11 The Symbol for an Enumerated Value (EnumEnum).......................................... 34 Figure 12 The Symbol for an Enumerated List (EnumListType)......................................... 35 Figure 13 The Symbols for a Populated Enumerated List ................................................... 35 Figure 14 Enumerated Lists and Enumerated Entries.......................................................... 37 Figure 15 Units of Measure Example .................................................................................. 40 Figure 16 A Taxonomy of a Dog......................................................................................... 44 Figure 17 A Dog Realizes that It's a Wolf, too.................................................................... 48 Figure 18 A Relationship Between Man and Woman ......................................................... 50 Figure 19 RelDef Model....................................................................................................... 56 Figure 20 Vessel with Nozzles (Conceptual)....................................................................... 62 Figure 21 Vessel with Nozzles (SmartPlant schema) .......................................................... 62 Figure 22 EdgeDef Example of Numeric Position .............................................................. 63 Figure 23 EdgeDef Example of Property Comparison ........................................................ 63 Figure 24 Sample of a Directed Graph ................................................................................ 64 Figure 25 ViewDef ............................................................................................................... 65 Figure 26 Class Diagram for MAN ..................................................................................... 71 Figure 27 Class Diagram for WOMAN............................................................................... 72 Figure 28 the Mother-Son Relationship............................................................................... 72 Figure 29 Types of SmartPlant schema Files ...................................................................... 77 Figure 30 Classes That Are in the P&ID Component.......................................................... 79 Figure 31 A Shared Pipeline ................................................................................................ 80 Figure 32 Vessel/Nozzle/Pipe run from P&ID Drawing ..................................................... 86 Figure 33 An Object Diagram of Vessel/Nozzle/Pipe run................................................... 87 Figure 34 Vessel/Nozzle/Pipe run in SmartPlant schema.................................................... 87 Figure 35 Pattern for "Part" and "Occurrence".................................................................... 92 Figure 36 Properties of an Equipment-as-a-Part.................................................................. 94 Figure 37 Properties of Equipment-as-an-Occurrence ........................................................ 95 Figure 38 A 1/2 HP Pump.................................................................................................. 112 Figure 39 Classes that are Polymorphic with respect to IRotatingItem............................. 115 Figure 40 Top-level of Instrument Type Hierarchy........................................................... 118 Figure 41 Second-level of Instrument Type Hierarchy ..................................................... 118 Figure 42 Leaf-nodes in the Instrument Type Hierarchy................................................... 119 Figure 43 "IPipingComponent" InterfaceDef .................................................................... 120

xiv

Figure 44 Hierarchical Dependence for Piping Component Types ................................... 121 Figure 45 3 Levels of Scoping ........................................................................................... 123 Figure 46 "IPipingComponent" ......................................................................................... 123 Figure 47 Example of Linnaean taxonomic model............................................................ 127 Figure 48 ClassDef ............................................................................................................ 129 Figure 49 ClassDef Class................................................................................................... 129 Figure 50 EnumEnum ........................................................................................................ 130 Figure 51 EnumEnum Class............................................................................................... 130 Figure 52 EnumListType .................................................................................................... 131 Figure 53 EnumListType Class .......................................................................................... 131 Figure 54 InterfaceDef ....................................................................................................... 132 Figure 55 InterfaceDef Class ............................................................................................. 132 Figure 56 PropertyDef ....................................................................................................... 133 Figure 57 PropertyDef Class ............................................................................................. 133 Figure 58 RelDef ................................................................................................................ 134 Figure 59 RelDef Class ...................................................................................................... 135 Figure 60 UoMEnum.......................................................................................................... 136 Figure 61 UoMEnum Class................................................................................................ 136 Figure 62 UoMListType ..................................................................................................... 137 Figure 63 UoMListType Class ........................................................................................... 137 Figure 64 UML Diagram of EQDFan............................................................................... 171 Figure 65 Interface Diagram 1 - Agitator Part & Occurrence Model................................ 172 Figure 66 Interface Diagram 2........................................................................................... 172 Figure 67 Interface Diagram 3........................................................................................... 172 Figure 68 Interface Diagram 4........................................................................................... 173 Figure 69 Interface Diagram 5........................................................................................... 173 Figure 70 Interface Diagram 6........................................................................................... 174 Figure 71 Interface Diagram 7........................................................................................... 174 Figure 72 Interface Diagram 8........................................................................................... 175 Figure 73 Interface Diagram 9........................................................................................... 176

1

1. A Roadmap It begins - a journey into something that is considered to be very difficult by many people. Fact is, most folks would rather have their finger nails gnawed on by a hungry badger than delve into this subject. The answer as to why you're reading this is up to you, but I hope that this document clears up many aspects of the SmartPlant schema. Intergraph PPM has spent years, working on a way to fully integrate disparate software systems. That is a very complex subject, and would require several large volumes to really explain properly.

Problem Definition The SmartPlant Enterprise suite allows many different software "tools" to communicate in an intelligent way about the kinds of things that are in your, e.g., process plant, ship, or other large-scale facility. A lot of companies have tried to do this, and some have been successful, to varying degrees. Intergraph PPM has worked out a "practical" way to do complete integration, based on the idea that individual software "tools" don't have to change a lot, but they must simply learn how to "map" their idea of "things" to and from a "global" idea of "things", e.g., some program calls a thing a "Pump", and another program calls it an "Equipment" and still another program only thinks only of the dimensions of the base of the pump, so that it can be properly attached to the deck. SmartPlant Enterprise won't force you to re-code those programs in order to share the common concepts about "pumps" - it's OK to just "map" one programs' idea of a "Pump" to an idea of an "Equipment" to a "dimensional datasheet". Somewhere, a database is running and absorbing all those "shared" ideas about how different tools think about pumps - that's what we call SmartPlant Foundation (SPF). It uses a Rosetta stone, called a "schema" to get everybody talking the same language. It also incorporates a powerful workflow engine, "rules", document management, and a few other things that you're sure to find very useful for a total integration solution.

What the heck is a "Schema"? One of the key elements to full integration is to have a "schema", and enforce some kind of rules between a "publisher" and a "retriever" of data. It should be simple for two different systems to talk about something that

2

they have in common, e.g., a motor, a pump, a valve, etc. But it is really not simple at all. That's because each system has its own idea of what things are, and how they are used. A "schema" is simply another way of saying "a diagrammatic representation, an outline, or a model." Before you can understand the SmartPlant data model, you have to understand some very basic concepts (if you already know this stuff, please apply for a job in my department).

1. What is "data modeling"? 2. Classification of objects & Data "normalization" 3. Symbolic logic 4. The Data model A. Basic structures i. Classes, Interfaces, etc ii. Relationships B. Patterns 5. The Meta Schema

I'll try to make your journey fun, but wait! I think I hear the familiar TV voice of Rod Sterling saying: "That's the signpost up ahead -- your next stop: The SmartPlant Schema Zone"!!

"nah na NAH naaaa"

3

2. The Origins of Data Modeling SmartPlant Foundation (SPF) is based on the idea that many software programs need to share common sets of data. That is an opportunity, and a burden, since each program was developed independently, and yet now needs to share the data in an intelligent manner. To make sure that all the programs are talking about the same thing, we use a "model" of an idealistic world, which follows strict rules, so that each program can talk to each other through a common base in a predictable way. Let's see what that means.

Why do we "model data"? One of the hardest things to understand is "how does data from one program get exchanged with (used by) another program?" For example, if you create a piping and instrumentation diagram (P&ID), which shows a pump, some pipe lines, and a few valves: how can that information be fed to a 3-D modeling program "with meaning." Up till now, software programs had to jump through hoops to figure out that a certain valve on a P&ID is "that same valve" on a 3-D drawing. With SPF, we hope to show that it is simple to share all of the complex data about pumps, valves, pipes, etc., with all of the many software programs that are used to design large-scale systems.

Lots of "Things" in the World If you think about how many pumps, pipes, valves, vessels, etc., are in a modern chemical "process" plant, or on a large ocean-going platform, e.g., FPSO, the answer is 105 to 106 objects. Nobody can afford to think about each of those objects 10 times, just because 10 different software programs were written that deal with those objects. If you can save time by intelligently sharing data between the programs that are used during the design phase, you can see that a lot of money can be saved.

Data Lives Past the "Design Phase" In addition, once all the data about a plant or ship is captured in a database, it can be turned over to the owner-operator, so that he has a head-start on testing, startup, and operation of the unit. Then, you can recycle and change the data when you design the "next" facility and save money there, too! In fact, productivity gains as high as 90% have been measured with SmartPlant 3D (reference:

4

http://www.intergraph.com/smartplant/3d/Productivity_Gains_with_SmartPlant_3D.asp).

The Concept of a "Model" While there are many aspects to the overall "integration" concept, at the heart of it all is a "data model." Huh? You've heard of models since you were a kid: model airplanes, model cars, models of people, a.k.a. dolls. The Guru says: "models are used to convey the essence of what you're talking about. Sometimes, some important information can be lost, and a model is still OK." (¿que? what did he mean by that?) Listen up: a model of a car isn't something that you really get into and drive to the office, but it is "real-enough" that you make the mental leap that it represents a car strongly enough that you can actually "pretend" to drive the car to work. As a child, you probably played with lots of real-world models that let you see how things work, without putting you behind the wheel of a real car when you could not even reach the pedals.

Figure 1 A Picture of a Model of a Car and a Picture of an Actual Car

Think of how abstract the left-hand image in Figure 1 is - it isn't even a model of a car, it is a picture (a 2-D representation) of a plastic model of a car, but I look at it and have no problem making a leap to thinking about my driving experience this morning, which is depicted in the right-hand image, which is a picture (a 2-D representation) of an actual plastic (fiberglass) car.

Modeling "Anything" The idea of "modeling something" doesn't stop with making physical models. Popular interactive role-playing games are good examples of modeling "world events" in real-time.

5

Figure 2 A Role Playing Game is a Model of World Events

A model of a monster lunges, and you push a button on a game pad, and bang! the "monster" is "dead." Fighter pilots train in simulators, which model the exact action of the plane, and might "crash" many times without harming anyone. Modeling is all around us.

Modeling Data If you think about the problem of integrating data from a lot of different software applications, you can understand how a "model" of the data that is being passed around might be a good way to simplify the discussion of "how do I get that valve from a P&ID (piping diagram) into my 3-D program?" A "model of a valve" is not a valve, but it can expose many aspects of a valve, e.g., its flow-rate, its weight, its inlet size, etc. Some other program may not care about any of that, and just wants to talk about the height of the valve, or about who carries the valve "in-stock", so that it can be ordered quickly.

Different "Views" of the Same Thing Look at Figure 3, below. Each of these different "views" of the valve are perfectly valid to the software tool that uses the valve in its own particular way. But somehow, there is the concept to all the programs that "there is this particular valve that we're all talking about." It appears here, it appears there, it appears everywhere. It even finally shows up in the completed plant, and you can turn it on, and fluids flow through it!

6

Figure 3 Different Views of a Valve

A "Shared" View Each SmartPlant Enterprise software program, a.k.a. "tool" has some conceptual model of a valve. When we say "tool", we're talking about:

- � SmartPlant 3D our next generation, data-centric, rule-driven engineering design solution.

- � SmartPlant Electrical an application designed by electrical engineers for electrical engineers.

- � SmartPlant Explorer for accessing plant data resident on disparate systems via the Web from anywhere in the world, anytime of the day.

- � SmartPlant Foundation for total information management for the life of your plant.

- � SmartPlant Instrumentation the industry-leading instrumentation solution (previously marketed as INtools).

- � SmartPlant Layout a preliminary 3D plant layout tool. - � SmartPlant Markup a precision viewing and markup tool. - � SmartPlant Offshore the most advanced offshore industry design

software offered in two decades. - � SmartPlant P&ID for generating "intelligent" P&IDs and

management of related engineering data for use throughout a plant's life.

- � SmartPlant Process Safety for conducting and managing hazard and operability (HAZOP) studies.

- � SmartPlant Review for dynamically viewing 3D computer models for in-depth review and analysis.

- � SmartPlant Review Publisher automatically distributing compressed SmartPlant Review data to network locations anywhere in the world.

7

- � SmartSketch® for producing engineering drawings from conceptual layouts to detailed equipment drawings to installation details and more.

- ...and other SmartPlant Enterprise "enabled" tools, e.g., Aspen Zyqad. No one tool cares about "all" the possible properties of a valve. So how do we "share" the data about "this particular valve" between tools? The Guru replies: "make a "model of a valve", and share that between the tools!"

The Definition of a "Data Model" So, that is what a "data model" is - an abstract representation of the objects that software tools can share, use, think about, and grow to love. It makes it easy for each tool, because they can still think about "a valve" in their own way. It makes it easy for all tools because they can share the concept of "this particular valve" by agreeing on what the data model for a valve is. Pretty simple concept. The SmartPlant schema defines the structure of the SmartPlant Foundation (SPF) database, and is used as the neutral format through which authoring tools publish and retrieve data, independent of their specific data model. The section Overview of SmartPlant schema Data Model describes in detail the SmartPlant schema model. Other functions of the SmartPlant schema include:

- Enumerated lists: engineering is full of lists of valid data that can be applied to data values (and shared between applications), e.g., types of valves, fluid codes, etc.

- Connectivity - engineering is as much about the relationships between equipment as the equipment itself, e.g., a vessel has a nozzles that connects to different pipelines.

- User-defined properties - Software applications provide the means for users to specify user-defined variables. Procedures must be established to assure that this data is implemented in the SmartPlant schema.

- Support for Units-of-Measure, to allow clear flow of data regardless of the units specified.

8

- Rules for evolving the schema, so changes to the structure and semantics of the data can be made due to new or changing requirements.

- Specific support for engineering concepts such addressing process data, relationships between equipment and nozzles, and so on.

Tool User's Perspective The engineering application tool user, e.g., the SmartPlant Instrumentation (SPI) customer, does not need to understand and comprehend the SmartPlant schema to use SPF. In fact, they are able to conduct their workflows without concern for database, data model, and underlying architecture. The SmartPlant schema assures that data will be stored and retrieved in a proper fashion in accordance with the defined structure and rules.

Tool Adapters Each authoring tool that is part of SmartPlant Enterprise has an authoring tool "Adapter", which facilitates the sharing of data between the authoring tool and SmartPlant Enterprise. Tool adapters generate XML files for "publish" operations, and consume XML files for "retrieve" operations.

Tool Map Schemas Tool map schemas a.k.a. "Map files", describe the mapping between an authoring tool's internal data model and the SmartPlant schema. When a document* is published, the authoring tool adapter, with the help of the SmartPlant schema component API uses the tool map schema to convert the data from the tool's internal data model to the SmartPlant schema. As you would expect, the opposite occurs when a file is retrieved into an authoring tool, the retrieved data is converted from the SmartPlant schema format to the tool's internal data model. * The word "document" is "overloaded" with meaning by just about everyone. For

the purposes of this document, we're talking about an XML file that contains data, under control of a schema, that's all.

Best practices recommend that every authoring tool that integrates through SmartPlant Enterprise provide the ability to map to and from the SmartPlant schema. However, special cases exist where the exchange of data is "hard-coded". For more information about authoring tool mapping,

9

see the SmartPlant Schema Mapping Guide, delivered with the SmartPlant Foundation (SPF) documentation.

Conclusion The Guru opines: "Once you have seen a few model cars, you get the picture. Once you have seen a few models of data, you'll get that picture, too!"

10

3. Classification of Objects Humans seem to be able to naturally classify things. If you put a big handful of coins down in front of most people, their first instinct is to sort them into groups - pennies, nickels, dimes, etc., going into separate groups. It's just easier to think about things that are somehow grouped properly. That's an interesting topic - how do people "group things"?

Sorting is a Way of Grouping Objects Would you group a table full of mixed coins by value, by size, by composition, or by something else? Did you ever stack the decreasing-diameter coins on top of larger coins? There are a lot of ways to group the coins, and you get to pick the way that makes the most sense to you. If you want to pick another way later on, you simply sort the coins in a different sequence. Did you think about putting the dimes on the bottom and the half-dollars on top? You could.

The Linnaean Taxonomic Model Some scientists classify living things with a Linnaean model of taxonomy, which provides an underlying classification structure which is used to build up a semantic network of animal classes. Taxonomy is the branch of biology that deals with identification and naming of living things. Each node within this hierarchy provides a place where you can hang information about the animal class. In other words, it allows you to describe an animal with respect to its position in the hierarchy and provide inheritance of features from higher classes. It also allows us to infer relationships between animals to produce comparisons. Did you ever observe that a dog is like a wolf? So did Carl Linnaeus - but he sat down and spent a great deal of effort figuring that dogs are like wolves, and not like tomatoes. For more information on the Linnaean Taxonomic model, see Appendix B.

"Animal, Vegetable, or Mineral?" Did you play this game when you were young? Imagine someone walks up to you and asks "Guess what I'm holding in my hand?" Having no idea, you reply: "is it an animal, vegetable or mineral?" The answer allows you to narrow down the scope, and eventually guess what the object is. The Linnaean taxonomic model is the scientific basis for classifying "animals" and "vegetables." (The Guru straightens up, pushes up his spectacles, and says:

11

"ahem! Minerals are classified by chemical composition in a similar manner, based on the dominant anion, or anionic group" and then he falls back into a trance).

Shortcomings of the Linnaean Model Using the Linnaean model, we can easily visualize that wolves and dogs are related (have some shared characteristics). It is obvious to a child that maple tree and an oak tree are similar (have some shared characteristics). However, life in the world of classification of objects is not so simple. To put it bluntly, what if there is not a clear answer to "is it animal, vegetable or mineral?" Look back at Figure 3 for a minute. When we are talking about a valve, is it an image on a P&ID, an image on an electrical schematic diagram, or an actual valve, or what? It is all of those at the same time, and that is perfectly fine!

Polymorphism Polymorphism? What? Before you hit the web, let me look that up for you. A quick search reveals that generally polymorphism is the ability to appear in many forms. Let's apply this to our valve. Take a look back at the images in Figure 3. Moreover, a valve can be more than those images shown there, and that's an important point. For example, here's a few: - A valve that you think about ("we'll need a valve in that pipeline so that we can control the flow to the storage tank") - A valve that you order from a catalog (let's get a pinch valve from the Clow catalog) - A valve that you put on a P&ID as an image (look at V-100 on the P&ID) - A valve that has weight and center of gravity (for a ship, this is important) - A valve that has dimensions (the inlet and outlet diameters are 8") - A valve that has a history of failure and was rebuilt last month (valve serial number 10223 is back from rebuild) - A valve that you will need next time, because you needed it this time (we predict that we will need 40 of these valves, because last time we needed 40) - A valve that you walk up to and put your hand on (this is the valve that is shown on the P&ID as V-100) - A mechanical device that controls fluid flow in a pipeline

12

Looks safe to say that our valve fits the general definition of polymorphism, but as I look again, I see that polymorphism also means allowing a single definition to be used with different types of data (specifically, different classes of objects). That sounds good, but does this apply to our valve? Sure does! Let's say that the valve forms mentioned above have sets of similar properties but they are modeled as different classes, e.g., ConceptValve, CatalogValve, P&IDValve, etc., Polymorphism allows us to take the sets of common properties, define them on a single interface, e.g., IValve, and realize this interface from any number of different classes. This way, it doesn't matter which class we're talking to, we can refer to the IValve interface. This is an important point. We will cover it in more detail later.

The Linnaean Model Fails in the General Case So, when different people talk about a "valve", what should come to mind? The problem is: everyone who thinks about a "valve" thinks about in his own terms. In fact, there is no one "correct" way to think about a valve, and that's OK. Is a valve an animal, vegetable or mineral? It's all of those. Just ask the people who are all thinking about valves:

- a dog's heart has valves (animal) - a valve used to control vegetable oil in a fryer (vegetable) - a brass valve in a pipe line (mineral)

Uh oh! How can we all think different things about a "valve", and come to some conclusions and agreements before we have fluid flowing through it? Let's try a different approach: instead of us guessing at the Linnaean taxonomy of a valve, how about if we let the valve "tell us what it is", and we'll just listen carefully.

If a Valve Could Talk (this is what it would say) "Ahem", let me clear my 'throat': - I'm a valve. I perform the function of controlling fluid flow in, e.g., a fluid system of some kind. - I may be a commodity item. I may be ordered from a number of different catalogs, as I am manufactured by several different companies - On P&ID ATQ-73J, this is my image, just so that you can recognize me. - I weigh 100 pounds, and my center of gravity is at x=10.0, y=3.0, z=7.5

13

- My inlet side is an 8" opening. My outlet is on the other side, and offset 2", it is also an 8" opening. - I had a small leak last month. I was sent back to the manufacturer and repaired. I can be reinstalled whenever you take me off this shelf in the warehouse. - In the process plant that you built last year, you used 40 valves exactly like me. When you design the next plant, try to remember that. - My serial number is VZ-012345. I was manufactured on January 4, 2005. - I'm a mechanical device. I have certain mechanisms that are used to control the flow of fluid through a pipeline. My design pressure is 200 psi.

A Role-based View of Objects Now, dear reader, I'm leading you in a direction, for sure. The "valve" exposes certain "roles" to the universe, and the roles that a valve object "realizes" are there for us to use, if we want to listen and understand. This is called a "role-based" approach to classifying things - let them tell what they are (meaning what roles the object thinks it fulfills). The Guru jumps up and shouts: "Instead of you trying to guess whether it is animal, vegetable, or mineral, the object just tells you!" Yipes!! You have to admit that that's a real powerful idea. Microsoft has been a leading proponent of the "role-based" view of objects, and they implement this by using an artifact called an "interface." That is, in fact, one of the most important ideas of what is called COM. The use of interfaces is also common in Microsoft .NET technology. Just remember this: An interface = a role. Let's look at an example.

My Roles I'm thinking of myself for a minute. What roles do I expose to the universe? - I am a man - I am a taxpayer - I drive an automobile - I am married (to a nice woman) - I work at Intergraph PPM - etc.

14

As we look at each of these "roles" that I present to the universe (a.k.a. roles that I "Realize" that I provide to the universe), they begin to classify the way that I participate in relationships with others people, or entities in the universe: - As a taxpayer, I have some properties that the IRS and State of Alabama are interested in (how much money does he make?) - As a driver, I should have been tested, and acquired a Driver's License - Since I am married, and a man, I am a husband - Since I work at Intergraph PPM, I have an office, a phone number that is different from home, and an employee id number. ...and so on. Each of these roles can be used to form relationships to whomever cares about that aspect of me. The IRS doesn't care how much I weigh (yet), and the Driver's License bureau doesn't care about how much I earn (yet). They all can concentrate on what they like the best, when they want to form ideas about "who is that person?" and "what can we expect from him?"

Zen-like Thinking about Objects (and their "-ness") If it's not clear yet, another way to think about "roles" is to think about the -ness suffix. ¿el lóco? The Guru chimes in: "A desk exposes "desk-ness." A tank exposes "tank-ness." A car exposes "car-ness." And, a valve exposes "valve-ness." This sounds like "zen" philosophy, but I heard the Guru says that it is critically important for your understanding of the ways of the universe. Look at Figure 1 and you will agree: any child can point to a car, a model of a car, a picture of a car, a picture of a model of a car, or a simple line-drawing from a 3-year-old, and say "car." It's because the "car-ness" of a car is totally apparent to the most casual observer! The thing that makes something a thing is it's "thing-ness", where you can just fill in the blanks.

The Elliot Ness-ness of Elliot Ness For movie-goers, when we think of the movie "The Untouchables", we think of "Elliot Ness". A policeman with such a strong moral character that it made him "untouchable" by organized crime groups (meaning that they could not bribe him). This property of "high moral character" was exposed to the universe in a way that his entire squad of police officers inherited that property. He also had a hat-size, and a driver's license, but those roles have

15

been lost to history. Only his name and one particularly interesting property survive to this day and are the basis of his legend.

A Designer is Trying to Fulfill a Role Now, picture some piping engineer thinking: "I need something to help control the flow of fluids in this pipeline." And somewhere in the universe, a lonely object is saying: "Due to my "valve-ness", I can control the flow of fluids in a pipeline." Too bad we can't get them conversing with each other. The valve is ready, willing and able to provide its role of "controlling flow of fluids in a pipeline." But it has so darn many roles that it provides, the designer may not hear that one role in the many. Let's help them both out a little.

16

4. Why Be Normal? As a philosopher once (should have) said: "Many objects can yield up many roles to the universe. Therefore, some important ideas might get lost in the noise." If you are trying to think about all the roles that you yield up to the universe - good luck! As long as you exist, and even past that, you will perform some roles. You can't possibly list all of your roles.

Foundations of Data Normalization However, you can list certain "important" roles that you expose to the universe, in some orderly way, and hope that whomever needs one of those roles will find it. It follows that, e.g., the easier that you make it for your roles to be discovered and understood, the more likely that your roles will be utilized by someone who is looking for some particular role. If you get pulled over for speeding, the officer probably doesn't want to know your taxpayer id, or your hat size, he wants to know your driver's license number (and expiration date). Thinking in these terms, and with all the roles that you expose to the universe, how can you just expose the "right" role to Patrolman I. M. Donut? You probably reach for your wallet, or purse, because that's where you group information that is relevant to your identity. From within that mass (mess?) of stuff, you pick out your driver's license. That kind of process (of grouping important data together for easy retrieval) is what computer geeks call "data normalization."

What is Data Normalization? Data normalization is a technical process that insures that data is organized with the goal of reducing redundancies and anomalies in data, and improving efficiencies. While normalization is not the be-all and end-all of good design, a normalized schema provides a good starting point for further development. For the real computer geek, you can look at Appendix A to see the rules of data normalization.

3NF, 4NF, 5NF - When is NF Enough? In the early days of databases, it was sufficient to normalize data to the third level (3NF), where 3NF = Third-Normal Form. We know that's pretty efficient, since Microsoft SQL and Oracle (and others) built profitable

17

empires on producing 3NF databases for us to use. But it turns out the "best" approach doesn't stop there. Therefore, many advanced systems use 4NF and 5NF data base architecture. While this may sound pretty geeky, it is an important point when it comes time for looking at e.g., a "polymorphic" valve. The Guru alleges: "The designer and the valve communicate best when they say the least to each other, and when that communication consists of very focused ideas about what's going on. The higher-number normalization is better for tighter, more unambiguous conversations."

SmartPlant Foundation Data is 4NF and 5NF The SmartPlant schema tries hard to be 4NF or 5NF, where possible. It just makes for less ambiguous data representation, and therefore less noise and distraction to the software program that is trying to find out about certain aspects of, e.g., a valve or a pump. In 3NF, you get all the data about a valve. By time you use 5NF, you just get one tightly-bound set of properties that are highly relevant to the idea that you are looking to expose. For example, the P&ID program sure doesn't care about the orientation angle of a valve (since P&ID is a 2-D drawing program, it has no clue about rotation in the Z-dimension). Therefore, any data about Z-axis orientation angle should not be offered up to a P&ID program - get it? That would just be "noise."

Denormalization If we can "normalize" data, can we "denormalize" data? You betcha! Let's try thinking about a computer - it has memory. Humans have memory. Should we make a common "role" for memory, which both computers and humans realize? Maybe - and that's a firm answer. There are a lot of factors that a data modeler uses to decide which things to "normalize" and which things to "denormalize." In the example of modeling "computer memory vs. human memory", you should be thinking of the poor soul who will retrieve the data that you published about "memory." Generally, are the two ideas really closely related? If so, then they should be bound together tightly (as a common role), and assigned to their own role, or "interface". If they are not so close, you can just put them on different interfaces as "properties", and name them, e.g., HUMAN_MEMORY, and COMPUTER_MEMORY. The goal of the data modeler is to try to minimize ambiguity, and sometimes that's a very difficult task.

18

Where Interfaces Fit In Interfaces are just convenient "places" to group the tightly-bound properties of a role. That's a mouthful, but you should be getting the idea by now:

- A role is something that an object yields up to the universe, e.g., "I am a driver, here is my 'driver-ness'."

- It (a role) consists of closely-related properties, e.g., driver's license number, expiration date, restrictions, picture.

- That you purposefully keep together, e.g., the on a driver's license, in your wallet, in your purse, in your car (hopefully).

- Because it (a role) makes data retrieval easier, and less ambiguous, e.g., for Officer Donut, whom we do not want to slow down a lot.

- If you want to get more technical - an interface is a named table of property definitions that are role-based.

Baby, You Can Drive My Car So, you should think of you. Think of the roles that you yield up to the universe (but not all of them). You say "I am a ...", which is a collection of these properties (age, weight, sex). For convention sake, let's take some role, and prefix it with the letter "I", so that we know that it is an "Interface." Are you ready for your first Interface: "Driver"? It has these properties:

- Driver's License number - Expiration Date - Restrictions - Picture

If someone is thinking of you as a "Driver", this is where they go: the "Driver" interface. Have you figured out that it won't do them any good to go to the "Taxpayer" interface? Your "role as a driver" is not much like your "role as a taxpayer". That is why the previously mentioned Linnaean taxonomy fails - if you look at all your roles, how would you possibly classify them all in a strict hierarchy? Right - you can't! But you can just (simply) yield up any and all roles that you care to expose to the universe, and just listen to the Guru's simple mantra: "tightly group similar properties." That works pretty well for you, and for the objects that would like to form some kind of relationship with you.

19

Orthogonal roles How did someone know to go to the "Driver" interface, instead of "Taxpayer" interface? The role of "Driver" is said to be orthogonal to the role of "Taxpayer." Orthogonal ? What? I'm already searching... Orthogonal means "having a set of mutually perpendicular axes; meeting at right angles." OK, let me search again..., in simple terms, that means that facts about "driver-ness" and facts about "taxpayer-ness" are unrelated. This is a powerful idea for grouping data! If we want to add more information about you, as a "Driver", where would we put it? Correct(!): on the "Driver" interface. Hooah! Now you're a data modeler... ...almost... The Guru claims: "At least, by now you know why we have a data model in SmartPlant Foundation (SPF):

"The SmartPlant Foundation data model lets objects from one software tool form relationships with other software tools by a tightly-controlled set of rules"

20

5. An Introduction to Symbolic Logic In Figure 4, below, we see the idea of (a model of) a "human" a "man" and a "woman".

Figure 4 Symbols Representing Human, Man, Woman

Thinking about those three "roles", and some possible relationships that can be formed between them:

- What "role" does a "human" represent, i.e., what is "human-ness"? - What "role" does a "man" represent, i.e., what is "man-ness"? - What "role" does a "woman" represent, i.e., what is "woman-ness"? - How can "human" and "man" be related?

o A "man" is a type of "human" o A type of "human" is "man"

- How can "human" and "woman" be related? o A "woman" is a type of "human" o A type of "human" is woman

- How can "man" and "woman" be related? Note that unlike the "type of" relationships between "human" and "man" and "woman", relationships between "man" and "woman" are slightly different.

o A "man" can be "married to" a woman o A "man" can be "the son of" a woman o A "man" can be "the father of" a woman o etc.

Data Modeling Conventions The pictures (images, glyphs, etc.) that are used in Figure 4 are pretty simplistic, and most people over the age of 3 would recognize the fact that we're trying to show humans, or something like that. That idea breaks down pretty quickly when we are trying to model a "concrete slab" or a "drum heat

21

exchanger" - what are the easily-understood symbols for those? So let's just state for the record that one of the functions of a data model is to present things in a symbolic form, therefore, lets just come up with a symbol that generally represents any role. How about this:

Figure 5 The Symbol for the IMan Interface

Symbols are Precise You're thinking "OK, so an 'Interface' (the representation of a "role") is a circle, no big deal." But the idea of data modeling just became much more interesting - the "zen" of creating and reading data models has a lot to do with how well we all understand what's going on in the symbols on the data model. Now, the Guru gets snippy: "If you are going to use the SmartPlant schema to exchange data with your computer system, you must learn how to read these symbols accurately! They represent a very accurate view of the data model, but it won't do you any good if you think that it means "A", but it really means "a". Model diagrams consist of circles, lines, rectangles, etc. It is very important that you understand exactly what they mean."

Unified Modeling Language (UML) Which brings us to an important point. There are lots of symbols that can be cooked up, and just because some diagram shows a circle and tells you that it means "interface" does not mean that all pictures of circles are interfaces, nor that all interfaces are represented by circles! We (data modelers) have agreed that we will (mostly) use symbols that are part of a set of modeling practices called Unified Modeling Language, or UML (pronounced you-em-ell). There were many attempts during the last 20 years to arrive at a "common" understanding of how to represent ideas on a diagram. UML won the war because it is so easy to use, and is extensible (for new ideas that might come along at any time). Can we state that, in UML, every circle is an interface? Nope - life is not that easy. The SmartPlant schema is represented by a Unified Modeling Language (UML) model. A solid understanding of UML is needed to completely

22

comprehend and digest the complexities of the SmartPlant schema. This document will present a real world example of how the relationships between graphics and data generated by an application are captured into the SmartPlant schema.

Symbolic Logic UML is used as a symbolic framework upon which we express the ideas that we are modeling. Even an experienced data modeler needs to know what symbols represent what ideas, but then it's Katie bar the door! The precise nature of the symbols (and symbolic logic, in general) virtually guarantees that ambiguity is minimized, and accuracy is maximized. Once you know that Figure 5 represents an interface, you know what to expect every time you see one of those circles. That's a real powerful idea!

23

6. The SmartPlant Data Model The SmartPlant Schema The SmartPlant schema describes the structure of data passed through SmartPlant Enterprise, along with its rules. The SmartPlant schema can be hard to understand, but to make it easier to interpret, the Schema Component exists. That is a set of .dll's that assists the tools with the generation and subsequent parsing of the XML data. The tool adapter interfaces with the Schema Component (the main interface point) to read the SmartPlant schema.

SmartPlant Schema Rules Because SmartPlant Enterprise is intended to facilitate heterogeneous data exchange, the following rules apply:

- All schema data is defined as part of the SmartPlant schema - The SmartPlant schema describes everything that goes on in SPF - A copy of the SmartPlant schema (an XML file) resides on the server - Component schemas are selective extracts from the SmartPlant

schema, and reside on every client - All changes are made to the SmartPlant schema and then propagated

to the component schemas.

Lots of Structures The SmartPlant Foundation data model consists of many structures (see Appendix J) that make it easier for programs to talk to each other. The SmartPlant schema is an XML file that describes the structure of the XML files generated by the authoring tools in much the same way as a data dictionary describes the structure of a database As tools publish documents in XML format, those documents must adhere to the format defined by the SmartPlant schema to ensure that the XML data can be loaded into SmartPlant Foundation (SPF), and retrieved into the other authoring tools. Here are some of the important concepts that we will cover in this chapter:

- Classes and ClassDefs

24

- Component Schemas (CompSchema) - Interfaces and InterfaceDefs - Properties, PropertyDefs and Property Types (Scoping) - Enumerated lists - Units of measure - etc.

Overview of the SmartPlant schema Data Model In the rest of this document, certain graphical conventions are used when creating and displaying a UML diagram:

• A "Class" is designated by a rectangle • An "Interface" may optionally be displayed as a circle or a rectangle • "Associations", a.k.a. "Relationships" are straight lines, which may,

optionally, be dashed-lines. Generally, two types of diagrams are developed, viz., an "Interface diagram", and a "Class diagram". Each type tries to present the data model in an interesting, understandable form. Other diagrams may be created to make it easier to visualize some aspect of the model. All the UML diagrams may be saved within the SmartPlant schema file and are available upon demand within the SmartPlant Schema Editor, when the user asks to see it.

SmartPlant schema Class / Interface / Relationship Model The building blocks of the SmartPlant schema are classes, interfaces, and relationships:

- Classes typically represent real-world objects like instruments, equipment or pipe runs. Classes are defined by ClassDefs.

- Interfaces are used to tightly bind "roles". Interfaces are defined by InterfaceDefs.

- Relationships represent the association between two objects. Relationships are defined by RelDefs.

In SmartPlant schema jargon, ClassDefs "realize" InterfaceDefs. For example, a Vessel class definition realizes the interface definition labeled ‘IVessel’. The "IVessel" interface "exposes" properties, such as "RatedVolume". Do you see: the main purpose of a ClassDef is to expose a group of related interfaces to the world.

25

7. Defining an Interface (InterfaceDef) Review of Interfaces The Guru maintains "Remember: an "Interface" represents "roles" that an object wishes to expose to (yield up to) the universe." It is a handy "collector" of very similar properties about some particular aspect of an object (due to data normalization). An Interface is a thing that provides a linkage between two things. The main point of an interface is that some underlying object can tell the world that it is willing to put forth (yield up) a certain "role", that other roles may wish to query, report on, or form relationships with. "All of you who are wearing sandals today, raise your hand" is the same as some query finding the "ISandal" interface realized by a class (in a published document). If the "ISandal" interface exposes the "ShoeSize" property, so much the better for the reporting program that cares about ordering size-15 sandals.

Defining an Interface (InterfaceDef) In the SmartPlant schema, an interface is defined using an "InterfaceDef" (d'oh!). The "InterfaceDef" is arguably the most important element in the SmartPlant Foundation data model, because it is the vehicle that lets objects yield up their roles to the universe. Let's just say that you need to get very familiar with InterfaceDefs.

InterfaceDef - Graphic Representation First of all, InterfaceDefs can be represented in 2 different ways, depending on what the data modeler is trying to express:

Figure 6 An InterfaceDef as a Rectangle

26

Figure 7 An InterfaceDef as a Circle

In Figure 6, the data modeler is trying to show you all the properties that the InterfaceDef exposes.

The <<Stereotype>> Notice the first line of text <<InterfaceDef>>. That style of printing (in UML terms) is called "stereotyping." You don't know about it much now, but a stereotype is a mechanism that is used to categorize an element in some way. A stereotype name is surrounded by Guillemots << and >>. Stereotypes are used to extend the UML notational elements, to classify and extend associations, inheritance relationships, classes and components. Stereotypes are used to create new kinds of modeling elements. That's one of the reasons that UML is so powerful, it is easily extended. Enough about stereotypes. In Figure 7, the data modeler is putting less emphasis on the properties, and is just stating (to you, the viewer) that the InterfaceDef exists.

27

8. Defining a Property (PropertyDef) In Figure 6, you saw that an InterfaceDef exposes some properties to the universe. In fact, doing a double-take, you should have noticed that there are pairs (tuples) of values:

- UID=IPumpOcc - Name=IPumpOcc - Description=An equipment item for transferring kinetic energy to a

fluid - PropCategory=Equipment - DisplayName=Pump

What is a Property? The Guru Googles some expert definitions:

- A property is a basic, or essential attribute shared by all members of a class.

- In philosophy, mathematics, and logic, a property is an attribute of an object; thus a red object is said to have the property of red-ness.

That's the idea that we tried to explain back in Chapter 3, when we talked about the Zen-like properties of objects, i.e., cars have some kind of essential property that is "car-ness"; a valve has "valve-ness", etc.

What is a PropertyDef? If you tightly-group very-similar properties together ("normalize them"), and expose them to the universe, it is more likely that someone who is wanting that set of properties will see and understand what you are trying to do. The little machine that handles the grouping and exposing to the universe is the InterfaceDef. The little machine that carries the -ness of a property is a PropertyDef.

"Scoping" a PropertyDef If we're talking about an inlet on a valve, it has some interesting properties:

28

- Inlet Size - Maximum Flow rate - Material of construction - Orientation-angle - Description of the valve - etc. We will want to "publish" these properties so that the "retrieving" application knows exactly what we're talking about. More than that, we both need to understand the possible values that can be entered into those properties. For example: - Inlet size is expressed a "length" - Maximum flow rate is expressed as a "flow rate" - Material of construction is a list of values - Orientation-angle is expressed as an angle - Description of the valve is letters and numbers - etc.

Scoping Examples In the SmartPlant schema, we say that a PropertyDef is "scoped by" something. That something defines the "units", or "lists", or "type of thing" that the PropertyDef will allow to be passed between applications, e.g.,

- With respect to "Inlet size", the values that we agree can be passed between our applications are length-units. Therefore we "Scope" the PropertyDef "InletSize" with "LengthUoM", which contains {inches, feet, meters, ...}.

o PropertyDef InletSize is ScopedBy LengthUoM - With respect to "orientation-angle", we agree that we're going to

exchange angles o PropertyDef OrientationAngle is ScopedBy AngleUoM, which

contains {deg, gr, rad, ...} - With respect to material of construction, I will pick a value from a

list, and later on, I will hand you the list. o PropertyDef MaterialOfConstruction is ScopedBy

EnumListType 'Materials', which contains {Iron, Copper, SS314, ...}

29

- With respect to the Description, o PropertyDef Description is ScopedBy string

Scoping Types The Guru looks right through you and says "So you see that "scoping" a PropertyDef is simply the equivalent of restricting data input values to certain "types"? Another way of saying it is that we are reducing the scope of what is possible down to some well-defined set of things. Here are the intrinsic (built-in) data types which can be used for Scoping PropertyDefs:

Intrinsic Type GraphDefType BooleanType IntType ClassDefViewDefsType LinkedListType CompositeStringType ObjectsType DateTimeType PathDefType DirectoryFileType PropComparisonsTypeDiscreteUoMListType PropValsType DocumentType StringType DoubleArrayType UoMListType DoubleType URLType EnumListLevelType ViewPropsDefType EnumListType YMDType

Table 1 Intrinsic Scoping Types

InterfaceDef / PropertyDef Redux Finally, the Guru shouts: "You will attain great levels of understanding when you realize that InterfaceDefs Expose PropertyDefs, which are ScopedBy Property Types!" Let's try reading Figure 8, a sample schema, and see how we do...

30

Figure 8 Sample InterfaceDef, PropertyDef, EnumListType An InterfaceDef, "SampleValveInlet" Exposes 5 PropertyDefs. Each PropertyDef is ScopedBy a different Property type, and each type shows some of the possible values that it allows. Note that in the SmartPlant schema, InterfaceDef names begin with the letter "I", by widely-accepted convention.

31

9. Defining a Class (ClassDef)

Figure 9 The Symbol for a Class Definition (ClassDef)

In Figure 9, we see the symbol for a class definition, or "ClassDef." Strangely familiar, you say? Right, the "rectangle" is used to express several different things in the SmartPlant schema. It's OK; we see the stereotype <<ClassDef>> which gives it away. A ClassDef is the SmartPlant schema element that will eventually become something important in the data that is "published" and "retrieved" from your software tool. Let's be more precise: instances of classes become "objects" within a container that gets published by a software program, during the "publish" process. For example, if your program normally creates equipment data sheets, you can expect to "publish" a document, which contains instances of Classes (that were defined by ClassDefs) which represent pumps, motors, stairs, etc.

Idea of Instance Let's see how good you are at understanding this: an instance of a class that was defined as a ClassDef named 'ELEWire' can be published, and is expected to contain data that is the electrical system's idea about a wire. Did you figure out the "instance" word? Think: "I am an instance of a human being" and you'll get the picture. The Mustang that is parked in front of Wal*mart is an instance of a car, and an instance of a Ford.

Object Identity We know how Ford keeps track of "instances of Mustangs" - each one gets a serial number, a.k.a. VIN. Same idea in the SmartPlant schema - all objects get a unique id (UID), which is Exposed by the "IObject" InterfaceDef. In addition to the obvious things, like pumps getting a UID, every object in the

32

entire schema gets a UID - everything. All relationships are then formed between two UIDs.

Model Definitions (ModelDef) A "model" is a non-redundant description of an object, e.g., a 3D plant model is a non-redundant 3D description of a plant. Model definitions in the SmartPlant schema are roughly-based on the POSC Caesar model. Please read about that here (for the link-challenged reader, please refer to Chapter 23).

It's Nice to Share (Objects) The primary function of a ModelDef is to identify those objects that can be "shared" between tools. Objects can only be shared if they exist within the same ModelDef. Objects in different ModelDefs can be related, but cannot be shared. The only use for the ModelDef is to enforce a rule that ClassDefs must be in the same ModelDef to participate in a Sharing relationship.

Sharing Allows Changes Sharing allows objects to be intimately acted upon by different tools, hopefully in a non-destructive way. For example, a pump is a type of equipment that is published, retrieved and CHANGED by many tools. This allows a cycle of ever-increasing knowledge about the pump to be added by each subsequent retrieve, modify, and publish of data about the pump:

- Some kind of pumping function is required - The pump is connected to streams - The streams have a certain fluid code running through them - The pump needs to pump at a certain volume - The pump needs a certain minimum horsepower on the driving motor - etc.

Another way of saying it is "each tool adds more value to the design by adding more and more information to the pump."

The SameAs Relationship In each tool, the pump is published with a different class definition. However, a SharedObjDef indicates that these classes are really talking about the same thing in SPF. When an object is created by one tool, then

33

published, another tool can retrieve the object, modify it and publish it as a different object (with a different UID). The two publishes establish a "SameAs" relationship (what that actually means is that the tools do the correlation). This indicates that the object from the first tool is the same as the object from the second tool.

Shared object definition (SharedObjDef)

Figure 10 Example of Shared Objects Look at Figure 10. It shows that many software tools can retrieve, modify, and publish "instruments", because they are in the "SharedInstrument_PM" model, meaning that they are "Planned material".

34

10. Defining a List of Values (EnumEnum, EnumListType)

Figure 11 The Symbol for an Enumerated Value (EnumEnum)

Enumerated Values (EnumEnum) In Figure 11, we see the symbol for an "enumerated value", which is named "EnumEnum" in the SmartPlant schema. What are "enumerated values"? They are formal definitions of possible values that are allowed to populate properties. An enumerated value is called "semantically strong." It is a "contract" between the program that "publishes" a value, and the program that "retrieves" the value.

Enumerated Lists of Values Engineering is full of lists of valid data that can be applied to data values, and shared between applications. For example, you can think of a list of StopLightColors as a set of {Red, Yellow, Green}. If somebody was going to exchange data about the color that anyone could expect to be visible in a stoplight, you would be limited to just those values. In the above example viz., stoplight colors, if the "retrieving" program gets a value of "Pink", what do you think will happen? I don't know either (it is only expecting Red, Yellow or Green). Somewhere, something is broken. Once programs all agree to a contract, it is hard to change, since the "publishing" program does not know who is "retrieving" the data, once the data is out in the wild. If you know all the colors that are valid, and someone wants to add a different value, who is responsible for getting the "retrieving" applications to change their software? That's mighty costly, and time-consuming. Here, at Intergraph PPM, we established a SmartPlant

35

schema Control Board (CCB), plus a separate Enumerated List Change Control Board to help control the consequences of changes to enumerated lists.

Enumerated Lists (EnumListType)

Figure 12 The Symbol for an Enumerated List (EnumListType) In Figure 12, we see the symbol for an enumerated list, or "EnumListType." An enumerated list groups enumerated values, and forms a "contract" between the "publishing" and "retrieving" applications. Now, let's add some enumerated values to the enumerated list in Figure 12:

Figure 13 The Symbols for a Populated Enumerated List Figure 13 shows that the enumerated list named "AC/DC" contains 2 values, viz., "AC" and "DC". I hope that it's obvious what's going on. Do you see the stereotyped relations between the EnumListType and the two EnumEnum entries? The stereotype <<Contains>> simply means that the list contains the entries.

Varying Strengths of Enumerated Lists Stoplight colors might be easy to guess (if you're an experienced driver), but if you don't know all the values of something, you can use a little "softer" approach: an "open-ended" enumerated list of values. You can "seed" the list with "typical" values, and let end-users extend the list (brands of automobiles is a good example). If you don't have a clue about what values might appear, just use a "string-type" property, and don't worry about what is published ("name" is a good

36

example, since, according to one source, there are 9 billion of them [thanks ACC]).

Properties can be Scoped by Enumerated Lists Every property definition (PropertyDef) is scoped by one and only one property type. An enumerated list (EnumListType) is one of the property types that can scope property definitions. Each enumerated list contains one or more enumerated entries. Each enumerated entry (EnumEnum) represents a possible value for a property that is scoped by that enumerated list.

EnumEnum Short-Text and Long-Text The "Name" property on the "IObject" interface for an enumerated entry is used to store the "short text" value for the enumerated entry. The "Description" property on the "IObject" interface is used for the "long text" value. For example, in the "ClampOptions" enumerated list, one entry has "Tri-Clamp 13MHHM" in the short-text field, and "Tri-Clamp 13MHHM Hinged Heavy Duty w/wing nut" in the long-text field.

Multiple-level Enumerated Lists (EnumListType) Many enumerated entries are intermediate nodes in a hierarchy of enumerated values. For example, the "typing" of equipment consists of a multi-level hierarchy where each level down the hierarchy provides a more specific definition of the equipment. Every branch node in a hierarchy is itself an enumerated list as well as an enumerated value. Only the top-most node in the hierarchy is not an enumerated value (just an enumerated list) and only the leaf nodes in the hierarchy are not enumerated lists (just enumerated values). This is easy if you can visualize:

- Equipment (an enumerated list) o Process Equipment (an enumerated list)

Process-equipment driver (an enumerated list) • Turbine (an enumerated list)

o Steam turbine (an enumerated list) Double-flow steam turbine (a value)

If you want to understand the underlying structure of enumerated lists, the following UML diagram presents the SmartPlant schema model for

37

enumerated lists and enumerated entries. However, I'd skip it if it's late in the afternoon.

Figure 14 Enumerated Lists and Enumerated Entries The "EnumListType" class definition is used for enumerated list property types. "EnumListType" realizes "IPropertyType", which allows it to be a scoping property type for property definitions. "EnumListType" realizes "IEnumListType", the interface definition that supports enumerated list behavior. "IEnumListType" has a Contains relationship definition to "IEnumEnum". Instances of this relationship are used to indicate the enumerated entries contained within the enumerated list. Leaf nodes within an enumerated list hierarchy are instances of the "EnumEnum" class definition. This class definition realizes "IEnumEnum", the interface definition that supports enumerated entry behavior, and "IObject", the interface that contains the short (Name) and long (Description) text values for the enumerated entry. Branch nodes within an enumerated list hierarchy are instances of the "EnumListType" class. "EnumListType" has an optional realizes relationship to "IEnumEnum", which means that an enumerated list may or may not be an enumerated entry as well. For branch nodes within an enumerated list

38

hierarchy, the "EnumListType" object will realize this optional interface. The topmost node in an enumerated list hierarchy is an instance of the "EnumListType" class definition. This instance does not realize "IEnumEnum" since it is not an enumerated entry. Also see the section on EnumListLevelType, and other related stuff (Chapter 26, section Ideas About Enumerated Lists).

Linking Enumerated Values to Interface Definitions (EnumMetadata) The SmartPlant schema provides a mechanism for designating multi-level Interface hierarchies. For example, there are many types of major equipment in a process plant. Not all participating tools will agree to a hierarchical breakdown of those many types (partly because each tool was developed independently). However they each need to be able to create an accurate "map" between their objects and the SmartPlant schema objects, so that they can publish and retrieve documents to the EDR. Since the tools can't agree on the hierarchy, they leave it up to the SmartPlant schema. The SmartPlant schema provides the "EnumMetadata" mechanism to control the hierarchies. Each InterfaceDef exposes a property called "EnumMetadata". When a hierarchical interface is added to the schema, a unique value may be placed there. Imagine a program that publishes a vertical centrifugal pump (maybe in a P&ID drawing). A second program (maybe SmartPlant Instrumentation) retrieves the document, but does not have such a detailed equipment hierarchy, and just has the concept of a "pump" (or even higher-level concept). When the second program publishes an updated pump, the first program still needs to know that it is a vertical centrifugal pump, not just a plain pump. When the publishing program creates a pump class object that realizes the "IVerticalCentrifugalPump" interface, which exposes the property "ProcessEqType1 thru 6", then, even though it did not know about the pump at a detailed level, it does not lose the information that the other program cared about. Notice that the ClassDef realized one or more of the following InterfaceDefs, viz., IProcessEquipment, IMaterialTransferEquipment,

39

IFluidTransferMachine, IPump, ICentrifugalPump, IVerticalCentrifugalPump. Maybe the program only knows about general concepts of process equipment, in which case, it realized "IProcessEquipment", maybe it is more detailed in its knowledge, but in any case, we don't lose semantic information about object type-ness. That's a powerful idea for sharing data between tools that don't have the same level of knowledge about objects! The Guru quietly says: "Therefore, an enumerated list entry is polymorphic with respect to the interfaces that are defined by its 'Metadata for enumeration' entries."

40

11. Defining Units of Measure (UoMEnum, UoMListType) Units of Measure (UoMListType)

Figure 15 Units of Measure Example

Figure 15 shows a unit-of-measure list (UoMListType), with some of its possible values, which are expressed as UoMEnums. A UoMListType is like an EnumListType (in fact, it is a child of an EnumListType). It exposes the possible values for the named unit-of-measures that might occur as data is exchanged between applications. Here we show that programs can exchange data about "electric current", in terms of Amps (A), milliamps (mA), emu's, esu's, etc. But not "pounds" or "inches", since they are not in the UoMListType.

Unit of Measure (UoMEnum) Each entry in the UoM list is a UoMEnum (which is a child of an EnumEnum) and has an "A" and "B" conversion value, which are used to convert from the "SI" unit to the target unit.

41

Check out Example 1, below: If the base is "Ampere", and the target unit is "mA" (= 1/1000th of an ampere), the A-conversion factor is "1000", and the B-conversion factor is 0. Because: it takes 1000 milliamps to equal 1 Ampere, the base "SI" unit.

SI Unit International System of units (SI), is the metric system of measurement. You can read about it here. Examples of SI units include: Ampere, Volt, meter, gram etc. Using the SmartPlant schema, the given unit (x) is multiplied by A, and then B is added to that value to determine the SI value (y = Ax + B).

42

Default SI Unit (HasDefaultSI) Also note in Figure 15 that there is a relationship, with a stereotype of <<HasDefaultSI>> that defines which entry in the table is the "base" or "SI" unit. When performing a conversion, everything gets converted to this, first. For example, if you publish a length of 1 inch, it will get transformed to the default SI unit, which, for length, is "meter" (SPF actually stores both values, i.e., the "as-published" value, and the "converted" value). Also, remember that you can't easily add values to a UoM list, because the retrieving application isn't expecting the new value. If you got a new unit "grex", and you were expecting {yard; foot; inch} what would happen?

Units of Measure Conditions If engineers are sitting around, talking about, e.g., pressure, they might express it as either "absolute" or "gauge". Technically, the difference is 1 atmosphere of pressure in the readings between absolute- and gauge-pressure. "Absolute" and "gauge" are instances of what we call "conditions." In the SmartPlant schema, we associate an enumerated list called a (ConditionList) that identifies the possible "conditions" for that unit of measure list. For example, a tool could publish the value "100 psi @ Gauge". A PropertyDef that is typed as a Unit of Measure has a double-precision floating point value in the SI unit for that list.

"Any" UoM (AnyUoM) List There is one more topic about units of measure lists. The "instrumentation" application presented this problem: a meter in an instrument loop might be

43

remote from the sensor that performs a measurement. The meter may be switched from one sensor to another, depending on operator preference. Can we change the meter to read "volts" now, and "pressure" later? The answer is "sure", because we realize that the meter is probably just a 0 to some-value general-purpose meter anyway. Somewhere a microprocessor is converting volts, or current, into units that get displayed on the meter, so the meter units are not very relevant. If a sensor changes value from 0 to 2 volts when the temperature changes from -100 to +100, the meter simply "scales" that range (reduces the difference between -100 and +100 to a range of 0 to 2), and displays the result. In other words, the "scaled" meter doesn't know if you want to see Joules per hour or kilograms per second. So, e.g., "IScaledInstrument" would expose a property, e.g., engineering units, which would be scoped by "AnyUoM", meaning that you might expect to see any value that is in that list "pop up" on that particular instrument.

44

12. The Implies Relationship (Inheritance) The idea that a dog inherits some characteristics of a wolf is a pretty obvious, and we can model that concept. It goes back to the Linnaean taxonomic model and a simplified model might look like this:

Figure 16 A Taxonomy of a Dog Figure 16 says "if something claims that it is a dog, i.e., fulfills the role of being a dog, then that claim also implies that it is a type of wolf, which implies that it is a type of mammal, which implies that it is a type of animal." The relationship between the InterfaceDef named "DOG" and the InterfaceDef named "WOLF" has a stereotype of <<Implies>>, which means:

- Is a kind of - or Requires this set of properties to complete it's existence

Notice that the Implies relationship has a "1" on one end and a "2" on the other end. "1" and "2" represent "ordinal" numbers on a relationship.

45

Ordinal numbers have to do with the "order" in which things appear. The end with a "1" is the "source", or "child" in the relationship, and the end with a "2" is the "destination", or "parent" in the Implies relationship. In other forms of UML, e.g., the Rational Rose UML tool, there is usually an arrow, which points from source to destination.

Property Inheritance The InterfaceDef at the "end-1" inherits all the properties of the InterfaceDef at the "end-2", all the way up the tree. NOTE: your published data doesn't get properties by implying an interface; rather, to get the properties, you must realize the InterfaceDef.

Implies is a Transitive Relation DANGER! Better skip this (higher-level mathematics is involved) You might have the teeniest question in the back of your mind, "does this guy know what the heck he's talking about?" Let's discuss the "Implies" relationship in more detail, and then You Decide. Definition: In mathematics, a binary relation R over a set X is transitive if it holds for all a, b, and c in X, that if a is related to b and b is related to c, then a is related to c. In mathematical notation, this is:

To make it simpler, since we were kids, we learned that we are our mother's child, and, therefore, her mother is our grandmother.

Conversations re: Dog, Wolf, Mammal and Animal Look at the <<Implies>> relationship between DOG and WOLF and MAMMAL and ANIMAL in Figure 16 again. If we know that a MAMMAL has certain characteristics, e.g., a warm-blooded vertebrate that grows hair on its skin, then the model says that it is safe to Imply that a WOLF has those characteristics, and a DOG has those characteristics, too. And we can conclude that since a MAMMAL Implies ANIMAL, then a MAMMAL has the characteristics of an ANIMAL, too (meaning that it's not a vegetable or mineral). The Guru queries: "Do you now understand transitive relationships?"

46

"Things that have Legs" Look at Figure 16 again - let's think about "things that have legs", i.e., as a data modeler, where would you put the property "Number Of Legs":

- Do all members of the ANIMAL class have legs? NO - Do all members of the MAMMAL class have legs? MAYBE, e.g., whale,

dolphin, etc. are mammals, but don't appear to have legs. - Do all members of the WOLF class have legs? YES - Do all members of the DOG class have legs? YES - Just to make this mind-exercise more stimulating:

o Do all members of the FROG class have legs? YES - are they MAMMALs - NO!

o Do all members of the BIRD class have legs? YES - are they MAMMALs - NO!

o Do all members of the DESK class have legs? YES - are they ANIMALs or MAMMALs - NO!

Referring to Figure 16: So somewhere "above? or below?" MAMMAL and "above" WOLF, the idea of "things that have legs" is introduced. If this were a Linnaean taxonomic model, we would need to sort out classes of things, such that all members of the MAMMAL class don't have legs, e.g., whales don't have legs, but the class WOLF, somehow does have legs. The Guru points his index finger into the air and emphatically states: "The great thing about using Interfaces to expose roles and group properties is that any class that fulfills a role can expose that role to the universe with an interface." Therefore, there is no gnashing of teeth "where will we introduce "THINGS WITH LEGS" into the hierarchy?" It's far simpler to just say:

- a WOLF Realizes that it has legs - a FROG Realizes that it has legs but is not a MAMMAL - a BIRD Realizes that it has legs but is not a MAMMAL - a DESK Realizes that it has legs and is not an ANIMAL - etc.

47

Boring Author's note: YES, a whale has vestigial legs, which means they are not visible (and not particularly useful). Probably since he doesn't have to walk to the local Quick Sack for a beer - ain't life strange? If you're a data modeler, but not a "domain expert" on whales, you might model it wrong for a couple of reasons, e.g., is it a mammal or fish?; does it have legs or fins? Also, we suspect that probably all mammals have legs, since they're vertebrates, but the data modeler is not always a certified expert on vertebrates, mammals, valves, pumps or electric wires.

"Implies" and Relationship Inheritance Besides inheriting the "properties" of a "parent" class, a "child" inherits the "behavior" of the parent, too. For example, if the InterfaceDef "WOLF" has a Relationship to "TERRITORY" (meaning "a wolf is territorial"), then the class "DOG" will "inherit" that relationship, too, i.e., "a dog is territorial."

"Optional" vs. "Required" Implies Looking at Figure 16, we said that "if something claims that it is a DOG, i.e., "fulfills the role of being a dog", that also implies that it is a type of WOLF, which implies that it is a type of MAMMAL, which implies that it is a type of ANIMAL." But is that entirely true? Is every instance of a DOG a type of WOLF? The answer is YES. So we probably want to put some real "strength" into the model of "Implies" that states that fact. The <<Implies>> relationship has a property named "IsRequired", which may be set to "True" for exactly that purpose. Some facts about a DOG may not always be true. For example, every WOLF is a HUNTER, but is every DOG a HUNTER? Think about the tea-kettle poodle, down the street, and you'll realize that at 2 pounds, he won't be bringing down a 2,000 pound Caribou, anytime soon. He is an instance of DOG that does not inherit all the properties of WOLF. If DOG Implies WOLF, and WOLF Implies HUNTER, we should make that Implies "Optional", since some members of the class DOG do not fulfill the role of HUNTER (at least little Fluffy can dream).

48

13. The Realizes Relationship The Realizes Relationship The Guru says: "A ClassDef Realizes InterfaceDefs which Expose PropertyDefs, which are ScopedBy Property Types." What he means is: an object that is defined by a ClassDef expose its "roles" ("yields them up to the universe") via InterfaceDefs - after all, that's where "role" information is carried. Let's try a little thought experiment: A German Shepherd realizes that it has some characteristics of a WOLF, a MAMMAL, and an ANIMAL, like Figure 17, below:

Figure 17 A Dog Realizes that It's a Wolf, too

Do you see how we said that the German Shepherd, which is an instance of a "DOG" class, realized something about itself, and then it yielded up those ideas to the universe by Realizing InterfaceDefs? That goes back to Powerful Idea #1. (with a dog, realizing something about himself is possible, but a "pump" or a "valve" realizing something about themselves? Believe me, we're data modelers: it's easy to think abstract thoughts, OK?).

The "Primary" Interface The SmartPlant schema has an important concept of how roles are grouped, such that when you finally look at an object, you can tell what its "essential"

49

role is. That role is exposed via the "Primary Interface". A couple of examples are in order:

- The Primary Interface for a dog is DOG, i.e., the role that exposes "dog-ness", and is the essential definition of each dog in the universe. Any 2-year-old would understand that you're talking about a dog if you yield up the Primary Interface "DOG".

- The Primary Interface for a bicycle is BICYCLE, i.e., the role that exposes "bicycle-ness", and is the essential definition of each bicycle that you could ever encounter

- The Primary Interface for a valve is VALVE, i.e., the role that exposes the "valve-ness" of every valve in the universe.

Now, let's refine and qualify that idea a little bit for SmartPlant schema users (because you're special). First, by convention, SmartPlant schema Interfaces start with the letter "I", and next, Primary Interface definitions for concrete objects generally end in "...Occ", which means "the occurrence of an object." For example, the Primary Interface definition for "PIDInstrument" is "IInstrumentOcc". For more information about occurrences, see this. So, really, in the SmartPlant schema, the list looks like this:

- The Primary Interface for a dog is "IDogOcc" (an occurrence of a DOG)

- The Primary Interface for a bicycle is "IBicycleOcc" - The Primary Interface for a valve is "IValveOcc"

The most relevant purpose for the Primary Interface is to define the full and complete "role-ness" of an object. It defines what an object "is" and everything that is know about it. The Guru sternly warns: "A ClassDef MUST Realize the Primary Interface. In addition, it MAY Realize any other Interfaces that are either directly or indirectly Implied by the Primary Interface." Otherwise, the Schema Police will write you a ticket!

50

14. Defining a Relationship (RelDef, Rel) The Relationship Definition (RelDef) See if you remember: One of the underlying purposes of an object exposing a role to the universe is so that someone else can form a relationship with it. Now that you have seen some basic symbols, look at this:

Figure 18 A Relationship Between Man and Woman Figure 18 shows one possible relationship (aka. association) between a Man and a Woman, viz., Marriage. There are obviously numerous other roles that could be shown, but this one is easy enough to understand. Here we are defining that a relationship "can" exist between a Man and a Woman, but we do not insist on that - all men are not associated to all women via Marriage! Let's say it a different way: We model how one role is related to another role by a "relationship definition" a.k.a. RelDef.

A Data Modeler Defines Marriage (hoo-boy!) Try this: a relationship (which is defined in the schema by a RelDef) defines how an instance of the class Man (let's say: Doug), can form a valid relationship with an instance of the class Woman (let's say: Diane). One possible relationship they can form is named Marriage. Other relationships are possible, in fact if you think about the countless ways that a Man and a Woman can be related to each other, it boggles the mind. To calm you down a little bit, let's agree to model the "important" relationships now, and the "less-important" relationships, mañana.

A Data Modeler Thinks About RelDefs Here's a more technical description (it uses big words, but don't be scared). I want you to be clear about what goes on in this relationship definition thing:

- In the data model, any object in the universe that fulfills the role of Man can expose that role to the universe via an interface. If you

51

think that you fulfill the role of Man, then you can state "I realize that I am a Man, therefore the class (that I am an instance of) in the model should Realize the Man interface."

- In the data model, any object in the universe that fulfills the role of Woman can expose that role to the universe via an interface. If you think that you fulfill the role of Woman, then you can state "I realize that I am a Woman, therefore the class (that I am an instance of) in the model should Realize the Woman interface."

If you Realize the Man interface, you may look out amongst all the objects in the universe that Realize the Woman interface and form a relationship with that object. That relationship is called Marriage. I don't want to hear complaints about how the data model "objectifies women", because it absolutely does! ...and men, too! ...and valves, too!

A Guru Ponders Marriage Let's take a short ride in a fast machine, i.e., the mind of the data modeling Guru in action!! After looking at the data model in Figure 18, here's how the Guru thinks about what the model says:

- "A man" o (thinking) "A man" is a member of the set of "Man"

(thinking) The set of "Man" that we're thinking about, is referring to objects that Realize that they are a Man.

• (thinking) Since objects are defined in the SmartPlant schema using ClassDefs, we're talking about a ClassDef that Realizes InterfaceDef Man

o (thinking) Therefore, an object identified as Doug, since it is an instance of a class that Realizes the Man interface, can participate in the Marriage relationship.

- Can form an association with "a woman" o (thinking) "A woman" is a member of the set of "Woman"

(thinking) The set of "Woman" that we're thinking about, is referring to objects that Realize that they are a Woman.

• (thinking) Since objects are defined in the SmartPlant schema using ClassDefs, we're talking

52

about a ClassDef that Realizes InterfaceDef Woman

o (thinking) Therefore, an object identified as Diane, since it is an instance of a class that Realizes the Woman interface, can participate in the Marriage relationship.

- And that relationship is called Marriage. o Which means that an instance of a relationship definition

(RelDef) is going to be published, (i.e., a Rel) And the Rel will have a unique id (UID) And one end of the Rel contains the ID of Doug And the other end contains the ID of Diane

(as if you needed further proof that the mind of a data modeling Guru is a pretty strange thing). Please note that there may be legal or cultural rules about forming that particular relationship that need to be modeled, and they are called "semantics, rules, ontology, etc." We'll give you a breather for now, but this is an important subject, and there is more discussion on this topic coming up - but wait!, I think I hear wedding bells in the distance. Let's see what other properties are on a RelDef - look way below, at Figure 59. What do you see?

- A RelDef has a Name that describes the relationship - The Name and UID must be the same - It may have a description (that might be valuable to someone who is

trying to figure out what the relationship does) - A relationship may be "ordered" on end-1, end-2, or neither - A RelDef may have a Link Interface property (an InterfaceDef) - A RelDef may be "abstract" or "concrete" - A RelDef has 2 ends, end-1 and end-2 - Each end contains the name of an InterfaceDef - Each end has a "role" name - Each end may have a role "display name" - Each end has a "minimum" and "maximum" cardinality - Each end must make a statement about how objects are published - Objects at either end may be filtered out of a down-stream display - A RelDef may have Delete and Copy semantics

53

- etc. You're probably asking yourself: why do we need a RelDef at all? The Guru's characteristically simple answer is "Instances of RelDefs become Rels." But I'm betting that you won't let me get away with that. In order for two objects to form relationships with each other, they need some kind of "contract" that explains how they can do that. That's so that the "retrieving" software knows what the "publishing" software is capable of doing. It's almost a miniature pre-nuptial agreement.

"Abstract" Relationship Definitions One good thing about the concept of "abstraction" is that it lets you define things at a high-enough level that characteristics of many things become obvious (the view from the top of a mountain is further). For example, if you see a Ford Mustang, it has certain characteristics, but it is also a "car", which has more general characteristics, and is a type of "vehicle", which is a type of "who knows what." At each level of the hierarchical definition, more general properties and relationships can be described:

- John owns that Ford Mustang with VIN 2G58H190699 (a 1:1 relationship)

- People own cars (an M:N relationship between people and cars that are registered at the County Courthouse so that taxes are paid)

- People own vehicles (an M:N people to cars, motorcycles, buses, etc., each type of which is kept track of at different locations, but all of which are probably taxed like crazy...)

At some point, you can identify some essential properties of the relationship. In this case, many people can own many vehicles seems to be a correct statement, so that seems like a good candidate to become a RelDef in the SmartPlant schema: it expresses cardinality (N:M), roles (Owner, OwnedBy), has a name (OwnsVehicle). Also, realize that abstraction can get out of hand. John's Mustang has weight, so does his motorcycle, and his boat. But nobody cares about the aggregate weight of all his vehicles, or, more to the point, nobody cares about the aggregate weight of everybody's vehicles!

54

Introduction to Delete Propagation Semantics There can also be some actions that happen if an object is deleted on either side of a relationship, e.g., the owner sells a car - what happens?

- The car probably doesn't cease to exist. - The owner probably doesn't cease to exist. - The relationship, in fact, is permanent, so that the tax bureau can

figure out what date the car changed hands, even years after the transaction occurred.

- At some point, a different owner may buy the car, and therefore establish a new relationship that needs to be tracked (forever).

- Maybe the car will be destroyed, in which case no more relationships may be formed with it.

Another example of a relationship would be to think of a desk that has drawers. Ask yourself: what if one of the drawers is pulled out, and destroyed? Does the desk go away? How about the owner of the desk (if any). Does he cease to exist? Now, ask: what if the desk goes away? I'm pretty sure that drawers go with it, but the owner doesn't disappear. So it can be a good idea to have abstract relationships, which describe roles that are related, and what happens if one of them goes away.

"Concrete" Relationship Definitions If you know that John owns a Mustang with VIN 2G58H190699, you should ask yourself if there is an "abstract" relationship definition (RelDef) in the model (or that can be put into the model) that expresses that same idea, but at a higher-level. In this case, we would find that the schema has an abstract relationship "PeopleOwnVehicles" and it has a child "PeopleOwnCars" - therefore, we can conclude that our new RelDef should be a child of "PeopleOwnCars", so that the proper cardinality, roles, and semantics will be inherited by our new relationship. We've been serious for too long. It's time to lift up our spirits and discover how Relationship Definitions (RelDefs) and Relationships (Rels) work with "real-world" objects.

55

Invitation to a Wedding (Example of a Rel) If Doug, an instance of a "man", and Diane, an instance of a "woman", want to get married in the SmartPlant Foundation Chapel of Love, we would first model the "Marriage" relationship between them as a RelDef "Marriage" (while the organ plays the Wedding March from Lohengren). That Marriage RelDef allows ANY "Man" and ANY "Woman" to participate in that relationship. Then, after the Service, the EF-compliant "marriage software" would "publish" a document (to SPF), that described the joyful announcement like this: "a new instance of RelDef Marriage, has been established between an instance of "Man", Doug and instance of "Woman", Diane, and has been assigned the unique ID of 12345". The published Rel ("i.e., instance" of the "Marriage" relationship definition) links the object of the first part (id= Doug) to the object of the second part (id= Diane) in wedded bliss. NOTE: as a data modeler, I would think that there also needs to be a "start date", and, possibly an "end date" on the relationship. That would be a clue that the data modeler needs to model those properties.

Introduction to Cardinality Not to get too far away from the "marriage" as a "RelDef" idea, we could talk about the "cardinality" of the relationship, i.e., y'all expect that both Doug and Diane are married to exactly 1 person at a time. However, in the context of the real-world, we know that the love-birds can both be divorced and re-married "zero or more" times, to many other people over their lifetimes. That means that the data modeler needs to use a cardinality of zero or more (0..*), a.k.a., "many" on each end of the RelDef. Do you see what "cardinality" represents - a count. So, if Doug and Diane can be married to more than one person in their lifetime (under any circumstance), then the roles on each end of the RelDef should include a cardinality of "many." The cardinality does not say "when" they can be married (that's usually a cultural restriction), just that they can be married to more than one person during their lifetime. In the properties listed above, you can see that the definition of a relationship is a very complex topic. The "contract" between InterfaceDefs

56

has to state a lot of stuff, like roles (I am a Man, vs. I am a Car owner) and cardinalities (there must be exactly 1 of me). If two InterfaceDefs could just join hands and form a relationship, it would be very difficult for the retrieving software to know if any rules had been broken, e.g., if the cardinality (the count) on one end of a relationship is from 0 to 3, how can the retrieving program know that the data that it is retrieving is OK? The RelDef simply describes the "contract" and can say the cardinality is such-and-such, and the retrieving application can just count on it being right.

Which RelDef is Right for Me? The SmartPlant schema has a lot of RelDefs, and if you stare long enough, you may go blind. How do you pick the right one, so that your Rel has a good parent? First, think about the "contract" that you're forming between the two roles that you're associating. For each of the 2 roles that are being related, what do they imply? For example, is the most appropriate place to make the association between this role and another at a very specific level, a not-so-specific level, or a very abstract level? Think: is this keyboard related to this computer, or do most keyboards wind up with a relationship to computers in general, or is it more general than that, maybe I/O devices in general are related to machines in general?

- First, pick the right level of abstraction, i.e., from very concrete to very abstract. Look at the "Implies hierarchy" to see what relationships you can form.

- Next, you should not use an "abstract" RelDef to create a Rel in the document that you publish (not strictly enforced).

- Last, is "cardinality" an issue? Is there a RelDef that has the right cardinality on both ends?

Locality of Reference For the true RelDef aficionados (I know that a few of you are out there), there is a little-known property of a RelDef called "locality of reference". Skip this junk (he's off the deep-end). Here is a model of a RelDef:

Figure 19 RelDef Model

57

See the little bitty minus-signs in front of the two roles? They represent the locality of reference for each role. Thinking that an instance of a RelDef is a relationship, let's visualize a relationship between a vessel and a nozzle on that vessel, i.e., a vessel is a type of equipment, and a nozzle is a type of equipment component.

Shared Objects and Locality of Reference Now we're getting ready to "publish" either the vessel, the nozzle, or both from our SPF-compliant software "tool" into SPF. Let's think about "shared objects" for a minute. Shared objects are published by different tools, and have a shared (agreed-upon) concept (with other tools that also agree) about vessels and nozzles:

- Can we just publish a vessel without nozzles? - Can we just publish a nozzle without knowing what vessel it is

associated with? - What happens if we publish a vessel and some, but not all, nozzles?

And to make it more interesting, what about the other tools that think that vessels and nozzles are shared objects? The "they", below, refers to "another tool":

- Can "they" just publish a vessel without nozzles? - Can "they" just publish a nozzle without knowing what vessel it is

associated with? - What happens if "they" publish a vessel and some, but not all, nozzles?

Sorry Charlie, the Guru doesn't know the answers to any of those questions. Therefore, he recommends that you use the locality of reference property on each role to control whether the object at this end of the relationship: - Must be in same container as other object - Must be published by same tool as other object - Has been published by another component Let's make it a little clearer. By "publishing a document", we mean that we are working with some software tool that creates an XML document (via an

58

adapter) that may contain vessels, and may contain nozzles. For each nozzle that is related to the vessel, there will be a relationship between the vessel and the nozzle (V101 <--> N1). As you create that relationship, surprise! you find that you don't know a thing about, e.g., the nozzles! For some perfectly valid reason, you are only in charge of creating vessels, not nozzles. Should you publish the vessel, if you already know that you don't know about its associated nozzles? Well, maybe! Same scenario for the tool that publishes nozzles, but hasn't got a clue about vessels - can he publish a relationship with one end being "this nozzle", and the other end being "I dunno"? Maybe! Are you a little surprised? Thinking about shared objects for a minute, you realize that "some other tool may be able to publish the data that is associated with my data, at an earlier or later time, and that's OK." I know nozzles, and Bo knows vessels. That's fine. But when I publish the "nozzle", I'm counting on Bo to supply the UID of the vessel, so that we can complete the relationship between us (vessel <--> nozzle). What gets published is validated against the locality of reference property. You ask the Guru: "Is it OK for me to publish a 'dangling relationship'"? Surprisingly, he says: "Yes, because, based on the value of the locality of reference property, we expect Bo to publish the rest of the data tomorrow, using his tool."

59

15. Unique Identifiers (UIDs) In the SmartPlant world, every object must have a unique ID (UID). A UID is a necessary property of each object in order to keep the database in a consistent state. Since the SmartPlant schema is built on top of SPF, UIDs must be unique within the context of SPF. You can skip the technical ideas about UIDs. Every UID must follow the "ACID" principle, viz., be: Atomic - A transaction must execute exactly once and must be atomic—either all of the work is done or none of it is. Operations within a transaction usually share a common intent and are interdependent. By performing only a subset of these operations, the system could compromise the overall intent of the transaction. Atomicity eliminates the chance of processing only a subset of operations. Consistent - A transaction must preserve the consistency of data, transforming one consistent state of data into another consistent state of data. Much of the responsibility for maintaining consistency falls to the application developer. Isolated - A transaction must be a unit of isolation, which means that concurrent transactions should behave as if each were the only transaction running in the system. Because a high degree of isolation can limit the number of concurrent transactions, some applications reduce the isolation level in exchange for better throughput. Durable - A transaction must be recoverable and therefore must have durability. If a transaction commits, the system guarantees that its updates can persist even if the computer crashes immediately after the commit. Specialized logging allows the system's restart procedure to complete unfinished operations required by the transaction, making the transaction durable.

60

16. Edges, Graphs, Views & Class View Map (EdgeDef, GraphDef, ViewDef, ClassViewMap) The SmartPlant schema has structures that make it easier for the tools to view things more like "their" world. Remember that each software tool has its own idea of how objects are hooked up. The ability to navigate from one object in the model to another object in the model can be determined by Edge definitions (EdgeDef). This allows you to specify which interface to start the navigation, and which direction to travel, in order to see information associated with a different interface. Once these navigation "edges" have been defined, they can be grouped together to form a Graph definition (DirectedGraphDef). These are a connected network of edge definitions. Finally, a View definition (ViewDef) is a way of filtering lists of properties that will be available in the user interface. A ViewDef can also be used as a way of securing information, i.e., certain users may be allowed to see portions of the model, and others won't, based on a ViewDef that is based on their role. NOTE: This chapter is definitely harder to understand, because the concepts are built upon a deep understanding of the ideas that were presented so far. There are a couple of technical documents that have been published that cover all the details of EdgeDefs, GraphDefs, and ViewDefs, e.g., "View Definitions", and "Edges Graphs and Views". Skip over this junk, it's just too technical for me.

Edge Definition (EdgeDef) An edge definition (EdgeDef) starts at some Interface, and creates a "path" through the schema to other interfaces - the path is called an "edge." In SPF, edge definitions are custom relationship expansions that appear on the shortcut menu when a user right-clicks an object that exposes the relationship referenced by the edge definition. Instead of requiring the

61

user to go directly from Object A to Object B in the tree view, an edge definition can be created to allow the user to traverse through multiple intermediate objects and display an object at the end of the relationship that meets the specified criteria. For example:

- An edge definition could be created to expand only the first nozzle on a vessel.

- A system administrator might create and edge definition to traverse directly from a plant to a unit. In SPF, units are directly related to a functional area. However, a custom edge definition would allow the user to expand the plant to see the units without expanding a functional area first.

Each edge definition consists of the following:

- A starting Interface definition (InterfaceDef) - A path definition that originates there - Discrimination, or "filtering" criteria that is applied to objects at the

end of the path - Position criteria (ordinality) that can select a specific object from the

set of objects at the end of the path that satisfy the discrimination criteria.

You can create edge definitions for a variety of purposes:

- To traverse across multiple relationships - To select only certain objects from the destination end - To do multiple relationship traversal and selection of objects

Here's an example of a useful application of an EdgeDef. Look at this conceptual diagram of a process vessel with some nozzles:

62

Figure 20 Vessel with Nozzles (Conceptual)

The SmartPlant schema for that looks like this:

Figure 21 Vessel with Nozzles (SmartPlant schema) So, let's cook up a couple of useful EdgeDefs that might make life easier for reporting:

- Get me the "1st" nozzle on the vessel (ordinality = 1) - Get me a named nozzle on the vessel (Name = "Inlet" or "Drain") - Get me nozzle #2 (or #3, or #8)

Since EdgeDefs can be arbitrarily complex, we can think about these:

63

- For Pipe run "XYZ-123", show me the vessels along the pipe run that have a "Drain" nozzle

o Pipe run -> nozzle -> vessel -> nozzle="Drain" - For Pipe run PR-101, go through the vessel and tell me the name of the

Pipe run that exits the vessel as a "Drain" o Pipe run("PR-101") -> nozzle -> vessel -> nozzle="Drain" -> Pipe

run - Show me the Valve that controls the output of nozzle #2?

o Nozzle(#2) -> Valve Figure 22 shows an EdgeDef that uses a numeric position property:

Figure 22 EdgeDef Example of Numeric Position

- This is the SmartPlant schema EdgeDef named "PipingPort1" - It starts at "IPipingPortComposition" - and travels across RelDef "PipingPortComposition" - It will succeed if the NumericPosition property = "1" (or some given

value) - Can you guess how to get to "PipingPort2", or "3", etc.?

That allows you to easily filter your view to just port "1", or "2", etc. Finally, Figure 23 is an example that lets you specify a property value, instead of a numeric position to make your EdgeDef useful:

Figure 23 EdgeDef Example of Property Comparison

- This is the SmartPlant schema EdgeDef named "StreamNormalCase"

64

- It starts at "IProcessDataComposition" - and travels across RelDef "ProcessDataCaseComposition" - It will succeed if the PropComparisons property =

"IProcessDataCase~ProcessCase~=~Nor" o That means "if the "ProcessCase" property on the object

contains the string "Nor" - bingo! you'll see it on your report (well, you still have to write the report software).

Graph Definition (DirectedGraphDef) A graph definition (DirectedGraphDef) is used to define directed graphs (a connected network of edge definitions) and includes: - A relationship to its starting Interface definition (InterfaceDef)

- A definition of the directed graph

Technical Details of Graph Definition (DirectedGraphDef) Each graph definition starts at an interface definition (InterfaceDef) and branches out from that interface definition to related interface definitions. Any edge definition (EdgeDef) that is tied to the starting interface definition or to an interface definition implied (either directly or indirectly) by that interface definition can be used as part of the graph definition. Likewise, when an edge definition is traversed as part of a graph definition, the ending interface definition (and its implied interface definitions) for that edge definition can also be used to add edge definitions to the directed graph definition.

Figure 24 Sample of a Directed Graph

View Definition (ViewDef) A view definition (ViewDef) is used to provide an alternative view of data to that provided by the underlying schema. While schema-based depictions of

65

the data are useful to viewers familiar with the underlying schema, other users will need more user-oriented views of the data for it to be meaningful. View definitions are the EF equivalent to relational database views. A relational database view is, in simplified terms, a combination of joins and projects (prō-ject' as verb not noun – emphasis on second syllable), where the joins are used to retrieve the desired objects and the projects are used to determine which properties (columns) to include and what to call those properties. The EF equivalent (actually much more powerful) to the relational database joins is the directed graph definition as previously described. The projection of this graph data in EF is accomplished using the view definitions. An EF view definition consists of the following:

• A relationship to its starting interface definition • An identification of the directed graph definition that applies • A definition of the projection of property definitions from the

directed graph definition A view definition (ViewDef) is based on a directed graph definition (DirectedGraphDef) and, therefore, like it, has a relationship to its starting interface definition (InterfaceDef). In actuality, this interface definition is always the same interface definition as that for its directed graph definition (kept redundantly for performance reasons). As described previously, the directed graph definition for the view definition defines the set of edge definitions that will be traversed when the view corresponding to the view definition is created.

Figure 25 ViewDef

66

Class View Maps (ClassViewMap) Class view maps (ClassViewMap) is a collection of ClassDefs and ViewDefs that have related user groups in SPF. Since they are only used by SPF, they will not be covered in detail here, but there is documentation available. It should be sufficient to say that the ClassViewMap is important for shared class definitions because it allows you to use the same view definition for multiple class definitions, including those objects that are shared across tools. By using the same view definition for multiple class definitions, users see the same presentation of information whether they are looking at the originally-published class, or a class from another tool for the shared object. For example, if SmartPlant P&ID publishes an object of the "PIDProcessEquipment" class, and Zyqad publishes an object of the "EQDCentrifugalPump" class, the shared object will have a different class in SPF. To allow users to see the same "view" of the shared object regardless of which tool published it, the same view definition could be associated with both the class definitions. (Sorry, I bet that this chapter wore you out.)

67

17. UML Concepts (Elaboration) The most important concept of the SmartPlant schema is that it is based on exposing "roles", implemented via "interfaces" to the outside world. This concept is called "role-based modeling." By way of example, a discussion is provided that re-states everything that we already said - I just want to be sure that you "get it." The Guru declares: "Resistance is futile."

The Most Important Concepts of the SmartPlant schema Data Model Class - a specification of the low-level structure and behavior of some set of objects. Classes specify an object's attributes (data elements) and methods (member functions). A class generally represents a real-world object, in other words it is like a biological species. A class can offer up many "roles" to the world. For example, a “Man” can be a “Father”, a “Husband”, an “Uncle”, a “Steelworker”, a “Taxpayer”, a “Driver” etc. None of the roles that the “Man” plays with the universe are necessarily “mutually exclusive”. When the IRS wants to interact with the “Man”, it doesn’t care that he is an “Uncle” or a “Driver”, it cares that he exposes a “Taxpayer” role that they can interact with. The “Taxpayer” role probably has a unique id (Taxpayer number) that the IRS uses, along with other properties that are relevant to the “Taxpayer” role. Obviously, the class “Man” can play many roles with the universe. The Guru affirms: "A class "exposes", or “yields up”, or “realizes” its roles through abstract entities called “interfaces”. Finally, a class is defined by a ClassDef. Interface - A "role" that a class of objects "realizes" that it is (exposes to the universe). Generally speaking, an Interface contains the properties that are used by the outside world to interact with the class. The properties are usually non-redundant among the interfaces (good practice). By convention, interface names are preceded by the letter “I”. For example, the “Taxpayer” role is exposed to the universe by the “ITaxpayer” interface. “ITaxpayer” would probably contain the Man’s taxpayer id. The

68

“ISteelworker” interface would contain his Union affiliation; the “IDriver” interface would contain his driver license number, etc. Although a "Man" yields up many roles to the universe, somehow, the properties of each role need to be clearly discriminated. That makes the roles "orthogonal to" ("having a set of mutually perpendicular axes, meeting at right angles") each other. Why is it an advantage to think this way? There are no relationships between classes, only between interfaces. That is because only the interfaces are exposed to the outside world. The underlying reason for modeling classes and interfaces instead of classes and relationships is because of the complexity of the relationships that can be formed. In a traditional "class-based" data model, relationships go directly from one class to another. The problem is, e.g., when the class hierarchy gets moderately deep, the relationships become very hard to understand. The consequence is that the modeler moves the relationships “up” in the hierarchy, which causes ambiguity in defining just what the relationship represents. By grouping similar characteristics together and exposing them as an abstract entity called an interface, it is easier to maintain precision in the relationships. In a classical taxonomy (hierarchy), it is often very difficult, or impossible, to clearly define which properties belong to which classes of objects. In the preceding example, we could say that a "Woman" could have most of the same properties as a "Man" - except for, viz., "Uncle" and "Husband" - a "Woman" simply can't play those roles. Likewise, a "Man" can't play the role of "Wife" or "Mother". So to model a "Man" and "Woman", we could take the common properties of both, i.e., (Athlete, Breadwinner, Teacher, etc., and put them at a higher abstract level, i.e., "Person". Then the "Husband-" and "Wife-"specific properties (isFather; isMother) could stay at the more detailed level ("Man" might be "Father"; "Woman" might be "Mother"). The Guru allows: "It should be clear that a "Person" can't be both a "Father" and a "Mother", so modeling the class with both of those properties is incorrect, because it is ambiguous. The situation may be prevented just by modeling the classes correctly."

69

An interface is defined by an InterfaceDef. Object - an instance of a class, e.g., 3.14159 is an instance of a floating-point numeric type.

Interface Polymorphism (WARNING: Skip this unless you are a real hard-core geek) The Guru lectures: "In the SmartPlant schema, polymorphism is implemented via the "Realizes" relationship. When two classes "realize" the same interface, they are said to be polymorphic with respect to that interface (see Figure 39). Which means that a client can make early-bound calls to the properties (and, within SPF, methods) of the interface without having to know the class of the object it's using. By creating standard role-based interfaces and implementing them in multiple classes, the user can take advantage of polymorphism in the tools that publish and retrieve data from SPF. For example, a P&ID pump, a SP3D pump, a PFD pump, an Equipment datasheet pump all "Realize" the "IPump" interface (in addition to whatever other interfaces they realize). Interface polymorphism is a powerful idea for sharing roles between tools that have slightly different ideas about the objects that they share.

Reasons for using Interfaces The reasons for using interfaces for data exchange are:

• The separation of “signature” from “implementation”

• Polymorphism - interfaces being associated with roles that are fulfilled by classes

• Interfaces satisfying roles associated with relationships

• Interfaces are contracts that classes agree to support

• Flexibility of modeling that results from having classes implement interfaces - what matters are the interfaces and not the classes

• Interfaces are immutable and can be depended on to not change

70

The Guru makes known: "The concept of abstracting classes and correctly figuring out which roles get which properties (maintaining orthogonal roles) is the heart of creating a correct data model. Before adding new objects to the SmartPlant schema, please be very sure that you clearly understand role-based modeling." (...I Warned You)

71

18. Examples of Class and Interface Models

Figure 26 Class Diagram for MAN

Since interfaces are "abstract", they can be exposed by (“realized by”) any class. For example, the class “Woman” can also realize most of the interfaces that “Man” exposes, with the exceptions of “IHusband” and “IUncle”.

72

Figure 27 Class Diagram for WOMAN

Another Example of an Interface Relationship Model This important concept is being presented again, just for Mark, who is a slow-learner. The rest of you probably already know this stuff, right (so stop snoring already!)?

Example of the RelDef Labeled "Children" In a data model, a "relationship definition" (RelDef) has a name, two roles and two cardinalities. Thinking of the relationship between two interfaces, we have a role for the first interface and a role for the second interface. For example, one important defined relationship between a “Son” and a “Mother” would be named “Children”. The “ISon” and “IMother” interfaces that were realized by the classes “Man” and “Woman” are related. The following Figure shows two interfaces with a relationship between them.

Figure 28 the Mother-Son Relationship

73

As a data modeling concept, please note that the “Children” relationship shown in Figure 28 may actually have its own properties. For example, the date of birth or adoption, and possibly a termination date, too. That means that it (the set of properties that come into existence as the result of a mother having a son) is a first-class object, and, like “Son” and “Mother” objects, gets a unique id (similar to Taxpayer id), etc. The properties that come into existence as a result of a relationship being established are called "link attributes."

Review of RelDef A Relationship Definition (RelDef) consists of two roles, plus two cardinalities, plus an identity, etc. Obviously, the name should describe how the roles play with each other. Examining Figure 28, the UML diagram states:

• An instance of a class that realizes the interface "ISon", e.g., "a man named Doug" may form a valid relationship with an instance of a class that realizes the interface "IMother", e.g., "Sally", and that relationship between them is called "Children", i.e., Doug is Sally's child and Sally is Doug's mother.

• A "Son" and a "Mother" may have many different kinds of relationships besides "Children", however with respect to the "Children" relationship, the role that "ISon" plays with "IMother" is named "Sons", while the role that the "IMother" plays with "ISon" is named "Mother"

• With respect to the maximum cardinalities in the diagram: o An instance of a "Son" may form a valid relationship with one

instance of "Mother". Read the cardinality on the side "opposite" side of "Children" to figure this out.

o An instance of a "Mother" may form a valid relationship with many instances of "Son". Read the cardinality on the side "opposite" side of "Children" to figure this out..

• With respect to the minimum cardinalities in the diagram: o In this example, it is safe to model the minimum cardinality on

both sides as "0", but it could be argued (and it is shown) that "1" should be the minimum for the “Mother” role, otherwise a "Children" relationship does not exist (since there can’t be a “Son” without a “Mother”, by definition, QED).

74

19. The SmartPlant "Meta Schema" From the last chapter, you saw modeling elements like:

- InterfaceDef - define an interface - ClassDef - define a class - PropertyDef - define a property - EnumListType - enumerated list of values - EnumEnum - enumerated value - UoMListType - unit of measure list of values - RelDef - define a relationship - etc.

By now, you're thinking "this is all too confusing! How is a data modeler supposed to keep track of all of these "things" that comprise the SmartPlant data model"? Well, a good data modeler would model the model elements!! The description of how all the model elements interact with each other is contained in a "model of the model", also called a "meta schema." That's a powerful idea for organizing data model elements. The Guru conveys: "The meta schema is a set of schema objects that describe the objects in the SmartPlant schema. It defines the language in which the SmartPlant schema is written."

Technical Description of the SmartPlant Meta Schema The meta schema classes do not directly describe the data that is part of the schema, the SmartPlant schema describes that. Instead, these classes describe the classes in the schema. The meta schema defines the rules of the schema and is the code behind the schema. For example, all classes in the schema are instances of the ClassDef class in the meta schema. Similarly, all relationship definitions in the schema are of class RelDef, which is part of the meta schema.

75

So, dear reader, welcome to my world: the meta schema also describes itself! All classes in the meta schema are also of the class ClassDef, which is defined as part of the meta schema.

Relationships between Schema Elements Try to get a handle on this idea: the SmartPlant meta schema defines how, e.g., a ClassDef and an InterfaceDef are allowed to interact. Specifically:

- A ClassDef MUST Realize 1 or more InterfaceDefs - A ClassDef MUST Realize Exactly 1 InterfaceDef named "IObject" - A ClassDef MUST HAVE a Model definition - A ClassDef MUST belong to 1 Component schema - A ClassDef MUST HAVE 1 "Class factory" definition - A ClassDef MUST HAVE 1 Primary Interface definition - The ClassDef Name must be EQUAL TO it's UID - A ClassDef MAY HAVE a description - A ClassDef MAY HAVE a Display name - A ClassDef may have 0 OR MORE Shared object definitions - etc.

These are the "Rules of the Road" for a ClassDef. The schema component actually enforces those rules. If you use the SmartPlant Schema Editor, it won't let you mess up a ClassDef, because it knows what one "behaves" like.

Informal Rules Besides the formal rules, there are informal rules, such as how a ClassDef is named, etc. Many of these rules are considered "best practices." No great harm will result if you name an InterfaceDef "TESTING123", but it will confuse someone later on, who is used to the idea that InterfaceDef names begin with the letter "I". Another informal rule is: don't add things to a "closed" enumerated list. You might be able to, but you should not. That's because the schema file and the data files will not be "backwards compatible." Think about this case: someone adds "PINK" to the enumerated list of {YES;NO}. What does the retrieving software do to handle that? I don't know either.

76

The SmartPlant Schema Editor It is time to introduce (drum-roll, please) the SmartPlant Schema Editor. It is a software tool that keeps track of the internal (meta-) structures, and lets a knowledgeable user create or change schema elements. If you're this far into this document, it makes sense for you to download the latest copy of the SmartPlant Schema Editor, and take a look at the meta schema. Just open up the Editor and do a View/Metaschema/OK. On the left side of the screen, you can hit the "+" right next to ClassDef, and you will start to see some of the many internal structures that the editor deals with.

More Powerful than a Speeding Bullet? No - but the SmartPlant Schema Editor is more powerful than Rational Rose, which it replaced for this application about 5 years ago. The Editor has specific, hard-coded logic and rules that keep you from making lots of mistakes. But you can still make some. However, it does have a back-end "validate" feature which will catch 99.9% of the errors that you can make. Intergraph PPM has educational courses that are designed to teach you how to create and modify the SmartPlant schema for your site, and I recommend that you take that course when you get a chance.

77

20. SmartPlant schema Files The SmartPlant schema consists of data modeling elements (classes, relationships, etc.) which are modeled in Unified Modeling Language (UML), based on a meta schema (and its rules) and instantiated in an "XML" file, called the SmartPlant schema file. The SmartPlant schema file may also contain graphical elements (schema diagrams) that can be laid-out in visually pleasing ways so that the data modeling elements are presented in an optimal fashion.

Figure 29 Types of SmartPlant schema Files

The software tool that manipulates the schema file is called the SmartPlant Schema Editor, and is available through normal Intergraph distribution channels. The Editor uses Microsoft COM components (.dll files) that are called SmartPlant schema Components.

78

Component Schemas (CompSchema) The SmartPlant schema file contains all the class definitions (ClassDefs) for all the participating tool users. Each ClassDef is associated to a "Component Schema", which is a way of grouping classes that are used within a specified domain or application area. Component Schemas break up the SmartPlant schema into manageable chunks that correspond almost one-to-one to a document type being published. At a minimum, there is a component schema defined for each tool that publishes into SPF. Here is an example of the class definitions (ClassDefs) that the SPP&ID program can publish.

79

Figure 30 Classes That Are in the P&ID Component

80

A Shared Pipeline Do you have a concept of a "Pipeline"? So does SPP&ID, and PDS and SP3D. Let's see how they use the idea of sharing so that they are all talking about the "same" Pipeline.

Figure 31 A Shared Pipeline Figure 31 (best in color) shows that ClassDefs PIDPipeline, PDSPipeline, and P3DPipelineSystem all think about Pipelines in a very similar manner, and many of the "roles" of pipelines are shared between these tools. However, please note the bottom 9 roles that P3DPipelineSystem yields up to the universe. They are unique to SP3D. The other tools don't have a clue about, e.g., ISystemChild, etc. Also notice that some roles are not shared at all, and some are shared by 2 or 3 classes. The properties that are exposed by

81

the shared roles can be modified by any of the tools that publish those classes.

Existing Component Schemas The SmartPlant Schema Editor has the capability of creating individual component schemas, based on the class definition's association to a component schema object. Currently there are 16 Component schemas:

• ControlSystemComponent – Control system component • DimensionalDatasheetComponent - Dimensional Datasheet component • DocVersioningComponent - Document Versioning component • ELEComponent – SmartPlant Electrical component • EQLComponent – Equipment list component • EquipDataSheet - Equipment Datasheet component • GenericDocument - Base set of document classes • IMLComponent – Instrument Master List component • InstrumentIndexComponent - Instrument Index • P3DComponent - SmartPlant 3D Diagram • PBSComponent - Plant Breakdown Structure component • PDSComponent – PDS component • PFDComponent - Process Flow Diagram • PIDComponent - Piping & Instrumentation Diagram • ProcessDataComponent – Process data component • WBSComponent - Work Breakdown Structure Component

That is way simpler than it sounds. All of the ClassDefs for, e.g., the SP3D tool are bound together to a parent object called "P3DComponent.". When SP3D "publishes" a document, it can only publish objects that are defined by ClassDefs that are contained in the "P3DComponent" group. Which means that the schema for a tool can be much smaller than the entire SmartPlant schema (which is really pretty big).

Technical Description of Component Schemas Press here to skip this. Component schemas contain the following:

- The set of class definitions (ClassDef) that have a componentization relationship with the component schema

- The interface definitions (InterfaceDef) that are Realized by those class definitions

82

- The property definitions (PropertyDef) that are Exposed by those interface definitions

- The property types that are ScopedBy those property definitions The component schemas are full of examples of shared objects that appear in more than one component schema. Virtually all of the schema data defined in a component schema may be shared by one or more other component schemas. The unique identity of an object is defined by its unique identifier (UID), and does not depend in any way on its classification. Therefore, an object can be classified differently by different components and still be one shared object in SPF. For example, if an object in one component schema is classified as a Cableway, and the same object with the same UID is classified as Pipe, by another component schema, then the shared object in SPF contains the information associated with the union of classes Cableway and Pipe.

83

21. XML Files Overview XML, or Extensible Markup Language, is an International Standard, or specification, that is used for storing structured data in an easy, transparent manner. Traditional databases were stored in some kind of proprietary, binary format that was highly optimized by the particular database vendor. That made it very hard to translate it to another format (which is what the database vendors wanted), and makes it impossible to view the underlying data in any meaningful way, without the vendor-supplied GUI and other tools. Now-a-days, most applications that intend to talk to other applications use XML, because it is easy to view, easy to understand, easy to implement, and still retains as much structure as necessary to make sender and receiver comfortable. By the way, it is easy to define the structure of an XML file with a schema! That's a real powerful idea for sharing structured data!

SPF Documents are in XML Format All documents that are published into SPF or retrieved from SPF are in XML format. These XML files (see example) must conform to the structure defined by the SmartPlant schema. When we say "publish" and "retrieve", we mean that a software tool, e.g., SmartPlant P&ID gathers up "appropriate" objects (pumps, motors, valves, etc.), and uses an "adapter" to create an XML data file, under control of the SmartPlant schema, and then submits the file to SPF for storage. Each "publish" operation includes at least data and metadata containers, and may also contain some "instructions", e.g., "tombstones" in a container of their own.

SmartPlant schema Helps Organize XML Files The SmartPlant schema defines what the publishing and retrieving applications (tools) can expect the XML file to look like. For example, a tool publishes a property that contains the enumerated value "RED", and the retrieving tool can be developed so that it knows that it must only react to the set of {RED; YELLOW; GREEN}. The publishing and retrieving tools have a "contract", and can behave in a well-ordered manner. The XML files that are published and retrieved are in a well-known format to everybody - it's not just an XML file, it's an XML file that has widely-understood meaning.

84

NOTE: it is perfectly valid to create an XML file that does not have a schema, or even a data dictionary. And, because of the structured nature of XML files, the retrieving application "can" deduce some meaning from a completely naked XML file that is keyed-into the simplest text input program on the planet. The Guru divulges: "The point where the SmartPlant schema and XML intersect is a "contract", and is agreed to, and widely publicized, and is, therefore a "standard" way of dealing with conforming documents." Retrievers can count on it to be stable. Publishers can count on it to be stable. New tools "know" how to share ideas about pumps, valves, and gasoline. Just publishing an XML file that contains the word "pump" is really not enough to get the job done. A schema makes sure that the XML structure is "standard". Of course you should understand by now that besides the documents that get published and retrieved, the SmartPlant schema itself is also an XML file! When we find a powerful idea like XML, we try to use it as much as possible.

85

22. Patterns Let's start by looking at simple patterns in the SmartPlant schema, and then work our way towards the real richness of the SmartPlant data model.

Example of a Real-World Model Let's look at how the relationships between graphics and data generated by an application are captured into the SmartPlant schema.

Review of Class, Interface, Property and Relation For review: the building blocks of the SmartPlant schema are classes, interfaces, and relationships:

- Classes typically represent real-world objects like instruments, equipment or pipe runs. Classes are defined by ClassDefs.

- Interfaces are used to tightly bind "roles". Interfaces are defined by InterfaceDefs.

- Relationships represent the association between two objects. Relationships are defined by RelDefs.

In SmartPlant schema jargon, ClassDefs "realize" InterfaceDefs. For example, a Vessel class (we're talking about a "process vessel", e.g., one that would be used in a chemical process plant that refines petrochemicals) definition Realizes the interface definition named "IVessel" (by convention, interfaces names begin with the letter "I"). The "IVessel" interface "exposes" properties, such as RatedVolume. Interfaces are related to other interfaces by definable relationships. Referring to Figure 34, for example, the "INozzle" interface is related to the "IEquipment" interface by the relationship named "EquipmentNozzle". Hierarchy is shown on the SmartPlant schema as "Implies Relationships" or also referred to in documentation as "implied" interfaces. Look at Figure 34, the "INozzle" interface Implies the "IEquipmentComponent" interface, in other words, a nozzle is an equipment component. "INozzle" also Implies the "IPipingPortComposition" interface, in other words, a nozzle is a collection of zero or more piping ports.

86

With respect to a software tool "publishing" some data into SPF: publishing a class would cause an object to be output to the document, and publishing a relationship also causes an object to be output (see sample XML file).

SmartPlant schema Complexity Breakdown The SmartPlant schema contains complex information that is not easily discernable to the inexperienced reader (that's pretty much of an understatement). To show some of the richness contained within the SmartPlant schema, a progression from a real world drawing to the SmartPlant schema is made. Figure 32 shows a simple P&ID drawing consisting of a vessel/nozzle/pipe run. Figure 33 transforms Figure 32 to an Object Diagram conforming to the SmartPlant schema. Finally, Figure 34 displays an excerpt from the SmartPlant schema that shows all pertinent interfaces and relationships for the vessel/nozzle/pipe run. To show what is actually published, a sample XML file that the SmartPlant P&ID application would produce for the vessel/nozzle/pipe run example is provided.

Vessel/Nozzle/Pipe run Drawing Figure 32 is a drawing from SmartPlant P&ID, depicts a simple vessel (V-101), that has a nozzle (N1) and is connected to a pipe run (F-217101-XS).

Figure 32 Vessel/Nozzle/Pipe run from P&ID Drawing

An Object Diagram The Object Diagram shown in Figure 33, below, is the transformation of the internal SmartPlant P&ID data model into a format that conforms with the SmartPlant schema. From the Object Diagram, a total of seven objects will be published: four class objects and three relationships.

87

Figure 33 An Object Diagram of Vessel/Nozzle/Pipe run

The blocks on the Object Diagram are the class objects, the "lollipops" are the interfaces, and the solid lines are the relationships. Not all interfaces are shown for the class objects. Notice that the nozzle does not directly connect to the pipe run, instead, a new object "PipingPort" is created, since that is what connects to a pipe run in the SmartPlant schema, as shown below.

Excerpt from the SmartPlant schema

Figure 34 Vessel/Nozzle/Pipe run in SmartPlant schema

Figure 34 shows all directly related interfaces, relationships, and implies relationships for the vessel/nozzle/pipe run drawing. The interfaces and relationships are depicted in the SmartPlant schema. The relationship type, both role and cardinality, is defined. When examining the

88

SmartPlant schema, it is important to note that classes are not shown. The reader must have sufficient familiarity to infer that the Vessel Class will realize the "IProcessVessel" interface.

Sample XML file A total of seven objects will be published: four objects and three relationships. <EQDProcessVessel> <IObject UID=”123” Name=”V-101”/> <IProcessVesselOcc .../> <IProcessVessel VolumeRating=”250”…/> <IEquipmentOcc … /> <IEquipment ... /> </EQDProcessVessel> <EQDNozzle> <IObject UID=”234” Name=”N1”/> <INozzleOcc .../> <INozzle NozzleType="??" /> <IEquipmentComponentOcc … /> <IEquipmentComponent .../> </EQDNozzle> <EQDPipingConnector> <IUID UID=”678” Name=””/> <IPipingConnector …/> <IConnector EstimatedLength="15.0 ft" .../> </EQDPipingConnector > <EQDPipingPort> <IUID UID=”345”/> </EQDPipingPort> <Rel> <IUID UID=”Relationship_123_234”/> <IRel UID1=”123” UID2=”234” DefUID=”EquipmentPartComposition” </Rel> <Rel> <IUID UID=”Relationship_234_456”/> <IRel UID1=”234” UID2=”456” DefUID=”PipingPortComposition” </Rel> <Rel> <IUID UID=”Relationship_234_678”/> <IRel UID1=”234” UID2=”678” DefUID=”PipingEnd1Conn” </Rel>

The simplified "sample" from the SmartPlant schema contains all the information needed to capture graphical objects, relationships between the objects, the hierarchy, and the data (properties) associated with those objects.

89

"Part" vs. "Occurrence" One important pattern is how a "part" is different from an "occurrence", and it is not a simple one. It comes from the underlying architectural model, and it will take a little while to understand. See Figure 65 for a basic idea of how the UML should look. "Occurrence"

If a P&ID diagram shows valve "V-101" in a pipeline, it is there for a reason: the designer has fulfilled a "design intent to control fluid-flow with the valve identified as "V-101". (NOTE: you will learn more about the concept of design intent, called "facility model", in a later chapter). Therefore, when we talk about an "occurrence of a valve" (it's also called a "tagged item", or a "functionally significant item"), we mean, literally, that when the design activity is done, it is the designer's intention that there will really "be" a valve that will be purchased from a vendor, and installed in a pipeline somewhere, and it will be linked back to valve "V-101" on the P&ID. The Guru points out: "An occurrence of an item almost always shows up on a P&ID diagram as a 'tagged item', gets purchased, and then, installed somewhere, e.g., in a process plant." "Part"

Think about some valves. You're probably visualizing: - Valve

o Linear Valves Globe valve

• Globe valve, reduced port • Globe valve, rotary

o Hose valve o 3-way valve o Control valve o etc.

In general, there are some "valve-type-ness ideas that come to mind about all valves, meaning: "within the class 'valve', what type of valve is it"? Earlier, we talked about classification of objects, and how it deals with

90

breaking down big classifications into smaller and smaller groups of similar things. Thinking about Animals: you're probably visualizing, e.g.:

- Animals o Mammals

Dogs • Poodle • German shepherd

Cats • Siamese • Tabby

Elephants o Reptiles

Crocodile Snake etc.

The class "Animals" contains the classes {Mammals; Reptiles}, each of which contains closely-related classes, etc. Can you see why we call it a "class type hierarchy"? Why It's Called 'Part'

Common properties about type-ness are grouped together and yield up a "part" role to the universe (via the "IPart" interface). So why did the committee of very bright thinkers call it "part" instead of "type hierarchy"? It is an especially relevant question since many folks think of "part" as "an engine has, i.e., 'is made up of', parts called pistons". But in the underlying POSC Caesar model, (which was the basis for the SmartPlant schema), it is called "part", meaning "catalog part". What they meant to convey was that a catalog of, e.g., valves is typically broken down by "types". Typical Material

Calling a "type hierarchy" a "part" turns out to be a bad move from another point of view, viz., "catalog" items are called "typical material" in the POSC Caesar model. We, more or less, think that "typical" means "type-ness".

91

That kind of ambiguity causes great confusion (at least among data modelers), and I think that somebody should get spanked and go to bed without dinner! The Guru grunts: "For now, please memorize that 'Part' means 'type hierarchy' and 'typical material' means 'catalog'." Don't Need No Stinkin' Parts

There really doesn't need to be a "part" role for everything in your life, but it may save you some design time, when you consider the number of valves that are in a process plant, or animals in the animal kingdom. Think of this: In the document that SmartPlant P&ID will publish, almost certainly, there's going to be "an occurrence of a valve", i.e., a "tagged" item, and in addition there may be valves that are called parts, which describe characteristics of valves, in general, but do not show up on the P&ID diagram. There can also be valves in a catalog (typical valves), and even valves that have a serial number (actual valves). Modeling "Part" vs. "Occurrence"

Thinking of a "valve-as-a-part", what are common characteristics that describe "valve-part-ness", e.g., inlet size, outlet size, inlet/outlet offset, weight, height, type, etc. And thinking of a "valve-as-an-occurrence", what are common characteristics that describe the "valve-occurrence-ness"? Well, for example: mounting angle, height above ground, etc. Understand this: a "valve-as-a-part" can't possibly know how an occurrence of a valve will be mounted, so properties about "parts" and "occurrences" are different. Now, let's look at a data model of "part" and "occurrence."

92

Figure 35 Pattern for "Part" and "Occurrence"

What properties and relationships would you expect to appear on an occurrence of a valve "IReliefValveOcc" vs. common characteristics of all valves (valve-as-a-part) "IReliefValve"? IValve (part-ness) IValveOcc (occurrence-ness) ============== ====================== - Opening speed (inherit from IValve if possible) - Number of nozzles (inherit from IValve if possible) - Material of construction (inherit from IValve if possible) - Valve type (inherit from IValve if possible) - Bolting requirements (inherit from IValve if possible) - Mounting angle (can't inherit) - Installation instructions (can't inherit) - Weight A Different Weight ??? Looking at Figure 35: for sure we're going to realize the role of "an occurrence of a valve" ("IReliefValveOcc"), since it will finally, really exist as a "tagged" item on a P&ID drawing (otherwise, what are we doing?). There is an optional <<Implies>> that says "maybe there are common characteristics of all valves, that we'll find on the role "Valve". We also see that "mounting angle" is only on the "occurrence" of a valve, since that property can't possibly be a common property of a "valve-as-a-part" or a "typical" valve. Similarly, "Installation instructions" are truly "occurrence" properties, since we can't "install" the "valve-as-a-part", we can only install the "valve-as-an-occurrence".

93

Now, why is "Weight" listed twice in the table above? Because even though some catalog entry says that the valve weighs 300 pounds, this "occurrence" of a valve might weigh 302 pounds. We may want to remember the original "design" parameter of "300", and the "adjusted" value of 302 pounds. How do we do that? The problem of data ambiguity raises its ugly head! There are suddenly two different meanings of "Weight":

- the weight of a typical valve - the weight of an occurrence of a valve

The Blame Game

Obviously, we should blame the data modeler! Not so fast there, son. The property "weight" must have a strong semantic meaning to someone. In this case, it has strong semantic meaning to two different people. The data model does not properly capture the two different meanings. Let's think of the excuses the data modeler could use:

- A second user came along and thought that "weight" meant "actual weight"

- The first user did not specify that he meant "design" weight - The data modeler didn't ask enough questions, e.g., he is not enough of

a "domain expert" to know that there are different meanings to the word "weight"

How do we fix the problem? First, we call a meeting. No, really. We have to sort out the "semantic meaning" of the ambiguous term. After the meeting, we may find that there are other meanings to "weight":

- actual weight - water weight - test weight - fluid-filled weight

And now, the data modeler can take one of several actions:

- Add new properties to the model - Add new interfaces to the model (are there new roles?)

94

- Publish the agreed meaning of "weight" - Publish the new "weight" attributes and their new meanings.

What about the data that the customer was publishing that may be incorrect? For that, we have schema evolution rules, and data transformation. Actual Material

You'll also need to understand that the "actual" valve, i.e., the one with S/N CV-123-OHN-24B, can have a weight that is different from weight of the valve-as-part, and different from weight of the valve-as-occurrence. In order to understand the different phases in the life of a valve, and gain a better insight into what "Planned material", and "Actual material" are, be sure to read the exciting Chapter 23. Let's try to understand why the data modeler decides to expose properties on something-as-a-part vs. something-as-an-occurrence. That should help settle down the part of your brain, that is still wondering "what is a part, and what is an occurrence?" Part Roles & Properties

Look at Figure 36, below. It shows properties that are on an "equipment-as-a-part", viz., "IEquipment".

Figure 36 Properties of an Equipment-as-a-Part Thinking of "equipment-as-a-part", what properties should be there? In other words, what is the Zen of an "equipment-as-a-part"? Certainly, "type-ness" should be there. The other couple of properties wind up there, because it is the result of data normalization.

95

Implied Part Roles

Because of 5NF data normalization, some of the properties are exposed by other roles, which are implied by "IEquipment". Look at the first table in Appendix I; you can see that there are an additional 10 roles that an "equipment-as-a-part" yields up to the universe (along with all those properties):

Role Catalog Electrical Equipment Identification Insulation & Tracing Material Management MRO Process & Environmental Conditions

Safety Surface Treatment & Coatings Weight & COG

Occurrence Roles & Properties

Look at Figure 37, below. It shows properties that are on an "equipment-as-an-occurrence", viz., "IEquipmentOcc".

Figure 37 Properties of Equipment-as-an-Occurrence Why is there only 1 property, and why is it "that" property? Good question! Thinking about what roles "an occurrence of a piece of equipment" might yield up to the universe: we're thinking of a horizontal tank here, help me out a little, it might be "sloped" so that liquid would always run out of one end and not stay inside and corrode the tank. Could we put the role of being a "sloped item" on "equipment-as-a-part"? Nope - "sloped-ness" is not about "type-ness", nor "identification", hey, look up at the table of Role's just above. Is "sloped items" somehow in that list? Can you see why not? The answer is "because sloping items (items that have a measurable slope) can only occur at the item level, not at the item-definition level." The equipment "occurrence" is an item (a tagged item), not the definition of an item (which

96

is a "part"); therefore "IEquipmentOcc" can realize that it is "sloped", but "IEquipment" can not. Implied Occurrence Roles

Because of 5NF data normalization, some of the properties are exposed by other roles, which are implied by "IEquipmentOcc". Look at the second table in Appendix I. You can see that there are an additional 8 roles that an "equipment-as-an-occurrence" yields up to the universe (along with all those properties):

Role Dimensional & Geometrical Equipment Identification Manufacturing, Fabrication, Construction

Miscellaneous Process & Environmental Conditions Startup Treatment State & Status Testing

Be alert! We see "Equipment" as a role, which means that an "occurrence" of something might realize that it is a "part", too. Let's ask ourselves: why is the "Testing" role on "equipment-as-an-occurrence" and not "equipment-as-a-part" - easy, you can test a valve, but you can't test the definition of a valve.

97

RelDef Patterns There are two common relationship patterns that you will encounter in the SmartPlant schema, viz., composition and collection.

Composition relationships Composition relationships are used to model very strong ideas about how parents and children are related. More specifically, a composition describes what happens to the child, if the parent is deleted. In a composition relationship, we would say "if the parent is deleted, the children are deleted." Let's make that clear with an example: If you have a process vessel with several nozzles on it, what happens if the designer deletes the vessel from the P&ID? Right - the nozzles can't be left hanging in space, so they are deleted (by delete propagation rules). Now, this brings up a REAL BIG PROBLEM. Let's say that vessel V-101 on the P&ID just got deleted, but vessel V-101 and its nozzles are modeled on a SP3D drawing (remember "shared objects"?). What the heck happens now? Can one tool delete something, and make it go away from another tool? The Guru laughs: "But of course!" That's part of what makes SPF a complete solution to collaborative engineering. I don't want to give away all the secrets of "delete propagation" here, but suffice it to say that when the vessel was deleted from the P&ID, it published a document that contained a special structure called a "tombstone" for the vessel and its nozzles. Tools like SP3D are able to retrieve that document and act on the fact that another tool is giving them a "to-do action", e.g., "delete the vessel and its nozzles."

Collection relationships Collection relationships are not quite as strong as composition relationships. They allow for the case that children can exist after their parent has been terminated. Let's see if you understand this example: I'm imagining a cup full of pens. If the cup goes away (the thing that is collecting the pens in one spot), do the pens go away? Nope. Therefore, there are no "delete propagation" rules on collections.

98

Plant Breakdown Structure The Plant Breakdown Structure (PBS) is a hierarchy of, e.g., the real, physical things that are required to build, e.g., a process plant. The default PBS is a hierarchy of Plant, Functional Area, Functional Unit. Not everyone agrees on that particular hierarchy, so it can be "customized" by the development team during SPF installation process. Actually, the PBS hierarchy is created by SPF and published by it, and finally, retrieved by the various tools in a PBS Document.

Work Breakdown Structure The Work Breakdown Structure (WBS) is a hierarchy of the assembly instructions for the plant. A WBS doesn't include "real-world" objects -- it is more like a "project plan." The default WBS is Plant, Project, Contract. After the plant is built, the WBS disappears (but the PBS still exists). WBS hierarchy is created by SPF and published by it, and finally, retrieved by the various tools in a WBS Document. Actually there are several WBS documents published by SPF:

- The "ProjectList" document is published by an administrator - It is also automatically published whenever the project state is

changed - There is one project list published for each plant in the "as-built"

configuration. This contains the Plant object and all Projects created within that plant.

- Some tools, e.g., SmartPlant 3D create projects in batch mode, so they retrieve the "ProjectList" document and get all the projects at once

- "Contract" is a document that is created by SPF document management system. Files may be attached, revised, etc.

Naming Conventions The following naming conventions are used in the schema:

- Interface definitions are prefixed with “I”. For example, "IPump" is an interface definition that expresses the role of a “pump”.

- Many class definitions are prefixed with information about the component schema that they are associated with. For example,

99

"EQDStrainer" has a Componentization relationship with the EquipDataSheet component schema.

- Properties may be prefixed with the name of the interface definition that exposes them. For example, Instrument_FluidType is exposed by "IInstrument". This is called denormalization of an attribute.

- Relationship definitions are named according to their pattern, such as collection or composition. For example, "PBSItemCollection" is a collection, and "PipingPortComposition" is a composition.

- Primary interface definitions for concrete objects generally end in "Occ," which is the “occurrence of an object”. For example, the primary interface definition for "PIDInstrument" is "IInstrumentOcc". For more information about occurrences, follow this link.

100

23. SmartPlant Architectural Model The Underlying "Architectural Model" In the beginning (of the SmartPlant schema), it was decided that the data model should be able to serve as an overall model, e.g., for a process plant, from the conceptual phase through construction, handover, operation, and finally to the decommissioning and dismantlement phase. For that reason, the SmartPlant schema is based on some concepts from POSC Caesar. In fact, here is what they have to say:

"Information concerning engineering, construction and operation of production facilities is created, used and modified by many different organisations throughout a facility's lifetime. Economic, safety and environmental considerations demand that this information is available to owners and operators of production facilities, contractors, and regulatory bodies in a consistent, integrated form. This requirement can be satisfied by specifications that prescribe the structure and meaning of data that is shared by organisations and disciplines involved in all stages of a facility's life-cycle."

In general, the SmartPlant schema has a concept of "early-stage design", which is encompassed by a "facility model." Picture something like "let's think about a facility for producing gasoline." You're not talking about a particular vessel and its piping system quite yet; the idea is still more of a conceptual design.

Here is the "Facility model" Simulated --> Predicted --> Required --> Planned --> Actual Facility Facility Facility Facility Facility The "facility model" evolves into things that get purchased (or fabricated), called a "material model". Let's say we look at the output of the simulator and see that we need to increase the fluid pressure between one vessel and another. That means that we need a facility to do that pressure increase. One possible way to increase pressure in a fluid line is to use a pump, so the facility might evolve into a pump. However, another way to increase pressure in a fluid line is by gravity, so the facility might evolve into a height requirement for one vessel vs. another. The "facility" isn't really something

101

that you can put your hand on; it just evolves into something that fulfills its requirements.

Here is the "Material model" Typical --> Required --> Planned --> Actual Material Material Material Material Now, "material" is something that we plan to purchase or fabricate, or more generally speaking, something that was refined from the "facility" model, and will be used in a real application. "Planned material" is material that you "plan to purchase", in order to fulfill some requirement(s) of a "facility" model. Another common term for "planned material" is "a tagged item." On a P&ID, it might have tag number "V-101."

Facility and Material Models Here's Designer Don saying "I need to buy a valve to fulfill the need that this "V-101" on the P&ID created." He looks up the valve in a catalog (which contains "typical" valves), and picks the proper one, based on design characteristics that are required for the facility that needs a valve to control it. He picks a valve, sends a message to Joan, in the Purchasing Department, who rolls it into the order of 40 similar valves from U.S. Valve Company (she probably uses MARIAN). When the batch of valves arrives, the serial numbers of individual valves are matched to the Planned material valves, and begin their life, controlling the flow of fluid through a pipe line. Now we have a database reference that says that V-101 has serial number "USV-1023-8-200." And since it is now "actual material", it will have a testing cycle, and a maintenance history, all its own!

Facility and Material Model Summary Summary: somewhere on a simulation diagram (maybe an early process flow diagram), a "facility" for controlling fluid flow was defined, and a "material item" was drawn on a P&ID. Later it was purchased from a manufacturer, and we can finally install, test, maintain, and use the valve for a long time. We also can remember all of these relationships and properties for the next time that we're building a similar plant. That's a powerful idea for design reuse!

102

24. Schema "Evolution" The SmartPlant schema is not complete. In fact it may never be complete, because defining all the things that can be defined with it is a mighty large set of things. There are some things that you can do to extend the schema, and some things that you must not do. There is a separately-published and highly-technical document "SmartPlant schema Evolution" that states the rules of schema "evolution." It would not be wise to reproduce all that stuff here. Here are some ideas to think about:

- If a "conforming" change is made, e.g., a new, optional PropertyDef is added, what will happen?

- If a "non-conforming" change is made, e.g., a "mandatory" InterfaceDef is added, what will happen?

- If a customer extends his schema, how will a new schema from Intergraph PPM get re-synchronized with it?

- Do schema files and data files have to be forward- and backward-compatible in order to be useful?

103

25. Schema Reading Practice I say: It's easy to read UML diagrams because they are very precise, and there are only a few symbols used. The Guru blurts out: "Easy to Do is Easy to Say". So with that in mind, let's spend a few minutes reading some UML diagrams so that he quiets down a little bit.

UML Reading Practice for ClassDefs Let's look at the Figure 64 in Appendix H, to see a "fan" on an equipment datasheet. That diagram is what you'll actually see if you let the SmartPlant Schema Editor create the UML diagram. Now, let's see if a picture is truly worth 1,000 words:

It is a "Shared object" (meaning that other tools can publish their idea of a fan and it will be merged into this idea of a fan within SPF) in the "Planned material" model (meaning that we plan to purchase a fan).

It is in the "Equipment Data Sheet" Component Schema (meaning that it is probably published by a tool that publishes a bunch of other "EQD"-type classes.

It has a Primary interface named "IFanOcc" (an occurrence of a fan, i.e., a tagged item).

104

It Realizes 46 roles: Category Interface Behavior IDifferentialTemperatureItem Behavior IRotatingItem Catalog IPart Dimensional & Geometrical IOrientedItem Equipment IEquipment Equipment IEquipmentOcc Equipment IFan Equipment IFanOcc Equipment IFluidTransferMachine Equipment IFluidTransferMachineOcc Equipment IGasTransferMachine Equipment IGasTransferMachineOcc Equipment IMaterialTransferEquipment Equipment IMaterialTransferEquipmentOcc Equipment IMechanicalEquipment Equipment IProcessEquipment Equipment IProcessEquipmentOcc Identification INamedEquipment Identification IObject Identification IPBSItem Identification IPBSItemCollection Insulation & Tracing IInsulatedItem Manufacturing, Fabrication, Construction IInstalledItem Manufacturing, Fabrication, Construction IManufacturedItem Manufacturing, Fabrication, Construction IRequisitionedItem Manufacturing, Fabrication, Construction ISuppliedItem Material Management IPlannedMatl Material Management ISpecifiedMatlItem Miscellaneous IDesignedItem Miscellaneous INonDrawingItem Miscellaneous IPartOcc Process & Environmental Conditions IAltDgnPoint Process & Environmental Conditions IDesignPoint Process & Environmental Conditions IFacilityPoint Process & Environmental Conditions INormalDgnPoint Process & Environmental Conditions IPressureDropItem Process & Environmental Conditions IPressureRatedObject Process & Environmental Conditions IProcessDataCaseComposition Process & Environmental Conditions IProcessPointCollection Process & Environmental Conditions IProcessWettedItem Startup Treatment ICleanedItem Surface Treatment & Coatings ICoatedItem Testing ITestedItem

105

Category Interface Weight & COG ICOGItem Weight & COG ISolidItem Weight & COG IWeightItem

Those roles expose 209 properties, which are scoped by 73 types, which include 22 different unit of measure lists, and 46 enumerated lists: Property Type AltDesignPressMax PressureUoM AltDesignPressMin PressureUoM AltDesignTempMax TemperatureUoM AltDesignTempMin TemperatureUoM AngularVelocity AngularVelocityUoM AsynchronousSpeed AngularVelocityUoM AvgInsulDens DensityUoM CatalogName string CatalogPartNumber string CleaningResponsibility CleaningResponsibilities CleaningRqmt CleaningRqmts CoatingColor CoatingColors CoatingRequirement CoatingReq1 CoatingType CoatingReq2 ConstructionStatus ConstructionStati ConstructionStatus2 ConstructStati2 CorrosionAllowance LengthUoM Description string Design_FluidState FluidPhases Design_MassFlowRate MassFlowUoM Design_MetalTemperature TemperatureUoM Design_Pressure PressureUoM Design_Pressure2 PressureUoM Design_ShortTermDuration TimeUoM Design_ShortTermPressure PressureUoM Design_ShortTermTemperature TemperatureUoM Design_SpecificGravityMassBasis double Design_SteamOutPressure PressureUoM Design_SteamOutRequired boolean Design_SteamOutTemperature TemperatureUoM Design_Temperature TemperatureUoM Design_Temperature2 TemperatureUoM Design_VacuumPressure PressureUoM Design_VacuumTemperature TemperatureUoM Design_VaporPressure PressureUoM Design_VentingTemperature TemperatureUoM Design_Viscosity AbsoluteViscosityUoM DesignApprovalRequired boolean

106

Property Type DesignCriteriaFluidState FluidPhases DesignCriteriaMassFlowRate MassFlowUoM DesignCriteriaMetalTemperature TemperatureUoM DesignCriteriaPower PowerUoM DesignCriteriaPressure PressureUoM DesignCriteriaPressure2 PressureUoM DesignCriteriaShortTermDuration TimeUoM DesignCriteriaShortTermPressure PressureUoM DesignCriteriaShortTermTemperature TemperatureUoM DesignCriteriaSpecificGravityMassBasis double DesignCriteriaSpeed AngularVelocityUoM DesignCriteriaSteamOutPressure PressureUoM DesignCriteriaSteamOutRequirement boolean DesignCriteriaSteamOutTemperature TemperatureUoM DesignCriteriaTemperature TemperatureUoM DesignCriteriaTemperature2 TemperatureUoM DesignCriteriaVacuumPressure PressureUoM DesignCriteriaVacuumTemperature TemperatureUoM DesignCriteriaVapourPressure PressureUoM DesignCriteriaVentingTemperature TemperatureUoM DesignCriteriaViscosity AbsoluteViscosityUoM DesignResponsibility DesignResponsibilities DesignWeight MassUoM DifferentialTemperature DiffTempUoM Dry_Installed_Weight MassUoM Dry_Stripped_Weight MassUoM ElectricalEquipmentDesignType ElectricEquipmentDesignTypes EqType0 EqTypes0 EqType1 EqTypes1 EqType2 EqTypes2 EqType3 EqTypes3 EqType4 EqTypes4 EqType5 EqTypes5 EqType6 EqTypes6 EqTypeDescription string EquipmentTrimSpec string EquipPrefix string EquipSeqNo string EquipSuff string ExteriorSurfaceTreatment ExteriorSurfaceTreatments FluidServiceCategory FluidServiceCategories FluidServiceCategory2 FluidServiceCategories2 FluidTransferMachine_Capacity VolumetricFlowUoM FluidTransferMachine_DifferentialPressure DiffPressUoM FluidTransferMachine_RatedPower PowerUoM FrictionalPressureDrop DiffPressUoM

107

Property Type Global_Design_CoG_X LengthUoM Global_Design_CoG_Y LengthUoM Global_Design_CoG_Z LengthUoM Global_Dry_Installed_CoG_X LengthUoM Global_Dry_Installed_CoG_Y LengthUoM Global_Dry_Installed_CoG_Z LengthUoM Global_Dry_Stripped_CoG_X LengthUoM Global_Dry_Stripped_CoG_Y LengthUoM Global_Dry_Stripped_CoG_Z LengthUoM Global_Test_CoG_X LengthUoM Global_Test_CoG_Y LengthUoM Global_Test_CoG_Z LengthUoM Global_Wet_Operating_CoG_X LengthUoM Global_Wet_Operating_CoG_Y LengthUoM Global_Wet_Operating_CoG_Z LengthUoM HeightRelativeToGrade LengthUoM HyperlinkToVendor string InstallationResponsibility InstallationResponsibilities InsulatedItem_OperatingTemperature TemperatureUoM InsulationSurfaceArea AreaUoM InsulationWeight MassUoM InsulCompositeMatl InsulCompositeMaterials InsulPurpose1 InsulPurposes1 InsulPurpose2 InsulPurposes2 InsulPurpose3 InsulPurposes3 InsulSpec string InsulTemp TemperatureUoM InsulThickSrc InsulThickSrcs InteriorSurfaceTreatment InteriorSurfaceTreatments Local_Design_CoG_X LengthUoM Local_Design_CoG_Y LengthUoM Local_Design_CoG_Z LengthUoM Local_Dry_Installed_CoG_X LengthUoM Local_Dry_Installed_CoG_Y LengthUoM Local_Dry_Installed_CoG_Z LengthUoM Local_Dry_Stripped_CoG_X LengthUoM Local_Dry_Stripped_CoG_Y LengthUoM Local_Dry_Stripped_CoG_Z LengthUoM Local_Test_CoG_X LengthUoM Local_Test_CoG_Y LengthUoM Local_Test_CoG_Z LengthUoM Local_Wet_Operating_CoG_X LengthUoM Local_Wet_Operating_CoG_Y LengthUoM Local_Wet_Operating_CoG_Z LengthUoM LocalizedShortMaterialDescription string LongMaterialDescription string

108

Property Type Manufacturer ManufacturerIndustryPractice2 ManufacturerIndustryPractice ManufacturerIndustryPractices ManufacturerModelNumber ManufacturerModels ManufacturerName ManufacturerNames Material_DampingCoefficient double Material_Density DensityUoM Material_ElasticModulus ElasticModulusUoM Material_Emissivity double Material_MaxCompression double Material_MaxShear double Material_MaxTension double Material_PoissonRatio double Material_ShearModulus PressureUoM Material_SpecificHeat SpecificHeatCapacityUoM Material_ThermalConductivity ThermalConductivityUoM Material_ThermalExpansionCoefficient double Material_UltimateStress StressUoM Material_YieldStress StressUoM MaterialsCategory MaterialsGradePractice2 MaterialsGrade MaterialsGradePractice3 MaterialsGradePractice MaterialsGradePractices MaximumAngularVelocity AngularVelocityUoM MaximumPressureDrop DiffPressUoM MechanicalEquipment_DistanceBetweenInOut LengthUoM MechanicalEquipment_OperatingTimePerTime TimePerTimeUoM MechanicalEquipment_OperationMode MechanicalEquipmentOperatingModes MinimumPressureDrop DiffPressUoM MomentumPressureDrop DiffPressUoM Name string128 NormDesignPressMax PressureUoM NormDesignPressMin PressureUoM NormDesignTempMax TemperatureUoM NormDesignTempMin TemperatureUoM NumberOfNozzlesRequired int NumberOfPoles int OrientationMatrix_x0 double OrientationMatrix_x1 double OrientationMatrix_x2 double OrientationMatrix_y0 double OrientationMatrix_y1 double OrientationMatrix_y2 double OrientationMatrix_z0 double OrientationMatrix_z1 double OrientationMatrix_z2 double PlannedOrientation PlannedOrientations PressureDrop DiffPressUoM

109

Property Type PressureDrop_Dirty DiffPressUoM PressureDropLimit DiffPressUoM PressureDropPercent PercentageUoM PressureRating PressureRatings PressureRating2 PressureRatings2 ProcessEquipment_ApplicableStandard ProcessEquipmentApplicableStandards ProcessEquipment_MountingIsPlanned boolean ProcessEquipment_PlannedOperatingFactor PercentageUoM RequisitionResponsibility RequisitionResponsibilities RequisitionType RequisitionTypes RotationDirection RotationViewsFromDriveEnd ShortMaterialDescription string SlopedEquipment_Angle AngleUoM StaticPressureDrop DiffPressUoM SupplyResponsibility SupplyResponsibilities SurfaceArea AreaUoM SynchronousSpeed AngularVelocityUoM TemperatureRating TemperatureUoM TestingMaxPressure PressureUoM TestingMaxTemp TemperatureUoM TestingMinPressure PressureUoM TestingMinTemp TemperatureUoM TestingPercentage double

TestingRequirements {E7B4AB1A-CE33-4021-909C-EAF0F8334C09}

TestingResponsibility TestingResponsibilities TestingType TestingType2 TestWeight MassUoM TotalInsulThick LengthUoM UID string128 Vendor string VendorPartNumber string VolumetricCapacity VolumeUoM Wet_Operating_Weight MassUoM

It can participate in up to 25 different relationships: Relationship Name ControlEquipment DistribConnAccessoryParts EquipDataSheet_DatasheetItems EquipEquip EquipmentComponentCompositionEquipmentComponents EquipmentNozzle EquipmentOcc_EquipmentOcc

110

Relationship Name MatlExpansion NonDrawingItemCollection OwnsImpliedItems P3DSystemHierarchy Part_PartOcc PBSItemCollection PBSItemFacilityPoint PBSItemHasImpliedParts PBSItemNotes PBSWBS PlannedMatlActualization PlannedMatlConstruction PlannedMatlProcurement ProcessDataCaseComposition ProcessEquipInstrument ProcessPointCollection SignalPorts

UML Reading Practice for InterfaceDefs Let's look at Figures 65 through 73 in Appendix H, to see how the data model of an "agitator":

- Figure 65 shows a basic UML diagram of equipment, viz., an agitator, and how it optionally might expose the "part" role of an agitator, too. This is your basic "part / occurrence" pattern.

- Figure 66 shows two things: o First, the model will develop a "left-" and "right-side" idea

Left-side will be "part" stuff (type hierarchy ideas) Right-side will be "occurrence" stuff

o With respect to "part", it says: "an Agitator is a type of Mixing Equipment"

- Figure 67 continues to develop the "type-ness" of the agitator - it says: "Mixing equipment" is a type of "Process equipment"

- Figure 68 starts working on the "occurrence" side of the model. It says that "an occurrence of an agitator must be an occurrence of mixing equipment". It also shows that "mixing equipment" has an optional role of being a "rotating item" ("IRotatingItem"), which means that an agitator might be a rotating item.

- Figure 69 says that "an occurrence of mixing equipment" might be a type of process equipment (an occurrence).

111

- Figure 70 says something important, viz., "occurrences of mixing equipment are 'planned material'". See the "required" implies between "IMixingEquipmentOcc" and "IPlannedMatl"? That means that the agitator object that will be published will be, for sure, "mixing equipment" and "planned material"

- Figure 71 adds the "equipment" role to the diagram (on the "part" side of the model). Now you see that "process equipment" must be a type of "equipment", and that an occurrence of equipment may expose equipment type-ness ("IEquipment").

- Figure 72 shows a more complete story: the left-side is now clearly "part" and the right-side is clearly "occurrence". Furthermore, we can see some of the underlying relationships that might exist between "equipment" and "occurrences of equipment".

- Figure 73 is the same as Figure 72, but puts emphasis on the fact that the left-side, or "part" side, carries the "type-ness" of equipment.

- !!BREAKTIME!!

A Child's Poem Do the Class -> Interface -> Relation -> Property -> Type thing remind you of the child's poem "As I was going to St. Ives"?

As I was going to St. Ives I met a man with seven wives,

Every wife had seven sacks, Every sack had seven cats, Every cat had seven kits:

Kits, cats, sacks and wives, How many were going to St. Ives?

(P.S. I hope you get 1 and not 2,801 as the answer to the riddle!)

112

26. Secrets of the SmartPlant schema Master

Right here I'm going to state that I will NOT reproduce the 6-pound manual entitled "SPF Modeling and Schema Editor, Course Guide", which you get when you take the course through normal channels at Intergraph. So I hereby request that you take some time and Read That Fine Manual (RTFM). However, on a recent trip up the mountain, the Guru started a spiel that goes like this...

Model InterfaceDefs First (Data Normalization) Thinking about how to start eating this SmartPlant schema "elephant": The most important thing is to think about the "roles" that you will be modeling. And as you know from earlier chapters, "roles" are presented to the universe by InterfaceDefs. Here we go... Now, we're thinking about a "pump", and what roles it yields up to the universe:

Figure 38 A 1/2 HP Pump - It is a piece of equipment

113

- It is used to move fluid - We're going to buy some for the new plant - It rotates - It needs a motor to drive it - It has parts inside of a shell - It is a manufactured item - It has weight, and center-of-gravity - etc. to the bazillionth place

Just a simple pump can be horribly complex. By that, we mean that there can be lots of "roles", each of which has many properties and relationships to other roles. The SmartPlant schema helps to control the complexity. Now, look at these properties of a pump for a minute. It only shows a few hundred properties, but real-world pumps can have thousands!

Organizing Lots of Pump Properties Take a deep breath: how would you begin to deal with that kind of complexity? The sheer number of properties on any significant real-world object is very daunting -- by the way, did I mention data normalization?

- Since a pump "is a piece of equipment", we will group all the ideas about it's "equipment-ness" on the "IEquipment" InterfaceDef

- Since "it is used to move fluid", we will group all the ideas about it's ability to move fluid on the "IFluidTransferMachine" InterfaceDef

- Since "we're going to buy some for the new plant", we will group all those ideas on the "IPlannedMatl" InterfaceDef (Planned material = we plan to purchase it)

- Since "it rotates", we will group all the ideas about its rotating-ness on the "IRotatingItem" InterfaceDef.

What's the Spin on Rotating Items?

- How is equipment classified? - How does a fluid transfer machine behave? - How do we purchase one of these puppies? - What does a "rotating item" do for me?

Well, let's pick on one of these things and grind it down to size:

114

- Properties of a "rotating item"

o Angular velocity o Asynchronous speed o Maximum angular velocity o Rotation direction o Synchronous speed

These Properties "belong" on InterfaceDef "IRotatingItem", since every rotating item in the universe has either these exact properties, or such a similar set that we can't tell the difference. In fact if an expert in rotating things comes up to us and says: "yo' - D - you missed out on the fact that rotating things have a "number of poles", you can simply add that as a property to the "IRotatingItem" InterfaceDef. Remember that data normalization stuff, and that 5NF stuff? Here's where the rubber meets the road. You EXPECT that properties about rotating items are on IRotatingItem, and nowhere else! If you are thinking about adding a PropertyDef to an InterfaceDef, you MUST think like this and do it like this! This is the "IRotatingItem" InterfaceDef:

The Results of "Normalizing" a Pump To see how truly useful this concept is, look at the properties of a pump, when they are normalized. Does that seems to be a tad-bit better?

How Interfaces Help to Tame Polymorphism The "IRotatingItem" InterfaceDef is "Realized by" the pump ClassDef, and any other ClassDef that yields up the role of a "rotating item" to the universe. Let's show that simple diagram:

115

Figure 39 Classes that are Polymorphic with respect to IRotatingItem

116

Did I say "simple diagram"!? After looking at Figure 39, I hope you have some appreciation for how difficult it would be to try to model all those classes in some way that made the fact that they all are "rotating items" visible in a useable way. Do you agree that the Linnaean taxonomic model probably fails in this case?

117

Ideas about ClassDefs First, model them last. They're just a collection of InterfaceDefs. After you get to a certain level of competence with the model, you'll be able to look at an Interface model in UML and just "know" what ClassDefs are required.

Naming ClassDefs Start ClassDef names with some identifier that groups them with the software tool that publishes them. For example, objects that will be published by SmartPlant 3D probably should begin with "P3D".

118

Ideas about Enumerated Lists (including EnumListLevelType) It is very common for engineering applications to use large lists for classifying objects. For example, what kinds of "instruments" can appear in a process plant? I don't know. But we can gnaw the problem down to size by approaching the modeling problem with the handy-dandy "hierarchy of instrument types" model. For those of you who were awake, and fully appreciated Figure 39, let me assure you that we're not going to fall into the Linnaean taxonomic model failure situation, for the simple reason that "instrument types" is a monolithic set of entities, and can easily be expressed as a normal hierarchy.

Figure 40 Top-level of Instrument Type Hierarchy The top-level of the instrument hierarchy is easy to understand. Now, let's drill down one-level.

Figure 41 Second-level of Instrument Type Hierarchy

119

Other than the fact that most data modelers don't know what "LG" or "LI" mean, everyone can grasp the concept of a multi-level hierarchy. Where does it all end? All good hierarchies come to an end, and it is usually at a "leaf-node", but that is not a requirement in the SmartPlant schema.

Figure 42 Leaf-nodes in the Instrument Type Hierarchy

Incomplete Hierarchies The SmartPlant schema accommodates tools that don't, or can't think about all those pesky hierarchical levels. If your tool is used for early-stage design, you might not know what type of "whatever" that you will use to fulfill a certain "facility" request, e.g., a facility that requires fluid pressure in a pipeline to increase by 2% might be fulfilled by a pump, or a reducing valve, or gravity, or who-knows? In a similar manner, an equipment datasheet program probably knows in great detail about equipment types, while a simulation program may not even have a clue what a horizontal centrifugal pump is. SPF has the idea that tools don't have to populate values for all the levels of a hierarchy when publishing a document. Each tool just publishes as much as it can, and that's OK. For example, if you don't know about a horizontal centrifugal pump, do you know about centrifugal pump? No - how about pump? No - how about mechanical equipment? No - how about process equipment? Whatever clue you can give to the downstream application, the better.

120

Beating Enumerated Lists into Enumeration Hierarchies Enumerated lists can be combined to form an enumeration hierarchy. All nodes in the hierarchy that are EnumListTypes are enumerated entries for the EnumListType above them. Finally, All EnumListType nodes must contain EnumEnums (enumerated list entries) or other EnumListTypes (enumerated lists.

Cutting Across the Grain with EnumListLevelType How do we omit levels of hierarchy, and yet have a good exchange of data? We'll use "piping components" as an example of a hierarchical list that can be thought of in two different ways. First, here is the "IPipingComponent" InterfaceDef:

Figure 43 "IPipingComponent" InterfaceDef

Notice the properties named: "PipingComponentType1" "PipingComponentType2" "PipingComponentType3"

These 3 properties will be used as a 3-level list that will classify piping components, i.e.,

- The PropertyDef "PipingComponentType1" will contain values that are at Level-1 (the least-detailed) of the hierarchy

- The PropertyDef "PipingComponentType2" will contain values that are at Level-2 of the hierarchy

- The PropertyDef "PipingComponentType3" will contain values that are at Level-3 (the most-detailed) of the hierarchy

121

Scoping with an EnumListLevelType How will we "scope" these properties? - that's a little weird - let's look at the hierarchy of piping component types in Appendix G, then come back here.

Figure 44 Hierarchical Dependence for Piping Component Types Do you see that the value that we're going to put into property 3, i.e., "PipingComponentTypes3" (the 3rd-level of the hierarchy)

- Depends on the value that we put in property 2, i.e., "PipingComponentTypes2" (the 2nd-level of the hierarchy)

o which depends on the value that we put in property 1, i.e., "PipingComponentTypes1".

So how do we "scope" that kind of property? - We "slice" through the hierarchy so that all Level-3 properties "line up" and use that set of values as the scoping for "PipingComponentType3".

122

- Then we slice through the hierarchy so that all Level-2 properties line up, and use that set of values as the scoping for "PipingComponentTypes2". - Finally, "PipingComponentTypes1" is ScopedBy the Level-1 entries, viz., "PipingComponentTypes1". This idea is a little tough, so let's say that a little differently:

- All the Level-3 values, no matter what branch of the hierarchy they appear in, are brought together, named "PipingComponentTypes3", and are the scoping value for "PipingComponentType3".

o All the Level-2 values, no matter what branch they appear in, are brought together, named "PipingComponentTypes2", and are the scoping value for "PipingComponentType2". All the Level-1 values, no matter what branch they appear

in, are brought together, named "PipingComponentTypes1", and are the scoping value for "PipingComponentType1".

123

Figure 45 3 Levels of Scoping

Figure 46 "IPipingComponent"

124

The View from the Top of the Mountain You've been climbing for a long time - have you figured it out yet? What are the important concepts of the SmartPlant schema model? Class

- is "a group of similar things" - is defined by "ClassDef" - Realizes roles (via interfaces)

Object

- is "an instance of a class" - has a unique identifier - is published and retrieved in a "document" to SPF

Interface

- is "a role, used for grouping properties and form relationships with other interfaces" - is defined by "InterfaceDef" - Implies other interfaces and thus inherits their characteristics

Property

- is "a basic or essential attribute shared by all members of a class" - is defined by "PropertyDef" - is ExposedBy Interfaces - is ScopedBy Data Types or Enumerated Lists

Relationship

- is "the rules by which two roles interact" - is defined by "RelDef" - Connects roles (Interfaces) to other roles (Interfaces)

...(more to follow, if and when the Guru is awake)...

125

Appendix A. Rules of Data Normalization Data normalization was formalized by E.F. Codd and there are many good books on the subject. Here is a summary of the 5 levels of normalization. 1NF (1st normal form) - Eliminate Repeating Groups - Make a separate table for each set of related attributes, and give each table a primary key. 2NF (2nd normal form) - Eliminate Redundant Data - If an attribute depends on only part of a multi-valued key, remove it to a separate table. 3NF (3rd normal form) - Eliminate Columns Not Dependent on Key - If attributes do not contribute to a description of the key, remove them to a separate table. 4NF (4th normal form) - Isolate Independent Multiple Relationships - No table may contain two or more 1:n or n:m relationships that are not directly related. 5NF (5th normal form) - Isolate Semantically Related Multiple Relationships - There may be practical constrains on information that justify separating logically related many-to-many relationships.

126

Appendix B. Linnaean Taxonomic Model A technical description of the Linnaean taxonomic model is from Linnaean description: "The practice of classifying organisms into hierarchical groups originated with Aristotle and was codified into nearly immutable biological law by Linnaeus. The heart of taxonomy is the biological species, which forms the foundation for higher levels of classification. Whereas species have long been established among sexual eukaryotes, achieving a meaningful species concept for prokaryotes has been an onerous task and has proven exceedingly difficult for describing viruses and bacteriophages. Moreover, the assembly of viral “species” into higher-order taxonomic groupings has been even more tenuous, since these groupings were based initially on limited numbers of morphological features and more recently on overall genomic similarities. The wealth of nucleotide sequence information that catalyzed a revolution in the taxonomy of free-living organisms necessitates a reevaluation of the concept of viral species, genera, families, and higher levels of classification. Just as microbiologists discarded dubious morphological traits in favor of more accurate molecular yardsticks of evolutionary change, virologists can gain new insight into viral evolution through the rigorous analyses afforded by the molecular phylogenetics of viral genes. For bacteriophages, such dissections of genomic sequences reveal fundamental flaws in the Linnaean paradigm that necessitate a new view of viral evolution, classification, and taxonomy." "Biological taxonomy is rooted in the Linnaean “boxes within boxes” hierarchical paradigm. Here, groups of organisms are defined by their shared characteristics. These groups are subdivided (boxes formed within boxes) based on greater numbers of characters shared within subgroups and on the presence of characters that distinguish between subgroups. This framework is strictly hierarchical; that is, a group at any one taxonomic level can belong to only one parental group (e.g., a species can be a member of only one genus). When devised, the Linnaean paradigm provided an orderly classification of living things, allowing natural historians to place newly found creatures into its hierarchical framework with relative ease, merely by navigating the ever more detailed sets of characteristics that defined groups within groups." The Figure below shows an example of a Linnaean taxonomic model.

127

This website Linnaean taxonomic model presents a reasonable example of the Linnaean taxonomic model. Amphibia (Linnaeus, 1758); Amphibians / Batrachians Caudata (Scopoli, 1777) or Urodela (Latreille, 1825); Caudates Cryptobranchoidea (Fitzinger, 1826); Suborder, ancient or primitive salamanders Cryptobranchidae (Fitzinger, 1826) Giant Salamanders Hynobiidae (Cope, 1859) Asiatic Salamanders Salamandroidea (Fitzinger, 1826); Suborder, advanced salamanders Ambystomatidae (Gray, 1850) Mole Salamanders & Axolotls Amphiumidae (Gray, 1825)Amphiumas Dicamptodontidae (Tihen, 1958) Pacific Giant Salamanders Plethodontidae (Gray, 1850) Lungless Salamanders Proteidae (Gray, 1825) Mudpuppies, Waterdogs, and Olms Rhyacotritonidae (Tihen, 1958) Torrent / Seep Salamanders Salamandridae (Goldfuss, 1820) True Salamanders & Newts Sirenoidea (Goodrich, 1930); Suborder, sirens Sirenidae (Gray, 1825) Sirens

Figure 47 Example of Linnaean taxonomic model

128

Summary Living things are divided into Kingdom, Phylum, Class, Order, Family, Genus and Species

129

Appendix C. Schema Element Definitions

Figure 48 ClassDef

Figure 49 ClassDef Class

130

Figure 50 EnumEnum

Figure 51 EnumEnum Class

131

Figure 52 EnumListType

Figure 53 EnumListType Class

132

Figure 54 InterfaceDef

Figure 55 InterfaceDef Class

133

Figure 56 PropertyDef

Figure 57 PropertyDef Class

134

Figure 58 RelDef

135

Figure 59 RelDef Class

136

Figure 60 UoMEnum

Figure 61 UoMEnum Class

137

Figure 62 UoMListType

Figure 63 UoMListType Class

138

Appendix D. Definitions, Acronyms and Abbreviations Adapter Authoring tool software that facilitates the sharing of data between

itself and SmartPlant Enterprise. Tool adapters generate XML files for publish operations and consume XML when tools retrieve documents

Authoring tools Applications where documents are created and then shared through SmartPlant Enterprise, including Zyqad, SmartPlant P&ID, SmartPlant Electrical, SmartPlant Instrumentation, SmartPlant 3D, and SmartPlant Foundation

Cardinality It means "count", e.g., a cardinality of "1" means that exactly "1" of something should exist.

Class A group of similar things. Classes specify an object's attributes (data elements) and methods (member functions). It generally represents a real-world object, close to the concept of a biological species.

ClassDef A SmartPlant schema element that defines a Class. A specification of the low-level structure and behavior of some set of objects.

Component schema

A subdivision of the complete SmartPlant schema that contains a set of class definitions that are used within a specific domain or application area. There is typically one component schema per published document type.

e.g. for example EDR Engineering Data Repository. It is the underlying SPF database

where all the "things" are stored, shared, and reported on. EdgeDef Single or multiple relationship definitions with direction. In the

schema, an edge definition is used to traverse from a starting object to related objects

SmartPlant schema An XML file that describes the structure of the XML files generated by SmartPlant Enterprise authoring tools in much the same way as a data dictionary describes the structure of a database. As tools publish documents in XML format, those documents must adhere to the format defined by the schema to ensure that the XML data can be loaded into SmartPlant Foundation and retrieved into the other authoring tools

Enumerated list (EnumListType)

A list of possible string property values defined for a property definition in the SmartPlant schema. a.k.a. enumerated sets, pick lists, code lists, and lookups

Enumerated value (EnumEnum)

A member of an enumerated set that defines one possible value for a property in the SmartPlant schema. Enumerated values are sometimes called enumerated entries

GraphDef A connected network of edge definitions with structure. Each graph

139

definition in the SmartPlant schema starts at an interface definition and traverses through one or more relationship definitions to another interface definition at the other end. Graph definitions are sometimes referred to as directed graph definitions

Hierarchy A classified structure with superiors, or roots, and subordinates, or dependents, used for grouping data

Implies The relationship between two interface definitions in the SmartPlant schema. If an interface definition implies another interface definition, then any class definition that realizes the first interface definition can also realize the implied interface definition

Interface The place where two things meet, usually for the purpose of exposing a "role", and may be used to group properties, and to form relationships with other interfaces. An interface is abstract, it is not a class

InterfaceDef An SmartPlant schema element that defines an Interface Linnaean taxonomic model

A scientific way of classifying and naming living things

Mapping A mechanism for software to convert authoring tool data, described by the tool schema, to and from SPF data, described by the SmartPlant schema. See Schema Mapping

Meta schema A set of schema objects that describe the objects in the SmartPlant schema. The meta schema provides the building blocks upon which the SmartPlant schema is built

Object An instance of a class, e.g., 3.14159 is an instance of a floating-point numeric type. An instance of class PumpOcc will be a tagged pump.

Occurrence The fact of something existing, or how much of it exists Ordinality Numerically order something, e.g., first, second, third... Orthogonal Having a set of mutually perpendicular axes; meeting at right

angles. Part A part is a section of a greater whole. If we're talking about, e.g.,

equipment {pumps, vessels, etc.}, then "part-ness" is really the "type hierarchy" that discriminates the different types of equipment.

Plant breakdown structure (PBS)

The composition of the plant based on the grouping of physical objects by their function in the plant. The plant usually occupies the top level of the hierarchy and is typically followed by areas and units

POSC Caesar A European standards body, Petro technical Open Standards Committee that is trying to make ISO 15926 a de facto standard for the process industry, including oil & gas

Primary interface Defines the set of possible roles for a ClassDef, and should imply everything that is known about the ClassDef.

Project A logical unit of data that is a subset of the items that make up a plant. A project is used for making controlled, incremental changes to the data in a plant. There can be multiple projects for a plant at any given time

140

Publish To share a document and its data with other authoring tools by exporting an XML file containing the document data and relationships to SmartPlant Foundation. When a container is published, the software places the XML file in the appropriate SmartPlant Foundation vault and loads the data from the XML file into the SmartPlant Foundation database. After the document is published, users can retrieve the data from the XML file located in the SmartPlant Foundation vault into other authoring tools

Realize The relationship between class definitions and interface definitions in the SmartPlant schema. Class definitions realize interface definitions. The interface definitions that are realized by a class definition expose the properties for that class definition

Relationship An SmartPlant schema element that represents a relationship between two elements

RelDef Associations between interface definitions in the SmartPlant schema. Relationship definitions identify two specific objects that fulfill the roles on each end of the relationship

Retrieve To import document data from an .xml file that was published by another authoring tool for the purpose of maintaining consistency of data across tools. When you retrieve a document, most authoring tools analyze the impact of the newly retrieved data on the existing database and then place tasks on the authoring tool's To Do List that allow you to create, delete, or modify items at the appropriate time in the design process

Schema A diagrammatic representation, an outline, or a model ScopedBy The relationship between “property definitions” and “property

types” in the SmartPlant schema. The scoped by relationship specifies the property type that defines acceptable values, or scopes, a particular property definition. Every property definition in the SmartPlant schema is scoped by one and only one property type. All properties of that property definition must be of that property type.

Schema component

A suite of ActiveX components that provide functionality surrounding the creation, parsing, validation, and comparison of the SmartPlant schema and data. The tool adapters interact with the Schema Component to read the SmartPlant schema, to create data for publish, and to retrieve data

Semantic The dictionary says "the study of meaning", but we mean it to be more like "the rules that are invoked when an action takes place"

Shared object A schema object used to group together similar class definitions that define the same object in different domains. Class definitions that can be shared have a Sharing relationship with shared object definitions in the SmartPlant schema

SI unit International System of Units, sometimes referred to as the metric system. When values for units of measure are published, they are converted to SI units and stored, regardless of the units of measure

141

selected when the user defined the value in the authoring tool SP3D SmartPlant 3D SPEL SmartPlant Electrical SmartPlant Enterprise

A suite of integrated engineering applications delivered together, whose purpose is the total information of a large facility, e.g., process plant, ship, etc.

SmartPlant Foundation (SPF)

The underlying software framework that allows SmartPlant tools to integrate. Provides database, rules, document management, etc.

SmartPlant Integration

SmartPlant integration standardizes and improves the communication among the various SmartPlant Enterprise authoring tools used in the course of designing, constructing, and operating a plant. SmartPlant Integration manages data exchange among these authoring tools, which enables sharing and re-use of plant information throughout the plant lifecycle

Taxonomy Wikipedia says "(from Greek verb tassein = "to classify" and nomos = law, science) may refer to:

- the science of classifying living things - a system of classification in some other field.

Taxonomies are frequently hierarchical in structure. However, taxonomy may also refer to relationship schemes other than hierarchies, such as network structures."

TEF The Engineering Framework; the technology behind SmartPlant integration

Tool schema A set of schema objects that describe the data in the authoring tool databases before it is transformed into the format prescribed by the SmartPlant schema. The tool schema also specifies the mapping between objects in the tool database and the SmartPlant schema

UML Unified Modeling Language, a popular way of visually expressing a schema

ViewDef A named group of properties extracted from the possible properties that a graph definition exposes. View definitions are used to provide a different view of data from that provided by the underlying schema

viz "Namely" or "that is to say" Work breakdown structure (WBS)

The composition of the plant based on the construction work to be completed. The plant usually occupies the top level of the hierarchy; it is typically followed by projects, contracts, and documents

XML Extensible Markup Language; the format for all documents published to SmartPlant Enterprise or retrieved from SmartPlant Enterprise. These XML files must conform to the structure defined by the SmartPlant schema

142

Appendix E. Some Properties of a Pump Prop # Property Type

1 Pump_CoolingWaterPlan eCoolingWaterPlan 2 Pump_SealFlushPipingPlanDescription eSealFlushPipingPlan_API610 3 FluidTransferMachine_DifferentialPressure DiffPressUoM 4 FluidTransferMachine_RatedPower PowerUoM 5 FluidTransferMachine_Capacity VolumetricFlowUoM 6 EqType0 EqTypes0 7 EqType1 EqTypes1 8 EqType2 EqTypes2 9 EqType3 EqTypes3

10 EqType4 EqTypes4 11 EqType5 EqTypes5 12 EqType6 EqTypes6 13 EqTypeDescription string 14 EquipmentTrimSpec string 15 NumberOfNozzlesRequired int 16 SteamJacketPressure PressureUoM 17 Jacket_CleaningRqmt CleaningRqmts 18 Jacket_CleaningResponsibility CleaningResponsibilities 19 Jacket_CoatingRequirement CoatingReq1 20 Jacket_CoatingType CoatingReq2 21 Jacket_ExteriorSurfaceTreatment ExteriorSurfaceTreatments 22 Jacket_InteriorSurfaceTreatment InteriorSurfaceTreatments 23 Jacket_CoatingColor CoatingColors 24 Jacket_CorrosionAllowance LengthUoM 25 Jacket_FlowDirection FlowDirections 26 Jacket_FluidSystem FluidSystems 27 Jacket_AvgInsulDens DensityUoM 28 Jacket_InsulCompositeMatl InsulCompositeMaterials 29 Jacket_InsulPurpose1 InsulPurposes1 30 Jacket_InsulPurpose2 InsulPurposes2 31 Jacket_InsulPurpose3 InsulPurposes3 32 Jacket_InsulSpec string 33 Jacket_InsulTemp TemperatureUoM 34 Jacket_InsulThickSrc InsulThickSrcs 35 Jacket_TotalInsulThick LengthUoM 36 Jacket_OperatingTemperature TemperatureUoM 37 Jacket_InsulationSurfaceArea AreaUoM 38 Jacket_InsulationWeight MassUoM 39 Jacket_ItemTag string 40 Jacket_ItemTagSequenceNumber string 41 Jacket_ItemTagSuffix string 42 Jacket_SteamOutPressure PressureUoM 43 Jacket_SteamoutReq SteamOutReqs

143

Prop # Property Type

44 Jacket_SteamoutTemperature TemperatureUoM 45 Jacket_MaterialOfConstructionClass string 46 Jacket_NominalDiameter LengthUoM 47 Jacket_OperatingFluidCode FluidCodes 48 Jacket_PipingMaterialsClass string 49 Jacket_ScheduleOrThickness ScheduleThicknessPractices 50 Jacket_ScheduleThickness2 ScheduleThicknesses2 51 Jacket_HeatTransferCoefficient CoefficientOfHeatTransferUoM 52 Jacket_HeatTransferArea AreaUoM 53 UID string128 54 Name string128 55 Description string 56 MaterialsCategory MaterialsGradePractice2 57 MaterialsGrade MaterialsGradePractice3 58 MaterialsGradePractice MaterialsGradePractices 59 LongMaterialDescription string 60 ShortMaterialDescription string 61 LocalizedShortMaterialDescription string 62 Material_DampingCoefficient double 63 Material_Density DensityUoM 64 Material_ElasticModulus ElasticModulusUoM 65 Material_Emissivity double 66 Material_MaxCompression double 67 Material_MaxShear double 68 Material_MaxTension double 69 Material_PoissonRatio double 70 Material_ShearModulus PressureUoM 71 Material_SpecificHeat SpecificHeatCapacityUoM 72 Material_ThermalConductivity ThermalConductivityUoM 73 Material_ThermalExpansionCoefficient double 74 Material_UltimateStress StressUoM 75 Material_YieldStress StressUoM 76 SurfaceArea AreaUoM 77 VolumetricCapacity VolumeUoM 78 Dry_Stripped_Weight MassUoM 79 Dry_Installed_Weight MassUoM 80 Wet_Operating_Weight MassUoM 81 DesignWeight MassUoM 82 TestWeight MassUoM 83 Local_Dry_Stripped_CoG_X LengthUoM 84 Local_Dry_Installed_CoG_X LengthUoM 85 Local_Wet_Operating_CoG_X LengthUoM 86 Local_Design_CoG_X LengthUoM 87 Local_Dry_Stripped_CoG_Y LengthUoM 88 Local_Dry_Stripped_CoG_Z LengthUoM 89 Local_Wet_Operating_CoG_Y LengthUoM 90 Local_Wet_Operating_CoG_Z LengthUoM

144

Prop # Property Type

91 Local_Design_CoG_Y LengthUoM 92 Local_Design_CoG_Z LengthUoM 93 Local_Dry_Installed_CoG_Y LengthUoM 94 Local_Dry_Installed_CoG_Z LengthUoM 95 Local_Test_CoG_X LengthUoM 96 Local_Test_CoG_Y LengthUoM 97 Local_Test_CoG_Z LengthUoM 98 Global_Design_CoG_X LengthUoM 99 Global_Design_CoG_Y LengthUoM

100 Global_Design_CoG_Z LengthUoM 101 Global_Dry_Installed_CoG_X LengthUoM 102 Global_Dry_Installed_CoG_Y LengthUoM 103 Global_Dry_Installed_CoG_Z LengthUoM 104 Global_Dry_Stripped_CoG_X LengthUoM 105 Global_Dry_Stripped_CoG_Y LengthUoM 106 Global_Dry_Stripped_CoG_Z LengthUoM 107 Global_Test_CoG_X LengthUoM 108 Global_Test_CoG_Y LengthUoM 109 Global_Test_CoG_Z LengthUoM 110 Global_Wet_Operating_CoG_X LengthUoM 111 Global_Wet_Operating_CoG_Y LengthUoM 112 Global_Wet_Operating_CoG_Z LengthUoM 113 LubricationRequirement string 114 PressureDrop_Dirty DiffPressUoM 115 PressureDrop DiffPressUoM 116 MaximumPressureDrop DiffPressUoM 117 MinimumPressureDrop DiffPressUoM 118 PressureDropLimit DiffPressUoM 119 FrictionalPressureDrop DiffPressUoM 120 MomentumPressureDrop DiffPressUoM 121 PressureDropPercent PercentageUoM 122 StaticPressureDrop DiffPressUoM 123 CorrosionAllowance LengthUoM 124 FluidServiceCategory FluidServiceCategories 125 TemperatureRating TemperatureUoM 126 FluidServiceCategory2 FluidServiceCategories2 127 CoatingRequirement CoatingReq1 128 CoatingType CoatingReq2 129 ExteriorSurfaceTreatment ExteriorSurfaceTreatments 130 InteriorSurfaceTreatment InteriorSurfaceTreatments 131 CoatingColor CoatingColors 132 PaintByManufacturersStandard boolean 133 PaintSpecifications_Exterior boolean 134 PaintSpecifications_Interior boolean 135 PaintSpecifications_SurfacePreparation PaintSurfacePreparations 136 PaintSpecifications_Underside boolean 137 PaintSpecifications_MaterialName PaintMaterialNames

145

Prop # Property Type

138 Paint_ApplicableSpecification PaintApplicableSpecifications 139 PaintSpecifications_Primer PaintPrimers 140 PaintSpecifications_Grouting boolean 141 PaintSpecifications_Epoxy PaintSpecEpoxy 142 PaintSpecifications_FinishCoat PaintSpecFinishCoatings 143 PaintingResponsibility PaintingResponsibilities 144 PressureRating2 PressureRatings2 145 PressureRating PressureRatings 146 Tracing_MaxTemperature TemperatureUoM 147 Tracing_MinTemperature TemperatureUoM 148 HTraceMediumTemp TemperatureUoM 149 HTraceRqmt HTraceRqmts 150 HTraceRqmt2 HTraceRqmts2 151 HTraceRqmt3 HTraceRqmts3 152 AverageActiveLoad PowerUoM 153 ConsumedActiveLoad PowerUoM 154 ConsumedApparentLoad ElectricLoadUoM 155 ConsumedReactiveLoad ReactiveLoadUoM 156 ElecDemandFactor double 157 XCoincidenceFactor double 158 YCoincidenceFactor double 159 ZCoincidenceFactor double 160 ZZCoincidenceFactor double 161 ParticularActiveLoad PowerUoM 162 ParticularApparentLoad ElectricLoadUoM 163 ParticularPower PowerUoM 164 ParticularReactiveLoad ReactiveLoadUoM 165 InsulatedItem_OperatingTemperature TemperatureUoM 166 InsulationSurfaceArea AreaUoM 167 InsulationWeight MassUoM 168 InsulTemp TemperatureUoM 169 InsulThickSrc InsulThickSrcs 170 InsulSpec string 171 InsulCompositeMatl InsulCompositeMaterials 172 AvgInsulDens DensityUoM 173 TotalInsulThick LengthUoM 174 InsulPurpose1 InsulPurposes1 175 InsulPurpose2 InsulPurposes2 176 InsulPurpose3 InsulPurposes3 177 GasGroup GasGroups 178 HazardousAreaClassification EquipmentAreaClassifications 179 HazardousAreaTemperatureClass TemperatureClasses 180 AutomaticIgnitionRequired boolean 181 AutomaticReIgnitionRequired boolean 182 BatteryBackupRequried boolean 183 FlameProofRequired boolean 184 LocalAlarmRequired boolean

146

Prop # Property Type

185 ManualIgnitionRequired boolean 186 PilotFailureDetectionRequired boolean 187 RechargeableRequired boolean 188 RemoteAlarmRequired boolean 189 VoltFreeContactsRequired boolean 190 WeatherProofRequired boolean 191 ExplosionProtection ExplosionProtectionCategories 192 MechanicalEquipment_OperationMode MechanicalEquipmentOperatingModes 193 MechanicalEquipment_DistanceBetweenInOut LengthUoM 194 MechanicalEquipment_OperatingTimePerTime TimePerTimeUoM 195 ProcessEquipment_MountingIsPlanned boolean 196 ProcessEquipment_ApplicableStandard ProcessEquipmentApplicableStandards 197 ProcessEquipment_PlannedOperatingFactor PercentageUoM 198 DifferentialTemperature DiffTempUoM 199 SlopedEquipment_Angle AngleUoM 200 DesignResponsibility DesignResponsibilities 201 DesignApprovalRequired boolean 202 ElectricalEquipmentDesignType ElectricEquipmentDesignTypes 203 Design_Temperature TemperatureUoM 204 Design_Pressure PressureUoM 205 Design_Temperature2 TemperatureUoM 206 Design_Pressure2 PressureUoM 207 Design_VacuumTemperature TemperatureUoM 208 Design_VacuumPressure PressureUoM 209 Design_SteamOutTemperature TemperatureUoM 210 Design_SteamOutPressure PressureUoM 211 Design_SteamOutRequired boolean 212 Design_ShortTermTemperature TemperatureUoM 213 Design_ShortTermPressure PressureUoM 214 Design_ShortTermDuration TimeUoM 215 Design_VentingTemperature TemperatureUoM 216 Design_MetalTemperature TemperatureUoM 217 Design_VaporPressure PressureUoM 218 Design_MassFlowRate MassFlowUoM 219 Design_SpecificGravityMassBasis double 220 Design_Viscosity AbsoluteViscosityUoM 221 Design_FluidState FluidPhases 222 HeightRelativeToGrade LengthUoM 223 ConstructionStatus ConstructionStati 224 ConstructionStatus2 ConstructStati2 225 ExpansionCount int 226 CatalogName string 227 CatalogPartNumber string 228 TestingMaxPressure PressureUoM 229 TestingMaxTemp TemperatureUoM 230 TestingMinPressure PressureUoM 231 TestingMinTemp TemperatureUoM

147

Prop # Property Type

232 TestingResponsibility TestingResponsibilities 233 TestingPercentage double 234 TestingRequirements TestingRequirements 235 TestingType TestingType2 236 CleaningRqmt CleaningRqmts 237 CleaningResponsibility CleaningResponsibilities 238 FabricationType FabricationRequirement2 239 FabricationRequirement FabricationRequirements 240 FabricationResponsibility FabricationResponsibility 241 FabricationTypeBasis FabricationTypeBases 242 FabricatedWeight MassUoM 243 FabricatorName string 244 InstallationResponsibility InstallationResponsibilities 245 ManufacturerIndustryPractice ManufacturerIndustryPractices 246 Manufacturer ManufacturerIndustryPractice2 247 ManufacturerName ManufacturerNames 248 ManufacturerModelNumber ManufacturerModels 249 EquipPrefix string 250 EquipSeqNo string 251 EquipSuff string 252 AltDesignTempMin TemperatureUoM 253 AltDesignTempMax TemperatureUoM 254 AltDesignPressMin PressureUoM 255 AltDesignPressMax PressureUoM 256 DesignCriteriaPressure2 PressureUoM 257 DesignCriteriaTemperature2 TemperatureUoM 258 NormDesignTempMin TemperatureUoM 259 NormDesignTempMax TemperatureUoM 260 NormDesignPressMin PressureUoM 261 NormDesignPressMax PressureUoM 262 DesignCriteriaFluidState FluidPhases 263 DesignCriteriaMassFlowRate MassFlowUoM 264 DesignCriteriaMetalTemperature TemperatureUoM 265 DesignCriteriaPower PowerUoM 266 DesignCriteriaPressure PressureUoM 267 DesignCriteriaShortTermDuration TimeUoM 268 DesignCriteriaShortTermPressure PressureUoM 269 DesignCriteriaShortTermTemperature TemperatureUoM 270 DesignCriteriaSpecificGravityMassBasis double 271 DesignCriteriaSpeed AngularVelocityUoM 272 DesignCriteriaSteamOutPressure PressureUoM 273 DesignCriteriaSteamOutRequirement boolean 274 DesignCriteriaSteamOutTemperature TemperatureUoM 275 DesignCriteriaTemperature TemperatureUoM 276 DesignCriteriaVacuumPressure PressureUoM 277 DesignCriteriaVacuumTemperature TemperatureUoM 278 DesignCriteriaVapourPressure PressureUoM

148

Prop # Property Type

279 DesignCriteriaVentingTemperature TemperatureUoM 280 DesignCriteriaViscosity AbsoluteViscosityUoM 281 RequisitionResponsibility RequisitionResponsibilities 282 RequisitionType RequisitionTypes 283 SteamOutPressure PressureUoM 284 SteamOutTemperature TemperatureUoM 285 SteamoutReq SteamOutReqs 286 WBSItemPurpose WBSItemType2 287 WBSItemType WBSItemTypes 288 MountingOrientation MountingOrientations 289 MountingLocation IndoorsOutdoors 290 Lattitude AngleUoM 291 Longitude AngleUoM 292 LocationX LengthUoM 293 LocationY LengthUoM 294 LocationZ LengthUoM 295 Vendor string 296 VendorPartNumber string 297 HyperlinkToVendor string 298 SupplyResponsibility SupplyResponsibilities 299 HoldRemarks string 300 HoldStatus HoldStatus 301 Hold_Name string 302 Hold_CreatedDate YMD 303 Hold_Number string 304 Hold_ClosedBy string 305 Hold_ClosedDate YMD 306 Hold_CreatedBy string 307 MTO_ReportingRequirements ReportingRequirements 308 MTO_ReportingType ReportingRequirements2 309 SP3D_DateCreated DateTimeUoM 310 SP3D_DateLastModified DateTimeUoM 311 SP3D_UserCreated string 312 SP3D_UserLastModified string 313 SP3D_ApprovalStatus SP3DApprovalStatii 314 SP3D_ApprovalReason SP3DApprovalStatii 315 ProcessPlantEquipment_StressRelieving boolean 316 ProcessPlantEquipment_DischargePressureRated PressureUoM 317 ProcessPlantEquipment_Height LengthUoM 318 PlantItem_MaterialClass string 319 PlannedOrientation PlannedOrientations 320 OrientationMatrix_x0 double 321 OrientationMatrix_x1 double 322 OrientationMatrix_x2 double 323 OrientationMatrix_y0 double 324 OrientationMatrix_y1 double 325 OrientationMatrix_y2 double

149

Prop # Property Type

326 OrientationMatrix_z0 double 327 OrientationMatrix_z1 double 328 OrientationMatrix_z2 double 329 Range1X LengthUoM 330 Range1Y LengthUoM 331 Range1Z LengthUoM 332 Range2X LengthUoM 333 Range2Y LengthUoM 334 Range2Z LengthUoM 335 ConstructionType ConstructionRequirement2 336 ConstructionRequirement ConstructionRequirements 337 MaximumAngularVelocity AngularVelocityUoM 338 AngularVelocity AngularVelocityUoM 339 AsynchronousSpeed AngularVelocityUoM 340 SynchronousSpeed AngularVelocityUoM 341 NumberOfPoles int 342 RotationDirection RotationViewsFromDriveEnd

These are not all the properties of a pump, but it's a good start.

150

Appendix F. Normalized Properties of a Pump Interface Property I3DDrawingItem I3DObject SP3D_DateLastModified I3DObject SP3D_DateCreated I3DObject SP3D_UserCreated I3DObject SP3D_UserLastModified I3DObject SP3D_ApprovalStatus I3DObject SP3D_ApprovalReason I3DRange Range1X I3DRange Range1Y I3DRange Range2Z I3DRange Range2Y I3DRange Range1Z I3DRange Range2X IAltDgnPoint AltDesignPressMax IAltDgnPoint AltDesignTempMax IAltDgnPoint AltDesignPressMin IAltDgnPoint AltDesignTempMin IAltDgnPoint DesignCriteriaTemperature2 IAltDgnPoint DesignCriteriaPressure2 IAssemblyChild ICleanedItem CleaningResponsibility ICleanedItem CleaningRqmt ICoatedItem CoatingRequirement ICoatedItem CoatingType ICoatedItem ExteriorSurfaceTreatment ICoatedItem InteriorSurfaceTreatment ICoatedItem CoatingColor ICOGItem Global_Dry_Installed_CoG_Y ICOGItem Global_Dry_Stripped_CoG_Y ICOGItem Global_Dry_Stripped_CoG_X ICOGItem Local_Test_CoG_Z ICOGItem Local_Test_CoG_Y ICOGItem Global_Wet_Operating_CoG_X ICOGItem Global_Wet_Operating_CoG_Y ICOGItem Global_Wet_Operating_CoG_Z ICOGItem Global_Design_CoG_X ICOGItem Global_Design_CoG_Y ICOGItem Global_Design_CoG_Z ICOGItem Global_Test_CoG_X ICOGItem Local_Test_CoG_X ICOGItem Local_Design_CoG_Z ICOGItem Local_Dry_Stripped_CoG_X ICOGItem Local_Dry_Stripped_CoG_Y ICOGItem Local_Dry_Stripped_CoG_Z ICOGItem Local_Dry_Installed_CoG_X ICOGItem Local_Dry_Installed_CoG_Y ICOGItem Local_Dry_Installed_CoG_Z ICOGItem Local_Wet_Operating_CoG_X ICOGItem Local_Wet_Operating_CoG_Y ICOGItem Local_Wet_Operating_CoG_Z

151

Interface Property ICOGItem Local_Design_CoG_X ICOGItem Global_Dry_Installed_CoG_Z ICOGItem Global_Dry_Installed_CoG_X ICOGItem Global_Dry_Stripped_CoG_Z ICOGItem Global_Test_CoG_Z ICOGItem Global_Test_CoG_Y ICOGItem Local_Design_CoG_Y IConstructedItem ConstructionRequirement IConstructedItem ConstructionType IDesignedItem Design_FluidState IDesignedItem Design_Temperature2 IDesignedItem Design_Pressure2 IDesignedItem Design_VacuumTemperature IDesignedItem Design_VacuumPressure IDesignedItem Design_SteamOutTemperature IDesignedItem Design_Viscosity IDesignedItem Design_SteamOutPressure IDesignedItem Design_Pressure IDesignedItem Design_Temperature IDesignedItem ElectricalEquipmentDesignType IDesignedItem DesignApprovalRequired IDesignedItem DesignResponsibility IDesignedItem Design_SteamOutRequired IDesignedItem Design_SpecificGravityMassBasis IDesignedItem Design_ShortTermTemperature IDesignedItem Design_ShortTermPressure IDesignedItem Design_ShortTermDuration IDesignedItem Design_VentingTemperature IDesignedItem Design_MetalTemperature IDesignedItem Design_VaporPressure IDesignedItem Design_MassFlowRate IDesignPoint IDifferentialTemperatureItem DifferentialTemperature IDistributionPartOcc IDocumentItem IDrawingItem IElecPowerConsumer XCoincidenceFactor IElecPowerConsumer ZZCoincidenceFactor IElecPowerConsumer ParticularActiveLoad IElecPowerConsumer ParticularApparentLoad IElecPowerConsumer ParticularPower IElecPowerConsumer ParticularReactiveLoad IElecPowerConsumer YCoincidenceFactor IElecPowerConsumer ElecDemandFactor IElecPowerConsumer ZCoincidenceFactor IElecPowerConsumer ConsumedReactiveLoad IElecPowerConsumer ConsumedApparentLoad IElecPowerConsumer AverageActiveLoad IElecPowerConsumer ConsumedActiveLoad IEquipment EqType1 IEquipment EqType3 IEquipment EqType2 IEquipment EqType0

152

Interface Property IEquipment NumberOfNozzlesRequired IEquipment EquipmentTrimSpec IEquipment EqTypeDescription IEquipment EqType6 IEquipment EqType5 IEquipment EqType4 IEquipmentFoundationPortComposition IEquipmentOcc SlopedEquipment_Angle IExpandableThing ExpansionCount IExplosionProtected ExplosionProtection IFabricatedItem FabricatorName IFabricatedItem FabricatedWeight IFabricatedItem FabricationResponsibility IFabricatedItem FabricationType IFabricatedItem FabricationRequirement IFabricatedItem FabricationTypeBasis IFacilityPoint IFluidTransferMachine FluidTransferMachine_Capacity IFluidTransferMachine FluidTransferMachine_DifferentialPressure IFluidTransferMachine FluidTransferMachine_RatedPower IFluidTransferMachineOcc IHazardousAreaRated WeatherProofRequired IHazardousAreaRated VoltFreeContactsRequired IHazardousAreaRated RemoteAlarmRequired IHazardousAreaRated RechargeableRequired IHazardousAreaRated PilotFailureDetectionRequired IHazardousAreaRated ManualIgnitionRequired IHazardousAreaRated LocalAlarmRequired IHazardousAreaRated FlameProofRequired IHazardousAreaRated BatteryBackupRequried IHazardousAreaRated AutomaticReIgnitionRequired IHazardousAreaRated AutomaticIgnitionRequired IHazardousAreaRated HazardousAreaTemperatureClass IHazardousAreaRated HazardousAreaClassification IHazardousAreaRated GasGroup IHeatTracedItem Tracing_MinTemperature IHeatTracedItem Tracing_MaxTemperature IHeatTracedItem HTraceRqmt IHeatTracedItem HTraceMediumTemp IHeatTracedItem HTraceRqmt2 IHeatTracedItem HTraceRqmt3 IHeldItem HoldRemarks IHeldItem Hold_CreatedDate IHeldItem Hold_ClosedBy IHeldItem Hold_CreatedBy IHeldItem Hold_ClosedDate IHeldItem HoldStatus IHeldItem Hold_Number IHeldItem Hold_Name IHydrostaticTestedItem IInstalledItem InstallationResponsibility IInsulatedItem InsulationWeight IInsulatedItem InsulatedItem_OperatingTemperature

153

Interface Property IInsulatedItem TotalInsulThick IInsulatedItem AvgInsulDens IInsulatedItem InsulCompositeMatl IInsulatedItem InsulSpec IInsulatedItem InsulationSurfaceArea IInsulatedItem InsulThickSrc IInsulatedItem InsulTemp IInsulatedItem InsulPurpose1 IInsulatedItem InsulPurpose2 IInsulatedItem InsulPurpose3 IJacketedItem Jacket_ExteriorSurfaceTreatment IJacketedItem Jacket_FlowDirection IJacketedItem Jacket_CorrosionAllowance IJacketedItem Jacket_ItemTagSuffix IJacketedItem Jacket_CoatingType IJacketedItem Jacket_ItemTagSequenceNumber IJacketedItem Jacket_CoatingColor IJacketedItem Jacket_SteamOutPressure IJacketedItem Jacket_InteriorSurfaceTreatment IJacketedItem Jacket_CoatingRequirement IJacketedItem Jacket_CleaningResponsibility IJacketedItem Jacket_FluidSystem IJacketedItem Jacket_SteamoutReq IJacketedItem Jacket_SteamoutTemperature IJacketedItem Jacket_MaterialOfConstructionClass IJacketedItem Jacket_NominalDiameter IJacketedItem Jacket_OperatingFluidCode IJacketedItem Jacket_PipingMaterialsClass IJacketedItem Jacket_ScheduleOrThickness IJacketedItem SteamJacketPressure IJacketedItem Jacket_CleaningRqmt IJacketedItem Jacket_AvgInsulDens IJacketedItem Jacket_HeatTransferCoefficient IJacketedItem Jacket_HeatTransferArea IJacketedItem Jacket_ScheduleThickness2 IJacketedItem Jacket_InsulCompositeMatl IJacketedItem Jacket_InsulPurpose1 IJacketedItem Jacket_InsulPurpose2 IJacketedItem Jacket_ItemTag IJacketedItem Jacket_InsulationWeight IJacketedItem Jacket_InsulationSurfaceArea IJacketedItem Jacket_OperatingTemperature IJacketedItem Jacket_TotalInsulThick IJacketedItem Jacket_InsulThickSrc IJacketedItem Jacket_InsulPurpose3 IJacketedItem Jacket_InsulSpec IJacketedItem Jacket_InsulTemp ILocatedItem Lattitude ILocatedItem Longitude ILocatedItem LocationZ ILocatedItem LocationY ILocatedItem LocationX ILubricatedItem LubricationRequirement

154

Interface Property IManufacturedItem ManufacturerIndustryPractice IManufacturedItem ManufacturerModelNumber IManufacturedItem ManufacturerName IManufacturedItem Manufacturer IMaterialItem IMaterialTransferEquipment IMaterialTransferEquipmentOcc IMechanicalEquipment MechanicalEquipment_OperatingTimePerTime IMechanicalEquipment MechanicalEquipment_OperationMode IMechanicalEquipment MechanicalEquipment_DistanceBetweenInOut IMemberSystemParent IMfgParent IMountedItem MountingLocation IMountedItem MountingOrientation IMTOInfo MTO_ReportingType IMTOInfo MTO_ReportingRequirements INamedEquipment EquipSuff INamedEquipment EquipPrefix INamedEquipment EquipSeqNo INonDrawingItem INormalDgnPoint NormDesignPressMax INormalDgnPoint NormDesignPressMin INormalDgnPoint NormDesignTempMax INormalDgnPoint NormDesignTempMin INormalDgnPoint DesignCriteriaViscosity INormalDgnPoint DesignCriteriaFluidState INormalDgnPoint DesignCriteriaMassFlowRate INormalDgnPoint DesignCriteriaMetalTemperature INormalDgnPoint DesignCriteriaVentingTemperature INormalDgnPoint DesignCriteriaVapourPressure INormalDgnPoint DesignCriteriaVacuumTemperature INormalDgnPoint DesignCriteriaVacuumPressure INormalDgnPoint DesignCriteriaTemperature INormalDgnPoint DesignCriteriaSteamOutTemperature INormalDgnPoint DesignCriteriaSteamOutRequirement INormalDgnPoint DesignCriteriaSteamOutPressure INormalDgnPoint DesignCriteriaSpeed INormalDgnPoint DesignCriteriaSpecificGravityMassBasis INormalDgnPoint DesignCriteriaShortTermTemperature INormalDgnPoint DesignCriteriaPower INormalDgnPoint DesignCriteriaPressure INormalDgnPoint DesignCriteriaShortTermPressure INormalDgnPoint DesignCriteriaShortTermDuration INoteCollection IObject UID IObject Name IObject Description IOrientedItem OrientationMatrix_x1 IOrientedItem OrientationMatrix_y2 IOrientedItem OrientationMatrix_z0 IOrientedItem OrientationMatrix_z1 IOrientedItem OrientationMatrix_z2 IOrientedItem PlannedOrientation

155

Interface Property IOrientedItem OrientationMatrix_x0 IOrientedItem OrientationMatrix_y1 IOrientedItem OrientationMatrix_y0 IOrientedItem OrientationMatrix_x2 IPaintedItem PaintingResponsibility IPaintedItem PaintSpecifications_FinishCoat IPaintedItem Paint_ApplicableSpecification IPaintedItem PaintSpecifications_Interior IPaintedItem PaintSpecifications_Exterior IPaintedItem PaintSpecifications_MaterialName IPaintedItem PaintByManufacturersStandard IPaintedItem PaintSpecifications_SurfacePreparation IPaintedItem PaintSpecifications_Primer IPaintedItem PaintSpecifications_Grouting IPaintedItem PaintSpecifications_Underside IPaintedItem PaintSpecifications_Epoxy IPart IPartOcc CatalogPartNumber IPartOcc CatalogName IPBSItem ConstructionStatus IPBSItem HeightRelativeToGrade IPBSItem ConstructionStatus2 IPBSItemCollection IPBSSystem IPBSSystemParent IPlannedMatl IPlantItem PlantItem_MaterialClass IPortComposition IPressureDropItem PressureDrop_Dirty IPressureDropItem PressureDrop IPressureDropItem FrictionalPressureDrop IPressureDropItem MomentumPressureDrop IPressureDropItem PressureDropPercent IPressureDropItem StaticPressureDrop IPressureDropItem MaximumPressureDrop IPressureDropItem MinimumPressureDrop IPressureDropItem PressureDropLimit IPressureRatedObject PressureRating IPressureRatedObject PressureRating2 IProcessDataCaseComposition IProcessEquipment ProcessEquipment_MountingIsPlanned IProcessEquipment ProcessEquipment_PlannedOperatingFactor IProcessEquipment ProcessEquipment_ApplicableStandard IProcessEquipmentOcc IProcessPlantEquipment ProcessPlantEquipment_Height IProcessPlantEquipment ProcessPlantEquipment_DischargePressureRated IProcessPlantEquipment ProcessPlantEquipment_StressRelieving IProcessPointCollection IProcessWettedItem FluidServiceCategory IProcessWettedItem TemperatureRating IProcessWettedItem CorrosionAllowance IProcessWettedItem FluidServiceCategory2 IPump Pump_SealFlushPipingPlanDescription

156

Interface Property IPumpOcc Pump_CoolingWaterPlan IRequisitionedItem RequisitionType IRequisitionedItem RequisitionResponsibility IRotatingItem RotationDirection IRotatingItem SynchronousSpeed IRotatingItem AsynchronousSpeed IRotatingItem AngularVelocity IRotatingItem MaximumAngularVelocity IRotatingItem NumberOfPoles ISolidItem SurfaceArea ISolidItem VolumetricCapacity ISpecifiedMatlItem ShortMaterialDescription ISpecifiedMatlItem Material_ThermalConductivity ISpecifiedMatlItem LongMaterialDescription ISpecifiedMatlItem LocalizedShortMaterialDescription ISpecifiedMatlItem MaterialsGradePractice ISpecifiedMatlItem MaterialsCategory ISpecifiedMatlItem MaterialsGrade ISpecifiedMatlItem Material_DampingCoefficient ISpecifiedMatlItem Material_Density ISpecifiedMatlItem Material_ElasticModulus ISpecifiedMatlItem Material_Emissivity ISpecifiedMatlItem Material_MaxCompression ISpecifiedMatlItem Material_MaxShear ISpecifiedMatlItem Material_MaxTension ISpecifiedMatlItem Material_PoissonRatio ISpecifiedMatlItem Material_ShearModulus ISpecifiedMatlItem Material_SpecificHeat ISpecifiedMatlItem Material_ThermalExpansionCoefficient ISpecifiedMatlItem Material_UltimateStress ISpecifiedMatlItem Material_YieldStress ISteamedItem SteamOutPressure ISteamedItem SteamoutReq ISteamedItem SteamOutTemperature ISuppliedItem HyperlinkToVendor ISuppliedItem VendorPartNumber ISuppliedItem Vendor ISuppliedItem SupplyResponsibility ISystemChild ITestedItem TestingMinTemp ITestedItem TestingMaxTemp ITestedItem TestingResponsibility ITestedItem TestingPercentage ITestedItem TestingRequirements ITestedItem TestingType ITestedItem TestingMinPressure ITestedItem TestingMaxPressure ITypicalMatl IWBSItem WBSItemType IWBSItem WBSItemPurpose IWBSItemCollection IWeightItem Dry_Stripped_Weight IWeightItem TestWeight

157

Interface Property IWeightItem DesignWeight IWeightItem Wet_Operating_Weight IWeightItem Dry_Installed_Weight

Pump properties have been "Normalized"

158

Appendix G. Piping Component Type Hierarchy Level 1 Level 2 Level 3

Bolted joint spacers Spacer ring Jacket spacer Jacket spacers Jacket spacer group Blind assembly Flange isolation kit Isolating sleeve Union nut

Miscellaneous

Vent stack cover GBSET Jack screw Nut

Miscellaneous bolting

Washer Bonnet shield Fitting shield Flange shield Instrument shield Piping specialty shield

Shields

Valve shield Crimp ring Tubing accessories Tube strap

Valve assembly shield Valve and flange shield BSVPK DSVPK Valve packing VPK Chain Extension stem guide

Accessories

Valve-operator accessory Floor stand bracket Double long turn Tee Double Tee Double full-size tees Tee with double offset

Double olet-type branches XLET Tee with double offset, reducing branch Tee with double offset, reducing run and branch Double reducing tees Tee with double offset, reducing runs 45 degree double Y Double wyes YD

Drip ring tees TDR EOLLR Elbolets EPIPET CPLH Endolets FOLHC X Full-size crosses XBA L90YB Full-size laterals LAT Drop Tee Long turn Tee S90YB Supply and return Tee

Branches

Full-size tees

T

159

Level 1 Level 2 Level 3 TBA Tee with offset Test Tee TFI TSPLT TSRV TST TUOB TUOR

TWMSW Full-size, sloped header tees T88 Increasing olet-type branches Expanded pipet Increasing tees TRRR

LOL Latrolets LOLPIPET RPADNR Non-radial branch reinforcement RWELDNR

Non-radial olet-type branches WOLNR BOL COL FLGOL FOL IWOL NOL PIPET SAD SOL SOLSS SWOL TLET TOL TOLSS WOL

Olet-type branches

WOLSS XRB Reducing crosses XRRB L90YRB LRB Reducing laterals LRRB S90YRB Tee with offset, reducing branch Tee with offset, reducing run and branch Tee with offset, reducing runs Tee, heat exchanger Tee, reducing run (baseboard) TRB TRI

Reducing tees

TRRB Reducing true Y Reducing wyes Reducing wye RPAD Reinforcing pads RPAD2

Reinforcing welds RWELD

160

Level 1 Level 2 Level 3 RWELD2

45 degree Y Long turn Y WYE

Wyes

Y 11.25 degree direction change E11 15 degree direction change E15 22.5 degree direction change E22 30 degree direction change E30

E45 E453D E45L E45LR E45LT E45M1 E45M2 E45M3 E45S E45ST

45 degree direction change

E45U E903DT 45-90 degree direction change E90LRT

5.625 degree direction change E5 60 degree direction change E60 88 degree direction change E88

90 degree elbow with inlet 90 degree elbow with side inlet 90 degree elbow with vent 90 degree elbow, close rough 90 degree elbow, drop 90 degree elbow, hanger 90 degree elbow, intermediate radius E90 E903D E90BU E90L E90LR E90LT E90M1 E90M2 E90M3 E90M4 E90M5 E90S E90SR E90ST E90SW E90TC

90 degree direction change

E90U E90R 90 degree reducing direction change E90RST

Double 90 degree direction change 90 degree double elbow

Direction-change fitting

Less than 45 degree direction change E453DT

161

Level 1 Level 2 Level 3 E45LRT

180 degree return with cleanout R180 R180CL R180LR R180MD R180OP R180SR R180UP

Returns

R180UPSO Closure plate, external to jacket Closure plates Closure plate, internal to jacket CAP Cap with drain CLOSSET Fitting cleanout with plug HDHEMI HIFVPLU

Ending fittings

PLUG BALJDE90 BALJE90

End-fitting

Flexible ending fittings BALJST Dry barrel type hydrant FOACH FOAMK FOAT HYD3W HYDIND HYDMNOZ HYDSFR

Fire hydrant

HYDUG Hose reel Hose accessory HRST1 ME1 MELB MFOAM MGUN MN1

Monitors

MREMO Spray sprinkler

Fire and safety

Sprinklers SSP1 Adapter, drop (tubing) Adapter, flush (tubing) Adapter, hose (tubing) Adapter, soil pipe (tubing) Adapter, trap (tubing) Adapter, tubing ADPT01 ADPT02 ADPT03 ADPT04 ADPT05

In-Line Fittings Adapters

ADPT06

162

Level 1 Level 2 Level 3 TLDMADPT

BDISC BLPAD BLSPO FBLD

Blinds

FUBLD BUSH Bushing, external Bushing, flush CPLR INSR1 INSR2 REDC REDCLT

Concentric diameter change

SWGC Concentric diameter increase INCRC

BOSSET CLACB CLAGLOK Clamp, bell-joint Clamp, Grayloc Clamp, SPO-Lock Clamp, Techlok Clamp, Tri-Clamp CLAVBAN CLMP1 CONNP Coupling with drain Coupling with tube stop Coupling, compression Coupling, cross-over Coupling, eccentric Coupling, flanged adapter Coupling, hanger Coupling, repair Coupling, transition Coupling, Victaulic CPL CPL45E CPLBAY CPLCOM CPLFJ CPLFLE CPLM1 CPLTAN CPLVIPS Dresser coupling HC HIFVCPL SLV SWBRTL SWFFQCB

Couplings and connectors

SWFFQCS

163

Level 1 Level 2 Level 3 SWQCPLB SWQCSWOS SWQCSWS Tapping sleeve Tapping sleeve, mechanical joint

WELBFL REDE REDELT Eccentric diameter change SWGE

Expander flanges FEWN CBFERR FERR Ferrules TCFERR BALFL FCP FFIL FLWN FS FSJ FSW FTHD FWN

Flanges

INSFL HIFADPT HIFADPTSPL High integrity flange adapters HIFADPTSTEP HIFLBRING HIFLBRINGSPL High integrity flange load bearing rings HIFLBRINGSTEP DBLHUB GLBLHUB GLHUB HUB SPOLHUB

Hubs

TLHUB BLSPA OPSPA SLSPA

In-line spacers

TBSPA FL Lap joint flanges FSSE BNIP Close nipple INLNIP

Nipples

NIP FOSO FOSW FOTHD

Orifice flanges

FOWN Orifice Plates Orifice plate Orifice spacers ORFSPA Orifice spacers ORSPA

Plate flanges FPL

164

Level 1 Level 2 Level 3 FPLSE

FRFILR FRINS FRS FRSW FRTHD

Reducing flanges

FRWN Reducing Plate flanges FRPL Reducing Slip-on flanges FRSO

FSO Slip-on flanges FSOSE AFCNOZ AIRANOZ FLSPNOZ HFCNOZ HOLCNOZ

Spray nozzles

VLFCNOZ STBNDL Stub ends STBNDS T1SPA Tapered spacers T2SPA UN UND UNHD UNO

Unions

UNTL Detonation flame arrester FAEOLC FAEOLCM FAEOLR FAICMET FAICP Flame arrester with free vent Flame arrester, horizontal Flame arrester, vertical Flame arrestor Flame check, high pressure Flame check, low pressure

Arrestor

Flame trap assembly Blank disc Blind flange Paddle blind

Blinds

Spectacle blind Sample cooler Sample cooler, high pressure Sample cooler, low pressure Sampler, fixed volume liquid Sampler, in-line SLRMOB

Coolers

SLRPNOB Couplings Exhaust heads Exhaust head

Piping specialty

Expansion joint EJCLSH

165

Level 1 Level 2 Level 3 EJEPB EJEXPR EJFAB EJGIM EJINLPB EJRECT EJREFL EJSLTY EJTELS EJTHKW EJTOR EJUNI Expansion joint Expansion joint, double end Expansion joint, single end

Hinged expansion joint Filter Filter, equipment protection Filter, instrument protection

Filter

Filter, multiplex liquid Paddle spacer Ring spacer In-line spacers Solid spacer Air chamber Bulkhead fitting Miscellaneous tubing specialties Venturi insert Specialty 1 Other piping specialties Specialty 2 Drum trap with bottom inlet Drum trap, swivel P-trap P-trap with cleanout P-trap with union joint P-trap, suction line

Other traps

Trap, upturn Gas pulse trap Hammer arrestor Liquid pulse trap Shock trap

Pressure attenuation devices

Surge arrester Acoustic filter Acoustic pulse trap In-line silencer Noise attenuator Vent diffuser

Silencers

Vent silencer Specialty valves Motor operated valve

Automatic differential condensate controller Ball float liquid drainer Ball float steam trap Bellows steam trap Controlled disc steam trap

Steam trap

Fixed temperature discharge trap

166

Level 1 Level 2 Level 3 Float and thermostatic steam trap Float steam trap, free Float trap, angle type Float trap, horizontal Float trap, vertical Impulse steam trap Integral seat disc trap Inverted bucket steam trap Open bucket steam trap Orifice trap Steam trap Steam trap diffuser Thermodynamic steam trap Thermodynamic steam trap, high pressure Thermostatic air vent Thermostatic steam trap Thermostatic steam trap, balanced pressure Thermostatic steam trap, balanced pressure bellows Thermostatic steam trap, balanced pressure wafer Thermostatic steam trap, bimetallic Thermostatic steam trap, liquid expansion Thermostatic steam trap, simple bimetallic

Upright (open top) bucket steam trap Angle block strainer Barrel strainer Basket strainer Cone strainer Core strainer Double basket strainer Duplex basket strainer Flat face perforated strainer Flat perforated strainer Flat plate strainer Inclined perforated strainer Inverted cone strainer Perforated cone strainer Permanent line strainer Sanitary strainer Single basket strainer Sludge shoe Suction strainer or Suction diffuser Sump strainer T strainer Tank suction strainer Tee-type assembly angle pattern strainer Tee-type assembly straight thru pattern strainer Temporary cone strainer Temporary strainer Truncated cone strainer (perforated basket strainer)

Strainer

Y strainer Ejector Injector

Suction tees and ejectors

Mixing tee

167

Level 1 Level 2 Level 3 Mixing tee, high pressure static

Sparger Double elbow swivel joint LOARAFR LOARBL LOARF LOARSCI LOARSLS LOARVRL LOARWA ROTUN Single elbow swivel joint

Swivel joint

Straight-thru swivel joint Free vent with screen Free vent without screen FVENT

Vents

FVENTWE Pressure/vacuum relief manhole cover PSE Press/vac rupture disc P PSV Press/vac relief valve P

Relief device

Temperature fusible plug or disc Distance pieces DISTPC Hose HOSE Jacketed piping, variable length Plain piping with integral core and jacket Piping fixed-length PIPEFX Piping variable-length PIPE

Straight section

Tube TUBE 3-way generic body valve 3-way solenoid valve 3WRV1 BAL3W CK3W CKST3W DIA3W GLO3W PLU3W

3-way valves

SLI3W 3-way valves flow-directional CKAR

4-way generic body valve 4-way solenoid valve 4WRV1 BAL4W CK4W DIA4W

4-way valves

PLU4W BAL5W CK5W DIA5W GENB5W PLU5W

5-way valves

SOL5W GENB6W

Valves

6-way valves PLU6W

168

Level 1 Level 2 Level 3 SOL6W 7-way valves DIA7W

CKAL Angle valve flow-directional CKAST 2-way angle solenoid valve Angle slurry valve, 90 Degree BDA Generic body angle valve GLOA HOSA

Angle valves

TKDR Angle valves, 45 Degree Angle slurry valve, 45 Degree

Lower cross Lower tee Lower tee / upper cross Upper cross / lower cross Upper tee / lower cross Upper tee / lower tee

Control/Throttling valves

Y-body DIA2W Left-hand tangential, reverse acting Right-hand tangential, reverse acting Upper cross, reverse acting

Diverter valves

Upper tee, reverse acting ALA DEL Fire and safety valves DRY 45 degrees 90 degrees 90 degrees, offset down 90 degrees, offset left 90 degrees, offset right Flanged 45 degrees

Kettle valves

Flanged 90 degrees BFYDF BFYDFDE BFYDFL BFYDFS BFYHP BFYLP BFYLUG BFYLUGDE BFYTE BFYWF BFYWFDE BFYWFL BFYWFS BFYWFSFL BFYWFSFS BWV CKBAL CKBP

Linear Flow Directional Valves

CKHL

169

Level 1 Level 2 Level 3 CKLR CKLRY CKPI CKS CKSPS CKSR CKSSP CKST CKTD CKVL CKWF CKYST

FOOT BALF BALFLO BALL Ball valve, temperature blowdown automated BALLP BALR BALSP BDY DIA FLO GAT GATBL GATCON GATEX GATF GATPS GATPSLI GATR GATRASYM GATSLI GATSP GATWE Generic body valve GLO Globe valve, bonnetless inclined GLOR GLOREC GLOROT GLOSP GLOY HOS KNF Multivane 1 damper/louver valve Multivane 2 damper/louver valve NEE PIN PLU PLUPB PLUSP

Linear Valves

PLUVP

170

Level 1 Level 2 Level 3 Single vane damper/louver valve SLI Solenoid valve

Solenoid valve, proportional Multi-port valves 6WRV1 Other instrument valves Valve with restriction orifice

Angle pressure relief valve Balanced automatic pressure relief valve BLOF Conservation vent CONVDIA PCONVPAW Pressure automated valve Pressure control valve Pressure safety valve Pressure/vacuum relief valve PSPILO PSSPRO PVCONVEOL PVCONVFA PVCONVINL PVCONVPAW PVCONVPAWSL PVCONVSL Safety relief valve Straight-through pressure relief valve Tee type relief valve Vacuum relief valve VACVEOL

Pressure valves

VACVSM SAMHO Sampling valves SAMHOIF

Sanitary access valve/fitting assemblies Sanitary access valve/fitting assembly FLBT Free flow reverse current valve Motor operated valve SAFS

Specialty valves

SAFSTAN Tandem valves Tandem valve

10F flanged Clamp cross Clamp inlet Flanged cross Flanged offset left Flanged offset right Tee offset left

Tank outlet valves

Tee offset right

Temperature valves Temperature safety valve

The 3-Level Enumerated List Named "PipingComponentTypes1"

171

Appendix H. Some UML Diagrams

Figures for Chapter 25, "UML Reading Practice for ClassDefs"

Figure 64 UML Diagram of EQDFan

172

Figures for Chapter 25, "UML Reading Practice for InterfaceDefs"

Figure 65 Interface Diagram 1 - Agitator Part & Occurrence Model

Figure 66 Interface Diagram 2

Figure 67 Interface Diagram 3

173

Figure 68 Interface Diagram 4

Figure 69 Interface Diagram 5

174

Figure 70 Interface Diagram 6

Figure 71 Interface Diagram 7

175

Figure 72 Interface Diagram 8

176

Figure 73 Interface Diagram 9

x

177

x

178

Appendix I. Equipment Property Spreadsheets This is a summary of the roles and properties that are exposed by "IEquipment". Category Interface Property Catalog IPart Catalog ITypicalMatl Electrical IElecPowerConsumer AverageActiveLoad Electrical IElecPowerConsumer ConsumedActiveLoad Electrical IElecPowerConsumer ConsumedApparentLoad Electrical IElecPowerConsumer ConsumedReactiveLoad Electrical IElecPowerConsumer ElecDemandFactor Electrical IElecPowerConsumer ParticularActiveLoad Electrical IElecPowerConsumer ParticularApparentLoad Electrical IElecPowerConsumer ParticularPower Electrical IElecPowerConsumer ParticularReactiveLoad Electrical IElecPowerConsumer XCoincidenceFactor Electrical IElecPowerConsumer YCoincidenceFactor Electrical IElecPowerConsumer ZCoincidenceFactor Electrical IElecPowerConsumer ZZCoincidenceFactor Equipment IEquipment EqType0 Equipment IEquipment EqType1 Equipment IEquipment EqType2 Equipment IEquipment EqType3 Equipment IEquipment EqType4 Equipment IEquipment EqType5 Equipment IEquipment EqType6 Equipment IEquipment EqTypeDescription Equipment IEquipment EquipmentTrimSpec Equipment IEquipment NumberOfNozzlesRequired Equipment IMechanicalEquipment MechanicalEquipment_DistanceBetweenInOut Equipment IMechanicalEquipment MechanicalEquipment_OperatingTimePerTime Equipment IMechanicalEquipment MechanicalEquipment_OperationMode Identification IObject Description Identification IObject Name Identification IObject UID Insulation & Tracing IHeatTracedItem HTraceMediumTemp Insulation & Tracing IHeatTracedItem HTraceRqmt Insulation & Tracing IHeatTracedItem HTraceRqmt2 Insulation & Tracing IHeatTracedItem HTraceRqmt3 Insulation & Tracing IHeatTracedItem Tracing_MaxTemperature Insulation & Tracing IHeatTracedItem Tracing_MinTemperature Insulation & Tracing IInsulatedItem AvgInsulDens Insulation & Tracing IInsulatedItem InsulatedItem_OperatingTemperature

179

Category Interface Property Insulation & Tracing IInsulatedItem InsulationSurfaceArea Insulation & Tracing IInsulatedItem InsulationWeight Insulation & Tracing IInsulatedItem InsulCompositeMatl Insulation & Tracing IInsulatedItem InsulPurpose1 Insulation & Tracing IInsulatedItem InsulPurpose2 Insulation & Tracing IInsulatedItem InsulPurpose3 Insulation & Tracing IInsulatedItem InsulSpec Insulation & Tracing IInsulatedItem InsulTemp Insulation & Tracing IInsulatedItem InsulThickSrc Insulation & Tracing IInsulatedItem TotalInsulThick Insulation & Tracing IJacketedItem Jacket_AvgInsulDens Insulation & Tracing IJacketedItem Jacket_CleaningResponsibility Insulation & Tracing IJacketedItem Jacket_CleaningRqmt Insulation & Tracing IJacketedItem Jacket_CoatingColor Insulation & Tracing IJacketedItem Jacket_CoatingRequirement Insulation & Tracing IJacketedItem Jacket_CoatingType Insulation & Tracing IJacketedItem Jacket_CorrosionAllowance Insulation & Tracing IJacketedItem Jacket_ExteriorSurfaceTreatment Insulation & Tracing IJacketedItem Jacket_FlowDirection Insulation & Tracing IJacketedItem Jacket_FluidSystem Insulation & Tracing IJacketedItem Jacket_HeatTransferArea Insulation & Tracing IJacketedItem Jacket_HeatTransferCoefficient Insulation & Tracing IJacketedItem Jacket_InsulationSurfaceArea Insulation & Tracing IJacketedItem Jacket_InsulationWeight Insulation & Tracing IJacketedItem Jacket_InsulCompositeMatl Insulation & Tracing IJacketedItem Jacket_InsulPurpose1 Insulation & Tracing IJacketedItem Jacket_InsulPurpose2 Insulation & Tracing IJacketedItem Jacket_InsulPurpose3 Insulation & Tracing IJacketedItem Jacket_InsulSpec Insulation & Tracing IJacketedItem Jacket_InsulTemp Insulation & Tracing IJacketedItem Jacket_InsulThickSrc Insulation & Tracing IJacketedItem Jacket_InteriorSurfaceTreatment Insulation & Tracing IJacketedItem Jacket_ItemTag Insulation & Tracing IJacketedItem Jacket_ItemTagSequenceNumber Insulation & Tracing IJacketedItem Jacket_ItemTagSuffix Insulation & Tracing IJacketedItem Jacket_MaterialOfConstructionClass Insulation & Tracing IJacketedItem Jacket_NominalDiameter Insulation & Tracing IJacketedItem Jacket_OperatingFluidCode Insulation & Tracing IJacketedItem Jacket_OperatingTemperature Insulation & Tracing IJacketedItem Jacket_PipingMaterialsClass Insulation & Tracing IJacketedItem Jacket_ScheduleOrThickness Insulation & Tracing IJacketedItem Jacket_ScheduleThickness2 Insulation & Tracing IJacketedItem Jacket_SteamOutPressure Insulation & Tracing IJacketedItem Jacket_SteamoutReq Insulation & Tracing IJacketedItem Jacket_SteamoutTemperature Insulation & Tracing IJacketedItem Jacket_TotalInsulThick Insulation & Tracing IJacketedItem SteamJacketPressure Material Management ISpecifiedMatlItem LocalizedShortMaterialDescription Material Management ISpecifiedMatlItem LongMaterialDescription Material Management ISpecifiedMatlItem Material_DampingCoefficient

180

Category Interface Property Material Management ISpecifiedMatlItem Material_Density Material Management ISpecifiedMatlItem Material_ElasticModulus Material Management ISpecifiedMatlItem Material_Emissivity Material Management ISpecifiedMatlItem Material_MaxCompression Material Management ISpecifiedMatlItem Material_MaxShear Material Management ISpecifiedMatlItem Material_MaxTension Material Management ISpecifiedMatlItem Material_PoissonRatio Material Management ISpecifiedMatlItem Material_ShearModulus Material Management ISpecifiedMatlItem Material_SpecificHeat Material Management ISpecifiedMatlItem Material_ThermalConductivity Material Management ISpecifiedMatlItem Material_ThermalExpansionCoefficient Material Management ISpecifiedMatlItem Material_UltimateStress Material Management ISpecifiedMatlItem Material_YieldStress Material Management ISpecifiedMatlItem MaterialsCategory Material Management ISpecifiedMatlItem MaterialsGrade Material Management ISpecifiedMatlItem MaterialsGradePractice Material Management ISpecifiedMatlItem ShortMaterialDescription MRO ILubricatedItem LubricationRequirement Process & Environmental Conditions IPressureDropItem FrictionalPressureDrop Process & Environmental Conditions IPressureDropItem MaximumPressureDrop Process & Environmental Conditions IPressureDropItem MinimumPressureDrop Process & Environmental Conditions IPressureDropItem MomentumPressureDrop Process & Environmental Conditions IPressureDropItem PressureDrop Process & Environmental Conditions IPressureDropItem PressureDrop_Dirty Process & Environmental Conditions IPressureDropItem PressureDropLimit Process & Environmental Conditions IPressureDropItem PressureDropPercent Process & Environmental Conditions IPressureDropItem StaticPressureDrop Process & Environmental Conditions IPressureRatedObject PressureRating Process & Environmental Conditions IPressureRatedObject PressureRating2 Process & Environmental Conditions IProcessWettedItem CorrosionAllowance Process & Environmental Conditions IProcessWettedItem FluidServiceCategory Process & Environmental Conditions IProcessWettedItem FluidServiceCategory2 Process & Environmental Conditions IProcessWettedItem TemperatureRating Safety IExplosionProtected ExplosionProtection Safety IHazardousAreaRated AutomaticIgnitionRequired Safety IHazardousAreaRated AutomaticReIgnitionRequired Safety IHazardousAreaRated BatteryBackupRequried Safety IHazardousAreaRated FlameProofRequired Safety IHazardousAreaRated GasGroup Safety IHazardousAreaRated HazardousAreaClassification Safety IHazardousAreaRated HazardousAreaTemperatureClass Safety IHazardousAreaRated LocalAlarmRequired

181

Category Interface Property Safety IHazardousAreaRated ManualIgnitionRequired Safety IHazardousAreaRated PilotFailureDetectionRequired Safety IHazardousAreaRated RechargeableRequired Safety IHazardousAreaRated RemoteAlarmRequired Safety IHazardousAreaRated VoltFreeContactsRequired Safety IHazardousAreaRated WeatherProofRequired Surface Treatment & Coatings ICoatedItem CoatingColor Surface Treatment & Coatings ICoatedItem CoatingRequirement Surface Treatment & Coatings ICoatedItem CoatingType Surface Treatment & Coatings ICoatedItem ExteriorSurfaceTreatment Surface Treatment & Coatings ICoatedItem InteriorSurfaceTreatment Surface Treatment & Coatings IPaintedItem Paint_ApplicableSpecification Surface Treatment & Coatings IPaintedItem PaintByManufacturersStandard Surface Treatment & Coatings IPaintedItem PaintingResponsibility Surface Treatment & Coatings IPaintedItem PaintSpecifications_Epoxy Surface Treatment & Coatings IPaintedItem PaintSpecifications_Exterior Surface Treatment & Coatings IPaintedItem PaintSpecifications_FinishCoat Surface Treatment & Coatings IPaintedItem PaintSpecifications_Grouting Surface Treatment & Coatings IPaintedItem PaintSpecifications_Interior Surface Treatment & Coatings IPaintedItem PaintSpecifications_MaterialName Surface Treatment & Coatings IPaintedItem PaintSpecifications_Primer Surface Treatment & Coatings IPaintedItem PaintSpecifications_SurfacePreparation Surface Treatment & Coatings IPaintedItem PaintSpecifications_Underside Weight & COG ICOGItem Global_Design_CoG_X Weight & COG ICOGItem Global_Design_CoG_Y Weight & COG ICOGItem Global_Design_CoG_Z Weight & COG ICOGItem Global_Dry_Installed_CoG_X Weight & COG ICOGItem Global_Dry_Installed_CoG_Y Weight & COG ICOGItem Global_Dry_Installed_CoG_Z Weight & COG ICOGItem Global_Dry_Stripped_CoG_X Weight & COG ICOGItem Global_Dry_Stripped_CoG_Y Weight & COG ICOGItem Global_Dry_Stripped_CoG_Z Weight & COG ICOGItem Global_Test_CoG_X Weight & COG ICOGItem Global_Test_CoG_Y Weight & COG ICOGItem Global_Test_CoG_Z Weight & COG ICOGItem Global_Wet_Operating_CoG_X Weight & COG ICOGItem Global_Wet_Operating_CoG_Y Weight & COG ICOGItem Global_Wet_Operating_CoG_Z Weight & COG ICOGItem Local_Design_CoG_X Weight & COG ICOGItem Local_Design_CoG_Y Weight & COG ICOGItem Local_Design_CoG_Z Weight & COG ICOGItem Local_Dry_Installed_CoG_X Weight & COG ICOGItem Local_Dry_Installed_CoG_Y Weight & COG ICOGItem Local_Dry_Installed_CoG_Z Weight & COG ICOGItem Local_Dry_Stripped_CoG_X Weight & COG ICOGItem Local_Dry_Stripped_CoG_Y Weight & COG ICOGItem Local_Dry_Stripped_CoG_Z Weight & COG ICOGItem Local_Test_CoG_X Weight & COG ICOGItem Local_Test_CoG_Y Weight & COG ICOGItem Local_Test_CoG_Z

182

Category Interface Property Weight & COG ICOGItem Local_Wet_Operating_CoG_X Weight & COG ICOGItem Local_Wet_Operating_CoG_Y Weight & COG ICOGItem Local_Wet_Operating_CoG_Z Weight & COG ISolidItem SurfaceArea Weight & COG ISolidItem VolumetricCapacity Weight & COG IWeightItem DesignWeight Weight & COG IWeightItem Dry_Installed_Weight Weight & COG IWeightItem Dry_Stripped_Weight Weight & COG IWeightItem TestWeight Weight & COG IWeightItem Wet_Operating_Weight

This is a summary of the roles and properties that are exposed by "IEquipmentOcc", that are not exposed by the "IEquipment" interface.

Category Interface Property Dimensional & Geometrical I3DRange Range1X Dimensional & Geometrical I3DRange Range1Y Dimensional & Geometrical I3DRange Range1Z Dimensional & Geometrical I3DRange Range2X Dimensional & Geometrical I3DRange Range2Y Dimensional & Geometrical I3DRange Range2Z Dimensional & Geometrical ILocatedItem Lattitude Dimensional & Geometrical ILocatedItem LocationX Dimensional & Geometrical ILocatedItem LocationY Dimensional & Geometrical ILocatedItem LocationZ Dimensional & Geometrical ILocatedItem Longitude Dimensional & Geometrical IOrientedItem OrientationMatrix_x0 Dimensional & Geometrical IOrientedItem OrientationMatrix_x1 Dimensional & Geometrical IOrientedItem OrientationMatrix_x2 Dimensional & Geometrical IOrientedItem OrientationMatrix_y0 Dimensional & Geometrical IOrientedItem OrientationMatrix_y1 Dimensional & Geometrical IOrientedItem OrientationMatrix_y2 Dimensional & Geometrical IOrientedItem OrientationMatrix_z0 Dimensional & Geometrical IOrientedItem OrientationMatrix_z1 Dimensional & Geometrical IOrientedItem OrientationMatrix_z2 Dimensional & Geometrical IOrientedItem PlannedOrientation Equipment IEquipmentOcc SlopedEquipment_Angle Identification I3DObject SP3D_ApprovalReason Identification I3DObject SP3D_ApprovalStatus Identification I3DObject SP3D_DateCreated Identification I3DObject SP3D_DateLastModified Identification I3DObject SP3D_UserCreated Identification I3DObject SP3D_UserLastModified Identification INamedEquipment EquipPrefix Identification INamedEquipment EquipSeqNo Identification INamedEquipment EquipSuff Identification IPBSItem ConstructionStatus Identification IPBSItem ConstructionStatus2 Identification IPBSItem HeightRelativeToGrade

183

Category Interface Property Manufacturing, Fabrication, Construction IConstructedItem ConstructionRequirement Manufacturing, Fabrication, Construction IConstructedItem ConstructionType Manufacturing, Fabrication, Construction IFabricatedItem FabricatedWeight Manufacturing, Fabrication, Construction IFabricatedItem FabricationRequirement Manufacturing, Fabrication, Construction IFabricatedItem FabricationResponsibility Manufacturing, Fabrication, Construction IFabricatedItem FabricationType Manufacturing, Fabrication, Construction IFabricatedItem FabricationTypeBasis Manufacturing, Fabrication, Construction IFabricatedItem FabricatorName Manufacturing, Fabrication, Construction IInstalledItem InstallationResponsibility Manufacturing, Fabrication, Construction IManufacturedItem Manufacturer Manufacturing, Fabrication, Construction IManufacturedItem ManufacturerIndustryPractice Manufacturing, Fabrication, Construction IManufacturedItem ManufacturerModelNumber Manufacturing, Fabrication, Construction IManufacturedItem ManufacturerName Manufacturing, Fabrication, Construction IRequisitionedItem RequisitionResponsibility Manufacturing, Fabrication, Construction IRequisitionedItem RequisitionType Manufacturing, Fabrication, Construction ISuppliedItem HyperlinkToVendor Manufacturing, Fabrication, Construction ISuppliedItem SupplyResponsibility Manufacturing, Fabrication, Construction ISuppliedItem Vendor Manufacturing, Fabrication, Construction ISuppliedItem VendorPartNumber Manufacturing, Fabrication, Construction IWBSItem WBSItemPurpose Manufacturing, Fabrication, Construction IWBSItem WBSItemType Miscellaneous IDesignedItem Design_FluidState Miscellaneous IDesignedItem Design_MassFlowRate Miscellaneous IDesignedItem Design_MetalTemperature Miscellaneous IDesignedItem Design_Pressure Miscellaneous IDesignedItem Design_Pressure2 Miscellaneous IDesignedItem Design_ShortTermDuration Miscellaneous IDesignedItem Design_ShortTermPressure Miscellaneous IDesignedItem Design_ShortTermTemperature Miscellaneous IDesignedItem Design_SpecificGravityMassBasis Miscellaneous IDesignedItem Design_SteamOutPressure Miscellaneous IDesignedItem Design_SteamOutRequired Miscellaneous IDesignedItem Design_SteamOutTemperature Miscellaneous IDesignedItem Design_Temperature Miscellaneous IDesignedItem Design_Temperature2 Miscellaneous IDesignedItem Design_VacuumPressure Miscellaneous IDesignedItem Design_VacuumTemperature Miscellaneous IDesignedItem Design_VaporPressure Miscellaneous IDesignedItem Design_VentingTemperature Miscellaneous IDesignedItem Design_Viscosity Miscellaneous IDesignedItem DesignApprovalRequired Miscellaneous IDesignedItem DesignResponsibility Miscellaneous IDesignedItem ElectricalEquipmentDesignType Miscellaneous IExpandableThing ExpansionCount Miscellaneous IMountedItem MountingLocation Miscellaneous IMountedItem MountingOrientation Miscellaneous IMTOInfo MTO_ReportingRequirements Miscellaneous IMTOInfo MTO_ReportingType Miscellaneous IPartOcc CatalogName Miscellaneous IPartOcc CatalogPartNumber Process & Environmental Conditions IAltDgnPoint AltDesignPressMax

184

Category Interface Property Process & Environmental Conditions IAltDgnPoint AltDesignPressMin Process & Environmental Conditions IAltDgnPoint AltDesignTempMax Process & Environmental Conditions IAltDgnPoint AltDesignTempMin Process & Environmental Conditions IAltDgnPoint DesignCriteriaPressure2 Process & Environmental Conditions IAltDgnPoint DesignCriteriaTemperature2 Process & Environmental Conditions INormalDgnPoint DesignCriteriaFluidState Process & Environmental Conditions INormalDgnPoint DesignCriteriaMassFlowRate Process & Environmental Conditions INormalDgnPoint DesignCriteriaMetalTemperature Process & Environmental Conditions INormalDgnPoint DesignCriteriaPower Process & Environmental Conditions INormalDgnPoint DesignCriteriaPressure Process & Environmental Conditions INormalDgnPoint DesignCriteriaShortTermDuration Process & Environmental Conditions INormalDgnPoint DesignCriteriaShortTermPressure Process & Environmental Conditions INormalDgnPoint DesignCriteriaShortTermTemperature Process & Environmental Conditions INormalDgnPoint DesignCriteriaSpecificGravityMassBasis Process & Environmental Conditions INormalDgnPoint DesignCriteriaSpeed Process & Environmental Conditions INormalDgnPoint DesignCriteriaSteamOutPressure Process & Environmental Conditions INormalDgnPoint DesignCriteriaSteamOutRequirement Process & Environmental Conditions INormalDgnPoint DesignCriteriaSteamOutTemperature Process & Environmental Conditions INormalDgnPoint DesignCriteriaTemperature Process & Environmental Conditions INormalDgnPoint DesignCriteriaVacuumPressure Process & Environmental Conditions INormalDgnPoint DesignCriteriaVacuumTemperature Process & Environmental Conditions INormalDgnPoint DesignCriteriaVapourPressure Process & Environmental Conditions INormalDgnPoint DesignCriteriaVentingTemperature Process & Environmental Conditions INormalDgnPoint DesignCriteriaViscosity Process & Environmental Conditions INormalDgnPoint NormDesignPressMax Process & Environmental Conditions INormalDgnPoint NormDesignPressMin Process & Environmental Conditions INormalDgnPoint NormDesignTempMax Process & Environmental Conditions INormalDgnPoint NormDesignTempMin Startup Treatment ICleanedItem CleaningResponsibility Startup Treatment ICleanedItem CleaningRqmt Startup Treatment ISteamedItem SteamOutPressure Startup Treatment ISteamedItem SteamoutReq Startup Treatment ISteamedItem SteamOutTemperature State & Status IHeldItem Hold_ClosedBy State & Status IHeldItem Hold_ClosedDate State & Status IHeldItem Hold_CreatedBy State & Status IHeldItem Hold_CreatedDate State & Status IHeldItem Hold_Name State & Status IHeldItem Hold_Number State & Status IHeldItem HoldRemarks State & Status IHeldItem HoldStatus Testing ITestedItem TestingMaxPressure Testing ITestedItem TestingMaxTemp Testing ITestedItem TestingMinPressure Testing ITestedItem TestingMinTemp Testing ITestedItem TestingPercentage Testing ITestedItem TestingRequirements Testing ITestedItem TestingResponsibility Testing ITestedItem TestingType IPlantItem PlantItem_MaterialClass IProcessPlantEquipment ProcessPlantEquipment_DischargePressureRated

185

Category Interface Property IProcessPlantEquipment ProcessPlantEquipment_Height IProcessPlantEquipment ProcessPlantEquipment_StressRelieving

186

Appendix J. SmartPlant Meta-Schema Objects At the heart of the SmartPlant schema are the object definitions that make everything run. Behind each of these structures is a smart bit of code that behaves in a very specific way. Some of them are useful, and some of them are not used at all. They are grouped as follows:

Architecture objects Action Actor PersistentDataStore SoftwareComponent UseCase UseCaseEntity

Schema objects Book EmbeddedGraphRelDef RecursiveRelDef BooleanType EnumEnum Rel ClassDef EnumListLevelType RelDef ClassDefViewDefsType EnumListType RelDefConstraint ClassFactoryDef GraphDefType SharedObjDef ClassList InterfaceDef SpecialRelDef ClassViewMap InterfaceDefConstraint StringType CompositeStringType IntersectRelDef Topic CompSchema IntType TransformDef DateTimeType LinkedListType UMLViewDef DirectedGraphDef ModelDef UoMEnum DirectoryFileType NamedQuery UoMListType DiscreteUoM ObjectsType URLType DiscreteUoMListType Package UserForm DocumentTemplate PathDefType ViewDef DoubleArrayType PropComparisonsType ViewDefCategory DoubleType PropertyDef ViewPropsDefType EdgeDef PropValsType YMDType

Software objects PlannedMethod SoftwareArgument SoftwareClass SoftwareControl SoftwareEnum

187

SoftwareEnumList SoftwareFactory SoftwareInterface SoftwareMethod SoftwareProperty TypeLibEF

Tool objects Tool ToolSchema ToolSchemaFile

188

Appendix K. SmartPlant Schema Rationale The Guru lowers his voice and says: "There are some real great reasons to take this stuff seriously -- the most important of which is that it affects your profitability." Many engineering tools already have complex data models and databases in place designed specifically to meet the needs of their particular problem area. However, when it comes to exchanging data between applications, then there is a need to translate and map the data from one application into the language of the other application. This is typically a non-trivial task requiring domain experts from each application to work together to achieve, when compounded by trying to integrate multiple applications then the task can become overwhelming. In addition, given that each application is continually evolving, then no sooner is one integration point complete when it needs to be revisited after an upgrade. There are even ANSI and ISO standards, in various states of completeness, that might be considered as a basis for this type of engineering work. Most of them have been trying to get kick-started for 20 or more years. It's not that the problem hasn't been characterized to death; it's that committees are not famous for dishing up real-world solutions in any reasonable timeframe. Recognizing this issue, Intergraph embarked on creating a single new Data Model (SmartPlant Schema) to be at the heart of their Integration strategy and then providing mapping technology to allow other applications to read and write to this data model. The principles behind SmartPlant Schema are very simple, as new applications are to be integrated with SmartPlant Enterprise, each Design Basis and each Design Deliverable required and produced by that application is matched against the existing SmartPlant Schema with any data that is missing then being used as input to enhance it. Since the SmartPlant Schema is role-based, and very "normalized" is easy to grasp, map to, and expand. Therefore, the more robust the data model, the more productive the EPC or O/O when it comes time to getting real-world data into, and real-world queries and reports out of the SmartPlant Enterprise.

189

Appendix L. The TEST The TEST - Please Read Carefully Before You Start. Open-book, of course!

1. What are Roles? Give several examples. 2. What are Interfaces? Why do we use Interfaces? 3. What are Properties? 4. What are Classes? 5. What are Relationships? 6. What is an Object? 7. What conventions are used for naming Interfaces and classes? 8. How are a taxonomy and a hierarchy similar? 9. What term describes many ways of looking at the same thing? 10. What is a "meta schema"? 11. What is a "component schema"? 12. Why do we model data? 13. What does the "-ness" suffix have to do with object classification? 14. How many levels of "normal form" are there? 15. What is/are the symbol(s) for an interface? 16. What is an "abstract" relationship definition used for? 17. What is a "part" and what is an "occurrence" 18. What is the Default SI for LengthUoM? 19. Who is the author of this great book? 20. Why do we have "delete propagation" semantics?

190

Index Abstract, 7, 53, 70

abstracting classes, 70 ACID principle, 59

Atomic, 59 Consistent, 59 Durable, 59 Isolated, 59

Actual, 91, 94 Actual material, 94 Adapter, v, 8, 23, 58, 83, 138 Agitator, 110 API, vi, 8 Architectural Model, 100 Cardinality, 55, 138

many, 55 maximum, 73 minimum, 73

Catalog, 90 Class, 24, 25, 31, 67, 69, 71, 72, 73, 85,

88, 138 Abstracting, 70

Class diagram, 24 Class factory, 75 ClassDef, 24, 31, 48, 51, 66, 67, 74, 75,

76, 78, 81, 85, 114, 129, 138 Naming, 117 Sharing, 32

ClassViewMap, 66 Collection, 99 Component Schema, v, 23, 75, 78, 81,

103, 138 Composition, 99 CompSchema, 78 ConditionList, 42 Connectivity, 7 Conversion, 40 dangling relationship, 58 delete propagation, 97 Denormalization, 17

design intent, 89 DirectedGraphDef, 60, 64, 65 Discrimination, 61 Document, 8

PBS hierarchy, 98 ProjectList, 98

Edge, 60 Edge definition, 60, 61, 64, 65 EdgeDef, 60, 61, 62, 63, 64, 138

Discrimination, or "filtering", 61 NumericPosition, 63 path definition, 61 Position criteria, 61 PropComparisons, 64

EnumEnum, 34, 35, 37, 40, 74, 120, 130, 138 long text, 36 short text, 36

Enumerated lists, 7 EnumListLevelType, 36, 120, 121 EnumListType, 35, 36, 37, 40, 74, 120,

131, 138 open-ended, 35

EnumMetadata, 38 Exposes, 24, 27, 85 Extensible Markup Language, 83 Facility model, 89 Functionally Significant Item, 89 Graph definition, 60, 64, 65 GraphDef, 138 Hierarchy, 139

leaf-node, 119

Implies, 44, 85, 92, 139 Inheritance, 47 Instance, 31, 48, 53, 55, 69, 73, 139 Interface, 2, 13, 17, 18, 19, 21, 22, 24,

25, 52, 67, 68, 69, 71, 72, 73, 85, 86, 87, 88, 139 Review, 25

191

interface definition, 64 Interface diagram, 24 InterfaceDef, 24, 25, 26, 27, 31, 44,

45, 48, 52, 55, 61, 64, 65, 69, 74, 75, 85, 112, 113, 114, 120, 132, 139 EnumMetadata, 38 Names begin with the letter "I", 18,

30, 75 IObject, 31 IPart, 90 IPipingComponent, 120 IRotatingItem, 113, 114 join, 65 Link attributes, 73 Linnaean taxonomic model, 10, 11, 12,

18, 44, 46, 116, 118, 126, 127, 139 Loose integration, iv Map files, 8 Mapping, 139

Meta Schema, 74, 75, 76, 77, 139, 186

Model, 4, 5, 7, 11, 12, 21, 24, 32, 67, 72, 75, 85, 100, 112, 126 Architectural, 100 class-based, 68 Conceptual, 6 data, iv, v, vii, 2, 4, 7, 8, 9, 17, 19, 21,

22, 24, 25, 48, 68, 70, 72, 73, 77, 85, 86, 91, 100

P&ID data, 86 POSC Facility model, 100 POSC Material model, 100, 101

ModelDef, 32 Modeling, 2, 3, 4, 17, 21, 22, 67, 68, 69,

70, 73, 74, 77, 112 data, 5

-ness suffix, 14, 27 bicycle-ness, 49 car-ness, 14, 27 dog-ness, 49 driver-ness, 18, 19 Elliot Ness-ness, 14 human-ness, 20 man-ness, 20

object type-ness, 39 part-ness, 139 red-ness, 27 role-ness, 49 sloped-ness, 95 tank-ness, 14 taxpayer-ness, 19 thing-ness, 14 type-ness, 90, 110 valve-ness, 14, 15, 27, 49 valve-part-ness, 91 valve-type-ness, 89 woman-ness, 20

Normalization, 16, 17, 125, 150 3NF, 16, 17, 125 4NF, 16, 17, 125 5NF, 16, 17, 114, 125 data, 16, 25, 94, 112, 114, 125

Normalize, 27 Object, v, 2, 3, 7, 10, 11, 13, 16, 18, 19,

24, 25, 31, 52, 53, 67, 68, 69, 70, 73, 75, 81, 85, 86, 87, 88, 98, 139

Occurrence, 89, 91, 92 Equipment-as-an-occurrence, 95, 96 Valve-as-an-occurrence, 91, 92

Ordinal numbers, 45 Ordinality, 45, 139 Orthogonal, 19, 139 Part, 89, 90, 91, 92, 125

catalog, 90 Equipment-as-a-part, 94, 95, 96 Valve-as-a-part, 91, 92

PipingComponentTypes1, 170 Planned material, 33, 94, 101, 103,

113 Plant breakdown structure (PBS), 81, 98,

139 Polymorphism, 11, 12, 17, 39, 69, 114 POSC Caesar, 32, 90, 100 Primary Interface, 49, 75, 99, 103,

139 project, 65 Project, 139 Property, 14, 15, 25, 27

192

PropertyDef, 27, 28, 36, 42, 74, 114, 133 Typed as a Unit of Measure, 42

Publish, 7, 8, 25, 31, 34, 35, 52, 55, 69, 78, 81, 83, 86, 117, 140

pump, 112, 113, 142, 150 Realize, 12, 14, 17, 24, 45, 48, 51, 67,

69, 71, 72, 73, 75, 85, 88, 92, 140 Rel, 52, 53, 55, 88, 140 Relationship, v, 7, 8, 10, 14, 18, 19, 20,

22, 24, 25, 26, 32, 42, 44, 47, 48, 50, 52, 53, 55, 68, 69, 72, 73, 77, 85, 86, 87, 88, 92, 101, 113, 125, 139, 140 Inheritance, 47 transitive, 45

Relationships Collection, 97 Composition, 97

RelDef, 24, 50, 52, 53, 55, 56, 63, 64, 72, 73, 74, 85, 134, 135, 140 Abstract, 52, 53 Concrete, 52 locality of reference, 56, 57 Marriage, 50, 51 Patterns, 97

Retrieve, 7, 8, 17, 31, 34, 35, 69, 83, 140

Role, 4, 13, 14, 15, 16, 17, 18, 19, 20, 21, 25, 44, 47, 48, 50, 52, 56, 67, 68, 69, 70, 72, 73, 87, 92, 112, 113, 114, 139

Role-based, 13, 18, 67, 69, 70 SameAs, 32 Schema, iv, 1, 16, 24, 31, 70, 75, 76, 77,

78, 83, 85, 86, 102, 129, 140, 141 component, 99 Evolution, 8, 102 Tool, 8, 141

Schema Component, 23, 140 Scoping

PropertyDef, 27, 28, 29, 121 ScopedBy, 140 scoping property type for property

definitions, 37

Semantics, v, 8, 52, 54, 93, 125, 140 Delete and Copy, 52 Delete Propagation, 54 semantic meaning, 93 semantic network, 10 strong semantics, 34, 93

shared object, 97 Shared object, 32, 58, 66, 82, 140 SharedObjDef, 32, 33 SI-unit, 40, 41, 42, 140 SmartPlant Integration, iv SmartPlant Enterprise, 1, 6, 8, 141

enabled tools, 7 SmartPlant Foundation, iv, vi, 3, 7, 9,

19, 23, 55, 138, 140, 141 data, 17 data model, iv, 19, 23, 25

SmartPlant Integration, 141 SmartPlant schema, v, 1, 7, 8, 17, 21, 23,

24, 25, 30, 31, 32, 42, 48, 49, 53, 60, 63, 67, 69, 74, 76, 77, 83, 84, 85, 86, 87, 88, 100, 102, 112, 113, 119, 138, 139, 140, 141 Editor, 77, 81

File, 77 SmartPlant Schema Editor, vi, 24,

75, 76, 103 SmartPlant Tools

SmartPlant 3D, 6 SmartPlant Electrical, 6 SmartPlant Explorer, 6 SmartPlant Foundation, 6 SmartPlant Instrumentation, 6 SmartPlant Layout, 6 SmartPlant Markup, 6 SmartPlant Offshore, 6 SmartPlant P&ID, 6 SmartPlant Process Safety, 6 SmartPlant Review, 6 SmartPlant Review Publisher, 6 SmartSketch®, 7

SPF, iv, v, vi, 3, 8, 23, 59, 61, 66, 83 Adapter, v data model, v

193

Data model, 19 database, 7 Publish, 55 SameAs, 32

St. Ives, 111 Stereotype, 26, 31, 35, 42, 44

HasDefaultSI, 42 Symbolic logic, 20, 21, 22 Tagged item, 89, 91, 101, 103 Taxonomy, 10, 12, 18, 68, 126 TEF, 141 tombstone, 97 Tool, iv, 5, 6, 7, 8, 19, 31, 76, 77, 78,

138 Authoring, 8

Transitive, 45 Type hierarchy, 90, 91 Typical, 91 Typical material, 90, 91 UID, 82

UML, 21, 110 Extending, 26

Unified Modeling Language (UML), 21, 22, 24, 26, 67, 73, 77, 141

Unique ID (UID), 27, 31, 52, 59, 75, 88 Units of Measure, 7, 40

AnyUoM, 42 Conditions, 42

absolute, 42 gauge, 42

UoMEnum, 40, 136 UoMListType, 40, 137 Valve, 2, 3, 5, 6, 7, 11, 12, 13, 14, 15,

17, 48, 89, 91, 101 View, 5, 60 view definition, 64, 65, 66 ViewDef, 60, 64, 65, 66, 141 Work breakdown structure (WBS), 81,

98, 141 XML, 23, 77, 83, 84, 86, 88, 141