Process Control and Optimization, VOLUME II - Unicauca

single equipment path for a batch or multiple pos- sibilities, of ..... Additionally, when purely manual actions are required, the .... is still zero, FIC-101 is switched back to manual (t4). .... In order to maximize future reuse, specifications for each.
312KB taille 36 téléchargements 220 vues
8.8

Chemical Reactors: Batch Sequencing D. C. KENDALL, W. F. SCHLEGEL B. G. LIPTÁK, F. MOLNÁR

(1995)

(1970)

H. I. HERTANU

R. A. DWIGGINS

M

(1985)

(2005)

Flow sheet symbol

INTRODUCTION This section concentrates on batch reactor automation and its component parts. Batch processes in general are covered in Sections 8.3 (Batch Control Description, Terminology, and Standard S88) and 8.4 (Batch Processes and their Automation). These sections should be studied when integrating a chemical reactor into a larger processing facility or into the whole plant. Refer to Section 8.9 (Chemical Reactors: Control and Optimization) for the regulatory control and optimization strategies associated with chemical reactors, including the control of temperature and pressure and the determination of reaction endpoint. Section 8.10 (Chemical Reactors: Simulation and Modeling) describes the modeling and simulation of chemical reactors. The various aspects of DCS-based batch control systems were discussed in Chapter 4. Control issues associated with external heat transfer equipment and transfer pumps are further described in Sections 8.11 (Chiller Control), 8.28 (Heat Exchanger, Condenser, and Evaporator Controls), and 8.34 (Pump Controls and Optimization). Many reactions require control of dissolved oxygen, redox potential, pH, or inerting systems, which are respectively covered in Sections 8.1 (Aeration and DO Controls), 8.31 (ORP Controls), 8.32 (pH Control), and 8.29 (Inerting Systems). A batch process produces discrete quantities of material in a discontinuous fashion, such that the equipment states, process conditions, and batch composition vary with time. The starting of a pump, the opening of a valve, the completion of charging of a particular material into the reactor, and the reaching of the endpoint of a reaction are all events in time, requiring different operator responses and automated control actions. Designers and users of batch control systems must deal with time-varying process conditions and transition phenomena. The control system will frequently serve the creation of multiple products and accommodate idle times between batches. Start-up and shutdown procedures are integral to the operation of each batch and are often automated to improve cycle time (for higher throughput) and repeatability (for quality and regulatory compliance). Preparatory procedures that must execute periodically or before every batch, such as cleaning, sterilizing, and pressure testing, may be automated as well. 1640 © 2006 by Béla Lipták

Batch chemical processing has increased in importance in those industries that manufacture low-volume and highvalue-added chemicals. The main advantage of batch processes is their great flexibility and rapid response to changing market conditions, but their unsteady-state operation makes tight quality control difficult. In these markets, increased customer demand for rapid commercialization of differentiated high-quality products has fueled the construction of highly flexible and highly automated batch facilities.

BATCH CONTROL CHARACTERISTICS Sequential control encompasses all control functions (discrete and analog) triggered by events (time-based or processbased), whether normal or abnormal. In its simplest form, this comprises basic control functions analogous to those seen in continuous processes and relies on the operator to coordinate all control actions and status reporting required before, during, and after each process step. This can be overwhelming, causing overall performance to deteriorate. In a fully automated batch plant, these coordination functions are executed by the control system for multiple simultaneous batches queued from a production schedule, using preprogrammed product-specific material, equipment, and processing requirements for each batch. Traditional batch automation is characterized by high project costs, lack of revision flexibility, and difficulties in maintaining the system. A desirable batch automation system, on the other hand, is easy to use and modify by the chemical and production engineer. It is also standardized and therefore can be designed by configuration and not by programming, plus it avoids costly maintenance and support associated with custom software. A desirable system should also be hierarchically built from a reusable library of preprogrammed and user-definable modules (application objects), so as to further simplify application development and eliminate re-engineering of commonly used components. As shown in Table 8.8a, the automation of batch reactors can be structured in layers. Table 8.3b and Figure 8.4d have also defined such levels or layers. This section will discuss

8.8 Chemical Reactors: Batch Sequencing

The product that is produced by one execution of a recipe. CAMPAIGN The total production run of one product, for example, for a single order or season, consisting of one or more lots. COMMON RESOURCE An equipment entity that services more than one unit, either simultaneously (shareduse resource) or one at a time (exclusive-use resource). CONTROL MODULE Lowest-level equipment grouping that acts as a single entity from a control standpoint, but cannot execute procedural elements. May be an individual measurement (with suitable signal conditioning or state names) or a grouping of directly coupled actuators with their associated measurements, alarms, and control actions, including subordinate control modules as appropriate. Examples are an uncontrolled temperature, a flow control loop, an automatic block valve with limit switches, or a header containing interlocked (mutually exclusive) block valves. COORDINATION CONTROL Control functions existing at multiple levels to schedule batches and manage recipes, procedural control execution, equipment entity allocation, and batch data. EQUIPMENT CONTROL The procedural, basic, and coordination control capability that enables an equipment entity to perform its function. It is not part of a recipe, but may be directed by a recipe. EQUIPMENT ENTITY A set of process and control equipment and associated control capability that has been grouped together to provide some specified process or equipment functionality. EQUIPMENT MODULE An equipment entity incorporating necessary devices, control modules, and application-specific states and modes to execute some basic process-oriented task or group of tasks. May include equipment procedural elements (typically phase logic) or subordinate equipment modules, but may not overlap other equipment modules. Examples are a common (exclusive-use) weigh tank, a recirculation/transfer pump within a unit, and a shared-use ingredient dosing system. FORMULA The list of process inputs, outputs, and data (operating set points, reported values, timing) required to execute the batch procedure. LOT A collection of batches prepared using the same recipe. Typically, all batches of a lot are prepared from the same homogeneous source of raw material. OPERATION A major programmed processing action or set of related actions, normally consisting of one or more phases. PHASE The lowest level of procedural control to accomplish a process-oriented task. Phases may be further subdivided into equipment-oriented steps and transitions for executing a defined task, as described in BATCH

TABLE 8.8a Five Levels of Batch Automation Process

Control

Plant

Plant management

Production

Batch scheduling, resource allocation, and reporting

Unit

Recipe-based unit control

Basic operations

Equipment control

Devices

Regulatory sequences, and discrete control safety interlock

