Achieving Increased Batch Plant Productivity by the Application of a Multi-Level DCS Solution

Abstract

The application of DCS-based "advanced controls" is a common method of achieving enhanced performance from continuous processes such as refinery units. However, it is less widely recognized, but nonetheless true, that modern DCS systems can include other software tools for the significant improvement of batch plant productivity, product quality, and economic performance. Due to the fundamental processing differences between the two types of plants, unique batch "advanced control" features are required which are different from those used for continuous plants.

ISA batch control standard 588.01 defines a batch Control Activity Model which breaks the process down into the following hierarchical activities:

• Basic Control,
• Unit Supervision,
• Process Management,
• Recipe Management,
• Production Information Management, and
• Production Planning and Scheduling.

A modern, batch-oriented DCS incorporates application features which, when properly applied, can improve batch plant productivity at all of these levels. These features range from special control algorithms to speed reactor heating, to automatic loading of queued recipes to minimize batch cycle time, to paperless downloading of optimal schedules from the corporate ERP (Enterprise Resource Planning) system. This paper gives an overview of the DCS solutions which are available at each level and explores the sources of productivity enhancement which a batch plant might expect to achieve from each.

Continuous Plant Advanced Control

The application of DCS-based "advanced controls" is a common method of achieving enhanced performance from continuous processes such as refinery units. Spawned by the increasing availability of computing power since the mid 1970's and driven by continuously increasing competitive forces, advanced controls have been honed to a real science by the Hydrocarbon Processing Industry and their vendor network ⁽¹⁾. Most successful oil companies view advanced controls as a competitive necessity, and many of their rivals who did not share the vision have dropped by the wayside in the past decade. Designed to improve the plant's economic performance, and sometimes providing payback times of mere months, most advanced controls are specifically engineered to fit the operating characteristics of the plants to which they are applied ^{(2) (3)}.

The majority of these plants operate continuously at steady-state, with the objective of producing a high volume of product at a relatively modest upgrade in dollars per barrel. Multiple products are commonly produced simultaneously from a single unit. Although the product specifications may change on a seasonal basis, a continuous hydrocarbon unit typically attempts to make the same consistent grades of products day after day, week after week. The goal is to keep the unit running, maximize throughput, counteract disturbances, and maintain constant product quality with minimum giveaway ^{(4) (5)}.

As a result, it is not surprising that the advanced controls which one so often hears about consist of increasingly sophisticated mathematical calculations to achieve some, or hopefully all, of the above goals. Consider a few examples. Feedforward control is applied to anticipate and counteract measurable incoming disturbances, thus retaining the process at steady state. Composition controls, or neural networks serving as virtual analyzers, provide quick, on-line compensation for unmeasured disturbances, allowing product quality to remain consistent over long periods of time ⁽⁶⁾. Decoupling networks isolate each control loop from the disturbances of the other loops. With measured and unmeasured disturbances under control, constraint control networks and constraint pushing strategies are installed to ensure that the process unit continuously operates against its limiting constraints, even when those constraints vary from day to night or winter to summer. Alternately, a model-based, multivariable constraint control package might be installed to attack all of the foregoing problems, as well as maximizing product value ⁽⁷⁾. All-in-all, the objective is to keep the unit steady and to consistently make the same product day after day. As we shall see, this differs dramatically from the objectives of most batch process plants.

Batch Operating Objectives

In contrast, one hears much less about the application of "advanced controls" to batch process plants. This is partially due to the high visibility and successful history of advanced control in the Hydrocarbon Processing Industry. It is also due to the fundamental processing differences between the two types of plants, which inherently decrease the effectiveness of many common continuous plant advanced control techniques. A continuous plant attempts to maintain steady-state, whereas the product composition in a batch reactor deliberately varies with time. Continuous plants make the same product for long periods, but batch plants may make numerous different products over the course of a single week ⁽⁸⁾. All of the materials in the units of a continuous plant typically progress into a single, combined product tank. In contrast, each vessel in a serially arranged batch train, or path, may contain material of a different batch with a different recipe, perhaps even for a different customer. The batches progress through the train with a new batch occupying a vessel as soon as the material from the previous batch clears that vessel and moves on to the next unit.

