Automated identification of hazardous scenarios due to human errors in batch plant operation

Transcription

1 Automated identification of hazardous scenarios due to human errors in batch plant operation Abstract C.Palmer, P.W.H. Chung and D.F. Zhou Department of Computer Science, Loughborough University, Leicestershire, LE11 3TU, UK. S.A. McCoy Hazid Technologies LTD, Beeston, Nottingham, NG9 2ND, UK HAZOP studies are widely used for identifying hazard and operability problems during plant design. However, the application of the technique is very repetitive and time consuming. Research into the automation of HAZOP has been motivated by the opportunity for reducing the considerable time spent by engineers. Much of the research on automated hazard identification so far has concentrated on continuous plants by considering the causes and consequences of deviations from steady state. This paper focuses primarily on batch processes where a batch plant moves through a number of different stages during operation. It investigates the use of qualitative simulation and knowledge-based techniques to analyse the effect of following a sequence of operating instructions on a plant. To create an automated system for batch HAZOP, a number of research issues had to be addressed. These include the formal representation of operating instructions, the generation of deviation from normal operation, the propagation of effects of the results of a sequence of operations and the identification of potential hazardous consequences. CHECKOP is a prototype batch HAZOP system that is being developed at Loughborough University. It takes a plant description and a set of operating instructions as input and produces a HAZOP report automatically. In this paper the novel features of CHECKOP for addressing these issues will be described. The overall system architecture and the details of the major components of the systems will also be discussed. The capabilities and limitations of CHECKOP will be illustrated through a number of examples. 1 Introduction HAZOP studies are widely used for identifying hazard and operability problems during plant design. However, the application of the technique is very repetitive and time consuming. One way to overcome this bottleneck is to develop automated hazard identification systems that emulate the HAZOP technique. Much of the research on automated hazard identification so far has concentrated on continuous plants by considering the causes and consequences of deviations from steady state. The computing technique used is generally based on the idea of fault propagation using signed-directed graph (Chung, 1993; Vaidhyanathan and Venkatasubramanian, 1995). While a lot of progress has been made in this area (McCoy et al, 2000a and 2000b; Chung et al, 2003), very little work has been done in automated hazard identification of batch plants. In batch processes the plant operation moves through a number of stages, rather than each equipment item remaining in a steady state indefinitely, as is normal for continuously operating plants. The changes in equipment state over time mean that batch processes are more difficult to model accurately than continuous processes. Batch processes require the state of the plant to be expressed. A method of representing a sequence of actions (operating instructions) to achieve a state is also needed. These are not captured by the signeddirected graph technique (McCoy et al, 2003). A new approach is being sought (Chung and McCoy, 2004; McCoy et al, 2004). This paper describes a research project that considers the use of qualitative simulation and knowledge-based techniques to analyse the effect following a sequence of operating instructions has on a plant. It commences by describing a simple batch plant case study. A number of research issues which had to be addressed in order to create an automated system for batch HAZOP are considered. A prototype batch HAZOP system, CHECKOP, is described. The novel features contained within it for addressing the research issues are detailed. Examples from the case study are used to illustrate the capabilities and limitations of CHECKOP.

2 Figure 1 A Simple Batch Processing Plant Example 2 Batch Reactor Case Study In order to demonstrate how the prototype batch HAZOP system, CHECKOP, is used to aid batch HAZOP of a process, the simple batch processing plant illustrated in Figure 1 is considered. The reactor shown produces a product P from two reactants A and B, using the simple chemical reaction A + B P. An excess of reactant B is used so that reactant A is completely consumed in the reactor. To safely produce the product, a sequence of operating instructions is followed by the human operators of the plant. A simplified example of such a sequence might be: 1. Charge the reactor with reactant A. 2. Turn on the agitator and the cooling water flow through the cooling jacket. 3. Gradually add a sufficient excess of reactant B to the vessel. 4. Continue mixing reactor contents for a while, to allow reaction to complete. 5. Pump the product mixture away for separation. 6. When reactor is empty, switch off mixer, product transfer pump and cooling water. 7. Wash reactor internals thoroughly with water. 3 Research Issues In order for an operating procedure to be analysed by a computerized system it must be formally represented. Instructions written in natural language style are difficult for the computer to understand and their meaning may also be ambiguous. Some means of representing the (typically) implicit assumptions associated with each step is needed. For instance, the procedure shown in section 2 assumes that the reactor is clean and empty at the start of the batch. If, however, an operator had not adequately washed the reactor, or (worse still) had not pumped away the product mixture after the last batch had finished, adding reactant A to the reactor in such a state could have potentially hazardous consequences (such as a premature reaction with reactant B present from the last batch). Predicting such consequences is possible if some way of representing the sequence of actions in the procedure is available, as well as a way of expressing the assumed state of the plant items before and after each of the steps.

