Phasuite: an automated HAZOP analysis tool for chemical processes

PHASUITE: AN AUTOMATED HAZOP ANALYSISTOOL FOR CHEMICAL PROCESSES

Part II: Implementation and Case Study

C. ZHAO, M. BHUSHAN and V. VENKATASUBRAMANIAN�

Laboratory for Intelligent Process Systems, School of Chemical Engineering, Purdue University, West Lafayette, IN, USA

To aid human experts in conducting HAZOP analysis in a more thorough and systema-tic way, a software system called PHASuite has been developed. The work is dividedinto two parts. First, a knowledge engineering framework has been proposed and dis-

cussed in Part I of this two-part paper. Based on the proposed framework, the second partfocus on issues related to design and implementation of PHASuite. Standard software engin-eering methodologies have been applied to guide the design and development of PHASuite inorder to achieve the goal of efficiency, flexibility and high quality. Layered and repositorysoftware architecture have been designed to handle the complex information flow and themultipart knowledge base in the system. Objected-oriented and component-oriented method-ologies are adopted for design and implementation. Unified modelling language is used fordesign and documentation of development details. The results management facilities of PHA-Suite, including results summary, details and reports are presented. An industrial pharma-ceutical process is presented as a case study to illustrate the applicability and procedure ofusing PHASuite for automated HAZOP analysis.

Keywords: automated HAZOP analysis; PHASuite; software engineering.

INTRODUCTION

To aid human experts in conducting HAZOP analysis in amore thorough and systematic way, PHASuite (ProcessHazard Analysis Suite) has been developed in this work.The knowledge engineering framework is presented in thefirst part of the two-part paper. Based on the proposed frame-work, a powerful software infrastructure is designed, andPHASuite is constructed.As discussed in Part I, the underlying knowledge engin-

eering framework is complicated and consists of severalmajor components. A good design is crucial to the successof PHASuite. Figure 1 shows the major components andtheir interactions in PHASuite. The bottom layer is theknowledge base, which contains operation related andsafety related knowledge. The object layer includes (1)objects related to knowledge, such as unit procedure, oper-ation, safety model for operation and equipment, which areinstantiated from the knowledge base through DAO orODBC; and (2) objects related to process information,such as equipment, chemistry and material, which can beinstantiated from the information directly imported fromother software systems using the information sharing

scheme based on ontology. Operating procedure synthesisengine uses the process information and operation knowl-edge to generate operating procedures, which are thenused by the process safety analysis engine to generateHAZOP results. All the results are stored in results data-base. User can then review the operating procedure resultsthrough operating procedures viewers and safety analysisresults through various safety results management facilities.The results can also be shared by other software systemsusing appropriate information sharing schemes. Knowledgebuilder is a knowledge acquisition and management facilityfor modifying the knowledge base.

To successfully build PHASuite, best practices of soft-ware development have been followed. General conceptsof these methodologies as well as their application in devel-oping PHASuite are discussed in the next section. Resultmanagement provides the interface for human experts toreview and access the results generated by PHASuite.Design and implementation details of this component arediscussed in the Results Management section. An industrialpharmaceutical process is introduced and used as a casestudy to illustrate the applicability and procedure of usingPHASuite for automated HAZOP analysis.

IMPLEMENTATION METHODOLOGIES

An automated HAZOP analysis system is very complex.The goal of this work is to develop a ready-to-deploy

�Correspondence to: Professor V. Venkatasubramanian, Laboratory forIntelligent Process Systems, School of Chemical Engineering, PurdueUniversity, West Lafayette, IN 47907, USA.E-mail: [email protected]

533

0957–5820/05/$30.00+0.00# 2005 Institution of Chemical Engineers

www.icheme.org/journals Trans IChemE, Part B, November 2005doi: 10.1205/psep.04056 Process Safety and Environmental Protection, 83(B6): 533–548

system and not just a prototype. Design and implemen-tation of such a complex system need careful and extensiveplanning. Software engineering practice, which is definedas application of a systematic, disciplined, quantifiableapproach to the development, operation and maintenanceof software that is the application of engineering to soft-ware (IEEE, 1990), is indispensable for success. In this sec-tion, the software development process, softwarearchitecture, design and implementation methodologies,as well as unified modeling language (UML), which isused to describe different aspects of the software, arediscussed.

Software Development Process

The classical software development process model is thewaterfall model (Braude, 2001), which is a sequence ofactivities consisting of requirement analysis, design,implementation, integration, system testing and documen-tation. Although the activities are basic elements in soft-ware development process, some of them need to bevisited more than once, which introduces the spiral processmodel. The idea is to build each version based on results ofthe previous one. For a large project involving many engin-eers from different disciplines, Microsoft’s synch-and-stabilize model is useful. As Cucumano and Selby (1997)reported, Microsoft typically decomposes projects intoparts, applies incremental synchronization process, andperiodically ‘stabilizes’ the applications by combiningparts. Since the development of PHASuite only involvesa small number of developers, the spiral process model isadopted in development of PHASuite.

Software Architecture

