Requirements and constraints

Grant Whitford's question, whether a reactor could replace most of the campus gas, is not yet something a team can design to. “Most” could mean half or nine-tenths. “Replace” could mean the reactor runs all year or only in winter. Nothing in the question says how safe, how quiet, how cheap or how soon. Hana's first deliverable is a requirements document that turns the question into statements the team can design against and, at the end, verify. She books two sessions with Grant and one with Rohan, and asks each team member to bring the requirements their own area will need.

This lesson shows how stakeholder needs become engineering requirements, how requirements are written so they can be verified, and how constraints differ from requirements. It works through the campus heat demand to choose the reactor's thermal power, sets out the safety, regulatory and interface requirements for Kestrel-10, and introduces the requirements traceability matrix that links each requirement to the analysis that will show it is met.

From needs to requirements

Stakeholders describe what they need in their own terms. The facilities director needs heat delivered reliably at the temperature the buildings require, at a cost the university can justify, with less carbon than gas. The university's senior leadership needs a project that does not expose the institution to unacceptable financial or reputational risk. Students and faculty want a facility for teaching and research. Neighbours and the wider public need assurance that the reactor is safe and that they will be told what is happening. The regulator needs a design that meets its requirements and an applicant able to operate it safely.

A requirement is a statement of what the system must do or be, written so that a test, analysis, inspection or demonstration can show whether it is met. Good requirements share a few properties. Each says one thing. Each is necessary, in that removing it would leave a stakeholder need unmet. Each is verifiable, which rules out words like “adequate”, “minimize” or “user-friendly” unless they are tied to a measurable criterion. Each is feasible as far as anyone can tell at the time. And each is free of design: “the core shall be cooled by natural circulation” is a design decision, while “the reactor shall remove full-power heat from the core without relying on pumps” is a requirement that natural circulation might meet.

In practice the line between requirement and design choice moves as a project develops. At the concept stage the team keeps requirements as solution-neutral as possible, so that different concepts can be compared fairly. After concept selection, some design decisions become requirements on the subsystems: once the team has chosen a pool reactor, “the pool water above the core shall be at least 9 m deep” becomes a requirement on the civil design, derived from the shielding analysis.

Sizing the reactor from the heat demand

The most important performance requirement is the thermal power, and it comes from the campus heat demand. Space heating load depends on the difference between indoor and outdoor temperature; domestic hot water, laboratories and kitchens add a base load that runs all year. Without metered hourly data, the team builds a model: the heating load is a base load plus a building heat-loss coefficient multiplied by the difference between 18 °C and the outdoor temperature, whenever the outdoor temperature is below 18 °C. The coefficient is calibrated so that the model reproduces the university's annual gas consumption, and the outdoor temperature follows an annual cycle with a daily swing, fitted to the climate normals for Thunder Bay.

Sorting the 8,760 hourly loads of a year from highest to lowest gives the load duration curve. The area under the curve is the annual heat demand, and the curve shows immediately how much of it a supply of a given size can meet. A reactor that runs at constant output P supplies the area under the curve but not above the horizontal line at P; the hours above the line, which are the coldest hours of the year, must be supplied by something else, in this case the existing gas boilers kept as peaking and backup units.

# Campus heat load duration curve and how much of the annual heat a reactor of a given size can supply.
# Hourly outdoor temperature is modelled as an annual cosine plus a daily swing (an illustrative climate).
import math
T_MEAN, T_AMP, T_DAY = 2.5, 16.0, 5.0    # annual mean, annual amplitude, daily half-swing (deg C)
BASE = 2.2           # MW: domestic hot water, labs, kitchens (all year)
UA = 0.255           # MW per K of (18 C - outdoor) heating demand
T_DESIGN = -31.0    # design outdoor temperature (deg C)
loads = []
for h in range(8760):
    day = h / 24
    T = T_MEAN - T_AMP * math.cos(2 * math.pi * (day - 20) / 365) - T_DAY * math.cos(2 * math.pi * (h % 24 - 3) / 24)
    loads.append(BASE + UA * max(0.0, 18 - T))
