Exception Handling for Optimal Batch Production

Transcription

1 Presented at the World Batch Forum European Conference Mechelen, Belgium October 14-16, S. Southgate Drive Chandler, Arizona Fax Exception Handling for Optimal Batch Production Presented at the World Batch Forum 2002 European Conference Paul J. Marriott BEng, CEng, MIEE. Senior Project Engineer Aston Dane Plc Park Mill Way, Clayton West Huddersfield, West Yorkshire, UK, HD8 9XJ Tel: Fax: KEY WORDS Exception Handling, Batch Control System, Batch Process Performance, Batch Quality, Physical and Procedural Models, Optimum Batch Production. ABSTRACT This paper supports the application of an Intelligent exception handling strategy, which helps to provide maximum business benefit and optimum batch production. Incorrect or incomplete design of the exception handling philosophy for a batch control system can have a detrimental effect to the batch process performance, including both the batch quality and processing time. Even though most people would agree with this, exception handling is often an area of batch control system design not always given the level of attention it duly requires, even though it can have such a significant impact. This paper identifies the various causes of these exceptions and discusses the corresponding issues to be reviewed during the projects design stage, including the impact to the design of the physical and procedural models. We must ensure that not only are all conditions catered for, but that each is managed intelligently and safely. Intelligently means that we ensure the correct level of action is taken and to the affected area only, that the correct level of information is given to the operations staff, and that all associated events are logged correctly for future reviews. Copyright 2002 World Batch Forum. All rights reserved. Page 1

2 INTRODUCTION Exception Handling involves all areas of the batch control system design, from the plant control modules right through to the operator interface and batch management system. Each of these areas is discussed with regard to working towards the goal of Optimal Batch Production, and proposals are put forward for an intelligent exception handling strategy. These proposals are examples of typical approaches used on recent projects. Where the design of these areas is not given the due consideration they require, a reduction in batch process performance can result, detrimentally affecting the batch scheduling, batch quality, or both. When defining the functionality of any control system, all possibilities should be considered, i.e. define the functionality when things go right, and more importantly when things go wrong. This includes having an awareness of the implications to the safety of personnel, process equipment, and the environment, as well as to the performance of the batch process itself. It s usually much easier to define the plant functionality for normal operation, but much more difficult to define the actions when things go wrong. Finally, the reasons for employing a continued engineering effort throughout the life cycle of the batch processing facility are discussed, including having a policy of continuous review and improvement. To support this discussion a typical automated batch control system has been defined to include the following main components and their associated function: - Control and Monitoring of the plant Control Modules, Phase Logic and Unit Supervision is carried out through a PLC. Operator control and monitoring of the plant equipment and batches is via a SCADA system. Recipe Management, Batch Execution, Batch Monitoring and Arbitration is carried out via a Batch Management system. For this example the batch process plant is heavily automated with few manual process operations. WHAT DO WE MEAN Exception Handling? Firstly, what is meant by the term Exception Handling?. S88.01 States Exception as meaning An event which occurs outside the normal or desired behaviour of batch control. [Ref: 1]. Examples of such events are:- Alarms caused by equipment failures, process alarms caused by inadequate process control, process interlocks preventing normal batch operation, unexpected operator intervention to hold or stop the batch, unavailability of a process unit, a common resource or ingredient material due to arbitration issues. For the purpose of this paper the term normal or desired behaviour, shall be defined as meaning the continued and unobstructed operation of the batch process, controlled in such a manner to produce a final product of the expected quality. S88.01 States that Exception Handling is an essential function of batch manufacturing. Exception handling is an integral part of all control and typically constitutes a very large portion of the control definition. Copyright 2002 World Batch Forum. All rights reserved. Page 2

