Model Checking for Automatic Verification of Control Logics in

Dec 13, 2010 - If no error is found, the user can refine the model description (e.g., by taking more design decisions into account so that the model b...
0 downloads 5 Views 4MB Size
Download PDF
Ind. Eng. Chem. Res. 2011, 50, 905–915

905

Model Checking for Automatic Verification of Control Logics in Chemical Processes Jinkyung Kim† and Il Moon*,‡ School of Chemical and Biomolecular Engineering, Georgia Institute of Technology, 311 Ferst DriVe, NW, Atlanta, Georgia 30332, United States, and Department of Chemical and Biomolecular Engineering, Yonsei UniVersity, 134 Shinchon-dong Seodaemun-ku, Seoul 120-749, Korea

This study focused on the automatic verification and validation of the safety and correctness of chemical process control logics. Discrete events, system behaviors, and control logic of chemical processes were formally modeled as automata. The symbolic model checking method was used to verify its safety and reliability. The strength of this method is synthesizing a feasible sequence through a counter-example and simultaneously verifying its correctness using computation tree logic (CTL). The model checking method was applied to determine the error-free design of the control operating sequence and automatically find the logical errors. An automatic technique is proposed to provide and modify the P&ID design of control logics for the chemical process industry. This Article addresses the model development of the control logics for industrial chemical processes and presents several case studies to show how a model checking approach can be used for the efficient verification of control logics. 1. Introduction The use of computer-aided techniques in chemical engineering has clearly increased in recent decades, and new fields for computer applications are still being explored. Computer-aided engineering has become able to handle more challenging chemical process systems due to its complexity and multiplicity. However, a major problem is that system complexity grows rapidly, which results in increased vulnerability to manual error. Safety aspects, error-finding, error-free operating network solving, and proving correctness can be very expensive, particularly if performed during system design, construction, and operation. As chemical processing systems are highly automated, verifying their safety is becoming more difficult, but it must be completed in the design steps. Most chemical processes contain both discrete control logics and continuous dynamics; these are connected with networks and operated synchronously. All of these must be verified at each stage of development, such as formal specification, design, implementation, construction, and maintenance. Changes in operating procedures make verification more difficult. When designing a chemical process and developing an error-free operation procedure for the process, verifying the safety and operability of the process automatically and efficiently is necessary. System verification, that is, the process of determining the correctness, is becoming an increasingly more important activity. System verification is a technique to support quality modeling and simulation of the system’s design. More specifically, this process establishes that a design fulfills its requirements. When it is common practice to perform verification clearly, model checking for faults at the very end of the design trajectory is unacceptable: a troublesome amount of effort would be needed to repair or modify an error found at this point. The whole design trajectory would need to be redone to see where and how the error arose. To verify the chemical process automatically, the signals and phenomena exhibited by the control logics, various process * To whom correspondence should be addressed. E-mail: ilmoon@ yonsei.ac.kr. † Georgia Institute of Technology. ‡ Yonsei University.

variables, operating procedures, operator behavior, and their networks have to be described in the modeling part. The model checking approach can be challenged and is appropriate for the graphical modeling and automatic verification of chemical processes, including nondeterministic variables, finite control logics, and real-time systems, because it uses automata, communications among channels, and shared variables. The model checker is based on the theory of automata, and its modeling language offers additional features such as bounded integer variables and urgency. The query language for the specific properties and operability to be checked is a subset of computation tree logic (CTL). One of the most important protective measurements in chemical industrial plants is the control logic of the safety instrumented system (SIS). It 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 altering the process to a safe state when predetermined conditions are violated. An SIS is commonly used on rare occasions such as emergency shutdown and shutdown systems. Therefore, an SIS must be available for operation whenever needed. If an SIS failure occurs, it is difficult to avoid accidents such as explosions, process damage, environmental damage, loss of cost, and loss of human life. An SIS must thus be verified and validated thoroughly and systematically in the design stage. An infeasible design for the SIS causes the process to shutdown or leads to abnormal situations. Most existing manual methods such as hazard and operability study (HAZOP), fault tree analysis (FTA), and failure mode and effect analysis (FMEA) are commonly used to identify the hazards, safety, and reliability of SIS in industrial fields. However, these manual methods usually consume a great deal of time and require manpower. The safety integrity level (SIL) is a standard for SIS design and is used to specify the safety integrity requirements of the safety instrumented functions to be allocated to the SIS. SIL offers information on the probability of failure on demand, but it cannot verify the safety and reliability of SIS control logics. Simulators are often used to analyze the behavior of control

10.1021/ie100007w  2011 American Chemical Society Published on Web 12/13/2010

906

Ind. Eng. Chem. Res., Vol. 50, No. 2, 2011

systems and process variables based on a determined model. Although examining the output of simulation is sometimes helpful, in practice, this method is not ideal for handling discrete events and behavior, which commonly comprise the SIS control logics. The model checking verification method is an alternative approach that has recently been used to achieve significant results. The main purpose of a model checker is to verify models with regard to requirement specifications. Efficient algorithms can verify properties of extremely large systems. In these techniques, specifications are written as formulas in a proposition temporal logic, and models are represented by binary decision diagrams (BDD). Verification is accomplished by efficient searching techniques that view the transition system as a model for the logic and determine if the model satisfies all the specifications. This approach includes several advantages. 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 automatically. The verification method was originally developed by Clarke et al.1 Moon et al.2,3 applied this verification method to the automatic verification of discrete chemical process control system (i.e., on-off switch, pump, relay, tank level, and switch). Moon4 also applied the method to verifying the safety and operability of PLC-based chemical processing systems. Probst5 suggested a method for decisive operating steps by using the valve toughness in a furnace system as an example. Probst et al.6 used symbolic model checking to formally verify safety and operability specifications on an industrial solids handling process. Turk7 presented a procedure for the construction of a discrete model that captures relevant dynamics and phenomena for safety verification. Kim et al.8 proposed a method for finding errors in operating schedules for batch processes. Kim and Moon9 proposed a new methodology of finding an error-free makespan of operating schedules in a multipurpose batch process. Yang et al.10 studied the verification of safety interlock system operability. Milam11 developed verification modules of diverse chemical processes. The verification tool UPPAAL, which was used in this study, was developed as a model checker to verify real-time systems (Petterssoon12). It has been applied successfully in case studies ranging from communication protocols to multimedia applications. Kristofferson13 studied an experimental batch plant by applying a model of automata and UPPAAL. Kim et al.14 proposed a graphical modeling for the safety verification of chemical process using UPPAAL. These studies dealt with the control logic of chemical industrial processes. In this study, we applied this approach to provide error-free design of control logics in chemical industrial processes. This method was tested for three examples to determine the error-free location of control logics and find the logical and infeasible errors automatically, which are difficult to find manually. The remainder of this Article is as follows. Section 2 briefly introduces the model checking verification. Section 3 explains the model description method for UPPAAL with automata theory. The CTL language used for the specifications is described in section 4. Section 5 shows two kinds of case studies for the automatic verification of the pressure regulating valve system and the raw water supplying systems by using the model checker UPPAAL. Section 6 presents the conclusions.

Figure 1. Verification methodology for model checking.

2. Model Checking for Verification 2.1. Model Checking Method. Model checking is an automated technique that, given a finite state model of a system and property stated in an appropriate logical formalism such as temporal logic, systematically checks the validity of this property (MaMillian15). Model checking is a general approach and has been applied in areas such as hardware verification and software engineering. Because of its success in several projects and the high degree of support from tools, there has been increasing interest from industry in model checking. The basic concept of model checking is to use algorithms executed by computer tools to verify the correctness of systems. The user inputs a description of a system model (all possible behaviors) and a description of requirement specifications (desirable behaviors) and leaves the verification up to the machine. If an error is identified, the model checker provides a counter-example showing under which circumstances the error can be generated. The counter-example consists of a scenario in which the model behaves in an undesired way. Thus, the counter-example provides evidence that the model is faulty and needs to be revised. This allows the user to locate the error and to repair the model specification before continuing. If no error is found, the user can refine the model description (e.g., by taking more design decisions into account so that the model becomes more concrete/realistic) and restart the verification process. The model checking algorithms are typically based on an exhaustive state space searching of the system model: for each state of the model, the algorithm checks whether the model behaves “correctly”, that is, whether the state satisfies the desired property. In its simplest form, this technique is known as reachability analysis. For example, to determine whether a system can reach a state where no further progress is possible (i.e., a deadlock), it is sufficient to determine all reachable states and whether a reachable state form exists in which no further progress can be made. Reachability analysis is only applicable to proving freedom from deadlock and proving invariant properties: that is, properties that hold during an entire computation. This is insufficient for communication protocols when a paramount concern arises, such as that once a message is sent, it is eventually being received. These types of “progress” properties are not usually covered by a reachability check. Model checking is the most successful approach that has emerged for verifying requirements. The essential idea and verification methodology for model checking is shown in Figure 1. A model-checking tool (UPPAAL in this study) accepts system requirements or a design (i.e., models) and a property (i.e., specification) that the final system is expected to satisfy. The tool then outputs yes if the given model satisfies the given specifications and generates a counter-example otherwise. The

Ind. Eng. Chem. Res., Vol. 50, No. 2, 2011

counter-example details why the model does not satisfy the specification. By studying the counter-example, we can pinpoint the source of the error in the model, correct the model, and try again. The idea is that by ensuring the model sufficiently satisfies system properties, we increase our confidence in the correctness of the model. There are basically two approaches to model checking that differ in desired behavior, that is, the requirement specifications: The first is the logic-based or heterogeneous approach. In this approach, the behavior of the desired system is captured by stating a set of properties for some appropriate logic, usually temporal or modal. The system is usually modeled as a finitestate automaton, where states represent the values of variables and control locations. Transitions that indicate how a system can change from one state to another are considered to be correct with respect to these requirements if they satisfy these properties for a given set of initial states. The second is the behavior-based or homogeneous approach. In this approach, both the desired and possible behavior are given in the same notation (e.g., an automation), and equivalence relations (or preorders) are used as a correctness criterion. The equivalence relations usually follow a notion that “behaves at least as”. Because there are different perspectives and intuitions concerning the meaning of two processes to “behave the same” (or “behave at least as”), various equivalence notions are defined. One of the most well-known notions of equivalence is bisimulation. In short, two automata are bisimilar if one automaton can simulate every step of the other automation and vice versa. A frequently encountered notion of preorder is (language) inclusion. Automaton A is included in automaton B if all words accepted by A are accepted by B. A system is considered to be correct if the desired and possible behaviors are equivalent (or ordered) with respect to the equivalence attribute under investigation. Although these two techniques are conceptually different, connections between the two approaches can be established as follows. A particular logic induces an equivalence relation on systems as follows: two systems are equivalent if (and only if) they satisfy the same formulas. Relationships between different logics and equivalence relations have been established by using this concept. For instance, two similar models may be known to satisfy the same formulas of the logic CTL, which is commonly used for model checking purposes. The connection between the two different approaches is clear: if the two models process the same properties (checked using the logic approach), then they are behaviorally equivalent (as they can be checked by the behavioral approach). The reverse direction is more interesting, because it is generally infeasible to check all properties of certain logic; however, checking for equivalences such as a bisimulation can be done more efficiently (time is logarithmic for the number of states and linear for the number of transitions). 2.2. Benefits of Model Checking. The general approach can be applied to hardware verification, software engineering, multiagent systems, communication protocols, embedded systems, chemical engineering, bioinformatics, etc. Model checking supports partial verification. A design can be verified against a partial specification by considering only a subset of all requirements. This can result in improved efficiency because the validation can be restricted to check only the most relevant requirements while ignoring the less important although computationally expensive requirements. Case studies have shown that incorporating model checking in the design process does not delay this process more than

907

using simulation and testing. For several case studies, the use of model checking has led to shorter development times. In addition, due to several advanced techniques, model checkers are able to deal with rather larger state spaces (e.g., a case study using 10130 states has been reported in the literature). Model checkers potentially have to be routinely used by system designers with as much ease as using compilers; this is basically because model checking does not involve a high degree of interaction with the user. It also supports sound and interesting mathematical foundations. Modeling, semantics, concurrency theory, logic and automata theory, data structures, graph algorithms, etc., constitute the basis of model checking. 2.3. Limitations of Model Checking. The main limitations of model checking are: It is appropriate mainly for control-intensive applications with communication between components. It is less suited to dataintensive applications because the treatment of data usually introduces infinite state spaces. Applicability of model checking is subject to decidability issues. For particular cases, most classes of infinite-state systems, model checking is not effectively computable. However, formal verification is in principle applicable to such systems. Using model checking, a model of the system is verified rather than the real system itself. The fact that a model possesses certain properties does not guarantee that the final realization possesses the same properties. Therefore, complementary techniques, such as systematic testing, are needed. Only stated requirements are checked. There is no guarantee of the completeness of desired properties. Finding appropriate abstraction (such as the system model and appropriate properties in temporal logic) requires some expertise. We believe that absolute correctness can never be achieved for systems of realistic size. Despite the above limitations, we believe that model checking can provide a significant increase in the level of confidence of a system. Because it is quite common to model the possible behavior of the system as (finitestate) automata during this process, model checking is inherently vulnerable to a rather practical problem that the number of states may exceed the amount of computer memory available. This is particularly a problem for parallel and distributed systems with many possible system states: the size of the state space of such systems is in the worst case proportional to the product of the size of the state spaces of their individual components. The problem that the number of states can become too large is known as the state-space explosion problem. Several effective methods have been developed to combat this problem. 3. Model Description for Safety Verification To verify a given process and SIS control logic, their respective models are developed from the process and SIS control logic descriptions. Completeness and correctness of the model is the key issue in verifying the SIS control logics. The model description is a nondeterministic guarded command language with simple data (e.g., bounded integers, arrays). Like SIS in chemical processes, control-oriented systems occur in a wide variety of safety problems during the design stage. For control-oriented systems, finite state machines are widely accepted as a good, clean, and abstract notion for defining requirements and design. To model the systems, the following is also needed: ability to modularize the requirements to view them at different levels of detail, method to combine requirements or design of components, and ability to state variables

908

Ind. Eng. Chem. Res., Vol. 50, No. 2, 2011

Figure 2. Automata modeling in UPPAAL (Behrmann et al.17).

Figure 3. Examples of computation trees satisfying five common CTL formulas.

and facilities (e.g., valve or pump) to update them for use in guards on transitions. The model checking tool (UPPAAL) has its own rigorous formal language for design models. UPPAAL serves as a modeling or design language to describe the process behavior (e.g., valve, pump, motor) as networks of automata and SIS control process logics in chemical industrial processes. The idea is to model a process using automata and simulate it. Figure 2 shows a method for automata modeling in UPPAAL. Automata are finite state machines, that is, a graph containing finite sets of locations and labeled edges. A system consists of a network of processes that are composed of locations (Alur and Dill16). The system is modeled as a network of several such

Figure 4. Pressure-regulating valve system with pressure indicator.

automata in parallel. The model is further extended with bounded discrete variables that are part of the state. A state in the system is defined by the locations of all automata and the values of the discrete variables. Each location may fire and edge separately or synchronize with another state, which leads to a new location. Location includes three kinds of location types: first, an initial location that presents the beginning of the process; each process must have exactly one initial location; second, urgent locations that force the actual process to always make a transition without any delay; and finally, committed locations so that if any process is in a committed location, the next transition must involve an edge from one of the committed locations. Transitions are used to change location, and transitions between these locations define how the system behaves. To control where the transition goes, it is possible to have a guard and synchronization. Synchronization means that two processes change location in one simulation step. Synchronization is done with (or via) channels. To synchronize two processes, the synchronization is labeled with a channel variable that has been declared previously followed by “!” or “?” The guard and invariant express conditions at the edge on the value of the integer variable that must be satisfied for the transition to take place. It is side-effect free, type correct, and evaluates to Boolean. Only integer variables and constants are referenced (or arrays of such). When executed, the update expression of the edge is evaluated. Side effects for this expression change the state of the system. The simulation of the constructed model is a validation that enables the examination of possible dynamic executions of a system during the early design stage; thus, it provides an inexpensive means of fault detection prior to verification by a model checker to cover the exhaustive dynamic behavior of the system. A graphical simulation provides graphical visualization and recording of the possible dynamic and discrete behaviors of a description model for SIS control logic, that is, sequence of the symbolic statement for the control logic. It is also used to visualize traces generated by the model checker. 4. CTL for Specification Language The model checker is to check invariant and bounded-lively properties by exploring the state space of a system, that is, safety and reachability analysis in terms of symbolic states represented by constraints. Similar to the model, the requirement specifications must be expressed in a formally well-defined and machine-

Ind. Eng. Chem. Res., Vol. 50, No. 2, 2011

909

Figure 5. Model descriptions for PI101.

readable language. Several such logics exist in the scientific literature, and this study used a simplified version of computation tree logic (CTL). Similar to CTL, the query language consists of path and state formulas. The state formula describes individual statements, while the path formula quantifies paths or traces of the model. The path formula can be classified in terms of reachability, safety, and reliability. Figure 3 illustrates the different path formulas supported by UPPAAL. Each type is described below. E 〈〉 φ: A path exists where φ eventually holds. A [] φ: φ always holds for all paths. E [] φ: A path exists where φ always holds. A 〈〉 φ: φ eventually holds for all paths. Ψ f φ: φ eventually holds whenever Ψ holds.

4.1. Reachability. Reachability properties are the simplest form of properties. A specification asks whether it is possible for a given state formula φ to be satisfied by any reachable state. In other words, is there an existing path starting at the initial state such that φ is eventually satisfied along that path. Reachability properties are often used while designing a model to perform sanity checks. These properties do not by themselves guarantee the correctness of the model, but they verify the basic behavior and condition of the model. We express that some states satisfying φ should be reachable using the path formula E 〈〉 φ in UPPAAL. 4.2. Safety. Safety properties have the form: “something bad will never happen”. In UPPAAL, these properties are formulated positively; that is, something good is invariantly true. Let φ be

910

Ind. Eng. Chem. Res., Vol. 50, No. 2, 2011

Figure 6. Model descriptions for PI102.

4.3. Liveness. Liveness properties have the form: “something will eventually happen”. For example, if the on button of the remote control for the television is pressed, then the television should eventually turn on. In its simple form, liveness is expressed with the path formula A 〈〉 φ, meaning that φ is eventually satisfied. The more useful form is the leads to or response property, which is written as φ f Ψ and read as Ψ is eventually satisfied whenever φ is satisfied.

Figure 7. Counter-example trace of specification for PI101.

a state formula. We express that φ should be true in all reachable states with the path formula A [] φ, whereas E [] φ says that there should be a maximal path such that φ is always true.

This Article presents the safety specifications of the SIS control system in chemical industrial processes. In contrast to normal control logic, SIS controls abnormal situations such as emergencies, control failure, abnormal signals, and incorrect control logic programs. The safe state of SIS control logic must be verified as part of the specification because all possible states are constructed in the part of model description. This study specified the verification for the right location of the controller, reliability of the SIS control logics, and safe SIS control

Ind. Eng. Chem. Res., Vol. 50, No. 2, 2011

911

Figure 8. Raw water supplying system in HOU (heavy oil upgrading) plant.

operation procedures and logics. Several case studies on chemical processes were used to address the automatic and systematic verification of the SIS control logic. 5. Case Studies 5.1. Pressure-Regulating Valve. Figure 4 illustrates a pressure-regulating valve system with pressure indicators in an LPG pipe line. The purpose of this case study was to present a suitable location problem of pressure indicators as a safety interlock control system. The process consists of two inlet gas flows and one outlet gas flow. The pressure of one inlet flow indicates 20 kg/cm2 · G, while the other shows 12 kg/cm2 · G. The pressure of the two inlet flows can be oscillated, and the pressure of the outlet flow can also be oscillated by the inlet flow. The normal pressure of the outlet is 12 kg/cm2 · G. The pressure oscillation of the 12 kg/cm2 · G inlet flow can be ignored because it has little effect on the pressure of outlet flow due to being the same pressure. The 20 kg/cm2 · G inlet flow is controlled to a pressure of 12 kg/cm2 · G using one pressure regulating valve (PV). A pressure translator and indicator are located on alternative lines for the outlet flow (PT1 and PI101) and 20 kg/cm2 · G inlet flow (PT2 and PI102). The integer variables for modeling this process are as follows: int[0,1] inlet01_normal(12 kg/cm2 G) (0, abnormal; and 1, normal); int[0,2] inlet02_normal(20 kg/cm2 G) (0, abnormal; 1, normal; and 2, normalizing); int[0,1] outlet_normal (0, abnormal; and 1, normal); int[0,1] PI101_on (0, off; and 1, on); int[0,1] PI102_on (0, off; and 1, on). We chose an available location for alternative pressure indicators using model checking verification. Figures 5 and 6 show the model descriptions of PI101 and PI102, respectively. States inlet01 and inlet02 can be randomly transitioned from the initial state to normal or abnormal, from normal to abnormal, and from abnormal to normal. The state of the outlet is normal if inlet01 and inlet02 are normal and abnormal if either or both

inlet01 and inlet02 are abnormal. The initial states of PI101 and PI102 are off. PI101 turns on only if the outlet becomes abnormal and stays on until the outlet comes back to the normal state, whereas PI102 turns on only if inlet02 becomes abnormal and stays on until inlet02 comes back to the normal state. After PI101 or PI102 turn on, the state of inlet02 transitions to normalizing and becomes normal if PI101 or PI102 turn off. The verification specifications are as follows: A[] !(inlet02_ normal))1 && PI101_on))1), PI101 case; and A[] !(inlet02_normal))1 && PI102_on))1), PI102 case. These specifications show that there is no situation where inlet02 is controlled normally through the pressure-regulating valve, even though inlet02 has a normal flow due to the outlet’s abnormal state. The specification results do not satisfy the PI101 case but satisfy the PI102 case. On the basis of these results, we verified that PI102 is an available location for the pressure indicator. Figure 7 shows a trace as to why PI101 was not satisfied. 5.2. Raw Water Supplying System in HOU (Heavy Oil Upgrading) Plant. Raw water supply systems are an ubiquitous process in chemical industrial plants. Figure 8 shows part of a P&ID (piping and instrumentation diagram) for the utility process design of an HOU project in a petrochemical plant. Raw water from a river is stored in a raw water pond. The water flows to the 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 through valve 22, for the clarifier feed through valve 23, and for firefighting or emergency showers through valve 14. Valve 14 is directly connected to the bypass pipeline between the pump and raw water tank. Valve 14 is always open because it is used for emergency situations. The system has two pumps, one for normal operations and another as a standby. If one pump is out of order, the other pump starts operating instantly. These pumps receive signals from indicator I-100. I-100 is controlled by pressure controller PI-101 or level

