RESEARCH INFORMATION LETTER 1002:

Identification and Analysis of Failure 

Modes in Digital Instrumentation and 

Controls (DI&C) Safety Systems—Expert 

Clinic Findings, Part 2

EXECUTIVE SUMMARY

In Staff Requirements Memorandum (SRM) M080605B, the Commission directed the staff to 

“report the progress made with respect to identifying and analyzing digital I&C failure modes.” 

The desired outcome of this directive was to better enable the staff to make safety assurance 

determinations of digital safety systems.

Three research information letters (RILs), RIL-1001, RIL-1002, and RIL-1003, address the 

Commission’s SRM. RIL-1001 (part 1) dated May 4, 2011 discussed uncertainties that impede 

reasonable assurance determinations of DI&C safety systems containing software. RIL-1002 

(part 2) discusses the staff’s progress with respect to identifying and analyzing DI&C failure 

modes. RIL-1003 (part 3) is scheduled to be completed in early 2015. It will discuss the 

feasibility of applying failure mode analysis to quantification of risk associated with DI&C 

systems.

Eleven sets of DI&C safety system failure modes are identified and compared in this report. 

The staff’s work resulted in one synthesized generic set of system level DI&C failure modes. 

The staff’s analysis found that the synthesized failure modes could be used beneficially to 

support, in part, the development of the design basis of a system, and in the analysis of 

performance-degradation during operation.

The staff’s analysis also found, however, that the synthesized set may not be suitable for 

determining the level of safety of a DI&C safety system. The findings indicate that there may be 

additional system—specific failure modes that have not been identified. Furthermore, some or 

all of the failure modes identified may not manifest in a particular system. As such, the 

synthesized set of failure modes may not be helpful for purposes of making determinations of 

reasonable assurance of safety. The NRC staff is investigating alternative analytical 

approaches to support needs for making better determinations of safety assurance; these 

investigations will continue in future work.

This RIL also includes results from staff investigations on the efficacy of Software Fault Modes 

and Effects Analysis (SFMEA) as a method for identifying faults leading to DI&C system failure, 

i.e., performance – degradation of a safety function. Six distinct SFMEA methods were found, 

but the staff did not find a sound technical basis to require NRC applicants and licensees to 

perform an SFMEA similar to any of these methods. NUREG/IA-0254, “Suitability of Fault 

Modes and Effects Analysis for Regulatory Assurance of Complex Logic in Digital 

Instrumentation and Control Systems,” provides additional information supporting this 

conclusion.

i
The staff used an expert elicitation process to establish its findings as described above. The 

process involved collecting and analyzing information from a diverse panel of safety critical 

digital system experts. These experts were consulted in 2010. In addition, the staff also 

reviewed over 150 public and nonpublic documents and conducted additional interviews with 

experts who were not a part of the elicitation process.

The results of the staff’s efforts have been shared with researchers that are both internal and 

external to the NRC. Specifically, the results have been shared with NRC experts conducting 

research on DI&C probabilistic risk assessment (PRA) methods and researchers from the 

Electrical Power Research Institute (EPRI) who are conducting research on hazard analysis 

methods. This RIL does not address issues related to quantifying the reliability of digital 

systems. The Division of Risk Assessment within the Office of Nuclear Regulatory Research 

(RES) is evaluating appropriate failure modes for the development of probabilistic models for 

DI&C systems.

In summary, the staff finds that the failure modes identified in this RIL may not be suitable for 

determining the level of safety of a DI&C safety system. However, there could be some 

potential benefits if the identified failure modes are applied in the development of the design 

basis of a DI&C system and in analysis of performance degradation modes. No additional work 

will be performed by the NRC to identify additional failure modes. NRC will continue to monitor 

external research on identification of digital system failure modes and seek opportunities to 

share any insights found with its stakeholders.

ii
TABLE OF CONTENTS

Section Page

EXECUTIVE SUMMARY .............................................................................................................i

1. INTRODUCTION............................................................................................................ 6

1.1. Objectives........................................................................................................... 6

1.2. Scope ................................................................................................................. 7

2. ORGANIZATION OF REMAINING SECTIONS .............................................................. 7

3. BACKGROUND.............................................................................................................. 8

4. APPLICABLE NRC REGULATIONS AND GUIDANCE ON FAILURE MODE ANALYSES

......................................................................................................................................10

5. RESEARCH METHOD ..................................................................................................13

5.1. NRC Expert Elicitation .......................................................................................13

5.2. Supplemental NRC Research Activities .............................................................13

6. FINDINGS.....................................................................................................................14

6.1. Digital System Failure Modes Findings ..............................................................14

6.2. Efficacy of SFMEA for Identifying Faults Leading to System Failures.................31

7. CONCLUSIONS............................................................................................................33

7.1. Failure Modes Identified.....................................................................................33

7.2. SFMEA ..............................................................................................................33

7.3. Next Steps .........................................................................................................34

8. GLOSSARY...................................................................................................................35

8.1. Selection of Definitions ......................................................................................35

8.2. Definitions..........................................................................................................35

9. EXPERTS CONSULTED...............................................................................................41

10. CITED LITERATURE ....................................................................................................43

11. LITERATURE REVIEWED BUT NOT CITED ................................................................47

APPENDIX A. THE VOCABULARY RELATED TO FAILURE MODES – A DISCUSSION

.............................................................................................................A-1

A.1. Failure..............................................................................................................A-1

A.2. Reason for Avoiding the Term “Failure” for Software .......................................A-2

A.3. Fault.................................................................................................................A-2

A.4. Error.................................................................................................................A-3

A.5. Stimulus-Response, Event-Action, State-Mode - Concepts to Characterize 

Behavior ..........................................................................................................A-3

A.6. Failure Modes ..................................................................................................A-5

A.7. Fault Modes .....................................................................................................A-6

iii
A.8. Bibliography.....................................................................................................A-6

APPENDIX B. IDENTIFIED SOFTWARE FAULTS AND FAULT MODES SETS .........B-1

B.1. Software Faults and Fault Modes Identified by Source ....................................B-1

B.2. Fault Classification and Taxonomy Schemes.................................................B-14

B.3. Summary of Software Faults and Fault Modes Found....................................B-20

B.4. Bibliography...................................................................................................B-20

APPENDIX C. SOFTWARE FAULT MODES AND EFFECTS ANALYSIS METHODS.C-1

C.1. SFMEA in Literature Reviewed ........................................................................C-1

C.2. Efficacy of SFMEA in Identifying Faults............................................................C-6

C.3. Bibliography.....................................................................................................C-6

APPENDIX D. OPERATING EXPERIENCE AND FAILURE MODES ..........................D-1

D.1. Failure Modes of Induction Motors: Example usage........................................D-1

D.2. Digital System Failure Modes: Utility in organizing operating experience data D-2

D.3. Bibliography.....................................................................................................D-2

APPENDIX E. FAILURE MODE RELATED EFFORTS BY NRC PRA STAFF AND 

OTHER STAKEHOLDERS ..............................................................................E-1

E.1. Probabilistic Risk Assessment Research .........................................................E-1

E.2. Working Group on Risk Assessment (WGRisk) Activities and Results.............E-1

E.3. Halden Research Project Efforts ......................................................................E-2

E.4. Bibliography.....................................................................................................E-3

LIST OF FIGURES

Figure Page

Figure 1 Inter-related research work products....................................................................8

LIST OF TABLES

Table Page

Table 1 Reference Set A - NRC/IRSN Collaboration [2]..................................................16

Table 2 Failure Mode Set B [8]. ......................................................................................18

Table 3 Failure Mode Set C [24]. ....................................................................................19

Table 4 Failure Mode Set D [26]. ....................................................................................20

Table 5 Failure Mode Set E [27]. ....................................................................................21

Table 6 Failure Mode Set F ............................................................................................22

Table 7 Failure Mode Set G [29].....................................................................................23

Table 8 Failure Mode Set H [30]. ....................................................................................23

Table 9 Failure Mode Set I [31].......................................................................................24

Table 10 Failure Mode Set J – WGRisk Activities [32] and [33]. .......................................25

Table 11 Failure Mode Set K [23],[36] ..............................................................................25

Table 12 Summary of Failure Mode Correlations to Reference Set A...............................26

Table 13 Failure Mode Set L – Characterization of Failure Modes of a “Generic” Digital 

Safety System....................................................................................................30

Table 14 Experts Interviewed during NRC’s DI&C Expert Elicitation Activity.....................41

iv
Table 15 Experts Consulted during Additional NRC Research Activities...........................42

Table B-1 Fault/Fault Mode Set 1 [B3]. ............................................................................B-2

Table B-2 Fault/Fault Mode Set 2 [B4]. ............................................................................B-3

Table B-3 Fault/Fault Mode Set 3 [B5]. ............................................................................B-4

Table B-4 Fault/Fault Mode Set 4 [B6]. ............................................................................B-4

Table B-5 Fault/Fault Mode Set 5 [B8]. ............................................................................B-5

Table B-6 Fault/Fault Mode Set 6 [B9]. ............................................................................B-7

Table B-7 Fault//Fault Mode Set 7 [B10]...........................................................................B-8

Table B-8 Fault/Fault Mode Set 8 [B11] ...........................................................................B-9

Table B-9 Fault/Fault Mode Set 9 [B12]..........................................................................B-10

Table B-10 Fault/Fault Mode Set 10 [B1]. ........................................................................B-11

Table B-11 Defect Attributes in [B1] .................................................................................B-15

v
1. INTRODUCTION

This RIL is a result of Commission directions to “report the progress made with respect to 

identifying failure modes” for use in assurance of digital safety systems as stated in Staff 

Requirements Memorandum (SRM) M080605B, “Meeting with Advisory Committee on Reactor 

Safeguards (ACRS),” dated June 26, 2008 [1]. Findings from staff investigations on the efficacy

Software Fault Modes and Effects Analysis (SFMEA)1 for use in software assurance are also 

included in this RIL.

This research information letter (RIL) is the second in a series of three letters (RIL-1001, 

RIL-1002, and RIL-1003) that collectively respond to digital instrumentation and control (DI&C)

related directions in the SRM. RIL-1001, “Software -Related Uncertainties in the Assurance of 

Digital Safety Systems – Expert Clinic Findings, Part 1,” was published on May 4, 2011 [3].

RIL-1003 will discuss the feasibility of applying failure mode analysis to quantification of risk 

associated with digital safety systems.

The insights described in this letter are interim results of a broader research effort to support 

improved regulatory guidance for staff to make reasonable assurance determinations of DI&C 

safety systems.

1.1. Objectives

The objectives of this RIL are to:

1. “Report the progress made with respect to identifying and analyzing DI&C failure modes,”

as directed by the Commission in SRM M080605B [1].

2. Report the findings resulting from the staff investigation on “the efficacy of SFMEA as a 

method for identifying faults leading to system failure,” i.e., performance-degradation of a 

safety function2 in response to ACRS recommendation #4 as detailed in [4].

3. Formally transfer knowledge regarding these research results to licensing reviewers in the 

Office of Nuclear Reactor Regulation (NRR) and the Office of New Reactors (NRO).

4. Add to the basis established in RIL-1001 for research results to be reported in RIL-1003,

“Feasibility of Applying Failure Mode Analysis to Quantification of Risk Associated with 

Digital Safety Systems—Expert Clinic Findings, Part 3.”

1 Whereas the term, “failure modes and effects analysis (FMEA)” is used in the context of the 

overall DI&C system, the corresponding concept for software (and other forms of complex logic) 

in a DI&C system is “fault modes and effects analysis.” Logic does not fail in the traditional sense 

of degradation of a hardware component but the system could fail, due to a pre-existing logic 

fault, triggered by some combination of inputs and system-internal conditions.” [2] (See Appendix 

A) 2 This objective satisfies the staff commitment to the ACRS detailed in NRC staff response letter 

dated December 7, 2010 [4] (See Background).

6

 
1.2. Scope

The scope of this research is limited to organizing existing knowledge about identified failure 

modes for purposes of determining the level of safety of a digital I&C safety system in an NPP. 

The use of the failure modes for other purposes or applications is outside the scope of this work.

Related topics such as guidance for reviewing specific methods for failure mode analysis (such 

as Failure Modes and Effects Analysis), system hazard analysis, development assurance, 

defensive measures, preventative approaches, and hardware/software interactions are outside 

the scope of this RIL and are addressed or will be addressed through ongoing or future Office of 

Nuclear Regulatory Research (RES) efforts with input from the NRC licensing offices.

Although this RIL is not intended to address issues related to quantifying the reliability of digital 

systems, the results and conclusions may provide insights for probabilistic risk assessment 

purposes in related RES efforts (see Appendix E).

2. ORGANIZATION OF REMAINING SECTIONS

Section 3 summarizes the history that led to this RIL. Section 4 presents the regulations and 

guidance pertinent to the content in this report. Section 5 describes the research method. 

Section 6 presents the findings. Section 7 summarizes the conclusions and presents the next 

steps. A glossary of terms used is presented in Section 8. Section 9 through Section 11 list 

respectively the experts consulted, literature cited, and literature reviewed but not cited during 

the research that led to this document.

The appendices contain information that supports and supplements the discussion presented in 

the main body of this document. Appendix A discusses the usage of the terms fault, error, 

failure, event, state, and mode in the context of characterizing behavior. Appendix B presents 

the fault and fault modes found. Appendix C presents several methods that can be called

Software Fault Modes and Effects Analysis. Appendix D discusses the use of failure modes to 

organize operating experience. An overview of research on failure-mode analysis for PRA

activities in which the NRC staff is involved in are discussed in Appendix E.

7
3. BACKGROUND

On June 26, 2008, the Commission issued SRM-M080605B directing the staff to “report the 

progress made with respect to identifying and analyzing digital I&C failure modes, and discuss 

the feasibility of applying failure mode analysis to quantification of risk associated with digital 

I&C” [1]. The Office of Nuclear Reactor Regulation (NRR) took the lead in effecting the 

response with support from RES. On June 6, 2009, the Commission was orally briefed about 

the progress [5].

The Commission direction to the staff has its roots in long standing agency wide efforts to risk 

inform the licensing process [6]. As part of that effort, the RES staff began supporting 

investigations, such as NUREG/CR-6962, “Traditional Probabilistic Risk Assessment Methods 

for Digital Systems,” on state-of-the art probabilistic risk assessment (PRA) methodologies for 

software based DI&C systems [7].

The following information provides an overview (aided with Figure 1) of the history of the 

initiating concerns and how these concerns are addressed by NRC research activities. In 

Figure 1, white boxes represent documents that communicate the concerns resulting in staff 

work efforts, shaded boxes annotated with a circle represent ongoing work, dark-shaded boxes 

represent completed work, and boxes annotated with a star represent future work.

Figure 1 Inter-related research work products

The Advisory Committee on Reactor Safeguards (ACRS) raised concerns at various meetings 

that digital system failure modes were not well understood, and formally brought the concerns to 

the Commission’s attention [8] after reviewing DI&C ISG-03, “Interim Staff Guidance on Review 

8
of New Reactor Digital Instrumentation and Control Probabilistic Risk Assessments”[9] on 

April 11, 2008 [10]. The ACRS discussed its recommendations with the Commission on June 5, 

2008 [11] which led to SRM-M080605B [1].

The NRC research activity, “Analytical Assessment of DI&C Systems" described in 

Section 3.1.5 of the Digital Systems Research Plan fiscal year (FY) 2010 - FY2014 [12], was 

formulated partly to support the NRR response to the Commission. Execution of this plan 

included expert elicitation activities, which are described in Appendix B of RIL-1001 [3]. The 

NRC staff also performed additional research to validate these findings through a literature 

review and discussions with experts who were not part of the elicitation activities described in 

Appendix B of RIL-1001 [3].

Section 3.1.5 of [12] was also intended to address, in part, Objective 2 (stated above), as a 

response [4] to ACRS’ suggestion that “Software FMEA methods should be investigated and 

evaluated to examine their suitability for identifying critical software failures that could impair 

reliable and predictable DI&C performance” [13]. Further amplifying the need for this research, 

the NRC licensing staff has also raised concerns that a complete set of failure modes is not 

known and the frequencies of occurrence for known digital system failure modes are not 

available.

3

To identify research issues of common interest and collaboration opportunities under a bilateral 

agreement between the NRC and the Institut de Radioprotection et de Sûreté Nucléaire (IRSN), 

the latter’s DI&C experts reviewed the NRC Digital Systems Research Plan and indicated 

interest in the research described in Section 3.1.5. A collaborative effort was conducted on one 

of the topics of common interest, Software Fault Modes and Effects Analysis (SFMEA), which 

primarily contributed to Objective 2 and resulted in NUREG/IA-0254 [2]. The results of the 

collaboration with IRSN provided an independent check on the information obtained from the 

NRC expert elicitation activities about the efficacy of SFMEA as a method for identifying faults 

leading to system failures impairing a safety function. The effort also resulted in the 

identification of a set of DI&C system failure modes which are discussed in Section 6.1.1.1.

An overview of ongoing work and future work in Figure 1 is discussed in Section 7.

3 Data from operating experience cannot be aggregated and is statistically insignificant, spotty, and 

scattered. The staff has indicated that operating experience and failure mode data provided by 

industry to support claims of digital equipment reliability in submittals such as Benefits Associated 

with Expanding Automatic Diverse Actuation System Functions [14] has been insufficient [15].

9

 
4. APPLICABLE NRC REGULATIONS AND GUIDANCE ON FAILURE 

MODE ANALYSES

Title 10, Chapter 1, of the Code of Federal Regulations (CFR), regulatory guides (RGs), and 

other NRC-generated documents require or endorse only one method for failure mode analysis. 

This method is called a Failure Mode and Effects Analysis (FMEA). FMEA documentation has 

been accepted to support determinations of reasonable assurance for I&C hardware. The 

regulations and guidance do not provide prescriptive acceptance criteria on the format, or 

content of a failure mode analysis [16].

The following regulations directly mention and require identification of failure modes or failure 

mode analyses:

• 10 CFR 50.34(f)(2)(xxii) states that any application regarding B&W designed plants shall 

“Perform a failure modes and effects analysis of the integrated control system (ICS) to 

include consideration of failures and effects of input and output signals to the ICS.”

• 10 CFR 50.73(b)(2)(ii)(E) states that Licensee Event Reports shall contain “The failure 

mode, mechanism, and effect of each failed component, if known.”

• 10 CFR Part 50, “Domestic Licensing of Production and Utilization Facilities,” 

Appendix A, III., “Protection and Reactivity Control Systems”

General Design Criterion 23 – “Protection System Failure Modes” states that the 

protection system shall be designed to fail into a safe state or into a state demonstrated 

to be acceptable on some other defined basis if conditions such as disconnection of the 

system, loss of energy (e.g., electric power, instrument air), or postulated adverse 

environments (e.g., extreme heat or cold, fire, pressure, steam, water, and radiation) are 

experienced.

• 10 CFR 50, Appendix K, “ECCS Evaluation Models,” I.D.1 — “Single Failure Criterion,” 

states that “An analysis of possible failure modes of ECCS equipment and of their 

effects on ECCS performance must be made.”

Failure mode identification and analysis has also been used to satisfy the following regulations:

• 10 CFR 50.55a(h), “Protection and Safety Systems,” incorporates by reference IEEE 

Standard 603-1991 “IEEE Standard Criteria for safety systems for Nuclear power 

Generating Stations4

,” which in Section 5.1, “Single Failure Criterion,” states that:

“The safety systems shall perform all safety functions required for a design basis event 

in the presence of: (1) any single detectable failure within the safety systems concurrent 

with all identifiable but non-detectable failures; (2) all failures caused by the single 

failure; and (3) all failures and spurious system actions that cause or are caused by the 

4 Regulations in10 CFR Part 50.55a(h)(1) incorporates by reference IEEE Std 603-1991, including 

the correction sheet dated January 30, 1995.

10

 
design basis event requiring the safety functions. The single-failure criterion applies to 

the safety systems whether control is by automatic or manual means.”

In addition to Section 5.1, Clause 4 includes the following statements:

4. Safety system designation. A specific basis shall be established for the design 

of each safety system of the nuclear power generating station. The design basis 

shall also be available as needed to facilitate the determination of the adequacy 

of the safety system, including design changes. The design basis ... shall 

document as a minimum:

...

4.8 The conditions having the potential for functional degradation of safety 

system performance and for which provisions shall be incorporated to retain the 

capability for performing the safety functions ...5

• 10 CFR 50, Appendix A, III, “Protection and Reactivity Control Systems”

Criterion 21 – Protection System Reliability and Testability. The protection system shall 

be designed for high functionality reliability and in-service testability commensurate with 

the safety functions to be performed. Redundancy and independence designed into the 

protection system shall be sufficient to assure that (1) no single failure results in loss of 

the protection function and (2) removal from service of any component or channel does 

not result in loss of the required minimum redundancy unless the acceptable reliability of 

operation of the protection system can be otherwise demonstrated.

• RG 1.53, Revision 2, “Application of the Single-Failure Criterion to Safety Systems” [17]

endorses IEEE 379-2000 [18], which suggests that documentation of a single failure 

analysis through an FMEA may be acceptable. Experience from staff reviews of FMEAs 

has shown that “Each system must be independently assessed to conclude that FMEA 

is sufficiently detailed to provide a useful assessment of the potential failures and effects 

of those failures” [16].

• Part II of RG 1.70, Revision 3, “Standard Format and Content of Safety Analysis Reports 

for Nuclear Power Plants, LWR Edition” [19] communicates that the staff found it 

acceptable that FMEAs be provided for various systems. Specific to I&C systems, [19]

states that FMEAs should be provided for the reactor trip system according to Section 

7.2.2, and engineered safety feature system according to Section 7.3.2. Specific to 

Control Systems Not Required for Safety of [19], Section 7.7.2, states that “analyses 

5 For emerging digital safety systems, characterized by increasing inter-connectivity, interactions, 

and dependence on software, FMEA does not suffice for satisfying Clause 4.8. FMEA does not 

suffice because “the conditions having the potential for functional degradation of safety system 

performance” are not limited to a failure of some part of the system. “Functional degradation of 

safety system performance” can occur due to unintended interactions and couplings, even when 

no component of the system fails. Alternative analytical approaches are needed, for which 

early-stage exploration has started; these investigations should continue. See Draft RIL-1101 

“Technical basis to review hazard analysis of digital safety systems” [ML13331A003].

11

 
should demonstrate that the protection systems are capable of coping with all (including 

gross) failure modes of the control systems.”

12
5. RESEARCH METHOD

The results presented in this RIL were obtained through an expert elicitation process 

(Section 5.1) and supplemented with subsequent NRC research activities (Section 5.2) to 

strengthen the findings and improve the degree of validity of the reported results.

5.1. NRC Expert Elicitation 

Information from a select group of experts was captured in individual elicitation interviews, group 

discussions held during a 2-day expert clinic (see Appendix B of RIL-1001 [3]), and post-clinic 

discussions. Table 14 (Section 09) lists the experts who participated in this elicitation process, 

their affiliation, and their initials. Information provided by interviewed experts is cited with the 

use of their initials in the remainder of this RIL (e.g., [AW] stands for Alan Wassyng).

5.2. Supplemental NRC Research Activities

The NRC staff also sought information from other sources because the expert elicitation did not 

result in a set of digital safety system failure modes for use in determinations of reasonable 

assurance of digital safety systems. Specifically, additional research was needed to find failure 

modes appropriate for evaluating systems like those described in new reactor licensing 

applications.

