INFORMATION TO USERS While the most advanced technology har been used to photograph and reproduce this manuscript, the quality of the reproduction is heavily dependent upon the quality of the material submitted. For example: • Manuscript pages may have indistinct print. In such cases, the best available copy has been filmed. • Manuscripts may not always be complete. In such cases, a note will indicate that it is not possible to obtain missing pages. • Copyrighted material may have been removed from the manuscript. In such cases, a note will indicate the deletion. Oversize materials (e.g., maps, drawings, and charts) are photographed 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 also filmed as one exposure and is available, for an additional charge, as a standard 35mm slide or as a 17”x 23” black and white photographic print. Most photographs reproduce acceptably on positive microfilm or microfiche but lack the clarity on xerographic copies made from the microfilm. For an additional charge, 35mm slides of 6”x 9” black and white photographic prints are available for any photographs or illustrations that cannot be reproduced satisfactorily by xerogi’aphy.
8625286
SHARMA, DEVA-DATTA
A KNOWLEDGE BASED FRAMEWORK FOR PROCEDURE SYNTHESIS AND ITS APPLICATION TO THE EMERGENCY RESPONSE IN A NUCLEAR POWER PLANT
The Ohio S tate U n iv e rs ity PH.D. 1986
University Microfilms
I ntern Sti on si SOO N. Zeeb Road. Ann Arbor, Ml 48106
Copyright isse
by
SHARMA, DEVA-DATTA
All Rights Reserved
PLEASE NOTE:
In all cases this material has been filmed in ttie 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 iiiustraüons, 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 page.
7. Indistinct, broken or small print on several pages yX
8. Print exceeds margin requirements ______
9. Tightly bound copy with print lost in spine ______
10. Computer printout pages with indistinct print ______190 11. Page{s) ______lacking when materia! received, and not available from school or author.
12. Page(s) ______seem to be missing in numbering only as text follows. 251 13. Two pages num bered . Text follows.
14. Curling and wrinkled pages ______
15. Dissertation contains pages with print at a slant, filmed a s received
16. Other______
University Microfilms International
A KNOWLEDGE BASED FRAMEWORK FOR PROCEDURE
SYNTHESIS AND ITS APPLICATION TO
THE EMERGENCY RESPONSE IN A
NUCLEAR POWER PLANT
DISSERTATION
Presented in Partial Fulfillment of the Requirements for the De^ee Doctor of Philosophy m the Graduate School of the Ohio State University
By
Deva-Datta Shanna, ETech., M.Tech.,
The Ohio State University 1986
Dissertation Committee: oved by Don W. Miller E Chandrasekaran Brian Hajek Adviser Nuclear Engineering Copyright by
Deva-Datta Sharma To My Parents
Smt. Vimala Devi and Shri Bhoodeva Datta Shanna ACKNOWLEDGEMENTS
I wish 10 express heartfelt gratitude towards my advisers. Dr. Don W. Miller and
Dr. B. Chandrasekaran, for their guidance, continuous encouragement, and patience which was so essential for the completion of this work.
I am grateful to my reading committe member. Professor Brian Hajek, for his earnest interest in my work and for his various suggestions. Specially, his efforts and recommendations to help in narrowing the gap between the theory and the real world are gratefully acknowledged.
I thank Gabe Kovacs, John Fried, and Mary Moyer of the Battelle Memorial
Institute for providing me the staff fellowship to complete this work I also thank
Sriram Mahalingam, Ed Dudzinski, and Jim Brink of the AT program office, Battelle
Memorial Institute, for assuming the burden of extra work to enable me to work on my dissertation.
The NSF grant #’CBT-8400840 provided the basic support for this work and
several other members of the research team whose inputs were very vslriable. Several
members of the Laboratory for the Artificial Intelligence Research, The Ohio State
University, provided timely help in dealing with the computer system problems.
iii Finally, I wish to thank my wife Abha and my family in India for their support and faith in me.
IV VITA
September 10. 1956 ...... Bom - Hatfaras. India.
1977 ETecâ. (Electrical Engineering). Institute of Technology Banaras Hindu University, Varanasi. India
1979 ...... M. Tech. (Nuclear Engineering). Indian Institute of Technology. Kanpur. India
1982 ...... M.S. (Nuclear Engineering). The Ohio State Universitj'. Columbus, Ohio.
1982-Present ...... Principal Research Scientist. Battelle Memorial Institute, Columbus. Ohio.
PUBLICATIONS Research and Technical Papers:
D.D. Shanna D.W. Miller, B.K. Hajek. and E Chandrasekaran. "Intelligent Process (Zontrol Operator Aid — An Artificial Intelligence Approach". Proc. of Sixth Power Plant Dynamics. Control and Testing Symposium. Knoxville. April 1986.
B.K. Hajek. D.D. Sharma S. Hashemi. D.W. Miller, and E Chandrasekaran. "Artificial Intelligence Enhancements to the Safet)' Parameter Display System”, Proc. of ^ International Topical Meeting on Advances m Human Factors in Nuclear Power Systems. Knoxville, April 1986.
D.D. Shanna. B. Chandrasekaran. and D.W. Miller. "Dynamic Procedure Synthesis. Execution, and Failure Recovery". Proc. of First Intemational Conference on Applications of Artificial Intelligence to Engineering Problems. Southampton. England. April 1986.
D.D. Sharma and Sriram Mahalingam. "WELDEX — An Expert System for Non- Destructive Testing of Welds". Proc. of t ^ IEEE AI Applications Conference. December. 1985.
D.D. Sharma, D.W. Miller, and B. Chandrasekaran, "Design of an Artificial Intelligence System for Safety Function Maintenance". Trans. Am. Nucl. Soc.. 50. pp294-297, November 1985.
D.D. Sharma and Sriram Mahalingam."WELDEX — A Radiograph Interpretation Expert System for Welding Inspection", to be published in the Proc. of Mechanical Failure Prevention Group Symposium on Use of New Technologies to Improve Mechanical Readiness. Reliability, and MaintainabiliP.'. National Bureau of Standards. Washington. D.C, April 1985.
D.D. Sharma and D.W. Miller, "A Risk/Cost Benefit Approach to Establishing Threshold Values for Critical Nuclear Plant Safety Parameters", Trans. Am. Nucl. Soc., June 1983.
B. Chandrasekaran, D.D. Sharma, • and D.W. Miller. "Application of Knowledge- Based Systems to Reactor Operations". Trans. Am. Nucl. Soc.. Winter 1982.
D.D. Shanna and K. Sriram. "Fault Tree Analysis of CANDU Shutdown System". Nucl. Engg. and Design.. November. 1980.
D.D. Shanna and K. Sriram. "CANDU reactor Shutdown System Unavailabjlty Estimation". Trans. Am. Nucl. Soc.. 35. November, 1980.
D.D. Sharma, D. Chatterjee. and K. Sriram, "Minimum Risk Based Selection of Waste Fuel Dumpling Site". Proc. of ^ Sixth Indian Association of Radiological
VI Protection on Safety Aspects of Nuclear Fuel Cvcle. Bhabha Atomic Research Center. Bombay, March. 1979.
D.D. Shanna. and K. Sriram. "Fault Tree Modeling of Reactor Shutdown System". Proc. of Power Plant Safety and Reliability. Bhabha Atomic Research Center. Bombay, January, 1979.
Reports and Books:
D.D. Sharma. and J.R. Brink. "A Systematic Approach for Building Expert Systems", internal report, Battelle Memorial Institute, 1985.
BJ. Erownstein, M.B. Kuhner, R.B. McCown, F.G. Rea. G.F. Renner, and D.D-Sharma. "Role of Artificial Intelligence in the Development of Tactical Robots", Report R-6161, Defense Advanced Research Projects Agency, June 1984.
D.D. Sharma, and J.R. Prink, "Industrial Expert Systems", internal report. Battelle Memorial Institute, 1983.
D.D. Sharma. "Development of Methods for Fire Risk Analysis in Nuclear Industry", internal report, Battelle Memorial Institute, 1983.
Several Training modules for "Development of a Training Course for the Davis- Besse Nuclear Power Station Instrument and Control Engineers and Technicians”, for the Toledo Edison Company, 1980 - 1981
D.W. Miller, P.A. Schlosser, A.C DeVuono, R.N. Christensen, D.D. Sharma, and J. Shih, "Instrumentation Needs for In Situ and Field testing Program", Tech. Report for the Office of Nuclear Waste Isolation, Battelle Memorial Institute. April 1980.
D.D. Sharma, "Fault Tree Analysis of a CANDU Shutdown System", MS Thesis. Indian Institute of Technology, Kanpur, 1979.
D.D. Sharma, "Performance Optimization of Electrical Distribution Network", B.S. Thesis. Banaras University, Varanasi, 1977.
Vll FIELDS OF STUDY
Major Fiel± Nuclear Engineering Studies in Reactor Instrumentation and Control: Professor Don W. Miller
Studies in Nuclear Systems Analysis: Professor S. Nakamur?. and Professor Don " Miller
Studies in Artificial Intelligence: Professor B. Chandrasekaran
Studies in Man-Machine Systems: Professor T. Rockwell and Professor R. Jagasinski
Vll] TABLE OF CONTENTS
Dedication ...... ü Acknowledgements ...... iii V i t a ...... V List of Tables ...... xiii List Of Figures ...... xiii Abbreviations ...... xv 1. Introduction ...... 1 LI Motivation ...... 2 LLl Operational Problems in Complex Engineering Systems ...... 3 LL2 Overview of the TMI-2 Accident ...... 6 LL3 TMI-2 Lessons Learned ...... 11 1.2 Dynamic Procedure Synthesis - An Overview and Research Issues . . 12 L2.1 NPP related Design and Research Issues ...... 15 L2.2 AI related Design and Research Issues ...... 17 L2.3 Scope and Limitations of the S tu d y ...... 19 L3 The Organization of the Dissertation ...... 21 2. Background ...... 23 2.1 Existing Approaches for Emergency response in Nuclear Power Plants 24 2.1.1 Event-Oriented and Symptom-Oriented Approaches ...... 25 2.1.2 Function-Oriented Procedure Selection ...... 26 2.L3 Existing Integrated Approaches ...... 28 2.2 Operator Aids in Nuclear Power In d u stry ...... 31 2.2.1 Monitoring. Detection and Diagnosis A id s ...... 33 2.2.2 Selection and Synthesis of Control Procedures ...... 37 3. A Knowledge Based Framework for Procedure S ynthesis ...... 44 3.1 Analysis of the Task of Controlling an Abnormal Incident ...*... 46
IX 3.L1 Scenario: Loss of All Feed Water to a B W R ...... 46 3.L2 Analysis of Operator A ctions ...... 47 3.2 Characterization of Procedure Synthesis in a Nuclear Power Plant . . 52 3.2.1 The Need for Dynamic Procedure Synthesis ...... 53 3.2.2 Reasoning Tasks for Dynamic Procedure Synthesis ...... 55 3.2.3 Interaction between Procedure Synthesis T a s k s ...... 62 3.3 An Information Processing Model for Dynamic Procedure Synthesis . S4 3.3.1 Background ...... 66 3.3.2 Problem Statem ent ...... 70 3.3.3 Assumptions ...... 72 3.3.4 A Problem Solving Theory for Procedure Synthesis ...... 73 3.3.5 Problem Solving Mechanisms for Dynamic Procedure Synthesis . 76 3.4 Summary ...... 86 4. The Organization and Representation of Knowledge for Dynamic Procedure Synthesis ...... 88 4.1 Background ...... 89 4.2 Organization of the Library of Plans ...... 92 4.2.1 Goal Indexed Plans L ibrary ...... 94 4.2.2 Event Indexed Plans library ...... 95 4.2.3 System Plans Library ...... 98 4.3 Knowledge Types and Representation ...... 100 4.3.1 Knowledge about System Status ...... 100 4.3.2 Trends and other Temporal Relationships ...... 105 4.3.3 Diagnostic Knowledge ...... 108 4.3.4 Knowledge about Plans ...... 109 4.3.5 Control Knowledge ...... 121 4.4 Implementation of DPSRL ...... 126 4.4.1 Background ...... 127 4.4.2 The DPSRL Program ...... 129 4.5 An Example of the Application of DPSRL ...... 137 5. FEPS — A Framework for the Synthesis of Emergency Procedures in a Nuclear Power Plant ...... 154 5.1 An Approach to Int^rated Symptomatic/Events/Functions Oriented Procedure Synthesis ...... 155 5.1.1 Elements of FEPS ...... 157 5.L2 Organization of Procedures in NPP ...... 161 5.L3 Integration of Event-Oriented and Safety Goal Maintenance Approaches 163 5.1.4 Discussion of FEPS ...... 164 5.2 Safety Goal Plans — An Approach for Safety Function Maintenance 166 5.2.1 Decomposition of Plant Safety Functions ...... 168 5.2.2 Development of the Safety Goals Hierarchy ...... 170 5.3 Plan libraries for FEPS ...... 172 5.3.1 Event P la n s ...... 174 5.3.2 System Plans ...... 175 5.3.3 Goal Plans ...... 175 5.4 Demonstration of FEPS and Performance Analysis ...... 176 5.4.1 Performance Analysis ...... 177 5.4.2 A nalysis ...... 198 5.5 Summary ...... 207 6. Smfunaiy, Conclusions, and Recommendations ...... 20^ 6.1 Summary...... 208 6.2 Contributions and Results ...... 210 6.3 Conclusions ...... 214 6.4 Recommendations for Future W o rk ...... 216 6.4.1 Research Issues...... 216 6.4.2 Technology Transfer Issues ...... 221 References ...... 224 Appendix A. Sample Procedures Used in Implementing FE P S ...... 233 A1 Event P la n s...... 242 A.2 System Plans ...... 255 A3 Goal Plans ...... 268 Appendix B. Traces of the Performance of FEPS for Sample Cases . . . 269 E l Case L Trip of All FW Pum ps ...... 281 E2 Case 2. Loss of All FW ...... 289 E l l Case I L Loss of All FW Without Using FEPS ...... 289 E12 Case 12 Method L Loss of All FW Without Using the Safety Goal Hierarchy ...... 294 E13 Case 13 Method 1 Lo» of All FW Using the Safety GoalHierarchy 312 E3 Case 3. Loss of All FW with Failure to Scram ...... 331 B.4 Case 4. Loss of All FW with Failure to Trip Recirc Pumps ...... 337 E5 Case 5. Loss of ALl FW with Failure of HPCS/RCIC ...... 356
XI LIST OF TABLES
Table 1: Sequence of Evenc for the Loss cf FW Event ...... 179 Table 2: Sequence of Events for the Loss of FW with the failure to Start High Pressure In jectio n ...... 182 Table 3: Typical Execution Time of FEPS Program ...... 206
XU LIST OF FIGURES
Figure 1: Sequence of Events at the b^inning of the TMI-2 Accident 7 Figure 2: Sequence of Events for Loss of AH F W ...... 48 Figure 3: Reasoning Tasks for Dynamic Procedure Synthesis ...... 63 Figure 4: Structure of a Planning System ...... 67 Figure 5: An Example of a Classification Hierarchy for Indexing into Events Plan L ibrary...... 78 Figure 6: Organization of Plans in D P S ...... 93 Figure 7: A Typical Frame for Goal P la n s ...... 96 Figure & A Typical Frame for Event Plans ...... 97 Figure 9: A Typical Frame for System P la n s ...... 99 Figure Kh A Typical Plan Frame ...... 119 Figure 11: DPSRL Objects ...... 130 Figure 12: A Typical Compiled Plan Object ...... 132 Figure 13: DPSRL Meta Class MetaPlanner...... 133 Figure 14: DPSRL Class Action and its Subclasses ...... 134 Figure 15: PSRL Class DataBase ...... 136 Figure 16: Procedures used for the Synthesis in the Reactor Scram Scenario 138 Figure 17: Synthesized Procedure for Reactor Scram ...... 141 Figure 1& Elements of F E PS ...... 158 Figure 19: The Safety Goal Hierarchy ...... 173 Figure 20: The Loss of FW Scenario for the Demonstration of FEPS 178 Figure 21: Event Tree for BWR Transient Events from WASH 1400 . 181 Figure 22: Procedure for a FW Pump T rip ...... 184 Figure 23: Procedure Generated by FEPS for the FW Pump Trip Scenario 185 Figure 24: Procedur* Generated by FEPS for event Tripped FW Pumps with Failure to Start MFWPump using simple Function Oriented Approach ...... 189
xui Figure 25: Procedure for the Event Loss of All FW ...... 191 Figure 26: Procedure to Maintain RPV Water Level C ontrol ...... 191 Figure 27: Procedure Generated by FEPS for event Tripped FW Pumps with the Failure to Start MFWPump using Safety Goals Hierarchy A pproach ...... 192 Figure 28: Procedure for Reactor Scram ...... 194 Figure 29: Procedure Generated by FEPS for the scenario of Loss of All FW with Failure to Scram R eacto r ...... 195 Figure 3(k Procedure for Maintaining Inserted Reactivity Control . . . 196 Figure 31: Procedure Generated by FEPS for the Loss of All FW with Failure to Trip Recirc Pumps ...... 197 Figure 32: Procedure Generated by FEPS for Loss of All FW with Failure to Start H i^ Pressure Injection ...... 199 Figure 33: Procedure for Inventory Control ...... 200 Figure 34: Procedure for the Low Pressure Injection ...... 201 Figure 35: Integration between Safety Goals and Events Procedure . . 205
XIV ABBREVIATIONS
BWR: Boiling Water Reactor.
DPS: Dynamic Procedure Synthesis described in this dissertation.
DPSRL Dynamic Procedure Synthesis Representation Language described in this dissertation.
FEPS: Framework for Emergency Procedure Synthesis.
PR: Failure Recovery Process.
FW: Feed Water.
LOFW: Loss of All Feed Water.
MDX: A Medical Diagnosis Expert system designed at OSU.
NPP: Nuclear Power Plant
PE: Procedure Execution Process.
PG: Procedure Generation Process
PSM: Plant Status Monitoring Process.
PSS: Procedure Selection and Scheduling Process.
RPS: Reactor Protection System CHAPTER 1
INTRODUCTION
The objective cf this dissertation is to develop a knowledge based framework to synthesize operating procedures in runtime to respond to an operational emergency in a nuclear power plant (NK*). The development of the framework is based on an analysis of the task of controlling an operational emergency as a knowled^ based planning process. Specifically, this dissertation describes:
• a task analysis of an expert operators response to an emergency situation in a Boiling Water Reactor (BWR), where the goal is to maintain plant safety functions, and identification of various subtasks performed by the operator.
• a knowledge based problem solving theory for dynamically synthesizing procedures (DPS) for knowledge rich domains;
• a knowledge representation framework and a high level language (DPSRL) to support the DPS approach;
• a framework for emergency response in a NPP (FEPS) and an experimental prototype implemented in DPSRL; and
• demonstration of the DPS theory and the FEPS framework. 2 In this chapter, we discuss operator error as a cause of the operational problems in a NPP and other complex engineering systems. An overview of a knowledge based theory (called DPS) is presented as a systematic approach to design decision aids for operators to help in some of the problems, specifically, in selecting and modifying procedures in runtime. We also present an overview of the related research issues both in Artificial Intelligence and Nuclear Engineering.
Finally, we describe the scope of the proposed approach and its limitations.
1.1 MOTIVATION
Over the last 32 years of the history of commercial nuclear power there have been several accidents in nuclear installations worldwide. The two most serious, the
TMI-2 accident in March 1979 and the accident at the Chernobyl nuclear power plant in April 1986, have been partially attributed to the human error. Several other industrial accidents in the commercial aviation, the chemical industry, and the
Challanger space shuttle disaster have also been attributed to human error at various stages of design, manufacturing, inspection, and operation. It is our observation that most of the serious human errors are caused by errors in judgement and decision making. Specifically, human errors are caused by the failure to apply knowledge and reasoning to solve a problem. It is our belief that one of the reasons for this failure is that technologically advanced systems have 3 become extennely complex, and often lack in adequate decision aids. In this section some of the reasons for human error are discussed. The TMI-2 accident is also analyzed to identify specific areas where decision aids for operating a NPP are needed.
1.1.1 Operational Problems in Complex Engineering Systems
In recent years several industrial accidents have been attributed to an operator or human error at some stage of the industrial process. To date there is no well accepted scientific theory explaining why human operator error occurs. There are. however, two schools of thoughts: the behavior psychologists and the AI scientists.
The behavioral psychologists inspired by the control theoretic view of human behavior have proposed two paradigms. One of the paradigms contends that operators behave as feedback contre! systems. An error occurs if the system (or the environment) does not provide sufficient feedback signals to enable determination of the conformance of the operators actions with the expected system response. Thus the source of error lies with the system or the environment rather than with the operator. Proponents of this paradigm would like to see many more meaningful feedback signals from the system probably displayed in a manner to ergonomically improve the man-machine interface. Such improvements, although useful, result in a large number of sensor variables displayed in the control room.
For a complex system like a nuclear power plant the number of sensor values is very large causing the problem of information overload [Sheridan 80]. 4 A somewhat more popular paradigm asserts that along with feedback signals operators also use a feedforward model (a type of mental model), which they carry in their heads, of how the environment will respond to specific actions. Using the feedback data available from the system and the predictions based on the feedforward model, operators plan and execute actions. An error occurs if the feedforward model is inaccurate for the specific situation. Proponents of this view suggest improved training to help operators develop correct mental models.
Moreover, they sug^st that information should be displayed in a manner consistent with the mental model of the operator. Practical solutions based on such a view have not yet been developed.
The third view and the one which is the basis of this dissertation, is inspired by the information processing or the computational view of human intelligence held by the researchers in Artificial Intelligence (AI). Instead of developing estimation models of how people react, the AI research focuses on developing computational mental models of how people think. According to the AI paradigm an operator or a pilot can be viewed as an experienced problem solver who uses situation Jt:'- t*sr specific knowledge to plan and execute actions. Futhermore, the problem solving is viewed as an information processing based computational task.
According to the AI view, an human error occurs if the operational problem to be solved requires computational resources exceeding the human capabilities. The operational complexity arises from the following sources: L Information Overload: It is a well established fact that the human channel capacity for processing independent pieces of data is very limited [Miller 56]. Detection, diagnosis, and correction of operational problems require interpretation of an enormous amount of data provided by a large number of sensors. Under severe time constraints, typical of most operational problems, such an information overload, even if it provides useful feedback cues, can practically paralyze an operator.
2. Cognitive Overload: in order to adequately respond to a new situation an operator has to reason out the solution based on his understanding of the functioning of the engineering system, various underlying processes, and their interactions. Modem engineering systems are not only extremely complex to understand but for several off-normal situations their behavior is not even correctly understood. Even if sufficient time were available, the reasoning or the cognitive capability required to comprehend the system behavior during a new situation and to arrive at an adequate solution can be a formidable task. Even during familiar situations the operator may be cognitively paralyzed under the pressure of limited time and stress caused by an unacceptably h i^ risk perception.
3. Lack of Knowledge: The increasing automation in the control of modem engineering systems creates two types of problems: first, it requires retraining of the operators to make them knowledgeable about the new systems; second, often the assumptions underlying the automation are not clearly communicated to the operators. Whenever, system control functions being performed by operators are automated, the design engineers implicitly redefine the distribution of responsibility between the operator and the automatic control systems. Often the redefined distribution is not properly communicated, even worse the system interactions are not even known.
The realization that the existing engineering systems have become operationally too complex for human operators has spurred great interest in the development of advanced computerized operator aids. The capability of designing reliable automated control systems has changed the definition of the operators role. In the modem 6 conttol room ( or the cockpit) an operator is assuming more sophisticated decision making roles and delegating traditional operations tasks of monitoring sensor data and manipulating certain controls to computer aided systems. Such advances are useful in reducing the information overload on the operator allowing increased opportunity and resources to effectively perform the cognitive tasks.
1.1.2 Overview of the TM I-2 Accident
The analysis of the TMI-2 accident presented here is based an account of the accident published in the Kemeny commission report [Kemeny 79]. Prior to the accident, TMI-2 operating personnel were performing certain maintenance operation which probably caused the trip of both the main feedwater pumps at 4:00:37 s.m. on March 28. 1979. The sequence of events during the first 12 seconds of the incident is shown in Figure L
The opening of the PORV is an expected event following loss of FW and is expected to close after the pressure reduces. In this specific incident the PORV
failed to close although the valve position light in the control room erroneously
indicated that it had closed (the valve position light really indicates whether the
valve solenoid is energized). The stuck open PORV resulted in a loss of coolant
accident (LOCA). Despite several indirect indications of an open PORV and
presence of symptoms of a LOCA the problem was not detected for almost 2-1/2
hours. Figure 1: Sequence of Events during the first 12 seconds of the TMI-2 Accident
Loss of All FW to Steam Generators y
autocxtioTis
Turbine Trip loss of coolant supply
loss of steam removal V Loss of RCS Heat Removal
Increase in RCS Pressure
Reactor PORV Shutdown Opens
Heat Generation Reduces
RCS Pressure Decreases 1 PORV Fails to Close
LOCA1 8 Once the pressure dropped to 1650 psig h i^ pressure injection was started to add coolant to the reactor. With the PORV open the reactor pressure continued to decrease. Due to the continued loss of coolant through the PORV and decay heat generation, the RCS temperature remained constant With the decreasing pressure and constant temperature of the RCS, the coolant density in the reactor started decreasing causing a h i^ pressurizer level Assuming that sufficient coolant was in the reactor, the operators reduced the high pressure injection and increased the letdown flow to keep the pressurizer level within the specified limits which caused more coolant to be lost from reactor than injected, a condition that existed for about 3-1/2 hours. During this period steam voids accumulated in the reactor causing the core to be uncovered and high temperature leading to cladding
(zircaloy) and steam reaction producing hydrogen gas. The non-condensible hydrogen gas bubble in the reactor made it difficult to reestablish high pressure injection after the PORV was closed. About 16 hours after the beginning of the accident the plant was repressurized and forced recirculation was reestablished thus placing the plant in a stable cooling mode.
Estimating the impact of the accident on the core the Kemeny Commission concluded that a large fraction of fuel rod cladding (90 % or more) was damaged,
30 -40% of fuel may have sustained temperatures in excess of 4000 F, some of the fuel may have melted, considerable amount of radioactivity escaped from the fuel to the coolant, the containment building, and the auxiliary building. Radioactivity release to environment was insignificant The problem at TMI-2 can be attributed to the following factors
L Equipment Malfunctions Equipment failure was responsible for initiating the accident and contributed to the failure of the operating personnel Specifically, clogging of the condensate polisher required the unclogging repair action which resulted in the shutdown of condensate pumps and subsequent trip of main feedwaterpumps Finally, the failure of the PORV to close was the primarily cause for the LOCA.
1 Inadequate Operating Procedures Evaluation of TMI-2 operating and emergency procedures revealed that some of the procedures were deficient and could have caused confusion or incorrect operator action. Some of the significant deficiencies were:
• Omission of Critics! Steps: The procedures for the loss of both the feedwater pumps and the turbine trip specify that the PORV will open but do not a require a positive verification of the status of the PORV. Further, none of the procedures required the operator to verify that the PORV was closed after a decrease in pressure following a pressure transient that would exceed the PORV set point.
• Conflicting Objectives: Some of the procedures emphasized avoiding equipment damage (in accordance with the technical specifications), and maintaining plant availability, but ignored the critical safety goal such as avoiding the uncovering of the core.The procedure for Reactor Coolant Pump Operation precludes pump operation with excessive vibration even under low pressure LOCA condition. Had it not been for this procedure the uncovering of the core at TMI-2 could have been delayed thus reducing the extent of core damage. The Pressurizer Operation procedure prohibits the pressurizer from going solid (a technical specification requirement) which forced the operators at TMI-2 to cut-back coolant injection into the core.
• Inadequate Diagnostic Guidance: In some of the procedures the diagnostic information was confusing and inaccurate, or For example, the procedure for reactor trip did not require the operator to find the cause of the trip and correct it. The procedure for LOCA lists ten symptoms including decreasing pressurizer level During the TMI-2 accident except for decreasing pressurizer level all other symptoms were present. Since the 10 pressurizer level was high the operators at TMI-2 were unable to conclude that a LOCA was occurring.
3. Failure to Diagnose Problem: During the accident the operator failed to diagnose the cause of the accident (stuck open PORV) and the immediate effect (LOCA). There were several indications of an open PORV such as high outlet temperature alarm for the PORV and a pressurizer safety valve which occurred 30 seconds into the accident, another pressurizer safety valve h i^ outlet temperature alarm which occurred 1 minute into the accident, and the increasing pressure of the reactor coolant drain tank into which the coolant from the open PORV is collected. Similarly there were several indications that the core inventory was low such as high in-core thermocouple reading, h i^ out- of-core neutron flux levels on the source range, low reactor pressure and constant temperature following the actuation of HPI, h i^ reactor building sump leveL etc. Operators ignored the h i^ outlet temperature alarm because these valves were known to be leaking. They ignored the thermocouple reading under the belief that thermocouple are often inaccurate. They failed to seek other corroborating information because, first they did not suspect, and second the diagnostic guidance was confusing.
4. Failure to Follow Procedure: During the accident operators failed to follow some of the procedure steps. Following the loss of both feedwater pumps the immediate actions of the emergency procedure require the operator to manually trip the reactor which the operator failed to do. The procedures for turbine trip and loss of feedwater pumps require the operator to verify that emergency pumps are running and delivering water to the steam generator. Operators failed to notice that water was not being delivered to the steam generators which subsequently caused the steam generators to boil dry. Even after the emergency water restored the steam generator leveL the steam generators were not effectively used to remove decay heat from the reactor coolant system.
5. Inadequate Equipment Design: In certain situations the equipment design was found to be inadequate and partly responsible for the accident. Specifically, the condensate polishing system instrumentation and control did not have adequate fail-safe features, and the PORV position indicator is not an indication of the valve position but merely an indication of whether the PORV solenoid is energized or non The 11 PORV is also intended to be used for avoiding scram during normal transients putting more demand on the PORV and increasing the chance of failure.
The Kemeny Commission also found inadequate training, lack of human facmrs consideration in control room design, and failure to learn from past incidents at other plants as contributing causes of the TMI-2 accident.
1.1,3 TM I-2 Lessons Learned
Review of the TMI accident by NRC staff identified that there is a need to make improvements in the areas of human factors engineering as it relates to control room design: qualification and training of operations persons to reduce human errors and handle unforseen situations; int^raticn of human element in the design, operations, and regulation of safety systems; and quality assurance of operations [USNRC 79]. The NRC task force specifically called for improvements in the design and implementation of emergency procedtires, and in the man- machine interface. The design of emergency procedures was required to take into account system interactions. It was also recommended that procedures should be unambiguous and useful in crisis control Proper int^ration of control room displays, procedures, and operator actions was also recommended. The role for sophisticated computer application to aid the operator in monitoring and diagnosis was also recognized. NUREG-0585 also calls for a more effective implementation of defense-in-depth philosophy for reactor operations and emergency response. 12 Most of the design changes following TMI were focussed on improving the human factors in the control room and development of a safety parameter display system to aid operator in monitoring the safety status of the reactor. It was recognized that apart from safety status monitoring aid there is a need for a cognitive aid to assist the operator in the diagnosis of malfunctions and selection and execution of appropriate emergency procedures [USNRC 81]. The need for a knowledge based decision aid was also recognized by the Advisory Committee on
Reactor Safety [Shewmon 82].
1.2 DYNAMIC PROCEDURE SYNTHESIS - AN OVERVIEW AND RESEARCH ISSUES
The objective of the proposed dynamic procedure synthesis (DPS) approach is to generate executable and successful corrective actions in runtime. The need for runtime processing arises because a nuclear power plant is a complex dynamic system, and it is not possible to enumerate all its states or anticipate all its responses. Furthermore, it cannot be assumed that a properly selected corrective procedure will be successfully executed, thus there is a need for a runtime procedure modification or failure recovery. The DPS approach provides a framework to synthesize procedures in the NPP and the other piocess plants to control unanticipated incidents by synthesizing procedures in response the dynamic situation while preserving certain prespecified high level objectives. 13 The DPS framework provides a guideline for building the library of predefined plans, specifies the indexing mechanisms, and the problem solving mechanisms. The library of predefined plans consists of hierarchical descriptions of weU tested plans and their alternatives. All plans have a unique name and most of them also specify the goals to be achieved by their execution. The indexing or plan selection mechanism consists of indexing by goals, indexing by a plant state, and retrieval using the unique name of the plan. To select the initial plan a set of goals and events or incidents are defined. The plant status is continually monitored and the plan associated with the occurrence of an event or a threatened goal is selected. This initial plan is expanded and analyzed to determine if it is executable. Analyzing executability is a complex operation and requires checking that all the critical systems required by the plan are fimctionally available, and that no two plan steps conflict An executable plan is then executed by executing each of the plan steps and checking the success of each step after the execution.
If a plan step fails then either an executable prespecified alternative is selected or another plan is selected to achieve the goals to be achieved by the failed plan step.
The framework specifies how to represent and organize domain knowledge in terms of plans, plant states, and goals. The framework also outlines a theory of how to apply domain knowledge and problem solving strat^es to synthesize procedures for both anticipated and unanticipated plant conditions. The knowledge organization and problem solving principles developed specifically address the 14 runtiine procedure synthesis problem in knowledge rich domains where a significant number of well tested procedures and their alternatives exisL Also the procedure synthesis is driven by the need to achieve a single plant objective such as plant safety. A h i^ level programming language has also been developed to enable
engineers to develop practical systems using the the procedure synthesis framework.
The DPS framework has been used to design a new integrated approach for synthesizing emergency procedures for a BWR. The int^rated approach is designed
to effectively utilize the existing event and function oriented approaches by providing the capability for runtime procedure modification, failure recovery, and
defense-in-depth philosophy. The int^rated approach utilizes the event and symptom based procedures whenever possible. Unanticipated incidents which cannot
be diagnosed are controlled by maintaining the safety functions. To implement the
safety functions maintenance a hierarchy of safety goals is developed. In the
hierarchy of safety goals the lower level goals are meant to control the status of
safety subsystems. The higher level goals are the well recognized safety functions
[Corcoran 81]. The hierarchy of safety goals effectively implements the defence-
in-dcpîh philosophy to reactor safety as applied to emergency response
management The emergency procedures are synthesized in runtime and modified
dynamically to provide effective control of the off-normal incident The approach
proposes to first control an off-normal incident at the subsystem level, failing
which actions at the system level and subsequently control actions at the plant
level are taken. This feature assures that every attempt is made to minimize the 15 consequence of the incident by localizing it at the subsystem level without significantly compromising the system safety.
The FEPS implementation for a BWR is tested for several off-normal transients to evaluate the feasibility of applying the knowledge based approach for runtime procedure synthesis in practical applications . Specifically, the objective of the evaluations performed is to verify the functionality of the procedure qmthesis framework, he., various aspects of procedure synthesis and runtime procedure modification, determine the adequacy of knowledge representation and organization principles, evaluate the procedures synthesized by the int^raied approach, check that the integrated approach follows the defense in depth principles, and finally to collect data on the operational performance of the specific implementation.
1,2.1 NPP related Design and Research Issues
In designing the migrated procedure synthesis approach several research issues are addressed. The focus of the work reported here is the maintenance of safety.
Most process plant and power plants have to meet various operational and productivity goals along with the safety goals. In order to resolve the conflicts between various goals it is essential to understand the relationship between the various goals and to define priority criteria. In the NPP whenever the safety of the plant is in question the safety goals always take priority. 16 During an off-normal situation a procedure can be selected using either the event based approach, symptom based approach or the safety function based approach. A framework is required to integrate the three approaches providing a unified approach to select the procedures. The framework should identify the interrelationship between the three approaches and provide an unambiguous guidance in selection of procedures and transition from one approach to other. The motivation behind using an integrated approach is to take advantage of the predefined optimal event and symptomatic procedures and to use safety goal or function procedures to respond to unanticipated incidents. It is, therefore, required to define a set of safety goals, a goal structure and a systematic approach to determine which safety goals should be achieved to enable effective control of unanticipated incidents within the runtime constraints. In effect, the goal structure should be a type of skeleton plan to assure the safety of the plant.
Sometimes it may be required to respond to multiple events or goals requiring that more than one procedure be selected and executed concurrently. Since the actions in concurrent procedures may produce conflicting changes in plant state, a principled approach is required to handle such situations. Executing a selected procedure is a non-trivial task requiring problem solving to select action steps, verify their success, and find an alternative if the action fails. There is a need for a systematic approach to provide guidance in procedure execution and monitoring the results of the execution. In case a procedure fails, a systematic domain specific approach is required to decide on the actions to be taken. 17 The event based and symptomatic approaches require limited diagnostic capability. Once a procedure is selected a detailed plan can be synthesized. In synthesizing the detailed plan it is possible to eliminate certain plans or actions because it may be known that they will not succeed if tried. Determining the potential success or failure of a plan based upon its current failure mode calls for more sophisticated diagnostic capabilities. Given that sophisticated diagnostic capability is available there is need for a systematic approach to int^rate the functioning of the d i^ o stic system with that of the plan synthesizer. In principle it is also possible to predict the results of an action if executed and reject the action if the results are undesirable. How to build a reasoning system that can predict the effects of certain actions and how to integrate its functioning with the plan synthesizer are also relevant issues.
1.2.2 AI related Design and Research Issues
In designing knowledge based systems it is required to specify the search space, the problem solving mechanisms, and principles to organize the domain specific knowledge. Specification of search space requires defining an organization of predefined plans. In the domain of the NPP, the plans in the search space should be represented such that they specify various types of sequencing of more primitive procedures and often also specify alternative plans. The sequencing of the primitive procedures specify the order in which they are to be executed and also provides a control over the the search for alternative actions. 18 Following the specification of the search space it is required to design an indexing mechanism to efficiently access the relevant plans in runtime. For the
NPP domain and other process industries it is desirable to index the plans based
on the state of the plant and the goals to be achieved. An adequate representation
for plant states and goals is also needed. Since the runtime search can be expensive
it should be possible to find the intial plan using a few predefined plant states
and goals. Once a plan is selected several problem-solving tasks are required to
dynamically synthesize, execute, and modify the plan. Identification of distinct
problem solving tasks is necessary because each problem solving task may use
different forms of knowledge and control mechanisms for efficiently solving the
specific task.
The problem solving mechanisms utilize domain specific knowledge to perform
specific tasks. One of the key design issues is the identification and representation
of relevant domain knowledge. Although the knowledge can be represented in
various ways it is desirable to design a knowledge organization approach for
computational efficiency and a representation approach to enable coding at an
abstraction level consistent with application of the knowledge to the problem. This
requires defining appropriate knowledge primitives to describe plans, plan
sequences, ^stem states, goals, and various aspects of relevant system feature, and
an appropriate language to construct complex pieces of domain knowledge in terms
of the defined knowledge primitives. 19 1.2.3 Scope and Limitations of the Study
Assisting an operator in coping with an operational emergency requires a variety of tools: an ergonomically sound control room design, a well designed operator training pit^ram emphasizing both the ^^tem specifics and fundamentals, a set of well designed operating procedures, diagnostic support systems, sensor data validation systems, and other decision support qrstems to aid in the knowledge based reasoning The subject of study in this dissertation are the knowledge intensive tasks performed by an operator that require reasoning In section 3.2 we have identified several types of reasoning tasks performed by an operator of a
NPP. However, in this dissertation we have studied only those tasks that relate to emergency procedure selection, execution, and runtime procedure modification.
Research needs for other reasoning tasks are discussed in Chapter 6.
In this study our emphasis has been on developing a conceptual framework for accomplishing the dynamic synthesis of emergency procedures in a NPP. The development of the framework is based on a task analysis of an expert operators response to an emergency situation in a NPP. An operators task in responding to an emergency situation is to effectively use the predefined procedures rather than design new optimal procedures. Thus DPS provides a systematic approach to use the knowledge of predefined procedures to synthesize executable procedures for anticipated and unanticipated situations. The problem solving in DPS is knowledge driven based on AI concepts. At the present stage of development, DPS lacks 20 problem solving capability to predetermine that the synthesized procedures will produce desired results. The success of the synthesized procedures is based on the assumption that the predefined procedures are designed to be effective. Research directions to overcome this limitation are discussed in Chapter 6.
The DPS approach is demonstrated by using it to develop a framework for emergency response (FEPS) for a Boiling Water Reactor. The FEPS framework int^rates the optimal event and symptom oriented procedures with the more effective and conservative safety function maintenance procedures. The FEPS is not simply a computer based implementation of the existing emergency response approaches. FEPS incorporates two basic enhancements. First, it is based on DPS and thus includes a systematic approach for procedure selection, a refined procedure execution logic, and runtime procedure modification capability to handle procedure failures and unanticipated failures. Second, instead of a few safety functions it utilizes a hierarchy of safety goals to achieve what safety function maintenanace procedures do to implement the defense-in-depth philosophy, and to achieve a better integration with the event-oriented procedures.
The implementation of FEPS described in this dissertation considers only a few selected safety goals, events and symptoms. The purpose of the implementation is to demonstrate the features of the procedure synthesis framework and an example of how it can be applied to a practical problem. The BWR data and procedures used in the implementation are based on existing reactors and represent 21 a typical plant rather than a specific plant. We have not performed extensive testing which is proposed for future work-
1.3 THE ORGANIZATION OF THE DISSERTATION
In Chapter 2 the existing approaches used in nuclear power industry are reviewed. The event-oriented and function-oriented approaches are analyzed and their advantages and drawbacks are discussed. Design of computer based operator aids for NPP has been an active area of research. These operator aids are intended to overcome some of the drawbacks of the written procedures, respond to the recommendations of NRC and improve the productivity and safety of the plant.
In Chapter 2 significant concepts in NPP and AI for operator aid design are discussed.
In Chapter 3 a theory for dynamic procedure synthesis is developed. First, a task analysis of an operators actions in responding to an abnormal event are analyzed. Based on the analysis we have defined the problem solving requirements for a solution. Then, a knowledge based approach is developed for procedure synthesis. Chapter 4 describes the knowledge organization and representation
framework required for the DPS theory. It also describes a high level programming
language (DPSRL) to help design prototype systems. 22 Chapter 5 describes a framework for emergency procedure synthesis (FEPS) based on the DPS approach. The organization of plans and a safety goal hierarchy for a BWR are described. The discussion in the chapter is supported by the examples from an implementation of a prototype using DPSRL. Chapter 5 also describes an evaluation process and describes results of an evaluation of the FEPS approach.
In Chapter 6 we discizss the major conclusions and direction for future work.
Appc.idiX A shows examples of a few selected procedures used in the implementation of FEPS. Appendix B shows results produced by the FEPS program for selected cases discussed in section 5.4. CHAPTER 2
BACKGROUND
In the previous Chapter human error was emphasized as one of the key factors responsible for several industrial accidents. It was discussed that modem technological systans have become extremely complex, and that there is a need for knowledge based operator aids to help in safe and productive operation. In the nuclear power industry and other technologically advanced industries the operator aid is currently provided throu^ extensive training and written operating guidelines. It is now widely recognized that these traditional devices are not always adequate in responding to complex and iinfamibar situations. Realising this there has been a growing interest in advanced computer based operator advisory systems
[Rouse 84].
In this chapter the existing emergency response approach in a NPP is reviewed. The existing approach of using written procedures for responding to events and maintaining safety functions is analyzed and the drawbacks are discussed. In NPP and other similar domains, the development of advanced operator aids is an active research area. In this chapter we review some of the key operator aid concepts and discuss their relevancy to solving the practical problem of generating emergency procedures.
23 24 2.1 EXISTING APPROACHES FOR EMERGENCY RESPONSE IN NUCLEAR POWER PLANTS
Prior to the TMI accident the implementation of emergency procedures was based on event-oriented approaches. In an event-oriented approach procedures are developed and defined for a selected set of component malfunctions or events.
During an off-normal condition the operator tries to find the responsible component malfunction and select the associated procedure. The TMI accident
demonstrated the limitations of a purely event-oriented approach resulting in the development of several alternative approaches. Two basic types of alternative approaches currently used are: qrmptom oriented, and function oriented. In the symptom-oriented approach procedures are defined to respond to a set of
symptoms which indicate an abnormal condition (but not a specific component malfunction). The state approach developed in France is a type of symptom-
oriented approach [Sureau 84]. In the state approach procedures are defined to
take the plant from an unsafe operating r%ion characterized by a set of critical
state variables to a more stable operating state. In the function-oriented approach procedures are defined to maintain a selected set of safety functions. In the
nuclear power plants the general trend is to use the event-oriented approach in
conjunction with one or more of the alternative approaches [Mancini 84]. 25 In this section various approaches to the emergency procedure design and selection are reviewed, the conceptual and implementational drawbacks are discussed, and the need for an improved framework for emergency procedures is proposed.
2.1.1 Event-Oriented and Symptom-Oriented Approaches
The widely used approach in nuclear power plants and other process industries for selecting emergency control procedures is to recognize the observed system response in terms of predefined symptom patterns and select corrective actions associated with the recognized symptom set When the recognition of a symptom sets are defined to be the manifestations of specific component failures then the associated procedures are designed to compensate for the failed component or mitigate the consequences due to the failure of the component Selecting a procedure by identifying the failed component is called eve/rf oriented approach
[Mancini 84]. Sometimes it is not possible to diagnose the responsible failed component but it is important to respond to a specific set of symptoms. The process of selecting procedures by recognizing a specific set of symptoms not diagnosable to any component malfunction is called symptomatic approach
[Mancini 84]. Presently both the event and symptomatic approaches are in effect implemented as a table of selected symptom patterns and associated recommended actions. Both the approaches for selecting procedures have the following drawbacks: 26 • They fail to respond to unanticipated incidents, specifically the multiple failures. Using these approaches to cover all possible significant incidents requires using a very large table of predefined procedures. For most applications such a table of procedures will be combinatorially explosive.
• Diagnosis of some events, especially multiple failures, may require detailed analysis of sensor data during runtime which can be very inefficient for complex systems like a nuclear power plant
• Based on sensor data it may not be possible to reach at an unambiguous di%nosis because different incidents can produce similar symptoms, especially in the case of multiple failures [vonHerrmann 83a].
• The procedures designed for pre-defined incidents presume the system to behave in a predictable fashion [vonHerrmann 83a]. Any departure of the system response from the expected behavior causes the procedure to be inapplicable, and
• In general the capability to recover from the failure of the selected procedure is limited.
2.1.2 Function-Oriented Procedure Selection
After the TMI-2 accident, the need for improved emergency procedures was widely recognized. Specifically, it was recommended that emergency procedures should enable operators to respond to multiple failures, aid the operator in maintaining safety functions without the need for diagnosis to respond to unanticipated incidents, and that procedures should be unambiguous [USNRC 83].
In essence the need to develop an emergency procedure framework that does not depend upon di%nosing pre-defined events was emphasized. To implement the recommended improvements the nuclear industry in United States alimented the event-oriented and symptomatic approaches with a function-oriented approach 27 [vonHerrmann 83a]. The function-oriented approach is based on the concept of maintaining critical safety functions during all modes of operation of the plant, and specifically during the duration of the transient. The basic assumption is: For certain system objectives (such as plant safety) it is possible to define a li-miTPfi set of key system luncuui» aueii îhai the system objective is achieved (e.g.. plant safety assured) if the key system functions are successfully performed. The concept of maintaining safety functions is attractive because it is possible to define a small set of critical safety functions to cover the virtually imiimirAH number of events.
An event is significant and requires operator action because it can challenge one or more of the safety functions. If the operator is successful in maintaining the safety functions then plant safety is assured irrespective of the cause of the incident
Another advantage of the safety function maintenance approach is that to monitor the status of the safety functions a relatively small amount of information needs to be analyzed for selecting a procedure. The existing implementations of the function-oriented approach have the following drawbacks:
• due to limited amount of sensor data diverse accident conditions exhibiting similar symptoms can result in ambiguous diagnosis of key functions [vonHerrmann 83a], and
• since only a few key functions are to be performed, the transition to the function-oriented approach is usually too rapid leading to inefficient (althou^ effective) actions. 28 2.1.3 Existing Int^p*ated Approaches
In United States integrated approaches have been developed by all the four vendors. In all these approaches abnormal or off-normal anticipated transients are responded to by using an event-oriented approach. To handle unanticipated situations Westin^ouse, Combustion Engineering, and General Electric emergency operating procedures are based on a function-oriented approach, whereas the
Babcock and Wilcox emergency operating procedures are based on a symptom- oriented approach.
In the Westinghouse approach the function-oriented response consists of ei^teen pre-defined procedures to maintain six critical safety functions:
Subcriticality, RCS Integrity, Core Cooling, RCS Inventory, Heat Sink, and
Containment Integrity. The logic to monitor the status of safety functions and to select a specific procedure is specified as simple logical combinations of a few parameters such as reactor pressure and temperature [vonHerrmann 83a]. The CE approach to function-oriented response addresses four safety functions: Reactivity
Control, RCS Heat Removal, RCS Inventory, and Containment Integrity [CE 81].
The GE approach defines two major procedures to maintain safety functions with several contingency procedures to handle special cases [GE 81]. The RPV Control procedure is entered when specific symptoms are observed with the objective to maintain reactivity control, pressure control, and level control Similarly the
Containment Control procedure is intended to maintain the primary containment 29 temperature, pressure, and level within acceptable limits. The Babcock and Wilcox approach is based on tracking the values of pressure and temperature. Based upon the values of pressure and temperature the operator can detect the occtnrence of an undesirable heat transfer condition and is guided to corrective actions. An abnormal incident is cousiucfcu to be under control if the pressure and temperatures have desirable values [B & W 80] The principle underlying the development of the existing emergency operating procedtires can be stated as a two step approach:
L if the specific event can be identified then use an event specific procedure for optimal recovery,
1 if the event cannot be identified, or the procedure is not defined, or the defined procedure fails to produce desired effects then maintain the critical safety function.
In practiœ both event diagnosis and monitoring of safety function status is reduced to simply monitoring certain symptoms. The practical approach to selecting an emergency procedure thus becomes simply one of monitoring pre-specified symptom sets and selecting associated procedures [vonHerrmann 83a]. This simplistic approach is considered to have the advantage of not requiring the operator to be aware of the specific event which has occurred or the challenged safety function [vonHerrmann 83a]. This is in fact a major drawback since the knowledge of a specific event or the challenged function is critical to finding procedures for multiple failures or alternative actions for failed procedures.
Specifically, the existing implementation of emergency procedures have the following drawbacks: 30 • Although the design of procedures is based on sound principles the use of procedures in the control room lacks a principled framework to enable the operator to deal with multiple failures and the failure of rœommended procedures.
• As discussed above, the current implementations can be reduced to a simplistic table lookup strategy of matching symptom patterns and selecting associated procedures. The knowledge of an event or a function is used in designing the procedures. The selection and execution of a procedure in the control room ignores the basic cause. We believe that the knowle^e of specific event and failure modes of components can be effectively used to eliminate procedure steps that might fail if executed.
• Whenever the event-oriented approach breaks down it is assumed that the function-oriented approach will adequately handle it. The function oriented approach uses a few system level functions. Thus no matter how the event based procedure fails the current approach will always select procedures to maintain system level functions. In some cases a more optimal approach would be to maintain a subqrstem level or a component level functicn. The need to consider more than just the few safety functions is emphasized in this dissertation.
• The current approach lacks an adequate method for failure recovery from the selected procedures. In the current approach if a procedure fails then an adequate alternative has to be specifically prescribed. If the prescribed alternative also fails then there is no principled approach to find an adequate alternative.
• The written procedures can often be ambiguous [Kemeny 79]. There is a need for a principled approach to guide the operator in executing the procedures and evaluating the success or the failure of procedures.
In summary there is need for a better approach to enable runtime synthesis of optimal and effective procedures, to enable runtime recovery from failures in an optimal and effective manner, and to assure in practice compliance to the defense-in-depth philosophy. 31 2.2 OPERATOR AIDS IN NUCLEAR POWER INDUSTRY
The potential and need for computer based decision making operator aids to help operators cope with the operational complexity of nuclear power plants and produce safe and economical nuclear electricity has long been recognized [Bullock
69]. Some of the early efforts to introduce computer based aids in nuclear power plant were abandoned because the application requirements exceeded the capability of existing hardware technology. Use of computer based operator aids in the control room was discouraged because of the lack of safety qualified hardware and a general distrust towards software reliability. Following the TMI accident the need for computerized decision aids was once again recognized and significant efforts are being made by the industry [Long 84] [Lewis 85], and the NRC to utilize advanced computerized decision aids for appropriate applications [Taylor 85].
To effectively operate a nuclear power plant operator aids are needed for both normal and off-normal operations. During normal operation the primary operational task is to monitor the status of various safety and non-safety systems, and perform normal start-up. power changes, and shutdown operations. For normal operations operator aids are required to provide the operator with better access to pertinent information and control mechanisms for plant start-up, normal operation power changes, and shutdown. The need for better access to plant status information is partly addressed by the new human engineered design of display of 32 sensor data and alarms in the modem control rooms, however, the need to int^rate the displayed information with the controls, procedures, and operator constraints still esists [Sheridan SG], Some of the normal operating procedures such as plant start-up, shutdown and control rod position manipulation to change power level are sufficiently involved, and require significant skill and reliance on operators memory and training. The need for operator aids for these tasks is well recognized. An approach for changing control rod position to manipulate power based on early research in artificial intelligence in heuristic programming and learning was developed by Macdonald and Koen [Koen 75]. A knowledge based approach has been proposed to aid an operator in plant start-up for a boiling water reactor has been developed by Nishizawa et al [Nishizawa 83]. A design of knowledge base and its application to reactivity control using reactor control control heuristics has been described by Bernard [Bernard 86].
During an off-normal incident the operator is confronted by the problem of observing and interpreting the enormous amount of sensor data, verifying the correctness of the data, and making decisions on the nature of the problem and necessary corrective actions. Unlike the normal operating modes where the primary operator response is skill and rule based [Rasmussen 79], the operators response during off-normal conditions is knowledge based. The role of computer ^ tem s as knowledge-based decision aids to the operators is supported by the Advisory
Committee on Reactor Safety [Shewmon 82]. In order to make correct decisions the operator has to perform two basic tasks: 33 • Identify the nature of off-normal incidents,
• Select and successfully execute corrective actions to bring the plant to safe shutdown status.
Identification of the nature of the operational problem requires monitoring, interpreting and comprehending plant data, verifying that the sensor data is correct.
Le., signal validation, detecting off-normal condition, and if possible diagnosing the malfunction. Selecting and executing a successful corrective action requires capability of procedure selection, reasoning about the potential effect of the procedure on plant status, and synthesizing a new procedure if required.
Responding to off-normal situations is knowledge based in the sense that it is not possible to enumerate all possible strat^es to control the plant for any potential off-normal incident. The operator has to use his knowledge about the plant and his experience to reason in runtime to determine what actions should be taken for the specific off-normal situation.
2.2.1 Monitoring, Detection and Diagnosis Aids
Development of certain operator aids initiated before the TMI accident were motivated by the fact that the information displayed hr the control room is not adequate to prevent spurious or avoidable plant shutdowns [Meijer 81]. Spurious shutdowns are often caused by sensor malfunction and human error. Avoidable shutdowns are those due to operator controllable transients. Thus the need for signal validation, sensor malfunction detection, and quick transient identification was recognized. 34 The significance of early detection of malfunctions for plant availability and safety motivated some of the early basic research for real time diagnosis based on analytical trend analysis [Kanji 73] [Saxe 73], pattern recognition [Ina
73] [Gonzalez 73], system identification techniques [Fukuda 79], and decision theoretic methods [Saedtler 79]. In general the trend analysis and identification methods depend upon using an abstract mathematical model to describe some aspect of reactor response.
The parameters of the model are estimated using plant specific operational data. An off-normal situation is detected when either the response of the reactor deviates from that predicted by the model by more than a pre-defined margin, or certain parameters of the model estimated using current plant operation data deviate from normal parameter values by more than a prespecified margin. These methods can be made highly sensitive and efficient in detecting departure from normal plant response. However, whether the departure really implies an abnormal plant condition has to be interpreted by the operator. Althou^ in principle it is possible to prepare a catalogue of abnormal plant conditions and the expected changes in model parameters, such a strategy will be difficult to implement in practice and the reliability of the results obtained from such an approach is also questionable.
The problem of interpreting the results of an abstract model can be solved by pre-specifying failure interpretations to changes in the plant state using domain 35 specific knowledge. Fault trees specify the logical relationship between a pre defined system failure and component failure states. It has been suggested that fault trees can be used for diagnosis [Lambert 77], however, fault trees can only help diagnose specific malfunctions for which they are defined. Moreover, fault trees do not provide an adequate model for the general diagnositic problem. Such a method would have obviously failed to diagnose the TMI accident. Another approach to help quickly detect the malfunction has been used by the designers of disturbance analysis system (DAS) [Meijer 80]. In DAS an abnormal transient is modeled as a logical relationship of cause and consequence plant states including time delays before the consequence is realized. This cause-consequence model is used to track the transient and suggest appropriate corrective actions to prevent a reactor shutdown. This approach is also lîmiîMi by the number of transients modeled and would have failed to control the TMI accidenL
Following the TMI-2 accident, on NRCs recommendation, safety parameter display systems (SPDS) were developed. The SPDS systems are intended to adequately display in the control room a minimum set of plant parameters to summarize the safety status of the nuclear power plant [Joyce 83] [Long 84]. The
SPDS enables the operator to monitor a few selected sensor values critical to plant safety and determine if the safety status of the reactor is being compromised. The
TMI-2 accident emphasizes the need to preserve the safety status of the plant even if the exact malfunction cannot be diagnosed, thus rekindling the interest in safety functions as applied to the plant operation. The need to monitor the availability of 36 safety systems, and the status of plant safety functions [Corcoran 81] lead to the development of critical function monitoring systems (CFMS) [Meijer 84].
Recognizing that the diagnosis of complex systems is essentially a knowledge based task and inspired by the success of knowledge based systems in the medical domain [Buchanan 84] several prototype expert systems have been built for the diagnosis of nuclear reactor malfunctions. A rule based system was developed by
Nelson to model the response tree logic to identify specific plant states and select associated procedures [Nelson 82]. An expert system developed by Underwood utilizes predefined networks of causes and effects to diagnose system malfunction
[Underwood 82]. Based on their work on medical diagnosis Chandrasekaran et al developed an expert system using the MDX approach [Chandra 82a]. In the MDX approach the diagnostic hypotheses are organized as classification hierarchy of specialist nodes where each specialist has knowledge on how to establish the specific hypothesis [Gomez 79] [Chandra 82b]. The diagnosis is performed by matching the top specialist in the hierarchy against the plant data to determine if the plant data can support the hypothesis or establish it If the top node is established then it is refined by matching its sub-nodes gainst the plant data. An approach for diagn?^ by comparing the plant data with the expected data from a simulator has been developed [Motoda 85] which first used cause consequence relationships (expressed as rules) to enumerate all possible malfunctions that can potentially account for the difference in the plant data from expected values. The set of possible malfunctions are then analyzed to reduce the number by checking 37 for inconsistencies and comparing with simulation results. Finally, tests are proposed to help discriminate between remaining defects.
Detection of abnormal plant state and diagnosis is done to find an appropriate corrective action. The work on DAS, CFMS, and Response Trees was motivated by identifying a pre-defined abnormal plant state and then executing pre-defined corrective actions or success paths associated with the abnormal state to control the reactor response. This problem of selecting control procedures is discused in detail in next section.
2.2.2 Selection and Synthesis of Control Procédures
The problem of generating corrective actions can be viewed as task of generating an ordered sequence of pre-defined control actions or a control plan.
Much of the early research in planning has been done by researchers in the field of Artificial Intelligence (AI).
AX Approgches to Planning
The basic approach for generating plans is to define a search space of primitive plans and an indexing mechanism to search for appropriate plans from the search space. Some of the earlier planning systems were based on the idea of means-ends analysis [Nilsson 79] [Simon 72]. In the means-ends analysis the initial state and the goal state of the system are examined, and an indexing mechanism is used to 38 find plans or operators to achieve the goal state. In STRIPS the search space consists of a list of plans or operators, their preconditions, and effects. The indexing mechanism first tries to identify all operators whose effect is the goal state and examines their preconditions. If the precondition is not true then preconditions become the new goal leading to another set of operators thus defining a plan. In GPS the search space consists of difference reducing operators.
The indexing mechanism uses the difference in the initial state and the goal state as a key to find an operator that would reduce the difference. Once again the preconditions of the candidate operators become the new goals and lead to another set of operators. The basic problem with mean-ends analysis is that although it constrains the search space by only examining subgoals indicated by the preconditions of the relevant operators, it can still lead to very large search spaces for practical problems where the length of individual plans is nontrivial One of the reasons for this problem is that the planning systems based on a pure means- ends analysis do not have a good source of information to decide which operators are likely to succeed [Sacerdoti 77].
NOAH (network of action hierarchies) is an integrated approach for planning and execution monitoring [Sacerdoti 77]. NOAH contains three types of knowledge: task specific knowledge about the allowed actions, the world model or the knowledge about a particular situation in the particular domain, and the general problem solving knowledge on how to select a plan, expand it, and construct a valid detailed plan using various plan critics to analyze interactions 39 beDveen subplans. NOAH constructs a plan in a hierarchical fashion by analyzing and resolving subplan interactions at every level of expansion thus effectively reducing the search space. Initially, a problem is presented to NOAH as a goal to be made true. NOAH first finds a one step plan for the goal and expands it in terms of subgoals. Following the expansion it also develops a detailed model of the effects of every action in the plan. Before the plan is further expanded the effects of the actions are analyzed to identify conflicting interactions using both general purpose and task specific plan critics and reordering the actions to resolve the conflict
In most of the real world planning activities pursued by human experts it is possible to define skeleton plans or scripts to specify highly competent ways to achieve a goal A skeleton plan is a partial or an abstract plan. Such an approach has been used by one of the MOLGEN systems [Friedland 79] and in knowledge based understanding using scripts [Schank 77]. The prestored skeleton plans contain outlines for solving a variety of problems. The planning process consists of selecting a skeleton plan and filling in the details for the specific situation using various problem-solving operators and large amounts of domain specific knowledge.
Much of the research in planning has been devoted to problems with a well defined initial state, goal state, and a world model that does not change except in a predictable manner to the actions suggested by the plan. The focus of research has been the study of problem solving strat^es, and framework for representing 40 knowledge about plans and the world. In a nuclear power plant and other process applications the world model or the system state is dynamic and may change in unpredictable manner. Often the initial state and goal states are not completely specified and have to be inferred. It is also not possible to predict the effects of an action with complete certainty, and it may be required to modify a selected action if it fails to produce desired system response. The need for reasoning about goals and a sophisticated way to monitor plan execution and failure recovery is obvious. The problem of reasoning about goals during planning has been addressed in [Wilensky 83]. Only recently attention has been paid to the problem of plan execution and failure recovery of a plan during execution [Georgeff 85].
Planning Approaches in NPP
The procedure selection and synthesis work in NPP can be cat^orized by the
indexing mechanism used. There are essentially three types of approaches:
• selection by plant state,
• selection by goal, and
• simulation.
In the seiect/on by plant state approach a table of enumerated plant states of
interest and associated control procedure is used. The basic plan selection problem
requires classifying the plant state to match it to one of the enumerated plant
states. The current practice in industry of using event and symptomatic procedures
falls in this e a te ry . Several approaches to operator aids for event and 41 symptomatic guidance have been developed. The CFMS can be viewed as a plan selection system where the enumerated plant states are safety functions and the search space contains success paths [Meijer 84]. The approach of using response trees also falls in this cat^ory where the response tree logic is used to efficiently identify a plant stnia and the associated procedure [Nelson S2]. An operatcr support system for emergency systems has been developed to provide pre-trip guidance using a cause consequence tree approach similar to DAS and a post-trip guidance using a event and ^rmptom based approach [Murata 84]. A symptom oriented guidance approach has been reported which not only provides the basic operational guidance to bring the plant to a safe shutdown state but also assists the operator in determining operational priority of safety systems [Tanji 85]. A procedure selection and procedure tracking system has been developed by EPRI
[Cain 84]. The basic problem in selecting plans based only on the plant state is that the approach breaks down for plant states that are not predefined The problem of an unanticipated plant state can be addressed if the plant states are defined at a functional level such that all plant states enumerated or otherwise can be mapped into a set of enumerated functional states. The CFMS relies on this concept to achieve a better coverage of unanticipated incidents.
In the selection ty goals method a library of goals and procedures for achieving them are defined Indexing mechanisms are defined for retrieving procedures for a specified goal Emergency procedures for nuclear power plants developed following the TMI incident are designed to achieve certain safety goals. 42 In order to control unanticipated incidents an approach based on identifying a desired safety state for the plant and then selecting a procedure to take the plant from the current state to the desired safety state was developed and demonstrated for a model of a fast flux test facility [Seeman 83]. A hybrid knowledge-based system has been developed for achieving multiple goals in a situation where the effects of the actions are uncertain [Yufik 83]. The hybrid approach is based on generating a control plan to achieve various goals such that the subjective utility of the outcome is maximiTed. For every goal a sequence of actions and probable effects are predefined. The operator specifies the subjective utility for various goals. The control plan is then generated so as to maximize the subjective utility.
The selection by simulation approach is based upon tracking predefined scenarios of plant incidents. The DAS approach is an example of tracking predefined accident scenarios and recommending appropriate actions [Meijer 80].
An approach based on using petri-nets to model scenarios has been developed
[Gallanti 85]. A petri-net model of the scenario is used to track the state of a transient in the plant A petri-net is a network of nodes (which model plant states or conditions) and directed links between the nodes (which model transitions between the nodes). A transition takes place when all the input nodes are true.
Various operator actions are also modeled on the petri-net and are selected when appropriate plant state is reached. 43 Both the selection bv state and simulation approaches have the drawback that they lack a principled framework for generating procedures. For practical applications these approaches will have to use a very large library of predefined states and accident scenarios causing the timely selection of effective procedures in runtime very difficult The goal based selection approach can be effective if the number of goal states are finite and if the goal states can be predefined. In the demonstration study on fast flux test facility [Seeman 83] even for a small system of 18 components more than 8000 goal states were developed. Simple adaptation of such an approach to a large system is not a practical solution. Moreover, there exists a large number of well tested procedures that can be selected by identifying the state of the plant making it desirable to utilize an integrated approach of selection by state and goal based selection. In a practical situation it is often required to modify a selected procedure in response to the dynamics of the plant.
The approaches to date do not address the problem of procedure modification.
In the next chapter we describe an integrated approach based on the goal based and the selection by plant state approaches. The int^rated approach enables the utilization of efficient procedures for controlling the enumerated plant states
(such as event and symptomatic procedures), and provides capability to respond to unanticipated events by a goal maintenance procedures. The approach also utilizes a goal directed reasoning approach to recover from the failure of selected procedures. CHAPTER 3
A KNOWLEDGE BASED FRAMEWORK FOR PROCEDURE SYNTHESIS
Operating a complex system, such as a nuclear power plant, requires accomplishing several tasks such as monitoring the plant state, diagnosing an abnormal plant response, and selecting and executing appropriate corrective action.
For familiar abnormal conditions, the tasks of diagnosis and corrective action selection can be performed using the predefined procedures, however, unfamiliar abnormal situations require reasoning based on experience and the knowledge about plant systems and operations. For complex systems, unfamiliar situations exist because it is not possible to enumerate, a priori, all possible abnormal occurrences.
The TMl-2 accident clearly demonstrated that operating the plant is a knowledge based task requiring skilled and highly trained operators to use knowledge and reasoning in controlling the plant response during abnormal incidents. In recommending that the training program for operators should emphasize on improving operators level of knowledge about systems, operations and int^rating
44 45 the knowledge with the operating experience, the Kemeny commisiion recognized that operating a NPP is inherently a knowledge based task [Kemeny 79].
In this chapter we describe a knowledge based framework for synthesizing procedures in a nuclear power plant. First, a task analysis of an operators actions in controlling an abnormal event is described. The task analysis presented consists of: 1. an analysis of the task of controlling an abnormal incident, and 2. a characterization of the task performed by the operator. The objective of the task analysis as presented here is to identifv the various reasoning tasks required, and to identify the knowledge and its use in controlling an abnormal situation in a nuclear power plant. A specific abnormal incident in a nuclear power plant and operator actions to control the incident are analyzed in section 3.1 to identify:
• specific problems solved by an operator in controlling an abnormal incident and various tasks performed by the operator such as diagnosis, monitoring, and plan selection (see section 3.2.3);
• the nature of interaction between the tasks (see section 3.2.3),
• the nature of knowledge used by an expert operator to perform specific tasks (see section 4.2);
• the reasoning or the problem-solving required to perform the tasks. Le., how the knowledge is applied to perform the tasks (see section 3.2.3)
The task analysis is required to define what tasks the knowledge based system should be capable of doing and to understand how the knowledge based reasoning is used to perform the specific tasks. A knowledge level understanding of the task is useful in identifying and designing computational approaches appropriate for 46 solving the problem. The second part of this chapter describes an information processing model for procedure synthesis.
3.1 ANALYSIS OF THE TASK OF CONTROLLING AN ABNORMAL INCIDENT
Departure from normal operations condition requires execution of corrective actions. Identification of an abnormal state, selection or synthesis of corrective actions, and execution of corrective actions require an operator to perform various reasoning tasks, some of which are performed in runtime. In this section an analysis of various operator actions is presented. The analysis is based on a description on the selected transient in [vonHerrmann 83b].
3.1.1 Scenario: Loss of All Feed Water to a BWR
For specificity let us consider the scenario of a complete loss of Feed Water
(FW) to the reactor, an event which can potentially cause the melting of nuclear fuel Because this event has a potential for a most serious consequence, automatic control features and operator procedures are designed to respond to it. It is a normal practice in the nuclear power industry to identify such events and design control actions, both automatic and manual, to control them. 47 Figure 2 shows the sequence of events following the loss of all FW.
Immediately following the loss of FW the plant instrumentation and control system will detect changes in feed water flow and automatically reduce recirculation flow.
The loss of feed water flow also causes a decrease in the reactor vessel water leveL Within a few seconds the water level drops below a predefined low water level setting causing insertion of control rods into the core (Reactor Scram) and turbine/generator trip. The water level continues to decrease and reaches low-low level set point which initiates a recirculation pump trip, and the actuation of the high pressure coolant injection system (HPCS) and rector coolant injection. In this scenario we assume that the HPCS and RCIC systems fail to start Failure of the
HPCS/RCIC system requires that the water supply to the reactor vessel should be restored by other means failing which the core will uncover in about 30 minutes and eventually fuel will start melting.
3.1.2 Analysis of Operator Actions
In responding to this event an operator has to perform several tasks.
Normally, the sensor data from the reactor are continually m onitored to determine the operating state of the plant as being either normal or abnormal
Immediately after the loss of FW there are several indications of an abnormal incident such as the reactor trip alarm, recirculation pump trip alarm, loss of feed
flow etc. Thus, an operator will be able to detect that there is a problem. Plant state monitoring and problem detection is one of the first tasks to be performed by the an operator. 48 Figure 2: Sequence of Events for Loss of All FW
Loss of FW \ reduced Recire7 Flow low water leoel scram due to closure of reached due to Recirc Values loss of^Mlant
Reactor Scram Initiated
reduction, in reactor pressure core flow decreases reactor pressure increases increased aoitis Reactor Power Decreases Safety Reüëî Valves Open V continued decrease steady high Turbine Bypass in reactor water leoel pressure Valves O^n
Low Low Level i (Level 2) pressure < 744 psig pressure > 1065 psig Reactor Mode ^ Switch in RUN
HPCS/RCIC Msrv Pressure Regulator Recirc Pumps Closes System operates Tripped Signal Generated
HPCS/RCIC HPCS/RCIC not SigiAl Initiated Initiated
ADS Initiated Manually
Start Start 1------? Low Pressure Residual Heat . ECCS Removal System 49 Next, the identification of the problem is required to verify that the
reactor is responding as expected, and to select the necessary control actions. The problem of loss of reactor vessel coolant inventor}' is rea^nized by a reduction in
vessel level The cause for loss of inventory is diagnosed to be the loss of FW by
recognizing a decrease in feed water flow.
Once the problem is identified the operator se le c ts the following predefined
control procedure (either from his training, or because he is following some
predefined procedure): Procedure A
TO Limit the Consequence of Loss of FW;
verify the occurrence of reactor scram at Reactor Water Level - Level 3 verify recirculation pump trip at Reactor Water Level - Level 2 verify the actuation of HPCS and RCIC at Reactor Water Level - Level 2 verify the actuation of low pressure injection when Reactor Pressure is about 400 psig actuate the shutdown cooling mode of residual heat removal system if needed
First, an operator wül construct a detailed specification on how to execute
Procedure A by expanding the various steps using primitive procedures such as: 50
Procedure A.1
To verify the occurrence of reactor scram:
check that the neutron flux has decreased check that the position of control rods is zero
Lei us assume that the operator successfully verifies the reactor scram and recirculation pump trip, but finds that HPCS and RCIC have failed to start With the failure of HPCS and RCIC the normal means of achieving the goal of maintaining the reactor vessel water level is lost Since, a failure to maintain adequate water level in reactor can cause fuel melting, a plan to recover from this failure is required. Maintaining the reactor water level is a critical safety goal for which a corrective procedure is predefined. TuUs, the failure recovery requires using the following goal plan: Procedure B
T O maintain adequate water level execute:
if the reactor pressure > 400 psig then use high pressure coolant supply or reduce the reactor pressure and use low pressure coolant injection else use low pressure injection
Expansion of the plan for using high pressure coolant supply requires identifying various plant systems and actions that can provide coolant at a high 51 pressure. Using the knowledge of plant system capabilities the following feasible plan can be constructed: Procedure B.1
TO provide coolant at high pressure execute one or more of the follow ing actions:
Actuate/Restore HPCS/RCIC Actuate/Restore FW System If Reactor Pressure < 700 psig Then Use Condensate Systems Use CRD Hydraulic System Use SLC System
Before executing the expanded plan, an expert operator will eliminate plan steps that are unavailable. A plan is unavailable if. based on system status data or reasoning, it is determined a priori that the plan will not succeed. An expert operators analysis of procedure B.1 will consist of the following arguments:
• The actuation of the HPCS/RCIC is rejected because this action has already failed (a conclusion based on known system status). If the HPCS and RCIC failed to start because of a the spurious trip or an isolation signal, then the repeated efforts to start the two systems may succeed (a conclusion based on knowing the cause of failure). Repair of the high pressure injection system is not possible in the limited time available (less than 30 minutes) to prevent core uncovery.
• The use of the FW qrstem is eliminated because the turbine driven FW pumps cannot be restarted in lack of adequate steam supply. The FW pumps pumps cannot be used if the loss of all FW was caused by a break in the FW line. Let us also assume that the condensate pumps cannot be used beacuse the pressure is higher than 700 psig.
• The use of the CRD hydraulic system is eliminated because it cannot supply enough water to prevent core uncovery following a loss of inventory caused by the loss of FW. 52 • The use of the SLC system is eliminated because it cannot supply enough water. Moreover, use of the SLC is normally undesirable because it injects boron into the core. Normally, an experienced operator will not even consider the SLC system for this scenario. We have included SLC Q^stem simply to show an example of an inappropriate action because of its known undesirable side-effects.
The failure to restore the high pressure coolant supply requires selection of
the following plan step: Reduce reactor pressure and Use Low Pressure Coolant Injection.
The normal way to reduce pressure is to open pressure relief valves. Let us assume
that the operator is successful in reducing the pressure and starting low pressure
injection systems. Once the condition is stabilized (reduced temperature and
pressure) he/die will align the residual heat removal systems (RHR) for long term
cooling.
3.2 CHARACTERIZATION OF PROCEDURE SYNTHESIS IN A NUCLEAR POWER PLANT
Based on the analysis of the loss of feed water (LOFW) scenario, the
following issues are examined:
• the need for dynamic (runtime) procedure synthesis. 53 • various reasoning tasks required for responding to an abnormal operating condition, and the knowledge used for each task, and
• the interaction between tasks.
3.2.1 The Need for Dynamic Procedure Synthesis
In response to an abnormal incident the key problem is to find a procedure to control the incident. A procedure can be found either by selectin g one from a library of predefined procedures or by synthe^zing a procedure using a library of primitive procedures. Selecting a procedure from a library of predefined procedures can be used if:
• it is possible to define a complete set of procedures for all incidents of interest,
• the success of a correctly selected procedure is guaranteed, and
• the number of procedures is not combinatorially unmanageable.
In this situation the procedure selection process becomes one of diagnosis to identify the incident and choosing the recommended procedure for that incident
The procedure selection approach will fail if any of the following are true:
e the incident cannot be identified,
o the number of procedures is combinatorially unmanageable,
e the success of the procedure cannot be guaranteed,
in which case a procedure qmthesis approach is needed. In a procedure synthesis approach a procedure is constructed using predefined primitive procedures. 54 For static systems (i.e., ^ te m does not change with time) it is possible to define requirements for the procedure and synthesize it before its execution. However, if
the requirements for the desired procedure are not well defined and change with
time then it is necessary to synthesize a procedure dynamically, i.e., in runtime.
Responding to an abnormal incident in a NPP requires the capability to
dynamically synthesize a control procedure because:
• The requirements for the procedure change with the changing response of the reactor.
• The information on the specifics of the transient unfolds as the transient progresses based on the plants response to various automatic and mannsi action. The enhanced knowledge which builos up dynamically can be utilized only by a d y n a m ic procedure ^ th e sis approach.
• The response of the plant cannot be accurately predicted due to the lack of complete knowledge of the system state and also because the existing knowledge needed to make such predictions is incomplete and not reliable.
• The selected procedure or parts of it might fail requiring selection of an executable alternative in runtime..
At any given instant only the current procedure step can be known.
Subsequent steps of the procedure need to be ^thesized in response to the
changing requirements of the situation. 55 1.2J- Reasoning Tasks for Dynamic Procedure Synthesis
Generating procedures in runtime requires knowledge based reasoning to solve several problems in runtime. Based on the analysis of the loss of feed water scenario we conclude that in controlling an abnormal incident in a NPP an operator typically solves the foUowing problems:
1. Is there a problem that requires a corrective action?
2. Are the data reliable?
3. What procedure to select?
4. Should the selected procedure be executed?
5. How to determine that the selected procedure will not be executable?
6. How to synthesize an executable procedure?
7. How to interpret a procedure for execution. Le., given a procedure how to determine the actions and the order of their execution?
8. How to determine success/failure of the procedure?
9. How to recover from a procedure failure?
Reasoning tasks required for solving these problems are discussed in foliowing par%raphs.
Plant Status Monitoring and Abnormality Detection
Solving the first problem requires an analysis of the plant sensor data in runtime to detect a departure from the expected normal plant operation. The analysis of the plant state requires: 56 • online interpretation of a large number of alarms and sensor data (approximately 3000), and
• inferring the departure from normal operating condition based on the sensor and alarm values.
Online interpretation of all sensor data in a NPP is not practical However, it is possible to monitor the status of a specific goal (e.g., tnaîTitain plant safety) by- analyzing only a small set of critical sensor values (approximately 40). The development of the Safety Parameter Display System by nuclear power industry for monitoring sensor values critical to the plant safety is based on this concept [Joyce
83].
Inferring the departure from a normal operating mode is a complex process and requires:
• determining what the normal state should be given the goals of operating a plant, and
o an analysis of the plant state with respect to the expected normal state.
In principle, this requires determining, in runtime, the significance, of the current plant state with respect to the objective of the plants operation. In practice, however, the reasoning involved requires checking the deviation of the pre-defined combinations of variables or plant states from the expected values. For example, the abnormal plant state due to the loss of all feed water (discussed in section
3.1.2) is detected by checking the values of following alarms and sensor values: Reactor Water Level Low Feed Water Flow Rate Decreasing Steam Flow Rate - FW Flow Rate > 0 FW Pumps Tripped 57 Sensor Data Validation
Determining whether the sensor data are correct requires isolating malfunctioned sensors and estimating the value of a variable using the available sensor values and knowledge on the status of various systems of the plant Detecting an invalid sensor value requires runtime comjHxison of the measured sensor value with the expected sensor value. Checking every sensor value in a NPP in runtime is a formidable task and there is a need to isolate sensor values that require validation.
Reasoning is required to infer that a sensor value may be invalid and in determining the expected sensor value. One of the ways to suspect a sensor value is to look for conflicting diagnostic conclusions based on the sensor values
[Chandra 85a]. [Hashemi 86]. Determination of expected values is based on several things such as using the values of similar sensors, and estimating the value using values of parametically related sensor.
Diagnosis
Diagnostic reasoning is required to determine the cause of an abnormal plant state.
For procedure synthesis, diagnosis of the plant state is required to:
1. identify the required corrective actions, and
2. determine the corrective actions to be executed.
Identifying the required corrective actions: Consider the example discussed in the section 3.1.2 where first, the loss of feed water was di%nosed as the cause 58 for low reactor water level, and then the predefined corrective procedure A was selected. It is possible to further diagnose the cause of loss of FW, however, in controlling an abnormal situation the detail of diagnosis is determined by:
• the time available for diagnosis, and
• by identifying a plant state for which a corrective action is defined.
If there is no time limitation, then it is desirable to diagnose rigorously to find the malfunction and repair it. In most situations there is a limit on the available
time, and control actions that mitigate the consequences rather than repair the malfunction are selected. For example, the procedure A in section 3.1.2 does not repair the problem of LOFW but it limits the consequences of the incident.
In a NPP there are an extremely large number of possible plant malfunction states and checking each one of them in nmtime in not possible. Thus, the practical problem of di%nosis in responding to an abnormal incident is to timely identify a plant state which is associated with a corrective action plan. If the
number of such plant states is extremely large then the runtime diagnosis may not
be possible, and more efficient diagnostic strat^es are needed.
Determining the corrective actions to be executed: If the corrective action
plan has been identified then it is necessary to isolate plan steps which will be
unsuccessful because necessary component or system has malfunctioned. Diagnosis is
needed in this case to determine the status of essential plant systems in the
corrective action plan. The diagnosis task in this case simply requires checking the 59 status of identified systems. For example, in executing procedure B.1 the action actuate HPCS/RCIC was eliminated because these systems were known to be in a failed state. However, if the failure was caused by a spurious trip then the action would have been attempted.
Consequence Prediction
Given an initial plant state, the task of consequence prediction is to predict the changes in the plant state following the execution of an action. Consequence prediction is required for determining the effect of an action. Given several alternative actions the capability to predict their consequence can help select the most desirable action. In the scenario of LOFW described in section 3.1.2 consequence prediction was used to eliminate several alternative actions. For example, in Procedure B.1, the use of CRD hydraulic systsras was eliminated because the operator reasoned that given a loss of FW incident the use of CRD hydraulic system will not provide sufficient coolant. Use of SLC was eliminated on similar arguments. The operator also reasoned that the use of SLC will require extensive reactor coolant purification actions to remove the boron.
Some knowledge used for the consequence prediction can be precompiled, such as, the high concentration of boron in the reactor coolant following the use of the SLC system. To handle unusual situations, reasoning about the consequence of an action may require reasoning about the structure and function of the system 60 and the interaction between different systems. For example, for a small leak in the reactor coolant system the use of CRD hydraulic system may provide just the adequate amount of coolanL Given the rate of loss of reactor coolant and the status of the FW system, the adequacy of the CRD hydraulic system may have tc be determined in runtime.
Procédure Synthesis
In this dissertation Procedure Synthesis is used to describe the task of developing a detailed sequence of actions to respond to a situation. Procedure synthesis starts with an initial plan, such as Procedure B in section 3.1.2, and takes into consideration the effect of plant dynamics on the executability and success of various steps of the plan to generate a successful procedure. For example, in the
LOFW scenario described in section 3.1.2 the operator used predefined procedures
A, A.1, B, and B.1 to construct the following procedure in runtime: Procedure C
Verified Reactor Scraa at Level 3 Verified Recirculation Pump Trip at Level 2 Detected Failure of HPCS/RCIS actuation at Level 2 Goal: Maintain Adequate Water Level Identified Failed to Restore High Pressure Coolant Supply Reduced Reactor Pressure below 400 psig Started Low Pressure Injection Goa:l Maintain Adequate Water Level Achieved Use Shutdown Cooling Mode of Heat Removal System If required. 61 The task of procedure synthesis requires runtime construction of an executable procedure. Some of the executable steps of a procedure may become unexecutable because of the unanticipated system response (eg., in Procedure A the failure of
HPCS/RCIS was unexpected) requiring the synthesis of an adequate alternative procedure In synthesizing the Procedure C, an expert operator typically performs the following tasks:
• Selection of an initial procedure such as Procedure A by accomplishing the monitoring and diagnosis tasks as described above specifically by detecting abnormal changes in plant condition and selecting predefined procedures for controlling the effect of these changes.
• Synthesis of an executable procedure by first, expanding the initial procedure in terms of more detailed procedures, and second, by eliminating actions which will definitely fail The expansion is performed by using an expanded procedure for each of the plan steps of the initial procedure. For example. Procedure B.1 is an expansion of one step of Procedure B. The process of eliminating actions that might fail requires using the diagnostic and consequence prediction tasks as discussed above.
» Execution of the procedure by selecting the next action, determining if it should be executed, and if executed then determining if it has been successful For example. Procedure B.1 specifies a ordered sequence of actions thus determining the next candidate action is simple. The first candidate action is Actuate/Restore HPCS/RCIS. This action need not be executed if its goal of providing coolant at high pressure is already achieved. The action diould not be initiated if the necessary precondition, le., reactor pressure be greater than 450 psig is not true. After the action is executed it is successful only if its goal is achieved. In case the action fails then an alternative action has to be found and executed.
• If an action fails then the goal is to either recover the action by repair within time constraints or find a functional equivalent A functional equivalent is found by searching for all actions that can satisfy the goal of the failed action. For example, in Procedure A the failure to verify actuation of HPCS/RCIC required searching for an action to achieve the goal maintain adequate water level 62 3.2.3 Interaction between Procedore Synthesis Tasks
As seen from preceding discussion various reasoning tasks need to interact to solve the problem of plan synthesis. Various reasoning tasks and their interaction is shown in Figure 3. In a typical situation the plant sensor data are first analyzed to isolate malfunctioned sensors and estimate validated data. As discussed in [Chandra
85a] the question of invalid data is sometimes raised because the diagnostic hypotheses deduced from the data are in conflict The validated data are then used for plant status monitoring to detect significant changes in plant response. If there is a change in plant response that requires a corrective action then an action plan is synthesized. In synthesizing the plan it is sometimes necessary and possible to determine the effect of a certain action thus requiring the need for Consequence
Prediction reasoning. Reasoning about the consequence of an action may require diagnostic knowledge about other systems thus requiring interaction between the
consequence prediction and diagnosis tasks. In synthesizing a plan it is also necessary to assure that the steps of the plan are not disabled by some failure requiring the need for diagrtostic reasoning. 63 Figure 3: Reasoning Tasks for Dynamic Procedure Synthesis
Validated Sensor and Component Status Database
Plant Status Sensor Data Monitoring Validation
Diagnosis Procedure Synthesis
PlantPlant Component Consequence Sensor Maintenance Status Prediction Data Data Data irator
Legend Data Path Control Path 64 3.3 AN INFORMATION PROCESSING MODEL FOR DYNAMIC PROCEDURE SYNTHESIS
In this dissertation Dynamic Procédure Synthesis (DPS) refers to the task of selecting procedures, synthesizing executable procedures, executing and monitoring the progress of procedures, and finding alternatives for failed procedures during runtime. In this section a knowledge based framework for accomplishing the DPS is described. The framework is based on our observation that during most abnormal operating conditions, highly experienced operators and expert engineers are able to use the pre-specified operating procedures and their knowledge about the system to perform the DPS task in response to unanticipated transients. The framework is based on the assumption that selecting, synthesizing, executing, and failure recovery of procedures requires certain problem solving skills and domain specific knowledge. Specifically, the proposed framework defines:
• An information processing model for the DPS task based on the idea of searching for an appropriate plan in the search space of pre-specified plans;
• Problem solving mechanisms required for accomplishing the DPS task in accordance of the developed information processing model;
• A framework for organizing planning knowledge required for DPS.
The tasks of plant monitoring, and diagnosis are treated with simplistic ideas, however, the framework provides guidance for incorporating sophisticated solutions.
The tasks of signal validation and consequence prediction ar:; recognized but no 65 attempt has been made to propose a solution. It is assumed that validated sensor data are available. The proposed solution approach is capable of utilizing consequKice prediction but does not depend upon it. In the following discussion we will use the following terms to refer to various types of plans or procedures:
Plan: A plan is an ordered sequence of actions to bring about or prevent a certain change in the state of the plant or a system. Procedures A, A.1, B, and
B.1 in section 3.1.2 are examples of a plan.
Plan Library: A collection of declared plans.
Primitive Plan: Primitive plans are the declared basic simplest operator executable actions which cannot be further expanded in terms of other plans declared in the plan library. Close Bs^sass Valve or Press the Reactor Shutdown
Switch are examples of primitive plans. Other operator executable procedures are defined in terms of these primitive procedures.
Plan Fragment: Given a plan, a plan fragment is a subplan of the plan.
In procedure B.1 section 3.L2 actions Actuate/restore HPCS/RCIC, Use CRD
Hydraulic System are examples of a plan fragment. Plan fragments can be complex and can be expanded in terms of other procedures. 66 Synthesized Plan: A plan generated by the plan ^thesizing approach using predefined plans. A synthesized plan is not declared in the plan library. Procedure
C in section 3.2.2 is an example of a synthesized procedure.
3.3.1 Background
In section 2.2.2 we presented a review of some of the Issic work in AI on planning. The task of procedure synthesis studied in this work is a special case of the larger class of planning and problem solving tasks studied in Artificial
Intelligence. In AI a planning task includes several sub-tasks: assessing a situation, deciding what goals to pursue, creating plans to secure these goals, and executing plans [Wilenskv 83]. where a plan is an ordered sequence of actions.
Implicit in the task of creating plans is the task of recovering from the failure of a plan and replanning. A planning formulation consists of specifying several elements (shown in Figure 4);
• a library of plans containing predefined plans.
• a simulation, consequence predictive, or a cause-effects model to evaluate the effects of actions and plans,
• a world or a qrstem state model which can be updated by simulating the effects of plans, and
• a planning logic which, given the initial state and goal state, will generate a plan. If goal state is not given, then the planning system will be required to determine the goal state. 67 Figure 4: Structure of a Planning System
Plan Library
A
V Initial State ■ Planning/ Problem Solving > Plan Goal . Logic State
Plant/System Plant/System Simulation/Predictior Status Model Model
Legend Data Path
Control Path 68 Thus, an AI solution to a planning problem involves specifying the following:
• An epistemic theory of what types of knowledge are involved in solving the problem.
• A problem solving theory of planning which describes the information processing or a computational model for generating and executing the plans.
• A knowledge organization and representation theory on how the planning knowledge should be modeled.
Problem Solving in Procedure Synthesis
Problem solving is essentially a process of mapping into a space of feasible solutions. Two basic mapping approaches are: selection of a solution, and, generation or synthesis of a solution [Sacerdoti 77] [Clancey 85]. If the solution space consists of complete solutions then the problem is solved by selecting the desired solution. For example, for the task of diagnosing a power plant the solution space can be defined as a collection of various component malfunctions.
The problem of diagnosis then becomes one of selecting the specific component malfunction(s) which will explain the observed sensor data. If the solution space consists of elements of typical solutions then the problem is solved by synthesizing a complete solution using the elements of the solution. For example, in responding to an unanticipated abnormal situation it is required to construct a corrective action procedure utilizing the basic control actions of the plant. 69 The mapping can be accomplished either by searching the solution space, or by developing a closed form solution. Most complex problems require searching of the solution space to find the solution. The selection process of mapping can be accomplished in several ways. Relatively small solution spaces can be exhaustively searched by checking every potential solution to find the desired one. For larger solution spaces it may be possible to constrain the solution space by defining a sub-space of feasible solutions, and then exhaustively searching the smaller space of feasible solutions. For very larger search spaces it may be possible to define a mechanism by which a feasible solution can be hypothesized and tested.
In some problems, such as procedure synthesis for a power plant, the number or primitive plans is very large. Since the number of primitive procedures is relatively large the solution space of all possible control procedures will be too large to be of practical use using the simple solution generation and exhaustive search approaches specially during a runtime situation. However, if the primitive control actions are of reasonable size then it may be possible to synthesize the desired procedures within the time constraints. Also, the dynamically changing plant conditions require the capability of refocussing the search for a procedure to modify and synthesize a plan to achieve changing goals. 70 3.3^ Problem Statement
From an information processing viewpoint, the dynamic procedure synthesis consists of two basic information processing problems:
• defining in runtime what goal(s) to pursue, and
• selecting in runtime a plan from a search space or a library of predefined plans, to achieve specified objective(s) and meet specified constraints under the current system state.
The search space of plans or the library of plans consists of predefined plans to change the system state in a desired manner, such as procedures A and B described in section 3.LZ Often the expansion of the steps in a predefined plan are also specified, such as procedures A.1 and B.1. Thus, the search space may consist of a hierarchy of predefined plans. For a typical NPP we have identified more than 300 primitive plans. The extremely large number of possible plans
(aerated by taking all combinations of 300 plans) makes it impossible to exhaustively generate and test all possible plans in runtime, thus requiring an efficient indexing (or plan selection) mechanism to find the desired plan. In practice, however, the search space is constrained by domain specific conâderations such as the goal(s) to be achieved and the various constraints a candidate plan should satisfy, specifically:
• The plan should be available. Le., there is no a priori reason to believe that the systems required for critical plan steps may be in a failestate. For example, if a certain valve is known to be stuck closed 71 then it is unavailable for the action Open Valve. Other examples are discussed below.
• The plan should be executable. Le., the necessary runtime process and system condition are satisfied.
• The selected plan should be efndent. Le., a plan that attempts to repair the problem or control it within a small system is preferred over one that attempts to control it in a larger system.
• The plan should be effective. Le., the selected plan should result in desired effects.
• both the plan selection and the execution of the plan should be accomplished within specified time limits.
For example, in the scenario of loss of feed water described in section 3.L2. the key problem was to inject water into the core at h i^ pressure. Procedure B.1 specifies the various options. The HPCS/RCIC could not be used because they have failed and are. therefore. una\/ailable. The steam driven feed water pumps could not be used because they are rendered unavailable due to the loss of steam supply to steam turbines caused by the isolation of the reactor where the steam is produced. The low pressure supply systems are not execu table at reactor pressure higher than 450 psig. CRD hydraulic system is rejected because it will not be effecth /e in providing the desired flow rate to cool the reactor. The SLC system wras rejected both because it will be ineffective and using it is inefficient. In section 3.1.2 these decisions were made by an expert operator. In this section we will develop an information processing model to model the reasoning of the expert operator. 72 3.3.3 Assomptions
To design an information processing model for dynamic procedure synthesis it is assumed that using the available domain knowledge it is possible to define:
1. A library of effective and wel tested predefined plans for changing states of plant components and systems.
2. A table of diagnostic states (process states and events) and recommended control plans.
3. Backup plans for a large number of plans. A backup plan is used if the principal plan is either not executable or fails in execution.
4. A list of operational goals, associated knowledge on when to pursue the goal, and recommended plans to achieve the goal
5. A mapping between the list of diagnostic states and the list of operational goals that need to be achieved.
6. A goal for each plan (an ordered sequence of goals) such that if the plan fails then backup actions can be found by searching for plans to achieve the goal
Assumption 1 is required to gaurantee that the qmthesized procedures using predefined plans will be successful If some of the predefined procedures do not satisfy this assumption then the success of the synthesized procedure in controlling the plant cannot be gauranteed, however, the problem solving approach described in this section will still apply • 73 3-3.4 A Problem Solving Theory for Procedure Synthesis
The proposed theory is applicable io knowledge rich domains that satisfy the assumptions listed above, and specifies:
• how to organize the search space of predefined plans,
• a knowledge based search or an indexing mechanism to map into the space of predefined plans, and
• various subproblems that need to be solved to find an acceptable plan.
Search Space of Predefined Plans
There are two types of predefined plans: the primitive plans and plans defined using the primitive plans. The search space consists of only plans that are presumed to be effective to assure that an intended change will take place by executing the ordered sequence of actions specified by the plan. Often a plan also specifies backup or alternative actions to its subplans. In the LOFW scenario described in section 3.L2 the search space of plans consists of Procedures A, A.1,
B, B.L and procedures for the expansion of the plan steps In Procedure B the plan step "reduce reactor pressure and use low pressure injection" is a backup plan to the plan step "use high pressure coolant supply".
Indexing or Plan Selection Mechanism
The indexing mechanism defines how to select the desired plan from the space of predefined plans For the procedure synthesis task a plan can be selected: to 74 satisfy a specified goal, to control a specified plant state or malfunction or an event, or by direct retrieval from the plan library. Thus the library of all plans can be divided into three separate libraries:
• Library of Goal Plans containing plans that are indexed by pre-specified goals such as the Procedure B in section 3.L2.
• Library of Event Plans containing plans that are indexed by pre specified diagnosable plant states, malfunctions or events such as the Procedure A.
® Library of other plans that are indexed by a unique name for each plan such as the Procedures A.1 and B.1.
This decomposition of predefined plans is applicable to knowledge rich domains where it is possible to specify:
e a finite set of goals, knowledge to determine which goal to pursue, and plans to achieve the goals, and
• a finite set of diagnosable plant conditions, knowledge on how to diagnose the plant condition, and plans to respond to them.
Each of the event and goal plans consist of at least two parts:
• a corrective action procedure, and
® a set of conditions, called entry conditions, which if true require the execution of the corrective action procedure
For example the plan for the loss of feed water incident in the events plan library will be: 75 Procedure D
Event: Loss of a ll FW
Entry Condition: Reactor Water Level: Low FW Flow Rate: 0 or decreasing rapidly RPV Pressure: high
Corrective Action: v erify the occurrence of reactor scram verify recirculation pump trip verify the actuation of HPCS and RCIC verify the actuation of low pressure injection verify the actuation of reactor heat removal system
Thus, indexing into the library of goal and event plans requires checking the entry conditions and selecting the corrective actions.
Sub-Problems
Given the library of predefined plans and the indexing mechanisms as defined above, synthesis of a successful plan requires information processing models to perform the various reasoning tasks described in section 3.2.1 In this work we have developed models for the following tasks:
• Monitoring: Le., continuously checking if any of the pre-specified goals need to be achieved or any of the pre-specified events need response.
• Procedure Selection and Scheduling; Le., determining what goals to achieve or events to respond to, the order in which responding actions should be executed, and selecting or constructing the feasible plan.
• Procedure Generation; Le., ^thesizing an executable procedure using the feasible plan. 76 • Procedure Execution; Le., deciding what procedure step to execute and determining whether the execution of the procedure step was successful by producing expected changes in the system state.
• Failure Recovery, Le., synthesizing an executable alternative procedure to recover from a failed procedure step.
Information processing models for these tasks are discussed in the next section.
3.3,5 Problem Solving Mechanisms for Dynamic Procedure Synthesis
The dynamic synthesis of procedures requires solving several sub-problems.
In this section an information processing approach for solving various sub-problems is described .
Monitoring and Diagnosis
Monitoring involves checking the entry conditions for the events and goal plans.
Often the entry conditions (such as those of Procedure D) simply require checking the value of some sensor data point or an alarm, however, sometimes malfunction diagnosis may be required. For example, to identify the abnormal event of FW
Pump Trip, it is first required to detect the off-normal situation of loss of FW, and then di^nose the problem to be the trip of FW pumps.
If the number of goals and events is relatively small then entry conditions can be evaluated in a sequential manner. For a large number of goals and events 77 sequential evaluation of entry conditions may not be practical and more efficient and powerful classification s tr a ta can be used. One of the ways to solve this problem is to organize the plant states as a classification hierarchy where the tip nodes are predefined events and goals, and the intermediate nodes are hypotheses about plant states (see Figure 5). This hierarchy is based on the MDX approach for diagnosis in medical domain [Gomez 79]. The applicability of the MDX approach for the diagnosis of engineering problems has already been demonstrated
[Chandra 82a], [Hashemi 86]. The diagnosis is performed by first checking if the top level malfunction state in the hierarchy is substantiated by the available plant sensor data. If it is and there is time available for further diagnosis then the
lower level malfunction states are examined in the same manner.
Plan Selection and Schenniin^
Having detected the goals and events to be controlled, the purpose of plan selection is to identify appropriate corrective procedures and the purpose of
scheduling is to specify the order in which these plans are to be executed. Thus,
once the goal or the event to be controlled is known the corrective action plan is
retrieved from the appropriate plan library. For example, in Procedure D, having
detected a loss of all FW, the corrective action (which is same as Procedure A) is
retrieved from the library of events plans. ' nodWithdr«w«l WlfRecIrStart Reactivitylncrease ^ RcicIrR RciclrRontrniralllnc ^ MisplacedOund1« / PressurcRegfallOpen —• lossFWMoalIng CooUntTempOecrfièse X Heatinc FWControHerfail ''S/RValveOpen /lleatChange; LossFW ' PressureRegFailCtosed ReactorPressureInc ^ TurblneTrIp ^ '^OeneratorLoadReJ lleatkobalanca { MSLIVCIosuro RodOrop ,--'CnMalo|i«ratlonOec BundloDrop 'H eaiO ec DundleMisptaced 'FW T em phK ------SteainConlrolterFaH CootantFlow Inc------RoclrControtFail
CCIik ; _^IIPCSStart Coolantlnventorylnc — FWControlFallOpen Stearnlinn-Break 'CooHngCapacltyChange < CoolantlventoryOoc FWLoss CGDec ^ ' OpenS/RValve • RcclrTrlp ' ConlantFlowDeG ■ RecJfF ailOccFlow
Figure 5: An Example of a Classification Hierarchy for Indexing into Events Plan Library 5^ 79 Scheduling corrective plans is a complex process requiring the capability to predict the potential consequence of executing and failing to execute various
actions. In some simple situations it is possible to pre-specify the prioritization cf
various goals and events. In the work reported here the later approach is selected.
However, the more powerful approach of scheduling plans based on an evaluation
of potential consequence can be incorporated in the overall approach.
Generanng an Executable Procedure
Given an initial plan, an executable procedure is generated by expanding the
individual steps of the plan in terms of available and executable pre-defined
control actions. The expansion is accomplished by retrieving detailed procedures to
accomplish the task specified by the plan steps. Each of the plan steps of the
expanded plan is checked for the availability. Plan steps that are not unavailable
and are critical to the success of the initial plan are replaced by an alternative
action. Specifically, generating an executable plan involves following steps:
Expand the Initial Plan: The initial plan is expanded to assemble a detailed
procedure consisting of actions an operator can execute using the procedures
defined in the library of systems plans. The expansion is accomplished in an
hierarchical manner. For example, the Procedure A is expanded by using detailed
plans for various steps such as the Procedure A.1 for verifying reactor scram.
Similarly, the Procedure B is expanded using procedures similar to Procedure B.1. 80 In procedure B.1, each of the actions can be further expanded. The result of this expansion process is an assembled procedure for scccsplishing the initial plan in terms of primitive actions.
Test the Availability of the Expanded Plan: The availability of the expanded plan depends upon the availability of its subplans in the expansion. In this dissertation a subplan is considered to be available if there is no evidence to suggest that the subplan will not be successful A subplan is unavailable if the key plant systems or components required for the execution of the subplan are:
• in a failed state, or,
• under repair, or,
• not operable because of the unfavorable plant condition or loss of essential inputs, or
• it is known that the subplan will not succeed.
An analysis of the availability of action of Procedure B.1 was presented in section 3.1.1
Find Available Alternative Actions If a plan step is not available then there is a need to find an alternative action which is available. In knowledge rich domains, such as the NPP, often appropriate backup actions are predefined and selected as a substitution. In Procedure B.1 the action reduce the reactor pressure and use low pressure injection is a backup action to use high 81 pressure c o d a n t supply. However, if the backup action is not defined or is not available then there is a need to find an adequate substitution. The serch and synthesis of an available alternative is performed using the Failure Recovery
Mechanism defined in section 3.3J.
The result of procedure generation is a detailed hierarchical procedure of available actions executable by an operator. The availability is determined by checking availability of each of the subplans down to the primitive actions. The reason for such a computationally rigorous process is as follows: It is assumed that even though the user may not need a detailed procedure expanâon, he will essentially be executing the primitive actions to accomplish the plan. Therefore, by in-depth testing, the potential for a failure at primitive actions level is eliminated.
Plan Synthesis daring Execution
The dynamic nature of the NPP requires that given an available plan, the executability of a specific plan step should be evaluated just before its execution.
It is assumed that the outcome of an action cannot be completely predicted, thus the impact of previous actions on the executability of a specific plan step cannot be ascertained ahead of time. Therefore, the plan to be followed by the user or an operator is generated in runtime in response to the dynamically changing plant conditions. Synthesizing a plan requires following operations: 82 Select a Procedure Step: The first step is to determine the procedure step to be executed, which requires the capability to interpret the description of the procedure. For example, in Procedure A, the first step is to verify reactor scram followed by other actions in the specified sequence.
Check if the Plan Step is Needed: Let us consider the following procedure: Procedure E
If reactor pressure is high Then To Achieve Goal: reduce re a c to r pressure execute one of follow ing:
open safety relief valves except if suppression pool temperature is high or use pressure regulator except if condensor is not available
This procedure has four elements:
• the entry condition: reactor pressure is high,
• the ^>ah reduce reactor pressure,
• the exclude conditions: suppression pool temperature high and condensor not available, and
• the procedures: use safety relief valves and use pressure r^ulator.
This procedure is needed if the entry condition is true, the goal is not achieved, and the exclude conditions are not true. To determine whether a plan 83 step is needed these three conditions are checked. There are two types of goals to
be distinguished:
• goals which, if not true, need to be achieved (called Achieve goals), and
• goals which, even if true, need to be maintained (called Maintain goals).
If an achieve goal is true then the plan step is not needed. However, even if the
Maintain goal is true the plan step is needed to keep it true.
Test the Executability of the Selected Plan Step: The executability of a
plan is determined by checking for vaiious factors which, if true, will prevent the
execution of the plan. These factors are:
• Preconditions: Often a plan cannot be executed rmiess certain system conditions, called preconditions, are true. Preconditions change dynamically with the plant state and have to be evaluated in runtime. For example, in Procedure B, the precondition to executing action actuate low pressure injection is that reactor pressure be less than 450 psig. If a plan is not executed because its preconditions are not true then it is considered to be failed and an executable alternative is generated.
• Previous Exécution History: If a previous attempt to execute the plan had failed and the cause for the failure has not been cleared or repaired, then it can be assumed that the plan will fail if attempted and is not executable. Since repair actions often occur concurrently with the plant operation, it is necessary to check the repair status just before attempting the execution.
• Reset Status of the Action: Even if a previous attempt to execute a plan succeeded, some of the plans require that certain reset actions be taken before attempting a re-execution of the plan. The reset actions essentially restore the status of certain systems and plant variables. Before executing such a plan it is necessary to verify that the reset conditions are true. 84 Execute the Selected Plan Step: Executing the plan step is done by prompting the user to execute the action. The user can respond Yes if done. No if attempted but failed, or ? to obtain more detailed expansion of the plan step.
Check the Success of the Execution: The execution of an action is considered to be successful if the user responds Yes to the prompt and if the goal has been achieved. Thus after the execution of the action the goal of the plan step is checked again. If the goal has not been achieved or the user responds No to the action prompt then the action is assumed to have failed. For example, the
Procedure E is considered to have failed if the goal reduce reactor pressure is not achieved.
Dealing with the Failure of Plan Step: If a plan step has failed then an alternative action is found by solving the Failure Recovery problem as described in following section.
Failure Recovery during Execution
The failure recovery process is modeled as a goal directed search, ie., if an action
fails then its executable alternative is found to achieve the goal of the failed
action. To demonstrate the recovery logic let us consider the two specific procedures A and B. 85 The Procedure A implies that for the success of the plan all of the five actions should be successfully executcu in the specified sequence. Thus, if action verify the occurrence of Reactor Scram failed then to prevent the failure of the plan it is required to find an alternative action to achieve the goal of reactor scram. As described in section 3.1.2 the action verify the actuation of HPCS and RCIC was assumed to have failed. The Failure Recovery process retrieves the prespecified goal of maintain adequate water level and then finds
Procedure B to achieve the goaL
As a second example, consider the Procedure B. Given that the reactor pressure is high, this procedure implies that for success it is sufficient to successfully execute one of the two actions: use high pressure coolant supply and Reduce the reactor pressure and use Low Pressure
In je c tio n , However, the first action is preferred over the second action. If the first action tails then the predefined second action B is selected for execution. If the second action also fails, then the Failure Recovery process attempts to find an executable alternative to achieve the goal achieve the goal of the Procedure B. 86 3.4 SUMMARY
In this chapter a framework for dynamic synthesis of control procedures was described. The framework is based on the assumption that the task of an operator in controlling a plant can be described as a problem solving process which is driven by task specific knowledge. To identify the plant control specific problems solved, the problem solving strategies used, and the knowledge used by an operator; a task analysis of operators actions in controlling the loss of feed water incident is completed as described in section 3.L From the task analysis it was found that an operator typically solves several problems described in section 3.2. From the task analysis it was also found that since a NPP is a dynamic system whose response cannot be accurately predicted, controlling it requires the capability to dynamically synthesize and modify control procedures. Apart from the capability of procedure synthesis, to solve the problems described in section 3.2 an operator is required to perform several lypes of reasoning tasks described in section 3.2.2.
An information processing model (DPS) to perform the procedure synthesis task is described in section 3.3. The DPS approach models the task of procedure synthesis as one of selecting and modifying plans in runtime using a library of predefined procedures. The plan selection process is required to satisfy various constraints described in section 3.3.2. Runtime synthesis of procedures requires computationally efficient mechanisms to select plans. In the DPS approach this is 87 achieved by decomposing the library of predefined plans into several libraries. The decomposition is based on domain specific goals to be achieved by the procedures.
To synthesize successful plans and modify the failed plans computational models
for various reasoning tasks performed by an operator are developed. These models
are described in section 3.3.5.
The DPS model is proposed as a systematic framework for synthesizing
procedures for controlling the response of dynamic systems. The application of
DPS is restricted by the assumptions described in section 3.3.3. The outcome is
determined by the domain specific knowledge used to implement the DPS model
Several types of knowledge are used in performing the various reasoning tasks. In
the next chapter a language and its implementation for organizing and representing
knowledge required for the DPS model is described. An example illustrating the
functioning of the DPS model and the use of a language is also described in the
next chapter, section 4.5. CHAPTER 4
THE ORGANIZATION AND REPRESENTATION OF KNOWLEDGE FOR DYNAMIC PROCEDURE SYNTHESIS
To scccapiish the DPS task both the knowledge about predefined plans, and the knowledge to perform various tasks such as monitoring, diagnosis, plan selection and scheduling, plan generation, execution, and failure recovery is needed.
In this chapter we describe a knowledge represention framework, and a language to express the plan synthesis knowledge and implement the problem solving mechanisms of the DPS model Specifically, this chapter describes:
• an organization for the library of predefined plans,
• different types of knowledge required and their organization,
• implementation of a language to represent the knowledge for dynamic procedure synthesis (DPSRL), and
• an example of the application of the DPS approach using DPSRL to a simplified Reactor Scram event.
88 89 4.1 BACKGROUND
Ac AI theory of how to solve a problem embodies a theory about how to represent the knowledge involved in a task, and about how that knowledge is used.
Much of the research in AI is concerned with precisely describing the knowledge and reasoning processes at the symbol level In order to precisely define the knowledge and its use, AI researchers often develop a formal language to describe the primitives of the knowledge at the symbol level, an algebra or logic of how the primitives are used to construct higher level knowledge concepts, and how such a representation of knowledge can be used to model the problem solving task.
Finally, the problem solving theory and the representation language are tested by developing a computer program that embodies the developed theory.
Developing an AI language requires defining symbol structures and their interpretations to express the knowledge. Several general purpose formal languages exist which can, in principle, be used for syntactically expressing the planning knowledge at the symbol level However, such languages often do not provide specific interpretation of the symbol structures. The problem of knowledge representation requires defining closely related symbol level syntax and problem specific semantics. It is the semantics aspect of a language that allows expressing a variety of knowle(%e about the real world such as knowledge about objects, processes, events, causal relationships, goals, actions, etc. Thus the representation 90 language should be adequate both syntactically and semantically, for the specific problem or a class of problems. Much of the research in AI is concerned with developing languages that embody problem solving AI theories for a class of problems.
In designing an AI language that embodies a problem solving theory there are several representational issues to consider
• Expressiveness: Does the syntactic representation make all of the important semantic distinctions between the concepts being represented? [Woods 83]
• Structural Representation: Can the language support specialized forms of syntactic representations? [Bobrow 77]
• Computational EfficierKy: Does the language allow for efficient computation of various inferences required to solve the problem? [Woods 83]
• Conciseness: Is the representation scheme compact, clear, and at the right level of abstraction? [Woods 83]
• Easy Retrieval and Access: Is the representation scheme such that the desired knowledge can be easily accessed? [Bobrow 77]
• Multiple Level of Representation: Does the representation scheme allow the representation of the same concept at the different levels of abstraction? [Bobrow 77]
Several AI languies have been developed that provide desired characteristics for specific problem types. Most of the popular AI languages were initially designed for a specific problem and are not appropriate as a general purpose AI language. It is widely recognized that no single AI language is appropriate for 91 solving all applications, primarily because different problems use différait types of knowledge and problem solving theory, and it is neither possible nor de&rable to have a uniform representation for all knowledge types. The existing ad hoc approach of developing a different language for different problems is clearly undesirable and emphasizes the need to develop a theory to provide a structure to the AI research in problem solving and languages.
A framework for understanding and guiding the research in developing knowledge based expert tystems has been proposed by Chandrasekaran [Chandra
85] which claims that complex knowiedge based reasoning tasks can tie decomposed into a number of generic tasks or problem so/vinp stratégies where each task is associated with specific types of knowledge and a family of problem solving mechanisms. Examples of generic tasks are; classification, knowledge-directed information exchange, hypothesis matching, object synthesis by plan selection and refinement, state abstraction, and abductive assembly of hypothesis. The advantage of this point of view is that once the problem solving strat^es and appropriate languages for the generic tasks are developed, new applications can be developed in a principled way using the tools for the generic tasks. In this chapta a language is described for procedure synthesis which is a type of the generic task object synthesis by plan selection and refinement. 92 4.2 ORGANIZATION OF THE LIBRARY OF PLANS
Based on the discussion presented in section 3.3.4 on indexing mechanisms, the library of predefined procedures is decomposed into three groups based on how a procedure is initially selected (see Figure 6):
• Goal-Indexed plan library containing predefined procedures to achieve or maintain goals.
• Event-Indexed plan library containing predefined procedures to responsd to a certain diagnosed event, incident, or specific process state, and
• System-specific plan library containing the procedures required for the expansion of the above procedures.
The purpose of the proposed organization is to provide:
• a computationally efficient mechanism for plan indexing,
• a decomposition of plans which is a conceptual model of how an expert engineer or operator might view them, and
• an organization of plans which enables migrated use of both the goal and event plans.
Two important features required for int^ration between the goal and event plans are: the capability to transfer from an event plan to a goal plan, and the capability to transfer from a goal plan to event plans. The motivation for requiring these capabilities and some of the variations are:
• Event -> Goal: Let us assume that while executing an event procedure it become clear that the procedure will not succeed. Thus, it become necessary to abondon the procedure and try to maintian the prespecified critical goals. To maintain the critical goals it is requîTed to select a goal plan fron the goal plan library. It is, theefore, necessary to be able to transfe from any event plan to an appropriate goal plan. 93
Figure 6: Organization of Plans in DPS
System Goal Plant Plans Library Plans
Events Plans Library
Legend ______Data Path
______Control Path 94 • Goal -> Event: Let us assume that the cause of an abnormal incident cannot be diagnosed thus requiring the execution of a goal plan. However, while executing the goal plan the cause of the malfuaetion is diagnosed to be one of the predefined events. Normally, the event plan will provide an optimal recovery from the malfimction. To enable the selection of the appropriate event plan it is required to have the capability to abondon the goal plan and transfer to the event plan.
9 Event -> Goal -> Event: An event plan consists of several plan steps. Each plan step is supposed to maintain one of the critical goals. While executing an event plan it may become clear that a specific plan step will not succeed requiring that the corresponding goal plan be executed. After the goal plan is successfully executed it is desired to return to the original event plan and execute the remaining plan steps.
• Goal -> Event -> Goal: In the Goal -> Event scenario described above, if the event plan fails thai it is required to transfer back to achieving the goal using other plans. If only a plan step of an event plan fails, then the transfer from may occur to a different goal
4.2.1 Goal-Indexed Plans library
Goal plans library contains plans for maintaining predefined critical goals or system functions. Goal plans contain knowledge to determine when to execute the specified plans, and how to determine if the goal is maintained. The goals plans library can be further organized as a structure of goals and subgoals. A hierarcy of safety goals structure for a NPP is discussed in section 5.2.
A typical plan frame for a goal is shown in Figure 7. The slot PlanU brary consists of predefined plans to achieve or maintain the goal The slot SuperG oal specifies the goal to be achieved if the present goal cannot be achieved by the plans specified in the plan library. Often, there is only one super goal But as 95 shown in Figure 7 it is possible to have more than one super goaL The slot
SubGoaJs declares goals which if failoî require the the present goal be achieved.
The present goal is invoked either because a subgoal has failed or certain plant state conditions (entry conditions) are true. The slot Enter? specifies the entry conditions. Often it is required to reason about high level interpretations of plant status. For a goal it is required to determine if the goal has been achieved. This knowledge is declared in the slot labeled InferedStates which stands for inferred states..
42^ Event-Indexed Plans library
Event-plans library contains corrective action plans for responding to anticipated incidents. Anticipated incidents are disposable system malfunctions. An event plan contains knowledge to determine when to execute the plan, and how to determine if the goal of the event plan are satisfied.
Planning knowledge required by the DPS for synthesizing procedures to
control an event (a specific qrstem or component malfunction), or an undesired process state is declared in event frames. A typical event frame is shown in Figure
8. In the event frame diown, the slot P/anU brary contains a library of plans for
responding to the event The slot Enter? contains knowledge to determine if the
specific event plan should be selected, and the slot InferedStates contain
knowledge to make necessary high level interpretations of the system state. 96 Figure 7; A Typical Frame for Goal Plans
DEdit Of CLASSES #SFWFIowControl
((MecaClass iSoalPTariSHirta Eclited: oas "25-üct-aç i'S:4ÿ --1 (Supers Functions) (ClassVariables (SupepFunction FWSupplyContro' doc (# unaocument^a C» a a a e a oyi) (SubFunction FVValvesControl doc (* ijnacicumenteo Cv i a a e a dv)) (PlanUbrary (Umit ControlActions Achieve) doc (*) Limit (DoSequence ((NotShutdown Reactor) -> (Scram Reactor)) (Start ECCS.HiPressInject ion) (Start PressRellefSystera) (Isolate RPV)) doc (» Rtt P«rrÿ; ControlActions (OoAsMany ((OR (NotOsciHating SteaaFlow) ((Oscillating StearaFlow) (NotFailed EPR)) -> (OoBackUp (ChangeMode F'l'ControlSystein to SingleElementMode) (ChangeMode MasterFyControl1er to m^riuô mode ) (ChangeMode FVControllers to Manual Mode) toach ieve (Control RPV .Water-Level)})) (Balance FeedWaterTrains.Flow) (Maintain RPV.WaterLevel toachieve ((RPV.WaterLevel > 155 in) (RPV.WaterLevel < 165 in)))) doc ■;* P,«f: Oyatr Crtak proc for mis:=r controller failure jymptomj) Achieve (OoBackUp ControlActions Limit tomaintain (Achieved SuperFunct ion) )) (Enter? ((FWValves doNotFollow MasterControl1er ) (OR (TransientFlow FWTrains) (InstableFlow FWTrains))) d o c Ref; O yster C reer ,i )) ( InstanceVariable-: )) 97 Figure 8: A Typical Frame for Event Plans
DFrlit of Cl ASSFS
(InstanceVariable:)> 98 4.^3 System Plans Library
System plans library contains plans required for changing the status of various plant systems. System plans are used to expand the event and goal plans to generate operator executable procedures. Control plans related to a specific system or component are grouped together to provide an efficient way of indexing.
Goal-indexed and event-indexed plans specify corrective actions in terms of control actions on certain systems and components. The plans for systems specify how certain system level operations should be performed. Plans for a system are specified in a system plan frame. A typical system plan frame is shown in Figure
9. The slot S u b system s declares the functional subsystems of the system. The slot
PlanU brary declares various control actions and other operational actions required for changing the state of the system. The slot labeled InferedState provides knowledge to interpret the system state in terms of high level descriptions. Some of the system plans need to access specific design data. The D esignData slot provides a place to declare such data. 99 Figure 9: A Typical Frame for System Plans
OM tt ...t ,<;i a s m S //S H I'S (•'■eiaClass Syîte»Pians««ca (Supers CoeponencPlans) (Classvanaples vSysteauaae KPS ooc i*.0 (SuPSysttas (ScraaSystea ControlRods) OùC »•> (PUnLibrary (Trip aanualTrip Reset) acic Reset (OoAnyOoe ( ( Masùccurred (Tnp RPSJ) •> '.OoAnyOoe (ResetTrip RPS if ((TiaeLapsea (Trip RPS)>> lô sec)) (OoSeqiMnce (valtFor "Tiae Lapsed after TripRPS • iOsecs") (ResetTrip RPS)))) (ResetTi ip RPS) -eua my (InResetMode RPS) toBwetOo Notning nofix) Trip (OoBackUp (Depress ' SmUTDDKN Reactor Rode Switch on Panel PSÊâ") («rnandüepress "RPS RanuaT Scram CM a , B, C, i 0 pusnputtonf) (ArmaridOepreti "RRCS RanuaT API CM A, and B pushbuttons for RRCS Divisions i and toachieve (Opened PilotScramVaTves) toB w e tOo (Reset RPS)) dot MAAuuTnpAPS Tnp ts im«n4«>a* to
(kiferecBtates (Tnppeu InResetRode CTearedTripLogle) doc (♦> InRetetRode (Totnfmr ((Lighted TripSystes-A White Lights) (Lighted TrlpSystem-B White Lights) (Closed PllotScramValves) (Closed BackupScramvaTvot) (Opened SDVVencVaTves) (Opened SDVDralnvaTves) (Drained SOV)) ToAchiewe (Reset RPS)) Tripped (Toinfer ((Opened PiTotScramVaTves) (Inserted ConiroTRods)) ToAcMev* (Trip RPS)))) (InstanteVarlabTes (TripRPS TrlpRPSTnpAôiôS doc i.» iv aoaea oy snAhMi.) (RetetP.PS ResetRPSResetAaaiO aoc .• iv m o m s m a a m a .i (Trip RPSTrlpDoflacKUpAaeSl doc «,* iv aoooo oy s m a a m a i ) (Reset RPSResetDoAnyOneA809S doc >,• iv aooao ey s m a a m a ,./) ) 100 4.3 KNOWLEDGE TYPES AND REPRESENTATION
The knowledge required for procedure synthesis consists of knowledge for describing; the state of the system, changes in the qrstem state, time dependent relationships between system states, operator actions and plans, and time dependent relatiohships between actions, and time dependent relationships between system states and actions. In this section various knowledge types used for DPS and their representation in DPSRL is discussed.
4.3.1 Knowledge about System Status
System status is defined by specifying the value of various system variables
(such as sensor and alarm data) and the status of various subsystems. In the NPP and other process plant domain system state variables consist of various plant variables (e.g.. Reactor Power, FW Flow Rate, Control Rods Position, etc.), the
operating status of various plant qrstems and components (e.g.. Status of Main
Turbine, status of emergency cooling systems, etc.), and time.
Three basic tasks performed by operators in reasoning about the system status
are:
• to determine the state of various Q^tem variables and sub^stems, such as determining: Js the Reactor Fewer greater than 105 %?,
• to in terp ret the state of various system variables and subsystems in terms of conclusions about the system status, such as: Is Reactor in a Shutdown State?, 101
• to determine the number of certain subsystems in 2 certain state, such as: Number of Tripped Recirojiation Pumps.
In DPSRL expressions of the type is Reactor Power greater than 105
%? are called Conditions, expressions of the type is Reactor in a Shutdown
S ta te? are called Predicates, and expressions of the type Number of Tripped
Rœircuiation Pumps are called Functions. Conditions are evaluated to be True or False by comparing the value of the state variable with the measured value by the plant sensors. Predicates are evaluated to be True or False and often require an evaluation of a complex set of conditions. The value of a function is either a number or a tymbol and often requires simple data processing operations on the available data. Both the conditions and predicates can use functions and vice versa. DPSRL contains mechanisms to evaluate conditions. The knowledge required to evaluate predicates and functions are typically declared as InferedStates in the plan frames (see Figures 7, 8, and 9).
Representation of Conditions
In reasoning about system status it is required to determine the truth of a specified relationship between a system variable and some specified value. A condition is typically expressed as:
Often the value is a number, however, the value can be any tymbol or a function 102 whose value is a either a number or a value. A condition is evaluated by checking if the specified relationship holds true between the system-variable and the value.
In DPSRL several types of relationships can be evaluated, such as. equal to (=). greater then (gt, GT. >). less than (It, LT, <). equal to and greater than (ge. GE). less than an equal to (le. LE).
Examples of simple conditions are: (ReactorPower > 105 %) (ReactorPressure < 1000 psi)
For abstracting high level interpretation of a system state it is often required to evaluate the value of a set of conditions according to some logic. Compound conditions are defined using various logical relationships. An example of a compound condition is the entry conditions for the safety goal Maintain Core integrity Safety Function.
[OR (RPV.WaterLevel < 159.3 in) (RPV.Pressure > 1037 psig) (SuppressionPool.Pressure > 1.68 psig) [a n d (RequiredScran Reactor) [o r (Reactor.Power > 105 %) (UnKnown Reactor.Power)]]]
Sometimes the system variable itself can be- another condition, such-as ((DurationOf (FWFlow < 22 %)) > 1 5 secs)
In this example, the inner condition (FWFlow < 22 %) is embedded in a temporal 103 function DurationOf which is a part of another condition. In DPSRL many such structures are possible.
Representation of Predicates
It is often required to express the knowledge about the state of a system in terms of high level interpretation of the system status. For example, it is often required to determine the availability of a system. Although, determining availability requires evaluating a complex set of conditions, it is useful to express the plan synthesis knowledge at a higher level of system status rather than at the low level of sensor data based conditions. In DPSRL such knowledge is expressed as predicates. A predicate is an expression of the form:
The variable can either be a system variable or a system name. For example, in the previous example the following predicate expression are used:
(RequiredScran Reactor) which means: Is Reactor Scram required?
(Unknown Reactor.Power) which means: Is Reactor Power unknown?
Often a predicate is a pair of symbols. In some situations a predicate can be a triplet of the form:
[a n d (doNotFollow FWValves MasterController) (OR (TransientFlow FWTrains) (instableFlow FWTrains)]
DPSRL also allows to write this as:
[a n d (FWValves doNotFollow MasterController) (OR (TransientFlow FWTrains) (InstableFlow FWTrains)]
Renresentins Functions
The syntax for a function is:
(runction-name variable)
Examples of a function and their use in conditions are:
[(NunberOscillating RecircPinnps) “ 1] [(NumberOpen SRV) > 3] 105 4.3.2 Trends and other Temporal Relationships
The dynamic nature of the DPS task requires reasoning about time dependent
conditions and temporal development of plant condition. The general problem of
temporal reasoning is complex and an area of active research in AI [Allen
84] [Allen 85]. In this work we have modeled a few simple aspects of temporal
reasoning in procedure synthesis. Our preliminary analysis has shown that there is a need to express the following types of knowledge:
• Trends of state variables such as: FW Flow is Increasing Reactor Pressure is Oscillating Flow in FW Trains is Transient
• Time of Occurrance of an event such as: RPS Reset Has Occurred
• Time Interval between two incidents such as: Time Lapsed since the In itia tio n of Redundant R eactivity Control System is greater then 25 seconds
• Time dependent relationship between two processes such as: Flow variation in one train is opposite in phase to the flow in other trait.
• Time dependent relation^p between an event and an operator or system action.
In DPSRL, temporal knowledge is expressed in two ways: as a special case of
knowledge about system conditions and predicates, and as specially defined
procedures. 106 Trends
Trends are a special case of conditions and predicates where the status question refers to the change in the value of variable over time. Examples of trends are: (Oscillating ReactorPressure)
(Increasing FWFlow)
(Decreasing MFP.Amps)
To evaluate thœe trends procedures are defined to determine what increasing, decreasing, and oscillating means. Such procedures are often specific to a variable, because, for example, what may be a considered steady trend for Reactor Pressure may be interpreted as oscillating for Main FW Pump current
Knowledge about Temporal Relationships
In DPS the need to reason about the temporal relationship between ±e system variables arises frequently. However, in DPS only a few types of temporal relationships occur. Temporal relationships modeled in DPSRL are:
• HasOccurred? is a predicate which determines if a specified change in system state has already occurred. For Example, 107
[HasOccurred? (Trip RPS)]
the value of this expression is True if by the time of evaluation of this expression the action Trip RPS has occurred.
NatOccurred? is a predicate which is a complement of HasOccurred?
TimeLapsed is a function of two arguments and is similar to function Timelnterval, except that it assumes that the first argument occurred after the second argument For example: [(TimeLapsed (Initiate RRCS)) > 25 secs]
the value of this expression is True if the time passed since the execution of action Initiate RRCS is greater than 25 seconds.
’ Durat/onOf is a function which calculates the duration of certain plant stale being true. For example, in the following condition the duration of system state ''FWFlow < 22 %” is computed:
((DurâtionOf FWFlow < 22 %) > 15 sec)
• OccurranceTime is a function which determines the time of a occurrence of certain change in system state. Often used by predicates described above.
• Timelnterval is a function which takes as argument two specified changes in system state and determines the time passed between their occurrence. Often used by the predicates described above. 108 4.3.3 Diagnostic Knowledge
To accomplish the DPS task, diagnostic knowledge is used for two specific purposes: First, to search a feasible plan, and second to eliminate plan steps that will fail because of unfavorable system conditions. To search for a feasible plan it is required to evaluate various entry conditions for the event and goal plans.
Checking entry conditions require evaluating predefined conditions and predicates.
Sometimes, the conditions and predicates require performing diagnosis such as: FW Flow is ABNORMAL because FW Valve failed to respond to Controller setpoint changes.
Instrument air UNAVAILABLE due to a Balance of Plant Isolation
To eliminate plan steps that might fail, it is required to determine the status of key components required for the successful execution of the plan step. For example the following diagnostic knowledge prevents the selection of turbine driven
FW pumiB: FW Pump Trip caused by the loss of lube oil
Turbine driven FW pump are Unavailable because of Main Steam Line Isolation
In the current implementation of DPSRL, di^nostic knowledge is expressed as conditions, for example. 109
[(CauseOf FWPuap Trip) * (LossOf LubeOil)]
in this example the evaluation of special function CauseOf will trigger the diagnostic process.
The evaluation of the diagnostic knowledge needs powerful organization of diagnostic cat%ories as discussed in sections 3.2.2 and 3.3.3.
4.3.4 Knowledge about Plans
To synthesize and execute a successful procedure requires reasoning about how to select the plan, the structure of the plans, and the goals of the plan. To perform these tasks the following types of knowledge about a plan are required.
Knowledge about Actions and their Sequence in Plans
A plan is an ordered sequence of goals and actions. In the domain of the
NPP and process plants there are several predefined well tested procedures. Based upon an analysis of procedures in NPP we have identified several types of sequences. A plan is represented as:
If the operator specifies the order in which the actions are to be executed then, in DPSRL, the plan is referred to as a Compound Plan. All other plans are referred to as simple Plans. 110 Simple Plans: Simple plans are syntactically a single step action such as:
^operator systerr-name/systenr-feature>
Examples of a simple plan are: (Start PressureReliefSystem) (Scram Reactor) (Shutdown FWPumps) (Reduce Reactor.Power)
Simple plans can be expanded if their detail plans are defined. In a NPP, a simple plan once executed may not be re-executable because of certain engineering desigi considerations. To accomodate such actions three types of simple actions are recognized: Not repeatable in run-time, rep ea ta b le after executing certain predefined actions, and re p e titiv e actions. The repeatability of an action is declared in the specification of a plan. Some special primitive operators defined are: Exit to describe the step of abondoning a procedure, ExitTo to describe the abandoning of an action and start execution of another action, and MakeTrue to describe an action to achieve a certain goal
The knowledge on how to determine the availability, executability, and how to
find an alternative action to a simple plan is defined in terms of procedures. In
DPSRL such procedures are defined. I l l Compound Plan: The ^ ta x of a compound plan is:
where, the notation actions - " stands for a variable number of actions.
In compound plans, the sequence operator is a symbol with a specific
interpretation on how to execute the actions. For example, in the compound plan;
[DoSequence (Start FWPumps) (Start HPCS) (Start FWBoosterPusps)]
DoSequence is the sequence operator which implies that the actions Start
FWPumps, Start HPCS, and Start FWBocsterPumps should be executed in the
specified sequence.
The interpretation of the operator is done by the various problem solvers
discussed in section PSMECHANISMS. For example, the problem solver for Plan
Generation evaluates the availability of an expanded plan differently for different
sequence operators. The problem solver for Plan Execution mechanism assigns
three types of interpretation to a sequence operator
• it specifies the order in which the actions are to be executed;
• it specifies how to determine the success of the plan based upon the success or failure of the plan; and 112 • it specifies what to do if an action of the plan fails.
The Failure R&xn/ery mechanism utilizes the the sequence operator to determine which of the failed actions should be recovered. The sequence not only defines the order in which to execute the action but also how to determine the failure/success of the action and what to do if the plan fails. Sequence operators currently defined in DPSRL are described in the following paragraphs
Sequence Operators in DPSRL
DoSeqnenceAU
Consider the following plan which is a part of the procedure for responding to the event Lost Recirculation Pump:
[DoSeqnenceAU (Verify Shutdown Reactor) (Verify Tripped Main Turbine) (Verify Tripped Reactor Feed Pump) (Verify Tripped Main Feed Pumps)]
The sequence operator DoSequenceAH is interpreted by the Plan
Execution problem solver to mean that for the success of this plan all the actions should be executed successfuUy in the specified sequence. Failure to execute any action requires that the failed action be recovered before executing the next action. 113 DoSequence
DoSequence is similar to DoSequenceAU except that if an action fails then subsequent actions can be executed before recovering from the failed action.
However, for the plan to succeed the failed action diould be recovered.
DoTogetherAll
DoTogetherAU is similar to DoSequenceAU except that for the success of the plan all the actions should be executed simultaneously. Failure to execute any action requires that the failed action be recovered before proceeding with the execution of other actions.
DoT%ether
DoTogether is similar to DoSequmce, except that it requires concurrent execution of all the actions
DoBackUp
Let us consider the following procedure for opening the pilot scram valves: 114
[DoBackUp (Trip RPS) (De-Energize Pilot Scram Valves Solenoid) (Energize Backup Scram Valves Solenoid) (Initiate ARI)]
The sequence operator DoBackUp implies that the specified actions are alternative actions. The sequence of the actions specifies the order in which the actions should be tried. DoBackUp operator is interpreted to mean that for the success of the plan at least one of the actions should be executed successfully. If an action fails then, instead of trying to recover from the failure, the next action in the specified sequence is executed.
DoMonitor
Consider the following procedure which is a part of procedure to respond to the event Open Safety Relief Vaive.
[DoMonitor ((SuppPool.Level > 18.5 ft) -> (ExitTo (Achieve SuppPoolLevelControl) ) ((SuppPool.Temp > 95 F) -> (ExitTo (Achieve SuppPoolTempControl))]
This procedure represents a special case. Unlike other procedures which result in an action on the system as soon as they are executed, the execution of this procedure results in the creation of the following two procedures: 115
blanspaceC 1 line) Monitor the values of Suppression Pool Level and Temperature in p a ra lle l to other system actions, and:
W h e n SuppPool .Level > 18.5 becomes True Then Terminate specified actions and Start executing procedure to achieve goal SuppPoolLevelControl.
Wh e n SuppPool.Temp > 95 F becomes True Then Terminate specified actions and start executing procedure to achieve SuppPoolTempControl.
The operator DoM onitor is defined to handle such a special case. Execution of a DoMonitor action requires that the ^stem state be continuously monitored for the specified conditions and the action be executed when the desired condition is realized.
DoTracking
DoTracldng is similar to DoMonitor. except that instead of monitoring a single condition the procedure requires tracking the changes in a specific variable
and executing various actions. For example, in the following simplified procedure
for maintaining safety goal Rsacxivity Control, the variable Reactor.Power is
being tracked: 116
[DoTracking [(Reactor.Power GE 105 %) -> (DoBackUp (Initiate AR) (Runback RecircFiow))] [(a n d (Reactor.Power < 105 %) (ControlRods.Position ••G)) -> (PostScram Reactor)]]
Two more sequence operators of interest are: DoAsMany and DoAnyOne.
DoAsM any operator defines a sequence of actions. For the success of the plan it is required that at least one of the actions be successful, however, it is desirable to execute as many actions as possible. DoAnyOne operator defines equivalent alternatives. The plan succeeds if any action is successfully executed.
Knowledge about Goals
In specifying a plan, the knowledge about the goals of the plan is important to make at least three types of decision:
• Is the goal of the plan already true?
• Is the goal of the plan true after the execution of the plan?
® If the plan fails then finding an executable alternative to achieve the same goal
The goals of the plan are usually conditions that should be made true. In DPS the two types of goals identified in section 3.3.5 are: 117
• Achieve Goals: Goals that are not true before the execution and are made true after the execution achieved by «ecuting the plan. Failure of a plan whose goal is achieve goal will leave the goal in the false condition. For example, a procedure for responding to a recirculation flow control malfunction contains the following plan:
[DoSequence (Balance RecircLoopFlow) (Insert ControlRods) toachieve (Decreased Reactor.Power)]
In this example, the goal (Decreased Reactor.Power) specifies a condition to be achieved by the plan.
• Maintain Goals: Goals that are true before the execution of the action and are maintained true by executing the action. Failure of a plan whose goal is maintain goal causes the goal to become false. For example, the procedure to respond to the event of FW Pump trip contains the following plan step:
[s ta rt Available.FWPumps tomaintain (Achieved RPVWaterLevelControl)]
In this example, the goal (Achieved RPVWaterLevelControl) is a safety goal which should be kept true during all conditions. The action of starting FW pumps is required both to achieve the safety goal, and if it is already true, men to maintain it.
Knowledge required to Select Plans
To accomplish the DPS task there are three basic ways to select a plan.
First, the event and goal plans are selected if pre-defined plant conditions (called entry conditions) are true. The example on page 102 shows entry conditions for selecting the plan for the safety goal Maintain Core Intergrity. Second, the system 118 plans are selected by explicitly retrievmg them. Third, the goal plans are selected by retrieving plans for goals to be achieved.
Representation of a Plan A plan is represented as a frame with several slots as shown Figure 10.
In DPSRL, a simple syntax is provided to write procedures as shown in several examples. The syntax is: (operator - actions - - other-attributes -)
The other attributes of the plan essentially correspond to the different slots of the frame shown in Figure 10. The DPSRL provides a set of easily readable key words to specify these attributes. For example: [DoSequence actio n s
toachieve achieve-goal
if preconditions
notif exclude-conditions
tomaintain maintain-goal
ToResetDo re se t-a c tio n ]
DPSRL parses such a description of a plan and creates a plan frame. 119
Figure l(k A Typical Plan Frame
Plan: unique plan nam* or a plan id
Operator: specifies the order in which the actions should be performed or defines the operation.
Objects: a system or component on which the operation is performed or other plans.
TriggerCond: a heuristic condition(s) used to recommend this plan.
PreCond: a system state(s) that should be true to execute this plan.
ExeludeCond: a system state(s) which if true require that this plan should not be executed.
AchieveGoal: the goal(s) to be achieved by the execution of this plan.
HaintainGoal: the goal(s) to be maintained by the execution of this plan.
Effects: changes in the system state as a result of this action.
ResetAction: specifies the required action to reset system state before re-executing this plan.
RecoverFailure: specifies the control on failure recovery process should this plan fail.
FailureMode: specifies the cause of failure of the plan to be used by the failure recovery process.
ExecutionHistory: keeps a record of idien the plan was first used and when was it used last.
Status: specifies if the plan is currently under execution. 120 Interpretation of Plans bv different Problem Solvers
DPSRL includes the various problem solving mechanisms required for DPS.
The outcome of a problem solving mechanism depends upon the several declared properties of a plan. In a sense, problem solvers are special purpose interpreters of the plan data structure discussed in section 4.3.4. Plan features that govern the outcome of problem solvers are:
• O perator: The response of various problems solvers is different for different operators.
• TriggerCond: While executing a plan, the Plan Execution problemsolver will exclude all plan steps whose TriggerCond is not True.
• PreCond: While executing a plan, if the PreCond of a plan step is not True then the Plan Execution problem solver concludes that the plan step has failed and its executable alternative needs be synthesized.
• BxciudeCond: While executing a plan, the Plan Execution problem solver will not execute actions whose ExeludeCond is True.
• AchieveGoal: If the AchieveGoal of an action is True then the Plan Execution problem solver will not execute it. If the AchieveGoal is not true then the action will be executed and the success of execution is determined by checking the value of AchieveGoal subsequent to the execution. If the AchieveGoal is still not True, then the action is presumed to have failed and an alternative action to make AchieveGoal True is synthesized.
• MairtainGoal: Similar to AchieveGoal, except that the action is executed even if the MaintainGoal is initially True. Plan Execution problem solver interprets MaintainGoal to mean that the action should be executed to either make MaintainGoal True or to keep it in a True state.
• E ffects: If the goal for an action is not defined than Effects are used as the Goal to determine the executability and success of the execution of the action. 121 • ResetAction: ReseiAction can take values NIL, NotResetable, and a plan. The value NIL refers to an which needs no rest action for re execution. NotResetable refers to actions which cannot be re-executed in run-time. If a reset action plan is specified then reset action should be before attempting a re-execution of the plan.
• RecoverFailure: If ResetFailure is NIL than it implies that the action, if failed, should not be recovered.
• Statu s: Status specifies if the action is available. In expanding a plan, the Plan Generation problem solver will exclude actions with status NIL
4.3,5 Control Knowledge
In performing the DPS task based on the theorj’ described so far, there is a potential problem of maintaining the focus of the problem solving process. In this section some of the potential focus problems and the control knowledge required
to solve them are discussed.
Selecting the Next Executable Action
In the DPS theory, failure to execute a selected action requires solving the
failure recovery problem. The failure recovery process requires searching for an executable alternative which, in some situations, can cause a certain d ^ e e of focus
problem. The problem solving process can be improved if the potential failure of
the action can be anticipated at the time of selecting the action. A selected action
is not executed if there is a reason to believe that, it will be ineffective in
accomplishing its intended function. In general determining the potential 122 effectiveness requires predictive capability. However, in a NPP. for a certain class of actions it is possible to anticipate the failure of certain actions at the time of selection using domain specific knowledge.
In a nuclear power plant, by design, not all actions are immediately repeatable once they are executed. The predefined actions in a NPP belong to one of the following three classes;
® Nat Repeatable: Class of actions which cannot be re-executed during runtime.
• Repeatable: Class of actions which can be re-executed, but, require that certain reset actions be executed before attempting a second execution.
• Repetitive: Class of actions that can be re-executed without any restriction.
Actions declared to be not repeatable are not selected once they are executed. For the repeatable and repetitive actions, there is still a problem to determine if the re-execution of the action will be successful In DPSRL, a repeatable or a repetitive action is assumed to be effective if it was successful in previous execution. If the action failed and its goal had to be recovered then the particular action is not selected. Thus apart from knowing whether the action is re-executable or not, it is also necessary to know the result of its previous execution.
Preventing Indefinite Failure Recovery Process
It is possible for the planning system to be trapped in pursuing a low level goal. 123 Le., finding alternatives to a failed action, and alternatives to alternatives, if they don’t succeed. This is, in general, not a problem if the high level goals (in case of
NPP, the safety goals) are not challenged. A control problem occurrs, if a high level goal is threatened while the procedure synthesizer is pursuing a low level goal The control over this situation can be obtained by;
• recognizing that a global or a higher level goal has been challenged,
• recognizing that a subgoal of the h i^er level goal is being pursued,
• interrupting all active actions or plans directed towards achieving the local goal, and
• activating the plans for achieveing the higher level goal
Implemmitatio]) of this solution has not been implemented in the current version of DPSRL.
Selecting Goals to Achieve dnring paHiw geeovery
There are two types of problem in selecting the goals to be achieved. The first problem occurs because of the defined logic for failure recovery. If an action fails, then the procedure synthesizer attempts to recover from failure by searching for actions to achieve the goal of the failed plan. For some procedures, required to bypass the failure recovery process for the subplans, instead try to achieve the goal of the parent procedure. In DPSRL, the specification of a plan contains a slot called FixSubActions. If the value is this slot is specified as NIL then the failure 124 recovery of the subactions is not attempted. For example, consider the following
procedure which is a part of a plan for Inserting the Control Rods:
[(RPV.Pressure > 1500 psig) -> (DoSequenceAU (Decrease RPV.Pressure toachieve (RPV.Pressure < 1500 psig)) (Open PilotScranValves) toachieve (Inserted ControlRods) nofix)]
In this example, the keyword nofix specifies that if any of the subactions
Decrease RPV.Pressure or Open PilotScramValves fails, then the failure
recover process should ignore their failure, and try to recover the goal Inserted
ControlRods. V^thout the option nofix, the failure of action Decrease
•RPV.Failure will intiate recovery process for goal RPV.Pressure < 1500. Since,
Inserted ControlRods is a significant goal, it is desired to directly achieve that
goal instead of trying to recover c secondary goal, thus requiring the use of option
nofix.
The second problem occurs, when the failure recovery process falls into a
loop by suggesting the failed action as its own solution. The loop problem occurs
bœause their exists a symmetrical relationship between a goal and plans to achieve
the goal For example: 125
Plan 1 To Achieve Goal; Inserted Control Rods Execute Action : Manual Scram or Trip RPS
Plan 2 Execute Action : Manual Scram To Cause Effect: Inserted Control Rods
Such symmetrical relations, where an action is means to achieve its own goal,
cause the loop problem. One possible solution to this problem is not to use them
in a knowledge base. However, symmetrical relations are in general useful, and
cause no problem when only one way of the two plans is used. For example; if some other plan calls to achieve the goal Inserted ControlRods then
ManualScram is a perfectly valid solution.
In simple situations such relationships can be identified during knowledge
encoding and avoided by explicitly suppressing Failure Recovery mechanism. Such
a solution is not satisfactory (although can be exploited where convenient) because,
the loop relationships can be synthesized in runtime. A more practical approach
is to remember the action under execution and avoid it during the failure recovery
thus avoiding potential loop. In DPSRL, the representation of a plan contains a
slot named Activated. On starting the execution of a plan the value of slot
Activated is set equal to True. When the plan is exited the value is reset to NIL.
During a failure recovery process, all activated actions are not selected. 126 4.4 IMPLEMENTATION OF DPSRL
DPSRL is a higii level programming language for representing planning knowledge required for the dynamic procedure synthesis (DPS) framework. As discussed in section 4.2, planning knowledge consists of knowledge about system state, temporal knowledge, predefined plans, goals and effects of a plan, and d i^o stic knowledge. DPSRL thus provides representation primitives to express plans typical to the operation of a process plant or a power plant, system states, and necessary problem solving mechanisms required for the dynamic ^th esis of procedures.
In principle, DPSRL can be implemented in any programming language, but the highly symbolic nature of the knowledge requires capabilities for symbolic processing, including powerful features for data abstraction, recursion, and dynamic memory allocation. Various dialects of LISP provide these features. The current version of DPSRL is implemented in Interlisp-D [Xerox 83], a dialect of Lisp which run on Xerox Lisp workstations, and LOOPS [Bobrow 83]. LOOPS is a
Interlisp-D based object oriented language which is similar to SMALLTALK in many features. LOOPS provides a powerful environment for designing large modular knowledge based systems. 127 .4.1 Background
A computational process specifies a sequence of steps to solve a specific task.
A programming la n g u ^ provides a systematic notation and computational primitives by which we can describe and automate the computational process on a computer. Different programming languages differ in the manner they describe a computational process. Traditional languages such as FORTRAN and LISP describe the computational process in terms of procedures (or control) and data. In
FORTRAN the procedures are specified as a sequence of executable steps. In US? the procedures and control are specified as a process of applying functions to specified arguments. In object oriented languages (like SMALLTALK and LOOPS) the computational process is modeled as a collection of objects that have their own procedures and data. These objects interact by passing messages to each other. In
AI languages the computational process is described in terms of problem solving primitives and mechanisms. DPSRL is an example of an AJ Iangu%e which is implemented using a procedural language (InterLisp-D) and object oriented language
(LOOPS).
In LOOPS, an object is a programming construct with some local memory and local operations. An object representing a pump stores design and operation data about a pump and operations (called methods) to specify how to start a pump, change its speed, and how to repair iL A message is a request to an object to perform a specific operation. The message specifies the desired operation 128 and not how the operation should be performed. The receiving object determines how to perform the operation. For example, a message to object pump can be reduce sp^d hy 20 %. The object pump then computes what desired speed is and applies the appropriate operation to perform the request made by the message.
In modelling real world situation it is often required to model the properties of a class of objects, such as a Pump. It is also desired to model special cases of a pump such as a Centrifugal Pump. It is also desired to specify examples of a class such as Pump-1 and CentrifugalPump-A. LCX)PS provides mechanisms and programming constructs to accomplish this task. In class Pump one specifies data and operations to be shared by all member of the class. A subclass, such as
CentrifugalPump, is a specialization of class Pump and contains modified data and operations required for its own subclass. Examples such as Pump-A are called instances and inherit all the data and operations of the class Pump. Similarly, instance CentrifugalPump-A inherits all the data and operations of class
Centrif ugalPump. Classes themselves are instances of another class called MetaClass.
In LOOPS an instance of a class can receive messages to perform an operation defined in its class. Normally, a class does not respond to a message that requires performing operations attached to iL Operations to be performed by a class are defined in a Meta Class where the class is an instance of the meta class. 129 4.4^ The DPSRL Program
Figure 11 shows a top view of the objKîs and their relationships in DPSRL.
The three major components are:
• the core DPSRL consisting of various objects and procedures,
• application specific knowledge objects consisting essentially of plan libraries defined by the user, and
• a application specific library of compiled procedures generated by DPSRL using the plan libraries defined by the user.
The DPSRL Core
The core of DPSRL consists of several tj^jes of objects (metaclasses, classes, subclasses, and instances) and procedures or methods to support the design of an application based on the DPS theory. The procedures defined include: procedures for intial setup, procedures for accessing data from DPSRL and application specific knowledge objects, procedures for interpreting and evaluating various types of knowledge expressions dicussed in section 4.3, and procedures for implementing problem solving statues discussed in section 3.3.5. As described in section 4.4.1, implementing programs in an object oriented language provides an efficient way of sharing data and/or procedures using the inheritance mechanism. In the following paragraphs an overview of various objects and procedures is provided.
DPSRL Meta Classes 130 Figure 11; DPSRL Objects
MetaPlanner
MetaSynthesizer PlanLibMeta
SystemLibMeta GoalLibMeta
Application Specific Plan Libraries
Goals Plan Goal Plan Libraries
Synthesizer Events Plan Event Plan Libraries
Systems Plan System Plan Libraries DataBase Action
Application Specific Compiled Plans
Legend X ------^ y : y is a SUBCLASS of x
X ------> y : y is an INSTANCE of x 131 The principal meta class MetaPlanner contains methods required for intially setting up the application specific compiled plans library, information retrieval methods to access information from application specific plan library classes, and some methods to test the nature of a plan, and conditions in support of the problem solving process. The intial setup procedures parse a procedure description show below and create a set of objects of the type shown in Figure 12 which are essentially an instance of the class Action or its subclasses shown in Figure 11.
The subclass PlanLibMeta shown in Figure 13 contains procedural knowledge and information retrieval methods for Goal Plans, Event Plans, and System Plans.
The information to be retrieved typically consists of predefined procedures, predicates for inferred stated, and the enter conditions. The procedures for retrieving predefined procedures is used for plan selection, generation, and systhesis. The first few steps in DPS require idratification of plans to be executed, and if there are more than one plan then a compound plan has to be syntheâzed. The mcta class SynthesisMeta contains methods for identifying and synthesizing compound plans.
DPSRL Classes for Plan library
There are three basic plan library classes defined: GoalPlans, SystemPlans, Event and Parameter Plans. Thae classes are instances of the meta class PlanLibMeta.
These classes provide the direct interface for developing the application specific 132 Figure 12: A Typical Compiled Plan Object
DEditngf INSTANCES #$FWPumpTripLiinit:Re Class^nheritance Lattice GoaiHansMeta PlanLibMeta MetaPlanner SystemPlansMeta SynthesisMeta Figure 13: DPSRL Meta Class MetaPlanner application specific plans library. New classes can be easily defined by creating new instances of the meta class PlanLibMeta. In the NPP application described in the next chapter two other plan library classes defined are: ParameterPlans and SymptomaticPlans. Plan Library classes inherit procedures from their respective meta classes. Figures 7 , 8, and 9 show typical examples of these classes. More examples are shown in Appendix A. DPSRL Class Action Class Action provides much of the knowledge for problem solving in DPSRL. All the plans (predefined and those synthesized in runtime) in DPSRL are compiled as an instance of the class Action or one of its subclasses. The class Action has two major subclasses: Procedure to describe simple single step actions of the type described as simple pians in section 4.3.4, and M-Operator to describe compound plans to describe plans that specify a sequence of actions. Several specializations of these subclasses are defined (see figure 14. 1 3 4 Figure 14: DPSRL Class Action and its Subclasses Glass Inheritance Lattice NotRepeatable ProcTemplate R epetitive / P rocedure R esetabie Exit SpeciaiActs ExitTo M akeTrue Action OoAnyGne AltOperator DoAsMany DoBackUp M -O perator DoMonitor DoSequenceAU - DoSequence DoTogetherAil - D oTogether OoTracking 135 A Procedure can be NotRepeatable once it is executed, it may be Resetabie requiring execution of some reset actions, or it may be Repetitive requiring no special action before re-execution. Some special actions defined arc Exit to describe abandoning of a procedure, ExitTo to describe abandoning a procedure and starting execution of another procedure, and MakeTrue which is required to find a plan to make true specified system condition. Similarly, the subclass M - Operator is specialized into several subclasses. Methods defined for class Action are primarily problem solving procedures. Some of the key methods determine if the action is available, executable, was it successful after execution, and how to find an executable alternative to a failed action. DPSRL Class DataBase The DataBase class provides methods for interpreting and evaluating various conditions and predicates defined in the plans. Ideally, the evaluation of conditions and predicates should be done using online data from a real system or a simulation of a system. In lack of either facility, DPSRL utilizes a simple representation of a transient described by subclass Transient and stores the record of operator responses in subclass Operation^ecord. Some of the plans requires access to certain plan design data. Such data is declared in subclass DesignData (see Figure 15). 136 Glass Inheritance Lattice- PatternMatcher Dummy D ataB ase OperationsRecord T ransient DesignKB Figure 15: PSRL Class DataBase Application Specific Knowledge Objects As discussed above, the classes GoalPlans. EventPlans, and SystemPlans provide an interface for defining application specific plan library. Application specific plan library objects are exxentially subclasses of these classes. It is also possible to define structural relationships between the knowledge objects. Examples of knowledge objects are shown in Chapter 5 and later in this chapter in section 4.5 Application Specific library of Compiled Plans The compiled plans are essentially instances of class Action and provide an efficient way for accessing information about the plans necessary for plan selection and ^thesis. 137 4.5 AN EXAMPLE OF THE APPLICATION OF DPSRL For specificity, let us consider the scenario of a reactor scram. A nuclear power plant is required to be shutdown if a plant condition indicating potential for core meltdown exists. The procedure used for plan shutdown under such conditions is an event plan called Reactor Scram. Here we assume that conditions exist for reactor scram but the automatic control systems have failed to initiate a scram. A simplified procedure for Reactor Scram is: Simplified Procédure for Event Reactor Scram [(ReactorPower > 105 %) -> (DoSequenceAU (Trip EPS (PostScram Reactor) tomaintain (Achieved ReactivityControl))] In this example various plans are as follows: • GoalPlans: ReactivityCntrl • EvmitPlans: Reactor Scram • SystemPlans: Trip RPS, PostScram Reactor, Open Pilot Scram Valves etc. Graphical illustration of procedures used in this scenario is shown in Figure 16 The goal Reactivity Control links the event plan for Reactor Scram with the goal plan for the goal Reactivity Control. 138 Figure 16: Procedures used for the Synthesis in the Reactor Scram Scenario Success Paths^ For Scram-Reactor^- PostScram (Reactor } DoSequenceAU Trip (RPS) Success Paths For the Goal (Opene^PilptScramMalwes), !nitiate(ARI} Energize (BackupScarm Val vesSoienoid ) DoBackUp DeEnergize (PilotScram VaivesSoIenoid ) Trip (RPS) Success Paths For the Goal (Inserted, GontrolRods) Open(Pi!otScramValves ) ./! DoSequenceAU / —— — —— — Decrease (RPV.Pressure) ^ ManualScram(ScramSystern) Trip (RPS) DoBackUp Reset(ARI) X < Reset(RPS) Dpen (PilotScram Val ves } Trip(RPS) 139 Problem Analysis using DPS Approach Let us assume that the condition (ReactorPower > 105 %) is True thus recommending the selection of the procedure for Reactor Scram. Using the plan template for Reactor Scram the task of plan synthesis requires synthesizing an executable procedure to successfully achieve the ^>al Reactivity Control In the DPS approach qmthesizing such a procedure requires reasoning about the following questions: 1. Is the procedure (Reactor Scram) needed? On one hand the procedure is needed because the entry condition (ReactorPower > 105 %) is True. However, the procedure is not needed if the goal is already True 1 Is the procedure (Reactor Scram) available? The procedure for Reactor Scram is available if there is no a priori reason to believe that the necessary primitive plans are not executable 3. Is the procedure (Reactor Scram) Executable? The procedure for Reactor Scram is executable if the preconditions are true and necessary primitive plans are executable 4. Which action to execute next? The procedure for Reactor Scram clearly indicates that action Trip RPS should be executed first. 5. Is the executed action successful? The executed action Trip RPS is successful if the goal of action is achieved. The goal of Trip RPS is specified in its expansion. 6. W hat to do if the action is not successful? For the Reactor Scram to be successful the action Trip RPS must be successful Thus if Trip RPS fails an alternative action has to be found. 7. Hew to find alternative for the failed action? An alternative is found to achieve the goal of ' failed action Trip RPS, le.. Open PilotScramValves. If an executable alternative is found then it is executed. 140 8. What to do if the failed action cannot be recovered? If Trip RPS cannot be recovered then the procedure Reactor Scram cannot achieve the goal Reactivity Control An alternative action is required to achieve the function Reactivity Control and «ecuted if found. If the alternative cannot be found then the procedure for Maintain Core Int^rity (super function of Reactivity Control from the goal hierarchy) is executed. Procedure Synthesis for Reactor Scram The trace pf the procedure synthesis scenario shown below is generated using DPSRL using various problem solvers included in the DPS approach, specifically, plant status monitoring (rSM), plan selection and scheduling (FSS), plan generation (PG), plan execution (PE), and failure recovery (PR). In the trace all the comments and instructions are generated by DPSRL. Comments in the brackets are not generated by DPSRL and are included to summarize the operation of the program. In this sample example several pre-defined procedures are t%ed by the Planning System to synthesize a plan for the operator shown in Figure 17. The qmthesized plan is not a pre-specified plan and has been synthesized in response to the dynamics of the Reactor and user actions. This example also shows the failure recovery behavior and the compliance to the defense-in-depth philosophy. Using this planning system the user although unsuccessful in executing the intial action was ultimately successful in shutting down the reactor. 141 Figure 17: Synthesized Procedure for Reactor S c r a m fzLgoalof Start TnpHPSis RzScrma Opta«d PUot Scr&n r > . ValvM Start Op#a Pilot Scram Valvat PE Selects . Energize Backnp Scarm VaivesSoIenoid failed failed PE rajoctasaquaaea . rt raiacis , ^ Hasat RPS.BaaatABI. * TnpRPS OpaaPSV aad TnpRPS yE Selects PE Selects saqueaca Manual SC ram Decrease Pressure and üiled Open PSV failed PE FA: no achia vaabia goals daclarad for TR lasart ControlBods Scram Raactar Failed FR: goal of Scram Raactorit Maintain Raactivity Control 142 DPS is Implemented using the DPSRL High Level Language This is a trace of an Example Scenario Following Abbreviations are Used for Various Problem Solving Mechanisms; PSM : Plant Status Monitoring PSS : Procedure Selection and Scheduling PG : Procedure Generation PE : Procedure Execution FR : Failure Recovery DYNAMIC PROCEDURE SYNTHESIZER INITIATED > > PSM: Checking Goals > > PSM: Checking Events > > PSM: Checking Events Reactor Scram Is (AlarmOn FullScram) True?--> y Is (AlarmOn RPS Manual Scram) True?~> y > > PSM: Event Reactor Scram Established = > NOTE; The PSM Problem Solver checks the entry conditions for ail the goal and event plans. It finds that the entry conditions for the event Reactor Scram are True. The DPS top level control informs PSS that a certain event needs corrective actions. > > PSS: Retrieving Plan for Event Reactor Scram > > PSS: Single Event therefore No Scheduling Required > > PG: Generating a Procedure for Reactor Scram = > NOTE: PG uses the initial plan for Reactor Scram and expands the plan in terms of executable systems procedures. This is done by retrieving the precompiled expansion of plan steps specified in the Reactor Scram procedure and checking the availability of the expanded plan. > > Please Start Execution Interactively 143 = > NOTE: The user initiates the execution of the procedure Reactor Scram. DPSRL will assist the user in execution by checking in runtime the executabiiity of various actions, sepecifying the order for executing various steps, determining their success, and generating executable alternatives if the actions fai I. . PE Ï5 CONSIDERING (Scram Reactor) Checking the Enter Conditions » Enter Conditions are True Checking Goals » Goal is Not Specified Checking Exclude Conditions » Exclude conditions are Not True Determining Executabiiity oh (Scram Reactor) Not Executed Before Generating Procedure for (Scram Reactor) Action is Available Checking Preconditions » Preconditions are True Determining Executabiiity où TripRPS Not Executed Before Action is Available Checking Preconditions » Preconditions are True Determining Executabiiity où (Trip RPS) Not Executed Before Action is Available Checking Preconditions » Preconditions are True Determining Executabiiity of: Depress SHUTDOWN Reactor Mode Switch on Panel P680 Not Executed Before Action is Available Checking Preconditions >> Preconditions are True > > Depress SHUTDOWN Reactor Mode Swhdh on Panel P680is Executable > > (Trip RPS) is Executable Determining Executabiiity of: PostScramReactor Not Executed Before Action is Available Checking Preconditions » Preconditions are True > > PostScramReactor is Executable > > (Scram Reactor) is Executable = > NOTE: Having determined that procedure Scram Reactor is executable, PE selects TripRPS as the first action to be executed. PE IS CONSIDERING TripRPS 144 Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions » Enter Conditions are True Checking Goals Is (Check Control Rods Moving Inside) True?-> n Is (ControlRods.Position = 0) True? — > n » Goals are Not True Checking Exclude Conditions » Exclude conditions are Not True Determining Executabiiity of: TripRPS Not Executed Before Action is Available Checking Preconditions » Preconditions are True Determining Executabiiity o£ (Trip RPS) Not Executed Before Action is Available Checking Preconditions >> Preconditions are True Determining Executabiiity ofc Depress SHUTDOWN Reactor Mode Switch on Panel P680 Not Executed Before Action is Available Checking Preconditions » Preconditions are True > > Depress SHUTDOWN Reactor Mode Switch on Pane! P680 is Executable >>(Trip RPS) is Executable = > NOTE: Checking reset conditions > > PE: Reset Action is Needed Prior to Executing TripRPS > > PE: Searching for the Reset Action Checking the Enter Conditions >> Enter Conditions are True Checking Goals » Goal is Not Specified Is (Lighted TripSystem-A White Lights) True?-> y Is (Lighted TripSystem-B White Lights) True?-> y Is (Closed AllPilotScramValves) True?~> y Is (Closed BackupScramValves) True?--> y Is (Opened SDVVentValves) True?-> y Is (Opened SDVDrain Valves) True? -> y 145 Is (Drained SDV) T ru e? -> y Action not required because goals are already True > > PE: Reset Action Not Needed = > NOTE: Since the effects of the Reset Actions are already true, PE concludes that reset action is not needed. = > NOTE: Prompting the user to execute the selected action = = > Try Trip (RPS) Done? —> n Response is NIL = > NOTE: The user is unable to execute the action resulting in a failureof the action. PE initiates the failure recovery process to find an executable alternative to Trip RPS. Invoking Failure Recovery Problem Solving Process (FR) Finding a Procedure to Achieve the Goals of action :TripRPS Goal to be Achieved is :(Opened PilotScramValves) TripRPS is already active = > NOTE: FR notices that Trip RPS has a goal (Opened PilotScramValves). It retrieves the predefined procedure for opening PilotScramValves from Systems Plan Library and returns it to PE PE IS CONSIDERING (Open PDotScramValves) Checking the Enter Conditions » Enter Conditions are True Checking Goals Is (ControlRods-Position = 0) True? -> n » Goals are Not True Checking Exclude Conditions » Exclude conditions are Not True Determining Executabiiity où (Open PilotScramValves) Not Executed Before Action is Available Checking Preconditions » Preconditions are True Determining Executabiiity of: TripRPS Executed Before TripRPS is not repetitive 146 Determining Executabiiity of: DeEnergizePilotScramValves Not Executed Before Action is Available Checking Preconditions » Preconditions are True > > DeEnergizePilotSramValves ê Executable > >(Open PilotScramValves) is Executable = > NOTE: The procedure for Open Pilot ScramValves has several alternative actions. First action is TripRPS. PE checks and finds th a t Trip RPS isthe failed action it is trying to recover from, therefore, it skips Trip RPS and proceeds with other alternative actions. PE IS CONSIDERING TripRPS Invoking Problem Solving Process Procedure Execution (PE) TripRPS is already active > > PE: TripRPS not executable since already active PE IS CONSIDERING DeEner^ePilotScramValvesSolenoid Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions >> Enter Conditions are True Checking Goals » Goal is Not Specified Checking Exclude Conditions » Exclude conditions are Not True Determining Executabiiity of: DeEnergizePilotScramValvesSolenoid Not Executed Before Action is Available Checking Preconditions >> Preconditions are True > > DeEnergizePilotScramValvesSolenoid is Executable = > NOTE: Execution prompt for the user = = >Try DeEnergize (PilotScramValvesSolenoid) Done? —> n Response is NIL 147 = > NOTE: Since Open PilotScramValves is a DoBackUp Procedure, PE does not try to recover from the failure to execute DeEnergize(PilotScramValvesSolenoid). Instead it selects the next predefined alternative. PE IS CONSIDERING EnergizeBackupScarmValvesSolenoid Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions » Enter Conditions are True Checking Goals » Goal is Not Specified Checking Exclude Conditions » Exclude conditions are Not True Determining Executabiiity oû EnergizeBackupScarmVaivesSoIenoid Not Executed Before Action is Available Checking Preconditions >> Preconditions are True > > EnergizeBackupScarmValvesSolenoid is Executable = > NOTE: Execution prompt for the user = = > Try Energize (BackupScarmValvesSolenoid) Done? —> n Response is NIL = > NOTE: Since Open PilotScramValves is a DoBackUp Procedure, PE does not try to recover from the failure to execute Energize(BackUp Scram VaivesSoIenoid). Instead it selects the next predefined alternative. PE IS CONSIDERING InitiateARI Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions » Enter Conditions are True Checking Goals » Goal is Not Specified Checking Exclude Conditions » Exclude conditions are Not True Determining Executabiiity of: InitiateARI Not Executed Before Action is Available Checking Preconditions » Preconditions are True > > InitiateARI is Executable = > NOTE: Execution Prompt for the user. = = > Try Initiate (ARI) Done? —> n 148 Response is NIL Action Not Successful = > NOTE; The procedure Open PilotScramValves has failed. PE will again initiate a failure recovery process. Invoking Failure Recovery Problem Solving Process (FR) Finding a Procedure to Achieve the Goals of action :(Open PilotScramValves) Goal to he Achieved is :(Inserted ControlRods) TripRPS is already active OpenPi1otScramValves is already active TripRPS is already active = > NOTE: The goal Inserted Control Rods can be achieved by various procedures. FR notes that the candidate procedures Trip RPS and Open PilotScramValves have already failed and thus rejects them. This prevents a potential looping problem as discussed in section 4. FR selects the specified procedure Insert ControlRods and returns it to PE. PE IS CONSIDERING (Insert ControlRods) Checking the Enter Conditions » Enter Conditions are True Checking Goals Is (ControlRods.Position = 0) True?-> n Checking Exclude Conditions » Exclude conditions are Not True Determining Executabiiity of: (Insert ControlRods) Not Executed Before Action is Available Generating Procedure for active action Checking Preconditions » Preconditions are True Determining Executabiiity oh TripRPS Executed Before Trip RPS is already active TripRPS is Not Executable Determining Executabiiity of: (Open PilotScramValves) Executed Before Open PilotScramVanlvas is already active Open PilotScramValves is Not Executable Determining Executabiiity où ResetRPS Not Executed Before Action is Available Checking Preconditions >> Preconditions are True Determining Executabiiity of: (Reset RPS) 149 Not Executed Before Action is Available Checking Preconditions » Preconditions are True Determining Executabiiity où ResetTripRPS Not Executed Before Action is Available Checking Preconditions Is ((TimeLapsed (Trip RPS)) > 10 sec) True? -> y » Preconditions are True > >ResetTripfPS is Executable > > (Reset RPS) is Executable > > ResetRPS s Executable Determining Executabiiity où ResetARI Not Executed Before Action is Available Checking Preconditions » Preconcitions are True > > ResetARI is Executable > > (Insert ControlRods) is Executable PE IS CONSIDERING TripRPS Invoking Problem Solving Process Procedure Execudon (PE) TripRPS is already active > > PE: TripRPS not executable since already acdve PE IS CONSIDERING OpenPilotScramValves Invoking Problem Solving Process Procedure Execudon (PE) OpenPilOtScramValves is already active > > PE: OpenPilotScramValves not executable since already acdve Determining Executabiiity où ResetRPS Not Executed Before Action is Available Checking Preconditions » Preconditions are True Determining Executabiiity où (Reset RPS) Not Executed Before Action is Available Checking Preconditions » Preconditions are True Determining Executabiiity où ResetTripRPS Not Executed Before Action is Available Checking Preconditions 150 Is ((TimeLapsed (Trip RPS)) > 10 sec) True?-> y >> Preconditions are True > > (Reset RPS) is Executable Determining Executabiiity of: ResetARI Not Executed Before Action is Available Checking Preconditions >> Preconditions are True > > ResetARI is Executable Determining Executabiiity où TripRPS Executed Before Trip RPS is already active TripRPS is Not Executable Determining Executabiiity OÙ (ManualScram ScramSystem) Not Executed Before Action is Available Checking Preconditions » Preconditions are True Determining Executabiiity où (Reset ScramSystem) Not executed Before Action is Available Checking Preconditions >> Preconditions are True Determining Executabiiity où (Reset RPS) Not Executed Before Action is Available Checking Preconditions >> Preconditions are True Determining Executabiiity of: ResetTripRPS Not Executed Before Action is Available Checking Preconditions Is ((TimeLapsed (Trip RPS)) > 10 sec) True?~> y » Preconditions are True > > ResetTripRPS is Executable >>(Reset RPS) is Executable . > > (Reset ScramSystem) is Executable Determine Executabiiity où ManualTripRPS Not Executed Before Action is Available Checking Preconditions » Preconditions are True > > ManuaUripRPS is Executable > > (ManualScram ScramSystem) is Executable > > (Insert ControlRods) is Executable PROCEDURE SYNTHESIZER IS CONSIDERING TripRPS Invoking Problem Solving Process Procedure Execution (PE) TripRPS is already active »PE: TripRPS is not executable since already active 151 PROCEDURE SYNTHESIZER IS CONSIDERING OpenPilotScramValves Invoking Problem Solving Process Procedure Execution (PE) OponPilotScrsfliValves is already active > > PE: OpenPilotScramValves is not executable since already active PROCEDURE SYNTHESIZER IS CONSIDERING ManualScramScramSystem Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions » Enter Conditions are True Checking Goals Is (ControlRods.Position = 0) True?~> n » Goals are Not True Checking Exclude Conditions » Exclude conditions are Not True iLTcCcx iitutxüg ujkcC uuiùiiiiy o ii iTitm uatscram scrum sysiem Not Executed Before Action is Available • » Preconditions are True Determining Executabiiity oA (ManualScram ScramSystem) Not Executed Before Generating Procedure for (ManualScram ScramSystem) Action is Available >> Preconditions are True Determining Executabiiity of: ResctScramSystem Not Executed Before Action is Available » Preconditions are True Determining Executabiiity o£ ResetRPS Not Executed Before Action is Available » Preconditions are True Determining Executabiiity of: ResetTripRPS Not Executed Before Action is Available Checking Preconditions Is ((TimeLapsed (Trip RPS)) > 10 sec) True? -> y >/ Preconditions are True > > ResetTripRPS is Executable > > ResetRPS a Executable > > ResetScramSystem a Executable Determining Executabiiity o6 ManualTripRPS Not Executed Before Action is Available 152 » Preconditions are True > > ManuaUripRPS s Executable > > (ManualScram ScramSystem) is Executable > > ManualScramScramSystem is Executable > > PE: Reset Action is Needed Prior to Executing ManualScramScramSystem > > PE: Searching for the Reset Action Checking the Enter Conditions » Enter Conditions are True Checking Goals » Goal is Not Specified Action not required because goals are already True » PE: Reset Action Not Needed = > NOTE: Prompting the user to execute selected action = = > Try ManualScram (ScramSystem) Done? —> n Response is NIL = > NOTE: Sofar, Procedure Synthesizer has selected and recommended several actions to insert control rods. However, due to some unknown reasons the operator was unable to execute the recommended actions. Now Procedure Synthesizer attempts another procedure which is based on the fact that if the reactor pressure is very high then the control rods cannot be inserted, requiring first that the pressure be reduced. Some experts do not agree with the advisability of this procedure. PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking the Enter Conditions Is ((RPV.Pressure > 1500 psig)) True?-> n » Enter Conditions are Not True Action not required because Enter conditions are not True > > PE: active action not required Checking Goals » Goal is Not Specified Is (ControlRods Position = 0) True? -> n Action Not Successful = > NOTE: PE will invoke failure recovery process to find an alternative to the failed procedure Insert ControlRods. FR will first try to recover from the most recently failed action. If it cannot find an alternative to the most recently failed action then it will try to recover the next most recently failed action, stepping backward all the way to the initial procedure. Invoking Failure Recovery Problem Solving Process (FR) 153 Finding a Procedure to Achieve the Goals of action :(Insert ControlRods) Goals Not Found Finding Procedure to Maintain the Goals for action (Insert ControlRods) Maintain Goals Not Found Finding Procedure to Maintain the Goals for action (Open PilotScramValves) Maintain Goals Not Found Finding Procedure to Maintain the Goals for action TripRPS Maintain Goals Not Found = > NOTE: FR has failed to find an achievable goal to recover from the alternatives to the procedure Trip RPS. Trip RPSis a subaction of the procedure Scram Reactor. Since Scram Reactor is a DoSequenceAU type of procedure and a subaction has failed, FR determines to attempt tfind an alternative to Scram reactor. Invoking Failure Recovery Problem Solving Process (FR) Finding a Procedure to Achieve the Goals of action :(Scram Reactor) Goals Not Found Finding Procedure to Maintain the Goals for action (Scram Reactor) Goal To Be maintained is :(Achieved ReactivityCntrl) = > NOTE: FR finds a procedure for ReactivityControl and returns it to PE for execution. CHAPTER 5 FEPS - A FRAMEWORK FOR THE SYNTHESIS OF EMERGENCY PROCEDURES IN A NUCLEAR POWER PLANT In Chapter 3, the problem of responding to a power plant emergency caused by a system malfunction was analyzed, it was shown to be a knowledge intensive reasoning task, which requires the capability to synthesize corrective procedures in runtime to control a dynamically evolving situation. Also, a knowledge-based problem solving approach was described for the task of dynamic procedure synthesisflDPS). In Chapter 4, various types of knowledge, and a knowledge organization and representation language (DPSRL) designed to express the knowledge for DPS was described. Also, an implementation of a high level programming language in InterLisp-D and LOOPS on a Xerox Lisp machine was described. In this chapter, we describe an application of DPS theory to dynamically synthesize emergency operating procedures for a Boiling Water Reactor. 154 As discussed in Chapter 2. in the nuclear industry systematic approaches to respond to an operational emergency have always been used. The knowledge intensive reasoning is often done by procedure designers (with the help of experienced operators) to produce a set of prescriptive procedures for well defined scenarios. However, there is still a need for a systematic framework to help in responding to unanticipated scenarios. In this chapter we describe: ® a new framework (FEPS), based on the DPS theory, to organize the exisiting knowledge about the procedin-es, and to utilize the knowledge to respond to an emergency in nmtime, • an experimental prototype using the language DPSRL as an illustration of FEPS, • an analysis of the performance of the prototype on a Loss of All Feed Water incident 5.1 AN APPROACH TO INTEGRATED SYMPTOMATIC/EVENTS/FUNCTIONS ORIENTED PROCEDURE SYNTHESIS As discussed in Chapter 2, to provide an effective emergency response, the proposed approach should provide guidance in responding to unanticipated incidents and multiple failures, handle procedure failures, and implement defense-in-depth philosophy. Furthermore, it was discussed in section 3.1.2 that to obtain an effective emergency response it is required to have the capability to synthesize 156 procedures dynamically. Specifically, the proposed approach should have following characteristics: L Capability to synthesize procedures in runtime, and 1 Failure Recd/ery in runtime. There should be a systematic approach to recover from the failure of a procedure in a manner which is optimal, and/or effective, and follows defense-in-depth. 3. Utilize existing event-oriented procedures. The event-oriented procedures are optimal for the specific scenario. The approach should effectively utilize the exisiting event-oriented procedures augmented by the capability to dynamically synthesize procedures. 4. Utilize existing function-oriented procedures. To enable the selection and synthesis of executable corrective actions for unanticipated situations and multiple failures the approach should utilize the well accepted notion of maintaining safety functions ai^ en ted by the capability to dynamically synthesize procedures. 5. Integration: The approach should provide an effective and runtime int^ration of the event-oriented and function oriented approaches. It is also desirable to have a smooth transition between the two approaches. 6. Unambiguous Interpretation: The framework should provide a systematic approach to generate unambiguous interpretation of a procedure during execution. The DPS theory described in Chapter 3 provides a framework to achieve the first two characteristics. The plan execution logic of DPS described in section 3.3.5 achieves the last requirement. A design for characteristics 3, 4, and 5 using DPS framework is described in this Chapter. Specifically, the following aspects of the proposed framework (FEPS) are described: • Various elements of the framework, their functionalities, and their interaction. 157 • Various types of procedures (goal and event oriented) and how to and organize them. • The approach for the integration and smooth transition between different procedure organizations, and • The approach for failure recovery and defense-in-depth. 5.1.1 Elements of FEPS In Chapter 3. section 3.2.2 . we identified the following tasks required for responding to an emergency situation; plant status monitoring and abnormality detection, sensor data validation, malfunction diagnosis, consequence prediction, and procedure synthesis. Figure 18 shows various elements of the FEPS approach. These elements correspond to various tasks performed by an operator. Routinely, these tasks are performed using prescriptive procedures. However, in non-trivial situations, performing these tasks becomes a knowledge intensive activity. We. therefore, believe that all of the elements in Figure 18 have a significant amount of knowledge based component. The Sensor Data Validation System (SDVS) is designed to isolate failed sensors and estimate correct values of measured sensor values. The problem of sensor data validation is also discussed in sections 3.2.2 and 3.3.5. SDVS normally employs operational heuristics, analytical models, and diagnostic knowledge to 158 Figure 18: Elements of FEPS VALIDATED SENSOR AND COMPONENT STATUS DATABASE Plant Status Signal Diagnosis ^ Monitoring Validation Goal Plans Procedure Selection and Consequence Events Prediction Synthesis Plans Procedure System Generation Plans Procedure Execution Legend Data Path Failure Control Path Recovery 159 isolate sensor failures and estimate correct values. Applications of the SDVS in the nuclear and aviation industry utilize sophisticated analytical techniques [Meijer 81]. The use of experience based knowledge and operational heuristics has been identified in chemical industry [Anyakora 74]. Some of the common heuristics used both in chemical and nuclear industry include redundant information (e.g., a priori expectations, past signal values, redundant sensors, and interrelated sensors), change in sensor values (e.g., noisy value, trend checks, limit checks, unusual variations etc.), and analytical redundancy (e.g. mass and heat balances, flow- pressure drop relationships, consistent states etc.) An AI approach for sensor data validation is being developed at the Ohio State University [Chandra 85a] [Hashemi 86]. The Diagnosis System (DS) is designed to determine component malfunctions based on sensor data. Often the DS is required to explain ^stem malfunctions or off-normal conditions in terms of component malfunctions. Depending upon the knowledge available, the DS may be based upon a simple rule-based classification approach [Buchanan 84], utilize powerful diagnostic architectures to classify by organizing knowledge as a hierarchy of diagnostic specialists [Gomez 79], or utilize "deeper” functional and structural understanding of how components function and interact [Sembugamoorthy 84] [Davis 83] [Genesereth 82]. 160 As discussed in section 5.L2, the existing procedures of a NPP (which includes procedures for normal operation, repair of plant systems, off-normal operating procedures, emergency procedures) are grouped into three categories: Events procedures. Goal procedures, and System procedures. The Plant M onitoring system checks the status of the entry conditions of each of the event and goal procedures to determine which procedures need to be executed. The Plant monitoring system essentially employs diagnostic reasoning to first determine which of the safety functions are lost, or events detected. The Procedure Selection then selects the appropriate corrective procedure. If more than one emergency procedure is selected then the Procedure Scheduler system defines a composite plan based on the knowledge of the significance of the various goals to be achieved to the overall plant safety. The purpose of Consequence Prediction system is to provide answers to questions like: What will happen if valve VI is opened? Answer to such questions requires reasoning about system function under the existing plant conditions. The purpose of Procedure Synthesizer is to generate an executable procedure to achieve the goals of an intial plan selected by the Procedure Selection and Scheduler systems. In order to synthesize executable plans the Procedure Synthesizer has to interact with DS to find out the status of critical components and systems and also with consequence prediction to eliminate potentially unsuccessful actions. If a procedure fails then the procedure synthesizer should also have the capability to recover from the failure. 161 The need for each of these elements is discussed in Chapter 3. section 3.2. The logic for accomplishing the tasks of each of the elements is discussed in section 3.3.5. 5.1.2 Organization of Procedures in NPP To apply the DPS approach three types of plans are needed: plans for changing the status of various plant systems in a desired manner, plans to achieve specified goals, and plans to control specified tystem malfunction or events. In the domain of NPP these three decompositions are: System Plans: In a NPP there are several plant systems and components whose operating states can be changed to exercise control over the response of the plant. Often controls for changing the state of such components is available to the operator in the control room. The collection of procedures to chan^ the state cf a system or component in a desired manner constitute the library of system pian s. System plans can be specified at various levels of detail The p rim itive system pians are the basic procedures that an operator is expected to know from his training, such as, verify that reactor power is less than 105%, and Press ARI initiation button. System plans are defined in terms of these primitive procedures. Goal Plans: The safety goal of a NPP is to prevent core meltdown and the release of radioactivity to the public. As discussed in section 5.2 this safety goal 162 can be decomposed in terms of critical plant safety functions, and safety functions defined at the level of control systems and components The goal plans are procedures defined for achieving or maintsining the safety goals Goal plans are specified in terms of the system plans Event Plans: In the NPP industry procedures are predefined for a selected set of events It is assumed that these procedures provide optimal recovery for the corresponding evens The event plans used here are the same as those defined in emergency procedures guideline and the abnormal operations guideline. In the work reported in this dissertation the event plans are organized as a simple list of procedures The possibility and the need for a systematic structuring of these procedures is recognized. A potential hierarchical structure for event plans is shown in Figure 5. System plans are organized around the specific system for which they are designed. The goal plans are organized as a hierarchy of goals The principles underlying the selection of safety goals and their organization are discussed in next section. All the procedures included in system plans, event plans, and goal plans are described using the representation language DPSRL described in Chapter 4. 163 5.1.3 Int^yation of Event-Oriented and Safety Goal Maintenance Approaches Using the event plans an optimal procedure can be selected for pre-defined diagnosable plant malfunctions. Using the goal plans it is possible to select procedures for unanticipated plant malfunctions which will ultimately challenge at least one of the pre-defined safety goals. There are two specific situations where it is required to change from one set of plans to other • While executing the event procedure a safety goal is challenged requiring immediate actions for maintaining the safety goals, and • While executing actions for achieving a safety goal an event is diagnosed requiring that the pre-defined optimal procedure for controlling the event should be executed. The integration is achieved by explicitly defining the safety goals for each procedure step in the event procedures, and by including diagnostic knowledge to identify specific events in the procedures to achieve safety goals. For example, consider the following simplified procedure for the event Pressure Regulator Failed Operr. [DoSequence ( (NotShutdown Reactor) —> (DoSequence (Start PressReliefSystem tomaintain SteamReliefControl) (Scram Reactor tomaintain InsertedReactivityControI))) (Start HiPressInjection tomaintain HiPressInventoryControl) (Isolate RPV tomaintain InventoryControl)] 164 The safety goals in this example are shown in Figure 19. The smoothness of the transition is achieved by defining a hierarchy of safety goals and specifying lowest level safety goals for each procedure step in the event procedures. For example, in the above procedure the failure to Scram Reactor requires achieving a lower level goal InsertedReactivityControI instead of trying to achieve the higher level goal ReactivityControl. 5.1.4 Discussion of FEPS In the begining of this section certain desired features for FEPS were discussed. In this section a comparison of FEPS with respect to those features is presented. Capability to synthesize procedures in runtime: The capability to dynamically synthesize procedures using a library of pre-defined actions is achieved by using the DPS approach described in Chapter 3. Essentially, the synthesis is achieved by performing the following tasks: procedure synthesis, execution, and failure recovery. The failure recovery logic is based on goal directed indexing for alternative actions as defined in the previous chapter. Failure Recovery in runtim e. Utilize the existing event-oriented procedures. Event-oriented procedures are utilized with some modifications. First, these procedures are written in a modular fashion (Le. by using the names of a sub-procedure or the goals to 165 be achieved instead of the detailed procedtire). This approach to specifying procedures not only provides a convenient and efficient way of encoding the knowledge about operating procedures, but is also consistent with how experienced operators think about the procedures. When an operator thinks about how to scram a reactor he immediately thinks about named procedures such as how to trip the RPS and follow on actions rather the details of the procedures. The second modification is to specify with each procedure step the goal it is supposed to achieve. Utilize existing function-oriented procedures. The maintenance of safety function is achieved by maintaining safety goals. By design, the safety functions are a proper subset of the safety goals. The procedures for maintaining safety goals are based on the existing procedures for maintaining safety function. integration: The integration is achieved by writing the procedures to conform with the DPS approach using the DPSRL language. The strat^y to achieve the integration is described in section 5.1.3. The smooth transition from an event plan to goal plans is facilitated by using a hierarchy of goals and writing the event plans as described in section 5.3. Unambiguous irrterprstation: An unambiguous interpretation of the procedures is achieved by using the procedure execution logic defined in Chapter 3. The execution logic utilizes the structure and the specified knowledge in the procedures to determine which actions should be executed. 166 Defense-in-depth approach to Operational Safety: The safety goals hierarchy not only provides a smooth transition from events plans to goal plans, but also provides an approach for def ense-in-depth philosophy by explicitly specifying higher level goals to be achieved in case the lower level goals cannot be achieved. 5.2 SAFETY GOAL PLANS - AN APPROACH FOR SAFETY FUNCTION MAINTENANCE In FEPS. the objective of safety function maintenance to provide operator an unambiguous guidance in maintaining critical safety functions without requiring detailed runtime diagnosis to identify the initiating event is achieved by maintaining the safety goals. The term safety goal is used to describe any svstem. subsystem, component or process state (not just functions), which if not achieved can potentially challenge the safety of the plant. In the NPP industry, the term safety function refers to the well known plant level functions (as many as 7). whereas, the term safety goal, as used here, refers to any safety challenging system state. Examples of safety goals are: Maintain Core Integrity. Reactivity Control. Inserted Reactivity Control. Boron Control, and Control Rods Control The safety goals approach is based on the observation that it is possible to define a hierarchy of system, sub-system, and component states or functions 167 critical to plant safety and to relate the status of safety goal at one level to the status of afety goal at another level Thus, the plant safety can be expressed in terms of the safety goals at the system level (which are essentially the critical safety ftmctions), the system safety goals are expressible in terms of the sub-system safety goals. An analysis of critical function monitoring logic and the success paths developed to maintain safety functions substantiates this observation [Meijer 84]. The possibility of decomposing plant functions in terms of system and sub-system functions is a well accepted fact [Rasmussen 84] [vonHerrmann 83a]. However, the problem of how such a decomposition can be used for improving plant operations has not been adequately addressed. The proposed FEPS approach is unique in the sense that it advances the concept of decomposing plant functions by. • specifying a safety oriented approach for performing such a decomposition. • demonstrating the usefulness of such a decomposition in providing guidance to operators for effective and optimal response, and e demonstrating the usefulness of such a decomposition for implementing the defense-in-depth philosophy to reactor operations. 168 5.2.1 Decomposition of Plant Safety Functions In principle, the number of all possible safety related operational goals can be very large, thus potentially defeating any attempt to automate the monitoring and maintenance of all the goals. From a practical viewpoint only those goals need to be monitored for which the procedures can be defined. Thus, the plant functions are decomposed in terms of safety goals which satisfy the following conditions: • it should be possible to check the status of the safety goal, • the procedures to maintain the safety goals exist, and • the selected safety goals should at least include goals to prevent or control the events leading to release of radioactivity and other critical safety functions. Safety Goals for a BWR The last criteria above needs some explanation. The following discussion is based on an analysis of BWR safety presented in WASH-1400 VoL 9 [WASH-1400 74]. The fundamental safety goal in a nuclear power plant is to prevent the release of radioactivity from the reactor to the surroundings. A typical 1000 MWe reactor core contains approximately l.OE+09 curies of long term radionuclides out of which 98% are in the uranium dioxide fuel pellets, and the remaining 2% in the gas plenum primarily in the form of krypton, xenon, and iodine etc. Significant amounts of radioactivity can be released if the fuel cladding is damaged and the fuel pellets melt due to overheating of the fuels. Fuel overheating can take place 169 if the heat generated exceeds the heat removed from the fuel For effective emergency response, the set of selected safety goals should at least address the safety questions related to the fuel overheating and the release of radioactivity. Thus, in Figure 19 the fundamental safety goal of Prer/ent Radioactivity Release is decomposed into two goals: Maintain Core Int^rity, ard Maintain Containment Integrity. The goal of Maintain Core integrity can be threatened if the heat generated in the fuel exceeds the heat removal capacity of the reactor coolant system. This can happen if any of the following occurs: heat generation increases, cooling capacity of the heat removal system decreases, and reactor coolant is lost. Heat generation can be controlled by achieving the goal of Reactivity Contrai. The goal of Core Cooling Control takes care of the incidents leading to loss of jling capacity and LOCA. The safety goal of Reactivity Control is intended to control and prevent unintended rise in generated power. Unintended rise of generated power can be caused by any phenomena leading to an increase in positive reactivity in the core. Some of the well known causes are: reduction in temperatures of the coolant in core, increase in the flow of coolant through the core, uncontrolled removal of control rods or inserted reactivity, and increase in pressure. Reduction in the temperature of reactor coolant can be caused by any one of the following: reduction in feed water temperature, increase of feed water flow rate to the core 170 possible due to the feed water controller malfunction, increase in moderator (i.e. coolant) density possibly due to a reduction in void fraction in core caused by a high pressure transient, and finally overcooling of coolant due to a malfunction in shutdown cooling. Figure 19 shows safety goals corresponding to the decomposition of Reactivity ControL Similarly, the safety goal of Core Cooling Control can be decomposed into goals for maintaining adequate core cooling capacity. This includes maintaining: adequate core heat removal, adequate coolant inventory in the core, and pressure control to assure that core heat is being removed by steam generation. Figure 19 also shows various safety goals relevant to the problem of core cooling. 5.2.2 Development of the Safety Goals Hierarchy Motivation Consider ± e scenario where a low level goal, for example ControlRodsControl, is challenged and the pre-defined corrective actions to control it are unsuccessful Assuming that we have an unstructured list of safety goals, the only solution is to wait until some other safety goal, such as InsertedReactivityControI or the ReactivityControl, is threatened and then execute the corrective actions of the most recently threatened safety goal This simplistic approach may cause unnecessary propagation of the malfunction through the plant thus challenging several low level safety goals, and finally challenge the higher level safety goals thereby increasing the overall risk. The need for a better solution is apparent 171 The Solution Approach It is proposed that an adequate solution is to define the knowledge on the inter relationship of the safety goals in the following form; IF < safety goal g cannot be maintained> — > THEN An analysis of the safety goals acu the process cf decomposition of plant functions reveals that it is possible to define a hierarchy of safety goafs where the failure to a maintain low level goal p red ic ts that the next higher level goal in the hierarchy will be ultimately challenged. The potential risk is thus controlled by executing the corrective actions for the higher level goals before they are really challenged. The Solution Safety goals are defined at all levels of plant description. Le., plant level, system leveL subsystem and control systems leveL and component level The purpose of defining a safety goals hierarchy is to provide explicit guidance to help decide which safety goal to pursue if the active safety goal cannot be mainTainpd. The bottom-up hierarchical approach is, in effect, an implementation of the defense- in-depth philosophy where failure to achieve a restricted goal requires achieving a more general goal Figure 19 shows an hierarchical structure of safety goals where 172 the goals to the right are decompositions of the goals to the left. The safety goal hierarchy has the following interpretation: • The higher level goal provides coverage for a specific safety related problem. • The lower level goals (to the right in the hierarchy) can be simply a partial decomposition of the h i^er level goals (to the left in the hierarchy). The implications are: L the approach does not require that the lower level goals be a perfect and complete decomposition, and 2. if the decomposition is partial, then if an abnormal incident not covered by the lower level goals occurs, then it will be detected at the higher level This will lead to a less optimal recovery path. • Safety goals that are sub-goals of the same higher level goal are independent in the sense that the detection of a threat and selection of a procedure for a safety goal does not depend on the other goal Any interaction is resolved by the knowledge contained in the higher level goal • If a lower level goal cannot be maintained then the higher level goal has to be maintained. 5.3 PLAN LIBRARIES FOR FEPS In this section we discuss the specific design of plan libraries for a NPP. The need for plan libraries was discussed in section 3.3.4, a basic organization was described in section 4.2. and an application of the organization of plan libraries to the NPP was discussed in section 5.1.2. / M4intCont«(nmentlntegrity -T Cîoatâlnmentlemplîontrol Ste«rnneliefConirol 0(H\densorlltfAtnernovil RPVPrnssureConuoI C S The motivation for using event-oriented procedures is to enable optimal recovery from diagnosable plant malfunctions. The event procedures used in the FEPS approach explicitly specify the sequence of safety goals to be achieved and an optimal action to achieve the safety goaL The specified action is designed to be optimal for achieveing the safety goal given by assuming the plant malfunction, the expected evolution of the transient, and the expected response of the plant to various control actions. Appendix A.1 contains several examples of event procedures used in FEPS approach. The event procedure consists of three items: • Entry Conditions: The purpose of entry conditions is to identify the abnormal incident Entry conditions consist of a set of process states and the status of various plant systems which if true indicate that a certain malfunction has occured and that a control action is required. • immediate Actions: The purpose of immediate actions is to quickly control the transient to limit the consequence of the abnormal event and assure that various safety goals will be maintained. Immediate actions are executed soon after the event is identified. Immediate actions often require verifying the status of automatic control systems, and the expected effects of their action. The operator is expected to intervene if the automatic systems fail to respond in the desired manner. • Follow-up Actions: The purpose of follow-up actions is to assure that the various safety goals are maintained and that the plant is returned to a safe state. • Limit Actions: The purpose of limit cations is to specify the control over the immediate and follow-up actions. 175 5.3.2 System Plans System plans are intended to change the status of plant qrstems. To enable efficient retrieval, the system plans they are declared in a frame for various systems. Appendix A.2 contains several examples of plans for various systems. The systems plan frame essentially consists of the following slots: • Subsystems: contains a list of susb^stems of RPS. • PlanLibrary: contains a list of the name declared plans, and the plans themselves. • inferedStates: contains a list of high level interpretations for RPS, and conditions to evaluate them. For example, in the RPS plan frame, declared infered states are InResetMode and Tripped. The slot for infered state Tripped also contains knowledge on how to achieve the tripped RPS state. 5.3.3 Goal Plans Goal plans are intended to provide procedures to achieve and TnaintaiTi safety goals. Appendix A.3 contains several examples of goal plans. The goal plans frame consists of the following slots: • SubFunctions: contains a list of sub-goals. • PlanLibrary: contains plans to achieve the safety goaL The basic plan is called Achieve. • infered States: contains knowledge on determining if the safety goal is being maintained and enter conditions to enable selection of the A chieve plan. 176 5.4 DEMONSTRATION OF FEPS AND PERFORMANCE ATiALYSIS The application of FEPS described here is based on the following four major components: e a computational theory for dynamic procedure synthesis discussed in section 3.3. • the representation language DPSRL described in Chapter 4, • the FEPS framework for an integrated approach for responding to operational emergency in a NPP . and • the domain specific knowledge about plans and procedures used to develop the application for a BWR. The first three items are specific contributions developed in this dissertation, and together constitute a systematic framework to enhance the existing approaches for emergency response used in NPPs. The last item is required for demonstrating the DPS and FEPS framework. The procedures used are representative of procedures used in a typical BWR and are based on operating procedures used in variotis BWR plants. The objective of the evaluation is to demonstrate that the framework is feasible using predefined procedures. No attempt is made to validate the knowledge contained in the predefined procedures. Various features to be demonstrated for DPS and FEPS are: 177 L DPS can synthesize procedures in runtime using prespecified procedures. This involves various features such as procedure generation, execution, and failure recovery as discussed in section 3.3.5. 2. DPS provides correct and unambiguous interpretation of procedures during execution. 3. The FEPS approach provides a way for efficient and effective integration of function based and event oriented procedure selection. 4. The FEPS provides an effective approach for realizing defense-in-depth philosophy. Items 1 and 2 were demonstrated in the example of a Reactor Scram scenario in section 4.5. The examples described here will demonstrate items 3 and 4 along with items 1 and 2. 5.4.1 Performance Analysis For specificity, we will consider the scenario of a loss of feed water. The loss of all FW transient is considered to be of moderate frequency [FSAR 85]. To demonstrate the various aspects of FEPS we will consider several variations of this scenario to encompass various unanticipated failures. The performance of the FEPS based system will be analysed to demonstrate the various features of DPS and FEPS mentioned on page 176. Scenario Description 178 Figure 20; The Loss cf FW Scenario for the Demonstration of FEPS C asel FW Pump Trip Case 2 Loss of AllFW Case 2.1 Case 2.2 Control of Control of Loss of AllFW Loss of All FW without using using FEPS/DPS FEPS/DPS Case 2.2 Method 1 Case 2.2 Method 2 Without using the Using the Safety Goals Safety Goals Hierarchy Hierarchy Case 5 Case 3 Case 4 Failure to Failure Failure to Start to Scram Trip Recirc HPCS Pumps 179 Table 1: Sequence of Events for the Loss of FW Event Time-Sec Event 0 Trip of all feedwater pumps initiated. 3.5 Vessel water level reaches level 4 and initiates recirculation flow runback. 5 Feedwater flow decays to zero. 7.0 Vessel water level trip initiates scram trip. 14.9 Vessel water level reaches Level 2. 15.1 Recirculation pumps trip due to Level 2 trip. 45 HPCS and RCIC flow enters vessel Source: [FSAR 85] 180 The scenario used for demonstrating the performance of FEPS b^ins with a trip of both the FW Pumps as shown in Figure 20. To demonstrate the FEPS/DPS approach we have assumed that the operator fails to start the MFW Pump which is required to control the FW Pump trip transient The loss of both the FW Pumps and the failure to start the MFW Pump causes a loss of all FW to the reactor. The incident of loss of all FW to the reactor was discussed in section 3.1.2. The sequence of events for a typical loss of feed water transient is shown in Table 1 which is obtained from a final safety analysis report [FSAR 85]. In section 3.L2 (see also Figure 2) we discussed a case of the failure of the loss of all feed water scenario with the failure to start high pressure injection. This event has been analyzed in WASH 1400 and designated in Figure 21 as the transient TQU. The sequence of events for this transient is shown in Table 2 and IS based on several sources [FSAR 85] [vonHemnann 83b]. For demonstration purpose we have also considered two additional malfunctions: - failure to trip reactor causing an ATWS situation, ® failure to trip recirculation pumps causing reactivity abnormalities, and It is possible that while responding to the various cases described below, the entry conditions to the emergency procedures (modeled as safety goal Maintain Core Integrity in the safety goal hierarchy in shown in Figure 19 are satisfied. The desired response in such a situation would be to exit the current procedure and start executing reactivity, level, and pressure control emergency procedures. In 181 Figure 21: Event Tree for BWR Transient Events from WASH 1400 nmrsj HPCI LP HPSW AT RS S/R S/R FW or VO VR ECCS or SEQUENCE RCIC PCS - M U W 1. T 2. TW 3. TQ 4. TQW 5. TQU 6. TQUW 7. TQUV 8. TP 9. TPW 10. TPQ 11. TPQW 12. TPQU 13. TPQUW 14. TPQUV 15. TM 16. TC Source: WASH 1400, Appendix 1. 182 Table 2: Sequence of Events for the Loss of FW with the failure to Start H i^ Pressure Injection Time-sec Event 0 Trip of all feedwater pumps initiated. Vessel water level reaches level 4 and initiates recirculation flow runback. 5 Feedwater flow decays to zero. 7.0 Vessel water level trip initiates scram trip. 14.9 Vessel water level reaches Level 2. 15.1 Recirculation pumps trip due to Level 2 trip. 44.9 HPCS and RCIC fail to start 1-15 min Operator attempts to restore high pressure systems. 5-15 min Operator initiates depressurization. Source [FSAR 85] [vonHemnaim 83b] 183 section 4.3.5 we have described an approach to accomplish this process, however, this feature has not been implemented in the current version of FEPS. In the following discussion we have assumed that this feature will be available. Moreover, in synthesizing the procedures described below we have assumed that the entry conditions for the emergency procedures does not occur. This assumption is being made to demonstrate the dynamic synthesis capabilities of the proposed FEPS/DPS approach. The traces of the FEPS program in response to these events are included in Appendix B, The procedures qmthesized and some aspects of the reasoning performed by FEPS are summarized in Figures 23, 24, 27, 29, 31, and 32. Case 1; FW Pump Trip In a FW pump trip scenario both the feedwater pumps are assumed to have tripped. The FEPS program first detects that an abnormal incident has taken place and then diagnoses the cause to be a FW pump trip. After identifying the cause, the FEPS program generates a procedure shown in Figure 22. In this case it is assumed that the procedure to respond to a FW pump trip event is successfuL As shown in Figure 23, the procedure execution problem solver (PE) interprets the procedure shown in Figure 22 and selects actions to be executed. As shown in the trace in Appendix B.1, in selecting the procedure FEPS performs various problem solving tasks described in section 3.3.5. HuhnnsN Shutdown(FWPurnps) / ^Bro»kV*cuu»n(AuxGondens«r)/ -IsolateSoilSteamToCFV/PUfnps) As ^^T^^CIoseSuctV«lvo(FWPufnps) ' CloseReclrcControlV4lva(FWPurnps) DoAsM«ny ClaseDlschValvii(FWPufnps) DoMonitor- EMltTo(Achtava MalntCnrelntegrUy) St*ri(FWPufnps) OoSequenceAH DoSequonceAH ^^Beduco(B«clrcFlow to ~ 70 percent) '^DoAnyOno-*^ Reduce(RacircFlow to ~ 46 percent) ^'fleduca(BeclrcFlow to ~ 30 percent) lsol«te(ShutdowitC Doling) DoSequence LowSpeedMode (RecircPurnps) Scratn(Reactor) ■ OoMonitor • < ■ Close(ReclrcFlowControlValvos to 48 percent Loop Flow) DoSequence ' lowSpaedModa(BeclfcPuinps) 'Start(MFP) Figure 22: Procedure for a FW Pump Trip % 185 Figure 23: Procedure Generated by FEPS for the FW Pump Trip Scenario PE Selects PE Selects PE Selects DoMonitor Do Monitor Start MFP Slow Speed Mode Close Recirc Flo-w OK Recirc Pumps Valves OK OK PE Selects PE Selects DoMonitor Sequence of Actions Start Reactor Feed PE Selects < - Shutdown Reactor Pump Turbine Reduce Recirc Flow Low Speed Mode Recirc Pumps OK OK Isolate RHRS System OK PE Selects PE Selects PE Selects Start Reactor Feed Start MFP to Start MFP to ■> do something special Pump Turbine do something special OK OK OK PE Selects PE Selects PE Selects Close Discharge DoMonitor Close Recirc Control Exit To RPV Control Valves of FW Pumps e - Valves of FW Pumps K- OK (Maintain Core Integrity) OK Procedures \/ PE Selects PE Selects PE Selects Isolate Seal Steam to Break Vacuum of Close Suction Valves ■> FW Pumps Aux Condenser of FW Pumps OK OK OK PE Selects FW Pump Shutdown Trip FW Pumps OK OK 186 Afxer successfully starting the MFW Pump, PE generates several m onitor condition and then execute type procedures. Specifically, it sets up the following monitoring procedures: IF (FW Flow is less than 22 % for more than 15 secs) — > THEN (Switch RecircPurnps to Low Speed Mode) IF (RPV Water Level is less than 198 in AND Atleast one FWPump is tripped) — > THEN (Close RecircFlow Control Valves to 48 % Loop Flow position) IF (RPV Water Level is less than 179 in) — > THEN (DoSequence (Scram Reactor) (Switch RecircPurnps to Low Speed Mode) (Isolate Shutdown Cooling System)) As shown in Figure 23 we have assumed that none of these monitoring procedures are immediately required. Thus PE proceeds to execute the predefined immediate actions for this event (see Appendix A.1) and selects the action Reduce R&drcFlaw to 30 % so as to reduce reactor power to 20 % value. Following which PE recommends To the operator to start tripped FW Pumps which is assumed to be successfuL Finally, PE helps operator in executing the follow on actions. Case 2; Loss of Ail FW Let us assume that in the procedure for FW Pump Trip the action to S ta rt 187 Motor Driven FW Pump failed causing a total loss of FW supply to the reactor. This failure requiresselection or generation of an alternative procedure. The PEPS generates an alternative procedure by using the failure recovery problem solving process described in section 3.3.5. Here we describe four different approaches. Case 2.1: Without Using FEPS: If the FEPS approach is not used then the failure to start the MFW Pump will cause the failure of the predefined procedure for FW Pump Trip. However, the written procedure currently in use specifies the following rule: IF(RPV Water Level < 179 in) -> THEN (ExitTo RPV Control Emergency Procedure) Using typical data from various sources it will be about 30 seconds before the reactor water level falls to the 179 in level [vonHemnann 83b] [FSAR 85]. Thus the reactor will be in a high consequence state (called sequence TC in Figure 21) for about 30 seconds before an appropriate corrective action is initiated. The trace of FEPS program for this scenario is shown in Appendix B.2 Case 2.2: Using FEP& Within the FEPS approach the necessary failure recovery action can be modeled in two distinct ways. Method 1. Without Using the Safety Goa! Hierarchy: A simple extension of the written procedure can be accomplished by rewriting the S ta rt M FW Pum p action as: ibo (Start MFWPump tomaintain (Achieved MaintCorelntegrity)) , which specifies that if there is a failure to start the MFWPump then the procedure to Maintain Core Integrity (which is similar to the RPV Control Procedure) should be selected. Here we are simply using the existing approach of function oriented procedures without using the the safety goals hierarchy shown in Figure 19. The idea of specifying the safety function as a goal of action S ta rt M FW Pum p is due to the DPS approach developed in this work. The trace of the FEPS program is shown in Appendix B.3. This modification enables selection of the desired procedure for maintaining core int^rity as soon as the failure of Start MFWPump action is determined. The FEPS program took about 15 seconds to select the required procedure and another 6 seconds to initiate the procedure for maintaining core integrity, thus reducing the time spent in the high consequence state TC by approximately 9 seconds. We believe it is possible to significantly improve the execution speed of the FEPS program . The procedure for TnainTain core integrity specifies concurrent execution of procedures for Reactivity Control, Inventor}' Control, and Pressure Control as shown in Figure 24. Method 2. Using the Safety Goal Hierarch/: Using the the safety goal hierarchy of the FEPS approach shown in Figure 5.2 the procedure can be modified as follows: 189 Figure 24: Procedure Generated by FEPS for event Tripped FW Pumps with Failure to Start MFWPump using simple Function Oriented Approach PE Selects Start PE Selects Setting up various ■ PE FWPump Start MFW Pump monitoring procedure — >: Invokes Trip failed processes ! FR FR : goal of Start MFW Pump is Maintain Core Integrity Start FR finds a plan Maintain for the goal and returns Core Integrity it to PE / Start Start Start '' Maintain Maintain Maintain Reactivity RPV Water Level RPV Pressure V Control Control Control 191 Success Paths For Abnormal Event LossOfAIIFW Start(Shutdownj%HR) DoSequenceAB lniti*te(HighPressurelnjection^CCS) DoTr*cking < Trip(ItecircPumps) - Limit (ReactorScr am ) Runb«cfc(RecircPumps) Figure 25: Procedure for the Event Loss of All FW Success Paths For Achieve RPVWaterLevelControl - E»tTo((Lifnit ReactorScram)) | DoSequence ManuaKontrol(FWPun*) | DoSequence- ■DoAnyOne ■ Run8ack(RecircPumps) I Umit(LossOfAVW) Figure 26: Procedure to Maintain RPV Water Level Control 192 Figure 27: Procedure Generated by FEPS for event Tripped FW Pumps with the Failure to Start MFWPump using Safety Goals Hierarchy Approach PE Selects Start PE Selects Setting up various ■ ‘"PE FWPump Start MFW Pump monitoring procedure — >! Invokes Trip failed processes (see Fig 5.x) ! FR FR : goal of Start MFW Pump is Maintain RPV Water Level Control "f ■ .)lL Start ; FR finds a plan PE Selects Maintain RPV Water . for the goal and returns Limit Loss ! it to PE of All FW Leve Î Control Start PE Selects PE Selects Limit Runback Limit Reactor Loss of 1 ^ Recirc Pumps Scram All FW OK OK PE Selects Trip Recirc Pumps OK PE Selects PE Selects Limit Start Residual Initiate High Loss of All Heat Removal Presseure Injection FW Systems OK OK OK 193 Case 3: Loss of all FW with Failure to Scram Let us assume that during the execution of the procedure for Loss of All FW shown in Figure 25 the operator fails to execute the reactor scram procedure successfully.  simple situation of reactor scram was discussed in section 4.5. Here we consider a more realistic procedure for reactor scram. Failure to scram causes a complex situation of multiple failure along with the loss of FW. For specificity, let us assume that while executing the procedure for reactor scram shown in Figure 28 the operator fails to insert the control rods. PE invokes the failure recovery process to find an alternative to the action insert control rods. As shown in the Figure 29, FR selects the procedure for maintaining safety goal In serted Reactivity Control shown in Figure 30. PE executes the procedure for the safety goal and successfully completes the execution of the loss of all FW procedure. Case 4; Loss of All FW with Failure to Trip Recirc Ptunps Let us consider that in the loss of all FW scenario the operator was successful in executing reactor scram procedure but failed to execute Trip Recirc Pumps (see Figure 25). As shown in Figure 31, to find alternative actions PE invokes FR. FR Siir;nn|ss';Pa'tl s f(ïr;ljijnit l3paclbrSnriun FoUow(Ptant CooMown Procedure) Operato(nWCU) Align (Rec ircPum ps ) Boset(Ani) D oAsM tny neset(RPâ) WaUFor(Cleared Scram Conditions) MaIntain(nPV.Water).evel) Allgn(FWSystem) OoSequenceAH l«laintaln(flPVWaterLevel) Verify(AchIeved RPVPressureControl) Verify(ManualMode RecircFlowControl) OoMonitor - - DoSequence Verify(LowSpeedModo RecircPurnps) OoMonitor - -OoSequenco- Trlp(MabiTurb) OoSequenceAH Verify(Oecreasing Reactor Pow er) —- Verify (Closed SOV.OrainValves) D oS equence Verify(Closed SOV.VentValves) Insera(ContrrHRods) Put(the Reactor Mode Switch in SHUTDOWN) Figure 28: Procedure for Reactor Scram 195 Figure 29: Procedure Generated by FEPS for the scenario of Loss of All FW with Failure to Scram Reactor PE Selects Start PE Selects Setting up various - -pg"- FWPump Start MFW Pump monitoring procedure Invokes Trip failed processes FR }L ------, FR : goal of ; / Start \ Start MFW Pump Start PE Selects I Maintain \<— : is Maintain RPV ! Limit Limit Loss ^ 1 RPV Water j ; Water Level Control > Loss of of Allrw \ Leve 1 Control / '■ All FW \ J 1 L r- .i.. I • I FR finds a plan • >—: for the goal and returns - PE Selects PE Selects I it to PE ! Runback Limit Reactor Recirc Pumps Scram I______J OK failed PE Selects PE Selects Put Reactor Mode Insert Contro PE Switch in SHUTDOWN Rods Invokes OK failed FR tart I PE Selects PE Selects Decrase Maintain i .... 1 Initiate RRCS <■ Reactor Power Inserted FR : goal of i OK failed Reactivity Insert Control Rods j Control is Maintain Inserted: Reactivity Control I------r ------' aintain Inserted Trip Recirc r ------i'— Reactivity i FR finds a plan i Contorl —j for Inserted Reactivity j OK ; Control and returns it to; ! PE ! I______J PE Selects PE Selects Limit Start Residual Initiate High Loss of All Heat Removal t - Presseure Injectior FW Systems OK OK OK 196 Success Paths For the. Goal (Achieved InsertedReactivityCntrl) ■lnftiate(RRCS} DoS«pience OoAsMany ■ Decrease (Reactor fow er) Success Paths For (Reset .BRCS) ResetisoiationLogic(RWCU } -DoAsMany ResetTrrpLogic(RecsrcPumps) - DoSe%p*éoceAa ResetRunbackLogic (FWSystem ) ‘ ResetTripLogic(ARi} Figure 30: Procedure for Maintaming Inserted Reactivity Control finds that the action Trip Recirc Pumps is required to maintain safety goal Core Flow Control, however, there is no procedure defined for maintaining Core Flow Control TnsTÆad of reporting a failure to recover, FR attempts to find a procedure for the goal of maintain Core Flow Control (If a procedure were defined for Core Flow Control FR would have selected it) FR finds that the goal of Core Flow Control is to maintain Reactivity Control and selects the appropriate procedure and returns it for execution. Case 5; Loss of all FW with Failure of HPCS/RCIC 197 Figure 31: Procedure Generated by FEPS for the Loss of All FW with Failure to Trip Recirc Pumps PE Selects Start PE Selects Setting up various FWPump Start MFW Pump monitoring procedure >; Invokes : Trip failed processes! ______Y______j FR : goal of Start \ ■ Start MFW Pump Start PE Selects Maintain \<— : Limit Limit Loss ! is Maintain RPV RPV Water I Water Level Control Loss of of AllFW Leve 1 Control / ! All FW FR finds a plan PE Selects PE Selects for the goal and returns Runback Limit Reactor it to PE RecircPurnps Scram OK OK PE Selects r-p g--: FR : goal of Trip Recirc Invokes • 5» Trip Recirc Pumps Pumps ! FR ! . is Maintain Core failed I ■ Flow Control I FR does not find j a plan defined for : Maintain Core Flow Control Start I FR finds a plam ij I FR: goal of Maintain Maintain <• -j for Maintain Reactivity j, j Core Flow Control is Reactivity ; Control and returns it to: “ "j Maintain Reactivity Control ! PE !I Control 198 Let us assume that in executing the procedure for the loss of all FW (shown in Figure 25 the operator failed to execute the actions to start high pressure injection. As shown in Figure 32, PE invokes FR to find au alternative action. By examining the goals of the failed procedure FR finds that h i^ pressure injection is required to maintain the safety goal to maintain h i^ pressure inventory control FR fails to find a procedure for high pressure inventory goal because none is defined. FR then finds the goal of high pressure inventory control and find a procedure to maintain inventory control shown in Figure 33 and starts its execution. As shown in Figure 32. PE achieves the goal of inventory control by first reducing the reactor pressure and then initiating low pressure injection procedure shown in Figure 34. 5.4,2 Analysis In this section we have presented the results obtained from the FEPS program for seven cases. Most of the cases modeled multiple failures and threat to plant safety functions. The examples demonstrate the capability of FEPS framework to control such situations. These examples demonstrate the characteristics of the DPS based FEPS described below. 199 Figure 32: Procedure Generated by FEPS for Loss of All FW with Failure to Start Hig^i Pressure Injection ------■ PSSelecS------pg— PE Selects Setting up various Start MFW Pump monitoring procedure Invokes failed processes' FR ctt: goalof Start Start MFW Pump PE Selects Maintain Limit Loss is Maintain RPV RPV Water Water Level Control of AIIFW Leve I Control FRGndsaplan PE Selects PE Selects for the goal and returns Runback Trip Recirc ! it to PE Limit Reactor I______Recirc Pumps Scram Pumps OK OK OK PE rejects PE Selects PE Selects ■■ Pg“ Start High Pressure Isolate MSIV ' Invokestvokc ! Injection OK Initiate High Presseure Iiyectior ^ FR ! failed PE Selects Start Low ______y _____ Pressure Injection / FR ; goal of Initiate H i^ Pressure Start Injection is Maintain Maintain High Pressure Inventory Inventory Control Control ------y ------Start ______V______Low Pressure Injection FR did not find a plan defined for Fr finds a plan for Maintain High Maintain Inventory Pressure Inventory Control Control PE Selects “f Open SRVs 'I' OK FH; goal oT Maintain PE Selects High Pressure Control is Start LPCI Maintain Inventory Control andLPCS Low Pressure OK Injection OK PE Selects Maintain Limit Start Residual Inventory Loss of All Heat Removal <------;------( Control FW Systems OK OK OK SucçessI Path^ f|,arf AcHieyé jriyentûryCdntrûl ’ Restore(nPV.WaterLevel) Operate(LPCS) 'DoBackUp Operate(LPCI) Operate(RGiC) DoAsMany Operate(HPCS) Operate (CRD WaterSuppty ) Operate(FWSystem) DoSequence □oAsMany i Opera te(CondensateSystern) PowerControl(RPVWaterLevel) Flood(RPV) (nltiate(DleselOenerators) StartLoPresslnj(ECCS) ‘D o A « M « n y ^ ------^^StartHlPresslni(ECCS) Isolate (OOP) -lsolate(MSiV) Figure 33: Procedure for Inventory Control K) 201 Paths For StàrtLoPîFessIhj ECÇS Start(LPCS) DoAsMany Start(HPCS) Start(l_PCI) D oSecuence Operate (ADS) DoBackUp Operate (SRV) Figure 34: Procedure for the Low Pressure Injection Procedure SelectionlGerieratior}: A basic operation of DPS/PEPS is to select a procedure from a library of predefined procedures. In Case 1 the procedure for FWPump Trip was selected from the events plan library. The details of this procedure were generated by selecting plans from .yystems plan library and were used to determine executability of various action. Several examples of this process are shown in Appendix B. Similarly, all the examples described above involve selection and generation of various procedures. 202 Procedure Execution (PE:) A major feature of DPS/FEPS is the procedure execution logic. PE logic determines if an action should be executed, if executed it determines if the action was successful, and if not successful it determines what to do next. In the figures summarizing the results for various examples the actions to be executed are selected usmg PE logic. In cases 2.2, 3, 4, and 5 PE invokes the failure recovery process and continues with execution of the alternative action. Failure Recovery (PRO Failure recovery logic is another major feature of DPS/FEPS. FR finds an alternative action by trying to achieve the goals of the failed action. Cases 2.2, 3, 4, and 5 are specific examples of the fimction of FR. Cases 4 and 5 also demonstrate the robustness of the failure recovery process. In these cases FR does not abruptly fail despite the lack of knowledge of a certain procedure. Having failed to find an optimal recovery success path, the failure recovery process found an adequate but less optimal success path. This also demonstrates the graceful degradation feature of the FR process. Procedure Interpretation: Given a procedure modeled using DPSRL, procedure interpretation involves unambiguously assigning domain specific meaning to the procedure. The DPSRL language provides a large set of procedure primitives to capture various aspects of a procedure The problem solving processes are designed to use these features to make decisions. In the examples shown above, several procedures were successfully interpreted by various problem solvers. The feature of unambiguous interpretation is essentially realized by using a rich vocabulary to describe procedure features. 203 Procedure Synthesis: The procedures shown in Figures 27, 29. 31 and 32 are examples of the procedure synthesis capabilitj'. None of these procedures is declared in the knowledge base of the FEPS program. These procedures have been dynamically constructed in response to the various failures during the execution of the recommended procedures. Multiple Failures: Cases 2 throu^ 5 are all examples of multiple failures and procedures generated are demonstration of the capability of the approach to synthesize procedures for multiple failures. Defense—in—Depth: The FR in Cases 4 and 5 demonstrates the defense-in- depth feature. In Case 4 when FR failed to achieve safety goal maintain Core Flow Control it decided to achieve the next higher level safety goal maintain reactivity control Thus a failure at low level was controlled by achieving a more general goal Similarly, in Case 5 the failure to achieve safety goal maintain high pressure inventory control was controlled by achieving higher level safety goal maintain inventory control In both the cases a less optimal but safer procedure is selected to compensate for the failure of an optimal procedure. These examples also demonstrate the robustness of the approach for certain types of knowledge deficiencies. In Case 4 the failure to maintian safety goal Core Flow Control was due to a lack of predefined knowledge. Thus, in finding an alternative action the DPS/FEPS approach treats the lack of a procedure and the failure of a procedure in a similar manner. This feature is true for safety goals only. 204 Integration: The integration issue discussed in sections 4.2 and 5.1.3 is demonstrated by Cases 2.2 throng 5. The Event -> Goal int^ration is observed in all these cases where to recover from the failure of various steps the FR process finds a procedure to maintain a safety goaL The Event->Goal->Event integration shown in Figure 35 is observed across all these cases. Execution Time: We lealize that we have not produced systematic data of the execution time for realistic situaüons to judge the performance of the FEPS program. The purpose of this dissertation was to describe and demonstrate an approach for procedure synthesis rather than produce a high performance software system. Table 3 summarizes execution time required by the FEPS program to select/construct an executable procedure, present to the operator in a graphic format, and prompt the operator to execute the action. However, based on the performance of our the experimental software we are convinced that using advanced hardware and software technologies it is possible to produce systems which can operate at with a much higher execution speeds for a NPP and other similar applications. In the sample cases discusses in the previous section we found that more than 64 percent of the procedures were synthesized and presented to the operator in 0 - 10 secs, about 22 percent of the procedures in 10 - 20 secs, about 13 percent procedures in 20 - 30 secs, and the reamining 1 percent of the procedures took mote than 30 secs. 205 Figure 35; Integration between Safety Goals and Events Procedure C a s e 2,2 Method 1: Events >Goal Start Executing Execute Procedure Procedure for Event for Safety Goal Tripped FW Pumps Maintain Core Integrity C a s e 2,2 Method 2: Event. Goal E v e n t Execute Procedure Return to Start Executing ^ for Safety Goal Procedure for Procedure for Event' RPV WaterLevel Tripped FW Tripped FW Pumps Control Pumps Case 3: Events—> Goal Event. Goal Event Execute Procedure Execute Start Executing ^ for Safety Goal Procedure for Procedure for Event" RPV WaterLevel Limit Reactor Tripped FW Pumps Control Scram Execute Return to Return to Procedure for the Triiped the Limit Reactor Safety Goal FW Pump Scram Procedure Inserted Reactivity Procedure Control 206 Table 3: Typical Execution Time of FEPS Program Execution Time FEPS Process of FEPS in secs 0 - 5 FEPS determines operator executable actions. 6-10 FEPS determines operator executable actions from complex procedures. Failure recovery process (transition from event procedure to safety goal procedures). 11-15 DoSequenceAU procedures of more than 4 subactions. 16 - 20 Long DoSequenceAH’s, double failure recovery. 21-25 Complex DoTrackiag procedures, operator requests help for a complex procedure. 26 - 30 Transition from a safety goal procedure to an event procedure. 31 - 35 Transition from one long sequence of actions to another long sequence of action. 35 - 55 Long procedures requiring complex reasoning 207 5.5 SUMMARY In this Chapter we have described an application of the DPS approach to synthesize procedures to respond to operational emergency in a nuclear power plant. We described how the operating and emergency procedures of a NPP can be organized in various plan libraries according to the DPS method. In Chapter 2 we specifically addressed the need for an efficient integration between the events and function oriented procedures. In this Chapter we developed a DPS theory based approach (FEPS) to int^rate the three plan libraries and use the integration effectively to synthesize emergency procedures. To implement the safety functions philosophy along with the defense-in-depth philosophy and to provide an efficient int^ration between various procedure selection approaches, we have introduced the idea of a safety goals hierarchy. The development of a safety goals hierarchy for a typical BWR is discussed. Finally, we have described several examples of the performance of a DPS/FEPS based program for various transient and multiple failure scenarios and have shown that the DPS/FEPS framework has the capability to significantly improve upon the existing approaches to select emergency procedures. CHAPTER 6 SUMMARY, CONCLUSIONS, AND RECOMMENDATIONS The objective of this dissertation was to study the task of selecting and sjrnthesizing control procedures as a knowledge based problem solving process and develop a systematic approach for automatic and runtime synthesis of control actions for complex real system such as a nuclear power plant. 6.1 SUMMARY The Problem In recent years several accidents in complex man-made systems have been attributed to human error at various stages of the process. Operator errors (human errors in operating systems) are currently a significant topic of active research, and it is generally believed that some of the serious errors are due to factors that 208 209 adversely affect the decision making ability of an operator. In this dissertation we have adopted the information processing viewpoint of human decision making. According to this view human decision making can be modeled as a knowledge based problem solving process. It is our interprétation that a power plant operator can be viewed as an experienced problem solver who applies task specific knowledge to plan and execute control actions: and an operator error can be explained as a situation where the computational resources required to solve a problem exceed the human capabilities. Thus our basic approach is to model an operators task as a knowledge based planning problem. The Methodology The methodology used in this dissertation for analyzing a problem as a knowledge based task, and for developing and demonstrating a systematic framework consists of several steps. L We have analyzed an experienced operator’s reasoning in controlling an emergency situation specifically, the loss of feed water in a boiling water reactor. Our analysis has considered the situation of multiple malfunctions and unanticipated failures. The purpose of the task analysis was to characterize the complex set of operator actions as a ^tem atic process of several simpler tasks. Also, the task analysis provided a characterization (in information processing terms) of the nature of the task and the knowledge involved. 2. The results of the task analysis are used to develop an information processing model The purpose of the information processing model is to specify the solution space for the problem and the computational approach to model the various problem solving tasks performed by the operator. To test the model a high level knowledge representation 210 language was developed. This langu%e essentially implements the necessary mechanisms to model the task specific knowledge and the problem solving approaches. 3. Based on the information processing model and using the knowledge representation language an experimental prototype was developed for synthesizing emergency procedures for a boiling water reactor. The experimental prototype was tested on several selected scenarios to demonstrate the various features of the model. 6.2 CONTRIBUTIONS AND RESULTS Our analysis of the task of an expert operators reasoning in constructing control actions and the development of a systematic approach for dynamic synthesis of control actions for a nuclear power plant has produced results and contributions discussed below. 1. The task analysis presented in Chapter 3 showed that the task of controlling an operational emergency requires capability to construct or synthesize procedures in order to respond to unanticipated initiating events, failure of selected procedures, and unexpected response of plant to selected procedures. 2. The results of the task analysis confirm that an operators actions can be viewed as a process of solving the following problems (described in section 3.2.2): • Is there a problem that requires a corrective action? 211 • Are the data reliable? ® What procedure to select? • Should the selected procedure be executed? • How to determine that the selected procedure will not be executable? • How to synthesize an executable procedure? • How to interpret a procedure for execution. Le., given a procedure how to determine the actions and the order of their execution? • How to determine success/failure of the procedure? ® How to recover from a procedure failure? The task analysis also decomposed an operators task into several simpler tasks, such as, plant status monitoring, abnormality detection, sensor data validation, malfunction diagnosis, consequence prediction, procedure synthesis, and failure recovery. 3. Based on the results of the task analysis a framework for organizing plans and problem solving to dynamically qmthesize procedures (DPS) has been developed- The DPS framework specifies an organization of predefined plans and computational approaches for various problem solving processes. In this dissertation we have specifically developed approaches for selecting procedures, executing procedures, synthesizing procedures, and failure recovery. 4. Based on the analysis of the knowledge required for procedure synthesis in a NPP we have identified several types of knowledge, such as, knowledge about 212 system status, conditions and predicates, parameter trends and temporal relationships, diagnostic knowledge, knowledge about plans, and control knowledge. We have developed a representation formalism (DPSRL) for modelling the various knowledge types which is consistent with the way experts conceptualize about plans and allows for efficient problem solving. We have also implemented the representation language in Interlisp-D on a Xerox Lisp machine. 5. Based on the DPS model we have developed a framework for emergency procedure synthesis (FEPS) for nuclear power plants. The FEPS framework organizes the predefined plans into three plan libraries and uses mechanisms of DPS to realise integration between them. The FEPS framework also proposes a safety goals hierarchy to main tain plant safety functions, achieve efficient int^ration between various plan libraries, and realise the defense-in-depth philosophy. The FEPS approach requires that procedures and other relevant knowledge be modelled in accordance to DPSRL. 6. We have developed an experimental implementation of FEPS for a typical BWR using typical procedures and other domain specific knowledge. The experimental implementation is tested using several transient scenarios including cases for multiple malfunctions and safety function threatening scenarios. The results from the test cases successfully demonstrated various features of DPS/FEPS. Typical response time of the FEPS program are also summarized in Table 3. 213 In section 1.2.1 and 1.2.2 we discussed various research issues. The DPS approach and the DPSRL language provide solutions to the following research issues identified in section L2.2: • specification of the search space, and appropriate indexing mechanism (sections 3.3.4), • specification of the problem solving mechanisms and their computational models (section 3.3.5).. and c organization and representation of domain specific planning knowledge (sections 4.2 and 4.3). The FEPS framework and the experimental prototype for a BWR provide solutions to the following research issues identified in section 1.2.1; • migration of various procedure selection approaches (section 5.1.3). • unambiguous interpretation of procedures (sections 3.3.5, 4.3.4, and 5.4), • multiple malfunctions and procedure failures (sections 3.3.5. 5.2, 5.3, and ■ 5.4). • synthesis of potentially successful procedures (section 3.3.5), and • graceful d%radation or the defense-in-depth philosophy (section 3.3.5, 5.2 and 5.4). 214 6.3 CONCLUSIONS This dissertation has provided the necessary background and examples to show an application of the knowledge based systems approach to the complex problem of procedure synthesis in runtime. This dissertation has proposed and demonstrated a systematic framework for dynamically synthesizing, executing, modifying, and recovering procedures from failures. The feasibility of icing the framework to develop an approach for emergency procedure synthesis for a nuclear power plant is also demonstrated. The conclusions reached are discussed below. 1. Viewing the problem of operating a complex system as a knowledge based problem solving task provides a useful and practical solution to the problem of human error. The knowledge based approach provides a useful decomposition of the complex task of controlling a power plant in terms of simpler subtasks, andan identification of the types of knowledge required. Modelling the problem solving activity required for various subtasks as computational process enables the development of a precise theory on how to synthesize procedures in runtime, and the automation of the problem solving process using computers. Having identified various subtasks, the knowledge required, and their computational models it is possible to ascertain the computational complexity of various subtasks. In the design of a man-machine system the knowledge of the computational complexity of the various tasks can be used in dividing the the decision making function between the operator and the computer based decision aid system. 215 2. The DPS framework is an adequate model for organizing plans and synthesizing procedures if the application domain satisfies the various assumptions described in section 3.3.3. To a large extent these assumptions are true in the NPP domain, and we believe that they will be approximately true for other process industries. The DPS framework reported in this dissertation addresses a few of the several problem solving tasks identified in section 3.2.2. However, the framework can be enhanced to include other problem solving tasks. 3. The knowledge representation framework of DPSRL can be used to express a large number of procedures and other knowledge types. The representation of plans is not only usable for the NPP domain, it is also natural and easy to use by domain experts. We believe that our modelling of plans and other knowledge types is by far the most extensive made to date for the NPP domain. We also believe that DPSRL contains modelling ideas useful for other application domains as well. 4. The DPS based FEPS framework for synthesizing emergency procedures attempts to overcome most of the drawbacks of the existing approaches outlined in Chapter 2 We have shown that FEPS does provide a promising framework to organize predefined procedures, enables efficient int^ration between different procedure selection approaches, has the unambiguous procedure interpretation and failure recovery features of DPS, and does realise the defense-in-depth philosophy. FEPS can be enhanced as more powerful problem solving approaches are developed for consequence prediction and diagnosis. FEPS is not a simple implementation of 216 existing approaches but a significantly different and unique approach based on the principles of DPS. 6.4 RECOMMENDATIONS FOR FUTURE WORK We believe that the DPS/FEPS frameworks described in this dissertation can serve as a basic foundation for future enhancements to develop a cognitively more accurate and computationally efficient framework, which can then be used for developing systems for practical use. In this section we identify research, and technology transfer issues for future work. 6.4.1 Research Issues Goai Conflict Resolution and Pricritizaticn: The approach to the dynamic synthesis of procedure described in this dissertation involves procedure selection, procedure expansion and synthesis, execution, and goal directed procedure modification. Selecting the intial procedure requires an unambiguous identification of goals to be achieved. In the situation where it is required to satisfy multiple goals a principled approach is needed to resolve goal conflicts and prioritize them. In this dissertation the problem of goal conflicts and prioritization is not solved. It is recommended that research be done to address the problem of resolving goal conflicts and prioritization. 217 Diagnostic Reasoning and Sensor Malfunction Detetction In general the procedure expansion leads to a large detailed plan containing actions that may clearly fail if executed. Such actions can be recognized during plan synthesis if it is known that certain critical systems are in a failed state. Determining failure state of various systems and their impact on the success of specific actions requires sophisticated diagnostic capability. The framework develop^ in this dissertation is capable of incorporating a sophisticated diagnostic capability but in the current state of development simple state checking strategj' is used. It is recommended that a powerful diagnostic approach should be developed and integrated with the proposed DPS framework. Diagnostic reasoning is also needed for another important task: Sensor malfunction detection. The nature of di^nostic reasoning required for sensor malfunction detection and signal validation can be quite different from the diagnostic reasoning required to determine tha availability of a certain procedure. The ongoing research on signal validation at the Ohio State University is expected to provide a greater understanding of this problem [Chandra 85a] [Hashemi 86]. Consequence Prediction Another kind of problem that exists in expanded plans is that the subplans may have undesirable interactions. In general to recognize these interactions it is needed 218 to simulate the effects of actions to predict their impact on the plant and on the success of other actions. The problem of developing prediction capability is not solved in this thesis although the need to efficiently use such knowledge when available is clearly recognized. The framework can be enhanced to utilize the capability of a consequence prediction problem solver. It is recommended that research be performed to solve the problem of consequence prediction. Apart from using consequence prediction for eliminating potentially unsuccessful procedures, the consequence prediction can also be used to recommend creative procedures. For example, knowing the details of how components functions and their interactions, it is possible to simulate and generate new procedure sequences. Research in reasoning about simulation can produce useful results for the procedure synthesis task. System Functional Model The problem of resolving goal conflicts, identifying what goals to pursue, and consequence prediction can benefit from a knowledge about system structure and component behavior. In the present status the knowledge representation scheme developed does not allow for representing component behavior and structure. Any such representation has to be motivated by how such knowledge will be used to solve various problems. Using knowledge about component behavior to solve various problems is an area of active research in AI. Continued research in this area is 219 recoînmended including a subsequent integration of consequence prediction capability with DPS. Use of Analytical and Simulation Models In engineering problems a large body of knowledge exists in the form of analytical models and quantitative data. For the problem solving addressed in the thesis it still needs to be defined how and where analytical models of system can be usefuL Modeling component behavior models can be one possible area. In the current implementation quantitative data is used in rather simple manner. The need for using such data for reasoning is apparent but basic research issues are still being defined and not addressed in this dissertation. It is recommended that problems involved in int^rating analytical model with symbolic models be pursued. Explanation of R easoning In knowledge based systems the capability to query the system to get explanation for various decisions is very important Simple what and how questions do not address the complex issues of explanations. In the current implementations information to answer questions like what and how can be accessed using the powerful interactive interface. Research issues of explanation are recommended for future work. 220 Temporal Reasoning about System Data In understanding the behavior of engineering systems and selecting control actions it is often important to reason about trends and temporal relationships. In this dissertation some initial direction has been proposed. The need for a systematic study of temporal issues as they relate to procedures synthesis is recognized and recommended for further work. Temporal Reasoniw in Execu tins Actions After executing an action there is a certain time delay before the desired effects begin to appear. A relevant question is how long to wait for the effects to materialize before assuming that the action has failed. For simple situations it may be possible to predefine the wait time, however, for most situations there may be a need to reason about the system dynamics as determined by the prevalent scenario. A similar situation exists in evaluating the preconditions to determine the excutability of the action. Sometimes the preconditions may not be true at the time of evaluation but may become true after a while. The question then is to determine if one should wait for the preconditions to become true, and how long should one wait. We recommend that temporal issues in executing actions be studied in a future work. 221 Knowledge Intensive Reasoning In the DPS framework, the executability of a procedure is determined by exhaustively checking the availability status of all the subactions. As can be seen from Table 3 in Chapter 5, this causes lo n ^ execution time for larger procedures. It is possible to use domain specific knowledge to limit the number of subactions whose availability needs to be checked. We recommend that this issue be studied as a knowledge based problem rather than a problem of defining a general algorthim. 6.4,2 Technol^y Transfer Issues The motivation of the work described in this dissertation was to develop a solution to a real problem of providing knowledge based decision aid to a power plant operator. To realize this objective the ideas proposed in this dissertation need to transfered to a NPP. However, before such a transer can be accomplished various research issues discussed above need to be resolved. Moreover, technology tranfer specific issues disscued below need to be addressed. The role of the FEPS/DPS based System In introducing a new technology the definition of its role and migration with the existing plant need to be carefully analyzed. We envision that an FEPS/DPS based operator aid will supplement the existing operating procedures and emergency response mechanims rather than replace them. The FEPS/DPS based system wiU 222 provide several advantages in terms of a systematic approach for procedure selection, execution, and failure recovery based on defense-in-depth philosophy and will be ideally suited as an advising system. We recommend that research be performed in collaboration with experts from power plants to define the role and the plant for kaowlcugc based operator advisory systems. Validation and Performance Evaluation To be of practical use, the FEPS/DPS based system will need to have validated procedures and an acceptable performance. Since, the FEPS systems provides an interpretation of its procedures, the correctness of the procedures can be determined with a greater rigor than has been possible with the written procedures. The performance evaluation is required to ascertain the quality and the timeliness of the advice provided by the system. We recommend that such tests be performed. There is another performance evaluation criteria; the reduction in risk. We recommend that an analysis be conducted to determine the impact of the use of a FEPS/DPS based system on the relative change in the risk in controlling an abnormal incidenL Development of Knowledge Base For practical use the need for a large knowledge base is obvious. In this dissertation we have described a framework for collecting and organizing necessary 223 knowledge. We believe that the development of a reasonably complete and well tested knowledge base for a specific plant will take more than a 4 man-years effort. Application Specific Hardware The current implementation of FEPS is on a Lisp machine. Lisp machines provide a powerful development environment, however, they are not adequate for application in a power plant. Thus we cannot recommend the Lisp machine hardware or the Lisp software for implementing the systems to be used in a power plant The selection of a hardware and software has to be done to provide adequate interface with the rest of the plant We also recommend that the potential for application specific hardware based on VLSI technology be explored to achieve a high degree of performance necessary for real-time applications. 224 REFERENCES [Allen 84] Allen. J. F. Towards a General Theory of Action and Time. Ajrtifida! Intelligence 23(2), July, 1984. [Allen 85] Allen, J. F. and Hayes, P. J. A Common-Sense Theory of Time. In Proceedings of the Ninth IJCAI. International Joint Conferences of Artificial Intelligence, Inc., August, 1985. [Anyakora 74] Anyakora, S.N., and Lees, F.P. Detection of Instrument Malfunction by the Process Operator. In E. Edwards and P.P. Lees (editors). The Human Operator in Process Control. Taylor and Francis Ltd., London, 1974. [B & W 80] Abnormal Transient Operating Guidelines (DRAFT). July, 1980 Babcock & Wilcox. [Bernard 86] Bernard, J. A. The Construction and Use of a Knowledge Base in the Real-Time Control of Research Reactor Power. In B. R. Upadhyaya, T. W. Kerlin, and E. M. Katz (editors), Proc. of the 6th Power Plant Dynamics, Control & Testing Sym posium . The University of Tennessee, Knoxville, Tennessee, ApriL 1986. [Bobrow 77] Bobrow, Daniel G. A Panel Discussion on Knowledge Representation. Proc. of International Joint Conference On Artificial Intelligence , 1977. [Bobrow 83] Bobrow, D. G. and Stefik, M. The LOOPS Manual The Xerox Corporation, 1983. [Buchanan 84] Buchanan, B. G. and Shortliffe, E. H. Rule-Based Expert Systems: The Mycin Experimerns of the Stanford Heuristic Programming Project. Addison-Wesley Publishing Company, 1984. 225 [Bullock 69] Bullock, J3. Seminar on the Applications of On-Line Computers to Nuclear Reactors. Nuclear Safet'/ 10(2), Mar-Apr., 1969. [Cain 84] Cain, D. BwR Advanced Operator Aids/Expert System. 1984. Presented at the EFRI Workshop on Artificial Intelligences for the Nuclear Industry. [CE 81] Combustion Engineering Emergency Procedure Guidelines. June, 1981 Report No. CEN-152. [Chandra 82a] Chandrasekaran, B.. Sharma, D. D., and Miller, D. W. The Application of Knowledge-Based Systems to Reactor Operation. Trans. Am. Nucl., Vol. 43 , November, 1982. [Chandra 82b] Chandrasekaran, B., Mittal, S. and Smith, J. Reasoning with uncertain knowledge: the MDX approach. Proceedings of 1st Annual Joint Conferences of the American Medical Informatics Association , 1982. [Chandra 85a] Chandrasekaran, B. and Miller, D. W. An Artificial Intelligence Approach to Sensor Conflict Detection. Proc. of the ANS International Topical Meeting on Computer Applications for Nuclear Power Plant Operations and Control, Pasco, Washington , September, 1985. [Chandra 85b] Chandrasekaran, B. Generic Tasks in Knowledge Rased reasonng: Chracterization and Designing Expert Systems at the ’R i^ t’ Level of Abstraction. In Proc. of the Second Conference on Artificial Intelligenœ Applications. The IEEE Computer Society. December, 1985. [Clancey 85] Clancey, WJ. Heuristic Classification. Artificial Intelligence 27(3), December, 1985. [Corcoran 81] Corcoran, W. R., Church, J. P., Cross, M. T., and Guinn, W. N. The Critical Safety Functions and Plant Operation. Nucl.Technology. Vol. 55 , December. 1981. 226 [Davis 83] Davis, R. and Shrobe, H. Representing Structure and Behaviour of Digital Hardware. IEEE Computer , October. 1983. [Friedland 79] Friedland, P. E. Knowledge-based Experiment Design in Molecular G enetics. Technical Report, Computer Scirace Department, Stanford University. 1979. Report No. 79-771. [FSAR 85] FSAR: Perry Nuclear Power Plant Units 1 & 2 Chapter 15. 1985 [Fulcuda 79] Fukuda. T. Application of Stable Adaptive Schemes to Nuclear Reactor Systems. 2. Parameter Identification and Adaptive Control of Non-linear Loosely Coupled Core Reactor. Journal of Nuclear Science and Technology 16(7), July. 1979. [Gallanti 85] Callanti, M.. Giovanni G.. Spampinato. L.. and Stefanini A. Representing Procedural Knowledge in Expert Systems: An Application to Process Control Proc. of IJCAI , 1985. [GE 81] Emergency Procedure Guidelines - BWR 1 throu^ 6, Revision 1. January, 1981 General Electric Comapany. [Genesereth 82] Genesereth, M. R. Diagnosis Using Hierarchical Design Models. In Proc. of American Association for Artificial Irrtelligence. August, 1982. [Georgeff 85] Gcorgeff. M.P., Lanslcy, A.L., and Bessieixe, P. A Procedural Logic. Proc. of IJCAI . 1985. [Gomez 79] Gomez, F. and Chandrasekaran, B. Knowledge Organization and Distribution for D i^osis. IEEE Trans. Systems, Man. and Cybernetics , January. 1979. Special Issue on Metaphors for Problem-Solving in Distributed Systems. 227 [Gonzalez 73] Gonzalez, R.C On the Application of Pattern Recognition Methods to Reactor Malfunction Diagnosis. Proc. of Power Plant Dynamics, Control and Testing 2, 1973. [Hashemi 86] Hashemi Sia, Hajek B.. Miller. D. W., Josephson J. J.. Cbandrasekama. B. Expert System Application to Plant Diagnosis and Sensor Data Validation. Proc. of the Sixth Power Plant Dynamics, Control, and Testing Symposium . April 14-16, 1986. [Ina 73] Ina. S., Yoshikawa, H-, and Wakahayashi, J. Simulation Study of a Diagnostic System of Nuclear Reactor. Proc. of Power Plant Dynamics, Control, and Testing 2, 1973. [Joyce 83] Joyce, J. P. and Lapinsky, G. W. Jr. A History and Overview of the Safety Parameter Display System Concept iEEE Trans, on Nuclear Science NS-3(Ki), February, 1983. [Kanji 73] Kanji Kato. Anamoly Detection System for Nuclear Power Plant Proc. of Power Plant Dynamics, Control, and Testing 2, 1973. [Kemeny 79] Kemeny, J.G. R epot of the Presidents Commission on The Accident at Three Mile Island The Need for Change: The legacy of TML Pergamon Press, 1979. [Koen 75] Koen, B. V. and Mcdonald J. L. Application of Artificial Intelligence Techniques to Digital Computer Control of Nuclear Reactors. Nuclear Science and Engineering 56(2), February, 1975. [Lambert 77] Lambert H. and Yadigargolu. Fault Trees for Diagnostics of Syston Fault Conditions. Nuclear Science and Engineering 62, January, 1977. 228 [Lewis 85] Lewis. Janice R. Safety Systems Status Monitoring. Nuclear Safety 25(4):459-467, July-August, 1985. [Long 84] Long. A.B. Computaiized Operator Decision Aids. Nuclear Safety 25(4). July-August. 1984. [Mancini 84] MancinL C.. and Wahlstrom, B. Recent Development in Designing and Validating Emergency Operating Procedures and Training Operators in Their Use. In Fiftfie International f/leeting on Thermal reactor Safety, pages 746-75L Nuclear Research Center, Karlsruhe, Sept 9-13, 1984. [Meijer 80] Meijer, C H. and Fr%ner, B. On-Line Power Plant Alarm and Disturbance Analysis and Surveillance Systems (DASSJ. Technical Report, Electric Power Research Institute, ApriL 1980. EPRI-NP-1684. [Meijer 81] Meijer, C H., Pasquenza, J. P., abd Deckert, J. C On-Line Power Plant Signal Validation Technique Utilizing Parity-Space Representation and Analytic Redundancy. Technical Report, Electric Power Research Institute, Palo Alto. California. November, 198L Report EPRI-NP-2110. [Meijer 84] Meijer, C H. A critical Function Expert System for Nuclear Power Plants. Worksfiop on Artificial Intelligence Applications to Nuclear P o w e r , 1984. [Miller 56] Miller, George A. The Magical NumberSeven, Plus or Minus Two: Some Limits of Our Capacity for Processing Information. Psychological Review 63, 1956. [Motoda 85] KigucM, T. and Motoda, H. A Knowledge Based System for Power Plant Diagnosis. Proc. of the ANS International Topical Meeting on Computer Applications for Nuclear Power Plant Operation and Control. Pasco, WA . September, 1985. 229 [Murata 84] Murata F., Kaio K., and Hashimoto S. Operator Support System For Emergency Conditions. In Ooerational Safety of Nuclear Power Plants. International Atomic Energy Agency, Vienna, 1984. [Nelson 82] Nelson, William R. REACTOR: An Expert System for Diagnosis and Treatment of Nuclear Reactor Accidents. Proc. of Naticna! Conf. on A! , Aug 18-20, 1982. [Nilsson 79] Nillson, N. J. Some Examples of AI Mechanisms for Goal Seeking. Planning, and Reasoning. In Friedhart Klix (editor). Human and Artificial Intelligence. North-HoUand Publishing Company, 1979. [Nishizawa 83] Nishizawa, Y., Motoda, H., Yamada, N., and Wada, Y. Approach to Knowledge Based Man-Machine Communication for BWR Start-Up Guidance. Journal of Nuclear Scierice ard Technology 20(10), 1983. [Rasmussen 79] Rasmussen. Jens. On the Structure of Knowledge - A Morphology of Mental Models in a Man-Machine Context. Technical Report M2192, Riso National Laboratory, Roskilde, Denmark, 1979. [Rasmussen 84] Rasmussen, Jens. Strat%ies for State Identification and Diagnosis in Supervisory Control Tasks, and Design of Computer-Based Support Systems. Advances in Man-Machine Research 1:139-193, 1984. [Rouse 84] Rouse, W. E editor. Advances in Man-Machine Research. JAI Press Inc., 1984. [Sacerdoti 77] SacerdotL E D. A Structure for Pians and Behavior. Elsevier North Holland Publishing Company, New York, 1977. 230 [Saedtler 79] Sædtler, E. A New Method for On Line Surveillance of Nuclear Power Reactors based on Decision Theory. NucL Engg. and Design 51, 1979. [Saxe 73] Saxe, R. F. Power Plant Dynamics and Malfunction Detection. Proc. of Power Plant Dynamics. Control, and Testing 2, 1973. [Schank 77] Schank, R. and Abelson, R. Scripts Pians Goals and Understanding. Lawrence Exlbaum Associates, Publishers, Hillsdale, New Jersey. 1977. [Seeman 83] Seeman, SJE., Colley, R.W., and Stratton, R.C. Optimization of thr Man-Machine Interface for LMFBR’s. Nuclear Safety 24(4), July-August, 1983. [Sembugamoorthy 84] Sembugamoorthy. V., and Chandrasekaran, B. Functiorial Representation of Devices and Compilation of Diagnostic Problem Solving Systems. Technical Report, Laboratory of AI Research, Dept of Computer and Information Science, The Ohio State University, 1984. [Sheridan 80] Sheridan. T. B. Human Error in Nuclear Power Plants. Technology Review , February. 1980. [Shewmon 82] Shewmon, P. and Palladino. NJ. ACRS Report on Emergency Response Capabilities at Nuciear Power Plants Nuclear R^nlatory Commission. May 11, 1982. Available from NRC Public Document Room. [Simon 72] NeweU, Allen and Simon, Herbert. Prct!c.m. Sdvi.ng. Prentice-HaU, New Jer^, 1971 231 [Sureau 84] Sureau, H., and Mesnage, J. Physical State Approach to PWR Emergency Operating Procedures: Recent Developments in France. In Fifth international Meeting on Thermal reactor Safety, pages 833-841 Nuclear Research Center. Karlsruhe, Sept. 9-13, 1984. [Tanji 85] Tanji Junichi. and Utma Shunsuke. A Symptom-Oriented Method for PostTrip Operation Guidance in Boiling Water Reactors. Nud. Technology 71580-589, December, 1985. [Taylor 85] Taylor, G.M. Meeting reviews Computer use in Nuclear Power. Nuclear News , November, 1985. [Underwood 82] Underwood, W. E. A CSA Model-Based Nuclear Power Consultant. Proc. of AAA! . August, 1982. [USNRC 79] U. S. Nuclear Regulatory Commission. TMI-2 Lisons Learned Task Force Final Report. Technical Report, , October, 1979. USNRC Report NUREG-0585. [USNRC 81] U. S. Nuclear R^ulatory Commission. Functional Criteria for Emergency Response Facilities Final R eport. Technical Report, , February, 1981 USNRC Report NUREG-0696. [USNRC 83] U.S. Nuclear R^ulatory Commission. Clarification of TMi Action Plan Requirements: Requirements for Emergency Response Capability. Technical Report, , January, 1983. USNRC Report NUREG-0737. 232 [vonHemnamn 83a] vonHerrmann. J.L. Methods for Review and Evaluation of Emergeno/ Procedure Guidelines Volume 1: Methodologies. Technical Report, U,S. Nuclear R^nlatory Commission, March, 1983. USNRC Report NUREG/CR-3177. [vonHerrmann 83b] Brinsfield, W.A., Bums, E.T., McClymont, A.S., Mays, S.E., and vonHerrmann. JJ - Methods for Review and Evaluation of Emergeno/ Procedure Guidelines Volume 3: Applications to General Electric Plants. Technical Report, U.S. Nuclear R%ulaiory Commission, September, 1983. USNRC Report NUREG/GR-3177b. [WASH-1400 74] Rassmussen, N. WASH-1400: Reader Safety Study Appendix 9: Safety Design Rationale for Nuclear Power Plants. Technical Report, U.S. Atomic Energy Commission, 1974. [Wilensky 83] Wilensky, R. Planning and Understanding. Addison-Wesley Publishing Company, Reading, Massachusetts, 1983. [Woods 83] Woods, William A. What’s Important About Knowledge Representation? IEEE Computer , October, 1983. [Xerox 83] The Interlisp Reference Manual 1983. [Yufii 83] Yufik, Y. M. and Sheridan, T. B. A Framework for Design of Operator Planning/Decision Aids. Trans, of Am. Nud. Soc. 45. 1983. APPENDIX A. SAMPLE PROCEDURES USED IN IMPLEMENTING FEPS 233 234 A.1 EVENT PLANS [OEFCLASS ReactorScram (MetaClass GoalPJansMeta Edited: (‘ ddt“24-Jun-86lt:29")) (Supers Events) (ClassVarlables (Planlibrary (Limit ImmediateActions FollowOn) doc (*) tmmediateActlons (DoSequenceAII (Put the Reactor Mode Switch In SHUTDOWN) (Insert ControlRods tomalntain (Achieved InsortodReactlvityCntrl)) (DoSequence (Verify Closed SDV.VentValves) (Verify Closed SOV.OralnValvos)) (Verify Decreasing Reactor.Power tomalntain (Achieved React1vItyCntrl)) [OoMonltor ((Reactor.Power < 5 %) > (Trip MalnTurb causing ((Closed "Main Stop Valve") (Closed "Turb Control Valves") (Closed "Combined Intermediate Valves") (Open "Gen Breakers") (Tripped "Normal Supply Breakers") (Closed "Startup Supply Breakers") (Tripped "Gen Field Breakers"] [DoMonltor ((OR (DuratlonOf FWFlow < 22 X) > 15 sec) (RPV.WatorLevel < 178 in) ((DuratlonOf 01fferentlalTomp of SteamOomo/Rec1rcPumpSoctlonLIne < 8 F)> 15 sec)) (DoSequence (Verify LowSpeedMode ReclrcPumps) (Verify HanualMode fleclrcFlowControl] (Verify Achieved RPVPressureControl) (Maintain RPVWaterLevel to (RPVWaterLevol » 200 In) tomalntain ^ (Achieved RPVWaterLevelControl))) FollowOn (OoAtMany (Align FWSystom to CondonsateSystom) (Maintain RPV.WatorLovol to (RPV-WatorLovol < 215 in)) (WaitFor "Cloarod Scnc Conditions") (Rosot RPS) (Rosot ARI) (Align RecircPumps) (Oporato RWCU toachiovo ((RPV.WatorLovol > 193 in) (RPV.WatorLovol < 215 in))) (Follow "Plant Cooldown Procoduro")) limit (DoSequenceAII ImmediateActions FollowOn)) (Enter! ((OR (AlarmOn Full Scram) (AlarmOn ilalfScram)) (OR (AlarmOn "RPS Manual Scram") (AlarmOn "RPS RX PRESS ill") (AlarmOn "RPS DW PRESS ill") (AlarmOn "RPS INST VOL ill") (AlarmOn "RPS NEUTRON MON TRIP") (AlarmOn "RPS HSIV CLOSURE") (AlarmOn "RPS MSL RAD HI") (AlarmOn "RPS TURB CONT V FAST CLOSE") (AlarmOn "RPS RX LEVEL HI L8") (AlarmOn "RPS RX LEVEL LO L3") (AlarmOn "RPS TURB STOP VLV CLOSURE"))) doc (*) (InferedStates NIL doc ('))) ( InstanceVariables (LimitReactorScram LimitReactorScramLimitA0632 doc (* IVadded by )) ( Immed iateAct ionsRoactorScram ImmediatoAct ions Re actor Sc ramlmmedi fit o Act ions A0633 doc (‘ IV added by )) ( Fol lowOnRoactorScram Fol lowOnReactorScrarnFol low0nA0634 doc (' IVadded by )) (Limit RoactorScramLimitOoSequenceAl 1AQ635 doc (* IV added by )) ( ImmediatoAct ions Reac torSc ramlmmedi a toAc t ionsDoSoqiionceAl 1A0659 doc (* IVadded by )) (FollowOn RoactorScramFollow0nDoAsManyA0675 doc (* IV added by)))] g [OEFCLASS LoSSOfAllFW (MstaClass GoalPlansHata Edi Lad : dds"24 Jun 86 23 S8”)) (Supers Events) [ClassVarlables (Enter? ((Tripped fWPumps) (Decreasing RPVWaterLevol) (OR (Decreasing FWFlow) (Decreasing FWPumps)) (OR (Decreasing RxFeedPumps.RPM) (Decreasing HFP.Amps))) doc (* 8ef: Perry fWPump Trip Procedure) (Plantibrary (ImmediateActions FollowOn Limit) doc (•* Ref: Perry FSAR and EG&G Report) ImmediateActions [OoTracking ((Level4 RPV.WatorLevel) * (Runback ReclrcPumps tomalntain (Achieved CoreFlowControl))) [(Levels RPV.WatorLevel) > (DoSequenceAII (limit ReactorScram tomalntain (Achieved RoactlvltyCntrl )) (Trip ReclrcPumps tomalntain (Achieved CoreFlowControl] ((L0 V0 I2 RPV.WatorLevel) • ^ (StartlllPressInj ECCS tomalntain (Achieved IllProssInventoryControl ] FollowOn ((Normal RPV.WaterLevel ) (Normal RPV.Pressure) • > (Start Shutdown .RI1R tomalntain (Achieved ShutdownCool IngControl ))) limit (DoSequenceAII ImmediateActions FollowOn tomalntain (Achieved MaIntCoroIntegrity] [DEFCLASs OpenReliefSafetyValve (HetaClass GoalPlansMeta Edited: (• dds 'B Dec S521 :S9")) (Supers Events) (CiassVariables (Symptoms NIL doc (')) [Plantibrary (limit ImmediateActions FollowOn) doc (•) Limit (DoSequenceAII ImmodiatoAct ions FollowOn) ImmediateActions [DoSequence (TurnOn "Plant £mar()Oncy Alarm") (Announce "Evacuate Containment") (DoDackUp (Close Opened.SRV) (Oaenorgizo SRVSolenoids) (DoSequence (Open SRV) (DoDackUp (Close SRV) (Doenergizo SRVSolenoids] FollowOn (DoMonltor ((SuppPool.Level > 13.5 ft) •> (ExitTo (Achieve SuppPoolLovelControl ) ) ) ((SuppPool.Temp > 95 F) > (ExItTo (Achieve SuppPool TempControl ] (Enter? ((OR (AlarmOn "SRV OPEN") (AlarmOn "SRV LEAKAGE PGM")) (OR (Increased SuppPool.Temp) (Increased SuppPool.Level) (Decreased HalnGen.Power) (Mismatch SteamFlow.fWFlow))) doc (* Undocumented CV added by SUAHMA) ))] « [OEFCLASS RecircPumpLost (MstaClass GoalPlansMeta Edited: ddt " B Dec-OS22:46")) (Supers Events) (CiassVariables (Plantibrary (Limit ImmediateActions FollowOn) doc (* Ref: Perry to» oF Reclrc Pump Procedure) Limit (DoSequenceAII ImmediateActions FollowOn) ImmediateActions [DoAsMany (DoMonltor ((RPV>Watertevol < 219 in) > (DoSequenceAII (Verify Shutdown Reactor) (Verify Tripped MainTurb) (Verify Tripped RFPT) (Verify MFP))) ((Mismatched SteamFlow.fWFlow) ■> (Verify Reduced FWFlow))) (DoAsMany (Control RPV.WaterLevel to ((RPV.WaterLevel > 197 in) (RPV.WaterLevel < 205 in))) ((Increasing RPV.WatorLevel) ■ > (ManualControl FWControlSystem)) ((Stabilized RPV.WaterLevel) (Docroaso Reactor.Power to "Iimit specified"))) (((NumberTripped RecircPumps)' 2) •> (DoSequence (Shutdown Reactor) ((Unstable Reactor.Power) > (Trip RPS] FollowOn (FollowOn RecircPumps)) ' (Enter? ((OR (AlarmOn "RCIRC MOTOR LOCKOUT") (AlarmOn "RCIRC AUTO XFER INCOMPLETE") (AlarmOn "RCIRC MG SET LOCKOUT")) (OR (Decreased Reactor.Power) (Oecreased RPV.WatorLovel) (Decreased MainGon.Power) (Decreased RecircPump.DiffPress) . (Decreased JP.Flow) (Mismatch RecircLoop.Flow) (Decreased CorePlate.DiffPress) (Decreased JP.TotalFlow) (Decreased FWFlow) (Decreased SteamFlow))) to doc (• Ref: Perry Loss of Redrc Pump Procedure) ^ ))] (* lVJauvaoy)Hj [OEFCLASS RocircFlowControlMalfunction (HptaClass GoalPlansMeta Edited: (‘ ddt "8 Dec-8522:2f")) (Supers Events) [CiassVariables (Enter? ((OR (AlarmOn "MASTER CONT TRIP OUTPUT RATE") (AlarmOn "FLUX CONT TRIP OUTPUT RATE") (AlarmOn "fCV MOTION INIUDITED") (AlarmOn "FCV HPU INOP") (AlarmOn "BOO BLOCK APRM RCIRC FLOW HI")) (OR (Mismatched RocircFlow.Loop) (UnexpectodChange APRMPoworLovol) (UnoxpectodChango RecircLoopF iuw) (UnexpectodChange TotalJPflow)) (UnexpectedChango JPLoopFlow))) (PlanLibraiy (limit ImmediatoAct ions FollowOn) doc (* Ref.' Perry tteactor llecirc flow Control Malfunction Procedure) Unit (DoScf|uenceAII ImmediateActions FollowOn) ImmediateActions (DoSequence (ManualMode RocircFlowControl) (OoBackUp (Restore Reactor.Power) (ArmandOopress "HPU SHUTDOWN"))) FollowOn (DoSequence (Balance RecircLoopFlow) (Insert ControlRods) toachieve (Decreased Reactor.Power]] è o (OEFCLASS FWPumpTrip 5 (MetaClass GoalPlansMota Editod: (‘ dds “ 5-Jul-86 >6:38“)) üi (Supers Events) % (CiassVariables [Plantibrary (Limit AutoActions ImmediateActions FollowOn) ;i; doc (‘ 8ùf:Perry rWPump Trip Procedure) [7^ limit (DoSequenceAII (DoSequence AutoActions ImmediateActions) FollowOn) g AutoActions m [DoSequence (Start MFP tomalntain (Achieved RPVWaterLevelControl)) m (DoMonltor ((Duration FWFlow < 22 X) > 15 secs) IS (LowSpeedMode RecircPumps tomalntain ^ (Achieved ^ RecircFlowControl))) g ((RPVWaterLevol < 198 in) 7) (OR (tripped RFPTA) p ( Tripped RFPTB)) - (Close "RecireFlowControlVa I VOS to 48 percent Loop Flow" toachlove (Achieved CoreFlowControl))) ((RPVWaterLevel » 178 In) ■> (DoSequence (Scram Reactor) (LowSpeedMode RecircPumps) (Isolate ShutdownCooling] ImmediateActions (DoSequenceAII (DoAnyOne (Reduce "RecircFlow to ' 30 percent" if ((Operating MFP) (NotOperating RFPA) (llotOperating RFPO)) toachiovo (Reactor.Power < 20 X))) (Reduce "RecircFlow to ' 45 percent” if (Operating One.AFP) toach ievo (Reactor.Power < 60 X))) (Reduce "RecircFlow to ' 70 percent" if ((Operating One.RFP) (Operating MFP)) teachievo (Reactor.Power < 80 X))) ^ toachieve (Achieved RocircFlowControl)) ^ (Start FWPumps tomalntain (Achieved RPVWaterLevelControl))) FollowOn (DoAsMany (DoMonltor ((ftPVWaterLovo) < 178 In) > (ExitTo Achieve MaintCoroIntegrity))) ((CausoOr FWPumpTrip is l.ossOfLuboOi I ) (DoAsMany (ClosoOischValvo FWPumps) (CioseRecircContro)Valve FWPumps) (CloseSuctValvo FWPumps) (IsolatoSoalStoamTo FWPumps) (BreakVacuum AuxCondonsor) (Shutdown FWPumps] (Enter? ((Tripped FWPumps) (Decreasing RPVWaterLevol) (OR (Decreasing FWFlow) (Decreasing FWPumps)) (OR (Decreasing RxFoedPumps.RPM) (Oecreastng HFP.Amps))) doc (* Ref: Perry FWPump Trip Procedure) )) (InstanceVariables (LimitFWPumpTrip LimitFWPumpTripLimitA1059 doc (* IV added by )) (AutoAct ionsFWPumpTr ip AutoAct ionsFWPumpIr ipAutoAct ionsA1060 doc (* IV added by )) (ImmediateActionsFWPumpTrip ImmedI ateActionsFWPumpTripImmediateActionsAiOBI doc T* IV added by )) (FollowOnFWPumpTrip FollowOnFWPumpTripFollowOnA1062 doc (* IV added by )) (limit FWPumpTr IpL imi tDoSequoncoAl 1A1063 doc (‘ IV added by )) (AutoActions FWPumpTripAutoActionsOoSequonceA1090 doc (' IV added by}) ( ImmediatoActions FWPumpTripImmed iateAct ionsDoSoquoncoAl1A1099 doc (‘ IV added by )) (FollowOn FWPumpTripFollowOnOoAsHanyAl106 doc (' IV added by )) ) ] g 243 A.2 SYSTEM PLANS [OEFCLASS RPV (MetaLljss SystemPlansMeta Edited: dds "l70ctS5 ?2:S)")) (Supers ComponentPlans) (CiassVariables (PlanLibraiy (Isolate Flood EmorgOepress InjectWator ExitFlood SteamCooI Ing InjectOoron) doc (* ref Party) Isolate (DoSequence (Stop RecircPumps) (Stop FWPumps) (Close. InjoctionValvo tIPCS) (Close LPCS) (Close LPCI) (Change RCIC . PiimpF low to 0)) InjectWator (DoSequence (Start FWPumps) (Start HPCS) (Start LPCS) (Start LPCI) (Start FWBoosterPumps) (Start CROPumps) (Start RIIR.SorviceWaterSystom) (Start ECCS.WatorLogPumps) (Start SLCPurops)) F lood [DoAnyOne (((NumberOpon SRV) < 8 ) (EmorgOepress RPV)) (DoAsMany ((OR ((NumberOpon SRV)= 3) (Available HPCS) (Available FWPumps)) • ^ (DoSequence (Close MSI'/) (Close "Riin & RCIC sr supp inbo isol valve-) (Close "MSI ORN 8 MSIV BYP INBO ISOL VALVE"))) [(Known RPV WatorLovol) • > (DoAnyOne ((Inserted ControlRods) (DoSequence (InJectWater RPV until (Increasing RPV.WaterLevel)) (ExitFlood RPV))) (DoSequence (Doliequence (Stop ReclrcPumps) (Stop FWPumps) (Close.InjoctionValvo HPCS) (Close LPCS) (Close LPCI) (Change RCIC.PumpFlow to 0) until (RPV.Preosure < ( MimAURPVFIoodingPress))) (DoBackUp (DoSequence (Start. FWPumps) (Start RxFWQoostorPumps) (Start CROPumps)) (Start RIIR) (Start HPCS) (Start LPCS) (Start LPCI) (Start ServlceWaterSystem) ((OR (Inserted ControlRods) ((Shutdown Reactor) (NOT (InJoctedBoron RPV))) • 5* (ExitFlood RPV))) toachieve ( IncreasodIejection RPV) until (((Numb»rOpen SRV)> 2) (RPV.Pressure > ( MinAltRPVFloodInpPress] g ((UnKnown RPV.WaterLovol ) -> (DoSequence (InJectWater RPV until (((NumberOpon SSV)> 3) (NOT (Incroasing RPV.Pressure)) ((RPV.Pressure - Containment.Pressure)> 130 psig))) (RestoreIndication RPV.WaterLevel) (InJectWater RPV until ((OryWel1.Temperature < 212 f) (Containment.Temperature < 185 f) (Known RPV.WaterLevel))) (ExitFlood RPV] EmargOepress (OoAsMany ((Required.Boronlnjection RPV) • ^ . (Isolate RPV)) (DoAnyOne ((SuppressionPool.WaterLevel > 8 ft) (OoOackUp (Open.Valves AOS) (Open SRV until ((NumberOpen SRV)> 7)) . (Rapidly "Depreesurize using options to be defined later"))) (Rapidly "Dopreesurize using options to be defined later")) until (Required (Flood RPV))) uteamCooling [DoAnyOne ((RPV.WaterLevel = -112 in) (OpenValvo SRV)) ((Unknown RPV.WaterLevel) ' (OpenValva SRV) (DoMonltor ((RPV.Pressure IE 700 psig) (EmergOepress RPV] InjectOoron (Inject "Boron into RPV" until (SLTank,Level < 1050 gal))) (Subsystems NIL doc (‘ Undocumented CV addcii by SHAHMA» (InlcredStatcs (NumberOflnjecLions RoquirodSteamCool ing RoquirodlnJoctBorun RoquirodFlood InjectodDoron) doc (•) NumberOfInjections ( 0 ) RoquirodSteamCooling NIL RoquiredlnjoctOoron ((NotShutdown Roactor) (SuppressionPool.Tempo rature >> 110)) RoquirodFlood NIL InjoctedOoron NIL)) [OEFCLASS PilotScramValves (MetaClass SystemPlansMeta Edited: (‘dds"23Oct-85IS02")) (Supers Valve) [CiassVariables (Subsystems NIL doc (*)) (Plantibrary (Open Close) doc (*) Open (OoBackUp (Trip RPS) (OoEnergize PilotScramValvosSolonoid) (Energize BackupScarmValvusSolenoid) (Initiate ARI) toachieve (Inserted ControlRods) toRcsotDo Nothing) Close (Close " PilotScramValves")) (InferedStates (Open Closed) doc Opened (Tolnlei (OR (Hovinglnside ControlRods) (Inserted ControlRods)) ToAchieve (Open PilotScramValves)) Closed (Tolnfet (Closed AllPilotScramValves) ToAchievo (Close PilotScramValves] (InstanceVariables (OpenP ilotScramValves OponPi1otSnramValvosGpenAOllS doc (• IV added by SUAHMA)) (ClosePilotScramValves ClosoPilotScramValvesClosoAOllB doc (• IV added by SUAHMA)) (Open PilotScramVaIvosOpenOoBackUpAOl17 doc (* IVaddcdby SUAHMA)) % (Close PilotScramValvosClosoCloseAOlZI doc " (* IV added by SUAHMA)) ) ] [OEFCLASS ControlRods (MetaClass SystemPlansMeta Edited: Cdds"3Feba6t6:3S")) (Supers ComponentPlans) (CiassVariables (Planlibrary Insert doc (* tv) Insert (OoBackUp (Trip UPS) (Open PilotScramValves) (DoSequenceAII (Reset RPS) (Reset ARI) (Trip RPS)) (ManualScram ScramSystem) ((RPV.Pressure > 1500 psig) ■ > (DoSequenceAII (Decrease RPV.Pressure to (RPV.Pressure < 1500 psig)) (Open PilotScramValves))) causing (Inserted ControlRods) nofix) doc (' Insert is a procedure to insert control rods without any prejudice of what the purpose is. It is subsystem specific ac(ion) ) (InferedStates (Inserted Mov inglns ide) doc (') Inserted (Tolnfer (Con trol Rods . Pos i t ion = 0) ToAchiove (Insert ControlRods)) Mov inglns ide (Chock "Control Rods Moving Inside"))) (InstanceVariables (Insert ControlRodsInsortOoOackUpAOI22 doc (' IV added by SHARMA)) ) ] [OEfCLASS RecircPumps (MetaClass SystemPlansMeta Edited: (" dds " 8 Doc-85 t7:28")) (Supers Pump) [CiassVariables (Subsystems (RecircPumpA RocircPumpB) doc (’ Undocumented CV added by 5IIARMA) ) (PlanLibraiy (Decrease.Speed HesetTripLogic Trip.FastSpeed Initiate.LFMG Irip.LFMG FollowOn FollowOnl/5Trip FollowOnl/4Trip FollowOnMultiTrip Stop Align) doc (‘ Ref Oyster Creek) Decrease.Speed (ChangeHanually SpeedControl) ResetTripLogic (Message "Reset Recirc Pumps Trip Logic") Trip.FastSpeed (Message " Trip Recirc Pump Fast Speed Operation Mode") Ini tlate.LFMG (Message "Initiate Recirc Pumps LFMG Mode") Trip.LFMF (Message "Trip Recirc Pumps LFMG Mode") FollowOn (DoAnyOne (((NumtierTrippod RecircPumps)» 1) ((NumberOporating RecircPumps)» 4) (Follow0nl/5Trip RecircPumps)) (((NumborTripped RecircPumps)» I) ((NumborOporating RecircPumps)» 3) " ^ (FollowOnl/4Trip RecircPumps)) (((NumberTrIpped RecircPumps)) I) • > (FollowOnMultiTrip RecircPumps))) doc 6 F 0 1lowOn1/ôT r ip (CioSequencc (OpoiiQyPassValve Trippod.Roc 1 rcPiimps) (ClosoPunipOFs chValvo Trippod Roc ircPumps) (Maintain RPV.WatorLovol to ({RPV.WatorLovol > 155 In) (RPV.WatorLovol < 165 In))) (Hossago "Notify tho Systnm Dispatcher of any powor limitations") (Verify 'Tech Spec limitations on continuod opération with ono Roc ire Puinp out of service")) folIow0nl/4frip (DoAsMany (DoScquonce (OponByPassValvo Trippod.RocircPumps) (ClosoPumpDischValve T ripped.RecircPumps) (Maintain RPV.WatorLevel to ((RPV.WatorLovol > 165 in) (RPV.WatorLovol < 165 in))) (Message "Initiate Plant Shutdown to Hot Standby") (Message "Initiate Plant Cooldown from Hot Standby to Cold Shutdown")) (DoSequenceAII (Restore RocircLoop. Idle) (RosuraoPoworOporation Reactor))) FollowOnMulti T rip (DoAsMany (((NumberTripped RecircPumps)» 5) • ^ (DoTogcthcr (Message "Open Suction Valves of All Roc ire Pumps") (Message "Open Discharge Valves of All Recirc Pumps"))) (Maintain RPV.WatorLovol to ((RPV.WatorLevel > 155 in) (RPV.WaterLevel < 165 in))) (Scram Reactor)) stop (DoSequenceAII (Trip.FastSpeed ReclrcPumps) (Trip.LFMG RecircPumps)) AT ign (DoSequence (Assure "Both Reactor Recirc Pumps running in slow speed") (Assure "Recirc loop A and B Flow Controls in Manual") (Assure "Flow Control Valves Full Open")) doc (* üef: Pony Peactor Scram Procedure) w o ) (InferedStates (Trippod NumberTripped NumberOperat ing) doc (*) Tripped T NumberTripped (for pump in (flecircPurops Subsystems) bind number •- 0 do (if (Condition? (Trippod pump)) then (number *- number r 1 )) finally (RETURN number)) NumberOperating (for pump in (RecircPumps Subsystems) bind number 0 do (if ■ (Condition? (Tripped pump)) then (number *- number ♦ 1 )) finally (RETURN number] ^ (MetaClass SystemPlansMeta Editod: (‘ ddi"24 Jun Q623:S3 )) (Supers ComponentPlans) [CiassVariables (Subsystems (IIPCS AOS LPCS LPCI) doc (*) (PlanLibrary (StartlliPressInJ StartOepress StartLoPressInj Isolatel.oPressInj ) doc (*) StartlliProssInj (DoTogether (Start IIPCS) (Start RCIC) toachieuo (Achieved lliPressInventr)ryControl )) StartOepress (DoTogether (Operate AOS) (Rol iefValve) toachieve (Achieved StoamRoliefControl)) StartLoPressInj (DoSequence ((RPV.Pressure > 400 psig) • > (DoBackUp (Operate SRV) (Operate AOS) toachieve (RPV.Pressure < 400 psig))) (DoAsMany (Start LPCI) (Start IIPCS) (Start LPCS) toachieve (Achieved LoPressInventoryControl) ) ) IsolateLoPressInj (DoTogetherAli (Isolate LPCI) (Isolate LPCS] K (InstanceVariables (StarttliPressInJECCS StartlllPress In jECCSStartlliPress In jA0754 doc ^ (' IV added by )) [OEFCLASS ScrimSystem (MetaClass SystemPlansMeta Edited: (•dds "22 Oct 8533")) (Supers ComponentPlans) (C1assVariïbles (Subsystems (PilotScramValves CROPumps SOV) doc (*) ) (Planlibrary (ManualScram Reset) doc (') Rosot (DoAsMany (Reset RPS) (Reset ARI) (Reset PilotScramValves) causing (InResetMode ScramSystem) toRcsctOo Nothing noFIx) ManualScram (DoSequenceAII (Reset ScramSystem) [DoBackUp (ManualTrip RPS) (DoSequenceAII (Start CROPumps) (Close "Charging water header isolation valve") (Open PIlotScramValves) (Message "Oirect the effluent from withdravr lino vent to a radwaste drain and open withdraw line vent" ) ((Inserted ControlRods) > (Shut "withdraw line vent"] toachieve (Inserted ControlRods) loResetDo (Reset ScramSystem))) (InferedStates InResetMode doc (*) InResetMode (Tolnfer T ) ) ) ( InstanceVariables (ManualScramScramSystem ManualScramScramSystemManua1ScramA0102 doc (• IVadded hy SUARMA)) (ResetScramSystem ResetScramSystemResetA0103 doc (* IV added by SHARMA)) (ManualScram ScramSystemManualScramOoSequenceAllAO104 doc (• IV added by SHARMA)) (Reset ScramSystemResetOoAsManyAOHZ doc (• IV added by SHARMA)) ) ] « [OEFCLASS RP'î (MetaClass SystemPlansMeta Edited: (‘ dds " 6May-86 15:34")) (Supers ComponentPlans) [CiassVariables (SystemName RPS doc (')) (Subsystems (ScramSystem ControlRods) doc (*) ) (Planlibrary (Trip ManualTrip Reset) rioc (‘) ____ (DoAnyOne [(HasOccurrod (Trip RPS)) * *^ (DoAnyOne (ResetIrip RPS if ((limeLapsed (Trip fiPS))> 10 sec)) j (DoSequence (WaitFor I ''Time Lapsed after TripRPS ’ lOsecs") (ResetTrip RPS] (ResetTrip RPS) causing I (InResetMode RPS) toRcsclDo Nothing nofix) ■ Trip I (DoBackUp (Depress " SHUTDOWN Reactor Mode Switch on Panel P 6 RÜ") (ArmandOopress "RPS Manual Scram CM A, 0, C, & 0 pushbuttons") (ArmandOopress "RRCS Manual ARI CM A, and B pushbuttons for RRCS Divisions 1 and 2") toachieve (Opened PilotScramValves) toResotDo (Reset RPS)) doc (* ManualTiip is intended to manually actuate RP5 Trip) ) (InferedStates (Tripped InResetMode ClearedTripLogic) doc (') InResetMode (Tolnfer ((Lighted TripSystom-A White Lights) (Lighted TripSystem-B White Lights) (Closed PilotScramValves) (Closed OackupScramValVOS) (Opened SOVVontValves) (Opened SOVOrainVaIves) (Drained SDV)) ToAchieve (Reset RPS)) Tripped (Tolnfer ((Opened PilotScramValves) (Inserted ControlRods)) ^ ToAchieve (Trip RPS] ^.,^^^^,^byS,fARMA)) [OEFCLASS RRCS (MetaClass SystemPlansMeta Edited; ( dds 24Jun 86 11-33 j) (Supers ComponentPlans) [CiassVariables (Subsystems ARI doc ( )) (Planlibrary (Initiate Reset) ^ (joc (• from Periyiyitemsdeicription on RRCS) Initiate (DoSequenceAII (Initiate ARI) ( flip.FastSpeed RecircPumps) (OoTracking ((RPV.Pressure > 1113 psig) ((TimuLapsed (Initiate RRCS))> 25) (NotDownScalo APRM) • ^ (DoAsMany ( Ini t iato . LFMCi RecircPumps) (Runback FWSystoni))) ((Lovel2 RPV.WatorLovol) • > (Trip.LFMG RecircPumps)) (((OR ((IimoLapsod (RPV.Pressure > 1113 psig) )> 120) ((TimoLapsed (love 12 RPV.WatorLevel))> 120) ((Iimelapsod (Initiate RRCS))> 120) ) (ffotOownScalo APRM)) • > (Isolate nWCU))) toRetetOo (Reset RRCS) ) Reset (DoSequenceAII (ResetTripLogic ARI if ((TimoLapsed (Initiate RRCS))> 30)) (((TimoLapsed (Initiate RRCS))> 120) • > (DoAsMany (ResetRunbackLogic FWSystom) (ResetTripLogic RecircPumps) (RosotlsolationLogic RWCUj ^ o> [OEFCi-ASS Reactor (HetaClass SystemPlansMeta Editod: (‘ dds "tONov-85 ?t 2S )) (Supers ComponentPIans) [ClassVariables (Subsystems (RPV RWCU RocircPumps RPS ACPoworSystem PrimContainmont SecondContainmont SuppressionPool RocircPumps ESF BOP) doc (‘) (PlanLibraty Scram doc (') Scram (DoSequcnccAll (Trip RPS) (PostScram Reactor) tomaintain (Achieved Reactivi tyCntrl))) (InferedStates (Shutdown NotShutdown StartUpModo RUNModo) doc (*) Shutdown (Tolnfer (Reactor.Power < 10) ToAchievc (Scram Reactor)) NotShutdown (Tolnfer ■ (Shutdown Reactor] (InstanceVariables (Scram RoactorScramOoSequencoAl1A0130 doc (• IV added by SH ARMA)))] [DEFCLASS HPCS (MetaOass SystemPlansMeta Edited; (‘dds"7Dec85l5:3f")) (Supers CcmponentPlans) (ClassVariables(Subsystems NIL doc (" Undocumented CV added by SHARMA)) (Ptantibrary (Start Close. InJoctionValve) doc (•) start (DoSequenceAII (Verify "IIPCS Configuration") (Start "HPCS Pumps")) Close.InJoctionValve (Close "HPCS Injection Valves")) (InferedStatos (Required? NotOperating) doc (•) (InstanceVariables (StartHPCS StartHPCSStartA075!l doc (• IVaddedby)) (Close. Inject ionValvetiPCS Close. Inject ionValvoHPCSClose . InjoctionVa1voA0760 doc (‘ IVaddedby)) (Start HPCSStartDoSequoncoAl1A0789 doc (‘ IVaddedby)) l-J (Close. InJoctionValve HPCSCIose. injectionValveCloseA08 « 256 A3 GOAL PLANS [DEFCLASS SuppressionPoolHeatRemoval (MetaClass GoalPtansHeta Edited: (‘dds"7Doca5l5 09")) (Supers Functions) [ClassVariables (SupciFunctlon CoreHoatSinkControl doc f* Undocumented CV added by)) (SubFunction (OryWell TempControi SuppPooiTompControi SuppPoolLovolControl ) doc ( ' Undocumented CV added by) ) (PlanLibrary (ControlActions Achieve) doc (‘ Ref: PeriyCPG) ControlActions (DoScqucnce ((Open SRV) - (Close SRV))) Achieve NIL) (Enter? (SuppPool .Temp > 95 F) doc (* Undocumented CV added by SIIARfdA) ) (InferedStates Achieved doc (') Ach ieved (Tolnfer ( SuppPool Temp <= 110 F ) ToAchievo (Achieve Suppress ionPoolMeat Removal]] [DEFCLASS RPVWaterLevelControl (MetaClass GoalPlansMota Edited: (* ddt "H/un-86 10:3?')) (Supers functions) [ClassVariables (SupeiFunction InventoryControl ) (PlanLibraiy (LimitActions Achieve) doc (* Oef : Oyster Creek) LimitActions [DoAnyOne ((Enter? LossOfAIIfW) -> (Limit LossOfAllFW)) (DoSequence (RunBack Reel rePumps toachiove (Reduce Steamflow)) ((Malfunctioned fWPumpControl1er) • ^ (ManiialControl FWPump) ) ((RoquirodScram? Reactor) - > (ExitTo (limit RuactorScram] Achieve (DoSequence LimitActions toachievc (Achiovod SiiperFunct ion) ) ) (Enter? ((RUNMode Reactor) (Low RPVWaterLevol))) (InferedStates Achieved doc (• Ref: Perry FWPump Trip Procedure) Achieved (Tolnfer ((RPVWatorLovol > 197 in) (RPVWaterLovoI < 205 in)) ToAchieve (Achieve RPVWaterLovo IControl ] [DEFCLASS PrevRadRelease (MetaClass GoalPlansMota Editod: (‘ dds"?8Oct-85?l:0?'')) (Sopors Functions) (ClassVariables (Superfunction NIL doc (‘ UndocumentedCVjddedby)) (Subfunction (MaintCoroIntegrity MaintContainmontIntegrity) doc (“ Undocumented CV added by) ) (Enter? (OR (HighAlarm Off Gas Vont Pipe Rad Monitor) (High Alarm Plant Ventilation Rad Monitor) (High Alarm Turbine Bui Iding/lloator Bay Rad Monitor) (High Alarm Under Drain Manhole Rad Monitor) (Alarm Emorg Service Loop A Rad Monitor) (Alarm Emorg Service Loop B Rad Monitor) (High Alarm RadWasto Effluent to ESW Rad Monitor) (Rad Reading of 1 mr/hr or greater at the sito boundary)) (X doc (* Undocumented CV added by SUARMA) oo ))] [DEFCLASS CorePressureControl (HetaClass GoalPlansMf-ta Edited: (‘dds"220ct-85 15:50")) (Supers Functions) (ClassVariables ( Superl'unction ReactivityCntrl doc (‘ Undocumented CV added by)) (SubFunction NIL doc (‘ Undocumented CV added by)) (PlanLibrary (LimitActions ControlActions Achieve Enter) doc (*) LimitActions [OoAsMany (DoAsMany (RunDack RocircFlow) (Operate UypassValvos) toachievc (Reactor.Pressure < lOZO psig)) (DoMonilor ( ( Roqu i rodScarm Reactor) > (ExitTo (Scarm Reactor] ControlActions [(NotTrippod RPS) • > (OoAnyOne ((FailodClose ProssuroRog) • > (limit PressRogFai ICloso) ) (DoAsMany ((Closed MSIV) -> (DoScqucnce [Decrease Reactor.Power until (OR (((Unisolatod SteamLInes)» 3) (SteamFlow = 10.6 EO Ibs per hr)) (((Unisolated SteamLines)» 2) (SteamFlow ' 7.0 EG lbs per hr] (Open Closed.MSIV))) (Open Closed.MainTurbStopVaIves) (Open Closed.MainTurbControlValVOS] doc (* Ref: Limerick Operational TransientsOriO?) Achieve (DoSequence LimitActions ControlActions tomaintain (Achiovod SuperFunction)) ) (Enter? ((RPVPressure > PressHighEnoughtoInducoRoactivityIncroaso) ^ (CausoOf High RPVPressure Unknown)) K doc (' Undocumented CV added by SHARMA) ))] [DEFCLASS ReactivityCntrl (MetaClass GoalPlansMota Editod: (‘ ddi"2‘1lun 8600:16")) (Supers Functions) (ClassVariables (SuperFunction MaintCoroIntegrity doc (* immediate higher level function to this function) (SubFunction (RCTompControl CoroFlowControl CorePressureControl InsortedReactlvityCntrl) doc (* immediate subfunctions) ) (PlanLibrary (ControlActions LimitActions Achieve) doc (* heuristic knowledge for selecting applicable actions) LimitActions (Scram Reactor) ControlActions [DoTracking ( (Reactor.Power GE 4) (DoBackUp (Initiate ARI) (DoSequence (Runback ReclrcPump.Flow) (Dec.oaso Rec1rcPump.Speed) If (MalnTurb.Status =. OK)) (DoSequence (PostTrIp MalnTurb) (Trip ReclrcPump) If (MalnTurb.Status = Trip)) until (Reactor.Power < 4))) ((Reactor.Power GE 4) (ControlRods.Pos11 ion '= 0) (SuppressionPool. Temp GE 110) • > (DoTogether [DoBackUp (Initiate SLCSystem until ((CentrolRods.Pos it ion = 0 ) or ( SLCSystem.TankLevel IE 28))) (DoSequence (Inject Reactor.Boron) (Stop LowProssECCS.Injection) (Isolate RWCU) until (( ^ Control Rods.Pos11ion =0) o (Reactor.UoronQnty GE 753] (Insort ControIRods))) ((Control Rod s,Pos i tion = 0) • > (PostScram Reactor)) ((ControlRods.Pos i tIon '= 0) ■ > (DoSomethIng If ((SLCSystem.TankLovol LE 28) (Reactor.OoronQnty LE 753] Achieve (DoBackUp LimitActions ControlActions toachievc (Achieved ReactivItyCntrl) tomaintain (Achieved SuperFunction) nof1 a) doc (* plan for operator Achieve) ) (InferedStates Achieved doc (*) Achieved (Tolnfer ((Reactor.Power < 4) (NOT (Increasing Reactor.Power))) ToAchievo (Achieve ReactfvityCntrl))) (Enter? (NOT (Achieved ReactivityCntrl)) doc (* Undocumented CV added by SHARMA) )) (InstanceVariables (ControlActionsReactIvi tyCntrl CentrolActlonsReactlvltyCntrIControlAct IonsAOt66 doc (‘ IV added by SHARMA)) (LimitActlonsReactlvltyCntrl LImitActlonsReactlvltyCntrlLImltActlonsAO167 doc (' IVaddedby SHARMA)) (AchlovoReactlvltyCntrl AchlovoRoactlvltyCntrlAchiovoAOlOB doc § [DEFCLASS InsertedReactivityCntrl (MotaClass GoalPlansMota Editod: C ddi'24lun86 11:31")) (Supers Functions) [ClassVarlablos (SuperFunction RoactlvltyCntrl doc C Undocumented CV added by)) (SubFunction (ControlRodsControl BoronControl Enter) doc C Undocumented CV added by) (PlanLibrary (ControlActions Achieve) doc (*) ControlActions (OoAsMany (Decrease Reactor.Power) (Initiate RRCS)) Achieve (DoSequence ControlActions tomaintain (Achieved SuperFunction))) (InferedStates Achieved doc (') Ach loved (Tolnfer (ControlRods.Pos I tlon = 0) ToAchieve (Achieve InsertedReactIvItyCntrl] [DEFCLASS MaintCorelntegrity (MetaClass GoalPlansMeta Editod: (‘ dds"23Jun-86 23:37")) (Supers Functions) [ClassVariables (SuperFunction ProvRadExposr doc (‘ Undocumented CV added by)) (SubFunction (RoactlvltyCntrl CoreCool IngControl ) doc (‘ Undocumented CV added by) ) (PlanLibrary Achieve doc (• Ref: Percy and Brian) Achieve (DoTogether (ControlActions ReactivityCntrl) (ControlActions InventoryControl) (ControlActions RPVPressureControl ) tomaintain (Achieved SuperFunction) nofIx)) [Enter? (OR (RPV.WaterLevo < 159.3 In) (RPV.Pressure > 103? psIg) (SuppressionPool.Pressure > 1.08 psIg) (Roqu1redlsolatIon MSIV) ((RequlredScram Reactor) (OR (Reactor.Power > 4 % ) (Unknown Reactor.Power] (InferedStates Achieved doc (') Achieved (Tolnfer (NO! (Enter? MaintCoroIntegrity) ) ToAchievo (Achieve MaintCorelntegrity] (InstanceVariables (Achieve Ma IntCorelntegr I tyAch leveDoIogetherAOZG? doc (' IV added by SUARMA)))] [DEFCLASS FWFIowControl (MetaClass GoalPlansMeta Editod: (*dds"l3 Feb-86 11:32")) (Supers Functions) (ClassVariables (SuperFunction FWSupplyControl doc Undocumented CV added by)) (SubFunction FWValvesControl doc (‘ Undocumented CV added by)) (PlanLibrary (Limit ControlActions Achieve) doc (•) Limit (DoSequence ((NotShutdown Reactor) • > (Scram Reactor ) ) (Start ECCS.IliProsslnjoct Ion) (Start PressRollofSystom) ( isolate RPV)) doc (* Ref: Percy) ControlActions [OoAsMany [(OR (NotOsc 11 lat Ing SteamFlow) ((Oscillating SteamFlow) (NotFallod EPR)) • ^ (OoilackUp (ChangoHodo FWControlSystom to SlngleElementMode) (ChangeMode MasterFWControl1er to ManualMode) (ChangeMode FWControIlors to ManualMode) toachievc (Control RPVWaterLevol] (Balance FoedWa torFi-a ins . F low) (Maintain RPV.Waterl.evel toachleve ((RPV.WaterLovol > 155 In) (RPV.WaterLevoI < 165 In] doc (* Ref: Oytter Creek proc for matter controller failure symptoms) Achieve (DoBackUp ControlActions Limit tomaintain (Achiovod SuperFunction))) (Enter? ((FWValves doNotFol low MasterControl 1er) (OR (TranslentFlow FWlralns) ( InstableFlow FWlralns))) doc (‘ Ref: Oyster Creek) w )) [DEFCLASS FWValvesControl (MetaClass GoalPlansMeta Edited: (*ddi"3Feb-86l6 32")) (Supers Functions) (ClassVariables (SuperFunction FWFIowControl doc (• Undocumented CV added by)) (SubFunction NIL doc (• Undocumented CV added by)) (PlanLibrary (ControlActions Achieve Enter) doc (*) ControlActions [DoSequence [DoBackUp (ChangeMode Falled.FWControIlors to ManualMode) (DoSequence (Throttle MoatorBankOutlotValvo toachlovo ((RPV.WaterLovol > 147 In) (RPV.WalorLevol < 171 In)) until (Established local manual control ) ) (LocalControl Fallod.FWControllors) (DoMonltor ((Tripped RPS) • ^ (TrlpFWPump Failed,FWControIlors] (Dalance Flow through FW Trains) (Maintain RPV.WatorLovol toachleve ((RPV.WaterLovol > lollmlt) (RPV.WaterLovol < hlLlmlt] Achieve (DoSequence ControlActions tomaintain (Achieved SuperFunction))) (Enter? ( (High RPV.WaterLevol ) (FWValvo Falls to répond to controller sotpolnt changes) (Flow variation In one FW train opposite In phase to the other trains In service)) doc (* Undocumented CV added by SIIAIIMA) )) $ [DEFCLASS InventoryControl (MetaClass GoalPlansMeta Edited: ddi"2S-Jjn-86 I8:‘t9")) (Supers Functions) I [ClassVariables (SupeiFunction CoreCool ingControl doc I Undo[un\entodCV added by)) (SubFunction (RPVWaterLevelControl FW-StmFlowDalancoControl RCSIntegrityControl ' )l iPross invcnl oryCon tro I ! LoProssInventoryControl) doc (‘ Undocumented CV added by) i • ) (PianLibiaiy (Enter ControlActions Achieve) I doc (') ContioiActions (OoAsMany (DoAsMany ((Required? MSIVIsolation) > j (isolate MSIV)) ' ((Roquiredlsolatio? OOP) i •> ( Isolate OOP)) ((Required? HPCS) • > (DoDackUp ( StarttliPressInj ECCS nofix) ( StartLoPressInj ECCS nofix))) ((Required? LPCS) • ^ (StartLoPressInj ECCS)) (initiate DieselGenerators) ) ((Unknown RPV.WaterLevol) * * > (Flood RPV)) ((ControlRodsPos it ion GT 2) • ^ (PowerControl RPVWaterLevol)) (OoHackUp (OoAsMany (Oporato CondonsateSystcm) (Oporato FWSystom) (Oporato cnoWatorSupply) (Oporato HPCS to (HPCS.DIschPross = 1460 psig)) . (Oporato RCIC) (Oporato LPCI to (LPCI.DischPross = 400 psig)) (Oporato LPCS to (LPCS.OischPross » 500 psig)) toachlovo ((RPV.WatorLovol > 183 in) (RPV.WatorLovol < 218 in))) (Rostoro RPV.WatorLovol) toachievc (Nonia I RPVWatorLovol ) ) ) Achieve (DoSequence ControlActions tomaintain (Achiovod SuporFiinct ion ) ) ) (Enter? (OR (RPVWaterLovo < 177.7 in) (UnKnown RPVWatorLovol)) doc (‘ Undocumented CV added by SUARMA) ) (InferedStates Achiovod doc (*) Achiovod (Tolnfer (Enter? InventoryControl) ToAchievo (Achieve InventoryControl] » [DEFCLASS FWTempControl (MetaClass GoalPlansMeta Editod: (*dc/$ "22 0ct 85/S dA")) (Supers Functions) (ClassVariables (SupeiFunction ReactivityCntrl doc (‘ Undocumented CV .idüed by)) (SubFunction NIL doc Undocumented CV added by)) (PlanLibrary (ControlActions Achieve LimitActions Enter) doc (*) LimitActions (OoScqucnce (Notify PlanHanager) ((Shutdown Reactor) •> (PostScram Reactor)) (Monitor OffGasRoactivity) (Monitor RoactorCoolantActivity) (Monitor HSLRadiation) (Post a note in FWHeaters to seek permission of PlantManager before starting it)) (* ref Oyster Creek Abnormal Operations procedure for t OSS of F W beaters) ControlActions [(NotShutdown Reactor) •> (DoBackUp (Reduce RocircFlow toachlovo (Reactor,Power < 20 % )) (Insert ControIRods toachleve (Power below rod block sotpolnt] (• ref: Oyster Creek Abrwrmal Operations procedure for Loss of FW heaters) Achieve (DoBackUp LimitActions ControlActions tomaintain (Achieved SuperFunction))) (Enter? NIL doc (’ Undocumented CV added by SIIARfelA))) (InstanceVariables (AchievoFWTempControl AchioveFWTompControlAchlQveA0310 doc 3 roEFCLflSS RecircFlowControl (MetaClass GoalPlansMota Editod: (’ ddf"28 0ct-85i1:43‘‘)) (Supers functions) (ClassVariables (SuperFunction CoreflowControl doc (‘ Undocumented CV added by)) (SubFunction NIL doc Undocumented CV added by)) [Planlbrary (ControlActions Achieve Enter) doc (* 8ef: Oyster Creek) ControlActions (OoAnyOne (((NuniberOscillatlng RocircPumps)- 1) • ^ (DoSequence (DoBackUp (ManiialControl Reclrcflow) (ManiialControl RocircPumps if (MalnGon output fluctuations < 15 HWE ) ) (DoSequenceAII (Trip Osc111 atIng.Rec1rcPumps) (FollowOnT rip RocircPumps)) ) (EqualIzo "the flow through the operating recIre loops") (Makelruo "Reactor.Power < RodBlockSetPolnt"))) [((NumborOsclllating RocircPumps)) 1) -> (DoBackUp (DoSequenceAII (ChangeMode Oscillating.RocircPumps to Manual) (ManualControl RocircFlow)) (ManualControl RocircPumps If (MalnGon output fluctuations < 15 MWE)) (DoSequence (Scram Reactor) (Trip Osc11latIng.Rec1rcPumps) (FollowOnTrlp RocircPumps] Achieve (DoSequence ControlActions tomaintain (Achiovod SuperFunction] ( Enter? NIL doc (‘ Undocumented CV added by SUARMA)) )] w oo APPENDIX B. TRACES OF THE PERFORMANCE OF FEPS FOR SAMPLE CASES 269 270 B.1 CASE 1. TRIP OF ALL FW PUMPS 211 5-Jul-86 15:41:08 PROCEDURE SYNTHESIZER IS CONSIDERING Trip FWPumps Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Gosd is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True NOTE: Active Action refers to one of the compound sequence of actions such as a DoSequence or a DoBackUp action Determining Executability of: active action Not Executed Before Generating Procedure for active action Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: active action Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking Goals .272 > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: active action Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING StartMFP Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: Starti'IFP Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > StartMFP is Executable 5-Jul-86 15:41:36 Try Start (MFP) Done?—> y Response is T Checking Goals > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True 273 Determining Executability of: active action Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable Setting a Monitoring Process for condition ((Duration FWFlow < 22 ) > 15 secs)) to follow the following rule IF ((Duration FWFlow < 22 ) > 15 secs)) --> THEN (LowSpeedMode(RecircPumps)) Setting a Monitoring Process for condition ((RPVWaterLevel < 198 in) (OR (Tripped RFPTA) (Tripped RFPTB))) to follow the following rule IF ((RPVWaterLevel < 198 in) (OR (Tripped RFPTA) (Tripped RFPTB))) --> THEN (Close( RecircFlowControl Valves to 48 percent Loop Flow)) Setting a Monitoring Process for condition ((RPVWaterLevel = 178 in)) to follow the following rule IF ((RPVWaterLevel = 178 in)) --> THEN (DoSequence(FWPumpTripLimitScramA1071 FWPumpTripLimitLowSpeedModeA1072 FWPumpTripLimitIsolateA1073)) Checking Goals > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True 274 Determining Executability of: active action Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: active action Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING ReduceRecircFIow to 30 percent Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals Is (Reactor.Power < 20» True? --> n > > Goals are Not True Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of; ReduceRecircFIow to ' 30 percent Not Executed Before Action is Available Checking Preconditions Is (Operating MFP) True? - > y 275 Is (NotOperating RFPA) True?-> y Is (NotOperating RFPB) True?--> y > > Preconditions are True > > ReduceRecircFIow to ' 30 percent is Executable 5-Jui-86 15:42:12 Try Reduce (RecircFlow to ' 30 percent) Done? —> y Response is T Checking Goals Is (Reactor.Power < 20)) True?-> y > > Goals are True Checking Goals > > Goal is Not Specified Checking Goals > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING StartFWPumps Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: StartFWPumps Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > StartFWPumps is Executable 5-JuI-86 15:42:27 Try Start (FWPumps) Done?—> y 276 Response is T Checking Goals > > Goal is Not Specified Checking Goals > > Goal is Not Specified Checking Goals > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: active action Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: active action Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable Setting a Monitoring Process for condition ((RPVWaterLevel < 178 in)) to follow the following rule 277 IF ((RPVWaterLevel < 178 in)) > THEN (ExitTo(Achieve MaintCorelntegrity)) PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: active action Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING CIoseDischValveFWPumps Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: CIoseDischValveFWPumps Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > CloseDischValveF'VPumps is Executable 5-Jui-86 15:42:51 Try CioseDischVaive (FWPumps) Done?—> y 2 7 fi Response is T Checking Goals > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING Close RecircControlValveFWPumps Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: CloseRecircControlValveFWPumps Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > CloseRecircControlValveFWPumos is Executable 5-Jul-86 15:42:58 Try CloseRecircControlValve (FWPumps) Done? — > y Response is T Checking Goals > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING CIoseSuctVaiveFWPumps Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: CIoseSuctVaiveFWPumps 279 Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > CloseSuctValveFWPixmps is Executable 5-Jul-86 15:43:05 Try CloseSuctVaive (FWPumps) Done?—> y Response is T Checking Goals > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING IsolateSealSteamTo F W Pumps Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: IsolateSealSteamToFWPumps Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > IsolateSealSteamToFWPumps is Executable 5-Jul-86 15:43:13 Try IsolateSeaiSteamTo (FWPumps) Done?—> y Response is T Checking Goals > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING Break VacuumAuxCondenser 280 Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal Is Not SpeciSed Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: BreakVacuumAuxCondenser Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > BreakVacuumAuxCondenser is Executable 5-Jul-86 15:43:20 Try BreakVacuum (AuxCondenser) Done?—> y Response is T Checking Goals > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING ShutdownFWPumps Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: ShutdownFWPumps Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > ShutdownFWPumps is Executable 281 ,5-Jul-86 15:43:27 T ry Shutdown (FWPumps) Done?—> y Response is T Checking Goals > > Goal is Not Specified Checking Goals > > Goal is Not Specified Checking Goals > > Goal is Not Specified Checking Goals > > Goal is Not Specified NOTE: Execution o f Procedure Trip FW PUMP Com pleted Successfully 282 B.2 CASE 2. LOSS OF ALL FW B-2-1 Case 2.1. Loss of Ail FW Without Using FEPS 283 5-JuI-86 15:48:53 PROCEDURE SYNTHESIZER IS CONSIDERING Trip FWPumps Checking the Enter Conditions ■ > > Enter Conditions are True Checking Goals > > Go^ is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: active action Not Executed Before Generating Procédure for active action Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable = > NOTE: Active Action refers to one of the compound sequence of actions such as DoSequence or a DoBackUp action. PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: active action Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking Goals > > Goal is Not Specified Checking Exclude Conditions 284 > > Exclude conditions are Not True Determining Executability of: active action Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING StartJVIFP Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: StartMFP Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > StartMFP is Executable 5-JuI-86 15:49:16 Try Start (MFP) Done?—> n Response is NIL PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: active action Not Executed Before Action is Available 285 Checking Preconditions > > Preconditions are True > > active action is Executable Setting a Monitoring Process for condition ((Duration FWFlow < 22 ) > 15 secs)) to follow the following rule IF ((Duration FWFlow < 22 ) > 15 secs)) --> THEN (LowSpeedMode(RecircPumps)) Setting a Monitoring Process for condition ((RP VWaterLevel < 198 in) (OR (Tripped RFPTA) (Tripped RFPTB))) to follow the following rule IF ((RPVWaterLevel < 198 in) (OR (Tripped RFPTA) (Tripped RFPTB))) --> THEN (Close(RecircFlowControlValves to 48 percent Loop Flow)) Setting a Monitoring Process for condition ((RPVWaterLevel = 178 in)) to follow the following rule IF ((RPVWaterLevel = 178 in)) --> THEN (DoSequence(FWPumpTripLimitScramA1071 FWPumpTripLimitLowSpeedModeA1072 FWPumpTripLimitIsolateA1073)) 5-Jul-S8 15:49:28 Invoking Failure Recovery Problem Solving Process (FR) Finding a Procedure to Achieve the Goals of action :active action Goals Not Found Finding Procedure to Maintain the Goals for action active action Maintain Goals Not Found PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified 286 Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: active action Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True DeterminingExecutabilityof: active action Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING ReduceRecireFlow to 30 percent Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals Is (Reactor.Power < 20)) True?-> n > > Goals are Not True Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: ReduceRecircFlow to ' 30 percent Not Executed Before 287 Action is Available Checking Preconditions Is (Operating iVIFP) True?--> n Is (NotOperating RFPA) True?--> y Is (NotOperating RFPB) True?--> y > > Preconditions are Not True ReduceRecircFlow to ' 30 percent is Not Executable > > PE: ReduceRecircFlow to ‘ 30 percent not executable PROCEDURE SYNTHESIZER IS CONSIDERING ReduceRecircFlow to 45 percent Invoking Problem. Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals Is (Reactor.Power < 60)) True?--> n > > Goals are Not True Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: ReduceRecircFlow to ' 45 percent Not Executed Before Action is Available Checking Preconditions Is (Operating One.RFP) True?--> n > > Preconditions are Not True ReduceRecircFlow to ' 45 percent is Not Executable > > PE: ReduceRecircFlow to ' 45 percent not executable PROCEDURE SYNTHESIZER IS CONSIDERING ReduceRecircFlow to 70 percent Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions 288 > > Enter Conditions are True Checking Goals Is (Reactor.Power < 80)) True?--> n > > Goals are Not True Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: ReduceRecircFlow to ' 70 percent Not Executed Before Action is Available Checking Preconditions Is (Operating One.RFP) True?--> n Is (Operating MFP) True?--> n > > Preconditions are Not True ReduceRecircFlow to ' 70 percent is Not Executable > > PE: ReduceRecircFlow to ' 70 percent not executable Action Not Successful 5-Jui-86 15:50:21 Invoking Failure Recovery Problem Solving Process (FR) Finding a Procedure to Achieve the Goals of action lactive action Goals Not Found Finding Procedure to Maintain the Goals for action active action Maintain (jkials Not Found > > PE: Action was not Successful 5-Jul-86 15:50:23 Invoking Failure Recovery Problem Solving Process (FR) Finding a Procedure to Achieve the Goals of action :active action Goals Not Found Finding Procedure to Maintain the Goals for action active action Maintain Goals Not Found 289 5-Jul-86 15:50:26 Invoking Failure Recovery Problem Solving Process (FR) Finding a Procedure to Achieve the Goals of action .-active action Goals Not Found Finding Procedure to Maintain the Goals for action active action Maintain Goals Not Found > > PE: Action was not Successful 5-Jul-86 15:50:28 Invoking Failure Recovery Problem Solving Process (FR) Finding a Procedure to Achieve the Goals of action ractive action. Goals Not Found Finding Procedure to Maintain the Goals for action active action Maintain Goals Not Found = > NOTE: Lacking adequate knowledge the simple computerization of existing procedures (without using FE PS/D PS approach) fails to provide a corrective action. As discussed in Chapter 5, the operator will be asked to enter RPV Control emergency procedure when appropriate preconditions are satisfied. 290 B.2.2 Case 2.2 Method 1. Loss of Ail FW Without Using the Safety Goal Hierarchy 291 5-Jul-86 16:50:10 PROCEDURE SYNTHESIZER IS CONSIDERING Trip FWPumps Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: active action Not Executed Before Generating Procedure for active action Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: active action Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True 292 Determining Executability of: active action Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING StartMFP Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: StartMFP Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > StartMFP is Executable 5-JuI-86 16:50:40 Try Start (MFP) Done?—> n Response is NIL PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of; active action Not Executed Before Action is Available Checking Preconditions > > Preconditions are True 293 ■ > active action is Executable Setting a Monitoring Process for condition ((Duration FWFlow < 22 ) > 15 secs)) to follow the following rule IF ((Duration FWFlow < 22 ) > 15 secs)) > THEN (LowSpeedMode(RecircPumps)) Setting a Monitoring Process for condition ((RPVWaterLevel < 198 in) (OR (Tripped RFPTA) (Tripped RFPTB))) to follow the following rule IF ((RPVWaterLevel < 198 in) (OR (Tripped RFPTA) (Tripped RFPTB))) > THEN (Close(RecircFlowControlValves to 48 percent Loop Flow)) Setting a Monitoring Process for condition ((RPVWaterLevel = 178 in)) to follow the following rule IF ((RPVWaterLevel = 178 in)) --> THEN (DoSequence(FWPumpTripLimitScramA1071 FWPumpTripLimitLowSpeedModeA1072 FWPumpTripLimitIsolateA1073)) 5-Jul-86 16:50:54 Invoking Failure Recovery Problem Solving Process (FR) Finding a Procedure to Achieve the Goals of action :StartMFP Goals Not Found Finding Procedure to Maintain the Goals for action StartMFP Goal To Be maintained is :(Achieved MaintCorelntegrity) = > NOTE: FR has selected the procedure to Maintain Core Integrity as a corrective action to recover from the failure to Start MFW Pump. Maintain Core integrity is now the active action. PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking Goals > Goal is Not Specified 294 Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: active action Not Executed Before Generating Procedure for active action Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING ControIActionsReactivityCntrl Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: ControIActionsReactivityCntrl Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > ControIActionsReactivityCntrl is Executable 5-Jul-86 16:51:14 Try ControIActions (ReactivityCntrl) Done?—> y Response is T Checking Goals > > Goal is Not Specified = > NOTE: PE proceeds with the execution of inventory Control and Pressure Control emergency procedures. 295 B.2.3 Case 2.3 Method 2. Loss of All FW Using the Safety GoalHierarchy 296 5-Jul-S6 22:11:51 PROCEDURE SYNTHESIZER IS CONSIDERING Trip FWPumps Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goad is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: active action Not Executed Before Generating Procedure for active action Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: active action Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True 297 Determining Executability of: active action Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING StartMFP Invoking Problem SolvingProcess Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: StartMFP Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > StartMFP is Executable 5-Jul-86 22:12:17 Try Start (MFP) Done?—> n Response is NIL PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: active action Not Executed Before Action is Available Checking Preconditions > > Preconditions are True 298 > > active action is Executable Setting a Monitoring Process for condition ((Duration FWFlow < 22 ) > 15 secs)) to follow the following rule IF ((Duration FWFlow < 22 ) > 15 secs)) --> THEN (LowSpeedMode(RecircPumps)) Setting a Monitoring Process for condition ((RP VWaterLevel < 195 in) (OR (Tripped RFPTA) (Tripped RFPTB))) to follow the following rule IF ((RPVWaterLevel < 198 in) (OR (Tripped RFPTA) (Tripped RFPTB))) > THEN (Close(RecircFlowControlValves to 48 percent Loop Flow)) Setting a Monitoring Process for condition ((RPVWaterLevel = 178 in)) to follow the following rule IF ((RPVWaterLevel = 178 in)) > THEN (DoSequence(FWPumpTripLimitScramA1071 FWPumpTripLimitLowSpeedModeA1072 FWPumpTripLimitIsolateA1073)) 5-Jul-86 22:12:29 Invoking Failure Recovery Problem Solving Process (FR) Finding a Procedure to Acnieve the Goals of action ;StartMFP Goals Not Found Finding Procedure to Maintain the Goals for action StartMFP Goal To Be maintained is :( Achieved RPVWaterLevelControl) = > NOTE: FR has selected the procedure to Maintain RPVWaterLevelControl to achieve the goal of Achieved RPVWaterLevelControl to recover from the failure o f Start MFW Pump. PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking Goals Is (RPVWaterLevel > 197 in) True? -> n 299 > > Goals are Not True Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: active action Not Executed Before Generating Procedure for active action Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING (LimitActions RPVWaterLevelControl) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: (LimitActions RPVWaterLevelControl) Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > (LimitActions RPVWaterLevelControl) is Executable PROCEDURE SYNTHESIZER IS CONSIDERING LimitLossOfAIIFW Invoking Problem Solving Process Procedure Execution ( PE) Checking the E nter Conditions Is (Tripped FWPumps) True? y Is (Decreasing RPVWaterLevel) True? -> y Is (Decreasing FWFlow) True? --> y Is (Decreasing RxFeed Pumps.RPM) True? -> y 300 > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: LimitLossOfAilFW Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > LimitLossOfAIIFW is Executable 5-Jul-86 22:13.*09 Try Limit (LossOfAIlFW) Done?—> ? Response is Help = > NOTE: On operators request Procedure SYnthesizer will construct and display a detailed procedure for Loss o f All FW. PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determ ining Executability of: active action Not Executed Before Generating Procedure for active action Generating Procedure for (ImmediateActions LossOfAIlFW) Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable 301 PROCEDURE SYNTHESIZER IS CONSIDERING (ImmediateActions LossOfAIlFW) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: (ImmediateActions LossOfAIlFW) Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > (ImmediateActions LossOfAIlFW) is Executable Checking the Enter Conditions Is (Le vel4 RPV. Water Level) True? - > y > > Enter Conditions are True PROCEDURE SYNTHESIZER IS CONSIDERING RunbackRecircPumps Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions Is (LeveI4 RPV.WaterLevel) True? -> y > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: RunbackRecircPumps Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > RunbackRecircPumps is Executable 5-JuI-86 22:13:44 302 Try Runback (RecircPumps) Done?—> y Response is T Checking Goals > > Go^ is Not Specined Checking the Enter Conditions Is (Levels RPV.WaterLevel) True?-*> y > > Enter Conditions are True PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking the Enter Conditions Is (Levels RPV.WaterLevel) True? -> y > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: active action Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING LimitReactorScram Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executabilitj' of: LimitReactorScram Not Executed Before 303 Action is Available Checking Preconditions > > Preconditions are True > > LimitReactorScram is Executable 5-Jul-86 22:14:04 Try Limit (ReactorScram) Done?—> y Response is T Checking Goals > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING TripRecircPumps Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: TripRecircPumps Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > TripRecircPumps is Executable 5-Jul-86 22:14:14 Try Trip (RecircPumps) Done?—> y Response is T Checking Goals > > Goal is Not Specified Checking Goals > > Goal is Not Specified Checking the Enter Conditions Is (LeveI2 RPV.WaterLevel) True? --> y 304 > > Enter Conditions are True PROCEDURE SYNTHESIZER IS CONSIDERING StartHiPressInjECCS Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions Is (Level2 RPV.WaterLevel) True? -> y > > Enter Conditions are True Checking Goals Is (Required? HPCS) True? -> y Is (NotOperating HPCS) True? -> y > > Goals are Not True Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: StartHiPressInjECCS Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > StartHiPressInjECCS is Executable 5-Jul-86 22:14:33 Try StartHiPressInj (ECCS) Done?—> y Response is T Checking Goals Is (Required? HPCS) True? -> y Is (NotOperating HPCS) True? --> n Is (Required? RCIC) True? — > y 305 Is (NotOperating RCIC) True? > n > > Goals are True PROCEDURE SYNTHESIZER IS CONSIDERING StartShutdown.RHR Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions Is (Normal RPV.WaterLevel) True? > y Is (Normal RPV.Pressure) True? y > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: StartShutdown.RHR Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > StartShutdown.RHR is Executable 5-Jul-86 22:14:53 Try Start (Shuidown.RHR) Done?—> y Response is T Checking (]roals > > Goal is Not Specified Checking Goals > > Goal is Not Specified 306 Checking Goals Is (RpVWaterLevel > 197 in) True?--> y Is (RPVWaterLevel < 205 in) True? -> y > > Goafe are True PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: active action Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: active action Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable 307 PROCEDURE SYNTHESIZER IS CONSIDERING ReduceRecircFlow to 30 percent Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions axe True Checking Goals Is (Reactor.Power < 20)) True? --> y > > Goals are True Action not required because goals are already True > > PE; ReduceRecircFlow to ' 30 percent not required Checking Goals > > G o^ is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING StartFWPumps Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of; StartFWPumps Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > StartFWPumps is Executable 5-Jul-86 22:15:29 Try Start(FWPumps) Done?—> y Response is T Checking Goals > > Goal is Not Specified Checking Goals > > Goal is Not Specified Checking Goals > > Goal is Not Specified 308 PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: active action Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: active action Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable Setting a Monitoring Process for condition ((RP VWaterLevel < 178 in)) to follow the following rule IF ((RPVWaterLevel < 178 in)) --> THEN (ExitTo(Achieve MaintCorelntegrity)) PROCEDURE SYNTHESIZER IS CONSIDERING active action Checking Goals > > Goal is Not Specified Checking Exclude Conditions 309 > > Exclude conditions are Not True Determining Executability of; active action Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING CloseDischValveFWPumps Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: CloseDischValveFWPumps Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > CloseDischValveFWPumps is Executable 5-Jul-86 22:15:52 Try'CIoseDischValve (FWPumps) Done?—> y Response is T Checking Goals > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING CloseRecircControiValveFWPumps Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals 310 > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: CloseRecircControlValveFWPumps Not Executed Before Action is Available C decking Preconditions > > Preconditions are True > > CloseRecircControiValveFWPumps is Executable 5-Jul-86 22:16:00 Try CIoseRecircControlValve (FWPumps) Done?—> y Response is T Checking Goals > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING CloseSuctVaiveFWPumps Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: CloseSuctVaiveFWPumps Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > CloseSuctVaiveFWPumps is Executable 5-JuI-86 22:16:07 Try CloseSuctValve (FWPumps) Done? —> y Response is T Checking Goals 311 > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING IsolateSealSteamToFWPumps Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: IsolateSealSteamToFWPumps Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > IsolateSealSteamToFWPumps is Executable 5-Jul-86 22:16:14 Try IsoIateSealSteamTo(FWPumps) Done?—> y Response is T Checking Goals > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING BreakVacuumAuxCondenser Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: BreakVacuumAuxCondenser Not Executed Before Action is Available Checking Preconditions 312 > > Preconditions axe True > > BreakVacuumAuxCondenser is Executable 5-Jul-86 22:16:21 Try BreakVacuum(AuxCondenser) Done?—> y Response is T Checking Goals > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING ShutdownFWPumps Invoking Problem Solving Process Procedure Execution (PE) Checking the Eater Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: ShutdownFWPumps Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > ShutdownFWPumps is Executable 5-Jul<86 22:16:28 Try Shutdown (FWPumps) Done?—> y Response is T Checking Goals > > Goal is Not Specified Checking Goals > > Goal is Not Specified Checking Goals > > Goal is Not Specified Checking Goals > > Goal is Not Specified 313 B.3 CASE 3. LOSS OF ALL FW WITH FAILURE TO SCRAM 314 9-Jul-86 02:34:34 PROCEDURE SYNTHESIZER IS CONSIDERING Limit LossOfAIlFW Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True = > NOTE: In this example traces of active actions (ccmpund actions like DoSeouence) have been removed . PROCEDURE SYNTHESIZER IS CONSIDERING (ImmediateActions LossOfAIlFW) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: (ImmediateActions LossOfAIlFW) Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > (ImmediateActions LossOfAIlFW) is Executable Checking the Enter Conditions Is (Level4 RPV.WaterLevel) True? --> y > > Enter Conditions are True PROCEDURE SYNTHESIZER IS CONSIDERING RunbackRecircPumps Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions Is (Level4 RPV.WaterLevel) True? -> y > > Enter Conditions are True Checking Goals 315 > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: RunbackRecircPumps Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > RunbackRecircPumos is Executable 9-Jui-86 02:35:11 Try Runback (RecircPumps) Done?—> y Response is T Checking Goals > > Goal is Not Specified Checking the Enter Conditions Is (Levels RPV.WaterLevel) True?--> y > > Enter Conditions are True Checking the Enter Conditions = > NOTE: Enter Conditions of subactions Is (Levels RPV.WaterLevel) True? -> y > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are NotTrue PROCEDURE SYNTHESIZER IS CONSIDERING LimitReactorScram Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions 316 > > Exclude conditions are NotTrue Determining Executability of: LimitReactorScram Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > LimitReactorScram is Executable 9-JuI-86 02:35i26 Try Limit (ReactorScram) Done?—> ? = > NOTE: Operator has requested for details on how to execute procedure Limit ReactorScram. Response is Help PROCEDURE SYNTHESIZER IS CONSIDERING Limit ReactorScram Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are NotTrue PROCEDURE SYNTHESIZER IS CONSIDERING Put t he Reactor Mode Switch in SHUTDOWN Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are NotTrue Determining Executability of: Putthe Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > Putthe is Executable 317 9-Jul-86 02:36:05 Try Put (the Reactor Mode Switch in SHUTDOWN) Done? —> y Response is T Checking Goals > > Go^ is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING InsertControlRods Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Is (ControiRods.Position = 0) True? -> n Checking Exclude Conditions > > Exclude conditions are NotTrue Determining Executability of: InsertControlRods Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > InsertControlRods is Executable 9-Jui-86 02:36:19 Try Insert (ControiRods) Done? — > n Response is NIL 9-JuI-86 02:36:26 Invoking Failure Recovery Problem Solving Process (FR) Finding a Procedure to Achieve the Goals of action rInsertControlRods Goals Not Found Finding Procedure to Maintain the Goals for action InsertControlRods Goal To Be maintained is -.(Achieved InsertedReactivityCntrl) PROCEDURE SYNTHESIZER IS CONSIDERING active action = > NOTE: Active action is procedure for Maintaining Insert Reactivity Control 318 Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are NotTrue PROCEDURE SYNTHESIZER IS CONSIDERING (ControlActions InsertedReactivityCntrl) Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: (ControlActions InsertedReactivityCntrl) Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > (ControlActions InsertedReactivityCntrl) is Executable PROCEDURE SYNTHESIZER IS CONSIDERING Decrease Reactor. Power Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Is (Reactor.Power < 4) True? > n Checking Exclude Conditions > > Exclude conditions are NotTrue Determining Executability of: DecreaseReactor.Power Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > DecreaseReactor.Power is Executable 9-Jul-86 02:36:55 Try Decrease (Reactor.Power) Done?—> n Response is NIL 319 PROCEDURE SYNTHESIZER IS CONSIDERING InitiateRRCS Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified • Checking Exclude Conditions > > Exclude conditions are NotTrue Determining Executability of: InitiateRRCS Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > InitiateRRCS is Executable > > PE: Reset Action is Needed Prior to Executing InitiateRRCS > > PE: Searching for the Reset Action Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are NotTrue Determining Executability of: InitiateRRCS Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > InitiateRRCS is Executable PROCEDURE SYNTHESIZER IS CONSIDERING (Reset RRCS) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are NotTrue Determining Executability of: (Reset RRCS) Not Executed Before Generating Procedure for (Reset RRCS) 320 Action is Available Checking Preconditions > > Preconditions are True > > (Reset RRCS) is Executable PROCEDURE SYNTHESIZER IS CONSIDERING ResetTripLogicARI Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are NotTrue Determining Executability of: ResetTripLogicARI Not Executed Before Action is Available Checking Preconditions Is ((TimeLapsed (Initiate RRCS)) > 30) True? > y > > Preconditions are True > > ResetTripLogicARI is Executable 9-JuI-86 02:37:29 Try ResetTripLogic (ARI) Done?—> y Response is T Checking Goals > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING ResetRunbackLogicFWSystem Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are NotTrue Determining Executability of: ResetRunbackLogicFWSystem 321 Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > ResetRunbackLogicFWSystem is Executable 9-Jul-86 02:37:42 Try ResetRunbackLogic (FWSystem) Done? —> y Response is T Checking Goals > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING ResetTripLogicRecirc Pumps Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: ResetTripLogicRecircPumps Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > ResetTripLogicRecircPumps is Executable 9-Jul-86 02:37:50 Try ResetTripLogic(RecircPumps) Done?—> y Response is T Checking Goals > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING ResetlsoIationLogicRWCU Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions 322 > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are NotTrue Determining Executability of: ResetlsoIationLogicRWCU Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > ResetlsoIationLogicRWCU is Executable 9-Jui-86 02:37:57 Try ResetlsolationLogic (RWCU) Done?—> y Response is T Checking Goals > > Goal is Not Specified 9-Jul-86 02:38:03 Try Initiate (RRCS) Done?—> y Response is T Checking Goals > > Goal is Not Specified = > NOTE: Having Successfuly inserted the Control Rods the PE process return to rest of the Limit Reactor Scram procedure. PROCEDURE SYNTHESIZER IS CONSIDERING VerifyCIosed Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are NotTrue 323 Determining Executability of: VerifyCIosed Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > VerifyCIosed is Executable 9-Jul-86 02:38:21 Try Verify (Closed SDV.VentValves) Done?—> y Response is T Checking Goals > > Go^ is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING VerifyCIosed Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are NotTrue Determining Executability of: VerifyCIosed Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > VerifyCIosed is Executable 9-Jui-86 02:38:29 Try Verify (Closed SDV.DrainValves) Done?—> y Response is T Checking Goals > > Goal is Not Specified Checking Goals > > (jroal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING Verify Decreasing 324 Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are NotTrue Determining Executability of: VerifyDecreasing Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > VerifyDecreasing is Executable 9-Jul-8S 02:38:38 Try Verify (Decreasing Reactor.Power) Done? — > y Response is T Checking Goals > > Goal is Not Specified Setting a Monitoring Process for condition ((OR (DurationOf FWFIow < 22 ) > 15sec) (RPV.WaterLevel < 178 in) ((DurationOf DifferentialTemp of SteamDome/RecircPumpSectionLine < 8 F) > 15 sec))) to follow the following rule IF ((OR (DurationOf FWFIow < 22) > 15 sec) (RPV.WaterLevel < 178 in) ((DurationOf DifferentialTemp of SteamDome/RecircPumpSectionLine < 8 F) > 15 sec))) --> THEN (DoSequence(ReactorScramLimitVerifyA0648 ReactorScramLimit Verify A0649)) PROCEDURE SYNTHESIZER IS CONSIDERING Verify Achieved Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals 325 > > Goal is Not Specified CheckingExclude Conditions > > Exclude conditions are Not True Determining Executability of: Verify Achieved Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > VerifyAchieved is Executable 9-Jul-86 02:38:58 T ry Verify (Achieved RPVPressureControl) Done? - > y Response is T Checking Goals > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING MaintainRPVWaterLevel Invoking Problem. Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals Is (RpVW aterLevel = 200 in) True? --> y > > Goals are True Action not required because goals are already True > > PE: MaintainRPVWaterLevel not required Checking (joals > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING AlignFWSystem Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals Is (CondensateSystem) True?--> y > > Goals are True Action not required because goals are already True 326 > > PE; AlignFWSystem not required PROCEDURE SYNTHESIZER IS CONSIDERING MaintainRPV.WacerLevei Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals Is (RPV.W aterLevel < 215 in) T r u e ? -> y > > Coals are True Action not required because goals are already True > > PE: MaintainRPVWaterLevel not required PROCEDURE SYNTHESIZER IS CONSIDERING WaitForCleared Scram Conditions Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: WaitForCleared Scram Conditions Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > WaitForCleared Scram Conditions is Executable 9-JuI-86 02:39:30 Try WaitFor (Cleared Scram Conditions) Done? —> y Response is T Checking Goals > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING ResetRPS Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals 327 > > Goal is Not Specified Is vLighted TripSystem-A White Lights) True? y Is (Lighted TripSystem-B White Lights) True?--> y Is (Closed AllPilotScramVaives) True?-> y Is (Closed BackupScramValves) True?--> y Is (Opened SDVVentVaives) True?--> y Is (OpenedSDVDrainValves) True?—> y Is (Drained SDV) True? > y Action not required because goals are already True > > PE: ResetRPS not required PROCEDURE SYNTHESIZER IS CONSIDERING ResetARI Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: ResetARI Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > ResetARI is Executable 9-Jul-86 02:39:52 Try Reset (ARI) Done?—> y Response is T Checking Goals > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING AlignRecircPumps 328 Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Go^ is Not Specified Checking Exclude Conditions > > Exclude conditions are NotTrue Determining Executability of: AlignRecircPumps Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > AlignRecircPumps is Executable 9-JuI-86 02:40:00 Try Align (RecircPumps) Done?---> y Response is T Checking Goals > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING OperateRWCU Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals Is (RPV.WaterLevel > 193 in) True? -> y Is (RPV.WaterLevel < 215 in) True?--> y > > Goals are True Action not required because goals are already True > > PE: OperateRWCU not required PROCEDURE SYNTHESIZER IS CONSIDERING FolIowPlant Cooldown Procedure Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified 329 Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: FollowPlant Cooldown Procedure Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > FollowPlant Cooldown Procedure is Executable 9-Jul-86 02:40:15 Try Follow (Plant Cooldown Procedure) Done? —> y f Response is T Checking Goals > > Goal is Not Specified = > NOTE: Having successfully executed Limit reactorScram Procedure PE proceeds with the execution of the rest of the Loss of All FW procedure. PROCEDURE SYNTHESIZER IS CONSIDERING TripRecircPumps Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > (joal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: TripRecircPumps Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > TripRecircPumps is Executable 9-Jul-86 02:40:26 Try Trip (RecircPumps) Done? — > y Response is T 330 Checking Goals > > Goal is Not Specified Checking Goals > > Goal is Not Specified Checking tlie Enter Conditions Is (LeveI2 RPV.WaterLevei) True?--> y > > Enter Conditions are True PROCEDURE SYNTHESIZER IS CONSIDERING StartHiPressInjECCS Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions Is (Level2 RPV.WaterLevei) True? — > y > > Enter Conditions are True Checking Goals Is (Required? HPCS) True? -> y Is (NotOperating HPCS) True? -> y > > Goals are Not True Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: StartHiPressInjECCS Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > StartHiPressInjECCS is Executable 9-Jul-86 02:40:47 Try StartHiPressInj (ECCS) Done? —> y Response is T Checking Goals Is (Required? HPCS) True? -> y Is (NotOperating HPCS) True? -> n Is (Required? RCIC) True? -> y 331 Is (NotOperating RCIC) True?--> n > > Goals are True PROCEDURE SYNTHESIZER IS CONSIDERING StartShutdown.RHR Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions Is (Normal RPV.WaterLevei) True? -> y Is (Normal RPV.Pressure) True? -> y > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: StartShutdown.RHR Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > StartShutdown.RHR is Executable 9-Jul-86 02:4Id)2 Try Start (Shutdown.RHR) Done?—> y Response is T Checking Goals > > Goal is Not Specified Checking Goals > > Goal is Not Specified 332 B.4 CASE 4. LOSS-OF ALL FW WITH FAILURE TO TRIP RECIRC PUMPS 333 9-Jul-8602:42:24 PROCEDURE SYNTHESIZER IS CONSIDERING Limit LossOfAllFW Checking üie Enter Conditions > > Enter Conditions are True Checking Goals > > Go^ is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Generating Procedure for (ImmediateActions LossOfAllFW) Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING (ImmediateActions LossOfAllFW) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: (ImmediateActions LossOfAllFW) Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > (ImmediateActions LossOfAllFW) is Executable Checking the Enter Conditions Is (Level4 RPV.WaterLevei) True?--> y > > Enter Conditions are True PROCEDURE SYNTHESIZER IS CONSIDERING RunbackRecircPumps Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions Is (Level4 RPV.WaterLevei) True?--> y 334 > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: RunbackRecircPumps Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > RunbackRecircPumps is Executable 9-Jul-86 02:42:44 Try Runback (RecircPumps) Done?—> y Response is T Checking Goals > > Goal is Not Specified Checking the Enter Conditions Is (Levels RPV.WaterLevei) True? -> y > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True PROCEDURE SYNTHESIZER IS CONSIDERING LimitReactorScram Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: LimitReactorScram Not Executed Before Action is Available Checking Preconditions 335 > > Preconditions are True > > LimitReactorScram is Executable 9-Jul-86 02:42:58 Try Limit (ReactorScram) Done?—> y Response is T Checking Goals > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING TripRecircPumps Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: TripRecircPumps Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > TripRecircPumps is Executable 9-Jul-86 02:43:06 Try Trip (RecircPumps) Done? — > n & Response is NIL 9-Jul-86 02:43:09 Invoking Failure Recovery Problem Solving Process (FR) Finding a Procedure to Achieve the Goals of action :TripRecircPumps Goals Not Found Finding Procedure to Maintain the Goals for action TripRecircPumps Goal To Be maintained is :(Achieved CoreFlowControl) PROCEDURE SYNTHESIZER IS CONSIDERING AchieveReactivityCntrl Invoking Problem Solving Process Procedure Execution (PE) 336 Checking the Enter Conditions > > Enter Conditions are True Checking Goals Is (Reactor.Power < 4) True? -> n > > Goals are Not True Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: AchieveReactivityCntrl Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > AchieveReactivityCntrl is Executable 9-JuI-86 02:43:32 Try Achieve (ReactivityCntrl) Done?---> y Response is T Checking Goals Is (Reactor.Power < 4) True? -> y Is (Increasing Reactor.Power) True? -> n > > Goals are True Checking the Enter Conditions Is (Level2 RPV.WaterLevei) True? -> y > > Enter Conditions are True PROCEDURE SYNTHESIZER IS CONSIDERING StartHiPressInjECCS Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions Is (Level2 RPV.WaterLevei) True? > y > > Enter Conditions are True Checking Goals Is (Required? HPCS) True? -> y Is (NotOperating HPCS) True? --> n Is (Required? RCIC) True? -> y 337 Is (NotOperating RCIC) True?--> n > > Goals are True Action not required because goals are alread y True > > PE: StartHiPressInjECCS not required PROCEDURE SYNTHESIZER IS CONSIDERING StartShutdown.RHR Invoking Problem Solving Process Procedure Execution (PE) Checking the Enter Conditions If (Normal RPV.WaterLevei) True? - > v f Is (Normal RPVJPressure) True? — > y f > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: StartShutdown.RHR Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > StartShutdown.RHR is Executable 9-JuI-86 02:44:14 Try Start (Shutdown.RHR) Done?—> y Response is T Checking Goals > > Goal is Not Specified Checking Goals > > Goal is Not Specified B.5 CASE 5. LOSS OF .ALL FW WITH F.AILURE OF KPCS/RCIC 339 8 X 11 TEdk 9-Jul-86 02^i4:59 PROCEDURE SYNTHESIZER IS CONSIDERING lim it LossOfAllFW Checking' the Enter Conditions > > Enter Conditions are Tr-ue Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True G euerating pTocedure for Çlo lo ediateActions Ij-issOfAllFViT) Action is Available Checking Preconditions > > Preconditions are True > > active action is Executable PROCEDURE SYNTHESIZER IS CONSIDERING (ImmediateActions LossOfAllFW) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: (ImmediateActions LossOfAllFV/) Not Executed Bef'-'TA Action is Available Checking Preconditions > > Preconditions are True > > (ImmediateActions LossOfAllFW) is Executable Checking tiie Enter Conditions 340 8x il TEdit Is (Level4 RPV.WaterLevei) True? --> y > > Enter Conditions are True PROCEDURE SYNTHESIZER IS CONSIDERING RunbackRecircPumps Invoking- Problem Solving- Prooiss Procedure Execution (PE) Checking the Enter Conditions Is (Level4 RPV.WaterLevei) True? -> y > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executabilitj-- of: RunbackPtecircPumps Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > R.UnbackPlecircPumps is Executable 9 .Jul-86 02:45:18 Try Runback (RecircFhimps) Done?—> y Re^'Onse is T Checking Goals > > Goal is Not Specified Checking tlie Enter Conditions Is (Levels RPV.WaterLevei) True? -> y > > Enter Conditions are True 341 8 X 1 i TEdrt Checking' Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True PROCEDURE SYNTHESIZER IS CONSIDERING UiaitReactorScram Invoking Problem Solving Process Procedure Execution i?E) Checking tiie Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of; LimitPLeactorScram Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > LimitReactorScram is Executable 9-Jxd-86 02:45:31 Try Limit (ReactorScram) Doue?—> y Resp'onse is T Checking Goals > > Goal is Not Specil'ied PROCEDURE SYNTHESIZER. IS CONSIDERING TripRecircPumps Invoking Problem Solving Process Procedure Execution (PE) Checking tire Enter Conditions > > Enter Conditions are True 342 «X 11-TEdit Invoking' Problem Solving Process Procedure Execurion (PE) Checking the Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of; LirriitPLeactorScram Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > LimitReactorScram is Executable 9-Jul-86 02:45:31 Try Limit (ReactorScram) Doue?—> y Response is T Checking Goals > > Goal is Not Specit'ird PROCEDURE SYNTHESIZER IS CONSIDERING TripRecircPumps Invoking Problem Solving Process Procedure Execution (PE) Checking tiie Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining E;-:ecutability of; TripRecircPumps 343 8 X i l TEdit Not Executed Before Action is Available Checkinr Preconditions > > Preconditions are True > > Trip FiecircP umps is Executable 9-Jul-86 02:45:37 Try Trip (RecircPumps) Doue? —> y R-esp'onse is T Checking' Coals > > Goal is Not Specified Checking Goals > > Goal is Not Specified Checking tlic Enter Conditions Is (Level2 RPV.WaterLevei) True?~> y > > Enter Conditions are True PROCEDURE SYNTHESIZER. IS CONSIDERING StartHiPressIujECCS Invoking Problem Solving Process Procedure.Execution (PE) Checking tlie Enter Conditions Is (Level2 RPV.WaterLevei) True? > y > > Enter Conditions are True Checking Goals Is (Required? HPCS) True?--> y Is (NotOjieratiug HPCS) True?--> y > > Goals are Not True Checking Exclude Conditions > > Exclude conditions are Not True 344 Determining Executability of: StartHiPressInjECCS Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > StartHiPressInjECCS is Executable 9-Jul-86 02x15:53 Try StartHiPressInj (ECCS) Done? —> n FLes^:ionse is NIL 9-JuI-86 02:45:56 Invoking Failure Recovery Problem Solving Process (FR) Finding a Procedure to Achieve tlie Goals of action :StartHiPresslnjECCS Goal to be A-±iieved is : (Achieved HiPressInventoryControl) PROCEDURE SYNTHESIZER IS CONSIDERING AchievelnventoryControI Invoking Problem Solving Process Procedure Execution (PE) Checking tlie Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining E>:ecutability of: AdiieveInventoryContro 1 Not E:-:ecuted Before Action is Available Checking Preconditions > > Preconditions are True > > AchievelnventoryControl is Executable 345 e x -li TEdit 9-Jui-88 02:46:05 Try Achieve (InventoryControl) Done?*~> ? E-esp'Onse is Help PROCEDURE SYNTHESIZER IS CONSIDERING Achieve Inveutory Control Checking' Goals > > Goal is Not Spooified Checking Exclude Conditions > > E:-:clude conditions are Not True PROCEDURE SYNTHESIZER IS CONSIDERING (ControIActions Inve ntoryControI) Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining E:-:eoutability of: (ContrelActions InventoryControl) Not Executed Before Action is Available Che eking P re co nditio ns > > Preconditions are True > > (ControlActions InventoryControl) is Executable PROCEDURE SYNTHESIZER IS CONSIDERING IsolateMSIV Invoking Problem Solving Process Procedure Execution (PE) Checking tiie Enter Conditions Is (Required? MSIVIsolation) True? > y 346 8 X I tTEdk > > Enter Conditions are Tnic Checking: Goals > > Goal is Not Specified Checking: Exclude Conditions > > Exclude conditions are Not True Determining: E xecutability of; Iso late MSI V Not Executed Before Action is Available Checking: Preconditions > > Preconditions are True > > IsolateMSIV is Executable 9-Jxd-86 02:46.'43 Try Isolate (MSDone?—>y R.esfionse is T Checking Goals > > Goal is Not Specificd PROCEDURE SYNTHESIZER IS CONSIDERING IsolateBOP Invoking Problem Solving Process Procedure Execution (PE) Checking tlie Enter Conditions Is (Re quire dis olatio? BOP) True?—> y > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking: Exclude Conditions > > Exclude conditions are Not True Determining Executability of: IsolateEOP 347 -8_xj11 TEdit Nût Executed Before Action is Available Checking Preconditions > > Preconditions arc True > > IsolateEOP is Executable 9-Jxil-85 02:46:52 Try Isolate (BOP) Done? ~-> y R es^'onse is T Checking Goals > > Goal is Not Specil'ird Checking tlie Enter Conditions Is (Piequired? HPCS) True? -> ,y > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True PROCEDURE SYNTHESIZER IS CONSIDERING StartHiPressInjECCS Invoking Problem Solving Process Procedure Execution (PE) Checking tlie Enter Conditions > > Enter Conditions are True Checking Goals Is (Required? HPCS) True?-> y Is (NotOperating HPCS) True?--> y Checking Exclude Conditions > > Exclude conditions are Not True 348 8 x i l TEdk Detemining’ Executability of: StartHiPressInjECCS Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > StartHiPressInjECCS is Executable 9-Jttl-86 02x17:14 Try StartHiPressInj (ECCS) Done? > n R-es^'Onse is NIL PROCEDURE SYNTHESIZER IS CONSIDERING StartLoPressInjECCS Invoking Problem Solving Process Procedure Execution (PE) Checking tlïc Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is N 0 1 Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of; StartLoPressInjECCS Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > StartLoPressInjECCS is Executable 349 «x11 TEdir 9-Jul-86 02x17:25 Try StartLoPressInj(ECCS) Done?—> ? Resp'onsc is Help PROCEDURE SYNTHESIZER IS CONSIDERING (StartLoPressInj ECCS) Chcoking- Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True De te training; Executability of: (StartLoPressInj ECCS^i Not Executed Before Generatiii;g' Procedure for (StartLoPressInj ECCS) Action is Available Checking; Preconditions > > Preconditions are True > > (StartLoPressInj ECCS) is Executable Checking: the Enter Conditions Is ((RPV.Pressure >400psig)) True? -> y > > Enter Conditions are True Checking: Goals Is (RPV.Pressure < 400%)sig) True?-> n > > Goals are Not True Checking; Exclude Conditions > > Exclude conditions are Not True 350 8 X 11 qFEditl PROCEDURE SYNTHESIZER IS CONSIDERING OperateSRV Invoking' Problem Solving Process Procedure Execution (PE) Che clung the Enter Conditions > > E nter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: OperateSPiV Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > OperateSFlV is Executable 9-J vl1-86 02:48:00 Try Operate (SRVO Done? —> y Ftesp'Onse is T Checking Goals > > Goal is Not Specified Checking Goals Is (RPV.F*ressure < 400psig) True?-> y > > Goals are True Checkin?' Goals Is (RPV.Press\ire < 400psig) True?--> y > > Goals are True 351 S-X 11 TEdit Checking Goals Is (Achieved LoPresslaveutoryCoiitroI) True? > a > > Goals are Not True Checking Exclude Conditions > > Exclude conditions are Not True PROCEDURE SYNTHESIZER IS CONSIDERING StartLPCI Invoking Prcblerri Solving Process Procedure Execution (PE) Checking tlie Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: StartLPCI N 0 1 E xe cute d B efo re Action is A.vailable Checking P re co nditio ns > > Preconditions are True > > StartLPCI is Executable 9-Jul-86 02:48:37 Try Start(LPCI) Doae?—> y Resp'onse is T Checking Goals > > Goal is Not Specified PROCEDURE SYNTHESIZER IS CONSIDERING StartH PCS 352 8 X 11 TEdk Invoking' Problem Solving Process Procedure Execution (PE) Che eking tiie E nte r Co nditio ns > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of; StartH PCS Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > StartHPCS is Executable 9-Jul-86 02:48:44 Tt7 Start (HPCS) Done?—> n Ftesf-onse is NIL PROCEDURE SYNTHESIZER IS CONSIDERING StartLPCS Invoking Problem Solving Process Procedure Execution (PE) Checking tlie Enter Conditions > > E nter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of: StartLPCS Not Executed Before 353 8 TBdit Action is Availablc_ Checking: Preconditions > > Preconditions are True > > StartLPCS is Executable 9-Jul-86 02x18:52 Try Start (LPCS) Done?—> y Resp'onse is T Checking Goals > > Goal is Not Specified Checking Goals Is (Achieved LoPressInventoryControl) True?-> y > > Goals are True Checking Goals > :> Goal is Not Specil'ied PROCEDURE SYNTHESIZER IS CONSIDERING StartLoPressInjECCS Invoking Problem Solving Process Procedure Execution (PE) Checking tljc Enter Conditions Is (R equired? LPCS) True? > y > > Enter Conditions are True Checking Goals > > Go al is N 0 1 Sp e cifie d Checking Exclude Conditions > > Exclude conditions are Not True Determining Executability of; St a rtLo Pre ssl njE C C S Executed Before StartLoPressInjECCS is net repetitive 354 8_x i l TE StartLoPrcssInjECCS b Not Executable > > PE: StartLoPressInjECCS not executable PROCEDURE SYNTHESIZER IS CONSIDERING Initiate Dies clGeuerators Invoking Problem Solving Process Procedure Execution (PE) Checking tlie Enter Conditions > > Enter Conditions are True Checking Goals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determining E:-:ecutability of: InitiateDieselGenerators Not Executed Before Action is Available Checking Preconditions > > Preconditions are True > > InitiateDieselGenerators is Executable 9-JXÜ-86 02:49:20 Try Initiate (DieselGeuerators) Done? — > y Ftesp'onse is T Checking Goals > > Goal is Not Specified Checking Goals > > Goal is Not Specifird PROCEDURE SYNTHESIZER IS CONSIDERING FloodRPV Invoking Problem Solving Process Procedure Execution (PE) Checking tire E nter Conditions 355 8 X -f 1‘ TEdit Is (Uukuowu RPV.WaterLevel) True? ~> a. > > Enter Conditions are Not True Action not required because Enter conditions are not True > > PE: FloodPtPV not required PROCEDURE SYNTHESIZER IS CONSIDERING PowerControIRP\^ aterLevei Invokin:j- Problem Solving Procesj Procedure Execution (PE) Checking tire Enter Conditions Is ((ControIRodsPositioii GT 2)) True? --> n > > Enter Conditions are Not True Action not required because Enter conditions are not True > > PE; Po'-yerCvntroiRPVWaterLeve 1 not required PROCEDURE SYNTHESIZER IS CONSIDERING StartShutdowixRHR Invoking Problem Solving Process Procedure Execution (PE) Checking tire E nter Conditions Is (Normal RPV.WaterLevel) True?-> y Is (Normal RPV. Pres sure) True?-> y > > Enter Conditions are True Checking Coals > > Goal is Not Specified Checking Exclude Conditions > > Exclude conditions are Not True Determ ining E xecutability of: StartSl'iUtdov/n.PwHPl Not Executed Before 356 Action is Available Checliing: Preconditions > > Preconditions are True > > StartSliUtdo'yn.RHR. is Executable 9-Jul-86 02:49:37 Try Start (Shutdown.RHR) Done?—> y R ezp'onse is T Checking: Coals :> > Goal is Not. Specified Checking Goals > > Goal is Not Sjoecified