912

Ind. Eng. Chem. Res., Vol. 50, No. 2, 2011

Figure 9. Model descriptions of Case 1.

controller LIC-101. PI-101 receives a signal from pressure translator PT1 and monitors the pressure of flow from the raw water pond to the pump. If PI-101 indicates very low pressure, the pump turns off automatically; otherwise, the pump operates normally. If I-100 is connected to LIC-101 (Case 1), I-100 receives a signal from LIC-101 when the level of the raw water tank is very high, and the pump turns off with this signal. Another case is that LIC-101 is connected to valve LV (Case 2). If the raw water tank has a very high level, LV is closed. There is no situation where the two pumps turn off at the same time because the water is always prepared to use for emergency. One pump always needs to be operated at least. This example represents a case of searching unsafe control logics out of all possible for a safety instrumented system in an early design stage. The normal operation sequence of the system is as follows: (1) The water flows from raw water pond when valve V1 is open. (2) If the pressure is not very low, one of the two pumps turns on. (3) If pump1 turns on, valve V5 is opened; and if pump2 turns on, valve V10 is opened. (4) If valve V5 or V10 is opened, valve LV is opened. (5) The water flows into raw water tank if valve LV is opened. (6) Valve 14 is always open to prepare for emergencies. (7) The water flows into the process through valve V22 or V23.