6 The supplemental information was also reviewed to validate that the information

obtained was representative of the larger DI&C community.

The staff reviewed more than 150 publications from various technical meetings, conferences, 

journals, and non-published documents from organizations7 that have worked on or are 

performing work on the topics addressed in this RIL. The literature review included Software 

Fault Modes and Effects Analysis (SFMEA) - related publications. Results and insights also 

were obtained from licensee and applicant-submitted documents, NRC safety evaluation 

reports, the collaborative effort with IRSN, and other ongoing research activities.8

 Additional 

experts, not present at the expert elicitation activities, also were engaged (See Section 09, 

Table 15). The staff sought diverse perspectives through these supplemental research activities 

to improve validity of the results reported in this RIL.

6 Systems that included features outside previous operating experience such as more software, 

interconnections, interactions, and potential feedback paths. 7 Such as NASA, Jet Propulsion Laboratory, etc. 8 See Appendix E for a description of PRA related work and the Halden Research Project 

Collaboration.

13

 
6. FINDINGS

Section 6.1 presents the DI&C safety system (Objective 1) failure modes identified. Section 6.2

reports the findings on the efficacy of Software Fault Modes and Effects Analysis (SFMEA) as a 

method for identifying faults leading to system failures impairing a safety function (Objective 2).

The information obtained included some terms that had multiple meanings in the sources cited 

and referenced. For the purpose of integrating information drawn from these sources and 

references unambiguously, more specific (narrower) definitions of some terms have been 

selected. Please see Section 8 Glossary and Appendix A. Efforts outside the scope of this RIL 

continue toward a consistent vocabulary across internal and external stakeholders and relevant 

standards.

6.1. Digital System Failure Modes Findings

The surveyed technical community has not identified a complete set of (generic or “standard”)

digital system failure modes suitable for use in reasonable assurance determinations in a digital 

system like those seen in recent new reactor licensing applications (see Footnote 8). Some 

experts indicated that it is unlikely that anyone can identify a complete set of failure modes that 

can occur in a moderately complex digital system [MH, AW, PM, DC]9

. Dr. Michael Holloway 

[MH] summarized that “A comprehensive set depends on the complexity of the system; for any 

system that is moderately complex, you can never be sure that you’ve got a comprehensive 

set.” A comprehensive, complete set is needed to ensure that no critical unanalyzed conditions 

are missed during a regulatory review of a Failure Mode and Effects Analysis (FMEA). 

STUK [20] also reported that “software failure modes are generally unknown—software modules 

do not fail, they only display incorrect behavior.”

As reported in [21], many companies that develop safety critical systems in other industries 

(e.g., aerospace and automotive industries) use two or three generic failure modes10 for

analysis in the early stages of development. Two or three high-level generic failure modes, 

however, are not sufficiently informative for use in assurance of a DI&C safety system11 with 

more software, interconnections, interactions, and potential feedback paths than systems for 

which operating experience has been accumulated.

Section 6.1.1 presents system level DI&C failure modes found through the expert elicitation

process and supplemental research activities.

12 The failure modes identified by each source

9 See Table 14 and Table 15 to decode expert initials. Information provided by interviewed experts 

is cited by the use of their initials in this RIL. 10 Examples provided in this reference include: function not provided when required; function 

provided when not required; function incorrect [21]. 11 NRC sponsored Brookhaven National Laboratory that included another set of three generic failure 

modes: Failure to generate a signal in time (omission failure), Spurious signal (generation of 

signal when it is not required), and Adverse effects on other functions (systems, operators). They 

cautioned, however, that for PRA “the level of modeling detail is established by the objectives of 

the study and the resources available” [22]. 12 Readers note that the failure modes reported in this section may also be reported in the non-cited 

references. See Section 11.0.

14

 
are presented as separate sets (Sets A through K shown in Table 1 through Table 11); patterns 

are seen across these sets. For the purpose of reporting the progress made with respect to 

identifying digital system failure modes (Objective 2) and to summarize what has been learned, 

the staff synthesized information gleaned from sets A through K shown in Table 1 through Table 

11 into one generic13 set (Set L). Section 6.1.2 presents this synthesis of identified generic 

digital safety system failure modes. This study does not claim that Set L is complete. A specific 

system may exhibit some failure mode not identified in Set L. This study does not claim that Set 

L is the best possible synthesis for all kinds of purposes; other synthesized characterizations 

are possible and may be useful for other purposes. However, for the purpose of NPP safety 

system analysis and safety assurance, Set L is more informative than Sets A-K; the extent of its 

utility will be explored in future work.

There are other ongoing efforts at the NRC and among stakeholder organizations to identify and 

analyze failure modes for different objectives and purposes. A description of the NRC research 

projects is provided in Appendix E: Failure Mode Related Efforts by NRC PRA Staff and Other 

Stakeholders. Descriptions of research from stakeholder organizations, such as work reported 

in the Electrical Power Research Institute’s (EPRI’s) “Hazard Analysis Methods for Digital 

Instrumentation and Control Systems” [23], is integrated where appropriate in the body or 

appendices of this report.14

6.1.1. Digital System Failure Modes Identified

Sections 6.1.1.1 through 6.1.1.10 provide an overview of different failure modes as 

characterized in various sources. Discussions on the utility of these sets of failure modes for 

the purpose of organizing data from operating experience of unwanted and possibly unsafe 

behaviors of a digital safety system of a kind that may be used in NPPs are also included.

The primary focus is on identified system-level functional failure modes, in terms of behavior 

change, as manifested at the system output. Some failure modes found were characterized in 

the context of software or some other component, but are analyzed here for insights into how 

system-level failure modes can be characterized. The technical community does not consider 

these sets of failure modes standard or complete.

6.1.1.1. Reference Set A - NRC/IRSN Collaboration

Table 1 shows a set of failure modes, Reference Set A, elicited from IRSN [2]. The failure 

modes are characterized in terms of behavior change, as manifested at the output of a software 

module. This set was selected as the baseline (reference set) because it was the most 

informative characterization of known digital system failure modes before work on RIL-1002 

began.

13 Generic means that the failure modes apply to a broad range of digital safety systems. Additional 

failure modes may be found in specific designs. 14 See Section 6.1.1.11, Footnote 20, and Section B.2.9 for descriptions and insights obtained from 

EPRI’s research.

15

 
Table 1 Reference Set A - NRC/IRSN Collaboration [2]

ID Failure Modes Elaboration Remarks

A.1 Failure to perform the module 

function at the required time

Deviation from requirement in 

time domain

Includes:

• Function completion too 

early

• Function completion too 

late

• No function completion

May not be discovered in 

controlled tests.

A.2 Failure to perform the module 

function with correct value 

Deviation from requirement in 

value domain

Application-specific 

examples:

• value zero

• value too low

• value too high

• value stuck at previous

A.3 Performance of an unwanted 

function by the module

Deviation from expected 

performance of the module

Application-specific example: 

Module interrupt service 

routine interrupts function 

processing.

May be difficult to detect 

during system testing

A.4 Interference or unexpected 

coupling with another module.

Deviation from expected 

system performance due to 

module interactions

More prevalent in 

software-reliant complex 

systems and networked 

systems.

May not be discovered in 

controlled tests or revealed in 

design FMEA.

Since the set of failure modes is small, it would seem to ease the burden of gathering and 

organizing data from operating experience. These failure modes, however, are not discernible 

by direct observation of the physical state of the failed system, as in the case of a simple 

electromechanical relay or similar hardware device. Additional information is needed (e.g., 

run-time history) to determine if the intended function was executed in a timely manner (failure 

mode A.1 in Table 1) or, in the case of a multi-valued output, whether the value was incorrect 

(failure mode A.2 in Table 1).

Failure mode A.3 occurs when a module performs an unintended or unexpected function, but it 

could also have secondary effects. For example, the unintended or unexpected function could 

cause the system to respond in a way that deviates from the expected performance of the 

system. For example, a module could have an integrated function prioritization routine that 

interrupts the cyclic processing of background functions in a manner that causes the 

16
background functions to cease operating. This in turn could cause the system to fail to meet 

schedule constraints on performing background testing functions.

Failure mode A.4 is a case where a module (module X) may produce a correct, timely output, 

but the output interferes with the performance of another module (module Y) in a system. 

Often, module X and module Y may satisfy their respective specifications when evaluated 

individually or even under integrated testing (which is not exhaustive due to its effort-intensive, 

time-intensive nature). Even after failure of module Y in operation, it may be difficult to identify 

such interference from the externally observable states of modules X and Y. Significant 

investigative effort is needed to detect this class of failure modes.

Reference Set A could be used to aggregate and organize operating experience data to 

estimate the historic frequency at which failure modes A.1, A.2, A.3 and A.4 occurred. 

However, in the case of a complex digital safety system for a NPP, the historic frequency of 

occurrence of failure modes A.1, A.2, A.3, and A.4 (in Table 1) would not be very informative 

about the future likelihood of occurrence because of differences across systems and their 

environments, as explained in Appendix D: Operating Experience and Failure Modes.

The same limitation occurs in other sets of failure modes, which are discussed in 

Section 6.1.1.2 through Section 6.1.1.10. In these sections, Reference Set A is used for 

comparison with characterizations reported in these sections and accompanying tables.

6.1.1.2. Failure Mode Set B

In [8], the ACRS provided an “example list” of processor-level “failure modes” as a starting point 

for the NRC’s study to identify a “comprehensive” set of failure modes for a digital safety 

system. In this example, a “task” implies a “real-time program executing under control of a 

kernel or operating system”; the “real-time program” is some unit of work in the application 

software.

In Table 2, failure mode B.1 through failure mode B.6 can be abstracted into the behavior 

change of a digital safety system (within which these tasks are executing), as manifested at its 

output, in the following manner. Failure modes B.1, B.2, B.3, B.4, and B.6 can be mapped (⇒) 

into failure mode A.1 (see Table 1). Failure mode B.5 can be mapped into failure mode A.2. 

Failure mode B.5 also can be mapped into failure mode A.3. However, the characterization of 

failure mode B.5, by itself, does not provide enough information to determine whether the 

system-level effect is failure mode A.2 or failure mode A.3. While Set B may be useful for 

diagnostic analysis at a component level, its value addition over Reference Set A is unclear for 

the purpose of organizing operating experience data.

17
Table 2 Failure Mode Set B [8].

ID Failure Modes Elaboration Remarks/Mapping

B.1 Task Crash The control software task 

exits unexpectedly. ⇒A.2

B.2 Task Hang The process goes into an 

infinite loop. ⇒A.1

B.3 Task Late Response

The output of the task 

exceeds the specified 

response time.

⇒A.1

B.4 Task Early Response The output of the task is too 

early ⇒A.1

B.5 Task Incorrect Response

The output of the task is 

timely but violates 

specifications.

⇒{A.2 or A.3}

B.6 Task No Response

There is no output from the 

task (but the task is not 

suspended).

⇒A.1

Also, there could be some other kind of task-level “misbehavior” that prevents progress of 

execution of an application program without anything “failing” (e.g., a task waiting or blocked for 

something else). The wait could be indefinite, in case of a deadlock condition. Consider 

collecting experiential data about digital system failures at such a level of detail: First, the set of 

“failure modes” would have to be expanded to cover missed cases, such as those discussed 

above. Next, each failure incident would have to be analyzed to identify the particular “mode.” 

In current practice, such information is not available. Secondly, the information may not be 

enough to determine future likelihood of occurrence from past frequency of occurrence for the 

same reasons that were mentioned in the discussion for Table 1 above.

6.1.1.3. Failure Mode Set C 

In “Effective Application of Software Safety Techniques for Automotive Embedded Control 

Systems,” [24], which is based on SAE Standard ARP 5580 [25] and tried in the automotive 

component industry, failure mode set {C.1, C.2, C.3, C.4} is considered applicable to all 

software components. As shown in Table 3, failure mode C.1 is mappable into failure mode 

A.1. With failure mode C.2, if no output is produced, the failure mode corresponds to {B.1 or 

B.2 or B.6}, all of which map into A.1. Further, in C.2, if an output is produced, the failure mode 

corresponds roughly to {B.2 or B.6}, both of which map into A.1.

Failure mode C.3 could correspond to B.3 or B.4 (both mappable into A.1). Failure mode C.4 

corresponds roughly to B.5 (mappable into A.2 or A.3). Thus, in Failure Mode Set C, failure 

mode C.1 through failure mode C.4 are not more informative than Reference Set A.

18
In [24], failure modes C.5 and C.6 are considered applicable only to interrupt service routines 

(ISR). However, failure mode C.5 could apply to any called routine. Furthermore, if failure 

mode C.5 does not complete or return, it could block the progress of the calling routine or 

program. The effect is similar to failure mode B.5 above.

Table 3 Failure Mode Set C [24].

ID Failure Modes Elaboration Remarks/Mapping

C.1 Failure to execute ⇒A.1

C.2 Executes incompletely No output produced

Output produced

⇒{B.1 or B.2 or B.6}⇒A.1

⇒{B.2 or B.6}⇒A.1

C.3 Executes with incorrect timing 

Includes:

• incorrect activation time

• incorrect execution time

⇒A.1

C.4 Erroneous execution Includes incorrect output 

value

Similar to B.5.

⇒{A.2 or A.3}

C.5 Failure to return

Subsumes “failure to 

complete” failure mode 

Effect: Prevents execution of 

tasks with lower priority.

Similar to B.5. ⇒{A.2 or A.3}

Applicable only to “interrupt 

service routine” (ISR) type of 

software

C.6 Returns incorrect priority

Applicable only to ISR in an 

operating system using 

priority-based scheduling of 

tasks.

Failure mode C.6 provides more specific information about a misbehaving interrupt service 

routine (ISR). However, a system-specific analysis is needed to determine the effect on the 

system behavior. If the analysis finds that system safety is affected, [24] suggests means of 

mitigation be devised. However, addition of components may create new hazards and may 

increase system complexity. In contrast, the developer should consider correcting the defect 

(eliminating the failure mode). If correctness of the original software cannot be assured, it is 

unclear how correctness of the mitigating means could be assured. While Set C may be useful 

for diagnostic analysis at a component level, its value addition over Reference Set A is unclear 

for the purpose of organizing operating experience data.

6.1.1.4. Failure Mode Set D 

“Software FMEA Techniques” [26] suggests a generic set of failure modes for consideration at 

the early stage of the system development lifecycle to analyze the effects of failures, identify 

commensurate requirements and constraints, rework the architecture, and iterate until all 

identified failure modes are addressed.

19
Failure Mode Set D was developed from experience in the analysis of automotive embedded 

systems (called electronic control units) for controlling brakes, steering, and engine throttle. In 

Table 4, failure mode D.1 is an abstraction of all possible combinations of incorrect inputs (i.e.,

the analysis examines the effect of all incorrect sets of inputs). Similarly, failure mode D.2 is an 

abstraction of all possible combinations of incorrect outputs (i.e., the analysis examines the 

effect of all incorrect sets of outputs). Failure mode D.2 roughly corresponds to B.5 and C.4.

Failure modes D.2, D.3, D.4, and D.5 require system design information at a level of detail that 

may not be available at the system architecture design phase or even at the software 

architecture design phase. Furthermore, system level analysis requires consideration of the 

failure modes of the elements of the system, which, in [26] are the same as the set {C.1, C.2, 

C.3, C.4} discussed above. Often, this level of detail is not developed at the system and 

software architecture design phases of the development lifecycle for a new system.

Table 4 Failure Mode Set D [26].

ID Failure Modes Elaboration Remarks

D.1 Input value incorrect ⟹A.2

D.2 Output value corrupted Logically complete set

Similar to B.5 and C.4

⟹A.2 or A.3

D.3 Blocked interrupt

Does not map to Set A. This 

level of detail is not available 

at the system level.

D.4 Incorrect interrupt return 

Includes:

• incorrect priority

• failure to return

Does not map to Set A. Does 

not map to Set A. This level 

of detail is not available at the 

system level.

D.5 Priority errors Causality-oriented 

characterization.

D.6 Resource conflict Logically complete set of 

resource conflicts.

Causality-oriented 

characterization.

⇒A.4.

In [26] and in an interview with the NRC, [PG] cautions about the significant (often prohibitive) 

amount of effort required to perform a FMEA on software elements15. While Set D may be 

useful for diagnostic analysis at a component level, its value addition over Reference Set A is 

unclear for the purpose of organizing operating experience data.

6.1.1.5. Failure Mode Set E

In “Industry Survey of Digital I&C Failures” [27], Korsah, et al., report failure modes identified in 

a variety of surveyed failure databases. Many of these databases are identified in ANSI/IEEE 

15 Software FMEA requires identification of the failure mode of every algorithm and every variable.

20

 
Std 500-1984, “IEEE Standard Reliability Data for Pumps and Drivers, Actuators, and Valves” 

[28]. IEEE Std 500-1984 databases have been used by various industries to organize 

instrumentation failure data. Table 5 summarizes the relationship of the Failure Mode Set E 

failures with the Reference Set A categories.

Table 5 Failure Mode Set E [27].

ID Failure Modes Elaboration Remarks/Mapping

E.1 Zero or maximum output Original Source: [28] ⟹A.2

E.2 No change of output with 

change of input

Has “no change on demand” 

[28] ⟹A.2

E.3 Functioned without signal Has “change without 

demand” [28] ⟹A.3

E.4 No function with signal

A special case of E.2.

It could also be the “zero 

output case” of E.1.

⟹A.2

E.5 Erratic output Original Source: [28]

Could have effects that are 

different from A.2 (output has 

incorrect value, but it may be 

stable) and should be 

considered for inclusion in a 

set more comprehensive than 

A – see Set L in Table 13.

E.6 High output Original Source: [28] ⟹A.2

E.7 Low output Original Source: [28] ⟹A.2

E.8 Functioned at improper signal 

level

May be viewed as a special 

case of E.3 or E.5

⟹A.3

E.9 Intermittent Operation

The term “intermittent” is 

sometimes used for a case 

where failure occurs 

intermittently. However, 

users logging operational 

experience data might not 

have such a meaning 

consistently.

Could have effects that are 

different from A.2 (output has 

incorrect value, but it may be 

stable) and should be 

considered for inclusion in a 

set more comprehensive than 

A – see Set L in Table 13.

Set E lacks the information provided by failure mode A.1 (incorrectness in time) and failure 

mode A.4 (unwanted effect on some other item). Thus, in this respect, Failure Mode Set E is 

not as informative as Reference Set A. However, failure mode E.5 and failure mode E.9 could 

have effects that are different from failure mode A.2 (output has incorrect value, but it may be 

stable) and should be considered for inclusion in a set more comprehensive and informative

than Reference Set A – see Failure Mode Set L in Table 13.

21
6.1.1.6. Failure Mode Set F

Dr. Sergio Guarro abstracted Failure Mode Set F from databases of anomalies and failures at 

the National Aeronautics and Space Administration (NASA) and Jet Propulsion Laboratory 

(JPL). Failure mode F.1 is specific to a servo-controlled function and oriented to causality rather 

than behavior change observable at output. Failure mode F.1 maps to failure mode A.1, failure 

mode A.2, or failure mode A.3, depending on the type of failure. Failure mode F.2 maps into 

failure mode E.4, which maps into failure mode A.2. Failure mode F.3 maps into failure mode 

E.4, which maps into failure mode A.2. Failure mode F.5 could map into any of failure mode 

E.1, failure mode E.2, failure mode E.5, failure mode E.6, or failure mode E.7, which map into 

failure mode A.2 (except failure mode E.5). Table 6 summarizes the relationship of the Failure 

Mode Set F failures with Reference Set A.

Table 6 Failure Mode Set F

ID Failure Modes Elaboration Remarks/Mapping

F.1 Continuous Control Failure

Control set point too high

Control set point too low

Control algorithm 

overcorrecting

Control algorithm under 

correcting

Causality-oriented 

characterization.

⇒A.1 or

⇒A.2 or 

⇒A.3

F.2 Failure to Activate Upon demand ⇒E.4⇒A.2

F.3 Inadvertent Activation Includes premature 

activation. ⇒A.3

F.4 Redundancy Management 

Failure

Application-specific 

examples:

VMC and SIGI redundancy 

management failure

Does not map to Reference

Set A.

F.5 Failure to Run Correctly

⇒ A.1, A.2, A.3, or A.4.

⇒E.1⇒A.2 or 

⇒E.2⇒A.2 or

⇒E.5 or

⇒E.6⇒A.2 or

⇒E.7⇒A.2.

Application-specific 

examples:

• Value zero

• Value too low

• Value too high

• Value stuck at previous

6.1.1.7. Failure Mode Set G 

In “How FMEA Improves Hardware and Software Safety & Design Reuse” [29], Bidokhti 

identifies Failure Mode Set G for a functional FMEA performed at the top-level software 

architecture. Failure modes G.1, G.2, and G.3 are the same as failure modes C.1, C.2, and 

22
C.3, but failure mode G.4, “Errors in the assigned functioning,” is not specific or clear enough to 

be usable consistently. If the intended meaning is “mistake in allocation of a function to a 

software element,” then the characterization is causality-oriented rather than in terms of 

behavior change, as manifested at the output.

Bidokhti also mentions other types of FMEA. For hardware-software interface issues, a set of 

failure modes are identified as failure to update value; incomplete update of value; value update 

occurs at incorrect time; and errors in value or message. Conceptually, these failure modes 

correspond to G.1, G.2, G.3, and G.4, respectively.

Table 7 summarizes the relationship of the Failure Mode Set G failures with Reference Set A.

Table 7 Failure Mode Set G [29]

ID Failure Modes Elaboration Remarks/Mapping

G.1 Failure to Execute Conceptually, failure to 

update value ⇒C.1⇒A.1

G.2 Incomplete Execution Conceptually, incomplete 

update of value

⇒C.2⇒{B.1 or B.2 or 

B.6}⇒A.1

⇒C.2⇒{B.2 or B.6}⇒A.1

G.3 Execution at an incorrect time Conceptually, value update 

occurs at incorrect time ⇒C.3⇒A.1

G.4

Errors in the assigned 

functioning Conceptually, errors in value 

or message

Does not map to Set A. 

Causality-oriented. This level 

of detail is not available at the 

system level.

6.1.1.8. Failure Mode Set H [30]

In “Failure Modes and Effects Analysis (FMEA) and Systematic Design” [30], Murdoch, et al., 

cluster failures into two groups {H.1, H.2}, which could be viewed as generic failure modes, 

since the authors use the expression, “A system may generally fail in one of two ways.” 

However, H1 is a causality-oriented characterization, and H2 is mappable into A.4. Failure 

modes H1 and H2 could also be viewed as categories of failures rather than failure modes.

Table 8 summarizes the relationship of the Failure Mode Set H failures with Reference Set A.

Table 8 Failure Mode Set H [30].

ID Failure Modes Elaboration Remarks/Mapping

H.1 System Failure resulting from 

component failure H.1 is causality-oriented Does not map to Set A.

H.2

Unintended functioning when 

all components are behaving 

according to specification.

⇒A.4

23
6.1.1.9. Failure Mode Set I - FMEA Approach for Reliability Modeling of Digital I&C [31]

In “A Generic Failure Modes and Effects Analysis (FMEA) Approach for Reliability Modeling of 

Digital Instrumentation and Control (I&C) Systems” [31], Chu, et al., characterize two failure 

modes for analog output signals, I.1 and I.2. While these modes may be typical of analog 

hardware failures, a system function failure due to software could also result in other incorrect 

values. Chu et al. characterize four failure modes for digital output signals, I.3, I.4, I.5, and I.6. 

