A Model Based System Commissioning Approach for Nuclear Facilities

Abstract

Commissioning is considered as a critical phase in the delivery of a Nuclear Facility (NF) as it is the first stage in the authorization of the NF to be exploited. Most of the nuclear projects start to overrun costs during commissioning mainly since this phase is not addressed properly and is affected by many issues from previous phases (Design, Procurement, and Construction). This article proposes a general methodology to prepare and realize the commissioning activities. Using models to do so improves communication and removes ambiguities between stakeholders. It also formalizes and clarifies the commissioning organization and activities prior to any implementation. It also allows for capitalizing and sharing the experience from previous projects, by drawing references models and good practices patterns. The so-called Model Based commissioning method is elaborated around concepts, languages, processes, tools, and patterns inspired from Model Based System Engineering (MBSE) principles and practices. The theoretical foundations will be supported by results from nuclear facilities demonstrating the added value.

1. Introduction

During the design and realization phases of a Nuclear Facility (NF), there is a critical need to run and optimize a global activity called commissioning. The commissioning is an important process that ensures that the system and its components are running safely and as they are supposed to, regarding the requirements. The goal is to face and address the issues of safety, security, costs, and performance but also to deliver the necessary demonstrations and justifications to the customer or any stakeholders requesting those justifications. Commissioning also aims to provide those justifications to a Regulatory Body (RB) such as the French Nuclear Safety Authority (ASN) [1] which is in charge of authorizing the beginning of the operation of the NF. Commissioning is in fact recognized in many areas [2] but lacks formalization especially in the nuclear field. It is not considered enough of a challenge to be managed all along the NF life cycle.

Facing the importance of the commissioning in the delivery of a NF and the lack of formalization of a methodology, this article intends, therefore, to formalize commissioning and to present a method aiming to conduct commissioning activities using a model-based approach. The goal is, therefore, to propose a general framework that contributes to improving the structuration and organization of data and data-related activities (analysis, mining, ...) generated by the numerous processes orchestrated by the commissioning. Section 2 proposes a review of the state of the art concerning the commissioning and defines the numerous resulting issues. Section 3 presents industrial use cases showing the applicability and relevance of the method on NF. Section 4 discusses the results and outlines the perspectives envisioned.

2. Literature Review: Commissioning

The scientific approach described hereafter consisted in comparing the elements of definition and standards from the literature (top-down approach) and the feedback accumulated in various commissioning projects by the company ASSYSTEM that we are working with (referred to as bottom-up approach).

According to the IAEA [3] “In its simplest form, commissioning is the confirmation that an installed system functions as per its requirements”. Nevertheless, the Authors of [4] identify that “There is currently no standard for the commissioning process”. While in many fields, some proposition of commissioning definition emerges as above.

The American Society of Heating, Refrigerating and Air—Conditioning Engineers (ASHRAE) gives for example the following definition “A quality-focused process for enhancing the delivery of a project […] verifying and documenting that the facility and all of its systems and assemblies are planned, designed, installed, tested, operated, and maintained to meet the Owner’s Project Requirements.” [4]. Commissioning is also sometimes defined as a part of a life cycle phase “Commissioning is well representing integration as it is the part of the project life-cycle where earlier integration efforts are put into action and can therefore be evaluated” [5].

Even though differences between certain application fields appear, commissioning must be considered as an important objective to be carried out along with a project. For this purpose, commissioning requests to prepare and manage various activities that could be separated or enriched from those already identified in SE processes. These activities involve both business and technical resources, aiming to prepare, provide, share, and manage multiple deliverables from different streams. Hereafter we will focus on the nuclear field, where commissioning particularly deals with operation, performance, safety, and security requirements [3,6]. Indeed, commissioning must assess the respect of different safety and security requirements to authorize the running of an NF by the safety authorities. Moreover, due to the fact that we are dealing with an NF and that this field is greatly standardized specific safety requirements must therefore be considered [7].

Commissioning must therefore deal with several factors of complexity related to the NF [8], to the multiplicity and heterogeneity of concerned domains (civil engineering, mechanical engineering, Heating, Ventilation and Air-Conditioning (HVAC), computer sciences, electronic, automation, and control command engineering, etc.). Last, it must consider the multiple interactions that have to be managed all along with the commissioning between the stakeholders, each one having eventually a specific vocabulary for each involved stream. Particularly, the exchange, traceability, consistency, and availability of data, information, and knowledge between these stakeholders are crucial to allow and facilitate these interactions. So, interoperability at different levels (processes, data, and tools) is of great relevance [9]. Finally, commissioning must evolve in a dependent manner with the activities that are already highlighted by SE processes and be fed with their results.

These management and organizational issues have been encountered by engineering for years and it seems quite normal to meet them during the commissioning of an NF. However, engineering has evolved to deal with those issues with new approaches and methodologies such as SE. SE is an interdisciplinary scientific approach that formalizes and addresses the life cycle phases of complex systems. It promotes systemic and engineering principles (requirement, architecture, ...) and processes that are today standardized for different types of enterprises typology [10,11], such an approach allows to overcome the issues aforementioned.