3 A combination of human error analysis and process modelling can be used to detect these situations and to suggest redesign of the plant to eliminate such dangers. HAZOP studies are performed by a multi-disciplinary team of experts. A study considers all possible deviations of a plant from its intended operation, by using deviation guidewords (None, More of, Less of, Part of, Other) applied to each of the process variables (flow, pressure, temperature, etc.) in the plant in turn (Lawley, 1974). The causes and consequences of each of these deviations are then examined, and a report of all the important hazards and operability problems is prepared. For a continuous plant the expected operation of the plant is a single steady state, and deviations from that are disturbances in the pressures, temperatures, flows, etc. in the plant. For Batch HAZOP this method is extended to consider deviations from the intended state of the plant during each of the stages of its operations. The technique also looks at variations in the operating instructions of the plant, to consider what would happen if operations were missed out, performed in the wrong order, for too long a time, etc. 4 CHECKOP System Overview A research prototype, CHECKOP, has been created to address the research issues detailed. The CHECKOP system consists of three main components, takes a number of files as input and generates a report file as output as shown in Figure 2. Plant Description File Plant specific Operating Procedure File Internal Plant Model Parser Internal Procedure Model Action Model Library Simulation Engine Modified Procedure Deviation Generator Batch HAZOP Report CHECKOP Figure 2 The components of CHECKOP 5 CHECKOP Features The three main components of the system are the Parser, the Deviation Generator and the Simulation Engine. The Parser reads the input files prepared by the user and converts the information into an internal form for

4 processing by the other two components. The information provided by the user is specific to the plant that is required to be HAZOPed. One of the files gives details about the items of equipment in the plant, their connectivities and their current states. The other file contains a set of operating instructions to be applied to the plant to bring the plant from its initial state to its goal state, whilst also achieving the production of a batch of product! The Deviation Generator systematically applies the deviation guidewords to the operating procedure so that the Simulation Engine can infer what will be the consequence if a certain instruction in the procedure is not executed, or if the instruction is carried out too early or too late, etc. Having gone through all the deviations, the Simulation Engine will produce a report file providing warnings against any undesirable situations that may result from the deviations. To carry out the simulation the Simulation Engine requires the Action Model Library which provides information about actions that can be performed on different pieces of equipment and the effects of those actions. 5.1 Plant Description An object-oriented approach is used to describe the plant. Consider the batch plant shown in figure 1; each item in the plant is declared in the plant description file. For each item at least the following basic information is given: The type of unit it belongs to; Which other plant items it is connected to. Other appropriate information related to a plant item will also be stored with that plant item. Table 1 provides some example descriptions of the plant items found in figure 1. Formal plant item declaration instance(tank101 isa tank, [ content info [reactanta], outports info [out is [pump101,in]] ]). instance(pump101 isa pump, [ status is offline, outports info [out is [valve101,in]] ]). instance(valve101 isa valve, [ status is closed, outports info [out is [reactor101, in2]] ]). instance(reactor101 isa stirred_tank_reactor, [ outports info [out1 is [valve103,in], out2 is [valve106,in]], heatsink info [hout is [jacket101,hin]], Explanation Tank101 is a tank The content of the tank is reactanta The outlet of the tank is connected to the inlet of pump101 Pump101 is a pump The status of the pump is off-line The outlet of the pump is connected to the inlet of valve101 Valve101 is a valve The status of the valve is closed The outlet of the valve is connected to inlet 2 of reactor101 Reactor101 is a stirred-tank-reactor The outlet 1 of the reactor is connected to the inlet of valve 101 and outlet 2 is connected to valve 106 The heat of the reactor is transferred to jacket 101 The intended reaction is called reaction_ab_p reaction info [reaction_ab_p] ]). Table 1 Explanation of Plant Description