peak_design = BASE + UA * (18 - T_DESIGN)
annual = sum(loads)                                   # MWh (1 h steps)
loads.sort(reverse=True)
print(f"peak hour in model year: {loads[0]:.1f} MW; design-day peak: {peak_design:.1f} MW")
print(f"annual campus heat: {annual / 1000:.1f} GWh; average load {annual / 8760:.1f} MW")
for hrs in (0, 500, 2000, 4380, 6000, 8000, 8759):
    print(f"  load exceeded for {hrs:5d} h: {loads[hrs]:5.1f} MW")
print(f"{'reactor (MWt)':>14s}{'heat supplied (GWh)':>21s}{'share of campus heat':>22s}{'capacity factor':>17s}")
for P in (4, 6, 8, 10, 12, 14):
    supplied = sum(min(P, L) for L in loads) * 0.93   # 93 % availability (refuelling and maintenance)
    print(f"{P:14d}{supplied / 1000:21.1f}{supplied / annual:22.0%}{supplied / (P * 8760):17.0%}")

peak hour in model year: 11.5 MW; design-day peak: 14.7 MW
annual campus heat: 54.5 GWh; average load 6.2 MW
  load exceeded for     0 h:  11.5 MW
  load exceeded for   500 h:  10.7 MW
  load exceeded for  2000 h:   9.0 MW
  load exceeded for  4380 h:   6.2 MW
  load exceeded for  6000 h:   4.0 MW
  load exceeded for  8000 h:   2.2 MW
  load exceeded for  8759 h:   2.2 MW
 reactor (MWt)  heat supplied (GWh)  share of campus heat  capacity factor
             4                 29.6                   54%              84%
             6                 39.3                   72%              75%
             8                 46.3                   85%              66%
            10                 50.0                   92%              57%
            12                 50.7                   93%              48%
            14                 50.7                   93%              41%

The results show the central trade-off of the project. A 4 MWt reactor would run at a high capacity factor, about 84 percent, but would supply only about half the campus heat. A 10 MWt reactor supplies about 92 percent of the heat, but its capacity factor falls to 57 percent, because for much of the summer the campus needs only a fifth of its output. Beyond 10 MWt, the extra capacity supplies almost nothing, since availability rather than size then limits the share. The team writes the performance requirement as a share of heat, at least 85 percent, which an 8 MWt unit would just meet, and chooses 10 MWt to allow for campus growth, for the margin between modelled and metered loads, and for the research uses that need a higher neutron flux. Grant notes that the low summer capacity factor will hurt the economics, and asks the team to look later at summer heat customers.

Temperatures and the interface with the campus network

Heat is only useful at the temperature the buildings need. Most of the campus network was built decades ago to run at 90 to 110 °C, which suited gas boilers. A low-pressure pool reactor cannot reach those temperatures without pressurizing its pool or boiling its water, so the interface requirement becomes a negotiation. Grant confirms that the university is already converting buildings to low-temperature hot water, at 65 to 70 °C supply and about 40 °C return, because that improves the efficiency of every heat source, including heat pumps. The team writes the interface requirement as a supply temperature of at least 65 °C at the campus heat exchanger, with the existing boilers able to boost temperature on the coldest days.

A second interface requirement protects the campus from the reactor. Water that passes through the core becomes slightly radioactive, mainly from short-lived activation products, and may carry traces of corrosion products and, if a fuel rod leaked, fission products. The design must ensure that no primary water can reach the campus network. The usual solution, and the one the team specifies as a requirement rather than a design choice, is an intermediate loop between the pool and the campus network, with the campus side at a higher pressure than the intermediate loop so that any leak in the campus heat exchanger flows towards the reactor, not away from it. Radiation monitors on the intermediate loop detect any leak from the pool heat exchanger.

Safety requirements

