AUTOMATIC VERIFICATION OF SAFETY INSTRUMENTED SYSTEM IN CHEMICAL PROCESSES

Size: px
Start display at page:

Download "AUTOMATIC VERIFICATION OF SAFETY INSTRUMENTED SYSTEM IN CHEMICAL PROCESSES"

Transcription

1 AUTOMATIC VERIFICATION OF SAFETY INSTRUMENTED SYSTEM IN CHEMICAL PROCESSES Jinkyung Kim, Younghee Lee and Il Moon Department of Chemical Engineering, Yonsei University, 134 Shinchon-dong Seodaemun-ku, Seoul , Korea; Model checking is applied to determine the error-free design of the SIS and to find the logical errors in the chemical processes. We propose an automatic technique to provide and to modify the P&ID design of SIS control logics in the chemical process industry. Model checking is also useful when SIS is analyzed with FTA. It attempts to verify correctness and completeness of FT for the SIS. The idea of the verification of FT is to systematically specify the system model and to prove the correctness and completeness of FT. Model checking method, an automatic error finding approach, is used to verify its safety and reliability. The strength of this method is to synthesize a feasible sequence through a counter-example and to verify its correctness using computation tree logic (CTL) simultaneously. This paper proposes an automatic technique to provide and to modify the P&ID design and the FT of the SIS control logics in the chemical process industry. KEYWORDS: model checking, automatic verification, CTL, SIS, FT INTRODUCTION A safety instrumented system (SIS) is one of the most important protective measurements in chemical industrial plants and provides automatic actions to correct an abnormal process event or behavior that has not been controlled by basic control systems and manual interventions. SIS is composed of any combination of sensors, logic solvers, and final control elements for the purpose of taking the process to a safe state when predetermined conditions are violated. A SIS is commonly used on rare occasions including emergency shutdown system, safety shutdown system, and safety interlock system. A SIS, therefore, must be available to operate whenever needed. If SIS failure occurs, it is difficult to avoid from accidents such as explosion, process damage, environmental damage, loss of cost, and loss of human life. A SIS, thus, must be verified and validated thoroughly and systematically in design stage. Most of existing methods such as HAZOP (hazard and operability study), FTA (fault tree analysis), FMEA (Failure mode and effect analysis), etc. for identifying hazards, safety and reliability of SIS are commonly used in industrial field. These methods, however, are usually very time consuming and only depend on manpower. In this paper, we apply model checking approach to provide design of the SIS and to validate the FT for the SIS in chemical industrial processes. This method is tested by two examples to find the logical and unfeasible errors automatically which is difficult to find using manual methods. MODEL CHECKING METHOD The model checking verification method is an alternative approach that has achieved significant results recently. The main purpose of a model checker is verifying the model with regard to a requirement specification. Efficient algorithms are able to verify properties of extremely large systems. In these techniques, specifications are written as formulas in a proposition temporal logic and systems are represented by state-transition graph. The verification is accomplished by efficient searching techniques that views the transition system as a model for the logic, and determines if the specifications are satisfied by the model. There are several advantages to this approach. An important one is that the procedure is completely automatic. The model checker accepts a model description and specifications written as temporal logic formulas, and it determines if the formulas are true or not for that model. A model-checking tool (UPPAAL is used in this paper) accepts system requirements or design (called model) and a property (called specification) that the final system is expected to satisfy. The tool then output yes if the given model satisfies given specifications and generates a counterexample otherwise. The counterexample details why the model doesn t satisfy the specification. By studying the counterexample, we can pinpoint the source of the error in the model, correct the model, and try again. The idea is that by ensuring that the model satisfied enough system propertied, we increase our confidence in the correctness of the model. The systems requirements are called models because they represent requirements or design. Likely SIS in chemical process, control-oriented systems occur in a wide variety of safety problems in design stage. For the control-oriented systems, finite stat machines are widely accepted as a good, clean, and abstract notation for defining requirements and design. For modeling the systems, the followings are also needed to: be able to modularize the requirements to view them at different levels of detail have a way to combine requirements or design of components 1

