Using XML

ELEMENT 3
PROCUREMENT
USING XML SCHMAS FOR FACILITIES EQUIPMENT
W W W. FIATECH .ORG
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. 2. 3. 4. Basic equipment information found on various equipment lists and bill of materials documents. Equipment datasheets for centrifugal pumps and shell and tube exchangers (which include process material properties) Process materials, associated properties, calculation methods and experimental property data 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. 2. 3. 4. 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), Core engineering object schemas for reusable, base engineering objects that can be used by multiple engineering disciplines and subject domains Subject engineering object schemas that provide schemas related to specific equipment items 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 usersupplied extensions to the schema.
Using the cfiXML Schemas
-2-
19 July, 2004
FIATECH AEX Project
REVISION HISTORY
Release 1.0 1.1 1.2 1.3 1.4 1.5 2.0 Date 18 Sept 02 4 Nov 02 26 Nov 02 13 Dec 02 28 April 03 21 June 2004 19 July 2004 Notes Initial release for industry review and comment. 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. Revised to include additional industry comments during November Updated equipment types list Revised to include additional industry feedback and schema evolution from November Revised to include results from the AEX Testbed evaluation and expanded to illustrate how to use and extend the schemas in practical software implementations. First Public release for industry software implementation
-3-
19 July, 2004
FIATECH AEX Project
TABLE OF CONTENTS
EXECUTIVE SUMMARY REVISION HISTORY TABLE OF CONTENTS READERS ORIENTATION TO THIS DOCUMENT COPYRIGHT AND LICENSE NOTICE 1.
1.1 1.2 1.3 1.4
1 3 4 5 5 6
6 7 7 12
BUSINESS USAGE CONTEXT

Business Motivation Major Usage Scenarios Software Usage and Transaction Survey Candidate Software Packages
2.
2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15
SCHEMA INTRODUCTION
XML Usage Scenario Messaging and File Exchange Schema Scope Schema Structural Overview Namespaces Overview Core Data Types Overview Core Objects Overview Subject Schemas Overview Equipment Types Classification Container-Collector Overview Messaging and Business Protocol Containers Naming and Sequence/Choice Ordering Conventions Object Management Schema Extensibility Schema Object Library Namespace and File Folder Organization
13
14 14 14 15 17 18 19 20 21 21 21 22 23 23 24
3.
3.1 3.2 3.3 3.4 3.5 3.6
SCHEMA OVERVIEWS
Extended Data Types (ext: namespace) Physical Quantities (pq: namespace) Engineering Type Library (etl: namespace) Objects (obj: namespace) Context and Projects (ctx: and proj: namespaces) Documents (dx: namespace)
26
26 27 28 29 29 30
-4-
19 July, 2004
FIATECH AEX Project
3.7 3.8 3.9 3.10 3.11 3.12
Equipment (eq: namespace) Materials and Properties (mtrl: namespace) Unit Operations (uo: namespace) Site (site: namespace) Rotating Equipment (eqRot: and eqRotDoc: namespaces) Heat Exchange Equipment (eqHx: and eqHxDoc: namespaces)
32 33 34 34 35 37
4. 5.
5.1 5.2
GETTING STARTED WITH CFIXML PUMP TUTORIAL USING AND EXTENDING THE SCHEMAS
Part 1 Using the existing schemas Part 2 Extending/Customizing the schemas
39 40
41 44
APPENDIX A. UML NOTATION REFERENCE APPENDIX B. DATA TYPES (EXT: NAMESPACE) APPENDIX C. PHYSICAL QUANTITIES (PQ: NAMESPACE) APPENDIX D. MATERIAL PROPERTIES (MTRL: NAMESPACE) APPENDIX E. ABBREVIATION TABLE APPENDIX F. EQUIPMENT TYPES CLASSIFICATION QUESTIONS AND FEEDBACK
48 49 51 60 65 68 73
READERS 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
-5-
19 July, 2004
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
-6-
19 July, 2004
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 o To/from scientific journals and experimental databases and analysis tools 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 o o Property tables and curves Process simulation stream tables 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
-7-
19 July, 2004
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
Lab Data Reporting System
Regressed Parameters Database
Process / Equipment Simulator
Properties Table
Method Parameters
Properties Simulator
Process Simulation
Paper Publications
Data Capture Software
Properties Table
Data Evaluation/ Regression Software
Published Experimental Database
Properties Table
Datasheet Software
Evaluated Experimental Database
Legend Electronic Document

