Design of a Nuclear Power Plant Supervisory Control

Design of a Nuclear Power Plant Supervisory Control System Eduardo de Carvalho, Rodney A. Rixey, Jeffrey P. Shepley, José Orlando Gomes, and Stephanie Guerlain, Senior Member, IEEE

process where ultimate decision execution lies with the operators. Thus it is important to provide the best possible decision support through effective supervisory control interfaces. We observed an existing operational nuclear power plant simulator and noted several deficiencies. An interface redesign prototype was constructed in PowerPoint as an alternative to the current simulator and hardcopy procedure manuals. The design improves upon the graphical layout of system information and provides better integration of procedures, automation, and alarm systems. The design was validated by expert opinion and a scenario-based comparison. Future implementation and testing of the redesign is suggested for further validation.

During 30 hours of observations, we learned how the operators interacted with the simulated PWR in various states of operation. We paid particular attention to the tasks dictated by the procedure manual and to the operators’ actual activity. Noting deficiencies in supporting operators’ tasks, we developed a prototype operator interface that improves upon the graphical layout of system information, the navigation across screens, the alarm presentation, and adds computer-based procedures that dynamically update and correspond with real-time system information. We evaluated the prototype using heuristic techniques and a scenario-based performance comparison using the original design as a performance benchmark.

I. INTRODUCTION

II. MOTIVATION

power plant (NPP) control room operators observe and manipulate an extremely complex system. In the past, this required walking along a large control panel, taking readings from gauges and adjusting knobs and levers. Many of today’s control rooms have replaced or augmented these more traditional control panels with visual display units (VDUs). The Laboratório de Interfaces Homem/Sistema (Human/System Interface Laboratory or LABIHS) a department of the Nuclear Engineering Institute (IEN) in Rio de Janeiro, Brazil, is testing a NPP control room simulator consisting solely of VDUs. The simulator was provided to them through a partnership with the Korean Atomic Energy Research Institute. It represents a three-loop, 930 MW Westinghouse Pressurized Water Reactor (PWR), with simulation logic developed by VTT Energy (Finland). In its present form, the simulator allows the operators to perform many functions required in the operation of a PWR in a real NPP. LABIHS’s goal is to use the simulator to train operators and explore advanced operator interface concepts.

Operational failure at a NPP can lead to catastrophic consequences. NPP incidents and “near misses” occur at a rate of about 80 per year [1]. While typical consequences only lead to decreased efficiency and revenues, accidents such as at the infamous Three Mile Island and Chernobyl reactors pose a threat to public safety. Effective and resilient control of NPPs is essential for their continued safe operation. Although a NPP is a complex system with many potential latent failures, one particularly important component is the human-machine interface. In fact, a Nuclear Regulatory Commission official claims “upwards of 65% of commercial nuclear system failures involve human error” [2]. LABIHS conducts research on human-system interaction in the nuclear power domain. Its goal is to improve user interface support for operator tasks, with the intention of promoting safer and more efficient NPP operation. Partnering with LABIHS provided us with an outstanding opportunity to investigate the nature of operator-system interaction and to contribute to operational safety and efficiency through enhanced decision-support system design.

Abstract— Nuclear power production is a safety-critical

N

UCLEAR

Manuscript received April 14, 2006. This work was supported in part by grants from the Coordenação de Aperfeiçoamento de Pessoal de Nível Superior and the Fund for the Improvement of Postsecondary Education. E. Carvalho is with the Federal University of Rio de Janeiro, Rio de Janeiro, Brazil. (e-mail: [email protected]). R. A. Rixey is with the University of Virginia, Charlottesville, VA 22904 USA (e-mail: [email protected]). J. P. Shepley is with the University of Virginia, Charlottesville, VA 22904 USA (e-mail: [email protected]). J. Gomes is with the Industrial Engineering Department, Federal University of Rio de Janeiro, RJ, Brazil (e-mail: [email protected] ). S. Guerlain is with the Systems and Information Engineering Department, University of Virginia, Charlottesville, VA 22904-4747 USA (corresponding author; e-mail: [email protected])

