Integration

A Gentle Introduction to the SmartPlant Schema

Version 2014 R3 (5.3)
April 2015
Copyright
Copyright © 2006-2015 Hexagon AB and/or its subsidiaries and affiliates.All rights reserved.
Including software, documentation, 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 from Intergraph Corporation.
Portions of the user interface copyright 2012-2014 Telerik AD.

U.S. Government 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
305 Intergraph Way
Madison, AL 35758

Documentation
Documentation shall mean, whether in electronic or printed form, User's Guides, Installation Guides, Reference Guides,
Administrator's Guides, Customization Guides, Programmer's Guides, Configuration Guides and Help Guides delivered with
a particular software product.

Other Documentation
Other Documentation shall mean, whether in electronic or printed form and delivered with software or on Intergraph Smart
Support, SharePoint, or box.net, any documentation related to work processes, workflows, and best practices that is
provided by Intergraph as guidance for using a software product.

Terms of Use
a. Use of a software product and Documentation is subject to the Software License Agreement ("SLA") delivered with the
software product unless the Licensee has a valid signed license for this software product with Intergraph Corporation. If
the Licensee has a valid signed license for this software product with Intergraph Corporation, the valid signed license
shall take precedence and govern the use of this software product and Documentation. Subject to the terms contained
within the applicable license agreement, Intergraph Corporation gives Licensee permission to print a reasonable
number of copies of the Documentation as defined in the applicable license agreement and delivered with the software
product for Licensee's internal, non-commercial use. The Documentation may not be printed for resale or redistribution.
b. For use of Documentation or Other Documentation where end user does not receive a SLA or does not have a valid
license agreement with Intergraph, Intergraph grants the Licensee a non-exclusive license to use the Documentation or
Other Documentation for Licensee’s internal non-commercial use. Intergraph Corporation gives Licensee permission to
print a reasonable number of copies of Other Documentation for Licensee’s internal, non-commercial use. The Other
Documentation may not be printed for resale or redistribution. This license contained in this subsection b) may be
terminated at any time and for any reason by Intergraph Corporation by giving written notice to Licensee.
Disclaimer of Warranties
Except for any express warranties as may be stated in the SLA or separate license or separate terms and conditions,
Intergraph Corporation disclaims any and all express or implied warranties including, but not limited to the implied warranties
of merchantability and fitness for a particular purpose and nothing stated in, or implied by, this document or its contents shall
be considered or deemed a modification or amendment of such disclaimer. 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, Documentation and Other Documentation discussed in this document are furnished under a license and may
be used or copied only in accordance with the terms of this license. 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.
 Limitation of Damages
IN NO EVENT WILL INTERGRAPH CORPORATION BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL
INCIDENTAL, SPECIAL, OR PUNITIVE DAMAGES, INCLUDING BUT NOT LIMITED TO, LOSS OF USE OR
PRODUCTION, LOSS OF REVENUE OR PROFIT, LOSS OF DATA, OR CLAIMS OF THIRD PARTIES, EVEN IF
INTERGRAPH CORPORATION HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
UNDER NO CIRCUMSTANCES SHALL INTERGRAPH CORPORATION’S LIABILITY EXCEED THE AMOUNT THAT
INTERGRAPH CORPORATION HAS BEEN PAID BY LICENSEE UNDER THIS AGREEMENT AT THE TIME THE CLAIM
IS MADE. EXCEPT WHERE PROHIBITED BY APPLICABLE LAW, NO CLAIM, REGARDLESS OF FORM, ARISING OUT
OF OR IN CONNECTION WITH THE SUBJECT MATTER OF THIS DOCUMENT MAY BE BROUGHT BY LICENSEE
MORE THAN TWO (2) YEARS AFTER THE EVENT GIVING RISE TO THE CAUSE OF ACTION HAS OCCURRED.
IF UNDER THE LAW RULED APPLICABLE ANY PART OF THIS SECTION IS INVALID, THEN INTERGRAPH LIMITS ITS
LIABILITY TO THE MAXIMUM EXTENT ALLOWED BY SAID LAW.

Export Controls
Intergraph Corporation’s commercial-off-the-shelf software products, customized software and/or third-party software,
including any technical data related thereto (“Technical Data”), obtained from Intergraph Corporation, its subsidiaries or
distributors, is subject to the export control laws and regulations of the United States of America. Diversion contrary to U.S.
law is prohibited. To the extent prohibited by United States or other applicable laws, Intergraph Corporation software
products, customized software, Technical Data, and/or third-party software, or any derivatives thereof, obtained from
Intergraph Corporation, its subsidiaries or distributors must not be exported or re-exported, directly or indirectly (including via
remote access) under the following circumstances:
a. To Cuba, Iran, North Korea, the Crimean region of Ukraine, or Syria, or any national of these countries or territories.
b. To any person or entity listed on any United States government denial list, including, but not limited to, the United
States Department of Commerce Denied Persons, Entities, and Unverified Lists, the United States Department of
Treasury Specially Designated Nationals List, and the United States Department of State Debarred List
(https://build.export.gov/main/ecr/eg_main_023148).
c. To any entity when Customer knows, or has reason to know, the end use of the software product, customized software,
Technical Data and/or third-party software obtained from Intergraph Corporation, its subsidiaries or distributors is
related to the design, development, production, or use of missiles, chemical, biological, or nuclear weapons, or other
un-safeguarded or sensitive nuclear uses.
d. To any entity when Customer knows, or has reason to know, that an illegal reshipment will take place.
e. Any questions regarding export/re-export of relevant Intergraph Corporation software product, customized software,
Technical Data and/or third-party software obtained from Intergraph Corporation, its subsidiaries or distributors, should
be addressed to PPM’s Export Compliance Department, 305 Intergraph Way, Madison, Alabama 35758 USA or at
[email protected]. Customer shall hold harmless and indemnify PPM and Hexagon Group Company
for any causes of action, claims, costs, expenses and/or damages resulting to PPM or Hexagon Group Company from
a breach by Customer.
Trademarks
Intergraph®, the Intergraph logo®, Intergraph Smart®, SmartPlant®, SmartMarine, SmartSketch®, SmartPlant Cloud®, PDS®,
FrameWorks®, I-Route, I-Export, ISOGEN®, SPOOLGEN, SupportManager®, SupportModeler®, SAPPHIRE®, TANK, PV
Elite®, CADWorx®, CADWorx DraftPro®, GTSTRUDL®, and CAESAR II® are trademarks or registered trademarks of
Intergraph Corporation or its affiliates, parents, subsidiaries. Hexagon and the Hexagon logo are registered trademarks of
Hexagon AB or its subsidiaries. Microsoft and Windows are registered trademarks of Microsoft Corporation. MicroStation is
a registered trademark of Bentley Systems, Inc. Other brands and product names are trademarks of their respective owners.

A Gentle Introduction to SmartPlant Schema ii

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.

A Gentle Introduction to SmartPlant Schema iii

 - 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! Hexagon PPM 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 J.

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.

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.

A Gentle Introduction to SmartPlant Schema iv

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.

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

A Gentle Introduction to SmartPlant Schema v

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 ;-}

A Gentle Introduction to SmartPlant Schema vi

Table of Contents

Introduction ................................................................................................................................................. iii

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

Table of Contents ...................................................................................................................................... vii

Table of Figures ......................................................................................................................................... xii

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" ....................................................................................................................... 3
Modeling "Anything" ................................................................................................................................ 4
Modeling Data ......................................................................................................................................... 4
Different "Views" of the Same Thing ....................................................................................................... 5
A "Shared" View ...................................................................................................................................... 5
The Definition of a "Data Model" ............................................................................................................. 5
Tool User's Perspective .......................................................................................................................... 6
Tool Adapters .......................................................................................................................................... 6
Tool Map Schemas ................................................................................................................................. 6
Conclusion .............................................................................................................................................. 7

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

4. Why Be Normal? .................................................................................................................................... 13

Foundations of Data Normalization ....................................................................................................... 13

A Gentle Introduction to SmartPlant Schema vii

 What is Data Normalization? ................................................................................................................ 13
3NF, 4NF, 5NF - When is NF Enough? ................................................................................................ 13
SmartPlant Foundation Data is 4NF and 5NF ...................................................................................... 14
Denormalization .................................................................................................................................... 14
Where Interfaces Fit In .......................................................................................................................... 14
Baby, You Can Drive My Car ................................................................................................................ 15
Orthogonal roles .................................................................................................................................... 15

5. An Introduction to Symbolic Logic ...................................................................................................... 16

Data Modeling Conventions .................................................................................................................. 16
Symbols are Precise ............................................................................................................................. 17
Unified Modeling Language (UML) ....................................................................................................... 17
Symbolic Logic ...................................................................................................................................... 17

6. The SmartPlant Data Model .................................................................................................................. 18

The SmartPlant Schema ....................................................................................................................... 18
SmartPlant Schema Rules .................................................................................................................... 18
Lots of Structures .................................................................................................................................. 18
Overview of the SmartPlant schema Data Model ................................................................................. 19
SmartPlant schema Class / Interface / Relationship Model .................................................................. 19

7. Defining an Interface (InterfaceDef) ..................................................................................................... 20

Review of Interfaces.............................................................................................................................. 20
Defining an Interface (InterfaceDef) ...................................................................................................... 20
InterfaceDef - Graphic Representation ................................................................................................. 21
The <<Stereotype>> ............................................................................................................................. 21

8. Defining a Property (PropertyDef) ....................................................................................................... 22