The model description consists of 10 modules. Units or facilities that do not exist below are not modeled because these can be omitted when analyzing the control logics of the system. The 10 modules are as follows: flow from the raw water pond module, PI-101 module (pressure indicator module), I-100 module (pump controller), dual pumps module, five valves module (V1, V5, V10, V14, and LV), and level of raw water tank module. Integer variables for modeling this process are as follows: int[0,1] v1 (0, close; and 1, open); int[0,2] flow (0, initial; 1, normal; and 2, low low pressure); int[0,1] PI101(0, low low; and 1, normal); int[0,1] Pump1, Pump2 (0, off; and 1, on); int[0,1] Pump1_fail, Pump2_fail (0, normal; and 1, fail); int[0,1] V5, V10, Lv (0, close; and 1, open); int[0,1] V14:)1 (0, close; and 1, open), V14 always open; int[0,1] Level (0, normal; and 1, high high level). Normal, Lowlowpres, Pump, and PumpStop are used as synchronization variables. Figures 9 and 10 illustrate model descriptions of Cases 1 and 2, respectively. I-100 and LV are the only factors changed in Case 2. The verification specifications are as follows. Case 1: A[] !(PI101))1 && Pump1))0 && Pump2))0 && Lv))1 && (!(Pump1_fail))1) && !(Pump2_fail))1))). This specification shows that there is no situation where the inlet flow from the raw water pond is not at a very low pressure and the two pumps are not operating without failure. The result for the specification is not satisfied. A counter-example trace is

