Howto Configurethe Authoringand DWHModels

SmartPlant Foundation
How to Configure the Authoring and Data

Warehouse Models
Version 2009 R4
August 2012
DSPF1-PE-200074D
Copyright
Copyright © 2008-2012 Intergraph Corporation. All Rights Reserved.
Including software, file formats, and audiovisual displays; may be used pursuant to applicable software license agreement;
contains confidential and proprietary information of Intergraph and/or third parties which is protected by copyright law, trade
secret law, and international treaty, and may not be provided or otherwise made available without proper authorization from
Intergraph Corporation.
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
P.O. Box 240000
Huntsville, AL 35813
Terms of Use
Use of this software product is subject to the End User License Agreement ("EULA") delivered with this 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. 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.
Warranties and Liabilities
All warranties given by Intergraph Corporation about equipment or software are set forth in the EULA provided with the software
or applicable license for the software product signed by Intergraph Corporation, and nothing stated in, or implied by, this
document or its contents shall be considered or deemed a modification or amendment of such warranties. Intergraph believes
the information in this publication is accurate as of its publication date.
The information and the software discussed in this document are subject to change without notice and are subject to applicable
technical product descriptions. Intergraph Corporation is not responsible for any error that may appear in this document.
The software discussed in this document is furnished under a license and may be used or copied only in accordance with the
terms of this license. No responsibility is assumed by Intergraph for the use or reliability of software on equipment that is not
supplied by Intergraph or its affiliated companies. THE USER OF THE SOFTWARE IS EXPECTED TO MAKE THE FINAL
EVALUATION AS TO THE USEFULNESS OF THE SOFTWARE IN HIS OWN ENVIRONMENT.
Intergraph is not responsible for the accuracy of delivered data including, but not limited to, catalog, reference and symbol data.
Users should verify for themselves that the data is accurate and suitable for their project work.
Trademarks
Intergraph, the Intergraph logo, PDS, SmartPlant, SmartMarine, FrameWorks, I-Convert, I-Export, I-Sketch, IntelliShip, INtools,
ISOGEN, MARIAN, SmartSketch, SPOOLGEN, SupportManager, and SupportModeler 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 .......................................................................................................................................................... 7
SmartPlant Foundation Product Documentation .................................................................................... 7
Documentation Comments ..................................................................................................................... 8
Introduction .................................................................................................................................................. 9
Authoring and Data Warehouse Overview .............................................................................................. 13

Architecture of SmartPlant Foundation Authoring ................................................................................ 13
SmartPlant Foundation Authoring Client and Server ..................................................................... 13
Architecture of SmartPlant Data Warehouse ................................................................................. 14
Authoring Process Overview ................................................................................................................. 15
Registration .................................................................................................................................... 15
Publish and Retrieve ...................................................................................................................... 16
Data Warehouse Process Overview ..................................................................................................... 17
Pre-Loading Data for Approval ....................................................................................................... 18
Approving the Data ......................................................................................................................... 19
Loading the Data into the Configuration ......................................................................................... 19
Viewing the Data Warehouse Items ............................................................................................... 19
Data Flow through the Domains ..................................................................................................... 21
SameAs Relationship ..................................................................................................................... 28
Authoring Model ........................................................................................................................................ 31

Registration Object ............................................................................................................................... 31
Registration Object Diagram .......................................................................................................... 31
Adapter Document ................................................................................................................................ 33
Adapter Document Diagram ........................................................................................................... 33
Design Basis ................................................................................................................................... 35
Interfaces Used with Authoring ...................................................................................................... 35
Authoring Interfaces Diagram ......................................................................................................... 36
Data Warehouse Model ............................................................................................................................. 37

SmartPlant Integration Document Object Diagram............................................................................... 37
SmartPlant Integration Published Document Diagram ................................................................... 38
SmartPlant Integration Published Instructions Diagram ................................................................. 45
SmartPlant Foundation Authoring Adapter Details ............................................................................... 49

SmartPlant Foundation Adapter ............................................................................................................ 49
ToolParameters .............................................................................................................................. 49
GetPublishableDocTypes ............................................................................................................... 49
PublishDocument ........................................................................................................................... 49
RetrieveDocument .......................................................................................................................... 50
Writing a Tool Map Schema .................................................................................................................. 51
Tool Map File Definition of the Authoring Schema ......................................................................... 51
Tool Map File Mapping Definitions for the Authoring Schema ....................................................... 52
Using Schema Editor to View and Validate Tool Map Files ........................................................... 52
Generate a Tool Map Schema from a Spreadsheet Tool .............................................................. 54
SmartPlant Foundation How to Configure the Authoring and Data Warehouse Models 3
Contents
Writing an Adapter Header File ............................................................................................................. 55

ToolComponentSchema ................................................................................................................. 57
ToolSchemaMapFile ....................................................................................................................... 57
DesignBasisComponentSchema .................................................................................................... 57
Publish Section of the Adapter Header File ................................................................................... 57
Retrieve Section of Adapter Header File ........................................................................................ 59
Compare Section of the Adapter Header File ................................................................................ 60
How to Extend the Integration Schema ................................................................................................... 61

CMF File and Physical Pseudo Files .................................................................................................... 61
Pseudo Files and ContainerID ....................................................................................................... 61
Opening the CMF file for Editing .................................................................................................... 62
Creating a New Pseudo File in the Schema Editor ........................................................................ 63
Merging a Previously Generated Schema into a Pseudo File........................................................ 64
Converting an Existing Pseudo File into a Physical Pseudo File ................................................... 65
Loading Schema Changes into the SmartPlant Foundation Database ................................................ 65
Extracting the Schema Files to Load .............................................................................................. 66
Loading the Exported Files into SmartPlant Foundation ................................................................ 67
Regenerating New Component Schema Files ............................................................................... 67
Published Loader Operation .................................................................................................................... 69

Overview ............................................................................................................................................... 69
Supporting an Object Change of ClassDef ........................................................................................... 69
Workflow ............................................................................................................................................... 70
Example of the UpdateClassInstruction ................................................................................................ 70
Plant Breakdown Structure for Integration Setup .................................................................................. 70

Integration Hierarchy Limitations .......................................................................................................... 71
Plant Naming Guidelines ...................................................................................................................... 71
Work Process for Creating a Custom PBS Hierarchy........................................................................... 72
Remove the Existing PBS Structure ............................................................................................... 73
Check Out the SmartPlant Schema CMF File ................................................................................ 75
Define the Plant Breakdown Structure (PBS) Hierarchy from a Template ..................................... 75
Check In the CMF file ..................................................................................................................... 77
Prepare the CMF Data to be Loaded into SmartPlant Foundation ................................................ 77
Load the CMF Data Changes into the Data Warehouse Database ............................................... 78
Generate Component Schema Files .............................................................................................. 80
Generate SmartPlant Foundation Authoring PBS Configuration ................................................... 80
Load New Schema Files for the Alternate PBS ............................................................................. 84
Add the PBS to SmartPlant Foundation and Test .......................................................................... 85
Work Process for Creating or Modifying a PBS Hierarchy Template ................................................... 89
Create a New PBS Template ......................................................................................................... 89
Create a New Plant Group ............................................................................................................. 90
Edit the Plant Breakdown Structure (PBS) Hierarchy Template .................................................... 91
How to Configure Excel Publish .............................................................................................................. 97

Steps to Configure the Excel Publish.................................................................................................... 97
Published Schema Definition ......................................................................................................... 97
ViewDef Creation ............................................................................................................................ 97
Excel Template Document Creation ............................................................................................... 98
Datasheet Definition Creation ........................................................................................................ 98
4 SmartPlant Foundation How to Configure the Authoring and Data Warehouse Models
Contents
Map the ViewDef to the Excel Template ........................................................................................ 99

Configure a Publish Method ........................................................................................................... 99
How to Configure SmartPlant Foundation Authoring ......................................................................... 101

Defining the Data Warehouse Schema .............................................................................................. 102
Shared Object Configuration for Data Mining .............................................................................. 103
Data Warehouse Publish Schema Creation ................................................................................. 105
Loading the Publish Schema into SmartPlant Foundation ........................................................... 105
Defining and Mapping the Authoring Schema .................................................................................... 106
Generating the Authoring Schema and Mapping ......................................................................... 106
Configuring Domains .......................................................................................................................... 110
Configuring the Authoring Environment .............................................................................................. 111
Configuration to Create and Manage the Authored Data ............................................................. 111
Configuring Equipment List Authoring ................................................................................................ 120
Adapter Document Configuration ................................................................................................. 120
Setting Up Publish and Retrieve Roles ............................................................................................... 121
Configuring Publish for Authored Data ............................................................................................... 122
Register Tool ................................................................................................................................ 122
Publish Object or Document ......................................................................................................... 123
Publish by Query .......................................................................................................................... 124
Publish Data Sheet ....................................................................................................................... 124
Load Published Data .................................................................................................................... 125
Configuring SkipFailedDocuments ............................................................................................... 125
Configuring the Retrieve and Compare Process ................................................................................ 126
Configuring Retrieve for Objects Published by Other Tools ............................................................... 126
Mapping the Retrieved SmartPlant Schema to the Authoring Schema ....................................... 127
Retrieve Document ....................................................................................................................... 127
Configuring a Design Basis Document ............................................................................................... 128
Design Basis Document Configuration ......................................................................................... 128
Compare with Design Basis ......................................................................................................... 130
Compare with Latest Retrieved Data ........................................................................................... 131
Configuring Exposure of the Published Data ...................................................................................... 132
Special Edge Definitions............................................................................................................... 132
Configuring Data Warehouse Inconsistency Reports ......................................................................... 133
Load XML files to run Inconsistency Reports on an Updated Database ...................................... 135
Retrieving Data Authored in SmartPlant Foundation into Other Tools ............................................... 136
Configuring Excel Load for the Equipment List ................................................................................... 136
Configuring Excel Publish for the Equipment List ............................................................................... 137
Summary of Core Delivered Authoring and Data Warehouse Models (OOTB) ................................. 139
Domains and Their Usage .................................................................................................................. 139
Adapter Documents ............................................................................................................................ 140
Roles and Message Access Groups ................................................................................................... 141
Administration Roles..................................................................................................................... 141
Authoring Roles ............................................................................................................................ 143
Data Warehouse Roles ................................................................................................................ 145
Integration Roles .......................................................................................................................... 146
Authoring Methods .............................................................................................................................. 146
Register Authoring Tool with SmartPlant Foundation .................................................................. 146
Framework Retrieve ..................................................................................................................... 147
Compare with Design Basis ......................................................................................................... 147
Compare with Latest Retrieved Data ........................................................................................... 148
Contents
Publish RHM ................................................................................................................................. 148

Publish by Query .......................................................................................................................... 149
Publish Data Sheet ....................................................................................................................... 149
Sample Adapter Document Load File .................................................................................................... 151
Index ......................................................................................................................................................... 153
Preface
This document details how to configure the authoring and data warehouse models 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.
In describing the authoring and data warehouse models, this document refers to administration
objects such as methods and menus. Details on how to configure these objects can be found in
other administration guides.
SmartPlant Foundation Product Documentation

SmartPlant Foundation documentation is available as Help and as Adobe® 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 Guide Master Table of Contents - Provides a copy of the table of contents of each
"How to" document in the SmartPlant Foundation documentation set. Use this document to
locate the guide that contains a particular topic without opening each "How to" guide to
search for the topic.
 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 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 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 Document Management - Provides information for system administrators
on how to configure document management in SmartPlant Foundation and describes the
 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 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 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 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.
Preface
 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
 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 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 and describes the
 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).
SECTION 1
Introduction
SmartPlant Foundation authoring is all about using SmartPlant Foundation like any other
engineering tool to create and manage data in isolation from the approved plant model and
publish items to that model when ready to share it with the enterprise. Users can either create
data interactively and via loaders, like the Excel loader, or retrieve data published by other tools
such as SmartPlant P&ID, to form the basis of their design. The data can be published in a
number of ways, either on an ad-hoc basis directly from the item via its data sheet, or by first
creating a formal data sheet or list document for approval to control the scope of the data
published.
Different Uses for SmartPlant Foundation

SmartPlant Foundation has long been used to create data, as well as manage data created by
the SmartPlant Enterprise tools. It can be used in stand-alone mode to create data, as a basic
integrator to be the file broker among tools in an integrated enterprise, and as a full-blown data
warehouse to expose and manage integrated data. In SmartPlant Foundation 2007, there was
no clear separation of the data in each of these environments.
SmartPlant Foundation 2008 introduced the concept of domains to separate the data published
by the tools and also to separate working data in SmartPlant Foundation from its published data.
This introduced different ways of using SmartPlant Foundation. The user‟s role controls access
to data and ultimately in which mode, or modes, they are working. The following terms are
important for understanding the environments in which SmartPlant Foundation is working.
Stand-alone SmartPlant Foundation
SmartPlant Foundation is considered stand-alone when it is used without any tool integration
and uses the regular create, update, and delete commands in SmartPlant Foundation to
manage data just like in the SmartPlant Foundation 2007 integrated systems.
Data Warehouse
SmartPlant Foundation can be used to manage data across the integrated enterprise. The data
warehouse holds all the data published by the tools, allowing users to browse the data and view
inconsistencies across the different tools. They can use SmartPlant Foundation to create
support and reference data such as manufacturers, transmittals, and so on.
SmartPlant Foundation Authoring
"SmartPlant Foundation authoring" refers to the action of creating data in SmartPlant
Foundation and publishing it to the data warehouse. It must not be confused with the creation of
data that is not published. SmartPlant Foundation authoring is like a design tool and should be
used as a design tool with no visibility to the data warehouse and vice versa. For example the
user‟s roles may limit access so that the user sees SmartPlant Foundation as a dedicated
application for equipment list generation. Generally, the authoring domains are unique to the
different SmartPlant Foundation applications or engineering disciplines.
Before a user can publish or retrieve data, the SmartPlant Foundation authoring application
must first be registered with the data warehouse. This is just like any other authoring tool, and
the registration identifies the plant into which the data is published.
Introduction
Mapping and Data Transformations

The data stored in the data warehouse is defined by SmartPlant schema. This describes the
data in a consistent schema to maximize the efficiency of managing the published data by, for
example, using common properties for each of the tool's published data. Each tool, such as
SmartPlant P&ID, has its own internal data dictionary that can in no way be expected to match
the SmartPlant schema. To accommodate these differences, each tool exposes its data
dictionary, which is mapped to the SmartPlant schema. As the tool publishes data, it uses this
mapping to transform the published data into the SmartPlant schema format and save it in a file.
This file is transferred to SmartPlant Foundation and stored in the data warehouse. The data is
loaded from the files into the data warehouse once it has been approved.
SmartPlant Foundation Domains

Domains are a convenient way of grouping together data of a particular set of classes. Domains
can be turned on and off by the users roles and are used to segregate data. Users in one role
may not have access to a domain that is accessible to another user in a different role. To
facilitate the different ways of working there are three „categories‟ or informal groupings of
domains that are combined when using SmartPlant Foundation in each of the „environments‟
described above.
Data Warehouse Domains
These are the shared and published domains. The publish domains store the documents and
data published by the tools, and the shared domain links together the different versions of the
same object published by multiple tools.
Authoring Domains
These are private domains used by SmartPlant Foundation to author equipment lists (and so on)
that are then published to the data warehouse. They are used to manage engineering data
before it is released to the enterprise through a publish, just like P&ID manages its data.
Separate authoring domains may be configured to isolate data by different disciplines in
SmartPlant Foundation. Alternatively, a single domain may be configured for multiple roles all
working on a common data set, though access can still be restricted to objects or parts of
objects using conditions. This usage of authoring domains is discussed in more detail later in the
document.
Common or Reference Domains
These are the core SmartPlant Foundation domains that are used for anything else interactively
created in SmartPlant Foundation, such as transmittal, folder, or supplier. Data in these domains
is visible by anyone using SmartPlant Foundation in any environment.
As already mentioned, the user‟s role controls access to the system, part of which is setting up
the different domains to be queried.
 When working in stand-alone, the user would have access to the common domains only.
 When working in the data warehouse, the user would have access to the data warehouse
domains and the common domains.
 When authoring data, the user would have access to one or more authoring domains and
the common domains.
There is no technical reason why a user cannot access both authoring and data
warehouse domains but a query for a SmartPlant Foundation tag will return both the data
warehouse and authored versions of the tag, which might be confusing to the user. For this
reason, users should be restricted to working in one or the other.
The diagrams in the sections below illustrate how this works.
Introduction
Overview of SmartPlant Foundation Data Segregation

Stand-alone SmartPlant Foundation
The user is working with a set of core SmartPlant Foundation domains to create and manage
data.

The user is working with one or more authoring domains and a set of core SmartPlant
Foundation domains to create and manage transmittals, documents, and so on.
Introduction
The SmartPlant Foundation authored tag is in the authoring domain and is only visible when this
domain is turned on by the user's role, usually only when the user is creating and updating the
tags (such as an equipment list). It is then published to the data warehouse, and the tags are
loaded into the published domain, which creates new tags that are linked up to the shared
object. If other tools have published the same tag then it is linked by the same shared object.
During this process, the authored data is transformed into the SmartPlant schema format so that
it can be effectively managed.
The user logs into the data warehouse using a different role that exposes the shared and
published domains but not the authoring domain. Now the user sees the published data and
even if another user is logged in and authoring more tags, they do not see changes until that
user publishes them.
Data Warehouse
The user is working with a set publish domains that store the tools published data, the shared
domain linking them together and a set of core SmartPlant Foundation domains to create and
manage transmittals, documents, and so on. Note that this diagram shows data published by
two tools and also by a SmartPlant Foundation authoring application.
SECTION 2
Authoring and Data Warehouse

Overview
Architecture of SmartPlant Foundation Authoring

This section briefly details the key components of Authoring. It includes the main software
elements of SmartPlant Foundation and the SmartPlant Client, as well as describing some of the
component schema used within Authoring.
SmartPlant Foundation Authoring Client and Server

This is an implementation of both the SmartPlant Foundation server and client where the system
has been configured to meet one or more specific disciplines' requirements where SmartPlant
Foundation is used as the tool to create, alter, or delete data. For example, SmartPlant
Foundation (authoring) might be used by process engineers to enter or alter instrument data
sheets. User access would be set up to allow only these users access to this data, and the
component schema would be configured so that the data being generated would be in terms
that they are accustomed to. After editing of the data is complete and it is ready to be shared,
the client will make a call to the SmartPlant Client where data will be released to others by
publishing to the data warehouse.
Component Schemas
A component schema is a subset of the SmartPlant Schema Class Definitions identified for a
particular task or discipline. Each tool has its own set of component schemas for published data,
and SmartPlant Foundation has additional component schemas for authoring and common data.
The component schemas are linked to domains as described later in this document.
Authoring Component Schema

The Authoring Component Schema (SPFAuthoringComponent) is the authoring schema that
contains the key authoring class definitions and interfaces. The contents of this schema contain
document classes to support storage of SmartPlant Foundation adapters, Authoring registration
data and same as relationships. It also contains key interfaces used to control what objects can
be published.
Process Design Component Schema

The supplied Process Design Component Schema (ProcessDesignComponent) is a working
example of an authoring component. The contents of this schema contain the classes to support
the Instrument Process Data sheets and a design basis object for the Process Engineer used
after objects are retrieved into the process domain.
Authoring and Data Warehouse Overview
Schema Component
Not to be confused with a component schema, the Schema Component is a set of DLLs that
perform specific tasks centered on the various schemas used in the system. In authoring, the
Schema Component plays a central part in organizing the data that needs to be published and
retrieved. When data is published, it is the job of the schema component to load up the
component schema and map file and transform the data from the authoring component schema
to the data warehouse component schema.
SmartPlant Client
This is the GUI used for integration often referred to as the common UI. All tools including
SmartPlant Foundation authoring access the publish and retrieve dialog boxes when data is
exchanged between the tool (SmartPlant Foundation authoring, in this case) and the SmartPlant
Foundation data warehouse.
SmartPlant Foundation Adapter

The SmartPlant Foundation adapter is the software component that acts as the interface
between SmartPlant Foundation authoring and the Schema Component. The Adapter fetches
the data that needs to be published from SmartPlant Foundation authoring, loads up the
necessary component and map schemas into the schema component, and then transforms the
data from one format to another.
Architecture of SmartPlant Data Warehouse

This section briefly details the key components of SmartPlant Foundation data warehouse. It
includes the main software elements as well as describing some of the schema. Unlike
SmartPlant Foundation 2007, which consolidated all similar items that published data (defined
by the same as relationship) into one object, SmartPlant Foundation 2008 (and later) stores its
published data into separate domains within the database and a shared object is created that
points to all similar objects.
SmartPlant Foundation Data Warehouse Client and Server

This is an implementation of both the SmartPlant Foundation server and client in which the
system has been configured to act as a data warehouse.
EFSchema
The key schema used for defining the data warehouse content is defined within the SmartPlant
schema. This schema contains all the component schemas that are used within the integration
environment.
Shared Domain
This domain can be considered the core domain of the data warehouse and is used to store all
published documents and hold all of the shared objects that point to all of the data that resides
in the published domains. When a tool publishes data, a document is created in this domain in
the specified configuration (Plant). Any files that are associated are also attached to the
document in this domain. At this stage the document is "unapproved". This attached data can be
directly loaded into the correct configuration or optionally loaded into a sub configuration so that
the data can be validated ("approved").
After approval, the data contained in the associated files is loaded into the necessary tool
domain, and a shared object is created in the shared object domain that point to the data in the
tool domain. A SameAs relationship issued when there is a common object used by multiple
tools, and rather than create a new shared object, a shared object that already exists is linked
instead.
In order to achieve this objective, all objects and relationships loaded into the published domains
also have a common interface (ISPFTEFPublishedItem) added that can be used for navigation
purposes.
In order to prevent duplicating data between SmartPlant Foundation authoring and

SmartPlant Foundation data warehousing, there are a number of domains that can be
considered as “shared” domains. These are the Schema, Admin, SmartPlant Foundation, and
SPFReference domains.
Publish Domains
Each tool that publishes data into SmartPlant Foundation has a domain set up for it. The publish
domain is used to store approved and unapproved published data.
Authoring Process Overview

Registration
In order to publish or retrieve data, a tool needs to be registered with the data warehouse. This
registration links the tool to the SmartPlant Foundation data warehouse server and a particular
plant. A unique signature is generated each time a tool is registered. A tool has to separately
register each data warehouse plant it is to work with. This may be a single tool database
managing multiple plants or separate tool databases for each plant depending on how the tools
work internally. SmartPlant Foundation supports multiple plants so each registration of a
SmartPlant Foundation application uses a separate plant.
The registration process also compares the authoring tool‟s schema release number against the
list of supported release numbers on the SmartPlant Foundation server. If the tool schema is
compatible, the tool is granted registration.
Publish and Retrieve

After a tool (including SmartPlant Foundation) has been registered with the SmartPlant
Foundation data warehouse, data can then be exchanged using the publish and retrieve options
that are available within the SmartPlant Client.
In summary, the tool using SmartPlant Client publishes a document that is stored within the
Data Warehouse shared domain until the appropriate action to load it is taken. This load process
is described below in the data warehouse process overview. Once the document has reached
this state, it is marked as now being retrievable by other tools. Providing the other tools have
been registered and the correct access to the document types has been configured, these other
tools can start retrieving this document (and the associated data).
Data Warehouse Process Overview

After a tool has published a document, a representation of it exists within the Shared domain
with the data stored within attached files. The process is then to make any checks that need to
be made first before deciding to load the data and making the document available for other tools
to retrieve. Depending on the procedure in place within an organization, the process of loading
the data can be as simple or as complex as the organization wants to make it - a simple
automatic load or a more complex per load for approval. This process is managed by publish
workflows. The following sections detail the options available.
Managers and project leads can review the published viewable file, but if they wish to look at the
data in detail before they load it into the data warehouse, it is necessary to pre-load the data for
approval.
Pre-Loading Data for Approval

The approach for approval of data is to load the published data into a sub document
configuration below the plant. This makes use of SmartPlant Foundation‟s powerful concurrent
engineering functionality where a user querying the document configuration can see the data
loaded in isolation, in the context of existing plant data and compare the two. This is an optional
step due to the size of some of the files, the time taken to load the data, and the amount of
storage that it requires. This sub-configuration is named after the associated published
document version and is used to load only items associated with it. The permissions of this sub
configuration are automatically inherited and carried forward from the parent plant or project
configuration.
Creating a Sub Configuration

