api rp 557 guide to advanced control system

Guide To Advanced Control Systems

API RECOMMENDED PRACTICE 557FIRST EDITION, DECEMBER 2000

COPYRIGHT 2003; American Petroleum Institute

Document provided by IHS Licensee=Technip Abu Dabhi/5931917101, User=, 11/30/2003 04:39:23 MST Questions or comments about this message: please callthe Document Policy Group at 1-800-451-1584.

--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---

Guide To Advanced ControlSystems

Downstream Segment

API RECOMMENDED PRACTICE 557FIRST EDITION, DECEMBER 2000



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---

SPECIAL NOTES

API publications necessarily address problems of a general nature. With respect to partic-ular circumstances, local, state, and federal laws and regulations should be reviewed.

API is not undertaking to meet the duties of employers, manufacturers, or suppliers towarn and properly train and equip their employees, and others exposed, concerning healthand safety risks and precautions, nor undertaking their obligations under local, state, or fed-eral laws.

Information concerning safety and health risks and proper precautions with respect to par-ticular materials and conditions should be obtained from the employer, the manufacturer orsupplier of that material, or the material safety data sheet.

Nothing contained in any API publication is to be construed as granting any right, byimplication or otherwise, for the manufacture, sale, or use of any method, apparatus, or prod-uct covered by letters patent. Neither should anything contained in the publication be con-strued as insuring anyone against liability for infringement of letters patent.

Generally, API standards are reviewed and revised, reafÞrmed, or withdrawn at least everyÞve years. Sometimes a one-time extension of up to two years will be added to this reviewcycle. This publication will no longer be in effect Þve years after its publication date as anoperative API standard or, where an extension has been granted, upon republication. Statusof the publication can be ascertained from the API Standardization Manager [telephone(202) 682-8000]. A catalog of API publications and materials is published annually andupdated quarterly by API, 1220 L Street, N.W., Washington, D.C. 20005.

This document was produced under API standardization procedures that ensure appropri-ate notiÞcation and participation in the developmental process and is designated as an APIstandard. Questions concerning the interpretation of the content of this standard or com-ments and questions concerning the procedures under which this standard was developedshould be directed in writing to the API Standardization Manager, American Petroleum Insti-tute, 1220 L Street, N.W., Washington, D.C. 20005. Requests for permission to reproduce ortranslate all or any part of the material published herein should also be addressed to the gen-eral manager.

API standards are published to facilitate the broad availability of proven, sound engineer-ing and operating practices. These standards are not intended to obviate the need for apply-ing sound engineering judgment regarding when and where these standards should beutilized. The formulation and publication of API standards is not intended in any way toinhibit anyone from using any other practices.

Any manufacturer marking equipment or materials in conformance with the markingrequirements of an API standard is solely responsible for complying with all the applicablerequirements of that standard. API does not represent, warrant, or guarantee that such prod-ucts do in fact conform to the applicable API standard.

All rights reserved. No part of this work may be reproduced, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise,

without prior written permission from the publisher. Contact the Publisher, API Publishing Services, 1220 L Street, N.W., Washington, D.C. 20005.

Copyright © 2000American Petroleum Institute



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---

FOREWORD

API publications may be used by anyone desiring to do so. Every effort has been made bythe Institute to assure the accuracy and reliability of the data contained in them; however, theInstitute makes no representation, warranty, or guarantee in connection with this publicationand hereby expressly disclaims any liability or responsibility for loss or damage resultingfrom its use or for the violation of any federal, state, or municipal regulation with which thispublication may conßict.

Suggested revisions are invited and should be submitted to the API Standardization Man-ager, American Petroleum Institute, 1220 L Street, N.W., Washington, D.C. 20005.

iii



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---

CONTENTS

Page

1 GENERAL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 DeÞnitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 CONTROL SYSTEM FUNCTIONS AND TYPES . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1 Regulatory Control System Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Model-Based Control Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.3 Optimizers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.4 Expert Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.5 Fuzzy Logic Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.6 Batch and Sequence Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.7 Blending Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.8 Oil Movement Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 OPPORTUNITY IDENTIFICATION AND JUSTIFICATION . . . . . . . . . . . . . . . . . . 63.1 Resource Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.2 The Economic Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.3 IdentiÞcation of Potential Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.4 IdentiÞcation and QuantiÞcation of BeneÞtsÑFeasibility Study. . . . . . . . . . . . . 7

4 ADVANCED CONTROL PROJECTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.1 Master Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2 Project Execution Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.3 Implementation Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.4 Personnel Commitments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.5 Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.6 Application Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5 TECHNOLOGY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.1 Hardware Platform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.2 Software Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6 DESIGN CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196.1 General Design Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196.2 Plant Data Collection for Application Design. . . . . . . . . . . . . . . . . . . . . . . . . . . 206.3 Functional Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216.4 Manipulated Variable Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236.5 Operator Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.6 Application Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.7 Engineering Graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.8 Performance Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

7 APPLICATION MAINTENANCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267.1 Personnel Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277.2 Continuing Training. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277.3 Change Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277.4 Performance Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287.5 Documentation Maintenance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

v



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---

CONTENTS

Page

Figures1.1 ReÞnery Operation Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.1 Control and Automation Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Operating Conditions versus Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.1 Improvements from Reduced Variability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106.1 Advanced Control System/Regulatory Control System Interface . . . . . . . . . . . . . 24

Tables3.1 Advanced Control BeneÞts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2 BeneÞt Feasibility Study Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.1 Typical Advanced Control Project Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2 Advanced Control System Training Program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---

1

Guide To Advanced Control Systems

1 General

1.1 INTRODUCTION

This recommended practice addresses the implementationand ownership of advanced control systems for reÞnery pur-poses. The major sections of this recommended practice aredescribed below.

Figure 1.1 illustrates the major functions involved in theefÞcient and economic operation of a reÞnery and showswhere advanced control Þts into this scheme. Advanced con-trol systems form a fundamental building block on whichmany of the other functions depend.

1.2 SCOPE

This recommended practice describes commonly usedpractices for the opportunity identiÞcation, justiÞcation,project management, implementation and maintenance ofadvanced control system applications in reÞnery services.This practice is not intended to specify the use or selection ofany particular technique over another, nor is intended todescribe speciÞc applications. It may be used as the basis fordeÞning the work processes and common functions requiredto deÞne, implement and maintain advanced control systemapplications.

The practices described in this document are applicable toall advanced control system applications. Users who areexperienced in advanced control may have developed theirown equivalent practices. This document is not intended tosupersede user practices that have been found to be accept-able or to require that the practices described in this documentbe followed if they are not appropriate to the circumstance.

Selection of a speciÞc hardware platform, software plat-form or application software is not within the scope of thisrecommended practice.

1.2.1 Control Systems Functions and Types

The functions and characteristics of commonly usedadvanced control systems applications are described in Sec-tion 2.

1.2.2 Opportunity Identification and Justification

General procedures for identiÞcation of advanced controlsystems applications which may provide economic or opera-tional beneÞt to a facility are described in Section 3.

1.2.3 Advanced Control Projects

General concepts for planning and management of anadvanced control project are described in Section 4.

1.2.4 Technology Considerations

The technical issues that should be considered in selectingadvanced control system hardware and software are describedin Section 5.

1.2.5 Design Considerations

Application design features needed to support controlfunctions, operator interfaces and engineer interfaces aredescribed in Section 6.

1.2.6 Application Maintenance

Ongoing maintenance recommended practices foradvanced control system applications are described inSection 7.

1.3 DEFINITIONS

The following are deÞnitions of terms used in this recom-mended practice. Also refer to API RP 554 for deÞnitions ofrelated terms.

1.3.1 Personnel

1.3.1.1 advanced control engineering specialist:

An individual trained and experienced in the design andimplementation of advanced control systems. This individualis knowledgeable in process engineering, process control the-ory and application and computer applications. An advancedcontrol engineering specialist may be an employee of a reÞn-ing company, an employee of a control systems manufactureror consultant, an independent consultant or other contractor.

1.3.1.2 advanced control support specialist:

Anindividual charged with monitoring and maintaining an exist-ing advanced control application. This individual may be aunit process engineer, a plant control system engineer or otherindividual who is knowledgeable in the speciÞc application.

1.3.1.3 advanced control user:

An individual who isthe ultimate user of an advanced control system application.This individual may be a process operator or an engineercharged with operation of the advanced control system appli-cation.

1.3.1.4 operator:

A person or persons that is responsiblefor day-to-day operation of a process unit and its advancedcontrol applications.

1.3.1.5 project engineer:

An individual responsible forthe execution of an advanced control project. This individualmay have a variety of responsibilities depending on the natureand scope of a particular project. Primary among these is



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---

2 API R

ECOMMENDED

P

RACTICE

557

management of the project resources, budget and schedule.On smaller projects, an advanced control engineering special-ist may also perform the duties of the project engineer.

1.3.1.6 unit engineer:

An engineer charged with engi-neering tasks directly associated with the day to day opera-tion of a process unit or area. In some cases, this engineermay also be assigned the duties of an advanced control sup-port specialist.

1.3.2 Controller Types

1.3.2.1 advanced control system application:

Anycontrol system application that has functions beyond thosecommonly associated with regulatory control systems. Anadvanced control systems application may be characterizedby any of the following:

a. A control system that controls or manipulates multiplevariables in order to maintain one or more operatingobjectives.b. A control system that performs calculations beyond thosethat could normally be performed using standard algorithmsavailable in DCS systems or multi-loop controllers.c. A control system that may utilize a signiÞcant numberof DCS standard algorithms connected together in a com-plex manner.d. A control system that is executed in a higher level comput-ing resource such as a process control computer orimplemented in a programming environment at lower controllevels, irrespective of the complexity of the computations.

These types of applications are referred to by terms such asadvanced process control (APC), model based predictive con-trol (MPC), matrix control, multivariable control (MVC) etc.

1.3.2.2 controller:

The collection of functions associatedwith either a regulatory control system or an advanced controlsystem. In the context of this document, controller used with-out any other description is intended to mean an advancedcontrol system.

1.3.2.3 manufacturing execution system:

An appli-cation that is directed towards management of manufacturingoperations. This includes issues such as manufacturing sched-uling, raw material management and resource planning.

1.3.2.4 optimization:

A process control function thatdetermines the operating conditions that maximize the eco-nomic beneÞt of an operation within a set of constraints. Anoptimization scheme may address any number of objectivessuch as maximization of a particular product stream, minimi-zation of operating cost or maximization of an equipmentitemÕs operating life. Typically optimization programs areexecuted at a frequency of hours to days and can take a fewminutes to an hour to run.

1.3.2.5 multivariable control:

A form of an advancedcontrol system application in which several control variablesare maintained at desired values through a complex relation-ship. Several manipulated variables may be adjusted simulta-neously in order to maintain an economic or other operatingobjective. Multivariable controllers typically execute at a fre-quency of one to Þve minutes.

Figure 1.1—Refinery Operation Functions

Product, intermediate and raw material planning and operating objectives

Multi plant integration

Advanced control systems

Process historian

Yield accounting and process analysis

Blend property control and storage management

Blending and oil movementsRegulatory control system

Field measurements, control elements and communications

Operation planning and optimizationon-line optimization

Maintenance,engineering and

administration

Corporate management/Enterprise resource planning systems

Facility management



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---

G

UIDE

TO

A

DVANCED

C

ONTROL

S

YSTEMS

3

1.3.2.6 regulatory control:

A control application inwhich generally one controlled variable is maintained at adesired value by manipulation of one manipulated vari-able. Regulatory control may also include control applica-tions that utilize common calculations or predictions.Examples are steam drum level controls, combustion con-trols or mass ßow calculations.

1.3.3 Controller Terminology

1.3.3.1 advanced control system:

The combinationof the hardware platform, software platform and applica-tion software necessary to implement an advanced controlsystem application.

1.3.3.2 automatic shedding:

A function by which anadvanced control system application fully or partially turnsoff and control is returned to the regulatory control scheme.This may be a result of invalid input values, inability todeliver controller outputs or inability of the controller to meetits objectives.

1.3.3.3 constraints:

Limits in the process or equipmentthat should not be exceeded. Constraints may take the form ofphysical limits such as a design temperature or pressure orother pre-deÞned process limits such as a maximum feed rate,composition or other value. Constraints may be either maxi-mum values or minimum values such as ßow pressure, tem-perature or process stream qualities.

1.3.3.4 controlled variables:

Process values that aremaintained by the control system by making appropriateadjustments to manipulated variables.

1.3.3.5 disturbance variables:

Process input valuesassociated with an advanced control system application thatare measured but are not controlled by the application. Anadvanced control system application often takes controlactions to maintain the control objectives when disturbancevariables change. Examples are ambient temperature, feedfrom another unit, etc.

