fig3 illustrates the on - line diagnostic scheme as well as the off line training scheme . the simulator produces nearly fifteen hundred sensor measurements of which only less than 30 are being used . the feature extractor will transform these selected sensor values to produce the features . in the training scheme , these features are then compiled , formatted and compressed to an acceptable form for training the bayesian network . the bayesian network is then trained using the data produced by the training data constructor . the training process is off - line , however , in future on - site application , a semi - on - line process can be provided to periodically update the bayesian network with new data . during testing , the trained bayesian network is then installed in the bayesian fault diagnosis module . the outputs from the diagnostic module are basically the probability distribution for all query ( fault ) nodes . this result is transformed by the human machine interface module to a more acceptable display for guiding the operator . the initial version of the display is traffic - light style , where red indicates fault ( s ) with highest ( with respect to predefined threshold settings ) probability . it is possible to have more than one red or a combination with yellow , as this condition is caused by multiple faults . the human - machine interface scenario may eventually include a series of displays following the needs of the user . one display includes a graphical explanation of which observations trigger ( or do not trigger ) the diagnosis . this will allow the users to reason about and validate the diagnostic quickly . furthermore , the user can simply point and click on any parameter to get full access of its probability distributions and history . the task under consideration is to produce an early accident diagnosis system with coverage of all major fault classes . various networks have been constructed . their architectures are in between the fully engineered network ( dag ) and a pure naïve network where the query nodes are directly connected to the observation nodes . in our initial test , we have produced a smaller system for diagnosing three types of primary circuit leak in a four - loop , pressurized water nuclear reactor . specifically , we consider small leaks of the following types : ( fluid ) primary loop leaks ( psml ), pressurizer steam leaks ( psl ; through the pressurizer wall rather than through a stuck valve ), and steam generator tube ruptures ( sgtr 1 - 4 ). substantially all of these faults generate symptoms that are similar to a certain extent due to the fact that all cause a loss of coolant volume from the primary circuit . under certain aggravating conditions , such as the failure of the main coolant pump in a loop that has experienced a tube rupture , the difficulty of discriminating among these faults is exacerbated . simulated runs of one half hour in duration were generated for five sizes of each fault . the sizes chosen for the primary loop leaks and pressurizer leaks were between 0 . 3 and 10 cm 2 and for the steam generator tube ruptures were between 1 and 12 cm 2 . results on the benchmark task are shown in fig4 , and 6 . the system was always able to determine the correct diagnosis , although incorrect diagnoses did appear transiently ( for up to about three minutes ) in some cases , most commonly for the pressurizer steam leaks , which were misclassified as primary loop leaks . the criterion used to determine the system &# 39 ; s diagnosis based on the probability distribution contained in the bayesian network was that the marginal probability of the presence of the fault given the observed evidence be greater than 0 . 5 . the performance of the on the initial network on benchmark data was considered satisfactory . in the following step we are expanding the coverage of the diagnostic module to include four initial conditions ( 100 %, 60 %, 30 %, and missing loop 3 ). six additional fault types are added to the diagnostic scheme , i . e ., volume regulation system hot leak ( vrhl ), pressurizer safety valve open ( psvo ), run up run down line feedwater supply leak ( rurdlfsl ), containment steam line rupture ( cslr ), between - valve steam line rupture ( bvslr ) and before - steam - generator feedwater supply leak ( bsgfsl ). similar to the previous cases , five fault sizes are simulated for each of the new fault types . two network architectures are considered : a slightly engineered naïve network ( fig7 ) and an automatically learned general dag . experiments are done following two different schemes . in the first scheme , the network is trained with all odd size faults across selected initial conditions ( 100 % and 60 % power , and missing loop 3 ). it is then tested on the even sizes across the same initial conditions . the result is quite good . the only errors were one unclassified case and one double classified case ( classified as two faults ). in the second scheme , the network is trained with all sizes across initial condition 100 % and 60 % power , and missing loop 3 . testing is done on all sizes within initial condition 30 % power . although misclassification only occurred once , there are about 15 % cases which are unclassified . future modification and refinement is expected to improve performance . fig8 summarizes the results from the naive network and automatic learned network . it shows the performance ratio with respect to length of time required to detecting the fault and length of error time ( i . e . time in which the system incorrectly indicates the presence of any fault ). the graphical user interface ( gui ) of the complex system is a graphical representation of the information we want to convey to the operator . the gui may be a simple information display ( i . e ., no input is solicited from the operator ). this document is intended to assist discussions about the initial version of the gui as well about a more ideal version to be produced in the future . to produce the gui , we need to make decisions in two areas : the bayesian network underlying the current diagnostic systems is capable of calculating various kinds of probabilistic information . we list the most attractive possibilities below in section 2 . which should we implement ? given a choice of what information to display , how should the interface appear to the operator ? the interface for the diagnostic module should , to the greatest extent possible , have the following properties . the underlying concepts ( diagnosis names and semantics of the probabilistic information ) should be comfortable for the operator the interface should not mislead the operator into an incorrect impression of the meaning of the diagnostic findings the interface , at least at the top - level , should be as simple as possible , in order to convey information quickly and easily to the operator below we list some of the possible information that we may choose to display to the user . we make a distinction between a fault , by which we mean a condition like a steam tube rupture , and a diagnosis , which may consist of an assertion that multiple faults are present ( e . g . a steam tube rupture and a small loca ). the most straightforward approach is to display simple probability of the presence of each fault , i . e . the probability that a given fault is present independent of what other faults may be present simultaneously . if the observed evidence is e and the potential faults are f 1 through f n , we would display p ( f 1 | e ) through p ( f n | e ). the weakness of this approach is that it might be misleading for the multiple fault case . in particular , note that the most likely pair of faults is not necessarily the pair composed of the two faults that are most probable when considered alone . for example , in the figure below , in which we take the area of each set to be proportional to its probability , although p ( a )= p ( b )& gt ; p ( c )= p ( d ), it is the case that p ( c and d )& gt ; p ( a and b ). since the probability of the simultaneous presence of multiple faults decreases very fast as the number of simultaneous faults increases ( i . e ., three simultaneous faults is less - likely to occur than two simultaneous faults ), one possible solution to the weakness of the single - fault probability choice is to only display probabilities for fault pairs ( i . e . no triples , quadruples , etc .). that is , for all j and k , to display p ( f j and f k | e ). despite the fact that this approach presents more detailed information than the single - fault approach , a remaining weakness of this approach is that it still does not handle the simultaneous presence of more than two faults . the most probable diagnosis is that ordered set of values , one for each fault , which is most probable given the evidence , i . e arg min p ( f 1 and f 2 and . . . and f n | e ). the advantage of this approach is that the best simultaneous set of values for each diagnosis is displayed regardless of how many diagnoses are valid . one weakness , however , is that the magnitude of the probability of the most probable diagnosis is not very significant in the case where many explanations have similar probability . another weakness is that it is not easy to calculate or display more than one , the most probable , explanation when there are many individual diagnoses ( obviously , when there are n diagnoses there are 2 n explanations ). to make concrete the distinction between the various proposals , we provide the fig9 below . in the diagram , a , b , and c are taken to be the names of single faults . each of the atomic subsets of the diagram corresponds to one possible diagnosis . for example , the diagnosis that consists of the assertion that faults a and c are simultaneously present is labeled abc ( any diagnosis that is underlined is not present — note that the underlining is only visible when this document is viewed in printed form or viewed at high resolution on a monitor !). then the single - fault option displays only p ( a ), p ( b ), and p ( c ) ( we are neglecting conditioning on the evidence ). note that p ( a )= p ( a bc )+ p ( ab c )+ p ( abc )+ p ( a b c ), etc . the fault - pair option would display p ( a only ), p ( b only ), p ( c only ), p ( ab ), p ( ac ), and p ( bc ). note that p ( a only )= p ( a bc ), p ( ab )= p ( abc )+ p ( ab c ), etc . the most probable diagnosis option would display the probabilities of the most probable atomic subsets . if we take the size of the subsets to correspond to their probability , the three most probable diagnoses in fig9 appear to be a bc , a b c , and ab c . regardless of the choice of the three options above , it is clear that , at least implicitly , we will be displaying information about probabilities to the user . the first issue to be dealt with regarding the appearance of the gui , therefore , is how probability values will be represented . we propose three options below continuous shades ( e . g . larger probability is represented by a darker color ) small number of discrete shades ( e . g . green for ok , yellow for possible validity , red for near certainty that the diagnosis is valid ) in addition to the best current diagnosis , it may be desirable to give a partial historical record of past diagnoses from the past few minutes . this will let the operator transcend the capabilities of the diagnostic system itself by using trend information in forming his final judgement . for example , the operator could make an argument of the form “ a is the most probable diagnosis right now , but the probability of a seems to decrease over time whereas the probability of b is increasing . therefore i expect that at some future time , b will be the most probable diagnosis .” of course , such arguments may or may not be helpful , depending upon the specific properties of a particular diagnostic system . the diagrams below show how the interface might look and how the appearance should be interpreted . the purpose of these diagrams is not to advocate any one of them in particular , but rather to gain an understanding of which graphical elements and choices of information to display are most effective . they are given in no particular order . example one shows the simplest possible interface . single - fault probabilities are displayed in three quantization levels , green ( low ), yellow ( moderate ), and red ( high ). example two is a straightforward presentation of event - pair probabilities . the two simultaneous faults are arbitrarily labeled “ fault 1 ” and “ fault 2 ”. the case where only one fault is present is handled by the inclusion of a null fault , labeled “ no fault ” in the list for fault 2 . obviously , it does not make sense to allow fault 1 and fault 2 to be the same . the result is an upper - triangular matrix of probabilities . gray - level shading is used to represent the relative probability of an event pair with black being relatively high and white being nearly zero . this display technique may be weak in that under some circumstances it may be difficult for the eye to detect the difference between various levels of gray . note that the total probability for all event pairs must sum to one . the most probable pair of faults ( i . e . the most probable diagnosis ) are indicated by highlighting their names in red . example three uses every possible display element with the exception of fault - pair probabilities . the specific choices for each element are given in the list below . the most probable diagnosis is given by highlighting some combination of faults in red . the single - fault probability is displayed using color by discretization to three levels as in example 1 . furthermore , the single - fault probability is represented in words as “ unlikely ”, “ somewhat likely ” or “ very likely ” the current and two previous values of the single - fault probabilities are also displayed as bars at the extreme right . for each diagnosis , there are three bars representing ( from top to bottom ), the oldest value for the relevant probability ( in gray ), the second - oldest value ( also in gray ), and the current value ( in black ). this example displays fault - pair probabilities in a different way than example 2 . here the probability is given only for the most probable pairs . when fault 2 would have been “ no fault ” in example 2 , here the entry for fault 2 is simply left blank . each fault name has been assigned a particular color to make obvious how many times each specific fault appears on the list ( e . g . “ str loop 3 ” can be assigned dark green , “ small loca ” black , “ prim . mini - leak ” blue ). the third column displays the relative probability information in color and words as above . the fourth displays the probability information a third time as bars . in this example , the four most probable diagnoses are displayed . while not shown in this example , in principle any number of simultaneous faults could be detected and displayed with this approach . each row represents a single complete diagnosis , which may consist of an assertion that multiple faults are present . the presence of a fault is indicated by coloring the corresponding box red . at the far right , bars indicate the relative probability of each diagnosis . an indication of which observations were of the greatest importance to the network in making its diagnosis one can also display a confidence level indicator which indicates a degree of confidence that a current set of extracted features were well covered during training , wherein good coverage means a high level of confidence for a given hypothesis , and low coverage means a low level of confidence for a given hypothesis . a scheme based on probabilistic - reasoning has been developed to identify faults immediately following a reactor trip . satisfactory results were found for different fault types . the scheme is then extended and generalized to include six more faults and three additional initial conditions . the preliminary testing shows good results for testing data in the same initial condition as the training data . the above describes the preferred embodiment of the invention . various modifications and additions will be apparent to those of skill in the art and are intended to be covered by the following claims .