CFIHOS March

C-GD-003 2022

CFIHOS RDL Development Guide

Version Date Comments/History

V01 Initial revision with Chevron content, titled “Chevron Approach to RDL
Alignment”
• Principles section
• Guidelines section
V02 BP modifications:
• Added Tagging criteria section
• Updates to Principles and Guidelines section
• Renamed to “BP Approach to RDL Alignment”
V03 Shell modifications
• Added Background section
• Added CFIHOS Submission section
• Added Assessment Criteria section
• Consolidated Guidelines section into Principles.
• Updated Principles section to expand on the definition of the
principles and provide examples
• Updated Tagging Criteria section to compare criteria from BP,
Chevron, and Shell
• Renamed to “Consolidated Approach to CFIHOS RDL Alignment”
V04 Modifications to clarify functional/physical classification of equipment
• Added Definitions section
• Added Revision History section
• Clarifications added for approach to functional and physical classes
• Example classes updated to align with approach to functional and
physical classes
V05 Add description of difference between Tag (Functional) and Equipment
(Physical) Classes.
V06 Include rule changes agreed upon TOTAL joining group.

V07 • Merger of existing ‘Consolidated Approach to CFIHOS RDL Alignment’

and ‘CFIHOS Properties Rules’
• Incorporate comments from review by expanded CFIHOS RDL Working
Group
CFIHOS RDL Development Guide ````cx

Acknowledgements
In 2012, Shell approached Netherlands-based process industry organization USPI to
explore turning their corporate information standard into an industry-wide standard. The
result was the CFIHOS (Capital Facilities Information Handover Specification) project.
Its aim is to offer practical, standardized specifications for information handover that work
across the supply chain – operators, contractors and suppliers. The most recent CFIHOS
industry standard (Version 1.4) was published in October 2019 by USPI with support from
the Engineering Advancement Association of Japan (ENAA). This document, describing the
scope and procedures of CFIHOS, is part of this standard.
Following a member vote in 2019, the future governance, development, and maintenance
of the CFIHOS project and standard moved from USPI to IOGP in January 2020, becoming
Joint Industry Project (JIP)36.

Disclaimer
Whilst every effort has been made to ensure the accuracy of the information
contained in this publication, neither IOGP nor any of its Members past present or
future warrants its accuracy or will, regardless of its or their negligence, assume
liability for any foreseeable or unforeseeable use made thereof, which liability is
hereby excluded. Consequently, such use is at the recipient’s own risk on the basis
that any use by the recipient constitutes agreement to the terms of this disclaimer.
The recipient is obliged to inform any subsequent recipient of such terms.
This publication is made available for information purposes and solely for the private
use of the user. IOGP will not directly or indirectly endorse, approve or accredit the
content of any course, event or otherwise where this publication will be reproduced.

Copyright notice
The contents of these pages are © International Association of Oil & Gas Producers.
Permission is given to reproduce this report in whole or in part provided (i)
that the copyright of IOGP and (ii) the sources are acknowledged. All other rights are
reserved. Any other use requires the prior written permission of IOGP.
These Terms and Conditions shall be governed by and construed in accordance
with the laws of England and Wales. Disputes arising here from shall be exclusively
subject to the jurisdiction of the courts of England and Wales.

Page 2 of 19
CFIHOS RDL Development Guide ````cx

The Capital Facilities Information Handover Specification (CFIHOS) is an industry standard developed
to improve information exchange between the companies who own, operate, and construct plants
for the process and energy sectors. Starting with a common equipment naming taxonomy and
supporting specifications, its goal is to become a common language for the exchange of information
in these sectors.

The initial focus is on information, both structured data and traditional document formats, which are
required be handed over when a project moves from its development to operations phase.
Ultimately, the aim is for CFIHOS to become the de-facto standard for information exchange
throughout the physical asset lifecycle, from conception through to decommissioning.

The Reference Data Library or “RDL” lies at the heart of CFIHOS. This library gives a standard and
unified naming convention for equipment, its attributes, properties, disciplines and documents and
relationships.