1.3.3.6 linear programming:

An algebraic computa-tion optimization technique that uses two or more linearequations that relate process or economic variables. Thelinear program solves the relationship to maximize or min-imize the objective function that is usually an economicmeasure of operating efÞciency.

1.3.3.7 manipulated variables:

Process values that areadjusted by the advanced control system application to meetoperating targets and desired values of controlled variables.

1.3.3.8 process variable:

An indication of processperformance, which are directly measured using instru-mentation sensors and transmitters, values that are com-puted from these variables or values obtained fromlaboratory testing or other techniques.

1.3.3.9 service factor:

A measure of the effectiveness ofan advanced control system application. It is more than ameasure of whether the application is on or off. This usuallyis a complex calculation that is based on the numbers andtypes of subfunctions within an application, the percentage oftime that the functions are operating and the relative eco-nomic weighting of each subfunction.

2 Control System Functions and Types

This section describes functions common to advanced con-trol system applications and related systems. Figure 2.1 illus-trates basic control system functions and how they relate tothis and other recommended practices.

2.1 REGULATORY CONTROL SYSTEM FUNCTIONS

Regulatory control systems provide fundamental control ofprocess variables such as pressure, temperature, ßow, andlevel by manipulating Þnal control elements such as controlvalves or electric motors. The standard control algorithm usedin these systems is proportional-integral-derivative (PID),although alternate algorithms and calculations may also beused. The functions of regulatory control systems are coveredin API RP 554.

Complex regulatory control systems typically combine anumber of functions used in regulatory control systems tomeet a control objective. Typical applications include:

¥ Cascade control¥ Dynamic compensation, e.g., Þltering or time-shifting

of variables¥ Variable gain adaptive controllers or other non-linear

algorithms¥ Calculated variables such as pressure and temperature

compensation of ßow or other simple computations¥ Override control using output selectors¥ Ratio controllersThe regulatory control system must be conÞgured to allow

remote access to its setpoints so the advanced control systemcan write to them. It must also have a mechanism to automat-ically disable these remote setpoints or go to a pre-deter-mined status if the advanced control system has failed.

2.2 MODEL-BASED CONTROL SYSTEMS

Model-based control systems use a mathematical model ofthe process to improve process performance. The model maybe based on process engineering principles or may be aredescribed below.

2.2.1 First Principle Model-Based Advanced Control Systems

First principle models are derived from the fundamentalmass and energy balances, and associated thermodynamics,



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---

4 API R

ECOMMENDED

P

RACTICE

557

equilibrium and reaction kinetic relationships. These modelscan be used to improve control system accuracy or rangewhen the characteristics of the process are well understood.Typical applications are:

¥ Computation of heat and material balances or reactoryields and conversions

¥ Computation of inferred process variables that are notmeasured

¥ Improvement of control system operating range byincluding non-linear effects

First principal models typically are steady state relation-ships and become difÞcult to apply in processes that exhibitcomplex or variable dynamic behavior.

2.2.2 System Response Based Advanced Control Systems

System response models are based on observations ofactual system dynamic performance. They are usually appliedwhen a process is too complex to use Þrst principal models orwhen multiple interacting variables must be controlled. Com-mon characteristics are:

a. The control system is capable of performing multivariablecontrol.

b. The model is generally used to predict the effects of con-trol moves and determine the proper actions.c. The controller handles constraints.d. The controller can optimize performance within the deÞni-tions available in the process model.

The system model allows the controllers to relate multiplemanipulated variables (MVs) which the controller adjusts andmultiple disturbance variables (DVs) which the controllercannot adjust to multiple control variables (CVs). It simulta-neously adjusts all MVÕs to drive all CVÕs to their ÒbestÓoperating points.

The process models determine the ÒbestÓ operatingpoint based on user-deÞned constraints and process eco-nomic information. Typically, the best operating point iswhere the maximum number of system constraints possi-ble is reached. Figure 2.2 shows the general relationshipsof operating points and constraints. This is a simpliÞedpresentation, as in most real applications, multiple operat-ing values and constraints exist.

2.2.2.1 Multivariable, Matrix Based Systems

These systems use empirical models obtained by testing theprocess to identify its characteristics and interrelationships.

Figure 2.1—Control and Automation Functions

Plant wide planning and optimization

Plant business network

Unit optimizers

Plant control network – RP 554

Advanced control systems – RP 557Blend

property controls

Tank gauge and valve comm

Tank gauges, sensors, valves and actuators

Blending flow meters and controllers

Safety and logic sensors, transmitters valves

and actuators

Analyzers – RP 555

Valves and actuators –

RP 553

Sensors and transmitters –

RP 551

Regulatory control systems –

RP 554

Process interlocks –

RP 554

Safety and protective systems – ANSI/ISA S84.01/RP 554

Blending and oil movement controls

Process transmission systems – RP 552

Process historian –

RP 554

Human interface –

RP 554

Alarm & abnormal situation mgmt. –

RP 554

Environmental monitoring and

reporting

Lab operations and data

management



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---

G

UIDE

TO

A

DVANCED

C

ONTROL

S

YSTEMS

5

Matrix controllers use linear models to relate MVs and DVs toCVs. They may also incorporate transformations of inputs andoutputs to handle process nonlinearities. Some versions ofthese controllers have been extended to use non-linear models.These controllers have been used in the reÞning industry forseveral years and have evolved considerably.

2.2.2.2 Neural Net Systems

Neural networks are capable of providing similar function-ality as matrix controllers. The fundamental differencebetween neural net and matrix controllers is a learning enginethat develops the process model based on observations. Thelearning engine behaves somewhat like an optimizer thatcombines observations and user-supplied rules to generate aprocess model.

Neural net controllers require substantial historical datafrom which the model is created. If such data is not available,an extended data acquisition period may be required. In someapplications step testing is done to ÒtrainÓ the neural net.

Neural net controllers can produce non-linear models andcan adapt the model to process changes without requiring for-mal process testing. Typically, these adaptations are per-formed off-line using parameters generated by the on-lineneural net application.

Neural net controllers are a recent development and do notyet have the same experience or success base as matrix-basedcontrollers.

2.3 OPTIMIZERS

Optimizers provide a computation method to determine theÒbestÓ operating point based on user-deÞned economic objec-tives and a model of the process. The outputs of optimizersare usually steady state objectives for other controllers suchas multivariable controllers that handle dynamic control.

Optimizers may operate in an off-line or on-line mode. Inthe off-line mode the model is not receiving dynamic datafrom the process. In the on-line mode key real-time processdata is connected to the model.

An on-line mode application may be on-line open loop oron-line closed loop. In on-line closed-loop mode the outputsare automatically passed to the dynamic controls. In on-lineopen-loop mode, the optimizer outputs are presented to theoperator, and the operator is responsible for passing changesto the dynamic control.

In on-line applications, signiÞcant data validation and rec-onciliation are necessary. It may also be necessary that steadyoperations exist when the optimizer is run. Some more pow-erful optimizers may not require this.

2.3.1 Imbedded Linear Programs

Many multi-variable controllers contain an imbedded lin-ear program to solve an optimization problem. The imbeddedLPs are based on linear relationships between CVs and costs.Typically, these applications address a small number of pro-cess variables, usually less than 20 variables.

Figure 2.2—Operating Conditions versus Constraints



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---

6 API R

ECOMMENDED

P

RACTICE

557

2.3.2 Unit Level On-Line Optimizers

Unit level optimizers may be used to compute operatingtargets for one or more unit multi-variable controllers. Theseoptimizers typically use a much larger number of variablesand may have thermodynamic, equilibrium or kinetic rela-tionships built into them. They usually require functions fordata validation, reconciliation and parameter estimation. Unitlevel optimizers typically are able to access economic datafrom external sources. Unit optimizers may use more rigor-ous non-linear models to identify optimum operating condi-tions for the overall unit.

2.3.3 Plant Wide Optimizers

Linking several unit level optimizers allows the system tolocate a global optimum for the entire plant. In practice this isan extremely complex undertaking. This type of optimizationrequires rigorous models to ensure accurate results. Data rec-onciliation with overall material balances and yield account-ing systems is a critical requirement for plant leveloptimizers. For example, as the product slate from one unit isthe feed to the next, a small error introduced due to a poormodel or conßicting data will propagate throughout the entireoptimizer, which can provide an inferior result.

Use of these optimizers has often been limited by the accu-racy of the unit optimizers when applied to very large systems.The computing load for these optimizers and the volume ofinput data can be immense. Some success has been obtainedusing off-line linear program models of a number of plants.

2.4 EXPERT SYSTEMS

Rule based systems are used in reÞnery applications wherepredetermined events exist. They are well suited for providingdetailed information to operations based on events that haveoccurred in the process. Typically, these systems are used inan advisory capacity and are not directly connected to a con-trol system. Abnormal Situation Management is an emergingapplication of expert systems.

2.5 FUZZY LOGIC SYSTEMS

Fuzzy logic is used when the rules followed are inexact. Itis a technique which can transform graded or qualiÞed rules,such as if a Òtemperature gets too hot then slowly increase thecooling waterÓ, into speciÞc actions. Fuzzy controllers are adeveloping technology in the process industries. Fuzzy con-trollers may be imbedded in equipment controllers providedwith packages. Some DCS systems provide fuzzy controlblocks as part of their algorithm set.

2.6 BATCH AND SEQUENCE SYSTEMS

These control strategies are used for operations that haveÞnite steps executed in a predetermined order. Examples arereformer regeneration, water treating, coke handling, etc.These operations are described in detail in ISA S88.01 andare not within the scope of this recommended practice.

2.7 BLENDING SYSTEMS

Component blending is used in various fuel productioncomplexes. These systems are comprised of blend ratio regu-latory control elements, property estimators and optimizersthat adjust recipes to meet Þnal property speciÞcations. Thecontrol systems used include advanced strategies as describedin this document, but blending practices are not within thescope of this recommended practice.

2.8 OIL MOVEMENT SYSTEMS

Oil movement systems use heuristic rule-based systemsand are not within the scope of this recommended practice.

3 Opportunity Identification and Justification

3.1 RESOURCE REQUIREMENTS

The identiÞcation of improved control opportunities is amulti-disciplinary task with operations planning, operations,process and control application knowledge and experienceplaying the most signiÞcant roles. ReÞnersÕ experiences havedemonstrated that the essential element of success in imple-menting advanced control projects is the engineersÕ knowl-edge, experience and ability. While appropriate technology isan important factor, it cannot make up for lack of skill orexperience in the personnel implementing the application.

A beneÞts feasibility study for a single process advancedcontrol application can be handled by a suitably skilled indi-vidual relying on specialist support where required. However,as the scope of the study increases, particularly when study-ing a complete reÞnery, a small mixed discipline teamapproach is recommended. The team should include repre-sentation from site process/planning, operations and controlsystem engineering.

BeneÞt identiÞcation requires both technical and inter-per-sonal communication skills. IdentiÞcation and realization ofbeneÞts requires:

a. Understanding the economic driving forces for theprocesses.b. Understanding how the processes work and interact.c. Understanding the processÕs real limitations and con-straints .d. Obtaining buy-in for the beneÞts and solutions from theadvanced control users and support specialists.

3.2 THE ECONOMIC DRIVERS

Long and short-range business plans should be thebasis for evaluating potential beneÞts. These plans mustreßect the impact of a number of typical economic driv-ers. Not all of them will be applicable to a particular mar-ket or reÞnery, but they are indicative of the forces that



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---

G

UIDE

TO

A

DVANCED

C

ONTROL

S

YSTEMS

7

determine reÞning economics. Examples of economicdrivers that must be considered are:

Business Management Drivers

¥ Financial objectives ¥ Environmental and safety objectives¥ Process unit turnaround schedules

Local Plant Drivers

¥ Crude and other feed stocks and Þnished product pricing¥ Volume and shipping methods for crude and other feed

stock¥ Demand and shipping method of Þnished products ¥ Product margins¥ Utility usage and prices

Local Economy Issues

¥ Seasonal variations in product demand, quality andsupply

¥ The economy in which the plant operates, e.g., open orclosed market economic operation

¥ Government inßuence and requirements

3.3 IDENTIFICATION OF POTENTIAL APPLICATIONS

Most opportunities are identiÞed during discussions withsite personnel from the process, planning and operationsfunctions and a preliminary assessment of the process perfor-mance data. The following are useful guidelines for this pre-liminary assessment:

