OVERVIEW OF THE METHOD

This section outlines a methodology which could be used to perform digital CCF evaluation across an integrated plant design scope. The methodology was used as a pilot case to evaluate a NPP design which was certified by the U.S. NRC in the 1990’s, but has not been constructed in the United States. The licensing basis design descriptions for that design were used as the exclusive source of information defining the plant’s design.

The descriptions of the evaluation methodology contained in this section are informed by experience gained during the pilot case evaluation.

4.1. Establish D-in-D Concept

The first step in the method is to establish a D-in-D concept which forms the basis for the remainder of the evaluation activities. The five lines of defence [2] provide a useful framework for this purpose. The D-in-D

S. SMALL and I. POPPEL

44

concept for the pilot evaluation included Defence Lines 2, 3, and part of 4. The IAEA lines of defence were translated into the U.S. regulatory and safety classification schemes and terminology as follows:

Defence Line 2 contains those functions which attempt to control or stop a plant transient before any parameters reach a safety system actuation setpoint. If the Defence Line 2 functions are successful, initiation of a safety-related reactor trip or ESF function is not needed. The functions in Defence Line 2 are nonsafety-related.

Defence Line 3 contains those functions which act to mitigate a design basis event by preventing fuel damage, assuring the integrity of the barriers to release, and placing the plant in a safe state. These functions include reactor trip and actuation of engineered safety features. The Defence Line 3 functions are needed when Defence Line 2 is not effective at intercepting a transient, when the transient is itself caused by a failure of Defence Line 2 functions, or when an event starts “beyond” the capabilities of Defence Line 2. The functions in Defence Line 3 are safety-related.

Defence Line 4 (partial) contains those functions which can place the plant in a safe state if the Defence Line 3 functions fail. The Defence Line 4 functions are nonsafety-related.

During the pilot evaluation, it was decided to express the remainder of the D-in-D concept in the form of requirement statements; primarily to support their direct use as acceptance criteria for the evaluation, but also to make the D-in-D concept as unambiguous as possible. The requirement statements were aimed at the ‘plant-level’, meaning that they were not specific to any system or function; instead, they focused on plant functions residing in a given line of defence. Examples of the types of requirements used to define the D-in-D concept for the pilot evaluation are:

— A CCF occurring in Defence Line 2, which impairs mitigation of a design basis event, shall be mitigated by functions in Defence Line 3.

— A CCF occurring in Defence Line 2, which causes a design basis event, shall be mitigated by functions in Defence Line 3, or by a combination of functions in Defence Line 3 and unaffected functions in Defence Line 2. The unaffected functions are determined in accordance with the section “CCF guidelines”. If a combination of Defence Line 2 and 3 functions is credited, then:

 The credited functions in Defence Line 3 shall not depend on successful occurrence of the credited Defence Line 2 functions, and

 It shall be confirmed that the design basis event cannot be caused by a digital CCF in support systems which would also render the credited defence line 2 functions ineffective.

— Defence Line 3 functions shall depend only on safety-related support systems;

— Defence Line 2 functions and Defence Line 4 functions shall depend only on nonsafety-related support systems.

Requirements related to diversity and independence between defence lines were also included. In total, 11 plant-level requirements were used to define the D-in-D concept for the pilot evaluation. It should be noted that the pilot evaluation had a scope limited to Defence Lines 2, 3, and part of 4; a D-in-D concept supporting a broader evaluation scope would naturally include more requirements.

4.2. Establish Evaluation Scope

The evaluation scope can be defined in terms of the initiating events, the plant systems, and the types of digital CCFs to be included. The pilot evaluation was performed with the following scope:

Plant Events: The evaluation included those design basis events in the plant’s licensing basis accident analysis which start from a full-power operational state, superimposed with a single digital CCF. The definition of included events indirectly defines the scope of defence lines which will be included. In the case of the pilot evaluation, the plant’s licensing basis accident analysis involved functions in defence lines 2, 3, and part of 4.