The architecture of a software system is concerned withthe top-level decomposition of the system into its maincomponents. As defined by Bass et al. (1998): ‘The soft-ware architecture of a program or computing system isthe structure or structures of the system, which comprise

software components, the externally visible properties ofthose components and the relationships among them.’

System engineering deals with complex problems. Avery good strategy for handling complexity is to decom-pose the problem so that it has the characteristics of asmall problem. Similarly, the core of software engineeringis decomposition. The tasks in designing software architec-ture, which is the basis of software development, are:

. define the system in terms of components and inter-actions among components;

. show correspondence between requirements andelements of the constructed system;

. address system-level properties such as scale, capacity,throughput, consistency, compatibility.

Bosch (2000) proposed a method for software architec-ture design that includes explicit assessment of quality attri-butes and design decisions for achieving those attributes.Hofmeister et al. (1999) divided software architectureinto four distinct views, based on what they had observedin practice. The four views are conceptual, module,execution, and code. The goal is to help software engineersmanage complexity by separating different aspects intoseparate views. In decomposition of the system, two mainconcepts are used to define the interactions within modulesand between different modules. Cohesion within a moduleis the degree to which communication takes place amongthe module’s elements. Coupling describes the degree towhich modules communicate with other modules. Effectivemodularization is accomplished by maximizing cohesionand minimizing coupling. Low coupling or high cohesionis particularly important for software design because ofthe necessity to continually modify applications. Good soft-ware architecture should have the following characteristics:(1) easy to add features; (2) able to facilitate changingrequirements; (3) easy to understand and implement; and(4) efficiency in execution and compilation, and havesmall size on run time and code base. After more thantwo decades of development in software engineering,researchers have categorized software architectures into

Figure 1. Major components of PHASuite.

Trans IChemE, Part B, Process Safety and Environmental Protection, 2005, 83(B6): 533–548

534 ZHAO et al.

following groups (Bass et al., 1998): (1) data flow architec-tures, including batch sequential and pipes and filters; (2)independent components, including parallel communicat-ing processes, client-server systems, and event systems;(3) virtual machines, including interpreters and rule-basedsystems; (4) repository architectures, including database,hypertext systems, and blackboards; and (5) layeredarchitectures.PHASuite is implemented based on layered and reposi-

tory architecture. The information flow in the system islayered, so the layered architecture is a natural fit. Inlayered architecture, a layer is a collection of software arti-facts, typically a package of classes. In the common form, alayer uses at most one other layer which is the layer justbelow itself, and is used by at most one other layer. Build-ing applications layer by layer can greatly simplify theprocess. Different components in PHASuite need to besupported by knowledge base. So knowledge base isdesigned as a repository. The conceptual design of thelayered architecture and important components for eachlayer are shown in Figure 1.

Unified Modelling Language

Unified Modelling Language (UML) is an object-oriented modelling language developed to visualize,specify, construct and document the artifacts of a softwaresystem (Booch et al., 1999). Diagrams are at the core ofUML. Different kinds of diagrams are used to model differ-ent aspects of a software system. In PHASuite, several dia-grams have been used to present the different views of thesoftware architecture and detailed design, including (1)class diagram as a static view of a system, classes, interfaceand their relations; (2) object diagram as static snapshots ofinstances of classes in class diagram to show objects andtheir relationships; (3) use case diagram as a static usecase view of a system; (4) sequence diagram as a dynamicview of a system to show time-ordering of messagesbetween objects; (5) state chart diagram to show theevent-ordered behaviour of an object; (6) activity diagramto show the flow control among objects; (7) component dia-gram as a static implementation view of a system to showorganizations and dependencies among a set of com-ponents; and (8) deployment diagram to show the configur-ation of run-time processing nodes.As an example, Figure 2, the use case diagram, shows the

main tasks of the system and the possible user interactionswith the system. From user point of view, the user can beinvolved in three major activities. Basic process infor-mation, including material, equipment, chemistry, andoperating procedures are input into the system. Afterchecking for completion of input information, tools arethen invoked to generate detailed operating procedures,i.e., process sequence diagram, and process flow diagram.Petri Nets representation is then created based on this infor-mation. Analysis is then carried out, and results are viewedby user.

Design and Implementation Methodologies

OOP and COPSimilar to decomposition, reuse has always been a

long-standing goal of software engineering researchers.

Object-oriented programming (OOP) is an approachtowards this goal. The basic concepts behind OOP are:object, class, encapsulation, polymorphism and inheritance.The information hiding mechanism supplied by OOP givesdeveloper more freedom to deal with complex problems. Italso provides a partial basis for extensibility. Many suc-cessful software systems have been developed based onOOP. OOP can be defined as:

Polymorphism þ (some) late binding

þ (some) information hidingþ inheritance

Creating truly extensible software systems, so that units(components) can be plugged in at run-time without anyeffect on existing components and without requiring aglobal integrity check, is a goal of development. OOP isnot enough to enable construction of truly extensible sys-tems. Safety and modularity are two main problems facedby OOP. To solve this problem and move towards creatingtruly extensible systems, component-oriented programming(COP) has been proposed recently based on OOP bySzyperski (1998). The main idea behind COP is interface(or contract). Compared with OOP, COP can beexpressed as:

Polymorphism þ (really) late binding

þ (real) information hidingþ safety

Code reuse is far less important than component reuse inCOP. Since a full integration test of all components is notfeasible, component construction requires safety by meansof strong and static local checking. Component configur-ation requires modularity. The software industry hasalready seen the trend to move towards adding small com-ponents that work together to replace isolated applications.The tools which can be used for COP include JavaBeans,COM, CORBA and so on. Praehofer et al. (2001) createda simulation framework using JavaBeans componentmodel.

As shown in Figure 1, PHASuite is developed using OOPand some components are designed using COP, e.g., thecomponent for two-level, two-layer reasoning enginewhich applies to both operation and equipment level.

Design patternsSuccessful design and implementation of a software

system depends not only on the overall architecture butalso on design details. Some of these design structuresrecur in different software, and good practice found inone can then be abstracted and reused. To describe theserecurring design structures, efforts have been made toabstract these structures from concrete designs, identifyclasses, collaborations, responsibilities, and discuss theapplicability, trade-offs and consequences. These descrip-tions are patterns, which can be defined as: named, wellunderstood good solutions to common problems in context.Gamma et al. (1995) summarized 23 useful design patterns,and cataloged them into creational patterns, such asAbstract Factory, Prototype, Singleton and so on; Structuralpatterns, such as Facade, Proxy, Composite and so on; andBehavioral patterns, such as Chain of Responsibility,


PHASUITE: PART II 535

Interpreter, Observer, Visitor and so on. Several benefitscan be achieved by properly adopting these design patterns,including: making the system robust to changes and supply-ing a common design vocabulary.The design patterns are applied frequently in the system.

For example, Singleton pattern is used to create the infor-mation reservoir. For operating procedure synthesis the sin-gleton information reservoir is the document object, and forHAZOP analysis, it is the PHAObject object. Compositepattern is used to relate the Petri Nets representation ofan operation to its model.

RefactoringDuring a software development process, some changes

are dramatic in the sense that the external behaviour ofthe software is changed due to design changes. Mostchanges are, however, made to improve the internal struc-ture of the software system, and the external behaviour ofthe code remains the same. As a common scenario, thecode will be modified after it was first constructed basedon a good design, and hence the integrity of the system,its structure according to that design, gradually fades. To

minimize the chances of introducing bugs in the code, adisciplined way for code change is necessary.

Refactoring (Fowler, 1999) is such a process. Simplesteps are taken, such as moving a field from one class toanother, pulling some code out of a method to make it aseparate method, and pushing some code up or down in ahierarchy. The cumulative effect of these small changescan radically improve the software inner structure. Fowler(1999) discussed the reasons for performing refactoring,general principles of refactoring, and also catalogued therefactoring methods. Some refactoring methods are usedregularly during the development of PHASuite, such asthe methods to move features between objects, organizingdata, composition methods, making method calls simplerand dealing with generalization.

Coding styles and documentationDocumentation is essential for reuse and maintenance,

and undocumented code is almost useless (Kernighan andPike, 1999). There are some tools that can extract formattedcomments in the source code and generate an on-line docu-mentation browser in HTML format or in other documen-tation formats. For example, Doxygen is such a tool for

Figure 2. Use-case diagram for PHASuite.


536 ZHAO et al.

Cþþ, and Java, and JavaDoc is a tool for Java. Coding stylesinclude naming conventions, comments types, documen-tation, complexity management, formatting and so on.Documentation in PHASuite is divided into several parts,

including: comments in the code to illustrate the function-ality of the piece of code or important lines, design detailsrecorded in separate documents, and also documents withgeneral ideas behind the design. Coding styles in PHASuitefollow specification in Hoff (2000).

GUI

As pointed out by Ambler (1998), for most of the users,the user interface is the software, i.e., a fundamental realityof application development is that the user interface is thesystem to the users. Constantine (1995) points out that agood user interface allows people who understand the pro-blem domain to work with the application without havingto read the manuals or receive training. So although thefunctionality that an application provides to users is import-ant, the way in which it provides that functionality is also asimportant. An application that is difficult to use won’t beused. Nielsen and Molich (1990) presented ten usabilityheuristics for user interface design. Though most of themare straightforward, they are nevertheless very useful.The most important guideline of GUI design for PHA-

Suite is to let user easily access all the information whichis obtained either from user input or is generated by thissystem in a consistent manner. The GUI is designed for anovice user to quickly build a mental model and understandthe control flow of the system, as well as for an advanceduser to quickly access and navigate through information.Attention is also paid to navigation within a screen andbetween screens.