3 WHAT IS OPTIMAL BATCH PRODUCTION? The author has assumed that for optimal batch production our aim is to achieve the following :- 1. Complete the batch in the scheduled time. 2. Produce a batch where the quality of the product is greater than the minimum acceptable. There are many events, which can affect achievement of the optimal batch, some of which are outside the control of the batch control system e.g. poor quality of ingredient material. This paper shall only consider those areas under the direct influence of the control system itself, which includes the control of process plant equipment and the process operations. To achieve these goals we need to strive towards the following:- 1. To have zero unforeseen stoppages. 2. To have adequate process control to achieve the setpoints and tolerances that the product requires. In reality these two goals can be very difficult to achieve and are heavily dependant on the required tolerances of the product, the condition of the process plant and the condition and design of the control system. Typical problems preventing achievement of optimal batch production: - Improper Operator Intervention. - Unforeseen process conditions that cause the process operator to take drastic action, or present him with conditions he cannot cope with. Lack of relevant control system information, causing him to Hold, Stop or Abort the batch. Making an incorrect decision due to confusing or conflicting information or even due to lack of training. Equipment Failures Possibly due to inadequate preventative maintenance. Poor Process Control Inadequate process control due to poor functional definition or control loop accuracy, resulting in the generation of unnecessary process alarms or resulting in poor quality product. Resource Allocation / Equipment Arbitration Through bad design or external conditions, the batch is Held, waiting for equipment / common resources / materials, to become available. Process Alarm Levels Incorrect alarm setpoints specified at the design stage, or alarm limits being unnecessarily set too tight for the product. Both cases resulting in avoidable disruption to production brought about by continuous generation of alarms. Incorrect Process Interlock Strategy Causing unnecessary stoppage time waiting for process interlock conditions to be removed. Inefficient co-ordination (Phase to Phase, Phase to Common Resource, Unit to Unit) Complicated, unnecessary or incomplete co-ordination preventing smooth and correct progression of the batch through the plant, possibly caused by incorrect design of the physical model. Copyright 2002 World Batch Forum. All rights reserved. Page 3

4 CONTROL SYSTEM DESIGN PHILOSOPHY The main areas of the control system design to be discussed are: - Alarm Handling Strategy, Equipment Control, Identification and Control of Common Resources, Physical Model Design, Procedural Model Design, and Operator Interface Design. Although it s impossible to prevent all possible causes of unscheduled plant stoppages from ever occurring, we can improve the situation if certain key issues are defined and understood by all members of the project team before we carry out the control system design. It s much easier and cheaper to modify and improve the exception handling capability during the early stages of system design, than it is during the latter stages. Note: Some of the design problems can be compounded when a contract manufacturing or multipurpose processing facility is being designed, where product definition cannot be determined in advance. The following sections review the relevant issues for each of the defined design areas. For each of these areas one design solution is proposed, however the author acknowledges that there are many possible solutions available. ALARM HANDLING STRATEGY We must first decide on an alarm handling strategy. Define the Alarm Propagation Level, i.e. are the alarms to be propagated to the Unit Procedure Level, or to the Procedure Level?. In the typical automated batch control system stated previously, propagation to the Unit procedure level is required, and as such additional co-ordination at the Phase to Phase, Phase to Equipment Module or Unit to Unit Level is necessary. Define the requirements for :- Alarms / Operator Warnings / Operator Messages. Alarms are defined as those exception events, which cause an alarm message to be displayed on the SCADA system requiring the attention of the operator, and resulting in the control system taking automatic action to move the control system to a known safe state. Typically this would result in both the Phase and possibly the associated unit procedure being moved to the held state. Operator Warnings are defined as those exception events, which cause a message to be displayed on the SCADA system, requiring the attention of the operator, but do not warrant any automatic action to be taken. Typically most Phases have the facility to handle two sets of alarm setpoints. If the process variable exceeded the inner setpoints, i.e. those closest to the process setpoint, then a warning is generated, if the process variable exceeded the outer setpoints then an alarm is generated. Operator Messages are defined as those normal events which occur during recipe operation, e.g. Take a Sample From V1234. They result in an Operator message being displayed on the Batch Management system, requiring the attention of the operator. As these are expected events they shall not be discussed further. Copyright 2002 World Batch Forum. All rights reserved. Page 4

