Nuclear Thermal Rocket Emulator for a Hardware-in-the-Loop Test Bed ^†

Abstract

To support NASA’s mission to use nuclear thermal rockets for future Mars missions, an instrumentation and control test bed has been built at Oak Ridge National Laboratory. The system is designed as a hardware-in-the-loop test bed for testing control elements and autonomous control algorithms for nuclear thermal propulsion rockets. The mock reactor system consists of a modular and scalable framework, using inexpensive components and open-source software. The hardware system consists of a two-phase flow loop and a mock reactor with six control drums. A single-board computer (NVIDIA Jetson) handles reactor core emulation and hosts a message queuing telemetry transport broker that allows user-deployed control algorithms to interact with the system hardware. The reactor emulator receives sensor data from the hardware and provides the simulated performance of the reactor under steady-state, transient, and fault conditions. The emulator uses a reactivity lookup table and the point kinetics equations to solve for the reactor dynamics in real time. Emulated reactor dynamics and sensor input inform the autonomous control algorithm’s decision-making in a closed-loop manner. The current system is capable of operating at 10 Hz, but faster cycle rates are an area of ongoing research. This test bed will enable NASA and other space vendors to rigorously test their autonomous control systems for NTP rockets under transient (reactor startup and shutdown), steady-state, and fault conditions to reduce development time and risk for autonomous control systems in future missions.

1. Introduction

The operation of nuclear thermal rockets and reactors for fission surface power (FSP; a nuclear reactor on a moon or planet) require either full-time staff or an autonomous control system to both start and maintain the reactor operation. NASA is interested in placing a nuclear reactor on the moon that can operate continuously for 10 years [1]. Although a lunar reactor can be monitored and controlled from an Earth ground station (communications delay is only a couple seconds), the ultimate goal is to put a reactor on Mars to power long-term mission technology. The time delay between Earth and Mars ranges from 3 to 22 min, so either a full-time operator or an autonomous control system is needed for the reactor on Mars. Likewise, for nuclear thermal rockets, the time delay for communications can be minutes between the Earth and a spaceship, depending on location. With astronauts already responsible for other significant tasks on lunar and Mars missions, the current consensus is that the reactor should operate autonomously. Autonomous nuclear reactor controls have not been commercially developed and remain at a low technology readiness level. Rigorous and extensive testing and validation will be necessary before certification for use near humans.

During NASA’s Project Rover and the Nuclear Engine for Rocket Vehicle Application (NERVA) nuclear thermal rocket program in the 1960s through the 1970s, an automatic control system was used to control some of the reactor’s control systems during the rapid startup [2,3,4]. The automatic system followed a predetermined run script for the drum movement; for autonomous control systems, the system must be able to react to sensor data and make decisions on drum movement and other control aspects of the rocket. To test the control system, several reactors were built and multiple ground tests were conducted during the Rover/NERVA program (23 different reactors) [5] at the Nevada Test Site to fully evaluate both the reactor and its automatic control system. Additionally, a non-nuclear reactor and nuclear thermal propulsion (NTP) engine were built at the NASA Plum Brook station in Sandusky, Ohio, to analyze the control system for the turbomachinery [3]. High costs and regulatory restrictions currently impede the prospects of performing full ground tests of a nuclear thermal rocket system. Consequently, a new non-nuclear reactor hardware-in-the-loop test bed has been built at Oak Ridge National Laboratory (ORNL) to test and evaluate the control systems and autonomous control algorithms for an NTP engine.

The non-nuclear mock reactor at ORNL is a hardware-in-the-loop test bed system that consists of control element hardware (control drums, valves, turbomachinery) that can be actuated by a user or an automated control algorithm. A nuclear reactor emulator receives sensor data from the hardware and provides the dynamic performance of the reactor under steady-state, transient, and fault conditions. Emulated reactor dynamics and sensor input informs the autonomous control algorithm’s decision-making in a closed-loop manner. This manuscript focuses on the digital hardware and nuclear reactor emulator portion of the test bed, more information on the control hardware and layout itself is available elsewhere [6].

2. Background: NTP Reactor Controls

