MDEP Generic Common Position

Multinational Design Evaluation Programme
Generic Common Position
DICWG No1 – PUBLIC USE

Date: 17 June 2013
Validity: until next update or archiving
Version A

MDEP GenericCommon Position
No DICWG-01

Related to : Digital Instrumentation and Controls Working Group activities

COMMON POSITION ON THE TREATMENT OFCOMMON CAUSE FAILURE CAUSED BY
SOFTWARE WITHIN DIGITAL SAFETY SYSTEMS

1MDEP Generic Common Position

Multinational Design Evaluation Programme
Generic Common Position
DICWG No1 – PUBLIC USE

Date: 17 June 2013
Validity: until next update or archiving
Version A

Participation
Countries involved in the MDEP working group Canada, Finland, France, India, Japan, People’s
discussions:
Republic of China, Republic of Korea, RussianFederation, South Africa, the U.A.E., the U.K. andthe U.S.
Countries which support the present common Canada, Finland, France, India, Japan, People’s
position
Republic of China, Republic of Korea, RussianFederation, South Africa, the U.A.E., the U.K. andthe U.S.
Countries with no objection:
Countries which disagree
Compatible with existing IAEA related documents
Yes2MDEP Generic Common Position

Multinational Design Evaluation Programme
Generic Common Position
DICWG No1 – PUBLIC USE

Date: 17 June 2013
Validity: until next update or archiving
Version A

Multinational Design Evaluation Programme
Digital Instrumentation and Controls Working Group

GENERIC COMMON POSITION DICWG NO1 : COMMON POSITION ON THE TREATMENT
OF COMMON CAUSE FAILURES CAUSED BY SOFTWARE WITHIN DIGITAL SAFETY
SYSTEMS

Summary:
The Digital Instrumentation and Controls Working Group (DICWG) has agreed that a common
position on this topic is warranted given the increased use of Digital I&C in new reactor designs, its safetyimplications, and the need to develop a common understanding from the perspectives of regulatory
authorities. This action follows the DICWG examination of the regulatory requirements of the participating
members and of relevant industry standards and IAEA documents. The DICWG proposes a common
position based on its recent experience with the new reactor application reviews and operating plant issues1.
Context:
Common cause failures (CCF)2 have been a significant safety concern for nuclear power plantsystems. The increasing dependence on software-in safety systems for nuclear power plants has increased
the safety significance of CCF caused by software, when software in redundant channels or portions ofsafety systems has some common dependency. For example, the effect of systematic failures can lead to aloss of safety in many ways:

unwanted actuationsa safety function is not provided when needed.

Therefore, nuclear power plants should be systematically protected from the effects of common cause
failures caused by software in DI&C safety systems. Software for nuclear power plant safety systems
should be of the high quality necessary to help assure against the loss of safety (i.e. developed with highquality engineering practices, commensurate quality assurance applied, with continuous improvement
through corrective actions based on lessons learned from operating experience). However, demonstrating
adequate software quality only through verification and validation activities and controls on thedevelopment process has proved to be problematic. Therefore, this common position provides guidance
for the assessment of the potential for CCF for software. It is recognized that programmable logic devices
do not execute software in the conventional sense; however, the application development process using
1

The goal of MDEP is not to independently develop new regulatory standards. Common Positions are not legally binding and do notconstitute additional obligations for the regulators or the licensees but are guidelines, recommendations, or assessments that the MDEP
participants agree are good to highlight during their safety reviews of new reactors. Any MDEP member may decide to implement thecommon positions through its national regulatory process.
2It is not necessary to consider common cause failures due to software errors in the application of the single failure criterion.

3MDEP Generic Common Position

Multinational Design Evaluation Programme
Generic Common Position
DICWG No1 – PUBLIC USE

Date: 17 June 2013
Validity: until next update or archiving
Version A

