SPF - Gentle Intro To SP Schema PDF

Integration
A Gentle Introduction to the SmartPlant Schema
Version 2008 January 2008 DSPF1-PE-200051C

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.
ii
iii
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.
iv
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.
v
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.
vi
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
vii
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
viii
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
ix
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
x
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
xi
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
xii
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
xiii
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
xiv
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
1
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"
2
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:
3
http://www.intergraph.com/smartplant/3d/Productivity_Gains_with_SmartP
lant_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.
4
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!
5
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.
6
- 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.
7
- 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,
8
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!"
9
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:
10
"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
11
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
12
- 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.
13
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
14
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.
15
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
16
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.
17
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.
18
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"
19
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
20
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
21
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!
22
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
23
- 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.
24
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
25
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.
26
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:
27
- 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,
...}
28
- 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 PropComparisonsType
DiscreteUoMListType 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...
29
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.
30
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
31
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
32
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".
33
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
34
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
35
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
36
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
37
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,
38
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."
39
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.
40
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).
41
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
42
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.
43
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.
44
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?"
45
"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.
46
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).
47
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"
48
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!
49
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
50
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
51
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
52
- 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!
53
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.
54
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
55
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
56
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
57
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."
58
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.
59
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
60
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:
61
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:
62
- 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"
63
- 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
64
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
65
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.)
66
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
67
“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."
68
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
69
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)
70
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”.
71
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
72
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).
73
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.
74
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.
75
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.
76
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.
77
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.
78
Figure 30 Classes That Are in the P&ID Component
79
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
80
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
81
- 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.
82
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.
83
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.
84
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.
85
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.
86
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
87
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>
<IRel UID1=”234” UID2=”456” DefUID=”PipingPortComposition”
</Rel>
<Rel>
<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.
88
"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
89
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".
90
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."
91
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".
92
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?)
93
- 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.
94
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
95
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.
96
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.
97
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,
98
"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.
99
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
100
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!
101
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?
102
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).
103
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
104
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
105
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
106
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
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
107
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_y0 double
OrientationMatrix_z0 double
PlannedOrientation PlannedOrientations
PressureDrop DiffPressUoM
108
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
{E7B4AB1A-CE33-4021-909C-
TestingRequirements 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
EquipmentComponentComposition
EquipmentComponents
EquipmentNozzle
EquipmentOcc_EquipmentOcc
109
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).
110
- 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!)
111
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
112
- 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:
113
- 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:
114
Figure 39 Classes that are Polymorphic with respect to IRotatingItem
115
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?
116
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".
117
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
118
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.
119
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"
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
at Level-2 of the hierarchy
at Level-3 (the most-detailed) of the hierarchy
120
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".
121
- 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".
122
Figure 45 3 Levels of Scoping
Figure 46 "IPipingComponent"
123
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)...
124
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.
125
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.
126
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
127
Summary
Living things are divided into Kingdom, Phylum, Class, Order, Family, Genus
and Species
128
Appendix C. Schema Element Definitions
Figure 48 ClassDef
Figure 49 ClassDef Class
129
Figure 50 EnumEnum
Figure 51 EnumEnum Class
130
Figure 52 EnumListType
Figure 53 EnumListType Class
131
Figure 54 InterfaceDef
Figure 55 InterfaceDef Class
132
Figure 56 PropertyDef
Figure 57 PropertyDef Class
133
Figure 58 RelDef
134
Figure 59 RelDef Class
135
Figure 60 UoMEnum
Figure 61 UoMEnum Class
136
Figure 62 UoMListType
Figure 63 UoMListType Class
137
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 A subdivision of the complete SmartPlant schema that contains a
schema 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 A list of possible string property values defined for a property
(EnumListType) definition in the SmartPlant schema. a.k.a. enumerated sets, pick
lists, code lists, and lookups
Enumerated value A member of an enumerated set that defines one possible value for
(EnumEnum) a property in the SmartPlant schema. Enumerated values are
sometimes called enumerated entries
GraphDef A connected network of edge definitions with structure. Each graph
138
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 A scientific way of classifying and naming living things
taxonomic model
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 The composition of the plant based on the grouping of physical
structure (PBS) 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
139
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 A suite of ActiveX components that provide functionality
component 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
140
selected when the user defined the value in the authoring tool
SP3D SmartPlant 3D
SPEL SmartPlant Electrical
SmartPlant A suite of integrated engineering applications delivered together,
Enterprise whose purpose is the total information of a large facility, e.g.,
process plant, ship, etc.
SmartPlant The underlying software framework that allows SmartPlant tools to
Foundation (SPF) integrate. Provides database, rules, document management, etc.
SmartPlant SmartPlant integration standardizes and improves the
Integration 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 The composition of the plant based on the construction work to be
structure (WBS) 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
141
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
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
142
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
143
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
144
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
177 GasGroup GasGroups
178 HazardousAreaClassification EquipmentAreaClassifications
179 HazardousAreaTemperatureClass TemperatureClasses
180 AutomaticIgnitionRequired boolean
181 AutomaticReIgnitionRequired boolean
182 BatteryBackupRequried boolean
183 FlameProofRequired boolean
184 LocalAlarmRequired boolean
145
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
146
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
147
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
323 OrientationMatrix_y0 double
148
Prop
# Property Type
326 OrientationMatrix_z0 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.
149
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
150
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
151
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
152
Interface Property
IInsulatedItem TotalInsulThick
IInsulatedItem AvgInsulDens
IInsulatedItem InsulCompositeMatl
IInsulatedItem InsulSpec
IInsulatedItem InsulationSurfaceArea
IInsulatedItem InsulThickSrc
IInsulatedItem InsulTemp
IInsulatedItem InsulPurpose1
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_ItemTag
IJacketedItem Jacket_InsulationWeight
IJacketedItem Jacket_InsulationSurfaceArea
IJacketedItem Jacket_OperatingTemperature
IJacketedItem Jacket_TotalInsulThick
IJacketedItem Jacket_InsulThickSrc
IJacketedItem Jacket_InsulSpec
IJacketedItem Jacket_InsulTemp
ILocatedItem Lattitude
ILocatedItem Longitude
ILocatedItem LocationZ
ILocatedItem LocationY
ILocatedItem LocationX
ILubricatedItem LubricationRequirement
153
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 PlannedOrientation
154
Interface Property
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
155
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
156
Interface Property
IWeightItem DesignWeight
IWeightItem Wet_Operating_Weight
IWeightItem Dry_Installed_Weight
Pump properties have been "Normalized"
157
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
Miscellaneous Isolating sleeve
Union nut
Vent stack cover
GBSET
Jack screw
Miscellaneous bolting
Nut
Washer
Bonnet shield
Accessories Fitting shield
Flange shield
Shields
Instrument shield
Piping specialty shield
Valve shield
Crimp ring
Tubing accessories
Tube strap
Valve assembly shield Valve and flange shield
BSVPK
Valve packing DSVPK
VPK
Chain
Valve-operator accessory Extension stem guide
Floor stand bracket
Branches Double long turn Tee
Double full-size tees Double Tee
Tee with double offset
Double olet-type branches XLET
Tee with double offset, reducing branch
Double reducing tees Tee with double offset, reducing run and branch
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
Full-size tees Drop Tee
Long turn Tee
S90YB
Supply and return Tee
T
158
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
Olet-type branches
SOL
SOLSS
SWOL
TLET
TOL
TOLSS
WOL
WOLSS
XRB
Reducing crosses
XRRB
L90YRB
Reducing laterals LRB
LRRB
S90YRB
Tee with offset, reducing branch
Tee with offset, reducing run and branch
Tee with offset, reducing runs
Reducing tees Tee, heat exchanger
Tee, reducing run (baseboard)
TRB
TRI
TRRB
Reducing true Y
Reducing wyes
Reducing wye
RPAD
Reinforcing pads
RPAD2
Reinforcing welds RWELD
159
RWELD2
45 degree Y
Long turn Y
Wyes
WYE
Y
Direction-change 11.25 degree direction change E11
fitting 15 degree direction change E15
22.5 degree direction change E22
30 degree direction change E30
E45
E453D
E45L
E45LR
E45LT
45 degree direction change E45M1
E45M2
E45M3
E45S
E45ST
E45U
E903DT
45-90 degree direction change
E90LRT
5.625 degree direction change E5
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
90 degree direction change
E90LT
E90M1
E90M2
E90M3
E90M4
E90M5
E90S
E90SR
E90ST
E90SW
E90TC
E90U
E90R
90 degree reducing direction change
E90RST
Double 90 degree direction change 90 degree double elbow
Less than 45 degree direction change E453DT
160
E45LRT
180 degree return with cleanout
R180
R180CL
R180LR
Returns R180MD
R180OP
R180SR
R180UP
R180UPSO
Closure plate, external to jacket
Closure plates
Closure plate, internal to jacket
CAP
Cap with drain
CLOSSET
Ending fittings Fitting cleanout with plug
End-fitting
HDHEMI
HIFVPLU
PLUG
BALJDE90
Flexible ending fittings BALJE90
BALJST
Dry barrel type hydrant
FOACH
FOAMK
FOAT
Fire hydrant HYD3W
HYDIND
HYDMNOZ
HYDSFR
HYDUG
Fire and safety Hose reel
Hose accessory
HRST1
ME1
MELB
MFOAM
Monitors
MGUN
MN1
MREMO
Spray sprinkler
Sprinklers
SSP1
In-Line Fittings Adapters Adapter, drop (tubing)
Adapter, flush (tubing)
Adapter, hose (tubing)
Adapter, soil pipe (tubing)
Adapter, trap (tubing)
Adapter, tubing
ADPT01
ADPT02
ADPT03
ADPT04
ADPT05
ADPT06
161
TLDMADPT
BDISC
BLPAD
Blinds BLSPO
FBLD
FUBLD
BUSH
Bushing, external
Bushing, flush
CPLR
Concentric diameter change INSR1
INSR2
REDC
REDCLT
SWGC
Concentric diameter increase INCRC
Couplings and connectors 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
SWFFQCS
162
SWQCPLB
SWQCSWOS
SWQCSWS
Tapping sleeve
Tapping sleeve, mechanical joint
WELBFL
REDE
Eccentric diameter change REDELT
SWGE
Expander flanges FEWN
CBFERR
Ferrules FERR
TCFERR
BALFL
FCP
FFIL
FLWN
FS
Flanges
FSJ
FSW
FTHD
FWN
INSFL
HIFADPT
High integrity flange adapters HIFADPTSPL
HIFADPTSTEP
HIFLBRING
High integrity flange load bearing rings HIFLBRINGSPL
HIFLBRINGSTEP
DBLHUB
GLBLHUB
GLHUB
Hubs
HUB
SPOLHUB
TLHUB
BLSPA
OPSPA
In-line spacers
SLSPA
TBSPA
FL
Lap joint flanges
FSSE
BNIP
Close nipple
Nipples
INLNIP
NIP
FOSO
FOSW
Orifice flanges
FOTHD
FOWN
Orifice Plates Orifice plate
Orifice spacers ORFSPA
Orifice spacers ORSPA
Plate flanges FPL
163
FPLSE
FRFILR
FRINS
FRS
Reducing flanges
FRSW
FRTHD
FRWN
Reducing Plate flanges FRPL
Reducing Slip-on flanges FRSO
FSO
Slip-on flanges
FSOSE
AFCNOZ
AIRANOZ
FLSPNOZ
Spray nozzles
HFCNOZ
HOLCNOZ
VLFCNOZ
STBNDL
Stub ends
STBNDS
T1SPA
Tapered spacers
T2SPA
UN
UND
Unions UNHD
UNO
UNTL
Piping specialty Detonation flame arrester
FAEOLC
FAEOLCM
FAEOLR
FAICMET
FAICP
Arrestor Flame arrester with free vent
Flame arrester, horizontal
Flame arrester, vertical
Flame arrestor
Flame check, high pressure
Flame check, low pressure
Flame trap assembly
Blank disc
Blind flange
Blinds
Paddle blind
Spectacle blind
Sample cooler
Sample cooler, high pressure
Sample cooler, low pressure
Coolers Sampler, fixed volume liquid
Sampler, in-line
SLRMOB
SLRPNOB
Couplings
Exhaust heads Exhaust head
Expansion joint EJCLSH
164
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
Filter, instrument protection
Filter, multiplex liquid
Paddle spacer
In-line spacers Ring spacer
Solid spacer
Air chamber
Miscellaneous tubing specialties Bulkhead fitting
Venturi insert
Specialty 1
Other piping specialties
Specialty 2
Drum trap with bottom inlet
Drum trap, swivel
P-trap
Other traps P-trap with cleanout
P-trap with union joint
P-trap, suction line
Trap, upturn
Gas pulse trap
Hammer arrestor
Pressure attenuation devices Liquid pulse trap
Shock trap
Surge arrester
Acoustic filter
Acoustic pulse trap
In-line silencer
Silencers
Noise attenuator
Vent diffuser
Vent silencer
Specialty valves Motor operated valve
Steam trap Automatic differential condensate controller
Ball float liquid drainer
Ball float steam trap
Bellows steam trap
Controlled disc steam trap
Fixed temperature discharge trap
165
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
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)
Y strainer
Suction tees and ejectors Ejector
Injector
Mixing tee
166
Mixing tee, high pressure static
Sparger
Double elbow swivel joint
LOARAFR
LOARBL
LOARF
LOARSCI
Swivel joint LOARSLS
LOARVRL
LOARWA
ROTUN
Single elbow swivel joint
Straight-thru swivel joint
Free vent with screen
Free vent without screen
Vents
FVENT
FVENTWE
Pressure/vacuum relief manhole cover
PSE Press/vac rupture disc P
Relief device
PSV Press/vac relief valve P
Temperature fusible plug or disc
Distance pieces DISTPC
Hose HOSE
Jacketed piping, variable length Plain piping with integral core and jacket
Straight section
Piping fixed-length PIPEFX
Piping variable-length PIPE
Tube TUBE
Valves 3-way generic body valve
3-way solenoid valve
3WRV1
BAL3W
CK3W
3-way valves
CKST3W
DIA3W
GLO3W
PLU3W
SLI3W
3-way valves flow-directional CKAR
4-way generic body valve
4-way solenoid valve
4WRV1
4-way valves BAL4W
CK4W
DIA4W
PLU4W
BAL5W
CK5W
DIA5W
5-way valves
GENB5W
PLU5W
SOL5W
6-way valves GENB6W
PLU6W
167
SOL6W
7-way valves DIA7W
CKAL
Angle valve flow-directional
CKAST
2-way angle solenoid valve
Angle slurry valve, 90 Degree
BDA
Angle valves Generic body angle valve
GLOA
HOSA
TKDR
Angle valves, 45 Degree Angle slurry valve, 45 Degree
Lower cross
Lower tee
Lower tee / upper cross
Control/Throttling valves Upper cross / lower cross
Upper tee / lower cross
Upper tee / lower tee
Y-body
DIA2W
Left-hand tangential, reverse acting
Diverter valves Right-hand tangential, reverse acting
Upper cross, reverse acting
Upper tee, reverse acting
ALA
Fire and safety valves DEL
DRY
45 degrees
90 degrees
90 degrees, offset down
Kettle valves 90 degrees, offset left
90 degrees, offset right
Flanged 45 degrees
Flanged 90 degrees
Linear Flow Directional Valves BFYDF
BFYDFDE
BFYDFL
BFYDFS
BFYHP
BFYLP
BFYLUG
BFYLUGDE
BFYTE
BFYWF
BFYWFDE
BFYWFL
BFYWFS
BFYWFSFL
BFYWFSFS
BWV
CKBAL
CKBP
CKHL
168
CKLR
CKLRY
CKPI
CKS
CKSPS
CKSR
CKSSP
CKST
CKTD
CKVL
CKWF
CKYST
FOOT
Linear Valves 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
PLUVP
169
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
Pressure valves
PVCONVEOL
PVCONVFA
PVCONVINL
PVCONVPAW
PVCONVPAWSL
PVCONVSL
Safety relief valve
Straight-through pressure relief valve
Tee type relief valve
Vacuum relief valve
VACVEOL
VACVSM
SAMHO
Sampling valves
SAMHOIF
Sanitary access valve/fitting assemblies Sanitary access valve/fitting assembly
FLBT
Free flow reverse current valve
Specialty valves Motor operated valve
SAFS
SAFSTAN
Tandem valves Tandem valve
10F flanged
Clamp cross
Clamp inlet
Flanged cross
Tank outlet valves
Flanged offset left
Flanged offset right
Tee offset left
Tee offset right
Temperature valves Temperature safety valve
The 3-Level Enumerated List Named "PipingComponentTypes1"
170
Appendix H. Some UML Diagrams
Figures for Chapter 25, "UML Reading Practice for ClassDefs"
Figure 64 UML Diagram of EQDFan
171
Figures for Chapter 25, "UML Reading Practice for InterfaceDefs"
Figure 65 Interface Diagram 1 - Agitator Part & Occurrence Model
Figure 66 Interface Diagram 2
172
173
174
175
x
176
x
177
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 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
178
Insulation & Tracing IInsulatedItem InsulationSurfaceArea
Insulation & Tracing IInsulatedItem InsulationWeight
Insulation & Tracing IInsulatedItem InsulCompositeMatl
Insulation & Tracing IInsulatedItem InsulPurpose1
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_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
179
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
Conditions IPressureDropItem FrictionalPressureDrop
Conditions IPressureDropItem MaximumPressureDrop
Conditions IPressureDropItem MinimumPressureDrop
Conditions IPressureDropItem MomentumPressureDrop
Conditions IPressureDropItem PressureDrop
Conditions IPressureDropItem PressureDrop_Dirty
Conditions IPressureDropItem PressureDropLimit
Conditions IPressureDropItem PressureDropPercent
Conditions IPressureDropItem StaticPressureDrop
Conditions IPressureRatedObject PressureRating
Conditions IPressureRatedObject PressureRating2
Conditions IProcessWettedItem CorrosionAllowance
Conditions IProcessWettedItem FluidServiceCategory
Conditions IProcessWettedItem FluidServiceCategory2
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
180
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
181
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.

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_y0
Dimensional & Geometrical IOrientedItem OrientationMatrix_z0
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
182
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
183
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
184
IProcessPlantEquipment ProcessPlantEquipment_Height
IProcessPlantEquipment ProcessPlantEquipment_StressRelieving
185
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
186
SoftwareEnumList
SoftwareFactory
SoftwareInterface
SoftwareMethod
SoftwareProperty
TypeLibEF
Tool objects
Tool
ToolSchema
ToolSchemaFile
187
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.
188
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?
189
Index
Abstract, 7, 53, 70 design intent, 89
abstracting classes, 70 DirectedGraphDef, 60, 64, 65
ACID principle, 59 Discrimination, 61
Atomic, 59 Document, 8
Consistent, 59 PBS hierarchy, 98
Durable, 59 ProjectList, 98
Isolated, 59
Edge, 60
Actual, 91, 94
Edge definition, 60, 61, 64, 65
Actual material, 94
Adapter, v, 8, 23, 58, 83, 138 EdgeDef, 60, 61, 62, 63, 64, 138
Discrimination, or "filtering", 61
Agitator, 110
NumericPosition, 63
API, vi, 8 path definition, 61
Architectural Model, 100 Position criteria, 61
Cardinality, 55, 138 PropComparisons, 64
many, 55
maximum, 73 EnumEnum, 34, 35, 37, 40, 74,
minimum, 73 120, 130, 138
Catalog, 90 long text, 36
Class, 24, 25, 31, 67, 69, 71, 72, 73, 85, short text, 36
88, 138 Enumerated lists, 7
Abstracting, 70 EnumListLevelType, 36, 120, 121
Class diagram, 24 EnumListType, 35, 36, 37, 40, 74, 120,
131, 138
Class factory, 75
open-ended, 35
ClassDef, 24, 31, 48, 51, 66, 67, 74, 75, EnumMetadata, 38
76, 78, 81, 85, 114, 129, 138 Exposes, 24, 27, 85
Naming, 117
Sharing, 32 Extensible Markup Language, 83
ClassViewMap, 66 Facility model, 89
Collection, 99 Functionally Significant Item, 89
Component Schema, v, 23, 75, 78, 81, Graph definition, 60, 64, 65
103, 138 GraphDef, 138
Composition, 99 Hierarchy, 139
CompSchema, 78 leaf-node, 119
ConditionList, 42 Implies, 44, 85, 92, 139
Connectivity, 7 Inheritance, 47
Conversion, 40 Instance, 31, 48, 53, 55, 69, 73, 139
dangling relationship, 58 Interface, 2, 13, 17, 18, 19, 21, 22, 24,
delete propagation, 97 25, 52, 67, 68, 69, 71, 72, 73, 85, 86,
Denormalization, 17 87, 88, 139
Review, 25
190
interface definition, 64 object type-ness, 39
Interface diagram, 24 part-ness, 139
red-ness, 27
InterfaceDef, 24, 25, 26, 27, 31, 44, role-ness, 49
45, 48, 52, 55, 61, 64, 65, 69, 74, 75, sloped-ness, 95
85, 112, 113, 114, 120, 132, 139 tank-ness, 14
EnumMetadata, 38 taxpayer-ness, 19
Names begin with the letter "I", 18, thing-ness, 14
30, 75 type-ness, 90, 110
IObject, 31 valve-ness, 14, 15, 27, 49
IPart, 90 valve-part-ness, 91
IPipingComponent, 120 valve-type-ness, 89
IRotatingItem, 113, 114 woman-ness, 20
join, 65 Normalization, 16, 17, 125, 150
3NF, 16, 17, 125
Link attributes, 73 4NF, 16, 17, 125
Linnaean taxonomic model, 10, 11, 12, 5NF, 16, 17, 114, 125
18, 44, 46, 116, 118, 126, 127, 139 data, 16, 25, 94, 112, 114, 125
Loose integration, iv
Normalize, 27
Map files, 8 Object, v, 2, 3, 7, 10, 11, 13, 16, 18, 19,
Mapping, 139 24, 25, 31, 52, 53, 67, 68, 69, 70, 73,
Meta Schema, 74, 75, 76, 77, 75, 81, 85, 86, 87, 88, 98, 139
139, 186 Occurrence, 89, 91, 92
Model, 4, 5, 7, 11, 12, 21, 24, 32, 67, 72, Equipment-as-an-occurrence, 95, 96
75, 85, 100, 112, 126 Valve-as-an-occurrence, 91, 92
Architectural, 100 Ordinal numbers, 45
class-based, 68 Ordinality, 45, 139
Conceptual, 6 Orthogonal, 19, 139
data, iv, v, vii, 2, 4, 7, 8, 9, 17, 19, 21, Part, 89, 90, 91, 92, 125
22, 24, 25, 48, 68, 70, 72, 73, 77,
catalog, 90
85, 86, 91, 100
Equipment-as-a-part, 94, 95, 96
P&ID data, 86
Valve-as-a-part, 91, 92
POSC Facility model, 100
POSC Material model, 100, 101 PipingComponentTypes1, 170
ModelDef, 32 Planned material, 33, 94, 101, 103,
Modeling, 2, 3, 4, 17, 21, 22, 67, 68, 69, 113
70, 73, 74, 77, 112 Plant breakdown structure (PBS), 81, 98,
data, 5 139
-ness suffix, 14, 27 Polymorphism, 11, 12, 17, 39, 69, 114
bicycle-ness, 49 POSC Caesar, 32, 90, 100
car-ness, 14, 27 Primary Interface, 49, 75, 99, 103,
dog-ness, 49 139
driver-ness, 18, 19
project, 65
Elliot Ness-ness, 14
Project, 139
human-ness, 20
man-ness, 20 Property, 14, 15, 25, 27
191
PropertyDef, 27, 28, 36, 42, 74, Semantics, v, 8, 52, 54, 93, 125, 140
Delete and Copy, 52
114, 133
Delete Propagation, 54
Typed as a Unit of Measure, 42
semantic meaning, 93
Publish, 7, 8, 25, 31, 34, 35, 52, 55, 69, semantic network, 10
78, 81, 83, 86, 117, 140 strong semantics, 34, 93
pump, 112, 113, 142, 150 shared object, 97
Realize, 12, 14, 17, 24, 45, 48, 51, 67, Shared object, 32, 58, 66, 82, 140
69, 71, 72, 73, 75, 85, 88, 92, 140
SharedObjDef, 32, 33
Rel, 52, 53, 55, 88, 140
SI-unit, 40, 41, 42, 140
Relationship, v, 7, 8, 10, 14, 18, 19, 20,
22, 24, 25, 26, 32, 42, 44, 47, 48, 50, SmartPlant Integration, iv
52, 53, 55, 68, 69, 72, 73, 77, 85, 86, SmartPlant Enterprise, 1, 6, 8, 141
87, 88, 92, 101, 113, 125, 139, 140 enabled tools, 7
Inheritance, 47 SmartPlant Foundation, iv, vi, 3, 7, 9,
transitive, 45 19, 23, 55, 138, 140, 141
Relationships data, 17
Collection, 97 data model, iv, 19, 23, 25
Composition, 97 SmartPlant Integration, 141
RelDef, 24, 50, 52, 53, 55, 56, 63, 64, SmartPlant schema, v, 1, 7, 8, 17, 21, 23,
72, 73, 74, 85, 134, 135, 140 24, 25, 30, 31, 32, 42, 48, 49, 53, 60,
Abstract, 52, 53 63, 67, 69, 74, 76, 77, 83, 84, 85, 86,
Concrete, 52 87, 88, 100, 102, 112, 113, 119, 138,
locality of reference, 56, 57 139, 140, 141
Marriage, 50, 51 Editor, 77, 81
Patterns, 97 File, 77
Retrieve, 7, 8, 17, 31, 34, 35, 69, 83, SmartPlant Schema Editor, vi, 24,
140 75, 76, 103
Role, 4, 13, 14, 15, 16, 17, 18, 19, 20, SmartPlant Tools
21, 25, 44, 47, 48, 50, 52, 56, 67, 68, SmartPlant 3D, 6
69, 70, 72, 73, 87, 92, 112, 113, 114, SmartPlant Electrical, 6
139 SmartPlant Explorer, 6
Role-based, 13, 18, 67, 69, 70 SmartPlant Foundation, 6
SameAs, 32 SmartPlant Instrumentation, 6
Schema, iv, 1, 16, 24, 31, 70, 75, 76, 77, SmartPlant Layout, 6
78, 83, 85, 86, 102, 129, 140, 141 SmartPlant Markup, 6
component, 99 SmartPlant Offshore, 6
Evolution, 8, 102 SmartPlant P&ID, 6
Tool, 8, 141 SmartPlant Process Safety, 6
Schema Component, 23, 140 SmartPlant Review, 6
Scoping SmartPlant Review Publisher, 6
PropertyDef, 27, 28, 29, 121 SmartSketch®, 7
ScopedBy, 140 SPF, iv, v, vi, 3, 8, 23, 59, 61, 66, 83
scoping property type for property Adapter, v
definitions, 37 data model, v
192
Data model, 19 UML, 21, 110
database, 7 Extending, 26
Publish, 55 Unified Modeling Language (UML), 21,
SameAs, 32 22, 24, 26, 67, 73, 77, 141
St. Ives, 111 Unique ID (UID), 27, 31, 52, 59, 75, 88
Stereotype, 26, 31, 35, 42, 44 Units of Measure, 7, 40
HasDefaultSI, 42 AnyUoM, 42
Symbolic logic, 20, 21, 22 Conditions, 42
Tagged item, 89, 91, 101, 103 absolute, 42
Taxonomy, 10, 12, 18, 68, 126 gauge, 42
TEF, 141 UoMEnum, 40, 136
tombstone, 97 UoMListType, 40, 137
Tool, iv, 5, 6, 7, 8, 19, 31, 76, 77, 78, Valve, 2, 3, 5, 6, 7, 11, 12, 13, 14, 15,
138 17, 48, 89, 91, 101
Authoring, 8 View, 5, 60
Transitive, 45 view definition, 64, 65, 66
Type hierarchy, 90, 91 ViewDef, 60, 64, 65, 66, 141
Typical, 91 Work breakdown structure (WBS), 81,
Typical material, 90, 91 98, 141
UID, 82 XML, 23, 77, 83, 84, 86, 88, 141
193