For NTP and FSP reactors, the general design is a cylindrical geometry, with fuel elements embedded in a moderator matrix (e.g., beryllium, zirconium hydride, graphite). Coolant channels or heat pipes are placed in the moderator matrix for heat removal, and control drums are placed on the periphery of the reactor for reactivity control (Figure 1). The control drums are the main mechanism for controlling the reactor’s power, and they typically consist of a cylindrical drum with a neutron poison section (typically boron) on one side and a reflector on the other. At shutdown, the neutron poison side of the control drums is directed toward the reactor to ensure the core remains in a low-power state. During reactor startup, the control drums gradually rotate the poison face away from the reactor core to add reactivity to the reactor and achieve criticality. Reactivity is a measure of a reactor’s state relative to the critical state (the neutrons from one fission cause exactly one other fission of a fissile atom). Positive reactivity indicates a positive change in the number of fissions that subsequently occur from the neutrons of a previous fission, whereas negative reactivity indicates a negative change in the number of fissions. Reactivity is measured in per cent mille (PCM) changes in the reactor critical state or $k_{\mathrm{eff}}$. Controlling the amount of reactivity in the reactor is paramount to ensuring safe operation at desired power ranges.

In addition to the drum movement, temperature and coolant/propellant densities in the reactor core can adjust reactivity conditions. The reactivity of NTP systems is tightly coupled to the dynamic thermal-hydraulic response of the reactor system. As materials heat up in the reactor core, changes in the neutron fission cross section and scattering of the fuel and surrounding materials cause a reduction in reactivity, a process known as negative reactivity feedback. Furthermore, as the fuel is spent and high neutron absorbing fission products gather in the core (i.e., xenon), an additional negative reactivity penalty will occur for the reactor. By contrast, the presence of flowing propellant (hydrogen gas) in the core causes neutrons to more easily thermalize and fission the uranium fuel, causing a positive reactivity boost. As a result, the control drums must actively rotate back and forth to counter these negative and positive reactivity phenomena that occur during operation. If a reactor adds too much positive reactivity, then the reactor risks prompt criticality and rapid deconstruction. On the other extreme, failure to compensate for the negative reactivity will cause the reactor/engine to prematurely shut down. NTP and FSP reactors will be effected by different reactivity phenomenon due to their different operating schemes. NTP reactors are ramped to full power in under a minute, with the temperature rising from 300 K to 2500 K in the same time frame. These high temperatures cause a significant amount of negative reactivity as opposed to a FSP reactor which operates around 1000 K. However, a NTP reactor only operates for around 10–30 min, so xenon poisoning of the reactor will not be a significant issue during operation but FSP reactors will have major xenon poisoning effects from their projected 10 year steady state operation.

The control drums and propellant valves/turbomachinery are the main two control mechanisms for an NTP rocket. Manipulating the drums and control valves control the reactor power and thrust levels of the rocket. For autonomous controls, a control algorithm must be able adjust both these systems in response to the various sensor data collected from the engine (e.g., temperature, propellant flow rates, turbine speed, nozzle pressure). Additionally, fault conditions with the control elements (e.g., drum stuck, valve fluttering) and sensors in the rocket engine (e.g., loss of a sensor, sensor drift) must be tested to enable further development of autonomous control algorithms. This manuscript provides an overview of the hardware and describes how the reactor dynamics are simulated in real time for testing of control elements and algorithms.

3. Mock Reactor Test Bed

The non-nuclear test bed consists of two tightly coupled hardware control systems: the control drum system and the propellant flow system. The control drum system contains six control drums inserted into the periphery of a cylindrical reactor body, with resolvers, optical encoders, and torquemeters to provide drum movement characterization. The flow-loop system consists of a two-phase system of water and pressurized air. This system imitates the propellant flow through a nuclear thermal rocket engine. Actuated valves, turbomachinery, flow, pressure, and temperature sensors provide feedback on the loop status. The two hardware systems are shown in Figure 2.

In an NTP rocket, liquid hydrogen is used as the propellant and undergoes a phase change from liquid to gas throughout the propellant flow path to the reactor. To reduce complexity and the extreme hazard of working with hydrogen, water is used in the flow loop instead of hydrogen. Liquid water is pumped out of a main tank from a pump attached to a turbine that is powered by compressed air (representing the rocket design of using the semi-heated propellant to power the main turbo pump of the engine). The mass flow of pressurized air in the turbine section of the flow loop is matched to the mass flow rate of the water coming out of the main tank (for more information on the setup and of the setup of a typical nuclear rocket engine see ref. [6]). The temperature, pressure, and flow of the water and air are measured throughout the mock reactor hardware and used as inputs into the reactor emulator model. Physical measurements are scaled to represent the actual values that a NTP reactor would experience. Although the exact values from the sensors are scaled down compared to an actual NTP engine, the process of actuating, recording, moving, sensing, and adding in fault conditions to the hardware is valuable when characterizing behaviors in the system and identifying failure modes in autonomous controls.