III. METHODS A. Interviews and Observations i. Focusing Observation: Decomposing Operations of the Complex System The simulator encompasses all of the essential subsystems of a nuclear power plant, enabling the simulation of

a wide range of use-case scenarios. Operations of a nuclear power plant fall under 4 basic phases: 1. Startup 2. Normal Operation 3. Incidents/Accidents/Trips 4. Shutdown Although important events occur in all categories of operations, our limited timeframe required that we focus on periods of higher activity. After discussion with the operators, we learned that the tartup phase induces the most activity, providing the best opportunity to build familiarity with the system. After observing startup simulations we observed several simulated incidents and accidents. We did not study the shutdown phase in depth due to time limitations and its similarity to startup. The startup phase can be further sub-divided into four steps. Although these steps are not an inherent part of the physical system, they are clearly present in the minds of the operators and are reflected in the procedures, and thus constitute an important cognitive division of the system as a whole: 1. Cold Shutdown to Hot Shutdown 2. Hot Shutdown to Hot Standby 3. Hot Standby to 2% Power (“Plant Startup”) 4. Operations greater than 2% Power These subcategories provided a structure for observing the operations of the simulated plant. ii. Observation Methodology The simulator is equipped with a ceiling-mounted camera which captures the majority of the room, including the two operators’ stations and the main presentation screen (fig. 1). We also used a tripod-mounted Mini-DV camcorder to record whichever operator would be likely to have the most active role during a given simulation. We also occasionally employed a hand-held digital camera to film particular details of interest that were not sufficiently captured by the other two cameras.

Fig. 1. Simulator Control Room.

The research team was divided to pair up with the employees of the simulator. Rixey accompanied the primary operator; Shepley accompanied the secondary operator; and Carvalho accompanied the simulator supervisor. However, in many of the cases, the operators conducted the simulations without the supervisor present. In these cases, Carvalho observed the overall proceedings and attempted to capture the communications and interactions between the two operators using his native command of Portuguese. During the startup phase observations, we encouraged the operators to verbalize their goals, actions, and concerns to improve our understanding of the technical system. However, during the simulated accidents, we tried not to interfere with the operators so as to elicit true response behavior. During the simulated accidents, the supervisor, as well as two senior LABIHS researchers were also present. This placed noticeably increased pressure on the operators, and also led them to justify their actions verbally after the scenario was completed. B. Heuristic Evaluation of LABIHS Interface Based on our observations we performed a heuristic evaluation of the LABIHS simulator. Our evaluation focused on the level of support for operator tasks. We organized the interface’s shortcomings into the three thematic categories detailed below. i. Graphic Design Flaws Figure 2 shows a typical control screen for one subsystem of the plant, in this case, the Chemical and Volume Control System (CVCS). Multiple objects with bright, contrasting colors compete for the operator’s attention on the cluttered screen. In many places in the interface, red is associated with a state of alarm or failure. However, this association is undermined by the red color of some valves, pumps, and indicators which are operating normally. Additionally, the red components are highly salient, even when they do not require the operators’ attention. Excessive labels contribute to clutter. For example, the blue RCP Seal information box displays the same variables for each of the three RCP seals, but uses nine labels – one for each variable display field. It increases the visual distance between readouts, making comparisons of the values difficult. The high salience of the large pump icons detracts from the operator’s ability to perceive other elements on the screen. They are not frequently manipulated and they only display two pump states (on and off). The sharp contrast between the white lines representing the pipes which connect system elements and the black background contributes to the clutter of the screen without providing much information. The white-on-black color scheme is also used for pump and valve labels, as well as the system variable values. The similarity in color detracts from the salience of these labels and values.

The lack of distinction between pipes with and without flow does not contribute to the principle of pictorial realism, i.e., that a visual representation should accurately symbolize the entity it is intended to represent [3]. To determine the path of coolant, operators must trace the white line representing the pipe, noting the sequence of valves and pumps through which the line passes to ensure that all are open or on, respectively. While the on/off color distinction is clear, there is no redundant indicator of a valve’s state, nor does the interface support the synthesis of individual valve states into an overall depiction of flow; each valve must be independently analyzed, increasing the operator’s cognitive load. Label legibility is poor due to all-capital text. This also increases the label’s space requirement without providing additional information. Also, the shine used to produce the 3D graphical effects for the tanks and reactor core decreases contrast and reduces legibility for the white labels that overlay these graphics.

