Why So Many SCRAMs?

I was reviewing the NRC event reports for the last few months and noticed several reactor trips. The normal average is one trip every two years or so. I did not go back and see if in this recent spate of trips any of the units involved were exceeding that rate, it just seemed like a lot in a relatively short period of time.

If you’re curious to see what kinds of things the NRC requires to be reported to it, here is the link. https://www.nrc.gov/reading-rm/doc-collections/event-status/event/2024/index.html

We’ll start with basics. A reactor trip (or SCRAM) is a fast shutdown of the reactor by causing all control rods to insert fully into the core. This is generally achieved in PWRs by deenergizing the gripper mechanism that holds onto the rod and letting them fall into the core. On BWRs, the rods are inserted from the bottom using hydraulic pressure contained in a SCRAM volume.

Either way, the control rods absorb all the extra neutrons floating around the core and stop the fission chain reaction almost instantly.

There are a lot of things that can cause a reactor to trip. They are all based on 10CFR50 Appendix A, General Design Criteria. These are just what they sound like, general requirements for all nuclear power plant designs with the goal to ensure the facility can be operated without undue risk to the health and safety of the public.

https://www.nrc.gov/reading-rm/doc-collections/cfr/part050/part050-appa.html

The key part for todays discussion is below. This outlines the GDC for the reactor protection system.

I am going to discuss the Westinghouse version of the RPS, as I am most familiar with it and I have a lot of publicly available information on it. See this link if you really want to dig in. https://nrcoe.inl.gov/SysStudy/W.aspx

The starting point for the RPS are the sensors. These are instruments that monitor a given parameter, such as reactor power. Per the above criteria, they are required to be extremely reliable and able to be tested at power. To do this, the system uses multiple sensors (usually 3 or 4 to allow for logic circuits – we’ll get there), all of which are completely independent from their power supply all the way to their outputs. This ensures that no single failure can prevent the system from working.

(Single failure criteria is defined in the GDC. Basically, no one thing can break and prevent any of the important to safety systems from doing their job. Engineers use this to find the worst possible thing to break and then prove that the plant is still safe even without that 1 thing. It gets really complicated, but that’s the idea.)

The output from the sensor is then sent to a bistable circuit. A bistable has 2 conditions; not-tripped, or tripped. The bistable compares the output of the sensor to a setpoint, and if the output is above (or below depending on the thing being checked) that setpoint, the bistable trips and sends this trip signal on to the logic circuits.

The logic circuits are designed to ensure a trip happens if it is a legitimate signal, and to prevent an instrument failure in a single channel from causing a trip if it’s not real. It does this by requiring either 2 of 3 or 3 of 4 logic to be met.

Using the reactor power example I started with, there are 4 channels of reactor power instruments. In a real event such as a power excursion above 100% power, all 4 channels should register the event. If 1 channel is broken (single failure criteria again), the 3 remaining channels will see the event and still meet the 3 of 4 logic and order a reactor trip.

On the other hand, if 1 channel fails when there is no event actually occurring, the system will only see 1 of 4 channels asking for a trip and will not cause a trip to happen.

Once the logic is met, the trip signal is sent on the the reactor trip circuit breakers (TCB). There are 2 of them in series (this means power passes through the A TCB first, then the B TCB). The logic system above sends out 2 signals, an A trip and a B trip. The A signal goes to the A TCB and the B signal to the B TCB. As long as either breaker opens, power is lost to the mechanism holding the rods out of the core and they fall in and kill the fission reaction.

This is how the RPS functions. There are usually around 10 different indications that are monitored to tell this system to do its job. If system pressure gets too high or too low, the reactor will trip. If power gets too high, it will trip. If SG water level gets too low, it will trip. There are also some more complex calculated trips that monitor several parameters to determine if the core is operating safely.

This is all intended to prevent the core from exceeding the specified acceptable fuel design limits (SAFDL) during any anticipated operational occurrences (AOO). These are events that can be expected to happen once or more in the lifetime of a plant, such as a turbine trip.

In other words, this is all intended to prevent damaging the fuel or fuel cladding, thereby ensuring that the fission products remain inside the fuel rods and no one is exposed to an extra radiation.