The CFIHOS RDL includes:

 A list of Tag classes and their definitions, describing what the equipment does
 A list of Equipment and their descriptions, describing the physical equipment item
 A list of properties
 List of disciplines document types
 Lists of properties of tags and equipment
 Pick lists (allowable values for data properties to aid validation)
 Units of Measure
 Relationships between data objects.

The initial CFIHOS RDL development approach document was developed by the Owner Operator RDL
Alignment Team (bp, Chevron, Shell and TotalEnergies) and later expanded to include ExxonMobil
and Equinor with a view to carry out a one-off alignment of their existing RDLs.

Following the growth in membership of CFIHOS community across the supply chain, the RDL
development and governance document has been improved to accommodate input from wider
stakeholders to drive consistency and clarity in the set of criteria to be applied in maturing the
content of the RDL through feature requests.

Page 3 of 19
CFIHOS RDL Development Guide ````cx

Contents
1. Introduction ............................................................................................................................... 5
2. Definitions ................................................................................................................................. 6
3. Principles .................................................................................................................................. 6
4. Criteria for Class acceptance or rejection ................................................................................ 6
4.1 A Class is accepted when it reflects: ................................................................................. 6
4.2 A Class name is rejected when it: ..................................................................................... 7
4.3 Procedure for Class acceptance or rejection .................................................................... 7
4.3.1 Completion of Mandatory fields ........................................................................ 8
4.4 Assumption of validity ...................................................................................................... 10
4.5 Further Assessment Criteria ............................................................................................ 10
4.5.1 Valid Business Need ....................................................................................... 10
4.5.2 Reference to International or Industry standard ............................................. 10
4.5.3 Hierarchy maintenance during class removal ................................................. 10
4.5.4 Duplication of classes ..................................................................................... 10
4.5.5 Specialization .................................................................................................. 10
5. Criteria for creating and maintaining Properties ..................................................................... 10
5.1 Criteria to decide the creation of a new property. ........................................................... 10
5.2 Rules for naming a new property..................................................................................... 11
5.3 Rules for describing metadata for a new property. ......................................................... 12
5.4 Rules for assigning properties to classes........................................................................ 13
Annex 1 - Tagging Criteria ............................................................................................................. 15
Annex 2 - Tag (Functional) Vs Equipment (Physical) Classification.............................................. 17

Figure List
Figure 2: Required attribute for tag class or equipment class request .................................... 9
Figure 3: tag/equipment class hierarchy ................................................................................ 10
Figure 4: Taxonomy mapping between CFIHOS and Common names ................................ 11

Table List
Figure 1: example of tag class to equipment class mapping ................................................... 5
Figure 5: Property entity attributes ......................................................................................... 13
Figure 6: Example on Datasheet showing property groups ................................................... 13
Figure 7: Tag class property metadata ................................................................................... 14
Figure 8: Equipment class property metadata ....................................................................... 14
Figure 9: Model Part class property metadata ....................................................................... 14

Page 4 of 19
CFIHOS RDL Development Guide ````cx

1. Introduction
This document describes the rules that shall be applied by the CFIHOS RDL Work Group to identify
equipment classes, their attributes, properties, units of measurement, pick list of values and
relationships for additions/modifications/deletions in the CFIHOS RDL.
Engineering objects (e.g. Tags, Equipment or Model Parts) can be classified in CFIHOS to enable the
grouping of similar objects and specification of common requirements. Tag (or Functional) and
Equipment (or Physical) Class(es) are defined in the CFIHOS RDL, and a hierarchy to help to assign
appropriate Class(es).
Each Tag is classified by a “Tag Class” and the basic function (e.g. pump) that the object is intended
or required to perform is captured as design information (e.g. Flowrate). Once a physical object is
selected to be installed at that function an “Equipment Class” (e.g. Centrifugal Pump) is used to
describe the actual capability and nature of the installed equipment (e.g. Dimensions). These
physical properties would change if the component was switched out for another, but the functional
properties would not (See Annex 2 for further explanation).
The split between Tag (Functional) and Equipment (Physical) class is difficult to define. In the
current version of the CFIHOS RDL the same class name is used for Tag and Equipment classes.
Where the tag class and equipment class are not the same, mappings between the Tag and
Equipment have been made, as shown in figure 1 below:

Figure 1: example of tag class to equipment class mapping

The approach taken for the RDL is based on the assumption that a class can be either just a tag class,
just an equipment class, or both. The split between functional and physical classes in a practical
implementation will be one of how far down the class hierarchy you go before you move from
functional to physical. E.g. pump could be functional where subclass centrifugal pump might be
physical.
Simplistically this will be interpreted as if the respective Owner Operator’s Tagging Specifications
have a requirement for a functional class, it shall be considered as a valid Tag (Functional) class. This
shall apply for items that traditionally have not been uniquely identified, for example Special Piping
(SP) Items as well as uniquely identified tags. A high level comparison of the Owner Operator’s
Tagging Specs is shown in Section 6.
This approach will be reviewed for continuous improvement to ensure that it is fit for purpose.
Each class can have properties associated with it that describe some aspect of the Tag, Equipment or
Model Part. Classes and Properties are created, populated and maintained in order to satisfy
business needs (e.g. the ‘Voltage’ is a commonly used physical property for electrical equipment, as
the value has a large impact on the maintenance routine for that piece of equipment). An object of a

Page 5 of 19
CFIHOS RDL Development Guide ````cx

specific Class is placed in an operating environment in order to perform its function and it usually
contains a product, for which the property ‘fluid phase’ (e.g. gas, liquid.) would be required.

2. Definitions
A.1 A class represents a group of objects that have similar properties, behaviours and
relationships as defined by the rules for membership of the class
A.2 The Tag Class represents the design intent or engineering specification
A.3 The Equipment Class represents the physical item, i.e. actual installed item
A.4 The Model represents what can be purchased to satisfy the function
A.5 Property or attribute or characteristic are synonyms for a discrete item of data; it should
have a unique name or label, a concise, unique and unambiguous definition or description,
including data type and rules for acceptable population with a value. Property, Attribute
and Characteristic are synonyms in the context of this document
A.6 Functional properties describe engineering requirements for design or purchase purposes
A.7 Physical properties describe standard equipment from a manufacturers catalogue or actual
installed equipment.

3. Principles
Each of the participating Companies have their own RDL/Class Library. To enable consensus and
alignment of the Companies’ RDLs, each Company shall map their own RDL with the CFIHOS RDL.
Each Company can then propose any changes considered necessary to the RDL Work Group for
agreement through Feature Requests. Sections 4 and 5 provides further detail of the criteria for
agreeing proposed changes.

4. Criteria for Class acceptance or rejection

The initial CFIHOS RDL classes were built upon, and shall be maintained based on the following:
4.1 A Class is accepted when it reflects:
A.8 Different Classes (Functional or Physical) must have different sets of properties. If this is not
the case, then there is no reason to have a different Class. Example:
a) Tag (functional) class “electric motor” does not have the same set of properties, as
an “electric generator”, so two distinct classes are required except as mandated by
legislation or relevant international standards.
b) Equipment (physical) class “Centrifugal Pump” shares the same properties, as a
“Multistage Centrifugal Pump”, only the value for the property ‘Number of Stage’
would be different, so only one class is required, the most generic one.
A.9 In case of measurement devices (e.g. instruments), the class name may contain the
measured variable (e.g. “pressure transmitter”).
A.10 The method (physical process) used to perform the function. In order to perform the
function different methods (e.g. geometry, physical effect) can be used. Different methods
imply different detailed properties, this means that in that case more than one class is
required to group these properties. Examples:
• An object of equipment class “Centrifugal pump” uses the centrifugal force in order
to perform the “pump” function.

Page 6 of 19
CFIHOS RDL Development Guide ````cx

