Perils of Precedent in Nuclear Software Qualification

Authors

  • Dr. Fred Pollard Rolls-Royce SMR Limited
  • Martin Rendell Rolls-Royce SMR Limited
  • Dan Finnigan Rolls-Royce SMR Limited

Keywords:

software assurance, Nuclear Industries, independent assessment

Abstract

This paper examines the continuing use of the United Kingdom nuclear industry’s current precedent in the qualification of software and programmable logic used in nuclear control and instrumentation systems.  In this context, software qualification has conventionally relied on a two-legged argument comprising “production excellence” and “independent confidence-building measures” (the latter including independent static analysis, independent dynamic analysis, and statistical testing).  Drawing on precedent from Sizewell B and subsequent UK nuclear practice, this paper argues that these measures have too often become in-effect “prescribed” techniques rather than measures selected to answer a clearly stated safety question.  This paper reviews the claimed contribution of these techniques to safety and confidence-building, considering their practical and technical limitations, their dependence on developer interpretation, their cost and schedule implications, and their effect on through-life modification.  It concludes that post hoc re-verification of completed software can provide little additional safety benefit where modern standards-based development, verification, validation, and independent functional safety assessment have already been performed, and may inhibit future safety improvements to a system by making modification disproportionately difficult.  The paper proposes a possible alternative approach to software qualification, but notes that until the goal of qualification is determined, it is not clear how to assess the validity of any qualification performed above and beyond that which is prescribed by international standards.

Block diagram illustrating relationships between roles.  The Licensee instructs the Developer and the Analyst who provide artefacts and findings, respectively.  For efficient working the Analyst may also request information directly from the Developer, who provides responses.  The Licensee should monitor this exchange and cause it to be documented.  If anomalies are detected, the Licensee makes the fix/no fix decision.

Downloads

Published

2026-10-13