A process step (LoadToDocConfig) at the start of the publish workflow (PublishWithDocLoad) is
used to easily create a sub configuration to be easily created that inheits permissions
(CreateDesignBasisSubConfig). This creates a configuration below the plant named after the
document in the format
DocumentName__DocumentRevision_DocumentVersion
Alternatively, this configuration can be created manually.
Login to the Configuration

When a user is working in SmartPlant Foundation, the user can login to the dynamically created
configuration. The configuration dialog box shows all “active” configurations if a user has
permission to log into the domain. The new document configuration for the pre-loaded data is
shown as a sub configuration below the plant.
There is also a Set Configuration option on the menu of a published document to set the
current configuration to that of the document instead of having to do this in the regular
configuration selection GUI.
When a user is working in SmartPlant Foundation, there needs to be an easy mechanism to log
in to the dynamically created configuration. The configuration dialog box shows all “active”
configurations if a user has permission to log into the domain.
Loading the Unapproved Data

Loading the data into an unapproved area means that results in each item contained in the file
needs to be created in the document configuration. This is done using the Load Published
Data into Document Configuration command under the Load Options menu on the published
document.
As part of this load process, the file is fetched from the vault, which could potentially be on a
different computer. If the data being loaded references a different version of the schema to that
which has been loaded into the database, then the file also needs to be transformed.
Approving the Data

After a user has logged in and selected a published document, the user can navigate and view
the data for approval, either by looking at the view file or loading the data into a document
configuration as described above. Workflow is used to inform the user that a document needs to
be approved, and standard SmartPlant Foundation functionality, such as relationship expand
and view, is used to inspect the data. There is also functionality to compare data from the
unapproved area to the data contained in the approved area.
Loading the Data into the Configuration

At some point in the process, the data needs to be loaded into the correct configuration.
Because the approval steps are optional, the starting point of the load is from the published
document, rather than from the loaded unapproved area.
This means that data approval needs to be carried out again if the optional load was performed,
but it also means that there is just one route by which data can be loaded into the configuration.
This task can take several minutes or hours to complete, so the Scheduler is used. Like the
optional SmartPlant integration load, the process of loading the data to the published domain
can be initiated from:
 A process step that queues the load-to-configuration in the Scheduler.
 A manual step in case the document is not added to a workflow.
 From the document again if the process fails.
Two processes take place when loading data; a load process that populates the tool specific
publish domain, and the consolidate process that creates a shared object and relates the
published data to the object.
Initially when an object is consolidated there is just one reference from the shared object to a
published object. But as downstream applications begin to take that object and add additional
information, and the data is published and loaded into other domains, the shared object will
begin to point to multiple objects. When the document object contained in the data file is loaded
rather than creating a shared object, a link to the published document is established.
Viewing the Data Warehouse Items

The general rule for navigating data in the data warehouse is that the user always starts any
activity from the core shared object and also finishes off on a shared object if it is a relationship
expansion.
Quick Find
To quick find an item in the data warehouse, the standard SmartPlant Foundation quick find
functions are configured on the shared object interfaces.
Detail Form
The standard detail form functionality is used to navigate from the current shared object to the
associated Comprised Of tool object. SmartPlant Foundation then searches for the most
specific view definition that it can find and uses this view (along with the associated graph
definition) to gather up and display the data.
The shared object is not classified so there is no possibility for configuring different forms on the
shared object. It is also not possible to show data from the Comprised Of published data. For
this reason, a separate command has been configured to show the different published data.
View Shared Data (Inconsistencies) Form

The View Shared Data (uses ViewSharedData API) form is used in order to view all of the data
published by all of the tools in one dialog box. This form highlights any inconsistencies found
between the different views (or tools) of the data. Separate commands, such as View Shared
Equipment, are configured for different types of published objects as a graph is used to identify
the data to display.
Ad Hoc Report List View Changes

The ad hoc reports return multiple property values for properties published by multiple tools.
There is an option on the report dialog to Display latest values only that returns only the latest
values to the list view, detects any inconsistencies, and display them in a different color (yellow).
If the user requires finding out more about why the data was inconsistent, then they execute the
History or View Inconsistencies commands.
The reports have to be configured with a ViewDef starting at the shared object and then
navigating the SPFTEFComprisedOf relationship to the properties of the published data.
Properties Grid
The role that the user has logged in to determines the information that is displayed in the
property grid when an object is selected. The system looks for a ViewDef on the most specific
interface of the shared object. If one is not found, then all the data is returned. To further control
which ViewDef is selected, the system filters ViewDefs based on owning groups related to the
object‟ interface. The ViewDef is filtered out if the interface is related an owning group that is not
in the user‟s role.
The properties grid displays all the data that it finds the ViewDef in all of the published domains
that comprise that shared object. Where inconsistencies are found, multiple values for the
properties are displayed.
History
The mechanism to display data for history is similar to the Properties window mechanism. This
uses a ViewDef in much the same way.
Data Flow through the Domains

The following diagrams illustrate a typical process where data is moved from one domain to
another.
 Data is published from the tool into the data warehouse shared domain. A SmartPlant
Foundation document is created and its data and view files attached. The document is also
attached to a workflow that is used for approval and data loading.
 As part of the workflow, there is an optional step to load the data into a sub-configuration in
the tool domain. In here the data can be viewed and navigated and then approved (or
rejected).
 When the document is approved, the data contained in the attached files is then loaded in
the tool specific domain into the appropriate configuration. In the example below this is a
Plant. When the consolidate task is run, a shared object is also created in the data
warehouse domain and is related to the tool specific domain. Similar objects from other
domains are also associated.
 Other documents do not have to be loaded before they can be retrieved.
 Once approved, a document can then be retrieved. For existing tool adapters, data is
retrieved through a To Do List in the tool. For SmartPlant Foundation or a tool using the
adapter, data is first retrieved into a design basis domain, and then using compare
functionality, a user can choose which data should then become part of the design.
 The publish process can then be repeated once the design is complete.
Data Publish
 A document and its files are published from the tool. The result of this publish is that a
SmartPlant Foundation three-tier document (master/revision/version) is created in the
DWShared domain in the project it was published to.
 The associated files are stored at the tool schema version, which may not necessarily be the
same as the SmartPlant Foundation schema version. A relationship to an object
representing the SmartPlant schema is also created.
 A workflow is set up to manage the process of getting the contents of the file loaded and
then merged into an approved area. This workflow can optionally trigger off a load into a
sub-configuration.
The user is able to log in to a particular configuration and view the documents that need
approval.
Optional Data Load

This optional step in the workflow is used to load the data into a sub-configuration so that data
can be approved. A Scheduler task is used so that the user does not need to wait for the
operation to complete, as this may take some considerable time if it is a large file.
This task triggers a transform of the files if they are a different version to the current SmartPlant
schema version loaded. Once the transform is complete, a sub configuration is then created,
and the contents of the file can be loaded. At this stage, the data is unapproved.
Data Approval
The user is able to see the data that needs to be approved in the workflow step and is able to
change to that configuration. This can be done either from the main configuration selection
dialog box or from a shortcut menu on the document.
Using standard SmartPlant Foundation functions, the user can navigate the data in the domain.
The user can view that data using standard SmartPlant Foundation functionality such as the
details form, the properties grid area, ad hoc reporting as well as some of the navigation
functions.
There is a new compare function that can be used to compare the data in the unapproved
configuration with the project or plant configuration.
Data Load
As a result of approving a step in a workflow, a process step is then run that triggers the load
and consolidate process into the same domain. The data is loaded into the plant and the sub
configuration is deleted.
Shared Objects
Whenever data is consolidated into a tool domain, such as PFD, a shared object is created in
the central DWShared domain. This object only instantiates one or two key interfaces and relies
on the relationship (SPFComprisedOf) to point to the real data.
A shared document is created in the DWShared domain and linked to the full document that is
created in the publish domain. The document master is also related to the tool signature, which
is related to the plant and tool that the tool signature represents.
Shared Objects (Multiple Domains)

For each tool that publishes data to the data warehouse, a separate domain is needed. The data
from each tool is loaded into the appropriate area and a link to the DWShared domain is
created.
If an object is identical to another item, the tool object is linked to an existing proxy object (or
Shared Object).
In order for the Same As relationship to be created, the data is first retrieved by the tool. In the
following diagram the dotted line between the document version and the signature represents
this relationship.
SameAs Relationship
A SameAs relationship is created for a common part used by multiple tools. Rather than create
a new shared object, a shared object that already exists is linked instead.
When the data is re-published, a SameAs relationship to each object that originated from the
design basis (except the object itself) is created and sent to the data warehouse as part of the
published data.
SECTION 3
Authoring Model
This section describes the Authoring data model in more detail.
Registration Object
Registration associates a design tool with a SmartPlant Foundation plant. The registration
information is held in the database so that the system knows where to publish and retrieve data
for a particular configuration.
The registration object is created on registration along with two relationship definitions to the
configuration item and to a server object.
Registration Object Diagram
Details of the properties and functionality exposed by these interfaces are given in the following
sections.
Authoring Model
SPFAuthRegistration Class
This class holds the signature and relationship to the configuration used when the tool was
registered.
ISPFAuthRegistration Interface
ISPFAuthRegistration is the primary interface of SPFAuthRegistration class, which is the object
that holds the signature as defined by the server.
The following properties are found on this interface.
Name Description Set On

SPFAuthSignature The signature of the tool as defined by the data Registration form
warehouse when the tool was registered. of the tool
SPFAuthToolID This holds the abbreviation for the tool as defined Registration form
in SmartPlant Foundation (for example, IPD for of the tool
Instrument Process Data Sheet tool).
SPFRegistrationConfig Relationship Definition

A tool is registered against a plant or project. SPFRegistrationConfig links the signature to the
configuration the tool was registered against and is created when the tool is registered with
SmartPlant Foundation data warehouse.
ISPFServer Interface
This holds the URL to the data warehouse.
The following property is found on this interface.

SPFServerURL The URL entered as part of the registration Registration wizard
process. form.
SPFRegistrationServer Relationship Definition

This links the registration to the server (URL) and is created on registration.
Authoring Model
ISPFLocalServer Interface
This is implied by ISPFServer and used to distinguish a local server from a remote server.
Adapter Document
The adapter document class is used to store SmartPlant Foundation adapter files within the
SmartPlant Foundation database. Whenever a SmartPlant Foundation publish or retrieve is
invoked, the tool map file and the associated adapter header file are copied down to the client
for mapping to be performed. It is a revisable document comprised of a document master,
revision, and version called SPFAuthAdapterDocMaster.
Adapter Document Diagram
This diagram does not show all the interfaces realized by the adapter document class
definitions, just the ones that are particular to these classes. For more details on the document
structure and other interfaces (such as ISPFDocumentObject), refer to How to Configure
Document Management.
Authoring Model
The diagram shows the structure of the three-tier document consisting of the master, revision
and version, and a new file class. The adapter document is a non-published document as
indicated by the presence of the non-published document interfaces.
The adapter document is a classified document that realizes the ISPFClassifiedItem interface,
which holds the relationship to the document classification tree where an optional interface
ISPFAuthAdapterClass is used to identify the relevant classification and link to the ClassDef of
the document to create. For more information on classified documents, refer to How to
Configure Classified Objects.
Details of the properties and functionality exposed by the interfaces in the diagram are given in
the following sections. Only those specific to SmartPlant Foundation authoring are detailed
below.
ISPFAuthAdapterDocMaster Interface
This document master interface identifies the documents that are used to hold the tool map files
or the tool map adapter header files.

SPFAuthAdapterCode The document type within the domain. This Create form
is named on the publish and retrieve
methods.
SPFAuthAdapterFile
This is the file class definition used for holding the associated metadata for the Adapter mapping
and adapter header files.
The primary interface for this class is ISPFAuthAdapterFile, which does not expose any
properties. It also exposes the regular file interface. It realizes ISPFDBFile and its files are
stored in the database for easy delivery and portability.
SPFAuthAdapterClassClassDef Relationship Definition

This relationship definition links the adapter version to the classification items with the interface
ISPFAuthAdapterClass on it.
ISPFAuthAdapterClass Interface
This interface is associated with the document class definition SPFDocumentClass. An Adapter
document should only be classified to the class tree if this interface is present. These are found
under the System Documents node of the document classification tree.
Authoring Model
Design Basis
The design basis document class is used within SmartPlant Foundation to store the mapped
data that has been retrieved from the warehouse. These interfaces are realized on document
classes that represent a design basis. There is no default document class configured for this,
but it can be used for SmartPlant Foundation-based applications, such as Line Lists.
The SPFTEFRetrievedDesignBasis relationship is used to link the retrieve document to the tool
signature of the retrieving application.
Design Basis File

ISPFDesignBasisFile Interface
The ISPFDesignBasisFile Interface, if present on a File class, indicates that the associated file
contains a retrieved design file.
Example Process Engineer Class Design Basis Classes

The following class definitions are used to define a document object and its associated files for
holding the data retrieved from the data warehouse for process engineering.
PRCDesignBasisDocMaster/Revision/Version
This is an example of a delivered Design Basis document. This is the master class definition of a
three-tier document structure to hold the design basis data retrieved from the data warehouse.
This class definition is associated with the component schema ProcessDesignComponent which
is focused on defining classes for process engineering.
The primary interface for this class definition is IPRCDesignBasisDocMaster, which does not
expose any specific properties. The class also realizes the other standard document master
interfaces such as ISPFClassifiedItem, ISPFDocument, ISPFDocumentObject,
ISPFNonPublishedDocMaster and ISPFDocumentMaster.
Interfaces Used with Authoring

In order for an object (document or plant item) to publish data, the following interfaces must be
added to the item:
 ISPFAuthPublishableItem
 ISPFAuthPublishedItem
Authoring Model
Authoring Interfaces Diagram
sections.
ISPFAuthPublishableItem Interface
This is used to identify that an item can be published.

SPFAuthNeedsRepublishing If true then the item can be Code when the object is
published. updated
ISPFAuthPublishedItem Interface
This identifies that an item has been published. It is optionally realized on the published classes
and is instantiated when they are loaded.

SPFAuthPublishedDate The date published. Code when the object is
published
SPFAuthReasonForPublish The reason for publish. Code when the object is
published
SECTION 4
Data Warehouse Model

This section describes the Data Warehouse data model in detail.
SmartPlant Integration Document Object Diagram
The SmartPlant integration document and SmartPlant schema are complex objects. Each
consists of a master, revision, and version that are related by the SPFIncludesClass
relationship.
SmartPlant Integration Published Document Diagram
sections.
SPFTEFPublishedDocMaster Class
This is the master class definition of a three-tier document structure for published data. This
class definition is associated with the component schema TEFComponent which is focused on
defining classes for data warehouse.
The primary interface for this class definition is ISPFTEFPublishedDocMaster, which does not
SPFTEFPublishedDocRevision Class
This is the revision class definition of a three tier document structure for published data. This
class definition is associated with the component schema TEFComponent, which is focused on
defining classes for the data warehouse.
The primary interface for this class is ISPFTEFPublishedDocRevision, which does not expose
any properties. As well as realizing this interface, the other interfaces that are realized by this
class definition are the standard revision interfaces such as ISPFDocumentObject,
ISPFDocumentRevision, ISPFNonPublishedDocRevision and ISPFWorkflowItem.
SPFTEFPublishedDocVersion Class
This is the version class definition of a three tier document structure for published data.
The primary interface for this class is ISPFTEFPublishedDocVersion, which is described below.
As well as realizing this interface, the other interfaces that are realized by this class definition
are the standard version interfaces such as ISPFDocumentObject, ISPFDocumentVersion,
ISPFNonPublishedDocVersion, ISPFExportableItem, ISPFFileComposition and ISPFOwnedObj.
ISPFTEFPublishedDocVersion Interface
This interface is used to identify a document version as being a published document and
exposes a number of properties which are used when data is published.

SPFTEFObjectUIDSet The UIDs of the objects Framework client will read
contained within the file the file and add this in
SPFTEFRelUIDSet The UIDs of the relationships Framework client will read
contained within the file the file and add this in
SPFTEFDataLoadStatus Indicates whether the contents of Initially set in the Framework
the associated files have been client but set again when the
loaded or not document is loaded
SPFTEFHasBeenCorrelated Indicates whether the contents of Set in the Correlate
the associated file have been workflow
correlated using one of the
correlation workflows.

SPFTEFConsolidateStatus Indicates whether the contents Set to True when the
have been consolidated (whether consolidate task has
the shared objects have been successfully been run
generated)
SPFTEFIsRetrievable Indicates that the document can This property is not set by
be retrieved by other tools. You default. When this property
can use this property (with is not set, the document
custom code) to control the version is available for
availability of a document version retrieval. When this property
for retrieval by other tools. is set to False, the
document version becomes
unavailable for retrieval by
other tools. When this
property is set to True, the
document becomes
available for retrieval in the
Retrieve dialog box.
Functionality Configured on ISPFTEFPublishedDocVersion

The following commands are configured on this interface: Attach File, Compare, View and
Compare, Generate a Map File, Remove Task, Retry Task, Show failure, Consolidate
Document, Load Published Data and Load Published Data into Document Configuration.
SPFTEFPublishedFile Class
This is the file class definition used for holding the metadata for the files that the tools publish.
The primary interface for this class is ISPFTEFPublishFile, which does not expose any
properties. As well as realizing this interface, the other interfaces that are realized by this class
definition are the standard file interfaces such as ISPFFile, ISPFOwnedObj, ISPFRefFile,
ISPFBusinessFile, ISPFAlternativeRenditionComposition and ISPFMarkupCompositition.
Other interfaces attached to this class definition are in the following sections.
ISPFTEFXMLFile Interface
This interface is used to indicate that the associated file is a XML published file.
ISPFTEFToolDataFile Interface
This interface is used to indicate that the associated file is a XML published data file.
ISPFTEFViewableFile Interface
This interface is used to indicate that the associated file is the viewable published file.
ISPFTEFInstructionFile Interface
This interface is used to indicate that the associated file is an instruction file. This typically is the
tombstone file.
ISPFTEFDocumentMetaDataFile Interface
This interface is used to indicate that the associated file is a meta data document file.
SPFTEFSignature Class
The SPFTEFSignatureClass is the class used within the data warehouse that stores the tool's
signature when it registers with SmartPlant Foundation. The primary interface is described
below and the tool data is added to ISPFTEFTool.
ISPFTEFSignature Interface
This interface identifies the associated object as being an integration signature object.
ISPFTEFTool
This interface is used to store tool data when a tool registers itself with SmartPlant Foundation.

SPFTEFToolName The name of the registered tool Within the tool adapter of
the adapter header file
SPFToolDescription A description of the tool that Within the tool adapter of
registered the adapter header file
Functionality Configured on ISPFTEFSignature

The following commands are configured on this interface: Create Design Basis Query, Get
Retrievable Documents and Terminate.
SPFTEFRetrievedDesignBasis Relationship Definition

This links the design basis document version to the design basis signature of the tool that
retrieves it.
SPFTEFSchemaDocMaster Class
This is the master class definition of a three-tier document structure for holding schema data.
This class definition is associated with the component schema TEFComponent which is focused
on defining classes for data warehouse. With the model supplied, the only schema file
represented within the database is the .cmf file.
The primary interface for this class definition is ISPFTEFSchemaDocMaster, which does not
SPFTEFSchemaDocRevision Class
This is revision class definition of a 3-tier document structure for holding schema data. This
class definition is associated with the component schema TEFComponent which is focused on
defining classes for the data warehouse.
The primary interface for this class is ISPFTEFSchemaDocRevision, which does not expose any
definition are the standard revision interfaces such as ISPFDocumentObject,
ISPFDocumentRevision, ISPFNonPublishedDocRevision and ISPFWorkflowItem.
SPFTEFSchemaDocVersion Class
This is a version class definition of a three tier document structure for holding schema data.
The primary interface for this class is ISPFTEFSchemaDocVersion, which is described below.
As well as realizing this interface, the other interfaces that are realized by this class definition
are the standard version interfaces such as ISPFDocumentObject, ISPFDocumentVersion,
ISPFNonPublishedDocVersion, ISPFExportableItem, ISPFFileComposition, and
ISPFOwnedObj.
ISPFTEFSchemaDocVersion Interface
This interface is used to indicate that the document version is for storing schema data. The
following properties are found on this interface.

SPFTEFIsSchemaVersionCurrentlyLoaded Indicates whether the Load operation
schema file has been
loaded or not
Functionality Configured on ISPFTEFSchemaDocVersion

The following commands are configured on this interface: Load, Attach Schema as a File,
Launch CMF File Manager (General), Launch CMF File Manager (PBS), Launch CMF File
Manager (XML), Regenerate Schema Files, Create Schema Item, and Launch Schema
Editor.
SPFTEFSchemaFile Class
This is the file class definition used for holding the schema files.
The primary interface for this class is ISPFTEFSchemaFile which does not expose any
definition are the standard file interfaces such as ISPFFile, ISPFOwnedObj, ISPFRefFile,
ISPFBusinessFile, ISPFAlternativeRenditionComposition and ISPFMarkupCompositition.
The class also realizes ISPFDBFile which results in the schema (the .cmf file) being stored in
the database.
SPFTEFSchemaItem Class
This is a class that represents the main configurations within a .cmf file. Its primary interface is
ISPFTEFSchemaItem which is described below.
ISPFTEFSchemaItem Interface

SPFTEFSchemaVersion The schema version. GUI
SPFTEFIsSchemaConfigCurrentlyLoaded Is the schema configuration GUI
loaded into SmartPlant
Foundation.
SPFTEFSchemaItemToSchemaVersion Relationship Definition

This links the schema items to the schema versions.
SPFTEFQueue Class
SPFTEFQueue is the class used within the data warehouse that is created for a tool to control
the order by which associated published documents are loaded.
ISPFTEFQueue Interface
When a document is published, a relationship is set up to a “special” Scheduler queue object in
order for the correct files to be loaded in the sequence that they were published. The Scheduler
checks for this relationship whenever it attempts to start the load task. By using the date time
stamp on the relationship, the load order can be controlled.
SPFTEFPublishedDocVersionInQueue Relationship Definition

This links the document versions to the document queue.
SPFTEFConfigQueue Relationship Definition

This links the configuration item to the configuration queue.
SPFTEFDesignBasis Relationship Definition

This links the design basis signatures to the design basis document masters.
SPFTEFRetrievedDesignBasis Relationship Definition

This links the design basis document version to the design basis signature of the tool that
retrieves it.
SPFTEFSignaturePublishedDocument Relationship Definition

This links the published documents to the domain signature.
SPFTEFSignatureToolParameter Relationship Definition

This links the tool parameter signature to the tool parameter.
SPFTEFMovedSignatureConfigData Relationship Definition

This links moved signatures to the moved configuration items.
SPFTEFRetrievedDataDesignBasis Relationship Definition

This links the retrieved design basis signatures to the design basis document versions. This
interface is created whenever a user retrieves a document.
SPFTEFSignatureConfigurationItem Relationship Definition

This links the configuration signatures to the configuration item.
SPFTEFDocVersionSchemaItem Relationship Definition

This links the document versions to the schema item.
SmartPlant Integration Published Instructions Diagram
Details of the properties and functionality exposed by these interfaces are given in the sections
that follow.
ISPFTEFPublishInstruction Class Definition

During publish, the SmartPlant Client constructs the publish instruction that SmartPlant
Foundation uses to create the published document within the shared domain.
ISPFTEFPublishInstruction Interface
Name Description
SPFTEFPIDocumentVersion Document version
SPFTEFPISignature Signature
SPFTEFPITargetWorkflowName Target workflow name
SPFTEFPISchemaVersion Schema version
SPFTEFPIOwningGroupName Owning group name
SPFTEFPIDocumentVersionUID Document version UID
SPFTEFPIObjectUIDSet Object UID set
SPFTEFPIDocumentCategory Document category
SPFTEFPIRelUIDSet Relationship UID set
SPFTEFPIDocumentSubType Document sub type
SPFTEFPIDocumentUID Document UID
SPFTEFPIDocumentMajorRev Document major revision
SPFTEFPIDocumentDescription Document description
SPFTEFPIProjectName Project name
SPFTEFPIIsToolDoc Tool document
SPFTEFPIDocumentName Document name
SPFTEFPIGenCorrelations General correlations
SPFTEFPIDocumentRevision Document revision
SPFTEFPIMovedObjectUIDSet Moved object UID set
SPFTEFPIRevisionSchemeName Revision scheme name
SPFTEFPIMovedRelUID Moved relationship UID
SPFTEFPIDocumentMinorRev Document minor revision
SPFTEFPIObjectUIDsInstructions Object UID instructions
SPFTEFPIDocumentType Document type
SPFTEFPIRelUIDsInstructions Relationship UID instructions
 All of these properties are set in the background by the publish process within SmartPlant