Fig. 2. Simulator Interface Screen with Red Alarm Set Indicator

ii. Alarms When an abnormal system state occurs, the simulator initiates an audible alarm, as well as a flashing red “Alarm Set” indicator at the top right corner of the screen (fig. 2). The alarms are located on two separate alarm screens. They are arranged as tiles in grid where active alarms are indicated by a flashing red tile. The existing system does not support quick alarm identification. The alarm set indicator does not provide any detailed information about the nature of the alarm which is sounding. The operator must always navigate to both alarm screens to determine which alarms were activated. Additionally, the grid arrangement has no apparent organization or order. Related alarms are not grouped on the screen nor are alarms divided logically across the two alarm screens. Finally, all alarms are displayed identically, making it difficult to distinguish between alarms on the

basis of severity and importance. All alarms are annunciated by the same sound. iii. Procedures Procedures guide the operators as they face unfamiliar situations. The simulator uses hardcopy procedure manuals in the form of one-dimensional checklists and step-by-step guides. Non-compliance with procedures was observed frequently. Operators often improvised around the formal procedures to achieve their system goals, which in some cases enhances system safety [4]. We observed one operator using a hand-written sheet to aid him through various procedures. The procedures were often constraint-based, requiring the operator to maintain multiple system variables within a specified range. The current interface does not support this task. Instead, it relies on the operator’s cognitive ability to monitor system variables and recall acceptable ranges which change frequently during operation. For example, one procedure requires the operator to locate two variables, manually calculate the difference, and judge whether the difference exceeds a safe upper bound which depends on the current mode of operation. Finally, the layout of data in the simulator is inadequate for perceiving and comparing the rate at which a variable of interest is arriving at its limit. C. Study Limitations All of the observations were conducted on a compact simulator used largely to train operators. While the simulator does simulate all major NPP subsystems, it lacks some details which may affect operations in a real plant environment; therefore, operator actions may differ from actions in a real plant. In a real-plant situation, there are many interactions with the physical system, operators on the floor, the chemical department, management, and other stakeholders which are not fully represented in the simulator. Many operations were observed without the presence of the supervisor, leaving only two operators due to staffing constraints; however, because the supervisor is largely responsible for managing the complexity of the above mentioned components which are not modeled in the simulator, his absence was not detrimental to the operations; his other roles were carried out by the two operators. IV. NEW INTERFACE PROTOTYPE The redesigned interface is based on the deficiencies noted in the previous section. They include improved aesthetics and mock-up designs of new functionality. While we have not coded the components into the simulator software, we do not expect significant compatibility problems. The components consist of borders, text boxes, and colors – all of which are supported by the simulator’s graphics builder software (ILOG). The component functionality is also expected to be compatible, as it largely

mimics functions (such as linking, highlighting, and displaying real-time system variable values) observed in the original simulator. A. Graphic Design Improvements We propose several changes to the schematic-based control screens (for example, see fig. 3). These aim to improve operator situational awareness, and reduce the likelihood of human error. We remedied the overload of red icons by updating the valve and pump color scheme. Grey is used to reduce salience of closed valves and pumps which are off. Redundant coding is provided by rotating closed valves perpendicular to the pipe, while open valves remain parallel. The size of the pump icons is reduced. While still easy to locate, the off pumps and closed valves do not attract unnecessary attention from a broad overview. The frequently manipulated variable-flow valves remain unchanged, providing distinction that helps the operator to quickly locate them. We also simplified the controls for the green “Makeup Mode” control box in the center of the screen. The circular indicators now serve as buttons as well as indicators, obviating the need for the grey buttons. Also, now only the indicator showing the current mode is lit green. The other indicators which were previously red are toned down to black, so that they do not distract the operator. The RCP seal information box has also been simplified to bring the variable displays into closer visual proximity, and excessive labels have been removed to decrease clutter. The pipes have been re-colored to decrease the salience of those pipes with no coolant flow and to emphasize the pipes with flow. Pipes with coolant flow are bolded and shaded the same color green as the switched-on pumps and open valves. As a result, the emergent feature is a green circuit where there is flow of reactor coolant. The pipes with no flow have been subdued from white to grey so that they will not interfere with the reading of labels and variables.