• Objects of equipment class “Plate heat exchanger” and “shell and tube heat
exchanger” are fundamentally different in shape
A.11 The primary function performed by the object. For example, “ventilation fan” and “cooling
fan” are in fact “fans” that performs different secondary functions,” ventilating” and
“cooling”, but the primary function of a “fan” is to create a flow of gas. This flow of gas may
be used to “ventilate” or to “cool”.
A.12 In this particular case, the object performing the function should be contained in the name,
description or properties in the corresponding secondary function. In the previous
example, the Tag description (service) could be “Main Control room ventilation fan” and
the Functional Class of the Tag would be “fan”. The physical class could be “centrifugal fan”
or “axial fan”, describing the actual type of fan installed to perform the function
A.13 If the installed object has different maintenance requirements, different physical classes
may be required, e.g. “gas turbine” vs “steam turbine”.
4.2 A Class name is rejected when it:
R.1 Contains the location where the classified object will be installed (e.g. “deep well pump”)
or is ambiguous – e.g. subsea control panel is unlikely to be installed under water.
R.2 Contains the dimensions of the classified object (e.g.”5-inch valve”).
R.3 Contains the material that is used to build the object (e.g. “stainless valve”).
R.4 Makes reference to the product properties that could be contained within the Object (in
term of physical variables like pressure, flow, temperature or fluid type) unless its primary
function is to measure these physical variables (e.g. “chemical tank” would be rejected
because it could be used for storing other contents, for example diesel).
R.5 For measurement devices, contains the Unit of measure used to measure the variable
(e.g. PSI pressure transmitter).
R.6 Contains a term that is part of an infinite series of terms which would result in the
creation of an infinite number of classes. (e.g. “CO2 gas detector” is rejected because CO2
is one combination of molecules and there are an infinite number of molecules
combinations).
R.7 Is intended to classify objects of different natures, i.e. “catch-all” type of classes (e.g.
“Other mechanical equipment”)
R.8 Is a Tag Class, with the ‘Equipment Installed’ attribute set to yes, that does not have any
mapped physical classes.
R.9 Is a Functional Class at the lowest level of the hierarchy that is not used by any of the
Owner Operator RDL Alignment Team members (See Section 4.5.1).
R.10 Contains an abbreviation in the Name
R.11 Shares the same definition as another class (provision is available in CFIHOS to capture a
synonym).
R.12 Is a Tag or Equipment class with only one child at the lowest level of the hierarchy.

4.3 Procedure for Class acceptance or rejection

CFIHOS members’ proposal submitted through CFIHOS Feature Request (FR) process shall be
assessed based on the criteria defined in Section 4 to enable consensus.
1. The proposing member is responsible for

Page 7 of 19
CFIHOS RDL Development Guide ````cx

a. submitting a Feature Request regarding their proposal

b. ensuring the proposed class meets the criteria described in section 4.
c. providing all relevant information to support CFIHOS members voting regarding the
overall principle of the FR.
2. Provided the proposed change meet the criteria and supported by majority of RDL Work Group
members, the change will be submitted to the CFIHOS RDL FR Maintenance Team for inclusion
in the CFIHOS RDL.
3. If a majority is not achievable, proposed change will be deferred or outrightly rejected. The
outcome will be reported to the CFIHOS RDL FR Maintenance team as “not approved” along
with the reason for rejection documented (in case it is proposed again in the future).

4.3.1 Completion of Mandatory fields

Defined in the CFIHOS Tag/Functional Class and Equipment/Physical Class definitions the following
fields are considered mandatory and additions will not be proposed if these fields cannot be
completed (Source: CFIHOS V1.5).

Tag_Class Equipment_Class

Attribute_ Definition Constraint Attribute_ Definition Constraint

Primary Key

Primary Key
Mandatory

Mandatory
Name Name

