How To Configure Classified Objects

SmartPlant Foundation
How to Configure Classified Objects
Version 2014 R3 (5.3)
April 2015
DSPF1-PE-200075G
Copyright
Copyright © 2008 - 2015 Intergraph® Corporation. All Rights Reserved. Intergraph is part of Hexagon.
Including software, file formats, and audiovisual displays; may be used pursuant to applicable software license agreement; contains
confidential and proprietary information of Intergraph and/or third parties which is protected by copyright law, trade secret law, and
international treaty, and may not be provided or otherwise made available without proper authorization 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 End User License Agreement ("EULA") 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 EULA 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. 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 EULA 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.
SmartPlant Foundation How to Configure Classified Objects 2

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 software products and any third-party Software Products obtained from Intergraph Corporation, its
subsidiaries, or distributors (including any Documentation, Other Documentation or technical data related to these products) are
subject to the export control laws and regulations of the United States. Diversion contrary to U.S. law is prohibited. These Software
Products, and the direct product thereof, must not be exported or re-exported, directly or indirectly (including via remote access)
under the following circumstances:
a. To Cuba, Iran, North Korea, Sudan, or Syria, or any national of these countries.
b. To any person or entity listed on any U.S. government denial list, including but not limited to, the U.S. Department of Commerce
Denied Persons, Entities, and Unverified Lists, http://www.bis.doc.gov/complianceandenforcement/liststocheck.htm, the U.S.
Department of Treasury Specially Designated Nationals List, http://www.treas.gov/offices/enforcement/ofac/, and the U.S.
Department of State Debarred List, http://www.pmddtc.state.gov/compliance/debar.html.
c. To any entity when Licensee knows, or has reason to know, the end use of the Software Product 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 Licensee knows, or has reason to know, that an illegal reshipment will take place.
e. Any questions regarding export or re-export of these Software Products should be addressed to Intergraph Corporation’s Export
Compliance Department, Huntsville, Alabama 35894, USA.
Trademarks
Intergraph, the Intergraph logo, Intergraph Smart, PDS, SmartPlant, SmartMarine, FrameWorks, I-Sketch, IntelliShip, ISOGEN,
SmartSketch, SPOOLGEN, SupportManager, SupportModeler, Sapphire, and FreeView are trademarks or registered trademarks of
Intergraph Corporation or its subsidiaries in the United States and other countries. 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.

Contents
Preface .......................................................................................................................................................... 6
SmartPlant Foundation Product Documentation .................................................................................... 6
Documentation Comments ..................................................................................................................... 7
What's New in How to Configure Classified Objects? ............................................................................. 8
Classified Objects Configuration ............................................................................................................... 9

Classification tree example use case ................................................................................................... 10
How to Configure Classification Trees and Classified Objects............................................................ 13

Configure the Engineering Numbering System (ENS).......................................................................... 13
Configure the ENS work process ................................................................................................... 13
Create a new ENS definition .......................................................................................................... 14
Create a new ENS item .................................................................................................................. 14
ENS item types ............................................................................................................................... 15
Manage the Engineering Numbering System................................................................................. 20
Create a new ENS relationship ...................................................................................................... 21
Configure alternative ENS definitions for a classification ............................................................... 22
Configure alternative ENS definitions for a configuration ............................................................... 22
Configure secondary ENS definitions ............................................................................................. 23
Configure the Hide ENS Multi Item Create option .......................................................................... 24
Configure a new classification tree ....................................................................................................... 25
Model the classification .................................................................................................................. 25
Creating the classification tree hierarchy ....................................................................................... 26
Configure homogeneous classifications ............................................................................................... 29
Add the classified item interface to the object ClassDef ................................................................ 29
Link the ClassDef to be created to the classification tree .............................................................. 29
Link the classified objects to the classification tree ........................................................................ 30
Configure the methods ................................................................................................................... 30
Set up the classified document forms ............................................................................................ 30
Restricting the classification tree node availability ......................................................................... 30
Configure heterogeneous classifications .............................................................................................. 31
Model the classified objects in the schema .................................................................................... 31
Configure alternative forms for a classification .............................................................................. 33
Configure classified documents ............................................................................................................ 33
Classified documents and forms .................................................................................................... 33
Expose classified objects and documents in the GUI .................................................................... 34
Document re-classification ............................................................................................................. 36
Configure unique identifiers .................................................................................................................. 37
Rename objects, UIDs, and unique keys ....................................................................................... 38
Classified Object Model ............................................................................................................................ 39

Core classification tree diagram ............................................................................................................ 39

Contents
ISPFObjClass interface .................................................................................................................. 40

SPFObjClassEnumEnum relationship definition ............................................................................ 40
SPFEnumEnumObjClass relationship definition ............................................................................ 40
SPFClassDefForm and SPFClassDefENSDef relationship definitions .......................................... 40
SPFClassMember relationship definition ....................................................................................... 41
IEnumEnum interface ..................................................................................................................... 41
IClassDef interface ......................................................................................................................... 41
Core classified object relationship model ............................................................................................. 41
Class items ..................................................................................................................................... 42
Relate class tree to Enum tree ....................................................................................................... 42
Core classified object diagram .............................................................................................................. 43
ISPFClassifiedItem interface .......................................................................................................... 44
SPFClassifiedLevel1-8 relDefs ....................................................................................................... 44
Document classification diagram .......................................................................................................... 44
ISPFDisplayOverride interface ....................................................................................................... 45
Classified design document diagram .................................................................................................... 46
SPFDesignDocMaster class ........................................................................................................... 47
ISPFDesignDocMaster interface .................................................................................................... 47
SPFClassifiedItem interface ........................................................................................................... 48
ISPFDocument interface ................................................................................................................ 48
SPFDocument class ....................................................................................................................... 48
ISPFDesignDocClass interface ...................................................................................................... 48
ISPFObjClass ................................................................................................................................. 48
SPFItemClasification relationship definition ................................................................................... 48
IEnumEnum .................................................................................................................................... 48
SPFEnumEnumObjClass and SPFObjClassEnumEnum relationship definitions.......................... 48
Classified vendor document diagram.................................................................................................... 49
ISPFClassifiedItem ......................................................................................................................... 50
SPFVendorDocClassVendorDocMaster ........................................................................................ 50
SPFDocClassVendorVersionClassDef (not shown on the diagram) ............................................. 50
SPFDocClassVendorMasterClassDef (not shown on the diagram) ............................................... 50
Design document classification model .................................................................................................. 50
Design document classification diagram ........................................................................................ 51
Engineering numbering system (ENS) diagram ............................................................................. 53
Summary of Delivered Classification Trees ........................................................................................... 54

Classification tree models ..................................................................................................................... 54
Index ........................................................................................................................................................... 56

Preface
This document details how to configure classified objects in SmartPlant® Foundation and is one
of a set of “How To” guides that describe how to configure the various components of
SmartPlant Foundation and the details of the underlying data model. It can be used as a training
guide to explore the configuration of the system and as a model reference document. This
document is intended for users who have used the SmartPlant Foundation Desktop Client and
have a good understanding of schema modeling techniques.
SmartPlant Foundation Product Documentation

SmartPlant Foundation documentation is available as Help and as PDF files. To view printable
guides for SmartPlant Foundation, click Help > Printable Guides in the software.
Intergraph gives its customers permission to print as many copies of the delivered PDF files as
they need for their non-commercial use. Do not print the PDF files for resale or redistribution.
Model Configuration Guides

 How to Configure the Authoring and Data Warehouse Models - Provides information for
system administrators on how to configure the authoring and data warehouse models in
SmartPlant Foundation and describes the underlying data model.
 How to Configure Classified Objects - Provides information for system administrators on
how to configure classified objects in SmartPlant Foundation and describes the underlying
data model.
 How to Configure the Consolidated Data Warehouse (CDW) - Provides information for
system administrators on how to configure the CDW in SmartPlant Foundation and
describes the underlying data model.
 How to Configure Concurrent Engineering - Provides information for system administrators
on how to configure concurrent engineering in SmartPlant Foundation and describes the
underlying data model.
 How to Configure the Data Sheet Model - Provides information for system administrators on
how to configure the data sheets model in SmartPlant Foundation and describes the
 How to Configure Document Management - Provides information for system administrators
on how to configure document management in SmartPlant Foundation and describes the
 How to Configure the GUI Model - Provides information for system administrators on how to
configure the graphical user interface (GUI) model in SmartPlant Foundation and describes
the underlying data model.
 How to Configure the Infrastructure Model - Provides information for system administrators
on how to configure the infrastructure model in SmartPlant Foundation and describes the
 How to Configure the Line List Model - Provides information for system administrators on
how to configure the line list application in SmartPlant Foundation and describes the

Preface
 How to Configure Performance - Provides information for system administrators on how to

enhance the performance of SmartPlant Foundation.
 How to Configure the Progress Model - Provides information for system administrators on
how to configure the progress model in SmartPlant Foundation and describes the underlying
data model.
 How to Configure Reports - Provides information for system administrators on how to
