using_xml

WWW.FIATECH.ORG

ELEMENT 3

PROCUREMENT

USING XML SCHMAS FOR FACILITIES EQUIPMENT

AEX PROJECT

USING XML SCHEMAS FOR FACILITIES EQUIPMENT

19 July 2004

Version 2.0 T. L. Teague, R. W. Turton and M. E. Palmer

EXECUTIVE SUMMARY This document provides an overview of a suite of XML schemas for the design, procurement and operation of capital facilities equipment and explains the overall structure, design philosophy and usage conventions. A tutorial illustrating how the schemas can be used in software implementations and extended to add custom information models is included. This set of XML schemas was developed collaboratively over 2 years between the FIATECH Automating Equipment Information eXchange (AEX) Project, the AIChE Design Institute for Physical Properties (DIPPR) 991 project, ePlantData and the National Institute of Standards and Technology (NIST) AEX Testbed to form this initial release of the capital facilities equipment XML schemas.

The focus of this work is to support a number of key work process transactions associated with engineered equipment over the capital facility life cycle, including Engineering, Procurement, Construction, Operations and Maintenance (EPCOM). From the list of potential equipment types important to the AEX Project sponsors, the project team chose centrifugal pumps and shell and tube exchangers as the initial scope, in recognition that these are some of the most common types of equipment in a typical capital facility. Over 20 transactions in the life of engineered equipment were identified as valuable for automating, and from this list of 20, the AEX Project identified 5 as having high potential for significant economic benefits. These 5 scenarios include:

Request for Quote (RFQ)

Quote

Purchase Order (PO)

As-built

Bill of Materials

In making this assessment, we noted that it was important to capture usage scenarios that cross the organizational boundaries between owner, EPC, and suppliers. The rationale for this is that many companies are working on software interoperability and integration capabilities within their own companies, but they recognize that a common industry approach is needed to cross the organizational boundaries and offers the highest potential benefit for the industry.

Using XML Schemas for Facilities Equipment, v.2.0 - 1 - 19 July, 2004

FIATECH AEX Project

These XML schemas have been developed with an object-oriented schema framework to support equipment item data, process material data that appear on equipment datasheets, procurement data and relevant project data. The initial subject focus of this work is:

1. Basic equipment information found on various equipment lists and bill of materials documents.

2. Equipment datasheets for centrifugal pumps and shell and tube exchangers (which include process material properties)

3. Process materials, associated properties, calculation methods and experimental property data

4. Equipment documents used over the life cycle of capital facilities.

While the scope is initially limited to these types of information, we have approached the schema design with the requirement that the base schema structures be capable of handling any equipment item, any engineering document, any material property relevant to capital facilities and extensions by users. Therefore, it is possible to use these schemas to describe any equipment item and any engineering document. At this point in time, we have only provided in-depth attribution for centrifugal pumps, shell and tube exchangers and their associated datasheets. Because of the effort to create a robust, reusable schema framework, we anticipate that extensions of this XML framework to handle other types of equipment items will be very straightforward and cost-effective.

The schema architecture is designed to fit within the larger context of information management for capital facilities, project management, supply chain optimization and procurement. The contributors to this set of schemas share a common vision of the collaborative development by multiple organizations of a cohesive set of XML schemas to support automating the information exchanges over the life cycle of capital facilities. With this goal, the cooperating organizations agreed to establish an “umbrella label” for these schemas: cfiXML (capital facilities industry XML). We are continuing to broaden collaboration with additional XML development efforts to achieve this goal.

There are four basic parts to the capital facilities equipment XML architecture:

1. Core data type schemas for extensions to basic data types to support engineering requirements (these are essential extensions added to the “XSD” base data types provided in the W3C XML Schema standard),

2. Core engineering object schemas for reusable, base engineering objects that can be used by multiple engineering disciplines and subject domains

3. Subject engineering object schemas that provide schemas related to specific equipment items

4. Collection-container schemas that are used to model engineering document and project document schemas. The collection-container schemas allow core and subject-specific engineering objects to be combined in various ways to support various data transactions and usage scenarios.

The components of these schemas are divided into XML namespaces for ease of schema development by various disciplines, work groups and organizations, managing and isolating schema inter-dependencies, and providing for flexible schema reuse and schema maintenance.

