Modernising Nuclear Instrumentation & Control: Going Digital Without Compromising Safety

Analogue instrumentation in the operating reactor fleet is reaching the end of its supportable life. Components are no longer manufactured, drift and calibration burden grow, and the engineers who understood the original designs are retiring. Digital replacement is necessary. It also introduces a failure mode analogue systems did not have, and the entire regulatory apparatus around nuclear I&C modernisation exists to address that one thing.

The problem digital introduces: common cause failure

Analogue redundancy fails independently. Four identical analogue channels drift, degrade and fail for reasons rooted in individual component variation, so a fault in one carries little information about the others. Statistical independence is a reasonable assumption, and it is the assumption redundancy math depends on.

Identical software does not fail independently. Four channels running the same code, given the same inputs, produce the same defect at the same instant. Redundancy that protects perfectly against random hardware failure provides no protection at all against a software fault, and this is the central engineering concern in every digital I&C upgrade.

That structure is the whole argument. Adding a fifth identical channel reduces the quadratic term and leaves the linear one untouched. If β is significant — and for identical software it is, at the limit, unity — additional identical redundancy buys essentially nothing. The only lever that moves the dominant term is diversity.

Diversity, and what actually counts as diverse

Regulatory guidance requires an analysis demonstrating that a postulated software common cause failure in the protection system does not defeat the ability to reach a safe state. In practice this means a diverse means of actuation implemented differently enough that a shared defect is not credible.

Why FPGA-based I&C has gained ground

A microprocessor-based safety system carries an operating system or executive, a scheduler, interrupt handling, and a memory model — all of which must be qualified, and none of which exists to perform the safety function. The verification burden is dominated by infrastructure the application does not need.

An FPGA implementation of the same logic has no instruction stream, no scheduler and no shared memory. The logic is spatial rather than sequential: each function occupies its own gates and executes concurrently, so timing is fixed by propagation delay rather than by execution order. There is no interrupt latency to bound, no priority inversion, and no scenario in which one function starves another.

• Deterministic by construction — response time is a hardware property, not a scheduling outcome.
• No operating system to qualify, which removes the largest single block of code from the verification scope.
• Concurrent execution, so functional independence can be physically demonstrated rather than argued.
• A tractably small design that can be exhaustively verified — for finite logic, formal methods can prove properties rather than sample behaviours.
• Excellent technology diversity against a microprocessor-based primary, since the toolchains and failure mechanisms share almost nothing.

The trade is real: FPGA designs are harder to modify, the hardware description toolchain itself must be qualified, and complex functions are more awkward to express than in software. For the highest safety category — the reactor trip function, where the logic is comparatively simple and the verification demand is extreme — the trade is generally favourable, which is why diverse FPGA-based protection has become a common architecture.

Categorisation drives everything downstream

IEC 61226 sorts I&C functions into categories A, B and C by their safety significance, and the category determines the applicable standard, the qualification effort and the permissible design practices. Category A — functions required to reach and maintain a safe state — attracts the full weight of IEC 60880, including constraints that read as severe to engineers from other domains and are entirely deliberate.

• No dynamic memory allocation after initialisation — heap exhaustion and fragmentation are not analysable.
• No recursion, and statically bounded loops, so worst-case execution time and stack depth are provable rather than measured.
• No interrupts in the safety path where cyclic execution can be used instead, removing an entire class of timing non-determinism.
• Defensive programming with explicit range checking on every input, and a defined safe response to every out-of-range condition.
• Full requirements-to-code-to-test traceability, with independent verification and validation by an organisation separate from the developers.

The cost consequence is that scope discipline is the largest lever on project economics. Every function allowed to drift into category A carries category A verification cost. Rigorous categorisation at the start — and an architecture that keeps non-safety functions physically and logically separated from safety ones — determines the budget more than any technology selection.

Isolation between safety and everything else

Operators want data from the protection system for monitoring, and that requirement is legitimate. It must not create a path by which anything can affect the protection system. The accepted solution is unidirectional communication enforced in hardware — a data diode with no physical return path — so the safety division can publish while remaining unreachable.

Qualification extends well beyond function. Equipment must be shown to perform under the environmental conditions it will face: seismic qualification by shake-table testing to the site's design basis, electromagnetic compatibility against both the plant's own noise and external interference, and environmental qualification for temperature, humidity and radiation. A digital device that meets every functional requirement and fails EMI qualification is not installable, and discovering that late is one of the more expensive outcomes in this domain.

The disciplined sequence

Successful modernisations follow a consistent order: categorise functions rigorously and resist scope drift; choose an architecture whose diversity argument holds against a postulated software common cause failure; select technology per category rather than standardising across the plant; qualify equipment early, because environmental testing has long lead times and no shortcuts; and engage the regulator on the diversity and defence-in-depth analysis before the design is fixed rather than after. The technical work is well understood. The programmes that overrun are almost always the ones that treated the licensing basis as a documentation exercise to be completed at the end.