ISA T R A N S A C T I O N S ®

ELSEVIER ISA Transactions 35 (1996) 187 - 195

Instrument information m a n a g e m e n t - - the n e w paradigm

Mike Spencer a, *, Steve Hutt b, Fred Mintun b, Gary Wollner b

a Q1C Systems Inc., 531 Main St., Suite 1176, El Segundo, CA 90245, USA b Chevron USA Products, 324 West El Segundo BldL,., El Segundo, CA 90245, USA

Abstract

This paper analyzes the type of requirements needed for information and documentation management within the instrumentation design and maintenance environments in order to maintain credible safety and reliability standards for installed equipment and systems. A new paradigm is introduced that integrates the requirements of the engineering design contractor and the plant design, maintenance and reliability groups. This paper proposes an improvement in the way we do business which will offer significant economic and quality benefits in addition to satisfying the safety and environmental requirements of OSHA 1910 and the quality requirements of ISO 9000. The paradigm accounts for the type and the nature of the data required in an integrated system and the way users in each domain interact with the data. New methods are proposed for building and maintaining design specifications, transferring them to the plant end user in a usable form and, managing ongoing changes in design parameters to ensure installed specifications are in synchronization with the design specifications. Copyright © 1996 Elsevier Science Ltd.

Keywords : Instrument design; Instrument maintenance; Instrument database management; Instrument reliability; Instrument documentation

1. Introduct ion

The evolution of instrument information and doc- umentation management in the chemical and process industries has been slow during the last 30 years. The volume and complexi ty of instrumentation infor- mation has continued to increase. The ability to maintain and access this type of information is be- coming increasingly difficult. The lack of a suitable holistic information model incorporating all aspects of instrumentation design and maintenance has pre- vented successful computerization of the process.

* Corresponding author. Tel.: + 1-310-640-0511 ; fax: + 1-310- 322-2076.

During this time very few computerized systems have been developed. Of the few that have appeared, each has focused on narrow aspects of " the big pic ture" .

The introduction of US legislation such as OSHA 1910.1 19 and European quality standards such as ISO 9000, require an approach to information and documentation management that accounts for the integrated nature of instrumentation systems.

OSHA specifies that we must know the parame- ters for the installed equipment and that those param- eters must match the design parameters. In addition, procedures must be in place for managing the change of design parameters and that these changes are subsequently reflected in the installation. It specifies that mechanical integrity of systems including instru-

0019-0578/96/$15.00 + 0.00 Copyright © 1996 Elsevier Science Ltd. All rights reserved. PII S0019-0578(96)00011-0

188 M. Spencer et al. l ISA Transactions 35 (1996) 187-195

mentation and control systems must be maintained in order to maintain a high standard of safety and reliability within the plant environment.

2. The new paradigm

In order to accommodate ongoing legislation and run our businesses in a more efficient manner an information model is required that will define " the big picture" . In other words, one that integrates the requirements of the engineering contractor, and the plant design, maintenance and reliability groups. The model identifies each group as a specific domain.The information model identifies the following elements as a basis for the new paradigm: • The number and type of interdependent domains. • The type and nature of data within a domain. • The flow of data within a domain. • The flow of data between domains. • The tasks performed on the data within a domain.

The paradigm introduces new methods for: • Building and maintaining design specifications. • Transferring them to the plant end user in a

usable form. • Managing ongoing changes to instrumentation and

control system design parameters. • Managing the installed base of instrumentation. • Ensuring installed specifications conform to the

design specifications.

The information model is illustrated by the dia- gram in Fig. 1 and shows the domains, the flow of data between each domain, and the relationship be- tween tasks and data for each domain. The model incorporates methodologies for improving the tasks required to create and maintain the data in each of the domains, and in addition, provides functionality that allows auditing and analysis of the data by reliability engineering.

3. Evaluating the paradigm shift

Whenever executing a paradigm shift from an old way to a new way of doings things, there is always apprehension, caution and a resistance to change. The benefits must be weighed against the risk of failure. In order to execute a successful shift, the potential stumbling blocks and risks must first be examined and accounted for through a careful evalu- ation process.