the bottom three levels in Table 8.8a, which corresponds to Levels 2 and 3 in Table 8.3b. For detailed information about the automation of higher-level functions relating to production and plantwide automation, refer to Sections 8.3 (Batch Control Description, Terminology, and Standard S88) and 8.4 (Batch Processes and their Automation). BATCH CONTROL STANDARDS As covered in Sections 8.3 (Batch Control Description, Terminology, and Standard S88) and 8.4 (Batch Processes and their Automation), standards for batch and sequential automation have been prepared by the ISA SP88 Standardization Committee (1988, USA), based upon earlier work of the NAMUR Advisory Committee on Instrumentation and Control (1986, Europe). The American National Standards Institute and the International Electrotechnical Commission have adopted the recommendations of the SP88 committee as U.S. Standards ANSI/ISA S-88.01 (1995), 88.00.02 (2001), and 88.00.03 (2003) and with minor revisions as European Standards IEC 61512-1 (1997) and 61512-2 (2001). These standards have enabled industrywide development of project methodologies and batch control system capabilities that facilitate organizing, communicating, and implementing batch automation requirements, and enable efficient skills transfer and database portability among disparate platforms. These developments should be taken into consideration when designing the automation of chemical batch reactors. Standard Terminology The following summarizes some of the core terminology identified in the international Purdue Workshop on Industrial Com1 2 puter Systems and the ISA S88.01/IEC 61512-1 standard for precise definition, discussion, and solution of batch control problems: Continuously executed algorithms that drive the process or equipment to a specified state and keep it there, such as indicators, regulatory and device controls, and interlocks.

BASIC CONTROL

© 2006 by Béla Lipták

1641

1642

Control and Optimization of Unit Operations

European Standard IEC 60848 (1988) for specification of sequential function charts. Normally, the phase boundaries represent points of process transition, hold, or activity. The boundaries define major milestones and possible points of safe intervention. Phases may exist either as part of a recipe procedure (recipe phase) or independently for equipment control (equipment phase); however, any constituent steps are always part of the equipment phase. PROCEDURAL CONTROL Control that sequentially directs subordinate procedural elements or basic controls to execute the steps required by its defined processoriented task. PROCEDURE A user-defined set of instructions that define the strategy for making a single batch of a particular type or grade of product. PROCESS CELL A grouping of equipment that comprises one or more complete trains and defines the immediate local domain for production scheduling (analogous to a work cell in discrete manufacturing). RECIPE The complete set of data and operations that define the control requirements for a particular type or grade of final or intermediate product. Specifically, each recipe comprises a header, formula, procedure, and equipment requirements. TRAIN A grouping within one process cell of units and associated lower-level equipment that is capable of making a batch of material. A train may define a single equipment path for a batch or multiple possibilities, of which one will be selected based on availability during execution of the control recipe. Multiple batches can be processed simultaneously in the same train (but different units). UNIT An equipment entity that contains and performs some major processing activity or activities (e.g., react, crystallize, make solution) on one batch at a time. A unit normally comprises a major piece of equipment and directly associated control modules or equipment modules that are not shared with other units. UNIT PROCEDURE A major programmed processing action or set of related actions, normally consisting of one or more operations. Unit procedures are naturally related to a distinct regime of production: for example, all processing carried out in one batch unit of a multiunit production line.

BATCH REACTOR CONTROL Regardless of whether the ISA S88/IEC 61512 standards will be fully applied in the automation of a particular batch reactor, their basic concepts should be understood to provide a common basis for analysis, modularization, and communication of the control requirements. The following summary identifies key points of Sections 8.3 (Batch Control, Terminology) and

© 2006 by Béla Lipták

Corporation

Plant

Area

Train

Unit

Equipment module

Control module

Element

FIG. 8.8b The equipment model of hierarchically grouped physical assets.

8.4 (Batch Processes and their Automation) that are required to discuss batch reactor control in this context. The physical assets of a manufacturing enterprise are hierarchically grouped within a physical model into the following levels: enterprise, site, area, process cell, unit, equipment module, and control module (Figure 8.8b). The ISA S88/IEC 61512 documents identify a standard structure for batch control at the bottom four levels of this hierarchy (see Definitions above). Suitable decomposition of process cells into units, equipment modules, and control modules underpins successful application of the standards, as does the long-term development of well-constructed specification and component libraries for recurring module and procedural element functionalities. Table 8.8c illustrates how the various conceptual models defined in the standards and summarized below align with this physical model. Control Concepts Batch control spans multiple levels of the physical model and comprises three distinct types of control:

8.8 Chemical Reactors: Batch Sequencing

1643

TABLE 8.8c Conceptual Model Relationships in ISA S88/IEC 61512 Physical Model Structure

Batch Control Concepts

Process Model Structure

Procedural Model Structure

Recipe Types

Enterprise

General recipe

Site

Site recipe

Basis of Recipe Procedure Definition Process model (general processing requirements)

Area Process cell

Unit*

Coordination control

Procedural control

Master recipe Process

Procedure

Process stage

Unit procedure

Process operation

Operation

Process action

Phase

Control recipe

Procedural model (procedure to deploy process model using available equipment)

Equipment module* Basic control Control module* * May comprise common resources that service multiple units, either simultaneously (shared-use resource) or one at a time (exclusiveuse resource).

Basic control is responsible for establishing and maintaining associated process and equipment variables in defined states based on external commands, analogous to continuous process control. It comprises continuously executed functions of control modules and equipment modules such as process indication, regulatory (including PID, fuzzy, multivariable, and custom algorithm) and discrete control, interlocking, and cyclic operations (such as sump pump or bag house solenoid control). These control functions may be executed automatically, manually, or external to the control system. Procedural control comprises both equipment-specific (equipment control) and product-specific (recipe control) functions that are hierarchically organized to determine the execution order of equipment phases and, through those phases, provide supervisory commands to basic control. Recipe control requires definition of a procedural control element at the recipe procedure level and supporting equipment phases at the unit or equipment module level, with peer-to-peer transference from recipe control to equipment control occurring at some level of the recipe and equipment procedure hierarchies. Coordination control operates primarily at the process cell level to schedule batches and manage recipes, procedural control execution, entity allocation, and batch data. Status, availability, and control mode propagation (downward or upward in the control hierarchy), however, are parts of coordination control that are best managed by the equipment entities themselves (units, equipment modules, and control modules). Recipe Types A recipe typically defines the product-specific procedural control requirements for producing a single batch of a specific

© 2006 by Béla Lipták

product. Additional recipes may be defined to separately schedule ancillary activities for production equipment, such as cleaning and sterilizing. Four standard recipe types defined at various levels of the physical model are used as follows: General recipes are defined at the enterprise level and tightly controlled by R&D to standardize the process across multiple sites and support multisite production planning. These material-centric recipes define a complete process from raw materials or intermediate products to final product and are generally represented in material-centric Process Procedure Chart (PPC) notation defined in Section 7 of ANSI/ISA-88.00.03. Site recipes are defined in PPC notation based on corresponding general recipes, with some added site-specific information. They standardize the process across the site, support long-term production scheduling, and reflect only that portion of each general recipe that can be executed locally. Master and Control Recipes Master recipes unique to each product or intermediate product made in each process cell are constructed from corresponding site recipes either manually or automatically, reflecting only the portion of the production activity that can be completed in that cell. These standardize the actual production procedure to be used based on the type of equipment available in the process cell and support detailed production scheduling. Master recipes are generally represented in equipmentcentric Procedure Function Chart (PFC) notation defined in Section 6 of ANSI/ISA-88.00.02. Ancillary master recipes may also be defined to efficiently schedule and execute productindependent recipes for such activities as equipment cleaning