Software System
Note: Heavy weighted lines indicate initial opportunity areas
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. Using the cfiXML Schemas
-819 July, 2004
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.
-9-
19 July, 2004
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 Suppliers Order Entry and Tracking system. The Supplier engineer enters data from the buyer Equipment Datasheet into the suppliers 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.
- 10 -
19 July, 2004
Software and Information Flows

EPC
Process Simulator Equipment Design Intelligent 2D Drawing Software Intelligent Drawings Email / Collaboration / Data Warehouse Accounts Payable/ Receivable Intelligent 3D CAD System
Owner
Document Management Maintenance Management ERP - Asset Management Plant Performance Owner Data Warehouse
Process Simulation
Equipment Design Equipment Datasheet
EPC EPC
Equipment List Software
Equipment List & Equipment Status
Datasheet Software
Bid Tabulation Software Cost Estimating Email / eMarketplace/ Collaboration Procurement System Planning, Scheduling & Tracking Construction Site Asset Management
Procurement System
Supplier
RFQ with Datasheet Quote with Datasheet Purchase Order with Datasheet As Built BOM Datasheet & Parts List Equipment Status Update Accounts Receivable
Email / eMarketplace/ Collaboration
Legend
Electronic Document Software System
Order Entry, Material Tracking and Datasheet *
Bolded lines and symbols indicate opportunity areas
- 11 -
19 July, 2004
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 datarich 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.
- 13 -
19 July, 2004
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 filebased 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 messagingbased 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. 2. 3. 4. Basic equipment information found on various equipment lists and bill of materials documents Equipment datasheets for centrifugal pumps and shell and tube exchangers (which include process material properties) Process materials, associated properties, calculation methods and experimental property data 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 costeffective. 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), Core engineering object schemas for reusable base engineering objects that can be used by multiple engineering disciplines and subject domains Subject engineering object schemas that provide schemas related to specific equipment items
2. 3.
- 14 -
19 July, 2004
FIATECH AEX Project 4. Collection-container schemas that are used to model engineering document schemas. The collectioncontainer schemas allow core and subject-specific engineering objects to be combined in various ways to support various data transactions and usage scenarios.
Example
Namespaces
XML Schema xsd: XML Schema Definition Core Data Type Schemas ext: extended base data types pq: physical quantities obj:BaseObject etl: engineering type library
XML Schema
xsd:double
cfiXML
Core Data Types
ext:Double
pq:Weight Mass
eq:weight/ value
obj:Object
eq:FacilityItem
Core Engineering Object Schemas
eq:EquipmentItem
Core Engineering Object Schemas obj: base objects ctx: context - organization, location, etc. dx: document eq: equipment mtrl: material properties proj: project information site: site information uo: unit operations Subject Engineering Object Schemas eqHx: heat exchanger equipment eqRot: rotating equipment eq ---: other types - see namespaces thmo: thermo extensions to mtrl properties Collection-container Schemas eqHxDoc: eng datasheets - S&T heat exch eqRotDoc: eng datasheets - centrif pump
Subject-specific Engineering Object Schemas
eqRot:RotatingEquipment
eqRot:CentrifugalPump
Collection-container Schemas (e.g., documents that contain engineering objects)
eqRotDoc: CentrifugalPumpDataSheet
Messaging Protocol Container
OAGIS, UBL, RosettaNet, etc
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.
- 15 -
19 July, 2004
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.
- 16 -
19 July, 2004
FIATECH AEX Project

xsd: XML Schema
Core Data Type Schemas
ext: Extended Datatypes

etl: Engineering Type Library, geometric shapes, electrical types
pq: Physical Quantities
Core Object Schemas

ctx: Context info: Organization, Person, Location, etc.
obj: Base objects

dx: Basic document information
proj: Project information
eq: Equipment items
mtrl: Basic material properties
uo: Unit operation (equip performance)
site: Site Information
Subject Schemas
eqElec: electrical
eqFire: fired equipment
eqRot: rotating equipment and accessories

eqSld: solids handling
eqStg: storage vessels
eqHx: heat exchange equipment