parent tag Identify the Refer to M1 parent Identify the parent Refer to M1
class name parent class of a definition equipment class of an definition
Tag_Class, in group: class name Equipment_Class, group:
order to build a Tag_Class in order to build a Equipment_Cl
hierarchy of hierarchy of ass
Classes. Classes.
tag class The full name of PK equipment The full name of PK
name the tag class. class name the
Equipment_Class.
tag class Definition of the M equipment Definition of the M
definition Tag_Class. class Equipment_Class.
definition
abstract class When set to No, See Picklist: M abstract class When set to No, See Picklist: M
flag indicates that the yes no flag indicates that the yes no
Class can be used Class can be used
for classifying for classifying Tag,
Tag, Equipment Equipment or
or Model_Part. If Model_Part. If set
set to Yes, to Yes, indicates
indicates that the that the Class can
Class can only be only be used for

1
All new classes proposed will be provided with a Parent Class to ensure that it can be added to the existing
hierarchy.

Page 8 of 19
CFIHOS RDL Development Guide ````cx

Tag_Class Equipment_Class
Attribute_ Definition Constraint Attribute_ Definition Constraint

Primary Key

Primary Key
Mandatory

Mandatory
Name Name

used for building building a class

a class hierarchy. hierarchy.
ISO15926 The identifier iso15926 The identifier used
part4 unique used in ISO part4 unique in ISO 15926-4 to
number 15926-4 to number identify this class
identify this class uniquely.
uniquely.
CFIHOS A unique id CFIHOS A unique id
unique id number assigned unique id number assigned
by the CFIHOS by the CFIHOS
project. project.
unique id The identifier unique id The identifier used
STEPLIB used in Steplib to steplib in Steplib to
identify this class identify this class
uniquely. uniquely.
unique id The identifier unique id The identifier used
POSC used in POSC- posc caesar in POSC-CAESAR to
CAESAR CAESAR to identify this class
identify this class uniquely.
uniquely.
referenced International or referenced International or
standard Industry Standard standard Industry Standard
that requirement that requirement
is sourced from. is sourced from.
tag number A regular spare part Indicate if some See Picklist: M
format expression that info req spare part yes no
represents the information is
tag class format required for this
according to type of Equipment.
Principals Tagging
Specification
equipment Indicate if See Picklist: M reason for To provide the
installed equipment is yes no having class Reason for having
expected to be the Class.
installed for this
type of Tag.
reason for To provide the
having class Reason for
having the Class.
Figure 2: Required attribute for tag class or equipment class request

Page 9 of 19
CFIHOS RDL Development Guide ````cx

4.4 Assumption of validity

Each company has invested time and expertise into their respective class libraries – suggestions
should be accepted provided that they meet the defined criteria.

4.5 Further Assessment Criteria

4.5.1 Valid Business Need
A valid business need must be demonstrated before proposing a new class. The standard rule is that
the class must be in use at more than one asset to consider adding (this may be across OOs). If only
in use in one asset, then the class would be considered as project/asset specific and the OO can still
use in their local library until usage increases.

4.5.2 Reference to International or Industry standard

Proposed new classes should (wherever possible) be described in an international or industry
standard/reference, preferably ISO 15926 Part 4 and/or other standards (for example API, ISO, IEE,
ISA).

4.5.3 Hierarchy maintenance during class removal

Where the list of child classes of a parent class reduces into one class, such parent class ceases to be
a parent class. However, such parent class could be restored where additional class(es) are proposed
and accepted to the list of child classes in the future.

4.5.4 Duplication of classes

New classes must not be proposed that are synonyms of existing classes. Synonyms may be added to
existing classes to allow for variations between companies/regions. Such synonym cannot be used
for more than one class.

4.5.5 Specialization
All classes shall be added whenever possible to the existing CFIHOS class hierarchy. Where possible
this should maintain consistency with the existing granularity within CFIHOS.

Class Sub Class Sub Sub Class

Valve Ball Valve
Transmitter Pressure Transmitter
Analysing instrument Chromatograph Gas chromatograph
Figure 3: tag/equipment class hierarchy

The decision on where to stop the sub classification can be made by applying the rules described in
this document (rule R12).