configure reporting in SmartPlant Foundation and describes the underlying data model.
 How to Configure the Security Model - Provides information for system administrators on
how to configure the security model in SmartPlant Foundation and describes the underlying
data model.
 How to Set Up and Configure SmartPlant Foundation - Provides information for system
administrators on how to set up and configure SmartPlant Foundation after install.
 How to Configure the Workflow Model - Provides information for system administrators on
how to configure the workflow model in SmartPlant Foundation and describes the underlying
data model.
Documentation Comments
Send documentation comments or suggestions to PPMdoc@intergraph.com
(mailto:ppmdoc@intergraph.com?subject=documentation comments).

What's New in How to Configure
Classified Objects?
If a SmartPlant Foundation release is not listed below, that release has fixes only and no
new features for this particular portion of the application. For a complete list of the new features
in a release, refer to the SmartPlant Foundation Core Functionality & Enterprise Integration
Capabilities Release Bulletin. For more information about fixes included in a release, see the
ReadMe file delivered with the SmartPlant Foundation setup.
Version 2014 R3
 You can now restrict the availability of classification tree nodes in the hierarchy tree when
using the Reclassify form. The ReclassifyObject client API has been updated so you can
choose to select an interface definition with which to filter the classifications. This behavior is
now consistent with the Create method. For more information, see Document
re-classification (on page 36). (CR-AM-68434)
Version 2014 R1
 Administrators can hide the Start at number and Number to create options when users
create objects with ENS to ensure that users cannot create multiple objects or override the
start sequence number. For more information, see Configure the Hide ENS Multi Item
Create option (on page 24).

SECTION 1
Classified Objects Configuration

Classified objects are those that have a typing hierarchy that is modeled in SmartPlant
Foundation as a classification tree. The classification tree consists of first class objects so that
they support relationship management and shortcut menus to the objects that they classify.
They can be configuration controlled, enabling different hierarchies in different configurations.
The classification tree is similar to that used in the Business Object model in SmartPlant
Foundation 3.x, but in SmartPlant Foundation 4.x (and later) it is also used to expose the
SmartPlant integration typing hierarchies. In the SmartPlant Schema, there are Enum typing
hierarchies for documents and tags, but this is a rigid structure that cannot be easily modified
and rearranged or sub selected for use in projects.
In SmartPlant Foundation, the Enum hierarchies are hidden behind, and related to, a
classification tree. The classification trees need a related Enum hierarchy only to support
SmartPlant integration because it is the Enum typing hierarchies that are used by the tools, but
they are still exposed as classification trees in SmartPlant Foundation for consistency and GUI
support.
Interactive business item creation and query is performed in SmartPlant Foundation using the
classification tree with the Enum typing set on the objects in the background. SmartPlant
integration still publishes documents and tags based on the Enum typing, and when the objects
are loaded into SmartPlant Foundation, relationships to the classification tree are created on the
fly. There are two separate relationships: one mapping from the classification tree to the Enum
hierarchy for interactive use and one mapping from the Enum hierarchy to the classification tree
for use by the publish process.
The following functionality can be configured by the classification tree:
 Different class definitions (ClassDefs) to create or query from each node.
 Alternative forms for these class definitions.
 Alternative ENS definitions for these class definitions.
 Object typing for SmartPlant integration via relationships to the Enum hierarchy.
Each classification tree can potentially classify many business items; for example, one
document classification tree can be used to classify many different document classes. Each tree
is usually composed of related objects of the same class definition, though that is not a
restriction.
There may be more than one family of objects that follow the same classification such as tags,
assets, models, and variants. To control the access to these different families of objects, each of
these families are configured using a specific relationship to the class definitions that need to be
created or queried within that family. Not every node of the tree needs these relationships
because this configuration is inherited down the tree. To identify a node of the tree as being
valid for a particular family, each family is usually represented by an optional interface on the
classification tree, and each node of the classification tree can then instantiate the relevant
interfaces. For example, some nodes may be valid for assets and others for assets, models, and
variants. The relevant class definitions for each member of the family are related to the node of
the tree, and this relationship is inherited down the tree.

When a family uses the same class definition on all nodes of the tree, then this relationship only
needs to be created at the top node, and the tree can be described as a Homogeneous tree as
is the case for the Design Document. When the family uses different class definitions at different
nodes of the tree, it can be described as Heterogeneous, which is the case for equipment with
different class definitions for pumps, vessels, and so forth.
Attached to the optional interfaces are various methods to create and query the relevant family
of objects. The methods reference the relationship path to the class definition used when the
object is created. The number of alternative class definitions that can be created from one
classification is therefore limitless.
For example, in the case of a catalog classification tree used to create both Model, Variant, and
Tag business items, there would be optional interfaces on the classification class definition for
each family with create and query methods attached. Optional interfaces are used because it is
not always valid to create all families from all nodes of a classification tree.
A business item can be classified by two different trees. For example, a primary tree could be
configured for the organization and separate classification trees for their vendors and
sub-contractors. When a business item is created within the structure of one classification tree, it
is automatically related to the alternative trees.
See Also
Configure a new classification tree (on page 25)
Classification tree example use case (on page 10)
Classification tree example use case

The table below shows an example classification tree and how it maps to the SmartPlant Enum
Tree. In this example, not all classification nodes are mapped to a SmartPlant Enum and not all
SmartPlant Enums are mapped to classification nodes. This is an example of a heterogeneous
tree that is used for SmartPlant integration and so demonstrates all the functionality of
classification trees. In this example:
 The classification tree does not contain the same number of levels as the SmartPlant Enum
tree. It is missing intermediate nodes between Equipment and Pumps and also the
subdivision of Centrifugal Pumps.
 Interactively, the user would only see a Pumps classification, and these would be typed as
Pump in the SmartPlant Schema.
 If a tool published a Horizontal centrifugal pump, then this would be related to the Pumps
classification as well.
 The text and brackets demonstrate how different shortcut menu commands are made
available for different business item class definitions from each node.

Classification Tree SmartPlant Enum Tree
[-] Tag Types [Query Models]

[Query Variants]
[Query Assets]
[-] Equipment [Query Models] Equipment

[Query Variants]
[Query Assets]
Process equipment
Material transfer equipment
Fluid-transfer machine
[-] Pumps [Query Models] Pump

[Query Variants]
[Query Assets]
[Create Model]
[Create Variant]
[-] Centrifugal Pump [Query Models] Centrifugal pump

[Query Variants]
[Query Assets]
[Create Model]
[Create Variant]
[Create Asset]
Horizontal centrifugal
pump
Vertical centrifugal
pump
[-] Valves [Query Models] Valves

[Query Variants]
[Query Assets]
[Create Model]
[Create Variant]

Classification Tree SmartPlant Enum Tree
Linear Valves
[-] Gate Valve [Query Models] GAT

[Query Variants] GATBL
[Query Assets] GATCON
[Create Model] GATEX
[Create Variant] GATF
[Create Asset] GATR
GATRASYM
GATSP

SECTION 2
How to Configure Classification Trees

and Classified Objects
For more information on how to configure classification trees and classified objects, see the
following topics.
 Configure the Engineering Numbering System (ENS) (on page 13)
 Configure a new classification tree (on page 25)
 Configure homogeneous classifications (on page 29)
 Configure heterogeneous classifications (on page 31)
 Configure classified documents (on page 33)
 Rename objects, UIDs, and unique keys (on page 38)
Configure the Engineering Numbering System (ENS)

The Engineering Numbering System (ENS) provides automated object identification, which
allows project-specific identification formats to be configured as templates. SmartPlant
Foundation uses these templates to guide the user when creating new objects.
The ENS definition is composed of various components called ENS items that can extract data
from constants and from other properties on the object or related objects. These components
are configured in sequence with additional delimiter characters to define the required format.
When bulk loading historical data using the Desktop Client Loader, you can override the
ENS functionality so that you can specify names for objects in the load files. For more
information, see SuppressENS in the How to Set Up and Configure SmartPlant Foundation
guide.
Configure the ENS work process

The overall work process of implementing ENS for an object consists of three smaller tasks, as
illustrated in the following diagram:

How to Configure Classification Trees and Classified Objects
What do you want to do?

 Create a new ENS definition (on page 14)
 Create a new ENS item (on page 14)
 Create a new ENS relationship (on page 21)
Create a new ENS definition

1. Click File > New > Administration > ENS Definition.
2. In the New ENS Definition dialog box, type a required Name, optional Description, and
select a Property set by ENS.
The Property set by ENS is the property of an object for which you want to set ENS.
The most common is Name.
3. Click Finish.
Create a new ENS item

1. In the Manage Engineering Numbering System dialog box, click Create.
This dialog box appears when you click Finish in the New ENS Definition dialog
box. You can also access this dialog box by right-clicking an ENS definition and clicking
Manage ENS Items.
2. Type a required Name, optional Description, and select an ENS Type to associate with the
ENS Definition on the New ENS Item dialog box.
An ENS item can be one of the following types:
 Constant - specifies a text value.
 Environment - specifies an environment value.
 Function - used for automatic sequence numbers.
 Property - specifies a property definition.
 Related Item - specifies a relationship definition. If identifying a relationship definition,