MBSE inherits and enriches SE by highlighting, formalizing, and tooling the interest and roles of modeling and models all along with a design project. This scientific approach encompasses all activities to specify, design check, and implement a system. The use of models allows to carry out those activities more smoothly as it enables to successfully exchange data and to now and then simulate [12] the system behavior. Indeed, apart from verbal exchanges, documents (paper, files, or electronic databases) are the main means of communication and information sharing between the different stakeholders involved in a technological system development project, as well as the main means of integrating the design activity prior to the realization and physical integration of the system itself [13,14]. This document-based engineering has shown its effectiveness but also its limitations [15]. The increasing complexity of systems can only sharpen this contradiction between, on the one hand, the difficulty of developing technological systems of growing complexity (either scientifically and technically, and regarding the number, heterogeneity, and interconnections between components) with increasingly large teams, geographically distributed over varied cultural vision and, on the other hand, the means available in terms of document-based engineering. Last, any MBSE method must rely on norms and standards defined in SE such as those processes where we can find verification and validation. However, nor the concepts related strictly to the commissioning as well as processes focusing on commissioning remain poorly discussed and formalized, and sometimes don’t even exist.

Therefore, INCOSE (International Council on Systems Engineering) has developed a 2020 vision of systems engineering [15] in which the future of systems engineering will be based on models and open to new engineering practices. It, therefore, urges the community of engineers and researchers to deepen their reflections on MBSE, which it believes cannot be a simple non-directed extrapolation of current SE practices. Many methods have already been developed around MBSE, such as ARCADIA developed by Thales [16], or some variant as RFLP in CATIA environment proposed by Dassault or the CESAM [17] system framework. Those structured engineering methods are helping to define and validate iteratively the architecture of complex systems (both functionally and physically). They promote collaborative work amongst the often numerous stakeholders involved during the design phase of the system and help to converge towards the adequacy of all the identified needs. Implementation of MBSE in ASSYSTEM shows a better understanding of the processes between the different teams, and thus allows them to be more efficient in their tasks. However, although those methods are already showing their efficiency in the industry, they logically stop being applied at the end of the design phase, being then replaced for instance by so-called Model Based System Integration (MBSI) [18] that aims to cover the realization phase, particularly integration, verification, transition, and validation (IVTV) processes. Various works show the importance of bridging the gap between phases then between those methodologies and processes. For instance, [19] explains the full advantage of an MBSE approach and shows that it is crucial to create links between the SE domain and engineering to ensure the continuity and the collaborative nature of a design project. Furthermore, commissioning remains underestimated, and the gap between SE and commissioning needs to be bridged.

To bridge this gap, developing a model-based method in support of the commissioning of critical infrastructure must therefore follow some principles:

• Modeling activities must be in accordance with SE practices and processes, with commissioning objectives (performance, safety, and security), and considering both risks and other milestones identified on the global engineering project of a targeted NF.
• Modeling activities must use languages and tools that allow building and working by using a set of models understood and shared by all stakeholders. Furthermore, these modeling means are to be consistent and compliant with commissioning concepts.
• Tools must be chosen as much as possible interoperable, then maybe eventually interchanged in a specific way to manage different activities and to enable digital continuity (modeling, simulating, optimizing, scheduling, approving, etc.).
• Commissioning must be viewed in a holistic manner with a focus on the mission of not only irrigating but also orchestrating SE processes. It means commissioning must lead and promote converging to better confidence in the results throughout the NF life cycle. Finally, good practices, modeling patterns, and experiences inspired by previous projects are considered knowledge resources used for eventually revisiting and enriching the methodology.

Regarding these investigations, two major issues need to be addressed:

• Issue 1: Some inherent concepts, processes, and activities in phase with commissioning objectives are known and practiced in the SE domain. For instance, concepts such as requirements, system, components, IVTV processes, or IVTV Plan are mandatory and already defined. However, there is no real consideration nor orchestration of those processes, activities, and deliverables as it could be relevant if we focus on the commissioning objectives. Indeed, SE promotes processes for both design and realization phases of a so-called System of Interest (SOI) identified as a complex system. We think it would be preferable to enrich these processes considering commissioning relevance and importance or to promote a transverse process allowing us to bridge this gap and take more attention to commissioning in both system design and system realization phases.
• Issue 2: Limitations of principles, languages, modeling rules, and standards to provide models that could then be used and take attention to these commissioning objectives. In the SE domain, the MBSE approach promotes modeling as a crucial activity for many reasons [20], particularly the use of models will allow improving the interoperability between actors involved in both system design and system realization processes, covering naturally commissioning objectives such as safety and security requirement considerations.

The objective is therefore to build a method that can be applied to any commissioning project in the nuclear field, as described above. This method irrigates and orchestrates design and realization phases as a whole, when necessary. However, as we observed, very diverse fields of skills and competencies are requested [21]. Furthermore, considering systems typologies and complexity levels, some differences between projects appear. Still, there are three main points that characterize a commissioning project [22], the management, the oversight, and the organizational issues. It is important to notice that those points show that commissioning often has to deal with activities that are not directly linked to the technical SE processes seen above such as verification and validation for example. Many commissioning activities can be listed for any project, such as for example the execution of a trial. This is always going to be the same, especially when the component to be tested is known such as for instance a pump or a valve. However, it always occurs that to execute the trial for bigger components or even functional entities, there is a need to be in a certain configuration, or sometimes resources are not available. Those activities are more related to the specific project processes than to the technical ones, often generic, that are run to provide justifications and proof that the system is well designed and implemented. This shows how commissioning, being an important and transverse process, is directly linked to the project and its complexity, and subsequently, the identification of a generic definition of commissioning becomes more complicated.

