Integration

A Gentle Introduction to SmartPlant Schema Patterns, Process, &

Practice
Version 2009 R3 SP3 (4.3.3)
August 2011
Copyright
Copyright © 2011 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.
 Introduction

Did you read "A Gentle Introduction to the SmartPlant® Schema"? It is an introduction to
data modeling concepts and the SmartPlant meta schema. The SmartPlant schema is an
extensible framework for representing data, which is customizable by real-world users like
you.

The next stop on your journey towards understanding the SmartPlant schema is to try to
grasp the "patterns" that are buried in it (maybe like the novel The DaVinci Code).

Hexagon PPM wants you to be able to take the released SmartPlant schema and extend it to
meet your needs. We don't think that it's very difficult, but it's not exactly easy, either.
If you're the one who got "volunteered" to extend the schema, here's your chance to shine!
Schema-oriented tasks can be fun if you don't feel completely lost - and that's why this
book is here.

SmartPlant Schema Overview

The SmartPlant schema, effectively the SmartPlant Foundation data model, provides the
structure and semantics of the data that can be published to, and retrieved from, the
SmartPlant Foundation data repository.

How This Book is Organized

The hardest part of extending the schema is understanding the "patterns" that are
embedded in the SmartPlant schema. This book will try to explain SmartPlant schema
"patterns" to you, in a way that you can understand. When you recognize and understand a
"pattern" in the schema, you will be able to extend it for your application.

But enough of the abstract stuff -- when you need to do something with the SmartPlant

schema, you need to know how to think like

So after seeing a pattern, you'll see what the process is to "make it so". And most things
that Schema Man! does on a day-to-day basis are based on certain practices, which have
developed over many years, and you may want to adopt them in your schema development
process (or not!).

As in "A Gentle Introduction to the SmartPlant Schema", you'll see that some of the ideas
about the "patterns" 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. After seeing a few patterns, processes and practices, you'll be ready
to tackle "your" schema problems.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice i

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 is available through normal channels,

including some mighty fine Hexagon PPM Training courses, which you should plan to attend.

One problem with this book is that it is "frozen in time", and if the underlying schema
changes, you might be confused about the examples here, vs. what you see in your copy of
the schema. If you're looking for insight into:
- What are the best practices for creating a data model?
- How can I incorporate my own equipment types?
- Which classes and relationships should I use?
- How does the schema really hang together?

...then this is the right place. You will find the patterns and philosophy used to build the
SmartPlant schema, hopefully, giving you a deeper understanding of how to make it work for
YOU.. Before you start, you probably want to read, with understanding, "A Gentle
Introduction to the SmartPlant Schema" and review the "jargon" that is associated with
this topic.

Disclaimer
I'm not an author, I'm a data architect. I intend to "lighten-up" the topic of the
SmartPlant schema patterns. I take this subject seriously, but I don't think that the
presentation has to be done in a serious manner. ;-}

This book is subtitled "Tales From A Modern-Day Super Modeler who Fights
Data Ambiguity with Powerful Data Modeling Tools.” It seems that all the superheroes were
busy this year, and, let's face it, it only takes a dedicated nerd to figure out this stuff, so
having muscles of steel hardly seems relevant (however, a red cape might be a nice touch).
So gather around the campfire and listen as Schema Man! spins his schema stories.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice ii

Table of Contents

Introduction ................................................................................................................................................... i
SmartPlant Schema Overview.............................................................................................. i
How This Book is Organized ................................................................................................ i
Disclaimer ............................................................................................................................ ii

Table of Contents ....................................................................................................................................... iii

Table of Figures .......................................................................................................................................... ix

Table of Figures .......................................................................................................................................... ix

1 A Roadmap ................................................................................................................................................ 1
Patterns are Not Always Obvious ....................................................................................... 1
Why Learn Patterns? .......................................................................................................... 1
What's a "Practice"? ........................................................................................................... 2
A Process is a Set of Practices .......................................................................................... 2

2 Patterns ..................................................................................................................................................... 4
Introduction to Patterns ...................................................................................................... 4
The Origin of Anti-Patterns ................................................................................................. 6
Thinking about SmartPlant Schema Patterns .................................................................... 6
Explaining Patterns is Not Easy ......................................................................................... 6
Meta-Patterns: How to Express Design Patterns ............................................................... 8
Schema Pattern Levels ...................................................................................................... 9
The Meta-Pattern of This Book........................................................................................... 9
How to Use This Book ...................................................................................................... 10
SmartPlant Enterprise is a Framework ............................................................................. 10

3 Basic Patterns ......................................................................................................................................... 12

3.1 Interface Definition Pattern ............................................................................................................. 12
3.1.1 Identity ..................................................................................................................... 12
3.1.2 Purpose ................................................................................................................... 12
3.1.3 Usage ...................................................................................................................... 16
3.1.4 UML Interface Diagram ........................................................................................... 17
3.1.5 UML Class Diagram ................................................................................................ 18
3.1.6 Description of Pattern .............................................................................................. 20
3.1.7 Relationships to Other Schema Elements............................................................... 20
3.1.8 Collaborations .......................................................................................................... 23
3.1.9 Consequences ......................................................................................................... 23
3.1.10 Implementation ...................................................................................................... 23
3.1.11 Similar Patterns ..................................................................................................... 24
3.1.12 Anti-Patterns .......................................................................................................... 24
3.2 Property Definition Pattern .............................................................................................................. 24
3.2.1 Identity ..................................................................................................................... 24
3.2.2 Purpose ................................................................................................................... 25
3.2.3 Usage ...................................................................................................................... 25

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice iii

 3.2.4 UML Interface Diagram ........................................................................................... 25
3.2.5 UML Class Diagram ................................................................................................ 26
3.2.6 Description of Pattern .............................................................................................. 27
3.2.7 Relationships to Other Schema Elements............................................................... 27
3.2.8 Collaborations .......................................................................................................... 27
3.2.9 Consequences ......................................................................................................... 28
3.2.10 Implementation ...................................................................................................... 28
3.2.11 Similar Patterns ..................................................................................................... 28
3.2.12 Anti-Patterns .......................................................................................................... 28
3.3 Property Type Pattern ..................................................................................................................... 28
3.3.1 Identity ..................................................................................................................... 28
3.3.2 Purpose ................................................................................................................... 29
3.3.3 Usage ...................................................................................................................... 29
3.3.4 UML Interface Diagram ........................................................................................... 29
3.3.5 UML Class Diagram ................................................................................................ 30
3.3.6 Description of Pattern .............................................................................................. 31
3.3.7 Relationships to Other Schema Elements............................................................... 34
3.3.8 Collaborations .......................................................................................................... 34
3.3.9 Consequences ......................................................................................................... 35
3.3.10 Implementation ...................................................................................................... 35
3.3.11 Similar Patterns ..................................................................................................... 35
3.3.12 Anti-patterns .......................................................................................................... 35
3.4 Relation Pattern .............................................................................................................................. 36
3.4.1 Identity ..................................................................................................................... 36
3.4.2 Purpose ................................................................................................................... 36
3.4.3 Usage ...................................................................................................................... 36
3.4.4 UML Interface Diagram ........................................................................................... 38
3.4.5 UML Class Diagram ................................................................................................ 49
3.4.6 Description of Pattern .............................................................................................. 49
3.4.7 Relationships to Other Schema Elements............................................................... 49
3.4.8 Collaborations .......................................................................................................... 50
3.4.9 Consequences ......................................................................................................... 50
3.4.10 Implementation ...................................................................................................... 50
3.4.11 Similar Patterns ..................................................................................................... 50
3.4.12 Anti-patterns .......................................................................................................... 50
3.5 Relation Definition Pattern .............................................................................................................. 51
3.5.1 Identity ..................................................................................................................... 51
3.5.2 Purpose ................................................................................................................... 51
3.5.3 Usage ...................................................................................................................... 54
3.5.4 UML Interface Diagram ........................................................................................... 55
3.5.5 UML Class Diagram ................................................................................................ 56
3.5.6 Description of Pattern .............................................................................................. 57
3.5.7 Relationships to Other Schema Elements............................................................... 57
3.5.8 Collaborations .......................................................................................................... 57
3.5.9 Consequences ......................................................................................................... 57
3.5.10 Implementation ...................................................................................................... 57
3.5.11 Similar Patterns ..................................................................................................... 57
3.5.12 Anti-Patterns .......................................................................................................... 57
3.6 Class Definition Pattern .................................................................................................................. 58
3.6.1 Identity ..................................................................................................................... 58
3.6.2 Purpose ................................................................................................................... 58
3.6.3 Usage ...................................................................................................................... 60
3.6.4 UML Interface Diagram ........................................................................................... 62
3.6.5 UML Class Diagram ................................................................................................ 63
3.6.6 Description of Pattern .............................................................................................. 63
3.6.7 Relationships to Other Schema Elements............................................................... 64

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice iv

 3.6.8 Collaborations .......................................................................................................... 64
3.6.9 Consequences ......................................................................................................... 65
3.6.10 Implementation ...................................................................................................... 65
3.6.11 Similar Patterns ..................................................................................................... 65
3.6.12 Anti-Patterns .......................................................................................................... 66
3.7 Component Schema Pattern ........................................................................................................... 66
3.7.1 Identity ..................................................................................................................... 66
3.7.2 Purpose ................................................................................................................... 66
3.7.3 Usage ...................................................................................................................... 67
3.7.4 UML Interface Diagram ........................................................................................... 68
3.7.5 UML Class Diagram ................................................................................................ 69
3.7.6 Description of Pattern .............................................................................................. 70
3.7.7 Relationships to Other Schema Elements............................................................... 70
3.7.8 Collaborations .......................................................................................................... 70
3.7.9 Consequences ......................................................................................................... 70
3.7.10 Implementation ...................................................................................................... 70
3.7.11 Similar Patterns ..................................................................................................... 71
3.7.12 Anti-Patterns .......................................................................................................... 71
3.8 Model Definition Pattern .................................................................................................................. 71
3.8.1 Identity ..................................................................................................................... 71
3.8.2 Purpose ................................................................................................................... 71
3.8.3 Usage ...................................................................................................................... 71
3.8.4 UML Interface Diagram ........................................................................................... 72
3.8.5 UML Class Diagram ................................................................................................ 72
3.8.6 Description of Pattern .............................................................................................. 72
3.8.7 Relationships to Other Schema Elements............................................................... 72
3.8.8 Collaborations .......................................................................................................... 72
3.8.9 Consequences ......................................................................................................... 72
3.8.10 Implementation ...................................................................................................... 72
3.8.11 Similar Patterns ..................................................................................................... 72
3.8.12 Anti-Patterns .......................................................................................................... 73

4 Mid-level Patterns ................................................................................................................................... 74

4.1 Class/Interface/Property Pattern ..................................................................................................... 74
4.1.1 Identity ..................................................................................................................... 74
4.1.2 Purpose ................................................................................................................... 74
4.1.3 Usage ...................................................................................................................... 74
4.1.4 UML Interface Diagram ........................................................................................... 74
4.1.5 UML Class Diagram ................................................................................................ 76
4.1.6 Description of Pattern .............................................................................................. 76
4.1.7 Relationships to Other Schema Elements............................................................... 76
4.1.8 Collaborations .......................................................................................................... 77
4.1.9 Consequences ......................................................................................................... 77
4.1.10 Implementation ...................................................................................................... 77
4.1.11 Similar Patterns ..................................................................................................... 77
4.1.12 Anti-Patterns .......................................................................................................... 78
4.2 Multi-level List Pattern ..................................................................................................................... 78
4.2.1 Identity ..................................................................................................................... 79
4.2.2 Purpose ................................................................................................................... 79
4.2.3 Usage ...................................................................................................................... 79
4.2.4 UML Interface Diagram ........................................................................................... 80
4.2.5 UML Class Diagram ................................................................................................ 81
4.2.6 Description of Pattern .............................................................................................. 85
4.2.7 Relationships to Other Schema Elements............................................................... 85
4.2.8 Collaborations .......................................................................................................... 85

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice v

 4.2.9 Consequences ......................................................................................................... 85
4.2.10 Implementation ...................................................................................................... 86
4.2.11 Similar Patterns ..................................................................................................... 90
4.2.12 Anti-Patterns .......................................................................................................... 90
4.3 Edge Definition Pattern ................................................................................................................... 91
4.3.1 Identity ..................................................................................................................... 92
4.3.2 Purpose ................................................................................................................... 93
4.3.3 Usage ...................................................................................................................... 93
4.3.4 UML Interface Diagram ........................................................................................... 93
4.3.5 UML Class Diagram ................................................................................................ 96
4.3.6 Description of Pattern .............................................................................................. 96
4.3.7 Relationships to Other Schema Elements............................................................... 96
4.3.8 Collaborations .......................................................................................................... 97
4.3.9 Consequences ......................................................................................................... 97
4.3.10 Implementation ...................................................................................................... 97
4.3.11 Similar Patterns ..................................................................................................... 99
4.3.12 Anti-Patterns .......................................................................................................... 99
4.4 Graph Definition Pattern ............................................................................................................... 100
4.4.1 Identity ................................................................................................................... 100
4.4.2 Purpose ................................................................................................................. 100
4.4.3 Usage .................................................................................................................... 101
4.4.4 UML Interface Diagram ......................................................................................... 103
4.4.5 UML Class Diagram .............................................................................................. 104
4.4.6 Description of Pattern ............................................................................................ 105
4.4.7 Relationships to Other Schema Elements............................................................. 106
4.4.8 Collaborations ........................................................................................................ 106
4.4.9 Consequences ....................................................................................................... 106
4.4.10 Implementation .................................................................................................... 106
4.4.11 Similar Patterns ................................................................................................... 106
4.4.12 Anti-Patterns ........................................................................................................ 106
4.5 View Definition Pattern .................................................................................................................. 107
4.5.1 Identity ................................................................................................................... 108
4.5.2 Purpose ................................................................................................................. 108
4.5.3 Usage .................................................................................................................... 108
4.5.4 UML Interface Diagram ......................................................................................... 108
4.5.5 UML Class Diagram .............................................................................................. 109
4.5.6 Description of Pattern ............................................................................................ 109
4.5.7 Relationships to Other Schema Elements............................................................. 109
4.5.8 Collaborations ........................................................................................................ 110
4.5.9 Consequences ....................................................................................................... 110
4.5.10 Implementation .................................................................................................... 110
4.5.11 Similar Patterns ................................................................................................... 110
4.5.12 Anti-Patterns ........................................................................................................ 110
4.6 Shared Objects, Expansion, and SameAs Pattern ....................................................................... 111
4.6.1 Identity ................................................................................................................... 111
4.6.2 Purpose ................................................................................................................. 111
4.6.3 Usage .................................................................................................................... 113
4.6.4 UML Interface Diagram ......................................................................................... 113
4.6.5 UML Class Diagram .............................................................................................. 113
4.6.6 Description of Pattern ............................................................................................ 114
4.6.7 Relationships to Other Schema Elements............................................................. 115
4.6.8 Collaborations ........................................................................................................ 115
4.6.9 Consequences ....................................................................................................... 115
4.6.10 Implementation .................................................................................................... 115
4.6.11 Similar Patterns ................................................................................................... 116
4.6.12 Anti-Patterns ........................................................................................................ 116

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice vi

5 Business Patterns ................................................................................................................................ 117
5.1 POSC/Caesar Pattern ................................................................................................................... 117
5.1.1 Identity ................................................................................................................... 117
5.1.2 Purpose ................................................................................................................. 117
5.1.3 Usage .................................................................................................................... 117
5.1.4 UML Interface Diagram ......................................................................................... 117
5.1.5 UML Class Diagram .............................................................................................. 119
5.1.6 Description of Pattern ............................................................................................ 119
5.1.7 Relationships to Other Schema Elements............................................................. 121
5.1.8 Collaborations ........................................................................................................ 123
5.1.9 Consequences ....................................................................................................... 123
5.1.10 Implementation .................................................................................................... 124
5.1.11 Similar Patterns ................................................................................................... 124
5.1.12 Anti-Patterns ........................................................................................................ 124
5.2 Typical Material vs. Planned Material Pattern .............................................................................. 125
5.2.1 Identity ................................................................................................................... 125
5.2.2 Purpose ................................................................................................................. 125
5.2.3 Usage .................................................................................................................... 125
5.2.4 UML Interface Diagram ......................................................................................... 127
5.2.5 UML Class Diagram .............................................................................................. 133
5.2.6 Description of Pattern ............................................................................................ 135
5.2.7 Relationships to Other Schema Elements............................................................. 135
5.2.8 Collaborations ........................................................................................................ 135
5.2.9 Consequences ....................................................................................................... 135
5.2.10 Implementation .................................................................................................... 136
5.2.11 Similar Patterns ................................................................................................... 136
5.2.12 Anti-Patterns ........................................................................................................ 137
5.3 Collection Pattern .......................................................................................................................... 137
5.3.1 Identity ................................................................................................................... 137
5.3.2 Purpose ................................................................................................................. 137
5.3.3 Usage .................................................................................................................... 138
5.3.4 UML Interface Diagram ......................................................................................... 138
5.3.5 UML Class Diagram .............................................................................................. 138
5.3.6 Description of Pattern ............................................................................................ 138
5.3.7 Relationships to Other Schema Elements............................................................. 139
5.3.8 Collaborations ........................................................................................................ 139
5.3.9 Consequences ....................................................................................................... 139
5.3.10 Implementation .................................................................................................... 139
5.3.11 Similar Patterns ................................................................................................... 139
5.3.12 Anti-Patterns ........................................................................................................ 139
5.4 Composition Pattern...................................................................................................................... 139
5.4.1 Identity ................................................................................................................... 139
5.4.2 Purpose ................................................................................................................. 139
5.4.3 Usage .................................................................................................................... 140
5.4.4 UML Interface Diagram ......................................................................................... 140
5.4.5 UML Class Diagram .............................................................................................. 140
5.4.6 Description of Pattern ............................................................................................ 140
5.4.7 Relationships to Other Schema Elements............................................................. 140
5.4.8 Collaborations ........................................................................................................ 140
5.4.9 Consequences ....................................................................................................... 140
5.4.10 Implementation .................................................................................................... 141
5.4.11 Similar Patterns ................................................................................................... 141
5.4.12 Anti-Patterns ........................................................................................................ 141
5.5 Connectivity Pattern ...................................................................................................................... 141
5.5.1 Identity ................................................................................................................... 141

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice vii

 5.5.2 Purpose ................................................................................................................. 141
5.5.3 Usage .................................................................................................................... 141
5.5.4 UML Interface Diagram ......................................................................................... 141
5.5.5 UML Class Diagram .............................................................................................. 142
5.5.6 Description of Pattern ............................................................................................ 142
5.5.7 Relationships to Other Schema Elements............................................................. 144
5.5.8 Collaborations ........................................................................................................ 144
5.5.9 Consequences ....................................................................................................... 145
5.5.10 Implementation .................................................................................................... 145
5.5.11 Participants .......................................................................................................... 148
5.5.12 Similar Patterns ................................................................................................... 148
5.5.13 Anti-Patterns ........................................................................................................ 148

6 Anti-Patterns ......................................................................................................................................... 149

6.1.1 Schema Ambiguity................................................................................................. 149
6.1.2 Improper or Weak Scoping of Properties .............................................................. 149
6.1.3 Relationship Parent ............................................................................................... 150
6.1.4 To Normalize or Not to Normalize—That is the Question ..................................... 150
6.1.5 My Anti-Patterns .................................................................................................... 150

7 Bibliography .......................................................................................................................................... 151

Appendix A Schema Man! ...................................................................................................................... 153

Appendix B Images ................................................................................................................................. 155

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

Index ......................................................................................................................................................... 162

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice viii

Table of Figures

Figure 1 A Building Foundation with Re-bar but Before Concrete is Poured ................. 7
Figure 2 Chess Pattern named "Giuoco Piano" ........................................................... 11
Figure 3 A Pump on a Simulation Drawing .................................................................. 14
Figure 4 ANSI Pump Dimensions ................................................................................. 15
Figure 5 A Sample UML Interface Pattern ................................................................... 17
Figure 6 A Sample UML Class Pattern ........................................................................ 19
Figure 7 Simple Relationship Pattern ........................................................................... 20
Figure 8 Relationships that a Pump may Participate in ............................................... 21
Figure 9 UML Diagram of Typical Property .................................................................. 26
Figure 10 PropertyDef Class Diagram ......................................................................... 26
Figure 11 IPropertyType UML Diagram ....................................................................... 30
Figure 12 Example of PropertyType Class Diagram (UML) ......................................... 30
Figure 13 Multi-level Enumerated List in Properties ..................................................... 33
Figure 14 Partial Equipment-Type Hierarchy ............................................................... 34
Figure 15 Sample Relationship Definition in Meta Schema ......................................... 37
Figure 16 Enumerated List Contains Values ................................................................ 37
Figure 17 Componentization Relation Definition UML Diagram ................................... 38
Figure 18 Componentization Relation Example ........................................................... 39
Figure 19 Contains Relation UML Diagram .................................................................. 39
Figure 20 Contains Relation Example .......................................................................... 39
Figure 21 EnumMetadata Relation UML Diagram ....................................................... 40
Figure 22 EnumMetadata Relation Example................................................................ 40
Figure 23 Nozzle Types ................................................................................................ 41
Figure 24 Exposes Relation UML Diagram .................................................................. 41
Figure 25 Exposes Relation Example .......................................................................... 42
Figure 26 HasDefaultSI Relation UML Diagram ........................................................... 42
Figure 27 HasDefaultSI Relation Example ................................................................... 42
Figure 28 Implies Relation UML Diagram .................................................................... 43
Figure 29 Implies Relation Example ............................................................................. 43
Figure 30 Instantiates Relation UML Diagram ............................................................. 43
Figure 31 Instantiates Relation Example ...................................................................... 44
Figure 32 ModelClass Relation UML Diagram ............................................................. 44
Figure 33 ModelClass Relation Example ..................................................................... 44
Figure 34 PrimaryInterface Relation UML Diagram ..................................................... 45
Figure 35 PrimaryInterface Relation Example.............................................................. 45
Figure 36 Realizes Relation UML Diagram .................................................................. 45
Figure 37 Realizes Relation Example .......................................................................... 46
Figure 38 ScopedBy Relation UML Diagram ............................................................... 46
Figure 39 ScopedBy Relation Example ........................................................................ 46
Figure 40 Sharing Relation UML Diagram ................................................................... 47
Figure 41 Sharing Relation Example ............................................................................ 47
Figure 42 UoMConditions Relation UML Diagram ....................................................... 48
Figure 43 UoMConditions Relation Example ............................................................... 48
Figure 44 A Bicycle, a Man Marries a Woman, a Compressor Spool has Nozzles ..... 52
Figure 45 Equipment Nozzles Relation Definition ........................................................ 53
Figure 46 Relation Definition Showing Inheritance ...................................................... 54
Figure 47 IRelDef UML Diagram .................................................................................. 56
Figure 48 RelDef Class Diagram .................................................................................. 56
Figure 49 Instrument Class .......................................................................................... 61
Figure 50 IClassDef UML Diagram............................................................................... 62

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice ix

Figure 51 ClassDef Class Diagram ............................................................................. 63
Figure 52 A Cross-Stitch Pattern Named "The Fundamental Idea About Classes" ..... 64
Figure 53 Componentization Relation Definition UML Diagram ................................... 68
Figure 54 Control System Component Members ......................................................... 69
Figure 55 Model Definition to Class Definition Relationship ....................................... 72
Figure 56 An Instance of a ModelClass ....................................................................... 72
Figure 57 IMammal Implies IObject .............................................................................. 75
Figure 58 The Basic Roles of a Mammal ..................................................................... 75
Figure 59 Some Mammal Properties ............................................................................ 75
Figure 60 Class Diagram of a Mammal ........................................................................ 76
Figure 61 Enumerated List Hierarchy ........................................................................... 79
Figure 62 IEnumListType UML Diagram ...................................................................... 80
Figure 63 EnumListLevelType Meta Schema .............................................................. 81
Figure 64 Enumerated Entry Metadata ........................................................................ 82
Figure 65 Example of EnumMetadata Relationship ..................................................... 83
Figure 66 Example of PropertyDef and EnumListType ................................................ 83
Figure 67 Example of Multi-level List............................................................................ 84
Figure 68 A Raven's Comments about The Pump ....................................................... 86
Figure 69 Multi-level Enumerated List of Auto Manufacturers ..................................... 87
Figure 70 Properties in a Hierarchy are ScopedBy EnumListLevelType ..................... 87
Figure 71 Interfaces ...................................................................................................... 88
Figure 72 Interfaces are Tied to Hierarchy using EnumMetadata ................................ 89
Figure 73 Overall View of Auto Manufacturers Tied to Interfaces ................................ 89
Figure 74 Dorothy Explains Edges ............................................................................... 91
Figure 75 An EdgeDef is Born ...................................................................................... 92
Figure 76 IEdgeDef UML Diagram ............................................................................... 93
Figure 77 Edge for Piping Port 1 .................................................................................. 94
Figure 78 Shared Objects With a Relationship ............................................................ 95
Figure 79 Class Diagram for EdgeDef.......................................................................... 96
Figure 80 Navigation from Chicago to L.A. .................................................................. 97
Figure 81 UML Interface Diagram of Cities and Highways .......................................... 98
Figure 82 UML Class Diagram of Cities and Highways ............................................... 98
Figure 83 City and Highway Objects ............................................................................ 99
Figure 84 Graphs by Dorothy ..................................................................................... 101
Figure 85 Define One Edge for Each Nozzle ............................................................. 102
Figure 86 IDirectedGraphDef UML Diagram .............................................................. 103
Figure 87 DirectedGraphDef UML Diagram ............................................................... 104
Figure 88 A Complex GraphDef ................................................................................. 105
Figure 89 Lots of Properties ....................................................................................... 107
Figure 90 IViewDef UML Diagram .............................................................................. 108
Figure 91 ViewDef UML Diagram ............................................................................... 109
Figure 92 ISharedObjDef UML Diagram .................................................................... 113
Figure 93 Shared Objects UML Diagram ................................................................... 113
Figure 94 Material Expansion Schema ...................................................................... 114
Figure 95 Material Expansion on a P&ID ................................................................... 115
Figure 96 Facility Model ............................................................................................. 118
Figure 97 Material Model ............................................................................................ 119
Figure 98 Version n+1 of Facility is Based on Version n............................................ 120
Figure 99 Washington Crossing the Delaware ........................................................... 121
Figure 100 A P&ID Pump With Tag P-142 ................................................................. 121
Figure 101 Pump Catalog ........................................................................................... 122
Figure 102 Pump S/N RH-GH5002-Z ......................................................................... 123
Figure 103 Two Pumps that are Polymorphic with Respect to IMaterialItem ............ 124
Figure 104 Conceptual Schema of Manufacturer, Model, Catalog ............................ 127
Figure 105 Denormalized Manufacturer, Model Plus Catalog ................................... 127
Figure 106 Typical Material Model ............................................................................. 128

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice x

Figure 107 New Typical and Planned Material Model ................................................ 128
Figure 108 A Pump on a PFD and a Pump in a Catalog............................................ 129
Figure 109 Abbreviated UML of Relief Valve ............................................................. 130
Figure 110 Equipment and Equipment Components ................................................. 131
Figure 111 Cable Tray and Cable Tray Components................................................. 132
Figure 112 Cable Stuff ................................................................................................ 132
Figure 113 Pump Catalogs ......................................................................................... 133
Figure 114 A Pump in a Pump Catalog ...................................................................... 133
Figure 115 A Pump In a Pump Catalog ...................................................................... 134
Figure 116 Typical and Planned Pumps .................................................................... 134
Figure 117 Collection (of cars) ................................................................................... 137
Figure 118 The Connectivity Pattern .......................................................................... 141
Figure 119 IConnector ................................................................................................ 142
Figure 120 IConnection .............................................................................................. 143
Figure 121 A Piping Connector is a Type of Connector ............................................. 145
Figure 122 Three Relationships between Piping Connectors and Piping
Connections........................................................................................... 145
Figure 123 Connector Classes ................................................................................... 146
Figure 124 Shared Connector Classes ...................................................................... 147
Figure 125 Classes that Realize That They Are Connections ................................... 147
Figure 126 Classes That Use Connection Pattern ..................................................... 148

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice xi