SPF - Gentle Intro To SP Schema PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SPF - Gentle Intro To SP Schema PDF

Uploaded by

Copyright:

Available Formats

Integration

A Gentle Introduction to the SmartPlant Schema

Version 2008 January 2008 DSPF1-PE-200051C

- A software-based platform that allows for integration of a wide-variety of

SmartPlant® Schema Overview

How This Book is Organized

- The SmartPlant Schema Editor

Documentation on all of the above-mentioned topics are available through

SmartPlant Enterprise won't force you to re-code those programs in order

What the heck is a "Schema"?

1. What is "data modeling"?

"nah na NAH naaaa"

Why do we "model data"?

Lots of "Things" in the World

Data Lives Past the "Design Phase"

The Concept of a "Model"

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

Different "Views" of the Same Thing

- SmartPlant 3D our next generation, data-centric, rule-driven

The Definition of a "Data Model"

The SmartPlant schema defines the structure of the SmartPlant Foundation

- Enumerated lists: engineering is full of lists of valid data that can be

Tool User's Perspective

Tool Map Schemas

Sorting is a Way of Grouping Objects

The Linnaean Taxonomic Model

"Animal, Vegetable, or Mineral?"

Shortcomings of the Linnaean Model

The Linnaean Model Fails in the General Case

- a dog's heart has valves (animal)

