Application of Logic Alarm Cause Tracking System to Shinhanul 1&2 Nuclear Power Plants

Transcription

1 Application of Logic Alarm Cause Tracking System to Shinhanul 1&2 Nuclear Power Plants Jung Taek Kim 1, Se Woo Chun 1, Jung Woon Lee 1, Jae Chang Park 1, Sang Jung Lee 2, and Sung Pil Lyu 3 1. Instrumentation & Control and Human Factors Research Division, Korea Atomic Energy Research Institute, Daejeon, , Korea (jtkim@kaeri.re.kr) 2. Electronics Engineering Department, Chungnam National University, Daejeon, Korea (eesjl@cnu.ac.kr) 3. Department of Computer, Semyung University, Jecheon, Chungbuk, , Korea (lsp415@semyung.ac.kr) Abstract: After the TMI accident, many alarm reduction systems and diagnostic systems have been studied to reduce nuisance alarms and to detect the causes of an abnormal state. These systems provide an operator with information on significant alarms or causes of an abnormal state for an operator to identify that state. In this paper, an operator-aid system, Logic Alarm Cause Tracking System (LogACTs), is proposed for tracking the logics of an alarm, finding the causes of an alarm, displaying the highlighted alarm procedure related to the causes, and suppressing and filtering nuisance alarms due to the physical or logical connections between components or systems in an abnormal state. The system can be used by an operator to identify the detailed causes of an alarm without checking all the causes of the candidates by alarms. The proposed system will be applied to a Korean Standard Nuclear Power Plant of a PWR, ShinHanul 1&2 Nuclear Power Plant. Keyword: Alarm Cause Tracking, Alarm Processing, Logic Tracking. 1 Introduction A malfunction and failure of components or a mismatch and disturbance between systems cause a lot of nuisance alarms because of physical or logical connections between components and systems. And so many nuisance alarms can lead to a serious human burden for an operator like the TMI accident. After the TMI accident, many alarm reduction systems and diagnostic systems have been studied to reduce nuisance alarms and to detect the causes of an abnormal state. These systems provide an operator with information on significant alarms or causes of an abnormal state for an operator to identify the state. So, most of these studies have focused on high level information like physical or logical states of a failure rather than the state of process signals as detailed causes of an alarm. In light of the need to enhance the plant information to operators, and to improve the technological advances, the advanced operator-aid system research team of the Korea Atomic Energy Research Institute (KAERI) is developing an operator-aid system for an intelligent alarm processing, tracking of alarm cause, and process monitoring and diagnosis of process disturbance [1,2,5,6,7]. All of the degradations and failures of a valve pump and sensor cause a disturbance of a process related to degraded components. Initial indication of such a disturbance will be displayed on an alarm. Our initial effort focused on a process monitoring, alarm suppression and tracking of an alarm root cause. In this paper, an operator-aid system, Logic Alarm Cause Tracking System (LogACTs) is proposed for tracking the logics of an alarm, finding the causes of an alarm, displaying the highlighted alarm procedure related to the causes, and suppressing and filtering nuisance alarms due to the physical or logical connections between components or systems in an abnormal state. The system can be used by an operator to identify the detailed causes of an alarm without checking all the causes of the candidates by alarms. The proposed system will be applied to a Korean Standard Nuclear Power Plant of PWR type reactor, ShinHanul 1&2 Nuclear Power Plant. 2 Alarm Processing Methods This section describes our basic concept and strategy for alarm reduction and alarm suppression on an advanced alarm processing technologies to the generated process alarms. At the outset, we noted the inherent limitation of alarm processing systems that are mostly based on binary information (i.e., alarm on or off), as opposed to diagnostic systems that directly manipulate continuous process measurements [1,5]. Hence, an advances alarm processing systems carry out their inference mostly with information of a lower quality, compared to diagnostic systems. As a result, the function of an alarm processing system should be limited to integrating plant ISOFIC/ISSNP 2014, Jeju, Korea, August 24~28,