a. Review actual plant performance against production/oper-ating targets.b. Review plant performance against best of class or otherbenchmarks.c. Review the economic drivers added value potentials.d. Consider any anticipated process plant changes.e. Identify improvements that have been realized by existingadvanced control system applications.f. Identify opportunities for control improvements using rig-orous plant steady state models that have been tuned tocorrelate with actual plant data.

A number of improvement areas which may be consideredare listed in Table 3.1.

The outcome of this preliminary assessment is a list ofpotential applications and their beneÞts. This list should bereviewed with appropriate personnel to rank the potentialbeneÞts and identify those which appear to have high poten-tial and which should be further studied.

3.4 IDENTIFICATION AND QUANTIFICATION OF BENEFITS—FEASIBILITY STUDY

Each of the top ranked items identiÞed from examinationof the potential beneÞts should be considered in detail. The

overall methodology is outlined in Table 3.2. For existingplants, data can be obtained based on observed operation. Fornew plants, these data could be obtained from assessment ofequivalent data from similar operations or process models.

3.4.1 Application Objectives

The Þrst step in the feasibility study is to identify theobjectives of the proposed control application. This can beachieved though a series of discussions with the site represen-tatives from the planning, technical and operations functions.It is important that process constraints/limits and productiontargets/speciÞcations are examined and challenged. IdentiÞedconstraints should be considered for testing and data collec-tion, as they may be perceived rather than real.

It is also important to identify the effects that proposedcontrol improvements may have on other units or utilities. Forexample, an increase in an intermediate product stream ratemay exceed the capabilities of downstream equipment. How-ever, the beneÞts of selling any excess intermediate should beconsidered.

3.4.2 Data Collection and Validation

3.4.2.1 Data Requirements

The objective of this step is to identify all the necessarydata and information which will quantify the actual perfor-mance of the process relative to its operating targets and thecontrol objectives.

The following types of data should be collected in sufÞ-cient quantity to be statistically signiÞcant and consistent:

a. Operating targetsÑsuch as product qualities, rates, yields.b. Actual values achievedÑfeed and product rates, yieldsand laboratory and on-line analyzer results.c. Process operating constraints and limits, reasons and val-uesÑthis could include throughputs; pressure/ ßow/temperature limits, valve position and equipment capacitylimits, limitations imposed by other processes or planningrestrictions, environmental restrictions or safety restrictions. d. Availability of process (stream days) and reasons for out-ages or restricted operation.e. Measurement availabilityÑanalyzers, ßows, etc., includ-ing accuracy, repeatability and reliability.f. Discrete events such as coke drum sequencing, dryerswitches, etc.g. Control system performance indicators such as poorly per-forming control loops, control valves, etc. h. Future plans and timing for process modiÞcations andtheir potential impact.i. Production operating target changes which may beplanned.j. Future operational ßexibility requirements.k. Economic driver data and long-term plan. See Section 3.2.



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---

8 API R

ECOMMENDED

P

RACTICE

557

Assumptions will have to be made where necessary dataand information are unavailable. Assumptions relative tomissing data and the impact on the conÞdence of eco-nomic predictions should be discussed with and acceptedby site personnel.

3.4.2.2 Representative Period of Operation

It is important that one or more representative periods ofoperation be selected and agreed on as the basis for beneÞtidentiÞcation. These should reßect ÔnormalÕ operation of theprocessÐno shutdowns, processing deÞciencies nor unusualplanning/production requirements. Any variation due toweather or day/night operation should be included. Onemonth minimum is recommended, particularly when infre-quent (once per day) laboratory data will be used in the analy-sis. The data analyzed must be statistically signiÞcant andconsistent.

Data from several periods during the operational run of aunit may be required. This will account for effects such asseasonal changes to plans and targets, ambient conditions orstart-of-run to end-of-run conditions that may have a signiÞ-cant impact on potential beneÞts.

The representative period(s) will be used for pro-rating thepotential beneÞt to an annual basis using an agreed on streamdays per year. Stream days vary between processes and sites.Three-hundred-and-Þfty stream days per year are often usedas a default when no speciÞc information is available.

Failure to identify and agree on realistic representativeperiods can lead to misleading and erroneous beneÞt pre-dictions. For example, the actual and audited beneÞts of acrude unit application were $900,000 for the summermonths and only $100,000 for the winter months. Theoriginal feasibility study had been based on summer oper-ation only ($1.8MM/year). BeneÞts were therefore over-predicted by $800,000 per year.

Table 3.1—Advanced Control Benefits

Improvement Area Potential BeneÞts

Yield Product upgradingReduced variabilityReduced quality give-away on intermediate or Þnal productControl closer to targets

Stability Reduced product downgradingReduced energy usageProduction closer to constraints for better control

Throughput Higher production by better operation against process equipment constraints and limits such as:Tray vapor/liquid loadingCondenser/reboiler dutyPump/control valve capacityHeater/vessel temperaturesPressures/ßows/levelsCompressor parametersMinimization of unwanted material in feedstock (i.e. nC4 in alkylation feed)

Reactors Improved reactor performance by better control of: Weighted average inlet temperature Weighted average bed temperature Hydrogen to feed/recycle Reactant and other key process variables

Energy Usage Reduce total energy costs by better control of: Reßux ratios Pressure minimization, Reduced stripping steam Pumparound heat recovery

Heaters Improved efÞciency of heater operation through: Swing fuel Þring control to maximize usage of lower value or variable fuel Injection steam ratio control where appropriate Multi-user control strategy (i.e., Hot Oil Systems) Pass outlet temperature balance control

Miscellaneous Enhanced understanding of the process for better management of all site functionsImproved equipment reliability due to more stable operation at intended conditionsSharing of best practices from other applications



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---

G

UIDE

TO

A

DVANCED

C

ONTROL

S

YSTEMS

9

3.4.2.3 Performance Data Validation

Collected data must be validated before it is used inbeneÞts computations. Typical steps taken to validate thedata include:

a. Filter out any obvious bad process data, including datafrom identiÞed Ônon-normalÕ operation in the representativeperiod(s).

b. Carry out a simple statistical mean and standard deviationanalysis of the absolute actual values of targets and con-straints as appropriate.

c. Compare to site-wide data reconciliation.

Note: Frequently the statistics vary as a function of the targets setand often reßect the non-linear response of the process. In thesecases, it is more meaningful to perform the statistical average andstandard deviation on the difference between the target and actualvalues and to calculate a time weighted average for the actual value.

3.4.3 Control Improvement Prediction

3.4.3.1 Analysis Techniques

An important method in analyzing potential controlimprovement beneÞts is statistical analysis. Reducing thestandard deviation of controlled variables (targets, set-points) and moving operation closer to constraints is wellaccepted in practice as a basis for predicting the improve-ment achievable. Often a 50% reduction is assumed, butthe current value of the standard deviation should be con-sidered and evaluated before assuming a reduction. Often,a 50% reduction, can be somewhat conservative as shownby actual audits of control applications.

It should also be noted that the improvement in stability ofthe controlled variables is often achieved by more frequentadjustments of the manipulated variables. However, the neteffect is a reduction in variability of the controlled variables.Figure 3.1 illustrates how reduction in variability results inthe ability to operate closer to process constraints, which gen-erally translates into tangible beneÞts related to increased

process rates, improved product quality, reduced giveaway orsimilar economic beneÞts.

Another valuable analysis is to compare operations vari-ability among operating crews. Often signiÞcant beneÞts canbe quantiÞed by comparing ÒbestÓ operation vs. averageoperation within the site.

Skill is required in selecting which prediction method toemploy. Limitations in information or current capabilitymay indicate one method when in fact another is moreappropriate. As discussed above, it is also necessary toconsider the time weighted average of control targets whenthose targets are changing.

The prediction of reduced variability may then affect theoverall process yield, feed rate or energy usage. Economicfactors for these effects should be readily available from thesite. The same data can be obtained from a rigorous steadystate process model and appropriate pricing information.Such a model can also be used to assess the impact of the pre-dicted change(s) on other process parameters to conÞrm thatthe change is realistic and viable with respect to known pro-cess operating limits/constraints.

Where no acceptable analysis technique exists, it maybe possible to infer beneÞt information from similarapplications. However, this will impact on the conÞdenceof the prediction.

3.4.3.2 Practical Considerations

One hundred percent of an identiÞed beneÞt is rarelyachievable in practice. Perfect control is not possible andsome small, but positive, give-away will generally be requiredto ensure that market product speciÞcations are not exceeded.

The existing control performance affects both the beneÞtsprediction and the ability to realize the beneÞt with theintended control application. Additional measurement andcontrol capabilities may be required and their availability andutilization affect the realizable beneÞt. The use of on-lineanalyzers, either physical or inferential, may be required torealize a signiÞcant part of the beneÞt. Analyzer availabilitymust be pro-rated into the prediction.

Process constraints and plant limitations provide limits to abeneÞt. However, actual constraints or limits should be estab-lished on an objective basis as limits may be more perceivedthan real or could be relaxed by improved control or minorphysical modiÞcation.

SigniÞcant product yield pattern changes are often a resultof these evaluations. However, the prediction must reßect thepresent and future market situation. Predicted beneÞts willhave to show up in the bottom line of the siteÕs operation.

3.4.3.3 Synergystic Effects

The realization of a predicted beneÞt can have synergys-tic effects. These can either increase or decrease the ulti-mate beneÞts.

Table 3.2—Benefit Feasibility Study Steps

1. Identify application objectives .

2. Identify representative period of operation.

3. Collect and validate process data .

4. Analyze data for performance against targets.

5. Identify control application improvement.

6. Analyze control infrastructure performance and requirements.

7. Apply appropriate economics.

8. Categorize beneÞts on a conÞdence basis .

9. Review and agree beneÞts analysis with site.

10. Set-up post-application beneÞt audit basis.



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---

10 API R

ECOMMENDED

P

RACTICE

557

Examples of effects that may increase beneÞts include:

a. Reductions in stripping steam usage by implementingratio control results in a reduced sour water stripper pro-cess load.b. The reduction in the furfural wash ratio in a lube oil plantto minimize quality give-away and improve rafÞnate yieldalso produces a throughput increase for some feeds and fur-fural recovery section heat demand reductions for all feeds.

Examples of effects that may decrease beneÞts include:

a. Increase in a product recovery that cannot be handled by adownstream unit or sold at a proÞt.b. Improved controls on an upstream unit reduce potentialof a downstream unit compared to a stand-alone look atthe downstream unit. For example, stabilizing an upstreamunit may reduce variability in a downstream unit, thusshifting potential beneÞts for the downstream unit to theupstream unit.c. An existing control infrastructure may not be able to sup-port the proposed control application fully. Examples includelow on-line analyzer availability and poor basic controlperformance.d. Changes in the yield of upstream units may adverselyaffect the performance of downstream units. For example, the

recovery of additional butane/butene components for alkyla-tion feed can add unwanted n-butane and n-pentane which inturn adversely affect yield, quality and heat requirements inthe aklyation unit.

e. Some predictions can only be taken for part of the time. Asan example, the control objective of butane recovery in a deb-utanizer is a function of seasonal changes in demand,operational constraints and quality speciÞcations. For exam-ple, summer-to-winter change in gasoline speciÞcations limitthe amount of butane that gasoline can contain, plus summer-time demand for LPG components is generally low.Therefore, summer pricing of butane may not justify addi-tional recovery.

3.4.3.4 Existing Control Performance

The performance of an advanced control system appli-cation can be limited by the performance of the basic regu-latory controls and infrastructure with which it interfaces.It is imperative to review this infrastructure and make theimprovements required to support the advanced controlsystem application.

The review must be undertaken with the knowledge of theobjectives and requirements of the proposed Advanced Con-

Figure 3.1—Improvements from Reduced Variability

Controlled Variable

Per

cent

age

of O

ccur

ance

s

Operating target w/o advanced

control

Operation after advanced control

Improvement in control

Reduced variability w/

advanced control

Variability w/o advanced

control

Operation before advanced control

Operating target w/ advanced

control

Process specification

constraint

Allowable off spec operation



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---

G

UIDE

TO

ADVANCED CONTROL SYSTEMS 11

trol System Applications. Examples of the areas whichshould be addressed include:

a. On-line analyzersÑcurrent performance and availabil-ityÑIs improvement required? What additional analyzers oranalyzer modiÞcations are required?b. Regulatory controlsÑcurrent performanceÑAre modi-Þcations or loop tuning required? Is a major upgradeprerequisite to implementation of the advanced controlapplications?c. Control facilities maintenanceÑIs Þeld equipment reli-ability high enough to support an Advanced Control SystemApplication?d. Control valve performance problemsÑAre valves appro-priate to the service or are improvements in valve dynamicsor precision required?e. Additional required measurementsÑAre additional ßow,column differential pressures, levels, etc. measurementsneeded to support the advanced control applications?f. Are inferential models required because analyzers are notreusable or because the cycle time is long or results are notfrequent enough for the control.g. New or upgraded control facilitiesÑOften existingregulatory control schemes must be improved or modi-Þed. Occasionally equipment cannot be operated in themanner intended and the control objectives must be modi-Þed. Examples are:

Ð HeatersÑA control objective may be to improveefÞciency by air trim control, but the basic require-ments of box pressure and emissions compliancemust also be met.

Ð Local ControllersÑMany sidestream strippers havelocal pneumatic level controllers with perhaps anindication in the control room. Often the level con-trol valve position is identiÞed as a constraint. Thisrequires relocating the controller to the DCS or mak-ing the control valve position available to theadvanced control system.

Ð Measurements/Control LoopsÑStability improve-ment may require upgrade of existing regulatorycontrols. For example, existing level and tempera-ture control loops may need to be modiÞed toinclude cascade ßow control. New measurementsmay be necessary for identiÞed constraints. Often,side streams are not ßow controlled, but theadvanced control scheme may require it. In thisinstance a ßow measurement element and ßow con-troller may need to be added.

Ð Pre-Control Project ImprovementsÑThe feasiblystudy invariably results in identiÞcation of any num-ber of improvements. For example, loop tuning, con-trol valve sizing and performance, improved sensors,etc., can be made without implementing theadvanced control application. The beneÞts of these

improvements may reduce the increment beneÞtsattributable to the advanced control application.

3.4.4 Economic Prediction

The Þnal economic beneÞts predictions require combiningthe identiÞed control improvements and operating economicsdiscussed above.

Where possible the predicted beneÞts should be con-Þrmed against production performance monitoring. Forexample, performance monitoring should indicate similarmagnitudes from assessment of product give-away or loss.Where available plant wide LP models can also help backcheck predicted beneÞts.

3.4.5 Benefits Assessment

Predicted beneÞts should be assessed to identify probabili-ties of realizing the beneÞts. Identifying beneÞts in terms ofconÞdence can be very helpful in supporting Þnancial casesfor applications and quantifying of economic risk. Generally,beneÞts fall into three areas:

a. BeneÞts which can be rigorously quantiÞed.b. BeneÞts which can be positively identiÞed in a qualitativesense but less rigorously quantiÞed.c. BeneÞts which are less tangible. These beneÞts cannot bereadily quantiÞed, but are generally recognized in the indus-try. The quantiÞcation of these beneÞts may be somewhatsubjective. These beneÞts tend to be those derived from theimproved knowledge of the process, better operator inter-faces, improved efÞciencies such as better operatorutilization, reduced maintenance and faster troubleshooting.

3.4.6 Benefits Reporting/Functional Specification

An advanced control feasibility report should be prepared.This document should address the following items:

a. An overview of the process.b. Current and future operating objectives.c. Economics used for the beneÞts prediction.d. BeneÞts prediction analysis, including assumptions madeand references to all data sources.e. Functional speciÞcation and scope deÞnition ofapplication:

Ð Description of control objectives.Ð List of control I/O.Ð Implementation platform requirements.Ð List control/measurement upgrades required.Ð Control infrastructure upgrade requirements.

f. Preliminary estimates of implementation costs, includingthe following:

Ð Application hardware and software including licencefees.

Ð Engineering and project management.



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---

12 API RECOMMENDED PRACTICE 557

Ð Owners costs, support, training, documentation.Ð Measurement additions and upgrades.Ð Regulatory control upgrades.Ð Contract services.Ð Travel and living expenses.

g. Preliminary schedule.h. Plans for post application audit.

3.4.7 Benefit Post-Application Audit Planning

Experience has demonstrated that post-implementationaudits are only as good as the quality of the pre-implementa-tion (base case) information. The base case must be devel-oped prior to implementation as this is the only time that thecorrect base data exists.

The information and data produced for a beneÞts predic-tion study provides a very sound basis (base case) for car-rying out a subsequent post-application audit. Theapplication implementation will always be in the future.Hence, it is important that the impact of any interveningchanges, both non control (process modiÞcations, catalyst/target changes etc.) and control are evaluated to check thevalidity of the base case.

4 Advanced Control ProjectsThis section addresses aspects of project management

and execution that are unique to advanced control projects.This section is not intended to describe general projectexecution issues such as budget, schedule and contracting,but is intended to address those issues unique to advancedcontrol projects.

An advanced control project may consist of implemen-tation of one or more applications. The scope may alsoinclude infrastructure scope items such as Þeld instrumen-tation and measurements, and regulatory control enhance-ments in addition to the applications and their associatedhardware and software.

4.1 MASTER PLAN

Prior to embarking on any advanced control projects, thefacility should have a deÞned Master Plan for Automation.This plan should have the full support of facility managementand have considered the strategic business impacts. The con-tent of an automation master plan will vary from facility tofacility, but should contain the following elements:

a. DeÞnition of the long-term objective of the master planand division of the work into phases.b. IdentiÞcation of beneÞts to be realized from each phase ofthe plan.c. DeÞnition of the control and computing equipment andsoftware platforms that the facility will use. This may includedeÞnition of allowed applications for various hardware andsoftware alternatives.

d. IdentiÞcation of existing and planned control networksand an expansion path or evolution plan for those networks.e. DeÞnition of process control implementation standardsand practices for the facility.f. IdentiÞcation of critical timing issues with respect to unitturnarounds or other shutdowns that may be opportunities forcontrol and instrumentation system modiÞcations, upgradesor improvements.g. Milestones or schedule for review and update of the plan.h. IdentiÞcation of resources required to provide ongoingapplication maintenance after implementation is complete.

4.2 PROJECT EXECUTION PLAN

Prior to commencement of an advanced control project, aproject execution plan should be prepared as a guide to howthe objectives of an advanced control project will be realized.The plan should build on the information in the feasibilityreport and master plan. It should address the following:

¥ Timing of the project¥ Functional speciÞcation ¥ Resource requirements ¥ Project beneÞts¥ BeneÞt validation plan¥ Training plan¥ Design plant testing and implementation plan¥ Commissioning plan¥ Post commissioning economic performance plan¥ Ongoing application support and maintenance

4.3 IMPLEMENTATION ISSUES

Advanced control projects have a number of implementa-tion issues that are not normally associated with projects ofother types. The project engineer should be fully cognizant ofthe requirements of the facility master plan and be prepared toexecute the project within the guidelines of this plan

Common issues associated with implementation ofadvanced control applications are:

a. Advanced control projects often involve upgrades of exist-ing control systems. This may range from wholesale upgradesof obsolete instrumentation systems with modern DCS sys-tems to incremental upgrades of existing systems.b. Most advanced control projects will involve addition orupgrade of process measurements. Some of these measure-ments may not be accessible during normal operation anddesign of the control system may have to recognize delayedavailability of certain measurements. Some of these measure-ments may involve the use of on-line analyzers. Typicallyanalyzers must be installed and have a demonstrated perfor-mance history before the advanced control application canuse the measurement. The project budget and schedule mustrecognize the costs and timing associated with new orupgraded measurements.



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---

GUIDE TO ADVANCED CONTROL SYSTEMS 13

c. New construction projects often involve implementationof an advanced control system. Usually this implementationcannot proceed to any extent until after the construction hasbeen completed and operating data are available.

d. New construction projects may also involve modiÞcationof existing units, which may also have existing advanced con-trol systems. The scope of new construction may be such thatthe process equipment, operating conditions or operatingcharacteristics will be different than those on which the exist-ing advanced control system was based. This may require thatthe existing advanced control system be redesigned or modi-Þed before it can be recommissioned.

e. Many advanced control projects are dependent on having aunit shutdown to install measurements that may not be acces-sible during operation. Until these measurements areavailable, it may not be possible to completely perform pro-cess testing or control system implementation tasks. Thisshutdown may also be required to implement control systemreplacements or upgrades. Many times the turnaround orshutdown schedule will determine the overall advanced con-trol project schedule.

f. Process safety management regulations usually requirethat process hazard analysis be performed on the advancedcontrol system. This may require implementation of amanagement of change procedure to assure that develop-ments in system design are properly reviewed before theyare implemented.

g. An advanced control systemÕs design may be based on anumber of different techniques. Among these are steady stateand dynamic process modeling to identify relationshipsamong key operating variables and on stream testing of exist-ing systems to derive empirical relationships. If signiÞcantprocess modiÞcations are being made in parallel with theadvanced control project, some of this work may not be com-pleted until the modiÞcations have been completed.

h. An advanced control system project may require integra-tion of multiple software packages, possibly from more thanone supplier. An integration plan, including identiÞcation ofthe organization and individuals responsible for ensuring thatall software works as intended. The use of a single ÒsuiteÓ ofsoftware versus several applications from different sourcesshould be evaluated. Not all applications in a suite of softwaremay be the best Þt for a project, but this should be weighedagainst the cost of implementing and maintaining softwareintegration among several vendorÕs offerings.

4.4 PERSONNEL COMMITMENTS

Successful execution of an advanced control projectrequires commitment of an appropriate number of personnelwith the appropriate skill sets. As mentioned above, availabil-ity of personnel with the knowledge, experience and ability toundertake advanced control projects is critical to the success

of the project. Attempting to implement a project withoutadequately skilled personnel will likely result in failure.

As compared to many other types of design/constructionprojects, advanced control projects require that a substantiallyhigher percentage of total project costs be devoted to engi-neering. Advanced control applications also require contin-ued maintenance if a continuous beneÞt stream is to berealized. Process facility management must recognize thepersonnel commitments required and consider them withrespect to beneÞts when making stafÞng decisions.

4.4.1 General Skill Set

Personnel assigned to advanced control projects should befamiliar with the speciÞc practices and techniques associatedwith such projects. This includes knowledge and experiencein process control engineering, control system hardware andsoftware and general process engineering.

4.4.2 Project Management Skills

Project management skills are an important factor inadvanced control project execution. However, the manage-ment methodology must recognize the unique characteris-tics of advanced control projects. This includes issues suchas critical path schedule items often being unit shutdowndriven, extended periods where little or no apparentprogress is made due to these restrictions, and the oftenextended implementation, testing and validation periodsassociated with such projects.

4.4.3 Specialist Support

Participation of specialists skilled in such areas as processengineering, computer implementation or analytical methodsis a critical component of an advanced control project. Theseindividuals may be on the ownerÕs staff or may be contract ormanufacturer/vendor employees. In any case, these individu-als may need to devote a signiÞcant amount of time to theeffort.

4.4.4 Vendor or Consultant Support

In many cases, an owner may not have sufÞcient staffwith the requisite skills available. In these cases, use ofmanufacturer, vendor or consultant personnel can beapplied to leverage existing staff and realize the beneÞts ofthe applications. Should use of such personnel be neces-sary, the owner should ensure that the personnel have therequisite skills and training.

4.4.5 Plant Operations and Maintenance Support

A key component of any successful advanced controlproject is the support and participation of plant operations andmaintenance personnel. Operations input is a key factor in



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---


deÞning advanced control objectives and strategies and inimplementation, execution and maintenance of the controlscheme, operator interfaces and backup and fallback strate-gies. It is highly recommended that a skilled operator beassigned to the project team.

Maintenance input is necessary to identify requirementsfor the advanced control system to handle routine orunscheduled maintenance of sensors, transmitters, controlelements and control equipment and engineering orientedchanges such as loop tuning, conÞguration changes, etc.These issues must be addressed as an integral part of theadvanced control system design.

4.5 SCHEDULE

Advanced control projects have scheduling characteristicsthat are unique to these types of projects. These characteris-tics often result in high activity periods separated by substan-tial periods of little or no apparent activity.

Prior to starting an advanced control project, all signiÞcanttasks and their expected duration must be deÞned. All sched-ule constraints imposed by resource availability and opera-tions should be identiÞed. Table 4.1 shows a list of typicaltasks associated with an advanced control project. The actualtasks, duration and lead time may vary substantially depend-ing on the scope of the application, plant operations and theprior experience of the engineering, operations and mainte-nance staff.

Table 4.1—Typical Advanced Control Project Tasks

Task Typical Timing

Facility Master Automation Plan 12 to 60 months prior to project initiation

Feasibility Study and Project IdentiÞcation 6 to 18 months prior to project initiation

Project Implementation Plan At initiation of project

Functional SpeciÞcation Start of project scope deÞnition

Regulatory Control and Measurement Design 6-12 months prior toprior to commissioning

Design SpeciÞcation With Regulatory Control and Measurement Design

Advanced Control Software Purchase 6-12 months prior to commissioning