the name must be preceded by either + or -, which indicates the direction to traverse the
related item definition. The ENS edge definition UID box supports relationship
definitions only, not edge definitions.
Most of the options available for defining an ENS item are dependent on the
ENS type you have chosen for the item. See ENS item types (on page 15) for more
information about the options available for each ENS type.
3. Click Finish.

See Also
ENS item types (on page 15)
Configure the Engineering Numbering System (ENS) (on page 13)
Manage the Engineering Numbering System (on page 20)
ENS item types

Most of the options available for defining an ENS item are dependent on the ENS type you have
chosen for the item.
An ENS item can be one of the following types, and the available options are as follows:
Constant
This ENS type specifies a text value for the ENS item.
The options available for the Constant ENS type are:

ENS Unique Sequence Context - specifies that the sequence number used will be defined in
the context of the other items in the ENS definition.
ENS delimiter after - specifies the delimiter to add at the end of the item when the software
builds the ENS string. This is an optional field.
ENS constant - specifies constant values for the ENS item. This is a required field.
Environment
This ENS type specifies an environment value.
The options available for the Environment ENS type are:

 ENS Unique Sequence Context - specifies that the sequence number used will be defined
in the context of the other items in the ENS definition.

 ENS function - specifies the environment variable used to determine the value for this ENS
item. Possible values are:
 CurrentConfig - the name of the currently selected create configuration.
 CurrentQueryConfig - the name of the currently selected query configuration.
 PlantName - the name of the current plant.
 Username - the login name of the current user.
 PrimarySeqNo – allows the primary and secondary ENS definitions to be the same on
the item. For more information, see Configure secondary ENS definitions (on page 23).
 ENS pad justification- specifies the location of a pad sequence. Possible values for the
Environment item type are:
 Left - pad characters are placed on the left side of the item.
 None - no justification. If ENS Unique Sequence Context is not selected, the length of
the field is considered when the software determines the next sequence number, but the
value of the field is not. If ENS Unique Sequence Context is selected, then the
software uses the actual value to determine the next sequence number. This is the
default value.
 Right - pad characters are placed on the right side of the item.
 Variable - treats the ENS item as a variable length when determining the next sequence
number. This means that neither the value nor the length of the field is considered when
the software determines the next sequence number.
 ENS pad character - specifies value to pad sequences if all the spaces allotted by the ENS
field length option are not used.
When the software builds the ENS string, if there is no value for the selected
environment variable and you have selected a pad character, the resulting string is
composed entirely of pad characters. If you have selected an ENS pad justification value
of Left or Right but no pad character and the environment variable does not have a value,
then this field is ignored when the software builds the ENS string.
 ENS delimiter after - specifies the delimiter to add at the end of the item when the software
 ENS field length - specifies the length of the ENS item. If the value of the field is longer
than the specified length, the value is truncated. This is a required field.

Function
This ENS type is used for automatic sequence numbers.
The options available for the Function ENS type are:

 ENS function - the only value available for this field is Sequence. Sequence defines the
sequence of numbers to follow the ENS sequence start number.
 ENS field length - specifies the length of the ENS item. This is a required field. If the value
of the field is longer than the specified length, the value is truncated.
 ENS fill gaps - specifies whether or not the software fills gaps left in the sequence if
numbers are skipped. For example, if you create four items, starting with 20, the software
will provide 20, 21, 22, and 24 if 23 is already used. If the starting number is not available
and this property is set to True, the software displays an error message. If the property is set
to False, the whole range of numbers must be available to create the item. For more
information, see Fill ENS gaps (on page 20).
 ENS pad justification - specifies the location of a pad sequence. Possible values for the
Function item type are:
 Left - pad characters are placed on the left side of the item. If you select this value, you
must also type a value for ENS pad character.
 None - no justification. This is the default value.
field length option are not used. If you select Left for the ENS pad justification value, this
field is required. This field is only used for an ENS pad justification value of Left.
 ENS sequence start number - specifies the sequence start number for an ENS function
sequence item. This is an optional field.
 The default ENS function sequence start number is set to 1. To start an ENS sequence
beginning with the number 0 (zero), type -1 in the ENS sequence start number field.
 You can hide the ENS sequence Start at number and Number to create fields on a
create form to prevent users creating multiple objects or overriding the start sequence

number. For more information, see Configure the Hide ENS Multi Item Create option (on
page 24).
Property
This ENS type specifies a property definition.
The options available for the Property ENS type are:

 ENS Unique Sequence Context - specifies that the sequence number used will be defined
in the context of the other items in the ENS definition.
Property item type are:
default value.
When the software builds the ENS string, if there is no value for the selected property
and you have selected a pad character, the resulting string is composed entirely of pad
characters. If you have selected an ENS pad justification value of Left or Right but no pad
character and the property does not have a property value, then this field is ignored when
the software builds the ENS string.
 ENS property definition UID - specifies the name of the property used for the ENS item.
This is a required field.

Related item
This ENS type specifies a relationship definition or an edge definition.
The options available for the Related Item ENS type are:
 ENS edge definition UID - specifies the UID for an edge definition or a relationship
definition. If identifying a relationship definition, the name must be preceded by either + or -,
which indicates the direction to traverse the related item definition. If identifying an edge
definition, the name must be preceded by EDG_.
Property item type are:
default value.
When the software builds the ENS string, if there is no value for the selected property
and you have selected a pad character, the resulting string is composed entirely of pad
characters. If you have selected an ENS pad justification value of Left or Right but no pad
character and the property does not have a property value, then this field is ignored when
the software builds the ENS string.
 ENS property definition UID - specifies the name of the property used for the ENS item.
This is a required field.

Fill ENS gaps

The most common use for an ENS definition is to generate a unique name for a new object.
Usually the ENS definition contains an ENS item of type function sequence. The sequence is
incremented each time a new object is created. However, users can override the sequence
generation by specifying a sequence number directly on the form.
Users can also generate a range of items based on the Number to define field. For example, if
you specify a starting number of 20 and specify four items, the software allocates 20, 21, 22 and
23. If the starting number and the range are not available, the software displays an error
message.
Specifying a manual sequence number can create gaps in the sequence. For example, if you
generated the sequence above and the last auto-generated number was 18, there would be a
gap where 19 was not being used.
To make the handling of gaps configurable, a property on the ENS item called FillGaps allows
you to specify whether the software allows gaps or fills them. If this property is set to True, gaps
are filled, and the software supplies the next available numbers in the range. For example, if you
create four items, starting with 20, the software will provide 20, 21, 22, and 24 if 23 is already
used. If the starting number is not available and this property is set to True, the software
displays an error message. If the property is set to False, the whole range of numbers must be
available to create the item.
The default ENS sequence start number is set to 1. To start an ENS sequence start
number to beginning with the number 0 (zero), type -1 in the ENS sequence start number field.
Manage the Engineering Numbering System

You can manage, create, update, remove, and filter the relationships among ENS definitions
and items.
1. Right-click an ENS definition.
2. Click Manage Engineering Numbering System.
3. In the Manage Engineering Numbering System dialog box, select an item and click
to relate the item to the ENS definition.
If the dialog box is in portrait orientation, the Library pane appears at the bottom of
the dialog box instead of on the right side of the dialog box. Click Relate Selected Item
in the Library pane to relate the item to the ENS definition.

You can also edit properties of the ENS items in the table on the left side of the dialog
box. See ENS item types (on page 15) for more information about the available options for
each ENS item type.

4. Click OK.
 Click and to order the objects of the ENS definitions.

 Click Create to create a new ENS item.
 Click Remove Selected Item to remove the relationship between an item and a
definition. The item remains in the database.
See Also
ENS item types (on page 15)
Create a new ENS item (on page 14)
Create a new ENS relationship

Apply ENS to an object by relating the class definition of the object to an ENS definition.
1. Click Find > Schema > Class Definition.
2. Type the criteria to find and display the class definition that will contain the ENS. Click OK.
3. Drag the ENS Definition onto the Class Definition.
4. In the New Relationship text box, click OK to create the new ENS relationship.
Multiple ENS definitions on the same class definition can be configured using
secondary ENS definitions. For more information, see Configure secondary ENS definitions
(on page 23).
See Also

Configure alternative ENS definitions for a classification

Starting with:
Copy ENS 1 and modify and relate to the class definition.
Now relate the ENS to the relevant node of the tree.
See Also
Configure alternative ENS definitions for a configuration