Now we have to talk about the concept of engineering margin. In all of these calculations that are done to find the right setpoints to protect the reactor, engineers assume worst possible conditions. The instrument is at the outside limit of calibration in the unsafe direction, the reactor is at its most unstable time in core life, the operators are morons and will never take action before the system does it automatically (more on this later).

The SAFDLs also contain margin. They may say something like ensure fuel centerline temperature never reaches 4000F, when the actual point that damage would occur is 4500F. This is done to ensure we are operating in as conservative a manner as possible with respect to protecting the fuel. It gives us room for the occasional human error hiding somewhere in all these calculations, too.

The setpoints that come out of all this engineering conservatism are heavy on margin. When we finally get a setpoint it goes into technical specifications as the Limiting Safety System Setpoint (LSSS). After all this talk of margin, do you really think that is the number that’s used? Of course not. We use a number that is conservative to the LSSS so that the reactor trips before the actual required value.

Lets use SG water level as an example of a LSSS and actual setpoint used. If the calculations said that the reactor has to trip at 10 inches in the SGs, we would set the actual setpoint to a higher value like 20 inches. If it was the high pressurizer pressure trip, the LSSS might be 2500 psia, and we set the setpoint to actually trip the reactor lower than that, as say 2400 psia. The key is that the actual setpoints are conservative to the required LSSS ones.

So, that is the automatic system. In practice, we as operators almost never allow the automatic system to do its job. We are always monitoring the reactor, and if any of the parameters that would cause a trip are trending in that direction and we can’t fix it in time, we trip the reactor ourselves.

Some things happen too quickly for us to do this, like the main turbine tripping. This is where all the heat from the reactor is going, and if it goes away suddenly the reactor will heat up quickly and pressure will rise with it. To prevent this, if the turbine trips it automatically tells the reactor to trip. This happens in milliseconds, so we rarely beat this one.

A number of the trips I saw were due to feedwater issues. Feedwater is the water we put into the steam generators. This removes heat from the reactor as the water is boiled. If you lose feedwater, you are at risk of losing the heat sink for the reactor with effects similar to the turbine trip above. This is a slower event (1 or 2 minutes maybe). We follow our procedures to try to start another feedwater pump, but if SG water level drops too close to the setpoint, we manually trip the reactor before the automatic trip can do it.

Another aspect of this that is worth mentioning is operator training. They get 5 or 6 weeks a year of additional training, much of it in the simulator. In the simulator, the reactor trips in just about every scenario. This is to ensure the crews are highly trained in responding to the rare actual trip. We also test them on the reactor failing to trip, which is almost impossible, but very consequential if it does happen. I have ordered the fake reactor tripped hundreds of times in my career. I have never done so on the real unit. It just doesn’t happen often.

As to the whys for all these trips, most of them have been caused by non-safety related equipment failing. Things like FW pumps and transformers unexpectedly breaking happen. Nuclear plants have a robust preventative maintenance program for all of this, but sometimes shit happens. Sometimes that shit seems to cluster.

I do not believe the spate of trips indicates any significant issue within the industry or at the individual plants. The plants will investigate the reasons, implement strategies to fix whatever the problem was, and will have to convince the NRC that they did so in an acceptable manner.

One of the things that gives me such confidence in the nuclear industry is our drive to learn from mistakes and prevent future similar mistakes from happening. We learned this lesson the hard way from TMI, but we learned it well.

If you want to see what the NRC does to a plant that has several trips in short order and fails to fix its own problems, please dig into this special inspection report the Turkey Point got in 2020 after tripping 3 times in a week or so. 1 trip was equipment related, the other 2 were operator caused. The middle one is especially concerning as far as trips go.

https://www.nrc.gov/docs/ML2034/ML20344A126.pdf

Anyway, that was a lot more than I thought it would be when I started and I could keep going, but won’t torture you further. As always, this is all open source. Here are some more links if you’re curious.

https://www.nrc.gov/docs/ML1125/ML11251A044.pdf

https://www.nrc.gov/reading-rm/doc-collections/event-status/event/2024/index.html

https://www.nrc.gov/reading-rm/doc-collections/cfr/part050/part050-appa.html