Simulator exercises

On her last week in the I&C group, Hana sits at the back of the TVA simulator while a crew of licensed operators runs a training scenario. Marcel is the instructor at the console behind a one-way window. He starts with the unit at full power, then quietly fails a steam generator level channel high. The crew notices the mismatch, places the channel in trip per procedure and continues. Twenty minutes later he trips a main feedwater pump. The runback cuts load; the crew confirms the runback, checks levels and stabilizes the unit. “Now the interesting part,” Marcel murmurs, and fails a second instrument just as the crew settles.

This final lesson brings the course together through the simulator. It explains what full-scope simulators are and how they are qualified, how training scenarios are designed and evaluated, and then walks through four exercises that combine the control, instrumentation, protection and human factors ideas of the previous lessons.

Full-scope simulators

A full-scope simulator replicates a specific plant's control room and models the plant's response in real time, from normal operation through design basis accidents. Its models include neutron kinetics, thermal hydraulics of the reactor coolant and steam systems, the control systems and logic, the electrical system and the instrument channels. Under 10 CFR 55.46, a plant-referenced simulator used for operator licensing examinations must meet ANSI/ANS-3.5 as endorsed by Regulatory Guide 1.149, with performance testing and comparison against plant data. Simulator fidelity is maintained against plant changes so that what crews learn on the simulator is true of the plant.

Simulators serve several purposes. They train new operators and requalify experienced ones. They examine candidates for certification or licensing. They support the validation of new procedures and interface designs, as part of the human factors verification and validation described in lesson 11. And they let engineers test control system changes, such as new tuning or logic, with a realistic plant model before installation.

Designing a scenario

A training scenario is a script that takes the crew through a sequence of events designed to exercise specific knowledge and skills. Good scenarios begin from a realistic plant state, introduce an instrument failure or minor equipment problem to test diagnosis, add a component failure that requires abnormal procedures, and progress to a major transient or accident that requires emergency procedures. Each scenario defines the expected crew actions, the critical tasks, actions whose omission or incorrect performance would lead to a significant degradation of plant safety, and the time limits for them. Instructors observe, record times and actions, and lead a debrief afterwards.

Evaluation looks at crew performance as well as individual actions. Did the crew communicate clearly, using repeat-backs and three-way communication? Did the shift supervisor maintain an overview without getting lost in details? Did the crew use procedures correctly and recognize when a procedure did not fit the situation? Did they monitor critical safety functions throughout? The debrief, often supported by a replay of the simulator data, is where most of the learning happens.

Exercise 1: an instrument failure

A steam generator level channel used for control fails high. The three-element controller sees high level and reduces feed flow; the real level begins to fall. The crew sees disagreement among the redundant level channels, recognizes the failed channel, selects a healthy channel for control or takes manual control, and places the failed channel in trip as the technical specifications allow. The lessons from this course: redundant indications let a crew detect a failed channel (lesson 7); a failed control input can drive a real process away from its setpoint (lesson 5); and because the protection channels vote two-out-of-four and control uses a median or validated signal in modern designs, the failure neither causes a trip nor defeats protection (lessons 8 and 9).

Exercise 2: a pump trip and automatic power reduction

A main feedwater pump trips at full power. The turbine runs back, steam dumps open briefly, and rod control inserts rods to bring average temperature back to its program. Steam generator levels dip because feed flow falls faster than steam flow, then recover as the remaining pump and the feed controllers respond. The crew confirms the runback, checks levels and pressurizer pressure, and verifies margin to the steam generator low-low level trip. Later, as xenon builds up after the power reduction, the crew dilutes boron to hold rod position within insertion limits and plans the return to power.

Exercise 3: reactor trip and decay heat

A loss of all feedwater leads to a reactor trip on low steam generator or boiler level. The crew's first actions follow the emergency procedure: confirm that the reactor has tripped, with all rods in or poison injected and neutron power falling; confirm the turbine has tripped; and check that heat is being removed. After the trip, the core still produces decay heat from fission products, a few percent of full power at first and falling over hours.

# Simulator exercise: decay heat after a trip from full power, and scoring of crew actions.
P0 = 2700.0                                  # MW thermal
def decay(t): return P0 * 0.066 * ((t + 1.0) ** -0.2 - (t + 1.0e6) ** -0.2)   # Way-Wigner style estimate
for t in (10, 60, 600, 3600):
    print(f"decay heat {t:5d} s after trip: {decay(t):6.1f} MW ({decay(t) / P0 * 100:.1f}%)")
critical = {"confirm reactor trip": 60, "verify heat sink": 300, "stabilize pressure": 900}
actions = {"confirm reactor trip": 25, "verify heat sink": 340, "stabilize pressure": 640}
score = 0
for task, limit in critical.items():
    t = actions.get(task)
    ok = t is not None and t <= limit
    score += ok
    print(f"{task:22s} limit {limit:4d} s, done at {t:4d} s: {'met' if ok else 'missed'}")