eqInst: instrumentation, control devices and accessories
eqVesl: pressure vessels & internals
eqPvf: pipes, ducts valves, fittings and internals
thmo: Extended mtrl properties
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 domainindependent 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
Using XML Schemas for Facilities Equipment, v.2.0 - 17 19 July, 2004
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

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
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:
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
- 18 -
19 July, 2004
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.
- 19 -
19 July, 2004
FIATECH AEX Project
CentrifugalPump (eqRot)
EquipmentItem (eq) FacilityItem (eq)
RotatingEquipment (eqRot)
Object (obj)
Figure 3. Inheritance/Extension mechanism illustrated conceptually for a centrifugal pump
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
327 types total
Heat Exchangers
21 types
Rotating Equipment & Accessories

40 types
Storage Vessels
5 types
Pipes, Ducts, Valves, Fittings & Internals

54 types
Electrical
21 types
Fired Equipment
6 types
Pressure Vessels & Internals

23 types
Solids Handling
26 types
Instrumentation, Control Devices & Accessories

131 types
Figure 4. Equipment Types Classification
- 20 -
19 July, 2004
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 PFDs, P&IDs, 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. 2. 3. Use alphabetical ordering as the default way to order elements in a sequence or choice list. 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. 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 userUsing 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 organizations 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. 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. 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 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.
2. 3. 4.
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 IDs, 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.
- 24 -
19 July, 2004
FIATECH AEX Project
Figure 5. Capital facilities industry XML Object Library

obj: BaseObject
obj:Object
ctx: Organization
ctx: SubOrganization
obj: TextObject
eq: FacilityItem
eq: BulkItem
eq: PipingComponent
eq: Flange
mtrl: Material
mtrl: MaterialComponent
mtrl: Material ComponentList
mtrl: MaterialComposition
uo: ProcessDefinition
uo: UnitOperation
uo: PressureChange UnitOperation uo: FluidTransfer UnitOperation uo: PumpUnit Operation
uo: HeatExchanger UnitOperation uo: ShellTubeHeat ExchangerUnitOperation
dx: TextDocument
ctx: Location
ctx: GeographicArea
ctx: LocationAnd GeographicArea
dx: HTMLDocument
dx: Citation
thmo: ExtendedCitation
eq: FabricatedItem
eq: FabricatedNozzle
mtrl: Reaction
ctx: Person
proj: Project
proj: Activity
dx: ProjectDocument
dx: OrganizationDocument
eq: EquipmentItem
eqRot: RotatingEquipment
eqRot: CentrifugalPump
eqElec: Motor
eqRot: Baseplate
eqRot: Casing
eqRot: Coupling
mtrl: MaterialProperty
mtrl: Property
dx: DatasheetA
dxDsCpmp:Centrifugal PumpDataSheet
dxDsSt: ShellTube ExchangerDataSheet
thmo: Property DataTable

thmo: Method
thmo: Method ParameterSet
thmo: MtrlSample
thmo: PureSample
etl: ElectricalArea Classification

etl: ElectricalSupply Characteristic
uo: Stream
uo: MaterialStream
uo: EnergyStream
uo: UtilityStream
site: SiteFacility
etl: Shape
etl: RectangularShape
etl: CylindricalShape
etl: Coordinate
site: SiteSubArea
site: FacilitySystem
site: EquipmentSet
site: EnvironmentalData
eq: PipeSpec
eqRot: Gear
eqRot: Impeller
thmo: MixtureSample
eqRot: MechanicalSeal
eqRot: Packing
eq: PipingConnection
eq: EquipmentConnection
eqHx: ExchangerNozzle
eq: Shaft
Legend
ns: CoreSchemaObjName
eq: UtilityService
eq: MaterialUtilityService
eq: BearingAssembly
eqHx: HeatExchanger
eqHx: ShellTube HeatExchangerUnit
ns: SubjectSchemaObjName
Note: ns = namespace identifier
eq: Electrical UtilityService