1644

Control and Optimization of Unit Operations

and sterilization, which are excluded from general and site recipes because they are not process-related. Control recipes are batch-specific and identify the specific equipment used to make the batch. They are normally created by a batch server from the corresponding master recipe upon scheduling and initialization of each batch and include all associated schedule details, parameter changes, and results. Recipe Structure Each recipe is defined by four basic elements, with a fifth category for ancillary design and operation data. The content of each category varies with recipe type as follows: Header contains administrative information (e.g., recipe name, product identification, and version control). Procedure hierarchically defines the processing strategy, based on the process model (process, process stage, process operation, process action) for general and site recipes and based on the procedural model (procedure, unit procedure, operation, phase) for master and control recipes. Each level of the hierarchy is defined by a recipe-specific series and parallel combination of subordinates and transition conditions. Equipment requirements are listed for the entire batch and for each procedural element. These comprise design data in general and site recipes (such as materials of construction and design temperatures) vs. selection criteria for master and control recipes (such as first available sterilized “type 2” reactor). Formula comprises all parameters to properly execute the procedure. All recipe types require process operating conditions, but general and site recipes may include acceptable parameter ranges and detailed heat and mass balances vs. master and control recipes with settings related to the local equipment type and capabilities. General information, optionally provided, can range from special safety considerations and conceptual process flow diagrams in general and site recipes to links to material safety data sheets, standard operating practices, and P&IDs in master and control recipes. Programming Concepts Three underlying concepts that also must be understood for successful implementation of these models relate to objectoriented programming, object commands and states, and exception handling. These concepts apply to the models described above as follows: Object-Oriented Programming The power of the S88 models lies in the separate layering, modularity, and reusability of equipment and procedural elements. Object-oriented programming is an enabling technology for efficient implementation (and specification) of these structures, whereby the functionality (including commands and state definitions), data links, and parameters associated with each control element are encapsulated in a single object.

© 2006 by Béla Lipták

Similar objects may be generated through simple replication with new data links and parameter values, but this creates multiple copies of the program that must be individually corrected and retested for validation. If the same objects are instead instantiated from an object class with the same properties, then a single copy of the source code provides the designed functionality. In this case, full validation is required for only one instance and data links and parameter values checked for all instances. Combining object classes with minor functional differences into a single class can yield even greater efficiency. Depending upon the target system capabilities, this may be accommodated through either additional parameters or subclasses. Following validation, the specifications and code for each object class and subclass should be stored in a library for reuse on subsequent projects. Object Commands and States State is defined in S88.01 as “the condition of an equipment entity or of a procedural element at a given time.” Equipment states are represented by user-defined enumerations, which normally relate to availability for units (e.g., reactor with states of dirty, clean, sterile, and out of service) and combinations of input/output (I/O) states for control modules (e.g., block valve with states of open and close) and equipment modules (e.g., pumping station with states of stop, recirculate, and transfer). Unit objects do not normally receive commands, as in principle they are just containers for lower-level entities and procedural elements. Control module and equipment module state commands comprise requests to set the module’s output(s) to the indicated state, based on an internal lookup or hard-coded correlation (note that the outputs are not commanded directly, and the receiving module ultimately decides if the requested transition is permitted). Phase objects have a standard set of states and commands, which usually corresponds to the example given in S88.01. Under this model, the phase executes normal logic and monitoring functions in the running state and optional exception logic in the pausing, holding, stopping, or aborting state before entering the quiescent paused, held, stopped, or aborted state, respectively. These state transitions may be triggered by the operator (if permitted by system security) or automatically (via its internal exception monitoring functions or cascaded from higher-level procedural elements) and may be required to cascade upward through the procedural hierarchy. Higher level procedural elements have the same state enumerations and propagation capabilities, but generally handle exception conditions through normal transition logic. Exception Handling Exception handling is defined in S88.01 as “those functions that deal with plant or process contingencies and other events which occur outside the normal or desired behavior of batch control.” Due to transient behavior of batch processes, they are inherently more problematic to operate than continuous units and must respond appropriately

8.8 Chemical Reactors: Batch Sequencing

to a large number of possible failures in the context of what is happening at the time. The problems encountered may relate to unavailability of material or equipment, process problems, or equipment malfunctions. This occupies a large portion of the control definition and is usually underestimated by engineers lacking batch control experience. Pushing exception handling as far down the control hierarchy as possible and maximally utilizing low-level object classes simplifies the task by minimizing the amount of detail required in supervisory logic. For example, process alarms and device failures (e.g., failure to reach the commanded state) should be monitored and alarmed by the responsible control modules and responded to by operational interlocks. Exception handling by associated phase logic need only enable and adjust any process-dependent alarm settings, confirm that commanded device states are permitted, and trigger its own exception logic when warranted. If recovery requires aborting one phase and executing another (such as reheating to reaction temperature following a feed loss and subsequent cool-down in a semibatch operation), then it must be dealt with manually or through appropriate transition logic above

1645

the phase level. Either way, appropriate interlocks must be present at the control module level (e.g., to prevent feed resuming below minimum temperature).

SEQUENCING LOGIC CONTROLS A batch reactor control system is a combination of analog and discrete control functions supervised by procedural control logic. The various analog loops used in reactor control are discussed in Section 8.9 (Chemical Reactors — Control and Optimization). The discrete controls provide the capability to turn things on and off, and the procedural controls serve to initiate and step through the various process phases in logical sequence, as shown in Figure 8.8d. The equipment phases in a unit or common resource execute distinct minor processing activities in the batch cycle, such as charge, mix, heat, and transfer. Equipment phase logic details can be reduced to a timeordered combination of a few basic state transitions, resulting

Make polymer

(a)

Reactor initialization

Charge solvent and monomer Hold tank ready to transfer

Polymerizer ready to transfer Allocate polymerizer

Allocate hold tank

Vent

Sparge and purge

Allocate dryer Heatup

Wait for >1000 lbs solvent charged

Charge solvent Polymerizer

Hold tank

Dryer Add initiator and polymerize

De-allocate polymerizer

Allocate hold tank

Charge monomer

Allocate dryer

Mix

Transfer

(b)

(c)