0:08 CHARGING FLOW CONT FLOW LOW

Main Menu

Plant Overvw

C–P Status

Alarm

ROD

RHR

RCS

CVCS

FWS

Cond.

Reactvty

Elec.

Fig. 3. Improved Simulator Interface Screen (CVCS) with CFL alarm.

Issues with the legibility of labels were addressed by using mixed-case fonts which use less space and provide redundant coding of written information: the shape of the words provides another cue for recognition, aside from the sequence of the letters. To further aid legibility, the 3D graphical tanks, pressurizer, and reactor core were replaced with simpler, flat representations. This allows for increased legibility of the labels, as well as the inclusion of a graphical indicator for the fluid level in the Volume Control Tank (VCT), Pressurizer (Prz), and Reactor Core. The graphical indicator does not require much visual space on the screen, and provides the operator with redundant information on the fluid level of the component. Understanding the context of a reactor core coolant level of 6.5 meters, for example, is aided by the blue bar showing the level of fluid relative to full (top) and empty (bottom) states. B. Alarm System Improvements The prototype includes an extensive revision of the original alarm system. The major changes are captured in the revised alarm screen (fig. 4). The alarms have been divided into two panels within the same screen, distinguishing reactor and turbine trip alarms from all others. Within each panel the alarms are organized by the location of their activator in the system. For example, the charging flow indicator is located on the CVCS screen and hence, on the alarm screen, it is under the CVCS column heading. Each alarm tile is a dynamic interface component. This reduces the required number of alarm tiles, allowing all of them to fit on one screen. Instead of a button each for pressurizer pressure high and pressurizer pressure low, the redesign simply uses pressurizer pressure. Depending on the alarm (high or low), the alarm tile displays the appropriate text. Each sounding alarm tile also keeps track of how many seconds since the alarm was set off using a small counter in the upper-left corner of the tile. The trend graphs on the alarm screen saves time and provides better diagnostic information. The acknowledging system has also been improved to allow single-alarm acknowledgement by clicking on a sounding alarm tile. Each alarm tile acts as a link; clicking the sounding alarm tile navigates to the appropriate screen. On the relevant screen, a red box flashes several times, drawing attention to the area triggering the alarm (fig. 3). Additionally, the alarms relating to the current screen are displayed in chronological order of occurrence as red tiles to the right of the schematic diagram. Clicking on these tiles flashes the red box several times around the area of concern. The navigation buttons have been revised to provide easier access to all the operations screens. While the system is in an alarm state, the related navigation buttons at the bottom of the screen are displayed in red, effectively doubling as an

alarm overview. Clicking on the red alarm button navigates to the alarm screen (fig. 4). ALARM Rod Control MANUAL RCT TRIP

Reactivity

PWR RANGE HI FL UX PWR RANGE HI FLUX RATE RCT TRIP HI SETPT RCT TRIP

SOURCE RANGE HI PWR RANGE HI FL UX FLUX RCT TRIP LO SETPT RCT TRIP

INTMD RANGE HI FLUX RCT TRIP

OT∆ T RCT TRIP

CTMT PRESS HI SI RCT TRIP

CTMT SPRAY ACTUATED

PRZ CONT LEVEL HEATER

OP∆ P RCT TRIP

Rod Control

RHR

CONT BANK L O-LO CCWS OUTLET TEMP CT MT SUMP L EVEL LIMIT HI

POWER RANGE OVERPOWER ROD STOP

T WO OR MORE ROD AT BOTT ON

Reset RESET

RCS

FWS

RCS FLOW L O AT HI PWR RCT TRIP

PRZ HI PRESS RCT T RIP

PRZ LO PRESS & P-7 SG 1,2,3 WTR LEVEL TBN OVERSPEED HI RCT TRIP LO-LO RCT TRIP TBN TRIP