these devices have many similarities with software development, and the deficiencies that may beintroduced during the application development process may induce errors in the programmable logic
devices that can result in common cause failures of these devices of a type similar to software commoncause failure.
Although deficiencies with the potential to give rise to software common cause failures can be
introduced at all phases of the software life cycle, this common position will only consider the potential forsoftware common cause failures within digital safety system safety functions arising from latent design
deficiencies introduced in any of the three software development activities; software requirements,
software design and software implementation (as illustrated in Figure 1 “Typical digital I&C systemdevelopment lifecycle” of Generic Common Position No.3). While deficiencies created during systemdevelopment life cycle phase activities (e.g. the system requirements phase) can also lead to common cause
failures, these design deficiencies would occur regardless of whether the system developed is using
software or not. As this common position only considers the software requirements, software design, andsoftware implementation lifecycle phases the scope of this document is limited to the consideration of thepotential for software common cause failures caused by the introduction of latent errors in the design ofdigital safety systems.
Definition of terms:
Common Cause Failure: Failure of two or more structures, systems or components due to a single event orcause. [IAEA SSR2/1, 2012]
Diversity: The presence of different attributes between systems or components intended to minimize thepotential for common cause failure.
Generic Common Position on the Treatment of Software Common Cause Failures:
1.

For each design basis event an analysis should be performed to demonstrate that the plant cancope with the effects of a common-cause failure caused by software.
1.1 The analysis should postulate credible CCF caused by software that result in systematicfailures of safety functions.
1.2 The analysis need only consider one postulated CCF caused by software at a time.
1.3 Existing measures can be credited to mitigate the effects of the CCF. However, it should beverified that these measures are sufficient. Where manual action is credited, response times
should be justified in accordance with each country’s acceptance criteria.

2.

Actuation of plant components resulting from credible CCF caused by software should beconsidered by the safety analysis.

3.

Diversity is a way to reduce the potential effects of CCF (e.g. incorporation of inherent diversity
in the design of the instrumentation and control system, or by the use of a diverse backupsystem). It is recognized that there are varying degrees of diversity.
3.1 If CCF caused by software could adversely affect a safety function that is required to respondto a design basis event, a diverse means of effective response (with documented basis)should be provided and its effectiveness should be justified.

4

MDEP Generic Common Position

Multinational Design Evaluation Programme
Generic Common Position
DICWG No1 – PUBLIC USE

Date: 17 June 2013
Validity: until next update or archiving
Version A

3.2 If diversity is proposed to be used in the I&C design to mitigate effects of CCF caused bysoftware, and if adequate mitigation cannot be demonstrated, then the design should be
modified and re-analysed.
3.3 Different member countries have different regulatory positions regarding the quality andclassification of diverse backup systems, and use of manual actions to mitigate against
potential common cause failures caused by software in safety systems (see Annex 1).
Therefore, if a design seeks to mitigate against the potential for CCF caused by software
through the implementation of diverse backup systems or manual action, consideration of
the different member country’s regulatory position regarding the quality and classification ofdiverse backup systems or manual action should be included in the analysis.
4. Different member countries may accept different methods to mitigate against the potential for CCF
caused by software (e.g., formal methods to prove software correctness).
References
IAEA SSR 2/1, “Specific Safety Requirements: Design”, 2012
10 CFR Part 50, “General Design Criteria for Nuclear Power Plants”
USNRC NUREG-0800, Standard Review Plan, Branch Technical Position 7-19, “Guidance for Evaluationof Diversity and Defense-in-Depth in Digital Computer-Based Instrumentation and ControlSystems”, 2012USNRC NUREG/CR-6303, “Method for Performing Diversity and Defense-in-Depth Analyses of Reactor
Protection Systems”, 1994
USNRC Staff Requirements Memorandum to SECY-93-087, Policy, Technical, and Licensing Issues
Pertaining to Evolutionary and Advanced Light-Water Reactor (ALWR) Designs,” Item II.Q, 1993
IEC 60880, “Nuclear power plants - Instrumentation and control systems important to safety - Softwareaspects for computer-based systems performing category A functions”, 2006
IEC 62340, “Nuclear power plants - Instrumentation and control systems important to safety Requirements for coping with common cause failure (CCF)”, 2007
IEEE 379, “Standard Application of the Single-Failure Criterion to Nuclear Power Generating Station
Safety Systems”, 2000
IEEE 603, “IEEE Standard Criteria for Safety Systems for Nuclear Power Generating Stations”, 2009
IEEE 7-4.3.2, “IEEE Standard Criteria for Digital Computers in Safety Systems of Nuclear Power
Generating Stations”, 20105