Figure 3 shows the main elements of the GUI. At the topof the screen are menus and toolbars. The menus aredivided into six parts: File, Edit, Generate, HAZOP Analy-sis, Tools, and Results. The functionalities can be easilyidentified through the names. The input information is col-lected in the ‘project view’ tree shown on the left hand sideof the screen. The inputs are organized in four parts:material information, equipment information, chemistry,and operating procedure information. User can directlyaccess and modify the information associated with eachitem by double clicking on it. For inputs with no graphicalinformation, operations such as insert, delete can also beperformed directly through the tree view. Other views ofthe project can also be added to the left-hand side of thewindow. The right-hand side of the window is to displaythe graphical inputs and outputs. The windows aretabbed. Each window represents a specific part of the pro-cess information. P&ID is the window for entering P&IDinformation. Block Operation window is used to input theblock operations. PFD window is used to show the resultssimplified P&ID generated from P&ID. PSD windowshows the PSD diagram generated from operating pro-cedure synthesis. Different dialogues and forms are usedto interact with user, such as the dialogue for HAZOPanalysis where user can select the deviations to be ana-lysed, and the result summary dialogue to give the useran overview of the results. Grid view is adopted for userto examine the results as shown in Figure 3. User caninsert, delete, and modify results and the changes aredirectly exported to result database.

System Packaging

An installer for PHASuite has been developed to sim-plify the task for system installation and configuration.

Figure 3. Main GUI components.



After installation, several directories are created automati-cally, and entries in registry for storing some general infor-mation such as the directory information are created. Someof the installed files are binary files. Some of them are com-piled as executable files (exe) and some of them aredynamic library files (dll). Some of the files are related tothe storage of the knowledge base.Figure 4 shows the relationship between the main binary

files in the execution view of the system. PHASuite.exe isthe entry of the system. It supplies most of the user inter-faces. Operating procedures synthesis related routines arealso included in its code base. SimEng.dll is the library con-taining all the functionalities of the two-level, two-layerreasoning engine. HAZOPModel.dll is the library definingthe interface between knowledge base and the reasoningengine. PHACommon.dll contains the common class defi-nitions, such as material, equipment and chemistry, whichare shared by several modules.According to the process flow of this system, the main

functionalities in PHASuite.exe include (1) accepting userinput and/or importing information from other informationsources; (2) checking consistency and completeness ofinput information; and (3) operating procedure synthesisand viewing the generated operating procedures. Duringgenerating the HAZOP case study, SimEng.dll is invokedto transform the process information into a Petri Nets rep-resentation. At the same time, HAZOPModel.dll is invokedto select and import models from knowledge base into theruntime system. The analysis interface resides in SimEng.dllwhich also contains the reasoning engine and results creationfacilities. After the analysis is performed and results are gen-erated, the result repository is created. The results facilitiesin PHASuite.exe, interfacing with the results repository,can be called by the user’s requests during results review.

Integration with Other Software

The ability to integrate with other software is veryimportant, and hence PHASuite has been developed withopen architecture as one of the main guiding principles.The information sharing schemes discussed in part I ofthe two-part paper have been implemented. Interface hasbeen developed for importing process information fromBatch Plusw of Aspen Tech, and exporting analysis resultsto PHAProw.

RESULTS MANAGEMENT

Results management is a very important module in PHA-Suite. The results generated by reasoning engine are storedin a result database which consists of several predefinedtables. The main design concept for this module is to sep-arate results storage from safety analysis. Several tables areused to store process information related to results. The rawresults table documents every detail of the results. The rawresults are then processed and simplified for user to view.This module is highly user interactive. Through thismodule, user can access the results, view the results,modify the results and create report from the analysis. Cur-rently, there are two main views on the results, summaryand detail, as will be discussed in this section.

Characteristic of the Results

HAZOP analysis is a detailed safety analysis techniquewhich involves propagation of deviation to operations/equipments. This invariably results in generation of largenumber of results. Hence a well-designed results manage-ment strategy is vital for ensuring the success of any auto-mated HAZOP analysis technique. Appropriately reducingthe number of results and presenting the results to the userin a dynamic manner are crucial for good results manage-ment. It is also essential to understand the source of theresults and the number of distinct results in order to effec-tively manage the results. To distinguish between differenttypes of deviation propagation, as illustrated in Figure 5,causal path are categorized into three types:

(1) Direct causal path: process variable of the given devi-ation is connected with consequence node fromwhich results are generated. These process variablesare labeled as dprocvar. The dprocvar variables canbe further categorized into two types: (1) First typedprocvar which are process variables to which devi-ations can be applied to. (2) Second type dprocvarwhich are process variables to which deviationscannot directly be applied to, for example, reaction_ex-tent, separation_extent and so on.

(2) Local propagation path: deviation propagates from aprocess variable to other process variables in thesame model before a consequence node is reached.

(3) Propagation across models: deviation propagates froma process variable in a model to other process variablesbefore a consequence node in some other model isreached.

For direct causal path, the number of results depends onthe number of the first type dprocvar variables and the rulesfor local consequences and causes. For local propagation,the number of results depends on the complexity of themodel in terms of relations between process variables.Results are reported through dprocvar and some of theresults may have already been reported by first type dproc-var. For causal path across models, the number of resultsdepends on the complexity of the unit procedure in termsof the number of operations within the unit procedure.

Results from analysis on a small but typical pharma-ceutical process have been analysed and the observationsare: (1) approximate 50% of deviations generate results;(2) only 50% of the total results are unique; (3) fromFigure 4. Packaging diagram of PHASuite.