Besides requiring very frequent changes in control logic as each new batch enters the vessel, this situation creates unique requirements for data gathering, trending, and reporting. The reporting package must recognize which batch is in vessel B at a given instant, and at the end of the batch, it must associate that data with the values gathered earlier when that material was in vessel A and later when it is in vessel C. Likewise, the operator interface must permit the operator to view, understand, and control the simultaneous progression of multiple different batches of product through the train.

When it comes to optimization, continuous plants tend to push operating constraints, whereas batch plants push time. Time represents throughput, which represents money. If charge valves can be lined up quickly and automatically, time can be saved. If the control strategy can bring the reactor up to temperature five minutes faster, that represents time saved. If the raw materials for the next batch can be pre-weighed, pre-mixed, or pre-heated while the previous batch is in progress, that represents even more time saved. If the recipe (meaning the procedure and related control strategy) for an incoming batch can be set up immediately after the previous batch clears the vessel, then time can be saved. When a piece of equipment breaks, a large amount of time can be saved if an alternate vessel can be substituted and the original control strategy loaded to the alternate equipment. If the clearing of pipes or the cleaning of vessels can be automated, even more time can saved. Finally, and very significantly, if the completed batch is "on-specification" the first time, valuable time and ingredients may be saved by the avoidance of re-running, reprocessing and performing repetitive laboratory analyses.

Batch operations require high precision. The batch volume is usually relatively small, and a metering error which might go unnoticed on a refinery crude unit can cause a high value batch product to become entirely worthless. When an off-specification batch is created, it often cannot be "blended off' as is possible in the large tanks of a refinery or terminal.

Finally, almost all batch plants require great flexibility. A single process train may be required to run as many as 100-150 different recipes, each requiring its own control strategy. Even when the next several days' recipe queue has been established, it is always subject to rescheduling at the last minute due to changing marketing requirements. New products, and therefore new control strategies, are also continuously developed, and great value exists in the ability to quickly build, test, debug, and implement a new recipe.

It suffices to say that batch plants operate differently, and have different advanced control requirements, than continuous process units. Unique batch advanced control features are required which are distinct from those used for continuous plants ⁽⁹⁾. It is not widely recognized, but nonetheless true, that modern DCS systems can include software tools for the significant improvement of batch plant productivity, product quality, and economic performance.

Batch Control Activity Model

ISA batch control standard S88 defines a batch Control Activity Model, along with various other batch terminology and models. The generic Control Activity Model applies to all batch processes and breaks the control requirements into a set of hierarchical activities.

The Control Activity Model describes all levels of a batch plant's activities. Working upward from the plant sensor, these levels are as follows:

• Process Control
• Unit Supervision
• Process Management
• Recipe Management
• Production Information Management, and
• Production Planning and Scheduling.

A modern, batch-oriented DCS incorporates application features which, when properly applied, can improve batch plant productivity at all levels of the Control Activity Model. A few examples will be explored for each level.

Process Control Features

At the control level, a means is often needed to store recipe setpoint variables, referred to as "formula data" in S88 terms. The instrument blocks of a continuous control DCS are sometimes capable of storing a software generated analog value, but this often requires the block to be placed off scan, thus generating an alarm. In contrast, a batch-oriented DCS includes distinctive batch data set blocks which can receive and store multiple formula data values under a single tagname. Furthermore, the block may be arranged in array format so that an entire second set of values can be written into place via a software switch.

A batch-oriented DCS must frequently provide the ability to transfer a pre-defined amount of material into or out of a vessel. Batching controllers, or batch set units, provide a number of special features to permit such transfers in a precise, safe, and controllable manner. These include ramping the initial flow rate up, totalizing the flow, anticipating the upcoming end of the transfer, ramping the flow rate down, and performing a post-transfer leak check. The batch set unit should be capable of batching material based on a direct flow measurement or on a change in vessel load cell reading.

A frequent batch control problem is the need for different units to share a common device, such as a valve, pump, line segment, or charging header. This situation is easily accommodated if the DCS includes a resource scheduler instrument. The resource scheduler queues the incoming requests for a shared device and manages access according to pre-specified rules. For example, access might be granted to only one user at a time on a first-come, first-served basis. In another case, certain users might be given priority to "bump" less urgent users. The resource scheduler might permit simultaneous access to more than one user, such as a maximum of three vessels filling from a water header.