When evaluating any new or replacement instru- ment information or documentation management sys- tem you should ask whether the system will offer improvements to the way business is currently being done in your own business and can these benefits be transferred to the customer. No matter who you are or what job you have, you will have a product to deliver. You must first decide: What role you are playing; What your product is; Who your customers

ENGINEERING CONTRACTOR

DOMAIN

DESIGN ] TASKS

Data Flow

PROJECT DESIGN

DATA

Single Data File Multi User Access

PROJECT DELIVERABLES

PRE-EXISTING CONDITIONS

PLANT DOMAINS

DESIGN TASKS

Data l Flow

PLANT DESIGN

DATA

MAINTENANCE 1 TASKS J

I Data

Multi User Access |~llr Flow v Single Data File

MAINTENANCE ] DATA

Data Flow

Fig. 1. RELIABILITY 1~,~

TASKS J"~

Data Flow

M. Spencer et al./1SA Transactions 35 (1996) 187-195 189

are within your organization and outside of your organization; What your customers requirements are.

3.1. Will the new system offer me or my customer

any or all o f the fol lowing benefits?

• Economic benefits. • Safety benefits. • Environmental benefits.

Quality benefits.

3.2. What is the cost o f achieving these benefits with the new system and are there any immediate or ongoing costs beyond?

New, replacement or recurring software costs. Incremental costs of any new hardware. Costs to support the system in house. Costs of converting any existing data. Costs of compiling and reconciling existing data. Costs of training administrators and end users.

3.3. Questions that should be asked o f your organi- zation as an assurance as to whether the anticipated

benefits can be achieved and sustained

• Is the management infrastructure in place to sup- port the new system?

• Is the hardware infrastructure in place to support the new system?

• Is the end user knowledgeable enough to make best use of the new system?

• Can procedures be written to support the use of the new system?

• Will the procedures be followed? • Can the procedures be enforced? • Can you answer the question: " W h a t ' s in it for

me?" for each user of the new system.

3.4. Questions that should be asked o f your existing or planned company wide information management systems in order to avoid instrument data conflicts or redundancy

• Does an instrument design documentation system exist within the company?

• How is instrument design documentation originat-

ing from an engineering contractor integrated into company information systems? Does an instrument maintenance documentation system exist within the company? Does an instrument reliability information system exist within the company? Does any dynamic data relationship exist between any of these information systems? Do other information systems exist within the company that contain common instrument infor- mation? If so, what type of information systems are they? What is the purpose of each of these information systems? How is common instrument information kept cur- rent within each system, or is it? Which of these systems will the new system replace? Will I be able to keep the remaining information systems up to date with instrumentation changes originating from the new system? If it is possible to provide updates to other infor- mation systems, how can I be assured of the integrity of the updates on an ongoing basis?

3.5. Questions that should be asked o f the system developer as a fur ther assurance that the anticipated benefits can be achieved and sustained

Can the developer assure me that he understands: My business needs. My technical needs. The big picture. Can the developer assure me that the system is: Well documented and will continue to be. Well supported and will continue to be. Can the system offer: Multiple users access to the system simultane- ously. User configuration to suit my needs. Administrative control of instrumentation design and documentation standards. Administrative control of access privileges. Automatic data file back up. Transactional back-up of data. Data file reconstitution from transactional back ups. Audit trails.

190 M. Spencer et al. / ISA Transactions 35 (1996) 187-195

• On line help. In order to meet my future needs is the developer

prepared to: • Customize the system for me. • Allow me access to the source code for me to

customize. • Share development costs for any added function-

ality I might need.

4. The domains

Before implementing the model we must first identify each domain and understand their current paradigms. We then can be in a position to break- down the traditional technical and political informa- tion barriers that exist between each domain and begin the process of integrating the requirements of each domain into a centralized system. The domains are described as follows:

Engineering Design Contractor. Plant Engineering Design Group. Maintenance Group. Reliability Group. External Information Systems.