What is a Property? ............................................................................................................................... 22
What is a PropertyDef? ......................................................................................................................... 22
"Scoping" a PropertyDef ....................................................................................................................... 22
Scoping Examples ................................................................................................................................ 23
Scoping Types ...................................................................................................................................... 23
InterfaceDef / PropertyDef Redux ......................................................................................................... 24

9. Defining a Class (ClassDef) .................................................................................................................. 26

Idea of Instance ..................................................................................................................................... 26
Object Identity ....................................................................................................................................... 26
Model Definitions (ModelDef) ................................................................................................................ 27
It's Nice to Share (Objects) ................................................................................................................... 27
Sharing Allows Changes ....................................................................................................................... 27
The SameAs Relationship .................................................................................................................... 27
Shared object definition (SharedObjDef) .............................................................................................. 28

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

Enumerated Values (EnumEnum) ........................................................................................................ 29
Enumerated Lists of Values .................................................................................................................. 29
Enumerated Lists (EnumListType) ........................................................................................................ 30
Varying Strengths of Enumerated Lists ................................................................................................ 30
Properties can be Scoped by Enumerated Lists ................................................................................... 30
EnumEnum Short-Text and Long-Text ................................................................................................. 31
Multiple-level Enumerated Lists (EnumListType) ................................................................................. 31

A Gentle Introduction to SmartPlant Schema viii

 Hierarchical Levels ................................................................................................................................ 33
Linking Enumerated Values to Interface Definitions (EnumMetadata) ................................................. 35

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

Units of Measure (UoMListType) .......................................................................................................... 36
Unit of Measure (UoMEnum) ................................................................................................................ 36
SI Unit.................................................................................................................................................... 37
Default SI Unit (HasDefaultSI) .............................................................................................................. 38
Units of Measure Conditions ................................................................................................................. 38
"Any" UoM (AnyUoM) List ..................................................................................................................... 39

12. The Implies Relationship (Inheritance) ............................................................................................. 40

Property Inheritance .............................................................................................................................. 41
Implies is a Transitive Relation ............................................................................................................. 41
Conversations re: Dog, Wolf, Mammal and Animal .............................................................................. 41
"Things that have Legs" ........................................................................................................................ 41
"Implies" and Relationship Inheritance ................................................................................................. 42
"Optional" vs. "Required" Implies .......................................................................................................... 43

13. The Realizes Relationship .................................................................................................................. 44

The Realizes Relationship .................................................................................................................... 44
The "Primary" Interface ......................................................................................................................... 44

14. Defining a Relationship (RelDef, Rel) ................................................................................................ 46

The Relationship Definition (RelDef) ..................................................................................................... 46
A Data Modeler Defines Marriage (hoo-boy!) ....................................................................................... 46
A Data Modeler Thinks About RelDefs ................................................................................................. 46
A Guru Ponders Marriage ..................................................................................................................... 47
"Abstract" Relationship Definitions ........................................................................................................ 48
Introduction to Delete Propagation Semantics ..................................................................................... 49
"Concrete" Relationship Definitions ...................................................................................................... 50
Invitation to a Wedding (Example of a Rel)........................................................................................... 50
Introduction to Cardinality ..................................................................................................................... 50
Which RelDef is Right for Me? .............................................................................................................. 51
Locality of Reference ............................................................................................................................ 51
Shared Objects and Locality of Reference ........................................................................................... 52

15. Unique Identifiers (UIDs) ..................................................................................................................... 54

16. Edges, Graphs, & Views (EdgeDef, GraphDef, ViewDef) ................................................................. 55

Edge Definition (EdgeDef) .................................................................................................................... 55
Graph Definition (DirectedGraphDef) .................................................................................................... 58
Technical Details of Graph Definition (DirectedGraphDef) ................................................................... 59
View Definition (ViewDef)...................................................................................................................... 59

17. UML Concepts (Elaboration) .............................................................................................................. 61

The Most Important Concepts of the SmartPlant schema Data Model ................................................ 61
Interface Polymorphism ........................................................................................................................ 62
Reasons for using Interfaces ................................................................................................................ 63

18. Examples of Class and Interface Models .......................................................................................... 64

Another Example of an Interface Relationship Model ........................................................................... 65

A Gentle Introduction to SmartPlant Schema ix

 Example of the RelDef Labeled "Children" ........................................................................................... 65
Review of RelDef .................................................................................................................................. 66

19. The SmartPlant "Meta Schema" ......................................................................................................... 67

Technical Description of the SmartPlant Meta Schema ....................................................................... 67
Relationships between Schema Elements............................................................................................ 68
Informal Rules ....................................................................................................................................... 68
The SmartPlant Schema Editor ............................................................................................................ 68
More Powerful than a Speeding Bullet?................................................................................................ 69

20. SmartPlant schema Files .................................................................................................................... 70

Component Schemas (CompSchema) ................................................................................................. 71
A Shared Pipeline ................................................................................................................................. 73
Existing Component Schemas .............................................................................................................. 74
Technical Description of Component Schemas .................................................................................... 74

21. XML Files Overview ............................................................................................................................. 76

SPF Documents are in XML Format ..................................................................................................... 76
SmartPlant schema Helps Organize XML Files .................................................................................... 76

22. Patterns ................................................................................................................................................ 78

Example of a Real-World Model ........................................................................................................... 78
Review of Class, Interface, Property, and Relation .............................................................................. 78
SmartPlant schema Complexity Breakdown ......................................................................................... 79
Vessel/Nozzle/Pipe run Drawing ........................................................................................................... 79
An Object Diagram ................................................................................................................................ 79
Excerpt from the SmartPlant schema ................................................................................................... 80
Sample XML file .................................................................................................................................... 81
"Part" vs. "Occurrence" ......................................................................................................................... 82
"Occurrence"................................................................................................................................... 82
"Part" ............................................................................................................................................... 82
Why It's Called 'Part' ....................................................................................................................... 83
Typical Material .............................................................................................................................. 83
Don't Need No Stinkin' Parts .......................................................................................................... 83
Modeling "Part" vs. "Occurrence" ................................................................................................... 84
The Blame Game ........................................................................................................................... 85
Actual Material ................................................................................................................................ 86
Part Roles & Properties .................................................................................................................. 86
Implied Part Roles .......................................................................................................................... 87
Occurrence Roles & Properties ...................................................................................................... 87
Implied Occurrence Roles .............................................................................................................. 88
RelDef Patterns ..................................................................................................................................... 88
Composition relationships ..................................................................................................................... 88
Collection relationships ......................................................................................................................... 89
Plant Breakdown Structure ................................................................................................................... 89
Work Breakdown Structure ................................................................................................................... 89
Naming Conventions ............................................................................................................................. 89

23. SmartPlant Architectural Model ......................................................................................................... 91

The Underlying "Architectural Model" ................................................................................................... 91
Here is the "Facility model" ................................................................................................................... 91
Here is the "Material model".................................................................................................................. 92
Facility and Material Models ................................................................................................................. 92

A Gentle Introduction to SmartPlant Schema x

 Facility and Material Model Summary ................................................................................................... 92

24. Schema "Evolution" ............................................................................................................................ 93

25. Schema Reading Practice................................................................................................................... 94

UML Reading Practice for ClassDefs ................................................................................................... 94
UML Reading Practice for InterfaceDefs ............................................................................................ 101
A Child's Poem .................................................................................................................................... 102

26. Secrets of the SmartPlant schema Master...................................................................................... 103

Model InterfaceDefs First (Data Normalization) .................................................................................. 103
Organizing Lots of Pump Properties ................................................................................................... 104
What's the Spin on Rotating Items? .................................................................................................... 104
The Results of "Normalizing" a Pump ................................................................................................. 105
How Interfaces Help to Tame Polymorphism...................................................................................... 105
Ideas about ClassDefs ........................................................................................................................ 107
Naming ClassDefs .............................................................................................................................. 107
Ideas about Enumerated Lists (including EnumListLevelType) .......................................................... 107
Incomplete Hierarchies ....................................................................................................................... 109
Beating Enumerated Lists into Enumeration Hierarchies ................................................................... 109
Cutting Across the Grain with EnumListLevelType ............................................................................. 109
Scoping with an EnumListLevelType .................................................................................................. 110
The View from the Top of the Mountain .............................................................................................. 113

Appendix A. Rules of Data Normalization ............................................................................................ 114

Appendix B. Linnaean Taxonomic Model ............................................................................................ 115

Summary ............................................................................................................................................. 116

Appendix C. Definitions, Acronyms and Abbreviations ...................................................................... 117

Appendix D. Some Properties of a Pump ............................................................................................. 121

Appendix E. Normalized Properties of a Pump .................................................................................... 129

Appendix F. Piping Component Type Hierarchy .................................................................................. 137

Appendix G. Some UML Diagrams ........................................................................................................ 151

Figures for Chapter 25, "UML Reading Practice for ClassDefs"......................................................... 151
Figures for Chapter 25, "UML Reading Practice for InterfaceDefs" ................................................... 152

Appendix H. Equipment Property Spreadsheets ................................................................................. 158

Appendix I. SmartPlant Meta-Schema Objects..................................................................................... 165

Architecture objects............................................................................................................................. 165
Schema objects ................................................................................................................................... 165
Software objects .................................................................................................................................. 165

Appendix J. SmartPlant Schema Rationale .......................................................................................... 167

Appendix K. The TEST ............................................................................................................................ 168

Index ......................................................................................................................................................... 169

