Simulator exercises

On her last week in the I&C group, Hana sits at the back of the Darlington simulator while a crew of authorized nuclear 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 boiler level transmitter low. The crew notices a mismatch on the displays, takes the channel out of service and continues. Twenty minutes later he trips a heat transport pump. A stepback cuts power; the crew confirms the stepback, checks flows 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 with spatial effects, thermal hydraulics of the heat transport and steam systems, the control computers and logic, the electrical system and the instrument channels. In Canada, the CNSC requires full-scope simulator training for authorized staff, and REGDOC-2.2.3 sets out the certification requirements, including simulator-based examinations. Simulator fidelity is maintained against plant data and design changes, often following the ANSI/ANS-3.5 standard, 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 boiler level transmitter fails low. The three-element controller sees low level and increases feed flow; the real level begins to rise. The crew sees disagreement among the redundant level indications, recognizes the failed channel, transfers the controller to a healthy channel or to manual, and removes the failed channel from service. 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 shutdown system has its own, separate level channels with two-out-of-three logic, the failure neither causes a trip nor defeats protection (lesson 8).

Exercise 2: a pump trip and automatic power reduction

A heat transport pump trips at full power. Within seconds the regulating system steps power back by dropping the mechanical control absorbers, and core flow drops to the value supplied by the remaining pumps. The crew confirms that the stepback occurred and power settled at the expected level, checks heat transport pressure and pressurizer level, and verifies that the shutdown systems' flow and power channels show margin to their trips. Later, as xenon builds up after the power reduction, the regulating system drains the zones and then withdraws adjusters; the crew monitors this sequence and plans with fuelling and management whether to return to power before xenon becomes limiting.

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 transmitter fails high, making it appear that the heat transport system is full. A crew that trusts one indication might reduce feed, lowering real inventory. The procedures direct the crew to check redundant and diverse indications, such as other level channels, heat transport pressure and the subcooling margin, 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 behaviour that surprises operators. Operating experience from the plant and from other plants worldwide is turned into new scenarios, so crews practise 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 behaviour, 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 defence 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 centre, 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 practise its response to an emergency.