The owners of each domain, traditionally are respon- sible for the data associated with the work performed within their own domain. Each owner has a data product or "deliverable" that will be required by one or more of the other domains. The new paradigm ensures well defined deliverables and data compati- bility between each domain and is designed to allow each domain immediate access to information pre- sent in all other domains without fear of corruption.

The following sections contrast work methods and types of data used in the current and new paradigms for each domain. The new paradigm enforces the concept of project deliverables for each domain.

5. The engineering design contractor

Typically most engineering design contractors are reluctant to change the way they do business and have not made best use of emerging technologies. This situation needs to change due to the prolifera- tion of documentation and data required to support decisions and new government regulations.

Contractors still produce separate instrument in- dexes, data sheets, wiring details, DCS configuration

files and P & I D ' s as if they were separate entities. Many hours are spent trying to keep these documents in synchronization throughout a project. The intro- duction of the PC has resulted in these types of documents being translated to electronic format with very little integration. Although this may have im- proved things compared to using a pencil and paper it is still largely a facsimile of the paper system. The difference for the end user at best is that his project deliverables are in electronic format, but at what advantage to the end user if no mechanism exists to maintain each of the separate document types?

The contractor is responsible for ensuring that the specifications for equipment are properly docu- mented in a form that is not only usable to him during the project but is also usable to the customer in its final form. Unfortunately project deliverable format cannot normally be maintained when released into the plant environment. The contractor also has a responsibility to ensure that the data is prepared in an accurate, efficient and timely manner in that design methodology is continually improved to re- duce errors and reduce redundant or repetitive activi- ties or repeat work. Unfortunately the need to im- prove is not always internally recognized due to the " W e ' v e always done it this way" and "Innovation costs money" and " W h o ' s going to pay for it?" and " W h a t ' s in it for me'?" attitudes.

There is an increasing need to manage change in order to be more efficient and therefore more com- petitive. A solution to the above dilemmas requires an initiative on behalf of the engineering contractor to change the way he does business or an initiative on behalf of the customer to encourage that change. The customer can do this by promoting a spirit of co-operation to improve the way both parties do business and by: • Defining strict specifications for the engineering

contractors project deliverables. The project de- liverable format should match exactly the plant information systems' data requirements.

• Preparing a well defined scope of work for the engineering consultant in order that project deliv- erables can be measured against it during the project and upon completion. This will enable the identification of additional costs due to inefficien- cies in work methods.

• Promoting the use of an information management

M. Spencer et al. / 1SA Transactions 35 (1996) 187-195 191

system that can meet both parties requirements. Costs associated with this change can be more

than offset by the gains made over conventional methods. When evaluating any, new or replacement instrument design documentation management sys- tem the design contractor should ask whether the system is capable of: • Satisfying internal design documentation needs. • Satisfying the clients project deliverable require-

ments. • Increasing project deliverables quality.

Managing design changes. Improving design methods. Increasing design quality. Increasing designer efficiency. Increasing the integrity of design data. Reducing design man-hours. Reducing design costs to the client.

No system is perfect and the answers to these ques- tions when evaluating new or replacement systems, require that the engineer be fully cogniscent of the inadequacies of his existing system.

The usefulness of an information management system is dependent on how fast data can be entered and extracted from the system. The quality of the resident information is dependent upon the quality of the users, the quality of information being entered and the quality of the information management sys- tem. This can be vastly improved by eliminating redundant or double entry tasks. This can be achieved with a properly designed data base structure with suitable user interfaces. In order to evaluate the quality of the system it is recommended that it be inspected for at least the following characteristics.

5.1. Technology

• Platform independent. • Relational data base technology. • Client-Server technology. • Single centralized data file.

5.2. User interface

• Intuitive user interface. • Intuitive navigation system.

5.3. Management

Administrative control of user passwords and ac- cess privileges.

Management of tag numbers. Auditing. Management of tagging standards. Reservation of tag numbers per project. Powerful searching and sorting capabilities Management of loops and instruments per Pro- ject, System, P&ID. Management of instruments by loop and type. Propagation of calibrations between instruments in a loop. Multiple choice list library management. Report template library management.