However, only binary valued outputs are considered, even though digital outputs can be 

multi-valued (e.g., motor speed to adjust fluid flow rate). Thus, the Set, I, by itself, is not 

sufficient for characterizing failure modes of digital safety systems in general.

Table 9 summarizes the relationship of the Failure Mode Set I failures with Reference Set A.

Table 9 Failure Mode Set I [31]

ID Failure Modes Elaboration Remarks/Mapping

I.1 Signal fails high Applicable to analog signals

Only binary valued outputs 

are considered even though 

multi-valued digital outputs 

are possible in digital I&C 

safety systems.

I.2 Signal fails low

This failure mode includes 

loss of signal. Applicable to 

analog signals

I.3 Normally closed, fails closed 

(NCFC)

Applies to digital signals I.4 Normally closed, fails open 

(NCFO)

I.5 Normally open, fails closed 

(NOFC)

I.6 Normally open, fails open 

(NOFO)

6.1.1.10. Failure Mode Set J – WGRisk Activities16 [32]

In “A Summary of Taxonomies of Digital System Failure Modes Provided by the DIGREL Task 

Group” [32], and “Development of Best Practice Guidelines on Failure Modes Taxonomy 

Reliability Assessment of Digital I&C Systems for PSA” [33], Chu, Holmberg, et al., reported 

Failure Mode Set J. Failure mode J.1 and failure mode J.5 do not appear to provide any 

information more than failure mode J.7. Failure mode J.6 (causality-oriented) is subsumed in 

failure mode J.5. Thus, the seven failure modes identified in Failure Mode Set J have

effect-oriented information equivalent to four failure modes: J.2, J.3, J.4, and J.7. Failure mode 

J.2 corresponds to failure mode A.1. Failure mode J.3 corresponds to failure mode A.3. Failure 

mode J.4 corresponds to failure mode A.4. Failure mode J.7 (no actuation signal when 

demanded) may be viewed as a special case of failure mode A.2 (failure to perform the function 

with correct value). Thus, Failure Mode Set J does not provide any more information than 

16 Note that these failure modes are compiled from intermediate results of ongoing and evolving 

work. These examples of failure modes compiled for this work were compiled from 10 different 

organizations participating in the WGRISK Group for a Reactor Protection System. See 

Appendix E, Section E.2 for more information.

24

 
Reference Set A. The latter is more comprehensive because failure mode A.2 is more 

comprehensive than failure mode J.7 for the purpose of safety assurance.17

Table 10 summarizes the relationship of the Failure Mode Set J failures with Reference Set A.

Table 10 Failure Mode Set J – WGRisk Activities [32] and [33].

ID Failure Modes Elaboration Remarks/Mapping

J.1 Failure to actuate ⇒A.2

J.2 Failure to actuate in time ⇒A.1

J.3 Spurious actuation ⇒A.3

J.4 Adverse effects on other 

functions ⇒A.4

J.5 Loss of function

⇒A.1 or

⇒A.2

J.6 Loss of communication Causality-oriented

⇒J.5⇒A.1, or

⇒A.2

J.7 No actuation signal when 

demanded ⇒A.2 (special case)

6.1.1.11. Failure Mode Set K

EPRI’s ongoing Hazard Analysis Methods for Digital Instrumentation and Control Systems 

project, in part, researched, evaluated, and developed different methods for identifying ways in 

which adverse impact on nuclear safety and operability can occur [34]. Industry sponsored this 

work, because plants were experiencing unexpected/unwanted behaviors from some DI&C 

systems, even after extensive FMEAs [35]. EPRI summarized its interim project report [23] in a

presentation to the ACRS on September 19, 2013 [36]. Some of the methods tried by EPRI do 

not use the term “failure modes” but other terms such as guidewords, deviations, or unsafe 

control actions [23] [36]. Table 11 shows a set of “failure modes” identified in the Functional 

Failure Modes and Effects Analysis method.

Table 11 Failure Mode Set K [23],[36]

ID Failure Modes Elaboration Remarks/Mapping

K.1 No Function ⇒A.1

K.2 Partial Function ⇒A.1

K.3 Over Function ⇒A.3

17 It is acknowledged that Set J is more informative than Reference Set A for diagnostic analysis.

25

 
K.4 Degraded Function ⇒A.4 or A.2

K.5 Intermittent Function ⇒E.9 no mapping to 

Reference Set A

K.6 Unintended Function ⇒A.3

6.1.1.12. Summary of Failure Mode Correlations to Reference Set A

Table 12 summarizes the correlation of Failure Mode Set B through Failure Mode Set K with 

Reference Set A. Readers should note that not all failure modes mapped to Reference Set A. 

Reference Set A does not constitute a complete set of digital system failure modes.

Table 12 Summary of Failure Mode Correlations to Reference Set A

ID

A.1 A.2 A.3 A.4

Failure to perform 

the module function 

at the required time

Failure to perform 

the module function 

with correct value

Performance of an 

unwanted function 

by the module

Interference or 

unexpected 

coupling with 

another module

B.1 X

B.2 X

B.3 X

B.4 X

B.5 X X

B.6 X

C.1 X

C.2 X

C.3 X

C.4 X X

C.5 X X

C.6

D.1 X

26
Table 12 Summary of Failure Mode Correlations to Reference Set A

ID

A.1 A.2 A.3 A.4

Failure to perform 

the module function 

at the required time

Failure to perform 

the module function 

with correct value

Performance of an 

unwanted function 

by the module

Interference or 

unexpected 

coupling with 

another module

D.2 X X

D.3

D.4

D.5

D.6 X

E.1 X

E.2 X

E.3 X

E.4 X

E.5

E.6 X

E.7 X

E.8 X

E.9

F.1 X X X

F.2 X

F.3 X

F.4

F.5 X X X X

27
Table 12 Summary of Failure Mode Correlations to Reference Set A

ID

A.1 A.2 A.3 A.4

Failure to perform 

the module function 

at the required time

Failure to perform 

the module function 

with correct value

Performance of an 

unwanted function 

by the module

Interference or 

unexpected 

coupling with 

another module

G.1 X

G.2 X

G.3 X

G.4

H.1

H.2 X

I.1

I.2

I.3

I.4

I.5

I.6

J.1 X

J.2 X

J.3 X

J.4 X

J.5 X X

J.6 X X

J.7 X

28
Table 12 Summary of Failure Mode Correlations to Reference Set A

ID

A.1 A.2 A.3 A.4

Failure to perform 

the module function 

at the required time

Failure to perform 

the module function 

with correct value

Performance of an 

unwanted function 

by the module

Interference or 

unexpected 

coupling with 

another module

K.1 X

K.2 X

K.3 X

K.4 X X

K.5

K.6 X

Some other reported “failure modes” are not included in Table 2 through Table 11 because 

those failure modes could not be related to the system function level or because of differing 

interpretations of the term “failure mode.” For example, failure modes of digital components 

such as microprocessors, and static random access memory (SRAM), which can be found in 

references such as [31] and [37], are not included in Table 2 through Table 11 because the 

failure modes listed are specific to such digital hardware components. Appendix B lists 

examples that do not align with the definition of “failure mode” used in this RIL, but are aligned 

with the definitions of “fault” or “fault mode.”

6.1.2. A Synthesized Set of Digital System Failure Modes

The sets of failure modes in Section 6.1.1 exhibit patterns that indicate utility from different 

sources and perspectives. For the purpose of reporting the progress made with respect to 

identifying digital I&C failure modes (Objective 2), Table 13 shows a set of digital system failure 

modes (L.1-L.9) synthesized from informative characterizations reported in Section 6.1.1 such 

that Set L is more informative than any one set reported in Section 6.1.1.

29
Table 13 Failure Mode Set L – Characterization of Failure Modes of a “Generic” Digital 

Safety System.

ID Failure Mode Elaboration Remarks/Mapping

L.1 No output upon demand Includes no change in output 

or no response for any input ⟹A.2

L.2 Output without demand e.g., Unwanted response ⟹A.3

L.3 Output value incorrect Incorrect response to input or 

set of inputs

⟹A.2

Includes:

• Value too high or too low; 

Value stuck at previous value, 

e.g., ON, OFF

L.4 Output at incorrect time Too early; 

Too late.

⟹A.1

L.5 Output duration too short or 

too long.

This mode is specific to 

continuous functions.

No direct mapping, but 

related to A.1, C.3 and F.1

L.6 Output intermittent

Functions correctly 

intermittently Example: 

Loose connection

⟹E.9

No mapping to Reference Set 

A

L.7 Output flutters

Unwanted oscillation; output 

fluctuates rapidly Example: 

Unstable servo-loop.

Could damage equipment.

⟹E.5

No mapping to Reference Set 

A

L.8 Interference

Affects another system, often 

resulting from unwanted, 

unintended interactions, 

coupling, or side effects.

⟹A.4

30
Table 13 Failure Mode Set L – Characterization of Failure Modes of a “Generic” Digital 

Safety System.

ID Failure Mode Elaboration Remarks/Mapping

L.9 Byzantine behavior

Possible in a distributed 

system.

Could affect redundant 

elements of a system.

Could be caused by software

(e.g., propagating and 

worsening effect of round-off 

error).

Could be caused by 

hardware, (e.g., single-bit 

hardware fault caused 

Amazon S3 system failure in 

2008) [33].

⇒J.4⇒A.4

Although Set L in Table 13 is the most informative generic set synthesizable from the surveyed 

literature, there may be other system-specific failure modes, worthy of distinct identification, 

because the corresponding consequences can be distinguished usefully. Failure mode L.5 

through failure mode L.8, at some moment, could be construed to be a special case of one of 

the other failure modes (L.1, L.2, L.3, or L.4) in failure mode Set L; these are identified distinctly, 

because the consequences could be different or the recovery paths could be different. A 

particular system may not exhibit all of the failure modes in Set L. For example, failure mode 

L.5 would not be useful in a system that provides only discrete outputs, (i.e., does not provide 

any continuous control function). A particular system may also exhibit unexpected or undesired 

behaviors not characterized in Set L.

Nevertheless, Set L could be used beneficially to support, in part, development of the design 

basis of a system, as well as in the diagnostic analysis of performance-degradation during 

operation. The extent of its utility in NPP safety system analysis and safety assurance will be 

explored in future work.

6.2. Efficacy of SFMEA for Identifying Faults Leading to System 

Failures

Software is not subject to wear and tear or degradation in the same manner as hardware and 

does not exhibit failure in that sense. The potential effect of faulty software is considered in 

terms of system failure modes (i.e., performance-degradation of the safety function) and is 

identified in Section 6.1. The appendices provide more information on the efficacy of Software 

Fault Modes and Effects Analysis (SFMEA) as a method for identifying faults that may lead to 

system failure, i.e., performance-degradation of a safety function (Objective 2). Appendix B 

includes software faults and fault modes identified in the technical literature reviewed and 

identified by interviewed experts. Correlation and synthesis of software fault modes was not 

31
performed because the number of faults found was very large. Many faults and fault modes 

reported in Appendix B may not apply to some software systems.

The staff found six distinct SFMEA processes which are described in Appendix C: Software 

Fault Modes and Effects Analysis Methods.

18 The methods found were all adapted from 

methods originally intended to address hardware failures. None of the methods found were 

developed for purposes of assurance of software or digital safety systems similar to those seen 

in recent new reactor licensing applications.

19 In addition to Appendix C, please see 

NUREG/IA-0254 [2] for more information on SFMEA.

18 Other SFMEA processes were also found but are not discussed in detail because of similarities to 

the six that are discussed in Appendix C. 19 KAERI has applied SFMEA to a small, critical software module, finding a defect that could not be 

found with testing and formal verification. However, KAERI does not claim that it is scalable to 

such systems.

32

 
7. CONCLUSIONS

This RIL is part of an ongoing research effort to improve regulatory guidance concerning digital 

safety systems (See Figure 1). Following are the conclusions with respect to objectives 1 and 2

stated in Section 1.1.

7.1. Failure Modes Identified

The staff identified eleven sets of DI&C system failure modes by interviewing subject matter 

experts and by performing an extensive literature review. These failure mode sets are not 

supported by documented public consensus, and are not endorsed by any accepted standards

for use in determinations of reasonable assurance of a digital I&C safety system with features 

such as software, interconnections, interactions, and potential feedback paths.

The failure modes listed in Failure Mode Sets B – K were compared to Reference Set A 

because it contained the most informative characterizations of known digital system failure 

modes before work on RIL-1002 began. This comparison of the DI&C failure modes found

resulted in one synthesized system level generic set.

The staff’s analysis of the synthesized set of generic failure modes found that they could be 

used beneficially to support partial development of the design basis of a DI&C safety system for 

use in the nuclear industry. The synthesized set could also be useful in the analysis of 

performance-degradation during operation.

The synthesized set of system level DI&C failure modes, however, may not be helpful for 

determining the level of safety of a DI&C safety system. Additional critical generic and 

system—specific failure modes may exist. Some or all of the failure modes identified may not 

manifest in a particular system. In addition, the staff also learned that a digital system may 

experience unintended or undesired behaviors without the occurrence of a failure. As such, the 

synthesized set may not be comprehensive for purposes of making determinations of 

reasonable assurance.

See Section 7.3, Next Steps, for a discussion of the staff’s continuing research efforts to support 

licensing reviews of digital safety systems.

7.2. SFMEA

Appendix B lists the software faults and fault modes obtained by the staff throughout this 

research effort. Appendix C describes six different SFMEA techniques that were adapted from 

techniques originally developed for analyzing hardware failures. No sound technical basis was 

found to require or endorse that any of the SFMEA techniques be performed or submitted as 

part of licensing applications. Therefore, changes to established regulations and guidance is 

not recommended.

33
7.3. Next Steps

RIL-1002 will be followed by RIL-1003, which will discuss the feasibility of applying failure mode 

analysis to quantification of risk associated with digital safety systems. RIL-1003 will complete 

the staff’s work required by SRM M080605B [1]. RES will continue to track progress of external 

research on identification and analysis of digital safety failure modes.

20 The NRC has 

requested that EPRI review the findings in this report and explore a common position on a 

generic set of digital safety system failure modes for analysis or for organizing operating 

experience. 

The NRC will continue to explore common ground with potential utility for reducing uncertainties 

in safety assurance.

A broader hazard analysis approach will be introduced in RIL-1101, which includes the technical 

basis to support NRC licensing staff in the evaluation of an applicant’s digital safety system 

hazard analysis (HA) submission. A project has also been established to investigate the use of 

Safety Demonstration (or Assurance Case) Framework21 as discussed in Section A.6 of 

RIL-1001.

Research to establish an HA-based framework for assurance of digital safety systems is

continuing. The RES staff is working with the NRC licensing staff to address related topics 

outside the scope of this RIL in other ongoing or future RES projects.

20 The failure modes reported as Failure Mode Set J in Section 6.1.1.10 is from an ongoing and 

evolving research effort in which NRC is participating. NRC will continue following this work until 

results are finalized.

21 A safety demonstration framework or assurance case seeks to demonstrate the satisfaction of a 

safety goal through a logical (argument based) organization and integration of evidence from 

verification, validation, and audit activities in digital system development.

34

 
8. GLOSSARY

8.1. Selection of Definitions

Expert elicitation participants and technical references identified a divergence and lack of 

agreement on the vocabulary to discuss the topic with a common understanding [DC, PM, and 

MH] [39] [40]. The glossary focuses on terms that are not commonly understood in the same 

way in the sources informing the content of this RIL, removing or reducing ambiguity by 

selecting and using more specific definitions. Definitions in this RIL are based on definitions 

traceable to authoritative sources22, approximately in the following selection order:

1. definitions provided by 10 CFR Part 50, “Domestic Licensing of Production and 

Utilization Facilities”

2. IEEE 603 – IEEE Standard Criteria for Safety Systems for Nuclear Power Generating 

Stations

3. IEEE Standard 100

4. IEC 60050

5. other engineering standards

6. common acceptable dictionary

The intended usage-scope of these definitions is limited to this RIL. The meanings of 

compound words, terms, and expressions are derived from the meanings of their constituent 

words, as defined in this glossary. Where a word is not defined explicitly in the glossary, it is 

understood in terms of common usage as defined in published dictionaries of the English 

language. Notes are included to explain the meaning derived from such composition. Notes 

are also used to explain the derivation or adaptation from published definitions to suit the scope 

of this document. Notes are also provided where definitions have been modified based on 

learning that occurred after the public release of RIL-1001.

8.2. Definitions

Assure: Confirm the certainty of correctness of the claim, based on evidence and reasoning.

Notes:

1. For example, by proof

2. Derived forms:

2.1. Assurance

22 Authoritative sources may choose to modify definitions of the terms included in this glossary after 

public release of this RIL. This RIL communicates intermediate results of a long term NRC 

research effort. Definitions of future NRC documents may modify the definitions in this RIL with 

consideration of new information.

35

 
2.2. Assurable

2.3. Assurability

3. Claim: A true-false statement about the value of a defined property of a system. 

(Adapted from ISO/IEC TR 15026-1:2010 Systems and software engineering – Systems 

and software assurance – Part 1: Concepts and vocabulary, revised as ISO/IEC DIS 

15026-1:2013. Examples: (1) The system is safe. (2) Property X of the system holds.

3.1. The statement includes the following:

3.1.1. Limitations on the value of the property associated with the claim.

3.1.2. Limitations on the uncertainty of the property value meeting its limitations.

3.1.3. Limitations on conditions under which the claim is applicable.

3.2. The statement may also include the following:

3.2.1. Condition-related uncertainty.

3.3. A limitation may have a single value, may have multiple single values, may have a 

range of values, may have multiple ranges of values, or may be multi-dimensional. The 

boundary of a limitation may be incremental or conditional or probabilistic.

4. Evidence: Data supporting the existence or verity of something. (Adapted from 3.1936 

in ISO/IEC/IEEE 24765 Systems and software engineering – vocabulary, 2010)

5. Reason: Argument: A logical sequence or series of statements from a premise to a 

conclusion. (Adapted from http://www.merriam-webster.com/dictionary/argument. 

Derived forms:

5.1. Reasoning: The use of reason.

5.2. Reasonable: Being in accordance with reason. 

(http://www.merriam-webster.com/dictionary/reasonable)

6. Assurance of a safety system means that the certainty of correctness of the claim about 

its “safety property” is confirmed.

7. Assurance of software means that the certainty of correctness of the claim about its 

contribution to the “safety property” is confirmed. It is expected that the contribution will 

correspond to the allocation of requirements and constraints necessary for supporting 

the system safety property.

Byzantine behavior: In a distributed system, arbitrary behavior in response to a failure or fault

[41].

Note: Arbitrary behavior of an element that results in disruption of the intended system 

behavior.

Complexity: (A) (software) The degree to which a system or component has functionality, 

design or implementation that is difficult to understand and verify. (definition (1)(A) in [42]).

(B) (software) Pertaining to any of a set of structure-based metrics that measure the attribute in

Definition 1A in Ref. [42]. (definition (1)(B) in [42]).

36
Note 1: There is no universally accepted definition of the term “complexity.”23 The notes below 

give some other definitions of complexity to illustrate the diversity of perspectives.

Note 2: Conversely (changing negative expression to positive) Simplicity: The degree to which 

a system or component functionality, design or implementation can be understood and verified.

Note 3: The number of linearly independent paths (one plus the number of conditions) through 

the source code of a computer program is an indicator of control flow complexity, known as 

McCabe's cyclomatic complexity [43].

Note 4: In nontechnical language, we can define the effective complexity of an entity as the

length of a highly compressed description of its regularities [44].

Note 5: An ill-defined term that means many things to many people [45].

Note 6: A system is classified as complex if its design is unsuitable for the application of

exhaustive simulation and test, and therefore its behavior cannot be verified by exhaustive

testing. Source: Defence Standard 00-54, Requirements for safety related electronic hardware 

in defence equipment, UK Ministry of Defence, 1999.

Component: Constituent, elemental, or most primitive parts of a system.

Control System: (A) “an assemblage of control apparatus coordinated to execute a planned 

set of control.” (B) a system in which a desired effect is achieved by operating on the various 

inputs to the system until the output, which is a measure of the desired effect, falls within 

acceptable range of values.” (C) “A system in which deliberate guidance or manipulation is used 

to achieve a prescribed value of a variable.” (D) “A system in which a desired effect is achieved 

by operating on inputs until the output, which is a measure of the desired effect, falls within an 

acceptable range of values.” Note: All definitions are from [42].

Error: The difference between a computed, observed, or measured value or condition and the 

true, specified, or theoretically correct value or condition (definition 8A in [42]).

Failure: The termination of the ability of an item to perform a required function [42] [46].

24

Notes:

1. The following definitions represent the perspectives of different disciplines to reinforce 

the definition given above:

1.1. The termination of the ability of an item to perform a required function (Definition (1)(A) 

in [42]).

1.2. The termination of the ability of a functional unit to perform its required function 

(Definition (1)(N) in [42]).

23 Research is needed to clarify complexity within the context of system safety evaluation. 24 Reference [46] includes a note that this concept as defined does not apply to items consisting of 

software only.

37

 
1.3. An event in which a system or system component does not perform a required function 

within specified limits; a failure may be produced when a fault is encountered 

(Definition (1)(O) in [42]).

1.4. The termination of the ability of an item to perform its required function (Definition 9 in 

[42] from “nuclear power generating station”).

1.5. The loss of ability of a component, equipment, or system to perform a required function 

(Definition 13 in [42] Safety systems equipment in “nuclear power generating stations”).

1.6. An event that may limit the capability of equipment or a system to perform its function(s) 

(Definition 14 in [42] “Supervisory control, data acquisition, and automatic control”).

1.7. The termination of the ability of an item to perform a required function (Definition 15 in 

[42] “nuclear power generating systems”)

2. After failure, the item has a fault [46].

3. “Failure” is an event, as distinguished from “fault” which is a state [46].

4. This concept as defined does not apply to items consisting of software only [46].

Failure mode: (A) The effect by which a failure is observed to occur (adapted from definition 1 

in [42]). (B) The manner in which failure occurs. (adapted from definition 4 in [42]). Note - A 

failure mode is usually characterized by the manner in which a failure occurs.

Fault: the state of an item characterized by inability to perform a required function, excluding 

the inability during preventive maintenance or other planned actions, or due to lack of external 

resources [46]. 25

Notes

1. A fault is often the result of a failure of the item itself but may exist without prior 

failure. (191-05-01 in [46])

2. Following are other definitions, relating “fault” and “defect”:

a. a defect or flaw in a hardware or software component (Definition 13 in

[42]

b. a defect in a hardware device or component; for example, a short circuit 

or broken wire (Definition 9 in [42])

c. Synonym: physical defect 

3. The following definition is specific to software: An incorrect step, process, or 

data definition in a computer program (Definition (7)(A) in [42]).

Fault Mode: One of the possible states of a faulty item, for a given required function [46].

Fault Tree Analysis (FTA): An analysis to determine which fault modes of the subitems or 

external events, or combinations thereof, may result in a stated fault mode of the item, 

presented in the form of a fault tree [191-16-05 in [46]]

25 This definition is different than the definition of Fault used in RIL-1001 because of learning that 

occurred while performing supplemental research activities for RIL-1002.

38

 
Hazard: Potential for harm

Hazard Analysis (HA): The process of examining a system throughout its lifecycle to identify 

inherent hazards and contributory hazards, and requirements and constraints to eliminate, 

prevent, or control them.

Notes:

1. “Hazard identification” part of HA includes the identification of losses (harm) of 

concern.

2. This definition is narrower than many definitions of HA, some of which 

correspond to the NRC’s usage of the term “safety analysis” (as in a safety 

analysis report).

a. The scope of the definition excludes the verification that the 

requirements and constraints have been satisfied.

b. Various HA definitions and descriptions identify artifacts (results, 

including intermediate results) of HA by different names. The 

expression “requirements and constraints” used in this definition (to 

align and integrate them in well-established systems engineering terms) 

subsumes them.

c. The scope of the definition does not include quantification explicitly. 

Where appropriate (e.g., for a hardware component, quantification of its 

reliability would be implicit in the activity of formulating requirements and 

constraints).

Latent Fault: An existing fault that has not been recognized.

Mistake: (A) A human action that produces an unintended result (definition 1 in [42]: electronic 

computation). Note: Common mistakes include incorrect programming, coding, and manual 

operation [42]. (B) A human action that produces an incorrect result (definition C [42]: 

software).

Safety System: System designed (1) to initiate automatically the operation of appropriate 

systems including the reactivity control systems, to assure that specified acceptable fuel design 

limits are not exceeded as a result of anticipated operational occurrences [10 CFR Part 50, 

Appendix A, Criterion 20, “Protection System Functions”]; and (2) to sense accident conditions 

and to initiate the operation of systems and components important to safety [10 CFR Part 50, 

Appendix A, Criterion 20]. (3) A system that is relied upon to remain functional during and 

following design basis events to ensure: (i) the integrity of the reactor coolant pressure 

boundary, (ii) the capability to shut down the reactor and maintain it in a safe shutdown 

condition, or (iii) the capability to prevent or mitigate the consequences of accidents that could 

result in potential offsite exposures comparable to the 10 CFR Part 100, “Reactor Site Criteria,”

guidelines [47].

26

26 A safety system includes but is not limited to a) emergency negative reactivity insertion, b) 

emergency core cooling, c) post-accident radiation removal, d) containment isolation, and e) 