(d)

FIG. 8.8d The sequence of steps required to produce a polymer product are shown in a hierarchy of increasingly detailed Procedure Function Charts (PFCs). These PFCs are comprised of recipe procedural elements down to the phase level for one operation of one unit procedure in a recipe: Procedure for recipe “Polymer X,” (b) PFC for procedure “Make polymer,” (c) PFC for unit procedure “Polymerizer,” (d) PFC for operation “Charge solvent and monomer.”

© 2006 by Béla Lipták

1646

Control and Optimization of Unit Operations

from the procedural steps described in Figure 8.8d. These actions are listed below:

Batch sequencing A

1. 2. 3. 4.

5. 6. 7. 8. 9. 10.

Operate on/off devices (pumps, valves, and so on) Activate or deactivate control loops Open and close cascade loops Supply control loop parameters, such as set point, ramp rate, alarm limits, tuning parameters, and flow integrals Integrate flows Initiate times or delays between processing steps Perform calculations Compare values, measurements, and test indicators and branch according to the results of the comparisons Initiate alarm status or operator messages Release control if nothing more can be done until the next sequencing interval

It is important to note that the data acquisition and loop control functions are not included as part of the phase logic. Rather, the equipment phase logic plays a supervisory role, communicating changes to the control modules and equipment modules as required in the same way that an operator would adjust set points and alarm limits during the course of a batch. In turn, the execution of equipment phases within each unit is coordinated and parameterized by the currently operating control recipes (or in some circumstances by the operator). Additionally, when purely manual actions are required, the phase will trigger an operator message to perform the activity and confirm after it is complete. Figure 8.8e gives a specific example of the above generalized description. The upper portion of the illustration shows the physical equipment involved, including the nine controlled devices whose states are being logically sequenced. The lower portion of the illustration identifies the sequenced process states. During process state A the required quantity of raw material A is being charged. The prerequisites for the initiation of state A are that 1 and 4 be on and 6 be off. This means that the agitator must be on, the vent valve must be open, and the drain valve must be closed. When these prerequisites are satisfied, state A is initiated by turning 2 on. This means that the charge valve of reactant A is opened and a control loop, such as that shown in Figure 8.8f, is activated. The required quantity of this ingredient is set by the recipe as QA. When this target is reached, process state A is terminated and process state B is initiated, which then performs its own tasks defined by the sequencing logic. In a more sophisticated reactor control system, the number of controlled devices and the number of logical sequence steps is much greater, but the basic concept is the same.

B

K

FT

3

9 S

FT

2

© 2006 by Béla Lipták

5

PIA 1

TIC 8

7

Steam

Cond.

Process equipment

1 6 4

6

QB

QA A

B

C

1 2 3 Process state sequencing logic 1 2

1 - Agitator 2 - Feed “A” valve 3 - Feed “B” valve 4 - Vent valve 5 - Vacuum source valve

1 3 6

D 1 5 7

P = P1 7 E 1 8

Controlled devices 6 - Drain valve 7 - Steam vent valve 8 - Temperature control valve 9 - Catalyst valve

FIG. 8.8e Example of batch reactor sequencing logic. On top is the physical equipment used; on the bottom is a flowsheet of the sequenced process states.

and site recipes, which are respectively defined in the S88.00.02 and S88.00.03 standards. S88.00.03 also defines a more convenient tabular method that may be used in lieu of the PFC or PPC to specify procedural logic that is not highly branched. This method simply lists the operations and phases in sequence, using icons and path numbers to identify each parallel series of steps. A simple example of a PFC is illustrated in Figure 8.8d. The triangles at the top and bottom of each PFC represent

FQ 101

FIC 101

FY 101

I/P XV−1

FT 101

Recipe Procedures The standard graphical notation for representing complex procedural control is the Procedure Function Chart for master and control recipes and the Process Procedure Chart for general

4

FIG. 8.8f Flow control loop for charging reactant A.

Reactor

8.8 Chemical Reactors: Batch Sequencing

its start and endpoints and rectangles indicate the procedural elements, with corner markers distinguishing the symbols for a procedure, unit procedure, operation, and phase. Ovals are used to indicate equipment allocation steps, and connecting arrows represent the sequence in which procedural elements are initiated at the next lower level, upon the prior element completing its execution. Transition markers, indicated by a short double line, may be inserted at any point to provide additional conditions for initiation of the subsequent element. (Note that a procedural element may be notified when the transition below it goes TRUE, which provides a simple mechanism for requesting early termination of that element.) Parallel paths with a connecting double line above and below, as illustrated in Figure 8.8d(d), are initiated simultaneously and executed independently, with control passing beyond the endpoint after all paths have completed their execution. Branching (not illustrated) among two or more alternative paths is possible simply by splitting the connecting line and placing a transition condition at the start of each path. This feature can be used in a reaction operation, for example, to repeat periodic catalyst booster charge and product sampling phases until a satisfactory lab result is obtained (i.e., operationlevel exception handling). Procedure Function Chart Execution Execution of the illustrated procedure will be as follows. Procedure “Make Polymer” in Figure 8.8d(a) commences operation when a batch has been scheduled to execute on some train (which may specify a single product path or multiple options), initialized, and started. Figure 8.8d(b) specifies parallel execution along three paths for different unit procedures. The first branch causes an immediate attempt to allocate a polymerizer for the batch, selected polymerizers in the designated train. If no polymers are immediately available (i.e., they are in use for other batches) or none are in the correct state (e.g., they have been cleaned by a separate equipment recipe that manages equipment and cleaning fluids), execution is suspended pending allocation of a polymerizer for the batch. The next step initiates the polymerizer unit procedure and waits for it to complete before deallocating the unit. Meanwhile, the parallel path for the hold tank waits for the transition condition “Polymerizer ready to transfer,” which becomes TRUE when the polymerizer reaches its transfer phase. (Because this phase must work in tandem with the hold tank’s charge phase to move material between the units, it is necessary that both units be allocated to the batch during the transfer and that the unit procedures appear in parallel on the PFC. The transition condition prevents premature allocation of the hold tank, which might rob the unit of valuable operating time on another batch.) After the transition goes TRUE, the hold tank unit level sequencing is analogous to the polymerizer (except that connecting pathways are also validated before allocating a hold

© 2006 by Béla Lipták

1647

tank); likewise for the dryer after “Hold tank ready to transfer” is satisfied. The “Make polymer” procedure is complete when all three paths have fully executed. Continuing with this example, execution of one unit procedure, “Polymerizer,” triggers the PFC sequence illustrated in Figure 8.8d(c), in which each operation simply begins and executes to completion after its predecessor is complete. The “Polymerizer” unit procedure is complete when the entire series of operations is finished. The details of the “Charge solvent and monomer” operation, illustrated in Figure 8.8d(d), reveal how the recipe ultimately sequences the phases. The progression of series and parallel execution for this typical operation is analogous to that described previously for the unit procedure. The mechanism for control propagation, however, differs significantly in that recipe phases merely contain parameters, links to equipment phase parameters, and equipment phase states and commands, with all of the procedural details located in the equipment phase. Moreover, these links are established only at run time within the control recipe, based on the currently allocated units for the associated batch. This is because each recipe phase (productspecific) must be able to interface with any corresponding equipment phase (equipment-specific) that might be selected to run the product. Likewise, each equipment phase can be commanded at different times by a number of recipe phase instances, which may appear in the same or different recipes. Although the recipe phases and equipment phases belong to different object classes, this interface requires that all phases that are defined in the recipe unit class be present in the equipment unit. The corresponding phases in different equipment units need not be of the same object class, provided they expose the same parameter interface for the recipe phase. (It should be noted that this transference from recipe to equipment control may be done at any procedural level, but it usually occurs at the phase level and is discussed here only in that context.) Equipment Control Sequence Logic The sequential control functions of equipment phases, equipment modules, and control modules represent the heart of batch control functionality and the vast bulk of control software that must be defined and implemented. Various tools and methods have been used to describe the intended functions, including ladder and Boolean diagrams, state diagrams, matrix diagrams, time-sequence diagrams, Gantt charts, and sequential function charts, usually supplemented by a written description of the control objectives for each control object. Time-sequence diagrams are used here to illustrate detailed sequences of events. Time-Sequence Diagrams The time-sequence diagram shows the sequential changes in control actions and their time relationships. The sequence of