The brain of the mock reactor is an NVIDIA Jetson (Jetson NANO, manufactured in Taiwan) single board computer that hosts a message queuing telemetry transport (MQTT) broker that facilitates control commands and sensor data to and from the hardware and hosts the reactor emulator. A diagram of the input/output flow from the Jetson is shown in Figure 3. A Node-RED data flow visualizes sensor/hardware data and provides a user interface for manual control as well as experimental setup. To manage two-way communication between the hardware (e.g., drums, valves, flow meters) and software layer (control algorithm), I/O boards (QWICC boards) are used for each sensor and control element to convert the command signal to a representative voltage or current and vice versa for the sensor outputs. This architecture provides a controller-agnostic interface to enable rapid additions of new or different types of sensors to the system. The digital architecture setup of the system is shown in Figure 4. More information on the hardware and digital architecture of the mock reactor is given elsewhere [6]. The reactor emulator resides in a docker container on the NVIDIA Jetson and pulls the hardware values from the MQTT broker as inputs. The nuclear reactor emulator outputs a reactor power (based on the hardware inputs) back to the MQTT broker for use by the operator or control algorithm in the next control cycle. An entire control loop iteration (command, hardware move, sensor values, reactor emulator, reactor status) can be completed in 0.1 s (system operates at 10 Hz). Multiple control algorithms and emulators can be run in parallel or in piecewise control (algorithms switch at time or sensor feedback thresholds) on the MQTT broker, the only restriction is the complexity of the emulator or algorithm and its ability to maintain real-time.

4. Nuclear Reactor Emulator

The startup of a nuclear reactor is a dangerous process because the reactor contains excess reactivity and has elevated risk of crossing the prompt-critical threshold. The startup, especially for nuclear thermal rockets, is on a fast scale with some designs having reached full power in as little as 45 s [7]. Sensor feedback on the thermal and neutronics characteristics for the reactor is needed at a millisecond or faster time scale to properly control the reactor during startup. To simulate the reactor behavior in a very short time scale and allow the non-nuclear test bed to run in real time, the reactor emulator for the mock reactor test bed uses a lookup table and the point kinetics equations (PKEs) to calculate the reactivity changes and neutron population/power of the reactor as a function of time. Using Monte Carlo radiation transport codes to calculate the reactor physics would require computationally expensive simulations that would not run in real or even near real time; hence, the lookup table is used. However, Monte Carlo radiation transport codes were used to populate the lookup table and solve for different variables in the PKE equations. A high-fidelity model of the mock reactor test bed was created in the Monte Carlo N-Particle (MCNP) radiation transport code [8]. The dimensions of the reactor and the hardware were input into the model with the addition of a beryllium moderator in the middle of the mock reactor core (green hexagons in Figure 5), embedded with zirconium carbide coated highly enriched uranium nitride fuel (blue cylinders in Figure 5). A diagram of the reactor model is shown in Figure 5. A boron carbide section of the control drums (black crescent in the control drums in Figure 5), along with gaseous orthohydrogen in the flow channels, was also added. The hydrogen density was obtained from the literature [9] based on the temperature and fluid flow into the reactor. The mock reactor dimensions were too small for high-assay low-enriched uranium fuel to produce the reactivity and criticality typical of an NTP reactor, so highly-enriched uranium (HEU) was used in the model. Nonetheless, with the MQTT broker and docker system, a user could easily switch out the lookup tables (or have multiple stored) for the testbed, that represent their reactor design, fuel choice, reactor kinetics, etc.

The reactor lookup tables were generated from numerous high-fidelity MCNP reactor simulations. The output value of the models was a reactivity value for the reactor ($k_{\mathrm{eff}}$). The reactivity values were collected as a function of drum position, reactor temperature, and hydrogen fluid-flow volume. All of the MCNP models were simulated until the ($k_{\mathrm{eff}}$) value had an uncertainty of less than 5 percent. Figure 6 and Figure 7 show the reactivity from the MCNP model for drum position, temperature, and hydrogen flow in the core. The cross sections used in the MCNP models were from the ENDF-8 library. In Figure 7, the data shown is based on the different temperature values listed in the ENDF-8 cross section library (300, 600, 900, 1200, and 2500 K). The cross section for orthohydrogen was used in the core models as the temperature of the hydrogen when it reaches the core puts it in the 3:1 ratio range versus parahydrogen. The reactivity vs. drum angle plot in Figure 6 assumes all drums moved together; smaller reactivity insertions can occur by moving one or a subset of the drums.