- 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 comment commentReference changed Type xsd:string ext:ID xsd:boolean Description Comments or annotation on an individual data item. These comments are version independent and may have additional comments appended. A reference to a text object that contains a comment. This enables a comment to be reused among many data elements. 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:
- 26 -
19 July, 2004
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:Weight Mass
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"/>
- 27 -
19 July, 2004
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
CylindricalShape
RectangularShape
ElectricalAreaClassification
GeographicAngle
Coordinate
ElectricalSupplyCharacteristic
NormalFlowDirection
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.
- 28 -
19 July, 2004
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
copiedObject
Object
ctx: Person
Transaction
TextObject
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 implementers 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
obj: Object
0..n
proj:Project
0..n
contact
ctx:Person
ctx:Location
proj:Activity
ctx:Organization
facilityLocation
ctx:LocationAndGeographicArea
ctx:GeographicArea
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 organizations 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 organizations 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.
- 30 -
19 July, 2004
FIATECH AEX Project
obj: Object
obj:TextObject
HTMLDocument
TextDocument
copyrightOwner
ctx:Person
ctx:Organization
OrganizationDocument
OrganizationDocumentLibrary
ctx:Organization
ctx:Project
ProjectDocument
ProjectDocumentLibrary
DataSheetA
eqDoc: DataSheetLibrary
DataSheetHeader
site: Site
obj: BaseObj
eqDoc: EquipmentItem DataSheet
Citation
eq: EquipmentItem
CitationLibrary
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
- 31 -
19 July, 2004
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
ctx: Organization
supplier Company
fabricator Company
UtilityServiceA
FacilityItemA
MaterialUtilityService
EquipmentItem
construction Material
mtrl: Material
FabricatedItem
FabricatedNozzle
ElectricalUtilityService
BulkItem
PipingConnection
endDescription
mechanicalConnection
BearingAssembly
Bearing
Shaft
PipingComponent
EquipmentConnection
Flange
Elbow
Pipe
FittingEnd
threadedConnection
flangedConnection
weldedConnection
Reducer
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.
- 32 -
19 July, 2004
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:BaseObject
MaterialComponentLibrary
MaterialComponent
obj:Object
0 .. n
MaterialComponentList
MaterialProperty
0 .. n 0 .. n
Phase
Reaction
MaterialLibrary
Material
MaterialComposition
0 .. n
property
context
> 280 properties
phaseReference
fixedProperty
standardState
standardCondition
referenceCondition
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
UnitOperation
ProcessDefinition
ProcessPort
Stream
PressureChange UnitOperation FluidTransferUnitOperation
HeatExchanger
MaterialStream MaterialUtilityStream
EnergyStream EnergyUtilityStream
ShellTubeExchanger UnitOperation HeatExchangerSide
PumpUnitOperation
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.
- 34 -
19 July, 2004
FIATECH AEX Project

obj: Object
eq: electricalUtilityServiceProvided
eq: materialUtilityServiceProvided
SiteFacility
ctx: Organization
ownerOrganization
SiteSubArea
EnvironmentalData
etl: ElectricalAreaClassification
ctx: LocationAndGeographicArea
FacilitySystem
EquipmentSet
EquipmentConfiguration
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.

obj:BaseObject
obj:Object
dx:DataSheetA
eq:FacilityItemA
eq:EquipmentItem
uo: UnitOperation
eqrot:RotatingEquip
Driver
eq: Equipment Connection
uo: PressureChange Unit Operation
eqRot: Baseplate
eqElec: Motor
eqRot: Turbine
eqRot: Engine
eq: BearingAssembly
eqRot: Coupling
uo: FluidTransfer UnitOperation

uo: Stream
eqRot: Gear
eqRot: MechanicalSeal
eqRot: Packing
uo: PumpUnit Operation
uo:ProcessPort
eq: Shaft
uo: Material Stream
eqrot:CentrifugalPump
eqRot: Casing
eqRot: Impeller
eqRotDoc: DataSheetCentrifugalPump
site:SiteFacility
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.
- 37 -
19 July, 2004
FIATECH AEX Project

