Compuers Chem. Engng Vol.22, No.9, pp. 1385~1355, 1998 ‘Copytight © 1998 Elsevier Science Lid AU rights reserved. Printed in Great Betain ‘con8-1384)98 $19.00 + 000 PII: $0098-1354(98)00018-0 Automating HAZOP analysis of batch chemical plant: Part I. The knowledge representation framework Rajagopalan Srinivasan and Venkat Venkatasubramanian* Laboratory for Intelligent Process Systems, School of Chemical Engineering, Purdue University, ‘West Lafayette, IN 47907, USA (Received 17 December 1997) Abstract Hazard and operability (HAZOP) analysis is a systematic procedure for determining the abnormal causes of process deviations from normal behavior and their adverse consequences in a chemical plant. This isa dificult, labor-intensive, time-consuming activity that would benefit from automation, While HAZOP analysis is generally applied only to continuous process plants, it can be generalized to include batch process systems as well, as shown in this paper. The main thrust of this paper, however, is to develop a general framework for automating the HAZOP analysis of batch plants, The proposed framework combines high-level Petri nets and digraphs with object-oriented knowledge representation for the development ofa general, flexible, efficient, and user-friendly system, called Batch HAZOPExpert , implemented in G2. In this framework, the knowledge about tasks and sub-tasks in a batch process are modeled hierarchically using high-level Petri nets. Cause and effect relationships between process variables within a subtask are represented using subtask digraphs. Petri nets and subtask digraphs interact with each other in a two-tier organization to model the behavior of batch processes. ‘One of the novel features of this framework is that both the continuous and discrete nature of batch operation are represented explicitly. Another feature is the modeling of operator actions and errors, since they play a more Crucial role in batch process systems than in continuous ones. The first part of this paper describes the details of the intelligent systems framework. The second part discusses the application of the Batch HAZOPExpert system to an industrial case study. ©) 1998 Elsevier Science Ltd. All rights reserved Keywords: process safety; artificial intelligence; process hazard analysis; object oriented; Petri nets 1 Introduction 1997. By one estimate, this requires the PHA of about 25,000 plant sites to be completed in the United States Process hazard analysis (PHA) is the systematic at an estimated cost of about two billion dollars identification and mitigation of potential hazards which could endanger the health and safety of humans and cause serious economic losses. This is an impor- tant activity in process safety management (PSM) that requires a significant amount of time, effort, and spe- Cialized expertise. The importance of this activity is underscored by the Occupational Safety and Health ‘Administration's (OSHA) process safety management (PSM) standard Title 29 CFR 1910.119 which re- quires initial PHAs of all the processes covered by the standard to be completed by no later than 26 May “Author to whom correspondence should be adddressed. (Vaidhyanathan and Venkatasubramanian, 1996a). While a number of methods are available for perform- ing PHAs, HAZOP is the most widely used and recognized as a preferred PHA approach by the chem- ical process industry. Hazard and operability (HAZOP) analysis is a sys- tematic procedure for determining the abnormal causes of process deviations from normal behavior and their adverse consequences in a chemical plant from a process safety perspective. It can also identify operability problems which prevent efficient plant op- eration. It is performed by a multi-disciplinary team of experts, equipped with a complete description of the process and its operation, who systematically examine every part of the plant P&ID to determine 13451346 how deviations from the intent of the design of the plant can occur and cause hazards. They systemati- cally apply a set of guide words such as NONE, MORE OF, LESS OF, PART OF, etc, to key process variables to generate all conceivable deviation, and evaluate all the hazards associated with such devi- ations. Detailed description of the HAZOP technique with examples of its applications have been given by Lawley (1974, 1976), Kletz (1986), Knowiton (1989), and Venkatasubramanian and Vaidhyanathan (1994, 1996a). Since HAZOP analysis is laborious and time con- suming, there exists considerable incentive to auto- ‘mate this activity. An automated system can reduce the time, effort, and expense involved, make the analy- sis more thorough and detailed, and minimize or eliminate human errors. Recently, Vaidhyanathan and Venkatasubramanian (19952; 1995b; 1996b; 1996a) proposed a HAZOP-digraph model-based framework for automating the HAZOP analysis of continuous plants in steady state operation. The di- graph models represent the balance and confluence equations for the process units in a qualitative form, thus modeling the cause-and-effect relationships be- ‘tween the process state variables. These relationships remain the same in continuous plants operating under steady-state conditions. However, this approach can- not be used to automate the HAZOP analysis of ‘batch processes as the issues involved are significantly diferent from those of continuous plants. For example, the operation of a continuous plant can usually be inferred from its Piping and Instrumenta- tion Diagram (P&ID), This is because, during the steady-state operation of a continuous plant, a fixed operation is performed in each equipment. Therefore, every unit performs a specialized task. However, for a batch plant, the operating strategies play an impor- tant role. In batch operations, multiple tasks may be performed in each equipment. For example, a glass- lined still may be used to heat or cool the reactants, carry out a reaction, and distill the products. Know- ledge of the plant P&ID alone is not sufficient to indicate such plant operation. The operating proced- ure of the plant is, therefore, necessary to perform HAZOP analysis of batch plants. The existing methods for performing HAZOP analysis have no framework for representing the operating procedure or the operator actions and mistakes. Hence, they cannot be applied directly to batch processes. In addition, operations associated with production are performed in a sequence of steps called subtasks. Discontinuities occur due to the start and stop of these individual processing steps. In addition, the rela- tionships between the process variables may differ in different subtasks. As the plant evolves over time, different tasks are performed and the interrelation- ships between the process variables change. A digraph ‘model cannot by itself represent these dynamic cha- nges and discontinuities (Srinivasan and Venkatasub- ramanian, 1995). Hence, the digraph-based approach R. SRINIVASAN and V. VENKATASUBRAMANIAN alone cannot represent the operation of batch and semi-continuous plants, or the unsteady-state opera- tion of continuous plants. ‘This work addresses these important problems that lie in the generalization of the HAZOP analysis to batch process plants, and its automation. Since batch plants resemble discrete event systems (DES) in many respects, some of the concepts and techniques used in the modeling of DES are used in our framework. DES are characterized by discrete states and events. The events cause transition between the states. Batch pro- cessing can be modeled in a similar manner. Petri nets have often been used to model DES. One advantage of using Petri nets is that both the processing steps and the state of the system can be represented explicit- ly. In this work, we therefore use high-level Petri nets to represent the discontinuous nature of batch opera- tions. However, this alone is not sufficient for our Purposes as causal relationships between the process variables are required to perform HAZOP analysis. Such relationships can be modeled using digraphs. We therefore integrate high-level Petri nets and di- graphs in our framework to generalize the HAZOP analysis approach for batch plants, and facilitate its automation. This research contribution is presented in two parts, Part I introduces the overall framework while Part II illustrates its application on an indus- trial case study. 2. A hierarchical task-based language for modeling batch operation The central problems to be solved in the automa- tion of HAZOP analysis for batch process plants are: (i) generalizing the continuous process HAZOP meth- odology for batch processes, and (ii) developing an overall Knowledge representation framework that would facilitate the organization and representation of diverse types of knowledge such as product recipes, tasks, and subtasks. The hierarchical task-based lan- guage is introduced in this section with the help of an industrial case study. Consider Fig. 1 which shows a section of a batch plant (Eli Lilly 1994), The actual details of this case study such as the chemicals, reac- tions, and operating conditions are not presented in this paper due to the confidentiality issues involved. The production of Chemical A is the primary goal of this section. The major steps in the operation are: Chemical C and Chemical D are filtered to the STILL. A solution of Chemical B in water is added, ‘Chemical M is also added. The mixture is stirred with ‘maximum agitation at 35°C for 2b, then cooled to 25°C and the agitation stopped to allow the solids to settle. The supernatant liquid is decanted to TANK for further processing. A task-based language can be used for representing, such batch operation (Reklaitis, 1991). The sequence of processing steps or tasks to be carried out to make the product is generally called the product recipe. The product recipe describes the process itself and not‘The knowledge representation framework Fig. 1. A section of a batch plant. Table 1. Produet recipe for plant React in STILL React in TANK Filter products Table 2, List of subtasks for STILL Subtask Name Description Prepare Prepare STILL for operation Fill-l Charge Vessel with 1000 gal, C.D Solution Fill-2 Charge 300 gal B Fill3 Charge 250 1b M React Maintain T at 35°C for 2h Cool Cool Vessel contents to 25°C Empty Dump contents to TANK Clean Clean STILL a specific plant. Table 1 shows the product recipe for this case study. The entire operation to be performed in the STILL has been summarized as “React in STILL" in the product recipe. Each task in a recipe can be divided into a sequence of elementary steps or subtasks which can be directly performed by the plant operator. In the plant in Fig. 1, the first subtask the operator performs is to charge the C-D solution into the STILL. Table 2 gives the list of subtasks (ic. a task) for STILL. It describes in some detail the entire operation to be performed in STILL. Opera- tions in a unit begin with the execution of the first subtask. After the completion of the first subtask, the second subtask is started and so forth until the last 1347 subtask is finished. The equipment then becomes available for processing another task again. Often special subtasks, not directly related to the product recipe, are carried out in each unit. These are for preparing the equipment prior to operation and for cleaning the equipment at the end of the task. Each subtask has a well-defined beginning and end. The end of a subtask is signaled by the subtask termi- nation logic. The subtask termination logic is either a state event or a time event. A state event occurs when a state variable reaches a particular value. For example, the “Cool” subtask in STILL ends when temperature reaches 25°C. Here the subtask termina- tion logic is a state event. When the duration of a subtask is fixed a prior, its end is flagged by a time event, A time event causes a discontinuity in process- ing whose time of occurrence is known a priori. For example, the “React” subtask in STILL is carried out for 2h. So, the termination logic is a time event. The task-based language represents the discontinu- ous nature of batch operation in a hierarchical man- ner, However, it cannot describe the continuous change that occurs during each subtask. On the other hand, the methods used for modeling continuous op- erations cannot account for the discontinuities in batch operation even when an additional dimension of time is introduced. As a result, researchers have looked at several techniques for the modeling and analysis of batch systems (Yamalidou et al. 1990). Petri nets have proved to be a comprehensive tool for modeling discrete event systems (Yamalidou and Kantor, 1991) and can be used to represent the task- ‘based language described above. HAZOP analysis also requires the causal model of, the process in order to obtain the causes and conse- quences of a process variable deviation. For example, a high temperature deviation can occur during the “React” subtask in STILL. This could be due to a low coolant flow rate. As a consequence, a runaway reac- tion could occur leading to a fire hazard. To obtain such causes and consequences, the continuous change in each subtask has to be captured. This, we propose to handle using digraphs as developed by Vaid- hyanathan and Venkatasubramanian (1995a). Thus, we propose a new framework that integrates Petri nets and digraphs to provide a powerful representa~ tion for the cause-and-consequence analysis of batch processes which can be automated. 3. Petri nets Petri nets originate from the work of Carl Adam Petri who defined a general purpose mathematical tool for describing the relations that exist between conditions and events. Since then, they have been used for modeling dynamic systems in diverse areas (Peter- son, 1981) The Petri net is a language “ .. for the description, in a uniform and exact manner ... of phenomena related to... information transformation” (Petri,1348 1962). A classical Petri net is composed of four parts: a set of places P, a set of transitions T, an input function J, and an output function 0. A graphical representation of Petri nets is often used as a tool for visual communication similar to flow charts and block diagrams. ‘A Petri net graph is a representation of a Petri net structure as a graph. Corresponding to the places and transitions, a Petri net graph has two types of nodes. A circle represents a place and a rectangle represents a transition in the Petri net graph.* Directed arcs between the nodes represent the input and output functions. Each arc is directed from an element of one set of nodes (place or transition) to an element of the other set (transition or place) making the graph bipar- tite. Also, since multiple ares are allowed from one node of the graph to another, the Petri net graph is also a multigraph. Associated with each place P, in the Petri net is 1 non-negative integer m, of tokens or marks, The execution of a Petri net is controlled by the number and distribution of tokens in the Petri net. Graphi- cally, tokens are represented as dots inside the corres- ponding place. A Petri net executes by firing transitions. A transition is said to be enabled ifeach of its input places contains at least one token. Only an enabled transition can fire. Firing of a transition con- sists of removing one token from each of its input places and adding a token to cach of the output places. In classical Petri nets, an enabled transition fires immediately and this whole process occurs in- stantaneously — tokens appear in the output places the instant the transition fires. The state of a Petri net is described by its net markings. For a Petri net with » places its net marking is an r-vector, M. The vector M gives for each place Pina Petri net the number of tokens mi in that place. im) w M=(m, m2, 3.1. Modeling batch plant operation by classical Petri nets Batch operations can be described by Petri nets. In Petri nets, places represent the state of the system. ‘Then, the evolution of the system corresponds to the evolution of the markings on the Petri net. Figure 2 shows a tank and pump system, Continuous-mode operation of this system can be modeled by h G7 Fin Foes @ Fa = CfOP), 8 Fou = Kath, x), 4) where his the liquid level in the tank, F, the flow rate ofthe liquid entering the tank, F.. the flow rate of the **A transition is sometimes represented by a bar in literature. R. SRINIVASAN and V. VENKATASUBRAMANIAN Psa. Fig. 2. Tank filling operation. oD Fig. 3. Petri net model for the system in Fig, 2. liquid leaving the tank, AP the pressure drop across the pump and x the valve stem position. C and K are constants for a given pump and valve. The character- istics of the pump and valve are modeled by the f and @ functions. Equations (2)-(4) indicate the causal relationships between h, Fin Fou P, and x, However, the operation of this system in a batch mode would be modeled by actions or production rules such as ‘+ When the tank is empty, switch the pump on. ¢ When the tank is full, stop the pump. « Ifthe outlet valve is closed and there is liquid in the tank, then open the valve. «¢ Ifthe valve is open and there is no liquid in the tank, then close the valve. Petri nets can be used to model such operations. Figure 3 shows a simplified Petri net model of the‘The knowledge representation framework system described in Fig, 2. Each place in the Petri net describes a state of the system. For example, , represents the state “Pump is on”. Each transition represents an operation performed on the system. For example, T; represents the action of switching the pump off, Tokens are represented by dots. A dot inside a place indicates that a token is in that place. Different semantics can be attributed to a token oceu- ying a place. In this Petri net model, a token occupy- ing a place indicates that the state represented by the place is the current state of the system. For example, the token in P; in Fig. 3 indicates that at this stage of operation the state of the pump is off. A place can be in general occupied by more than one token. How- ever, such a situation would not occur in the Petri net in Fig. 3. Hence, no semantics need be associated to multiple tokens occupying a place in this Petri net example. ‘The initial marking of the Petri net is Mo = (P, Pz = 1, P= 1, Py Ps =1, Po =O)" (s) indicating that the tank is empty (ie. token in P), the pump off (ie. token in P,), and the valve closed (ie token in Ps). Then, the pump is switched on to fill the tank which is indicated by the firing of T>, the start pump transition. This represents the performance of the first production rule listed above, “When the tank is empty, switch the pump on”. This evolution of the system is described by the following Petri net evolu- tion. M, =(1001 10), 6 Mz = (0101107 a ‘To empty the tank, the valve is opened (ie. T; fires), M;=(011001). ® When the tank becomes empty, the valve is closed (ie TT, fires), and the system returns to its original state: M,=(01101 0). 0 The above example indicates the usefulness of a Petri net model to represent batch operation. How- ‘ever, certain drawbacks are evident even ftom this simple example. A classical Petri net modeling a real system, even in modest detail, tends to become com- plex, and extremely large. Every state that can be attained by the system has to be enumerated. Also, every possible interaction between the various states of the system has to be known in advance before a Petri net model can be developed. Therefore, the application of classical Petri nets to modeling chem- ical processes and their operation is limited. To ad- dress these limitations, extensions have been proposed for successful applications of Petri nets for large and complex systems, 1349 ‘Table 3. A chemical entity token Attribute Value Name ‘Composition 0% C 30% D Temperature asc Pressure Lamm 3.2, Colored Petri nets In classical Petri nets, each place P, can be occupied by m, tokens. Hence, the state of a system can be described only by an integer. Often more information about the state of a system needs to be represented, For example, if chemical entities are modeled as to- kens in a Petri net, to define the state of the system completely, we may need to represent temperature, pressure, and composition. Since these attributes can- not be represented by tokens in a classical Petri net, a value, often referred to as color, is associated with each token. The resulting Petri net is called a Colored Petri net (CPN). A colored token is an object to which attributes can be attached, The colored token can hence carry complex information or data. Thus, any kind of information regarding the token can be asso- ciated with the colored token. In the above example, the chemical entity token would have slots for name, ‘composition, temperature, and pressure. A particular instance of a chemical entity token is shown in Table 3. When a token resides in a place, the complete state of the system is defined. In CPN, transitions determine the slot instantiations of the produced to- ken based on the instantiation of the input token Thus, when the above-described token is input to a transition representing a heating subtask, the output token would have the same name, composition, and pressure but the value of the temperature attribute would be updated to represent the new state of the compound. A transition can thus embody a complex relation between the initial and final state of the system depending on the subtask being performed. 3.3. Timed Petri nets In some systems, a certain time may elapse between the start and end of an operation. It is important to be able to describe such temporal behavior of these sys- tems, However, in classical Petri nets transitions are instantaneous. Hence, when operations are modeled as transitions, information about time cannot be rep- resented. An additional dimension of time has to be added to Petri nets so that such systems can be modeled. There are two main methods for adding temporal information to Petri nets: timings associated with places (P-timed Petri nets), and timings asso- ciated with transitions (T-timed Petri nets). In P- timed Petri nets a time d, is associated with each place P.. A token added to P, is unavailable for enabling1350 conditions for the period. In T-timed Petri nets, a time 4, is associated with each transition T,, Also, each token has two states — reserved and unreserved, Only unreserved tokens are considered for enabling condi- tions. When a transition is enabled all its input tokens are reserved for firing, The firing itself occurs d, time later. T-timed Petri nets provide a means for incor- porating the dimension of time in a subtask. This would be discussed in more detail later. Several other modifications have been proposed to classical Petri nets. Some of these are abbreviations of classical Petri nets and are used for their simplicity, while others are extensions, David and Alla (1994) have surveyed sev- eral such modifications, Petri nets are a tool for representing the logical behavior of systems. However, there is no framework, either in the classical Petri net or in any of the modi- fied Petri nets proposed so far, to represent cause and effect relationships in a simple manner. As discussed earlier, digraphs have been widely used to build cause and effect models of chemical systems. Hence, a com- bination of Petri nets with digraphs can be effectively used to model the complex behavior of batch pro- cesses, which is what we propose in the next section. ‘4. Proposed representation framework The knowledge required for HAZOP analysis of batch processes includes the process P&ID and the product recipe. The product recipe is a hierarchical representation of the activities to be performed during Processing. Batch operations are performed as a se- quence of tasks, with each task being performed en- tirely in one unit. Each task comprises of a sequence of discrete subtasks. High-level Petri nets with timed transitions and colored tokens are well suited for representing batch operations. The product recipe as described in Table | can be represented using a Recipe Petri net. 4.1, Recipe Petri nets ‘The product recipe for a process contains informa- tion about the sequence of tasks and subtasks to be performed.* The sequence of tasks forming the prod- luct recipe cannot be inferred, in general, from the plant P&ID. For example, among the units in the plant described in Fig. 1, itis not clear whether STILL hhas to be operated first or TANK. However, t knowledge is of utmost importance to uniquely deter- mine batch operation. The importance of the se- quence of tasks is self-evident for multi-product batch plants where multiple tasks are associated with each unit. The task to be performed during a campaign is indicated by the product recipe. "Concurrent processing has not been considered here. How- ever, the current framework can be extended to account for concurrent operations also, This is under development. R. SRINIVASAN and V. VENKATASUBRAMANIAN aoa NTERUOATED | Fig. 4. Recipe Petri net for the batch plant in Fig. 1 Recipe Petri nets (RPN) can be used to represent the sequence of tasks to be performed during a cam- paign. Figure 4 shows the Recipe Petri net for the plant in Fig. 1. Recipe Petri nets have timed transitions and colored chemical entity tokens shown in Table 3. Each transition in these Petri nets repres- ents a task. The places represent the state of the entire plant. Associated with each transition in the recipe Petri net is a Task Petri net described below. 4.2. Task Petri nets Task Petri nets (TPN) represent the sequence of subtasks to be performed in each unit. Each transition in a TPN represents a subtask. Each place in a TPN indicates the state of the equipment. Colored tokens represent chemical species. The properties of chemical species pertinent to HAZOP analysis such as Name, ‘Composition, Temperature, and Pressure are the at- tributes associated with the colored tokens. The token shown in Table 3 is an example of a chemical entity token used in TPNs. Operations in an equipment start with a special transition called prepare-subtask. This subtask repres- ents all the activities to be performed on the equip- ment before processing can start. Similarly, at the completion of the task a specific subtask called clean- subtask is executed. This represents all the cleaning and other activities to be performed on the unit at the completion of the task. Every task has a unique pre- pare-subtask and clean-subtask. The prepare-subtask and the clean-subtask can be considered indicators of the start and stop of the task Figure 5 is a Petri net representation of the task described in Table 2. The transitions (boxes) represent the subtasks to be performed in STILL. The places (circles) store information about the state of the STILL at that stage of processing, The triangles at the beginning and end of the TPN indicate the prepare and clean subtasks for STILL. The connection-posts indicate the material transfer operations (like charg- ing a vessel, or dumping its contents) performed dur- ing the “React” task in STILL, as described below.‘The knowledge representation framework 1351 FLL o @ ® meee Pus ruse Oth) SUBTASK « One Transition LEGEND Connection fen D> mone <] cn Fig. 5. Task Petri net for STILL. Hazards often occur in batch plants when an opera- tion is carried out for either longer or shorter periods than dictated by the recipe. Itis therefore necessary to ‘model the duration for which each subtask is per- formed. So, an op-time, T, is associated with each transition in the task Petri net. The op-time is the duration for which the subtask is supposed to occur. The op-time can be determined from the subtask termination logic. If the subtask termination is by ‘atime event the op-time is fixed a priori. In the case of subtask termination by a state event, the op-time can be calculated if the mathematical model of the subtask is known. For example, in the “Fill” subtask on STILL, if the rate of transfer of the C-D Solution is known, then the op-time can be determined even though the termination logic is given as a state event. Occasionally, a subtask may not have started when it should have, This may cause the contents of the vessel to sit around, instead of the next subtask being per- formed. Hazardous side-reactions can therefore occur. Such scenarios can be represented by associating a dead time, Ts, with each transition. The dead time represents the time between when a subtask is enabled and when operation of the subtask actually starts. In real plant operations, dead time occurs due to the finite speed at which operators can perform actions. Most equipment in batch plants have multiple in- put and output ports for material transfer with other equipment. Also, to support multiple recipes and flex- ible operations, a large number of interconnections between process equipment exist. The product recipe contains information regarding the port to be used for ‘a material transfer operation. This information can be stored in the TPN using connection-posts. Connec- tion-posts mark material transfer ports in process equipment. Associated with each port is a unique connection-post. Each fill-subtask and empty-subtask has a connection-post attached to it since material transfer is performed during these subtasks. The direc- tion of the connection between a transition and a con- nection-post indicates whether material is transferred into or out of the unit during that subtask. In the plant shown in Fig. 1, the contents of STILL are transferred to TANK. This is indicated in the TPN for STILL by connecting the empty tank transition to the connection-post representing TANK as shown in Fig. 5. The TPN for TANK would have a corres- ponding connection-post for the STILL which would be connected to the transition representing charging the contents of STILL, 4.3, Subtask digraphs ‘Task Petri nets contain all information available in the product recipe about each task. However, the product recipe in itself does not contain any informa- tion about the cause and effect relationships between1352 process variables. Each transition in a TPN is there- fore a black-box model of the subtask. When a team of experts perform HAZOP analysis of a plant, they use their mental models of the subtasks to obtain cause and effect relationships. For example, during operation of the STILL shown in Fig. 5, ifthe charg- ing of chemical B in “Fill-2” is performed for a longer duration of time, the STILL could overflow leading to operator exposure to toxic materials. Such causal model of each subtask is critical for conducting HAZOP analysis of batch operations. To add this knowledge, a digraph can be associated with each subtask. ‘The subtask digraph represents the causal rela- tionships between process variables pertinent to that subtask. It can be derived from the balance equations governing that subtask. The subtask di- graph has certain important differences from the HAZOP digraph framework proposed by Vaid- hyanathan and Venkatasubramanian (1995a). In ad~ dition to nodes representing the state variables, the subtask digraph contains a node representing the duration of the subtask and nodes for the integral quantities — amount of mass and amount of heat contained in the subtask. In batch operations, material transfer occurs during filling and emptying subtasks. During other subtasks, operations are performed on the material already present in the unit. However, the amount of a sub- stance present in the unit may change during the course of other subtasks due to reaction and phase change. Similarly, the heat content of materials can also undergo changes due to heat transfer operations. ‘Therefore, digraph nodes representing amount of ma- terial which enters the subtask, amount of material ‘which leaves the subtask, amount of heat entering the subtask and the amount of heat leaving the subtasks are needed in each subtask digraph. This is in contrast to continuous plants where all transfer operations are continuous. Hence, the rate of mass and heat flow rather than the amounts are the important quantities, A subtask digraph model for the “cool” subtask is shown in Fig. 6. ‘The duration for which a subtask is performed is also important for hazard analysis of batch plants. If heating is performed on a unit for a longer duration than recommended, due to operator error, hazardous consequences may result. The subtask termination logic — the state of the unit which signals that the subtask should be terminated — is therefore a neces- sary part of subtask digraphs. Each subtask digraph hhasa termination-logic attached to one of the digraph nodes. The termination logic contains the value at subtask termination of the process variable to which it is attached. In the case of subtask termination by a time event, the termination logic is attached to the duration-of-subtask node. In the case of subtask ter- mination by a state event, the termination logic is attached to the process variable node which flags subtask completion. In Fig. 6, a subtask termination R. SRINIVASAN and V, VENKATASUBRAMANIAN logic with the value 35°C is attached to the temper- ature node. This indicates that the “cool” subtask terminates when the temperature in STILL 40-7A reaches 35°C ‘Another knowledge component to be modeled is equipment malfunction. HAZOP analysis requires modeling knowledge such as — a “no flow” situation may occur due to a “valve failing closed”. Equipment malfunction is generally process and recipe indepen- dent. Similarly, some consequences of process vari- able deviations are generic, Low coolant flow through the jacket of the CSTR may cause it to overheat. Such Knowledge can be built into subtask digraphs by including the abnormal cause and adverse conse- quence nodes as proposed by Vaidhyanathan and Venkatasubramanian (19952). The abnormal cause and adverse consequence nodes can be attached to any process variable node in the subtask digraph. The abnormal cause node stores information on the causes for a process variable deviation. The adverse conse- quence node contains information on the generic con- sequences of a process variable deviation. Figure 7 summarizes the knowledge representation framework proposed above. Two tiers of Petri nets are used to represent batch operation, On the upper level, a RPN describes the product recipe for a cam- paign. The sequence of subtasks in each task is repre- sented by a TPN in the lower tier of representation. Causal relationships between the process variables during each subtask is described by the subtask di- graphs. The TPN proposed here bear resemblance to the State-Task Network (STN) proposed by Kondili etal. (1993), STN was originally proposed to resolve ambi- Buities in recipe networks especially for multi-prod- uuct/multi-purpose batch plants. STNs comprise of two types of nodes: state nodes which represent the feeds, intermediate and final products, and the task nodes representing the processing operations. In spite of the topological similarity between STN and TPN, the knowledge present in the two are different. The STN, like the recipe network, describes the process itself. However, no knowledge about the process equipment in which the task has to be performed is present in the STN. For hazard analysis, properties of the process unit, such as, maximum temperature and pressure it can withstand, material of construction, etc, are important. The RPN and TPN, therefore represent the product recipe in a hierarchical frame~ work while including @ one-to-one correspondence with the process equipment in which the tasks are to be performed. The places in the TPN represent the state of the process unit at that stage of processing, with the process materials represented by colored tokens. Each transition in the TPN represents one subtask because the subtask termination logic plays a key role for analyzing plant maloperation, In the STN, each task represents the set of activities required to transform one material to another. The elementary steps — subtask — are thus not identified.‘SUBRAMANIAN R. SRINIVASAN and V. VENKATA: 1354 yromaurey 4 woneyussaidas s¥payHouy posodosd 1 Bi‘The knowledge representation framework 5. Conclusions Automating HAZOP analysis is an important problem with immediate industrial applications. Pre- vious work in this area has been limited to continuous processes and has not addressed batch processes in any significant depth. In this paper, the important issues involved in automating HAZOP analysis of batch processes have been discussed. In particular, the problem of modeling batch plant operation in a way suitable for automating HAZOP analysis is ad- dressed. It has been demonstrated that batch plant operation can be represented by making suitable modifications to high-level Petri nets, The concept of subtask digraphs to represent qualitative, causal knowledge is developed. Petri nets and subtask di- graphs have been integrated in a multi-tier framework to represent batch plant operations. Hazards arising due to either process variable deviation or plant mal- operation can be represented in the proposed frame- ‘work. Examples of the construction of the hierarchical modeling structures were presented. The application of this framework for a real-life industrial case study is discussed in Part II of this paper. References David, R. and Alla, H. (1994) Petri nets for modeling ‘of dynamic systems — a survey. Automatica 30(2), 175-202. Eli Lilly, (1994) Process hazard review of chemical R process. Private Communication. Kletz, T. A. (1986) HAZOP & HAZAN: Notes on the Identification and Assessment of Haards. The Inst tution of Chemical Engineers, Rugby England. Knowlton, R. E. (1989) Hazard and Operability Stud- ies: The Guide Word Approach. Chematics Interna- tional Company Vancouver. Kondili, E., Pantelides, C. C. and Sargent, R. W. H. (1993) A general purpose algorithm for short term scheduling of batch operations — I. MILP formula- tion. Comput. Chem. Engng 17, 211-227. Lawley, H. G. (1974) Operability studies and hazard analysis. Chem. Engng Prog. 70, 105-116. 1355 Lawley, H. G. (1976) Size up plant hazards this way. Hydrocarbon Processing $5, 247-261, Peterson, J. L. (1981) Petri Net Theory and the Modeling of Systems. Prentice-Hall, Englewood ifs, NB. Petri, C. A. (1962) Kommunikation mit auto- ‘maten. Ph.D. thesis, University of Bonn, Germany. Also in English translation, Communication with automata, New York, Griffiss air force base, Tech- nical Report, RADC-TR-65-377, Vol. 1, Supp 1, 1966. Reklaitis, G. V. (1991) Perspectives of scheduling and planning of process operations. Proc. PSE91 Conf, Montebello, Canada. Srinivasan, R. and Venkatasubramanian, V. (1995) Integrating Petri nets and digraphs to represent the HAZOP knowledge of batch processes. AICHE An- nual Meeting, Miami Beach, FL, 1784. Vaidhyanathan, R. and Venkatasubramanian, V. (1995a) Diagraph-based models for automated HAZOP analysis. Reliability Engng System Safety 50, 33-49. Vaidhyanathan, R. and Venkatasubramanian, V. (1995) Digraph-based models for automating HAZOP analysis of chemical plants. AIChE An- nual Meeting, Miami Beach, FL, 1731 Vaidhyanathan, R, and Venkatasubramanian, V. (1996a) HAZOP Expert: an expert system for auto- mating HAZOP analysis. Process Safety Progress 15(2), 80-88 Viadhyanathan, R. and Venkatasubramanian, V. (1996b) A_semi-quantitative reasioning methodo- logy for filtering and ranking HAZOP results in HAZOP Expert. Reliability Engng System Safety 53, 185-203. Venkatasubramanian, V. and Vaidhyanathan, R. (1994) A knowledge-based framework for automat- ing HAZOP analysis. AIChE J. 40, 496-505. Yamalidou, E. C. and Kantor, J. C, (1991) Modeling ‘and optimal control of discrete-event chemical pro- cesses using Petri nets. Comput, Chem. Engng 15, 503-519. Yamalidou, E. C., Patsidou, E. P. and Kantor, J. C. (1990) Modeling discrete-event dynamical systems for chemical process control—a survey of several new techniques. Comput. Chem. Engng 14, 281-299.