Client.
 There is an execute method within the code, that acts upon the instruction, and carries out
some validation prior to the creation of a new publish document with its associated files.
IInstruction Interface
The IInstruction interface informs the code that the item needs to be processed as an instruction
rather than just being loaded. With the code, all interfaces that are a specialization of this
interface (in other words, the publish instruction described above) need to have a method added
within the code that executes the instruction.
SECTION 5

Adapter Details
This section details the SmartPlant Foundation adapter functions and the main functions that it
uses as well as how to write its two main input files, the adapter header file and the tool map file.
SmartPlant Foundation Adapter

The SPFAdapter is the default adapter supplied with SmartPlant Foundation and has been
architected to allow for a limited amount of customization. The adapter supplied has a generic
class, SPFTEFAdapterGEN, that can be referenced directly from a method or can be inherited
from another class in the same assembly or from a custom assembly that can then override any
of the standard functions defined.
Once a new class has been defined, the class can be referenced from a method to allow for
specialized functionality. The SPFAdapter is delivered with one such class that has been
inherited from SPFTEFAdapterGEN called LPDAdapter that applies enhanced mapping for
items with class name PIDPipingConnector.
ToolParameters
This function reads the adapter header files and stores data in memory. It finds the relevant
adapter document using the SPFAuthAdapterCode property on the adapter document master.
The code to search for is identified on the publish and retrieve methods and so on.
GetPublishableDocTypes
This function reads the publishable document types that were originally defined in the adapter
header file and sets the required attributes in the SmartPlant Client.
PublishDocument
This function controls the generation of data when the OK button is clicked on the SmartPlant
Publish dialog box.
Calls are made to the following functions during execution of this function:
 PopulateMetaDataContainer
 ExpandToSecondaryItems
 PopulateDataContainerForPublish
 GetSameAsUIDsForPublish
If the OutputDebugFiles node is defined in the adapter header file, all generated files
used for publish will be saved in the user's TEMP folder.
SmartPlant Foundation Authoring Adapter Details
PopulateMetaDataContainer
This function generates the metadata container for published data. If a view file is passed in as a
tool parameter, then this is added as a reference; otherwise, if the object has any view files
attached, these are added instead.
ExpandToSecondaryItems
This function uses the graph defined in the adapter header file to expand from the selected
items to all related items defined in the graph definition.
PopulateDataContainerForPublish
This function reads the tool map file and the source data and generates the data file to be
published. In order for classes and interfaces to be published, there must be SPFMapClassDef
entries in the tool map file. In order for a relationship definition to be published, a
SPFMapRelDef entry needs to be found, and for any property data that needs to be mapped
across, a SPFPropertyDef entry needs to be found. For enumerated values, all values
transferred regardless of a whether a mapping exists or not, but if mapping exists, the mapping
is used rather than an assumed mapping of one to one.
GetSameAsUIDsForPublish
This function extracts all the UIDs from the file that is being published and makes a call to the
authoring database to see if there are corresponding Same As items. If there are, these are
added to the data file that gets submitted for publish.
RetrieveDocument
This function controls the retrieval of data from the data warehouse. The key points about the
methods are:
1. A call is made to PreRetrieveData first (to allow for customization).
2. The domain of the document being retrieved is determined and subsequently stamped on
any properties instantiated as a result of the retrieve.
3. Key elements of the map file are read into arrays to improve performance.
4. The view file is downloaded if the RetrieveViewFile parameter is set to True in the adapter
header file.
5. The meta data file is read, and the document variables are stored away so that if a design
basis document is created later, it can be created with the same information as it is stored in
the data warehouse.
6. The data file is read, and if a mapping is found, a load file is generated in the authoring
schema. While the data is being processed, and if the item is a ClassDef (and is also
mapped), then a call is made to the function AutoExpandClassDef to allow for enhanced
mapping.
7. The tombstone file is read, and any delete instructions found are extracted. The Same As
objects are read and checked against the authoring database, and if any exist, a new delete
instruction (with the UID of the authoring item) is created and added to the file.
8. A call is made to PostProcessRetrievedObjects to allow for further customization if needed.
9. The data is serialized.
Writing a Tool Map Schema

Tool map schemas are used by the adapters to translate tool data to and from the SmartPlant
Schema. Although SmartPlant Foundation is unlike most other tools in that there is a schema
that is used to define the model, the way that mapping is done is just like any other tool and
uses a tool map schema. The tool map schema is a combination of a representation of a tool
data dictionary and the mapping to the SmartPlant Schema. The schema definition (ClassDef,
InterfaceDef PropertyDef) structure of the SmartPlant Foundation authoring database must be
represented in a tool map schema as a MapClassDef and MapPropertyDef structure. This is
achieved by using the name property on each of the Map classes.
Because the authoring schema and published schema are essentially the same, the SmartPlant
Foundation adapter can make a few assumptions, which means the tool map schema does not
need to be as fully defined as it does for other external tools.
Tool Map File Definition of the Authoring Schema

ClassDefs
Just like any tool, the SmartPlant Foundation authoring schema has to be defined in the tool
map file. The first basis is the definition of the ClassDef.
The example below shows the map class definition for the authoring schema class definition
called PpmPAEquipment.
<SPMapClassDef>
<IObject UID="MapPpmPAEquipment" Name="PpmPAEquipment"/>
<IMapObject/>
<IMapClassDef MapOption="IncludeRealized"/>
</SPMapClassDef>
For the SmartPlant Foundation adapter, the MapOption property does not have to be
filled in; it is included here for reference.
InterfaceDefs and Realize Relations

All interfaces need to be defined as well as a Realizes relationship to the parent class.
<SPMapClassDef>
<IObject UID="MapICleanedItem" Name="ICleanedItem"/>
<IMapObject/>
<IMapClassDef IsInterface="True" MapOption="MapDirectly"/>
</SPMapClassDef>
<Rel>
<IObject UID="MapPpmPAEquipment.MapICleanedItem"/>
<IRel UID1="MapPpmPAEquipment" UID2="MapICleanedItem"
DefUID="MapClassRealizesMapClass"/>
</Rel>
For the SmartPlant Foundation adapter, the MapOption property does not have to be
filled in; it is included here for reference.
PropertyDefs and Expose Relations

All relationship definitions need to be defined if they are to be mapped.
<SPMapRelDef>
<IObject UID="MapPpmUnitPBSItem" Name="PpmUnitPBSItem"/>
<IMapObject/>
<IMapRelDef/>
</SPMapRelDef>
<Rel>
<IObject UID="PBSItemCollection.MapPpmUnitPBSItem"/>
<IRel UID1="PBSItemCollection" UID2="MapPpmUnitPBSItem"
DefUID="RelDefToMapRelDef"/>
<IMapRel MapEnd1IsEnd1="False"/>
</Rel>
Tool Map File Mapping Definitions for the Authoring Schema

Once the tool schema is defined, mapping to the data warehouse schema can be performed
using the tool schema functions in the Schema Editor.
All mapping results in one of two relationships being created:
Mapping for Publish

A MapClassToClass relationship defines the publish map for any ClassDef, IDef, RelDef, and so
on. In this case, the PpmPAEquipment authoring ClassDef defined as the
MapPpmPAEquipment map class is mapped to the PpmPPEquipment ClassDef in the
SmartPlant Schema.
<Rel>
<IObject UID="MapPpmPAEquipment.PpmPPEquipment"/>
<IRel UID1="MapPpmPAEquipment" UID2="PpmPPEquipment"
DefUID="MapClassToClass"/>
</Rel>
Mapping for Retrieve

A ClassToMapClass relationship defines the publish map for any ClassDef, IDef, RelDef, and so
on. In this case, the PpmPAEquipment authoring ClassDef defined as the
MapPpmPAEquipment map class is mapped to the PIDMechanicalEquipment ClassDef in the
SmartPlant Schema.
<Rel>
<IObject UID="PIDMechanicalEquipment.MapPpmPAEquipment"/>
<IRel UID1="PIDMechanicalEquipment" UID2="MapPpmPAEquipment"
DefUID="ClassToMapClass"/>
</Rel>
Using Schema Editor to View and Validate Tool Map Files

Use the Schema Editor to view and validate tool map files.
1. Launch the Schema Editor on the CMF_ver document
2. Use the File > Open > Tool Schema File option to open the tool map file.
3. Use the View > Tool Schema File option to view the contents of the map file. The
Properties tab gives a good overview of the contents.
4. Use the Edit Form tab to view further details and the Publish or Retrieve sub tab to view
the mapping details on an interface.
5. Use the Tools > Tool Schema > Validate > Display Results command to validate the tool
map file. Because the authoring schema and published schema are essentially the same,
the SmartPlant Foundation adapter can make a few assumptions, which means the tool
map schema does not need to be as fully defined as it does for other external tools. This
means that the following validation errors may be shown but they can be ignored:
MinCardinalityNotMet on
FromClassForMapRelDef_<<RelDefName>>
ToClassForMapRelDef_<<RelDefName>>
MapClassMapProperties_Name
MapClassMapProperties_Descriptions
Generate a Tool Map Schema from a Spreadsheet Tool

An alternative approach is to generate the mapping from a spreadsheet, which is probably the
best approach. The authoring schema still has to be generated and can be initially created from
the publish schema as described above.
An example spreadsheet can be found in the delivered product files. This is the one that is used
to define the retrieve mapping for the line list application. The file is called
05PP-PAMappings.xls and is found in the default product folder installed with the program.
There is a button to generate the named files on the README sheet and separate sheets for
defining the mapping as follows:
ClassDefMapping
This is used to define the class mapping. Enter the ClassDef names in the relevant columns to
define the mapping.
InterfaceDefMapping
This is used to define the interface mapping including IObject. All mapped interfaces need to be
realized by their classes in the tool schema as defined next.
RealizesMapping
All mapped interfaces must be realized by their classes in the tool schema.
PropertyDefMapping
Properties on interfaces are mapped as above.
RelDefMapping
The RelDefs are mapped as above. End 1 is End 1 is set to True if the same objects is at End
1 on the RelDef in both the authored and published schema.
Writing an Adapter Header File

The adapter header file provides additional information for the map file used by SmartPlant
Foundation when it is used as a tool.
Example Adapter Header File
The Line List Application adapter header file also includes a ValidLineEndObjects section inside
the Retrieve section.
ToolComponentSchema
UID - This is the name of the authoring (tool) component schema that creates or publishes data.
ToolSchemaMapFile
Name - This is a reference to the corresponding map file, which is used for both the publish and
retrieve mapping. It finds the relevant tool map document using the SPFAuthAdapterCode
property on the tool map document master then it searches for an attached file of this name.
The code to search for is identified on the publish and retrieve methods.
DesignBasisComponentSchema
UID - This is the name of the design basis component schema.
Publish Section of the Adapter Header File

Publish
The publish options are provided for future control of the publish process to use a batch process
to find the documents to publish. For now, the options should be set as shown.
FindToPublish - Set to True to indicate that the publish command should perform the search
for items that need publishing. The search uses the QueryForInterface, looking for objects that
have been updated since they were last published.
BatchPublish - This field will be used in the future to control the batch query for the list of
documents to publish.
ToolBatchPublish - This field will be used in the future to control the batch query for the list of
documents to publish.
QueryForInterface
Name - Used in conjunction with the FrameworkPublish client API. All items in the database that
need to be republished containing the specified interface and SPFAuthPublishableItem are
returned in the Publish dialog box.
ExpandUsingGraph
Name - Used in conjunction with all publish client APIs. This node specifies the graph to run on
single or multiple items selected in order to gather up all related items. For example, in the case
of a process instrument, the process points and process point cases are also included in the
publish file.
DocCategory
Name - To publish an object, an associated document needs to be created in the data
warehouse domain. This is the value of the DocCategory that is assigned to the associated
document.
DocType
Name - To publish an object, an associated document must be created. This is the value of the
DocType that is assigned to the associated document.
DocSubtype
DocSubtype (if required) that is assigned to the associated document.
DocTitle
DocTitle that is assigned to the associated document.
ComponentSchema or PublishToComponentSchema
UID - This is the UID of the target component schema in the data warehouse and is assigned at
the top of the file when the data is published. The node names of ComponentSchema and
PublishToComponentSchema can be used interchangeably. The PublishToComponentSchema
name was introduced for clarity.
DocumentToPublish
AutoCreate - The value of this field is either True or False and is used to determine whether a
dynamic document needs to be generated with relationship to the published items. The setting
depends on how the objects are to be published, and is used to determine how the published
document is inserted into the published data file for creation in the data warehouse.
If the object is to be published through its data sheet (IPD) then this option must be set to True
to dynamically create a document object in the published xml file.
If the object is managed in the authoring environment using a data sheet or data list document, it
is published through the document snapshot and the flag is set to False. The published
document snapshot (XML and view file) is inserted into the published file.
CreateDocRelsWithInterface - The value of this field is used in the adapter to create a
relationship between the newly created dynamic document and items in the publish file that
contain the named interface.
RelDefName - Name of the relationship to be created between the newly created dynamic
document and the item(s). This is typically NonDrawingItemCollection.
DocumentAtEnd - The value of this field is either set to 1 or 2 and indicates that the
relationship definition named above has the document at End1 or End2.
DocTypes/Document
Name - This is a field for reference only to help identify the corresponding UID.
UID - This is the UID of the DocType (or DocSubtype) that was referenced above. This UID is
used in the adapter code GetPublishableDocTypes.
DocClassDef - If a dynamic document is created from the selected item(s), this is the class
definition that it is created as in the data warehouse.
Other tools request the list of publishable document types allowed from the data
warehouse.
Retrieve Section of Adapter Header File

Retrieve
RetrieveViewFile - The value of this field is either set to True or False and is used in the
adapter to set the corresponding SmartPlant Client support feature RetrieveViewFile to the
value specified. If set to True, then the view files attached to the document(s) that have been
selected for retrieve are downloaded along with the corresponding data files.
DocTypes/Document
Name - This is a field for reference only to help identify the corresponding UID.
UID - This is the UID of the DocType (or DocSubtype) that is used in the adapter code
GetRetrieveableDocTypes. The Retrieve dialog box only shows documents that have a
document type or subtype named
DocClassDef - When retrieving, this field is used for reference to make the file more readable.
Other tools make a request to the data warehouse to get the list of retrievable document
types.
OnRetrieve
Action - After a document has been retrieved, this field specifies the action that should take
place after the data has been mapped. The possible options are
 DesignLoad (or Load) - Submits the mapped data directly to the Loader. The document
needs to be modeled in the schema and is identified by its classification in the
DesignBasisClassification.
 DesignBasisLoad - Creates a design basis document and attaches the mapped data, the
delete instructions and any view files to it. The document needs to be modeled in the
schema and is identified by its classification in the DesignBasisClassification.
 DesignBasisLoadAndCompare – Similar to action DesignBasisLoad, but launches the
Compare dialog box with the results.
 Compare – Sends the results directly to the Compare dialog box. The data is not saved; if
the data is not accepted, then a full retrieve operation needs to be performed again.
 Custom – Makes a call to a function called CustomRetrieveData that can be overridden.
DesignBasisClassification - If action DesignBasisLoad or DesignBasisLoadAndCompare is
selected, then the name of the document classification needs to be named. Knowing the
classification, the associated design basis master, revision, and version can then be determined
by expanding from the classification the SPFObjClassClassDef relationship.
FileClassDef - If action DesignBasisLoad or DesignBasisLoadAndCompare is selected, then

the name of the design basis document class definition needs to be specified. If this is not set,
then the default file class definition that is used is the name of the domain and „DesignBasisFile‟
provided that the document has been configured in the schema.
AssignNewUIDs - This option is associated with the compare options above and is used to
determine whether a new UID is assigned when an item is selected in the compare dialog box.
If a new UID is assigned, then a Same As item is also created.
OutputDebugFiles
If this node is added to theXML above a set of files is created in the user's TEMP directory
whenever a publish or retrieve function takes place.
Typically on Publish the following files get created
 Publish_Data_<item name>.xml – Contains the data that has been mapped from the
authoring schema into the publish schema.
 Publish_MetaData_<item name>.xml – Contains the document version and files details of
the published document that is created.
And on Retrieve the typical files would be
 Retrieve_Data_Orig_<Domain>.xml – Original file of the publishing application.
 Retrieve_Data_FilteredOrig_<Domain>.xml - Contains only the objects and relationships
that have been mapped in the format of the publishing application.
 Retrieve_Data_<Domain>.xml - Contains the mapped data as will be sent to the loader or
saved into SmartPlant Foundation authoring
 Retrieve_Tombstone_<Domain>.xml - Contains any instructions that accompany the data
retrieved.
ValidLineEndObjects
For more information, see the ValidLineEndObjects section of the Line List Adapter Document
topic in the How to Configure the Line List Model.
Compare Section of the Adapter Header File

Compare
AssemblyName - In order to allow the compare functions to be overridden, the name of the
compare assembly needs to be named if either the action DesignBasisLoadAndCompare or
Compare is selected. By default, the assembly supplied with SmartPlant Foundation is named
SPFCompare.dll
ClassName - In addition to the assembly name, the class name also needs to be specified in
order for the two compare functions to work. The name needs to be identical to the COM
registration. By default, the class name with SmartPlant Foundation is named
SPFCompare.TEF.Compare.SPFCompareClass
SECTION 6
How to Extend the Integration Schema
CMF File and Physical Pseudo Files

The integration schema is delivered as a CMF file in the SmartPlant Foundation system as a
document in the seed database. In the past, the user was forced to manage all schema
extensions in the single CMF file making it difficult for users to perform concurrent edits and to
update the SmartPlant Foundation database after making small changes. The new process
available in SmartPlant Foundation 2009 R3 SP2 relies on the ability to manage schema
extensions in the CMF file as a set of referenced physical pseudo files.
The CMF file is made up of configuration blocks (ConfigBlock) that contain schema that is
applicable to given configurations (Config) of the schema. A configuration can be used in two
ways; to identify the SmartPlant Foundation version, such as EF_2007_R1_SP6 and
EF_2008_R2, or to segment the schema in to different parts. A configuration used to segment
the schema is referred to as a pseudo file and has IsPseudoFile="True" set in its header at
the top of the CMF file. All ConfigBlocks contain at least one of each type of Config. For
example one is to identify the version of the schema to which it is applicable, and the other a
config in which the actual schema is defined.
To extend the CMF schema using a separate physical file, it is necessary to create a new Config
that is set up with IsPseudoFile="True" and also identified as a physical file. This is done in
the Schema Editor as described in the Pseudo Files and ContainerID Section below.
The delivered CMF file comes with a pseudo file preconfigured for custom extensions called
“Customization,” but this is not set up as a separate physical file. This can be switched to a
separate physical file in the Schema Editor as described in the Pseudo Files and ContainerID
Section below..
Once the schema is created in a separate pseudo file, it is possible to selectively compare and
load this into SmartPlant Foundation. It is very important to understand how the compare
process works using the ContainerID.
Pseudo Files and ContainerID

In order to load the schema into the SmartPlant Foundation database, it is necessary to first
extract a single version schema from the multiversion CMF file, such as the EF_2008_R2
schema. The main CMF file is extracted into a file called SCHEMA_EFSchema-Gen.xml, which
has a ContainerID of Core.EFSchema. When loading this file into SmartPlant Foundation, there
is an option to compare by ContainerID in order to perform deletes on schema items that have
been removed.
When creating a separate physical pseudo file the user has to enter a unique ContainerID for
that file. This can then be used for comparison on load to manage changes to schema modeled
in that pseudo file. The ContainerID is composed of two parts, foldername.filename, so that
when the Export By Container command is used in SmartPlant Foundation, the schema is
exported to the identified subfolder and file name. An example ContainerID might be
ProjectXYX.WorkPackageSchema.
If you move schema between the pseudo files or the CMF file, then you change its
ContainerID, this results in the deletion of schema from your SmartPlant Foundation database if
you also first load the file from which the schema was removed and use the Compare By
ContainerID option. When moving schema between files, Intergraph recommends that you first
load the files without the Compare by ContainerID option so that the schema is not deleted.
This updates the ContainerID on the relevant schema in SmartPlant Foundation, making
Compare by ContainerID possible on subsequent loads.
Opening the CMF file for Editing

Before the schema can be edited, the CMF file has to be checked out.
1. Click Find > Integration > Schema Documents to get a list of the documents.
2. Check out the CMF_Ver document.
3. Launch the Schema Editor, either from the right-click menu of the checked out document or
from the Start menu.
4. On the Set Active Configuration dialog box, click Advanced. The following dialog box
appears:
 The configuration to display is EF_2008_R2 for SmartPlant Foundation 4.x systems.

 Unless the schema is intended for both SmartPlant Foundation 3.x and 4.x, select only
the EF_2008_R2 configuration for new objects.
 Leave the default options in the Applications to be included list.
 Leave Customization as the selected Pseudo file.
5. Click OK.
6. Click View > Schema (Active) > OK on the View Schema dialog box to view the schema.
See the Schema Editor User's Guide for more details.
It is now possible to add a pseudo file, merge in externally generated schema as a pseudo file,
and convert existing pseudo files to physical pseudo files.
Once the separate pseudo file has been created, it is necessary to attach the file to the
CMF_ver document.
Creating a New Pseudo File in the Schema Editor

Creating a new pseudo file is done by creating a new configuration.
1. Click Tools > Schema>Advanced > Create Configuration.
 Enter a new file name in the Name field. This must end in .xml in order to create the
configuration as a physical file.
 Enter a description.
 Do not select a starting configuration; this will make the configuration a primary
configuration rather than a pseudo-file.
 Select the Configuration is pseudo file option.
 Do not enter a path, and the pseudo file will be created in the same folder as the CMF
file.
 Change the automatically generated ContainerID to one that reflects the file's usage.
See notes on ContainerID usage above.
 Click OK.
2. Click Tools > Schema > Set Active Configuration to set up the correct configurations for
new objects, making sure the newly created pseudo file is selected.
3. Click File > Save > Schema File to save the schema files. This saves both the CMF file
with its new configuration header and the newly created physical pseudo file.
An alternative process to set the ContainerID for a newly created pseudo file:
1. Exit the Schema Editor.
2. Edit the newly created file in a text editor and manually set the ContainerID to something
that represents the schema usage (it defaults to a numeric value). This ContainerID is used
to identify schema previously loaded into the SmartPlant Foundation database when
performing the compare during load.
The next time the CMF file is opened, the ContainerID in the header is updated to match the
pseudo file.
The new schema can now be modeled in the Schema Editor, or pasted in to the physical
pseudo file.
Remember to attach the new pseudo file to the CMF_ver document in SmartPlant
Foundation.
Merging a Previously Generated Schema into a Pseudo File

Schema that has been created in a standalone .xml file can be imported from the CMF file into a
new pseudo file using the Merge command.
1. In the Schema Editor, click Tools > Schema > Set Active Configuration to set up the
correct configurations for display and new objects. There is no need to select the pseudo
file. The active configuration in this case is the SmartPlant Foundation configuration.
2. Click Tools > Schema > Advanced > Merge to merge the file into the active configuration.
 Select the .xml file to merge.

 Enter a new file name in the Configuration (pseudo file) name box. This must end in
.xml in order to create the configuration as a physical file.
 Enter a description.
3. Set the ContainerID for the newly created pseudo file as described above.
4. Click File > Save > Schema File to save the schema files.
Converting an Existing Pseudo File into a Physical Pseudo

File
The schema may have already been modeled in the CMF file in a pseudo file such as
Customization. This can be moved into a physical file to make use of the improved schema
loading process.
1. In the Schema Editor, click Tools > Schema > Advanced > Rename Configuration to add
the .xml extension on the name and make it a physical pseudo file.
2. Set the ContainerID for the newly created pseudo file as described above.
3. Click File > Save > Schema File to save the schema files.
Remember to attach the new pseudo file to the CMF_ver document in SPF.
Loading Schema Changes into the SmartPlant

Foundation Database
As described above, the integration schema is managed as a multiversion CMF file and
optionally additional pseudo files in SmartPlant Foundation. In order to load this into SmartPlant
Foundation, the user has to extract the single version schema files to compare and load.
Extracting the Schema Files to Load