MDEP Generic Common Position

Multinational Design Evaluation Programme
Generic Common Position
DICWG No1 – PUBLIC USE

Date: 17 June 2013
Validity: until next update or archiving
Version A

Annex 1: National positions
MemberCountryCanada

Diverse Backup System
Classification
Safety (by regulation) for
category A software. For
category B & C, only
redundancy requirement nodiverse backup systemrequirement.

Diverse Backup: Softwarebased or not?
Software-based backup
with full diversity

China

Non-safety class allowed

Software-based allowedwith adequate diversity
demonstrated.

FranceLower safety class

Software-based allowedwith adequate diversity
demonstrated.

Finland

Lower safety class allowed

India

SafetySoftware-based allowedwith adequate diversity
demonstrated.
Software-based allowedwith adequate diversity
demonstrated.

Japan

Non-safety allowed

Hardwired system allowed.

Korea

Non-safety hardware;“safety-related” software

Software-based allowedwith adequate diversity
demonstrated.

RussianFederation

SafetyBoth6When manual, instead ofautomatic, backup allowed?
When manual backup meets
licensing conditions, e.g.
functional/performancerequirements, reliability
when <20 minutes protective
action required, operator
action is allowed withmanager’s approval.
When adequate humanfactors engineering analysis
performed;
When <30-minute protective
action required, automatic
backup systemrecommended.
When adequate humanfactors engineering analysis
performed;
When <30-minute protective
action required, automatic
backup systemrecommended.
No requirements

Design shall not take credit
for operator action within thefirst 30 minutes of Postulated
Initiating Event.
Manual back-up is allowed inJapan, but there is no timerequirement for back-up
system.
 Not allowed for diverse
reactor trip
 Allowed for ESFASManual actions aimed
against safety are prohibitedfor 30 minutes after
emergency is originated.

MDEP Generic Common Position

Multinational Design Evaluation Programme
Generic Common Position
DICWG No1 – PUBLIC USE

Date: 17 June 2013
Validity: until next update or archiving
Version A

MemberCountry
South Africa

Diverse Backup System
Classification

Diverse Backup: Softwarebased or not?

When manual, instead ofautomatic, backup allowed?

UnitedKingdom

Safety or safety related(requirements of IEC62166
and the reliability claim aretaken into consideration)

When adequate humanfactors engineering analysis
has been performed showingthat typically 30 minutes canelapse before the manual
action is required.

United States

Non-safety allowed;“enhanced quality”

A software CCF limit forreliability claims is applied.
Hardware-based backup
systems strongly preferred
due to their inherent design
diversity. Diversity inhardware compared to thatused in primary system alsoa relevant factor inassessment.
Software-based allowedwith adequate diversity
demonstrated.

UAE

Non-safety class allowed

Software-based allowedwith adequate diversity
demonstrated.

When adequate humanfactors engineering analysis
performed;
When <30-minute protective
action required, automatic
backup systemrecommended.
Manual initiation and control
of protective action ispermitted provided that
adequate human factors
engineering analysis has
been performed.
Within 30 min following
onset of initiating event
backup protective action
should be automatic.

Note: MDEP members currently have different safety classifications and definitions for I&C

systems. The IAEA is developing a safety guide (DS-367, “Safety Classification of Structures,
Systems, and Components in Nuclear Power Plants”) to promote harmonization on safetyclassifications. The adoption of this guidance into digital I&C systems by MDEP members would
require revisions to this table.

7