In constructing this XML schema framework, we carefully selected schema design principles to build schemas in line with the best practices advocated by the XML development community (see http://www.xfront.com/BestPracticesHomepage.html). We have documented these results in a companion document: FIATECH XML Schema Development Guidelines.

We believe the schemas are relatively straightforward to review and understand with the use of XML parsing tools and the examples in this document. Additionally, the schemas can be readily extended to model other equipment items. A discussion on how to use the schemas is included, together with an illustrative example for some centrifugal pump data items. The example also illustrates how the schemas may be extended to include user-supplied extensions to the schema.

Using the cfiXML Schemas - 2 - 19 July, 2004

http://www.xfront.com/BestPracticesHomepage.html

FIATECH AEX Project

REVISION HISTORY Release Date Notes

1.0 18 Sept 02 Initial release for industry review and comment.

1.1 4 Nov 02 Revised to include initial round of industry comment and to restructure some parts of the document (schema design principles) to be in a separate related document.

1.2 26 Nov 02 Revised to include additional industry comments during November

1.3 13 Dec 02 Updated equipment types list

1.4 28 April 03 Revised to include additional industry feedback and schema evolution from November

1.5 21 June 2004 Revised to include results from the AEX Testbed evaluation and expanded to illustrate how to use and extend the schemas in practical software implementations.

2.0 19 July 2004 First Public release for industry software implementation


FIATECH AEX Project

TABLE OF CONTENTS

EXECUTIVE SUMMARY 1

REVISION HISTORY 3

TABLE OF CONTENTS 4

READER’S ORIENTATION TO THIS DOCUMENT 5

COPYRIGHT AND LICENSE NOTICE 5

1. BUSINESS USAGE CONTEXT 6 1.1 Business Motivation 6 1.2 Major Usage Scenarios 7 1.3 Software Usage and Transaction Survey 7 1.4 Candidate Software Packages 12

2. SCHEMA INTRODUCTION 13 2.1 XML Usage Scenario – Messaging and File Exchange 14 2.2 Schema Scope 14 2.3 Schema Structural Overview 14 2.4 Namespaces Overview 15 2.5 Core Data Types Overview 17 2.6 Core Objects Overview 18 2.7 Subject Schemas Overview 19 2.8 Equipment Types Classification 20 2.9 Container-Collector Overview 21 2.10 Messaging and Business Protocol Containers 21 2.11 Naming and Sequence/Choice Ordering Conventions 21 2.12 Object Management 22 2.13 Schema Extensibility 23 2.14 Schema Object Library 23 2.15 Namespace and File Folder Organization 24

3. SCHEMA OVERVIEWS 26 3.1 Extended Data Types (ext: namespace) 26 3.2 Physical Quantities (pq: namespace) 27 3.3 Engineering Type Library (etl: namespace) 28 3.4 Objects (obj: namespace) 29 3.5 Context and Projects (ctx: and proj: namespaces) 29 3.6 Documents (dx: namespace) 30


FIATECH AEX Project

3.7 Equipment (eq: namespace) 32 3.8 Materials and Properties (mtrl: namespace) 33 3.9 Unit Operations (uo: namespace) 34 3.10 Site (site: namespace) 34 3.11 Rotating Equipment (eqRot: and eqRotDoc: namespaces) 35 3.12 Heat Exchange Equipment (eqHx: and eqHxDoc: namespaces) 37

4. GETTING STARTED WITH CFIXML 39

5. PUMP TUTORIAL – USING AND EXTENDING THE SCHEMAS 40 5.1 Part 1 – Using the existing schemas 41 5.2 Part 2 – Extending/Customizing the schemas 44

APPENDIX A. UML NOTATION REFERENCE 48

APPENDIX B. DATA TYPES (EXT: NAMESPACE) 49

APPENDIX C. PHYSICAL QUANTITIES (PQ: NAMESPACE) 51

APPENDIX D. MATERIAL PROPERTIES (MTRL: NAMESPACE) 60

APPENDIX E. ABBREVIATION TABLE 65

APPENDIX F. EQUIPMENT TYPES CLASSIFICATION 68

QUESTIONS AND FEEDBACK 73

READER’S ORIENTATION TO THIS DOCUMENT In addition to this document, two other resources are available:

Schema Architecture (a narrated PowerPoint presentation which introduces the cfiXML schema architecture to software owners and implementers).

XML Schema Development Guidelines (introduces XML technology and contains principles and recommended processes for developing XML schemas)

If you are an XML schema developer who wants to extend the facilities equipment XML schemas for your own use you may want to review the XML Schema Development Guidelines, which describes in some detail the capital facilities industry XML schema design philosophies and usage conventions.

The cfiXML schema files and examples are provided separately. They should be installed and used in a single common folder according to the recommended folder structure. While XML schema definition files can be reviewed in native text formats, we highly recommend that XML schema files should be reviewed in an XML schema interactive development environment such as XML Spy from Altova, Inc. TurboXML from TIBCO, or VisualStudio from Microsoft.

COPYRIGHT AND LICENSE NOTICE Several organizations contributed to the development of the XML schemas for exchanging capital facilities equipment information and we anticipate that additional organizations will openly contribute to its development in the future. Fundamental to this open, cooperative development is the agreement that the resulting schemas will be freely available for anyone to use. In order to maintain suitable configuration control, while allowing organizations


FIATECH AEX Project

to continue to develop improvements and additions, the following open source licenses and copyright language is included with all schema files. “Portions Copyright (C) 2001-2004 AIChE-DIPPR, All Rights Reserved. Portions Copyright (C) 2001-2004 ePlantData, Inc., All Rights Reserved. Portions Copyright (C) 2002-2004 FIATECH, All Rights Reserved. This file contains Original Code and/or Modifications of Original Code (the "Contents") as defined in and that are subject to the DIPPR Public Source License Version 1.0, the ePlantData Public Source License Version 1.0 and the FIATECH Public Source License Version 1.0. Copies of these licenses are available at http://www.cfixml.org. You may only use the Contents according to the terms and conditions in these Licenses. The Contents are distributed for use on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED. LICENSOR HEREBY DISCLAIMS ALL SUCH WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.”

1. BUSINESS USAGE CONTEXT The Guidelines for Developing XML Schemas describes a process for developing XML schemas. This process includes as the initial activity, understanding and documenting the business context, usage scenarios and information requirements for the schemas being developed.

1.1 Business Motivation As capital facilities are conceived, designed, constructed, operated and maintained a huge amount of information is assembled and used by many companies. Today this digital information is created and used in a number of incompatible software systems. This makes sharing, reuse and long-term archival of digital information over the facility life cycle difficult, time-consuming and expensive. This problem is estimated to cost the capital facilities industry at least a billion dollars a year.

The quantification of the cost or lack of interoperability in the capital facilities industry is subject of a current NIST research study. A previous NIST study for the automotive industry identified costs associated with lack of interoperability in that industry at upwards of $1 Billion annually. Other studies from CII and NIST have estimated that significant improvements in the automation and integration of software systems in the capital facilities industry could be worth up to 8% of total project capital cost, a 14% reduction in project schedule and 5-15% reduction in annual maintenance costs. Applying these percentages to the estimated $100 billion annual capital facilities investment suggests that $1 Billion per year is a reasonable, if not conservative estimate for industry-wide benefits. For any one large company engaged in capital projects, the benefits are potentially millions of dollars annually. For example, a large chemical company recently estimated that $375,000 savings per year could be achieved just for pump procurement in their process plant facilities.

The solution to this problem has been recognized for a number of years – software data interoperability through implementation of commonly agreed digital data interchange formats in industry software. Therefore solving the problem only requires that industry organizations agree upon and implement common electronic information exchange protocols. Extensible Markup Language (XML) is an Internet technology standard that offers, for the first time, a widely used, cost-effective implementation technology to solve the software interoperability problem. However, XML is merely an enabling technology and does not solve the problem by itself. Rather, it is the combination of XML technology and pragmatic industry consensus and software implementations that ultimately solves the problem for the industry. FIATECH, DIPPR and ePlantData have initiated an open industry cooperative effort over the last 2 years and have adopted an umbrella name of Capital Facilities Industry XML (cfiXML). It is a voluntary collaborative and cooperative effort undertaken by these organizations that are aimed towards achieving a pragmatic industry consensus around the use of XML technology to achieve the noted economic benefits for capital facilities equipment and material properties. These industry groups share a common vision of the collaborative development by multiple


FIATECH AEX Project

organizations of a cohesive set of XML schemas to support automating the information exchanges over the life cycle of capital facilities.

1.2 Major Usage Scenarios The focus of the DIPPR 991 project for physical properties data exchange (PPDX) is to support the exchange of information about materials and material properties to support Engineering work processes for process facilities. In particular the following exchange scenarios are of interest:

Experimentally measured material properties data capture, reporting and retrieval

o To/from scientific journals and experimental databases and analysis tools

o Tables of measured properties, sample description, citation information

Comparison of calculated and measured physical properties data

Transferring regressed calculation method parameters to other tools that calculate or predict material properties

Reporting or sharing of calculated properties.

o Property tables and curves

o Process simulation stream tables

o Material properties on equipment data sheets

The FIATECH AEX project addresses engineered equipment information over the facility life cycle including Engineering, Procurement, Construction, Operations and Maintenance (EPCOM). From the list of potential equipment types of interest to AEX sponsor organizations, centrifugal pumps and shell and tube exchangers were chosen in recognition that these are the most common types of process equipment in a typical capital facility. Over 20 transactions in the work process over the life of engineered equipment were identified, and from this list of 20 identified 5 as having a high potential importance towards capturing economic benefits. These 5 scenarios include:

Request for Quote (RFQ)

Quote

Purchase Order

As-built

Bill of Materials

In making this assessment, the FIATECH AEX project noted that it was important to capture usage scenarios that cross the organizational boundaries between owner, EPC, and suppliers. The rationale for this is that many companies are working on software interoperability and integration capabilities within their own companies, but recognize that having a common industry approach was needed to cross the organizational boundaries, and therefore offers the highest potential benefit for the current project work.

The FIATECH AEX project continues its focus is on demonstrating working software implementations for centrifugal pumps as well as extending the cfiXML schemas to additional high priority equipment types. These include induction electric motors, air cooled heat exchangers, centrifugal compressors and fans, reciprocating compressors, pressure vessels, control valve, relief valve, transmitters.

1.3 Software Usage and Transaction Survey In addition to identifying the above major usage scenarios DIPPR, and FIATECH did a limited survey of the work processes and the various software packages that produce and consume material properties and equipment information over the life cycle. In this analysis, the general types of software packages were identified and the key documents that are used to transmit information from one software package to another were noted. As expected, the equipment datasheet is a key document for transmitting such information. The other key document type was the equipment list or bill of materials, which provide a subset of summary information about equipment items. In


FIATECH AEX Project

practice equipment datasheets, equipment lists and engineering drawings all need to be maintained in a synchronized state, but this task is difficult, because different software packages are often used to produce the various engineering documents.

A diagram showing the key types of software and the key engineering information transmittal documents are shown in the two Software Information Flows diagrams on the following pages. The first diagram pertains to the software and information flows related to material properties, while the second diagram pertains to the software and information flows related to process equipment.

Material Properties – Software and Data Flow Description

Process /EquipmentSimulator

DatasheetSoftware

ProcessSimulation

Lab DataReportingSystem

PropertiesTable

DataCaptureSoftware

PropertiesTable

PublishedExperimental

Database

DataEvaluation/RegressionSoftware

RegressedParametersDatabase

MethodParameters

PropertiesSimulator

PropertiesTable

PaperPublications

SoftwareSystem

ElectronicDocument

Legend

Note: Heavy weighted linesindicate initial opportunity areas

EvaluatedExperimental

Database

A laboratory measures physical property measurements in a spreadsheet or a Laboratory Data Automation and Reporting system and reports the result in a property table containing measurement data.

The data may be presented in the form of paper publications or laboratory reports that contain one or more measured property data tables.

Laboratory property data tables are captured either in spreadsheets or in data capture software, which may then be transferred to published experimental property databases.

Laboratory property data tables are evaluated for data quality and transferred to evaluated experimental property databases.

Experimental property data is obtained from published or evaluated property databases and imported into data regression software for the purpose of fitting predictive calculation model parameters to fit the available experimental data.

Existing calculation model parameters are retrieved from regressed model parameter databases for the purpose of fitting predictive calculation model parameters to fit available experimental data.


FIATECH AEX Project

Regressed model parameters are shared with programs that calculate or predict physical properties using the calculation model parameters, including process simulators, properties simulators, or equipment design software.

Properties simulators and process simulators produce tables or single instances of calculated properties, including property curves, streams and simulation stream summaries.

Stream properties, property curves, and simulation stream summaries are shared with equipment design software and equipment datash

Equipment Life Cycle – Software Data Flow Description

Engineering

The process engineer uses a Process Simulator to produce a Process Simulation Results document. The process engineer uses Datasheet Software and the Process Simulation Results document to create a “process” Equipment Datasheet document. Mechanical engineers take the “process” Equipment Datasheet document as input to an Equipment Design program, which produces Equipment Design Results. The mechanical engineer uses Datasheet Software to incorporate Equipment Design Results and produce a “mechanical” Equipment Datasheet document. The mechanical Equipment Datasheet may be issued to the Owner for review comments and approval by Email or Collaboration software. The Owner may submit review and approval comments on the Equipment Datasheet using Email or Collaboration software. Key information about the equipment item is taken from the Equipment Datasheet and incorporated into Equipment List Software to produce an Equipment List. Instrument, electrical and piping engineers produce instrument, electrical and piping component Equipment Datasheets and Equipment Lists similar to the way mechanical engineers produce mechanical Equipment Datasheets and Equipment Lists. The cost engineer enters key information from the various Equipment Lists into the Cost Estimating software to produce a cost estimate. The scheduling engineer enters key information from the various Equipment Lists into the Planning and Scheduling software. The 2D CAD operator enters key information from the various Equipment Lists into the Intelligent 2D drawing software to produce PFDs, P&IDs and arrangement drawings. The 3D CAD operator enters key information from the Equipment List into the 3D CAD system to produce 3D models of the system and associated 2D views of the model, such as arrangement drawings and isometric drawings. The 2D and 3D CAD systems periodically issue Bill of Materials and Equipment List reports as equipment items are added to / modified in the CAD systems during detailed engineering design.

Procurement

The mechanical/instrument/electrical/piping engineer completes an Inquiry Requisition document, which refers to one or more equipment items.


FIATECH AEX Project

The mechanical/instrument/electrical/piping engineer provides the Inquiry Requisition document to a buyer. The buyer enters key information from the Inquiry Requisition document or Equipment List into the Procurement System. The buyer submits the Inquiry Requisition, including attached Equipment Datasheets to prospective suppliers as a Request For Quotation (RFQ). This is typically done by fax and Email. The Supplier engineer receives the Inquiry Requisition and enters key data about the prospective customer and the Inquiry Requisition into the Supplier’s Order Entry and Tracking system. The Supplier engineer enters data from the buyer Equipment Datasheet into the supplier’s Equipment Design and Cost Estimating programs for the purpose of verifying the buyer equipment design, performing specific equipment selection, equipment performance rating and cost estimating required to provide a quotation to the prospective buyer. The Supplier engineer prepares a Quote and submits it along with a revised Equipment Datasheet, that includes any changes that were needed in the course of preparing the Quote. The Quote is typically emailed or faxed to the prospective buyer. The Suppler engineer may be requested by the buyer to re-key the summary information that is to be included in the buyer Bid Tabulation software (spreadsheet or web site form). The buyer and the mechanical engineer review the Supplier Quotes using the Bid Tabulation software and make a recommendation supplier selection. The supplier selection recommendation and the Bid Tabulation results are issued to the Owner for Approval. The Owner returns comments and approval on the Bid Tabulation results. Any revisions that were made in the quote / approval process are incorporated by the engineer into the Equipment Datasheet in preparation for issuing the Purchase Order. The engineer prepares a Purchase Order with an updated Equipment Datasheet and submits it to the Owner for approval. The Owner approves the Purchase Order and the approved Purchase Order is submitted to the buyer.


Software and Information Flows

EquipmentDesign

EquipmentDesign

EquipmentDesign

EquipmentDesign

CostEstimating

CostEstimating

CostEstimating

Intelligent 2DDrawingSoftware



Intelligent3D CADSystem



ProcessSimulator

ProcessSimulation

ProcessSimulator

ProcessSimulation

ProcessSimulatorProcess

Simulator

ProcessSimulationProcess

SimulationEquipment

DesignEquipment

DesignEquipment

Design

DatasheetSoftware

EquipmentDatasheet

DatasheetSoftware

DatasheetSoftware

DatasheetSoftware

EquipmentDatasheetEquipmentDatasheet

PurchaseOrder withDatasheet



MaintenanceManagementMaintenanceManagementMaintenanceManagement

PlantPerformance

PlantPerformance

PlantPerformance

ERP - AssetManagementERP - AssetManagementERP - AssetManagement

Email /eMarketplace/Collaboration

RFQ withDatasheet



RFQ withDatasheetRFQ withDatasheet

Order Entry,Material Trackingand Datasheet *

Quote withDatasheet



Quote withDatasheetQuote withDatasheet

Owner DataWarehouseOwner DataWarehouseOwner DataWarehouse

ConstructionSite Asset

Management


Management


Management

Planning,Scheduling &

Tracking


Tracking


Tracking

Owner

Supplier

EPCDocument

ManagementDocument

ManagementDocument

Management

AccountsPayable/

Receivable

AccountsPayable/

Receivable

AccountsPayable/

Receivable

AccountsReceivableAccounts

ReceivableAccounts

Receivable

EquipmentStatus Update




IntelligentDrawingsIntelligentDrawingsIntelligentDrawings

Email /Collaboration /

Data Warehouse


Data Warehouse


Data Warehouse


Data Warehouse

Bid TabulationSoftware



ProcurementSystem

ProcurementSystem

ProcurementSystem




ProcurementSystem

ProcurementSystem

ProcurementSystem

As Built BOMDatasheet

& Parts List


& Parts List


& Parts List

SoftwareSystem

ElectronicDocument

Legend

Bolded lines and symbolsindicate opportunity areas

SoftwareSystemSoftwareSystem

ElectronicDocumentElectronicDocument

Legend

Bolded lines and symbolsindicate opportunity areas

EPC

EPC

Equipment ListSoftware

Equipment List &Equipment Status



Equipment List &Equipment StatusEquipment List &Equipment StatusEquipment List &Equipment Status


FIATECH AEX Project

The buyer updates the Procurement System and issues the Purchase Order to the Supplier.

Construction

The Supplier updates the Order Entry and Tracking System and initiates equipment fabrication. The Supplier regularly supplies the buyer with Equipment Status Update information as the equipment is fabricated and delivered. The Supplier notifies the buyer when the required suppliers documentation (part of Equipment Status Update) is delivered. One of the required suppliers documents is an “as-built” Equipment Datasheet, including Spare Parts Lists. The Supplier issues an Invoice to the buyer when the required equipment and documentation have been delivered. The buyer provides the scheduling engineer with Equipment Status Update information, which is entered into the Planning Scheduling and Tracking system. When the equipment and supporting documents are delivered to the construction site, the construction engineer enters delivered equipment and document information into the Construction Site Asset Management system and notifies the buyer that the equipment/document has been received. The buyer enters the Invoice into the Accounts Payable system. Payment is made to Supplier from the Accounts Payable system when the site construction engineer verifies that all equipment and documentation have been delivered and are certified to meet all requirements.

Operations and Maintenance

The Supplier provides the “as-built” Equipment Datasheet and the Spare Parts List to the buyer and the buyer provides the same to the Owner at project “handover.” The Owner engineer enters as-built Equipment Datasheet information and Spare Parts information into the Maintenance Management system. The Owner engineer enters the as-built Equipment Datasheet information into the Asset Management and/or Data Warehouse System. The Owner engineer enters the as-built Equipment Datasheet information into the Plant Performance and Reliability Tracking System. The Owner engineers and buyers continue to directly interact with equipment Suppliers for equipment and spare parts procurement activities throughout the equipment life cycle.

1.4 Candidate Software Packages Using these results, the following types of software packages and prospective software vendors (incomplete list) were identified that participate in information transactions associated with equipment data sheets and equipment lists.

Experimental data capture – in-house EXCEL, TRC-GDC

Experimental properties databases – DIPPR, TRC, API, PPDS, DECHEMA

Data regression software – Aspen Tech, in house software

Using XML Schemas for Facilities Equipment, v.2.0 - 12 - 19 July 2004

FIATECH AEX Project

Properties Simulator – Virtual Materials Group, InfoChem, Aspen Tech, in-house

Process Simulator – Aspen Tech, SimSci, Chemstations, BR&E

Equipment Design – Flowserve, Goulds, Sulzer, Engineered Software, Sundyne, Ebara, HTRI, AspenTech/Hyprotech, Coade, Codeware, IntelliEquip

Datasheet – In-house, AspenTech, Intergraph, Cadcentre

Equipment & Instrument List – In-house, AspenTech, Cadcentre, Intergraph, Bentley/Rebis

Intelligent P&ID – In-house (AutoCAD/Microstation), Bentley/Rebis, Cadcentre, Intergraph, Plant4D

Cost Estimating – In-house, AspenTech

Procurement – In-house, Marian/Intergraph, SAP

Bid Tabulation – In-house (EXCEL and Web Site)

Order Entry & Tracking – SAP

Collaboration – Citadon, e-Builder, Skire

E-marketplace – Trade-Ranger, ProcureZone, Pantellos, Big Machines

Plan, Schedule & Track – Primavera, Microsoft, Meridian

ERP – Asset Management – SAP

Maintenance Management – MRO Software, Meridium, SAP, JD Edwards

Integration – Impress

Data Warehouse – ESSI, Intergraph

The next step in this process is to define the detailed contents of the data transactions that occur in the transitions between the above software packages at various stages in the work process. To discover this, more detailed use cases need to be defined which identify the various specific data groupings and data items associated with each transaction and software package. These transaction definitions together with the detailed XML schema model for the transaction documents enable practical, useful software interfaces to be built by the respective software owners.

2. SCHEMA INTRODUCTION The effort to develop facilities equipment XML schemas is based on the use of XML schema definitions to specify and validate XML file content. XML schemas provide a rich technology for describing complex, data sets and data-rich documents. For more information about XML, see the XML Schema Development Guidelines document.

The capital facilities industry XML schemas are designed to establish a comprehensive interoperable XML framework for use in describing data required in the life cycle of capital facilities. The engineering technical information describing facilities, equipment and physical properties of materials is inherently complex, and is most naturally modeled using object-oriented data modeling techniques. Accordingly, the facilities equipment XML schemas are object-oriented engineering data schemas, consisting of many related and interdependent XML namespaces, schema files and complex type definitions, covering a variety of subject areas. In describing the data on an equipment datasheet, there are a number of reusable data subsets, which need to be modeled separately so that the subsets can be appropriately reused, under various usage scenarios in the life cycle work processes associated with facility data.

We anticipate that organizations and individuals may wish to make locally used modifications to the common industry XML schemas. Provisions are made in the schemas to add extra values to enumeration lists, and to add custom elements to support particular software requirements. These local variants may still be considered “compliant” with the common capital facilities industry XML schemas, provided the extensions are made in the recommended ways. See the pump tutorial in Section 5 to see how local extensions can be made.


FIATECH AEX Project

2.1 XML Usage Scenario – Messaging and File Exchange In supporting XML-based electronic data exchanges in software applications there are two basic types of data exchange usage scenarios – message-based and file-based. In message-based scenarios, XML messages are sent between software applications, either locally or over the Internet. In file-based scenarios one application ‘exports’ an XML file and another application ‘imports’ the file. The existing work processes in the capital facilities industry at the current time are largely file-based, either using files as email attachments or as file management as an inherent part of work process collaboration environments. The capital facilities industry will eventually need to support both message-based and file-based data exchange scenarios, but in the near term, the emphasis is likely to be on file-based usage scenarios. The cfiXML schemas focus on the domain-based information content and XML documents used in file exchange usage scenarios, and these XML documents may also be used as ‘attachments’ in messaging-based scenarios. The AEX Project is investigating the use of evolving eBusiness specifications for message-based exchanges of domain information.

2.2 Schema Scope These XML schemas have been developed with an object-oriented schema framework to support equipment item data, process material data that appear on equipment datasheets, procurement data and relevant project data. The initial subject focus of this work is:

1. Basic equipment information found on various equipment lists and bill of materials documents

2. Equipment datasheets for centrifugal pumps and shell and tube exchangers (which include process material properties)

3. Process materials, associated properties, calculation methods and experimental property data

4. Equipment documents used over the life cycle of capital facilities.

2.3 Schema Structural Overview While the scope is initially limited to these types of information, we have approached the schema design with the requirement that the base schema structures be capable of handling any equipment item, any engineering document and any material property for any information exchange usage scenario. Therefore it is possible to use our schema in its current form to describe any equipment item, and any engineering document. At this point in time, we have only provided in-depth attribution for shell and tube exchangers, centrifugal pumps and their associated datasheets as well as an extensive physical properties model for materials, including provision for experimental data, calculation models and parameters and calculated properties, property curves and property tables. Because of the initial effort to create a robust, reusable schema framework, we anticipate that extension of the object-oriented capital facilities industry XML framework to handle other equipment items will be very straightforward and cost-effective. See the “pump tutorial” in section 5 to see how this is done.

There are four basic parts to the capital facilities industry XML architecture as illustrated in Figure 1 on the following page. See Appendix A for brief description of the unified modeling language (UML) notation used in Figure 1.

1. Core data type schemas for extensions to basic data types to support engineering requirements (these are essential extensions added to the “XSD” base data types provided in the W3C XML Schema standard),

2. Core engineering object schemas for reusable base engineering objects that can be used by multiple engineering disciplines and subject domains

3. Subject engineering object schemas that provide schemas related to specific equipment items


FIATECH AEX Project

4. Collection-container schemas that are used to model engineering document schemas. The collection-container schemas allow core and subject-specific engineering objects to be combined in various ways to support various data transactions and usage scenarios.

Core Data Types

Collection-container Schemas(e.g., documents that contain engineering objects)

XML Schema

Core Engineering Object Schemas

cfiXML

Namespaces

XML Schemaxsd: XML Schema Definition

Core Data Type Schemasext: extended base data typespq: physical quantitiesetl: engineering type library

Core Engineering Object Schemasobj: base objectsctx: context - organization, location, etc.dx: documenteq: equipmentmtrl: material propertiesproj: project informationsite: site informationuo: unit operations

Subject Engineering Object SchemaseqHx: heat exchanger equipmenteqRot: rotating equipmenteq ---: other types - see namespacesthmo: thermo extensions to mtrl properties

Collection-container SchemaseqHxDoc: eng datasheets - S&T heat excheqRotDoc: eng datasheets - centrif pump

xsd:double

ext:Double

pq:WeightMass

eq:weight/value

Example

obj:Object

eq:FacilityItem

eqRotDoc:CentrifugalPumpDataSheet

eqRot:CentrifugalPump

Messaging Protocol ContainerOAGIS, UBL, RosettaNet, etc

Subject-specific Engineering Object Schemas

obj:BaseObject

eq:EquipmentItem

eqRot:RotatingEquipment

Figure 1. Capital facilities industry XML Overview

Figure 1 illustrates how these parts relate to each other, to standard XML schema definitions, and to various messaging protocol containers that are currently being developed by various industry groups.

Subsequent sections will introduce each of these major parts of the capital facilities industry XML schema architecture.

2.4 Namespaces Overview XML documents need to have unique names for XML tags (elements) that have specific meanings. In a small schema, with relatively few tags, it is relatively easy to define and maintain unique tags. In large systems, such as the capital facilities industry XML, where multiple collaborating groups working independently could potentially define thousands of element definitions, it becomes more difficult to ensure uniqueness across the various parts of the schema.

To accommodate this problem, XML schema provides for the use of “namespaces.” Namespaces provide the ability to define a collection of conceptually related data elements, where uniqueness is only required within the namespace. This allows different namespaces to use the same tag in different ways. In order to accommodate global uniqueness, XML documents can use multiple namespaces in the same document. Element tags in the document have a shorthand namespace prefix, e.g., “pq:” which is shorthand for physical quantities. In the XML document, the combination of the namespace prefix and the element tag ensures that the tag is unique within the document. For ease of maintenance for large schemas, each namespace may also include one or more separate files that combine to provide all the types and elements required in a single namespace.


FIATECH AEX Project

In order to ensure interoperable XML documents that use multiple namespaces, the namespaces themselves are required to be named uniquely. It is a common usage convention to use a common globally unique identifier string that is composed of a URL that is “owned” by the organization developing the schema.

For the capital facilities industry XML, all namespaces belong to a common “root” URI, specifically “http://www.cfixml.org”. To the end of this common root, a short identifier is put at the end separated by a forward slash. For example, the “pq” namespace would have a full unique identifier of “http://www.cfixml.org/pq.” This string then uniquely identifies the physical quantities namespace, which ensures there is no conflict with other industries and schema data definitions. By convention, we assign the shorthand prefix tag “pq:” is typically assigned in a schema declaration to mean the same thing as “http://www.cfixml.org/pq” so that the XML files are much more human readable, yet maintain uniqueness for the XML parsing program. In this document the file name, namespace prefix and full namespace qualifier will often, for convenience and simplicity, be treated as synonymous. Figure 2 illustrates the 21 capital facility industry namespaces and their relationships to each other.

The namespaces shown in Figure 2 were defined to meet the following general requirements:

To enable conceptually-related schema elements to reside in the same namespace

To enable namespaces to be easily imported and reused in other derivative schemas

To separate domains that are likely to be developed and maintained by separate organizational groups

To anticipate the need for collection-container XML documents to use only the relevant portions of a potentially very large suite of XML schema.

In Figure 2 we use UML notation (see Appendix A), where the dashed arrow lines indicate a usage dependency of a namespace upon the namespace that is pointed to. For example the “eq” namespace depends on the “mtrl” namespace to define the construction material of an equipment item. The open arrow lines indicate that complex types in a namespace extend complex types in the namespace that is pointed to. For example, the “ext” extended data types are extension types from the base “xsd” namespace, and the “eq” EquipItem complex type extends from the “obj:Obj” complex type.


FIATECH AEX Project

Core Object Schemas

Core Data Type Schemas

xsd: XML Schema

ext: Extended Datatypes

pq: Physical Quantities

obj: Base objects

etl: Engineering Type Library,geometric shapes, electrical types

Subject Schemas

ctx: Context info: Organization,Person, Location, etc.

dx: Basic documentinformation

mtrl: Basicmaterial properties

uo: Unit operation(equip performance)

eq: Equipmentitems

thmo: Extended mtrl properties

eqHx: heat exchange equipment

eqRot: rotating equipment and accessories

site: SiteInformation

eqPvf: pipes, ducts valves, fittings and internals

eqInst: instrumentation, control devices andaccessories eqVesl: pressure vessels & internals

eqElec: electrical

eqSld: solids handlingeqFire: fired equipment

eqStg: storage vessels

proj: Projectinformation

Figure 2. Capital facilities industry XML Namespaces overview

2.5 Core Data Types Overview As an underlying basis, capital facilities industry XML extends the base XML Schema standard by providing a generalized framework for handing engineering data requirements for any engineering domain. These core domain-independent schemas are divided in two main parts – the core data types and the core objects (see next section).

The core data type schemas extend the standard XML Schema data types for engineering needs, including consistent means for handling units of measurement, handling of vector data and table data, and underlying mechanisms to provide annotation and revision tracking for any element in the schema. There are three core data type namespaces:

ext: extends the XSD basic data types to include base attributes for annotation and revision tracking at the element level and to provide vector and table data types

pq: defines physical quantity base data types that associate the appropriate units of measurement numbers, including enumeration lists of valid units of measure

etl: defines some reusable complex data types, but which are not Objects (see next section), including simple shape geometries and electrical source and area classification specifications

As shown in Figure 1, these extensions use the object-oriented mechanism of inheritance, extending the base data types provided in the XSD schema. Inheritance allows the extended, or derived, data types to include all the


FIATECH AEX Project

features of the base data type, with extensions to handle additional requirements. For example, we start with xsd:double and add the first data type extension to create the data type “ext:Double” data type. The ext:Double data type includes three attributes for handling revision tracking information and associated annotation for each data element in the schema. Next we add units of measurement handling by providing another data type extension to “pq:WeightMass.” The element pq:WeightMass extends the ext:Double data type by associating mass units of measurement with ext:Double. Notice what happens when we extend finally to the engineering domain. Any element in the domain schema which has mass weight units of measure can be defined simply by extending from the pq:WeightMass data type. At this final engineering object level, when creating schemas containing engineering domain elements in context, the underlying engineering data requirements are satisfied “for free” by using the inheritance mechanism, without having to duplicate this information many times in the schema.

Similar data type extensions for all the XSD base data types including, integers, longs, floats, Boolean, date, strings, etc. In addition to base data type scalar values, extended base data types are defined for vectors (lists), and tables of XSD base data types. For units of measurement, in addition to weight mass illustrated above, definitions for over 80 types of base physical quantities, including pressure, mass, mole, length, area, volume, flow rates, energy flows, etc.

2.6 Core Objects Overview In defining the capital facilities industry XML framework, we have discovered a number of core reusable objects that can be reused and applied across multiple subject domains. These include:

obj: defines base object data types that allows engineering objects to be uniquely identified and referenced by other objects, as well as providing facilities for recording object transactions, and tracking object type and status

ctx: objects that describe context information including organization, person, location, etc.

dx: objects that describe document information, identification, literature citations, etc.

eq: objects that describe equipment items and parts

mtrl: objects that describe construction and process materials and material properties

proj: objects that contain basic descriptions of projects and planned and actual status of activities

site: objects that describe site information, facilities, facility systems, environmental data

uo: objects that describe unit operations (equipment performance) and streams

The key idea of a core object is that it can be thought of as a “container” which can be accessed by its name, like understanding the contents of a box without having to open the box. Providing this mechanism to uniquely identify objects anywhere in the engineering schema enables the schema (and resulting XML instance files) to make reference to and use these objects elsewhere in the schema or to find instance data elsewhere in the same file, or in different files on the network without having to replicate the schema or the data.

In general, engineering objects contain a large number of individual engineering data elements that are typically grouped together in logical ways. For example, in Figure 1, a FacilityItem is a type of Object that contains a number of elements that describe the facility item, such as the element weight/value. There are many types of items in a facility, but all of them can have the common characteristic of having a weight/value.

It should be briefly noted that the rationale for separating unit operation data from equipment data. Unit operations generally describe process functional performance requirements, while equipment data generally describe physical items of equipment. Also, in practice, a unit operation may have multiple associated items of equipment, e.g., a distillation column, and an equipment item may be modeled using multiple unit operations, e.g., a three-phase separator. Finally, the domain users of unit operations are different from the domain users of physical equipment information. This model separation also enables more convenient support of multiple business work process use cases – some focused on process simulation, and others focused on equipment design and specification. Of course


FIATECH AEX Project

of defining engineering documents for equipment such as data sheets, there are embedded associations in the XML schema between unit operation and stream data with a particular item of equipment.

2.7 Subject Schemas Overview The subject-specific schemas build on and extend from the core object schemas in a particular subject domain. For example, centrifugal pumps and shell and tube heat exchangers are types of Equipment Items. Shell and tube exchangers are part of the eqHx namespace while centrifugal pumps are part of the eqRot namespace. This reflects the fact that two different domain disciplines work with these different types of equipment. In the ‘thmo’ namespace, used by thermodynamic specialist and process engineers, the basic material properties core schemas are extended to describe the experimental or calculation methods, and to produce both simple and complex property tables associated with various experiments and calculations.

The currently identified subject schema namespaces are:

eqElec: electrical equipment types

eqFire: fired equipment types

eqHx: heat exchanger equipment types

eqRot: rotating equipment types

eqSld: solids handling equipment types

eqStg: storage vessel equipment types

eqVesl: vessel equipment types

eqPvf: piping, valves and fittings equipment types

eqInst: instrumentation and control system equipment types

thmo: thermodynamic parameters and extended material properties data

In Figure 1, it should be noted that eqRot:CentrifugalPump objects inherit characteristics from an EquipmentItem object, which in turns inherits characteristics from FacilityItem and from there the base characteristics of obj:Object the base for all engineering objects in the capital facilities industry XML schemas. The FacilityItem object contains the weight/value element discussed earlier. The EquipmentItem object describes characteristics associated with all equipment items, such as the equipment tag. The CentrifugalPump object contains a number of additional elements that are specific to centrifugal pumps. The idea of an inheritance/extension/generalization hierarchy is depicted in Figure 3.


FIATECH AEX Project

Figure 3. Inheritance/Extension mechanism illustrated conceptually for a centrifugal pump

Object (obj) FacilityItem

(eq)

RotatingEquipment (eqRot)

EquipmentItem (eq)

CentrifugalPump (eqRot)

2.8 Equipment Types Classification In terms of defining namespaces for the subject-specific schemas, we have chosen to group similar equipment items together – heat exchangers, rotating equipment, instrumentation etc. This enables a number of conceptually related equipment items that are likely to share data element structures to be grouped together in a namespace. In usage, this means an XML document describing a pump does not have to be burdened with bringing in all the schemas associated with heat exchangers or instruments. A starter list of 327 equipment types, grouped by 10 equipment namespaces, is included in Appendix F. A summary of this equipment classification is shown below in Figure 4.

Equipment Items

HeatExchangers

RotatingEquipment &Accessories

Pressure Vessels& Internals

Pipes, Ducts,Valves, Fittings &

Internals

Instrumentation,Control Devices& Accessories

Electrical

FiredEquipment

StorageVessels

SolidsHandling

6 types 23 types

5 types

26 types

54 types

131 types

21 types 40 types 21 types

327 types total

Figure 4. Equipment Types Classification


FIATECH AEX Project

Using the 327 equipment types which are identified by name only in the 9 equipment namespaces above it is possible to construct summary equipment lists or generic data sheets that contains basic information about the equipment item, e.g., tag, manufacturer, model number, cost, weight, etc. In addition to the summary information on any of the above equipment types, the following equipment types were developed in detail:

• Electrical o Motor (partial model for centrifugal pump driver support)

• Heat Exchangers o Shell and Tube Exchangers

• Rotating Equipment and Accessories o Centrifugal Pumps o Rotating equipment common parts, e.g., bearing assemblies, shafts, seals, etc.

2.9 Container-Collector Overview To the engineering object schema, we have added some basic data models to handle information associated with engineering, project and commercial documents.

Documents are modeled essentially as collector-container “views” of the underlying engineering and project object data. Therefore they can be constructed more or less arbitrarily as needed to suit the purpose of any given data transaction and usage scenario.

In the initial set of the capital facilities engineering XML schemas, we have provided some standard engineering and project documents, such as a centrifugal pump datasheet, a shell and tube exchanger datasheet, and a material property data table document to serve as a document for a set of experimentally measured or calculated properties. We have also included a simple “order” document that can be used for inquiries, bids, and purchase orders.

Many document types can be assembled using the same base underlying data including process simulation inputs and results, equipment design program inputs and results, and, in the future, supporting graphical documents such as PFD’s, P&ID’s, isometrics, etc.

In Figure 1, we have shown an example document, CentrifugalPumpDataSheet, for a centrifugal pump datasheet, which contains the CentrifugalPump engineering object, which derives its associated property from the inheritance hierarchy back to obj:Object.

2.10 Messaging and Business Protocol Containers The capital facilities industry XML Engineering Documents do not directly include the messaging and business process protocol schemas, which are being developed in other industry XML efforts such as OAGIS, UBL, RosettaNet, etc.

Rather, capital facilities industry XML engineering documents are intended to be the “payload” documents contained within, or attached to any appropriate e-business messaging and business process architecture that is used by the industry.

The ctx namespace contains information that will be similar to or the same as the messaging and business protocols, including complex types for organization, person, location, and project information.

When developing schemas, we should recognize that one of two requirements may be needed for implementers: (1) the need for implementers of messaging applications to consistently populate information between the ctx namespace and the external messaging or business protocol namespaces, or (2) the need for implementers to replace ctx objects with references to equivalent elements in other horizontal industry namespaces.

2.11 Naming and Sequence/Choice Ordering Conventions For assigning element and attribute names, we have used the naming conventions described in the XML Schema Development Guidelines document. The following naming rules and conventions have been applied:

Elements and attributes start with lower case letters Complex and simple types start with upper case letters


FIATECH AEX Project

Compound terms are separated using Camel Case convention, i.e., using capital letters to identify the separate terms in a compound term, e.g., centrifugalPumpDataSheet.

The order of terms in a compound term follows an adaptation of the ISO 11179 standard, specifically, class – type qualifier – location qualifier – modifier – physical quantity (see XML Schema Development Guidelines for more detail). For example, outsideDiameter where the physical quantity is listed last is preferred over diameterOutside.

While fully spelled terms are preferred, commonly used acronyms and abbreviations are permitted in a few cases, provided they are broadly recognized within the subject domain, e.g., API, info, max, min, MAWP, NPSH, provided there is no potential for the abbreviation to be misinterpreted, and that abbreviations are always used the same way. Out of more than 1300 terms used in the cfiXML schemas only about 70 are abbreviations. These are maintained in an abbreviation table to ensure consistency of abbreviation usage. See Appendix E for the current cfiXML Abbreviation table.

The cfiXML schemas make extensive use of element ‘sequences’ or ‘choice’ lists. Some of these lists can become quite lengthy. The element/group order is important to consider from a usability and maintenance point of view. For long lists of items, alphabetical order is always the most usable order for locating terms. From the schema maintenance viewpoint, alphabetical order can be maintained from one schema version to the next, because virtually all elements are optional and so additional elements can be inserted at the appropriate location without invalidating existing XML files. For usability sake there is some argument about using ‘natural or logical order’ versus alphabetical order that have validity in some cases, for example the order of elements in a mailing address. Accordingly, we have chosen to apply the following rules to the sequences and choice lists in the cfiXML schemas.

1. Use alphabetical ordering as the default way to order elements in a sequence or choice list. 2. If there is a defensible, logical natural order to an element grouping, such as the elements that comprise a

mailing address, then use the logical natural order in preference to alphabetical order. 3. When placing elements in alphabetical order, ignore any namespace prefixes that occur in element or

group references.

2.12 Object Management As discussed under the Core Objects section above, the capital facilities industry XML provides the ability to identify engineering objects and documents as a unique object and refer to it by its unique identifier.

Therefore, at any place where an object could be contained within XML in an instance file, that object can be replaced by a reference to where the data can be found. Three ways of implementing object references are possible: (1) in the same file (local reference) (2) direct reference by URI and Xpointer (3) indirect reference through an object registry. In the case of registries, the obj namespace does not explicitly define the structure of such registries; these are left up to individual implementations. An example of a simple object registry is found in the idx.xsd file.

We expect that, as various organizations internally implement XML data files, that it will be convenient to create a whole collection of XML files that will be used together with either external direct referencing or indirect referencing by means of an object registry. On the other hand, files intended for external data transactions, e.g., with business partners, are likely to be totally self-contained, i.e., will only make use of the local referencing mechanism.

In order to assist in managing a complex set of objects in a given software environment, such objects are identified by a URI, to which they are considered to “belong”. That owner URI may contain a registry which identifies the location of objects or it may simply be a unique identification for the source of that object. The ownerURI is one of the attributes of an Object.

Each Object has an objectID attribute, in the format as follows:

namespacePrefix.type.idOrName.versionNumber.branch

(where versionNumber and branch are optional)

For example, “eq.EquipmentItem.E101.1” is version 1 of E101, which is of complex type EquipmentItem, defined in eq. The complex type is used, not the element name, since the same complex type can be used by elements with different names, defined in a specific subject or container schema. This comprises a unique id because the combination of namespace and complexTypeName are unique within a namespace. The E101 is a user- Using XML Schemas for Facilities Equipment, v.2.0 - 22 - 19 July, 2004

FIATECH AEX Project

defined unique name, which can be enforced by application software. The version and branch numbers are optional and application-provided for applications that maintain versions. It is intended that application software will automatically populate the namespace, the complexTypeName, the version number and the branch number.

The objectID should be unique to a single instance of the XML data (that is the data to which references can be made), within the set of all objects belonging to a given URI. If no ownerUri is given, the ID should be unique within a given file or folder. The objectID does not derive from xsd:ID and may occur several times in a single XML file, since several references can be made to a single object. (For more details on the justification for this design approach, see the XML Schema Development Guidelines document.)

For external data transactions, the organizationID attribute offers a universally unique identifier for the organization who owns the data object. This string should include the full unique identifier, e.g., for a company, this would include 1.2.840.1.xxxxx, where xxxx is the ANSI issued unique company identifier. See ANSI Procedures for registering organization names in the United States of America under the Joint-ISO-CCIT arc at http://web.ansi.org/public/services/reg_org.html

In order to assist in organizing cfiXML data and objects, we recommend that an XML file be created, listing all XML files that are interrelated. We propose a file naming convention to call this file indexcfi.xml. The creation of such a file in a folder of related XML files will provide a consistent resource to assist third parties in navigating the data. The idx schema gives a structure for this file.

2.13 Schema Extensibility Extensibility is very important in the schema design. The XML files validated against a schema must be able to include elements that were not included in the original design. It must also be possible for users to extend the schemas on local systems. The capital facilities industry XML framework supplies schema that can be used as is, or can be readily extended as needed by two parties who need to exchange data that are not contained in the current schemas without having to edit the base standard schema files.

We recommend, by convention, that user schema extensions be contained in a separate user extension namespace. The namespace name is recommended to be “http://www.cfixml.org/custom/xxx-com/yyy” where “xxx-com” is an organization’s domain name (substituting hypen ‘-‘ for ‘.’) and “yyy” is defined by the user organization however they choose. For multiple user namespaces, simply use different “yyy” designations as needed.

Further, we recommend, by convention, that the user-defined schemas be placed in the folder structure provided by cfiXML under the “custom” subfolder of the root cfiXML folder that uses the same naming convention.

The basic schema extension mechanisms are as follows:

1. Each “sequence” or “choice” element list in the schema provides the ability for the user to insert additional custom elements and/or arbitrarily complex element structures by adding these schema elements to a separate user-editable file. This allows users to insert additional data elements without affecting the base schema.

2. The enumeration choice list for each enumeration data type element in the schema can be extended by users adding these elements in a separate user-editable file, without affecting the base schema.

3. The core data types all include an “any” attribute that can be used to add attributes to any element in the schema at the “leaf” level, which are derived by extension from base data types

4. New engineering or other data transaction documents to support specific data transaction can be created by simply defining new and separate document schema files. These document schemas are essentially the custom collections of engineering objects that are needed to support a particular transaction.

The extension mechanisms described above are illustrated in the section 5 of this document.

2.14 Schema Object Library The diagram on Figure 5 (following page) summarizes the current key core and subject objects that reside in the current schema object library. To obtain more details about these objects, please review the accompanying Core


FIATECH AEX Project

Schemas and Subject Schemas documents and refer to the appropriate XML schema files directly. The XML schema files are briefly described in the following section. We recommend that XML schema editing software such as XML Spy, TurboXML, or VisualStudio is the most effective means to review the XML schemas.

2.15 Namespace and File Folder Organization The cfiXML schemas are delivered in a file folder structure that uses the following basic principles:

All cfiXML namespace names will derive from the string “http://www.cfixml.org” plus a unique path All public cfiXML documentation files are held in a separate subfolder called “documentation” All public cfiXML example instance files are held in a separate subfolder called “examples” All public cfiXML ‘base’ schema definition files are held in a separate subfolder called “schema” All public cfiXML ‘exchange document schemas’ are held in a subfolder called “schema/document” Implementer custom schemas are to be held in a separate subfolder called “schema/custom” Implementers will use their own organization domain name as the root of the path extension to

“http://www.cfixml.org/schema/custom” but substituting a dash for the period, e.g., “eplantdata-com” and then they have full discretion to create further subfolders under their own custom folder as necessary

The location of each schema file relative to a base directory corresponds to the namespace name The namespace names will include a “path” element relative to the root: http://www.cfixml.org, For

example, the base schema ‘eq’ namespace is declared as “http://www.cfixml.org/eq.” The centrifugal pump data sheet exchange document schema is declared as “http://www.cfixml.org/document/eqDoc” The custom namespace for the ‘eq’ customization namespace provided by cfiXML.org is “http://www.cfixml.org/custom/cifxml-org/eq”

Unique Object ID’s, including custom objects, are formed by using the convention as described in section 2.9, whether they are base cfiXML objects or implementer-supplied custom objects.

Applying these principles results in the following structure for the schema folders: [documentation] [examples] [schema]

ctx.xsd eq.xsd (etc. other cfiXML base schema files) [custom]

[bechtel-com] [cfixml-org] [eplantdata-com] [htri-net] [nist-gov] [xynchron-com]

abc.xsd - implementer specific schema [xrom1]

pqr.xsd - site specific schema (etc. - other organization-specific extension schema folders)

[document] eqRotDoc.xsd (etc. other document schemas)

See the Contents document for more details about the contents of the full set of release files.


FIATECH AEX Project

Figure 5. Capital facilities industry XML Object Library

Legend

Note: ns = namespace identifier

obj: BaseObject

ctx: Organization

site: SiteSubArea

ctx: Location

ctx: Person

site: SiteFacility

proj: Project

eq: UtilityService

site: FacilitySystem

site: EquipmentSet

eq: MaterialUtilityService

site: EnvironmentalData

ctx: GeographicAreadx: HTMLDocument

dx: Citation

dx: TextDocument

eq: EquipmentItem

eqRot: RotatingEquipment

eqRot: CentrifugalPump

eq: BearingAssembly

eqHx: HeatExchanger

eqHx: ShellTubeHeatExchangerUnit

etl: Shape

etl: RectangularShape

etl: CylindricalShape

mtrl: Material

mtrl: MaterialProperty

thmo: PropertyDataTable

mtrl: Reaction

mtrl: MaterialComponent

mtrl: MaterialComponentList

uo: Stream

uo: MaterialStream

uo: EnergyStream

uo: UtilityStream

mtrl: Property

uo: ProcessDefinition

uo: UnitOperation

uo: PressureChangeUnitOperation

uo: FluidTransferUnitOperation

uo: PumpUnitOperation

uo: HeatExchangerUnitOperation

uo: ShellTubeHeatExchangerUnitOperation

ns: CoreSchemaObjName

ns: SubjectSchemaObjName eq: ElectricalUtilityService

etl: ElectricalAreaClassification

etl: ElectricalSupplyCharacteristic

eqRot: MechanicalSeal

eqRot: Packing

eqElec: Motor

eqRot: Baseplate

eqRot: Gear

eq: Shaft

eqRot: Casing

eqRot: Impeller

eqRot: Coupling

etl: Coordinate

thmo: Method

thmo: MethodParameterSet

mtrl: MaterialComposition

thmo: MtrlSample

thmo: MixtureSample

thmo: PureSample

dx: DatasheetA

dx: ProjectDocument

dx: OrganizationDocument

obj: TextObject

dxDsCpmp:CentrifugalPumpDataSheet

dxDsSt: ShellTubeExchangerDataSheet

ctx: LocationAndGeographicArea

ctx: SubOrganization

obj:Object

proj: Activity

eq: FacilityItem

eq: BulkItem

eq: FabricatedItem

eq: FabricatedNozzle

eq: PipingComponent

eq: Flange

eq: PipeSpec

eq: PipingConnection

eq: EquipmentConnection

eqHx: ExchangerNozzle

thmo: ExtendedCitation

Using XML Schemas for Facilities Equipment, v.2.0 - 25 - 19 July 2004

FIATECH AEX Project

3. SCHEMA OVERVIEWS In this section, we review the overall nature of the cfiXML schemas by namespace, using Unified Modeling Language (UML) notation. See Appendix A for an overview of UML notations. See the XML schema definition files for the cited namespaces to see detailed definitions and descriptions of these objects, including the contained elements and attributes and detailed annotations for the contained elements and attributes.

3.1 Extended Data Types (ext: namespace)

3.1.1 Purpose The ext namespace provides definitions of data types that are extensions of the base XML schema data types. The types defined include:

scalar (single value) types list (vector) types table types

The content of the data allowed in the elements is determined by the use of XSD types, and may be further constrained by the application of pattern templates.

An illustration of how ext is defined relative to the XSD base data types is shown below

xsd:double

ext:Double

All types defined in ext may have one or more attribute groups defined. There are three base attribute groups defined – BaseAttributeGroup, ListAttributeGroup and TableAttributeGroup. The List and Table attribute groups support metadata for vectors and tables of numbers. The Base AttributeGroup, used for all data types in the ‘ext’ namespace, enables annotated version and revision tracking at the data element level, a requirement of the engineering problem domain.

BaseAttributeGroup Attributes

Name Type Description comment xsd:string Comments or annotation on an individual data item. These

comments are version independent and may have additional comments appended.

commentReference ext:ID A reference to a text object that contains a comment. This enables a comment to be reused among many data elements.

changed xsd:boolean Changed flag indicating that this data item has changed since the previous version indicated by the version number in the objectID.

3.1.2 Usage To declare an element using a type defined in ext, the type attribute of an element is set to the name of the type, taken from the full list in the next section. This name must be preceded by the ext: namespace qualifier (which must be defined in the header of the schema file). For example:


FIATECH AEX Project

xsd:integer

ext:Integer

eqHx:numberTubePass

<xsd:element name="numberTubePass" type="ext:Integer" minOccurs="0" />

This defines an element of type I (integer) from ext. This element will then have the attributes from BaseAttributeGroup available. The XML instance of this element can be, for example:

<numberTubePass changed=”true” comment=”to be checked by tomorrow”>2</numberTubePass>

A full set of data types that are included in the XML schemas is listed in Appendix B.

3.2 Physical Quantities (pq: namespace)

3.2.1 Purpose The pq namespace provides physical quantity data types used in data elements. The types defined include:

scalar (single value) types list (vector) types table types

All pq types are derived from ext:Double – double precision real number – since they are intended to represent measured or designed quantities such as length, weight, etc. Each type has a defined attribute, symbol, which is used to set the units in which the quantity is measured. The permitted values for this symbol for each type is defined in an enumeration. The inheritance hierarchy is shown below.

xsd:double

ext:Double

pq:WeightMass

eq:weight/value

3.2.2 Usage To declare an element using a type defined in pq, the type attribute of an element is set to the name of the type, taken from the full list in the next section. This name must be preceded by the pq: namespace qualifier (which must be defined in the header of the schema file). For example:

<xsd:element name="value" type="pq:WeightMass" minOccurs="0"/>


FIATECH AEX Project

This defines an element of type WeightMass from pq. This element will then have the attribute symbol available. All pq data types have the attributes from ext:BaseAttributeGroup available. The XML instance of this element can be, for example:

<weight> <type>dry</type> <value changed=”true” symbol=”lb”>20.5</value>

</weight>

If no units are specified for an individual element, i.e. no symbol attribute is present, the unit set is to be taken from the containing object, which has an attribute unitSet. This can be set to “SI”, “USEngineering” or other choices of unit sets. For each unit set, there is a corresponding complexType which specified the unit to use for each variable type, e.g. for SI the unit to use for acceleration is m/s2.

If the containing object has no unitSet specified and no symbol is specified for the object, the default units are to be taken as SI. Therefore every object which wishes to use units other than SI must specify a unitSet, even if the containing or parent object has a unitSet defined.

If a unitSet does not define a default unit for a physical quantity, then the units are to be taken as the same as the SI units (or the unit in the original set from which the unitSet is derived). For example, US Engineering units and SI both use Volts for electrical potential so there is no need to redefine Volts as the default for all other unitSets.

See Appendix C for a full list of physical quantities.

3.3 Engineering Type Library (etl: namespace)

3.3.1 Purpose The etl collects together in one place miscellaneous data type definitions which are re-used at several points in the schemas, but which do not derive from obj:Object, hence there is no dependency upon the ‘obj’ namespace. At present these reusable elements include:

3.3.2 Summary of types

Shape

RectangularShapeCylindricalShape

ElectricalAreaClassification GeographicAngle

ElectricalSupplyCharacteristic NormalFlowDirection

Coordinate

The geometric shapes derive from the basic Shape element, adding more parameters to the shape. The names are generally self-explanatory. None of the other types defined are interrelated.

ElectricalSupplyCharacteristic defines the parameters of an electrical power supply required, e.g. 1-phase 240V, 50Hz or 3-phase 440V.

ElectricalAreaClassification classifies areas by safety requirements, e.g., Class I, Division 2, Group C-D.

Geographic Angle describes the means to describe latitude and longitude.

Coordinate is a Cartesian coordinate.

NormalFlowDirection is a reusable enumeration indicating direction of flow.


FIATECH AEX Project

3.4 Objects (obj: namespace)

3.4.1 Purpose The obj namespace defines the base types from which all other schema objects derive. These base types are defined to have the fundamental attributes and base element data required to identify, name, and manage objects that can be defined and referenced by other elements and objects in the schema.

The objects in obj are generally not intended to be used directly in instance files. Rather, they are to be used as the base ‘type’ for defining other objects. Occasionally, container schemas (such as idx) may refer to Objects. This allows any object derived from obj to be included in an XML instance file (so-called “variable content containers”), but these instances would normally be higher-level derived objects, not Object by itself.

3.4.2 Summary and comments

BaseObject

Transaction

Object

TextObject

copiedObject

ctx: Person

BaseObject is the lowest level object defined. It has the attributes required to identify objects and some basic descriptive elements, name and description, but omits the capability of recording version tracking and transaction records as Objects do. The full engineering object, Object, which permits transaction recording and version tracking, derives from BaseObject, as do the ctx objects. ctx objects are context data and do not require detailed transaction recording. If they were based on Object, there is a chance of circular references resulting, since transactions refer to the person responsible for a transaction.

BaseObject also defines object name and desc elements that should by default be used for the name and description of the object. There should not normally be any need to define specific name and description fields for engineering objects.

An Object can include one or more transactions, each of which has several elements defining the transaction, including date/time, person, parent object, etc.

3.5 Context and Projects (ctx: and proj: namespaces)

3.5.1 Purpose The ctx namespace defines the objects needed throughout the data to provide a context for data – project, person and organization. These are all derived from BaseObject, not Object, and are used to define some of the lowest level properties of objects.

Many other XML initiatives have also developed definitions of the objects in ctx. In the longer term it is reasonably likely that the context data type definitions may be replaced by schema types common to other broader industry initiatives. In any case, for the present, it will be the implementer’s responsibility to use the context data types in the “attachment” consistently with similar data elements that appear in the messaging “envelope” schemas that are being used in a particular organization.


FIATECH AEX Project


obj: BaseObject

ctx:Person

ctx:Organization

ctx:Locationproj:Project

ctx:GeographicArea

ctx:LocationAndGeographicArea

contact

facilityLocation

0..n

proj:Activity0..n

obj: Object

Person, Organization and Location are straightforward definitions of the data for these objects. All have been made into objects derived from BaseObject so that many references can be made to one instance of the data. Updating a person or organization’s details will be available to all objects referring to those details. A location is less likely to “change” with time or be referred to in multiple data objects. However we believe it should still be made a referencable object so that corrections or amendments could be made more easily.

Location can include street address, latitude/longitude or other methods of defining a position. LocationAndGeographicArea defines a rectangular area relative to a location; the offset and rotation of that area can be specified, allowing a facility area to be defined relative to the origin of the facility. This is not an independent referencable object – multiple uses of the same area are unlikely to occur and re-use of the data could potentially lead to errors. A common reference location can be used by several LocationAndGeograArea instances.

A project is defined as existing in the context of a single organization. This is the scope of a program of work from that organization’s perspective. A Project can contain associated projects, thereby allowing the collection of individual projects to be recognized as a single related project. The roles of different organizations and their individual project numbers used can therefore be associated with each other under a single “umbrella” project. Like some other objects, project has relatively few attributes, but the name and description of the project should be entered in the BaseObject name and description elements.

3.6 Documents (dx: namespace)

3.6.1 Purpose The dx namespace defines the properties common to all engineering documents associated with projects and organizations. When creating specific documents for a given usage scenarios or particular corporate environment, the documents can extend a document object from dx with objects from other core or subject namespaces.


FIATECH AEX Project


obj: Object

TextDocument

ProjectDocument

obj:TextObject copyrightOwner

ctx:ProjectOrganizationDocument ctx:Organization

HTMLDocument

CitationLibrary

Citation

ProjectDocumentLibraryOrganizationDocumentLibrary

DataSheetA DataSheetHeader

eq: EquipmentItem

eqDoc: EquipmentItemDataSheet

eqDoc:DataSheetLibrary

obj: BaseObj

site: Site

ctx:Person

ctx:Organization

TextDocument represents any kind of stand-alone text document. It is identified by the originator (copyrightOwnerOrganization or Person) and the identification used by the owner: title or other ID reference. One or more text objects can be included within it. These text objects are unformatted strings. To allow more formatting, HTMLDoc extends TextDocument with one or more pages in XHTML format.

TextDoc/HTMLDoc can therefore represent documents which have been created without reference to any other capital facilities industry XML object but which need to be captured and catalogued within a capital facilities industry XML-based application.

To associate a document or set of documents with a project, the ProjectDocument and ProjectDocumentLibrary objects are used. These are referenceable objects, which refer to a project. The former associates one document with a project under one ID; the latter associates multiple documents with a project, with one or more documents grouped under an ID. This is directly analogous to filing a set of parts or operations manuals in a project office under project-specific IDs.

A similar mechanism is used to create OrganizationDocumnet and OrganizationDocumentLibrary – documents associated with an organization. Note that creating a Project/Organization Document or Library does not require any changes to be made to the source document. The same set of documents can be “filed” in different ways in different projects, while still referring to a single common document. The same document could also be referred to directly in the context of a specific equipment item.

In the context of a project, datasheets and datasheet libraries are a principal mechanism for defining the scope of the project. Such a “view” on the data can present a subset of the whole facility or site.

Datasheets are different in that they refer to a specific item of equipment, and the other information on the data sheet only makes sense in the context of the project and that item of equipment. They are essentially a view of some underlying data with a small amount of project-related metadata about that equipment. DataSheetA is an abstract object that must be extended with an equipment item, system element or other data before it can be used. Once extended in this manner, a DataSheet is analogous to a ProjectDocument, with the combination of DataSheetHeader plus EquipmentItem (as an example) taking the place of the TextDocument. Note that datasheets can be associated with a particular organization or project via the appropriate entries in the Datasheet Header.

A datasheet library can be created by associating a project with a collection of DataSheetHeader/EquipItem combinations. The schema file eqDoc,xsd gives an example of such a library. In eqDoc the datasheet element


FIATECH AEX Project

(which brings together header and equipmentItem) is not an independent object, but this could easily be created if business processes require it.

The core dx schema also provides for bibliographic citation information so that external documents can be referenced at various places in the rest of the schema.

3.7 Equipment (eq: namespace) 3.7.1 Purpose The eq namespace defines the properties common to all facility equipment items – weight, environmental constraints, cost, etc. Three basic types of facility equipment items are identified – EquipmentItem, BulkItem and FabricatedItem. These basic types should be used for the creation of all subject-specific schemas relating to facility items, possibly via an intermediate “generalized” item. For example, a centrifugal pump is derived from a generic rotating equipment item, which in turn is derived from EquipmentItem according to the following inheritance hierarchy which is illustrated in Figures 1, 3 and 5.

obj:BaseObject |__ obj:Object |__eq:FacilityItemA |__ eq:EquipmentItem |__ eqRot:RotatingEquipment |__ eqRot:CentrifugalPump


obj: Object

FacilityItemA

BulkItem

UtilityServiceA

ElectricalUtilityServiceMaterialUtilityService

ctx: Organization

mtrl: MaterialconstructionMaterial

fabricatorCompany

EquipmentItemFabricatedItem

supplierCompany

PipingComponent

FabricatedNozzle

PipingConnection

EquipmentConnection

endDescription

flangedConnection

weldedConnection

threadedConnection

mechanicalConnection Elbow

Reducer

PipeFlange

FittingEnd

BearingAssembly Bearing Shaft

The core object in the eq namespace is the FacilityItemA, which is an abstract object that is instantiated in one of three ways: EquipmentItem, BulkItem and FabricatedItem.

Shaft, BearingAssembly and Shaft are derived from EquipmentItem and are intended to be re-used as a contained element wherever these equipment parts are required in various subject schemas.

EquipmentConnections, FabricatedItem and PipingConnections are defined in terms of the type of connection. A flangedConnection includes description of the Flange, which itself is a subtype of PipingComponent. Other PipingComponents include Elbows, Pipes, and Reducers, all of which include FittingEnd as part of their definitions.


FIATECH AEX Project

EquipmentItems and BulkItems are intended to be specific instances of an item, with its own serial number and tag. The same object could be used as a “template” defining a standard catalog model or other item type that could be used at several locations in a facility.

FacilityItems are constructed of a constructionMaterial, which is a Material defined in the mtrl namespace. The FacilityItem also provides for a supplierCompany or a fabricatorCompany, which is an Organization defined in the ctx namespace.

EquipmentItems and BulkItems may use a MaterialUtilityService or an ElectricalUtilityService which are subtypes of UtilityServiceA, an abstract object type. If so desired, the utility services may be associated with a FacilitySystem in the site namespace definition (see site namespace section).

3.8 Materials and Properties (mtrl: namespace) 3.8.1 Purpose The mtrl namespace defines materials, to be used for process streams, stream properties on equipment data sheets or for materials of construction. Materials can be made of multiple material components (each normally a single chemical species) and mtrl defines the relationship between a material and its components.

Each material can also have one or more physical properties associated with it. More complex thermodynamic data such are experimental or calculated property tables and curves are defined in the thmo namespace.

mtrl also defines reactions and their parameters, for use in defining reaction-based properties.


obj:Object

property

MaterialProperty

MaterialComponentLibrary

MaterialComponent

MaterialComponentList

phaseReference

Material

Reaction

fixedProperty standardCondition

context

standardState

MaterialComposition

MaterialLibrary

referenceCondition

Phase

obj:BaseObject

0 .. n

0 .. n

0 .. n

> 280 properties

0 .. n

The Material object is a referencable material (either a pure material or a mixture) that can occur at multiple places in a facility or piece of equipment. For mixtures, a MaterialComponentList is used, which defines a series of material components, together with the order of components, for any component vector properties. The MaterialComposition is the only vector property used in this base schema and is used for describing the mixture in terms of relative amounts of each component, e.g., mass fraction. The MaterialComposition offers a choice of possible ways to define the relative amounts – by volume, by mass, by mole, etc.

A MaterialComponentLibrary contains one or more material component. A material component can include various identifying information such as its chemical formula or a variety of other standard ways of identifying a chemical species. If a material is a pure chemical, a single component should still be set up, with a composition of 100%.

To define a property associated with a material, e.g. its density under the conditions in a piece of equipment, MaterialProperty is used. A MaterialProperty contains a Material object, phase definitions, reaction definitions and may contain multiple properties associated with the Material. Properties are characterized by definition information,


FIATECH AEX Project

including a reference to the specific phase or reaction, reference conditions, standard conditions, one or more specific fixed values (e.g. standard density), etc. The property types and values are contained under property data (specific properties listed in Appendix D). Property data can be expressed as scalar numbers, vectors, or tables.

3.9 Unit Operations (uo: namespace)

3.9.1 Purpose The uo namespace defines the properties common to all unit operations and facility equipment process performance.


obj: Object

ProcessDefinitionUnitOperation Stream

MaterialStream

MaterialUtilityStream

EnergyStream

ProcessPort

EnergyUtilityStream

HeatExchanger

PumpUnitOperation HeatExchangerSide

FluidTransferUnitOperation

PressureChangeUnitOperation

ShellTubeExchangerUnitOperation

A unit operation is a referenceable object that is typically characterized by a particular type of engineering calculation such as those found in process facility modeling software. The unit operation carries out a further description of the process definition in terms of key engineering data that specify process performance characteristics.

A process definition is a referenceable object that describes a general process function (may or may not correspond to a process model).

Unit operations and Process definitions are often characterized by material or energy flowing between them through one or more associated ProcessPorts. Each process port contains a stream, either material or energy, each of which can be either a process stream or a utility stream.

3.10 Site (site: namespace)

3.10.1 Purpose The site namespace defines the context information relevant to an overall facility. It is used for organizing the relationships among facility data at a relatively high level schema and uses elements from the core schemas.


FIATECH AEX Project

3.10.2 Summary and comments obj: Object

SiteFacility

EnvironmentalDatactx: OrganizationownerOrganization

etl: ElectricalAreaClassification

SiteSubArea

ctx: LocationAndGeographicArea

FacilitySystem

EquipmentSet EquipmentConfiguration

eq: electricalUtilityServiceProvided

eq: materialUtilityServiceProvided

A SiteFacility is the highest level object available to define a geographic location that contains one or more FacilitySystems. The site may be also characterized by SiteSubAreas, which define the physical boundaries of parts of the site and the facilities on the site. Each of these can have a specific location and rectangular area defined. Sites and site SubAreas may have environmental data, have electrical area classifications, and be characterized by geographic locations within the site.

A SiteFacility may contain one or more FacilitySystem objects. FacilitySystems can be defined at any level of detail, but it is often used as the next highest aggregation on a site. FacilitySystems may have utility services associated with them; and they may provide those services as well. There are no limit to the number and type of FacilitySystems that can be described, and in general they will not be mutually exclusive. Optionally, each FacilitySystem can be broken down further into one or more EquipmentSets.

The structure of an EquipmentSet is made of one or more EquipmentConfigurations. Each EquipmentConfiguration can be made up of equipment items operating in standalone, in parallel or in series. If in parallel, the proportion of the service carried out by each item can be specified. The structure of EquipmentConfiguration is sufficiently general that it should be able to represent any combination of parallel, series and standalone arrangements – for example, two items in series operating in parallel with a combination of one item in series with two items in parallel. While such combinations are unlikely in practice, the design has ensured that the structure of SiteFacility imposes no constraints on the possible interrelationships of equipment components.

3.11 Rotating Equipment (eqRot: and eqRotDoc: namespaces)

3.11.1 Purpose The eqRot namespace holds schema definitions for approximately 40 types of rotating equipment or machinery. The schemas for these 40 equipment items are contained in the following schema definition files:

eqRot – base namespace declaration file eqRotBase.xsd – contains base rotating equipment item schemas and equipment type names eqRotCpmp.xsd – contains details for centrifugal pumps eqRotSeal.xsd – contains details for mechanical seals and packing

The eqRotDoc namespace contains the schema definitions for defined container documents for rotating equipment. There are two engineering documents currently defined: a centrifugal pump datasheet and a centrifugal pump equipment list.

Rotating equipment are complex assemblies of a driver, fluid mover, connecting shaft and various equipment parts including bearings, seals, baseplates, lube oil systems. In approaching the information model for centrifugal pumps,


FIATECH AEX Project

the model was largely set up as a generalized model for any item of rotating equipment, with some specializations that are appropriate only for centrifugal pumps. In this way, the model will be readily extensible and reusable to other rotating equipment items, including centrifugal and reciprocating compressors, fans, other pump types, etc. The centrifugal pump model is presented below as representative of many rotating equipment types.


Driver

eqRotDoc: DataSheetCentrifugalPump

eqrot:RotatingEquip

eqrot:CentrifugalPump

eq:EquipmentItem

dx:DataSheetA

obj:Object

eqRot: Baseplate

eq: BearingAssembly

eqRot: Gear

eq: Shaft

eqRot: Coupling

eqRot: Casing

eqRot: Impeller

eqRot:MechanicalSeal

eqRot: Packing

eq: EquipmentConnection

eqElec: Motor

eqRot: Turbine

eqRot: Engine

uo: PumpUnitOperation

uo: FluidTransferUnitOperation

uo: PressureChangeUnit Operation

uo: MaterialStream

uo: Stream

site:SiteFacility

uo: UnitOperation

uo:ProcessPort

eq:FacilityItemA

obj:BaseObject

As discussed already in the eq namespace discussion, a centrifugal pump is derived from a generic rotating equipment item, which in turn is derived from EquipmentItem according to the following inheritance hierarchy which is illustrated above and in Figures 1, 3 and 5.

obj:BaseObject |__ obj:Object |__eq:FacilityItemA |__ eq:EquipmentItem |__ eqRot:RotatingEquipment |__ eqRot:CentrifugalPump

A rotating equipment item contains the following major equipment item components:

Baseplate


FIATECH AEX Project

Bearing Assembly Casing Coupling Driver – may be electric motor, turbine or engine Gear Impeller Mechanical Seal Packing Shaft

The process performance information and stream information are described

obj:BaseObject |__ obj:Object |__uo:UnitOperation |__ uo:PressureChangeUnitOperation |__ uo:FluidTransferUnitOperation |__ uo:PumpUnitOperation

The pump unit operation has process ports and material stream property data for the pumped process fluid.

The centrifugalPumpDataSheet is the container document for centrifugalPump. The datasheet also contains Datasheet identifying information as well as SiteFacility and MaterialStream information.

3.12 Heat Exchange Equipment (eqHx: and eqHxDoc: namespaces)

3.12.1 Purpose The eqHx namespace holds schema definitions for approximately 20 types of heat exchange equipment. The schemas for these 20 equipment items are contained in the following schema definition files:

eqHx.xsd – base namespace declaration file eqHxBase.xsd – contains base heat exchange equipment item schemas and equipment type names eqHxSt.xsd – contains details for shell and tube heat exchangers

The eqHxDoc namespace contains the schema definitions for defined container documents for heat exchange equipment. There are two engineering documents currently defined: a shell and tube exchanger data sheet and a shell and tube exchanger equipment list.

Shell and tube heat exchangers, as described on equipment datasheets are, in fact complex assemblies of equipment parts, fluid properties and unit operations data as illustrated below.

Heat exchange equipment are complex assemblies of various parts. In approaching the information model for heat exchangers, the model was set up as a generalized model for any item of heat exchange equipment, e.g., heat exchanger and tube, with detailed specializations that are appropriate only for shell and tube exchangers. In this way, the model will be readily extensible and reusable to other heat exchange equipment items, including air coolers, plate and other heat exchanger types. The shell and tube exchanger model is presented below.


FIATECH AEX Project


eqHxDoc: ShellTubeExchangerDataSheet

eqHx:HeatExchangerEquipment

eqHx:ShellTubeExchangerUnit

eq:FacilityItemA

obj:Object

eqHx:exchangerDesign

uo: ShellTubeExchangerUnitOperation

uo:HeatExhangerUnitOperation

site:SiteFacility

eqHx: shellTubeExchangerAssembly

eqHx:ExchangerNozzle

eqHx:bundle

eqHx:end

eqHx:performance

eqHx:reboilerPiping

eqHx:shell

uo: MaterialStream

uo: Streamuo:UnitOperation

uo:ProcessPort

uo: HeatExchangerSide

eq:EquipmentItem

thmo:PropertyDataTable

eq:EquipmentConnection

dx:DataSheetA

eqHx:Tube

As discussed already in the eq namespace discussion the shell and tube exchanger derives characteristics through the following inheritance hierarchy, which is similar to the centrifugal pump inheritance hierarchy shown in Figures 1, 3 and 5.

obj:BaseObject |__ obj:Object |__eq:FacilityItemA |__ eq:EquipmentItem |__ eqHx:HeatExchangerEquipment |__ eqHx:ShellTubeHeatExchangerUnit

A shell and tube item contains the following major equipment item components:

bundle, which contains tubes, tubesheet, baffles, etc. end ExchangerNozzle – which is extended from EquipmentConnection reboiler Piping shell

The process performance information and stream information are described


FIATECH AEX Project

obj:BaseObject |__ obj:Object |__uo:UnitOperation |__ uo:HeatExchangerUnitOperation |__ uo:ShellTubeExchangerUnitOperation |__ uo:HeatExchangerSide

The heat exchanger side unit operation has process ports and material stream property data for the process fluid.

The datasheet is the container for shellTubeHeatExchanger, unit operations data, material stream properties.

4. GETTING STARTED WITH CFIXML The cfiXML schemas are large, complex, and set up to be used in multiple usage scenarios. Given this size and complexity, how can we best get started to use them?

First, you answer the question: What do I want to do?

If you are reading this document, chances are you are responsible for a software application that needs to read and write XML instance files that conform to the schema definitions so that users of your software won’t have to manually re-key information from one software application to another. Refer to the Section 1 for more information about usage scenarios and business context and to the XML Schema Development Guidelines for an introduction to XML and basic XML file exchange and messaging usage scenarios.

Here we will focus on the XML file exchange usage scenario in preference to messaging usage scenarios. In the file exchange scenario, application software “imports” or “exports” XML instance files and the transport of those files is most likely to occur as email attachments or as part of other work process environments.

Here are the basic steps for setting up an XML import/export interface in your application software:

1. Determine what data needs to be read into or written from your software application to support one or more usage scenarios that are of interest to your users. Refer to the Introduction document for sample usage scenarios to understand what data you may want to transfer on behalf of your users. Talk to your users about the data they would like to transfer to/from your application.

2. Review the existing XML ‘document’ schemas (see the ‘document’ folder) to see if there are existing XML document definitions that can be used, e.g., see the Centrifugal Pump data sheet element which is defined in the ‘document/eqRot.xsd’ file. An example of a centrifugal pump datasheet is found in the ‘examples/DataSheetPumpRP4194R1.xml’ You may need to consider defining your own document schema definition file, if the existing exchange document definitions do not meet your need. If your scope of data exchange is very narrow, e.g., contained within a single global element, then consider using one of the global elements defined in any of the schema definition files.

3. Understand how the information is stored in your own application and what programming interfaces are required to get and put information into application storage.

4. Design and document a mapping table between the data structures in your own application for the data you want to transfer (either import, export or both). As part of the mapping table, in one column of the table define the storage location and function calls required to get or put information from/to the application storage. In a second column define the Xpath to the element in the cfiXML schemas that match the data item(s) you want to transfer. Xpath is a notation that can be used by XML Stylesheet Language Tranformations (XSLT) to “flatten” the XML tree structure in an XML instance file by providing a unique path definition to data contained within an XML instance file.

5. Write application code for “import” and/or “export” that uses an XML parser, such as MSXML or Xerces, and the DOM or SAX application programming interface(s) to parse the XML instance file to get or put information into an XML instance file and your application storage according to the mapping table you defined in step 4.


FIATECH AEX Project

While XML schema files can be reviewed in native form, we highly recommend that XML schema files should be reviewed in an XML schema interactive development environment such as XML Spy from Altova, Inc. TurboXML from TIBCO, or VisualStudio from Microsoft. For the purpose of this document, we will present the XML files in native formats.

An open source public example of an EXCEL workbook that contains the minimum data for the centrifugal pump BidRFQ and BidQuote usage scenarios, a simple inquiry/purchase order, and a Visual Basic for Applications programming example will soon be available as a NIST report. This programming example can be used as a ‘go-by’ reference for getting started on building your own software application interfaces for mapping, reading and writing cfiXML files from your internal application software.

The next section provides a small introductory example to show how the existing cfiXML schemas may be used and extended as needed.

5. PUMP TUTORIAL – USING AND EXTENDING THE SCHEMAS In this section, we illustrate how to use an existing equipment item, a centrifugal pump, to illustrate how the existing schemas can be directly used, and extended if needed.

Consider a centrifugal pump, which has the following characteristics:

- equipment tag: P-101 - dry weight: 435 lbs - normal capacity: 35 gallons/minute - manufacturer: XYZ Flow Equipment Company - model: A-1 - type: OH3 - operating environment: outdoor

The pump tutorial shows how

- to use existing schemas as is - to extend existing schemas to accommodate new information

The tutorial is carried out in stages:

Part 1 - Using Existing schemas

a. Using the built-in schema for values we know and are already in the schema

b. Using Units of Measurement

Part 2 – Extending/customizing the schemas (optional, only if you have the interest)

a. Extending the schema for values that are not in the schema using the “custom” extension mechanism that accommodates ‘any’ elements.

b. Extending the schema with user-supplied enhancement schemas

c. Defining user extensions to enumeration values

The example files for this pump tutorial are located in the ‘schema/custom/cfixml-org’ folder in the standard distribution zip file.


FIATECH AEX Project

5.1 Part 1 – Using the existing schemas

Part 1a – Using pre-defined core objects and elements From a basic understanding of XML, we know that we can assign each part of the data to an element enclosed in tags and even without knowing anything about the schema, we would expect the XML data file for our pump to look something like:

<centrifugalPump> <tag>P-101</tag> <dryWeight>435.0</dryWeight> <normalCapacity>35</normalCapacity> <manufacturerCompany>XYZ Flow Equipment Company</manufacturerCompany> <model>A-1</model> <type>OH3</type> <operatingEnvironment>outdoor</operatingEnvironment>

</centrifugalPump>

How do we describe this pump using the cfiXML core schema framework? First we need to look for schemas that already exist. If I look at Figure 5, the Object Library Summary, I find eqRot:CentrifugalPump as an object listed on the diagram. The prefix “eqRot:” denotes that this is included in the rotating equipment namespace. Consulting the Contents document, section 1.3, I can see that the eqRot namespace has four schema files associated with it – eqRot, eqRotBase, eqCpmp, and eqSeal. Then reading the file description, I see that the XML schema definition file I want is located in the eqCpmp.xsd file. Now that I’ve found the equipment item schema that I need, I would also like to look at the ‘document’ schemas that have been defined in the document subfolder. Again, looking at section 1.3 of the Contents document, I find a document, eqRotDoc.xsd that contains the document schema definition for a centrifugal pump datasheet. So, the two XML schema definition files I will want to look at first will be the eqRotDoc.xsd file and the eqCPmp.xsd file. As illustrated in Figure 1, the centrifugal pump datasheet contains the equipment item, ‘centrifugalPump.’ It also contains other information such as material properties and environmental conditions. As illustrated in Figures 1, 3 and 5, the centrifugal pump is defined as the bottom layer extension of a multiple layer inheritance hierarchy object data model, summarized as follows: obj:BaseObject |__ obj:Object |__eq:FacilityItemA |__ eq:EquipmentItem |__ eqRot:RotatingEquipment |__ eqRot:CentrifugalPump The structure of the inheritance hierarchy schema is powerful, because it allows reuse of information at each layer across multiple object types and equipment types. However, with this power for reusability of schema definitions comes with the price of some complexity in the use of the schemas, because there are multiple places to search in the inheritance hierarchy when you are looking for a particular data element. The general nature of the content of this inheritance hierarchy can be summarized as follows:

1. obj:BaseObject holds common data about all objects, e.g., the unique ObjectID, the name and description 2. obj:Object holds common data about engineering objects, e.g., the revision number, the revision date, etc. 3. eq:FacilityItemA holds common data about any facility item, e.g., its id information, weight or cost 4. eq:EquipmentItem holds common data about any engineered equipment item, e.g., its design or

documentation and certification requirements Using XML Schemas for Facilities Equipment, v.2.0 - 41 - 19 July, 2004

FIATECH AEX Project

5. eq:RotatingEquipment holds common data about any item of rotating equipment, e.g., the various pieces and parts of rotating equipment like bearings, seals, baseplates, etc.

6. eq:CentrifugalPump holds data specific to centrifugal pumps, e.g., information about vertically suspended pumps, applicable centrifugal pump standard, etc.

The way XML works is that each of these layers in an inheritance hierarchy shows up in the schema definition as a separate part of the element sequence. The ordering of elements in an instance file starts with the BaseObject data, then follows with ObjectData then FacilityItem data, etc. to CentrifugalPump data. The practical impact of this inheritance structure is that, when you are doing mappings to your software application, and you don’t immediately find the information element you’re looking for, you need to keep looking throughout the inheritance hierarchy until you find what you need. After working with the schemas for a while, you become familiar with which level to start looking first. In a graphical XML editor such as XML Spy, this task is relatively easy, because you can start with eqRot:CentrifugalPump and all levels of the hierarchy are shown at once, in the correct order. Let’s consider our pump data items listed above (without regard to the actual schema) to see where we might begin looking: <centrifugalPump>

<tag>P-101</tag> <dryWeight>435.0</dryWeight> <normalCapacity>35</normalCapacity> <manufacturerCompany>XYZ Flow Equipment Company</manufacturerCompany> <model>A-1</model> <type>OH3</type> <operatingEnvironment>marine</operatingEnvironment>

</centrifugalPump>

I used XML Spy to create the following XML file, using the built-in schema definition for CentrifugalPumpDataSheet in the eqRotDoc.xsd file for a centrifugal pump datasheet. Our initial XML description of the pump is: <?xml version="1.0" encoding="UTF-8"?>  <centrifugalPumpDataSheet objectID="dxDsCpmp.DataSheetCentrifPump.Doc1012" xmlns="http://www.cfixml.org/document/eqRotDoc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:obj="http://www.cfixml.org/obj" xmlns:ctx="http://www.cfixml.org/ctx" xmlns:site="http://www.cfixml.org/site" xmlns:eq="http://www.cfixml.org/eq" xmlns:eqRot="http://www.cfixml.org/eqRot" xsi:schemaLocation="http://www.cfixml.org/document/eqRotDoc ../../document/eqRotDoc.xsd"> <site:siteFacility objectID="site.SiteFacility.NotSitedYet"> <site:siteSubArea objectID="site.SiteSubArea.P-101"> <site:characteristic> <site:isIndoor>false</site:isIndoor> </site:characteristic> </site:siteSubArea> </site:siteFacility> <eqRot:centrifugalPump objectID="eqRot.CentrifugalPump.P-101"> <eq:id> <ctx:manufacturerCompany objectID="ctx.Organization.XYZFlowEquipmentCompany"> <obj:name>XYZ Flow Equipment Company</obj:name> </ctx:manufacturerCompany> <eq:model>A-1</eq:model> <eq:tag>P-101</eq:tag> </eq:id> <eq:weight> <eq:weightType>dry</eq:weightType> <eq:value>435</eq:value> Using XML Schemas for Facilities Equipment, v.2.0 - 42 - 19 July, 2004

FIATECH AEX Project

</eq:weight> <eqRot:operatingCondition> <eqRot:condition> <eqRot:volumetricFlow>35</eqRot:volumetricFlow> <eq:operatingConditionType>normal</eq:operatingConditionType> </eqRot:condition> </eqRot:operatingCondition> <eqRot:centrifugalPumpISOClassification>OH3</eqRot:centrifugalPumpISOClassification> </eqRot:centrifugalPump> </centrifugalPumpDataSheet>

The root element of the document, centrifugalPumpDataSheet, includes other attributes that first define the required namespaces, the schema location and adds the objectID attribute. One thing to notice is that the centrifugal pump data sheet document contains elements from several namespaces (obj, site, ctx, eq, and eqRot) because:

1. a Data Sheet is an arbitrary container document for other objects – some from site description date and some from rotating equipment, and

2. even for centrifugal pump, the inheritance hierarchy described above spans three namespaces – obj, eq and eqRot.

So, the elements contained within the data sheet document that come from namespaces other than the containing datasheet document are then always prefixed with their namespace prefix.

The operating environment description of “operating outdoors” is specified using the site:characteristic/isIndoor element, set to false to indicate outdoors.

The manufacturer company is specified using the ctx:manufacturerCompany element.

The equipment tag and model elements are contained within the centrifugalPump element, inside the “id” tag, which provides for a number of other ways that equipment can be identified.

The dry weight is one type of weight that can be associated with EquipmentItems in the eq namespace, and is modeled as two elements – the type and the value. This approach, while slightly more complex than having a single ‘dryWeight’ element has the advantage of being easily extensible to the current built in enumeration list for weight types. The operating condition for normal volumetric flow rate capacity is modeled using a similar approach in the eqRot namespace. Finally, the pump type is found in the centrifugal pump part of the model in the eqRot namespace.

So, the existing schema can be used to populate information about our pump without any modifications whatever – except – what about the units of measurement? We address this in part 1b.

Part 1b - Using units of Measurement So what units are the recorded values measured in for the XML file we just created? The answer is that the default unit set for cfiXML is SI units, if they are not otherwise specified.

We can specify units at the file level, at the object level, or at the element level for each quantity. There are three ‘built-in’ unit sets (see pq.xsd, complex types – SI, Metric and USEngineering). Each of these is a sequence where the default unit label is set for the 80+ built-in physical quantities. Each physical quantity has a built-in, but extensible list of common unit labels from which you can select.

In this example, to be sure we are recording the correct values in the XML instance file, we will specify the USEngineering Unit Set at the file level, and then over-ride the label for the volumetric flow rate so that it will be in US Gallons/minute.

<?xml version="1.0" encoding="UTF-8"?>  <centrifugalPumpDataSheet objectID="eqRotDoc.DataSheetCentrifPump.Doc1012" xmlns="http://www.cfixml.org/document/eqRotDoc" xmlns:xsi="http://www.w3.org/2001/XMLSchema- Using XML Schemas for Facilities Equipment, v.2.0 - 43 - 19 July, 2004

FIATECH AEX Project

instance" xmlns:custom="http://www.cfixml.org/custom/cfixml-org/custom" xmlns:ctx="http://www.cfixml.org/ctx" xmlns:obj="http://www.cfixml.org/obj" xmlns:site="http://www.cfixml.org/site" xmlns:eq="http://www.cfixml.org/eq" xmlns:eqRot="http://www.cfixml.org/eqRot" xsi:schemaLocation="http://www.cfixml.org/custom/cfixml-org/custom ../../../schema/custom/cfixml-org/custom3.xsd http://www.cfixml.org/document/eqRotDoc ../../document/eqRotDoc.xsd" unitSet="USEngineering"> <site:siteFacility objectID="site.SiteFacility.NotSitedYet"> <site:siteSubArea objectID="site.SiteSubArea.P-101"> <site:characteristic> <site:isIndoor>false</site:isIndoor> </site:characteristic> </site:siteSubArea> </site:siteFacility> <eqRot:centrifugalPump objectID="eqRot.CentrifugalPump.P-101"> <eq:id> <ctx:manufacturerCompany objectID="ctx.Organization.XYZFlowEquipmentCompany"> <obj:name>XYZ Flow Equipment Company</obj:name> </ctx:manufacturerCompany> <eq:model>A-1</eq:model> <eq:tag>P-101</eq:tag> </eq:id> <eq:weight> <eq:weightType>dry</eq:weightType> <eq:value>435</eq:value>  </eq:weight> <eqRot:operatingCondition> <eqRot:condition> <eqRot:volumetricFlow symbol="US_gal/min">35</eqRot:volumetricFlow>  <eq:operatingConditionType>normal</eq:operatingConditionType> </eqRot:condition> </eqRot:operatingCondition> <eqRot:centrifugalPumpISOClassification>OH3</eqRot:centrifugalPumpISOClassification> </eqRot:centrifugalPump> </centrifugalPumpDataSheet>

The XML schema provides a default set of valid symbols as enumeration data types (see ‘pq’ namespace discussion in Section 3). These enumeration data types, like any others in the schema framework, may be extended to use other symbols that are not part of the standard symbol set if so desired.

5.2 Part 2 – Extending/Customizing the schemas What if, instead of ‘outdoors’ we wanted to designate the pump as operating in a “marine environment”? We have two options:

- add the required elements directly to the XML instance file using the ‘customSiteCharacteristic’ tag.

- create a new XML schema file, extending the siteSubArea with the required elements.

Finally, what if the ISO Classification team adds a pump designated as OH5, which is not a valid choice in the current enumeration choice list for centrifugal pump ISO Classification element.

We will examine each of these situations in this part.

FIATECH AEX Project

Part 2a – Adding custom data directly through custom elements The simplest way to provide extra data elements is to use the extensibility built into the schema using the ‘custom’ element found at the end of the appropriate sequence in the schema. In this example, we will add the custom element “isMarine” as an extension of “SiteSubArea/characteristic.”

<?xml version="1.0" encoding="UTF-8"?>  <centrifugalPumpDataSheet objectID="eqRotDoc.DataSheetCentrifPump.Doc1012"  <site:siteFacility objectID="site.SiteFacility.NotSitedYet"> <site:siteSubArea objectID="site.SiteSubArea.P-101"> <site:characteristic> <site:customSubAreaCharacteristic> <isMarine>true</isMarine> </site:customSubAreaCharacteristic> </site:characteristic> </site:siteSubArea> </site:siteFacility> <eqRot:centrifugalPump objectID="eqRot.CentrifugalPump.P-101">  </eqRot:centrifugalPump> </centrifugalPumpDataSheet> In this example, all we did was add the custom element directly under the ‘site:characteristic’ element that was already built in to the base schema for SiteSubArea. The additional element for isMarine is contained directly within the customSiteSubArea block.

This approach is easy. However, the shortcoming of it is that the data is not validated to know that it is a Boolean value, because the elements contained within the customSiteSubArea (or any custom element in the schema) can literally be anything you want. As long as the XML is well-formed with data enclosed with valid XML tags, no further validation is made. This is OK, provided when you build your software application that uses this, you take on the additional burden of ensuring the data is valid.

In the next step, we show you how you can add data elements of a particular data type and have the XML parser validate against this data type, saving you work in your application code.

Part 2b – Adding elements by defining a custom extension schema In this example, we show how to do a user extension using a separate custom schema file. This is very powerful for defining extensions that are not already in the schema. In this example, we are doing the relatively simple task of adding an additional element to the site schema to describe the “isMarine” extension under SiteSubArea/characteristic to be fully validated as a Boolean data item by the XML parser. This is advantageous to applications, because data validation is done directly by the XML parser, not the application code.

The custom user schema file, custom.xsd is as follows:

<?xml version="1.0" encoding="utf-8"?>  <xsd:schema targetNamespace="http://www.cfixml.org/custom/cfixml-org/custom" xmlns="http://www.cfixml.org/custom/cfixml-org/custom" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ext="http://www.cfixml.org/ext" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.00.0000"> <xsd:import namespace="http://www.cfixml.org/ext" schemaLocation="../../../schema/ext.xsd"/> <xsd:element name="isMarine" type="ext:Boolean" nillable="true"/> </xsd:schema>

FIATECH AEX Project

We first declare a custom namespace according to cfiXML usage convention as “http://www.cfixml.org/custom/cfixml-org/custom.” Second we use XML’s import feature to import the “ext” namespace, which defines the “Boolean” data type, by adding a few additional attributes to the base data type xsd:boolean as defined under the ‘ext’ namespace (see section on the ‘ext’ namespace for more details). Finally, we define an element for ‘isMarine’ in this namespace which is has the data type of “ext:Boolean.” In the XML instance file, virtually everything is the same, except we declare the ‘custom’ namespace and substitute “custom:isMarine” in place of the unvalidated ‘isMarine’ element we added in Part 2. The advantage of doing this is that now, the XML parser will validate the ‘isMarine’ element as a Boolean data type.

<?xml version="1.0" encoding="UTF-8"?>  <centrifugalPumpDataSheet objectID="dxDsCpmp.DataSheetCentrifPump.Doc1012" xmlns="http://www.cfixml.org/document/eqRotDoc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:obj="http://www.cfixml.org/obj" xmlns:ctx="http://www.cfixml.org/ctx" xmlns:custom="http://www.cfixml.org/custom/cfixml-org/custom" xmlns:site="http://www.cfixml.org/site" xmlns:eq="http://www.cfixml.org/eq" xmlns:eqRot="http://www.cfixml.org/eqRot" xsi:schemaLocation="http://www.cfixml.org/eqRotDoc ../../../schema/document/eqRotDoc.xsd http://www.cfixml.org/custom/cfixml-org/custom ../../../schema/custom/cfixml-org/custom2b.xsd "> <site:siteFacility objectID="site.SiteFacility.NotSitedYet"> <site:siteSubArea objectID="site.SiteSubArea.P-101"> <site:characteristic> <site:customSubAreaCharacteristic> <custom:isMarine>true</custom:isMarine> </site:customSubAreaCharacteristic> </site:characteristic> </site:siteSubArea> </site:siteFacility> <eqRot:centrifugalPump objectID="eqRot.CentrifugalPump.P-101">  </eqRot:centrifugalPump> </centrifugalPumpDataSheet>

This solution, while it is not as easy as using the customSubAreaCharacteristic element already built in to the schema as in Part 2a, is much more powerful, because it offers the advantage of full parser validation of the data. This maybe not so important a consideration for a one-element extension, but is very useful if a large number of elements or complex structure is needed.

Part 2c – Adding extensions to enumeration variable values The cfiXML schemas have many built-in enumeration value elements in the schema. While we make every effort to make them complete, we recognize that enumeration elements will need to be occasionally extended by schema users. For example, the ISO Classification team has recently added a pump designated as OH5, but this choice is not available in the base schema. To add this choice to the enumeration list, we will show how to extend the ‘custom’ schema extension from part 2b, where we added the new element ‘isMarine.’ In this case we simply add a new element as a standard enumeration variable (restriction of the xsd:string datatype). Our new ‘custom’ schema now becomes:

<?xml version="1.0" encoding="utf-8"?>  <xsd:schema targetNamespace="http://www.cfixml.org/custom/cfixml-org/custom" xmlns:ext="http://www.cfixml.org/ext" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.cfixml.org/custom/cfixml-org/custom" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.00.0000"> Using XML Schemas for Facilities Equipment, v.2.0 - 46 - 19 July, 2004

FIATECH AEX Project

<xsd:import namespace="http://www.cfixml.org/ext" schemaLocation="../../../schema/ext.xsd"/> <xsd:element name="centrifugalPumpISOClassification"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="OH5"/> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="isMarine" type="ext:Boolean" nillable="true"/> </xsd:schema>

Using this custom schema, the XML instance file changing the centrifugaPumpISOClassification from OH3 to OH5 is the following:

<?xml version="1.0" encoding="UTF-8"?>  <centrifugalPumpDataSheet objectID="eqRotDoc.DataSheetCentrifPump.Doc1012"  <site:siteFacility objectID="site.SiteFacility.NotSitedYet">  </site:siteFacility> <eqRot:centrifugalPump objectID="eqRot.CentrifugalPump.P-101">  </eqRot:operatingCondition> <eqRot:centrifugalPumpISOClassification>custom</eqRot:centrifugalPumpISOClassification> <custom:centrifugalPumpISOClassification>OH5</custom:centrifugalPumpISOClassification> </eqRot:centrifugalPump> </centrifugalPumpDataSheet>

Note that the built-in schema element choice has the choice of custom, and then the next element comes from the ‘custom’ namespace defined in our user-supplied custom schema definition file.

FIATECH AEX Project

APPENDIX A. UML NOTATION REFERENCE In this document we make use of a small subset of Unified Modeling Language (UML) notation to depict relationships among object classes in the cfiXML object model. In this appendix, we summarize the notation subset that we have used.

A

Indicates inheritance, or extends relationship; B inherits characteristics from A, or B extends A

B

Indicates uses relationship; B uses A

A

B

Indicates contains relationship; A contains B

A

B

A

Indicates may contain or reference relationship; A may contain B, A may contain a reference to B

B


FIATECH AEX Project

APPENDIX B. DATA TYPES (EXT: NAMESPACE) Name Description AnyCharacterName A string of any characters other than whitespace. AnyCharacterNameList List of strings of any characters other than whitespace. AnyCharacterNameTable Table of strings of any characters other than whitespace. Base64Binary Binary data converted to text using base64. Boolean Boolean (logical). BooleanList Boolean (logical) - list. BooleanTable Boolean (logical) - table. Byte Byte or unsigned character. ByteList Byte or unsigned character - list. ByteTable Byte or unsigned character - table. Currency Currency CurrencyList Currency - list Custom Any custom elements, user defined or external, any number of times. Date Date DateList Date - list DateTable Date - table DateTime Date and time. Double Double precision number. DoubleList Double precision number - list. DoubleTable Double precision number - table. DoubleWord Double word or unsigned long. DoubleWordList Double word or unsigned long - list. DoubleWordTable Double word or unsigned long - table. Duration Change in Date and Time DurationList Change in Date and Time - List DurationTable Change in Date and Time - List GUID Globally unique identifier GUIDList Globally unique identifier - list. HexBinary Hex-encoded binary data HexBinaryList Hex-encoded binary data - list. Integer Integer IntegerList Integer - list. IntegerTable Integer - table. LongInteger Long integer LongIntegerList Long integer - list LongIntegerTable Long integer - table Name Name starting with a letter and containing no delimiter characters. NameList Name starting with a letter and containing no delimiter characters - list. NameTable Name starting with a letter and containing no delimiter characters - table. ShortInteger Short integer ShortIntegerList Short integer - list. ShoutIntegerTable Short integer - table. String String of characters including spaces. Time Time TimeList Time - list TimeTable Time - table URI Universal resource identifier. URIList Universal resource identifier - list. Word Word or unsigned integer. WordList Word or unsigned integer - list. WordTable Word or unsigned integer - table.


FIATECH AEX Project

Name Description XPath XPath. Xpointer Xpointer Xpointer XpointerList Year Year


FIATECH AEX Project

APPENDIX C. PHYSICAL QUANTITIES (PQ: NAMESPACE) Name Description Units Acceleration Acceleration. (length/time squared) ft/s2

m/s2 Angle Plane angle. deg

min_angle s_angle rad

AngleSolid Solid Angle. sr AngularMomentum Angular momentum. (mass x velocity x length) kg.m2/s

lb.ft2/s AngularVelocity Angular velocity. (angle/time) deg/s

rad/min rad/s rev/min rev/s

Any Any Engineering Variable - Scalar Area Area. (length squared) acre

ft2 ha in2 m2 mile2 yd2

AreaMole Molar specific area. (area/mole) ft2/lbmol in2/lbmol m2/gmol m2/mol m2/kmol

Brightness Luminous intensity cd cp

ConcentrationMass Concentration. (mass/volume) see DensMass ConcentrationMole Molar concentration. (quantity/volume) see DensMole CpMass Specific heat capacity. (heat/(mass x temperature interval) Btu/lb.degF

ft.lbf/lb.degF J/kg.K kcal/kg.K kgf.m/kg.K kJ/kg.degC

CpMole Molar specific heat capacity Btu/lbmol.degF ft.lbf/lbmol.degF J/gmol.K J/mol.K kcal/kmol.K kgf.m/kmol.K kJ/kmol.degC kJ/kmol.K

CpVolume Heat capacity, volume basis. (heat/(volume x temperature interval))

Btu/ft3.degF J/m3.K kcal/m3.K kJ/m3.degC

DensityLength Linear density or mass per unit length. (mass/length) kg/m lb/ft


FIATECH AEX Project

Name Description Units lb/in lb/mile lb/yd

DensityMass Density. (mass/volume) degApi g/cm3 g/dm3 g/l g/ml kg/m3 lb/ft3 lb/in3 lb/UK_gal lb/US_gal oz/UK_gal oz/US_gal sg ton/yd3

DensityMole Molar Density. (mole/volume) kmol/m3 lbmol/ft3 lbmol/in3 lbmol/UK_gal lbmol/US_gal mol/cm3 mol/dm3 mol/l mol/m3 mol/ml gmol/cm3 gmol/dm3 gmol/l gmol/m3 gmol/ml

DensityVelocitySquared Density velocity squared or RhoV² (density x velocity²) see P Diffusivity Diffusivity. Equivalent to kinematic viscosity - viscKin.

(area/time) see ViscKin

ElectricalCapacitance Electric capacitance (charge/voltage) C/V F

ElectricalCharge Electric charge A.s C

ElectricalChargeMoment Electric charge moment C.m A.s.m

ElectricalCurrent Electric current A ElectricalEnergy Electrical energy. see Energy ElectricalPower Electrical power associated with electrical equipment. see Power Energy Energy - work, heat, etc. Btu

cal cal_15 cal_th ft.lbf ft.pdl hp.h J kgf.m kJ


FIATECH AEX Project

Name Description Units kW.h lbf.ft lbf.in MJ N.m ozf.in pdl.ft tonf.ft W.s

EnergyMass Mass Specific Energy. (energy or heat/mass) Btu/lb ft.lbf/lb J/kg kcal/kg kgf.m/kg kJ/kg

EnergyMole Molar specific energy. (energy/quantity) Btu/lbmol ft.lbf/lbmol J/kmol J/gmol J/mol kcal/kmol kgf.m/kmol kJ/kmol

EnergyPressureCoef Energy pressure coefficient (energy/pressure) Btu/psi ft.lbf/psi J/Pa J/kPa kcal/kPa kgf.m/kPa kJ/kPa

EnergyVolume Energy content, volume basis or calorific value. (heat/volume)

see P

EntropyMass Specific entropy. (heat/(mass x thermodynamic temperature))

see CpMass

EntropyMole Molar specific entropy. (heat/(quantity x thermodynamic temperature))

see CpMole

FlowMass Mass rate of flow. (mass/time) kg/h kg/s lb/h lb/s ton/h

FlowMole Molar flow rate. (quantity/time) kmol/h kmol/s lbmol/h lbmol/s mol/s gmol/s

FlowStandardVolume Standard volume rate of flow. (volume/time) see FlowVol FlowVolume Volume rate of flow. (volume/time) ft3/h

ft3/min ft3/s l/h l/min l/s


FIATECH AEX Project

Name Description Units m3/h m3/min m3/s UK_gal/h UK_gal/min UK_gal/s US_gal/h US_gal/min US_gal/s

Fluidity Fluidity, reciprocal dynamic viscosity. (velocity gradient/stress)

per_cP m2/kgf.s ft2/lbf.h ft2/lbf.s per_Pa.s ft2_pdl.s

Force Force. (mass x acceleration) dyn kgf lbf N ozf pdl tonf

FoulingRes Fouling resistence (area x temp. difference / power) cm2.s.K/cal ft2.h.degF/Btu m2.degC/kW m2.h.K/kcal m2.K/W

Frequency Frequency. (number/time) Hz HenryConstantMolality Henry's law constant - Molality. (pressure x molar density) Pa.kg/kmol

kPa.kg/kmol psi.lb/lbmol

HenryConstantMolarity Henry's law constant - Molarity. (pressure x molar volume) Pa.m3/kmol kPa.l/kmol

Heat Heat energy. see Energy HeatFlow Heat flow rate such as boiler power. see Power HeatFlux Heat flux density. (heat/(area x time)) Btu/ft2.h

cal/cm2.s kcal/m2.h kW/m2 W/in2 W/m2

HeatReleaseRate Heat release rate. (heat/(volume x time)) Btu/ft3.h cal/cm3.s kcal/m3.h kW/m3 W/m3

HeatTransferCoef Heat transfer coefficient or thermal conductance. (heat/(areax time x temp. difference)

Btu/ft2.h.degF cal/cm2.s.K kcal/m2.h.K kW/m2.K W/m2.K

JTCoef Joule-Thomson coefficient. (temperature/pressure) K/Pa K/kPa degC/kPa


FIATECH AEX Project

Name Description Units decC/bar degF/psi degR/psi

LargeLength Large distances as measured in km or miles. see Len Length Length angstrom

cm fathom ft in km m micro_m mil mile mm n_mile thou yd

LengthReciprocal Reciprocal Length per_cm per_ft per_in per_m per_micro_m per_mil per_mm

Mass Mass cwt g kg lb metric_carat mg micro_g oz shcwt shton slug stone t ton u

MassPerArea Mass per unit area. (mass/length squared) kg/ha kg/m2 lb/thousand_ft2 lb/acre oz/ft2 oz/yd2 ton/mile2

MassTransferCoef Mass transfer coefficient (mole/time.area)/(mole/volume) mol/s.m2/mol/m3 MassVelocity Mass velocity (mass/(area x time)) kg/s.m2

lb/h.ft2 MechanicalPower Mechanical power associated with mechanical equipment. see Power ModulusOfElasticity Modulus of elasticity. (force/area) see P Mole Mole or quantity of a substance. gmol

kmol


FIATECH AEX Project

Name Description Units lbmol mol

MolecularWeight Molecular weight (mass/quantity) kg/kmol g/gmol g/mol lb/lbmol u

MolecularWeightReciprocal Reciprocal molecular weight (quantity/mass) gmol/g mol/g kmol/kg lbmol/lb

MomentInertia Moment of inertia. (mass x length squared) kg.m2 lb.ft2 lb.in2 oz.in2

MomentOfForce Moment of force, or torque. (force x length) see Energy Momentum Momentum, linear. (mass x velocity) g.cm/s

kg.m/s lb.ft/s

NauticalLength Nautical distances as used at sea. see Len P Pressure (force/area) atm

bar Btu/ft3 ftH2O hbar inH2O inHg J/m3 kcal/m3 kg/m.s2 kgf/cm2 kJ/m3 kPa lb/ft.h2 lbf/ft2 lbf/in2 mbar mmHg MPa N/m2 N/mm2 Pa pdl/ft2 psi th/litre therm/UK_gal tonf/ft2 tonf/in2 torr

PDifference Pressure difference or interval. (force/area) atmDiff barDiff ftH2ODiff hbarDiff inH2ODiff


FIATECH AEX Project

Name Description Units inHgDiff kgf/cm2Diff kPaDiff lbf/ft2Diff lbf/in2Diff mbarDiff mmHgDiff MPaDiff N/m2Diff N/mm2Diff PaDiff psiDiff pdl/ft2Diff tonf/ft2Diff tonf/in2Diff torrDiff

PressureDropGradient Pressure drop per length ((force/area)/length) bar/m Pa/m psi/ft

Power Power. (energy/time) Btu/h cal/s ft.lbf/s GW hp kcal/h kgf.m/s kV.A kW MW V.A W

PReciprocal Reciprocal Pressure (area/force) per_atm per_bar per_Btu/ft3 per_ftH2O per_hbar per_inH2O per_inHg m3/J m3/kcal m.s2/kg cm2/kgf m3/kJ per_kPa ft.h2/lb ft2/lbf in2/lbf per_mbar per_mmHg per_MPa m2/N mm2/N per_Pa ft2/pdl


FIATECH AEX Project

Name Description Units per_psi litre/th UK_gal/therm ft2/tonf in2/tonf per_torr

SmallLength Small length such as measured in mm or inches. see Len SolubilityParameter Solubility parameter Pa1/2 Stress Stress. (force/area) see P SurfaceMass Specific surface or area per unit mass. (length

squared/mass) acre/lb cm2/mg ft2/oz ha/kg kft2/lb m2/g m2/kg mm2/mg yd2/oz

SurfaceTension Force per unit length or surface tension. (force/length) dyn/cm N/m

T Temperature - absolute. degC degF degR K

TemperatureDifference Temperature - difference or interval. degCDiff degFDiff degRDiff KDiff

ThermalConductivity Thermal conductivity. (heat x length/(area x time x temperature difference))

Btu.in/ft2.h.degF Btu/ft.h.degF cal/cm.s.K kcal/m.h.K kW/m.degC W/m.K

ThermalDiffusivity Thermal diffusivity. Equivalent to kinematic viscosity - viscKin. (area/time)

see ViscKin

ThermalExpansion Thermal expansion, linear in/degF m/degC m/K

ThermalExpansionVolume Thermal expansion, volume in3/degF m3/degC m3/K

ThermalP Thermal pressure. (pressure/temperature) Pa/K kPa/K kPa/degC bar/degC psi/degF psi/degR

ThermalResistivity Thermal resistivity. (area x time x temp. difference/(heat x length))

cm.s.K/cal ft.h.degF/Btu ft2.h.degF/Btu.in m.degC/kW m.h.K/kcal m.K/W


FIATECH AEX Project

Name Description Units Time Time. d

h min s week

Torque Torque or moment of force. (force x length) see Energy TReciprocal Reciprocal temperature per_degC

per_degF per_degR per_K

Velocity

Linear velocity or speed. (length/time) ft/min ft/s in/s km/h kn m/s mile/h

VerySmallLength Very small length such as measured in µm or mil. see Len Viscosity Viscosity, dynamic. (stress/velocity gradient) cP

kgf.s/m2 lbf.h/ft2 lbf.s/ft2 Pa.s pdl.s/ft2

KinematicViscosity Viscosity, kinematic. (length squared/time) cSt ft2/h ft2/s in2/h in2/s m2/h m2/s

Volume Volume. (length cubed) bbl bbl_dry cm3 dm3 ft3 in3 l m3 ml mm3 UK_fl_oz UK_gal UK_pt US_fl_oz US_gal US_pt US_qt yd3

VolumeSquaredMoleSquared Molar specific volume squared. (volume2/mass2) ft6/lbmol2 in6/lbmol2 l2/gmol2 l2/mol2 l2/kmol2


FIATECH AEX Project

Name Description Units m6/gmol2 m6/mol2 m6/kmol2

VolumeMass Specific volume. (volume/mass) ft3/lb ft3/ton in3/lb l/kg m3/kg UK_gal/lb

VolumeMole Molar specific volume. (volume/mole) ft3/lbmol in3/lbmol l/gmol l/mol l/kmol m3/gmol m3/mol m3/kmol UK_gal/lbmol US_gal/lbmol

Voltage Voltage or electric potential (energy/time.elecCurrent) kV micro_V mV MV V

WaveLength Wavelength measured in Angstroms. see Len WeightForce Weight (force) see Force WeightMass Weight (mass) see Mass Work Work energy. see Energy

APPENDIX D. MATERIAL PROPERTIES (MTRL: NAMESPACE) The following is the current list of properties under the Property type in the mtrl namespace. Scalar values, Lists and Tables are all supported.

acentricFactor acidity acidNumber activity activityCoef activityCoefList adiabaticCompressibility


FIATECH AEX Project

adiabaticCompressibilityList adsorptionCapacity alkalinity anilinePoint amountMass amountMole amountStandardVolume apiGravity apparentCpMole apparentEnthalpyMole apparentEntropyMole apparentGibbsEnergyMole apparentVolumeMole apparentReactionKMoleFraction apparentReactionKMolality apparentReactionKMolarity apparentReactionKP areSuspendedSolidHard areSuspendedSolidGritty areSuspendedSolidPulpy areSuspendedSolidSoft ashWeightFraction autoignitionT azeotropicP azeotropicT binaryDiffusionCoef biologicalConcentrationFactor bitumenSofteningPointT bitumenWeightFraction bod boilingT bromineIndex bromineNumber bunsenCoef carbonResidueWeightFraction carbonWaterPartition carbonaceousTOD cetaneIndex cetaneNumber chloridePPM cloudPointT coldFilterPluggingPointT colorNumber colorText combinedTOD componentAmountMass componentAmountMole componentAmountStandardVolume componentAmountVolume componentBunsenCoef componentCpMole componentEnthalpyMole componentEntropyMole componentFugacity componentFugacityCoef componentGibbsEnergy Using XML Schemas for Facilities Equipment, v.2.0 - 61 - 19 July, 2004

FIATECH AEX Project

componentHenryConstant componentHenryConstantMolality componentHenryConstantMolarity componentKValue componentMassFlow componentMassFraction componentMassMolarity componentMassMolality componentMassRatio componentMolality componentMolarity componentMoleFlow componentMoleFraction componentMolePerMassConcentration componentPartialP componentPartialVolumeMole componentMoleRatio componentOstwaldCoef componentRelativePartialCpMole componentRelativePartialCpMoleList componentRelativePartialEnthalpyMole componentRelativePartialEntropyMole componentRelativePartialGibbsEnergyMole componentRelativeVolatility componentRelativePartialVolumeMole compressiveYieldStrength comparativeTrackingIndex compoundTypeVolumePercent compoundTypeWeightPercent componentStandardVolumeFlow componentStandardVolumeFraction componentStandardVolumeRatio componentVolumeFlow componentVolumeFraction componentVolumeMolarity componentVolumePPM componentVolumeRatio componentWeightPercent componentWeightPPM condensingT copperCorrosion corrosiveAgent cpCv cpMass cpMole cpVolume criticalDensityMass criticalDensityMole criticalP criticalT criticalVolumeMass criticalVolumeMole criticalZ cryoscopicConstant csMass Using XML Schemas for Facilities Equipment, v.2.0 - 62 - 19 July, 2004

FIATECH AEX Project

csMole csVolume cvMass cvMole cvVolume densityMass densityMole dichromateCOD dielectricConstant dipoleMoment dissolvedSolidConcentrationMass dissolvedSolidPPM electricalDissipationPercent elementTypePercent elementWeightPercent elongationAtYieldPercent enthalpyFormationMole enthalpyMass enthalpyMole enthalpyPressureCoef enthalpyReactionMass enthalpyReactionMole enthalpyTransitionMass enthalpyTransitionMole enthalpyTransitionTriplePointMass enthalpyTransitionTriplePointMole entropyMass entropyMole eutecticT excessCpMole excessEnthalpyMole excessEntropyMoleList excessGibbsEnergyMole excessVirialCoefList excessVolumeMole fatigueStrength filterFlowT filterabilityT flashPointT flexuralModulus flexuralYieldStrength fluidity frictionCoef fugacity fugacityCoef gibbsEnergyFormationMole gibbsEnergyMass gibbsEnergyMole glassTransitionT gloss gumInFuel hasSuspendedSolid helmholzEnergyMass helmholzEnergyMole hydrateT impactEnergy Using XML Schemas for Facilities Equipment, v.2.0 - 63 - 19 July, 2004

FIATECH AEX Project

interfacialTension internalEnergyMass internalEnergyMole internalEnergyReactionMass internalEnergyReactionMole isCorrosive isFlammable isHazardous isToxic isothermalCompressibility jtCoef kinematicViscosity environmentalLeadConcentration linearMoldShrinkage linearThermalExpansionCoefList lowerConsulateT lowerFlammabilityLimit lowerFlammabilityT lubricity luminometerNumber mechanicalHardness meltingPoint microbialContamination modulusOfElasticity molecularWeight motorOctaneNumber multiphasePointP multiphasePointT octaneNumber octanolWaterPartition organicCarbonWaterPartition osmoticP ostwaldCoef osmoticPressureCoef oxidationStabilityTime p particulateVolumePercent particulateWeightPercent permanganateCOD ph phaseFractionMass phaseFractionMole phaseFractionVolume poissonRatio pourPointT pumpabilty radiusGyration reactionK refractiveIndex researchOctaneNumber saltInOilConcentration sayboltColor secondVirialAcousticCoefList secondVirialCoef sedimentVolumePercent sedimentWeightPercent Using XML Schemas for Facilities Equipment, v.2.0 - 64 - 19 July, 2004

FIATECH AEX Project

selfDiffusionCoef shearStrength softeningPointT soilWaterPartition solubilityParameter soundSpeed specificGravity surfaceTension t tensileYieldStrength thirdVirialAcousticCoef thirdVirialCoef thirdVirialInteractionCoefC112 thermalConductivity thermalDiffusivity thermalOxidationStabilityTime thermalPressureCoef toxicityConcentration traceDiffusionCoef transitionT triplePointP triplePointT ultimateTensileStrength upperConsulateT upperFlammabilityLimit upperFlammabilityT vaporP vanderwaalsAreaMole vanderwaalsVolumeMole virialInteractionCoef viscosity volumeMass volumeMole volumetricThermalExpansionCoef waterHardness waterHenryConstantMassRatio waterHenryConstantMoleRatio waterSolubilityMassRatio waterSolubilityMoleRatio watsonKFactor waxPointT Z

APPENDIX E. ABBREVIATION TABLE Abbreviation Explanation 3D three-dimensional A abstract type suffix AC alternating current API American Petroleum Institute bod biological oxygen demand CO2 carbon dioxide COD chemical oxygen demand


FIATECH AEX Project

Abbreviation Explanation coden CODEN identification for journals coef coefficient cp heat capacity at constant pressure cs heat capacity at saturation cv heat capacity at constant volume DC direct current E Enumeration Fx force in the x direction Fy force in the y direction Fz force in the z direction GUID globally unique identifier H2 hydrogen H2S hydrogen sulfide hex hexadecimal HRSG heat recovery steam generation HTML hypertext markup language ID identifier IP I (current) to P (pressure) IR infrared ISBN international standard book number ISO international standards organization ISSN international standard subscription number JT Joule-Thomson LMTD log mean temperature difference log logarithm MAWP maximum allowable working pressure max maximum min minimum MTD mean temperature difference Mx moment force in the x direction My moment force in the y direction Mz moment force in the z direction NPSH net positive suction head NPSHR net positive suction head required NRTL non-Random Two Liquid method for predicting fluid properties O2 oxygen P pressure used as a physical quantity pna Parafinic-Napthenic-Aromatic ppm parts per million PR Peng-Robinson equation of state method for predicting fluid properties QA quality assurance RPM revolutions per minute RTD resistance temperature detector SI Systemme Internationale SMILES SMILES is a way of expressing chemical formulas spec specification SRK Soave-Redlich-Kwong equation of state method for predicting fluid properties sub subordinate T temperature TEMA Thermal Equipment Manufacturer's Association


FIATECH AEX Project

Abbreviation Explanation TOD theoretical oxygen demand UMI University Microfilms Incorporated UPS uninterruptible power supply URI universal resource indicator URL universal resource locator US United States XML extensible markup language XPath XPath XPointer XPointer - a URI plus an Xpath


FIATECH AEX Project

APPENDIX F. EQUIPMENT TYPES CLASSIFICATION The FIATECH AEX Project has defined an equipment types classification to aid in segmenting the large amount of required work around the development of equipment XML schemas. One of the design principles for the capital facilities industry XML (cfiXML) schemas is to minimize the number of namespaces used. Since there are many different types of equipment, one namespace per equipment type is too many. Because of the volume of information and the many different engineering disciplines involved, having one namespace for all equipment types is too few. The purpose of defining separate namespaces is to enable people who have similar discipline and domain expertise to work together in the same namespace and to define and use terminology for that namespace without worrying about potential naming conflicts with other types of equipment outside of that namespace. It is a requirement of XML schema that terminology that is used is unique within that namespace. The purpose of setting up a comprehensive set of namespaces and an initial starter list of equipment types is threefold:

1. To enable near-term support for equipment list usage scenarios. In these scenarios the type of equipment, some unique identifier and a few key characteristics are needed to produce and use lists of individual equipment items in various applications (current AEX project focus).

2. To provide a way to organize a comprehensive multi-organization industry effort (cfiXML) for which many players will eventually participate to produce XML schemas for capital facilities, not just the FIATECH AEX project effort

3. To recognize that the eventual scope of a comprehensive capital facilities industry XML vocabulary, developed both by AEX and other related industry groups, needs to describe information about the entire capital facility, not just certain pieces and parts of the facility

A collaborative effort of DIPPR, ePlantData and FIATECH produced the core underlying XML schemas. The FIATECH AEX project produced basic schemas for all equipment types to support equipment list usage scenarios, and detailed information models for 2 equipment types – centrifugal pumps and shell and tube heat exchangers. The equipment types below were modeled to support information found on industry standard datasheets. The equipment classification described below is the AEX project’s attempt to organize equipment types into 9 namespaces and an initial starter list of 327 equipment types. The proposed nine namespaces are indicated by the headings below and the numbers of starter list equipment types in each namespace are shown as parenthetical numbers.

• Electrical (21) • Heat Exchangers (21) • Fired Equipment (6) • Instrumentation, Control Devices and Accessories (131) • Pipes, Ducts, Valves, Fittings and Internals (54) • Pressure Vessels and Internals (23) • Rotating Equipment and Accessories (40) • Storage Vessels (5) • Solids Handling (26)

In the context of the equipment namespaces above, the initial AEX project focus was for the following equipment types:

• Electrical o Motor (partial model for centrifugal pump driver support)

• Heat Exchangers o Shell and Tube Exchangers

• Rotating Equipment and Accessories Using XML Schemas for Facilities Equipment, v.2.0 - 68 - 19 July, 2004

FIATECH AEX Project

o Centrifugal Pumps o Rotating equipment common parts, e.g., bearing assemblies, shafts, seals, etc.

Additionally, as part of the AEX project, basic equipment types were identified, in name only, for all nine of the identified major namespaces to support the identified starter list of 327 equipment types across all the nine of the identified namespaces. These proposed equipment type names are listed on the following pages and in the base AEX schema namespace files. When they are fully developed and attributed, by AEX and other industry project efforts, the XML schemas for each of the 327 equipment types listed below are likely to reside in separate schema files. At present, the equipment types in separate XML schema files include centrifugal pumps, shell and tube heat exchangers, motors, and mechanical seals. The remaining equipment items are listed either in the root namespace file, or in the namespace ‘base’ file.

Electrical (21) Cable Cable tray Conduit & Fittings Circuit Breaker Generator Motor Variable Speed Drive Motor Control Center Relay panel Starter Switchgear Panel Board – instrument (DC, AC), lighting, safety Terminal (junction) box Transformer Un-interruptible Power Supply (UPS) – DC, AC, Pulse-width modulated

Heat Exchangers (21) Air cooled exchanger Air humidifier Bayonet exchanger Cooling tower Double pipe exchanger Evaporator Evaporative cooler Fan coil Graphite block exchanger Heat Recovery Steam Generation (HRSG) Hairpin exchanger Helical coil Plate fin exchanger Plate and frame exchanger Radiant convection heater Shell and tube exchanger Spiral plate exchanger Steam sparger Tank heater Tank jacket


FIATECH AEX Project

Fired Equipment (6) Boiler Waste heat boiler Flare Fired heater Incinerator (solid waste, thermal oxidizer) Rotary Kiln

Instrumentation, Control Devices and Accessories (131) Actuator (diaphragm, spring, case, piston, stem, indicator, seal, pilot valve, positioner) Alarm Analyzers (30 types: Boiling range, Carbon dioxide, Cloud point, Conductivity, Cut point, Dissolved

oxygen, Dynamic viscosity, End point, Flame detector, Flash point, Gas chromatograph, Gas detector , Gas specific gravity (centrifugal), Hydrogen sulfide – personnel, Hydrogen sulfide – process, Infrared, Ion concentration, Liquid density (vibration), Liquid density (weighing), Oxygen in gas, Pour point, Sample conditioning assembly, Sample pre-conditioning assembly, Sample take-off assembly, Smoke and dust, Smoke density, Sulfur, Trace oxygen in gas, Turbidity, Vapor pressure (kinetic), Water in gas)

Annunciator Computer Control valve Controller (flow, level, pressure, temperature) Damper Differential Pressure Indicator & Instrument Digital Controller Distributed Control System (DCS) Indicator (flow, level, pressure, temperature) Indicator-Controller (flow, level, pressure, temperature) Field Bus Recorder (flow, level, pressure, temperature) Recorder-Controller (flow, level, pressure, temperature) Switch (flow, level-displacement, level-float, limit, pressure, temperature) Transmitter (flow, level, pressure, temperature) Flow meters (coriolis, flume, integral orifice, magnetic, orifice, pitot tube, positive displacement,

rotameter, sight glass, thermal, turbine, venture, vortex, ultrasonic) Human Machine Interface (HMI) I/P Transducer Level gauge, Level servo gauge, Level glasses and cocks Level instrument (capacitance, displacement, magnetic, nuclear, radar, thermal dispersion, vibration) Machinery (axial position, vibration) Operator Interface Terminal (OIT) Pressure control valve Pressure gauge Pressure relief valve – conventional, conventional with bellow, pilot-operated Pressure vacuum relief valve Printed circuit heat exchanger Programmable Logic Controller (PLC) Rupture Disk Hand Switch Sensor Thermometer – bimetal, dial, glass Temperature indicator, instrument, instrument-filled


FIATECH AEX Project

Temperature sensor – resistance Thermocouple Thermostatic expansion device Thermowell Temperature regulator – self-actuated Weight – Load cell Weighing system Solenoid valve Traps and drainers Visual Display Unit (VDU) Variable Air Volume (VAV) Box

Pipes, Ducts, Valves, Fittings, and Internals (54) Air terminal Bushing Cap Casing Cross Duct Ejector Elbow Expansion joint Extension Fitting Flame arrestor Flange Increaser Insert Isolating joint Lateral Lock nut Pig trap Pipe – rigid, flexible, transmission Plug Reducer Return Restriction orifice union Spring can Spring hanger Static mixer Stub End Tee Trap Union Valve (Ball, Butterfly, Check, Diaphragm, Eccentric Disk, Four-way, Gate, Globe, Flapper, Multiple Orifice, Needle, Plug, Shuttle, Slide, Three-way) Valve Body Valve Packing Valve Seal Valve Seat Ring Waste nut Wye


FIATECH AEX Project

Pressure Vessels & Internals (23) Coalescer Pressure vessel – cylindrical, spherical, spheroidal Deaerator Demister pad Distributor Mist eliminator Separation packing stack Separation tower Separation tray stack Separation tray support Spray nozzle Support grid Tray – bubble-cap, chimney, draw-off, jet, sieve, valve, separation

Rotating Equipment and Accessories (40) Air intake Agitator Axial compressor Bearing – Radial, Thrust Centrifugal compressor Centrifugal pump Controlled volume pump Coupling Cylinder Exhaust Fan Fluid Reservoir Fuel Filter Fuel Injector Gas engine Gas turbine Gear Gear pump Hydroturbine Impeller Mechanical seal Mixer Piston Reciprocating compressor Reciprocating pump Rotary blower Rotary compressor Rotary pump Screw compressor Scroll Compressor Silencer Starter Steam Turbine – aeroderivative, industrial Turbocharger Turboexpander – axial, centrifugal Vacuum pump


FIATECH AEX Project


Storage Vessels (5) Atmospheric storage tank Bin Silo Sump Tote

Solids Handling (26) Air Filter Bag dust collector Bag filter Ceramic tube filters Conveyor – belt, vibrating, screw Cyclone Dryer – rotary, tray, vacuum pan Electrostatic precipitator Extruder Filter press Hydrocyclone Gravity filter Leaf filter Mill – ball, cage, hammer Rotary drum filter Rotary valve Solid packaging unit Strainer Strainer filters Weighing equipment

QUESTIONS AND FEEDBACK If you have questions or wish to offer constructive feedback to improve the capital facilities industry XML, please contact:

T. L. (Tom) Teague ePlantData, Inc. 5116 Bissonnet #460 Bellaire, TX 77401-4007 USA Tel: +1-713-728-9140 Fax: +1-713-728-1371 Email: [email protected]

mailto:[email protected]

using_xml

Documents

equipment datasheets

equipment documents

various equipment

equipment item data

life of engineered equipment

basic equipment information

common types of equipment

fiatech aex project