A Roadmap
Can you hear a computer-generated voice saying, "Welcome to the next level," as the
journey into the heart of the SmartPlant schema continues? You have already read and
understood "A Gentle Introduction to the SmartPlant Schema", so you have a good grasp of
the terms and ideas that are associated with the SmartPlant meta schema. If you didn't
read it, you're going to be lost on this journey, so please do that now -- otherwise, please
fasten your seat belt.

Patterns are Not Always Obvious

The idea of explaining patterns seems to be obvious, but many times we look at different
things and do not "see the pattern." It can be very frustrating for someone to be looking at
you saying, "Don't you see a pattern there?” and you haven't got a clue what the heck

pattern she's observing. Later on, you look at that same thing and say "AHA!
That's just like a checker board (or a car, or a valve, or a pump)."

We all perceive patterns differently. In this book, I'll try to show the patterns in the
SmartPlant schema at a high-level, and at a low-level, so that you really gain a deeper
understanding of what's going on.

If it's OK with you, I'll mostly just say "schema" when I mean "SmartPlant schema" in the
rest of this book.

Why Learn Patterns?

Why you want to have a deep understanding of the schema is up to you, but I guess that
you're trying to customize your application suite so that it publishes or retrieves data to or
from the SmartPlant Enterprise suite. You have to publish a document that contains a
"valve", and all you see in the schema is an "instrument" - what's the next step? When
you're done here, I hope you will feel much more confidant and actually know the answer to
that seemingly strange question.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 1

What's a "Practice"?
Remember when you learned to write the alphabet in 'cursive form'? Tie your shoes?
Parallel park? Your teacher or mentor encouraged you to "practice, practice, practice." Now
you show your kids how to tie their shoes -- the funny part is that you have to remember
the long forgotten "practice" of tying a shoe. You did it without thinking about it for so
long, that you must remember the steps in order to teach it. That's what a practice is --
the systematic approach to solving a problem.

A practice does not address some huge problem. Rather, a practice attacks a specific
aspect of a problem. A practice is something that can be articulated and has a clear
beginning and end, and tells a complete story in understandable chunks. You'll see a bunch
of stories in this book, for that very reason. Hint: A practice leads to a goal.

A practice is a proven way of addressing a problem. It's something that's been done before
and can be repeatedly applied to the same problem to produce consistent results. It should
be noted that practices may be improved, and the new practice may be better, faster,
cheaper, or just more fun and less boring.

A "Process" is a Set of Practices

A process is a way of dealing with things in a routine way. says, "It is

axiomatic that the existence of a process doesn't mean that anyone actually follows it."
Also note that a favorite process of humans is called "the process of trial and error." If
you have a set of proven practices, and execute them in a well-defined way, you can declare
that the process leads to some kind of successful conclusion.

Review: 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, for example, a motor,
a pump, a valve, and so on. But it is really not simple at all. That's because each program
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."

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 Pattern Zone"!

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 2

 "nah na NAH naaaa"

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 3

Patterns

Grey Wolf tells the Story of Patterns

After growling about data modeling for what seemed to be a long time, looked at
the large gathering and said: "This is like howling at the moon - the SmartPlant schema is
just not that hard to understand! It has a lot of patterns embedded within it that can help
you understand what's going on. In fact, its purpose in life is to make sure that multiple
software 'tools' adhere to patterns in order that they can exchange data in a meaningful

way." stood in the gathering (look at his legs: he can't sit) and listened as
Grey Wolf began the Story of Patterns.

Introduction to Patterns
Here is what Grady Booch, the Chief Scientist at Rational Software Corporation, says about
patterns:

"All well-structured object-oriented architectures are full of patterns.

Indeed, one of the ways that I measure the quality of an object-oriented
system is to judge whether or not its developers have paid careful attention
to the common collaborations among its objects. Focusing on such
mechanisms during a system's development can yield an architecture that is
smaller, simpler, and far more understandable than if these patterns are
ignored."

The Origin of "Patterns"

In the world of systems analysis, there has been a lot of work in the past 10 years on the
subject of "patterns." However, significant papers were written as far back as the late
70's that blazed the trail of understanding. Take a minute and look at the Bibliography.
The most important book about the idea of "patterns" is Design Patterns by Erich Gamma
and friends. It presents 23 patterns that enable reusable designs, without rediscovering
the design solutions themselves. Some of the important patterns that he documents, and
are used in SmartPlant Enterprise include:
 Factory Method - Defines an interface for creating an object, but let subclasses
decide which class to instantiate. Factory Method lets a class defer instantiation to
subclasses.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 4

  Adapter - Converts the interface of a class into another interface clients expect.
Adapter lets classes work together that couldn't otherwise because of
compatibility.
 Composite - Composes objects into tree structures to represent part-hole
hierarchies. Composite lets clients treat individual objects and compositions of
objects uniformly.
 Façade - Hides the complexity of the underlying schema (the ISO 15926 crowd
really loves this pattern).
 Iterator - Provides a way to access the elements of an aggregate object sequentially
without exposing its underlying representation.
 Mediator - Defines an object that encapsulates how a set of objects interact.
Mediator promotes loose coupling by keeping objects from referring to each other
explicitly, and it lets you vary their interaction independently.
 Memento - Without violating encapsulation, captures and externalizes an object's
internal state so that the object can be restored to this state later.
 Observer - Defines a one-to-many dependency between objects so that when one
object changes state, all its dependents are notified and updated automatically.
 State - Allows an object to alter its behavior when its internal state changes. The
object will appear to change its class.
 Strategy - Defines a family of algorithms, encapsulates each one, and makes them
interchangeable. Strategy lets the algorithm vary independently from clients that
use it.
 Template Method - Defines the skeleton of an algorithm in an operation, deferring
some steps to subclasses. Template Method lets subclasses redefine certain steps
of an algorithm without changing the algorithm's structure.

As you'll see, SmartPlant Enterprise and the schema are loaded with many patterns, at many
levels.

Why Use Patterns?

"Design Patterns" gives a brief rationale for using patterns:

"Novelists and playwrights rarely design their plots from scratch. Instead, they
follow patterns like 'Tragically Flawed Hero' (Macbeth, Hamlet, etc.) or 'The
Romantic Novel' (countless romance novels). In the same way, object-oriented
designers follow patterns like 'represent states with objects' and 'decorate objects
so that you can easily add/remove features.' Once you know the pattern, a lot of
design decisions follow automatically."

said that the principal benefit for using patterns is summed up in the word
"Reusability."

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 5

The Origin of Anti-Patterns
The last chapter will discuss Anti-Patterns, which are based on the idea that defining
patterns that fail is just about as good as defining patterns that succeed.

The After-Action Report

Failures, or anti-patterns, should always create documentation, called, for example, an
"After-Action Report (AAR)", which will help prevent similar failures "next time" (dare we
say "if someone reads it"?). Do you think that the exact same failures must happen over
and over again? If you watch the movie Ground Hog Day, you get the idea that even
someone who is very deep in a rut of failure can eventually change the outcome of his
situation. In order to succeed, we "refactor" the bad pattern into a corrected pattern.

Thinking about SmartPlant Schema Patterns

We'll concentrate on patterns that occur within the schema and meta-schema—but first, a
review. Some patterns were introduced in "A Gentle Introduction to the SmartPlant
Schema", so you have been exposed to:
 The Linnaean model of taxonomy (which provides an underlying classification
structure, which is used to build up a semantic network of animal classes)
 Polymorphism (the ability to appear in many forms)
 A role-based view of objects that is implemented using "interfaces"
 The "-ness" of something, for example, "car-ness", "desk-ness", "valve-ness", and so