5 By convention the batch plant is given in its idle state, with all valves closed and all pumps off-line. During operation the states of these equipment items are changed by the action of plant operations. 5.2 Operating Procedure Description In order to avoid the difficulties and ambiguities caused by natural language, the operating procedures supplied as input to CHECKOP are composed using a formal template representation. The following templates are utilised: Template 1: Item Action Example: valve101 open Template 2: Item Action until Condition Example: mixer on until elapsed-time 20 minutes Template 3: Item1 Action Item2 Filler-word Fluid until Condition Example: reactor101 fill-from tank101 with reactanta until volume 30 percent Given the plant shown in figure 1, the instructions for charging reactor101 with reactanta can be expressed as: valve101 open pump101 start reactor101 fill-from tank101 with reactanta until volume 30 percent pump101 stop valve101 close An input file of operating instructions for CHECKOP is shown in figure 3 below. Compare this with the operating instruction sequence for human operators given in the Batch Reactor Case Study section (section 2). (1) valve101 open (2) pump101 start (3) reactor101 fill_from tank101 with reactanta until volume 30 percent (6) agitator turn_on (7) valve104 open (8) jacket1 cool_content until temperature 25 degree (9) valve102 open (10) pump102 start (11) reactor101 fill_from tank102 with reactantb until volume 60 percent (12) pump102 stop (13) valve102 close (14) agitator stir_content of reactor101 until elapsed_time 20 minutes (15) valve103 open (16) pump103 start (17) reactor101 empty_to tank103 with [reactantb, productp] until volume 0 percent (18) pump103 stop (19) valve103 close (20) agitator turn_off (21) valve104 close (22) valve106 open (23) valve105 open (24) reactor101 wash with water (25) valve105 close (26) valve106 close Figure 3 Example Operating Procedure for Batch Plant Some of the arguments given in this operating procedure may seem to be redundant, but they do play a part as a way of checking the plant state during operation against the stated intention of the action in the instructions. For

6 example in the action reactor101 fill-from tank101 with reactanta until volume 30 percent the with reactanta part may be considered as a check that tank101 is a source of reactanta just in case the tank contents have been contaminated, or the action wrongly executed, for instance. Some of the actions shown in figure 3 necessitate more operator involvement, and may therefore not seem to be not primitive when compared to others (e.g. compare pump101 start to reactor101 wash with water ). This is inevitable, but does not prevent simulating the state of the plant during operation. The file containing the operating instructions for operating the plant is read in by CHECKOP and translated into its internal form. 5.3 The Deviation Generator The Deviation Generator component of CHECKOP applies the batch HAZOP guidewords. The guidewords are utilized by introducing a particular error into an operating procedure. The Deviation Generator applies the guide words no, early and late systematically to generate different versions of the operating procedure. This allows CHECKOP to explore the consequences of different scenarios that could result from human errors made by the operators. By applying the guideword no to the following example procedure: Charge Reactor101 with reactanta (1) valve101 open (2) pump101 start (3) reactor101 fill-from tank101 with reactanta until volume 30 percent the Deviation Generator will remove systematically one instruction at a time from the procedure, which will result in five different operations. Each represents an error of omission, i.e. an operator failed, or forgot, to carry out a specified instruction. For example, procedure with instruction 1 omitted: (2) pump101 start (3) reactor101 fill-from tank101 with reactanta until volume 30 percent Procedure with instruction 2 omitted: (1) valve101 open (3) reactor101 fill-from tank101 with reactanta until volume 30 percent When the guide word early is applied to the operation, actions are moved earlier in the procedure. For example, moving the instruction reactor101 fill-from tank101 with reactanta until volume 30 percent two steps forward will result in the procedure: (3) reactor101 fill-from tank101 with reactanta until volume 30 percent (1) valve101 open (2) pump101 start All the different procedures generated by the Deviation Generator are passed to the Simulation Engine for analysis to identify operability problems and potential hazardous situations.