An ENS definition can be related to ClassDefs, classifications, and also configuration items.
In the case of classification and configuration, the software navigates the respective trees
looking for the most specialized ENS definition. In the case of configuration, the software starts
at the current create configuration, and if it does not find an ENS definition at this level, it
navigates up the tree to configuration top until it finds one.
The following order of preference is used to determine which ENS definition to use. In all the
following cases, the system first retrieves ENS definitions related to the ClassDef of the object.
1. First, search for an ENS definition with a matching classification and configuration or one
higher up the tree; that is, if the object is classified and in a configuration, look for an ENS
definition with both a relevant classification and configuration related.
2. If the object is classified, the classification takes preference over the configuration; that is,
an ENS definition with a matching classification and no configuration (applicable for any
configuration) takes preference over one with a matching configuration and no classification.
3. If the object is not classified, search for an ENS definition with a matching configuration.
4. Finally, search for an ENS definition with no configuration and no classification.
There is a drag-and-drop condition (IsObj1SPFPlantOrConfigTop) on the configuration
item to ENS definition relationship definition (SPFConfigurationItemENSDef) that only allows an
ENS definition to be related to a plant. The reason this restriction is in place is because if an
ENS definition was allowed to be related at both project and plant level, then there could

potentially be a problem when merging: If different ENS definitions are used at the project level
and the plant level, then the object would need to be renamed on merge, which isn’t allowed.
However, it is valid for a customer to add a configuration level above plant, for example, site; in
this case, the condition (IsObj1SPFPlantOrConfigTop) would need to be updated to support this.
Configure secondary ENS definitions

Secondary ENS definitions allow two properties on an object to be set via ENS, for example,
Name and Internal/External Name.
A primary ENSDef can have one or many secondary ENSDefs related to it. The secondary
ENSDefs must be related to different properties. Also, the secondary ENSDefs cannot be
related to a ClassDef because, when the software generates the next sequence number, it
queries the database and filters on the ClassDef related to the primary interface.
On creation of the relationship between two ENSDefs, there is validation that ensures that the
ENSDefs don’t reference the same property and that any secondary ENSDefs don’t have a
related ClassDef.
The system administrator role has permissions to create a relationship between two ENSDefs
by dragging a secondary ENSDef onto a primary one. Expansion can be done both ways using
the shortcut menu options. The Manage Secondary Engineering Number Systems command
on the primary ENSDef manages the relationships between ENSDefs.
Any property that is the target of a secondary ENSDef should either be excluded
from the create form or made read-only.
Manual sequence numbers

On the create form, the user can specify a manual sequence number for any new object, giving
users the ability to create a range of objects using the number of copies as well. Manual
sequence numbers can only be used on the primary ENSDefs. If any secondary ENSDef needs
to use the same sequence number as the primary ENSDef, an environment option on the
ENSItem called PrimarySeqNo allows the sequence numbers to be the same.
See Also

Configure the Hide ENS Multi Item Create option

When you create a new ENS definition, you can override the inclusion of the ENS sequence
Start at number and the Number to create options on the create form to ensure users cannot
create multiple objects or override the start sequence number.
To hide the options, select the Hide ENS Multi Item Create check box on the create form.
When you create a new ENS defined object, the Number to create and Start at number fields
do not appear at the bottom of the object create form.
 The Hide ENS Multi Item Create check box appears on all new create and generate forms
used to create or modify objects, even if the object created is not configured for ENS. By
selecting the Hide ENS Multi Item Create check box, the SPFHideENSCreateOptions
property is set to True, so the ENS fields do not appear on the create form.
 The SPFHideENSCreateOptions property is part of the standard database, however, if the
Hide ENS Multi Item Create check box does not appear on the create form, you can add
the property by finding the class definition for the SPF Form object and adding the property
to the class definition.

Configure a new classification tree

See the following topics for more information on configuring a new classification tree.
 Model the classification (on page 25)
 Creating the classification tree hierarchy (on page 26)
Model the classification

Use the Schema Editor to model classification trees to describe the breakdown of documents,
tags, assets and, so on in the system in terms of the customer's structure or their client’s
structure. For more information, see the Schema Editing section in the How to Set Up and
Configure SmartPlant Foundation guide.
The classification tree is created as a hierarchy of related objects with optional interfaces
instantiated to manage the creation and query of classified objects. The classification trees are
modeled with the following interfaces as described in the Classified Object Model section:
 Primary Interface (required) for example, IMyEquipClass.
 ISPFObjClass (required) defines this as a classification object.
 ISPFSubscribableItem (required) to support user subscription to the class trees. If this is not
needed, then this interface does not need to be realized.
 ISPFDisplayOverride (optional). If this is not needed, then this interface does not need to be
realized.
 Optional Interface 1, 2… to control specific node functionality.
It is not always applicable to have all the create and query methods available from all nodes of
the tree, particularly the top node. This is the reason for the optional interfaces.
The optional interfaces will have the client methods and also the relationships to the ClassDefs
to create. If more than one family of objects is to be managed by the tree, it must use more than
one optional interface.
The Unique Key needs to include the occurrence property if the tree is to support more than one
node with the same name:
Unique Key = Prefix,Name,SPFClassificationOccurrence
Example unique keys for the classification ClassDefs:
 For regular classifications, use:
SPFIsConfigurationControlled="False"
SPFUIDDef="DC,Name,SPFClassificationOccurrence"
 If uniqueness is to be enforced in the whole tree, then the key is simply:
SPFUIDDef="DC,Name"
How the ClassDefs are created and are configured to the tree is described in the How to
Configure Classified Objects section.

Making the classification tree configuration controlled

To make the classification tree support different structures in different configurations, such as
Plants, the class definition has to be configured with IsConfigurationControlled = True.
Classifications created at one configuration will be available in lower configurations.
If the same classification is to be configured in more than one configuration, make sure the key
includes the configuration. It is also worth putting a prefix in the key.
Unique Key = Prefix,CurrentConfig,Name,
For configuration-dependent classifications, use:
SPFIsConfigurationControlled="True"
SPFUIDDef="DC,Name,CurrentConfig, SPFClassificationOccurance"
Because the classification tree is not to be claimed or merged, it does not need any of
the concurrent engineering interfaces. However, if a classification created at the Plant has to be
hidden from the project, then the claim interfaces will have to be added so that the classification
can be claimed into the project and terminated. However, this is not a common requirement.
Make the classification tree SmartPlant integration compatible

You must relate the classification tree to a SmartPlant integration Enum hierarchy.
See Relate class tree to Enum tree (on page 42).
Creating the classification tree hierarchy

As already noted, not all classification trees need to have related Enum hierarchies, only those
that are used for SmartPlant integration. When they are to be used for SmartPlant integration,
there is a simple utility in the Desktop Client called the Generate Class Tree Wizard used to
generate all of the branches of the tree from the Enum hierarchy.
Automatic creation of a classification tree from a SmartPlant

enum hierarchy
Generate Class Tree is available as a shortcut menu command on an enum. This creates a
load file containing a classification structure matching the enum hierarchy selected. The user
identifies the class definition for the classification objects, and the load file contains all the
classification objects and the relationships to the known hierarchy. This load file can then be
loaded into SmartPlant Foundation, and the tree can be either related to an existing tree or used
as a complete tree.
1. To generate a class tree, right-click the enum, and click Generate Class Tree on the
shortcut menu. The Generate Class Tree Wizard is displayed.
2. Select the classification ClassDef to create, and click Next.
3. Select the Optional Interfaces.
The optional interfaces will be instantiated on all nodes of the tree generated by the
wizard. These can be edited in the generated load file or after loading into SmartPlant
Foundation using the Add Optional Interface shortcut menu command.

4. Click Finish, and enter the load file name.

5. Click Save to generate the load file.
The structure must then be loaded using the SmartPlant Foundation Loader. Next, drag the
sub-tree onto an existing tree. If this is a completely new tree, it must be exposed in the client.
For more information, see Exposing the classification tree in the client (on page 28).
Running reports on the classification trees

Run the Class Tree View ad hoc report to view all or part of a classification tree and its
mappings. Alternatively, simply perform a query for the classification tree objects of Enums to
view them in a list view with the relevant column items. A shortcut menu command is available
to display them in a tree-list view for managing these relationships as described below.
Importing a classification tree from load files

A classification tree created from the Enum hierarchy or by hand can be loaded using the
SmartPlant Foundation Loader. If the tree is to be configuration controlled, make sure the
relevant create configuration is selected before loading the file.
Here is a sample classification load file for a Document Classification. Note the relationship to
the parent classification and to the related Enum (only needed for SmartPlant integration
compatibility). The _1 is a way to ensure that the items are unique.
Note that the relationship to the Enums is only needed for SmartPlant integration.
Creating the classification tree interactively

Though not configured in the delivered model, it is easy to set up a shortcut menu command to
create sub-nodes of a classification tree. Terminate relationships is available on any node in the
delivered model.
Each classification tree would need its own shortcut menu command to create and relate a
sub-node of the correct class definition and with the correct relationship. Use the following client
API with the following arguments:
Client API: CreateObjAndRel
Argument 1: Class definition to create, for example, SPFDocumentClass
Argument 2: Relationship definition to object = SPFClassMember

Note that the create form would need to be modified to expose any optional interfaces that need
to be created.
Managing the classification tree – Enum mapping