5. Criteria for creating and maintaining Properties

The initial CFIHOS RDL classes and properties were built upon, and shall be maintained based on the
following:

5.1 Criteria to decide the creation of a new property.

P.1 The property must appear on an international or industry standard or datasheet (See rule
P10 for how to deal with inconsistent property naming in existing standards).

Page 10 of 19
CFIHOS RDL Development Guide ````cx

P.2 The property will be used for the purposes of reporting (e.g. Ex register), searching,
calculations or sharing (e.g. common data between CMMS and Inspection Management
System). The property may have multiple purposes, i.e. for multiple consuming
organizations and/or data systems. Purpose(s) must be explicit.
NB. CFIHOS does not try to include all data sheet fields on a datasheet, only those where a
specific business requirement exists to hold the value as data will be included.
P.3 The property shall be related to at least one tag Class or one equipment Class or one
CFIHOS Data object (i.e. no property will be unused).
P.4 The same property name can be used for both Tag (Functional) and Equipment (Physical)
classes. For example, explosion protection gas group are required to define the EX
requirement (functional) and the suitability of the equipment for use (physical). The
Functional and Physical properties can be compared to partially automate the verification
of the requirement.
5.2 Rules for naming a new property.
P.5 Each property shall have a unique name and unique definition.
P.6 Abbreviations and special characters (e.g. /) shall be avoided in property names.
P.7 The picture below illustrates the usage of the terms ‘upper limit’, ‘lower limit’, ‘normal’
and ‘rated’.

CFIHOS Name Common Name

Upper limit allowable pressure Maximum allowable working pressure
Upper limit design pressure Upper design pressure
Upper limit operating pressure Maximum operating pressure
Rated pressure
Normal operating pressure Operating pressure
Lower limit operating pressure
Lower limit design pressure Lower design pressure
Lower limit allowable pressure Minimum allowable working pressure
Figure 4: Taxonomy mapping between CFIHOS and Common names

Some Definitions:
• The values for ‘allowed’ are set by regulatory requirements.
• The value for ‘rated’ is the value at which the equipment has been designed to operate most
efficiently.
• The value for ‘normal operating’ is the value at which the equipment will operate most of the
time.

Note:
• The above example is for pressure but is applicable to any measured variable.
• The terms ‘normal design’ and ‘rated design’ are not allowed. The term ‘rated’ is used instead.

P.8 The name used for a property of a ‘part’ should contain the:
a) Role of the part within the whole (e.g. inlet)
b) Class of the part (e.g. flange) – see note below

Page 11 of 19
CFIHOS RDL Development Guide ````cx

c) Property name (e.g. diameter)

Concatenating these words gives the name of the property ‘inlet flange diameter’.

Note:
• ‘Part’ should not be used to capture properties for tagged items (i.e. items that have a class
defined in the Tag Class reference data). For example, in a package, pumps shall be uniquely
tagged. Properties should therefore be associated against the pump tag and not the package
tag, hence eliminating the need for a pump capacity property against the package.
Components of the pump, for example the impellor, the casing can have properties created,
i.e. casing material, impellor diameter, etc.).