2 Jung-Taek Kim, Se-Woo Chun, Jung-Woon Lee, Jae-Chang Park, Sang-Jung Lee and Sung-Pil Lyu information to the system, prioritizing alarm signals based on some methods as discussed below, and providing limited aids to a fault diagnosis. How to process alarms has been studied by many developers of alarm systems [3,4] ; an important issue now is which methods to adopt and how to implement them. In this study, various advanced alarm handling systems have been reviewed.[4,5] The major methods we found to be the most effective, while applying to the ShinHanul 1&2 Unit, include: plant-mode dependency, cause-consequence relationships (sometimes called direct precursor) and multi-setpoint relationship (sometimes called level precursor). 2.1 Plant Mode Dependency Processing Prioritizing alarm messages depending on the operating mode of the plant is another popular method that has been applied in many other annunciator systems. In the mode dependency processing, alarms are processed depending on the global state of the plant, while in the state dependency processing, they are handled depending on the local state of equipment. When the plant changes its operating mode, some equipment correspondingly may change their states. Many alarms are temporarily generated according to a changing operational mode or reactor shutdown. But when the operational mode is changed, several alarms appear and disappear in a minute. These alarms are caused by a temporary process disturbance when some pump or valve is turned on or off in terms of changing the demand of an operational mode. As an example, the following alarms are coalesced into the trip action of the plant: Tavg/Tref Hi/Lo, RCP LTDN HX Outlet Press Hi/Lo, Steam Generator Water Level Deviation High/Low, Steam Generator A Steam/Feedwater Flow Deviation, and NIS High Flux Rate Power Range. Most of these temporary alarms are nuisance alarms that an operator needs not recognize. ADIOS suppresses or filters these nuisance alarms by applying a plant mode dependency processing first whenever it is applicable. The plant-mode dependency processing may be applied depending on some actions of the plant, such as a setback, stepback, safety injection or plant trip, and some relatively stable, operating modes of the plant, such as a hot shutdown or cold shutdown. We need simply to extract those alarms associated with these plant actions or modes, and then, suppress them whenever the actions or modes are recognized in a real time. Although conceptually simple, caution should be exercised in applying it, because the change of plant operating modes, and also the operation of the plant in a certain shutdown mode often results from some failure in the plant. In such a case, some alarms may not behave as expected by the analysts; hence, a thorough analysis of the alarm-mode relationship must be performed using a simulator for its practical implementation. 2.2 Multi-setpoint Relationships Processing Another method adopted in LogACTs is, a multi-setpoint relationship, the implementation of which is straightforward. For instance, the priority of the alarm, Steam Generator A Water Level Low, is lowered when the alarm, Steam Generator A Water Level Low-Low, also is activated. This method has something to do with a signal validation. When the signal of steam generator A is not validated, the operators may place more confidence on the annunciator message if both low and low-low alarms come in, compared to the situation where the low alarm is completely filtered out, leaving only the low-low alarm on. 2.3 Cause-Consequence Relationships Processing Another method that has been applied in LogACTs is a cause-consequence relationship, sometimes called a direct precursor. Here we note confusion in using this term among the developers of advanced alarm handling systems. For instance, the term, cause-consequence relationship, has been popularly used, including in the early computer-based alarm systems for the Oldbury and Wylfa nuclear plants in the U.K., developed about three decades ago. Also this term has been used in the early disturbance analysis systems; e.g., the basic model was called cause-consequence trees. At the outset of this research, we tried to find cause-consequence relationships between (process) alarms, using the well-known technique of a directed graph (or digraph) in the field of process diagnostics. As will be reported elsewhere, however this attempt failed to identify such relationships to the extent widely applicable. Although causality could be readily established between process variables and parameters, we could rarely find such a relationship among alarm signals. Fig. 1 shows a concept of the sequential alarms by the Cause-Consequence Relationships when Feedwater Pump 04P trips by the alarm Feedwater Pump 04P Lube Oil Press LoLo. Several alarms are generated due to a trip of Feedwater Pump 04P. Here, Feedwater Pump 04P Lube Oil Press LoLo becomes a causal alarm 2 ISOFIC/ISSNP 2014, Jeju, Korea, August 24~28, 2014