2 Figure 1. Raw water supplying system in HOU (Heavy Oil Upgrading) plant be able to stat variable and facilities (for example, valve or pump) to update them in order to use them in guards on transitions. Model checking tool (UPPAAL) has its own rigorous formal language for design models. CASE STUDY 1 Raw water supplying system is ubiquitous process in chemical industrial plants. Figure 1 is a part of P&ID (Piping & Instrumentation Diagram) for utility process design of HOU project in petrochemical plant. Raw water from a river is stored in a raw water pond. The water flows to a raw water tank through a pump. The water runs into the plant through three valves (V22, V23, and V14). The water is used for cooling water in process through valve 22, for clarifier feed through valve 23, and for fire water or emergency shower through valve 14. Valve 14 is directly connected to the by-pass pipeline between pump and raw water tank. Valve 14 is always open because it is used in emergency situations only. The system has two pumps: one which is used for normal operation and the other, which stands by the first pump. If the first pump is out of order, the other pump starts operating instantly. These pumps get a signal from indicator I-100. I-100 is controlled by pressure controller PI-101 or level controller LIC-101. PI-101 gets a signal from pressure translator PT1, monitoring the pressure of flow from raw water pond to the pump. If PI-101 indicates low low pressure, the pump turns off automatically; otherwise the pump is operated normally. In case that I-100 is connected to LIC-101 (Case 1), I-100 get a signal from LIC-101when level of raw water tank is high high, and the pump turns off by this signal. Another case is when LIC-101 is connected to valve LV (Case 2). If raw water tank has high high level, LV is closed. There will never be a situation in which two pumps turn off at the same time because the water is always prepared to use for emergency. At least: one pump needs to be operated. This example represents the case to search these unsafe control logics of SIS of all possible control logics in early design stage. The sequences of the normal operation of the system are following; 1. Water flows from raw water pond when valve V1. 2. If the pressure is not low low, one of two pumps turns on. 3. If pump1 turns on, valve V5 is open and if pump2 turns on, valve V10 is open. 4. If valve V5 or V10 is open, valve LV is open. 5. Water flows into raw water tank if valve LV is open. 6. Valve 14 is always opened to prepare emergency. 7. Water flows into the process through valve V22 or V23. Model description consists of 10 modules. Units or facilities do not exist below are not modeled because these can be omitted as a matter of analyzing control logics of the system. Figure 2 illustrates the model description of Case A. Specifications for verification are; Case A: A½Š!(PI101¼¼1 && Pump1¼¼0 && Pump2¼¼0 & Lv¼¼1 && (!(Pump1_ fail¼¼1) &&!(Pump2_ fail¼¼1))) This specification represents there is no situation that inlet flow from raw water pond is not low low pressure, two pumps are not operated without failure. The result for the specification is not satisfied. A counter example trace is shown in figure 3. Two pumps are not operated simultaneously when the level of raw water tank leads to high high. This control logic has an unsafe state, the system 2

3 IChemE SYMPOSIUM SERIES NO. 153 Figure 2. The model description of Case A needs to redesign. This specification means there is no situation that inlet flow from raw water pond is not low low pressure, one pump is operated without failure, valve LV is closed, and the level of raw water tank leads to high high. The answer for this query is not satisfied and the reasonable trace is shown in figure 3. This situation is less unsafe than Case A, but it is also an error because the water cannot flow only through Case B: A½!(PI101¼¼1 && (Pump1¼¼1 or Pump2¼¼1) && Level¼¼1 && Lv¼¼0 && (!(Pump1_fail¼¼1) &&!(Pump2_fail¼¼1))) Figure 3. A counter example trace of specification for Case A and Case B 3

