Automatic Verification of Safety Instrumented System in .../media/Documents/Subject... · AUTOMATIC VERIFICATION OF SAFETY INSTRUMENTED SYSTEM IN CHEMICAL ... and abstract ... Automatic

IChemE SYMPOSIUM SERIES NO. 153 # 2007 IChemE

AUTOMATIC VERIFICATION OF SAFETY INSTRUMENTED SYSTEM IN CHEMICALPROCESSES

Jinkyung Kim, Younghee Lee and Il Moon

Department of Chemical Engineering, Yonsei University, 134 Shinchon-dong Seodaemun-ku, Seoul 120-749, Korea; e-mail:

[email protected]

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

INTRODUCTIONA safety instrumented system (SIS) is one of the mostimportant protective measurements in chemical industrialplants and provides automatic actions to correct an abnor-mal process event or behavior that has not been controlledby basic control systems and manual interventions. SIS iscomposed of any combination of sensors, logic solvers,and final control elements for the purpose of taking theprocess to a safe state when predetermined conditions areviolated. A SIS is commonly used on rare occasions includ-ing emergency shutdown system, safety shutdown system,and safety interlock system. A SIS, therefore, must be avail-able to operate whenever needed. If SIS failure occurs, it isdifficult to avoid from accidents such as explosion, processdamage, environmental damage, loss of cost, and loss ofhuman life. A SIS, thus, must be verified and validatedthoroughly and systematically in design stage. Most ofexisting methods such as HAZOP (hazard and operabilitystudy), FTA (fault tree analysis), FMEA (Failure modeand effect analysis), etc. for identifying hazards, safetyand reliability of SIS are commonly used in industrialfield. These methods, however, are usually very time con-suming and only depend on manpower. In this paper, weapply model checking approach to provide design of theSIS and to validate the FT for the SIS in chemical industrialprocesses. This method is tested by two examples to find thelogical and unfeasible errors automatically which is difficultto find using manual methods.

MODEL CHECKING METHODThe model checking verification method is an alternativeapproach that has achieved significant results recently.The main purpose of a model checker is verifying themodel with regard to a requirement specification. Efficientalgorithms are able to verify properties of extremely

1

large systems. In these techniques, specifications arewritten as formulas in a proposition temporal logic andsystems are represented by state-transition graph. The veri-fication is accomplished by efficient searching techniquesthat views the transition system as a model for thelogic, and determines if the specifications are satisfied bythe model. There are several advantages to this approach.An important one is that the procedure is completelyautomatic.

The model checker accepts a model description andspecifications written as temporal logic formulas, and itdetermines 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) anda property (called specification) that the final system isexpected to satisfy. The tool then output yes if the givenmodel satisfies given specifications and generates a counter-example otherwise. The counterexample details why themodel doesn’t satisfy the specification. By studying thecounterexample, we can pinpoint the source of the error inthe model, correct the model, and try again. The idea isthat by ensuring that the model satisfied enough systempropertied, we increase our confidence in the correctnessof the model. The systems requirements are called modelsbecause they represent requirements or design.

Likely SIS in chemical process, control-orientedsystems occur in a wide variety of safety problems indesign stage. For the control-oriented systems, finite statmachines are widely accepted as a good, clean, and abstractnotation for defining requirements and design. For modelingthe systems, the followings are also needed to:

– be able to modularize the requirements to view them atdifferent levels of detail

– have a way to combine requirements or design of com-ponents

Figure 1. Raw water supplying system in HOU (Heavy Oil Upgrading) plant


– be able to stat variable and facilities (for example, valveor pump) to update them in order to use them in guardson transitions.

Model checking tool (UPPAAL) has its own rigorousformal language for design models.

CASE STUDY 1Raw water supplying system is ubiquitous process in chemi-cal industrial plants. Figure 1 is a part of P&ID (Piping &Instrumentation Diagram) for utility process design ofHOU project in petrochemical plant. Raw water from ariver is stored in a raw water pond. The water flows to araw water tank through a pump. The water runs into theplant through three valves (V22, V23, and V14). Thewater is used for cooling water in process through valve22, for clarifier feed through valve 23, and for fire wateror emergency shower through valve 14. Valve 14 is directlyconnected to the by-pass pipeline between pump and rawwater tank. Valve 14 is always open because it is used inemergency 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 oforder, the other pump starts operating instantly. Thesepumps get a signal from indicator I-100. I-100 is controlledby pressure controller PI-101 or level controller LIC-101.PI-101 gets a signal from pressure translator PT1, monitor-ing the pressure of flow from raw water pond to the pump. IfPI-101 indicates low low pressure, the pump turns offautomatically; otherwise the pump is operated normally.In case that I-100 is connected to LIC-101 (Case 1), I-100get a signal from LIC-101when level of raw water tank ishigh high, and the pump turns off by this signal. Anothercase is when LIC-101 is connected to valve LV (Case 2).If raw water tank has high high level, LV is closed. There

2

will never be a situation in which two pumps turn off atthe same time because the water is always prepared to usefor emergency. At least: one pump needs to be operated.This example represents the case to search these unsafecontrol logics of SIS of all possible control logics in earlydesign stage.

The sequences of the normal operation of the systemare 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 facilitiesdo not exist below are not modeled because these can beomitted as a matter of analyzing control logics of thesystem. 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 inletflow from raw water pond is not low low pressure, twopumps are not operated without failure. The result for thespecification is not satisfied. A counter example trace isshown in figure 3. Two pumps are not operated simul-taneously when the level of raw water tank leads to highhigh. This control logic has an unsafe state, the system

Figure 2. The model description of Case A


needs to redesign.

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 o