5.4. Data ent~.

• Data sheet style data entry and editing. Spreadsheet style data entry and editing. User configurable data entry windows.

• Global data entry and editing. • Duplication of Loop and Instrument specifica-

tions. Multiple choice lists per data entry field.

• Data import and export with field matching.

5.5. Reporting

• Access to all data fields for reporting purposes. • User configurable lists and summary report tem-

plates. • User configurable data sheet templates. • User configurable print packages.

Auto-generation of loop check and calibration reports.

5.6. DCS design

• Auto-generation of DCS point tag configuration files.

• Management of instruments connected to the DCS.

• Management and generation of termination schedules.

5. 7. Drawings

• Auto-generation of Loop drawings. • Tag reconciliation with CAD P&ID.

The system would be expected to have specific design reporting capabilities such as:

192 M. Spencer et al. / I SA Transactions 35 (1996) 187 195

Journal reporting of data modifications, Instrument lists using any combination of data base fields as sort criteria. Loop data sheets configurable to suit specific design functions. Instrument data sheets configurable to suit spe- cific instruments and design functions. Design calibration schedules. Alarm and trip calibration schedules. DCS configuration files. DCS point assignment schedules. DCS termination schedules.

• Junction box and marshalling cabinet termination schedules. Loop calibration check data sheets.

• Loop drawings. Instrument installation schedules. This type of information can be regarded as the

project deliverables for: • The instrument designer for field survey and data

collection purposes. • The instrument designer for instrument design

purposes. • The instrument vendor for purchasing purposes. • The systems designer for DCS design purposes. • The installation contractor for installation and

commissioning purposes. • The final customer who in most cases would be

the plant engineering designs department respon- sible for the maintenance of the data upon accep- tance. Ideally it should be available in electronic format as one single integrated data file.

6. The plant design engineering group

The engineering department is responsible for the validity of designs either initiated from within the plant or accepted from engineering contractors. This group may also assume the role of the project engi- neering contractor in house. The group would also be responsible for management of the design documen- tation in order to keep it current and up to date at all times. If it can do this, then the maintenance depart- ment and other "need to know" groups will have a valid reference point at all times.

The current state of instrument design specifica- tions on most plants sadly does not reflect the way the plant is actually installed. This is ironic since the installed base should always mirror the design speci- fications not the other way round. The reason for this is that procedures for management of change are either not in place or they are not adhered to, nor is there a centralized point of reference for keeping the design documentation up to date. The design specifi- cations often sit on a shelf or in separate computer files. As the plant design changes the new set of documentation gets placed next to the old set (some- times). This results in multiple specifications for the same plant and it is not always apparent which is the most current. This situation reduces the integrity of the design data and is obviously unsatisfactory and is generally propagated each time a new project is completed when the design project deliverables are handed over to the plant. This happens whether its a small in house project, of which there are many or a large project engineered by a contractor. Project deliverables are generally accepted innocently with- out questioning their validity due to the volume or complexit3' of the documents. Errors and omissions only come to light some time later, during the main- tenance of the plant.

A solution to this situation requires that plant design engineering have a method of accepting, owning, maintaining and managing design docu- mentation for all approved designs.

To facilitate these requirements the system should have the following capabilities: • Management of change of instrumentation and

control systems. Management of the design records for all in- stalled control loops. Design department ownership of instrument de- sign specifications. Management of the design records for all "works in progress' '. Maintaining these records current and up to date at all times. Managing the transition between design and in- stallation. Managing the integration of project deliverables into the system. Extraction of data for project engineering pur- poses.

M. Spencer et a l . / ISA Transactions 35 (1996) 187-195 193

• Access by maintenance personnel for reference purpose only.

• Maintaining tag synchronization with the ap- proved P&ID tags.

• Maintaining tag synchronization with the installed DCS tags.

• Maintaining tag synchronization with other plant information systems. In addition the system should clearly differentiate

between: • Projects in the process of design and those al-