3 Application of Logic Alarm Cause Tracking System to ShinHanul 1&2 NPPs 3 and the several sequential alarms are the consequential alarms. FWBP 04P Running Oil Press lo(p2) Normal Rx Trip Oil Press lolo(p2) (Caused Alarm) Raw Alarm Mode, Status FWBP 04P Trip(P2) Level Precursor MFWP 01P Trip(P2) Rx PWR>75% RPCS ACTu(P1) Cause-Consequence Here we should mention that the term, cause-consequence relationship, is rather ambiguously used, probably because of a lack of a consensus on the terminology among the developers of alarm systems or man-machine interface systems. In fact, a large part of what others say about the causal relationship can be processed by plant-mode dependency which we believe to be more appropriate terminology. For example, M. Bray et al. say that an electrical bus failure alarm and a low flow alarm for an electricity-driven pump can be processed using a direct-precursor relationship between them. The electrical failure alarm is emphasized because it is a direct precursor of the low flow alarm, while the low flow alarm is de-emphasized, relative to the electrical failure alarm, because the low flow alarm is simply a consequence of the electrical bus failure. 2.4 Interlock Equipment Processing Some alarms are interlinked to plant components. These alarms do not have meanings if the components are out of service. For example, an alarm CEP DISCH HDR PRESS LO has no meaning if the condenser pumps (CEPs) are out of service and can be represented by a composed input alarm CEP TRIP. 2.5 Common Resource Processing Oil Press lo(p2 -P3) (Level Precursor) Oil Press lolo(p2) (Caused Alarm) RPCS ACTu (P1 -P2) (Consequential) MFWP 01P Trip (P2 -P3) (Consequential) FWBP 04P Trip (P2 -P3) (Consequential) Alarm Presentation Fig. 1 Sequential alarms by the Cause-Consequence Relationships There are common resources such as compressed air or electricity to be supplied to plant components. These common resources are supplied in common lines with multiple trains. In case that a malfunction occurs in a common resource supply system, many alarms are activated in relation to the components receiving resources from the common resource supply system. These alarms can be represented by an alarm of the common resource supply system. For example, when many alarms occur due to trips in the air supply system or the electrical supply system, "Air Supply System Train A Trip" or "Electrical Supply System Train B Trip" can be a representative alarm and other alarms can be treated as usual alarms. 2.6 Alarm-Status Separation Processing In some cases, alarms may indicate an automatic activation of plant components. These alarms are classified as status alarms in our alarm processing and displayed separately to other alarms. Operators also expressed that alarm-status separation would be necessary[8]. Not important alarms are also classified separately from causal alarms. Some examples of these are deviation alarms by a malfunction of reluctant sensors or equipment, alarms for a door open or key-unlock related to periodic tests, and minor alarms not affecting power reduction such as one for blocked strainers. 3 Alarm Cause Tracking Methods This section describes our basic methodologies to detect and track a root cause of alarms and abnormal states of Alarm Root Cause Tracking Module(ACT). ACT tracks the root causes of the alarms when generated by a process disturbance as a result of sensor failures or hardware failures. Sensor failures or hardware failures cause a lot of nuisance alarms because of the physical or logical connections between the systems. ACT uses the logical information acquired from the LDs(Logic Diagrams) and ARPs(Alarm Response Procedures) which include a logical relationship between the alarms and the system states. It uses the logical relationships between the object oriented and visualized logics which are constructed from the logic diagrams and alarm response procedures. Fig.2 shows the tracking of an alarm cause when linking the operating state of the related component to the presented alarms or alarm response procedures. As shown in Fig.2, ACT can track the root cause of an alarm by checking the operating condition of the related component. ACT provides an operator with the causes of an alarm, the tracking path from the ISOFIC/ISSNP 2014, Jeju, Korea, August 24~28,