post-accident heat removal.

39

 
Note: IEEE 603-2009 states that “a safety system shall encompass all of the elements required 

to achieve a safety function.” In addition, “safety functions include but are not limited to the 

following: a) emergency negative reactivity insertion, b) emergency core cooling, c) 

post-accident radiation removal, d) containment isolation, and e) post-accident heat removal” 

[48].

Software Fault Mode and Effects Analysis: A qualitative method of reliability analysis, which 

involves the study of the fault modes, which can exist in every sub item of the item, and the 

determination of the effects of each fault mode on other sub items of the item and on the 

required functions of the item.

System: A combination of interacting elements organized to achieve one or more stated 

purposes [49].

40
9. EXPERTS CONSULTED

Table 14 identifies experts consulted during the NRC’s DI&C expert elicitation activity, including 

the initials used in this RIL to refer to them. Table 15 identifies experts consulted after the 

NRC’s DI&C expert elicitation activity, including the symbols used in this RIL to reference their 

names.

Table 14 Experts Interviewed during NRC’s DI&C Expert Elicitation Activity.

Abbreviation Expert and

Affiliation Abbreviation Expert and Affiliation

AW Alan Wassyng

McMaster University JH Jorgen HanssonCarnegie-Mellon University

BJ Barry Johnson

University of Virginia JM John McDermidUniversity of York

CW Chris Johnson

University of Glasgow LS Lorenzo StringiniCity University, London

DC Darren Cofer

Rockwell Collins MB Manfred BroyTechnical University of Munich

DD Dan Dvorak

NASA JPL MD Mike DewaltFederal Aviation Administration

DW David Ward

MIRA Ltd. MH Michael HollowayNASA Langley

GH Gerard Holzman

NASA JPL PJ Paul JonesFood and Drug Administration

JH Jamie Harper

NASA Goddard PM Paul MinerNASA Langley

JB Jens Braband

TS RA SD RAMSS RB Robin BloomfieldCity University, London

JG John Goodenough

Carnegie Mellon University SS Stefan SchaanSiemens

JK John Knight

University of Virginia SP Steve PrushaNASA JPL

41
Table 15 Experts Consulted during Additional NRC Research Activities.

Abbreviation Expert and 

Affiliation

Communications with 

NRC

HH Herbert Hecht

SoHaR Inc.

Tele-meeting

October 10, 2010

PG Pete Goddard

TRW Automotive

Tele-meeting

September 10, 2010

RC Ram Chillarege

Chillarege Inc.

Tele-meeting

September 1, 2010

RL Robyn Lutz

NASA JPL

Private Communications 

w. S. Birla

SG Sergio Guarro

Asca Inc

Informal Presentations 

December 22, 2010 and 

February 23, 2011

42
10. CITED LITERATURE

[1] A. Vietti-Cook, “SRM M8065B, Memorandum: Staff Requirements Meeting with Advisory 

Committee on Reactor Safeguards (ACRS), Thursday, June 5, 2008, Commissioners’ 

Conference Room, One White Flint North, Rockville, MD,” June 2008, Available: 

http://www.nrc.gov/reading-rm/doccollections/commission/srm/meet/2008/m20080605b.pdf, Agencywide Documents Access 

and Management System (ADAMS) Accession Number: ML081780761.

[2] L. Betancourt, S. Birla, J. Gassino, and P. Regnier, NUREG/IA 0254 Suitability of Fault 

Modes and Effects Analysis for Regulatory Assurance of Complex Logic in Digital 

Instrumentation and Control Systems, Nuclear Regulatory Commission, 2011 Available: 

http://pbadupws.nrc.gov/docs/ML1120/ML11201A179.pdf, 

ADAMS Accession Number: ML11201A179.

[3] U.S. Nuclear Regulatory Commission, “Research Information Letter 

1001-Software-Related Uncertainties in the Assurance of Digital Safety Systems -Expert 

Clinic Findings, Part 1,” Available: 

http://pbadupws.nrc.gov/docs/ML1112/ML111240017.pdf, 

ADAMS Accession Number: ML111240017.

[4] R.W. Borchardt, “Response to Advisory Committee on Reactor Safeguards 

Recommendations on Draft Final Digital Instrumentation and Control Interim Staff 

Guidance-06, ‘Licensing Process’,” Dec. 2010, 

ADAMS Accession Number: ML103130193.

[5] “United States Nuclear Regulatory Commission Briefing on Digital Instrumentation and 

Control Transcript,” Jun. 2009, Available: http://www.nrc.gov/reading-rm/doccollections/commission/tr/2009/20090604a.pdf.

[6] U.S. Nuclear Regulatory Commission, “Final PRA Policy Statement,” Aug. 1995, Available: 

http://www.nrc.gov/reading-rm/doc-collections/commission/policy/60fr42622.pdf.

[7] T.L. Chu, G. Martinez-Guridi, M. Yue, J. Lehner, and P. Smanta, NUREG/CR 6962,

“Traditional Probabilistic Risk Assessment Methods for Digital Systems,” U.S. Nuclear 

Regulatory Commission, 2008 Available: 

http://pbadupws.nrc.gov/docs/ML0831/ML083110448.pdf, 

ADAMS Accession Number: ML0803110448.

[8] W. Shack, “Digital Instrumentation and Control Systems Interim Staff Guidance, ACRS 

Letter to NRC Commission,” Apr. 2008, ADAMS Accession Number: ML081050636.

[9] U.S. Nuclear Regulatory Commission, “Interim Staff Guidance on Review of New Reactor 

Digital Instrumentation and Control Probabilistic Risk Assessments” Available: 

http://pbadupws.nrc.gov/docs/ML0805/ML080570048.pdf.

[10] ACRS, “Advisory Committee on Reactor Safeguards 551st Meeting Transcript,” Apr. 2008, 

Available: http://www.nrc.gov/reading-rm/doccollections/acrs/tr/fullcommittee/2008/acrs041108-551.pdf

43
[11] U.S. Nuclear Regulatory Commission, “U.S. Nuclear Regulatory Commission Meeting with 

Advisory Committee on Reactor Safeguards Transcript,” Available: 

http://www.nrc.gov/reading-rm/doc-collections/commission/tr/2008/20080605b.pdf

[12] US, NRC Digital System Research Plan FY 2010-FY 2014 Available: 

http://pbadupws.nrc.gov/docs/ML1005/ML100541484.pdf, 

ADAMS Accession Number: ML100541484.

[13] S. Abdel-Khalik, “Draft Final Digital Instrumentation & Control Interim Staff Guidance-06: 

Licensing Process,” Oct. 2010, ADAMS Accession Number: ML102850357.

[14] Erin Engineering, “Benefits and Risks Associated with Expanding Automated Diverse 

Actuation System Functions”, EPRI, 2008, Available: 

http://pbadupws.nrc.gov/docs/ML0908/ML090860465.pdf, 

ADAMS Accession Number: ML090860465.

[15] R.W. Borchardt, “Status of The Nuclear Regulatory Commission Staff Efforts to Improve 

the Predictability and Effectiveness of Digital Instrumentation and Control Reviews,” 

Available: http://www.nrc.gov/reading-rm/doccollections/commission/secys/2009/secy2009-0061/2009-0061scy.pdf.

[16] NRC, Licensing Process Interim Staff Guidance, Nuclear Regulatory Commission, 2011 

Available: http://pbadupws.nrc.gov/docs/ML1101/ML110140103.pdf, 

ADAMS Accession Number ML110140103.

[17] U.S. Nuclear Regulatory Commission, Regulatory Guide 1.53, Rev. 2, “Application of the 

Single Failure Criterion to Safety Systems,” Available: 

http://pbadupws.nrc.gov/docs/ML0332/ML033220006.pdf.

[18] IEEE 379-2000, IEEE Standard Application of the Single Failure Criterion to Nuclear 

Power Generating Station Safety Systems Available: 

http://standards.ieee.org/findstds/standard/379-2000.html

[19] U.S. Nuclear Regulatory Commission, Part II of Regulatory Guide 1.70 Rev. 3, “Standard 

Format and Content of Safety Analysis Reports for Nuclear Power Plants LWR Edition,”

Available: http://pbadupws.nrc.gov/docs/ML0113/ML011340108.pdf, 

ADAMS Accession Number: ML011340108.

[20] P. Haapanen, “STUK-YTO-TR 190 Failure mode and effects analysis of software-based 

automation systems,” Helsinki: Radiation and Nuclear Safety Authority, 2002.

[21] T. Stålhane, S. Farfeleder, and O. Daramola, “Safety Analysis Based on Requirements,” 

Available: www.cesarproject.eu.

[22] T. -L. Chu, G. Martinez-Guridi, M. Yue, P. Samanta, G. Vinod, and J. Lehner, “Workshop 

on Philosophical Basis for Incorporating Software Failures in A Probabilistic Risk 

Assessment,” Available: http://pbadupws.nrc.gov/docs/ML0927/ML092780607.pdf, 

ML092780607.

[23] Hazard Analysis Methods for Digital Instrumentation and Control Systems.

EPRI, Palo Alto, CA: 2013. 3002000509

44
[24] B.J. Czerny, J.G. D’Ambrosio, B.T. Murray, and P. Sundaram, “2005-01-0785 Effective 

Application of Software Safety Techniques for Automotive Embedded Control Systems,”

Warrendale, PA: SAE International, 2005 Available: 

http://www.sae.org/technical/papers/2005-01-0785.

[25] SAE, SAE ARP 5580 SAE ARP 5580, “Recommended Failure Modes and Effects Analysis 

(FMEA) Practices for Non-Automotive Applications,” 2001.

[26] P.L. Goddard, “Software FMEA Techniques,” Proceedings of the Annual Reliability and 

Maintainability Symposium, IEEE, 2000, pp. 118–123 Available: 

http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=816294.

[27] K. Korsah, M.D. Muhlheim, and D.E. Holcomb, “ORNL/TM-2006/626 Industry Survey of 

Digital I&C Failures,” Oak Ridge National Laboratory/Nuclear Regulatory Commission, 

2007 Available: http://www.ornl.gov/~webworks/cppr/y2007/rpt/125413.pdf.

[28] ANSI/IEEE, “ANSI/IEEE 500-1984 IEEE Standard Reliability Data for Pumps and Drivers, 

Actuators, and Valves”, ANSI/IEEE, 1984 Available: 

http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=35066.

[29] N. Bidokhti, “How FMEA Improves Hardware and Software Safety & Design Reuse,” 

International Workshop on Software Reuse and Safety (RESAFE-2006), Torino, Italy: 

Available: www.favaro.net/john/RESAFE2006/papers/Bidokhti.pdf.

[30] J. Murdoch, J.A. McDermid, and P. Wilkinson, “Failure Modes and Effects Analysis 

(FMEA) and Systematic Design,” International System Safety Conference, 2001 Available: 

ftp://ftp.cs.york.ac.uk/pub/hise/Failure%20Modes%20&%20Effects%20Analysis.pdf.

[31] T. -L. Chu, M. Yue, G. Martinez-, and J. Lehner, “A Generic Failure Modes and Effects 

Analysis (FMEA) Approach for Reliability Modeling of Digital Instrumentation and Control 

(I&C) Systems,” 10th International Probabilistic Safety Assessment and Management 

Conference, Seattle, WA 2010.

[32] T. -L. Chu, M. Yue, and W. Postma, “A Summary of Taxonomies of Digital System Failure 

Modes Provided by the DIGREL Task Group,” PSAM 11, Helsinki, Finland: 2012, ADAMS 

Accession Number: ML120680552.

[33] J. -E. Holmberg, S. Authén, and A. Amri, “Development of Best Practice Guidelines on 

Failure Modes Taxonomy Reliability Assessment of Digital I&C Systems for PSA,” PSAM 

11, Helsinki, Finland, 2012.

[34] B.J. Geddes and R.C. Torok, “Digital System Failure Mode Analysis Methodologies,” 

NPIC&HMIT (2010), Las Vegas, NV, American Nuclear Society, 2010, pp. 1690–1696.

[35] R. Torok and B. Geddes, “Systems Theoretic Process Analysis (STPA) Applied to a 

Nuclear Power Plant Control System,” March 2013, Available: 

http://psas.scripts.mit.edu/home/wpcontent/uploads/2013/04/02_EPRI_MIT_STAMP_Mar2013.pdf.

[36] R. Torok, B. Geddes, and D. Blanchard, “Update on Digital Instrumentation and Control 

Projects - Failure Modes - Hazard Analysis Methods - Operating Experience Review - PRA 

45
Insights,” September 2013, Available: 

http://pbadupws.nrc.gov/docs/ML1327/ML13277A646.pdf.

[37] S.M. Cetiner, K. Korsah, and M.D. Muhlheim, “Survey on Failure Modes and Failure 

Mechanisms in Digital Components and Systems,” NPIC&HMIT (2009), Sixth American 

Nuclear Society International Topical Meeting on Nuclear Plant Instrumentation, Control, 

and Human-Machine Interface Technologies, LaGrange Park, IL: American Nuclear 

Society, 2009.

[38] Amazon S3 Team, “Amazon S3 Availability Event July 20, 2008,” Amazon Web Services

Available: http://status.aws.amazon.com/s3-20080720.html.

[39] N.G. Leveson, Safeware: System Safety and Computers, Addison-Wesley Professional, 

1995.

[40] SoHaR, “Software Failure Modes and Effects Analysis {FMEA},” November 2011, 

Available: www.sohar.com/proj_pub/download/SoHaR_FMEA_Final.pdf.

[41] F. Schneider, Understanding Protocols for Byzantine Clock Synchronization, Cornell 

University, Available: http://hdl.handle.net/1813/6699.

[42] IEEE “IEEE Standards Dictionary: Glossary of Terms and Definitions,” IEEE Std 

100-2000.

[43] T.J. McCabe, “A Complexity Measure,” IEEE Transactions on Software Engineering, Vol. 

SE-2, December. 1976, pp. 308–320.

[44] M. Gell-Mann and S. Lloyd, “Effective Complexity,” June 2003, Available: 

http://www.santafe.edu/media/workingpapers/03-12-068.pdf.

[45] G.W. Flake, The Computational Beauty of Nature: Computer Explorations of Fractals, 

Chaos, Complex Systems, and Adaptation, Cambridge, Mass: MIT Press, 1998 QA76.6 

.F557 1998.

[46] IEC 60050-191 International Electrotechnical Vocabulary - Chapter 191: Dependability 

and Quality of Service, IEC, 1990.

[47] Institute of Electrical and Electronic Engineers (IEEE) 603-1991, IEEE Standard Criteria for 

Safety Systems for Nuclear Power Generating Stations, 1991 Available: 

http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=159411.

[48] IEEE Standard 603-2009, “Standard Criteria for Safety Systems for Nuclear Power 

Generating Stations,” 2009 Available: 

http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5325914.

[49] IEEE Std 15288-2008 “Systems and Software Engineering System Life Cycle Processes,” 

ISO/IEC 15288:2008(E) (Revision of IEEE Std 15288-2004, 2008), pp. 1–84.

46
11. LITERATURE REVIEWED BUT NOT CITED

[NC1] IEEE, “A Discussion of the Term Failure Mode,” IEEE Std 500-1984, Dec. 1983, pp. 22–

26.

[NC2] D. Vallespir and J. Herbert, “A Framework to Evaluate Defect Taxonomies,” 2009.

Available: 

http://sedici.unlp.edu.ar/bitstream/handle/10915/20983/2634.pdf%3Fsequence%3D1

[NC3] N. Ozarin and M. Siracusa, “A Process for Failure Modes and Effects Analysis of 

Computer Software,” Reliability and Maintainability Symposium, 2003. Annual, 2003, pp. 

365–370.

[NC4] T.L. Chu, G. Martinez-Guridi, M. Yue, and J. Lehner, “A Review of Software-Induced 

Failure Experience,” American Nuclear Society 5th Int. Meeting on Nuclear Power 

Instrumentation Control and Human Machine Interface Technology, American Nuclear 

Society, 2006.

[NC5] W. Li and H. Zhang, “A Software Hazard Analysis Method for Automotive Control 

System,” Computer Science and Automation Engineering (CSAE), 2011 IEEE 

International Conference on, 2011, pp. 744–748.

[NC6] E. Fronczak, “A Top-Down Approach to High-Consequence Fault Analysis for Software 

Systems,” Proceedings The Eighth International Symposium on Software Reliability 

Engineering, 1997, p. 259.

[NC7] ACRS, “ACRS Digital I&CS Subcommittee Transcript,” June 2011, Available: 

www.nrc.gov/reading-rm/doc-collections/acrs/agenda/2011/

ADAMS Accession Number: ML111711584.

[NC8] B.J. Czerny, J.G. D’Ambrosio, P.O. Jacob, B.T. Murray, and P. Sundaram, 

“2004-01-1666 An Adaptable Software Safety Process for Automotive Safety-Critical 

Systems,” Warrendale, PA: SAE International, 2004 Available: 

http://www.sae.org/technical/papers/2004-01-1666

[NC9] C. Price and N. Snooke, “An Automated Software FMEA,” Singapore: 2008 Available: 

http://users.aber.ac.uk/nns/publications/papers/SFMEA_ISSRC.pdf

[NC10] M. Grottke, A.P. Nikora, and K.S. Trivedi, “An Empirical Investigation of Fault Types in 

Space Mission System Software,” Dependable Systems and Networks (DSN), 2010 

IEEE/IFIP International Conference on, 2010, pp. 447–456.

[NC11]K. Korsa, M.S. Cetiner, M.D. Mulheim, and Poore III, Willis P., “An Investigation of 

Digital Instrumentation and Control System Failure Modes,” 7th ANS Topical Meeting on 

Nuclear Power Plant Instrumentation, Control, and Human-Machine Interface 

Technology, Las Vegas, NV, 2010 Available: 

http://www.osti.gov/bridge/product.biblio.jsp?osti_id=1038464

47
[NC12] U.S. Nuclear Regulatory Commission, “Branch Technical Position 7-21: Guidance on 

Digital Computer Real-Time Performance, Revision 5 [ML070550070],” March 2007, 

ADAMS Accession Number: ML070550070.

[NC13] B.M. Cook, “Classification of I&C Systems: A Practical Approach,” NPIC&HMIT 2010, 

Las Vegas, NV: American Nuclear Society, 2010, pp. 99–119.

[NC14] A. Vietti-Cook, “COMGEA-11-0001 – UTILIZATION OF EXPERT JUDGMENT IN 

REGULATORY DECISION MAKING,” March 2011, 

ADAMS Accession Number: ML110740304.

[NC15] G. Apostolakis, “COMGEA-11-0001, UTILIZATION OF EXPERT JUDGMENT IN 

REGULATORY DECISION MAKING,” January. 2011, Available: www.nrc.gov/readingrm/doc-collections/commission/comm-secy/2011/2011-0001comgea.pdf,

ADAMS Accession Number: ML110200139.

[NC15] U.S. Nuclear Regulatory Commission, “Common Q Safety Evaluation, Non-Proprietary 

Version,” ADAMS Accession Number: ML003740165.

[NC16] H. Hecht, X. An, and M. Hecht, “Computer Aided Software FMEA,” Computer Press, 

2004.

[NC17] A. Avizienis, “Dependability and Its Threats: A Taxonomy,” Building the Information 

Society:, J. -C. Laprie, B. Randell, and R. Jacquart, eds., Boston: Kluwer Academic 

Publishers, 2004, pp. 91–120.

[NC18] R.R. Lutz and I.C. Mikulski, “Empirical analysis of safety-critical anomalies during 

operations,” Software Engineering, IEEE Transactions on, vol. 30, 2004, pp. 172–180.

[NC19] R. Lutz and A. Nikora, “Failure Assessment,” ISHEM ’05, Napa, CA: 2005.

[NC20] Reliability Analysis Center, “94-12203 Failure Mode, Effects, and Criticality Analysis 

(FMECA),” Reliability Analysis Center, 1993.

[NC21] Omnicon Group Inc., “Failure Modes and Effects Analysis (Brochure),” February 2004, 

Available: 

www.omnicongroup.com/images/pdf/brochures/OmniconSWFMEABrochureRevJ8.5x11

.pdf

[NC22] N. Ozarin, “Failure Modes and Effects Analysis during Design of Computer Software,” 

IEEE, 2011, pp. 201–206 Available: 

http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1285448.

[NC23] M. Hecht, E. Shokri, S. Meyers, E. Nguyen, W. Greenwell, and A. Lam, “Failure Modes 

and Effects Analysis for a Software-Intensive Satellite Control System,” 26th 

International System Safety Conference 2008: ISSC 2008 ; Vancouver, Canada, 25 - 29 

August 2008, Red Hook, NY: Curran, 2009, pp. 612–622.

[NC24] D.R. Wallace and D.R. Kuhn, “Failure Modes in Medical Device Software: an Analysis of 

48
15 Years of Recall Data,” 2001, pp. 301–311.

[NC25] D. Andra, “Failure Modes Presentation,” 2002, Available: 

www.wdtb.noaa.gov/workshop/wdm/originals/FailureModes.pdf

[NC26] Pacific Northwest National Laboratory (PNNL), “Failure Modes: Meaning, Identification 

& Analysis in SW-Intensive DI&C System for Nuclear Power Plant Safety Functions 

(Draft, PNNL D19.Second Evolution),” December 2009.

[NC27] M. Dixit, D. Brenchley, S. Shoemaker, R. Sullivan, and J. Young, “Failure Modes: 

Meaning, Identification & Analysis is SW-Intensive DI&C Systems (Draft PNNL Report, 

D19),” February 2010.