Expand the tree in the tree view or search for the classification structure to be configured.
Right-clicking Manage Classification Tree expands the classification tree structure to a tree-list
view to display a classification tree with a column set showing the related Enums, forms, and so
forth.
The tree can be expanded and navigated, and these relationships can be changed through drag
and drop. Note the two columns for the two different Classification-Enum relationships. The To
Enum is the one used to determine the typing based on the selected classification during
Interactive create, and the From Enum is the one used to determine the classification from the
typing during publish.
Also from an Enum or EnumList, the shortcut menu command Manage Enum Hierarchy
expands the Enum structure to a tree-list view to display the hierarchy with a column set
showing the related classifications.
It is then easy to drag and drop between the two views.
Exposing the classification tree in the client

Use the Load Object method and a drill-down item; see the How to Configure the GUI Model
guide for details. Note the reload flag on the method.
A configuration-controlled tree will need a configuration independent top node.
When exposing the classification tree in the tree view:
1. Use the LoadObject client API with the following parameters:
Interface name to search = interface on the Classification class definition, for example,
ISPFDocumentClass
Object name or UID = Name or UID of classification object to retrieve, for example,
DC_Document_category_1 (UID will ensure we find the correct one.)
ReloadOnCreateConfigLevel1Change = False – set to True for configuration dependent
classification trees.
ReloadOnQueryConfigChange = False
2. Create a DrillDown item, and relate the method to it.
3. Relate the VIEWONLY access group to the method.

Configure homogeneous classifications

Object create and query methods can be configured to create or query a single object ClassDef
from all classification tree nodes. For example, Create Design Document might always create
the same document ClassDef for all nodes of the tree.
Add the classified item interface to the object ClassDef

All classified objects and document masters must realize the ISPFClassifiedItem interface. Use
Schema Editor to ensure that this is a required realize relationship. For example:
CSTDocumentMaster must realize (required) ISPFClassifiedItem.
This provides the relationships to link the classified item to the class tree and to store the parent
classification levels for ease of searching.
Link the ClassDef to be created to the classification tree

In the future, this will only be necessary for trees that manage multiple ClassDefs.
The SPFObjClassClassDef is an abstract RelDef between ISPFObjClass on all classification
tree objects and IClassDef. It is necessary to create specializations of this to link each family of
ClassDefs to the tree. In our case, we only have one ClassDef (CSTDocVersion) to link to the
tree. Use Schema Editor to create this relationship (there is one restriction: Schema Editor will
not allow you to create this RelDef to an interface that is not in the current writable schema – so
either do this by copy and paste of an example, or create the RelDef to an interface that is in
your writable schema and then edit the schema file afterwards).
For example, create the following RelDef:
Name: CSTDocClassClassDef
Specialization of: SPFObjClassClassDef
Interface1: ISPFDocumentClass (use ICSTDocVersion and edit later)
Role1: CustomDocClassication
Role1 Display As: Custom Document Classification
Cardinality 1: 0,*
Interface2: IClassDef (type this into schema editor)
Role2: CustomDocClassDef
Role2 Display As: Custom Document ClassDef **
Cardinality 2: 0,1
This is important so that when dropping the ClassDef on the nodes of the tree, we
can see which relationship is being created.
When the schema has been loaded, enable navigation, drag and drop (in direction 21), and
terminate for this RelDef for an Access Group such as SystemAdmin.
When the RelDef access has been configured, query for the ClassDef (CSTDocVersion) that is
to be related to the tree, and drop it onto the top Document category node. Note that when
relating document classes, it is the version ClassDef that is related.

Link the classified objects to the classification tree

The navigation from the tree node to the classified objects and documents is available via the
SPFPrimaryClassification. If specific shortcut menu navigation is required (for example, to
Custom Documents), EdgeDefs can be configured to navigate to specific objects using the valid
end interface such as ICSTDocMaster.
Configure the methods

The CreateObj client API is used to create a non-classified object from a menu. Use
CreateClassObj to create the classified objects from the menu and CreateClassObjFromClass
to create the classified object from the shortcut menu of the class tree. Similar client APIs are
available for query.
For example, create a pull-down menu method with the following details:
Name: CSTCreateCustomDoc
Client API: CreateClassObj
RelDef: CSTDocClassClassDef
Allow Drilldown: True
Top Node: DC_Document_category_1 (actually UID)
Filtering: ISPFDesignDocClass **
Title: Custom Documents
File Attachment: SPFDesignFile~SPFFileComposition~PROMPT
 Note that this restricts the availability of classification tree nodes as described below. In this
case, ISPFDesignDocClass is used to ignore Template and System document nodes.
 To create a shortcut menu method, use the CreateClassObjFromClass client API, and relate
the method to the relevant class tree interface.
Set up the classified document forms

Non-classified documents use the NonClassifiedDocumentMaster form section to expose the
enumerated typing properties. This is not needed for Classified Documents, so remove this form
section and add the DocumentMaster form section instead.
Restricting the classification tree node availability

You can restrict the availability of classification tree nodes using optional interfaces.
The shortcut menu methods are related to the optional interfaces so that they are only available
for the relevant classification tree nodes. For example, not all tree nodes are valid for design
documents, so the Create Design Document method is configured on the ISPFDesignDocClass
interface.
Pull-down methods are not directly linked to interfaces so the create and query methods for
classified objects have an argument in which one or more (separated by ~) InterfaceDefs can be
specified to filter the tree that is displayed in the wizard.

Configure heterogeneous classifications

This is where the object create and query methods need to be able to create and query different
object ClassDefs from different nodes of the classification tree. For example, Create Equipment
Asset might create different ClassDefs for pumps, valves, vessels, and so forth.
Model the classified objects in the schema

For more information on modeling the classified objects in the schema, see the following topics.
 Required ClassDef schema model (on page 31)
 Link the class definition to the classification tree (on page 31)
 Link the classified objects to the classification tree (on page 30)
 Configure the methods (on page 32)
 Set up the classified document forms (on page 32)
 Restricting the classification tree node availability (on page 32)
Required ClassDef schema model

All classified objects must realize the ISPFClassifiedItem interface. Ensure that this is a required
realize relationship.
Link the class definition to the classification tree

Once the classification tree has been modeled, you must set the ClassDefs that will be
managed by this tree. The tree can manage multiple families, for example, an Asset Model and
variant. Each family can use different ClassDefs to represent objects from different nodes of the
tree, which is why a specialized Relationship Definition has to be configured.
The classification tree objects would be created with different optional interfaces to control the
availability of the methods and relationships:
 ICSTAssetClassification
 ICSTModelClassification
 ICSTVariantClassification
The core functionality provides the relationships between the classification tree and the
classified objects. However, it may be necessary to configure separate shortcut menu expansion
options to each class. To do this, configure an EdgeDef:
 Starting Interface: ICSTAssetClassification
 Path: SPFPrimaryClassification
 End Interface: ICSTAsset (to only show assets)
Similarly for the Model and Variant.
This cannot be done in the Schema Editor; therefore, copy and paste from a core
schema (search for SPFObjClassClassDef in the files).

Then relate the relevant Asset ClassDefs to the different nodes of the classification tree. See the
delivered Equipment Class tree as an example.
Now that the classification tree has been linked to the ClassDefs that it manages, create the
Relationship Definitions to instantiate objects, that is, the Relationship Definition that will link the
equipment to the tree.
Even if the tree is managing more than one family, a single Relationship Definition could be
configured if there is a common interface on all the ClassDefs in the different families. For
example, a Relationship Definition between ImyEquipClass and ImyEquipment. (This
Relationship Definition will be a specialization of SPFPrimaryClassification.) This would give just
one shortcut menu expansion, such as 37, on the class tree.
For individual relationship expansions, create separate Relationship Definitions between
ImyAssetClass and ImyAssetEquipment.
If a second classification tree (for example, Vendors) is to be configured to classify the same
objects, then this second tree has to be related with a Relationship Definition, that is, a
specialization of SPFItemClassification because only one tree can be related by
SPFPrimaryClassification.
Link the classified objects to the classification tree

This is exactly as for the Homogeneous tree described above. For more information, see Link
the classified objects to the classification tree (on page 30).
Configure the methods

This is exactly as for the Homogeneous tree described above. For more information, see
Configure the methods (on page 30).
Set up the classified document forms

This is exactly as for the Homogeneous tree described above. For more information, see Set up
the classified document forms (on page 30).
Restricting the classification tree node availability

This is exactly as for the Homogeneous tree described above. For more information, see
Restricting the classification tree node availability (on page 30).

Configure alternative forms for a classification

Starting with:
Copy form 1 and modify and relate to the ClassDef.
Now relate the form to the relevant node of the tree.
Configure classified documents

Because of their complex nature, the process of configuring custom classifications for
documents is more involved than that of creating classifications for simple objects. The following
sections provide information about how to create and use custom document classifications.
Classified documents and forms

Classified documents do not need to expose the typing properties at create time so the
DocumentMaster form section is used instead of the NonClassifiedDocumentMaster section.
It is possible to configure different forms for different classifications of the same document. The
default form is related to the ClassDef just like for the basic document described above.
Additional forms can be configured and related to different nodes of the classification tree to
expose different sets of properties, perhaps on different optional interfaces.
When creating or querying for a classified document, the system starts and the selected
classification tree node and works up until it finds a form related to the classification and the
ClassDef. If none is found, it uses the default one on the ClassDef.

