~ PergamonComputers and Chemical Engineering Supplement (1999) S391-S39~

© 1999 Elsevier Science Ltd. All rights reservedPII: S0098·135~199/00136-2

Verifying Signed Directed Graph Models forProcess Plants

Claire Palmer and Paul W.H. Chung

Department of Chemical Engineering, Loughborough University, Loughborough, Leicestershire, LEll 3TU

ABSTRACTQualitative modelling using signed directed graphs is briefly described. The need for verification is discussed andthe verification techniques for signed directed graph models of process plants are detailed.

Keywords: qualitative modelling, signed directed graphs, verification

QUALITATIVE MODELLINGSigned directed graphs are a form of qualitative model.This paper will begin by describing the concept ofqualitative models, why they are useful and explainingwhy they are difficult to construct. The need forverification of the signed directed graph models createdis considered.

Quantitative numeric methods havetraditionally been used for detailed design. However,for many engineering tasks numerical methods are notalways required or suitable. Qualitative reasoning isable to provide statements about the possible behaviourof dynamic systems, emphasising a causal explanationof the behaviour derived from a structural description.Numerical methods give precise answers but if a broaderoutlook is required then qualitative reasoning canprovide the solution to a whole class of problems.Qualitative reasoning does not require detailedquantitative information (which may be difficult orexpensive to acquire or simply unnecessary) in order todescribe a physical system. As well as providing adescription of the physical system, qualitative reasoningcan be used to explain how the system functions. Asqualitative models do not refer to numeric values,precise values are abstracted into symbolic ones. Forexample, a change in a value for a process variable suchas flow might be depicted qualitatively as increasing.

A signed directed graph (lri et aI., 1979;Oyeleye and Kramer, 1988; Wilcox and Himmelblau,1994; Chung, 1993; Larkin et al., 1997) consists of aninfluence graph with labelled arcs. An influence graphcontains the variables in a physical system which aredepicted as nodes. These are connected by arcs toreflect the influence the variables have on one another.An arc from a node X, to another node Y, indicates thata change in the variable X will cause a change in thevariable Y. An influence is defined as a causal relationbetween two variables or simply how one variableaffects the other. Several variations of signed directedgraph exist in which the arcs may be labelleddifferently. In the format used here each arc of thegraph is labelled with a sign "+" or "-". The sign" '+"indicates a positive influence, i.e, Y will increase if X isincreased and Y will decrease if X is decreased. The

sign "-" indicates a negative influence, i.e. Y willdecrease if X is increased and Y will increase if X isdecreased. The SDG allows the behaviour and failureaspects of individual components within a process plantto be described, including how they relate to, and affect,other components. A tool is being created to build SDGmodels with an application in mind. This application isthe expert system QUEEN (Qualitative Effects Engine)which analyses the effects of process deviations inprocess plants (Chung, 1993).

Qualitative model construction is recognised asa difficult task (Schut and Bredeweg, 1994). However,no guidelines exist as to how to build the models.Consequently there are no tools to aid in model'construction. Applications such as QUEEN require agood library of component models. The model librarywas previously achieved by experts writing the modelsin a format that could be directly used by theapplication program. An engineer who is unfamiliarwith the system would find this difficult. An alternativemethod would be to use an intermediary (a knowledgeengineer) to gather information from the expert andconvert it into the application system format. Thiswould be expensive and time consuming. Both methodswould take up a lot of the expert's time. An engineershould be able to enter information directly in order tomaintain efficiency and avoid information loss throughthe intermediary. A prototype tool, Equipment ModelBuilder (Palmer and Chung, 1997; 1998), which enablesan expert to enter information directly without needingto understand details of the model format or theapplication.

All forms of modelling errors occur due toomissions and mistakes. These errors need to beidentified otherwise this could lead to wrong resultsbeing output by QUEEN. This paper will look at whatis meant by verification and some of tile verificationtechniques used by Equipment Model Builder.

VERIFICATIONSeveral definitions of verification exist in the literature.Andert (1992) defines verification as "substantiationthat the system does the job right. Verification requiresdetermination through formal confirmation and/or proof

+X --. Y