4 Jung-Taek Kim, Se-Woo Chun, Jung-Woon Lee, Jae-Chang Park, Sang-Jung Lee and Sung-Pil Lyu alarm to its causes on logic diagrams, the precedent alarms and the alarm response procedure with the detected causes, related directions and so on. shows a connector with serial no. 1 in the LD ( drawing no. XA02) Moderator Temp AbnormalPL5-1 PZR Press Lo PZR Level Hi PZR Level Lo Fig.3 Class for connection 경보및출력감발원인추적결과표시 CCW Cooling Control Valve xxx-cvxx Close Fig.2 Tracking of alarm cause by linking a logic of the operating state of the related component to the presented alarms or alarm response procedures. 3.1 Representation of LogicElement in LogicDiagram To track alarm causes, LD and ARP are represented by objects. Each object is activated by a message regarding a change of input states and it updates its own state. The connections between objects in LD are made graphically and logically by signal lines but the connection between logic elements in a logic diagram and a sub-item of an ARP are made only logically by an interactive user interface. A connection is used as the path to track the causes of an alarm, and the state of an object is used to choose the paths to the causes. There are various logic elements in LD which are used for the operation of input signals such as the 'and' gate and the 'or' gate, for the connection between logic elements such as a signal line and a drawing connector, and for an abbreviation of the logics. Logic element is represented by an object generated from the class CLogicElement. Logic element has its own ID, description, current state, state-changed time, input/output object pointers and position which includes x, y position, drawing no, and so on. Logic elements are classified into the following three types of classes which are for an operation, for a connection and for an abbreviation of the logics derived from the logic element class. - class for a connection : Drawing connector is used for connecting two objects logically which are too far to connect to each other graphically in the same or a different diagram. Signal line has the same function as a connector, but a signal line is a visible path graphically. The drawing connector in the left side in Fig.3(b) 3.2 Representation of Alarm Response Procedures ARP is represented by a tree which has the sub-items for grouping alarms in a high level of the tree and the sub-items for an alarm in a lower level. Leaf of the tree means a line of the ARP, i.e. a description of a supposed cause, a direction to proper actions for an operator, a supposed result after an alarm and so on. Each node of the tree has its own ID and pointers to the related logic elements, and functions for displaying the ARP with the highlighted causes and related directions. Fig.4 shows an ARP tree which is displayed by the function DisplayDialog() of logic element. The logical connection between a logic element and a sub item of the ARP is made by a check in the checkbox in the right side of Fig.4. The checked sub item is highlighted when the logic element is registered in the cause tree after tracking the alarm causes. Fig.4 Connection for an ARP tree Fig.5 shows the tracking result of an alarm cause when tracking the operating state of the related component to the presented alarms or alarm response procedures. There are the compressed alarm messages collecting the important and causal alarms from the generated alarms, the root cause of causal alarm and the brief alarm information in the left side of window, and all alarm messages generated and the tracking result displayed by logic diagram. 4 ISOFIC/ISSNP 2014, Jeju, Korea, August 24~28, 2014