obj:Object
eq:FacilityItemA eq:EquipmentItem uo:UnitOperation uo:HeatExhangerUnitOperation uo: ShellTubeExchangerUnitOperation eqHx:ShellTubeExchangerUnit eqHx:exchangerDesign eqHx: shellTubeExchangerAssembly eqHx:bundle eqHx:end eqHx:performance eqHx:shell eqHx:reboilerPiping eqHx:ExchangerNozzle dx:DataSheetA eq:EquipmentConnection eqHx:Tube uo:ProcessPort uo: HeatExchangerSide uo: MaterialStream uo: Stream
eqHx:HeatExchangerEquipment
eqHxDoc: ShellTubeExchangerDataSheet
site:SiteFacility
thmo:PropertyDataTable
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
- 38 -
19 July, 2004
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 wont 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. 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. Understand how the information is stored in your own application and what programming interfaces are required to get and put information into application storage. 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. 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.
2.
3. 4.
5.
- 39 -
19 July, 2004
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 goby 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. b. Using the built-in schema for values we know and are already in the schema Using Units of Measurement
Part 2 Extending/customizing the schemas (optional, only if you have the interest) a. b. c. Extending the schema for values that are not in the schema using the custom extension mechanism that accommodates any elements. Extending the schema with user-supplied enhancement schemas 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.
- 40 -
19 July, 2004
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 Ive 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
FIATECH AEX Project 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 dont immediately find the information element youre 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. Lets 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/XMLSchemainstance" 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>
5.
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. 2. a Data Sheet is an arbitrary container document for other objects some from site description date and some from rotating equipment, and 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/XMLSchemaUsing 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/cfixmlorg/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.
- 44 -
19 July, 2004
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 XMLs 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/XMLSchemainstance" 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">
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.
- 47 -
19 July, 2004
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
A
Indicates uses relationship; B uses A
A
Indicates contains relationship; A contains B
B
A
Indicates may contain or reference relationship; A may contain B, A may contain a reference to B
- 48 -
19 July, 2004
FIATECH AEX Project
APPENDIX B. DATA TYPES (EXT: NAMESPACE)

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