A Gentle Introduction to SmartPlant Schema xi

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 ........................................... 4
Figure 3 Different Views of a Valve ................................................................................ 5
Figure 4 Symbols Representing Human, Man, Woman ............................................... 16
Figure 5 The Symbol for the IMan Interface ................................................................. 17
Figure 6 An InterfaceDef as a Rectangle ..................................................................... 21
Figure 7 An InterfaceDef as a Circle ............................................................................ 21
Figure 8 Sample InterfaceDef, PropertyDef, EnumListType ........................................ 25
Figure 9 The Symbol for a Class Definition (ClassDef) ................................................ 26
Figure 10 Example of Shared Objects.......................................................................... 28
Figure 11 The Symbol for an Enumerated Value (EnumEnum) ................................... 29
Figure 12 The Symbol for an Enumerated List (EnumListType) .................................. 30
Figure 13 The Symbols for a Populated Enumerated List ........................................... 30
Figure 14 Enumerated Lists and Enumerated Entries ................................................. 32
Figure 15 Enumerated List Hierarchy
Figure 16 EnumListLevelType Meta Schema
Figure 17 Units of Measure Example ........................................................................... 36
Figure 18 A Taxonomy of a Dog................................................................................... 40
Figure 19 A Dog Realizes that It's a Wolf, too .............................................................. 44
Figure 20 A Relationship Between Man and Woman................................................... 46
Figure 21 RelDef Model ................................................................................................ 51
Figure 22 Vessel with Nozzles (Conceptual) ................................................................ 56
Figure 23 Vessel with Nozzles (SmartPlant schema) .................................................. 57
Figure 24 EdgeDef Example of Numeric Position ........................................................ 58
Figure 25 EdgeDef Example of Property Comparison ................................................. 58
Figure 26 Sample of a Directed Graph ......................................................................... 59
Figure 27 ViewDef ........................................................................................................ 60
Figure 28 Class Diagram for MAN................................................................................ 64
Figure 29 Class Diagram for WOMAN ......................................................................... 65
Figure 30 the Mother-Son Relationship ........................................................................ 65
Figure 31 Types of SmartPlant schema Files .............................................................. 70
Figure 32 Classes That Are in the P&ID Component ................................................... 72
Figure 33 A Shared Pipeline......................................................................................... 73
Figure 34 Vessel/Nozzle/Pipe run from P&ID Drawing ................................................ 79
Figure 35 An Object Diagram of Vessel/Nozzle/Pipe run............................................. 80
Figure 36 Vessel/Nozzle/Pipe run in SmartPlant schema............................................ 80
Figure 37 Pattern for "Part" and "Occurrence" ............................................................. 84
Figure 38 Properties of an Equipment-as-a-Part.......................................................... 86
Figure 39 Properties of Equipment-as-an-Occurrence................................................. 87
Figure 40 A 1/2 HP Pump........................................................................................... 103
Figure 41 Classes that are Polymorphic with respect to IRotatingItem...................... 106
Figure 42 Top-level of Instrument Type Hierarchy ..................................................... 107
Figure 43 Second-level of Instrument Type Hierarchy ............................................... 108
Figure 44 Leaf-nodes in the Instrument Type Hierarchy ............................................ 108
Figure 45 "IPipingComponent" InterfaceDef .............................................................. 109
Figure 46 Hierarchical Dependence for Piping Component Types ............................ 110
Figure 47 3 Levels of Scoping .................................................................................... 112
Figure 48 "IPipingComponent" ................................................................................... 112
Figure 49 Example of Linnaean taxonomic model ..................................................... 116
Figure 66 UML Diagram of EQDFan ......................................................................... 151

A Gentle Introduction to SmartPlant Schema xii

 Figure 67 Interface Diagram 1 - Agitator Part & Occurrence Model .......................... 152
Figure 68 Interface Diagram 2 .................................................................................... 152
Figure 69 Interface Diagram 3 .................................................................................... 153
Figure 70 Interface Diagram 4 .................................................................................... 153
Figure 71 Interface Diagram 5 .................................................................................... 154
Figure 72 Interface Diagram 6 .................................................................................... 154
Figure 73 Interface Diagram 7 .................................................................................... 155
Figure 74 Interface Diagram 8 .................................................................................... 156
Figure 75 Interface Diagram 9 .................................................................................... 157

A Gentle Introduction to SmartPlant Schema xiii

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. Hexagon 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. Hexagon 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 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"

A Gentle Introduction to SmartPlant Schema 1

 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"

A Gentle Introduction to SmartPlant Schema 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 Intergraph Smart® 3D (reference:
http://www.intergraph.com/smartplant/3d/Productivity_Gains_with_SmartPlant_3D.asp).

The Concept of a "Model"

While there are many aspects to the overall "integration" concept, at the heart of it all is a
"data model." Huh? You've heard of models since you were a kid: model airplanes, model
cars, models of people, a.k.a. dolls.

A Gentle Introduction to SmartPlant Schema 3

 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.

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 Gentle Introduction to SmartPlant Schema 4

 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!

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 different SmartPlant products, such as
Smart 3D, SmartPlant Electrical, SmartPlant Foundation, SmartPlant Instrumentation,
SmartPlant P&ID, and so on.

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.

A Gentle Introduction to SmartPlant Schema 5

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

A Gentle Introduction to SmartPlant Schema 6

 * 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, 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!"

A Gentle Introduction to SmartPlant Schema 7

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

A Gentle Introduction to SmartPlant Schema 8

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

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.

A Gentle Introduction to SmartPlant Schema 9

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

A Gentle Introduction to SmartPlant Schema 10

 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 Hexagon PPM
- etc.

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

A Gentle Introduction to SmartPlant Schema 11

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

A Gentle Introduction to SmartPlant Schema 12

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 Officer Smith? 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 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."

A Gentle Introduction to SmartPlant Schema 13

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.

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.

A Gentle Introduction to SmartPlant Schema 14

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.

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"

A Gentle Introduction to SmartPlant Schema 15

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

A Gentle Introduction to SmartPlant Schema 16

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

A Gentle Introduction to SmartPlant Schema 17

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

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

A Gentle Introduction to SmartPlant Schema 18

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.

A Gentle Introduction to SmartPlant Schema 19

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.

The "InterfaceDef" class definition realizes the "IInterfaceRole" interface definition.

This interface definition exposes two properties: "SpecializationValue" and
"InterfaceIcon".
"SpecializationValue" is an integer property that indicates how specialized the role for the
interface is. The higher the "SpecializationValue" the more specialized the role.
For interface definitions that have a corresponding icon, the "InterfaceIcon" property
identifies the name of this icon.

Figure 6. IInterfaceRole Interface Definition

The combination of "SpecializationValue" and "InterfaceIcon" can be used to determine the

most specialized icon for an object.

A Gentle Introduction to SmartPlant Schema 20

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 7 An InterfaceDef as a Rectangle

Figure 8 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.

A Gentle Introduction to SmartPlant Schema 21

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:

- Inlet Size
- Maximum Flow rate
- Material of construction
- Orientation-angle
- Description of the valve
- etc.

A Gentle Introduction to SmartPlant Schema 22

 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, ...}
 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"?

A Gentle Introduction to SmartPlant Schema 23

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

A Gentle Introduction to SmartPlant Schema 24

 Figure 9 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.

A Gentle Introduction to SmartPlant Schema 25

9. Defining a Class (ClassDef)

Figure 10 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 entire schema gets a UID - everything. All relationships
are then formed between two UIDs.

A Gentle Introduction to SmartPlant Schema 26

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

A Gentle Introduction to SmartPlant Schema 27

Shared object definition (SharedObjDef)
A "SharedObjDef" class allows a "Shared Object" to be created in the user-data file.
Shared objects may be modified by more than one user, which is why they are called shared.
For example, the flow-rate of a "shared" valve may be set by the PFD application and then
modified by the P&ID application.

Figure 11 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".

A Gentle Introduction to SmartPlant Schema 28

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

Figure 12 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 Hexagon PPM, we established a SmartPlant schema Control Board
(CCB), plus a separate Enumerated List Change Control Board to help control the
consequences of changes to enumerated lists.

A Gentle Introduction to SmartPlant Schema 29

Enumerated Lists (EnumListType)

Figure 13 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 14 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 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.

A Gentle Introduction to SmartPlant Schema 30

 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 enumerated lists and enumerated
entries. However, I'd skip it if it's late in the afternoon.

A Gentle Introduction to SmartPlant Schema 31

 Figure 15 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 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.

A Gentle Introduction to SmartPlant Schema 32

Hierarchical Levels
While the topmost node and each of the branch nodes in an enumerated list hierarchy are
enumerated lists, the requirement exists to treat all of the enumerated lists and
enumerated entries at a given hierarchical level as an enumerated list.
In the following hierarchy, the topmost node is A. The second level in the hierarchy
consists of three nodes: A.1, A.2, and A.3. These enumerated lists are the enumerated
entries for enumerated list A. Enumerated list A.1 contains enumerated entries A.1.1 and
A.1.2, enumerated list A.2 contains enumerated entries A.2.1, A.2.2, and A.2.3, and
enumerated list A.3 contains enumerated entries A.3.1 and A.3.2.

Figure 15. Enumerated List Hierarchy

Enumerated list A could be the property type for property TypeOfA, enumerated list A.1
could be the property type for property TypeOfA.1, enumerated list A.2 could be the
property type for property TypeIOfA.2, and enumerated list A.3 could be the property
type for property TypeOfA.3.
However, what if the need exists to know the subtype of A (that is, the type of the type of
A). For this case the possible values are A.1.1, A.1.2, A.2.1, A.2.2, A.2.3, A.3.1, and A.3.2. In
other words the possible values for the property SubtypeOfA are all the leaf nodes at the
lowest level of this hierarchy.
The requirement to treat entire levels of a hierarchy as a property type rather than
treating each of the branch nodes as a property type is a common one. Many tools do not
deal with the specialized role (interface) that would expose the specific property
associated with a branch node but rather deal with just an overall type definition. For
example, many tools may want to type an equipment object as a centrifugal pump but far
fewer tools would want to support the pump role (IPump interface) associated with this
branch node. Therefore, most tools would want EquipmentType1, EquipmentType2 (i.e.,
EquipmentSubtype), etc. properties rather than the more specific EquipmentType,
MaterialHandlingEquipmentType, FluidTransferMachineType, PumpType, etc. properties.
To handle properties based on enumerated list hierarchical level, the EnumListLevelType
class definition has been added to the SmartPlant schema. The UML for this class
definition is shown in Figure 16, which follows.