538 ZHAO et al.

deviation point of view, there are 165 deviations whichgenerate results, and 367 consequences to review; fromconsequence point of view, there are only 197 unique con-sequences to consider.Based on the characteristics of the analysis results, two

approaches can be adopted to help the user in meaningfullyreviewing the results: (1) reducing the number of results,and (2) providing the user with a better way of viewingthe results. From analysis point of view, possible ways toreduce number of results include (1) reducing number ofprocess variables: for example, separation of operationand equipment model and using more specific models foroperation and equipment would be helpful in achievingthis; (2) tightening rules for direct cause and consequencewith more sophisticated condition checking; (3) addingconditions (rules) on local propagation path, since currentlythere are no restrictions on the propagation path, except useof the arc property of being highable or lowable to deter-mine whether the path is valid; (4) restricting deviation pro-pagated to upstream/downstream operations by introducingprocess specific knowledge, including equipment conditionand material condition. Currently the deviation is propa-gated to all reachable operations/equipments within theunit procedure. Some of these ideas have already beenimplemented, and others are under active consideration.An intelligent and dynamic result management tool is

required to provide an appropriate way for user to reviewthe results. In PHASuite, such a result management toolhas been developed which has the following features:

. User can view results categorized by location, deviation,consequence class, material, and severity.

. After user finishes reviewing a consequence, all the devi-ations that can generate the same consequence can bemarked.

. Results are not only shown statically, but also changedalong with the review process.

. The causal path for cause and consequence can be dis-played to the user.

. Statistics on the results are easily accessible to the user.

In the current implementation, the results from thereasoning engine are stored in a result database. Severaltables are used to store different information about theresults. Operations table stores the information aboutthe operating procedures as well as the mapping betweenthe level of the operation which user can access and theintermediate operation level which is only visible to thereasoning engine. The Equipments table maps the ID ofthe equipment which is used in other tables to the nameof the equipment. DigraphNodeInfo table maps the ID ofthe diagraph node to the variable name that the node rep-resents. The ID of a node is a string, with format of‘(UniqueID of the operation).(ID of the node in themodel)’. The results, which are obtained directly from thereasoning engine without any further processing, arestored in RawResult table. Each record in this table rep-resents a result, with all the information to specify theresult, including the location of the deviation, the type ofthe deviation, the consequence and its location, the causeand its location, severity of the consequence, the safeguard,the recommendation, and the causal paths for cause andconsequence. The materials which are involved in eachresult are stored in ConseqMaterials table. The intentionin constructing the RawResult table is two-fold. It ensuresintermediate storage or internal copy of all the results gen-erated by the reasoning engine. Also, due to the differentlevels of operations which the user can access and thereasoning engine works on, it is difficult for user to under-stand the raw results without any further processing. Result-ForDisplay table is generated from RawResult table andstores these results which are accessible to the user. Thekey step to create ResultForDisplay from RawResult is toupdate the identification of the deviation source operation,consequence location operation and cause location oper-ation from UniqueID to normal operation numbers. Thepurpose of this step is to move from lower intermediatelevel of operation to a higher level operation. By doingthis, some results may seem to be the same to the user,and the duplicate causes or consequences are then deleted.Other techniques can also be applied to make the results

Figure 5. Different types of causal path.



easier to review. For example, rather than repeating a resultwhich has been reported somewhere else in the results fromother deviations along the causal path, a message such as‘@Refer to (the location of the deviation the results arereported)’ can be generated. Figure 6 illustrates the overallstructure of the results management tool.

Results Summary

To present the users with an overview of the results fromthe analysis, a results summary facility is constructed inPHASuite. This facility allows user to check the numberof results generated by taking various combinations ofdifferent criteria. A screen shot of the result summary facil-ity is shown in Figure 14. The different criteria which canbe used to categorize the results are (1) the origin of theresult, i.e., the unit procedure within which the deviationis applied; (2) the consequence class, e.g., equipment rup-ture, fire hazard, operator exposure, runaway reaction andso on; (3) the severity of the result, with the level of sever-ity increasing from 1 to 5; (4) type of deviation, e.g., hightemperature, high level, high pressure, and so on; and (5)materials involved in the result. Each criterion is shownin a list box along with the number of results belongingto every item in the criteria. For example, in Figure 14,there are 102 results in the first unit procedure. Categorizedby the classes of the consequences, 69 results belong to firehazards while 17 belong to equipment rupture. Categorizedby severity of the consequence, 49 results have highestseverity of 5. Categorized by the type of deviation, 46results are due to high agitation in different operations,and categorized by presence of materials, ACETIC-ACIDis involved in 30 results. The user can also combine differ-ent criteria to categorize the results. The criteria selectedfrom different categories are combined using ‘AND’ oper-ator. For example, by selecting the first unit procedure and‘corrosion’ in the ‘consequence class’, the user can viewthose results which lead to corrosion in the first unitprocedure.The details of the results filtered by combination of

different criteria can also be shown in the Results Details