Another specialized batch control algorithm is the batch PID. Besides providing the same feedback as other HD algorithms, the batch PID permits a vessel to be heated up (or cooled down) as quickly as possible without an overshoot. This is accomplished by special logic which applies a more aggressive control algorithm when the deviation between setpoint and measurement is large and which switches to normal PID control as the temperature approaches the setpoint. Given the earlier statement that time represents money in batch processing, this special instrument has the effect of bringing the batch up to temperature in a faster and more economical manner.

Sometimes, batch processing requirements are quite complex, and it is beneficial if the batch DCS includes a fuzzy logic control instrument. Fuzzy logic generates a control manipulation based on rules, which are in turn stated in terms of linguistic variables. One often publicized feature of fuzzy logic is that when the exact mathematics of a situation are unknown, it permits a satisfactory controller to be established in less time than by traditional continuous control techniques. Although fuzzy logic is sometimes applied in continuous plants, it provides a very powerful solution for batch control problems and is a desirable feature in a batch-oriented DCS.

Unit Supervision Features

Unit Supervision, the next level of the Control Activity Model, refers to the monitoring, control, and operation of a "unit" as an entity as opposed to an unrelated collection of tags. A unit commonly represents a process vessel, such as a reactor, but can in fact represent any related collection of devices, such as a charge header. With Unit Supervision, the user can implement a unit procedure which coordinates the activities of the unit's various valves, pumps, and controllers ⁽¹⁰⁾.

A DCS which supports Unit Supervision includes one or more special unit instrument blocks. These blocks permit an entire unit to be operated as an entity with its own faceplate, mode, status, and alarm conditions. A desirable feature is the ability for the user to define the permissible modes (AUTO, MANUAL, etc.) and statuses (RUN, PAUSE, etc.), as well as the permissible changes between various modes and statuses in a customized State Transition Matrix. For example, the matrix might be configured to prohibit pausing a vessel containing chemicals which would decompose during the pause.

A unit instrument also supports user defined control logic, which is called a "unit procedure." The unit procedure causes different activities to occur on the unit, such as opening valves in a defined sequence, starting pumps, changing temperature and pressure setpoints, or sending messages to the operator. Sometimes, the unit procedure remains the same from batch to batch, as for a water charging header. More commonly, different unit procedures are downloaded from a recipe in order to make differing products in the same process equipment. If the DCS permits the underlying program code to be written using generic names, then each unit can have an association table between the generic names (e.g., AGITATOR) and its own device tagnames (e.g., 304AG1201). Thus, the code need only be written once, and it can be automatically reused by all units which require agitator control.

Just as a PID instrument contains tuning constants, a unit instrument supports a variety of system defined and user defined data values. These data are used to help the operator understand the current batch activities, provide constants used by the unit procedure calculations, and capture information for reporting purposes. Examples of unit data might be the name of the currently executing recipe, the recipe start time, the current recipe step number, or the physical dimensions of the vessel for a level-to-volume calculation. A user with proper login security may be permitted to change the values of selected unit data items, making it much easier to alter a unit calculation than by editing and recompiling constants embedded in the underlying code of the unit procedure.

Operator interface features are especially important in a DCS with Unit Supervision. Automatically generated displays include Sequential Function Charts (SFC) which permit the operator to see the past, current, and upcoming steps, and even follow the progress of the underlying program code within the active step. Window displays of this type greatly enhance the operator's understanding of the recipe.

In addition, the DCS must provide unique operator messaging features which are not normally required for continuous control. Most DCS's support the ability to trigger a pre-defined operator guide message, but a batch DCS also frequently needs to receive input from the operator using dialogue messages. For example, the operator may verify that certain ingredients have been manually added to a catalyst tank and may be required to enter the actual number of pounds and/or the ingredient lot number. In other cases, the DCS may present the operator with a menu of various choices, such as the option to use A or B pump or the permissible tanks to receive the batch product.

Process Management Features

Process Management allows the operator to initiate, monitor, and control an entire batch as a single entity as opposed to a collection of individual unit procedures. It also permits a collection of units to be arranged into various batch processing arrangements, referred to as lines, trains, and paths. Thus, Process Management builds upon the Unit Supervision features of a batch-oriented DCS.

A fundamental feature of Process Management is the ability to generate, download, and operate a control recipe, consisting of coordinated activities to be performed in multiple batch units. A control recipe is often based on a pre-defined master recipe created by Recipe Management (described below). During the creation of the control recipe, some of the master recipe's formula data values may be deliberately altered to cause slightly different processing, and the control recipe is assigned a Batch Identification Number (Batch ID). The control recipe is downloaded and executed to create a single specific batch of product.