4 Figure 4. The process diagram of a storage tank with SIF V14. If emergency water or fire water is not used, the water cannot flow anywhere. Then, a safety valve next to valve V14 will pop up when the pressure in the pipeline is over set point of the safety valve. Reinstallation is needed. It is necessary to modify this control logic of safety instrumented system. Control logical errors are automatically found by model checking method in the design of the SIS. This case study illustrates that model checking becomes an automatic technique for the safety verification of the chemical process design instead of manual safety analysis methods. If each process unit is modeled as a module, it becomes a more fast and effective method to verify and find the safety errors of whole plant design. CASE STUDY 2 The subject of this case study is a Safety Instrumented Function (SIF) which protects a storage tank by measuring pressure, flow rate, temperature, and liquid level. Logic voting is employed in the logic solver. The process diagram for the process is shown in Figure 4. The fault tree model of Probability of Failure on Demand (PFD) for this SIF process is shown in Figure 5. The process consists of a storage tank, two level switches, two temperature switches, two pressure transmitters, three flow transmitters, and two block valves. The purpose of this case study is to evaluate reliability and SIL by correctly using FTA. The correctness of reliability and SIL depends on the completeness of synthesis of the fault tree. It is important to verify and find errors in a synthesized fault tree. We propose a verifying method using model checking through this case study. Model description of the process in UPPAAL is performed for normal operation and failure of each device. In case of level switches, temperature switches, and pressure transmitters, they are normally operated if at least one device out of two devices is operated. Block valves are also operated with the same logic. In case of flow transmitter, they are normally operated if at least two out of three devices are normally operated. The variables used in the modeling are Boolean logics, and they have these operating control logics. Synchronization variables are used to clear state transition delays. The state of each device has Boolean variables (i.e. normal or fail) randomly. The state of failure mode connecting both devices has also normal or fail according to operating control logics. In case of flow transmitters, the state for the number of devices operating is added because three flow transmitters are connected. Specifications for verification of fault tree based on Figure 5 are following; Specification 1: There is no event that both pressure transmitter lead to fail except that two transmitters are failing at the same time. A½Š!(!(P1¼¼1 && P2¼¼1) && PTF¼¼1) Specification 2: There is no event that both temperature switches lead to fail except that two switches are failing at the same time. A½Š!(!(T1¼¼1 && T2¼¼1) && TSF¼¼1) Specification 3: There is no event that both level switches lead to fail except that two switches are failing at the same time. A½Š!(!(L1¼¼1 && L2¼¼1) && LSF¼¼1) Specification 4: There is no event that both valves lead to fail except that two valves are failing at the same time. A½Š!(!(V1¼¼1 && V2¼¼1) && VF¼¼1) Specification 5: There is no state that all flow transmitter lead to fail except that three transmitters are failing at the same time. A½Š!(!(F1¼¼1 && F2¼¼1 && F3¼¼1) && FTF¼¼1) The verifying results of the specifications 1, 2, 3, and 4 are satisfied. The results show that the gates corresponding to each device failure mode in the fault tree based on Figure 5 have correct gate logics (AND or OR) and complete subevents. However, the specification 5 is not satisfied. The counter-example is shown in Figure 6. Based on the counter-example, flow transmitters lead to failure when 4

5 Figure 5. A probability of failure on demand fault tree for the SIF not only three transmitters failed at the same time, but also when two transmitters fail simultaneously. It is necessary for the fault tree to be modified as shown in Figure 7. The PFD avg data for the individual components used in this case study are shown in Figures 5 and 7. The calculated overall system PFD avg is 4.47 E-2 in case of the non modified fault tree, which falls into SIL 1 according to Table 10, 7.41 E-3 in case of the modified fault tree after verification, which falls into SIL 2. The result illustrates that it is possible for an incorrect fault tree to lead a change of SIL estimation. Figure 6. A counter-example of the specification 5 CONCLUSION This study proposes a novel approach to verify the design of SIS control logic for chemical engineering process using model checking. Model checking is applied to automatically verify unsafe procedures of SIS control operation in the raw water supplying system. Based on the results, we propose a novel approach to validate safe design of SIS instead of current safety assessment methods such as HAZOP. We introduce an automatic technique to provide and to modify the P&ID design of SIS control logics in the chemical process industry. Another application represents that the model checking technique is useful when we are to validate the correctness of informal safety analysis such as FTA. It attempts to 5

6 Figure 7. A modified fault tree for probability of failure on demand verify the correctness and completeness of FT for the SIL. The idea of the verification of FT is to systematically specify the system model and to prove the correctness and completeness of FT. Automatic model checking technique helps a safety engineer better understand the context better in which the specified failure mode occurs so that he/she conduct a more precise safety analysis. REFERENCES Alur., R. and Dill, D., 1994, A theory of timed automata, Theoretical Computer Science B 126: Behrmann, G., David, A. and Larsen, K.G., A Tutorial on Uppaal, Available at Center for Chemical Process Safety (CCPS), 2000, Guidelines for chemical process quantitative risk analysis, 2 nd edition, New York: Center for Chemical Process Safety, AIChE. IEC 61508, 1998, Functional safety of electrical/electronic/ programmable electronic safety related systems, Part 1. International Electrotechnical Commission, Final standard. ISA TR Part 3, Safety instrumented functions (SIF) safety integrity level evaluation techniques Part 3: Determining the SIL of a SIF via fault tree analysis. Kim, J. and Moon, I., 2000, Synthesis of safe operation procedure for multi-purpose Bath Processes using SMV. Computers and Chemical Engineering, 24: Kim, J., Lee, Y. and Moon, I., 2006, Graphical modeling for the safety verification of chemical processes, ESCAPE 16 meeting Jul Kim, J. and Moon, I., 2006, Automatic verification of safety instrumented system control logics in chemical industrial processes. AIChE Annual Meeting, San Francisco, Dallas, Nov Moon, I., Power, G. J., Burch, J. R. and Clarke, E.M., 1992, Automatic verification of sequential control systems using temporal logic, AIChE Journal, 38: OREDA, 2002, Offshore reliability data handbook, 4 th edition, Hovik, Norway: Det Norske Veritas. 6