on.
 Data normalization (how to tightly-group similar properties)
 The idea of "orthogonal" roles ("having a set of mutually perpendicular axes; meeting
at right angles")
 Symbolic logic (how a specific symbol can have a precise meaning)
 Unified Modeling Language (UML)
 Why there IS a SmartPlant schema and data model
 Inheritance of properties and behavior via the Implies relationship
 Abstract vs. Concrete relationships
 The idea of "Shared objects"
 The underlying POSC/Caesar model ("Facility" and "Material")
 and so on

Explaining Patterns is Not Easy

Designing a system that allows loosely-integrated software programs (also known as tools)
to communicate with each other at a detailed level is hard to do. Understanding how it
works is more difficult. Explaining it is hardest of all.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 6

 You are good at what you do, but could you explain your job in great detail to your mother,
your uncle, a co-worker in another department, a customer? How would you do that? You
would not try to explain every one of your ideas from "first principles"; rather, you'd try to
explain the patterns of how you do this, and then how you do that. For example, you'd point
to Figure 1 and say, "First we lay down pipes and re-bar, and then we mix the concrete and
pour the foundation.”

Figure 1 A Building Foundation with Re-bar but Before Concrete is Poured

“After it sets, we erect the walls and install electrical wiring according to a Standard.
Finally, we put on the roof and coat it like this. We build all our houses like that."

says this: "The schema is extended by adding roles, properties of the roles, and
relationships between the roles. Enumerated lists may need to be extended, too. Then we
add classes and publish the result."

Pattern-Space

interrupts, "Well, it's great if you know how to pour a foundation, but
otherwise, you're going to be lost pretty quickly. You need to know what 'pourable thing' is
being discussed, and what does 'foundation' mean. Why in the world would you "pour" one?"

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 7

 smiled (Note: a wolf-smile is not all that glamorous) "So, the first thing about
discussing a pattern, is learning about domain-specific objects in enough detail that you can
understand them, and manipulate them in the pattern-space of whatever you're talking
about. In other words, if you don't know what 'pouring' is, or 'what is being poured', or
what a 'foundation' is, or why one would 'pour a foundation', you're in trouble. In fact, if
the domain expert said 'We pour concrete,' what would you think of his ability to function
in a normal society? So part of understanding 'patterns' is a superficial understanding of
the pattern-space, or the 'subject area,' that is being discussed."

The Pattern-Space of the Schema

The pattern-space of the schema uses these terms:
 Role
 Interface (including "primary interface")
 Property
 Relationship (including cardinality)
 Class
 Enumerated list
 Unit of measure
 Unified Modeling Language (UML) and data modeling
 Data normalization
 and so on

That's not a very big list of stuff, is it? puts on his best Zen-face and utters,
"True understanding of those terms is required in order for you to discover and use the
patterns in the schema. That will make your design decisions much easier!"

Meta-Patterns: How to Express Design Patterns

After taking a break, continues, "If you have the task of explaining the patterns
that are used in your world, how would you do that? I bet that you'd first develop a "meta-
pattern," or to say it another way, a 'pattern of patterns' - that's what this book does,
too."

Your Agenda
You, dear reader, need to learn how to think about patterns in your pattern-space. When
you're done with this book, you will feel confident about reading the schema, and updating it
with your own ideas of how your facility will be modeled in the schema.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 8

Schema Pattern Levels
Schema patterns are 3 levels, namely, basic, mid-level, and business:
 Basic patterns define the core-elements of the schema, that is, interfaces,
properties, classes, and so on.
 Mid-level patterns define how the basic patterns are connected and used within the
schema. For example, interfaces expose properties that are scoped by types.
 Business patterns define how users can put together business solutions using schema
elements, for example, Connectivity pattern, Process data pattern.

Schema Patterns
Here are the patterns that will be covered by this book, and you may want to study them in
this order:
 Basic patterns
• Interface definition pattern
• Property definition pattern
• Property type pattern
• Relation pattern
• Relation definition pattern
• Class definition pattern
• Edge definition pattern
• Graph definition pattern
• View definition pattern
• Shared Objects, Expansion, and SameAs pattern
 Mid-level patterns
• Class/Interface/Property model
• Multi-level lists
 Business patterns
• POSC/Caesar facility and material model
• Typical material vs. Planned material
• Component Schema Pattern (a basic pattern)
• Model Definition Pattern (a basic pattern)
• Collection Pattern
• Composition Pattern
• Connectivity Pattern

The Meta-Pattern of This Book

explains, "We need a 'pattern to describe the patterns' in the SmartPlant

schema. A 'pattern of a pattern' is called a meta-pattern. In this book, each meta-pattern
describes the who, what, when, where and why of the pattern:
 Identity - How is the pattern identified? What is its name and a brief description?

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 9

  Purpose - What does the pattern do? Discuss the rationale and intent behind the
pattern.
 Usage - What SmartPlant Enterprise tools use this pattern?
 UML Diagram - Show the overall UML diagram(s) as an "Interface diagram", a "Class
diagram", or anything that is useful.
 Description of the pattern
 Relationships to other schema elements - What relationships are formed with other
schema objects to make bigger patterns?
 Collaborations - How do the objects that use this pattern use it?
 Consequences - If you use this pattern, what do you expect as a result?
 Implementation - How should the data modeler and the tool developer view this
pattern?
 Similar patterns - What patterns are similar to this one?
 Anti-patterns - Are there relevant anti-patterns? How can they be refactored for
success?

How to Use This Book

Applications are hard to design, and some of them are hard to understand and implement.
For example, think about how complex the Microsoft® Windows® operating system must be
to accommodate all the demands that the users put upon it. If you were going to code some
new, complex program that runs on Windows, you'd use a toolkit or a software design kit
(SDK) to make your life easier. But you still have to understand the underlying "framework"
to have any hope of success! For example, if you don't know how the basic message dispatch
loop works in Windows, it isn't very likely that the "Microsoft DirectX SDK" will do you any
good.

Furthermore, even the underlying framework can change. Look back at Windows 3.1 and
contrast that Windows XP Pro - you can see a vast change in the framework, and in the
architecture that it encompasses. Obviously, software is fragile, with respect to changes in
the operating system that it runs upon.

SmartPlant Enterprise is a Framework

SmartPlant Enterprise provides a framework for loose integration of software tools that
are used to design and build large facilities. This book will attempt to present some of the
underlying design issues that were critical to the framework design. A framework should
always try to describe itself through design patterns so that the users are more likely to
achieve high-levels of design reuse. The framework's architecture should be disclosed to
all the users so that they can effectively use it.

Frameworks are Complex

Large frameworks often seem "complex", simply because there are so many patterns in
them. People who want to become proficient must go through a learning curve, which is
pretty scary. Design pattern documentation is used to "flatten" the learning curve
somewhat, and make it obvious what's going on behind the curtain.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 10

Simple vs. Easy
Chess is a great example of something that is "simple but not easy." If you look at the game
of chess, there are 6 different pieces (rook, knight, bishop, king, queen, pawn), on an 8x8
square board, with a basic structure of moves by 2 alternating players who capture
opponent pieces and finally disable the king. It takes less than an hour to memorize the
rules of chess. But it takes a "Master" to memorize the patterns!

In chess, the opening game is different from the middle game, and that's different from
the end game. Each of those has well-known patterns.

Figure 2 Chess Pattern named "Giuoco Piano"

Controlling the center of the board is a recurring pattern. Castling is a simple, but powerful
pattern. Figure 2 shows an opening pattern called Giuoco Piano, which is very common
"opening pattern", and you'll certainly encounter it if you play chess. There are thousands
of books on chess patterns, each of which promises to reveal some guarded secrets that
chess masters hope you'll never learn. The truth is chess masters only learn patterns. The
other truth is that most people get scared away from chess because they believe that "it's
too complicated."

The SmartPlant schema has very few "pieces" (interfaces, classes, lists), and not a lot of
"moves" (classes realize interfaces; interfaces expose properties, which are scoped by
types, and so on). There are innumerable ways that the basic pieces can be hooked together
into patterns that apply to designing and building a large facility. I hope you'll see some of
them are in this very fine book.

Don't let the fact that there are lots of patterns throw you for a loop, instead, try to
understand that these underlying design patterns are what allows you to exchange

intelligent data with a world of like-minded users. winks: "Some wolves chase
jack rabbits simply because they're fast."

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 11

Basic Patterns
Basic patterns in this chapter include:
- Interface definition pattern
- Property definition pattern
- Property type pattern
- Relation pattern
- Relation definition pattern
- Class definition pattern
- Component schema pattern
- Model definition pattern
- Edge definition pattern
- Graph definition pattern
- View definition pattern
- Shared Object, Expansion, and SameAs pattern

Interface Definition Pattern

is a drummer with the group "Bongo Morley and The Modelers", but his "day

job" is data modeling, which he learned from . Now, he's trying to explain to
the other band members, Hans (lead guitar), Dell (bass) and Deb (vocals), about patterns in
the SmartPlant schema. He says, "The heart of rock-and-roll is the beat, and the heart of
the SmartPlant schema is that objects expose their roles through abstract entities called
'interfaces'. Too bad Hans didn't read "A Gentle Introduction to the SmartPlant Schema",
because now he's wondering what the heck is going on. He keeps thinking that the relational
databases that he's used for the last 20 years are "good enough." Dell rolls his eyes and
Bongo laughs and says, "The Interface Definition Pattern shows how you can think about
creating new interfaces and utilize existing interfaces in an optimal manner." Hans silently
promises to read the Gentle Introduction book tonight, after band practice.

Identity
Interface Definition Pattern

Purpose
Define a standard way for objects to expose their roles to the universe.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 12

 says, "If you're a good old-fashioned relational database (RDB) person, like
Hans, then you might wonder 'what's the deal with roles?'." From a classical RDB point of
view, you think that it's easy to see that a "data dictionary" is the right way to go. You just
define the fields that you want in the records, and load the database tables. Seems real
straightforward. It's OK until you try to define similar properties that wind up in more
than one table - then you've got a few problems.

"Now wait a second", Hans says, "I normalize my tables and create a data dictionary based
on third-normal form (3NF), so there isn't a problem at all!" "Well," Bongo replies, "You
might have a problem simply because data can be more normalized than 3NF. The
SmartPlant schema is mostly normalized to 5NF, which groups things by semantic meaning,
which is stronger than grouping by a key, like 3NF does. Try to concentrate for a minute.
Here is the technical definition of fifth-normal form (5NF):

"Isolate semantically related multiple relationships"

Deb is starting to zone-out. Dell, well, we don't know about bass players, do we? Hans
seems to have some questions building up, but doesn't know how to ask them and not seem
stupid in front of his mates.

Bongo continues. "Hans, you're right in thinking that, usually, related attributes belong
together and that 3NF is usually enough. The need for 5NF becomes clear when you think
about inserts and deletes for records in multiple tables. If you perform entity-relationship
analysis, you'll see that you can optimize updates, and decrease the number of inserts into
some tables, which can mean important savings in time and space." By now, Dell is looking
like something out of time and space. Deb realizes that Dell is playing air bass, and she
recognizes the pattern of the song “Stairway to Heaven.” Hans realizes that he needs to
Google 5NF AND read the Gentle Introduction book. Man, this next week is going to be a
bummer! Bongo sees what's going on and concludes with "a table is in 5NF if it cannot have
a lossless decomposition into smaller tables." Deb is humming “Stairway to Heaven,” and
Hans is looking at his watch.

Bongo, the real leader of the band, tries again. "For example, you might have a property
named PumpColor in your pump table, because that makes sense and is valid to do in a 3NF
database. However, in the SmartPlant schema, all things that are ‘painted’ are isolated from
all things that are ‘pumps’ because the painted surface of the pump is not about ‘pump-ness,’
rather it is about ‘surface-coating-ness.’ That makes life easier from a couple of points of
view:

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 13

 - Valves, vessels, pipes, and many other things in the universe can be "coated" with
paint. The 3NF, RDB way would put a property on each and every object, named,
for example, PumpColor, ValveColor, VesselColor, PipeColor, and so on. In the
SmartPlant schema, any object may realize that it fulfills the role of "being a
painted thing" to the universe. That way, there is only one PaintColor property,
and any object that realizes that "I am a painted item" may announce that fact
to the universe by using the "I am a painted item" interface.
- That makes it easier to control the idea of "things that are painted",’ because
you can model all "things that are painted" in a uniform manner. There might be
some standards that are used for painting, which can be applied in one place -
the "I am a painted thing" interface. If pumps and valves use the same paint
standards, you don't have to have it in the RDB twice.
- If the paint standards get changed, or extended, it is easy to find the interface
that yields up the role of "I am a painted thing", and extend it or correct it. You
don't have to look through each table in your database to see if something needs
changing. Finding all properties that have "color" or "paint" or whatever
somebody called it is pretty hard to do with 100% level of confidence.
- Most important of all - the retriever of the data only needs to look in one place
to find out if the object is painted - s/he looks at an interface that carries the
role of being a painted thing. If the underlying object realizes hey! "I am a
painted thing," it declares that to the universe, by realizing the "I am a painted
thing" interface. If the item is not painted, then it does not realize that
interface. That's called "interface polymorphism" and is a very important topic.

It is important to be able to think about the polymorphic nature of the objects that we're
working on during the holistic engineering design cycle. Suddenly, Deb wakes up: "Back up

there, - what is the meaning of 'a polymorphic pump'?" And Bongo, without
skipping a beat, says, "Here are some examples:"
- A pump is a requirement for increasing pressure in a pipe line (Figure 3)

Figure 3 A Pump on a Simulation Drawing

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 14

 - A pump is on a P&ID, with tag P-142 (Figure 98)
- A pump is in a catalog (Figure 99)
- A pump with a serial number (Figure 100)
- A pump whose dimensions are listed (Figure 4)

Figure 4 ANSI Pump Dimensions

- and so on

"Those are some of the ways that designers and engineers think of pumps, and that's surely
not a complete list. Some of the ideas are shared, and some of them are different,
depending on the engineering discipline involved. For example, the electrical engineer
probably doesn't care about the weight of the pump, but does care about the cable that can
be routed to the motor that drives the pump."

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 15

 Interface Polymorphism

, who is a Phil Collins wannabe, does a little bada-bing on his drum! "THIS IS
REALLY IMPORTANT TO UNDERSTAND!" 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. That is, a client can make
early-bound calls to the properties (and, someday, methods) of the interface without having
to know the class of the object it's using. By creating standard role-based interfaces and
implementing them in multiple classes, the user can take advantage of polymorphism in the
tools that publish and retrieve data from SmartPlant Foundation. For example, a P&ID
pump, a 3D model pump, a PFD pump, and an Equipment data sheet pump all Realize the
IPump interface (in addition to whatever other interfaces they realize).

The schema uses abstract "interfaces" for data exchange. The reasons for doing that 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 being 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 (can be depended on not to change)

Usage

"If you get just one point, get this", says, "Every time that you want to
communicate information about an object in a SmartPlant Enterprise tool, you start by
thinking of the roles that it exposes, the properties that can be exposed by that role, and
the relationships that it can form with other objects. The place that you store all that
information is in an interface, a property, a relationship, and so on, and all of them are
stored in the SmartPlant schema."

An InterfaceDef class is used by (or "Realized by") a "Class" to present the "roles" that the
class exposes to the world.
- An InterfaceDef is "Realized By" a ClassDef
- It exposes properties of the role (via "InterfaceDef Exposes PropertyDef")
- All InterfaceDef classes directly or indirectly "Imply" the Interface IObject
(IObject is for object identity)

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 16

 - An "InterfaceDef" is the end-point of all relationships. This is an important
concept. In older class-based models, relationships were between classes. This
can cause ambiguous meanings of what roles the relationship exposes. Because
interfaces are unambiguous "orthogonal" roles, a relationship between two of
them is unambiguous. An example of an ambiguous relationship would be between
a Person and another Person object, named "Parent-to-Child". While it is true
that a Parent-to-Child relationship is between two Persons, it is more accurate
and unambiguous to say that one Parent-to-Child relationship is between a
Father and a Son.

UML Interface Diagram

Please take the time to review this pattern. It is very important to your understanding of
interfaces - and interfaces are the most important instrumentality in the SmartPlant
schema.

Figure 5 A Sample UML Interface Pattern

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 17

 Let's read Figure 5, shall we? In the center is "an occurrence of a pump" named IPumpOcc,
which has subtypes of pumps listed below, and additional roles that it inherits properties
and behavior from, above. What's an "occurrence of a pump", you say - we'll get there in a
little while (§5.2 covers it). I really hope you already read "A Gentle Introduction to the
SmartPlant Schema", because it tells you about the Implies relationships, transitivity,
stereotypes, and so on.

The Interface Pattern is used extensively in all SmartPlant schema activities. As a pattern,
you will see that it is showing a main "role", and subordinate roles and parent roles - this is a
good pattern to learn.

UML Class Diagram

It is not very common, but you should see a sample of the Class Diagram pattern. Here is a
pump from an equipment data sheet.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 18

 Figure 6 A Sample UML Class Pattern

As you can see from Figure 6, Class diagrams can be very messy. A class "realizes" that it
fulfills a lot of roles, and they all look like the previous graphic on a UML diagram. You can
see why we don't normally produce them, since it's hard to understand what's going on.
When you get to be a better data modeler, you'll understand why the guru said in "A Gentle
Introduction to the SmartPlant Schema" that class diagrams are just "inferred", once the
interface diagrams are complete.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 19

Description of Pattern
An object can have many roles that it presents to the universe. The roles may have
properties and may form associations with other roles. If you think about a "pump" as an
object, what roles does it present to the universe?
 It moves fluid from "point-A" to "point-B"(an engineer might say that "it increases
pressure in a closed system", but not all fluid systems are "closed")
 It has a mechanism that rotates inside of itself
 It weighs something
 It has a tag (a name), a serial number, and a maintenance history
 It is ordered from a certain manufacturer
 There are many types of pumps, each of which can have its own properties
 and so on

Relationships to Other Schema Elements

One of the two reasons that interfaces expose roles to the universe is so that other

interfaces can form relationships with them. explains it this way: If a

Mother has a relationship to a Son, that is an important and distinctly different relationship
from a Mother has a relationship to a Daughter. Both of those relationships are types of
abstract "mother-has-children" relationships. Furthermore, if there is neither a "Son", nor
a "Daughter", there can't be a "Mother"! In other words, a person who exposes the role of
"Mother" to the universe is claiming that she has either a "Son", a "Daughter", or both.
NOTE: we show that in the model with the cardinality "1" on the IMother interface.

Figure 7 Simple Relationship Pattern

OK, Modelers-to-be, let's read Figure 7:

- A Child is related to a Parent by an abstract relationship called Children.
- Sons and Daughters are types of Child.
- Mother is a type of Parent.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 20

 - Sons and Daughters are related to Mothers by relationships that are
specializations of the Children relationship. You'll see this pattern a lot in the
schema

It would be a very complex diagram, indeed, if we were to start showing all the possible
relationships in which, for example, a pump can participate, so let's forgo a UML diagram of
that and use a spreadsheet format instead. As you'll see in Figure 8, below, even that
contains a lot of data.

Figure 8 Relationships that a Pump may Participate in

I’m sure you figured out that Figure 8 doesn't show all the relationships in which a Pump can
participate. The Relationship Pattern for Interfaces that are Realized by a Class might wind
up looking like that, simply because a UML diagram would be a useless plate of spaghetti.

Deeper Meaning
Look back at the Simple Relationship pattern (Figure 7). It illustrates a couple of good ways
to read and write relationships.
 Look at the abstraction pattern (at the top and with the note {abstract}). Relationships
usually start out at a high-level of abstraction, and associate a couple of roles at that
abstract level. See if you understand this: there really isn't a first-class object
somewhere that is some kind of "parent", or "child", but we know that the idea that
many Parents have many Children is valid.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 21

 o What that pattern represents to : "an object that realizes that
it is a Parent can form a relationship with an object that realizes that it is a
Child, via a relationship named Children.
 Notice that the Mother role is a subtype of the Parent role.

o sees the pattern "IMother Implies IParent", and understands

that to mean several things:
 A Parent can have subtypes, one of which is Mother
 A Mother is one type of Parent
 A Mother requires some part of the role of Parent in order to be
"complete"
 There may be many other types of Parent that are not shown on the
diagram.

 Notice that the Son and Daughter are each a type of Child. sees these
patterns:
o ISon Implies IChild (likely meaning: A Son is a type of Child)
o IDaughter Implies IChild (likely meaning: A Daughter is a type of Child)
o He is also thinking that there are two subtypes of IChild for a reason, and
assumes that the roles Son and Daughter are orthogonal to each other (meaning
that the role Son is not the same as the role Daughter).
 Notice that there is a relationship between Son and Mother, namely, MotherSons, and a
different relationship between Daughter and Mother, namely, MotherDaughters, both
of which are specializations of the abstract relationship Children.

o thinks the two different relationships are there for a reason

and assumes that there are special meanings associated to MotherDaughters vs.
MotherSons relationships.
 Look at the pattern on the left-half of the picture, that is, roles that are related via
Implies, and the pattern on the right -half of the picture: roles that are also related via
Implies. The "Implies hierarchy" on either side can't be broken if the lower-level
relationships (MotherSons, MotherDaughters) are going to be types of the abstract
upper-level relationships (Children).
 See the cardinality on both sides of the Children relationship - why is it many-to-many
(0..* is the representation for "many")?

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 22

 o thinks about the pattern: "many children can have many parents,
and many parents can have many children." Remember that another type of
Parent is Father, which is not on this diagram; therefore the many-to-many
relationship Children is valid, even though it isn't explicitly shown.
 See the cardinality on MotherSons and MotherDaughters. Why is it different from the
cardinality on the abstract relationship that is its parent?

o The pattern that sees is a Son has exactly 1 Mother, and a

Daughter has exactly 1 Mother.
o Furthermore, a Mother can have many Sons and Daughters.

That's a lot of pattern knowledge that we got from such a simple diagram, don't you agree?
There are even more patterns "in there", but it is more complexity than you need (right

now). quips: "Do you see that a UML diagram is certainly worth 1.0E3
words?"

Collaborations
Interfaces represent abstract roles that classes of objects present to the universe.
Interfaces may carry properties, and may be related to other interfaces. Classes realize
that they fulfill roles.

Consequences
The Philosophy: "Roles, exposed by interfaces" is a powerful and flexible process for
classifying objects. It avoids the pitfalls of the Linnaean taxonomic model because
different classes of things can just yield up their roles to the universe by realizing that
they satisfy the requirements for that role. Got it? Bada-bing!

Implementation

is in a rush to get to the next gig: "Let's be brief:"

- An interface is a tightly-grouped set of properties, and is thought of as a "role"
that an object yields up to the universe.
- Two interface can be associated via a relationship (a RelDef)
- An object realizes things about itself that it wants to expose to the universe via
interfaces, for example, "I move fluids", "I weigh 200 pounds", "I was purchased
(at Evans Manufacturing)", and so on.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 23

Similar Patterns
Collection Pattern
Composition Pattern

Anti-Patterns
Here are some anti-patterns for the Interface Definition Pattern:
 Interface names that don't begin with the letter "I" are incorrect. (it is a long-
standing practice, and better not to change it.)
o Refactor by changing the name to begin with "I."
 Question why an interface is present in your model if it has no properties and no
relationships. Why should an object expose that role if nobody cares about it?
o Refactor by deleting the InterfaceDef until you are ready to use it.
 If the properties on an interface are only loosely related, you probably don't have a
succinct role for the interface.
o Refactor by splitting out the properties into separate interfaces.
 When adding new properties to the schema, look hard for an existing interface
before creating a new one. Take pity on the retriever of your data. If she sees an
interface for "painted things" and another interface for "things coated with paint",
what's she going to do?
o Refactoring idea: That's the deal about schema -- it's easy to plan for the
retriever upfront. Please try to avoid ambiguous schema concepts that are
"like" each other, but will confuse the retriever.

Property Definition Pattern

During a TV interview last week, told Channel 31's Carmen Diaz "One
of the two major functions of interfaces is to expose properties that belong to the
underlying object. For example, if there is an interface that expresses the role of 'a
rotating item', then you can expect that a property that carries the item's 'angular

velocity' is not far away." Carmen is wondering why thinks that's news.

Identity
Property Definition Pattern

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 24

Purpose

During the interview, said: "Carmen, properties of an object are defined with
a PropertyDef. How properties get onto a particular interface is the subject of much
debate -- some people think that they just wander there, under the influence of a data
modeler who 'doesn't get it', and who is probably under the influence of an intoxicant.
Others claim that there is no rhyme or reason and clearly are frustrated that 'it's too hard
to find the properties that I'm looking for!'."

"The truth is that a good data modeler uses 'data normalization' to tightly-group related
properties and intentionally put them onto the interface that describes that precise set of
functionality. Around here, the data modelers assert that most interfaces are born from
an intentional act of data modeling, but some folks are waiting to hear confirmation of that
in your report on the 5:00 news."

Usage
Simple examples of properties are:
- Weight
- Length
- Color
- and so on

How do we decide where to put properties in the schema? First of all, properties don't
exist in thin air, they're "functionally grouped" and exposed by "interfaces" -- so we have
the first clue.

Next, think about what "interfaces" represent, namely, "abstract roles that classes of
objects present to the universe." To get a deeper understanding of the schema, think about
a "pump" and its properties, and to make it easier, spin ahead to pump roles (in §3.1.6). The
goal of data normalization is to group similar properties on "appropriate" interface. For
example, you expect to see properties about "how fast a pump rotates" on the
IRotatingItem interface, and properties about how much the pump weighs on the
IWeightItem interface. That's where the idea of "data normalization" comes in - it
answers the questions of how to properly group properties and put that group on an
interface.

UML Interface Diagram

Here is a UML diagram of a typical property:

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 25

 Figure 9 UML Diagram of Typical Property

The property "dry, stripped weight", which is named Dry_Stripped_Weight is exposed by

interface IWeightItem (and I hope that makes sense by now), and its type is MassUoM,
meaning that "dry, stripped weight" expects values to be expressed in "mass units."

Remember - the IWeightItem interface can expose other properties, for example:

UML Class Diagram

A property definition (PropertyDef) is a schema element that looks like this:

Figure 10 PropertyDef Class Diagram

Read Figure 10 -- let's see what it says:

- The component schema for PropertyDefs is "MetaSchema"

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 26

 - The model for a PropertyDef is "MetaModel"
- A property has identity (IObject)
- A property is a property definition (IPropertyDef)
- A property is mappable (IMappableProperty)
- A property is a schema object (ISchemaObj)
- The rest of this stuff is not used outside of the schema

Description of Pattern

So asked: "Are you saying that a property is:

- Defined by: a PropertyDef
- Exposed by: an interface (InterfaceDef) - in fact, one of the two principal
purposes of an interface is to tightly group similar properties and expose them
to the universe.
- Scoped by: a type. All properties in the schema have a defined type so that
tools can publish and retrieve data without wondering what some values might
be."

"Right on, Carmen!" exclaimed. He knew that the news broadcast tonight
would be very different from the normal fare of war, gas price increases, and politics.

Meanwhile, Carmen is picturing herself with an award for innovative reporting .

Relationships to Other Schema Elements

A property is defined by a PropertyDef and has two relationships, namely, a ScopedBy
relationship to the proper type and an Exposes relationship to the interface that groups
similar properties. Properties are also used to map between equivalent properties in a
SmartPlant Enterprise tool and the schema.

Collaborations
Properties are mapped to by SmartPlant Enterprise tools that want to publish or retrieve
data that matches the property. For example, a tool might want the weight of a pump, and
map their property named PumpWeight to the schema property named, for example,
Dry_Stripped_Weight.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 27

Consequences
Properties carry values from one tool to another. Like a little string of sugar-ants, each
carrying 1 grain of sugar out of your kitchen, each property carries one nibble of
information from you to another tool. Good luck, little ants! If you figure out this stuff,
please let me know.

Implementation
A property is defined by a PropertyDef. A property declares that it is a certain "type", via
the ScopedBy relationship. A property is exposed to the universe by an Exposes
relationship (from an interface).

Similar Patterns
N/A

Anti-Patterns
There is one very obscure anti-pattern relating to property definition: If you use a multi-
level list to scope a property, then you can't use the same mid-level EnumListLevelType to
scope two properties on the same interface.
Refactor to put those property definitions on different interfaces.

Property Type Pattern

It was naptime, and was reading Aesop's Fables to his grandkids, Bill and
Laura, and apparently, "The Fox and Stork" were at it again - they couldn't agree on how to
drink soup, or eat dinner, or, most importantly, how to exchange data between their
software tools.

He told the kids: "The SmartPlant schema forces agreement on many issues between the
participants of the SmartPlant Enterprise. Here's the deal: if you want to be a conforming
SmartPlant Enterprise tool, you need to agree to a certain set of rules to make sure that
data ambiguity is eliminated (or minimized), and that other tools with whom you interact are
clear on the issue of what you will publish and what you expect to retrieve. Properties that
are exchanged between tools are restricted to agreed-upon types with this pattern."

Identity
Property Type Pattern

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 28

Purpose

"Ha! Look at this picture, Bill", continued, "The Fox thinks that the length of
a ladder is measured in 'feet', and the Stork thinks that it is better to measure a ladder
using 'meters', so it's "Houston, we've got a problem!"

Bill and Laura were getting sleepy, so decides to sneak in an even worse
situation - he shines a flashlight up on his face and tells this scary story: "Once upon a time,
a fairy-tale creature thought that 'feet' was fine for measuring something, and another
creature, in the same story, thought that 'pounds per square inch' was the way to go. You
can imagine how that story ended! When tools participate in the SmartPlant Enterprise
solution, they must agree on the type (also known as ‘scope’) of a property before they can
publish or retrieve data. Otherwise, this would just be a fable about a Fox and a Stork!"

When says, "A property is scoped by a type," he means that both parties in a
data exchange know what "type" the data is before they publish and retrieve it.

Usage
There are several ways to classify (or "scope") properties:
- Simple types (also known as intrinsic types):
o Boolean
o Date & Time
o Double
o Integer
o Path (not currently used)
o String
o Year/Month/Day
- Enumerated values
- Enumerated lists of values, including multi-level lists
- Units of measure (a type of enumerated list of values)

UML Interface Diagram

When you see a property (IPropertyDef), it is scoped by one of these types
(IPropertyType):

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 29

 Figure 11 IPropertyType UML Diagram

Some of the types are 'internal', so we won't discuss them, but the rest are pretty easy to
understand.

UML Class Diagram

Each of the property types has a class diagram that looks like Figure 12:

Figure 12 Example of PropertyType Class Diagram (UML)

Reading Figure 12 is pretty easy. What you need to understand is that the DoubleType
class will allow and disallow values that the user enters into the property field. The "Double
type" allows digits, a single decimal point, and so on. If you try to publish a value that has
the letter "Q" in it, the publish will fail because the letter "Q" is not allowed by the
DoubleType class.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 30

Description of Pattern
The Property Type Pattern guarantees that data elements are "scoped", or "restricted to"
as accurate a representation as possible. For example, if the Fox publishes a document with
the string "1.32", what does it mean? It should seem curious to you that the value seems to
be a precise number, but that we can't figure out anything else about it. Is it a currency
amount? Temperature? Pressure difference between inlet- and outlet- on a pipe run?
What?

Loosest Scoping is by "String"

Because we don't know anything else about "1.32", we just don't have much in the way of
"semantic meaning" to go on. Could the next record be "X.32"? We just don't know, and
can't guess. That seems like it isn't the best possible situation for exchanging data
between tools - but sometimes, it is just fine. For example, the string "Jones, John" is a
perfect example of a "string" that is probably OK to exchange. We may not need any more
precision than that!

Scoping by Intrinsic Types

We can tighten up the semantics a bit by using the intrinsic (built-in) types:
- Integer
- Double
- Boolean
- and so on

If the Stork tries to publish the string "1.32", and the type is "integer", we know that's an
error, because the rule for integer scoping does not allow a decimal point.

The same deal is true for a "Boolean" field that we try to publish that has "GREEN" in it - it
will fail validation. Can you see how useful this is? The retriever of the data can have
confidence that what he retrieves is probably very good data, because you are going to have
a hard time publishing bad data!

Enumerated Values
Let's think about the common traffic control device called a "stop light." I bet that you
know what to do in each of these scenarios:
- Light is RED
- Light is YELLOW
- Light is GREEN

You already know that that's the entire set of values that you can use. Why not make life
on the publisher and retriever easy by making a list that just contains those values, and
then "scope" a property by that enumerated list?

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 31

 says, "Here is the set of all known StopLightColors {RED, YELLOW, GREEN}.
Now that should be a real confidence-builder for both publisher and retriever of data.
Could we have used a "string" type? Sure. Is this approach better? Probably. It
eliminates the possibility of a tool publishing "rEd" instead of "RED." The retrieving tool
doesn't have to expect "rEd" as a possible value, because it can never be published." The
finite set of enumerated values helps when querying data from the SmartPlant Foundation
database, as well. Remember: the schema is not just about data exchange, but it is also the
model for "persistence" in the database.

Multi-Level Enumerated Lists

Sometimes it is very convenient to think of multi-level type hierarchies, for example:
- Equipment
o Process equipment
 Material transfer equipment
• Fluid-transfer machine
o Pump
 Centrifugal pump
• Horizontal centrifugal pump

Once again, you can see that if the schema can enforce that hierarchy, it is much easier for
the retrieving tools to act on whatever data they get (because a horizontal centrifugal pump
can't show up under the wrong branch of the hierarchy). Now, let's see how we can encode
that list of hierarchical values in a useful way.

Multiple Properties, Scoped by Different Levels

Looking at that equipment classification hierarchy, we see 7 levels. Here's a little trick
that the schema implements to keep everything straight:

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 32

 Figure 13 Multi-level Enumerated List in Properties

What do we mean? We're trying to exchange a 7-level hierarchy, so we put 7 properties on

an interface (an InterfaceDef Exposes 7 PropertyDefs):
- Property 1 is scoped by the multiple-level enumerated list (EnumListType)
- Property 2 is scoped by values that are valid for level 2 of the hierarchy
(EnumListLevelType)
- In a similar manner, Property 3 through 7 are scoped by values that are valid for
their level (EnumListLevelType)

What are the valid values for level-2 through level-7 of the hierarchy:
- For level-2, the set of values identified as {any value from level-2 of the
hierarchy}
- For level-3, the set of values identified as {any value from level-3 of the
hierarchy}
- and so on

Walking down the tree from the root to branch, to branch, finally to a leaf is easy to do by
the "publish" software, and makes it easy for the "retrieve" software to have confidence
that the values that it gets are correct.

Here is a portion of the "equipment" hierarchy:

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 33

 Figure 14 Partial Equipment-Type Hierarchy

- The entries in column P1 scope property 1

- The entries in column P2 scope property 2
- and so on (It's so much fun to say “and so on”, because that implies that you are
capable of figuring out the pattern that is involved, and that's what this book is
all about.)

Fire up the released schema (using the SmartPlant Schema Editor) and you can see all the
multi-level lists, and how they are used to scope properties.

Relationships to Other Schema Elements

Property types are related to intrinsic types and enumerated lists (which include units of
measure).

Collaborations
"Scoping a property" is an important part of the schema, and an important part of the
overall strategy of making data that flows through the SmartPlant Enterprise accurate and
unambiguous. Because tools are "loosely integrated" to each other, it is especially important

for all tools to exchange properly scoped data. asserts: "Types make the data
trustworthy."

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 34

Consequences
Schema support for property types increases the probability that tools will succeed in
exchanging properties. If one tool publishes "3 meters" and the retrieving tool only
understands "feet", that's OK, because an automatic conversion is performed by the
SmartPlant system. We won't say that this ends all the problems between the Fox and the
Stork, but it goes a long way towards getting them to sit down to a meal and not be
genuinely rude to each other.

Implementation
When you are going to scope a property with a type, there are two basic approaches:
- If the property is scoped by an "intrinsic type", then just pick the appropriate
type from the Schema Editor
- If the property is scoped by an enumerated list, there are two sub-categories:
o Enumerated value list
 If the list already exists, this is a no-brainer
 If you need to create a new list, the Schema Editor allows you to
do that as a child process to the property-scoping user interface
o Multi-level enumerated value list
 This is more complex because you need to plan out how many
levels there are in your multi-level list
 Use an existing list or create a new one
 Create a property for each level (PropertyDef)
 If you create a new multi-level list, don't forget to create an
EnumListLevelType entry for each level from 2 to n. That is
what you will scope the appropriate property, at that level.

Similar Patterns
Units of measure lists are similar to enumerated value lists, and are, in fact, children of
enumerated lists.

Anti-Patterns
The Mars Climate Orbiter Spacecraft was lost because one NASA team used imperial units
while another used metric units for a key spacecraft operation. The confusion over units
was identified in preliminary findings by JPL's internal peer review. "People sometimes
make errors," said Dr. Edward Weiler, NASA's Associate Administrator for Space Science.
"The problem here was not the error, it was the failure of NASA's systems engineering, and
the checks and balances in our processes to detect the error. That's why we lost the
spacecraft." Did he mention that the parachute deployed at 3 times the height that it was
designed for, and the spacecraft crashed so badly that they've still not positively identified
the remains on the surface of Mars? To phrase it another way: "100,000 feet, 100,000
meters, who checks that at data interchange time? Why would anyone use anything other
than 'feet' as a length? "

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 35

 opines: "Maybe they should have used the Property Type pattern." Is that
the sound of the Stork laughing or is he just choking on a fish?

Relation Pattern
The Relation Pattern is used to associate two schema objects to each other, following a
defined set of rules that are encoded in the meta schema. As we said before, a Class
Realizes Interfaces, which Expose properties that are Scoped by Types. Let's find out
what makes that phrase "operational."

Identity
Relation Pattern

Purpose
SmartPlant schema elements are related to each other in some way, via the Relation
Pattern. For example, classes are related to interfaces, which are related to properties,
which are related to types, and so on.

Usage
Schema elements are related to other schema elements using the Relation Pattern. Keep in
mind that we're not talking about relations that get "published" by a tool, rather, these
relationships are embedded within the schema, and are defined in the meta-schema. There
are 68 relationship definitions in the meta-schema Here are the most important ones:
- Componentization (§ 3.4.4.1)
- Contains (§ 3.4.4.2)
- EnumMetadata (§ 3.4.4.3)
- Exposes (§ 3.4.4.4)
- HasDefaultSI (§ 3.4.4.5)
- Implies (§ 3.4.4.6)
- Instantiates (§ 3.4.4.7)
- ModelClass (§ 3.4.4.8)
- PrimaryInterface (§ 3.4.4.9)
- Realizes (§ 3.4.4.10)
- ScopedBy (§ 3.4.4.11)
- Sharing (§ 3.4.4.12)
- UoMConditions (§ 3.4.4.13)

As we have said, the schema is defined by a meta-schema that has a built-in idea of how
relations between schema objects work. In other words, there is a built-in "relationship
definition" object (RelDef) in the meta-schema for each of the above-mentioned
relationship definitions.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 36

 explains it like this: (Roll up your sleeves and look at Figure 15, below:)

Figure 15 Sample Relationship Definition in Meta-Schema

"It shows a 'relationship definition' in the meta schema named 'Contains' which defines the
relationship between an object that exposes the role of being an enumerated list
(IEnumListType) and the objects that are the enumerated values that are in the
enumerated list (IEnumEnum). When you want to add an enumerated value to an enumerated
list, you will use the Contains relationship definition. When you do that, you will wind up with
a relationship between an enumerated list entry and an enumerated value, and that
relationship will have a stereotype of <<Contains>>."

Look at a sample UML diagram of an enumerated list that contains a couple of values:

Figure 16 Enumerated List Contains Values

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 37

 The schema that is generated by the Schema Editor looks like this (abbreviated example):

<EnumListType>
<IObject UID="ACDC" Name="AC/DC""/>
</EnumListType>

<EnumEnum>
<IObject UID="UID_DC" Name="DC"/>
</EnumEnum>
<EnumEnum>
<IObject UID="UID_AC" Name="AC"/>
</EnumEnum>

<Rel>
<IObject UID="{8969062D}"/>
<IRel UID1="ACDC" UID2="UID_DC" DefUID="Contains"/>
</Rel>
<Rel>
<IObject UID="{F4A083DD}"/>
<IRel UID1="ACDC" UID2="UID_AC" DefUID="Contains"/>
</Rel>

In particular:
- Do you see how the stereotype <<Contains>> in the UML diagram wound up as
DefUID="Contains" in the schema file? That's how the schema and meta
schema elements are bound together
- Do you see how an instance of the relationship definition for "Contains" became
a relationship object (Rel), in the schema

UML Interface Diagram

In the rest of this chapter, each of the meta schema relationship definitions will be shown
separately.

Componentization
Section §3.7 contains a complete description of the Component Schema Pattern. In brief,
each class definition (ClassDef) must belong to 1 "component schema".

Figure 17 Componentization Relation Definition UML Diagram

Component schemas are used to group classes so that the entire schema does not need to
be stored on every SmartPlant Enterprise client computer. Because the schema is large,
we're looking for a little optimization with this trick. For example, the SmartPlant P&ID
software probably doesn't need all the Smart 3D class definitions, because it won't use
them anyway.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 38

Componentization Example
Figure 18 shows 3 classes (of many) that are in the "Equipment data sheet" component
schema:

Figure 18 Componentization Relation Example

That means that when you use the Schema Editor to generate a component schema file that
is based on "EquipDataSheet", the resulting file will contain all the classes that have the
"Componentization" relationship to "EquipDataSheet."

Contains
Enumerated lists (EnumListType) contain enumerated values (EnumEnum).

Figure 19 Contains Relation UML Diagram

For example, the graphic below contains the "Pipe slope direction" enumerated list. Now
that you know what the meta schema looks like, see if the schema makes sense to you.

Figure 20 Contains Relation Example

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 39

EnumMetadata
Interfaces (InterfaceDef) can be refined (made more specific) by "typing" them by using
the "EnumMetadata" relationship. Let's see what that means.

Figure 21 EnumMetadata Relation UML Diagram

Figure 21 shows the basic relationship between an enumerated entry (IEnumEnum) and a
role named "IEnumMetdata", namely, the thing that enumerates it.

Figure 22 EnumMetadata Relation Example

Reading Figure 22, we see that:

- On the left, "Nozzle" is an enumerated list (EnumListType)
- IEnumListType Implies IenumEnum; therefore, by transitivity, the enumerated
list "Nozzle" can be on End 1 of the EnumMetadata relationship
- INozzle is an interface (InterfaceDef)
- On the right, InterfaceDef Implies (= is a type of) IenumMetadata; therefore,
by transitivity, the interface INozzle can be on End 2 of this relationship
- Therefore INozzle may have a relationship with an enumerated list of values
named "Nozzle"

Which can be restated as INozzle can be "refined by" values in the Nozzle enumerated list,
which currently contains the values shown in Figure 23

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 40

 Figure 23 Nozzle Types

So you see that a single INozzle interface can be further refined by supplying a nozzle
"type." Why bother? Well, some tools don't care about the type of a nozzle, but some do.
Whatever SmartPlant Enterprise tool "knows" the nozzle type is free to publish it, and from
then on, whoever retrieves it, has the data available.

Exposes
One of the most fundamental ideas in the schema is that an interface exposes properties.

Figure 24 Exposes Relation UML Diagram

If some item has "wet weight" and "dry weight", you should be thinking, "Look for those
weight properties on the IWeight interface." If an item loses pressure, you're thinking,
"Look for the pressure drop amount on IPressureDropItem", and so on. These little
factoids are due to the process of data normalization that was used to create schema
elements. When you can define the role that an item "yields up to the universe", you
automatically group relevant properties concerning that role, and place them together on
that role. Simply translated, that means that interfaces (roles) expose properties.

rushes in and says: "Please note the cardinality on the

ExposedByInterfaceDefs role. It is 1..*, which means that a property may appear on more
than one interface. In a highly-normalized model that is generally not a good idea, but
there are extremely rare exceptions that are accommodated by that cardinality."

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 41

 Figure 25 Exposes Relation Example

Figure 25 shows a few properties that are exposed by an interface. The rules of data
normalization control what properties are selected for that particular role.

HasDefaultSI
Every unit-of-measure list (UoMListType) has exactly one value that is defined to be the
"base" SI unit. Of course, the phrase "SI unit" refers to the International System of
Units, and is abbreviated by "SI".

Figure 26 HasDefaultSI Relation UML Diagram

For example, in the case of length, the SI unit is "meter"; for mass, it is "kilogram", and so
on.

Figure 27 HasDefaultSI Relation Example

Implies
An interface (defined by InterfaceDef) may imply other interfaces.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 42

 Figure 28 Implies Relation UML Diagram

The extreme power of that simple statement lies in the underlying philosophy of using a
highly-normalized data model. An interface carries a tightly-defined "role", and you might
ask, "Why would one role need to imply another role?"

says that one interface implies another interface for one of two reasons:
- The implying interface (the child) is a "type of" the implied interface (the
parent). For example, IPump implies IFluidTransferMachine because a pump is a
type of fluid transfer machine.
- The implying interface (the child) requires the implied interface (the parent) in
order to fulfill its total role-ness in the universe. For example, you might think
that a control valve (IControlValve) results in the loss of pressure in a pipe line;
therefore, to accurately describe how a control valve realizes that it is a
pressure drop item (IPressureDropItem), you would expect the model to say
IControlValve Implies IPressureDropItem.

Figure 29 Implies Relation Example

Instantiates
An object is created from a class definition (ClassDef) with a "class factory."

Figure 30 Instantiates Relation UML Diagram

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 43

This is an internal thing that the schema component uses, and it is only mentioned here for
completeness. For deeper understanding of why one needs a "factory" to create classes,
refer to the Design Patterns book, "Factory Method."

Figure 31 Instantiates Relation Example

ModelClass
Each class (ClassDef) belongs to exactly one model (ModelDef). The idea of "models" is
from the POSC/Caesar concept of facility vs. material.

Figure 32 ModelClass Relation UML Diagram

Current model definitions are:

- Actual material (ActualMaterialModel) also known as "Asset" model
- Facility model (FacilityModel)
- Meta model (MetaModel)
- Organization (OrganizationModel)
- Planned material (PlannedMaterialModel) also known as "Tag" model
- Typical material (TypicalMaterialModel) also known as "Catalog" model
- Work breakdown (WorkBreakdownModel)

Figure 33 ModelClass Relation Example

Primary Interface
Each class (ClassDef) must realize one "Primary Interface." A primary interface defines
the essential roles for an object.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 44

 Figure 34 PrimaryInterface Relation UML Diagram

You must understand this: The Primary Interface carries all the roles that the object is
capable of realizing. To state that a different way, the Primary Interface implies, either
directly or indirectly, all the interfaces that the object might be able to realize. Think
about it: that makes the Primary Interface like a fingerprint - it is unique in the universe.

Figure 35 PrimaryInterface Relation Example

Realizes
A class (defined by a ClassDef) realizes its roles with this relationship.

Figure 36 Realizes Relation UML Diagram

The "Primary Interface" (along with its implied interfaces) defines the "domain" of roles
(which roles an object may possibly yield up to the universe), but the Realizes relationship
defines the "range" of roles (those roles which are actually supported by an object). For
example, a Primary Interface IA might directly or indirectly imply IB and IC and ID (which
means IA might be a type of IB, IC or ID, or might require part of one of those roles to
complete its mission in life), but a tool is under no obligation to realize any of those roles
when it actually publishes an object (maybe a particular tool only cares that IA is a type of
IC, so it does not need to realize IB or ID).

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 45

 Figure 37 Realizes Relation Example

The Realizes Relation Example shows a few of the interfaces that a class can Realize. By
now, you should be thinking, "a class is just a convenient way to group a bunch of roles
together and cause an object to come into existence, with those properties tagging right
along."

ScopedBy
A property (defined by PropertyDef) is scoped by a type (PropertyType). Please review
Property Type Pattern in §3.3 before reading this.

Figure 38 ScopedBy Relation UML Diagram

A property type must be (notice the cardinality of "1") thought out before you can publish
data, so that the retriever of the data doesn't have a big problem figuring out what you
meant.

Figure 39 ScopedBy Relation Example

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 46

Sharing
An object, which is an instance of a class, may be "shared" by different tools.

Figure 40 Sharing Relation UML Diagram

Sharing gives SmartPlant Enterprise tools the ability to contribute to the data that is
published to the SmartPlant Enterprise database. This is particularly useful in a
collaborative engineering environment (where different engineering processes contribute
different properties to the objects that make up the final facility). For example, an
instrument is defined by many different tools, each of which has a partial idea about the
instrument, as they see it.

Figure 41 Sharing Relation Example

Like your kindergarten teacher told you: "Sharing is good." But which tools get to share
things? Let's say that the SmartPlant P&ID program publishes an instrument named
PIDInlineInstrument. First of all, an instrument appears on a P&ID drawing for a reason,
namely, someone plans to purchase it and install it. Therefore, an instrument that is
published by SmartPlant P&ID is in the "Planned Material" model (planned material = a plan
to purchase something). In the schema, the class PIDInstrument has a "Sharing"
relationship with SharedInstrument_PM, where "PM" stands for "Planned Material."

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 47

Now, let's say that other tools, for example, SmartPlant Electrical, Smart 3D, and so on,
want to change or enhance the data about that instrument (before or after SmartPlant
P&ID published it). The appropriate classes in those tools, that is, ELEInstrument,
EQDControlValve, and so on, should also have a Sharing relationship to
SharedInstrument_PM and are therefore allowed to publish their classes to the SmartPlant
Enterprise database. The SmartPlant Enterprise tools are also allowed to establish a
relationship between their object (a specific instrument) and equivalent object(s) in the
database (other instruments) by a process called "correlation." A single "valve" can be
published by many tools, each of which increases the total knowledge about that valve, until
everything that is "relevant" is known. See §4.6 for a lot more on the subject of "shared
objects."

UoMConditions
A unit of measure list (defined by UoMListType) may have "conditions" that are required in
order to make the reading unambiguous. For example, a pressure gauge may have a readout
in "Gauge" or "Atmosphere", which differ by 14.7 psi. And if you think that's not important,
NASA would disagree (see anti-pattern).

Figure 42 UoMConditions Relation UML Diagram

Because of that little factoid, it is important to state, for example, "pressure conditions"
(meaning the conditions under which the reading is being taken), before publishing data, else
the retriever will have a heck of a time trying to figure out what was meant. And that
designer isn't getting paid to be a mind reader (oh, that's you - sorry).

Figure 43 UoMConditions Relation Example

An example of a published data file, using unit of measure with condition follows:

<PIDInlineInstrument>
<IObject UID="B168E6E8" Name="0D0-PV-7201"/>
...several lines omitted...
<IDesignConditions DesignPressMax="5 barg @Gauge"/>

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 48

 </PIDInlineInstrument>

Because of that "@Gauge" identifier, I bet the retriever now knows exactly what the "5"

means. (Cheering in background.) has defeated data ambiguity once again!

UML Class Diagram

In summary, the most important relationships are shown in this chapter:

- Componentization (§ 3.4.4.1)
- Contains (§ 3.4.4.2)
- EnumMetadata (§ 3.4.4.3)
- Exposes (§ 3.4.4.4)
- HasDefaultSI (§ 3.4.4.5)
- Implies (§ 3.4.4.6)
- Instantiates (§ 3.4.4.7)
- ModelClass (§ 3.4.4.8)
- PrimaryInterface (§ 3.4.4.9)
- Realizes (§ 3.4.4.10)
- ScopedBy (§ 3.4.4.11)
- Sharing (§ 3.4.4.12)
- UoMConditions (§ 3.4.4.13)

Description of Pattern
The Relation Pattern associates two schema elements to each other. Quite possibly, you're
not used to explicit relationships between schema elements. For example, if you're used to
working with a database, you don't think much of how a class and its properties are related,
relying instead on a data dictionary and the built-in SQL query facility to make all that
happen.
However, the SmartPlant schema is a 'living' schema, and it changes and evolves over time.
One of the most powerful things about the SmartPlant schema is the ability for the schema
to evolve, and for the tool users to know how schema evolution will impact them. By having
explicit relationships between the different schema elements, it becomes a manageable
problem to communicate to tools 'what changes have taken place since last time I got a
schema?'. Using the schema component, one schema can be compared with another schema,
and a set of 'instructions' is generated that clearly states what changes happened. Because
every relationship between every schema element is a first-class object, with its own UID,
it is very easy to track changes, additions, and deletions that have happened.

Relationships to Other Schema Elements

Relations are everywhere in the meta schema and in the schema, and each one is defined by
a relationship definition (a RelDef).

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 49

Collaborations
Relationships between schema elements are what make the SmartPlant schema work! It
doesn't do much good to have a class that doesn't realize some role(s), so the Realizes
relationship is used. Lists of values Contain enumerated values. Properties are ScopedBy
types, and so on.

Consequences
Using the Relation Pattern is an essential part of schema development. ALL schema
elements are related to other schema elements via a Relation.

Implementation
How should the data modeler and the tool developer view the Relation Pattern? It is so
fundamental to the schema, and to published and retrieved data, that it is clearly a building
block that can't be over-emphasized in importance. You must understand the idea of a
Relationship in order to succeed! For example, you are related to your mother. In your role
as a data modeler, you should be able to "abstract" that idea to the idea that any child has a
mother, then any child has parents, then any item may have zero or more parents. When
you develop or use the SmartPlant schema, you will see that the most common schema
element is the Relationship.

Similar Patterns
N/A

Anti-Patterns
Gauge vs. Absolute pressure became an issue in January 1967, when Roger Chaffee, Virgil
Grissom, and Edward White were killed at Cape Kennedy during a training exercise for the
Apollo 1 mission. The crew died as a result of a fire within the spacecraft cabin. The flash
fire occurred in command module 012 during a launch pad test of the Apollo/Saturn space
vehicle being prepared for the first piloted flight. The investigation pinpointed the cause
and made specific recommendations that led to major design and engineering modifications
and revisions to test planning, test discipline, manufacturing processes and procedures, and
quality control.

One of the main findings was that the test was conducted with a 16.7 pounds per square
inch absolute, 100-percent oxygen atmosphere (which was ignited by electrical arcing).
"The crew was never capable of effecting emergency egress because of the pressurization
before rupture and their lack of consciousness soon after the rupture." Author's note: the
test pressure should have been 5 psi absolute, which is actually LESS THAN atmospheric
pressure by quite a bit!

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 50

Relation Definition Pattern
As you saw in the preceding chapter, the Relation Pattern is used to associate two schema
objects to each other. Now we'll discuss the Relation Definition Pattern (defined by
RelDef), which is used to define how that happens.