If a Valve Could Talk (this is what it would say)

A Role-based View of Objects

Microsoft has been a leading proponent of the "role-based" view of objects,

Zen-like Thinking about Objects (and their "-ness")

The Elliot Ness-ness of Elliot Ness

A Designer is Trying to Fulfill a Role

Foundations of Data Normalization

What is Data Normalization?

3NF, 4NF, 5NF - When is NF Enough?

SmartPlant Foundation Data is 4NF and 5NF

Baby, You Can Drive My Car

- Driver's License number

If someone is thinking of you as a "Driver", this is where they go: the

If we want to add more information about you, as a "Driver", where would we

"The SmartPlant Foundation data model lets

Figure 4 Symbols Representing Human, Man, Woman

- What "role" does a "human" represent, i.e., what is "human-ness"?

Data Modeling Conventions

Figure 5 The Symbol for the IMan Interface

Symbols are Precise

Unified Modeling Language (UML)

The SmartPlant schema is represented by a Unified Modeling Language

SmartPlant Schema Rules

- All schema data is defined as part of the SmartPlant schema

- Classes and ClassDefs

Overview of the SmartPlant schema Data Model

• A "Class" is designated by a rectangle

Generally, two types of diagrams are developed, viz., an "Interface diagram",

SmartPlant schema Class / Interface / Relationship Model

- Classes typically represent real-world objects like instruments,

In SmartPlant schema jargon, ClassDefs "realize" InterfaceDefs. For

Defining an Interface (InterfaceDef)