5 Define the Alarm Group Alarms can be split into two main groups, which cover most situations that can occur during plant operation, however there will always be certain alarms needing to be treated as special cases. The two main groups can be classed as:- Alarms Which Are A Function of Time, and Alarms Which Are Not A Function of Time. To be more specific, the first could be classed as Phase or Process alarms, the second being classed as Equipment alarms. Phase or Process Alarms are those, generated within the Phase logic during the period when they are active, hence the statement that they are a function of time. These alarm limits are specified as part of the batch recipe and as such are not hard coded, they can be varied for each recipe. Phase or Process Alarms are Product Dependant. Examples of Phase Alarms:- Batch Temperature exceeds high limit of 75 Deg. C. Transfer Watchdog Timeout Exceeded generated when the transfer of product between two vessels has exceeded the given time limit. It is important to note that when specifying these alarm limits care must be taken to ensure they are realistic and suitable for both the product being manufactured and the capability of the control system itself. They should be specified to ensure that they prevent damage to the batch but are not so tight they continually cause alarms to be generated, thus halting production and resulting in increased batch time. Equipment alarms are those, generated directly from within the control module, and can occur at any time whether the device is in use or not. These alarm conditions are fixed and hard coded, and cannot be changed as part of the recipe. Equipment Alarms are Product Independent. Examples of Equipment Alarms:- Valve Failure generated by a command discrepancy where the state of the feedback position switches does not match the state of the valve command signal. High High (HH) Level the contents within the vessel have reached the HH Level probe. EQUIPMENT CONTROL An important area to define early in the design stage of the project is the method for controlling plant devices, namely valves, motors, PID loops etc. Define Automatic / Manual Operation of Control Modules. Typically there should be no need, during normal plant production, for the operator to take manual control of any plant device other than where the recipe requires. There are always a few exceptions to this and they should be treated as special cases, e.g. for maintenance purposes. As a result of this philosophy, the design decision is as follows: - Manual control of any device on a unit will be inhibited while any Phase on that unit is operative, manual control will only be enabled if all Phases on the unit are either Idle or Held. If any device is not in automatic mode when any Phase on the unit becomes active, a Phase alarm will be generated which will result in the unit procedure being held until the condition is rectified. Copyright 2002 World Batch Forum. All rights reserved. Page 5

6 This design decision is only one of many possibilities, there are many different philosophies in use today. The main objective in most cases is to inhibit manual control of a plant device, which is presently being controlled by a Phase. IDENTIFY COMMON RESOURCES & DEFINE THE ASSOCIATED CONTROL STRATEGY The majority of process plants these days require the use of some common resources which have to be shared between process cells, e.g. the use of common site bulk storage vessels or common services. Use of these shared resources can, in certain cases, cause problems which affect the progression of each batch. For this reason careful design and planning is required around the usage of all shared equipment. Although this is strictly a plant design issue and not a control system issue, the process design team needs to be aware of the implications of their decision. Therefore the first question to ask is, Does the equipment really need to be shared?, if so what is the usage strategy, i.e. exclusive use, or common use. If the equipment is to be shared on an exclusive use basis, what arbitration rule is to be used, first come first serve, or is it determined by priority?. If priority is to be used, what are the priority levels and how are they assigned?. These rules can become quite complex. Wherever possible the project design team should work towards limiting the effects of shared equipment, by either removing it altogether or by reducing the amount of time the batch has to wait for shared resources becoming available Typical shared resource problem is the Common Site Bulk Storage Vessels:- Where raw ingredients have to be batched into vessels via batching meters from common site bulk storage vessels, the number of possible concurrent users is determined by the number of batching meters installed. In this example a decision could be made to install additional equipment to alleviate the possibility of bottle necks occurring. The costs for these options have to be weighed against the possible benefits and are dependant on many variables e.g. The likelihood of a conflict occurring, the result of such a conflict, and the cost of installing additional equipment. In the case above the installation of additional pumps, valves and batching meters would be required, to either alleviate or remove the problem entirely. Shared resources can also pose a problem with regard to handling equipment faults. When a fault occurs within a shared equipment module, the fault must be propagated to the process unit that has acquired the shared resource at that point in time, this requires the use of co-ordination logic. PHYSICAL MODEL DESIGN Design of the physical model is extremely important in ensuring the process plant operates smoothly and efficiently. See Ref. 1 for the definitions of the entities contained within the physical model. Process Unit The boundaries around process units must be clear and well defined. One of the main objectives during the definition of the process unit boundaries, is to minimise the interaction between process units and / or common resource equipment modules. Other areas to be considered are:- Copyright 2002 World Batch Forum. All rights reserved. Page 6