view and can be reported in a report view, by selectingthe commands ‘Show Results’ and ‘Report Results’respectively. The Results Details facility and ResultsReport facility are discussed next.

Results Details

Eventually, the user needs an easy to use facility to gothrough the results one by one. Such a Results Details facil-ity has been constructed in PHASuite, and is shown inFigure 15. The main portion of the facility is the resultsworksheet in a grid view with style similar to that ofExcel worksheet. The top portion of the frame containsthe control information of the results worksheet. Resultsare organized by unit procedure, operation, and the devi-ations listed in the corresponding list boxes. The unit pro-cedures and operations correspond to the operatingprocedures listed in the ‘Operation’ section in the ProjectView. In the results worksheet, information shown for aresult includes the deviation type, deviation variable,cause, consequence, safeguards, recommendation and com-ments. Every field in the result worksheet is editable. Usercan also add or delete a result. All of these modificationsare directly made to the results storage. More informationon the result can be accessed by clicking the right buttonof the mouse over different fields of the result. Currently,when this is done over ‘node variable’ field in a result,equipment involved in this result and type of model usedin analysis are summarized in a dialog box and shown touser. By doing this over cause or consequence, causalpath for the cause or consequence is displayed in a dialoguebox as illustrated in Figure 15. In this dialogue box, usercan find more information related to the result, includingthe severity of the result, the materials involved, and thepath of the deviations with their locations which leadfrom the deviation to the location of consequence or fromthe location of the cause to the deviation. A dialogue boxfor editing/entering information for following up the rec-ommendations can be accessed by clicking right button ofthe mouse over the recommendation field.

During reviewing the results, user can mark if the currentresult is important or worthy of further discussion by set-ting the first field with label of ‘Discussion?’ of the resultsworksheet to be true, as shown in Figure 15. By doing this,the text colour for the whole result is changed to blue inorder to distinguish it from other unselected results. Usercan also view only the selected results or unselected resultsor both of them by toggling the corresponding settings inthe upper control information frame.

Besides the above features for providing assistance to theuser for reviewing the results, some more advanced wayscan also be implemented in results detail view. Forexample, in current version of PHASuite, when user setsa result to be discussed, all the results similar to the currentresult in terms of the consequence being the same but fromdifferent causal path can also be automatically selected.

Exporting Results

As the user views and modifies the results, the resultsdatabase is automatically updated. The report facility canthen be invoked to generate a report to document theresults. Figure 17 shows the report template available inFigure 6. Overall structure of results management.


540 ZHAO et al.

the current version of PHASuite. The report can also beexported to different file formats, so that it can be loadeddirectly on the web, or stored in a word document, andso on.In addition, the results can be exported to file formats

which can be accessed by other process safety documen-tation tools. In current version of PHASuite, the resultscan be exported to a hierarchical text format, and after amapping of fields, the results can be imported to PHAProw

as discussed in the first part.

CASE STUDY: AN INDUSTRIAL PHARMACEUTICALPROCESS

An industrial case study is used to illustrate the function-alities of PHASuite and the procedure to perform safety

analysis using PHASuite. The case study is a typicalbatch process from a major pharmaceutical company inUS. The process contains around 20 high level operationsand 120 low level operations. Some unit procedures containmore operations than others, for example, the smallest unitoperation contains three steps, and the largest one containsmore than 10. Around 20 materials are used in the process.Most of them are hazardous, for example, some of them areflammable, static, toxic, or highly reactive materials. TheP&ID consists of around twenty major equipments includ-ing reactors, tanks, distillation columns and so on. The pro-cess involves four reactions, and ten separations includingextraction, filtration, centrifuge, drying and distillation.The process information was already available in BatchPlusw. The screen shots were captured during performingprocess safety analysis on this case study using PHASuite.

Figure 7. Importing process information from Batch Plusw.

Figure 8. Interface for user input/modification on process information.



Because of the confidentiality reason, some sensitive infor-mation, such as material names and equipment names arecovered by ‘��’. For this case study, more than90% of the process information can be imported from

Batch Plusw. The major effort for entering process infor-mation is related to the hazardous properties of processmaterials, which are currently entered manually by compil-ing the relevant information from MSDS.

PHASuite gathered information from Batch Plusw usingthe information sharing schemes based on ontologies (dis-cussed in Part I) as shown in Figure 7. During the step ofchecking for completeness and consistency of the infor-mation, the information not available from Batch Plusw,mainly the material hazardous properties, are input throughthe interface shown in Figure 8.

The operation knowledge stored in knowledge base is thenused by the operating procedure synthesis engine to generatedetailed operating procedures. The main interface the userwould encounter is shown in Figure 9. Before operating pro-cedure is generated, PHASuite checks the completeness ofthe information and notifies user if information is not com-plete. Several icons are used to inform user that some infor-mation is necessary but missing from the specification. Forexample, an icon with ‘Q’ in red background displayed infront of an operation in project view shows that the operationspecification is not complete, as exemplified by operation 2.2in Figure 9, where equipment is not specified. The icon with‘S’ in green background informs user that a separation needsto be specified for that operation.