RCS F LOW L O AT LO PWR RCT TRIP

PRZ HI L EVEL RCT T RIP

RCS

INTMD RANGE HI FL UX ROD ST OP

INSTRUMENT AIR PRESS LO

Ack

RHR

MANUAL SI RCT TRIP

MS/TS

SG 1,2,3 WTR LEVEL MSL PRESS LO ISO HI-HI T BN TRIP SI RCT TRIP

TBN T RIP & P-7 RCT TRIP

FWS

Condenser

CVCS PRZ PRESS

Condenser CONDENSER VACCUM L O TBN TRIP

TBN TRIP P-4

L/D HX OUTL ET FLOW

RCP SEAL INJ WTR F LOW LO

FW PUMP CONDENSATE SG 1,2,3 LEVEL LO DISCHARGE HEATER STORAGE T K L EVEL PRESS HI

RWST L EVEL LO-LO

CTMT AIR TEMP HI

CTMT PHASE B ISO ACTUATED

RCS 1,2,3 Tavg HI

PRT TEMP HI

L/D HX OUTL ET TEMP HI

SG 1,2,3 STM/FW FL OW DEVIATION

FW TEMP HI

CTMT MOIST URE HI

CTMT RAD HI

RCS 1,2,3 T avg / AUCT Tavg HI / L O

PRT PRESS HI

RHX L /D OUT LET TEMP HI

CHARGING FL OW CONT FLOW L OW

MSIV TRIPPED

FW PUMP TRIP

CONDENSER ABS PRESS HI

CT MT PRESS HI

ACCUM TK PRESS

VCT L EVEL

VCT PRESS

MSL PRESS RATE HI ST EAM ISO

MSL 1,2,3 PRESS RATE

CONDENSATE PUMP FLOW L O

CONDENSER LEVEL

0:05 CONT BANK D FUL L ROD WITHDRAWAL

AXIAL POWER DISTRIBUT ION L IMIT

Reactivity

Electrical

Tref/AUCT Tavg HI / LO

GEN BRK OPEN

PRZ PORV OPENING RCS 1,2,3 FLOW LO

RCP 1,2,3 TRIP

AFW (MD) ACT UATED

CVCS L/D HX outlet flow

-25

-20

-15

L/D HX outlet temperature

-10

-5

0

-25

RCP Seal INJ water flow

-25

-20

-15

-10

-20

-15

-10

RHX L/D outlet temperature

-5

0

-25

RWST level

-5

0

-25

-20

-20

-15

-10

VCT level

-5

0

-25

Charging flow cont flow

-15

-10

-5

0

-25

-20

-15

-20

-15

-10

-5

0

-10

-5

0

VCT pressure

-25

-20

-15

-10

-5

0

-10

-25

-5

-20

0

-15

Fig. 4. The revised alarm screen.

C. Procedure and Emergency Guidance Improvements Due to strict procedural adherence requirements, instead of requiring decision support, operators often benefit from tools that reduce errors of omission. The Procedure Guidance Component (PGC) supports the operator’s process control effectiveness, by converting the procedure manual into an online, navigable guide (fig. 5). Clicking on any procedure in the left column produces a detailed text description of the procedure. It also reports relevant system variables and links to useful screens elsewhere in the simulator. This tool adds interactivity to what was previously only a hardcopy procedure manual.

technique common to document viewer applications. The continuity provided through the scrolling feature obviates the need for page turning, which takes time and artificially divides what, in reality, is a continuous process. The logic that runs the simulator can be used to support the EGC. Because some decision nodes are based on system variables, the system can often suggest an appropriate decision based on the current system state. The system’s suggestion is displayed in a green box to the right of the flow diagram and above the response instructions. It includes the suggested action and the rationale for proposing it. In addition, the operator can trace the decision path because the system fades the paths which have not been taken to a neutral grey, leaving a bold black decision path. Digitizing the emergency procedures enables the implementation of additional support features. The response instructions often involve “if-then” statements. For example, if the pressurizer level reaches 8 meters, then open valves X and Y. Because the simulator knows system variable values, it can guide “if-then” decision-making by placing a red box around “then” actions when the “if” conditional is met. Procedure and System Overview LOCA Guidance