[NC28] H. Zhang, “Fast Abstract: A Study on SFMEA Method for UML-based Software,” 20th 

International Symposium on Software Reliability Engineering, Mysuru, India: IEEE 

Computer Society, 2009

[NC29] W.E. Vesely, F.F. Goldberg, N.H. Roberts, and D.F. Haasl, NUREG 0492 Fault Tree 

Handbook, 1981.

[NC30] N. Bidokhti, “FMEA is Not Enough,” IEEE, 2009, pp. 333–337 Available: 

http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4914698

[NC31] Westinghouse, WCAP-16438-NP, Rev.3, APP-GW-JJ-004, Rev. 0 FMEA of AP1000 

Protection and Safety Monitoring System (Non-Proprietary), 2011 

ADAMS Accession Number: ML110670191.

[NC32] Federal Aviation Administration, “Guide to Reusable Launch and Reentry Vehicle 

Reliability Analysis,” April 2005, Available: 

www.faa.gov/about/office_org/headquarters_offices/ast/licenses_permits/media/FAA_A

ST_Guide_to_Reliability_Analysis_v1.pdf

[NC33] IEC, IEC 61508, Edition 2.0, International Standard: Functional Safety of 

Electrical/Electronic/Programmable Electronic Safety Related Systems - Part 4: 

Definitions and Abbreviations, IEC, 2010.

[NC34] B. Li, “Integrating Software into PRA (Probabilistic Risk Assessment),” Ph.D., University 

of Maryland, College Park, 2004.

[NC35] L. Buglione and A. Abran, “Introducing Root-Cause Analysis and Orthogonal Defect 

Classification at Lower CMMI Maturity Levels,” Available: 

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.90.3192

[NC36] G.Y. Park, D.I. Kim, and C.H. Jung, “Issues on Validation of Programmable Logic 

Design for Digital Instrumentation and Control System,” NPIC&HMIT (2010), Las 

Vegas, NV, American Nuclear Society, 2010, pp. 954–963.

[NC37] N. Carte and D. Halverson, “Licensing Process for Digital Safety Systems,” NPIC&HMIT 

2010, Las Vegas, Nevada: American Nuclear Society, 2010, pp. 1001–1008.

49
[NC38] AREVA NP Inc., ANP-10310NP Methodology for 100% Combinatorial Testing of the 

U.S. EPR(TM) Priority Module, Non-Proprietary Version, AREVA NP Inc., 2011 

ADAMS Accession Number: ML111010480.

[NC39] B. Nolan, B. Brown, L. Balmelli, T. Bohn, and U. Wahli, Model Driven Systems 

Development with Rational Products, [United States?] : IBM, International Technical 

Support Organization, 2008.

[NC40] N. Snooke, “Model-based Failure Modes and Effects Analysis of Software,” Available: 

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.2.1253

[NC41] N. Snooke and C. Price, “Model-Driven Automated Software FMEA,” IEEE, 2011, pp. 1–

6 Available: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5754453.

[NC42] T.L. Chu, M. Yue, G. Martinez-Guridi, K. Mernick, J. Lehner, and A. Kuritzky, 

NUREG/CR-6997 Modeling a Digital Feedwater Control System Using Traditional 

Probabilistic Assessment Methods, Brookhaven National Laboratory/NRC, 2009 

Available: www.nrc.gov/reading-rm/doc-collections/nuregs/contract/cr6997/

[NC43] R. Stattel, “Oconee Digital Safety System Licensing Experience,” NPIC&HMIT (2010), 

Las Vegas, NV: American Nuclear Society, 2010, pp. 977–991.

[NC44] B. Geddes, N. Thuy, and R. Torok, “1016731 Operating Experience Insights on 

Common-Cause Failures in Digital Instrumentation and Control Systems,” EPRI, 2008 

Available: 

http://www.epri.com/abstracts/Pages/ProductAbstract.aspx?ProductId=0000000000010

16731

[NC45] J. Dehlinger and R.R. Lutz, “PLFaultCAT: A Product-Line Software Fault Tree Analysis 

Tool,” Automated Software Engineering, Vol. 13, January 2006, pp. 169–193.

[NC46] N. Bidokhti, “Practical Software Failure Analysis Presentation,” June 2008, Available: 

www.opsalacarte.com/pdfs/Tech_Papers/Practical_SW_Failure_Analysis_for_Applied_

Reliability_Symposium_June_2008.pdf

[NC47] E. Piljugin, S. Authén, and J. -E. Holmberg, “Proposal for the Taxonomy of Failure 

Modes of Digital System Hardware for PSA,” PSAM 11, Helsinki, Finland: 2012.

[NC48] G. -Y. Park, H. -S. Eom, S. -W. Cheon, S. -C. Jang, and D. -H. Kim, “Quantitative Safety 

Analysis of Nuclear Safety Software,” NPIC&HMIT (2010), Las Vegas, NV, American 

Nuclear Society, 2010, pp. 1297–1304.

[NC49] Duke Energy /Oconee Nuclear Station, RPS/ESPS Failure Modes and Effects Analysis 

Summary Calculation, Non-Proprietary Version, 2009 

ADAMS Accession Number: ML091770437.

[NC50] J. Liu, J. Dehlinger, and R. Lutz, “Safety Analysis of Software Product Lines Using 

State-Based Modeling,” IEEE, 2011, pp. 21–30 Available: 

http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1544718

50
[NC51] J.B. Bowles and C. Wan, “Software Failure Modes and Effects Analysis for a Small 

Embedded Control System,” IEEE, 2011, pp. 1–6, Available: 

http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=902433

[NC52] G. -Y. Park, “Software FMEA Analysis for Safety Software,” International Conference on 

Nuclear Engineering, Brussels, Belgium: ASME

[NC53] WCAP-16592-NP, Revision 2 Software Hazard Analysis of AP1000TM Protection and 

Safety Monitoring System (Non-Proprietary), 2010 ADAMS 

Accession Number: ML103370195.

[NC54] G. -Y. Park, S. -W. Cheon, K.C. Kwon, K.Y. Koh, P.H. Seong, E. Jee, and S. Cha, 

“Software Qualification Activities for Safety Critical Software,” NPIC&HMIT (2009), 

Tennessee: American Nuclear Society, 2009.

[NC55] G. -Y. Park, H. -S. Eom, D. -H. Kim, and H.G. Kang, “Software Reliability Assessment of 

Reactor Protection System,” Transactions of the American Nuclear Society (ANS), vol. 

103, 2010.

[NC56] T. Hobson, “Software Safety: Examples, Definitions, Standards, Techniques,” 

November 2008, Available: www.cs.not.ac.uk/~cah/G53QAT/Schedule08.html

[NC57] European Cooperation for Space Standardization, ECSS-Q-80-03 Space Product 

Assurance: Methods and Techniques to Support the Assessment of Software 

Dependability and Safety (Draft), 2006 Available: 

http://www.ecss.nl/forums/ecss/dispatch.cgi/home/showFile/100623/d20060426090708/

No/Draft-ECSS-Q-80-03A(1March2006).pdf

[NC58] National Aeronautics and Space Administration (NASA), NSTS 22206 Revision D Space 

Shuttle: Requirements for Preparation and Approval of Failure Mode and Effects 

Analysis (FMEA) and Critical Items List (CIL), 1993.

[NC59] R.J. Duphily, Aerospace Report No. TOR-2009 (8591) -13 Space Vehicle Failure 

Modes, Effects, and Criticality Analysis (FMECA) Guide, 2011 Available: 

www.everyspec.com/USAF/TORs/TOR2009-8591-13_21606

[NC60] NASA, “Standard for Performing a Failure Mode and Effects Analysis (FMEA) and 

Establishing a Critical Items List (CIL) (DRAFT): Flight Assurance Procedure 

(FAP) - 322-209,” Nov. 2011, Available: http://rsdo.gsfc.nasa.gov/documents/Rapid-IIIDocuments/MAR-Reference/GSFC-FAP-322-208-FMEA-Draft.pdf

[NC61] R.R. Lutz, “Targeting Safety-Related Errors during Software Requirements Analysis,” 

SIGSOFT Softw. Eng. Notes, Vol. 18, December. 1993, pp. 99–106.

[NC62] S. Perry, R.L. Wears, and R.I. Cook, “The Role of Automation in Complex System 

Failures,” Journal of Patient Safety, Vol. 1, March. 2005, pp. 56–61.

[NC63] N. Ozarin, “The Role of Software Failure Modes and Effects Analysis for Interfaces in 

Safety-and Mission-Critical Systems,” IEEE, 2008, pp. 1–8 Available: 

51
http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4519009.

[NC64] C. Raspotnig, V. Katta, A.L. Opdahl, and T. Stålhane, HWR 1002 Towards Approaches 

for Analysis and Argumentation of Systems Safety and Security: Comparison of 

Techniques and Conceptual Model, 2011.

[NC65] AREVA NP Inc., ANP-10309NP U.S. EPR Protection System: Technical Report, 

Non-Proprietary Version, 2011 Available: 

http://pbadupws.nrc.gov/docs/ML1119/ML11195A295.pdf, 

ADAMS Accession Number: ML11195A295

[NC66] R. Lutz and A. Patterson-Hine, “Using Fault Modeling in Safety Cases,” IEEE, 2008, pp. 

271–276 Available: 

http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4700333.

[NC67] R. Lutz, “What Software Product Lines Can Tell Us about Sustainable, Long-lived 

Systems,” Nov. 2009 Available: 

http://www.cs.iastate.edu/~sandeepk/publications/SPLC10_lutz_weiss_krishnan_yang.

pdf

[NC68] J. Gray, “Technical Report 85.7 Why Do Computers Stop and What Can Be Done About 

It?” 1985 Available: www.hpl.hp.com/techreports/tandem/TR-85.7.html.

[NC69] “NRC: Glossary - Reasonable” Available:

http://www.nrc.gov/reading-rm/basic-ref/glossary/reasonable.html.

[NC70] C. Eckert, “Identification and Elimination of Systemic Problems,” Proceedings of the 

Society of Maintenance and Reliability Professionals Annual Symposium, St. Louis, 

MO: 2009.

[NC71] G. -Y. Park, K.C. Kwon, E. Jee, K.Y. Koh, and P.H. Seong, “Safety Activities on 

Safety-Critical Software for Reactor Protection System,” Transactions of the American 

Nuclear Society (ANS), vol. 96, Jun. 2007, pp. 237–238.

[NC72] G. -Y. Park, “Software Qualification Activities for Safety Critical Software,” March. 2014, 

Available: https://ric.nrc-gateway.gov/Docs/Abstracts/parkg-y-th27-hv.pdf.

52
APPENDIX A. THE VOCABULARY RELATED TO FAILURE MODES –

A DISCUSSION

Terms such as failure, fault, defect, error, and mode are commonly used in different ways, 

leading to ambiguity and confusion. To avoid misunderstanding, RIL-1002 uses each of these 

terms as defined in the Glossary27 and based on authoritative28 sources. This discussion 

explains the rationale underlying the selected definitions.

The scope and context of this discussion is limited29 to a software-dependent safety system, 

where the criticality is of the highest level and the system consists of safety-related elements 

only.

The discussion starts with an introduction of basic concepts (failure; fault; defect; error; mistake; 

stimulus-response; event-action; state and mode) and progresses to a combination of those 

concepts (e.g., fault mode) demonstrating the consistency of the combinational terms with the 

constituent terms and the value of maintaining such consistency.

A.1. Failure

In the context of engineered systems, especially those with sensors, actuators and control logic, 

the term “failure” has been used to mean “termination of the ability of an item to perform a 

required function” 30 [A1](also see [A2] and definitions 1A, 1N, 1O, 9, 13, 14 and 15 in [A3]). 

The term, “failure” implies that the system or component of concern was once31 able to perform 

its required function [MB]. Failure is an event [A1], signifying termination or loss of function. 

This widely accepted definition is similar to and consistent with the definition of “single failure” 

stated in Title 10 of the Code of Federal Regulations (10 CFR) Part 50, Appendix A “General 

Design Criteria for Nuclear Power Plants”: “A single failure means an occurrence which results 

in the loss of capability of a component to perform its intended safety functions.” In this 

definition, “loss of capability” has the same meaning as “termination of the ability” in the 

International Electrotechnical Commission (IEC) definition given above. The term “occurrence” 

in the definition given in Appendix A of 10 CFR Part 50 maps into the term “event” mentioned 

above and in reference [A1].

The concept of “failure” is well-known, well-accepted and well-understood in the context of 

physical components and systems with physical elements. Physical components fail as a result 

of applied excessive loading, or wear and tear due to physical degradation processes or 

mechanisms. Examples of failure of physical systems and components (which were functioning 

correctly) include:

1. A fluid flow control (shut-off) valve is unable to stop or resume flow.

2. A motor is unable to provide motion, motive force, or motive torque.

27 Exceptions arise when quoting or citing references, which use these terms in meanings different 

from the one in the RIL-1002 glossary. 28 Authoritative definitions are those accepted with a broad consensus, usually evidenced by 

inclusion in an accepted standard by a reputable standards organization. 29 While the discussion may have much broader applicability, the scope is kept narrow for ease of 

explanation. 30 This definition is widely accepted. 31 i.e., at the start of operation.

A-1

 
3. A pipe is no longer able to transport fluid from its source to destination at a specified flow 

rate.

4. A resistor ceases to provide the specified resistance.

A.2. Reason for Avoiding the Term “Failure” for Software

The concept of “failure” as explained in Section A.1 does not apply to software [A1]. Some 

experts assert that use of the term, failure, for software may be meaningless or perhaps 

misleading [DC, PM, and MH]. The rationale is that “Software does not exhibit random wear-out 

failures as does hardware; it is an abstraction [A4].” That is, “Software itself does not fail; it is a 

design for a machine ... Software-related computer [system] failures are always systematic 

[A4].”

Software items are of a different nature than hardware items in the applicability of the concept of 

failure, as explained above. If the software item does not perform a function under a specific 

condition, it was not able to do so from the beginning of operation. “If the item is a software 

system or component and is able to perform its function correctly from inception, it will continue 

to perform its function; it will not break” [MB]. A software item either performs a function under a 

given condition or it does not; the ability to perform a function is never lost. That is, software 

does not break down or wear out. This is why the term “failure” as defined in the glossary

should not be used for a software item.

A.3. Fault

The International Electrotechnical Vocabulary, in 191-05-01, defines “fault” as the state of an 

item characterized by inability to perform a required function, excluding the inability during 

preventive maintenance or other planned actions, or due to lack of external resources.”[A1]

Note the close relationship of this definition with the definition of failure “termination of the ability 

of an item to perform a required function,” where “termination of the ability” is an EVENT. Then, 

fault is the resulting STATE of the item. Also, note that an item need not “fail” to reach a fault 

state. It may be faulty (it may be in a state characterized by the inability to perform a required 

function) to begin with, as discussed in Section A.2 above in the case of software.

The International Electrotechnical Vocabulary, in 191-05-20, defines “latent fault” as “an existing 

fault that has not yet been recognized” (i.e., discovered) [A1]. In software operating in a system 

of highest criticality (e.g., for nuclear reactor safety), one would not expect the system to be 

commissioned with a known fault in the safety critical software. However, the system may still 

have a latent fault, particularly if it is complex. In such a system, testing, by itself, cannot assure 

the absence of a fault. For that reason, other approaches are needed to defend against a 

potential latent fault.

In [A3] definition 14 characterizes “fault” as a defect32 in a hardware or software component, 

where the term “defect” connotes a deficiency or inadequacy that may impair the intended 

function. However, some researchers distinguish between fault and defect as follows: a fault is 

32 In software, it is “designed in” [DC, GH], i.e., resulting from some inadequacy in its engineering, 

rather than resulting from degradation. In hardware, it may also be the result of some inadequacy 

in its manufacturing, fabrication, or construction.

A-2

 
a logical (function level) abstraction, whereas a defect is described in terms of some physical 

characteristic. It may be possible to map many defects at the physical or implementation level 

into a single fault at the function level. Then, the abstraction reduces the number of conditions 

or cases to be considered in an analysis. On the other hand, a single defect at the physical or 

implementation level may lead to multiple faults at the function level. Therefore, it would be 

more useful and less confusing to treat fault and defect as different concepts, and the definition 

of fault given in the International Electrotechnical Vocabulary should be used.

Appendix B provides examples of faults and a discussion on potential classification schemes.

A.4. Error

Often, the term “error” is used in the sense of “defect” or “fault” as evident in many of the 

surveyed publications. Furthermore, often, in the same system or the same publication, the 

term “error” is also used in other ways.

The community interested in “fault tolerant systems” does not recommend using “error” to mean 

“fault” or “defect.” In the context of this discussion, usage of the term “error” is limited to mean, 

“Any discrepancy between a computed, observed, or measured value or condition and the true, 

specified, or theoretically correct value or condition” (adapted from combination of definitions 1 

and 12 in [A3]). This definition is consistent with definitions 3A, 4, 5, 6, 8A, 11, and 12 [A3].

Note that even the selected definition allows for a wide range of usages. For example, in a 

closed loop control system, the specified value may be the setpoint and the discrepancy 

between the observed value and the setpoint may not indicate any unwanted or undesirable 

behavior; in fact, it may be natural to the control scheme and the controlled system.

Many of the surveyed publications have also used the term “error” to mean a human mistake.

To avoid ambiguity, RIL-1002 avoids usage of the term “error” in that meaning. A mistake is

defined as a human action (or inaction) that produces an unintended or incorrect result (adapted 

from definitions 1 and 3 in [A3]).

ISO/IEC/IEEE 24765:2010(E) in 3.1719 (definition of mistake) notes that “The fault tolerance 

discipline distinguishes between a human action (a mistake), its manifestation (a hardware or 

software fault), the result of the fault (a failure), and the amount by which the result is incorrect 

(the error).” [A5]

A.5. Stimulus-Response, Event-Action, State-Mode - Concepts to 

Characterize Behavior

The stimulus-response relationship is a useful paradigm to characterize behavior in many fields 

of science and provides the underpinning for conceiving, specifying, designing, analyzing, and 

evaluating engineered systems. Discretization of the behavior space (e.g., into sub-behaviors)

is a useful way of decomposing or organizing the problem space (or requirements space) for an 

engineered system. For example, certain sub-behaviors can only occur under certain 

conditions or are required only under certain conditions. The concept of discretizing the 

behavior space is used in engineering safety into engineered systems, e.g., detection of a 

hazardous condition, such as failure (a change in condition) of a critical valve, and using it as a 

stimulus to select (switch to) mitigating behavior.

A-3
An occurrence of some change33 in conditions can be abstracted into the concept, “event.” 

When this change serves as a stimulus to enable an action or to select some group of actions 

(i.e., change in sub-behavior) or to cause an action by an item, the concept of “event” is useful 

in understanding, describing, or specifying the behavior of the item. Following are some other 

examples of an event, given in ISO/IEC/IEEE 24765-2010 (E) [A5]:

• a timer expiration

• an external interrupt

• an internal signal

• an internal message

The existence of a certain set of stable conditions can be abstracted into the concept “state.” 

For example, the state may be an abstraction of the values of a set of variables that 

characterize the behavior of an item. In the example of the valve, introduced earlier, its two 

stable states for normal operation are: OPEN; CLOSED.

Mode is defined (definition 8 in [A3] and definition 1 in ISO/IEC/IEEE 24765-2010 (E) §3.1806 

[A5]) as a set of related features or functional capabilities of a product. Mapping into the 

vocabulary used in the discussion above, “product” maps into “item” and “set of related features 

or functional capabilities” maps into sub-behavior.

These standards cite the following examples:

• online mode

• offline mode

• maintenance mode

Taking the example of an operating nuclear reactor, the term “mode” is used to refer to different 

sub-behaviors or groups of behaviors such as:

• on power (starting up; raising power; operating at reduced power; operating at full 

power; reducing power)

• hot shut down(reactor is sub-critical and coolant temperature is above a certain 

threshold)

• cold shut down (reactor is sub-critical and coolant temperature is below a certain 

threshold)

• etc.

From these examples, it can be seen that the term “mode” and “state” are related, such that the 

term “mode” clusters a number of states into one region of related behaviors. The term “state” 

can also be used in this manner (i.e., a state can be an abstraction of a set of finer-grained 

states). Technically, “mode” and “state” have the same meaning; the differences lie in popular 

usage.

With the various examples given above, it can be seen that the state-based event-driven 

paradigm34 provides a unified means to describe or specify normal operational, as well as 

off-normal non-operational behaviors. The vocabulary used to characterize different kinds of 

conditions should be consistent with this paradigm.

33 Example in the case of a normally functioning valve: Termination of its ability to perform its 

required function. 34 Example formalisms: Finite state machine or automaton; extended finite state machine.

A-4

 
A.6. Failure Modes

Although the term, “failure mode” is used very commonly, its usage is not supported by the 

International Electrotechnical Vocabulary 60050 Chapter 191: Dependability and Quality of 

Service, amended, 1999-03 [A1].

IEEE Std 500-1984 P&V (withdrawn) defines “Failure Mode” as the effect35 by which a failure is 

observed to occur [A6]. However, even for components such as pumps, valves, and actuators, 

which are simpler than the DI&C systems being introduced in NPPs, the authors of this standard 

found differences in usage and intended meanings of the basic terms.

IEEE Std 500-1984 P&V in Section 1.3, defines failure as “the termination of the ability of an 

item or equipment to perform a required function.” Essentially this definition is the same as in 

Section A.1 above.

In order to assist in a common understanding and usage of basic terms, IEEE Std 500-1984 

P&V published Appendix A [A7], discussing these terms. In its Section A5, it recognized 

“failure” to be an event, as characterized in Section A.1 above. IEEE Std 500-1984 P&V in 

Section 1.3 defines failure mode as “the effect by which a failure is observed to occur.” Then, 

IEEE Std 500-1984 P&V, in Section A5 of the Appendix, explains that “A failure mode provides 

a descriptive characterization of the failure event in generic terms” with the intent of 

distinguishing the term, “failure mode” from the mechanism causing the failure and from the 

effect36 propagated to a higher level assembly or other elements of a system with multiple levels 

of assembly.

In contrast, the International Electrotechnical Vocabulary has deprecated the terms “failure 

mode,” “failure modes and effects analysis”, and “failure modes, effects and criticality analysis.” 

However, this discussion uses the term “failure mode” while referring to usage in cited 

publications [A1]. In the examples of failures given in Section A.1, each is an example of one 

“failure mode37” for each type of component. For a given type of component, there may be 

several “failure modes,” e.g., the following “failure modes” of a fluid flow control (shut-off) valve, 

which has two stable states (open; closed), and changes state, responding to inputs (OPEN; 

CLOSE):

1. No output upon demand: If it receives input to change its state, it does not, i.e., it stays 

where it is

2. Output without demand: It changes state without input.

3. Output at incorrect time: State change is not completed within the required time interval 

after input.

4. Output intermittent: Upon receiving input, sometimes the valve responds correctly, but 

not at other times (exhibiting one of the other failure modes in this list38).

5. Output flutters: When the input signal OPEN is given, the valve does not change from 

the CLOSED state to a stable OPEN state, but its position fluctuates; or, when the input 

35 Effect does not have the same meaning here, as denoted by the letter E in FMEA. 36 Here, effect has the meaning denoted by the letter E in FMEA. 37 The term is used herein as used popularly, although inconsistent with ISO/IEC 60051-191 [A1]. 38 Comparing this list with the failure modes L.1-L.8 in Table 13, L.5 and L.8 are not applicable to 

