5.1. Data Structure Overview

This chapter describes the structure of the database established to collectdata and perform calculations described in the previous sections of thisGuideline. This structure is embodied in database software that acceptsand stores data, analyzes the data according to predefined algorithms andrules sets, and produces a set of standardized results for the user.

A summary of the data structure for the CCPS Equipment Reliability Data-base is shown in Figure 5.1. This figure is valid (and can be applied) at anylevel in the taxonomy. The CCPS Database contains four distinct types of data:

• Unique Item Data—Fixed data specific to an item as defined by anidentifying number and a boundary diagram. Examples of uniqueitem data are serial number, model number and manufacturer.

• Application Data—User-defined data specific to the location and thecondition of operation and maintenance of an item. Examples ofapplication data are pressure, temperature, fluid state, and corro-siveness.

• Event Data—Data recording events that can happen to, or are doneto a given item in a given application, for example, inspections, tests,or failures. An example of an event datum would be the actual liftpressure from a relief valve bench test.

• Failure Logic Data—For failure events, these are data that define theitem function(s) lost, the mode(s) of failure observed and the mecha-nism of failure. For example, a failure logic datum might specify thata lift pressure of more than 150% of the design setpoint would trans-late to the failure mode of "fails to lift at set pressure."

5 Data Structure

FIGURE 5.1. Data structure overview.

Note that, within the Inventory Data group, the CCPS Database makesa distinction between information relating to the application and the infor-mation relating to a particular piece of equipment. This distinction is madebecause a company may utilize a piece of equipment in several differentlocations during the life of that equipment item. The structure allows thedatabase user to collect and analyze information for both location and item.

5.2. General Taxonomy

The general taxonomy for the Application and Inventory Data of the CCPSDatabase is shown in Figure 5.2. Because the Application Data areuser-defined and "boilerplate" in nature, it is addressed first in the taxon-omy. The General Taxonomy has seven basic levels of indenture.

Inventory DataApplication Data Event

DataUniqueItemData

LocationData

OperatingConditions

OperatingMode

MaintenanceStrategy

FailureLogicData

Rule Set

Function / FailureModes

Mechanism

Level

INDUSTRY

ChemicalsOil/Gas

SITE

AnonymizedUSER-DEFINED

PLANT

Anonymized

UNIT

alkylationcoking

SYSTEM

CompressorsPumps

COMPONENT

transmission

FIXED

PART

bearingsseals

FIGURE 5.2. CCPS Database taxonomy.

1. Industry2. Site3. Plant4. Unit / Process Unit5. System6. Component7. Part

The first four levels of the taxonomy relate to application data and thelast three relate to inventory data, comprising both item and applicationinformation. The options for all levels are listed in Appendix II.

It is not practical to display the entire taxonomy on paper. It is better toshow the basic relationships that exist within the software, supplementedby standard pick list tables and failure mode definitions. It is possible forthe user to query the relational database using filters, to essentially define aunique taxonomy with attendant data for the purpose of analyzing specificissue (s).

5.2.1. Taxonomy Levels 1-4 (Industry, Site,Plant, Process Units)

The taxonomy appearing at levels 1-4, as shown in Figure 5.2, is a highlevel categorization that relates to industries and plant operations regard-less of the equipment systems involved. For these levels, the user inputsthe appropriate choices from pick lists for each equipment system beingtracked. In this way the actual taxonomy for the specific application isdeveloped. During analysis the user may query the data to define a specialtaxonomy of interest. This is illustrated in Table 5.1.

TABLE 5.1Illustration of User-Defined Taxonomy

Level Industry Site Plant Unit System

PickList

Chemical —commodity

Chemical —polymers

Gases —industrial

Oil/Gas—refining

Ohio

New York

Texas A

Texas В

Refinery

Olefms

Ethylene

Alkylation

Coking

Distillation

Reforming

Hydrocracking

Pumps

Compressors

Turbines

Vessels

Condenser

The query above would search for data for all pumps in distillationunits in the refinery plant at the 'Texas A' site, within the oil-gas refiningindustry. The anonymization process means that only users with specificprivileges would be able to specify searches for their own site. An exampleof the complete taxonomy, down to the part level, might be

Level I/Industry — chemicalLevel 2/Site — Texas ALevel 3/Plant — ethyleneLevel 4/Unit — compressionLevel 5/System — compressorLevel 6/Component — power transmissionLevel 7/Part — coupling

The above example assumes that the user has access rights to specificsite and plant data. For users without access to the proprietary fields in thedata, those fields cannot be specified in a search query, and are bypassed inthe taxonomy. An example of a typical search by someone with no accessrights might be as shown below:

Level I/Industry — chemicalLevel 2/Site — allLevel 3/Plant — allLevel 4/Unit — compressionLevel 5/System — compressorLevel 6/Component — power transmissionLevel 7/Part — coupling