Ind. Eng. Chem. Res., Vol. 50, No. 2, 2011

913

Figure 10. Model descriptions of I-100 and LV in Case 2.

Figure 11. Counter-example trace of specification for Case 1.

shown in Figure 11. The two pumps are not operated simultaneously when the level of the raw water tank is very high. Because this control logic has an unsafe state, the system needs to be redesigned. Case 2: A[] !(PI101))1 && (Pump1))1 or Pump2))1) && Level))1 && Lv))0 && (!(Pump1_fail))1) && !(Pump2_fail))1))). This specification means there is no situation where the inlet flow from raw water pond does not have very low pressure, one pump is operated without failure, valve LV is closed, and the level of the raw water tank is very high. The answer for this query is not satisfied, and the reasonable trace is shown in Figure 12. This situation is less unsafe than Case 1, but it is

also an error because the water cannot flow only through V14. If emergency or firefighting water is not used, the water cannot flow anywhere. Thus, a safety valve next to valve V14 will pop up when the pressure in the pipeline is over a set point for the safety valve. Reinstallation is needed. It is necessary to modify the control logic for the safety instrumented system. Control logical errors are automatically found by the model checking method in SIS design. This case study illustrates that model checking becomes an automatic technique for the safety verification of the chemical process design in contrast to manual safety analysis methods. If each process unit is modeled as a module, it becomes a faster and more effective method to verify and find the safety errors of the entire plant design.

