Management of Engineering and Safety Knowledge Along Reactor Lifetime

Management of Engineering and Safety Knowledge Along Reactor Lifetime

Thuy NGUYEN

EDF

ABSTRACT

Often, current engineering approaches for nuclear power plants (NPPs) are still very similar to those put in place decades ago. Such approaches might have been adequate in the past, where regulatory and operational requirements were less stringent than they are today. They may still be adequate for evolutionary designs, where a proven-in-use design is improved but not radically modified. They are not optimal for innovative designs such as highly manoeuvrable reactors, hybrid reactors (combining production of electric power with other uses of energy to cope with demand variations), SMRs (Small Modular Reactors) or Gen IV reactors. In particular, engineering and safety knowledge could be better structured and systematic, and specific information easier to retrieve and understand. The approach proposed in this paper combines and takes advantage of research work currently being done at EDF R&D on several subjects: the engineering of complex systems (typically, cyber-physical or even socio-cyber-physical systems, and systems of systems), the design of innovative reactors, and safety justification.

Key Words: Systems engineering, Complex systems, Modelling, Simulation, Safety justification, Regulatory requirements, Traceability

1 INTRODUCTION

Nuclear power plants (NPPs) are subject to extremely stringent and ever increasing constraints covering a wide range of issues: safety (particularly after majors accidents have shaken public confidence), security and computer security, cost (for design, construction, operation, renovation and deconstruction, particularly in the light of cheap or subsidized alternative sources of energy) and operation (with, increasingly, the need to take into account a high percentage of intermittent renewables in the energy mix).

In many cases, current engineering approaches for NPPs are still very similar to those put in place decades ago. Such approaches might have been adequate in the past, where constraints were less stringent than they are today. They may still be adequate for evolutionary designs, where a proven-in-use design is improved but not radically modified. They tend to beless than optimal for innovative designs such as highly manoeuvrable reactors, hybrid reactors (combining production of electric power with other uses of energy to cope with demand variations), SMRs (Small Modular Reactors) or Gen IV reactors. In particular, engineering and safety knowledge could be better structured and systematic, and specific information easier to retrieve and understand.

2General Approach

This paper proposes anapproach that combines and takes advantage of three complementary elements:

• Safety & security requirements from national regulations and international standards are essential inputs. Their interpretation and reconciliation (when coming from different sources) are a challenge. The proposed approach first relies on a database organising and clarifying all applicable requirements.
• An NPP is a complex system that requires the cooperation of many engineering teams and disciplines covering a very wide range of topics and the complete lifetime of the plant, from initial prospective studies (to determine the main plant characteristics) to deconstruction. Thus, the approach also relies on high level, formal assumptions, requirements and behavioural modelling, facilitating teams coordination and enabling massive simulation for design verification and operator assistance.
• Lastly, the approach integrates a Claim-Argument-Evidence justification framework: whereas the formal modelling of the previous bullet represents objective engineering goals and facts, this framework organises and structures human reasoning and subjective judgement.

3Regulatory & Standard Requirements

The design, construction and operation of an NPP are in a very large part guided and constrained by safety and security considerations. Many international standards and guides regarding these issues have been developed by bodies such as the IAEA (International Atomic Energy Agency), the IEC (International Electrotechnical Commission) and the IEEE (Institute of Electrical and Electronics Engineers), some specific to NPPs, others (like IEC 61508) not. Even though these standards bodies makeefforts to coordinate their works, the current set of documents does not, by far, constitute an integrated whole: each body has its own way of organising a given topic into documents, and documents from a given body are often difficult to relate and compare with those of other bodies. Sometimes, even the approaches and principles are different, making comparison even more difficult.

In addition to international standards, most countries with NPPs have developed nuclear specific national regulations and guidelines. Like for international standards, national documents are organised and follow principles that differ from country to country. Also, the same international standard can be interpreted differently in different countries. Here again, there are ongoing harmonisation efforts, with bodies such as MDEP (Multinational Design Evaluation Programme) or WENRA (Western European Nuclear Regulator Association). However, the nuclear industry is still far from the level of agreement and consensus reached by other industries such as the aviation industry, and a plant design accepted in one country may very well be rejected by another.An NPP designed for construction and operation in a single country already faces a significant challenge understanding and meeting the requirements and practices of that country. NPPs designed for international markets face an even greater challenge.

The approach proposed can be decomposed into the following steps:

• Determination of the country (or countries) of interest for a given project, and of the standards and the international consensus bodies to be taken into consideration.
• Collection the corresponding regulatory, standard and consensus documents. Sometimes, national practices also need to be collected: what has been required, or on the contrary rejected, in recent projects.
• Extraction, from these documents, of the significant statements, in particular ofindividual definitions, requirements, recommendations and practices.
• Organisation of these statements into a structured database for easy retrieval of all the statements concerning a specific topic (e.g., defence in depth or data communication), country, engineering discipline (e.g., I&C or human factors), safety class, etc. The database can also facilitate the retrieval of statements a given level of "urgency" (e.g., requirements vs. recommendations, or safety vs. safety related). One can then determine which of these statements will be considered as design requirements. This will in general include all regulatory requirements, but can also include many if not all standard requirements, and a number of recommendations and practices (which are often de facto requirements).
• Development of unambiguous rules for engineering and operation,covering the selecteddesign requirements. As previously noted, many are expressed in general terms and allow different interpretations. Also, as they come from different sources and may address similar goals using different terms, concepts or solutions, the rules provide an interpretation that is easier to manage by the subsequent engineering activities.
• Justification that compliance to these rules implies compliance with the original design requirements collected in the database. This justification can be organised as proposed in Section 5 Justification Framework.

When the plant progresses in its lifecycle, one will need to justify that its design, constructionand operation are indeed in compliance with the rules. Sometimes, exceptions with respect to the rules might be necessary. Then, one will need to provide a direct justification that these exceptions are indeed consistent with the original requirements (see Figure 1).

Figure 1. Justification of the NPP with respect to regulatory and standard requirements.

4Advanced modelling for the Engineering of Complex Systems

A complex system can be defined as a system that cannot be fully understood and mastered in all necessary aspects and to the necessary degree by a single individual or from the standpoint of a single discipline. On the contrary, it needs the cooperation and coordination of many disciplines and teams covering a very wide range of topics, from so-called "hard sciences" (such as physics, materials, civil engineering and computer engineering) to "softer sciences" (such as psychology and sociology). Coordinating these disciplines and their many teams is a difficult but essential issue, but as different disciplines often rely on specific concepts, terms and tools, they tend to have difficulties understanding one another.Even teams that practice the same discipline may have difficulties coordinating with one another: too much coordination could lead to paralysis; too little rapidly leads to chaos. Thus, the essence of systems engineering for complex systems is the art of coordinatingmany teams and very different disciplines just as necessary (see Figure 2).

Figure 2. A neutral coordination ground for the teams & disciplines working on the system.

Coordination is not only necessary at specific instants in the lifetime of an NPP: it is also necessary to ensure it over the lifetime, so that the engineers and operators of the future will know and understand the principles that guided the design of the plants, and the details necessary for correct and safe operation, retrofit, renovation and upgrade.

Together with a number of other industrial organisations, tool providers and academic and scientific bodies, EDF R&D is developing an innovative approach for the engineering of complex systems. This approach is based on the modelling and simulation of the dynamic phenomena affecting such systems, covering their complete lifecycle from prospective studies aiming at defining the nature and scope of a system to be developed, down to system operation and maintenance, retrofits and modification (see Figure3).

Figure 3. Coverage of the system lifecycle

The methodology is based in a large part on the FOrmal Requirements Modelling Language (FORM-L) that has been specified in the framework of the ITEA2 project MODRIO. Its scope is the formal modelling of properties, in particular of requirements and assumptions, in the form of envelopes of dynamic, time-dependent phenomena (see Figure 4). Formal here means that the properties have rigorous syntax and semantics that can be interpreted by software tools to actively support a variety of systems engineering activities.

Figure 4. Individual trajectories, versus envelopes allowing multiple trajectories.

The approach aims at the following objectives:

• Multi-aspect modelling, covering the needs of various disciplines such as physics, instrumentation and control, human behaviour, costs and revenues analyses, operations and maintenance, probabilistic analyses, complex tasks scheduling (e.g., for outages), etc. Each discipline can still use its methods, tools and models of choice, but it expresses its assumptions and its needs regarding the other disciplines in FORM-L, generally in the form of formal contracts.
• Multi-phase modelling all along system lifecycle, to allow step-by-step verification and validation and toreconcile safety and dependabilitywith innovation. In particular, even for a given discipline, the system may be represented by different models, each representing different stages of development or operation. The first models represent preliminary and high-level views, and can be expressed as FORM-L envelopes. The subsequent ones represent more detailed views of the solutions chosen, and can be expressed either in FORM-L or in discipline-specific formats.Bindings allow information exchange between FORM-L models and non-FORM-L models.
• Multi-aspect and multi-phase modelling provide powerful means for the management of size and complexity. It can provide a complete view of the system, but also focused views on specific issues or subsystems. In particular, the formal modelling of contracts can help understand the complex webs of interdependencies between disciplines and between subsystems.
• Massive simulation in order to efficiently explore many different normal and failure situations. Tools are currently being developed at EDF to automatically generate test cases that are consistent with the assumptions modelled in FORM-L, to automatically verify the satisfaction of requirements also modelled in FORM-L, and to enable co-simulation of FORM-L models with non-FORM-L models. Simulation can also be a very effective help in the understanding of complex models and systems, and can be used for training or for what-if analyses.
• Formal analysis, in favourable cases, to verify that in all modelled situations and under the specified assumptions, the specified requirements will be satisfied.
• The ability to efficiently assess a solution with respect to specified assumptions and requirements means that at each step in the development of solutions, one can explore multiple options (including innovative ones), eliminate those that do not meet the requirements, and then select the best remaining one(s) for the next steps.