1648

Control and Optimization of Unit Operations

events can be followed along dotted lines for vertical time coincidence and along the solid lines in a horizontal direction for sequence control. The diamond symbol is used to indicate a trigger event, and a vertical dotted line indicates the time coincidence trigger events. When two or more diamonds occur in the same relative time line, an “AND” logic condition is assumed. The format of the time-sequence diagram proceeds from left to right in discrete time steps, with relative time being the horizontal coordinate. Figure 8.8g illustrates a time-sequence diagram for a flow loop, such as the one shown in Figure 8.8f. First, the valve XV-1 is opened and the controller FIC-101 is placed in automatic (t0). When XV-1 is open and FIC-101 is in “auto,” the continuous task of flow integration is started (t1). When the desired total is reached (t2), XV-1 is closed. When XV-1 is closed (t3), the integration of flow continues to check for leakage. If, at the end of a preset time interval, the total flow is still zero, FIC-101 is switched back to manual (t4). Figure 8.8h describes a control system in both ladder and time-sequence terminology. Here, when the start button is closed and XV-1 is open (its contact is closed), motor coil M is energized. When the coil is energized, its auxiliary “Mcontact” closes. Once the M-contact is closed, it keeps the coil energized even if the start button contact reopens. If at any time the XV-1 valve would fail closed, its limit switch contact will open to de-energize the M coil. Once the coil is de-energized, the auxiliary M-contact reopens. t0

XV−1

XV−1 M Open

M-contact Start button

Close Open

XV−1

Open

Fail

M-coil

Energize

M-contact

De-energize

Close

In batch process units, the batch sequence is subdivided into process states. Each state is given a unique name, such as CHARGE, REACT, HEAT, COOL, HOLD, DISCHARGE, WASH, and EMPTY. Within each state, discrete t3

t4

t5

Discrete and regulatory control tasks XV−1 FIC101

Open

Close Man

Auto

Calculation End condition

Continuous task

Continuous task

Time sequence t0 XV−1 is opened and FIC101 is placed in auto t1 If XV−1 is open and FIC101 is in auto then start end condition continuous task t2 XV−1 closes after end condition met t3 If XV−1 closed then start end condition t4 FIC–101 is put in manual after end condition met t5 Time sequence ends

Continuous task start Trigger event

FIG. 8.8g The time-sequence diagram for the flow control loop in Figure 8.8f. The sequence proceeds in discrete steps from left to right.

© 2006 by Béla Lipták

Open

FIG. 8.8h The time-sequence diagram of the flow control loop in Figure 8.8f is described in ladder diagram format at the top and by timesequence diagram in the lower part of this figure.

Time steps t2

t1

M

Start button

8.8 Chemical Reactors: Batch Sequencing

control functions, continuous-regulatory control functions, and safety and permissive interlocks are performed.

ENGINEERING A BATCH CONTROL STRATEGY When microprocessor-based controls are used, the control system design follows the step-by-step approach described in Figure 8.8i to specify the functional requirements. The iterative nature indicated by the decision at the bottom is due to refinement of P&IDs, process definition, and control logic interactions over the duration of the project. Of the eight steps shown, steps 1-2 provide an overall foundation for the work to follow. Steps 3-5 specify equipment-centric requirements, steps 6-7 define the process sequencing and supervision, and steps 8-9 identify exception handling and reporting requirements. Designing a suitable degree of control modularity at the equipment module level is the most important and challenging aspect of establishing overall design modularity and maximizing reuse of prior engineering efforts. Typical sequence control tasks and events to consider are shown in Table 8.8j. Preparatory Steps In the first step of Figure 8.8i (step 1), the process control engineer should review the P&ID flow sheets to make sure that the measurement and control devices and control strategies are accurately represented and that they are capable of meeting the requirements of the applicable general/site recipes or process description, standard automation practices, and expected cycle times. Ancillary automation requirements that are not covered by general/site recipes, such as clean in place (CIP), should also be reviewed. Any subsequently identified P&ID deficiencies must be noted as soon as possible to avoid costly rework later in the project. In the next step (step 2), the engineer must identify and tabulate the process cells, units, trains, and common resources. As defined by ISA S88/IEC 61512 standards, process cells identify the physical limits for any single recipe/batch. Units and their associated controls may be allocated to only one batch at a time, so vessels that sequentially hold the same batch within a process cell line must be identified as separate units if they are to simultaneously process successive batches. Equipment and controls that service more than one unit (e.g., a shared transfer pump) must be separately identified as common resources. Similar assignments must be made for continuous parts of the process, as units also define the common basis for alarm groupings and database structure. Equipment-Related Requirements In step 3, the process control engineer should identify on the P&IDs the discrete and analog measurement and control

© 2006 by Béla Lipták

1649