Once the schema document is checked into SmartPlant Foundation, click the Launch CMF
File Manager (XML) command on the shortcut menu.
1. Select the files that need extracting. In the example above, only the custom pseudo file is
selected.
2. Select the relevant configuration. For SPF 2009 R3 SP2, it is EF_2008_R3.
 When you click Export, the files are generated at the output path indicated. The method
behind the shortcut menu option has different configuration options for path selection.
 The CMF file exports to SCHEMA_EFSchema-Gen.xml.
 The pseudo files export to SCHEMA_pseudofilename-Gen.xml
 The export process also adds realized relationships on all ClassDefs for the following
interfaces because they are needed in SmartPlant Foundation and are unknown to the
integration schema:
 ISPFTEFPublishedItem
 ISPFClaimableItem
 ISPFClaimedItem
 ISPFTEFClaimedItem
 ISPFTEFClaimableItem
 ISPFMergableItem
 ISPFMergedItem
Loading the Exported Files into SmartPlant Foundation

Use the Schema Import Wizard to load these files into the SmartPlant Foundation database.
For more information, please refer to the How to Set Up and Configure SmartPlant Foundation
guide.
Regenerating New Component Schema Files

The adapters use the component schema files as described above, and these need to be
regenerated after changes have been made to the integration schema. There are commands in
the Schema Editor for regenerating all, or just a selected component schema file.
 If the CMF file has changed, it is recommended you regenerate all the component schemas
because the change may affect many components.
 If a pseudo file has been changed, the change may be localized to one component, in which
case the single component schema can be regenerated.
The schema component file differs from the actual schema file just generated; it is a full
standalone definition of the complete schema including all dependencies, such as the property
definitions and all scoped by Enums and so on.
You can regenerate ALL the component schemas in one of two ways:
 By using the Regenerate Schema Files command on the shortcut menu of the CMF
document in SmartPlant Foundation. This uses the scheduler to regenerate the files and
automatically put them in the delivered location.
 By using the Schema Editor:
 Open the CMF file with the Schema Editor using the same configuration selections as
above.
 Click Tools > Schema > Generate Component Schema.
This creates the component schema files in the same directory as the CMF files. These
need to be moved to replace the delivered files in the Product Directory.
It may be necessary to manually remove any copies of these files from the user's
temp directory.
To regenerate a new component schema file for a single schema component, use the Schema
Editor:
 Open the CMF file with the Schema Editor using the same configuration selections as
above.
 Click Tools > Schema > Generate Component Schema.
This presents a list of component schemas for selection and then creates the new
component schema file in the same directory as the CMF files. This needs to be moved to
replace the delivered files in the Product Directory.
SECTION 7
Published Loader Operation
Overview
The Loader command allows you to process load files in order to add objects and relationships
to the SmartPlant Foundation database. The Loader connects with the data warehouse and acts
as a middle tier between various data sources and the calling program objects. Loader reduces
the number of load programs by reusing the calling program objects directly. Each authoring tool
loads different document types and associated data into SmartPlant Foundation to allow the
exchange of data between the various authoring tools, avoiding the duplication of data for each
tool.
Supporting an Object Change of ClassDef

SmartPlant Foundation changes the ClassDef of an object by the schema component
generating an UpdateClassinstruction during a load. This update class instruction is then
included in the tombstone file of a set of publish files and subsequently loaded into SmartPlant
Foundation.
The UpdateClassInstruction tells SmartPlant Foundation that the ClassDef of a previously
published object has been changed by an authoring tool to a different ClassDef, such as when a
user changes a piece of equipment in a system to a different but similar type of equipment.
SmartPlant Foundation handles this change automatically, by finding the previously published
object and merging all valid interfaces and properties from the existing object onto the new
object. Any interfaces or properties that are no longer valid are discarded. Simultaneously
SmartPlant Foundation removes any existing relationships which rely on the discarded
interfaces. The previous object is then replaced by the new version with the new ClassDef as
specified on the UpdateClassInstruction.
For example, in SmartPlant Piping and Instrumentation Diagram, an engineer may need to
change an PIDInstrument to an PIDInlineInstrument.This type of change might occur because
the engineer needs to alter an element of a design during the design phase of a plant, and the
design needs to reflect the change on a drawing even though the drawing might have already
been published.
Following a successful publish, the selected object will have had its ClassDef changed. The user
also sees displayed any appropriate interfaces and properties that have been brought forward
onto the new object.
Plant Breakdown Structure for Integration Setup
Workflow
The update of the ClassDef of an object workflow is as follows:
1. The user creates an object in an authoring tool, for example named Object1.
2. The authoring tool updates Object1 with a ClassDef of ClassA.
3. The tool publishes Object1 into SmartPlant Foundation with a ClassDef of ClassA.
4. A SharedObject is created in SmartPlant Foundation to represent the tool object.
5. The user then updates the tool version of Object1 with a different Classdef, ClassB.
6. The tool then re-publishes Object1 with a new ClassDef of ClassB into SmartPlant
Foundation.
7. Upon publishing, the schema component determines that the classification of the object has
changed and generates an UpdateClassInstruction.
8. SmartPlant Foundation loads the new version of Object1 and detects the
UpdateClassInstruction.
9. SmartPlant Foundation updates the ClassDef of Object1 and updates the SharedObject
with the new Classdef, ClassB.
Example of the UpdateClassInstruction

<UpdateClassInstruction>
<IObject UID="UpdateClass_41B17408FC414AB8A6E47ABF2A714A4C" />
<IRefObject RefClass="PIDInlineInstrument"
RefUID="41B17408FC414AB8A6E47ABF2A714A4C" RefName="Test PID Inline
Instrument"/>
<IPropValues PropValues="IObject\%Name\%Test
PIDInstrument\%IObject\%Description\%This is now a PIDInstrument"
AddedInterfaces=""/>
<IUpdateClassInstruction NewClass="PIDInstrument"/>
<IUpdateInstruction/>
<IInstruction/>
</UpdateClassInstruction>
Plant Breakdown Structure for

Integration Setup
In an integrated environment, engineering data is organized using a plant breakdown structure
(PBS). A plant breakdown structure is a hierarchy by which your plant is organized. For
example, a PBS for organizing plant data might be plant/area/system/subsystem or
plant/area/unit.
The PBS hierarchy defined in the SmartPlant schema is used to create the PBS hierarchy in
SmartPlant Foundation. This hierarchy is communicated to integrated authoring tools when
SmartPlant Foundation publishes the plant breakdown structure and the tools retrieve it.
In versions prior to 2007, the plant breakdown structure for integrated authoring tools was
restricted to plant/area/unit. By default, the PBS for integration is still plant/area/unit in the
schema. However, you can use the Schema Editor to configure the default hierarchy in the
schema to meet your needs.
See Also
Work Process for Creating a Custom PBS Hierarchy (on page 72)
Define the Plant Breakdown Structure (PBS) Hierarchy in the Schema (on page 92)
Integration Hierarchy Limitations

The integrated environment imposes the following limitations on custom hierarchies, based on
requirements from the authoring tools. This list includes the tool imposing each restriction, so
that customers can factor these limitations into their hierarchy setup based on their current and
future tool usage.
 The hierarchy must have a minimum of 3 levels. This limitation is imposed by SmartPlant
Instrumentation.
 The names of hierarchy items cannot be changed once created. This limitation is imposed
by SmartPlant Foundation.
 The hierarchy scheme cannot be modified after the plant is created. This limitation is
imposed by SmartPlant P&ID and SmartPlant Foundation.
 If using a unit in the hierarchy, the unit number must be unique. Unit names can be
duplicated across the hierarchy. This limitation is imposed by SmartPlant Instrumentation.
See Also
Define the Plant Breakdown Structure (PBS) Hierarchy in the Schema (on page 92)
Work Process for Creating a Custom PBS Hierarchy (on page 72)
Plant Naming Guidelines

Use the following guidelines when naming your plant, or top-level hierarchy items, which will be
used in an integrated environment. These limitations are imposed by the authoring tools and the
database software. For these guidelines, "plant" is used as an example of a top-level hierarchy
item.
 Do not use special characters at all in any part of a plant name or plant breakdown structure
such as area or unit. These include ~ . + - = _ ! ? ' " , ; : & % @ # ^ * < > ( ) | [ ] {} / \.
 A warning message that the characters are invalid is displayed if you use any special
characters.
 The plant name is case-sensitive and cannot exceed 20 characters.
 The plant name must be unique within the current domain. This limitation is imposed by
SmartPlant Instrumentation.
 Intergraph recommends that the SmartPlant Instrumentation domain schema name and
domain name match the plant name.
 Intergraph recommends that the plant name be the same name across all authoring
tools.
 You can use digits and spaces within the body of the plant name, for example Plant _1.
However, SmartPlant Foundation treats spaces exactly the same as underscores; so if
you name a new plant with a name that already exists, but use a space or an
underscore to differentiate, an error message will state it is already in existence. For
example Plant 1 and Plant_1 are treated as being exactly the same.
If you enter a space as the first character of your plant, area, or unit name, SmartPlant
Foundation allows you to register the plant. However, when you publish the Plant Breakdown
Structure (PBS), an error message is displayed. See SmartPlant Foundation Troubleshooting
Guide for further information.
Work Process for Creating a Custom PBS Hierarchy

The following describes the process for defining a custom PBS hierarchy for integration:
 If your current database contains an existing PBS hierarchy, remove the existing PBS
structure from the database, update the existing plants in the database, and remove the
existing PBSHierarchy graph definitions for SmartPlant Foundation authoring before creating
your custom PBS hierarchy. These changes are made by running load files delivered with
SmartPlant Foundation.
 Check out the SmartPlant schema CMF file from the SmartPlant Foundation Desktop Client.
 Right-click the new revision of the CMF file in SmartPlant Foundation, and click Launch
Schema Editor. This provides the Schema Editor with the appropriate plant and SmartPlant
Foundation site for connection.
 Select the schema version or versions that you want to view in the Specify configurations
to display window of the Active Configurations dialog box.
 Click the Advanced button on the Active Configurations dialog box to view the Set
Configurations for new objects window, where you can specify what version or versions of
the schema changes should be written to. For example, to modify the 2008 schema, select
the 2008 configuration for new objects.
By default, both the 2007 and 2008 configurations are checked to allow forward and
backward compatibility between schema versions when creating new objects or modifying
existing objects.
 Define the hierarchy in the schema using a template in the Schema Editor.
If you want to define the hierarchy without using a template, see Define the Plant
Breakdown Structure (PBS) Hierarchy in the Schema (on page 92).
 Check the CMF file back into SmartPlant Foundation.
 Prepare the updated SmartPlant schema CMF file to be loaded into SmartPlant Foundation
data warehouse database.
 Load the updated schema file into the SmartPlant Foundation data warehouse database.
 Generate SmartPlant Foundation authoring PBS configuration.
 Generate a new SmartPlant Foundation PBS authoring component schema.
 Generate a new SmartPlant Foundation PBS authoring tool map schema.
 Generate PBS methods, menus and forms.
 Load the generated files into SmartPlant Foundation to load administration and schema data
and generate forms and menus.
 Check out the existing PBS authoring adapter tool map schema and check in the PBS
authoring tool map schema that was generated.
 Create a new plant.
Be sure not to create the plant until you complete all the previous steps in the
work process.
 Create a host and vault and add the necessary publish interfaces needed for the vault.
 Relate the new plant to a vault configured for integration.
See Also
Plant Breakdown Structure for Integration Setup (on page 70)
Remove the Existing PBS Structure

If you are starting from a database that already contains the PBS structure, such as spf42adw
(the delivered database for integration), you must remove the PBS structure before you can
create a custom hierarchy. To remove the existing PBS structure from the spf42adw database,
you can use files delivered by default with SmartPlant Foundation. The files are located in the
<SmartPlant Foundation Installation Location>\Samples\SampleData directory in the
AlternativePBS\AdwDatabaseWithPBS folder.
The RemoveExistingPBS.xmlldr file in this directory references all the scripts that are required to
remove the existing PBS.
Make sure the Query Scope is not defined before running the load files.
You may need to edit the paths to the scripts in the RemoveExistingPBS.xmlldr file
before you run it.
1. To remove the PBS, run RemoveExistingPBS.xmlldr in the Desktop Client loader. When
you load the file, the following scripts are loaded and run in the correct order:
 01-ADMIN_Remove_AreaAndUnit.xml
 02-DATA_Remove_AreasAndUnits.xml
 03-DATA_Remove_ProjectsAndPlants.xml
 04-SCHEMA_Remove_AreaAndUnit.xml
 05-SCHEMA_Remove_PlantExpansionDefaultGraphDef.xml
 06-SCHEMA_Remove_PBSGraphDefs.xml
2. If you receive the following message that the plant you are removing cannot be found, click
OK.
3. Process the load files again.
4. Click the Query Scope on the Desktop Client status bar to validate that the plant(s) have
been removed.
5. After you load the files, log out of the Desktop Client, and recycle the Application Pools. For
more information on recycling the Application Pools, see the Recycling the Application
Pools section of Server Settings for SmartPlant Foundation Desktop Client in the Integration
Setup Guide.
Check Out the SmartPlant Schema CMF File

1. Log in to the Desktop Client.
2. Click Find > Integration > Schema Documents.
You must be logged on to the SmartPlant Foundation data warehouse
database and have a schema administrator role to be able to access commands on the
Integration menu.
3. In the Enter Name box, type CMF*, and click OK.
4. Right-click the CMF_Ver document, then click Edit > Check Out on the shortcut menu.
5. Browse to the location to which you want to check out the file. The default location is the My
Documents folder.
6. Click OK.
7. Open the Schema Editor from the Start menu.
8. Click File > Open > Starting File.
9. Browse to the .cmf file that you saved to your local machine.
10. On the Set Active Configurations dialog box, select the schema version to which you will
apply changes. For example to apply changes to the 2008 version only, click EF_2008.
11. Click OK.
Define the Plant Breakdown Structure (PBS) Hierarchy from

a Template
If you do not want to define the PBS structure from an existing template, but would rather
create a custom PBS hierarchy, see Define the Plant Breakdown Structure (PBS) Hierarchy in
the Schema (on page 92).
1. After you check out the schema CMF file from the Desktop Client and launch the Schema
Editor, click Tools > Schema > Set PBS Hierarchy.
You can also click the Schema File button in the Workflows dialog box, and then click
Set PBS Hierarchy on the shortcut menu.
2. Click Set from PBS Template.
3. Select a PBS Template from the drop down menu in the Select PBS Template dialog box,
and click OK.
The PBS hierarchy populates automatically in the Define PBS Hierarchy dialog box.
The Hierarchy2 through Hierarchy7 PBS templates match the delivered templates
available in SmartPlant Engineering Manager and SmartPlant Electrical.
4. Click OK to save the new hierarchy.

5. In the Identify Configurations for Instructions dialog box, select the configuration or
configurations to which you want to apply the PBS changes. For example, if you want the
PBS structure to apply to both the 2007 and 2008 versions, select EF_2007 and EF_2008.
6. Click OK.
7. Click File > Save > Schema File to save your changes to the SmartPlant schema.
8. Close the Schema Editor.
9. After you make changes in the schema, you must load the updated schema into the
SmartPlant Foundation database. See Load Schema Changes into the SmartPlant
Foundation Database.
Check In the CMF file

After you modify the alternate PBS structure, check the CMF file back into SmartPlant
Foundation. This operation currently compresses the file and checks the compressed file into
the database.
Prepare the CMF Data to be Loaded into SmartPlant

Foundation
1. In the Desktop Client find the configuration file (CMF_ver). To find the CMF file, click Find
> Integration > Schema Documents.
2. Right-click the new version of the .cmf file and select Launch CMF File Manager (XML).
3. Select the CMF from the Input file list.

4. For SmartPlant Foundation 2009 or higher, verify that EF_2008_R5 is selected in the CMF
list under Available configurations.
5. Click Export to prepare the data to be loaded into SmartPlant Foundation.
By default the output directory is the My Documents folder for the current user.
Load the CMF Data Changes into the Data Warehouse

Database
1. In the Desktop Client, click Administration > Schema Import Wizard.
2. In the Schema Import Wizard, select Compare content of selected file against all
database items with a matching container ID.
3. Under Select external schema file, browse to SCHEMA_EFSchema-Gen.xml in the
directory where the software created the CMF files you prepared to be loaded. For more
information, see Prepare the CMF Data to be Loaded into SmartPlant Foundation (on page
77).
4. Click Next.
Schema Import Wizard compares the generated schema with the SmartPlant Foundation
database and displays the results. This process can take about 10 minutes.
5. Under Comparison Results, select all the items, and then click Next.
If the items were all successfully loaded, the status in the Load State column is set to
Loaded. If not, the status if either Passed or Failed.
6. Click Finish.
Generate Component Schema Files

1. In the Desktop Client, right-click the CMF file you edited.
2. On the shortcut menu, click Regenerate Schema Files.
This command automates the process of generating the PBS structure component
schema files by creating a scheduler task that calls the Schema Editor through the API.
3. Make sure that the scheduler is started so that the component schema files can be
generated.
The command generated the SmartPlant component schemas and tool metadata. These
files are located at the path you defined for your site.
This process can take several minutes.
Generate SmartPlant Foundation Authoring PBS

Configuration
This procedure generates the PBS authoring component schema and a new PBS authoring tool
map schema. In addition, this step creates new PBS methods and menus.
1. To create a tool (or authoring) schema, find the CMF you modified in the Desktop Client
(Find > Integration > Schema Documents).
2. Right-click the CMF file version (CMF_Ver), and click Launch CMF File manager (PBS).
The component schema and prefix are populated from the associated method.
3. Select the Combined Authoring and DW database option.
4. Click Load.
One node should appear in the tree view.

5. Expand the PBSComponent node.
6. Make sure the Inherit Clicked Item option is selected.
7. Select PBSComponent to export all items.
You can unselect items that are not needed for export, but always include
PBSComponent and PBSDocument.
8. Click Export.
This operation generates the schema, some basic SmartPlant Foundation administration
operations, and a tool schema with mappings to the SmartPlant schema. This information is
contained within 7 files in the output directory.
File Name Description Comments

SPF_01_AuthoringSchema.xml SmartPlant This contains the
Foundation PBS sub-schema for the new
authoring PBS hierarchy
schema
SPF_02_AuthAdminData.xml New PBS This file holds the methods
Methods and and menus configuration
Menus (used to display your new
item in the authoring
environment).
SPF_03_AuthFormInstruction.xml PBS Form The instructions to
Instructions generate forms for newly
generated objects.
File Name Description Comments

SPF_04_DWAdminData.xml Data Optional - only required if
Warehouse you want to see the data
Methods and as it is loaded in the data
Menus warehouse
SPF_05_DWFormInstruction.xml Data Optional - only required if
Warehouse you want to see the data
Form as it is loaded in the data
Instructions warehouse
SPF_SelectedItems.xml Copy of Do not load - contains the
Selected Items classes selected that form
the new hierarchy. You can
use this file to see what
classes were selected
when the export was done.
ToolMapSchema_SPF.xml New PBS Tool Do not load - contains the
Map Schema classes selected that form
the new hierarchy. You can
use this file to see what
classes were selected
when the export was done.
9. Close the CMF File Manager dialog box.
Load New Schema Files for the Alternate PBS

Load the New Schema
 In the Desktop Client, click File > Loader select the SPF_01_AuthoringSchema.xml file.
Load the AdminData.xml File

 Click File > Loader and select the SPF_02_AdminData.xml file.
Generate Forms
 Load the SPF_03_AuthFormInstruction.xml file, and click Process. This will generate all
forms defined under the component schema.
Update Access Group for the New PBS Graph Definition

The Schema Editor automatically generates a graph Def called DGD_PBSHeirarchy; the change
will be loaded with the Schema Import Wizard.
A few updates need to be made to the PBSHierarchy graph def. These changes are made when
you load the UpdatePBSHierarchyGraphDef.xmlldr file delivered in the <SmartPlant
Foundation Installation Location>\Samples\SampleData\AlternativePBS folder. This file
references the scripts that will make the necessary updates to the PBSHeirarchy graph def.
Use the Desktop Client Loader to open and load this file. The scripts below are loaded and run
in the correct order:
 01-ADMIN_Update_PBSHierarchy.xml
 02- SCHEMA_Update_PBSHierarchy.xml
Attach the New Tool Schema

1. To attach the new Tool Schema, find the existing tool schema PBS tool map schema in
SmartPlant Foundation by selecting Find > Adapter Documents, type PBS Map Schema,
and click OK.
2. Check out the PBS Map Schema file.
3. Replace the checked out document (ToolMapSchema_PBS.xml) with the newly-generated
map schema ToolMapSchema_SPF.xml (Rename and replace).
4. Check in the new PBS Map Schema file.
5. Log out of Desktop Client.
Add the PBS to SmartPlant Foundation and Test

Create a Host and Organization
1. Log into the Desktop Client.
2. Click File > New > Administration > Host.
The host is the node name of your SmartPlant Foundation server.
3. Modify Intergraph organization.
 Find > Organization / Support Items > All Organizations.
 Right-click Intergraph, then click Update.
 Select the host you created from the File server host list.
Create a Vault
1. Click File > New > Administration > Vault in the Desktop Client.
2. Type a name and description for the vault.
3. In the Local path box, type the file location where you want the vault to be stored on the
SmartPlant Foundation server.
You must create the folder structure for your vault on the SmartPlant Foundation
server.
4. In the Sub directory property or name box, type
Obj->SPFFileComposition_12->SPFRevisionVersions_21->SPFDocumentRevisions_21.SP
FDocType. This property stores your published and non-published documents based on
document type.
5. In the Host list, select the host you created.
Do not set to local host.
6. Relate ISPFTEFPublishedDocVersion to the vault.
 Click Find > Schema > Interface Definition. In the Find box, type
ISPFTEFPublishedDocVersion.
 Drag the vault you created on to ISPFTEFPublishedDocVersion.
7. Relate ISPFNonPublishedDocVersion to the vault.
 Click Find > Schema > Interface Definition. In the Find box, type
ISPFNonPublishedDocVersion.
 Drag the vault you created on to ISPFNonPublishedDocVersion.
8. Relate the Owning Group to the vault.
 Click Find > Administration > Vault to find the vault you created. Press CTRL and
drag the vault to the New Items window.
 Click Find > Administration > Owning Group.

 Drag the ADMIN owning group on to the vault.
9. Log out of the Desktop Client.
Create a Plant
1. Log into the Desktop Client.
2. Click File > New > Organization / Support Items > Plant.
3. Type the name of your plant based on the guidelines in Plant Naming Guidelines (on page
71).
4. In the Status list, select Active.
5. Relate the vault to the plant.
6. Click Find > Administration > Vault to find the vault you created.
7. Drag the vault to the plant in the tree view.
8. You must define role assignments for the new configuration.
Create and Attach Icons

1. To change the icons for your PBS structure, do one of the following:
 Create new icons.
 Create a copy of the icons delivered with SmartPlant Foundation and rename them with
the name of the new PBS classes. Sample icons are located in the Product Directory.
2. Place your icons in the Product Directory.
Icons must be in .gif format.
3. Click Query Scope on the Desktop Client status bar and select the new plant.
Create a Unit
1. Click File > New > Organization / Support Items > Unit.
2. Type the name of your unit.
3. Pick the Plant created in the previous step.
4. Select New for Construction status.
Create a System
1. Click File > New > Organization / Support Items > System.
2. Type the name of your system.
3. Pick the Unit created in the previous step.
Create a Sub System

1. Click File > New > Organization / Support Items > Sub System.
2. Type the name of your sub system
3. Pick the System created in the previous step.
5. The customized PBS structure is created.
Testing
1. Click SmartPlant > PBS > Register.
2. Test the create, update and view functions of each item in the new structure.
3. Test the publish function.
 Right-click the plant, then click Publish PBS.
Remember the PBS needs to be registered, and the Process Engineer needs to be
associated to the SmartPlantPublish and SmartPlantRetrieve roles defined in the database.
The new PBS is now ready to be retrieved by the authoring tools.
Include Plants in a Configuration

The query and create configurations are set in the Set Active Scope dialog box. Plants that are
active are displayed in this dialog box.
To activate a plant that has a status of Created, find the plant in the Desktop Client (Find >
Organization / Support Items), right-click the plant, and click Activate configuration.
Work Process for Creating or Modifying a PBS

Hierarchy Template
The following describes the process for creating a custom PBS hierarchy template for
integration.
 Check out the SmartPlant schema CMF file from the SmartPlant Foundation Desktop Client.
 Right-click the new revision of the CMF file in SmartPlant Foundation, and click Launch