7 Process Unit Alarms and Unit Devices in Auto / Manual. Once the process unit boundaries have been defined, a list of the control modules contained within each unit can be compiled. The Alarm States of each control module within each unit are combined to produce a single Unit Alarm. This Unit Alarm flag is used by each Phase which belongs to that unit, and if a Unit Alarm is present while any Phase is active, then both the Phase and then the unit procedure would be moved to the Held state. In certain cases, not all control modules are included within the Unit Alarm and some that are may have additional conditional logic. It may not always be necessary to hold the process unit if certain control modules fail, e.g. A device failing on the vessel jacket services skid, may not directly cause a problem unless it results in the temperature of the vessel contents exceeding the given limits. The Operational ( Auto / Man ) state of each control module are also combined on a unit basis to produce a single All Unit Devices in Automatic interlock. Propagation of Transfer Interlocks and Unit Alarms There is usually a requirement for co-ordination between all Phases that need to interact between process units, or between process units and equipment modules, e.g. for the setting up and execution of transfer operations. If the design decision is to propagate alarms to the unit level then this coordination is also the means by which to propagate the alarm state between the source and destination units / equipment modules. Common Resource Equipment Modules Common resource equipment modules are defined as being self-contained entities, and as such are treated in the same manner as process units with regard to Alarms, Devices in Auto / Manual and Transfer Interlocks. Figure 1 Shows an example of alarm propagation for two units from Control Module, through Unit Supervision, Phase Logic to the Batch Manager. It also shows the co-ordination control between the two units. Copyright 2002 World Batch Forum. All rights reserved. Page 7

8 CM (A1-An) "In Manual" "Unit (A) Device in Manual" Phase (A1) "In Alarm" Control Modules (A1 - An) CM (A1-An) "In Alarm" CM (A1-An) "Commands" Unit ( A ) Supervision "Unit (A) Device in Alarm" CM (A1-An) "Status" Unit (A) Phase (A1-Ax) Logic "HOLD" Phase (A1) CM (B1-Bn) "In Manual" Phase to Phase / Equipment Module Co-ordination "Unit (B) Device in Manual" Phase (B1) "In Alarm" Phase Logic Interface Batch Manager Control Modules (B1 - Bn) CM (B1-Bn) "In Alarm" CM (B1-Bn) "Commands" Unit ( B ) Supervision "Unit (B) Device in Alarm" CM (B1-Bn) "Status" Unit (B) Phase (B1-Bx) Logic "HOLD" Phase (B1) Figure 1 Fault Propagation & Phase Co-Ordination Phase to Phase / Equipment Module Co-ordination PROCEDURAL MODEL DESIGN Although not necessarily obvious when discussing exception handling, design of the Procedural Model, specifically the recipe structure and Phase functionality, can have a significant impact through co-ordination and alarm control, and through the efficient releasing / acquiring of equipment. Phases Phases should be designed to reduce the amount of interaction with other Phases or common resource equipment modules. In most cases, where transfer Phases are involved, Phase to Phase coordination is required to ensure both Phases are synchronised throughout their sequence. Where alarm propagation is to the unit level, status information needs to be exchanged between the two Phases, ensuring that both units are held if a unit alarm occurs on either. The actual method of carrying out the co-ordination task depends on the batch control system being employed and on the operating regime for the process cell, e.g. does the process cell have fixed routes or are class based recipes being employed. Copyright 2002 World Batch Forum. All rights reserved. Page 8