914

Ind. Eng. Chem. Res., Vol. 50, No. 2, 2011

Figure 12. Counter-example trace of specification for Case 2.

6. Conclusions In this study, we concentrated on a verification technique that is known as model checking. Model checking is an automated technique that, given a finite-state model of a system and a property stated in some appropriate logical formalism such as temporal logic, systematically checks the validity of this property. Model checking is a challenging approach in chemical process engineering. Because of its success in several hardware and software engineering applications, there has been growing interest in this technique in the chemical process industry. No one can achieve absolute guaranteed correctness for systems of realistic size. Despite its limitations, however, model checking can provide a significant increase in the level of confidence of a system. Various applications using model checking method are illustrated in this study. The presented case studies show that model checking can be a challenging but suitable approach in the process systems engineering field. Model checking is completely automatic and fast. Model checking can be applied to partial designs and so can provide useful information about a system’s correctness even if the system is not completely specified. Model checkers are rather user-friendly to use. Model checking is more applicable to control-intensive applications (such as process control system, reactive system, programmable logics, and operating sequence with discrete parameters). Model checking can generate counter-examples, which can be used to aid debugging.

Using model checking, a system design is checked for a fixed (and finite) set of parameters. This study represents a novel approach to verifying the design of control logics for chemical engineering process through case studies. Logical error-free locations of a pressure transmitter for the regulating valve were found, and two unsafe procedures for SIS control operations in the raw water supplying system were verified automatically. On the basis of the results, we propose a novel approach to validate the safe design of SIS instead of current safety assessment methods such as HAZOP. We introduce an automatic technique to provide and modify the P&ID design of control logics in the chemical process industry. Literature Cited (1) Clarke, E. M.; Emerson, A.; Sistla, K. L. Automatic Verification of Finite-State Cocurrent Systems Using Temporal Logic Specifications. ACM Trans. Programming Languages Syst. 1986, 8, 244–263. (2) Moon, I.; Powers, G. J.; Burch, J. R.; Clarke, E. M. Automatic Verification of Sequential Control Systems Using Temporal Logic. AIChE J. 1992, 38, 67–75. (3) Moon, I.; Ko, D.; Probst, S. T.; Powers, G. J. A Symbolic Model Verifier for Safe Chemical Process Control Systems. J. Chem. Eng. Jpn. 1997, 30, 13–23. (4) Moon, I. Modeling PLCs for Logic Verification. IEEE Control Syst. 1994, 14, 53–59. (5) Probst, S. T. Chemical Process Safety and Operability Analysis using Symbolic Model Checking. Ph.D. Thesis, Carnegie Mellon University, 1996. (6) Probst, S. T.; Powers, G. J.; Long, D. E.; Moon, I. Verification of Logically Controlled, Solids Transport System Using Symbolic Model Checking. Comput. Chem. Eng. 1997, 21, 417–429.