This specification means there is no situation that inletflow from raw water pond is not low low pressure, one pumpis operated without failure, valve LV is closed, and the levelof raw water tank leads to high high. The answer for thisquery is not satisfied and the reasonable trace is shown infigure 3. This situation is less unsafe than Case A, but it isalso an error because the water cannot flow only through

f specification for Case A and Case B

3

Figure 4. The process diagram of a storage tank with SIF


V14. If emergency water or fire water is not used, the watercannot flow anywhere. Then, a safety valve next to valveV14 will pop up when the pressure in the pipeline is overset point of the safety valve. Reinstallation is needed. It isnecessary to modify this control logic of safety instrumentedsystem.

Control logical errors are automatically found bymodel checking method in the design of the SIS. Thiscase study illustrates that model checking becomes an auto-matic technique for the safety verification of the chemicalprocess design instead of manual safety analysis methods.If each process unit is modeled as a module, it becomes amore fast and effective method to verify and find thesafety errors of whole plant design.

CASE STUDY 2The subject of this case study is a Safety InstrumentedFunction (SIF) which protects a storage tank by measuringpressure, flow rate, temperature, and liquid level. Logicvoting is employed in the logic solver. The processdiagram for the process is shown in Figure 4. The faulttree model of Probability of Failure on Demand (PFD) forthis SIF process is shown in Figure 5. The process consistsof a storage tank, two level switches, two temperatureswitches, two pressure transmitters, three flow transmitters,and two block valves. The purpose of this case study is toevaluate reliability and SIL by correctly using FTA. Thecorrectness of reliability and SIL depends on the complete-ness of synthesis of the fault tree. It is important to verifyand find errors in a synthesized fault tree. We propose averifying method using model checking through this casestudy.

Model description of the process in UPPAAL is per-formed for normal operation and failure of each device. Incase of level switches, temperature switches, and pressuretransmitters, they are normally operated if at least onedevice out of two devices is operated. Block valves arealso operated with the same logic. In case of flow transmit-ter, they are normally operated if at least two out of threedevices are normally operated. The variables used in themodeling are Boolean logics, and they have these operating

4

control logics. Synchronization variables are used to clearstate transition delays. The state of each device hasBoolean variables (i.e. normal or fail) randomly. The stateof failure mode connecting both devices has also normalor fail according to operating control logics. In case offlow transmitters, the state for the number of devices operat-ing is added because three flow transmitters are connected.

Specifications for verification of fault tree based onFigure 5 are following;

Specification 1: There is no event that both pressure trans-mitter lead to fail except that two transmitters are failingat the same time.

A½� !(!(P1¼¼1 && P2¼¼1) && PTF¼¼1)

Specification 2: There is no event that both temperatureswitches lead to fail except that two switches are failing atthe same time.

A½� !(!(T1¼¼1 && T2¼¼1) && TSF¼¼1)

Specification 3: There is no event that both level switcheslead to fail except that two switches are failing at thesame time.

A½� !(!(L1¼¼1 && L2¼¼1) && LSF¼¼1)

Specification 4: There is no event that both valves lead tofail 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 transmitterlead to fail except that three transmitters are failing at thesame time.

A½� !(!(F1¼¼1 && F2¼¼1 && F3¼¼1) && FTF¼¼1)

The verifying results of the specifications 1, 2, 3, and4 are satisfied. The results show that the gates correspondingto each device failure mode in the fault tree based onFigure 5 have correct gate logics (AND or OR) and com-plete subevents. However, the specification 5 is not satisfied.The counter-example is shown in Figure 6. Based on thecounter-example, flow transmitters lead to failure when

Figure 5. A probability of failure on demand fault tree for the SIF

Figure 6. A counter-example of the specification 5


5

not only three transmitters failed at the same time, but alsowhen two transmitters fail simultaneously. It is necessaryfor the fault tree to be modified as shown in Figure 7.

The PFDavg data for the individual components usedin this case study are shown in Figures 5 and 7. The calcu-lated overall system PFDavg is 4.47�E-2 in case of the nonmodified fault tree, which falls into SIL 1 according toTable 10, 7.41�E-3 in case of the modified fault tree afterverification, which falls into SIL 2. The result illustratesthat it is possible for an incorrect fault tree to lead achange of SIL estimation.

CONCLUSIONThis study proposes a novel approach to verify the design ofSIS control logic for chemical engineering process usingmodel checking. Model checking is applied to automaticallyverify unsafe procedures of SIS control operation in the rawwater supplying system. Based on the results, we propose anovel approach to validate safe design of SIS instead ofcurrent safety assessment methods such as HAZOP. Weintroduce an automatic technique to provide and to modifythe P&ID design of SIS control logics in the chemicalprocess industry.

Another application represents that the model check-ing technique is useful when we are to validate the correct-ness of informal safety analysis such as FTA. It attempts to

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 systematicallyspecify the system model and to prove the correctness andcompleteness of FT. Automatic model checking techniquehelps a safety engineer better understand the context betterin which the specified failure mode occurs so that he/sheconduct a more precise safety analysis.

REFERENCESAlur., R. and Dill, D., 1994, A theory of timed automata, Theor-

etical Computer Science B 126: 183–235.

Behrmann, G., David, A. and Larsen, K.G., A Tutorial on

Uppaal, Available at http:// www.uppaal.com.

Center for Chemical Process Safety (CCPS), 2000, Guidelines

for chemical process quantitative risk analysis, 2nd 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.

6

ISA TR84.00.02-2002 – 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: 385–392.

Kim, J., Lee, Y. and Moon, I., 2006, Graphical modeling for the

safety verification of chemical processes, ESCAPE 16

meeting Jul. 9–13.

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. 12–17.

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: 67–75.

OREDA, 2002, Offshore reliability data handbook, 4th edition,

Hovik, Norway: Det Norske Veritas.