devices and tag them in terms of input and output signals. (If the instrument index is available at this time, the I/O list items may easily be extracted from it. Once the I/O list is established, it should be checked against the P&ID for recent changes. Note that assigning I/O to units and common resources may not be necessary, but will be helpful for sorting purposes during detailed design.) In step 4, the engineer must define all basic control requirements (control modules and equipment modules, except phase logic) associated with each unit and common resource identified in step 2. In general, control modules are at least structurally well-defined by the P&ID, but equipment modules entail coordinated control (usually command- or event-driven) of multiple devices that is more subjectively defined based on P&ID symbols and notes, coupled with the engineer’s analysis of operational requirements. A control specification comprising a written description (or cause-and-effect matrix for simple interlocks) or control diagrams (based on ISA symbology, Boolean or ladder logic, sequential function chart, or time-sequence notation) is required to define each unique module class. If such classes have been well designed on previous projects, most new requirements will be drawn from a previously developed specification library, supplemented with a project-specific tabulation (sorted by unit or common resource) of tags, connections, and parameters that are unique to each required instance. In order to maximize future reuse, specifications for each class of new modules should be as general as practical, consolidating similar types by using internal parameters to select features. Operating modes, human and supervisory control requirements, indicators (e.g., states, fault, module performance statistics), and relevant process calculations (e.g., material and heat balances and recipe corrections based on quality control data) should also be defined. In step 5, the equipment procedural control is defined for each equipment module and unit, comprising phases and higher-level elements as appropriate. Supervisory control and parameter interfaces for each phase and suitable transition conditions and actions for each phase state must be identified. Phase logic is the workhorse of procedural control, administering the real-time control functions primarily by sequentially manipulating and monitoring states of the various equipment modules and control modules via the previously defined basic controls. Equipment procedural elements, like basic control entities, can be reused across multiple products and projects by creating libraries of flexible and modular object classes for previously specified functionalities. To be usable, however, such classes must be based on indirect addressing schemes that reference tag names generically within the unit or equipment module. Procedural control object classes, like those for basic control, can thus be documented in detail just for a single instance, with an appended tabulation of suitable linkages and parameter values for each instance.

1650

Control and Optimization of Unit Operations

Start

Step 1

General/site recipes and P&ID review

Reference general/site recipes (if available) and P&ID

2

Identify units and common resources

Document major components of S88 equipment model

3

Identify measurement and control devices

4

Define basic control functions

Reference CM and EM spec libraries; tabulate instances; for new classes, define parameters, states, commands, interlocks & control features

5

Define equipment procedural control functions

Reference equipment phase library; tabulate instances; for new classes, document sequence requirements

6

Identify interface and coordination control requirements

7

Define recipe procedural controls

8

Define exception conditions and recovery logic

9

Define performance indicators and management reports

No

Engineering complete?

Define process I/O

Identify HMI, batch management, and scheduling needs; define security and equipment arbitration policies

Review product and ancillary sequence needs; reference recipe procedure library; tabulate instances and parameter differences; fully define any new classes

Analyze strategy; prepare emergency procedures and alarm monitoring

Define data collection and reports

Control refinements? P&ID updates? Process changes?

Yes

End

CM—Control module EM—Equipment module

FIG. 8.8i Step-by-step approach to specifying a microprocessor-based batch control system.

© 2006 by Béla Lipták

8.8 Chemical Reactors: Batch Sequencing

TABLE 8.8j Typical Sequence Control Tasks and Events 1. Sequence start prerequisites and permissives (e.g., unit available, previous batch complete, interlocks satisfied) 2. Discrete element and devices (e.g., outlet valve, inlet value, manifold, agitator) 3. Regulatory control loop setpoint changes, mode changes, output changes, profiles, etc. (A/M-PID algorithm, SP profile, output) 4. End conditions 5. Timers 6. Calculations (e.g., heat or mass balance) 7. Operator action request/response (e.g., clean, take laboratory analysis, check batch end) 8. Process failure conditions (e.g., level too high, pressure too low)

1651

device and equipment malfunctions, unexpected process delays and events, and abnormal process and quality measurements must be evaluated relative to the need for alarms or messages to alert the operator, for automatically holding or aborting the batch, and for any special response or recovery procedures. Various adjustments of the previously designed strategies may be required. In step 9, all the historical data trending and reporting necessary for adequate production and performance management are designed and formatted. Batch processes have unique data storage and retrieval requirements, as information must be identified with individual batches as they move through the plant, as well as their ultimate material origins and disposition. Adjustments of the previously designed strategies may be required to cover unanticipated data requirements.

9. Failure actions (branch to alternative sequence)

Implementation Process Sequencing and Supervision In step 6, the engineer must identify the interface (human and data) and coordination control requirements, including how recipe management, production planning and scheduling, and production information management will work. If a commercial batch server will be used to implement the upperlevel procedural control requirements, it will also perform most coordination control functions; otherwise, custom programming must be specified for this purpose (not usually cost-effective unless the required capability is very limited). Guidelines must be developed for equipment arbitration, batch historization (including product genealogy tracking and electronic signatures, as needed), and application security. A custom operator interface may be required (along with extra phase logic for setting display variables such as status, step descriptors, prompts, fault messages, and parameters) to monitor and control phase execution details. Custom interlock displays and faceplates (and module-based display variables) may be required to adequately monitor and control nonstandard basic control functions. In step 7, the master recipe is defined for each product, based on the process information identified in step 1, and for each ancillary equipment operation (e.g., CIP) that will be routinely scheduled. The procedure, unit procedure, and operation levels of the control strategy must be defined, as well as the equipment (unit and common resource) and formula requirements. Depending upon the equipment controls specified in step 5, the product recipes may be either unitspecific or not. Definition of master recipes can also utilize component libraries for rapid construction, particularly in circumstances where tabulation of formula differences is sufficient to accommodate most products. Exception Handling and Reporting In step 8, an overall failure analysis must be done, with the plant considered in its entirety. The consequences of potential

© 2006 by Béla Lipták

Various microprocessor- and computer-based systems are specifically designed to perform the wide variety of control tasks involved in batch processes. In the area of continuous (regulatory) control, a fill-inthe-blank-type language supported by CRT-based operator consoles has become an accepted standard. The fill-in-theblank language is used to configure the control system database and to create many of the necessary control algorithms. The discrete functions (direct on/off control, interlock control, sequence control) require programming. Many programming languages available for generating control software are of the “high-level” type, meaning that the instructions are expressed in English. Various structures and procedures contained in the programming languages offered for control applications include: • • •

• • • • •

Processing discrete inputs and outputs Timing and counting routines Special routines applied to start up electric motors sequentially, in order to limit the inrush current imposed on the power supply Integration of analog variables Message triggering Transfer routines for synchronization of dual processors (whenever 100% redundancy is required). Dynamic links of discrete variables to P&ID-type graphic displays for monitoring batch processes Interface routines for linking recipe data files with the main control program

Process management functions are programmed using high-level languages that are well suited for data manipulations. The application software development for a certain defined and specified project is considered finished when all the programs are debugged and are running within the constraints of the operating system and the hardware configuration. To avoid unexpected control interactions during start-up,