Schema Editor. This provides the Schema Editor with the appropriate plant and SmartPlant
Foundation site for connection.
 Select the schema version or versions that you want to view in the Specify configurations
to display window of the Active Configurations dialog box.
 Click the Advanced button on the Active Configurations dialog box to view the Set
Configurations for new objects window, where you can specify what version or versions of
the schema changes should be written to. For example, to modify the 2008 schema, select
the 2008 configuration for new objects.
By default, both the 2007 and 2008 configurations are checked to allow forward and
backward compatibility between schema versions when creating new objects or modifying
existing objects.
 Create the PBS hierarchy template using the Schema Editor.
 Create any plant groups using the Schema Editor.
 Check the CMF file back into SmartPlant Foundation.
Create a New PBS Template

Editor, click Tools > Schema > Define PBS Templates.
2. Right-click Templates in the Define PBS Templates dialog box, and click Create New PBS
Template.
3. Enter a name, display name, and description for the PBS template in the appropriate fields.
4. Right-click Plant under the Template name you created, and click Add group to <Template
Name> hierarchy after Plant.
You can rename the Plant group by selecting Plant, and clicking it a second time.
5. Select a plant group from the Select Group to Add to Hierarchy dialog box, and click OK.
For example, select FunctionalArea, and click OK.
6. Add the PlantSystem and Level plant groups under FunctionalArea.
7. Click OK to save the hierarchy template.
Create a New Plant Group

Editor, click Tools > Schema > Define PBS Templates.
2. Right-click Plant Groups in the Define PBS Templates dialog box, and click Create New
Plant Group.
3. Enter a name, display name, and description for the plant group in the appropriate fields of
the Create Plant Group dialog box.
Click Edit Properties to add ExposedPropertyDefs to the plant group.
4. Click OK.
Edit the Plant Breakdown Structure (PBS) Hierarchy

Template
Editor, click Tools > Schema > Edit PBS Templates.
Edit PBS Templates on the shortcut menu.
2. Right-click a hierarchy template and select Edit <Hierarchy Name>. For example,
right-click Hierarchy2 and select Edit Hierarchy2.
3. Make changes as necessary to the PBS template Display name, Description, and Plant
display name in the Overview tab of the Edit PBS Template Definition dialog box.
4. Edit the PBS template properties on the Properties tab. You can edit the Category,
Description, Display Name, Schema Revision/Version, Help Context ID, Needs Further
Analysis, Analysis Comment, and By Customer fields on this tab.
5. Click OK to save the template.

6. Click OK to close the Define PBS Templates dialog box.
9. Click OK.
After you make changes in the schema, you must load the updated schema into the
SmartPlant Foundation database. See Load Schema Changes into the SmartPlant Foundation
Database.
Intergraph recommends you create the PBS hierarchy from a template. This workflow is
optional and should only be used if you intend to create a PBS hierarchy without using a
template. For more information on creating a PBS hierarchy from a template, see Define the
Plant Breakdown Structure (PBS) Hierarchy from a Template (on page 75).
Editor, click Tools > Schema > Set PBS Hierarchy.
Set PBS Hierarchy on the shortcut menu.
2. If you do not want to use the default PBS items in your hierarchy, click Delete Bottom
Relationship to delete the PBS items and relationships from the bottom up.
You cannot delete the Plant item at the top of the hierarchy. In the schema, the
top-level item in the PBS is always a plant. However, you can change the display name for
the plant.
3. To change the display name for the plant, type the new name in the text box in the Display
name column.
4. To define additional PBS items, click Create.

5. In the Create PBS Item dialog box, define the name and display name. The software
automatically builds the relationship name to the parent item in the hierarchy.
 Because plant is always the top-level class definition in PBS hierarchy in the schema
even if you change its display name, you cannot use "Plant" as the name of another
object in the PBS hierarchy.
 The recommended naming convention for the relationship between an item and its
parent is <Parent><Item>s, for example, SitePlants. However, you can name this
relationship any name that you want.
 PBSHierarchy DirectedGraphDef is automatically created when you create the PBS
hierarchy.
6. Click OK.
7. Repeat steps 4-6 for each additional item that you want to add to the PBS hierarchy.
 Your PBS hierarchy must include at least 3 levels.
 PBS hierarchy cannot be changed after it is created in the SmartPlant Foundation client.
8. Click OK to save the new hierarchy.
9. In the Identify Configurations for Instructions dialog box, select the configuration or
configurations to which you want to apply the PBS changes. For example, if you want the
PBS structure to apply to both the 2007 and 2008 versions, select EF_2007 and EF_2008.
10. Click OK.

After you make changes in the schema, you must load the updated schema into the
SmartPlant Foundation database. See Load Schema Changes into the SmartPlant Foundation
Database.
SECTION 8
How to Configure Excel Publish

This section describes in detail how to use Excel to publish data into the SmartPlant Foundation
data warehouse.
The How to Setup and Configure SmartPlant Foundation guide details how to configure
SmartPlant Foundation to load data in from Excel and the How to Configure the Data Sheet
Model guide details how to create and configure the data list definition and Excel template that
are needed to support this process.
Steps to Configure the Excel Publish

Published Schema Definition
Create the publish schema for the items and document to be published. See How to Configure
SmartPlant Foundation Authoring (on page 101).
 Make sure the objects being published have a unique interface.

 Re-use as much of the SmartPlant Schema interfaces as possible as this makes mapping
much easier.
 The object ClassDef must realize the interfaces ISPFTEFPublishedItem and
INonDrawingItem.
 The model definition for the object ClassDef should be PlannedMaterialModel.
 If the published data is to be correlated with data published from other tools then the
ClassDef needs to be related to a shared object definition (for example,
SharedEquipment_PM).
 The published document ClassDef should realize the IDocument, IDocumentVersion,
IDocumentRevision, IDocVersionComposition, INonDrawingItem and
ISPFTEFPublishedItem interfaces.
 The model definition for the document ClassDef should be WorkBreakDownModel.
 The objects are related to the published document via the NonDrawingItemCollection
RelDef via the INonDrawingItem interface.
ViewDef Creation
Create a GraphDef and ViewDef to access all the properties and relationships that are to be
published. This should start on a unique interface of the objects being published, to include
relationships to PBS items, etc. It should also include the typing properties for the objects on the
IEquipment interface, of which 4 levels are usually sufficient.
To test the ViewDef, after it has been loaded in to SmartPlant Foundation, relate a Message
Access Group to it and run a new ad hoc report. This returns any objects of this ClassDef that
have already been published to this domain.
Excel Template Document Creation

Create an Excel template document with an Excel File that contains columns, etc., for the data
to be loaded.
Create the template document in SmartPlant Foundation and attach the file.
Datasheet Definition Creation

The datasheet definition object ties together the ViewDef, template document and ClassDef of
the object to be created in the published domain.
Create a datasheet definition object just like you would for the Excel Load but add additional
information to control the publish process.
Datasheet definition details:
 Enter the datasheet type (for example, EquipmentList). This is a free entry field to assist in
classifying the different datasheet definitions.
 Select the ViewDef modeled earlier.
 Select the Template document just checked in.
 Select the target class definition for the objects to be created.
Excel publish settings:
 Enter the document title (will be set on all published documents using this template).
 Enter the published document category (for example, Process Documents).
 Enter the published document type (for example, Process Published Documents).
 Enter the published document sub-type if needed.
 Enter the ClassDef of the published document mentioned above.
 Enter the details of the relationships to be created between the published objects and the
published document.
 The format is ObjectInterface,RelDef_21/12.
 The object interface is a unique interface on the published objects.
 The RelDef is that between the published objects and the published document in the
direction from the document to the object. Usually this will be
NonDrawingItemCollction_21.
Now that the data list definition links the ViewDef to the template document, you can map the
ViewDef properties to the cells in the Excel template.
Map the ViewDef to the Excel Template

This is done using Data Sheet Definer as detailed in the How to Configure the Data Sheet Model
guide.
1. Check out the file and run Data Sheet Definer to map the properties of the ViewDef to the
header cells in the Excel sheet.
Note that you must identify an end of table cell, usually well down the sheet in column
A. This is done by selecting the End Table option below the Name in the right pane of the
data sheet definer GUI.
2. Save the spreadsheet and check in the template document.
Configure a Publish Method

In order to publish a spreadsheet, a method has to be exposed as a menu option. There is a
default method provided called ExcelPublish that is available under the SmartPlant menu. This
presents a GUI to select the Excel file to load and the Template document to use with it. It also
automatically registers the Excel Publish tool with the data warehouse against the active
configuration.
This method, or similar methods, can be configured for each template by specifying the template
document name on the method instead of using the option to select it in the GUI. Refer to the to
the Setup and Configure SmartPlant Foundation guide for more details on setting up the
method.
One of the differences between the Excel Publish and Excel Load is the need to first register the
tool with the data warehouse before publishing. This is exactly the same as registering the
authoring environment before publishing. To make it easier, there is an option on the
ExcelPublish API to auto register at the same time if not already registered.
With auto register selected the registration is made as follows:
 Using the current server URL.
 Using the current logged in user.
 Registering to the current configuration (plant).
 Registering to the domain in which the target ClassDef will be stored.
 The Tool Adapter Prog ID needs to be specified on the method as you would do in the
register method. This should be set to SPFAdapter.TEF.Adapters.ExcelAdapter.
The alternative is to unselect the option to not automatically register the tool and create a
separate registration method as described in Configuring Publish for Authored Data (on page
122). The Tool Adapter Prog ID should be set to SPFAdapter.TEF.Adapters.ExcelAdapter.
SECTION 9
How to Configure SmartPlant

Foundation Authoring
This section describes in detail how to exchange data with the SmartPlant Foundation data
warehouse. Details of the data model are covered in the previous sections of this document.
For the purpose of illustration, this section describes how to configure a simple equipment list in
SmartPlant Foundation that can work with data retrieved from SmartPlant P&ID, imported by
Excel, or created directly in the SmartPlant Foundation authoring environment, and then publish
that data to the data warehouse. This entails defining domains, the data warehouse and
authoring schema, the mapping between them, the equipment list display and editing, the
retrieve, load and publish, and configuring the roles for the users.
As already described previously in this document, there are two ways to publish authored data,
by either creating the publish document dynamically from a data sheet or data list, or by
modeling up a document to manage the approval and publish of the data. The advantage of
modeling up a document is that the snapshot functionality enables engineers to create the
publish, and view files for review before publishing and to know that the data published was then
reviewed even if for some reason the actual authored data items have been updated in the
meantime. The document is also revisable, so providing controlled updates to the related data
by conditions that check the status of the related document and only allow updates when it is
working, is one example.
There are two common ways to author lists of data in SmartPlant Foundation. One is to create a
list object in between the document and the list items and the other is to relate the items directly
to the document.
The following diagram shows a typical structure for using a list object to manage editing related
data and a document to control the approval and publish process. This can be used to assist
with authoring and also when there is a need to integrate the list object itself as in the
SmartPlant Foundation line list application. The equipment is related to the equipment list
document through the equipment list object.
The following diagram shows a typical structure for when the document is also acting as the list
control object and the data items are related to the document revision. The document is the
container for the data and is used to manage the list editing as well as the publish.
The published schema includes a published document and a published equipment item. When a
SmartPlant Foundation publishable document is created in the authoring environment, a shared
How to Configure SmartPlant Foundation Authoring
document is also created in the data warehouse shared domain. When the document is
published, it is created in the publish domain and linked to the shared document. The diagram
below shows a typical configuration for a simple published equipment list and how they are
related.
Defining the Data Warehouse Schema

Before you can author anything, you must define the schema for what you intend to create and
publish to the data warehouse. It is best to create the data warehouse schema first as this will
most likely share many of the existing SmartPlant schema interfaces. For example, if you want
to share data between the tools and see inconsistencies in data, the same interfaces and
properties are used by all the tools, such as IHeatTracedItem. Most major published items are
typed, so typically equipment classes should realize the IEquipment interface.
Every published item must have a certain minimum set of interfaces:
INonDrawingItem To relate the published items to the
published document with the
NonDrawingItemCollection RelDef.
ISPFTEFPublishedItem To relate the published item to the shared
object via the SPFTEFComprisedOf RelDef.
This interface is not part of the base
integration schema and is not part of the
published schema in the .cmf file but is
needed within the SmartPlant Foundation
database. It is left off initially and is added
automatically by the schema extraction
process described in Extracting the Schema
Files to Load (on page 66) .
IPBSItem Usually realized to support the relationship to
the PBS tree.
When any item is published, it must be associated to a document object. It is necessary to
model a published SmartPlant integration document in the published schema component.
For example, PpmPPDocument realizes the following interfaces:

IDocVersionComposition
IDocument
INonDrawingDocument
INonDrawingItemCollection To relate the published items to the
published document via the
NonDrawingItemCollection RelDef.
IObject
IPpmDocument
IPpmPPDocument
IReferencedDocumentCollection
ISPFTEFPublishedItem To link this via the SPFTEFComprisedOf
RelDef to the shared document
(SPFTEFPublishedMaster). This is not part
of the published schema in the .cmf file but is
added before loading into SmartPlant
Foundation as described above.
The document category and type for this document are identified in the adapter header file. If a
new category and type are required, then this needs to be added into the document category
Enum hierarchy. For example, Process Published Document under Process Documents
(UID=EE73). A sample schema to create this is provided below:
<EnumEnum>
<IObject UID="e1PpmPPDocument" Name=" Process Published Document "
Description="Process Published Document"/>
<IEnumEnum/>
<ISchemaObj/>
</EnumEnum>
<Rel>
<IObject UID="EE73.e1PpmPPDocument"/>
<IRel UID1="EE73" UID2="e1PpmPPDocument" DefUID="Contains"
IsRequired="True" OrderValue="0"/>
<ISchemaObj/>
</Rel>
Shared Object Configuration for Data Mining

The shared object can be "typed" by configuring optional interfaces on it that are instantiated
depending on the interfaces on the published objects. These interfaces can then be used on
QFind methods to provide menu options for finding published data of different types.
The recommended model for the shared object is:
ClassDef SPFTEFSharedObject
Required Interfaces ISPFTEFSharedObject,
ISPFTEFPublishedObjectCollection, IObject
Optional Interfaces ISPFTEFSharedEquipment and
ISPFTEFSharedInstrument and then extended
depending on the customer requirements
The optional interfaces on the shared object are used for quick find only, and the details about
the object are stored on the associated published items. When viewing objects in the data
warehouse, they are dynamically consolidated to display the latest values of the published data
that is associated to the shared object.
The optional interfaces instantiated as published objects are loaded based on a relationship
between an interface on the published object and the shared object. The relationship definition
to control the creation of optional interfaces is SPFTEFSharedMappedInterface.
For the equipment list, no new interface is added to the shared object. The following optional
interfaces are already on the shared object:
ISPFTEFSharedArea Shared Area
ISPFTEFSharedEquipment Shared Equipment
ISPFTEFSharedInstrument Shared Instrument
ISPFTEFSharedPipeRun Shared Pipe Run
ISPFTEFSharedPipeline Shared Pipeline
ISPFTEFSharedPipingComponent Shared piping component
ISPFTEFSharedPlant Shared Plant
ISPFTEFSharedProcessCaseData Shared Process Case Data
ISPFTEFSharedSimulatedFacility Shared Simulated Facility
ISPFTEFSharedSimulationModel Shared Simulation Model
ISPFTEFSharedStream Shared stream
ISPFTEFSharedUnit Shared Unit
For example, the published equipment list schema uses the IEquipment interface that is related
to the ISPFTEFSharedEquipment interface.
RelDefs Exposed on SPFTEFSharedObject

The SPFTEFComprisedOf RelDef links the shared object (ISPFTEFPublishedObjectCollection
interface) to the published items (ISPFTEFPublishedItem)
Configuring the Shared Interface for the Published Equipment

For the published equipment to create shared objects that instantiate the
ISPFTEFSharedEquipment interface, one of the realized interfaces on the published equipment
must be related to the SPFTEFSharedMappedInterface RelDef.
ISPFTEFSharedEquipment is already related to IEquipment, which is often used on published
equipment ClassDefs so there would be no need to create an additional relationship. To see
what is related to these shared object interfaces, find them in the Desktop Client and then use
the Export Data command to browse the structure.
Data Warehouse Publish Schema Creation

The publish schema must ultimately reside in the CMF file in the SmartPlant Foundation
database that contains all the published schema for all the tools. In order to work on this, the
integration schema document must be checked out.
 Use the Find > Integration > Schema Documents to get a list of the documents.
 Check out the document called CMF_Ver
There are three approaches to getting the publish schema in to the CMF file:
1. Use the Schema Editor and create it directly in the CMF file
2. Create it in a separate file and merge it in
3. Manage it in a totally separate physical file that is referenced by the CMF file.
For more information, see How to Extend the Integration Schema (on page 61).
Configuration to Support Consolidation

For the published objects to support consolidation with objects published by other tools, an
interface on the published equipment needs to be related to the appropriate shared object
definition. This can be done in the Schema Editor at this stage so that it gets into the schema file
generated in the next step.
Loading the Publish Schema into SmartPlant Foundation

Preparing the Schema Load File
A new base SmartPlant schema file needs generating to replace the delivered one in the
Product Directory \Models\Core folder to support the writing of customization code. If the
published schema was modeled in the CMF file directly then this file is also used for loading the
published schema into the SmartPlant Foundation database.
 Use the Launch CMF File Manager (xml) command from the shortcut menu of the CMF
document in SmartPlant Foundation to generate the schema xml file. For more information,
see How to Extend the Integration Schema (on page 61).
 Accept the defaults in the dialog box and make a note of where the schema file is
generated.
 This adds the following SmartPlant Foundation interfaces to the published schema tag
ClassDefs
ISPFClaimableItem - Not needed.
ISPFClaimedItem - Not needed.
ISPFTEFClaimedItem - Not needed; may be used in the future.
ISPFTEFClaimableItem - Not needed; may be used in the future.
ISPFMergableItem - Not needed.
ISPFMergedItem - Not needed.
ISPFTEFPublishedItem (also added to the published document)
 It also sets SPFIsConfigurationControlled="True" on all the ClassDefs
 This creates a file called SCHEMA_EFSchema-Gen.xml from the CMF file and additional
files for any pseudo files used.
 These files need to be moved to replace the delivered file in the Prodcut Directory
\Models\Core
Now the EFSchema-Gen.xml schema file and exported pseudo files can be loaded into
Loading the Schema File

 Locate the files generated (EFSchema-Gen.xml and files for any pseudo files used) and
start the Schema Import Wizard by clicking Administration > Schema Import Wizard.
Select the Compare contents of selected files against all items with matching content
and select the file.
 The compare content of selected files with the database handles new items and
updates only.
 The second option works with the container ID in the database and selects all items with
this container ID and does a compare with the file. This option handles new items,
updates and deletions and should be used on subsequent loads of modified schema.
There are a number of options for creating the authoring schema that will be discussed next.
Defining and Mapping the Authoring Schema

The Authoring schema can be a reflection of the data warehouse schema with a new
component schema and new ClassDefs with new primary interfaces but realizing the same
interfaces. This means that the mapping is a 1:1 relationship.
One way to create the authoring schema and the mapping file is to generate it from the
published schema. Alternatively, the authoring schema can be created by copying the published
schema but in this case the mapping file needs to be generated manually. See the section
earlier in this document dedicated to creating the mapping files.
Generating the Authoring Schema and Mapping

The Authoring schema can be created manually from scratch. Use the Schema Editor to build
this in a schema file on its own.
 Create an empty schema file, set a suitable container ID in the header.
 Create a .cfg file for loading up this file and all its dependencies in the Schema Editor. Note