Name Acceleration Angle Description Acceleration. (length/time squared) Plane angle. Units ft/s2 m/s2 deg min_angle s_angle rad sr kg.m2/s lb.ft2/s deg/s rad/min rad/s rev/min rev/s
AngleSolid AngularMomentum AngularVelocity
Solid Angle. Angular momentum. (mass x velocity x length) Angular velocity. (angle/time)
Any Area
AreaMole
Brightness ConcentrationMass ConcentrationMole CpMass
CpMole
CpVolume
DensityLength
acre ft2 ha in2 m2 mile2 yd2 Molar specific area. (area/mole) ft2/lbmol in2/lbmol m2/gmol m2/mol m2/kmol Luminous intensity cd cp Concentration. (mass/volume) see DensMass Molar concentration. (quantity/volume) see DensMole 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 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 Heat capacity, volume basis. (heat/(volume x temperature Btu/ft3.degF interval)) J/m3.K kcal/m3.K kJ/m3.degC Linear density or mass per unit length. (mass/length) kg/m lb/ft
- 51 19 July, 2004
Any Engineering Variable - Scalar Area. (length squared)
FIATECH AEX Project
Name
Description
DensityMass
Density. (mass/volume)
DensityMole
Molar Density. (mole/volume)
DensityVelocitySquared Diffusivity ElectricalCapacitance ElectricalCharge ElectricalChargeMoment ElectricalCurrent ElectricalEnergy ElectricalPower Energy
Density velocity squared or RhoV (density x velocity) Diffusivity. Equivalent to kinematic viscosity - viscKin. (area/time) Electric capacitance (charge/voltage) Electric charge Electric charge moment Electric current Electrical energy. Electrical power associated with electrical equipment. Energy - work, heat, etc.
Units lb/in lb/mile lb/yd 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 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 see P see ViscKin C/V F A.s C C.m A.s.m A see Energy see Power Btu cal cal_15 cal_th ft.lbf ft.pdl hp.h J kgf.m kJ
19 July, 2004
- 52 -
FIATECH AEX Project
Name
Description
EnergyMass
Mass Specific Energy. (energy or heat/mass)
EnergyMole
Molar specific energy. (energy/quantity)
EnergyPressureCoef
Energy pressure coefficient (energy/pressure)
EnergyVolume EntropyMass EntropyMole FlowMass
Energy content, volume basis or calorific value. (heat/volume) Specific entropy. (heat/(mass x thermodynamic temperature)) Molar specific entropy. (heat/(quantity x thermodynamic temperature)) Mass rate of flow. (mass/time)
Units kW.h lbf.ft lbf.in MJ N.m ozf.in pdl.ft tonf.ft W.s Btu/lb ft.lbf/lb J/kg kcal/kg kgf.m/kg kJ/kg Btu/lbmol ft.lbf/lbmol J/kmol J/gmol J/mol kcal/kmol kgf.m/kmol kJ/kmol Btu/psi ft.lbf/psi J/Pa J/kPa kcal/kPa kgf.m/kPa kJ/kPa see P see CpMass see CpMole kg/h kg/s lb/h lb/s ton/h kmol/h kmol/s lbmol/h lbmol/s mol/s gmol/s see FlowVol ft3/h ft3/min ft3/s l/h l/min l/s
19 July, 2004
FlowMole
Molar flow rate. (quantity/time)
FlowStandardVolume FlowVolume
Standard volume rate of flow. (volume/time) Volume rate of flow. (volume/time)
- 53 -
FIATECH AEX Project
Name
Fluidity
Force
FoulingRes
Frequency HenryConstantMolality HenryConstantMolarity Heat HeatFlow HeatFlux
HeatReleaseRate
HeatTransferCoef
JTCoef
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, reciprocal dynamic viscosity. (velocity per_cP gradient/stress) m2/kgf.s ft2/lbf.h ft2/lbf.s per_Pa.s ft2_pdl.s Force. (mass x acceleration) dyn kgf lbf N ozf pdl tonf 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. (number/time) Hz Henry's law constant - Molality. (pressure x molar density) Pa.kg/kmol kPa.kg/kmol psi.lb/lbmol Henry's law constant - Molarity. (pressure x molar volume) Pa.m3/kmol kPa.l/kmol Heat energy. see Energy Heat flow rate such as boiler power. see Power Heat flux density. (heat/(area x time)) Btu/ft2.h cal/cm2.s kcal/m2.h kW/m2 W/in2 W/m2 Heat release rate. (heat/(volume x time)) Btu/ft3.h cal/cm3.s kcal/m3.h kW/m3 W/m3 Heat transfer coefficient or thermal conductance. (heat/(area Btu/ft2.h.degF x time x temp. difference) cal/cm2.s.K kcal/m2.h.K kW/m2.K W/m2.K Joule-Thomson coefficient. (temperature/pressure) K/Pa K/kPa degC/kPa
- 54 19 July, 2004
Description
FIATECH AEX Project
Name
LargeLength Length
LengthReciprocal
Mass
MassPerArea
MassTransferCoef MassVelocity MechanicalPower ModulusOfElasticity Mole
Units decC/bar degF/psi degR/psi Large distances as measured in km or miles. see Len Length angstrom cm fathom ft in km m micro_m mil mile mm n_mile thou yd Reciprocal Length per_cm per_ft per_in per_m per_micro_m per_mil per_mm Mass cwt g kg lb metric_carat mg micro_g oz shcwt shton slug stone t ton u Mass per unit area. (mass/length squared) kg/ha kg/m2 lb/thousand_ft2 lb/acre oz/ft2 oz/yd2 ton/mile2 Mass transfer coefficient (mole/time.area)/(mole/volume) mol/s.m2/mol/m3 Mass velocity (mass/(area x time)) kg/s.m2 lb/h.ft2 Mechanical power associated with mechanical equipment. see Power Modulus of elasticity. (force/area) see P Mole or quantity of a substance. gmol kmol
- 55 19 July, 2004
Description
FIATECH AEX Project
Name MolecularWeight
Description Molecular weight (mass/quantity)
MolecularWeightReciprocal
Reciprocal molecular weight (quantity/mass)
MomentInertia
Moment of inertia. (mass x length squared)
MomentOfForce Momentum NauticalLength P
Moment of force, or torque. (force x length) Momentum, linear. (mass x velocity) Nautical distances as used at sea. Pressure (force/area)
PDifference
Pressure difference or interval. (force/area)
Units lbmol mol kg/kmol g/gmol g/mol lb/lbmol u gmol/g mol/g kmol/kg lbmol/lb kg.m2 lb.ft2 lb.in2 oz.in2 see Energy g.cm/s kg.m/s lb.ft/s see Len 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 atmDiff barDiff ftH2ODiff hbarDiff inH2ODiff
19 July, 2004
- 56 -
FIATECH AEX Project
Name
Description
PressureDropGradient Power
Pressure drop per length ((force/area)/length) Power. (energy/time)
PReciprocal
Reciprocal Pressure (area/force)
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 bar/m Pa/m psi/ft Btu/h cal/s ft.lbf/s GW hp kcal/h kgf.m/s kV.A kW MW V.A W 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
19 July, 2004
- 57 -
FIATECH AEX Project
Name
Description
SmallLength SolubilityParameter Stress SurfaceMass
Small length such as measured in mm or inches. Solubility parameter Stress. (force/area) Specific surface or area per unit mass. (length squared/mass)
SurfaceTension T
Force per unit length or surface tension. (force/length) Temperature - absolute.
TemperatureDifference
Temperature - difference or interval.
ThermalConductivity
Thermal conductivity. (heat x length/(area x time x temperature difference))
ThermalDiffusivity ThermalExpansion ThermalExpansionVolume ThermalP
Thermal diffusivity. Equivalent to kinematic viscosity viscKin. (area/time) Thermal expansion, linear
Units per_psi litre/th UK_gal/therm ft2/tonf in2/tonf per_torr see Len Pa1/2 see P acre/lb cm2/mg ft2/oz ha/kg kft2/lb m2/g m2/kg mm2/mg yd2/oz dyn/cm N/m degC degF degR K degCDiff degFDiff degRDiff KDiff Btu.in/ft2.h.degF Btu/ft.h.degF cal/cm.s.K kcal/m.h.K kW/m.degC W/m.K see ViscKin
ThermalResistivity
in/degF m/degC m/K Thermal expansion, volume in3/degF m3/degC m3/K Thermal pressure. (pressure/temperature) Pa/K kPa/K kPa/degC bar/degC psi/degF psi/degR Thermal resistivity. (area x time x temp. difference/(heat x cm.s.K/cal length)) ft.h.degF/Btu ft2.h.degF/Btu.in m.degC/kW m.h.K/kcal m.K/W
- 58 19 July, 2004
FIATECH AEX Project
Name Time
Description Time.
Torque TReciprocal
Torque or moment of force. (force x length) Reciprocal temperature
Velocity
Linear velocity or speed. (length/time)
VerySmallLength Viscosity
Very small length such as measured in m or mil. Viscosity, dynamic. (stress/velocity gradient)
KinematicViscosity
Viscosity, kinematic. (length squared/time)
Volume
Volume. (length cubed)
VolumeSquaredMoleSquared Molar specific volume squared. (volume2/mass2)
Units d h min s week see Energy per_degC per_degF per_degR per_K ft/min ft/s in/s km/h kn m/s mile/h see Len cP kgf.s/m2 lbf.h/ft2 lbf.s/ft2 Pa.s pdl.s/ft2 cSt ft2/h ft2/s in2/h in2/s m2/h m2/s 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 ft6/lbmol2 in6/lbmol2 l2/gmol2 l2/mol2 l2/kmol2
19 July, 2004
- 59 -
FIATECH AEX Project
Name
Description
VolumeMass
Specific volume. (volume/mass)
VolumeMole
Molar specific volume. (volume/mole)
Voltage
Voltage or electric potential (energy/time.elecCurrent)
WaveLength WeightForce WeightMass Work
Wavelength measured in Angstroms. Weight (force) Weight (mass) Work energy.
Units m6/gmol2 m6/mol2 m6/kmol2 ft3/lb ft3/ton in3/lb l/kg m3/kg UK_gal/lb ft3/lbmol in3/lbmol l/gmol l/mol l/kmol m3/gmol m3/mol m3/kmol UK_gal/lbmol US_gal/lbmol kV micro_V mV MV V see Len see Force see Mass 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
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 componentRelativePartialGibbsEnergyMol e 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
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
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
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 3D A AC API bod CO2 COD Explanation three-dimensional abstract type suffix alternating current American Petroleum Institute biological oxygen demand carbon dioxide chemical oxygen demand
- 65 19 July, 2004
FIATECH AEX Project Abbreviation coden coef cp cs cv DC E Fx Fy Fz GUID H2 H2S hex HRSG HTML ID IP IR ISBN ISO ISSN JT LMTD log MAWP max min MTD Mx My Mz NPSH NPSHR NRTL O2 P pna ppm PR QA RPM RTD SI SMILES spec SRK sub T TEMA
Explanation CODEN identification for journals coefficient heat capacity at constant pressure heat capacity at saturation heat capacity at constant volume direct current Enumeration force in the x direction force in the y direction force in the z direction globally unique identifier hydrogen hydrogen sulfide hexadecimal heat recovery steam generation hypertext markup language identifier I (current) to P (pressure) infrared international standard book number international standards organization international standard subscription number Joule-Thomson log mean temperature difference logarithm maximum allowable working pressure maximum minimum mean temperature difference moment force in the x direction moment force in the y direction moment force in the z direction net positive suction head net positive suction head required non-Random Two Liquid method for predicting fluid properties oxygen pressure used as a physical quantity Parafinic-Napthenic-Aromatic parts per million Peng-Robinson equation of state method for predicting fluid properties quality assurance revolutions per minute resistance temperature detector Systemme Internationale SMILES is a way of expressing chemical formulas specification Soave-Redlich-Kwong equation of state method for predicting fluid properties subordinate temperature Thermal Equipment Manufacturer's Association
- 66 19 July, 2004
FIATECH AEX Project Abbreviation TOD UMI UPS URI URL US XML XPath XPointer
Explanation theoretical oxygen demand University Microfilms Incorporated uninterruptible power supply universal resource indicator universal resource locator United States extensible markup language XPath XPointer - a URI plus an Xpath
- 67 -
19 July, 2004
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). 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 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
2.
3.
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 projects 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
- 68 19 July, 2004
FIATECH AEX Project Centrifugal Pumps Rotating equipment common parts, e.g., bearing assemblies, shafts, seals, etc.
o o
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
- 69 -
19 July, 2004
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
- 71 -
19 July, 2004
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
- 72 -
19 July, 2004
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: teague@eplantdata.com
- 73 -
19 July, 2004