P.9 The property name should be very specific (e.g. on a shell and tube heat exchanger ‘shell
side fluid name’ is preferred to ‘fluid name’), unless this is the fluid in the whole assembly.
This allows one:
• To re-use the property for another class and to have a precise non-ambiguous
definition.
• To add more properties in the future without having to rename the existing ones (e.g.
if ‘fluid name’ was created instead of ‘shell fluid name’, then it would be hard to
introduce at a later stage a property for the ‘tube fluid name’).
P.10 Where possible, property names should align with international or industry standards
(e.g. ISO-13709 for centrifugal pumps). Ideally the names would be the same but there
are many inconsistencies in the engineering standards today that prevent this, so a
reference to the source property name shall be retained where the property has different
names in separate standards.
P.11 The word ‘Type’ shall be used in an unambiguous way, e.g. ‘actuator type’ is not a good
property name as it could be referring to many aspects of the actuator; the signal type,
the type of motion (linear or rotary) or the type of actuation, etc.
5.3 Rules for describing metadata for a new property.
P.12 The property definition should be detailed enough to avoid ambiguities. The definition
must not be a simple repetition of the property name or synonyms thereof. The
definition should use terminology that can be understood by people from any
discipline/background.
P.13 When a new property requires a unit of measure, it must be associated with a valid unit of
measure dimension (for example temperature) which would allow for the specific uom (for
example degrees Celsius or Kelvin).
P.14 Pick lists should be used when there is a finite list of well-defined values or options. Free
text should be used when there is potentially an infinite number of options e.g. a property
like ‘gas composition’ is not suitable for a pick list as there are too many possible values
options to list.
P.15 The use of lookup values for property shall be maximized whenever possible and reference
to the corresponding standard, if exist mentioned (e.g. explosion protection concept
property lookup values are referenced back to EN 50014).
P.16 The property shall be mapped to one and only one ISO15926/PCA Property (check date –
based on)
P.17 CFIHOS shall not capture the mapping between the property name and the equivalent

Page 12 of 19
CFIHOS RDL Development Guide ````cx

name in other applications (e.g. CMMS, Corrosion/Inspection System, and Commissioning

Completions Management System). If this mapping is required, it will be retained by each
Owner Operator as the number of variations is too large to handle within the standards.

See the CFIHOS Data Dictionary for latest Meta data. Below is screenshot

Figure 5: Property entity attributes

Note:
Additional meta-data requirements would be considered as part of future maturation of CFIHOS
standard for properties. Examples include:
• Required at Maturity Level – to indicate when in the lifecycle the property needs to be
provided. For example, At end of FEED, prior to procurement, after procurement, etc.
• Attribute Group – to group properties as they are on a typical data sheet. The example below
shows an example for Air Cooled Heat Exchangers from ISO 13706, where properties are group
into “Basic design data” and “Performance data – tube side”.

Figure 6: Example on Datasheet showing property groups

5.4 Rules for assigning properties to classes

P.18 P18. Properties can be assigned to a Tag, Equipment or Model Part. The property must

Page 13 of 19
CFIHOS RDL Development Guide ````cx

appear on an international or industry standard or datasheet for the class to be assigned.

P.19 P19. For new properties, the international or industry standard or datasheet defining the
relationship between the class and the property must always be identified.
P.20 P20. Default units of measure will be assigned based on the values from the relevant
standard.

See the CFIHOS Data Dictionary for latest Meta data. Below are examples:

Figure 7: Tag class property metadata

Figure 8: Equipment class property metadata

Figure 9: Model Part class property metadata

Page 14 of 19
CFIHOS RDL Development Guide ````cx

Annex 1 - Tagging Criteria

The table below provides a high-level comparison of typical Owner Operator’s Tagging
Requirements.

BP Chevron Shell TotalEnergies

Operations to identify specific requires identification to identify specific Tags shall be allocated to
equipment for in one or more equipment for isolation Asset objects up to a
isolation purposes operational procedures. purposes (electrical, certain level of the Asset
(electrical and process and utilities) in decomposition, allowing
Subject to isolation
process) in relation to relation to operational to manage efficiently & in
procedures such as
operational procedures. a practical way Company
permit to work (PTW)
procedures. activities and associated
(e.g., electrical
technical information.
equipment, manual
Tags can be allocated to
valves, and piping
single objects or group of
specialty items).
objects, subject to site
Maintenance the need to perform subject to inspection, the need to handle or construction/installation,
maintenance maintenance, or perform maintenance pre/commissioning,
activities on an history. activities on an operations, inspection
equipment item, that equipment item or line and/or maintenance.
will require that will require • All Safety Critical
Includes pipe supports
scheduling of scheduling of Elements shall be tagged.
with maintainable
maintenance and/or maintenance, • Any other item or
components (e.g.,
equipment history inspection and/or object installed
springs, dampers, and
recording at that level equipment history permanently at a
polytetrafluoroethylene
of detail. recording at that level worksite, which is
[PTFE) guides).
of detail. handled during one or
Certification pressure regulation, are EX-rated, used in a pressure regulation, several of above activities
mechanical handling hazardous area, or used hazardous area rated, shall be allocated a
safe working load, for mechanical mechanical handling dedicated tag by
etc. requirements for handling). safe working load, etc. Contractor.
specific equipment. requirements for • Temporary items or
Subject to compliance
All EX certified specific equipment. objects supporting some
or regulations.
electrical equipment of above activities may
within sub-contractor also be tagged for close
and/or supplier follow up of their status
packages or modules over time
must be allocated a
project tag number
except for IS barriers
and cable glands.
Safety equipment which Related to safety, ‘Equipment items’ that
performs a safety including both process perform a safety
function, e.g. safety and life support function, e.g. pressure
pressure relief valves relief valves, over-
and over-pressure pressure protection
protection devices. devices, safety
instrumented systems
and fire-fighting
devices.
Commissioning The need to perform
detailed functional
checks and system
start-up activities.