The drum reactivity in Figure 6 shows a critical point at ${101}^{\circ }$, assuming all drums are at that position. The positive or negative reactivity added to the core is highest when the control drums are at ${90}^{\circ }$ and lowest at $0^{\circ }$ or ${180}^{\circ }$ due to the geometry of the control drum poison section. As the drums approach ${90}^{\circ }$, only a small portion of the poison section surface area faces the core, so any movement from ${90}^{\circ }$ causes a significant amount of the poison to face the core. By contrast, at $0^{\circ }$ or ${180}^{\circ }$ (fully closed or open), the poison surface area facing the core does not change much with drum movement (hence the shape of the data in Figure 6). For this model, around critical (${101}^{\circ }$), every degree change from the drums corresponds to a significant amount of reactivity—hundreds of per cent mille. Previous space reactor designs, such as NERVA [5] and Topaz-II [10,11], have typically included more drums (12–16), so moving only one or only a subset can produce minor changes in reactivity. Additionally, Topaz-II had a control drum made of stainless steel instead of boron for smaller reactivity insertions and better control near the critical point [12].

In addition to the control drums, temperature and hydrogen flow also contribute positive and negative reactivity in the core (Figure 7). For the drum reactivity calculations in Figure 6, the reactor temperature was assumed to be 300 K and without hydrogen flow (shutdown state); the next set of reactor simulations had the drums exactly at the critical point (${101}^{\circ }$) and changed the temperature and hydrogen density in the core to evaluate the changes in reactivity from temperature and hydrogen flow rate as the rocket starts. As the temperature in the reactor increases, a negative reactivity temperature feedback occurs because the cross sections of the fuel change with increasing temperature. By contrast, as the density of hydrogen increases in the reactor from an increase in flow, a positive reactivity occurs due to the increase in neutron moderation from the hydrogen. Interestingly, if liquid hydrogen enters the core, then a large 8000 PCM reactivity insertion can occur, potentially causing the reactor to go critical with the drums closed or prompt critical in a worst-case scenario. This scenario was observed during one of the NERVA tests: “…we were running a shut-down and too much cold hydrogen inventory was allowed into the core. The result was an engine operating at 250 MW with the drums fully inserted” [2]. The large density of liquid hydrogen relative to hydrogen gas causes a significant increase in neutron thermalization in the core, creating a neutron spectrum that is more likely to fission U-235 causing a rapid positive reactivity in the core. Ensuring that the hydrogen does not enter the core as a liquid is imperative for reactor safety and operation.

For the mock reactor test bed, the control hardware and sensors (drum position and flow conditions) communicates their physical data to the MQTT broker on the NVIDIA Jetson. The lookup tables and PKEs (nuclear reactor emulator) sit in a docker container on the NVIDIA Jetson and pull the hardware values from the MQTT broker as inputs. The reactivity is interpolated from the lookup tables for the control drum position, temperature, and fluid flow. Once a total reactivity value has been determined from the lookup tables (drum reactivity − temperature reactivity + $H_2$ flow reactivity), it is inserted into the inhour equation to determine the reactor period. The reactor period is the time required for the neutron density to change by a factor of e. The inhour equation is shown in Equation (1):

$$\rho ={\displaystyle \frac{l^{*}}{T_p}}+\sum {\displaystyle \frac{{\beta }_{\mathrm{eff}}}{1+\lambda T_p}},$$

(1)

where $\rho$ is the reactivity from the lookup table (calculated from high-fidelity Monte Carlo radiation transport models), $T_p$ is the reactor period (to be solved for), $l^{*}$ is the neutron generation time, ${\beta }_{\mathrm{eff}}$ is the fraction of the delayed neutrons, and $\lambda$ is the precursor decay time. Using the MCNP model of the reactor, many of the variables ($l^{*}$, ${\beta }_{\mathrm{eff}}$, $\lambda$) were calculated for in the model and used in the equation. When solving for reactor kinetics as a function of time, the point kinetic equations yield an ordinary differential equation in regards to the neutron population as a function of time (see Equation (2)). The general solution to the PKE equation for neutron population is given in Equation (3) and is a function of the reactor period.