Expose classified objects and documents in the GUI

Classified objects can be created and queried from either the menus or via the classification
tree.
The table below details the API used for creating classified objects from the pull-down menu.
Arguments 1 to 10 are listed. For more details and examples, refer to the delivered model.
CreateClassObj
1. RelDef to navigate to the ClassDef RelDef to navigate to the ClassDef. Used to

derive the ClassDef to create from the
classification object.
2. Allow classification tree drilldown To allow / prevent the user from drilling further
down the tree. If this is false, then the
classification selection page of the wizard is
skipped.
3. UID of classification Classification tree node to display in the

classification selection page of the wizard. If no
sub classifications exist, the wizard skips this
first page.
4. Classification tree filtering A ~ separated list of interfaces to perform

classification tree filtering (optional).
5. Title Title for the create forms.
6. File attachment configuration File attachment configuration (optional)

FileClassDef~FileRelDef~ReferenceAction
(SPFFileComposition is the default RelDef if
none specified)
7. Details of secondary class Details of secondary class to create and its

relationship to parent ClassDef (arg1) (~
separator).
8. Workflow processing option Workflow processing option. Options are

Select, SelectRequired, or a named workflow.
9. Not used
10. Post method name Post method name. Will run this method on the
new object. For complex objects, add
~InterfaceDefUID to identify the object on
which it is run.
Note that argument 4 can be used to restrict which classification nodes are available for
selection based on the presence of optional interfaces.
The following additional create client APIs are available, but since most of the arguments are the
same, only the differences are mentioned here.

CreateClassObjAndRel
This is used to configure a shortcut menu method on an object to create a classified object and
relate it to the selected object. There is an additional argument to define the RelDef to use to
relate the new classified object to the selected object.
CreateClassObjFromClass
This is used to configure a shortcut menu method on the classification tree nodes to create
classified objects. The arguments are exactly the same as for CreateClassObj except that
argument 3 is not used.
QueryClassObj
1. RelDef to navigate to the RelDef to navigate to the ClassDef. Used to

ClassDef derive the ClassDef to create from the
classification object.
2. Allow classification tree drilldown To allow/prevent the user from drilling further
down the tree. If this is false, then the
classification selection page of the wizard is
skipped.
3. UID of classification Classification tree node to display in the

classification selection page of the wizard. If no
sub classifications exist, the wizard skips this first
page.
4. Not used
5. Primary interface override Override InterfaceDef used in queries that

replaces PrimaryIDef.
6. Column set to present results Name of the column set to present results.
7. Not used
8. Query filter - Property Standard property comparisons apply to all

comparison queries.
9. Configuration Behavior Values

NullConfigQuery/IgnoreConfigFilter/Blank.
NullConfigQuery: queries once for null config
objects, IgnoreConfigFilter: always queries
selected configurations AND their parent
configurations, Blank: queries with regular
configuration filtering.
10. Classification tree filtering A ~ separated list of interfaces to perform

classification tree filtering (optional).
Note that argument 9 controls the way in which the query is performed with respect to
concurrent engineering. If querying for configuration independent data, then this argument is
usually set to NullConfigQuery. If querying for configuration dependent documents, then this is

usually set to IgnoreConfigFilter so that the user sees the document in the selected query
configurations and above.
QueryClassObjFromClass
This is used to configure a shortcut menu method on the classification tree nodes to create
classified objects. The arguments are exactly the same as for QueryClassObj except that
argument 3 is not used.
Document re-classification
Methods can be configured to re-classify any classified object. Various options are available to
control the extent of the re-classification, for example, to ensure only a change of typing without
a change of ClassDef.
ReclassifyObject
Argument Description
1. Show confirm changes page Display any changes to the objects as a result
of the reclassification.
2. Allow ClassDef change Determines whether to allow reclassification if

the target ClassDef differs from the original.
FALSE = Do not allow reclassification. TRUE =
Allow reclassification.
3. Top classification Top-level classification for displaying in the tree.
4. ENS handling Handle changes to ENS based on

reclassification. For example, full renaming or
retain ENS name.
5. Form purpose Mode in which to prompt for any missing data

(usually Update).
6. Classification filtering tree A ~ (tilde) separated list of interfaces to filter for

in the classification tree.
The ReclassifyObject client API has an updated argument 6. You can restrict the
availability of classification tree nodes in the hierarchy tree by selecting an interface definition in
the Reclassify form that you can use to filter the classifications. This behavior is now consistent
with the Create method.

Configure unique identifiers

You can control the format and value for an object’s unique identifier definition (UID) and unique
key definition by setting the SPFUIDDef and SPFUniqueKeyDef properties on the class
definition of the object. For most objects, you can define a prefix and then use the object's name
as the value. For example, specifying TG.Name as the SPFUIDDef property for tags results in
any tags being given a UID of TG_NameofTag
For documents, additional configuration is available that allows each of the document classes
(master, revision, and version) to inherit the UID and/or unique key from the PARENT object in
the document class definition hierarchy. For example, in the default design document
configuration, the document revision UID is defined as the document master UID with the major
and minor revision appended to it.
You can define inheritance of UIDs and unique keys for document classes using the
PARENTUID keyword. For example:
SPFUIDDef="PARENTUID,SPFMajorRevision,SPFMinorRevision"
Similarly, you can set the unique key using the document master's unique key on the revision
using the following:
SPFUniqueKeyDef="PARENT,SPFMajorRevision,SPFMinorRevision"
You must not use PARENTUID as part of a unique key definition as this can
disconnect relationship definitions from the objects. The recommended way of configuring this
type of inheritance for UIDs is to use the PARENT key word. Therefore:
 PARENT for use only in a Unique Key definition.
 PARENTUID for use only in a UID definition.
PARENT and PARENTUID example

<ClassDef>
<IObject UID="SPFDesignDocMaster" Name="SPFDesignDocMaster"
Description="Design Document" ContainerID="Core.SPFDesignDocumentSchema"
/>
<ISPFClassDefExt SPFIsConfigurationControlled="True"
SPFUniqueKeyDef="DM,CurrentConfig,Name"
SPFUIDDef="DM,CurrentConfig,Name" />
<ISchemaObj DisplayName="Design document" />
<IClassDef />
</ClassDef>
<ClassDef>
<IObject UID="SPFDesignDocRevision" Name="SPFDesignDocRevision"
Description="Design Document Revision"
ContainerID="Core.SPFDesignDocumentSchema" />
<ISPFClassDefExt SPFIsConfigurationControlled="True"
SPFUniqueKeyDef="PARENT,SPFMajorRevision,SPFMinorRevision"
SPFUIDDef="PARENTUID,SPFMajorRevision,SPFMinorRevision" />
<ISchemaObj DisplayName="Design document revision" />
<IClassDef />
</ClassDef>

<ClassDef>
<IObject UID="SPFDesignDocVersion" Name="SPFDesignDocVersion"
Description="Design Document Version"
ContainerID="Core.SPFDesignDocumentSchema" />
<ISPFClassDefExt SPFFTREnabled="True"
SPFIsConfigurationControlled="True"
SPFUniqueKeyDef="PARENT,SPFDocVersion"
SPFUIDDef="PARENTUID,SPFDocVersion" />
<ISchemaObj DisplayName="Design document version" />
<IClassDef />
</ClassDef>
See Also
Rename objects, UIDs, and unique keys (on page 38)
Rename objects, UIDs, and unique keys

When an object is renamed using an update form or in a load file, the UID and the unique key of
each object is updated to reflect the new name that forms as a part of the UID or unique key.
When renaming documents, the UID is set on the master, so all revisions and all versions are
renamed if inheritance is defined on the UIDs for document classes using the PARENTUID
keyword. All these objects have the UID regenerated, including any relationships. In this
situation, when you rename an object with the UID set, the name on the master, all revisions,
and all versions are updated so that they are all consistent.
 If any of the revisions have been revised into a sub-configuration when the document is
renamed, the UID is not regenerated. The name changes on the object related to the update
method only.
 For other types of objects such as SCHEMA or ADMIN, the objects can be renamed, but the
UIDs are not updated as this is not supported by the cache service.
See Also
Configure unique identifiers (on page 37)

SECTION 3
Classified Object Model

This section describes the core SmartPlant Foundation schema model for classified objects and
how the model is extended for each tree or family of objects.
Core classification tree diagram

The diagram below shows the relationship between the classification tree objects that instantiate
ISPFObjClass and the Enum hierarchy and the relationships to the ClassDef, Form, and ENS
Definition. This core model underpins all classification trees as described in more detail below.
Remember that not all trees require the relationships to the Enum hierarchy, only those that
expose the SmartPlant integration typing hierarchies.
There are two very important points to note about this diagram:
 There are two relationships between ISPFObjClass and IEnumEnum, one to map from the
classification tree to the SmartPlant integration typing hierarchy and one for mapping in the
other direction.
 There is an abstract relationship between ISPFObjClass and IClassDef that needs to be
specialized for each different family on the classification tree.