5.2.2. Taxonomy Levels 5-7 (System, Component, Part)

The taxonomy of levels 5-7 are specific to equipment systems. Use of therelational database software allows the user to specify equipment systempopulations that are of specific interest to the analyst. In one case, the ana-lyst may be interested in compressor systems processing a particular fluid.For this case, all equipment considered part of the compressor would beincluded. In another case, the concern may be the performance of heatexchangers. Only heat exchangers of a particular type, such as shell andtube, would be included for this case.

The equipment systems available within the CCPS database are listedin Appendix II. For the convenience of the user, equipment systems havegenerally been grouped into various classes of systems. The concept of"grouping" was borrowed from the ISO-standard and the OREDA database."Equipment Group" provides a convenient means for grouping equipmentsystems.

5.2.3. Treatment of Subordinate Systems in the CCPS Database

Some systems, such as heat exchangers, function as independent systemsin some applications or as support systems in other applications. In a sup-porting role, these systems act like components of the larger system, ratherthan independent systems. These supporting systems are referred to assubordinate systems when they function as components for a largersystem. The subordinate relationship between systems is sometimesreferred to as a "parent-child" relationship. An example of this par-ent-child relationship is the interstage heat exchanger that is part of a com-pressor system. The compressor is the parent, and the heat exchanger isthe child. However, both the compressor and the heat exchanger areequipment systems in the taxonomy.

To resolve this dilemma, the Equipment Reliability Database hasincluded the option to record the subordination of systems, so that failureof a subordinate system accurately cascades to failure of the primarysystem. The systems are registered as independent systems, but they aretagged as being subordinate to a larger system. Using the example of a heatexchanger supporting a compressor, the user would enter the database inthe compressor system and would then be automatically linked to the heatexchanger system. The heat exchanger would appear as a componentwhen system-level events are recorded.

5.3. Database Structure

The database is constructed of a series of tables that specify the databasefields. Software is also available to analyze and report data according to auser's specifications. Each table contains numerous fields that are popu-lated with predefined information, known as "pick lists." The pick lists pro-vide a means of standardizing input fields (see Appendix II for the CCPSDatabase tables).

Table 5.2 shows an overview of the tables contained in the database.During future development, more tables may be added. Temporary tables,used to store intermediate results for calculations, are not shown in Table5.2.

Descriptions of the tables used in the database are provided in the fol-lowing sections. Due to the changing nature of the database design as addi-tional equipment systems are developed and added, the exact tables arenot shown in this Guideline.

5.3.7. Inventory Tables

Inventory tables provide information that identifies a piece of equipmentfor use in the database. Inventory information is used when filtering datafor specific applications.

Subscriber Inventory

Data are submitted to the database by a Subscriber. Data in this field arefully anonymized in the aggregated dataset distributed to participants.Typically, the Subscriber would be based at a plant or site and be registeredand qualified to submit data. It is possible for one company to have severalsubscribers to the database. There is one copy of the Subscriber InventoryTable for each Subscriber. Throughout the data tables, the Subscriber isuniquely defined by the Subscriber Name. The Subscriber Inventory Tablecaptures information about the Subscriber such as company name, contactname, address (physical, postal, and e-mail), and phone numbers.

Site Inventory

Data in this field are fully anonymized in the aggregated dataset distributedto participants. This table is completed once for each site enrolled by a sub-scriber in the reporting system. There is only one copy of this table for eachsite. In most cases, there will only be one site associated with a subscriber.In many cases, depending on the internal organization of the reportingentity, the site name will be the same as the Subscriber Location. This tablecontains information such as site name, location, and contact.

Plant Inventory

This table is completed once for each Plant in the reporting system at agiven Site. Data in this field are partially anonymized in the aggregateddataset distributed to participants. There may be multiple versions of thistable for each site. This table captures information such as plant name,industry associated with the plant, as well as type of plant, external envi-ronment, plant start date, and normal operating mode.

Unit Inventory

This table is submitted once for each process unit in the reporting systemat a plant. There may be multiple versions of this table for each plant. Thetable contains information regarding unit name, operating mode, and unitstart date.

TABLE 5.2Database Structure

Table Type

InventoryTables

EventTables

Table Description

Subscriber Inventory

Site Inventory

Plant Inventory

Unit Inventory

System Inventory —General

Plant Events

Process Unit Events

System Events

Related Tables

System-Specific Inventory

Loss of Containment

Startup

Shutdown

Curtailment

Loss of Containment

Startup

Shutdown

Curtailment

Calibration

Inspection

Proof Test

Repair

Preventive Maintenance

Condition-Based Maintenance

Demand

Loss of Containment

Startup

Shutdown

Curtailment

Calibration