Hardware Platform Purchase 6-12 months prior to commissioning

Model IdentiÞcation Testing 3-6 months prior to commissioning

Model IdentiÞcation and Implementation 2-4 months prior to commissioning

Engineer Training Initial at software purchase. General training 4Ð6 months prior to commissioning

Operator and Engineering Graphics Implementation 2-4 months prior to commissioning

Advanced Control Hardware and Software Installation 2-4 months prior to commissioning

Regulatory Control and Measurement Installation As allowed by operation and scope of design. Minimum 2Ð4 months prior to commissioning

Install, Test and Simulate Advanced Control Applications 2Ð4 months prior to commissioning

Operator and Maintenance Training 1 month prior to commissioning and during commissioning

Commissioning 1 to 2 monthsÑSubject to operations scheduleÑreference point for other tasks

Initial Advanced Control System Operation Commissioning and 2Ð4 months after commissioning

Full Time Advanced Control System Operation 2-4 months after commissioning

Close-out Documentation 1-4 months after commissioning

Post Commissioning Economics Audit 3-6 months after commissioning

Advanced Control System Adjustments and ModiÞcations 2-6 months after commissioning

Life Cycle Support Ongoing

Note: These tasks are generalized and not all tasks may be applicable to all types of control technologies. Depending on the technology used,additional or modiÞed tasks may be necessary.



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---


4.5.1 Resource Availability

Personnel with the skills required for implementation of anadvanced control project are in limited availability. As part ofthe scheduling process, the types of skills and number of per-sonnel required must be deÞned. The availability of such per-sonnel may determine the project schedule.

4.5.2 Impact of Ongoing Operations

Implementation of advanced control projects is oftendependent on ongoing operations. Shutdowns or turnaroundsmay be required to add or modify process measurements orÞnal control elements.

Process testing to develop process models or other relation-ships is usually required for any advanced control system.This testing often can consume several weeks and may beinterrupted by unstable operations or operations at conditionsdifferent than those contemplated by the advanced controlsystem. It is also not unusual that after initial process testingis completed, changes in operating conditions or objectivesrequire additional testing.

4.5.3 Training

Training programs for operations, engineering and mainte-nance personnel must be developed. Depending on theresponsibilities and prior knowledge of the personnel to betrained, the content and timing of this training will vary. Table5.1 shows an example of an overall training program.

The training program must address initial training,refresher training for existing personnel, training for new per-sonnel and training in operations without the advanced con-trol application in service. The training program should haveprovisions for tracking an individualÕs training history. Basedon local regulations, it may be necessary that operators becertiÞed to operate the process and its control systems.

4.5.3.1 Training Tools

At a minimum, training manuals shall be prepared foroperator and maintenance technician training. The manualshould describe:

a. The application and its implementation.b. All operator interfaces and reports.c. A list of inputs and outputs associated with the applicationand any requirements for their maintenance.d. Instructions on how to put the application on control andtake it off of control.e. Operations in degraded control modesÑe.g., partial shed-ding, operation with substituted values, etc.f. Application maintenance requirements and procedures.

Initial classroom training can familiarize the operators withthe general application. This formal training must be supple-mented with on-console training and support by the advanced

control application engineers during initial testing and com-missioning. This training may occur over several weeks. Thetraining plan should include plans for on-process training ofshift operators and post commissioning training to updatepersonnel on changes that were made during commissioning.

In the event that the advanced controls are not operating,the unit operator must be able to assume safe control of theunit. The effectiveness and reliability of modern DCS andadvanced control systems has resulted in much more stableoperation of process units. As a result, operators have far lessexposure to upset operation, or operation without theadvanced control applications running. Additional training isrequired to assure that the operators are capable of handlingupset and degraded control conditions.

Process simulators are an effective means to provide thistraining. The advances in computer technology have madeimplementation of high Þdelity dynamic simulators an effec-tive and economical tool for training. These simulators canaccurately represent the behavior of a process, its control sys-tems and the operator interface. Routine refresher training ofoperators using dynamic simulators is becoming a viable andeffective means of maintaining operator skills.

4.5.4 Testing and Commissioning

Relative to many other types of projects, the testing andcommissioning processes for an advanced control systemsare extended activities. Advanced control systems are usu-ally complex and require that a large number of variablesand possibly several different operating conditions betested and monitored.

Testing for an advanced control application consists of off-line or simulated operation during which the performance ofthe application is checked for correct operation. Some of thetest objectives are to:

a. Verify input and output connections.b. Verify bad value behavior and control application shed-ding and degradation performance.c. Verify watchdog timer function for communication andapplication program failure.d. Verify that intermediate calculations produce expectedresults.e. Verify that application predictions and control outputs areas expected.f. Develop preliminary tuning.g. Exercise all operator, engineering and maintenanceinterfaces.

Commissioning consists of placing the application on pro-cess and observing and adjusting its performance for a longenough period to demonstrate acceptable operation.

Often initial commissioning is done on a limited basiswith the advanced control scheme being operated duringday shifts or when a key operating crew is on shift. During



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---


this period, substantial specialist support is necessary tomonitor the control system performance and identify anynecessary modiÞcations to the application. Larger applica-tions, or applications which are difÞcult to turn on and offmay require that the control application operate around theclock and that commissioning application support also beavailable around the clock.

4.5.5 Economic Performance Audit

Prior to close out of an advanced control project, an eco-nomic performance audit of the advanced control systemshould be performed. This audit serves to validate the ben-eÞts identiÞed during project development and providesthe base line for use in monitoring ongoing performance.The methods used in performing this audit should be thesame as those described above under IdentiÞcation andQuantiÞcation of BeneÞts.

4.6 APPLICATION DOCUMENTATION

Each advanced control project shall produce a completeand accurate set of documentation for turn over to the plant

operations, maintenance and engineering groups. A docu-mentation package should be produced for each application.This documentation package typically contains itemsdescribed below.

In addition to these documents, there will be a number ofproject oriented documents that may be retained in historicalÞles. Some of these items are records of feasibility studies,scope deÞnitions and estimates, project execution records andother records that are not identiÞed as being required for turnover. Description of these Þles is not part of this scope.

4.6.1 Functional Specification

A functional speciÞcation for the advanced control appli-cation should be prepared and maintained during implemen-tation. This speciÞcation will be an update of the speciÞcationdeveloped for the feasibility study.

4.6.2 Design Specification

The design speciÞcation addresses detailed require-ments to implement the application described in the func-

Table 4.2—Advanced Control System Training Program

Organization Personnel Content Location Timing Method

Operations Console Operator/ Liaison with APC project

Detailed Commis-sioning, Operation w-w/o Controls

Vendor facility or plant training facility

At functional design w/ continuation dur-ing implementation and at commission-ing

Classroom, detailed simulators, on pro-cess

Other Operators Operation w-w/o Controls

On-site Prior to commission-ing and continuation during commission-ing

Classroom, on con-sole & simulator

Operation Supervi-sion

Overview of func-tions and objectives

OfÞce Prior to commission-ing

Presentation

Engineering Control Engineer Objectives, Process, Control Technolo-gies and Detailed Application

Vendor facility & ofÞce

Prior to project and during functional design

Classroom, simulator

Process Engineer Objectives, Applica-tion Details, Com-missioning, Operation w-w/o Controls

Vendor facility or plant training facility

Prior to commission-ing

Presentation and Classroom

Project Engineer Objectives and Scope

OfÞce At start of project Presentation

Maintenance Application Support Specialist

Control Technolo-gies and Detailed Application Mainte-nance

Plant training facili-ties

During design Classroom, simula-tor, actual system

Instrument and DCS Technicians

Maintenance Proce-dures w-w/o Con-trols

On-site Prior to commission-ing and continuation during commission-ing

Classroom, on pro-cess



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---


tional speciÞcation. Examples of the items that thisdocument addresses are:

a. Description of the application objectives and functions.b. DeÞnition of control technology and communicationsmethods.c. Scope of DCS, regulatory control and measurementimprovements.d. I/O requirements.e. Model details.

Ð Expected MVs, CVs, and DVs.Ð Estimated response time for each controller.

f. Operator, engineer and maintenance interfaces. g. Requirements for turning the application on and off, andshedding or control degradation behaviors.h. Data base contents and structure.i. Maintenance requirements.j. Training requirements.

Section 6 describes a number of issues that should be con-sidered while developing this speciÞcation.

4.6.3 Ongoing Documentation

The following types of documents represent the actualinstallation in the Þeld and shall be kept current.

4.6.3.1 Applications Configuration Data Base

A description of the contents and structure of the applica-tions conÞguration data base shall be maintained. Backupcopies of the data base shall be made at regular intervals.

4.6.3.2 Graphics and Reports

The primary documentation for graphics is a hard copy ofeach graphic in the system, preferably in color, and a listingof code or conÞguration associated with the behaviors of allactive graphic elements. Similar information shall be docu-mented for all conÞgured reports. Electronic backups of allgraphics and report Þles shall be made at regular intervals.

4.6.3.3 Program Listings

Up-to-date listings of all application programs shouldbe kept in backed up electronic form, and if desired, inhard copy. It is also suggested that the listings be accom-panied by descriptive material deÞning the purpose andfunction of all programs and the inputs and outputs usedby the application. Program ßow diagrams should beincluded where appropriate.

4.6.3.4 Training Documents and Procedures

Copies of training procedures, records and manuals shallbe maintained.

4.6.3.5 Maintenance Procedures

Copies of maintenance procedures, records and manualsshall be maintained.

5 Technology Considerations5.1 HARDWARE PLATFORM

The hardware platform used for an advanced control appli-cation usually has a fundamental impact on the feasibility,economics, and the ultimate success of the application. Theavailable options should be evaluated, and a choice of plat-form should be made, as early in the implementation as prac-ticable. Often, this may have been determined duringdevelopment of the master plan. Control engineers and com-puter hardware systems specialists should be consulted whenmaking this choice.

If the application software can run on multiple platforms,the relative advantages and disadvantages of each should bestudied carefully. Typically, the choice will be between run-ning the application on standard distributed control system(DCS) equipment or on general-purpose computer hardware.If the application is run on general-purpose computer hard-ware, often the choice will be between a workstation and apersonal computer (PC) type platform. As DCS equipmentmigrates toward using more general-purpose hardware, andas PCs and workstations evolve to have similar capabilitiesand pricing, the distinctions between hardware platforms arebecoming increasingly difÞcult to discern.

There are trade-offs between locating applications onDCS platforms versus general-purpose computers. Forexample, running an application on DCS equipment mayhave the advantages of close coupling to the underlyingregulatory controls, use of the familiar DCS operator inter-face console, and for many applications, may require nonew hardware. Disadvantages may be lack of portability ofthe application to other systems, less ÒfriendlyÓ implemen-tation and maintenance tools, and if required, hardwarethat is more expensive.

System security and maintainability are major consider-ations. Any computer running an advanced control systemshould be dedicated to advanced control functions and not beshared with non-related functions. It generally is permissibleto run advanced control applications on the same computerthat is running a historian, but should not be shared withapplications such as accounting, personal computing serversor similar applications. It is good practice to segregate appli-cations so that loss of a single computer will have limitedimpact. Consideration must also be given to computer load-ing so that applications will execute in the time required.

The recent history and likely future for a hardware plat-form should be analyzed carefully against the require-ments for the application. The computer hardware andoperating system environment is volatile and consideration



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---


should be given to migration paths available. The condi-tions and the hardware support infrastructure at the siteshould be evaluated carefully. This is especially true if thehardware platform will be completely new to the plant siterequiring additional training or new support personnel.Contract hardware support with the hardware vendor maybe an attractive alternative.

Involving knowledgeable specialists from diverse back-grounds often can prove beneÞcial in hardware selection.The capabilities of general-purpose computer hardwareand DCS systems are continuously changing. Proper selec-tion of hardware requires the input of specialists who areaware of the existing and developing capabilities of vari-ous hardware platforms.

Often the advanced control application supplier, the under-lying DCS hardware restrictions, or a previous choice of usercompany standard hardware may dictate the choice of hard-ware. Such a dictated choice should be evaluated to assurethat the selection is appropriate.

5.2 SOFTWARE PLATFORM

The software platform consists of the operating system, thecontrol application development package, and data collec-tion/archiving packages with associated database systems.Issues which should be considered when selecting a softwareplatform are discussed below.

5.2.1 Data Flow

Data ßow requirements for control applications can have amajor inßuence on the selection of a software (and hardware)platform. The data ßow requirements of each control applica-tion should be analyzed when choosing the software plat-form. The real time aspects of control applications requirethat data ßow in a deterministic manner at regular intervals,and that this data come from or go to a permanently assignedlocation. Some software platforms can present a major prob-lem for some control applications, for example:

a. The platform depends on exception-based data reporting.b. The platform uses relational database structures. c. The platform cannot process data frequently enough.

Control engineers familiar with the dynamic data require-ments of the control application should be involved in dataßow evaluations.

5.2.2 Application Separation

Individual control applications running on a commonsoftware platform shall be separate and distinct from eachother. Any control application shall not depend on any partof any other unrelated control application for its properfunctioning. Control applications shall be capable of beingturned on and off and otherwise manipulated without caus-

ing disruption in any other, unrelated application. Thisrequirement shall be clearly speciÞed and communicatedto the people who will be doing the programming and con-Þguration of the control applications.

5.2.3 Security

The software platform shall provide security from unau-thorized access to the control applications and security frominadvertent and unauthorized changes to the basic processcontrol system.

Security from unauthorized access usually is accomplishedby some combination of password and keylock access. Sys-tem administration and security procedures should be estab-lished as early in the project as practicable. A personknowledgeable in computer security administration and asso-ciated issues should be used when setting up the system.

Security from inadvertent changes shall be evaluated thor-oughly when choosing the software platform. Any softwareplatform used in process control must provide very robust,hard-to-bypass protection against accidental or unauthorizedchanges to the basic process control system. A computer spe-cialist familiar with the software platform, how it communi-cates, and possible protections should be used when choosingthe software platform.

Some plants adhere to strict security, such as using pass-words, to limit DCS access to certain usage levels. For exam-ple, process operators are allowed access to all operatinglevels required to control the process, shift supervisors mighthave additional access to production schedules, and plantengineers would be able to access everything, including con-Þguring the system. Access to controller tuning parameters isgenerally restricted to the plant engineers and instrument peo-ple. Otherwise, a troublesome control loop might be Òre-tunedÓ by each shift.

5.2.4 Communications with Regulatory Control System

Communications with the regulatory control system are afundamental requirement for any advanced control systemapplication. The quantity and frequency of data communi-cated between the advanced control application and the pro-cess system should be determined as early in a project aspracticable. Communication functions between the advancedcontrol platform and the regulatory control system must beveriÞed.

Typically, DCS systems provide a mechanism for restrict-ing the ability for a remote application to write data to theDCS. The security set up of the DCS system shall be evalu-ated to ensure that unauthorized data writes from a remoteapplication do not occur.

Communication limitations could have a major inßu-ence on the feasibility of a given advanced control applica-tion. Control engineers familiar with the quantity and



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---


frequency of data communication required by a given con-trol application should be consulted when choosing a soft-ware/hardware platform.

5.2.5 Communications with Historian

The software platform should be capable of communicat-ing with a historical database system. Usually the advancedcontrol application is required to keep data on its past perfor-mance. The application may also require historical data toperform its functions.

Many control applications generate a set of futuremoves that the control system plans to make. It is desirableto be able to store the forecast moves and display them tothe operator in either tabular or graphic format. Such capa-bilities should be included in either the historian or controlapplication package.

Historical data requirements will have an inßuence on soft-ware (and hardware) platform choice. Frequency of historicaldata collection, retention time for this data, and where histori-cal data will reside should be determined at the outset of anadvanced control project. Any special uses of historical data,such as statistical calculations, can be heavily inßuenced bydata archiving techniques.

5.2.6 Open Systems and Software Standards

Many of the open systems and software standards that arebeing developed for business information systems are beingapplied to process control applications. Methods for applica-tion of these standards to process control are evolving and arenot yet mature. Use of these standards offers the potential for:

a. SigniÞcant reduction in the implementation and mainte-nance costs associated with advanced control applications. b. Applications that are ßexible, reusable and portable.Applications programs can be developed using the conceptsof object oriented and modular programming. The applica-tions may then be connected to many DCS systems orhardware platforms through vendor supplied open systemsinterface.c. SigniÞcant improvement in the ability to support and mon-itor applications from remote locations through the use ofdialup connections, intranets and internet access.

These beneÞts must be balanced with the signiÞcant secu-rity and reliability concerns associated with the use of opensystems. Applications personnel must approach use of infor-mation systems standards with care. The security and reliabil-ity requirements of process control applications are muchhigher than those required of many business applications.Designs must recognize these requirements and provide forisolation of control system from other networks. The securitysystem must also restrict access to the control systems to

those computers and personnel who are authorized andensure that actions and communications from other networksdo not impact control system performance and security. Referto API RP 554 for information on network isolation practices.

6 Design Considerations

6.1 GENERAL DESIGN ISSUES

6.1.1 Regulatory Control System

Performance of the underlying regulatory control loops isan essential part of advanced control success. Many advancedcontrol performance problems can be tracked to poor regula-tory control performance. Regulatory controller performanceshould be reviewed to verify that measurement accuracy andreliability, controller tuning, PV range selection and controlvalve performance are adequate for advanced control func-tions. If regulatory control performance is unacceptable,upgrades of the regulatory controls will be required prior tothe advanced controls can be commissioned.

The design of an advanced control application may alsorequire that the basic regulatory scheme be reorganized. Akey step in the overall design is determining which regulatorycontrol loops should be connected to the advanced controlsystem application.

6.1.2 Acceptance and Support

A successful advanced control application is accepted andsupported by the process facility operating and technical peo-ple. It stabilizes operations and is robust. It is easily operatedand monitored.

Acceptance and support of the application requires thefollowing:

a. Make process facility operations and maintenance person-nel part of the project team.b. Charge the process facility representatives with solicitinginput from the rest of the process facility and representingtheir requirements to the project team.c. Require that the project team conduct design reviews withthe remaining process facility personnel. The design reviewsshould address the functions of the application, the status ofwork and outstanding issues.d. Involvement from the economics and planning personnelis critical to ensure that the application meets the overallrequirements of the facility. It is also important that thechanges in the operation of the plant (e.g., product yields andcapacities) realized from the applications are communicatedback to these groups.e. Involve all of the facility operations and maintenance peo-ple during the installation and testing phases.



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---


An advanced control application that stabilizes operationsand is robust will:

a. Handle normal process disturbances with little or no oper-ator attention. b. Handle major disturbances and bring the facility back intoa normal operating range within an acceptable time frame.The magnitude and duration of disturbances that the controlsystem should handle must be developed with the facility per-sonnel. This is often a trade off between model complexityand willingness to accept some loss of the application onstream time.c. Incorporate techniques that allow the application to tol-erate failures and degradation of control without upsettingthe process. See Application Shutdown, Shedding andDegradation (6.4.3.2).d. Run reliably without internal application program faultscausing the application software to shut down.

An advanced control application that is easily operated andmonitored will allow the operator to quickly and accuratelydetermine the status of the application, determine the valuesof important measurements, and make appropriate changeswhen necessary. This is discussed in 6.3.

6.1.3 Focus and Simplicity

The project team should carefully examine the optionsavailable in the selected advanced control software and useonly those functions required. Successful control applicationsare those that are only as complex as necessary to perform therequired functions and do not include unneeded options andfeatures. Direct, easy to understand implementations shouldbe used even if they result in slightly less efÞcient programoperation. Implementations that use tricks or complex func-tions make applications more difÞcult to maintain or modifyand result in lower application usage.

6.2 PLANT DATA COLLECTION FOR APPLICATION DESIGN

Most advanced control applications require the collec-tion of signiÞcant plant data in order to complete thedesign. The type of data needed, the quantity needed, andhow it will be collected should be determined early in aproject. The type of data required will vary based on thetype of control application. For example, multivariablematrix controls require plant testing. Neural Net control-lers often require evaluation of historical data, while fuzzylogic or expert systems often require development of rulesbased on operating or process knowledge.

6.2.1 Step Disturbance Testing

Often an advanced control application will require datacollected during disturbances to the process facility steady

state operations. If this is the case, involvement and consentof the operating personnel shall be sought well in advance.The extent and magnitude of the disturbances should beclearly understood and agreed to. Procedures for the testingshould be in place and understood prior to testing begins.Prior to commencement of testing, the calibration of all mea-suring instruments and review of the performance of all con-trol valves shall be performed. A qualiÞed and knowledgeablecontrol engineer shall be present during all testing.

Disturbance testing may take the form of a series of steptests using either set point or control valve position stepchanges. Advances in analysis of test data have allowed useof other types of disturbance testing such as use of impulses.Disturbance testing may last over a period of days to weeks.

For some facilities, disturbances to normal operationscould have major consequences; however, some advancedcontrol applications require disturbance testing. In this case,compromises shall be explored with the relevant operationsand technical people. If compromise is not possible, an alter-native advanced control application may be required, or theapplication may not be feasible at all. The feasibility of per-forming necessary plant testing shall be established duringthe scope deÞnition of the project.

6.2.2 Plant Historian

Often, data collected from the plant historical database, canbe used in designing the advanced control application. This isespecially applicable if neural net controllers are being imple-mented. If the application has special requirements for type,frequency, and time period the data collected, these require-ments should be communicated to those responsible for oper-ating and maintaining the plant historian. If the requirementsfor the application data collection cannot be met, then alterna-tives and compromises should be explored and agreed to.

Historical data should be analyzed carefully to make surethat it is providing useful information for the control applica-tion. Often historical data collection schemes, such as averag-ing, compression, or exception reporting can distort thedynamic or statistical behavior of the process to be con-trolled, and make the historical data of limited value for con-troller design purposes.

If the process contains a regulatory controller that will notbe present in the Þnal advanced control application, the his-torical data may not be valid for the affected variables andadditional testing or data analysis may be necessary. Forexample, the original control strategy may contain a tempera-ture cascade that would not be used in the advanced controlapplication. The behavior of this cascade can affect the valid-ity of historical data for use in developing the model for theadvanced control application.



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---


6.2.3 Data Validation

Any data collected, massaged, and used to design the con-trol application should be validated with the real operationand behavior of the process facility. During data collection,the reasonableness of the data should be evaluated. Criteria toevaluate data reasonableness are:

a. Do ßows add up to satisfy material balances? b. Are energy balances correct? (e.g., Does a stream beingheated have higher temperature leaving the exchanger thanentering and does the heated stream absorb as much energy asthe cooled stream gives up?) c. The dynamic nature of the data should be analyzed care-fully, especially where modeling is being done. (e.g., Is thistruly a response to a process disturbance or is it noise?) d. The state of the process facility at the time of data collec-tion should be accounted for. (e.g., Was everything ÒnormalÓ,or was the facility in the middle of major transition?) e. Any output resulting from the data should be analyzedcarefully to make sure that it is reßective of actual conditions.(e.g., Does this dynamic model really show what happens?)f. Has an unmeasured disturbance occurred during the datacollection? If such a disturbance occurs during a test run, thatdata must be discarded.

Data analysis and reconciliation has a major inßuence onsuccessful advanced control application design. SufÞcienttime to do a thorough job should be allowed for in the projectschedule. This activity requires a well trained, thoroughlyexperienced control engineer.

In some cases, use of on-line data reconciliation may benecessary. This is a function of how much analysis or manip-ulation of test data is required. The need for on-line reconcili-ation should be identiÞed early in a project, as this can requiresubstantial amounts of planning and programming.

6.2.4 Data Collection for Fuzzy Logic or Expert Systems

Fuzzy logic and expert systems use a set of rules or knowl-edge about a system to generate their control decisions. Col-lection of data for these systems usually amounts toaccumulating knowledge from personnel who are familiarwith the operation of the process, from which rules that thecontroller should follow are generated.

6.3 FUNCTIONAL CONSIDERATIONS

6.3.1 Control Design Criteria

Controller design is based to some extent on the experienceof the control engineer and the features provided by commer-cial controller vendors. Packages available from varioussources may have differing features and tools. Some maycontain support for data input validation, operator interfaces,

controller performance monitoring or other accessories andtools.

In addition to technical decisions such as selecting control-ler type. control objectives and design of the core controlfunctions, controller design also consists of providing thesupport functions necessary for day to day operation. Some ofthe functions that need to be considered are:

a. Input data validation and controller response to detectionof bad data.b. Operator interfaces, including simple methods to turn thecontroller on and off.c. Controller size and complexity versus issues of ease ofoperation and reliability.d. Means to monitor controller performance.e. Means to adjust controller operating parameters andtuning.f. Use of inferential calculations in place of physical devices,such as temperature sensors and analyzers.

6.3.2 Application Maintenance

The application package should be designed to readily sup-port modiÞcation of the advanced control application. ThesemodiÞcations can be of several different forms:

a. ModiÞcations due to normally anticipated changes inoperating modes. Depending on the nature or frequency ofthese changes, it may be advisable to incorporate these capa-bilities directly in the base design. For example, anapplication may have to accommodate high/low severity, startor end of run conditions or winter/summer operations.b. ModiÞcations due to changes in process requirements orprocess economics that were not anticipated at the time theapplication was designed. Examples here may be changes inequipment, changes in product slates or substantial changesin economics. c. ModiÞcations that result from changes in control technol-ogy, platform technology changes, application packageupgrades, etc. For example a new controller algorithm maybecome available or a change in control platform or operatingsystem may be necessary.

The evaluation of control packages should also considerthe vendorÕs base structure and their technology migrationphilosophy. For example, does the vendor provide modularstructure which allows for incremental upgrades and ease ofchange without having to do signiÞcant work to reimplementthe users control applications.

6.3.3 Input Value Validation and Value Substitution

Any control system relies on the quality of the datareceived from sensors, transmitters, analyzers or other inputdevices. In regulatory control applications, it is usually easyto assess the quality of the input, or an input failure generally



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---


has limited impact. In advanced control systems, numerouscontrol outputs may be affected by failure of one input. Provi-sions shall be made to validate the input and to provide meansof running with alternate data.

There are three general classes of input failure:

a. The input signal has failed. b. A sensor or transmitter needs to be taken off-line for main-tenance, calibration, etc.c. The input signal appears to be good, but is inaccurate,unstable, frozen, etc.

When an input signal goes bad while in service, the controlapplication must be able to recognize this event and takeappropriate actions. Validation of input signals can be han-dled in a number of ways depending on the importance of theinput and how it is used.

If an input is to a single regulatory controller, the controllermay be placed in manual mode while the input is beingrepaired. Many DCS regulatory controllers have functionsthat automatically place the controller into a standby mode ifits input is determined to be bad. If the input goes to a multi-variable controller, it may be permissible to substitute a man-ual value, the last good value or drop it from the multivariablecontroller calculations. If the value is a critical value, mecha-nisms may need to be in place to automatically shut down themultivariable controller.

The most common way of determining if a input is valid isto compare it with other process data. For example, a temper-ature may be compared with other temperatures or against acomputed heat duty to determine if its value is reasonable. Ifthe measured and computed variables do not agree withinsome limit, the variable can be declared bad.

Another method to validate input data is to use a statisticalsoftware package. The statistical package can monitor a largenumber of inputs of various types. It automatically and con-tinually calculates on-line the mean, standard deviation, andmedian value for each monitored input. These values can beused to assess the quality of a given piece of data. Thismethod tends to be quite computation intensive and normallyis not used for Advanced Control Applications. The morecommon application of this technique is for use in optimizerdata reconciliation.

Analyzers are a good example of the kind of inputwhere input validation and value substitution are needed.Analyzers often provide key inputs to an advanced controlapplication, but are the most complex and least reliable ofinputs. For this reason, the inputs must be checked forabsolute and relative accuracy. Analyzer results should beroutinely checked against laboratory analysis. Analyzerstatus alarms and ßags must be checked to verify that theanalyzer is performing properly.

Some techniques that are used to compensate for loss of ananalyzer are:

¥ Use of inferred value computations that can be used forshort periods of time if the analyzer fails. These mayless accurate than an analyzer, but suitable for shortterm use. The inferred calculation can also be used tovalidate analyzer inputs.

¥ Use of inferred value computations which are correctedby the analyzer output, but which may be used for shorttime periods without correction from the analyzer. Thismay allow the inferred value computation to be muchsimpler than a stand alone algorithm, but still allow forshort term operation without an analyzer. For example,this method will allow one analyzer to be used for sev-eral streams where normally cycle times would beunacceptable.

6.3.4 Application Controls

6.3.4.1 Initialization, Startup and Restart

For an advanced control application to be put into service,it is necessary for all underlying controls to be capable ofaccepting the application outputs and for all inputs used bythe application to be available. Advanced control applicationscan be started up in a Òcold startÓ or Òwarm startÓ mode. AÒcold startÓ of an application is necessary when it is Þrstimplemented, has been totally shut down, the computer hasbeen restarted, etc. A Òwarm restartÓ occurs after partial shed-ding or degradation as described below.

A cold startup of an advanced control application requiresthat all underlying regulatory controllers be in the moderequired by the advanced control application and thatrequired inputs be available. Any inferred property calcula-tions and process models used by the application should befunctional. The advanced control application should track orinitialize all appropriate internal values and set points so thatthe application startup is bumpless. It may also be necessaryfor the advanced control application to initialize internal cal-culations, tables and matrices, or perform other calculationsnecessary to start the application.

A warm restart may not require that all of these actions beperformed. Examples of what may be necessary for a warmrestart are validation that a previously failed value is nowgood or placing a controller back into the proper mode inorder to resume operation of the application.

An advanced control application is usually put on-linemanually by the process operator. Advanced control appli-cations should have start-up utilities that will either auto-matically perform all start-up steps when commanded orwhich step an operator through a commissioning proce-dure. A warm restart will likely have fewer operations thatmust be performed. The operator interface should bedesigned so the startup process can be initiated and moni-tored by a single operator.



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---


6.3.4.2 Application Shutdown, Shedding and Degradation

Advanced control applications require a means of bothmanually and automatically turning off all or part of theapplication. This may be characterized by any of the fol-lowing:

a. Total shutdown of the control application and return toregulatory control operation. This is deÞned as applicationshutdown or total shedding.b. Shutdown of part of the application with some of theadvanced control applications functioning, but with other por-tions not operating. This is deÞned as partial shedding.c. Continued operation of the advanced control applicationusing last good values or substituted values for one or moreinput variables. This is deÞned as application degradation.

Automatic application shutdown may be the result of:

a. Failure of a key input variable .b. Decision by the control application that it cannot maintainthe control objectives.c. Operation outside of the valid control range. d. The control application cannot write its outputs due toincorrect regulatory control modes.

Depending on the nature of a problem, automatic shut-down may shut down all or part of the application. The opera-tor may initiate manual shutdown at any time.

Automatic or manual application shutdown should returncontrol to the regulatory control system without disturbingthe process or requiring additional intervention by the opera-tor. All application shutdowns, sheds or degradation shouldbe alarmed or logged, depending on the severity or criticalityof the event.

Any regulatory controllers having parameters adjusted bythe advanced control application should be returned to auto-matic or cascade modes. The user will have to decide if auto-matic shutdown should establish cascade loops that arebroken when the advanced control system application is oper-ating. Any regulatory controllers that might have been placedin direct digital control by the advanced control applicationshould be automatically placed back into operation.

6.3.4.3 Instrument Maintenance and Calibration

When a signal is being maintained or calibrated, it must betaken out of service as far as the advanced control applicationis concerned. This requires that facilities be provided to allowthe operator to tell the application that a value should not beused, or that a substituted value should be used. The operatorinterface should be designed to indicate the status of all val-ues used by the application. Provisions should be made todetect bad values and shed control as described above.

A manual input may be used in place of the live signal ifthe signal is noncritical, typically stable, and is not the PV to

a regulatory controller. If the value is a critical input, part orall of the application may need to be stopped during mainte-nance. It is recommended that Þeld instruments associatedwith advanced control applications be identiÞed as such byÞeld labeling and maintenance of lists or displays of all inputsused by an advanced control application.

Maintenance of control valves usually require that an entirecontrol loop be taken out of service, and it may require thatall or part of an advanced control application also be takenout of service. This should be done manually before the loopis released for service.

Maintenance practices must also address the effect on reg-ulatory controls. This is beyond the scope of this document.

6.4 MANIPULATED VARIABLE FUNCTIONS

6.4.1 Set Point Control

Set point control is a mode of control where anadvanced control applicationÕs outputs are the set points ofregulatory controllers. The regulatory controllers performthe task of maintaining an advanced control systemÕsmanipulated variables at the values required. Figure 6.1illustrates this relationship.

A well-designed, well-tuned regulatory control scheme iscritical to the success of any advanced control system. If keyregulatory controllers are in manual or cannot maintain theirset points, the advanced control application may have to auto-matically shed.

Set point control requires that the advanced control systembe aware of the operating mode for the controller and be ableto read the regulatory controller set points. During operationswhen the advanced control system is not determining the setpoint of the regulatory controllers, the advanced controlapplication should be able to adjust its internal values to trackthe current setpoints and be ready for bumpless transfer. Ifautomatic application startup is part of the system design, theadvanced control system must also be able to command andverify mode changes in the target regulatory controllers.

It is possible to independently set regulatory control limits(e.g., set point minimum/maximum and set point rate ofchange) in both the advanced control application and theDCS. It is important to consider these issues and set standardsfor the implementation. The clear problem to avoid is havinglimits set in the DCS that are unknown to the advanced con-trol system (e.g., set point rate of change limits in the DCS).This can introduce model error when the advanced controlsystem performs its control calculations.

The advanced control application must be made aware ifthere is any limitation in the regulatory control loop thatwould prevent the set point to the regulatory controller frombeing realized. Typical examples are controller windup or setpoint/valve clamping logic in the regulatory control system.This communication typically takes the form of a discrete



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---


ßag informing the Advanced Control application that setpoint changes are only allowable in certain directions (up,down, or neither direction).

6.4.2 Direct Digital Control (DDC)

DDC is a form of control in which the output signal froman advanced control application goes directly to a valve ratherthan to a set point of a regulatory controller. In most imple-mentations, DDC control bypasses a regulatory controller. Ifthe advanced control application is turned off or automati-cally sheds, the regulatory controller takes over control of thevalve. This practice is no longer as common as it once wasand is not recommended.

If DDC is used, the advanced control system must be ableto read the current values of the regulatory controller set pointand output and be able to track those values for bumplesstransfer. The regulatory controller must also be conÞgured totrack the performance of the advanced control system and beable to bumplessly transfer control back to the regulatorycontroller when required.

6.5 OPERATOR INTERFACE

6.5.1 Operator Graphics

Operator graphics can range from tabular data to verysophisticated pictorial displays. Graphic Þelds can displayÞxed data, and dynamic data whose attributes can change thecolor of process values, vessels, pipes, etc.

Advanced control applications should be provided withadequate graphic displays to allow operators to understandand control the operating state of the application. Generally,overview information and access to detail graphics areincluded on normal operating graphics. Detailed graphics dis-play comprehensive data and provide the means for interfac-ing with the advanced control application. Detailed advancedcontrol graphics provide the operator and engineer with sufÞ-cient information to allow for monitoring and manipulation ofthe application. Detailed graphics provide information suchas the following:

a. The state of each control function within the advancedcontrol system.b. Values and status of inputs and outputs.c. Predicted values for manipulated and controlled variables.

Figure 6.1—Advanced Control System/Regulatory Control System Interface

REGULATORY CONTROL

ADVANCED CONTROLLER

Remote SP

Shed CMD

Advanced control algorithmOn/off/shedalgorithm

Quality check

FT

FC

PV

MV

MV

Other variables

Other controllers

CVs, DVs

Bumplesstransfer

To shedalgorithm

Controller(typical)

Operator controls

Objectives CV setpoints

Economics & prices

Constraint values

Manual inputs (lab)

Historian values

Quality check

ModeSP

CMDPV SPShed.



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---


d. Indication of active or predicted constraints.e. Interface for starting and stopping the application or por-tions of this application.f. Functions to command the bypass or substitution of inputvariables.g. Instructions on startup and shutdown procedures.

Engineering detail graphics provide information on thefunction of the application, intermediate results, performancestatistics and tuning parameters. These are discussed below.

6.5.2 On-Line Instructions And Help

On line instructions and help should be provided with anyadvanced control application. On-line instructions are used toinstruct the operator how to perform a particular task when acertain process event occurs or to provide background infor-mation on the application. On-line instructions/help mayappear as tabular or written text on a graphic or they mayappear as single line text in a dedicated Þeld on the graphic. Ifavailable, on-line help should be context sensitive. If the com-puter or DCS system being used supports a multi-windowenvironment, help instructions may be contained in pop-upwindows. More sophisticated systems may support on-lineaccess to the application instruction manuals.

6.5.3 Engineering Interface

An effective engineering interface is required to allowengineering personnel to develop and maintain applications,monitor performance and tune and adjust the system.Depending on speciÞc system design, the engineering inter-face may be integrated with the DCS or be implemented on aseparate computer or PC platform.

Access to engineering functions should be restricted toauthorized personnel by some type of security system.

6.6 APPLICATION TOOLS

The proprietary software package and the hardware plat-form used for a particular application deÞne application tools.These engineering tools provide the following functions.