A batch-oriented DCS includes special Process Management display screens to permit the operator to select the desired master recipe, modify any desired formula data values, add the recipe to a recipe queue, and either manually start the control recipe or schedule it to automatically start based on time of day or equipment availability. After the recipe becomes active, additional Process Management windows are provided to permit the operator to view the overall status of the control recipe and of each batch unit's individual unit recipe. Another desirable feature is the ability to change the status of the recipe as a whole (e.g., from RUN to PAUSE) instead of having to individually change the statuses of the unit instruments which are executing the various unit recipes.

In addition to enabling a plant's process units to be classified into lines, trains, and paths, Process Management should permit the operator to select alternate vessels (that is, an alternate path) for running a given batch. Such capability enhances the batch plant's productivity because a given recipe no longer must wait until specific vessels are available. Instead, the recipe can be executed on an alternate path if one or more of the normal vessels is under maintenance or already occupied by material from a different batch. Obviously, any vessel cannot serve all purposes, and Process Management addresses this limitation by permitting the recipe to specify which pieces of process equipment are permissible for each portion of the batch.

Finally, when the activities of the individual batch units in making a product are coordinated into a recipe, it is possible for Process Management to gather information in a batch-oriented manner instead of the usual time contiguous manner. The data are usually associated by Batch ID. These data may consist of formula data and setpoint values, operator messages and responses, process events, process alarms, recipe and part-recipe start and stop times, and batch trends. The data are displayed on the DCS during the batch and may be passed to the Production Information Management level at the end of the batch.

Recipe Management Features

Recipe Management provides the environment and tools for creating, modifying, and storing new recipes. Although several types of recipes exist, the one most commonly stored at the DCS level is called a master recipe. As described above, the master recipe contains all of the information for generation of a control recipe to run on a specific line of a specific plant.

A recipe consists of four general parts: the header, the recipe formula data, the recipe procedures for each unit, and the recipe's equipment requirements. A DCS which supports Recipe Management should include builders for creating all four of these parts.

The recipe header is important even though it does not include any executable control instructions. The header includes the recipe name (or number) and various information which is important for recipe tracking, such as the name of the person who created the recipe, their comments, the creation date, the revision number, revision date, etc.

The recipe formula data are the various setpoints, ingredient quantities, ingredient names, device open/close or on/off flags, wait times, flow rates and other variables which are required for the control system to make the desired end product. It is desirable that the DCS be able to accommodate formula data in integer, real, or character string format--thus permitting an operator message to be entered by the recipe engineer without hard coding that instruction permanently into the DCS. Another very useful feature is the ability to store formula data in arrays, such as a series of agitator speeds. This allows a piece of program code (such as that which controls agitators) to be used by multiple units with agitators and still call upon unique formula data values in each instance.

The recipe procedures are the actual batch control logic for each unit instrument, such as:

• Charge ingredient from header
• Add water
• Start agitator

Each batch unit utilized to make the recipe may have its own unit (or part) recipe procedure, or some units (such as a water header) may have a fixed procedure which is not defined by Recipe Management. Recipe procedures are conveniently built using graphical Sequential Function Charts. The system should permit recipe procedures to include branches, parallel operations, and user definable transition conditions for proceeding to the next step.

Production Information Management Features

roduction Information Management receives, manages, displays, and permits analysis of data gathered during the execution of a batch. This information is often gathered by DCS functions, such as Unit Supervision and/or Process Management, with the data being grouped according to Batch ID. Batch information may consist of alarm logs, event logs, operator action logs, batch trends, and batch journal data in addition to process data collected specifically for the batch report.

At the DCS level, the production information is typically used to generate a customized batch report. In addition to obvious items such as Batch ID and ingredient quantities, a batch report commonly contains batch starting and ending times and temperatures or pressures gathered at key moments during the batch. The DCS may also append the batch journal and batch trends to the report.

It is important for the DCS to be able to export production information files to higher level MES (Manufacturing Execution System) and ERP (Enterprise Resource Planning) systems. A PIMS (Plant Information Management System) at the MES level provides valuable analysis capabilities such as displaying single batch and multi-batch trends, permitting batch comparisons by overlay or side-by-side displays, and comparing a given batch with a previously defined "ideal" batch profile. At the DCS level, it is important that the data be gathered and stored according to Batch ID instead in a time contiguous manner. The batch information file should be retained on the DCS for a sufficient time, so that no data are lost if the MES system is temporarily down when the batch is completed.