ISPFObjClass interface
This interface identifies a ClassDef as part of a classification tree and is the interface on which
all classification tree functionality is written.
The following property is found on this interface.
Name Description Set On
SPFClassificationOccurance Used to support multiple nodes with The code

the same name in the same tree. *
* The property makes up part of the key classification tree objects and is used to support
multiple nodes with the same name in the same tree.
Functionality configured on ISPFObjClass

The following commands are configured on this interface: Add Optional Interfaces.
SPFObjClassEnumEnum relationship definition

This is the optional relationship used during interactive creation to determine the SmartPlant
integration typing for an object based on the selected classification. More than one classification
tree node can be mapped to the same Enum using this relationship, which would mean multiple
classifications generate objects of the same typing structure. It is not possible to map one
classification tree node to more than one Enum with this relationship because it would not be
possible to determine the unique Enum for a given classification.
SPFEnumEnumObjClass relationship definition

This is the optional relationship used during publish to determine the classification for an object
based on the published SmartPlant integration typing. More than one Enum can be mapped to
the same classification tree node using this relationship, which would mean multiple typing
publish objects of the same classification. It is not possible to map one Enum to more than one
classification tree node with this relationship because it would not be possible to determine the
unique classification for a given Enum.
SPFClassDefForm and SPFClassDefENSDef relationship

definitions
The default form and engineering numbering system for an object is determined by these
relationships to the ClassDef; however, alternative specialized forms and engineering
numbering systems can be configured via the classification tree.
When determining the form and the engineering numbering system for a classified object, the
system looks up the classification tree for one that is related to both the node of the
classification tree and the ClassDef to be created. If one is not found, the default form and
engineering numbering system related to the ClassDef is used.

SPFClassMember relationship definition

This links the sub classification to its parent classification. ISPFObjClass is related to itself in
order to create a nested classification structure.
IEnumEnum interface
This holds the enumerated values (the entries in the Enum list).
The following properties are found on this interface.
EnumNumber The enumerated value. This is set on the schema

when it is defined.
EnumIsDisabled Enum is disabled. Not supported but planned

in a future release; it will
make the Enum valid for
query and so forth but not
for update or create.
Functionality configured on IEnumEnum

The following commands are configured on this interface: Add Optional Interfaces.
IClassDef interface
The primary interface of the meta schema definition of a ClassDef.
Core classified object relationship model

The following sections illustrate how classified items are related to the classification tree. These
are core relationships; one of which (abstract) can be specialized for each different classification
tree for different sets of classified ClassDefs.

Class items
To support queries at any level for any classified object:
Tags have eight levels of hierarchy (only the first three levels are shown in the above diagram).
Level relationships can be exposed on properties grid, forms, reports, and so on.
Relate class tree to Enum tree

The following configuration is required (for publish and retrieve) for publishing to the data
warehouse.

Core classified object diagram
Details of the properties and functionality exposed by these interfaces are given in the sections
that follow.
Specializations of SPFItemClassification are used to relate objects to each classification tree if
the object is classified by more than one tree. SPFItemClassification is used for general
navigation between classified objects and the classification tree
SPFPrimaryClassification is a specialization of SPFItemClassification and is used to link every
classified object to its main tree, the one that is primarily used in the Desktop Client to create
and manipulate the objects.
It is possible to configure more than one Classification Tree for use in classifying objects of a
given ClassDef. For example, there may be an internal company document classification and
also a vendor or contractor document classification. In this situation, the system needs to know
which is primary classification to use when determining relationships between the classification
tree and Enum typing hierarchy. The SPFPrimaryClassification relationship would be used to
link objects to their main tree and other specialized relationships would be used to link the
objects to other trees. The objects are always created via the primary tree and linked at that time
by SPFPrimaryClassification and also linked to the alternative trees by the specialized
relationship.
See above.

ISPFClassifiedItem interface
Identifies an object as a classified object.
SPFClassifiedLevel1-8 relDefs
When a classified object is created, it is linked to the class tree node and all those above using
one of these relationships to support query options from any level of the tree.
Document classification diagram

This diagram shows the document class interface structure to support the creation of a Design
Document. There are additional optional interfaces and relationships for Vendor Documents that
are not shown here. These are detailed in the Delivered For section.

that follow.
Note the two optional interfaces with two different Relationship Definitions that are
specializations of SPFObjClassClassDef.
Client methods are configured on the optional interfaces.
Classifications that instantiate ISPFDesignDocClass are used to create design documents and
those that instantiate ISPFTemplateClass are used to create template documents. Those that
instantiate both can create either.
When relating the document ClassDefs to the classification tree, the document version
ClassDefs is used. There is an exception to this when configuring document reservation where
the document master is related as described in the How to Configure Document Management
guide.
There are two vendor document relationship definitions to the design document class (vendor
documents share the same classification as the design documents). The one to the master is
used for the reserve revision functionality, and the one to the version is for activating the
reserved document or creating a complete vendor document without reservation. For more
information on document reservation, see How to Configure Document Management.
The ISPFListDocumentClass is used to identify classifications for the list documents.
See above.
ISPFDisplayOverride interface
This is an optional interface to allow a display name override and is standard functionality for
administration items.
The following property is found on this interface.
NameOverride Alternative display name for a Create/Update form

classification node.

Classified design document diagram

This diagram shows the relationship between the design document classification tree and the
Enum typing hierarchy. A very similar model is used for the Template documents, but that is not
pictured here because it is so similar.
that follow.
The main thing shown in the above diagram is the overall picture of how the typing relationships
and properties are stored and used.
Without SmartPlant integration

Only the top portion of the diagram is relevant. The class tree would not have any relationships
to the Enum hierarchy, that is, no SPFObjClassEnumEnum or SPFEnumEnumObjClass
relationships. When the document is created, the document is simply related to the relevant
classification tree node by the SPFPrimaryClassification, and the SPFClassifiedLevel#
relationships are created to the higher nodes.

To support SmartPlant integration