Objects expose their roles through abstract entities called "interfaces." Relation
definitions are used to define the association between two interfaces. A relation definition
is one of the most complex structures in the schema, and you really need to be on your toes
when creating new ones, or trying to interpret existing ones. Some of the complexity comes
from:
- Lots of properties on a Relation Definition (RelDef) (because it actually is a
complex structure)
- Intense concentration is required to think about several levels of what's being
expressed:
o The Relation Definition itself, as a schema element (RelDef)
o How it will be instantiated in a published document (as a Rel)
o How it will be used by tools to relate objects
o How its rules will be enforced by SmartPlant Foundation

warns: "Some ideas are simple and easy, for example, how to turn on a light
switch. Some ideas are simple, but not easy, for example, how is the circumference of a
circle related to the diameter. This topic is not simple and it's not easy." So go grab a
cuppa' Joe and stay alert!

Identity
Relation Definition Pattern

Purpose
Forming relationships between objects is very common in the world around us. Let's discuss
two important ideas about relationships:
- How do we define a relationship between objects?
o Abstract relationships
o Concrete relationships
- How does a tool publish a defined relationship?

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 51

Defining a Relationship Between Objects
We say, for example, "a bicycle has wheels" or "a man marries a woman" or "a compressor
spool has nozzles", and from those statements, we form certain mental images:

Figure 44 A Bicycle, a Man Marries a Woman, a Compressor Spool has Nozzles

We're thinking of a bicycle and its wheels, a husband and his wife, a compressor spool and
its nozzles. With respect to the schema, we're thinking of how to define those
relationships so that those ideas can be correctly and unambiguously published and
retrieved by SmartPlant Enterprise tools.

Thinking of "classes of things": a bicycle belongs to a class of objects called "vehicles".

Other members of the class of "vehicles" include trains, motorcycles and automobiles, and
so on, but they all have some "vehicle-ness" in common, so we call them "vehicles."

Thinking of "Relations", they are defined in a similar manner, for example, marriage belongs
to a "class of relations" between men and women. Other "class of relations" members might
include mothers and sons, brothers and sisters, and so on, and they all have something in
common, so we group them as "class of relations between men and women."

The Initial Thought Process for a Relationship Definition

During our analysis phase, we need to ask a domain expert questions like these:
- Q: Do all bicycles have wheels?
o A: Yes
- Q: How many wheels can be on a bicycle?
o A: 2 is most common, but any small number is probably OK. Also, 3 or 4
seems to be OK.
- Q: If the designer deletes the bike frame from a design drawing, what's the
deal with the wheels, that is, do they go away, too?
o A: Yes - If no "design bike", then no "design wheels"

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 52

 - Q: Is there a more generic, or "abstract" idea that we could base this idea (of
bicycles and wheels) on?
o A: Yes, for example, all common vehicles have wheels
- Q: What role does a bicycle play with wheels?
o A: It is a collection of (usually) 2 wheels (actually, 0 or more)
- Q: What role do wheels play with a bicycle?
o A: They are owned by a bicycle
- and so on

Now that we've done some preliminary systems analysis, we're ready to put the new
relationship definition into the schema, right? Wrong-o! Now, we're ready to look for
something that is already in the schema that is similar to what we're about to add and use
it, if possible.

Equipment Nozzles Example

Look back at Figure 44 and then below at Figure 45. If you plan to publish, for example, a
P&ID document, with a

Figure 45 Equipment Nozzles Relation Definition

relationship between an object that is classified as "equipment" (maybe a compressor) and

its nozzles, then you need to know what "constraints" are on that relationship, for example:
- How many nozzles can be on a compressor? (what is the cardinality)
- If the compressor is removed, that is, deleted from a P&ID, do the nozzles go
away, too? (is there delete propagation)?
- Do the nozzles have some kind of sequence? (what is the ordinality)
- and so on

Figure 45 directly relates equipment and nozzles, but it has a "parent" Relation Definition -
EquipmentComponents, so the whole thing looks like this:

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 53

 Figure 46 Relation Definition Showing Inheritance

Read Figure 46 along with

- Equipment (is defined by IEquipment) can have related components
(IEquipmentComponent) via the EquipmentComponents relation definition, but
that relationship is "abstract", and therefore can't be published.
- A nozzle (is defined byINozzle) is a type of equipment component
- A compressor (is defined by ICompressor) is a type of equipment
- Therefore a Compressor can have a collection of (0 or more) Nozzles via
EquipmentNozzle relation definition

Usage
The Relation Definition (RelDef) that you specify in the schema is enforced when you
publish a document that contains a relationship (Rel) between two objects. Recall that a
relationship (Rel) is simply an instance of a relationship definition (RelDef).

pushes up his glasses and says: "There seems to be an awful lot of properties
on a relationship definition, and it will take you a while to understand them all, but be
patient and you will succeed."

Here are the basic properties of a Relation Definition:

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 54

 - Name (this is also the UID of the relationship definition) - choose something
meaningful, for example, EquipmentNozzle, MotherSons, Marriage, and so on.
- Description - something meaningful
- Ordering
o Neither relationship collection is ordered
o Relationships from end 1 to end 2 are ordered
o Relationships from end 2 to end 1 are ordered
- Link interfaces (link attributes is a whole topic)
- For correlation
o Identities of related objects are independent
o Identity of object at end 1 depends on object at end 2
o Identity of object at end 2 depends on object at end 1

As you saw in Figure 46, some Relation Definitions are specializations of other Relation
Definitions, so you need to know:
- Is this an "abstract” or "standard" relationship?
- Is this a "specialization" of another Relation Definition?
- Ties into hierarchy defined by relationship definition

Each end of the Relation Definition has some properties:

- What Interface are we referring to?
- What is its role?
- The "display name" of the role
- Minimum cardinality - minimum number of objects
- Maximum cardinality - maximum number of objects
- Object at end 1 or 2 has been published by ...
o Must be in same container as object 2
o Must be published by same tool as object 2
o Has been published by another component
- Filter out edge in display? (a SmartPlant Foundation-only property)

Certain rules can be defined and enforced by the SmartPlant Foundation software (which
runs at the heart of the SmartPlant Enterprise), that is:
- Delete behavior
- Copy behavior for object 1 or 2
o Copy object at end 2 or 1
o Copy relationship to object at end 2 or 1
o Don't copy object or relationship
- Do we need to publish objects on both sides of a relationship now, or can the
other side wait until later?

UML Interface Diagram

If it seems like a lot of stuff is needed just to define a relationship between two objects,
just look at Figure 47, below, you can see how complex this really is.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 55

 Figure 47 IRelDef UML Diagram

UML Class Diagram

The class diagram for a RelDef follows:

Figure 48 RelDef Class Diagram

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 56

Description of Pattern
Using the Relation Definition Pattern, relationships can be defined between any two roles
that make sense. The resulting Relation Definition (RelDef) is used at the time that a
document is published, to instantiate a relationship between two objects and to enforce
constraints on that relationship.

Relationships to Other Schema Elements

Relationship definitions are related to two schema elements:
- Other Relationship definitions (RelDef), via "Inheritance"
- Interfaces (InterfaceDef)
- Edges (EdgeDef)

Collaborations
Relationship Definitions are used to spawn Relationships. The RelDef contains the rules for
how the Relationship is supposed to interact with the world.

Consequences
If you use the Relationship Definition pattern, the result will be a well-defined hierarchy of
abstract and concrete relationships that can be published by one tool and retrieved by
another tool. Remember: it is very important to think about the retriever of the data -- any
ambiguity in the SmartPlant schema makes it very difficult for the poor woman who's
writing the retrieval logic to figure out what relationship you're talking about.

Implementation
Because there are exactly two ends to a relationship definition, pick one and relate it to the
other. Over time, we have evolved the idea that picking the "many" side first seems to be a
good pattern.

Similar Patterns
Collection Pattern
Composition Pattern

Anti-Patterns
N/A

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 57

Class Definition Pattern
If you want to publish a 'pump' into the SmartPlant World, you should define a 'pump class'
and then publish an 'instance of a pump', based on that class.

In general, you need to know that an object, for example, pump P-101, that you publish into
the SmartPlant database is an "instance of a class", which was defined by a class definition
(ClassDef) in the schema.

says, "A cow is an instance of a mammal." That's the basis of the Class
Definition Pattern. "Listen up", he says, "first, you have to define what a mammal 'is' by
figuring out its mammal-ness. Then you create one - poof! - the mammal that just got
created is called an 'instance of a mammal'."
- Author's note 1: Google 'mammal', or ask the nearby zoologist to find out what
mammal-ness is.
- Author's note 2: you may find that it is somewhat difficult to create one
('poof!' is really not so easy to do), and you should probably rely on a More
Powerful Being to do that.

For now, let's stick with what we can do, namely, define a class.

Identity
Class Definition Pattern

Purpose
If you have a SmartPlant tool, for example, SmartPlant P&ID, SmartPlant Electrical, Smart
3D, and so on, and you're ready to start publishing your "stuff", what do you need to do?
- Define the roles that your tool will publish (create InterfaceDefs)
- Optionally define the properties on those roles (PropertyDef)
- Optionally create associations between the roles (RelDef)
- Do some mapping between your stuff and the SmartPlant stuff
- Publish something? Wait a minute! - back in §3.1, you said "The most
fundamental idea of the SmartPlant schema is that objects expose their roles
through abstract entities called "interfaces." But you can't publish abstract
entities!

Uh oh, you got me. You need a way to stitch together all those abstract entities and publish
that stitched-together thing, in a container called a document. The thing that binds roles
together is called a class; it groups similar things, it is the creator of "objects", and it's
defined by a ClassDef.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 58

Let's make sure that you understand that last little bit of information. "The thing that
binds roles together is called a class" means that you classify objects by observing
similarities in things and then grouping them together.

In the case of "mammal-ness", scientists have decided that some of the characteristics
that bind mammals together into a class are:
- warm-blooded (endothermic)
- vertebrate (has a backbone)
- grows hair on its skin
- (in females) produces milk for its young
- has internal fertilization
- breathes air
- gives live birth (does not lay eggs and incubate them)

As you know by now, we would probably take each of those "roles", for example, 'breathes
air', and create abstract interfaces (IBreathesAir) to expose those roles (and properties)
to the universe. As you know, not everything that, for example, 'breathes air' is a mammal,
so that particular interface, or role, may also be realized by, for example, a crocodile, which
is a reptile. A crocodile has a backbone, so it has some of the characteristics of a mammal,
for example, has legs, eyes, a beating heart, and lots of other characteristics that it shares
with mammals - but it is not a mammal, for example, it "lays eggs", and is "cold-blooded." It
is "hairless" and does not "produce milk for its young."

So the secret of classifying 'mammals' as different from 'reptiles' is that one class has a
certain set of roles, and a different class has a different set of roles - even if some of the
roles overlap! Here's something weird for you to think about: so-called 'hairs' like you have
on your head (trichomes) are also found on plants. So classes as diverse as thistles and
humans have at least one common role! Author's question: do plants 'breathe air'??

At the end of the thought process about "mammal-ness", some significant difference exists,
for example, "gives live-birth" vs. "lays eggs and incubates them" is a significant enough
difference that scientists have different classes for mammals than reptiles.

Let's summarize our thoughts on interfaces and classes - interfaces carry role-ness, classes
realize that they expose those roles to the universe.

- The mammal class (Mammalia) realizes that it has these roles:

o Endothermic (warm-blooded)
o Covered by hair
o Air-breathing
o Vertebrate (has backbone)
o Gives live birth
o and so on
- The reptile class (Sauropsida) realizes these roles:
o Oviparous (egg-laying)
o Ectothermic (cold-blooded)

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 59

 o Covered by scales
o Air-breathing
o Vertebrate (has backbone)
o and so on

Usage
If you start thinking about your tool's data, and what great chunks of useful wisdom you can
share with the rest of the collaborative engineering process team (by publishing it to the
SmartPlant Enterprise), you should think like this:
- My tool (a software program) deals with instruments that are used to monitor
the conditions of a pipe line.
- Which means that you need to publish "instrument things" and "pipe line things"
- Which means that you need an "instrument class" to group instrument roles and
properties
- And a "pipe line class" to group pipe line roles and properties.

has a little helper for you -- how you can picture interfaces and properties in
an easy-to-understand manner. First, look at a UML diagram of an instrument class
(PIDInstrument) definition:

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 60

 Figure 49 Instrument Class

As you can tell, it is far too complex to understand, and if the UML diagram showed all of
the properties that are exposed by those interfaces, it would be a real mess (however, you
must admit that it may have some artistic value). In the center of the diagram is a class
definition (ClassDef), which represents an instrument that is shown on a P&ID, namely,
PIDInstrument. Each of the circles, at the end of a dashed line (also known as a lollipop) is
a UML representation of an interface (InterfaceDef) (see §3.1) that the PIDInstrument
class yields up to the universe (Realizes that it is). In fact, a simple trick for reading the
diagram is to say "a PIDInstrumentClass realizes that it is (or may be) an 'oriented item'
(IOrientedItem)", and so on.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 61

UML Interface Diagram
Figure 50, below, shows the UML diagram for the IClassDef interface:

Figure 50 IClassDef UML Diagram

Holy smokes! That's complicated! What's going on? First of all, what matters to you (as
the owner of a tool that is about to publish an object that is defined by a ClassDef ) is:
- IMappableClass - This lets you do "mapping" between the class, and whatever is
your tool's equivalent
- The relationship between IClassDef and IInterfaceDef is obviously mighty
important - it's our friend, the "Realizes" relationship, and it lets a class realize
what roles it yields up to the universe
- ICompSchema - what component schema the class is tied to, and consequently,
what objects (that are based on that class) it can publish
- ISharedObjDef - Lets two tools "share" objects
- IModelDef - what "model" the class is tied to
- IDocumentType - the "document type"

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 62

 When you define a "class", you'll need to supply answers to those questions, for example,
what component schema is this class tied to, and so on.

UML Class Diagram

The UML diagram of a ClassDef looks like this:

Figure 51 ClassDef Class Diagram

There's nothing very interesting here, except the IMappableClass interface, which lets you
map a class to whatever is your equivalent.