print(f"critical tasks met: {score} of {len(critical)} -> {'pass' if score == len(critical) else 'debrief and repeat'}")

decay heat    10 s after trip:   99.1 MW (3.7%)
decay heat    60 s after trip:   67.1 MW (2.5%)
decay heat   600 s after trip:   38.3 MW (1.4%)
decay heat  3600 s after trip:   23.4 MW (0.9%)
confirm reactor trip   limit   60 s, done at   25 s: met
verify heat sink       limit  300 s, done at  340 s: missed
stabilize pressure     limit  900 s, done at  640 s: met
critical tasks met: 2 of 3 -> debrief and repeat

For a 2700 MW thermal reactor, decay heat is about 100 MW ten seconds after the trip and still more than 20 MW after an hour, which is why heat removal must be established and maintained. In this run the crew confirmed the trip in 25 seconds and stabilized pressure in under eleven minutes but took 340 seconds to verify a heat sink, past the 300-second limit. In a real evaluation, missing a critical task would lead to a debrief and remedial training, not because the plant would necessarily have been damaged, but because the time limit was chosen to keep margin.

Exercise 4: a second failure during recovery

The final part of Marcel's scenario combines failures. As the crew stabilizes the unit after the trip, a pressurizer level channel fails high, making it appear that the reactor coolant system is full. A crew that trusts one indication might reduce charging or safety injection, lowering real inventory. The procedures direct the crew to check redundant and diverse indications, such as other level channels, subcooling margin, core exit thermocouples and pressure trends, before acting. Hana watches the shift supervisor stop the crew, ask for confirmation from a second channel, and continue only when it agrees with pressure trends. Afterwards Marcel connects this directly to Three Mile Island, where a misleading pressurizer level led operators to reduce emergency cooling.

Learning from exercises

Simulator programs feed results back into the plant. Repeated difficulties with an exercise may reveal a procedure that is unclear, a display that hides important information, or a control behavior that surprises operators. Operating experience from the plant and from other plants worldwide is turned into new scenarios, so crews practice events that have happened elsewhere. And engineers use the simulator to test proposed I&C changes with real crews before installation, closing the loop between design, operation and training that runs through this course.

Andrea's last conversation with Hana before her rotation ends returns to the whiteboard sketch from her first morning. “A plant is a set of loops,” she says. “Control loops that hold it steady, protection loops that act once, and the biggest loop of all, the crew, who watch the indications, decide and act. Our job is to make all three reliable, and to make sure that when one fails, the others still work.”

Simulator limits and fidelity

A simulator is only as good as its models. Real-time models must simplify: the core may be represented by a few hundred nodes rather than the thousands used in design codes, and two-phase flow by correlations rather than detailed calculations. Simulator engineers validate the models against plant data from start-ups, trips and tests, and against best-estimate codes for accidents that have never happened at the plant. Where the simulator cannot reproduce a phenomenon accurately, such as some severe accident behavior, instructors are told so and scenarios avoid relying on it. Each plant modification that affects the control room or the plant's response must be reflected in the simulator before crews are trained on it, which makes the simulator group part of the design change process.

Negative training is the risk to manage. If a simulator responds differently from the plant, crews may learn the wrong expectation and act on it in a real event. Simulator programs therefore track deficiencies reported by instructors and operators, compare simulator and plant responses after real plant events, and fix differences that could affect training. The standard for simulators requires such comparisons and periodic performance tests.

From the simulator to the plant

Engineers use the simulator in their own work as well. Before a new controller tuning or logic change is installed, it can be loaded into the simulator, tested against the scenarios it must handle, and shown to the crews who will operate it. Procedure writers walk through new procedures on the simulator to find steps that do not work. Safety analysts compare simulator responses with their analysis assumptions for timing of operator actions. This is the last step of the closed loop of design, operation and training that the human factors program describes.

Hana's report at the end of her rotation describes the four exercises and what each taught her about the plant. Andrea reads it and adds a single comment at the end: that the most important skill she saw in the crew was not speed but verification, the habit of confirming a reading with a second, independent source before acting on it. It is the same principle that underlies redundant channels, diverse shutdown systems and defense in depth, applied by people.

Exercises with the wider organization

Simulator scenarios are also used in emergency exercises that involve the whole site and outside organizations. The simulator drives the plant conditions that the control room crew sees, and the data are passed to the technical support center, the emergency operations facility and, in large exercises, to provincial, state and federal authorities. These exercises test communication, decision-making on protective actions and the flow of plant information under stress. Regulators observe them and require corrective actions where weaknesses appear. In this way the same simulator that teaches a single crew to confirm a trip also helps an entire region practice its response to an emergency.