Inspection

Proof Test

Repair

Preventive Maintenance

Condition-Based Maintenance

Demand

Notes

System-specificfields are a func-tion of system type

Not all event typesare Applicable toall Systems.

System Inventory—General

There is one General System Inventory table for all systems enrolled in thedatabase, regardless of Subscriber. There is one record for each systemlogged in the database. Each record in the General Inventory table cap-tures information that applies to all systems, regardless of type. A sample ofsome of the fields in this table is shown below.

• Subscriber ID• Site ID• Plant ID• Serial number• Tag number• Date installed• Surveillance start date• Maintenance strategy• Associated systems• External environment

System Inventory—Specific

Much of the information needed to store meaningful inventory data is afunction of the specific equipment type. For instance, a relief valve can bepartially characterized by its lift pressure, a property that a pipe would nothave. Because different types of systems require different fields to specifythe inventory, a specific inventory table exists for each type of system in theCCPS Database. As an example, a partial listing of the System-SpecificInventory table for relief devices is provided below:

Valve design• Manufacturer• Model number• Inlet connection size• Orifice size and designation• Outlet connection size

Service Conditions• Fluid handled• Phase at relief inlet• Set/Opening pressure• Blowdown %

Selection of material• Body material• Spring material• Bonnet material• Seat material

5.3.2. Event Tables

Once an item (plant, unit, system, etc.) has been registered in the database,event information can be gathered via the event tables. Currently the CCPSDatabase is designed to record data at the plant and system levels.

A key feature of the CCPS Equipment Reliability Database is the capac-ity to store and retrieve data pertaining to events at the plant, process unitand the system levels.

Plant EventsThe main Plant Event table records the name and type of event occurringfor a specific plant registered in the database. The information stored inthe Plant Event table is the name of the plant, date and time of the eventand the type of event (curtailment, shutdown, etc.). Once the type of eventhas been recorded, the user inputs specific data through the subtableslisted below.

Plant Event—Loss of ContainmentThis table stores information for loss of containment events at the Plantlevel. Some of the fields in this table are listed below.

• Event date and time• Event duration OR• Event end date and time• Reportable? Y/N• Fluid released• Failure descriptors• Severity• Hole size• Consequence

For loss of containment events, the severity field is then used to deter-mine the specific failure mode based on a rule set programmed or imbed-ded in the database program.

Plant Event—ShutdownThe Plant Shutdown Event table records necessary information for a plantshutdown. A partial listing of the fields in this table is shown below.

• Event date and time• Event duration or• Date and time returned to service• Is there a force majeuret Y/N

• Shutdown cause• Shutdown subcause• Scheduled activity? Y/N/Unknown

The default for all plant shutdown events is "loss of production."Through the use of filters, an analyst can zero in on why the plant shutdown.

Plant Event—StartupThe Startup Event table for plants contains the following fields:

• Event duration• Event end date• Event end time• Was the startup successful? Y/N

Plant Event - CurtailmentA curtailment is defined as a partial reduction in the output of a plant. Cur-tailment information is gathered using the following fields:

• Event start date and time• Event duration, or• Date and time returned to full capacity• Cause of curtailment• Maintenance Required?• Average percent capacity available

Process Unit EventsProcess unit events had not been developed at the time of publication ofthis Guideline.

System EventsThe events below are examples only. Some fields and/or tables may changebased upon system of interest. The System Events table contains therecords submitted by a subscriber for each system event reported during agiven period. One record is submitted for each event. In the CCPS Data-base, the following are considered as events for systems:

• Loss of Containment• Startup• Shutdown• Curtailment• Calibration

• Inspection• Proof Test• Repair• Preventive Maintenance• Condition-Based Maintenance• Process Demand

Owing to the differences among systems, some of the above eventsmay not apply to a given system. For instance, a curtailment is not an appli-cable event for relief valves. When the taxonomy for a system is established,the list of applicable events is developed so that the database can be pro-grammed to screen out irrelevant events.

Any number of records can be reported during a given period. Allevents are uniquely defined by their Subscriber ID, System ID, event dateand time.

System Event—Loss of ContainmentLoss of containment events can occur for nearly all systems. A sample of thefields used for system-level loss of containment events is shown below forrelief valves:

• Event date and time• Event end date and time or• Duration• Pressure at time of failure• Fluid Released• Severity• Quantity Released, Ib• Hole Size• Estimated Area• Event description• Consequence• Reportable Incident?• If reportable, reportable to:• Comments

System Event—ShutdownIf a system is shutdown, certain data are recorded for the estimation ofrelibility parameters.

• Event date• Event time• Date and time returned to service

• Is there a. force majeure? Y/N• Shutdown cause• Shutdown subcause• Scheduled activity? Y/N/Unknown