The generated process sequence diagram (PSD) is shownin Figure 10. The PSD contains a unique column corre-sponding to each equipment involved in the batch process.The columns are populated with operations correspondingto that equipment arranged in a temporal sequence.Figure 11 shows the interface where the user can examine

Figure 9. Generating operating procedures and completeness checking.

Figure 10. Process sequence diagram.


542 ZHAO et al.

the detailed instruction for the operation and a video screenhas also been embedded to show the correct procedures forcarrying out the current operation. To generate a HAZOPcase study for this process, user would only need toselect from the corresponding menu, specify analysismode, and confirm the creation, with just few clicks ofmouse button. The procedure is shown in Figure 12. Alot of details, however, are hidden behind the scene, includ-ing (1) PHASuite automatically converts the PSD and PFDto a colored Petri Nets representation; (2) the level of PFDand PSD are bridged using functional representation; and(3) appropriate models for operations and equipments areselected from the knowledge base which is managedusing case-based techniques.Figure 13 shows the main interface for user to interact

with the reasoning engine. User can browse through theavailable deviations for each unit procedure and also foreach operation. User can specify failure analysis setting,which is different from the normal deviation analysis inthe manner in which propagation is carried out. User caneither select ‘Run Selection’ and the reasoning enginewould then only analyse the deviations specified, or usercan select ‘Run Process’ to perform analysis on thewhole process. Behind the scene, the two-level, two-layerreasoning engine is called up to perform analysis basedon the Petri Nets representation of the process and retrievesafety related knowledge from the knowledge base. Thebasic steps consist of material propagation, deviationpropagation and result generation.The analysis on this process took about 1 min on a PC

with Pentium II 600 MHz processor and 256 MBmemory. After the analysis, Figure 14 shows that 1153deviations are analyzed in PHASuite, and about one thirdof the deviations, 451 to be precise, generate abnormal con-sequences. The total number of results is 616. Through the

interface for Results Summary, the user is able to query thestored results based on different combinations of variouscriteria, including unit procedure, consequence class, sever-ity level, deviation type, and hazardous material involved

Figure 11. Batch instructions.

Figure 12. Steps for creating HAZOP case study.



in the consequence. The counts of consequences are alsoshown in each column presented in the interface to illus-trate the number distributions. Results details window isshown in Figure 15. The results are organized accordingto the levels of operations and deviations, as shown inthe control frame. Current unit procedure, operation anddeviation are shown in corresponding list boxes. By

choosing the ‘all deviation’ option from the Deviation listbox, all the results belonging to the current unit procedureand current operation are shown in results worksheet. Theresults are listed one by one in the worksheet with eachof them showing the deviation type (i.e., high, low, zero),deviation variable (i.e., temperature, pressure, level, andso on), cause, consequence, safeguard, recommendation,

Figure 13. Main interface for conducting HAZOP analysis.

Figure 14. Results statistics and results summary.


544 ZHAO et al.

and comment. By clicking the check box in the firstcolumn, the current result is marked for later discussion,and the font colour of the current result shown in thatrow is changed to blue. By toggling the checkboxes on

the control frame, Selected and Unselected, only theselected results, unselected results or all the results canbe displayed in the worksheet frame. Each column in theworksheet is clickable, i.e., by clicking right button of the

Figure 15. Results details and interface for showing auxiliary information.

Figure 16. Modification on the knowledge base through Knowledge Builder.



mouse, information related to that item shows up as shownin Figure 15.While reviewing the results, the users may find that some

consequence are not desirable or not a concern in general,

for example, ‘boil-off of liquid materials’ in current casestudy. After finding out the model from the deviation infor-mation dialogue, the user, in current implementation, canuse Knowledge Builder to delete the local consequence

Figure 17. Report template.

Figure 18. Results exported from PHASuite read by PHAProw.


546 ZHAO et al.

from the ‘charge_operation’, as illustrated in Figure 16.When the analysis is performed next time, the undesirableconsequence will not be generated.After reviewing the results, user may export the results to

a report using the report facilities. Current report templateis shown in Figure 17. Results can also be exported tosafety documentation tools. Figure 18 shows the resultsexported to PHAProw.For this process, it takes a team of four experts four full

days to finish the HAZOP analysis, and the total time isabout 128 man-hours. The analysis time using PHASuitecan be divided following the steps illustrated in Figure 1of Part I of this paper.

. Gathering process information. Since most of the processinformation has been imported automatically from BatchPlus, the time spent on entering information is only formanually entering the material hazardous properties,associating reactions with corresponding operations,and checking for missing information. This should takean engineer less than 2 h.

. Analysing automatically in PHASuite. Little time isneeded for PHASuite to analyse. For this process, PHA-Suite generates the analysis results in minutes.

. Reviewing the results. This is the most time consumingstep. The PHA team needs to go over the results gener-ated by PHASuite one by one. On an average, it takes1 min for discussion on one result (a lot of results arerepeated due to the propagation nature of HAZOP analy-sis). So the total time for the 600 results generated in pro-cess will take 40 man-hours.