$${\displaystyle \frac{dn}{dt}}={\displaystyle \frac{\rho \left(t\right)-\beta }{\mathrm{\Lambda }}}n\left(t\right)+\sum \lambda C\left(t\right)$$

(2)

$$n\left(t\right)=n_{0}exp\left({\displaystyle \frac{1}{T_p}}\right)$$

(3)

Solving for the reactor period using the inhour equation and using the general solution for neutron population, the reactor power behavior can be solved for analytically and computationally expediently. The neutron population output is converted into a reactor power (fission rate), which is sent back to the MQTT broker for the control algorithm to use in the next control iteration cycle.

To test the emulator and the hardware in the control loop system, a simple pre-determined control script was loaded and a 5 min run was executed. The script moved the drums in a predetermined movement to ramp the reactor up to 10 MW, with a hold in power, and then a ramp up to 100 MW with a hold in power, before a shutdown. The reactor power of the mock reactor along with the drum angle versus $K_{\mathrm{eff}}$ of the reactor as a function of time can be seen in Figure 8.

The negative reactivity temperature feedback of reactor system can be seen in Figure 8 as the control drum angle for criticality changes as the reactor increases in power and temperature. The emulator processing speeds currently limit the control loop to 10 Hz even though most of the sensors have a refresh rate in the hundreds to thousands of hertz range. Ongoing efforts are considering methods to accelerate emulator calculations to maintain real-time simulation at higher system cycle rates (100 Hz or faster). This initial test of the mock reactor system was successfully using a pre-defined script for the reactor controls, however, manual controls and full autonomous control tests will be conducted in future research efforts.

Future work on the emulator will focus on the addition of fuel burnup and fission product burn-in reactivity calculations. During reactor operations, fuel depletion and the inclusion of fission products, notably xenon, can cause a significant decrease in core reactivity. To account for this negative reactivity inclusion, a lookup table is being developed to produce a burn time vs. reactivity vs. time element to the emulator and add another layer of realism to the test bed. Xenon poisoning in a NTP reactor will not likely be an issue, due to the short 10–30 min reactor operation duration during a burn but but will have a significant effect when trying to restart the reactor after shutdown. Furthermore, in a real NTP and FSP system, fission chambers and ion chambers would record the neutron flux and produce an estimated reactor power. The determination of the reactor power by ion and fission chambers is complicated when the reactor is started in orbit or in deep space. Most NTP flight plans have the engine starting at a nuclear safe orbit, which is above 1100 km in altitude. This orbit puts it directly in the lower Van Allen belt where high-energy protons (up to 700 MeV [13] ) will likely induce a high background rate in the ion and fission chambers. During reactor startup, neutron levels in the core will be low (small signal in ion and fission chambers) during the approach to critical, and elevated background levels in the detectors for the space radiation will likely cause significant issues and uncertainty during startup. Future work on the mock-reactor will include simulating the neutron detectors, so that different placements of the detectors in and around the reactor along with different background rates can be added to add realism and test the ability of the control algorithms to start the reactor in space. Lastly, decay heat is calculated in the emulator (see Figure 8), and so tests of a control algorithms ability to maintain temperature of the reactor after reactor shutdown and during coasting using the propellant system would be intriguing.

5. Conclusions

To support NASA’s mission to use autonomous controls for nuclear thermal rockets for future Mars missions, an instrumentation and control test bed has been built at ORNL. The system is designed to test control elements and autonomous control algorithms for NTP rockets by employing a hardware-in-the-loop scheme. The non-nuclear reactor test bed consists of control element hardware (e.g., control drums, valves, turbomachinery) connected to a control algorithm via a MQTT broker that is housed on a single-board computer (NVIDA Jetson). The reactor performance is simulated by a reactor emulator that uses the physical data from the test bed as inputs to a reactor reactivity lookup table. The reactivity values from the lookup table are input into the PKE equations that determine the reactor power behavior as a function of time. The reactor emulator sends the reactor power data back to the MQTT broker for the control algorithm to use for the next control cycle iteration. This test bed will enable NASA and other space vendors to rigorously test their autonomous control systems for NTP rockets under transient (reactor startup and shutdown), steady-state, and fault conditions. In conclusion, a hardware-in-the-loop testbed has been built for nuclear thermal rockets to reduce development time and risk for autonomous control systems in future missions.