Page 15 of 19
CFIHOS RDL Development Guide ````cx

BP Chevron Shell TotalEnergies

Engineering
Connected to
permanent cables.
Includes inline piping
equipment, devices,
and components (e.g.,
manual valves and
piping specialty items).
Spares ‘Equipment items’ that
require tag numbers to
allow Bills of Materials
to be related to them.
Technical Technical documents
Documentation require references to
Tags to be collected to
facilitate finding key
information in the
Operate Phase

Page 16 of 19
CFIHOS RDL Development Guide ````cx

Annex 2 - Tag (Functional) Vs Equipment (Physical) Classification

PROJECT REQUIREMENTS

During a Project the design of the asset is progressively decomposed into functional items until a
sufficient level of granularity is achieved to enable procurement of equipment. These lowest level
functions are allocated a unique identification number per plant, known as a Tag.

Different functions have different requirements, for an example a pump and a motor will be
represented with different symbols, have different tag formats and have different data and
document requirements to progress the design and subsequent execution of the project. To allow
these differences to be managed the Tags are classified.

The classification of the Tag may become more explicit as the Project progresses, so in FEED it may
be known that a pump function is required but only when further specification of the requirements
are defined in EXECUTE will it become clear that a centrifugal pump is most suitable for the required
function. This will result in a functional specification defining the design and operating conditions
that can be used to determine the physical items that most effectively meet the functional
requirement for procurement.

Page 17 of 19
CFIHOS RDL Development Guide ````cx

Vendors will offer either a custom designed item or a standard model part that can meet or exceed
the functional requirements. This allows the selection of the physical equipment that will be
procured to be installed to satisfy the function. These physical items typically have a serial number
to uniquely identify them and can be classified with an equipment (Physical) class based on the
technology used to satisfy the requirements (a pneumatic motor will have different properties to an
electrical motor for example). To complicate matters the data sheets for these different items often
mix tag and equipment properties in the same document.

OPERATIONAL REQUIREMENTS

Once the plant is handed over to Operations, the main focus is to ensure that the asset continues to
function as designed. Different functions will require different activities to be performed to achieve
this based on the likely failure modes. Maintenance and Inspection activities are defined in the
Maintenance System and typically scheduled at the functional level with costs and history
subsequently recorded.

For some functions, for example pressure vessels, it is difficult to distinguish between the functional
and physical. Other functions being able to be replaced, for example a relief valve could be removed
and another equivalent relief installed to provide the same function. With this example of a relief
valve it is important to ensure that the certification of the specific valve installed is known to ensure
it is configured correctly. ISO 15926-2 contains an equivalent example for a pump.

Page 18 of 19
CFIHOS RDL Development Guide ````cx

The Tag (function) would only change if there was a plant change to change the functional
requirement.

To put very simplistically a Tag is description of the function required, while the equipment is
something that can be touched and is installed to satisfy the function.

Page 19 of 19