the 2-position valve: L.5 applies to an element with continuous control and L.8 applies to a 

distributed system.

A-5

 
signal CLOSE is given, the valve does not transition from the OPEN state to a stable 

CLOSED state, but its position fluctuates.

In each of the five modes above, the behavior is exhibited in repeated occurrences of the input.

A.7. Fault Modes

A term related to fault is “fault mode” which is defined as “one of the possible states of a faulty 

item, for a given required function [A1]. Referring to the example of the valve given in Section 

A.3, according to IEC 60051-191 [A1] these are fault modes – not failure modes. The subject of 

fault modes for software items is further discussed in Appendix B.

A.8. Bibliography

[A1] IEC, “IEC 60050-191 International Electrotechnical Vocabulary - Chapter 191: 

Dependability and Quality of Service,” IEC, IEC60050-191, 1990.

[A2] U.S. Nuclear Regulatory Commission, “Research Information Letter 1001: 

Software-Related Uncertainties in the Assurance of Digital Safety Systems - Expert Clinic 

Findings, Part 1.”

[A3] IEEE, “IEEE 100 The Authoritative Dictionary of IEEE Standards Terms Seventh Edition,” 

IEEE Std 100-2000, 2000.

[A4] Nancy G. Leveson, Safeware: System Safety and Computers. Addison-Wesley 

Professional, 1995.

[A5] IEEE, “24765-2010 - Systems and Software Engineering - Vocabulary,” Standard 

24765-2010, 2010.

[A6] ANSI/IEEE, “IEEE Standard Reliability Data for Pumps and Drivers, Actuators, and 

Valves,” ANSI/IEEE, ANSI/IEEE 500-1984, 1984.

[A7] IEEE, “A Discussion of the Term Failure Mode,” IEEE Std 500-1984, pp. 22–26, Dec.1983.

A-6
APPENDIX B. IDENTIFIED SOFTWARE FAULTS AND FAULT 

MODES SETS

Section 6.1.1 reported digital system instrumentation and control (I&C) failure modes identified 

during the expert elicitation process and supplemental NRC research activities. This appendix 

reports the software faults39, fault modes40, and classification and taxonomy schemes that were 

identified.

41

B.1. Software Faults and Fault Modes Identified by Source

After analyzing the information available, more faults and fault modes were found than can be 

presented.42 This section presents some fault and fault mode sets found through the expert 

elicitation process and supplemental NRC research activities. The staff found that faults, fault 

modes, and effects resulting from activated faults or fault modes were often identified in the 

technical literature as “failure modes” or “software failure modes.” Because of the large number 

of faults and fault modes, correlation analysis and fault synthesis similar to failure mode 

correlation and synthesis in Sections 6.1.1.12 and 6.1.2 was not performed. The staff also 

could not assemble a set of faults and fault modes of greatest concern for software that could 

be used for assurance of a digital safety system similar to those seen in recent new reactor 

licensing applications. Experts indicated that it may not be possible to generate a complete list 

of suitable faults and fault modes [JK, GH, MH].

The faults and fault mode sets reported in this document are limited to references reviewed for 

the purposes listed in Section 1.1. A section is dedicated to each source reviewed. Faults and 

fault modes are reported in tables that consist of 3 columns. The first column provides an 

identification number for each fault and fault mode. The second and third columns present the 

faults and fault modes. Faults and fault modes may be repeated in multiple sections. Columns 

are shaded if no information was found for the respective category. Other characterizations of

the faults and fault mode sets presented are possible. Faults and fault modes may exist that 

are not listed in this section.

B.1.1. Fault/Fault Mode Set 1

In his paper, “How FMEA Improves Hardware and Software Safety & Design Reuse”43 [B3], N. 

Bidokhti states that “there are many categories” of software faults and provides five example 

39 The state of an item characterized by inability to perform a required function, excluding the 

inability during preventive maintenance or other planned actions, or due to lack of external 

resources” [B1]. 40 One of the possible states of a faulty item for a required function [B2]. 41 Consistent definitions of the terms “failure”, “failure mode” and “fault” are not used in the technical 

literature. This appendix reports “faults” as defined in this RIL. The sources cited may have 

referred to faults as errors, failures, bugs, etc. See the Glossary and Appendix A for information 

on the definitions chosen for RIL-1002.

42 Terminology consistent with definitions used in this RIL replaces the original wording in this 

section where possible in the tables below. It was not possible to replace the terminology by 

some authors.

43 This is the same source of Failure Mode Set G in Section 6.1.1.7.

B-1

 
categories: Requirements faults, Interface faults, Fault Tolerance faults, Resource Usage 

faults, and Data faults.

Example faults and fault modes are provided in the paper, organized into two of the example 

categories: Requirement Faults and Interface faults. The author seems to acknowledge that 

his examples and definitions may not be suitable for every situation. He states that it is 

essential that “definition of [faults], categories of [faults], and [fault] modes are well understood 

and accepted by all team members,” before any identification and analysis begins.

Table B-1 Fault/Fault Mode Set 1 [B3].

ID Faults Fault Modes

1.1 Incorrect requirements

1.2 Ambiguous requirements

1.3 Conflicting requirements

1.4 Exceptional condition not 

specified

1.5 Test points or monitors not 

specified

1.6

Message based interface 

fault

No message received

1.7 Invalid message received

1.8 Message received out of 

sequence.

1.9 Duplicate message received

1.10 Message not acknowledged

1.11 Message acknowledged out of 

sequence

1.12 Duplicate acknowledge 

received

B.1.2. Fault/Fault Mode Set 2 

In their paper titled “Failure Modes in Embedded Systems and Its Prevention” [B4], the authors 

stated that two main groups of faults are possible: hardware and software. The authors state 

that their list contains “some examples” of software faults.

B-2
Table B-2 Fault/Fault Mode Set 2 [B4].

ID Faults Fault Modes

2.1

Buffer overflow:

computer memory is smaller 

than the programmer 

expected

2.2

Dangling pointers:

Common in non-safe 

programming languages in 

which the human 

programmer is responsible 

for making sure every 

pointer points to the right 

memory location at all times.

2.3 Resource leaks (such as 

memory leaks)

2.4

Race conditions: specific 

relative timing events that 

lead to unexpected 

behavior.

2.5

Semantic design: the 

meaning of an arrow 

between two subsystems in 

a visual software 

environment not interpreted 

the same way by the 

hardware.

B.1.3. Fault/Fault Mode Set 3

Czerny et al, in “Effective Application of Software Safety Techniques for Automotive Embedded 

Control Systems” [B5]44, provided a set of variable fault and fault modes. The paper stated that 

“In addition to potential variable [fault] modes, potential processing logic fault modes may be 

considered.” Analysis of processing logic faults and fault modes includes examining 

computational operators and operations (e.g., addition, subtraction, multiplication, comparison).

44 This set of fault modes are from the same source as Failure Mode Set C.

B-3

 
Table B-3 Fault/Fault Mode Set 3 [B5].

ID Faults Fault Modes

3.1

Variable type – Analog

Fault

High

Low

3.2 Variable Type – Boolean

Fault

True when False

False when True

3.3

Enumerated Example 

Values

Faults

A when it should be B,

B when it should be C,

C when it should be A, or

C when it should be B

B.1.4. Fault/Fault Mode Set 4 

A paper by Vyas and Mittal, “Operation Level Safety Analysis for Object Oriented Software 

Design Using SFMEA” [B6], presents a bottom up approach to identifying faults and fault modes 

in methods used in object oriented code. Four fault and fault mode cause types are listed as 

“failure modes”: “Precondition Violation Failure Modes, Parametric Failure Modes, Method Call 

or Invoke Failure Modes, and Post Conditional Failure Modes.”

Table B-4 Fault/Fault Mode Set 4 [B6].

ID Faults Fault Modes

4.1

Incorrect method 

response with 

precondition violated

4.2

Precondition satisfied but 

corresponding exception 

is raised.

4.3

Constraints on Parameter 

Value faults 

Constraint is false but 

exception is not raised, 

constraint is true but 

exception is raised.

B-4
Table B-4 Fault/Fault Mode Set 4 [B6].

ID Faults Fault Modes

4.4

Method m1 invokes m2 in 

wrong order (if invocation 

of m2 is condition based)

4.5

m1 invokes m2 by wrong 

parameters (if m2 is 

parameterized)

4.6

m1 (of class A) fails to 

invoke m2 (of class B) 

because lack of instance 

of class B

4.7

m1 invokes m2 in wrong 

order (if invocation of m2 

is condition based)

4.8

m1 invokes m2 by wrong 

parameters (if m2 is 

parameterized)

B.1.5. Fault/Fault Mode Set 5 NUREG/CR – Appendix C (BNL)

This fault set was obtained from a document that was originally an appendix to NRC 

NUREG/CR-6962 [B7]. The appendix did not appear in the final document but it was released 

publicly for feedback from the Advisory Committee on Reactor Safeguards [B8].

Table B-5 Fault/Fault Mode Set 5 [B8].

ID Faults Fault Modes

5.1

Software runs into an 

infinite loop

Software stops generating 

outputs and deadlocks 

between processes. More 

specific fault modes include:

Halt/Termination with Clear 

message, and

Halt/Termination without 

clear message.

B-5
Table B-5 Fault/Fault Mode Set 5 [B8].

ID Faults Fault Modes

5.2 Software generates 

incorrect output.

Runs with evidently wrong 

results, and

Runs with wrong results that 

are not evident.

5.3

Software runs with 

misleading commands to 

the user, incomplete or 

incorrect display of 

information.

Incomplete or incorrect 

information displayed.

5.4 Timing/order fault

5.5 Interrupt induced fault

5.6 Omission of a function or 

attribute fault.

5.7 Unintended function or 

attribute fault.

5.8

Incorrect implementation of 

a function or an attribute

fault.

5.9 Data faults.

B.1.6. Fault/Fault Mode Set 6 

In their paper, “Experience Report: Contributions of SFMEA to Requirements Analysis” [B9],

Lutz and Woodhouse postulated four data faults types and four event fault types. The data fault 

types are: Absent Data, Incorrect Data, Timing of Data Wrong, and Duplicate Data. The event 

fault types are: Halt/Abnormal Termination, Omission, Incorrect Logic/Event, and Timing/Order.

B-6
Table B-6 Fault/Fault Mode Set 6 [B9].

ID Faults Fault Modes

6.1

Lost or missing messages, 

absence of sensor input 

data, lack of input or 

output, failure to receive 

needed data, missing 

commands, missing 

updates of data values, 

data loss due to hardware 

failures, software process 

or sensor does not send 

the data needed for correct 

functioning.

6.2

Bad data, flags or variables 

set to values that don’t 

accurately describe the 

spacecraft’s state or the 

operating environment, 

erroneous triggers, limits, 

deadbands, delay timers, 

erroneous parameters, 

wrong command outputs, 

or wrong parameters to the 

right commands, spurious 

or unexpected signals.

6.3

Data arrive too late to be 

used or be accurate, or too 

early to be used or be 

accurate; obsolete data are 

used in control decisions 

(data age), inadvertent, 

spurious (unexpected) or 

transient data.

6.4

Redundant copies of data, 

data overflow, data 

saturation.

6.5

Open, stuck, hung, and 

deadlocked at this point 

(event) in the process.

6.6

Event does not occur but 

process continues 

execution, jumps, skips, 

B-7
Table B-6 Fault/Fault Mode Set 6 [B9].

ID Faults Fault Modes

short.

6.7

Behavior is wrong, logic is 

wrong, branch logic is 

reversed, wrong 

assumptions about state, 

preconditions, “don’t cares” 

aren’t truly so; event (e.g.,

command issued) is wrong 

to implement the intent or 

requirement.

6.8

Event occurs at wrong time 

or in wrong order, event 

occurs too early, too late, 

the sequence of events is 

incorrect, an event that 

must precede another 

event doesn’t occur as it 

should, iterative events 

occur intermittently rather 

than regularly, events that 

should occur only once 

instead occur iteratively.

B.1.7. Fault/Fault Mode Set 7

In the paper titled “FMEA Performed on the Spinline3 Operational System Software as Part of 

the TIHANGE 1 NIS Refurbishment Safety Case” [B10], Ristord and Esmenjaud provided a list 

of “five general failure modes.” This list of “five general failure modes” contains effects (as 

defined by this RIL): the operating system stops, the program stops with a clear message, the 

program stops without a clear message, the program runs producing obviously wrong results, 

and the program runs producing apparently correct but wrong results. The authors also defined 

“context specific” faults for code that was grouped into blocks of code instructions referred to as 

“block instructions.” Correct behavior was defined first; the faults and fault modes identified

were derived from the definition of correct behavior.

Table B-7 Fault//Fault Mode Set 7 [B10].

ID Faults Fault Modes

7.1 The block instructions 

execution does not end 

B-8
Table B-7 Fault//Fault Mode Set 7 [B10].

ID Faults Fault Modes

through the “exit” point

7.2

The block instruction 

execution time does not 

meet time limits

7.3

The block instruction does 

not perform the intended 

actions or performs 

unintended actions:

It modifies code memory or 

constants

It does not provide 

expected outputs.

It modifies the variables that 

it shall not modify.

It does not interact as 

expected with I/O boards.

It does not interact as 

expected with CPU 

resources.

It modifies code memory or 

constraints.

B.1.8. Fault/Fault Mode Set 8

Becker and Flick, in their paper “A Practical Approach to Failure Modes, Effects, and Criticality 

Analysis (FMECA) for Computing Systems” [B11], lists “some typical” faults and fault modes 

organized into categories describing the effect of the faults and fault modes. The categories 

included effects at the software and hardware level. Hardware effects not listed in Table B-8

include: slow response, startup failure, and loss of external system.

Table B-8 Fault/Fault Mode Set 8 [B11]

ID Faults Fault Modes

8.1

Unsolicited termination of the 

normal and correct 

processing 

No fault mode provided.

8.2

No fault provided. Termination of required 

processing without an 

associated notification of 

termination.

8.3 No fault provided. Process ceases to perform its 

required services but 

continues performing actions 

B-9
Table B-8 Fault/Fault Mode Set 8 [B11]

ID Faults Fault Modes

and consumes resources 

without notification of its 

status.

8.4 Duplicate messages Application in a different end 

state.

8.5 Application failing to send a 

message.

No fault mode provided.

8.6

Fault (specific fault not 

provided) occurs while writing 

a checkpoint file.

Checkpoint file not in a 

consistent state

8.7 No fault provided. Design limit of size of a 

database is reached.

8.8 No fault provided. Application is unable to send 

a service request message.

B.1.9. Fault/Fault Mode Set 9 – WGRisk Activities

Chu et al, in [B12], identified faults and fault modes by considering the architecture of an 

example digital system. Table B-9 lists the faults and fault modes identified by examining “the 

software program running on a particular microprocessor.”

Table B-9 Fault/Fault Mode Set 9 [B12].

ID Faults Fault Modes

9.1 Erroneous operation of data 

acquisition

Incorrect value

Incorrect validity

No value

No validity

9.2 Erroneous operation for logic 

processing

Failure to actuate (including 

failure to hold)

Spurious failure

9.3 Erroneous operation for 

voting logic

Incorrect voting

No vote

B-10
Table B-9 Fault/Fault Mode Set 9 [B12].

ID Faults Fault Modes

9.4 Erroneous operation for 

priority actuation logic

Incorrect priority

No priority

B.1.10. Fault/Fault Mode Set 10 

The faults and fault modes found in IEEE Standard 1044TM-2009 [B1] standard are listed in 

Table B-10. Examples of faults listed in the standard are for information only and are not 

exhaustive. Additional information on this standard is provided in Section B.2.2.

Table B-10 Fault/Fault Mode Set 10 [B1].

ID Fault Fault Modes

10.1

Defect in data definition, 

initialization, mapping, 

access, or use, as found in a 

model, specification or 

implementation.

Variable not assigned initial 

value or flag

Incorrect data type or 

column size

Incorrect variable name 

used 

Valid range undefined 

Incorrect relationship 

cardinality in data model

Missing or incorrect value in 

pick list

10.2

Defect in specification or 

implementation of an 

interface (e.g., between user 

and machine, between two 

internal software modules, 

between software module 

and database, between 

internal and external software 

components, between 

software and hardware)

Incorrect module interface 

design or implementation

Incorrect report layout 

(design or implementation)

Incorrect or insufficient 

parameters passed

Cryptic or unfamiliar label 

or message in user 

interface

Incomplete or incorrect 

message sent or displayed

Missing required field on 

data entry screen

B-11
Table B-10 Fault/Fault Mode Set 10 [B1].

ID Fault Fault Modes

10.3

Defect in decision logic, 

branching, sequencing, or 

computational algorithm, as 

found in natural language 

specifications or in 

implementation logic.

Missing else clause 

Incorrect sequencing of 

operations

Incorrect operator or 

operand in expression

Missing logic to test for or 

respond to an error 

condition (e.g., return code, 

end of file, null value)

Input value not compared 

with valid range

Missing system response in 

sequence diagram

Defect in description of 

software or its use, 

installation, or operation.

Nonconformity with the 

defined rules of a language.

10.4

Defect in description of 

software or its use, 

installation or operation

10.5 Nonconformity with the 

defined rules of a language

10.6 Nonconformity with defined 

standard.

10.7 Defect for which there is no 

defined type.

10.8 Something is incorrect, 

inconsistent, or ambiguous

10.9 Something is absent that 

should be present

10.10 Something is present that 

need not be.

B-12
Table B-10 Fault/Fault Mode Set 10 [B1].

ID Fault Fault Modes

10.11

Defects inserted during 

requirements definition 

activities (e.g., elicitation, 

analysis or specification):

Function required to meet 

customer goals omitted from 

requirements specification.

Incomplete use case 

specification

Performance requirements 

missing or incorrect

Security requirements 

missing or incorrect

Function incorrectly specified 

in requirements specifications

Function not needed to meet 

customer goals specified in 

requirements specifications

10.12

Defects inserted during 

coding or analogous activities

Incorrect variable typing.

Incorrect data initialization

Module interface not coded 

as designed.

10.13 Defect inserted during 

product build or packaging

Wrong source file included 

in build.

Wrong .EXE file included in 

distribution/deployment 

package.

Wrong localization 

parameters in .INI file

B-13
Table B-10 Fault/Fault Mode Set 10 [B1].

ID Fault Fault Modes

10.14

Defect inserted during 

documentation of instructions 

for installation or operation

Incorrect menu choices 

listed in User Manual.

Incorrect task or navigation 

instructions in online help.

Missing installation 

pre-requisite in product 

specifications.

Wrong version identifier in 

product release notes.

B.2. Fault Classification and Taxonomy Schemes

A complete list of software faults and fault modes was not found45. The technical community 

has recognized that there is a need to establish a common language to improve communication 

about software faults and fault modes. Computer scientists, companies, and standards 

organizations have developed several classification systems and taxonomies that seek to 

establish a framework for defining, characterizing, and cataloging faults and fault modes to 

support software design and development. This section describes a few classification

approaches and taxonomies46:

a. Heisenbugs, Bohrbugs, and Mandlebug classifications 

b. IEEE STD 1044-2009, Standard Classification for Software Anomalies

c. Boris Beizer’s Classification of Software Bugs

d. IBM’s Orthogonal Defect Classification (ODC)

e. Hewlett Packard’s Defect Origins, Types, and Modes

f. MITRE’s Common Weakness Enumeration (CWE)

g. Avizienis/Laprie/Randell/Landwehr Taxonomy47

h. A Taxonomy Based on PRA Requirements

i. EPRI’s Hierarchy of Software Interactions and Faults

45 Many faults and fault modes are known but more are expected to be found in the future. 46 This list is not exhaustive. Other classification systems and taxonomies may exist. 47 This taxonomy was used in NUREG/CR-7151 titled “Development of a Fault Injection-Based 

Dependability Assessment Methodology for Digital I&C Systems.”

B-14

 
B.2.1. Heisenbugs, Bohrbugs, and Mandelbugs

This set of “software bugs”48 classifications originated in the paper “Why do Computers Stop 

and What Can be Done about It?” [B13] by Jim Gray. Although no formal definition of the terms 

was provided, Gray said that bugs could be classified as either Heisenbugs or Bohrbugs. 

Heisenbugs were understood to be “soft” meaning that “they go away when you look at them.” 

That is, Heisenbugs are transient faults or bugs that change when one inspects the bug. 

Although the term “Mandelbugs” was adopted by computer scientists and is sometimes used as 

a synonym for Heisenbugs, others have used this term to mean that it is a very complex bug 

that has the appearance of being chaotic or that it changes when it is inspected (it’s a Bohrbug 

that appears to be a Heisenbug). The other type of software bugs are Bohrbugs, which can be 

understood as “solid” and easily detectable by standard techniques. A lesser used term is a 

“Schrodinger bug” which can be described as code that should have never worked. This 

classification approach has been used to analyze faults in past JPL/NASA space missions 

[B14]. Although these terms are used by the software community, no standard definition was 

found for these terms.

B.2.2. IEEE STD 1044-2009, Standard Classification for Software 

Anomalies 

IEEE Standard 1044TM-2009 [B1] provides an approach to “the classification of software 

anomalies, regardless of when they originate or when they are encountered within the project, 

product, or system life cycle.” The main focus of the standard is to provide a list of attributes 

that can be used to classify identified defects in software products discovered by any 

organization. The document recognizes that “there are other attributes of failures or defects that 

are of unique value to specific applications or business requirements,”; that is, it is expected that 

organizations and individuals may tailor the classification attribute values in this standard. The 

classification process is also to be defined by the organization using a process provided in this 

standard. Table B-11 lists the set of defect attributes in [B1].

Table B-11 Defect Attributes in [B1]

Attribute Definition

Defect ID Unique identifier

Description Description of what is missing, wrong, or unnecessary

Status Current state within defect report life cycle

Asset The software asset (product, component, module, etc.) containing the defect.

Artifact The specific software work product containing the defect.

Version detected Identification of the software version in which the defect was detected.

48 The term “software bugs” includes faults and failures as used by Gray.

B-15

 
Version corrected Identification of the software version in which the defect was corrected.

Priority

Ranking for processing assigned by the organization responsible for the 

evaluation, resolution, and closure of the defect relative to other reported 

defects.

Severity

The highest failure impact that the defect could (or did) cause, as determined 

by (from the perspective of) the organization responsible for software 

engineering.

Probability Probability of recurring failure caused by this defect.

Effect The class of requirement that is impacted by a failure caused by a defect.

Type A categorization based on the class of code within which the defect is found 

or the work product within which the defect is found.

Mode

A categorization based on whether the defect is due to incorrect 

implementation or representation, the addition of something that is not 

needed or an omission.

Insertion activity The activity during which the defect was injected/inserted.

Detection activity The activity during which the defect was detected.

Failure reference(s) Identifier of the failure(s) caused by the defect.

Change reference Identifier of the corrective change request initiated to correct the defect.

Disposition Final disposition of defect report upon closure.

B.2.3. Boris Beizer’s Classification Scheme49

In Chapter 2 of Boris Beizer’s book “Software Testing Techniques – Second Edition,” a 

“Taxonomy of Bugs” is presented [B15]. He chose the term “bug” because at the time he wrote 

the book word “standards [were] inconsistent with one another and with themselves in the 

definition of ‘fault,’ ‘error,’ and ‘failure.’” Beizer acknowledged that “there is no universally 

correct way to categorize bugs ... [and that] bugs are difficult to categorize.” In addition, “the 

severity of a bug, for the same bug with the same symptoms, depends on context.” That is, a 