SPFObjClassEnumEnum or SPFEnumEnumObjClass relationships have to be in place to map
the classification tree to the Enum hierarchy. The document master realizes the ISPFDocument
interface that contains the typing properties used by SmartPlant integration. The
SPFDocumentClass realizes the ISPFObjClass that is related the SmartPlant integration Enum
hierarchy. When a document is created, it is related to the tree exactly as for the non-SmartPlant
integration situation. Additionally, if there are Enums related to the classification tree node, they
are used to populate the document typing properties.
SPFDesignDocMaster class
The SPFDesignDocMaster class realizes the ISPFDocument interface that exposes the three
document typing properties that are scoped by the document category Enum List Type. As
mentioned previously, SmartPlant integration uses this typing hierarchy to manage its
documents. When a document is published into SmartPlant Foundation, its classification is
determined by navigating the SPFEnumEnumObjClass relationship.
When working interactively in SmartPlant Foundation, the customer may not want to see the
complete SmartPlant integration typing hierarchy. A classification tree, for example,
SPFDocumentClass, is created and related to the Enum hierarchy. The various ways to do this
are described in How To Configure Classified Objects (see "How to Configure Classification
Trees and Classified Objects" on page 13).
When creating a Design Document, the user selects the classification to create and the
properties on the ISPFDocument interface are populated automatically by looking up the related
Enum via the SPFObjClassEnumEnum relationship.
The resultant document is both related to the classification tree and has the typing properties
that enable relationship expansion or query by a specific classification.
If the document class is not to be integrated through a publish or retrieve, there does not need to
be a related Enum hierarchy and the typing properties are not set on the object. The
SPFClassifiedLeveln relationships are always created to support query and relationship
expansion from all levels of the tree.
ISPFDesignDocMaster interface
This interface carries the relationship to the design document revision and identifies the class as
a design document master of a revisable document.
Functionality configured on ISPFDesignDocMaster

The following command is configured on this interface: Copy.

SPFClassifiedItem interface
Identifies a classified object and has the Classified Level relationships to the classification tree
as described above.
ISPFDocument interface
Identifies the object as a document and carries the document typing properties used for
SmartPlant integration.
SPFDocument class
This is the ClassDef for the document classification tree objects.
ISPFDesignDocClass interface
This is the optional interface on the ClassDef for the design document classification tree object
that, when instantiated, identifies the node for managing design documents.
ISPFObjClass
See above.
SPFItemClasification relationship definition

This links the classified item to the class object.
IEnumEnum
See above.
SPFEnumEnumObjClass and SPFObjClassEnumEnum

relationship definitions
Refer to Relate class tree to Enum tree (on page 42). These are only needed for SmartPlant
integration.
Two mappings of the classification node to the SmartPlant integration Enum tree are required:
 Enum for classification
 Classification for Enum
Two Relationship Definitions are required to manage this because the relationship is not
one-to-one. For example, when SmartPlant integration publishes a Horizontal or Vertical
centrifugal pump, its classification would be Centrifugal Pump. If the SmartPlant integration
Enum tree has levels of classification below the customer tree (as in the case of the centrifugal
Pump above), then there would be no need to map the SmartPlant integration sub
classifications because it inherits up the tree as discussed later.

Classified vendor document diagram
that follow.
The following model must be configured.

ISPFClassifiedItem
This must be realized to identify it as a classified item.
SPFVendorDocClassVendorDocMaster
This has to be defined to link the document to the document class tree and is a specialization of
SPFPrimaryClassification. In this case, it links the vendor document master to the design
document class tree.
SPFDocClassVendorVersionClassDef (not shown on the

diagram)
When creating or querying for objects from the shortcut menu of the classification tree,
SmartPlant Foundation needs to know the ClassDef to be created or queried. This can be
specified in a method argument, but to make it easier to configure different ClassDefs from
different nodes of the classification tree, it is necessary to configure a relationship between the
classification tree and the ClassDef to create.
This must be a specialization of SPFObjClassClassDef.
SPFDocClassVendorMasterClassDef (not shown on the

diagram)
This is required by the creation process to reserve the document.
Design document classification model

This model describes the ClassDef for the document classification tree and its relationships.

Design document classification diagram
that follow.
SPFDocument class
See above.

ISPFDocumentClass interface
This interface is used to identify the object as a document classification node. Not all nodes of
the tree are valid for creating document objects, and this interface can be identified on the
create methods to filter the tree so that only nodes with this interface are selectable in the
creation wizards.
ISPFDesignDocClass interface
See above.
ISPFObjClass
See above.
ISPFTemplateClass interface
This is the optional interface on the ClassDef for the template document classification tree object
that, when instantiated, identifies the node for managing template documents.
SPFObjClassClassDef relationship definition

This links the object classification to the classification ClassDef.
SPFDesignDocClassClassDef relationship definition

This is used to link the design document classification to the ClassDef to be created or queried.
This is a specialization of SPFObjClassClassDef.
SPFTemplateClassClassDef relationship definition

This is used to link the template document classification to the ClassDef to be created or
queried. This is a specialization of SPFObjClassClassDef.

Engineering numbering system (ENS) diagram

SECTION 4
Summary of Delivered Classification

Trees
There are delivered trees: Documents, Equipment, and Instrumentation.
Classification tree models

The three trees and their specialized ClassDefs relationships:
This shows the two document classifications and two tag classifications that come in the
delivered model.
 Relate to Version for full document create.

Summary of Delivered Classification Trees
 Relate to master for document reservation (only creates the master).

For more information, see the How to Configure Document Management guide.

Index
A D
Add the classified item interface to the Design document classification diagram •
object ClassDef • 29 51
Automatic creation of a classification tree Design document classification model • 50
from a SmartPlant enum hierarchy • 26 Document classification diagram • 44
Document re-classification • 36
C
Class items • 42 E
Classification tree example use case • 10 Engineering numbering system (ENS)
Classification tree models • 54 diagram • 53
Classified design document diagram • 46 ENS item types • 15
Classified documents and forms • 33 Expose classified objects and documents in
Classified Object Model • 39 the GUI • 34
Classified Objects Configuration • 9 Exposing the classification tree in the client
Classified vendor document diagram • 49 • 28
Configure a new classification tree • 25
Configure alternative ENS definitions for a F
classification • 22
Configure alternative ENS definitions for a Fill ENS gaps • 20
configuration • 22
Configure alternative forms for a H
classification • 33 How to Configure Classification Trees and
Configure classified documents • 33 Classified Objects • 13
Configure heterogeneous classifications •
31
Configure homogeneous classifications • 29
I
Configure secondary ENS definitions • 23 IClassDef interface • 41
Configure the Engineering Numbering IEnumEnum • 48
System (ENS) • 13 IEnumEnum interface • 41
Configure the ENS work process • 13 Importing a classification tree from load files
Configure the Hide ENS Multi Item Create • 27
option • 24 ISPFClassifiedItem • 50
Configure the methods • 30, 32 ISPFClassifiedItem interface • 44
Configure unique identifiers • 37 ISPFDesignDocClass interface • 48, 52
Core classification tree diagram • 39 ISPFDesignDocMaster interface • 47
Core classified object diagram • 43 ISPFDisplayOverride interface • 45
Core classified object relationship model • ISPFDocument interface • 48
41 ISPFDocumentClass interface • 52
Create a new ENS definition • 14 ISPFObjClass • 48, 52
Create a new ENS item • 14 ISPFObjClass interface • 40, 43, 45
Create a new ENS relationship • 21 ISPFTemplateClass interface • 52
Creating the classification tree hierarchy •
26 L
Creating the classification tree interactively Link the class definition to the classification
• 27 tree • 31

Index
Link the ClassDef to be created to the SPFEnumEnumObjClass and

classification tree • 29 SPFObjClassEnumEnum relationship
Link the classified objects to the definitions • 48
classification tree • 30, 32 SPFEnumEnumObjClass relationship
definition • 40
M SPFItemClasification relationship definition
• 48
Make the classification tree SmartPlant SPFObjClassClassDef relationship
integration compatible • 26 definition • 52
Making the classification tree configuration SPFObjClassEnumEnum relationship
controlled • 26 definition • 40
Manage the Engineering Numbering SPFTemplateClassClassDef relationship
System • 20 definition • 52
Managing the classification tree – Enum SPFVendorDocClassVendorDocMaster • 50
mapping • 28 Summary of Delivered Classification Trees •
Model the classification • 25 54
Model the classified objects in the schema •
31
W
P What's New in How to Configure Classified
Objects? • 8
Preface • 6
R
Relate class tree to Enum tree • 42
Rename objects, UIDs, and unique keys •
38
Required ClassDef schema model • 31
Restricting the classification tree node
availability • 30, 32
Running reports on the classification trees •
27
S
Set up the classified document forms • 30,
32
SPFClassDefForm and
SPFClassDefENSDef relationship
definitions • 40
SPFClassifiedItem interface • 48
SPFClassifiedLevel1-8 relDefs • 44
SPFClassMember relationship definition •
41
SPFDesignDocClassClassDef relationship
definition • 52
SPFDesignDocMaster class • 47
SPFDocClassVendorMasterClassDef (not
shown on the diagram) • 50
SPFDocClassVendorVersionClassDef (not
shown on the diagram) • 50
SPFDocument class • 48, 51

How To Configure Classified Objects

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

How To Configure Classified Objects

Uploaded by

Copyright:

Available Formats

SmartPlant Foundation

How to Configure Classified Objects

Version 2014 R3 (5.3)

U.S. Government Restricted Rights Legend

SmartPlant Foundation How to Configure Classified Objects 2

SmartPlant Foundation How to Configure Classified Objects 3

What's New in How to Configure Classified Objects? ............................................................................. 8

Classified Objects Configuration ............................................................................................................... 9

How to Configure Classification Trees and Classified Objects............................................................ 13

Classified Object Model ............................................................................................................................ 39

SmartPlant Foundation How to Configure Classified Objects 4

ISPFObjClass interface .................................................................................................................. 40

Summary of Delivered Classification Trees ........................................................................................... 54

SmartPlant Foundation How to Configure Classified Objects 5

SmartPlant Foundation Product Documentation

Model Configuration Guides

SmartPlant Foundation How to Configure Classified Objects 6

 How to Configure Performance - Provides information for system administrators on how to

SmartPlant Foundation How to Configure Classified Objects 7

SmartPlant Foundation How to Configure Classified Objects 8

Classified Objects Configuration

SmartPlant Foundation How to Configure Classified Objects 9

Classification tree example use case

SmartPlant Foundation How to Configure Classified Objects 10

Classification Tree SmartPlant Enum Tree

[-] Tag Types [Query Models]

[-] Equipment [Query Models] Equipment

Material transfer equipment

[-] Pumps [Query Models] Pump

[-] Centrifugal Pump [Query Models] Centrifugal pump

[-] Valves [Query Models] Valves

SmartPlant Foundation How to Configure Classified Objects 11

Classification Tree SmartPlant Enum Tree

[-] Gate Valve [Query Models] GAT

SmartPlant Foundation How to Configure Classified Objects 12

How to Configure Classification Trees

Configure the Engineering Numbering System (ENS)

Configure the ENS work process

SmartPlant Foundation How to Configure Classified Objects 13

What do you want to do?

Create a new ENS definition

Create a new ENS item

SmartPlant Foundation How to Configure Classified Objects 14

ENS item types

The options available for the Constant ENS type are:

The options available for the Environment ENS type are:

SmartPlant Foundation How to Configure Classified Objects 15

SmartPlant Foundation How to Configure Classified Objects 16

The options available for the Function ENS type are:

SmartPlant Foundation How to Configure Classified Objects 17

The options available for the Property ENS type are:

SmartPlant Foundation How to Configure Classified Objects 18

SmartPlant Foundation How to Configure Classified Objects 19

Fill ENS gaps

Manage the Engineering Numbering System

in the Library pane to relate the item to the ENS definition.

SmartPlant Foundation How to Configure Classified Objects 20

 Click and to order the objects of the ENS definitions.

Create a new ENS relationship

SmartPlant Foundation How to Configure Classified Objects 21

Configure alternative ENS definitions for a classification

Copy ENS 1 and modify and relate to the class definition.

Now relate the ENS to the relevant node of the tree.