Using XML

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Using XML

Загружено:

Авторское право:

Доступные форматы

ELEMENT 3

USING XML SCHMAS FOR FACILITIES EQUIPMENT

AEX PROJECT USING XML SCHEMAS FOR FACILITIES EQUIPMENT

Using XML Schemas for Facilities Equipment, v.2.0

Using the cfiXML Schemas

FIATECH AEX Project

Using the cfiXML Schemas

FIATECH AEX Project

BUSINESS USAGE CONTEXT

Using the cfiXML Schemas

FIATECH AEX Project

3.7 3.8 3.9 3.10 3.11 3.12

READERS ORIENTATION TO THIS DOCUMENT

COPYRIGHT AND LICENSE NOTICE

Using the cfiXML Schemas

BUSINESS USAGE CONTEXT

Using the cfiXML Schemas

Major Usage Scenarios

Software Usage and Transaction Survey

Using the cfiXML Schemas

Material Properties Software and Data Flow Description

Lab Data Reporting System

Regressed Parameters Database

Process / Equipment Simulator

Data Capture Software

Published Experimental Database

Evaluated Experimental Database

Legend Electronic Document

Note: Heavy weighted lines indicate initial opportunity areas

Equipment Life Cycle Software Data Flow Description

Using the cfiXML Schemas

Using the cfiXML Schemas

Software and Information Flows

Equipment Design Equipment Datasheet

Equipment List & Equipment Status

Email / eMarketplace/ Collaboration

Order Entry, Material Tracking and Datasheet *

Bolded lines and symbols indicate opportunity areas

Using XML Schemas for Facilities Equipment, v.2.0

FIATECH AEX Project

Candidate Software Packages

Using XML Schemas for Facilities Equipment, v.2.0

FIATECH AEX Project

XML Usage Scenario Messaging and File Exchange

Schema Structural Overview

Using XML Schemas for Facilities Equipment, v.2.0

Core Engineering Object Schemas

Subject-specific Engineering Object Schemas

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

OAGIS, UBL, RosettaNet, etc

Using XML Schemas for Facilities Equipment, v.2.0

Using XML Schemas for Facilities Equipment, v.2.0

FIATECH AEX Project

Core Data Type Schemas

ext: Extended Datatypes

pq: Physical Quantities

Core Object Schemas

obj: Base objects

proj: Project information

eq: Equipment items

mtrl: Basic material properties

uo: Unit operation (equip performance)