System Event—StartupThe system startup event is characterized by the ability of the system tostart according to predefined criteria. A failure to start is, by itself, a failuremode for most systems. If the field for successful start is a no (N), the fail-ure mode is automatically set to "fails to start."

System Event—CurtailmentCurtailments events are usually linked to the "partial loss of throughput"failure mode. The following is a sample of fields appearing in a System Cur-tailment table.

• Event start date and time• Event duration, or• Date and time returned to full capacity• Cause of curtailment• Maintenance Required?• Average percent capacity available

System Event—InspectionInspections typically do not mean that a failure has occurred; however,they can point to a failure mode that may not be easily detected. TheInspection Event table records the necessary information from a systeminspection. For relief valves, a sample of the data fields are provided below.

• Discharge piping visual inspection• Weep hole visual inspection• Evidence of seat leakage• External leakage• Repair required• Pressure between rupture disk and relief valve• Insulation loss?• Heat tracing operating?• Pressure monitor functional?• Temperature monitor functional?• Excess flow check valve functional?

System Event—Process DemandProcess upsets may trigger failures or successes for some systems. A partiallisting of the process upset data collected for relief devices is provided inthe list below.

• Event end date• Event duration or event end time (Depending what is picked, the

other should be calculated.)• Reason for process demand• Event description• Valve lift? (Discharge through the relief valve.)• Lift pressure• Maximum process pressure achieved• Rapid cycling of the valve (chatter) audible during incident?• Valve reseat?• Reseat pressure• Code deviation?• Protected equipment damaged?• Loss of containment?• Repair or replacement required?• Additional information

System Event—RepairRepair events occur when a repair is made following a failure, proof test,inspection, or condition-based maintenance. The following fields are partof the System Repair Event table for relief devices. Keep in mind that "fail-ure mode" does not appear as a field here, since failure modes are calcu-lated by the rule set provided to the software.

• Maintenance start date• Maintenance start time• Date maintenance completed• Maintenance hours expended• Maintenance performed• Components repaired• Components replaced• Part replaced• Components failed• Component failure cause (s)• Part failure mode• Part failure cause (s)• Additional information• Disposition following repair

System Event—Proof TestThe fields used to record data for a relief device proof test event are shownbelow.

• Proof test date• Event time• Visual flow path inspection: inlet• Visual flow path inspection: outlet• External leakage• Seat leakage• Leak pressure• Valve lift?• Lift pressure• Maximum test pressure• Valve reseat• Reseat pressure• Leakage following reseat• Maintenance performed?• Actual test time (hours)• Additional information

System Event—CalibrationThe fields used to record data for a calibration are shown below.

• Calibration date• Time of calibration• Calibration performed in-situ (Y/N)• As-found value(s)• Point check (P) or range (R)?

System Event—Condition-Based MaintenanceCondition-based maintenance (CBM) events occur when maintenance isperformed based on the some predefined condition of the item. The fol-lowing fields are part of the System CBM Event table for relief devices.

• Maintenance start date• Maintenance start time• Condition for maintenance• Maintenance hours expended• Maintenance performed• Components repaired• Components replaced• Part replaced

• Components failed• Component failure cause(s)• Part failure mode• Part failure cause (s)• Additional information• Disposition following repair

System Event—Preventive MaintenancePreventive maintenance events occur when maintenance is carried out atpredetermined intervals or according to prescribed criteria and isintended to reduce the probability of failure of an item. The followingfields are examples of the Preventive Maintenance Event table for reliefdevices.

• Maintenance start date• Maintenance start time• Date maintenance completed• Maintenance hours expended• Maintenance performed• Components repaired• Components replaced• Part replaced• Components failed• Component failure cause(s)• Part failure mode• Part failure cause (s)• Additional information

5.3.3. Failure Logic Data

Failure logic data are not contained in separate tables; rather, they areembedded in the programmable logic of the database, allowing the fail-ure modes to be determined from factual data contained in event datatables. The failure logic is determined during the taxonomy developmentprocess and provides the crucial link between event data and failuremodes. Samples of the failure logic data for relief devices are presentedin Table 5.3.

TABLE 5.3Sample of Failure Logic for Relief Valves

SystemFailureModes

Fail toopen

Opensabove setpressure

Failure ModeDefinition

Fail to openprior to reaching1.5 times setpressure

Opens between1.1 and 1.5 timesset pressure

Input Form

Demand

Proof Test

Inspection

Demand

Proof Test

Relief Valve Failure Logic

Criteria

Relief lift = "NO" or lift ratio equal to orgreater than 1.5

Fail to open if "plugged" or lift ratio equalto or greater than 1.5 or max pressureequal to or greater than 1.5

Discharge piping plugged field = Plugged

Lift ratio between 1.1 and 1.5

Lift ratio between 1.1 and 1.5