Plant Systems: The evaluation included primary systems and support systems. Primary systems were defined as those whose functions directly mitigate a design basis event, or whose failure can directly initiate a design basis event. Support systems were defined as electrical supply systems, cooling water systems, and HVAC systems whose failure could prevent mitigation of or initiate a design basis event, but only by way of causing a failure of a primary system which in turn directly affects a design basis event.

Digital CCFs: The pilot evaluation was intended to evaluate a reasonable set of CCF scenarios. It did not attempt to bound all imaginable digital CCF scenarios. Section 4.3 of the paper identifies the specific digital CCF modes which were included.

S. SMALL and I. POPPEL

45 4.3. Establish Digital CCF Modes and Guidelines

An evaluation of this type is only defendable if clear definition is given to the digital CCF modes which will be considered and how those modes are applied. The pilot evaluation included two CCF modes. A CCF resulting in no action or state change occurring when an action or state change should have occurred was defined as a ‘passive’ CCF mode and was included. A CCF resulting in action or state change occurring when the action or state change should not have occurred was defined as a ‘spurious’ CCF mode and was included.

The pilot evaluation explicitly excluded two other CCF modes. A CCF resulting in some, but not all, actions that should be taken for a given scenario being taken was defined as ‘partial’ CCF mode and was excluded.

A CCF resulting in a specific and varied combination of output states across a digital technology platform, with no basis for the chosen combination beyond the fact that it would make the results of an event significantly worse than has previously been evaluated, was defined as a ‘deviant’ CCF mode and was excluded.

The pilot evaluation included the following guidelines to govern application of the included failure modes.

— When a spurious CCF is postulated, it is assumed that a single function acts when it should not. A single function includes all actions ordered on the basis of a single setpoint value. The guidelines regarding availability to credit other functions are as follows:

 If the spurious CCF occurs in a safety-related technology platform, all other functions in that technology platform are assumed to fail as-is; they maintain their control outputs in the same state that existed immediately prior to occurrence of the CCF.

Functions in a different safety-related technology platform are assumed to function normally and correctly;

 If the spurious CCF occurs in a nonsafety-related technology platform, all other functions in the same control segment are assumed to fail as-is; they maintain their control outputs in the same state that existed immediately prior to occurrence of the CCF. Functions in different control segments can be assumed to function normally and correctly, even if they are in the same technology platform. Functions in a different nonsafety-related technology platform are assumed to function normally and correctly.

— When a passive CCF is postulated, it is applied on a technology platform-wide basis. The guideline regarding availability to credit other functions is the following, regardless of whether the CCF occurs in a safety-related or nonsafety-related technology platform;

 All functions in the technology platform should be assumed to fail as-is; they maintain their control outputs in the same state that existed immediately prior to occurrence of the CCF.

For spurious CCF modes, the decision to assume a ‘failed as-is’ state for the rest of the functions in the control segment or in the same technology platform is a conservative scheme to isolate the effects of the failed function, and to prevent taking credit for the same digital equipment suffering the CCF. It is just as likely that other functions performed by the equipment, which spuriously actuated a function, would be performed correctly.

Also, specific requirements were generated around establishing a degree of independence between different control segments to support the concept of limiting a spurious CCF to one control segment at a time.

4.4. Establish Assumptions

Two types of evaluation assumptions need to be established; methodology assumptions and design assumptions. Consistent with other types of ‘beyond design basis’ analyses, best-estimate (realistic) methodology assumptions were used for the pilot evaluation. Examples of these assumptions include setting the initial power conditions for events to 100% as opposed to the more conservative 102% used in the licensing basis accident analysis. Offsite power remains available during all events except those where loss of power was the event initiator and no additional failures impacted event mitigation beyond the digital CCF being evaluated.

Design assumptions were established when some aspect of the design was not explicitly defined in the licensing basis or was generally defined but not in enough detail to support the evaluation. These types of assumptions are needed when a conceptual design is being evaluated. However, it would not be necessary if an as-built design was being evaluated. In the pilot evaluation, design assumptions were always followed with a specific design requirement intended to assure that the detailed plant design would be consistent with the design assumptions.

S. SMALL and I. POPPEL

46

The methodology assumptions were established prior to starting the evaluation and design assumptions were added throughout the evaluation as they became necessary.