Suggested Action: Address decision node 9 Rationale: RCS pressure dropped < 9 bar within 200 sec (node 8)

no

RHR pumps in operation (RCS pr. < 9 bar)

Continue Small-break LOCA /LOCA in PZ R steam sp ace; press. > 9 bars.

If: PRZ level

RCS pressure droped < 9 bar within 200 sec

PRZ lvl 2.10 m

< 2.28 m

yes

Then: Large-break LOCA C. press. = Ctm. Press.; M S press. Poss. > 4 bar.

no

M edium-break LOCA

9

Continue L arge/Mediu m-break LOC A RHR pumps in the reflood/sump recirculation mode make up the outflow thr ough the break at coolant pressure < 9 bar.

8

Variable & Trends

Procedure Guidance

7

Address action node 10 If: PZR level

9

> 2.28 m

yes

Then:

PZR level < 2.28 m

Address action node 12 no

Reset RP signals “JR 41/42”

10

Raise PZR level to about 8 m by spraying from “JDH*

11

End “If” __________________________________

4.0 Procedures

Display

4.1 Continue RCS heat… 4.2 Increase RCS pres… 4.3 If any RCP’s have b… 4.4 The letdown flow… 4.5 When RCS pressu… 4.6 When RCS pressu… 4.7 Place the auxiliary…

DESCRIPTION 4.6 When RCS pressure is above 140 kg/cm2, ensure the following: 4.6.1 Verify pressurizer permissive P-11 status light off. OK 4.6.2 Verify pressurizer SI and steam line pressure SI are unblocked on trip status panel. OK 4.6.3 Verify PORV block clears when RCS pressure goew above 153.6 kg/cm2. VERIFY

4.8 Align the steam du… 4.9 Continue heatup u…

RELEVANT VARIABLES AND LINKS

4.10 Verify minimum sh…

Link to RCS screen Current RCS pressure

4.11 Verify the following…

144 kg/cm2

4.12 Review to ensure…

Fig. 5. Procedure Guidance Component.

The second component, the Emergency Guidance Component (EGC), is used during emergencies in which the root problem is unknown. The EGC is a reworking of the Strategic Manual Operations flow diagrams provided by LABIHS (for example, see fig. 6). Clicking on event objects on the left provides response instructions on the right. The operator may scroll up or down through the flow diagram and response instructions using the click and drag

Bypass emergency core cooling criteria

PRZ lvl

CTout

VCT

MS pr

RCS pr

PRZ pr

12

Tavg

Main Menu

Plant Overvw

C–P Status

Alarm

ROD

RHR

RCS

CVCS

FW S

Cond.

Reactvty

Elec.

Fig 6. Procedure and System Overview screen displaying the EGC.

The Procedure and System Overview (PSO) screen was created to display the PGC and the EGC (fig. 6). The operator may tab between the PGC and the EGC, which reduces short-term memory requirements when compared to hardcopy procedures. On the right side of the PSO, graphical representations of relevant variables are displayed. These are dictated by the current procedure. For example, during a Loss of Coolant Accident (LOCA) the system will keep track of main system pressure, pressurizer pressure, etc. In addition to providing support during emergencies, it aids accident prevention by supporting operator awareness. In the hardcopy procedures, the response instructions of action nodes include “if-then” relationships. Some “if”