Moreover, those project processes are run in many ways and depend partly on the country’s culture, as we can read on the Western European Nuclear Regulators Association (WENRA) website “One way is not necessarily better than the other. Therefore, safety judgments require a thorough understanding of how various safety factors interface and integrate to a whole. They require an in-depth knowledge of safety related technical and physical issues, as well as of design details, of each nuclear facility. It is equally important to be aware of the culture in which the plant is operated. This knowledge of individual technical and cultural issues as they apply to each plant, is fundamental for someone who takes on the responsibility to regulate and supervise nuclear safety”. To benchmark European inspection practices for components and structures of nuclear facilities, working groups have been therefore created, such as WENRA Inspection (WIG) or the Working Group on the Regulation of New Reactors (WGRNR). It is important to notice that it is here a question of the country's policies. The benchmark is indeed done to show how those SE processes are run and validated in every European country, whether it is a question of general processes for the WIG or especially for commissioning for WGRNR. Reports have been done and we can find much information summarized in Figure 1. This table represents the different approaches to deal with safety problematics regarding the country in charge, it presents whom and how the safety classes are treated. The study of such reports allows establishing what kind of activities are run in the same way regardless of the country's culture and therefore to build a pattern of good practices understood by any project manager. In a nutshell, due to project specificities such as distinct safety cultures, commissioning of an NF is way too often considered as a First of a Kind, even though strong genericities should be underlined.

First, we can notice that those inspections are in many ways run differently in regards to the country, and moreover, it seems logical that if those activities are directly and intrinsically linked to the country's culture and policy, it will also be linked to the project owner and manager. Within ASSYSTEM, it has been significantly observed that there is always a need to adapt regarding the environment. Therefore, it demands a lot of adaptability to build an entire strategy that matches companies’ good practices and culture. In addition, those habits are evolving through time as we can read in the WANO report [23] “Traits of a Healthy Nuclear Safety Culture describes the essential traits and attributes of a healthy nuclear safety culture, with the goal of creating a framework for open discussion and continuing evolution of safety culture throughout the commercial nuclear energy industry.”

Within the ASSYSTEM Group, many issues have been experimented with in several projects. Hereafter we will consider two specific projects called STEMA (French acronym of ‘Station Traitement Effluents de Marcoule’) and Flamanville 3. STEMA consisted in the commissioning of a Radioactive Liquid Effluent Treatment Plant situated in CEA (French acronym for ‘Commissariat à l’Energie atomique et aux énergies Alternatives’) Research Center named Marcoule (France). For the Flamanville 3 project, an EPR project at the Flamanville site in France, ASSYSTEM covered the tests of a large range of systems. The teams supervised some of the testing systems in the nuclear Island, the Conventional Island, and the Balance of Plant. One of the main objectives was to contribute to the digitization of the commissioning.

During these projects, feedbacks such as a Return of EXperience (REX) have been written and the study of these documents has shown that blocking points are often encountered during the transition between the assembly and the trials or between trials and handover. This shows that there is an unexpected amount of work and data to analyze, and it illustrates the fact that even though, the activities that must be run during the trials phase are well known by the teams in charge, the orchestration, and planning of those activities is needed. Furthermore, those technical processes often draw information they need in the models and documents developed during the design phase, as they must check that the system met the requirements It is also relevant to notice that even though the realization of trials is often similar from one project to another, these experience feedbacks show that projects managers have their own way of working within those projects. For instance, the planning of these trials is always done according to the company’s culture requesting certain adaptability for teams’ members. This shows once again that building a model-based approach for commissioning would be relevant but also that feedback repositories need to be articulated around common denominators that need to be rigorously identified.

Those new elements of the literature bring out two new issues that need to be addressed:

• Issue 3: Each project aiming to design then realize and qualify an NF has its own specificities but cannot be interpreted, as such as a first of a kind in the mind of stakeholders. So, it is difficult even unbelievable to share and cross experiences, to reuse models adapted. This complicates a generic definition and formalization of the commissioning.
• Issue 4: Absence or difficulty in using knowledge repositories on commissioning (formalization of a REX, a pattern of good or bad practice, etc.). Indeed, the complexity of each project creates the need for important management of those patterns and a better definition of which REX and pattern are good to use.

To conclude, it must be pointed out that the commissioning must face the complexity of the NF (structure, architecture, functions, numerous requirements, etc.) but also must deal with heterogeneous stakeholders that have different expectations and use specific vocabulary inducing sometimes misinterpretation due to ambiguities. Particularly, it is a systematic question of security and nuclear safety requirements that must be validated by a Regulatory Body (RB). Moreover, an NF is a critical infrastructure [24] as it often deals with energy or medical molecule production [3,25]. Indeed, the operation of such infrastructures must deal with many threats, such as defense against terrorist attacks, but also natural disasters like floods for example, which can lead to quite considerable damage.