Additionally, batch data from the DCS provide valuable feedback to Production Planning and Scheduling systems. Accurate model initialization data and production information are required from the DCS to permit the production planning package to predict stock, unit, and inventory levels and to detect potential stock and utility limit violations. If the production schedule is being generated, monitored, and rescheduled in real-time by a remote operator, the batch-oriented DCS must also have the ability to capture and transmit the current recipe, Batch ID, and status information of each batch unit on a frequent, periodic basis. This feature permits the remote scheduler to determine which batch is currently running and when it is expected to finish.

Production Planning and Scheduling Features

In addition to uploading batch information, the DCS should provide the capability to receive and execute production schedules from the Production Planning and Scheduling system. This may be a centralized, third party system, or may be a more tightly coupled operation scheduling system provided by the DCS vendor. With differing degrees of rigor and cost these systems contain models of the batch process which permit the user to evaluate effects of changes in production schedules or process equipment.

For those corporations embarking upon an enterprise-wide solution, such as SAP, it is essential to select a DCS which provides a full-featured, certified interface package. Such a package must support efficient, menu defined correlation of the DCS tagnames with the corresponding SAP naming conventions. Even with a certified interface, a joint feasibility study involving the vendor and the end user's SAP team is advisable to ensure compatibility with the peculiarities of the specific implementation.

Individual batch operating plants often find a more feasible balance between cost, rigor, and maintainability from a more tightly coupled, vendor supplied Production Planning package. A typical package permits the plant situation to be defined in terms of facilities, recipe ingredient requirements, product make, processing times, utility consumption, and operating calendar. Then, a simplified scheduling strategy, stated in linguistic rules, is selected. Based on this input, a GANTT chart schedule is generated along with simulated stock, unit, and utility levels. The schedule can be manually adjusted, either by drag-and-drop manipulation on the GANTT chart, or by altering the strategy rules. When an acceptable schedule with no constraint violations has been generated, the pertinent data are electronically downloaded to the Process Management recipe queue in the DCS.

Whether local or enterprise wide, the DCS's ability to integrate with, and receive electronic schedules from, such systems makes a positive impact on any batch company's flexibility, market responsiveness, and time to market.

Summary

In conclusion, it is clear that the operating characteristics and objectives of batch plants differ from those of continuous process units. These differences, in turn, cause many of the popular and well-publicized advanced control techniques to be less effective for batch use. However, the batch control industry has its own very specialized "advanced control" tools, a large number of which are embedded in a modern, batch-oriented Distributed Control System. When properly applied at all levels of the Control Activity Model, such a DCS can greatly enhance the competitiveness and economic return of a bulk chemical, specialty chemical, or pharmaceutical organization whose profitability relies on batch processing.

References:

1. Christie, D., "Advanced Controls Improve Reformulated Fuel Yield and Quality," Fuel Reformulation, July/August 1993.
2. Jensen, B., "Improve Control of Cryogenic Gas Plants," Hydrocarbon Processing, May 1991.
3. Gibbons, C. and Kania, C., "Online Optimization for an Ethylene Plant," ISA Proceedings, 1990.
4. Christie, D. and Holden, D., "Fluid Cat Cracking Units' Advanced Control Can Achieve Benefits in Six Areas," Oil & Gas Journal, September 25, 1989.
5. Collins, P. and Jensen, B., "Incentives for Tighter Fractionator Control," Control, November 1990.
6. Blaesi, J. and Jensen, B., "Can Neural Networks Compete With Process Calculations?,"Intech, Volume 39, Number 12, pg. 34.
7. Gaines, L., McGee, N. and Kettinger, J., "Multivariable Control of a Depropanizer," ISA/91 Advances in Instrumentation and Control, Volume 46, Part 1, pg. 159.
8. Bryant, S., "Oil Plant Blends Advanced Automation With Innovation," Control, September 1993.
9. Christie, D., "A Methodology for Batch Control Implementation - Real World Lessons," presented at World Batch Forum, April 1998.
10. Korkmaz, B. and Pillai, V., "Unit Supervision - A Key Component in Process Management and Process Control," presented at World Batch Forum, April 1998.