uniquely identified bug will have context-based effects.

In Table 2.1 of his book, Beizer provided the following major categories under which software 

bugs can be grouped:

1. Requirements

49 All quotes from Software Testing Techniques, Second edition, by Boris Beizer. Copyright © 1990 

by Boris Beizer. The information is reprinted with permission of Van Nostrand Reinhold, New 

York.

B-16

 
2. Features and Functionality

3. Structural Bugs

4. Data

5. Implementation and Coding

6. Integration

7. System and Software Architecture

8. Testing

9. Other, Unspecified

In the only Appendix to his book “Bug Statistics and Taxonomy,” he provided up to five levels of 

subcategories to express and detail the bug taxonomy for each major category. His example of 

structural bugs (#3 above) demonstrates the taxonomy:

1. 3xxx – Structural Bugs in Implemented Software

2. 32xx – Processing bugs

3. 322xx – Expression evaluations

4. 3222 – Arithmetic expressions

5. 3222.1 – Wrong operator

Beizer noted that the taxonomy may grow to include more subcategories (with a suggested

format of xxxx.x.x). The author warned that “Bug statistics tell you nothing about the coming 

release, only the bugs of the previous release.”

B.2.4. IBM’s Orthogonal Defect Classification (ODC)

Orthogonal defect classification [B16][B17] is a classification based on a set of attributes defined 

by IBM (the technical lead was [RC]). It is a classification approach intended to lie between 

Statistical Defect Models50 and Causal Analysis (quantitative and qualitative classification 

extremes). The term “defect” is defined as “a necessary change” in ODC. The definition of 

“defect” in ODC is not the same definition used in this RIL. Faults, errors, and mistakes as 

defined in this RIL are all of “defects” according to ODC.

The set of attributes used for this classification scheme are:

1. Activity: the activity that was being performed at the time the defect was discovered.

2. Triggers: The environment or condition that had to exist for the defect to surface.

3. Impact: The effect or issue that the defect complicates.

4. Target: The high level identity of the entity that was fixed.

5. Defect Type: The nature of the actual correction that was made.

6. Qualifier: Captures the element of either nonexistent or wrong or irrelevant 

implementation in relation to defect type.

7. Source: Identifies the origin of the target.

8. Age: The history of the target.

50 Statistical Defect Models (SDM) are tools that attempt to predict the reliability of a software 

product. SDMs attempt to measure the number of defects that remain after a software product 

has been deployed, the failure rate of that product, and the short term defect detection rate [B9].

B-17

 
Defect types consist of:

1. Assignment/Initialization

2. Checking

3. Algorithm/Method

4. Function/Class/Object

5. Timing/Serialization

6. Interface/O-O Messages

7. Relationship

8. Documentation

Defects are qualified by:

1. Missing: defect was caused by an omission

2. Incorrect: defect was caused by a commission

3. Extraneous: defect was caused by to something not relevant or pertinent to the 

document or code.

B.2.5. Hewlett Packard’s Defect Origins, Types and Modes

This classification approach specifies defects via three dimensions: origins, types, and modes 

[B18]. Origins are the source of the defect, not where the defect is discovered in the lifecycle 

process, but where it could have or should have first been corrected. The possible origins are: 

specifications/requirements, design, code, environmental support, documentation, or other. 

Types are coarse-grained categorizations and differ for each origin (and also include “other”). 

The modes are: missing, unclear, wrong, changed, better way. In summary, the origin specifies 

“where”, the type specifies “what”, and the mode specifies “why.”

B.2.6. MITRE’s Common Weakness Enumeration (CWE)

CWE [B19] is a “dictionary of known software weaknesses51” [B20] intended for use by the 

cyber security community. The dictionary was developed in order to establish a common 

language for describing cyber security weaknesses. The project is sponsored by the National 

Cyber Security Division of the U.S. Department of Homeland Security and is maintained by the 

MITRE Corporation. In addition to defining software weakness terms, the CWE project also 

includes entries and metadata, which have been used to create taxonomies of software 

weaknesses and to demonstrate the relationship between the defined terms.

51 Weaknesses are defined as “a type of mistake in software that, in proper conditions, could 

contribute to the introduction of vulnerabilities within that software. This term applies to mistakes 

regardless of whether they occur in implementation, design, or other phases of the SDLC.” 

Weaknesses include “flaws, faults, bugs, vulnerabilities, and other errors in software 

implementation, code, design, or architecture that if left unaddressed could result in systems and 

networks being vulnerable to attack” [http://cwe.mitre.org/about/faq.html#A.1].

B-18

 
This dictionary includes a taxonomy which is evidence of how hard it is to obtain a list of known 

faults and categorize them. As of November 1, 2011, the CWE listed 886 entries. The entries 

defined include 157 categories52, 693 weaknesses, 27 views53 and 9 compound elements54. 

The level of detail for each weakness varies. “Class Weaknesses” are the most abstract 

entries; they are independent of specific languages or technology. “Base weaknesses” are 

described in an abstract fashion but with sufficient details for detection and prevention. “Variant 

Weaknesses” are described at a very low level of detail, typically limited to a specific language 

or technology [B21].

Several organizations have adopted or are adhering to the definitions provided on the CWE 

Web site even though the dictionary shows the status of every entry listed on the CWE Web site 

as either “Draft” or “Incomplete.” There is no guarantee that the list of terms is complete and 

that new weaknesses will not be found.

The staff searched the CWE for faults and fault modes that may occur when software is used in 

digital safety systems. Not all of the faults and fault modes listed in the CWE dictionary would 

apply to every case proposed by a licensee or applicant. Eliminating the irrelevant known 

weaknesses was a challenge for the NRC staff because the CWE is so large. The CWE Web

site provides several graphical depictions of how the entries are related and how they can be 

categorized [B22]. For a depiction of just the categories with some vulnerabilities see [B23]. 

Finding the faults that could apply to software used in digital safety systems was like searching 

for a “needle-in-a-haystack.” Some entries that are relevant to digital safety systems in the 

CWE include: Indicator of Poor Code Quality [B24], Resource Management Errors [B25], 

Improper Restriction of Operations within the Bounds of a Memory Buffer [B26], Improper Input 

Validation [B27], and Concurrent Execution using Shared Resource Synchronization (‘Race 

Condition’) [B28].

B.2.7. Avizienis/Laprie/Randell/Landwehr Taxonomy

In their paper, “Basic Concepts and Taxonomy of Dependable and Secure Computing” [B29], 

Avizienis, Laprie, Randell, and Landwehr faults have eight “basic viewpoints”: phase of 

creation, system boundaries, phenomenological cause, dimension, objective, intent, capability, 

and persistence. There are “256 different combined fault classes” that are possible but not all 

fault classes can be classified by the eight viewpoints. They identified “31 likely combinations” 

of fault classes but also state that “more combinations may be identified in the future.”

B.2.8. A Taxonomy Based on PRA Requirements

In the paper, “Integrating Software into PRA: A Software-Related Failure Mode Taxonomy” 

[B30], Li et al. (authors from the University of Maryland and NASA), describe a taxonomy 

“established based on the principles derived from taxonomy theory, other classifications, and 

the PRA requirements” as described in the paper. The taxonomy presented consists of four 

52 Category is defined as “a CWE entry that contains a set of other entries that share a common 

characteristic.”

53 A View is a “subset of CWE entries that provide a way of examining CWE content.” 54 Compound Element is defined as a CWE entry “that closely associates two or more CWE 

entries.”

B-19

 
levels. It begins from two general types of software faults: internal faults and interaction faults. 

More specific types of faults and fault modes are described through a four level hierarchy.

B.2.9. EPRI’S Hierarchy of Software Interactions and Faults

In Appendix B of [B31], EPRI researchers propose a digital failure analysis taxonomy that 

includes examples of failure modes, failure mechanisms, faults, and defensive measures for 

generic hardware and software implemented at various levels of abstraction. The taxonomy 

proposes organizing software faults into four levels of a hierarchy: Binaries (Level 1), Tools 

(Level 2), Application and Operating System Software (Level 3), and System Architecture (Level 

4). Example fault modes (called Failure Modes), their causes (Failure Mechanisms), and ways 

to address them (Defensive Measures) in [B31] do not form a comprehensive listing.

B.3. Summary of Software Faults and Fault Modes Found

This Appendix presents the software faults and fault modes identified during the expert 

elicitation process and in the technical literature reviewed. In addition, several taxonomy and 

classification schemes were discussed. The potential fault and fault mode space for software in

it is large. Some faults and fault modes reported in this Appendix may be applicable to some 

digital systems containing software but not to others. Critical faults and fault modes that are not 

listed may also exist. Further analysis of the fault modes listed in this chapter using any of the 

techniques discussed in Appendix C will not provide assurance that the software is fault free. 

The benefits of further analysis of the faults and fault modes reported (See Appendix C) are 

marginal.

B.4. Bibliography

[B1] Software & Systems Engineering Standards Committee, IEEE 1044, IEEE Standard 

Classification for Software Anomalies, IEEE, 2010.

[B2] IEC, IEC60050-191 International Electrotechnical Vocabulary - Chapter 191: 

Dependability and Quality of Service, IEC, 1990.

[B3] N. Bidokhti, “How FMEA Improves Hardware and Software Safety & Design Reuse,” 

International Workshop on Software Reuse and Safety (RESAFE-2006), Torino, Italy: 

Available: www.favaro.net/john/RESAFE2006/papers/Bidokhti.pdf.

[B4] S. Khaiyum and Y.S. Kumaraswamy, “Failure Modes in Embedded Systems and Its 

Prevention,” Journal of Software Engineering Research, Jun. 2011, Available: 

http://astronomyjournal.yolasite.com/resources/2.pdf.

[B5] B.J. Czerny, J.G. D’Ambrosio, B.T. Murray, and P. Sundaram, 2005-01-0785 Effective 

Application of Software Safety Techniques for Automotive Embedded Control Systems, 

Warrendale, PA: SAE International, 2005 Available: 

http://www.sae.org/technical/papers/2005-01-0785

[B6] P. Vyas and R.K. Mittal, “Operation Level Safety Analysis for Object Oriented Software 

Design Using SFMEA,” IEEE, 2009, pp. 1675–1679 Available: 

B-20
http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4809269

[B7] T.L. Chu, G. Martinez-Guridi, M. Yue, J. Lehner, and P. Smanta, NUREG/CR- 6962

Traditional Probabilistic Risk Assessment Methods for Digital Systems (NUREG/CR-6962), 

U.S. Nuclear Regulatory Commission, 2008 Available: 

http://pbadupws.nrc.gov/docs/ML0831/ML083110448.pdf, ADAMS Accession Number: 

ML083110448.

[B8] “Draft NUREG/CR-XXXX, "Approaches for Using Traditional Probabilistic Risk Assessment 

Methods for Digital Systems, Appendix C: Modeling Of Software Failures,” Available: 

http://pbadupws.nrc.gov/docs/ML0726/ML072690238.pdf.

[B9] R.R. Lutz and R.M. Woodhouse, “Experience Report: Contributions of SFMEA to 

Requirements Analysis,” ICRE, 1996, pp. 44–51.

[B10] L. Ristord and C. Esmenjaud, “FMEA Performed on the SPINLINE3 Operational System 

Software as part of the TIHANGE 1 NIS Refurbishment Safety Case,” CNRA/CSNI 

workshop on Licensing and Operating Experience of Computer-Based I&C Systems, 

Hluboka nad Vltavou, Czech Republic: Nuclear Energy Agency: Committee on the 

Safety of Nuclear Installations, 2001, pp. 37–50 Available: http://www.oecdnea.org/nsd/docs/2002/csni-r2002-1-vol2.pdf.

[B11] J.C. Becker and G. Flick, “A practical approach to failure mode, effects and criticality 

analysis (FMECA) for computing systems,” IEEE Comput. Soc. Press, 2012, pp. 228–

236 Available: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=618602.

[B12] T. -L. Chu, M. Yue, and W. Postma, “A Summary of Taxonomies of Digital System 

Failure Modes Provided by the DIGREL Task Group,” PSAM 11, Helsinki, Finland: 2012 

ADAMS Accession Number: ML120680552.

[B13] J. Gray, Technical Report 85.7 Why Do Computers Stop and What Can Be Done About 

It?, 1985 Available: www.hpl.hp.com/techreports/tandem/TR-85.7.html.

[B14] M. Grottke, A.P. Nikora, and K.S. Trivedi, “An empirical investigation of fault types in 

space mission system software,” Dependable Systems and Networks (DSN), 2010 

IEEE/IFIP International Conference on, Dependable Systems and Networks (DSN), 

2010 IEEE/IFIP International Conference on, 2010, pp. 447–456.

[B15] B. Beizer, Software Testing Techniques Second Edition, 1990.

[B16] “Orthogonal Defect Classification,” IBM Research Available: 

http://researcher.watson.ibm.com/researcher/view_group.php?id=480

[B17] R. Chillarege, I.S. Bhandari, J.K. Chaar, M.J. Halliday, D.S. Moebus, B.K. Ray, and 

M. -Y. Wong, “Orthogonal Defect Classification-A Concept for In-Process 

Measurements,” IEEE Transactions on Software Engineering, Vol. 18, November. 1992, 

pp. 943–956, Available: 

http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=177364.

B-21
[B18] J.T. Huber, “A Comparison of IBM’s Orthogonal Defect Classification to Hewlett 

Packard’s Defect Origins, Types, and Modes,” 1999, Available: 

https://www.stickyminds.com/sites/default/files/article/file/2012/XDD2883filelistfilename1

_0.pdf

[B19] MITRE, “Common Weakness Enumeration Homepage,” Common Weakness 

Enumeration Available: http://cwe.mitre.org/.

[B20] S.M. Christey, J.E. Kenderdine, J.M. Mazella, B. Miles, and R.A. Martin, eds., “Common 

Weakness Enumeration: A Community-Developed Dictionary of Software Weakness 

Types (CWE Version 2.1),” September 2011, Available: 

http://cwe.mitre.org/data/published/cwe_v2.1.pdf.

[B21] “CWE Glossary,” Common Weakness Enumeration, Available: 

http://cwe.mitre.org/documents/glossary/index.

[B22] “PDFs with Graphical Depictions of CWE (2.2),” Common Weakness Enumeration

Available: http://cwe.mitre.org/data/pdfs.html.

[B23] MITRE, “Development View with Categories Highlighted,” Common Weakness 

Enumeration, Available: http://cwe.mitre.org/data/pdf/699_cats_only_colored.pdf.

[B24] “CWE: 398: Indicator of Poor Code Quality,” Common Weakness Enumeration,

Available: http://cwe.mitre.org/data/definitions/398.html.

[B25] “CWE-399: Resource Management Errors,” Common Weakness Enumeration,

Available: http://cwe.mitre.org/data/definitions/399.html.

[B26] “CWE-119: Improper Restriction of Operations within the Bounds of a Memory 

Buffer,” Common Weakness Enumeration, Available: 

http://cwe.mitre.org/data/definitions/119.html.

[B27] “CWE-20: Improper Input Validation,” Common Weakness Enumeration, Available: 

http://cwe.mitre.org/data/definitions/20.html.

[B28] “CWE-362: Concurrent Execution using Shared Resource with Improper 

Synchronization (’Race Condition’),” Common Weakness Enumeration, Available: 

http://cwe.mitre.org/data/definitions/362.html.

[B29] A. Avizienis, “Dependability and Its Threats: A Taxonomy,” Building the Information 

Society:, J. -C. Laprie, B. Randell, and R. Jacquart, eds., Boston: Kluwer Academic 

Publishers, 2004, pp. 91–120.

[B30] B. Li, M. Li, K. Chen, and C. Smidts, “Integrating Software into PRA: A Software-Related 

Failure Mode Taxonomy,” Risk Analysis, Vol. 26, August. 2006, pp. 997–1012.

[B31] Hazard Analysis Methods for Digital Instrumentation and Control Systems.

EPRI, Palo Alto, CA: 2013. 3002000509

B-22
APPENDIX C. SOFTWARE FAULT MODES AND EFFECTS 

ANALYSIS METHODS

This appendix presents more details on staff findings on the efficacy of Software Fault55 Modes 

and Effects Analysis (SFMEA) as a method for identifying faults leading to system failure, i.e., 

performance-degradation of a safety function. Although no accepted or proposed standards 

were found for SFMEA56, “companies have taken the traditional methods used for hardware and 

modified them for software” [C9]. Methods that are based on Failure Modes and Effects 

Analysis (FMEA) are referred to as SFMEA and are documented in technical literature. 

Representative SFMEA processes and applications found in the literature are presented in this 

appendix. Observations on the similarities and differences are presented with conclusions 

pertinent to the efficacy of SFMEA as a method for identifying faults leading to system failures 

impairing a safety function.

C.1. SFMEA in Literature Reviewed

C.1.1. System and Detailed Level SFMEA

In his paper “Software FMEA Techniques” [C10], Goddard described two types of SFMEA: 

System level and Detailed level SFMEA. Both techniques are described as being applied 

during system design stages.

System level is applied early in the software design after the architecture has been developed 

and functions have been assigned to separate software elements in the architecture. This 

analysis is focused on top level software design - that is software elements are treated as black 

boxes, the code has not yet been written. The authors state that system level SFMEA should 

be updated as the top level software design progresses and in parallel with detailed design 

SFMEA.

Detailed SFMEA is applied late in the design process when, at minimum, pseudo code is 

available. Software requirements documentation, top level design descriptions, and detailed 

design descriptions should also be available. In performing the analysis, fault modes for each 

variable and each algorithm in each software element needs to be postulated. The effects of 

each postulated fault mode must then be traced through the code to the output signals. In both 

the article and his interview with the NRC, [PG] stated that “detailed level SFMEA is becoming 

moot”57 because it is labor intensive. In particular, detailed SFMEA “may not be cost effective 

for systems with adequate hardware protections. [C10]” 

55 Whereas the term, “failure modes and effects analysis (FMEA)” is used in the context of the 

overall DI&C system, the corresponding concept for software (and other forms of complex logic) 

in a DI&C system is “fault modes and effects analysis.” Logic does not fail in the traditional sense 

of degradation of a hardware component but the system could fail, due to a pre-existing logic 

fault, triggered by some combination of inputs and system-internal conditions.” [C1]

56 The staff did find FMEA standards used for analysis of hardware that includes references: the 

following references to this footnote: [C2],[C3],[C4],[C5],[C6],[C7], and [C8]. 57 Tele-meeting between NRC and [PG] held on September 10, 2010.

C-1

 
During his interview, [PG] stated that “the intent of the software FMEA is not to verify the quality 

of the software ... the entire intent of the software FMEA is to demonstrate that should 

something go wrong whether it’s hardware induced or software induced that the software 

architecture is such that it will catch that something went wrong and that it will handle it in a safe 

manner.” The important assumption is that it is possible to move to a safe state once something 

goes wrong. [PG] further noted that “showing that you can detect something, a discrepancy, is 

miles away from showing that you can isolate it correctly, make some kind of recovery 

technique and push forward.” There is no indication that the SFMEA methods in this reference 

are suitable for assurance or for identifying faults that lead to system failures impairing a safety 

function.

C.1.2. Functional, Interface, and Detailed SFMEA

Bowles and Wan built on the work of Goddard and provided an example of the SFMEA process 

applied to a ball-in-a-tube system in their paper “Software Failure Modes and Effect Analysis for 

a Small Embedded Control System” [C11]. Bowles and Wan described three types of SFMEA: 

functional, interface, and detailed (compared to system and detailed SFMEA as described by 

Goddard [C10]).

In performing the functional SFMEA, Bowles and Wan divided their program into four distinct 

software functions. The paper identified three fault modes each for two of the software 

functions and traced the effects of the fault modes (the local effect, next-level effect, and system 

effect). The local effect is the immediate consequence of the activated fault. The next-level 

effect is the consequence of the local effect. The system level effect is the failure that occurs at 

the system level. For example, the ball-in-tube system in this paper is designed to keep a small 

ball suspended at a predetermined height. Activated faults have local effects that lead to other 

effects which ultimately result in the system not being able to maintain the ball at the 

predetermined height.

For the interface SFMEA, Bowles and Wan identified three interfaces either between software 

modules or software-hardware elements of the system and provided four fault modes for one of 

the interfaces. For their example, local and system effects were identified for each of the four 

faults of one interface identified.

The detailed SFMEA was described as analyzing “the effect of individual software variable 

[faults] on the system output.” The paper listed faults applicable to a few possible variable types 

and provided a table example of detailed SFMEA for one computation used in their example 

system.

In this paper, Bowles and Wan caution that “detailed SFMEA can be most effectively applied to 

software for systems which do not have effective hardware memory protection, processing 

results protection, and memory transfer protection.” The SFMEA tables provided in Bowles’ and 

Wan’s paper include remarks suggesting that design changes are needed. There is no 

indication that the SFMEA methods in this reference are suitable for assurance or for identifying

faults that lead to system failures impairing a safety function.

C-2
C.1.3. SFMEA for Requirements Analysis

Lutz and Woodhouse, in the paper “Experience Report: Contributions of SFMEA to 

Requirements Analysis”[C12] describe their use of SFMEA process in combination with a 

process similar to Fault Tree Analysis (FTA) during the requirements analysis stage of the 

software lifecycle on 24 software modules on two spacecraft systems. The SFMEA process is 

described as “forward searching to identify Cause/Effect relationships” in which data or software 

behavior can result in unwanted effects. Fault modes were analyzed through two tables: A 

Data Table for analyzing communication faults (data read or received by the software process) 

and an Events Table to analyze software process faults (single actions such as “perform a 

calculation, sample a sensor value, and command an antenna to slew to another position”). 

The tables were used to identify concerns and vulnerable areas with sufficient detail so a reader 

could determine whether a requirement needed to be changed. Each table contained four 

columns. The data table columns consisted of: Data Item, Data Fault Type, Description, and 

Effect. The event table columns consisted of: Event, Event Fault Type, Description, and Effect. 

The data and event fault types are listed in Appendix B, which discusses fault modes.

Lutz and Woodhouse noted that “like most failure analysis methods, SFMEA is time consuming; 

much of it is tedious; and it depends on the domain knowledge of the analyst and accuracy of 

the documentation” and that “unlike hardware, a complete list of failure modes for software 

cannot be assembled.” Despite the detractions, Lutz and Woodhouse “found that SFMEA was 

feasible and useful for requirements analysis in a large well-documented system.” There is no 

indication in this work that SFMEA is appropriate for assurance or for identifying faults leading to 

system failures impairing a safety function.

C.1.4. SFMEA for Model-Based and Object Oriented Environments

H. Hecht, in collaboration with X. An and M. Hecht, found SFMEA useful in model-based or 

object oriented design environments, specifically when Unified Modeling Language tools are 

used [C13][C14]. The approach is described for two lifecycle phases: concept and 

design/implementation. The authors also state that the techniques (with the aid of a computer) 

can be used to organize Verification and Validation activities. These authors stated that there 

are fundamentally “two approaches for partitioning software for a system FMEA: functional or 

by output variables, considering one variable at a time.” Both approaches are problematic 

because “functional partitions of a program are subjective and different analysts can come up 

with different lists of functions for a given program” and that “generating a software FMEA based 

on failures of a single output variable misses conditions in which a programming error affects 

multiple variables.” In light of these issues, Hecht et al, sought to automate the SFMEA process 

for use in the concept, design/implementation, and verification and validation (V&V) phases of 

the software lifecycle of model based or object oriented designed software.

The analysis process discussed in Hecht’s work is derived from MIL STD-1629 [C4]. The 

SFMEA worksheet lists the following columns: ID, Component, Fault Mode58, Local Effect, 

Next-Higher-Level Effect, System Effect, Severity, Detection Method, Compensation, and 

Remarks. In this process, components are the methods of the object oriented structures in a 

58 The article uses the column “Failure Mode.” The column heading was replaced for this appendix 

with “Fault Mode” for terminology consistency.

C-3

 
software program. The Fault Modes used are a compressed set based on fault mode set 

provided in the STUK report [C15] but others can be defined by the analyst. The analyst is also 

to provide the information for the compensation and remarks columns.

C.1.5. Code Level SFMEA

Nathaniel Ozarin in three papers: [C16][C17][C18], argued that SFMEA is best performed at the 

code level (comparable to detail level as described by Goddard in [C10]). He argued that 

“moving from the lowest level of analysis to the highest level – typically from the method level to 

the module or package level – a FMEA becomes less accurate, less precise, less tedious, and 

less time-consuming ... a FMEA is based increasingly on the stated intent ... and less on the 

actual product behavior”[C16]. Ozarin used his technique to determine if a single software 

variable can cause catastrophic events or other serious effects. The result of his analysis is to 

make the source code “more robust in specific areas before deployment.” Ozarin provides no 

indication that SFMEA can be used to identify faults leading to system failures impairing a safety 

function.

The details of the process are articulated in reference [C16] of this appendix. Ozarin specifically 

looks at situations where “a software variable is assigned an unintended value” and follows six 

steps for the SFMEA process. The six steps are:

1) System and Software Familiarization

2) Database Tool Development