A Gentle Introduction to SmartPlant Schema 33

 Figure 16. EnumListLevelType Meta Schema
This class definition realizes "IPropertyType" and is therefore a valid property type for
scoping property definitions (e.g., subtype properties). This class definition also supports
"IEnumListType", which means that it supports the behavior associated with enumerated
lists. However, it does not support "IEnumEnum" and is therefore not a valid enumerated
entry.
The "IEnumListLevelType" interface definition has a "BaseEnumListForEnumLevel"
relationship definition to the "IEnumListType" interface definition. This relationship
definition is used to identify the enumerated list that is the starting point for the
enumerated list level. For the hierarchy described earlier, the starting enumerated list
would be, e.g., "A".
The "IEnumListLevelType" interface definition has an "EdgeDefForEnumLevel" relationship
definition to "IEdgeDef". This relationship definition is used to identify the edge definition
that applies to the enumerated list level property type. This edge definition will have a
starting interface definition of "IEnumListType" and will traverse the Contains relationship
a minimum of two times.

A Gentle Introduction to SmartPlant Schema 34

 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, 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."

A Gentle Introduction to SmartPlant Schema 35

11. Defining Units of Measure
(UoMEnum, UoMListType)

Units of Measure (UoMListType)

Figure 16 Units of Measure Example

Figure 17 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.

A Gentle Introduction to SmartPlant Schema 36

 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 (y) is determined by multiplying the SI value (x) by A, and
then B is added to that value to determine the converted value (y = Ax + B). Alternatively,
the SI value (x) can be determined by dividing the given value (y) by A, and subtracting B (x
= (y –B) / A).

A Gentle Introduction to SmartPlant Schema 37

Default SI Unit (HasDefaultSI)
Also note in Figure 17 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.

A Gentle Introduction to SmartPlant Schema 38

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

A Gentle Introduction to SmartPlant Schema 39

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 18 A Taxonomy of a Dog

Figure 18 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 its existence

A Gentle Introduction to SmartPlant Schema 40

 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. 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 18 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?"

"Things that have Legs"

Look at Figure 18 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

A Gentle Introduction to SmartPlant Schema 41

  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 18: 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.

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

A Gentle Introduction to SmartPlant Schema 42

"Optional" vs. "Required" Implies
Looking at Figure 18, 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).

A Gentle Introduction to SmartPlant Schema 43

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 19, below:

Figure 19 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" 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".

A Gentle Introduction to SmartPlant Schema 44

  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!

A Gentle Introduction to SmartPlant Schema 45

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 20 A Relationship Between Man and Woman

Figure 20 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 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."

A Gentle Introduction to SmartPlant Schema 46

  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 20, 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 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

A Gentle Introduction to SmartPlant Schema 47

 (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 61. 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
 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:

A Gentle Introduction to SmartPlant Schema 48

  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!

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.

A Gentle Introduction to SmartPlant Schema 49

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

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.

A Gentle Introduction to SmartPlant Schema 50

 In the properties listed above, you can see that the definition of a relationship is a very
complex topic. The "contract" between InterfaceDefs 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 21 RelDef Model

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.

A Gentle Introduction to SmartPlant Schema 51

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

A Gentle Introduction to SmartPlant Schema 52

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

A Gentle Introduction to SmartPlant Schema 53

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.

A Gentle Introduction to SmartPlant Schema 54

16. Edges, Graphs, & Views (EdgeDef,
GraphDef, ViewDef)

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

A Gentle Introduction to SmartPlant Schema 55

 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:

Figure 22 Vessel with Nozzles (Conceptual)

The SmartPlant schema for that looks like this:

A Gentle Introduction to SmartPlant Schema 56

 Figure 23 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:

 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 24 shows an EdgeDef that uses a numeric position property:

A Gentle Introduction to SmartPlant Schema 57

 Figure 24 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 25 is an example that lets you specify a property value, instead of a numeric
position to make your EdgeDef useful:

Figure 25 EdgeDef Example of Property Comparison

 This is the SmartPlant schema EdgeDef named "StreamNormalCase"

 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

A Gentle Introduction to SmartPlant Schema 58

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

A Gentle Introduction to SmartPlant Schema 59

 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 27 ViewDef

(Sorry, I bet that this chapter wore you out.)

A Gentle Introduction to SmartPlant Schema 60

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 “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?

A Gentle Introduction to SmartPlant Schema 61

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

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.

A Gentle Introduction to SmartPlant Schema 62

 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 Smart 3D 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

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)

A Gentle Introduction to SmartPlant Schema 63

18. Examples of Class and Interface
Models

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

A Gentle Introduction to SmartPlant Schema 64

 Figure 18 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 19 the Mother-Son Relationship

A Gentle Introduction to SmartPlant Schema 65

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

A Gentle Introduction to SmartPlant Schema 66

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.

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.

A Gentle Introduction to SmartPlant Schema 67

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.

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.

A Gentle Introduction to SmartPlant Schema 68

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

A Gentle Introduction to SmartPlant Schema 69

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 31 Types of SmartPlant schema Files

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

A Gentle Introduction to SmartPlant Schema 70

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.

A Gentle Introduction to SmartPlant Schema 71

 Figure 32 Classes That Are in the P&ID Component

A Gentle Introduction to SmartPlant Schema 72

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

Figure 20 A Shared Pipeline

Figure 33 (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 Smart 3D. 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 the
shared roles can be modified by any of the tools that publish those classes.

A Gentle Introduction to SmartPlant Schema 73

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 - Smart 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 Smart 3D 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
 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.

A Gentle Introduction to SmartPlant Schema 74

 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.

A Gentle Introduction to SmartPlant Schema 75

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.

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.

A Gentle Introduction to SmartPlant Schema 76

 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.

A Gentle Introduction to SmartPlant Schema 77

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

36, 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 36, 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.

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

A Gentle Introduction to SmartPlant Schema 78

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 34 shows a simple P&ID drawing consisting of a
vessel/nozzle/pipe run. Figure 35 transforms Figure 34 to an Object Diagram conforming
to the SmartPlant schema. Finally, Figure 36 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 34 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 34 Vessel/Nozzle/Pipe run from P&ID Drawing

An Object Diagram
The Object Diagram shown in Figure 35, 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.

A Gentle Introduction to SmartPlant Schema 79

 Figure 35 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 36 Vessel/Nozzle/Pipe run in SmartPlant schema

Figure 36 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 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.

A Gentle Introduction to SmartPlant Schema 80

Sample XML file
A total of seven objects will be published: four objects and three relationships.

<EQDProcessVessel>
<IObject UID=”123” Name=”V-101”/>
<IProcessVesselOcc .../>
<IProcessVessel VolumeRating=”250”…/>
<IEquipmentOcc … />
<IEquipment ... />
</EQDProcessVessel>
<EQDNozzle>
<IObject UID=”234” Name=”N1”/>
<INozzleOcc .../>
<INozzle NozzleType="??" />
<IEquipmentComponentOcc … />
<IEquipmentComponent .../>
</EQDNozzle>
<EQDPipingConnector>
<IUID UID=”678” Name=””/>
<IPipingConnector …/>
<IConnector EstimatedLength="15.0 ft" .../>
</EQDPipingConnector >
<EQDPipingPort>
<IUID UID=”345”/>
</EQDPipingPort>
<Rel>
<IUID UID=”Relationship_123_234”/>
<IRel UID1=”123” UID2=”234” DefUID=”EquipmentPartComposition”
</Rel>
<Rel>
<IUID UID=”Relationship_234_456”/>
<IRel UID1=”234” UID2=”456” DefUID=”PipingPortComposition”
</Rel>
<Rel>
<IUID UID=”Relationship_234_678”/>
<IRel UID1=”234” UID2=”678” DefUID=”PipingEnd1Conn”
</Rel>

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

A Gentle Introduction to SmartPlant Schema 81

"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 67 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 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

A Gentle Introduction to SmartPlant Schema 82

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

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

A Gentle Introduction to SmartPlant Schema 83

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

Figure 37 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 ???

A Gentle Introduction to SmartPlant Schema 84

 Looking at Figure 37: 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".

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

A Gentle Introduction to SmartPlant Schema 85

  Add new interfaces to the model (are there new roles?)
 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 38, below. It shows properties that are on an "equipment-as-a-part", viz.,
"IEquipment".

Figure 38 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.

A Gentle Introduction to SmartPlant Schema 86

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 39, below. It shows properties that are on an "equipment-as-an-occurrence",
viz., "IEquipmentOcc".

Figure 39 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 is a "part"); therefore "IEquipmentOcc" can realize that it is "sloped", but
"IEquipment" can not.

A Gentle Introduction to SmartPlant Schema 87

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.

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 Smart
3D 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 Smart 3D 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."

A Gentle Introduction to SmartPlant Schema 88

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.

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., Smart 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, "EQDStrainer" has a Componentization relationship with
the EquipDataSheet component schema.

A Gentle Introduction to SmartPlant Schema 89

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

A Gentle Introduction to SmartPlant Schema 90

 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 that you can put your hand
on; it just evolves into something that fulfills its requirements.