5 Application of Logic Alarm Cause Tracking System to ShinHanul 1&2 NPPs 5 Fig.5 Tracking result of alarm cause by tracking the operating state of the related components 4 Alarm Analysis Sheet for LogACTs In order to apply the above alarm processing methods, a careful analysis of alarms become critical in the development of computerized alarm systems. All alarms of the NPPs, to which our alarm systems may be applied, were analyzed by using the alarm signal information, the alarm procedures, the abnormal and emergency operation procedures, the control logic drawings, and the plant process drawings. Information related to alarm signals, alarm processing, alarm causes, alarm classification, and so on, can be filled after the analysis. The results are stored in a database. Hence a database management program can handle them easily to perform the alarm processing. Fig.6 Alarm analysis sheet for the LogACTs Fig.6 shows the standard sheet of the alarm analysis for development of alarm processing algorithm. The cause-consequential relationships between all alarms and whole alarm response procedures and messages were analyzed to find out causal alarms and track the root cause of alarms. Alarm analysis sheet is directly connected with algorithms for the alarm processing, so is automatically processed by algorithms as put the analyzed data into the analysis sheet, which is DB. The several alarm processing techniques are used to LogACTs such as alarm mode, level precursor, causal alarms, consequential alarms, interlock equipment, common resources, etc. For example, if a cause-consequence relationship between any alarm and another alarm exists, the causal-consequential alarm of the left side table in this sheet is just added and removed. A result of the analyzed data related to the causal alarm is collected and added from list of alarm and operation status of equipment within the analysis sheet for alarm processing, so is automatically processed by algorithms. Component operation status of the cause-related component for finding out the root cause of the selected causal alarms is automatically checked and tracked within the analysis sheet connected with algorithms. Therefore, many alarms avalanched by the abnormal operation situation are automatically suppressed and filtered by alarm processing algorithms such as mode dependency processing, cause-consequential relationship, level precursor relationship, and not-important alarm. The upset condition for reduction and suppression of the nuisance alarms is checked, and so the nuisance alarms will be suppressed in this abnormal condition. 5 Configuration for LogACTs 5.1 Hardware Configuration of LogACTs LogACTs can have separately been configured from an alarm server in Information Processing System(IPS) or integrated with a sub-program module of an alarm server in Information Processing System(IPS). Signals entered into the LogACTs for processing and tracking cause of alarms are gathered from the duel Information Networks belonging to IPS. LogACTs consists of duel processing Server and several Clients, and also includes LogACTs Engineering Workstations (EWS). Fig.7 shows the hardware configuration of the LogACTs. ISOFIC/ISSNP 2014, Jeju, Korea, August 24~28,

6 Jung-Taek Kim, Se-Woo Chun, Jung-Woon Lee, Jae-Chang Park, Sang-Jung Lee and Sung-Pil Lyu Fig.7 Hardware Configuration of the LogACTs Software of the LogACTs will be modulated to the software modules. There are three major modules which are LogACTs Server Module for data collecting from DCC, alarm processing to suppress and filter the temporary and nuisance alarms and tracking of alarm cause, LogACTs Web Client Module for accessing from Web-environment, and LogACTs Client Module for display compressed alarm message list, alarm message list, alarm cause, alarm information, and so on. Figure 4 shows the software configuration of the LogACTs Software Configuration of LogACTs Software configuration of the LogACTs is to be modulated according to each function of the software modules. There are four major modules which are for alarm suppression and filtering, for a link and DB of an alarm and an alarm cause tracking, tracking engine of an alarm cause tracking, and for confirming an alarm cause tracking and displaying a parameter and state of an alarm cause tracking. Fig.8 shows the software configuration of the LogACTs. carries out the functions listed above. Windows matching with the functions are listed as follows; a compressed alarm message window for 1) the causal alarm list compressed from whole alarm list, a whole alarm message window for 2) a full list of alarm messages (also for 3) alarm messages sorted by the priorities or the system groups, and status or program alarms, depending on user selection, an alarm information window for 4) an alarm message selected from the windows displaying alarm messages, an alarm cause window for 5) the causes of alarms in a compressed alarm message window, a cause-tracking logic diagram window for 6) computerized logic diagrams showing causes tracked through the alarm logic diagrams, an AOP entry condition window for 7) AOP entry condition checks, an AOP mimic diagram window for 8) monitoring plant status during AOP execution, an EOP entry condition window for 9) EOP entry condition checks, and an alarm history window for 10) retrieval and presentation of alarm message history. LogACTs windows are classified into main windows or pop-up windows as shown in Fig.9. Together with these windows, several buttons and pull-down menus are composed as controls that lead users to desired information on the LogACTs display. Fig.8 Software Configuration of the LogACTs 5.3 Display Windows of LogACTs Many windows are devised for displaying information being generated when LogACTs Fig.9 LogACTs display structure Fig.10 shows an alarm display window of the LogACTs alarm display windows. This alarm display windows is a part of IPS Alarm Display System in advanced control room design of the APR 1400, Korean Standard Nuclear Power Plants. As shown in Fig.10, a frame of main alarm display windows is adopted from of IPS Alarm Display System to maintain a design consistence of alarm display and prevent operation confusion. This represents a causal alarm message list of LogACTs which is compressed from a full list of alarm messages. So the root cause of the causal alarms will be located to the bottom of this display window. The menu arranged for information processing systems(ips) is located to the top of this display 6 ISOFIC/ISSNP 2014, Jeju, Korea, August 24~28, 2014