1652

Control and Optimization of Unit Operations

TABLE 8.8k Performance Capabilities of Batch Charging Instruments Detector

Type

Min. Error

Rangeability

Load cell weighing

Mass

±0.1% FS

NL

Turbine-type flowmeters

Volumetric

±0.25% AF

10:1

Positive displacement flowmeters

Volumetric

±0.25% AF

10:1

Metering pumps

Volumetric

±0.5% FS

20:1

Mass flow meters

Mass

±0.2% AF

20:1

Vortex shedding flow meters

Volumetric

±0.75% AF

10:1

Level

Volumetric

±0.25% in.

NL

AF—Actual flow. FS—Full scale. NL—No limitation.

a full simulation of the sequential control functions (run using the as-designed operator interface) is an essential debugging aid for complex batch processes. Batch Charging Reactants and catalysts can be charged into the reactors, either by weight or by volume, using flow meters, pumps, feeders, and weighing systems, as shown in Table 8.8k. The main considerations in making the selection are accuracy and reliability of the data obtained. Because material balances are always based on the weight (not the volume) of the reactants, all things being equal, the mass- or weight-type sensors would be preferable; using such sensors would eliminate the need for density or temperature compensation. If they cannot be considered for some reason, the solid-state volumetric sensors (vortex) would be preferred over the ones with moving parts (turbines, pumps, positive displacement meters), because sensors with moving parts tend to be high-maintenance devices, with frequent need for recalibration. Therefore, in a new installation with no restrictions on hardware selection, it might be advisable to place the reactor on load cells and charge all ingredients that weigh more than 10% of the total batch by weight. Reactants and additives that are needed in lesser quantities can be added under the control of Coriolis mass flowmeter-based measurements with the load cells providing only backup. Catalysts or ingredients needed in extremely small quantities, representing less than 1% of the total batch, can be added by metering pumps or by specialized feeders. UNIT OPERATIONS CONTROLLERS In the last decade, manufacturers of shared, distributed controllers (which started out as microprocessor-based multiple PID controllers) have added more and more logic capability

© 2006 by Béla Lipták

to their products. At the same time, manufacturers of PLCs (which started out as microprocessor-based programmable logic controllers) added more and more PID capability to their products. The result today is the merging of these products into devices that are capable of handling both analog and logic sequencing control tasks. Although the control industry does not yet speak in these terms, a new era of process control has arrived: the era of the “unit operations controller.” The unit controller is capable of controlling a unit operation in the plant. That unit operation can be a reactor, a distillation tower, a compressor, or any other subsystem. This represents a major step forward because it makes it necessary to stop thinking in terms of controlling single loops—such as pressures, flows, or temperatures—and to start thinking in multivariable terms, controlling the overall unit operation. This is a prudent and logical direction to take because plants do not produce and sell pressures, flows, or temperatures: they sell a product. Therefore, the truly relevant control variable is maximum productivity. To move from the age of single to multivariable mentality, the unit controller is required. The microprocessor is needed to memorize the complex nature of the unit process in order for control to take place on this new and higher level. The chemical reactor is a natural candidate for control by unit controller. The number and types of input and output signals required and the types of control actions to be performed on them are within the capabilities of many microprocessor-based multiloop products on today’s market. Therefore, the user can implement right now all that is discussed in this section and in the previous section. Today’s process control industry is somewhat softwarelimited. A large variety of well-designed “empty boxes” are available, which are provided with a library of low-level software subroutines for PID, logic, and other functions. Unfortunately, with few exceptions, it is up to the user to educate this box to become a reactor controller or some other unit operation controller. Depending on the manufacturer, these empty boxes are more or less “friendly” to the user. High-level software packages will be developed in the future to give “personality” to the previously empty boxes. One plug-in cassette or floppy disk might educate an empty box to become a distillation tower controller, and other disks could give it the personality of a dryer, evaporator, reactor, or other controller. It goes without saying that these high-level programs would also require adjustment to fit the universal unit controller to the particular process, but this “custom fit” would occur at a much higher level. All user inputs could be provided by process engineers. These inputs could deal with recipes, temperature profiles, equipment or piping configuration, and so on. While such high-level, all-purpose packages are not yet available, flexible and reconfigurable reactor control packages (available with or without the reactor equipment) have been developed. One such reactor unit controller is described in the following paragraphs.

8.8 Chemical Reactors: Batch Sequencing

1. Jacket system, with pump, on/off and control valves, and steam ejector 2. Distillation system, consisting of reflux cooler, condenser, water separator, and receiving tanks 3. Charging system, with weighing equipment and other instruments 4. Feeding system, consisting of a feeding tank, a dosing pump, and control devices

© 2006 by Béla Lipták

Distillation

SP FIC OP PV

SP PV FIC

Enable

OP

Reactant addition

Remote SP TIC OP Setpoint Gain PV SP OP FQ PV FIC Enable

Feedforward + TIC OP TY

SP PV TIC

PV

Steam heating

Steam flow into jacket Jacket temperature

OP

Reactor temperature

Condensate flowrate

Enable

Nonisothermal temperature control

Reactant flowrate Cooling water

Remote Setpoint

OP

Reactant

Setpoint

Reactor control systems can be distinguished based on many criteria. One of these is flexibility. If a reactor control system is specifically designed for a particular product to be made in a particular unit, the control system has no flexibility at all. Flexibility can be built into the controls, so that they might be used even if operating condition, raw material, or product specifications change (“static flexibility”). A higher level of flexibility is one where the control system can be used to make different products and to maintain different operating conditions (“dynamic flexibility”). If the equipment configuration and the associated piping connections can also be changed, this is called structural flexibility in a control system. In plants where products change often, such as in pharmaceutical plants, flexibility in the reactor control is an important consideration, because it allows for the implementation of new production strategies without loss of time or need for additional engineering design. Figure 8.8l shows a reactor control system that is provided with some structural flexibility. The control system is basically a unit controller, which is initially “empty” in the sense that it has a certain I/O, display, and memory capability. That capability is not utilized by the supplier to configure a single reactor control system (nonflexible system) but rather is used to configure a variety of control systems, which can be selected by the operator as a function of the desired equipment and operations. Figure 8.8l illustrates how a flexible reactor control system might be reconfigured into different control structures. In the “nonflexible” (dedicated) reactor control systems, the operator would only adjust the controller set points, tuning parameters, and the quantities of ingredients in the recipes. With a flexible reactor unit controller, the same reactor might be used for reaction, stripping or distillation, or crystallization, and for each operation a different control configuration and different tuning constants are needed. Because of the many operations taking place within the same reactor, the sensors must have wide rangeability and the controllers must be adapted for variable gain operation, because the time constants (dynamics) of the process changes with time. The equipment accompanying this reactor unit controller 3 is shown in Figure 8.8m. The most important piece of equipment is the reactor itself. In addition, the following equipment modules exist and will be described in the following paragraphs:

Recipe parameters

Enable signal

REACTOR UNIT CONTROLLER

1653

Flexible reactor technology unit

FIG. 8.8l Illustration of the flexibility that a unit controller can provide.

5. Auxiliary systems, with equipment to perform operations such as clean in place, material transfer, inertization, and so on Each equipment module is provided with the measurements necessary for operations and control. Jacket Equipment Module In addition to the jacket itself, the jacket equipment module consists of a pump, a steam ejector, two control valves (TCV-1 and -2), and ten on/off valves (V1 to V10). The various options on the operation of the jacket controls are described in Section 8.9. The jacket system can be in several states, as shown by the state diagram in Figure 8.8n.

1654

Vinert1 V25 Vinert2

Vcool2

Condenser #2

Weighed feed tank

Water

V16

Nitrogen Vexh4

V17

Condenser #1

Vfeed2

V13

Water separation

Vcool1 V feed1 Reactant in Cvsteam Steam in

P TCV1

V14

Cvfeed

Vrefl

M

V11 Hot or cold liquid

V12

Steam

V10

Vsel

V18

V15

Vrev

Vexh3 V7

Exhaust

Cvfluid TCV2

V watin

V19

V metin

Outlet

Vcon

Vac

V21

Vvac1

Vac

Condensate outlet

V1

Vdrain V2

Vmetout

Cooling medium outlet Water outlet

Vvac2 V24

V23 T

Vexh2 Exhaust V22

Exhaust

Vloop

V9

© 2006 by Béla Lipták

Vrec2

Vexh1

V8 V5 Vdrain1V6

FIG. 8.8m 4 Prepackaged and automated reactor control system.

V20

Vdrain2

Cooling medium inlet V4

Vrec1

Receiving tank 2.

V3

Receiving tank 1.

Cooling water inlet

Control and Optimization of Unit Operations

V26

8.8 Chemical Reactors: Batch Sequencing

1655

Steam heating and jacket empty and no cooling media before.

No

ms alar

Steam

S0 initial state

S5 water empty

ty t emp Jacke

pty Jacket not em Exit

S1 error

If

St olin eam a g m fter e di No errors a Co

S2 steam heating

it

S9 water filling

Emergency

S10 water empty

Ex

ull

mpty Jacket e

tf ke c a J

N LL alarm

If S6 cool. media empty

Cooling w

Jacket full ith cooling

S15 S8 cool. media empty

S4 water heatingcooling

S3 water filling

o

S14

al a r Ex ms it

If

HH alarm

S7 cooling

media

Cooling with cooling media and jacket empty and no steam heating before.

Water heating/cooling or steam heating after cooling media or cooling with cooling media after steam.

FIG. 8.8n 4 State diagram of a reactor jacket system.

In state S 0 all the valves are closed except the vent valve V 7, which is open. If any of the safety interlocks are activated, hardware errors or device malfunctions are detected, and the system is returned to state S1, which is the “error state.” In this state the control is returned to the operator. If the controlled process variables are not on set point and high or low alarms are registered, these bring the system into states S14 or S15, where those corrective responses are initiated that have been preprogrammed for such conditions. When either the higher level of software or the operator is ready to initiate the steam heating state (S2), valves V10 and V6 are opened and TCV-1 is assigned to throttle the steam. In order to make sure that the steam condensate will not be contaminated, if prior to the steam heating state the jacket was filled with a cooling media (such as methanol or brine), the jackets will be first flushed with water (V3, V5, TCV-2, V1, and pump on), and then drained (V7, V8, V9, V1, and pump on). Because of the multiple heat-transfer media used, automatic controls are provided not only to protect against crosscontamination but also to protect the glass lining of the reactor against damage by excessive temperature differences.

© 2006 by Béla Lipták

Therefore, if the particular batch sequence calls for consecutive stages that could thermally shock the glass lining (direct steam heating followed by cooling, or the other way around), the jacket interlocks automatically guarantee that intermediate temperature operations will be inserted, to make 4 the transition gradual and thereby protect the glass. Therefore, when direct steam heat is followed by cooling, states S9 and S10 are interposed to bring the jacket temperature to an intermediate value to avoid shocking the glass. Prior to starting to heat or cool with water, the jacket is filled in state S3 (V3, V5, V7 opened, and pump on), and only when the jacket is full does the heating (V10, TCV-1 open, while V7 closes) or cooling (TCV-2 and V1 open) state (S4) start. When this is over, the water is drained from the jacket (V1, V8, V9, V19 open, pump on), and when the jacket is empty, it might return to the initial state (S0). When a cooling media other than water is used (methanol or brine), the same sequence of filling (S6), cooling (S7), and draining (S8) states is initiated as was the case with the waterbased operation. With these various control states, it becomes possible to match the desired batch temperature profile for a particular reaction with a profile of jacket temperatures that 4 is reasonably close to it.

1656

Control and Optimization of Unit Operations

Recipe Charging Module The reactants, catalysts, solvents, modifiers, and other chemicals are charged into the reactor either before or during the reaction. The operation that takes place prior to starting the reaction is called charging, while the continuous addition during the reaction is often called feeding. The chemicals can be added on the basis of their weight or their volume, and the devices used in charging them include mass or volumetric 5 flowmeters, metering pumps, feeders, or weighing systems. When weighing is applied, it can be done by weighing the reactor itself or by providing a separate weighed charge tank, as is the case in Figure 8.8m. The accuracy, reliability, and rangeability of the charging devices are the main criteria for selection, as was discussed in connection with Table 8.8k. The ingredients that are fed while the reaction is in progress can be charged all at once (dumped), or they can be charged as a function of time, temperature, pressure, pH, or other variables. They are usually charged from a separate feeding tank under level or flow control or added by dosing

pumps. In Figure 8.8l the on/off valves V11, V12, and V13 serve to control feeding. For an example of an installation in which the reactant is added under temperature control, refer to Figure 8.8o.

Stripping or Distillation Module The addition of the distillation equipment module to the reactor provides the capability to perform the type of batch distillation that is illustrated in Figure 8.8p. The resulting quality of separation is naturally lower than if a distillation column is used. During this stripping phase the reactor is either in the hot water or in the direct steam heating mode, which guarantees a state of slow boiling in the reactor. During the stripping phase, valves V15, V16, and V17 are open. This state of slow boiling can be terminated on the basis of time or on the basis of the rise in vapor pressure in the reactor. If desired, water can be separated before the reflux is returned to the reactor.

HIC High limit 4

TY 4 Slave with preload FRC 1