5Justification FrameworkS

An assurance case can be defined as a documented body of evidence that provides a convincing and valid argument that a specified set of critical claims regarding a system's properties are adequately justified for a given application in a given environment. Initially, they have been applied mainly to safety cases, but they are now applied to security cases and to cases for business critical systems. ISO/IEC/IEEE 15026 is about systems and software assurance, and its Part 2 is about assurance cases, and in particular of structured assurance cases. Such cases are structured sets of claims, arguments and evidence, where:

• A claim is a proposition made about a system of concern.
• An argument is a reasoning of WHY a claim is true. It is usually supported by one or more pieces of evidence.
• A piece can be a fact, a datum, an object, a claim that is not further justified (and that is then an assumption), or (recursively) an assurance case supporting a sub-claim.

Justification frameworks have been introduced to help develop,verifyand maintain complex assurance cases. They also facilitate the reuse of assurance case structures to similar systems or issues. The proposal here is to apply the justification framework developed by the Euratom FP7 project HARMONICS to justify that a solution under study not only complies with given regulatory or standard requirements as discussed in Section 3, but also that it meets the other types of requirements discussed in Section 4 (e.g., functional requirements, performance requirements or economic requirements).

Among many other things, the HARMONICS justification framework introduces 5 basic justification blocks:

• Concretion. This block is used when some aspect of the claim needs to be given a more precise definition or interpretation. It is needed when a claim refers to arequirement expressed in abstract terms, as is often the case of the regulatory or standard requirements of Section 3, is ambiguously wordedor lacks precision.
• Substitution. Another common type of claim expansion involves transforming a claim about an object into a claim about an equivalent object, which can be viewed as a form of substitution. For example, one might claim that the evaluated system specimen has a certain property, and therefore the production system has this property too, provided that the production system is equivalent in some clearly defined way to the evaluated one. When engineering makes use of the advanced modelling introduced in Section4, and when one wishes to an assurance case early in the system lifecycle, preliminary models (generally in FORM-L) can be used as substitutes to real systems, provided that the real systems are consistent with these models.
• Decomposition. This block is concerned with structure. Many arguments are based on the partitioning of some aspect of the claim, for example, according to the functions or the architecture of the system, to the properties being considered, or with respect to some sequence such as lifecycle phases or modes of operation. The basic idea is very simple: for example, in order to make a claim about a property of a system, we need to investigate whether the system has this property by evaluating its subsystems. To do this, we need to be clear about what the property is and we also need rules about how we view the system as being composed of subsystems and how the properties of these subsystems can be combined. Double decomposition is the most general form of decomposition in which a claim that a property of a system can be deduced from other properties of the constituting subsystems. Single decomposition is when either the property or the system is being decomposed, not both. Preliminary evidence for decomposition can often be based on the advanced modelling introduced in Section4.
• Calculation. This block is used to claim that the value of a property of a system can be computed from the values of related properties of other objects (e.g. its sub-systems). One application of the block is to provide a quantitative argument when the value of one property can be calculated from the values of other specific properties. For example, the availability of a system can be calculated from its reliability and its failure recovery time, or the average time of data retrieval from a database can be calculated from the probability that the data is in the cache and the time of data retrieval if it is not in the cache.
• Evidence incorporation. This block is used at the edge of the case tree to incorporate the evidence elements. The block demonstrates that a sub-claim is directly satisfied by its supporting evidence.

6CONCLUSION

Even though these three techniques have been developed separately and are individually beneficial, they complement one another in a very effective manner, and when integrated, they constitute a powerful and effective means for representing safety and engineering knowledge on such a complex system as an NPP. Indeed, many of the limits and weaknesses of one can be compensated by the others:

• Regulatory and standard requirements are often expressed in general and abstract terms. Concretion with the justification framework may be used to trace the precise interpretation made by a project. That interpretation is explicit and can be subjected to reviews and scrutiny.
• Early justification of engineering rules with respect to regulatory and standard requirements may be associated with modelling in preliminary development phases. This could enable early safety and / or security assessments, when there is still time design changes and when that is not too costly.
• More generally, some of the evidence needed for safety or security justification may be taken from the advanced modelling of assumptions and solutions. Conversely, the fact that particular assumptions or solution features are cited in safety or security justification means that changes will need to be rigorously controlled.
• The advanced, progressive modelling approach proposed, together with simulation, can help understand the WHY of some of the design decisions (in order to satisfy requirements stated at earlier stages, in the framework of explicitly stated assumptions). In complex cases, the justification approach, with its decomposition and calculation blocks, provides additional help withmuch more explicit and informative traceability meansthan the traditional links, which are devoid of any semantics. This is particularly evident for requirements / claims that need to be allocated to a large number of components (e.g., response times or reliability).

7REFERENCES