INFORMATION TO USERS The most advanced technology has been used to photo graph and reproduce this manuscript from the microfilm master. UMI films the original text directly from the copy submitted. Thus, some dissertation copies are in typewriter face, while others may be from a computer printer.
In the unlikely event that the author did not send UMI a complete manuscript and there are missing pages, these will be noted. Also, if unauthorized copyrighted material had to be removed, a note will indicate the deletion.
Oversize materials (e.g., maps, drawings, charts) are re produced by sectioning the original, beginning at the upper left-hand comer and continuing from left to right in equal sections with small overlaps. Each oversize page is available as one exposure on a standard 35 mm slide or as a 17" x 23" black and white photographic print for an additional charge.
Photographs included in the original manuscript have been reproduced xerographically in this copy. 35 mm slides or 6" x 9" black and white photographic prints are available for any photographs or illustrations appearing in this copy for an additional charge. Contact UMI directly to order.
Accessing the World'sUMI Information since 1938
300 North Z eeb Road, Ann Arbor, Ml 48106-1346 USA
Order Number 8812260
Expert systems application to nuclear power plant malfunction diagnosis and sensor data validation
Hashemi, Siavash, Ph.D.
The Ohio State University, 1988
Copyright ©1988 by Hashemi, Siavash. All rights reserved.
UMI 300 N. Zeeb Rd. Ann Arbor, MI 48106
PLEASE NOTE:
In all cases this material has been filmed in the best possible way from the available copy. Problems encountered with this document have been identified here with a check mark V .
1. Glossy photographs or pages ______
2. Colored illustrations, paper or print ______
3. Photographs with dark background _____
4. Illustrations are poor copy ______
5. Pages with black marks, not original copy ^
6. Print shows through as there is text on both sides of p a g e ______
7. Indistinct, broken or small print on several pages i /
8. Print exceeds margin requirements ______
9. Tightly bound copy with print lost in spine ______
10. Computer printout pages with indistinct print ______
11. Page(s) ______lacking when material received, and not available from school or author.
12. Page(s) seem to be missing in numbering only as text follows.
13. Two pages numbered . Text follows.
14. Curling and wrinkled pages
15. Dissertation contains pages with print at a slant, filmed as received
16. Other
UMI
EXPERT SYSTEMS APPLICATION TO NUCLEAR POWER PLANT MALFUNCTION DIAGNOSIS AND SENSOR DATA VALIDATION
DISSERTATION
Presented in partial Fullfilment of the Requirements for the Degree of Doctorate of Philosophy in the Graduate School of The Ohio State University
By:
Siavash Hashemi, B.S., M.S.
* % * * * * *
The Ohio State University 1988
Approved By:
Dissertation Committee: Dr. Don W. Miller AdviserS S m Dr. B. Chandrasekaran Graduate Program in Mr. Brian K. Hajek Nuclear Engineering Copyright By:
Siavash Hashemi 1988 TO MY PARENTS:
Seyed Mahmood Hashemi and Parichehr Farivar ACKNOWLEDGEMENT
I wish to express heartfelt gratitude to my advisers,
Professor Don W. Miller, Professor Brian K. Hajek, and
Professor B. Chandrasekaran, for their guidance, continuous encouragement, and patience which were so essential for the completion of this work.
I am grateful to all of the faculty and staff of the
Nuclear Engineering Department and staff of the Laboratory of Artificial Intelligence Research (LAIR) for their continuous support, help, and being there when I needed them. My thanks should go especially to the secretarial staff of the Nuclear Engineering Department.
I wish to thank my friends M. Tavakoli, D. D. Sharma,
R. Bhatnagar, J. Stasenko, T. Bylander, W. Punch, J.
Sticklin, A. Welch, J. Josephson, M. Tanner, and all other people for helping me get started, getting me going and providing timely help in dealing with the computer system problems, at all times.
The DOE Grant No. DE-AC01-86NE37965.M001, NSF Grant No.
CBT-8400840, and The Ohio State University provided the basic support for this work and several other members of the research team whose inputs were very valuable. I wish to thank my family in Iran and the US for their moral and financial support and faith in me. Without them,
this work would not have been possible.
I wish to thank Ken Ross and David Mishelevich of
IntelliCorp for allocating the necessary time and machines
for me to finish this dissertation.
Last, but not least, I wish to give special thanks to my dearest friends, M. Ighani, D. Orender, C. D. Cross, and
M. Tozer for their love, support and cheering me up when I
needed it the most.
I will never forget this whole experience or any of the
aforementioned people. The last five years were amongst the best years of my life. Thank you everyone. VITA
April 14, 1959 Born - Tehran, Iran
1980 B. S. Nuclear Engineering The University of Oklahoma Norman, Oklahoma
1982 M. S. Nuclear Engineering The University of Oklahoma Norman, Oklahoma
1982 - 1987 Graduate Research Associate The Ohio State University Columbus, Ohio
1987 - Present Senior Knowledge Systems Engineer and Program Manager IntelliCorp MountainView, Clifornia
PUBLICATIONS
Research and Technical Papers
S. Hashemi, B.K. Hajek, D.W. Miller, "An Expert System for Sensor Data Validation and Malfunction Detection", presented and Published in ANS Topical Meeting on Artificial Intelligence and other Innovative Computer Applications in Nuclear Industry Proceedings, Snowbird, Utah, Sep 1987.
B.K. Hajek, J.E. Stasenko, S. Hashemi, "The Structure of an Expert System to Diagnose and Supply Corrective Procedures for Nuclear Power Malfunctions", presented and Published in ANS Topical Meeting on Artificial Intelligence and other Innovative Computer Applications in Nuclear Industry Proceedings, Snowbird, Utah, Sep 1987.
D.W. Miller, S. Hashemi, B.K. Hajek, D.D. Sharma, "The Introduction of Artificial Intelligence In A University Research Program in Nuclear Engineering", UPCAEDM Conference Proceedings, Columbus, Ohio, June 1987.
S. Hashemi, W.F. Punch, B.K. Hajek, "CSRL: A Language foe Malfunction Detection and Sensor Data Validation", EPRI Conference on Expert Systems Applications in Nuclear Power Plants Proceedings, Invited Paper, May 1987.
iv B.K. Hajek, S. Hashemi, D.W. Miller, "Expert Systems Applications to Fault Diagnosis and Procedure Synthesis", EPRI Conference on Expert Systems Applications in Nuclear Power Plants Proceedings, Invited Paper, May 1987.
S. Hashemi, D.W. Miller, B. Chandrasekaran, B.K. Hajek, "Expert Sytem Application to Plant Diagnosis and Sensor Data Validation", The Sixth Power Plant Dynamics, Control and Testing Symposium Proceedings, Knoxville, Tennessee, April 1986.
B.K. Hajek, S. Hashemi, D.D. Sharma, B.K. Chandrasekaran, D.W. Miller, "Artificial Intelligence Enhancement to Safety Parameter Display Systems", International Topical Meeting on Advances in Human Factors in Nuclear Power Plants Proceedings, Knoxville, Tennesse, April, 1986.
S. Hashemi, D.W. Miller, et al., "A Small Inherently Safe Reactor Without ECCS", ANS Winter Meeting Proceedings, Nov. 1985.
S. Hashemi, "Artificial Intelligence Techniques in Diagnosis of Nuclear Power Plants",'22nd Annual ANS Midwestern Student Conference, March 1985.
"Reports"
S. Hashemi, B.R. Reed, R.O. Wooten, S.L. Nicolosi, "Design and implementation of an Expert System to Assist Source Term Code Package Users", Submitted to USNRC, Report form Battelle Memorial Institute, October, 1986.
K. Ramakrishna, B.K. Hajek, S. Hashemi, "Expert Systems Applications to Maintenance Scheduling and Spare Parts Inventory", Submitted to Combustion Engineering, Inc., Aug. 1984.
S. Mahalingam, M. Tanner, J. Ruparel, S. Hashemi, "A Report on Expert Systems Applications to Engineering Problems", Submitted to Combustion Engineering, Inc., Sep. 1983.
FIELDS OF STUDY
Major Field: Nuclear Engineering Studies in: Nuclear Instrumentation, Prof. D. W. Miller Expert Systems Applications, Prof. B. chandrasekaran Nuclear Operations and Safety, Profs. B.K. Hajek and T. Aldemir
v TABLE OF CONTENTS
ACKNOWLEDGEMENTS ii
VITA iv
TABLE OF CONTENTS vi
LIST OF FIGURES viii
LIST OF SYMBOLS X
CHAPTER PAGE
I. INTRODUCTION 1
1.1 Preface 1 1.2 Research Objectives 2 1.3 Background 3 1.4 Dissertation Organization 5 1.5 The Safety Parameter Display System Concept 6 1.6 Expert Systems; What are They and What Can 9 They Do 1.7 Literature Review 12 1.7.1 Diagnostic Systems in NPP Domain 12 1.7.2 Sensor Validation in NPP Domain 20 1.8 Summary 35
II. NUCLEAR POWER PLANT MODEL DESCRIPTION 36
III. DIAGNOSIS AND SENSOR DATA VALIDATION IN CSRL 45
3.1 Diagnosis in CSRL 45 3.1.1 Hierarchichal Structures 45 3.1.2 Problem Solving Strategy 47 3.1.3 Confidence Factors 53 3.2 Sensor Data Validation Technique 56 3.2.1 Introduction 56 3.2.2 Current Technology in Sensor Validation 58 3.2.3 Proposed Technique 60 3.3 Summary 75 IV. CSRL MODIFICATIONS AND DATABASE DESCRIPTION 76
4.1 Components of the Database 76 4.2 Different Query Functions 79 4.3 How the Questions Are Asked And 82 Where the Answers Stored
V. MODEL VALIDATION AND VERIFICATION AND SAMPLE RUNS 85
5.1 Expert System Model Validation 85 5.2 Conventions for Running This Expert System 88 5.3 Sample Runs 91 5.4 Summary 107
VI. RECOMMENDATIONS AND FUTURE PLANS 109
VII. SUMMARY AND CONCLUSIONS 114
APPENDICES 119
A. Sample Runs 120 B. Code Printout 140 C. Modifications of CSRL and Documentation 199 of Changes
LIST OF REFERENCES 206
vii LIST OF FIGURES
Page
Figure 1. Parity Space with Decision Regions 29
Figure 2. Typical Analytical Measurement Calculator 32
Figure 3. Typical Decision-Estimator 32
Figure 4. An Example of Signal Validation Flow 33 Diagram Using Analytical redundancy
Figure 5. Reactor Coolant System Model 38
Figure 6. Hierarchy of Malfunction Specialists 49 in the Simplified BWR
Figure 7. Example Knowledge Group 51
Figure 8. Example Specialist 54
Figure 9. Knowledge Group Organization within 54 Specialists
Figure 10. An Example of a Modified Knowledge Group 63
Figure 11. An Example of a Modified Specialist 65
Figure 12. Suspicious Sensor List 66
Figure 13. An Example of Normal Expectation Data Pattern 68
Figure 14. Validation Routine for SRV Position 70
Figure 15. Sensor Validation Routine Block diagram 73
Figure 16. The Sensors Lattice 74
Figure 17. Instance Variables of Reactor Pressure 77
Figure 18. Expected Symptoms of SRVStuckOpen Malfunction 87
Figure 19. Loss of Feedwater Heaters Accident 94 Before Sensor Data Validation
viii LIST OF fIGURES (contd.) Page
Figure 20. Loss of Feedwater Heaters Accident 96 After Sensor Data Validation
Figure 21. Schematic Diagram of a Feedwater Heater 97
Figure 22. Inadvertent Closure of MSIVs and Open SRVs 99 Before Sensor Data Validation
Figure 23. Inadvertent Closure of MSIVs and Open SRVs 100 After Sensor Data Validation
Figure 24. Inadvetent Initiation of ECCS 103 Before Sensor Data Validation
Figure 25. Inadvertent Initiation of ECCS 104 After Sensor Data Validation
Figure 26. Failure of Validation Routines 106 LIST OF SYMBOLS
AMC Analytic Measurement Calculator BOP Balance Of Plant BWR Boiling Water Reactor CF Confidence Factor CFMS Critical Functions Monitoring System CSF Critical Safety Functions CV Class Variable CV Control Valve DASS Disturbance Analysis and Surveilance System D-E Decision-Estimator ECCS Emergency Core Cooling System ERF Emergency Response Facility FW Feedwater IV Instance Variable KBS Knowledge Based (Expert) System LAIR Laboratory of Artificial Intelligence Research LOCA Loss Of Coolant Accident LPU Least Plant Unit MFP Main FeedWater Pump MSIV Main Steam Isolation Valve MSL Main Steam Line PWR Pressurized Water Reactor RHR Residual Heat Removal SDL Suspicious Data List SPDS Safety Parameter Display System SRV Safety Relief Valve SSL Suspicious Sensors List TMI Three Mile Island TSV Turbine Stop Valve USAR Updated Safety Analysis Report US-NRC The United States Nuclear Regulatory Commision
x CHAPTER I
INTRODUCTION
1.1 Introduction
Nuclear power plant operation and monitoring in general is a complex task which requires a large number of sensors, alarms, and displays. At any instant in time, the operator is required to make a judgement about the state of the plant and to react accordingly. During abnormal situations, operators are further burdened with time constraints. The possibility of undetected malfunctions in the
instrumentation channels adds to the complexity of an operator's reasoning task.
Failure of human operators to cope with the conceptual complexity of abnormal situations often leads to more
serious malfunctions and further damage to the plant (TMI-2 as an example). During these abnormalities, operators rely on the information provided by the plant sensors and
associated alarms. Their usefulness, however, is quickly
diminished by their large number and the difficult task of
interpreting and comprehending the information provided by
them. The need for an aid to assist the operator in
interpreting the available data and diagnosing the problems
is obvious [1].
1 2
One form of operator aid is the Safety Parameter
Display System (SPDS)[2]. These display systems are data collection devices that concentrate on the most critical plant variables, such as reactor power and water level, suppression pool loading (in BWRs), steam generator levels
(in PWRS) and containment pressure. The SPDS only provides a display of these parameters in an integrated fashion. The major task of diagnosing malfunctions is still the
responsibility of plant personel.
Recent work at The Ohio State University Laboratory of
Artificial Intelligence Research (LAIR) and within the
Nuclear Engineering Program has concentrated on the problem
of diagnostic expert systems applied to the nuclaar power
plant domain. There has also been concern about diagnostic
expert system performance when using potentially invalid
sensor data. That is, we have been developing expert systems
that can perform diagnostic problem solving despite the
existance of some conflicting data in the domain. This work
has resulted in enhancement of a programming tool, CSRL [3,
4], that allows domain experts to create a diagnostic system
that will be, to some degree, tolerant of inaccurate data
while performing diagnosis.
1.2 Research Objectives
The objective of this research is to develop a
knowledge-based framework to perform diagnosis and sensor
data validation in a Nuclear Power Plant (NPP). The 3 development: of the framework is based on the task of diagnosis as a classification type problem solving and sensor data validation by violation of normally expected symptoms of detected malfunctions. To meet the objective, the following tasks were performed:
1. An analysis of an expert operators diagnosis of an
abnormal situation, and representation of this problem
solving as hierarchical classification.
2. A methodology to enhance current sensor validation
techniques in the NPP domain.
3. Enhancement to a high level language for Conceptual
Structures Representation Language (CSRL) which
provides a framework for knowledge representation in
knowledge-rich domains, and
4. A representation of the above tasks by several
examples.
1.3 Background
As was mentioned in Section 1.1, the Safety Parameter
Display System in general, only provides a display system to the operator, and the tasks of diagnosis and execution of corrective procedures are still left to the operator. For this project, a design of an expert system operator aid to assist nuclear power plant personnel in plant malfunction diagnosis has been completed. This expert system has been developed by using CSRL in a LOOPS environment. 4
As was shown in a previous study [5], malfunction diagnosis and sensor signal validation tasks are integrated counterparts, and one cannot be accomplished in an efficient way without the other. Because of this, CSRL was enhanced and modified to enable the developed expert system to detect unreliable sensor data, relying on the violation of the normal expectations of malfunctions as another source of redundancy. This level of redundancy is proposed to be in addition to conventional sensor hardware redundancies currently implemented in nuclear power plants.
This method of malfunction diagnosis uses basic parameters as input data. By relying on basic parameters, the diagnosis can start before an alarm set point is violated. This will give the operator an extra amount of time to respond to plant abnormal transients. This may lead to avoiding unnecessary reactor trips thereby increasing plant availability and potentially saving millions of dollars throughout the life of a plant.
In addition to diagnosis, this expert system is capable of detecting common cause failures, as well as instrumentation line calibration errors and drifts, as will be discussed in later chapters. The currently implemented sensor validation routines are not capable of detecting the above faults, and are only aimed at gross failures, such as shorts, grounds, transducer failures, or loss of power supplies. 5
In this dissertation, the design and implementation of such an expert system is discussed, and several examples are presented. The proposed expert system operator aid is designed to complement the currently existing safety parameter display systems, and to provide additional help to the plant's operating staff.
1.4 Dissertation Organization
The issues encountered during the past three years are discussed in this dissertation. In this chapter, a review of the SPDS concept is made. This review is followed by a brief description of expert systems and their applicability to the nuclear power industry. Next, a literature review of existing diagnostic and sensor validation methodologies is presented.
In the second Chapter, the model of the nuclear power plant used as the basis of the design of the expert system for diagnosis and sensor data validation is presented.
The third Chapter presents the methodology of diagnosis in general and modifications to the existing programming shell in order to making it appropriate to diagnosis in this domain. Also in this chapter, sensor data validation in
CSRL is described. In Chapter four, the required database is described. Model validation technique and sample runs are presented in Chapter five.
Recommendations and future development plans are discussed in Chapter six, and finally, the summary and 6
conclusions are presented in Chapter seven.
1.5 Safety Parameter Display System (SPDS) Concept
The accident at Three Mile Island (TMI) and subsequent
investigations have demonstrated the need for improving the presentation of plant process information to operators [2,
6]. This is especially true when a nuclear power plant undergoes a major transient. A major transient, such as the
one at TMI, may develop slowly over an extended period of time and can potentially challenge several safety functions.
Thus, during a major transient, a reactor operator is
required to monitor and process large amounts of data to
ascertain the operational status and safety of the plant.
A detailed analysis of the TMI incident identified
necessary improvements to the Emergency Response Facilities
(ERFs) which are designed to respond to an accident at a
nuclear power plant [2]. This analysis concluded the need
for modifications and enhancements to the ERFs. At the
present time, these modifications and enhancements are
mostly incorporated in existing plants.
Another requirement set forth by the United States
Nuclear Regulatory Commision (US-NRC), as a result of the
TMI accident, was to improve the data display facilities.
The concept of the Safety Parameter Display System (SPDSs)
was introduced in NUREG-0696, and its conceptual function
was discussed in 1981 [6]. The SPDS concept and its
functionality is briefly discussed in this section. 7
The operational complexity of modern engineering systems often exceeds the capabilities of human operators.
Malfunctions and failures often contribute to the failure of the human operator to cope with the conceptual complexity of the problem. Examples from air transportation, military systems, the petrochemical industry, and the nuclear power industry are well known.
System malfunctions often require capabilities to diagnose and correct the problem under severe time constraints using data from sensors which monitor the state of the system. While these sensors provide necessary and useful data, their utility is quickly diminished by their large number and the extremely difficult task of interpreting and comprehending the information provided by them. The need for an operator aid to assist in
interpreting the available data in problem diagnosis and recommendation for corrective actions was apparent during the Three Mile Island Unit 2, Incident [2],
In the last decade, the problem of designing operator aids has received considerable attention in the nuclear power industry. Various approaches are being pursued to assist the operator in dealing with complex situations.
Following the TMI-2 incident, the nuclear power industry has developed the Disturbance Analysis and Surveilance System
(DASS) [7, 8], Safety Parameter Display System (SPDS),
Critical Function Monitoring System (CFMS) [9], and various 8
sensor validation routines [10].
The primary function of the SPDS is to assist control
room operational personnel make quick assessments of the plant safety status. The minimum set of functions to be displayed by the SPDS is [2]:
1. Reactivity Control,
2. Reactor Core Cooling and Heat Removal from Primary
System,
3. Reactor Coolant System Integrity,
4. Radioactivity Control, and
5. Containment Integrity.
The SPDS in general, provides indications of plant parameters (or derived variables) representative of the
safety status of the plant, which aids the operator in the
rapid detection of abnormal operating conditions significant
to plant safety. Additional enhancements to the SPDS have
been suggested in order to maximize its benefit [11]. Some
of these enhancements are trend analysis and frequency
domain analysis packages and limited sensor validation.
The CFMS improves the quality of the information by
presenting to the operator information from all sensors.
Both the SPDSs and CFMSs are installed in many nuclear power
plants in United States.
The DASS is by far the most ambitious of the three
systems and attempts to provide the operator critical
information on how the plant is going to behave in the near 9 future, so that he can avoid an emergency situation. DASS, in my opinion, is an elementary artificial intelligence program and involves generation of apriori', extensive cause-consequence trees for every conceivable malfunction or transient. The difficulty of capturing every conceivable malfunction is obvious.
Existing implementation of DASS can provide prealarming information for a few selected scenarios and are still in the research stage.
These systems provide prealarming and diagnostic aids to the operator. Validity checks on sensor data are usually a part of these systems. However, due to lack of enough sophistication in these routines, there are some modes of sensor failures that can potentially remain undetected.
These modes are the common cause failures and instrumentaion calibration drifts and will be discussed later.
1.6 Expert Systems: What Are They and What Can They Do
A commmon goal within the nuclear industry has been to advance the state-of-the-art to provide safer, cheaper, and more reliable electric power. The state-of-the-art includes the underlying physics and engineering principles as well as expertise. There has been an enormous sum of money spent in the power industry to build tools that reflect these principles. Whereas, the tools, such as the sophisticated computer codes, can be replicated rather cheaply the skills to apply them cannot. We are increasingly stymied in 10 efforts to move the state of the art forward by the fact that expertise remains a limited commodity.
Expert systems technology, using Artificial
Intelligence (AI) techniques, is a promising way to capture skills and knowledge from experts. It may be used to enhance human capability for reasoning and diagnosis in various engineering and operating functions of a nuclear power plant.
Two questions arise regarding Expert Systems: (1) What are they, and (2) What can they provide to nuclear power plant operators. These questions are addressed in the following paragraphs.
In general terms, expert systems are computer-based programs that use AI techniques to encode and decode knowledge and judgement of valuable experts. AI is a part of computer science that investigates symbolic, non- algorithmic reasoning processes, for use in machine inference. Such modeling can be fruitful when one considers human intelligence, which is predominantly symbolic manipulation in nature, and which uses little or no numerical methods in exercising the cognitive process. The expert system of interest in the context of this study embodies a specific type of expertise or knowledge and hence the often used name of Knowledge-Based Expert System.
In considering how to construct an expert system, such that the human beings can efficiently relate, a morphology 11
similar to the expert systems of the human mind is useful.
One of the models of the construct of the human mind seems to be similar to a society of many experts and sub-experts
and is often in the form of a hierarchical corporate
structure. Each of these experts holds a form of knowledge
of a specific domain of expertise and procedures allowing
the distribution of that expertise to the other experts.
When a problem requiring resolution is posed to the human mind, control is transfered to that expert most
capable of solving the problem. For each case, each expert
at higher levels of the hierarchy will decide if its
subsequent nodes, at lower levels, can provide a detailed
answer to the problem. If the answer is negative then the
problem is passed on to the next expert on the same level
until one is found that can provide the solution by invoking
subsequent nodes further down the hierarchy of the experts.
However, if the solution of the problem cannot be provided
by the experts, then the system can propose a probable
solution and a related confidence factor. It also can
decide to make another attempt by requesting more
information from the outside world, or it can suggest that
an incorrect piece of evidence has been provided.
It readily can be seen that to successfully achieve a
stable plant condition during the occurence of an adverse
event, especially with a potentially simultaneous occurence
of multiple failures of success paths, requires considerable 12 mental activity from the operator. It is therefore no surprise that several attempts have been made within the nuclear industry to provide so-called monitoring and diagnostic aids to the operators. Most of these aids, identified as safety parameter display systems, are intended to provide the operator with a more integrated plant status display from which he can further perform diagnosis.
In the next section, an overview of the current work in plant diagnosis and sensor data validation is done.
1.7 Literature Review
The literature review is divided into two subsections in the following manner. In the first subsection, a selected number of the published results in the area of expert system diagnosis is summarized. In the next, papers in the area of sensor data validation are reviewed.
1.7.1 Literature Review of Diagnostic Systems Using Expert Systems
A Critical Function Expert System for Nuclear Power Plants [12]
In this paper the concept of Critical Functions (CF) and CF maintenance by using an Expert System is discussed.
A Critical Function is generally considered as a function that must be accomplished by means of a group of actions undertaken to reach a designated goal target. In a nuclear power plant, in terms of operations, efficiency, and sefety, a number of critical functions are defined. In the 13 case of safety, the critical functions are: Reactivity
Control, Reactor Coolant System Inventory Control, Reactor
Coolant Pressure Control, Reactor Core Heat Removal,
Containment Pressure/Temperature Control, and Containment
Isolation.
The critical functions must be maintained continuously to assure the target goal and this become most important during an abnormal event. The actions to be taken to accomplish the critical functions are identified as primary and alternate success paths, which could be fully or semi automated. Even though the automation of these procedures
is desired, in nuclear power plants only those which require a response time faster than the operator reaction time are automated.
The paper discusses the Critical Function Expert System
(CFES), which is an outgrowth of the Critical Function
Monitoring System (CFMS). The CFES is based on the concept of critical functions and includes such features as automatic best-success path selection.
This expert system is built in the form of a hierarchical structure as a society of experts and
subexperts. Each of these experts holds the knowledge of a
specific domain of expertise, in the form of IF ... THEN ...
ELSE ... rules to model the various stages of the operator1s
cognitive process. 14
CFES has four subparts as follows:
1. Symptomatic Event Logic to correlate a symptom set to
an event oriented recovery procedure.
2. Critical Fuction Status Logic to identify the status of
the critical safety functions.
3. Critical Function Successpath Availability Logic, to
identify which successpaths are available to maintain a
critical function.
4. Critical Function "Best-Estimate" Successpath Selection
Logic, to identify which successpath can best be
initiated to accomplish selected critical function.
As can be expected, if any abnormal situation arises, these four logical states are evoked and eventually, the critical function in danger and the best successpath to recovery are identified and flashed on the screen.
This is an interesting paper in many ways. In this paper Critical Function Monitoring System technology is utilized and improved. This system can be assumed to be the closest thing to an AI system. In this paper, it also is suggested that expert systems are another step towards improvement of current control room design. Finally, this paper suggests that eventually these expert systems will be hard-wired in the control room panels. 15
Application of Knowledge-Based Systems to the Reactor Operation [13]
In this paper, the basic idea and the possible role of knowledge-based systems in the nuclear industry is discussed.
Expert systems in AI are the systems which use problem solving strategies in well defined areas of specialized knowledge to show a performance compatible to a human expert. The reason for using expert systems is based on realization that in knowldge-rich domains, problems can be solved efficiently by:
1. Using domain specific knowledge,
2. Organizing the knowledge so as to tune its structure to
the particular problem,
3. Using the structured knowledge in a manner to achieve a
high performance for the particular problem.
The idea of a society of specialists and a hierarchical order of specialists and subspecialists is discussed.
Expertise of each specialist is in the form of rules. Types of rules are defined as: Confirmatory Rules, Exclusionary
Rules, and Recommendation Rules.
The ideas of separation of identification of a disturbance and the synthesis of corrective procedures are distinguished as diagnostic and predictive reasonings.
Diagnostic problems require the state of the plant to be determined as belonging to a set of predefined 16 classificatory states. This involves seeking the causes of the phenomena. The basic reasoning process is one of searching the state space of classification based on the knowledge of the causal association between the observable symptoms.
The reasoning involved in the synthesis of corrective action requires the capability to reason about the effects of a given action under consideration. In this process, a corrective action based on the diagnostic reasoning should be analyzed for the final plan. Thus, the reasoning for a predictive task is central to synthesis of corrective actions.
A CSA Model-Based NPP Consultant [14]
The purpose of this paper is to investigate Common
Sense Algorithms (CSA) and expert system technology in representing knowledge of nuclear power plants for use in malfunction diagnosis.
The common sense algorithms are reviewed and illustrated with a CSA model of a nuclear power plant subsystem. Also, the inference rules and control strategies of a prototype computer-based consultant that uses the knowledge base is described and a sample consultation involving the TMI-2 accident is presented.
First, what are the common sense algorithm networks?
The CSA representation for physical mechanisms consists of four events and nine relations. The events are: Actions, 17
Tendencies, States, and Statechanges. The nine relations
(or links between events) are: Oneshot Causality,
Repetitive Causality, State Coupling, Equivalence,
Antagonism, Enablement, Threshold, and Rate Confluence. The
first five of the above relations can be "gated" by
conditions that must hold for the causal relationship to
continue to hold. By using these four events and nine
relations, any state of a given system, as well as
subsystem, components, or subcomponents, can be described.
A CSA network will consist of these descriptions as well as alarms (such as radiation level higher than normal,
the component-alarms, and etc.) and their relationships.
The claim is that by using this network, along with
diagnostic and control rules, one can detect and easily
correct the faults.
In this system, a forward chaining control strategy is
used and it can diagnose four types of accidents: LOCA,
Loss of secondary Coolant, Steam Generator Tube Rupturem and
Spurious Actuation of the Safety Injection.
One of the interesting features of this system is that
it can "order tests". When a causal event is infered which
has immediate but not verified symptoms, the control
mechanism asks the operator to verify them in order to
further confirm the inference. Thus, it is claimed that
CSA networks can handle seemingly conflicting observations
and give a clear interpretation of the data. 18
REACTOR: An Expert System for Diagnosis and Treatment of Nuclear Accidents [15]
REACTOR is an expert system developed by EG & 6 Idaho,
Inc., which assists nuclear power plant operators in diagnosis and treatment of plant accidents. This paper covers the reasons why expert system technology may prove valuable in the control rooms.
The purpose of REACTOR is to monitor a nuclear reactor facility, to detect deviations from normal operating conditions, to determine the significance of the situations and to recommend an appropriate response. It performs these tasks by operating on a large knowledge base with a procedure similar to Winston's animal classification system
[16] that reasons both forward and backward. In short, the system reasons forward until a conclusion is reached. If not enough information is available to reach a conclusion, then the system reasons backward to determine what information it needs to know. REACTOR then will query the plant instruments (or the operator) in order to fill the gaps in its knowledge.
The knowledge of REACTOR is of two types i event- oriented, and function oriented. Event oriented knowledge describes the expected behavior of the reactor systems under known accidents, and are gathered from past experiences.
This type of knowledge is claimed to be good for identification of accidents which would fit the given 19 pattern. This knowledge is coded in the form of production rules (IF ... THEN ... ELSE ...).
The function oriented knowledge is concerned with the configuration of the reactor systems and how its components work together to perform a given function. These strategies are used if the event-oriented approach cannot identify the accident. In this approach, a response tree is used. (A response tree is a diagram which shows the successpaths which can be used to provide a given safety function). This is similar to the Critical Function Monitoring System
(CFMS), discussed earlier.
This system incorporates four types of events, Loss of
Feedwater, Steam Line Break, Steam Generator Tube Rupture, and LOCA.
A Summary of the Artificial Intelligence Applications at the HFIR [17]
In this paper, an expert system for diagnosis of the
High Flux Isotope Reactor (HFIR) is described.
The method of diagnosis of this system is as follows.
This expert system has about fourteen key parameters as input data. The "normal signature" of the reactor is collected for a period of time. Any deviation from this normal plant signature is assumed to be a malfunction.
Malfunction identification is achieved by comparing the current signature with the different malfunction signatures available. 20
In my opinion, this method of diagnosis is inefficent, if not impossible. The reason for this ineficiency is the large number of malfunction patterns, and the combinations of patterns, that are needed to be stored and eventually, has to be searched to find the appropriate one.
1.7.2 Literature Review of the Sensor Validation Techniques
The recent work in the area of sensor data validation and conflict detection in nuclear power plants is described in this subsection. In order to understand the reasons for the limitations of the current techniques and realization of the need for improved sensor validation, a summary of current techniques that are utilized in the operating power plants, are presented in the following paragraphs.
Current Techniques*
There have been several sensor signal validation routines incorporated in currently operating nuclear power plant instrumentation. These routines are: "like" sensors comparison, limit checking on trends and absolute values, auctioneering amongst like sensors, instrument loop integrity checking, and live zeros and ceilings. A brief description of each routine follows.
* Adapted from: Deyst, J.J., Kanazawa, R.M., Pasquenza, J.P., "Sensor Validaton: A Method to Enhance the Quality of the Man/Machine Interface in Nuclear Power Stations", IEEE Trans, on NS, Vol NS-28, No. 1, Feb 1981. 21
"Like11 Sensor Comparison
This technique involves comparing sensors that measure equivalent or symmetric process parameters. Sensor redundancy is required and a definite identification of an incorrect sensor can only be made when at least a 3-fold redundancy exists. In the past, these comparisons have been done manually (i.e., by a plant operator using control room indicators). However, more recently they have been automated in digital computer based systems.
Limit Checking
This technique involves comparing sensor outputs to fixed limits (either absolute limits or rate-of-change limits). The technique does not require sensor redundancy and can identify a sensor or instrument loop that has been subjected to a rather gross failure. This type of checking has been incorporated into many digital computer systems and is particularly useful when normal or expected sensor outputs fall well within the range of the total sensor output.
Live Zeros and Ceilings
This technique is similar to limit checking except that the sensor/instrument loop output is scaled to eliminate the possibility of maximum and minimum voltages occuring during the normal operation. This method is particularly useful when the normal sensor response covers a large portion of 22 the total sensor range. The identification of shorts,
ground, or open circuits is facilitated with this approach.
The technique has been incorporated and automated into many
of the newer instrument systems.
Auctioneering
Although not strictly a sensor data validation technique, but a control technique, auctioneering of sensor
signals for use by automatic control, protection and monitoring systems has been used for many years. This method involves selecting the highest and/or lowest signal
level among two or more equivalent signals, prior to processing them through the system algorithms or logic.
This technique is employed as a way of reducing the
likelihood of a system responding in an undesirable manner
(i.e., this is one of the "fail-safe” features of most
reactor protection systems). Of course, this technique
cannot by itself identify which sensor is failed nor replace
or ignore the failed sensor if it happens to fail in the
direction that satisfies the auctioneering logic. As such,
the availability or operability of systems is only
deminished by this method, even though, it does enhance the
overall plant safety.
Instrument Loop Integrity
This technique is used to check the quality of the
entire instrument loop by checking certain presumably 23 stationary characteristics of the loop. The primary item checked in this procedure is the loop resistance.
Application of this method is not as widespread as the others discussed above and has been mainly used to check instruments that are not readily accessible and which are susceptible to subtle abnormalities that are not readily detectable by other techniques. This system does not require redundancy and can identify which instrument loop is not operating normally. However, there are two drawbacks to this technique. They are: (a) All failure modes of the instrument loop cannot be detected by this method, and (b)
Application of this technique usually requires removal of the instrument line from operational status.
While these routines are capable of improving the system safety, availability, and operability, they have certain limitations that curtail their effectiveness. These limitations are as follows [18]:
1. Sensor redundancy is required in most techniques and at
least 3-fold redundancy is needed to identify the
incorrect sensor. System availability using these
techniques is enhanced by adding more sensors which is
expensive, especially in retrofit and safety related
cases.
2. These techniques use only observable parameters and
generally rely on those measurements that have
symmetric counterparts (if not redundant measurements). 24
No benefit is taken from inferences based on sets of
measurements nor are the techniques readily adaptable
for cases in which process asymmetries exist.
3. The techniques are oriented towards identifying gross
failures (shorts, grounds, etc.). Subtle or long-term
failures, such as decalibrations, drifts, etc., are not
readily detectable.
4. The techniques cannot identify common cause induced
failures that affect redundant and/or symmetric
sensors.
The above limitations can be overcome by use of advanced signal validation techniques. These techniques, as will be seen in this chapter and in Chapter 3, can make a substantial contribution to improving system availability and operability. Furthermore, the increased validity of sensor data enables the plant operator to make more valid decisions and thus, to increase safety of plant operation.
Sensor Failure Detection and Estimation [19]
In this paper, several current methods of sensor signal validation are discussed. The signal validation is achieved through two methods as follows:
1. Static Methods which are referred to when the sensor
performance is not correlated with system dynamics.
These methods are like-sensor comparison, limit
checking, and instrument-loop-integrity checking.
These methods have previously been described. 25
2. Dynamic Methods - which use signal analysis, either
empirically or in conjunction with dynamic system
models. Some of the empirical approaches use noise
analysis and others use time series modeling.
In this paper, a method is proposed to validate sensor signals based on the signals acquired from a set of sensors that is different from the one under study. That is, relying on unlike sensor parameters to validate a sensor signal. These methods are described below.
Empirical time-series models are used for both system dynamics representation and sensor fault magnitude estimation. The objective is to make the dependency of the fault detection algorithm less sensitive to the variations in the parameters of the model. This is accomplished by adaptively constructing multivariative data-driven models of the signals representing a subsystem of the reactor in the time domain. Data driven means that the system models are data dependent. This technique has the following features:
1. A subsystem of the reactor is considered for analysis,
2. The sensor output of interest will be related to other
signals so that a good time-series model can be
developed,
3. A dual-hypotheses testing procedure is used; the
prediction of the sensor output during the tracking
phase is compared with its prediction during the
learning phase. A decision about the sensor anamoly is 26
made by evaluating the liklihood ratio and comparing it
aginst a treshold based on the false alarm rate, and,
4. If the test indicates anamoly in the sensor behavior,
the sensor error is estimated by appropriate
measurement models. Faults, such as sensor bias,
excess noise, and changes in response-time
characteristics, can be estimated.
This method can be used for estimating the values of more than one sensor at a time.
Upadhyaya in this paper has discussed the response time degradation monitoring of thermocouples as a possible method of signal validation. It is argued that normal fluctuations of the signals forom temperature sensors can be used to monitor their response time characteristics. In their approach, a univariate autoregressive model of the random signal is developed and the sensor impulse response is obtained. This model is then used to estimate the step response of the sensor. Due to accuracy problems, this model can only be used for monitoring changes in the sensor time costants. For higher accuracies, an external perturbation test must be performed.
One of the problems with the two above methods is that an appropriate dynamic model describing the relationships among measured signals and nonmeasured state variables must be available and a measurement-system is required to represent the sensor outputs. 27
Sensor Validation: A Method to Enhance the Quality of the Man-Machine Interface in Nuclear Power Stations [20]
In this paper, it is argued that sensor data validation is a prerequisite of Disturbance Analysis an Surveillance
Systems (DASS). The central part of DASS in aiding the operators of nuclear power plants in making correct decisions, is the single, validated database, upon which the
DASS modules operate upon.
In this paper, the current technology in sensor validation is discussed. These methods are: (1) Like sensor comparison, (2) Limit checking, (3) Live zeros and ceilings,
(4) Auctioneering, and (5) Instrument loop integrity checking. The limitations of the current technology is described in this paper (Re: Chapter 4) and benefits of improved sensor validation are discussed.
In this paper, it is discussed that the sensor validation must be done by attempting to identify unacceptable performance of specific sensors and terminating the use of their output data and thus, the database is maintained valid by protecting it against ingesting invalid data.
This is achieved by making use of redundant data. The redundant data is of two forms:
1. Directly redundant sensor data, when more than one
sensor is measuring the same variable. Thus, direct
redundancy implies replication of identical sensors. 28
2. Analytical redundant sensor data, when the physical
relationships between variables are recognized and used
in providing additional redundant sources of
information.
In the proposed method of signal validation, all of the relevant sources of information to each sensor are collected. In a typical nuclear power plant, there is an abundance of such direct and indirect data. Once all of the sources of data and their relationships are identified, then fault identification must be accomplished. The identification process is based on recognizing the inconsistencies between redundant information sources.
The visibility of such inconsistencies are enhanced by eliminating the underlying measured quantity from the data.
This is accomplished by creating linear relationships between the sensed variables which are called parity equations. The formed parity equations contain the sensor errors, including the ones which may result from a failure, and do not contain the underlying measured variable.
The number of the parity equations is the same as the number of excess sources of information that are available.
As an example, if there are three measurements of the same variable, then there exists two parity equations.
The space spanned by the parity equations is called the parity space. The variables generated by the parity equations form the coordinate system of a vector which lies 29 in the parity space. For the example shown in Figure 1, the parity space is two dimensional. The magnitude of this vector is a measure of the disparity between the various redundant sensor outputs.
Under normal circumstances, when no abnormalities are present, the parity vector is small, reflecting the acceptable errors in the sensor outputs that are consistent with normal operation. If a sensor failure occurs, then the parity vector grows in magnitude, signifying the presence of failure. Furthermore, each sensor failure is associated with a unique direction in the parity space, so the direction of growth of the parity vector is indicative of the identity of the failed sensor.
M U L T IP L E f AIL U R E S y
L P U 2 L P U 3 FAILED HIGH F A IL E D LO W
MULTIPLE MULTIPLE FAILURES ' 2 o r 3 > FAILURES FAILED 1 o r 3 :A !L E D >
N O L P U L P U 1 L P U 1 F A I L E D LOW TAILED HIGH' FAILURE
f 1 o r 3 ) ' l o r 2 ' FAILED FAILED 2 o r 3 MULTIPLE lFAILEI MULTIPLE PARITY FAILURES FAILURES VECTOR
L P U 3 L P U 2 FAILED HIGH F A IL E D LO W
MULTIPLE FAILURES
Figure 1. Parity Space with Decision Regions 30
In this method, the problem of sensor fault detection and identification becomes one of recognizing the magnitude and direction of the parity vector growth. Also, by taking advantage of the diversity of the available data, the data provided by the "accepted" sensors must be highly valid and reliable.
There are two problems with this method. The first one
is that the growth and direction of the parity vector must be identified in presence of ordinary process noise which are naturally present in the outputs of unfailed sensors.
The required extra accuracy makes the computations
cumbersome and time consuming for applications that involve validation of a large number of sensors by this method.
The second problem is that if only direct redundancies are used, such as the cases where more than three-fold
redundancy is available, then common cause failures are not
identifiable. Strictly speaking, in order to isolate n
failures unambiguously, the number of independent measurements, m, must satisfy the equation of m>2n+l.
This equation shows that the parity space dimension can grow very rapidly to detect common-cause failures amongst three or more sensors. This method is then similar to a more elaborate "majority ruling" sensor validation. 31
On-Line Power Plant Signal Validation Technique Utilizing Parity-Space Representation and Analytical Redundancy [21]
In this work, the concept of parity space and analytical redundancy are combined with two new concepts to perform sensor signal validation. The overall methodology is discussed below.
Two building blocks are identified in this method.
They are as follows:
1. Analytical Measurement Calculator (AMC) (Fig. 2), which
combines signals from unlike sources, such as direct
sensor measurements and validated variable estimates,
to generate an analytical measurement of a variable.
This analytic measurement is then compared with other
measurements of the same variable in a decision-
estimator.
2. Decision-Estimator (D-E), which has inputs of all of
the direct and analytic measurements of a single
variable of interest. The D-E performs two critical
functions. First, it forms a "validated" estimate of
the measured variable using a consistent subset of its
input measurements. In addition, the D-E employs
measurement inconsistency to determine when one or more
of its several inputs has failed, and excludes a failed
measurement from subsequent consideration. The
transfer of this failed measurement information to the
plant operator is a primary output function performed
by the algorithm (Fig. 3). The algorithms for 32
identifying the validity of an individual sensor is
similar to the parity-space technique, as was described
above.
In this paper, the term "Least Plant Unit" (LPU) is introduced to designate the basic resolution of the fault isolation algorithm. Specifically, an LPU consists of the aggregate of plant components, any one of whose failure could cause its associated D-E input measurement to be faulty, i.e., it represents the resolution of the fault isolation algorithm. Thus, if an LPU is too large, then the plant operator does not recieve sufficiently specific information about the source of the fault to take effective action. If the LPU is too small, then the amount of time required for fault identification is excessive and
S IG N A L 1
S IG N A L 2 ANALYTIC
S IG N A L 3 MEASUREMENT
M O D E L O F A N A L Y T IC RELATIONSHIP
Figure 2. Typical Analytical Measurement Calculator
MEASUREMENT 1
MEASUREMENT 2 ESTIMATE
MEASUREMENT 3
Figure 3. Typical Decision-Estimator 33 ultimately, the cost of the fault identification would be
too much.
An example of this method is presented in Figure 4. In
this example, the applied technique Can validate the sensor
data from sensor A. In the process of validating sensor A,
the signals from sensors B and D are also obtained.
There are two major problems with this methodology.
The first problem is that there is an assumption Of single-
point-failure, to be able to identify the failures in cases
where only three measurements are available for a parameter.
Thus, if multiple failure do occur, only the first one is
VALIDATED
B E S T IM A T E
A S E N S O R 1
A S E N S O R 2
VALIDATED ANALYTIC M O D E L O F B S E N S O R 1 A E S T IM A T E COMPONENT /MEASUREMENT
C S E N S O R
M O D E L O F A N A L Y T IC A COMPONENT B SENSOR 2 MEASUREMENT
D S E N S O R 1
VALIDATED D S E N S O R 2 O E S T IM A T E
D S E N S O R 3
Figure 4. An Example of Signal Validation Flow Diagram Using Analytical Redundancy 34 identifiable. The second problem which is inherent to the parity space methodology, is, as previously discussed, the dimension of the parity space required for isolation of faults by this technique.
Signal Validation Advances Development for On-Line Plant Monitoring and Control [22]
In this paper, the above ideas of decision-estimators, analytic measurement calculators, and the least plant unit, are utilized to validate fifteen parameters related to monitoring of the Critical Safety Functions (CFS) of core cooling, Reactor Coolant System (RCS) inventory, RCS integrity, containment integrity, reactivity control, and
RCS heat removal of a Westinghouse Pressurized Water Reactor
(PWR). These fifteen parameters are: RCS pressure, hot leg temperature, cold leg temperature, core neutron power, steam generator pressure, steam generator level, containment pressure, containment sump level, feedwater flow rate, pressurizer level, core exit temperature, RCS flow rate,
Residual Heat Removal (RHR) flow rate, letdown flow rate, and shutdown temperature.
These fifteen parameters are programmed in separate subroutines and are accessed from a main program. The complexity of these routines vary from a single stage decision-estimator to multi-level of D-E and AMCs. Other than the implementation of the above ideas, there is no new ideas in this work, compared to the previous project by 35
EPRI, as was discussed above.
1.8 Summary
In this chapter, different kinds of SPDS were reviewed.
Next, knowledge based expert systems and their applicability to the nuclear power diagnosis domain were discussed and a literature review of the techniques utilized in currently operating nuclear power plants was made.
Also in this chapter, it was discussed that the current sensor validation routines can not detect common cause failures and thus, there is a need for enhancement to the current techniques. It was further argued that malfunction diagnosis and sensor validation are complementary to each other and one can not be accomplished efficiently, without the other. CHAPTER II
NUCLEAR POWER PLANT MODEL DESCRIPTION
The Nuclear Power Plants (NPP) domain was selected to
demonstrate the applicability of the theories developed
during the course of this project. These theories discuss
the concept of sensor data validation in conjunction with malfunction diagnosis [23, 24, 25] and will be discussed in
later chapters. In this chapter, three subjects are
discussed. (1) The Boiling Water Reactor (BWR) model; (2)
The discussion of the modeled reactor coolant subsytem; and
(3) The assumptions and simplifications inherent to the model.
A subsystem of the NPP domain was selected during the
implementation stages of this research. The selected
subsystem was selected to meet the following criteria:
1. This subsystem must be large enough to prove the
principles and theories developed for this research,
and to show that the size of the selected system causes
no limitation on these principles and theories.
2. This system must not be too large so that a reasonably
deep study and understanding of this subsystem, within
the time limits of the project, cannot be completed.
36 3. Problem solving in this system must not be of a trivial
nature due to abundance of sensors and alarms. In this
subsystem, there must exist problem areas of interest
to the nuclear engineering community which ordinarily
require a deeper problem solving strategy than routine
and day to day tasks normally employed.
4. The selected system must be of a generic nature amongst
the various plants, except for minor differences due to
specific plant designs. This makes the issues and
examples more general and understandable by a wider
audience.
5. There must be sufficient information readily available
in the public domain about the chosen subsystem. This
can considerably simplify the knowledge engineerring
task and speed up the knowledge collection about the
selected subsystem.
After considering the above factors, the coolant system of Unit one of the Perry Nuclear Power Station was selected.
This plant is a General Electric (GE) Boiling Water Reactor-
6 (BWR6) with Mark III containment (Fig 2.1), and is located near Cleveland, Ohio.
The coolant system of this plant meets all of the above criteria and is of interest to the nuclear power generation community. The subsystem's problems which are dealt with in this project, range from a Main FeedWater Pump (MFWP) trip to large Loss Of Coolant Accidents (LOCA), as will be seen containment
drywel1
safety relief valve HSlVs Turbine Building
flow control j f and bypass steam dryers valves water steam M evel separator
turbine generator control valve recirculation condenser pump control main feedwater circ pump pump
suppression pool N Feed Water Heaters
u> Figure 5. Reactor Coolant System Model 00 39 in later chapters. In the following paragraphs, the BWR domain, as well as the reactor coolant subsystem are described briefly.
Boiling water reactors generate steam from nuclear heat produced from the fission process. Nuclear fuel bundles are configured as the reactor core, which is surrounded by water and serves the dual purposes of moderating neutrons and cooling the core. The fission process is self-regulated by boiling, which creates steam voids that allow excess neutrons to escape. The process is also regulated by control rods containing neutron absorbing material which can be inserted into (or withdrawn from) the bottom of the core.
Saturated steam is then passed through the steam separators and dryers inside the reactor vessel and sent through a normal steam cycle, i.e., turbine, condenser, condensate system, feedwater and preheater systems, and the coolant is returned to the pressure vessel.
In addition to the above subsystems, there are 19
Safety Relief Valves (SRVs) on the four Main Steam Lines
(MSLs), four pairs of inboard and outboard Main Steam
Isolation Valves (MSIVs), four Turbine Stop Valves (TSVs) and four turbine Control Valves (CVs). These components comprise the reactor coolant system.
The nuclear process is physically separated from the non-nuclear part of the system, or "Balance Of Plant" (BOP).
The reactor vessel is housed inside a containment building 40 which can be isolated from the BOP in the event of an accident. A subcooled body of water known as the suppression pool is located at the base of the containment building to serve as a temporary heat sink during overpressure or loss of heat sink accidents and limits the containment pressure if a leak should occur. Emergency Core
Cooling Systems (ECCS) are provided to maintain reactor vessel coolant inventory and remove heat from the core during an accident.
For this research, a simplified model of the above
BWR/6 coolant system is utilized. In this model,in addition to the reactor coolant subsystem, the control rods, recirculation loops, the containment building, including drywell and suppression pool and turbine building are modeled. These components, in addition to the core cooling subsystem, present a more global view of the state of the plant's coolant system.
The developed expert system contains a vast amount of knowledge for various malfunctions and incorporates primary sensors related to this subsystem. These sensors in general are flow, temperature, neutron flux and pressure indicators and are readily available throughout the plant. These parameters are also available through the Safety Parameter
Display System (SPDS) or plant process computers and are readily accessible. 41
The knowledge base of this expert system contains information about the different malfunction scenarios encoded within each node, as will be seen in the later chapters. The sources of the required knowledge are:
1. Professor Don W. Miller, the Chairman Nuclear
Engineering program: He specializes in nuclear
instrumentation and control. He has an in depth
knowledge of reactor instrumentation and control
systems.
2. Professor Brian K. Hajek, a faculty member in the
Nuclear Engineering program: He is an NRC Licensing
Examiner for BWR operators, and has an in depth
knowledge of plant operations and systems.
3. Accident Analysis Section of the Updated final Safety
Analysis Report (USAR) of the Perry Nuclear Power
Plant.
4. Training courses and material developed for the Black
Fox* and Perry** simulators.
5. Instructions for the Perry Power Plant Simulator
instructors.
* Black Fox Nuclear Power Plant was a GE-BWR/6 near Tulsa, Oklahoma. The plans for building this plant were canceled in 1980. However, the USNRC is is still operating the full function simulator.
** Perry Nuclear Power Plant is a GE-BWR/6 near Cleveland, Ohio. It achieved initial criticality in 1987. 42
6. Personal knowledge of the BWR systems through plant
documents that were developed for the Perry Nuclear
Power Plant.
The above sources were utilized extensvely In the knowledge engineering tasks and during debugging stages, as will be discussed in later chapters.
After selecting the coolant sytem of the above plant, a set of assumptions had to be made to enable completion of this research. These assumptions and simplifications, however, will not limit the scope or applicability of the theories and principles behind this work. At the present time, the expansion of the developed expert system is underway by other members of this research group.
The required assumptions and simplifications during the prototyping stage of this expert system are:
1. The plant is operating at 100% power and is at steady
state condition.
2. The nineteen Steam Relief Valves (SRV) are replaced
with one SRV. This one relief valve is assumed to be
functionally equivalent to the set of ninteen SRVs by
adjusting the mass flow rate.
3. Four Main Steam Lines are replaced with one
functionally equivalent steam line. This steam line
has a mass flow rate equivalent to the four MSLs.
4. Four sets of inboard and outboard Main Steam Isolation
Valves (MSIV) are replaced with one set of MSIVs. This one pair is assumed to be functionally equivalent to the four sets of MSIVs.
Four turbine stop valves and all of the turbine bypass valves are replaced with one stop valve and one bypass valve, respectively, each having an equivalent capacity to the four original valves.
The three stages of the main turbine are modeled as one stage which is functionally equivalent to the three stages. It is assumed that there are appropriate steam bleed lines from this turbine to the feedwater heaters.
Condensate and feedwater pumps are simplified as one equivalent Main Feedwater Pump (MFWP). This pump has the same capacity as the plant's original pumps.
Two recirculation loops are modeled as one equivalent loop. This loop is equipped with a flow control valve and a two speed pump (as is designed for the Perry
NPP).
Condensate and feedwater heaters are modeled as one equivalent feedwater heater. The shell side steam is bled from the turbine, as was discussed in item 6 above.
The set of input data are assumed to be valid and reliable unless indicated otherwise. This input data set is assumed to have gone through the already existing signal validation routines. 44
11. The set of input data is a snapshot of the continuously
changing plant data, and is frozen in tine, until the
diagnosis and validation are done.
The above assumptions simplify the model considerably
(Fig. 5). However, the overall concept of malfunction detection is not compromised by these assumptions. These simplifications were implemented in the original model.
This original model is currently under expansion so that some of these simplifications can be eliminated.
Once the final decision was made on the plant model and its subsystems, then the sources of the required information were identified. This information is used during the knowledge engineering task and the construction of the malfunction specialists. CHAPTER III
DIAGNOSIS AND SENSOR DATA VALIDATION IN CSRL
An advanced plant surveillance and diagnostic system has been designed for the purpose of aiding operators to respond to plant abnormal transients. The diagnostic system of interest to this dissertation is a knowledge rich computer-based program that uses AI techniques to encode and decode the knowledge and judgements of experts. These types of computer codes are generally known as Knowledge Based
Expert Systems. Expert systems are a subdomain of the artificial intelligence field of computer science. The proposed expert system is described in the following sections. In the first section, diagnosis in CSRL is discussed, and in the second section, the sensor validation technique is presented.
3.1 Diagnosis in CSRL
3.1.1 Hierarchical Structures
Many kinds of problem solving for expert systems have been proposed within the AI community. Whatever the approach, there is a need to acquire the knowledge in a given domain and.implement it in the spirit of the problem solving paradigm. Reducing the time to implement a system usually involves the creation of a high level language which reflects the intended method of problem solving. For
45 46 example, EMYCIN [26] was created for building systems based
on MYCIN-like problem solving [27]. Such languages are also
intended to speed up the knowledge acquisition process by
allowing domain experts to input knowledge in a form close to their conceptual level. Another goal is to make it easier to enforce consistency between the expert's knowledge
and its implementation, through structured programming,
displays, and user interface.
CSRL [3, 28] (Conceptual Structures Representation
Language) is a high level language for implementing expert
diagnostic systems that are based on the AI group's approach
to diagnostic problem solving. CSRL facilitates the
development of diagnostic systems by supporting constructs which represent diagnostic knowledge at appropriate levels
of abstraction.
CSRL was developed at The Ohio State University by the
Laboratory of Artificial Research (LAIR) for the task of
classificatory problem solving. This work is motivated by
the following central ideas [29, 30]:
1. Proper description of the cognitive task (in this case
classification) reveals the appropriate computational
strategy and knowledge form that allows a traceable
solution for this kind of problem solving.
2. Programming tools are developed that allow the domain
expert to easily add domain knowledge with limited
concern about the specifics of the implementation, once 47
such a description is available.
3. Proper description of such tasks reveal a small set of
Generic Tasks that, taken together, account for a
significant part of cognition.
Knowledge based expert systems contain focused domain specific knowledge (and hence they are called knowledge based expert systems). In addition to the domain specific knowledge, these expert systems contain information about how to utilize this knowledge to attain a diagnostic conclusion. The diagnostic work of the AI group at The Ohio
State University, is motivated around the following two central ideas (the theoretical basis for these ideas is given in detail in several publications [4, 25, 29, 31]):
- Problem solving knowledege is decomposed into a
collection of specialists and subspecialists, each of
whom concentrates its knowledge about a relevant
concept or malfunction.
- These conceptual specialists perform problem solving in
parallel, and communicate in certain specified ways to
keep track of the global state of the problem solver.
These ideas are implemented in CSRL which at this time is executeable in LOOPS/lnterLisp-D environment.
3.1.2 Problem Solving Strategy
Problem solving in such systems has a generic character and typically has the task of classifying a given case into a diagnostic statement. In classification, the form of the 48 required knowledge is proposed to be of the form of a hierarchy of malfunction hypotheses [29]. In this hierarchy of malfunctions, the top levels are more general diagnostic classes, and the bottom levels correspond to more specific cases (type-subtype arrangement of the malfunctions). The set of tip nodes in this hierarchy will then be thought of as the diagnostic conclusions relevant to the system. The links between the nodes are based on a type-subtype relationship (Fig. 6) .
Diagnosis begins by firing of the top node. This activity is initialted by detection of the out-of-order symptoms monitored by the top node.
The problem solving strategy of this classifcation system is a top-down examination of the hierarchy, termed
"Establish-Refine"[31]. The reasoning can be organized as a hierarchical collection of specialists. Each specialist in this hierarchy contain two modules identified as reasoning and as control knowledge. The knowledge in these modules can be utilized to establish or reject that specialist (or malfunction hypothesis).
Establish-Refine can be thought of as the examination of the "appropriateness" of a particular malfunction of the hierarchy. If a malfunction is found appropriate (i.e.,
Established), then its sub-malfunctions in the hierarchy are also asked to establish (i.e., Refine). If that specialist is not established, then none of its subspecialists need be 'C on aa rTuba Laak ,HlgbCoolantConductlv!t] .RWCUFall .DtmlMrallarFall
■RidrcFCVErr
ColdWatarAcc
WghPraaaDoaToEHCFaylt
•TurbLoadRaJWOBypaaa iNiOfClreFim iF .CondanaarFall^^^^ LoaaOfKaatSlnk. .StaamJUr€|actorFali
TurblnaControlValva RCIC ’MgbPrvaauraSyataa*' HPCf 'ECCSEFWCErr LPCI Hlghlnvanti 'LowPraaauraSyatai
‘FWCofltroftarFaffMgh
>HlghFWDSchPraaa FWCentroawFallLow •FWPBoctValvaClar .L«vNP8H ,FWP7urbTrlp/L»«SpMtf. .FWPTurbCntrtValtaClar ■LowCondVac
FWBPTrl] LoaFWBPSuelFrm 'HighFWBPDachPraat .loaaOfFaadwatarFlow, LowHotSurgaTank
'InMlfirtVilviClar LowPrtaaDuaToEHCFauM
H o lW a N T a n h •HotSurgaTank -CondanaataStoragaTank >OtfwrSreallLaakages >OtrtafdaConla)iMBantlOCA
LOCA StaaraUnaBraak.
.RaclrellnaProblam RalltfVaivaOpan
Figure 6. Hierarchy of Malfunction Specialists in the Simplified BWR 50 examined, and that part of the tree can be pruned (not analyzed). Therefore, the arrangement of the specialists on this hierarchical tree is of utmost importance.
The evaluation of malfunction appropriateness is based on knowledge embedded in each malfunction node of the hierarchy. In essence, each node is capable of performing a simple kind of problem solving which evaluates whether given the currently available data, the malfunction at the node exists. This embedded knowledge is known as a knowledge group. The knowledge groups for each node are are responsible for making the appropriateness measures. Each knowledge group contains domain expertise of the form, "What pattern of data must exist for this malfunction to be labele dappropriate?" Furthermore, if the indicated pattern is not found, how must the approriateness of the malfunction be measured? (Fig. 7).
In each knowledge group, three kinds of questions can be asked of the user (or directly from a data base containing plant parameter values):
1. Questions with Yes (True), No (False) or Unknown
answers (AskYNU? function, with answers Y, N or U ) ,
2. Questions with HighHigh, High, Normal, Low, LowLow or
Unknown answers (AskHLN? function, with answers HH, H,
N, L, LL, or U), and
3. Questions with rapIdlyIncreasing, Increasing, Steady,
Decreasing, rapiDlyDecreasing or Unknown answers 51 (AskTrend? function, with answers: II, I, s, D, DD, or U).
The query function in item 1 above is a standard function of
CSRL, and the functions indicated in items 2 and 3 were developed specifically for this research.
These multi-level answers are capable of providing qualitative input "knowledge" to the system, thus accurately classifying the state of the plant without having any need for numerical information.
During the course of this research, it was felt that the standard CSRL query functions did not contain adequate detail. Thus, as was discussed above, the AskHLN? query function was added to CSRL to incorporate five levels of answers. These five levels lend themselves naturally to
User Exec - - PPDefault Window
Reactor kg of ClosedMSIVs Expressions of table 1 - (AskYNU? “Are the MSIVs open") 2 - (AskHLN? "What is the reactor pressure") 3 - (AskHLN? "What is the steam flow rate") 4 - (AskYNU? "Are there any SRVs open") 1 2 3 4 value OR T U1 OR N H HH) (OR L LLi T 3 OR T U* iOR H HH) (OR L LL) ot 1 o ?? ? • -3
Figure 7. Example Knowledge Group 52 this domain because of the current standards in labeling the parameters in a nuclear power plant.
It was also decided that because of the range of the time constants involved in a nuclear power plant, the absolute values of the parameters alone are insufficient to make sound diagnostic statements. This was specially true for slowly developing transients. Thus, the third function, namely AskTrend?, was developed to account for trend data.
These trends can identify abnormalities which otherwise could take from minutes to even weeks before tripping an alarm set point in one of the basic parameters or related systems.
Even though for this research project, the reactor coolant system of a GE-BWR/6 (Fig. 5) was selected for analysis, it is important to note that the generic nature of this study is independent of the subsystem selected and can be used in any other domain with similar problem solving needs.
The reactor coolant system malfunctions are organized in a hierarchy of system and subsystem faults. As an example, Coolant-System-Malfunction has as subspecialists,
Reactor-Over-Power-Due-To-Coolant-System-Faults, Pipe-
Breaks, etc. (Fig. 6).
In this expert system, the given set of parameters is utilized to reach a diagnostic conclusion. The Knowledge
Based System (KBS) classifies the state of the reactor among 53 several possiblities by using the Establish-Refine technique, as was discussed in page 49. This technique prunes the search space very rapidly and efficiently.
The input data are a set of fundamental parameters such as pressures, flows, levels, and temperatures. Sensors monitor the performance of the related systems and components of the reactor coolant system. These parameters are assumed to have been through the conventional validation routines, and an average value for each parameter is obtained in the end.
At this stage, knowledge groups (Fig. 7), which are embedded in each specialist (Fig. 8), are used to diagnose the state of the system. These knowledge groups are
collections of evidences from different parts of the plant
(Fig. 9). The mechanism of utilizing the available evidence
in each specialist is discussed in the following section.
3.1.3 Confidence Factors
In this system, evidence for establishing or rejecting
a malfunction hypothesis is a collection of data patterns
from different parts of the plant. As an example, evidence
for the hypothesis of CoolSysFault can be decomposed into
reactor data, containment data, steam and electrical output
data, and suppression pool data. We can think of each of
these components as an abstraction from sensor data, which
then contributes to the further abstraction of the
CoolSysFault hypothesis. 54
User Exec — PPDefault Windpw - V (Specialist RecircFGVErr ♦♦COMMENT** (declare (LoopsSuper NPPSpec1al1st) (Superspecialist Rx-OverPower)) (kgs (RecircFCV **C0MMENT** Table (match (AskYNU? "Are the reclrc flow control valves 1n normal position") (AskHLN? "What is the jetpumps flow rate") (AskTrend? "What 1s the jetpumps flow trend") with (if T ? ? then -3 elseif F ? ? then 3 elseif ? (NOT N) ? then 3 elseif ? ? (NOT S) then 3 else -3)))) (messages (Establish **COMMENT** (SetConfidence self RecircFCV))))..
Figure 8. Example Specialist
CoolSysFault Summary Knowledge Group
Reactor Containment Suppression Pool Steam & Electric knowledge Group knowledge Group knowledge Group knowledge Group
Figure 9. Knowledge Group Organization within Specialists 55
For the reactor data, for example, the sensor values that contribute to the abstraction are reactor pressure vessel pressure, water and power levels, and their respective trends. Various combinations of these sensor values are classified into classes, "Strong Evidence for",
"Moderate Evidence for", etc.
Depending on the available evidence from a specialist's knowledge groups, each node is assigned a confidence value from +3 to -3. The significance of these confidence factors are:
Conf. Value = +3 ------> The malfunction is DEFINITE Conf. Value = +2 > The malfunction is VERY LIKELY Conf. Value = +1 ------> The malfunction is LIKELY Conf. Value = 0 ------> The malfunction is POSSIBLE Conf. Value =-1 -> The malfunction is UNLIKELY Conf. Value = - 2 > The malfunction is VERY UNLIKELY Conf. Value = - 3 > The malfunction is DEFINITELY NOT
Should the confidence value of a node be determined as
+2 or +3, (better than LIKELY odds), then the subnodes of that particular specialist are also examined. If the node's confidence value are determined to be anywhere between -3 to
+1, the subnodes of that particular node are ignored until later in the diagnostic reasoning.
Up to this point, it has been assumed that the input data are a set of valid and reliable data. These input data are assumed to have gone through some standard data validation and are in general, reliable. However, due to common cause failures, the input data may be faulty, and thus, some of the data may require further validation. Past 56 studies have shown that sensor data validation and diagnosis are integral components to one another, and neither one can be accomplished separetely in an efficient manner [5,32].
In the next section, the sensor validation routine in the context of diagnosis is discussed. We have introduced another level of sophistication to the validation procedures discussed in the literature review section (Section 1.5), and have made use of the conclusions that are reached during diagnosis as a context to suspect potentially unreliable data.
3.2 Sensor Data Validation Technique
3.2.1 Introduction
The information that is brought by the plant instrumentation to the man-machine interface is of primary importance, and it should be considered in light of advanced man-machine interfaces. In the past, instrumentation surveillance for validity has been largely a combination of periodic calibration by technicians and frequent observations by operating personnel. The operator is expected to believe his instruments by comparing like-sensor data. He also learns by experience that some signals are uncertain and he often develops a pattern of not believing
some signals when they do not fit his judgement as to the
system condition.
Advanced instrumentation technology, today, has reached
a point that signal validation should be done primarily by 57 the individual instrumentation. The instrumention must be reliable to the point that the operator can be confident of the available sensor data. He must always be alert and be ready to question data but, his first response after a simple cross checking of the available data, should be confidence in his instrument readings. Due to complexity and criticality of analyses of some of the data points, a number of sensor validation schemes are developed and computerized, as described in Chapter 1.
Sensor validation can be thought of as a two stage function. Each stage is capable of identifying a certain class of faulty sensors. The two stages are:
1. First level of validation is mainly dependent on
comparison of redundant sensor signals (including
auctioneering, fail safe assumptions, and so on) and is
aimed at identification of gross failures of the
instrumentation channels (Such as shorts, open
circuits, connector failures, or detector failures).
These techniques are based on various kinds of
redundancy in sensor hardware and are descussed in
Sections 1.5.2, and 3.2.2.
2. The second level of validation is beyond hardware
redundancy and is accomplished through expectations
derived during malfunction diagnosis. "That is, in the
process of exploring the space of possible
malfunctions, initial data and intermediate conclusions 58
set up expectations of the characteristics of the final
answer"[24]. This method of validation uses analytical
redundancies and local versus system loop condition and
is aimed at common cause failures identification, or a
more subtle failures, such as instrumentation
calibration drifts. These techniques are described in
section 3.2.3.
3.2.2 Current Technology in Sensor Validation
The first level of signal validation has been implemented in currently operating nuclear power plants and provides substantial assistance to plant operators towards identification of faulty instrumentation channels. However, the second level is more difficult and requires a significant amount of modeling of plant systems, subsystems, or components. Large scale modeling of plant systems is expensive and may not prove cost effective. On the other hand, the subsystem or component modeling can be efficiently used to analytically obtain an estimate of suspicious sensor data in the subsystem.
The assumption of "sensor data are reliable until proven otherwise," is utilized in the developed expert
system because it is assumed that the input parameters have been through the conventional sensor data validation
routines. It is also assumed that an average value for each
parameter is available for each parameter. This assumption will simplify the diagnosis task. For the task of sensor 59 validation, however, individual data points are accessible upon request of the expert system.
The already existing routines, as were described in section 1.7.2, include: "like" sensors comparison, limit checking on trends and absolute values, auctioneering amongst like sensors, instrument loop integrity checking, live zeros and ceilings, and parity space checking. For a detailed description of these methods, refer to section
1.7.2.
These conventional routines can improve the operational safety, but not the availability and operabability of the plant. The major shortcomings of these sensor validation routines were also discussed in section 1.5.2.
It is clear that improving the quality of sensor data to safety related systems and displays will enhance the response of the operator during abnormal events. Another important benefit of more sophisticated sensor data validation relates to plant availability, if it is applied to not only safety related systems, but also control systems. A study in 1980 [33] showed that on the average, instrument failures alone, account for one trip per plant per year, or about 1% of the total plant unavailability.
These trips are occuring in the presence of conventional validation techniques.
If these spurious trips could be eliminated via a more robust sensor validation methodology, a savings of about 60
$500,000 per plant per year could be realized. (This is based on typical replacement power costs for an 800 MWe unit of approximately $500,000 per day, 1980 figures.) Thus, the
financial impact of this additional sensor validation, throughout the life of a plant (around 40 years) is obvious.
We have introduced another level of sophistication to the above techniques and have made use of the conclusions that are reached during diagnosis as a context to suspect potentially unreliable data. This is in addition to making use of analytical redundancies as will be mentioned later.
This technique is dicussed in the next section.
3.2.3 Proposed Technique
During the design stages and prototyping of the designed system, a great deal of attention was paid to
ensure the system's ability of reaching a diagnostic
conclusion based on partially complete data sets as well as potentially incorrect input parameters. To reach this goal,
all relevant and useful sources of information for each malfunction hypothesis (specialist) are identified. Next,
the relationship between them are determined and proper
combinations of this information are utilized in
establishing or rejecting the malfunction hypotheses. As an
example, in order to detect a large LOCA, the containment
and reactor pressure vessel parameters, as well as the
turbine-generator, suppression pool, main steam line and
feedwater parameters are taken into account. In this 61 fashion, having only a partial list of valid parameters, a fairly accurate diagnosis is still possible.
It is also important to note that it is impossible to ensure that all possible malfunctions are covered by any expert system. Thus, the system must be designed so that if it encounters a situation which is not covered by its knowledge-base, to either fail gracefully or to be able to reason on its own. The first one is accomplished by providing a partial and correct diagnosis and the later, by a functional description of the plant components, systems and the relationship amongst them. The functional representation of systems is still topic of many research projects and is outside of the scope of this dissertation.
One of the important factors to note here is that due to violation of "normal expectations" of malfunctions [23,
24], some combinations of the input data values can be marked as not capable of occurring or highly unlikely. That is, in the process of matching the malfunction patterns to data, certain combinations of data do not make sense in the given domain. As an example, turbine/generator electrical output must be zero (or decreasing rapidly) if the Main
Steam Isolation Valves (MSIVs) are closed.
Thus, the process of faulty sensor identification involves the following three steps:
1. The first step is to establish some expectations by
using local knowledge, or the context of other nodes. 62
2. The second step is to use these expectations to flag
particular data values as questionalble.
3. The third step is the process of validating or
rejecting the questionable sensor values based on the
relational redundancies available in other parts of the
plant.
In addition to various conventional sensor hardware
redundancy, the expectations derived during diagnosis are utilized as an extra source of redundancy. These
expectations are embodied in the specialists' knowledge
groups and are formed and encoded a priori'. The knowledge
groups were designed to give a rating of pattern fit to
input data. If the fit is not exactly as expected, then
those values that are outside the expectations are flagged
as suspicious [24, 25], and they are subjected to further
analysis (Fig. 10). Note that only knowledge group rows with one or two mismatches, depending on the size of the knowledge group, are identified as suspicious. If the number of mismatches is more than these preset limits, then the knowledge group is ruled out and will not be subjected
to the validation scheme detailed here.
The knowledge group rows that do not meet the expected
symptoms completely are identified as containing suspicious
data, and this is indicated by addition of a in their
confidence values. The reason for marking confidence factors with a * as opposed to rejecting the knowledge group (CF =- 63
3) due to mismatch of expectations and symptoms is that there are enough indications for Establishing the knowledge group.
In Figure 10 a modified knowledge group is presented, which indicates the incorporation of *s in confidence factors. In Figure 11, a modified malfunction specialist is presented. The * alarms the user (and the computer) that this row of the knowledge group will be subject to further analysis and thus, the confidence factor of the specialist containing this knowledge group, can potentially change.
Should a knowledge group row be identified as containing suspicious data, then one of the following cases must be true.
SR VOpen KG of ReliefValveOpen
Expressions of table
1 -(AskYNt? "Are there any SRVs open")
2- (AskHLN? "What is the suppression pool temperature")
3- (AskTrond? "What is the suppression pool temperature trend")
4- (AskHLN? "What is the suppression pool level”)
QUESTIONABLE 1 2 3 4 VALUE SENSORS
T (ORNHHH) (OR SI ID (O R N H H H ) 3 -
(OR F t ) (OR il HID (OR III) (O RH H H ) 3* SI
(OR F C) N (OR III) ? I* SI and S4
? ? ?? ■3 ...
Figure 10. An Example of a Modified Knowledge Group 64
- The set of expectations are not valid at that
particular instant of time due to the assumptions
about the initial conditions of the malfunction
scenario compared to the state of the actual state of
the plant before malfunction, i.e. the knowledge base
is not valid, or,
- The set of symptoms are not valid at that particular
instant of time which leads to the conclusion of THE
XYZ (GROUP OF) SENSOR(S) HAS FAILED.
In order to decide which one of the above cases is true, the following algorithm is used:
1. Start Diagnosis
2. Once a * is encountered in the knowledge group's
confidece factor, then the entire knowledge group row
is stored in the Suspicious Data List (SDL) . Each
entry to this list is of the form of:
(Specialist 1 (KG-Name 1 (SI VI) (S2 V2) ... (Sn Vn)) (KG-Name 2 (SI VI) (S2 V2) ... (Sn Vn)) •
(KG-Name n (SI VI) (S2 V2) ... (Sn Vn))
Where Si are the sensor names and Vi are their values.
An example is presented in Figure 12. In that figure,
the upper box represents all values of the sample run
and the lower box is the expansion of the Suspicious
Data List (SDL). 65
DEdit of LossOfFWHtr specialist [Specialist LossOfFWHtr (* specialist for LOSSOfrWHTR) (declare (LoopsSuper NPPSpeclallst) (Superspecialist ColdWaterAcc)) (kgs (Water&SteamFlow (* definition of now knowledge group) Table (match (AskHLN? "What 1s the steam flow rate") (AskTrend? “What 1s the steam flow trend") (AskHLN? "What is the feedwater flow rate") AskTrend? "What 1s the feedwater flow trend") with (if N S N S then 3 elseif N ? N ? then 2 else -3))) (Reactor (* definition of new knowledge group) Table (match (AskHLN? "What 1s the feedwater temperature") (AskTrend? "What 1s the reactor power level trend") (AskTrend? "What 1s the reactor water level trend") (AskTrend? "What 1s the feedwater temperature trend") with (if [OR N L LL) OR I (OR S I!) X (OR D DO)1 then 3 elseif (OR H HH) (OR I (OR S I II)X (OR D DO) then 3* else -3)))) (messages (Establish (if (6T Water&SteamFlow 1) then (if (EQ Reactor (QUOTE 3*)) then (DoLIsp (<- ($! currentCase) StoreSusData SPECIALIST KGNarae CaseNo) (SPECIALIST self) (KGName (QUOTE Reactor)) (CaseNo ($! currentCase))) (SetConfIdence self Reactor) else (SetConfIdence self Reactor)) else (SetConfIdence self Water&SteamFlow)))))
Figure 11. An Example of a Modified Specialist 66
3. Diagnosis (Establish - Refine Routine) resumes from
where it was temporarily halted to store the SDL.
Diagnosis resumes until all diagnostic conclusions are
reached and suspicious knowledge groups are identified.
The lower box of Figure 12 shows all of the SDL
collected during the sample run. It shows that the
LOCA Specialist had questionable data in its
Steam&Electric knowledge group and ClosedMSIVs
Specialist had suspicious data in the two knowledge
groups of Reactor and MSIV.
Local properties of Class ClosedMSIVs MetaClass (MetaSpeclal1st Edited: (* edited: "19-Feb-87 12:55") doc (* specialist Supers (NPPSpedallst) I Vs CVs (Superspecialist Subspecialists Bindings Declarations Kgs — ) Methods NIL All IVs of SCIosedMSIVs case U confIdenceValue U nessagesRecelved NIL variables NIL state uncalled suMmary UnSetKnov1edgeQroup FiredKgRow ; kMyIV &) (fyractor &) ) Reactor UnsetKnow ledgeGroup MSI V UnSctKnowledgcGroup DEdit of expression ((MSIV (((T U)
(DT> DD) ^then|s| JMSIVOpen) then SMSIVOpen))) (Reactor (((T U) (N H HH) (L LL) (T) then jMSIVOpen) ((T U) (H HH) (L LL) (F U) then (A SMSIVOpen tSRVOpen)))))
Figure 12. Suspicious Sensors List 67 Validation starts by sending a "Validate" message
(either by manually pointing the mouse to a specialist, or automatically by the system) to any Specialist that has * in its confidence value. The data relavent to this Specialist is extracted from the SDL for analysis.
The suspicious parameter from this knowledge group
(which is identified a priori’) is separated and stored in the Suspicious Sensors List (SSL). This is accomplished by comparing the stored knowledge group row in the SDL to a data pattern Instance Variable (IV) of that Specialist. This data pattern IV is called
"FiredKgRow" and is presented in Figure 13 for the
ClosedMSIVs Specialist of the sample run. Note that there are more than one data pattern for each knowledge group of the specialist. Also, it is important to note that these data patterns are more generalized forms, compared to the individual rows of the knowledge groups.
In each row of a knowledge group, three types of suspicious sensors (or combinations) can be identified:
a. An individual sensor can be suspected strongly
(eg., Sensor-1 is suspicious), and the final
diagnosis is not affected, as a result of signal
validation. One example of this case is the
MSIVOpen sensor of the sample run which is
represented in the lower box of the Figure 14. 68
This pattern shows that:
if: MSIVs Position = Open or Unknown and Turbine Stop Valve = Open and Turbine Electrical Output Trend = Decreasing or Rapidly Decreasing
Then The MSIVs Position = Questionable
b. A group of sensors can be suspected strongly (eg.,
Sensor-1 and Sensor-2), and the final diagnosis
may change, as a result of signal validation. The
lower box of Figure 13 presents such an example
as:
If: MSIVs Position = Open or Unknown and TSVs Position = Open and Main Steam Line Steam Flow= Very Low and Reactor Pressure = High or Very High and SRV position = Closed
Then The TSV, MSIV and SRV Positions =Questionable.
All .Valuus of CSRLCase $Case2. browser #&(NPPBrowser (43 . 37252)) valueBrowser #&(NPPValueBrowser (43 . 37240)) specialists (#$CoolSysFaultCase2 #$L0CACase2 #$LowInventoryCase2 #$H1ghInve SusDataLlst ______( (# $ L G C a , Stcci (ii-’iE lee trie & & --) i#lClosedM-31V: Reactor 6 £. ) Instances NIL strlngDB (NIL NIL NIL (&) (&) — ) DEdit of expression ((#$L0CA Stean&Electric ((AskHLN? "What 1s the steae flow rate") 1s L) ((AskHLN? "What 1s the turbine electrical output") 1s L) ((AskHLN? "What 1s the reactor power level") 1s N) ((AskYNU? "Are there any SRVs open") 1s F)) (#$C1osedMSIVs Reactor ((AskYNU? "Are the HSIVs open") 1s T) ((AskHLN? "What 1s the reactor pressure") • 1s H) ((AskHLN? “What 1s the steaa flow rate") 1s L) ((AskYNU? "Are there any SRVs open") 1s F)))
Figure 13. An Example of Normal Expectation Data Pattern 69
c. Two sensors (or groups of) are suspected but, the
resolution of which one of the sensors is faulty
requires further analysis (eg., Sensor-1 or
Sensor-2). Thus, diagnosis cannot be completed
until this analysis is performed. An example is:
If: FeedWater Pump Speed = Normal And Reactor Water Level = High And ECCS Injection Alarm = Off
Then Either Reactor Water Level Sensor or ECCS Alarm Is Questionable.
In cases i and ii, the sensors are added directly to the list of sensors to be further analyzed (SSL), if they are not already on the list. In the third case, the following steps have to be followed before the sensors are added to SSL.
The SSL is first checked to see if any of the sensors are already on the list. If one is on the list, then it is assumed that the other sensor is producing reliable data and this procedure is terminated.
Otherwise, the list of specialists that have used these sensors are checked to see if the remainder of these specialists are producing diagnostic statements that are consistent with either of these sensors. If there is overwhelming evidence towards either one (if any of the above Specialists have * in their confidence factor), then that sensor is added to SSL. If the above steps fail to resolve the situation, then both 70 are added to SSL.
5. Once the SDL is completed, then a backup value is
calculated for each sensor in this list. The
measurement validation (or estimation) requires the use
of simple on-line dynamic plant process models which
have been previousely verified and validated. These
estimates should be capable of being calculated in real
time. As an example, the SRV Position is inferred by
the Suppression Pool Temperature Uniformity and SRV
Downcomer Pressure. That is, if the suppression pool
temperature is not uniform and the SRV downcommer
pressure is high, then the SRV position is open. This
example is presented in Figure 14.
DEdit o f function SRV .Position (Method ((SRV Position) self) <* edited: •• s-Jun-8r 15:47") (* New method template) (if (AND (EQ (AskYNU? “Is the suppression pool temperature uniform"
(QUOTE F)) (OR (EQ (AskHLN? "What is the SRV downcomer pressure") (QUOTE HH)) (EQ (AskHLN? “What is the SRV downcomer pressure") (QUOTE H)))) t h e n T else (QUOTE F)))
Figure 14. Validation Routine for Validation of SRV Position 6. The old value for each sensor is replaced by the newly
calculated values. The system then alerts the plant
operator of the failed sensor (s) and the newly
calculated data are presented.
7. Once the sensor validation is completed and unreliable
sensors are identified, then the newly calculated
values are used and diagnosis is restarted from the top
(GOTO Step 1). The above steps continue until all of
the unreliable sensors are identified.
It is important to note that the extra steps in 4 are performed to avoid the cost of unnecessary sensor validation by keeping the number of sensors to be checked to a minimum.
In this algorithm, the backup values for sensors must be obtained. These values determine if the expectations are not valid or if the sensors are faulty. The redundant sensor data are usually obtained from one of the following types of relationships:
- Logical conclusions drawn from diagnosis (eg: IF (LOCA
IN DRYWELL) THEN DRYWELL PRESSURE = HIGH) .
- Logical conclusions drawn form available data (eg: IF
SUPPRESSION POOL TEMPERATURE IS NON UNIFORM AND SRV
DOWNCOMER PRESSURE IS HIGH THEN THE SRV POSITION IS
OPEN) .
- Analytical Calculations (having a pipe cross section,
pressures across a valve, and temperature of the fluid,
one can calculate the flow rate across the valve) [34]. 72
- Causal relationships between unlike parameters (such
as: if there is an electric output from the turbine-
generator, then the turbine stop valve is open).
Note that this methodology is relying on unlike sensor data comparison and thus, common cause failures or instrumentation channel drifts are no longer problems. By the same argument, the reliability of the calculated data is potentially higher because common cause failure cannot play an active role in this calculation.
Another important factor to avoid in this routine is that validation of one sensor should not rely on information supplied by another sensor which is on the Suspicious
Sensors List (SSL). That is, one has to rely on the
"potentially valid" data as redundancy for a suspicious sensor, as opposed to "potentially faulty". And since in this algorithm, it is assumed that all sensors are reliable until otherwise suspected, then the number of sensors available for backup value calculation is only limited by the total number of possible inferences and/or relationships between different sensors.
Once the diagnostic reasoning is completed and all the diagnostic conclusions are reached, this added source of information is used to either VALIDATE or REJECT suspicious sensor data. The methods of obtaining backup data to suspicious sensors are arranged in the order of preference, taking into account the reliability and cost of each method. 73
This analysis is done in the "Intelligent Sensor Validation" part of the expert system (Fig 15).
One should note that the diagnostic conclusions are used in this expert system as another source of redundant
information. This means that only under the context of a
specific diagnostic hypothesis (fault) certain data are
examined (as an example, the DRYWELL PRESSURE data is
examined under the context of a LOCA).
PLANT DATA DIAGNOSTIC CONCLUSIONS CONVENTIONAL KNOWLEDGE SENSOR BASED EXPERT VALIDATION SYSTEM SUSPICIOUS ROUTINES FOR D A T A ^ DIAGNOSIS
INTELLIGENT SENSOR VALIDATION
USER OTHERSOURCES INPUT OF INFORMATION
Figure 15. Sensor Validation Routine Block Diagram 74
The redundant information and related functions for validating sensor data are placed in the sensors hierarchy
(Fig. 16). Each node on this tree contains methods for validating related parameters (eg., the Feedwater node has methods to validate Feedwater Temperature and Flow ) and these parameters are simply Instances of each node. (eg. the question of "What is the feedwater temperature" is asked from FeedWaterTemp instance of the Feedwater Node.) Using these extra sources of information, the suspected sensor data can be accepted (validated) or rejected.
Glass Inheritance Lattice AuxTanks Containment Drywell ECCS FeedW ater Pumps Reactor RecircuIationLim Sensors Steam SuppressionPool Turbine FWTurbineCV MSIV ValvesPosition SRV TurbineCV T urbineStop Valve
Figure 16. Sensor Lattice 75
Once the faulty sensor(s) is identified, there are two routes that can be taken:
1. Replace that faulty data with the new (and validated)
value and repeat the diagnosis, after informing the
user,
2. Ignore that faulty data (mark it Unknown) and repeat
diagnosis, after informing the user.
Since there exists only one correct diagnsis of the state of the plant, then both of the above methods must lead to the same diagnostic conclusion. However, the first method is adapted for this research project, because it is a more elgant method and easier to implement.
3.3 Summary
In this chapter, the diagnostic methodology has been described and confidence factors in the context of diagnostic statements were discussed. Aslo, in this chapter, a new technique has been detailed for sensor data validation relying on indirect measurements and diagnostic conclusions. CHAPTER IV
CSRL MODIFICATIONS AND DATABASE DESCRIPTION
In this chapter, details of the sensors database, sensor validation methods, and sensor instances are defined, and their utilities are discussed.
The required information for an expert system can be supplied from several sources such as the operator, direct query from a process control computer, or a database. The expert system of interest in this dissertation is of the- type that uses the latter, ie., a database.
This system's database is substantially different from the traditional CSRL based expert systems and will be discussed here in detail. The CSRL modifications and query functions are also presented in this chapter.
4.1 Components of the Database
Traditional computer codes in general require data to start execution. These data for the unmodified CSRL are acquired by querying a current-case database or the user about the parameters which are required to establish or reject a malfunction hypothesis. The standard query functions of CSRL are designed in such a way that the relevant answers are first sought in the database and should an answer not be found, then the user is prompted for an
76 77 answer. The given answer to each question is then stored in the database for subsequent queries.
Initially, it appears that the modified CSRL system is working in the same manor as before. However, if the system is inspected closer, the database access functions reveal a substantial difference. In this sytem, each parameter is stored as an "Instance" of a sensor in the sensors tree
(Fig. 16). In these instances, there are slots which are each allocated for a special function. These slots (Fig.
17) are called Instance Variables (IV).
All Values of SRV SSRVOpen. StringQuery "Are there any SRVs open" SensorType Position SpecialistUsedThisSensor (LOCA ReliefValveQpen ClosedMSIVs)
Figure 17. Instance Variables of Reactor Pressure
At this time, there are only three IVs for each parameter:
1. StringQuery - The string of characters (which is used
in asking the user about the parameter). This string
and the given answer are stored in the current case
database for future reference by the expert system.
2. SensorType - The type of sensor that measures each
parameter. The sensor type is normally a LISP Atom (ie., a single word) and points to a method of the same
name, to calculate a backup to this specific parameter.
The above method resides in the parent node in the / sensors tree.
3. SpecialistUsedThisSensor - The names of all specialists
that have used this parameter are stored. At this
time, this IV must be filled manually. But since an
accidental exclusion of one or more specialists can
cause problems in the sensor validation routines, this
must eventually be filled automatically. The reason
for storing this information is that once a parameter
is marked suspicious (or potentially faulty), one may
wish to examine the rest of the malfunction specialists
that have used this sensor value to check whether or
not their overall expectations are met with the current
value of the sensor.
This method of collecting data and storing data, enables expansion of the database as needed. As an example, once this system is ready to be linked to a process control computer, then another IV will be needed to store the Point
ID of each sensor on the computer so that the computer and expert system can easily communicate. Another IV can be used to store the calibration information of each parameter so that in the event of recalibration or changing of the sensing line components, the new information can be utilized with great ease. 79
4.2 Different Query Functions
The standard CSRL had several already built in query functions. These functions were capable of handling most of the situations in a simple diagnostic system. However, these functions did not incorporate sufficient detail for use in the nuclear power plant diagnosis domain. The new query functions, as will be discussed in the following paragraphs, are designed such that they can deal with more detailed levels and trends.
The first function is called AskHLN?. This function is used when the answers to a question can be of the type high, low, or normal. This function was modified so that five levels of answers would be possible. The possible answers to these questions (and their proper syntax in parentheses) are: (1) Very high (HH), (2) High (H), (3) Normal (N), (4)
Low (L), (5) Very low (LL), or (6) Unknown (U). The different levels for answers lend themselves naturally to the nuclear power plant domain indications, and current standards for labeling parameters (such as reactor (BWR) water level, neutronic power level, or reactor pressure vessel pressure).
The second function is called AskTrend?. This function was developed to incorporate queries about the time dependent rate of change of a parameter, and thus, handle some of the time dependent plant diagnosis. The possible answers to this function are: (1) Increasing rapidly (II), 80
(2) Increasing (I), (3) Steady (S), (4) Decreasing (D), (5)
Decreasing rapidly (DD) and, (6)Unknown (U). These answers can be used to indicate different trends for each parameter.
The use of this function enables us to handle time varying data a step beyond the current practice in the AI society.
It also facilitates the detection of slowly evolving abnormal conditions. This is accomplished by not having to wait for a block of time until a limit is exceeded on the absolute value of parameter, before the detection of abnormalities starts.
The third function is called AskYNU? which is a slightly modified version of AskTFU? a standard query function of CSRL. This function is used with answers of the type (1) Yes (Y), (2) No (N), or (3) Unknown (U). The
AskTFU? function has similar answers as following: (1) True
(T), (2) False (F) or (3) Unknown (U).
There is another query function available in CSRL which has not been used in this expert system environment.
However, it will eventually be used in the implementation of expert systems and thus, it is important to mention this function here for future reference. This function can be used in the integration of qualitative and quantitative parameters in CSRL. Called Asklnteger?, it is used for cases that require a numerical value for the answer. This function requests an answer between maximum and a minimum values specified by the user for error checks on the input. With 81 this function comes a large number of algebraic properties such as: greater than (Gt), less than (Lt), equal to (Eq), greater than or equal to (Ge), less than or equal to (Le), etc. [35].
Utilizing these query functions enables the expert system to collect information on an as-needed basis. Also, the AskTrend? query function enables the expert system to not have to rely on control room alarms in order to initiate a malfunction diagnosis. The reason for this is that most alarms function by detecting a violation of a limit on a parameter absolute value. This can sometimes take from fractions of a second to many hours. By making use of the direct data, one can gain an extra amount of time to initiate diagnosis by detecting limit violations on trends, and one does not have to wait for an alarm to go off before begining diagnosis. This can be a great advantage for early detection, system.
Another advantage is that by monitoring trends of data, leaks, transients, or malfunctions that could remain unnoticed for some time, can be detected. Thus, a proper corrective action can be initiated as soon as the diagnosis is completed.
Fianlly, from the probabilistic risk assessment point of view, by reducing the total number of components between the sensors and the expert system input stage, the reliability of the data is increased. The reason for this 82 is that an alarm component can fail without an actual sensing channel failure.
4.3 How the Questions are Asked and Where the Answers Stored
The knowledge groups in modified CSRL Specialists use the AskYNU?, AskHLN?, AskTrend?, and Asklnteger functions in conjunction with the LOOPS function GetValue to query the database or the user for the required data. An example of such query is:
(AskYNU? (GetValue $SRVOpen 'StringQuery))
The GetValue function retrieves the StringQuery
Instance Variable (IV) (for the above example, it returns
"Are there any SRVs open", as presented in Figure 17).
AskXXX? function uses the returned value (a string of characters) and the database is searched for an answer. If this question is asked for the first time, then the user is asked for a possible answer (Yes, No, or Unknown for this example) and the string, along with the answer is stored in the database. If this question is asked again, then the previous answer is provided directly to the knowledge group.
By creating the Sensor Datum (SD), otherwise known as
Instances of sensors (Fig. 17), the sensor database can contain a large variety of information. As an example, the current sensor database contains the following information:
a) StringQuery - This slot contains the character string
for querying the user, or the database. b) SensorType - This slot contains the sensor type. Some
of the possible sensor types are: Position, Pressure,
Temperature, Flow, and Flux. The Sensor type is also a
reference to a LOOPS Method for validation of the
specific sensor. In the above example, the Method of
validation is called: "SRV.Position”. The first part
of this method name is the name of the sensor node on
the Sensors Tree and the extension is the actual name
of the Validation method,
c) SpecialistUsedThisSensor - This slot contains the name
of the specialists that use this sensor in their
decision process. This list is used during the
validation procedures.
A few more slots have been proposed in this research which will be incorporated into the next generation of this expert system. These include:
a) PointID - In this slot, the Point Identification of a
sensor is stored. The Point ID is the identification
method of various data points on the plant's process
control or SPDS computers, and can be used when the
expert system is ready for direct communication with
the plant computers.
b) Status - In this slot, the state of the sensor is
stored. Some of these states are: operational,
unavailable, or, unreliable. These values can be used
by the Procedure Synthesis Expert System for evaluating the reliability of the available data.
c) Calibration - In this slot, calibration information for
various sensors are stored, if such data is available.
As an example, the calibration curves for thermocouples
can be stored in this IV.
d) Limits - In this slot, the limits of the sensor are
stored. As an example, reactor pressure, during normal
operation of the plant, can only be between 0 to 1100
psig.
This method of storing and retrieving sensor data is a compact way of grouping all necessary information regarding sensors. Another advantage to this method is that in case of a change in any of the related information, updating the database with the new information is an easy task and only has to be done locally. CHAPTER V
MODEL VALIDATION AND VERIFICATION AND SAMPLE RUNS
In this chapter, the steps towards validation and verification of this expert system are described and three sample runs are presented. These examples are illustrative of this expert system's power in diagnosis and sensor data validation.
5.1 Expert System Model Validation
Validation of the model was performed to ensure its proper operation. In this section, the validation steps are discussed.
For each node of the hierarchical malfunction structure, there are several knowledge groups which contribute to the final diagnostic decision. For each one of these knowledge groups, depending on the sensor patterns and combination of sensor data, a confidence factor is obtained. The confidence factor for each specialist is based on the combination of the confidence factors of its knowlege groups.
An incorrect confidence factor or an unexpected combination of input data can potentially lead to incorrect diagnostic conclusions. Two such incorrect diagnostic statements are: (1) specialists do not establish when they
85 should have, and (2) specialists get established when they should not. To ensure a sound performance ofthe expert system in diagnosis, all of the tip nodes must be tested.
One of the possible possible testing procedures may include the following steps:
1. A malfunction scenario corresponding to a tip-node
specialist is selected.
2. The normally-expected initial symptoms of a selected
scenario are determined and the results are tabulated,
as shown in figure 18. The best results are obtained
by assuming all of the sensors are operating normally,
i.e., no sensor malfunctions are present. These
expected symptoms are obtained from one or more of the
following sources:
a. System description and operating manuals,
b. Opinion of experts,
c. Data from real system transients,
d. Results of computer codes that provide transient
analyses,
e. FSAR descriptions of the scenario and the expected
symptoms for this scenario, along with data
trends.
f. Perry Simulator runs of the proposed scenario and
recording of the data for later analysis. This
analysis must include corrections due to simulator
speed and accuracy of simulation. 87 TITIM Relief valve Stuck Open am 2/4/»s DATE OF XBST 2/4/86 ARSVKR a n s w e r I f QUESTION t m NORMAL OTHER TEAM NORM
A. REACTOR 1 Is Ob* reactor pressure belov 300 pal* TWO | N Is the reactor pressure above 100 paia TWO | Y What is tha raaetor praasur* KIN | H What is tha rsactor praisura trsnd IDS | B What is tha rsactor vatar larval HIX | N What is tha rsactor vatar laval trsnd ZDS | S What is tha rsactor povar lsval KIN I M What is tha rsactor povar larvaltrsnd IDS | S What is tha coolant conductivity BIN | M What is tha coolant conductivity trsnd 106 | 6 Ara all MSIVa opan YWD | Y Ara tha raeirc FCVs in normal position YND | Y Ara all SRVs eloaad YND | Y Ara all of tha SRV micro switches off YNU | Y What is tha pressure of the SRV dovneoaer HIM | N B. SUPPRESSION FOOL and CONTAINMENT
What is tha supp pool vatar laval HIM | N What is tha aupp pool water level trend IDS | S What is tha aupp pool temperature HIM | N What is tha supp pool tesperature trend ID6 | S Is there a supp pool tesperature imbalance YND | N What is tha dryvall temperature HIM I N What is tha dryvall temperature trend IDS | S What is the dryvall sump laval HIM | N What is tha dryvall sump laval trend IDS | S What ia tha dryvall pressure HIM | N What is tha dryvall pressure trend ID6 | S D. rZEONATER and STEAK FLOW
What is tha feedvatar flow rata BIN | N What is tha feadvatar flow trend I M 1 S What is the feadvatar temperature HIM | N What is tha feadvatar tsaperature trend ZDS | S What is tha staaa flow rata BIN | N What is tha staaa flow trend IDS 1 S What is tha hot surge tank level ' HIM 1 N E. ECCS AND RCICS 1 Are there any alarms shoving ECCS initiation YND | N Ara any of tha RHR pumps running? YND | N Ara any of tha LPCI nods valves opan YND | N la HPCS lined up to spray vatar in RFV YND | Y Is HPCS puap running YND | N Is RCIC lined up to deliver vatar to RPV YND | Y Is tha RCIC pump running YND | N la tha LPCS lined up to inject vatar to RFV YND | Y Is tha LPCS pump running YND | N F. TURBINE, CONDENSER and RWCD SYSTEMS
Are tha turbine bypass valves closed YND | Y Are tha turbine FCVs in normal position YND | Y What is tha turbine electrical output BIN | N Is there any laakaga in tha condenser tubas YND | N What is tha condensate storage tank laval BIN | N What is tha condenser pressure BIN | N What is tha condenser pressure trend U S | S What ia tha condenser temperature BIN | N Whst is tha condenser tsaperature trend IDS | S Ara the deainaral iters working normally YND | Y Has tha Rad Waste Clean Op Systaa failed YND | N
COMMENTS: Safety Relief valva Stuck Opan vitb the alcro-svitch position indicator falias closad. Figure 18. Expected Symptoms of SRVStuckOpen Malfunction •88
3. The expert system is then asked to identify the
initiating event, after inputing the obtained data in
step 2. If the diagnosis is correct, then that
specialist has passed the test. Otherwise, the
knowledge groups, after a validity check of the input
data, are modified (data combination and confidence
factors of the knowledge group) until the desired
result is obtained.
4. The rest of the system is then executed to ensure that
other nodes will not fire when they are not supposed
to. If any of the specialists fire incorrectly, then
their knowledge base (knowledge groups) must be
modified to correct their behavior. This modification
must be performed after reevaluation of the input data.
The above steps are continued for all of the scenarios related to all the tip nodes of the malfunction hierarchy.
In the following section, the conventions for running this expert system is discussed and at the end, three of the sample runs are presented and discussed.
5.2 Conventions for Running This Expert System
There are two stages in successful execution of this expert system. The first is setting up the environment (or the Browser Windows), and the second is running the code.
These steps are described in this section. It has been assumed that the user has a minimum knowledge of the Xerox
1108(09) or Xerox 1186 Lisp Machine operation. 89
Step 1. Setting up Browsers
Two Browsers must be set up before the expert system execution can be started. The first is called the
NPPBrowser and the syntax for setting it up is:
(_New $NPPBrowser Browse '(NPPSpecialist CoolSysFault Specialist))
The user is then prompted to position this newly created window somewhere on the screen. In the above syntax, $NPPBrowser is the LOOPS Object that contains the new "Diagnose" method, NPPSpecialist contains the new
Establish-Refine routines, and Specialist contains the rest of the traditional CSRL methods. Finally, CoolSysFault is the actual expert system.
The size of the Browser window can be adjusted by the following procedure:
1. Point the cursor to the title bar of the Browser
window, click the middle button, and hold it in the
down position.
2. Select the "Recompute" option of the available menu, and
the "SelectFont" option from the submenu. Release the
middle button.
3. Select the desired character font and size.
4. The tree is then redrawn and the Browser Window is
reshaped. If it does not reshape automatically, then
select "Recompute" from the title bar menu and release
the middle button. » 90 The next Browser is for the Sensors hierarchy. You can go to this browser by the command:
(Browse 'Sensors)
The user is then prompted for positioning the window. The window size can be adjusted in the same fashion as above.
The above steps will set up an appropriate environment for running the computer code.
Step 2. Execution
Before the start of execution, if there is a database already available on the machine that needs to be loaded, then, from the title bar menu of the NPPBrowser, the
"LoadCase" option must be selected. The user is then prompted to give the name of the case to be loaded. This step will load all of the necessary data for a currently existing example of the expert system run.
Execution starts by pointing the cursor to the
CoolSysFault node (Specialist) and selecting "Diagnose11 with the left button. Then the user is prompted to answer the appropriate questions. The steps that follow are similar to the standard CSRL code, and there is no need for describing the steps, as they are already available elsewhere [35].
There is, however, one extra step in this code. The last question that the user is asked is the "Validation"
Procedure. The available options are: (1) Manual
Validation, and (2) AutoValidation. The two differ only in that in manual validation, the user has to select a node 91 with in its confidence value, and then send a validate message to it by clicking the left button and selecting
"Validate" option. In AutoValidation, the specialist, which is selected automatically, will be the first Tip-Node with * in its confidence factor.
Three examples of these runs are available in Appendix
A. The results are discussed in the next section.
5.3 Sample Runs
The results from three sample runs of the proposed expert system prototype are presented in this section.
These sample runs demonstrate the applicability of this method of diagnosis and sensor data validation.
For each sample run, a scenario is designed with an initiating event and several assumptions. The events initiating these scenarios are discussed, and the assumptions for each case are listed. For these three examples, it has been assumed that the plant is operating at
100% power at a steady state condition.
Conflicting sensor data can in general cause three classes of diagnosis. These cases are as follows:
1. Incorrect data has a minor impact on the diagnosis of
the malfunction, and the final diagnosis is correct.
This means that the presence of that sensor data is
neither necessary nor sufficient, and is only a
complementary element in establishing the malfunction
hypothesis. 92
2. Diagnosis cannot be completed until validation of
incorrect sensor data is completed. In such a case,
the suspected sensor has a major impact on the final
diagnosis, and depending on which value is accepted, a
malfunction hypothesis may be established or rejected.
3. Due to incorrect data, an incorrect diagnosis is
reached, and after sensor validation, diagnosis is
reversed. In such a case, two values of the same
sensor are acceptable to one malfunction specialist,
and the incorrect sensor data cannot be detected in
that specialist.
These cases vary widely in terms of the diagnostic results reached before and after sensor validation. The first two cases frequently can be encountered in the nuclear power plant diagnosis and data validation domain. However, situations of the third type are very rare in this domain.
The reason for this is that most sensors in the nuclear power plant domain are redundant and closely coupled, and there is also an aboundance of sensors in different and related parts of the plant that can be used to indicate a malfunction. However, for the sake of completeness, this case is also demonstrated with an example, even though this example may not be realistic.
It should be mentioned that the first two scenarios are the result of data gathered from visits to the Perry
Nuclear Power Plant simulator, near Cleveland, Ohio. The 93 last one, however, is just to prove the point and for the above mentioned reasons may not be a very valid example.
Nevertheless, as will be demonstrated later, this expert system is capable of handling such situations.
Case 1. There is enough evidence to confirm a diagnosis and to also identify an individual faulty sensor.
For this example, a LossOfFWHtr (Loss of feedwater heater) accident is considered. In this scenario, it is assumed that the feedwater temperature sensor has failed and is indicating High.
During the first run (i.e., diagnosis based on the faulty sensor data), the system is capable of identifying the LossOfFWHtr malfunction with a high degree of confidence
(3*) (Fig. 19). The *, as was mentioned in previous chapters, indicates that further analysis of the data in this specialist is needed.
The basis for reaching the malfunction diagnosis is:
1. Increasing reactor power level (neutronic),
2. Normal and steady steam and feedwater flow rates, and
3. Normal and steady water level.
In the process of validation, the existance of conflicting evidence is sensed and • indicated in the
Suspicious Sensors Window (SSW). As will be discussed in the next paragraph, the validation procedure indicates the new value for the feedwater temperature should have been different (Low or Normal). This new value is substituted in Suspicious -Sensors - Window
*r flW .C ftt
'CondaaarTuboLoak Case 1 confidence value browser HlshCeefantCondudivitm .RWCUFalt .DamlnaralUorFail
-RaelrcFCVErr
CotdWatarAcr ’LoaaOfFWHTR •HtghPrraaDoaToEHCFaoll
■Turt>L«adR«|WOBjrpaaa •LeaaOfCfrePump LoaaOfHaatSlnk. .StaamAlrE|actovFall
‘TurblnaCenlrolValva RCIC ’MghPraaauraSyataaT ECCSAFWCErr
KlgNnvtnK ‘LavPraaauraSyatai
1 FWControllarFal!M|h .MghFWDSchPraaa >FWControdof Fall Low ■FWPSuclValvaClar L*»HP8H ,FWPTurbTrlp/LowSpood< .FWPTufbCntrlVal?oClar ■LowCondVae ‘ Low FW B PSuc tPrata ‘HlghFWBPOaefiPrtaa .LoaaOfFoodwatarFloWi ‘LowHolSurgaTank
‘kiadvartVatvaCtar ‘LowPraaaDuoToEHCFault
>H«lWttlTank -HotSurgtTank CondtnaaiaBtoragtTonk •OtharSmallLoakagoa - OutaldtContaiiwaanlLOCA LOCA, •laamUnaBraak.
.RaelreLlftaProblaw RvlftfVaivaOpan
Figure 19. Loss of Feedwater Heaters Accident Before Sensor Data Validation ■CfcVO 95 the database and again, diagnosis is initiated to check the validity of these calculations. The final diagnosis and faulty sensor are represented in Figure 20.
There are several methods for calculating a new value for the feedwater temperature. The most desirable method is to check if the feedwater heater is operating normally
(i.e., check the confidence factor of LossOfFWHtr node, via the GetConfidenceValue function in the standard CSRL). But, since the suspicous data originated in this node, another method is required.
The backup measurement for the feedwater temperature is obtained by a simple qualitative mass and heat balance, using parameters from the shell and tube sides of the feedwater heater heat exchangers (namely flow, pressure of the extraction steam on the shell side, and the inlet temperature and flow rate of the tube side) (Fig. 21).
After the new value is calculated, the new diagnostic statement confirms the previous one, as well as the faulty temperature sensor, and the * is removed to show that the new value is acceptable by all other specialists in the hierarchical tree.
Case2. The diagnosis is reversed by the results of the sensor validation.
An inadvertent closure of the MSIVs (ClosedMSIVs) will be considered in this example. If the MSIVs close, the
Safety Relief Valves (SRVs) should cycle to relieve and Suspicious -Serisors-Window — ^ Tha answer to the question of: "What is the feedwater temperature was changed from H To L
NPPSpaelallat i “‘CondaaarTubalaak HlghCoolantConductlvit) -R W C U F all Casel! confidence value browser ..DamlnaralUarFall
RaelrcFCVErr
RK*OtarPo«a ColdWaiarAcc*
HtflhPraaaDuaToEHCFaull
TurbL.oadR«(WOBypaa« »LeaeOfClrcPu*ip CondtnaarFalU LoaaOIHaatSInk «StaamAlrEfac1orFalt CloaadMSIVa
TurbinaContrelValva
HighPraaauraSyatam ECCSAFWCErr
CeetSyaFaull
FWControllarFallMgti
HlghFWOSchPraaa FWCentroSarFailLow FWPSuclValvaClar L ow N P S H FWPTurbTrfpflowSpaad FWPTurbCntrlValvaClar LowCundVae FWBPTrip. ~lo»FW BPSuclPraaa “ HlghFWBPDachPraaa loaaOfFaadvaterFlew ~LowHolSurgaTank HfghFwmeken
InadverlVaTvaCler LowPraaeDueToEHCFault
HolWallTank HlghAutTankLa HetSurgaTank CendanaalaSteragaTank OtharSmafllaakagea OutaldaContalnnwntLOCA
SlaamUnalraak
RaclrelfnaPrablaw RallafValvaOpan
B p a d a lta t
Figure 20. Loss of Feedwater Heaters Accident After ID Sensor Data Validation cn 97 maintain pressure in the Reactor Pressure Vessel (RPV). For this scenario, it is assumed that one of the SRVs fails to reclose after opening.
To make the scenario more complicated for malfunction diagnosis, it is also assumed that the direct indications of
SRV and MSIV positions have failed and read CLOSED and OPEN, respectively. That is, the control board lights do not change from their pre-event indications.
During the first run of the diagnostic system, the LOCA node has fired with a confidence value of 0* to show more evidence is required to either Establish or Reject the LOCA possibility. Further up in the tree, the CiosedMSIVs and
TurbineControlValve nodes fire with confidence factors of 1*
Secondary (Shell Side)
Primary Primary (Tube Side) (Tube Side)
© ©
Secondary (Shell Side)
______Flow Sensor
^ ------Temperature Sensor ______Pressure Sensor
Figure 21. Schematic Diagram of the Feedwater Heater 98 and 3*, respectively. This means there is a mild indication of MSIV closure and therefore, strong evidence for the wrong turbine control valve positions (normally, the TCVs would remain open until the turbine is manually tripped by an operator). Also, there is no indication of an open SRV. The results of this example are presented in Figure 22.
During the sensor signal validation step, the list of suspicious data is inspected and validated. Backup information for the SRV position is obtained from the local
Suppression Pool temperature and the SRV-downcommer pressure
(Perry specific). The backup information for the MSIV position comes from matching the Steam Flow Rate, Reactor
Pressure and Turbine Electrical Output.
After validation of the suspicious sensors, the new values are replaced in the database, and diagnosis is restarted from the top. At the end of this step, shown in
Figure 23, the new diagnosis indicates a confidence factor of 2 for LOCA, 3 for SRVOpen and 3 for ClosedMSIVs. The confidence factor of the TurbineControlValve node is also changed from +3* to -3 to account for the fact that the
MSIVs are the cause of the observed symptoms.
Case 3. Diagnosis cannot be completed until the validation is completed.
One of the interesting situations that can be encountered in a complex engineering system is that one can arrive at an incorrect diagnosis due to faulty sensors. Suspicious -Sensors -Window
fcr V f.CIRl
’CondeaerTubeleak , HlghCeetantCondudlvlljh .RWCUFall .DemtnarallxarFall
RaelrcFCVErr C a s e 2 conlidence Wtlue browser 'I ■ColdWaterAcc*
• HI ghPreaaDueTaEHCFault
>TurbLeadRe|WOBypaet .CondanaarFall^" ■LoeaOfCircPump LoaaOf HeatSink. ■BtaamAtrE|ectorFall
‘TurbineControiValv* RCIC 'MghPreeaureSyateai' HPCS ECCSAFWCErr •LPCI 'LowPraeaureSyaiei
FWControllerFeNWgh •HlghFWDSehPreaa ■FWContr oft erFaHLi •FWPSuctVaJreCJar ■LewNPSH .FWPTurbTrlp/lowSpeed. .FWPTurbCntrlVatvaClar .LewCendVae ’LowFWBPSoctPreaa FWBPTrl] HighFWBPDachPreaa .LoaaOf FeetfwaterFI) LowHotSurgeTank
‘tnadvertVelvaCler LowPreaaDueToEHCFault •HotWedTank 'HlghAutTankLoi -HotSurgeTank ■CondenaataSteragaTank -OtherSmatlLaakagaa -OutaldaContalnnentLOCA
LOCA. ■SttamUneBreak.
.RaclrcUnaPrebtaaa .RellefValvaOpan
Speciallet
Figure 22. Inadvertent Closure of MSIVs and Open SRVs Before Sensor Data Validation VO VO Suspicious -jjuiisors -Window TIib answer to the question of: “Are the MSIVs open“ was changed from T To F The answer to the question of: “Are there any SRVs open" was changed from F NPPSpactallat To T ’’’CondaaarTubaLaak Casii^ uunlidiMicti value browse MghCoofantCooductlvIt -RWCUFall .DamlnaralUarFall
RaelrcFCVErr
R*»OvarPowa ColdWaUrAee- HlghPraasDuaToEHCFautt TurbLeadRa/WOSypaaa •LoaaOfClrcPump CondanaarFall- LaaaOfHaatSInk »StaamAlrEJactorFa!l CloaadMSIVa TurblnaControlValva RCIC HtghPraaauraSyatan
ECCSAFWCErr
CHtSyiFiitli FWControltarFallMgli HlghFWDSctiPraaa FWContralfarFallL«w FWPSuclValvaClar lawMPSH ,FWPTurbTrlp/low3p«td FWPTurbCntrlValvaCtar LowCondVac LowFWBPSuetPraas HighFWBPOachPraaa LoaaOf FaadwatarFloa Una-A LovHotSurgaTank MghFWRaelrc JnadrartVahraCJar
KotWamank HighAuiTankLa HotSurgaTank CondtnaatoSloragaTank OlharSmalllaakagaa Out aida Con lal i h m ntLOC A StaamUnaBraak
RatlrcllwaFrablw> RtlialValvaOptn
Spadallat
Figure 23. Inadvertent Closure of MSIVs and Open SRVs
After Sensor Data Validation 100 1 0 1
This means that after sensor validation, the updated
diagnostic conclusions are reversed. This situation is
highly unlikely in the nuclear power plant domain, due to
the following reasons:
1. High degree of sensor redundancy,
2. Closely coupled sensors, and
3. Known intersensor relationships.
This situation, however, is likely in other domains
such as refinaries and other chemical processing plants that
do not have the redundancies inherent in nuclear plants. The
sensor validation routine is designed such that the above
situations also can be handled. It is important to mention
that finding an example in the nuclear power plant domain
which is of serious interest is difficult. For the sake of
completeness, however, this case is hypothesized.
In this example, the ECCS initiation alarm has failed
and the HPCS injection is initiated (due to some unspecified
reason) and thus, a high inventory is caused, in conjunction
with a Rx-OverPower situation because of the cold HPCS water
addition.
During the first run, the node Highlnventory is
rejected by looking at ECCS alarm and FWpump speed being
normal. (In an actual situation, this diagnosis must be
level dominant and the hypothesis of Highlnventory would have been established first. The reason that this important piece of evidence is not used is that this example is 1 0 2 hypothesized to just demonstrate the power of this methodology.) However, the HPCSInjection node under the
RxOverPower specialists is established with a confidence factor of 2* (Figure 24).
During the sensor validation stage, the related parameters to HPCS are examined. The HPCS motor current,
HPCS injection and bypass valves positions confirm that HPCS has started and water is delivered to the reactor pressure vessel. This new HPCS status is placed in the database and diagnosis is repeated.
After sensor validation, the Highlnventory is
Established (CF=3) by having all indications of higher level and the source of this extra inventory (HPCS ON), and further Refinement indicated that Highlnventory is due to
HPCS injection. The CF of HPCSInjection is improved to +3, as a result of the sensor validation (Figure 25).
The ECCS alarm is validated by inspecting the HPCS pump status and the related HPCS injection valves being open for this system.
In the above scenarios, it has been assumed there is sufficient data to calculate a backup value for the suspicious sensor. These data are used as an independent measurement to validate or reject the suspicious sensor data. There are situations however, that the above calculations are not possible. These situations are as follows: Suspicious -Sensors - W in d o w
'CondaaarTubaLaak HighCootantConductlvIl .RWCUFall .DamlnaralimFoll
HPCSIn|#eUon Ri*OvarPowor ColdWatarAce- ■LoaaOf FWHTR .asoU confidence value browser ■HighPraaaDuaToEHCFault
-TurbLoadRa|WOBypooo .CondanaarFalL^^^^-- • LoaaOf ClrcPump XeaaOffiaatSlnk. .StaamAlrEJacterFall
TurblnaControfVatva RCIC ’MghPraaauroSyatan' HPCS ECCSAFWCErr LPCI ■LowPraaauratjratai •LPCS -FWControMarFaflMgh
•HtghFWDSehProaa ■FWControHarFollL' ► FW PSuct Val vo Cl ar • LawNPSH .FWPTurfcTrip/LowSpaad, .FWPTufbCntrlValvaClar .LowCofidVae
'FWBPTrli ’LowFWBPSuetProaa .LoaaOf FaadwatarFlow, HlghFWBPDachPraaa ’LowHotSurgaTank
’kiadvartVahroCtar LowPraaaDuoToEHCFatdt
•HolWallTatik ■HighAuiTankLar^^^^^ ■HotSurgaTank ■CondanaataStoragaTonk ’OtharSmaflLookagao -OutaldeContalnawRtLOCA
LOCA. .SiaamUnaBraak.
■RaclfeLlftoProbla o .RatlafValvoOpon
Figure 24. Inadvertent Initiation of ECCS 103 Before Sensor Data Validation St>ec»abst browser lor NPP.CSHL ! Suspicious -Sensors -Window VP8pac1a11st The answer to the question of: Cowd«n»i»Ti*«t.a* 'Are there alarms indicating ECCS initiation" jHfghCooTantConductlvJty moral i was changed from F Dea1nera11xarfa11 To T RaclrcfCVErr HPCSInjection ColtfVatarAcc •Kx-OvwrPower Lo*«OffWttr
1. One or more of the sensors required to calculate the
new value is in the Suspicious Sensor List itself, and
it cannot be used in the above calculations.
2. One or more of the required sensors is not readily
available through the plant process control computer or
the Safety Parameter Display System computer and some
time is required before the missing data is available
through manual means. Two examples of this situation
are: (1) The coolant chemistry information, and (2)
Data which require an operator to check an instrument
in a remote plant location.
3. Calculation of the backup parameter is too costly and
uncertain to be done within the time limits and
tolerances of this expert system. An example of this
type of sensor is the RPV water level sensor of the
BWRs which is costly to analyticaly compute without a
direct measurement.
Should the system fail to calculate a backup value for a sensor due to any of the above reasons, the user is then informed of the suspicious parameter and its value, and he is asked to input the parameter manually. In order to assist the operator in his decision making, the specialists that have used this parameter and have *s in their confidence factors, as well as the ones that have used this parameter and do not have a * in their confidence value are displayed (upper box in Figure 26). The user is then asked Suspicious -Sensors-Window
Your answer to the question of: 'What is the feed w ater temperature" w as H Which I suspect is wrong Thu following specialists (which have used this sensor value) have *’s in their confidence values: (ColdWaterAcc LossOfFWHtr) MPPSpaclalial .illsts "CandaaarTubaLaak And the foflowii HlghCMiantCoAdudhrltm -RWCUFail do not have *’s their confidence values: (Rx-OverPower) . Daminarallxar Fall > I have done ad that I could havel It’s your turn nowlll varify and input the new valuo^f Uppercase please) RaelrcFCVErr se1 confidence value — HPCSInjection Ri«OvirPrai ColdWatarAcc* -LoccOIFWHTH HlghPraaaDwaTaEHCFault
TurbloadRatWOBypaaa -LoaaOfClrePump CortdanaarFalL LuaaOfHaatSInk — SlaamAlrE)actorFaII CieaadHSIVa TurblnaContralValva
HtghPraaauraSyatam
ECCSSFWCErr
CaolSyaFault LovPraaauraSjaia
FWCcntrollarFaflMgh HigliFWOScbPraaa FWCantrcMarFallLaw FWPSuclValvaClar .LewNPSH FWPTurbTrlp/lowSpaad .FWPTurbCntrlValwClar ■LawCondVac LowFWBPSuctPraoa HighFWBPDachPraaa LoaaOf FaadwatarFiaw Uita-A ‘LowHotSurgaTank MghFWRaclrcFl Lina«l fctadrtrtVcfraCfcj LovPraaaDuaToEHCFaidt
HotWatlTank KighAuiTankLt HetSurgaTank CondanaalaStaragaTank OtharSmaflLaakagaa Outalda Cental m m MLOCA StaamUnaSraak
.RaclreLfnaProbtaoi RallafValvaOpan
Spadallat H o Figure 26. Failure of Validation Routines o> 107 to verify the sensor data and input the new value, if one is needed. If the operator is unable to decide on a new value, then an Unknown (U) value can be used as an input to this expert system and diagnosis is resumed, using this value.
5.4 Summary
The steps towards validation and verification of this expert system performance have been discussed in this chapter. These steps, along with the necessary documentation, provide the basis for a successful operation of this expert system.
The syntax and semantics for running this expert system are described in section 5.2. This description is based on the assumption that the user has some familiarity with the
Xerox 1108(09), before running this expert system.
Also, as was seen in this chapter, this method of diagnosis is capable of identifying a malfunction, even in the presence of one or more faulty sensors. The sample runs illustrated the three classes of diagnosis under faulty sensors. These classes are different in terms of the diagnostic conclusions reached before and after sensor validation.
It also is demonstrated that in case the expert system were not able to decide on reliability ' of a suspicious sensor, then the user is informed of the suspicious sensor as well as the list of the specialists whose expectations were not met that have used this sensor, and the ones that 108 whose expectations were net. These steps are carried out to provide the user with more knowledge about the state of the systen and potentially faulty sensors. This has been typically called "a system failing gracefully". CHAPTER VI
RECOMMENDATIONS AND FUTURE PLANS
In previous chapters, the state of the developed expert system prototype and its functionality were described. This system and its usefulness can, however, be improved in several ways.
The expert system performance has been tested for several scenarios. The most important task that must be completed is extensive testing and documentation of the results of each malfunction specialist. A proposed testing procedure to follow may be the same as the one described in section 5.1. One key factor in the above validation would be the documentation of the results of each run. In a future implementation of this system on a "validated” full function simulator, these documents will be used for debugging and updating the knowledge base of this system.
One of the major assumptions that was made for this study was the initial conditions of the plant. This assumption stated the initial plant conditions are: (a) the plant operating at 100% power level, and (b) plant be running at a steady state. Even though the knowledge base of this system is based on deviation from the "Normal" values, this assumption limits the applicability of this
109 1 1 0 expert system in day to day operation of the plant.
One possible solution for the next generation of this expert system may be the implementation of a front end expert system to interface the plant database (or process computers) and to identify the "Normal" values for the plant conditions for any plant's power level and condition [36,
37]. The results can then be used in this already existing expert system. This is currently being pursued as a major part of the second phase of this project.
One basic defficiency with this methodology is the assumed sequence of diagnosis and sensor validation can cause difficulties in detection of faulty sensors during the normal plant operating conditions. The reason is the diagnoser is activated only when some of the parameters seem to be out of the ordinary, and normally a single outlying sensor would not initiate the diagnoser. Thus, the faulty sensor can remain hidden. This will not help the operator in a situation the apparent plant fault is due to malfunctioning sensors. If the failed sensor activates some of the plant's automatic systems, then the diagnostic problem is complicated even more.
Another problem in this system arises when the failed sensor remains hidden because of the "DIAGNOSTIC NODE" on the tree which questions that sensor's validity is not activated (its parent has been ruled out). This furthur complicates the diagnosis task, as well as sensor Ill validation, by creating incorrect diagnostic statements.
This diagnosis can be potentially not marked as questionable and thus, lead to confusion of the operators in assessment of the state of the paint.
The above two problems can be solved by implementing a
Plant Status Monitoring System (PSMS) [36, 37], to monitor all important plant parameters. PSMS can identify a parameter as an outlier and through a simple table look up
(a precompiled table), it can prescribe either sensor validation, or, diagnosis at a level other than the top node. This will activate the sensor validation system, on an "as needed" basis.
The sensor validation routines must then be modified to either request malfunction diagnosis directly from the diagnostic part of the expert system, or, for some cases, not rely heavily on the system's diagnosis. This information is used in validation routines, as was mentioned in chapter 4. A possible design for the PSMS is described in references 22 and 23.
An expert system performing any kind of problem solving, must be capable of explaining its own actions and the reasons for reaching a conclusion [38]. At the present stage, the proposed expert system is only capable of a limited explanation of its diagnostic reasoning in the form of tracing the rules and knowledge groups that fired, during the execution. However, no such facilities are available at 1 1 2 the present time for explaining the validation reasoning.
In order to further increase its usefulness to a plant operator, this feature must eventually be added, even if in a limited fashion.
Another area that can be improved is the handling of time dependent variables. As was discussed in Chapters 3 and 5, there was an attempt to partially solve this problem by incorporation of a new query function, namely AskTrend?.
An addition to this expert system is necessary to improve the ability to handle the above problem. This addition must be able to incorporate the functional description of parts of the plant subsystem to predict the expected behavior and to compare that behavior to its expectations. Then, based on these analyses, this expert system should be able to modify its own knowledge base, as the data change and transients evolve [39],
One area of necessary future research is the interfacing problems involved in the communication with the plant, should the incorporation of LISP machines in the control rooms be decided. Potential solutions for these problems is to rewrite the final version of the code on some other computer, such as a MicroVax, that is compatible with the currently existing plant computers, or to design a communication platform between the two computers.
Once the diagnosis of the plant's malfunctions is complete, the operators must be informed of the results. 113
Thus, human Interfaces must be developed for effective man- machine communications. The displays must qualify the requirements set forth by the US-NRC and must be acceptable by the plant operators.
Finally, the system's usefulness is increased by accompanying another expert system which is capable of prescribing corrective actions to the operator, once the diagnosis is complete. One such system is the expert system developed by Dr. Deva-Datta Sharma [14, 15, 32, 40], which dynamically synthesizes corrective procedures. CHAPTER VII
SUMMARY AND CONCLUSIONS
An expert system was developed for this project. This expert system is proposed to be a complementary part of the existing Safety Parameter Display System (SPDS). The main task of this expert system is to diagnose coolant system malfunctions of a General Electric boiling water reactor.
The nuclear power plant that was used as a model for this project is the Perry Nuclear Power Plant. This plant is a
BWR-6 with a Mark III containment, and is located near
Cleveland, Ohio. The Perry full-function simulator was used extensively for validation of the developed expert system.
As a secondary task, the expert system in this study is capable of detecting some of the faulty sensors based on violations of normal expectations derived during diagnosis.
In this methodology, if normal expectations of a malfunction are not met, then one or more sensors are marked as
"suspicious”, or "questionable”, and will be subject to further analysis. This extra source of information is proposed to be an additional level of redundancy to the traditional hardware redundancies that are implemented in current designs of the safety parameter display systems.
114 115
The traditional methods of sensor data validation are aimed at identification of gross failures of individual sensors by making use of sensors measuring the same parameter, i.e., having hardware redundancy. Some of the failures that can be identified by these methods are shorts, grounds, open circuits, cable and/or connector failures.
The proposed method of sensor validation can be especially useful when the traditional methods fail to identify instrumentation channel failures, such as common cause failures, and calibration drifts. Another case where this method of signal validation can be of potential value is when the addition of sensors at the hardware level is expensive, or not possible.
The input to this expert system is a set of fundamental parameters, such as neutron flux, flows, temperatures and pressures, as well as their respected trends. These data are assumed to have been subjected to the currently existing signal validation routines and an average value for each parameter is available. The task of partial validation and averaging is accomplished by the SPDS.
In order to achieve the above tasks of malfunction diagnosis and sensor data validation, CSRL [3, 28], an expert system building shell, was used. This programming language is a generic tool for development of expert systems for the main task of diagnosis and was first developed by the Ohio State University Laboratory of Artificial 116
Intelligence Research (LAIR), for diagnosis in the medical domain. Because of its origin, CSRL was developed for static, or slowly evolving situations. Thus, CSRL was modified so that it can achieve the required goals in this domain. Some of the major modifications of CSRL that were necessary for this project follows.
1) Query functions were modified to account for five
levels of input data, as opposed to the previous three.
The five levels of data are: Very High (HH), High (H),
Normal (N), Low (L), and Very Low (LL). These five
levels of input data lend themselves in a normal
fashion to the nuclear industry, as most of the
parameters have the same identifying labels in this
domain.
2) A new query function, namely AskTrend?, was added to
account for trends in the input data. This function
also incorporates five levels of input information.
These five are: Increasing Rapidly (II), Increasing
(I), Steady (S), Decreasing (D), Rapidly Decreasing
(DD). This information was determined to be of vital
importance in diagnosis of slowly developing
transients before their effects would show elsewhere
in the plant.
3) Extensive additons to the "CSRLCase" function were made
to accomodate editing, modifying, resetting, and
addition of data to the CSRL sample runs (databases). 117
4) The Establish-Refine routine was modified so that new
confidence values with *s, would behave as described in
this dissertation.
5) Browser functions for the output of this expert system
were modified so that the tasks of data validation is
possible, and the task of editing and resetting the
scenarios is simplified.
6) Finally, new functions were added and old functions
were modified throughout CSRL, to account for
suspicious data and to contain the data patterns of
knowledge groups. These data patterns are used in data
validation, as was discussed in this dissertation.
The modified CSRL was then utilized to meet the following objectives initially established for this research:
1. Diagnosis - Modified CSRL was utilized to perform
diagnosis in the nuclear power plant domain.
2. Sensor Validation - A methodology for enhancement of
sensor data validation was described. This methodology
is based on faulty sensor detection due to violation of
normal expectation of a malfunction, and is proposed to
be a complementary component to malfunction diagnosis.
This additional method of sensor validation can
identify common cause failures and instrumentation
decalibration. 118
3. Concept Demonstration - The above concepts were
demonstrated through several examples for this domain.
Two of these examples represent sample runs at the
Perry Nuclear Power Plant full function simulator.
The task of diagnosis accomplished by this expert system is proposed to be an addition to the SPDSs which are currently in use in the operating nuclear power plants. The reason for making use of the existing SPDSs as a front-end to this expert system is that SPDSs enable us to make use of their front-end data validation and database.
Also, as indicated in NUREG 0696, diagnosis is one of the desired objectives of the SPDS, and since this expert system is capable of performing efficient diagnosis, even in the presence of faulty data, then it becomes a strong candidate for such task. APPENDICES APPENDIX A
SAMPLE RUNS
1 2 0 {CASPIAN:LAIR:OHIO-STATE}
(FILECREATED "15-Jun-87 08:09:45' {CASPIAN:LAIR:OHIO-STATE}
changes to: (INSTANCES Casel) (VARS CASEICONS))
(PRETTYCOMPRINT CASE1C0NS) (RPAQQ CASE1COMS ((INSTANCES Casel))) [DEFINST CSRLCase (Casel "UOW0.1j[:.Vz6.1") (browser NIL) (valueBrowser NIL) (specialists (»&(CoolSysFault "UOW0.1j[:.Vz6.2") #»(LOCA "U0W0.1j[:.Vz6.3") #&(LowInventory "U0W0.1J[:.Vz6.4") 4>&(H1ghInventory "UOW0.1j[: .Vz6.5') #&(LossOfHeatSink "UOW0.1j[:.Vz6.6") #&(Rx-OverPower "UOWO. l j [ : . Vz6.7") #&(H1ghCoolantConductivity 'UOWO.1j [ : .Vz6.8") #&(ReliefValweOpen "UOWO.1j [ :.Vz6.9") #&(RecircLineProblem "UOWO. 1 j[ : .Vz6.10") #S(SteamLineBrk "UOWO. lj[ :. Vz6. U ") *&(Outs1deGontainmentLOCA "UOWO. l j [ : .Vz6.12") #a(OtherSmall Leakages "UOWO.lj[: .Vz6.13") #&(H1ghAuxTankLev "UOWO.lj[: .Vz6.14")
*&(LowPressDueToEHCFault "UOWO. l j[ : ,Vz6.15") #&(LossOfFeedwaterFlow "UOWO. 1J[: ,Vz6.16" ) #&(FWControllerFailLow "UOWO.1j [ :.Vz6.17") #&(FWControllerFailHigh "UOWO. l j [ : ,Vz6.18") #&(ECCS&FWCErr "U0W0.1j[:.Vz6.19") #&(TurbineControlValve "UOWO. lj[: .Vz6.20" ) 4>&(ClosedMSIVs "UOW0.1J[: .Vz6.21") 4*&(CondenserFa1l "UOW0.1j[: .Vz8.22") #&(TurbLoadRejWOBypass "UOWO.1j[ : .Vz6.23")
#&(HighPressDueToEHCFault "UOWO.1j [ :.Vz6.24") #&{ColdWaterAcc "UOW0.1j[:.Vz6.25") W&(RecircFCVErr "UOWO.lj[: . Vz6.26") W&(DemineralizerFall "UOWO.1j[ : .Vz6.27") #&(RWCUFail "UOWO.1J[: .Vz6.28") #&(CondenserTubeLeak "UOWO.l j [ : .Vz6.29" ) #&(LossOfFWHtr "UOWO.1j [ : . Vz6.32") #&(HPCSInjection "UOWO. l j [ : . Vz6.33”))) [SusOataList ((MLossOfFWHtr Reactor ((AskHLN? "What is the feedwater temperature") is H) ((AskTrend? "What is the reactor power level trend") is I) ((AskTrend? "What is the reactor water level trend") is S) ((AskTrend? "What is the feedwater temperature trend") is D] (stringOB (NIL NIL NIL NIL (("What is the suppression pool water level trend" . S)) NIL ((’Are the turbine bypass valves closed" . T)) (("What is the drywell temperature" . N)) NIL NIL NIL ((’What is the drywell sump level trend" . S) ("What is the turbine electrical output" . N)) NIL NIL (("What is the condensate storage tank level" . N)) NIL (("What 1s the turbine electrical output trend" . S)) NIL NIL (("What is the steam flow rate" . N)) NIL ((’What 1s the feedwater flow rate" . N)) (("What is the reactor pressure" . N)) ((’Has CoolSysFault completed diagnosis’ . F) ("What is the reactor pressure trend" . S) ("What is the feedwater temperature trend" . D)) ((’What is the hot surge tank level" . N)) NIL (("What is the feedwater flow trend’ . S)) NIL NIL NIL (("Are the MSIVs open" . T)) NIL (("Has ColdWaterAcc completed diagnosis" . F)) (("What is the drywell temperature trend" . S) 1 2 2 {CASPIAN:LAIR:0HI0-STATE}
("What 1s the drywell sump level" . N)) (("What is the drywell pressure" . N) ("What 1s the reactor water level" . N)) (("What is the drywell pressure trend" . S)) (("What is the reactor power level" . H) ("Is HPCS pump running" . F) ("What is the reactor water level trend" . S)) (("Are the recirc flow control valves in normal position" . T)) (('What is the reactor power level trend" . I)) ( ( ’What is the hot well le v e l’ . N)) (("What is the coolant conductivity" . N) ("Are the turbine control valves in normal position" . T)) NIL (("What is the steam flow trend" . S)) (("What is the coolant conductivity trend" . S) ("What is the feedwater temperature’ . H)) NIL (("What is the suppression pool water level’ . N) ("Has Rx-OverPower completed diagnosis’ . F)) NIL))]
[definst CooiSysFauit(CoolSysFaultCase1 "UOW0.1j[:.Vz6.2") (case Casel) (confidenceValue 3 explanation ((summary is 3))) (messagesReceived ((Refine CoolSysFault NIL) (Establish CoolSysFault NIL) (Establish-refine CoolSysFault NIL))) (variables ? anyEstablished? (T F F) specialist NIL) (sta te suspended) (summary 3 explanation ((Reactor is 3))) (SuppressionPool UnSetKnowledgeGroup) (Containment UnSetKnowledgeGroup) (Reactor 3 explanation (((AskHLN? "What is the reactor power level") is H) ((AskTrend? "What is the reactor power level trend") is I))) (Steam&Electric UnSetKnowledgeGroup)]
[DEFINST lo ca (LOCACasel "UOW0.1j[:.Vz6.3") (case Casel) (confidenceValue -3 explanation ((summary is -3))) (messagesReceived ((Establish CoolSysFault NIL))) (state active) (summary -3 explanation ((Steam&Electric is -3) (Containment is -3) (SuppressionPool is -3))) (SuppressionPool -3 explanation (((AskTrend? "What 1s the suppression pool water level trend") is S))) (Steam&Electric -3 explanation (((AskHLN? "What is the steam flow rate") is N))) (Containment -3 explanation (((AskHLN? "What 1s the drywell pressure") 1s N) ((AskHLN? "What 1s the drywell sump level") is N) ((AskHLN? "What is the drywell temperature") 1s N) ((AskTrend? "What is the drywell pressure trend") is S) ((AskTrend? "What is the drywell temperature trend") is S) ((AskTrend? "What is the drywell sump level trend") is S)))]
[definst Lowinventory(LowlnventoryCase1 "UOW0.1j[:.Vz6.4") (case Casel) (confidenceValue -3 explanation ((waterlev is -3))) (messagesReceived ((Establish CoolSysFault NIL))) (state active) (waterlev -3 explanation (((AskHLN? "What is the reactor water level") {CASPIAN:LAIR:OHIO-STATE}
[definst Highinventory (HighlnventoryCasel "UOW0.1j[:.Vz6.5") (case Casel) (confidenceValue -3 explanation ((LowInventorylnTanks is *3))) (messagesReceived ((Establish CoolSysFault NIL))) (state active) (WaterLevel -3 explanation (((AskHLN? "What is the reactor water level") is N))) (LowInventorylnTanks -3 explanation (((AskHLN? "What is the condensate storage tank level") is N) ((AskHLN? "What is the hot surge tank level") is N) ((AskHLN? "What is the hot well level") is N)))]
[definst Loss0fHeatSink(LossOfHeatSinkCase1 “UOW0.1j[:.Vz6.6") (case Casel) (confidenceValue -3 explanation ((summary is -3))) (messagesReceived ((Establish CoolSysFault NIL))) (state active) (summary -3 explanation ((Valves is -3) (Steam&Electric is -3))) (Valves -3 explanation (((AskYNU? "Are the MSIVs open") is T) ((AskYNU? "Are the turbine bypass valves closed") is T) ((AskYNU? "Are the turbine control valves in normal position") is T))) (Steam&Electric -3 explanation (((AskHLN? "What is the turbine electrical output") is N)))]
[definst Rx-OverPower (Rx-OverPowerCase1 "UOW0.1j[:.Vz6.7") (case Casel) (confidenceValue 3 explanation ((summary is 3))) (messagesReceived ((Refine CoolSysFault NIL) (Establish CoolSysFault NIL))) (variables ? anyEstabl ished? (T T) specialist NIL) (state suspended) (summary 3 explanation ((Reactor is 3))) (Water&recirc UnSetKnowledgeGroup explanation (((AskYNU? "Are the recirc flow control valves in normal position") is T) ((AskHLN? "What is the feedwater temperature") is U))) (Reactor 3 explanation (((AskHLN? "What is the reactor power level") is H) ((AskTrend? 'What is the reactor pressure trend”) is S) ((AskTrend? "What is the reactor power level trend") is I))) (HPCS UnSetKnowledgeGroup explanation (((AskYNU? "Is HPCS pump running") is F)))]
[definst HighCooiantConductivity (HighCoolantConductivityCasel "UOW0.1j[:.Vz6.8") (case Casel) (confidenceValue -3 explanation ((Conductivity is -3))) (messagesReceived ((Establish CoolSysFault NIL))) (state active) (Conductivity -3 explanation (((AskHLN? "What is the coolant conductivity") is N) ((AskTrend? "What is the coolant conductivity trend") is S)))J
[definst ReiiervaiveOpen(ReliefValveOpenCase1 "UOW0.1j[:.Vz6.9") (case Casel) (srvopen UnSetKnowledgeGroup) (press UnSetKnowledgeGroup) {CASPIAN:LAIR:OHIO-STATE>
(Reactor UnSetKnowledgeGroup)]
[definst RecircLineProbiem(RecircLineProblemCase1 "UOW0.1j[:.Vz6.10") (case Casel) (reclrc UnSetKnowledgeGroup)]
[definst steamLineBrk(SteamtineBrkCase1 "UOW0.1j[:.Vz6.11") (case Casel) (SteamUneBreak UnSetKnowledgeGroup)]
[definst OutsideContainmentLOCA(OutsideContainmentLOCACase1 "UOW0.1j[:.Vz6.12") (case Casel) (summary UnSetKnowledgeGroup) (SteamUneBreak UnSetKnowledgeGroup) (FeedWaterLineBreak UnSetKnowledgeGroup)]
[definst otherSmaiiLeakages (OtherSmallLeakagesCasel "UOW0.1j[:.Vz6.13") (case Casel) (recirc UnSetKnowledgeGroup)]
[definst HighAuxTankLev (HighAuxTankLevCasel "UOW0.1j[:.Vz6.14") (case Casel) (summary UnSetKnowledgeGroup) (cst UnSetKnowledgeGroup) (hotwell UnSetKnowledgeGroup) (hst UnSetKnowledgeGroup)]
[definst LowPressDueToEHCFauit(LowPressDueToEHCFaultCase1 nUOW0.1j[:.Vz6.15") (case Casel) (Pressure UnSetKnowledgeGroup)]
[definst Loss0fFeedwaterFiow(lossOfFeedwaterFlovvCase1 "UOW0.1j[:.Vz6.16") (case Casel) (mfwp UnSetKnowledgeGroup)]
[definst FHControiierFaiiLow(FWControllerFailLowCase1 "UOW0.1j[:.Vz6.17") (case Casel) (fwcfl UnSetKnowledgeGroup) (mfwp UnSetKnowledgeGroup)]
[definst FWControiierFaiiHigh(FWControllerFailHighCase1 "UOW0.1j[:.Vz6.18") (case Casel) (WaterLevel UnSetKnowledgeGroup) (LowInventorylnTanks UnSetKnowledgeGroup)]
[DEFINST ECCS&FWCErr (ECCS&FWCErrCasel "UOW0.1j[:.Vz6.19") (case Casel) (ECCS UnSetKnowledgeGroup)]
[definst TurbineControiValve (TurbineControlValveCasel "UOW0.1j[:.Vz6.20") (case Casel) (TurbineControiValve UnSetKnowledgeGroup)]
[DEFINST ciosedMSivs (ClosedMSIVsCasel "UOW0.1j[:.Vz6.21") (case Casel) (Reactor UnSetKnowledgeGroup) (MSIV UnSetKnowledgeGroup)]
[definst CondenserFaii (CondenserFailCasel "UOW0.1j[:.Vz6.22") (case Casel) (Vacuum UnSetKnowledgeGroup)] 125 (CASPIAN:LAIR:OHIO-STATE}
[definst TurbioadRejwOBypass (TurbLoadRejWOBypassCasel "UOWO.Ijf.'.Vze^B") (case Casel) (Valves UnSetKnowledgeGroup)]
[definst HighPressDueToEHCFauit (HighPressDueToEHCFaultCasel "UOW0.1j[:.Vz6.24") (case Casel) (confidenceValue -3 explanation ( (PressureRegFailClosed 1s -3))) (messagesReceived ((Establish Rx-OverPower NIL))) (state active) (PressureRegFailClosed -3 explanation (((AskTrend? "What is the reactor pressure trend") is S)))]
[definst coidWaterAcc(ColdWaterAccCase1 "UOW0.1j[:.Vz6.25") (case Casel) (confidenceValue 3* explanation ((Water&SteamFlow is 3) (WaterTemp is 3*))) (messagesReceived ((Refine Rx-OverPower NIL) (Establish Rx-OverPower NIL))) (variables ? anyEstablished? (T T T) specialist NIL) (state suspended) (WaterTemp 3* explanation (((AskHLN? "What is the feedwater temperature") 1s H) ((AskTrend? "What is the reactor water level trend") is S) ((AskTrend? "What is the feedwater temperature trend") is D) ((AskTrend? "What is the reactor power level trend") is I))) (Water&SteamFlow 3 explanation (((AskHLN? "What is the steam flow rate") is N) ((AskTrend? "What is the steam flow trend") 1s S) ((AskHLN? "What is the feedwater flow rate") 1s N) ((AskTrend? "What is the feedwater flow trend") is S)))]
[definst RecircFCVErr(RecircFCVErrCase1 "UOW0.1j[:.Vz6.26") (case Casel) (confidenceValue -3 explanation ((RecircFCV is -3))) (messagesReceived ((Establish Rx-OverPower NIL))) (state active) (RecircFCV -3 explanation (((AskYNU? "Are the recirc flow control valves in normal position") is T)))]
[DEFINST DemineralizerFail (DemineralizerFailCasel "UOW0.1j[:.Vz6.27") (case Casel) (DeminFailure UnSetKnowledgeGroup)]
[definst RWCUFaii (RWCUFailCasel "UOW0.1j[:.Vz6.28") (case Casel) (RWCU UnSetKnowledgeGroup)]
[definst CondenserTubeLeak (CondenserTubeLeakCasel "UOW0.1j[:.Vz6.29") (case Casel) (CondenserTube UnSetKnowledgeGroup)]
[DEFINST LossOfFWHtr(LossOfFWHtrCase1 "UOWO. 1j[:.Vz6.32") (case Casel) (confidenceValue 3* explanation ((Reactor is 3*) (Reactor is 3*))) (messagesReceived ((Establish ColdWaterAcc NIL))) (variables ? anyEstablished? (F) specialist NIL) 126 {CASPIAN:LAIR:0HI0-STATE}
(state active) (Water&SteamFlow 3 explanation (((AskHLN? 'What Is the steam flow rate') Is N) ((AskTrend? 'What 1s the steam flow trend") 1s S) ((AskHLN? "What is the feedwater flow rate") 1s N) ((AskTrend? "What is the feedwater flow trend") is S))) (Reactor 3* explanation (((AskHLN? 'What 1s the feedwater temperature") 1s H) ((AskTrend? "What is the reactor power level trend") is I) ((AskTrend? "What Is the reactor water level trend”) 1s S) ((AskTrend? "What is the feedwater temperature trend") 1s D)))]
[definst HPCSinjection(HPCSInjectionCase1 "UOW0.1j[:.Vz6.33") (case Casel) (confidenceValue -3 explanation ((HPCS is -3))) (messagesReceived ((Establish ColdWaterAcc NIL))) (state active) (ECCSInjectn UnSetKnowledgeGroup) (HPCS -3 explanation (((AskYNU? "Is HPCS pump running") IS F)))]
STOP {CASPIAN:LAIR:0HI0-STATE}
(FILECREATED "i5-Jun-87 08:08:44" {CASPIAN:LAIR:OHIO-STATE}
changes to: (INSTANCES Case2) (VARS CASE2COMS))
(PRETTYCOHPRINT CASE2COMS)
(RPAQQ CASE2COMS ((INSTANCES Case2))) [DEFINST csRLCase (Case2 "UOW0.1j[:.Vz6.30n) (browser NIL) (valueBrowser NIL) (specialists (#&(CoolSysFault ’UOWO.l j [ : .Vz6.31’ ) #&(L0CA "UOW0.1j[:.Vz6.36") #&(LowInventory "UOWO. 1 j[ :.Vz6.37") #&(HighInventory "UOWO.1j [ :.Vz6.38" ) #&(LossOfHeatSink "UOWO. lj[:.Vz6.39" ) #&( R*-Ove rPower "UOWO.1j [:. Vz6.40" ) #&(HighCoolantConductivity "UOWO.lj[: .Vz6.41") #&(Rel1efValveOpen "UOWO.l j [ : .Vz6.42") #&(RecircL1neProblem ’UOWO.lj[:.V z6.43") #&(SteamLineBrk "UOWO.1j [ : ,Vz6.44" ) #&(OutsideContainmentLOCA "UOW0.1j[:.Vz6.45") #&(OtherSmallLeakages "UOW0.1j[: .Vz6.46") #&(LargeBreak "UOWO.l j [ : .Vz6.47") #&(Smal1 Break "UOWO.lj[: .Vz6.48") #&(HighAuxTankLev "UOWO.l j [ : .Vz6.49" )
#&(LowPressDueToEHCFault "UOWO.l j [ : .Vz6.50") #&(LossOFFeedwaterFlow "UOWO.lj[: .Vz6.51") #&(FWControTlerFai1 Low "UOWO. l j [ :.Vz6.52")
#&(FWContro11erFailHigh "UOWO. l j [ : ,Vz6.53") #&(ECCS&FWCErr "UOWO.1j [ :.Vz6.54") #&(Turb1neControlValve "UOWO.lj[: .Vz6.55") #&(ClosedMSIVs "UOWO.l j [ : .Vz6.56") #&(CondenserFa11 "UOWO. l j [ : .Vz6.57") (F&(TurbLoadRejWOBypass "UOWO,lj[: .Vz6.58") 4>&(SteamA1rEjectorsFa11 "UOWO. l j [ : .Vz6.59") #&(LossOfCi rcPump "UOWO. 1 j[ : .Vz6.60") #&(HighPressDueToEHCFault "UOWO. l j [ : .Vz6.61") #&(ColdWaterAcc "UOWO.lj[ : .Vz6.62") #&(RecircFCVErr "UOWO.lj[ : .Vz6.63" ) #&(DemineralizerFail "UOWO.lj[:.Vz6.64") #&(RWCUFail "UOWO.1j [ : .Vz6.65") W&(CondenserTubeleak "UOWO.lj[: . Vz6.66"))) [SusDataList ((WSLOCA Steam&Electric ((AskHLN? "What is the steam flow rate") is L) ((AskHLN? "What is the turbine electrical output") is L) ((AskHLN? "What is the reactor power level") is N) ((AskYNU? "Are there any SRVs open") is F)) (#$LOCA Steam&Electric ((AskHLN? "What is the steam flow rate") is L) ((AskHLN? "What is the turbine electrical output") is L) ((AskHLN? "What is the react or power level") is N) ((AskYNU? "Are there any SRVs open") 1s F)) (MClosedMSIVs MSIV ((AskYNU? "Are the MSIVs open") is T) ((AskYNU? "Are the turbine stop valves closed") is T) ((AskTrend? “What is the turbine electrical output trend") is D)) (WSClosedMSIVs Reactor ((AskYNU? "Are the MSIVs open") is T) ((AskHLN? "What is the reactor pressure") is H) ((AskHLN? "What is the steam flow rate") is L) ((AskYNU? "Are there any SRVs open") {CASPIAN:LAIR:0HI0-STATE}
IS F] [stHngDB (NIL NIL NIL ((’What Is the reactor power" . L)) (("What is the suppression pool water level trend" . I)) NIL (("Are the turbine bypass valves closed" . T)) (("What is the drywell temperature" . N)) NIL NIL (("Has LOCA completed diagnosis" . F) ("Are the turbine stop valves closed" . T)) (("What is the drywell sump level trend" . S) ("What is the turbine electrical output" . L)) NIL NIL (("What is the condensate storage tank level" . N)) NIL (("Is the suppression pool temperature uniform" . F) ( ’What is the suppression pool temperature trend" . I) ("What is the turbine electrical output trend" . 0)) (("What is the condenser temperature" . N)) NIL (("What is the steam flow rate" . L)) NIL NIL (("What is the reactor pressure" . H)) ((’Has CoolSysFault completed diagnosis’ . F) ("What is the reactor pressure trend" . I)) (("What is the hot surge tank level" . N)) NIL NIL NIL NIL NIL (("Are the MSIVs open" . T)) NIL NIL (("What is the suppression pool temperature" . N) ("What is the drywell temperature trend" . S) ("What is the drywell sump level" . N)) (("What is the reactor water level" . N) ("What is the drywell pressure" . N)) {("What is the drywell pressure trend" . S)) (("Is HPCS pump running" . F) ("What is the reactor water level trend" . I) (“What is the reactor power level" . N)) (("Are the recirc flow control valves in normal position" . T) ("What is the condenser pressure" . N)) (("What is the reactor power level trend" . D)) (("What is the hot well level" . N) ("What is the condenser pressure trend" . S)) (("What is the coolant conductivity" . N) ("Are the turbine control valves in normal position" . T) ("Are there any SRVs open" . F)) NIL NIL (("What is the coolant conductivity trend" . S) ("What is the feedwater temperature" . N)) (("What is the SRV downcomer pressure" . H) ("What is the condenser temperature trend" . S)) (("What is the suppression pool water level" . N)) (("Has LossOfHeatSink completed diagnosis" . F]]
[definst CoolSysFault (CoolSysFaultCase2 "UOW0.1j(:.Vz6.31") (case Case2) (confidenceValue 3 explanation ((summary is 3))) (messagesReceived ((Refine CoolSysFault NIL) (Establish CoolSysFault NIL) (Establish-refine CoolSysFault NIL))) (variables ? anyEstablished? (T T T) specialist (LOCA)) (state suspended) (summary 3 explanation ((Reactor is 3))) (SuppressionPool UnSetKnowledgeGroup) (Containment UnSetKnowledgeGroup) (Reactor 3 explanation (((AskTrend? "What is the reactor pressure trend") is I) ((AskTrend? "What is the reactor water level trend") is I) ((AskTrend? "What is the reactor power level trend") is D))) (Steam&Electric UnSetKnowledgeGroup)]
[DEFINST L0CA{L0CACase2 "UOW0.1j[:.Vz6.36") (case Case2 ) (confidenceValue 0* explanation ((summary is 0*) (summary is <)•))) {CASPIAN:LAIR:0HI0-STATE}
(messagesReceived ((Establish CoolSysFault NIL))) (variables ? anyEstablished? (T T) specialist (OutsideContainmentLOCA)) (state active) (summary 0* explanation ((Steam&Electric is 2*) (Containment is -3) (SuppressionPool is 3))) (SuppressionPool 3 explanation (((AskHLN? “What is the suppression pool water level") is N) ((AskTrend? "What is the suppression pool water level trend") is I) ((AskHLN? "What is the suppression pool temperature") is N) ((AskTrend? "What is the suppression pool temperature trend") is I))) (Steam&Electric 2* explanation (((AskHLN? "What is the steam flow rate") is L) ((AskHLN? "What is the turbine electrical output") is L) ((AskHLN? "What is the reactor power level") is N) ((AskYNU? "Are there any SRVs open") is F))) (Containment -3 explanation (((AskHLN? "What is the drywell pressure") is N) ((AskHLN? "What is the drywell sump level") is N) ((AskHLN? "What is the drywell temperature") is N) ((AskTrend? "What is the drywell pressure trend") is S) ((AskTrend? "What is the drywell temperature trend") is S) ((AskTrend? "What is the drywell sump level trend") is S)))]
[definst Lowlnventory(LowlriventoryCase2 "UOW0.1j[:.Vz6.37") (case Case2) (confidenceValue -3 explanation ((waterlev is -3))) (messagesReceived ((Establish CoolSysFault NIL))) (state active) (waterlev -3 explanation (((AskHLN? "What is the reactor water level") is N)))]
[definst Highlnventory (HighlnventoryCase2 "UOW0.1j[:.Vz6.38") (case Case2) (confidenceValue -3 explanation ((LowInventorylnTanks is -3))) (messagesReceived ((Establish CoolSysFault NIL))) (state active) (WaterLevel -3 explanation (((AskHLN? "What is the reactor water level") is N))) (LowInventorylnTanks -3 explanation (((AskHLN? "What is the condensate storage tank level") is N) ((AskHLN? "What is the hot surge tank level") is N) ((AskHLN? "What is the hot well level") is N)))]
[DEFINST LossOfHeatSink (LossOfHeatSinkCase2 "UOW0.1j[:.Vz6.39”) (case Case2) (confidenceValue 3 explanation ((summary is 3))) (messagesReceived ((Refine CoolSysFault NIL) (Establish CoolSysFault NIL))) (variables ? anyEstablished? (T T) specialist NIL) (state suspended) (summary 3 explanation ((Steam&Electric is 3))) (Valves -3 explanation (((AskYNU? "Are the MSIVs open") is T) ((AskYNU? "Are the turbine bypass valves closed") {CASPIAN:LAIR:OHIO-STATE>
1s T) ((AskYNU? "Are the turbine control valves in normal position") 1s T))) (Steam&Electric 3 explanation (((AskHLN? "What is the reactor power level") is N) ((AskHLN? "What is the turbine electrical output") is L) ((AskHLN? “What is the steam flow rate") is L)))]
[definst Rx-OverPower (Rx-OverPowerCase2 "UOW0.1j[:.Vz6.40") (case Case2) (confidenceValue -3 explanation ((summary is -3))) (messagesReceived ((Establish CoolSysFault NIL))) (state active) (summary -3 explanation ((Reactor is -3) (Water&recirc is -3) (HPCS is -3))) (Water&recirc -3 explanation (((AskYNU? "Are the recirc flow control valves in normal position") is T) ((AskHLN? "What is the feedwater temperature") is N))) (Reactor -3 explanation (((AskHLN? "What is the reactor power level") is N))) (HPCS -3 explanation (((AskYNU? "Is HPCS pump running") is F)))3
[definst HighCooiantConductivity (HighCoolantConductivityCase2 "UOW0.1j[:.Vz6.41") (case Case2) (confidenceValue -3 explanation ((Conductivity is -3))) (messagesReceived ((Establish CoolSysFault NIL))) (state active) (Conductivity -3 explanation (((AskHLN? "What is the coolant conductivity") is N) ((AskTrend? "What is the coolant conductivity trend") is S))>:
[definst Rei iefVaiveOpen (ReliefValveOpenCase2 "UOW0.1j[:.Vz6.42") (case Case?) (srvopen UnSetKnowledgeGroup explanation (((AskYNU? "Are there any SRVs open") is T) ((AskHLN? "What is the suppression pool temperature") is N) ((AskTrend? "What is the suppression pool temperature trend") is I) ((AskHLN? "What is the suppression pool water level") is N))) (press UnSetKnowledgeGroup explanation (((AskHLN? "What is the drywell pressure") is N))) (Reactor UnSetKnowledgeGroup)]
[definst RecircLineProbiem(RecircLineProblemCase2 "UOW0.1j[:.Vz6.43") (case Case2) (recirc UnSetKnowledgeGroup explanation (((AskHLN? "What is the reactor water level") is N) ((AskHLN? “What is the drywell pressure") is N) ((AskTrend? "What is the reactor water level trend") is I) ((AskTrend? "What is the drywell pressure trend") is S)))]
[definst steamLineBrk(SteamLineBrkCase2 "UOW0.1j[:.Vz6.44") (case Case2) (SteamLineBreak UnSetKnowledgeGroup explanation (((AskHLN? "What is the steam flow rate") is L) ((AskHLN? "What is the reactor pressure") is H)))] 131 {CASPIAN:LAIR:OHIO-STATE}
[definst OutsideContammentLOCA (OutsideContainmentLOCACase2 "UOW0.1j[:.Vz6.45") (case Case2) (summary UnSetKnowledgeGroup explanation ((FeedWaterLineBreak is *3) (SteamLineBreak is -3))) (SteamLineBreak UnSetKnowledgeGroup explanation (((AskHLN? "What is the steam flow rate") is L) ((AskHLN? “What is the reactor pressure*) is H))) (FeedWaterLineBreak UnSetKnowledgeGroup explanation (((AskHLN? •What is the reactor water level*) is N) ((AskHLN? "What is the drywell pressure") is N) ((AskTrend? "What is the reactor water level trend") is I) ((AskTrend? "What is the reactor pressure trend") is I)))]
[definst otherSmaiiLeakages (OtherSmallLeakagesCase2 "UOW0.1j[:.Vz6.46") (case Case2) (recirc UnSetKnowledgeGroup explanation (((AskTrend? "What is the reactor water level trend") is I) ((AskTrend? "What is the reactor pressure trend") is I)))]
[DEFINST LargeBreak (LargeBreakCase2 "UOWO.1 j[:.Vz6.47") (case Case2) (LargeBreak UnSetKnowledgeGroup)]
[definst SmaiiBreak (SmallBreakCase2 "UOW0.1j[:.Vz6.48") (case Case2) (SmaiiBreak UnSetKnowledgeGroup)]
[definst HighAuxTankLev (HighAuxTankLevCase2 "UOWO.1 j[:.Vz6.49") (case Case2) (summary UnSetKnowledgeGroup) (cst UnSetKnowledgeGroup) (hotwell UnSetKnowledgeGroup) (hst UnSetKnowledgeGroup)]
[definst LowPressDueToEHCFauit (LowPressDueToEHCFaultCase2 nUOW0.1j[:.Vz6.5O") (case Case2) (Pressure UnSetKnowledgeGroup)]
[definst LossOfFeedwaterFiow(LossOfFeedvvaterFlowCase2 "UOW0.1j[:.Vz6.51") (case Case2) (mfwp UnSetKnowledgeGroup)]
[definst FWControiierFaiiLow(FWControllerFailLowCase2 "UOW0.1j[:.Vz6.52") (case Case2) (fwcfl UnSetKnowledgeGroup) (mfwp UnSetKnowledgeGroup)]
[definst FWControiierFaiiHigh(FWControllerFailHighCase2 "UOW0.1jt:.Vz6.53") (case Case2) (WaterLevel UnSetKnowledgeGroup) (LowInventorylnTanks UnSetKnowledgeGroup)]
[DEFINST ECCS&FWCErr (ECCS&FWCErrCase2 "UOW0.1j[:.Vz6.54") (case Case2) (ECCS UnSetKnowledgeGroup)]
[definst TurbineControi Valve (TurbineControlValveCase2 "UOW0.1j[:.Vz6.55") (case Case2) (confidenceValue 3* explanation ((TurbineControlValve is 3*))) (messagesReceived ((Establish LossOfHeatSink NIL))) (state active) (TurbineControlValve 3* explanation (((AskYNU? "Are the MSIVs open") is T) ((AskYNU? "Are the turbine control valves in normal position" is T) ((AskHLN? "What is the turbine electrical output") is L) ((AskYNU? "Are the turbine bypass valves closed") is T)))]
[definst ciosedMSivs{ClosedMSIVsCase2 "UOW0.1j[:.Vz6.56") (case Case2) (confidenceValue 1* explanation ((MSIV is 2*) (Reactor is 1*))) (messagesReceived ((Establish LossOfHeatSink NIL))) (state active) (Reactor 1* explanation (((AskYNU? "Are the MSIVs open") is T) ((AskHLN? "What is the reactor pressure") is H) ((AskHLN? "What is the steam flow rate") is L) ((AskYNU? "Are there any SRVs open") is F))) (MSIV 2* explanation (((AskYNU? "Are the MSIVs open") is T) ((AskYNU? "Are the turbine stop valves closed") is T) ((AskTrend? "What is the turbine electrical output trend") is D)))]
[definst CondenserFaii (CondenserFailCase2 "UOW0.1j[:.Vz6.57") (case Case2) (confidenceValue -3 explanation ((Vacuum is -3))) (messagesReceived ((Establish LossOfHeatSink NIL))) (state active) (Vacuum -3 explanation (((AskHLN? "What is the condenser pressure") is N) ((AskHLN? "What is the condenser temperature") is N)))]
[DEFINST TurbLoadRejwOBypass (TurbLoadRejWOBypassCase2 "UOW0.1j[:.Vz6.58") (case Case2) (confidenceValue -3 explanation ((Valves is -3))) (messagesReceived ((Establish LossOfHeatSink NIL))) (state active) (Valves -3 explanation (((AskHLN? "What is the reactor power") is L)))]
[Definst steamAirEjec tors Fail (SteamAirEjectorsFailCase2 nUOW0.1j[:.Vz6.59“) (case Case2) (AirRejectors UnSetKnowledgeGroup)]
[Definst LossOfCircPump(LossOfCircPumpCase2 "UOW0.1j[:.Vz6.60") (c a se Case2) (CirculationPump UnSetKnowledgeGroup)]
[definst HighPressDueToEHCFauit (HighPressDueToEHCFaultCase2 "UOW0.1j[:.Vz6.61") (case Case2) (PressureRegFailClosed UnSetKnowledgeGroup)]
[DEFINST coldWaterAcc (ColdWaterAccCase2 "UOW0.1j[:.Vz6.62") (case Case2) {CASPIAN:LAIR:0HI0-STATE}
(WaterTemp UnSetKnowledgeGroup) (Water&SteamFlow UnSetKnowledgeGroup)]
[DEFINST RecircFCVErr(RecircFCVErrCase2"UOW0.1j[:.Vz6.63") (case Case2) (RecircFCV UnSetKnowledgeGroup)]
[DEFINST DemineralizerFaii (DemineralizerFailCase2 "UOW0.1j[:.Vz6.64") (case Case2) (DeminFailure UnSetKnowledgeGroup)]
[DEFINST RWCUFaii (RWCUFailCase2 "UOW0.1j[:.Vz6.65") (case Case2) (RWCU UnSetKnowledgeGroup)]
[DEFINST CondenserTubeLeak (CondenserTubeLeakCase2 ”UOW0.1j[:.Vz6.66n) (case Case2) (CondehserTube UnSetKnowledgeGroup)]
STOP {CASPIAN:LAIR :OHIO-STATE}
(FILECREATED "i5-Jun-87 08:13:55' {CASPIAN:LAIR:OHIO-STATE}
changes to: (INSTANCES Case3) (VARS CASE3C0MS))
(PRETTYCOMPRINT CASE3COMS)
(RPAQQ CASE3COMS ((INSTANCES Case3))l [DEFINST cSRLCase(Case3 "UOW0.1j[:.Vz6.34") (browser NIL) (valueBrowser NIL) (specialists (#&(CoolSysFault 'UOWO. 1j [ : .Vz6.35') #&(LOCA 'UOWO.l j [ : .Vz6.71") #&(LowInventory "UOWO. 1 j[ :.Vz6.72") #&{HighInventory "UOWO.1j [ :.Vz6.73") #&(LossOfHeatSink "UOWO.1j[ : .Vz6 .74") #&(Rx-OverPower "UOW0.1j[:.Vz8.75") #&(HighCoolantConductivity "UOWO.l j [ : .Vz6.76" ) #&(ReliefValveOpen "UOWO.1j [:.Vz6 .77") if&(RecircLineProblem "UOWO. l j [ : .Vz 6 . 78" ) #&(SteamLineBrk "UOWO. lj [ : .Vz6.79") 4&(0utsideContainmentL0CA "UOWO.l j [ : ,Vz6.80" ) #8i(0therSmal 1 Leakages "UOWO. 1 j[: .Vz6.81“) #&(HighAuxTankLev "UOWO.lj[ : .Vz6.82")
#&(LowPressDueToEHCFault "UOWO.l j [ : .Vz6.83") W8i(LossOfFeedwaterFlow "UOWO. 1 j[: ,Vz6.84") <*&(FWControllerFai 1 Low "UOWO.l j [ : .Vz6.85")
#&(FWControllerFailHigh "UOWO.1j [ :.Vz6 .8 6 ") #&(ECCS&FWCErr "UOWO.lj[: .Vz6.87") #&(TurbineControlValve "UOWO.l j [ :.Vz 6 .88 ") #&(ClosedMSIVs "UOWO.lj[:.Vz6.89") #S(CondenserFai1 "UOWO.lj[: ,Vz6.90") #&(TurbLoadRejWOBypass "UOWO.lj[:.Vz6.91") W&(HighPressDueToEHCFault "UOWO.1j [ :.Vz6.92" ) #&(ColdWaterAcc "UOWO.lj[: .Vz6.93") #&(RecircFCVErr "UOWO.1j [:.Vz6 .94") #&(LossOfFWHtr "UOWO.lj[: .Vz6.95") #&(HPCSInjection "UOWO.1j[ :.Vz6.96") #&(Demineral izerFail "UOWO.lj[:,Vz6.97" ) (F8 (RWCUFail "UOWO. lj[:.Vz6.98") #&(CondenserTubeLeak "UOWO.1j [ :.Vz6.99" ))) [SusDataList ((WIHighlnventory WaterLevel ((AskHLN? "What is the reactor water level") is H) ((AskHLN? "What is the feedwater pumps speed") is N) ((AskYNU? "Are there alarms indicating ECCS initiation") is F)) (WSHPCSInjection ECCSInjectn ((AskYNU? "Are there alarms indicating ECCS initiation") is F) ((AskHLN? "What is the feedwater flow rate") is N) ((AskHLN? "What is the reactor water level") is H] (stringDB (NIL NIL NIL NIL ((“What is the suppression pool water level trend" . S)) NIL (("Are the turbine bypass valves closed" . T)) (("What is the feedwater pump discharge pressure" . U) ("What is the drywell temperature” . N)) NIL NIL NIL (("What is the drywell sump level trend" . 0) ("What is the turbine electrical output" . N)) NIL NIL (('What is the feedwater pumps speed" . N) ("What is the condensate storage tank level" . L) ("Are there alarms indicating ECCS initiation" . F)) (("Is the RCIC pump running" . F) NIL) (("Is the reactor pressure above 100 psia" . T)) NIL NIL (("What is the steam flow rate" . N)) NIL (("What is the feedwater flow rate" . N)) (NIL ("What is the reactor pressure" . N)) ((’Has CoolSysFault completed diagnosis” . F) 135 {CASPIAN:LAIR:OHIO-STATE}
("What is the feedwater temperature trend" . S) ("What is the reactor pressure trend" . D)) (("What is the hot surge tank level" . N)) NIL (("What 1s the feedwater flow trend" . S)) NIL NIL NIL (("Are the MSIVs open" . T)) NIL NIL (('What is the drywell temperature trend" . D) ("What is the drywell sump level" . N)) (("What is the drywell pressure" . N) ("What is the reactor water level" . H)) (("Is HPCS lined up to deliver water to RPV" . T) NIL NIL ("What is the drywell pressure trend" . D)) (("Is HPCS pump running" . T) NIL NIL ("What is the reactor power level’ . N) ("What is the reactor water level trend" . I)) (NIL ("Are the recirc flow control valves in normal position" . T)) (("What is the reactor power level trend’ . I)) ((’Is the reactor pressure below 300 ps1a" . F) ("What is the hot well level" . N)) ((’Has HighPressureSystem completed diagnosis" . F) ("What is the coolant conductivity" . N) ("Are the turbine control valves in normal position" . T) ("Are there any SRVs open” . F)) NIL ((’What is the steam flow trend" . S)) (("What is the coolant conductivity trend’ . S) ("What is the feedwater temperature” . N)) NIL (("Has Rx-OverPower completed diagnosis" . F) ("What is the suppression pool water level" . N)) NIL))]
[DEFINST CooiSysFauit (CoolSysFaultCase3 "UOW0.1j[:.Vz6.35") (case Case3) (confidenceValue 3 explanation ((summary is 3))) (messagesReceived ((Refine CooiSysFauit NIL) (Establish CooiSysFauit NIL) (Establish-refine CooiSysFauit NIL) (Establish CooiSysFauit NIL) (Establish-refine CooiSysFauit NIL))) (variables ? anyEstablished? (T) specialist NIL) (state suspended) (summary 3 explanation ((Reactor is 3))) (Reactor 3 explanation (((AskTrend? "What is the reactor pressure trend") is D) ((AskTrend? "What is the reactor water level trend") is I) ((AskTrend? "What is the reactor power level trend") is I)))]
[DEFINST L0CA{LOCACase3 "UOWO.1 jt:.Vz6.71") (case Case3) (confidenceValue -3 explanation ((summary is -3))) (messagesReceived ((Establish CooiSysFauit NIL))) (state active) (summary -3 explanation ((Steam&Electric is -3) (Containment is -3) (SuppressionPool is -3))) (SuppressionPool -3 explanation (((AskTrend? "What 1s the suppression pool water level trend") is S))) (SteamiElectric -3 explanation (((AskHLN? "What is the steam flow rate") 1S N) ((AskHLN? "What is the turbine electrical output") is N) ((AskHLN? "What is the reactor power level") is N) ((AskYNU? "Are there any SRVs open") is F))) (Containment -3 explanation (((AskHLN? "What is the drywell pressure") is N) {CASPIAN:LAIR:OHIO-STATE}
((AskHLN? "What 1s the drywell sump level") 1s N) ((AskHLN? "What is the drywell temperature") 1s N) ((AskTrend? "What 1s the drywell pressure trend") is 0 ) ((AskTrend? "What 1s the drywell temperature trend") 1s 0 ) ((AskTrend? "What 1s the drywell sump level trend") is D)))]
[DEFINST Lowlnventory (LowlnventoryCase3 "UOW0.1j[:.Vz6.72”) (case Case3) (confIdenceValue -3 explanation ((waterlev 1s -3))) (messagesReceived ((Establish CooiSysFauit NIL))) (state active) (waterlev -3 explanation (((AskHLN? "What 1s the reactor water level") is H)))]
[definst Highinventory (High!nventoryCase3 "UOW0.1j(:.Vz6.73") (case Case3) (confidenceValue 0* explanation ((WaterLevel is 0*) (LowInventorylnTanks is 1) (WaterLevel is 0*))) (messagesReceived ((Establish CooiSysFauit NIL))) (state active) (WaterLevel 0* explanation (((AskHLN? "What is the reactor water level") 1s H) ((AskHLN? "What is the feedwater pumps speed") is N) ((AskYNU? "Are there alarms indicating ECCS initiation") is F))) (LowInventorylnTanks 1 explanation (((AskHLN? "What is the condensate storage tank level") is L) ((AskHLN? "What is the hot surge tank level") is N) ((AskHLN? "What is the hot well level") is N)))]
[definst LossOfHeatsink (LossOfHeatSinkCase3 "UOW0.1j[:.Vz6.74") (case Case3) (confidenceValue -3 explanation ((summary is -3))) (messagesReceived ((Establish CooiSysFauit NIL))) (state active) (summary -3 explanation ((Valves is -3) (Steam&Electric is -3))) (Valves -3 explanation (((AskYNU? "Are the MSIVs open") is T) ((AskYNU? "Are the turbine bypass valves closed") is T) ((AskYNU? "Are the turbine control valves in normal position") is T))) (Steam&Electric -3 explanation (((AskHLN? "What is the turbine electrical output") is N)))]
[definst Rx-0verPower(R*-0verPowerCase3 "UOW0.1j[:.Vz6.75") (case Case3) (confidenceValue 3 explanation ((summary is 3))) (messagesReceived ((Refine CooiSysFauit NIL) (Establish CooiSysFauit NIL))) (variables ? anyEstablished? (T) specialist NIL) (state suspended) (summary 3 explanation ((HPCS 1s 3))) (Water&recirc -3 explanation (((AskYNU? "Are the recirc flow control valves in normal position") is T) ((AskHLN? "What is the feedwater temperature") is N))) (Reactor -3 explanation (((AskHLN? "What is the reactor pressure") {CASPIAN:LAIR:0HI0-STATE}
is N) ((AskHLN? "What is the reactor power level’) is N))) (HPCS 3 explanation (((AskYNU? "Is HPCS pump running") is T) ((AskYNU? "Is HPCS lined up to deliver water to RPV") is T)))]
[DEFINST HighCooiantConductivity (HighCoolantConductivityCase3 "UOW0.1j[:.Vz6.76") (case Case3) (confidenceValue -3 explanation ((Conductivity is -3))) (messagesReceived ((Establish CooiSysFauit NIL))) (state active) (Conductivity -3 explanation (((AskHLN? "What is the coolant conductivity") is N) ((AskTrend? "What is the coolant conductivity trend") is S)))]
[definst ReiiefVaiveOpen (ReliefValveOpenCase3 "UOW0.1j[:.Vz6.77") (case Case3)]
[definst RecircLineProbiem(RecircLineProblemCase3 "UOW0.1j[:.Vz6.78") (case Case3)]
[definst steamLineBrk(SteamLineBrkCase3 "UOW0.1j[:.Vz6.79") (case Case3)]
[definst 0utsideContainmentL0CA(OutsideContainmentLOCACase3 "UOW0.1j[:.Vz6.80") (case Case3)]
[definst othersmaiiLeakages (OtherSmallLeakagesCase3 "UOW0.1j[:.Vz6.81") (case Case3)]
[DEFINST HighAuxTankLev (HighAuxTankLevCase3 "UOW0.1j[:.Vz6.82") (case Case3)]
[DEFINST LowPressDueToEHCFauit (LowPressDueToEHCFaultCase3 "UOW0.1j[:.Vz6.83") (case Case3)]
[DEFINST Loss0fFeedwaterFiow(LossOfFeedvvaterFlowCase3 "UOW0.1j[:.Vz6.84") (case Case3)]
[definst FWControiierFaiiLow(FWControllerFailLowCase3 "UOW0.1j[:.Vz6.85") (case Case3)]
[DEFINST FWControlierFailHigh (FWControllerFailHighCase3 "UOW0.1j[:.Vz6.86") (case Case3)]
[DEFINST eccs&fwcerr (ECCS&FWCErrCase3 "UOW0.1j[:.Vz6.87") (case Case3)]
[definst TurbineControiValve (TurbineControlValveCase3 "UOW0.1j[:.Vz6.88") (case Case3)]
[oefinst ciosedMSivs (ClosedMSIVsCase3 "UOW0.1j[:.Vz6.89") (case Case3)]
[definst CondenserFaii (CondenserFailCase3 "UOW0.1j[:.Vz6.90") (case Case3)] {CASPIAN:LAIR:OHIO-STATE}
[DEFINST TurbLoadRejWOBypass (TurbLoadRejWOBypassCase3 "UOW0.1j[:.Vz6.91") (case Case3)]
[DEFINST HighPressDueToEHCFauH(HighPressDueToEHCFaultCase3 "UOW0.1j[:.Vz6.92") (case Case3) (confidenceValue -3 explanation ((PressureRegFailClosed is -3))) (messagesReceived ((Establish Rx-OverPower NIL))) (state active) (PressureRegFailClosed -3 explanation (((AskTrend? "What is the reactor pressure trend") is D)))]
[definst CoidWaterAcc (ColdWaterAccCase3 "UOW0.1j[:.Vz6.93") (case Case3) (confidenceValue 3 explanation ((Water&SteamFlow is 3) (WaterTemp is 3))) (messagesReceived ((Refine Rx-OverPower NIL) (Establish Rx-OverPower NIL))) (variables ? anyEstablished? (T) specialist NIL) (state suspended) (WaterTemp 3 explanation (((AskHLN? 'What is the feedwater temperature") is N) ((AskTrend? "What is the reactor water level trend") is I ) ((AskTrend? "What is the feedwater temperature trend") is S) ((AskTrend? "What is the reactor power level trend") is I))) (Water&SteamFlow 3 explanation (((AskHLN? "What is the steam flow rate") is N) ((AskTrend? "What is the steam flow trend") is S) ((AskHLN? "What is the feedwater flow rate") is N) ((AskTrend? "What is the feedwater flow trend") is S)))]
[definst RecircFcvErr(RecircFCVErrCase3 "UOW0.1j[:.Vz6.94") (case Case3) (confidenceValue -3 explanation ((RecircFCV is -3))) (messagesReceived ((Establish Rx-OverPower NIL))) (state active) (RecircFCV -3 explanation (((AskYNU? "Are the recirc flow control valves in normal position") is T)))]
[DEFINST Loss0fFWHtr{LossOfFWHtrCase3 "UOW0.1j[:.Vz6.95") (case Case3) (confidenceValue -3 explanation ((Water&SteamFlow is 3) (Reactor is -3))) (messagesReceived ((Establish CoidWaterAcc NIL))) (state active) (Water&SteamFlow 3 explanation (((AskHLN? "What is the steam flow rate") is N) ((AskTrend? "What is the steam flow trend") is S) ((AskHLN? "What is the feedwater flow rate") is N) ((AskTrend? "What is the feedwater flow trend") is S))) (Reactor -3 explanation (((AskHLN? "What is the feedwater temperature") is N) ((AskTrend? "What is the feedwater temperature trend") is S)))]
[definst HPCSinjeetion(HPCSInjectionCase3 "UOW0.1j!:.Vz6.96”) (case Case3) (confidenceValue 2* explanation ((ECCSInjectn is 2*) 139 {CASPIAN:LAIR:0HI0-STATE}
(ECCSInjectn is 2*))) (messagesReceived ((Establish CoidWaterAcc NIL))) (state active) (ECCSInjectn 2* explanation (((AskYNU? "Are there alarms indicating ECCS initiation" ) is F) ((AskHLN? "What is the feedwater flow rate") is N) ((AskHLN? "What is the reactor water level") is H))) (HPCS 3 explanation (((AskYNU? "Is HPCS pump running") 1s T) ((AskYNU? "Is HPCS linedup to deliver water to RPV") 1s T)))]
[definst DemineralizerFaii (DemineralizerFailCase3 "UOW0.1j[:.Vz6.97") (case Case3)]
[DEFINST RWCUFaii (RWCUFailCase3 "UOW0.1j[:.Vz6.9B") (case Case3)]
[definst CondenserTubeLeak (CondenserTubeLeakCase3 "UOW0.1j[:.Vz6.99") (case Case3)]
STOP APPENDIX B
CODE PRINTOUT
140 {CASPIAN:LAIR:OHIO-STATE}
(Specialist NPPSpecialist [kgs (summary Rules (* the default summary knowledge group simply asks the user to enter the confidence value of the specialist) (match (DoLisp (Asklnteger? (CONCAT "Enter the confidence value of " self) -3 3) (self self)) with (if ? then ! ] [messages (Suggest (* the default Suggest message lets the message pass thru if the specialist is not rejected) (parameters message specialist parameters) (if (Unknown? (ConfidenceValue of self)) then (call self with Establish)) (if (Not (-? self)) then (call specialist with message (expand parameters)) (exit active))) (Refine (* the default Refine message invokes each subspecialist with a Establish message, and calls those which have established with Refine messages) (variables anyEstablished?) (Set anyEstablished? F) [for specialist in subspecialists do (if (And anyEstablished? (doLISP ( IsCurrentSpecialistFinished) ( currentSpecialist self))) then (exit finished)) (call specialist with Establish) (if [or (+? specialist) (or (Eq (ConfidenceValue of specialist) (QUOTE ?•)) (Eq (ConfidenceValue of specialist) (QUOTE 3*] then (Set anyEstablished? T) (if (Not (TipSpecialist? specialist)) then (call specialist with Refine] (exit suspended)) (Establish-refine (• the default Establish-refine message calls the specialist with an Establish and (if established) Refine message) (call self with Establish) (if [or (+? self) (or (Eq (ConfidenceValue of self) (QUOTE 2*)) (Eq (ConfidenceValue of self) (QUOTE 3*] then (call self with Refine) (exit suspended) elseif (+-? self) then (exit suspended) else (exit finished))) (Establish (* the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self summary) (1f [or (♦? self) (or (Eq (ConfidenceValue of self) (QUOTE 2*)) (Eq (ConfidenceValue of self) {CASPIAN:LAIR:OHIO-STATE}
(QUOTE 3*] then (Exit active) elseif (-? self) then (Exit finished) else (Exit suspended])
(Specialist CooiSysFauit (declare (Subspecialists LOCA Lowlnventory Highlnventory LossOfHeatSink Rx-OverPower HighCoolantConductivity) (LoopsSuper NPPSpecialist)) [kgs (summary Table (* the default summary knowledge group simply asks the user to enter the confidence va-lue of the specialist) (match Reactor SuppressionPool Containment Steam&Electric with (if (GT 1) ? ? ? then 3 elseif ? (GT 1) ? ? then 3 elseif ? ? (GT 1) then 3 elseif ? ? ? (GT 1) then 3 else -3))) (SuppressionPool (• definition of new knowledge group) Table (• or RULES) (match (AskHLN? "What is the suppression pool water level") (AskTrend? "What is the suppression pool water level trend") (AskHLN? "What is the suppression pool temperature") (AskTrend? "What is the suppression pool temperature trend") (* decision knowledge) with (if (OR H L) (OR I D DO II) H (OR I DD) then 3 elseif (OR H L) ?(OR I II D DD) (OR I II) then 3 elseif ? ? H (OR I N II) then 2 elseif ? (OR I II 0 DD) ? ? then 2 elseif ? ? ? (OR I II) then 2 else -3))) (Steam&Electric Table (• LOCA determination) (match (AskHLN? "What is the steam flow rate") (AskHLN? "What is the turbine electrical output") (AskHLN? "What is the reactor pressure") (AskHLN? "What is the reactor power level") with (if N N N N then -3 elseif (OR HH H N) (OR L LL) ? ? then 3 elseif ? L (OR N L) {CASPIAN:LAIR:OHIO-STATE}
(OR N H) then 3 else 0 ))) (Reactor (• Reactor Water Level. Pressure and Power Checking) Table (match (AskHLN? What is the reactor pressure") (AskHLN? What is the reactor water level") (AskHLN? What is the reactor power level") (AskTrend? 'What is the reactor pressure trend”) (AskT rend? 'What is the reactor water level trend") (AskT rend? 'What is the reactor power level trend") (* decision knowledge) with (if (NOT N) (NOT N) (NOT N) ? ? ? then 3 elseif ? ? ? (NOT S) (NOT S) (NOT S) then 3 elseif (NOT N) ? ? (NOT S) ? ? then 3 e l s e i f ? (NOT N) ? ? (NOT S)
t h e n e l s e i f ? ? (NOT N) ? ? (NOT S) t h e n 3 e l s e i f (NOT N) ? ? 1 ? ? t h e n 2 e l s e i f ? (NOT N) ? ? ? ? t h e n 2 e l s e i f ? ? (NOT N) ? ? ? t h e n 2 e l s e i f ? ? ? (NOT S) ? ? t h e n 2 e l s e i f ? ? ? ? (NOT S)
t hen 2 e l s e i f ? ? ? ? ? (NOT then 2 else -3))) (Containment (• Checking the containment variables) Table (• or RULES) (match (AskHLN? "What is the drywell pressure") (AskHLN? "What is the drywell sump level") (AskHLN? "What is the drywell temperature") (AskTrend? "What is the drywell pressure trend") (AskTrend? "What is the drywell temperature trend") (AskTrend? "What is the drywell sump level trend") (* decision knowledge) with (if (OR H HH) (OR H HH) (OR H HH) ? ? ? then 3 elseif ? ? ? (OR I II) (OR I II) (OR I II) then 3 {CASPIAN:LAIR:OHIO-STATE}
e l s e i f (OR H HH) 7 7 (OR I II) 7 7 t h e n 3 e l s e i f 7 (OR H HH) 7 7 (OR I II) 7 t h e n 3 e l s e i f 7 7 (OR H HH) 7 7 (OR I II) t h e n 3 e l s e i f (OR H HH) 7 7 7 7 7 t h e n 2 e l s e i f 7 (OR H HH) 7 7 7 7 t h e n 2 e l s e i f 7 7 (OR H HH) ? 7 7 t h e n 2 e l s e i f ? 7 ? (OR I II) 7 7 t h e n 2 e l s e i f 7 7 ? ? (OR I II) 7 t h e n 2 e l s e i f 7 7 ? ? ? (OR I II t h e n 2 e l s e -3] (messages (Establish (* the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self summary))))
(Specialist LOCA (• specialist for LOCA) (declare (Superspeciaiist CooiSysFauit) (LoopsSuper NPPSpecialist) (Subspecialists ReliefValveOpen RecircLineProblem SteamLineBrk OutsideContainmentLOCA OtherSmal1 Leakages)) [kgs (summary Table (• the default summary knowledge group simply asks the user to enter the confidence value of the specialist) (match Steam&Electric Containment SuppressionPool with (if (GT 1) (GT 1) (GT 1) then 3 elseif (GT 0) (GT 0) 7 then 2 elseif ? (GT 0) (GT 0 ) then 2 elseif (GT 1) 7 (GT 0 ) then 2 elseif (GT 0 ) 7 (GT 0 ) then 1» elseif (GT 1) ? ? then 0* elseif ? (GT 1) 7 {CASPIAN:LAIR:OHIO-STATE}
then 0* elseif ? ? (GT 1) then 0* else -3))) (SuppressionPool (* definition of new knowledge group) Table (• or RULES) (match (AskHLN? ’What is the suppression pool water level") (AskTrend? "What is the suppression pool water level trend") (AskHLN? "What is the suppression pool temperature") (AskTrend? "What is the suppression pool temperature trend") (* decision knowledge) with (if (OR N H HH) (OR I II) (OR N H HH) (OR I II) then 3 elseif 1 ? (OR I II) (OR I II) then 2 else -3))) (Steam&Electric Table (• LOCA determination) (match (AskHLN? "What is the steam flow rate") (AskHLN? "What is the turbine electrical output”) (AskHLN? "What is the reactor power level") (AskYNU? "Are there any SRVs open”) with (if N N N F then -3 elseif (OR H HH) (OR L LL N) ? T then 3 elseif (OR L LL) (OR L LL) (OR N H) T then 3 elseif (OR L LL) (OR L LL) (OR N H) F then 2* else -3))) (Containment (• Checking the containment variables) Table (• or RULES) (match (AskHLN? "What is the drywell pressure") (AskHLN? "What is the drywell sump level") (AskHLN? "What is the drywell temperature") (AskTrend? 'What is the drywell pressure trend") (AskTrend? "What is the drywell temperature trend") (AskTrend? "What is the drywell sump level trend") (* decision knowledge) w i t h (if (OR H HH) (OR H HH) (OR H HH) ? ? ? then 3 elseif ? ? ? (OR I II) (OR I II) (OR I II) then 3 elseif (OR H HH) {CASPIAN:LAIR:OHIO-STATE>
? ? (OR I II) ? 7 then 3 elseif ? (OR H HH) ? ? (OR I II) ? then 3 elseif 7 ? (OR H HH) 7 ? (OR I II) then 3 elseif (OR H HH) 7 7 ? ? ? then 2 elseif ? (OR H HH) 7 ? ? ? then 2 elseif 7 ? (OR H HH) 7 7 7 then 2 elseif 7 ? ? (OR I II) 7 7 then 2 elseif 7 ? ? ? (OR I II) 7 then 2 elseif 7 ? ? ? ? (OR III) then 2 else -3] [messages (Establish [if (EQ Steam&Electric (QUOTE 2*)) then ((DoLisp (- ($! currentCase) StoreSusData SPECIALIST KGName CaseNo) (SPECIALIST self) (KGName (QUOTE Steam&Electric)) (CaseNo ($.' currentCase] (if (OR (EQ summary (QUOTE 0*)) (EQ summary (QUOTE 1*)) (EQ summary (QUOTE 2*))) then (DoLisp (<- ($: currentCase) StoreSusData SPECIALIST KGName CaseNo) (SPECIALIST self) (KGName (QUOTE Steam&Electric)) (CaseNo (I! currentCase))) (SetConfidence self summary) else (SetConfidence self summary])
(Special ist Lowlnventory (* specialist for-LowFlow) (declare (Superspecialist CooiSysFauit) (LoopsSuper NPPSpecialist) (Subspecialists HighAuxTankLev LowPressDueToEHCFault LossOfFeedwaterFlow FWControllerFailLow)) [kgs (waterlev Table (• Check for water level) (match (AskHLN? "What is the reactor water level") (AskTrend? "What is the reactor water level trend") (AskHLN? "What is the drywell pressure") (AskHLN? "What is the drywell temperature") (AskHLN? "What is the suppression pool temperature") (AskHLN? "What is the suppression pool water level") with (if (OR L LL) (OR 0 OD) 7 7 7 7 then 3 elseif (OR L LL) (OR D DO) (OR H HH) (OR H HH) ? 7 then 3 elseif (OR L LL) {CASPIAN:LAIR:OHIO-STATE}
? ? ? (OR H HH) (OR H HH) then 3 else -3] (messages (Establish (• the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self waterlev))))
(Specialist Highlnventory (• specialist for HighFlow) (declare (Subspecialists FWControllerFailHigh ECCS&FWCErr) (LoopsSuper NPPSpecialist) (Superspecialist CooiSysFauit)) [kgs (WaterLevel (* definition of new knowledge group) Table (• or RULES) (match (AskHLN? "What is the reactor water level") (AskHLN? "What is the feedwater pumps speed") (AskYNU? "Are there alarms indicating ECCS initiation") with (if (OR H HH) (OR H N HH) T then 3 elseif (OR H HH) ? T then 2 elseif (OR H HH) (OR H N HH) F then 0* else -3))) (LowInventorylnTanks (• If low inventory in any of these tanks, then water level must be high in the Rx.) Table (match (AskHLN? "What is the condensate storage tank level") (AskHLN? “What is the hot surge tank level") (AskHLN? "What is the hot well level") (• decision knowledge) with (if (OR L LL) (OR L LL) (OR L LL) then 3 elseif (OR L LL) (OR L LL) 7 then 3 elseif (OR L LL) ? (OR L LL) then 2 elseif ? (OR L LL) (OR L LL) then 2 elseif (OR L LL) ? ? then 1 elseif ? (OR L LL) 7 then i elseif ? ? (OR L LI then 1 else -I»] (CASPIAN:LAIR:OHIO-STATE}
[messages (Establish (if (AND (EQ WaterLevel (QUOTE 0*)) (GE LowInventorylnTanks 1)) (• if LowInventorylnTanks establishes, then there is a possibility of Highlnventory in the Rx) then (DoLisp (*• ($! currentCase) StoreSusData SPECIALIST KGName CaseNo) (SPECIALIST self) (KGName (QUOTE WaterLevel)) (CaseNo ($! currentCase))) (SetConfidence self WaterLevel) elseif (GE LowInventorylnTanks 1) then (SetConfidence self WaterLevel) else (SetConfidence self LowInventorylnTanks])
(Specialist LossOfHeatSink (* specialist for LossOfHeatSink) (declare (Subspecialists TurbineControlValve ClosedMSIVs CondenserFail TurbLoadRejWOBypass) (LoopsSuper NPPSpecialist) (Superspecialist CooiSysFauit)) [kgs (summary Table (• the default summary knowledge group simply asks the user to enter the confidence value of the specialist) (match Valves Steam&Electric with (if (GT 1) ? then 3 elseif ? (GT 1) then 3 else -3))) (Valves (* definition of new knowledge group) Table (match (AskYNU? "Are the MSIVs open”) (AskYNU? "Are the turbine bypass valves closed") (AskYNU? "Are the turbine control valves in normal position") with (if T T T then -3 else 3))) (Steam&Electric (• definition of new knowledge group) Table (match (AskHLN? "What is the reactor power level") (AskHLN? "What is the turbine electrical output") (AskHLN? "What is the steam flow rate") with (if (OR N H HH) (OR L LL) (OR L LL) then 3 else -3] (messages (Establish (* the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self summary))))
(Specialist Rx-OverPower (• specialist for HighHeatSource) (declare (Superspecialist CooiSysFauit) {CASPIAN:LAIR:OHIO-STATE}
(LoopsSuper NPPSpecialist) (Subspecialists HighPressDueToEHCFault CoidWaterAcc RecircFCVErr)
[kgs (summary Table (• the default summary knowledge group simply asks the user to enter the confidence value of the specialist) (match Reactor Water&recirc HPCS with (if (GT 1) ? ? then 3 elseif 7 (GT 1) 7 then 3 elseif ? ? (GT 1) then 3 else -3))) (Water&recirc (* definition of new knowledge group) Table (match (AskYNU? "Are the recirc flow control valves in normal position") (AskHLN? “What is the feedwater temperature") with (if F ? then elseif (OR L LL) then else -3))) (Reactor (* Reactor Water Level. Pressure and Power Checking) Table (match (AskHLN? "What is the reactor pressure") (AskHLN? "What is the reactor power level") (AskTrend? "What is the reactor pressure trend”) (AskTrend? "What is the reactor power level trend") (• decision knowledge) wi th (if (OR H HH) (OR H HH) ? ? then 3 elseif ? (OR H HH) (OR S 1 II) (OR I II) then 3 else -3))) (HPCS (• Checking the LPCI mode of the RHR) Table (• or RULES) (match (AskYNU? "Is HPCS pump running”) (AskYNU? "Is HPCS lined up to deliver water to RPV") with (if T T then 3 elseif T U then 2 else -3] (messages (Establish (* the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self summary))))
(Special ist HighCoolantConductivity (• specialist for HighCoolantConductivity) (declare (LoopsSuper NPPSpecialist) {CASPIAN:LAIR:OHIO-STATE}
(Superspecialist CooiSysFauit) (Subspecialists DemineralizerFail RWCUFail CondenserTubeLeak)) [kgs (Conductivity (* definition of new knowledge group) Table (match (AskHLN? "What is the coolant conductivity") (AskTrend? "What is the coolant conductivity trend") with (if (OR H HH) (OR I II) then 3 elseif ? (OR I II) then 2 elseif (OR H HH)
then 2 else -3] (messages (Establish (* the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self Conductivity))))
(Specialist ReliefValveOpen (• specialist for ReliefValvStuckOpen) (declare (Superspecialist LOCA) (LoopsSuper NPPSpecialist)) [kgs (srvopen (* definition of new knowledge group) Table (match (AskYNU? "Are there any SRVs open") (AskHLN? “What is the suppression pool temperature") (AskTrend? "What is the suppression pool temperature trend") (AskHLN? "What is the suppression pool water level") wi th (if T (OR N H HH) (OR 1 II) (OR H N HH) then 3 elseif (OR F U) (OR H HH) (OR I II) (OR H HH) then 3* elseif (OR F U) N (OR I II) ? then 2* else -3))) (press Table (match (AskHLN? "What is the drywell pressure") with (if N then -3 else 0 ))) (Reactor (• definition of new knowledge group) Table (match (AskHLN? "What is the reactor power level") (AskHLN? "What is the turbine electrical output") with (if (OR N L) (OR L LL) then 3 else -3] [messages (Establish (if (LT press 1) then (if (OR (EQ srvopen (QUOTE 2*)) {CASPIAN:LAIR:OHIO-STATE}
(EQ srvopen (QUOTE 3*))) then (DoLisp («- (S! currentCase) StoreSusData SPECIALIST KGName CaseNo) (SPECIALIST self) (KGName (QUOTE srvopen)) (CaseNo ($! currentCase))) (SetConfidence self srvopen) else (SetConfidence self srvopen)) else (SetConfidence self press])
(Specialist RecircLineProblem (• specialist for RecircLineBrk) (declare (Subspecialists) (LoopsSuper NPPSpecialist) (Superspecialist LOCA)) [kgs (recirc (* definition of new knowledge group) Table (match (AskHLN? "What s i the reactor water level") (AskHLN? "What is the drywell pressure") (AskHLN? "What s the drywell sump level") (AskHLN? "What s the reactor pressure") (AskTrend? "What is the reactor water level trend") (AskTrend? "What is the drywell pressure trend”) (AskTrend? "What is the reactor pressure trend") with (if LL HH HH L 7 7 7 then 3 elseif ? ? ? ? DO II (OR 0 DD) then 3 elseif ? ? ? ? ? II (OR D DD) then 2 elseif ? HH HH 7 7 7 7 then 2 elseif LL HH ? 7 7 7 7 then 2 elseif LL ? HH ? 7 7 7 then 2 else -3] (messages (Establish (• the default Establish message set the confidence value to the value of-V summary. _ e*its __ _ active__ if established, finished if rejected, and suspended otherwise) (SetConfidence self recirc))))
(Specialist SteamLineBrk (• specialist for SteamLineBrk) (declare (Subspecialists LargeBreak SmallBreak) (LoopsSuper NPPSpecialist) (Superspecialist LOCA)) [kgs (SteamLineBreak (• definition of new knowledge group) Table (match (AskHLN? "What is the steam flow rate") (AskHLN? "What is the turbine electrical output") (AskHLN? "What is the reactor pressure") (AskHLN? "What is the suppression poo! water level") (AskHLN? "What is the containment pressure") with (if (OR H HH) (OR (NOT H) (NOT HH)) (OR L LL) ? ? then 3 152 {CASPIAN:LAIR:OHIO-STATE>
elseif (OR? H HH) (OR L LL) H ? then 3 elseif ? ? (OR L LL) H H then 3 else -3j (messages (Establish (* the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self SteamLineBreak))))
(Specialist OutsideContainmentLOCA (• specialist for OutsideContainmentLOCA) (declare (LoopsSuper NPPSpecialist) (Superspecialist LOCA)) [kgs (summary Table (• the default summary knowledge group simply asks the user to enter the confidence value of the specialist) (match FeedWaterLineBreak SteamLineBreak with (if 3 ? then 3 elseif ? 3 then 3 elseif (GT 1) (GT 1) then 3 elseif ? (GT l ) then 2 elseif ? (GT 1) then 2 else -3))1 (SteamLineBreak (• definition of new knowledge group) Table (match (AskHLN? "What is the steam flow rate") (AskHLN? "What is the turbine electrical output") (AskHLN? "What is the reactor pressure") (AskHLN? "What is the suppression pool water level") (AskHLN? "What is the containment pressure") with (if (OR H HH) (OR (NOT H) (NOT HH)) (OR L LL) N N then 3 elseif (OR H HH) (OR L LL) ? N N then 3 elseif ? ? (OR L LL) N N then 3 else -3))) (FeedWaterLineBreak (• definition of new knowledge group) Table (match (AskHLN? "What is the reactor water level") (AskHLN? "What is the drywell pressure") (AskHLN? "What is the drywell sump level") [CASPIAN:LAIR:OHIO-STATE}
(AskHLN? "What is the reactor pressure") (AskTrend? "What is the reactor water level trend") (AskTrend? "What is the drywell pressure trend") (AskT rend? 'What is the reactor pressure trend") with (if LL N N L ? ? then 3 elseif ? ? (OR D DD) S S then 3 elseif ? ? ? ? ? S S then -2 elseif ? HH HH ?.? ? S then -2 elseif LL HH ? ? ? S ? then -2 elseif LL ? HH ? ? ? S then -Z else -3] ,v (messages (Establish (• the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self summary))))
(Specialist OtherSmallLeakages (• specialist for OtherLeakages) (declare (Subspecialists) (LoopsSuper NPPSpecialist) (Superspecialist LOCA)) [kgs (recirc (• definition of new knowledge group) Table (match (AskTrend? "What is the reactor water level trend") (AskTrend? "What is the drywell pressure trend"! (AskTrend? "What is the drywell temperature trend") (AskTrend? "What is the reactor pressure trend") (AskTrend? "What is the drywell sump level trend") wi th (if D I I D I then 3 elseif ? (OR I S) 7 (OR S D) I then 3 else -3] (messages (Establish (* the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self reci rc))))
(Specialist HighAuxTankLev (• specialist for HighAuxTankLev) (declare (Subspecialists CondensateStorageTank HotSurgeTank HotwellTank) (LoopsSuper NPPSpecialist) (Superspecialist Lowlnventory)) [kgs (summary (• definition of new knowledge group) Table (match hst cst hotwell with {CASPIAN:LAIR:OHIO-STATE}
(if 3 ? ? then 3 elseif ? 3 ? then 3 elseif ? ? 3 then 3 elseif 2 2 2 then 3 elseif 2 2 ? then 2 elseif 2 ? 2 then 2 elseif ? 2 2 then 2 elseif -3 -3 -3 then -3 elseif -3 -2 -3 then -2 elseif -2 (LE -2) -3 then -2 elseif -2 0 -3 then -1 elseif 0 -2 -3 then -1 else 0 ))) (hst (* definition of new knowledge group) Table (match (AskHLN? "What is t,he hot surge tank level") (AskHLN? "What is the hot surge tank level control output") (AskHLN? "What is the FW heater outlet flow— input to HST") (AskHLN? "What is the total reactor FW flow") wi th (if (OR H HH) (OR N H HH) (OR N H HH) (OR N L LL) then 3 elseif (OR H HH) (OR H HH) ? ? then 2 elseif (OR H HH) 7 (OR H HH) (OR N L LL) then 2 elseif N N N N then -3 elseif (OR H HH) ? ? ? then 1 elseif (OR N L LL) ? HH LL then 3* elseif (OR N L LL) 7 (OR N H HH) (OR L LL) then 2* else 0 ))) [hotwel1 (• definition of new knowledge g r o u p ) Table (match (AskHLN? "What is the hotwell storage tank level" with (if HH then 3 elseif H then 2 elseif N 155 {CASPIAN:LAIR:OH10-STATE}
then -3 elseif L then -3 elseif LL then -3 (' or RULES) (• decision knowledge) ] (cst (• definition of new knowledge group) Table (match (AskHLN? "What is the condensate storage tank level") (AskHLN? "What is the FW reject flow to the condensate storage tank") (AskHLN? "What is the emergency hotwell makeup control valve position") (AskHLN? "What is the normal hotwell makeup control valve position") with (if (OR H HH) (OR H HH) (OR H HH) (OR H HH) then 3 elseif (OR H HH) (OR H HH) ? ? then 2 elseif (NOT (OR L LL)) (OR H HH) (OR H HH) (OR H HH) then 2 elseif (OR N L LL) (OR L LL) (OR L LL) (OR L LL) then -3 elseif (OR N L LL) (OR L LL) ? ? then -2 else 0 ] [messages (Establish (if (OR (EQ hst (QUOTE 3*)) (EQ hst (QUOTE 2*))) then (DoLisp («- (I! currentCase) StoreSusData SPECIALIST KGName CaseNo) (SPECIALIST self) (KGName (QUOTE hst)) (CaseNo ($! currentCase))) (SetConfidence self hst) else (SetConfidence self summary])
(Specialist LowPressOueToEHCFault (• specialist for PressRegulatorFail Open) (declare (LoopsSuper NPPSpecialist) (Superspecialist Lowlnventory)) [kgs (Pressure (• definition of new knowledge group) Table (• or RULES) (match (AskHLN? "What is the reactor pressure") (AskHLN? "What is the reactor water level") (AskHLN? "What is the steam flow rate”) (AskTrend? "What is the reactor pressure trend") (* decision knowledge) with (if (OR L LL) (OR L LL) (OR H HH) (OR S D 00) then 3 156 {CASPIAN:LAIR:OHIO-STATE}
elseif (OR L LL) (OR L LL) ? ? then 2 elseif ? (OR L LL) (OR H HH) (OR D DD) then 2 else -3] (messages (Establish (* the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self Pressure))))
(Specialist LossOfFeedwaterFlow (• specialist for FeedWaterPumpTrip) (declare (Subspecialists InadvertValveClsr HighFWRecircFlow FWPTurbTrip/LowSpeed) (Superspecialist Lowlnventory) (LoopsSuper NPPSpecial ist)) [kgs (mfwp Table (• definition of new knowledge group) (match (AskYNU? "Are the feedwater pumps running normally") (AskHLN? "What is the feedwater flow rate") (AskHLN? "What is the reactor power level") (AskTrend? "What is the reactor power level trend") with (if T N N S then -3 elseif F (OR L LL) ?(NOT (OR L LL)) then 3 elseif U (OR L LL) ?(NOT (OR L LL)) then 1 elseif U (OR L LL) (OR L LL) 7 then -1 elseif F ? ? ? then 2 else -1] (messages (Establish (* the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self mfwp))))
(Specialist FWControllerFailLow (• specialist for LossOfCoolantAccident) (declare (LoopsSuper NPPSpecialist) (Superspecialist Lowlnventory) (Subspecialists)) [kgs (mfwp Table (• definition of new knowledge group) (match (AskYNU? "Are the feedwater pumps running normally") (AskHLN? "What is the feedwater flow rate") (AskHLN? "What is the reactor power level") (AskTrend? "What is the reactor power level trend") with (if T N N S {CASPIAN:LAIR:OHIO-STATE}
then -3 elseif F (OR L LL) ?(NOT (OR L LL)) then 3 elseif U (OR L LL) ?(NOT (OR L LL)) then 1 elseif U (OR L LL) (OR L LL) 7 then -1 elseif F ? ? ? then 2 else -1))) (fwcfl (* definition of new knowledge group) (• or RULES) (" decision knowledge) Table (match (AskHLN? "What is the feedwater flow rate") (AskTrend? "What is the feedwater flow trend") (AskHLN? "What is the reactor power level") with (if (OR L LL) (OR S D DD) (NOT (OR L LL)) then 3 elseif ? (OR D DD) 7 then 2 else -3] [messages (Establish (if (LT mfwp 1) then (SetConfidence self fwcfl) else (SetConfidence self 2])
(Specialist FWControllerFailHigh (• specialist for FWControllerFail) (declare (LoopsSuper NPPSpecialist) (Superspecialist Highlnventory)) [kgs (WaterLevel (• definition of new knowledge group) Table (• or RULES) (match (AskHLN? "What is the reactor water level") (AskHLN? "What is the feedwater pumps speed") with (if (OR H HH) (OR H HH) then 3 elseif (OR H HH) 7 then 2 else -3))) (LowInventorylnTanks (• If low inventory in any of these tanks, then water level must be high in the Rx.) Table (match (AskHLN? "What is the condensate storage tank level") (AskHLN? "What is the hot surge tank level") (AskHLN? "What is the hot well level") (* decision knowledge) with (if (OR L LL) (OR L LL) (OR L LL) then 3 elseif (OR L LL) (OR L LL) {CASPIAN:LAIR:OHIO-STATE}
(Specialist ECCS&FWCE rr (• specialist for Eccslnitiation) (declare (Superspecialist Highlnventory) (LoopsSuper NPPSpecial ist) (Subspecialists LowPressureSystem HighPressureSystem)) [kgs (ECCS Table (match (AskYNU? "Are there alarms indicating ECCS initiation”) with (if T then 3 else -3] (messages (Establish (• the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self ECCS))))
(Special ist TurbineControlValve (• specialist for TubContValv) (declare (Subspecialists) (LoopsSuper NPPSpecial ist) (Superspecialist LossOfHeatSink)) [kgs (TurbineControlValve (• definition of new knowledge group) Table (match (AskYNU? "Are the MSIVs open") (AskYNU? "Are the turbine control valves in normal position”) (AskHLN? "What is the turbine electrical output”) (AskYNU? "Are the turbine bypass valves closed") with (if T F (NOT N) T then 3 elseif T T (OR L LL) T then 3* elseif T T ? ? then -3 else -3] (messages (Establish (• the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self TurbineControlValve)))) {CASPIAN:LAIR:OHIO-STATE>
(Specialist ClosedMSIVs (• specialist for ClosedMSIVs) (declare (LoopsSuper NPPSpecialist) (Superspecialist LossOfHeatSink)) [kgs (Reactor Table (natch (AskYNU? "Are the MSIVs open") (AskHLN? "What is the reactorpressure") (AskHLN? "What is the steam flow rate") (AskYNU? "Are there any SRVs open") with (if (OR T U) (OR N H HH) (OR L LL) T then 3» elseif (OR T U) (OR H HH) ?(OR L LL) then l» else -3))) (MSIV (* definition of new knowledge group) Table (match (AskYNU? "Are the MSIVs open") (AskYNU? "Are the turbine stop valves closed") (AskTrend? "What is the turbine electrical output trend") with (if F T (OR D DD) then 3 elseif T T (OR D 00) then 2" elseif F T S then 1* else -3] [messages (Establish (if (GT MSIV 2) then (SetConfidence self MSIV) elseif (OR (EQ MSIV (QUOTE 1*)) (EQ MSIV (QUOTE 2*))) then (DoLisp (•■ ($'■ currentCase) StoreSusData SPECIALIST KGName CaseNo) (SPECIALIST self) (KGName (QUOTE MSIV)) (CaseNo ($! currentCase))) ■ [if (OR (EQ Reactor (QUOTE 1*)) (EQ Reactor (QUOTE 3*))) then (DoLisp (•- ($! currentCase) StoreSusData SPECIALIST KGName CaseNo) (SPECIALIST self) (KGName (QUOTE Reactor)) (CaseNo ($! currentCase] (SetConfidence self Reactor) elseif (OR (EQ Reactor (QUOTE 1»)) (EQ Reactor (QUOTE 3*))) then (DoLisp («- ($•' currentCase) StoreSusData SPECIALIST KGName CaseNo) (SPECIALIST self) (KGName (QUOTE Reactor)) (CaseNo ($! currentCase))) (SetConfidence self MSIV])
(Specialist CondenserFail (• specialist for Condensor) (declare (LoopsSuper NPPSpecialist) (Subspecialists SteamAirEjectorsFail LossOfCircPump) (Superspecialist LossOfHeatSink)) {CASPIAN:LAIR:OHI0-STATE}
[kgs (Vacuum (• definition of new knowledge group) Table (match (AskHLN? "What is the condenser pressure") (AskTrend? "What is the condenser pressure trend") (AskHLN? "What is the condenser temperature") (AskTrend? "What is the condenser temperature trend") (• or RULES) with (if (OR H HH) (OR I II) ? ? then 3 elseif ? ? (OR H HH) (OR I II) then 3 else -3] (messages (Establish (• the default Establish message set the confidence value to the value of Vacuum exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self Vacuum))))
(Specialist TurbLoadRejWOBypass (• specialist for TurbineLoadRejection) (declare (LoopsSuper NPPSpecialist) (Superspecialist LossOfHeatSink)) [kgs (Valves (• definition of new knowledge group) Table (match (AskYNU’ Are the MSIVs open") (AskHLN What is the reactor power”) (AskHLN What is the turbine elctrical output") (AskYNU Are the turbine bypass valves closed") (AskYNU Are the turbine stop valves closed") with (if T (OR N H HH) (OR L LL) T T then 3 elseif T (OR N H HH) (OR L LL) ? T then 3* else -3] (messages (Establish (SetConfidence self Valves))))
(Specialist HighPressDueToEHCFault (• specialist for OverPressAcc) (declare (LoopsSuper NPPSpecialist) (Superspecialist Rx-OverPower)) [kgs (PressureRegFailClosed (• definition of new knowledge group) Table (match (AskHLN? "What is the steam flow rate") (AskT rend? "What is the reactor pressure trend") (AskTrend? "What is the turbine electrical output trend") with (if (OR H N HH) (OR I II) (OR S D OD) then 3 elseif ? (OR I II) (OR S D DO) then 1* {CASPIAN:LAIR:OHIO-STATE}
else -3] (messages (Establish (• the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self PressureRegFailClosed))))
(Specialist ColdWaterAcc (• specialist for ColdWaterAcc) (declare (Superspecialist Rx-OverPower) (Subspecialists LossOfFWHtr HPCSInjection) (LoopsSuper NPPSpecialist)) [kgs (WaterTemp (• definition of new knowledge group) Table (match (AskHLN? "What is the feedwater temperature") (AskTrend? "What is the reactor water level trend") (AskTrend? "What is the feedwater temperature trend") (AskTrend? "What is the reactor power level trend") with (if (OR L N) (OR S I) (OR D S DO) (OR I II) then 3 elseif (OR H N) (OR S I II) (OR S 0 DD) (OR I II) then 3* elseif ? (OR S I II) (OR I II) then 1* else -3))) (WaterSSteamFlow (• definition of new knowledge group) Table (match (AskHLN? "What is the steam flow rate") (AskTrend? "What is the steam flow trend”) (AskHLN? "What is the feedwater flow rate") (AskT rend? "What is the feedwater flow trend") with (if N S (OR N L LL) (OR S D OD) then 3 elseif N ? (OR N L LL)
then 3 else -3] [messages (Establish (if (GT WaterSSteamFlow 1) then (SetConfidence self WaterTemp) else (SetConfidence self WaterSSteamFlow])
(Specialist Reci rcFCVErr (• specialist for Reci rcPumpOverSpeed) (declare (LoopsSuper NPPSpecialist) (Superspecialist Rx-OverPower)) [kgs (RecircFCV (• definition of new knowledge group) Table (match (AskYNU? Are the recirc flow control valves in normal position") (AskHLN? "What is the jetpumps flow rate") (AskTrend? "What is the jetpumps flow trend") (CASPIAN:LAIR:OHIO-STATE}
with (if T ? ? then -3 elseif F ? ? then 3 elseif ? (NOT N) then 3 elseif ? ? (NOT S) then 3 else -3] (messages (Establish (• the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self RecircFCV))))
(Special 1st. Demineral izerFail (• specialist for DemineralizerFail) (declare (LoopsSuper NPPSpecialist) (Superspecialist HighCoolantConductivity)) [kgs (DeminFailure (• definition of new knowledge group) Table (match (AskYNU? "Are the demineralizers working normally") with (if F then 3 else -3] (messages (Establish (• the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self DeminFa’lure))))
(Specialist RWCUFai1 (• specialist for RWCUFail) (declare (LoopsSuper NPPSpecialist) (Superspecial ist HighCoolantConductivity)) [kgs (RWCU (• definition of new knowledge group) Table (match (AskYNU? "Has the Rad Waste Clean Up System failed") with (if T then 3 else -3] (messages (Establish (• the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self RWCU))))
(Specialist CondenserTubeLeak (• specialist for CondenserTubeLeak) (declare (LoopsSuper NPPSpecialist) (Superspecialist HighCoolantConductivity)) [kgs (CondenserTube (• definition of new knowledge group) 163 {CASPIAN:LAIR:OHIO-STATE}
Table (natch (AskYNU? "Is there any leakage in the condenser tubes") with (if T then 3 else -3] (messages (Establish (• the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self CondenserTube))))
(Specialist LargeBreak (* specialist for SmallBreak) (declare (LoopsSuper NPPSpecialist) (Superspecialist SteamLineBrk)) [kgs (LargeBreak (• definition of new knowledge group) Table (match (AskHLN? 'What is the steam flow rate") (AskHLN? 'What is the turbine electrical output") (AskHLN? 'What is the reactor pressure") (AskHLN? "What is the suppression . pool water level") (AskHLN? "What i:s the containment pressure") with (nf HH (NOT HH) LL ? f then 3 elseif HH ? LL H ? then 3 elseif ? ? LL 1H H then 3 else 3] (messages (Establish (* the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self LargeBreak))))
(Specialist SmalIBreak (• specialist for LargeBreak) (declare (LoopsSuper NPPSpecialist) (Superspecialist SteamLineBrk)) [kgs (SmallBreak (• definition of new knowledge group) Table (match (AskHLN? "What is the steam flow rate") (AskHLN? "What is the turbine electrical output") (AskHLN? "What is the reactor pressure") (AskHLN? "What is the suppression pool water level") (AskHLN? "What is the containment pressure") with (if H (NOT H) L ? ? then 3 elseif H ? L H ? then 3 elseif ? ? L HH then 3 elseif H L L ? ? then 2* else -3] (messages (Establish (* the default Establish message 164 {CASPIAN: LAIR :OHIO-STATE}
set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self SmallBreak))))
(Specialist CondensateStorageTank ( # specialist for CondensateStorageTank) (declare (Superspecialist HighAuxTankLev) (LoopsSuper NPPSpecialist)) [kgs (cst (» definition of new knowledge group) Table (match (AskHLN? "What is the condensate storage tank level”) (AskHLN? "What is the FW reject flow to the condensate storage tank") (AskHLN? "What is the emergency hotwell control valve position") (AskHLN? "What is the normal hotwell makeup control valve position") with (if (OR H HH) (OR H HH) (OR H HH) ' (OR H HH) then 3 elseif (OR H HH) (OR H HH) ? ? then 2 elseif (NOT (OR L (OR H HH) (OR H HH) (OR H HH) then 2 elseif (OR N L LL) (OR L LL) (OR L LL) (OR L LL) then -3 elseif (OR N L LL) (OR L LL) ? ? then -2 else 0] [messages (Establish (* the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self cst) (if (+? self) then (Exit active) elseif (-? self) then (Exit finished) else (Exit suspended])
(Specialist HotSurgeTank (• specialist for HotSurgeTAnk) (declare (Superspecialist HighAuxTankLev) (LoopsSuper NPPSpecialist)) [kgs (hst (• definition of new knowledge group) Table (match (AskHLN? "What is the hot surge tank level”) (AskHLN? "What is the hot surge tank level control output”) (CASPIAN;LAIR:OHIO-STATE>
(AskHLN? "What is the FW heater outlet flow— Input to HST") (AskHLN? "What is the total reactor FW flow") with (if (OR H HH) (OR N H HH) (OR N H HH) (OR N L LL) then 3 elseif (OR H HH) (OR H HH) ? ? then 2 elseif (OR H HH) 7 (OR H HH) (OR N L LL) then 2 elseif N N N N then -3 elseif (OR H HH) ? ? ? then 1 elseif (OR N L LL) ? HH LL then 3* elseif (OR N L LL) 7 (OR N H HH) (OR L LL) then 2 * else 0 ] [messages (Establish (• the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwi se) (SetConfidence self hst) (if [or (+? self) (or (Eq (ConfidenceValue of self) (QUOTE 2*)) (Eq (ConfidenceValue of self) (QUOTE 3»] then (Exit active) elseif (-? self) then (Exit finished) else (Exit suspended])
(Specialist HotwellTank (* specialist for HotwellTank) (declare (Superspecialist HighAuxTankLev) (LoopsSuper NPPSpecialist)) [kgs (hotvelltank (• definition of new knowledge group) Table (match (AskHLN? What is the hotwell level") with (if HH then 3 elseif H then 2 elseif L then -3 elseif LL then -3 elseif N then -3 else 0 ] (messages (Establish (• the default Establish message set the confidence value to the value of summary, exits active 166 [CASPIAN:LAIR:OHIO-STATE}
if established, finished if rejected, and suspended otherwise) (SetConfidence self hotwelltank))))
(Specialist InadvertVal veClsr (• specialist for InadvertValveClsr) (declare (Superspecialist LossOfFeedwaterflow) (LoopsSuper NPPSpecialist)) [kgs (valves (• definition of new knowledge group) Table (match (AskYNU? 'Is the FW 6A inlet valve open") (AskYNU? "Is the FW 6B inlet valve open") with (if T T then elseif then elseif ? F then else 0 ))) (summ (* definition of new knowledge group) Table (match heatervalve valves dschvalve with (if -3 -3 -3 then -3 elseif 3 ? then 3 elseif ? 3 ? then 3 elseif ? ? 3 then 3 else 0 ))) (heatervalve (• definition of new knowledge group) Table (match (AskYNU? "Is the heater 6A inlet valve open") (AskYNU? "Is the heater 6B inlet valve open”) (AskYNU? "Is the heater 6A outlet valve open") (AskYNU? "Is the heater 6B outlet valve open") (AskYNU? "Is the 6th string heater bypass valve open") with (if T T T T ? then -3 elseif ? ? ? ? T then. -2 elseif F ? ? ? F then 3 elseif ? F ? ? F then 3 elseif ? ? F ? F then 3 elseif 7 ? ? F F then 3 else 0 ))) (dschvalve (• definition of new knowledge group) Table (match (AskYNU? "Is the FWP-A discharge valve open") (AskYNU? "Is the FWP-Bdischarge valve open") with (if T T then -3 elseif F ? then 3 elseif ? F then 3 else o] {CASPIAN:LAIR:OHIO-STATE}
[messages (Establish (* the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self summ) (if [or (+? self) (or (Eq (ConfidenceValue of self) (QUOTE 2*)) (Eq (ConfidenceValue of self) (QUOTE 3»] then (Exit active) elseif (-? self) then (Exit finished) else (Exit suspended])
(Specialist HighFWReci rcFlow (• specialist for HighFWRecircFlow) (declare (Superspecialist LossOfFeedwaterFlow) (LoopsSuper NPPSpecialist) (Subspecialists Line-B Line-A)) [kgs (summ (• definition of new knowledge group) Table (match fwrecirc-a fwrecirc-b with (if -3 -3 then -3 elseif 3 ? then 3 elseif ? 3 then 3 elseif 2 (GE 1) then 3 elseif (GE 1) 2 then 3 else 0 ))) (fwrecirc-b (• definition of new knowledge group) Table (match (AskHLN? "What is the FWP-B suction flow") (AskHLN? "What is the FW flow in line-B") (AskHLN? "What is the FWP-B turbine speed") (AskHLN? "What is the line-B FW recirculation flow”) with (if (OR N H HH) (OR N H HH) (OR N H HH) N then -3 elseif (OR N H HH) (OR L LL) (OR N H HH) (OR H HH) then 3 elseif ? (OR L LL) (OR N H HH) (OR H HH) then 2 elseif (OR N H HH) (OR L LL) 7 (OR H HH) then 2 elseif ? (OR L LL) (OR N H HH) 7 then 1 elseif (OR N H HH) 168 {CASPIAN:LAIR:OHIO-STATE}
(OR L LL) ? N then 2». elseif HH LL ? (OR N L LL) then 3* else 0 ))) (fwrecirc-a (• definition of new knowledge group) Table (match (AskHLN? "What is the FWP-A suction flow") (AskHLN? "What is the FW flow in line-A") (AskHLN? "What is the FWP-A turbine speed") (AskHLN? "What is the line-A FW recirculation flow") with (if (OR N H HH) (OR N H HH) (OR N H HH) N then -3 elseif (OR N H HH) (OR L LL) (OR N H HH) (OR H HH) then 3 elseif ? (OR L LL) (OR N H HH) (OR H HH) then 2 elseif (OR N H HH) ?(OR L LL) (OR H HH) then 2 elseif ? (OR L LL) ?(OR N H HH) then 1 elseif (OR N H HH) (OR L LL) ? N then 2* elseif HH LL ? (OR N L LL) then 3* else 0] [messages (Establish (• the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self fwrecirc) (if [or (+? self) (or (Eq (ConfidenceValue of self) (QUOTE 2*)) (Eq (ConfidenceValue of self) (QUOTE 3*] then (Exit active) elseif (-? self) then (Exit finished) else (Exit suspended])
(Specialist FWPTurbTrip/LowSpeed (• specialist for FWPTurbTrip/LowSpeed) (declare (Subspecialists FWBPTrip LowAuxCondVac FWPTurbCntrlValveClsr LowNPSH FWPSuctValveClsr HighFWDschPress) (LoopsSuper NPPSpecialist) (Superspecialist LossOfFeedwaterFlow)) [kgs (turbtrip (• definition of new knowledge group) Table {CASPIAN:LAIR:OHIO-STATE}
(match (AskHLN? "What is the FWP-A turbine speed") (AskHLN? "What is the FWP-B turbine speed") (AskYNU? "Is the FWP-A discharge valve open") (AskYNU? "Is the FWP-B discharge valve open") with (if (OR N H HH) (OR N H HH) T T then -3 elseif (OR L LL) ? ? ? then 2 elseif ? (OR L LL) ? ? then 2 elseif (OR L LL) ? F ? then 3 elseif 7 (OR L LL) ? F then 3 elseif ? ? F ? then 2 elseif ? ? ? F then 2 else 0 ))) (tripsignal (? definition of new knowledge group) Table (match (AskYNU? "Is the FWP-A tripped") (AskYNU? "Is the FWP-B tripped") with (if F F then -3 elseif T ? then 3 elseif ? T then 3 else 0 ))) (summary Table (match turbtrip tripsignal with (if -3 -3 then -3 elseif ? 3 then 3 elseif 2 0 then 2 elseif 3 ? then 3 else 0] (messages (Establish (* the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self summary))))
(Specialist LowPressureSystem (• specialist for LowPressureSystem) (declare (Subspecialists LPCS LPCI)) [kgs (lp (• Chacking for LOW press Systems) Table (• or RULES) (match (AskYNU? "Is the reactor pressure below 300 psia") (* decision knowledge) with (if F then -3 else 3] (messages (Establish (• the default Establish message {CASPIAN:LAIR:OHIO-STATE}
set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self Ip))))
(Special 1st HighPressureSystem {* specialist for HighPressureSystem) (declare (Subspecialists HPCS RCIC) (Superspecialist ECCS&FWCErr)) [kgs (hp (• hp kgs to check for high pressure systems) Table (• or RULES) (match (AskYNU? "Are there alarms Indicating ECCS initiation") (AskYNU? "Is the reactor pressure below 300 psia") (AskYNU? "Is the reactor pressure above 100 psia") (* decision knowledge) with (if F ? ? then -3 elseif ? T ? then 3 elseif ? ? T then 2 else 0] (messages (Establish (* the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self hp))))
(Specialist SteamAirEjectorsFail (• specialist for Ai rRejectorsFail) (declare (LoopsSuper NPPSpecialist) (Superspecialist CondenserFail)) [kgs (AirRejectors (• definition of new knowledge group) Table (match (AskHLN? "What is the condenser pressure") (As kTrend? "What is the condenser pressure trend") with (if ? (OR H HH) then 3 elseif ? (OR 1 II) then 3 else -3] (messages (Establish (* the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self AirRejectors))))
(Specialist LossOfCi rcPump (• specialist for LossOfCircPump) (declare (LoopsSuper NPPSpecialist) (Superspecialist CondenserFail)) [kgs (CirculationPump (• definition of new knowledge group) (CASPIAN:LAIR:OHIO-STATE>
Table (match (AskHLN? "What is the condenser temperature") (AskTrend? "What is the condenser temperature trend”) with (if ? (OR H HH) then 3 elseif ? (OR I II) then 3 else -3] (messages (Establish (• the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self CirculationPump))))
(Specialist LossOfFWHtr (• specialist for LossOfFWHTR) (declare (LoopsSuper NPPSpecialist) (Superspecialist ColdWaterAcc)) [kgs (WaterSSteamFlow (• definition of new knowledge group) Table (match (AskHLN? "What is the steam flow rate") (AskTrend? "What is the steam flow trend") (AskHLN? "What is the feedwater flow rate") (AskTrend? "What is the feedwater flow trend") wi th (if N S N S then 3 elseif N ? N ? then 2 else -3))) (Reactor (* definition of new knowledge group) Table (match (AskHLN? "What is the feedwater temperature") (AskTrend? "What is the reactor power level trend") (AskTrend? "What is the reactor water level trend") (AskTrend? "What is the feedwater temperature trend") with (if (OR N L LL) (OR I II) (OR S I II) (OR 0 DD) then 3 elseif (OR H HH) (OR I II) (OR S 1 II) (OR 0 DD) then 3* else -3] [messages (Establish (if (GT WaterSSteamFlow 1) then (if (EQ Reactor (QUOTE 3*)) then (DoLisp («- (J! currentCase) StoreSusData SPECIALIST KGName CaseNo) (SPECIALIST self) (KGName (QUOTE Reactor)) (CaseNo ($! currentCase))) (SetConfidence self Reactor) else (SetConfidence self Reactor)) else (SetConfidence self WaterSSteamFlow])
(Specialist HPCSInjection (• specialist for ECCSInjectio) {CASPIAN:LAIR:OHIO-STATE}
(declare (Subspecialists) (LoopsSuper NPPSpecialist) (Superspecialist ColdWaterAcc)) [kgs (HPCS Table (match (AskYNU? "Is HPCS pump running") (AskYNU? "Is HPCS linedup to deliver water to RPV") with (if T T then 3 else -3))) (ECCSInjectn (• definition of new knowledge group) Table (match (AskYNU? "Are there alarms indicating ECCS initiation") (AskHLN? "What is the feedwater flow rate") (AskHLN? "What is the reactorwater level”) with (if T (OR L LL N) (OR N H HH) then 3 elseif F (OR L LL N) (OR N H HH) then 2* elseif F ? ? then -3 else r3] [messages (Establish (if (GT HPCS 0) then (if (EQ ECCSInjectn (QUOTE 2»)) then (DoLisp («- ($! currentCase) StoreSusData SPECIALIST KGName CaseNo) (SPECIALIST self) (KGName (QUOTE ECCSInjectn) ) (CaseNo ($! currentCase))) (SetConfidence self ECCSInjectn) else (SetConfidence self ECCSInjectn)) else (SetConfidence self HPCS])
(Specialist Line-B (• specialist for Line-B) (declare (Superspecialist HighFWRecircFlow) (LoopsSuper NPPSpecialist)) [kgs (recircline-b (• definition of new knowledge group) Table (match (AskHLN? "What is the feedwater recirculation flow in line-B") with (if H then 2 elseif HH then 3 elseif N then -3 elseif L then -2 elseif LL then -3 else 0 ] [messages (Establish (* the default Establish message set the confidence value to the value of summary. e»its active if established, finished if rejected, and suspended otherwise) (SetConfidence self recircline-b) (if [or (♦? self) (or (Eq (ConfidenceValue of self) (QUOTE 2*)) (Eq (ConfidenceValue of self) {CASPIAN:LAIR:OHIO-STATE}
(QUOTE 3*] then (Exit active) elseif (-? self) then (Exit finished) else (Exit suspended])
(Specialist line-A (• specialist for Line-A) (declare (Superspecialist HighFWRecircFlow) (LoopsSuper NPPSpecialist)) [kgs (recircline-a (• definition of new knowledge group) Table (match (AskHLN? "What is the feedwater recirculation flow in line-A") with (if H then 2 elseif HH then 3 elseif N then -3 elseif L then -2 elseif LL then -3 else 0 ] [messages (Establish (• the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self recircline-a) (if [or (■►? self) (or (Eq (ConfidenceValue of self) (QUOTE 2*)) (Eq (ConfidenceValue of self) (QUOTE 3*] then (Exit active) elseif (-? self) then (Exit fimshed) else (Exit suspended])
(Specialist FWBPTrip (• specialist for FWBPTrip) (declare (Subspecialists LowHotSurgeTank HighFWBPDschPress LowFWBPSuctPress) (LoopsSuper NPPSpecialist) (Superspecialist FWPTurbTrip/LowSpeed)) [kgs (boosterpumps (• If all of the booster pumps trip then a trip signal is sent to the feed water pumps however, if at least one pump is operating the signal will not be sent.)
Table (match (AskYNU? "Is the FWBP-A tripped") (AskYNU? "IS the FWBP-B tripped") (AskYNU? "Is the FWBP-C tripped") (AskYNU? "Is the FWBP-D tripped") with (if T T T T then 3 elseif F F F F then -3 else 0] (messages (Establish (* the default Establish message set the confidence value to the {CASPIAN:LAIR:OHIO-STATE}
value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self boosterpumps))))
(Specialist LowAuxCondVac (• specialist for LowAuxCondVac) (declare (Superspscialist FWPTurbTrip/LowSpeed) (LoopsSuper NPPSpecialist)) [kgs (auxcondvacuum (• The FW pump turbines will trip if the auxiliary condenser vacuum decreases to 18.5 Hg and is still decreasing.) Table (match (AskHLN? "What is the auxiliary condenser-A vacuum") (AskHLN? "What is the auxiliary condenser-B vacuum") (AskTrend? "What is the auxiliary condenser-A vacuum trend") (AskTrend? "What is the auxiliary condenser-B vacuum trend") with . (if N N S S then -3 elseif LL ? (OR D DD) 7 then 3 elseif L ? (OR D DD)
then elseif LL ’ (OR D DD) then elseif ? L ? (OR D DD) then else 0] (messages (Establish (• the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self auxcondvacuum))))
(Specialist FWPTurbCntrlValveClsr (• specialist for FWPTurbCntrlValveClsr) (declare (Superspecialist FWPTurbTrip/LowSpeed) (LoopsSuper NPPSpecialist)) [kgs (tdfpcntrlvalve (• definition of new knowledge group) Table (match (AskHLN? "What is the FWP-A turbine control valve position") (AskHLN? "What is the FWP-B turbine control valve position") with (if N N then -3 elseif L ? then 2 elseif LL ? then 3 elseif ? L then 2 elseif ? LL then 3 else 0] (messages (Establish (* the default Establish message {CASPIAN:LAIR:OHIO-STATE}
set the confidence value to the value of summary, esits active if established, finished if rejected, and suspended otherwise) (SetConfidence self tdfpcntrlvalve))))
(Specialist LowNPSH (• specialist for LowNPSH) (declare (Superspecialist FWPTurbTri p/LowSpeed) (LoopsSuper NPPSpecialist)) [kgs (npsh (• definition of new knowledge group) Table (match (AskHLN? "What is the FWP-A suction pressure”) (AskHLN? "What is the FWP-B suction pressure") with (if (OR N H HH) (OR N H HH) then -3 elseif ? LL then 3 elseif ? L then 2 elseif LL ? then 3 elseif L ? then 2 else 0] (messages (Establish (' the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self npsh))))
(Specialist FWPSuctValveClsr (* specialist for FWPSuctValveClsr) (declare (Superspecialist FWPTurbTrip/LowSpeed) (LoopsSuper NPPSpecialist)) [kgs (suctionvalve (* definition of new knowledge group) Table (match (AskYNU? Is the FWP-A suction valve open") (AskYNU? Is the FWP-B suction valve open") (AskHLN? What is the FWP-A suction flow") (AskHLN? What is the FWP-B suction flow") with (if ? F ? (NOT (OR N H HH)) then elseif ? (NOT (OR N H HH)) then elseif F ? (NOT (OR N H HH)) then elseif ? ? (NOT (OR N H HH)) then elseif ? (NOT (OR N H HH)) then elseif then elseif F ? ? then else 0] (messages (Establish (• the default Establish message set the confidence value to the 176 {CASPIAN: LAI R:OHIO-STATE}
value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self suctionvalve))))
(Specialist HighFWDschPress (• specialist for HighFWDschPress) (declare (Superspecialist FWPTurbTrip/LowSpeed) (LoopsSuper NPPSpecialist)) [kgs (dischargepressure (• The discharge pressure on either FW pump must be 1450psig and increasing in order for the turbine to trip) Table (match (AskHLN? "What is the FWP-A discharge pressure") (AskHLN? "What is the FWP-B discharge pressure") (AskTrend? "What is the FWP-A discharge pressure trend") (AskT rend? "What is the FWP-B discharge pressure trend") with (if 7 (OR H HH) (OR I II) 7 then 3 elseif ? (OR H HH) 7 (OR I II) then 3 elseif N N S S then -3 elseif (OR H HH) ? ? ? then 2 elseif ? (OR H HH) ? ? then 2 else 0] (messages (Establish (• the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self dischargepressure))))
(Specialist LPCS (• specialist for Junk) (declare (Superspecialist LowPressureSystem) (LoopsSuper NPPSpecialist)) [kgs (LPCS (* Check Operating Press) Table (match (AskVNU? "Is the reactor pressure below 300 psia") (AskYNU? "Is LPCS pump running") (AskYNU? "Is LPCS lined up to spray water in the vessel") with (if T T T then 3 else -3] (messages (Establish (SetConfidence self LPCS))))
(Specialist LPCI {CASPIAN:LAIR:OHIO-STATE}
(* specialist for junk) (declare (Superspecialist LowPressureSystem) (LoopsSuper NPPSpecialist)) [kgs (LPCI (* Check Operating Press) Table (match (AskYNU? “Is the reactor pressure below 300 psia") (AskYNU? "Is LPCI pump running") (AskYNU? "Is LPCI lined up to spray water in the vessel") with (if T T T then 3 else -3] (messages (Establish (SetConfidence self LPCI))))
(Specialist HPCS (• specialist for HPCS) (declare (Superspecialist HighPressureSysten) (LoopsSuper NPPSpecialist)) [kgs (HPCS (• Check Operating Press) Table (match (AskYNU? 'Is the reactor pressure below 300 psia") (AskYNU? "Is HPCS pump running") (AskYNU? "Is HPCS linedup to deliver water to RPV") with (if F T T then 3 else -3] (messages (Establish (SetConfidence self HPCS))))
(Specialist RCIC (• specialist for RCIC) (declare (LoopsSuper NPPSpecialist) (Superspecialist HighPressureSystem)) [kgs (press (• definition of new knowledge group) Table (• or RULES) (match (AskYNU? "Is the reactor pressure above 100 psia”) (AskYNU? "Is the RCIC pump running") (• decision knowledge) with (if T T then 3 else -3))) (RCIC (* definition of new knowledge group) Table (• or RULES) (match (AskHLN? "What is the suppression pool temperature") (AskYNU? "Is RCIC lined up to deliver water to the vessel") with (if (OR H HH) T then 3 elseif ? T then 3 elseif (OR H HH) 7 then 2 elseif ? F then -3 else -3] [messages (Establish (if (GE press 0) then (SetConfidence self RCIC) else (SetConfidence self press])
(Specialist LowHotSurgeTank (• specialist for 178 (CASPIAN:LAIR:OHIO-STATE>
LowHotSurgeTank) (declare (Superspecialist FWBPTrip) (LoopsSuper NPPSpecialist)) [kgs (hotsurgetank (* definition of new knowledge group) Table (match (AskHLN? "What is the hot surge tank level") (AskHLN? What is the hot surge tank level controller output") (AskHLN? "What is the FW heater outlet flow— input to HST") (AskHLN? What is the total reactor FW flow") with (if LL ? ? ? then 3 elseif L (OR L LL) (OR L LL) (OR L LL) then 2 elseif ? (OR L LL) (OR L LL) (OR N H HH) then 2 elseif (OR N H HH) ? ? ? then -3 elseif ? (OR N H HH) (OR N H HH) N then -2 else 0] [messages (Establish (* the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self hotsurgetank) ( if [or (•»? self) (or (Eq (ConfidenceValue of self) (QUOTE 2*)) (Eq (ConfidenceValue of self) (QUOTE 3*] then (Exit active) elseif (-? self) then (Exit finished) else (Exit suspended])
(Specialist HighFWBPOschPress (• specialist for HighFWBPDschPress) (declare (Superspecialist FWBPTrip) (LoopsSuper NPPSpecialist)) [kgs (dschpressure (* The booster pumps will trip if the discharge valve closes <90% open. If the discharge valve closes then the discharge pressure will increase.) Table (match (AskHLN? "What is the discharge pressure for the FWBP-A") (AskHLN? "What is the discharge pressure for the FWBP-B") (AskHLN? "What is the discharge pressure for the FWBP-C") (AskHLN? "What is the discharge pressure for the FWBP-D") with (if (OR H HH) (OR H HH) (OR H HH) . (OR H HH) {CASPIAN: LAIR:OHIO-STATE}
then 3 elseif (OR N L LL) (OR N L LL) (OR N L LL) (OR N L LL) then -3 else 0 ] (messages (Establish (* the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self dschpressure))))
(Specialist LowFWBPSuctPress (• specialist for LowFWBPSuctPress) (declare (Superspecialist FWBPTrip) (LoopsSuper NPPSpecialist)) [kgs (lowsuctionpressure (• definition of new knowledge group) Table (match (AskHLN? "What is the suction pressure for the FWBP-A") (AskHLN? "What is the suction pressure for the FWPB-B") (AskHLN? "What is the suction pressure for the FWBP-C") (AskHLN? ’What is the suction pressure for the FWBP-O") with (if (OR L LL) (OR L LL) (OR L LL) (OR L LL) then 3 elseif (OR N H HH) (OR N H HH) (OR N H HH) (OR N H HH) then -3 else 0] (messages (Establish (* the default Establish message set the confidence value to the value of summary, exits active if established, finished if rejected, and suspended otherwise) (SetConfidence self lowsuctionpressure)))) {CASPIAN: LAIR:OHIO-STATE}
(FILECREATED ”20-Jun-87 16:41:44“ {CASPIAN:LAIR:OHIO-STATE}
previous date: "ll-Jun-87 15:20:37“ {CASPIAN:LAIR:OHIO-STATE}
(PRETTYCOMPRINT FUNCTIONSCOMS) (RPAQQ FUNCTIONSCOMS ((CLASSES AuxTanks Containment CSRLCase DoLisp Drywell ECCS FeedWater FUTurbineCV MSIV NPPBrowser NPPValueBrowser Pumps Reactor RecirculationLine Sensors SRV Steam SuppressionPooI Turbine TurbineCV TurbineStopValve ValvesPosition) (FNS AddList AddToList AskHLN? AskTrend? AskUsers? GetAutoSusData GetSusData changeHLNtoHLN ChangelDZtoIDZ CollectSuspData ComparePattern ComparePatterns FindConfidenceValue FindKg FindMember FindSuspSensor FindTipNodeWith* HLN? IDS? Inspectlnstances IsCurrentSpecialistFinished MakeList MakeSpecialistList MakeSuspSensorList NPPSubs NewExplain RPLC ResetNPP Resolve ResolveList ResolveSuspSensorList SetSuspSensorList Substitute TipNode? ValidateSuspSensor) (METHODS AuxTanks.level CSRLCase.AutoValidate CSRLCase.Reset CSRLCase.ResetSusData CSRLCase.StoreSusData ECCS.Alarm FeedWater.FlowRate FeedWater.NewTemp FeedWater.Temperature MSIV.Position NPPBrowser.NPPDiagnose NPPValueBrowser.EditCase NPPValueBrowser.KGROWS NPPValueBrowser.NewValidate NPPValueBrowser.ResetCase NPPValueBrowser.ResetNode NPPValueBrowser.SaveCaseSia NPPValueBrowser.Validate Pumps.Speed Reactor.PowerTrend SRV.Position) (INSTANCES ECCSInjection FeedWaterTemp FWFlowRate FWFlowTrend FWHtrOutFlow FWPumpSpeed FWTempTrend HotSurgeTAnkLevel MSIVOpen RxPower RxPowerTrend RxPressure RxWLTrend SRVOpen SteamFlowRate SteamFlowTrend SuppressionPoolLevel SuppressionPoolTemp SuppressionPoolTempTrend TotalRxFWFlow TurbineElectricOutput) (VARS LOCAjunk ClosedMSIVjunk WINDOW))) (DEFCLASSES AuxTanks Containment CSRLCase DoLisp Drywell ECCS FeedWater FWTurbineCV MSIV NPPBrowser NPPValueBrowser Pumps Reactor RecirculationLine Sensors SRV Steam SuppressionPooI Turbine TurbineCV TurbineStopValve ValvesPosition) [defclass A uxT anks (MetaClass Class Edited: (' edited: "31-Dec-67 21:4S")) (Supers Sensors)]
[defclass Containment (MetaClass Class Edited: (‘ edited: "12-Nov-8609:17")) (Supers Sensors) (InstanceVariables (StringQuery doc (’ IV added by HASHEMI which includes the string for questioning the Data Basel) (SensorType NIL doc (’ IVadded by HASHEMI to include the type of sensor This is used for validation routines.)) (SpecialistUsedThisSensor NIL doc (’ IV added by HASHEMIto hold the names of the specialists that use this sensor))) ]
[defclass CSRLCase (MetaClass MetaCSRLCase doc (' class for cases to be diagnosed by CSRL) Edited: (’ edited “ll-Jun-8714.37") ) (Supers Object) (ClassVariables (CaseNumber 0 doc (’ the last case number used)) (Instances (Case3 Cast) Casl Case5) doc (’ a list of the names of the instances of this class) )) (InstanceVariables (browser NIL doc (’ the CSRL browser which is updated as the case proceeds)) (vtilueBrowser NIL doc (’ the confidence value browser which is updated as the case proceeds)) (specialists NIL doc (’ the list of specialist instances which are associated with this case)) (SusDataList NIL doc (’ list of suspicious data)) (instances NIL doc (’ instances other than specialists which should be saved with this case - should be pointers to instances, not their names)) (StringDB #((from 1 to 47 collect NIL) FirstFetcb NIL) doc (’ an list which associates strings (questions) with the answers provided by the user) ))] [DEFCLASS D oL isp (MetaClass MetaConstruct Edited: (’ edited. "S-FEB-8413 43")) (Supers Statement) (ClassVariables (RawPattern (?command ?lispForm -?bindings-)) (ProcessedPattern ((command VARIABLE) (CASPI AN: LAI R:OHIO-STATE}
(lispForm VARIABLE) (bindings VARIABLE SPLICED)) doc (* Undocumented CV added by) ))] [oefclass D ryw ell (MetaClass Class Edited: (• edited: "12-Nov-86 09:17")) (Supers Sensors) (InstanceVariables (StringQuery "" doc (• IV added by HASHEMI which includes the string for questioning the DataBase)) (SensorType NIL doc (• IV added by HASHEMI to include the type of sensor This is used for validation routines.)) (SpecialistUsedThisSensor NIL doc (• IV added by HASHEMI to hold the names of the specialists that use this sensor))) ]
[DEFCLASS ECCS (MetaClass Class Edited: (• edited: "6-Apr-8708:S2"» (Supers Sensors)]
[defclass F e ed W ate r (MetaClass Class Edited: (• edited: "12-NOV-86 09:17")) (Supers Sensors) (InstanceVariables (StringQuery doc (• IV added by HASHEMI which includes the string for questioning the DataBase)) (SensorType NIL doc (• IV added by HASHEMI to include the type of sensor This is used for validation routines.)) (SpecialistUsedThisSensor NIL doc (• IV added by HASHEMI to hold the names of the specialists that use this sensor))) ]
[oefclass FWTurbineCV (MetaClass Class Edited: (* edited: "13-Jan-8710:34")) (Supers ValvesPosition FeedWater)]
[DEFCLASS MSIV (MetaClass Class Edited: (•edited "12-Nov-86 09:18")) (Supers ValvesPosition) (InstanceVariables (StringQuery "" doc (• IV added by HASHEMI which includes the string for questioning the DataBase)) (SensorType NIL doc (• IV added by HASHEMI to include the type of sensor This is used for validation routines.)) (SpecialistUsedThisSensor NIL doc (• IV added by HASHEMI to hold the names of the specialists that use this sensor)))]
[defclass NPPBrowser (MetaClass Class Edited: (•edited "12-Jul-86 14:21")) (Supers CSRLBrowser) (ClassVariables (LeftButtonltems ((Print (QUOTE CSRLPrint) "Print specialist, declarations, knowledge group, or message") (PPTable (QUOTE CSRLPPTable) "print a table knowledge group in tabular format") (Doc (QUOTE CSRLDoc) "Documentation for specialist or a selected part") (Wherels (QUOTE CSRLWherels) "Find location of method, iv. or cv") (DeleteNode DeleteFromBrowser "Removes specialist from browser -- does not affect the specialist itself") (Unread (QUOTE Unread) "Put class name in typein buffer”) (Diagnose (QUOTE NPPDiagnose) "Diagnose a case with this specialist"))) (LocalCommands (CSRLPrint CSRLPPTable CSRLDoc CSRLWherels NPPDiagnose CSRLAdd CSRLCopy CSRLDelete CSRLEdit CSRLRename CopyTo BoxNode ClassDoc CVDoc DefineSubclass DeleteClassItem EditObject FindWhere FlipNode IVDoc LoadCase MoveTo Recompute RenamePart Unread)))]
[defclass NPPValueBrowser (MetaClass Class Edited: (*edited "S-Jun-87 15:35")) (Supers CSRLValueBrowser) (ClassVariables [LeftButtonltems ((ShowValues (QUOTE MakeValueLattice) "show values of specialist in a lattice") (Wherels (QUOTE Wherels) "Flash the specialist is in the superbrowser") 182 {CASPIAN:LAIR:OHIO-STATE}
(PPInstance (QUOTE PPInstance) "Print the specialist instance") (Validate (QUOTE NewValidate) "Goes through the validation routines") (ResetNode (QUOTE ResetNode) (" Resets only a specific node’] (MiddleButtonltems ((ShowValues (QUOTE MakeValueLattice) "show values of specialist in a lattice") (Wherels (QUOTE Wherels) "Flash the specialist is in the superbrowser") (PPInstance (QUOTE PPInstance) "Print the specialist instance") (Validate (QUOTE NewValidate) "Goes through the validation routines") (ResetNode (QUOTE ResetNode) " Resets only a specific node"))) (TitleH.ems ((EditCase (QUOTE EditCase) "Edit the currentCase data") (Recompute (Recompute ((Recompute Recompute "Recompute lattice for the current case") (InPlace RecomputelnPlace "Recompute keeping current view in window") (ShapeToHold ShapeToHold "Make window large or small enough to just hold graph") (SelectFont SelectFont "Select a new font for the browser”) (Lattice/Tree ChangeFormat "Change format between lattice and tree"))) "Recompute lattice for the current case") (Reset (QUOTE ResetCase) "Resets the currentCase") (SaveCase (QUOTE SaveCaseSia) "Make a file with case in it") (SavelnIT (QUOTE SavelnIT) ”IT«- [DEFCLASS PumpS (MetaClass Class Edited: (’ edited: "If-Jun-8714:S3")) (Supers Sensors)] [defclass R eactor (MetaClass Class Edited: (’ edited: “12-Nov-8609:16“)) (Supers Sensors) (InstanceVariables (StringQuery "" doc (’ IV added by HASHEMI which includes the string for questioning the DataBase)) (SensorType NIL doc (’ IV added by HASHEMI to include the type of sensor. This is used for validation routines.)) (SpecialistUsedThisSensor NIL doc (’ IV added by HASHEMI to hold the names of the specialists that use this sensor))) ] [defclass RecirculationLine (MetaClass Class Edited: (* edited: "17-Nov-8611:23")) (Supers Sensors)] [defclass S ensors (MetaClass Class Edited: (• edited: "12-Nov-8609:14")) (Supers Object) (InstanceVariables (StringQuery "" doc (• IV added by HASHEMI which includes the string for questioning the DataBase)) (SensorType NIL doc (• IV added by HASHEMI to include the type of sensor. This is used for validation routines.)) (SpecialistUsedThisSensor NIL doc (’ IV added by HASHEMI to hold the names of the specialists that use this sensor))) ] [DEFCLASS SRV {CASPIAN: LAIR :OHIO-STATE} (MetaClass Class Edited: (•edited "17-Nov-86 11:22“)) (Supers ValvesPosition)] [Defclass S te am (MetaClass Class Edited: (• edited: “!2-Nov-86 09:16")) (Supers Sensors) (InstanceVariables (StringQuery doc (• IV added by HASHEMI which includes the string for questioning the DataBase)) (SensorType NIL doc (• IV added by HASHEMI to include the type of sensor. This is used for validation routines.)) (Special istUsedThisSensor NIL doc (• IV added by HASHEMI to hold the names of the specialists that use this sensor))) ] [defclass SuppressionPool (HetaClass Class Edited: (•edited: “13Jan-8710:33")) (Supers Sensors)] [defclass T u rb in e (MetaClass Class Edited: (• edited: "8-1an-87 10:32")) (Supers Sensors)] [defclass T urbineC V (MetaClass Class Edited: (• edited: "8-Jan-87 10:33")) (Supers Turbine ValvesPosition) (InstanceVariables (StringQuery doc (• IV added by HASHEMI which includes the string for questioning the DataBase)) (SensorType NIL doc (• IV added by HASHEMI to include the type of sensor This is used for validation routines.)) (SpecialistUsedThisSensor NIL doc (• tv added by HASHEMI to hold the namesofthe specialists that use this sensor)))] [defclass TurbineStopValve (MetaClass Class Edited: (•edited "8-Jan-87 10:33")) (Supers Turbine ValvesPosition) (InstanceVariables (StringQuery doc (• IV added by HASHEMI which includes the string for questioning the DataBase)) (SensorType NIL doc (• IV added by HASHEMI to include the type of sensor This is used for validation routines)) (Special istUsedThi sSensor NIL doc (• IV added by HASHEMI to hold the namesofthe specialists that use this sensor))) ] [defclass ValvesPosition (MetaClass Class Edited: (’ edited “12Nov-8609 IS”)) (Supers Sensors) (InstanceVariables (StringQuery doc (• IV added by HASHEMI which includes the string for questioning the DataBase)) (SensorType NIL doc (• IV added by HASHEMI to include the type of sensor This is used for validation routines.)) (Special istUsedThi sSensor NIL doc (• IV added by HASHEMI to hold the names of the specialists that use this sensor))) ] (DEFINEQ (A ddL ist [LAMBDA (element) (* edited: "!9 Feb-8713:32") (for sensors in (CDR element) do (if (NOT (MEMB sensors SuspSensors)) then (MakeList sensors]) (A ddT oL ist [LAMBDA (element) (• edited: "20-)un-8716:12") (for elements in element do (if (NOT (MEMB elements SuspSensors)) then (MakeList elements]) (AskHLN? [LAMBDA (question) (• edited: "20 Jun-8716:24") («- currentCase Ask question (QUOTE HLN?) (QUOTE changeHLNtoHLN) (QUOTE (printout T T "Answer H for High HH for very High” "L for Low,” "LL for very Low" "N for Normal, or" "U for Unknown" T T]) (A skT rend? [LAMBDA (question) (•edited "tSSEP-85 16:02") (•- currentCase Ask question (QUOTE IDS?) {CASPIAN: LAIR :OHIO-STATE} (QUOTE ChangelDZtoIDZ) (QUOTE (printout T T 'Answer I for Increasing. II for rapidly Increasing. S for Steady. 0 for Decreasing, DD for rapiDly g. and U for Unknown" T T]) (AskUsers? [LAMBDA (ValidationList) (• edited: "10-Nov-8615:36") (if ValidationList then (for elem in ValidationList do [if (Explain elem) then (PRIN1 "The answer to the question of:') (PRINT (EVAL (CAR elem))) (PRIN1 • was changed from ') (PRINT (CADR elem)) (PRIN1 ■ to *) (PRINT Newlnp) else (PRIN1 "Your answer to the question of: ") (PRINT (EVAL (CAR elem))) (PRIN1 was: ') (PRINT (CADR elem)) (PRIN1 " but I expected: ") (PRINT (CADDR elem)) (PRIN1 "I have done all that I could have! It's your turn now!!!") (SETQ Newlnp (FindMember)) (if Newlnp then (SETQ Newlnp Newlnp) else (SETQ Newlnp (CADAR ValidationList] (NPPSubs (EVAL (CAR elem)) Newlnp)) (- currentCase ResetSusData) («- currentCase Reset) (- [$! (PACK (APPEND (UNPACK (QUOTE CoolSysFault)) (CDDR (UNPACK currentCase] RunMessage (QUOTE Establish-refine) (QUOTE CoolSysFault) NIL "The Validator") else NIL]) (GetAutoSusData [LAMBDA (NodeName) ('edited "19Feb-8711:57") (for SuspSpecialist in (GetValue currentCase (QUOTE SusDataList)) do (if (EQ NodeName (CAR SuspSpecialist)) then (CollectSuspData SuspSpecial ist)) finally (RETURN SuspiciousData]) (GetSusData [LAMBDA (obj) (’ edited: "6-Apr-87 10:19") (for SuspSpecialist in (GetValue currentCase (QUOTE SusDataList)) do (if (EQ obj (CAR SuspSpecialist)) then (CollectSuspData SuspSpecialist)) finally (RETURN SuspiciousData]) (changeHLNtoHLN [LAMBDA (x) ('edited: “20-Jun-8716:24") (SELECTQ x ((H h) (QUOTE H)) < <(D d) (QUOTE D)) ((S S) (QUOTE S)) ((II ii Ii il) (QUOTE II)) ((00 dd Dd dD) (QUOTE DD)) (QUOTE U]) (CollectSuspData [LAMBDA (SuspSpecialist) (‘ edited "12-Feb-8710:42") (if (EQ SuspiciousData NIL) then (SETQ SuspiciousData (LIST (CDR SuspSpecialist))) else (SETQ SuspiciousData (APPEND SuspiciousData (LIST (CDR SuspSpecialist]) (ComparePattern [LAMBDA (KGS EXP) (*edited. "19-Feb-8713:11") (SETQ KgName (CAR KGS)) (SETQ ExpKg (FindKg KgName EXP)) (for elem in ExpKg do (if (ComparePatterns elem KGS 0) then (SetSuspSensorList (ComparePatterns elem KGS 0))) finally (RETURN SuspSensorList]) (ComparePatterns [LAMBDA (elem KGS number) (‘ edited "19-Feb-8711:21") (for kgline in (CDR KGS) do ((SETQ number (PLUS number 1)) (if (MEMB (CADDR kgline) (CAR (NTH elem number))) then NIL else (RETURN NIL))) finally (RETURN (CAR (LAST elem]) (FindConfidenceValue [LAMBDA (specialist) (‘edited "ISJun-8708 47") (GetValue specialist (QUOTE confidenceValue]) (FindKg [LAMBDA (KgName EXP) (‘edited "12Feb-8711:06") (‘ Find the KG with Suspicious data in it) (for expect in EXP do (if (EQ (CAR expect) KgName) then (RETURN (CADR expect]) (FindMember [LAMBDA NIL ('edited: “8-Jan-8711:06") (while T do (PRIN1 "varify and input the new value (Uppercase please) ”) (TERPRI) (SETQ Newln (READ)) (if (MEMBER Newln (QUOTE (T F Y N U I II L LL H HH D DD S NIL))) then (RETURN Newln]) (FindSuspSensor [LAMBDA (SusData EXP) (‘edited. "11-Jun-8714:49") (MakeSuspSensorList SusData EXP) (if SuspSensorList then (ResolveSuspSensorList SuspSensorList) (ValidateSuspSensor SuspSensors]) (FindTipNodeWith* [LAMBDA NIL (‘ edited: "22-DecB6 10:52") (‘ Find the FIRST tipnode with a ‘ in it's Value) (for specialist in (GetValue currentCase (QUOTE specialists)) do (if (TipNode? specialist) then (if (EQ [CADR (UNPACK (GetValue specialist (QUOTE confidenceValue] (QUOTE *)) then (RETURN specialist))) finally (RETURN NIL]) (HLN? [LAMBDA (x) (‘edited: “20-Jun-8716:21") (if (MEMB x 186 { C A S P I A N : LAI R: OH 10 —STATE> (QUOTE (H h hh HH hH Hh L 1 LL 11 LI 11. U u N n))) then T else NIL]) (IDS? [ LAMBDA (*) (* edited: " 2-JUL-8S 11:44 ") (if (MEMB * (QUOTE (II ii i l l i S s u U d D DD dd Dd dD))) then T else NIL]) (Inspectlnstances [LAMBDA NIL ( 'edited "29-Jan-8709:25") (for instance in (CDR (CADDDR FUNCTIONSCOMS)) do (<- ($! instance) Inspect]) (IsCurrentSpecialistFinished [LAMBDA NIL (•edited: "26-Nov-86 13:53") (• asks user if currentSpecialist has finished processing) (PROG ((question (CONCAT "Has ■ currentSpecialist completed diagnosis"))) (RETURN (AskYNU? question]) (MakeList [LAMBDA (element) (•edited: "19-Feb-8711:29") (if (EQ SuspSensors NIL) then (SETQ SuspSensors (LIST element)) else (SETQ SuspSensors (APPEND SuspSensors (LIST element]) (MakeSpecialistList [LAMBDA (elems) (•edited: "31Dec-6719:31") (SETQ SpecialistList NIL) (for specialist in (GetValue (EVAL elems) (QUOTE Special istUsedThisSensor)) do [if [EQ (QUOTE *) (CADR (UNPACK (GetConfidenceValue specialist] then [if (NULL Special is tL is t) then (SETQ Speci al istList (LIST specialist)) else (SETQ Special i stList (APPEND Special istL ist (LIST specialist] else (if (NULL SpecList) then (SETQ SpecList (LIST specialist)) else (SETQ SpecList (APPEND SpecList (LIST specialist] finally (RETURN Special istL ist]) (MakeSuspSensorList [LAMBDA (SusData EXP) (•edited: "6-Apr-87 08:51") (for KGS in SusData do (ComparePattern KGS EXP]) (NPPSubs [LAMBDA (strl Newlnp) (•edited: "6-0ct-86 10:37") (Substitute s t r l (GetValue currentCase (QUOTE stringDB) NIL) Newlnp]) (NewExplain [LAMBDA (elem) (• edited: "20-Jun-8716:33") (SETQ Newlnp (►! (EVAL elem) (GetValue (EVAL elem) (QUOTE SensorType]) (RPLC [LAMBDA (JJ Value) (• edited: "22-Dec-86 11:38") (NPPSubs (GetValue (EVAL JJ) (QUOTE StringQuery)) Value]) (R esetN PP [LAMBDA (case) (•edited: "S-Nov-86 14:22") (SETQ case ($! case)) (•edited: "1S-SEP-85 17:47") (for specialist in (GetValue case (QUOTE specialists)) do ((*- specialist DeletelV (QUOTE state)) (♦• specialist DeletelV (QUOTE confidenceValue)) («- specialist DeletelV (QUOTE messagesReceived)) {CASPIAN:LAIR:OHIO-STATE} (for kg in (*• specialist List (QUOTE Kgs)) do (PutValue specialist kg (QUOTE UnSetKnowledgeGroup]) (R esolve [LAMBDA (elements) (•edited: “20-Jun-8715:25”) (SETQ COUNT 0) (for specialists in (GetValue (EVAL elements) (QUOTE SpecialistUsedThisSensor)) do (if (EQ [CADR (UNPACK (GetValue [EVAL (PACK (APPEND (CDR (UNPACK (EVAL specialists))) (CODR (UNPACK currentCase] (QUOTE confidenceValue] (QUOTE *)) then (SETQ COUNT (PLUS COUNT 1))) finally (RETURN COUNT]) (Resol veList [LAMBDA (element) (’ edited. "20Jun-8716:12”) (for elements in (CDR element) do (Resolve elements) (if (GREATERP COUNT 1) then (RETURN (LIST elements))) finally (RETURN (CDR element]) (ResolveSuspSensorList [LAMBDA (SuspSensorList) (' edited: ”20-Jun-8715:54") (SETQ SuspSensors NIL) (for element in SuspSensorList do (if (ATOM element) then (MakeList element) elseif (EQ (CAR element) (QUOTE A)) then (AddList element) elseif (ResolveList element) then (AddToList (ResolveList element))) finally (RETURN SuspSensors]) (SetSuspSensorList [LAMBDA (SuspSensors) (•edited "13Feb-8710.06”) (if (NOT SuspSensorList) then (SETQ SuspSensorList (LIST SuspSensors)) else (SETQ SuspSensorList (APPEND SuspSensorList (LIST SuspSensors]) (Substitute [LAMBDA (JJ Str2 Newlnp) C edited "23-Jui-86 10:48") (for sh in s tr 2 do (if sh then (if [for pairs in sh do (if (STRING-EQUAL (CAR pairs) JJ) then (RETURN (RPLACD pairs Newlnp] then (RETURN T))) finally (RETURN NIL]) (T ipN ode? [LAMBDA (specialist) (* edited: "7-Nov-86 12:10") (PROG (strl str2) [SETQ strl (PACK (CDDR (UNPACK currentCase] (SETQ str2 specialist) (if (GetClassValue [SI (PACK (CDDR (UNPACK (MKATOM (SUBSTRING Str2 1 (DIFFERENCE (STRPOS strl Str2) 1] (QUOTE Subspecialists)) then (RETURN NIL) else (RETURN (QUOTE T]) (ValidateSuspSensor [LAMBDA (SuspSensors) (’ edited. "20-Jun-87 16:15") (for elems in SuspSensors do (if (NewExplain elems) then (TTYDISPLAYSTREAM WINDOW) {CASPIAN:LAIR:OHIO-STATE} (printout NIL .FONT BOLDFONT 5 "The answer to the question of: ") (PRINT (GetValue (EVAL elems) (QUOTE StringQuery))) (printout NIL .FONT BOLDFONT 5 " was changed from ") [PRINT (AskHLN? (GetValue (EVAL elems) (QUOTE StringQuery] (printout NIL .FONT BOLDFONT 5 * To ") (PRINT Newlnp) (TTYDISPLAYSTREAM TTY) else (MakeSpecialistList elems) (TTYDISPLAYSTREAM WINDOW) (TERPRI) (TERPRI) (TERPRI) (printout NIL .FONT BOLDFONT 5 "Your answer to the question of: ") (TERPRI) (PRINT (GetValue (EVAL elems) (QUOTE StringQuery))) (printout NIL .FONT BOLDFONT 20 " was ") [PRINT (AskHLN? (GetValue (EVAL elems) (QUOTE StringQuery] (printout NIL .FONT BOLDFONT 10 ” Which I suspect is wrong ") (TERPRI) (if (NOT (NULL Special istL ist)) then (printout NIL .FONT BOLDFONT 5 "The following specialists (which have used this sensor value)") (TERPRI) (printout NIL .FONT BOLDFONT 5 " have *’s in their confidence values:") (PRIN1 " ") (PRINT SpecialistList) (TERPRI)) (if (NOT (NULL SpecList)) then (printout NIL .FONT BOLDFONT 5 "And the following specialists ") (printout NIL .FONT BOLDFONT 5 "do not have *'s in their confidence values:") (PRIN1 " ") (PRINT SpecList)) (printout NIL .FONT BOLDFONT 5 "I have done all that I could have! It's your turn now!!!") (TERPRI) (SETQ Newlnp (FindMember)) (SETQ Newlnp Newlnp; (TTYDISPLAYSTREAM TTY)) (NPPSubs (GetValue (EVAL elems) (QUOTE StringQuery)) Newlnp)) (if (EQ Validate (QUOTE N)) then (*■ currentCase Reset) (*■ currentCase ResetSusData) (- [S! (PACK (APPEND (UNPACK (QUOTE CoolSysFault)) (UNPACK (GetObjectName currentCase] RunMessage (QUOTE Establish-refine) (QUOTE CoolSysFault) NIL "the validator" )) (while (AND (EQ Validate (QUOTE Y)) (FindTipNodeWrth*)) do ((«- currentCase Reset) (*• currentCase ResetSusData) (- [S! (PACK (APPEND (UNPACK (QUOTE CoolSysFault)) (UNPACK (GetObjectName currentCase] RunMessage (QUOTE Establish-refine) (QUOTE CoolSysFault) NIL "the validator") («- currentCase AutoVal id a te ))) (* edited: "31-Dec-6719:19") ]) [METH AuxTanks level NIL (* New method template)] [ meth csRLCase AutoValidate NIL 189 {CASPIAN: LA I R : OH IO-STATE} (* New method template to start validation routine. This is done by accounting for suspicious data for the tip nodes with • only. Usually, the first tip node with • encountered is first [METH CSRLCase Reset NIL (• New method template)] [meth CSRLCase ResetSusData NIL (* New method template)] [meth CSRLCase S to reS u sD ata (SPECIALIST KGName C aseN o) (* New method template)] [METH ECCS A larm NIL (• New method template)] [METH FeedWater Flow R ate NIL (• New method template)] [METH FeedWater NewTemp NIL (• New method template)] [meth FeedWater Temperature NIL (* New method template)] [METH MSIV Position NIL (• New method template)] [meth NPPBrowser NPPDiagnose(obj objName) (• New method template)] [Meth NPPVai ueBrowser EditCase (obj objName) (• New method template)] [METH NPPVai ueBrowser KGROWS NIL (• New method template)] [meth NPPVai ueBrowser NewValidate (obj objName) (• New method template)] [METH NPPVai ueBrowser ResetCase NIL (• New method template)] [meth NPPVai ueBrowser ResetNode (obj objName) (* New method template)] [meth NPPVai ueBrowser SaveCaseSia (obj objName) (• save the case in a file)] [meth NPPVaiueBrowser Validate (obj objName) (* New method template to start validation routine)] [meth Pumps S p ee d NIL (* New method template)] [METH Reactor PowerTrend NIL (* New method template)] {CASPIAN:LAIR:OHIO-STATE} [METH SRV Position NIL (* New method template)] (DEFINEQ (AuxTanks.level (Method ((AuxTanks level) self) (“ edited. '31-Dec-6722:39") (’ New method template) (if (OR [AND (EQ [AskHLN? (GetValue ($ TotalRxFWFlow) ((QUOTE StringQuery] ((QUOTE LL))) (EQ [AskHLN? (GetValue (S FWHtrOutFlow) ((QUOTE StringQuery] ((QUOTE HH] [AND [OR (EQ [AskHLN? (GetValue ($ TotalRxFWFlow) ((QUOTE StringQuery] ((QUOTE L))) (EQ [AskHLN? (GetValue (S TotalRxFWFlow) ((QUOTE StringQuery] ((QUOTE LL] (OR (EQ [AskHLN? (GetValue (S FWHtrOutFlow) ((QUOTE StringQuery] ((QUOTE N))) (EQ [AskHLN? (GetValue (S FWHtrOutFlow) ((QUOTE StringQuery] ((QUOTE H))) (EQ [AskHLN? (GetValue ($ FWHtrOutFlow) ((QUOTE StringQuery] ((QUOTE HH] then ((QUOTE HH)) else N)))) (CSRLCase.AutoValidate [Method ((CSRLCase AutoValidate) self) (’ edited "31-Dec-6719.17") (‘ New method template to start validation routine This is done by accounting for suspicious data for the tip nodes with ’ only Usually, the first tip node with ’ encountered is first) (SETQ WINDOW (CREATEW NIL (QUOTE Suspicious-Sensors-Window) NIL NIL)) [PROG (strl str2) (SETQ SuspSensorList NIL) (SETQ SuspiciousData NIL) [SETQ strl (PACK (CDDR (UNPACK currentCase] (SETQ str2 (FindTipNodeWith* NIL)) (SETQ NodeName ($! (PACK (CDDR (UNPACK (MKATOM (SUBSTRING s tr 2 1 (DIFFERENCE (STRPOS strl Str2) 1] (PROG (SusData EXP) (SETQ SusData (GetAutoSusData NodeName) (’ suspicious data list) ) (SETQ EXP (GetValue NodeName (QUOTE FiredKgRow)) (' List of expectations) ) (if SusData then (PRIN1 "Validator is activated to account for suspicious data") ( PRIN1 ” ”) (FindSuspSensor SusData EXP) else (RETURN NIL]) (CSRLCase.Reset (Method ((CSRLCase Reset) self) (* edited. " 6-Oct-86 1.23 ") 191 {CASPIAN:LAIR:OHIO-STATE} (' New method template) (ResetNPP currentCase))) (CSRLCase.ResetSusData (Method ((CSRLCase ResetSusData) self) (* edited: "2-Oct-8614.22") (* New method template) (-0 SusDataList NIL))) (CSRLCase.StoreSusData [Method ((CSRLCase StoreSusData) self SPECIALIST KGName CaseNo) ( ' edited: "20-Jun-8714:54") (* New method template) [SETQ Instance (PACK (APPEND (UNPACK SPECIALIST) (CDDR (UNPACK CaseNo] (if (NOT (8 SusDataList)) then [«-0 SusDataList (LIST (APPEND (LIST ($! SPECIALIST) KGName) (GetValue (S'. Instance) KGName (QUOTE explanation] else (<-Q SusDataList (APPEND (0 SusDataList) (LIST (APPEND (LIST ($! SPECIALIST) KGName) (GetValue ($! Instance) KGName (QUOTE explanation]) (ECCS. Alarm (Method ((ECCS Alarm) self) ("edited' "6-Apr-8710 25") (’ New method template) (if (AND (EQ (AskYNU? "Is HPCS linedup to deliver water to RPV") T) (EQ (AskYNU? "Is HPCS pump running") T)) then T else NIL))) (FeedWater.FlowRate (Method ((FeedWater FlowRate) self) (' edited "6-Oct-8609 43") (‘ New method template) self)) (FeedWater.NewTemp [Method ((FeedWater NewTemp) self) (' edited: "8-Jan-8710:27") (* New method template) (if [NULL (if (EQ (AskYNU? "Are the feedwater heaters working normally") (QUOTE F)) then (QUOTE L) else (if (EQ (AskYNU? "Are the feedwater heaters working normally") (QUOTE T)) then (QUOTE N) else (i? (AND (for x in (QUOTE (H HH N)) do (if (EQ (AskHLN? "What is thetemperature of the shell side of the FW heaters") «) then (RETURN T)) finally (RETURN NIL)) (for x in (QUOTE (H HH N)) do (if (EQ (AskHLN? "What is the flow rate on the shell side of the FW heaters") x) then (RETURN T)) finally (RETURN NIL))) then (QUOTE N) else (if (OR (EQ (AskHLN? 192 {CASPIAN:LAIR:OHIO-STATE} "What is the temperature of the shell side of the FW heaters") (QUOTE U)) (EQ (AskHLN? "What is the flow rate on the shell side of the FW heaters") (QUOTE U))) then NIL else (QUOTE LJ then (if (OR (EQ (CAR (UNPACK (GetConfidenceValue ($ LossOfFWHtr))) 2 )) (EQ [CAR (UNPACK (GetConfidenceValue (S LossOfFWHtr] 3)) then (QUOTE L)) else (if (EQ (AskYNU? "Are the feedwater heaters working normally") (QUOTE F)) then (QUOTE L) else (if (EQ (AskYNU? "Are the feedwater heaters working normally") (QUOTE T)) then (QUOTE N) else (if (AND (for x in (QUOTE (H HH N)) do (if (EQ (AskHLN? "What is the temperature of the shell side of the FW heaters") *) then (RETURN T)) finally (RETURN NIL)) (for x in (QUOTE (H HH N)) do (if (EQ (AskHLN? “What is the flow rate on the shell side of the FW heaters”) «) then (RETURN T)) finally (RETURN NIL))) then (QUOTE N) else (if (OR (EQ (AskHLN? "What is the temperature of the shell side of the FW heaters”) (QUOTE U)) (EQ (AskHLN? "What is the flow rate on the shell side of the FW heaters”) (QUOTE U))) then NIL else (QUOTE L]) (FeedWater.Temperatu re [Method ((Feedwater Temperature) self) ("edited. " 81an-8710:27") (* New method template) (if (EQ (AskYNU? "Are the feedwater heaters working normally") (QUOTE F)) then (QUOTE L) else (if (EQ (AskYNU? "Are the feedwater heaters working normally") (QUOTE T)) then (QUOTE N) else (if (AND (for x in (QUOTE (H HH N)) do (if (EQ (AskHLN? "What is the temperature of the shell side of the FW heaters") *) then (RETURN T)) finally (RETURN NIL)) (for x in (QUOTE (H HH N)) do (if (EQ (AskHLN? "What is the flow rate on the shell side of the FW heaters") *) then (RETURN T)) finally (RETURN NIL))) then (QUOTE N) else (if (OR (EQ (AskHLN? "What is the temperature of the shell side of the FW heaters") (QUOTE U)) (EQ (AskHLN? "What is the flow rate on the shell side of the FW heaters") (QUOTE U))) then NIL else (QUOTE L]) (MSI V.Position (Method ( (MSIV Position) {CASPIAN: LAIR :OHIO-STATE} self) (' edited: “29-Jan-8711:21") (* New method template) (if [AND (OR (EQ (AskHLN? (GetValue (S RxPressure) (QUOTE StringQuery))) (QUOTE H)) (EQ (AskHLN? (GetValue (S RxPressure) (QUOTE StringQuery))) (QUOTE HH))) (OR (EQ (AskHLN? (GetValue (S SteamFlowRate) (QUOTE StringQuery))) (QUOTE L)) (EQ (AskHLN? (GetValue (S SteamFlowRate) (QUOTE StringQuery))) (QUOTE LL] then (QUOTE F) else T))) (NPPBrowser.NPPDiagnose [Method ((NPPBrowser NPPDiagnose) self obj objName) ('NY“31-Dec-0020:28") (• New method template) (PROG (newOrOld case message valueBrowser specialist) [SETQ newOrOld (MENU (create MENU ITEMS *- (QUOTE (("current case?" (QUOTE current)) ("new case?" (QUOTE new)) ("old case?" (QUOTE old] (if (NULL newOrOld) then (RETURN NIL)) (SELECTQ newOrOld (old [SETQ case (MENU (create MENU ITEMS •- (for oldCase in (00 ($ CSRLCase) Instances) when (SI oldCase) collect oldCase] (if (NULL case) then (RETURN NIL)) (SETQ currentCase ($1 case))) [new (SETQ currentCase (" csrlCaseClass New (PromptRead "Enter name of new case"] NIL) (PrintStatus "Case is " (GetObjectName currentCase)) (•• currentCase ResetSusData) [SETQ message (MENU (create MENU ITEMS <- (QUOTE (Establ ish-ref ine Establish Refine] (if (NULL message) then (RETURN NIL)) [SETQ Validate (MENU (create MENU ITEMS •- (QUOTE (("Automatic Validation" (QUOTE Y)) ("Manual Validation" (QUOTE N] (if (NULL Validate) then (RETURN NIL)) (-0 currentCase browser self) (if (NULL (0 currentCase valueBrowser)) then (SETQ valueBrowser (*■ (S NPPVai ueBrowser) New)) (-0 valueBrowser case currentCase) ("0 valueBrowser superBrowser s e lf) ("0 currentCase valueBrowser valueBrowser) (AddValue self (QUOTE subBrowsers) val ueBrowser)) (SETQ specialist («- obj Findlnstance)) (*■ specialist RunMessage message objName NIL "the user") (if (EQ Validate (QUOTE Y)) then (► currentCase AutoVal idate]) {CASPIAN:LAIR:OHIO-STATE} (NPPValueBrowser.EditCase (Method ( (NPPValueBrowser EditCase) self obj objName) (’ edited- “S-Jun-8715:15") (’ New method template) («- currentCase Edit))) (NPPValueBrowser.KGROWS (Method ((NPPValueBrowser KGROWS) (- (S LossOfFWHtr) UnParse (QUOTE Kg) (QUOTE Reactor))) (’ edited: "19-Dec-8611:57") (’ New method template) )) (NPPValueBrowser.NewValidate [Method ((NPPValueBrowser NewValidate) self obj objName) (’edited: "31-Dec-6720:06") (’ New method template) (SETQ SuspiciousData NIL) (SETQ SpecList NIL) (SETQ SuspSensorList NIL) (PROG (SusData EXP) (SETQ SusData (GetSusData obj) (’ suspicious data list) ) (SETQ EXP (GetValue obj (QUOTE FiredKgRow))) (H SusData then (if (WINDOWP WINDOW) then (CLEARW WINDOW) else (SETQ WINOOW (CREATEW NIL (QUOTE Suspicious-Sensors-Window) NIL NIL))) (FindSuspSensor SusData EXP) else (RETURN NIL]) (NPPValueBrowser.ResetCase (Method ((NPPValueBrowser ResetCase) self) (’ edited “31 -Dec-6719.45“) (’ New method template) (ResetNPP currentCase) (CLOSEW WINDOW))) (NPPVai ueBrowser. ResetNode [Method ((NPPValueBrowser ResetNode) self obj objName) (’ edited “4-Aug-86 14.35") [SETQ ob ($; (PACK (APPEND (CDDR (UNPACK obj)) (CDDR (UNPACK currentCase] (’ edited “4-Aug-86l2 00") (’ New method template) (- obDeletelV (QUOTE state)) (*• obDeletelV (QUOTE confidenceValue)) (•- ob DeletelV (QUOTE messagesReceived)) (for kg in (•- ob List (QUOTE Kgs)) do (PutValue ob kg (QUOTE UnSetKnowledgeGroup]) (NPPValueBrowser.SaveCaseSia [Method ((NPPValueBrowser SaveCaseSia) self obj objName) (’ edited: “5-Nov-8616:15") (’ save the case in a file) (PROG (case specialists browser valueBrowser caseFile) (SETQ case (8 case)) (RESETLST [if [NOT (MEMB (U-CASE (PromptRead "Do you want to save the specialist instances?")) (QUOTE (Y YES T] then (RESETSAVE (‘0 case special ists NIL) (LIST (QUOTE PutValue) case (QUOTE specialists) (0 case specialists] (RESETSAVE (-0 case browser NIL) (LIST (QUOTE PutValue) case 195 {CASPIAN:LAIR:OHIO-STATE} (QUOTE browser) (0 case browser))) (RESETSAVE (-0 case valueBrowser NIL) (LIST (QUOTE PutValue) case (QUOTE valueBrowser) (0 case valueBrowser))) (SETQ caseFile (U-CASE (GetObjectName case))) (ADDTOFILE (GetObjectName case) (QUOTE INSTANCES) caseFile) (MAKEFILE caseFile]) (NPPValueBrowser.Validate [Method ((NPPValueBrowser Validate) self obj objName) (' edited: "12-Feb-8710:21") (' New method template to start validation routine) (SETQ SuspSensorList NIL) (PROG (SusData EXP) (SETQ SusData (GetValue currentCase .(QUOTE SusDataList)) (* suspicious data list) ) (SETQ EXP (GetValue obj (QUOTE FiredKgRow))) (if SusData then (FindSuspSensor SusData EXP) else (RETURN NIL]) (Pumps.Speed [Method ((Pumps Speed) self) (' edited: "20-Jun-8716:33") (' New method template) (if (AND (EQ (AskHLN? “What is the feedwater pump discharge pressure") (QUOTE N)) (EQ (AskHLN? "What is the feedwater pump suction pressure") (QUOTE N))) then (QUOTE N) else (RETURN (QUOTE L]) (Reactor.PowerTrend (Method ((Reactor PowerTrend) self) ('edited "13-Oct-86 11 39") (' New method template) NIL)) (SRV.Position (Method ((SRV Position) self) ('edited "5-Jun-8715:47") (* New method template) (if [AND (EQ (AskYNU? "Is the suppression pool temperature uniform") (QUOTE F)) (OR (EQ (AskHLN? "What is the SRV downcomer pressure") (QUOTE HH)) (EQ (AskHLN? "What is the SRV downcomer pressure") (QUOTE H] then T else (QUOTE F)))) [DEFINST ECCS (ECCSInjection "AFW0.GQa:.7R7.78") (StringQuery "Are there alarms indicating ECCS initiation") (SensorType Alarm) (SpecialistUsedThisSensor (SHighlnventory))] [DEFINST Feedwater (FeedWaterTemp "NLV0.GQa..A48.2") (StringQuery "What is the feedwater temperature") (SensorType Temperature) (SpecialistUsedThisSensor (ColdWaterAcc LossOfFWHtr Rx-OverPower))] [DEFINST Feedwater (FWFIowRate "NLV0.GQa:.A48.3") (StringQuery "What is the feedwater flow rate") (SensorType Flow) (SpecialistUsedThisSensor (FWControllerFaiILow))] {CASPIAN:LAIR:OHIO-STATE} [DEFINST Feedwater (FWFIowTrend "NLV0.GQa:.A48.4") (StringQuery "What is the feedwater flow trend") (SensorType FlowTrend) (SpecialistUsedThisSensor NIL)] [DEFINST Feedwater (FWHtrOutFlow "D«-CO.f [ d e f in s t Pumps (FWPumpSpeed "UKW 0.1j[:.0><.7") (StringQuery "What is the feedwater pumps speed" StringQuery "What is the feedwater pumps speed") (SensorType Speed) (SpecialistUsedThisSensor (JHighlnventory SECCS&FWCErr SLowInventory))] [De f in s t Feedwater (FWTempTrend "NLV0.GQa:.A48.5") (StringQuery "What is the feedwater temperature trend") (SensorType TemperatureTrend) (SpecialistUsedThisSensor NIL)] [De f in s t AuxTanks (HotSurgeTAnkLevel "D«-C0.[ [DEFINST HSlv(MSIVOpen "J]W0.GQa:.6j7.1") (StringQuery "Are the MSIVs open") (SensorType Position) (SpecialistUsedThisSensor ClosedMSIVs)] [DEFINST Reactor (RxPower "JHW0.[ [De f in s t Reactor (RxPowerTrend "NLV0.GQa:.A48.6") (StringQuery "What is the reactor power level trend”) (SensorType PowerTrend) (SpecialistUsedThisSensor NIL)] [De f in s t Reactor (RxPressure ”J]W0.GQa:.6j7.2") (StringQuery "What is the reactor pressure")] [ d e f in s t R e a c to r (RxWLTrend "NLV0.GQa:.A48.7") (StringQuery "What is the reactor water level trend") (SensorType WaterLevelTrend) (SpecialistUsedThisSensor NIL)] [DEFINST SRv(SRVOpen "JZW0.GQa:.fS9.73") (StringQuery "Are there any SRVs open") (SensorType Position) (SpecialistUsedThisSensor (LOCA ReliefValveOpen ClosedMSIVs))] [De f in s t ste a m (SteamFlowRate "NLV0.GQa:.A48.9") (StringQuery "What is the steam flow rate") (SensorType Flow) (SpecialistUsedThisSensor NIL)] [ d e f in s t s t e a m (SteamFlowTrend "NLV0.GQa:.A48.8") (StringQuery "What is the steam flow trend") (SensorType FlowTrend) {CASPIAN:LAIR:OHIO-STATE} (SpecialistUsedThisSensor NIL)] [definst Suppress ionPooi (SuppressionPoolLevel "JHW0.f [definst SuppressionPooi (SuppressionPoolTemp ”JHW0.[ [definst SuppressionPooi (SuppressionPoolTempTrend "JHW0.[ [DEFINST Feedwater (TotalRxFWFlow ”D«-CO.[ [definst Turbine (TurbineElectricOutput "JHW0.[ (RPAQQ LOCAjunk [(Steam&Electric (((L LL) (L LL) (N L LL) (N H) (F) then SSRVOpen]) (RPAQQ ClosedMSlVjunk [(MSIV (((T U) (T) (D DO) then SMSIVOpen) then SMSIVOpen))) (Reactor (((T U) (N H HH) (L LL) (T> then SMSIVOpen) ((T U) (H HH) (L LL) (F U) then (A SMSIVOpen SSRVOpen]) (RPAQQ WINDOW {WINDOW}#56.104404) STOP APPENDIX C MODIFICATIONS OF CSRL AND DOCUMENTATION 198 Appendix C C.l Modifications of CSRL and Documentation of Changes Several CSRL functions were modified and new functionalities were added for the purpose of this dissertation. In this Appendix a list of these changes and modifications are presented and each function is reviewed. This review is organized by Classes, Functions and Methods and includes the list of arguments for each function, and the values that it should return. Please note that these functions and methods are developed for sensor validation routines, except for the cases that are noted. Note: N/A means Not Applicable A. CLASSES CSRLCase - Class for cases to be diagnosed. Enhancement to CSRL. Args : N/A Return : N/A Modification: Added new Instance Variable (IV) SusDataList. This list contains the questionable data points. DoLisp - Function to perform LISP functions within CSRL. Args : [(LISP-Function Argl Arg2 ...) (Argi Bindingl) (Arg2 Binding2) ...] Return : Whatever the LISP-Function returns Modification: Fixed a Bug. NPPBrowser - Class for the new Browser, Enhancement to CSRL. Args : N/A Return : N/A Modification: Add capability to include sensor validation, Manual or Automatic. 199 200 NPPValueBrowser - Class for the new value-browser, Enhancement to CSRL. Args : N/A Return : N/A Modification: Left-Button functionality added for resetting and validation of data points B. FUNCTIONS AddList - Function for adding an. element to a list, if not already there. Args : Element Return : List of Elements Modification: New AskHLN? - Query Function, Enhancement to CSRL Args : Question Return : Value Associated with Question Modification: Changed to 5 Level Answers AskTrend? - Query Function, Enhancement to CSRL. Args : Question , Return : Value Associated with Question Modification: New Query Funciton for Trend Inputs (5 levels) AskUsers? - Function to check a backup data for a sensor can be calculated automatically. If it cannot, then the user is queried about it and proper info is displayed to him. Args : Validation List Return : New Value for Each Element Modification: New GetAutoSusData - Function to perform automatic sensor validation. Args : Specialist Return : Suspicious Data of Specialist Modification: New GetSusData - Function to perform manual sensor validation Args : Specialist Return : Suspicious Data of Specialist Modification: New Change***to*** - Function to convert users input to uppercase. *** can be HLN, IDZ, YNU. Enhancement to CSRL Args : x Return : Uppercase x Modification: New 201 Col1ectSuspData - Function to collect suspicious data during diagnosis Args : Suspicious Specialist Return : Nil Modification: New ComparePattern - Function to compare normal expectations of malfunction with symptoms Args : Knowledge Groups and Expectations of a Specialist Return : Suspicious Sensors List Modification: New FindConfidenceValue - Function to find confidence value of a specialist Args : Specialist Return : Confidence Value Modification: New FindKg - Function to find the knowledge group containing suspicious data. Args : Knwledge Group Name and Expectations Return : Name of Knowledge Group Modification: New FindMember - Function to varify the users input is correct format. Args : Nil Return : User input Modification: New FindSuspSensor - Function to find suspicious sensor from the suspicious sensor list Args : Suspicious Data List and Expectations Return : Nil Modification: New FindTipNodeWith* - Function to find the first tip-node with * in its confidence value. Args : Nil Return : Specialist With * in CF Modification: New IsCurrentSpecialistFinished - Function to check if diagnosis is finished, Enhancement to CSRL. Args : Nil Return : Value Modification: Modified to only ask the question once. 202 MakeList - Function to keep adding suspicious sensors to the list of SuspSensorList Args : Element Return : Nil Modification: New MakeSpecialistList - Function to identify the specialists that have used a sensor Args : Sensor Value Return : List of Specialists Modification: New MakeSuspSensorList - Fuction to compare patterns between the knowledge groups and expectations Args : Suspicious Data and Expectations Return : Nil Modification: New NPPSubs - Function to replace an old value with new value Args : Question and New Input Return : New input Modification: New ResetNPP - Function to reset the current case Args : Case Return : Nil Modification: New ResolveList - Function to identify which row of a kg contains suspicious data Args : Element Return : List of Suspicious Sensors Modification: New SetSuspSensorList - Function for setting up the suspicious sensor list Args : Suspicious Sensor Return : Suspicious Sensors List Modification: New TipNode? - Function to check if a specialist is a tipnode? Args : Specialist Return : T or Nil Modification: New ValidateSuspSensor - Function that finds new values for sensors. Args : Suspicious Sensors List Return : New values Modification: New 203 C. METHODS CSRLCase.AutoValidate - Method to start auto validation Args : Obj, ObjName Return : Nil Modification: New CSRLCase.Reset - Method to reset currentCase, Enhancement to CSRL Args : Obj, ObjName Return : Nil Modification: New CSRLCase. ResetSusData - Method to reset suspicious sensors list Args : Obj, ObjName Return : Nil Modification: New CSRLCase. StoreSusData - Method to store suspicious data during diagnosis Args : Obj, ObjName Return : Nil Modification: New NPPBrowser.NPPDiaqnose - Method for adding sensor validation to standard CSRL Args : Obj, Obj/Name Return : Nil Modification: New NPPValueBrowser.EditCase - Method to edit current case, Enhancementy to CSRL Args : Obj, Obj/Name Return : Nil Modification: New NPPValueBrowser.NewValidate - Method for auto validation Args :Obj, objName Return : Nil Modification: New ValueBrowser.ResetNode -Method to reset a node, Enhancement to CSRL. Args : Obj, ObjName Return : Nil Modification: New 204 NPPValueBrowser.SaveCaseSia - Method to save the case on file-server, Enhancement to CSRL. Args : obj , Obj name Return : Nil Modification: New NPPValueBrowser.Validate - Function for manual validation Args : Obj , Obj name Return : Nil Modification: New A code listing of the above functions is presented in Appendix B. For more detail about these functions, please refer to this appendix. C.2 Methods of Testing of Modifications and Additions The testing routine for the modified functions, methods and classes was that a sample run that was saved from the original CSRL (before changes) was executed after each change and the final results were compared. If the final results of the two runs were identical and the added functuionality was performing according to expectations, then, that particular piece of the software was marked as valid. The new functions and methods were tested by utilization of the BREAK and TRACE packages which are available on the Xerox 1108/09 environments. Each added function was traced to ensure the proper function calls and control of the program. Next, the function would be "broken11 (ie. execution would stop at the "break" sign) and 205 the list of arguments, as well as the internals of the function were examined or modified. Then the sample run with appropriate modifications was executed and the expected behavior of the overall system were observed. If the overall behavior was as expected, then, that new function was marked as valid. The above steps were followed for all the additions and modifications to CSRL to ensure the proper behavior of this expert system. LIST OF REFERENCES 1. A.B. Long, "Computerized Operator Aids", Nuclear Safety, Vol. 25, No. 4, July/August 1984. 2. "FuctionalCriteria for Emergency Response Facilities", NUREG-0696, US-NRC, February, 1981. 3. Bylander, T., Mittal, S., Chandrasekaran, B., "CSRL: A Language for Expert Systems for Diagnosis", Proceedings of the International Joint Conference on Artificial Intelligence, pp 218-21, William Kaufman, Inc., Los Altos, CA., Aug. 83. 4. Chandrasekaran, B., "Decomposition of Domain Knowledge into Knowledge Sources: The MDX Approach". Proc 4th Nationa Conf. of Canadian Soc. for Computational Studies of the Intelligence (CSCSI/SCEIO), Saskatoon, Canada, May 1982. 5. Sharma, D.D., "PhD Dissertation Proposal", Nuclear Engineering Program, Mechanical Engineering Department, The Ohio State University, 1983. 6. "Human Factors Acceptance Criteria for the Safety Parameter Display System", NUREG 0835, USNRC, October 1981. 7. J. C. Lin, D. Okrent, "One Aspect of the Application of Disturbance Analysis to Nuclear Reactor Safety", School of Engineering ALO-143, UCLA, Jan 1982. 8. "On-Line Power Plant Alarm and Disturbance Analysis System", NP-613, Research Project 891, Prepared by Combustion Engineering Inc, Feb 1978. 9. C. H. Meijer, "A Critical Function Expert System for Nuclear Power Plants", The Enlarged Halden Programme Group Meeting on Feul Performance Experiment and Computerized Man-Machine Communication, May 23, 1982. 10. Upadhyaya, B., "Sensor Failure Detrection and Estimation", Nuclear Safety, Vol 26, No. 1, Jan-Feb 1985. 206 207 11. Hajek, B.K., Hashemi, S., Sharma, D.D., Chandrasekaran, B., Miller, D.W., "Artificial Intelligence Enhancement to Safety Parameter Display Systems", Presented in the Sixth Power Plant Dynamics, Control and Testing Simposium, Knoxville, Tennessee, April 1986. 12. C.H. Meijer, "Critical Function Expert System for Nuclear Power Pnants", Workshop on AI Applicatins to NPPs, Proc., Sponsered by EPRI, May 1984. 13. B. Chandrasekaran, D.D. Sharma, and D.W. Miller, "Application of knowledge Based Systems to the Reactor Operation", The American Nuclear Society Meeting Proc., Winter 82. 14. W.E. Underwood, "A CSA Model-Based NPP Consultant", AAAI Meeting Proc., 1982. 15. W.R. Nelson, "Reactor: An Expert System for Diagnosis and Treatment of Nuclear Accidents", AAAI Meeting Proc., 1982. 16. Winston, P.H., Horn, B.K., "Lisp Readings", Addison- Wesley Co, Mass., 1981. 17. D.K. Wehe, N.E. Clapp, et al., "Summary of the Artificial Intelligence Applications at HFIR", the Sixth Power Plant Dynamics, Control and Testing Symposium Proc., Knoxville, Tennessee, April 1986. 18. Deyst, J.J. Jr., Kanazawa, R.M., Pasquenza, J.P., "Sensor Validation: A Method to Enhance the Quality of the Man/Machine Interface in Nuclear Power Stations", IEEE Transactions on Nuclear Science, Vol. NS-28, No. 1, February 1981. 19. B.R. Upadhyaya,"Sensor Failure Detection and Estimation", Nuclear Safety, Vol. 26, No. 1, Jan.-Feb. 1985. 20. J.S. Dyest, R.M. Kanazawa, J.P. Pasquenza, "Sensor Validation: A Method to enhance the Quality of the Man- Machine Interface in Nuclear Power Stations, IEEE Transactions on Nuclear Science, Vol NS-28-1 Feb. 1981. 21. C.H. Meijer, J.P. Pasquenza, J.C. Deckert, J.L. Fischer, D.B. Laning, "On-Line Power Plant Signal Validation Technique Utilizing Parity-Space Representation and Analytical Redundancy, EPRI project number NP-2110, November 1981. 208 22. O.L. Deutch, "Signal Validation Advances Development for On-Line Plant Monitoring and Control", The Sixth Power Plant Dynamics, Control and Testing Symposium Proc., Knoxville, Tennessee, April 1986. 23. Chandrasekaran, B., Punch, W.F., "Hierarchical Classification: Its Usefulness for Diagnosis and Sensor Validation", Presented to the 2nd AIAA/NASA/USAF sumposium on Automation, Robotics and Advanced Computing, Feb. 1987. 24. Chandrasekaran, B., Punch, W.F., "Data Validation During Diagnosis, a Step Beyond Traditional Sensor Validation", Submitted to AAAI87. 25. S. Hashemi, D.W. Miller, B. Chandrasekaran, B.K. Hajek, "Expert Systems Application to Plant Diagnosis and Senor Data Validation", The Sixth Power Plant Dynamics, Control and Testing Symposium, Knoxville, Tennessee, April 1986. 26. Melle, W.V., "A Domain Independent Production-Rule System for Consultation Programs", Proc Sixth International Conference on Artificial Intelligence, PP 923-925, Tokyo, Japan, 1979. 27. Shortlife, E.H., "Computer-Based Medical Consultation: MYCIN", Elsevier, New York, 1976. 28. Bylander, T., Mittal, S., "CSRL: A Language for Classificatory Problem Solving and Uncertainty Handling", AI Magazine 7 (Summer 1986). 29. Chandrasekaran, B., Gomez, F., Mittal, S., and Smith, J., "An Approach to Medical Diagnosis Based on Conceptual Structures". Proc. IJCAI, Tokyo, Aug. 1979. 30. Brown, D.C., Chandrasekaran, B., "An Approach to Expert Systems for Mechanical Design", Proc. of IEEE Trends & Applications Conf., Gaithersburg, MD. May 1983. 31. B. Chandrasekaran, "Towards a Taxonomy of Problem Solving Types", AI Magazine, Vol. 4, No. 1, Winter/Spring 1983. 32. Sharma, D., Miller, D., Chandrasekaran, B., Design of an Artificial Intelligence System for Safety Function Maintenance", Trans. Am. Nucl. Soc. 50, pp 294-7, Nov 1985, Presented (Invited) at the Winter Meeting of American Nuclear Society. 209 33. "Component Failures of Pressurized Water Reactors", prepared by Combustion Engineering under Sandia Contract No. 136442, 1980. 34. "On-Line Power Plant Signal Validation Technique Utilizing Parity-Space Representation and Analytic Redundancy", EPRI NP-2110, Research Project 1541, Prepared by Combustion Engineering, Inc. and Charles Stark Draper Laboratory, Inc., November 1981. 35. Bylander, T., "Syntax and Semantics of CSRL in INTERLISP-D", Laboratory of Artificial Intelligence Research (LAIR), Department of Computer and Information Science, The Ohio State University, April 1985. 36. Hajek, B.K., Miller, D.W., Hashemi, S., et al., "Expert Systems Applications to Fault Diagnosis and Procedure Synthesis", Proc. of EPRI Sponsored *conference on Expert Systems Applications in Power Plants, Boston, MA, May, 1987. 37. Hajek, B.K., Stasenko, J.E., Hashemi, S., "The Structure of an Expert System to Diagnose and Supply Corrective Procedures for Nuclear Power Plant Malfunctions", Proc. ANS Topical Meeting on Artificial intelligence and other Innovative Computer Applications in Nuclear Industry, Snowbird, Utah, Sep., 1987. 38. Chandrasekaran, B., Tanner, M.C., Josephson, J.R., "Explaining Control Strategies in Problem Solving", IJCAI, 1987. 39. Moorthy, V.S., Chandrasekaran, B., "A Representation for the Functioning of Devices That Support Compilation of Expert Problem Solving Structures", Proc. MEDCOMP, Sep., 1983. 40. Sharma, D.D., "A Knowledge Based Framework for Procedure Synthesis and Its Application to the Emergency Respnse in a Nuclear Power Plant", Ph. D. Dissertation, The Ohio State University, Fall 1986. 41. Sharma, D., Chandrasekaran, B., Miller, D., "Dynamic Procedure Synthesis, Execution, and the Failure Recovery", The 1st International Conference on Applications of Artificial Intelligence to Engineering Problems proceedings, Southampton, United Kingdom, April 1986. 210 42. Sharma, D., Miller, D., Hajek, B., Chandrasekaran, B., "Intelligent Process Control Operator Aid - An Artificial Intelligence Approach", to be presented and published in the proceedings of the sixth Power Plant Dynamics, Control and Testing Symposium, Knoxville, Tennessee, April 86.