a. Application installation. Software should be providedto install the application and tools on the application plat-form. This software should be designed such that theapplications can be installed without interruption to anyongoing operations.b. Data acquisition and analysis. These tools should per-form or enable data acquisition for purposes of model orcontrol engine identiÞcation. Depending on the applica-tion, data acquisition may be direct or utilize an existingplant data historian. The analysis tools should allow fordesignation of good and bad data. Tools should be avail-able for evaluation of the data for purposes of validatingthe data collected. (See section 6.2.3). The analysis tools

should also provide methods for evaluating the data andconverting it to a control model.c. Application and model building and editing. The applica-tion and model building tools should provide the means tointerface the plant model to the basic control system and toset up all parameters required for the controller and model. d. Model and controller simulation and testing. These toolsallow the engineer to simulate, test and debug the controllerwithout having to operate the controller on the process. Simu-lators can also be used to provide training to engineeringpersonnel.

Note: The simulator functions available as an engineering tool gen-erally may not be sufÞcient for operator training.

e. Application performance monitoring and historization.The application tool set should provide functions that allowfor monitoring of the performance of the advanced controlapplication. This tool should allow the user to monitor on-control time, time operating against constraints, controllererrors and degraded performance time, and to deÞne the eco-nomic performance of the controller. The monitoring toolshould be able to historize the performance results of the con-troller for periods speciÞed by the user, typically for 2 to 5years. If alternate history tools are available, these may usedto satisfy this function. f. Application tuning. The tuning tools should provide ameans for the engineer to adjust the tuning parameters associ-ated with the advanced controller to provide the desireddynamic response. g. Engineering displays. An applicationÕs software set mayprovide a number of standard displays and graphics that facil-itate all of the above functions. These graphics may be Þxedor may be customizable by the user depending on the speciÞccontrol technology and supplier. They may reside on a PC, aWorkstation or on the DCS. (See 6.7)

The ultimate application tool is the control system archi-tecture itself. When deciding on a new process control systemseveral systems may be considered. In many cases, existingplant infrastructure may dictate the system to be used.

An important consideration in assessing application toolsis to identify the means by which the advanced control sys-tem will interface with the underlying regulatory control sys-tem. Additional hardware and software may be required, SeeÒTechnology ConsiderationsÓ.

6.7 ENGINEERING GRAPHICS

Engineering graphics are those displays used by the Engi-neer to install, startup, monitor and adjust the application.This information is normally viewed by technical personnel.Examples include:

a. Intermediate calculations.b. Special tuning parameters.c. Unit performance calculations.



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---


d. Cost and proÞtability data.e. Production schedule.

These displays should be comprehensive, easy to use andunder tight security (See 5.2.3). Engineering data that is ofrelevance to an operator should be replicated on the opera-torÕs graphics (See 6.5.1).

6.8 PERFORMANCE MONITORING

Monitoring is necessary to quantify the effectiveness andeconomic performance of an advanced control application.There are two kinds of performance monitoring. The Þrst isthe functioning of the control model and algorithms as com-pared to their design intent. The second is monitoring of theeconomic performance of the process with the control appli-cation in service.

Some vendors offer proprietary packages that providemonitoring of advanced process control applications and ben-eÞts. These packages provide automatic reporting of beneÞtsand functionality.

6.8.1 Control Function Performance

The application monitoring system should be able to quan-tify the following information relative to the function of thecontrol model and algorithms:

a. The percentage of time that each controlled variable wasin service.b. The percentage of time that the advanced control systemwas on-line and controlling the process. c. The percentage of time that each manipulated variable(regulatory control loop) was in cascade mode and receivingits set point from the advanced control application.d. The percentage of time that the controller was operatingagainst constraints and what those constraints were.e. The number of moves, sizes of moves and direction ofmoves made by the control application.f. The times when the control system had to shed due toinput or output errors and the cause of the errors. g. The times when the control system was turned off or on bythe operator.h. A measure of the controller model prediction comparedwith actual process response. This is a measure of the pro-cess/model mismatch.i. A measure of the dynamic behavior of the controller(under-damped, over-damped, oscillatory). This is a measureof the controller tuning.

6.8.2 Economic Performance

The primary measure of success of any advanced controlapplication is its economic performance. Economic perfor-mance metrics should be as simple as possible and directly

indicate the economic performance of the unit. Examples ofperformance metrics that are commonly used include:

a. Measurement of the cost of production per unit of feed orproduct.b. Measurement of energy use per unit of feed or product.c. Total throughput.d. Product yields.e. Product quality and variability relative to speciÞcations.

Economic performance metrics should be evaluated atmultiple points during the life of an advanced control applica-tion. A baseline operation should be determined for pre-project operation. A second evaluation is determined during apost-project audit. This second value normally becomes thebaseline for values that are calculated at regular intervals as ameasure of continuous improvement.

The baseline performance metrics may require re-evalua-tion as modiÞcations are made to plant equipment or operat-ing objectives.

6.8.3 Performance Information for the Operator

The advanced control application should have functionsthat compute and display key monitoring factors. NotiÞcationto alert the operator that the control application is not per-forming as expected should be provided. This may consist ofalarms, messages, or ßags. Examples include:

a. Indication that the advanced control application is on andfunctioning normally. NotiÞcation should be provided towarn that the application or parts of it have been turned offeither manually or automatically.b. Indication that the status of inputs and the underlying reg-ulatory control is normal. Alarms should be provided to warnthat the advanced control application function has beendegraded due to loss of connection to the regulatory controlsor due to bad inputs.c. The advanced control service factor.d. Computed economic metrics and the current delta fromthe baseline.e. When control against constraints is a control objective, thestatus of which constraints are active and the percentage oftime at which the application has operated against constraintsshould be indicated. In larger applications, prioritization ofconstraints may be necessary.

7 Application Maintenance

Advanced control systems support requirements do not endwith completion of the implementation project, but continuefor the life cycle of the application. Advanced control applica-tions typically are designed around a very speciÞc set of oper-ating conditions and economics. Changes in businessrequirements, operating objectives, operating conditions or



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---


plant physical design can adversely affect the beneÞts thatcan be obtained from a speciÞc design.

7.1 PERSONNEL REQUIREMENTS

Life Cycle support requirements must also address person-nel issues such as turnover, changing work assignments, andpromotions. Personnel involved in the original design may beworking on new applications and may unavailable for exist-ing application maintenance.

Industry experience has shown that the long term successof advanced control applications is directly related to thequality of ongoing application support. Dedicated staff willbe necessary to perform maintenance activities. Usually thistakes the form of advanced control support engineers andtechnicians directly available to operations, preferablylocated in close proximity to the operating areas.

Depending on the size of the applications it may bedesirable to outsource application support to a control ven-dor or local specialized engineering house. Many controlvendors also offer remote maintenance and diagnostic ser-vices via a secure remote network connection or dialupphone connection.

7.2 CONTINUING TRAINING

Training is a key activity during implementation of anadvanced control application, and it is also a key on-goingactivity during the life of the application. Refresher coursesand new personnel training should parallel the training pro-gram developed for the original application training.

7.2.1 Operations Training

Experience has shown that well-designed advanced controlapplications result in substantial improvements in the stabilityof unit operations. This has also reduced the amount of opera-tor intervention required on a day-to-day basis. On-goingoperations training is necessary to maintain the skill setrequired to operate the unit with and without the advancedcontrol system in service. This training should include:

a. Refresher training in the application for experiencedoperators.

b. Application training for new operators.

c. Training and drills to retain the skills required to operatethe unit without the advanced control application in serviceand during abnormal situations.

7.2.2 Maintenance Training

Ongoing application maintenance training parallels opera-tions training. Existing personnel need refresher training onthe application and new personnel require new user training.

This training should address training for all aspects of appli-cation maintenance including:

a. Maintenance of Þeld instrumentation associated with theapplication.b. Application maintenance including backups of programÞles and data, and modiÞcation of application performanceparameters and tuning.c. System platform maintenance, including computer hard-ware and operating systems.

7.3 CHANGE CONTROL

Change control refers to procedures to ensure that modiÞ-cations are made in an approved manner and are properlyexecuted, tested and documented. Typically processing facil-ity management establishes overall Management of Change(MOC) policies and procedures. Change control functions foradvanced control applications should adhere to those policies.These MOC policies usually deal with equipment issues, sospeciÞc advanced control change procedures will need to bedeÞned. Areas which should be addressed by MOC foradvanced control applications are discussed below.

7.3.1 Tuning and Parameters

Changes to tuning constants or operational parameters,such as input ranges, constraints, targets, alarm limits etc.should be restricted to authorized personnel. A list of parame-ters that should have controlled access shall be prepared foreach application.

Any changes to restricted parameters should be logged orhistorized. Any advanced control applications that automati-cally change parameters must be clearly documented and ameans for tracking the changes shall be available.

7.3.2 Control Objective modifications

Sometimes a control application must be modiÞed toaccommodate a change in the control objective. Changes ofthis type should go through the facilityÕs MOC process.Depending on the type and magnitude of change, additionalengineering and validation testing may be necessary.

7.3.3 Process Modifications

Changes in processes usually affect advanced controlapplications associated with them. Any modiÞcationsrequired to the advanced control applications as a result ofprocess changes should be handled under the MOC for theprocess change.

The control engineer must be consulted early in the processdesign phase so that he can analyze the impact on existingcontrol hardware and applications. Additional control hard-ware required, control system processor capacity, and theimpact on existing applications must be considered and



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---


deÞned. Careful planning and scheduling is required for theinstallation, testing, and commissioning of any new hardwareand applications. Some process modiÞcations may requirethat work be done during a plant shutdown. Control systemscheduling considerations must be integrated into the masterproject schedule.

7.3.4 Infrastructure Modifications

ModiÞcation or upgrade (e.g., a new version) of existingsoftware or hardware, or addition of new software or hard-ware requires administration under MOC procedures. Proce-dures shall be established for testing and validation of themodiÞcation and records must be maintained.

7.3.5 Control Technology Advances

Advances in control or computer technologies may makereimplementation of an existing application using a new tech-nology or platform desirable. The magnitude of the reimple-mentation scope usually will require that the work bemanaged under a project structure. The project organizationwill still be required to follow MOC procedures.

7.4 PERFORMANCE MONITORING

Performance monitoring of the advanced control applica-tion is necessary to track the beneÞts realized by the applica-tion and the control function performance. Procedures andstandards for applications performance monitoring should beestablished and followed. A log of system deÞciencies shouldbe maintained.

7.4.1 Data Collection and Archiving

Advanced control system applications typically have a sig-niÞcant amount of performance data collected by the plant orapplication historian. The data captured by the historianshould be reviewed periodically to verify that the data isbeing collected, archived, and backed up properly.

7.4.2 Performance Evaluation

Performance monitoring functions were described earlierin this document. The performance of an advanced controlapplication is monitored by the operators and advanced con-

trol support specialists. The following are common perfor-mance problems and examples of corrective measures:

a. On-line time is unacceptable. This may be due to inputvariables that are not reliable, the controller may need tun-ing, the model may need re-identiÞcation, the objectivesmay need correction or additional operator training may benecessary.b. BeneÞts may not be as expected or may be declining. Thismay be due to a low on-line time factor, inappropriate objec-tives, changes in the process or unreliable input data.c. The controller may be operating against a constraint whichlimits potential beneÞts. Values assigned to constraints shouldbe evaluated periodically to determine if they can be relaxed. d. The controller may be operating against an unexpectedprocess limitation. If this is the case, the control objectivesmay need adjustment, the model may need to be updated orconstraints may need to be re-identiÞed.e. The controller may be making too many or too large ofmoves or be cycling. This may be indicative of a need forretuning or re-identiÞcation of the model.f. Inputs may not be valid or substituted values are beingused. This is indicative that maintenance of Þeld instrumenta-tion or analyzers may be required.g. Controller functions may be limited by underlying reg-ulatory control loops not being in cascade, or are notperforming acceptably. Tuning or maintenance of thoseloops may be required.

7.5 DOCUMENTATION MAINTENANCE

Several types of supporting documentation for an advancedcontrol application must be maintained and kept up to date. Inaddition to hard copies of these documents, regular backupsof software and data bases should be made and kept in asecure location.

a. Functional and detailed design speciÞcations b. Application conÞguration database and source codelistingsc. Graphics and reports d. Operations instruction and training manualse. Training and certiÞcation recordsf. MOC change control records



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---

12/00



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---

Additional copies available from API Publications and Distribution:(202) 682-8375

Information about API Publications, Programs and Services isavailable on the World Wide Web at: http://www.api.org

Order No. C55701



--`,,``,,``,````,`,,,``,`,,,``,-`-`,,`,,`,`,,`---