statements refer to the system state (e.g., if valve X is open) while others ask the operator to wait for a variable to reach a set point before taking action. Unlike the hardcopy version, the new system displays these variables explicitly and proximally, and outlines in red the response instructions when the “if” conditions are met [5]. V. SCENARIO EVALUATION OF NEW PROTOTYPE The prototype has not yet been implemented, so scenariobased evaluation was used. To gauge performance, we evaluated the design using two representative scenarios. The LABIHS interface design provided the performance benchmark. A. Stuck Valve Incident Scenario The first scenario is a hypothetical incident in which the FV122 valve is in automatic mode and closed (correctly) due to high pressure in the pressurizer. When the pressurizer pressure drops, the FV122 valve is supposed to reopen. However, the valve is stuck closed. The interface (due to a glitch) incorrectly displays it as open. The initial symptom of this issue is the sounding of the Charging Flow Low (CFL) alarm. In the original design, when the alarm sounds, one operator navigates to both of the alarm screens, notes the CFL alarm and must use the main menu to navigate to the CVCS screen to diagnose the problem. Seeing FV122 “open” and automatic, the operator may check FV616 and the charging pumps. Seeing these open and on, respectively, the operator may check the Volume Control Tank (waiting to see up or down movement). At this point the operator may request field verification of the computer readings. This would identify that FV122 is closed, contrary to the interface display. In the redesigned interface, with only one alarm screen, one click allows the operator to observe the CFL alarm. The alarm arrangement and tile timer informs the operator which screens to go to and how long the alarm has been sounding. The trends on the alarm screen give a graphical representation of the magnitude of the problem, whether it is likely to become worse, and, if so, at what rate. With just these trends, the operator may begin to hypothesize the root problem even before navigating to the CVCS screen. For example, the Volume Control Tank graph displaying a downward trend coupled with the low charging flow could indicate a leak on the outflow side, whereas an upward trend could indicate a closed valve on outflow side. Next, the operator navigates to the CVCS screen to diagnose the problem by clicking directly on the blinking alarm. The CVCS screen’s flashing red box will direct the operator’s attention to the alarm’s trigger, in this case the charging flow indicator. Depending on the simulator logic, the gray colored piping may show that flow is not going through FV122, pin-pointing the root problem.

B. Loss of Coolant Accident Scenario A loss of coolant accident (LOCA) occurs when there is a pipe rupture in the Reactor Coolant System (RCS). This causes the reactor to trip (shutting down power production) automatically. The operators are tasked with bringing the system under control by following a LOCA flow diagram procedure. Currently this diagram is available in hardcopy and portable document format. The format requires the operator to shuffle among various pages. The flow diagrams and the response instructions are located on separate pages, either requiring the operator to flip back and forth at least once per node or to take up desk space by laying them side by side. The standard hardcopy procedures are bound, therefore requiring the flip method. Given a medium-break LOCA, getting to step 12 of the diagram requires at least 4 flips between the diagram pages and the response pages, and viewing 23 pages. The redesign addresses this issue by co-locating the flow diagram and the currently selected node’s response instructions. The redesign requires no page turns, and since it is linked to the alarm system, the operator does not have to search for the appropriate binder or page number. VI. EXTENSIONS Further testing is required to validate the claimed benefits of the redesign. This would entail implementing the prototype into the simulator for testing in multiple scenario simulations. In some sessions, the original design with hardcopy procedures would be used, providing a performance benchmark. Our design strategy must ultimately be tested in an actual nuclear power plant interface. This would be a substantially more complex problem due to added variables not represented in the compact simulator. ACKNOWLEDGEMENTS Thanks go to Paulo Victor de Carvalho for granting us the access to facilities that made this project possible, to the operators and staff at LABIHS for enlightening us on NPP operation, and to those at the Lake Anna Nuclear Power Plant for their helpful direction. REFERENCES [1]

[2]

[3] [4] [5]

International Atomic Energy Agency and Nuclear Energy Agency. Nuclear Power Plant Operating Experiences from the IAEA/NEA Incident Reporting System 1999-2002. Jointly Prepared by IAEA and OECD/NEA, 2003. http://www.nea.fr/html/nsd/reports/nea5168IRS.pdf . Ryan, T. The Human Factor in Operation and Maintenance of Complex High-Reliability Systems. American Institute of Aeronautics and Astronautics, Inc, 1989. Besnard, D. & Greathead, D. A Cognitive Approach to Safe Violations. Cognitive Technology Work, vol. 5, pp. 272-282. Roscoe, S. N. Airborne Displays for Flight and Navigation. Human Factors, 1968, vol. 10, pp. 321-332. Guerlain, G. & Bullemer, P. Critiquing Team Procedure Execution. Proceeding of the IEA 2000/HFES 2000 Congress, 2000.