SMR - modelling, safety and design justification

A project SMR has neither operational feedback nor a reference model inherited from a prototype. The design demonstration therefore relies on simulation tools that must be built and then defended before the safety authority. The choice of tool is not merely an internal technical detail: it conditions the ability to justify the results.

We develop these models in Modelica, in an open-source environment. The transparency of the equations facilitates review and instruction, the absence of a per-user license allows the models to be shared with all your teams, and independence from a vendor prevents a commercial evolution from jeopardising your calculation chain during the project.

This transparency is also what makes qualification achievable. We have carried out this approach on our own thermo-aerodynamic library, qualified in accordance with guide no. 28 of the ASN, with theoretical note, component validation, reference cases, and non-regression tests. The method is directly transposable to the tools developed for your project.

A system model is not intended to replace your business codes. Exporting to the FMI standard allows us to couple our models with your neutronics, thermohydraulics, or control-command tools, and to keep each discipline within its reference environment. Our models are also driven by scripts, from case generation to post-processing, which makes the calculation campaigns reproducible and traceable.

Our tool qualified for thermo-aerodynamic studies >

SMR sectors use heat transfer fluids and equipment for which there is neither universal correlation, nor ready-made library, nor manufacturer curve. A supplier cannot guarantee the behaviour of a component that they have never produced under these conditions, and literature data rarely covers the targeted operating range.

We implement the necessary physical properties and exchange laws by clarifying their validity range, a condition for the model to remain defensible in instruction. This clarification is as valuable as the result: it delineates what the model demonstrates and what it does not demonstrate.

The behaviour of an innovative piece of equipment cannot be evaluated in isolation. Modelling it within a complete system, with thermal and hydraulic couplings and regulations, allows for the verification of its behaviour at various critical operating points as well as its sensitivity to boundary conditions. This approach justifies the use of such equipment when it provides a measurable gain, or demonstrates that a conventional solution is sufficient to avoid unnecessary qualification difficulties.

Passive safety architectures concentrate this difficulty. Thermosiphon, natural circulation, discharge to an ultimate cold source: these are precisely the configurations where simplifying assumptions hold the least. A fixed exchange coefficient, deemed conservative, can either mask a margin or destroy it. We model these phenomena at the level of detail necessary for the announced margin to be a physical margin.

The architectural choices made in the early phases determine the bulk of the cost and demonstrability of the project, while they are made with the least information available. Revisiting them later is much more expensive than addressing them correctly from the start.

We are neither equipment suppliers, nor software publishers, nor candidates for implementation. Our analysis simultaneously addresses performance and safety, and incorporates a criterion often dealt with too late: the complexity of qualifying a specific piece of equipment. An elegant architecture but based on a component impossible to qualify within the project timeline is not a viable architecture.

Our team has built its experience on the French nuclear fleet and EPR projects: accident studies, safety reports, equipment qualification, instruction. This knowledge of the reference framework allows us to anticipate the expectations of the instruction at the time of the architecture choice, rather than discovering them during the compilation of the file.

Architecture comparisons are conducted on the same models and the same criteria, in order to produce quantified discrepancies rather than qualitative assessments. The deliverable provides the dimensioning quantities, the associated margins, and the points of vigilance for each variant.

Accidental transients, support function losses, breach scenarios, or mass-energy calculations form the core of the safety demonstration. An envelope approach, which considers the total available energy as instantaneously released, certainly exaggerates the phenomenon, but leads to very penalising demands and an oversizing of protection devices.

Dynamic modelling reproduces the real kinetics of the phenomena: thermal transfers, structural inertias, progressive evolution of conditions. It allows for the distinction between physical margins and conservatisms related to calculation assumptions, and optimises the sizing while maintaining the necessary margins for safety.

We write the calculation and justification notes intended for the file, and we also carry out independent reviews of existing notes. When the context requires it, part of the verification work can be conducted within our clients' quality system, so that the relevant chapters are signed off in verification.

These works are part of schedules that are non-negotiable, particularly when preparing a request for authorisation. We then organise production in such a way as to have usable results early on in terms of magnitude, and then to consolidate them, rather than delivering a complete file too late to be processed.

In an SMR project, input data is not a prerequisite: it stabilises gradually, often following the initial studies. Waiting for fixed values means never starting, and undertaking a study on provisional data exposes one to having to redo everything at the first change.

We address this situation through sensitivity studies. Rather than a single value, we explore plausible ranges to identify the parameters that are truly dimensioning and those that have no influence on the result. This information usefully guides design efforts and data requests from suppliers.

The structure of the models addresses the second point. Parameterised models, automated calculation campaigns, and configuration management under Git allow for the implementation of a design or interface evolution by restarting the study, without having to rebuild it. A modelling cannot be perfect, but it can be designed to evolve at the pace of the project.

We are ourselves a young company, and we understand the constraints that come with it: short milestones, budgets to arbitrate, and shifting scopes. Our support is scaled accordingly, from a few days to unblock a bottleneck to regular assistance over the duration of a phase, with a single technical contact and a transfer of the models to your teams.