4.5. Establish Acceptance Criteria

The pilot evaluation took advantage of well-formed requirements used to define the D-in-D concept to form the core of the evaluation’s acceptance criteria. If the requirements were met, the results were acceptable.

The main way that the D-in-D concept requirements needed to be augmented, to support their use as acceptance criteria, was by providing definition of what constitutes successful mitigation of an event superimposed with a digital CCF. These criteria were stated in terms of integrity of coolant boundary and/or containment, and in terms of radiological release values at the site boundary. It is important to note that due to the low probability of CCF occurrence the radiological release values can be relaxed from those used in the accident analyses. These criteria can differ by region, and different values can be used within the framework of the digital CCF evaluation method without adversely affecting the overall methodology.

4.6. Evaluate Support Systems

The support systems are evaluated by creating plant-wide ‘architectures’ of the support systems, and then evaluating those architectures against the requirements of the D-in-D concept which are specific to support system functions. Evaluation of the support system functions is performed on a ‘generic’ basis; meaning that digital CCF in the support systems is not explicitly considered against each design basis event, because the support systems are required to function during all design basis events. Evaluation of the support systems concludes:

— A digital CCF which impairs a support system does not adversely affect primary functions in adjacent defence lines;

— Any transients which could be caused by support system CCF can be mitigated within the established acceptance criteria.

4.7. Evaluate Primary Systems

Evaluation of the primary system functions is performed on an event-by-event basis for each event included in the scope of evaluation. First, the functions credited for mitigation of an event in absence of CCF are identified.

Then, the CCF guidelines (addressed in section 4.3) are used to postulate two types of digital CCFs.

— CCF which could impair the credited mitigation functions;

— CCF which could cause the event.

For both cases, functionality which is not affected by the CCF and which can mitigate the event is identified and mitigation of the event using this functionality is assessed against the acceptance criteria. The evaluation of an event concludes when the plant is in a stable, controlled condition with the critical safety functions relevant for that event being maintained. If such a plant state cannot be achieved or if acceptance criteria is not met, then a vulnerability is identified.

4.8. Summarize Vulnerabilities

Throughout performance of the pilot evaluation, when a vulnerability was discovered it was described in detail within the context of the related event. As the size of the evaluation document increased, it became evident that a collection and summary of all discovered vulnerabilities was needed, or else it was difficult to locate specific vulnerabilities of interest. At the conclusion of the pilot, the ‘vulnerability summary’ section was extremely useful for communication of results to project and design managers. It was also a good tool to use for identification of similar vulnerabilities from across the evaluation when considering options to address the vulnerabilities.

5. CONCLUSIONS

A widely accepted methodology to evaluate digital CCF across an integrated plant scope is needed to address the ever-increasing inclusion of digital technology into new NPP designs. Such evaluations should be performed at the plant-level, rather than at the level of individual systems or components. A pilot evaluation of

S. SMALL and I. POPPEL

47 this type was performed with a scope corresponding to IAEA Defence Lines 2, 3 and part of 4. However, it was designed to be scalable to include a larger set of events or CCF failure modes, if desired. The methodology can be used against a detailed plant design to demonstrate acceptability of the design, or against a conceptual plant design to set requirements which, if met, will assure acceptability of the detailed plant design.

The international regulatory community should consider cooperating to endorse a methodology of this type to support the standardization of plant designs across regions. Such standardization improves:

— Safety through shared operating experiences and minimalization of design variants (reducing risk of design errors;

— Cost competitiveness of nuclear power generation technologies.

REFERENCES

[1] NUCLEAR REGULATORY COMISSION, Embedded Digital Devices in Safety-Related Systems, Regulatory Issue Summary 2016-05, Washington, DC (2016).

[2] INTERNATIONAL ATOMIC ENERGY AGENCY, Safety of Nuclear Power Plants: Design, IAEA Specific Safety Requirements No. SSR/1 (Rev. 1), IAEA, Vienna (2016).

© GE-Hitachi Nuclear Energy Americas LLC, published under licence by IAEA, 2017

C. MUELLER et al.

48

DEVELOPMENT OF A METHOD FOR THE ASSESSMENT OF