3) Developing Rules and Assumptions

4) Developing Descriptive [Fault]59 Modes

5) Determining System Effects of Individual [Faults] 60

6) Generating the Report 

The system and software familiarization is the first step because he recommends that SFMEA 

“should not be performed by the people who developed the code.” The purpose of the database 

tool development stage is to develop tables to organize the information obtained through the 

SFMEA process. The proposed tables include a table to organize the different parts of the 

software program (for example, classes could be considered parts of the program). A second 

table defines the functions of each subroutine. The third table lists the appropriate variables 

(both input and output). A third table organizes the input and output variables of the program. 

In step 4 rules and assumptions are outlined for performing the analysis. In step 5, fault modes 

are developed that specify how a variable can take on a value that negatively affects the 

subroutines that use the variable. The effects of each fault are considered in step 5. In step 6, 

the findings and conclusions of the analysis are presented in report format.

59 The word used in the reference is “failure.” It was replaced in this appendix for consistency 

based on the definitions provided in the Glossary. 60 The word used in the reference is “failure.” It was replaced in this appendix for consistency 

based on the definitions provided in the Glossary.

C-4

 
C.1.6. Automated Code Level SFMEA

Snooke et al., through references [C20], [C21], [C22], [C23], has explored automating his 

version of a SFMEA process. Snooke’s work stems from the observation that “code level 

software FMEA has been performed for some years, but has been considered impractical 

except when applied to small pieces of highly critical code” [C22]. Snooke proposes a three 

step process. The first step is that “the source code of the software to be analyzed [be] parsed 

and transformed into a fault propagation model” [C22]. The second step involves injection and 

propagation of faulty input and output variables. The third step is identification of system level 

effects by mapping the functions of the software program to variables that implement the 

functions. Snooke notes that “this work is clearly program language dependent ... model 

construction has been achieved for a large subset of the JAVA language.” Furthermore, the 

work he describes “does not cover all constructs in all languages.” Snooke states that other 

tools and processes could be used to make modifications after performance of an SFMEA

[C23]. Snooke also writes that “generally the response might be to identify and remove 

unintended interactions and improve error checking” [C23].

C.1.7. Other Versions of the SFMEA Process

A few other sources were found describing a SFMEA process (See [C24],[C25],[C26],[C27]). 

These are not discussed to the extent of the examples above because they contained no new 

information. Reference [C24] provided an example of SFMEA for an object oriented software 

framework that utilized a block diagram of the code to develop a list of possible fault modes 

which would be traced from lower level effects up to system level effects. Reference [C25] “did 

not involve a detailed analysis of the software.” The process used in [C26] is similar to 

Goddard’s work [C10]. Park et al, in “Software FMEA Analysis for Safety Software” [C27], used 

SFMEA to analyze an Automatic Test and Interface Processor for a reactor protection system. 

Details about the process used in [C27] were not provided. The article did state that function 

blocks were used to represent the code and that the fault modes considered fell under 

functional, input, and output categories. The process, as described, in [C27] has elements of 

the detailed process descriptions provided in this appendix. Other non-public documents were 

also reviewed but are not discussed. No new information was obtained in these non-public 

documents.

C.1.8. Similarities and Differences among Sources Cited

Each of the versions of the “SFMEA” process found shared some similarities but also had some 

differences. All of the examples describe a process where the software is broken down into 

more manageable parts for analysis, they evaluated fault modes (see Appendix B for a listing of 

the fault modes found), and traced the effects of activating those fault modes. The level of 

abstraction of the software considered was different and ranged from very high level (e.g,, 

system-level, functional) to more detailed (e.g., code level, interface level). The extent to which 

the effects were traced also differed. The software lifecycle stages in which the SFMEA 

process was applied ranged from the requirements stage to late in the design stage. The 

processes described all had limitations to specific software languages, design environments, or 

were not to be used under certain conditions (such as software systems with memory 

protection) [C10].

C-5
C.2. Efficacy of SFMEA in Identifying Faults

The staff acknowledges that the variations of the SFMEA process reviewed have been useful in 

various stages of the software lifecycle61; however, the staff also found that:

• The potential fault space in software of moderate complexity is large [C1]. Many 

faults and fault propagation paths are difficult to identify because they “may be 

masked by some other functionality.” [JM].62 

• No standard process for performing an SFMEA was found. The variations of the 

SFMEA process reviewed were not applicable to all coding languages or 

software systems.

• It is difficult to consider all the possible effects of any identified fault on the 

system. That is, analysis of a fault mode may not provide certainty that any 

system will fail in any particular way because the effects can depend on time or 

situation dependent conditions that may apply only under very specific 

circumstances.

• The techniques reviewed do not identify faults resulting from system-system and 

system-environment interactions [C19]

63

In summary, the contribution of the reviewed SFMEA techniques toward assurance of software 

would be marginal.

C.3. Bibliography

[C1] L. Betancourt, S. Birla, J. Gassino, and P. Regnier, “Suitability of Fault Modes and Effects 

Analysis for Regulatory Assurance of Complex Logic in Digital Instrumentation and Control 

Systems,” Nuclear Regulatory Commission, NUREG/IA-0254, April. 2011.

[C2] International Electrotechnical Commission, Analysis Techniques for System Reliability:

Procedure for Failure Mode and Effects Analysis (FMEA). Geneva: International 

Electrotechnical Commission, 2006.

[C3] SAE, “SAE J1739, Potential Failure Mode and Effects Analysis in Design (Design FMEA), 

Potential Failure Mode and Effects Analysis in Manufacturing and Assembly Processes 

(Process FMEA),” SAE International, Standard J1739, January. 2009.

[C4] “Military Standard: Procedures for Performing a Failure Mode, Effects and Criticality

Analysis,” U.S. Department of Defense, MIL-STD-1629A, November 1980.

61 The methods described in this appendix indicate that SFMEA was useful to the authors and 

practitioners during software design. 62 See Appendix B for a list of faults and fault modes identified during the expert elicitation process 

and in the technical literature reviewed.

63 EPRI Report Number 3002000509 “Hazard Analysis Methods for Digital Instrumentation and 

Control Systems.” published in June 2013 also includes this conclusion.

C-6

 
[C5] SAE, “SAE ARP 5580, Recommended Failure Modes and Effects Analysis (FMEA) 

Practices for Non-Automotive Applications,” Standard SAE ARP 5580, 2001.

[C6] Chrysler Corporation, Ford Motor Company, General Motors Corporation, and Automotive 

Industry Action Group, Potential Failure Mode and Effects Analysis (FMEA): Reference 

Manual. [Southfield, MI]: Chrysler LLC, Ford Motor Co., General Motors Corp., 2008.

[C7] “352-1987: IEEE Guide for General Principles of Reliability Analysis of Nuclear Power 

Generating Station Safety Systems,” ANSI/IEEE, 1987.

[C8] British Standards Institution Group, BS EN 60812:2006 Analysis techniques for system 

reliability. Procedure for Failure Mode and Effects Analysis (FMEA). British Standards 

Institution Group, 2006.

[C9] N. Bidokhti, “How FMEA Improves Hardware and Software Safety & Design Reuse,” 

presented at the International Workshop on Software Reuse and Safety (RESAFE-2006), 

Torino, Italy, 2011.

[C10] P. L. Goddard, “Software FMEA Techniques,” 2000, pp. 118–123.

[C11] J. B. Bowles and C. Wan, “Software Failure Modes and Effects Analysis for a Small 

Embedded Control System,” 2011, pp. 1–6.

[C12] R. R. Lutz and R. M. Woodhouse, “Experience Report: Contributions of SFMEA to 

Requirements Analysis,” in ICRE, 1996, pp. 44–51.

[C13] H. Hecht, Xuegao An, and M. Hecht, “Computer Aided Software FMEA for Unified 

Modeling Language Based Software,” pp. 243–248.

[C14] H. Hecht, X. An, and M. Hecht, “More Effective V&V By Use of Software FMEA.”

[C15] P. Haapanen, Failure Mode and Effects Analysis of Software-Based Automation 

Systems. Helsinki: Radiation and Nuclear Safety Authority, 2002.

[C16] N. Ozarin, “Failure Modes and Effects Analysis during Design of Computer Software,” 

2011, pp. 201–206.

[C17] N. Ozarin and M. Siracusa, “A Process for Failure Modes and Effects Analysis of 

Computer Software,” presented at the Reliability and Maintainability Symposium, 2003. 

Annual, 2003, pp. 365–370.

[C19] Song, Yao, “Applying System-Theoretic Accident Model and Processes (STAMP) to 

Hazard Analysis (2012),” Open Access Dissertations and Theses. Paper 6801.

Available: 

http://digitalcommons.mcmaster.ca/cgi/viewcontent.cgi?article=7836&context=opendisse

rtations

C-7
[C18] N. Ozarin, “The Role of Software Failure Modes and Effects Analysis for Interfaces in 

Safety- and Mission-Critical Systems,” presented at the SysCon 2008-IEEE International 

Systems Conference, Montreal, Canada, 2008.

[C20] C. Price and N. Snooke, “An Automated Software FMEA,” Singapore, 2008.

[C21] N. Snooke and J. Bell, “Combining Functional Modelling and Qualitative Fault 

Propagation to Enable Failure Mode Effects Analysis of Software Systems,” presented at 

the ECAI MONET workshop, Riva, Italy, 2006.

[C22] N. Snooke and C. Price, “Model-Driven Automated Software FMEA,” 2011, pp. 1–6.

[C23] N. Snooke, “Model-based Failure Modes and Effects Analysis of Software.”

[C24] Tadeusz Cichocki; Janusz Gorski, “Failure Mode and Effect Analysis for Safety-Critical 

Systems with Software Components,” presented at the 19th International Conference, 

SAFECOMP 2000, Rotterdam, the Netherlands, 2000.

[C25] T. -L. Chu, M. Yue, G. Martinez-, and J. Lehner, “A Generic Failure Modes and Effects 

Analysis (FMEA) Approach for Reliability Modeling of Digital Instrumentation and Control 

(I&C) Systems,” presented at the 10th International Probabilistic Safety Assessment and 

Management Conference, Seattle, WA, 2010.

[C26] B. J. Czerny, J. G. D’Ambrosio, B. T. Murray, and P. Sundaram, “Effective Application of 

Software Safety Techniques for Automotive Embedded Control Systems,” SAE 

International, Warrendale, PA, 2005-01-0785, April. 2005.

[C27] G. -Y. Park, “Software FMEA Analysis for Safety Software,” presented at the 

International Conference on Nuclear Engineering, Brussels, Belgium.

C-8
APPENDIX D. OPERATING EXPERIENCE AND FAILURE MODES

Consistent with regulations and regulatory guidance, failure mode identification and analysis 

has been useful, as applied in the past by licensees and accepted by the NRC licensing staff for 

regulatory evaluation (for example, FMEA documentation has been reviewed64 to ensure that 

the single failure criterion was satisfied65 and has resulted in operational interactions controls 

such as testing and maintenance66)

67.

For new reactor designs, the staff has continued the practice accepting and reviewing FMEAs to 

ensure that the single failure criterion has been met. FMEAs can be a part of Inspections, 

Tests, Analyses, and Acceptance Criteria (ITAAC) for systems under development. For 

example, the U.S. EPR design, U.S. EPR Tier 1, Table 2.4.1-7 (PS ITAAC), Item 4.18 requires 

the performance of an FMEA for the Protection System [D1].

This appendix discusses practice in the organization of operating experience for a “traditional68” 

electromechanical device, a 3-phase AC, squirrel cage induction motor, and suitability of a 

similar approach for complex software.

D.1. Failure Modes of Induction Motors: Example usage

Three-phase AC squirrel cage induction motors vary over a wide range in combinations of size, 

power, and speed, but the engineering principles and key functional elements are the same, 

namely:

1. stator; stator winding

2. rotor; armature

3. casing or housing

4. shaft

5. bearings

Because the functional elements are the same across the whole range of motors, the 

associated failure mechanisms are the same, and their effect on the behavior of the whole 

motor is the same; thus, a compact, complete set of well-defined failure modes that apply to all 

squirrel cage induction motors can be identified. The following failure69 modes are from 

64 Information reviewed for these purposes is not limited to FMEA documentation. 65 ISG-06[ML11014010] states that “an FMEA is a method for document a single failure analysis 

which is in accordance with IEEE Std 379-2000 as endorsed by RG 1.53 Revision. 2.” 66 Internal NRC experts stated that FMEA has been used to demonstrate that necessary 

surveillances were identified for credible failures [Norbert Carte]. This information is supported by 

SECY-77-439 [ML060260236]. Supporting evidence can also be found by searching licensee 

provided License Amendment Requests. 67 FMEA does not address common cause failure (CCF) when a CCF is rooted in a systemic cause 

such as an engineering deficiency, it is pervasive (i.e., its effects cannot be pinpointed or isolated, 

but could occur at many hard-to-find places). 68 Characterized by long-term stability in engineering principles and design realizations. 69 Note: Usage of the term, failure mode, across guidance documents is not consistent with the 

definition selected in RIL-1002. In this case, it is mixed up with failure mechanisms.

D-1

 
Chapter 14 of the Handbook of Reliability Prediction Procedures for Mechanical Equipment on 

the U.S. Navy’s Naval Sea System Command Web site [D2]:

1. open winding

2. shorted winding

3. worn bearing; worn sleeve bearing

4. cracked Housing

5. sheared (armature) shaft

6. cracked rotor laminations

7. worn brushes (applicable to a direct current (DC) motor with brushes; not applicable to 

an induction motor)

Yet, operating-experience data for the specific failure modes listed above was not found. A 

literature search revealed that frequency of failure data is most often organized by component. 

This organization was found useful, because the key functional elements, their failure 

mechanisms, the dominant, failure modes manifested at the motor-level remained the same for 

all 3-phase AC squirrel cage induction motors. The underlying reasons are (1) the same 

engineered principles and key functional elements are used in all these motors, and (2) their 

dominant conditions of use fall in the same general pattern.

For example, data for large (200 hp) motors can be found in the IEEE Recommended Practice 

for the Design of Reliable Industrial and Commercial Power Systems (IEEE Std 493-1997) [D3]. 

Specifically, Table 3-17 presents the raw number of failures for each component, and Table 

3-19 presents the percentage of failures that pertain to failure initiators, failure contributors, and 

underlying causes.

D.2. Digital System Failure Modes: Utility in organizing operating 

experience data

Digital safety systems emerging in NPPs are complex, the underlying engineering, design, and 

implementation paradigms vary widely, and even for similar systems, conditions of use are 

sufficiently different to challenge meaningful aggregation and organization of data from 

operating experience according to system level failure modes such as those characterized in 

Section 6.1. Furthermore, when a system failure is caused by software or by some other 

systemic factor, “part replacement” (as in traditional electromechanical devices) does not correct 

the problem. The cause has to be removed or corrected; then, it is not the same system 

anymore. Aggregation of failure data across such changes would not support meaningful

analysis as simply as it does for replaced parts.

D.3. Bibliography

[D1] AREVA NP, Inc., “AREVA Design Control Document Rev. 3 - Tier 1 Chapter 02 - System 

Based Design Descriptions and ITAAC - Sections 2.4 Instrumentation of Control 

Systems - 2.4.1 Protection System,” Aug. 2011, Available: 

http://pbadupws.nrc.gov/docs/ML1123/ML11231A066.pdf, 

ADAMS Accession Number: ML11231A066.

D-2
[D2] Naval Surface Warfare Center Carderock Division, “Chapter 14: Electric Motors,” 

Handbook of Reliability Prediction Procedures for Mechanical Equipment, 2011, Available: 

http://www.navsea.navy.mil/nswc/carderock/pub/mechrel/products/handbook.aspx.

[D3] IEEE, 493-1997 (Gold Book), 1998, Available: 

http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=757619

D-3
APPENDIX E. FAILURE MODE RELATED EFFORTS BY NRC PRA 

STAFF AND OTHER STAKEHOLDERS

There is additional work related to identification of digital safety system failure modes that is 

directly sponsored by the NRC, indirectly sponsored through NRC international collaborative 

efforts70, or sponsored by other stakeholders with interests in the nuclear industry. These 

efforts are ongoing and are not expected to impact or change the results presented in this RIL. 

A summary of these efforts is presented in this appendix.

E.1. Probabilistic Risk Assessment Research

As described in the background of this RIL, the Commission, through its 1995 PRA Policy 

Statement, has encouraged the use of PRA technology in all regulatory matters to the extent 

supported by the state of the art in PRA methods and data. Because there is no consensus on 

how to quantify the reliability of digital systems, the NRC is performing research on the 

development of probabilistic models for digital I&C for inclusion in nuclear power plant (NPP) 

probabilistic risk assessments (PRAs).

Brookhaven National Laboratory (BNL) is supporting the NRC in this research through a series 

of projects on digital I&C system reliability modeling and quantification. Previous BNL projects 

have focused on reliability modeling and quantification of digital system hardware and on a 

review of available quantitative software reliability methods (QSRMs) that can be used to 

quantify software failure rates and probabilities of digital systems at NPPs. In addition, this 

previous work involved identification of a set of desirable characteristics for QSRMs. In current 

work, two candidate QSRMs have been selected based on a structured comparison of the 

previously identified QSRMs against the set of identified desirable characteristics for further 

investigation through a case study.

While these two areas of research (i.e., digital I&C PRA and analytical assessment of digital I&C 

systems) are closely related, they address different regulatory objectives. The findings and 

conclusions in the body of this RIL are focused toward assurance of safety critical digital 

systems. The PRA research is focused on developing methods and tools to support future risk 

informed approaches. The evaluation of appropriate failure modes for probabilistic risk 

assessment will be discussed in future NRC reports.71 

E.2. Working Group on Risk Assessment (WGRisk) Activities and 

Results

The U.S. Government actively participates in Organisation for Economic Co-operation and 

Development (OECD) activities. The NRC specifically collaborates through the Nuclear Energy 

Agency (NEA), which is a specialized agency within OECD [E1]. The Committee on the Safety 

of Nuclear Installations (CSNI), which is a committee under the NEA [E2] created and directed 

70 The staff has also been exposed to relevant information through presentations at conferences 

and other meetings with experts from other organizations interested in the digital safety systems. 

These other organizations include NASA, Society of Automotive Engineers, etc. 71 PRA experts in the RES staff have indicated that the failure modes, faults, and fault modes, and 

SFMEA approaches discussed in this RIL may have potential uses for PRA applications. Staff 

working on both the PRA related failure mode research and failure mode research for safety 

assurance are coordinating to ensure technical consistency between the two efforts.

E-1

 
the Working Group on Risk Assessment to set up a task group to coordinate an activity on DI&C 

system risk.72 The NRC joined this effort to complement the work previously described in 

Section E.1above.

One workshop has been held and two others are scheduled73 to discuss and share experiences 

with modeling and quantifying NPP DI&C systems in a PRA context. A resulting action from this

interaction has been to develop a taxonomy of failure modes of digital components for the 

purposes of performing PRA.74 Preliminary work has been done to create the taxonomy but this

work is not complete or publicly available, however, some papers based on the work have been 

presented at the Probabilistic Safety Assessment International Conference (PSAM 11, 2012) in 

Helsinki. The NRC will continue participating in this effort. All learning from this working group 

will be shared with other internal NRC research efforts considering the use of digital system 

failure modes.

Relevant failure modes identified in the WGRisk published papers are in Table 10, “Failure 

Mode Set J - Summary of Failure Mode Taxonomies,” in Section 6.1.1.10. Relevant fault 

modes are located in Appendix B. The failure and fault mode examples provided for Failure 

Mode Set J and Fault Mode Set 9 are from the following 10 organizations:

• Brookhaven National Laboratory (BNL)

• Canadian Nuclear Safety Commission (CNSC)

• Electricity of France (EDF)

• Institut de Radioprotection et de Suerte Nucleaire (IRSN)

• Japan Nuclear Energy Safety Organization (JNES)

• Korean Atomic Energy Research Institute (KAERI)

• Nuclear Research and Consultancy Group (NRG)

• Nordic Nuclear Energy Research (NKS)

• Ohio State University (OSU)

• Technical Research Centre of Finland (VTT)

E.3. Halden Research Project Efforts 

The NRC actively collaborates with the Halden Reactor Project (HRP)75 in Norway on topics of 

mutual interest.76 The staff regularly attends meetings organized by the HRP that update all 

stakeholders on ongoing research projects and closely related research by other organizations.

At the meeting held on October 1-7, 2011, at Sandefjord, Norway, NRC staff attended a 

presentation of ongoing research on cost-efficient methods and processes for safety relevant 

embedded systems (CESAR)77 [E3], which contained information relevant to SRM M080605B 

and the recommendations resulting from the ACRS 576th meeting (October 20, 2010). 

Relevant information from this interaction is presented in the main body of this RIL.

72 This information obtained via email/conversation with Gabriel Taylor

73 As of this writing. 74 Note that the WGRisk Group has not adopted the terminology used in this RIL. Their efforts are 

producing both failure modes and fault modes. 75 Like the WGRisk Group, the HRP is also operates under the auspices of OECD’s NEA. 76 The U.S. has participated (and been one source of funding) in the Halden Research Project since 

1958.

77 CESAR is a European project funded under the ARTEMIS Joint Undertaking. See references for 

more information

E-2

 
E.4. Bibliography

[E1] NEA, “The Nuclear Energy Agency Website,” Organisation for Economic Co-Operation and 

Development Nuclear Energy Agency Available: http://www.oecd-nea.org/nea/

[E2] NEA/CSNI, “Committee on the Safety of Nuclear Installations (CSNI) Webpage,” 

Committee on the Safety of Nuclear Installations Available: http://www.oecdnea.org/nsd/csni/

[E3] CESAR/ARTEMIS Joint Undertaking, “Cost Efficient Methods and Processes for Safety 

Relevant Embedded Systems,” CESAR Project Available: http://www.cesarproject.eu/

E-3