frame(tank isa unit,[ inports info [in],

outports info [out],unitports info [ liquid,vapour ],propLinks info [%propagationarc([in,flow],+,[liquid,levelD,arc([liquid,levell,+,[out,flow]),arc([in,temp],+,[liquid,temp]),arc([liquid,temp],+,[out,tempD,arcqvapour.templ.e.lliquid.templ),%faultsarc([fault,'external fire'],+,[vapour,tempD,%consequences resulting fromfaultsarc([fault,'leak to environment'],+,[consequence, 'loss of rnaterial'[),%consequences resulting fromdeviationsarc([deviation,[lessLevel,liquid]],+,[consequence,'vessel emptying'[),arc([deviation,[moreFlow,outll,+,[consequence,'vessel emptying'[),arc([deviation,[moreTemperature.liquidll,+,[consequence,'crystallisation'])]]).

The node 'X' may be compared to the conditions or lefthand side of a rule. The node 'Y' may be compared tothe conclusions or right hand side of a rule. Thecompleteness checks for rule-based systems are alsoapplicable to systems constructing SDG models.

How unreferenced attributes may occur in theunit models is illustrated using a simple model.

It can be seen from the example that there are four types

of SDG arc within a unit model:(i) deviations linked to deviations, e.g.([in,templ,+,[liquid,temp]);(ii) faults linked to deviations, e.g. ([fault,'externalfue'] ,+,[vapour,temp]);(iii) faults linked to consequences, e.g, ([fault,'leak toenvironment'],+,[consequence, 'loss of material']);(iv) deviations linked to consequences, e.g.([deviation]moreTemperature,liquid]],+,[consequence,'crystallisation'])

The initiating node 'X' of the arc shown couldbe a deviation or a fault. The influenced node 'Y' could

COMPLETENESS TECHNIQUESIncompleteness can occur due to a number of reasons.We will consider incompleteness resulting from:• unreferenced attributes;• missing propagation paths.

5392 Computers and Chemical Engineering Supplement (1999) S391-5394

that the system is correct, complete, and consistent UNREFERENCED A1TRIBUTESwithin itself and its specification". By contrast Hoppe The term 'unreferenced attributes' has been taken fromand Meseguer (1993) state that verification "checks a the body of work describing verification of rule-basedknowledge-based system against the specifications systems. Two types of incompleteness check forgenerated by its totally formalizable requirements . It is unreferenced attributes are reIevent to this work: theperformed by checking and not by proving knowledge- dead-end conclusion check and the unreachablebased system properties". Gupta (1993) defines condition check. The dead-end Conclusion checkverification as "a process by which the requirements, identifies rules with' conclusions that can never bespecifications, and design of the system are tested and utilised. The unreachable condition check identifiesevaluated for accuracy and consistency." rules with conclusions whose conditions can never be

For clarity, verification will be defined here as met.ensuring that the internal structure of each model is, as An SDG may be compared to a rule. Considerfar as possible, complete, correct and consistent. the arc shown below.Verification should also ensure that the model'sbehaviour is plausible. This means that the modelshould function correctly. This overlaps with somedefinitions of validation. For example, Gupta definesvalidation as "the functional accuracy or correctness ofthe system's performance." Ensuring that the internalstructure of the model is correct will go some waytowards ensuring that the model functions correctly.Some of the techniques used for verification may alsobe applicable to validation . Therefore, there is anoverlap between verification of a model and validation.However complete validation may only be achieved bytesting the model in the environment in which it isgoing to be used.

Verification consists of a number of techniques.The choice of techniques used will depend on the systembeing verified. The verification techniques must ensureas far as possible that the model is complete, correct andconsistent. In order for a model to be consistent it mustbe correct and concise.• A complete model is free from missing information.

It contains sufficient information to be able tofunction in all possible situations that arise in theapplication. AIl the information that ought to be inthe model is contained in the model structure.

• A correct model is an accurate representation andcontains no wrong information . It has no conflictinginformation . or illegitimate attributes. Anillegitimate attribute is one which does not occurwithin the set of attribute values allowed for themodel. A correct model will function correctly.

• A concise model has no redundant or duplicatedinformation. It has no information which issuperfluous or unnecessary. A model which is notconcise may lead to additional processing and maybe ambiguous.

Some of the techniques described here arepurely verification techniques wheareas others may bethought of as part of the tool's user interface,duplication checking or explanation facilities. A seriesof models has been developed to test the verificationmethods used.

Computers and Chemical Engineering Supplement (/999) 5391-5394 5393

be a deviation or consequence. A consequence mayoccur directly as a result of a fault (arc type iii). It mayalso occur as a result of a fault propagating through adeviation or series of deviations. For example, thefollowing fault propagation might occur within the tankmodel, leading to the consequence shown:

([tank,fault,extemal fire],+,[tank,vapour,temp])([tank,vapour,temp], +, [tank,liquid,temp])([tank,deviation,[moreTemperature,liquid]],+,[tank,consequence,crystallisation]).

The nodes in the path are of the types ii, i and ivrespectively. The fault (failure mode) initiating apropagation path need not be present in the same unit asthe resulting consequence. The fault may occur in a unitupstream in a plant and cause a deviation whichpropagates into another unit via its inports, or in adownstream unit and cause a deviation whichpropagates into another unit via its outports, to result ina consequence. For example, a pipe model linkedupstream of the tank model could cause the followingconsequence in the tank model:

(Ipipe.fault.partly blocked], -,[pipe,out,flow])(lpipe.out.flow], +,[tank,in,flow])(jtank.in.flow], +,[tank,liquid,level])([tank,deviation,[lessLevel,liquid]],+,[tank,consequence,vessel emptying])

Thus in order for a fault to have the potential tocause a consequence it must fall into one of thefollowing categories:(I) The fault must be directly linked to the consequence.(2) The fault must cause a deviation which propagateswithin the unit model to cause a consequence.(3) The fault must cause a deviation which propagatesout of the unit model via its inports or outports resultingin a consequence in another unit.

Any fault that does not fall into one of more of thesecategories is an unreferenced attribute as it has nooverall effect. An unreferenced fault (failure mode)causes a deviation with no effect.

Deviations with no effect may be present infault linked to deviation arcs as described above. Theymay also bepresent in deviation linked to deviation arcsin which the deviation does not propagate to a boundaryport. Deviations propagating from model boundaryports (ie. in and out ports) are assumed to have an effectas they may propagate out of the unit model resulting ina consequence in another unit. For example, thedeviation 'outflow' in the arc'([tank,liquid,level],+,[tank,out,flow])' could propagateout of the pipe unit to cause a potential effect in adownstream unit in a plant.

In order for a consequence to occur it musteither be:(1) directly linked to a fault.(2) result from a fault causing a deviation to propagatewithin a unit model.

(3) be linked to the inports or outports of lie unit model.This is so that deviations may propagate in to the unit tocause the consequence. An example of this last case fora tank model would be:

([tank,deviation,[moreFIow,out]],+,[tank,consequence,vessel emptying])

Any consequences not fulfilling these criteria areunreferenced attributes as they will never occur. Anunreferenced consequence is linked to a deviationwithout a cause.

Deviations without causes may be present indeviation linked to consequence arcs (described above).They may also be present in deviation linked todeviation arcs in which lie deviation does not initiate ata boundary port. Deviations initiating at boundaryports are assumed to have a cause. The cause maypropagate into the unit via its boundary ports fromelsewhere in the plant. For example, the deviation'inl.flow' in the arc "([tank,in,flow], +,[tank,liquid,level])" may be caused by a faultpropagating into the tank unit from an upstream unitwhen the tank unit is present in a plant description.

For a given model, Equipment Model Buildermaintains lists of deviations with no effect anddeviations without causes. Each new arc added ordeleted is checked to see if it causes these lists to requireupdating. A user may access these lists from a drop­down menu.

MISSINGPROPAGATION PATHSIn order for unit models to function correctly within aplant model deviations in process variables will need tobe able to propagate through them. This means tllatprocess variable deviations need to be able to propagatefrom a units inports to its outports and from its outportsto its inports. Exceptions to this are models for thesource and outlet of the plant. Some unit models maynot propagate all deviations. For example, an open tankwill not propagate an increase in flow from its outport toits inport. However most units will propagate mostdeviations.

Equipment Model Builder identifies processvariables with no propagation path through a unit modeland provides the user with a list. This does not meanthat the model is not complete if there are processvariables with no propagation path. For example, in thecase of the open tank there is no propagation path forflow from the tanks outports to its inports. It onlymeans that the modelmiglzt be not be complete. The listis intended to act as.a memory aid for a user. This listof process variables with no propagation paths will helpto ensure that lie unit models behaviour is plausible.

CORRECfNESS TECHNIQUESCorrectness is checked for by identifying wronginformation, looking for conflicting information withinthe model and preventing the entry of illegitimateattributes into lie model. Deviations with no effect and

ACKNOWLEDGEMENTSWhile undertaking this work Claire Palmer wassupported by an EPSRCI British Gas PostgraduateStudentshipand Paul Chung was supported by a BritishGasl Royal Academy of Engineering Senior ResearchFellowship.

REFERENCESAndert, E.P.,1992, Integrated Knowledge-based System­Design and Validation for solving problems in uncertainenvironments, International Journal of Man-MachineStudies, 36 (2): 357-373.Chung, P.W.H., 1993, Qualitative Analysis of ProcessPlant Behaviour, The Proceedings of the SixthInternational Conference on Industrial and EngineeringApplications of Artificial Intelligence and ExpertSystems: 277-283.Gupta, U.M.,1993, Validation and Verification ofKnowledge-Based Systems: A Survey. Journal ofApplied Intelligence, 3: 343-363.Hoppe, T. and Meseguer, P.,1993, WTTerminology: AProposal, IEEE Expert (June): 48-55.Iri, M. et al., 1979, An Algorithm for Diagnosis ofSystem Failures in the Chemical Process. Computersand Chemical Engineering, 3: 489-493.Larkin, F.n. et al., 1997, Computer-Aided HazardIdentification: Methodology and System Architecture,IChemESymposium Series Hazards Xlll Process Safety• The Future, 141: 337-348, IChernE, Rugby, UK.Oyeleye, O. O. and Kramer, M.A. , 1988 , QualitativeSimulation of Chemical Process Systems: Steady StateAnalysis, AIChEJournal,34: 1441-1454.Palmer, C. and Chung, P.W.H., 1997, ConstructingQualitative Models, IChemEJubilee ResearchEvent, 2:725-728, IChernE, Rugby, UK.Palmer, C. and Chung, P.W.H., 1998, EliminatingAmbiguities in Qualitative Models, Computers andChemical Engineering, (Suppl) 22: S843-S846.Schut, C. and Bredeweg, B.,. 1994, SupportingQualitative Model Specification, Proceedings of thesecond International Conference on Intelligent SystemsEngineering: 37-42. :Wilcox, N.A. and Himmelblau, n.M., 1994, ThePossible Cause and Effect Graphs (PeEG) Model forFault Diagnosis -I. Methodology, Computers andChemical Engineering, 18: 103-116.

CONCISENESS TECHNIQUESEquipment Model Builder checks for conciseness bytesting for redundant information and preventing theaddition of duplicated information to the model.Deviations with no effect and deviations without causesmight be present because the information they contain isredundant. Equipment Model Builders user interfaceprevents tile addition of duplicate arcs to the model.

539.1 Computers and Chemical Engineering Supplement (1999) SJ91-SJ9.f

deviations without causes may also occur because they CONCLUSIONScontain wrong information. Verification is necessary to detect modelling errors

Conflict may occur within the component which may give rise to wrong results when the modelsmodel when there is more than one possible path are utilised. A series of verification techniques forthrough the SDG. Problems occur when one path has a signed directed graph models has been described.contradictory effect compared to another. In order to However, some modelling. errors may still remain as thedeal with ambiguities a heuristic that is commonly used expert may be unaware what information is missing oris that when there is more than one acyclic path through incorrect. As a final verification technique the modelsthe SnG the shortest path is used. A method has been should be tested in a simple system to show that they aredevised which allows the user to check that the shortest behaving in an expected manner and are satisfactory forpath within tile component model leads to correct model their intended purpose.behaviour. A file of queries to test the effects of theshortest paths within the model is prepared. This fileand the component model are given to the QUEENsystem. The user checks the output from QUEEN toensure that tile model functions correctly.

Within the unit model, deviations maypropagate to cause effects along four different types ofpath. The deviation may propagate:(1) from a boundary port to a boundary port;(2) from a fault to cause a consequence;(3) from a fault to a boundary port;(4) from a boundary port to cause a consequence.

Equipment Model Builder prepares anexhaustive list of queries to test for shortest pathsbetween all the two node combinations which mightoccur within the model. The tool tests all possiblepaths. Not all of the paths tested for may exist. As allpossible shortest paths within the model are tested for,the user is able to see where paths do not exist as wellwhere they do. The omission of an arc may mean that apath does not exist where the user might expect to findone.

The technique for verifying the shortest path isintended to be the final verification performed upon themodel. Errors which could result in missing orincorrect shortest paths such as deviations with no effectand deviations without causes are detected prior to thistest to reduce tile number of problems found . The modelat this stage should be complete and correct to the bestof the user's knowledge. The user tests tile unit modelusing the technique for verifying the shortest path. Ifany errors are found within the model the user willcorrect them and test the model again. A cycle of testingand correcting the model is carried out until tile user issatisfied with it.

The layout of Equipment Model Builders frontend interface prevents the user from enteringillegitimate attributes. For example, the user isprevented from entering an arc containing a deviationwhich propagates through a port to influence itself at thesame port, e.g. ([in,flow], +, [in, flow]).