A Gentle Introduction to SmartPlant Schema 91

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!

A Gentle Introduction to SmartPlant Schema 92

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.

The SmartPlant Schema Editor User’s Guide contains a section that describes the rules of
schema evolution, rule enforcement and modification, and information on all object types,
definitions, lists, and entries. For detailed information on schema evolution concepts and
rules, see “SmartPlant Schema Modification Rules” in the SmartPlant Schema Editor User’s
Guide.

A Gentle Introduction to SmartPlant Schema 93

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

It Realizes 46 roles:

Category Interface
Behavior IDifferentialTemperatureItem
Behavior IRotatingItem

A Gentle Introduction to SmartPlant Schema 94

 Category Interface
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
Weight & COG ICOGItem
Weight & COG ISolidItem
Weight & COG IWeightItem

A Gentle Introduction to SmartPlant Schema 95

 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
DesignCriteriaFluidState FluidPhases
DesignCriteriaMassFlowRate MassFlowUoM
DesignCriteriaMetalTemperature TemperatureUoM
DesignCriteriaPower PowerUoM
DesignCriteriaPressure PressureUoM

A Gentle Introduction to SmartPlant Schema 96

 Property Type
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
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

A Gentle Introduction to SmartPlant Schema 97

 Property Type
Global_Dry_Installed_CoG_Z LengthUoM
Global_Dry_Stripped_CoG_X LengthUoM
Global_Dry_Stripped_CoG_Y LengthUoM
Global_Dry_Stripped_CoG_Z LengthUoM
Global_Test_CoG_X LengthUoM
Global_Test_CoG_Y LengthUoM
Global_Test_CoG_Z LengthUoM
Global_Wet_Operating_CoG_X LengthUoM
Global_Wet_Operating_CoG_Y LengthUoM
Global_Wet_Operating_CoG_Z LengthUoM
HeightRelativeToGrade LengthUoM
HyperlinkToVendor string
InstallationResponsibility InstallationResponsibilities
InsulatedItem_OperatingTemperature TemperatureUoM
InsulationSurfaceArea AreaUoM
InsulationWeight MassUoM
InsulCompositeMatl InsulCompositeMaterials
InsulPurpose1 InsulPurposes1
InsulPurpose2 InsulPurposes2
InsulPurpose3 InsulPurposes3
InsulSpec string
InsulTemp TemperatureUoM
InsulThickSrc InsulThickSrcs
InteriorSurfaceTreatment InteriorSurfaceTreatments
Local_Design_CoG_X LengthUoM
Local_Design_CoG_Y LengthUoM
Local_Design_CoG_Z LengthUoM
Local_Dry_Installed_CoG_X LengthUoM
Local_Dry_Installed_CoG_Y LengthUoM
Local_Dry_Installed_CoG_Z LengthUoM
Local_Dry_Stripped_CoG_X LengthUoM
Local_Dry_Stripped_CoG_Y LengthUoM
Local_Dry_Stripped_CoG_Z LengthUoM
Local_Test_CoG_X LengthUoM
Local_Test_CoG_Y LengthUoM
Local_Test_CoG_Z LengthUoM
Local_Wet_Operating_CoG_X LengthUoM
Local_Wet_Operating_CoG_Y LengthUoM
Local_Wet_Operating_CoG_Z LengthUoM
LocalizedShortMaterialDescription string
LongMaterialDescription string
Manufacturer ManufacturerIndustryPractice2
ManufacturerIndustryPractice ManufacturerIndustryPractices
ManufacturerModelNumber ManufacturerModels
ManufacturerName ManufacturerNames
Material_DampingCoefficient double

A Gentle Introduction to SmartPlant Schema 98

 Property Type
Material_Density DensityUoM
Material_ElasticModulus ElasticModulusUoM
Material_Emissivity double
Material_MaxCompression double
Material_MaxShear double
Material_MaxTension double
Material_PoissonRatio double
Material_ShearModulus PressureUoM
Material_SpecificHeat SpecificHeatCapacityUoM
Material_ThermalConductivity ThermalConductivityUoM
Material_ThermalExpansionCoefficient double
Material_UltimateStress StressUoM
Material_YieldStress StressUoM
MaterialsCategory MaterialsGradePractice2
MaterialsGrade MaterialsGradePractice3
MaterialsGradePractice MaterialsGradePractices
MaximumAngularVelocity AngularVelocityUoM
MaximumPressureDrop DiffPressUoM
MechanicalEquipment_DistanceBetweenInOut LengthUoM
MechanicalEquipment_OperatingTimePerTime TimePerTimeUoM
MechanicalEquipment_OperationMode MechanicalEquipmentOperatingModes
MinimumPressureDrop DiffPressUoM
MomentumPressureDrop DiffPressUoM
Name string128
NormDesignPressMax PressureUoM
NormDesignPressMin PressureUoM
NormDesignTempMax TemperatureUoM
NormDesignTempMin TemperatureUoM
NumberOfNozzlesRequired int
NumberOfPoles int
OrientationMatrix_x0 double
OrientationMatrix_x1 double
OrientationMatrix_x2 double
OrientationMatrix_y0 double
OrientationMatrix_y1 double
OrientationMatrix_y2 double
OrientationMatrix_z0 double
OrientationMatrix_z1 double
OrientationMatrix_z2 double
PlannedOrientation PlannedOrientations
PressureDrop DiffPressUoM
PressureDrop_Dirty DiffPressUoM
PressureDropLimit DiffPressUoM
PressureDropPercent PercentageUoM
PressureRating PressureRatings
PressureRating2 PressureRatings2

A Gentle Introduction to SmartPlant Schema 99

 Property Type
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
MatlExpansion
NonDrawingItemCollection
OwnsImpliedItems
P3DSystemHierarchy
Part_PartOcc
PBSItemCollection

A Gentle Introduction to SmartPlant Schema 100

 Relationship Name
PBSItemFacilityPoint
PBSItemHasImpliedParts
PBSItemNotes
PBSWBS
PlannedMatlActualization
PlannedMatlConstruction
PlannedMatlProcurement
ProcessDataCaseComposition
ProcessEquipInstrument
ProcessPointCollection
SignalPorts

UML Reading Practice for InterfaceDefs

Let's look at Figures 67 through 75 in Appendix H, to see how the data model of an
"agitator":

 Figure 67 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 68 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 69 continues to develop the "type-ness" of the agitator - it says: "Mixing equipment" is
a type of "Process equipment"
 Figure 70 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 71 says that "an occurrence of mixing equipment" might be a type of process
equipment (an occurrence).
 Figure 72 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 73 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 74 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 75 is the same as Figure 74, but puts emphasis on the fact that the left-side, or "part"
side, carries the "type-ness" of equipment.

A Gentle Introduction to SmartPlant Schema 101

  !!BREAKTIME!!

A Child's Poem
Does 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!)

A Gentle Introduction to SmartPlant Schema 102

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 Mapping, Course Guide", which you
get when you take the course through normal channels at Hexagon
PPM. 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 40 A 1/2 HP Pump

 It is a piece of equipment
 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

A Gentle Introduction to SmartPlant Schema 103

  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:

 Properties of a "rotating item"

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

A Gentle Introduction to SmartPlant Schema 104

 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:

A Gentle Introduction to SmartPlant Schema 105

 Figure 41 Classes that are Polymorphic with respect to IRotatingItem

A Gentle Introduction to SmartPlant Schema 106

 Did I say "simple diagram"!? After looking at Figure 41, 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?

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 Smart 3D probably should
begin with "P3D".

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 41, 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 42 Top-level of Instrument Type Hierarchy

A Gentle Introduction to SmartPlant Schema 107

 The top-level of the instrument hierarchy is easy to understand. Now, let's drill down one-
level.

Figure 43 Second-level of Instrument Type Hierarchy

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 44 Leaf-nodes in the Instrument Type Hierarchy

A Gentle Introduction to SmartPlant Schema 108

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.

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 45 "IPipingComponent" InterfaceDef

A Gentle Introduction to SmartPlant Schema 109

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

These 3 properties will be used as a 3-level list that will classify piping components, i.e.,
 The PropertyDef "PipingComponentType1" will contain values that are at Level-1 (the least-
detailed) of the hierarchy
 The PropertyDef "PipingComponentType2" will contain values that are at Level-2 of the
hierarchy
 The PropertyDef "PipingComponentType3" will contain values that are at Level-3 (the most-
detailed) of the hierarchy

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 46 Hierarchical Dependence for Piping Component Types

A Gentle Introduction to SmartPlant Schema 110

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

A Gentle Introduction to SmartPlant Schema 111

 Figure 47 3 Levels of Scoping

Figure 48 "IPipingComponent"

A Gentle Introduction to SmartPlant Schema 112

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

A Gentle Introduction to SmartPlant Schema 113

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.

A Gentle Introduction to SmartPlant Schema 114

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.

A Gentle Introduction to SmartPlant Schema 115

 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 49 Example of Linnaean taxonomic model

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

A Gentle Introduction to SmartPlant Schema 116

Appendix C. 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, SmartPlant Foundation, and so forth.
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 set of class
schema 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 An XML file that describes the structure of the XML files generated by
schema 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 definition in the
(EnumListType) SmartPlant schema. a.k.a. enumerated sets, pick lists, code lists, and lookups
Enumerated A member of an enumerated set that defines one possible value for a property in
value the SmartPlant schema. Enumerated values are sometimes called enumerated
(EnumEnum) entries.
GraphDef A connected network of edge definitions with structure. Each graph 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 A SmartPlant schema element that defines an Interface.