ready installed. • Design tag specifications for an instrument and

the specifications for the actual field instrument installed at that tag.

• Design tag specifications for a control function and the specifications for the actual control func- tion or point tag resident in the DCS system.

• The system should have specific reporting capa- bilities for plant engineering designers such as:

• Exception reporting between approved tags and P&ID tags.

• Exception reporting between approved tags and actual DCS tags.

• Exception reporting between approved tags and other plant systems.

• Reporting of spare tag numbers. • Reporting of tags in design. • Reporting of tags installed.

This type of reporting can be regarded as the project deliverables for: • The engineering contractor requiring current in-

stalled design data. • The plant DCS systems engineers requiring up-

dates on design changes. • The drafting and design department responsible

for P&ID maintenance. • The reliability engineering department responsi-

ble for ensuring the installed base of instruments matches the design requirements.

7. The plant maintenance group

The maintenance technician has very specific in- formation requirements and these are different from those of a engineering designer. Yet the maintenance technician needs the data produced by the designer

as reference material in order to perform his work to specification.

The failure in the past to clearly distinguish be- tween design and maintenance data requirements within a single information system is resulting in a separate evolution of computer programs for the engineering and maintenance environments.

This is being further confused due to the recent proliferation of maintenance oriented programs such as maintenance management systems (whose pri- mary focus is maintenance task management) and reliability programs (whose primary focus is reliabil- ity analysis). All of these types of specialized pro- grams will contain instrument data in some form. The questions will be: Which is the master source of data? How is this instrument information originated and where did it originate from? The new paradigm presents a solution with the centralization of design and maintenance data in a single controllable master system that other specialized systems (as described above) can reference.

In reality design and maintenance data cannot be separated since the design is always the reference for maintenance. Design is always subject to change particularly with instrumentation systems. Any de- sign changes need to be managed, accepted, and communicated to maintenance immediately.

Furthermore, documentation systems in the past have failed to recognize the existence of the control loop as an entity containing instruments that are connected or configured to work together as a group.

Instrument maintenance departments generally deal with the maintenance of hardware such as field instruments. Changes occurring to specifications for any component in the loop, including control func- tions resident on a computer, need to propagate to specification records for each of the connected com- ponents of the loop. Panel mounted tagged con- trollers, alarms and trip devices are being replaced by tagged control functions resident on DCS com- puter systems. The effect of this is to transfer the maintenance of these devices away from the mainte- nance department. This promotes a problem in that changes can occur outside of the design engineering and maintenance spheres of influence leading to data conflicts.

A solution to the above problem areas requires that the maintenance department have a method of

194 M. Spencer et al. /1SA Transactions 35 (1996) 187 195

owning, maintaining and managing records for in- stalled field instruments and be able to reference the design specifications for the respective tag position.

To facilitate these requirements, the system should have the following capabilities:

Management of the specification records for all installed instruments. Maintenance department ownership of installed instrument specifications. Maintaining these records current and up to date at all times. Managing the transitions of instruments between locations. Managing the repair history data for each instru- ment. Managing the calibration history data for each instrument. Managing the test equipment repair history data. Managing the test equipment calibration history data.

• Access to design engineering records for refer- ence purpose only. Extraction of maintenance data for project engi- neering purposes. To facilitate the above capabilities, the system

should have at least the following characteristics: Clear distinction between the design tag specifica- tions for an instrument and the specifications for the field instrument installed at that tag position. Unique identifiers for installed instruments. Unique identifiers for test equipment. Data entry for installed instrument specifications. Data entry for As Found-As Left calibrations. Data entry for instrument repair history reports. Data entry for test equipment calibration records. Reference to the tag design specifications and calibrations. Re-assignment of instruments to new tag posi- tions. Tracking of off line instruments. Tracking of instruments in and out of tag posi- tions. Tracking of demolished or out of service instru- ments. Export of design calibration data to calibration devices. Import of As Found-As Left calibration data from calibration devices.

The system should have specific maintenance report- ing capabilities such as: • Instrument lists using any combination of data