7 5.4 Simulation Engine The heart of the CHECKOP system is the simulation engine. Given an operating procedure, it applies each of the instructions one at a time and simulates its effect by changing the state of the plant. Therefore, the plant moves from one state to another until all the instructions are completed. However, the execution of a procedure may not always reach its end. This is because when the simulation engine detects an operability problem or hazardous situation it will report this to the user. For example, an analysis of the example procedure with instruction one missing will result in the following warning: There is no flow path between tank101 and reactor101 for filling. The simulation engine will work systematically through all the procedures generated by the deviation generator. 5.5 The Action Model Library Associated with each plant item type there is an action model in the Action Model Library. An object-oriented approach is used, so that each model inherits the properties from its class definition. The model specifies the operations that can be carried out on that type of plant item. For each action the pre-conditions that must be true before the action and the post-conditions after the action are stated. For example, the actions for a valve can be open or close. In its general form, there is no pre-condition for opening or closing a valve. However, the post-condition for opening a valve is that a flow path exists between the upstream unit and the downstream unit. The post-condition for closing a valve is that the flow path between the upstream unit and the downstream unit no longer exists. The actions for a pump can be start or stop. To start a pump, the pre-conditions are that there must be a flow path between the source of a fluid and the pump and there must be a flow path between the pump and the sink. If the pre-conditions are not met then the start operation will generate a warning message. The post-condition of starting a pump is that there is a flow between the source and the sink. On the other hand, there is no precondition for stopping a pump and the post-condition of stopping a pump is that there is no flow between the source and the sink. 6 Sample Runs A sample of the type of output produced by CHECKOP is given in Table 2, which shows the results for the examples given in the Deviator Generator section (section 5.3). Guideword Action Consequences No action (1) valve101 open (2) pump101 deadheading, equipment damage. (2) pump101 overheating. (3) reactor101 cannot be filled from tank101 because there is no flow path. (6) agitator running while vessel empty. No action (2) pump101 start (3) reactor101 cannot be filled from tank101 because there is no driving force for flow. Early action (3) reactor101 fill from tank101 with reactanta until volume 30 percent (-2) reactor101 cannot be filled from tank101 because there is no flow path. Table 2 Sample Batch HAZOP results from CHECKOP

8 The format shown here is similar to that produced in a traditional HAZOP study, except for the absence of a column for Causes and for Suggested Actions. The deviations generated by CHECKOP are deemed to be sufficient cause for the scenarios reported. CHECKOP does not advise on how to solve the problems it detects. The instructions in the operating procedure are referred to by line number in the Action and Consequences column. If no such number is given in the consequences column, then the operation referred to by that consequence is the deviated one. For Early/Late action, a number is given in parentheses after the entry in the Action column this gives the number of sequence steps early or late that the action takes place, for the deviation considered. 7 Discussion and Future Work When both input files have been processed, CHECKOP proceeds to examine deviations from the intended operating instructions and to simulate the plant operation for each deviation as explained above. For each simulation, it detects when hazardous situations or operability problems arise and reports them. It also continues the simulation after such problems, to see if there are further consequences later on if the procedure is followed blindly. This policy is most likely to over-report hazards because problems are usually (but not always) noticed when they occur. Nevertheless, over-reporting is preferable to missing something important. Further work is required on the deviation generator part of CHECKOP, in order to allow it to generate the most credible deviations of a given operating instruction. No action is straightforward there are only a limited number of ways of applying this guideword. Early action and Late action present more difficult decisions how far is it permissible to move the action? Without a sensible limit on this, exhaustive examination could bury the user in unwanted detail. A wider range of deviation guidewords needs to be considered, as automatically applied to actions in the operating instructions. So far, No Action and Early/Late Action have been considered and modelled. The next step is to fully consider Shorter/Longer Action, where the action is performed for a longer or shorter time than intended. This is particularly applicable for those actions which have an until clause (e.g. what happens if reactor101 is only filled to 10% instead of 30%?). Variants of the Other Action guide word should also be considered. This would include considering what happens if the action is performed on the wrong piece of equipment (e.g. what if the wrong pump is switched off?). Care needs to be taken to ensure that the most sensible and likely deviations are created for a given guide word, as the potential number of variations for even a single action step is huge. The Action Model Library is limited and requires further development work, to cover a wider range of actions; additionally, some of the existing action models need enhancing, to ensure that their pre-conditions and postconditions are as accurate as possible. CHECKOP s operating procedure templates describe primitive actions. A method is needed of organising the actions into either unordered groups or ordered sequences. Thus the example operating procedure shown in figure 3 could be organised as follows: charge reactor101 with reactanta: (1) valve101 open (2) pump101 start (3) reactor101 fill_from tank101 with reactanta until volume 30 percent start_up reactor101 cooling and agitator: (6) agitator turn_on (7) valve104 open (8) jacket1 cool_content until temperature 25 degree charge reactor101 from tank102 with excess of reactantb: (9) valve102 open (10) pump102 start (11) reactor101 fill_from tank102 with reactantb until volume 60 percent (12) pump102 stop (13) valve102 close wait until reaction complete:

9 (14) agitator stir_content of reactor101 until elapsed_time 20 minutes discharge product mixture for separation: (15) valve103 open (16) pump103 start (17) reactor101 empty_to tank103 with [reactantb, productp] until volume 0 percent (18) pump103 stop (19) valve103 close shut_down reactor101 cooling and agitator: (20) agitator turn_off (21) valve104 close wash reactor101 thoroughly with water: (22) valve106 open (23) valve105 open (24) reactor101 wash with water (25) valve105 close (26) valve106 close Figure 4 Example Operating Procedure for Batch Plant with grouped actions. The primitive actions are grouped together to form an operation. The plant operating procedure consists of a succession of operations. The process operations correspond most closely to the level of operating instructions an operator will usually follow, whereas the primitive actions correspond to the detailed activities performed in order to achieve the goals of the stated operation. This grouping of actions will allow standard operations models to be defined and reused in the same way that individual actions are defined from a model. Within CHECKOP, further development will also be needed to model phenomena which are not so far covered very well, such as process fluids and their interactions and reactions (whether intended or unwanted). This work will feed into more accurate modelling of the consequences of mal-operation in the batch plant, in terms of chains of events and/or hazards a form of consequence modelling. The objective in doing this type of modelling is to provide an even richer form of output as a result of the batch Hazop emulation performed by CHECKOP. 8 Conclusion By formalising the actions that take place in the batch plant we can start to look at the most likely human failure modes which could lead to hazards in the plant (in contrast to the process initiated ones). CHECKOP, the prototype batch HAZOP system, has demonstrated proof of concept for modelling operating procedures and their effect on a simple batch process. CHECKOP allows the state of plant units to be defined. A sequence of operator actions may be represented whereby each action is associated with a set of assumptions about the state of the plant and an expectation of the results of the action. Using the CHECKOP simulation engine batch HAZOP can be demonstrated by considering deviations from the intended sequence of operations and their resulting hazards. 9 References Chung, P.W.H. (1993) Qualitative Analysis of Process Plant Behaviour. In: Chung, P.W.H., Lovegrove, G. and Ali, M. (eds.), Proceedings of the Sixth International Conference on Industrial and Engineering Applications of Artificial Intelligence and Expert Systems, June 1993, Edinburgh, Gordon and Breach Science Publishers, pp Chung, P.W.H., McCoy, S.A. and Zhou, D.F. (2003) Computer-aided Hazard Identification. In: Mannan, M.S (ed.), Proceedings of Mary Kay O Connor Process Safety Center Annual Symposium, October 2003, Texas A&M University, Omnipress, pp Lawley, H.G. (1974) Operability Studies and Hazard Analysis, Chem. Engng Prog. 70, pp McCoy, S.A., Wakeman, S.J., Larkin, F.D., Chung, P.W., Rushton, A.G. and Lees, F.P. (2000a) HAZID, A

10 Computer Aid for Hazard Identification 4. Learning Set, Main Study System, Output Quality and Validation Trials, Transactions of the Institution of Chemical Engineers, Part B, 78, pp McCoy, S.A., Wakeman, S.J., Larkin, F.D., Chung, P.W., Rushton, A.G. and Lees, F.P. (2000b) HAZID, A Computer Aid for Hazard Identification 5. Future Development Topics and Conclusions, Transactions of the Institution of Chemical Engineers, Part B, 78, pp McCoy, S.A., Zhou, D. and Chung, P.W.H. (2003) State-Based Modelling in Hazard Identification. In: Chung, P.W.H., Hinde, C.J. and Ali, M. (eds), Proceedings of 16th International Conference on Industrial and Engineering Applications of Artificial Intelligence and Expert Systems, June 2003, Springer-Verlag, pp McCoy, S.A. and Chung, P.W.H (2004) Computer-aided HAZOP of Batch Processes. In: Proceedings of HAZARDS XVIII Symposium, November 2004, Manchester. McCoy, S.A., Chung, P.W.H. and Zhou, D.F. (2004) Computer-Aided HAZOP of Batch Processes. In: A. and Matos, H. (eds.), Proceedings of European Symposium on Computer-Aided Process Engineering (ESCAPE-14), May 2004, Lisbon, Elsevier (Amsterdam). Vaidhyanathan, R. and Venkatasubramanian, V. (1995) Digraph-based models for automated HAZOP analysis, Reliab Eng System Safety, 50, 1,