A Gentle Introduction to SmartPlant Schema 117

 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, and so forth.
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 The composition of the plant based on the grouping of physical objects by their
breakdown function in the plant. The plant usually occupies the top level of the hierarchy
structure (PBS) 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 Defines the set of possible roles for a ClassDef, and should imply everything that
interface 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
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 A 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, which allows you to create, delete, or modify items
at the appropriate time in the design process.
Schema A diagrammatic representation, an outline, or a model.

A Gentle Introduction to SmartPlant Schema 118

 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 surrounding the
component 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 selected when the user defined the
value in the authoring tool.
SP3D Smart 3D
SPEL SmartPlant Electrical
SmartPlant A suite of integrated engineering applications delivered together, whose purpose
Enterprise is the total information of a large facility, e.g., process plant, ship, etc.
SmartPlant The underlying software framework that allows SmartPlant tools to integrate.
Foundation Provides database, rules, document management, etc.
(SPF)
SmartPlant SmartPlant integration standardizes and improves the communication among
Integration 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 The composition of the plant based on the construction work to be completed.
breakdown The plant usually occupies the top level of the hierarchy; it is typically followed
structure by projects, contracts, and documents.
(WBS)

A Gentle Introduction to SmartPlant Schema 119

 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.

A Gentle Introduction to SmartPlant Schema 120

Appendix D. Some Properties of a Pump

Prop # Property Type

1 Pump_CoolingWaterPlan eCoolingWaterPlan
2 Pump_SealFlushPipingPlanDescription eSealFlushPipingPlan_API610
3 FluidTransferMachine_DifferentialPressure DiffPressUoM
4 FluidTransferMachine_RatedPower PowerUoM
5 FluidTransferMachine_Capacity VolumetricFlowUoM
6 EqType0 EqTypes0
7 EqType1 EqTypes1
8 EqType2 EqTypes2
9 EqType3 EqTypes3
10 EqType4 EqTypes4
11 EqType5 EqTypes5
12 EqType6 EqTypes6
13 EqTypeDescription string
14 EquipmentTrimSpec string
15 NumberOfNozzlesRequired int
16 SteamJacketPressure PressureUoM
17 Jacket_CleaningRqmt CleaningRqmts
18 Jacket_CleaningResponsibility CleaningResponsibilities
19 Jacket_CoatingRequirement CoatingReq1
20 Jacket_CoatingType CoatingReq2
21 Jacket_ExteriorSurfaceTreatment ExteriorSurfaceTreatments
22 Jacket_InteriorSurfaceTreatment InteriorSurfaceTreatments
23 Jacket_CoatingColor CoatingColors
24 Jacket_CorrosionAllowance LengthUoM
25 Jacket_FlowDirection FlowDirections
26 Jacket_FluidSystem FluidSystems
27 Jacket_AvgInsulDens DensityUoM
28 Jacket_InsulCompositeMatl InsulCompositeMaterials
29 Jacket_InsulPurpose1 InsulPurposes1
30 Jacket_InsulPurpose2 InsulPurposes2
31 Jacket_InsulPurpose3 InsulPurposes3
32 Jacket_InsulSpec string
33 Jacket_InsulTemp TemperatureUoM
34 Jacket_InsulThickSrc InsulThickSrcs
35 Jacket_TotalInsulThick LengthUoM
36 Jacket_OperatingTemperature TemperatureUoM
37 Jacket_InsulationSurfaceArea AreaUoM
38 Jacket_InsulationWeight MassUoM
39 Jacket_ItemTag string
40 Jacket_ItemTagSequenceNumber string
41 Jacket_ItemTagSuffix string
42 Jacket_SteamOutPressure PressureUoM

A Gentle Introduction to SmartPlant Schema 121

 Prop # Property Type
43 Jacket_SteamoutReq SteamOutReqs
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

A Gentle Introduction to SmartPlant Schema 122

 Prop # Property Type
90 Local_Wet_Operating_CoG_Z LengthUoM
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

A Gentle Introduction to SmartPlant Schema 123

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

A Gentle Introduction to SmartPlant Schema 124

 Prop # Property Type
184 LocalAlarmRequired boolean
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

A Gentle Introduction to SmartPlant Schema 125

 Prop # Property Type
231 TestingMinTemp TemperatureUoM
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

A Gentle Introduction to SmartPlant Schema 126

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

A Gentle Introduction to SmartPlant Schema 127

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

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

A Gentle Introduction to SmartPlant Schema 128

Appendix E. 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

A Gentle Introduction to SmartPlant Schema 129

 Interface Property
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
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

A Gentle Introduction to SmartPlant Schema 130

 Interface Property
IElecPowerConsumer ConsumedActiveLoad
IEquipment EqType1
IEquipment EqType3
IEquipment EqType2
IEquipment EqType0
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

A Gentle Introduction to SmartPlant Schema 131

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

A Gentle Introduction to SmartPlant Schema 132

 Interface Property
ILocatedItem Longitude
ILocatedItem LocationZ
ILocatedItem LocationY
ILocatedItem LocationX
ILubricatedItem LubricationRequirement
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

A Gentle Introduction to SmartPlant Schema 133

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

A Gentle Introduction to SmartPlant Schema 134

 Interface Property
IProcessWettedItem FluidServiceCategory
IProcessWettedItem TemperatureRating
IProcessWettedItem CorrosionAllowance
IProcessWettedItem FluidServiceCategory2
IPump Pump_SealFlushPipingPlanDescription
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

A Gentle Introduction to SmartPlant Schema 135

 Interface Property
IWBSItem WBSItemType
IWBSItem WBSItemPurpose
IWBSItemCollection
IWeightItem Dry_Stripped_Weight
IWeightItem TestWeight
IWeightItem DesignWeight
IWeightItem Wet_Operating_Weight
IWeightItem Dry_Installed_Weight

Pump properties have been "Normalized"

A Gentle Introduction to SmartPlant Schema 136

Appendix F. 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
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
Branches
Drip ring tees TDR
EOLLR
Elbolets
EPIPET
CPLH
Endolets
FOLHC
X
Full-size crosses
XBA
L90YB
Full-size laterals
LAT

A Gentle Introduction to SmartPlant Schema 137

 Level 1 Level 2 Level 3
Drop Tee
Long turn Tee
S90YB
Supply and return Tee
T
TBA
Tee with offset
Full-size tees 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

A Gentle Introduction to SmartPlant Schema 138

 Level 1 Level 2 Level 3
Reducing true Y
Reducing wyes
Reducing wye
RPAD
Reinforcing pads
RPAD2
RWELD
Reinforcing welds
RWELD2
45 degree Y
Long turn Y
Wyes
WYE
Y
11.25 degree direction change E11
15 degree direction change E15
22.5 degree direction change E22
30 degree direction change E30
E45
E453D
E45L
E45LR
E45LT
45 degree direction change E45M1
E45M2
E45M3
E45S
E45ST
E45U
E903DT
45-90 degree direction change
E90LRT
5.625 degree direction change E5
60 degree direction change E60
88 degree direction change E88
90 degree elbow with inlet
Direction-change
fitting 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
90 degree direction change E90LR
E90LT
E90M1
E90M2
E90M3
E90M4
E90M5
E90S
E90SR
E90ST
E90SW
E90TC

A Gentle Introduction to SmartPlant Schema 139

 Level 1 Level 2 Level 3
E90U
E90R
90 degree reducing direction change
E90RST
Double 90 degree direction change 90 degree double elbow
E453DT
Less than 45 degree direction change
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
Adapter, drop (tubing)
Adapter, flush (tubing)
Adapter, hose (tubing)
In-Line Fittings Adapters Adapter, soil pipe (tubing)
Adapter, trap (tubing)
Adapter, tubing
ADPT01

A Gentle Introduction to SmartPlant Schema 140

 Level 1 Level 2 Level 3
ADPT02
ADPT03
ADPT04
ADPT05
ADPT06
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
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
Couplings and connectors
Coupling, flanged adapter
Coupling, hanger
Coupling, repair
Coupling, transition
Coupling, Victaulic
CPL
CPL45E
CPLBAY
CPLCOM
CPLFJ
CPLFLE
CPLM1
CPLTAN
CPLVIPS
Dresser coupling
HC

A Gentle Introduction to SmartPlant Schema 141

 Level 1 Level 2 Level 3
HIFVCPL
SLV
SWBRTL
SWFFQCB
SWFFQCS
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
Orifice flanges FOSW
FOTHD

A Gentle Introduction to SmartPlant Schema 142

 Level 1 Level 2 Level 3
FOWN
Orifice Plates Orifice plate
Orifice spacers ORFSPA
Orifice spacers ORSPA
FPL
Plate flanges
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
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
Piping specialty
Flame check, low pressure
Flame trap assembly
Blank disc
Blind flange
Blinds
Paddle blind
Spectacle blind
Sample cooler
Sample cooler, high pressure
Coolers Sample cooler, low pressure
Sampler, fixed volume liquid
Sampler, in-line

A Gentle Introduction to SmartPlant Schema 143

 Level 1 Level 2 Level 3
SLRMOB
SLRPNOB
Couplings
Exhaust heads Exhaust head
EJCLSH
EJEPB
EJEXPR
EJFAB
EJGIM
EJINLPB
EJRECT
EJREFL
Expansion joint 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

A Gentle Introduction to SmartPlant Schema 144

 Level 1 Level 2 Level 3
Ball float liquid drainer
Ball float steam trap
Bellows steam trap
Controlled disc steam trap
Fixed temperature discharge trap
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
Strainer Perforated cone strainer
Permanent line strainer
Sanitary strainer
Single basket strainer
Sludge shoe
Suction strainer or Suction diffuser
Sump strainer
T strainer
Tank suction strainer
Tee-type assembly angle pattern strainer
Tee-type assembly straight thru pattern strainer
Temporary cone strainer
Temporary strainer