Secondly, hereafter considered, the design and implementation steps of an NF are guided by System Engineering (SE) [10,26] approach, principles, and processes. Particularly, NF realization is done following IVTV SE processes (Integration, Verification, Transition, and Validation). These processes do exist, but they are not clearly aware of the commissioning purpose which remains poorly considered. Moreover, over the past years, new methodological ways to perform SE have been developed, particularly hereafter considered, Model-Based System Engineering (MBSE [27] that promote and insist on the role and relevance of models all along the NF life cycle.

Therefore, and regarding the problematics and issues that have been stated, two paramount actions need to be taken:

• To define clearly and formalize the commissioning, its scope, and its goals in the nuclear field, considering the NF complexity factors summed up above.
• To put in practice commissioning in the reality, to enable and enhance its interactions with the SE processes, and even to induce a responsibility to the team in charge for the actual monitoring and orchestration of these SE processes. Those processes taking place in different life cycle phases, it is significantly important to establish this link as soon as possible, since the design project start that will ensure good and notable interaction between the latter.

The literature review coupled with the background of nuclear experts clearly shows that today there is a lack of methodology to prepare and conduct the commissioning phase of an NF that avoids those issues. Using MBSE to do so seems more than relevant as it allowed a unified approach of the entire commissioning of any NF and this for all the stakeholders involved.

The next section is devoted to the presentation of this model-based commissioning method referred to as Commissioning Guidelines for Nuclear Facilities (CoGuiNF)

3. Commissioning Methodology Description

It is essential to first present globally the CoGuiNF method elements, and then to present an overall view of the commissioning and the activities that need to be specified, optimized, and run, implying adaptations all along the IVTV of the NF. These activities form then the operational approach of the method. The concepts, the languages, and the tools are then presented prior to an industrial example carried out within ASSYSTEM.

3.1. Method

CoGuiNF must allow any person in charge of commissioning to:

-

Improve the coordination and the articulation of the different activities of all stakeholders involved both in the design and realization phases of an NF and taking attention to commissioning purpose. The goal is to bridge the gap between SE processes, involving both MBSE practitioners and actors involved in IVTV, each focusing on his/her own objectives (e.g., requirements engineering, architectural design, or integration, verification, or validation of the NF).

-

To head and request these stakeholders to converge and particularly to support them in preparing, managing, and performing activities related to reach commissioning objectives (e.g. in terms of resources, means, etc.) for the trials and examinations (contents, deliverable, justifications, pointed out requirements, etc.), components configuration management and more, requested classically in Integration, Verification (of the integration) and Validation (face to the customer and authorities) SE processes;

-

Check the wholeness and the relevance of those activities in a global and holistic way.

-

Establish, formalize, and optimize the planning of these activities in terms of costs, duration, and performance.

-

Last, organize and complete the REX of the pointed-out commissioning, to facilitate its reuse by other projects.

Concerning CoGuiNF, the five important elements are presented below:

• Concepts: they represent principles (concepts and attributes defining each concept), dependence between these principles (relations and attributes requested to define each relation, when necessary, but also rules and constraints associated with each relation) that are useful to describe, formalize, and handle commissioning. These concepts allow a clear definition of commissioning vocabulary, fused with system engineering vocabulary to create a more consensual and open vocabulary to be used in the nuclear domain. These concepts and relations are crucial to describe and formalize the different activities and processes that are to be done all along with the commissioning phase. They are hereafter formalized by using the metamodeling approach [28]. A metamodel highlights concepts modeled as Classes and Attributes and relations between concepts as Relations with Constraints as presented below.
• Languages: we discuss here essentially Domain Specific Modeling Languages (DSML) [29]. They allow the stakeholders to model commissioning activities, resources, trials... This requires selecting and formalizing sets of concepts and relations that are requested to represent a viewpoint of the commissioning system. Classically, at least functional, physical and behavioral viewpoints are used as promoted in the System Sciences field and, for instance, by the SAGACE approach [30] or more precisely as promoted in the System Engineering domain, for instance by the ARCADIA approach [31]. Formalizing the DSML means selecting an existing Modeling Language that matches with these concepts and relations (example: BPMN for functional viewpoint) or defining abstract and concrete syntaxes, semantic, and modeling and execution rules. Disposing then of various DSML, one or more for each viewpoint, authorizes actors to model the commissioning system and to link from an interoperable manner, all conforming to the common meta-model, related models, and engineering models, e.g., models of Requirements or Architectures.
• Processes: they describe how the method must be used, i.e., how the stakeholders must proceed when considering commissioning problematic. This aims to describe how these users will define and put in place a commissioning system (designed to conduct the commissioning) in phase with the engineering project then irrigate and orchestrate the whole set of SE processes the project requests. These processes are composed of various activities (e.g., to model, to check correctness, to evaluate, to optimize, to run tests, or to provide expected deliverables). Stakeholders involved in these activities then use the proposed concepts and DSML of the method in a consistent way. This has been experimented with at ASSYSTEM where teams are in charge of establishing a methodological guide that allows customers to model the system that will ensure a better check and follow-up of the trials [32].
• Tools: all along with the processes, they support the proposed activities (modeling tools, simulation tools, optimization tools...). They implement the chosen DSML and must manage all the data carried out and exchanged with other tools, for instance, dedicated to engineering activities.
• Knowledge repository: this is a central element of the method that gathers expertise, experiences, design patterns [33], and reference models. This allows users to reuse various parts of past successful experiences and also to reuse and configure for instance existing models already used and validated, reducing modeling duration, errors, or ambiguities. Indeed, it is necessary to draw inspiration from models considered as corresponding to proven solutions. On the contrary, it is also important to take care and to draw inspiration from models that correspond precisely to solutions that could not be applied or could not succeed. The goal is then to avoid reproducing certain past errors and gain time and performance. The following parts present more details of the method elements.

3.1.1. Concepts

Considering the literature review, the commissioning is classically defined within the actual nuclear industry as presented in Figure 2, this figure was drawn in accordance with the System Engineering Body of Knowledge [34] concepts in order to respect SE standards. This figure shows what kind of SE process deliverables are needed for the commissioning but also when during the SOI life cycle [10], here considered the NF. It also shows what kind of interactions are expected between stakeholders. The commissioning sometimes starts during the Concept Definition and not just during its Realization depending on the system complexity and the company culture and patterns. Indeed, as it has been presented in the literature review, the definition of commissioning itself is an important issue. Therefore, we propose a definition that best fits with any field of application.

Commissioning is often defined as an objective to reach, particularly when IVTV processes are run. As introduced earlier, we focus hereafter on promoting a systemic and holistic, up-to-date and validated view of commissioning throughout an NF engineering project, while remaining generic to be applied in other application domains.

As we already briefly discussed in the literature review, considering the commissioning as a system could be more than relevant and considering the complexity of it, two systems are defined: the classical SOI that needs to be built, and a System Used To Do (SUTD) [35] that will help the elaboration and the construction of the SOI.

We consider that the commissioning is composed of these two sub-systems, interacting continuously. So, commissioning could be globally seen as a system of systems [36] composed as follows:

-

The commissioning SOI [10,37] encapsulates the different activities and tasks that are needed to establish the evidence which allows the responsibility transfer. This SOI is closely linked to the NF itself and interacts with the SE processes. It shares various inputs with its environments (commissioning SUTD in particular) such as various management information (planning, milestones, etc.) and outputs such as all the evidence and justifications needed for the RB and the customer.

-

The commissioning SUTD ensures the SOI design, run, manage, and builds a program to follow and ensure the good coordination between commissioning SOI and other SE processes. It is also important to notice that the commissioning SUTD would be allowed to criticize some SE processes outputs (e.g., requirement repository) to harmonize the vocabulary and to avoid any retroactive actions (e.g., requirements repository redaction) that are often encountered during commissioning, especially because there is an important lack of interaction between commissioning and other processes.

The commissioning SUTD starts at the beginning of the Business and Mission Analysis process, as the IVTV plan is already gaining in maturity. Commissioning definition gains in maturity consequently all along with the design phase, being itself in phase with the NF design phase. In parallel, the commissioning SOI is itself designed and the commissioning program established. Particularly, the specific business activities require autonomy in terms of decision and evolution of the teams or even of the companies that are to be involved for instance in terms of availability or skills. Therefore, the commissioning evolves continuously due to numerous interactions and orchestration as synthesized in Figure 2. It is then considered as a system of systems that preserves the autonomy and evolution of the SOI and of the SUTD.

Consequently, the commissioning is characterized by two more or less overlaying steps linked to designing and realization objectives of the NF:

• Commissioning Design Time (CDT): the commissioning system, both the SOI and the SUTD, are first defined in a way then validated a priori by specifying the requested activities and resources, the objectives to reach, the constraints and requirements to be taken into consideration from the NF but also from all stakeholders being involved in such activities. The CDT, therefore, starts at the NF’s concept definition stage, which must feed, in terms of feasibility, regulatory, or deployment constraints, for example, and will be irrigated by commissioning system in terms of needs and testing, trials, reviews, and more globally all justification activities.
• Commissioning Run Time (CRT): the commissioning system performs its SOI as defined in CDT and controls its evolution and improvement by performing the SUTD. Indeed, commissioning SUTD must adapt the commissioning SOI as needed according to the various events or situations encountered during the realization of the targeted NF.

Commissioning SOI encompasses the IVTV processes and enrich the classical IVTV plan itself defined during the design phase of the NF that are defined by the Systems Engineering Body of Knowledge (SEBOK) [26] as:

○

Implementation consists of the construction of system elements that meet the stakeholders’ requirements and system requirements developed in the engineering life cycle phases, here considered of the NF. These system elements are then integrated to form intermediate aggregates and finally the complete system-of-interest.

○

Integration consists in delivering implemented system elements that compose the system-of-interest (SoI), assembling these implemented elements together, and performing the verification and validation actions (V&V actions) during the assembly. The ultimate goal of system integration is to ensure that the individual system elements function properly as a whole and satisfy the design properties or characteristics of the system.

○

Verification of this integration consists in ensuring its quality in relation to the established design. This consists in defining examinations, reviews, partial tests requiring sometimes to emulate some components not already available for integration, etc. This aims to check step by step the conformity of the result of the integration process with the design.

○

Transition to the customer consists in transferring some of the components manufactured at a separate production site at the customer's site for integration.

○

Validation with the stakeholder’s representatives of the NF development project, including the client. The validation also aims to prepare arguments and facts to support and facilitate the qualification of the NF by nuclear authorities. It consists then of new examinations, reviews, and essentially trials. This allows stakeholders to express themselves with confidence on the relevance of the architectural choices, on the safety, performance, and security of the installation in accordance with their requirements.

Regarding the commissioning objectives, we can here observe that all those SE processes have a common goal to deliver arguments and facts that show that all systems, subsystems, and components are compliant and meet the requirements. However, there is an important goal that is not clearly shown in those definitions, those processes must consequently be defined, planned, and, when possible, optimized considering different strategies (e.g., intending to reduce resources mobilization or costs) and must provide different schedules for all other processes to orchestrate and optimize their run. Moreover, the link between the system requirements or mission analysis that occur during early phases and verification or validation that occur during the system realization is not always given enough consideration and data often need to be rework. Management and dialogue between them are later ensured by the commissioning.

The concepts requested by the method that results from this observation and this architecture are formalized as follows. To begin with, as we rethought the commissioning as a system that defines and orchestrates various activities and even processes, we introduce the concept of the processor. It will be used to model any process, sub-process, activity, or task related to the commissioning purpose.

Those processes and activities consist in exchange flows, essentially of two natures:

• Data such as, for instance, the requirements repository generated by the stakeholders, will be read, and criticized by the commissioning team regarding the various justification activities (e.g., trials realization) that will allow checking the conformity of the NF as it has been integrated with those requirements.
• Material such as, for instance, prototypes, applications, or test benches to be deployed.

To model these processes, it is necessary to clearly define and characterize the relationships between the different concepts directly linked to the processor. Figure 3 summarizes all those concepts and relations.

Some of those interactions are presented in

Table 1. Examples of interactions between commissioning and its context.

Source	Exchanged Item	Target	Commissioning Role
Stakeholder’s needs and requirements	Requirements repository	Commissioning	Requirements analysis and comment
Commissioning	Commented requirements repository	Stakeholder’s needs and requirements
Integration	Integration Strategy	Commissioning	Elaborate a commissioning strategy that ensures the smooth running of the IVTV plan. Confirm that all those strategies consider all requirements. Give orientation for strategy improvement. Propose and promote specific trials and reviews for qualification.
Implementation	Implementation Strategy	Commissioning
Verification	Verification Strategy	Commissioning
Validation	Validation Strategy	Commissioning
Commissioning	Commissioning strategy	IVTV processes RB

, which shows also how a modeling approach may ensure the amelioration of these exchanges.

Regarding this definition, Figure 4 schematizes these main concepts inducing both static and dynamic points of view and interactions with the whole set of SE processes. As we can observe, the commissioning is starting earlier and takes place all along the project, advising and criticizing the data generated by various processes. The commissioning even partially has a role during System Deployment and use through reviews or simply by being able to run trials in case the system needs partial rebuilding.

3.1.2. Languages (Domain Specific Modelling Languages—DSML)

The exponential growth of information accessible through databases represents a challenge for information analysts. The volume of data, their diversity, and the heterogeneity of their sources prevent any manual operation of extraction of such knowledge. The need was felt to propose new methodologies as well as efficient tools to achieve this. The visualization method will therefore have to allow the data visualization, as well as analysis results of their analysis by preserving the important relations between the information and by illustrating the behaviors of the concerned processes. Through the distribution of links, incoming or outgoing, between the associated sites, it will show the geographical distribution of the domains. The model-based orientation of the proposed method then needs to adopt a multi-viewpoint modeling approach as promoted in both systemic and system engineering-related literature. We retain hereafter:

• Functional/Behavioral view: allows to describe what the commissioning does, not how nor with what it does something, and to describe the information it handles. It describes what users ultimately expect from commissioning when carrying out processes. The functional view enables functional invariants to be identified and structured between several processes or activities. At the same time, the chosen DSML for this view should provide models that can be executed i.e., simulated, or even formally analyzed. By using the same DSML, enables defining and reproducing the expected behavior of the modeled processes, checking various hypotheses and taking into consideration various situations in which these processes must remain able to provide their outputs respecting delays, performance objectives, or resources mobilization rules.
• Organizational view: focuses on the structure of the instances of the commissioning system (resources used and usable), their relations, and links that exist between them.
• Contextual view: presents the commissioning system in its own environment (stakeholders, external organizations, sub-contractors, or internal business units that may be involved) and the interactions that occur between the latter. For such a view it is important to highlight the fact that such models could already exist as the environment of the commissioning is closely linked to the NF environment.
• Informational view: includes all data generated and treated by the commissioning system. It also describes business objects (i.e., information) managed, manipulated, or exchanged by the information system, and how these business objects are manipulated.

To draw models that will correspond to each of those views and that allow the handling of the proposed concepts seen before, various DSML are requested. Some of them could exist, they concern modeling, simulation, or optimization languages used in the NF design phase in conformity with MBSE usage. However, they do not completely match with some of these concepts. Commissioning-specific new DSML can also be defined, being then interoperable with engineering languages. (e.g., requirements, and architectures).

By evidence, using the same DSML allows to easily irrigate and exchange the commissioning models with the NF model, the two models being then fully interoperable in terms of modeling concepts, modeling languages, and even modeling usages. However, it is important to consider other languages that might be more adapted to the modeling of processes, such as BPMN for example, or DSML respecting for instance some standards such as SPEM 2.0 [38,39].

BPMN provides a process description language with a visual notation that is easy to understand, at least at a basic level, by all stakeholders including domain experts and IT developers. It allows business process requirements to be modeled on an XML basis. Other languages take over for business process execution, such as the Web Services Business Process Execution Language (WSBPEL). It has been argued that the BPMN notation includes a limited set of elements [40] (Figure 5) that would allow a BPMN beginner to easily understand a reasonably complex process.

On the opposite, SPEM 2.0 provides a global metamodel, even considered as a pivot model allowing exchanges and improving interoperability between project management tools for instance. Globally, we consider SPEM could also allow us to define a more specific modeling language than BPMN for the functional view description.

All these Domain Specific Modeling Languages (DSML) are needed to represent the commissioning within all the previous views that are relevant. Hereafter Figure 6 presents the DSML established to allow the contextual view description and formalization.

3.1.3. Tools

Many tools can be used to instantiate those languages i.e., to create models such as Capella developed by Thales in 2007, GENESYS developed by Vitech, or RFLP developed by Dassault. We present hereafter more in details Capella, but it is important to keep in mind that the method developed must be able to be deployed regardless of the tool if the languages that will be presented can be implemented by this tool.

Capella is an open-source MBSE solution hosted by the Eclipse Foundation. It provides a tool-based process allowing the graphical modeling of system, software, or hardware architectures, in accordance with the principles and recommendations defined by the Arcadia method [16]. The result of such an environment is intuitive and allows engineers to focus on defining their architectures rather than on learning and using complex generic modeling languages such as UML or SysML to capture their needs. Dedicated to the underlying Arcadia method, it also guides engineers in their activities. The workspace has its own metamodel, which defines the concepts of the language that the user can manipulate through a project, i.e., through a Capella model, an instance of this metamodel. Then, the user can visualize this model under different aspects, according to different concerns, through diagrams. Thanks to this tool, it would be possible to instance CoGuiNF directly in parallel of the Arcadia method, as the language used in Capella is like SysML, processes could be built and be directly linked to the NF model itself, allowing the team in charge to build all commissioning strategy regarding the architecture and the different requirements.

As the language of Capella is close to SysML, to model processes need some adaptation. It is possible, but other tools are designed for that purpose, for instance, BPMN.io or SPEM 2.0 modeler.

To conclude, CoGuiNF must allow the commissioning stakeholders to choose the tools they want to use to design and conduct the commissioning in regard to those they are already using for engineering. Indeed, the major goal of working with models is to improve communication and decision-making, and to do so, working on the same tool to share the information seems to be more than relevant. For example, thanks to Capella Studio, it is possible to develop an extension of Capella that would allow designing the commissioning System in parallel with the SOI, making it possible to define and to draw links between commissioning, SE processes, and systems.

3.1.4. Knowledge Repository

A knowledge repository is a central element of the method, it gathers expertise, experiences, patterns, and reference models allowing reuse of experiences by enriching their model with good practices patterns or by avoiding reproduction of past errors that could have occurred. The goal remains to gain time and performance during the commissioning design and execution. As we are essentially working around models, the most important elements of the knowledge repository are patterns and reference models.

A reference model is the starting point for any commissioning project—a model that has something in common with the desired solution. Reference models establish, by their nature, a generic representation of processes in a particular domain and can be extended or modified to meet specific needs. It helps to highlight the stakeholders and processes that are involved and those that are not involved in the project scope. All of them provide important information from existing models. Reference models also help to set up the project team by identifying potential stakeholders and participants. During the modeling phases, the starting point will be the existing models because they can be modified and extended as needed to meet specific requirements. They contain all the information that has been identified as generic information for any commissioning project. For instance, Figure A1 in Appendix A represents a generic model that can help to establish the trial activities that have to be run.

A pattern is a set of the model(s) and associated information that describes a proven solution to a recurring problem in each context. A Design Pattern (DP) allows engineers and architects to associate a kind of problem to a potential solution that has already been tested and validated. It can then be partially reused in cases of similar problems. The goal is to help these actors by highlighting these potential solutions. A DP could focus, for example, on requirements writing (e.g., a set of boiler plates), on functional, logical, or physical architectural pieces of the solution. In the same way, an evaluation pattern contains the implemented approach, the evaluation criteria of interest, the used methods, the typologies of stakeholders, etc. in relation to a problem (evaluation objectives, concerns deemed relevant, or the nature of the system to be evaluated). Applied within the framework of MBSE, it, therefore, aims to improve the efficiency of engineering by representing past experiences, knowledge, and know-how, i.e., the company’s culture. Design Patterns are, in fact, a lever allowing engineers to solve problems faster and more reliably by drawing inspiration and/or customizing the information encapsulated in these patterns. Finally, by definition, a pattern maintains a certain number of relationships with all the other patterns, thus making their use more efficient and relevant.

3.2. Case Study Examples

To validate some elements of the method, they have been partially deployed on various projects carried out by the ASSYSTEM group. These deployments are presented in the next paragraphs, the last one being more detailed and illustrated with some figures.

The first project is called STEMA (French acronym of ‘Station Traitement Effluents de Marcoule’), the mission consisted in modeling a given perimeter of an effluent treatment installation and in developing a 4D schedule for the visualization and the conduct of the trials. The second one is called MOLFI (French acronym for “MOLybdène 99 de FIssion”) and consisted of the definition of a Tests and Trials Program (TTP) and requirements management within a Molybdenum99 production project. Molybdenum-99 is a radioisotope of molybdenum used in industry as a precursor to 99mTc (nuclear medicine) and is obtained by the irradiation of targets enriched in uranium235. For both projects, the main issue was the unexpected amount of data to analyze (e.g., requirement repositories, PBS, FBS, etc.) and the orchestration of the trials among all the other activities that are observed in such yards.

Furthermore, the difficulty of all stakeholders to efficiently discuss the SOI itself, its component, its functions, and requirements, dramatically slowed down the design of V&V activities needed.

The third project relies on a complex process allowing the definition of the tests to be carried out during the commissioning, the execution of these tests, and the verification of the obtained results. Within the framework of this, the objective was to assist in the digitization of this process. The mission consisted, essentially, in specifying the business expectations to the integration teams of the project on the one hand and in validating the solutions proposed by these integration teams regarding the target process on the other hand. This project was consequently more concerned with using the Informational view.

The modeling objective, as part of the definition of the need, was to map the exchanges of the commissioning system proposed. To do so two major activities have been defined and are presented below:

• Establish the contextual view to highlight the interfaces between the commissioning system and the various teams and IT tools that make up the information system.
• Establish the behavioral view allowing us to discuss the sequential chaining of the activities that are run by the different subsystems and actors.

First, to understand the next figures, different acronyms are used:

• BoC: Basis of Commissioning
• CI: Commissioning Instruction
• CP: Commissioning Program
• CTP: Commissioning Test Package
• EESR: End of Erection Status Report
• PFW: Permit for Work
• SAN: Sufficient Analysis
• SCF: System Commissioning File
• SCP: System Commissioning Program

To complete the first modeling activity, the diagram above was established. It provides an overall context for the commissioning, from the very beginning to ensure that all stakeholders share a common understanding of the role of everyone. By identifying the main interfaces and their natures but also the potential risks allocated to the latter, it allows materializing the different possible architectures for the project to choose the best one.

After the context is established, activities are directly linked to the subsystems that compose the commissioning system and it enables the modeling of their sequential chaining. This allows to describe the expected behavior of the commissioning system but also to identify a potential unexpected behavior that would directly lead to a delay or an additional cost for the project. It also allows identifying the dependencies between subsystems, interfaces, and activities in this given context. All those activities are moreover detailed by minor activities, and this ensures the traceability of the information. All stakeholders are then able to discuss their resources in regard to their respective missions and roles.

In addition, the availability and centralization of the data allow the running of other IT tools that might help to establish optimized chaining of these activities, in regard to resources needed and constraints that enable their undertaking.

As feedback, those three projects were closely concerned about using the Functional and Contextual View as in Figure 7 and Figure 8. Working with models has shown more than one advantage. In MOLFI for example, the verification of the V&V activities that have been elaborated have been done in groups using Capella, checking out the exhaustivity of the interfaces and the functions treated (200 functions, 300 requirements, and 200 interfaces).

Collaborative work sessions ensured a better dialogue between the different stakeholders and many mistakes have been corrected. The use of a modeling tool also ensured to have all the data and information centralized within the same tool and facilitate the allocation of all those concepts with themselves (e.g., functions allocated to a component which is defined by a requirement). Modeling the trials and their orchestration with the other activities also ensures having a better view of the global project schedule, ensuring that the commissioning activities do not disrupt the other activities or the other way around.

All this allowed for putting in a light that many elements (functions, requirements, and interfaces) were miss captured by the conventional method. For example, in MOLFI, almost 20 out of 200 functions (10%) were not clearly treated by the first draft of the trial program, and the work sessions around models allowed to point out this omission. In addition, it is important to note that in this field, delays and costs that would be induced by such a mistake are not negligible.

4. Conclusions

This paper presents the CoGuiNF methodology which includes an MBSE approach coupled with theoretical requirements for commissioning and ASSYSTEM’s feedback on previous commissioning projects in the nuclear facilities field. This method facilitates the design and conduct of commissioning but also aims at anticipating potential problems that could be encountered during the project. The model-based orientation of the proposed method adopts a multi-viewpoint modeling approach which is promoted in both systemic and system engineering and allows to draw the context in which the commissioning system is deployed, data treated and generated, resources and structures are managed, and how the system behaves during its deployment.

This method provides some interesting benefits while it was deployed in the presented projects. Globally, using and promoting a model based method to prepare (model, check, improve, evaluate, and validate prior to any implementation) and conduct (control, evaluate, modify, and adapt, manage changes) the commissioning allows:

• Unifying and promoting vocabulary, rules, processes, and activities understood and shared by all the involved stakeholders;
• Remaining in-phase and as soon as possible informing, even piloting various activities from IVTT processes, bridging the gap between commissioning teams and implementation teams;
• Design crosscutting activities at the earliest stages of the project that allow to clearly prepare the commissioning and to anticipate issues that may occur during the project.

5. Future Works

The method must be enriched and validated on more complex projects and be deployed at the scale of the whole company. For that, it is first essential to identify the most suitable IT tools in terms of functionalities but also in terms of interoperability within the Assystem network. Second, commissioning managers’ work must be supported and, as much as possible, assisted to gain time, to improve resources use, and to improve the confidence of all stakeholders of the commission project: quality and objectives of tests and trials defined and validated, resources planning checked and evaluated, etc. For this purpose, various models could be established and shared between all commission projects, being a source of credible and plausible information. These are called reference models and allows the avoidance of tedious tasks. Some of these models can even be simulated and put in lights where and when some unexpected events (resource availability) could have significant consequences in terms of cost and delay. This paves the way for early verification and validation (V&V) applications that are very important in the context of improving project delivery and commissioning activities. To do so, three major actions have been defined.

First, the development of an IT tool enabling the sorting and researching of patterns has been started. Secondly, the development of a Capella add-on, using Capella studio is in progress. This would permit the building of the commissioning models in parallel with the SOI ones, allowing to link the different elements of these respective models. Finally, another case study is planned on the international experimental thermonuclear reactor, ITER. The goal is to prepare and conduct all or parts of the trials of one building.