9 When defining Phase alarms, they should be relevant to the function of the Phase and be flexible, it should be part of the recipe design to define the alarm limits relevant to each product, this includes providing the facility for disabling the alarming function when not required. Operations Operations should be designed to combine common groups of Phases. Wherever possible coordination between Phases should be carried out inside the operation and not between operations. Procedures / Unit Procedures / Operations Procedures, unit procedures and operations should be designed to ensure that equipment can be acquired and released when and where necessary. Inefficient acquisition and release of equipment can dramatically affect the batch execution time. Part of the design process should be an offline debottlenecking exercise to check the progress through a batch campaign, as certain arbitration issues may not appear until after the 3 rd or 4 th batch is started. Review and optimisation of the recipe or procedure design should be an ongoing task continuing through campaign production. OPERATOR INTERFACE DESIGN A very important aspect of control system operation is around the design of the Operator interface. One possible source of unforeseen events is through improper operator action. There may be good reasons for this action to be taken, but sometimes it can occur due to confusion or lack of understanding about the information being displayed. To ensure that the operations staff are fully effective at all times, and to allow them to carry out their function safely, correctly and efficiently they need:- Access to the relevant information. Information to be displayed in an unambiguous format. The information should be available when and where it s required. Adequate training should be given at the right stage of the project, and reviewed on a regular basis. To improve the quality and availability of critical operator information, and to provide additional support to the operator at the point of use, systems can be deployed by which the operator can access managed help screens or standard operating procedures via a managed data server. Copyright 2002 World Batch Forum. All rights reserved. Page 9

10 CONTINUOUS REVIEW OF DESIGN AND STRATEGY Monitoring of the Production Process via Historical Process Data, and Batch / Alarm Reports The process control system and exception handling philosophies defined during the design stages should be continually reviewed throughout the lifecycle of the system. This can be achieved through analysis of the historical plant data collected by the control system, most control systems today have the capability for continuously recording process plant data and selected events. We should identify the occurrence of all unforeseen events, specifically the number of, the reasons for, and the types of. The most important are the repeated events, which have an affect on batch production time, or on the batch quality, typically: - Specific process alarms Improper operator intervention Arbitration Conflicts / Waiting Time SUMMARY OF THE DESIGN PROCESS Before beginning the design process, we need to define a common set of rules, that all members of the control system design team can understand and follow, these rules are outlined in steps 1,2 and 3 in Table 1 below. Typically this design team would include representatives covering the following areas:- Process / Chemical Engineering, Process Control Design, Batch Management, Operator Interface Design and Plant Operations. This set of common rules needs to be kept simple, and be easily understood by all parties. They need to be designed to cater for the majority of conditions (say > 90%), but be flexible enough to handle the remaining cases. After the definition of these rules is complete the detailed design can begin. Table 1 below, shows a summary of the suggested steps to be included within the normal design process. Copyright 2002 World Batch Forum. All rights reserved. Page 10

11 Table 1 Design Process STEP TASK 1. DEFINE ALARM HANDLING STRATEGY Define the Alarm Propagation Level Define the requirements for :- Alarms / Operator Warnings / Operator Messages. Define the Alarm Groups 2. IDENTIFY COMMON RESOURCES & DEFINE THE ASSOCIATED CONTROL STRATEGY 3. EQUIPMENT CONTROL Define Automatic / Manual Operation of Control Modules. 4. DESIGN OF THE PHYSICAL MODEL Process Unit Process Unit Alarms and Unit Devices in Auto / Manual. Propagation of Transfer Interlocks and Unit Alarms Common Resource Equipment Modules 5. DESIGN OF THE PROCEDURAL MODEL Phases Operations Procedures / Unit Procedures 6. OPERATOR INTERFACE DESIGN 7. CONTINUOUS REVIEW OF DESIGN AND STRATEGY Copyright 2002 World Batch Forum. All rights reserved. Page 11

12 EXAMPLE PROCESS CELL To reinforce some of the ideas discussed within the paper an example process plant has been defined, see Figure 2. Plant design for this example will assume that design Steps 1,2 and 3 from Table 1, have been completed. V 302 V 202 TIC 201 WIC 301 U3 U2 WIC 201 JACKET SERVICES JS201 M 301 M 201 Unit 3 Unit 2 V 301 V 201 To other vessels P 01 V 102 LIC 101 Figure 2 Example Process Cell U1 M 101 V 101 Unit 1 Copyright 2002 World Batch Forum. All rights reserved. Page 12