A Gentle Introduction to SmartPlant Schema 145

 Level 1 Level 2 Level 3
Truncated cone strainer (perforated basket strainer)
Y strainer
Ejector
Injector
Suction tees and ejectors Mixing tee
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
3-way generic body valve
3-way solenoid valve
3WRV1
BAL3W
CK3W
3-way valves
CKST3W
DIA3W
GLO3W
PLU3W
SLI3W
Valves 3-way valves flow-directional CKAR
4-way generic body valve
4-way solenoid valve
4WRV1
4-way valves BAL4W
CK4W
DIA4W
PLU4W
BAL5W
5-way valves CK5W
DIA5W

A Gentle Introduction to SmartPlant Schema 146

 Level 1 Level 2 Level 3
GENB5W
PLU5W
SOL5W
GENB6W
6-way valves PLU6W
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
BFYDF
BFYDFDE
BFYDFL
BFYDFS
BFYHP
BFYLP
BFYLUG
Linear Flow Directional Valves
BFYLUGDE
BFYTE
BFYWF
BFYWFDE
BFYWFL
BFYWFS
BFYWFSFL

A Gentle Introduction to SmartPlant Schema 147

 Level 1 Level 2 Level 3
BFYWFSFS
BWV
CKBAL
CKBP
CKHL
CKLR
CKLRY
CKPI
CKS
CKSPS
CKSR
CKSSP
CKST
CKTD
CKVL
CKWF
CKYST
FOOT
BALF
BALFLO
BALL
Ball valve, temperature blowdown automated
BALLP
BALR
BALSP
BDY
DIA
FLO
GAT
GATBL
GATCON
GATEX
GATF
GATPS
GATPSLI
Linear Valves 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

A Gentle Introduction to SmartPlant Schema 148

 Level 1 Level 2 Level 3
PIN
PLU
PLUPB
PLUSP
PLUVP
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

A Gentle Introduction to SmartPlant Schema 149

 The 3-Level Enumerated List Named "PipingComponentTypes1"

A Gentle Introduction to SmartPlant Schema 150

Appendix G. Some UML Diagrams

Figures for Chapter 25, "UML Reading Practice for

ClassDefs"

Figure 66 UML Diagram of EQDFan

A Gentle Introduction to SmartPlant Schema 151

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

Figure 67 Interface Diagram 1 - Agitator Part & Occurrence Model

Figure 68 Interface Diagram 2

A Gentle Introduction to SmartPlant Schema 152

 Figure 69 Interface Diagram 3

Figure 70 Interface Diagram 4

A Gentle Introduction to SmartPlant Schema 153

 Figure 71 Interface Diagram 5

Figure 72 Interface Diagram 6

A Gentle Introduction to SmartPlant Schema 154

 Figure 73 Interface Diagram 7

A Gentle Introduction to SmartPlant Schema 155

 Figure 74 Interface Diagram 8

A Gentle Introduction to SmartPlant Schema 156

 Figure 75 Interface Diagram 9

A Gentle Introduction to SmartPlant Schema 157

Appendix H. Equipment Property Spreadsheets

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

Category Interface Property

Catalog IPart
Catalog ITypicalMatl
Electrical IElecPowerConsumer AverageActiveLoad
Electrical IElecPowerConsumer ConsumedActiveLoad
Electrical IElecPowerConsumer ConsumedApparentLoad
Electrical IElecPowerConsumer ConsumedReactiveLoad
Electrical IElecPowerConsumer ElecDemandFactor
Electrical IElecPowerConsumer ParticularActiveLoad
Electrical IElecPowerConsumer ParticularApparentLoad
Electrical IElecPowerConsumer ParticularPower
Electrical IElecPowerConsumer ParticularReactiveLoad
Electrical IElecPowerConsumer XCoincidenceFactor
Electrical IElecPowerConsumer YCoincidenceFactor
Electrical IElecPowerConsumer ZCoincidenceFactor
Electrical IElecPowerConsumer ZZCoincidenceFactor
Equipment IEquipment EqType0
Equipment IEquipment EqType1
Equipment IEquipment EqType2
Equipment IEquipment EqType3
Equipment IEquipment EqType4
Equipment IEquipment EqType5
Equipment IEquipment EqType6
Equipment IEquipment EqTypeDescription
Equipment IEquipment EquipmentTrimSpec
Equipment IEquipment NumberOfNozzlesRequired
Equipment IMechanicalEquipment MechanicalEquipment_DistanceBetweenInOut
Equipment IMechanicalEquipment MechanicalEquipment_OperatingTimePerTime
Equipment IMechanicalEquipment MechanicalEquipment_OperationMode
Identification IObject Description
Identification IObject Name
Identification IObject UID
Insulation & Tracing IHeatTracedItem HTraceMediumTemp
Insulation & Tracing IHeatTracedItem HTraceRqmt
Insulation & Tracing IHeatTracedItem HTraceRqmt2
Insulation & Tracing IHeatTracedItem HTraceRqmt3
Insulation & Tracing IHeatTracedItem Tracing_MaxTemperature
Insulation & Tracing IHeatTracedItem Tracing_MinTemperature
Insulation & Tracing IInsulatedItem AvgInsulDens
Insulation & Tracing IInsulatedItem InsulatedItem_OperatingTemperature
Insulation & Tracing IInsulatedItem InsulationSurfaceArea
Insulation & Tracing IInsulatedItem InsulationWeight
Insulation & Tracing IInsulatedItem InsulCompositeMatl

A Gentle Introduction to SmartPlant Schema 158

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

A Gentle Introduction to SmartPlant Schema 159

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

A Gentle Introduction to SmartPlant Schema 160

 Category Interface Property
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
Weight & COG ICOGItem Local_Wet_Operating_CoG_X
Weight & COG ICOGItem Local_Wet_Operating_CoG_Y
Weight & COG ICOGItem Local_Wet_Operating_CoG_Z

A Gentle Introduction to SmartPlant Schema 161

 Category Interface Property
Weight & COG ISolidItem SurfaceArea
Weight & COG ISolidItem VolumetricCapacity
Weight & COG IWeightItem DesignWeight
Weight & COG IWeightItem Dry_Installed_Weight
Weight & COG IWeightItem Dry_Stripped_Weight
Weight & COG IWeightItem TestWeight
Weight & COG IWeightItem Wet_Operating_Weight

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

Category Interface Property

Dimensional & Geometrical I3DRange Range1X
Dimensional & Geometrical I3DRange Range1Y
Dimensional & Geometrical I3DRange Range1Z
Dimensional & Geometrical I3DRange Range2X
Dimensional & Geometrical I3DRange Range2Y
Dimensional & Geometrical I3DRange Range2Z
Dimensional & Geometrical ILocatedItem Lattitude
Dimensional & Geometrical ILocatedItem LocationX
Dimensional & Geometrical ILocatedItem LocationY
Dimensional & Geometrical ILocatedItem LocationZ
Dimensional & Geometrical ILocatedItem Longitude
Dimensional & Geometrical IOrientedItem OrientationMatrix_x0
Dimensional & Geometrical IOrientedItem OrientationMatrix_x1
Dimensional & Geometrical IOrientedItem OrientationMatrix_x2
Dimensional & Geometrical IOrientedItem OrientationMatrix_y0
Dimensional & Geometrical IOrientedItem OrientationMatrix_y1
Dimensional & Geometrical IOrientedItem OrientationMatrix_y2
Dimensional & Geometrical IOrientedItem OrientationMatrix_z0
Dimensional & Geometrical IOrientedItem OrientationMatrix_z1
Dimensional & Geometrical IOrientedItem OrientationMatrix_z2
Dimensional & Geometrical IOrientedItem PlannedOrientation
Equipment IEquipmentOcc SlopedEquipment_Angle
Identification I3DObject SP3D_ApprovalReason
Identification I3DObject SP3D_ApprovalStatus
Identification I3DObject SP3D_DateCreated
Identification I3DObject SP3D_DateLastModified
Identification I3DObject SP3D_UserCreated
Identification I3DObject SP3D_UserLastModified
Identification INamedEquipment EquipPrefix
Identification INamedEquipment EquipSeqNo
Identification INamedEquipment EquipSuff
Identification IPBSItem ConstructionStatus
Identification IPBSItem ConstructionStatus2
Identification IPBSItem HeightRelativeToGrade
Manufacturing, Fabrication, Construction IConstructedItem ConstructionRequirement
Manufacturing, Fabrication, Construction IConstructedItem ConstructionType
Manufacturing, Fabrication, Construction IFabricatedItem FabricatedWeight
Manufacturing, Fabrication, Construction IFabricatedItem FabricationRequirement

A Gentle Introduction to SmartPlant Schema 162

 Category Interface Property
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
Process & Environmental Conditions IAltDgnPoint AltDesignPressMin
Process & Environmental Conditions IAltDgnPoint AltDesignTempMax
Process & Environmental Conditions IAltDgnPoint AltDesignTempMin
Process & Environmental Conditions IAltDgnPoint DesignCriteriaPressure2

A Gentle Introduction to SmartPlant Schema 163

 Category Interface Property
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
IProcessPlantEquipment ProcessPlantEquipment_Height
IProcessPlantEquipment ProcessPlantEquipment_StressRelieving

A Gentle Introduction to SmartPlant Schema 164

Appendix I. 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

A Gentle Introduction to SmartPlant Schema 165

 SoftwareEnumList
SoftwareFactory
SoftwareInterface
SoftwareMethod
SoftwareProperty
TypeLibEF