Ind. Eng. Chem. Res., Vol. 50, No. 2, 2011 (7) Turk, A. L. Event Modeling and Verification of Chemical Processes Using Symbolic Model Checking. Ph.D. Thesis, Carnegie Mellon University, 1999. (8) Kim, J.; Kim, M.; Moon, I. Improved Search Algorithm for the Efficient Verification of Chemical Processes. Comput. Chem. Eng. 1999, 23, S601–604. (9) Kim, J.; Moon, I. Synthesis of Safe Operation Procedure for Multipurpose Bath Processes Using SMV. Comput. Chem. Eng. 2000, 24, 385– 392. (10) Yang, S. H.; Tan, L. S.; He, C. H. Automatic Verification of Safety Interlock Systems for Industrial Processes. J. Loss PreV. Process Ind. 2001, 14, 379–386. (11) Milam, D. E. Synthesizing Modular Logic Models of Chemical Engineering Process Equipment and Control Systems for Verification. Ph.D. Thesis, Carnegie Mellon University, 2003. (12) Petterssoon, P. Modelling and Verification of Real-Time Systems. Ph.D. Thesis, Uppsala University, 1999.

915

(13) Kristofferson, K. J. Compositional Verification of Concurrent Systems. Ph.D. thesis, Aalborg University, 1998. (14) Kim, J.; Lee, Y.; Moon, I. Graphical Modeling for the Safety Verification of Chemical Processes. ESCAPE 16 Meeting, July 9-13, 2006. (15) McMillan, K. Symbolic Model Checking; Kluwer Academic Publishers: Norwell, MA, 1993. (16) Alur, R.; Dill, D. A Theory of Timed Automata. Theor. Comput. Sci. B 1994, 126, 183–235. (17) Behrmann, G.; David, A.; Larsen, K. G. A Tutorial on Uppaal. Available at http://www.uppaal.com.

ReceiVed for reView January 2, 2010 ReVised manuscript receiVed November 20, 2010 Accepted November 24, 2010 IE100007W