13 STEP 4 DESIGN OF THE PHYSICAL MODEL During the definition of the physical model for this example, the process unit boundaries have been identified as indicated in Figure 2. After these boundaries have been defined, a list of control modules can be compiled for each unit, then for each of those control modules we can identify which are to be Unit Alarms see Table 2 Physical Model I/O List. Remember, Unit alarms are hard coded and product independent, where the alarm setpoints values are usually specified to protect the process equipment, e.g. to avoid over filling a vessel, or to prevent the process from exceeding the rating of the equipment or instrument. Once compiled, this information is available to all the design team, and displayed in a simple format. Table 2 has been produced specifically for the purpose of this example, in reality this information is usually appended to the existing I/O schedules, thus ensuring information regarding all plant devices is contained within a single document. As you may have noticed from Figure 2, transfer pump P 01 is shared between both Unit 2 and Unit 3 and as such is classed as belonging to both Units. If this motor does fail a Unit Alarm shall be generated and propagated to the unit which is currently using the device. NB: The information contained within Table 2 is for example purposes only. This table identifies only part of the information required in the full and complete design of a physical model. STEP 5 PROCEDURAL MODEL DESIGN To support some of the ideas in the paper regarding the use of Phase parameters and Phase alarms, example information has been given regarding two of the Phases required for the process, see Table 3. This table provides an example of the Phase parameters downloaded as part of the recipe and shows typical Phase alarms for the AGITATE and TEMP_CTRL Phases. These alarms are product dependent and are part of the recipe configuration. Remember that if a Phase alarm occurs it results in the unit procedure and other associated Phases being Held. During the functional design of the generic software modules, typically the Control Module and Phases, we should ensure the design covers all possible requirements, not just those for a specific product or function. For instance, certain recipes may require a specific alarm to be disabled ( e.g. enter a specific setpoint value of 9999 ), or there may be a future requirement for the Phase to continue to carry out different tasks when the Phase or unit procedure is Held, an example of this is in the case of the Agitate Phase. For certain recipes it may be acceptable to Stop the agitator when the Phase is Held, in other cases it may not be, and the agitator must continue to run regardless, that is unless the agitator itself has failed. In the case of the example TEMP_CTRL Phase being Held, the recipe can select to either apply Full Cooling, or to control to a new temperature setpoint. The author has not provided any further information about the procedural model design for the example process. Copyright 2002 World Batch Forum. All rights reserved. Page 13

14 Table 2: Physical Model I/O List REF: TAG REF DESCRIPTION FAILURE CONDITION ALARM RANGE ALARM TYPE / WARNING COMMENT U1 V 101 OUTLET VLV SWITCH FAULT, FAIL TO OPEN, FAIL TO CLOSE U1 V 102 INLET VLV SWITCH FAULT, FAIL TO OPEN, FAIL TO CLOSE U1 LIC 101 LEVEL TX SIGNAL FAULT HI HI LVL LVL > 90 % AVOID OVER FLOW HI LVL LVL > 85 % WARNING U1 M 101 AGITATOR TRIPPED, FAIL TO START, FAIL TO STOP U2 V 201 OUTLET VLV SWITCH FAULT, FAIL TO OPEN, FAIL TO CLOSE U2 V 202 INLET VLV SWITCH FAULT, FAIL TO OPEN, FAIL TO CLOSE U2 WIC 201 WEIGHT TX SIGNAL FAULT HI HI WT LVL > 85 % AVOID OVER WEIGHT HI WT LVL > 80 % WARNING U2 M 201 AGITATOR TRIPPED, FAIL TO START, FAIL TO STOP U2 JS 201 JACKET SERVICES GENERAL FAULT WARNING U2 TIC 201 BATCH TEMPERATURE U2 P01 TRANSFER PUMP ( SHARED DEVICE ) SIGNAL FAULT HI HI TEMP T > 120 DEGC TEMP COULD EXCEED RATED MAX. SWITCH FAULT, FAIL TO OPEN, FAIL TO CLOSE CONDITIONAL BELONGS TO U2 ONLY WHEN THE U2 TXFER OUT PHASE IS ACTIVE. U3 V 301 OUTLET VLV SWITCH FAULT, FAIL TO OPEN, FAIL TO CLOSE U3 V 302 INLET VLV SWITCH FAULT, FAIL TO OPEN, FAIL TO CLOSE U3 WIC 301 WEIGHT TX SIGNAL FAULT U3 M 201 AGITATOR TRIPPED, FAIL TO START, FAIL TO STOP U3 P01 TRANSFER PUMP ( SHARED DEVICE ) HI HI WT LVL > 90 % AVOID OVER WEIGHT HI WT LVL > 80 % WARNING SWITCH FAULT, FAIL TO OPEN, FAIL TO CLOSE CONDITIONAL BELONGS TO U3 ONLY WHEN THE U3 TXFER OUT PHASE IS ACTIVE. Copyright 2002 World Batch Forum. All rights reserved. Page 14

