When people ask me what I do at work, I often pause to consider who’s asking the question. I have a selection of answers.

• I’m an engineer
• I’m an engineer in the electric power industry
• I’m a nuclear engineer
• I’m a control systems engineer in the nuclear industry
• I work on safety analysis calculations in the nuclear industry
• I do setpoint and uncertainty calculations for nuclear power plants
• I keep the world safe from the evils of nuclear power

first two are accurate; the third one isn’t but serves a purpose. A nuclear engineer is someone with a nuclear engineering degree and I don’t have one of those. The fourth one is accurate; the fifth isn’t but few people would know that. While the sixth is an accurate description of what I do, it’s not very accessible to most people. The last is also accurate, if a bit flippant. My work helps ensure a nuclear plant is operated safely.

Nuclear power plants have an array of automatic and semi-automatic control systems designed to sense abnormal and potentially unsafe conditions and initiate actions to put the plant in a safe mode. These systems are separate from those that control the plant during normal power operation.

Every nuclear power plant also has a comprehensive array of analyses and calculations that demonstrate the plant can be safely shut down without releasing significant amounts of radiation to the public during postulated ‘accidents.’ In this context, an accident is a critical system failure, whether from equipment malfunction, design error or natural occurrences such as earthquakes. All credible accidents are analyzed with the results published in the plant’s Final Safety Analysis Report, a document that is submitted to the Nuclear Regulatory Commission as part of the requirements necessary to secure a license to operate the plant. The FSAR, along with other engineering documents, details the design basis of the plant. In other words, the design features that allow it to operate safely. As long as the evolving design of the plant remains within the design basis, the safety analyses remain valid. The FSAR is a living document – it’s continually updated as upgrades and modifications are made.

A license issued by the NRC is not simply a go-ahead to operate. It’s not a piece of paper. Rather, it’s a lot of paper. The most significant part of the license is the Technical Specifications, a document that provides, in considerable detail, exactly how the plant must be operated, particularly what safety equipment must be operable. The Tech Specs, as they’re commonly referred to, also contains dozens of limiting conditions for various parameters.

For example, the primary system pressure must be maintained within specific limits – not too high and not too low – when the reactor is at power. There are instruments (electronic measuring and control devices) that monitor primary pressure and initiate actions if it goes too high or too low. How high or low? Well, that’s where I come in. It would not do to set the instruments to actuate right at the limits provided in the Tech Specs. All measurements contain some amount of uncertainty and that uncertainty must be calculated and accounted for in the actual plant setpoint. So, if the Tech Spec limit is 2250 psia increasing, the actual setpoint might need to be 2230 psi or lower after determining that there might be 20 psi uncertainty. The 20 psi figure would come out of one of my setpoint and uncertainty calculations.

Because some of the uncertainties inherent in a measurement aren’t in play when instrument setpoints are periodically checked by technicians, the Tech Spec limits themselves incorporate a certain amount of margin with respect to what the safety analysis calculation assumed in concluding the plant could be safely shutdown. To determine a safe setpoint, we start with the safety analysis assumption and work backwards, accounting for all uncertainties that might influence the measurement during any postulated plant conditions, including accidents. That ends up validating both the Tech Spec limit and the actual setpoint.

So, that’s what I do. But as you might imagine, the details are complicated. Determining instrument inaccuracies is a matter of skill and art, as one of my engineering managers once described it. I have to agree. After doing this for a couple of decades – and before that I was an instrument technician, one of the people charged with actually ‘setting’ the setpoints in the field – I’ve come to know a bit about how to apply skill and art to the matter.

We (setpoint calc people) don’t work in an unregulated vacuum. I can’t just apply my experience, add a bit of art, and come up with what I think the setpoint should be. As with all nuclear safety-related activities, there are procedures and regulations to follow. Every plant has a specific engineering procedure that details in varying degrees how to determine setpoints. Most derive from what the original reactor vendor provided as a basis for operating the plant. Some plants have kept a version of that methodology in place over the years while others have made changes to come up with their own, unique methodology.

In every case, the methodology must be approved by the NRC. To determine whether to grant approval, the NRC relies on the controlling federal regulations (found in 10CFR50) and on industry standards that have been previously endorsed by the agency. The prevailing industry standard for determining setpoints is the International Society of Automation’s (formerly the Instrument Society of America) 67.04 publication, which has been revised over the years. ISA 67.04 and its implementing standard, RP67.04, discuss in great detail what effects on instruments must be considered and provides the basis for statistically combining the effects to come up with an overall uncertainty that accounts for all required factors with the level of confidence mandated by the NRC.

In the course of my career, I’ve prepared setpoint calcs for dozens of plants. That experience has been wildly mixed in terms of personal and professional satisfaction. Frankly, most clients can be utter assholes. They demand results that cannot be achieved and schedules that cannot be met. They demand error-free calculations despite providing ambiguous, error-ridden design documents to me as inputs to the calcs and despite allowing much faultier calculations from their own engineers. Their comments are often pedantic, irrelevant, or mind-bogglingly stupid. I’ve had discussions with clients that left me speechless. I’ve many times just wanted to say “You have no idea what you’re talking about, so why don’t you do the rest of us a favor and just shut the fuck up.”

On the other hand, when you get a client who understands the process, understands the challenges and respects you as a professional and as someone whose goal is to help their plant with whatever engineering difficulty they’re currently involved with, it can almost be rewarding. Almost.

All through my career as a setpoint calc engineer, my focus has been client-oriented. I’ve tried to find a way to allow the plant to do whatever it is they had in mind, be it a power uprate, a switch to 24-month fuel or simply (often not so simple) responding to a directive from the NRC, all while maintaining the prime directive: protect the design basis of the plant. Sometimes, it just doesn’t work out so well.

Recently, I was asked to come into a project that had experienced some difficulties because the engineers my company had doing the calcs were inexperienced and were getting hard questions from the client they couldn’t answer. I agreed, but after re-doing the calculations, I had to conclude that the plant couldn’t do what they wanted to do. The numbers just weren’t working out. No one is happy with that outcome.

Perhaps the darkest time for me was after years of working calculations with a big client that was planning not one, but two major plant modifications in back-to-back refueling outages. My partner (whom I’ve worked with for almost two decades and who is awesome) and I just kept running into issues making a set of very critical calculations come out right. And by right, I mean they would demonstrate that the plant’s design basis would be protected even after the two modifications were performed. Our results kept coming out negative. The client grew increasingly unhappy and eventually said they would take over the calculations themselves if we didn’t agree to incorporate changes that we didn’t think were proper. Changes that would make the calcs work but weren’t supported by available data.

I’m not going to name the plant and I’m not going to discuss how it all finally resolved itself. But I will say that for the first and only time in my career, I felt obliged to inform the NRC of a significant safety concern. In other words, I blew the whistle. There’s a process for doing this and as with other whistleblowing involving the federal government, there are some protections. I gave them all my files and my analyses and told them that, in my expert opinion, the plant was planning on violating their license and that the NRC should step in.

As I said, my primary focus is maintaining the design basis and I will not compromise that principle. You know how we’ve prevented Fukushima here in the US? By vigilantly maintaining the design basis. That’s also why Three Mile Island wasn’t Fukushima – the plant’s defense-in-depth safety systems worked. The containment building held.

So, yeah, I keep the world safe from the evils of nuclear power.

In the final analysis (no pun intended), I’ve hated this job. I wanted to be a geologist with the  US Geological Survey. Or a tennis pro.