7 Application of Logic Alarm Cause Tracking System to ShinHanul 1&2 NPPs 7 window. The left side of menu section is for the other alarm display pages. LogACTS checks whether the entry conditions of the abnormal operation procedures (AOPs) or the emergency operation procedures (EOPs) are met or not. Fig.11 shows a pop-up display window of the AOP entry condition of the LogACTs alarm display windows. LogACTs continually checks to see if AOP or EOP entry conditions are met. If a set of entry conditions is met, a window displaying the corresponding AOP or EOP title together with the marked entry conditions pops-up automatically. causes by alarms. The proposed system will be applied to a Korean Standard Nuclear Power Plant of PWR type reactor, ShinHanul 1&2 Nuclear Power Plant. Acknowledgement This work is supported by the Nuclear Research & Development of the Korea Institute of Energy Technology Evaluation and Planning grant funded by the Korean Government of the Ministry of Trade, Industry & Energy. Fig.10 An alarm display windows of LogACTs alarm display windows. Fig.11 A Pop-up alarm display windows of AOP entry condition 6 Conclusions In light of the need to enhance the plant information to operators, and of the technological advances, an advanced alarm processing and alarm cause tracking system has been developing. It tracks the logics of an alarm, finds the causes of an alarm, displays the highlighted alarm procedure related to the causes, and suppresses and filters nuisance alarms due to the physical or logical connections between components or systems in an abnormal state. The system can be used by an operator to identify the detailed causes of an alarm without checking all the References [1] Jung Taek Kim, et. al, An Evaluation Approach for Alarm Processing Improvement, IAEA Specialists Meeting (IWG-NPPCI) on Experience and Improvements in Advanced Alarm Annunciation Systems in Nuclear Power Plants, Chalk River, Ontario, Canada, [2] Sung P. Lyu, An Identification of Alarm Cause by Tracking Logic Diagram, 2002 Spring Conference, Korea Nuclear Society, May 2002 [3] I.S. Kim, Computerized Systems for On-Line Management of Failures: A State-of-the-Art Discussion of Alarm Systems and Diagnostic Systems Applied in the Nuclear Industry, Reliability Engineering and System Safety, 44 (1994) [4] L.R. Lupton, P.A. Lapointe and K.Q. Guo, "Survey of International Developments in Alarm Processing and Presentation Techniques", NEA/IAEA International Symposium on Nuclear Power Plant Instrumentation and Control, Tokyo, Japan, May 18-22, [5] I.K. Hwang et. al, An Object-Oriented implementation to improve Annunciation IAEA Specialists Meeting(IWG-NPPCI) on Experience and Improvements in Advanced Alarm Annunciation Systems in Nuclear Power Plants, Chalk River, Ontario, Canada, [6] J. T. Kim, et al, An Analysis of the Causal Alarm in Alarm and Diagnosis-Integrated Operator Support System(ADIOS), MARCON97, Knoxville, Tennessee, USA, [7] J.T. Kim, Y.K. Kang, H.C. Shin, B.J. Kim, J.W. Lee, S.J. Lee, and S.P. Lyu, An Application on Alarm Root Cause Tracking System(ACTs), Joint 8th Annual IEEE Conference on HFPP and 13th Annual Workshop on HPRCT, pp , 2007 [8] Emilie Roth and John O'Hara, Integrating Digital and Conventional Human-System Interfaces: Lessons Learned from a Control Room Modernization Program, NUREG/CR -6749, U.S. Nuclear Regulatory Commission, Washington, DC, 2002 ISOFIC/ISSNP 2014, Jeju, Korea, August 24~28,