Every reactor must perform three fundamental safety functions under all conditions: control reactivity, remove heat from the fuel, and confine radioactive material. The team's safety requirements are written as quantitative targets for each function, set at the concept stage so that the design can be judged against them. Some come straight from regulatory expectations; others are the team's own targets for a reactor that will sit in the middle of a campus, which it sets more strictly than the minimum.

For reactivity control, the team requires a shutdown margin of at least 1,000 pcm with the most reactive control rod stuck fully out, in the cold, xenon-free state where the core is most reactive, and it requires the moderator temperature and void coefficients to be negative in every operating state. For heat removal, it requires that full-power heat be removed from the core without pumps, and that decay heat be removed without electrical power or operator action for at least seven days. Seven days is longer than most power reactor designs require, but the team argues that a campus reactor should allow for the time needed to bring help from elsewhere after a severe winter storm. For confinement, it requires that no nucleate boiling occur anywhere in the core at full power, with a margin of at least 10 K, which keeps the fuel cladding far from its limits and makes the core behaviour simple to analyse.

Probabilistic targets complete the safety requirements. The team adopts a fuel damage frequency below one in a hundred thousand per reactor-year and a large release frequency below one in a million, figures similar to those used for new power reactors. For a reactor of 10 MWt with a large pool and low power density, Rohan expects the design to beat these targets by a wide margin, but writing them down forces the team to show it.

Radiation protection and siting requirements

Canadian dose limits are set by the Radiation Protection Regulations: 50 mSv in a year and 100 mSv over five years for nuclear energy workers, and 1 mSv per year for members of the public. Designs are expected to keep doses far below these limits, as low as reasonably achievable. The team sets design targets of 0.5 µSv per hour in areas the public can enter, 10 µSv per hour in routinely occupied controlled areas and a public dose from normal operation of less than 0.05 mSv per year at the site boundary. A further requirement, which turns out to drive the layout, is that the emergency planning zone should not extend beyond the campus, so that no off-campus protective actions would need to be planned for any credible accident.

Siting constraints come from the campus itself. Grant identifies a site at the edge of the campus next to the central heating plant, where the reactor building could connect to the existing network and where a security fence could be built without closing roads. The site is close to student residences and a hospital, which makes the low-dose and small emergency planning zone requirements essential rather than desirable. The team also records the geology, which allows a reactor building partly below grade, and the external hazards it will have to consider: winter storms, flooding, a gas pipeline that supplies the heating plant, and aircraft from a nearby airport.

Regulatory, schedule and cost requirements

The regulatory requirement is that the design must be licensable by the CNSC under the existing framework, which means the team must identify the applicable licences, the regulatory documents the design must meet and the main pre-licensing steps. It does not mean the team will prepare a licence application; the capstone shows that a credible route exists. A further requirement, added after Nikolai's first research, is that the project must respect the Crown's duty to consult Indigenous peoples whose rights could be affected, which for a site in Thunder Bay includes Fort William First Nation.

Schedule and cost requirements come from the university's own planning. The gas boilers will need replacing within about ten years, so a reactor that could not supply heat by then would have to be justified on other grounds. The cost requirement is written carefully. The team does not promise that nuclear heat will be cheaper than gas, because it has no basis for that yet. Instead it requires that the levelized cost of heat be estimated with stated assumptions and compared with gas-fired heat, including a range of carbon costs, so that the university can see what it would be paying for the reduction in emissions.

Traceability

A requirements traceability matrix links each requirement to its source, to the design features that address it and to the analysis that verifies it. It works in both directions. Forward traceability ensures that every requirement is addressed somewhere in the design; backward traceability ensures that every design feature exists for a reason. Hana keeps the matrix as a table with one row per requirement. At the concept selection gate, the verification column will be empty for most rows; by the final design review, every row should point to a section of the report and a calculation package.

Traceability also controls change. When a requirement changes, the matrix shows which design decisions and analyses depend on it and must be revisited. When the team later changes the core inlet temperature to gain boiling margin, the matrix shows that the change affects R-01, because the campus supply temperature depends on the pool temperature, and Hana checks that the campus network can still be supplied at 65 °C before the change is accepted.