Description of Pattern
A class of objects refers to a collection of things that share a common attribute (picture a
class of objects called 'song birds' and you're done). The process of classifying things
involves arranging them by classes or categories. Once you have identified and categorized
something, the schema mechanism for storing the information about the class is the
ClassDef. The ClassDef lets you express the roles that the class exposes to the universe.
When you publish a document, you include "instances of classes", which are called "objects."
Each object has, at a minimum, identity. It may also have any properties that it is
authorized to express. That authorization comes from this great cross-stitch pattern that
you can use for your next project with the group:

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 63

 Figure 52 A Cross-Stitch Pattern Named "The Fundamental Idea About Classes"

(I hope that my wife doesn't notice her cross-stitch software being used like this). So
think about it this way: you define a class, you define some interfaces, you define some
properties, you publish a document that contains your objects that are defined in the
schema to behave a certain way. It's that simple! The SmartPlant Enterprise suite takes
care of a lot of the underlying "enforcement", including validating your published file against
the schema.

Relationships to Other Schema Elements

If you play chess, you'll understand this simile: class definitions are like the 'king' - it's the
most powerful piece in some aspects (if it is captured, the game is over), and the least
capable piece in other aspects (its moves are very constrained), also, all the other pieces
are moving around in an attempt to protect the king (and attack the opposing king). You
must create a ClassDef, in order to publish objects, but the true "power" of classes isn't in
the ClassDef, rather, it is contained in the interfaces that the class realizes, and in the
properties that the interfaces expose, and the relationships that they establish to other
interfaces. It seems that ClassDef, the mighty "father of objects" is like the chess king --
by itself, it is really not very powerful at all, but with interfaces (queen), and properties
(knights, bishops), and their types (UoM and EnumLists = rooks, intrinsic types = pawns), we
can play an interesting game of integration.

Collaborations
ClassDef has several important collaborations that you need to understand:
- Mapping - lets you create external relationships (maps) between the things in
your world that looks like classes to corresponding schema stuff

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 64

 o ClassToMapClass
o MapClassToClass
- Componentization - lets you define which "component schema" the class will
appear in
- DocTypeClassDef - defines what kind of documents your tool can publish and
retrieve, and defines the document for "tombstones"
- Instantiates - remember how we talked about "instances of something", well,
instances are created with a "class factory" (IClassFactoryDef), via this
relationship.
- ModelClass - each class might be in one of the defined "models", as discussed in
§5.1.3 USAGE, for example, Planned material, and so on.
- Sharing - defines how you will share your data with other data (created by other
tools) in the collaborative engineering process
- Realizes - Relationships to interfaces that define what roles your class yields up
to the universe
- Primary Interface - as we discussed in §3.4.4.9 Primary Interface, it is the
"essential roles" for an object

Consequences
Classes are defined using the Class Definition Pattern. Objects, based on those class
definitions, are published to a document and stored in the SmartPlant Foundation database.

Implementation
In the schema, class names are generally based on the tool that creates them. For example,
classes that are published by the Equipment Datasheet generally begin with 'EQD'.
However, if some other tool wants to publish a class that's just like an EQDPump, that's
perfectly OK.

Similar Patterns
Classes and interfaces are widely accepted structures in the Microsoft Component Object
Model (COM). COM is a software architecture that allows applications to be built from
binary software components. COM is the underlying architecture for all current Microsoft
software, so you could say that it's an idea whose time has come. The most fundamental
problem that COM solves is: How can a system be designed so that binary executables from
different vendors, written in different parts of the world, and at different times, are able
to interoperate? The ClassDef, and InterfaceDef are structures in the SmartPlant schema
that answer the question: How can data from multiple software programs, operating in a
collaborative engineering environment share data. The more you know about COM, the more
you'll agree that it really solves the interoperability problem of binary software
components. We think that the SmartPlant schema and schema components provide the
same level of functionality for arbitrary shared data. See §4.6 for more information on
"shared objects."

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 65

Anti-Patterns
You may be used to thinking of classes in the classical sense, namely, a class of similar
objects, and that's fine. But remember the problem with classifying things: it's almost
impossible to do it right. This problem was discussed in detail in "A Gentle Introduction to
the SmartPlant Schema", and we won't cover it again here. It is important to get your head
around the concept of classes that realize roles, and roles that are related to each other,
and carry properties. Trying to classify, for example, a virus, is just too hard to do.

Component Schema Pattern

As you probably guessed, there are a lot of classes defined in the schema. However, every
tool that publishes data to SmartPlant Foundation does not need to have access to all of
them. The Component Schema Pattern is a grouping mechanism and a bit of a time saver.
Let's see how it works.

Identity
Component Schema Pattern

Purpose
"Component schemas" are used to group classes (ClassDef) so that the entire SmartPlant
schema does not need to be stored on every SmartPlant Enterprise client computer. Why
does that matter?

The schema is quite large and we're looking for a little optimization with this pattern. For
example, the SmartPlant P&ID software doesn't need all the Smart 3D class definitions,
because it won't use them anyway. For example, a P&ID drawing has no clue about what a
P3DCableTrayPort is. A P&ID (piping and instrumentation diagram) is a schematic
representation and Smart 3D is a higher-level 3-D representation. Some concepts are
shared between those tools, and some are not.

Many sets of tools work that way, that is, they don't have the same "domain of discourse."
But when all their outputs are combined, a total picture of the facility is created in the
SmartPlant Foundation database - and that's the ultimate goal of SmartPlant Foundation,
that is, gather up information from many different sources and combine it all in a
meaningful way.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 66

 Back to the topic at hand: many concepts of the different tools that are integration
participants are not "shared" concepts. Therefore, when it is time to publish data to
SmartPlant Foundation, a tool only needs to know its own classes, not any others. That's
why classes are broken into (orthogonal) groups, namely, tools won't want to waste time
parsing schema elements that they don't have any knowledge of. NOTE to the proofreader:
While it may be improper to end a sentence with a preposition, you'll agree that sometimes
it makes for easier reading. When an editor dared to change a sentence of Winston

Churchill that appeared to end inappropriately with a preposition, responded by

writing to the editor, "This is the kind of impertinence up with which I shall not put." Since

the preposition in my sentence has an object, it is not technically incorrect -

just likes to pull your chain! The cost to the author: $0 -- the look on your face right now:
Priceless.

Usage
Here is a list of component schemas that are built into the schema:
- ControlSystemComponent - groups of classes that have to do with control
systems
- DimensionalDatasheetComponent - groups of classes that have to do with things
that appear on a "dimensional data sheet"
- DocVersioningComponent - groups of classes that have to do with document
versions and revisions
- ELEComponent - electrical components
- EQLComponent - things on an equipment list
- EquipDataSheet - things on an equipment data sheet
- GenericDocumentComponent - things that are documents
- IMLComponent - things on an instrument master list
- InstrumentIndexComponent - things that are on an instrument index
- MetaSchema - internal use only
- P3DComponent - things that are on a 3D drawing
- PBSComponent - the plant breakdown structure
- PDSComponent - things that are used by Plant Design System
- PFDComponent - things on a Piping Flow diagram
- PIDComponent - things on a Piping & Instrumentation diagram
- ProcessDataComponent - things that are involved in the process data model
- WBSComponent - the work breakdown structure

It's no big deal - component schemas simply break the total schema into smaller, more
manageable pieces.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 67

UML Interface Diagram
Each class definition (ClassDef) must belong to 1 "component schema".

Figure 53 Componentization Relation Definition UML Diagram

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 68

UML Class Diagram
Figure 54, below, shows an example of classes that are bound together as part of the
ControlSystemComponent.

Figure 54 Control System Component Members

For this example, the Schema Editor will generate a "component schema file" that is based
on ControlSystemComponent, which contains (only) those classes, plus their interfaces, plus
their properties, plus their scoping, plus enumerated lists. That file is much smaller than
the entire schema, so it will parse and load faster by the tool that is publishing data to
SmartPlant Foundation.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 69

 The Schema Editor can also publish combinations of 2 or more component schemas (into one
file). So if your tool publishes electrical data and equipment data sheet data, just request
that those two groups get combined.

Description of Pattern
Think about how your tool publishes data: your tool invokes a piece of code called an
"adapter" which reads a "map" that translates your objects into SmartPlant objects, which
are then published as a document into the SmartPlant Foundation database.

It was decided, early on, that it is not very efficient to force each tool to load all the
classes during the publish phase because it is just too time-consuming for the adapter to
parse the entire schema file. Therefore, class definitions are grouped together by a
something called a "component schema". The Schema Editor creates these groups of
"component schemas", each of which contains a certain subgroup of all the possible classes.
Then, individual tools only have to know about that subgroup of classes, which is more
efficient.

This is just a composition pattern, as described in §5.4, below. It is used as a simple

grouping mechanism of class definitions (ClassDef), for the purpose of reducing schema
load- and parse-time by the tools that publish data to SmartPlant Foundation.

Relationships to Other Schema Elements

ClassDef

Collaborations
The Schema Editor breaks apart the "total" schema file into a bunch of smaller files, called
"component schema" files. Each file is a collection of class definitions that are probably
going to be published by the same tool, although that is not a requirement.

Consequences
A small collection of class definitions, along with required supporting definitions, is quicker
to parse and load than forcing each tool to read and parse the entire SmartPlant schema,
each time that a "publish" program is run.

Component schemas are about shared objects, which is discussed in §4.6.

Implementation
When you define a new class definition (ClassDef) in the Schema Editor, you will need to
choose a component schema that the new class belongs to. That shouldn't be rocket
science, because it is obvious which tool is publishing the class, so you either pick an existing
component schema, or create a new one - if your new classes don't fit into one of the
existing component schema categories - just fire up the trusty Schema Editor and add a
new one.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 70

 How do you pick a component schema for your class? Think about what kind of classes your
software tool is most likely to publish, and use the "closest" component schema group. The
fact is, it doesn't matter much which component schema you choose, because the grouping is
not a functional group - it is a logical group. The worst that can happen is that you might
parse a few extra classes at publish time.

Similar Patterns
Composition Pattern

Anti-Patterns
N/A

Model Definition Pattern

Each class definition (ClassDef) is associated to the overall architectural model, which is
based on the POSC/Caesar model that is described in §5.1, below.

Identity
Model Definition Pattern

Purpose
"Models" are used to break your tool's classes apart into some kind of high-level functional
groups. At the highest level, a class is either "facility" or "material", depending on whether
it is an abstract- or concrete role. Then the facility model and material model are further
sub-divided into more convenient groups and so on. These groups are based on the
POSC/Caesar model.

Usage
Here is a list of model definitions that are built into the schema:
- ActualMaterialModel - represents actual material items (they usually have a
serial number)
- FacilityModel - represents the abstract items that are in the concept-phase of
design
- PlannedMaterialModel - represents items that we plan to purchase
- TypicalMaterialModel - represents "typical" items, for example, a typical
computer is what you'd find in a specific manufacturer’s computer catalog
- WorkBreakdownModel - having to do with items in the work breakdown
structure (WBS)

Some technical description of a model definition would say that each of these are instances
of the ModelDef class, but that might confuse some readers, so I'll try not to put that in
this document.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 71

UML Interface Diagram
Every class (ClassDef) that you create must belong to a named model.

Figure 55 Model Definition to Class Definition Relationship

UML Class Diagram

Here is an example of a pump that will be published on an equipment data sheet. Because we
plan to purchase the pump, it is part of the "planned material" model.

Figure 56 An Instance of a ModelClass

Also, see how Figure 56 is derived from Figure 55, above.

Description of Pattern
Every object that gets published is an instance of a class, which is defined by a ClassDef.
Each ClassDef must be associated to a model (ModelDef). Therefore, you can figure out
that objects will be grouped by model.

Relationships to Other Schema Elements

ClassDef

Collaborations
The idea of "models" is really about "shared objects", which is discussed in §4.6. Objects
within a model share data in a different way than objects that are in different models.

Consequences
N/A

Implementation
When you define a new class definition (ClassDef) in the Schema Editor, you will need to
choose a "model" that the new class belongs to. How do you do that? Well, if you're going
to buy an instance of the object, for example, a pump, then you're probably talking about
planned material. If you're thinking about an item in a catalog, it's probably typical
material, and so on.

Similar Patterns
Composition Pattern

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 72

Anti-Patterns
N/A

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 73

Mid-level Patterns

Now that you have a good understanding of the basic elements of the schema, here are
some useful patterns for combining them to provide some powerful functionality in a
collaborative engineering environment.

Class/Interface/Property Pattern
As you saw in the lovely cross-stitch pattern in Figure 52, Classes Realize Interfaces that
Expose Properties, which are Scoped by types.

Identity
Class/Interface/Property Pattern

Purpose
Probably, the most common thing that you will do is add your own classes, interfaces, and
properties to the schema. There is proper a way to do that. And there is a reason for
doing that - the stuff that you want to share with other members of your collaborative
engineering group may not be in the schema, so you have to know how to extend your
schema.

Usage
There are two possible starting points:
- Find a similar class definition, and clone it. For example, if you're going to
publish a vertical centrifugal pump and you see a horizontal centrifugal pump in
the schema, it may save you some time.
- Plan 'B': Make an entirely new class definition from scratch. If you're sure that
nothing similar exists, go ahead and make your own class.

Let's go through an example of making an entirely new class definition from scratch,
because then you'll see the whole process.

UML Interface Diagram

Back in §3.6.2 we talked about mammals, so let's use that as our example. First, we'll
create the 'Primary Interface'. In this example, the primary interface is the interface
that expresses all the roles of being a mammal. The interface is named "IMammal", and it
needs to have, as one of its most fundamental roles, the concept of "identity", which is
exposed by the IObject interface.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 74

 Figure 57 IMammal Implies IObject

We're on a roll, now! What are the other roles that a mammal yields up to the universe?
(you should look back at §3.6.2 to find out).

Here is what that looks like, from a first-stab-at-it perspective:

Figure 58 The Basic Roles of a Mammal

Now, let’s add some properties to one of the interfaces and "scope" the property with an
enumerated list that contains a couple of values:

Figure 59 Some Mammal Properties

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 75

 That's about it! Just keep using the same idea of thinking about the roles that you want to
expose to the universe, adding properties, scoping them, and possibly adding enumerated
lists.

UML Class Diagram

Now, let's add the class definition to the UML diagram:

Figure 60 Class Diagram of a Mammal

As you recall, an instance of a ClassDef is an object, so you can now start publishing
instances of the aMammal class from your collaborative engineering tool. Congratulations!
(NOTE: There are actually a few more boring details, like mapping, and hooking up to the
SmartPlant adapter.)

Description of Pattern
Classes Realize Interfaces that Expose Properties. That should be embedded in your brain
by now; if not, please look back to Figure 52 at this time for a review of the (cross-stitch)
pattern (get it?).

Relationships to Other Schema Elements

The Class/Interface/Property Pattern is the most fundamental pattern in the schema and is
used to let you extend and customize the schema for your own SmartPlant-enabled tool.
Unlike some so-called "Standards", the SmartPlant schema was never intended to model
everything in the universe; therefore, you will find that this pattern is pretty common.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 76

Collaborations
When you use the Class/Interface/Property Pattern, you are enabling your tool to share
data in a collaborative engineering environment with like-minded tools - and that's good.
See - retrieving some other tool's document and parsing it is really easy to do - it is
guaranteed to be well-formed and accurate, because the schema component enforces rules
when the document is published, so retrieving it is a no-brainer. Keep this in mind: you are
publishing stuff so that someone else's tool can retrieve it, so your goal is to make clean,
unambiguous classes, interfaces and properties so that the retriever can use your data. If
you make a bunch of questionable classes, ambiguous interfaces and duplicate properties,
guess what - you lose.

Consequences
You create interfaces for the purpose of yielding up roles. Interfaces are purely imaginary.
They are used to tightly-group semantically-related concepts. You add properties to the
interfaces. You add classes that realize that they need some of those roles to be complete
in the universe. You publish instances of classes (called objects). The consequences of
adding classes, interfaces and properties to the schema is so that you can publish your data.
If you are a new user who has some stuff to contribute to the collaborative engineering
process, here's how to do it. It's an easy pattern to follow: express roles, then define
classes, and it should not take long to make a bunch of your stuff available to your fellow
collaborators.

Implementation
Use the Schema Editor to add the roles (InterfaceDef), properties, and classes. Be careful
that you don't add stuff that's already there.

You don't need to be a computer scientist to figure out that your idea of, for example, "a
horizontal pump" is the same as the schema idea of IOrientedItem, but you need to stay on
your toes - anything that you put into the schema that contributes to ambiguity will make
the schema too hard to use.

Similar Patterns
In the "database-oriented world", classes carry properties directly, and are related to
other classes. As we have discussed, the Class, Interface, Property model is simply a
better way of doing things.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 77

Anti-Patterns
Don't create interfaces if the role already exists! Don't add properties that are already in
the schema but seem to be on the wrong interface (they're probably right). The whole
point of a highly-normalized schema is to make it easy for the retrievers to get data into
their systems. If you add an identical role to one that is already there, you create

ambiguity,; therefore, will probably show up when you least expect it, and he
may slap you silly!

Multi-level List Pattern

It's easy to memorize, for example, the colors of the rainbow:
- Violet
- Indigo
- Blue
- Green
- Yellow
- Orange
- Red
(remember the mnemonic VIBGYOR), but it's not so easy to remember the 2-level list called
"Interior surface treatment", which goes like this:
- Undefined
o Undefined
- None
o Not Required
- Passivation/Descaling
o Pickled
o Pickle with acid
o Pickle/oil with acid
o Pickle with nitric acid (20-50%)
o Pickle with nitric acid (20-40%) + sodium dichromate (2-6%)
o Pickle with nitric acid (12%) + copper sulfate (4%)
o Acid descale with oxalic acid (5%)
o Acid descale with sulfuric acid (8-11%)
o Acid descale with nitric acid (15-25%) + hydrogen fluoride (8%)
- Rust inhibition
o Flush with rust inhibitor
o Flush with sodium nitrite (0.5%) + DSP/MSP (0.5%)

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 78

 laughs: "What the heck is 'sodium dichromate', and why is '2-6%' relevant?
In any case, I'd pay 5 Mexican Centavos to hear someone recite that list from memory!"

Identity
Multi-level List Pattern

Purpose
A multi-level enumerated list of values is populated with a hierarchy (or a tree) of values.
Each child has exactly one parent. This is a common idea in the real world.

Usage
Take a minute and review §3.3.6.2 Multi-level Enumerated Lists. What you see is that each
level of a multi-level list scopes a separate property on an interface.

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

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 79

 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; instead, they 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 (that is,
EquipmentSubtype), and so on properties rather than the more specific EquipmentType,
MaterialHandlingEquipmentType, FluidTransferMachineType, PumpType, and so on
properties.

UML Interface Diagram

Figure 62, below, shows the meta model for enumerated lists, enumerated values and
enumerated list level types:

Figure 62 IEnumListType UML Diagram

Let's see what's interesting there:

- The most important thing to see is the relationship BaseEnumListForEnumLevel,
which lets an enumerated list (IEnumListType) have many enumerated list levels
(IEnumListLevelType). We explained the use of enumerated list levels in detail
in "A Gentle Introduction to the SmartPlant Schema." Please take a few minutes
to review section "Ideas about Enumerated Lists (including EnumListLevelType),
in Chapter 26.
- Enumerated lists (IEnumListType) contain enumerated values (IEnumEnum).
- Of course, enumerated lists are mappable to whatever your tool thinks of as
equivalent lists of values.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 80

UML Class Diagram
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 63, which follows:

Figure 63 EnumListLevelType Meta Schema

The class definition EnumListLevelType realizes IPropertyType and is therefore a valid

property type for scoping property definitions (for example, 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 in Figure 61, the starting enumerated list would be, for
example, "A".

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 81

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.

Enumerated Entry Metadata

Sometimes enumerated entries are not just short and long text strings. In some cases
enumerated entries have additional properties and/or additional behavior associated with
them.

The EnumMetadata relationship definition shown in Figure 64, is used to relate an

enumerated entry (or an enumerated list that also supports the IEnumEnum interface) to
other objects that provide additional properties and/or additional behavior to the
enumerated entry.

Figure 64 Enumerated Entry Metadata

Type Specialization and the EnumMetadata Relationship

Here's one relationship that the tabloids won't be talking any time soon - I guarantee it!
Each level in an enumerated list hierarchy is a specialization of the level above it. For
example, pumps and compressors are specializations of mechanical equipment, and
reciprocating and centrifugal pumps are specializations of pumps. Therefore, type
specialization can be considered to be an enumerated list hierarchy.

At each level of specialization in the type hierarchy, there can be <<EnumMetadata>>

relationships to other objects that provide additional information and behavior about that
enumerated entry.

One of the class definitions that supports IEnumMetadata is InterfaceDef. This means
that an enumerated entry (or enumerated list that supports IEnumEnum) can have an
<<EnumMetadata>> relationship to an interface definition that defines additional properties
and behavior for that enumerated entry. For example, the "Pump" enumerated list could
have an <<EnumMetadata>> relationship to IPump, which would then define additional
properties and behavior common to pumps.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 82

 Figure 65 Example of EnumMetadata Relationship

Because the various nodes in the type specialization hierarchy can have corresponding roles
(interface definitions), the type specialization can have a corresponding role specialization.
For the type specialization, each node in the enumerated list hierarchy would have a
Contains relationship to its more generalized parent, whereas the corresponding role
specialization would have similar Implies relationships between the interface definitions.

Figure 66 Example of PropertyDef and EnumListType

The interface definition involved in the <<EnumMetadata>> relationship will normally have
(unless it corresponds to a leaf node) an exposed property definition that is scoped by the
related enumerated list. Figure 66 shows, for example, IPump exposes a property
PumpType that is scoped by the Pump enumerated list

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 83

Example of a Multi-level List
Next, though it isn't really a class diagram, it is the schema diagram that is an instance of
the meta schema diagram in Figure 62 and Figure 63.

Figure 67 Example of Multi-level List

Let's read Figure 67:

- ICoatedItem_Interior exposes two properties: Interior_CoatingRequirement
and Interior_CoatingType
- Interior_CoatingRequirement is ScopedBy an enumerated list (EnumListType)
named Coating requirement, which is the "top" of a hierarchy. How do we know
that? Look at the relationship between Coating requirement and CoatingReq2
(BaseEnumListForEnumLevel) and see that the end numbers 1 and 2 define the
direction of the hierarchy (top = 1)
- Interior_CoatingType is ScopedBy an enumerated list (EnumListType) named
CoatingReq2, which is the 2nd level of a 2-level hierarchy
- The enumerated list named Coating requirement includes the enumerated values:
Painting and Metallic coating

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 84

 - The enumerated list named Metallic coating includes the enumerated values:
Black Paint, Dura-Copper, and Metallized with zinc
- The enumerated list named Painting includes the enumerated values: PS2.03 and
PS4.04
- Here's a little secret for you: the edge (EdgeDef) named Contains2 helps you
gather together the enumerated values at level 2 of the hierarchy. I bet that a
3-level list would also have an edge named Contains3 and so on.

Description of Pattern
The Multi-level List Pattern lets you build up a hierarchical list of values (a hierarchical list
is like a tree). Entries in the list are connected by parent-child relationships. We covered
this in detail in §3.3.6.2 Multi-level Enumerated Lists.

Relationships to Other Schema Elements

As you can see from Figures 66 and 67, a multi-level list is a complex structure that has
relationships to PropertyDef, EnumListType, EnumListLevelType, Enum, and Rel.

Collaborations
Enumerated lists (EnumListType) may have optional "levels" (EnumListLevelType) and
probably have enumerated values (EnumEnum) at every node of the tree. If you have a list
of values that you want to share with another engineering tool, putting it into an
enumerated list is probably a good way to ensure that you will both be talking about the
same stuff.

Consequences
Sharing multi-level enumerated lists is a powerful idea for the collaborative design process.
A tool like a piping flow diagram (PFD), or a piping and instrumentation diagram (P&ID) is
used in early-stage design. Tools like Smart 3D takes the output of a PFD or P&ID and
enhances (embellishes) the objects that they published to come up with a late-stage, detail
design.

But, think of a "vertical, centrifugal pump" for a minute. The fact is that the early-stage
design tools don't have a clue about such a detailed entity - they may only have the concept
of "an equipment that increases pressure in a pipe line." For sure, the Smart 3D program
knows a lot about a vertical, centrifugal pump, and, of course, a pump catalog, or an
equipment data sheet that describes a pump to a fare-thee-well. The idea of a multi-level
enumerated list helps each of these tools share data about, for example, pumps. Early tools
know that it's an equipment ... later tools know that it has dimensions ... later tools know
where it will be placed in 3-space and so on.

It all goes back to the discussion of polymorphism - a polymorphic pump has different roles
that different tools contribute to the overall "shared" idea of a pump. In the case of
equipment, there is a 7-level hierarchy that defines "everything kind of equipment." With
apologies to E.A. Poe:

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 85

 The Pump
If it's a polymorphic pump that your tool's got,
And if you know a little,
Or if you know a lot,
About the pump as a concept -
Or the pump as an item with a tag,
An actual pump with a serial number,
Or a catalog, that on pumps does brag,
To share your pump with others,
Pick your values from a list,
Whether for levels 1, 2, 3 or 4.
Quoth the raven:
"Publish that, and nothing more"

Figure 68 A Raven's Comments about The Pump

Implementation
So how do you build a practical multi-level list? It's not so easy, because there are a lot of
steps involved:
- Create and populate the enumerated list - remember that an enumerated list
(EnumListType) can contain other enumerated lists or enumerated values
(EnumEnum)
o Create property definitions - make sure that you are on the correct
interface!
 Scope the property definitions with the enumerated lists or
enumerated values
• Create the links between the hierarchical levels of the
lists (EnumListLevelType)

How do you implement the multi-level list? Let's make a list of cars, grouped by
manufacturer:

Ford
- Mustang
o GT
 Shelby GT
- 500
o Coupe
o Sedan

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 86

 - Escape
Chevrolet
- Corvette
o Z06
- Malibu
Chrysler
- PT Cruiser
o LE
o SE
- 300
Honda
- Accord
o Hybrid
- Civic
o Hybrid

Here's what that looks like in the schema:

Figure 69 Multi-level Enumerated List of Auto Manufacturers

Let's add the level2, 3, and 4 relationships (EnumListLevelType) to the schema, and see
what we've cooked up:

Figure 70 Properties in a Hierarchy are ScopedBy EnumListLevelType

AutoMfr2 is the level 2 enumerated list level type and so on. Do you remember what the
enumerated list level types are for? When you scope a property by an EnumListLevelType,
you are telling the publishing program that it's OK to publish a selection from that
particular "level" of the list. Think about that for a second:
- What values are at level 1 of this list?
o {Chevrolet; Chrysler; Ford; Honda}
- What values are at level 2 of this list?
o {Corvette; Malibu; PT Cruiser; 300; Accord; Civic; 500; Mustang}

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 87

 - What values are at level 3 of this list?
o {Z06; LE; SE; Hybrid; Coupe; Sedan; GT}
- What values are at level 4 of this list?
o {Shelby}

Do you get it? What is a valid value that you can publish for property 1 (AutoMfr1)?
- Pick one from this list {Chevrolet; Chrysler; Ford; Honda}

Now, based on that choice, the values from level 2 (AutoMfr2) are constrained to 2 rules:
1. The choice must be in the level 2 list, and
2. The choice must be in the children of the level 1 list

Which means, for example, Chevrolet -> Corvette is a valid choice (if you can afford it), but
Honda -> 500 is invalid, because '500' is valid level 2 entry, but is not a child of the 'Honda'
hierarchy

In summary, it's done this way so that early-stage programs that only know about, for
example, 'Ford' can go ahead and publish something, but subsequent programs know about
'Mustang', and the 'GT' variant, and the 'Shelby' variant of that are OK to increase the
level of detail that is published.

Metadata for Enumeration

Just the other day I thought I heard say: "Let's talk about how
enumerated list values tie to interfaces."

Figure 71 Interfaces

Figure 71 shows the interface hierarchy that we're talking about, that is, types of
automobiles. And Figure 72, below, shows a tie between an interface hierarchy and an
enumerated list hierarchy

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 88

 Figure 72 Interfaces are tied to Hierarchy using EnumMetadata

Hey there, are you still awake after the commercial break? Did you see that little trick of

tying a hierarchy of interfaces to a hierarchy of enumerated list? As

says, "That's pretty useful for mapping your stuff to schema stuff."

Here is the overall picture of auto manufacturers and automobiles, nicely tied together.

Figure 73 Overall View of Auto Manufacturers Tied to Interfaces

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 89

Similar Patterns
Really, within the SmartPlant schema, the idea of tying enumerated list hierarchies to
interface hierarchies has its roots in Smart 3D. Within the SmartPlant schema, we treat
these tied-in enumerated lists as the carriers of a "strong-secondary key". Then Smart 3D
publishing process can just reference the enumerated value and not worry too much about
which interfaces are in the SmartPlant schema that correspond to those values. It's a low-
budget way of helping out the Smart 3D folks.

Anti-Patterns
When we were creating the schema, we tried to make enumerated lists "well-behaved", and
they looked like this:
1. List 'x'
a. enumerated value 'ax'
b. enumerated value 'bx'
c.
2. List 'y'
a. enumerated value 'ay'
b. enumerated value 'by'
3. and so on
But we got complaints from users who wanted to add new values between 'x' and 'y', plus
some values between 'ay' and 'by', too. So the nice, clean pattern does not appear to be
totally applicable to all enumerated lists.

We changed some of the lists to look like this:

1. List 'x'
a. List 'ax'
b. List 'bx'
2. List 'y'
a. List 'ay'
b. List 'by'
3. and so on
and that worked out better, because new entries could be inserted with no hassle. So the
refactored pattern is to end hierarchical lists at a branch-node, not at a leaf.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 90

Edge Definition Pattern
You can use edges to navigate from one object in the model to another object in the model.
Once the edges are defined, they can be grouped together to form a "directed" graph,
which is a connected network of edge definitions. Finally, a view can be used to filter the
lists of properties that will be available in the user interface. Let's start with edges.

(With apologies to L. Frank Baum). Once upon a time, in the land of SmartPlant (on the far-
far-outskirts of Oz), Dorothy said "Edges, and graphs and views, O My!" She was concerned
that complex ideas like that would scare the Scarecrow (he pretended to be brainless, but
she knew better). Because he was a friend (but mostly because he looked a lot like

, whom her girlfriend told her was a Super Model, and didn't quite understand
that he really is a Super Modeler, but that's a different story) she sat down by a brick road
(whose color is an enumerated value equal to "Yellow") and began to explain...

"An 'edge' is simply a mechanism to set up navigation across one or more relationships with
optional filtering of the objects returned. Edges are especially useful for ad hoc reporting.
Edges are defined with an EdgeDef." Dorothy picked up a stick and scratched this diagram
into the dust, beside the road:

Figure 74 Dorothy Explains Edges

"Now watch this", Dorothy said:

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 91

 Figure 75 An EdgeDef is Born

Finally, Dorothy sketched this simple P&ID in the yellow dust:

and told the Scarecrow: "What if

you wanted to know the diameter of one of the nozzles on one of those process vessels? If
you define an edge between the vessel and that nozzle, you won't have to ask a wizard for
the answer."

Identity
Edge Definition Pattern

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 92

Purpose
Edges may be used to traverse across multiple relationships, to select only certain objects
from the destination end, or to do multiple relationship traversal and selective
discrimination. Edges start at a specified interface (InterfaceDef) and can navigate across
any relationship (but at least 1) defined on that interface or any of its implied interfaces.
Therefore, an edge is available for navigation from any class that realizes the starting
interface. Dorothy sneezed from the yellow dust that she kicked up while drawing the
P&ID. "The Munchkins were wrong - follow the edge, not some dusty brick road", she said.

Usage
When using an edge to support, for example, reporting, the properties available to the
report, at the end of the navigation are, by default, those on the interface at the end of
the last relationship traversed plus properties on any implied interfaces. It is not possible,
by default, to reference properties on an interface that is implied by the interface at the
end of the "last" relationship traversed. Therefore, there is an option on the EdgeDef
(ValidInterfaceRefs) to identify a set of interfaces. That restricts the objects returned
to only those that have an instantiated interface. Then the available properties are only
from the "end" and "selected" interfaces.

UML Interface Diagram

Dorothy points to Figure 76, the edge definition (IEdgeDef) pattern:

Figure 76 IEdgeDef UML Diagram

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 93

"MY!” gasped the Scarecrow: “This is a very robust role, indeed!" Dorothy replied, "Let's
read:"
- IEdgeDef has some useful properties:
o Name (from IObject) = name of the edge, and is usually made up from
parts of the related class names, using the component suffix
o StartInterfaceName = edges start at this named interface
o PathDefn = this identifies the starting interface and the route through
any intervening relationships, up to the final interface (Another name
for Path might be 'relationship definitions traversed')
o ValidInterfaceDefUIDs = identify one or more interface definitions
that the destination object must realize if this it is a legitimate
destination
o FilterEdge (from IEdgeDef2) = a Boolean that indicates whether the
underlying query wants to see the results of this edge, or not ("Filter
out edge in display" is a better way to read this property)
- The relationship EdgeDefForEnumLevel goes between IEnumListLevelType and
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.
- ISimpleCriteria
o PropComparisons = a property, and its proposed value
- IPositionCriteria
o NumericPosition = in a set of objects, this is the ordinality that we want,
that is, the 1st object = 1; the 2nd object = 2, and so on. This only works
if the relationship is "ordered", because if it's not, then the results are
unpredictable
- It's mappable
- ISchemaObj
o DisplayName = an unambiguous description of the object that will be
displayed, for example, when navigating a tree control.

Figure 77 Edge for Piping Port 1

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 94

Look at the right-hand side of Figure 77 first. It says that an object that claims that it is
a "piping port composition" (a ClassDef that Realizes IPipingPortComposition) may have many
"piping ports" (IPipingPort), which are collected together using the piping port composition
(PipingPortComposition) relationship.

Now let's define an edge (EdgeDef) that goes to a "particular port." The edge named
PipingPort1 defines a route between interfaces IPipingPortComposition and IPipingPort, via
the relationship named PipingPortComposition. In addition, there is a filter that says that
this particular edge is referring to the 1st piping port in the group (as opposed to the 3rd
or 4th). If that's too hard to understand, think of a collection of "anything", and now think
about retrieving the 1st member of the collection - get it?

An edge defines the path that goes from somewhere to elsewhere (an object to another
object, both of which have interfaces that are associated to each other by relationships)
via a "path definition" (PathDefn). The + and - indicate the navigation direction. Pop quiz:

Figure 78 Shared Objects With a Relationship

If you want to show the end-prep that is necessary on control valve V-101, what should you
do?

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 95

UML Class Diagram

Figure 79 Class Diagram for EdgeDef

Reading Figure 79 we see:

- The component schema for EdgeDef is MetaSchema
- The model for EdgeDef is MetaModel
- An edge has identity (IObject)
- An edge has selection criteria (ISimpleCriteria, IPositionCriteria)
- An edge is mappable (IMappableProperty)

Description of Pattern
Edges are used to:
- Traverse (go across) multiple relationships,
- Select only certain objects from the destination end
- Do multiple relationship traversal and selective discrimination.

Edges start at a specified interface (InterfaceDef) and can navigate across any
relationship (but at least 1) defined on that interface or any of its implied interfaces.
Therefore, an edge is available for navigation from any class that realizes the starting
interface.

Relationships to Other Schema Elements

Obviously, edges are used to navigate:
- From (an object whose class realized some starting interface)
- To (at least 1 relationship)
- Finally to (an object whose class realized some end interface)

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 96

Collaborations
InterfaceDef, ClassDef, RelDef, GraphDef

Consequences
The edge tends to flatten a "normalized" model, and is very useful for making the schema
look more like what a user is used to seeing.

Implementation
Map out the route that you want to take from one object to another, through a relationship.
Then define the edge (EdgeDef). Finally, your query can use the defined edge to return a
set of data to the user that is centered around objects that the user understands.

Dorothy was not sure that the Scarecrow understood, because he always had that same
blank look on his face, so she went to her car and pulled out a map and a red pen and said,
"You can use a map to help you get from Chicago to L.A. Here's how:"
- Leave Chicago on Interstate 55, West
o Not Interstate 90 (towards Western suburbs)
o Not Interstate 94 (Northern destinations)
o Not Interstate 57 (Southern destinations)
- Travel to St. Louis
- Leave St. Louis on Interstate 44, West
o Not Interstate 64 (Eastern destinations)
o Not Interstate 55 (Southern destinations)
o Not Interstate 270 (a loop)
o Not Interstate 70 (Western destinations)

Figure 80 Navigation from Chicago to L.A.

- Travel to Oklahoma City

- Leave Oklahoma City on Interstate 40, West
o Not Interstate 44 (Southern destinations)

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 97

 o Not Interstate 35 (Northern destinations)
- Travel to Mojave National Preserve in California
- Leave the area on Interstate 15 (Southern destinations)
- Arrive in Los Angeles, California

Dorothy summarized, "Do you see the starting point (Chicago), the nodes along the way (St.
Louis, Oklahoma City, Mojave) and the final destination (Los Angeles)? That's how an edge
works - it gathers up those things and lets you navigate objects from one to another, by any
route that you want." Of course, she still wasn't sure if the Scarecrow "got it", but she was
sure that she explained it right!

The Scarecrow, who has been a target many times before, is wondering where Toto is, right
about now. Noticing the blank look on the Scarecrow's face, Dorothy said: "Let's draw a
data model of this, and you'll see what's up." She was going to use the stick and scratch
some UML diagrams in the yellow dust, but decided to use the SmartPlant Schema Editor
instead. Here is what she drew:

Figure 81 UML Interface Diagram of Cities and Highways

"We can think of a 'city' as a collection of highways that go in and out of it. A city is lots
of things, but right now, it's convenient for us to think of its role as a transportation hub."

Figure 82 UML Class Diagram of Cities and Highways

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 98

 "Remember to add class definitions to the model. Here we need to define cities (aCity) and
highways (aHighway). That's so that we can create objects and publish them to the
SmartPlant Foundation database."

Finally, Dorothy said, "Let's create some sample data for this exercise. Here's what we'd
expect to publish:"

Figure 83 City and Highway Objects

Finally, she saw the slight smile on the Scarecrow's face, and she knew that he finally
understood "edges" - but she realized that she still had to explain graphs and views, so she
knew that there were still a couple of more long afternoons with the Scarecrow. "Let's
take a break. Tomorrow I'll tell you the story of graphs and views and flying monkeys", she
said. The Scarecrow just smiled his enigmatic smile.

Similar Patterns
The mythical Land of Database would call edges "views", but the SmartPlant Schema already
uses that term for something else.

Anti-Patterns
N/A

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 99

Graph Definition Pattern
A graph is thought of as a set of objects called vertices joined by links called edges.
Typically, a graph is depicted as a set of vertices and nodes joined by lines (the edges).
Depending on the application, some edges can be directed. A graph is defined by a
GraphDef.

Identity
Graph Definition Pattern

Purpose
Dorothy looked the Scarecrow right in the eye (due to a mean crow, he only has one) and
said: "Today we learn about graphs - I hope you're up to it." The Scarecrow just smiled and
thought how smart Dorothy was.

"You learned about graphs in grammar school, but by now, you forgot most of that, so let me
refresh your memory (Because his brain was made of straw, she was never sure what sunk
in). "Here is the technical definition:"

"A graph is thought of as a set of objects called vertices joined by links called
edges. Typically, a graph is depicted as a set of vertices and nodes joined by lines
(the edges). Depending on the application, some edges can be directed."

"Wait!" the Scarecrow blurted out, "That's just what I read a minute ago, but I can't
remember where."

"That's what I was afraid of," said Dorothy, "Let me show you what it means."

"Look back at the map (Figure 80) that we used to go from Chicago to L.A. Did you notice
the arrow? The head of the arrow points in the direction of travel, in other words, the
route is a directed graph. When I wrote out the instructions, I said start here, go to
somewhere, go another-where, and finally end somewhere - that's a directed graph." The
Scarecrow got it. Then he said, "But I can go back by the same route, what then?" Dorothy
said. "Right, but the route from L.A. to Chicago is directed, too - just in the opposite
direction!"

"Now look at the sample data that went with the trip (Figure 83). What do you think the
cities {Chicago, St. Louis, Oklahoma City, Mojave, Los Angeles} represent? They're called
nodes." Scarecrow was quivering in the breeze now, and the dawn of understanding was
awakening in the one coal-black eye. "That means that each highway that you picked is one
of those edges that you told me about yesterday, and the entire route is a directed graph!"
Look out, girl - he's got it!

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 100

Usage
After a quick Mexican lunch, Dorothy continued: "You use a graph to get from here to
there, via edges or relationships - it's really that simple."

Figure 84 Graphs by Dorothy

"Remember, when you create a GraphDef, explicit EdgeDefs are not required unless you
need to apply criteria. One example is the Equipment to Nozzle relationship that we talked
about before. You have to turn the one-to-many relationship into many one-to-one
relationships using the position criteria. The Scarecrow was a little drowsy from the big
burrito lunch, and wondered aloud what relations she was talking about.
"Here now, straw head, no more Mexican food for you! Try to pay attention!"

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 101

 Figure 85 Define One Edge for Each Nozzle

The Scarecrow fluttered in the breeze - "OK! I get it! If I want to talk about nozzle 2 on a
process vessel, then the object that I'm talking about is the 2nd one in the equipment-
nozzle collection, so I need to make an edge that constrains the EquipmentNozzle
relationship somehow, and I see that I can make an EdgeDef where the RelCriteria value is
'2', then just that nozzle will be returned from the equipment-nozzle query." Needless to
say, Dorothy was relieved.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 102

UML Interface Diagram
In the schema, a graph definition is called a "directed graph", and the interface is named
IDirectedGraphDef.

Figure 86 IDirectedGraphDef UML Diagram

Let's read that:

- Graph name (on IObject)
- Display name (ISchemaObj) = what the user sees when displaying the graph
- IsComparisonGraphDef - a Boolean value that specifies whether this graph
definition is used for comparison. A comparison graph definition is a special
type of graph definition that is intended for performing comparisons between
two sets of data described by the comparison graph definition.
- GraphDefn is where the individual components of the graph are stored. A + or -
in front of an element in this string indicates direction, followed by the
relationship name. Commas separate relationships traversed in the GraphDef.
- GraphDefInterfaceDef = relationship to the starting interface. The starting
interface determines which edge definitions are available to include in the graph
definition. When you are editing a graph definition, you cannot modify the
starting interface definition.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 103

UML Class Diagram
In SmartPlant Foundation, graph definitions are used to define default

Figure 87 DirectedGraphDef UML Diagram

expansions and alternate expansions for class definitions. If the name of a class definition
is the same as the name of a graph definition, the graph definition is automatically used to
define the default expansion for the class definition. For example, when you expand an
object in the tree view, the graph definition with the same name as the class to which the
object belongs, defines the default expansion that you see.

You can also define alternate expansions for class definitions. For alternate expansions to
show up on the shortcut menu when you right-click an object in the SmartPlant Foundation
client, you must create a new method that uses the GetObjsbyGraphDefName client API
and references the appropriate graph definition. Default expansions created using graph
definitions show up in the method section of the shortcut menu that appears when you
right-click an object that exposes the starting interface defined in the graph definition.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 104

 Dorothy said, "Here's a cool example - it shows a complex GraphDef that goes through the
plant, area, unit (Plant Breakdown Structure) to a piece of equipment, and then to the P&ID
on which the equipment appears!"

Figure 88 A Complex GraphDef

Description of Pattern
Graph definitions (IDirectedGraphDef) are a set of definitions with structure. These can
be edges, as defined previously or dynamic edges, such as a relation expansion, identified by
its role name. Graphs provide a way of expanding from one interface down multiple
relationship paths (did you see that in Figure 88?).

Graphs are used to support a number of operations:

- Default relationship expansion in the client is configured using a graph created
with the same name as a ClassDef.
- Reporting and other operations need to return sets of properties for the
different objects returned. These are identified in ViewDefs, which are built
on top of GraphDefs.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 105

Relationships to Other Schema Elements
InterfaceDef, EdgeDef, ViewDef

Collaborations
Graphs, edges and views are used for mapping and for SmartPlant Foundation database
queries. They are navigation aids for traveling from one role to another -- like a Yellow
Brick Road from Munchkin Country to the Emerald City.

Consequences
Creating a graph is like taking a pencil and drawing a route on a map. You start somewhere,
travel in a certain direction, and end somewhere. Perhaps that’s why it's called a "directed
graph."

Implementation
A graph is defined by a GraphDef, and is created with the SmartPlant Schema Editor. A
graph can contain an edge, which makes sense if you remember that an edge connects
interfaces. Here is a real directed graph definition. Click your Red heels thrice and see if
you can figure it out:
+IFiredHeater/+IFiredHeater/,EDG_FiredHeaterFiredHeaterSecti
on1/FiredHeaterFiredHeaterSection1/+IFiredHeater,EDG_Heating
CoilBundle0/HeatingCoilBundle0/FiredHeaterFiredHeaterSection
1,EDG_FiredHeaterFiredHeaterSection2/FiredHeaterFiredHeaterS
ection2/+IFiredHeater,EDG_HeatingCoilBundle0/HeatingCoilBund
le0_0/FiredHeaterFiredHeaterSection2,EDG_FiredHeaterFiredHea
terSection3/FiredHeaterFiredHeaterSection3/+IFiredHeater,EDG
_HeatingCoilBundle0/HeatingCoilBundle0_1/FiredHeaterFiredHea
terSection3,EDG_FiredHeaterFiredHeaterSection4/FiredHeaterFi
redHeaterSection4/+IFiredHeater,EDG_HeatingCoilBundle0/Heati
ngCoilBundle0_2/FiredHeaterFiredHeaterSection4,EDG_FiredHeat
erFiredHeaterSection5/FiredHeaterFiredHeaterSection5/+IFired
Heater,EDG_HeatingCoilBundle0/HeatingCoilBundle0_3/FiredHeat
erFiredHeaterSection5,EDG_FiredHeaterSootBlowers1/FiredHeate
rSootBlowers1/+IFiredHeater

Similar Patterns
N/A

Anti-Patterns
N/A

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 106

View Definition Pattern
"After you get through creating edges and graphs, there is an awful lot of data that gets
exposed to the user," Dorothy explained to the Scarecrow. "While that may be nice for

, normal users need a more, a-hem, 'user-oriented' view of the data for it to
be meaningful."

"I'm not sure I understand what you just said," said the Scarecrow. "How is it possible that
there is more data than there needs to be?"

"Let me explain, my old, stuffy friend", Dorothy replied, but she didn't understand why the
Scarecrow didn't understand:

Figure 89 Lots of Properties

"As you build an edge (EdgeDef) or a graph (GraphDef), you make the properties that each
interface exposes, "visible" to the user. So what seems to be a simple graph can wind up
showing hundreds of properties, and the poor end-user won't have a chance of
understanding what you really meant. It's not 'wrong', but it's just not 'right', either -- if
you look at the graph that is defined in Figure 89, what you want the user to see is just
'what's relevant', not 'what's possible' - burdening the user with dozens or hundreds of
properties that s/he doesn't care about is never OK." The Scarecrow just shrugged.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 107

 Views are the SmartPlant equivalent of relational database views, and scope down the stuff
that you're looking at to a reasonable level. Views are defined by ViewDefs. After you get
done defining paths through the data, and because you realize that each interface that you
touch can expose many properties, probably 'too many', then be nice -- make a view that
strips off the properties that are irrelevant to the 'current' view.

Identity
View Definition Pattern

Purpose
Views are the SmartPlant equivalent of relational database views, in other words, a
combination of joins and projects (pronounced prO-jécts with a long O, and accent on the
2nd syllable). Joins are used to retrieve the desired objects, and projects are used to
determine which properties (columns) to include, and what to call them. The Scarecrow
wasn't too sure of those words, but Dorothy assured him that there wasn't going to be a
quiz Friday night in the Emerald City Pub.

Usage
Views are created to "throttle down" an edge or a graph to show just what is relevant to a
user. Because you can have as many views as you want, it's easy to see that having many
precisely targeted views will give the user a better chance to understand his data.
Remember that it's easy to confuse, and hard to lose that reputation. Pretty soon,
everyone will be saying, "It's too complicated", and they'll be right. Give your users a
special treat; always give them a view when the results can be made more precise.

UML Interface Diagram

Here is what a view definition (IViewDef) looks like:

Figure 90 IViewDef UML Diagram

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 108

 Let's read that:
- View name (on IObject)
- Display name (ISchemaObj) = what the user sees when displaying the view
- IsComparisonViewDef = a Boolean value that specifies whether this view is used
for comparisons. A comparison graph is a special type of view that is intended
for performing comparisons between the two sets of data described by the
comparison view definition
- ViewDefInterfaceDef = a relationship to the starting interface

UML Class Diagram

And here's what a view class looks like:

Figure 91 ViewDef UML Diagram

The only thing that's unusual is the class factory, and that doesn't mean much outside of
the schema component.

Description of Pattern
View definitions (ViewDef) are similar to relational database views, that is, they combine
joins and projects to retrieve some set of objects. Even a simple edge definition can
expose many irrelevant properties, and it just confuses the end-user. Speaking of "too
much of a good thing", create a simple edge for equipment (IEquipmentOcc) and its nozzles
(INozzleOcc) -- there are 406 properties on those two interfaces. Are you sure that you
want a user to see all of them? Are you focused on what a Nozzle report would look like for
all the equipment in some unit of the plant -- let's say just 8 nozzles per, we're talking
about one bodacious report! Therefore, define a view so that you can just expose the
properties that are relevant at that time.

Relationships to Other Schema Elements

InterfaceDef, GraphDef, EdgeDef

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 109

Collaborations
A view definition (ViewDef) is based on a directed graph (IDirectedGraphDef), and
therefore, like the directed graph, has a relationship to its starting interface. This
interface is always the same interface as that for its directed graph. The directed graph
for the view defines the set of edges that will be traversed when the view corresponding to
the view definition is created.

In SmartPlant Foundation, views are used to define what users see in the Properties window
when they select an object in the client. When you create ad hoc reports in the SmartPlant
Foundation client, you can also select the view that you want to use as the basis for the
report, as well as the properties from that view that you want to include in the report.

Furthermore, you can use views to create alternate views for classes.

Consequences
Good views make queries and ad hoc reports easier to understand by end-users.

Implementation
Views can only be made using the SmartPlant Schema Editor.

Similar Patterns
A database-based person would recognize the idea of views, joins, and projects presented
here.

Anti-Patterns
N/A

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 110

Shared Objects, Expansion, and SameAs Pattern
One of the really powerful ideas in the SmartPlant Enterprise suite is the concept of
collaborative engineering that is actually built in at the lowest levels of integration. If your
collaborative team thinks like this:
- Conceptual design
- Early-stage design
- Detailed design
- Procurement
- Construction
- Reuse good ideas for next facility
- and so on
then you can make good use of "shared objects" and "object expansion", by using
"correlation" and the "SameAs" relation, plus the MatlExpansion relationship.

Identity
Shared Objects, Expansion and SameAs Pattern

Purpose

Once upon a time, there were

- Papa bear, who thought great thoughts of process plants that he would like to
build, because those chemicals and pharmaceuticals would be needed "someday
soon."
- Mama bear, who enjoyed taking her husband's ideas, and doing detailed analysis,
even creating reports, generating data sheets and such.
- Brother bear, whose job was to "get 'er done" - he bought the stuff and made
sure that it was assembled at the right time, and in the right place.

Papa bear uses Aspen Basic Engineering to do simulations of the process plant, and Aspen
PFD software to get a look at piping flow diagrams. The output of his day consisted of
theoretical units that were mostly thought experiments. Some of them are called unit
operations, because they defined how a unit is supposed to perform, for example, some unit-
op is needed here so that the fluid pressure gets increased by 5%. Other things probably
came from earlier designs that were similar to this one. After you've built a couple of
yogurt plants, the next one should be pretty easy because you know a lot about what's
required.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 111

Mama bear uses SmartPlant P&ID to draw up some mighty fancy piping diagrams. She uses
SmartPlant Instrumentation to add things like pressure gauges and safety valves. When
she's on a tear, she puts on her green eyeshade and fires up Smart 3D - the entire yogurt
plant is modeled pretty well, and some days she does interference checks with different
piping systems, in different areas of the plant.

Brother bear uses Smart Materials (previously called MARIAN) to procure the pipes, valves,
pumps and such, from various manufacturers. When the stuff arrives, he checks the serial
numbers and keeps a pretty good check-list of what's what. Then he's got a pretty busy
day sending stuff to the right units, where it is being assembled according to a schedule -
he can almost taste the yogurt now - mmm'mmm - right tasty!

Got the picture? A happy team of collaborative engineers, who share data, and schedules
and ideas, and previous knowledge about stuff -- a fairy tale, you say? Nope - they're using
SmartPlant Enterprise-enabled tools to do all that stuff (will they live happily-ever-after?
Dunno)

What they do is share stuff like this:

- Papa bear is generating requirements for facilities
- Mama bear is refining the facilities into material
- Brother bear handles the actual material and does installation, construction, and
testing.

Does any of this have a familiar ring? It ought to. The only problem is that there are a few
ideas that need to be worked out before all this can happen:
- How do you know that Papa bear's requirement for increasing pressure
o is fulfilled by a pump that Mama bear will order
 and that's the same pump as Brother bear will install and test?
• and keep track of forever
o and use the same ideas in the next yogurt plant
 and so on
- What happens if Mama bear deletes the pump from her P&ID?
o How does she tell Papa and Brother bear?
 And what do they do?
• and so on
- What happens if Mama bear needs to order 2 pumps to fulfill the "increase
pressure" thing that Papa wants to do? Mama bear is conservative, and wants to
have a safety factor built-in. How does she let everyone know what's up?
- When a pump is delivered from the vendor, how does Brother bear know which
one it is? Where is it on that darned old P&ID? The P&ID changed since the
pump was ordered? Mama bear deleted it? Oooops!
- What if Mama bear goes on vacation? Who will print the equipment data sheets
so that Brother bear can order stuff?
- and so on

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 112

 Did you ever sit and think about all the problems involved in collaborative engineering? Even
in a small, tightly-integrated group, it's bearly possible to do real stuff, without losing track
of everything.

One way to keep track of "things that are shared by different folks" is to define them (in
the schema) as "shared", and track them that way. The facility for increasing pressure in a
pipe line that Papa bear wants, becomes pump P-101 on Mama bear's P&ID. The two pumps
(his/hers/theirs) are the same "shared pump." When Brother bear gets the Equipment
Data Sheet from Mama bear, he orders it from the vendor, and it arrives as an actual pump,
with a serial number - but it is the same "shared pump." How did it get to be that way?
Through the concepts of "shared objects" and the SameAs relation.

Usage
In the real world of collaborative engineering, there is a need to identify and share objects
that are created by different tools, at different times. The schema "enables" the sharing
of objects between the tools. After an object is published by someone, other tools can
"correlate" that object to their own object, and once that is done, all the tools that have
correlated objects can access and change all the data (that they are allowed to do by rule).

UML Interface Diagram

Figure 92 is the UML diagram for a shared object.

Figure 92 ISharedObjDef UML Diagram

That's pretty easy to read:

- A shared object (ISharedObjDef)
o has a relationship with (Sharing)
 a class (IClassDef)

UML Class Diagram

Look at this UML diagram, which shows how shared objects are modeled:

Figure 93 Shared Objects UML Diagram

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 113

 The schema object SharedEquipment_PM (where PM = Planned Material) has a <<Sharing>>
relationship with 3 classes. What that means:
- An instance of a PIDMechanicalComponent
- and an instance of EQDVerticalCentrifugalPump
- and an instance of EQDCentrifugalPump
o are eligible to be shared by different tools, published at different
times, and changeable by any of the other tools.

Say what? can all work on their different ideas about what "they" need,
but then come together later on, inside the SmartPlant Foundation database, and "share"
their objects with each other. His pump/her pump/their pump - that's pretty useful in a
collaborative engineering environment, for example, because they don't have to wait for
each other to finish something before they can move on.

Description of Pattern

Didn't President Franklin Roosevelt say ? Too bad he didn't

know about "shared objects" - it turns out that those 2 pumps on the P&ID may be just
"material expansions" of the one pump on the PFD. But how's a bear to know?

SmartPlant Enterprise doesn't just have a correlation step (which establishes a SameAs
between pumps), the publishing software can also publish a "material expansion"
relationship, for example, one pump to two (for a lot of good reasons, this happens pretty
regularly during the design stage).

Figure 94 Material Expansion Schema

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 114

 (sung to a familiar baseball tune) Oh say, can you see how a pump on a P&ID (an instance of
PIDMechanicalEquipment) can become 2 pumps on an equipment data sheet
(two instances of EQDCentrifugalPump, related with the MatlExpansion relationship)?

Look at the 2 pumps in Figure 95. They're there because of a design decision. On the PFD,
there was only 1. Probably, the PFD pump will be correlated to (via SameAs) P2A, and there
will be a material expansion relationship (MatlExpansion) published between P2A and P2B.
At least that's what we're hoping for.

Figure 95 Material Expansion on a P&ID

Relationships to Other Schema Elements

ClassDef

Collaborations
This pattern allows tools to share objects, and to expand objects - that's right at the heart
of the modern collaborative engineering design processes. Different engineers, using
different tools can define specifications for something, and then fulfill the role with
something, and later, expand the fulfillment - life is good.

Consequences
SmartPlant Enterprise tools can publish and retrieve objects and share and expand them
with this pattern. Shared objects allows tools to:
- Declare that my "this" is the same as your "that"
- Support the idea that one of your "things" is the same as more than one of my
"things"

Implementation
To make shared objects and material expansion work, you need to do this:
- Two or more tools publish objects
o The ClassDef for the object must be a shared object
 With the same shared object definition (SharedObjDef)

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 115

 - The objects are correlated (by a human, by a manual process), which creates a
SameAs relation between the objects
- If object expansion is necessary, for example, 1 pump to 2, then a relationship
(MatlExpansion) is published between the base object and its siblings.

Similar Patterns
N/A

Anti-Patterns
You might want to be careful about the SameAs relation and material expansion
relationship, if they are both used in the model (which is pretty likely). There is a
possibility of an obscure side effect, that is, the properties of pump P2B may not be the
same as the properties of pump P2A, which is the pump that is correlated to the pump on
the PFD. In this case, any properties that are different on pump P2B may not show up in a
standard query, because the query may not know about the material expansion (just a
caution).

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 116

Business Patterns
After understanding the lower-level patterns, we now can build more complex, business-
oriented solutions.

POSC/Caesar Pattern
A key part of the underlying "Architectural Model" of the schema has its roots in
POSC/Caesar. Please refer to Chapter 23 in "A Gentle Introduction to the SmartPlant
Schema" for a good introduction to this topic.

Identity
POSC/Caesar Pattern

Purpose
The POSC/Caesar data model can serve as an overall model for a process plant, or any large
facility, from the conceptual design phase through construction, handover, operation and
decommissioning and dismantlement.

The POSC/Caesar model was one of the first complete models to consider the entire
lifetime of a facility. There are two main concepts that are proffered by POSC/Caesar:
- The early-stage concept of a "Facility model" = conceptual things, for example,
the output of a simulation. Or, the Company President saying "we're going to
need a new polymer production facility" (he doesn't know how many pumps will be
required).
- The late-stage design concept of a "Material model" = purchased, fabricated, or
constructed things, for example, a pump that is ordered from a catalog and
installed in a plant.

Usage
The schema has some of the POSC/Caesar ideas "built-in", for example:
- Simulated facility = for example, the output of Aspen Zyqad
- Typical material = catalog data
- Planned material = material that we plan to purchase
- Actual material = an item with a serial number
- and so on

UML Interface Diagram

Let's look at the two main models, namely, "Facility model" and "Material model", then put
them together into an overall model.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 117

Facility Model
The abstract part of the design process is used to figure out how the facility will be built,
what components need to be acquired, what steps are required to construct the facility, and
so on.

Figure 96 Facility Model

Here is a brief description of the different phases of the facility model:

- Typical facility = an example of a facility, for example, a typical distillation
column.
- Simulated facility = the output of a simulation that helps in the design of a new
one
- Expected facility = what the new facility is expected to be, to look like, and so
on.
- Predicted facility = last time, we used 40 pumps, so we predict that this time,
we'll use 40 pumps
- Required facility = we know that the EPA is going to require a special pollution
control system on that incinerator
- Planned facility = we plan to construct a steam generation facility
- Actual facility = here is our new Baytown gasoline manufacturing facility.

Material Model
The Material model is used in the procurement and fabrication process that will fulfill the
design requirements that were established in the Facility model.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 118

 Figure 97 Material Model

Here is a brief description of the different phases of the Material model:

- Typical material = an example of an object. It is also called a catalog item
- Required material = on a P&ID, the designer knows that a pump will be required
to raise the fluid pressure by 20 psi
- Planned material = a plan to purchase something. It (that "something") is
represented as a "tagged item For example, on a P&ID, P-101 means pump 101.
- Predicted material = If we buy that pump, we need to buy the related motor to
drive it (and the mounting hardware, and the connecting hardware, too)
- Actual material = contains the serial number of an item and its installation and
maintenance history.

UML Class Diagram

N/A

Description of Pattern
Here's an easy way to think about the pattern: in the design process, "Facilities evolve into
Material."

Facility Model
The POSC/Caesar workflow implies that Facilities evolve from simulations, predictions,
requirements into planned, and finally actual Facilities.

Simulated --> Predicted --> Required --> Planned --> Actual

Facility Facility Facility Facility Facility

The schema doesn't support all of these steps, but can easily be enhanced, if that is
required.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 119

Material Model
We think of Typical material as catalog items, for example, you can find a typical pair of
shoes in a store’s catalog.

Typical --> Required --> Planned --> Actual

Material Material Material Material

The flow chart just above shows how things are specified in a "catalog", for the purpose of
fulfilling a (required or planned) requirement, then the items get a "tag", get purchased, and
finally, an item with a serial number is installed.

Feedback / Feed Forward

The above scenarios showed data advancing from left-to-right as the design process
progresses, but data can also flow from this design into a subsequent design, so it looks like
the data flow is from right-to-left. For example, if we build a process plant that uses 40
vertical sump pumps, we can feed that information into the "Predicted Facility" model when
we make the next "similar" plant. That results in a relationship between "Planned Facility"
and "Required Material", but it is a time warp thing:

Figure 98 Version n+1 of Facility is Based on Version n

It isn't the Planned Material of this plant feeding the Required Material of this plant, so
don't get confused - the feedback-looking relationship is really a feed-forward relationship
(from this instance of a plant to the next planned facility).

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 120

Relationships to Other Schema Elements
It was rumored General George Washington made this quote while crossing the Delaware in
that cold December of 1776? Look at this actual photo:

Occurrences are
Planned Material

Figure 99 Washington Crossing the Delaware

Now, look at Figure 100, below. What the Father of our country probably meant was: "If
you see a pump on a P&ID, and it has a "tag number", then the designer has it in his mind
that someone is going to procure a pump and associate it with that tag number."

Figure 100 A P&ID Pump With Tag P-142

In the schema, we mean that a "tagged pump" is "an occurrence of a pump", because we
expect an occurrence of it to appear somewhere, for example, in the plant, when
construction is complete. The pump occurrence is in the Planned Material model, because
someone plans to purchase the pump. George says, "Repeat after me: 'Pump P-142 is an
occurrence of a pump'."

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 121

The woman in the Procurement Department, upstairs, will probably look for a pump in the
latest Cat Pumps catalog. There are several hundred pumps in there, and they are called
"Typical material", because they represent, typically, what you're talking about, when you're
talking about a pump. She's probably looking at this:

Figure 101 Pump Catalog

The pump that is purchased (to fulfill the requirement of a "tagged pump" on a P&ID) is
called "Actual material", and has a serial number, maintenance history, and so on, which are
attributes of that "actual pump", not the "tagged pump."

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 122

 Figure 102 Pump S/N RH-GH5002-Z

Relationship Definitions
In order to accommodate the cycle of Typical material -> Required material -> Planned
material -> Actual material, the schema has some relationships that help out:
- From Typical material to Planned material = PlannedMatlActualization
- From Typical material to Required material = Typical_Required
- From Required material to Planned material = PlannedProcurement
- From Planned material to Actual material = Procurement
- From Planned material to Planned material = MatlExpansion

In the Facility model, the schema has the following relationships:

- Simulated facility to Predicted facility = Simulated_Predicted
- Predicted facility to Required facility = Predicted_Required
- Required facility to Planned facility = DetailedProcessDesign
- Planned facility to Actual facility = Planned_Actual

And the relationships from the Actual material model of this design cycle feed forward to
the design cycle of the next facility like this:
- Required material to Predicted facility (not implemented)
- Planned material to Planned facility (not implemented)
- Actual material to Planned facility (not implemented)
- and so on

Collaborations
SmartPlant-enabled tools work in a collaborative engineering environment to evolve a design
from "Facility" to "Material", and then on to the next "Facility." The patterns that are
learned in one design can be applied to the next, similar design - that saves time and money!
The full-lifecycle approach of the POSC/Caesar Pattern maximizes the probability that all
phases, from conceptual process design through facility operation are exploited, as much as
possible.

Consequences
Using the POSC/Caesar Pattern leads to clear thinking about the holistic engineering design
cycle:
- Conceptual Process Design
- Conceptual Engineering Design
- Detailed Process Design
- Detailed Engineering Design
- Procurement

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 123

 - Construction
- Commissioning
- Operate facility
- Decommission
- Tear-down
- Construct new, similar facility, based on lessons learned

Even if all of these phases aren't implemented right away, the underlying architecture and
schema artifacts are present and can be enabled later on. Don't you agree that the
consequences of thinking about a "holistic design cycle" can be mighty beneficial?

Implementation
Upstream, in the Conceptual Design phase, we're thinking about abstract facilities, so
classes there will probably realize "Facility" interfaces. Farther downstream, in the
detailed engineering phase, classes will realize the "Material" interfaces. Figure 103 shows
how the requirement for a pump on a P&ID (a "facility") is fulfilled by a pump on an
equipment data sheet ("material") via the PlannedFacility_PlannedMaterial relationship.

Figure 103 Two Pumps that are Polymorphic with Respect to IMaterialItem

Similar Patterns
The POSC/Caesar model has been absorbed into some of the more recent European
standards.

Anti-Patterns
N/A

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 124

Typical Material vs. Planned Material Pattern
The topic of Part vs. Occurrence was covered in "A Gentle Introduction to the SmartPlant
Schema", but significantly changed with Version 2008 (4.2) of the schema. This chapter
describes the schema.

Identity
Typical Material vs. Planned Material Pattern

Purpose
In the collaborative engineering design life-cycle, the engineer might start with a
requirement, and fill it with an item from a catalog, or start from a catalog item, and then
use it in the design. We discussed the idea of a "facility" evolving to "material" in the last
section (§5.1). The schema has a model of "typical" things and "planned" things built right
in. If you want pump P-101, on a P&ID to be a specific pump, for example, from a certain
pump catalog, then "have we got a deal for you."

Usage
Do you remember that planned material is, for example, "a plan to purchase something" and
that maybe it can be from a catalog of "typical" stuff? The schema has a way to represent
planned material (IPlannedMatl) and a way to represent typical material (ITypicalMatl), so
let's see how they are used.

Typical Material
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 and so on

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.

Now, think about Animals: you're probably visualizing, for example:

- Animals

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 125

 o Mammals
 Dogs
• Poodle
• German Shepherd
 Cats
• Siamese
• Tabby
 Elephants
o Reptiles
 Crocodile
 Snake
 and so on

The class "Animals" contains the subclasses {Mammals; Reptiles}, each of which contains
closely-related subclasses, and so on. Now, do you understand what a "class type hierarchy"
is?

Common properties about a class are grouped together and yield up a "typical" role to the
universe (via the ITypicalMatl interface), for example, a characteristic of the class of
mammals (Mammalia) is that they typically have hair.

What Else Does Typical Mean?

Besides "type-ness", what else is "typical" about an item? On a valve, how about inlet size,
outlet size, weight, height, and so on. If you have those properties exposed by a typical role,
then instances of that item won't have to carry many of their own properties. Try this: if
the weight, height, and yada yada is "typical" of all pumps, then what do you need to say
about a pump, except that it is based on such-and-such "typical pump"? That's pretty
useful, and beats thinking about having a big slug of properties at the occurrence level.

Typical is Optional
There really doesn't need to be a "typical" 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", that is, a "tagged" item. In addition there may be
valves that are called typical valves, which describe characteristics of valves in general, but
do not show up on, for example, a P&ID. Other tools may publish valves in a catalog, and
maybe valves that have a serial number (actual valves).

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 126

UML Interface Diagram
This is the correct "conceptual schema" of manufacturer, model and catalog:

Figure 104 Conceptual Schema of Manufacturer, Model, Catalog

Reading Figure 104, we see that:

- A manufacturer can have many "models" of things, for example,
o A pump manufacturer has many pumps, each of which gets a model
number assigned to it
o A valve manufacturer has many different valves, each of which gets a
model number assigned to it
o and so on
- Those models can be listed in many different catalogs, for example,
o The pump catalog example shows model number 230, but that same
model "230" might appear in several manufacturer or distributor
catalogs, that is, the old many-pumps-in-many-catalogs trick
o You are allowed to have 'catalogs of items' that aren't manufactured,
and don't have any model information, for example,
 A reference, or catalog of "best assembly practices for piping
components" is still a catalog, but you wouldn't call each of them
a model. Any kind of reference data might live in a catalog.

That looks pretty good, but the addition of the IManufacturer interface and the new
relationship Mfr_Models could cause tools that publish data some problems, because they
would have to keep track of those new objects in their data space. Therefore, let's look at
that model, but denormalize IManufacturer and IModel into one interface, shown in Figure
105.

Figure 105 Denormalized Manufacturer, Model Plus Catalog

It's OK to get rid of those extra objects, and it doesn't create any ambiguities in the
model.

Now, let's say that we've already got the interface IManufacturedItem that already has
those properties, plus a couple more, and then let's hook that into the Typical material
model, as in Figure 106.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 127

 Figure 106 Typical Material Model

That shows that manufactured items can be thought of as "typical material."

Finally, Figure 107, below, shows the Typical material and Planned material models together:

Figure 107 New Typical and Planned Material Model

Here's something that's easy to understand: An instance of "typical material" is brought

into existence ("actualized") by purchasing it, for example, when you look in a store’s catalog
at a pair of shoes (typical material), you can make them be on your feet (actualize them) by
purchasing them.

Planned material items are, for example, items that are tagged, and are later purchased. Do
you get it?

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 128

 Figure 108 A Pump on a PFD and a Pump in a Catalog

Look at the PFD in Figure 108. Maybe the "Feed Pump" is a 200 gpm pump:
- You (in collaboration with a specialist) look at the "type hierarchy" of pumps and
decide that you need a vertical, centrifugal pump to fulfill that role
- You look for one of those in a manufacturer's catalog and find it!
- Now you can actualize it (plan to purchase it). I don't know what your process is
for doing that, because everyone invents their own workflow, but if your
procurement system is integrated with SmartPlant Foundation, life will be a lot
easier when you go to procure the item.
- Did the item need to come from a catalog? Nope.
- Is it helpful to have a pump catalog if you want to order a pump? Usually.
- Note: This idea works both ways across the PlannedMatlActualization
relationship, that is, you can find planned material by looking it up in a catalog or
you can start from a known catalog item and plan to purchase it.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 129

 Figure 109 Abbreviated UML of Relief Valve

Thinking of a "valve-as-planned-material", what are the common characteristics that

describe the "valve-planned-material-ness"? Well, I can think of, for example, mounting
angle, height-above-ground, and so on. What about you?

Understand this: a "valve-as-typical-material", that is, a valve in a catalog, can't possibly

know how an occurrence of a valve (IReliefValveOcc) will be mounted or its height above the
ground, and so on, so "typical material" properties are different from "planned material"
properties.

Now that you understand the basic concepts of "typical" and "planned" material, let's see
how it is applied to a couple of good examples, for example, equipment, cable trays, cables,
and that kind of stuff. Several examples will bring home the points better.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 130

 Figure 110 Equipment and Equipment Components

Here's a nice, rich, juicy diagram, and you should take the time to understand the subtle
flavors:
- Equipment and components might appear in some catalogs (Mfr_Model_Catalog)
- The "typical material" role may expose "typeness", for example, IEquipment
exposes properties for the equipment type hierarchy
- Occurrences of equipment (IEquipmentOcc) and components
(IEquipmentComponentOcc) are "planned" material, and are commonly called
"tagged" items
o Each of the tagged items might have some of the characteristics of the
typical material, because they share interfaces (via the Implies
relationship between IEquipmentOcc and IEquipment). For example,
"typeness" might be shared between an object that exposes both
IEquipment and IEquipmentOcc.
o However, the properties on the tagged item might be different from the
properties on an item that is typical material, and if so, then two objects
are published, and are related to each other by the
PlannedMatlActualization relationship, or a child of it.
o Occurrences (planned material) are usually part of a Plant Breakdown
Structure, for example, Plant / Functional Area / Functional Unit, or
similar.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 131

 Figure 111 Cable Tray and Cable Tray Components

Does the cable tray model look familiar? It's supposed to because this a book about
patterns!

Figure 112 Cable Stuff

By now, you should be able to see the pattern that will be replicated for all the other
schema elements.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 132

UML Class Diagram
Let's build up a hypothetical model from the simple concepts that were presented. First,
here are a few pump catalogs.

Figure 113 Pump Catalogs

Now, here is an abbreviated UML diagram of "a pump, in a pump catalog":

Figure 114 A Pump in a Pump Catalog

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 133

If you really want to see what roles are on that "pump, in a pump catalog", here's what it
looks like:

Figure 115 A Pump In a Pump Catalog

Now, here is the piece de resistance, that is, a pump catalog, with a selected pump (typical
material), and that pump is related to a pump on an equipment data sheet (therefore, we
plan to purchase it). SO - the typical material pump (a very nice Gould pump) is actualized
by a planned material pump, after all.

Figure 116 Typical and Planned Pumps

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 134

Description of Pattern
Typical means "exhibiting the qualities or characteristics that identify a group or kind or
category." Typical material, therefore, exhibits the qualities or characteristics that
identify a group or kind or category of material items. Examples are typical pumps, typical
valves, typical compartments.

Planned material is a plan to purchase (or fabricate) something. If you look at a PFD and see
that you need a pump, you're probably going to need to purchase it. Where to get it? What
should it look like? What characteristics are important? Really, only a domain expert
knows.

The expert will probably fill out an equipment data sheet, which defines some of the
important characteristics that must be fulfilled. Probably, someone will reach for a couple
of pump catalogs, grab the data sheet, and try for the best possible match between
requirements and what is listed in the pump catalog. When the best match is found, the
item that is identified on the equipment data sheet, and the item that is picked from the
catalog get related (PlannedMatlActualization), so that later on, when the pump is ordered,
and delivered, it can be tied back to the original requirement.

Relationships to Other Schema Elements

N/A

Collaborations
The typical material to planned material workflow is what the dear customer knows all about
(we sure don't). Somehow, our customers have figured out the optimal procedures for
looking at a tagged item on a P&ID and figuring out how to get it to the worksite. Does the
SmartPlant schema help? Yes, because reports can be generated from SmartPlant
Foundation that show the status of the item, from the time that it first became a
requirement up until it is installed and tested, maintained, and decommissioned.

Consequences
Changing the model makes it a lot clearer, and makes it correct. Summary of changes:
1. The IPart interface has been eliminated, use ITypicalMatl instead
2. The IPartOcc interface is gone, replaced by IPlannedMatl
3. The Part_PartOcc relationship is gone, replaced by PlannedMatlActualization
a. If your tool needs a specialization of this relationship, contact support
4. A new interface ICatalog has been added, it exposes the catalog properties. We
could add catalog ID, catalog year, version, revision, or anything like that.
5. A new interface IMfrModel has been added; it exposes manufacturer name and
manufacturer model number. Because it implies ITypicalMatl, the Name field of the
underlying object will contain the catalog part number
6. A new relationship MfrModel_Catalog is added so that catalogs can reference parts
in either a manufacturer catalog or a distributor catalog (where a single catalog lists
the contents of many catalogs).

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 135

 7. When IPartOcc was deleted, the property CatalogName was deleted, because it is
really the Name property of ICatalog.
8. Also, the property CatalogPartNumber is gone, because it is really the Name
property of ITypicalMatl
9. The IManufacturedItem interface moves, so the classes that realize it will need to
be looked at.
10. Relationships that are specializations of PBSItemHasImpliedParts need to be fixed
up, that is, OwnsImpliedItems

These changes will:

- Get rid of the ambiguity of having CatalogName and CatalogPartNumber exposed
by an incorrect interface, when they are really Name properties on two other
interfaces.
- Get rid of two interfaces and a relationship that really contribute no additional
meaning to the model (they make the model ambiguous)
- Add the ICatalog interface to the model, which will let tools properly publish
catalogs and therefore, catalog data
- Correct the behavior of manufacturers, models, and catalogs

How it affects you:

- If you map to and/or publish IPart, IPartOcc, IManufacturedItem,
CatalogName, or CatalogPartNumber, or Part_PartOcc, then your mapping will
have to be updated to reflect the new model
- A schema transform will need to be developed to move the properties to their
new home
- A schema transform will need to be developed to move Part_PartOcc
relationships to the PlannedMatlActualization relationship
- Data migration will have to be done to any customer data that used these
interfaces, properties, or relationships.

How it benefits you:

- You will be able to cleanly publish and retrieve catalog data
- It will get rid of the ambiguity of the properties CatalogName and
CatalogPartNumber and properly represent them in the schema, so that
retrieving applications will have an easier time with retrieval.

Implementation
Typical and planned material roles are easy to implement. Looking back at the Equipment
and Equipment Components UML diagram in Figure 110, we see that underlying pattern of
polymorphism, that is, a pump that is viewed as typical material (IEquipment implies
ITypicalMatl) or planned material (IEquipmentOcc implies IPlannedMatl).

Similar Patterns
N/A

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 136

Anti-Patterns
N/A

Collection Pattern
A collection is a group of things that is considered as a whole or a group of items that has
one or more common properties. By "common properties", we mean "in whatever way is most
convenient for the user."

Identity
Collection Pattern

Purpose
A collection is very common in real life. Sometimes it is obvious, for example, "a herd of
buffalo" is a collection, but sometimes it is less obvious. For example, "the work processes
that it takes to build a process plant" is a collection, too.

Listen up: if you're still not convinced that the mind of a Data Modeler (DM) is strange, just
try to follow along:
1. Looking at the local supermarket parking lot, you see a bunch of cars
a. DM thinks: "Therefore, the parking lot is a collection of cars."
2. A supermarket parking lot may be many things, but as data modelers, when we see
the "is a" phrase, we think, "implies."
a. DM thinks: "A something that is also something else."
i. DM thinks: "Role 'A' is extended by role 'B'."
1. DM thinks: "We extend the role of ‘parking lot’ to include the
role of being a collection of cars,"
thus:

Figure 117 Collection (of cars)

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 137

 3. Look at the roles and cardinalities on the "Cars" relationship definition (RelDef), and
read with me: A parking lot is a collection of cars, which may have zero, 15, or

10,000 cars in it. "In fact," says, "Next time you're at the
supermarket, check it out and see if that's true about the 10,000 cars -- especially
if you're in a rush to just pick up a quart of milk!"
4. Pay particular attention to the "minimum" cardinality on the Car Collection role - it is
zero, which has some special meaning:
a. A car can exist without being in a collection, because a car can belong to
zero or one collections
b. From which we, as great and powerful wizards of data modeling think, "That
means that if the parking lot goes away, the cars will still be there!" Hoo-
boy - data modeling anyone?
5. Isn't it interesting that the maximum cardinality on "Car Collection" is 1? It means
that a car can only be in a maximum of 1 parking lot at a time (a data modeling joke:
active moms wish that this could be *). Hoo-boy - surf's up - data modeling anyone?

Let's go one more round with the idea of "minimum" cardinality of zero. Think of a
collection of peas in a peapod. If the peapod is disposed of (cardinality goes to zero), do
the peas still exist? Compare and contrast this behavior with the "Composition Pattern",
below.

Usage
The Collection Pattern is widely used, and easy to understand. Examples include wires in a
cable, components inside your computer, the junk in your kitchen drawer. Something acts
like a collector, and there are some items that participate in that collection.

One nice feature of collections that are defined in the schema is that they can be
"ordered." When you put a collection of colored lights into a StopLightController object,
you can put them on in a certain order (probably Red, Yellow, Green), which the retrieving
application will know, when it retrieves your document.

UML Interface Diagram

Look back at Figure 111 for the UML diagram of a typical collection.

UML Class Diagram

N/A

Description of Pattern
Items that are somehow related are grouped into collections. The collector has a
cardinality of 0..1 and the collection has a cardinality of 0..*.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 138

Relationships to Other Schema Elements
Collections are formed between interfaces (InterfaceDef). Views can also reference
collections. For example, you might want to make a view of the first 8 nozzles on a vessel,
and iterate through them in a certain sequence.

Collaborations
The retriever of a collection iterates through the set of objects in the collection, and one-
by-one consumes them.

Consequences
The retriever of a collection expects zero or more items to be returned from the collection.
They may or may not be in sequence, based on whether the RelDef declared the collection
to be ordered.

Implementation
Best practice is to imply a collector and relate it to a collection. Look back at Figure 117.
What we're trying to communicate is that a "parking lot" is extending its functionality by
implying that it is a "collection of cars", in addition to whatever else it is.

Similar Patterns
Composition Pattern

Anti-Patterns
Almost any relationship can be thought of as a collection, but that's not quite right.
Relationships where both cardinalities are "0..1" or the minimum cardinality is greater than
zero are probably not called collections.

Composition Pattern
A collection is a group of things that is considered as a whole, or a group of items that has
one or more common properties. A composition is a special type of collection that has a
strong "delete semantic", which means that "if the collector is destroyed, the collection is
destroyed, too."

Identity
Composition Pattern

Purpose
A composition is a type of collection that frequently occurs during the "design phase" of a
new facility. For example, let's say that a designer draws a vessel on a P&ID, and hooks up
some pipe lines to some of the nozzles on the vessel. What happens to the nozzles if the
designer erases the image of the vessel? If the nozzles are in a "composition" relationship,
then they all go away! (Lack of parent forces lack of children.)

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 139

Usage
The Composition Pattern is used when there is a strong delete semantic between a collector
and members of its set (of elements). The example of a pump and its nozzles is a good one -
- nozzles do not exist without a parent equipment of some kind. So if the parent (a pump) is
deleted, logically, the nozzles must be deleted, too.

UML Interface Diagram

Here's a simple example of a Composition relationship definition. For example, if the

Aquarium burns to the ground, the fish tanks go away, too. We can't be sure of what
happens to the fish, because they're not modeled, but I bet that someone will be saying,
"Look out tummy -- here they come!"

UML Class Diagram

N/A

Description of Pattern
Items that are closely related are grouped into compositions. The collector has a
cardinality of 1 and the collection has a cardinality of 0..*. Because of the cardinality of 1,
no children can exist if the parent is deleted.

Relationships to Other Schema Elements

Compositions are formed between interfaces (InterfaceDef). Views can also reference
compositions. For example, you might want to make a view of the first 8 nozzles on a vessel,
and iterate through them in a certain sequence. With the composition relationship, if the
vessel goes away, so do the nozzles.

Collaborations
The retriever of a composition iterates through the set of objects in the collection, and
one-by-one consumes them. The relevant difference between a collection and a composition
is that a semantic must exist that takes care of deleting children when the parent goes
away.

Consequences
Compositions are used to specify collections whose existence depends on a parent.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 140

Implementation
The collector-side of the relationship definition (RelDef) contains a cardinality of "1".

Similar Patterns
Collection

Anti-Patterns
Please be careful about specifying a Composition instead of a Collection. Be real sure that
the strong delete semantic is required -- do your analysis homework!

Connectivity Pattern
The "Connectivity Pattern" shows how an object called a "connector" exposes logical points
called "connections", to which other objects may connect.

Identity
Connectivity Pattern

Purpose
Define how "connectors" and "connections" behave so that networks of pipes, or electrical
wires, or whatever, can be put into the model.

Usage
The Connectivity Pattern is applicable to most kinds of connections that are in a normal
network of physical objects. Examples include piping systems, electrical wiring, connecting
equipment to a pipe run, and so on.

UML Interface Diagram

In UML, the connectivity model looks like this:

Figure 118 The Connectivity Pattern

says that Figure 118 can be read as "Many connectors can be related to many
connections." So we need to understand the role of "connector" and "connection", and then
look at how the relationship between them is defined.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 141

UML Class Diagram
N/A

Description of Pattern
Forming connections between objects is very common in the engineering world. For example,
pipes are connected together, electrical wires are connected together, HVAC ducts are
connected together, in-line equipment connects to nozzles, which connect to a pipe, and so
on. The Connectivity Pattern explains how objects can connect with other objects via a
relationship named "Connections."

Connector
The word "connect" means "something that joins or fastens together." Therefore, a
"connector" is defined as "an instrumentality that connects", for example:
 A water pipe joins a water storage tank to a place where the water is available for
sprinkling on the garden. The water pipe is a connector.
 An electrical wire joins a fuse box to a toaster. The electrical wire is a connector.
 A steel beam joins two floors of a building. The steel beam is a connector.
 A series of pipes are connected from point 'A' to point 'B', and are called pipe run
'P'. Each pipe is a connector.

Interface Definition "IConnector"

The SmartPlant schema exposes the role of a connector via the IConnector interface, which
is represented like this:

Figure 119 IConnector

reads Figure 119 like this:

 A connector may have a "flow-direction" property
• Connector flow direction values are:
 end 1 to end 2
 end 2 to end 1
 Bi-directional
 None
 Undefined

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 142

  A connector may have an estimated length
 A connector, in some circumstances, may have a representation on a drawing, that is
zero-length, and all of them together are zero-length.

What does that mean? Check it out: in a pipe, fluid may flow from end 1 to end 2, or from
end 2 to end 1, or either way, or maybe we don't know which way it flows (yet). We're
guessing that the pipe might be 10 feet long. We don't have a clue what the "all zero
length" thing is, so we'll ignore it. That wasn't so bad!

Connection
The logical, not physical, point where two things join is called the "connection point", or
simply the "connection." For example, the logical place where one pipe connects to another,
or one wire connects to another wire, and so on, is called a "connection." The "physical
connection" might be large or small or simple or complex, but it is represented as a "logical
point" in the Connectivity Pattern.

Interface Definition "IConnection"

The SmartPlant schema exposes the role of a connection via the IConnection interface,
which makes a UML diagram like this:

Figure 120 IConnection

reads Figure 120 like this:

 A connection may have a "connection flow-direction" property
• Connection flow direction values are:
 Bi-directional
 Inlet
 Outlet
 None
 Undefined

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 143

 Doesn't that just say that the logical end of a pipe can be expected to be used as an inlet,
an outlet, both, or I dunno yet? If you picture a simple garden hose, how do you know which
end to screw into the faucet, and which end do you then expect water to come out? I hope
you're able to figure that out in real life, or you will be getting wet at least 50% of the time
that you use a hose and spending the other 50% of the time, wondering why the hose
doesn't screw onto the faucet at all - sounds like a generic "college of your choice" joke. Do
you see how, in SmartPlant Enterprise, you could set those values into the hose when you
first drew the hose on a P&ID? "I guess it's going to be 50' long, and the fat end is the
inlet, while the male end is where the water will come out."

Relationships to Other Schema Elements

Now that you understand connectors and connections, look back at Figure 118 again. Do you
see how a connector, for example, a pipe, is related to "many" connections (in this context, a
"many" means 0 or more)? Let's say that a pipe has 2 ends, each of which is a connection,
plus you can tap into any point on a pipe (how many points is that, 0, 1, 2, 100?) That's why
we just model the cardinality on each end of "Connectivity" as "many"; we don't know the
total number of connections that are possible on a pipe or group of pipes.

A Concrete Connections Relationship

As you see from the data model in Figure 118, the "Connections" relationship definition is
"abstract", meaning that a tool does not really actually publish or retrieve it. Instead, a
"concrete" relationship is "derived from" the abstract relationship, and that is what tools
publish and retrieve.

End-1, End-2, Tap, or Fitting?

Just hold a real water pipe in your hand - it's "a connector." By inspection, you see a couple
of obvious places to form "a connection", that is, "end 1" and "end 2." But that's not the
only places that you can connect to that pipe! An instrumentation engineer may decide to
keep track of the pressure in that pipe, at a point 3 feet from "end 1." That place is going
to be drilled and tapped, and a thin pipe is going to be attached with some "kit", to the
active pipe and a pressure gauge will be attached to that. The pressure instrument will then
readout the fluid pressure at that point in the pipeline. The logical, not physical, point that
the instrument connects to, which is neither "end 1", nor "end 2", is called a "tap or fitting."
Can you see how that name fits with the idea of tapping into a pipe, or putting on a pressure
fitting?

Collaborations
Let's see how the SmartPlant Enterprise tools use the Connectivity Pattern to publish and
retrieve data:
1. At a high-level, for piping systems, the Connectivity Pattern can be used to hook one
pipe to another, and then publish those pipes, and the fact that they're hooked
together.
2. The Connectivity Pattern can be used to hook pipes to equipment nozzles.
3. It can be used to hook an instrument into a pipeline.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 144

Consequences
By separating the role of a pipe from the role of "where things can connect to the pipe", we
create a powerful model for integrating all the ways that different SmartPlant tools can

think about that problem. Q: "Hey, how can we hook up to this pipe?" says,
"At either end, or anywhere else!"

Implementation
Now, let's evolve the SmartPlant schema model in steps - like frames in a movie, which
started at Figure 118:

Figure 121 A Piping Connector is a Type of Connector

Figure 121 shows that a piping connector is a type of connector because InterfaceDef
IPipingConnector Implies InterfaceDef IConnector. You could have read that as one
subtype of connector is a piping connector - OK.

Figure 122 Three Relationships between Piping Connectors and Piping Connections

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 145

In Figure 122 you can see that a piping connection is a type of connection. Plus, you can see
that connections between "piping connectors" and "piping connections" are specializations of
the "Connections" relationship, and one of three types, based on where you are trying to
connect to, for example, a pipe:
- If you're going to connect at "end 1" use "PipingEnd1Conn"
- If at "end 2" use "PipingEnd2Conn"
- Anywhere else, along the pipe use "PipingTapOrFitting"

Figure 123 Connector Classes

Figure 123 shows a couple of classes that realize that they're piping connectors, and by the
transitive property of the Implies relation, namely, IPipingConnector Implies IConnector,
they realize that they are also connectors.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 146

 Figure 124 "Shared" Connector Classes

In Figure 125, you see that the point of showing a “SmartPlant P&ID" piping connector and a
"Smart 3D" pipe connector (in Figure 123) is that they both are "shared objects", meaning
that those two programs can update each other's data about connectors (as the design
evolves).

Figure 125 Classes that Realize That They Are Connections

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 147

 As far as connections go, Figure 125 shows that “SmartPlant P&ID" piping ports and "Smart
3D" pipe ports are shared objects that are both "piping connections" and "connections."

By now you probably understand that a pipe is a connector, and it has logical connection
points to be used for attaching something to it. But did you think of an electrical cable as a
connector? Sure, one end goes to a circuit-breaker and the other end goes to a wall
receptacle. OK. What about a wire, a conduit, a signal in a control system? OK. How about
any object? The simple solution is to see if the class realizes the IConnector interface. If
it does, then it is.

Participants
Figure 126, below, is an abbreviated diagram that shows classes that typically use the
"Connection Pattern."

Figure 126 Classes That Use "Connection Pattern"

Similar Patterns
Which SmartPlant Enterprise tools use the Connectivity Pattern? Most of them, including:
 SmartPlant Electrical
 Smart 3D
 SmartPlant P&ID
 Aspen Basic Engineering
 and so on

Anti-Patterns
N/A

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 148

Anti-Patterns
Referring to the Antipatterns. book in the Bibliography, William Brown decided that it was
not good to simply define "patterns", but great good can also be had by defining patterns
that fail, and he calls that "anti-patterns."

Wouldn't you agree that a "bully" is a good example of an "anti-pattern"? What about
preparation for, and response to, hurricanes Katrina and Rita in 2005? Were some of those
ideas probably "anti-patterns"? Do you agree that the loss of Space Shuttle Columbia, due
to launch during temperature conditions that were too cold for the O-rings to function
properly was an "anti-pattern"?

For each pattern, we tried to present (zero or more) relevant anti-patterns. "How do you
refactor for success?" should always be asked when a failure occurs.

Schema Ambiguity

The most common failure of schema development is ambiguity. warns, "It is

easy to publish any data in some convenient form. It is far more difficult to try to retrieve
the published data and make sense of it."

If you retrieve a document that has a "Motor" and an "Electric Motor", what are you
supposed to do? I don't know, either. See, it was easy for one tool to publish a motor and
it was easy for another tool to publish an electric motor, but pity the poor retriever.
Unfortunately, not all schema elements are unambiguous. In the name of expedience,
sometimes schema is "absorbed" from outside sources, without taking the time to do proper
analysis, and normalization. That causes problems downstream, but everyone reading this
book knows about the word "expedience."

Refactor: The best advice is doing it right the first time!

Improper or Weak Scoping of Properties

If the published data is declared to be all "strings" and "integers", then imagine how easy it
is to publish something! But if the data elements that are scoped by "string" really should
be scoped by an enumerated list, then strange data can appear in an input document. For
example, one tool might publish a value "RED", and another tool publishes "Red". What is a
retriever to do? I don't know, either.

Refactor: The best advice is to restrict using "string" to things that are "descriptions", and
to enumerate almost any other string-like properties.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 149

Relationship Parent
Relationships are between roles and are defined by RelDef. You can easily understand that
the role "Parent" is played with "Children", so you can understand that there is probably a
relationship definition that starts with "Parent" and ends with "Child". But there are lots of
"kinds of parents" and lots of "kinds of children" in schema-world. A "Pump" has some
"nozzles", and we can and should think of the "Pump" as being the parent of child nozzles.
The point is that common parent-child relationship semantics (behaviors) should be
inherited by anything that plays a "Parent" role, any time that it is playing that role with a
"Child". It is easy to forget to do this relationship normalization, but you really don't want
a totally separate relationship between a "Parent" role and a "Child" role, unless there is a
VERY good reason to do that.

Refactor: If you're creating a relationship definition, and either role already has a
relationship with another role, ask yourself if the new relationship could properly be a child
of the existing relationship.

To Normalize or Not to Normalize -- That is the Question

That's always a great question when the data modelers are shooting the breeze at the local
pub. There is no "right" answer. Sometimes you just "know" the answer, based on
experience. Other times, the coin lands on the edge, and it is impossible to justify the
normalize/denormalize decision. Best advice, look at a similar pattern in the schema. While
that's not always going to be right, it gives you a feeling of "best practice", which may help.

Here's an example: the properties name, address, city, state, ZIP, phone. Where do you
put them? Should you have an interface "IContactInformation" that has those properties?

Should you put them right on the "IManufacturer" interface instead? would
put them on "IContactInformation", because those properties can be tightly-bound and are
closely related to that role. However, over a beer and pizza, we can debate it further - HA!

Refactor: The schema is mostly designed to be 5NF, so a high degree of normalization is

OK.

My Anti-Patterns
Add your own anti-patterns here:
"...how to, for example, tie shoes..."

Refactor: (here's how to refactor those anti-patterns for success).

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 150

Bibliography

Recommended reading about "Patterns These are on 's bookshelf, so if you

want to be a Super Modeler, you might want to read them, too

Design Patterns: elements of reusable object-oriented software /

Erich Gamma ... [et al.].
cm. -- (Addison-Wesley professional computing series)
Includes bibliographical references and index.
ISBN 0-201-63361-2
Object-oriented programming (Computer science)
Computer software--Reusability
1994

Analysis patterns : reusable object models /

Martin Fowler
cm
Includes index
ISBN 0-201-89542-0
Object-oriented methods (Computer science)
1997

Applying UML and patterns : An introduction to object-oriented analysis and design / Craig
Larman
cm.
Includes index
ISBN 0-13-748880-7
Object-oriented methods (Computer science)
UML (Computer science)
System analysis
System design
1997

A System of patterns /
Frank Buschmann ... [et al.].
Includes bibliography and index
ISBN 0-471-95869-7
1996

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 151

Pattern Languages of program design (Vol 1., 2., 3.) /
edited by James O. Coplien, Douglas C. Schmidt
cm.
Includes bibliographical references and index
ISBN 0-201-60734-4
Computer software - Development
Object-oriented programming
1995

Antipatterns and Patterns in software configuration management /

William J. Brown ... [et al.].
cm. -- (John Wiley & Sons, Inc.)
Includes index.
ISBN 0-471-32929-0
1. Software configuration management
1999

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 152

Appendix A Schema Man!

HINT: You can print out this image of your favorite new Super Modeler "Schema Man!" and
his friends and make a mighty nice t-shirt transfer!

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 153

 IS THIS NORMAL?

Schema Man!
A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 154
Appendix B Images

Images from the web are credited here.

Bicycle picture
http://images.google.com/imgres?imgurl=http://www.hasslefreeclipart.com/clipart_transpo
rtation/bicycle.gif&imgrefurl=http://www.hasslefreeclipart.com/clipart_transportation/pag
e1.html&h=213&w=245&sz=13&tbnid=NPcyyqSeFzO2kM:&tbnh=91&tbnw=105&prev=/images
%3Fq%3Dbicycle&start=1&sa=X&oi=images&ct=image&cd=1

Nubian Wedding
http://upload.wikimedia.org/wikipedia/en/thumb/8/88/Egypt-Nubian_wedding.jpg/180px-
Egypt-Nubian_wedding.jpg

Compressor Spool
http://www.westmetalworks.com/images/dynamic/009.jpg

Washington Crosses the Delaware by Emmanuel Leutze

http://www.eyewitnesstohistory.com/images/washingtondelaware1.jpg

Cat Pumps Catalog

http://www.catpumps.com/pdfs/Catalogs/PumpCat.pdf

Pump Simulation
http://www.netl.doe.gov/publications/proceedings/01/vision21/v213-1.pdf

ANSI Pump Dimensions

http://www.mcnallyinstitute.com/Charts/ANSI_Dimensions_metric.html

Raven
http://images.google.com/images?q=tbn:nvQduJv1X5JEKM:www.jimhayes.com/photo/raven.j
pg

FDR
http://www.whitehouse.gov/kids/presidents/images/100-FDR1.jpg

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 155

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 Aspen Basic Engineering,
SmartPlant P&ID, SmartPlant Electrical, SmartPlant
Instrumentation, Smart 3D, and SmartPlant Foundation.
Cardinality It means "count", for example, a cardinality of "1" means that
exactly "1" of something should exist.
Class
A group of similar things. Classes specify an
object's attributes (data elements) and methods
(member functions). It generally represents a
real-world object, close to the concept of a
biological species.

ClassDef A SmartPlant schema element that defines a Class. A specification

of the low-level structure and behavior of some set of objects.
Component schema
A subdivision of the complete SmartPlant schema
that contains a set of class definitions that are
used within a specific domain or application area.
There is typically one component schema per
published document type.

Edge, EdgeDef
Single or multiple relationship definitions with
direction. In the schema, an edge definition is
used to traverse from a starting object to
related objects

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

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 156

Enumerated list A list of possible string property values defined for a property
(EnumListType) definition in the SmartPlant schema, also known as enumerated sets,
pick lists, code lists, and lookups
Enumerated value
(EnumEnum) A member of an enumerated set that defines one
possible value for a property in the SmartPlant
schema. Enumerated values are sometimes called
enumerated entries

Facility
(POSC) A business function or service provided by
equipment items and materials.

Graph, 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 An SmartPlant schema element that defines an Interface
Linnaean taxonomic model
A scientific way of classifying and naming living
things

Mapping A mechanism for software to convert authoring tool data, described

by the tool schema, to and from SPF data, described by the
SmartPlant schema. See Schema Mapping
Meta schema
A set of schema objects that describe the
objects in the SmartPlant schema. The meta
schema provides the building blocks upon which
the SmartPlant schema is built

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 157

Object An instance of a class, for example, 3.14159 is an instance of a
floating-point numeric type. An instance of class EQDPump will be a
tagged pump.
Occurrence
The fact of something existing, or how much of it
exists

Ordinality Numerically order something, for example, first, second, third...

Orthogonal
Having a set of mutually perpendicular axes;
meeting at right angles.

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

example, equipment {pumps, vessels, and so on}, then "part-ness" is
really the "type hierarchy" that discriminates the different types
of equipment.
Pattern Convention; something regarded as a normative example: a model
considered worthy of imitation
Plant breakdown structure
(PBS) The composition of the plant based on the
grouping of physical objects by their function in
the plant. The plant usually occupies the top level
of the hierarchy and is typically followed by
areas and units

POSC Caesar A European standards body, Petro technical Open Standards

Committee that is trying to make ISO 15926 a de facto standard
for the process industry, including oil & gas
Primary interface
Defines the set of possible roles for a ClassDef,
and should imply everything that is known about
the ClassDef.

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

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

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 158

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
that allow you to create, delete, or modify items at the appropriate
time in the design process.
Schema A diagrammatic representation, an outline, or a model.
ScopedBy
The relationship between “property definitions”
and “property types” in the SmartPlant schema.
The scoped by relationship specifies the property
type that defines acceptable values, or scopes, a
particular property definition. Every property
definition in the SmartPlant schema is scoped by
one and only one property type. All properties of
that property definition must be of that property
type.

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

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

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 159

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.

SmartPlant Enterprise
A suite of integrated engineering applications
delivered together.

SmartPlant The underlying software framework that allows SmartPlant

Foundation Enterprise tools to integrate. Provides database, rules, document
management, and so on.
SmartPlant integration
SmartPlant integration standardizes and improves
the communication among the various SmartPlant
Enterprise authoring tools used in the course of
designing, constructing, and operating a plant.
SmartPlant integration manages data exchange
among these authoring tools, which enables
sharing and re-use of plant information
throughout the plant lifecycle.

Taxonomy Wikipedia says "(from Greek verb tassein = "to classify" and nomos
= law, science) may refer to the science of classifying living things
a system of classification in some other field.

Taxonomies are frequently hierarchical in

structure. However, taxonomy may also refer to
relationship schemes other than hierarchies, such
as network structures."

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.
Typical material (POSC) Representative materials characterized by standard
identifiers and recommended, normal, or statistically
representative properties and compositions.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 160

UML Unified Modeling Language, a popular way of visually
expressing a schema.
Viewed
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.

Work breakdown structure The composition of the plant based on the construction work to be
(WBS) completed. The plant usually occupies the top level of the hierarchy;
it is typically followed by projects, contracts, and documents.
XML Extensible Markup Language; the format for all documents
published to SmartPlant Enterprise or retrieved from SmartPlant
Enterprise. These XML files must conform to the structure defined
by the SmartPlant schema.

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 161

Index
5NF, 150 PIDMechanicalEquipment, 115
abstract, 50 Sauropsida, 59
Abstract, 6 class factory, 43
Actual ClassDef, 16, 38, 43, 44, 45, 58, 61, 62, 63,
valve, 126 64, 66, 68, 70, 71, 72, 105, 156
EnumListLevelType, 81
Actual facility, 118
ClassToMapClass, 65
Actual material, 117, 119, 122
Collaborative engineering, 47, 60, 65, 74,
Actualized, 128 76, 77, 85, 111, 112, 113, 114, 115, 123,
Adapter, 70, 156 125
After-action Report (AAR), 6 Collection, 137
Anti-patterns, 6, 10, 149 COM, 65
Apollo 1, 50 Component schema, 38, 62, 63, 65, 66, 67,
Class Definition, 66, 71, 73 68, 70, 156
Class/Interface/Property Pattern, 78 ControlSystemComponent, 67, 69
Collection, 139 DimensionalDatasheetComponent, 67
Composition, 141 DocVersioningComponent, 67
Connectivity, 148 ELEComponent, 67
Edge Definition, 99 EQLComponent, 67
Graph Definition, 106 EquipDatasheet, 39
Interface Definition, 24 EquipDataSheet, 39, 67
NASA, 35 GenericDocumentComponent, 67
POSC/Caesar, 124 IMLComponent, 67
Property Definition, 28 InstrumentIndexComponent, 67
Property Type, 35 MetaSchema, 26, 67, 96
Relation, 50 P3DComponent, 67
Relation Definition, 57 PBSComponent, 67
Shared Object, 116 PFDComponent, 67
View Definition, 110 PIDComponent, 67
Anti-Patterns ProcessDataComponent, 67
Multi-level List, 90 WBSComponent, 67
API, ii Componentization, 38, 39, 65
BaseEnumListForEnumLevel, 80, 84 Composition, 5, 139
Booch, Grady, 4 Concrete, 6
Cardinality, 41, 138, 140, 156 Conditions, 48
minimum, 138, 139 Connection, 141
Class, 8, 156 flow direction, 143
DoubleType, 30 piping, 146
ELEInstrument, 48 Connector, 141
EQDCentrifugalPump, 114, 115 flow-direction, 142
EQDControlValve, 48 piping, 145
EQDVerticalCentrifugalPump, 114 Contains, 38, 39
InterfaceDef, 82
Correlation, 111, 116
Mammalia, 59
ModelDef, 71 crocodile, 59
PIDInlineInstrument, 47 Data normalization, 8, 25, 41, 42
PIDInstrument, 47, 60, 61 DefUID, 38
PIDMechanicalComponent, 114 Design Patterns, 5

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 162

 Adapter, 5 Primary Interface, 45
Composite, 5 Imply, 16
Façade, 5 Inheritance, 6
Factory Method, 4
Iterator, 5 Instance, 158
Mediator, 5 of a class, 58
Memento, 5 of a mammal, 58
Observer, 5 Instantiates, 43, 65
State, 5 Interface, 8, 42, 51, 157
Strategy, 5 Contains, 94
Template Method, 5 ICatalog, 135, 136
Directed graph, 100 IClassDef, 62, 113
IClassFactoryDef, 65
DocTypeClassDef, 65
ICoatedItem_Interior, 84
Document, ii, 1, 51, 53, 54, 57, 58, 63, 64, ICompSchema, 62
65, 77, 126, 138, 156 IConnection, 143
Edge, 91, 93, 96, 105 IConnector, 142, 145, 146, 148
PipingPort1, 95 IControlValve, 43
EdgeDef, 57, 85, 91, 93, 95, 96, 97, 101, IDirectedGraphDef, 103, 105, 110
102, 107, 156 IDocumentType, 62
Contains2, 85 IEdgeDef, 82, 94
Contains3, 85 IEnumEnum, 37, 40, 80, 81, 82
EnumEnum, 39, 86, 157 IEnumListLevelType, 80, 81, 82, 94
IEnumListType, 37, 40, 80, 81, 82, 94
Enumerated list, 8 IEnumMetadata, 40, 82
EnumListLevelType, 33, 80, 86, 87 IEnumMetdata, 40
EnumListType, 33, 39, 40, 86, 157 IEquipment, 131, 136
Coating requirement, 84 IEquipmentComponentOcc, 131
CoatingReq2, 84 IEquipmentOcc, 109, 131, 136
EnumMetadata, 40, 82, 83 IFluidTransferMachine, 43
Equipment, 131 IInterfaceDef, 62
equipment classification hierarchy, 32 IMammal, 74
IManufacturedItem, 127, 136
Equipment data sheet, 135 IManufacturer, 127
Expected facility, 118 IMappableClass, 62, 63
ExposedByInterfaceDefs, 41 IMfrModel, 135
Exposes, 16, 28, 41 IModel, 127
IModelDef, 62
Facility, 124, 157
INozzle, 40, 41
Facility model, 6, 44, 117, 118 INozzleOcc, 109
framework, 10 IObject, 74
Gamma, Erich, 4 IOrientedItem, 61
GetObjsbyGraphDefName, 104 IPart, 135, 136
IPartOcc, 135, 136
GraphDef, 100, 101, 105, 106, 107, 157
IPipingConnector, 145, 146
HasDefaultSI, 42 IPipingPort, 95
Hierarchy, 157 IPipingPortComposition, 95
IEdgeDef, 93 IPlannedMatl, 125, 135, 136
IMappableProperty, 27 IPositionCriteria, 94
Implies, 18, 22, 42, 43, 157 IPressureDropItem, 41, 43
IPropertyType, 81
hierarchy, 22
IPump, 16, 43, 82
IDaughter Implies IChild, 22
IReliefValveOcc, 130
IEnumListType Implies IEnumEnum, 40
IRotatingItem, 25
IMother Implies IParent, 22
ISharedObjDef, 62, 113
InterfaceDef Implies IEnumMetadata, 40
ISimpleCriteria, 94
ISon Implies IChild, 22

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 163

 ITypicalMatl, 125, 126, 135, 136 Multi-level enumerated value list, 35
IViewDef, 108 NASA, 35, 48
IWeight, 41
IWeightItem, 25 -ness suffix, 6
polymorphism, 14, 16 mammal-ness, 58, 59
Interface Pattern, 12 part-ness, 158
pump-ness, 13
InterfaceDef, 16, 40, 42, 57, 58, 61, 77,
role-ness, 43, 59
93, 96, 139, 140, 157 surface-coating-ness, 13
type of, 43 type-ness, 126
Interfaces valve-planned-material-ness, 130
expose properties, 41 valve-type-ness, 125
implied interface, 43 vehicle-ness, 52
implying interface, 43 Normalization
may Imply other Interfaces, 42 3NF, 13
properties exposed by, 42 5NF, 13
Intrinsic type, 29, 31, 34, 35, 64 third-normal form (3NF), 13
IObject, 16, 27 Normalize, 150
IPropertyDef, 27, 29 Nozzle, 40
IPropertyType, 29 Object, 47, 158
IPumpOcc, 18 Object expansion, 111
ISchemaObj, 27 Occurrence, 18, 121, 125, 126
Join, 108 Ordinality, 158
Linnaean taxonomic model, 6, 23, 157 Orthogonal, 158
loose integration, 6, 10, 34 P&ID, 38, 47, 48, 61, 66, 144, 147, 148, 156
MapClassToClass, 65 Part, 125
Mapping, ii, 27, 64, 157 Pattern, i, 4, 11
Material, 124 Basic, 9
books, 151
Material expansion, 114, 116 Business, 9
Material model, 6, 44, 117, 118 Class Definition Pattern, 58, 66, 71
meta schema, 6, 30, 38, 157 Class Diagram, 18
meta-pattern, 8, 9 Class/Interface/Property Pattern, 74
Collection Pattern, 137
metaschema, 36
Composition Pattern, 139
meta-schema, i, 1, 36 Connectivity Pattern, 141
meta-schema, 39 Edge Definition Pattern, 92
Model, 27 Graph Definition Pattern, 100
ActualMaterialModel, 44 Interface Definition Pattern, 12
FacilityModel, 44 Interface Pattern, 12, 18
MetaModel, 44 Mid-level, 9
OrganizationModel, 44 Multi-level List Pattern, 79, 85
PlannedMaterialModel, 44 Part vs. Occurrence Pattern, 125
TypicalMaterialModel, 44 pattern-space, 8
WorkBreakdownModel, 44 Property Definition Pattern, 24
Model definition, 71 Property Type Pattern, 28, 31
ActualMaterialModel, 71 Relation Definition Pattern, 51
FacilityModel, 71 Relation Pattern, 36
PlannedMaterialModel, 71 Shared Objects, Expansion and SameAs
TypicalMaterialModel, 71 Pattern, 111
WorkBreakdownModel, 71 Story of..., 4
ModelClass, 44, 65 View Definition Pattern, 108
ModelDef, 44, 72 Planned facility, 118, 120

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 164

Planned material, 65, 117, 119, 120, 125, Realizes, 16, 36, 46, 49
128, 130, 131, 135, 136 ScopedBy, 36, 49
Planned Material model, 47, 121, 128 Sharing, 36, 49
UoMConditions, 36, 49
Plant breakdown structure (PBS), 158 Relationhip
Polymorphic, 14 GraphDefInterfaceDef, 103
Polymorphism, 6, 16 Relationship, 8, 50, 157, 159
POSC/Caesar, 6, 44, 71, 123, 124 cardinality, 53
Pattern, 117 Componentization, 39
workflow, 119 delete propagation, 53
Position criteria, 101 DetailedProcessDesign, 123
practice, i, 2 EnumMetadata, 40
EquipmentNozzle, 102
Predicted facility, 118 MatlExpansion, 111, 115, 116, 123
Predicted material, 119 Mfr_Model_Catalog, 131
pressure conditions, 48 Mfr_Models, 127
Primary Interface, 44, 45, 65, 74, 158 MfrModel_Catalog, 135
PrimaryInterface, 44 OwnsImpliedItems, 136
Part_PartOcc, 135, 136
process, i, 2
PBSItemHasImpliedParts, 136
Procure, 121 PipingPortComposition, 95
Project, 108, 158 Planned_Actual, 123
Property, 8 PlannedFacility_PlannedMaterial, 124
CatalogName, 136 PlannedMatlActualization, 123, 129, 131,
Interior_CoatingRequirement, 84 135, 136
Interior_CoatingType, 84 PlannedProcurement, 123
PropertyDef, 16, 26, 27, 28, 35, 46, 58 Predicted_Required, 123
Procurement, 123
PropertyType, 46
Sharing, 113
Publish, i, ii, 1, 2, 27, 28, 29, 30, 31, 32, 33, Simulated_Predicted, 123
36, 41, 47, 48, 51, 53, 54, 57, 58, 63, 64, specialization of, 22
65, 67, 77, 126, 144, 156, 158 Typical_Required, 123
Realize, 45, 159 Relationship Definition
Realizes, 62, 65 Contains, 37
refactor, 6 EquipmentNozzle, 54
Refactor, 6, 24, 28 specialization, 55
Relationship Pattern
Rel, 38, 51, 54, 159
Realizes, 45
Relation
Contains, 82 RelDef, 36, 51, 54, 57, 58, 138, 150, 159
EdgeDefForEnumLevel, 94 BaseEnumListForEnumLevel, 81
EnumMetadata, 82 EdgeDefForEnumLevel, 82
SameAs, 111, 113, 114, 115, 116 EnumMetadata, 82
Relation Definition Required facility, 118
EquipmentComponents, 53 Required material, 119, 120
properties, 54 Retrieve, i, ii, 1, 2, 27, 28, 29, 31, 32, 33,
Relation Pattern, 36 41, 65, 77, 138, 144, 156, 159
Componentization, 36, 49 Reusability, 5
Contains, 36, 49
Role, 8, 157
EnumMetadata, 36, 49
Exposes, 36, 49 schema, 1
HasDefaultSI, 36, 49 Schema, i, ii, 1, 2, 8, 12, 17, 18, 25, 28, 32,
Implies, 36, 49 34, 58, 159, 161
Instantiates, 36, 49 component, ii
ModelClass, 36, 49 Editor, 34, 35
PrimaryInterface, 36, 49

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 165

 Elements, 9, 10, 20, 26, 27, 34, 36, 41, SP3D, 38, 66, 147, 148
49, 57, 64, 70, 72, 76, 85, 96, 106, 109, SPF, ii
115, 121, 139, 140, 144
evolution, ii Stereotype, 18
extending, i, 7 Tagged item, 20, 119, 121, 126, 131
objects, 36 Tool, 156
patterns, i, 1, 4, 5, 6, 9, 21 Transitivity, 18, 40
pattern-space, 8
Type hierarchy, 126, 129, 131
Tool, 160
Typical, 126, 135
Schema component, 77 pump, 126
Schema Component, 159 valve, 126
schema evolution, 49 Typical facility, 118
scope, 29 Typical material, 44, 117, 119, 120, 122,
scope of a property, 29 125, 128, 130, 131, 135, 136, 160
ScopedBy, 28, 46 Typical Material model, 127, 128
Scoping Unified Modeling Language (UML), 8, 161
Intrinsic types, 31 Unit of Measure, 8, 42
property, 34 base SI unit, 42
ScopedBy, 159 Unit of Measure list
Semantics, i, 159 Conditions, 48
Serial number, 71 Unit of Measure list Conditions
shared, 47 absolute, 50
Shared object, 111, 160 atmosphere, 48
SharedInstrument_PM, 47 gauge, 48, 50
Shared objects, 6 Units of measure, 35
UoMConditions, 48
SharedEquipment_PM, 114
UoMListType, 42, 48
SharedObjDef, 115
Valve, 2, 125, 126
Sharing, 47, 65
SharedInstrument_PM, 48 View, 108
SI unit, 42, 160 ViewDef, 108, 109, 110, 161
Simulated facility, 117, 118 WBS, 71
SmartPlant Enterprise, 1, 4, 5, 10, 16, 27, Weight
28, 29, 34, 38, 47, 48, 66, 144, 148, 160 dry, 41
wet, 41
SmartPlant Foundation, ii, 156, 158, 160
data model, i Work breakdown structure (WBS), 161
SmartPlant Integration, 160 XML, 161
SmartPlant schema, i, 6, 156, 157, 159, 160

A Gentle Introduction to SmartPlant Schema Patterns, Process, & Practice 166