15 Table 3 : Example Phase Alarms and Parameters PHASE PHASE PARAMETER LOW LEVEL SETPOINT SPEED SETPOINT AGITATE PARAMETER DESCRIPTION STOP THE AGITATOR IF THE VESSEL LEVEL FALLS BELOW THIS SETPOINT 0 = FIXED SPEED, % = VARIABLE SPEED TIME SETPOINT STIR TIME, 0 = NO SET TIME, = STIR TIME ( MINS ) ACTION ON PHASE HELD FAULT CONDITION ALARM OCCURED DEVICE IN MANUAL 0 = AGITATOR TO STOP ON PHASE HELD. 1 = AGITATOR CONTINUE ON PHASE HELD ALARM TYPE PHASE ALARM PHASE ALARM PHASE PHASE PARAMETER TEMPERATURE SETPOINT ACTION ON PHASE HELD HOLDING TEMP SETPOINT OUTSIDE LIMITS TEMPERATURE SETPOINT OFF SPEC TEMPERATURE SETPOINT FAULT CONDITION ALARM OCCURED DEVICE IN MANUAL VESSEL TEMPERATURE OUTSIDE LIMITS VESSEL TEMPERATURE OFF SPEC. TEMP_CTRL PARAMETER DESCRIPTION VESSEL CONTENTS TEMPERATURE SETPOINT 0 = APPLY FULL COOLING, 1 = CONTROL TO NEW SETPOINT VESSEL CONTENTS TEMPERATURE SETPOINT WHEN IN HOLDING. OUTSIDE LIMITS ALARM OCCURS IF ACTUAL VESSEL TEMP IS GREATER THAN OR LESS THAN ( TEMPERATURE SETPOINT +/- OUTSIDE LIMITS SETPOINT ) FOR (n) MINUTES. OFFSPEC ALARM OCCURS IF ACTUAL VESSEL TEMP IS GREATER THAN OR LESS THAN ( TEMPERATURE SETPOINT +/- OFF SPEC SETPOINT ) FOR (n) MINUTES. ALARM TYPE PHASE ALARM PHASE ALARM PHASE ALARM WARNING Copyright 2002 World Batch Forum. All rights reserved. Page 15

16 SUMMARY This paper has set out a definition for optimal batch production and identified the areas of the process control system design, employing the S88 Batch Control standard, which can influence achievement of this goal. The author has taken an holistic approach to exception handling, with regard to control system design, and as a result has identified factors, which need to be taken into account when considering the design of an intelligent Exception Handling strategy. To supplement this, an example has been provided to indicate some of the design philosophies used in existing batch processing facilities. In conclusion, it is hoped that this paper has reinforced the statement that the exception handling philosophy of a complex batching plant is a major part of the plant control system design and operation. Also that this philosophy can affect the overall capability of the plant and that the design process does not reach a conclusion when the control system is commissioned. All areas of design should be continually reviewed throughout the full lifecycle of the facility, in the achievement of optimal batch production. REFERENCES 1. ISA-S Batch Control Part 1: Models and Terminology. Copyright 2002 World Batch Forum. All rights reserved. Page 16