base fields as sort criteria. • Loop data sheets configured to suit specific main-

tenance functions. • Instrument data sheets configured to suit specific

maintenance functions. • Inspection forms configured to suit specific main-

tenance functions. • Scheduled instrument maintenance reports.

As Found-As Left calibration reports. Alarm and trip test schedule reports. Instrument repair history reports. Test equipment calibration records. DCS Wiring and termination schedules. Loop drawings. This type of information can be regarded as the

project deliverables for: • The instrument mechanic or technician responsi-

ble for the maintenance of instrumentation. This information would normally be in printed format for the technician to reference while fixing the instrumentation and subsequently mark-up for data entry.

• The reliability engineering department responsi- ble for ensuring the performance of the installed base of instruments matches the design require- ments.

8. The plant reliability group

The introduction of OSHA 1910. and its mechani- cal integrity, environmental, safety and reliability requirements has created the need for a reliability department. As a consequence of this, added eco- nomic benefits can be gained which otherwise would not have been realized.

The reliability departments responsibilities are for checking the installed system performance against the design parameters, analyzing, reconciling and implementing methods for correcting the differences.

The first question that needs to be asked is, does the installation reflect what the design specifies'? To answer this question we need to know: • What are the design specifications for the control

loop and its associated instruments and DCS con- trol functions'?

3/1. Spencer et al. l I S A Transactions 35 (1996) 187-195 195

CENTRALIZED DATA BASE

I INSTRUMENT 1 I INSTALLED 1 DESIGN DATA INSTRUMENT DATA

( ..OAOD,T ) ( TAOAOO,T ) ( TAOAOO,T )

PglD MAINTENANCE DRAWINGS DCS SYSTEM MANAGEMENT SYSTEMS

Fig. 2.

What are the actual specifications for the installed control loop and its associated instruments and DCS control functions?

• Whether the installed specifications for a control loop match the design specifications for that con- trol loop?

• Whether the installed specifications for the in- stalled instruments in the loop match the design specifications for the instruments in that loop?

Without a centralized data base of reliable informa- tion containing design data (resulting from a project or "management of change" process) integrated with maintenance data, it would be almost impossible to answer these questions.

The system should be equipped with a method of auditing actual installed equipment tags and specifi- cations against the approved design as shown in Fig. 2.

The auditing and checking process requires that tags and other related information resident on the P&ID's , in the DCS and in other systems such as a task based maintenance management system are in synchronization with the tags in the master instru- ment data base. The auditing and checking process can be automated and built into the system.

Once the credibility of the information has been established through the auditing and checking pro- cess he will be in a position to analyze the: • Performance history of the installed loop over a

period of time. • Performance history of the installed instruments

in the loop over a period of time.

To provide this degree of analysis the system will be required to: • Trend repair histories of installed loops and in-

struments against design parameters. • Trend calibration histories of installed loops and

instruments against design parameters. • Provide various statistics on the performance of

installed instruments. • Provide various statistics on differences between

design and installed specifications. Provide specific reliability analysis functionality tools. Given this type of functionality, the system should

help to answer the following questions: • What instruments have failed and why?

What instruments are the worst actors and why? What instruments or systems contribute to safety violations and why? What instruments or systems contribute to eco- nomic losses and why? What instruments or systems contribute to envi- ronmental violations and why? What is the failure rate for a given instrument type in a particular service? What is the failure rate for critical systems, loops and instruments? The answers to these questions are the essence of

any reliability program and will provide the informa- tion necessary for improving future engineering de- signs and maintenance activities. This type of infor- mation can be regarded as project deliverables for:

Plant engineering department for the purpose of improving designs. Maintenance department for the purpose of im- proving maintenance. Technical department for the purpose of improv- ing plant standards. It becomes apparent that if you do not have

credible reliable data as a basis for reliability analy- sis, any conclusions drawn from such an analysis will be unfounded and likely be meaningless. A reliability system cannot stand on its own. Any such system will require management and controls on the data originating from designs and maintenance. This adds further credence to the need for the centralized integrated system proposed by this paper.