. Covering other safety problems that have not been con-sidered in PHASuite. In this case study, PHASuite cancover 80% of the results. It is estimated that analysingthe specific safety problems may take about 25 man-hours.

So in total, using PHASuite, it took the human expertsabout 68 man-hours to finish safety analysis for this pro-cess. Compared with the time spent on the same processwithout the help of PHASuite, the time saving is about50%. Besides this case study, PHASuite has been appliedto a few other industrial chemical processes. The resultshave been compared with the PHA study conducted byPHA team. It has been observed that PHASuite consistentlycaptures about 80% of the safety issues. A sample compari-son of the results generated by PHASuite and by PHA teamis presented in Table 1. At the same time, PHASuite sys-tematically analyses potential deviations and generatesmore consistent results than the PHA team, e.g., low dur-ation of wash leading to operator exposure to hazardous

materials and fire hazards during unloading wet cake; andhigh temperature in hydrogenation may lead to vaporiza-tion of solvents and potential fire hazards.

CONCLUSIONS

To aid human experts in conducting HAZOP analysis ina more thorough and systematic way, a software system(PHASuite) has been developed. The system is based onthe knowledge engineering framework proposed in thefirst part of this two-part paper. Implementation of the frame-work as a software system requires systematic design andsuitable implementation methodologies. Software engineer-ing methodologies have been adopted in every stage ofimplementation, including design of the architecture, devel-opment of the code base, testing of the software, and so on.PHASuite has the following properties: (1) quality in termsof reliability, maintainability and resource efficiency; (2)robust and flexible knowledge base structure; (3) clearlydefined user flow control; (4) supporting flexible user inter-action; (5) extensible.

An industrial pharmaceutical process is presented as acase study to illustrate the applicability and procedure ofusing PHASuite for automated HAZOP analysis. It showsthat PHASuite can capture more than 80% results com-pared to the results generated by human teams. At thesame time, PHASuite systematically analyses potentialdeviations and generated more consistent results than thehuman PHA team. Using PHASuite, there is about40–60% savings in time and effort.

REFERENCES

Ambler, S.W., 1998, Building Object Applications that Work: Your Step-By-Step Handbook for Developing Robust Systems with Object Technol-ogy (Cambridge University Press, New York; USA).

Bass, L., Clements, P. and Kazman, R., 1998, Software Architecture inPractice (Addison-Wesley, MA, USA).

Booch, G., Rumbaugh, J. and Jacobson, I., 1999, The Unified ModelingLanguage User Guide (Addison-Wesley, MA, USA).

Bosch, J., 2000, Design and Use of Software Architectures (Addison-Wesley, MA, USA).

Braude, E.J., 2001, Software Engineering: An Object-Oriented Perspective(John Wiley & Sons, Inc., NJ, USA).

Constantine, L.L., 1995, Constantine on Peopleware (Yourdon Press).Cucumano, M.A. and Selby, R.W., 1997, How Microsoft builds software,

Communications of the ACM, 40(6): 53–61.Fowler, M., 1999, Refactoring: Improving the Design of Existing Code

(Addison-Wesley, Reading, Massachusetts, USA).Gamma, E., Helm, R., Johnson, R. and Vissides, J., 1995, Design Patterns:

Elements of Reusable Object-Ori0ented Software (Addison-Wesley,MA, USA).

Hoff, T., 2000, Cþþ Coding Standard. http://www.cs.umd.edu/users/cml/cstyle/CppCodingStandard.html.

Table 1. Examples of comparison between the results produced by PHASuite and human team.

Deviation Consequence by human PHA team Consequences generated by PHASuite

High duration ofdistillation operation

Receivers could be overfilled Potential overflow in receiver to vent pipe

Improper sampling Operator could get exposed to Material-1and process solvents

Operator exposure to hazardous material (ethanol, methanol,hydrogen-chloride, Material-1, toluene) during sampling

Low temperature indistillation operation

If the distillage plugs or freezes, the stillwould pressure up and cause the rupturedisc to break (venting to the roof)

Potential freezing-up in the condenser tubes leading to highpressure in the distillator



Hofmeister, C., Nord, R. and Soni, D., 1999, Applied Software Architec-ture (Addison-Wesley, MA, USA).

IEEE Standard 610.12–1990, 1990, IEEE Standard Glossary of SoftwareEngineering Terminology (IEEE).

Kernighan, B.W. and Pike, R., 1999, The Practice of Programming(Addison-Wesley, MA, USA).

Nielsen, J. and Molich, R., 1990, Heuristic evaluation of user interfaces,Proceedings of ACM Conference on Human Factors in Computing Sys-tems, Seattle, WA, USA, 249–256.

Praehofer, H., Sametinger, J. and Stritzinger, A., 2001, Conceptsand architecture of a simulation framework based on theJavaBeans component model, Future Generation Computer Systems,17: 539–559.

Szyperski, C., 1998, Component Software: Beyond Object-OrientedProgramming (Addison-Welsley, MA, USA).

The manuscript was received 1 March 2004 and accepted for publi-cation after revision 4 April 2005.


548 ZHAO et al.

Documents

Phasuite: an automated HAZOP analysis tool for chemical processes