Tool objects
Tool
ToolSchema
ToolSchemaFile

A Gentle Introduction to SmartPlant Schema 166

Appendix J. 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 it. When
compounded by trying to integrate multiple applications, 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, Hexagon PPM 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," it 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.
Appendix K. 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?

A Gentle Introduction to SmartPlant Schema 168

Index
Abstract, 5, 48, 63 EdgeDef, 55, 56, 57, 58, 59, 117
abstracting classes, 63 Discrimination, or "filtering", 56
ACID principle, 54 NumericPosition, 58
Atomic, 54 path definition, 56
Consistent, 54 Position criteria, 56
Durable, 54 PropComparisons, 58
Isolated, 54 EnumEnum, 29, 30, 32, 36, 67, 109, 117
Actual, 83, 86 long text, 31
short text, 31
Actual material, 86
Enumerated lists, 6
Adapter, iv, 6, 18, 52, 76, 117
Agitator, 101 EnumListLevelType, 31, 109, 110
EnumListType, 30, 32, 36, 67, 109, 117
API, v, 6 open-ended, 30
Architectural Model, 91 EnumMetadata, 35
Cardinality, 50, 117
Exposes, 19, 22, 78
many, 50
maximum, 66 Extensible Markup Language, 76
minimum, 66 Facility model, 82
Catalog, 83 Functionally Significant Item, 82
Class, 19, 20, 26, 61, 62, 64, 65, 66, 78, 80, Graph definition, 55, 58, 59, 60
117 GraphDef, 117
Abstracting, 63 Hierarchy, 117
Class diagram, 19 leaf-node, 108
Class factory, 68 Implies, 40, 41, 78, 85, 117
ClassDef, 19, 26, 44, 47, 61, 67, 68, 71, 74, Inheritance, 42
78, 105, 117 Instance, 26, 44, 48, 50, 62, 66, 118
Naming, 107 Interface, 2, 11, 14, 15, 17, 18, 19, 20, 48,
Sharing, 27 61, 62, 63, 64, 65, 66, 78, 79, 80, 117
Collection, 90 Review, 20
Component Schema, iv, 18, 68, 71, 74, 94, interface definition, 59
117 Interface diagram, 19
Composition, 90
CompSchema, 71 InterfaceDef, 19, 20, 21, 22, 26, 40, 41,
44, 48, 51, 56, 59, 62, 67, 68, 78, 103,
ConditionList, 38
104, 105, 109, 117
Connectivity, 6 EnumMetadata, 35
Conversion, 36 Names begin with the letter "I", 15, 25, 68
dangling relationship, 53 InterfaceIcon, 20
delete propagation, 88, 89 IObject, 26
Denormalization, 14 IPart, 83
design intent, 82 IPipingComponent, 109
DirectedGraphDef, 55, 58, 59 IRotatingItem, 104, 105
Discrimination, 56 join, 59
Document, 6 Link attributes, 66
PBS hierarchy, 89 Linnaean taxonomic model, 8, 9, 10, 15, 40,
ProjectList, 89 42, 107, 115, 116, 118
Edge, 55 Loose integration, iv
Edge definition, 55, 59, 60 Map files, 6

A Gentle Introduction to SmartPlant Schema 169

 Mapping, 118 Equipment-as-a-part, 86, 87, 88
Meta Schema, 67, 68, 70, 118, 165 Valve-as-a-part, 84, 85
Model, 3, 4, 5, 6, 9, 10, 17, 19, 27, 61, 65, PipingComponentTypes1, 150
68, 78, 91, 103, 115 Planned material, 28, 86, 92, 94, 104
Architectural, 91
Plant breakdown structure (PBS), 74, 89,
class-based, 62
118
Conceptual, 5
Polymorphism, 9, 13, 35, 62, 63, 105
data, iv, v, vi, 1, 3, 5, 6, 7, 14, 15, 16, 17,
19, 21, 44, 62, 63, 65, 66, 70, 78, 79, POSC Caesar, 27, 83, 91
84, 91 Primary Interface, 44, 45, 68, 90, 94, 118
P&ID data, 79 project, 59
POSC Facility model, 91 Project, 118
POSC Material model, 91, 92 Property, 12, 20, 22
ModelDef, 27 PropertyDef, 22, 23, 30, 38, 67, 105
Modeling, 1, 3, 4, 14, 17, 61, 62, 63, 66, 67, Typed as a Unit of Measure, 38
70, 103
Publish, 6, 20, 26, 29, 30, 47, 50, 63, 71, 74,
data, 4
76, 78, 107, 118
-ness suffix, 11, 22
bicycle-ness, 45 pump, 103, 104, 121, 129
car-ness, 11, 22 Realize, 9, 11, 14, 19, 41, 44, 47, 61, 62, 64,
dog-ness, 44 65, 66, 68, 78, 80, 85, 118
driver-ness, 14, 15 Rel, 47, 48, 50, 81, 118
Elliot Ness-ness, 12 Relationship, iv, 6, 8, 11, 15, 16, 17, 19, 20,
human-ness, 16 21, 26, 38, 40, 41, 42, 44, 46, 48, 51, 62,
man-ness, 16 63, 65, 66, 70, 78, 79, 80, 81, 84, 92, 104,
object type-ness, 35 114, 117, 118
part-ness, 118 Inheritance, 42
red-ness, 22 transitive, 41
role-ness, 45 Relationships
sloped-ness, 87 Collection, 89
tank-ness, 11 Composition, 88
taxpayer-ness, 15
RelDef, 19, 46, 47, 48, 49, 50, 51, 58, 65,
thing-ness, 11
66, 67, 78, 118
type-ness, 83, 101
Abstract, 48
valve-ness, 11, 12, 22, 45
Concrete, 48
valve-part-ness, 84
locality of reference, 51, 52
valve-type-ness, 82
Marriage, 46, 47
woman-ness, 16
Patterns, 88
Normalization, 13, 14, 114, 129
3NF, 13, 14, 114 Retrieve, 6, 14, 26, 29, 30, 63, 76, 118
4NF, 13, 14, 114 Role, 4, 10, 11, 12, 13, 14, 15, 16, 17, 20,
5NF, 13, 14, 105, 114 40, 43, 44, 46, 48, 51, 61, 62, 63, 65, 66,
data, 13, 20, 86, 103, 105, 114 80, 85, 103, 104, 105, 117
Normalize, 22 Role-based, 10, 11, 14, 61, 63
Object, iv, 1, 3, 5, 8, 9, 10, 11, 13, 14, 15, SameAs, 27
19, 20, 26, 48, 61, 62, 63, 66, 68, 74, 78, Schema, iii, 1, 13, 19, 26, 63, 68, 70, 71, 76,
79, 80, 81, 89, 118 78, 79, 93, 118, 119
Occurrence, 82, 83, 84, 85 component, 89
Evolution, 6, 93
Equipment-as-an-occurrence, 87, 88
Tool, 6, 119
Valve-as-an-occurrence, 84, 85
Schema Component, 18, 119
Ordinal numbers, 41
Scoping
Ordinality, 41, 118 PropertyDef, 22, 23, 24, 110
Orthogonal, 15, 118 ScopedBy, 119
Part, 82, 83, 84, 114 scoping property type for property
catalog, 83 definitions, 32

A Gentle Introduction to SmartPlant Schema 170

 Semantics, iv, 6, 48, 50, 85, 114, 119 HasDefaultSI, 38
Delete and Copy, 48 Symbolic logic, 16, 17
Delete Propagation, 49 Tagged item, 82, 83, 92, 94
semantic meaning, 85 Taxonomy, 8, 10, 15, 62, 115
semantic network, 8 TEF, 119
strong semantics, 29, 85 tombstone, 88
shared object, 88 Tool, iii, iv, 5, 6, 15, 26, 68, 70, 71, 117
Shared object, 27, 52, 74, 119 Authoring, 6, 7
SharedObjDef, 27, 28 Transitive, 41
SI-unit, 36, 37, 38, 119 Type hierarchy, 83
SmartPlant Enterprise, 1, 5, 6, 7, 119 Typical, 83
SmartPlant Foundation, iii, v, 3, 6, 7, 15, Typical material, 83
18, 50, 117, 118, 119 UID, 75
data, 14 UML, 17, 101
data model, iv, 15, 18, 20 Extending, 21
SmartPlant Integration, iii, 119 Unified Modeling Language (UML), 17, 19,
SmartPlant schema, iv, 1, 6, 14, 17, 18, 19, 21, 61, 66, 70, 119
20, 25, 26, 27, 38, 44, 45, 49, 55, 58, 61, Unique ID (UID), 22, 26, 47, 48, 54, 68, 81
62, 67, 69, 70, 76, 77, 78, 79, 80, 81, 91, Units of Measure, 6, 36
93, 103, 104, 109, 117, 118, 119 AnyUoM, 39
Editor, 70, 74 Conditions, 38
File, 70 absolute, 38
SmartPlant Schema Editor, v, 19, 68, 69, gauge, 38
94 UoMEnum, 36
SpecializationValue, 20 UoMListType, 36
Valve, 1, 3, 4, 5, 9, 10, 11, 12, 13, 14, 44,
SPF, iii, iv, v, 3, 6, 18, 54, 55, 76 82, 83, 92
Adapter, iv View, 5, 55
data model, iv
view definition, 59, 60
Data model, 15
database, 6 ViewDef, 55, 59, 119
Publish, 50 Work breakdown structure (WBS), 74, 89,
SameAs, 27 119
St. Ives, 102 XML, 18, 70, 76, 77, 79, 81, 120
Stereotype, 21, 26, 30, 38, 40

A Gentle Introduction to SmartPlant Schema 171