that this references the new SCHEMA_EFSchema-Gen.xml and the
SCHEMA_Core-DWGeneral.xml files. Replace <INSTDIR> by the install path. For
example, the install path can be C:\Program Files (x86)\SmartPlant\Foundation\2009:
`MS`<INSTDIR>\Models\SchemaComponent\SCHEMA_SchemaComponentCodedExte
nsions.xml
`MS`<INSTDIR>\Models\SchemaComponent\SCHEMA_SchemaComponentCodedExte
nsionsFixes.xml
`MS`<INSTDIR>\Models\SchemaComponent\SCHEMA_SchemaComponentDisplayNa
meFixes.xml
`MS`<INSTDIR>\Models\SchemaComponent\SCHEMA_SchemaComponentFixes.xml
`MS`<INSTDIR>\Models\BootStrap\SCHEMA_SchemaComponentExtensions.xml
`S`<INSTDIR>\Models\BootStrap\SCHEMA_BootStrap.xml!N
ÀS`<INSTDIR>\Models\Core\SCHEMA_SPFClaimSchema.xml!N
ÀS`<INSTDIR>\Models\Core\SCHEMA_SPFCoreSchema.xml!N
ÀS`<INSTDIR>\Models\Core\SCHEMA_Core-DWGeneral.xml!N
ÀS`<INSTDIR>\Models\Core\SCHEMA_EFSchema-Gen.xml!N
ÀS`<INSTDIR>\Models\Core\SCHEMA_SPFCoreDocMgtSchema.xml!N
ÀS`<INSTDIR>\Models\Core\SCHEMA_SPFDesignDocumentSchema.xml!N
ÀS`<INSTDIR>\Models\Core\SCHEMA_SPFDocumentClaimSchema.xml!N
ÀS`<INSTDIR>\Models\Core\SCHEMA_SPFListDocumentSchema.xml!N
ÀS`<INSTDIR>\Models\Core\SCHEMA_SPFProgressSchema.xml!N
ÀS`<INSTDIR>\Models\Core\SCHEMA_SPFDatasheetDocumentSchema.xml!N
ÀS`<INSTDIR>\Models\Core\SCHEMA_SPFDatasheetSchema.xml!N
ÀS`<INSTDIR>\Models\Common\SCHEMA_Common_WBS.xml!N
ÀS`<INSTDIR>\Models\Auth\SCHEMA_Auth-General.xml!N
ÀS`SCHEMA_PpmPASchema.xml!
ÀctS`SCHEMA_PpmPASchema.xml!Y
Usage of Standard SmartPlant Foundation Interfaces

The following interfaces may or may not be required as indicated:
ISPFClassifiedItem Needed if the item is classified, for example on the
major equipment classes. Note that there also needs to
be a RelDef to link the equipment ClassDef to the
classification tree, for example
PpmPAEquipmentClassClassDef.
ISPFSubscribableItem To support user subscription.
ISPFClaimableItem Optional to support configuration management locally
in SmartPlant Foundation.
ISPFClaimedItem Optional to support configuration management locally
ISPFMergableItem Optional to support configuration management locally
ISPFMergedItem Optional to support configuration management locally
Additional Schema Considerations

Make sure that SPFIsConfigurationControlled="True" on all the ClassDefs. This
should be set automatically by the process that extracts the schema from the CMF and pseudo
files prior to loading into SmartPlant Foundation.
Authoring Schema to Support the PBS Hierarchy

As the PBSItemCollection RelDef is defined with an end locality of across container, it will be
written into the component schema for the equipment, but will not take across the end object
such as the FunctionalUnit. This is so that the tool can publish the relationship to the PBS item
on its own. The authoring schema needs to be configured as follows:
 Define and realize a new PBS interface such as IPpmPBSItem
 Define a new RelDef linking this interface to the PBS item such as the SPFFunctionalUnit,
or PpmUnitPBSItem.
There are also a number of other things to make this work:
 The new RelDef needs to be included in the tool map file.
 The authoring PBS hierarchy must be created by first creating the Data Warehouse PBS
hierarchy and then retrieving it into SmartPlant Foundation authoring. This is so that there
will be SPFFunctionalUnit objects shared with the FunctionalUnit objects. They will have the
same UID which means when the PpmUnitPBSItem RelDef is transformed to the
PBSItemCollection RelDef it will sync up to the correct object.
Loading the Authoring Schema into SmartPlant Foundation

Use the Schema Import Wizard to load in the authoring schema in the same way as the
published schema was loaded. See Loading the Published Schema into SmartPlant Foundation
Creating the Tool Map Schema

The tool map schema file has to be configured manually. Use the spreadsheet approach as
described in the detailed section.
The creation of the adapter documents is described below in the section on configuring
authoring (publish and retrieve).
This is the configuration used for a simple equipment list:
The End 1 is End 1 is set to FALSE because the PpmUnitPBSItem has the Unit as the
first object in the relationship and the PBSItemCollection has the Unit as the second object in
the relationship.
Configuring Domains
Before any schema can be utilized in SmartPlant Foundation, a domain has to be configured to
persist any objects that are created with that schema. For SmartPlant Foundation authoring, two
domains are required, one to hold the authored data as it is created and one to hold the data in
the data warehouse after it has been published. As described in the model sections above,
schema classes are related to a domain through their component schema.
Remember that if you want to export the administration as a single file later, set the default
container ID in the user preferences before you start.
Data Warehouse Domain Configuration

Create a new domain for the data warehouse data.
 Select a name for the domain, for example, PpmPEQL
 Select DWShared as the domain environment – this ensures that when a user has access
to the data warehouse through a role, they automatically have access to the new equipment
list publish domain.
 Select the Published domain group.
 There is no need to select a domain type.
 Drag and drop the data warehouse component schema loaded above onto the new domain.
Authoring Domain Configuration

You can either create a new authoring domain or use an existing one. Use a new one if you
want to isolate the data like a separate application with its own user access or use an existing
one if you are extending the functionality available to existing roles.
Once you have configured up multiple schema functionality in one domain you cannot
separate them by turning a domain off, only through user access.
 Use a new domain if you want complete isolation of data.
 This is most commonly done for different disciplines working on common data at
different times in its lifecycle as each discipline can complete its work and publish to the
enterprise. The process group can issue the data early on and continue to work on it
while the mechanical group works in parallel. Overlapping publishes are not a problem
as each discipline only publishes their own data.
 This hides other authoring domains when working in this new one.
 This separates the data by publish.
 This means the only communication between this equipment list and other authoring
activities is through publish and retrieve.
 Use an existing domain to extend existing authoring capabilities
 This is done when a single discipline wants to manage the new data in the same
process as some existing data.
 The new data and the existing data are managed and published as a single package.
 The user‟s role access can still be configured to give separate access to components of
this data using conditions and specific update methods and forms but it is all published
as a single package.
If one discipline publishes the object they publish the whole object which may
include data managed by another discipline and that they might not even be able to see.
This might result in releasing data that is not suitable unless strict review processes are
put in place.
Create a new domain for the authored data.

 Do not select a domain environment – this is because role access to the authoring domain is
controlled specifically by this domain.
 Select the DATA domain group
 There is no need to select a domain type
 Find the SPFAUTHORING domain and drag and drop it onto the new domain. This builds
the dependency between these domains such that when the authoring roles specify the new
authoring domain, it also loads all the dependent core domains.
 Drag and drop the authoring component schema loaded above onto the new domain.
Alternatively use an existing authoring domain
 Find the relevant domain, for example ProcessD, and drag and drop the authoring
component schema loaded above onto the existing domain.
Configuring the Authoring Environment

Before anything can be retrieved or published, the authoring environment needs to be
configured with commands to create, query, and relate the data, and with list editing for the likes
of the equipment list.
Configuration to Create and Manage the Authored Data

Additional Schema to Support Equipment List Authoring
As mentioned above, there may or may not be a need to model a list object between the list
items and the document.
The How To Configure Document Management guide covers the configuration of publishable
documents in detail but the basics are covered here for convenience. The document should be
configured as follows.
Configuration of a List Document

The following schema is typical of what would be modeled for an equipment list document.
IPpmPAEquipListDocMaster
ClassDef used for the equipment list document that realizes the following interfaces:
IObject
IPpmPAEquipListDocMaster Primary interface
ISPFClassifiedItem This is a classified document. There
needs also to be a RelDef to link the
equipment ClassDef to the classification
tree, for example,
PpmPAEquipListDocClassClassDef.
See the classified document note
below.
ISPFDocument
ISPFDocumentMaster
ISPFDocumentObject
ISPFNonPublishedDocMaster To indicate this document has not been

published
Classified document considerations:
Typically the equipment list document is a classified document. This means that the
document version ClassDef has to be related to the classification tree. This is done by
defining a new RelDef between an interface on the classification tree and IClassDef. If you
want to restrict the creation of the equipment list documents to a specific node of the tree,
create a new interface and realize it optionally on the SPFDocumentClass ClassDef and
create a document classification node using this interface or add the interface to an existing
node. For example:
 Make the SPFDocumentClass ClassDef optionally realize a new interface, such as
IPpmPAEquipListDocClass.
 Create a RelDef between this and IClassDef, for example
PpmPAEquipListDocClassClassDef.
 Create a new document classification tree node or add IPpmPAEquipListDocClass to
an existing node.
 Drag and drop the PpmPAEquipListDocVersion ClassDef onto the new node of the
classification tree to create the relation for the create method to use.
IPpmPAEquipListDocRevision
IPpmPAEquipListDocRevisionClassDef uses for the equipment list document that controls the
publish process and realizes the following interfaces:
IObject
IPpmPAEquipListDocRevision Primary interface
ISPFAuthPublishableDocumentRevision Controls document publish with the
following properties
 SPFAuthPublishableToolID Domain of the authoring tool
 SPFAuthPublishableTargetClassDef Target ClassDef for the published
document
ISPFDocumentObject
ISPFDocumentRevision
ISPFListDocRevSnapshot Controls the snapshot process with the
following properties
 SPFSnapshotDataGraphDef Optional GraphDef to control the publish
file generation
ISPFListEditControl Controls the list edit process and
snapshot creation with the following
properties
 SPFClassDefForNewRelatedItems ClassDef to use for new items (list edit)
 SPFColSetToDisplayRelatedItems Complete column set to use for displaying
related items (list edit and snapshot)
 SPFDeleteActionForRelatedItems Delete action for related items (list edit)
 SPFPathDefnToRelatedItems Path definition used to get related items

(list edit and snapshot)
 SPFTitleForDisplayingRelatedItems Title for displaying related items (list edit)
ISPFNonPublishedDocRevision
ISPFWorkflowItem
 ISPFAuthPublishableDocumentRevision
This interface holds key properties that are used when a publishable document is created or
revised in the authoring environment as it also reserves the document in the data
warehouse for publishing later. The SPFAuthPublishableToolID property holds the authoring
tool domain and is used along with the current create configuration to find the tool
registration details to know where to create the reserved document. The document
reservation is performed by creating a reserved SPFTEFPublishedDocMaster in the
DWShared domain. The SPFAuthPublishableTargetClassDef contains the published
document, for example, PpmPPDocument, and this is written into properties on the reserved
document for later use.
In previous SmartPlant Foundation releases, the ISPFLLALineListRecordDocumentRevision
interface was also required to support the population of the properties on these two
interfaces on creation of the document, in some circumstances as described in detail below.
This was a temporary measure to make use of line list editing capabilities but this has now
been made generic with the release of SmartPlant Foundation 2009 R3 SP2.
IPpmPAEquipListDocVersion
The ClassDef used for the equipment list document snapshots files that realize the following
interfaces:
IObject
IPpmPAEquipListDocVersion Primary interface
ISPFDocumentObject
ISPFDocumentVersion
ISPFExportableItem
ISPFFileComposition
ISPFNonPublishedDocVersion
ISPFOwnedObj
RelDef from Equipment List to the Document

PpmPAEquipListDocRevEquipment links the document revision IPpmPAEquipListDocRevision
interface to the list items IPpmPAEquipment interface.
Configuration of a Separate Equipment List Object and Document

If there is a need to integrate the list object, like has been done for the line list application then it
is necessary to model a list ClassDef in both the authoring and publish schema and map them
to each other.
The following schema is typical of what would be modeled for an equipment list.
The document should be configured exactly as above for when there is no separate list object.
PpmPAEquipList
ClassDef used for the equipment list from which the list editing is configured that realizes the
following interfaces.
This is not actually published, it does not need the ISPFAuthPublishableItem and
ISPFAuthPublishedItem interfaces.
IObject
IPpmPAEquipList Primary interface
RelDef from Equipment List to Equipment

PpmPAEquipListEquipment links the equipment list IPpmPAEquipList interface to the equipment
IPpmPAEquipment interface
RelDef from Equipment List to the Document

PpmPAEquipListEquipListDoc links the list IPpmPAEquipList interface to the document master
IPpmPAEquipListDocMaster interface.
Configuration of Roles for the Equipment List

There are no specific roles or message access group requirements for authoring lists. The
delivered roles and access groups are described in a separate section of this document. If, for
example, the configuration is for process equipment, then the ProcessEngineer role could be
used.
Additional Configuration for Managing Equipment

Regular commands can be configured to create, find, update, and terminate individual
equipment items.
Form Generation
Find the ClassDef and use the Generate Form on the right-click menu to build the default form.
Column Set Generation

The column set can be configured interactively:
 Create a new column set
 Use the Manage Column Items dialogue box to configure the columns
 Use the Library tab to relate existing column items such as Name and Description
 Use the Navigate Schema tab to create and relate new column items by navigating to
the relevant properties and relationships, selecting them (use Ctrl for multiple items) and
add them to the list.
 Typically include the top typing properties and some key equipment properties.
 Relate the column set to an interface on the equipment class
 Specify this Column Set on the QFind method
 For the column set to be picked up after relationship expansions from other objects, it
has to be related to an interface with a specialization value. Core interfaces have
specialization values but new ones, such as the IPpmPAEquipment primary interface,
do not. Set the value to a high value such as 4000, it must be higher than the values of
the other interfaces on the class for the column set to be picked up. The specialization
value can be added in the SpecializationValues.xml file in the Site Server directory (for
example the Product Directory).
Classified Equipment
If the equipment items are classified, there are a number of additional tasks required. These are
described in detail in the How To Configure Classified Objects Guide but the basics are included
here for convenience.
 The equipment create methods need to use the classified object API as detailed below.
 An additional classification tree node might need to be defined for the equipment but
generally the standard ones are used.
 The equipment ClassDefs need to be related to the classification nodes. This can be done
by dropping the equipment classdef version classdef on the relevant classification tree node.
Configuration for Equipment List Editing

The basics on configuring Lists is covered here as well as the configuration of list editing. See
the SmartPlant Foundation Administration Guide for further details.There are two Client APIs for
simple list editing:
ListEditContextMenu For multi select list editing of objects
ListEditUncontrolledItems For list editing items from some related
object
The list edit method is a multi-select method that is configured on the right-click menu of the
data items to be edited. An example method for the equipment list is provided below:
Method PpmPAListEdit
Description Equipment List Edit
API Name ListEditContextMenu
ClassDef for New Rows PpmPAEquipment
Delete Action Terminate
PpmPAEquipmentListEditCS (See Note
Colum Set below)
The same column set that is used for the list view can be used, but it must first be
configured for edit using the Manage Column Items for Edit command.
Configuration of the Equipment List Document

The How To Configure Document Management guide covers the configuration of list documents
in detail, but the basics are covered here for convenience. The configuration for the creation of
the equipment list document depends on if the separate list object is used. Both configurations,
however, require methods to be configured that populate properties on two key interfaces when
the documents are created:
 ISPFAuthPublishableDocumentRevision has properties that control the publish process.
 ISPFListEditControl has properties that control the document snapshot process and the
editing of the list items from the right-click menu of the document.
List Document without a Separate List Object

This is where the list items are related directly to the document.
List Document Creation Method

There are a number of ways to create the list document. The important thing is that the create
process must populate key properties on the document to support list editing and publish.
The two properties on the ISPFListEditControl interface need populating as they are required by
the snap shot functionality.
 Set SPFPathDefnToRelatedItems, for example to +PpmPAEquipListDocRevEquipment.
 Set SPFColSetToDisplayRelatedItems, for example to PpmPAEquipmentListEditCS.
An additional property can be set to control the generation of the published data file. If the
column set does not contain all the objects to be published, such as the process cases
collection, then a GraphDef can be created and identified on the SPFSnapshotDataGraphDef
property of the ISPFListDocRevSnapshot interface. If one is not defined, the graph to publish is
dynamically generated from the column set.
The two properties on the ISPFAuthPublishableDocumentRevision interface also needs to be
populated.
 Set SPFAuthPublishableToolID, for example, to ProcessD.
 Set SPFAuthPublishableTargetClassDef, for example, to PpmPPDocument.
A number of options are available for creating the list document.
From the List Edit GUI

Configure a create method using the CreateClassObj. The two properties on the
ISPFAuthPublishableDocumentRevision interface need to be populated. This can be done by
configuring a hidden section on the create form. This is because the CreateClassObj method
does not yet support the property override argument like the
CreateClassObjAndRelWithPropertyOverrides described below.
Edit the PpmPAListEdit multi select list edit method available on the equipment and populate the
Create method argument with the create document method name. Now the document can be
created using a button on the list edit GUI.
Description Equipment List Edit
API Name ListEditContextMenu
ClassDef for new rows PpmPAEquipment
Delete action Terminate
Colum Set PpmPAEquipmentListEditCS
List Management Relationship
Definition +PpmPAEquipListDocRevEquipment
List Management Create Method MTH_PpmPAEquipListDocCreate
List Management Button Caption Document…
From a Pull-Down Menu Item

Configure a create method using the CreateClassObj. The two properties on the
ISPFAuthPublishableDocumentRevision interface and those on the ISPFListEditControl
interface need to be populated. This can be done by configuring a hidden section on the create
form.
From a Related Item

This uses the CreateClassObjAndRelWithPropertyOverrides Client API to create and relate the
document to an object and set to properties mentioned above. Configure this is off the right-click
menu of the equipment item itself. This means that to create the document you must first create
and relate it to one of the equipment items and add further items by dragging and dropping
them.
Method PpmPAEquipmentListDocCreate
Description Create Equipment List Document
API Name CreateClassObjAndRelWithPropertyOverrid
es
RelDef to Doc ClassDef from
Classification PpmPAEquipListDocClassClassDef
Allow classification drill down FALSE
Classification DC_List_Document_1
RelDef to related objects
-PpmPAEquipListEquipListDoc
PropertyOverrides See below
This method uses the property overrides argument to set the properties on the two document
interfaces mentioned above. The method argument contains a string of ~ separated
interface.property.value segments show separated here for readability:
ISPFListEditControl.SPFColSetToDisplayRelatedItems.
PpmPAEquipmentListEditCS~
ISPFListEditControl.SPFPathDefnToRelatedItems.+PpmPAEquipListDocRevEqui
pment~
ISPFAuthPublishableDocumentRevision.SPFAuthPublishableToolID.ProcessD~
ISPFAuthPublishableDocumentRevision.SPFAuthPublishableTargetClassDef.Pp
mPPDocument
The first two configure how the list objects are found for the snapshot generation and the second
two determine how it is published.
The optional property SPFSnapshotDataGraphDef may also need to be populated if the column
set does not contain all data to be published as described above.
List Edit Equipment from the Document

The alternative way to list edit the objects from the document is to use the ListEditRelatedItems
Client API. This method uses the properties on the ISPFListEditControl interface that are
populated when the document is created directly from the list edit GUI. Again these could be set
on the form or by using the overrides if the document was created by a different means.
Method PpmPAListDocListEditRelatedItems
Description Edit Equipment List
API Name ListEditRelatedItems
Alternative List Edit Method Configuration

This list edit method can be configured on the document using the ListEditUncontrolledItems
Client API to navigate to the related objects and run the same method as used when editing
them directly with multi select.
Method PpmPAListDocEditEquipment
API Name ListEditUncontrolledItems
MTH_PpmPAListEdit (in other words, the
List Edit method UID multi-select right-click menu one above)
Path to the related objects to edit + PpmPAEquipListDocRevEquipment
List Document with Separate List Object
List Document Creation Method

The list document is created from the right-click menu of the list object. An example method for
the equipment list would be:
Method PpmPAEquipmentListDocCreate
Description Create Equipment List Document
API Name CreateClassObjAndRelWithPropertyOverrides
RelDef to Doc ClassDef from
Classification PpmPAEquipListDocClassClassDef
Allow classification drill down FALSE
Classification DC_List_Document_1
RelDef to related objects -PpmPAEquipListEquipListDoc
PropertyOverrides The following property overrides are needed as
described above:
ISPFListEditControl.SPFColSetToDisplayRelatedItems.PpmPAListEdit~
ISPFListEditControl.SPFPathDefnToRelatedItems.EDG_EquipListDocRevToEquipment~
ISPFAuthPublishableDocumentRevision.SPFAuthPublishableToolID.ProcessD~
ISPFAuthPublishableDocumentRevision.SPFAuthPublishableTargetClassDef.PpmPPDocument
Equipment List Creation Method

The equipment list is created using the CreateObj method from a drop down menu. There are
no special properties to set as the list editing uses a Client API that navigates to the related
equipment and runs the same method that is used to list edit the equipment off the right-click
menu of the equipment items themselves.
List Edit Method Configuration

The list edit is configured on the list object. An example method for the equipment list would be:
Method PpmPAListEditList
API Name ListEditUncontrolledItems
PpmPAListEdit (for example, the multi select
List Edit method UID right-click menu one above)
Path to the related objects to edit + PpmPAEquipListEquipment
Configuration to Generate the Document Snapshot

The How To Configure Document Management guide covers the configuration of list document
snapshot generation in detail but the basics are covered here for convenience. In order to
publish the document it is necessary to generate the publishable XML and view file.
Method PpmPAEquipListSnapshot
Description Snapshot Equipment List
API Name CreateListDocumentSnapShot
Template Name Snapshot Template (this is the default)
Maintain template column size False (columns in Excel match SmartPlant
Foundation column item widths)
Include column set header True (column headers in Excel match SmartPlant
Foundation column item headers)
This method uses properties on the document to generate the view file and publishable data file.
 SPFPathDefnToRelatedItems - adds items to the view file.
 SPFColSetToDisplayRelatedItems - determines data to display in the view file and also
dynamically creates a GraphDef to get all the data to publish in the data file.
 SPFSnapshotDataGraphDef - Overrides the dynamic generation of the graph to publish.
This will be set when the column set does not contain all the objects to be published such as
the process cases collection.
Configuration to Load Equipment from Excel

Refer to the How To Setup and Configure SmartPlant Foundation guide for details on how to
use the Excel Loader.
Configuring Equipment List Authoring

Before anything can be published or retrieved, SmartPlant Foundation needs to know how the
data will be transformed between the authoring and data warehouse domains and how the
shared objects will be configured. This is done using two documents; one containing the
mapping file, and the other containing the adapter header file.
Adapter Document Configuration

Two adapter documents have to be created - the header document and the tool map schema
document. See earlier in this document for details on how to write and format the contents of the
files related to these documents.
Adapter Mapping File Configuration

The tool map file can be generated as the authoring schema is created, generated from a
spreadsheet, or written manually.
Create the Adapter Mapping Document in SmartPlant

Foundation
The Tool Map Schema document can be created interactively or by using a load file.
To create the document interactively:
1. Navigate the document category tree to System Documents
2. Use the Create Adapter command from the shortcut menu or the Adapter Document
category. (Note that in 4.3.1 and before there is an error in this method. The RelDef
identified on the CreateAdapterDocument method should be
SPFAuthAdapterClassClassDef.)
a. Enter a suitable name such as PA Tool Schema.
b. Enter the Adapter Code that will be used on the integration methods to identify the
document, such as PA.
c. Use the Attach Adapter command from the shortcut menu of the newly created
document to attach the file. (Note that in 4.3.1 and before there is an error in this
method. The AttachAdapter method identifies the SPFDesignFile class when it should
be the SPFAuthAdapterFile class. This needs to be changed to ensure the code can find
the adapter documents later. It is also a database file.)
To use a load file:
1. Copy one of the delivered sample load files, for example, „IPD Tool Map Schema Load.xml‟
found in C:\Program Files
(x86)\SmartPlant\Foundation\2009\Models\AuthExample\DTC-LoadFiles\AdapterDocument\
Adapter Docs\IPD
2. Make the following changes to the load file.
a. Change the name and UID of the document master, revision and version consistently.
The names of the document master, revision and version must be the same (for
example, IPD Map Schema) and it is recommended that the UIDs contain
master/revision/version and so on (for example, ToolMapSchema_IPDVersion).
b. Change the name and file name of the SPFAuthAdapterFile object to match the tool
map schema file name.
c. Update the relationships matching the changing UIDs of the document and file.
Adapter Header File Configuration

The easiest way to create an adapter header file is to copy one of the existing ones in
SmartPlant Foundation. An example file is described in the details section on header file
creation earlier in this document. There are a few key things not to forget:
 Remember to set the schema component and make sure the ToolSchemaMapFile name to
that of the tool map schema file created above.
 Name the adapter file after the adapter code reference that you are using to be consistent
with existing header files. For example, SPFAdapter_PAFile.xml.
 Set the document category, type, title and component schema for the published document.
 Set the equipment interface and RelDef for relating it to the document.
 Similarly set up the retrieve information.
Create the Adapter Mapping Document in SmartPlant

Foundation
 Configuring publish
 Configuring retrieve – design basis document
 Configuring document compare on retrieve
Setting Up Publish and Retrieve Roles

In order to publish and retrieve data to and from a data warehouse, the SmartPlantPublisher and
SmartPlantRetriever access groups (note access groups need to be set up rather than roles)
need to be initially set up for each user that needs to perform these tasks in the data warehouse
environment. Use the Configuration Role Assignment command to perform this task.
See the How to Configure the Security Model guide for details on how to create access groups.
There are two message access groups that are required to publish and retrieve that must be
included in the roles of the user.
 SmartPlantPublisher
 SmartPlantReviewer
Neither of these access groups are related to any methods. They are used during publish and
retrieve to determine the access for the user requesting the publish and retrieve. If the user has
more than one role in the active plant, then the SmartPlant Client does not know which role to
use so it looks for the role that it related to these access groups to determine the role to use.
The role used ultimately controls access to the publish vaults and so on.
There are other roles configured out of the box as described inSPF DTC ADMIN Role
Assignments .
Configuring Publish for Authored Data

Register Tool
Before any data can be published, the authoring environment must be registered with the data
warehouse. A method and menu option has to be configured to do this. The
FrameworkRegisterInt Client API is used to configure interactive tool registration.
Client API details:
API Name FrameworkRegisterInt
Description Register with SmartPlant (Interactive)
Arg 1 Tool adapter prog ID
Arg 2 Domain
Arg 3 Adapter Code
Arg 4 Database Code
Tool Adapter Program ID

This is the reference to the COM prog ID of the SmartPlant Foundation Adapter. An example of
which is SPFAdapter.TEF.Adapters.SPFTEFAdapterGEN. This is the general adapter supplied
with SmartPlant Foundation that can perform the basic publish and retrieve operations.
Customers can create their own adapters (see Custom Adapters below) that inherit from
SPFTEFAdapterGEN to override some adapter behavior.
The reference given above is typically the name given to a .NET assembly that is
compiled with the COM registration radio button selected.
Domain
This is the name of the authoring domain in which the data will be instantiated. For example,
ProcessD. When the comparison is made, the UIDs contained in the file are checked against the
authoring database in the domain specified.
Adapter Code
This is the code used to represent the SmartPlant Foundation tool and is used to find the
relevant adapter document via its adapter code property value, for example PA.
Database Code
This enables SmartPlant Foundation to publish and retrieve from a different database, but it is
not supported at this time so this argument is left blank.
The register method should be exposed through the SmartPlant menu. It is recommended that
a new sub-menu is created for each application as shown below.
The method to register the equipment list tool is listed below:

Method PpmPARegister
Description Register Tool PA
Tool Adapter Prog ID SPFAdapter.TEF.Adapters.SPFTEFAdapterGEN
Domain ProcessD
Adapter Code PA
Publish Object or Document

The FrameworkPublishRHM Client API is used to publish individual data items or a publishable
document from authoring to the data warehouse. It is a shortcut menu method that typically is
associated with an object (for example, IPRCProcessInstrument) or document
(IPpmPAEquipListDocVersion).
Client API details:
API Name FrameworkPublishRHM
Description Publish from right-click menu
Arg 1 Tool adapter prog ID (see above)
Arg 2 Domain (see above)
Arg 3 Adapter Code (see above)
Arg 4 Database Code (see above)
Several methods have been configured using this client API and are supplied with the core
delivered data warehouse database. These are detailed in the OOTB section later in this
document.
The method to publish the equipment list would be
Method PpmPAEquipmentListDocPublish
Description Publish Equipment List Document
Tool Adapter Prog SPFAdapter.TEF.Adapters,SPFT
ID EFAdapterGEN
Domain ProcessD
Adapter Code PA
Publish by Query
The FrameworkPublish ClientAPI publishes data from the authoring database to the data
warehouse. It is a stand-alone method that searches for all objects with the interface
ISPFAuthPublishableItem, where the SPFAuthNeedsRepublishing property is set to False.
Client API details:
API Name FrameworkPublish
Description Publish
document.
Publish Data Sheet

The TEFPublishDatasheet Client API publishes data from authoring to the data warehouse and
is a shortcut menu method that typically associated with an object (for example,
IPRCProcessInstrument). The difference with this API is that prior to the publish the data sheet
is regenerated.
Client API details:
API Name TEFPublishDatasheet
Description Publish
Arg 1 Data sheet Type
Arg 2 Data sheet Def UID
Data Sheet Type

Each data sheet has a code and this field indicates the type of data sheet (in other words, IPD)
that is being published using this method.
Data Sheet Def UID

The data sheet def UID allows the publish command to identify which data sheet definition
needs to be used when recreating the data sheet for publish.
document.
Load Published Data

The TEFLoadPublishData Client API loads published data attached to the document.
Client API details:
API Name TEFLoadPublishData
Description Load the published data attached to a
document
Arg 1 Load into document config only (true/false)
Load into Document Config Only

This controls if the data is loaded into the plant or the document sub configuration.
Two methods have been created - one with each option, in the delivered system attached to the
ISPFTEFPublishedDocVersion interface for loading published documents.
Configuring SkipFailedDocuments
The SkipFailedDocumentsInLoad setting in the web.config allows you to skip a published
document that failed during a load or consolidate task and continues processing other
documents in the queue. SkipFailedDocumentsInLoad can be set using the site settings in
Server Manager. You can set SkipFailedDocumentsInLoad to True to skip a published
document that failed or select False to continue without skipping the failed document. The
default setting is False.
Load and consolidate tasks is related to, and are handled with, a single
ISPFTEFQueueSchedulerTask scheduler task.The scheduler task continuously polls the
queue for the next document that is ready for loading. When a document is the first item on the
queue, and has load and consolidate statuses of Queued, the document is processed. Unless
SkipFailedDocuments is set to True, the next document in the queue is the first document
without a failed load or consolidate status.
When SkipFailedDocumentsInLoad is set to False, the queue stops processing documents
when 1 document on the queue has failed. A document has failed if it has a failed load,
consolidate or merge delta status.
If SkipFailedDocumentsInLoad is set to True, the queue continues to process documents if
previous documents have failed. Any previously failed document versions are removed from the
queue, if a later version successfully loads.
For additional details on Load Queue Management, see Load Queue Management in the
Desktop Client User's Guide.
For additional details on setup in Server Manager, see Create and Configure SmartPlant
Foundation Sites in the Server Manager User's Guide.
Configuring the Retrieve and Compare Process

The retrieve and compare process is as follows:
1. Verify tool registration is done by constructing a name from the domain (defined in argument
2), the current create configuration (as set in the Desktop Client) and the database code (if it
is defined in argument 4), and checking this to see if an SPFAuthRegistration record exists
in the authoring database with this name. If the check fails, a Tool not registered message
is displayed.
2. Verify SPFAdapterFile objects in the database with the adapter code defined in argument3.
The two files that need to be present are the tool map schema and the tool adapter header
file.
3. Verify the tool map schema and the tool adapter header file are present in the temporary
directory on the client. If they are not there, then these files are downloaded from the
database to the temporary directory. If they are available on the client, then a date
comparison is made to see if the files in the database are newer or not, and only if they are
newer will the files be downloaded.
4. The tool adapter header file is read where information such as what document types can be
retrieved is extracted. This information is then sent to the data warehouse system.
5. The GUI is displayed and the possible documents that can be retrieved are displayed in the
dialog box.
6. On selection of a document, the name of the associated component schema is extracted.
Two checks are then made.
 Verify the component schema exists on the server and is newer than the creation date
of the CMF file that is stored in the vault. If it is not, then a call is made to the Schema
Component to extract the latest version.
 Verify a local copy of the component schema exists and is newer than data warehouse
version. If it is not, a copy is made.
7. The data, map file, and component schema are loaded into the Schema Component and run
through the adapter to generate the necessary load file on the client.
8. The load file is stored, displayed in the compare GUI, or loaded into the authoring database.
Configuring Retrieve for Objects Published by Other

Tools
Before any data can be retrieved into an authoring environment, it must be registered as
described in the publish configuration above and the schema to be retrieved needs to be
mapped to the authoring schema.
Mapping the Retrieved SmartPlant Schema to the Authoring

Schema
Before any published data can be retrieved, it must be mapped from the SmartPlant schema to
the authoring schema in the SmartPlant Foundation authoring tool map schema file.
Mapping in the Schema Editor

This is described in detail in the SmartPlant Foundation Administration Guide.
 Check out the relevant Tool Map Schema adapter document.
 Find the schema document in SmartPlant Foundation.
 Launch the Schema Editor from the shortcut menu.
 Open the tool map schema file.
 Configure the retrieve mapping to the relevant component schema.
 Validate and save the mapping file.
 Check in the Tool Map Schema adapter document.
Alternative Mapping Approach

The mapping file contents are described in detail in the adapter section of this document.
 Check out the relevant Tool Map Schema adapter document.
 Either edit it manually in a text editor or use the spreadsheet approach to regenerate a new
file.
 Check in the Tool Map Schema adapter document.
Retrieve Document
The FrameworkRetrieve Client API is used to retrieve data from the data warehouse to
authoring.
In order to configure a method to retrieve data from a SmartPlant Foundation data warehouse, a
method referencing the FrameworkRetrieve client API needs to be set up. As this is a method
that is invoked from the main menu, a menu item and the necessary relationships should also
be configured.
API Name FrameworkRetrieve
Description Retrieve
Arg 1 Tool Adapter Prog ID (see above)
Arg 2 Domain
Domain
This is the name of the authoring domain into which data is retrieved. This is different from the
publish methods that identify the publish domain. In other words, this argument always identifies
the domain in which data is instantiated.
This method will work without further configuration only if the OnRetrieve Action in the Adapter
Header file is set to one of the following:
DesignLoad Transforms and loads the data directly into the
authoring environment
Compare Same as for DesignLoad but the Compare dialog
box is presented first.
The other actions available require the creation of a design basis document.
The method to retrieve the equipment list tool would be:
Method PpmPARetrieve
Description Retrieve Data
Domain ProcessD
Adapter Code PA
Adapter Code
This method works without further configuration only if the OnRetrieve Action in the Adapter
Header file is set to one of the following:
DesignLoad Transforms and loads the data directly into the
authoring environment.
Compare The same as for DesignLoad but the Compare
dialog box is presented first.
The other actions available require the creation of a design basis document.
Configuring a Design Basis Document

Design Basis Document Configuration
A design basis document has to be configured in order to store retrieved data as a design basis
and compare it with further data being retrieved and existing data. Standard document and file
classes need to be created as shown below. They need to be in the authoring schema
component, for example, ProcessD.
The document master realizes a primary interface and the following standard document
interfaces:
 IObject
 ISPFClassifiedItem
 ISPFDocument
 ISPFDocumentMaster
 ISPFDocumentObject
 ISPFNonPublishedDocMaster
The document revision realizes a primary interface and the following standard document
interfaces:
 IObject
 ISPFDocumentRevision
 ISPFNonPublishedDocRevision
 ISPFWorkflowItem
The document version realizes a primary interface and the following standard document
interfaces:
 IObject
 ISPFDocumentVersion
 ISPFExportableItem
 ISPFFileComposition
 ISPFNonPublishedDocVersion
 ISPFOwnedObj
A dedicated file class is configured that realizes a primary interface and the following standard
document interfaces:
 IObject
 ISPFAlternateRenditionComposition
 ISPFBusinessFile
 ISPFDesignBasisFile
 ISPFFile
 ISPFMarkupComposition
 ISPFNavigationFileComposition
 ISPFOwnedObj
There is no need to configure any create method as these documents are created on retrieve. It
is usual to create a QFind menu option based on the document revision primary interface.
The documents are classified which means a document category needs to be created under the
System Documents node, for example Retrieved Process Document.
To utilize the design basis document, the adapter header file to be edited:
 Set the DesignBasisComponentSchema UID, for example ProcessDesignComponent
 Set the OnRetrieve Action to
 DesignBasisLoad - Creates a design basis document and attaches the transformed
data, the delete instructions, and any view files to it.
 DesignBasisLoadAndCompare - Similar to action DesignBasisLoad, but launches the
Compare dialog box with the results.
 Set the DesignBasisClassification to the document category of the document, for example
Retrieved Process Document.
As well as comparing the incoming data on retrieve, various compare methods can be
configured to compare data on the shortcut menu of the design basis document.
Compare with Design Basis

The CompareDBasis Client API is used to retrieve data from the data warehouse to authoring. It
is a shortcut menu method that is associated with a design basis document (for example,
IPRCDesignBasisDocVersion).
Client API details:
API Name CompareDBasis
Description Compare Design Basis
Arg 1 Tool Component Schema
Arg 2 Tool Domain
Arg 3 Adapter Code
Arg 4 Assembly Name
Arg 5 Class Name
Arg 6 Assign New UIDs
delivered data warehouse database. For more information, see Summary of Core Delivered
Authoring and Data Warehouse Models (see "Summary of Core Delivered Authoring and Data
Warehouse Models (OOTB)" on page 139) later in How to Configure the Authoring and Data
Warehouse Models.
Tool Component Schema

The name of the tool (or authoring) component schema that any items selected will be loaded
into. The name of this component schema will be used in the header of any loader XML that is
then submitted to the server.
Tool Domain
This is the name of the authoring domain into which the data is instantiated. When the
comparison is made, the UIDs contained in the file are checked against the authoring database
in the domain specified.
Adapter Code
Adapter code or document type that is used to identify the map file.
Assembly Name
This is the name of the compare assembly that is loaded to perform the compare operations and
is usually SPFCompare.dll.
Class Name
This is the code class that processes the compare and is typically
SPFCompare.TEF.Compare.SPFCompareClass.
Assign New UIDs

If set to True, then the retrieved items will be loaded with newly generated UIDs.
Warehouse Models.
Compare with Latest Retrieved Data

The CompareLatestRetrievedData Client API is used to compare the latest retrieved data. The
actual data that is used for the comparison is the data held within the file that was last retrieved
into the user's Temp area. The method is run from a drop down menu.
Client API details:
API Name CompareLatestRetrievedData
Description Compare Latest Retrieved Data
Arg 1 Tool Component (see above)
Arg 2 Tool Domain (see above)
Arg 4 Assembly Name (see above)
Arg 5 Class Name (see above)
Warehouse Models.
Configuring Exposure of the Published Data

Default edges for navigation:
Name MasterToRepresentations
Display As Document Master to DrawingItems
Start IDef ISPFDocumentMaster
Path +SPFTEFComprisedOf,+DwgRepresentationComposition
Name LatestVersionsContainingDrawingItem
Display As Latest Versions Containing Drawing Item
Start IDef IDrawingItem
Path -DrawingItems,-DwgRepresentationComposition,-SPFTEFCom
prisedOf,+SPFDocumentRevisions,+SPFRevisionVersions
Name NonDrawingItemCollection12
Display As Items In Document
Start IDef INonDrawingItemCollection
Path -NonDrawingItemCollection
Name NonDrawingItemCollection21
Display As Documents
Start IDef INonDrawingItem
Path +NonDrawingItemCollection
Special Edge Definitions

A special edge definition has a pre-expansion relationship definition and a post expansion
relationship definition. It is used for objects shared across several tools and returns all the
properties for the object. Special edge definitions are generated automatically by SmartPlant
Foundation.
To navigate a special edge definition, the pre-expansion RelDef is expanded first, then the
normal RelDef is expanded, after which the post-expansion RelDef is expanded.
Example Special Edge Definition
Configuring Data Warehouse Inconsistency Reports

You can configure Excel reports to be run on SPFTEFSharedObjects. Users can select a single
shared object or multiple shared objects in the list view and call this report from the right-click
menu. The report is viewed in Excel, and the reports highlight the inconsistent properties. See
Viewing Inconsistency Reports in Excel in the Desktop Client User's Guide for more information
about running the report.
Configuring the Report

Use the InconsistencyReport client API to configure the report to be run from the right-click
menu of a shared object or multiple shared objects.
Use the InconsistencyReportWithStartingObject Client API client API to configure the report to
be run from any object that has shared objects related to it. Valid objects include published
documents and configuration items, such as plants, areas, or units.
The method arguments of both client APIs are listed below.
InconsistencyReport Client API

Argument Description Type Default value
Report Header The title to appear on the report. String Inconsistency
Report
Report Template The Excel template to use for the report. String None
Name
Freeze Columns If true, have static columns in the report. Boolean True
Show Inconsistent If true, show only inconsistent properties Boolean False
Properties Only for all objects.
Show Inconsistent If true, show only objects that contain Boolean True
Objects Only inconsistent properties but show all
properties for the object.
Portrait View If true, the properties appear down the Boolean True
page. If false, the properties appear across
the page in landscape fashion.
InconsistencyReportWithStartingObject Client API

Argument Description Type Default value
Edge Def or Graph Specify a graph definition or an edge String Nothing. You
Def definition to navigate to the objects. must provide a
value. Any
method which
uses this client
API and does
not specify a
value displays
an error.
Report Header The title to appear on the report. String Inconsistency
Report
Report Template The Excel template to use for the report. String None
Name
Freeze Columns If true, have static columns in the report. Boolean True
Show Inconsistent If true, show only inconsistent properties Boolean False

Properties Only for all objects.
Show Inconsistent If true, show only objects that contain Boolean True
Objects Only inconsistent properties but show all
properties for the object.
Portrait View If true, the properties appear down the Boolean True
page. If false, the properties appear across
the page in landscape fashion.
Creating an Excel Template

You can create your own template file in Excel, which is used to format the output of the report.
For an example template, see the delivered template, Inconsistencies Report Template. The
following named cells can be used to specify where the information will be displayed. At run-time
the named cell is replaced with the actual data from the report. If the named cell is not specified,
then the software does not populate the information.
Named Cell Description

REPORT_HEADER Displays the header of the report, which is specified on the
method.
REPORT_USER Displays the user who created the report.
REPORT_CONFIG Displays the current user config.
REPORT_DATE Displays the date the report was created.
REPORT_START Indicates the first cell to be used to start writing the report data.
Data is populated downwards and to the right of this cell.
To create a template file and use it for the report, do the following:
1. Create a template file in Excel.
2. Create a Template Document in the Desktop Client. (Select Document Category >
Template Documents > Excel Template Document in the tree view. Right-click Excel
Template Document and click New Template Document.)
3. Attach the Excel file to the new template document.
4. Modify the method you created using the InconsistencyReport client API. Assign the new
template to the Report Template Name argument (argument 3).
Load XML files to run Inconsistency Reports on an Updated

Database
In order to run the inconsistency reports on an upgraded database, load the
Models\InconsistencyReport\InconsistencyReport.xmlldr file into the SmartPlant Foundation
database.
The InconsistencyReport.xmlldr file contains the following XML files:
 SCHEMA_DW-InconsistencyReport.xml
 ADMIN_DW-InconsistencyReport.xml
 ADMIN_CDW-InconsistencyReport-SPFAccessGroupMethod.xml
 InconsistencyReportTemplateFile.xml
For more information about loading XML files, see Desktop Client Loader in How to Setup and
Configure SmartPlant Foundation guide.
Retrieving Data Authored in SmartPlant Foundation

into Other Tools
Every tool has its own adapter and also has a process for configuring data retrieval. SmartPlant
P&ID supports „plug and play‟ data retrieval by interface and is described here with an example.
 Add the document type to the schema‟s RetrieveDocTypes
 Checkout the schema document.
 Run the Schema Editor on the CMF file.
 Find the Tool Schemas and expand the SmartPlant P&ID Tool Schema.
 Add document types to the RetrieveDoc Types node.
 Ensure that the objects being retrieved have the correct interfaces and mapping.
 SmartPlant P&ID uses key interfaces to identify objects in the retrieved file such as
IInstrumentOcc.
 Properties and relationships are retrieved if they have been mapped from the
SmartPlant schema to the SmartPlant P&ID tool map schema.
Refer to the delivered SmartPlant Adapter for SmartPlant P&ID documentation
(SPAdapter-SPPID.pdf) for more details.
Configuring Excel Load for the Equipment List

Once the authoring schema has been created you can configure an Excel template to load data
into the authoring environment.
 Define a ViewDef to expose the properties and relationships on the authored equipment.
This can be tested by relating a Message Access Group and then running a new ad hoc
report. Existing authored objects will be returned and all the properties and relationships
populated.
 Create an Excel template file. This should contain a table structure with columns to match
the ViewDef properties.
 Create a new template document in SmartPlant Foundation and attach the file.
 Create a new Datalist Definition to link the ViewDef, template document and ClassDef to
create the following definitions:
 Check out the template document and run Data Sheet Definer to map the ViewDef
properties to the Excel cells.
 Check in the template document.
 Test the load using the File > Excel Import > Excel Import command.
 Configure specific Excel Import methods if you want to control which user loads what
type of template and uses Compare, and so on.
Configuring Excel Publish for the Equipment List

Once the publish schema has been created you can configure an Excel template to publish data
into the data warehouse.
 Define a ViewDef to expose the properties and relationships on the published equipment.
This can be tested by relating a Message Access Group and then running a new ad hoc
report. Existing published objects will be returned and all the properties and relationships
populated.
 Create an Excel template file. This should contain a table structure with columns to match
the ViewDef properties.
 Create a new Template document in SmartPlant Foundation and attach the file.
 Create a new Datalist Definition to link the ViewDef, template document and ClassDef to
create and enter the publish details:
 Check out the template document and run datasheet definer to map the ViewDef
properties to the Excel cells.
 Check in the template document.
 Test the load using the SmartPlant > Excel Publish option.
 Configure specific Excel Publish methods if you want to control which users publish
what type of template, and so on.
SECTION 10
Summary of Core Delivered Authoring

and Data Warehouse Models (OOTB)
The OOTB (out of the box) SmartPlant Foundation authoring and data warehouse database
contains the infrastructure to support design tool registration, data publish and retrieval, and the
basis for configuring equipment lists, data sheets, and so on for authoring and publishing data in
This section of the document details this infrastructure including the domains, methods, and
menus configured. It does not contain details of the line list configuration as this is covered in
detail in a How to Configure Line Lists Guide.
Domains and Their Usage

There are many domains delivered by default; the key domains for SmartPlant Foundation
authoring are described here.
SPFREFERENCE
This is a common domain. It contains classes for objects, such as the classification trees, that
are used in both SmartPlant Foundation authoring and in the data warehouse. It references the
SmartPlant Foundation domain that contains the majority of SmartPlant Foundation classes that
are used in both SmartPlant Foundation authoring and in the data warehouse such as
transmittals. The only reason to mention the SPFREFERENCE domain here is that it contains
the SPFPlant ClassDef that makes up part of the PBS tree that is created in SmartPlant
Foundation and published for retrieval by the tools.
They are what are referred to as „common‟ domains in that they are used in both SmartPlant
Foundation authoring and in the data warehouse.
SPFAUTHORING
This is an authoring domain; it contains the PBSAuthoringComponent and the
SPFAuthoringComponent component schemas.
PBSAuthoringComponent contains the SPFFunctionalArea and SPFFunctionalUnit ClassDefs
exposed in the Desktop Client tree view and used to author and publish the PBS hierarchy.
SPFAuthoringComponent contains the ClassDefs for data that is created in SmartPlant
Foundation and then published including the data sheet and list documents and supporting
objects such as adapter documents and registration objects. In SmartPlant Foundation release
2009 SP1 and before, this component schema incorrectly contained the design document,
vendor document, and contract ClassDefs, all of which were moved to SPFREFERENCE in
2009 R3 SP2. The only consequence of this is that it is not possible to turn off the
SPFAUTHORING domain when working in pure SmartPlant Foundation mode without losing
access to these classes. Also it is confusing when these classes are not actually authoring
objects as they cannot be published and can be used in authoring or in the warehouse.
Summary of Core Delivered Authoring and Data Warehouse Models (OOTB)
InstD
This is an authoring domain that was delivered as a place holder for configuring instrument lists.
It has been moved into the examples model area and not built into the OOTB database from
2009 R3 SP2 onwards.
MechanicalD
This is an authoring domain delivered that is ready for the installation of the mechanical
equipment data sheets from API.
ProcessD
This is an authoring domain. It supports the Instrument Process Data sheets (IPD). It contains
the schema for the design basis document, instrument, process point, and process case
ClassDefs. The actual data sheet document is defined in the SPFAUTHORING domain, but the
data that is published can be in any authoring domain.
DWShared
This is the special data warehouse domain that contains the shared objects that link together all
published data.
PBS
This is the data warehouse publish domain into which the PBS tree is published from
SmartPlant Foundation for retrieval by the tools.
PD
This is the data warehouse publish domain into which the process instruments are published
from SmartPlant Foundation using the Instrument Process Data sheets. ClassDefs in the
ProcessD authoring domain are mapped to ClassDefs in the PD domain.
Adapter Documents
The following adapter documents are supplied with the core delivered Authoring model. These
contain the files that control how SmartPlant Foundation authoring schema is mapped to the
SmartPlant schema and which interfaces get instantiated when the shared objects are created
in the data warehouse.
Adapter Header Files

 IDX Header - This is a legacy adapter header file and not built into the delivered database
from 2009 R3 SP2 onwards.
 IML Header - This was delivered as an example to support instrument master list authoring
in SmartPlant Foundation. This is a legacy adapter header file and not built into the OOTB
delivered database from 2009 R3 SP2 onwards.
 IPD Header - Defines how the data sheet information is retrieved and so on.
 LLA Header - Defines how line lists are retrieved and so on. For more information, see the
How to Configure Line List Guide.
 PBS Header - Defines how the PBS tree is published and so on.
 WBS Header - This is a legacy adapter header file and not built into the OOTB delivered
database from 2009 R3 SP2 onwards.
Map Files
 IDX Map Schema - This is a legacy adapter header file and not built into the OOTB
 IML Map Schema - This was delivered as an example to support instrument master list
authoring in SmartPlant Foundation.This is a legacy adapter header file and not built into the
OOTB delivered database from 2009 R3 SP2 onwards.
 IPD Map Schema - Defines the mapping between ProcessD and PD data.
 LLA Tool Map Schema - Defines the mapping for the line list. For more information, see
the How to Configure Line List Guide.
 PBS Map Schema - Defines the mapping for the PBS hierarchy.
 WBS Map Schema - This is a legacy adapter header file and not built into the OOTB
Roles and Message Access Groups

The commands available to a user working in SmartPlant Foundation are controlled by their role
which contains a set of message access groups that give access to the various commands. The
roles and message access groups delivered by for SmartPlant Foundation authoring and the
data warehouse, as well as the commands that they give access to are detailed below. Again,
the configuration for the line list is not detailed here as it is covered in the How to Configure Line
Lists guide.
The roles have many related message access groups, all of which are listed below, but only
those that are concerned specifically with authoring or the data warehouse are detailed further.
Details of the core message access groups can be found in the Configuring Document
Management Guide and the Configuring the Security Model Guide. When access groups are
related to roles, a domain can be identified on the relationship so that the user has access to
data in that domain. This domain access is explaned below.
Administration Roles
AuthoringAdministrator
Configuration of process case collections and adapter documents.
Related Message Access Groups:
Access Group Provides Access to...

AuthoringViewer Basic navigation, such as the PBS tree
AuthoringAdministrator Process case collections and adapter document
management
DocumentUpdate Create, update and edit documents
VIEWONLY View most general things such as folders and
queries. Plant items and Document covered by other
groups
DWAdministrator
Management of schema files, correlation activities, 3D composite documents, and published
data loading. This role gives access to the DWShared domain and its dependent tool domains.

DWAdministrator Schema file management and loading published data
DWEditor Manage correlations, 3D composite documents,

published data
DWViewer Basic access to published data via QFind and so on
queries. Plant items and Documents are covered by
other groups.
SchemaAdministrator
SmartPlant schema administration via the CMF file.

SchemaAdministrator Editing of the Schema CMF file and loading Schema

updates
queries. Plant items and Documents are covered by
other groups
PBSAdministrator
PBS management

AuthoringViewer Basic navigation, such as the PBS tree
PBSAdmin PBS creation, registration, publish, and so on

InstrumentationViewer Instrumentation and their categories
PlantItemView View plant items view tags only
VIEWONLY View most general things such as folders and queries.
Plant items and Documents are covered by other
groups such as PlantItemView
WBSAdministrator
WBS management

AuthoringViewer Basci navigation, such as PBS tree
WBSAdministrator Work Breakdown Structure management such as

plants and projects
PlantItemView View plant items view tags only
queries. Plant items and Document covered by other
groups
Authoring Roles
InstrumentationEngineer
Instrument creation through SmartPlant Foundation authoring

AuthoringViewer Basic navigation such as the PBS tree
InstrumentationViewer This relationship provides access to the InstD
domain
InstrumentationEngineer Used as a place holder for the development of the
authoring of instruments.
PlantItemView View Plant items and their view tags only
queries
InstrumentationViewer
Basic navigation of instrument creation through SmartPlant Foundation authoring

InstrumentationViewer This relationship provides access to the InstD
domain
queries
MechanicalEngineer
Mechanical equipment data sheet creation via SmartPlant Foundation authoring

MechanicalViewer This relationship provides access to the

MechanicalD domain. Used as a place holder for
the separate delivery of the mechanical
equipment data sheets
MechanicalEngineer Used as a place holder for the separate delivery
of the mechanical equipment data sheets.
PlantItemView View Plant items and their view tags only
queries
MechanicalViewer
Basic navigation of mechanical equipment data sheet creation through SmartPlant Foundation
authoring

MechanicalViewer This relationship provides access to the
MechanicalD domain. Used as a place holder for
the separate delivery of the mechanical
equipment data sheets
queries
ProcessEngineer
Process equipment creation through SmartPlant Foundation authoring

ProcessViewer Basic navigation of process data authored in
SmartPlant Foundation. This relationship
provides access to the ProcessD domain
ProcessEngineer Process equipment authoring in SmartPlant
Foundation including IPD data sheet generation
and publish as well as retrieval of PID data.
PlantItemView View most general things such as folders and
queries
queries
ProcessViewer
Basic navigation of process equipment creation through SmartPlant Foundation authoring

ProcessViewer Basic navigation of process data authored in
SmartPlant Foundation. This relationship
provides access to the ProcessD domain
PipingViewer and Piping Engineer

The roles are for the SmartPlant Foundation authoring of line lists.
Data Warehouse Roles

DWEditor
Managea correlation activities and 3D composite documents and also navigates and views
published data. This role gives access to the DWShared domain and its dependent tool
domains.

DWEditor Manage correlations, 3D composite documents, and so
on
VIEWONLY View most general things such as folders and queries
DWViewer
Navigates and views published data. This role gives access to the DWShared domain and its
dependent tool domains.

VIEWONLY View most general things such as folders and queries
Integration Roles
SmartPlantPublisher

SmartPlantPublisher Any role that performs the publish operation
SmartPlantRetriever

SmartPlantRetriever Any role that performs the retrieve operation
Authoring Methods
The delivered database contains a number of methods that configure SmartPlant Foundation
authoring.
Register Authoring Tool with SmartPlant Foundation
Method FrameworkRegisterPBS
Description Register for PBS
Domain SPFREFERENCE
Adapter Code PBS
Method FrameworkRegisterIntIPD
Description Register IPD with TEF (Interactive)
Domain ProcessD
Adapter Code IPD
Method FrameworkRegisterIntProcessCase
Description Register ProcessCase with TEF (Interactive)
Method FrameworkRegisterIntProcessCase
Domain SPFAuthoring
Adapter Code ProcessCase
Framework Retrieve
Method FrameworkRetrieveIPD
Description Retrieve IPD
Tool Adapter Prog SPFAdapter.TEFAdapters.SPTEFAdapter.GEN
IDArgument 1
Domain ProcessD
Adapter Code IPD
Method FrameworkRetrieveProcessCase
Description Retrieve ProcessCase
Tool Adapter Prog ID SPFAdapter.TEFAdapters.SPTEFAdapter.GEN
Domain SPFAuthoring
Compare with Design Basis

This method is used for comparing process data (in particular IPD data) with the associated
process engineering design basis file.
Method CompareDBasisIPD
Description Compare With Design
API Name CompareDBasis
Tool Comp Schema ProcessDesignComponent
Tool Domain ProcessD
Adapter Code IPD
Assembly Name SPFCompare.dll
Class Name SPFCompare.TEF.Compare.IPDCompareClass
Assign New UIDs True
Compare with Latest Retrieved Data

This method is used for comparing process data (in particular IPD data) with the last retrieved
process design basis file.
Method CompareLatestRetrievedDataForIPD
Description Compare Latest Retrieved Data For IPD
Tool Component ProcessDesignComponent
Tool Domain ProcessD
Adapter Code IPD
Class Name SPFCompare.TEF.Compare.IPDCompareClass
Method CompareLatestRetrievedDataForProcessCase
Description Compare Latest Retrieved Data For ProcessCase
Tool Component SPFAuthoringComponent
Tool Domain SPFAuthoring
ClassName SPFCompare.TEF.Compare.IPDCompareClass
Publish RHM
This method is used to publish the PBS hierarchy and is run from the right-click menu of the
plant.
Method FrameworkPublishPBSRHM
Description Publish PBS
Tool Adapter Prog ID SPFAdapter.TEF.Adapters,SPFTEFAdapterGEN
Domain SPFReference
Adapter Code PBS
The following method is run from a data sheet document to publish the contents of the data
sheet snapshot. See the data sheet configuration guide for more details on data sheet
documents.
Method FrameworkPublishDatasheetDoc
Method FrameworkPublishDatasheetDoc
Description Publish Snapshot
Tool Adapter Prog ID SPFAdapter.TEF.Adapters,SPFTEFAdapterGEN
Domain ProcessD
Adapter Code IPD
Publish by Query
These methods are run from the main menu and are used to query for and publish data.
Method FrameworkPublishIPD
Description Publish IPD
Domain ProcessD
Adapter Code IPD
Method FrameworkPublishProcessCase
Description Publish ProcessCase
Domain SPFAuthoring
Publish Data Sheet

This method is run directly off the tag and it generates the publish files on the fly without the
need for a data sheet document.
Method TEFPublishDatasheetIPD
Description Data sheet Publish IPD
API Name TEFPublishDatasheet
Data sheet type IPD
Data sheet Def UID
Domain ProcessD
Adapter Code IPD
APPENDIX A
Sample Adapter Document Load File

Copy and paste, and then edit this load file to load in the adapter document.
The following changes that have to be made:
 Consistently change the name and UID of the document master, revision, and version. The
names must be the same and it is recommended that the UIDs contain
master/revision/version and so on.
 Change the name and file name of the SPFAuthAdapterFile object.
 Update the relationships matching the changing UIDs of the document and file.
<Container CompSchema="SPFAuthoringComponent" Scope="Data" SoftwareVersion="04.02.00.00" ContainerID="Authoring">
<SPFAuthAdapterDocMaster>
<IObject Description="SPFAdapter_PAMaster" Name=" PA Header " UID="SPFAdapter_PAMaster" />
<ISPFDocumentMaster />
<ISPFNonPublishedDocMaster />
<ISPFAuthAdapterDocMaster SPFAuthAdapterCode="PA" />
<ISPFDocument SPFDocCategory="e1SPFSystemDocuments" SPFDocType="e1AdapterDocument" SPFTitle=""
SPFDocState="RESERVED"/>
</SPFAuthAdapterDocMaster>
<SPFAuthAdapterDocRevision>
<IObject Description="SPFAdapter_PARevision" Name=" PA Header " UID="SPFAdapter_PARevision" />
<ISPFDocumentRevision SPFExternalRevision="A1" SPFMajorRevision="A" SPFMinorRevision="1" SPFRevState="WORKING"
SPFRevUnderChangeInSameConfig="False" SPFSignoffComments="" />
<ISPFNonPublishedDocRevision />
<ISPFAuthAdapterDocRevision />
<ISPFWorkflowItem SPFTargetWorkflowName="" />
</SPFAuthAdapterDocRevision>
<SPFAuthAdapterDocVersion>
<IObject Description="PA Companion File" Name="PA Header" UID="SPFAdapter_PAVersion" />
<ISPFDocumentVersion SPFDocVersion="1" SPFIsDocVersionCheckedOut="False" SPFIsDocVersionSuperseded="False" />
<ISPFFileComposition />
<ISPFNonPublishedDocVersion />
<ISPFAuthAdapterDocVersion />
</SPFAuthAdapterDocVersion>
<SPFAuthAdapterFile>
<IObject Description="SPFAdapter_PAFile" Name="SPFAdapter_PAFile" UID="SPFAdapter_PAFile" />
<ISPFAlternateRenditionComposition />
<ISPFFile SPFLocalHostName="localhost" SPFLocalDirectory="C:\" SPFLocalFileName="SPFAdapter_PA.xml" />
<ISPFNavigationFileComposition />
<ISPFRefFile />
<ISPFAuthAdapterFile />
<ISPFDBFile />
</SPFAuthAdapterFile>
<SPFUploadInstruction>
<ISPFUploadInstruction FilePath="SPFAdapter_PA.xml" RemoveLocalFileInd="False"/>
<IRefObject RefClass="SPFAuthAdapterFile" RefUID="SPFAdapter_PAFile" RefName="SPFAdapter_PAFile" />
</SPFUploadInstruction>
<Rel>
<IRel DefUID="SPFFileVault" UID1="SPFAdapter_PAFile" UID2="VLT_SPF40Vault"/>
<IObject UID="SPFAdapter_PAFile.VLT_SPF40Vault" />
</Rel>
<Rel>
<IRel DefUID="SPFFileComposition" UID2="SPFAdapter_PAVersion" UID1="SPFAdapter_PAFile"/>
<IObject UID="SPFAdapter_PAFile.SPFAdapter_PAVersion" />
</Rel>
<Rel>
<IRel DefUID="SPFFileFileType" UID1="SPFAdapter_PAFile" UID2="FT_xml" />
<IObject UID="SPFAdapter_PAFile.FT_xml" />
</Rel>
<Rel>
<IObject UID="SPFAdapter_PAVersion.DAG_ADMIN" />
<IRel DefUID="SPFItemOwningGroup" UID1="SPFAdapter_PAVersion" UID2="DAG_ADMIN" />
</Rel>
<Rel>
<IObject UID="SPFAdapter_PAMaster.SPFAdapter_PARevision.MR" />
<IRel DefUID="SPFDocumentRevisions" UID1="SPFAdapter_PAMaster" UID2="SPFAdapter_PARevision" />
</Rel>
<Rel>
Sample Adapter Document Load File
<IObject UID="SPFAdapter_PARevision.SPFAdapter_PAVersion.RV" />
<IRel DefUID="SPFRevisionVersions" UID1="SPFAdapter_PARevision" UID2="SPFAdapter_PAVersion" />
</Rel>
<Rel>
<IObject UID="SPFAdapter_PARevision.RS_SPFRevisionScheme" />
<IRel UID1="SPFAdapter_PARevision" UID2="RS_SPFRevisionScheme" DefUID="SPFDocRevisionRevisionScheme"/>
</Rel>
</Container>
Index
ComponentSchema or
A PublishToComponentSchema • 58
Configuration for Equipment List Editing •
Ad Hoc Report List View Changes • 20 115
Adapter Code • 128, 130 Configuration of a List Document • 111
Adapter Document • 33 Configuration of a Separate Equipment List
Adapter Document Configuration • 120 Object and Document • 114
Adapter Document Diagram • 33 Configuration of Roles for the Equipment
Adapter Documents • 140 List • 114
Adapter Header File Configuration • 121 Configuration of the Equipment List
Adapter Mapping File Configuration • 120 Document • 116
Add the PBS to SmartPlant Foundation and Configuration to Create and Manage the
Test • 85 Authored Data • 111
Additional Configuration for Managing Configuration to Generate the Document
Equipment • 114 Snapshot • 119
Additional Schema Considerations • 107 Configuration to Load Equipment from
Additional Schema to Support Equipment Excel • 120
List Authoring • 111 Configuration to Support Consolidation •
Administration Roles • 141 105
Approving the Data • 19 Configure a Publish Method • 99
Architecture of SmartPlant Data Warehouse Configuring a Design Basis Document • 128
• 14 Configuring Data Warehouse Inconsistency
Architecture of SmartPlant Foundation Reports • 133
Authoring • 13 Configuring Domains • 110
Assembly Name • 131 Configuring Equipment List Authoring • 120
Assign New UIDs • 131 Configuring Excel Load for the Equipment
Authoring and Data Warehouse Overview • List • 136
13 Configuring Excel Publish for the
Authoring Interfaces Diagram • 36 Equipment List • 137
Authoring Methods • 146 Configuring Exposure of the Published Data
Authoring Model • 31 • 132
Authoring Process Overview • 15 Configuring Publish for Authored Data • 122
Authoring Roles • 143 Configuring Retrieve for Objects Published
Authoring Schema to Support the PBS by Other Tools • 126
Hierarchy • 108 Configuring SkipFailedDocuments • 125
Configuring the Authoring Environment •
C 111
Check In the CMF file • 77 Configuring the Retrieve and Compare
Check Out the SmartPlant Schema CMF Process • 126
File • 75 Configuring the Shared Interface for the
Class Name • 131 Published Equipment • 104
CMF File and Physical Pseudo Files • 61 Converting an Existing Pseudo File into a
Compare • 60 Physical Pseudo File • 65
Compare Section of the Adapter Header Create a New PBS Template • 89
File • 60 Create a New Plant Group • 90
Compare with Design Basis • 130, 147 Create the Adapter Mapping Document in
Compare with Latest Retrieved Data • 131, SmartPlant Foundation • 120, 121
148 Creating a New Pseudo File in the Schema
Component Schemas • 13 Editor • 63
Index
Creating a Sub Configuration • 18 Generate Component Schema Files • 80

Creating the Tool Map Schema • 108 Generate SmartPlant Foundation Authoring
PBS Configuration • 80
D Generating the Authoring Schema and
Mapping • 106
Data Flow through the Domains • 21 GetPublishableDocTypes • 49
Data Load • 25 GetSameAsUIDsForPublish • 50
Data Publish • 22
Data Warehouse Model • 37
Data Warehouse Process Overview • 17 H
Data Warehouse Publish Schema Creation History • 21
• 105 How to Configure Excel Publish • 97
Data Warehouse Roles • 145 How to Configure SmartPlant Foundation
Datasheet Definition Creation • 98 Authoring • 101
Define the Plant Breakdown Structure How to Extend the Integration Schema • 61
(PBS) Hierarchy from a Template • 75
Defining and Mapping the Authoring I
Schema • 106
Defining the Data Warehouse Schema • IInstruction Interface • 47
102 Include Plants in a Configuration • 88
Design Basis • 35 Integration Hierarchy Limitations • 71
Design Basis Document Configuration • 128 Integration Roles • 146
Design Basis File • 35 Interfaces Used with Authoring • 35
DesignBasisComponentSchema • 57 Introduction • 9
Detail Form • 20 ISPFAuthAdapterClass Interface • 34
DocCategory • 58 ISPFAuthAdapterDocMaster Interface • 34
DocSubtype • 58 ISPFAuthPublishableItem Interface • 36
DocTitle • 58 ISPFAuthPublishedItem Interface • 36
DocType • 58 ISPFAuthRegistration Interface • 32
DocTypes/Document • 59 ISPFDesignBasisFile Interface • 35
DocumentToPublish • 58 ISPFLocalServer Interface • 33
Domain • 128 ISPFServer Interface • 32
Domains and Their Usage • 139 ISPFTEFDocumentMetaDataFile Interface •
41
ISPFTEFInstructionFile Interface • 41
E ISPFTEFPublishedDocVersion Interface •
Edit the Plant Breakdown Structure (PBS) 39
Hierarchy Template • 91 ISPFTEFPublishInstruction Class Definition
EFSchema • 14 • 46
Example of the UpdateClassInstruction • 70 ISPFTEFPublishInstruction Interface • 46
Example Process Engineer Class Design ISPFTEFQueue Interface • 43
Basis Classes • 35 ISPFTEFSchemaDocVersion Interface • 42
Excel Template Document Creation • 98 ISPFTEFSchemaItem Interface • 43
ExpandToSecondaryItems • 50 ISPFTEFSignature Interface • 41
ExpandUsingGraph • 57 ISPFTEFTool • 41
Extracting the Schema Files to Load • 66 ISPFTEFToolDataFile Interface • 40
ISPFTEFViewableFile Interface • 41
F ISPFTEFXMLFile Interface • 40
Framework Retrieve • 147
L
G List Document with Separate List Object •
118
Generate a Tool Map Schema from a
Spreadsheet Tool • 54
Index
List Document without a Separate List Publish • 57

Object • 116 Publish and Retrieve • 16
Load New Schema Files for the Alternate Publish by Query • 124, 149
PBS • 84 Publish Data Sheet • 124, 149
Load Published Data • 125 Publish Domains • 15
Load the CMF Data Changes into the Data Publish Object or Document • 123
Warehouse Database • 78 Publish RHM • 148
Load XML files to run Inconsistency Publish Section of the Adapter Header File •
Reports on an Updated Database • 135 57
Loading Schema Changes into the PublishDocument • 49
SmartPlant Foundation Database • 65 Published Loader Operation • 69
Loading the Authoring Schema into Published Schema Definition • 97
SmartPlant Foundation • 108
Loading the Data into the Configuration • 19 Q
Loading the Exported Files into SmartPlant
Foundation • 67 QueryForInterface • 57
Loading the Publish Schema into Quick Find • 19
SmartPlant Foundation • 105
Loading the Schema File • 106 R
Loading the Unapproved Data • 18 Regenerating New Component Schema
Login to the Configuration • 18 Files • 67
Register Authoring Tool with SmartPlant
M Foundation • 146
Map the ViewDef to the Excel Template • Register Tool • 122
99 Registration • 15
Mapping the Retrieved SmartPlant Schema Registration Object • 31
to the Authoring Schema • 127 Registration Object Diagram • 31
Merging a Previously Generated Schema Remove the Existing PBS Structure • 73
into a Pseudo File • 64 Retrieve • 59
Retrieve Document • 127
Retrieve Section of Adapter Header File •
O 59
OnRetrieve • 59 RetrieveDocument • 50
Opening the CMF file for Editing • 62 Retrieving Data Authored in SmartPlant
OutputDebugFiles • 60 Foundation into Other Tools • 136
Overview • 69 Roles and Message Access Groups • 141
P S
Plant Breakdown Structure for Integration SameAs Relationship • 28
Setup • 70 Sample Adapter Document Load File • 151
Plant Naming Guidelines • 71 Schema Component • 14
PopulateDataContainerForPublish • 50 Setting Up Publish and Retrieve Roles •
PopulateMetaDataContainer • 50 121
PRCDesignBasisDocMaster/Revision/Versi Shared Domain • 15
on • 35 Shared Object Configuration for Data
Preface • 7 Mining • 103
Pre-Loading Data for Approval • 18 Shared Objects • 25
Prepare the CMF Data to be Loaded into Shared Objects (Multiple Domains) • 26
SmartPlant Foundation • 77 SmartPlant Client • 14
Preparing the Schema Load File • 105 SmartPlant Foundation Adapter • 14, 49
Properties Grid • 20 SmartPlant Foundation Authoring Adapter
Pseudo Files and ContainerID • 61 Details • 49
Index
SmartPlant Foundation Authoring Client Summary of Core Delivered Authoring and

and Server • 13 Data Warehouse Models (OOTB) • 139
SmartPlant Foundation Data Warehouse Supporting an Object Change of ClassDef •
Client and Server • 14 69
SmartPlant Integration Document Object
Diagram • 37 T
SmartPlant Integration Published Document
Diagram • 38 Tool Component Schema • 130
SmartPlant Integration Published Tool Domain • 130
Instructions Diagram • 45 Tool Map File Definition of the Authoring
Special Edge Definitions • 132 Schema • 51
SPFAuthAdapterClassClassDef Tool Map File Mapping Definitions for the
Relationship Definition • 34 Authoring Schema • 52
SPFAuthAdapterFile • 34 ToolComponentSchema • 57
SPFAuthRegistration Class • 32 ToolParameters • 49
SPFRegistrationConfig Relationship ToolSchemaMapFile • 57
Definition • 32
SPFRegistrationServer Relationship U
Definition • 32 Usage of Standard SmartPlant Foundation
SPFTEFConfigQueue Relationship Interfaces • 107
Definition • 44 Using Schema Editor to View and Validate
SPFTEFDesignBasis Relationship Tool Map Files • 52
Definition • 44
SPFTEFDocVersionSchemaItem
Relationship Definition • 44
V
SPFTEFMovedSignatureConfigData ValidLineEndObjects • 60
Relationship Definition • 44 View Shared Data (Inconsistencies) Form •
SPFTEFPublishedDocMaster Class • 39 20
SPFTEFPublishedDocRevision Class • 39 ViewDef Creation • 97
SPFTEFPublishedDocVersion Class • 39 Viewing the Data Warehouse Items • 19
SPFTEFPublishedDocVersionInQueue
Relationship Definition • 44 W
SPFTEFPublishedFile Class • 40 Work Process for Creating a Custom PBS
SPFTEFQueue Class • 43 Hierarchy • 72
SPFTEFRetrievedDataDesignBasis Work Process for Creating or Modifying a
Relationship Definition • 44 PBS Hierarchy Template • 89
SPFTEFRetrievedDesignBasis Relationship Workflow • 70
Definition • 42, 44 Writing a Tool Map Schema • 51
SPFTEFSchemaDocMaster Class • 42 Writing an Adapter Header File • 55
SPFTEFSchemaDocRevision Class • 42
SPFTEFSchemaDocVersion Class • 42
SPFTEFSchemaFile Class • 43
SPFTEFSchemaItem Class • 43
SPFTEFSchemaItemToSchemaVersion
SPFTEFSignature Class • 41
SPFTEFSignatureConfigurationItem
SPFTEFSignaturePublishedDocument
SPFTEFSignatureToolParameter
Steps to Configure the Excel Publish • 97

Howto Configurethe Authoringand DWHModels

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

Howto Configurethe Authoringand DWHModels

Uploaded by

Copyright:

Available Formats

SmartPlant Foundation

How to Configure the Authoring and Data

Authoring and Data Warehouse Overview .............................................................................................. 13

Authoring Model ........................................................................................................................................ 31

Data Warehouse Model ............................................................................................................................. 37

SmartPlant Foundation Authoring Adapter Details ............................................................................... 49

Writing an Adapter Header File ............................................................................................................. 55

How to Extend the Integration Schema ................................................................................................... 61

Published Loader Operation .................................................................................................................... 69

Plant Breakdown Structure for Integration Setup .................................................................................. 70

How to Configure Excel Publish .............................................................................................................. 97

Map the ViewDef to the Excel Template ........................................................................................ 99

How to Configure SmartPlant Foundation Authoring ......................................................................... 101

Publish RHM ................................................................................................................................. 148

Sample Adapter Document Load File .................................................................................................... 151

Index ......................................................................................................................................................... 153

SmartPlant Foundation Product Documentation

Model Configuration Guides

Different Uses for SmartPlant Foundation

Mapping and Data Transformations

SmartPlant Foundation Domains

Overview of SmartPlant Foundation Data Segregation

SmartPlant Foundation Authoring

Authoring and Data Warehouse

Architecture of SmartPlant Foundation Authoring

SmartPlant Foundation Authoring Client and Server

Authoring Component Schema

Process Design Component Schema

SmartPlant Foundation Adapter

Architecture of SmartPlant Data Warehouse

SmartPlant Foundation Data Warehouse Client and Server

In order to prevent duplicating data between SmartPlant Foundation authoring and

Authoring Process Overview

Publish and Retrieve

Data Warehouse Process Overview

Pre-Loading Data for Approval

Creating a Sub Configuration

Login to the Configuration

Loading the Unapproved Data

Approving the Data

Loading the Data into the Configuration

Viewing the Data Warehouse Items

View Shared Data (Inconsistencies) Form

Ad Hoc Report List View Changes

Data Flow through the Domains

Optional Data Load

Shared Objects (Multiple Domains)

Registration Object Diagram

Name Description Set On

SPFRegistrationConfig Relationship Definition

Name Description Set On

SPFRegistrationServer Relationship Definition

Adapter Document Diagram

Name Description Set On

SPFAuthAdapterClassClassDef Relationship Definition

Design Basis File

Example Process Engineer Class Design Basis Classes

Interfaces Used with Authoring

Authoring Interfaces Diagram

Name Description Set On

Name Description Set On

Data Warehouse Model

SmartPlant Integration Document Object Diagram