NUREG/CR-7273, Developing a Technical Basis for Embedded Digital Devices and Emerging Technologies

NUREG/CR-7273, Developing a Technical Basis for Embedded Digital Devices and Emerging Technologies

ML21091A019
Person / Time
Issue date:	03/31/2021
From:	Bull E, Hale R, Derek Halverson, Holcomb D, Huning A, Melin A, Muhlheim M, Nack A, Poore W, Wood R Office of Nuclear Regulatory Research, Oak Ridge, UT-Battelle, Univ of Tennessee - Knoxville
To:
Dickey K
References
NUREG/CR-7273
Download: ML21091A019 (335)

Text

NUREG/CR-7273 Developing a Technical Basis for Embedded Digital Devices and Emerging Technologies Office of Nuclear Regulatory Research

AVAILABILITY OF REFERENCE MATERIALS IN NRC PUBLICATIONS NRC Reference Material Non-NRC Reference Material As of November 1999, you may electronically access Documents available from public and special technical NUREG-series publications and other NRC records at the libraries include all open literature items, such as books, NRCs Library at www.nrc.gov/reading-rm.html. Publicly journal articles, transactions, Federal Register notices, released records include, to name a few, NUREG-series Federal and State legislation, and congressional reports.

publications; Federal Register notices; applicant, licensee, Such documents as theses, dissertations, foreign reports and vendor documents and correspondence; NRC and translations, and non-NRC conference proceedings correspondence and internal memoranda; bulletins and may be purchased from their sponsoring organization.

information notices; inspection and investigative reports; licensee event reports; and Commission papers and their Copies of industry codes and standards used in a attachments. substantive manner in the NRC regulatory process are maintained at NRC publications in the NUREG series, NRC regulations, The NRC Technical Library and Title 10, Energy, in the Code of Federal Regulations Two White Flint North may also be purchased from one of these two sources: 11545 Rockville Pike Rockville, MD 20852-2738

1. The Superintendent of Documents U.S. Government Publishing Office These standards are available in the library for reference Washington, DC 20402-0001 use by the public. Codes and standards are usually Internet: www.bookstore.gpo.gov copyrighted and may be purchased from the originating Telephone: (202) 512-1800 organization or, if they are American National Standards, Fax: (202) 512-2104 from American National Standards Institute

2. The National Technical Information Service 11 West 42nd Street 5301 Shawnee Road New York, NY 10036-8002 Alexandria, VA 22312-0002 Internet: www.ansi.org Internet: www.ntis.gov (212) 642-4900 1-800-553-6847 or, locally, (703) 605-6000 Legally binding regulatory requirements are stated only in A single copy of each NRC draft report for comment is laws; NRC regulations; licenses, including technical available free, to the extent of supply, upon written specifications; or orders, not in NUREG-series publications.

The views expressed in contractor prepared publications in request as follows:

this series are not necessarily those of the NRC.

Address: U.S. Nuclear Regulatory Commission The NUREG series comprises (1) technical and Office of Administration administrative reports and books prepared by the staff (NUREG-XXXX) or agency contractors (NUREG/CR-XXXX),

Division of Resource Management & Analysis (2) proceedings of conferences (NUREG/CP-XXXX),

Washington, DC 20555-0001 (3) reports resulting from international agreements E-mail: distribution.resource@nrc.gov (NUREG/IA-XXXX),(4) brochures (NUREG/BR-XXXX), and Facsimile: (301) 415-2289 (5) compilations of legal decisions and orders of the Commission and the Atomic and Safety Licensing Boards and of Directors decisions under Section 2.206 of the NRCs regulations (NUREG-0750).

Some publications in the NUREG series that are posted at the NRCs Web site address www.nrc.gov/reading-rm/ DISCLAIMER: This report was prepared as an account doc-collections/nuregs are updated periodically and may of work sponsored by an agency of the U.S. Government.

differ from the last printed version. Although references to Neither the U.S. Government nor any agency thereof, nor any employee, makes any warranty, expressed or implied, material found on a Web site bear the date the material or assumes any legal liability or responsibility for any third was accessed, the material available on the date cited partys use, or the results of such use, of any information, may subsequently be removed from the site. apparatus, product, or process disclosed in this publication, or represents that its use by such third party would not infringe privately owned rights.

NUREG/CR-7273 Developing a Technical Basis for Embedded Digital Devices and Emerging Technologies Manuscript Completed: July 2020 Date Published: March 2021 Prepared by:

Muhlheim, M. D. 1 Poore, W. P. 1 Nack, A. M. 2 Wood, R. T. 3 Melin, A. M. 1 Bull Ezell, N. D. 1 Hale, R. E. 1 Holcomb, D. E. 1 Huning, A. J. 1 Halverson, D. S.

1Oak Ridge National Laboratory Managed by UT-Battelle, LLC Oak Ridge, TN 37831-6285 2Consultant 3University of Tennessee Knoxville, TN 37996 D. S. Halverson, NRC Project Manager Office of Nuclear Regulatory Research

ABSTRACT An embedded digital device (EDD) is a component consisting of one or more electronic parts that requires the use of software, software-developed firmware, or software-developed programmable logic, that is integrated into hardware equipment to implement one or more system safety functions.

This report provides a technical basis for developing guidance for the safe use of EDDs in commercial nuclear power plants (NPPs) in the United States (U.S.), along with relevant observations, based on their classification, functionality, configurability, consequences of failure, and potential for common-cause failures (CCFs), and it reviews how other agencies worldwide, both nuclear and nonnuclear, regulate, approve the use of, and actually use EDDs.

Areas of interest include the types of components in safety-related applications most likely to have EDDs, methods used by other industries and countries to regulate the use of EDDs, and potential issues noted in industry. This information serves to support the technical basis for a graded approach in the selection and use of EDDs. A tangential supply chain issue is the use of replacement parts or parts in upgrades that may contain an undeclared digital device, as it may not meet the requirements for the safety-related application it is being used in.

Other attributes such as reliability (the ability to perform with correct, consistent results),

diagnostics, operating experience, and failure modes were reviewed because of their use in risk informing the acceptance of the use of EDDs. Emerging technologies associated with EDDs were noted during this work, and are described in this report.

International experience is similar to that acquired in the United States, and regulators around the world are evaluating the safe use of EDDs. Other industries are further along in the use of EDDs and therefore can provide useful insights into their use and regulation.

iii

TABLE OF CONTENTS ABSTRACT .......................................................................................................................................... iii LIST OF FIGURES ............................................................................................................................... ix LIST OF TABLES ................................................................................................................................ xi EXECUTIVE

SUMMARY

................................................................................................................... xiii ACKNOWLEDGMENTS......................................................................................................................xv ABBREVIATIONS AND ACRONYMS .............................................................................................xvii 1 INTRODUCTION ........................................................................................................................... 1-1 1.1 Scope of Study...................................................................................................................... 1-2 1.2 Research Approach .............................................................................................................. 1-3 2 EMBEDDED DIGITAL DEVICES ................................................................................................. 2-1 2.1 What Is an EDD? ................................................................................................................... 2-1 2.1.1 Hardware ..................................................................................................................... 2-2 2.1.2 Software ...................................................................................................................... 2-3 2.2 Diverse Terminology Related to EDDs .................................................................................. 2-3 2.2.1 Smart Device ............................................................................................................... 2-4 2.2.2 Intelligent Device of Limited Functionality................................................................... 2-5 2.2.3 Embedded System...................................................................................................... 2-7 2.2.4 Internet of Things ........................................................................................................ 2-8 2.2.5 Programmable Digital Device ..................................................................................... 2-9 2.3 Examples of How EDDs Are Currently Being Used .............................................................. 2-9 2.3.1 Personal Electronics and Appliances ......................................................................... 2-9 2.3.2 Industrial Sector ........................................................................................................2-10 3 IDENTIFYING DEVICES WITH EDDS ......................................................................................... 3-1 3.1 I&C Vendors for NPPs ........................................................................................................... 3-2 3.2 Types of components in NPPs in safety applications likely to have EDDs .......................... 3-2 3.3 Component Vendors for NPPs .............................................................................................. 3-4 3.4 Vendors of Interest ................................................................................................................ 3-4 3.5 Quality and Functionality ....................................................................................................... 3-5 4 SUPPORTING ISSUES ................................................................................................................ 4-1 4.1 Quality Assurance.................................................................................................................. 4-1 4.2 Undeclared Digital Content.................................................................................................... 4-4 4.2.1 Examples of Undeclared Digital Content .................................................................... 4-6 4.3 Software Tools ....................................................................................................................... 4-8 4.4 Credit for Other Certifications ..............................................................................................4-12 4.5 Cyber Security .....................................................................................................................4-14 4.6 Common-Cause Failures (CCFs)........................................................................................4-15 4.6.1 NRC ...........................................................................................................................4-17 4.6.2 IEC .............................................................................................................................4-18 4.6.3 CSA N290.14-15 .......................................................................................................4-19 4.6.4 DOE ...........................................................................................................................4-19 4.6.5 Military .......................................................................................................................4-20 4.6.6 Examples of CCFs ....................................................................................................4-21 4.7 Operating Experience ..........................................................................................................4-28 4.8 Failure Modes ......................................................................................................................4-30 v

4.9 Component Data..................................................................................................................4-35 4.9.1 FMEA........................................................................................................................4-38 4.10 Graded Approach ................................................................................................................4-42 4.10.1 Complexity / Simplicity .............................................................................................4-44 4.10.2 Classification ............................................................................................................4-48 4.10.3 Functionality .............................................................................................................4-57 4.10.4 Configurability...........................................................................................................4-59 4.10.5 Consequence ...........................................................................................................4-62 4.10.6 Dependability............................................................................................................4-73 4.10.7 Diversity and Defense-in-Depth ...............................................................................4-74 4.10.8 Self-Diagnostic Coverage ........................................................................................4-75 4.10.9 Testing ......................................................................................................................4-83 4.11 Emerging Technology (ET) .................................................................................................4-88 5 EXISTING PRACTICES ................................................................................................................ 5-1 5.1 Domestic Agencies ................................................................................................................. 5-1 5.1.1 U.S. Nuclear Regulatory Commission (NRC)............................................................. 5-1 5.1.2 U.S. Department of Defense (DoD) ............................................................................ 5-5 5.1.3 U.S. Department of Energy (DOE) ............................................................................. 5-5 5.1.4 Federal Aviation Administration (FAA)......................................................................5-13 5.1.5 Food and Drug Administration (FDA) .......................................................................5-14 5.1.6 Federal Energy Regulatory Commission (FERC) ....................................................5-14 5.1.7 Federal Railroad Administration (FRA) .....................................................................5-16 5.1.8 National Aeronautics and Space Administration (NASA).........................................5-17 5.1.9 Occupational Safety and Health Administration (OSHA) .........................................5-17 5.2 International Nuclear Regulating Agencies .........................................................................5-19 5.2.1 Canada ......................................................................................................................5-22 5.2.2 France .......................................................................................................................5-25 5.2.3 Germany....................................................................................................................5-27 5.2.4 India ...........................................................................................................................5-27 5.2.5 Japan .........................................................................................................................5-30 5.2.6 Korea .........................................................................................................................5-32 5.2.7 Pakistan .....................................................................................................................5-33 5.2.8 Romania ....................................................................................................................5-34 5.2.9 Russia........................................................................................................................5-36 5.2.10 United Kingdom.........................................................................................................5-38 6 STANDARDS AND GUIDES ........................................................................................................ 6-1 6.1 Adelard ................................................................................................................................... 6-6 6.2 American Petroleum Institute (API) ....................................................................................... 6-8 6.3 Automotive ............................................................................................................................. 6-9 6.4 CSA Group...........................................................................................................................6-10 6.5 Chemical Safety Board (CSB) .............................................................................................6-13 6.6 Department of Defense (DoD).............................................................................................6-13 6.7 U.S. Department of Energy (DOE) ......................................................................................6-15 6.8 Electric Power Research Institute (EPRI) ...........................................................................6-16 6.9 European Organisation for Civil Aviation Equipment (EUROCAE) ....................................6-20 6.10 International Atomic Energy Agency (IAEA) .......................................................................6-22 6.11 International Electrotechnical Commission (IEC)................................................................6-24 6.11.1 Process Industries...................................................................................................6-30 6.11.2 SIL Comparisons ....................................................................................................6-33 vi

6.12 Institute of Electrical and Electronics Engineers (IEEE) ...................................................6-34 6.12.1 IEEE WG 6.6.........................................................................................................6-36 6.13 International Society of Automation (ISA) .........................................................................6-36 6.14 International Organization for Standardization (ISO) ........................................................6-37 6.15 The National Aeronautics and Space Administration (NASA) ..........................................6-37 6.16 Nuclear Energy Agency (NEA)..........................................................................................6-38 6.17 Nuclear Energy Institute (NEI) ...........................................................................................6-39 6.18 National Institute of Standards and Technology (NIST) ...................................................6-39 6.19 Office for Nuclear Regulation (ONR).................................................................................6-40 6.20 Occupational Safety and Health Administration (OSHA)..................................................6-43 6.21 Federal Railroad Administration (FRA) .............................................................................6-43 6.22 In-House Developed Standards ........................................................................................6-44 7

SUMMARY

AND OBSERVATIONS ............................................................................................ 7-1 7.1 Summary................................................................................................................................. 7-1 7.1.1 Common Names ......................................................................................................... 7-2 7.1.2 EDD Related Issues .................................................................................................... 7-3 7.1.3 Operating Experience ................................................................................................. 7-3 7.1.4 Existing Practices ........................................................................................................ 7-4 7.1.5 Differences by Country................................................................................................ 7-4 7.1.6 Standards / Guidance ................................................................................................. 7-6 7.2 Observations .........................................................................................................................7-10 8 REFERENCES .............................................................................................................................. 8-1 APPENDIX A DEFINITIONS .......................................................................................................... A-1 APPENDIX B COMPONENT TYPES............................................................................................. B-1 APPENDIX C SOFTWARE TOOLS ............................................................................................... C-1 APPENDIX D EMERGING TECHNOLOGY (ET) .......................................................................... D-1 APPENDIX E DATA COMMUNICATION PROTOCOLS .............................................................. E-1 vii

LIST OF FIGURES Figure 3-1 Down-Selection Process to Identify Vendors of Interest for Focused Search for EDDs in 18 Component Types. ............................................................................3-4 Figure 5-1 NPP Supply Chain. ....................................................................................................5-3 Figure 5-2 Interconnectivity of Smart Devices at Cernavoda NPP [268]. ................................5-35 Figure 6-1 Generic and Application Sector Standards for IEC Standards Cover the Entire Lifecycle of I&C Systems in Many Industries. ...............................................6-26 Figure B-1 AV-42 Priority Logic Module ..................................................................................... B-9 Figure D-1 Concept Drawing of a Canned-Rotor, Magnetically Suspended, Reluctance Drive Motor-pump [D.58] ........................................................................................ D-17 ix

LIST OF TABLES Table 3-1 Types of Components in NPPs in Safety Related Applications Likely to have EDDs ..........................................................................................................................3-3 Table 4-1 Certification of Components in the U.S. Nuclear Industry and Other Industries .... 4-13 Table 4-2 Collection of Digital System Failure Modes [132,133,134,135] ..............................4-33 Table 4-3 Causes of Software-related Failure Modes [135] ....................................................4-34 Table 4-4 Causes of Processor-related Failures [136].........4-35 Table 4-5 Collection of the Consequences (Effects) of a Software Hazard ............................4-40 Table 4-6 Determination of Software Complexity [94] .............................................................4-47 Table 4-7 Comparative NPP I&C Safety Classifications [159, 160, 161, 162, 173] ...............4-52 Table 4-8 Software Hazard Risk Index [70] .............................................................................4-54 Table 4-9 IAEA Safety Classes of SSCs Based on Consequence of Failure [174]................4-55 Table 4-10 Relationship Between Functions and PIE [174] ......................................................4-66 Table 4-11 Severity Categories [83] ..........................................................................................4-67 Table 4-12 Probability Levels [83] ..............................................................................................4-68 Table 4-13 SIL Determination Based on IPLs [187] ..................................................................4-70 Table 4-14 Architectural Constraint Table for Type A Devices [75] ..........................................4-71 Table 4-15 Architectural Constraint Table for Type B Devices [75] ..........................................4-72 Table 4-16 Minimum Level for V&V Testing by Integrity Level (IEEE Std. 1012) .....................4-85 Table 4-17 Dynamic Analysis and Testing by IEC SIL (IEC 61508-3 Table B.2) .....................4-86 Table 5-1 Domestic Agencies Reviewed for Guidance on the Use of EDDs............................ 5-1 Table 5-2 Smart Grid Standards Developed by IEC ...............................................................5-15 Table 5-3 Countries Reviewed for Regulations and Guidance on the Use of EDDs ..............5-20 Table 5-4 Safety Categories in Canada and Alignment with Standards [94] ..........................5-24 Table 6-1 Standards Development Organizations (SDOs) and Organizations with Guidance Documents Cited by National and International Industries ...................... 6-1 Table 6-2 Most Similar Works ....................................................................................................6-5 Table 6-3 Approximate Cross-Domain Mapping of ASILs [286] .............................................6-10 Table 6-4 Applicable Methods for Qualification of Predeveloped Software [94] .....................6-11 Table 6-5 Acceptable Standards for the Recognized Program Method [94] ..........................6-11 Table 6-6 Minimum Unit Years of Required Operating History [94] ........................................6-12 Table 6-7 The Software Criticality Matrix Shows how the Severity and Software Control Categories are Correlated to Determine a Software Criticality Index for the DoD ..........................................................................................................................6-14 Table 6-8 SIL Determination Methodology in DOE-STD-1195-2011 [187] .............................6-15 Table 6-9 Minimum Hardware Fault Tolerance Requirements According to SIL (IEC 61511-1 Table 6) ......................................................................................................6-15 Table 6-10 Relationship Between Severity of Failure Condition, Safety Requirement, and Development Level [237] .........................................................................................6-21 Table 6-11 Architecturally Derived (and Reduced) Development Levels [237] ........................6-22 Table 6-12 Industries that Use IEC Standards as a Basis ........................................................6-25 Table 6-13 Maximum Accepted Failure Rates Based on SIL for Low Demand Systems ........ 6-31 Table 6-14 Maximum Accepted Failure Rates Based on SIL for High Demand Systems........ 6-31 Table 6-15 Review Independence Based on IEC SIL [188] ......................................................6-32 Table 6-16 Comparison of SILs for Different Industries [327] ...................................................6-33 Table 6-17 Four-level Software Integrity Scheme in IEEE Std. 1012-2004 ..............................6-35 Table 6-18 Graphic Illustration of the Assignment of Software Integrity Levels (Source:

IEEE Std. 1012-2014, Table B.3) ............................................................................6-35 Table 6-19 Relationship Between Safety Class and IEC SIL ....................................................6-41 xi

Table 6-20 Link Between Categorization, Classification and SIL (TAG-046, Table 1

[126]) ........................................................................................................................6-42 Table 7-1 Summary of Terminology and Standards by Country for Evaluating the Use of EDDs ......................................................................................................................7-4 Table 7-2 Summary of Terminology Used in Guidance/Standards Documents ....................... 7-9 Table A-1 Control Under 10 CFR 50, Appendix B Program Vs. Dedication Under CGD

[A.1] ........................................................................................................................... A-4 Table A-2 Dedication is Based on Criterion VII in 10 CFR 50, Appendix B [A.1] ..................... A-4 Table B-1 Types of Components in Safety Related Applications in NPPs Likely to have EDDs ......................................................................................................................... B-1 Table C-1 Preliminary COTS Acceptance Criteria in NUREG/CR-6421 .................................. C-2 Table C-2 Classes of Software Tools ........................................................................................ C-7 xii

EXECUTIVE

SUMMARY

Nuclear facilities are increasing their use and reliance on digital technology in systems and equipment. The first digital systems mimicked the analog systems, but as experience with digital systems increased, so did the complexity, functionality, communications, etc., of the systems. The same evolution has occurred in other industries and is likely to occur with the use of embedded digital devices (EDDs) in the nuclear industry. An EDD is a component consisting of one or more electronic parts that requires the use of software, software-developed firmware, or software-developed programmable logic that is integrated into equipment to implement one or more system safety functions. Equipment with EDDs can include sensors, breakers, priority logic modules, time delay relays, pumps, valve actuators, motor control centers, and uninterruptible power supplies.

In the United States and around the world, engineering and licensing activities in standards and guidance have been and continue to be developed to address the use of EDDs in safety-related systems. This report provides a technical basis for developing guidance for the safe use of EDDs, along with relevant observations.

The Oak Ridge National Laboratory (ORNL) review found that following the guidance for systems and 10 CFR 50, Appendix B, Quality Assurance, should be sufficient for the functionality of EDDs currently in use and that should be expected in the near term in safety-related applications.

However, the effort in a simplistic application of all the associated criteria in these guidance documents may be more than is necessary for EDDs, as these documents were developed to support systems that may be more complex and require more application-specific code and customization than is necessary or applicable to a particular EDD.

Therefore, this report includes material to serve as a technical basis for graded approaches that the agency could apply to EDDs. Existing flexibilities within the regulations and guidance applicable to EDDs can be applied using a graded approach to the review of devices: (1) developed under 10 CFR Appendix B quality assurance program or (2) dedicated using the commercial grade dedication (CGD) process. Based on ORNLs review, the technical basis for performing such graded approaches is presented based on the classification, functionality, configurability, consequences of failure, and potential for common-cause failures (CCFs). Another possible way to apply a graded approach would be to allow the use of the four safety integrity levels (SILs) available in International Electrotechnical Commission (IEC) standards. This work identifies and describes how industry and many regulators, both foreign and domestic, use IEC SIL certifications to support the CGD process. Another means for applying a graded approach would be to allow the use of different Software Integrity Levels in Institute of Electrical and Electronics Engineers (IEEE) standards such as IEEE 1012-2004 (or similar in later versions of IEEE 1012).

Diagnostics, operating experience, and failure modes were reviewed because of their use in risk informing the acceptance of the use of EDDs. The performance objectives of the EDDs can be demonstrated by showing that they are sufficiently reliable and robust commensurate with their safety significance. EDDs should be designed for a reliability level that is commensurate with the safety significance of the function(s) to be performed. Supporting issues for achieving a given level of functional reliability and robustness include quality, awareness of what digital content is in the EDD, the use of software tools, cyber security vulnerabilities, redundancy, diversity, failure detection, periodic testing (including the use of self-diagnostic features and surveillance tests),

and understanding of failure data/failure modes. Verification and validation (V&V) processes should be included at appropriate design stages to confirm that the necessary safety functions xiii

have been identified and will operate as intended. The metrics and attributes covered in this report provide readers with information to understand the functions of the EDD.

Areas of interest include the supply chain, the types of components in safety-related applications most likely to have EDDs, methods used by other industries and countries to regulate the use of EDDs, and potential issues noted in industry. Being able to leverage the reviews of other countries could also be useful in facilitating more efficient reviews of EDDs. The processes used by Canada and the United Kingdom, which are very different from those of the United States, were reviewed and contrasted in this report.

A supply chain issue related to obsolescence is the use of replacement parts that may not meet the EDD requirements for the safety-related application or an undeclared digital device used in an upgrade to an existing device. This has led to issues in NPP safety-related equipment. This report provides information to be used as a technical basis in supporting potential guidance in this area.

In this work, the term emerging technologies refers to devices related to EDDs, practices, design development and assessment methods and tools, and issues associated with evolving technology and new initiatives from the industry that could be included in license amendment applications or that could impact NPP digital systems, but which are not yet widespread in the U.S. nuclear industry.

Emerging technologies were not investigated as an independent effort considering all types of emerging technologies, but this analysis served to capture those that were identified during the evaluation of EDDs and that are related to EDDs. In addition, existing literature reviewing emerging technologies in the U.S. nuclear industry was reviewed for relationships with EDDs. In many cases, these emerging technologies could also generally apply to digital instrumentation and control systems.

As noted in the report, awareness of an EDDs failure modes is important, and failure modes and effects analyses (FMEAs) have been used to identify the effects of those failures. Issues have been identified with the use of FMEAs for high complexity devices or within interacting systems.

As EDDs are expected to increase in complexity and connectivity, the use of FMEAs to adequately address establishing the critical characteristics needed for dedication becomes questionable. Modern methods and tools designed to address more complex and connected systems may be needed for such EDDs as described in this report.

International experience is similar to that acquired in the United States, and regulators around the world are evaluating the safe use of EDDs. Other industries are further along in the use of EDDs and therefore can provide useful insights into their use and regulation in the U.S. nuclear power sector..

xiv

ACKNOWLEDGMENTS The authors wish to thank the following staff of the Office of Nuclear Reactor Regulation:

Norbert Carte, Samir Darbali, Greg Galletti, and Jack Zhou, for their invaluable insights and dedication throughout the project.

xv

ABBREVIATIONS AND ACRONYMS A2LA American Association for Laboratory Accreditation AC alternating current ACLASS ANSI-ASQ National Accreditation Board ACRS Advisory Committee on Reactor Safeguards ADAS Additional Diverse Actuation System A/D analog-to-digital AECL Atomic Energy of Canada Limited AERB Atomic Energy Regulatory Board AIAG Automotive Industry Action Group AIChE American Institute of Chemical Engineers AMI advanced metering infrastructure AMS Analysis and Measurement Services ANS American Nuclear Society ANSI American National Standards Institute API American Petroleum Institute API application programming interface AOO anticipated operational occurrences ARP Aerospace Recommended Practice ASIC application-specific integrated circuit ASIL automotive safety integrity level ASN Autorité de sûreté nucléaire ATEX Canadian Standards Association, Canada ATWS anticipated transients without scram AZZ/NLI AZZ/Nuclear Logistics Inc.

BDBA beyond design basis accident BSEP Brunswick Steam Electric Plant BSI British Standards Institute BTP Branch Technical Position C&I control and instrumentation CAE claims-arguments-evidence CAMS Containment Atmosphere Monitoring System CANDU Canadian-invented Deuterium-Uranium CBSIS computer-based systems important to safety CCA characteristic for acceptance CCF common cause failure CCPS Center for Chemical Process Safety CDA critical digital asset CDC condensate demineralizer controller CDF core damage frequency CEA French Alternative Energies and Atomic Energy Commission CEAC Control Element Assembly Calculator CFR U.S. Code of Federal Regulation CGD commercial grade dedication CGI commercial grade item CGIE commercial grade item evaluations CIM Common Information Model CINIF C&I Nuclear Industry Forum CIP critical infrastructure protection xvii

CLW co-located worker CM configuration management CNCAN National Commission for Nuclear Activities Control CNSC Canada is the Canadian Nuclear Safety Commission COMAH Control of Major Accident Hazards COTS commercial-off-the-shelf CPC core protection calculator CPLD complex programmable logic device CPU central processing unit CRC cyclic redundancy check CRDC control rod drive control system CSA Canadian Standards Association CSB Chemical Safety Board D3 defense-in-depth DAE Department of Atomic Energy DAkkS Deutsche Akkreditierungsstelle DAS Diverse Actuation System DBA design-basis accident DC diagnostic coverage DC direct current DCS distributed control systems DEC design extension criterion DEG design engineering guide DI&C digital instrumentation and controls DICWG Digital Instrumentation and Control Working Group DNBR departure from nuclear boiling ration DNFSB Defense Nuclear Facilities Safety Board DoD U.S. Department of Defense DOE U.S. Department of Energy DSA documented safety analysis DVC digital valve controller ECCS Emergency Core Cooling System EDD embedded digital device EDF Électricité de France EDG emergency diesel generator EEPROM electrically erasable programmable read only memory EFCOG Energy Facility Contractors Group EMC electromagnetic compatibility EMI electromagnetic interference EPIX Equipment Performance and Information Exchange System EPRI Electric Power Research Institute EPROM erasable programmable read only memory ESF engineered safety feature ESFAS engineered safety features actuation system ET emerging technology EUROCAE European Organisation for Civil Aviation Equipment FAA Federal Aviation Administration FCC Federal Communications Commission FDA Food and Drug Administration FERC Federal Energy Regulatory Commission FF frequency of dangerous failure per year xviii

FHA functional hazard analysis FMEA failure mode and effects analysis FMECA failure modes, effects and criticality analysis FMEDA failure modes, effects and diagnostics analysis FPGA field programmable gate arrays FPL fixed programming language FRA Federal Railroad Administration FSAR final safety analysis report FTA fault tree analysis FW facility worker GAN Gosatomnadzor GFE government-furnished equipment GOTS government-off-the-shelf GWR guided wave radar HART highway addressable remote transducer HCI human-computer interaction HDL hardware description language HHA health hazard analysis HLP hardwired logic platform HMI human-machine interface HPD hardware description language programmed device HR highly recommended HSE Health and Safety Executive IA instrument air IAEA International Atomic Energy Agency IAF International Accreditation Forum IAS International Accreditation Service, Inc.

IC integrated control IC integrated circuit ICBM independent confidence-building measures IDD intelligent digital device IEC International Electrotechnical Commission IED Intelligent electronic device IEEE Institute of Electrical and Electronics Engineers IN information notice INPO Institute of Nuclear Power Operations IP intellectual property IPF instrumented protective function IPL independent protection layer IROFS items relied on for safety ISG interim staff guidance ISO International Standards Organization IT information technology IV&V independent validation and verification KAERI Korea Advanced Energy Research Institute KGS Korea Gas Safety KINAC Korea Institute of Nuclear Nonproliferation and Control KINS Korea Institute of Nuclear Safety KPI key performance indicators LAN local area network LAR license amendment request xix

LAWPS Low-Activity Waste Pretreatment System LER Licensee Event Report LNG liquefied natural gas LOI local operator interface LOPA layer of protection analysis LOR level of rigor LRF large release frequency LVL limited variability [programming] language LWRS LightWater Reactor Sustainability program M&S models and simulations MCC motor control center MDEP Multi-national Design Evaluation Programme MEN Mikro Elektronik MEMS Mirco-Electrical Mechanical Systems MES manufacturing execution system MI mechanical integrity MIAC model identification adaptive control MIMO multiple-input multiple -output MOTS modified-off-the-shelf MLA Multi-Lateral Agreement MMIS man-machine interface system MOX mixed-oxide MPC model predictive control MRAC model reference adaptive control MS mitigation system MTTF mean time to failure N4 current generation of NPPs in France NASA National Aeronautics and Space Administration NDE nondestructive examination NDI non-developmental item NE Office of Nuclear Energy NEA Nuclear Energy Agency NEET Nuclear Energy Enabling Technologies NEI Nuclear Engineering International NERC North American Electric Reliability Corporation NISIWG nuclear industry working group NIST National Institute of Standards and Technology NLI Nuclear Logistics, Inc.

NNCA National Nuclear Control Agency NPJ Nuclear Plant Journal NPCIL Nuclear Power Corporation of India Limited NPEC Nuclear Power Engineering Committee NPP nuclear power plant NPRDS Nuclear Plant Reliability Data System NRA nuclear regulation authority NRC U.S. Nuclear Regulatory Commission NSC Nuclear Safety Commission NSSC Nuclear Safety and Security Commission NUOG Nuclear Utility Obsolescence Group NUPIC Nuclear Procurement Issues Corporation NVLAP National Voluntary Laboratory Accreditation Program xx

O&M operation and maintenance OEM original equipment manufacturer OECD Organisation for Economic Co-operation and Development OLM online monitoring ONR Office for Nuclear Regulation ORNL Oak Ridge National Laboratory OS operating system OSHA Occupational Safety and Health Administration OT operational technology PAEC Pakistan Atomic Energy Commission PASS primary avionics system software PAL programmable array logic PDD programmable digital device PE programmable electronic PED programmable electronic DEVICE PES programmable electronic system PFD probability of failure on demand PFDavg probability of failure on demand-average PFH probability of failure per hour PG&E Pacific Gas and Electric PHA preliminary hazard analysis PHWR pressurized heavy water reactor PID proportional-integral-derivative PIE postulated initiating events PJLA Perry Johnson Laboratory Accreditation PLA programmable logic array PLC programmable logic controller PLM priority logic module PNRA Pakistan Nuclear Regulatory Authority PRA probabilistic risk assessment PROL power reactor operating license PROM programmable read-only memory PS prevention system PSM process safety management QA quality assurance QC quality control QHO quantitative health objective QSRM quantitative software reliability methods R&D research and development RAMS Reliability, Availability, Maintainability, and Safety RFT redundant fault tolerant RG regulatory guide RIL research information letter RIS regulatory issue summary RISC risk-informed safety class RMP risk management plan ROM read-only memory RPCB reactor power cutback RPS reactor protection system RRF risk reduction factor RTB reactor trip breaker xxi

RTCA Radio Technical Commission for Aeronautics RTD resistance temperature detector RTPC real-time processing computer RTNSS regulatory treatment of non-safety system RTOS real-time operating system RTPC real-time process computing RTS reactor trip system SAMS Software Application Management System SAP safety assessment principle SAR safety analysis report SAT site acceptance test SBO station blackout SC safety class SCADA supervisory control and data acquisition SCCF software common cause failure SERH Safety Equipment Reliability Handbook SFF safe failure fraction SFMEA software FMEA SHA system hazard analysis SI safety injection SIL safety integrity level SIS safety instrumented system SISO single-input single-output SoS system of systems SLM safety layer matrix SPIDR System and Part Integrated Data Source SPLD simple programmable logic device SQA software quality assurance SRdB Sellafield Reliability Database SRHA system requirements hazard analysis SRRP Standard Regulatory Review Process SRS Savannah River Site SS safety significant SSCs structures, systems, and components SSHA subsystem hazard analysis SSPS solid state protection system SSS software system safety STI scientific and technical information SwCI software criticality index TAG technical assessment guide TAM technical assessment methodology TCL tool confidence level TF SCS Task Force on Safety Critical Software TGN technical guidance note TMI Three-Mile Island TMR triple modular redundant TÜV German Technical Inspectorate UCI United Controls International UFSAR Updated Final Safety Analysis Report UPS uninterrupted power supply xxii

UTK University of Tennessee, Knoxville V&V validation and verification VDU video display unit VFD variable frequency drive VICWG Vendor Inspection Cooperation Working Group VNIIAES Russian Research Institute for Nuclear Power Plant Operations xxiii

1 INTRODUCTION The commercial marketplace for commercial instrumentation and control (I&C) components and systems is now dominated by digital technology designed to serve the needs of nonnuclear industries, which demand the advanced capabilities and features the digital technology supports.

New nuclear power plants will employ digital technology in safety and nonsafety systems extensively. Therefore, the nuclear power industry stakeholders and U.S. Nuclear Regulatory Commission (NRC) staff must have confidence in the safety-relevant characteristics of this equipment to enable effective and efficient regulation and implementation.

Today, components come from a range of international suppliers, including many companies primarily focused on non-nuclear-industry customers. Additionally, the pool of nuclear power plant (NPP) vendor companies has decreased due to mergers and consolidation and a reduced number of plants being built. Many vendors and original equipment manufacturers (OEMs) in the nuclear industry partner with different sub-suppliers for different projects. For embedded digital devices (EDDs), these market conditions mean that such devices can be introduced through system upgrades, component replacements, and new equipment applications, from many sources.

Regulatory Issue Summary (RIS) 2016-05 [1] heightened the awareness that EDDs might exist in procured equipment used in safety-related systems without the devices having been explicitly identified in procurement documentation, and it recommends that licensees implement efforts to identify these devices. RIS 2016-05 [1] states,

. . . an embedded digital device is a component consisting of one or more electronic parts that requires the use of software, software-developed firmware, 1 or software-developed 0F programmable logic, and that is integrated into equipment to implement one or more system safety functions. . . . EDDs include digital components with executable code or software-developed programmable logic that is permanently or semi-permanently installed within the device (commonly referred to as firmware). Firmware includes, but may not be limited to, devices such as programmable logic devices, field programmable gate arrays, application specific integrated circuits, erasable programmable read only memory, electrically erasable programmable read only memory, and complex programmable logic devices.

Firmware includes programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), erasable programmable read-only memory (EPROM), and electrically erasable programmable read-only memory (EEPROM). The benefits of EDDs include:

• Improvements in accuracy, performance, and reliability

• Asset management improvement through access to a wider selection of suppliers

• Easy access to device maintenance information A disadvantage of an EDD is the increased design complexity and varied regulatory issues.

Equipment with EDDs can include sensors, breakers, priority logic modules, time delay relays, pumps, valve actuators, motor control centers, and uninterruptible power supplies.

1 Firmware refers to the combination of a hardware device, computer instructions, and data that reside as read-only software on that device (IEEE 100 [150], Authoritative Dictionary of IEEE Standards Terms).

1-1

RIS 2016-05 cites regulations, NRC guidance, and industry guidance to heighten awareness of the following key issues:

1. the need to ensure adequate quality and reliability of EDDs,

2. the need to address potential facility vulnerabilities to software common-cause failures (CCFs) of equipment with EDDs, and

3. the need to ensure sufficient procurement planning and material control to identify, review, test, and control EDDs.

Not only is equipment consisting of analog and older digital technology being replaced with commercial grade products containing EDDs, but EDDs can also be retrofitted to work in existing components. For example, valve controllers with EDDs can fit any existing rotary or sliding-stem valve; licensees can mount the instruments to pneumatic actuators to help improve performance and reliability. This significantly increases the number and types of components that may have EDDs, and it also increases the number of vendors and suppliers. Terminology differences can cause confusion because different names have the same meaning and the same names can have different meanings (which relates to functionality). Terminology differences can also make it difficult to discern if an EDD has been added to or is present in a device potentially resulting in the increased use of EDDs without the end user being aware of any changes.

1.1 Scope of Study The objective of this research is to develop a technical basis for evaluating the safe use of EDDs and related emerging technologies. This technical basis should support both existing guidance and the development of new guidance to review (and/or commercial grade dedication of) EDDs and emerging technologies.

Key issues associated with EDDs [2] are detailed below:

• Replacement of an analog device or a solid-state component with a digital device may change the manner needed to ensure adequate quality and reliability, including qualification such as electromagnetic combability (EMC).

• Digital devices may have an increased susceptibility to radiation effects.

• There is new potential for software CCFs that did not exist in the analog components.

• Potential for cyber security vulnerabilities including supply chain as well as the use of wireless technology.

• Sufficient procurement planning, identification in procured equipment, and adequate quality and reliability including qualification (such as EMC) are necessary.

• Testing sufficiency and completeness must be ensured.

These issues can impact any sector of the nuclear community, including conversion and deconversion fuel cycle facilities, power reactors, non-power production or utilization facilities, and enrichment, fuel fabrication, or mixed-oxide (MOX) fuel fabrication fuel cycle facilities.

1-2

This report provides a technical basis for evaluating the safe use of EDDs, along with observations, based on the classification, functionality, configurability, consequences of failure, and potential for CCFs and reviews how other sectors regulate, approve the use of, and actually use EDDs. Other attributes such as reliability (the ability to perform with correct, consistent results), diagnostics, operating experience, and failure modes were reviewed because of their use in risk informing the acceptance of the use of EDDs. Although these can impact the reliability of an EDD, maintainability (the ability to be easily serviced, repaired, or corrected), availability (the ability to be accessed and operated when needed), flexibility (the ability to be easily adapted to changing requirements), portability of software (the ability to be easily modified for a new environment), reusability (the ability to be used in multiple applications), testability (the ability to be easily tested), and usability (the ability to be easily learned and used) were not reviewed because they are primarily commercial (operability) concerns.

Areas of interest include the supply chain, the types of components in safety related applications most likely to have EDDs, methods used by other industries and countries to regulate the use of EDDs, and potential issues noted in industry. This information serves to support the technical basis for a graded approach in the regulation of EDDs. A tangential supply-chain-related issue with respect to obsolescence is the use of replacement parts that may not meet the EDDs requirements for the safety-related application. Equipment obsolescence is a concern for all nuclear plants. It affects plants with old and new systems and components, whether analog or digital. Obsolescence cannot be prevented. Replacement parts that do not meet the original design specifications could result in undeclared digital content that could be introduced through aftermarket parts, special manufacturing, repair/build, equivalency, reverse engineering, or design change. (Replacement parts from existing stock and the surplus market should meet requirements.)

1.2 Research Approach This review used the knowledge of NPP systems and components to identify systems that could receive a digital upgrade in a safety related application as well as the types of devices and technologies that could be applied to them.

The first step was to review the use of EDDs in NPPs, the makeup of an EDD, and the supply chain for EDDs for use in NPPs. The next step was to identify the components most likely to have an EDD. Oak Ridge National Laboratory (ORNL) investigated the literature and nuclear power industry marketplace to identify specific examples and categories of devices, technologies, and systems that contain EDDs or could be upgraded to contain EDDs or emerging technologies.

ORNL then solicited information from industry stakeholders on the most significant categories of devices, their functionality, quality, how they are developed, and how they meet regulation via internet searches and personal contact. This part of the analysis consisted of literature reviews with an emphasis on recent scientific and technical journals, internet searches, vendor contacts, and discussions with technology experts. Input was solicited from nuclear industry representatives such as the Nuclear Energy Institute (NEI), research teams under the U.S.

Department of Energy (DOE) Nuclear Energy Enabling Technologies (NEET) program, foreign regulators, IAEA staff, IEC standards committee members, and vendors for components used at NPPs on the most significant categories of devices and technologies.

An initial survey of other other sectors and international regulatory practices was also performed to support future detailed work.

1-3

ORNL also determined the potential safety implicationsnew hazards, vulnerabilities, failure modes, and triggering mechanisms, and other potential safety concernsbased on the use of digital I&C systems and components in safety-related or important to safety applications at NPPs.

ORNL then identified existing practices and solutions to address the safety implications from other industries or from international organizations.

The laboratory identified and reviewed NRCs current related regulatory infrastructure for EDDs and proposed categories of devices and technologies for evaluation. Direction was given to continue research with a technology neutral, general, high level approach to EDDs with a primary focus on information that could serve as a technical basis for graded approaches and the actionable results of that grading. This involved describing and evaluating EDD related processes and solutions from other nuclear regulators, other safety critical industries, and any methods and standards that are proposed or in use to address these technologies. Further decisions that could be supported in the future included grading based on IEEE Std. 1012, or the Office of Nuclear Regulations (ONRs) technical assessment guide TAG-046, Computer Based Safety Systems.

A secondary issue of interest that was identified was collecting the different terms and definitions used by other regulators and in other industries instead of EDD. Based on that input ORNL performed evaluations of existing practices and solutions to addressing those issues and identified failure modes and other issues with EDDs. The results of these evaluations were then organized into supporting issues and attributes that would support graded approaches.

Information on existing solutions and practices by other regulators, industries, and standard development organizations is also presented in their own sections as supporting information, or reference for future initiatives, as were emerging technologies related to EDDs that were identified during this work.

Summaries and observations were then developed.

1-4

2 EMBEDDED DIGITAL DEVICES Interest in EDDs for monitoring and providing control of components is increasing as pure analog-based components continue to disappear from the industrial I&C marketplace and as the added functionality of digital systems is welcomed.

A typical EDD in an industrial system performs a defined function. EDDs are typically configurable but not programmable (i.e. fixed firmware with configurable parameters or changeable settings), and they can sometimes perform a safety role as temperature transmitters, pressure transmitters, voltage regulators, gas analyzers, boiler controllers, relays, and radiation monitors. In other cases, EDDs may be configurable and programmable.

EDDs may provide monitoring capabilities and diagnostics with human-machine interfaces (HMI),

or they may provide autonomous control of a component. Technology trends seem to be moving toward EDDs with communication capabilities connected into a system arrangement. Thus, EDDs can provide more functionality independently at the component level, and could increase functionality further when coupled with other EDDs to make operational decisions based on inputs from other EDDs within the same flow loop or instrument channel or in another loop/channel.

Important trends in the development of EDDs are detailed below [6]:

1. Because of the high industrial competition and the advances in hardware and software technology, there is a continuous demand for products with more functionality.

2. The functionality is shifting from hardware to software.

3. The functionality is not limited to development by just one manufacturer but may be host to multiple parties.

4. More and more integration in networked environments that affect these devices in ways that might not have been foreseen.

2.1 What Is an EDD?

RIS 2016-05 [1] states:

an embedded digital device is a component consisting of one or more electronic parts that requires the use of software, software-developed firmware, or software-developed programmable logic, and that is integrated into equipment to implement one or more system safety functions.

The term EDD is used primarily in the U.S. nuclear industry, while most other industries and countries use related terms such as smart device, intelligent device, or device of limited functionality.

In general, EDDs currently in NPPs operate in a manner similar to existing analog technology.

However, unlike analog technology, the digital hardware and the associated software in an EDD can introduce new functionality, failure modes, operability issues, and 100% testing may not be achievable. In the emerging technology (ET) arena, increased communication capabilities and 2-1

wireless technology would increase the capabilities of the EDD significantly beyond its analog counterpart.

In the nuclear industry, EDDs currently primarily perform monitoring, diagnostics, or display functions, but an EDD can also perform control functions. However even if the primary additional functionality afforded by the use of an EDD is only diagnostics, the operation of the EDD may still be integral to the safety function of the device. In other cases the EDD may be entirely separate within the device from the portions responsible for the safety function. There have been cases where there are essentially two EDDs present, one for the safety function, and another for other functionality.

EDDs are generally considered to be installed physically within a component. However, this work identified external devices that are in almost all technical ways identical to one internal to a component. That is, the actual digital device can be bolted externally onto an existing SSCs or, for various reasons, portions of the device can be external in a manner that is in almost all technical ways identical to being internal. For example, relays may have the digital device embedded within the device with a container enclosing the component similar to the Allen-Bradley RTC-700 relay [3], whereas valves, pumps, and similar components may have the digital device attached to the outside of the component similar to the FieldVUE DVC6200 controller which is attached externally to a valve [4]. This is an example where diagnostics is actually performed by a bolt on device. In fact, the digital portions of devices may be located hundreds of feet from the actual component and installed on a rack similar to the devices at Pickering [5]. A rack of digital devices would easily allow information and data to be collected and transmitted as a package to a local control station or even to the control room.. Regulatorily such devices would require treatment similar to that described for an EDD.

There can be debate as to whether a particular digital device should be considered an EDD. For example some digital devices are considered to be standalone devices, not embedded or integrated as part of another equipment. This draws a distinction between smart transmitters which may be considered standalone devices, while some digital devices or components for circuit breakers, motor control centers, etc. are embedded or integrated as part of the corresponding equipment. Instances of a digital device embedded into a card used as part of a reactor protection system may or may not be considered an EDD. Again, regulatorily, these devices would require treatment similar to that described for an EDD.

In this report such technologies are sometimes described alongside EDDs.

2.1.1 Hardware The hardware part of an EDD is the physical unit that consists of the digital device that may be installed in or on a component.

Firmware is software specifically designed for a piece of hardware, such as

• microprocessors/microcontrollers,

• PLDs, including CPLDs,

• FPGAs,

• ASICs, 2-2

• programmable read-only memory chips, including EPROM and EEPROM.

Of the component types of interest that were identified and reviewed, some of the vendors contacted indicated that the technologies currently used by them in EDDs were primarily ASICs for NPPs. Other vendors indicated that they would use ASICs, CPLDs, or whatever the customer wanted. In light of the potential costs for dedicating commercial software-based systems, it is possible that development of ASIC-based or FPGA-based components for nuclear power safety applications will expand in the long term. In fact, these types of components are installed in digital devices around the world. Therefore, maintaining an awareness of the technology is warranted as standard integrated circuit (IC) chips are replaced with FPGA and ASICs. Only limited use of CPLDs such as the Allen-Bradley relay, the solid state protection system (SSPS) circuit boards, and the Hagan 7300A ASIC-based circuit boards from Westinghouse used in plant protection systems was found. Other examples are provided in the subsection on undeclared digital content.

2.1.2 Software Software includes the operating software, application software, and software tools, and can be embedded in the EDD firmware or logic. Some EDDs do not contain software during operation although software tools were used during their development.

Embedded software is software that interacts with and controls hardware. More specifically,

• The software is permanently or semi-permanently installed within the device (commonly referred to as firmware).

• The software is embeded in read only memory (ROM); it does not need secondary memories like the hard disk drive in a computer.

• Sensors observe the input and the software processes the data and transmits a signal to the actuators to control the actions or to an HMI.

EDD software may be manually written by coders or through the use of software tools. COTS software is usually dedicated. However, COTS software tools may or may not be dedicated.

One vendor contacted indicated that they write software code and use software tools according to the customer and the application of the component.

2.2 Diverse Terminology Related to EDDs Inside and outside the nuclear industry, different terms for EDDs may mean the same thing or may mean different things. Outside of the nuclear industry, however, the same words may refer to different functions or even to a system. A list of common terms which can apply to a component or system and which may or may not be referring to the same functionality is provided below:

• Embedded digital devices (EDDs)

• Embedded programmable device

• Embedded systems

• Programmable digital device

• Microprocessor-controlled device

• Configurable device 2-3

• Smart device

• Intelligent device

• Intelligent electronic device (IED)

• Intelligent field device

• Digital field device

• Industrial digital device of limited functionality

• Smart manufacturing systems A single term may refer to different types of devices, or different terms may refer to the same type of device and use. For example, components with EDDs may also be referred to as smart devices, intelligent devices, digital field devices, industrial digital devices of limited functionality, etc. However these terms should not be considered synonymous. For example a particularly complex and flexible EDD may not meet the definition of an industrial digital device of limited functionality. In other uses, the term smart device may refer to a single component, or it may refer to its use in a system.

The difference in functionality and terminology should be carefully reviewed when considering any regulatory guidance, standard, method, or operating experience because its use could be different than thought. Based on this review, smart device and intelligent device are the most frequently used terms for components in the nuclear industry, whereas industrial internet of things (IIoT) 2 1F refers to interconnected devices used in the process industries.

Therefore, when determining how digital devices are used and regulated, the term EDD may be too limiting or confusing. In this report, if quoted or referenced material from industry or regulators refers to these devices using another term, then that term is maintained. However, this report otherwise uses the term EDD and the definition provided in RIS 2016-05 [1].

Some examples of the most common terms related to EDDs are provided below.

2.2.1 Smart Device Digital commercial-off-the-shelf (COTS) devices are generally referred to as smart devices in process industries and outside the U.S. This is the most frequent term used. Smart devices are assimilated to computer-based safety systems (CBSSs) [7].

For some companies, the term smart device refers to devices that communicate with neighboring devices to optimize their own performance based on information about surrounding conditions.

An example is a flow transmitter that can autonomously compensate its measured value with data from connected pressure or temperature sensors [8]. For an NPP, this would still be an emerging technology (ET) because of limitations on interconnectivity.

In Canada, a smart device is configurable but not programmable and has limited and pre-developed functionality and low complexity. Example devices are uninterruptible power supplies, transmitters, netting switches, and relays. Example configurations include set points, input/output (I/0) ranges, proportional-integral-derivative controller (PID) parameters, menu settings (event 2 IIoT refers to interconnected sensors, instruments, and other devices networked together with computers in industrial applications, including manufacturing and energy management. This connectivity allows for data collection, exchange, and analysis, potentially facilitating improvements in productivity and efficiency, as well as providing other economic benefits. The IIoT is an evolution of a distributed control system (DCS) that allows for a higher degree of automation to refine and optimize the process controls.

2-4

logging setting, trend settings, user interface, etc.), and enabling features (write protection, passwords, etc.) [9].

In many instances, a smart device is identical to an EDD, but it simply has another name.

However, Sellafield 3 defines a smart instrument as one that measures or directly controls a single 2F process variable, uses a microprocessor, and is a COTS instrument [10]. At Sellafield, the smart instruments could communicate by using highway addressable remote transducer (HART) protocols, although this feature is not currently being used.

Smart devices are not restricted to measurement devices; they also include actuators, valves, motor variable speed drives, and other control equipment. Some users of the term smart devices mean devices that provide control capabilities, such as smart thermostats as used in homes or business environments.

Based on guidance in technical guidance note (TGN) 032, the ONR defines a smart device as

[11]:

• COTS

• Based on microprocessors/microcontrollers running software/firmware

• User configurable but not user programmable; user cannot add new functionality Devices that are typically excluded from the definitions of smart devices are programmable logic controllers (PLCs), supervisory control and data acquisition (SCADA) systems, and distributed control systems (DCSs). Also excluded are unique programmable systemsin essence, anything that contains full variability language. 4 By this definition, non-smart, dumb instruments do not 3F feature a microprocessor and firmware. For example, a dumb pressure transmitter would include simple pressure switches and older transmitters based on analog operational ampliers, etc.

2.2.2 Intelligent Device of Limited Functionality International Society of Automation (ISA)-108.1-2015 [13] defines an intelligent device as a device having digital communication and supplementary functions such as diagnostics in addition to its basic purpose.

Regulators in France use the terms intelligent device and intelligent device of limited functionality.

The French define a device with limited functionality as a device that contains pre-developed software or programmed logic whose primary function is well defined and applicable to only one type of application within an I&C system [14]. Furthermore, the primary function of the device is conceptually simple, is limited in scope, and is not re-programmable after manufacturing. If the devices primary function can be tuned or configured, then this capability is restricted to parameters related to the process. Examples of a digital device with limited functionality include 3 Sellafield is a large multi-function nuclear site on the coast of Cumbria, England. As of 2019, activities at the site include nuclear fuel reprocessing, nuclear waste storage and nuclear decommissioning, and it is a former nuclear power generating site.

4 The IEEE Digital Engineering Guide (DEG) defines full variability language (FVL) as language designed to be comprehensible to computer programmers and that provides the capability to implement a wide variety of functions and applications. For the EPRI DEG, FVL conveys the idea of programming an I&C system or component using languages like C, C++, assembly, etc., to achieve the application. Examples of FVL systems include general purpose computers, such as a plant process computer. However, it must be understood that FVL is also found in software embedded in an I&C system or component, but the FVL is typically hidden from the users point of view.

2-5

sensors, actuators, electrical protection devices, etc., that are functionally simple. Since 2016, the French standard RCC-E has two possible qualification paths: via use of IEC 61508, or via IEC 62671 with provisions for accelerated qualification for devices already certified per IEC 61508.

The Multi-national Design Evaluation Programme (MDEP) and IEC 62671 use the term industrial digital device of limited functionality instead of EDD. MDEP CP-DICWG-07 [15] uses this same term and definition, while the International Atomic Energy Agency (IAEA) [16] uses the same terminology and a similar definition. MDEP does not consider complex devices such as those that use commercial computers (PCs, PLCs) to be an industrial digital devices of limited functionality.

IEC 62671 [17] defines a digital device with limited functionality as a device that complies with the following criteria:

a) The device is a pre-existing digital device that contains pre-developed software or programmed logic (e.g., an [hardware description language programmed device] HPD) and is a candidate for use in an application important to safety.

b) The primary function performed is well-defined and applicable to only one type of application within an I&C system, such as measuring a temperature or pressure, positioning a valve, or controlling speed of a mechanical device, or performing an alarm function.

c) The primary function performed is conceptually simple and limited in scope (although the manner of accomplishing this internally may be complex).

d) The device is not designed so that it is re-programmable after manufacturing nor can the device functions be altered in a general way so that it performs a conceptually different function: only pre-defined parameters can be configured by users.

e) If the primary device function can be tuned or configured, then this capability is restricted to parameters related to the process (such as process range), performance (speed or timing), signal interface adjustment (such as selection of voltage or current range), or gains (such as adjustment of proportional band).

IEC notes that limited functionality is a synonym for dedicated functionality, in which the device is dedicated, as it is used for one specific function that cannot be changed in the field. IEC defines dedicated functionality as the property of devices that have been designed to accomplish only one clearly defined function or only a very narrow range of functions, such as, for example, capture and signal the value of a process parameter, or invert an alternating current power source to direct current. This function (or narrow range of functions) is inherent in the device, and not the product of programmability by the user.

Ancillary functions such as self-monitoring, self-calibration, and data communication may also be implemented within the device, but they do not change the fundamental, narrow scope of the devices applicability.

This same document (IEC 62671) provides the following examples of devices that would not be considered to be devices of limited functionality [17]:

• PLCs, 2-6

• Devices provided with a programmable language, regardless of its restricted nature (in terms of number of function blocks (or equivalent) or inputs and outputs), where such devices have been designed to allow them to be configured for more than one application (example: single loop digital controller with a function block language).

Thus, devices of limited functionality have restricted configurability so that they can be configured in only very limited ways, with relatively few options to control the manner in which a device will function in its intended application. The primary function or singular function (or minimal set of related functions) of the candidate device is required for the system and is important to safely to perform its function, as claimed in the safety analysis, and which is relied on to operate autonomously to achieve this function.

A multi-function device may offer the possibility of using several of its main functions as a primary function, but such a device would not meet the definition of having limited functionality and would be less favored for use than a single-function device.

IAEA SSG-39 [16] states that a device of limited functionality has the following characteristics:

• It contains predeveloped software or programmed logic;

• It is autonomous and performs only one conceptually simple principal function, which is defined by the manufacturer and which is not modifiable by the user;

• It is not designed to be reprogrammable;

• If it is reconfigurable, then the configurability is limited to parameters relating to compatibility with the process being monitored or controlled or to interfaces with connected equipment.

EPRI 1002833 seems to relate limited functionality to a device that can be comprehensively tested; this update to NEI 01-01 states that Example 4-1 describes the case of a digital smart transmitter that uses a relative simple digital architecture internally, drives the existing 4-20mA instrument loop, has limited functionality that can be comprehensively tested, and has extensive operating history. [18].

Regulators in Japan identify the following devices as having limited functionality rather than defining the functionality: actuator, relay, breaker, monitoring device, recorder, and controller [19].

2.2.3 Embedded System Another frequently used term is embedded system, which is used more in industry and in the internet of things (IoT) industry (see below). An embedded system is a combination of computer hardware and software, either fixed in capability or programmable, that is designed for a specific function or functions within a larger system [20]. The global market for embedded systems has been growing because of the increase in devices that include embedded systems. The market has also witnessed vast developments owing to advancements in areas such as material sciences, manufacturing techniques, and research and development (R&D) activities. The result is an increased demand for advanced capability of the devices and product choices.

One of the largest users of embedded systems is the automotive industry that is projected to account for almost 20% of the overall market by 2021 [21].

2-7

Other key markets for embedded systems include consumer electronics, defense, and aerospace

[21]. In particular, the consumer electronics industry has been gaining market share over the years as consumers increase spending on devices such as smartphones, laptops, and tablets for personal use. Adoption of smart electronics devices as a part of smart home setups also helps make the electronics industry a leading embedded systems market.

One area in which embedded systems are different from operating systems and development environments of other larger-scale computers is in the area of debugging [22]. Programmers working with desktop computer environments have systems that can run both the code being developed and separate debugger applications that monitor the actions of the development code as it is executed; however, embedded system programmers sometimes cannot do both.

Some programming languages run on microcontrollers with enough efficiency that rudimentary interactive debugging is available directly on the chip. In many instances, however, debugging of embedded systems requires attaching a separate debugging system to the target system via a serial or another port. In this scenario, the programmer can see the source code on the screen of a conventional personal computer just as would be the case in the debugging of software on a desktop computer. A separate, frequently used approach is to run software on a PC that emulates the physical chip in software, thus making it possible to debug the performance of the software as if it were running on an actual, physical chip.

2.2.4 Internet of Things The internet of things (IoT) builds on the embedded system base, which is expected to continue growing rapidly, driven in large part by the IoT. Expanding IoT applications such as wearables, drones, smart homes, smart buildings, video surveillance, 3D printers, and smart transportation are expected to increase the growth of embedded systems.

Companies are incorporating smart technology such as IoT into their systems and devices by expanding network-capable sensors and equipment to observe from monitors and communications links how a plant is operating. In the past, machines only sent small packets of data to a supervisory manufacturing execution system (MES) or SCADA platform; today, more information is being sent from sensors, equipment, and the plant floor over the same backend network.

In the manufacturing arena, the use of the term smart devices represents the convergence of information technology (IT) with operational technology (OT). IT/OT convergence is the integration of IT systems used for processing and storing all forms of electronic data with OT systems traditionally associated with manufacturing and industrial environments used to monitor events, processes and devices, and allow for adjustments in industrial operations. The purpose is to maintain the availability of the production process and to inform the operators of plant status.

IT/OT convergence may also be referred to as the IoT or the Industrial Internet of Things (IIoT).

Whereas IT inherently includes communications as a part of its information scope, OT has not traditionally been networked technology [20]. Many devices for monitoring or adjustment did not contain programmable devices, and those with computational capabilities generally used closed, proprietary protocols and PLCs rather than technologies that afford full computer control.

Like IT networks, OT networks are generally made up of computers, servers, and network switches. However, unlike IT networks, OT networks are comprised of an entirely different set of 2-8

hardware components that would typically be found on a manufacturing plant floor. The OT may be referred to as the industrial control system (ICS) or SCADA system. Some components in the control system include PLCs that control manufacturing equipment or HMIs that allow operators to interface with machinery.

Companies have begun integrating their IT and OT networks by employing IoT sensors on machinery to monitor valves, pumps, gauges and other pieces of equipment. By converging these systems, companies can monitor and harness data in new ways, implementing live dashboards, anomaly detection, process automation, relevant generation of key performance indicators (KPIs), and hundreds of other features now possible with IT/OT convergence [24].

Other benefits of the IT/OT convergence is that the information on plant status can now be remotely accessed. Avanceons Industry 4.0 [25] provides information at industrial plant levels by allowing workers to remotely access process sensors or final element information like measured value, configuration settings, etc. Among other things, this allows device- and system-performance optimization though delivery of remote services for maintenance and upgrades or repair from a remote location via the cloud.

It was estimated that by 2019, 35% of large global manufacturers with smart manufacturing initiatives had integrated IT and OT systems [21]. This percentage will likely increase as a Gartner survey reports that organizations are increasingly integrating and upgrading their systems, as advancements in technology have demonstrated that integrated systems produce optimized data results [24].

2.2.5 Programmable Digital Device EDDs are a subset of programmable digital devices (PDDs). Institute of Electrical and Electronics Engineers (IEEE) 7-4.3.2-2016 [26] defines programmable digital device as any device that relies on software instructions or programmable logic to accomplish a function. Examples include a computer, a programmable hardware device, or a device with firmware.

2.3 Examples of How EDDs Are Currently Being Used The trend towards using EDDs is pervasivefrom intelligent refrigerators to power plants to the IoT. EDDs are being commoditized into products and components that enhance their performance to make them easier to use. In part, this ease of use results in a move away from supplying data to that of supplying information. An EDD can process raw data into graphs or tables with alarms, indicators, or trends.

EDDs typically monitor parameter inputs, monitor components and their health, and provide an HMI. In some cases, an EDD may provide limited control capabilities. Because of the manner of their current use, EDDs may be too complex for vendors or suppliers to easily analyze and verify.

The use of EDDs in other industries was surveyed in the DOE NEET program, where the market for EDDs is focused now, but its use will migrate to the nuclear industry. Some examples from outside the nuclear industry are provided in the subsections below.

2.3.1 Personal Electronics and Appliances Embedded digital capabilities in consumer products are making their way into industrial uses in pumps, valves, breakers, etc., with sophisticated new diagnostic, monitoring, and control 2-9

capabilities. For example, many consumer products rely on HMI to select or launch applications in appliances or cell phones. The worldwide use of these products and advancements in their capabilities is merging into the components used in the nuclear market. Thus, it is preferable to address the issue now.

Not surprisingly, home appliances are benefitting from the use of EDDs through added functionality and communication capabilities. For example, a smart oven with an EDD can communicate over Wi-Fi or Bluetooth to an application on the users smart phone [28].

2.3.2 Industrial Sector Embedded digital capabilities in various industrial sectors are making their way into control systems and autonomous controls.

EDDs may also transform how the component operates. ITT Industrial Process has developed a pump with an EDD that can derive pump flow for centrifugal pumps without using separate flow sensors. The EDD uses the pump flow information to protect the pumps from minimum flow, deadhead, run-out conditions, and cavitation. When multiple parallel pumps are in use, the EDDs can coordinate and balance all the pump outputs [27]; this communication capability makes the EDD more of a system than a component.

2.3.2.1 Aerospace The aerospace industry was an early adopter of embedded systems. Specifically, guidance computers and avionics packages. These devices can perform complicated measurements and control functions that increase the safety of complex, unstable craft. For example, spacecraft use an embedded computer to take inertial measurements and absolute attitude data from a star tracker and synthesize them into altitude and heading information using Kalman filtering of the variables. These technologies would generally not be considere embedded digital devices.

However some features of these early systems can now be found within EDDs, such as Kalman filtering.

2.3.2.2 Medical Medical devices are also employing embedded digital systems, particularly in wearable devices like intelligent asthma monitors that can identify an oncoming asthma attack before the wearer notices symptoms. Another example is the SMARTdrill surgery tool that recommends where and how to drill based on resistance, bone density, and other factors while also providing surgeons real-time performance feedback.

2-10

3 IDENTIFYING DEVICES WITH EDDS EDDs can be introduced through system upgrades, component replacements, and new equipment applications. With over 6,000 vendors that supply components or services to NPPs and thousands upon thousands of components, a strategy was developed to select types of components in safety systems or systems important to safety that would be likely to have EDDs in the near term.

The use of EDDs in components used in the market is already very prevalent and is expected to expand into the nuclear market. Some current statistics are outlined below that shows its prevelance in industrial commercial and residential use and the limited market in the nuclear industry.

• Industrial, commercial, and residential use:

o 1.5 million valve positioners with digital field devices are currently installed around the world [30].

o 8 million Rosemount 3051 pressure transmitters with digital field devices are currently installed around the world [31].

o 1.5 million Rosemount 644 temperature transmitters, with an optional local operator interface (LOI) are installed around the world [31].

o 1.8 million pressure transmitters are sold annually in the United Kingdom [32].

• Nuclear industry:

o 540 pressure transmitters were purchased by the entire UK nuclear industry [32].

Thus, the data shows that a general market search would not indicate how EDDs are in use at NPPs. Several approaches were considered for identifying components with EDDs and their functions that would be relevant to safety-related applicatons at NPPs. One approach would be to focus a survey strictly on EDDs. DOEs Nuclear Energy Enabling Technology (NEET) program used this approach and focused their internet searches on EDDs. They identified the EDDs in use primarily for residential, business, and industry [33]. Their searches showed that the pervasive use of EDDs are outside the nuclear industry, which is supported by the data above. In terms of functionality, the research performed for this effort showed that EDDs primarily provide communications and diagnostics. However, based on the prevalence of EDDs as shown by the NEET study, it is very likely that as the use of EDDs increases, EDDs will migrate to the NPP industry, and other suppliers currently outside the nuclear industry will become NPP suppliers/vendors.

Of interest are the vendors that supply components with EDDs to NPPs. To this end, the approach was to specifically identify NPP vendors that supply selected components of interest.

With over 6,000 vendors that supply components to NPPs, it was surmised that vendors that also design, build, and install I&C systems would be the most likely to first couple EDDs to their components. This lead to another choice: develop questionnaires (surveys) or perform focused surveys by directly contacting the down-selected list of vendors.

3-1

A review of studies that sent questionnaires to licensees showed unfavorable response rates.

Some examples are provided below:

• EPRI developed a questionnaire (survey) about retrofits for utilities [34]. EPRI did not pursue this approach at the recommendations of the utilities themselves.

• EPRI conducted a survey of the application of advanced technologies to systems within NPPs by developing a questionnaire to identify the use of advanced I&C and control room technology [35]. The questionnaire was distributed to representatives of numerous domestic NPPs. There is no publication available that documents survey findings from this activity.

• ORNL did have some success in its survey of emerging technologies [36] when combined with literature reviews, internet searches, vendor contacts, and discussions with technology experts. The key to ORNLs success was the direct contact with vendors.

The responses to surveys and their usefulness (or lack thereof) and ORNLs success of directly contacting vendors led to a different approach. The chosen path forward was to

• identify vendors that provide I&C systems to NPPs

• identify those types of componets likely to have EDDs that are used in safaty applications

• idenfity those vendors that supply one or more of the components likely to have EDDs

• identify those vendors that provide I&C systems and one or more of the comonents likely to have EDDs

• contact the vendors to determine the characteristics and functionality of the EDDs 3.1 I&C Vendors for NPPs Because it was surmised that the vendors who also design, build, and install I&C systems in NPPs would be those most likely to couple EDDs to their components supplied to NPPs, the first step was to identify those I&C vendors.

Our review identified those digital I&C systems and components that are currently used or are planned for use in domestic NPPs. The research approach involved data mining of available publications, reports, and information sources, followed by a more detailed search of operational data. The result of the review identified 42 I&C vendors who had some type of I&C system or platform approved by the NRC or that was undergoing NRC review. The I&C systems included PLCs, microprocessors, and FPGA-based systems.

3.2 Types of components in NPPs in safety applications likely to have EDDs A typical NPP may contain ~200 pumps and over 5,000 valves [37]. That same plant may contain some 10,000 sensors and detectors,including up to 20 neutron detectors, 60 resistance temperature detectors (RTDs), as many as 100 thermocouples, and 500-2,500 pressure transmitters [38]. AZZ/Nuclear Logistics, Inc. partners with manufacturers and can offer over 10,000 prequalified components [39]. Thus, the number of components, component types, and 3-2

vendors is too large to thoroughly review, and a random collection of data would likely produce indefensible results.

In selecting a representative set of components likely to contain EDDs, a review was performed of the list of component vendors, along with information from previous studies on EDDs [47, 48]all while overlaying the function of an EDD. Component lists were reviewed from the following sources:

• Nuclear Utility Obsolescence Group (NUOG) [40]

• Nuclear Suppliers Association (NSA) [41]

• Nuclear Plant Journal (NPJ), web site [23] and digital copy of journal [43]

• Nuclear Engineering International (NEI) [44]

• American Nuclear Society (ANS) products and services issue of Nuclear News [39]

• Nuclear Procurement Issues Corporation (NUPIC) [45]

• World Nuclear Association [46]

• Nuclear Engineering Enabling Technologies (NEET) workshop on the Qualification of Embedded Digital Devices that included government and industry, utilities, universities, and vendors [47]

• University of Tennessee Knoxville (UTK) identification of EDDs in selected components [33, 48]

Eighteen types of components were identified as likely to be used in NPPs in safety related applications (Table 3-1) (Appendix B). This list is not necessarily a complete list of components that may include EDDs, but a down-selection process was necessary to determine the scope of the problem. During the down-selection process, services (non-components), passive components (e.g., piping), and structural components (including cable trays) were removed from further review.

Table 3-1 Types of Components in NPPs in Safety Related Applications Likely to have EDDs Chart (data) recorders Priority logic modules Circuit breakers Pumps Diesel generators Radiation monitors Flowmeters Relays, time-delay relays Gas analyzers Temperature transmitters Level meters Uninterruptible power supplies (UPSs)

Motor control centers (MCCs) Valve actuators Power supplies Valves Pressure transmitters Voltage regulators 3-3

3.3 Component Vendors for NPPs To determine the quality and functionality of the EDDs, those vendors with approved I&C systems in NPPs that also produce a component in the list of most likely components to be installed in an NPP were identified. Thus, this review focused on those vendors that provide components to NPPs. Component vendor lists were reviewed from the same sources used to identify types of components listed above.

From the over 6,000 vendors that provide components, structures, or services to NPPs.

Eliminating those vendors that provide at least 1 of the 18 component types of interest reduced the number of unique vendors to 320.

3.4 Vendors of Interest To reduce the number of vendors to consider further, it was hypothesized that those vendors most likely to embed digital devices into their components would be those that also design, build, and install I&C systems in NPPs. Thus, the list of vendors that supply at least one of the component types of interest to NPPs likely to be used in safety related applications was reduced to those vendors that also design, build, and install I&C systems in NPPs. When the list was reduced to only include vendors that supply at least 1 of the 18 component types to NPPs and that also provide I&C systems, 17 vendors remained (Figure 3-1).

Figure 3-1 Down-Selection Process to Identify Vendors of Interest for Focused Search for EDDs in 18 Component Types.

3-4

These 17 I&C vendors were contacted for the focused vendor searches:

• Allen Bradley

• Areva/Meggitt

• Eaton/Curtler Hammer

• Emerson/Rosemount

• Areva/Miron

• Framatome

• GE/GE-Hitachi

• Foxboro

• Invensys/Schneider Electric

• KEPCO/KNCH

• Honeywell

• Rolls-Royce

• SAIC

• Mitsubishi

• Westinghouse

• Yokogawa

• Siemens ORNL contacted these selected vendors via personal communication using the contacts provided in the products and services lists. Although surveys are typically not productive, this method of personal communication proved beneficial.

The personal contact with vendor engineers and representatives was insightful, and beneficial. In fact, the perception was that the vendors would partake in a workshop to discuss the use of EDDs and the requirements related to the use of firmware.

From discussions with vendors, it was noted that the software developer may be the licensee, the vendor, a company working on behalf of either, or a commercial software development company.

For example, Allen Bradley, owned by Rockwell Automation, has PLC-based bus load sequencers, a feedwater controller, and BOP controls. For components, Allen Bradley has safety relays, solid-state pressure sensors, flow switches, solid-state temperature sensors, and temperature controllers, to name a few. For the Allen Bradley 700-RTC relay however, Texas Instruments (TI) was responsible for the design change from an IC chip to the CPLD [49].

Thomasnet.com, which provides over 500,000 detailed supplier profiles, states that TI is a Manufacturer of analog and embedded processing devices. This shows that outsourcing does occur, although it is not readily apparent.

Other I&C vendors or component vendors not contacted may or may not develop their own EDDs.

However, the information obtained from this subset of vendors will most likely remain the same regardless of the sample size. In fact, randomly contacting these other vendors did not provide additional information on the quality and functionality of the component types beyond what was already known.

A complication affecting this selection process is that over time, companies merge or are acquired. For example, Eaton, which was included in our selection process, now includes Cooper Power Systems, Cutler-Hammer, Holec, Kearney, Kyle, McGraw-Edison, Pedersen Power Production and the distribution and control business unit from Westinghouse.

3.5 Quality and Functionality The desired output of this process involving contacting vendors was to learn about the quality and functionality of the EDDs. Not surprisingly, most of those vendors that provide I&C systems for use in NPPs have a 10 CFR 50, Appendix B program. Somewhat surprisingly (to the ORNL researchers), because not all of the internal components come from Appendix B-approved suppliers, some vendors sent the EDDs to a commercial grade dedicaiton (CGD) facility, even though the vendors design and manufacturing were performed under an Appendix B program.

3-5

Functionality/function for EDDs can be used to categorize devices. The functionality/function(s) of these 18 component types selected for review were determined to allow the classification of the devices at the component level rather than the system level. At the device level, functionality attributes identify significant functional activities and actions performed by the EDDs. This attribute addresses the functionality provided by an EDD that enables implementation of its functions. For the 18 component types, it was determined that the EDDs perform the following functions:

Non-control functionality

• Monitor the components inputs o Monitoring can be used to provide component health information or process variables; or it could be used by licensees to reduce surveillance activities and extend calibration intervals of I&C equipment.

o The process variables monitored in the EDDs by component type is dependent upon the purchase order received by the vendor. Depending upon the type of device, the process variables include voltage (v), frequency (f), current (i), temperature (T),

pressure (P), flow, etc. These variables can be transmitted to a control system such as the RPS.

o There could be an interface between the EDD controls and the sensors or the sensor could be part of the EDD.

• Diagnostics o Self-diagnostics are one means that can be used to assist in detecting partial failures that can degrade the capabilities of the system but may not be immediately detectable otherwise.

o Diagnostics are typically coupled with a monitor or a display device. The diagnostics can be separate from the control device and could even be developed and certified to different safety integrity levels (SILs).

o A software-to-system interface provides the data necessary for diagnostic coverage and alarms.

• Display (i.e. provide an HMI) o HMIs used in the industrial context are mostly screens or touchscreens that connect users to machines, systems, or devices. HMIs can be simple screen displays mounted on components, advanced touchscreens, multi-touch-enabled control panels, push buttons, computers with keyboards, mobile devices or tablets.

o In industrial facilities, factory operators use HMIs to control and automate machinery, as well as their production lines. A remote integrated HMI with a control function that has 2-way communication should follow guidance for systems rather than guidance tailored for devices.

o The basic HMI display of the process variables monitored can display alerts if a variable is outside of expected parameters, and it can display diagnostic results.

3-6

o The HMI screen can be integrated with a control function to allow operators to turn on/off components or to allow for adjustment of parameter displays, EDD operating parameters, etc.

o There will be an interface between the EDD and the display monitor (i.e. HMI).

Control functionality

• Control o An example of a control function for an EDD would be to take a reference signal in the process, compare it to the setpoint, and then change the output to the control device accordingly to minimize the error (such as a voltage regulator).

o A device with limited functionality could have a control function. That is, a device of limited functionality is a device whose primary function is well defined and applicable to only one type of application within an I&C system.

Communications functionality

• Communications o For this report, digital communications are not considered to be a functionality of an EDD because the communication function would be in support of a control or non-control function. If the primary purpose of a digital device were communications this would be a part of a system as opposed to an EDD. Further, while the IIoT inherently covers communications as a part of its information scope, the current use of EDDs in the nuclear power industry has not used networked technology. Once an EDD is connected and communicating (with possible voting logic), its functionality would affect system level concerns, such as independence between redundant trains or safety/non-safety interactions, which would need to be reviewed; current regulations and guidance adequately cover this.

o Communication capabilities may be present to allow the capability to perform diagnostics, maintenance, or software updates. These types of capabilities may not require networking.

The functionality of diagnostics allows the health of a device to be monitored continuously and remotely (through one-way communications). Devices with communication capabilities in use in industry can be configured remotely, and some devices allow firmware updates to be installed remotely. The process industry uses diagnostics to identify degradations, thus allowing corrective action to be taken and avoiding an upset condition.

3-7

As an example, the functionality of diagnostics related to a control valve is the capability to detect a variety of issues such as the following potential problems:

• Air leakage

• Valve assembly friction and dead band

• Instrument air quality

• Loose connections

• Supply pressure restriction

• Valve assembly calibration The diagnostic capability can also facilitate characterization of the valves performance following maintenance to increase the assurance that the valve will function properly when returned to service.

The control functionality uses onboard processing and sensor information or inputs such as from RPS or ESFAS for local open-loop and closed-loop control of process parameters. Utilizing feedback and sensor information within the EDD could be used to improve the transient response and accuracy of the controlled process parameters without resorting to centralized control.

The onboard processing ability in EDDs can be used to locally perform tasks such as:

• Self-calibration

• Continuous device diagnostics

• Statistical process information analysis

• Detection of sensor failures and switching to backup sensors

• Digital filtering

• Temperature compensation

• Known sensor error compensation

• Local data storage

• Signal analysis EDDs with expanded communication capabilities (an ET) would enable new modes of interaction between the operator and the device and inter-device communication and coordination.

Communication functions would be expected to be separate from those that allow for modification of the configuration of the EDD or for making program changes to the EDD. Once the device has a sufficiently expanded communications function it would behave more like a system rather than a simple component because of the interconnectivity between devices.

An EDD can have one or more of the functionalitiesmonitoring, diagnostics, display, control, and communicationsduring its operation. In fact, many devices have several of the functional characteristics listed above. That is, if the EDD were to provide some sort of control, then it would likely have diagnostics and monitoring capabilities. For example, low-voltage circuit breakers may incorporate embedded digital equipment to provide (1) monitoring functions or (2) monitoring and control functions.

A number of important trends can be observed in the development of embedded systems (which would apply to or include certain EDDs) and their functionalities [51]:

1. Users demand that products have more functionality.

3-8

2. The functionality provided by embedded systems is shifting from hardware to software.

3. The functionality of embedded systems is not solely developed by just one manufacturer but is common to multiple parties.

4. Embedded systems are more and more integrated into networked environments that affect plant systems in ways that were not foreseen during their construction.

At the component level, the functionalities required from the device, as well as the performance attributes associated with that functionality, include performance characteristics such as response time, memory allocation, reliability, and environmental qualification requirements. Many studies on functionality are focused at the micro level and specifically evaluate the functionality of the system.

At the system level, the functionalities required from the device reflect the purpose of the device.

Simply stated, the software should operate as it is supposed to, and the macro level evaluation addresses the impact of its failure on the system and the devices fitness for purpose. The macro level analysis identifies the users/products needs that are documented as the features of the system. This is typically described by documenting the intended use of the device to be designed.

This difference between component and system level analysis is important. The functionality of new features (compared to analog) is important only for those devices providing a function required for the system level function or that could impact providing the system level function such as through timing or internal communications. That is, for those functions such as monitoring, the component may still be operable, even if the displays fails.

3-9

4 SUPPORTING ISSUES The introduction of EDDs can affect safety by creating new hazards, vulnerabilities, failure modes, triggering mechanisms, and other potential safety concerns at both component and system levels.

New vendors into the market may not be familiar with the quality requirements associated with the nuclear power industry, especially for safety related applications.

The NRC issued RIS 2016-05 [1] to clarify their technical position on existing regulatory requirements for the quality and reliability of safety-related equipment with EDDs. RIS 2016-05, which applies to equipment, instrumentation, and controls that contain EDDs in safety-related systems, states that potential safety issues from using EDDs should adequately address the following:

1. The quality and reliability of EDDs that exist in actuation equipment

2. The potential vulnerabilities to CCFs

3. Sufficient procurement planning and material control to identify, review, test, and control EDDs Other issues include the potential for undeclared digital content in the devices, the difficulty in obtaining information about a devices design and operating history, the use of software tools, accepting certifications (similar to dedication) from other entities, new cyber security concerns, and the possibility that a graded approach may be beneficial for approving the use of EDDs.

In addition to meeting performance requirements, the EDDs should be designed for a reliability level that is commensurate with the safety significance of the function(s) to be performed.

Design attributes for achieving a given level of functional reliability and robustness include those related to quality, knowledge of the digital content in the EDD, the use of software tools, cyber security vulnerabilities, redundancy, diversity, failure detection, periodic testing (including the use of self-diagnostic features and surveillance tests), and failure data/failure modes.

Verification and validation (V&V) should be included at appropriate stages of the design to confirm that the necessary safety functions have been identified and will operate as intended.

These issues, discussed below, can be used to guide regulatory judgements and recommendations when undertaking technical assessments of the use of EDDs in safety related applications. The supporting issues can be used to appropriately grade the review of the use of EDDs. In addition, the supporting issues can be used to guide assessments of components in proposed new nuclear facility designs.

4.1 Quality Assurance The NRC has regulatory requirements to provide adequate assurance that the appropriate Quality Assurance(QA) is achieved; however, making this determination has proven to be problematic for components that contain EDDs, particularly if the presence of the EDD is not explicitly identified.

4-1

Quality Assurance is considered acceptable if the component or system is designed, manufactured, and maintained as required in 10 CFR 50, Appendix B. Some other countries and industries use International Standards Organization (ISO) 9001 to ensure adequate QA. SECY-03-0117 reviewed ISO 9001-2000 against the existing framework of Appendix B and concluded that ISO 9001 does not meet the requirements of Appendix B [52].

Two different methods of approving a component for use in safety-related applications are described in 10 CFR Part 21. The first method is to design and manufacture the component under a 10 CFR 50, Appendix B-compliant QA program. The second method is to dedicate a commercial grade item (CGI), which, if implemented correctly, is considered to be equivalent to the first method. The key in CGD is being able to identify and verify appropriate critical characteristics. Only if a safety-related component has appropriate critical characteristics that can be verified without requiring in process inspections and verifications can the component be purchased as a CGI and commercially dedicated.

Commercial grade dedication must be performed under an Appendix B QA program. In some cases, the licensees perform the CGD themselves.

The basis for a CGD program is provided in 10 CFR 21 for the reporting of defects and noncompliance. EPRI 3002002982 [53] (an update of EPRI NP-5652) provides guidelines for the CGD program, which can be used to dedicate hardware, software, and services. Software includes the operating (platform) software, application software, and software tools (compilers, assemblers, libraries) and can be embedded in programmable/configurable/fixed firmware, or it can be logic embedded in digital CGIs. The same requirements that apply to dedication of CGIs also apply to the dedication of CGD services, such as calibration [53].

The guidance in EPRI TR-106439 [54], which the NRC concluded contains an acceptable method for dedicating commercial grade digital equipment for use in NPPs, already includes provisions for flexibility in quality based on other factors, thus allowing for describing graded approaches within the existing guidance. Specifically it states:

The dedicator must determine which activities are appropriate for each application.

In general, the choice and extent of activities undertaken to verify adequate quality, and the specific criteria applied in making the assessment, depend on the safety significance and complexity of the device.

Safety significance depends on the function of the device and the consequences of its failure, and includes consideration of backups or other means of accomplishing the safety function. This includes consideration of the cumulative effects of upgrades to systems and equipment that provide diverse backup functions, especially in regard to preserving integrity of the intended diversity. Complexity includes the complexity of the device (e.g., overall architecture, number of functions, inputs and outputs, internal communications among processors or modules, and interfaces with other systems or devices) and complexity of the software.

Table 4-2 in EPRI TR-106439 identifies the following activities for assessing the built-in quality for commercial digital equipment; this list is not all-inclusive [54]:

• Review of the design, its documentation, and hardware and software implementations 4-2

• Review of the design/development process and its documentation, as it was applied for the item being evaluated

• Review of qualifications and experience of personnel involved in design and verification

• Review of vendor QA program and practices, including SQA

• Review of vendor configuration control program and practices

• Failure analysis

• Review of vendor testing

• Review of product operating history Regardless of whether the licensee used a commercial grade dedicating entity or performed testing and analyses for dedication themselves, under 10 CFR 21.21(c)(1) [55], the licensee is responsible for identifying defects and failures for dedicated items. If a commercial grade dedicating entity is used, they also have this responsibility.

EPRI TR-106439 (endorsed by NRC) identifies NUREG/CR-6421, NUREG/CR-6294, and EPRI TR-104159 (not endorsed by the NRCs endorsement of EPRI TR-106439) as documents that provide lists of attributes (not considered to be all-inclusive) related to the quality of commercial-grade digital equipment.

As noted in IEEE Std. 7-4.3.2-2016 (not currently endorsed by NRC), not every piece of commercial equipment is manufactured with the quality and design integrity necessary to be dedicated [26]. A preliminary determination of the likelihood of success should be performed to determine whether pursuit of commercial grade acceptance and dedication is likely to succeed.

This should include an evaluation of how cooperative the equipment vendor will be to detailed design analysis of its equipment, as well as the degree to which compensatory actions are required and if required if they are possible, and how sufficient these compensatory measures can be for missing design, review, testing, and other essential documentation.

The safety significance and simplicity of the system also play a role in assuring quality and dependability [18]. Software development activities must be more rigorous for applications with high safety significance. Simple systems with well-defined failure modes tend to allow for more thorough testing of all I/O combinations than complex systems; complexity increases the uncertainty associated with demonstrating software quality.

Typically, evidence of QA and the manufacturers use of appropriate development and manufacturing processes is obtained by performing a site visit, audit or inspection, or survey of the manufacturers site and quality controls. The scope of this activity focuses on the particular device being assessed, although some procedures might be applied to a number of different devices by the same manufacturer.

Paragon, a commercial grade dedicating entity of printed circuit boards, power supplies, breakers, motor control center components, pressure gauges and switches, electrical components, mechanical components, identified the following as challenges in dedicating components [56]:

• Access to Design Information/Requirements 4-3

o Lack of Information from Utility Design attributes Safety function Qualification requirements Host component information (if required)

IP/Proprietary issues Purchase orders have dated information, old specifications Utilities are doing their own CGD vs. outsourcing o Lack of information from OEM Unwilling to provide adequate detail Proprietary Obsolescence; no longer supported OEM Information stagnant Many OEMs are now gone; obsolescence The dedication process requires access to numerous documents, which include development process artefacts such as verification documents and results of analysis and testing performed by the manufacturer. Experience shows that it is important that manufacturers and dedicators access design documentation early in the engagement process with the manufacturer, e.g.,

setting up non-disclosure agreements [7]. The degree of a designs testability promotes proper operation and provides confidence that no new failure modes will be introduced. Adequacy of testability of EDDs is more likely to be successfully proven through its simplicity of design. EDDs, unlike systems, are typicaly simple devices of limited functionality with few interfaces, so their testing should be comparatively straightforward.

Nevertheless, despite a quality development process and thorough V&V and testing, complexity and other factors such as the inability to detect and eliminate errors may mean that defect-free EDDs cannot be guaranteed with reasonable assurance.

4.2 Undeclared Digital Content Commercial off-the-shelf (COTS) devices may consist of digital components with embedded software (i.e., firmware, FPGAs), but the user or assessor may be unaware of their presence.

Even for I&C devices, it may be difficult for the user or assessor to identify an embedded digital component. As digital content has become increasingly available and more cost effective to incorporate into devices, many COTS devices analog subcomponents are being replaced with digital devices that offer more options, reduce subcomponent part counts, and provide increased configurations at a reduced cost to the manufacturer. Because the device function remains the same, the product literature and part number for the device may not be revised to reflect this change. If a digital subcomponent is not identified, then its digital/software quality would not be assessed, and the component (i.e., COTS device) may have new failure mechanisms and modes that were not considered [7]. This condition may be referred to as COTS with undeclared content

[57].

If it is unknown if a replacement component has digital content, replacing an analog component may result in more than a minimal increase in the frequency of occurrence of an accident or the likelihood of a malfunction. The undeclared digital content may also introduce new failure modes that should be evaluated during the dedication process. The new failure modes may increase the consequences of a malfunction or failure or create the possibility for an accident type different than any previously evaluated.

4-4

The 18 types of components with EDDs identified earlier may contain digital content and could be the types of items with digital content with the end user being unaware.

One of the key issues identified in RIS 2016-05 related to the use of EDDs is that licensees include adequate procurement controls to include the identification of EDDs in procured equipment [1].

A licensees 10 CFR 50.59 process should recognize any added digital content, and if necessary, a license amendment request (LAR) should be submitted per 10 CFR 50.90. The unique configuration of each plant, and each application within each plant, makes it imperative that each licensee analyze whether the EDDs can be installed under 10 CFR 50.59. However, if the device contains undeclared digital content it is unlikely that the 10 CFRR 50.59 process would properly evaluate the failure modes of the device or its impact on system reliability and thus plant safety.

Those options that could introduce replacement parts that do not meet the original design specifications include aftermarket parts, special manufacturing, repair/build, equivalency, reverse engineering, or design change. (Replacement parts from existing stock and the surplus market should meet existing requirements.)

Undeclared digital content may result from design changes made by the manufacturer that are not communicated to the end user via notification, markings, or other indications that the device has been changed to incorporate digital content. Left undetected, undeclared digital content could find its way into, and become a de facto change to, the plants licensing basis.

EPRI uses the term undeclared digital content [57] to describe digital content that is supplied as part of a CGI without the recipients knowledge and identifies three means for identifying digital content:

1. Supplier literature (type certification, microprocessor, ASIC, FPGA, or CPLD, software version number, configurable, communication capabilities, connection ports, RCC Class in the French standard RCC-E, or Conformit Europenne [CE] marking, ISASecure Embedded Device Security Assurance, or IEC certification)

2. External indications (a picture or visual inspection of the item may indicate digital content or a software version number, or a hexadecimal data scheme may be included on the label)

3. Internal indications (a picture or visual inspection of the item showing a printed circuit board, a chip with a sticker indicating a software version number)

Because disassembling the EDD for an internal visual inspection could break seals or damage the internals, this approach should be treated as a destructive evaluation.

Other ways to identify digital content are as follows:

1. Contact the vendor / OEM

2. Include a requirement stipulating that the vendor inform the licensee of digital content, its form, pedigree, etc., in the purchase order. This would also serve as an aid for inspectors 4-5

If one is unsure on the possibility of undeclared digital component within a device, RIS 2016-05

[1], Curtiss Wright [58] and EPRI 3002008010 [57] provide guidance on identifying and assessing undeclared digital content.

4.2.1 Examples of Undeclared Digital Content As noted in Information Notice (IN) 2014-11 [59], NRC inspections identified examples in which previous qualification testing and analysis was improperly applied, as similarity between the previously tested and the currently supplied components was not established. This is of concern for CGIs, as changes made by a commercial OEM could impact the components qualification and dedication and could go undetected. Inadequate implementation of the CGD process might result in CGIs not being properly qualified to perform their safety functions. Particular attention to this potential concern is necessary when an item will be qualified or dedicated by an entity other than the OEM, and potential changes to the component design might impact that process. Therefore, care must be taken to ensure that replacement components are qualified and dedicated to perform their safety functions prior to installation in a nuclear power plant.

Examples of undeclared digital content are provided below.

4.2.1.1 Allen Bradley 700-RTC Relay This is an example where the digital content is not externally visible, it was used extensively in the industry, and its failures were reported but not recognized.

In mid-2009, Texas Instruments replaced the solid state integrated circuit logic chip (i.e., old style 16 pin Motorola timing IC chip) with a complex programmable logic device (CPLD) in the Allen Bradley 700-RTC relay. This was a rolling change, with no specific manufacturing date to help distinguish between the old and new configurations [60]. Upon incorporation of the design change, Allen Bradley did not change the part number of the relay, did not issue any product update/technical service bulletin noting the change, and did not update or indicate in the 700-RTC relay technical literature that a digital CPLD device had been incorporated into the product design. Thus, the relay replaced a solid-state device with a programmable CPLD with the relay having the same make, model number, form, fit, and function. The CGD of the modified relays did not identify or address the new design or the failure mechanisms associated with the design change [61]. The change is not visible externally because the timer circuit board containing the CPLD is enclosed within the relay body, requiring disassembly to see it.

After replacing a governor and voltage regulator on an emergency diesel generator (EDG-3) at Brunswick 2 in March 2015 (6 years after the design change), the output breaker failed to remain closed during post-maintenance testing [62]. It was determined that the Allen-Bradley Timing Relay Model 700-RTC in the breaker control logic was susceptible to an inductive kick produced by the downstream relay when it deenergized. During subsequent post-maintenance testing on EDG-4 after replacing the same type relay, its output breaker attempted to close four times before finally closing. The EDG-3 relays passed a post-event site acceptance test (SAT); however, it was determined that a recorder across the relay acted as a suppression device that prevented inductive kick, which was the cause of the relay chattering and then failing. All 9 Allen-Bradley 700-RTC relays were subsequently bench tested, and all chattered.

Duke Energy reported the digital content in the Allen-Bradley 700-RTC relay per 10 CFR 21 [55].

Brunswick Steam Electric Plant (BSEP) did not appear in the affected plants list because the relays had been obtained as commercial grade and were later dedicated for safety-related use.

4-6

Therefore, industry operating experience published via the 10 CFR 21 process was not recognized as applicable to BSEP. Brunswick had a protocol in place to perform sample inspection of incoming electrical CGD candidates for potential unauthorized digital devices [63].

This protocol applied to components likely to contain a digital device, such as transmitters, relays, timers, transducers, indicators and similar products with more complex circuitry. This process should have identified the Allen Bradley relay as having digital content [62].

In its evaluation of the cause of the event, Duke Energy indicated that the procedure for purchasing engineering products did not contain any guidance or requirement for the examination of dedicated high-risk items that may be susceptible to a manufacturer introducing a digital device such as a CPLD in the components circuitry [62]. Thus, its CGD process did not recognize the modification of the relay.

AZZ/Nuclear Logistics Inc. (AZZ/NLI) was the supplier of the 700-RTC relays to Brunswick 2 and performed its own inspection of the internals of the timing relay in May 2015 [64]. AZZ/NLI determined that the timing relays contain a CPLD that meets the definition of a digital device under the guidance of EPRI and NEI [18]. AZZ/NLI submitted a 10 CFR 21 report indicating that 130 relays were supplied to 11 U.S. licensees since 2009. Shortly thereafter, Nutherm International, Inc. and United Controls International (UCI) submitted 10 CFR 21 reports regarding the Allen Bradley 700-RTC relays in June 2015 and July 2015, respectively. UCI indicated that four relays were sent to one plant [65], and Nutherm indicated that relays were sent to two plants

[60]. Nutherm did not indicate the number of relays. A total of 5 dedication facilities dedicated nearly 700 of these 700-RTC relays that were sent to 12 different licensees that were used in safety-related applications [49].

Testing confirmed that the old-style relaysthe ones with the 16-pin Motorola chipdid not experience chatter and worked properly every time [49]. Testing also confirmed that those relays with the CPLD chattered based on dc inductive kick that was produced by downstream relays de-energizing. An inductive kick occurred when the coil de-energized, and the magnetic field collapsed, generating a voltage spike of about 3,200-3,500 volts. That voltage spike was then transmitted back upstream to the relay, which basically kept resetting the timer. The breaker would reclose, and the process would start again.

4.2.1.2 Reactor Trip Breakers This is an example of where digital content was not originally recognized.

Three-Mile Island (TMI)-1 requested a change to replace the reactor trip breakers (RTBs) in connection with the replacement of the existing control rod drive control system (CRDCS) with a digital CRDCS [66]. The licensees original submittal dated September 29, 2008 states, [t]he replacement of the RTBs, although included in the overall modification, is not a digital upgrade.

However, the licensee's May 6, 2009, submittal informed the NRC staff that, subsequent to the September 29, 2008, submittal, NLI notified the licensee that the RTBs contained microcontrollers. In the May 6, 2009, submittal, the licensee identified the use of microcontrollers in the RTBs as a digital upgrade to a safety system. Although this was originally a device with undeclared digital content, the vendor recognized that the licensee was likely to be unaware of the change and notified them.

4-7

4.2.1.3 Smart Chart Recorder Although the smart chart recorders were recognized to contain digital content, the extent and added functionality was not recognized.

Sellafields overall experience with smart devices was that it was often very difficult to tell whether an instrument was dumb or smart [50]. Specifically, Sellafield found that manufacturers data sheets never specified if microprocessors were used, operation and maintenance manuals never included this level of detail on component parts, and visual examination often proved inconclusive.

However, Sellafields experience shows that even when you recognize that the device has a digital component unnecessary software may be added that inhibits proper operation.

Several paperless chart recorders were installed in a low-SIL application at Sellafield (UK) [50].

Once installed, the recorders started to exhibit faults, mostly going to sleep or requiring constant rebooting. Recorders were swapped with identical spares, returned to the manufacturer, and reconfigured over a period of about 18 months, with no real improvement in reliability. It was discovered that the chart recorders contained a game called Cave Fly that was based on the film Hunt for Red October, and the game could not be deleted from the firmware; it could only locked-out from the operators. After the game was locked out, reliability seemed to improve, but faults were never completely eliminated. Sellafield decided to change the recorders for another make.

4.3 Software Tools Early software development methods relied on human inspection and testing for V&V; however, with increased automation (i.e., tool use) there is a comparable reduction in human involvement.

That is, there is a tendency to rely on the software tools more. Many of the software tools in use have a large user base that provides feedback, are well supported, and have been in use long enough to be well tested. However, undetected faults in the automated tools or tool-assisted engineering activities may pose serious risks to nuclear safety. In either case, having a good process and consistent method to assess the safety of the software development is important to all stakeholders in the nuclear industry from equipment vendors, utility licensees, and government regulatory organizations. The guidance and use of software tools is addressed further in Appendix C. Very generally, there are two concerns with software tools: (1) they should be evaluated to be appropriate for their manner of use (explained further below), and (2) they should be evaluated to ensure they are appropriate for the secure development and operational environment (SDOE).

IEEE Std. 603-1991 also does not specifically discuss software tools; however, IEEE Std. 7-4.3.2 specifies additional computer-specific requirements (incorporating hardware, software, firmware, and interfaces) to supplement the criteria and requirements of IEEE Std. 603. IEEE Std. 7-4.3.2 is used in conjunction with IEEE Std. 603 to assure the completeness of the safety system design when a computer is to be used as a component of a safety system.

A major change implemented in the 2016 revision of IEEE Std. 7-4.3.2 [26] (currently not endorsed by NRC) provides more specific criteria on the use of software tools used for digital devices and development of hardware, software, firmware, and programmable logic. IEEE Std.

7-4.3.2-2016 defines software tools as a sequence of instructions and commands used in the design, development, testing, review, analysis, or maintenance of a programmable digital device or its documentation. IEEE Std. 7-4.3.2-2016 requires that software be developed, modified, or accepted in accordance with a software QA plan and that the software QA plan shall address the software tools used for system development and maintenance.

4-8

RGs 1.152 and 1.168-1.173 provide some guidance on software used in safety systems, primarily through the endorsement of various IEEE standards. RG 1.152 endorses IEEE Std. 7-4.3.2-2003 (which is addressed below) and includes a specific regulatory position on establishing and maintaining a secure operational environment and a secure development environment for system software. Because this regulatory position does not specifically address software tools, the software tools used to develop the software, as well as the development environment of the software tool, do not need to have been secure to later develop safety-related software if it is determined defects not detected by the software tool will be detected by V&V activities. However while in use on safety-related software the tools would need to be within the secure development environment. IEEE Std. 7-4.3.2 2016 includes a clause that such software tools shall be incorporated into the secure development and operational environment and controlled under configuration management.

EPRI TR-1025243, endorsed by RG 1.231, provides guidance for using a CGD process to accept safety-related, commercial-grade design and analysis tools that are used in the design and analysis of safety-related plant SSCs. EPRI TR-1025243 guidance does not apply to all software tools used to support the design and development of safety-related software.

NRC Branch Technical Position (BTP) 7-18 states that EPRI TR-106439 and EPRI TR-107330 describe an acceptable process for qualifying commercial systems. NUREG/CR-6421 provides additional information on the characteristics of an acceptable process for qualifying existing software and discusses the use of engineering judgment and compensating factors for purchased PLC software. EPRI TR-106439 describes the generic functional and qualification requirements for a PLC. EPRI TR-107339 (not endorsed by the NRC) contains supplemental guidance for qualifying commercial digital equipment through tailoring the guidance in EPRI TR-106439 consistent with the importance of the digital equipment to safety. The primary focus of EPRI TR-107339 is on the differences in the technical evaluation and acceptance process required for digital, software-based equipment and systems. EPRI TR-107339 provides guidance for each of the phases of the CGI dedication processbeginning with project definition, defining detailed requirements, defining critical characteristics for acceptance, formulating an acceptance strategy, and verification of critical characteristics. Regarding the supplemental guidance of EPRI TR-107339, Information Systems Laboratories, Inc. (ISL) observes [67] that it is particularly relevant to commercial-grade software but not particularly relevant to software tools. In a review of software development tools, ISL notes that many software tools have a large user base that provides feedback, are well supported, and have been in use long enough to be well tested.

NRCs guidance in NUREG-0800 on the use of software tools [C.2] states that The software tool should be used in a manner such that defects not detected by the software tool will be detected by V&V activities. If, however, it cannot be proven that defects not detected by software tools or introduced by software tool will be detected by V&V activities, the software tools should be designed as Appendix B quality software itself, with all the attendant regulatory requirements for software developed under an Appendix B program.

This is further elaborated on as discussed in EPRI TR-106439 [54] (referenced in RG 1.173 and RG 1.206) which states that Because the output of the software tool as loaded into the PLC can be verified independently, and the tool is not connected to the PLC during operation in the plant (the PLC would be taken out of service during any re-configuration activity), the use of the tool is examined as part of dedicating the PLC but the tool itself does not require dedication.

4-9

The PLC, its hardware and the embedded operating software (firmware) do require dedication for the ESFAS application.

ISL surveyed standards, regulatory guidance, review/approval practices, and other industry practices concerning the use of software tools upon which the reliability of a digital safety-related system depends. Conclusions from ISL are given below:

• EPRIs CGD process is similar to the aerospace industrys safety litmus test [67]. Only safety-related items need to be dedicated. Determining the critical characteristics is similar to the identification and assignment of a tools confidence level in ISO 26262. The CGD acceptance process for EPRI is a combination of four alternative methods with similarities to methods from other industries.

• The CGD process can be applied to software tools, and many of the steps described in the dedication process specific to hardware or software dedication would be difficult to accomplish and must be adapted for software tools [67].

• The civil aviation industry software classification system is similar to the method used by the commercial nuclear power industry described in IEC 61508 and associated standards, as are the automotive industry practice described in ISO 26262, the high-speed railway industry practice described in BS EN 50128, and the method used in IEEE 1012-2004.

However, the civil aviation industry practice is based on a deterministic assessment of software-related errors and their impact on aircraft, crew, and system safety compared to the probabilistic risk-based methods of IEC 61508, ISO 26262, and BS EN 50128. These software classification methods are different from the guidance in RG 1.152 (Institute of Electrical and Electronics Engineers [IEEE] 1012-2004) that assigns the highest SIL to software executed in a commercial NPP [67].

• IEC standards lack consistency, do not include a comprehensive review and approval process, and do not contain a probabilistic risk-based process to design safety-related systems and may not be appropriate for commercial nuclear power safety-related software development since software failures 5 are impossible to quantify [67].

4F Other industries also struggle with the use of software tools.

Atomic Energy of Canada Limited (AECL) CE-1001-STD [251] specifies requirements and a minimum set of software engineering processes for safety-critical software development for Canadian-invented Deuterium-Uranium (CANDU) nuclear generating stations. AECL CE-1001-STD does not distinguish between different types of software tools, does not use software tool categories or classifications, and does not contain any specific software tool qualification requirements tailored to the type of tool.

NASA requires that the software tools used in developing software for safety-critical systems should be identified and the level of rigor associated with the verification, validation, and accreditation of software tools should be determined based on the tool functions and the safety classification of the systems in which the software will be used [70]. NASA also encourages the use of simulators or an in-circuit emulator (ICE) system for debugging in embedded systems; these tools allow the programmer or tester to find subtle problems more easily. However, the 5 See Appendix A for the IEC 61513 definition of the software failure term, which is used consistently used throughout this report.

4-10

guidebook does not discuss simulator or ICE system verification, validation, qualification, review, or approval practices.

Both the Federal Aviation Administration (FAA) and Radio Technical Commission for Aeronautics (RTCA) publish documents that address various aspects of verification, validation, certification, qualification, and use of software and software tools. The FAA requires that all software tools be identified, validated, and addressed within the software development activities and documentation. Software is classified based on how an error affects the software and system containing the software. The software classification defines the rigor necessary to demonstrate compliance with software development requirements. The primary method of tool qualification in accordance with RTCA DO-330 [71] is development, verification, and validation in accordance with a high-quality, well-organized software tool development life cycle process. Alternative tool qualification methods include using service history, exhaustive input testing, formal methods, and dissimilar tools. Unlike most other industries that superficially address COTS software tools, RTCA DO-330 provides a comprehensive qualification process for COTS tools that divides qualification responsibilities between the COTS developer and tool user. Unlike the aerospace industry, which classifies software tools separately from embedded system software, the civil aviation industry classifies software tools to the same level as the software developed with the tool.

ISO 26262 [72] is an international standard that is an automotive specific implementation of IEC 61508. ISO 26262 requires that a tool confidence level (TCL) be determined when (1) a software tool supports or enables the tailoring of activities and tasks of the safety life cycle and (2) the output of the software tool has not been examined or verified. This practice is consistent with the civil aviation industry as described in Radio Technical Commission for Aeronautics (RTCA) DO-178C; however, the ISO 26262 TCL process does not distinguish between software development tools and verification tools, and the TCL is based on a probabilistic assessment that a malfunction and its corresponding erroneous output will be prevented or detected. The TCL is used, along with the automotive safety integrity level (ASIL) to select an appropriate combination of four methods for qualifying software tools. The four qualification methods are: confidence from prior tool use, evaluation of the tool development process, tool validation, and tool development in accordance with a safety standard. Although ISO 26262 identifies four alternative software tool qualification methods, ISL concluded that they are not specific enough to ensure a consistent methodology within the automotive industry [67].

IEC 60880 and IEC 62138 identify types of software tools that require different levels of verification and assessment. IEC 60880 does not require tool qualification if the tool cannot introduce faults into the software: the tool output is always systematically verified, or tool faults are mitigated.

IAEA SSG-39 [16] requires software tools to be verified and assessed in a manner consistent with (1) tool reliability requirements, (2) the type of tool, (3) the potential for the tool to introduce fault or to fail to make the user aware of existing faults, and (4) the extent to which the tool may affect redundant elements of a system or diverse systems. Tools that can introduce faults or fail to detect faults need to be verified to a greater extent than tools less likely to introduce or detect faults; however, verification is not necessary if the tool output is systematically and independently verified.

Appendix C provides a more thorough discussion of software tools.

4-11

4.4 Credit for Other Certifications Many countries do not use the same CGD process as the NRC but still approve components for use in NPPs. This subsection provides some insight into how others approve components for use in safety applications.

In Canada, the justification process is specifically an activity for design suitability or qualification, as opposed to having a seperate commercial grade dedication process.

For the smart device justification in the UK [7]

there is generally limited reliance on certifications, especially at the higher safety classes. While the review of an independent qualified certification body can be used as evidence, its relevance depends on the scope of the certification and the availability of the supporting analyses. Often, the certifications are commissioned by a manufacturer and hence need a level of independent review (including of the supporting documents and analyses). Examples of certifications that can be credited as evidence as part of the justifications in the UK are related to quality assurance (e.g. ISO 9001) and hardware certification (e.g. environmental qualification).

Similarly, a proven in use argument is generally a weak justification for a smart device. In fact, the relevance of the operational experience significantly depends on the quality of data collection (e.g. including the version number, the number of demands, the failure mode) and the contractual arrangement for defect notifications. Operational experience is also limited in identifying systematic failures and hence needs to be complemented, for example with additional assessment of the design process and further analyses.

While the review of an independent qualified certification body can be used as evidence, its relevance depends on the scope of the certification and the availability of the supporting analyses.

Often, the certifications are commissioned by a manufacturer and hence need a level of independent review; this review must include the assessment of supporting documents and analyses. Examples of certifications that can be credited as evidence as part of the justifications in the UK are related to QA (e.g. ISO 9001) and hardware certification (e.g. environmental qualification).

An alternative type of certification is that performed by Adelard. This method is accepted by the United Kingdom. The information needed from the device vendor to perform validation needs to be easily accessible by the third-party dedicator. Adelard, through NDAs, has obtained information from vendors but this is a long, difficult task.

Guidance on the proper dedication of CGIs to be used in safety-related applications have received industry-wide acceptance. Guidance is provided in documents such as EPRI 3002002982 [53]

(an update of EPRI NP-5652 [73]; EPRI TR-102260 [74] provides supplemental guidance to EPRI NP-5652).

Similarly, industry outside the nuclear industry have certification requirements and methods for certifying products for use in different environments. Companies and testing facilities are approved for certification of these products.

4-12

The documents identified in Table 4-1 address the topic of suitability evaluations of COTS equipment. Common terms to be familiar with are CGD, proven in use, and prior use.

Table 4-1 Certification of Components in the U.S. Nuclear Industry and Other Industries Non-Process International (IEC) U.S. Department of Industry U.S. (IEEE) Nuclear Industry Nuclear Defense Specific

• IEC

• ISA

• EPRI NP-5652 R1

• IEC 61513 General

• MIL-STD-882E 61508 84.00.01 Guidance for CGD Requirements [79] Standard Practice Part 2 Part 1 [73]

• IEC 60987 Computer for System Safety

[75] [76]

• EPRI TR-106439 Based Hardware [80] [83]

Guidance for CGD of

• IEC 60880 Category

• Joint Software Digital Equipment [54] A Software aspects Systems Safety

• EPRI TR-107339 [81] Engineering Guidance for CGD of

• IEC 62138 Category Handbook [84]

Digital Equipment [77] B or C Software

• EPRI 1011710 aspects [82]

Handbook for Critical

• IEC 62671 Selection Digital Reviews [78] of Industrial Digital

• IEEE 7-4.3.2-2003 Devices of Limited Criteria for Computers Functionality [17]

in Safety Systems

[263]

Because of extensive reviews, design information made available, and testing, completion of the Adelard/Emphasis evaluation approved for use by ONR in the UK appears to be comparable to a CGD. This may be an alternative path for dedication and could provide credit for vendors that successfully complete this process.

Although there are differences in what constitutes certification, other industries recognize its need and its use is prevelant. The commercial industry has certification processes for safety systems and equipment. Examples of components certified to IEC 61508, UL 1998, and others include

[85]:

• Rosemount Pressure and temperature transmitters

• Siemens AS-I limit switches, position sensors, light curtains, logic

• Green Hills RTOS

• Phoenix Contract relays

• Yokogawa ProSafe PLC, EJX pressure transmitters

• ABB Metcon PT

• Samson 3730 positioner

• Triconix Trident PLC

• Emerson Delta V logic solver, FieldVue valve controller

• Maxcon air operated valves

• ADS Tech single board computer

• Wind River RTOS 4-13

• Honeywell SafetyManager PLC

• Allen-Bradley GuardPLC

• Schmersal limit switches

• Ominfles annunciators Allowing credit for components that have been approved by other countries or dedicators/certifiers outside the U.S. nuclear power industry may be an option to explore given a thorough review of the dedication/certification process through inspections and audits. In addition, leveraging the experience of those commercial products with a successful operating history outside the nuclear industry that may be useful in helping justify these units for use in nuclear facilities although care must be taken when using operating history as a basis for acceptability.

The World Nuclear Association (www.world-nuclear.org), in 2014 planned to have pilot audits with suppliers to develop a common consistent audit checklist and guidance linked to National Quality Standard Association (NQSA) document NSQ-100 [37]. The status of this effort is unknown to the authors.

4.5 Cyber Security Increased communication capabilities and wireless technology would advance the capabilities of the EDD significantly beyond its analog counterparts. Cybersecurity and issues with electromagnetic propagation (electromagnetic and radio frequency interference, fading, interference abatement) are the major concerns with implementation of digital technologies.

Wireless technologies, which are currently not in use in NPPs in safety-related applications, create additional cyber security concerns. Because of their availability, advantages, and extensive usage in process industries, wireless technologies will migrate into the nuclear arena in the near future.

10 CFR 73.54 [86] requires licensees to protect their critical digital assets (CDAs). NRCs RG 5.71 provides guidance for meeting 10 CFR 73.54. NEI 08-09 [87] (Addendum 3 of Revision 6 was endorsed by NRC September 8, 2017) is an alternative to RG 5.71 for meeting 10 CFR 73.54.

To avoid confusion between the coverage of the provisions of 10 CFR 73.54 and RG 1.152 with respect to cyber security, RG 1.152 defines the conditions for controlling a secure development environment and a secure operational environment. Cyber security issues are relevant throughout the entire supply chain, which includes the development and operational environments. EPRI 3002012753 [88] introduces a common supply chain model that was created with segments and transitions for describing cyber security across the supply chain that is risk-informed and that allows for a graded approach based on procurement type. It is recognized that the supply chain represents a significant cyber-attack pathway for digital assets and systems.

NEI 10-04 [89] provides guidance on the identification of digital computer and communication systems and networks subject to the requirements of 10 CFR 73.54. NEI 13-10 [90] provides guidance for addressing technical cyber security controls for CDAs. NEI 13-10 was developed to streamline the process for addressing the application of cyber security controls to the large number of CDAs identified by licensees when conducting the analysis required by 10 CFR 73.54(b). The goal is to minimize the burden on licensees for complying with their NRC-approved cyber security plan while continuing to ensure that the adequate protection criteria of 10 CFR 73.54 are met. Insights from NEI 13-10 may be helpful when assessing the risk of EDDs throughout the plant from nuclear and non-nuclear vendors.

4-14

Although it is written for the protection of critical infrastructure protection (CIP) programs [91],

IEEE Std. 1686-2013 [92] defines functions and features to be provided in intelligent electronic devices (IEDs). Electronic access to IEDs (e.g., EDDs) can be locally through a control panel, locally through a communication/diagnostic port with a test set or personal computer, or remotely through communications media. This standard can help users identify which features a system should have in order to raise the security level of an IED. Access control, an audit trail, supervisory control and monitoring, and the use of cyber security features such as encryption and QA of the firmware are cyber security control features addressed in the standard.

Pacific Gas and Electric (PG&E) indicated that they have two main expectations when dealing with vendors from a cyber security perspective [93]:

1. Expectations for the vendor: This includes the requirement that the specified product is free of defects, malware, bugs, and unauthorized components and that the product is protected while in transit to PG&E.

2. Expectations of the product: PG&E expects that the product has the necessary features to enable PG&E to comply with the provisions of NEI 08-09. This includes system hardening and access control.

Because the use of EDDs at NPPs will likely increase, and more vendors of EDDs will not be from inside the nuclear industry (see the Subsection on ET in EDDs), cyber security vulnerabilities and concerns will be greater.

4.6 Common-Cause Failures (CCFs)

Understanding the likelihood of CCFs of EDDs is a real concern with respect to the ability to properly assess plant risk and protect public health and safety. These CCFs can be related to software or hardware. Recent events discussed in Subsection 4.6.6 support both of these concerns. It should be noted that this is an area of significant ongoing work and is undergoing changes concurrently with this work. This brief treatment is intended to provide some high level background and a focus on how it may relate to EDDs specifically.

The potential for CCFs exists because of common components, identical hardware, identical software, the same requirements, and the same operating environment. For cases in which such commonalities are identified, justification should be provided to demonstrate that the potential for CCF is low. Hardware and software CCFs may cause identical components to fail at the same time. If CCF vulnerabilities may be of concern as a contributor to risk, a simple estimator for its contribution would be to use the -factor model.6 The -factor model is the most commonly used CCF model and is recommended by IEC 61508-6. The -factor model is simple and easy to understand and use because it has only the one extra parameter (). Typical implementation of the beta factor method calculates the CCF failure rate (CCF) for a component as the -factor times the total component failure rate (T). That is, CCF = T.

This procedure for estimating , as described in IEC 61508-6, is based on a set of questions and a scoring system of the answers to these questions. The IEC 61508-6 checklist includes 37 6 The factor method is an approximation method used for the quantitative evaluation of CCFs. In this method, the likelihood of the CCF is evaluated in relation to the random failure rate for the component. A factor is estimated such that % of the failure rate is attributed to the CCF and (1- )% to the random failure rate of the component. Ideally, this factor is obtained through historical data by determining the percentage of all the component failures in which multiple similar components failed.

4-15

questions in eight groups. A slightly different approach to determine the -factor is suggested in IEC 62601 for high-demand field machinery. The IEC 62061 checklist only has 14 questions and is less complicated than the IEC 61508-6 checklist.

The values used for in the -factor model can range from nearly zero to up to 25%, depending upon the device and the particular common cause issues under consideration [196]. For components with little to no data available, their failure probabilities or failure rates should be low and they are not likely to be significant contributors to core damage frequency, and a conservative generic -factor of 0.1 is likely to be adequate [197]. This provides an estimate of the CCF as CCF = 0.1T.

Software faiures are another potential cause of a CCF, commonly referred to as a software CCF (SCCF). A software design defect in an EDD can occur in the operating system (OS) (if it has one) or application system software that can cause one or more controllers to simultaneously generate erroneous outputs, or it may cause the outputs to freeze in their current state.

• The OS alone does not perform any application-specific logic that would be designed for influencing or controlled any SSC.

• An OS can be a commercially available, multi-tasking, real-time package available from a third party, or it can be a single task, once-through firmware program designed by the equipment vendor and embedded in their digital product.

• OS and application software often have different characteristics under the control of different entities.

The scope of software CCFs considered in diversity and defense-in-depth analyses include those faults and failures that could impair an automatic safety actuation or could impact the main control room instrumentation required to support operator manual action. For a software CCF to occur simultaneously in multiple EDDs, two conditions must be present:

1. An identical, latent defect must exist in the software (firmware) of multiple EDDs.

2. A triggering condition must occur almost simultaneously in multiple EDDs that exposes the latent defect.

The possibility of simultaneous failure of multiple redundant digital components exists if all of the components are executing the same program with essentially the same I/O and are more-or-less synchronous (i.e., software CCF). For a software CCF to occur in an EDD, a latent defect in the OS or the application software must exist, or the software is not suitable for a particular application.

Because of independent sensors, OS, application software, plant loop, etc., the likelihood of a software CCF occurring simultaneously at numerous EDDs because of these types of failures is likely low. This does not mean that software CCFs cannot occur, it is that the relative rankings from these failure modes are lower because of how the EDDs operate and receive sensor data.

Measures to reduce the likelihood and consequences of a CCF in an EDD include diversity, defense in depth, and no communication with other devices. The use of the EDD also needs to be considered. For example, considering the EDD as a component similar to a pump or valve, CCFs do exist, but plants may not have redundant and diverse components such as valves or 4-16

pumps in the same loop. If the EDD is an extension of the component (e.g., valve or pump), then its failure is bounded by the failure of the component to which it is attached.

Applying diversity to EDDs could be addressed through the use of EDDs from different vendors on different flow loops.

Another defensive measure to minimize the likelihood of a CCF (both in hardware and software) is through testing.

Communication independence, which is a defensive measure for a system, is a given for an EDD when it does not share data or resources.

Operating experience can be used to inform the design decisions and any review. This is a very important aspect of operating experience.

Thus, at the device level, with each device having its own sensor and operating on its own time scale, the risk of a CCF is reduced unless caused by external events, misuse of component, faulty requirements, or a software-related CCF similar to the chart recorder at Sellafield (extraneous code). Diversity on the highly redundant subsystem level may introduce maintenance problems, spare parts issues, etc. Thus, diversity at the device level may not be a practical solution.

EDDs in components in different channels/flow loops with possible software triggers may create CCF concerns. However, placing valve controllers for different valves on a rack could cause a CCF because of their physical location. Thus, while one problem may be solved the solution could create other problems.

How the NRC addresses CCFs and software CCFs is addressed below. How other agencies and IEC address CCFs is also discussed with the purpose of providing examples. Commonalities between agencies for reducing the likelihood and consequences of CCFs are the use of defense-in-depth, testing, QA, and fault tolerance. The military, however, does not address CCF per se; rather, it evaluates the consequences (hazards) of a failure. The likelihood of failure is reduced because the software system and environment are operated and tested either on a set frequency or continually.

For an EDD, the most likely contributors to CCF have been environmental effects such as EMI, DC inductive kick, temperature, seismic effects, fire, flooding, and errors in requirements or improper use of the component (i.e., use outside its critical characteristics). Likely failure modes of I&C systems are discussed below in the subsection on failure modes.

4.6.1 NRC NRC uses the defense-in-depth approach to the design and operation of nuclear facilities in a manner that prevents and mitigates accidents that release radiation or hazardous materials. The key is to create multiple independent and redundant layers of defense to compensate for potential human and mechanical failures so that no single layer, no matter how robust, is relied upon exclusively. The defense-in-depth approach includes the use of access controls, physical barriers, redundant and diverse key safety functions, and emergency response measures.

4-17

Standard Review Plan (SRP) BTP 7-19, Rev. 7, Chapter 7 of NUREG-0800, and Item II.Q of SECY-93-087 note that hardware design errors, software design errors, and software programming errors are all credible sources of CCF for digital safety systems.

BTP 7-19, Revision 7, provides guidance to the NRC staff on evaluating the defense-in-depth and diversity of a DI&C system. However, similar to a system, the EDDs testability could be used to eliminate consideration of CCF. In fact, compared to a system, the EDD is more likely to be simple enough that every possible combination of inputs and every possible sequence of device state can be tested, and all outputs can be verified for every case (i.e., 100% tested).

RIS 2016-05 [1] identifies NRCs regulatory requirements to address potential vulnerabilities to CCFs for safety-related equipment with EDDs. Supplement 1 to RIS 2002-22 [223] offers potential relief through qualitative assessment of the likelihood of failure. The RIS addresses two potential outcomes of the qualitative assessment:

1. Failure likelihood is sufficiently low

2. Failure likelihood is not sufficiently low 4.6.2 IEC IEC 61513 covers the system aspects of I&C systems important to safety at NPPs, including computer-based systems. IEC 61513 states that combinations of signal and functional diversities are cited as particularly effective methods to reduce risk of CCF due to errors in the requirements specifications or in the specification and implementation of application software [79].

In IEC 61513 [79], the design goal for defending against CCF is specified as providing measures against the occurrence of a CCF within I&C systems implementing different lines of defence against the same PIE [postulated initiating event]. The identified measures include the following:

• design provisions promoting tolerance of hazardous plant events (e.g., external influences and internal hazards),

• design provisions resulting in insensitivity to plant demand design (e.g., decoupling execution from plant status to avoid common triggering conditions),

• design provision to minimize the use of common elements or support systems among lines of defense,

• quality assurance and fault tolerance to minimize the potential impact of systematic faults,

• strategic design decisions to manage complexity, and

• design differences through application of diverse features.

For each design measure, requirements and recommendations are presented to guide the usage of these defensive approaches.

These measures are for I&C systems protecting against postulated IEs. The measures for tolerance can be applied to EDDs, but their application must be focused at the component level and not the system/plant level. For example, external influences such as EMI can be a significant CCF initiator to an EDD.

4-18

4.6.3 CSA N290.14-15 CSA N290.14-15 [94] is the standard used by Canadian licensed utilities to qualify commercial-grade software for use in safety-related applications.

For predeveloped software, CSA recognizes IEC SIL and other certifications. Testing can be used to support partial compliance with applicable industry standards. Testing can also be used for proof of acceptability for low complexity software. This appears to be similar to the 100%

testing option for addressing CCF identified by NRC in BTP 7-19 revision 7.

4.6.4 DOE The use of defense-in-depth design principles provides a means for addressing CCF vulnerabilities. Defense-in-depth is used to ensrue that no single function is relied upon. A digital CCF of all layers of defense would require the same digital fault to be present and concurrently actuated in each layer. A defense-in-depth analysis may reveal direct or indirect impacts on interfaces with existing plant SSCs. Defense-in-depth analysis requires assessments of the ability to prevent (reduce susceptibility) and to mitigate (cope with) a CCF.

DOE uses a much more detailed definition (9 aspects) for providing layers of protection and defense-in-depth, as shown below:

a) choose an appropriate site; b) minimize the quantity of material-at-risk; c) apply conservative design margins; d) apply quality assurance; e) use successive/multiple physical barriers for protection against radioactive releases f) use multiple means to ensure that safety functions are met by

1. controlling processes,

2. maintaining processes in safe status,

3. providing preventive and/or mitigative controls for accidents with the potential for radiological releases, and

4. providing means for monitoring facility conditions to support recovery from upset or accident conditions; g) use equipment in combination with administrative controls that

1. restrict deviation from normal operations,

2. monitor facility conditions during and after an event, and

3. provide for response to accidents to achieve a safe condition; 4-19

h) provide the means to monitor accident releases as required for emergency response; and i) establish emergency plans for minimizing the effects of an accident The DOE NEET Advanced Sensors and Instrumentation (ASI) program is evaluating how to extend a diversity and defense-in-depth (D3) analysis method to treat EDDs. This approach involves [48] the following actions:

• Evaluate equipment to ensure awareness of the presence of an EDD.

• Determine the role and safety relevance of the digital device in the performance of safety-related functions.

• Investigate whether the implementation of relevant functions in the EDD meets either of the two criteriainternal diversity or testabilityfor which the CCF is considered to be resolved.

• Evaluate the performance characteristics of the equipment to determine the nature of its failure response (e.g., whether failure is detectable and whether adequate time is available to respond).

• Assess whether the component-level CCF has an unacceptable system level or safety function impact (e.g., performance of a best-estimate analysis).

• If necessary, determine the availability of diverse alternatives to mitigate the impact of CCF.

By injecting faults into the software, the DOE NEET program may be able to identify software faults, and possibly software CCFs. Its findings could support this assessment.

4.6.5 Military The military does not address CCF per se; rather, it evaluates the consequences (hazards) of a failure. The likelihood of failure is reduced because the software system and environment are operated and tested either on a set frequency or continually.

DoD practices for software-based system development are given in the Software System Safety Handbook [95]. Testing is relied on to provide evidence of suitability; however, there is very limited ability to test COTS software to provide evidence that the software cannot influence system hazards. Testing in a laboratory cannot duplicate every nuance of the operational environment; nor can it duplicate every possible combination of events. During testing, COTS software is treated as a black box, and the tests measure the response of the software to input stimulus under presumably known system states.

DoD recognizes that hazards identified through black box testing are sometimes happenstance and difficult to duplicate [95]. Without detailed knowledge of the software design, the system safety and test groups can only develop limited testing to verify the safety and fail-safe features of the system. However, the DoD does perform supplemental environmental testing and additional mitigating strategies that could address CCFs.

4-20

4.6.6 Examples of CCFs If the failure rates are comparable for analog and digital devices, then the difference between the dependability of a redundant configuration and its counterpart using conventional technology would be driven by its susceptibility to a CCF. The question then reduces to, Are smart sensors

[EDDs] more prone to CCFs than conventional devices? [121]

Safety-related equipment with EDDs must satisfy regulatory requirements consistent with the safety significance of the equipment. Quality and reliability considerations must include potential vulnerabilities to CCFs, including software CCFs. However, 38 out of approximately 100 operating plants have reported potential and actual common-mode failures in safety-related disigal systems [96]. Some common-mode failures affected a single plant, while others affected several plants that were using the same digital system.

Operating history shows that hardware and software CCFs can occur. The examples provided are for I&C systems and not necessarily from the operating history of EDDs.

4.6.6.1 Hardware CCFs The selection of hardware-related CCF events are discussed below. Experiences at Brunswick 2, Shearon Harris, Beaver Valley Unit 2, Waterford 3, and Browns Ferry 3 reinforce regulatory concerns regarding the quality and reliability of safety-related equipment with EDDs and also highlight the use of components in a manner not intended.

The examples were chosen to demonstrate the variety of causes or types of CCFs.

Brunswick 2 The Allen-Bradley 700-RTC breakers having undeclared digital content is discussed in the examples of undeclared digital content. Its susceptibility to CCFs is discussed here.

The introduction of the CPLD made the device susceptible to DC-inductive kick produced by the downstream relay when it de-energized. Although this was not a new failure mode for digital systems, it was a new failure mode for the 700-RTC relay.

This is a potential CCF of all four EDGs, because the Allen-Bradley relays were installed in the breaker control logic of all 4 EDGs. Although one of the primary concerns of EDDs failing is the simultaneous CCF of the embedded software or firmware, the introduction of the CPLD made the device susceptible to DC-inductive kick produced by the downstream relay when it de-energized

[97].

As part of this effort, ORNL searched the 10 CFR 21 event reports for the terms EDD, embedded, Allen-Bradley, and CPLD to identify reports related to CPLDs replacing solid state or analog parts within a component. No similar events were identified using these terms.

However, searches of the 10 CFR 21 event reports related to inductive kick identified this failure mechanism also occurred at Shearon Harris, Beaver Valley 2, and Waterford 3.

Both the undeclared digital content and the dc inductive kick failure mechanism are applicable to EDDs.

4-21

Shearon Harris Both emergency load sequencers at Shearon Harris 1 were subject to a common mode failure because of improper application of the relays not accounting for dc inductive load rating [98]. The deficiency in the sequencer circuit design that existed since plant startup in 1986, failed to properly account for dc inductive loading of contacts.

There are two failure mechanisms relevant to DC inductive loading of contacts to be considered in evaluating sequencer performance. The first involves the Potter-Brumfield relays in which the tabs of the contact melt into the cam, and the second involves the microswitch contact mounted on the Agastat relays.

The contacts of the Potter-Brumfield relays do not have a specified dc rating, and testing was not performed prior to their application in the design of the sequencer by Ebasco. Previous failures of these contacts has occurred during sequencer testing, and during the special testing conducted on May 4, 1990.

The Agastat relay microswitches were installed in an inductive application where the DC current was 0.9 amps, while the contact rating was only 0.5 amps resistive. The sequencer circuit design failed to consider these ratings in the actual application.

Beaver Valley 2 In 1993, during testing of an EDG load sequencer, the load sequencer of Train A failed to automatically load safety-related equipment onto the emergency bus. After the load sequencer for Train A failed, two suspect relays were replaced, and the surveillance test was successfully repeated. Two days later, an EDG load sequencer of Train B failed to automatically load safety-related equipment onto the emergency bus [99].

The cause of both load sequencers failing was a CCF caused by voltage spiking (e.g. inductive kicks) by the auxiliary relays.

A review of these events indicated that the microprocessor-based timer/relay failed as a result of the voltage spikes that were generated by the auxiliary relay coil controlled by the timer/relay. The voltage spikes, also referred to as inductive kicks, were generated when the timer/relay time-delay contacts interrupted the current to the auxiliary relay coil. These spikes then arced across the timer/relay contacts. This arcing, in conjunction with the inductance and wiring capacitance, generated fast electrical noise transients called arc showering (electromagnetic interference). The peak voltage noise transient changes as a function of the breakdown voltage of the contact gap, which changes as the contacts move apart and/or bounce. These noise transients caused the microprocessor in the timer/relay to fail. The failure of the microprocessor-based timer/relay caused the time-delay contacts to reclose shortly after they had properly opened as part of the load sequencer operation. Closing the time-delay contact locked out (deenergized) the load sequencer master relay and prevented the load sequencer from operating. To correct the identified problem, the licensee installed diodes across the auxiliary relay coils to suppress the voltage spike that had caused the microprocessor-based timer/relay failure. This modification was confirmed to correct the problem through successful testing of the EDG load sequencer.

It was determined that the design control for the selection and review for suitability of the microprocessor timer/relays for this application was not adequate. The modification design data did not identify the potential for voltage spiking by the auxiliary relays and translate that potential 4-22

into electromagnetic interference requirements for the equipment purchase specification and the dedication testing specification. As a result of inadequate design control, a CCF mechanism was introduced into the diesel generator load sequencers.

This event highlights the need to ensure proper design control activities when replacing discrete electrical or electromechanical devices with digital microprocessor-based electronic devices.

Specifically, the event shows that safety-significant, common-mode failures can occur when the design review does not ensure that the digital, microprocessor-based replacement equipment is compatible for the specific application and service environment.

Waterford 3 At Waterford 3, an inadequate design change rendered the fast bus transfer system inoperable.

Modifications to the fast bus transfer circuitry in May 2017 did not properly account for the increased susceptibility to DC coil inductive kick of electronic devices and resulted in the licensees inability to maintain offsite power to the 6.9 kilo-volt (kV) and 4.16 kV electrical buses following a trip of the main generator [100].

The direct cause of the failure of the fast dead bus transfer was the Struthers Dunn (S-D) 237 Series Direct Current (DC) Time Delay on Dropout (TDDO) relays installed in the fast dead bus transfer circuitry instantaneously timed out when they were exposed to DC coil inductive kick, which prevented automatic transfer of the safety and non-safety electrical busses from the Unit Auxiliary Transformers to the Startup Transformers.

The Root Cause of this event was that the design change procedures in effect during the development of the 1997 and 2017 modifications to the fast dead bus transfer circuitry did not include guidance that electronic devices have a greater susceptibility to DC coil inductive kick than electro-mechanical devices and did not require identification of critical characteristics for non-quality related plant changes.

The Contributing Cause of this event was the post-modification testing performed following the change of the relays from Allen Bradley to Struthers Dunn did not exercise the fast dead bus transfer timing circuitry. This contributed to this condition by delaying detection of relay failure.

Shearon Harris Shearon Harris 1 replaced the SSPS control circuit boards with CPLD-based boards in 2013

[101]. Note that this represents a conern about a software CCF versus an actual failure event.

In this case, the licensee performed a review but erroneously concluded that the change could be implemented without performing a formal 10 CFR 50.59 evaluation and without obtaining a license amendment. Specifically, in the spring of 2012, Shearon Harris failed to perform a 10 CFR 50.59 evaluation that was sufficient to demonstrate that a license amendment was not required prior to replacing the original SSPS circuit boards with CPLD-based boards. The violation was due in part to the licensees misinterpretation of the NEI 01-01 guidance [102]. With the replacement of the SSPS boards, the licensee implemented a change that did not adequately evaluate and document that they did not create the possibility of a software CCF in the reactor protection system (RPS) and engineered safety features actuation systems (ESFAS) had not previously been evaluated in the Updated Final Safety Analysis Report (UFSAR) [103]. The licensee failed to recognize that the software used in the replacement boards had the potential to adversely affect the design functions of the SSPS.

4-23

Unlike the original circuit boards, which used fixed logic devices, the replacement boards were CPLD-based boards that required an application-specific software (data file) to configure the boards logic functions. These data files that are placed in the boards CPLD memory perform a specified design basis safety function in the SSPS. Because potential software-related failures represent a new failure mode for the SSPS, and these failures could occur on each of the redundant SSPS safety trains, there is a potential increase in the likelihood of a software CCF of the safety function performed by the CPLDs and ultimately, the SSPS.

Browns Ferry 3 In August 2006, a manual reactor trip of Browns Ferry Unit 3 occurred following the loss of 3A and 3B reactor recirculation pumps. The pump variable frequency drive (VFD) controllers became unresponsive, and the condensate demineralizer controller (CDC) failed simultaneously with the VFD controllers. Both the CDC and VFD controllers are connected to the ethernet-based plant integrated computer system network, and due to excessive network traffic, they failed simultaneously, resulting in a manual reactor trip [104].

This event demonstrates that digital CCF can occur due to digital communications.

4.6.6.2 Software CCFs The potential for software CCF has been recognized for many years. IEC 60800 states that software design and coding faults can result in the potential for CCF in software-based implementations of Category A functions. The standard states that software by itself does not have a CCF mode. Instead, CCF is a system failure issue that arises from faults in the functional requirements, system design, or in the software. Thus, the standard recommends that the potential effects of software CCF be considered in the application of the defense-in-depth principle, with appropriate countermeasures employed throughout the development and evaluation processes.

EPRI 1016731 [105] includes an evaluation of plant operating experience, noting that because safety systems are intentionally kept as simple as possible, they are subjected to rigorous design and quality assurance requirements, and are not often called upon to perform their safety functions; attempts to gather statistically significant data on number-of-demands and failures-to-actuate-on-demand may be futile in any relevant time frame.

A selection of software-related CCF events are discussed below. Experiences at Palo Verde 3, Turkey Pont 3 and 4, Savannah River, and Sellafield reinforce regulatory concerns regarding the quality and reliability of safety-related equipment with EDDs. EPRI also provides an example of a software CCF. The examples were chosen to demonstrate the variety of causes or types of software CCFs.

Palo Verde 3 On November 14, 1991, Palo Verde 3 tripped on low Departure from Nucleate Boiling Ratio (DNBR) signals [106]. During the post trip investigation, personnel discovered that a problem with the control element assembly calculator (CEAC) software design may have delayed the reactor trip for up to 16 seconds when a second core protection calculator (CPC) time delay was initiated.

A second time delay was the result of the CEAC software design not anticipating that there would be CEA slips lasting less than 0.5 seconds.

4-24

EPRI, in its review of actual and potential software CCF events, defined this as an active CCF because a bad setting was in all 4 CEAC/CPC's, but triggered in only 1 channel (1 rod slipped faster than expected) [105]. The reactors tripped immediately on deviation/low DNBR, instead of experiencing the 16 sec trip delay. The root cause is an incorrect parameter value with a contributing factor of an inadequate requirements definition.

Turkey Point 3 and 4 In November 1994, it was discovered that although the sequencer is supposed to allow valid safety injection (SI) signals to pass through while in test mode, a logic defect inhibited a valid SI signal during testing at Turkey Point [107]. This event is the only one found by EPRI that could have resulted in an actual CCF of a 1E system under certain conditions. The root cause was determined to be inadequate software design coupled with inadequate software V&V [105].

This digital system was deployed with a selectable automatic self-test feature. It was discovered later, during surveillance testing, that 5 of 18 automatic self-test routines running in each of asynchronous sequencer channels had an error in the application logic that would have prevented an actual SI signal from passing through while in auto test mode. The licensee determined that this condition resulted in all 4 sequencers being inoperable some of the time, triggered by asynchronous yet overlapping automatic tests. These individual channel tests were set up on a set frequency, not on every processor scan cycle. The immediate corrective action was to take the system out of automatic test mode and then correct the self-test logic with a software change.

This software logic defect was introduced during the detailed logic design phase of the software development. The detailed logic designer and the independent verifier failed to recognize the interaction between some process logic inhibits and the test logic. The defect in the software logic was not detected during V&V because the response to valid inputs was not tested during all stripping and loading sequences of the automatic and manual testing logic.

EPRI stated [105],

it is important to note that in this case [the event at Turkey Point 3 and 4] at least one important defensive measure had apparently not been applied in developing the application software. A cyclic software design, free of conditional statements (timed, periodic tests), independent of external conditions (test switch position) might have been used to ensure that multiple channels could not be disabled simultaneously.

EPRI also notes [105]

adding automated self-testing features to the relatively simple safety function logic led directly to the problem. It added complexity to the system functionality, with corresponding adverse effects on several aspects of system development that are important from a dependability perspective. For example, requirements become more complicated and more difficult to specify with high confidence that they are complete, correct, unambiguous, etc. It becomes more difficult to anticipate, specify and test all the potential abnormal and faulted conditions that the system might see, and so on. This event reinforces the notion that safety systems in nuclear plants tend to be functionally simple (compare a signal to a setpoint and change a zero to a one if the setpoint is exceeded), and changes that increase complexity should be considered very carefully.

4-25

Turkey Point 3 A latent design error in PLC coding prevented the two instrument air compressors from loading at Turkey Point 3. The design error was due to overreliance on the vendor to provide a complex digital modification without adequate in-house review [108].

Operations personnel in the control room at Turkey Point 3 acknowledged the instrument air (IA) low pressure annunciator and directed immediate operator action to start all available instrument air compressors. The diesel driven 3CD and 4CD IA compressors are designed to be backup sources for the electric-driven compressors. As backups, the compressors are placed in normal standby operation which bypasses all safety trip and shutdown protections to ensure that the compressors function and supply air when needed. If the diesel driven compressors experience trouble, an alarm will be activated giving operations personnel time to resolve the problem. The standby feature is unique to the diesel compressors.

As configured at the time of the event, it was expected that the 4CD and 3CD IA compressors would automatically start and load when IA system pressure dropped below the identified setpoint.

Instead, system pressure continued to drop, and both the 3CD and 4CD compressors were found running unloaded in a non-responsive state. Several attempts to take local control of the compressors and load were not successful. Ultimately, operators had to employ an emergency stop and locally start them in order to load and supply IA to the system. Both diesel-driven IA compressors were restarted and loaded; however, the IA pressure decreased below 65 psig for Unit 3, which required the manual reactor trip.

A cooling fan permissive in the PLC coding but not needed for standby operation rendered the compressors in a non-responsive state, requiring an emergency stop to exit the code and allow manual operation. The vendor-supplied compressor software was not subject to a detailed technical review by in-house personnel of the operating logic of the PLC.

The root causes of the event were as follows:

• A latent design error was in PLC coding which prevented the 3CD and 4CD IA compressors from loading

• The design error was due to overreliance on the vendor to provide a complex digital modification without adequate in-house review.

Contributing causes include difficulty in reading the 3CM LCD control panel screen in direct sunlight and lack of control panel screen instructions or operator aid. During rounds, the turbine plant operator could not see the control panel display on the running electric-driven compressor, 3CM. The operator pressed what was thought to be the administrative button to get the screen to a different mode. The load button was pressed instead, causing the compressor to unload. The control panel is difficult to view in direct sunlight. In addition, instructions for operating the IA compressor control panels were not readily available during the operator rounds.

Savannah River In July 2010, the Savannah River Site (SRS) experienced a failure in a safety-significant PLC processor module for a tritium air monitor in the Metallography Test Facility. The triple modular redundant (TMR) T8110B PLC processor modulewith firmware version build (b)115, designed to provide visual/audible alarms to alert workers of increased tritium activitywas displaying only 4-26

a visual alarm in the process room. Investigation revealed that the processor had unexpectedly gone offline, and the system, as designed, went into a safe configuration to energize the visual alarm [109].

The vendor ICS Triplex (a Rockwell Automation Company) had earlier issued a product notice in June 2010 that indicated that TMR T8110 processors with firmware versions b115-b127 were defective. Because the installed system had a processor model TMR T8110B (with firmware version b115), no further action was taken because the product notice did not include model TMR T8110B.

Diagnostic information obtained from the processor was relayed to the vendor to assist with the failure analysis. At that time, the vendor informed SRS that the product notice also applied to the TMR T8110B processor with firmware version b115. The vendor attributed the problem to a defect in the processor module firmware for versions b115-b127. It therefore affected both TMR processor modules T8110 and T8110B with the same firmware version b115. The vendor provided an updated copy of the firmware (version b128) to SRS, which corrected the problem.

Sellafield (UK)

Sellafield (UK) installed vacuum transmitters to monitor ventilation depressions in gloveboxes [50].

Commissioning tests revealed that a vacuum transmitter worked correctly between atmospheric pressure and -6mB. If the transmitter were pressurized it again worked correctly to about +6mB overpressure. However, at about +6mB pressurization, the electrical output would increase, and in effect, the transmitter would work in reverse (i.e., +7mB would read -1mB, +8mB would read -2mB, +9=-3, etc.). This was clearly an unrevealed dangerous condition because the glovebox could be dangerously pressurized but the indicators would show that the pressure was within limits.

Discussions with the manufacturer revealed a poor approach to quality. The fault was a well-known software bug, but the manufacturer had not contacted any of the customers to inform them of the fault. The manufacturer was not clear which of the serial numbered transmitters were affected with this problem. These transmitters have been removed, a search was completed for any others at Sellafield, and steps were taken to forbid all future purchases from this manufacturer.

Sellafield (UK)

The Sellafield experience with digital recorders is discussed in the subsection on undeclared digital content [50]. Addressed here is the CCF vulnerability of those recorders.

The event at Sellafield shows that software CCF can actually occur, but not in the usual way, making this a new software failure mode to be considered. The added software caused the chart recorders to go to sleep. Although this occurred in a noncontrol-capable device, this shows why guidance calls for no added, unnecessary software.

One of the regulatory positions in RG 1.152 includes a Regulatory Position prohibiting unwanted software. The case of the Sellafield chart recorders, which had gaming software installed, demonstrated that any safety-related device, even one with a high level of simplicity and low functionality, should still have some level of review.

4-27

EPRI example EPRI provides the following example of a redundant system failing because of inadequate configuration controls [110]:

A redundant system failed completely due to inadequate configuration controls. A spare part for a system with redundant trains was purchased and put on the shelf after the original system was installed and tested. Firmware on that spare part had a different revision level than the working system, but the module was purchased from the same manufacturer with the assumption that it was an identical part.

Later, one train failed, and the other took over, so there was no loss of function.

The bad part was replaced with the spare, at which time the entire system crashed and could not be restored until the spare part was removed. The firmware on the spare board was incompatible with the original boards firmware, which caused both trains to abort. When both trains had the same revision level of the firmware, then everything worked.

4.7 Operating Experience It is generally accepted that operating experience can be used to help prove the suitability and reliability of components and can therefore be used in support of meeting the regulatory requirements for the use of the device. However, rather than the reliability data provided, the greatest benefit from operating experience seems to be from the lessons learned as shown by the examples of CCFs such as susceptibility to dc inductive kick.

While operating experience alone does not provide sufficient evidence for the safety justification of a safety-related digital I&C system, it may provide, with proper documentation and under certain conditions, supporting evidence when performing licensing reviews and/or I&C system inspections. However, the large volume of operational experience from industrial applications may not be applicable because of a lack of documentation, uncertainty in the version of the device used, process conditions, operating environment, service history, proper failure reporting and recording of data, and any modifications made to the device.

Guerra et al. [111] state, under-reporting by the smart device users could lead to over-optimistic estimates of the MTTF [mean time to failure]. In fact, in Research Information Letter (RIL)-1002

[112], NRC recognizes that 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 [113] has been insufficient [114].

Traditionally, I&C operating experience is recorded and evaluated only if disturbances and failures occur. One of the problems with operating experience is that manufacturers do not disclose details on the design and operating experience of their products, so operating experience at the component and system level is difficult to obtain, and manufacturers and users do not readily share data. Although specific operational experience data for digital devices has proven difficult to come by, especially for software failures, what data is available has been reviewed to identify the failure modes (see Subsection 4.8).

It is recognized that operating experience by itself is insufficient for estimating the reliability of the device. High reliability of software can only be demonstrated by means of an independent 4-28

assessment with full access to the design documentation [115]. A user of a smart sensor/actuator, however, would not usually have access to the design documentation. The supplier would not normally allow other parties to review its design documentation, and as a result, it is not usually produced for that purpose. The Adelard process, discussed in this report, has access to design information, operating history, and essentially dedicates the component.

Factors that may compensate for lack of operating experiencea digital devices simplicity and high testabilitymay provide assurance of dependability that helps to compensate for a lack of operating history.

EPRI TR-106439 states, Successful operating experience in applications that are relevant to nuclear power plant safety systems may be used as part of the means for determining the acceptability of a commercial item. applicable operating experience can be a determining factor for COTS [commercial off-the-shelf] product qualification but is only a part of the dedication process and should not be considered the only determining factor."7 EPRI has analyzed the operating experiences of Korea, France, China, and other countries where digital I&C has been deployed to some extent. The analysis showed that, according to the operating experience, software CCFs is no more problematic than non-software CCFs [116].

Section 5.1 of EPRI TR-107339 refreshes the studies of software-based systems, showing that a large fraction of problems with software is attributable to problems in the requirements specifications. It recommends a controlled procedure or methodology for development of system requirements similar to that described in EPRI TR-108831 [110]. Based on the system requirements, a set of critical requirements can then be generated for the CGD process or evaluation of the software tools used.

Similarly, proven-in-use arguments are based on objective evidence that is generally insufficient to justify use as a Category 1 (safety related) component [94]. In Canada, a mature product that builds on proven-in-use data, cannot be used at Category 1 [176]. Also in Canada, proof through testing, which can only be used at Category 3, and only for low-complexity items, requires a certain level of in-use tests in a configuration representative of the application [176].

Preponderance of evidence allows a previous qualification to be considered provided the scope and applicability are justified.

The relevance of the operational experience significantly depends on the quality of data collection (including the version number, the number of demands, and the failure mode, for example) and the contractual arrangement for defect notifications. Operating experience is also limited in identifying systematic failures and hence must be complemented with efforts such as additional assessment of the design process and further analyses.

A key issue regarding operating experience is that extensively used products can still have crucial faults that could cause problems in safety systems. The tendency is to consider operational experience to be like extensive random testing. In this regard, operational experience suffers from the same shortcoming as testing in that testing cannot prove the absence of faults, except for very simple devices [117].

Operating experience can be a useful tool for identifying lessons learned. The examples of hardware-related CCF events at Brunswick, Shearon Harris, Browns Ferry, and Beaver Valley 7 The safety evaluation (SE) on EPRI TR-I06439 (NRC ADAMS Accession No. ML092190664) states, TR-106439 contains an acceptable method for dedicating commercial grade digital equipment for use in nuclear power plant safety applications and meets the requirements of 10 CFR Part 21.

4-29

reinforce regulatory concerns regarding the quality and reliability of safety-related equipment with EDDs and also highlight the use of components in a manner not intended.

Industry seems to overly rely on operating experience without focusing that experience on critical characteristics for their specific use. The review of vendor material for EDDs highlights the overall use of the EDDs and licensees may not question the process conditions, operating environment, service history, proper failure reporting and recording of data, and any modifications made to the device.

4.8 Failure Modes Understanding of dominant failure mechanisms helps in estimating failure probabilities and beta factors and on understanding the failure modes that can result in the specific failure being studied.

The failure mode is linked directly to the failure mechanism. IEEE Std 100 defines failure mechanism as the physical, chemical, or other process that results in failure. It notes that The circumstance that induces or activates the process is termed the root cause of the failure. The failure mechanism defines the physlcs of the failure. Thls involves the description and sequence of those mechanical, electrlcal, or chemical processes or a comblnatlon of these, whlch occurred during the period in which the failed item changed from an operational item to a failed item. Thus, the failure mode is the physical or functional manifestation of a failure. For example, the failure mode for a system may be characterized by slow operation, incorrect outputs, or complete termination of execution [127]. EPRI 1019182 [128] states that A failure mode of a system, component or function is defined by its external behavior, with the system, component or function effectively viewed as a black-box.

Understanding the failure modes of EDDs is vital when relying on self-diagnostics to identify and correct for failures. The presence of new and potentially unknown failure modes in digital systems and components translates into a slower rate of incorporating digital systems into NPPs compared to the process industries [129].

The term failure mechanism should not be confused with the term failure mode. Failure modes result from the activation of failure mechanisms. That is, as defined in IEEE Std 100, the failure mode is the effect by which a failure is observed to occur. The failure mode is generally categorized as electrical, mechanical, thermal, and contamination. IEEE Std. 100 defines the software failure mode as The physical or functional manifestation of a failure. For example, a system in failure mode may be characterized by slow operation, incorrect outputs, or complete termination of execution. For electronics, failure modes are usually identified as shorts, opens, or electrical deviations beyond specifications. For mechanical components, the failure mode may be low-cycle fatigue.

RIL-1002 provides a synthesized generic set of system-level DI&C failure modes that may be useful when developing a systems design basis and analyzing the degradation of its performance. This is relevant because EDD failure modes could degrade the safety function of a DI&C safety system. However, RIL-1002 notes that 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 systemspecific 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 4-30

be comprehensive for purposes of making determinations of reasonable assurance.

IEC 61508 only acknowledges two types of failuresafe and dangerous. Summers states that analysts believe that any degraded, not safe, or not dangerous failure can be assumed to be a safe failure. Ironically, while these non-failures are generally included in the SSF [safe failure fraction] calculation, the analysis reports actually recommend not including them in any spurious trip rate calculation [123].

Most recognize that the special nature of the design of smart sensors compared to analog sensors have a greater potential for unintended behaviors and subtle or new failure modes.

However, an NRC review of the new design boards for the SSPS, which uses PLDs, states that the programmable devices do not produce a different failure mode than previously analyzed [125].

Thus, the I&C portion of the EDD may be shown through extensive testing to behave and fail just like other I&C systems and components.

There are significant differences between the dependability aspects of deploying smart sensors vs. conventional ones. Some failure modes do not exist in conventional sensors, such as those involving information overload and timing aspects. Other failure modes emerge through the use of different technologies, such as those involving complexity, data integrity and human interface.

Not surprisingly, failures originating in human interface, complexity, and information overload are dominant [121]. Operating experience (see Subsection 4.7) is well suited for identifying failure modes and failure mechanisms.

In a PRA, very simplistic high level failure modes are represented explicitly on an application-specific basis, as detailed below:

• Probabilities of failures on demand

• Frequencies of failures in continuous conditions (e.g., spurious actuation and mission time failures, if applicable)

Many NPPs maintain maintenance records and use this information to update their PRAs.

However, licensees do not provide the specific failure data in their PRAs; instead they use the generic failure mode of fails (i.e., the component fails to function).

Although there may be a large amount of failure data for the products delivered, this information is typically proprietary and is seldom made publicly available. This makes identifying and collecting a set of failure modes for EDDs difficult.

For an EDD, the failure modes could be defined by functionmonitoring, diagnostics, communication, and control. For those EDDs that provide control, the failure modes should explore complexity by identifying the type of device and providing details on whether it has configurable/programmable internals such as CPLD, etc. The many combinations of types and functions of EDDs can be used to create a list of failure modes specific to that EDD.

At present, FMEAs and PRAs that include software/digital failures assess the same typical failure modes as analog systems, such as fails on/off, high/low, causes/prevents actuation, etc., for its digital failures. These failure modes are applicable to both analog and digital systems, but they fail to account for any potential new failure modes introduced by the digital systems.

4-31

Knowing the failure modes can serve two purposesevaluating the effects of those failures and providing input for diagnostics. To identify any new failure modes for digital I&C-based systems, ORNL reviewed the following databases or data handbooks [134]:

1. OREDA Offshore Reliability Data Handbook;

2. Reliability Data for Safety Instrumented Systems, PDS Data Handbook, 2006 Edition;

3. Guidelines for Process Equipment Reliability Data, with Data Table, AICHE;

4. Safety Equipment Reliability Handbook, Exida.com;

5. Reliability, Maintainability, and Risk: Practical Methods for Engineers, 6th edition (D. J.

Smith);

6. SPIDRSystem and Part Integrated Data Source; and

7. Nuclear Plant Reliability Data Systems (NPRDS) and Equipment Performance and Information Exchange (EPIX), INPO.

All of these sources are available for purchase except the INPO databases (NPRDS and EPIX).

Exidas Safety Equipment Reliability Handbook (SERH) provides a collection of failure rate data that contains equipment item reliability data from over 200 OEMs.

Technological failure modes in embedded systems can be divided into two main groups:

1. Physical failures of the hardware

2. Failures associated with errors in design such as improper requirements, integration, or software faults.

ORNL/TM-2010/32 [132] identified new failure modes for digital systems compared to analog systems such as relay race, complexity of the software program allowing an undetected latent error to escape testing, communications presenting unique problems for digital systems because of the ease of changing digital programs, and a quasi-trip state in which the output of the failed NAND gate would not allow a true HI. These examples represent failures of the hardware, the software, and its integration. In these reports design errors that may result from requirements or integration are often allocated conceptually to the software fault category.

The events at Brunswick with the Allen-Bradley relay and the CPLD boards at Shearon Harris also show changing some aspect of the digital devices may introduce new failure modes for that device.

All failure modes of I&C systems identified in ORNL/TM-2010/32 can be characterized as (a) detectable/preventable failures, (b) age-related failures, (c) random failures, (d) random/sudden failures, or (e) intermittent failures.

For convenience, a list of failure modes collected from these sources is presented in Table 4-2.

This table may include failure mechanisms (as defined above) but because the original sources identified these as failure modes this report maintained that classification.

4-32

Table 4-2 Collection of Digital System Failure Modes [132,133,134,135]

Open Shorted Output stuck high (high output)

Output stuck low (low output) Supply open Data bit loss High leakage current Slow transfer of data Incorrect results Alters data, address, memory No output Spurious operation Fails to function Erratic output In-service problem Faulty signal Software failure Instrument failure Control failure Calibration error Human error External events Overload No change in output (with change in input)

Functioned without signal No function with signal Maximum output Intermittent operation Functioned at improper signal Out of sequence level Corrupted input Specific operational experience data for digital devices has proven difficult to come by, especially for software failures. However, a review of software errors uncovered during integration and system testing of two spacecraft found that safety-related software errors are shown to arise most commonly from the following [137]:

1. Discrepancies between the documented requirements specifications and the requirements needed for correct functioning of the system, and

2. Misunderstandings of the softwares interface with the rest of the system Similarly, another study [138] found that only a tiny proportion of software failures can be attributed to bugs, 8 as detailed below:

7F

1. The largest class of software problems arises from errors made in the eliciting, recording, and analysis of requirements.

2. The second largest class of problems arises from poor human factors design.

The two classes are related.

Gruhn and Lucchini report similar results for the failure cause of software errors [139]:

• Requirements: 56%

• Design errors: 27%

• Other errors: 10%

• Coding errors: 7%

The primary causes of failure by lifecycle phase are [140]:

8 Bugs refer to errors in the software code that cause a program to fail to meet its specification 4-33

• Specification: 44%

• Changes after commissioning: 20%

• Operations and maintenance: 15%

• Design and implementation: 15%

• Installation and commissioning: 6%

Especially for complex systems, it is difficult to discover all errors. In practice, one must assume that an undiscovered error remains when the system becomes operational.9 especially for complex systems. Typically, a system (dormant error) may be discovered (i.e., becomes active).

Thus, a software failure occurs as a result of the combination of a dormant error and the onset of the specific set of conditions that triggers the error. In general, it is difficult to predict the impact of a triggered fault. The fault may cause the system to behave in undesirable ways. In addition, since the fault is unknown, it is difficult to predict how it will impact the system when it does occur.

For convenience, a list of the causes of software-related failures collected from these sources is presented in Table 4-3.

Table 4-3 Causes of Software-related Failure Modes [135]

Incomplete description of requirements Incorrect firmware coding Faulty calculation in program Requirements error Incorrect interpretation of requirements Task/Application crash Inadequate software version control Software update incompatible with design basis Inadequate software V&V Software lockup Application-independent classes of failure modes from the DI&C processor can be defined and standardized at the processor level, with the I&C effects defined separately. The Advisory Committee on Reactor Safeguards (ACRS) provided a list of processor classes of failure modes reported in the literature (Table 4-4).

9 While developing the avionics software for the space shuttle, the National Aeronautics and Space Administration (NASA) determined that the statistical average for software used in critical systems (e.g., flight control, air traffic control, etc.) averaged 10 to 12 errors for every 1,000 lines of software code. Because this was unacceptable to NASA for use on the space shuttle, NASA forced one of the most stringent test and verification processes ever undertaken for the primary avionics system software. An analysis performed after the Challenger accident showed that the primary avionics system software (PASS) for the space shuttle had a latent defect rate of just 0.11 errors per 1,000 lines of code. However, this achievement did not come easily or cheaply. In an industry where the average line of code costs the government (at the time of the report) about

$50 (written, documented, and tested), PASS cost NASA slightly over $1,000 per line. The total cost for the initial development and support for PASS was $500 million (http://history.nasa.gov/sts25th/pages/computer.html).

4-34

Table 4-4 Causes of Processor-related Failures [136]

Failure Mode Description Task crash The control software task exits unexpectedly Task hang The process goes into an infinite loop Task late response The output of the task exceeds the specified response time Task early response The output of the task is too early Task incorrect response The output of the task is timely but violates specifications Task no response There is no output from the task (but the task is not hung)

Processor crash The processor software kernel (or operating system) crashes bringing down all tasks running on the operating system Corrupted input The input signal from the plant sensors receives corrupted data due to either an analog electrical problem, an analog-to-digital conversion problem, or noise in a digital network Corrupted output The output signal to plant actuators is corrupted due to an analog electrical problem, a digital-to-analog conversion problem, or noise in a digital network is corrupted Out-of-sequence data Data packets arrive at the destination in a sequence different than expected (applicable to digital networks using transmission) 4.9 Component Data Component data is hard to collect and even harder to assess if the failure data is appropriate for the use intended. May factors such as attributes, properties, critical characteristics, operating environment, use, how the data is collected, etc. is typically not provided and users accept the values without question. Failure data, even vendor supplied data, with millions of hours of use, does not reflect how the component will be used for specific applications and can result in unsubstantiated claims of reliability. As always, care should be used when relying on operating experience and component reliability data, The limited data from operational experience in the NPP industry makes the use of reliability claims difficult to defend, although the non-nuclear industry has extensive operating experience, and vendors claim increased reliability. Complexity of the software can also impact its reliability.

Even though the single execution sequence of a complex software system has a vanishingly small probability of occurrence, there is very little one can say about the reliability of any such system, no matter how long it has actually executed without a failure [119].

Some databasessuch as the Equipment Performance and Information Exchange System (EPIX) that is maintained by the Institute of Nuclear Power Operation (INPO)contain data, but the specifics are time consuming and difficult to obtain, and the data are not publicly available.

The reporting of hardware and software failures is critical for monitoring the reliability of EDDs.

This is addressed under 10 CFR Part 21. Just as critical is the vendors willingness to provide assurance that the licensee would be notified of OS software errors and to support any necessary configuration controls for any future required software changes. Although the use of EDDs is widespread in industry and vendors have data, specifics have not been obtained for review by this project.

4-35

Although EDDs are not systems (even though they are frequently treated as such), the software process characteristics for a system are applicable, including completeness, consistency, correctness, style, traceability, unambiguity, and verifiability.

Data for the evaluation of the credit that can be given to feedback experience should be collected, including site information, operational profiles, demand rate, operating time, error reports, release history [115].10 However, an acceptable amount of feedback to take credit for operating experience requires data on devices with the same make, model, and software/hardware version operating in the same environment. Data on devices are difficult to obtain and become very difficult to collect on specific devices.

Vendor failure rates assume perfect operating conditions and perfect mechanical integrity, ignoring how the process and the operating environment contribute to equipment degradation and failure. Actual failure rates highly depend on the operating environment and MI and can be orders-of-magnitude higher than vendor-reported rates. Consequently, reliability data should be assessed based on field feedback: the less feedback, the more the uncertainty in the data [120].

The physical failure rates of smart sensors seem to be comparable to those of conventional sensors. Examples given by Meulen [121] show that the failure rate of the digital Honeywell STT250 smart temperature transmitter is calculated to be 3.9 x 10-7/h, and the failure rate of the digital Fisher-Rosemount 3051C Pressure Transmitter is 7 x 10-7/h: both failure rates are for all failure modes. The Nuclear Plant Reliability Data System (NPRDS) failure rate for analog transmitters is 1.42 x 10-7/h [122]. There is no reason to believe that the failure rate of smart sensors will be significantly better than for analog sensors, because conventional sensors are typically built using robust components, whereas smart sensors may contain more vulnerable components.

Prior to the release of IEC 61508, many manufacturers provided in-service and accelerated test failure data. Following the approval of IEC 61508, manufacturers increasingly began claiming compliance based on a shelf-state analysis with seemingly perfect operating environment conditions. IEC 61508 allows manufacturers to make SIL claims based on predictive analysis without any burden to substantiate the claims later using actual field data. However, the failure rates and PFD values declared in analysis reports are much better than those that can be achieved in actual field applications [123].

Failure rates are used to estimate the reliability of the devices. SAP ERL.1 [124] states, The reliability claimed for any structure, system or component should take into account its novelty, experience relevant to its proposed environment, and uncertainties in operating and fault conditions, physical data and design methods.

Paragraph 191 in the SAP further states, Where reliability data is unavailable, the demonstration should be based on a case-by-case analysis and include:

10 NRC staff participated in the meetings of the Regulator Task Force on Safety Critical Software (TF SCS) for nuclear reactors, which is comprised of international nuclear regulators and authorized technical support organizations. The task force met from 2009 to early 2016 and NRC provided input to the 2015 revision of the report. Although the NRC did not endorse the 2015 revision for regulatory use by the NRC, it published it as a technical report in NRCs NUREG/IA series [NUREG/IA-0493].

4-36

(a) a comprehensive examination of all the relevant scientific and technical issues; (b) a review of precedents set under comparable circumstances in the past; (c) where warranted, e.g., for complex items, an independent third-party assessment; and (d) periodic review of further developments in technical information, precedent and relevant good practice.

Because embedded systems are now largely defined and controlled by software, it is likely that software failures will form a major threat for reliability. Therefore, appropriate reliability analysis and design techniques should be provided to support the anticipation and prevention of potential failures. Diagnostics of active components should be self-evident, whereas diagnostics of standby components, although problematic, could be used to actuate and monitor the devices health.

Analyses can be used to support the reliability assessment of the EDDs [125]:

• Reliability

• Mean time between failure calculations

• Single point vulnerability studies

• Failure modes and effects analyses If the reliability assessment demonstrates that the EDDs reliability is at least as good as the reliability of analog boards, then the reliability of the EDDs should be acceptable, and credit may be able to be given to the sufficiency of the device to meet its safety standards.

EDDs that have a limited amount of software and lines of code in EDDs (some contain as little as a few kilobytes of assembler code) may support a proven-in-use argument based on their large operating history. However, for licensees to use this argument they (or the vendors) would have to provide the data and basis to demonstrate EDD reliability.

Although there are significant differences in the systems in the various industries that use IEC SILs for demonstrated integrity and reliability of components, there is not much difference at the individual component level. Leveraging the similarities at the component level has the potential to lead to a mutually beneficial relationship for industries and manufacturers through a larger pool of operating history because of the larger customer base. However, care must be taken before installing any EDD in a safety application based on a generic reliability value rather than choosing one based on its integrity and reliability in a similar operating environment.

The available data on failure rates and diagnostic coverage do not provide detailed design information [121]. Manufacturers evaluations may provide the numerical data required by IEC 61508-6failure rates and fault coveragebut the details for arriving at those values may not be provided and may not be applicable.

Industry seems to over rely on failure data compiled from operating experience without determining if that data is appropriate to make a determination with respect to the critical characteristics for their specific use. The review of vendor material for EDDs highlights the overall reliability of the EDDs and licensees may not question the process conditions, operating 4-37

environment, service history, proper failure reporting and recording of data, and any modifications made to the device.

4.9.1 FMEA After the failure modes for the digital parts of the EDDs are identified, an FMEA can be used to identify the potential effects of these failures on the components/system. Vendors, licensees, and applicants must understand the operation and failure modes of digital systems, including EDDs, as well as the effects of these failure modes on operations and safety.

The failure modes need to be understood and fully specified for each operating mode . Software requirements for handling both hardware and software failures should be provided, including requirements for analysis of and recovery from computer system failures. It is important to understand the full functionality of an EDD and its behaviors.

FMEA is a logical, structured process for identifying process areas of concern. FMEAs are typically used to show that the design meets the single failure criterion in 10 CFR 50, Appendix A, and to assess the potential for an undetectable failure. However, these uses of FMEA are at the system level.

More specific to this work is that FMEAs, at the component level, are used as part of the CGD process, determining the completeness of the diagnostics (if applicable). For evaluating component level reliability for IEC 61508 certifications, a failure modes, effects, and diagnostic analysis (FMEDA) is sometimes used.

In some cases, as described below, such as to determine if a malfunction with a different result could occur, multiple levels could need to be considered.

The effects of failure modes for the EDDs can be investigated at the following levels:

1. First-level effects: at the digital devices boundary

2. Second-level effects: on the component

3. Third-level effects : on the control or safety system

4. Fourth-level effects: on the plant/the safety function of the system Determining the first-level effects requires knowledge of the failure modes for the I&C portion of the EDD.

Typically, the results from an FMEA at the component level are inputs to the FMEA at the system level. Similarly, the results from an FMEA at the EDD (device) level are input to the FMEA at the component level. The failure of the EDD and its effect on the associated component may be bounded by an existing FMEA that evaluates the failure of the component. This is bounding if no new failure mechanisms at the component level are introduced.

NEI 96-07, Rev. 1 (endorsed by RG 1.187), states, Malfunctions of SSCs are generally postulated as potential single failures to evaluate plant performance with the focus being on the result of the malfunction rather than the cause or type of malfunction. A malfunction that involves an initiator or failure whose effects are not bounded by those explicitly described in the UFSAR [Updated Final Safety Analysis Report]

is a malfunction with a different result. A new failure mechanism is not a malfunction with a 4-38

different result if the result or effect is the same as, or is bounded by, that previously evaluated in the UFSAR.

Certain malfunctions will not be explicitly described in the FSAR because their effects are bounded by other malfunctions that are described.

The safety evaluation of the SSPS board replacements reported in Topical Report WCAP-17867-P [125], describes the FMEAs performed on the three safety-related boards. The FMEA studies resulted in two conclusions (as documented in the topical report):

1. There are no non-detectable failures that when paired with a detectable failure would cause a loss of safety function (Addressing IEEE 603-1991, Clause 5.1).

2. The new design boards do not produce a different failure mode than has been previously analyzed (Addressing GDC 23).Rather than using the FMEA for an EDD as input to the system and to the plant FMEA, an FMEA could, within the same table, consider the failure modes of the EDD and evaluate their effects to assess if there are any new failure modes at the system level or that affect the safety function. This is important to know prior to installation, because having no new failure modes at the component or system level means that there are no new consequences other than what has been considered previously.

This is similar to the FMEDA on the RadICS platform. The safety evaluation for the RadICS [144]

states that the RadICS FMEDA was used as input data to support a system-level FMEA and reliability analysis for an NPP-specific RadICS Platform system. The RadICS FMEDA for the FPGA based Safety Controller (FCS) was performed for each platform module and includes four groups of module components.

In regard to the issue of CGD and FMEA, NRC IP 38703 [142] includes the following statement:

An evaluation of credible failure modes of an item in its operating environment and the effects of these failure modes on the items safety function may be used in the safety classification of an item and as a basis for the selection of critical characteristics.

Subsequently, NRC IP 43004 [143] states that technical evaluations should include performance of a failure modes and effects analysis (FMEA) to identify the credible failure mechanisms of the item in the specific application under consideration.

Although not the only method, EPRI noted that A failure modes and effects analysis (FMEA) is an effective tool to determine critical characteristics when complete design information is not available [53].

Additionally, evaluating EDDs and their potential impacts at the system level may require extending the results of a component level FMEA to the system level, which then could be used in a plant level FMEA or PRA.

FMEDA is similar to an FMEA in that a systematic analysis technique is used to obtain subsystem

/ product level failure rates and failure modes with an added assessment of the diagnostic capabilities (i.e., the D in FMEDA) to detect failures. That is, an FMEDA combines the FMEA techniques with an extension to identify diagnostics techniques with failure modes relevant to safety instrumented systems. For example, the FMEDA for the RadICS platform analyzed 4-39

potential failures in each of its component groups and categorized the effects of these failures in terms of detectability/undetectability [144]:

• Fail-safe state (detected/undetected)

• Fail dangerous state (detected/undetected)

• Analog input (deviation more than 2% of span)

• Annunciation (detected/undetected)

• No effect

• Fail dangerous (undetected after surveillance test)

FMEA and extensions such as FMEDA are widely accepted methods for systematically analyzing a device to determine its hardware failure modes, their frequency, and their impact.

However, the key point is that these methods, FMEDA in particular for IEC 61508 certifications, are focused on random hardware failures. They explicitly do not consider systemic failures, and use operating experience indicating failures beyond what is anticipated by the FMEDA as an indication that there may be systemic issues with the component and would as a result require further review [276].

Further, FMEAs are limited in that they focus on singular events, CCFs are typically not evaluated, and the likelihood of multiple failures that are not evaluated could be more likely than the single failures.

Another challenge for FMEAs is software. Based on a review of software hazards analyses and software FMEAs, a collection by ORNL, based on the ORNL researchers experience, of the consequences (effects) of a software hazard is provided in Table 4-5. Because the consequences (effects) from the failures of software in Table 4-5 are at the system level, they do not all apply at the EDD level. They can be used to inform those performing an FMEA on an EDD what types of effects are typically considered.

Table 4-5 Collection of the Consequences (Effects) of a Software Hazard None Loss of redundancy Inadvertent trip Failure to trip when required False channel trip Partial loss of redundancy; system remains operable Display data failure Loss of redundancy for division voting; system remains operable Processor display; operator receives Inadvertent alarm erroneous information Inadvertent partial trip Erroneous input data Erroneous output display The NRC ACRS stated 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 [141]. This resulted in research by the NRC which is reported in RIL-1002 , which states that:

4-40

Appendix C describes six different SFMEA [software FMEA] 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.

Below is a short (i.e., not inclusive) list of references that show issues or deficiencies with FMEAs that NRC staff and inspectors could consider that demonstrate additional methods of determining appropriate failure modes:

• NRC Information Notice 1997-081 [145] is not digital specific, nor EDD specific, but rather relates to failures under certain conditions where a component would not operate as it should under certain circumstances.

• L. Betancourt, et. al., [146] recognize that finding faults in CPLDs through FMEA is akin to searching for a needle in a haystack. Although FMEAs have been successfully used for analyzing traditional hardware applying the technique to Complex Logic does not yield similar benefits.

• RIL-1002 [112] reviewed 11 sets of DI&C system failure modes. These failure mode sets are not supported by documented public consensus and are not endorsed by any accepted standards. The staffs analysis in the RIL found that a synthesized set of system level DI&C failure modes may not be helpful for determining the level of safety of a DI&C safety system. In addition, a limitation of the FMEA is that a digital system may experience unintended or undesired behaviors without the occurrence of a failure. The RIL recognizes that it is unlikely that anyone can identify a complete set of failure modes that can occur in a moderately complex digital system

• EPRI 300200509 [147] concludes that FMEA has its place, but also The FMEA methods are well suited for postulating single failures and their effects on other systems, sub-systems or components, and they can make use of the proposed failure taxonomy provided in Attachment B. However, these methods are not well suited for use in identifying misbehaviors or hazards beyond single failures, such a multiple hardware failures or unintended interactions of hardware and software components.

• The FAA System Safety Handbook, Chapter 8 [148] considers FMEA and FMEC as means of reliability analysis versus safety analysis.

These issues apply more to some uses of FMEA than others. For example, in the case of using an FMEA to determine if there are new failure modes present at the system level, a review may find that new or potentially new failure modes at the level of the EDD or component are bounded.

For example, although some new failure modes had been identified at the I&C level in ORNL/TM-2010/32 [132], these new failure modes did not create new failure modes at the system level.

However even if certain types of failures are already considered at the system level, critical characteristics should still be utilized to prevent their occurrence. This particular type of bounding also does not address CCF concerns.

In conclusion, FMEAs are used at different levels and for different purposes and are utilized within the NRCs regulatory infrastructure and in industry. In some applications using the FMEA of an EDD as input to the FMEA for the system or considering them together could be useful. However, an FMEA has limited utility for assessing systemic causes in newer digital configurations.

Specifically, systemic causes have pervasive effects whereas an FMEA is oriented to point-failures (localized, isolatable) as in the case of hardware items. Therefore, an FMEA may not be as robust in the discovery of (or confirming absence of) system-internal hazards rooted in system development activities. Multiple failures may be more important than single failures. Software failures are difficult to identify, so the effects are hard to predict. In these cases, modern methods 4-41

and tools designed to deal with more complex and connected systems may be needed for some applications of FMEA.

4.10 Graded Approach A graded approach accounts for the characteristics of the risk relevant to a components function and application in a system. A number of parameters can be identified that together describe the nature of the hazardous situation when safety-related components/systems fail or are not available. Several parameters are identified that, when combined, demonstrate an acceptable design to meet the safety functions of the system. Attributes or metrics that can be applied to grade the classification of the EDD could be based on several factors, including complexity/simplicity, redundancy, diversity, safety function of the EDD, failure modes/hazards analysis, etc. Each of the characteristicsdigital content, functionality, configurability, classification, and consequences of failurecan provide a basis for guidance on the acceptability of the design and functioning of the EDD. This would start with the current/default position for regulating the use of EDDs and could be tailored to specific component-based guidance.

The regulatory basis for using a graded approach based on safety significance derives from 10 CFR 50 Appendix B, which states, The quality assurance program shall provide control over activities affecting the quality of the identified structures, systems and components, to an extent consistent with their importance to safety.

The CGD process (i.e., EPRI TR-106439) is key in the use of EDDs, as most components are not developed under a 10 CFR 50 Appendix B process. A risk-informed approach was proposed in 10 CFR 50.69 and RG 1.174. As described below in observations, a risk-informed approach could also be used for CGD of simple digital devices.

he term graded approach could refer to the selective assignment of QA elements with which the software must comply based on its assigned quality classification, or it can refer to the grading of components based on risk. For this assessment, a graded approach is based on the latterrisk to the plant. Thus, a graded approach would tailor the efforts requirements according to the complexity of the system and application and the importance to safety and plant economics. NRC Inspection Procedure 38703 [142] states:

The application of graded quality assurance to the CGI dedication process should include consideration of the item's importance to safety and the factors specific to the item being procured. Certain items and services may require extensive controls throughout all stages of development while others may require only a limited quality assurance involvement in selected phases of development.

There are two factors to be considered in an EDDthe component in which it is embedded, and the sensor/actuator heart of the EDD. Sensors interact with the plants physical processes to measure process variables such as temperature, pressure, and flow. When sensors are embedded in components, they may provide surveillance and diagnostic capabilities that monitor process variables for abnormalities. Actuators such as valves and motors physically operate plant components to adjust physical processes to optimize plant performance for efficiency, safety, and/or shutdown. Actuator status indicators can also visually reflect automatic or manual control actions, such as the switching on or off of a motor or the opening or closing of a valve.

Devices vary widely in terms of functionality, complexity, and testability. EDDs serve many functions in components used in NPPsmonitoring, diagnostics, and/or control. The functionality provided by embedded systems is shifting from hardware to software. The functionality of 4-42

embedded systems is not solely developed by just one manufacturer, but it is host to multiple parties. In addition, embedded systems are increasingly integrated in networked environments that affect these systems in ways that might not have been foreseen during their construction.

Factors that could be considered for risk-informing the safety classification, level of review, and dedication of EDDs include:

• Complexity / simplicity

• Classification / quality

• Functionality

• Consequences of failure

• Configurability

• Redundancy

• Dependability

• Diversity

• Defense-in-depth

• Self-diagnostics

• Testing A risk-informed process would adjust the level of rigor associated with the design to the safety significance of the equipment.

A two legged approach is expected in the demonstration of the suitability of a smart device for a nuclear application in the UK. The two legs consist of:

• Production excellence (PE), which is a demonstration of excellence in all aspects of production from the initial specification through to the finally commissioned system;

• Independent confidence building measures (ICBMs), which provide an independent and thorough assessment of the safety systems fitness for purpose.

The ICBMs provide a graded approach according to class. Examples of ICBMs at the highest class (Class 1/pfd = 10-3) are:

• Instrument type tests

• Examination, inspection, maintenance and test records

• Proof test records

• Commissioning tests

• Hardware reliability analysis

• Prior use

• Supplier pedigree

• Independent certification

• Independent review of suppliers standards and procedures

• Independent functional safety assessment

• Independent review of tools

• Static analysis

• Dynamic analysis

• Statistical testing 4-43

ONR TAG-046, with respect to a graded approach, stresses that:

It is important to stress that the independent confidence building measures should be applied only to the finally delivered product - ie after completion of the manufacturers verification and validation, including the completion of any compensating activities. The duty-holder may, however, be able to make a case for applying techniques to code that has completed the manufacturers independent verification.

One key part of the regulatory process, upon which NS-TAST-GD-046 [126] is based, is that the grading allowed in the guidance impacts the reliability claim that the licensee can take for the device. While ONR does use a best estimate PRA (called PSA within their regulatory infrastructure) for certain purposes, when it comes to determining the needed grade of a system, a high confidence value (limited as in Table 1 of the reference) must be used. This means that if one device is implemented at a lower grade, then it may result in others being required to be implemented at a higher grade. However, currently, no such reliability feedback mechanism as a consequence of using a graded approach exists within the NRCs regulatory infrastructure.

From a standards perspective, both the nuclear IEEE (e.g., IEEE Std. 603) and the nuclear IEC (e.g., IEC 61513) standards suites use system-level requirements that are not easy synthesized down to component- or EDD-level requirements. The area of reliability is a good example of this.

In both nuclear standards suites, the system-level requirement for reliability is the single failure criterion. This requirement assumes some minimum level of reliability of the individual components, but it does not provide a clear requirement. There is no clear target for the reliability of the individual components. The situation is similar for other system-level requirements related to system architecture, such as redundancy, independence, and diversity. Of particular note is the area of CCF, which assumes that the systematic integrity of the individual components is insufficient, thus defeating redundant architectures. It remains a challenge to translate the IEEE and IEC system-level requirements related to this topic into component-level requirements.

Considering the complexity, classification, functionality, configurability, and consequence of failure is an approach that could be considered. Those countries with multiple safety classifications incorporate function or consequence into the safety classification. NASA uses a consequence-based approach. The IAEAs approach to the safety classification of SSCs considers safety classification (important to safety and not important to safety), functionality, and consequences that result if the function fails when it is required to perform, and it is also related to the consequences in the event of a spurious actuation [173]. DoD relates consequence to a condition, event, operation, process, or item whose mishap severity consequence is either marginal or negligible (safety-related) or a condition, event, operation, process, or item whose mishap severity consequence is either catastrophic or critical (safety-critical). EPRI recommends using a safety-significance-based graded approach that considers the context of the I&C in the plant, the likelihood of failure, and the failure consequences in assessing the adequacy of the implemented preventive and mitigative measures.

Each of these factors are addressed below and could be combined in some manner to provide a structured, defensible graded approach for the use of EDDs.

4.10.1 Complexity / Simplicity While there is no consensus on the best way to quantitatively measure complexity, there is broad agreement that simplicity helps ensure high dependability, and it is expected that a qualitative assessment of platform and functional simplicity may be practical [150]. The simplicity of critical functions is fundamental in achieving reliable components and systems.

4-44

The complexity of the EDD, and whether it has a processor, and if so, the type of processor it has, all also impact the level of potential risk.

Other factors that could affect the complexity of the device include (1) whether the code manages the hardware directly, if there is a distinct operating system, if interrupts are used for device inputs and outputs and timing, and the size of the code (number of lines).

Changes that increase complexity should be considered very carefully. For example, adding automated self-testing features to the relatively simple safety function logic may add complexity to thefunctionality, with corresponding adverse effects on several aspects of development. More specifically, the requirements can become more complicated, making it more difficult to specify with high confidence that they were complete, correct, unambiguous, etc. With added complexity, it becomes more difficult to anticipate, specify, and test all the potential abnormal and faulted conditions that the system might observe, etc.

4.10.1.1 Complexity There are many definitions of complexity with the common theme of difficult to understand and verify.

IEEE defines complexity as the degree to which a system or component has a design or implementation that is difficult to understand and verify [150].

The UK Ministry of Defence states that a system is classified as complex if its behavior cannot be verified by exhaustive testing [151].

The IEEE defines complexity as the degree to which a system or component has a design or implementation that is difficult to understand and verify [150, 152].

EPRIs digital engineering guide (DEG) [154] addresses complexity in terms of configurability.

This measure of complexity is based on the degree of configurability and how configurable a system or component is in the field. A key aspect of EPRIs digital engineering guide is grading engineering processes by complexity. However, this complexity is not in terms of the absolute complexity of the functions being performed by the device, but rather by the degree of configurability left for the integrator to perform or for creation of application-specific code.

Therefore, a device could ultimately achieve the exact same function, but in one case, more design was performed by the OEM, leaving only parameter setting and connections to the integrator or licensee, and in the other case, parts of the design were left to the integrator or licensee. Hypothetically this could result in identical devices, but the DEG would treat each case very differently.

Part of the appeal of smart sensors is that they allow integration without the need to understand the particulars of the sensors design. For example, for a smart sensor, purchasers rely on the OEM code and hardware within the sensor itself to perform functionality, such as analog-to-digital (A/D) conversion, filtering, and various checks on the signal being performed in the device itself.

Furthermore, the software and hardware are created by the same company that created the sensor itself. However, the purchasers understanding of the complexity of the device and any potential consequences would be limited.

4-45

For manufacturers, higher complexity may mean a higher probability of errors in the design of the EDD. For users, higher complexity may lead to a greater probability of errors when setting up and maintaining an EDD. (Note that this also applies to I&C systems.)

The issue related to EDDs is that of complexity. For very simple and very old systems, the failure modes were relatively straightforward. As complexity increases, which can be the case in EDDs, using methods designed for more complex systems makes sense. When discussing the technical evaluation, EPRI TR-106439 supports this concept, stating that a step is to determine how complex the device and the software are, which sets the levels of scrutiny for many aspects of the assessment. However, the additional digital oriented guidance in EPRI TR-106439 does not discuss FMEA nearly so much as it discusses a broader failure analysis in order to correctly identify requirements and critical characteristics.

A risk-based/graded approach would evaluate the complexity of the EDD with its level adjusted accordingly.

4.10.1.2 Simplicity Simplicitythe converse of complexitymay provide a more useful attribute.

IEEE defines simplicity as the degree to which a system or component has a design and implementation that is straightforward and easy to understand [150, 152]. IEEE also recognizes that All else being equal, a simpler system will be more reliable [155].

RIS 1002 [112] defines simplicity (by changing the negative expression of complexity to positive) as the degree to which a system or component functionality, design or implementation can be understood and verified.

For simplicity, IEEE Std. 7-4.3.2-2016 [26] states, it is recognized that simplicity is not a measurable characteristic of a safety system. As such, no acceptable degree of simplicity can be established for these systems however, measures should be taken to avoid unnecessary complexity. Added complexity associated with the performance of functions not directly related to the safety function may introduce design errors or create system hazards. As an example, the added the complexity resulting from self-test and self-diagnostics can improve safety and reliability. A balanced approach is required between the hazards associated with adding functionality and the benefits those functions provide. All functions allocated to safety systems shall be justified, documented and analyzed to determine if hazards are introduced to the safety system.

This shows that any added features to the EDDs, such as human systems integration (HSI), will result in additional risk of failures not associated with the original equipment when used by operators and maintenance personnel.

The question still remains as how to measure simplicity. A review by EPRI on Rosemount transmitters [156] provides qualitative metrics on assessing simplicity:

• No internal looping

• Embedded software is very small in size (less than 8K lines of executable code) 4-46

• Hardware is relatively simple

• Limited diagnostics (helps limit the size and complexity of the software)

• A single version of the software used for all identical EDDs These qualitative metrics and the overall simplicity of the device strengthen the use of historical data in evaluating the adequacy of the transmitter.

To have very high simplicity in a design, the component (or system) should:

• Contain simple priority commands

• Have minimized device functionality as much as possible

• Demonstrate 100% testability Appendix B of CSA N290.14-15 [94] provides guidance for determining an items complexity.

That appendix must be used in conjunction with the mature product method. A good summary of the approach to determining the complexity of a digital item is show in Table 4-6:

Table 4-6 Determination of Software Complexity [94]

Complexity categories Complexity level Interface complexity Lines of code Internal modules index Low < 1000 < 20 <5 Medium 1000-9999 20-199 5-9 High 10,000-99,999 200-1999 10-29 Very high 100,000 2000 30 The proof-through-testing method can only be used for category 3 applications that involve items that fit into the low complexity designation as determined by Appendix B of CSA N290.14-15.

This method involves running enough testing on an item to provide confidence that it operates correctly. The minimum successful test executions for a category 3 low complexity item is 250, and the minimum successful test hours is 100.

The preponderance-of-evidence method may be used for category 1, 2, or 3; this approach is dependent on engineering judgement. This method considers the following elements: proven-in-use arguments, partial compliance with applicable industry standards, evidence from a previous qualification, complementary testing, analysis of the candidate product, and use of verified software modules, objects, libraries, or components. A case is built to justify the use of a digital item based on any or all of these elements. This method is the most like the approach typically used in the United States based on EPRI TR-106439. This method also has some similarities to the approach prescribed in IEC 62671.

The code for smart sensors used in the United Kingdom has a number of distinctive features

[111]:

4-47

• Assembly language was used in early devices, but C code is found in most modern smart devices.

• The code size is small; there are tens of thousands of lines of code, although this may increase significantly if the instrument includes fieldbus or other types of communication protocols. (A discussion of communication protocols is provided in Appendix E of this report.)

• There is no distinct OS; the code manages the hardware directly.

• Interrupts are used for device I/O and timing, so there are concurrent code threads.

These features are not surprising for small, embedded systems. The benefit of using EDDs compared to a system is that they are simple enough to be amenable to a wide variety of techniques while still providing real, practical examples for which the outcome of the analysis has value.

From the information gathered, a risk-informed / graded approach for the classification of EDDs was evaluated. A risk-informed / graded approach would eliminate requirements for low safety significant uses of EDDs and would have little adverse effect on safety while reducing unnecessary regulatory burden. An FMEA may be suitable to fully evaluate simple devices and could provide insights into more complex devices. That is, if the EDD has been designed to accomplish only one clearly defined function or only a very narrow range of functions, the complexity is low, and including V&V efforts as part of a components quality design process should minimize the likelihood of a latent fault. In contrast, if the device is designed so that it is reprogrammable after manufacturing, or if the device functions can be altered in a general way so that it performs a conceptually different function, it would not be considered a simple device. To be deemed a simple device only pre-defined parameters can be configurable by users. These variables could be used in defining a classification of EDDs.

In conclusion, simplicity may be measured primarily through executable code size, functionality, and testability. These can be useful in making guidance on a graded approach.

4.10.2 Classification In the nuclear power industry I&C systems have been historically classified according to safety significance. This classification approach is based on a deterministic assessment of the system functions ability to assure safety. Safety classification is well established, and the scope of this project does not involve replacement or modification of the current structure. Nevertheless, safety significance is a key characteristic of I&C systems at NPPs, and there are notable variations within international safety classifications. A risk informed/graded approach to providing guidance to assess the risk of EDDs would require insights into a classification scheme for components and subcomponents, such as an EDD. Therefore, this section provides an overview of the prevailing safety classification approaches employed by the international nuclear power industry.

Safety classification is one of the fundamental safety concepts used to ensure that NPPs pose minimal risk to public safety. The classification of SSCs identifies the importance to safety for that SSC and the consequence of its failure. The classification of SSCs is closely related to the plant states and the postulated initiating events.

4-48

The term plant states can refer to the events to be considered for plant operation normal operating states and anticipated operational occurrences [AOOs], or the term can be used to identify the status of the plant to be reached after an event has occurredphysical conditions such as pressure, temperature, radiation, etc.

The classification of safety systems between countries, organizations, and even within the same organization may have a common term, but the terms may or may not have different meanings.

For example, within the NRC, there are examples of terminology differences and overlaps regarding coverage for safety-related, regulatory treatment of non-safety systems (RTNSS),

safety-significant systems requiring special treatment, and important-to-safety SSCs. If a component is classified as RISC-2, it is in a nonsafety-related system that performs a safety-significant function.

10 CFR 50 establishes a classification approach for SSCs in a nuclear facility. 10 CFR 50.2 defines safety-related SSCs in terms of reliance on those SSCs to remain functional during and after design basis events to assure (1) the integrity of the reactor coolant pressure boundary, (2) the capability to shut down the reactor and maintain a safe shutdown condition, and (3) the capability to prevent or mitigate the consequence of accidents that could result in unacceptable offsite exposures.

For electrical and I&C equipment, 10 CFR 50.49 documents the requirements associated with environmental qualification of electric equipment important to safety for nuclear power plants. The scope of the electric equipment important-to-safety covered by this regulation is safety-related systems, those nonsafety-related systems whose failure under postulated environmental conditions could prevent satisfactory accomplishment of safety functions, and certain post-accident monitoring systems.

NRCs regulatory guidance for classification for EDDs would be the same as for systems: safety or nonsafety, although in some instances the classification could be at the subcomponent level.

This allows individual pieces parts, like a spring or bonnet to be classified at a lower level than the component it is a part of. The U.S. nuclear industry has a clearly defined level of rigor at the system level, but because the framework only contains two categories, the level of rigor at the individual component level is vague. A prime example of this is in commercial-grade dedication of digital components. In the guidance and standards associated with this type of activity, it is commonly stated that the level of rigor should be determined based on the safety significance and complexity of the device [157]. EPRI 107339 [77] states that the safety significance and complexity of the equipment and the application determine the scope of activities required to accept the equipment this is referred to as a graded approach.

IEEE identifies I&C systems that are important to safety as Class 1E equipment. More specifically, IEEE Std. 323-2003 [158] defines Class 1E as the safety classification of the electric equipment and systems that are essential to emergency reactor shutdown, containment isolation, reactor core cooling, and containment and reactor heat removal, or are otherwise essential in preventing significant release of radioactive material to the environment.

In addition to the traditional deterministic classification approach, a risk-informed approach to safety classification has been established in 10 CFR 50.69. Specifically, SSCs are divided into risk-informed safety classes based on both deterministic safety classification and probabilistic significance to plant safety. In this classification approach, insight from a probabilistic risk assessment (PRA) on the safety significance of the function performed by a system is captured based on its contribution toward reducing the risk of release of radioactive material to the 4-49

environment. 10 CFR 50.69 defines a safety-significant function as a function whose degradation or loss could result in a significant adverse effect on defense-in-depth, safety margin, or risk.

10 CFR 50.69 applies a risk-informed categorization and treatment of SSCs into four risk-informed safety classes (RISCs) for passive advanced light water reactors:

RISC-1 SSCs: safety-related SSCs that perform safety significant functions.

RISC-2 SSCs: nonsafety-related SSCs that perform safety -significant functions.

RISC-3 SSCs: safety-related SSCs that perform low safety significant functions.

RISC-4 SSCs: nonsafety-related SSCs that perform low safety significant functions.

A safety significant function is a function whose degradation or loss could result in a significant adverse effect on defense-in-depth, safety margin, or risk.

The RTNSS process applies broadly to those nonsafety-related SSCs that perform risk-significant functions and therefore are candidates for regulatory oversight. The RTNSS process uses the following five criteria to determine those SSC functions:

1. SSC functions relied on to meet deterministic NRC performance requirements such as those set forth in 10 CFR 50.62 for mitigating anticipated transients without scram (ATWS) and in 10 CFR 50.63 for station blackout (SBO).

2. SSC functions relied on to ensure long-term safety (beyond 72 hours8.333333e-4 days <br />0.02 hours <br />1.190476e-4 weeks <br />2.7396e-5 months <br />) and to address seismic events.

3. SSC functions relied on under power-operating and shutdown conditions to meet the Commissions safety goal guidelines of a core damage frequency (CDF) of less than 1x10-4 each reactor year and a large release frequency (LRF) of less than 1x10-6 each reactor year.

4. SSC functions needed to meet the containment performance goal, including containment bypass, during severe accidents.

5. SSC functions relied on to prevent significant adverse systems interactions.

The Regulator Task Force on Safety Critical Software (TF SCS) for nuclear reactors is comprised of international nuclear regulators and authorized technical support organizations. Although the NRC is not a member of the TF SCS, the NRC staff have participated in meetings and have documented this participation in NUREG/IA-0463 [179]. A common position of those participating in the task force is as follows:

For a smart sensor/actuator, the licensee shall define the safety class, which shall be the same as the class of the system in which the smart sensor/actuator is embedded unless justified otherwise.

Using lessons learned from how other regulators, industries, and countries are addressing the regulation and use of EDDs requires an understanding of how the devices are classified in terms of safety. The World Nuclear Associations task force on digital I&C [161] identified the following difficulties in classifying the I&C safety functions:

4-50

o Inconsistency between international standards and local regulations o Ambiguous requirements for safety classification o Incomplete rules for I&C function categorization o Inconsistent requirements for systems provided specifically as diverse backup to protection systems A summary table of classification grades for systems is provided in Table 4-7. The data in this table is based on information from several organizations [159, 160, 161, 162]. The table does not represent precise relationships among the various categories in the classification of systems, but rather, it provides a qualitative assessment of the relative binning. While the table does not constitute a high-fidelity mapping of the classes and categories, it is intended to provide a general indication of the approximate relationship among the classification approaches. The summary table shows that the classification is not standard between countries and that the classifications and require interpretation by vendors and utilities. Therefore, classification based the methods used in other countries could be challenging to extend to U.S. regulations. However, lessons could be learned from other classification systems that may align with NRC regulations. For example the NRC may be uncomfortable with using reasoning for class 3 systems in the UK classification in safety-related systems, but class 1 systems might be acceptable for any safety related system. Similarly, the classification using IEC SILs and the ability to have different SILs for the same component depending upon its application and having separate hardware and software SILs for the same device may provide insights into providing guidance for EDDs at the individual component level.

The United States has the most coarsely graduated classification schemesafety-related/not safety-relatedand a more finely graduated scheme based on 10CFR50.69RISC values. GDC 1quality standards and records, and GDC 21protection system reliability and testability, provide some flexibility in that the systems important to safety, including the protection system, shall be designed fabricated, erected, and tested to quality standards commensurate with the importance of the safety functions to be performed. However, when ordering parts from vendors for nuclear facilities, licensees order safety or nonsafety parts; other designations are confusing to vendors (e.g., the DOE safety class designations, based on the experience of the ORNL researchers).

The critical characteristics are identifiable and measurable attributes and variables of a CGI, which once selected to be verified, provide reasonable assurance that the item received is the item specified [73]. When applied to NPPs licensed pursuant to 10 CFR Part 50, critical characteristics are those important design, material, and performance characteristics of a CGI that, once verified, will provide reasonable assurance that the item will perform its intended safety function [163].

If the classification systems in use or proposed based on consequences were tailored to components, then the EDDs that monitor or provide diagnoses of the health of the component would likely be in the lowest classification category. In addition, because the consequences of a single failure are low, the classification category, even for those EDDs that provide control functions, would not be very high if the likelihood of a CCF were considered low. If communication is added, then the device now behaves like a system, and CCFs are a potential contributor.

4-51

NUREG/CR-6421 [164] uses a classification scheme based on the importance to safety of the system in which the product will be used. The suggested number of categories is larger than two (safety and nonsafety) and less than five. The suggested safety categories of A, B, C, and unclassified in the NUREG/CR are derived from a predecessor to IEC 61226 and RG 1.97.

Table 4-7 Comparative NPP I&C Safety Classifications [159, 160, 161, 162, 173]

National or international Safety classification grade standard Not important to Systems important to safety safety U.S. (NRC)

Not safety-related Safety-related (Nonsafety)

Systems important to safety Systems not IAEA NS-G-1.3 Safety system Safety-related system important to safety Systems important to safety Systems not IAEA SSG-39 Safety system Safety-related system important to safety IAEA SSG- Function Category A Category B Category C Non-classified 30 System Class 1 Class 2 Class 3 IEC 61508 IEC SIL 3/4 IEC SIL 2 IEC SIL 1 IEC SIL 0 IEC 61226 Category A Category B Category C Unclassified IEC 61513 Class 1 Class 2 Class 3 Canada Category 1 Category 2 Category 3 Category 4 European utility F1A F1B (automatic F2 Not classified requirements (EUR) (automatic) and manual) time dependent Finland Class 2 Class 3 EYT/ STUK EYT France N4 1E 2E SH Important to Systems not safety important to safety France F1A F1B F2 Non classified Germany Category A Category B Category C Non-classified Japan PS1/MS1 PS2/MS2 PS3/MS3 Non-nuclear safety India 1A 1B 1C NINS Korea IC-1 IC-2 IC-3 Russia Class 2 Class 3 Class 4 Switzerland 1 2 3 Non-classified UK Class 1 Class 2 Class 3 Not classified EPRI 1025243, Rev. 1 [165], endorsed by RG 1.231 [166] (with exceptions), uses two functional safety classifications for the acceptance of commercial-grade computer programssafety-related and non-safety-related. A subset of non-safety-related items may be classified as augmented quality. EPRI 3002002289 [167], which is not endorsed by RG 1.231, supersedes EPRI 1025243.

4-52

As with hardware, when a computer program having the functional safety classification of safety-related is furnished as a commercial item, it should be procured as commercial grade and dedicated for use as a basic component in a safety-related application.

EPRI NP-6895 [168] documents the functional safety classification process for plant SSCs in detail. The safety classification of computer programs is performed to determine if any function(s) performed by the computer program could prevent associated SSCs from accomplishing their safety-related functions. If a postulated failure of a computer program (failure of a function performed by the computer program) could impact the capability of an associated SSC to perform its safety-related function(s), then the computer program is considered to be safety-related.

Therefore, functions of a computer program associated with SSCs could be identified as part of the safety classification process for computer programs.

The U.S. Department of Energy (DOE) uses three categories of SSCs plus an additional category that does not involve equipment: safety class, safety significant, non-safety, and specific administrative controls. None of these categories correspond to the definitions used by NRC.

The NEET project proposed a four-category classification structure:

• No impact

• Low impact

• High impact

• Critical impact The classification structure is based on the high-level characterization of potential impact of failure of an EDD on an instruments performance of its fundamental function. The classification framework can provide a means of preprocessing information about equipment with an EDD to support a determination of when and how a diversity and defense-in-depth analysis should be performed. This project is complementary to and not duplicative of the current NRC EDD project.

For the FAA, software is classified based on how an error affects the software and the system containing the software [169]. The software classification defines the rigor necessary to demonstrate compliance with software development requirements.

NASA uses a software classification system that is unique to the industry in that embedded system software, support software, software tools, and routine office software are all covered by the single classification system [170].

The railway industry uses a probabilistic risk-based process for safety-related system and software development [171].

Another name for safety categorization could be risk index. NASA separates the system risk, which specifies the hazard risk for the system as a whole. NASAs Software Hazard Risk Index is given in Table 4-8. The level of risk relates directly to the amount of analysis and testing that should be applied to the software.

NASAs hazard prioritization is important for determining allocation of resources and acceptance of risk. Hazards with the highest risk of Level 1 are not permitted in a system design. A system design exhibiting 1 for hazard risk level must be redesigned to eliminate the hazard. The lowest risk levels of "5" and above require minimal, if any, safety analysis or controls. For risk levels 2, 3, and 4, the amount of safety analysis required increases with the level of risk.

4-53

Table 4-8 Software Hazard Risk Index [70]

Software hazard risk index Suggested criteria 1 High risk: significant analysis and testing resources 2 Medium risk: requirements and design analysis and in-depth testing required 3-4 Moderate risk: high level analysis and testing acceptable with management approval 5 Low risk: acceptable EPRI 1025243 uses two functional safety classifications: safety-related and non-safety-related. A subset of non-safety-related items may be classified as augmented quality.

EPRI NP-6895 documents the functional safety classification process for plant SSCs in detail.

The safety classification of computer programs is performed to determine if any function(s) performed by the computer program could prevent associated SSCs from performing their safety-related functions. If a postulated failure of a computer program (failure of a function performed by the computer program) could impact the ability of an associated SSC to perform its safety-related function(s), the computer program is safety-related. Therefore, functions of a computer program associated with SSCs could be identified as part of the safety classification process for computer programs. There are two deterministic methodologies that result in a functional safety classificationone that considers failure modes, and effects and one that considers the impact that the computer software has on associated SSCs.

The primary contributors to assuring adequate protection will likely be different for safety and non-safety equipment for several reasons. EPRI succinctly discusses the differences between safety and nonsafety equipment in the passage shown below [149]:

Safety Systems Safety equipment have nuclear quality assurance pedigree, including qualification testing, with corresponding documentation. Software development practices and documentation will be in accordance with relevant nuclear safety standards and guidance. The system functionality will tend to be relatively simple, permitting high test coverage and a lower likelihood of requirements and design errors, but the operating experience may be limited, especially for systems developed specifically for nuclear safety applications. Safety equipment will also benefit from design requirements for separation and independence, which help decrease the likelihood of CCF. For safety systems, coping analysis is typically done using best estimate assumptions, ostensibly because its nuclear safety pedigree is adequate assurance that the likelihood of a CCF is quite low.

Non-Safety Systems In contrast, non-safety equipment is likely to be commercial grade, for which development practices, qualification testing and documentation vary widely. Operating experience may prove far more useful, provided it is sufficient, successful, relevant to the intended application and adequately documented. Mature commercial systems are likely to have defensive design measures that have been shown to be effective in avoiding and eliminating potential triggers, because of efforts to address problems and increase dependability as the product evolved. Nonsafety systems are often 4-54

of lesser risk significance, so for them, reasonable assurance and adequate protection may be achievable at a more modest level than for safety equipment. For non-safety systems, coping analysis using best-estimate methods may be justifiable on the basis of its strong defensive design measures and lesser risk significance.

The IAEA defines a deterministic safety classification for I&C systems in IAEA Safety Guide NS-G-1.3 [172]. The classification approach involves assigning a safety class based on the importance to safety of the function performed by the I&C system. Thus, the safety guide divides I&C systems into systems important to safety and systems not important to safety. An I&C system important to safety is one whose malfunction or failure could lead to unacceptable radiation exposure of the site personnel or members of the public. Systems important to safety are further subdivided into safety systems and safety-related systems. Safety systems perform protective functions, while safety-related systems are those I&C systems that perform important functions other than the main protective functions.

IAEAs approach to classification typically begins with categorization of the functions to be performed by I&C systems, which are assigned to categories according to their importance to safety. The safety importance of a function is related to the consequences that result if the function fails when it is required to perform, and it is also related to the consequences in the event of a spurious actuation [173].

The IAEA classifies the safety class of SSCs based on the severity of consequences of their failures (Table 4-9).

Table 4-9 IAEA Safety Classes of SSCs Based on Consequence of Failure [174]

Safety class Description 1 Any SSC whose failure would lead to consequences of high severity 2 Any SSC whose failure would lead to consequences of medium severity 3 Any SSC whose failure would lead to consequences of low severity The standards issued by the IEC adhere to the safety principles established by the IAEA. The IAEA and IEC approaches that start with the classification of the functions and then assign categories according to their importance to safety agree well with the use of a graded approach.

However, the IEC refines the safety classification approach established by the IAEA by resolving the important to safety class based on a three-tiered approach to identifying both I&C systems and the functions they perform. The IEC safety classification approach is based on the IAEA safety philosophy and the plant design basis. All SSCs that are items important to safety, including software for digital I&C systems, are classified on the basis of their function and their significance with regard to safety. Basically, I&C systems that provide functions to cope with postulated initiating events (PIEs) are classed in the highest safety class, whereas less important functions and equipment are assigned to lower safety classes. The IECs highest safety class is similar to the NRCs definition of safety-related SSCs as those SSCs that are relied upon to remain functional during and following design basis events.

IEC standards provide criteria for assignment of functions to safety categories and establish design requirements for the corresponding I&C systems and equipment. In IEC 61513 [79], the general requirements for I&C systems important to safety are established in terms of safety classes. I&C systems are assigned to one of three safety classesClass 1, Class 2, and Class 4-55

3or they are unclassified based on their main safety function. The determination of classification for safety functions is established in IEC 61226 [175]. This standard classifies functions into three categoriesCategory A, Category B, and Category C. Category A corresponds to functions that play a principal role in achieving or maintaining safety by preventing design basis events from leading to unacceptable consequences. Category B covers functions that play a complementary role to the Category A functions in assuring safety, especially functions required to operate after a nonhazardous stable state has been achieved. Category B also includes functions whose failure could initiate a design basis event or worsen the severity of an event. Category C addresses functions that play an auxiliary or indirect role in the achievement or maintenance of NPP safety. Other functions that do not meet the criteria of the three categories are identified as nonclassified (NC).

IEC 61226 [175] establishes a method to classify I&C systems and equipment according to their importance to safety. The classification of I&C functions depends on their contribution to the prevention and mitigation of PIEs. The resulting classification is then used in IEC 60880 [81] and IEC 62138 [82] to determine relevant specification and design requirements, including qualification requirements for software tools used to develop I&C software and systems important to safety.

IEC categories of I&C functions [177] are:

• Category A: any function that plays a principal role in ensuring nuclear safety

• Category B: any function that makes a significant contribution to nuclear safety

• Category C: any other safety function contributing to nuclear safety IEC 61513 [79] defines the following classes, which are similar to the categories in IEC 61226:

1. Class 1: - any SCC that forms a principal means of fulfilling a Category A safety function

2. Class 2 - any SCC that makes a significant contribution to fulfilling a Category A safety function or forms a principal means of ensuring a Category B safety function

3. Class 3 - any other SCC contributing to a categorized safety function Office for Nuclear Regulation (ONR) TG-046 [126] relates the safety class to the probability of failure on demand for standby and frequency of failure per year for active components. TG-046 states that the safety demonstration of hardware elements of CBSIS [computer-based systems important to safety] should take account of relevant standards. In particular, systems classified as either class 1 or class 2 should follow IEC 60987. Class 3 systems should follow IEC 61508 as a minimum.

By default, EDD/component combinations in those systems with potential safety consequences given their failure (e.g., digital sequencers, sensors, motor control centers, diesel generator sequencers, uninterruptible power supplies) will pose regulatory challenges to implementation.

This is because guidance for classification of components is based on the classification of systems or the safety functions of those systems and not on the consequences of the failure of those components. Thus, an EDD is typically treated as the same safety class as the component, which is the same safety class as the system, regardless of the consequences of failure.

It is unlikely that the failure of a single EDD, even one used for control, would lead to high or medium severity consequences. Consider as an example one of the components likely to have 4-56

an EDDa pump controller. The pump controller used in this example contains a microprocessor, and therefore contains both hardware and software. Pump controllers can be used for managing pump flow and/or pressure, from full off to full on, and may incorporate flow or pressure control via varying pump speed or use of flow or pressure control valves, utilization bypass lines, etc. Digital displays provide access to the performance and condition of the pump and well as other integrated components. Failure modes of the pump controller are not taking corrective action when needed or incorrectly taking action by adjusting pump flow and/or pressure when no action is required. The effect on the system, via the pump, is no flow, low flow, or high flow. Thus, an incorrect response from the pump controller results in the incorrect control of the pump flow and/or pressure for one pump in one flow loop. Failure to correctly respond or an incorrect response from this pump (and its controller) meets the single failure criterion because of redundant pumps in redundant flow loops.

A risk-informed approach allows a finer gradation of classifications than the safety/nonsafety method. Any deviation from this categorization must account for what vendors can provide. For example, a vendor may not be able to provide a RISC-3 component but could deliver a safety-related component or an IEC SIL 2 or 3 component. Some countries assume that an IEC SIL 3 component is comparable to a component designated as safety related, so their licensees can purchase IEC SIL 3 components. However, regulators that accept IEC SIL ratings recognize that certifications to a specific IEC SIL by themselves cannot be used as a basis for qualification because licensees are responsible for what is installed in their plant [176].

It is difficult to correlate safety classifications across agencies, standards, and uses. The NRCs categorization of safety/not safety does not match well with most other agencies and does not lend itself to risk-informing component/system failures. In the nuclear arena, IAEA, Canada, Finland, France, Germany, Japan, India, Switzerland, and the UK have finer granulations of safety classifications. This finer granulation could present a viable risk-informed classification of components/systems.

4.10.3 Functionality Function relates to purpose and could serve as a primary basis for establishing safety classification. For example, UK, Germany, and France relate the safety function of the device to its classification of safety for the SSC whereas India considers the consequences of the failure rather than the function. Much of the guidance on functionality acknowledges the difference between control and non-control functionality. However, a low functionality EDD may still provide a control function. In addition, the functionality of the EDD may be different than the functionality of the device. For example an EDD that only performs diagnostics could be present within a pump without having a control function, or within a sensor without having a monitoring function.

SRP BTP 7-17 [178] states that The safety classification of the hardware and software used to perform automatic self-testing should be equivalent to that of the tested system unless physical, electrical, and communications independence are maintained such that no failure of the test function can inhibit the performance of the safety function. A device with diagnostic or display functionality will need to maintain physical, electrical, and communications independence from the control functionality, otherwise it would need to be considered part of the control functionality or an other auxiliary feature.

NUREG/IA-0463 does not separate the functionality from the classification of the component, but it aligns with Appendix B and Part 21 with the statement unless justified otherwise.

4-57

The first step in the development of a graded approach is to identify the types of functions performed by EDDs and to separate those functions into non-control functions and control functions.

A risk-informed / graded approach based on the functionality of the EDD would evaluate the complexity of the EDD with its function to set the level of review sufficient to reach a safety conclusion. Devices performing simple monitoring, a low functionality with the lowest complexity level, may not require much guidance on software tools or type of digital device. At the other end of the graded approach, existing guidance would apply to those EDDs that perform a control function with more scrutiny if the component performs a safety function. However, the control function assessment could be graded based on its simplicity. Thus, an understanding of the EDDs functionality can be applied to facilitate a graded approach to qualification, testing, and inspections.

Even a device with non-control functionality must demonstrate that its failure would not compromise a safety function, either by demonstrating non-interference or by constructing a safety demonstration that considers the nonsafety functions as if they are safety functions [126].

EDDs that perform self-diagnostics and can alert users to failures or degradations should reduce the failure rate of the NPP. In addition, the operability of the component (i.e., active or on-demand) will influence the likelihood of a failure being detected or not. The use of a watchdog timer could initiate a corrective action given certain software malfunctions.

As defined at the device level (in this case the EDD), this functionality differs significantly from that at the system/plant level. The functions identified in IEC 61226 [175] are very high level and are the measures of quality by which the adequacy of each function in relation to its importance to plant safety is ensured. For example, one of the Category A functions for the I&C system is to shut down the reactor and maintain it in a subcritical state. An initial safety analysis of the specific NPP design is required to be completed prior to the classification of the I&C functions.

Similarly, the fundamental safety functions identified in IAEA NS-R-1 [180] and IAEA SSG-39 [16]

are at the plant level. These functions identify the following fundamental safety functions for an NPP for all plant states: (i) control of reactivity, (ii) removal of heat from the reactor and from the fuel store, and (iii) confinement of radioactive material, shielding against radiation, control of planned radioactive releases, and limitation of accidental radioactive releases.

IAEA recommends that the functions required for fulfilling the main safety functions in all plant states, including modes of normal operation, should be categorized on the basis of their safety significance. These documents acknowledge that at a lower level, the use of digital systems for I&C functions provides advantages that include the flexibility to provide complex functions, improved plant monitoring and improved interfaces with operators, as well as the capability for self-test and self-diagnostics, a better environment to facilitate the feedback of the operating experience based on tremendous capabilities for data recording, small physical size, and minimal cabling needs. Digital systems can include test and self-check functions that improve reliability, and they can provide a means for monitoring the status of the plant to ensure that the required safety functions are fulfilled. The required safety functions are determined based on the NPP design process, and a systematic approach must be required to be followed to allocate these functions to plant SCCs. A risk-informed / graded approach could eliminate or reduce requirements for low safety significant uses of EDDs and would have little adverse effect on safety while reducing unnecessary regulatory burden.

4-58

Software CCF is always a concern for digital systems. The functionality of the EDD will greatly influence the concern of a software CCF. If the functionality is to monitor, provide information, or perform diagnostics, its failure could be more of a nuisance rather than a safety concern.

However a CCF of sensors measuring a process variable could prevent a reactor trip. A risk-informed approach may recognize that there is not an increase in plant risk if used in this way.

Thus, even if the EDD has some limited control function, its failure may or may not be a safety concern.

One method that could be used to assess the risk because of the failure of an EDD would be to evaluate its risk using an FMEA at the component level and as input to a system level FMEA. An FMEA may be applicable for simple devices and could provide insights into more complex devices. If the EDD has been designed to accomplish only one clearly defined function or only a very narrow range of functions, then the complexity is low (i.e. it is a simple device of limited functionality), and V&V efforts on a quality-designed component should minimize the likelihood of a latent fault. Furthermore, if the device is designed so that it is re-programmable after manufacturing or the device functions can be altered in a general way so that it performs a conceptually different function, then it would not be considered a simple device; only pre-defined parameters can be configured by users.

Related to this, an FMEA would evaluate the failure modes from any known hardware and software faults and failures and would also assess how the vendor resolved or addressed each of these known failure modes. The FMEA would evaluate whether these failures affect the functionality of the EDD and whether the vendor has addressed these failures in the user documentation, although the FMEA may not be available.

4.10.4 Configurability Programmablity represents the capability within hardware and software to change; that is, to accept a new set of instructions that alter its behavior. Programmability generally refers to program logic. Configurable logic and flip-flops can be linked together with programmable interconnects. Memory cells control and define (1) the function that the logic performs, and (2) how the logic functions are interconnected. PLDs come in a range of types and sizes, from simple programmable logic devices (SPLDs) to FPGAs.

Configurability represents the extent to which the system/component facilitates selection, setting up and arrangements of its modules to perform I&C tasks. For hardware, configuration methods include connections by wiring, setting jumpers or switches, and inserting modules (on-line or off-line) [34]. Software configuration methods include selecting and setting parameters, programming, inserting software modules, down-loading programs (on-line or off-line), etc. An EDD may be configurable but not programmable, such as one with fixed firmware. Other devices can be configurable and programmable. Thus, configurability, programmability (and complexity) can vary greatly between devices. It is important to note that the ancillary functions that provide configurability must also be evaluated.

In most instances, dedicated devices are typically pre-developed devices with specific functionality. Once the configuration is changed it is not the same as the device that underwent factory acceptance testing or CGD. Therefore, prior to installation its use it would need to be reevaluated.

The configurability or programmability of the EDD represents the extent to which the system/component facilitates selection, setting up and arrangements of its modules to perform 4-59

I&C tasks. Configurability can be either through hardware, such as through the use of wiring, setting jumpers or switches, inserting modules, or through software configuration methods such as selecting and setting parameters, programming, inserting software modules, down-loading programs. IEC 62671 [17] states that restricted configurability applies to devices that can be configured in only very limited ways to select from among relatively few options the manner in which a device will function in its intended application. An HMI can allow increased configurability.

The more complex a device, the greater the potential that it is configurable; reconfigurability increases the likelihood of the device being reused, which in turn increases the potential for the reconfigured device adversely affecting the execution of a safety function [181]. Reconfigurable devices will also necessitate an increase in the level of V&V that should be required.

HMI can significantly increase the capabilities and ease of changing the configurability of the EDD. By separating aspects of the system such as configurable vs. programmable or critical vs.

non-critical functions of the device, it is possible to bound the scope of the dedication process.

The goal is to reduce uncertainty via techniques to provide more supporting evidence for devices that lack pedigree (i.e., a lower RISC or IEC SIL).

Some devices are designed not to be re-programmable after manufacturing; nor can the device functions be altered in a general way so that it performs a conceptually different function. In these types of devices, only predefined parameters can be configured by users.

Examples of types of firmware are listed as follows:

• Non-configurable, non-modifiable firmware: oven controller, diesel generator, pump

• Configurable, nonmodifiable firmware: fire alarm control panel, flow meter, spectrometer

• Modifiable firmware: PLC, PAL, PLA, CPLD, FPGA The engineers at ORNLs HFIR classify devices in two formsconfigurable or modifiableby asking the question can you make changes to the software on the EDD? If changes cannot be made to the software, then it is classified as configurable.

IEC 62671 [17] provides the following guidance for the functions of a candidate device of limited functionality that is configurable and the ancillary functions that provide configurability:

a. The configuration parameters of the primary functions shall be limited in capability to on/off (activate/de-activate) settings or scale-like adjustments such as calibration of process range and output, gain or damping setting, etc.

b. For systems applications of class 1 and 2, configuration protection shall include deliberate design features so that more than one mistake is necessary before an error in setting a configuration parameter is committed.

c. The configuration parameters of the primary functions shall be protected from inadvertent, malicious or unauthorised adjustment in a manner consistent with the overall security plan for the nuclear facility (see 5.4.2 of IEC 61513). This protection shall include password protection if it is supported by the candidate device.

d. Where it is necessary to configure ancillary or superfluous functions so that they cannot interfere with primary functions these configuration parameters shall be protected as in items b) and c).

4-60

e. It shall be possible to check a device after its configuration parameters have been changed to verify that the change has been done correctly.

f. If the device provides operators with display or modify-enabled access to configuration parameters, then the device shall provide enabled access for only those configuration parameters that they require to execute their duties.

g. Where the device provides operators with modify-enabled access to configuration parameters, all operator inputs shall be subject to applicable range and validity checks and or limits appropriate to the application.

h. Where it is required that configuration parameters and any necessary associated logic states be automatically restored following a power failure, whether partial or total, and this property is configurable, these configuration parameters shall be protected as in b) and c).

i. If the device is to operate in a channelized system, provisions shall be in place to ensure that only one channel of the redundant system can be subject to configuration changes at a time.

An objective of EPRIs DEG is to provide a graded approach to engineering activities using applicability, configurability, and consequence of error as key attributes to achieve a level of risk-informed efficiency. EPRIs technology configurability screen is a proxy for the likelihood of error.

As technology configurability increases, so does the likelihood for errors in requirements, design, implementation, operations, and maintenance. The DEG matches the risk as a function of two measures: (1) I&C system or component configurability, and (2) the consequences of an error.

Beyond configurability is programmability. Control devices may be considered to be nonprogrammable or programmable, although both types of devices are programmable to a degree. IEC 61508-4 [182] defines a programmable electronic (PE) device as a component based on computer technology which may be comprised of hardware, software, and of input and/or output units. This term covers microelectronic devices based on one or more central processing units (CPUs) together with associated memories, etc. Examples provided by the IEC for programmable electronic devices include:

• microprocessors,

• micro-controllers,

• programmable controllers,

• ASICs,

• PLCs, and

• other computer-based devices (for example smart sensors, transmitters, actuators).

All CPLDs allow simple design changes through reprogramming, and all commercial CPLD products are re-programmable although not necessarily by the user. With in-system programmable CPLDs, it is even possible to re-configure hardwarean example might be to change a protocol for a communications circuitwithout powering down [184].

Devices can be designed with fixed programming language (FPL) software that cannot be modified by the end-user, or limited variability [programming] language (LVL) that is modified by the end user. The IEC 61508 compliance process does not extend to the application software that resides in LVL devices.

4-61

4.10.5 Consequence Safety-related systems are designed to reduce the frequency or probability of the hazardous event and/or its consequences.

When determining the safety integrity requirements, it should be recognized that when making judgments on the severity of the consequence, only the incremental consequences should be considered. That is, one must determine the increase in the severity of the consequence if the function did not operate compared to that when it operates as intended. This can be done by first considering the consequences if the system fails to operate, and then considering what difference will be made if the mitigation function operates correctly. In considering the consequences that would occur if the system fails to operate, there will usually be a number of outcomes, all with different probabilities to be considered.

The principal consequence that physical barriers are designed to preclude is the uncontrolled release of radioactivity. Thus, for purposes of this review, the term consequence means dose.

The three physical barriers that provide defense-in-depth are:

1. Fuel and clad boundary

2. Reactor coolant system boundary

3. Containment boundary Safety systems are required to mitigate the consequences of accident events. Maintaining the integrity of these three barriers can prevent or mitigate the consequences of an accident event.

In this review, the focus is not at the system level but at the device level (i.e., EDD) and its effect on the system. The objective is to assess the consequences resulting in the action or inaction of an EDD on the component and then to assess the consequences of the components failure on the system. This is different than evaluating the use of the EDD to mitigate the consequences of an accident event. In this use, the definition of safety-related for the EDD based on the system may not correspond to the consequences of its failure.

There are three ways to assess if the failure has an increased consequence:

1. Its failure is modeled in the PRA or FMEA, or via similar tools and its consequences can be calculated.

2. The safety class of the SSC is known (although again, this is based on the system rather than device in a component).

3. Supporting issues, appropriately evaluated, may allow a risk-informed approach for the review and use of EDDs. The quality process (10 CFR 50, Appendix B), very high usage and operating experience outside the nuclear industry (millions of component types with EDDs), completeness of diagnostic coverage, etc. may inform a graded approach on the review and use of EDDs.

4.10.5.1 Device-level risk The proposed use of a graded approach is based on the consequences from the failure of a single device. The proposed consequence-based approach at the device level is similar to the 4-62

NASA-GB-1740.13 grading based on the consequences to the system because the consequences of the device failure are evaluated according to their impact on the system.

At the device level, an EDD with its own independent sensor data and the OS software for the EDD operating on its own time and is thus also independent from other devices. Therefore, from the plants point of reference, the failure of an EDD and its associated component is a single failure that the plant is designed to withstand, so long as it is not a failure of a new type or occurs as a CCF. Such a single failure (again at the device level), based on the plants safety basis, may not have unacceptable consequences.

The use of a graded approach also can provide relief from the design standpoint by relaxing the IEEE SIL 4 requirements for safety SSCs. Based on the guidance in Annex B of IEEE Std. 1012-2004, a risk-based approach could categorize devices with announced failures or with diagnostics as IEEE SIL 1-2 in the opinion of the ORNL researchers. This same approach would categorize devices with unannounced failures anywhere from IEEE SIL 1-4. If there are other devices that monitor the same parameter of interest to the EDD, then the failure of an individual EDD becomes less important.

For EDDs in their current usage, independence is maintained. However, based on foreign reactor usage, IoT, and industry, failures that were previously postulated to be independent on a train or system level may no longer be independent, or the proposed activity introduces a cross-tie or credible CCF. This would change the consequence-based assessment results.

EPRI 3002012755 [184] confirms that faults and misbehaviors in digital I&C systems manifest themselves by the impact they have on controlled equipment. Risk models indicate that controlled equipment has varying degrees of importance relative to events like core damage or lost generation.

In some simple EDDs, the digital-based board does not have the characteristics associated with microprocessor-based systems such as modifiable code, branches or interrupts, decision-making capability, and therefore would not be susceptabilie to lockups, and have significantly less software CCF susceptibility. That is, these EDDs primarily operate as fixed logic devices. Thus, failures are primarily single random hardware failures. However, CCFs, including CCFs due to software, such as the software used to design the device, can still occur.

Although CCFs result from a single cause, they would not all necessarily manifest themselves in all channels simultaneously. For example, if an error occurred in the EDD due to a sensor, processor, or programming error, then the error could be common to all identical EDDs and could thus lead to a CCF. However, all of the EDDs may not be on the same time scale, sensor reading, etc. and therefore would not have the same critical factor leading to failure. Therefore, failures may occur at different times in the different EDDs or not at all.

In addition, the architecture of programmable systems allows them to carry out internal diagnostic testing functions during their on-line operation. If internal faults are revealed before they can result in a failure, then the probability of single localized fault or failure that can ultimately contribute to a CCF is significantly reduced.

The above classes of failure modes (see section 4.8) could also be useful in the review of CCF analyses. Suppose for example that the application software has an algorithmic or arithmetic flaw of some type and that this flaw could be triggered on all channels simultaneously. However, for timing-related failures such as crashes or hang ups, this is not necessarily the case. The 4-63

particular sequence of events that causes a hang up because of a priority inversion on one processor in a multi-channel system might not cause the same event to occur on another processor simply because of the difference in which events were processed. Even in the case of coding flaws that cause memory leaks leading to a processor crash, it is unlikely that memory leaks will cause all processors to fail at precisely the same time. However, non-concurrent triggers still need to be evaluated on a case-by-case basis and the applicant/licensee should technically justify why a non-concurrent trigger is not applicable for a given EDD design/configuration.

A four-category consequence-based classification structure was proposed by a research project sponsored by the DOE NEET program [118]. The proposed structure involves four classes:

• No impact

• Low impact

• High impact

• Critical impact Like classification, consequences must be defined. NRC generally invokes three categories of consequences; two are in regulations (10 CFR 20 and 10 CFR 50.34), and one is in the safety goal policy that provides a quantitative health objective (QHO). The DOE consequence threshold is set for the public, co-located worker (CLW), and facility worker (FW) based on the total effective dose equivalent (TEDE) for the public, TEDE for CLW, and prompt death for FW.

Because EDDs may perform their functions differently than similar components without EDDs, their failure modes and the consequences of their failure may be different. These consequences can be at the individual device level or the CCF level.

Because each EDD is its own component, diagnostics on each individual component could indicate any detectable fault or failure of software or hardware almost immediately. Diagnostics could monitor hardware and software. A watchdog timer could indicate a software lockup.

However, it is important to ensure that failure of an EDD cannot cause another failure or render a safety system unavailable or to spuriously actuate.

This is not to say there will not be a software-related error, which in itself is a potential CCF; it is just that the likelihood of a software CCF is lower because of the diagnostics, independent environments they are interacting with, and independent sensor readings.

The likelihood of a software fault is small, and a trigger is necessary to activate the fault to result in a failure. For an EDD, the likelihood of a software CCF will be largely dependent upon the type of component and how it is used. Independent relays on the same electrical line reading frequency, voltage, or current are likely to read the same values. Components such as valve controllers that read temperature, flow, etc., are more likely to have different input readings. Thus, having individual digital devices acting on independent localized sensor readings can minimize the concern of CCFs for some component types, but it does not eliminate the concern for all types. In addition, internal diagnostics and watchdog timers in the EDD can identify software hang-ups or failures, as well as hardware failures.

The independent application software and independent OS software (based on timing) reduces the CCF risk of multiple EDDs resulting from a concurrent software-related failure. However, external factors such as EMI, electrical, or operating environment factors are potential CCF contributors. For example, the voltage, current, or frequency inputs to an EDD would be the same 4-64

for any EDDs in the same division of power, regardless of distance. EMI would have a sphere of influence around the source and could cause the failure of any EDD within that sphere.

Control devices can be divided into active control devices or on-demand devices. The primary difference is that the failure of an active control device will be evident either through faulty output or diagnostics. The failure of an on-demand device is not known until the device is demanded for service unless the built-in testing/self-diagnostic features could indicate that there is a failure present in the device prior to demanding its service. This is important if other acceptance processes are deemed acceptable such as IEC SIL because they are tied to probability of failure or probability of failure on demand.

4.10.5.2 System-level risk The understanding of risk and how it is managed is paramount to ensuring protection of computer systems.

The ASME/ANS PRA Standard [185] defines the term risk as the probability and consequences of an event, as expressed by the risk triplet, that is the answer to the following three questions:

(a) What can go wrong? (b) How likely is it? (c) What are the consequences if it occurs? (NRC website glossary [186]).

IEC 61226 [175] categorizes the functions for I&C systems based on the consequence of malfunction. IEC 61226 classifies the I&C functions important to safety into categories based on their contribution to the prevention and mitigation of PIE, and to (1) develop requirements consistent with the importance to safety for each category, and (2) to assign specification and design requirements to I&C systems and equipment which perform the classified functions.

Similar to the IEC requirements, IAEA SSG-30 [174] states that The functions required for fulfilling the main safety functions in all plant states, including modes of normal operation, should be categorized on the basis of their safety significance. The severity of consequences is divided into three levelshigh, medium and lowon the basis of the worst consequences that could arise if the function were not performed. The current version of IAEA SSG-30 [174] identifies the relationship between functions credited in the analysis of postulated initiating events and safety categories (Table 4-10).

4-65

Table 4-10 Relationship Between Functions and PIE [174]

Severity of the consequences Functions credited in the if the function is not performed safety assessment High Medium Low Functions to reach the Safety category 1 Safety category 2 Safety category 3 controlled state after AOO Functions to reach the Safety category 1 Safety category 2 Safety category 3 controlled state after design-basis accident (DBA)

Functions to reach and maintain Safety category 2 Safety category 3 Safety category 3 a safe state (transfer from controlled state to safe state)

Functions for the mitigation of Safety category 2 or 3 Not categorized Not categorized consequences of a design extension criterion (DEC) (i.e.,

beyond design-basis accident

[BDBA])

Table 4-10 shows the method specified by SSG-30 for categorization of functions depending on the magnitude of PIE (AOO / DBA / DEC) in relation to the plant states to be reached (controlled state / safe state) and the severity of consequences (high / medium / low) if the related function is not performed. The use of severity levels supports the process for safety categorization of the required functions. To optimize the process, a more detailed level of severity (e.g. by probabilistic values) should be identified.

NASA ties the required software safety review effort to the hazard severity level. The level of effort is related to the criticality of the software and is divided into the following:

Full software safety effort: Systems and subsystems with severe hazards which can escalate to major failures in a very short period of time require the greatest level of safety effort.

Moderate software safety effort: Systems and subsystems which fall into this category typically have either a limited hazard potential or, if they control serious hazards, then the response time for initiating hazard controls to prevent failures is long enough to allow for notification of human operators and for them to respond to the hazardous situation.

Minimum software safety effort: For systems in this category, either the inherent hazard potential of a system is very low or control of the hazard is accomplished by non-software means. Failures of these types of systems are primarily reliability concerns.

For NASA, the scope of the software development and software safety effort is dependent on risk.

Similarly, the review and certification of EDDs is broadly tied to risk through the use of safety and nonsafety classifications. This does not address nonsafety related components whose failure can be risk significant.

4-66

Like IEEE 1012, NASA-GB-1740.13 provides guidance on the types of assurance activities which may be performed during the life-cycle phases of safety-critical software development for the different criticality levels of the software.

The U.S. Department of Defense (DoD) assesses and documents risk based on the severity category and probability level of the potential mishap(s) for each hazard across all system modes

[83]. To determine the appropriate severity category as defined in Table 4-11 (MIL-STD-882E, Table I) for a given hazard at a given point in time, the potential for death or injury, environmental impact, or monetary loss is identified. A given hazard may have the potential to affect one or all of these three areas.

Table 4-11 Severity Categories [83]

Severity Description Mishap result criteria category Catastrophic 1 Could result in one or more of the following: death, permanent total disability, irreversible significant environmental impact, or monetary loss equal to or exceeding $10 M.

Critical 2 Could result in one or more of the following: permanent partial disability, injuries or occupational illness that may result in hospitalization of at least three personnel, reversible significant environmental impact, or monetary loss equal to or exceeding $1 M but less than $10 M.

Marginal 3 Could result in one or more of the following: injury or occupational illness resulting in one or more lost work day(s), reversible moderate environmental impact, or monetary loss equal to or exceeding $100 K but less than $1 M.

Negligible 4 Could result in one or more of the following: injury or occupational illness not resulting in a lost workday, minimal environmental impact, or monetary loss less than $100 K.

To determine the appropriate probability level as defined in Table 4-12 (MIL-STD-882E, Table II) for a given hazard at a given point in time, the likelihood of occurrence of a mishap is assessed.

Probability level F is used to document cases in which the hazard is no longer present. No amount of doctrine, training, warning, caution, or Personal Protective Equipment (PPE) can move a mishap probability to level F.

4-67

Table 4-12 Probability Levels [83]

Description Level Specific individual item Fleet or inventory Frequent A Likely to occur often in the life of an item Continuously experienced Probable B Will occur several times in the life of an item Will occur frequently Occasional C Likely to occur sometime in the life of an item Will occur several times Remote D Unlikely, but possible to occur in the life of an Unlikely, but can item reasonably be expected to occur Improbable E So unlikely, it can be assumed occurrence Unlikely to occur, but may not be experienced in the life of an item. possible (The improbable level is generally considered to be less than one in a million)

Eliminated F Incapable of occurrence. This level is used Incapable of occurrence.

when potential hazards are identified and later This level is used when eliminated potential hazards are identified and later eliminated DoD uses MIL-STD-882E to perform and document a subsystem hazard analysis (SSHA) to verify subsystem compliance with requirements to eliminate hazards or reduce the associated risks, to identify previously unidentified hazards associated with the design of subsystems, and to recommend actions necessary to eliminate identified hazards or mitigate their associated risks. At a minimum, the analysis shall not only verify subsystem compliance with requirements to eliminate hazards or reduce the associated risks, but it shall also identify previously unidentified hazards associated with the design of subsystems. Identifying previously unidentified hazards includes ensuring that the implementation of subsystem design requirements and mitigation measures has not introduced any new hazards. It also includes determining the modes of failure, including component failure modes and human errors, single point and common mode failures (i.e., CCFs), the effects when failures occur in subsystem components, and the effects resulting from functional relationships between components and equipment comprising each subsystem.

This process should also include consideration of the potential contribution of subsystem hardware and software events, including those developed by other contractors/sources, COTS software tools, government-off-the-shelf (GOTS) software tools, and modified-off-the-shelf (MOTS) software tools, as well as nondevelopmental items (NDIs), government furnished equipment (GFE) hardware or software, faults, and occurrences such as improper timing.

The goal for the military is to always eliminate the hazard if possible. When a hazard cannot be eliminated, then the associated risk should be reduced to the lowest acceptable level within the constraints of cost, schedule, and performance by applying the system safety design order of precedence, which identifies alternative mitigation approaches and lists them in order of decreasing effectiveness [83].

a) Eliminate hazards through design selection. Ideally, the hazard should be eliminated by selecting a design or material alternative that removes the hazard altogether.

b) Reduce risk through design alteration. If adopting an alternative design change or material to eliminate the hazard is not feasible, consider design changes that reduce the severity and/or the probability of the mishap potential caused by the hazard(s).

4-68

c) Incorporate engineered features or devices. If mitigation of the risk through design alteration is not feasible, reduce the severity or the probability of the mishap potential caused by the hazard(s) using engineered features or devices. In general, engineered features actively interrupt the mishap sequence and devices reduce the risk of a mishap.

d) Provide warning devices. If engineered features and devices are not feasible or do not adequately lower the severity or probability of the mishap potential caused by the hazard, include detection and warning systems to alert personnel to the presence of a hazardous condition or occurrence of a hazardous event.

e) Incorporate signage, procedures, training, and PPE. Where design alternatives, design changes, and engineered features and devices are not feasible and warning devices cannot adequately mitigate the severity or probability of the mishap potential caused by the hazard, incorporate signage, procedures, training, and PPE. Signage includes placards, labels, signs and other visual graphics. Procedures and training should include appropriate warnings and cautions. Procedures may prescribe the use of PPE. For hazards assigned Catastrophic or Critical mishap severity categories, the use of signage, procedures, training, and PPE as the only risk reduction method should be avoided.

The software and review could be classified based on how an error affects the software and system containing the software (see classification).

Redundancy for the use of EDDs could be

1. redundant processors in the same EDD package,

2. two EDDs supporting the same component or function, or

3. the component itself could be redundant either in a bypass line or in a redundant train, each with its own EDD.

EDDs could have internal redundancy, and theoretically, these redundant internals could be diverse. The concern with this arrangement is that the processors could compete (e.g., Byzantine General problem), or they could create an electromagnetic field that could be a likely contributor to CCF for an EDD.

Other means for adding fault tolerance (i.e., redundancy) at the device level would be similar to what is done in other systems: like a valve or pump in a train, an additional bypass line or another component in series with EDDs, placing redundant operating systems in the EDD, or having redundant EDDs to the same component or function. Note that some industries correlate redundancy, or the number of independent protection layers (IPLs), to IEC SILs.

There are a number of recognized methods for determining IEC SILs, such as layer of protection analysis (LOPA), which uses frequency of the event as a basis, or safety layer matrix (SLM),

which uses available information of IPLs as a basis for selection of the SIL for the safety instrumented system (SIS). The DOE standard uses a deterministic methodology (a modified SLM methodology), which is the approved method in ANSI/ISA 84.00.01-2004 [76]. The basis for this modified SLM methodology is that the safety classifications of SSCs are based on documented safety analyses (DSAs), so likelihoods and consequences do not have any further role in SIL determination.

As an example of correlating IPLs to IEC SILs, Appendix B of DOE-STD-1195 [187] correlates the number of IPLs to IEC SILs (Table 4-13) when determining the appropriate SIL for safety 4-69

significant (SS) safety instrumented function (SIFs) for DOE nonreactor nuclear facilities. The target SIL provides design input to a SS SIS that is credited with reducing the risk of a hazardous event by itself or in combination with other features to an acceptable level, as defined in the safety basis documentation.

Table 4-13 SIL Determination Based on IPLs [187]

Number of IPLs IEC SIL 3 1 2 2 1 2 Table 4-13 shows that if only two IPLs are credited in the hazard analysis for a particular event, and one of them is an SS SIS, then the SS SIS target SIL is SIL-2. If three or more IPLs are credited for this scenario, then the SS SIS would have a target SIL of SIL-1.

If two SISs are credited with preventing or mitigating the same event, then one of the SS SISs may be assigned as SIL-1. The second SS SIS would have its SIL determined according to Table 4-13. Both SS SISs can be credited if they meet the following requirements [187]:

• The IPL shall be designed to prevent an event or to mitigate the consequences of an event to a level that is supported by safety basis documents;

• The IPL safety function shall be identified and documented in the safety basis documents of a facility;

• The IPL shall be designed to perform its safety function during normal, abnormal, and design basis accident environmental conditions for which it is required to function; and

• The IPL shall be sufficiently independent so that the failure of one IPL, or of a component or subsystem of an IPL, does not adversely affect the probability of failure of another IPL credited for the same event.

DOE applies the following rules to the selection of SILs:

• If some combination of components or systems is required to function together to complete the safety function, then they are considered as one IPL.

• If an instrumented system has been classified as SS, then regardless of the number of IPLs credited, it shall have a target SIL of no less than SIL-1.

• The SIL determination methodology cannot be used by itself to reduce the classification of a SS SIS to non-safety significant.

The greater the fault tolerance in the system, the lower the SIL requirement. Redundancy would increase fault tolerance, thereby lowering the IEC SIL for an individual component. This combination could be used to assign a higher IEC SIL to a system through a combination of individual devices, or it could be used to incorporate lower IEC SIL components into the system.

4-70

The SIL provides confidence in the design and development of the component. Thus, multiple SIL components can be used to increase the comparable SIL, or lower grade SIL components can be used to maintain the system SIL. Theoretically, 8 SIL-1 components in series could be comparable to a SIL-4 safety level. However, the quality and processing of the SIL-1 component is much lower than that for SIL-2 or SIL-3 components. It is important to remember that the lower IEC SIL-rated device does not have the same quality and pedigree as the higher rated device.

Some industries correlate redundancy, or the number of IPLs or LOPA to IEC SILs. Similarly, adding EDDs to the same component or function may not be a viable solution because of cost and the possibility of having competing EDDs.

The device manufacturer must provide data on the SIL rating with respect to systematic faults.

This information is usually present in the conformity certificate of the individual devices [188]. This information can be supported by certificates produced by independent organizations such as the TÜV (German Technical Inspectorate) or companies specialized in testing.

Redundancy can be used to reduce the SIL of each component, or it can be used to increase the SIL if an extra or redundant sensor is implemented into the SFF [11]. Tables 4-14 and 4-15 show this concept. The IEC 61508 certificate provides an SFF. Table 4-14 and Table 4-15 provide the corresponding hardware fault tolerance (HFT) for that SFF. The HFT at the top of that column is used to determine the number of redundant devices required. For example, an SFF of 91% is in the range of the third row in the table. The HFT for this component for SIL-2 is 0, which means that a SIL-2 application does not require any redundant sensors. Similarly, the HFT for a SIL-3 application is 1, which means that SIL-3 requires one redundant sensor (i.e., two sensors total).

Table 4-14 Architectural Constraint Table for Type A Devices [75]

Hardware fault tolerance Safe failure fraction 0 1 2 (1 sensor) (2 sensors) (3 sensors)

<60% SIL-2 SIL-2 SIL-3 60% to <90% SIL-2 SIL-3 SIL-4 90% to <99% SIL-3 SIL-4 SIL-4 99% SIL-3 SIL-4 SIL-4 11 Safe failure fraction (SFF) describes the proportion of failures that are either not hazardous or hazardous but revealed by some auto-test. For example, SFF = 1, the proportion of unrevealed hazardous failures. The IEC 61508 standard specifies the levels of SFF required to claim conformance to a given SIL target according to the amount of redundancy being employed. There are two tables of rules indicating whether an item of equipment or component is simple (with well-defined failure modes, known as Type A) or complex (such as a programable instrument, known as Type B).

4-71

Table 4-15 Architectural Constraint Table for Type B Devices [75]

Hardware fault tolerance Safe failure fraction 0 1 2 (1 sensor) (2 sensors) (3 sensors)

<60% Not Allowed SIL-1 SIL-2 60% to <90% SIL-1 SIL-2 SIL-3 90% to <99% SIL-2 SIL-3 SIL-4 99% SIL-3 SIL-4 SIL-4 The SFF can be related to the diagnostic coverage (DC) (see Subsection 4.10.8) and to detected and undetected failures, as shown below [189]:

S + DD

=

S + D DD

=

DD + DU where SFF is the safe failure fraction; DC is the diagnostic coverage; S is a safe failure; SD is a safe, detectable failure; SU is a safe, undetectable failure and D is a dangerous failure; DD is a dangerous, detectable failure; DU is a dangerous, undetectable failure.

Safe failure may not affect the systems ability to perform its functions whereas dangerous failures prevent the system from working properly. Both safe and dangerous failures are divided into detectable and undetectable failures.

Redundancy is unlikely for EDDs. The safe failure fraction in IEC 61508-2 (Tables 4-14 and 4-15 above) would require SIL-3 for 99% safe failure fraction. The use of IPL and SFF does not appear to provide relief for risk-informing a safety related component from a SIL-3 to a SIL-2.

That is, functionality and consequences of failure are not considered.

However, in the railroad industry, Mikro Elektronik (MEN) has taken redundancy to the board level

[190]. Its A602/D602 - SIL 4 / DAL-A SBCs has triple redundancy on a single board. The board was developed according to RTCA DO-254, EN 50129, and IEC 61508, and it is certifiable up to SIL 4 (report from TÜV SÜD) and DAL-A. MENs railway computer platform complies with the EN 50126 (Reliability, Availability, Maintainability, Safety [RAMS]), EN 50128 (software) and EN 50129 (hardware) railway development standards for functional safety, and the single components are certified up to SIL 4.

4-72

4.10.6 Dependability Dependability is a measure of correctness. The amount of published research in the area of dependability of smart sensors is limited [121]. However, the overall objective of how to achieve dependability does apply to EDDs. RIS 2002-22, Supplement 1 recognizes that a key element in determining dependability is through having a quality design process. Other factors to consider in determining dependability include evaluating relevant operating experience and using suppliers that incorporate quality processes such as continual process improvement and incorporation of lessons learned and document how that information demonstrates adequate equipment dependability provide another measure of providing a dependable product.

Per the guidance In EPRI TR-106439 and IEEE Std. 7-4.3.2-2003, dependability characteristics address attributes that typically cannot be verified through inspection and testing alone and are generally affected by the process used to produce the device. EPRI TR-106439 [54] indicates that dependability is a broad concept that incorporates various characteristics of digital equipment, including reliability, safety, availability, maintainability, and others. EPRI 3002002982 [53] (an update of EPRI NP-5652 [73]; EPRI TR-102260 [74]) measures dependability with respect to built-in quality (quality of design and manufacture), failure modes and failure management, problem reporting, and reliability. Others identify the following dependability characteristics:

integrity, reliability, maintainability, and security [35].

In the process industry, the most important standards regarding the use of software are IEC 61508 and IEC 61511. The requirements for software in both of these standards also apply to the EDDs software and follow the standard and expected life cycle process, configuration management, specification methods, the use of formal methods, error detection and correction, etc.

IEC 62671 Clause 7 addresses dependability by providing evidence of correctness. This can be achieved through QA, design and development process, design configuration management, and design change control. Compensating measures to support dependability include operating experience and documentation improvement.

IAEA NE series document NP-T-3.27 [191] addresses the dependability of smart devices. Not surprisingly, vulnerabilities in a system could be detrimental to its dependability. Examples of vulnerabilities include uninitialized variables, divide by zero, timing issues, and tool chains.

Laprie [192] addresses the attributes, means, and impairments (threats) of dependability:

• Attributes of dependability include properties such as availability, reliability, safety, confidentiality, integrity, and maintainability.

• Means of achieving dependability include fault prevention, fault tolerance, fault removal, and fault forecasting.

• Threats to dependability are characterized as faults, errors and failures.

EPRI 1002833 [18], the final guideline on Licensing Digital Upgrades (NEI 01-01 / EPRI TR-102348, Revision 1), provides guidance on implementing and licensing digital upgrades and provides guidance on performing qualitative assessments of the dependability of digital I&C systems. RIS 2002-22 Supplement 1 [223] provides a pathway for implementation of EDDs as 4-73

digital modifications, and cites NEI 01-01/EPRI TR-102348, Revision 1, as industry guidance for evaluating EDDs in NPPs and fuel cycle facilities.

The qualitative assessment factors are (1) design attributes, (2) quality of the design process, and (3) operating experience.

Some important characteristics that should be evaluated for determining dependability include

[18]:

• The development of QA processes implemented for both the digital platform and the plant-specific application software

• Demonstration of compliance with appropriate industry standards and regulatory guidelines for development, software safety analysis, V&V, and configuration control

• Hardware and software design features that contribute to high dependability such as built-in fault detection and failure management schemes, internal redundancy and diagnostics, and use of software and hardware architectures designed to minimize failure consequences and facilitate problem diagnosis In addition, the maturity of the product and in-service experience with the platform and the plant system application should be considered. Substantial applicable operating history reduces uncertainty in demonstrating adequate dependability. Credit should also be taken for using digital platforms that have previously been reviewed by the NRC as part of dedication for safety-related applications.

As shown, dependability is a broad, general term that covers many characteristics. The difficulty is in determining if and when a system is sufficiently dependable. When a system is sufficiently dependable, its likelihood of failure should also be sufficiently low.

For EDDs with non-control functionality, the failure of the EDD is an individual component failure; the lack of control functions eliminates most CCF concerns. All analog and digital components can be susceptible to other factors such as EMI. Even diverse, redundant, independent EDDs could be susceptible to EMI to different degrees. For example, an Allen Bradley relay generated an inductive kick [49]. External effects of EMI can be mitigated by proper shielding; however, internal effects such as the inductive kick in the Allen Bradley may be more difficult to identify and address.

4.10.7 Diversity and Defense-in-Depth Diversity and defense-in-depth are design measures used to demonstrate that vulnerabilities to CCFs have been adequately addressed. NUREG/CR-7007 [193] identifies three diversity strategies that include the use of

1. fundamentally diverse technologies, such as analog and digital implementations,

2. distinctly different technologies, such as the distinct approaches represented by general-purpose microprocessors and field-programmable gate arrays, and

3. variations within a technology within the same technology, such as that provided by different microprocessors (e.g., Pentium and Power PC).

4-74

For digital systems, the defense-in-depth and diversity in the overall plant design are analyzed to assure that where there are vulnerabilities to software CCFs, the plant has adequate capability to cope with these vulnerabilities. Most defense-in-depth and diversity analyses generally focus on system-level consideration of CCF and does not explicitly address treatment of equipment/components. Characteristics that can serve to alleviate concerns about CCF vulnerability include 100% testability, which is applicable to EDDs, and sufficient internal diversity, which is not practicably applicable within a single EDD.

SRP BTP 7-19 provides measures guidance for evaluation of diversity and defense-In-depth in digital computer-based instrumentation and control systems. Diversity and defense-in-depth analysis methods are consequence based and system focused. This creates a challenge for assessing equipment with EDDs. Supplement 1 to RIS 2002 offers potential relief through qualitative assessment of the likelihood of failurethe failure likelihood is sufficiently low, or the failure likelihood is not sufficiently low.

For EDDs, diversity in the use of sensors has the advantage that it can reduce the probability that two or more sensors failing simultaneously, although this effect is limited by the fact that diverse sensors may still contain the same faults. A disadvantage of diversity can be the increased complexity of maintenance, which in itself can lead to a higher probability of failure of the sensors in EDDs. Whether the use of diversity is advisable depends on the design of the and the details of their application.

Meulen explores how diversity could improve the dependability of redundant EDD configurations.

Diversity can reduce the main causes of CCF information overload, complexity, and HMI, or as Meulen calls it, human computer interactions (HCIs) [121]:

1. Diverse sensors might react differently to information overload conditions.

2. EDDs designed for the same use will likely have comparable design, algorithms, and complexity; however, diversity will reduce the possibility of CCF because of complexity.

3. Diverse EDDs will most probably have different user interfaces.

Diversity of individual EDDs (e.g., each component has two or more diverse sensors) is not currently a practical solution and could cause competing information to operators or control capabilities in addition to maintenance issues. At the device level, with each device having its own sensor and operating on its own time scale, the risk of a CCF is reduced unless caused by external events or a software-related CCF similar to the chart recorder at Sellafield. Diversity on the highly redundant subsystem level introduces maintenance problems, spare parts issues, etc. Thus, diversity at the device level may not be a practical solution. As noted by Meulen [121] and supported by this review that at this stage for EDDs, it is not possible to give general recommendations for the use of diversity.

Other diversity measures may not be at the component level but at the V&V level. This could include conventional testing with simulator testing and the use of independent testing facilities.

4.10.8 Self-Diagnostic Coverage Self-diagnostics can be used to detect faults in a safety instrumented system, can be performed on a system or component level and can enforce a known state as the fault recovery action.

Many EDDs and systems have embedded self-diagnostics that are executed continuously. These 4-75

self-diagnostics can be used to determine the health status of the EDD. Self-diagnostic coverage could never be 100%, similar to how testing could never provide 100% coverage, because of the unknown unknowns and not knowing all of the failure modes. Nevertheless, the greater the knowledge and history of a component could provide a means to provide a graded review by accepting the diagnostic coverage and the confidence in that coverage.

Self-diagnostics, also referred to as diagnostics, are used to ensure that failures are detected, and as a result, they will use the appropriate default states. Self-diagnostics for EDDs are dependent on knowing the failure modes of the device. This is one reason why knowing the failure modes of the EDDs are so important.

Diagnostic coverage is defined as the fractional decrease in the probability of dangerous hardware failure resulting from the operation of the automatic diagnostic tests, and a dangerous failure is defined as a failure which has the potential to put the safety-related system in a hazardous or fail-to-function state [194].

The main purpose of self-diagnostics is to increase reliability, so introducing diagnostics has benefits, even if the volume of surveillance tests cannot be reduced. With periodic testing, some faults may remain undetected until the next periodic test, or in the worst case, until functional failure. The probability of these events can be greatly reduced using self-diagnostics. As there are potential unrevealed failures, some of which may be unsafe failures, there is still a need to perform functional testing to ensure that there are no unsafe failures remaining. The use of self-diagnostics may help to reduce the extent of the functional testing, but it will not eliminate the need for this testing.

Self-diagnostics can reduce the likelihood of a single failure, but it is practically impossible to detect all failure modes. This is why having as compete set of failure modes and an understanding of the EDD is so important. With self-diagnostics, EDDs installed in non-safety and safety applications should be able to reliably detect failures, provide early warning of potential failures, and notify plant operators to take appropriate action so that safety margins are maintained. Moreover, EDDs with self-diagnostics can provide added assurance that time-related degradation due to operation has not accumulated to a point that necessitates tests or preventive maintenance ahead of an extended surveillance interval.

Ideally, self-diagnostics would provide comprehensive coverage of the failure mechanisms.

However, this is not always possible, and it can be difficult to conclusively prove that the self-diagnostics can provide 100% coverage of all faults. Hence, it is necessary to make a conservative assumption about the percentage of failures that the self-diagnostics will identify.

IEC 61508-2 [75] provides levels of diagnostic coverage. This is usually a judgement based on the extent of the self-diagnostics and the complexity of the digital device, and it is often supported by a component-level FMEA or similar tool and operating history. By combining the percentage of failures detected by the self-diagnostics with the predicted failure rate, the unrevealed failure rate can be calculated.

EDDs that perform self-diagnostics and that can alert users to failures or degradations should lower the rate of failure identified as part of surveillance testing. In addition, the operability of the component (i.e., active or on-demand) will influence the likelihood of a failure being undetected.

SRP BTP 7-17 [178] defines a self-test as a test or series of tests performed by a device upon itself. Self-tests include on- line continuous self-diagnostics, equipment-initiated self-diagnostics, and operator-initiated self-diagnostics. The BTP recognizes that, although there are positive 4-76

aspects of self-test features, these should not be compromised by the additional complexity that the self-test features may add to the safety system. Simply stated, the improved ability to detect failures provided by the self-test features should outweigh the increased probability of failure associated with the self-test feature.

IEEE Std. 7-4.3.2-2003, Clause 5.5.3, states that Computer systems can experience partial failures that can degrade the capabilities of the computer system but may not be immediately detectable by the system. Self-diagnostics are one means that can be used to assist in detecting these failures. If self-diagnostics are incorporated into the system requirements, these functions shall be subject to the same V&V processes as the safety system functions.

, self-diagnostic functions shall not adversely affect the ability of the computer system to perform its safety function, or cause spurious actuations of the safety function. A typical set of self-diagnostic functions includes the following:

• Memory functionality and integrity tests (e.g., PROM checksum and RAM tests)

• Computer system instruction set (e.g., calculation tests)

• Computer peripheral hardware tests (e.g., watchdog timers and keyboards)

• Computer architecture support hardware (e.g., address lines and shared memory interfaces)

• Communication link diagnostics (e.g., cyclic redundancy check [CRC] checks)

Much of the operability of EDDs rely on self-diagnostics to identify failures and the failure of the device in a safe mode, etc. This makes the reliance on self-diagnostics one of the most important aspects to be evaluated. Self-diagnostics can add a lot of benefit by identifying errors and deviating performance; however, self-diagnostics add complexity, may have untested steps, and may falsely increase confidence in a device.

Excessive diagnostic coverage claims are routinely made on programmable electronic field devices [123]. Claims in excess of 90% are common, even with the restricted boundary and operating environment assumptions. A high diagnostic coverage translates directly into a high IEC SIL claim limit and low reported PFD. Such a claim makes sense when the credited diagnostic actually yields safer operation and is periodically proven to workthe same rule applied to any safety device. Self-diagnostics must be verifiable and auditable. Unfortunately, many manufacturer-supplied self-diagnostics are not capable of being tested in compliance with IEC 61511 Clause 11.3, requirements for system behavior on detection of a fault, and 16.3.1.1, which states that periodic proof tests shall be conducted using a written procedure to reveal undetected faults that prevent the SIS from operating in accordance with the safety requirements specification. Additionally, analysis reports do not include information on the products integrity if the self-diagnostics are not configured per the safety manual or if the product fails during operation.

The basis and accuracy of self-diagnostics, like operating experience, is difficult to assess with actual data because collecting data and information is very difficult because of intellectual property (IP) issues. Access to design documentation presents a challenge to nuclear operators/licensees.

In practice, this access is hindered by several factors, such as:

4-77

• the need to protect the suppliers IP rights,

• the potential revelation of anomalies in the suppliers processes and products,

• the time and effort required of the manufacturer,

• the argument that previous certification (if available) should suffice, and

• the relatively small size of the nuclear market, which typically means that nuclear licensees have limited influence on smart sensor/actuator suppliers.

Self-diagnostics and fault detection are features within a design that can provide immediate identification of a failure. Failures can be announced or unannounced. One of the worst scenarios for a safety system is that it is in a failed state and there is no indication of a problem until the system is called upon to perform its safety function.

A risk-informed approach would evaluate the likelihood and consequences of failures in application software, the OS, or self-diagnostics software. The very high usage and operating experience outside the nuclear industry (millions of component types) will reduce the likelihood of software failures, including software CCFs. Self-diagnostics help identify failures. If an OS or application software CCF occurs, then there should be feedback of the failure to the vendor, and the vendor could revise (fix) the software. No indication of this type of CCF was found, most likely because all EDDs are locally controlled and are on different time loops.

Self-diagnostics would monitor hardware and software. This is not to say there will not be a software-related error, which in itself is a potential CCF, it is just that the likelihood of a software CCF is low because of the self-diagnostics and independent sensor readings for the independent EDDs.

Diagnostic coverage (DC) represents the fraction of dangerous failures rates detected by self-diagnostics [195]. Overall, DC has four failure states in which the component fails in a safe/unsafe state and the failure is detected/undetected by self-diagnostics:

SD - failed in a safe manner, and failure is detected by the diagnostics or plant trip SU - failed in a safe manner, but failure was undetected by the diagnostics but identified through proof tests DD - failed in a dangerous manner, and failure is detected by the diagnostics DU - failed in a dangerous manner, and failure is undetected by the diagnostics but identified through proof tests or incident The total dangerous failure rate is then as follows:

DT is the total dangerous failure rate (DT = DD + DU)

For safety applications, the DC is typically applied to dangerous failures:

• the DC for the dangerous failures of a device is DC = DD/DT 4-78

• for a safety instructed subsystem with internal redundancy, DC is time dependent:

DC(t) = DD(t)/DT(t).

The specific percentages of DC are specified to make it likely that any dangerous failure is detected by the self-diagnostics, thereby reducing the probability of the existence of an undiscovered failure.

DC can be:

• low: 60-90 % coverage

• medium: 90-99 % coverage

• high: >99% coverage The hardware assessment consists of a failure modes, effects and diagnostics analysis (FMEDA).

A FMEDA is one of the steps taken to achieve functional safety assessment of a device per IEC 61508. From the FMEDA, failure rates are determined, and consequently, the SFF is calculated for the device. For full assessment purposes, all requirements of IEC 61508 must be considered.

Complete practical fault insertion tests can demonstrate that the DC corresponds to the assumed DC in the FMEDAs.

It has become easier to certify a high total failure device with a high DC claim to SIL 3 than it is to certify one with a low total failure rate but no diagnostics [123].

Often, self-diagnostics cannot be directly tested [198]. In fact, in most cases, there is no means to test the self-diagnostics to determine if they are working.

ISA-TR84.00.02-2015 [140] defines detected failures in relation to hardware and software failures, or faults, which are not hidden because they announce themselves or are discovered through normal operation or through dedicated detection methods. Undetected failures is the term used for failures or faults which do not announce themselves when they occur and which remain hidden until detected by some means (e.g., diagnostic tests, proof tests, or operator intervention like physical inspection and manual tests). Such failures cannot be repaired until they have been revealed. The term revealed is used for failures or faults that become evident due to being overt or as a result of being detected.

DOE Order 420.1C requires safety-significant SSCs to be designed to reliably perform all of their safety functions. The order states that this can be achieved through a number of means, including use of redundant systems/components, increased testing frequency, high reliability components, and diagnostic coverage (e.g., on-line testing, monitoring of component and system performance, and monitoring of various failure modes) [199].

ISA 84.00.01-1 Clause 11.9, ISA-TR84.00.02, provides guidance on (a) assessing random and systematic failures, failure modes and failure rates; (b) understanding the impact of diagnostics and mechanical integrity activities on the SIL and reliability; (c) identifying sources of common cause, common mode, and systematic failures; and (d) using quantitative methodologies to verify the SIL and spurious trip rate.

The consequence of the failures can be classified as safe or dangerous based on the impact or effect that the failure has on the devices operation [140]. A safe failure is a failure which favors a 4-79

given safety action, whereas a dangerous failure is a failure which impedes or disables a given safety action; a failure is dangerous only with regard to a given SIF.

IEC-61508 [194] defines these as follows:

Dangerous Detected Failure - A detected failure which has the potential to put the safety instrumented system in a hazardous or fail-to-function state. Dangerous detected failures do not include hardware failures and software faults identified during proof testing, represented by the plants surveillance testing.

Dangerous Undetected Failure - An undetected failure which has the potential to put the safety instrumented system in a hazardous or fail-to-function state. Dangerous undetected failures do not include hardware failures and software faults identified during proof testing.

Detected failures are in relation to hardware and software failures, or faults, which are not hidden because they announce themselves or are discovered through normal operation or through dedicated detection methods. The term undetected is used to describe failures or faults which do not announce themselves when they occur and which remain hidden until detected by some means (e.g., diagnostic tests, proof tests, operator intervention like physical inspection and manual tests). The repair of such failures can begin only after they have been revealed. The term revealed is used to describe failures or faults that become evident due to being overt or as a result of being detected.

In IEC 61511, the term dangerous detected failures/faults describes dangerous failures detected by diagnostic tests. The word overt is used to describe failures or faults which announce themselves when they occur (e.g., due to the change of state). Repair of such failures can begin as soon as they have occurred. When the detection is very fast as when discovered using diagnostic tests, detected failures or faults are considered overt failures or faults. When the detection is not as fast, as when discovered using proof tests, the detected failures or faults cannot be considered overt when addressing SILs. A dangerous, revealed failure can only be treated as a safe failure if effective automatic or manual compensating measures are taken early enough to ensure that safety integrity requirements are met for the safety function.

In IEC 61511, the term dangerous undetected failures/faults describes dangerous failures/faults that are not detected by diagnostic tests. However, undetected failures may also go undetected by operator intervention such as physical inspection and manual tests, or through normal operation.

Annex C of IEC 61508-6 gives an example of calculating diagnostic coverage and should be read in conjunction with Annex C of IEC 61508-2. M. van der Meulen [121] notes that:

A problem that remains is the confidentiality of information; manufacturers do not want to disclose details on the design of their sensors. This explains why reports on failure rates and diagnostic coverage exist on sensors, but they do not provide detailed design information. These evaluations give the numerical data-most importantly, failure rates and fault coverage-required by IEC 61508 for the calculations as presented part 6.

Sometimes independent assessors will perform fault insertion testing. In principle, this is comparable to performing a FMEDA. One advantage is that it concerns real insertion of faults, a disadvantage is that the number of faults that can be tested is lower and that some tests might be catastrophic. Also, the distribution of inserted faults might not reflect the distribution in actual use, and thus give a biased assessment of the fault behaviour that is to be expected. At the moment, the 4-80

approach to smart sensor assessment, including fault insertion testing, is the subject of a new IEC standard [IEEE 60770, Part 3], now in its draft phase.

The absence of design details makes it hard for users to assess the validity of the results and their applicability to each user's setting. Independent assessors (like EXIDA.com, TÜV, TNO and Factory Mutual) are therefore essential.

4.10.8.1 Announced Failures Failure modes described as self-monitored or covered are faults that can be detected and compensated for using the components downstream and operator actions. This does not indicate that non-covered faults are not detected; instead, faults that are not covered through self-monitoring will likely need to be subjected to periodic surveillance tests [200]. Fault coverage (i.e.,

self-monitored versus non-self-monitored failure modes) could play an important role in whether on-line monitoring (OLM) and self-diagnostic feature can be credited in a risk-informed assessment of the EDDs. This assumes that there is sufficient coverage of the self-diagnostics to detect the failure mechanisms and a determination of uncertainty, which is important if an EDD that provides self-diagnostics is relied upon to extend technical specification surveillance intervals.

A key consideration in the crediting of monitoring is the treatment of what are termed dangerous detected and dangerous undetected failure fractions, which are established to provide input to the reliability model for the device and the associated system [201].

IEC 61508-2 was developed to provide requirements for achieving safety integrity in the hardware of the safety-related systems, including sensors and final elements. Techniques and measures against both random and systematic hardware failures are required. These techniques and measures include an appropriate combination of fault avoidance and failure control measures.

For cases in which manual action is needed for functional safety, requirements are given for the operator interface. IEC 61508-2 specifies diagnostic test techniques and measures based on software and hardware (for example diversity) to detect random hardware failures.

IEC 61508-3 was developed to provide requirements for achieving safety integrity for the software, including both embedded (including diagnostic fault detection services) and application software. IEC 61508-3 requires a combination of approaches to ensure fault avoidance (QA) and fault tolerance (software architecture). IEC 61508-3 requires the adoption of such software engineering principles as (1) top-down design, (2) modularity, (3) verification of each phase of the development lifecycle, (4) verified software modules and software module libraries, and (5) clear documentation to facilitate verification and validation. The different levels of software require different, appropriate levels of assurance that these and related principles have been correctly applied.

Diagnostics may not be capable of detecting systematic errors such as software bugs [202].

However, appropriate precautionary measures to detect possible systematic faults can be implemented.

The detection of a fault on a standby device can be identified by exercising most devices, such as an isolation valve. Faults on active devices are in most cases self-identified. Standby devices such as a relay or breaker may be more difficult to exercise. Condition monitoring by exercising a standby device allows process variables or inputs to be read.

Unavailability of protection includes problems that lead to a failure to operate one or more functions of the device [203]. The deficiency must be self-demonstrating and must be signaled by 4-81

the device via target or display messages, fail-safe relay, communication protocols, or other means so that manual or automatic corrective actions can be taken to rectify the problem. If the problem is not self-demonstrating, then it belongs to the category of hidden failures to operate.

The prevailing NRC policy and guidance specifically invokes a consequence-based assessment approach that is primarily applied at the safety system (or redundancy/subsystem) level for sense and command functions. These safety functions are generally characterized as on-demand, in which the safety action is commanded and executed when indication of an infrequent (transients) or rare (accidents) PIE is sensed. This conventional assessment approach has not been extensively applied at the component level; nor has it been applied to equipment for which the safety-related function is generally characterized as continuous, frequent, or predictable (such as for many sensing, actuation, and support service equipment) [204].

A latent error in software is an undetected defect in the software caused by incorrect requirements, software implementation error, untested hardware failures, etc., that only occurs when triggered. The probability of an undetected latent error increases with complexity.

ORNL/TM-2010/32 [132] identifies new failure modes or the increased likelihood of failures for digital vs. analog systems such as relay race, the probability of an undetected latent error increasing with complexity, communications presenting unique problems for digital systems because of the ease of changing digital programs, and a quasi-trip state in which the output of the failed NAND (NOT AND) gate does not allow a true HI output.

Under IEC 61508 requirements, a product with a high total failure rate can achieve a high SIL claim limit as long as its failure is detected and annunciated. ISA-TR84.00.04-2015, Part 1 [205]

notes safe failure fraction (SSF) is a ratio of failure rates. It is a measurement that does not depend on the total failure rate. A device can have a high total failure rate, and as long as the failures are safe or detected, the SFF is also high. This means that a device can have a high SFF and be highly unreliable. Process users need reliable equipment to ensure safe operation.

Possessing a high SFF does not necessarily mean that the device performance is adequate for safe service. Summers [120] notes that the SFF is not penalized by the choice to alarm rather than achieving the safe state. Therefore, the more failures that are detected, the higher the SFF becomes, regardless of the number of times, or the total amount of time, that the device is in the failed state, essentially dumping responsibility for process protection back on the operator.

Fault detection simply informs the user that the device is no longer capable of operating as required; it does not achieve or maintain process safety.

The self-diagnostics can detect failures (if it has a complete set of failure modes); however, if the device cannot communicate to the safety/control system that a failure has been detected, or if the alarms on the device are not visual or audible to staff, then the benefits of self-diagnostics are minimal. This is true even if the diagnostic coverage is 100% and its fault detection capabilities (self-diagnostics) are working properly. In this case, the operators would not know that the device has failed, even though the device is capable of warning them. This means that the SIL requirement of the SIF / instrumented protective function (IPF) implementation is not satisfied.

This is a tradeoff for the use of EDDs in an NPP, because the communication capabilities, especially 2-way communication, increases the complexity of the EDD and could then require a much more complicated system review. Although 2-way communication is not an issue with the current use of EDDs, it is expected to be an ET that will be implemented sooner rather than later.

4-82

Industry and the available standards seem to over rely on diagnostic coverage. Diagnostic coverage is very dependent on knowing and understanding the failure modes of the EDDs. A diagnostic cannot detect a failure mode that it is not testing for.

4.10.9 Testing No matter the diagnostic, the only way to be certain that a device is working is to test it. However, the test itself must adequately simulate real demand conditions.

Testing is one method to provide assurance of the availability and effectiveness of functions important to safety and to confirm that these have not been degraded. For an EDD, testing is implemented to ensure that device functions as intended. In EDDs where failures would not be detected by testing or revealed by alarms or anomalous indications, the EDD should be analyzed for such undetected failures: the preferred course is to redesign the system or the test schemes to make the failures easily detectable. Interconnected systems should also be tested to confirm that all of their interfaces operate correctly.

Testing falls into two areas:

1. Initial - Design V&V

2. Periodic (surveillance)

Initial testing can be used to prove functionality and operability upon completion of design or at the end of the CGD process. Periodic testing of an installed device can never be comprehensive. In particular, it is difficult to ensure that the test (or the self-diagnostics) will find and announce internal failures is still working.

The surveillance test is manually initiated but may include automated or semi-automated test equipment to implement the test and/or record the test results. Proof testing is a synonym for surveillance testing used by IEC 61508. Surveillance testing should be designed to confirm that safety-critical functions of the EDD are being performed properly (e.g. overlapping end-to-end) with the test frequencies preferably being risk-based. Self-diagnostics are testing protocols embedded within the EDD and can be executed continuously. They try to perform most of the same functions but are implemented differently.

Failures of an EDD are grouped in IEC 61508 into two main categoriessafe failures and dangerous failures. Safe failures are divided into detectable (SD) and undetectable failures (SU) that do not affect the systems ability to perform its functions. Dangerous failures prevent the system from working properly on demand. Dangerous failures are also divided into detectable and undetectable failures with failure rates DD and DU, respectively. Some dangerous detectable failures can be detected by online self-diagnostics, whereas dangerous undetectable failures remain unobserved until the surveillance test. Therefore, the purpose of surveillance testing is to detect unrevealed faults at the time of testing, while diagnostic coverage allows the detection and remediation of fail-to-danger fault conditions between surveillance tests [206].

Although NRC uses the term surveillance test rather than proof test, ANSI/ANS NQA-1 requires tests, including, as appropriate, prototype qualification tests, production tests, proof tests prior to installation, construction tests, preoperational tests, operational tests, and computer program tests such as software design verification, factory acceptance tests, site acceptance tests, and in-use tests to be controlled. Required tests shall be controlled under appropriate environmental 4-83

conditions using the tools and equipment necessary to conduct the test in a manner to fulfill test requirements and acceptance criteria. The tests performed shall obtain the necessary data with sufficient accuracy for evaluation and acceptance.

Proof testing is defined in IEC 61508 as a Periodic test performed to detect dangerous hidden failures in a safety-related system so that, if necessary, a repair can restore the system to an as new condition or as close as practical to this condition. A proof test is designed to reveal all the undetected/unrevealed failures that are not revealed until a demand is placed upon the component/system. A proof test is not a functional test or a diagnostic test. A functional test is conducted to ensure that a specified function is working correctly. However, a functional test in redundant channels does not necessarily reveal all faults. For example, a functional test in a subsystem with a 1oo2 voting configuration may detect a dangerous fault of the sensor architecture, but it may not highlight the number of faults. A proof test, however, would reveal all faults, even if there are multiple faults, as (typically) all elements are individually tested. In summary, the proof tests should demonstrate that all parts of the system are fully effective in delivering the relevant safety function, including any automatic or diagnostic test equipment that is used as part of testing either during service or during the proof test [207].

The perceived benefit for industry is that the application of diagnostic techniques for cases in which none previously existed has the potential to decrease the surveillance test frequency and the scale of routine testing. However, surveillance testing does not necessarily render components any more reliable. Surveillance test intervals are the same as surveillance test intervals and are set up to be consistent with the operating goals for the system.

Periodic surveillance tests, automated self-diagnostics, and surveillance tests can be performed to show the operability of the device and to meet availability targets. An EDD can be in a failed state while appearing to be running properly, and it is recognized that some failures will be undetected by self-diagnostics and surveillance tests. Surveillance testing should be designed to confirm that safety-critical functions are being performed properly (e.g., overlapping end-to-end). The test frequencies for surveillance tests should be risk informed.

ONR recognizes that surveillance testing can be more easily shown to be comprehensive for a simple system, so a failure that does occur can be expected not to persist beyond the next test interval [207]. For complex systems, especially software-based systems in which systematic faults are much more likely, the time-to-failure distribution is completely unknown, and periodic surveillance tests can only reveal random faults arising from non-software sources. In these cases, the level of uncertainty is higher, the safety margin must be larger, and the level of dependence placed on the system should therefore be correspondingly less.

Model-based testing methods may provide effective demonstration of whether devices are subject to certain types of CCF and may establish a cost-effective automated testing framework for industry stakeholders to qualify equipment with EDDs.

Automated testing programs are available for many OSs and languages. When a test will be run more than a few times, automated testing will usually save time and effort. Automated testing also removes the possibility of human error when a test procedure is followed. This removes the random error component, but it does leave open the possibility of systematic error, in which the automated test makes the same error every time it is run [208].

IEEE Std. 1012-2004 [209], endorsed by RG 1.168, Rev. 2 [319], and IEEE Std. 829-2008 [210],

endorsed by RG 1.170, Rev. 1, as well as the newer, unendorsed revisions do not provide the 4-84

particulars of testing described herein, though perhaps they are implied. References to static analysis seem to refer to something more like code review and less like modern static analysis tools. Formal testing methods are mentioned briefly but not covered at length in later versions of IEEE Std. 1012, which is not endorsed by the NRC at this writing.

Testing may be performed by various organizations within the development effort. The IEEE Std.

1012 standard requires a minimum level of V&V testing, depending on the integrity level. Table 4-16 summarizes the minimum level of V&V testing required for the types of testing and integrity level. The term perform means that the V&V organization specifies and creates its testing products (i.e., test plan, test design, test cases, and test procedures) and either conducts the testing or analyzes the results when testing is conducted by another organization. The term review means that the V&V organization reviews the testing plans and analyzes the test results.

Table 4-16 Minimum Level for V&V Testing by Integrity Level (IEEE Std. 1012)

V&V testing by IEEE integrity level Software 4 3 2 1 Software component testing V&V Perform Perform Review No action Software integration testing V&V Perform Perform Review No action Software qualification testing V&V Perform Perform Review No action Software acceptance testing V&V Perform Perform Review No action NUREG/CR-4621 [164] evaluates six different testing strategies:

1. Static source code analysis

2. Structural testing

3. Functional testing

4. Statistical testing

5. Stress testing

6. Regression testing NUREG/CR-4621 states that It is possible to use statistical testing for the goal of finding failures (random testing). Statistical testing does not rely on any knowledge of the internal composition of the software object and is the only way to provide assurance that a specified reliability level has been achieved. Statistical testing is a practical method in many cases when moderate-to-high reliability (in the range of 10-4 to 10-5 failures per demand) is required.

NUREG/CR-7044 [211] compared three different quantitative software reliability methods (QSRMs): the software reliability growth method, the Bayesian belief network method, and the statistical testing method. The NUREG/CR concludes that the statistical testing method is the preferred approach for estimating demand-failure probabilities of safety-critical protection systems.

NUREG/CR-7234 [212] presents a successfully developed PRA-based statistical testing method, applied this method to a deployed digital system, and demonstrated its feasibility for digital I&C safety systems in NPPs.

All other factors being equal, techniques which are ranked as highly recommended (HR) in Table 4-17 (Table B.2 in IEC 61508-3) will be more effective in either preventing the introduction of systematic faults during software development or, in the case of the software architecture, more 4-85

effective in controlling residual faults in the software revealed during execution than techniques ranked as simply recommended.

Table 4-17 Dynamic Analysis and Testing by IEC SIL (IEC 61508-3 Table B.2)

Technique / Measure SIL 1 SIL 2 SIL 3 SIL 4 1 Test case execution from boundary value analysis R HR HR HR 2 Test case execution from error guessing R R R R 3 Test case execution from error seeding -- R R R 4 Test case execution from model-based test case R R HR HR generation 5 Performance modelling R R R HR 6 Equivalence classes an input partition testing R R R HR 7a Structural test coverage (entry points) 100% HR HR HR HR 7b Structural test coverage (statements) 100% R HR HR HR 7c Structural test coverage (branches) 100% R R HR HR 7d Structural test coverage (conditions, modified R R R HR condition [MC] / decision coverage [DC]) 100%

• R = Recommended, HR = highly recommended IEC 61511 requires users to validate and periodically demonstrate via diagnostics, alarms, manual operation, and safety functionality that the equipment operates according to the safety requirements specification.

Formal verification techniques such as proof of correctness have traditionally only been applied to high criticality systems because of their high cost. However, in many systems, particularly embedded systems such as smart sensors, only a small fraction of the code performs high criticality functions. Sofia Guerra et al. propose a focused proof that makes formal proof applicable at all SILs [111]. A combination of techniques is used to achieve this, as detailed below.

• Use modern proof tools.

• Restrict attention to critical code. A code review identifies the regions of the code that are directly responsible for the process variable. This code may be as little as 20% of the codebase and is typically comparatively simple. The code typically implements simple scaling and other transformation functions on the process variable. This means it can be proved correct quite easily.

• Perform independence analysis. The code that deals with user interaction, housekeeping, etc., is audited to identify points of interaction with the critical code. A variety of techniques can be used to show independence.

As an alternative to the independence analysis, Guerra et al. propose testing to exercise the parts of the code not covered by the formal analysis. This may be incorporated into an existing test program already planned for the device.

4-86

For some parts of the code, the approach described above may not be sufficient. For example, in one example encountered by Guerra, a sequence of large switch statements was used to determine the device behavior in any of several dozen input sensor types which were selected using a configuration parameter. Determining the devices actual behavior proved difficult. By deriving a version of the program specialized to a single input sensor type (like a particular type of thermocouple, for example), the computation became very clear and was easy to analyze. This strategy can be effective when only a limited number of the device configuration options are intended to be used in actual nuclear applications.

In general, the surveillance test procedures do not address testing product diagnostics [123].

Conversely, the diagnostic coverage fraction of dangerous failure rates is not detected by diagnostics [195]. Diagnostic coverage does not include any faults detected by surveillance tests.

Many devices have achieved a high IEC SIL via large diagnostic coverage factors, yet the means and procedures for testing the diagnostics are not provided or discussed in safety manuals.

An example of the need fortesting is the cause of a 9-hour outage of the AT&T long-distance telephone system which occurred on January 15, 1990. The outage can be traced back to a software upgrade that was loaded into all 114 of AT&Ts Class 4 Electronic Switching System (4ESS) switches in the United States in mid-December 1989. The updated software changed the communication protocol between the 4ESS switches [213]. Prior to the software update, once the first switch began processing calls after the trunk interface reinitialization, it would send another message to all the switches that it was connected, informing them that it was accepting new calls again. After receiving this message, the other switches would confirm that the first switch was indeed working and then would accept call routing signals from that first switch. After the update, instead of the first switch messaging the other switches that it was working again with subsequent confirmation, the new software simply had the first switch start sending routing signals to the other switches. Consequently, each switch would interpret the signals as an indication that the first switch was again working because they were receiving its routing signals.

The software problem resulted from a programming error in which the programmer misunderstood the effect of the placement of a command within an if statement in the coding. This branch of the if statement was never exercised during testing; if it had been, then the fault would have been recognized. This example emphasizes the necessity of a comprehensive, complete testing plan for software routines and the necessity of redundancy in both hardware and software to overcome any overlooked or unforeseen software errors. It is likely that testing of the system would have identified the undetected error at the system level.

Most safety manuals provide limited scope surveillance tests with estimated test coverage; product operation is typically not fully proven by these partial tests. Because failure modes and distributions are not provided, it is not possible to determine if the claimed surveillance test coverage is reasonably conservative or to define which failures the suggested test covers or does not cover.

Some failures are undetected by both diagnostic tests and surveillance tests. Because surveillance tests are not a very fast means for detecting undetected failures, the detected failures or faults cannot be considered overt failures or faults [195].

The degree of design testability promotes proper operation and provides confidence that no new failure modes will be introduced. Testability is enhanced by the simplicity of the design. If the EDD performs simple logic functions that are easily and comprehensively tested, and the logic functions can be thoroughly tested in the validation test program, then relief may be possible for 4-87

the review and dedication of the EDD or may possibly accept the use of SIL-specified devices with the caveat that it is properly tested for the critical characteristics for its end use.

4.11 Emerging Technology (ET)

Advances in ET may occur at the I&C level or the EDD level. A more detailed of likely advances in ET related to EDDs is provided in Appendix D.

ET in I&C systems include:

• sensors and measurement systems,

• communications media and networking,

• microprocessors and other integrated circuits

• computational platforms,

• diagnostics and prognostics,

• Human-system interactions,

• human-system interactions,

• high-integrity software, and

• I&C architectures in new plants.

ET in the use of EDDs include:

• increased functionality,

• cyber security hardening,

• high temperature uses,

• Increased wireless technology,

• localized control,

• combined control (similar to system control),

• additive manufacturing of devices, and

• embedded sensors.

Advances in I&C systems, EDDs, advanced reactor uses, and manufacturing will all make an impact on industry and will eventually be included in I&C systems in NPPs.

ET can originate from advances in industry migrating into the nuclear arena, or it can be developed to meet the unique needs for new nuclear plant designs.

Embedded digital capabilities will enable new types of components that are not feasible without the high-speed data acquisition and processing capabilities supplied by the on-board electronics and advances in I&C systems and components. A review of ET that could affect the use of EDDs is provided in Appendix D with a summary provided below.

For nuclear applications, there are some emerging applications of autonomous control for creating reactor components that operate in extreme environments. For example, replacing mechanical bearings with magnetic bearings can allow a pump to be made from materials that can operate above 650 °C.

Current-generation NPPs use a centralized control architecture that requires exceptional operator knowledge of the power plant; the cost and difficulty to design the operational and safety systems are significant due to system complexity. Localized control through the use of EDDs could allow 4-88

designs to be simplified and could streamline operation of complex systems while improving modularity similar to object-oriented control architectures.

Future advanced reactors may employ EDDs more extensively than the existing fleet due to the opportunity to integrate instrumentation into the SSCs during fabrication and/or construction.

Embedding digital devices into components is also more likely to be implemented in advanced reactors due to the advanced capabilities of digital technologies and the consequent potential for improving component performance and reliability.

A significant part of ET will be the advancement and use of wireless technologies. In the ET arena, increased communication capabilities and wireless technology would advance the capabilities of the EDD significantly beyond its analog counterparts. Cybersecurity and issues with electromagnetic propagation (electromagnetic and radio frequency interference, fading, interference abatement) are the major concerns with implementation of wireless technologies.

The NRC and industry are already engaged in this issue with past NRC [214], ORNL [215, 216],

EPRI [217], and DOE efforts [218, 219].

The NRC and ORNL have been researching wireless communications as an emerging technology in nuclear facilities. This research is aimed at developing a technical bases for regulatory guidance applicable to wireless technologies. A key element of regulatory guidance will be whether or not nuclear facilities can demonstrate that having data flowing in their wireless networks is secure. Wireless communications technology is not currently used in safety-related systems in nuclear facilities, but it is being used in non-safety-related and business applications, many of which have not been under the purview of NRCs regulatory authority.

A Canadian plant has used wireless sensors as part of online monitoring to enable condition-based monitoring. The EPRI research helped Ontario Power Generation deploy its first wireless sensor network.

DOE has been funding research efforts into the advancement of wireless technology such as thermoelectric generators for self-powered wireless sensor nodes. While the safety significance of the application of such technology is not indicated, the research evaluated the effects of gamma radiation on the materials for uses in harsh environments.

4-89

5 EXISTING PRACTICES Domestic and international uses of EDDs and identification/analysis of those uses were reviewed to learn how other industries and countries regulate and implement the use of EDDs and to possibly leverage their experience into the framework of NRC regulations and guidance.

Many of the regulatory agencies outside of the nuclear industry are concerned with public safety of consumer products and do not provide requirements or guidance on how this is accomplished.

Often the use of a standard comes down to insurability and possibly component quality and safety checks by Underwriters Laboratories or a similar organization. For example, Occupational Safety and Health Administration (OSHA) requires that information pertaining to the equipment in the process shall include design codes and standards employed. In some cases, insurance dictates which standards or processes are used.

5.1 Domestic Agencies In addition to NRC guidance on the uses of EDDs, the domestic uses of EDDs were evaluated for how other regulators within the United States evaluate the use of EDDs (Table 5-1).

Table 5-1 Domestic Agencies Reviewed for Guidance on the Use of EDDs Agency NRC - Nuclear Regulatory Commission DoD - Department of Defense DOE - Department of Energy FAA - Federal Aviation Administration FDA - Food and Drug Administration FERC - Federal Energy Regulatory Commission FRA - Federal Railroad Administration NASA - National Aeronautics and Space Administration OSHA -- Occupational Safety and Health Administration 5.1.1 U.S. Nuclear Regulatory Commission (NRC)

This section provides a brief overview of the NRCs current practices regarding EDDs. As part of this project, ORNL performed a thorough review of NRC practices throughout the lifecycle of an EDD, from early development processes to installations and the activities of the vendor inspection branch. Based on this ORNL concluded that NRC guidance is sufficient to review and approve EDDs. However, for more complicated EDDs this would require performing the review outside of the CGD process using existing guidance for systems. The key factor in determining whether the review could occur under CGD is if appropriate critical characteristics can be identified and verified.

5-1

RIS 2016-05 defined and provides guidance on the use of EDDs. The RIS does not provide any new guidance or set any new expectations [220] but rather compiles the guidance in one place.

The regulatory framework for EDDs is the same set of standards and guidance as that for the design and evaluation of SSCs containing in I&C systems. NRC also stressed CGD of EDDs, citing Appendix B, Part 21, and EPRI and IEEE standards.

The RIS raises awareness among licensees that EDDs, which may not have existed previously, may be introduced into a plant or facility via upgrades or replacement of equipment used in safety-related applications. The RIS encourages the identification, review, documentation, and control necessary to demonstrate quality and reliability. It also highlights possible vulnerability of equipment and systems to potential hazards like CCFs caused by software defects in EDDs. NEI noted that the RIS on EDDs brings attention to hidden digital components in devices that are often overlooked (e.g., breakers, inverters) [221].

Although the RIS does not address cyber security, 10 CFR 73.54 provides the regulations on cyber security [222].

For NPPs, basic components , which are safety related, must be designed and manufactured under a 10 CFR 50, Appendix B QA program or must have successfully undergone CGD, which must itself have been performed under an Appendix B QA program. The basis for a CGD program is found in 10 CFR 21.

In addition to using products designed and manufactured under a 10 CFR 50, Appendix B-compliant QA program, licensees may use appropriately dedicated CGIs for replacement parts.

Per 10 CFR 21, dedication may be performed by the manufacturer of the item, a third-party dedicating entity, or the licensee itself. In all cases, the dedication process must be conducted in accordance with the applicable provisions of 10 CFR Part 50, appendix B. This includes a requirement that for the persons or part of the organization performing quality assurance activities sufficient independence from those involved in design, organizational freedom, and direct access to an appropriate level of management must exist. The entity performing the dedication is responsible for identifying and evaluating deviations, reporting defects and failures to comply for the dedicated item, and maintaining auditable records of the dedication process. In addition to the dedicating entity having that responsibility, the licensee also has that responsibility whether they use a commercial grade dedicating entity or not.

EDDs should be identified early in the design to ensure procurement activities are sufficient to ensure quality and reliability, and the licensees 10 CFR 50.59 process should identify the presence of an EDD:

• CGD should ensure that EDDs are identified.

• Inclusion of these devices is not always advertised by equipment vendors.

• Discovery of these low-level embedded devices is sometimes difficult, both for NRC and licensees and CGDs.

To increase regulatory clarity and reduce regulatory burden without impacting safety, guidance for EDDs, which already addresses the potential for CCFs due to software error, includes discussions on the following:

5-2

• Susceptibility to software CCF

• Use in redundant systems

• Different (independent) sensors

• Graded approach - active or standby component

• Guidance on CCFs at the system level rather than at the component level (addressed by BTP 7-19, Rev. 7)

The current regulatory infrastructure is sufficient for those vendors and suppliers that normally provide components to NPPs throughout the supply chain (Figure 5-1). The front end of the supply chain begins with the development of the component and the guidance and processes used to develop that component. NRC provides guidance on the development of hardware and software in I&C systems. The middle of the supply chain represents the component being sent from the vendor to a commercial grade dedicating entity, before it is sent to a plant for use. The back end represents when the component or device is delivered to the NPP.

Figure 5-1 NPP Supply Chain It is expected that EDDs will significantly increase at NPPs. This in turn means that many vendors not previously supplying components or digital field devices to NPPs will most likely begin to supply components or digital field devices to NPPs. Because the use of EDDs at NPPs will increase and more vendors of EDDs will not be from inside the nuclear industry (see the Subsection 4.11 and Appendix D on ET in EDDs), cyber security vulnerabilities and concerns will be greater. In addition, concerns with respect to software development and the use of software tools will also increase.

Licensees/applicants obtaining items and equipment from vendors that includes components with EDDs should:

5-3

• In early stages, fully understand challenges that EDDs may pose.

• Include requirements to identify the use of EDDs consistent with the safety significance of the equipment in specifications for vendors.

• Include in specifications requirements for the vendor to document the quality of items with EDDs in a manner sufficient to support CGI dedication consistent with the safety significance of the equipment.

Suppliers new to the nuclear industry should become familiar with NRC requirements and guidance while also enabling the CGD process to be effective and efficient.

For new and existing suppliers, the NRC vendor oversight workshops provide an open forum for exchanging information regarding the supply of components and materials to both new and operating NPPs. These workshops are attended by NRC, vendors, industry groups, commercial grade dedicating entity facilities, government regulatory agencies, and foreign and domestic utilities. These workshops have addressed EDDs and CGD facilities. The workshops allow staff and industry to learn how testing and inspections are performed on I&C systems or EDDs.

During the development of this report, RIS 2002-22, Supplement 1 [223] was issued, providing a pathway for implementation of EDDs as digital modifications, such as those in the example below, without prior NRC approval using properly documented qualitative assessments:

• replacement of analog relays (including timing relays) with digital relays

• replacement of analog controls for safety-related support systems such as chiller (heating, ventilation, and air conditioning) systems and lubricating oil coolers

• replacement of analog controls for emergency diesel generator supporting systems and auxiliary systems such as voltage regulation

• installation of circuit breakers that contain embedded digital devices

• replacement of analog recorders and indicators with digital recorders and indicators

• digital upgrades to non-safety related control systems However, as the modification of the Allen-Bradley 700-RTC relay shows, even simple replacements of analog devices with digital devices or upgrades to digital devices can be vulnerable to a new or different failure mode that did not previously exist for that application.

Regulatory Issue Summary (RIS) 2002-22 [223] cites Nuclear Energy Institute (NEI) 01-01/EPRI TR-102348, Revision 1, [18] as industry guidance for evaluating EDDs in NPPs and fuel cycle facilities. The NRC is currently evaluating the sufficiency of NEI 96-07, Appendix D [224] to supersede the supplemental RIS 2002-22. [Regulatory Guide 1.187, Rev. 2, published in June 2020, endorses NEI 96-07, Appendix D, Revision 1, as a means for complying with the requirements of 10 CFR 50.59 when conducting digital I&C modifications, subject to clarifications.]

5-4

5.1.2 U.S. Department of Defense (DoD)

DoD standards (MIL-STD, MIL-SPEC, or (informally) MilSpecs) were searched for embedded digital control. No guidance was identified that specifically related to EDDs, but MIL-STD-882E

[83] was identified as addressing the higher level topic of safety systems. Furthermore, the Software Systems Safety Engineering Handbook [84] was issued as guidance by the Joint Software System Safety Committee.

DoDs approach to safety systems is geared very much towards process and intentionally does not focus on requiring specific design criteria or specific design techniques. This makes sense when considering the wide range of systems that the DoD utilizes. Focusing on requiring specific design principles may unnecessarily limit certain design activities. Instead, the focus is on the identification of the risks involved in each specific project and defining the appropriate levels of rigor to be implemented to eliminate or reduce those risks appropriately. While this approach works for DoD, it does not work as case study for the nuclear industry, where the scope of applications is much more focused and the requirements are much more prescriptive.

The safety issues associated with COTS products in safety-significant systems increases with the complexity of the safety system. COTS vendors do not usually create the software to be used in safety-significant systems or safety-critical applications, so they may not ensure conformance to safety guidelines or testing. COTS products are often black box and lack complete or adequate documentation of the establishment of safety requirements for the system. Therefore, COTS products may require significant analysis and testing in the context of the safety criticality of the system. Treating COTS products as black boxes is also necessary when the vendor cannot or will not supply a copy of the source code to the user.

EDDs abound in military infrastructure and vehicles of all types. Questions arise regarding the terminology used to describe EDDs how they are considered, and how they are actually used. To an extent, DoD uses the term smart devices for EDDs, and they associate smart devices with IoT.

DoD has apparently dropped the term digital and refers to these devices (and associated guidance) as infrastructure devices (e.g., smart electric meters) within industrial control systems

[225].

The DoD uses different terminology for EDDs and also considers communication capabilities between those devices.

5.1.3 U.S. Department of Energy (DOE)

DOE uses hardware fault tolerance, IEC SILs, and individual protection layers to promote safety.

DOE facilities use safety instrumented systems for various control functions such as safety interlocks and process alarms. DOE Std. 1195 applies requirements of an industry standard, ANSI/ISA 84.00.01-2004, to support the design of reliable safety significant safety instrumented systems at defense nuclear facilities.

DOE O 420.1C identifies DOE-STD-1195-2011 [187] as providing an acceptable method for achieving high reliability of safety-significant 12 safety instrumented systems. DOE-STD-1195-11F 2011 was developed based on ANSI/ISA 84.00.01-2004 and it identifies ANSI/ISA 84.00.01-2004 as an appropriate alternative means for meeting the reliability requirements. ANSI/ISA 84.00.01-12 The U.S. DOE classification of safety significant (SS) is the second highest level. The highest U.S. DOE classification is safety class (SC). DOE-STD-1195 is only for SS equipment in nonreactor nuclear facilities.

5-5

2004 and its predecessor, ANSI/ISA 84.01-1996, have been a source of requirements for the design of safety instrumented systems at DOE nonreactor nuclear facilities for more than 20 years.

The U.S. national standard ANSI/ISA-84.00.01-2004 is the same as the international standard IEC 61511, with the addition of a grandfather clause to accommodate existing safety instrumented system installations. Because the majority of DOE safety controls are of the on-demand mode of operation, this is the focus of the DOE standard.

For devices designed per IEC 61508, IEC 61511 Section 11.4.5 states that alternative fault tolerance requirements may be used provided an assessment is made in accordance to the requirements of IEC 61508 - 2, Tables 2 and 3. This statement directs the user to the IEC 61508 Hardware Fault Tolerance tables for Type A or Type B devices. These tables specify the number of required redundant sensors by the sensor SFF. A device designed per the IEC 61508 requirement of an SFF of >90%, Table 3 (Type B device) has the same fault tolerance requirements as stated in IEC 61511 Table 6, with a reduction of one fault tolerance. This is discussed further in the evaluation of DOE-STD-1195-2011.

The hardware fault tolerance minimum used by DOE is suited for systems dominated by single failures rather than highly redundant systems. To apply this at the component level for an EDD would require an added component in a bypass line; this would solve some problems associated with availability such as inadvertent closure of a valve, but it would create other problems such as added expense and maintenance costs.

5.1.3.1 NEET DOEs NEET program conducts R&D and makes strategic investments in research capabilities to develop innovative and crosscutting nuclear energy technologies to resolve U.S. industry nuclear technology development issues. Included in this is research to develop an effective approach employing science-based methods to resolve concerns about CCF vulnerability that serve to inhibit deployment of advanced instrumentation (e.g., sensors, actuators, microcontrollers) with EDDs in nuclear power applications. Other NEET activities are working on developing advanced capabilities for EDDs. As such, the NEET research can be useful for future applications of EDDs rather than current applications.

NEET workshop In July 2016, NEET held a workshop to address EDD issues [226]. The workshop included over 50 participants with representatives from various government, industry organizations, utilities, universities, and vendors.

The information covered in the workshop presentations is summarized below by group.

EDDs: NRC Perspective The key issues related to EDDs are sufficient procurement and control, identification of EDDs in procured equipment, adequate quality and reliability, and management of potential software-related CCFs. The NRC recognizes that existing regulations, policies, and acceptance criteria for software-related CCFs may require updating and clarification.

5-6

EDDs: Utility Perspective Discovery of low-level EDDs can be challenging, and adequate consideration of EDDs resulting in potential software-related CCFs is not always straightforward to licensees. In addition, plants must be vigilant in procurement planning and supply chain control to ensure that safety-related equipment with EDDs complies with all regulatory guidance. The industry needs improved and revised NRC-endorsed guidance to facilitate the implementation of digital upgrades and modifications under 10 CFR 50.59. In addition, to help the industry resolve software related CCF issues, digital guidance that is relevant to the capabilities and function of the EDD is important.

Vendor Perspective: Qualification of EDDs Because software failures are difficult to detect, classify, and correct, qualification of EDDs has been a significant hurdle to its implementation. The nuclear industry needs tools to measure software reliability and fault tolerance. The results of extensive testing on a digital system via the introduction of hardware and software faults proved that traditional statistical testing methods alone are not enough to detect all errors, and in some cases, a combination of testing methods is required to discover the error.

Classification Methods Based on its findings from a survey of EDDs in general use and an evaluation of the functional impact of EDD failures, the NEET program proposed a four-category classification structure [118]:

• No impact: the digital functionality should have no connection to the analog electrical or mechanical elements of the instrument other than through nonintrusive or passive measurement.

• Low impact: the digital functionality may be connected to the analog electrical or mechanical elements of the instrument and may be able to influence the output or performance of the instruments fundamental function.

• High impact: the digital functionality is likely to be integral to the analog electrical or mechanical elements of the instrument and is able to affect and potentially compromise the output or performance of the instruments fundamental function.

• Critical impact: the digital functionality is highly integrated with or replaces the analog electrical or mechanical elements of the instrument and is essential to the execution, output and/or performance of the instruments fundamental function.

The classification structure is based on the high-level characterization of potential impact of failure of an EDD on an instruments performance of its fundamental function. The focus of the classification framework is to better characterize the role of the EDD in accomplishing the safety function of the instrument. Basically, the approach is to determine and/or verify the various responsibilities of EDDs so that the potential impact on the safety function(s) of from a software CCF can be classified to enable establishment of a graded scheme for determining the level of evidence and extent of analysis necessary to assess whether a device is subject to CCF.

The classification framework can provide a means of preprocessing information about equipment with an EDD to support a determination of when and how a diversity and defense-in-depth analysis should be performed. For example, if equipment with an EDD is classified as no impact, 5-7

then it is reasonable to conclude that there is no credible CCF vulnerability and a diversity and defense-in-depth analysis should not be necessary. For the other classes, further assessment is needed to address any prospective failure modes that could degrade the instruments performance. Depending on the expected impact of a digital failure, it may be possible to identify defensive measures or testing to reasonably confirm that malperformance of the digital functionality provided by the EDD cannot inhibit or compromise the instruments fundamental function nor induce spurious action.

The NEET project also devised an analysis approach that extends the customary diversity and defense-in-depth analysis to account for the significance and functional impact of potential failures of an EDD and to enable a graded analysis approach based on the classification of EDDs. The proposed assessment approach for systematically evaluating the potential impact of prospective CCF vulnerabilities for equipment with an EDD is described below.

• The presence of an EDD should be reviewed, and all specifications to vendors should include requirements that any EDD be identified and that sufficient documentation of the quality of any commercial equipment be provided (as noted in RIS 2016-05).

• If equipment with an EDD is identified, then the role of the digital device in the performance of any safety-related function either performed or supported by the equipment should be investigated. If it is determined that the EDD has an impact on the equipment performance or sufficient information on the role of the EDD is not available, then further assessment of the potential for CCF vulnerabilities should proceed.

• In accordance with the approach identified in BTP 7-19, the two criteria for which it is considered that the potential for CCF is resolved are (1) there is sufficient internal diversity incorporated in the equipment or the design of the EDD, and (2) the software or software-designed logic is sufficiently simple that it has been or can be fully tested. If either condition can be demonstrated, then no further analysis would be necessary. If the vendor does not provide or have such information available, then further assessment of the potential for CCF vulnerabilities should proceed.

• The performance characteristics of the equipment should be evaluated to determine the nature of its failure response. Given that this assessment applies to equipment rather than systems, a key question for the evaluation is whether the equipment performs a function for which failure is self-revealing (e.g., its failure readily observable). If there is not direct, short-term indication of failure (e.g., failure responses such as fail as is or incorrect but plausible),

then the evaluation should consider whether failure of the equipment can be detected through available or additional monitoring.

At this stage, the assessment of equipment with an EDD transitions to the conventional diversity and defense-in-depth analysis.

If the considerations described in the assessment approach above do not fully resolve the potential impact of CCF in equipment with an EDD, then the equipment should be further treated as part of the conventional diversity and defense-in-depth analysis. The assessment of equipment with an EDD, including the results of a diversity and defense-in-depth analysis, are expected to demonstrate that there is sufficient defense-in-depth and diversity to cope with a postulated digital CCF of the EDDs in equipment of the reactor trip system (RTS) and ESFAS, including the credited control systems.

5-8

Model-Based Testing Initial research was performed towards development of a cost-effective testing framework focused on automated generation of mutant operators, establishment of a hardware simulator platform, and adoption of a smart sensor prototype to serve as an initial basis for developing the testing framework [228]. The fundamental technical development underway for this research involves establishment of a cost-effective qualification framework that incorporates model-based testing to support determination of whether equipment with an EDD is vulnerable to CCF. The approach for model-based testing has been generated, a suitable prototype intelligent device has been devised and emulated in a simulation environment, and the basic elements of a testing environment have been developed. The model-based testing methodology under development is based on an extension of a software testing technique known as mutation testing. In this approach, tests are developed based on hypothesized software faults arising from requirements, design, and coding sources.

Other NEET Projects of Interest Other reports/articles of interest developed under the NEET project include the following:

• Development and Demonstration of a Model Based Assessment Process for Qualification of Embedded Digital Devices in Nuclear Power Applications (Summary report of workshop)

[229]

• Embedded Instrumentation & Control for Extreme Environments (ORNL) [230]

• Qualification of Embedded Digital Devices in Instrumentation (ORNL) [231]

• Verifiable Digital I&C and Embedded Digital Devices for Nuclear Power (EPRI) [232]

5.1.3.2 Light-Water Reactor Sustainability (LWRS) Program DOEs Light-Water Reactor Sustainability (LWRS) program is addressing the qualification of digital devices for safety-related applications by [233]:

• Addressing CCFs associated with digital I&C systems

• Developing an architectural viewpoint that seeks to maximize reasoning, transparency and evidence while avoiding unnecessary complexity (SymPLe)

• Developing a verifiable architecture such as an accessible CPU-based architecture-but without its complexity where function blocks are the execution functions

• Limiting what a device can do by trading computational power for verifiability Another LWRS program is the Development of Model Based Assessment Process for Qualification of Embedded Digital Devices in NPP Applications [234]. The model-based testing (MBT)includes:

• Development of an MBT method to demonstrate proof of operational reliability

• Testing of a digital device using both MBT and conventional black box approaches 5-9

• Seed a number of test cases involving mutants or defects ranging from software specification to code in the software

• Detection of faults arising from multiple phases of the software lifecycle

• Implementation and execution time comparable or less than black box testing

• Detection of faults that are not detectable through conventional testing 5.1.3.3 Operational Experience DOE owns many nuclear reactors and nonreactor nuclear facilities. The use of EDDs is migrating to these facilities, and DOE is vigilant in ensuring the safety of workers and the public. Guidance and implementation of EDDs into several DOE-owned facilities is provided below. Because these are operating facilities the information can be useful in the use of EDDs at NPPs.

HFIR The engineers at ORNLs HFIR are actively pursuing upgrades in systems that no longer have commercially available analog replacement parts. This is a good example for the use of EDDs in replacement components.

HFIR is developing methods of testing and calibrating devices that contain EDDs. The engineers at HFIR classify devices in two formsconfigurable or modifiableby asking whether changes can be made to the software on the EDD. If changes cannot be made to the software, then it is classified as configurable. This directly correlates with the IAEA NE series report where the COTS is configurable but not programmable [235]. Examples of types of firmware are listed as follows:

• Nonconfigurable, nonmodifiable firmware: oven controller, diesel generator, pump

• Configurable, nonmodifiable firmware: fire alarm control panel, flow meter, spectrometer

• Modifiable firmware: PLC, PAL, PLA, CPLD, FPGA Its classification of the firmware determines the level of testing and calibration of the devices. To assess the risk of the firmware, the task group for HFIR suggests users to assess what can go wrong, to determine which risks are important to address, and to implement actions to address those risks. Once the embedded software is classified as configurable and not modifiable, a dedicated testbed and calibration system are developed following EPRI NP-5652 [73] guidelines.

The engineers at HFIR first develop a procedure to enable the following tests to be performed:

simulation test, functionality test, and failure test. The simulation test determines if the code performs the correct calculations. This can be viewed as a black-box test of the software where several known inputs deliver known outputs and any unknown outputs are failures. To perform the functional test physical hardware connects to the testbed to verify that it will perform the operation designated to it, i.e. a motor runs at a set speed or a valve opens/closes. Finally, the failure test is used to inject faults into the system. For example, the failure test might open the breaker supplying power to the PLC to ensure that all outputs fail to their designated position.

HFIR staff are currently designing a servo-system upgrade that is built on a redundancy backup design where three systems are installed to perform a single function. Under this design, if two servo-systems went offline, then the function would still be performed by the third servo-system.

5-10

One of the three servo-systems was recently upgraded to include EDDs. Following the steps described above, the system was first identified as configurable but not modifiable. The upgrade was divided into three phases: the prototype, design, and implementation phases. In the first phase of the project, the prototype phase, the team completed a quick design, built a prototype, and had the customer (HFIR) evaluate it. If the customer evaluation had returned with required changes, then the process would have started over again. This iterative process continued until the customer (HFIR) approved the prototype, and then the project moved into the design phase.

In the design phase, there was a formal gathering of requirements and SQA, including SQA umbrella documents for risk analysis, security plan, backup and recovery plan, change evaluation, tracking matrix, compliance matrix, procurement tracking, safety evaluation, training, and document control. The third phase included implementation, V&V, and installation and maintenance. Verification includes tests and inspections that ensure the software satisfies the system requirements. Validation includes tests and inspections that ensure the software performs correctly. V&V should be performed throughout the development and implementation of the software life cycle. HFIR was successful in the upgrade of the servo-systems in 2018.

LAWPS DOE is planning to design and build a Low-Activity Waste Pretreatment System (LAWPS) at the Hanford Site Farms to remove radioactive cesium and solids from some Hanford tank waste.

DOEs Defense Nuclear Facilities Safety Board (DNFSB) determined that the proposed alternative methodology for determining the SIL of the instrumented systems does not provide an equivalent level of safety as required by DOE Order 420.1C.

DOE Order 420.1C requires safety significant SSCs to be designed to reliably perform all of their safety functions. The order states that this can be achieved through a number of means, including use of redundant systems/components, increased testing frequency, high reliability components, and diagnostic coverage (e.g., on-line testing, monitoring of component and system performance, and monitoring of various failure modes). The order also requires that the facility design include multiple layers of protection (as part of the design defense-in-depth) to prevent or mitigate the unintended release of radioactive materials to the environment.

DOE Std. 1195 provides requirements and guidance for the design, procurement, installation, testing, maintenance, operation, and quality assurance of safety instrumented systems with safety significant functions at DOE nonreactor nuclear facilities. This standard covers safety-significant safety instrumented systems that contain analog or digital components. Those analog or digital components include switches, electrical relays, analog transmitters, computer-based systems consisting of embedded hardware and software components (such as programmable logic controllers, smart transmitters with built-in logic functions, and microprocessor-based monitoring systems), and final control devices. Embedded software is defined as software that is part of the system supplied by the manufacturer and is not accessible for modification by the end user.

Embedded software is also referred to as firmware or system software.

The methodology for LAWPS used the hazard frequency as the principal factor in determining SIL requirements; this is a key difference from the DOE Standard 1195 approach, which is based on the number of IPLs that exist to mitigate the hazard. The proposed methodology yields a SIL-1 design requirement for cases in which DOE Std. 1195 would require a SIL-2. DOE Std. 1195 allows a SIL-1 design if additional IPLs are identified and credited in the safety basis or if a failure of the safety instrumented system is not expected to result in a facility or collocated worker fatality.

Specifically, the use of the alternative methodology may result in safety instrumented system designs that do not meet DOEs intent for reliable performance, as well as safety strategies that 5-11

do not incorporate defense-in-depth [199]. Although this does not pose safety consequences for LAWPS, a similar application of the alternate methodology to other facilities may yield unacceptable consequences.

MOX The MOX facility is being built at SRS in South Carolina. The design, license, construction, and operation are contracted to Shaw AREVA MOX Services, LLC. The Mixed Oxide Fuel Fabrication Facility will be an NRC-licensed facility [236].

The MOX project is a National Nuclear Security Administration (NNSA) facility that will convert surplus plutonium (Pu) from nuclear weapons into MOX fuel for use in U.S. commercial NPPs.

MOX currently has 35 vendors on its approved commercial grade vendors list. CGIs for the MOX project are purchased directly by MOX Services. For MOX, the audited and approved suppliers have Part 21 responsibility while the nuclear suppliers can be held accountable through contracts, legal actions, and market place. That is, DOE holds the licensee responsible while MOX Services performs the dedication.

10 CFR 70.22(f) requires licensees to have a description of the quality assurance program to be applied to the design, fabrication, construction, testing and operation of the structures, systems, and components of the plant. The description of the QA program should include a discussion of how the criteria in Appendix B of part 50 of this chapter will be met. MOX Services has stated that the Application forplutonium processing and fuel fabrication facility shall containa description of the quality assurance program.

The CGD process for the MOX project is based on EPRI NP-5652. The projects commercial grade item evaluations (CGIEs) develop the technical, quality and documentation requirements for CGIs and establishes critical characteristics for acceptance (CCAs), acceptance criteria, and acceptance methods, and it develops input that controls and documents procurement and dedication activities.

Increased communication, monitoring, and controls are required of suppliers with CGD-related restrictions, depending upon the nature of the restriction.

Vendor-related lessons learned reported by MOX Services include:

• The results stemming from commercial grade surveys must be accounted for when developing the procurement strategy for how to establish a supply chain for a CGI.

• Know your suppliers (and your suppliers supplier) fabrication and CGD processes.

• Demand objective evidence that suppliers and sub-suppliers have appropriate QA programs and CGD processes in place to assure implementation is effective.

• Experience has shown that vendors of items relied on for safety (IROFSs) vary dramatically in their knowledge of standard sampling plans and implementation of sampling plan methodology.

• Vendor communication with project CGD group is very important.

o Placing CGD personnel in the vendor shop can be very beneficial.

5-12

• Aggressive management and oversight of NQA-1 vendor CGD programs is prudent.

o Review all vendor CGD plans and procedures initially.

o Reviews may be lessened when confidence is gained with vendor programs.

• The CGD acceptance process needs to be closely coordinated with receipt inspection capabilities.

5.1.4 Federal Aviation Administration (FAA)

Aerospace Recommended Practice (ARP) 4754A [237] is a guideline from SAE International dealing with the development processes which support certification of Aircraft systems. It was recognized by the FAA in AC 20-174. The European Organisation for Civil Aviation Equipment (EUROCAE) jointly issues the document as ED-79. See EUROCAE for a description of ARP 4754 and its relationship to IEC SILs.

FAA tailored IEEE/EIA 12207.0 and IEEE/EIA 12207.2 for the procurement of computer software products and services to meet FAA-STD-026A [169]. Only the sections specifically identified in the FAA standard are requirements of the FAA.

The civil aviation industry software classification system is different from the aerospace industry because the classifications are based on effects of anomalous behavior of the software rather than software functionality. Unlike the aerospace industry, which assigns software tools with a classification separate from embedded system software, the civil aviation industry classifies software tools to the same level as the software developed with the tool.

RTCA DO-178B classifies software using the FAAs five failure levels to characterize the impact of that particular softwares failure on an aircraftranging from Level A (catastrophic) to Level E (no effect on the operational capability of an aircraft)and it prescribes more stringent criteria at higher levels. DO-178B tends to focus more on eliminating defects than on preventing their introduction in the first place.

The primary method of tool qualification in accordance with RTCA DO-330 [71] is development, verification, and validation in accordance with a high-quality, well-organized software tool development life cycle process. Alternative tool qualification methods include using service history, exhaustive input testing, formal methods, and use of dissimilar tools. Unlike most other industries that superficially address COTS software tools, RTCA DO-330 provides a comprehensive qualification process for COTS tools that divides qualification responsibilities between the COTS developer and tool user [67]. RTCA DO-330 contains a tool qualification liaison process that contains similar activities and tasks as DI&C-ISG-to facilitate the review and approval of software tools.

RTCA DO-330 also provides alternative tool qualification methods of using service history, exhaustive input testing, formal methods, and use of dissimilar tools. These alternative methods are analogous to CGI dedication when there is not much information available from the vendor beyond the published product description and a users manual, and commercial-grade surveys (similar to EPRI Method 2) or source verifications (similar to EPRI Method 3) are impractical, leaving only special tests and inspections (similar to EPRI Method 1) and use of supplier and product performance history (similar to EPRI Method 4). The use of service history is analogous to EPRI Method 4.

5-13

The corresponding process of CGD for the aerospace industry is called qualification.

With respect to lessons to be learned from the FAA for EDDs in NPPs, the aerospace industry characterizes the software by failures on the system and uses five levels of failures whereas the civil aviation industry uses only one level of classification. Tool qualification is through V&V and testing, but also allows alternative methods such as service history and use of dissimilar tools.

5.1.5 Food and Drug Administration (FDA)

Among the products the Food and Drug Administration (FDA) regulates its treatment of medical devices is most relevant to EDDs, as some of those devices would employ EDDs. No regulations or guidance could be found at the component level when searching the FDA databases on regulations and guidance.

The FDAs guidance document on software validation [238], like the IECs, has a lengthy section on testing techniques and discusses how the level of criticality should determine the level of testing. It recognizes the limitations of testing and suggests the use of other verification techniques to overcome these limitations, but it does not specify what these might be.

Medical software is generally not subject to uniform standards and certification. However, the larger manufacturers often voluntarily adopt a standard such as the IEC 61508 or its U.S.

equivalent, ISA S84.01. Thus, medical devices use IEC SILs to promote safety.

Medical devices have three software safety classificationsMedical Device Class A, B, and C.

Under IEC 62304, , an industry-specific adaptation of IEC 61508, medical devices are classified based on the amount of injury that could be caused to a patient, an operator, or an onlooker.

Annex I of the Quality Risk Management guidance for industry [239] provides a general overview of and references for some of the primary tools that might be used in quality risk management by industry and regulators. The FDA recognizes IEC 60812 [240] as a method that can be used to prioritize risks and monitor the effectiveness of risk control activities. The FMEA can be applied to equipment and facilities and might be used to analyze a manufacturing operation and its effect on product or process. It identifies elements/operations within the system that render it vulnerable.

The output/results of FMEA can be used as a basis for design or further analysis or to guide resource deployment.

Of interest to the use of EDDs in NPPs, the FDA allows OEMs to prioritize risks through the use of analyses such as FMEAs.

5.1.6 Federal Energy Regulatory Commission (FERC)

Federal Energy Regulatory Commission (FERC) is the federal agency that regulates the transmission and wholesale of electricity and natural gas in interstate commerce and regulates the transportation of oil by pipeline in interstate commerce. FERC also reviews proposals to build interstate natural gas pipelines, natural gas storage projects, and liquefied natural gas (LNG) terminals, in addition to licensing non-federal hydropower projects.

The major orders and regulations for FERC were searched for specific guidance at the device level [241], but no guidance was found. At a higher level, there are five core IEC smart grid families of standards that have been recommended by the National Institute of Standards and Technology (NIST) for U.S. smart grid projects (Table 5-2). They have also been referenced in 5-14

smart grid roadmaps published in several countries around the world, including the United States, Germany, and China.

Table 5-2 Smart Grid Standards Developed by IEC Suite of standards - description Number Telecontrol equipment and systems IEC 60870 Facilitate exchanges of information between control centers consists of 37 parts Substation automation IEC 61850 Communication networks and systems in substation consists of Facilitates substation automation, communication and interoperability 18 parts through a common data format Common information model (CIM) / energy management IEC 61970 Energy management system application program interface (transmission) consists of 11 parts Common information model (CIM) / distribution management IEC 61968 Application integration at electric utilities - system interfaces for distribution consists of 7 parts management Security IEC 62351 Power systems management and associated information exchange - data consists of 7 parts and communications security addresses the cyber security of the communication protocols defined by the preceding IEC standards An intelligent electric grid allows the two-way flow of information and power. There are six key characteristics of an intelligent energy system:

1. Self-healing to rapidly detect, analyze, respond, and restore

2. Empowered and incorporating the consumer to incorporate consumer equipment and behavior in design and operation

3. Tolerant of attack to mitigate and be resilient to physical and cyber attacks

4. Providing necessary power with a power quality consistent with current consumer and industry needs

5. Accommodating a wide variety of supply and demand, including all distributed resources

6. Fully enabling maturing electricity markets to allow for and be supported by competitive markets To fulfill a requirement of the Energy Policy Act of 2005 (EPAct 2005) section 1252(e)(3), FERC prepares and publishes an annual report that assesses electricity demand response resources, including those available from all consumer classes. The report evaluates the demand response and advanced metering. At the consumer end, advanced metering systems are comprised of state-of-the-art electronic/digital hardware and software, which combine interval data measurement with continuously available remote communications. These systems enable 5-15

measurement of detailed, time-based information and frequent collection and transmittal of such information to various parties. Advanced metering infrastructure (AMI) typically refers to the full measurement and collection system that includes meters at the customer site (e.g.,

programmable communicating thermostats and smart appliances), communication networks between the customer and a service provider, such as an electric, gas, or water utility, and data reception and management systems that make the information available to the service provider.

AMI systems offered by different vendors will be required to conform to standards established by ANSI.

The standards used by FERC work together to achieve homogeneous communication systems to allow users to interoperate seamlessly. They also minimize the need for costly gateways and adapters that increase complexity and risk. They are already widely used in the industry by integrators (IEC Common Information Model [CIM]) and by manufacturers (IEC 61850). The requirements for a smart grid have to allow a more forgiving system expecting failures. Thus, the overall requirements specific to smart grids are not appropriate for use in EDDs in NPPs.

5.1.7 Federal Railroad Administration (FRA)

The purpose of the FRA is to promulgate and enforce rail safety regulations, administer railroad assistance programs, conduct research and development in support of improved railroad safety and national rail transportation policy.

49 CFR Chapter II, Appendix F to Part 229Recommended Practices for Design and Safety Analysis cites the latest versions of EN 50128/IEC 62279 and EN 50129, and IEC 61508 as being recognized by FRA as providing appropriate risk analysis processes for incorporation into verification and validation standards. With the use of IEC/BS EN standards, the FRA uses IEC SILs to promote safety.

EN 50128 [171] and EN 50129 are two European standards (EN 5012x) that define safety-related software process standards, hardware, and approval processes for railway applications. EN 50128 provides process standards for software for railway control and protection systems. EN 50129 covers safety-related electronic systems for signaling.

Even though the safety lifecycles for the industry-specific standards, such as EN 50128 13 for a 12F railway, inherit the definition of phases from the generic IEC standard of IEC 61508, the detailed phases of the safety lifecycles for the specific industries are different from IEC 61508.

BS EN 50128 [171] is a railway-specific implementation of IEC 61508 and specifies technical requirements for the development of safety-related software for railway control and protection systems. The railway industry uses a probabilistic risk-based process for safety-related system and software development.

The railway industry essentially uses the IEC SIL classification for components. As this is not currently used for EDDs in U.S. NPPs, its value is in the review and possible acceptance of IEC SILs.

13 The international version of EN 50128 is identical to IEC 62279.

5-16

5.1.8 National Aeronautics and Space Administration (NASA)

NASA does not provide specific verification, validation, or qualification requirements for most COTS, GOTS, or MOTS software tools and expects that automatically generated code be treated at the same level as hand-generated code [67].

Similar to other industries, NASA documents state that software tools used in developing software used in safety-critical systems should be identified, and the level of rigor associated with the verification, validation, and accreditation of software tools should be determined by the tool functions and the safety classification of the systems in which the software will be used [67].

NASA documents identify and recommend tools for many of the software engineering processes and define QA requirements for software tools. NASA uses a software classification system that is unique to the industry in that embedded system software, support software, software tools, and routine office software are all covered by the single classification system. NASA requires that an independent QA organization classify software tools to verify proper classification [67].

Using the consequence-based approach in NASA-GB-8719.13 [208] (NASA-GB-8719.13 supersedes NASA-GB-1740.13), the consequences of the device failure are evaluated, along with its impact on the system. This document cites both IEEE and IEC standards. The guidebook states that an operating system certified to the safety standard IEC 61508 is acceptable. The IEC standard IEC 61508 is currently under review by NASA to determine its acceptability as an international standard on software safety for products which contain programmable electronic systems (PESs) [70].

NASA-GB-8719.13 encourages the use of simulators or an in-circuit emulator (ICE) system for debugging in embedded systems because these tools allow the programmer or tester to find some subtle problems more easily. However, the guidebook does not discuss simulator or ICE system verification, validation, qualification, review, or approval practices.

NASA-STD-7009 [242] provides an approved set of requirements, recommendations, and criteria with which models and simulations (M&S) may be developed, accepted, and used in support of NASA activities.

With respect to complex electronics, NASA noted that [243]:

• Logic errors are still common in space-flight projects, with bad circuits making it into flight hardware

• A fundamental issue is how the complexity is managed to permit reliable design NASA guidance cites both IEEE and IEC standards. Of interest to EDDs is that NASA classifies the software and the software tools by a single classification system. It is important to note that the consequences of the device failure are evaluated, along with its impact on the system.

5.1.9 Occupational Safety and Health Administration (OSHA)

Title 29 CFR 1910.119 [244] contains requirements for preventing or minimizing the consequences of catastrophic releases of toxic, reactive, flammable, or explosive chemicals.

These releases may result in toxic, fire or explosion hazards. The process safety management (PSM) standard for OSHA, directs or implies the use of recognized and generally accepted good 5-17

engineering practice in the following sections, as opposed to prescriptively specifying particular equipment design and performance requirements. There are no specific requirements regarding consideration of the potential for CCF vulnerability or the use of diversity.

Many industries use IEC SILs to comply with OSHA regulations.

In a March 2000 letter to ISA, OSHA identified compliance with ANSI/ISA 84.00.01 (IEC 61511 Mod) as an acceptable implementation of recognized and generally accepted good engineering practice [245]. The use of ANSI/ISA 84.00.01 (IEC 61511 Mod) within industries that involve hazardous processes stems from the concept of recognized and generally accepted good engineering practice. ISA 84.00.01 is a performance-based standard.

The IEC 61508 standard then comes into play through ANSI/ISA 84.00.01 (IEC 61511 Mod),

which identifies the methodology of acceptance of equipment for use in safety systems by certification to IEC 61508.

The industries this applies to are any that fall under the purview of OSHA which, at a minimum, would include the oil and gas processing industry and the chemical processing industry. IEC 61511 is also embraced in a similar manner internationally. For example, the United Kingdom implements a very similar approach through their Health and Safety Executive (HSE) Control of Major Accident Hazards (COMAH) regulations.

There are many equipment manufacturers who use IEC 61508 for their development and certification process. These manufacturers supply products to industries that have implemented IEC 61511 (or ANSI/ISA 84.00.01) in a manner that allows for simplified acceptance of equipment for use in safety applications.

These manufactures apply the development requirement of IEC 61508 to the hardware and software of their products, which encompasses EDDs. The IEC 61508 requirements drive built in quality into the products through implementation of systematic integrity, low probability of failure, detection of failures, and management of failures (fail-to-safe state).

OSHAs Nationally Recognized Testing Laboratory (NRTL) Program recognizes private sector organizations to perform certification for certain products to ensure that they meet the requirements of both the construction and general industry OSHA electrical standards. Each NRTL has a scope of test standards that they are recognized for, and each NRTL uses its own unique registered certification mark(s) to designate product conformance to the applicable product safety test standards.

OSHA created the NRTL program to ensure that certain types of equipment be tested and certified for their safe use in the workplace. OSHAs NRTL regulations were established in 1988.

The first organization became recognized as a NRTL in 1989.

A Nationally Recognized Testing Laboratory (NRTL) is a private-sector organization that OSHA has recognized as meeting the legal requirements in 29 CFR 1910.7 to perform testing and certification of products using consensus-based test standards. These requirements are [246]:

• The capability to test and evaluate equipment for conformance with appropriate test standards; 5-18

• Adequate controls for the identification of certified products, conducting follow-up inspections of actual production;

• Complete independence from users (i.e., employers subject to the tested equipment requirements) and from any manufacturers or vendors of the certified products; and

• Effective procedures for producing its findings and for handling complaints and disputes An organization must have the necessary capability both as a product safety testing laboratory and as a product certification body to receive OSHA recognition as an NRTL.

OSHAs standards contain requirements for NRTL product testing and certification for 39 product types. For example, in 29 CFR 1910.303, OSHA requires NRTL approval for many kinds of electrical equipment when they are used in the workplace. OSHAs website contains a listing of the type of products requiring NRTL approval [247].

After certifying a product, the NRTL authorizes the manufacturer to apply a registered certification mark to the product. If the certification is done under the NRTL program, this mark signifies that the NRTL tested and certified the product, and that the product complies with the requirements of one or more appropriate product safety test standards.

The CE mark is unrelated to the requirements for product safety in the United States. It is a generic mark used in the European Union (EU) to indicate that a manufacturer has declared that the product meets regulatory requirements in the EU that may or may not include product safety.

In the United States, under OSHAs NRTL requirements, the product must have the specific mark of one of the NRTLs recognized to test and certify this type of product.

Of specific interest to EDDs in NPPs is that OSHA directs or implies the use of recognized and generally accepted good engineering practice. For this, many industries use IEC SILs for both hardware and software.

5.2 International Nuclear Regulating Agencies International regulatory practices with EDDs were reviewed to learn how others regulate and implement EDDs and to possibly leverage their experience into the framework of NRC regulations and guidance (Table 5-3). Inconsistency and ambiguity within and between standards for the classification of safety systems and functions necessitates a more comprehensive review of how guidance and standards are implemented for approving the use of EDDs in U.S. NPPs. However, the classifications for safety in many countries are divided more finely than in the United States and could provide insights on dividing the broad safety classification into more levels while maintaining safety.

5-19

Table 5-3 Countries Reviewed for Regulations and Guidance on the Use of EDDs Country Canada France Germany India Japan Korea Pakistan Romania Russia UK All countries review the information provided by the applicant for compliance with the applicable regulatory requirements [248]. In addition to document reviews, some countries use onsite audits and inspections to confirm that the regulatory requirements have been met. For example, in India, Korea, and the United States, audits or inspections are used in the review of various I&C-related technical topics. In India, an audit of system development life cycle documents (including V&V and QA documents) is performed as part of the review of software reliability. In the United States, inspections are used to evaluate the implementation of a licensees cybersecurity program.

In all cases, the technical basis for regulatory authorization is provided by a combination of country-specific regulations and regulatory guidance. In addition to the regulations and guidance documents, most countries make use of either national or international consensus standards related to I&C.

Korea, Pakistan, and the United States refer to the IEEE standards as part of the technical basis for regulatory authorization.

India and Russia identified the use of IAEA standards as the basis related to their review of I&C.

In Russia, IAEA Safety guide No. NS-G-1.3 and IAEA Draft Safety Guide DS-431 provide part of the technical basis for granting regulatory authorization in several technical topics. Also, in India, IAEA standards or other acceptable codes are used to review specific areas where Atomic Energy Regulatory Board (AERB) documents have not been prepared.

Canada, France, Germany, and the UK identify IEC standards as part of the technical basis for granting regulatory authorization. The most commonly identified IEC standards were IEC 60880, IEC 61513, and IEC 62138. The use of IEC 61511/IEC 61508 would leverage the economies of scale achieved in other industries to those of the nuclear industry. Other certifications are CSA for Canada, ATEX for Europe, and KGS for Korea. For example, CSA 61511 14 is the Canadian 13F version of IEC 61511.

14 IEC standards adopted by Canada as national standards are published as CSA standards by the CSA Group (formerly the Canadian Standards Association). ANSI does this for the United States and the British Standards Institute (BSI) for the United Kingdom. ANSI tends to keep the originating standards body ID in the standard title as in ANSI/ANS or ANSI/IEEE, when it adopts something as a national standard.

5-20

Canada, France, and the UK also have their own regulations and guidance in addition to standards developed by IEEE, IAEA, and IEC.

Those countries with multiple safety classifications incorporate function or consequence into the safety classification. For example, in evaluating a component or system, the UK first identifies the safety function of the device and then evaluates how the SSCs deliver those safety functions and their significance to safety. Similarly, Germany considers the safety functions in its classification of safety SSCs. Since 2016, France now considers devices of limited functionality. India, with its three safety categories, considers the consequences of the failure rather than the function.

The nature of the UK regulatory regime is not prescriptive; however, the UK does support international standards that may be prescriptive. Conversely, the NRC uses many standards that may be considered to be overly prescriptive but by considering standards that are performance based may provide some grading of design attributes.

The Canadian regulatory structure does not include a requirement for vendors to produce equipment in compliance with a nuclear-specific QA program. However, CSA N286 is included in plant licenses and there are no QA requirements regulated down to suppliers. The scope of N286 is only the plant. CSA N299 (formerly Z299) does exist for suppliers but it is only guidance.

These standards are interesting, in that they are implemented using a graded approach. There are different versions of this standard for each of the four safety categories of equipment. Each version is designated with a .1, .2, .3, or .4 suffix corresponding to the applicable safety category.

There is also no defect reporting regulation for suppliers, rather the licensees have obligations to report defects after an event of consequence occurs. No regulation exists that requires licensee or suppliers to report component defects when no consequential event has occurred. Note that in Canada the CGIs still undergo a certification process similar to the CGD. Interesting is that CSA N290.14-15 provides guidance for determining an items complexity based on lines of code, number of internal modules, and an interface complexity index.

The most commonly used route for qualification of a digital system in Germany is to build on an existing commercial certificate of compliance to an industrial standard such as IEC 61508 and have the device certified by an assessor such as TÜV. When an already-qualified device is to be re-used in another application, the qualification process can claim credit for an existing pre-qualification. Generic qualification is also possible, which can be used as a basis for an application-specific qualification In India, before a smart device can be used, a review is performed to ensure that device is qualified for use in an NPP. This review requires that the device meets functional and performance requirements that are evaluated with testing (e.g., accuracy, EMI/EMC, seismic, etc.), has extensive operating experience, both inside and outside of the nuclear industry for the same model and software version of the device, has a well-established design process that was used throughout the lifecycle, the HRA and FMEA have been performed,failure modes are predictable, and the manufacturing process was dependable, including ISO-9001 certification, version control, history, and problem reporting. If the device has networking features, then the devices are evaluated for cyber security concerns. The evaluation, which uses a graded approach, evaluates software to IEC 60800, IEEE Std. 603, IEEE Std. 7-4.3.2, and Indias AERB SG-D-25. AERB SG-D-25 refers to IEC standards. Additional (and practical) requirements for software in smart devices include the simplicity of the software without additional features, secondary function, and no unused code or features.

5-21

The common position paper, Licensing of Safety Critical Software for Nuclear Reactors [249],is the result of the work of a group of regulator and safety authorities experts. The 2007 version was completed at the invitation of the Western European Nuclear Regulators Association (WENRA). The focus of this work was to compare the respective licensing approaches, to identify where a consensus already exists, and to see how greater consistency and more mutual acceptance could be introduced into the current practices. These common positions and recommended practices take into account not only the positions of the participating regulators, but have also been reviewed against the international guidance, the technical expertise, and the evolving recommendations issued by the IAEA, the IEC and the IEEE organisations. Within this comparison, the term software also includes firmware and microcode.

A review of the standards and the guidelines are provided in the next subsection (Subsection 6).

5.2.1 Canada The regulator in Canada is the Canadian Nuclear Safety Commission (CNSC). The CNSC is the issuer of power reactor operating licenses (PROLs) for all of Canadas nuclear power generating plants. As part of the licensing process, the CNSC ensures that safety systems are in compliance with the relevant standards.

In Canada, certain types of EDDs are referred to by the related term smart devices. With respect to regulatory guidance, the CNSC is currently in a transition period regarding the standard applicable to digital devices. The previous licensing basis referenced CSA N290.14-07 [250], but now all new licenses and re-licensing activities are referencing the second edition of this standard, CSA N290.14-15 [94] and expanding the scope to include hardware and a broader range of software. As of November 2019, Pickering Nuclear Generating Station has been re-licensed using this second edition.

It is important to understand that the Canadian regulatory structure does not include a requirement for vendors to produce equipment in compliance with a nuclear-specific QA program, such as U.S. Title 10 CFR 50 App B or ASME NQA-1, and they also do not include a U.S. Title 10 CFR 21 requirement with which all vendors must agree to comply. In Canada, the justification process is specifically an activity for design suitability or qualification, as opposed to having a separate commercial grade dedication process.

To address QA requirements, CSA N286 is included in plant licenses. However, there are no QA requirements regulated down to suppliers. The scope of N286 is only the plant. CSA N299 (formerly Z299) Quality assurance program requirements for the supply of items and services for nuclear power plants does exist for suppliers but it is only guidance. These standards are interesting, in that they are implemented using a graded approach. There are different versions of this standard for each of the four safety categories of equipment. Each version is designated with a .1, .2, .3, or .4 suffix corresponding to the applicable safety category.

There is also no defect reporting regulation for suppliers. The licensees have obligations to report defects after an event of consequence occurs in accordance with REGDOC 3.1.1 Reporting Requirements for Nuclear Power Plants, but this does not apply to suppliers. No regulation exists that requires licensee or suppliers to report component defects when no consequential event has occurred.

The system/component classification in Canada includes four levels [94]:

5-22

• Category 1: high safety significance

• Category 2: moderate safety significance

• Category 3: low safety significance

• Category 4: no safety significance Category 1 aligns well with the NRCs safety-related classification. However, the other classification categories align with the IEC SILs.

5-23

Table 5-4 Safety Categories in Canada and Alignment with Standards [94]

Category 1 Category 2 Category 3 Category 4 Standard (high safety (moderate safety (low safety (no safety significance) significance) significance) significance)

IEC 61508-5 SIL 4 and 3 SIL 2 SIL 1 Non-safety-related IEC 61513, Class 1 Class 2 Class 3 Non-safety-system classes related IEC 61226 and Category A Category B Category C Non-safety-IEC 61513, related functions COG-95-264-1 Category I Category II Category III Category IV (also known as commercial grade)

In Canada, software and digital devices are organized into four typesReal Time Process Computing (RTPC), Scientific Engineering and Safety Analysis (SESA), Managed Systems, and Business IT. Digital devices used in safety applications in the nuclear plant fit into the RTPC type.

Within RTPC there are four categories; I, II, III, and IV.

The first step of the qualification activity is to determine the appropriate category for digital item.

This determination sets the requirements to be used for determining if the digital item is suitable for the intended safety application. It is a standardized method for implementing a graded approach.

In addition to all these methods, the Canadian qualification process also includes environmental, seismic, and electromagnetic compatibility assessments that are similar to what is done for U.S.

nuclear plants.

AECL CE-1001-STD [251] specifies requirements and a minimum set of software engineering processes for safety-critical software development for CANDU nuclear generating stations.

Software tool requirements are limited to high-level requirements to identify necessary resources for tool development, identify and document tools in plans and procedures, identify personnel required to maintain and manage the tools, and identify the qualification requirements for software tools. AECL CE-1001-STD does not distinguish between different types of software tools, does not use software tool categories or classifications, and does not contain any specific software tool qualification requirements tailored to the type of tool.

Overall, the Canadian approach to justifying the use of digital devices is an interesting case study because it correlates nuclear safety classifications directly to IEC 61508 SILs, it provides a path for accepting items based on SIL certifications issued by an independent third party, it does not include 10 CFR 50 App B or 10 CFR 21 requirements, and it also includes a standardized approach to ranking the complexity of a digital item. These aspects make the Canadian regulatory structure important to maintain awareness of since many of these aspects provide valuable approaches for dealing with issues currently being dealt with in the U.S. nuclear industry.

5-24

Numerous countries are evaluating the use of IEC SILs for CGIs. Note however, that in Canada the CGIs still undergo a certification process similar to the CGD.

5.2.2 France The French Atomic Energy Commission, created in 1945, was later renamed the French Alternative Energies and Atomic Energy Commission (CEA) in 2010. CEA (French: Commissariat l'énergie atomique et aux énergies alternatives), is a French public government-funded research organization in the areas of energy, defense and security, information technologies and health technologies. All commercial nuclear reactors in France have been and continue to be built and operated by the licensee Électricité de France (EDF). In 2006, the Autorité de sûreté nucléaire (ASN) was created as the independent French nuclear safety regulator, replacing the General Direction for Nuclear Safety and Radioprotection. On behalf of the state, ASN regulates nuclear safety and radiation protection. ASN issues regulatory decisions (general technical rules) that are to be endorsed by the government and issues technical rules and prescriptions. Not legally binding, ASN also provides guides that explain how to consider the corresponding regulation.

In France, certain types of EDDs are referred to using the related terms intelligent devices, simple devices, digital device of limited functionality, and smart devices. Regulatory guidance is broadly based on the IAEA standards [252]. Other relevant standards include the IEC 45A standards (mainly IEC 61513, IEC 60880), and French basic safety rule II.4.1a.

The system/component classification in France for the N4 plants (the current generation of nuclear power plants being built and operated in France) is five levels [162, 173]:

• 1E

• 2E

• SH

• Systems important to safety

• Not important to safety The safety categories do not align well with the NRCs safety-related classification.

The system/component classification for the older plants in France is four levels [159, 161]:

• F1A: the safety functions needed to demonstrate that the plant can reach a controlled state for any design basis condition

• F1B: the safety functions needed to demonstrate that the plant can reach and be kept in a safe shutdown state up from design basis condition, for at least 24 hours2.777778e-4 days <br />0.00667 hours <br />3.968254e-5 weeks <br />9.132e-6 months <br />

• F2: the safety functions needed to demonstrate that

- the plant can be kept in a safe shutdown state up to 72 hours8.333333e-4 days <br />0.02 hours <br />1.190476e-4 weeks <br />2.7396e-5 months <br /> from any design basis conditions,

- the plant can deal with the design extension conditions up to 72 hours8.333333e-4 days <br />0.02 hours <br />1.190476e-4 weeks <br />2.7396e-5 months <br />,

- the plant can withstand the internal and external hazards considered in the design over and beyond those included in the design basis analysis

• Non safety function: any other function These safety categories also do not align well with the NRCs safety-related classification. These levels are systems and equipment are not in contradiction with IEC 61226, but are more precisely defined following the defense-in-depth principle as well as design extension corresponding to post accident conditions after 24 hours2.777778e-4 days <br />0.00667 hours <br />3.968254e-5 weeks <br />9.132e-6 months <br />.

5-25

The French regulators define what they mean by digital device of limited functionality [14]:

• The device is a preexisting digital device that contains predeveloped software or programmed logic.

• The primary function performed is well defined and applicable to only one type of application within an I&C system.

• The primary function performed is conceptually simple and limited in scope.

• The device is not designed so that it is reprogrammable after manufacturing.

• If the primary device function can be tuned or configured, then this capability is restricted to parameters related to the process.

Up until 2000, no framework for regulating a smart device or devices of limited functionality existed, and the procedure for computer-based systems had to be used. Even a simple smart device with a good operational experience record could not be qualified if it was not developed to IEC 61513 with IEC 60880 or IEC 62138.

Since 2016, the current qualification framework in France for digital devices of limited functionality is as follows:

• All digital devices of limited functionality follow IEC 62671

• Already certified digital devices of limited functionality follow IEC 61508 with audit Examples of digital devices of limited functionality include digital electrical off-the-shelf equipment such as a sensor, an actuator, an electrical protection device, etc., that is functionally simple.

RCC-E [253] provides guidance on industrial digital devices of limited functionality and introduces alternative qualification methods that credit IEC 61508 certifications. For the I&C aspects, the RCC-E relies heavily on IEC standards but clarifies an interpretation at a national level. The RCC-E identifies what is and is not relevant in a standard such as IEC 62671 within the context of equipment qualification.

The approach to qualification of software and programmed digital aspects of smart devices in France relies on the idea that smart devices are pre-existing components bought off the shelf and that requirements cannot therefore undermine previous design choices [176]. Requirements essentially address QA processes, including V&V activities as implemented by the design, and the way smart devices are used and implemented within a system. According to the qualification method, suppliers may be subjected to audit; such audits are likely to require more if there are no third-party product certifications available.

It is mportant to note that France recognizes that certifications by themselves cannot be used as a basis for qualification because licensees are responsible for what is installed in their plant [176].

This is the same as the requirements for plants in the United States.

Suppliers are required to inform EDF of any changes to a device and EDF then analyses whether the change is major or minor and what action to take [176]. This is also the same as the requirements for plants in the United States.

5-26

5.2.3 Germany In Germany, certain types of EDDs are most likely referred to using the related terms digital device of limited functionality (synonym for device of dedicated functionality) or industrial digital device based on IEC terminology. Regulatory guidance is primarily based on the requirements defined by the German government [254] and nuclear regulator [255], which refer to the dedicated national standards relevant for hardware and software qualification. The approach is based on IEC standards such as IEC 61513, IEC 60880, and IEC 62138. DIN EN 61226 is the German version of IEC 61226. VDI/VDE 3528 [256] sets the regulatory expectations for COTS products.

The standards establish the criteria and methods to be used to assign the I&C functions of an NPP to three categories A, B, and C, which depend on the importance of the function for safety, and an unclassified category for functions with no direct safety role. The system/component classification in Germany, based on the definitions in IEC 61226, includes three levels for function:

• Category A: denotes the functions that play a principal role in the achievement or maintenance of NPP safety to prevent DBE from leading to unacceptable consequences.

• Category B: denotes functions that play a complementary role to the category A functions in the achievement or maintenance of NPP safety, especially the functions required to operate after the non-hazardous stable state has been achieved, to prevent design basis events (DBE) from leading to unacceptable consequences, or mitigate the consequences of DBE.

• Category C: denotes functions that play an auxiliary or indirect role in the achievement or maintenance of NPP safety. Category C includes functions that have some safety significance, but are not category A or B.

The safety categories do not align well with the NRCs safety-related classification.

The German equipment qualification applies to the approach prescribed by VDI/VDE 3528 [256].

This guideline describes the basic approach and boundary conditions for equipment qualification of commercial grade products, by intended use in nuclear I&C technology. The aim of VDI/VDE 3528 is to realize or preserve an I&C system with required reliability by use of components that are qualified according to industrial standards.

The most commonly used route for qualification of a digital system is to build on an existing commercial certificate of compliance to an industrial standard such as IEC 61508 and have the device certified by an assessor such as TÜV. When an already-qualified device is to be re-used in another application, the qualification process can claim credit for an existing pre-qualification.

Generic qualification is also possible, which can be used as a basis for an application-specific qualification [176].

When a COTS product is to be used for a category A or B function, an independent expert appointed in accordance with German law also performs a suitability assessment, focusing on te development process, testing, and proven performance/experience.

5.2.4 India In the Indian nuclear domain, Atomic Energy Regulatory Board (AERB) is the agency that certifies safety-critical software for NPPs.

5-27

In India, certain types of EDDs are referred to using the related term smart devices. Regulatory guidance is primarily from IEC 60880 for safety-critical software [257]. AERB safety guide (SG)

D-25 [258] deals with the computer-based systems of pressurized heavy water reactors (PHWR).

It provides guidelines for development of computer-based systems and explains the Standard Regulatory Review Process (SRRP) for computer-based I&C systems covering both hardware and software. IAEA standards, or other acceptable codes, are used to review specific areas for which AERB documents have not been prepared.

Indias regulatory agency also require QA and cite ISO-9001. India also uses IEEE standards IEEE Std. 603, IEEE Std. 7-4.3.2, and IEEE Std. 323.

In the Indian nuclear domain, the system classifications provided in AERB SG D-25 are:

• IA: I&C Safety Class A includes those computer-based systems that prevent postulated initiating events (PIEs) from leading to a significant sequence of events or that mitigate the consequences of a PIE. This class also applies to those computer-based systems the failure of which could directly cause a significant sequence of events.

• IB: I&C Safety Class B applies to computer-based systems that play a complementary role to the class IA systems in the achievement or maintenance of NPP safety. The operation of class IB computer-based systems may avoid the need to initiate class IA systems. Class IB computer-based systems may improve or complement the execution of class IA systems in mitigating the effects of a PIE. Class IB also applies to computer-based systems the failure of which could initiate or worsen the severity of a PIE.

• IC: I&C Safety Class C applies to computer-based systems that play auxiliary or indirect role in the achievement or maintenance of NPP safety. Class IC includes those computer-based systems that have some safety significance but do not belong to class IA or IB. They can be part of the total response to an incident but not be directly involved in mitigating the physical consequences of the incident.

The safety category IA aligns well with NRCs safety-related classification, but the other categories do not align well.

At present, regulatory guidance in India does not explicitly include/identify smart devices [259].

That said, the qualification of smart devices in India consists of two steps [260]:

• Generic qualification of product

• Qualification of smart device for specific application Before a smart device can be used, a review is performed to ensure that the device is qualified for use in an NPP. This review requires that the device

• meets functional and performance requirements that are evaluated with testing (e.g.,

accuracy, EMI/EMC, seismic, etc.),

• has extensive operating experience, both inside and outside of the nuclear industry for the same model and software version of the device,

• has a well-established design process that was used throughout the lifecycle, the HRA and FMEA have been performed, and failure modes are predictable, and 5-28

• the manufacturing process was dependable, including ISO-9001 certification, version control, history, and problem reporting.

If the device has networking features, then the devices are evaluated for cyber security concerns.

The evaluation, which uses a graded approach, evaluates software to IEC 60800, IEEE Std. 603, IEEE Std. 7-4.3.2, and Indias AERB SG-D-25. AERB SG-D-25 refers to IEC standards.

Additional (and practical) requirements for software in smart devices include the simplicity of the software without additional features, secondary function, and no unused code or features.

Not surprisingly, regulators have found that receiving source code and design documentation is difficult if at all possible, and the limited diagnostic information makes demonstration of software self-supervision difficult. Nuclear Power Corporation of India Limited (NPCIL), which is administered by the Department of Atomic Energy (DAE), proposes extensive black box testing and CCF analysis of systems with smart transmitters because of the unavailability of the source code [260]. Qualification of software tools is also an issue due to unavailability of reports detailing the qualification of the tools.

Similar to other countries, India recognizes that most requirements, guidance, and standards are given at a system level, which is difficult to apply at the component/device level.

The challenges faced by regulators in India are the same as those faced by other countries. An excellent compilation of challenges for qualifying smart devices is provided by Singh [259]:

• Digital devices are being used in large scale due to advantages of smart features.

• Smart features increase complexity and functionality.

• Uncertainties in assessment exist at the design stage.

• Validity of evidences are provided for assessment due to faster improvement and obsolesce of technologies.

• Sometimes it is difficult to know of the presence of smart devices in equipment in absence of internal details.

• Nuclear needs are not a priority for many commercial device manufacturers.

• Gap areas exist with respect to nuclear safety requirements for higher safety class.

• There is limited access to information on processes and design due to IP concerns.

• Design, development and manufacturing involves multiple vendors, so there is insufficient traceability and ownership of the original supplier.

• There is a greater chance of introduction of counterfeit, fraudulent, and suspects items and security vulnerabilities.

• Consideration of complementary testing and operating experiences could compensate for gap areas.

5-29

• Security assessment is challenging without knowing vulnerabilities.

• Diversity can prevent CCF v/s maintainability.

• Quality of documentation is lacking.

• Information is in pieces and is not written in compliance of justification needed for NPPs.

• Third-party assessors might not be aware of nuclear requirements.

• Documentation is available in different languages.

• Ensuring continuation of justification for future supplies is challenging.

• Suppliers continue to desire to upgrade products.

• Suppliers may not be proactive and may not consider that minor changes in design/component are important enough to record and report.

• Changes in manufacturing process are important.

• May require frequent requalification/revalidation exercises.

The experience in India in applying standards developed for systems at the component level can be useful in developing device specific guidance.

5.2.5 Japan Prior to the Fukushima Daiichi accident, the requirements and guides for the licensing review process of establishment/permit for existing Japanese nuclear power plants were established by the Nuclear Safety Commission (NSC). After the Fukushima Daiichi accident, a new nuclear regulatory body, the nuclear regulation authority (NRA) was established to improve its nuclear safety management and regulation in 2012.

In Japan, certain types of EDDs are referred to using the related term smart devices. Japan does not currently have regulations specific to the use of smart devices; I&C systems important safety were built on the assumption of using only nuclear qualified products and are regulated using the same requirements. [19].

The safety system/component classification in Japan is three levels in accordance with the importance of their safety function [153]:

• Class 1: Secure and maintain as high as reasonably achievable level of reliability.

• Class 2: Secure and maintain a high level of reliability.

• Class 3: Secure and maintain a level of reliability equal to or higher than that for general industry.

Those SSCs of which loss of the function could cause an abnormality of the nuclear reactor facility, which causes excessive radiation exposure to the general public or the working personnel (the system for preventing the occurrence of abnormalities), are referred to as PS.

5-30

Those SSCs that have the function to prevent the propagation of abnormality or terminate it quickly in an abnormal situation of a nuclear reactor facility, and to protect the general public or the working personnel from possible excessive radiation exposure (the system for mitigating the impact of abnormalities), are referred to as MS.

The classification based on PS/MS and the three classes are:

• PS1 (prevention system)/MS1 (mitigation system)

• PS2/MS2

• PS3/MS3 The NRA defines safety functions as the functions of SSCs necessary to ensure the safety of nuclear reactor facilities. SSCs are categorized based on whether they can cause or prevent an AOO or DBA [261]:

(1) Functions that may cause, when lost, AOOs and DBAs in nuclear reactor facilities, potentially leading to undue radiation exposure of the public or site personnel (2) Functions that prevent, in case of AOOs and DBAs in nuclear reactor facilities, the escalation of such conditions or put such conditions under control immediately, thereby preventing or mitigating potential undue radiation exposure of the public or site personnel Importance of safety functions refers to the degrees of the importance of safety functions of the safety system/component from the viewpoint of ensuring the safety of nuclear reactor facilities to address or prevent the escalation of AOOs and DBAs.

Standards, codes, and acceptance criteria for regulatory authorization are established by legislation and regulation; the guidance is provided by selected U.S. NRC guidelines.

Three paths are provided in IEC 61513 on the functional validation stageapplication software development, equipment (software and hardware) procurement, and development of novel system software and hardware features. Japan assumes that the procurement path provided in IEC 61513 will be adopted for smart devices [19].

The experience in Japan for regulating smart devices is similar to that of other countries [19]:

• Basically the smart devices are designed to be applicable for various industries. Many selectable functions are designed and many software (program and Data) modules are implemented.

• The interconnectivity between each program, data structure, etc. are generally not disclosed

• The configuration data which defines the available functions of the smart devices are set by the vender or the purchaser

• The program update may be submitted as a functional improvement with new version and revision numbers without prior notice.

Configuration management (CM) is essential for the successful use of smart devices. Watanabe recommends the following [19]:

5-31

• The licensee need to decide information level according to the safety grade of smart devices (graded approach).

• The licensee need to request the smart device venders to disclose the device information.

• Considering the trouble investigation, CM of the smart devices is needed to cover all device information including every program and data for superfluous functions

• The licensee is needed to keep information matching with the implemented smart devices through the CM system.

Japan does not specifically provide guidance on the use of smart devices but relies on the quality and function of the device application. Japan uses both IEC and IEEE standards as a safety basis.

5.2.6 Korea In 1981, the Nuclear Safety Center was founded as part of the Korea Advanced Energy Research Institute (KAERI). In 1985, the Nuclear Safety Center branched off as an auxiliary organization KAERI. In 1990, the Korea Institute of Nuclear Safety (KINS) was independently established.

Then in October 2004, the National Nuclear Control Agency (NNCA) was installed as an auxiliary organization of KINS, and the Korea Institute of Nuclear Nonproliferation and Control (KINAC) branched off in 2006.

In Korea, certain types of EDDs are referred to using the related term smart devices. Regulatory guidance is provided in KINS/GE-N001 [262], which is the Standard Review Plan for LWR in Korea. The Korean SRP based reviewsof CGIreference EPRI NP-5652, and EPRI TR-106439.

Other U.S. NRC guidance documents used for guidance or required incude SRP BTP 7-19, SRM on SECY-93-087, NUREG/CR-6303, IEEE Std. 603, and IEEE Std. 7-4.3.2.

One of the missions of the KINS is to review and inspect nuclear installations including commercial NPPs, nuclear fuel cycle facilities and research reactors in Korea. KINS was established under the Korea Institute of Nuclear Safety Institute Law in February 1990. The regulatory experiences of KINS regarding the use of EDDs for safety I&C systems and the future work for them are discussed below.

These licensing requirements are intended to be implemented by the regulatory agency as binding requirements within the national legal framework. This document is supplemented by detailed guidance in reference G-RG-CP, Preparation and Review of Applications for Construction Permits, and G-RG-OL, Preparation and Review of Applications for Operating Licenses, (not yet published). These are supported by information in IAEA Safety Guides, NRC RGs, and guidance from other international sources.

The regulatory structure is that KINS and KINAC support the Nuclear Safety and Security Commission (NSSC) and the NSSC reports to the prime minister of Korea.

The system/component classification in Korea has three levels:

• IC-I (IC-1)

• IC-II (IC-2)

• IC-III (IC-3) 5-32

The safety categories do not align well with the NRCs safety-related classification.

The Shin Kori-3&4 Nuclear Power Reactors (SKN 3&4) are the first NPPs in Korea that adopted safety grade smart transmitters. SKN 3&4 also used digital relays for EDGs; these digital relays are EDDs that are composed of digital devices with firmware.

Specific to the review of smart transmitters, KINS [12] reviewed the use of smart transmitters against IEEE Std. 7-4.3.2-2003 [263] and IEEE Std. 1012-2004 [209]. IEEE Std. 7-4.3.2-2003 was used to evaluate software CCFs, including use of manual action and non-safety-related systems, or components, or both, to provide the means to accomplish the function that would otherwise be defeated by the CCF. IEEE Std. 1012-2004 was used to evaluate theto determine if it met the V&V requirements. The software was developed as IEEE SIL Level 4 or equivalent according RG 1.168 [319]. The equipment was qualified by IEEE Std. 323-2003 [158]. Also, SRP Appendix 7.0-A [264] and SRP BTP 7-19 [227] provided additional guidance on the assessment of the diversity and the defense-in-depth for the digital I&C systems.

KINS reviewed the digital relays for the EDGs as CGIs that must be commercially dedicated for use; EPRI TR-106439 was used for the dedication process. Also, KINS reviewed the QA program, problem reporting, the maintenance and troubleshooting process, and the operating experiences for the digital relays.

The major review points for the use of EDDs at KINS are as follows:

• Quality and reliability (QA program and V&V process)

• CCFs via software errors

• EMC

• CGI dedication (procurement planning, review, test, and control, etc.) [12]

KINS observed that EDDs might exist in safety grade procured equipment without explicit identification. Undetected defects of EDDs might be the potential safety concerns. EDDs should meet certain specific requirements in order to be selected and used in a safety I&C system.

KINS plans to develop technical positions for identification and qualification of EDDs; its technical position will address, but may not be limited to, quality and reliability, CCFs via software errors, EMC, and CGD for EDDs.

For devices that are used in safety systems such as the ultrasonic level transmitter in the APR1400, diversity is achieved using different, diverse manufacturers designs for safety-related and non-safety-related applications [265].

The Korean regulatory framework is largely modeled on the U.S. NRC. However, the use of EDDs in Korean NPPs should be monitored for possible guidance and applications as they appear to be leading in this regard.

5.2.7 Pakistan The Pakistan Atomic Energy Commission (PAEC), established in 1956, is an independent governmental agency and a scientific research institution, concerned with research and development of nuclear power, promotion of nuclear science, energy conservation and the peaceful usage of nuclear technology. In 2001, the PAEC was integrated with the National Command Authority (Pakistan), which is under the prime minister of Pakistan. Currently, the 5-33

PAEC is held responsible for design preparation and proper operational function of commercial nuclear power plants, and the safety regulations and protections of the nuclear power facilities are managed by the Pakistan Nuclear Regulatory Authority (PNRA).

In Pakistan, certain types of EDDs are referred to using the related term smart devices. The only regulartory guidance found for Pakistan was IEEE Std. 1012.

The use of smart devices is not yet recommended by PAEC for nuclear systems because of cyber threats. However, indigenous systems with smart devices may be candidates for use in non-safety class systems after rigorous V&V. The PAECs concerns regarding the use of smart devices include [266]:

• Difficulty of system V&V

• Risk of cyber-attacks (currently no wireless controls are being installed at nuclear facilities in Pakistan)

• Anticipated problems for wireless-based smart systems 5.2.8 Romania The National Commission for Nuclear Activities Control (CNCAN) is the nuclear safety and security regulatory authority of Romania that is responsible for the regulation, licensing and control of nuclear activities, ensuring the peaceful use of nuclear energy and the protection of the public and workers from the harmful effects of ionizing radiation.

In Romania, certain types of EDDs are referred to using the related term smart devices.

Regulatory guidance is primarily from IEC 61511, EPRI 106439, and ANSI/ISA-S75.13.01.

Romania defines a smart device as [267]:

• an electronic device, generally connected to other devices or networks, that can operate to some extent interactively and autonomously

• a context-aware electronic device capable of performing autonomous computing and connecting to other devices by wire or wirelessly for data exchange

• devices such as sensors and valve actuators that contain computer-based technologies and are configurable to be suitable for a variety of applications

• devices with the capacity to generate elaborate data in addition to that strictly required by their main function Pakistan recognizes that smart devices can provide self-diagnostics and improved capabilities.

However, the cons of smart devices are their added complexity, additional failure modes, cyber security issues, and radiation sensitivity.

At the Cernavoda NPP, smart devices are used in transmitters, sensors, valves, pneumatics, valve positioners, relays, and controllers. The devices transmit data through the use of data diodes to communicate with an IoT, providing secure data transfer to IT systems (external or cloud based). Data communication uses the HART protocol.

5-34

Smart CANDU tools are an integrated set of software tools that facilitate online monitoring, self-diagnostics and analysis of systems to optimize performance and maximize plant life. This information management software application allows for system and component health monitoring.

The level of connectivity of smart devices is much greater than that of other countries, as shown in Figure 5-2.

Figure 5-2 Interconnectivity of Smart Devices at Cernavoda NPP [268].

There were two presentations from Romania during the IAEA Technical Meeting on Safety Aspects of Using Smart Digital Devices in Nuclear Systems Important to the Safety of Nuclear Power Plants. The first presentation [269] dealt with cyber-security guidance of digital applications and was not specific to smart devices. No unique information was presented.

The second presentation [267] described the use of smart devices at the CANDU-based NPP.

There are three levels within the Cernavoda I&C architecture in which smart devices are employed: (1) analytics (system level - essentially the sense, command, and monitoring aspects of systems, (2) connectivity and communication, and (3) field devices. The first level involves digital platforms and software. The example given is the SMARTCANDU tools used for monitoring (ThermAND and ChemAND). This is not technically a smart device example, but rather it is a digital system that can be treated as such (i.e., assessed under typical digital system review guidance). No further information was presented on how this system-level equipment/system was licensed.

The second level is identified in terms of the communications equipment. Specific examples given are gateways and data diodes. No specific information was given on how these devices were assessed, but the other presentation on cyber-security assessments identified the regulatory approach to computer security (IAEA NSS-17, IAEA NSS-13, IEEE 7-4.3.2-2010, and IEC 62645).

The third level involves smart sensing and autonomous controllers. Two specific valve positioners (controllers) were identified: (1) Emerson Fisher digital valve controller (DVC) 6000, and (2)

Emerson Fisher DVC 6200. These digital valve controllers are microprocessor-based current-to pneumatic instruments (microprocessor executes a digital control algorithm to establish a drive signal to the I/P converter based on the input demand). The DVC receives feedback of the valve travel position plus supply and actuator pneumatic pressure. This allows the instrument to diagnose not only itself, but also the valve and actuator to which it is mounted. In addition to the traditional function of converting a current signal to a pressure signal, DVCs use HART communications protocol for digital access to device information. The main difference between the two positioners is linkage. The DVC 6200 has a magnetic linkage, whereas the DVC 6000 has a mechanical linkage.

5-35

The justification for using the two smart positioners was based on CGI dedication guidance from EPRI TR-106439 (with emphasis on operating experience from Ginna, Vogtle and EdF) and vibration testing as defined in ANSI/ISA S75.13.01 [270]. Fatigue testing included 3 million cycles. No specific considerations were identified to address the smart characteristics of the devices other than citing the treatment of digital equipment under the EPRI CGI dedication guidance.

In summary, Romania simply follows the CGI dedication from EPRI TR-106439 and does not have specific guidance or practices for smart devices. They do, however, perform the typical vibration tests (based on ISA S75.13.01) and cite operating experience from Ginna, Vogtle, and EdF.

Regarding communications, there was no indication that they performed anything special for their gateways or data diode other than typical testing and following computer security guidance (IAEA NSS-13, IAEA NSS-17, IEC 62645, and IEEE 7-4.3.2-2010).

Essentially, Romania relies on IAEA and EPRI guidance, as well as the QA of the suppliers.

5.2.9 Russia The Rosatom Nuclear Energy State Corporation is the agency responsible for fuel cycle and nuclear energy production activities, nuclear scientific and research centers, and Rosatoms nuclear weapons complex.

The Russian Research Institute for Nuclear Power Plant Operations (VNIIAES) is the organization that assists in NPP startup, operations, and training and that manufactures full-scope and analytical simulators.

Gosatomnadzor (GAN) is the state committee for nuclear and radiation safety and is responsible for regulating the safety of Russia's civilian nuclear reactors and fuel cycle enterprises. (The Ministry of Defense is responsible for all military nuclear facilities.) GAN licenses all civilian facilities that use radioactive materials, develops rules and standards governing the safe use of these materials, and inspects all facilities that use these materials, including NPPs. GAN is also charged with approving the design and construction of all nuclear plants.

In Russia, certain types of EDDs are referred to using the related term smart devices.

In the Russian Federation, Rostekhnadzors regulatory activity in the area of I&C systems is based on the following regulations [248]:

• OPB-88/97, General Safety Provisions for NPPs (Sections 4.4, 4.5)

• NP-082-07, Nuclear Safety Rules for Reactor Installations of NPPs (Chapter 3)

• NP-026-04, Requirements to Control Systems Important to Safety of NPPs

• NP-006-98, Requirements to the Content of the Safety Analysis Report for VVER-type NPPs (chapter 7)

GOSTs are the Russian National Standards. Many GOSTs are adopted IEC standards:

5-36

• GOST R IEC 61513-2011

• GOST R IEC 60880-2010

• GOST R IEC 62138-2010

• GOST R IEC 60987-2011

• GOST R IEC 62340-2011

• GOST R IEC 61500 For those areas not covered by national regulations in due detail, such as digital I&C implementation, the provisions of internationally recognized documents such as IAEA standards are considered. IAEA standards that are part of the regulatory review include:

• IAEA Safety guide No. NS-G-1.3

• IAEA Draft Safety Guide DS-431 The system/component classification in Russia includes four levels [271]:

• Safety Class 1: includes fuel elements and elements of the NPP the failure of which would represent initiating events preceding BDBAs leading to damage of fuel elements with limits exceeding those established for DBAs on normal functioning of safety systems.

• Safety Class 2: includes elements the failure of which would be initiating events leading to damage of fuel elements within limits established for DBAs on proper functioning of safety systems with allowance for a specified number of failures in them for DBAs and safety systems elements, single failures of which lead to non-performance of functions by the relevant systems.

• Safety Class 3: includes systems important to safety that are not included in safety classes 1 and 2; elements containing radioactive substances release of which to the environment (including NPP rooms) on failures would exceed values specified in radiation safety standards; and elements performing control functions of radiation protection of personnel and the population.

• Safety Class 4: assigned NPP normal operating elements not affecting safety and not included in safety classes 1, 2, 3.

The classification categories for safety class 2 align well with the NRCs classification structure for safety-related, safety class 3 aligns well with important to safety, and safety class 4 aligns well with nonsafety. Safety Class 1 is related to BDBAs and does not align well with other regulators classification structure.

In discussing the safety aspects of using smart digital devices in nuclear systems important to the safety of NPPs, Sivokon discussed the challenges of digitizing I&C systems [272].

Russia recognizes the differences between analog and smart devices and uses technology in betweenhardwired logic. IEEE Std. 610.10 1994 defines hardwired as pertaining to a circuit or device whose characteristics are permanently determined by the interconnections between components. Hardwired logic is defined as a group of logic circuits permanently interconnected to perform a specific function. Their hardwired logic uses components with CMOS ICs (AND, OR, NOT gates, flip-flops, counters, multiplexers, etc.), analog-to-digital converters (ADCs) without microcontroller cores, EEPROMs, solid state relays, transistors, diodes, resistors, capacitors, 5-37

fuses, etc. They do not use processors, microcontrollers, FPGAs, or CPLDs because they recognize that only very simple devices are thoroughly testable.

Advantages of hardwiring include [273]:

• Software errors and malfunctions are not a problem because there are no software controls in the algorithm processing.

• Behavior is predictable, and in-depth testing can be performed without the complicated ICs (microprocessors, FPGAs, CPLDs) inside, simple standard logic ICs allow detailed analysis during development, even with the multimeter or oscilloscope, and equipment behavior is much more predictable even in malfunction.

• Hardwiring is cyber secure by design.

• There are no abundant or unused elements and no hidden functions.

• Hardwiring ensures easier qualification.

Disadvantages include [273]:

• Difficult to incorporate online proof testing in a single nonredundant device (monitoring still possible).

• Difficult to implement some time domain processing such as PID control This hardwired logic platform (HLP) has or is being implemented in the following plants and systems:

• Novovoronezh NPP unit 6 Diverse Actuation System (DAS)

• Leningrad NPP 2 unit 1 Additional Diverse Actuation System (ADAS)

• Novovoronezh NPP unit 7 Diverse Actuation System (DAS

• Rostov NPP unit 4 ESFAS channel

• Leningrad NPP 2 unit 2 Additional Diverse Actuation System (ADAS)

• Rostov NPP unit 3 ESFAS channel

• Kalinin NPP unit 1 ESFAS channel Many of the regulations used in Russia apprear to be based on IEC standards. Thus, a review of IEC standards should cover the regulatory basis in Russia.

5.2.10 United Kingdom The Office for Nuclear Regulation (ONR) is the United Kingdoms (UKs) independent nuclear safety and security regulator. ONRs inspectors use the safety assessment principles (SAPs),

together with supporting technical assessment guides (TAGs), to guide their regulatory judgements and recommendations when undertaking technical assessments of nuclear site licensees safety submissions.

In the UK, certain types of EDDs are referred to using the related term smart devices.

In the United Kingdom, smart devices are defined as [11]:

5-38

• COTS

• Based on microprocessors/microcontrollers running software/firmware, or a hardware description language (HDL)-programmed device

• User configurable but not user programmable (user cannot add new functionality)

Regulatory guidance is primarily from ONR SAPs, ONR TAG-046, TGN 032, IEC 61508, and the suite of (IEC) BS EN standards such as BS EN 61513, BA EN 61226, etc. Company Technical Standard CTS 214, mandates processes for C&I modification and replacement, and Technical Guidance Note (TGN) 032 outlines processes for the justification for the use of smart devices [11].

This guidance along with input from external standards such as IEC 61508, BS EN 61513, IEC 61226 feed into the Regulatory framework of ONR SAPs and TAG 046.

In evaluating a component or system, the UK first identifies the safety function of the device and then evaluates how the SSCs deliver those safety functions and their significance to safety. The basic safety requirements for UK nuclear facilities are identified in the SAPs issued by the Nuclear Safety Division of the Health and Safety executive which provides a framework for the consistent application of the principles. The nature of the UK regulatory regime is not prescriptive; however, the UK does support international standards that may be prescriptive.

The safety categorization scheme employed links with the licensees design basis analysis. The three-safety system/component classifications are [124, ONR SAP ECS.1]:

• Category A: any function that plays a principal role in ensuring nuclear safety

• Category B: any function that makes a significant contribution to nuclear safety

• Category C: any other safety function contributing to nuclear safety SSCs that have to deliver safety functions are identified and classified on the basis of those functions and their significance to safety [124], ONR SAP ECS.2]:

• Class 1: any SSC that forms a principal means of fulfilling a Category A safety function

• Class 2: any SSC that makes a significant contribution to fulfilling a Category A safety function or forms a principal means of ensuring a Category B safety function

• Class 3: any other SSC contributing to a categorized safety function The expectation in the UK is that the extent of the justification required is according to the safety significance of the device according to its safety class. Three safety classes are recognized in accordance with the relevant SAP (i.e., Class 1 to 3). As a minimum (e.g., Class 3),

demonstrated good commercial quality of the production excellence of the device may be sufficient, with commissioning test results and prior use as ICBMs. At the higher safety class (e.g., Class 1), it is necessary to assess a wide range of manufacturer documentation, including source code. Extensive ICBMs are also expected at Class 1 compared to Class 3, sufficient to make an adequate case for safety in the intended application.

Safety-related systems are distinct from safety systems in that, while they often have a significant influence on safety, they do not provide the primary means of protection for fault sequences. In an I&C context, safety-related systems include facility control systems, indicating and recording instrumentation, alarm systems, and communications systems.

The definition in ONR TAG 046, which is taken from the IAEA Safety Glossary, is a little different:

5-39

SAFETY RELATED SYSTEM - An item important to safety that is not part of a safety system (IAEA Safety Glossary). Safety-related systems are therefore systems in place to perform an operational function but which also provide a safety benefit. Safety related systems do not provide the primary means of protection for fault sequences. This is distinct from safety systems which are systems that do not perform any operational functions and are included solely because of the safety functions they perform.

ONR TAG 046 also uses the term computer based systems important to safety (CBSIS). A system important to safety is a safety system or safety-related system that implements safety functions at categories A-C and hence is assigned a corresponding class 1-3. The term CBSIS, therefore, encompasses both safety systems and safety-related systems that are computer based.

The classification categories do not align well with the NRCs classification structure, and this could lead to confusion with NRC regulations and guidance in that ONR considers safety-related systems to be distinct from safety systems. However, the basis of classifying based on safety function could provide potential avenues to explore for classification of devices.

Specific to the use of COTS smart devices, the UK recognizes the following challenges[11]:

• The risk from systematic failure must be sufficiently low.

• The device must always fail [safe] when triggered by a systematic failure (e.g., due to design flaws, human error, logic errors).

• A sufficiently low safety claim (class 3/2/1, 10-2/10-3/10-4 PFD) is inherited from the system safety case.

ONR TAG-046 identifies limits to the reliability claims that can be placed for a single smart device for the different safety classes. Modifications at the I&C architecture level may be an effective way to reduce the claim on each smart device if supported by a suitable CCF analysis. SAP ESS 27 [124] states that for computer-based systems, Where the system reliability is significantly dependent upon the performance of computer software, the establishment of and compliance with appropriate standards and practices throughout the software development life-cycle should be made, commensurate with the level of reliability required, by a demonstration of production excellence and confidence-building measures.

ONR TAG-046 provides additional guidance for supporting clause SAP ESS.27 and outlines a two-legged approach for demonstrating the suitability of a smart device. The two legs consist of

[274]:

1. Production excellence (PE) includes proof that the technical design practice is consistent with current accepted standards for the development of software for computer-based safety systems, implementation of a modern standards quality management system, and an application of a comprehensive testing program formulated to check every system function. This is a demonstration of excellence in all aspects of production from the initial specification to the finally commissioned system.

2. ICBMs include complete, preferably diverse checking of the finally validated production software by a team that is independent of the systems suppliers, and an independent 5-40

assessment of the comprehensive testing program covering the full scope of the test activities.

Production excellence for smart devices is typically assessed using the EMPHASIS approach (see Adelard below). The Emphasis assessment is used to provide evidence of the QA, design and development processes used by manufacturers of smart devices.

While the application of specific standards is not mandatory, ...the case for production excellence is greatly assisted by evidence of the systematic application of national and international ...

standards, coupled with a case by case justification of non-compliances [126]. IEC 61508, IEC 61513, and IEC 60880 are typical of the standards recommended for this role [176].

ICBMs are generally carried out by the licensee independently from the manufacturer, with specialized technical support where needed. To maximize the value added, they are generally expected to be diverse from the compensating measure used in the PE leg.

Licensees are responsible for ensuring that their use of COTS devices complies with SAP ESS.27 and TGN 046. The level of justification required for a smart device depends on a number of factors, but it broadly aligns with the safety function categories and system classes of IEC 61226.

In its guidance on COTs smart devices in ONR TAG-046 Revision 5, compensating activities are allowed to make up for the gaps in production excellence information. No attempt is made to define the compensating activities (compensatory measures), as these would be determined on a case by case basis.

5.2.10.1 Sellafield Sellafield is a nuclear site involved in fuel reprocessing, nuclear waste storage, and decommissioning.

The actual reliability of instruments used at Sellafield, both smart and dumb, have been catalogued over many years in the Sellafield Reliability Database (SRdB). However, the SRdB had little data on new models (mostly smarts) being offered by manufacturers. Their original intent was to use these new smarts on basic plant control systems (non-safety) and thus establish figures in the SRdB to show the reliability of these new smarts.

Sellafields experience on the use of smart instruments [50] is described in the following:

• It was often very difficult to even tell if an instrument was Dumb or Smart. Manufacturers data sheets never specified if microprocessors were used. O&M manuals often never went to this level of detail on component parts, and visual examination often proved inconclusive.

• Existing models became Smart over-night. An instrument purchased just two years before was known to be dumb and purchasing an identical instrument with exactly the same part number now delivered an identical Smart Instrument. Manufacturers thought this was a good thing!

• It became clear that the introduction of Smarts was proceeding faster than Sellafield staff could gather SRdB data on them in non-safety systems.

Realizing there was a knowledge gap around the subject of smart instruments in SISs, Sellafield formed a nuclear industry working group (NISIWG) [50]. Members consist of Sellafield Ltd.,

British-Energy, Magnox Generation, Urenco, BAE Systems, Atomic Weapons Establishment, 5-41

Devonport Dockyard Management Limited, Rolls-Royce Naval Marine, and GE Healthcare.

NISIWG had several objectives that include a common understanding of the technology, identification of potential problem areas, sharing of substantiations, spreading of costs, production of individual company standards and procedures based on a common substantiation methodology, and of course some market advantage with manufacturers.

At first, most manufacturers cooperated enthusiastically, but as the scope of the data NISIWG required became clear, only a very few were able to deliver. It is worth reviewing why many manufacturers withdrew from helping NISIWG further, as it is a clear indication of the way the market economy is influencing the whole IEC 61508/61511 issue.

Most manufacturers support waned as a consequence of the following issues [10]:

• A lack of understanding of IEC 61508 by the manufacturer.

• The UK nuclear industry process instrument market is only around 3% of the turnover of a large UK-based manufacturer. The nuclear industry is not a big player anymore.

Pressure transmitters, for example, were sold at 1.8 million annually, of which just 540 were purchased by the whole UK nuclear industry.

• The average purchase price of a smart instrument is around £1,000, with small profit margins.

• When IEC 61508 was first published, both potential users and manufacturers of 61508 type equipment had no previous experience with it and early offerings reflected this lack of experience. Manufacturers had already paid considerable funds to third parties to issue certificates, which NISIWG was now questioning. Typical examples included certificates stating SIL3 compliance, with NISIWG erring toward an SIL1 rating.

Manufacturers were therefore concerned that NISIWGs work would undermine the existing certificates. In recent times however, there has been a noted improvement in certification quality.

• It became demonstrably obvious that other industries were simply not as concerned about this issue as the nuclear industry. Indeed, NISIWG was often the only source of enquiries the manufacturer ever received for further details on the certification process.

5-42

6 STANDARDS AND GUIDES National and international standards provide normative criteria and guidance on the use and regulation of a host of components, including those pertinent to EDDs. United States and international standards were reviewed to learn how others regulate and implement EDDs and to possibly leverage this experience into the framework of NRC regulations and guidance (Table 6-1). Guidance on the development and assessment of EDDs were evaluated for EPRI, IEEE, ISL, and NIST. The use of the standards and guides by country is cited in the review of how each specific country addresses the use of EDDs in NPPs.

Table 6-1 Standards Development Organizations (SDOs) and Organizations with Guidance Documents Cited by National and International Industries SDO or organization Adelard AIChE - American Institute of Chemical Engineers API - American Petroleum Institute Automotive CSA Group - formerly, Canadian Standards Association CSB - Chemical Safety Board EPRI - Electric Power Research Institute EUROCAE - European Organisation for Civil Aviation Equipment IAEA - International Atomic Energy Agency IEC - International Electrotechnical Commission IEEE - Institute of Electrical and Electronic Engineers ISA - International Society of Automation ISO - International Organization for Standardization NEA - Nuclear Energy Agency NEI - Nuclear Energy Institute NIST - National Institute of Standards and Technology ONR - UK Office for Nuclear Regulation In-house developed standards From a standards perspective, both the nuclear IEEE (e.g. IEEE 603) and the nuclear IEC (e.g.

IEC 61513) standards suites use system-level requirements that are not easily synthesized down to component- or EDD-level requirements.

How other standards are used to classify and regulate systems and devices can be useful in identifying differences in regulatory philosophy and potential modifications that could be incorporated into the NRC regulatory structure. Many of the standards are based on the IEC suite of standards. For example, Adelard, API, ASIL, CSA Group (Canada), DOE, ISA, ISO, MDEP, NEI, ONR, OSHA, and FRA use IEC standards. The IAEA standards are the basis for the first tier of IEC standards for safety for nuclear I&C (IEC 61513). Feeding into IEC 61513 is IEC 61508 for functional safety (non-industry specific). Several are based on IEEE standards, such as (of course) IEEE and NIST. The EPRI reports provide a solid basis for evaluating specific aspects of safety.

6-1

The IAEAs approach to the safety classification of SSCs considers safety classification (important to safety and not important to safety), functionality, and consequences that result if the function fails when it is required to perform, and it is also related to the consequences in the event of a spurious actuation. The classification typically begins with categorization of the functions to be performed by I&C systems, which are assigned to categories according to their importance to safety. The safety importance of a function is related to the consequences.

Standards and their associated regulations can be either prescriptive or performance based.

Prescriptive requirements specify features, actions, or programmatic elements to be included in the design or process as the means for achieving a desired objective. Performance-based requirements rely upon measurable (or calculable) outcomes (i.e., performance results) to be met but provide more flexibility to the licensee as to the means of meeting those outcomes. A performance-based approach establishes performance and results as the primary basis for decision-making and incorporates the following principles: (1) measurable (or calculable) parameters (i.e., direct measurement of the physical parameter of interest or of related parameters that can be used to calculate the parameter of interest) exist to monitor system, including facility and licensee, performance; (2) objective criteria to assess performance are established based on risk insights, deterministic analyses, and performance history; (3) licensees have flexibility to determine how to meet the established performance criteria in ways that will encourage and reward improved outcomes; and (4) a framework exists in which the failure to meet a performance criterion, while undesirable, will not, in and of itself, constitute or result in an immediate safety concern [275].

Many of the standards are performance based, including those cited by DoD, DOE, ISA, ONR, and OSHA. Many of the standards reviewed also recognize and take into account that certain types of EDDs are dedicated devices of limited, specific functionality, that contain or may contain components driven by software or digital circuits designed using software-based tools. In fact, EUROCAE allows the system architectural features, such as redundancy, monitoring, or partitioning (the separation of critical from non-critical functions) to reduce the degree to which components contribute to specific failure conditions. Thus, a partitioned device can have different Design Assurance Levels (DALs) within the same component.

Because many regulations and standards are based on IEC SILs, it is important to learn from those that have evaluated the implementation of IEC SILs and those that have cited some shortcomings of the standards. The objective of EPRI 3002011817 [276] is to demonstrate that equipment certified to non-nuclear safety standards (more specifically, IEC-61508/61511) can meet or exceed nuclear power safety and reliability requirements without further analysis or verification. For the suitability of an item, EPRI 30020118186 states that IEC SIL certification to IEC 61508 may provide evidence of product or platform suitability. An NEI working group is leveraging EPRI 3002011817 to specify a third-party IEC 61508 SIL certification as an alternate approach to determining the acceptability of some of the dependability critical characteristics as defined by EPRI TR-106439. Adopting IEC SIL certifications would allow NPPs to use the same supply chain and structures that non-nuclear safety related industries use. This broadens the supplier base, promotes competition, and allows the harvesting of economies-of-scale arising from other safety industries.

Determining how IEC SIL certifications fit within the U.S. NRC regulatory structure would be a difficult task. Because quality and safety are related, certification to meet IEC SILs has quality implications, and it is be expected that as the SIL increases, the quality requirements would also increase. As written, the 10 CFR 50 Appendix B/CGD approach for safety-related components is not readily transferrable to cross-walking quality standards to the different SILs.

6-2

Before determining how the IEC SIL certification would fit within the NRC regulatory structure, it is important to note the limitations of applying standards for the process industry to the nuclear industry.

IEC 62671 [17] states that IEC 61508 can be used as complementary guidance for the evaluation and assessment of components [for use in the nuclear industry], but it is recognized that certification to non-nuclear standards alone is insufficient. This statement most likely recognizes the lack of clear mapping between the prescriptive nuclear requirements and the performance-based requirements of IEC 61508. It also reflects the concept that IEC 61508 requirements may not address nuclear-specific environmental concerns. Similarly, Summers notes that Following a careful review of a significant variety of product safety manuals, it appears that many field devices are achieving higher safety integrity level (SIL) claims than can be supported by process industry data [123].

Of note are those countries or agencies that use standards and guidance beyond the IEC suite of standards. More specifically, in addition to IEC standards, Canada uses CAN CSA-N290.14 and CSA-N290.8 and the UK uses ONR SAPs, ONR TAG-046, and TGN 032, respectively. DoD uses MIL-STD-882E, which is focused on providing performance criteria and does not prescribe specific design criteria or even specific design techniques. The main goal of MIL-STD-882E is to eliminate hazards when possible and to minimize risks when hazards cannot be eliminated.

NASA uses a consequence-based approach in NASA-GB-8719.13 to evaluate the consequences of the device failure and its impact on the system. The EMPHASIS tool used by Adelard uses a claims-based approach that is designed to demonstrate that the behavior and functionality of the product is sufficient for its intended application and that the products will behave accordingly throughout its design lifetime.

Industrial control equipment manufacturers, railway equipment, automobiles, medical devices, and airborne software use some type of SIL that can be 3, 4, or 5 levels (a SIL 0 or DAL E is not included in the number of levels). BS EN 50128 does not use all five levels of safety integrity.

Instead, the requirements for SIL 1 and SIL 2 are the same for each technique or measure.

Similarly, each technique or measure has the same requirements at SIL 3 and SIL 4. Therefore, effectively, there are recommendations for techniques and measures for only three SILs in BS EN 50128 [67]. Translating the integrity levels to safety/not safety for the NRC has not been performed but the categorization of these levels may provide insight to the NRC regulatory structure by providing information on how components are categorized compared to safety/not safety.

One benefit of using IEC SILs is that the SILs correlate the probability of failure on demand-average (PFDavg) or risk reduction factor (RRF) to safety. The U.S. DOE is like the NRC in that it does not currently use probabilistic classification methodologies for components. However, regulators within and outside the nuclear industry do use probability of failure as a measure of safety. ONR, through ONR TG-046 [126], relates the safety class to the probability of failure on demand for standby and frequency of failure per year for active components. The U.S. DoD assesses and documents risk based on the severity category and probability level of the potential mishap(s) for each hazard across all system modes.

The -2018 version of ISO 26262 includes guidance for software tool selection, use, documentation, and qualification. NASA expects that automatically generated code be treated at the same level as hand-generated code.

6-3

Although there are four integrity levels, the newer version of IEEE-1012-2016 no longer uses the SIL terminology to avoid confusion with the much more widely used IEC-61508 context; rather, IEEE 1012-2016 refers to integrity levels.

Insights and lessons to be learned could be gleaned from detailed reviews of the IEC standards (which covers most applications), Canada, UK, NASA, and DoD. Standards from each of these have a different philosophy for addressing safety. Many of the standards use a claim-based approach or consider the functionality of the device in performing a safety assessment. Others, such as ASIL, have a qualitative measurement of risk, whereas IEC SIL is quantitatively defined as probability or frequency of dangerous failures depending on the type of safety function.

The documents in Table 6-2 are the most similar works identified that are related to the comparison of industries that mitigate significant risk using digital instrumentation and controls equipment.

6-4

Table 6-2 Most Similar Works Existing Work Summary of Evaluation Nuclear Use of I&C Equipment Johnson recognizes that new technology will first appear in Certified for Commercial Safety commercial markets because there is a larger market. The Use [85] one exception is for nuclear specific functions and equipment.

The commercial industry now has certification processes for safety systems and equipment based upon IEC 61508, UL 1998 and others.

Comparison of IEC and IEEE The collections of IEEE and IEC standards have some overlap, Standards for Computer-Based but in many cases cover significantly different topics. For Control Systems Important to example, certain IEC standards deal with specific I&C Safety [277] functions, a topic area where IEEE standards are largely mute.

This paper considers how the two sets of standards may be used in a complementary fashion to achieve broader topic coverage than is possible using only one or the other standard suite.

Comparison of the Software The paper also compares the safety lifecycle and planning Safety Criteria between IEC and activities defined in IEC 61508 with those in IEC 60880 for the IEEE Standards for the Digital software safety lifecycle, IEEE 7-4.3.2 for the computer safety Instrumentation and Control system lifecycle, and IEEE 1228 for the software safety System [278] lifecycle.

Most of the IEC and IEEE standards consist of three main phasesplanning phase, the realization phase according to the plan, and the validation phase. This paper shows the differences in the safety lifecycles between the IEC and IEEE standards. A major difference is that the safety lifecycles in the IEEE standards require a direct safety analysis at each phase of the lifecycle.

The Potential for a Generic The concept is similar to the present work, but the focus is on Approach to Certification of railway, automotive, and aerospace sectors.

Safety Critical Systems in the This paper investigates the potential for common treatment of Transportation Sector [23]

certification of safety critical programmable electronic systems in the transportation industries. It contains a comparative review of new, emerging international standards that are likely to influence certification procedures in the railway, automotive and aerospace sectors in the future. These include the EUROCAE/SAE aerospace guidelines, the CENELEC railway standards, and IEC-61508. The review identifies the common and divergent requirements for certification among these standards.

6-5

6.1 Adelard The development of the Evaluation of Mission imperative, High-integrity Applications of Smart Instruments for Safety (EMPHASIS) 15 assessment tool is based on a questionnaire derived from 14F IEC 61508 [229]. The EMPHASIS assessment tool for smart instruments is intended for use in nuclear safety-critical applications in the UK [279].

EMPHASIS can be used with different target IEC SILs. For components with a lower integrity aim, other processes may be used that do not typically reach the same level of detail as an Emphasis assessment. Third-party product certifications (e.g., commercial certificates of compliance to IEC 61508) can be taken into account in the assessment of production excellence but are neither necessary nor sufficient for successful assessment. Compensatory activities must be carried out if the production excellence leg falls short of the standard expected.

The EMPHASIS approach has been accepted by ONR and licensees in the UK to dedicate the use of components with smart devices. Thus, the approach to justifying the use and application of smart devices in the UK nuclear industry is a mature process.

The EMPHASIS tool is based on IEC 61508 and is used by licenses, and an increasing number of suppliers. EMPHASISs methodology is to examine a series of criteria that includes the company, its core competencies, the tools and techniques used in the design and production of the product, and the testing requirements. More specifically, the types of evidence sought in the assessment stage of EMPHSAIS include product certificates, equipment manuals, company policy documents, design documentation, documentation of safety-related functions, and configuration management procedures.

The EMPHASIS tool is used to meet the production excellence leg of the two-legged approach in TAG-046. EMPHASIS consists of approximately 300 questions structured in four phases, and is inherently graded due to being based on IEC 61508 with its four SIL levels:

• Phase 1 covers QA and safety management.

• Phase 2 covers generic programmable electronic aspects and development process for the device as a whole.

• Phase 3 covers hardware development process and verification activities.

• Phase 4 covers software development process and verification activities.

15 EMPAHSIS was initiated by Moore Industries and the Control and Instrumentation Nuclear Industries Forum (CINIF, UK) in 2003/4 to address concerns regarding smart sensors. One of the projects funded by the CINIF, entitled COTS Goal-based Safety Assessment (COGS), was aimed at developing an approach to the safety justification of COTS products like devices dedicated to a single function, user-programmable and control equipment, or certain software-only products such as operating systems. COGS is a claim-based approach that is designed to demonstrate that the behavior and functionality of the product is sufficient for its intended application and that the products will behave accordingly throughout its design lifetime. According to CINIF, the key advantage of a claim-based approach is that there is greater flexibility in making a justification while ensuring that all safety relevant attributes of the COTS product are justified. The EMPHASIS tool is now owned by CINIF and has subsequently been developed further and supported by Adelard LLP on behalf of CINIF.

6-6

EMPHASIS is typically performed by considering the device independently of the application where it will be used. This allows for reuse of the justification in a number of applications, provided that the behavior of the device and any restrictions identified during the assessment are suitable for each application.

Many regulators and industries use IEC SILs for components with different safety requirements.

The EMPHASIS questionnaire can be configured for different IEC SILs by including more techniques and measures at higher SILs, as defined in IEC 61508.

The depth and breadth of the questions in EMPHASIS are directly linked to the level of detail in the wording of the requirements of IEC 61508. This standard is fairly long because the issues in assuring the software and hardware in computer-based systems are inherently complex. An analysis with significantly less depth is likely to trivialise or brush over essential aspects of the standard. IEC 61508 was chosen because many suppliers already claim compliance with its requirements, and UK regulators (e.g., ONR, HSE) recognize it as relevant good practice forming a benchmark for legal adequacy.

Adelard, working with Emerson, used EMPHASIS to assess the Rosemount 3051 Pressure Transmitter and the Rosemount 644 Temperature Transmitter using Emphasis at SIL 3 and 2 respectively [31]. The Rosemount 3051 pressure transmitters and Rosemount 644 temperature transmitters are the nonnuclear versions of the transmitters and are not qualified for nuclear plant use. Over 8 million pressure transmitters and 1.5 million temperature transmitters have been installed worldwide [31]. At present, the nuclear qualified pressure transmitters are 3051N [280].

Emerson answered over 300 assessment questions and provided over 150 archived documents as evidence for each individual product. Demonstrating production excellence requires the manufacturer of the smart device to show that all aspects of design, development and production are consistent with best practice and are performed in the context of an adequate quality management system. Additionally, the manufacturer must demonstrate that they have performed a testing program that verifies all functions of the device. Adelard visited Rosemounts premises for seven days to discuss and understand the development procedures and the approach to design and verification and to review the answers provided.

The Rosemount 3051 transmitters capabilities include power advisory diagnostics and temperature alerts. Power advisory diagnostics detect issues such as corroded terminals and wiring, grounding, and power supply issues. Temperature alerts can be set to notify if the process temperature reaches a trip high alert or low alert value, the total time the value was reached, and more. The transmitter is optimized with a local operator interface (LOI) and power advisory diagnostics to reduce installation and commissioning time. With wireless capabilities, these devices enhance monitoring and can operate in remote and hard-to-reach locations.

The Rosemount 644 can use 4-20 mA /HART protocol, FOUNDATION' fieldbus protocol, or PROFIBUS PA protocol. It has an LCD Display or LCD Display with LOI. The device performs basic diagnostics, has Hot Backup' capability, sensor drift alert, thermocouple degradation, and min/max tracking. (A hot backup means the backup controller is running. A hot backup controller is not considered to be independent of the primary controller because it is subject to common cause failure [195]. Furthermore, hot backup controllers may have components that are common to both the primary and the backup controller, such as the backplane, firmware, diagnostics, and transfer mechanisms which could have undetected dangerous failures.)

6-7

Emerson's feedback on the assessment of its transmitters using EMPHASIS is that the analysis was rigorous, beyond what they had been previously subjected to in other third-party certifications, but that it was well targeted and focused on issues relevant to product quality [281].

Emerson considered its self-funding of the assessment costs to be money well spent (usually the assessment is funded by the licensee). Note also that one of the Emerson assessments found the instrument to have fulfilled the production excellence criteria for class 1 / SIL3.

According to Adelard, safety demonstrations of commercial products can be challenging because of insufficient support from suppliers (products are sold as a black-box, design documentation constitutes intellectual property, etc.), unclear guidance documents, and inapplicability of known analysis techniques among others [282, 226]. However, creating justifications for higher classes will require access to code and development documentation (IP) to reach appropriate conclusions with sufficient confidence, but this IP does not leave the company and should not be carried into the safety case [281].

It is recognized that it is not easy to use the EMPHASIS tool to qualify the digital devices because (1) the assessors need special training on how to use the EMPHASIS tool; (2) the assessors have to have a very good understanding of IEC 61508; (3) the assessors should have a good knowledge of the digital devices to be qualified; (4) the current nuclear market for such digital devices is very small. Thus, there are not many qualified assessors available to do the qualification. The process, because of its complexity and completeness, seems to be greater than current reviews; however, if a vendor undertakes such as review and it is approved by ONR, the NRC ought to be able to substantially leverage those reviews.

The EMPHASIS assessments can be used to inform and support other safety cases so they can be used in other regulatory activities. In the United Kingdom, there is no problem in piecing together a case using parts from other assessments [281]. In fact, reusing an EMPHASIS assessment is just this on a large scale: reusing the whole production excellence leg. Claims, arguments, and evidence are ideal mechanisms for doing this while ensuring that the claims, arguments, and evidence are appropriately used in the new application.

Several devices have been assessed following the methodology in ONR TAG-046 by Adelard.

Examples of smart devices justified for nuclear application in the UK include:

• Temperature transmitters

• Pressure transmitters

• Radiation monitors

• Protection relays

• Gas analyzers

• Voltage regulators The majority of this has been done at Class 3. Only a limited number of devices have been assessed to Class 1 and 2.

6.2 American Petroleum Institute (API)

American Petroleum Institute API standard RP 554, Part 1 [283] provides a discussion of general functional communications that exist in a process control system; API RP 554, Part 2 [284]

describes a number of common implementations of these communications functions described in Part 1.

6-8

API RP 554, Part 2 discuses smart devices along the traditional sense of industrial practice these smart instruments communicate directly with the process control systems or with each other. These instruments not only transfer information about the basic process measurement, but they also communicate diagnostic information about the health of the device or other secondary information derived from the primary measurements.

The overall risk of a plant may be managed by focusing inspection efforts on the process equipment with higher risk. API 581 [285] provides a basis for managing risk by making an informed decision on inspection frequency, level of detail, and types of nondestructive examination (NDE). IEC 61511 is an informative reference to API 581.

None of the regulators reviewed cited an API standard. In addition, the application of smart devices in the petroleum industry, with their communication capabilities, is beyond what is in use in most industries, including the nuclear industry.

6.3 Automotive Automotive Safety Integrity Level (ASIL) is a risk classification process defined by ISO 26262 [72].

ISO 26262 is an international standard that is an automotive specific implementation of IEC 61508. ISO 26262 does not provide normative nor informative mapping of ASIL to SIL. While the two standards have similar processes for hazard assessment, ASIL and SIL are computed from different points. Whereas ASIL is a qualitative measurement of risk, SIL is quantitatively defined as probability or frequency of dangerous failures depending on the type of safety function.

ASIL has 4 SILsA, B, C, and D. ASIL A represents the lowest degree, and ASIL D represents the highest degree of automotive hazard.

ISO 26262 calculates ASIL based on the severity of the injuries that could result from an event, the likelihood the event will occur in normal operation, and how many drivers could control the situation to avoid the injury. The standard defines functional safety as the absence of unreasonable risk due to hazards caused by malfunctioning behavior of electrical or electronic systems. ASILs establish safety requirementsbased on the probability and acceptability of harmfor automotive components to be compliant with ISO 26262.

Because ASIL is a relatively recent development, discussions of ASIL often compare the SILs to levels defined in other well-established safety or quality management systems (Table 6-3). In particular, the ASILs are compared to the SIL risk reduction levels defined in IEC 61508 and the design assurance levels used in the context of DO-178C and DO-254. While there are some similarities, it is important to also understand the differences.

6-9

Table 6-3 Approximate Cross-Domain Mapping of ASILs [286]

Domain Domain-specific safety levels Automotive (ISO 26262) Quality ASIL-A ASIL-B/C ASIL-D management General (IEC 61508) SIL-1 SIL-2 SIL-3 SIL-4 Aviation (ED-12/DO-178/DO- Design DAL-D DAL-C DAL-B DAL-A 254) assurance level (DAL) -E Railway (CENELEC SIL-1 SIL-2 SIL-3 SIL-4 50126/128/129) 6.4 CSA Group IEC standards adopted by Canada as national standards are published as CSA standards by the CSA Group (formerly the Canadian Standards Association). CAN/CSA-C22.2 NO.61511 adopted IEC 61511 with Canadian deviations. Because CAN/CSA-C22.2 NO. 61511 is essentially the same as IEC 61511, it is reviewed under IEC standards below.

The Canadian Nuclear Safety Commission (CNSC) regulates the use of nuclear energy and materials in Canada. The CNSC is currently in a transition period regarding its standard applicable to digital devices. The previous licensing basis referenced CSA N290.14-07 [250], but now all new licenses and re-licensing activities are referencing the second edition of this standardCSA N290.14-15 [94]. The scope of CSA N290.14-15 expanded the scope of CSA N290.14-07 to include hardware and a broader range of software.

The qualification activities specified in CSA N290.14-15 include the performance of a design review that focuses on several specific concerns that would potentially impact the digital items ability to perform its safety function. These topics are silent for undetected failure, flooding, determinism, and performance (execution timing), common mode (systematic integrity), security, power interruption or restart, time-dependent behavior, modal behavior, shared resources, upgrades, maintainability issues, extra functionality, communications (wired of wireless),

coexistence, user interface, and other postulated failure modes.

CSA N290.14-07 provides a systematic approach to qualifying predeveloped software for use in safety-related applications, and there is an extensive amount of experience with using the standard.

The qualification activities specified in CSA N290.14-15 also include guidance for performing a failure analysis. Several references are provided for performing this analysis. Those references are IEC 62502 for event tree analysis, IEC 60812 for failure mode and effects analysis, IEC 61882 for hazard and operability studies, IEC 61025 for fault tree analysis, and EPRI 3002000509 for hazard analysis. Two complementary methods are required to be used for category 1 applications, and one method is required to be used for category 2 and 3 applications.

A product that has been pre-certified (e.g., using IEC 61508) assists in demonstrating compliance to some of the requirements in CSA N290.14. Then there are qualification activities specified in CSA N290.14-15 that are dependent on pre-developed software (and digital items) or custom software (and digital items). For pre-developed software/digital items, four methods identified for 6-10

qualification are identified as being available for use that are dependent on the category of the digital item. This category appears to be similar to what the NRC considers CGIs. Table 6-4 identifies the methods and their availability for each of the categories.

Table 6-4 Applicable Methods for Qualification of Predeveloped Software [94]

Applicable categories Method Category 1 Category 2 Category 3 Recognized program Mature product method Proof through testing Preponderance of evidence The recognized program method may be applied to pre-developed software digital items to be used in Category 1, 2, or 3 applications (Table 6-5). This method involves verifying that the process used to produce the digital item or the digital item itself conforms to one of the appropriate standards identified in Table 6-5. Conformance may be verified during the qualification activities, or it may be verified by an audit report or certification that was generated by an independent third party (separate from the OEM).

Table 6-5 Acceptable Standards for the Recognized Program Method [94]

Category Acceptable software development standards

1. OPG/AECL CE-0100-STD and OPG/AECL CE-1001-STD; 1 (High safety significance) 2. IEC 61508 (SIL 3); or

3. IEC 61513, Class 1 and IEC 60880

1. OPG/AECL CE-1002-STD;

2. IEC 61508 (SIL 2) 2 (Moderate safety significance)

3. IEC 61513, Class 2, and IEC 62138, Category B; or

4. IEEE 828, IEEE 830, IEEE 1012, and ISO/IEC 12207

1. OPG/AECL CE-1003-STD;

2. IEC 61508 (SIL 1) 3 (Low safety significance) 3. IEC 61513, Class 3 and IEC 62138, Category C;

4. ISO 9001 using the guidance in ISOIEC 90003; or

5. ISO/IEC 12207 The mature product method can be used for Category 2 and 3 applications and requires a minimum amount of successful operating history and minimal details on the items complexity.

This approach cannot be used for Category 1. Table 6-6 identifies the required operating history in years.

6-11

Table 6-6 Minimum Unit Years of Required Operating History [94]

Pre-developed Operating history, minimum unit years software digital item complexity Category 1 Category 2 Category 3 Low n/a 200 100 Medium n/a 500 200 High n/a 1,000 500 Very high n/a 2,000 1,000 The proof-through-testing method may be applied to pre-developed software digital items and items that are to be used in Category 3 applications. For a pre-developed software digital item that runs with discrete executions (e.g., software that runs only during system startup, such as boot firmware), the complexity of the pre-developed software digital item should be low (< 1,000 lines of code, < 20 internal modules, < 5 interface complexity index); the pre-developed software digital item should performs the same steps (i.e., not responding to varying external stimuli) on each execution in the given configuration; and the pre-developed software digital item should be tested in a configuration representative of its final installed configuration, without any failure, meeting the minimum number of test executions. For a pre-developed software digital item that is used continuously while the system is online (e.g., a disk controller), its complexity should be determined to be low (see above); it should continuously loop through a consistent set of steps, and it should be dynamically tested in a configuration representative of its final installed configuration, through all operational modes and a representative range of input values, without any failure, and meeting the minimum number of test hours. See table 4-6 for further detail on how the standard evaluates complexity.

The preponderance-of-evidence method may be applied to pre-developed software digital items to be used in Category1, 2, or 3 applications. This method consists of one or more of the following elements:

a. proven-in-use arguments;

b. partial compliance with applicable industry standards or guidelines, or other equivalent documents;

c. evidence from a previous qualification or a generic pre-qualification (e.g., certification to the relevant standard of IEC 61508) of the pre-developed software digital item, with consideration of the limits of applicability to the current application;

d. complementary testing;

e. analysis of the candidate product (e.g., design test coverage review); and

f. use of software modules, objects, libraries or components that have been verified.

CSA N290.14-15 allows a graded approach based on safety significance, operating history, complexity, functionality, and continuous or standby operation.

6-12

6.5 Chemical Safety Board (CSB)

The Chemical Safety Board (CSB) is an independent federal agency charged with investigating industrial chemical accidents. The CSB conducts root cause investigations of chemical accidents at fixed industrial facilities. Root causes are usually deficiencies in safety management systems but can be any factor that would have prevented the accident if that factor had not occurred.

Other accident causes often involve equipment failures, human errors, unforeseen chemical reactions or other hazards.

The CSB does not issue citations or fines, but it does make safety recommendations to facility management, industry organizations, labor groups, and regulatory agencies such as OSHA and EPA. After conducting an investigation, the CSB identifies any need for improvements and modernization to OSHAs PSM and to the Environmental Protection Agencys (EPAs) Risk Management Plan (RMP) program. Both OSHA and EPA have safety management regulations.

6.6 Department of Defense (DoD)

DoD has a large range of different applications for safety systems and mission critical computer applications. DoD expends extensive effort into developing those systems in a manner that allows them to have a very high level of correctness, reliability, and security. DoD uses MIL-STD-882E [83] to focus on providing performance criteria and does not prescribe specific design criteria or even specific design techniques. MIL-STD-882E states that its main goal is to eliminate hazards when possible and to minimize risks when hazards cannot be eliminated. The process for achieving this goal involves 8 elements. Those elements are:

1. document the system safety approach,

2. identify and document hazards,

3. assess and document risk,

4. identify and document risk mitigation measures,

5. reduce risk,

6. verify, validate, and document risk reduction,

7. accept risk and document, and

8. manage life-cycle risk.

During the process of assessing and documenting risks, the risks are categorized by severity and probability (frequency of occurrence). The probability levels can be defined as either qualitative or quantitative. Additionally, it is acknowledged that software risks must be assessed differently.

Due to inherent differences between the ways that hardware and software fail, predicting the probability of software failure is very difficult and cannot be based on historical data. Instead, software risks are assessed using software control categories, along with the severity categories to determine a software criticality index (SwCI). The SwCI is then correlated into a level of rigor (LOR) that can be used to define what the safety requirements are for the software.

Concerning classification of equipment, some specific terms are described in MIL-STD-882E.

Those terms are safety-related, safety-critical, and safety-significant. Safety-related is a term applied to a condition, event, operation, process, or item whose mishap severity consequence is either marginal or negligible. Safety-critical indicates a condition, event, operation, process, or item whose mishap severity consequence is either catastrophic or critical. Safety-significant is a term applied to a condition, event, operation, process, or item that is identified as either safety-critical or safety-related. DoD recognizes that even though these terms have been defined, their specific meaning will vary based on the nature of each specific application.

6-13

Hazard analysis is a significant aspect of the methodology prescribed in MIL-STD-882E. The sequence of hazard analyses is the preliminary hazard analysis (PHA), system requirements hazard analysis (SRHA), subsystem hazard analysis (SSHA), system hazard analysis (SHA),

operating and support hazard analysis (O&SHA), health hazard analysis (HHA), functional hazard analysis (FHA), system-of-systems (SoS) hazard analysis, and environmental hazard analysis (EHA).

The assessment of risk for software, and consequently software-controlled or software-intensive systems, cannot rely solely on the risk severity and probability. Determining the probability of failure of a single software function is difficult at best and cannot be based on historical data.

Software is generally application-specific and reliability parameters associated with it cannot be estimated in the same manner as hardware. Therefore, another approach shall be used for the assessment of softwares contributions to system risk that considers the potential risk severity and the degree of control that software exercises over the hardware. The degree of software control is defined using the Software Control Categories (SCC) in Table 6-7 (or approved tailored alternative) [83].

Table 6-7 The Software Criticality Matrix Shows how the Severity and Software Control Categories are Correlated to Determine a Software Criticality Index for the DoD Severity SCC Catastrophic Critical Marginal Negligible AT 1 1 3 4 Autonomous SAT 1 2 3 4 semi-autonomous RFT 2 3 4 4 redundant fault tolerant Influential 3 4 4 4 NSI 5 5 5 5 no safety impact In summary, MIL-STD-882E does not prescribe the use of any specific design architectures or methodologies to achieve safety. Instead, it is focused on the elimination and management of the risks involved and drives documentation of the specific methodologies that are implemented. It also prescribes the verification steps to ensure the implementations comply with the safety requirements that were derived from the hazard analyses.

The Software System Safety Engineering Handbook [84] is not a standard like MIL-STD-882E, but it is intended to provide additional guidance for achieving software system safety (SSS) as a subset within the overall concepts of system safety engineering. Appendix D of this handbook is specifically focused on use of COTS and NDI software. The approach presented in this handbook for evaluating a COTS item for selection and use in a safety system consists of the use of three criteria: confidence, influence, and complexity. The confidence aspect is focused on achieving strong evidence that indicates the COTS item will successfully perform its critical functions when installed within the full range of possible operating environmental parameters. The influence aspect focuses on understanding the safety significance of the role of the COTS item within the host safety system. Finally, the complexity aspect focuses on a combination of safety factors, testability factors, and integration factors. With these three criteriaconfidence, influence, and 6-14

complexityevaluations can be performed to make decisions about whether or not certain COTS items should be used within a particular safety system.

6.7 U.S. Department of Energy (DOE)

The U.S. DOE is like the NRC in that it does not currently use probabilistic classification methodologies. As a result, DOE-STD-1195 prescribes a deterministic approach based on the independent protection layers (IPLs) analysis methodology. Appendix B of the DOE standard contains a table that correlates the number of IPLs to either a SIL 1 or SIL 2 (reproduced as Table 6-8). The SILs are derived from ANSI/ISA 84.00.01-2004, which itself is based on the IEC SILs.

During the establishment of the safety basis for a DOE facility, the number of IPLs existing to prevent a hazardous event from occurring are counted and used to determine the SIL in accordance with the IPLs.

Table 6-8 SIL Determination Methodology in DOE-STD-1195-2011 [187]

3 SIL-1 Number of IPLs 2 SIL-2 1 SIL-2 Hardware fault tolerance (HFT) is defined as the ability of a functional unit to continue to perform a required safety function in the presence of a fault. This ability is expressed in the minimum number of required redundant sensors. The requirements per SIL expressed in Table 6-9 are from IEC 61511-1 [195]. This table is read by first looking for the SIL and then looking at the fault tolerance minimum. For example: A SIL 2 application requires one sensor and one redundant sensor. A SIL 4 application requires one sensor and two redundant sensors.

Table 6-9 Minimum Hardware Fault Tolerance Requirements According to SIL (IEC 61511-1 Table 6)

Hardware fault SIL tolerance (minimum) 0 0 1 0 2 1 3 1 4 2 The HFT requirement is not affected by the selection of either certified or prior-use sensors.

The HFT is comparable to redundancy in the nuclear sector. The safe failure fraction (SFF) and associated hardware fault tolerance requirements are intended as a way of preventing manufacturers from claiming high SILs for non-redundant devices simply based on the PFD calculation. The SFF tables were intended to ensure fault tolerance through required redundancy.

6-15

6.8 Electric Power Research Institute (EPRI)

EPRI provides guidance on the CGD process, configurability, SIL, and identification of an undeclared digital device in a component.

Many regulations and standards are based on IEC SILs. The objective of EPRI 3002011817

[276] is to demonstrate that equipment certified to non-nuclear safety standards (more specifically, IEC-61508/61511) can meet or exceed nuclear power reliability requirements without further analysis or verification at what EPRI describes as the platform level which refers to products and equipment versus levels involving how those are applied or integrated into the plant. This would allow NPPs to use the same supply chain and structures that non-nuclear safety related industries use. This broadens the supplier base, promotes competition, and allows the harvesting of economies-of-scale arising from other safety industries.

EPRI 3002011816 [154], the Digital Engineering Guide (DEG), applies systems engineering as the foundation to conduct a facility change that adds or modifies digital technologies, whether it is a new plant design, a major analog to a digital facility change, or a minor update to a software module in an installed digital system. The guidance uses a graded approach to match the rigor of each activity with the commensurate risks. Of interest is its applicability to EDDs. The DEG does not use the term embedded digital device, but EDDs would fit straightforwardly within the scope of the DEG. The DEG also uses the related term digital configuration item. The report states that A digital configuration item is an aggregation of hardware, software, or both, that is designated for configuration management and treated as a single entity in the configuration management process. It also notes that digital configuration items can be found in mechanical or electrical equipment (i.e., not just I&C equipment). Equipment information items such as technical manuals, data sheets, specifications, etc., should be examined carefully to determine if the equipment contains digital content. Equipment inspections may aid in this determination. Embedded programs, data and operating systems (firmware) and application software are considered digital configuration items.

For the suitability of an item, the DEG states that IEC SIL certification to IEC 61508 may provide evidence of product or platform suitability. If SIL certification is used as a method for demonstrating product or platform suitability, then the restrictions or conditions specified in the safety manual shall be integrated with related activities.

Some EPRI reports complement NRC regulatory guides by providing guidance for meeting the CGD requirements of 10 CFR 21 and the QA requirements of 10 CFR 50, Appendix B. EPRI NP-5652 [73] and EPRI TR-102260 [74] focus on CGD of hardware components. EPRI TR-106439

[54] and EPRI TR-107339 [77] provide guidance for accepting commercial-grade digital equipment. EPRI TR-1025243 [165] provides guidance for the CGD of safety-related design and analysis software tools.

In 1988, EPRI published EPRI NP-5652 to address industry concern over an effective methodology to ensure the proper dedication of CGIs used in safety-related applications. EPRI NP-5652 was the first guidance document to provide a detailed acceptance methodology specific to CGD for items used in NPPs. Industrys use of the CGD process has significantly increased over time as the number of suppliers with nuclear QA programs has decreased. However, the previous industry dedication guidance was developed in the late 1980s, and the NRC had only previously endorsed EPRI dedication guidance in Generic Letter 89-02 [287] and Generic Letter 91-05 [288].

6-16

EPRI NP-5652 defines the basic process for CGD: a technical evaluation, definition of critical characteristics for acceptance, and use of any of four acceptance methods to verify the characteristics. The key points of EPRI NP-5652 are the basic premise of CGD and the four acceptance methods for dedication. EPRI NP-5652 contains a generic procedure for acceptance of CGIs, as well as four alternative acceptance methods to provide flexibility. These four alternative acceptance methods are:

Method 1 Special Tests and Inspections Method 2 Commercial-Grade Surveys of Suppliers and Vendors supplying CGIs Method 3 Source Verification Method 4 Recording of Acceptable Supplier/Item Performance The report describes the implementation of each method and reviews examples of situations in which it could be beneficial to use more than one acceptance method.

EPRI TR-102260, which is not endorsed by the NRC, provides supplemental guidance to EPRI NP-5652 regarding the implementation of the process for dedicating CGIs for nuclear safety-related applications.

Digital equipment utilizing software presents new challenges in commercial dedication. However, the same basic approach still applies. Key elements of the dedication process are:

• An up-front technical evaluation to define the requirements for the device

• From these requirements, selecting a set of critical characteristics for acceptance

• Applying the methods described in NP-5652 (as endorsed by Generic Letter 89-02 and supplemented by Generic Letter 91-05) to verify the critical characteristics (or using the revision to NP-5652 as conditionally endorsed by RG 1.164).

With digital equipment, there are new critical characteristics and additional verification activities that need to be performed compared to analog equipment.

EPRI TR-106439 states that the following:

It is important to remember that when the final set of critical characteristics has been identified, all of these characteristics must be verified including physical, performance and dependability characteristics.

Although a prescriptive list of critical characteristics for each application of each device type may be useful, such a list could be easily misused. The list would become a check list rather than considering the device, its design, and use. It is the opinion of the ORNL researchers that a generic list of critical characteristics would not be a good solution, as they would be used as a checklist, and the result would not be adequate. Advances in I&C technology and functionality would require frequent updates to the check list otherwise the check list would become quickly outdated. An analogy is the migration from analog to digital systems. The first digital systems mimicked the analog systems. As experience with digital systems increased so did the 6-17

complexity, functionality, communications, etc. of the systems. The same is likely to occur with EDDs.

If appropriate verifiable critical characteristics cannot be identified, then commercial grade dedication cannot be used.

EPRI TR-102260 evaluated industry activities that occurred since the publication of EPRI NP-5652 and provides updated information that can be used to reduce engineering and procurement costs associated with CGD. Key points that should be considered when using this document in discussing software tools is that its primary focus is on materials and equipment and that no specific discussion is provided for digital equipment or software.

EPRI 3002002982 [53] is conditionally endorsed by RG 1.164. The NRC participated in the development of these methods [289]. EPRI 3002002982 describes a methodology that can be used to dedicate CGIs for use in safety-related applications. The scope of applications for which CGI dedication is used has evolved significantly since EPRI published EPRI NP-5652 and EPRI TR-102260. The guidance in this final report reflects lessons learned and addresses challenges that were identified through the expanded use of the original guidance.

EPRI TR-106439 [54] provides guidance for the dedication of commercial-grade digital equipment for use in safety systems. The guidance provided in EPRI TR-106439 addresses (1) application of the preexisting nondigital CGD guidance to digital systems, (2) identification of applicable codes and standards, (3) a process to perform the evaluation of commercial-grade digital equipment, and (4) acceptance criteria for using commercial-grade equipment in a safety system. This guideline is intended to help utilities evaluate, design, and implement digital upgrades involving commercial software-based equipment. The NRCs safety evaluation of EPRI TR-106439 concluded that TR-I06439 contains an acceptable method for dedicating commercial grade digital equipment for use in nuclear power plants. Furthermore, SRP BTP 7-18 [290] states that EPRI TR-106439 and EPRI TR-107330 describe an acceptable process for qualifying commercial systems. NUREG/CR-6421 provides additional information on the characteristics of an acceptable process for qualifying existing software, and discusses the use of engineering judgment and compensating factors for purchased PLC software.

EPRI TR-107330 [291] is a specification for qualifying a commercially available PLC for use in a safety application. The specifications are for evaluating a PLC for a safety-reated application, establishing a suitable qualification test program, and confirming that the manufacturer has an adequate QA program. The specification include requirements for QA measures to be applied, documentation to support the qualification, and documentation to provide the information needed for applying the qualified PLC platform to a specific application. EPRI TR-107330 emphasis that qualifying a particular platform for a different range of applications can be accomplished by making appropriate adjustments to the requirements. The NRCs safety evaluation of EPRI TR-107330 [292] concluded that the TR-107330 guidance is applicable to the generic qualification of a PLC as a component for safety-related applications....Because TR-107330 is generic, licensees referencing TR-107330 will need to document the details regarding the use of this specification in plant specific applications.

EPRI TR-107339 [77] is a supplement to EPRI TR-106439. EPRI TR-107339 provides more detailed guidance for evaluating commercial digital equipment through tailoring of the guidance in EPRI TR-106439 consistent with the importance of the digital equipment to safety and economics.

EPRI TR-107339 provides guidance for each of the phases of the CGI dedication process, including project definition, defining the detailed requirements, defining the critical characteristics 6-18

for acceptance, formulation of an acceptance strategy, and verification of critical characteristics.

Unlike EPRI TR-106439, EPRI TR-107339 is not endorsed by the NRC. The primary focus of EPRI TR-107339 is on the differences in the technical evaluation and acceptance process required for digital, software-based equipment and systems.

EPRI TR-1011710 [78] updates the methodology provided in EPRI TR-107339. This handbook provides updated design, analysis, and critical digital review guidance. The document was written by Electricité de France (EdF) and a U.S. consulting firm. The handbook combines the similar methods used in both countries for reviews of digital equipment (critical digital review and reinforced functional qualification [QFR]), incorporating the lessons learned and best practices from both countries. This documentation is not required to perform CGD, nor is it endorsed by the NRC, but it provides extensive updated guidance for documented design analysis of digital I&C as part of CGD.

EPRI TR-1025243 provides guidance for using its CGD methodology to accept commercially procured computer programs that perform a safety-related function. EPRI TR-1025243 provides a methodology that can be used to perform safety classification of non-process computer programs, such as design and analysis tools, that are not resident or embedded (installed as part of) plant systems, structures, and components. The report also provides guidance for using CGD methodology to accept commercially procured computer programs that perform a safety-related function. Included in EPRI TR-1025243 is a clarification of CGIs as related to computer programs.

EPRI TR-1025243, Rev. 1 is endorsed by NRC Regulatory Guide 1.231 with the following exception: the NRC staff does not accept the use of Revision 1 of EPRI Technical Report 1025243 dedication methodology for process (installed or embedded) computer programs or software tools associated with process computer programs.

EPRI 3002002289 [167], which is not endorsed by RG 1.231, supersedes EPRI 1025243. As with hardware, when a computer program having the functional safety classification of safety-related is furnished as a commercial item, it should be procured as commercial grade and dedicated for use as a basic component in a safety-related application. Guidance for accepting software integral to a plants SSCs is not included in the scope of EPRI 3002002289 because this type of software has been evaluated for use by the NRC. Guidance for accepting devices with integral computer programs may be found in the EPRI TR-106439 and EPRI TR-107330.

There is one important point to note in the discussion of CGD of the software portions of I&C systems described above: the difficulty in using testing as a tool to determine the quality of the software is that testing does not normally take into account software behavior under abnormal conditions and events. This differentiates system software from software tools, which are normally used under ideal conditions. Any abnormal event or condition that occurs during the testing or use of software tools can be eliminated simply by retesting or reprocessing.

Other EPRI documents not specific to the CGD process that are of interest for using and replacing EDDs include EPRI TR-1001503, EPRI 1008256, EPRI 3002005326, and EPRI 3002008010, which are described below.

The objective of EPRI TR-1001503 [34] is to identify and document existing systems and components that can be used for the modernization of I&C equipment in nuclear power plants and to make utilities more aware of alternative ways to modernize obsolete and costly-to-operate equipment. A database application consisted of a vendors database containing vendor information, a systems database capturing the capabilities of the product line, and a utilities 6-19

database containing data about specific implementations of a platform at NPPs. The database application was not maintained and is no longer available.

EPRI 1008256 [293] (formerly EPRI NP-6406), which is not endorsed by the NRC, provides detailed guidance for the technical evaluation of replacement items. This includes determining whether a replacement item is an equivalent or like-for-like replacement or if it is sufficiently different that a design change is required. It also includes guidance on defining safety-related functions and design requirements from which critical characteristics are identified.

EPRI 3002005326 [294], which is not endorsed by the NRC, recognizes that potential vulnerabilities can be managed using a combination of preventive and mitigative measures. This report provides practical guidance for addressing a full range of potential digital failure and CCF contexts. It includes steps for identifying and qualitatively assessing susceptibilities in terms of their likelihood, failure effects, and the measures in place to protect against them. The report also includes guidance on using susceptibility and coping analyses to screen and prioritize potential vulnerabilities. The guidance also includes the application of risk insights. The guidance provided in EPRI 3002005326 draws from industry standards and practices, lessons learned, and related EPRI products published over the last several years. It addresses both safety and non-safety applications. Technical considerations include factors that affect the likelihood of both latent software defects and the activating conditions that can trigger themfactors such as software development practices, test coverage, system and functional complexity, and designed-in defensive measures. The guide recommends using a safety-significance-based graded approach that considers the context of the I&C in the plant, the likelihood of failure, and the failure consequences in assessing the adequacy of the implemented preventive and mitigative measures.

Undeclared digital content is a concern in components with EDDs. EPRI 3002008010 [57],

which is not endorsed by the NRC, was prepared to assist EPRI members and their suppliers in detecting digital content embedded in electrical and electronic equipment and to prevent undeclared digital content from being installed. The report addresses the attributes associated with digital content including the type of processor, if the item supports data communication, and if the item is configurable. The report also provides signs of digital content (supplier literature, external, and internal) and how to identify them.

EPRI documents for CGD have evolved since first publishing EPRI NP-5652 in 1988. Although EPRI 3002002982 supersedes the original versions of EPRI reports EPRI NP-5652 and EPRI TR-102260 in their entirety [289], many CGI dedications cite EPRI NP-5652.

Of particular importance to EDDs is EPRIs document on undeclared digital content (EPRI 3002008010).

6.9 European Organisation for Civil Aviation Equipment (EUROCAE)

EUROCAE (European Organisation for Civil Aviation Equipment) ED-79/ARP-4754 [295] is focused on the railway, automotive, and aerospace sectors.

System safety requirements are established by a functional hazard assessment. The safety requirements of each function are defined by the most severe failure condition associated with this function. Table 6-10 shows the relationship between the five classes of failure conditions with the quantitative functional safety requirements (maximum rate of failure per flight hour) and the development assurance level for the system.

6-20

Table 6-10 Relationship Between Severity of Failure Condition, Safety Requirement, and Development Level [237]

Failure condition Quantitative safety Development class requirements (failure/h) assurance level (DAL)

Catastrophic P < 10-9 A Hazardous P < 10-7 B Major P < 10-5 C Minor None D No safety effect None E DAL A is comparable to IEC SIL 4, DAL B to IEC SIL 3, DAL C to IEC SIL 2, and DAL D to IEC SIL 1 [286].

While quantitative assessments can be used to assess whether safety requirements have been met for hardware, as far as systematic safety (hardware design and manufacturing/

software/installation errors) is concerned, qualitative techniques must be applied, and judgements must be made to demonstrate that a system meets the target safety levels.

The verification of safety requirements in a complex system would be problematic if these requirements were only expressed quantitatively [296]. The DALs (referred to as integrity levels by other SDOs) provide a qualitative indicator that a system meets its safety objectives. Its principal role is to relate a level of assurance about system safety to the application of an appropriate combination of quantitative and qualitative techniques during the system lifecycle.

Similar to other standards and guidance, when a function or a system is implemented using an architecture with more than one component, all the components inherit the system development level.

System architectural features such as redundancy, monitoring, or partitioning (the separation of critical from non-critical functions) can reduce the degree to which components contribute to specific failure conditions. Appropriate architectures can, therefore, reduce the necessary assurance activity, and as a consequence, the component DALs. The guidelines specify a number of such architectures and specify the potential reductions. A list of architectures is presented in Table 6-11.

6-21

Table 6-11 Architecturally Derived (and Reduced) Development Levels [237]

Most severe system failure condition /

Architecture system development level Catastrophic/A Major/B Partitioned design Level A for the partition. Each Each partitioned portion can partitioned portion can take a take a level corresponding to level corresponding to the most the most severe failure severe failure condition within condition within the partitioned the partitioned portion portion Two dissimilar, independent Level B for each portion Level C for each portion design implementing a function Two independent, partitioned Level A for the partition, level A Level B for the partition, level B designs implementing a for the primary portion, level B for the primary portion, level C function for the secondary portion for the secondary portion Active/monitor parallel designs At least one portion to level A, At least one portion to level B, the other portions to level C the other portion to level C Backup, parallel design Primary portion to level A, Primary portion to level B, backup portion to level C backup portion to level D Thus, ARP 4754 allows credit for partitioning, diversity, and redundancy for reducing the severity of system failure.

6.10 International Atomic Energy Agency (IAEA)

The top layer of the IEC standards derives from IAEA standards:

• IAEA SSR-2/1 [297] and IAEA SSR-2/2 [298] for the safety of nuclear power plants

• IAEA SSG-39 [16], which superseded IAEA NS-G-1.3 [172], for I&C systems important to safety in NPPs These standards are the basis for the first tier of safety for nuclear I&C: IEC 61513. Feeding into IEC 61513 is IEC 61508 for functional safety (non-industry specific).

The glossary for the IAEA [299] defines an item important to safety as an item that is part of a safety group and/or whose malfunction or failure could lead to radiation exposure of the site personnel or members of the public. Safety systems, safety-related items, and safety features (for design extension conditions) are all items important to safety:

• Safety system: a system important to safety, provided to ensure the safe shutdown of the reactor or the residual heat removal from the reactor core, or to limit the consequences of anticipated operational occurrences and design basis accidents

• Safety-related system: a system important to safety that is not part of a safety system

• Systems not important to safety 6-22

The term safety feature (for design extension conditions) refers to an item that is designed to perform a safety function for or that has a safety function for design extension conditions.

IAEA SSG-39 [16] provides recommendations on the design of I&C systems to meet the requirements established in IAEA Safety Standards Series No. SSR-2/1 [297]. IAEA SSG-39 is a revision and combination of IAEA safety guide IAEA NS-G-1.1 and draft safety guide IAEA DS-431. I&C systems important to safety are identified on the basis of the identification of necessary I&C safety functions and the definition of systems that perform certain combinations of these functions. The classification using IAEA SSG-39 aligns philosophically with the NRC classification.

IAEA SSG-39 provides guidance on the preparation of documentation used to adequately demonstrate the safety and reliability of computer-based systems important to safety. This safety guide applies to all types of software: pre-existing software or firmware, software to be specifically developed for the project, or software to be developed from an existing pre-developed equipment family of hardware or software modules. The safety standard requires software tools to be verified and assessed consistent with tool reliability requirements, the type of tool, the potential of the tool to introduce fault or fail to make the user aware of existing faults, and the extent to which the tool may affect redundant elements of a system or diverse systems. Tools that can introduce faults or fail to detect faults need to be verified to a greater extent than other tools; however, verification is not necessary if the tool output is systematically and independently verified.

IAEA SSG-39 [16] states that Commercial off the shelf devices tend to be more complex, may have unintended functionalities and often become obsolete in a shorter time. They will often have functions that are not needed in the NPP application. Qualification of a commercial off the shelf device could be more difficult because commercial development processes may be less transparent and controlled than those described in this Safety Guide. Often, qualification is impossible without cooperation from the vendor. The difficulty associated with acceptance of a commercial off the shelf device may often lie with the unavailability of the information to demonstrate quality and reliability.

The IAEA recognizes that SSG-39 is focused on the safety system. A new IAEA Nuclear Engineering (NE) Division series document will focus on smart devices and how the devices are used in an application [300]. Efforts on this new safety report began in 2018.

The IAEA is also working on Safety Report NSNI-18-23 [301] to address concerns specifically related to the use of smart devices. The IAEA recognizes that industrial or commercial grade smart devices are typically developed according to non-nuclear industry standards. Some of these devices are certified by non-nuclear organizations using those non-nuclear standards for the use in industrial safety applications (e.g. oil and gas industries, railways, aircraft). The qualification of an industrial or commercial smart device for applications in NPPs may be more difficult than a device specifically developed for the nuclear application. Similar to the nuclear industry, the availability of the information to demonstrate quality and reliability of a device is difficult to obtain. Currently there is limited regulatory guidance on the safe use of smart devices in nuclear safety systems, namely to select and evaluate smart devices for their use in NPPs, make use of a third-party certification within the framework of the assessment process, and adequately implement safety design criteria based on a graded approach.

IAEA SSG-39 provides limited, high-level guidance on the qualification of digital devices with limited functionality in order that they can be used in I&C systems important to safety. IEC 62671 provides guidance on the selection and use of industrial digital devices with limited functionality.

6-23

IAEA NSNI-18-23 specifically focuses on the selection and evaluation of devices of limited, specific functionality and limited configurability, for use in NPPs. Additional details on techniques and measures expected at different safety levels are available in IEC 61508.

IAEA COTS Guide NR T 3.31 [7] recognizes (1) the gradual decrease of market availability of nuclear qualified products, (2) the worldwide transition to digital technology, and (3) the increasing dependence on integrating commercial I&C products within new development or modernization projects. COTS devices are produced in large quantities, with varied widespread use and significant operating experience, providing a large, user-based test bed in which problems are identified and fixed. COTS devices may also offer benefits such as an extensive history of operation, a large installed user base, improved reliability with a proven operating history, proven technology, self-monitoring, and a larger group of technical personnel experienced with using them.

The use of COTS devices in systems important to safety raises concerns because their quality and integrity is not commonly developed in accordance with nuclear standards. Prior to use in NPPs, there is a need to demonstrate that digital COTS devices adhere to the functional, safety and environmental requirements (including heat, humidity, vibrations, electromagnetic interference/radiofrequency interference [EMI/RFI], seismic, etc., requirements as appropriate) with a level of quality and reliability comparable that of a nuclear product. When COTS devices are used in NPPs, it is important that a suitable process is in place to gather sufficient evidence and confidence to demonstrate that these products will meet specific quality, functional and non-functional requirements expected in the intended application.

The COTS guidance from the IAEA recognizes that COTS devices that are used in mechanical or electrical systems may not be considered as an I&C device. Users and assessors of these COTS devices may not be aware that these devices could be considered as an I&C device or that the device has an embedded digital component. Because the device function remains the same, the product literature and part number for the device may not be revised to reflect this change. If the digital subcomponent(s) are not identified, its (their) digital/software quality would not be assessed, and the component (i.e. COTS device) may have new failure mechanisms and modes that were not considered. This may also be referred to as COTS with undeclared content. This challenge is beyond the scope of the digital COTS justification process, but the IAEA COTS document cites NRC RIS 2016-05 and EPRI 3002008010 as two sources of information associated with this challenge.

6.11 International Electrotechnical Commission (IEC)

The IEC leverages IAEA safety guides to provide overall design principles for I&C systems. IEC standards must account for the regulations of all member states (62 full members, 26 associate members, 88 total members).

IEC standards are integral in the development of other standards in many industry standards as many industries have adopted the IEC standards outright or modified the standards to meet their specific needs. Table 6-12 and Figure 6-1 provide a listing of some industry standards and their relationship to IEC 61508.

6-24

Table 6-12 Industries that Use IEC Standards as a Basis Standard Industry Use IEC 61508 Non-Industry IEC 61508 provides guidance for safety-related systems.

Specific Large market sectors for sub-system/system suppliers conform to IEC 61508. Compliance with the standards in other sectors facilitate consistency with the requirements of IEC 61508.

IEC 61511 Process industry IEC 61511 has been developed as a process sector implementation of IEC 61508 IEC 61513 Nuclear power IEC 61513 provides an interpretation of the general requirements of IEC 61508-1, IEC 61508-2, and IEC 61508-4 for the nuclear application sector IEC/EN 62061 Control systems for IEC/EN 62061 is an industry-specific adaptation of IEC machinery 61508 IEC 62671 Nuclear power IEC 62671 provides requirements for determining whether digital devices of industrial quality, that are of dedicated, limited and specific functionality and limited configurability, are suitable for use in a nuclear application.

EN 5012X Railways EN 5012X is an industry-specific adaptation of IEC 61508 ISO 26262 Automobile ISO 26262 is a derivative of IEC 61508 and is an industry-specific adaptation of IEC 61508 ISO/IEC 62304 Medical devices ISO/IEC 62304 is an industry-specific adaptation of IEC 61508 ISO 13482 Robots ISO 13482 adopts the approach in IEC 62061 to formulate a safety standard for robots and robotic devices in personal care to specify the conditions for physical human- robot contact.

ISO collaborates closely with the IEC on all matters of electrotechnical standardization ISO 13849 Control systems for ISO 13849 Part 1 and IEC 62061 specify requirements for machinery the design and implementation of safety-related control systems of machinery. The use of either of these International Standards, in accordance with their scopes, can be presumed to fulfil the relevant essential safety requirements.

ISO collaborates closely with the IEC on all matters of electrotechnical standardization ISO/TR 23849 Control systems for ISO/TR 23849 provides guidance on the application of ISO machinery 13849 Part 1 and IEC 62061 in the design of safety-related control systems for machinery 6-25

Figure 6-1 Generic and Application Sector Standards for IEC Standards Cover the Entire Lifecycle of I&C Systems in Many Industries The IEC standards, and standards based on the IEC standards, used in process industries and foreign NPPs, are performance based and can provide a graded approach at the device level.

More specifically, IEC 61511-2 [202] states that IEC 61511 series is performance based, and that many approaches can be used to achieve compliance. IEC 61508 is considered to be performance-based because it avoids prescriptive rules, such as redundancy and self-test capability standard for the functional safety of equipment [276]. Similarly, ISA TR84.00.02-2015

[205] states that The approaches outlined in this document are performance-based; consequently, the reader is cautioned to understand that the examples provided do not represent prescriptive architectural configurations or MI requirements for any given SIL. Conversely, the U.S. nuclear industry has traditionally used a prescriptive method to determine the safety significance of a system and its impact on the severity of risk. As written, the 10 CFR 50 Appendix B/CGD approach for safety-related components is not readily transferrable to cross-walking quality standards to the different IEC SILs or to the application of a graded approach. However, reviewing the use of probabilistic, performance-based system analysis and the graded approach for achieving functional safety provided in the IEC standards can provide insights into the use of IEC SIL certified components and how they could fit into the NRC regulatory structure.

The guidance provided in key international IEC standards constitutes the basis for an overall approach to designing I&C systems important to safety. IEC 61508 [194] provides guidance for safety-related systems. Large market sectors for sub-system/system suppliers conform to IEC 61508. Compliance with the standards in other sectors facilitate consistency with the requirements of IEC 61508. The process industry uses IEC 61511 [195]. IEC 61513 [79]

represents the high-level guidance addressing I&C system architecture considerations in the nuclear sector; IEC 60880 [81] supplements that guidance by specifically addressing software-based system considerations; IEC 62340 [302] provides a framework for establishing a CCF 6-26

coping strategy that is consistent with the high-level requirements in IEC 61513 and complementary to the software requirements in IEC 60880.

IEC 61508 is based on two fundamental concepts [276]:

• safety lifecycle, which uses probabilistic, performance-based system analysis and design to minimize random failures and an engineering process to minimize systematic faults resulting from design and documentation errors

• SILs, which are used to implement a graded approach to achieving functional safety (with respect to both random and systematic failures)

IEC 61508-7 [303] provides a risk-based approach for determining the required performance of safety systems and provides generic requirements that can be used directly by industry or can be used as a basis for developing application-specific sector standards. This is arrived at by determining the severity of the risk associated with the hazard and assessing the frequency of the hazard and the protection to be provided by the system to reduce the risk from the hazard to a tolerable level.

IEC 61508 defines safety as a freedom from unacceptable risk of physical injury or of damage to the health of people, either directly, or indirectly, as a result of damage to property or to the environment. IEC 61508 defines functional safety as that part of safety that depends on a system or equipment operating correctly in response to its inputs. The safety lifecycle includes activities necessary to achieve the required functional safety for the functions executed by the electrical, electronic, and programmable electronic (E/E/PE) safety-related systems.

The use of IEC SILs allows correlation of expected quality standards to each SIL. A categorization framework or methodology is needed to map specific applications and equipment functions to the appropriate SIL. IEC 61508-5 [304] provides examples of how this can be accomplished. Once this framework is established, the QA sufficiency can be determined through the following approach:

• A specific SIL has been determined to be appropriate for the application.

• The equipment selected for the application has been determined to meet the requirements of that same SIL.

• Since meeting the requirements of the SIL includes satisfying the systematic integrity requirements, and since QA is an aspect of systematic integrity, it can be concluded that the QA used by the manufacturer to design and produce the equipment is adequate.

Components based on IEC 61508 are not directly applicable to NPPs. Differences in dedication also need to be understood. IEC 62671 [17] provides requirements for determining whether digital devices of industrial quality, that are of dedicated, limited and specific functionality and limited configurability, are suitable for use in a nuclear application. IEC 62671 states that IEC 61508 can be used as complementary guidance for the evaluation and assessment of components [for use in the nuclear industry], but it is recognized that certification to non-nuclear standards alone is insufficient. It is also important to remember that devices addressed by IEC 62671 are dedicated devices of limited, specific functionality. This statement most likely recognizes the lack of clear mapping between the prescriptive nuclear requirements and the 6-27

performance-based requirements of IEC 61508. It also reflects the concept that IEC 61508 requirements may not address nuclear-specific environmental concerns.

Although IEC 61508-1 does not require that the competence of personnel involved in functional safety assessments be formally authorized or accredited [276], most end-users who purchase IEC 61508 certified equipment demand that product certifications be done by a highly competent technical organization with accreditation from an Accreditation Body (AB) that is a member of the International Accreditation Forum (IAF) [305]. IAF membership includes more than 70 countries that are signatories of the IAF Multi-Lateral Agreement (MLA), which recognizes the equivalence of other members accreditations. There is a designated International Accreditation Forum (IAF) member entity in each country that performs accreditation. In the United States, ANSI is the national accreditation body. In the Federal Republic of Germany, it is the Deutsche Akkreditierungsstelle (DAkkS). Thus, IAF member accreditations are valid in most countries of the world.

The body for certifying items to IEC 61508 is accredited by a national accreditation body.

Accreditation bodies must meet ISO/IEC 17011 [306], which specifies requirements for the competence, consistent operation and impartiality of accreditation bodies assessing and accrediting conformity assessment bodies. ISO 17065 [307] specifies requirements, the observance of which is intended to ensure that certification bodies operate certification schemes in a competent, consistent and impartial manner, thereby facilitating the recognition of such bodies and the acceptance of certified products, processes and services on a national and international basis and so furthering international trade.

IEC 60880 [81] specifies requirements for achieving highly reliable software, covers all software life cycle activities, and together with IEC 61508, it can serve as the basis for certification of safety critical software for use in NPPs. It addresses each stage of software generation and documentation, including requirements specification, design, implementation, verification, validation and operation. Like other IEC standards, IEC 60880 is results oriented (i.e.,

performance based) rather than prescriptive, with a minimum set of V&V activities to be performed for each phase of development. Criteria within this standard are the resulting characteristics of the safety system.

With respect to the use of software tools, IEC 60880 requires documentation of tool use, adequate training on tool use, and verification of software tools to a level consistent with its reliability requirements, the type of tool, and the potential of the software tool to introduce faults. IEC 60880 and IEC 62138 [82] identify types of software tools that require different levels of verification and assessment. IEC 60880 does not require qualification of a software tool if the tool cannot introduce faults into the software, if the tool output is always systematically verified, or if tool faults are mitigated. IEC 62138 considers software tools to be support system software that is part of the system software in a typical I&C system and is either off-line or on-line (i.e., embedded in nonsafety support systems). Its requirements for software tools are consistent with but less rigorous than the IEC 60880 requirements. IEC 62138 focuses efforts on tool certification and the certification of the tool development process rather than a rigorous tool qualification process.

IEC 60987 [80] for computer hardware recognizes that software that is not firmware should be developed or assessed according to the requirements of the relevant software standard (that is, IEC 60880 for Class 1 systems and IEC 62138 for Class 2 systems).

IEC 61226 [175] establishes a method of classification of I&C systems and equipment according to their importance to safety. The classification of I&C functions depends on their contribution to 6-28

the prevention and mitigation of postulated initiating events. The resulting classification is then used in IEC 60880 and IEC 62138 to determine relevant specification and design requirements including qualification requirements for software tools used to develop I&C software and systems important to safety.

IEC 61513 [79] addresses hardware robustness and provides requirements for security at the level of the I&C architecture and of an individual I&C system. IEC 61513 allows I&C systems important to safety of classes 1, 2 and 3 to be implemented using conventional hard-wired equipment, digital technology equipment (computer based or programmed hardware) or by using a combination of both types of equipment. This international standard provides the acceptance criteria for the selection, evaluation, and use of certain digital devices that have not been developed specifically for use in these nuclear I&C systems.

IEC 61513 has been implemented by the nuclear industries in some countries, mostly in Europe, but this standard breaks from the performance-based requirements for systematic integrity and the probabilistic approach to reliability [308]. It points to other standards such as IEC 60880, IEC 62138, and IEC 60987 that implement a very prescriptive and deterministic approach that is very similar to the IEEE suite of standards (e.g. IEEE 603, IEEE 379, IEEE 7-4.3.2).

IEC 62671 [17] provides requirements for determining whether digital devices of industrial quality that were not developed specifically for use in nuclear I&C sytems are of dedicated, limited, and specific functionality and limited configurability are suitable for use in a nuclear application. This standard recognizes that devices addressed by this standard are dedicated devices of limited, specific functionality that contain or may contain components driven by software or digital circuits designed using software-based tools. Examples are smart sensors, valve positioners, and electrical protective devices or inverters that contain or may contain components driven by software or digital circuits designed using software-based tools. The IEC 62671 standard focuses on addressing the evaluation process, the elements of functionality and other requirements that shall be evaluated, the criteria for providing confidence in the correctness of the design and manufacture of the device, criteria for the integration of the device into a plant I&C system, and considerations for preserving the acceptability of the device. Thus, this standard is similar to a CGD facility dedicating a CGI for use in an NPP.

IEC 62671 [17] does not address the software aspects of complex general-purpose devices that are addressed by other standards such as IEC 60880 and IEC 62138 for software. This standard addresses the issues that should be considered when evaluating the suitability of these dedicated devices of limited, specific functionality for use in an NPP. The intent is to apply a graded approach to these issues, with more demanding requirements applied for higher classes.

Two other IEC standards are worth mentioning. The first, IEC 62098 [309], covers evaluation methods for microprocessor-based instruments. The second, IEC 60770-3 [310], provides guidelines for the evaluation of intelligent transmitters, including fault-injection testing.

The same components are typically certified for use in many other countries. For example, a specification sheet may list, among others, CSA (Canadian Standards Association, Canada),

ATEX (equipment for potentially explosive atmospheres, Europe), KGS (Korea Gas Safety, Korea), etc., to indicate that the product is certified for use in those countries. These certifications are generally the same as the IEC certifications. IEC certification can include specifying one of the four IEC 61508 SIL levels or classifying the component based on its safety in accordance with IEC 61226. A product assessment performed according to the requirements of IEC 61508 must include hardware probabilistic failure analysis, quality system evaluation, and an assessment of all 6-29

fault avoidance and fault control measures during hardware and software development. Because many vendors also supply many other industries, they also cite compliance with ISO 9001 [311]

for its QA program. Thus, it can be assumed that manufacturers that can achieve IEC SIL 2, 3, or 4 certifications can be assumed to have a complete, fully implemented QA program [157].

Although not necessarily a QA program that fully meets the requirements of Appendix B as per SECY-03-0117 which reviewed ISO 9001-2000 against the existing framework of Appendix B and concluded that ISO 9001 does not meet the requirements of Appendix B [52].

6.11.1 Process Industries IEC 61508 [194] and IEC 61511 [195] are currently the most widely used standards addressing the use of software in the process industry. IEC 61508 is used by manufacturers and suppliers to certify platforms and equipment, and IEC 61511 is used by designers, integrators, and end-users to certify applications of safety instrumented system. These standards address sensor software, even though its inclusion in the introduction of IEC 61508-7 [303] is rather indirect:

In most situations, safety is achieved by a number of systems which rely on many technologies (for example mechanical, hydraulic, pneumatic, electrical, electronic, programmable electronic). Any safety strategy must therefore consider not only all the elements within an individual system (for example sensors, controlling devices and actuators) but also all the safety-related systems making up the total combination of safety-related systems. Therefore, while this International Standard is concerned with E/E/PE [electrical, electronic, and programmable electronic] safety-related systems, it may also provide a framework within which safety-related systems based on other technologies may be considered.

Opposed to this, IEC 61511-1 [195] is very clear in its introduction:

The SIS [safety instrumented system] includes all devices necessary to carry out each SIF [safety instrumented function] from sensor(s) to final element(s).

Thus, IEC 61511 addresses the application of safety instrumented systems for the process industries, including sensors, logic solvers, and final elements.

Part 3 of IEC 61511 (ISA 84.00.01) and Part 5 of IEC 61508 describe methodologies that can be used to classify safety equipment. These methodologies all correlate an increase in requirements (higher IEC SIL) with the importance of the specific safety system to the overall safety of the plant (risk based, probabilistic). There are both qualitative and quantitative methods that are appropriate for certain types of systems and situations.

The IEC standards provide for device ratings by manufacturers. IEC 61508 has 4 SIL levels that are based on the probability of failure per hour (PFH) of operation. Each higher SIL value is a factor of 10 improvement in reliability. SIL-1 defines a probability of failure on demand (PFD) range of 10-1 to 10-2 or a risk reduction factor of 10 to 100. Table 6-13 and Table 6-14 show what this means in failures per year.

6-30

Table 6-13 Maximum Accepted Failure Rates Based on SIL for Low Demand Systems SIL PFD Failure rate of safety system SIL 1 10 pfd < 10

-2 -1 One failure in 10 years SIL 2 10-3 pfd < 10-2 One failure in 100 years SIL 3 10-4 pfd < 10-3 One failure in 1,000 years SIL 4 10-5 pfd < 10-4 One failure in 10,000 years Table 6-14 Maximum Accepted Failure Rates Based on SIL for High Demand Systems SIL PFH (per h) Failure rate of safety system SIL 1 10 pfh < 10

-6 -5 One failure in 100,000 h SIL 2 10 pfh < 10

-7 -6 One failure in 1,000,000 h SIL 3 10 pfh < 10

-8 -7 One failure in 10,000,000 h SIL 4 10 pfh < 10

-9 -8 One failure in 100,000,000 h A low demand mode on a safety system translates to a demand on the safety system not more frequently than once per year. Exida relates low demand mode to the proof test interval where the demand interval for operation made on a safety-related system is greater than twice the proof test interval [312]. Low demand mode (on demand) is typically found in the process industry

[188]. A typical example is an emergency shutdown system that only becomes active when the process becomes out of control. This normally occurs less than once a year.

A high demand mode (i.e., high demand rate or continuous demand) on a safety system translates to a continuous demand on the safety system or a demand that occurs more frequently than once per year.

Exida has a different definition of high demand mode that is intended to give credit to frequent diagnostics. High demand mode is where the demand interval for operation made on a safety-related system is less than 100x the diagnostic detection/reaction interval, or where the safety state is part of normal operation [312]. High demand mode (continuous mode) is mainly used in production engineering [188]. Continuous monitoring of working processes is frequently required to guarantee the safety of the workers and the environment.

Many industries use IEC SILs for meeting probability of failure on demand-average (PFDavg) or risk reduction factor (RRF). IEC SIL-1 represents the lowest risk-reduction level of performance; SIL-4 represents the highest risk-reduction level of performance. ISA 84.00.01 notes that SIL-4 is not used in the process industry sector because it requires elaborate systems and is difficult to support because of the high level of reliability required of the hardware. SIL-4 systems are not expected to be used for safety system controls in DOE facilities or in the process industries. For the process industry, SIL 4 is not to be required for a SIS. Non-process control measures are needed to reduce the risk to at least SIL 3 [313].

The following passages discuss the approaches used by IEC 61508 and IEC 61511, respectively.

6-31

Rating in accordance with IEC 61508: the definitions of IEC 61508 cover the complete product lifecycle from initial concept up to discontinuation of a product. In order to develop a component according to this standard, appropriate procedures and additional technical measures must be taken and verified from development through production. This often makes the development of a failsafe product more expensive than that of a standard component without SIL certification.

Rating in accordance with IEC 61511 (operational proof): currently there is only a limited number of devices which have been certified in accordance with the IEC 61508 standard. In order to allow a practicable selection of devices, the possibility of operational proof for devices has been permitted in IEC 61511.

Operational proof in IEC 61511 means that evidence must be provided to show a sufficient number of units in the field and include data on the operating period and conditions of use. A minimum period of use is 1 year, with a specified number of operating hours. The operational proof only applies to the version/release of the product for which the proof has been provided. All future modifications of the product must subsequently be carried out in accordance with IEC 61508.

The IEC SIL standard requires a functional safety assessment to be carried out on all parts of the safety-related system and for all phases of the lifecycle (see clause 8 of IEC 61508-1). The level of independence required of the assessor ranges from an independent person in the same organization for SIL 1 to an independent organization for SIL 3 / 4 (Table 6-15). In all cases, there is a specific requirement that the assessor be competent for the activities to be undertaken.

Table 6-15 Review Independence Based on IEC SIL [188]

IEC SIL 1 Independent person IEC SIL 2 Independent department IEC SIL 3 Independent organization IEC SIL 4 Independent organization Instruments that are fully compliant with IEC 61508 address systematic faults through a full assessment of fault avoidance and fault control measures during hardware and software development. There are three main parts to IEC 61508 which specify these requirements:

• Part 1 addresses the overall functional safety management of the product.

• Part 2 covers the hardware requirements, including achievement of failure rates and diagnostic coverage, as well as specific techniques and measures for avoidance of systematic failures.

• Part 3 covers the software requirements and is primarily focused on the process used when developing the software, including specific use of techniques, design, and coding standards and analysis and testing techniques.

Guidance from IEC 61511/IEC 61508 would place EDDs/components that perform HMI, diagnostics, and monitoring as IEC SIL 1, 2, or 3 based more on the system the component is in 6-32

rather than its functionality. This is consistent with how regulators in foreign countries assess IEC SIL levels. That is, the lower IEC SILs are applied to low risk situations.

Most smart sensors/actuators have a minimal operating system that handles interrupts and performs simple task scheduling; sometimes features such as priority scheduling, logging into files on flash, or emulating virtual memory are added. The application software layer, using these basic capabilities, implements the application-specific functionality, which of course varies considerably. These limited functionality EDDs may be referred to as simple devices in the process industry.

It is interesting to note that a smart device may be certified to different SILs depending on its use.

For example, the Fisher FIELDVUE DVC 6200 digital valve controller can meet the hardware requirements of IEC SIL 3 and the position monitor can meet the hardware requirements of IEC SIL 2 [312]. The software for the diagnostic function and transmitter / limit switch configurations are limited to SIL 2.

Basing the classification of the device on the safety class of the system in which it is installed may not match the consequences of its failure for those devices with limited functionality (i.e.,

monitoring, diagnostics, or HMI), especially if its failure does not impact the functionality of the component or system.

6.11.2 SIL Comparisons Safety-critical software requires a robust process of development, verification, configuration management, and QA processes. These processes are regulated by standards such as IEC 61508 [194] industrial control equipment manufacturers, EN 50128 [314] for railway equipment, ISO 26262 [72] for automobiles, ISO/IEC 62304 [315] for medical devices, and RTCA DO-178C [316] for airborne software. Many standards base the integrity of the software to the safety integrity level (Table 6-16).

Table 6-16 Comparison of SILs for Different Industries [327]

Safety Level Safety level IEC 61508 EN 50128 ISO 26262 ISO/IEC 62304 Automotive SIL Software SIL SIL Class 4 4 highest 3 3 D C C B 2 2 1 B A lowest 1 A 0

6-33

ISA 84.00.01 (the process industry daughter standard to IEC 61508) notes that the application of SIL 4 criteria is considered very unusual in the process industry and recommends redesigning the system to reduce its safety significance to a lower SIL before continuing on an effort to implement a system at SIL 4. It is further noted that SIL 4 is considered to be very difficult to achieve and maintain.

Translating the IEC SILs to safety/not safety for NRC has not been performed. The approval of the RadICS platform shows the difficulty in licensing and approving a digital control system platform solution for safety-related applications in NPPs that was based on IEC 61508 SIL 3. In its review [144], that NRC states Though functional safety assessments were performed to demonstrate RadICS platform compliance with IEC 61508 SIL 3 certification requirements, the NRCs regulatory framework does not include the SIL compliance approach. Where possible, the NRCs review compared the IEC methods to endorsed IEEE standards. For example, the SER stated that The SER recognizes that the FMEDA methods used were found to be consistent with IEEE Standard 379 2000 as endorsed by RG 1.53 Rev. 2. In other parts, the NRC required CGD of the platform because the RPC Radiy QMS [Quality Management System] has not been assessed by the NRC staff to be compliant to 10 CFR Part 50, Appendix B. It would be interesting and likely helpful to understand how the IEC SIL 3 conforms to the NRCs safety classification.

6.12 Institute of Electrical and Electronics Engineers (IEEE)

IEEE has more than 419,000 members in over 160 countries. IEEE standards may be required by the NRC by regulation (i.e., IEEE Std. 603-1991) or endorsed as providing an acceptable method for for complying with the Commissions regulations (i.e., 43 IEEE standards are endorsed by NRC Div. 1 regulatory guides [317]).

The clauses in IEEE standards are applicable at the component and system levels, depending on the clause. For EDDs, the most applicable standards are IEEE Std. 603, IEEE Std. 7-4.3.2, and IEEE Std. 1012 (currently endorsed in their 1991, 2003, and 2004 versions respectively).

IEEE 7-4.3.2-2016 [26] provides specific requirements for programmable digital devices to supplement the criteria and requirements of IEEE Std. 603-2009 [318]. Subclause 5.17 in IEEE 7-4.3.2-2016 requires that previously developed systems be qualified using a dedication process for a CGI. Annex C (informative) provides guidance for dedicating a CGI, including consideration of hardware, software, or firmware failures (i.e., hazards that could interfere with accomplishing the safety function). IEEE 7-4.3.2-2016 requires that software be developed, modified, or accepted in accordance with an SQA plan and that the plan shall address the software tools used for system development and maintenance.

IEEE Std. 1012-2004 [209], endorsed by Regulatory Guide 1.168, Rev. 2 [319], defines four software integrity levels (IEEE SILs (Table 6-17), not to be confused with the IEC safety integrity levels [SILs]. NRC endorses this standard for V&V, reviews, and audits of software used in safety systems. However, RG 1.168 states that software used in NPP safety systems should be assigned SIL 4 or the equivalent, as demonstrated by a mapping between the applicant or licensee approach and SIL 4 as defined in IEEE Std. 1012-2004. Thus, although four IEEE SILs exist, only SIL 4 is applied to safety systems in NPPs. Although not currently used in the licensing of NPPs, the different IEEE SILs provide a graded approach to software development.

6-34

Although there are four integrity levels, the newer version of IEEE-1012-2016 no longer uses the SIL terminology to avoid confusion with the much more widely used IEC-61508 context; rather, IEEE 1012-2016 refers to integrity levels. IEEE 1012-2016 is part of a much larger portfolio of lifecycle standards and using a V&V standard in isolation without a full discussion of the lifecycle may have unintended consequences. Lastly, IEEE 1012-2016 adopts modern systems engineering that includes an integrated view of hardware and software. IEEE 1012-2016 is currently not endorsed by NRC, but the differences between the -2004 and -2016 version are noted in the -2016 version to avoid confusion.

Table 6-17 Four-level Software Integrity Scheme in IEEE Std. 1012-2004 IEEE Std. 1012 SIL Consequences Mitigation 4 Grave No mitigation 3 Serious Partial to complete mitigation 2 Minor Complete mitigation 1 Negligible Mitigation not required Annex B (informative; not endorsed) of IEEE Std. 1012-2004 provides an example of a risk-based, four-level integrity scheme. The risk-based scheme, shown in Table 6-18, assigns a software integrity level based upon the combination of an error consequence and the likelihood of occurrence of an operating state that contributes to the error. Some table cells reflect more than one software integrity level, indicating that the final assignment of the software integrity level can be selected to address the system application and risk mitigation recommendations. For some industry applications, the definition of likelihood of occurrence categories may be expressed as probability figures derived by analysis or from system requirements.

Table 6-18 Graphic Illustration of the Assignment of Software Integrity Levels (Source : IEEE Std. 1012-2014, Table B.3)

Likelihood of occurrence of an operating state that Error contributes to the error (decreasing order of likelihood)

Consequence Reasonable Probable Occasional Infrequent Catastrophic 4 4 4 or 3 3 Critical 4 4 or 3 3 2 or 1 Marginal 3 3 or 2 2 or 1 1 Negligible 2 2 or 1 1 1 This standard applies to software being acquired, developed, maintained, or reused (legacy, modified, COTS, non-developmental items [NDIs]). The term software also includes firmware, microcode, and documentation. In many instances, the consequence/mitigation SIL definitions are applied, while the risk-based SIL levels are informative.

It is unknown if and to what extent IEEE standards are used in industry outside the nuclear arena.

Many of the standards, such as IEEE Std. 1012, are used for software development at NPPs.

However, the IEEE Std. 1012 working group stakeholders include vendors that supply both the nuclear industry and other entities in DOE, DoD, NASA, aerospace, NNSA, and universities.

6-35

When conducting V&V of a system, software, or hardware element, IEEE Std. 1012 states that it is important to examine the interactions with the system of which the element is a part. When performing V&V of an EDD, one should ask how it fits into the system.

The V&V processes for the software in an EDD will be similar to that for the software in a system.

As far as licensing is concerned, the software in EDDs presents many aspects similar to those for the development of software or the use of pre-existing software. Thus, several issues, common positions, and recommended practices for software in general also apply to the development of software in EDDs.

When validating the software in an EDD, assessments will be performed on a specific version of the device and the associated software. However, if the supplier changes its product (e.g., the software version), then the EDD should undergo another validation process. Thus, similar to system software, a process must be established to ensure that the software installed in the EDDs is the same version as those subjected to the validation process. In addition, a supplier could upgrade a product from a conventional device to one with embedded software without the end user being aware of this change. A process must be established to ensure that such changes are detected and that the EDD is subjected to assessment.

Quality of the software development process, such as using IEEE SILs as defined in IEEE Std.

1012, are used by Korea in evaluating EDDs.

6.12.1 IEEE WG 6.6 IEEE working group WG 6.6 Intelligent Digital Devices, was formed in 2012 as part of an effort by the IEEE Power and Energy Society (PES), Nuclear Power Engineering Committee (NPEC),

Subcommittee 6 Safety Related Systems, to identify areas for development of new standards.

WG 6.6 was formed to develop guidance on the use of intelligent digital devices (IDDs) in NPPs.

WG 6.6 started work on IEEE P1891 [320] with the scope of addressing IDDs in safety-related applications. The scope of P1891 evolved over the years to also cover simple and complex IDDs in augmented quality and nonsafety related applications, using a graded approach. WG 6.6 has recently narrowed the scope of their activities to focus on simple devices or devices of limited functionality for use in safety-related applications. The new standard will address certain devices that contain embedded software or electronically-configured digital circuits used in systems and equipment important to safety in nuclear power plants. It will provide requirements for the selection and evaluation of such devices where they have dedicated, limited, and specific functionality and limited configurability. There are similarities in scope between the current WG6.6 work and IEC 62671. WG6.6 is currently engaging IEC to pursue a Dual Logo standard with IEC 62671.

6.13 International Society of Automation (ISA)

ISA has adopted several IEC standards for use in automation and control systems. ISA has over 150 consensus industry standards.

ANSI/ISA-84.00.01-2004 is an identical adoption of IEC 61511, with the addition of a grandfather clause to accommodate existing SIS installations. The only modification to IEC 61511 for adoption as a U.S. standard (i.e., ANSI/ISA-84.00.01-2004 [IEC 61511-1 Mod]) was reference to the United State's handling of legacy systems (i.e., the grandfather clause).

6-36

DOE and OSHA cite the ANSI/ISA 84.00.01-2004 standard rather than IEC 61511.

ANSI/ISA 84.00.01-2004 Part 1 (IEC 61511-1 Mod) [76] provides several methods for determining SILs, such as layer of protection analysis, which uses frequency of the event as a basis, or safety layer matrix, which uses available information of IPLs as a basis for selection of SILs for the SISs.

ANSI/ISA 84.00.01-2004 is used by the process industries for designing reliable SISs that are commensurate with the level of hazard mitigation or prevention strategy.

The evaluation approaches outlined in ISA-TR84.00.02-2002, Part 2 [321] are performance-based approaches and do not provide specific results that can be used to select a specific architectural configuration for a given SIL.

6.14 International Organization for Standardization (ISO)

ISO collaborates closely with the IEC on all matters of electrotechnical standardization.

With respect to quality, many industries cite compliance with ISO 9001:2015. This standard includes requirements for leadership, planning, support, operation, performance evaluation, and continual improvement.

The automotive industry cites compliance with ISO 26262 [72]. ISO 26262 is an international standard for functional safety of electrical and/or electronic systems in production automobiles.

ISO 26262 is a derivative of IEC 61508, and similar to IEC 61508, is risk-based, where the risk of hazardous operational situations is qualitatively assessed, and safety measures are defined to avoid or control systematic failures and to detect or control random hardware failures or mitigate their effects.

ISO 26262 contains requirements for software integration and testing to demonstrate that the software architectural design is realized by the embedded software. ISO 26262 also contains requirements for the verification of software safety requirements to demonstrate that the embedded software fulfils the software safety requirements. The -2018 version of ISO 26262 includes guidance for software tool selection, use, documentation, and qualification.

Unlike the IEC standards with SILs 1-4, ISO 26262 uses four ASILs, A through D, to tailor the requirements of ISO 26262 to avoid unreasonable residual risk. ISO 26262 requires software to be assigned to one of four ASIL categories on the basis of the system ASIL and the level of risk associated with the use of the software in the system.

6.15 The National Aeronautics and Space Administration (NASA)

The consequence-based approach in NASA-GB-8719.13 [208] (NASA-GB-8719.13 supersedes NASA-GB-1740.13) evaluates the consequences of the device failure and its impact on the system. NASA-GB-8719.13 encourages the use of simulators or an in-circuit emulator (ICE) system for debugging in embedded systems because these tools allow the programmer or tester to find some subtle problems more easily. However, the guidebook does not discuss simulator or ICE system verification, validation, qualification, review, or approval practices.

NASA-STD-7009 [242] provides an approved set of requirements, recommendations, and criteria with which models and simulations (M&S) may be developed, accepted, and used in support of NASA activities. NASA does not provide specific verification, validation, or qualification 6-37

requirements for most COTS, GOTS, or MOTS software tools and expects automatically generated code to be treated to the same level as hand-generated code [67].

6.16 Nuclear Energy Agency (NEA)

The NEA is an agency within the Organisation for Economic Co-operation and Development (OECD). The NEA's current membership consists of 33 countries in Europe, the Americas, and the Asia-Pacific region. The goal of the NEA in the area of nuclear safety technology and regulation is to assist member countries in ensuring high standards of safety in the use of nuclear energy by supporting the development of effective and efficient regulation and oversight of nuclear installations and by helping to maintain and advance the scientific and technological knowledge base. All NEA members are also IAEA members.

MDEP was established in 2006; the nuclear regulatory authorities of 16 countries participate in MDEP. The NEA facilitates MDEP activities by providing technical secretariat services. This is a multi-national initiative to leverage resources and knowledge of national regulatory authorities tasked with regulatory design review for new reactors.

MDEP Common Position CP-DICWG-07 [15] (MDEP Generic Common Position #7) addresses using industrial digital devices of limited functionality in systems important to safety but that have not been developed specifically for use in nuclear power applications. The definition of a digital device of limited functionality, taken from IEC 62671, excludes PC, PLCs, etc. MDEP recognizes that the worldwide nuclear power industry is increasingly interested in using industrial digital devices of limited functionality [emphasis added] in systems important to safety, but that have not been developed specifically for use in nuclear power applications. Some of these devices are found embedded in plant components and actuating devices such as sensing instrumentation, motors, pumps, actuators, and breakers. MDEP does not consider complex devices such as those that use commercial computers (PCs, PLCs) to be industrial digital devices of limited functionality.

MDEPs Vendor Inspection Cooperation Working Group (VICWG) [322] is focused on evaluating opportunities to maximize the use of results from international regulator efforts at vendor facilities

[323] that includes

1. Developing a common QA quality control (QC) criteria document for use by multi-national regulatory bodies conducting joint inspections

2. Developing an inspection protocol for implementation of multi-national inspections

3. Completing several inspections with support by international regulators (both domestically and abroad)

Its first multi-national inspection was scheduled for July 2014 using the protocol and common QA/QC criteria documents with Valinox in Montbard, France (SG tube manufacturer).

NEA/CNRA/R(2014)7 [248] reports on the survey on the design review of new reactor applications. These are to serve as guides for regulatory organizations to understand how technical design reviews are performed by member countries. The licensing process surveys are based on IAEA Safety Guide GS-G-4.1. This volumeVolume 1is focused on I&C. Survey responses were provided by 11 countriesCanada, Finland, France, India, Japan, Republic of Korea, Russian Federation, Slovak Republic, Slovenia, Sweden, and the United States.

6-38

Standards cited by the various countries for regulating NPPs include those by CSA, ISO, IEC, IAEA, IEEE, and AERB.

6.17 Nuclear Energy Institute (NEI)

The NRC is currently evaluating the sufficiency of the NEIs proposed guidelines for digital modifications, cyber security controls, and CCFs:

• NEI 96-07, Appendix D [224]

• NEI 13-10, Rev. 5 [90]

• NEI 17-06 (still in draft) [308]

NEI 96-07, Appendix D may eventually supersede the supplemental RIS 2002-22. [Regulatory Guide 1.1.187, Rev. 2, published in June 2020, endorses NEI 96-07, Appendix D, Revision 1, as a means for complying with the requirements of 10 CFR 50.59 when conducting digital I&C modifications, subject to clarifications.]

The Nuclear Energy Institute (NEI) has a working group focused on Modernization Plan (MP) #3-Commercial Grade Dedication. This working group is leveraging EPRI 3002011817 [276] to specify a third-party IEC 61508 SIL certification as an alternate approach to determining the acceptability of some of the dependability critical characteristics as defined by EPRI TR-106439.

NEI is proposing this alternate method in a new document identified as NEI 17-06. Note that NEI 17-06 is still in draft form and the information in this report may become inaccurate.

Dependability critical characteristics are a special type of characteristic that are specifically associated with programmable digital devices (PDDs), which includes the scope of EDDs. This alternate method is being proposed to be used in lieu of the traditional verification methods of commercial grade surveys (EPRI method 2). The proposal also asserts that the IEC 61508 certification also removed the need for a detailed design review such as a Critical Design Review (CDR) as defined by EPRI 1011710 [78]. The primary basis for this proposal is that the development, manufacturing, and third-party review process involved in a SIL certification encompasses the requirements and activities involved in the performance of a design review and in the use of commercial grade surveys.

The intent of NEIs proposal is to use an existing ecosystem of dependable safety equipment in a manner that reduces lead time and procurement cost.

None of the other regulators reviewed cited an NEI white paper. However, EPRI 3002011817 was written to demonstrate that equipment certified to non-nuclear safety standards (more specifically, IEC-61508/61511) can meet or exceed nuclear power safety and reliability requirements without further analysis or verification; this EPRI document is related to the proposed NEI 17-06.

6.18 National Institute of Standards and Technology (NIST)

NIST special publication (SP) 500-234 [324] contains only a few high-level software tool requirements that deal with V&V and training associated with the health care industry. Both NIST SP 500-234 and IEEE 1012-2012 recommend that an independent V&V (IV&V) team execute qualification tests on tools (e.g., compilers, assemblers, and utilities) shared with the development environment and recommend that the IV&V team should use or develop its own set of test and analysis tools when possible. Both NIST SP 500-234 and IEEE 1012-2012 also state that the 6-39

V&V plan should include details for acquiring tools and for training personnel. However, NIST SP 500-234 does not discuss software integrity levels or provide minimum V&V activities as a function of integrity level. NIST SP 500-234 does not distinguish between different categories of tools or use safety as a measure to determine tool qualification requirements.

NIST SP 800-161 [325] provides guidance to federal agencies on identifying, assessing, selecting, and implementing risk management processes and mitigating controls throughout their organizations to help manage their iformation and communications technology (ICT) supply chain risks.

6.19 Office for Nuclear Regulation (ONR)

The UK Office for Nuclear Regulation (ONR) is the regulatory authority that oversees the safety and security at 37 nuclear licensed sites in the UK [326]. The UK generally operates a goal setting regime . This means that ONR sets out broad regulatory requirements, and it is for licensees to determine and justify how best to achieve them, referencing relevant good practice

[300]

The key principles considered by ONR inspectors in the review of safety submissions are set out in the SAPs [124]. The key SAP applicable to computer based safety systems is clause ESS.27, which states:

Where the system reliability is significantly dependent upon the performance of computer software, compliance with appropriate standards and practices throughout the software development lifecycle should be established in order to provide assurance of the final design.

The concepts outlined in the key SAPs are then expanded in more detailed TAGs.

The purpose of ONR TAG-046 [126] is to provide additional guidance for applying SAP ESS.27.

ESS.27 presents the elements of a multilegged procedure that should be used to demonstrate the adequacy of a computer-based safety system. An important distinction between smart devices and other computer-based systems is that the end user cannot modify or add device functionality to a smart device in any way, though they can usually perform limited configuration. Such devices are still considered as computer-based systems, and therefore their use in safety or safety-related applications should be justified according to SAP ESS.27.

For NPPs, TAG-046 states that IEC 61513 should be considered for assessing software aspects of computer-based systems important to safety as the general requirements for systems (all classes), IEC 60880 for software aspects for systems performing category A functions, and IEC 62138 for category B or C functions. While TAG-046 addresses some hardware-related topics, the IEC standard requirements for computer-based system hardware for NPPs are provided in IEC 61513 and IEC 60987 for class 1 and 2 systems and in IEC 61508 for class 3 systems.

TAG-046 recognizes that IEC 61513 does not provide an explicit link between safety class and IEC SIL as defined in IEC 61508. However, it does acknowledge that there are similarities between the assignment of SILs to safety functions in IEC 61508 and the classification of nuclear safety functions in IEC 61226. ONR has adopted the position outlined in NS-TAST-GD-003 [207]

and NS-TAST-GD-094 [328], whereby the system class is aligned to probabilistic targets and deterministic expectations. However, based on the information provided in TAG-046, a relationship between class and IEC SIL can be determined (Table 6-19).

6-40

Table 6-19 Relationship Between Safety Class and IEC SIL ONR TG-046 Class IEC SIL 1 3 or 4 2 2 3 1 The relationship between safety class, SIL, and numerical integrity target can be subject to some variation. For category A / class 1, the techniques required by IEC 61508 for SIL 4 should be applied, but the licensee can only claim a risk reduction (e.g., in the PSA) of 1E-4 (despite the fact that IEC 61508 allows for down to 1E-5). (This is assuming the hardware reliability supports 1E-4 or better; if it does not, then the claim is limited by the hardware reliability.) For category B / class 2, the initial expectation is that the techniques required by IEC 61058 for SIL2 should be applied, but then the licensee can only claim 1E-2. If the licensee wants to claim 1E-3, it needs to do better than just meet IEC 61508 SIL2. The framework set out in the rest of TAG 46 production excellence represented by the best practice by manufacturer and ICBMs represented by the confidence-building activities performed by the licensee or their agent is the mechanism to achieve this. (Likewise, for category C / class 3, SIL 1 gives 1E-1 by default; TAG 46 is applied to reach 1E-2.) In practice, the licensees almost always claim 1E-2 for a SIL 1 system, and this should be supported by a good production excellence / ICBM.

Clause 2.6 in TAG 046 describes an approach and references for risk informing. The key concept is that the safety class assigned is related to the risk reduction required. Therefore, identical systems could have very different safety classes due to the lack or presence of other independent systems to mitigate the hazard.

When determining the requirement for the system, ONR expects the deterministic analysis to be the primary means of determining the requirement, particularly for reactor protection, where these functions are well defined in IEC 61226. However, the PSA will often have some relevance in determining the requirement, especially if the system does not fit into the IEC 61226 framework. If the PSA requires lower than 1E-2 but not lower than 1E-3 (e.g., 9E-3), then this equates to a class 2 / SIL 2 system. Likewise, 9E-4 would be class 1 / SIL4, or possibly class 2 / SIL3, depending on deterministic arguments. (Note that ONR does not accept a claim better than 1E-4 for a computer-based system.)

If the PSA holds together with a claim of 1E-2, then, deterministic arguments aside, ONR would accept class 3 / SIL1 and expect good production excellence / ICBM. If the PSA holds together with a claim of 1E-1, TAG 46 states that ONR still expects class 1 / SIL1 (para 5.8); it is only when 3E-1 is needed that ONR would specify that TAG 46 compliance is no longer necessary. In practice, it appears that ONR may rely on third-party assessments and manufacturer pedigree arguments for 1E-1.

Best estimate is used when the PSA is being used to determine safety vulnerabilities and when the overall big picture could be distorted by conservatism just for the computer-based systems. It does not allow a reduction in the techniques expected to justify the numerical claim. When a PSA is driving the integrity requirement, then the PSA requires the high-confidence figures before being established as the requirement for the system.

6-41

Appendix 8 of ONR TAG-046 [126] outlines the ONRs expectations for the safety justification of COTS smart devices. Smart devices are instruments, sensors, actuators or other previously electromechanical components (e.g., relays, positioners and controllers), whose functionality is limited [emphasis added] and which feature built-in intelligence in the form of a microprocessor or hardware description language (HDL)-programmed device to help perform its function. An important distinction between smart devices and other computer-based systems is that the end user cannot modify or add device functionality in any way, although they can usually perform limited configuration. Such devices are still considered to be computer-based systems, so their use in safety or safety-related applications should be justified according to SAP ESS.27.

Table 6-19 relates the ONR TG-046 Clause 9.9 classes to IEC SIL levels, and Table 6-20 provides a link between categorization, classification, and IEC SIL.

Table 6-20 Link Between Categorization, Classification and SIL (TAG-046, Table 1 [126])

Category IEC 61508 IEC 61508 ONR initial Initial acceptable Limit to

& class PFD range FF range expectation nuclear safety reliability claim according (high (high re application case PFD value providing to TAG94 confidence) confidence) of techniques or FF (high relevant

& measures confidence) assessment per IEC 61508 criteria was met (high confidence)

Category A 1E-5 PFD 1E-5 FF < SIL 4 1E-4

• 1E-4*

/ class 1 < 1E-3 1E-3 Category B 1E-3 PFD 1E-3 FF < SIL 2 1E-2 1E-3

/ class 2 < 1E-2 1E-2 Category 1E-2 PFD 1E-2 FF < SIL 1 1E-1 1E-2 C/ < 1E-1 class 3 1E-1

• Note the best (minimum) that should be claimed for a computer-based safety system is 1E-4 (high confidence). A claim of 1E-4 (high confidence) should always be delivered by a SIL 4 system.

FF = frequency of dangerous failure per year One key part of the regulatory process, upon which NS-TAST-GD-046 [126] is based, is that the grading allowed in the guidance impacts the reliability claim that the licensee can take for the device. While ONR does use a best estimate PRA (called PSA within their regulatory infrastructure) for certain purposes, when it comes to determining the needed grade of a system, a high confidence value limited as in Table 6-20 must be used. This means that if one device is implemented at a lower grade, then it may result in others being required to be implemented at a higher grade.

Currently, no such reliability feedback mechanism as a consequence of using a graded approach exists within the NRCs regulatory infrastructure.

It should be noted that the high confidence numerical values in Table 6-20 start at 1E-1 and do not exceed 1E-4, even for a SIL 4 system with relevant assessment criteria having been met.

6-42

6.20 Occupational Safety and Health Administration (OSHA)

To help ensure safe and healthful workplaces, OSHA has issued the Process Safety Management of Highly Hazardous Chemicals standard (29 CFR 1910.119), that contains requirements for the management of hazards associated with processes using highly hazardous chemicals.

PSM is addressed in specific standards for general and construction industries. OSHA's standard emphasizes the management of hazards associated with highly hazardous chemicals and establishes a comprehensive management program that integrates technologies, procedures, and management practices. OSHA has PSM for different industries [329]:

• Process Safety Management for Petroleum Refineries. OSHA Publication 3918 (2017)

• Process Safety Management for Explosives and Pyrotechnics Manufacturing. OSHA Publication 3912 (2017)

• Process Safety Management for Small Businesses. OSHA Publication 3908 (2017)

• Process Safety Management for Storage Facilities. OSHA Publication 3909 (2017)

• PSM Covered Chemical Facilities National Emphasis Program. OSHA Directive CPL 03-00-021 (January 17, 2017)

• Process Safety Management - Small Business Advocacy Review Panel. OSHA is initiating a Small Business Advocacy Review Panel to get feedback on several potential revisions to OSHA's Process Safety Management Program (PSM) standard

• Petroleum Refinery Process Safety Management National Emphasis Program. OSHA Directive CPL 03-00-010 (August 18, 2009)

The PSM standards are performance-oriented. Therefore, employers have the flexibility in complying with the requirements of PSM, including, among other aspects, the use of recognized and generally accepted good engineering practices. Specific to this review, OSHA stated that ANSI/ISA 84.00.01-2004 Parts 1-3 (IEC 61511 Mod) may be applied under OSHA's PSM standard, 29 CFR 1910.119 [330]. OSHA considers the revised ANSI/ISA S84.00.01-2004 Parts 1-3 (IEC 61511 Mod) to be recognized and generally accepted good engineering practices for SISs. OSHA does not specify or benchmark S84.00.001-2004, Parts 1-3 as the only recognized and generally accepted good engineering practice.

6.21 Federal Railroad Administration (FRA)

The purpose of the Federal Railroad Administration (FRA) is to promulgate and enforce rail safety regulations, administer railroad assistance programs, and conduct research and development in support of improved railroad safety and national rail transportation policy.

The railway industry cites compliance with BS EN 50128 [171], a railway-specific implementation of IEC 61508 that specifies technical requirements for the development of safety-related software for railway control and protection systems. BS EN 50128 [171] and EN 50129 are two European standards (EN 5012x) that define safety-related software process standards, hardware, and approval processes for railway applications. EN 50128 provides process standards for software 6-43

for railway control and protection systems. EN 50129 covers safety-related electronic systems for signaling Even though the safety lifecycles for industry-specific standards such as EN 50128 16 for a railway 15F inherit the definition of phases from the generic IEC standard of IEC 61508, the detailed phases of the safety lifecycles for the specific industries are different from IEC 61508.

The railway industry uses a probabilistic risk-based process for safety-related system and software development. This standard requires a systematic approach for safety-related software development to identify hazards, assess risks, and identify risk reduction measures. BS EN 50128 requires software to be assigned to one of five SILs, from SIL 0 (lowest) to SIL 4 (highest),

on the basis of the system SIL and the level of risk associated with the use of the software in the system. BS EN 50128 does not use all five levels of safety integrity. Instead, the requirements for SIL 1 and SIL 2 are the same for each technique or measure. Similarly, each technique or measure has the same requirements at SIL 3 and SIL 4. Therefore, effectively, there are recommendations for techniques and measures for only three SILs in BS EN 50128 [67].

The safety-related software SIL and the tables of recommendations for measures and techniques to satisfy the requirements of BS EN 50128 do not impact the selection, use, or qualification of software tools used in the safety-related software development processes.

BS EN 50128 contains requirements and guidance for software tool selection, use, documentation, and qualification. BS EN 50128 also provides a comprehensive process for determining the confidence level in software tools used in the software development process similar to the tool qualification level used in the civil aviation industry. According to ISL [67], BS EN 50128 provides comprehensive, well-organized software tool requirements and guidance.

BS EN 50128 contains several requirements for software tools used in the safety-related software development life cycle process that only depend on the tool functionality. Tools are assigned to one of three classesT1, T2, or T3and the tool requirements vary by class.

6.22 In-House Developed Standards Companies such as Avanceon develop their own standards. According to Avanceon, its in-house developed standards ensure consistent product and project results, make it easier to support and maintain systems, and provide for more flexible and productive systems. If requested however, Avanceon can use specific industry standards. AutoGen' is an Avanceon software application designed to rapidly and dynamically configure standard PLC code, HMI objects, electrical drawings, and system documentation to meet the clients specific set of standards and process design [331].

16 The international version of EN 50128, which is identical to EN 50128, is IEC 62279.

6-44

7

SUMMARY

AND OBSERVATIONS The key issues related to EDDs are (1) sufficient rigor in their procurement and control, (2) identification of EDDs in procured equipment, (3) dedication needs for appropriate quality and reliability, and (4) management of potential software-related CCFs.

A review of vendor component specifications and performance along with personal communication with selected vendors provided insights into the process of component development (including EDDs), manufacturing, testing and change, and configuration management.

Specifically, 18 instrument applications investigated in this project include EDDs associated with commonly used pressure, level, flow, and temperature control instruments. The functionality of these devices should be representative of other I&C applications in NPPs that are outside the 18 component types reviewed.

An initial survey of other other sectors and international regulatory practices was also performed to support future detailed work in this project.

ORNL also determined the potential safety implicationsnew hazards, vulnerabilities, failure modes, and triggering mechanisms, and other potential safety concernsbased on the use of digital instrumentation and controls (I&C) systems and components in safety-related or important to safety applications at NPPs. ORNL then identified existing practices and solutions to address the safety implications from other industries or from international organizations.

An evaluation of those existing practices and solutions was performed in order to support future decisions regarding regulations and guidance by the NRC, in particular the application of a graded approach.

A summary from the evalaution is provided in the areas of terminology, EDD related issues, operating experience, and existing practices which the NRC could use to address the EDD related issues.

An overall set of observations follows, including some observations related to emerging technologies identified during the review and the evaluations.

7.1 Summary The installation of any EDD must be identified, reviewed, tested, controlled, and evaluated for the potential effects of hardware and software defects. Implementation of CGD, 10 CFR 21, and 10 CFR 50.59 processes, along with the NRC vendor inspection program, NUPIC (if five or more NUPIC members use their items and services) and NAIC evaluation of suppliers, and maintenance of the licensees approved suppliers (vendors) list, should provide assurance that only components of appropriate quality are in use. However, none of these processes identified the design modification of the Allen-Bradley timing relays.

Of importance to this project is the RIS 2016-05 [1] that was written to clarify NRCs technical position on existing regulatory requirements for the quality and reliability of safety-related equipment with EDDs. RIS 2016-05, which applies to equipment, instrumentation, and controls 7-1

that contain EDDs in safety-related systems, states that licensees should adequately address the following:

1. The quality and reliability of EDDs that exist in actuation equipment

2. The potential vulnerabilities to CCFs

3. Sufficient procurement planning and material control to identify, review, test, and control EDDs Other issues related to the use of EDDs in safety-related systems include the potential for undeclared digital content in the devices, the difficulty in obtaining information about a devices design and operating history, the use of software tools, accepting certifications (similar to dedication) from other entities, new cyber security concerns, and the possibility that a graded approach may be beneficial for approving the use of EDDs.

In addition to meeting performance requirements, EDDs in safety-related systems should be designed for a reliability level that is commensurate with the safety significance of the function(s) to be performed. Design attributes for achieving a given level of functional reliability and robustness include those related to quality, knowing if digital content is in the EDD, the use of software tools and their pedigree, cyber security vulnerabilities, redundancy, diversity, failure detection, periodic testing (including the use of self-diagnostic features and surveillance tests),

and failure data/failure modes. V&V should be included at appropriate stages of the design to confirm that the necessary safety functions have been identified and will operate as intended.

These issues, discussed below, can be used to guide regulatory judgements and recommendations when undertaking technical assessments of the use of EDDs in safety related applications. The supporting issues can be used to appropriately grade the review of the use of EDDs. In addition, the supporting issues can be used to guide assessments of proposed new nuclear facility designs.

7.1.1 Common Names Because of the different names and functionality of EDDs, it is important for licensees and the NRC to understand exactly what is being installed. This is because some smart instruments in industry include communication devices.

The U.S. NRC uses the term EDD but throughout industry, other regulators, and foreign uses of EDDs, the most common related term is smart device. Other related terminology includes devices of limited functionality, or intelligent devices. Industry also uses the term IoT that signifies the devices are connected to a larger system that provides monitoring and information from those devices.

The standards community uses a larger set of related device names for types of EDDs including EDD, simple device, intelligent device, smart device, digital device, digital device of limited functionality, (synonym for device of dedicated functionality), industrial digital device, and programmable digital device.

An important distinction made by the UKs ONR between smart devices and other computer-based systems is that the end user cannot modify or add device functionality in any way, although the user can usually perform limited configuration. Such devices are still consideredto be 7-2

computer-based systems, so their use in safety or safety-related applications should be justified according to the United Kingdoms Office of Nuclear Regulations SAP ESS.27.

7.1.2 EDD Related Issues The introduction of EDDs can create new hazards, vulnerabilities, failure modes, triggering mechanisms, and other potential safety concerns at both the component level and system level.

New vendors into the market may not be familiar with the quality requirements associated with the nuclear power industry. Other issues are the potential for undeclared digital content in the devices, the difficulty in obtaining information of the devices design and operating history, the use of software tools, accepting certifications (similar to dedication) from others, new cyber security concerns, and how a graded approach may be beneficial for approving the use of EDDs.

7.1.3 Operating Experience Operating experience, although frequently used to determine failure rates, may be more appropriately used for lessons learned. The dc inductive kick on a relay reported in March 2015 (6 years after the design change) was not an original issue and was recognized as a CCF as far back as 1991. The difference between 1991 and 2015 is that devices are switching from analog to digital and digital components are more susceptible to a dc inductive kick failure mechanism.

The review of operating experience for this report agreed with other reviews in that software errors can be CCFs that are likely the result from poorly defined, misunderstood, or not properly implemented requirements. Examples of both the undeclared digital content and the dc inductive kick failure mechanism highlighted in the review of operating experience are applicable to EDDs.

Some regulators, such as the military, do not address CCFs per se, but rely on safety assessments based on the consequences (hazards) of a failure.

An issue with operating experience is that software issues may be reported differently. For example, operational experience based on returns under warranty may not capture software issues that were resolved via a call to the company and a patch or change in configuration without the actual item needing to be returned. Similarly design errors that can be resolved via a patch, either to resolve a software issue or compensate for some other design fault using software, may be reported differently in any system based on the number of reported issues. Such updates allow for fixing devices in the field resulting in no further reports or returns for that issue, as opposed to a manufacturing defect that could not be so resolved. A partial solution to this issue could be a requirement to know and examination of the number of updates or patches that have occurred for the product. Larger numbers of patches may indicate issues with the production quality of the design process and software development lifecycle.

It is generally accepted that operating experience can be used to prove the suitability and reliability of components and can therefore be used to support the confirmation of the regulatory requirements for the use of the device. However, the large volume of operational experience from industrial applications may not be applicable, and thus misused, because of a lack of documentation, uncertainty in the version of the device used, process conditions, operating environment, service history, proper failure reporting and recording of data, and any modifications to the device. That is, the failure rates are not sufficiently refined to reflect the use of EDDs in different environments or conditions. The limited data from operational experience in the NPP industry makes the use of reliability claims difficult to defend, although the non-nuclear industry has extensive operating experience and vendors claim increased reliability.

7-3

7.1.4 Existing Practices Safety significance is a key characteristic of I&C systems at NPPs. Safety classification is one of the fundamental safety concepts used to ensure that NPPs pose minimal risk to public safety.

The classification of an SSC identifies the importance to safety for that SSC and the consequence of its failure. The classification of SSCs is closely related to the plant states and the postulated initiating events.

10 CFR 50 establishes a classification approach for SSCs in a nuclear facility. 10 CFR 50.2 defines safety-related SSCs in terms of reliance on those SSCs to remain functional during and after design basis events to assure (1) the integrity of the reactor coolant pressure boundary, (2) the capability to shut down the reactor and maintain a safe shutdown condition, and (3) the capability to prevent or mitigate the consequence of accidents that could result in unacceptable offsite exposures.

There are notable variations in safety classification internationally. The classification of safety systems between countries, organizations, and even within the same organization may have a common term, but the terms may have different meanings. Although the classification of safety systems for other countries may not align well with the NRCs safety/not safety classification, a review of these other classifications provided insights into how to provide a graded approach to the review of safety-related EDDs which led to the categories in section 4.10. Understanding the specifics of different classifications could support regulators leveraging portions of each others evaluations.

Another possible way to provide a graded approach would be to allow the use of IEC SIL certification used by industry and many regulators, both foreign and domestic, to support commercial graded dedication. Although this sounds simple, it would require much effort by the NRC to review and inspect the certification process, along with ensuring that any device meets the critical characteristics for its application.

7.1.5 Differences by Country A summary of the terminology and standards used when evaluating the use of EDDs in NPPs is provided in Table 7-1.

Table 7-1 Summary of Terminology and Standards by Country for Evaluating the Use of EDDs Country Terminology Standard Guidance/Guides United States Embedded digital devices (EDDs) Appendix B/CGD RIS 2016-05 [1]

RIS 2002-22 Supplement 1 [223]

Canada Smart devices CAN CSA-N290.14 CSA-N290.8 IEC 61508 (SIL)

IEC 61513 (safety class)

IEC 60880 IEC 62566 France Intelligent devices IEC 62671 (applicable to all)

Simple devices IEC 61508 (previously certified)

Digital device of limited functionality RCC-E 2016 7-4

Table 7-1 Summary of Terminology and Standards by Country for Evaluating the Use of EDDs (Continued)

Country Terminology Standard/Guidance/Guide Germany Digital device of limited functionality IEC 60880 (synonym for device of dedicated IEC 61508 functionality) IEC 61513 Industrial digital device IEC 62138 (based on IEC terminology) VDI/VDE 3528 India Smart devices ISO-9001 IEC 60880 IEEE Std. 603 [332]

IEEE Std. 7-4.3.2-2003 [263]

IEEE Std. 323 [158]

AERB SG-D-25 Japan Smart devices Japan does not currently have regulations specific to the use of smart devices; I&C systems important safety were built on the assumption of using only nuclear qualified products and are regulated using the same requirements.

Korea Smart devices KINS/GE-N001 SRP BTP 7-19 SRM on SECY-93-087 NUREG/CR-6303 IEEE Std. 603 [332]

IEEE Std. 7-4.3.2 [263]

EPRI NP-5652 [73]

EPRI TR-106439 [54]

Pakistan Smart devices IEEE Std. 1012 Romania Smart devices IEC 61511 EPRI 106439 ANSI/ISA-S75.13.01 Russian Smart devices ISO 9001 certified Federation Rostekhnadzor licensed UK Smart devices ONR SAPs ONR TAG-046 TGN 032 IEC 61508 BS EN 61513, 61226 7-5

Canada, Korea, and the United States refer to the IEEE standards as part of the basis for regulatory approval. IEEE Std. 603 and IEEE Std. 7-4.3.2 were most consistently identified as part of the basis.

India and Russia identified the use of IAEA safety standards related to their review of I&C. (The IEC standards are based on the IAEA standards.) In Russia, IAEA Safety Guide No. NS-G-1.3 and IAEA Draft Safety Guide DS-431 provide part of the technical basis for granting regulatory authorization in several technical topics. Also, in India, IAEA standards or other acceptable codes are used to review specific areas for which AERB documents have not been prepared.

Commonly used consensus standards are the IEC standards identified by Canada, France, and Russia as part of the technical basis for granting regulatory approval. The most commonly identified IEC standards were IEC 60880, IEC 61513, and IEC 62138.

France recognizes that certifications by themselves cannot be used as a basis for approval licensees are responsible for what is installed in their plant [176]. The United Kingdom uses IEC 61508 and Adelards EMPHASIS tool, despite a reputable body being required for IEC SIL certifications above SIL 1.

In its guidance on COTs smart devices in ONR TAG-046 Revision 5, compensating activities (compensating measures) are allowed to make up for the gaps in production excellence information. No attempt is made to define the compensating activities (compensatory measures),

as these would be determined on a case by case basis. TAG-046 indicates that there is no comprehensive guidance on the selection of independent confidence building measures for smart devices, beyond the details within the TAG itself. Some duty-holders have developed their own processes for justification of smart devices with ONR, however these are proprietay.

The UK and Canadian approaches to digital devices make for an interesting case study comparison. Both countries do not have a requirement for vendors to produce equipment in compliance with a nuclear-specific QA program such as 10 CFR 50 App B or ASME NQA-1, and they also do not include a 10 CFR 21 requirement that vendors must agree to comply with. As a result, both countries do not use the process commonly known as CGD. Both countries highly value the principles of IEC 61508 and implement a structured, graded approach using the defined SILs in conjunction with the classes and categories of IEC 61226. Despite these similarities, these countries have polar opposite perspectives on the value of third-party certifications. The CNSC is willing to rely heavily on these certifications, but the ONR has a significant skepticism of them. The ONR requires the certification process to be repeated through their EMPHASIS tool before having confidence in the digital device being suitable for the nuclear safety application.

7.1.6 Standards / Guidance Outside of the nuclear industry, vendors typically use recognized and generally accepted good engineering practice. If the regulatory agencies in other industries or countries identify a standard for systems/components, they typically cite an IEC standard. In many cases, this leads to the use of IEC 61511/IEC 61508. That is, the supply chain and structures for non-nuclear safety related industries use IEC-61508/61511. Many use the same IEC standards but adopt them under a different number. For example, the international version of EN 50128 is IEC 62279, which is identical to EN 50128. Canada adopted IEC 61508 under the number of CSA 61508. Similarly, IEC 61511 is ANSI/ISA 84.00.01. However, IEC 62671 appropriately states that IEC 61508 can be used as complementary guidance for the evaluation and assessment of components [for use in 7-6

the nuclear industry], but it is recognized that certification to non-nuclear standards alone is insufficient.

Many regulations and standards in use outside the U.S. nuclear industry are based on IEC SILs.

Efforts are underway to change that in the United States. The purpose of NEI 17-06 [308] is to provide an acceptable approach for procuring and accepting commercial grade digital equipment that have an IEC SIL certification by an accredited third party SIL certification body for nuclear safety-related applications. The objective of EPRI 3002011817 [276] is to demonstrate that equipment certified to non-nuclear safety standards (more specifically, IEC-61508/61511) can meet or exceed nuclear power reliability requirements without further analysis or verification.

EPRI 3002011816 [154] states that IEC SIL certification to IEC 61508 may provide evidence of product or platform suitability. If SIL certification is used as a method for demonstrating product or platform suitability, then the restrictions or conditions specified in the safety manual shall be integrated with related activities. Acceptance of components approved under IEC SIL certification to support the CGD process would require a proper review of IEC 61508, ensuring measures are in place so that only components that are used meet the form, fit, and function for its approved, and an inspection of the certification process and certification bodies.

Prior to acceptance, some deficiencies in the use of IEC SIL certifications have been expressed.

More specifically, Summers notes that under IEC 61508 requirements, a product with a high total failure rate can achieve a high SIL claim limit as long as its failure is detected and annunciated

[120]. This means that a device can have a high SFF and be highly unreliable. Possessing a high SFF does not necessarily mean that the device performance is adequate for safe service.

Summers notes that the SFF is not penalized by the choice to alarm rather than achieving the safe state. Therefore, the more failures that are detected, the higher the SFF becomes, regardless of the number of times, or the total amount of time, that the device is in the failed state, essentially dumping responsibility for process protection back on the operator. This approach would maximize the reliance on diagnostics and minimize the quality standards of the components. Summers also notes that Following a careful review of a significant variety of product safety manuals, it appears that many field devices are achieving higher safety integrity level (SIL) claims than can be supported by process industry data [123].

An alternative type of certification is that performed by Adelard. This method is accepted by the United Kingdom. That is, ONR has approved the use of EMPHASIS for dedicating components.

It may be possible to leverage the ONR/EMPHASIS review for use in the United States.

Much of the guidance on EDDs and smart devices treat the devices as systems. For example, the U.S. requirements and guidance used to review the use of EDDs refer to safety systems.

Guidance used by other regulators also review the devices like a system. Part of this is because the device is in a system. IEC 61511 defines component as one of the parts of a system, SIS subsystem, or device performing a specified function and states that a component may also include software. The components make up the system architecture. An impact analysis would be used to determine the effect that a change to a function or component will have to other functions or components in the system as well as in other systems.

The approach of the IEEE SIL and IEC SIL are similar in that the requirements for meeting the standard increase as the SIL level increases. However, the IEC SILs directly relate to safety goals, whereas the IEEE SIL indirectly relate to safety through the presumption that high software integrity or quality will result in improved safety assurance. It seems clear that, given the extensive international use of IEC SIL certification in non-nuclear industries and the directly treatment of the primary objective of safety, the IEC SIL classification would form a very suitable 7-7

basis for characterizing the reliability/dependability, and thus the associated evidentiary requirements for the reliability/dependability, of EDDs.

The international standards allow more of a risk-based approach compared to the United States by qualitatively assessing the risks of hazardous operational situations. The V&V of the software tools is based on a graded approach and whether the software tool can or cannot introduce faults into the software or whether it can fail to make the user aware of existing faults.

Overall, the international standards appear to cover the same concerns as NRCs guidance and endorsed standards. For example, both use SILs for developing software, although the SILs are not a one-for-one match. Both recognize that software tools may be used and, depending on the standard development organization (either domestic or international), guidance differs on the acceptance of the software tools; however, domestic and international standards recognize the importance of the development process. In addition, the evaluation/acceptance process and supply chain are important topics in both international and domestic standards. The value of endorsing international standards is that vendors would not be required to design to different criteria and go through two evaluation/acceptance processes.

The software in an EDD may be developed using software tools or manually written. Vendors that were contacted indicated that they will manually write the code for the EDD but will use software tools if requested by the customer. If they manually write the software code for an EDD that can be used in a safety application it is written following an approved Appendix B program. With respect to software tools, some regulators assess software tools similar to support system software that is part of the system software in a typical I&C system and is either off-line or on-line (i.e., embedded in nonsafety support systems). Software tools may not need to be developed under an Appendix B program nor dedicated if V&V activities can detect defects not detected by or introduced by the software tool. Regulatory guidance is not consistant when that cannot be demonstrated. IEEE 7-4.3.2 2003 describes a test tool validation program or using tool operation experience and Regulatory Guide 1.152 and ISG-06 do not seem to contradict this; however BTP 7-14 and SRP Appendix 7.1-D clearly indicate that if such verification cannot be demonstrated the tool itself should be developed or dedicated as safety-related, with all the attendant requirements. Thus, insights into the V&V of the outputs of software tools may be needed to support future uses of software tools, particularlily commercial tools.

Countries and regulators are not the only organizations with terminology differences. Table 7-2 shows that the standards in use for providing guidance to designing I&C systems (and used for EDDs) typically use the terminology simple or smart device but many other names are also used.

7-8

Table 7-2 Summary of Terminology Used in Guidance/Standards Documents Organization Terminology Guidance/Standard/Guide AFCEN Simple

• RCC E 2016 (French Society Smart device

• IEC 60880 for Design and Digital device

• IEC 62138 Construction rules Digital device of limited functionality

• IEC 62566 for Nuclear Island

• IEC 62671 Components )

• IEC 60987 EPRI Smart devices EPRI TR-106439 Embedded digital device EPRI TR-107339 EPRI 3002008010 IAEA Smart devices Addressing Safety of Smart Embedded digital devices Devices for Use in Nuclear Power Industrial digital device Plants (first ever IAEA safety report on the subject, to be published later in CY2020)

IAEA Nuclear Energy Series No.

NP-T-X.XX, V2.25 (number to be determined)

IAEA Nuclear Energy Series No.

NP-T-1.13 IAEA Safety Standards Series No.

SSG-39 IEC Digital device of limited functionality IEC 62671 (synonym for device of dedicated IEC 61508 functionality)

Industrial digital device IEEE Smart devices ONR SAPs Programmable digital device ONR TAG-046 TGN 032 IEC 61508 BS EN 61513, 61226 ISA Smart devices ANSI/ISA-84.00.01-2004 intelligent devices (IEC 61511 Mod)

ISA-TR108.1-2015 NEA Digital device of limited functionality MDEP DICWG-07 Programmable digital device NEA/CNRA/R(2014)7 7-9

7.2 Observations Functionality/Terminology The majority of EDDs in current use in the U.S. NPPs are stand-alone devices without communication connectivity beyond what may have been used in analog devices with a diagnostic output, such as being connected to other devices or in a system type architecture.

EDD usage in NPPs around the world is similar to that in U.S. NPPs. Within the nuclear industry, EDDs are of limited functionality and are typically referred to as EDDs, smart devices, or devices of limited functionality. This is much different than EDD use in other industries. In fact, it is from other industries that EDDs have many different names and functions and it is expected that the increased functionality of EDDs in other industries will migrate to the nuclear industry.

Supply Chain and CGD related challenges The ORNL review of the supply chainfront, middle, and back ends for EDDdid not identify gaps should a licensee and vendor follow the requirements and guidance as appropriate. This includes everything from secure development environments to purchase to integration at the plant. Many of these vendors that supply EDDs to NPPs are vertically integrated, or they specify the components to be used for the EDDs and are familiar with NRC regulations and guidance.

NRC inspections of the CGD facilities provide assurance of the processes being followed.

Devices manufactured in a different time frame would not be considered identical per the guidance in IP 43004. An equivalency evaluation could include steps to ensure an EDD has not been added to a device that previously did not have one, or that a known EDD has not undergone a change.

Documentation shortcomings vary depending on manufacturer and when the product was developed. It is challenging to perform CGD without support from the supplier, including access to product information, company site visits, and discussions. Moreover, determining how much of the code to analyze can be challenging. Adelard recommends using flow graphs to reveal the internal structure of the code to find out exactly what code governs the main function of the smart sensor. From there, the assessor may concentrate only on the variables accessed from this critical code. Development of other approaches can be beneficial (i.e. other plugins, black-box techniques, assembly code analysis, architecture/system-level mitigations based on hazard analysis). However, determining how many techniques to use and how to combine them effectively can be troublesome, as well. The ONR SAPs and TAGs are goal-setting principles and guidelines, but they do not define what exactly needs to be done for device justification. There is a list of tools, approaches, and techniques known to the industry, but they are not technology independent, and not all are applicable to all devices.

Safety demonstrations of COTS products can be challenging. Products may be sold as a black-box, safety demonstrations may require the suppliers intellectual property, available guidance documents may be unclear, and known analysis techniques may not be suitable. Moreover, the nuclear industry is a relatively small customer and does not have much leverage with manufacturers.

7-10

A standards-based approach to EDD justification does not necessarily provide evidence that the I&C system and its software achieve the performance required at the desired level of reliability.

One of the projects funded by the CINIF is entitled COTS Goal-based Safety Assessment (COGS) and is aimed at developing an approach to the safety justification of COTS products like devices dedicated to a single function, user-programmable and control equipment, or certain software-only products such as OSs. COGS is a claim-based approach, which uses the Claims-Arguments-Evidence (CAE) framework. A claim-based approach allows greater flexibility in making a justification while ensuring that all safety relevant attributes of the COTS product are justified. COGS is generally applicable to several types of products and is designed to demonstrate that the behavior and functionality of the product is sufficient for its intended application and that the products will behave accordingly throughout its design lifetime. Such an approach could provide some grading of the review of EDDs.

Operating and International Experience Recent events show that operating experience can provide lessons learned (such as undeclared digital content or dc inductive kick failure mechanism) that can be used to provide additional guidance such as how to determine if a device has undeclared digital content to specifying in procurement documents the presence of such a device.

International experience with vendors is similar to that in the United States: manufacturers data sheets may not state if microprocessors were used. O&M manuals may not go to the level of detail on component parts necessary for review, and visual examination often proved inconclusive.

Instruments purchased just two years before now had microprocessors and purchasing an identical instrument with exactly the same part number would deliver an identical smart instrument.

Emerging Technology In the future, if EDDs with communication capabilities are integrated into a safety system, the EDDs would need to consider independence between safety systems and other portions of a safety system, other systems, and the effects of design basis events, as required by Clause 5.6 in IEEE Std. 603. Care will need to be taken to ensure these requirements are not challenged in a particular implementation of an EDD as it may create new dependencies or make existing ones more significant.

As noted in Section 4.9.1, issues have been identified with the use of FMEAs with high complexity devices or within interacting systems. As EDDs are expected to increase in complexity and connectivity the use of FMEA to adequately address creating the critical characteristics needed for dedication becomes questionable. Modern methods and tools designed to deal with more complex and connected systems may be needed for such EDDs.

Licensing Review Guidance The ORNL review found that while following all guidance for systems and the process regulatory guidance in support of Appendix B Quality Assurance should be sufficient, it may not be necessary. Graded approaches and commercial grade dedication could therefore improve the effeciancy of EDD reviews.

In reviewing EDDs, system level concerns for EDDs with increased functionality are reviewed to the extent that they impact the FSAR in existing plants or the areas of review in a new design as 7-11

appropriate. This will vary depending particularly on any communication features added. The issue of quality then remains. Addressing quality using 10 CFR 50 Appendix B and associated regulatory guidance documents related to quality should be sufficient for EDDs, but that may entail more effort than is necessary as these guidance documents were developed to support systems that may be more complex and involve more application specific code and customization than a particular EDD. Approval under CGD hinges on the ability to properly identify critical characteristics and then verify them. Currently this relies heavily on an understanding of the failure modes and FMEA especially in the absence of design documentation, therefore the controversies associated with the use of FMEA on digital systems as described in this report and leveraging different types of FMEA or other techniques for performing hazards assessments along with modern means of V&V could be a path forward in being able to resolve issues with future EDDs with more functionality and complexity.

The approach to smart devices in ONR guidance and ISG-06 both describe the use of measures (called compensatory in ISG-06 and compensating in ONR Nuclear Safety Technical Assessment Guide 046 Revision 5) given shortcomings in demonstrating the adequacy of the rigor of the development and production process. Neither gives particularly specific guidance on the nature of these measures. It may be possible to provide additional guidance to industry in a harmonized manner.

ISG-06 Revision 2 already has consideration of integrated design environmental tools stating: It is acceptable for a licensee to adapt test documentation to reflect important process differences, technology differences, and exceptions related to the use of integrated design environment tools. However, utilizing this flexibility may be challenging for model based engineering approaches or tools that do not produce outputs that can easily be put on the docket in any form.

Tests to indicate the presence of a digital device could be developed and instituted either at the vendor or plant. For example, EMC testing may indicate the presence of an EDD due to many EDDs having a vulnerability to EMI/RFI or high energy radiation or the signature on an oscilloscope may differ once a digital device is installed.

7-12

8 REFERENCES

1. RIS 2016-05, Embedded Digital Devices in Safety-Related Systems, April 29, 2016.

(ADAMS Accession No. ML15118A015)

2. S. A. Arndt, Embedded Digital Devices NRC Perspective, Workshop on Qualification of Embedded Digital Devices Bethesda North Marriott Hotel, North Bethesda, MD, March 11, 2016.3.

3. Allen-Bradley Bulletin 700 -P, -R, -RTC, NEMA Industrial Relays.

https://ab.rockwellautomation.com/Relays-and-Timers/700-RTC-NEMA-Solid-State-Timing-Relays#documentation

4. Emerson Process Management (2020), FIELDVUEW DVC6200 Series Digital Valve Controller, https://www.emerson.com/documents/automation/product-bulletin-fieldvue-dvc6200-digital-valve-controller-en-123336.pdf

5. B. Fitzgerald, M. Cheng-Newson, and F. Mercaldi, Pickering Exploits Digital Valve Technology , Nuclear Engineering International, July 2015.

6. Editors R. de Lemos, C. Gacek, and A. Romanovsky, Architecting Dependable Systems IV, H. Sozer, B. Tekinerdogan, and M. Aksit, Extending Failure Modes and Effects Analysis Approach for Reliability Analysis at the Software Architecture Design Level, Pages 409-433, Springer-Verlag Berlin Heidelberg 2007.

7. IAEA Nuclear Energy Series No. NR-T-3.31, Challenges and Approaches for Selecting, Assessing and Qualifying Commercial Industrial Digital Instrumentation and Control Equipment for Use in Nuclear Power Plant Applications, International Atomic Energy Agency, Vienna, 2020

8. R. Selega, Smart Industry & Safety Instrumented Systems, Chemical Processing, Feb 21, 2018. https://www.controlglobal.com/articles/2018/smart-industry-and-safety-instrumented-systems

9. K. McKay, OPG Canada, Use of Smart Devices in Safety Related Computers, COTS Digital Devices in Safety Critical Industries, Use and Licensing, Report 2019:627, Stockholm on 22 October 2019..

10. T. S. Nobes, Smart Instruments in Safety Instrumented systemsSellafield Experiences.

Measurement + Control, Vol 41/6, July 2008.

https://journals.sagepub.com/doi/pdf/10.1177/002029400804100603

11. S. Kuball, Experience with Justification of Smart Devices in EDF NG UK and issues for consideration, IAEA Technical Meeting on Smart Devices, Vienna, 17-21 February 2020.

12. Kim, Y. M., Lee, H. K., & Park, H. S., Regulatory Experience of the Embedded Digital Devices for Safety I and C Systems on NPPs, Proceedings of the KNS 2016 Autumn Meeting, (pp. 1CD-ROM). Korea, Republic of: KNS, 2016.

8-1

13. International Society of Automation, Intelligent Device ManagementPart 1: Concepts and Terminology, ISA-TR108.1-2015, Research Triangle Park, North Carolina, June 16, 2015.

14. E. Overling, DDLF Qualification France, RCCE 2002-2012-2016, EDF, March 2019.

15. Multi-National Design Evaluation Programme Digital Instrumentation and Controls Working Group, Common Position on Selection and use of Industrial Digital Devices of Limited Functionality, MDEP Common Position CP-DICWG-07, Version 3, 09 July 2014.16. IAEA Safety Standards Series No. SSG-39, Design of Instrumentation and Control Systems for Nuclear Power Plants Specific Safety Guide, International Atomic Energy Agency, Vienna, 2016.

16. IAEA Safety Standards Series No. SSG-39, Design of Instrumentation and Control Systems for Nuclear Power Plants Specific Safety Guide, International Atomic Energy Agency, Vienna, 2016.

17. International Electrotechnical Commission, Nuclear Power Plants - Instrumentation and control important to safety - Selection and use of industrial digital devices of limited functionality, IEC 62671 Ed. 1, Geneva, Switzerland, 2009-01-09.

18. EPRI 1002833, Final Report, Guideline on Licensing Digital Upgrades: EPRI TR-102348, Revision 1, NEI 01-01: A Revision of EPRI TR-102348 to Reflect Changes to the 10 CFR 50.59 Rule, Electric Power Research Institute, EPRI, Palo Alto, CA, March 2002.

(ML020860169)

19. Watanabe Nobumichi, Considerations on Applying the Smart Devices, Technical Meeting on Safety Aspects of Using Smart Digital Devices in Nuclear Systems, IAEA Headquarters Vienna, Austria, 17 to 21 February 2020.

20. M. Rouse, DEFINITION embedded system, https://internetofthingsagenda.techtarget.com/definition/embedded-system

21. Global Embedded System Market: Snapshot, Transparency Market Research.

https://www.transparencymarketresearch.com/embedded-system.html

22. M. Rouse, embedded system.

https://internetofthingsagenda.techtarget.com/definition/embedded-system

23. IIoT: Combining the Best of OT and IT, Industrial Ethernet Book Issue 95 / 14.

https://iebmedia.com/index.php?id=11673&parentid=63&themeid=255&hft=95&showdetail

=true&bb=1

24. E. Dean, When worlds collide: Understanding emerging IT/OT convergence. 10 Sep 2018.

https://internetofthingsagenda.techtarget.com/blog/IoT-Agenda/When-worlds-collide-Understanding-emerging-IT-OT-convergence

25. B. Slusser, Industry 4.0 is here - are you ready?, March 16, 2018.

https://avanceon.com/author/writer_30/

26. IEEE Std. 7-4.3.2-2016, IEEE Standard Criteria for Programmable Digital Devices in Safety Systems of Nuclear Power Generating Stations, Institute of Electrical and Electronics Engineers, Piscataway, NJ, 29 January 2016.

8-2

27. PumpSmart - ITT Pro Services [Online]. Available:

https://www.ittproservices.com/ittgp/medialibrary/ITTPROServices/website/Literature/Broc hures/PRO%20Services/PSmartbulletin.pdf?ext=.pdf. [Accessed: Jan. 10, 2019].

28. Smart technology for your oven and stove [Online]. Available:

https://www.lifewire.com/smart-oven-range-4159902. [Accessed: Jan. 10, 2019].

29. L. Blain, World's first fully digital valves open up engine possibilities, New Atlas, August 11, 2018. https://newatlas.com/camcon-digital-iva-valve-system/55827/

30. T. Prestifilippo, FIELDVUEW DVC6200 Series Digital Valve Controller, A Single Instrument Solution Across Your Facility. http://omeas.com/wp-content/uploads/2018/08/Product-catalog-Fisher-DVC6200.pdf

31. E. Saopraseuth, N. Wienhold, E. Butler, S. Guerra, and H. Khlaaf, Emphasis Class 1 And Class 2 Assessment of Rosemount Pressure and Temperature Transmitters.

https://www.adelard.com/assets/files/docs/pp11v30_npic2019_Rosemount.pdf

32. T. Nobes, Smart Instruments in Safety Instrumented Systems - Sellafield Experiences, Measurement and Control, Volume 41, Issue 6, July 2008 https://journals.sagepub.com/doi/pdf/10.1177/002029400804100603

33. T. Jacobi, D. Floyd, R. Wood, A. Hashemian, H.M. Hashemian, and B. Shumaker.

Investigation of Instrumentation Containing an Embedded Digital Device, NPIC-HMIT 2017.

34. EPRI TR-1001503, Identification and Description of Instrumentation, Control, Safety, and Information Systems and Components Implemented in NPPs, Electric Power Research Institute, Palo Alto, CA, June 2001.

35. R. T. Wood, R. A. Joseph III, K. Korsah, M. D. Muhlheim, and J. A. Mullens, LTR/NRC/RES/2012-001, Classification Approach for Digital I&C Systems at NPPs, February 2012. (ADAMS Accession No. ML120970232)

36. R. T. Wood, et. al., Emerging Technologies in Instrumentation and Controls, NUREG/CR-6812 (ORNL/TM-2003/22), March 2003. (ADAMS Accession No. ML031900433)37. Greg Kaser, The World Nuclear Supply Chain - An Overview, World Nuclear Association, NEA International WPNE Workshop, Paris, 11 March 2014.

37. Greg Kaser, The World Nuclear Supply Chain - An Overview, World Nuclear Association, NEA International WPNE Workshop, Paris, 11 March 2014.

38. H. M. Hashemian, Nuclear Power Plant Instrumentation and Control, Nuclear Power -

Control, Reliability and Human Factors, Pavel Tsvetkov, IntechOpen, DOI: 10.5772/18768, September 26th 2011. Available from: https://www.intechopen.com/books/nuclear-power-control-reliability-and-human-factors/nuclear-power-plant-instrumentation-and-control

39. Nuclear News, 23rd Annual Vendor/Contractor Profile Issue, August 2017.

40. Nuclear Utility Obsolescence Group (NUOG), vendor links.

http://www.nuog.org/NUOG_Vendor_Links.html

41. Nuclear Suppliers Association (NSA). http://www.nuclearsuppliers.org/

8-3

42. Nuclear Plant Journal, Browse By Product, 2020.

http://www.nuclearplantjournal.com/index.php?option=com_content&view=article&id=125&

Itemid=149

43. Nuclear Plant Journal, Browse by Company, 2020.

http://www.nuclearplantjournal.com/index.php?option=com_content&view=article&id=130&It emid=150

44. Nuclear Engineering International, Company A-Z.

http://www.neimagazine.com/contractors/indexAtoZ.html

45. Nuclear Procurement Issues Corporation (NUPIC).

https://nupic.com/NUPIC/Home/Home.aspx

46. World Nuclear Association. http://www.world-nuclear.org/our-association.aspx

47. Nuclear Engineering Enabling Technologies (NEET) Workshop on Qualification of Embedded Digital Devices, Bethesda North Marriott Hotel, North Bethesda, MD, March 11, 2016.

48. R. Wood, Addressing Embedded Digital Devices in Diversity and Defense in Depth Analyses, IAEA Technical Meeting on Safety Aspects of Using Smart Digital Devices in Nuclear Systems Important to the Safety of Nuclear Power Plants, Vienna, 17-21 February 2020.

49. Advisory Committee on Reactor Safeguards Plant Operations and Fire Protection Subcommittee Meeting Minutes, Atlanta, GA, July 28, 2016. (ADAMS Accession No. ML16243A457)

50. T. S. Nobes, Smart Instruments in Safety Instrumented Systems - Sellafield Experiences, Measurement + Control Vol 41/6 July 2008.

51. H. Sozer, B. Tekinerdogan, and M. Aksit, Extending Failure Modes and Effects Analysis Approach for Reliability Analysis at the Software Architecture Design Level, Department of Computer Science, University of Twente, P.O. Box 217 7500 AE Enschede, The Netherlands, 2007.

52. K. Kavanagh, NRCs Vendor Inspection & Quality Assurance Update, 3rd Workshop on Vendor Oversight for New Reactor Construction, June 21, 2012. (ADAMS Accession No. ML12171A243)

53. EPRI 3002002982, Plant Engineering: Guideline for the Acceptance of Commercial-Grade Items in Nuclear Safety-Related Applications, Revision 1 to EPRI NP-5652 and TR-102260, Electric Power Research Institute, Palo Alto, CA, September 2014.

54. EPRI TR-106439, Guideline on Evaluation and Acceptance of Commercial Grade Digital Equipment for Nuclear Safety Applications, Electric Power Research Institute, Palo Alto, CA, October 1996.

55. 10 CFR 21.21 Notification of failure to comply or existence of a defect and its evaluation.

56. Doug VanTassell, Commercial Grade Dedication Challenges, NRC Workshop, June 14, 2018. (ADAMS Accession No. ML18150A373) 8-4

57. EPRI 3002008010, Guideline on Prevention and Detection of Undeclared Digital Content, Electric Power Research Institute, Palo Alto, CA, 2016.

58. Curtiss Wright Nuclear Division, Undeclared Digital Content, 24, 2020. (ADAMS Accession No. ML21076A003)

59. U.S. NRC Information Notice 2014-11, Recent Issues Related to the Qualification and Commercial Grade Dedication of Safety-Related Components, September 19, 2014.

(ADAMS Accession No. ML14149A520)

60. Nutherm International, Inc,

Subject:

Report of Potential 10CFR Part 21, Allen Bradley Time Relay Model 700RTC, June 4, 2015. (ADAMS Accession No. ML17311A903)

61. U.S. NRC Information Notice 2016-01: Recent Issues Related to the Commercial Grade Dedication of Allen Bradley 700-RTC Relays, February 17, 2016. (ADAMS Accession No. ML15295A173)

62. Brunswick Steam Electric Plant (BSEP), Unit 1, 5000325, Licensee Event Report 2015-002-1, Emergency Diesel Generator Loss of Safety Function, November 16, 2015.

(ADAMS Accession No. ML15329A374)

63. Bhavesh Patel, Duke Energy, Allen Bradley 700-RTC Relay Part 21 Issues, NRC Regulatory Information Conference, March 2016.

64. Part 21 Report No: P21-04302015, Rev. 3, Update: Report of potential 10 CFR Part 21, Allen Bradley Timing Relay Model 700RTC, AZZ/NLI, August 15, 2016. (ADAMS Accession No. ML16238A186)

65. United Controls International,

Subject:

Report of Potential Part 21 on Allen Bradley Time Delay Relay 700-RTC-11200U1, July 20, 2015. (ADAMS Accession No. ML15205A293)

66. U.S. NRC, Safety Evaluation by the Office of Nuclear Reactor Regulation Related to Amendment No. 273 to Renewed Facility Operating License No. DPR-50 Exelon Generation Company, LLC, Three Mile Island Nuclear Station, Unit 1 Docket No. 50-289, May 27, 2010.

(ADAMS Accession No. ML092740791)

67. J. Servatius, S. Alexander, and T. Gitnick, Evaluation of Guidance for Tools Used to Develop Safety-Related Digital Instrumentation and Control Software for NPPs, Task 2 Report: Analysis of the State of Practice, ISL-ESRD-TR-14-03, August 2014. (ADAMS Accession No. ML15043A206)

68. U.S. NRC I&C-ISG-06, Revision 1, Digital Instrumentation and Controls Licensing Process, January 19, 2011. (ADAMS Accession No. ML110140103)

69. U.S. NRC I&C-ISG-06, Revision 2, Digital Instrumentation and Controls Licensing Process, December 2018. (ADAMS Accession No. ML18269A259)

70. National Aeronautics and Space Administration, NASA Software Safety Guidebook. NASA-GB-1740.13.71. Radio Technical Commission for Aeronautics (RTCA), Software Tool Qualification Considerations, DO-330, December 2011.

71. RTCA/DO-330, Software Tool Qualification Considerations, December 2011.

8-5

72. International Organization for Standardization (ISO), "Road vehicles - Functional safety,"

ISO 26262-1:2018, 2018.73. EPRI NP 5652, Guideline for the Utilization of Commercial Grade Items in Nuclear Safety Related Applications (NCIG-07), June 1988.

73. EPRI NP 5652, Guideline for the Utilization of Commercial Grade Items in Nuclear Safety Related Applications (NCIG-07), June 1988.

74. EPRI TR-102260, Supplemental Guidance for the Application of EPRI Report NP-5652 on the Utilization of Commercial Grade Items, Electric Power Research Institute, Palo Alto, CA, March 1994.

75. International Electrotechnical Commission, Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 2: Requirements for electrical/electronic/programmable electronic safety-related systems, IEC 61508-2, Geneva, Switzerland, 2010-04.

76. International Society of Automation (ISA), Functional Safety: Safety Instrumented Systems for the Process Industry Sector - Part 1: Framework, Definitions, System, Hardware and Software Requirements, ANSI/ISA 84.00.01-2004, Part 1 (IEC 61511-1 Mod), Research Triangle Park, North Carolina, September 2004.77. EPRI TR-107339, Evaluating Commercial Digital Equipment for High Integrity Applications, Electric Power Research Institute, Palo Alto, CA, December 1997.

77. EPRI TR-107339, Evaluating Commercial Digital Equipment for High Integrity Applications, December 1997.

78. EPRI TR-1011710, Handbook for Evaluating Critical Digital Equipment and Systems, Electric Power Research Institute, Palo Alto, CA, November 2005.

79. International Electrotechnical Commission, Nuclear Power PlantsInstrumentation and Control for Systems Important to SafetyGeneral Requirements for Systems, IEC 61513, Geneva, Switzerland, March 2001.

80. International Electrotechnical Commission, Computer hardware, IEC 60987, Geneva, Switzerland, 2013.

81. International Electrotechnical Commission, Nuclear power plants - Instrumentation and control systems important to safety - Software aspects for computer based systems performing category A functions, IEC 60880:2006, Geneva, Switzerland, 2006.

82. International Electrotechnical Commission, NPPs - Instrumentation and Control Important for Safety - Software Aspects for Computer-Based Systems Performing Category B or C Functions, IEC 62138, First Edition, Geneva, Switzerland, January 2004.

83. U.S. Department of Defense, Standard Practice for System Safety, MIL-STD-882E, 11 May 2012.

84. U.S. Department of Defense, Joint Software Systems Safety Engineering Handbook, Version 1.0 Published August 27, 2010.

8-6

85. G. Johnson, Nuclear use of I&C Equipment Certified for Commercial Safety Use, Presented at Opportunities and Challenges for Water Cooled Reactors in the 21st Century Vienna, 2009 October 27 -29.

86. 10 CFR 73.54, Protection of Digital Computer and Communication Systems and Networks.

87. Nuclear Energy Institute, Cyber Security Plan for Nuclear Power Reactors, NEI 08-09, Rev. 6, April 2010. (ADAMS Accession No. ML101180437)

88. EPRI 3002012753, Technical Report, Revision 2, Cyber Security in the Supply Chain, Cyber Security Procurement Methodology, Electric Power Research Institute, Palo Alto, CA, October 2018.

89. Nuclear Energy Institute, Identifying Systems and Assets Subject to the Cyber Security Rule, NEI 10-04, Revision 2, July 2012. (ADAMS Accession No. ML12180A081)

90. Nuclear Energy Institute, Cyber Security Control Assessments, NEI 13-10, Rev. 5, February 2017. (ADAMS Accession No. ML17046A658)

91. North American Electric Reliability Corporation (NERC), Order Approving Revised Reliability Standards For Critical Infrastructure Protection And Requiring Compliance Filing, Cyber Security Standards CIP-002 to CIP-009, September 30, 2009.

https://www.nerc.com/FilingsOrders/us/FERCOrdersRules/OrderApproving_V2_CIP-002_CIP-009-09302009.pdf#search=Cyber%20Security%20Standards%20CIP%2D002

92. IEEE Std. 1686-2013, IEEE Standard for Intelligent Electronic Devices Cyber Security Capabilities, Institute of Electrical and Electronics Engineers, Piscataway, NJ, Approved December 11, 2013.

93. Vendor Expectations from a Cyber Security Perspective, https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjppv OrxrTrAhVLhuAKHYTJBSYQFjAAegQIAxAB&url=https%3A%2F%2Fnupic.com%2FNUPIC

%2FGetFile.aspx%3FID%3D74%26tbl%3DHOME_HOT_TOPICS_DOCS%26idFN%3Did%

26fileFN%3Dfile_name&usg=AOvVaw0Ns2UnavVZinm5fortREzZ [Accessed: September 6th, 2020].

94. CSA Group, Qualification of digital hardware and software for use in instrumentation and control applications for nuclear power plants, CSA N290.14-15, November 2015.

95. D. Alberico et. al., Software System Safety Handbook, Joint Software System Safety Committee, Joint Services Computer Resources Management Group, U.S. Navy, U.S.

Army, and the U.S. Air Force, December 1999.

96. U.S. NRC, Frequently Asked Questions About Digital I&C. (ADAMS Accession No. ML063620169) https://www.nrc.gov/docs/ML0636/ML063620169.pdf

97. Mike Cain, ACRS Briefing: Brunswick NPP Emergency Diesel Generator Commercial Grade Dedication Finding, July 28, 2016. (ADAMS Accession No. ML16210A515) 8-7

98. Shearon Harris Nuclear Power Plant, Unit 1, Both Emergency Load Sequencers Subject To Common Mode Failure Due To Improper Application Of Relays Not Accounting For Dc Inductive Load Rating, LER 90-015, June 25, 1990. (ADAMS Accession No. ML18009A580)

99. U.S. Nuclear Regulatory Commission (NRC), "Common-Cause Failures Due to Inadequate Design and Control Dedication," NRC Information Notice No. 94-20, Washington, D.C.,

1994. (ADAMS Accession No. ML031060589) 100. Waterford Steam Electric Station, LER 382/17-002 - Automatic Reactor Scram due to the Failure of Fast Bus Transfer Relays to Automatically Transfer Station Loads to Off-Site Power on a Main Generator Trip, September 18, 2017. (NRC ADAMS Accession No. ML17261B215) 101. Shearon Harris NPP - NRC Integrated Inspection Report 05000400/2013002, April 30, 2013. (ADAMS Accession No. ML13120A340) 102. EGM 14-002, Enforcement Guidance Memorandum 14-002, Dispositioning Westinghouse Pressurized Water Reactor Licensee Noncompliance With 10 CFR 50.59, Changes, Tests, And Experiments, for the Installation of Complex Programmable Logic Device (CPLD)

Based Solid State Protection System (SSPS) Cards, October 2, 2014. (ADAMS Accession No. ML14014A125) 103. IR 05000400/2013009; 04/01/2013 - 07/15/2013; Shearon Harris NPP, Unit 1; Evaluations of Changes, Tests, and Experiments and Permanent Plant Modifications Baseline Follow-up, August 12, 2013. (ADAMS Accession No. ML13224A290) 104. U.S. Nuclear Regulatory Commission (NRC),"Effects of Ethernet-Based,Non-Safety Related Controls on the Safe and Continued Operation of Nuclear Power Stations," NRC Information Notice: 2007-15, ADAMS Accession No. ML071010303, Washington, D.C., 2007.

105. EPRI 1016731, Operating Experience Insights on Common-Cause Failures in Digital Instrumentation and Control Systems, Electric Power Research Institute, Palo Alto, CA, December 2008.

106. Palo Verde Nuclear Station Unit 3, Reactor Trip Due to Lightning Induced Electrical Fault, (50-530) LER 91-008-00, December 13, 1991. (ADAMS Accession No. ML17306A337) 107. Turkey Point Units 3 and 4, 50-250/50-251, LER 94-005-02, Design Defect in Safeguards Bus Sequencer Logic Timing Places Both Units Outside the Design Basis, 50-250/50-251, LER 94-005-02, July 17, 1995. (ADAMS Accession No. ML17353A295) 108. Turkey Point Unit 3, 50-250, LER 2014-005-0, Manual Reactor Trip Due to Loss of Instrument Air, 50-250, LER 2014-005-0, October 10, 2014. (ADAMS Accession No. ML14303A475) 109. U.S. Department of Energy, Office of Health, Safety and Security, Software Quality Assurance, Firmware Defect in Programmable Logic Controller, Safety Advisory 2010-08, October 2010.110. EPRI TR-108331, Requirements Engineering for Digital Upgrades, Specification, Analysis, and Tracking, Electric Power Research Institute, Palo Alto, CA, December 1997.

8-8

110. EPRI TR-108331, Requirements Engineering for Digital Upgrades, Specification, Analysis, and Tracking, December 1997.

111. S. Guerra, P. Bishop, R. Bloomfield, and D. Sheridan, Assessment And Qualification Of Smart Sensors, Seventh American Nuclear Society International Topical Meeting on Nuclear Plant Instrumentation, Control and Human-Machine Interface Technologies NPIC&HMIT 2010, Las Vegas, Nevada, November 7-11, 2010, on CD-ROM, American Nuclear Society, LaGrange Park, IL (2010).

112. U.S. NRC Research Information Letter 1002, Identification and Analysis of Failure Modes in Digital Instrumentation and Controls (DI&C) Safety SystemsExpert Clinic Findings, Part 2, August 12, 2013. (ADAMS Accession No. ML14197A201) 113. Erin Engineering, Benefits and Risks Associated with Expanding Automated Diverse Actuation System Functions, Electric Power Research Institute, Palo Alto, CA,, 2008.

(ADAMS Accession No.ML090860465) 114. U.S. NRC SECY-09-0061, Status of The Nuclear Regulatory Commission Staff Efforts to Improve the Predictability and Effectiveness of Digital Instrumentation and Control Reviews, April 14, 2009.

115. S. Birla, Russell Sydnor, and N. Carte, (Availability of) An International Report on Safety Critical Software for Nuclear Reactors by the Regulator Task Force on Safety Critical Software (TF-SCS), NUREG/IA-0463, December 2015. (ADAMS Accession No. ML15348A206) 116. U.S. NRC Commissioner Briefing on Digital Instrumentation and Control, Rockville, Maryland, May 14, 2019. (Adams Accession No. ML19137A336) 117. U.S. Department of Transportation, Federal Aviation Administration, Software Service History Report, DOT/FAA/AR-01/125, Office of Aviation Research, Washington, D.C. 20591, January 2002.

118. R. Wood, et. al., Development and Demonstration of a Model Based Assessment Process for Qualification of Embedded Digital Devices in Nuclear Power Applications, Second Annual Progress Report, September 2017.

119. U.S. NRC Research Information Letter 1001: Software-Related Uncertainties in the Assurance of Digital Safety SystemsExpert Clinic Findings, Part 1. (ADAMS Accession No. ML111240017) 120. A. E. Summers, Kiss Off Safety System Myths, Many Misconceptions Muddle Maneuvers to Manage Risks, Chemical Processing, Environmental Health & Safety I Safety Instrumented Systems, Nov 07, 2011.

121. M. van der Meulen, On the Use of Smart Sensors, Common Cause Failure and the Need for Diversity, Centre for Software Reliability, City University, London http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.457.3366&rep=rep1&type=pdf 122. Nuclear Plant Reliability Data System (NPRDS). 1982 Annual Report. October 1983. Data inclusive for 7/74 - 12/82.

8-9

123. A. E. Summers, IEC 61508 Product Approvals-Veering off Course, ControlGlobal.com, July 2008. https://www.controlglobal.com/articles/2008/187/

124. UK Office of Nuclear Regulation, Safety Assessment Principles for Nuclear Facilities, 2014 Edition, Revision 1 (January 2020). http://www.onr.org.uk/saps/saps2014.pdf 125. U.S. NRC Final Safety Evaluation by the Office of Nuclear Reactor Regulation, Topical Report WCAP-17867-P, Revision 1, Westinghouse SSPS Board Replacement Licensing Summary Report, Pressurized Water Reactor Owners Group, September 19, 2014.

(ADAMS Accession No. ML14260A143) 126. UK Office for Nuclear Regulation, Technical Assessment Guide - Computer Based Safety Systems, NS-TAST-GD-046, Rev. 5, Liverpool, 2019.

127. International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC) / Institute of Electrical and Electronic Engineers (IEEE), Systems and software engineering Vocabulary, ISO/IEC/IEEE 24765-2017, 2017-09.

128. EPRI 1019182, Protecting against Digital Common-Cause Failure: Combining Defensive Measures and Diversity Attributes, Electric Power Research Institute, Palo Alto, CA,Final Report, November 2010.

129. B. Fitzgerald, T. Prestifilippo, and C. Holden, Digital field devices make headway and deliver results in NPPs, Nuclear Exchange, November 2012.

130. U.S. NRC Research Information Letter 1101, Technical Basis to Review Hazard Analysis of Digital Safety Systems, February 13, 2015. (ADAMS Accession No. ML14237A359) 131. B. F. Dittman, Digital I&C Research Relating to Embedded Digital Devices, Workshop on Safe Use of EDDs, October 9, 2014. (ADAMS Accession No. ML14280A569) 132. K. Korsah, S. M. Cetiner, M. D. Muhlheim, and W. P. Poore III, An Investigation of Digital Instrumentation and Control System Failure Modes, ORNL/TM-2010/32, March 2010.

133. 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.

134. K. Korsah, M. D. Muhlheim, and D. E. Holcomb, Industry Survey of Digital I&C Failures, ORNL/TM-2006/626, May 2007.

135. K. Korsah, S. Cetiner , M. Muhlheim, and W. P. Poore III, An Investigation of Digital Instrumentation and Control System Failure Modes, NPIC-HMIT 2010.

136. Letter from William J. Shack, Chairman, ACRS, to Dale E. Klein, Chairman, U.S. NRC,

Subject:

Digital Instrumentation and Control Systems Interim Staff Guidance, April 29, 2008. (ADAMS Accession No. ML081050636) 137. R. R. Lutz, Analyzing software requirements errors in safety-critical, embedded systems, Proceedings of the IEEE International Symposium on Requirements Engineering, 126-133, 1993.

8-10

138. National Research Council 2007. Software for Dependable Systems: Sufficient Evidence?.

Washington, DC: The National Academies Press. https://doi.org/10.17226/11923.

139. P. Gruhn and S. Lucchini, Safety Instrumented Systems: A Life-Cycle Approach, International Society of Automation, 2019.

140. International Society of Automation, Safety Integrity Level (SIL) Verification of Safety Instrumented Functions, ISA-TR84.00.02-2015, Research Triangle Park, North Carolina, Approved 8 September 2015.

141. S. Abdel-Khalik, Draft Final Digital Instrumentation & Control Interim Staff Guidance-06:

Licensing Process, Oct. 2010. (ADAMS Accession No. ML102850357) 142. U.S. NRC Inspection Procedure 38703, Commercial Grade Dedication, 1996.

143. U.S. NRC Inspection Procedure 43004, Inspection of Commercial-Grade Dedication Programs, November 2013. (ADAMS Accession No. ML16344A092) 144. U.S. Nuclear Regulatory Commission Staff, Safety Evaluation for Topical Report 2016-RPC003-TR-001 RadICS Safety System Digital Platform, August 2019 (NRC Adams Accession No. ML19134A193).

145. U.S. NRC Information Notice 1997-081, Deficiencies in Failure Modes and Effects Analyses for Instrumentation and Control Systems (ADAMS Accession Number: ML031050048) 146. 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 (ADAMS Accession Number: ML11201A179) 147. EPRI 300200509, Hazard Analysis Methods for Digital Instrumentation and Control Systems, Electric Power Research Institute, Palo Alto, CA, June 27, 2013.

148. U.S. Department of Transporation, Federal Aviation Administation, FAA System Safety Handbook, Chapter 8, Safety Analysis/Hazard Analysis Tasks, December 30, 2000.

149. EPRI 3002002990, Digital Common-Cause Failure Susceptibility: 2014 Project Status Electric Power Research Institute, Palo Alto, CA, November 2014.

150. IEEE Std. 100-2000, Authoritative Dictionary of IEEE Standards Terms, Institute of Electrical and Electronics Engineers, Piscataway, NJ, 2000.

151. UK Ministry of Defence, Requirements for safety related electronic hardware in defence equipment,, Defence Standard 00-54, 1999.

152. IEEE Std. 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology, Institute of Electrical and Electronics Engineers, Piscataway, NJ, 1990.

153. Government of Japan, Convention on Nuclear Safety National Report of Japan for the Third Review Meeting, August 2004.

https://www.meti.go.jp/english/report/downloadfiles/NISAreport3e.pdf 8-11

154. EPRI Technical Report 3002011816, Digital Engineering Guide, Decision Making Using Systems Engineering, Electric Power Research Institute, Palo Alto, CA, October 2018.

155. lEEE Std. 1100-2005, IEEE Recommended Practice for Powering and Grounding Electronic Equipment, Institute of Electrical and Electronics Engineers, Piscataway, NJ, Approved 9 December 2005.

156. EPRI 1001468, Final Report, Generic Qualification of the Rosemount 3051N Pressure Transmitter Summary of Activities and Results, Electric Power Research Institute, Palo Alto, CA, June 2000.

157. A. Nack, Standardizing Functional Safety Assessments for Off-The-Shelf Instrumentation and Controls, Masters Theses, The University of Tennessee, May 2016.

158. IEEE Std. 323-2003, IEEE Standard for Qualifying Class 1E Equipment for Nuclear Power Generating Stations, Institute of Electrical and Electronics Engineers, Piscataway, New Jersey, 2003.

159. R. A. Kisner et. al., Safety and Nonsafety Communications and Interactions in International Nuclear Power Plants, ORNL/NRC/LTR-07/05, August 2007.

160. International Atomic Energy Agency, Specification of requirements for upgrades using digital instrument and control systems, IAEA-TECDOC-1066, Vienna, 1999.

161. World Nuclear Association, Report No. 2015/008, Safety Classification for I&C Systems in Nuclear Power Plants - Current Status & Difficulties, September 2015.

162. International Atomic Energy Agency, Core Knowledge on Instrumentation and Control Systems in Nuclear Power Plants: A Reference Book, Nuclear Energy Series Report, IAEA NP-T-3.12, Vienna, Austria, December 2011.

163. 10 CFR 21.3, Definitions.

164. G. G. Preckshot and J. A. Scott, A Proposed Acceptance Process for Commercial Off-the-Shelf (COTS) Software in Reactor Applications, NUREG/CR-6421, March 1996. (ADAMS Accession No. ML063530384) 165. EPRI TR 1025243, Plant Engineering: Guideline for the Acceptance of Commercial-Grade Design and Analysis Computer Programs Used in Nuclear Safety-Related Applications, Electric Power Research Institute, Palo Alto, CA, June 2012.

166. U.S. NRC Regulatory Guide 1.231, Revision 0, Acceptance of Commercial-Grade Design and Analysis Computer Programs Used in Safety- Related Applications for Nuclear Power Plants, January 2017. (ADAMS Accession No. ML16126A183) 167. EPRI 3002002289, Plant Engineering: Guideline for the Acceptance of Commercial-Grade Design and Analysis Computer Programs Used in Nuclear Safety-Related Applications, Revision 1 of 1025243, Electric Power Research Institute, Palo Alto, CA, December 2013.

8-12

168. EPRI NP-6895, Guidelines for the Safety Classification of Systems, Components, and Parts Used in Nuclear Power Plant Applications (NCIG-17), Electric Power Research Institute, Palo Alto, CA, 1991.

169. U.S. Department of Transporation, Federal Aviation Administration, Software Development for the National Airspace System (NAS), FAA-STD-026A, June 1, 2001.

170. National Aeronautics and Space Administration, NASA Software Engineering Requirements, NASA NPR 7150.2A, November 2009.

171. British Standard Institution (BSI), Railway applicationsCommunication, signaling and processing systemsSoftware for railway control and protection systems, BS EN 51208:2011+A1:2020.

172. International Atomic Energy Agency, Instrumentation and Control Systems Important to Safety in Nuclear Power Plants, IAEA NS-G-1.3, Vienna, Austria, 2002.

173. International Atomic Energy Agency, Technical Challenges in the Application and Licensing of Digital Instrumentation and Control Systems in Nuclear Power Plants, Vienna IAEA Nuclear Energy Series No. NP-T-1.13, 2015.]

174. International Atomic Energy Agency, Safety Classification of Structures, Systems and Components in Nuclear Power Plants, IAEA Safety Standards Series No. SSG-30, Vienna, 2014.

175. International Electrotechnical Commission, Nuclear power plants - Instrumentation and control important to safety - Classification of instrumentation and control functions, IEC 61226, Edition 3, Geneva, Switzerland, 2005*09*23.

176. E. Butler, et. al., COTS Digital Devices in Safety Critical Industries, Report 2019:627, ENERGIFORSK NUCLEAR SAFETY RELATED I&C - ENSRIC, November 2019.

177. International Atomic Energy Agency, Modern Instrumentation and Control for Nuclear Power Plants, a Guidebook, IAEA Technical Reports Series No. 387, Vienna, 1999.

178. U.S. NRC SRP BTP 7-17, Rev. 6, Guidance on Self-Test and Surveillance Test Provisions, August 2016. (ADAMS Accession No. ML16019A316) 179. S. Birla, R. Sydnor, and N. Carte, (Availability of) An International Report on Safety Critical Software for Nuclear Reactors by the Regulator Task Force on Safety Critical Software (TF-SCS), NUREG/IA-0463, December 2015. (ADAMS Accession No. ML15348A206) 180. International Atomic Energy Agency, Safety of Nuclear Power Plants: Design, IAEA Safety Standard Series Requirements NS-R-1:2016, Vienna, 2016.

181. K. Korsah, et. al., Instrumentation and Controls in Nuclear Power Plants: An Emerging Technologies Update, NUREG/CR-6992, October 2009. (ADAMS Accession No. ML092950511) 8-13

182. International Electrotechnical Commission, Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 4: Definitions and abbreviations, IEC 61508-4, Edition 2, Geneva, Switzerland, 2010-04.

183. S. Brown and J. Rose, Architecture of FPGAs and CPLDs: A Tutorial, Department of Electrical and Computer Engineering, University of Toronto.

184. EPRI 3002012755, HAZCADS: Hazards and Consequences Analysis for Digital Systems, Electric Power Research Institute, Palo Alto, CA, Dec 17, 2018.

185. ASME/ANS RA-Sa-2009, Standard for Level 1/Large Early Release Frequency Probabilistic Risk Assessment for Nuclear Power Plant Applications, Addendum A to RA-S-2008, ASME, New York, NY, American Nuclear Society, La Grange Park, IL, February 2009.

186. NRC Web: Glossary http://www.nrc.gov/reading-rm/basic-ref/glossary.html 187. U.S. Department of Energy, Design of Safety Significant Safety Instrumented Systems Used at DOE Nonreactor Nuclear Facilities, DOE-STD-1195-2011, April 2011.

188. Siemens, Functional safety in process instrumentation with SIL rating, Questions, examples, background.

https://cache.industry.siemens.com/dl/files/169/109766169/att_980479/v1/SIL-Broschuere_EN.pdf 189. F. Liebusch, Relays in safety-related control systems, Electronic Specifier, January 9, 2017.

https://www.electronicspecifier.com/products/power/relays-in-safety-related-control-systems 190. MEN Mikro Elektronik, Embedded Electronics Product and Expertise Overview for Mission-Critical Industrial, Aerospace, Power & Energy, Marine, Automotive and Medical Solutions.

191. International Atomic Energy Agency, Dependability Assessment of Software for Safety Instrumentation and Control Systems at Nuclear Power Plan, Vienna IAEA Nuclear Energy Series No. NP-T-3.27,, 2018.

192. J. C. Laprie, Dependable Computing: Concepts, Limits Challenges, Proceedings of the 25th IEEE International Symposium on Fault-Tolerant ComputingSpecial Issue, Institute of Electrical and Electronics Engineers, Pasadena, California, pp. 42-54 (1995).

193. R. T. Wood, et. al., Diversity Strategies for Nuclear Power Plant Instrumentation and Control Systems, NUREG/CR-7007, February 2010.

194. International Electrotechnical Commission, Functional safety of electrical/electronic/programmable electronic safety-related systems, IEC 61508:2010, Geneva, Switzerland, 2010.

195. International Society of Automation (ISA), Functional Safety - Safety Instrumented Systems for the Process Industry Sector - Part 1: Framework, definitions, system, hardware and application programming requirements, ANSI/ISA-61511-1-2018 / IEC 61511-1:2016, Research Triangle Park, North Carolina, (IEC 61511-1:2016+AMD1:2017 CSV, IDT).

8-14

196. A. E. Summers, K. A. Ford, and G. Randy, Estimation and Evaluation of Common Cause Failures in SIS, Chemical Engineering Progress, November 1999.

197. International Atomic Energy Agency, Procedures for conducting common cause failure analysis in probabilistic safety assessment, IAEA TECDOC-648, Vienna, May 1992.

198. UK Health and Safety Executive (HSE), Proof Testing of Safety Instrumented Systems in the Onshore Chemical / Specialist Industry, Dec 14, 2018.

https://www.hse.gov.uk/foi/internalops/og/og-00054.htm 199. Letter from K. Deutsch, F. Bamdad, and P. Fox to S. A. Stokes, Technical Director, Defense Nuclear Facilities Safety Board, Staff Issue Report, Alternative Methodology for Safety Integrity Level Determination of Instrumented Systems at the Low-Activity Waste Pretreatment System, June 12, 2017.

200. G. Coles, Technical Specifications Surveillance Interval Extension of Digital Equipment in Nuclear Power Plants: Methods and Implementation Strategy, INL/EXT-19-55342, Revision 0, September 2019.

201. T. [Edward) Quinn, J. Mauck, R. Bockhorst, and K. Thomas, Digital Sensor Technology, INL/EXT-13-29750, July 2013.

202. International Society of Automation (ISA), Functional Safety - Safety Instrumented Systems for the Process Industry Sector - Part 2: Guidelines for the application of IEC 61511-1:2016, ANSI/ISA-61511-2-2018 / IEC 61511-2:2016, Research Triangle Park, North Carolina, (IEC 61511-2:2016, IDT) 203. IEEE Std. C37.231-2006(R2012), IEEE Recommended Practice for Microprocessor-Based Protection Equipment Firmware Control, Institute of Electrical and Electronics Engineers, Piscataway, NJ, Approved 12 June 2006, Reaffirmed 29 March 2012.

204. R. Wood, J. Mauck, and E. Quinn, Addressing Embedded Digital Devices in Safety-Related Systems of Nuclear Power Plants, NPIC&HMIT 2017, San Francisco, CA, June 11-15, 2017.

205. International Society of Automation (ISA), Guidelines for the Implementation of ANSI/ISA-84.00.01-2004 (IEC 61511 Mod), ISA-TR84.00.04-2015, Part 1, Research Triangle Park, North Carolina, Approved 6 April 2015.

206. S. Nunns, Principles for proof testing of safety instrumented systems in the chemical industry, Prepared by ABB Ltd for the Health and Safety Executive, 2002.

207. UK Office for Nuclear Regulation, Safety Systems, NS-TAST-GD-003, Revision 8, March 2018. http://www.onr.org.uk/operational/tech_asst_guides/ns-tast-gd-003.pdf 208. National Aeronautics and Space Administration, NASA Software Safety Guidebook, NASA-GB-8719.13, March 31, 2004.

209. IEEE Std. 1012-2004, IEEE Standard for Software Verification and Validation, Institute of Electrical and Electronics Engineers, Piscataway, NJ, 2004.

8-15

210. IEEE Std. 829-2008, IEEE Standard for Software and System Test Documentation, Institute of Electrical and Electronics Engineers, Piscataway, NJ, 2008.

211. T. Chu, M. Yue, G. Martinez-Guridi, and J. Lehner, Development of Quantitative Software Reliability Models for Digital Protection Systems of Nuclear Power Plants, Draft Report for Comment, NUREG/CR-7044, July 2011.

212. T. Chu, et. al., Development of A Statistical Testing Approach for Quantifying Safety-Related Digital System on Demand Failure Probability, NUREG/CR-7234, May 2017.

213. R. T. Wood et. al., Common-Cause Failure Mitigation Practices and Knowledge Gaps, ORNL/LTR-2012/556 (NEET/ASI/ORNL/TR-2012/01), October 2012.

214. J. Dion, M. K. Howlander, and P. D. Ewing, Wireless Network Security in Nuclear Facilities, NPIC&HMIT 2010, Las Vegas, Nevada, November 7-11, 2010. (Adams Accession No. ML103210371) 215. B.J. Kaldenbach, et. al., Assessment of Wireless Technologies and Their Application at Nuclear Facilities, Oak Ridge National Laboratory, NUREG/CR-6882, July 2006. (Adams Accession No. ML062140045) 216. M. Howlader, C.J. Kiger and P.D. Ewing, Coexistence Assessment of Industrial Wireless Protocols in the Nuclear Environment, Oak Ridge National Laboratory, NUREG/CR-6939, July 2007. (Adams Accession No. ML072210179) 217. EPRI 3002017641, EPRI Research Helps Ontario Power Generation (OPG) Deploy Its First Wireless Sensor Network at One Plant, Electric Power Research Institute, Palo Alto, CA, Dec 23, 2019.

218. Y. Zhang, B. Jaques, and V. Agarwal, Final Technical Report on Nanostructured Bulk Thermoelectric Generator for Efficient Power Harvesting for Self-powered Sensor Networks, Boise State University, March 2018.

219. V. Agarwal and Z. Ren, Sensors and Instrumentation Award Summaries, Nuclear Energy Enabling Technologies - Advanced Sensors and Instrumentation, May 2016.

220. E. Eagle, B. Venkataraman, and D. Hardesty, Embedded Digital Device Regulatory Issue Summary Update Embedded Digital Device Workshop, Workshop on Safe Use of EDDs, October 08, 2014. (ADAMS Accession No. ML14281A535) 221. G. Clefton, Overview - Embedded Digital Devices, Workshop on Safe Use of EDDs, October 9, 2014. (ADAMS Accession No. ML14280A548) 222. E. Lee, Cyber Security, Workshop on Safe Use of EDDs, October 9, 2014. (ADAMS Accession No. ML14280A537) 223. U.S. NRC RIS 2002-22, Supplement 1, Clarification on Endorsement of Nuclear Energy Institute Guidance in Designing Digital Upgrades in Instrumentation and Control Systems, May 31, 2018. (ADAMS Accession No. ML18143B633) 8-16

224. Nuclear Energy Institute, Guidelines for 10 CFR 50.59 Evaluations, Appendix D [Draft],

Supplemental Guidance for Application of 10 CFR 50.59 to Digital Modifications, NEI 96-07, Appendix D, December 20, 2016. (ADAMS Accession No. ML17075A371) 225. United States Government Accountability Office, Report to Congressional Committees, Internet of Things, Enhanced Assessments and Guidance Are Needed to Address Security Risks in DOD, GAO-17-668, July 2017.

226. B. D. Shumaker, A. H. Hashemian, H. M. Hashemian, and R. T. Wood, Summary Report of Technical Findings from Workshop on Qualification of Embedded Digital Devices, DOE Report M3CA-15-TN-UTK-0703-032, AMS Corp., Knoxville, TN, July 2016.

227. U.S. NRC BTP 7-19, Rev. 7, Guidance for Evaluation of Diversity and Defense-In-Depth in Digital Computer-Based Instrumentation and Control Systems Review Responsibilities, August 2016. (ADAMS Accession No. ML16019A344) 228. R. T. Wood, et. al., Development of a Model Based Assessment Process for Qualification of Embedded Digital Devices in NPP Applications: Research Approach and Current Status, 2017. https://www.semanticscholar.org/paper/DEVELOPMENT-OF-A-MODEL-BASED-ASSESSMENT-PROCESS-FOR-Wood-Hashemian/c01e2e66782aa8dde9bb75aabe568b49e3677fd7 229. B. D. Shumaker et. al., Development and Demonstration of a Model Based Assessment Process for Qualification of Embedded Digital Devices in Nuclear Power Applications Technical Report, Summary Report of Technical Findings from Workshop on Qualification of Embedded Digital Devices, July 25, 2016.

230. A. Melin, R. Kisner, and R. Vidrio, Embedded Instrumentation & Control for Extreme Environments, Advanced Sensors and Instrumentation, Issue 5, September 2016.

231. B. Shumaker, R. Wood, C. Elks, and C. Smidts, Qualification of Embedded Digital Devices in Instrumentation, Advanced Sensors and Instrumentation, Issue 6, March 2017.

232. C. Elks, T. Bakker, and M. Gibson, Verifiable Digital I&C and Embedded Digital Devices for Nuclear Power, Advanced Sensors and Instrumentation, Issue 6, March 2017.

233. S. Schuppner, DOE-NE Digital I&C Research, IAEA Technical Meeting on Critical Challenges with Digital Instrumentation and Control Systems at Nuclear Power Plants, October 8-11, 2019.

234. DOE Office of Nuclear Energy, Advanced Sensors and Instrumentation Award Summaries, Development of Model Based Assessment Process for Qualification of Embedded Digital Devices in NPP Applications, June 2018.

235. P. Picca, Relationship between the IAEA NE series report on digital COTS and the new IAEA safety report on smart devices IAEA technical meeting 19th February 2020, Vienna, Austria, February 19, 2020.

236. R. Whitley, Non Power Reactor: MOX Project Commercial Grade Dedication Challenges, June 21, 2012. (ADAMS Accession No. ML12171A541) 8-17

237. SAE International, Guidelines for Development of Civil Aircraft and Systems, SAE ARP 4754A, December 21, 2010.

238. U.S. Food and Drug Administration (FDA), General Principles of Software Validation; Final Guidance for Industry and FDA Staff, January 11, 2002. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-principles-software-validation 239. U.S. Department of Health and Human Services Food and Drug Administration, Guidance for Industry Q9 Quality Risk Management, Annex I: Risk Management Methods and Tools, June 2006. https://www.fda.gov/media/71543/download 240. International Electrotechnical Commission, Analysis techniques for system reliability -

Procedure for failure mode and effects analysis (FMEA), IEC 60812 Edition 3.0, Geneva, Switzerland, 2018-08.

241. Federal Energy Regulatory Commission, Major Orders and Regulations.

https://www.ferc.gov/enforcement-legal/legal/major-orders-regulations 242. National Aeronautics and Space Administration, Standard for Models and Simulations, NASA-STD-7009A W/CHANGE 1, Approved: 2016-07-13.

243. R. Katz, R. Barto, and K. Erickson, Logic Design Pathology and Space Flight Electronics, NASA Goddard Space Flight Center, 1997.

244. 29 CFR § 1910.119, Process safety management of highly hazardous chemicals, January 1, 2019.

245. Letter from R. E. Fairfax, to L. M. Ferson, Manager of Standards Services, ISA, Compliance with PSM and ANSI/ISA-S84.01 for safety instrumented systems, March 28, 2000. https://

www.osha.gov/laws-regs/standardinterpretations/2000-03-23 246. Occupational Health and Safety Administration, U.S. Department of Labor, What is a Nationally Recognized Testing Laboratory (NRTL).

https://www.osha.gov/dts/otpca/nrtl/nrtl_faq.html#employers_regulators 247. Occupational Health and Safety Administration, U.S. Department of Labor, Type of Products Requiring NRTL Approval. https://www.osha.gov/dts/otpca/nrtl/prodcatg.html 248. Organisation for Economic Co-operation and Development, Nuclear Energy Agency, CNRA Working Group on the Regulation of New Reactors, Report of the Survey on the Design Review of New Reactor Applications, Volume 1, Instrumentation and Control, NEA/CNRA/R(2014)7, 28-Jul-2014.

249. Swedish Radiation Safety Authority, Licensing of safety critical software for nuclear reactors, Common position of international nuclear regulators and authorised technical support organisations, 2010 BEL V, BfS, Consejo de Seguridad Nuclear, ISTec, NII, SSM, STUK, 2007.

https://inis.iaea.org/collection/NCLCollectionStore/_Public/41/028/41028258.pdf 250. CSA Group, Qualification of pre-developed software for use in safety-related instrumentation and control applications in nuclear power plants, CSA N290.14-07 (R2012).

8-18

251. Atomic Energy of Canada Limited, Standard for Software Engineering of Safety Critical Software, AECL CE-1001-STD, Revision 2, 12/01/1999.

252. French Nuclear Safety Authority, Seventh French Report under the Convention on Nuclear Safety, August 2016. https://www-ns.iaea.org/downloads/ni/safety_convention/7th-review-meeting/france-7th-report-national-csn.pdf 253. AFCEN Subcommittee RCC-E, Design and construction rules for electrical and I&C systems and equipment, 2016. https://afcen.com/en/publications/rcc-e/42/rcc-m-2012 254. Federal Ministry for the Environment, nature conservation and nuclear safety, Safety Requirements for Nuclear Power Plants, SiAnf, BMU, Berlin, 2015.

255. Kerntechnische Ausschuss (KTA), Reactor protection system and surveillance devices of the safety system, Safety Standard KTA 3501, November 2015. http://www.kta-gs.de/e/standards/3500/3501_engl_2015_11.pdf 256. The Association of German Engineers/Association of German Electricians, Requirements of commercial grade products and criteria for their use in the instrumentation and control systems important to safety in nuclear power plants - General part, Guideline, 3528 Blatt 1, VDI/VDE, Düsseldorf/Frankfurt am Main, 2017.

257. G. Karmakar and Y. Nirgude, AERB SG D-25 and IEC 60880 for certification of software in safety systems of Indian NPP, Proceedings of International Conference on VLSI, Communication, Advanced Devices, Signals & Systems and Networking (VCASAN-2013),

Volume: Lecture Notes in Electrical Engineering Vol. 258 Bangalore, July 2013.

https://www.researchgate.net/publication/267116185_AERB_SG_D-25_and_IEC_60880_for_certification_of_software_in_safety_systems_of_Indian_NPP 258. Atomic Energy Regulatory Board, Computer Based Systems of Pressurised Heavy Water Reactors, AERB Safety Guide AERB/NPP-PHWR/SG/D-25, Mumbai-400 094, India, January 2010.

https://www.aerb.gov.in/storage/images/PDF/CodesGuides/NuclearFacility/NPPDesign/3.pd f

259. H. Singh, Regulatory Requirements and Review Process for Qualification of Smart Devices for Use in NPPs, IAEA Technical Meeting, Vienna, February 17-21, 2020.

260. N. Agrawal, Issues & Challenges in Qualification of Smart Transmitters in Indian Nuclear Power Plants, IAEA Technical meeting on the Safety Aspects of Using Smart Digital Devices in Nuclear Systems Important to the Safety of Nuclear Power Plants, Vienna, Austria, 17 to 21 February 2020.

261. Nuclear Regulatory Authority, Outline of New Regulatory Requirements (Design Basis),

April 3, 2013. https://www.nsr.go.jp/data/000067117.pdf 262. Korea Institute of Nuclear Safety, KINS Safety Review Guidelines (SRG) for Light Water Reactor, KINS/GE-001, 2015.

263. IEEE Std. 7-4.3.2-2003, IEEE Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating Station, Institute of Electrical and Electronics Engineers, Piscataway, NJ, 19 December 2003.

8-19

264. U.S. NRC SRP Appendix 7.0-A, Rev. 6, Review Process for Digital Instrumentation and Control Systems, August 2016.

265. Yun Goo Kim, Smart Device and CCF analysis in APR1400, IAEA Technical Meeting on Smart Devices, Vienna, 17-21 February 2020.

266. F. Ullah, Safety Aspects of Using Smart Digital Devices in Nuclear Systems, Technical Meeting on Safety Aspects of Using Smart Digital Devices in Nuclear Systems, IAEA Headquarters Vienna, Austria, 17 to 21 February 2020.

267. B. Mircea, Smart Devices In Cernavoda NPP, IAEA Technical Meeting on the Safety Aspects of Using Smart Digital Devices in Nuclear Systems Important to the Safety of Nuclear Power Plants, IAEA Headquarters Vienna, Austria, 17 to 21 February 2020.

268. Personnal communication Mircea Barbu to M. D. Muhlheim, June 4, 2020.

269. M. Anton Iacobet, Current status of the regulatory activities related to computer security, IAEA Technical meeting on the Safety Aspects of Using Smart Digital Devices in Nuclear systems Important to the Safety of Nuclear Power Plants, Vienna, Austria, 17 to 21 February 2020.

270. International Society of Automation, Method for evaluating the performance of positioners with analog input signals and pneumatic output, ANSI/ISA S75.13.01, Research Triangle Park, North Carolina, 2013.

271. Federal Nuclear and Radiation Safety Authority of Russia (Gosatomnadzor of Russia),

General Regulations on Ensuring Safety of Nuclear Power Plants, OPB-88/97, NP-001-97 (PNAE G- 01 011-97), 1997.

272. V. Sivokon and D. Chichikin, Challenges of NPP I&C System Digitization, International Considerations, IAEA Technical Meeting on Safety Aspects of Using Smart Digital Devices in Nuclear Important to the Safety of NPPs, 17-21 February 2020.

273. E. Andropov, Third Approach: Between Analogue and Smart, Technical Meeting on Safety Aspects of Using Smart Digital Devices in Nuclear Systems, IAEA Headquarters Vienna, Austria, 17 to 21 February 2020.

274. S. Guerra, Smart Device Justification in the UK, The Cogs Approach, IAEA Technical Meeting on Safety Aspects of Using Smart Digital Devices in Nuclear Important to the Safety of NPPs, 17-21 February 2020.

275. Staff Requirements Memorandum (SRM) to SECY-98-144, White Paper on Risk-Informed and Performance-Based Regulation, March 1, 1999. (NRC ADAMS Accession No. ML003753601) 276. EPRI 3002011817, Safety Integrity Level (SIL) Certification Efficacy for Nuclear Power, Final Report, Electric Power Research Institute, Palo Alto, CA, July 2019.

277. G. Johnson, Comparison of IEC and IEEE standards for computer-based control systems important to safety, in 2001 IEEE Nuclear Science Symposium Conference Record, 2001, no. HCSS++, pp. 2474-2481.

8-20

278. J. S. Lee and K. Kwon, Comparison of the Software Safety Criteria between IEC and IEEE Standards for the Digital Instrumentation and Control System, in Transactions of the Korean Nuclear Society Autumn Meeting, 2006, pp. 1-2.

279. T. S. Lockhart, Vetting Smart Instruments for the Nuclear Industry, Moore Industries-International, Inc., September 2015.

https://www.miinet.com/images/pdf/whitepapers/Vetting_Smart_Instruments_for_the_Nuclea r_Industry_White_Paper_Moore_Industries.pdf 280. Reference Manual 00809-0100-4808, Rev CA, Rosemount 3051N Smart Pressure Transmitter for Nuclear Service, June 2008.

https://www.emerson.com/documents/automation/manual-rosemount-3051n-smart-pressure-transmitter-for-nuclear-service-en-89488.pdf 281. Personal communication from Mark Bowell, Principal Inspector - Nuclear Safety, Sellafield DFW Division, to D. S. Halverson, NRC, February 5, 2020.

282. R. T. Wood, et al., First Annual Progress Report, DOE Report M3CA-15-TN-UTK_-0703-033, The University of Tennessee, Knoxville, TN, September 2016.

283. American Petroleum Institute , Process Control SystemsProcess Control Systems Functions and Functional Specification Development, API Recommended Practice 554, Part 1, Second Edition, July 2007, Reaffirmed, November 2016.

284. American Petroleum Institute , Process Control SystemsProcess Control System Design, Downstream Segment, API Recommended Practice 554, Part 2, First Edition, October 2008, Reaffirmed, November 2016.

285. American Petroleum Institute , Risk-Based Inspection Methodology April 2016, API Recommended Practice 581, Third Edition, Addendum 1, April 2019.

286. MicroComputer Data Processing Company, Glossary of functional safety standards," https://

mcdpinc.com/glossary 287. U.S. NRC Generic Letter 89-02, Actions to Improve the Detection of Counterfeit and Fraudulently marketed Products, March 21, 1989.

288. U.S. NRC Generic Letter 91-05, Licensee Commercial-Grade Procurement and Dedication Programs, April 9, 1991.

289. U.S. NRC, The Vendor Times, December 2018. (ADAMS Accession No. ML18312A422) 290. U.S. NRC BTP 7-18, Revision 6, Guidance on The Use of Programmable Logic Controllers in Digital Computer-Based Instrumentation and Control Systems, August 2016. (ADAMS Accession No. ML16019A327) 291. EPRI TR-107330, Generic Requirements Specification for Qualifying a Commercially Available PLC for Safety-Related Applications in NPPs, Electric Power Research Institute, Palo Alto, CA, December 1996.

292. U.S. NRC Safety Evaluation Report, Safety Evaluation by the Office of Nuclear Reactor Regulation Electric Power Research Institute Topical Report, TR-107330, "Generic 8-21

Requirements Specification for Qualifying a Commercially Available PLC for Safety-Related Applications in Nuclear Power Plants, July 30, 1998. (ADAMS Accession No. ML12205A265) 293. EPRI 1008256, Rev. 1, Plant Support Engineering: Guidelines for the Technical Evaluation of Replacement Items in NPPsRevision 1, Electric Power Research Institute, Palo Alto, CA, 2006.

294. EPRI 3002005326, Methods for Assuring Safety and Dependability when Applying Digital Instrumentation and Control Systems, Electric Power Research Institute, Palo Alto, CA, June 30, 2016.

295. EUROCAE (European Organisation for Civil Aviation equipment) ED-79/ARP-4754, Certification considerations for highly-integrated or complex aircraft, EUROCAE, 17 Rue Hamelin, 75783 Paris, Cedex 16, France, 1996.

296. Y. Papadopoulos and J. A. McDermid, The potential for a generic approach to certification of safety critical systems in the transportation sector, Reliab. Eng. Syst. Saf., vol. 63, no. 1, pp. 47-66, Jan. 1999.

297. International Atomic Energy Agency, Safety of Nuclear Power Plants: Design, IAEA Specific Safety Requirements No. SSR-2/1, Vienna STI/PUB/1534, January 2012.

298. International Atomic Energy Agency, Safety of Nuclear Power Plants: Commissioning and Operation, IAEA Specific Safety Requirements No. SSR-2/2 (Rev. 1), Vienna, 2016.

299. International Atomic Energy Agency, Terminology Used in Nuclear Safety and Radiation Protection, Vienna, IAEA Safety Glossary, 2018 Edition.

300. P. Picca, Relationship between the IAEA NE series report on digital COTS and the new IAEA safety report on smart devices, IAEA technical meeting Vienna, Austria, 19 th February 2020.

301. D. Fournier, Safety Report NSNI-18-23, Safety Aspects of Using Smart Devices in Nuclear Systems Important to Safety, IAEA technical meeting Vienna, Austria, February 17-23, 2020.

302. International Electrotechnical Commission, Nuclear power plants - Instrumentation and control systems important to safety - Requirements for coping with common cause failure (CCF), IEC 62340, Edition 1.0, Geneva, Switzerland, 2007-12.

303. International Electrotechnical Commission, Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems - Part 7: Overview of Techniques and Measures, Second Edition, IEC 61508-7 Ed. 2.0, Geneva, Switzerland, April 2010.

304. International Electrotechnical Commission, "Examples of methods for the determination of safety integrity levels," IEC 61508-5, Edition 2.0, Geneva, Switzerland, 2010-04.

305. International Accreditation Forum, About US. https://www.iaf.nu//articles/About/2 8-22

306. International Electrotechnical Commission, Conformity assessment - Requirements for accreditation bodies accrediting conformity assessment bodies, ISO/IEC 17011, Geneva, Switzerland, 2017-11.

307. International Electrotechnical Commission, Conformity assessmentRequirements for bodies certifying products, processes and services, BS EN ISO/IEC 17065:2012, Geneva, Switzerland, 2012.

308. Nuclear Energy Institute, Guidance on Using IEC 61508 SIL Certification to Support the Acceptance of Commercial Grade Digital Equipment for Nuclear Safety Related Applications NEI 17-06, Revision B, September 2019.

309. International Electrotechnical Commission, , Evaluation methods for microprocessor-based instruments, NPR-IEC/TS62098,2001.

310. International Electrotechnical Commission, , Transmitters for use in industrial process control systems; Part 3: Methods for evaluation of intelligent transmitters IEC 60770-3, Ed.

2, .0, b:2-014.

311. International Organization for Standardization (ISO), Quality Management Systems Requirements, ISO 9001:2015, October 21, 2015.

312. Exida, Results of the IEC 61508 Functional Safety Assessment Project: DVC6200 SIS Digital Valve Controler and Position Monitor, October 18, 2019.

313. International Society of Automation, Functional Safety - Safety Instrumented Systems for the Process Industry Sector - Part 3: Guidelines for the determination of the required safety integrity levels, ANSI/ISA-61511-3-2018 / IEC 61511-3:2016, Research Triangle Park, North Carolina, Approved 11 July 2018.

314. British Standard Institution (BSI), Railway ApplicationsThe Specification and Demonstration of Reliability, Availability, Maintainability, and Safety (RAMS)Part 1: Basic Requirements and Generic Process, BS EN 50128:1999, 1999.

315. International Electrotechnical Commission, Medical Device Software - Software Life Cycle Processes, ISO/IEC 62304, Geneva, Switzerland, 2006.

316. Radio Technical Commission for Aeronautics (RTCA), Software Considerations in Airborne Systems and Equipment Certification, Radio Technical Commission for Aeronautics, DO-178C, 2011.

317. M. D. Muhlheim, et. al., Assessment of Applicability of Standards Endorsed by Regulatory Guides to Sodium Fast Reactors, ORNL/SR-2017/520, September 2017.

318. IEEE 603-2009, IEEE Standard Criteria for Safety Systems for Nuclear Power Generating Stations, Institute of Electrical and Electronics Engineers, Piscataway, NJ, September 11, 2009.

319. U.S. NRC Regulatory Guide 1.168, Revision 2, Verification, Validation, Reviews, and Audits for Digital Computer Software Used in Safety Systems of Nuclear Power Plants, July 2013.

(ADAMS Accession No. ML13073A210) 8-23

320. IEEE P1891, Standard Criteria for Application of Intelligent Digital Devices to Nuclear Power Generating Stations, Institute of Electrical and Electronics Engineers, Piscataway, NRC ADAMS Accession No. ML14280A578 321. International Society of Automation, Guidelines for the Application of ANSI/

ISA-84.00.01-2004 Part 1 (IEC 61511-1 Mod) - Informative, ISA-84.00.01-2004 Part 2 (IEC 61511-2 Mod), Research Triangle Park, North Carolina, 2 September 2004.

322. Organisation for Economic Co-operation and Development Nuclear Energy Agency, Vendor Inspection Co-operation Working Group (VICWG). http://www.oecd-nea.org/mdep/working-groups/vicwg.html 323. G. Galletti, NRC Vendor Inspection Update, NUPIC General Membership and Vendor Meetings, June 2014. (ADAMS Accession No. ML14150A118) 324. D. R. Wallace, L. M. Ippolito, and B. B. Cuthill, Reference Information for the Software Verification and Validation Process, NIST Special Publication 500-234, April 1996.

325. U.S. Department of Commerce, National Institute of Standards and Technology, Supply Chain Risk Management Practices for Federal Information Systems and Organizations, NIST SP 800-161, April 2015.

326. Office of Nuclear Regulation, A guide to Nuclear Regulation in the UK, 2016 Update, 2016.

http://www.onr.org.uk/documents/a-guide-to-nuclear-regulation-in-the-uk.pdf 327. J. Masters and J. Britton, How To Achieve EN 50128 Compliance, PR QA Programming Research. https://www.perforce.com/resources/qac/how-achieve-en-50128-compliance P 328. UK Office for Nuclear Regulation, Categorisation of Safety Functions and Classification of Structures, Systems and Components, NS-TAST-GD-094, Revision 1, July 2019.

http://www.onr.org.uk/operational/tech_asst_guides/ns-tast-gd-094.pdf 329. Occupational Safety and Health Administration, Process Safety Management.

https://www.osha.gov/SLTC/processsafetymanagement/

330. Occupational Safety and Health Administration, Standard Interpretations, Use of ANSI/ISA S84.00.01-2004 Parts 1-3 (IEC 61511 MOD) to comply with OSHA's Process Safety Management standard. https://www.osha.gov/laws-regs/

standardinterpretations/2005-11-29 331. Avanceon, Standards and Tools - MES & Automation. https://avanceon.com/standards-and-tools/

332. IEEE 603-1991, IEEE Standard Criteria for Safety Systems for Nuclear Power Generating Stations, Institute of Electrical and Electronics Engineers, Piscataway, NJ, Approved June 27,1991.

8-24

APPENDIX A DEFINITIONS Augmented quality Augmented quality is an optional subset of the classification category non-safety-related

[A.5]. It may be applied to any item that is subject to non-safety-related regulatory requirements or special requirements imposed by the customer.

Automation Any technique, method, or system of operating or controlling a process which reduces human intervention to a minimum and does not require continuous input from an operator

[A.14].

Basic component (10 CFR 21.3)

(1)(i) When applied to NPPs licensed under 10 CFR part 50 or part 52 of this chapter, basic component means a structure, system, or component, or part thereof that affects its safety function necessary to assure:

(A) The integrity of the reactor coolant pressure boundary; (B) The capability to shut down the reactor and maintain it in a safe shutdown condition; or (C) The capability to prevent or mitigate the consequences of accidents which could result in potential offsite exposures comparable to those referred to in § 50.34(a)(1), § 50.67(b)(2), or § 100.11 of this chapter, as applicable.

(ii) Basic components are items designed and manufactured under a quality assurance program complying with appendix B to part 50 of this chapter, or commercial grade items which have successfully completed the dedication process.

(2) When applied to standard design certifications under subpart C of part 52 of this chapter and standard design approvals under part 52 of this chapter, basic component means the design or procurement information approved or to be approved within the scope of the design certification or approval for a structure, system, or component, or part thereof, that affects its safety function necessary to assure:

(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 which could result in potential offsite exposures comparable to those referred to in §§ 50.34(a)(1),

50.67(b)(2), or 100.11 of this chapter, as applicable.

(3) When applied to other facilities and other activities licensed under 10 CFR parts 30, 40, 50 (other than nuclear power plants), 60, 61, 63, 70, 71, or 72 of this chapter, basic component means a structure, system, or component, or part thereof, that affects their safety function, that is directly procured by the licensee of a facility or activity subject A-1

to the regulations in this part and in which a defect or failure to comply with any applicable regulation in this chapter, order, or license issued by the Commission could create a substantial safety hazard.

(4) In all cases, basic component includes safety-related design, analysis, inspection, testing, fabrication, replacement of parts, or consulting services that are associated with the component hardware, design certification, design approval, or information in support of an early site permit application under part 52 of this chapter, whether these services are performed by the component supplier or others.

Closed-loop (feedback) control A control system in which the controlled quantity is measured and compared with a standard representing the desired performance. Note: Any deviation from the standard is fed back into the control system in such a sense that it will reduce the deviation of the controlled quantity from the standard [A.2].

Commercial grade item (10 CFR 21.3)

(1) When applied to NPPs licensed pursuant to 10 CFR Part 50, commercial grade item means a structure, system, or component, or part thereof that affects its safety function, that was not designed and manufactured as a basic component. Commercial grade items do not include items where the design and manufacturing process require in-process inspections and verifications to ensure that defects or failures to comply are identified and corrected (i.e., one or more critical characteristics of the item cannot be verified).

(2) When applied to facilities and activities licensed pursuant to 10 CFR Parts 30, 40, 50 (other than NPPs), 60, 61, 63, 70, 71, or 72, commercial grade item means an item that is:

(i) Not subject to design or specification requirements that are unique to those facilities or activities; (ii) Used in applications other than those facilities or activities; and (iii) To be ordered from the manufacturer/supplier on the basis of specifications set forth in the manufacturer's published product description (for example, a catalog).

Configurable software Software that is commercially available that allows the user to modify the functioning of the software in a limited way to suit user needs within clearly defined limits. Configurable software is an out-of-the-box solution that allows the owner to personalize certain aspects of the software themselves, without the help of experienced software developers.

Configurable software is flexible, scalable and can be continually shaped through a human-machine interface to meet and organizations industry-specific and organization-specific needs.

Control action (automatic control)

Of a control element or a controlling system, the nature of change of the output effected by the input. Note: The output may be a signal or the value of a manipulated variable. The A-2

input may be the control loop feedback signal when the command is constant, an actuating signal, or the output of another control element [A.2]

Dedicating entity (10 CFR 21.3)

When applied to NPPs licensed pursuant to 10 CFR Part 50, dedicating entity means the organization that performs the dedication process. Dedication may be performed by the manufacturer of the item, a third-party dedicating entity, or the licensee itself. The dedicating entity, pursuant to § 21.21(c) of this part, is responsible for identifying and evaluating deviations, reporting defects and failures to comply for the dedicated item, and maintaining auditable records of the dedication process.

Dedication (10 CFR 21.3)

1. When applied to NPPs licensed pursuant to 10 CFR Part 30, 40, 50, 60, dedication is an acceptance process undertaken to provide reasonable assurance that a commercial grade item to be used as a basic component will perform its intended safety function and, in this respect, is deemed equivalent to an item designed and manufactured under a 10 CFR Part 50, appendix B, quality assurance program.

This assurance is achieved by identifying the critical characteristics of the item and verifying their acceptability by inspections, tests, or analyses performed by the purchaser or third-party dedicating entity after delivery, supplemented as necessary by one or more of the following: commercial grade surveys; product inspections or witness at holdpoints at the manufacturer's facility, and analysis of historical records for acceptable performance. In all cases, the dedication process must be conducted in accordance with the applicable provisions of 10 CFR Part 50, appendix B. The process is considered complete when the item is designated for use as a basic component.

2. When applied to facilities and activities licensed pursuant to 10 CFR Parts 30, 40, 50 (other than NPPs), 60, 61, 63, 70, 71, or 72, dedication occurs after receipt when that item is designated for use as a basic component.

Dedication provides reasonable assurance that the commercially manufactured item conforms to its design and will perform its intended safety function. As noted in the introduction to 10 CFR 50, Appendix B, control under a 10 CFR 50, Appendix B-compliant QA program provides adequate confidence that a structure, system, or component will perform satisfactorily in service.

A-3

Table A-1 Control Under 10 CFR 50, Appendix B Program Vs. Dedication Under CGD

[A.1]

Control under Appendix B-Commercial grade dedication compliant QA program Original equipment manufacturer Third party / licensee Access to original design requirements Does not necessarily have access to original design requirements Knows what design requirements are important A failure modes and effects or other analysis is to ensure design functions can be performed needed to postulate critical characteristics Is verifying important design requirements Might need to use reverse engineering using Appendix B QA program controls techniques to determine acceptance criteria/tolerances Uses Appendix B controls to ensure materials Does not use Appendix B controls to ensure and parts used meet the original design materials and parts used meet the original requirements (drawings, specifications, etc.) design requirements (drawings, specifications, etc.)

Dedication is not a central tenet of QAit is an alternative acceptance method that is performed under the auspices of an Appendix B-compliant QA program.

o Dedication is an acceptance process that finds its basis in 10 CFR 50, Appendix B, Criterion VII (Table A-2)

Table A-2 Dedication is Based on Criterion VII in 10 CFR 50, Appendix B [A.1]

10 CFR 50, Appendix B, Criterion VII, Control of Purchased Material, Equipment, EPRI 3002002982 and Services Measures shall be established to assure that Method 2 - Commercial Grade Survey purchased material, equipment, and services, Method 4 - Item/Supplier performance whether purchased directly or through Method 3 - Source Surveillance contractors and subcontractors, conform to the Method 1 - Special Tests and Inspection procurement documents. These measures shall include provisions, as appropriate, for source evaluation and selection, objective evidence of quality furnished by the contractor or subcontractor, inspection at the contractor or subcontractor source, and examination of products upon delivery. . .

Digital component (RIS 2016-05)

Digital components include executable code or software-developed programmable logic that is permanently or semi-permanently installed within the device (commonly referred to as firmware). [A.15]

A-4

Dumb instruments Dumb instruments do not feature a microprocessor, firmware or similarly contrived performance. They include simple mechanical pressure switches and older design transmitters based on op-amps, etc. [A.19].

Embedded digital device A component consisting of one or more digital electronic parts that use software, software-developed firmware, or software-developed logic that is integrated into plant equipment

[A.16].

Firmware The combination of a hardware device and computer instructions and data that reside as READ-ONLY software on that device. The software cannot be readily modified under program control [A.17].

Firmware refers to a small piece of code that can reside in non-volatile memory. [A.18]

Non-modifiable non-configurable firmware is deliverable as an integral part of the items, where the computer instructions and data can only be modified by replacement of the hardware device. Firmware that can change features based on changes to a configuration baseline is considered configurable software.

Non-modifiable configurable firmware is delivered as an integral part of the items, with a limited ability to adjust functionality by modifying configuration parameters, via a set-up process.

Modifiable-configurable firmware is delivered as an integral part of the items, where the computer instructions and data can be modified, including at run time.

RIS 2016-05 [A.15] states that Firmware includes, but may not be limited to, devices such as programmable logic devices, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), erasable programmable read only memory (EPROM),

electrically erasable programmable read only memory (EEPROM), and complex programmable logic devices (CPLDs).

Function A function is a defined objective or characteristic action of a system or component. For example, an I&C system may have inventory control as its primary function [A.2]. A plant function is an I&C function to control, operate, and/or monitor a defined part of a process.

An I&C function may be subdivided into a number of subfunctions (for example, measuring function, control function, actuation function) for the purpose of allocation to I&C systems

[A.3].

Functionality A-5

Functionality attributes identify significant functional activities and actions that are performed by the EDDs. This attribute addresses the functionality provided by an EDD that enables the implementation of its functions.

To understand functionality, the uses of the terms functionality, function, safety, and safety-related must be understood. From this, the functionality of the EDD can be understood in its proper perspective.

Functionality includes the capabilities of the various computational, user interface, input, output, data management, and other features provided by a digital product (i.e., platform)

[A.2].

Functionality represents the operations that must be carried out [A.4]. Functions generally transform input information into output information. Inputs may be obtained from sensors, operators, other equipment, or other software. Outputs may be directed to actuators, operators, other equipment, or other software.

HAL (hardware abstraction layer)

HAL is a layer of programming that allows a computer operating system to interact with a hardware device at a general or abstract level rather than at a detailed hardware level

[A.22]. Thus, HAL allows desktop applications to discover and use the hardware of the host system.

The application programming interface (API), enables software modules to communicate with each other by using common objects and data exchange mechanisms [A.23],

regardless of the type of the underlying hardware.

Important to safety The term important to safety is not defined in 10 CFR 50.2 or in the NRC glossary; however, for electric equipment the term important to safety is defined in 10 CFR 50.49(b) as comprising equipment that (b)(1) is safety-related, (b)(2) is not safety-related, but the failure of which could impact safety, and (b)(3) certain post-accident monitoring equipment as described in Regulatory Guide 1.97.

Limited functionality A device of limited functionality has the following characteristics [A.8]:

• It contains predeveloped software or programmed logic;

• It is autonomous and performs only one conceptually simple principal function, which is defined by the manufacturer and which is not modifiable by the user;

• It is not designed to be reprogrammable;

• If it is reconfigurable, the configurability is limited to parameters relating to compatibility with the process being monitored or controlled, or interfaces with connected equipment.

A-6

Middleware The use of middleware isolates the applications software and the operating system. The middleware is a layer of software that is between and interfaces with both the operating system (OS) and the applications software [A.24]. Thus, all interactions between the applications software and the OS take place through the middleware. Middleware is an effective technique for isolating safety-critical functionality.Not safety related Not safety related is commonly referred to as nonsafety or nonsafety related.

Open-loop control system (general)

A system in which the controlled quantity is permitted to vary in accordance with the inherent characteristics of the controlsystem and the controlled power apparatus for any given adjustment of the con troller. Note: No function of the controlled variable is used for automatic controlof the system. It is not a feedback control system [A.2].

Plant function A plant function is an I&C function to control, operate, and/or monitor a defined part of a process. An I&C function may be subdivided into a number of subfunctions (for example, measuring function, control function, actuation function) for the purpose of allocation to I&C systems [A.3].

Process variable Safety limits, which are chosen to maintain the integrity of physical barriers, can be defined in terms of directly measured process variables [A.25]. Those parameters or quantities that are controlled at the correct limit are called Process Variables [A.26].

Because process variables change, instrumentation systems measure the variable then control the variable to keep the variable within the given limits. Process variables are part of a process/system that is being monitored and/or controlled. Pressure, temperature, flow and level are examples of process variables.

Qualification ISL defined qualification as used in industry practice as follows [A.5]:

Qualification: (1) As used in the aerospace industry, qualification is a systematic process through which software tools are verified to be suitable for their intended use(s) and to the extent possible, to be free of deficiencies that could adversely affect critical DI&C system software or result in failure to detect deficiencies in that software.

Quality Assurance 10 CFR 50, Appendix B establishes quality assurance (QA) requirements for the design, manufacture, construction, and operation of those structures, systems, and components.

The pertinent requirements of this appendix apply to all activities affecting the safety-related functions of those structures, systems, and components; these activities include designing, purchasing, fabricating, handling, shipping, storing, cleaning, erecting, installing, inspecting, testing, operating, maintaining, repairing, refueling, and modifying.

A-7

As used in this appendix, the term quality assurance comprises all those planned and systematic actions necessary to provide adequate confidence that a structure, system, or component will perform satisfactorily in service. QA includes quality control (QC), which comprises those QA actions related to the physical characteristics of a material, structure, component, or system which provide a means to control the quality of the material, structure, component, or system to predetermined requirements.

Risk-significant Risk-significant licensing basis events are those with frequencies within 1% of the Frequency-Consequence Target with site boundary doses exceeding 2.5 mrem. The use of the 1% metric is consistent with the approach to defining risk-significant event sequences in the PRA standards.

Safety function A safety function is one of the processes or conditions (e.g., negative reactivity insertion, emergency core cooling system [ECCS], containment isolation) essential to maintaining plant parameters within acceptable limits established for a design basis event [A.6, A.7, A.8].

Safety-related 10 CFR 50.2 defines safety related SSCs in terms of reliance on those SSCs to remain functional during and after design basis events.

The term safety-related is used to describe systems that are required to perform a specific function or functions to ensure risks are kept at an accepted level. Such functions are, by definition, safety functions. Any system, implemented in any technology, which carries out safety functions is a safety-related system. Two types of requirements are necessary to achieve functional safety [A.9]:

• safety function requirements (what the function does), and

• safety integrity requirements (the likelihood of a safety function being performed satisfactorily).

Safety-related SSC Safety-related SSCs describes those SSCs that are relied upon to remain functional during and following design basis events to assure [A.10]:

1. The integrity of the reactor coolant pressure boundary

2. The capability to shut down the reactor and maintain it in a safe shutdown condition; or

3. The capability to prevent or mitigate the consequences of accidents which could result in potential offsite exposures comparable to the applicable guideline exposures set forth in § 50.34(a)(1) or § 100.11 of this chapter, as applicable.

A-8

Safety significant function 10 CFR 50.69 defines a safety significant function as A function whose degradation or loss could result in a significant adverse effect on defense-in-depth, safety margin, or risk. Thus, systems that are highly safety significant are those whose failure can result in high consequences [A.11].

The safety-significant function in 10 CFR 50.69 does not replace the existing safety-related and non-safety-related categorizations. Rather, 10 CFR 50.69 divides these categorizations into two subcategories based on high or low safety significance that blends risk insights into the categorization process.

Software failure IEC 61513 for NPP I&C systems [A.3] defines a software failure as a system failure due to activation of a design fault in a software component. It is noted in the standard that [a]ll software failures are due to design faults, since software consists solely of design and does not wear out or suffer from physical ffailure. Since the triggers which activate software faults are encountered at random during system operation, software failures also occur randomly. See also failure, fault, software fault in IEC 61513 [A.3].

Solid-state device Solid-state gets its name from the path that electrical signals take through solid pieces of semi-conductor material [A.27]. Solid-state devices, such as a transistor, use conductors to control the flow of signals through a circuit. An integrated circuit (IC) chip is a collection of transistors and wires that hook them together.

A.1 REFERENCES A.1 M. H. Tannenbaum and J. Simmons, Control of Items Under 10 CFR 50, Appendix B With, and without, commercial grade item dedication, NRC Workshop on Vendor Oversight, June 14, 2018. (ADAMS Accession No. ML18150A371)

A.2 IEEE Std. 100-2000, Authoritative Dictionary of IEEE Standards Terms, Institute of Electrical and Electronics Engineers, Piscataway, NJ, 2000.

A.3 International Electrotechnical Commission, Nuclear Power PlantsInstrumentation and Control for Systems Important to SafetyGeneral Requirements for Systems, IEC 61513, Geneva, Switzerland, August 2011.

A.4 U.S. NRC SRP BTP 7-14,Rev. 6,Guidance on Software Reviews for Digital Computer-Based Instrumentation and Control Systems. (ADAMS Accession No. ML16019A308)

A.5 J. Servatius, S. Alexander, and T. Gitnick, Evaluation of Guidance for Tools Used to Develop Safety-Related Digital Instrumentation and Control Software for NPPs, Task 2 Report: Analysis of the State of Practice, ISL-ESRD-TR-14-03, August 2014. (ADAMS Accession No. ML15043A206)

A.6 EPRI TR-103669-V1, Programmable Logic Controller Qualification Guidelines for Nuclear Applications, Volume 1: Technical Information and Guidelines, Electric Power Research Institute, Palo Alto, CA, October 1994.

A-9

A.7 International Atomic Energy Agency, Safety of Nuclear Power Plants: Design, IAEA Safety Standard Series Requirements NS-R-1 :2016, Vienna, 2016.

A.8 International Atomic Energy Agency, Design of Instrumentation and Control Systems for Nuclear Power Plants, IAEA Specific Safety Guide No. SSG-39, Vienna, 2016.

A.9 International Electrotechnical Commission, Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 0: Functional safety and IEC 61508, IEC/TR 61508-0:2005, Geneva, Switzerland, September 2005.

A.10 10 CFR 50.2, Definitions.

A.11 10 CFR 50.69, Risk-informed categorization and treatment of structures, systems and components for nuclear power reactors.

A.12 International Electrotechnical Commission, Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 4: Definitions and abbreviations, IEC 61508-4, Geneva, Switzerland, 2010.

A.13 ISO/IEC/IEEE 24765, Systems and software engineering Vocabulary,, International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC) /

Institute of Electrical and Electronic Engineers (IEEE), Geneva, Switzerland, 2010.

A.14 Dictionary.com, Automation. https://www.dictionary.com/browse/automation A.15 U.S. NRC RIS 2016-05, Embedded Digital Devices in Safety-Related Systems, April 29, 2016. (ADAMS Accession No. ML15118A015)

A.16 E. O. Eagle Jr., U.S. NRC Office of New Reactors, Embedded Digital Device Issue in Plant Safety and Design Certification, November 2013. (ADAMS Accession No.ML13317A004)

A.17 U.S. Department of Defense, Standard Practice for System Safety, MIL-STD-882E, 11 May 2012.

A.18 M. Rouse, DEFINITION embedded system.

https://internetofthingsagenda.techtarget.com/definition/embedded-system A.19 T. S. Nobes, Smart Instruments in Safety Instrumented systemsSellafield Experiences, Measurement + Control, Vol 41/6, July 2008.

https://journals.sagepub.com/doi/pdf/10.1177/002029400804100603 A.20 IEEE/EIA 12207.1-1997, Information technologySoftware life cycle processesLife cycle data, Institute of Electrical and Electronics Engineers, Piscataway, NJ, April 1998.

A.21 Radio Technical Commission for Aeronautics, Software Considerations in Airborne Systems and Equipment Certification, RTCA DO-178C, December 2011.

A.22 M. Rouse, Hardware Abstraction Layer (HAL).

https://whatis.techtarget.com/definition/hardware-abstraction-layer-HAL A.23 IEEE Std C37.1-2007, IEEE Standard for SCADA and Automation Systems, Institute of Electrical and Electronics Engineers, Piscataway, NJ, May 8, 2008.

A-10

A.24 U.S. Department of Defense, Joint Software Systems Safety Engineering Handbook, Version 1.0, Published August 27, 2010.

A.25 T. [Edward) Quinn, J. Mauck, R. Bockhorst, and K. Thomas, Digital Sensor Technology, INL/EXT-13-29750, July 2013.

A.26 Sivaranjith, What is process variable and types of process variables?, Automation Forum, December 2017. https://automationforum.in/u/sivaranjith A.27 What does solid-state mean in relation to electronics?, How stuff works.

https://electronics.howstuffworks.com/questions558.htm A-11

APPENDIX B COMPONENT TYPES Eighteen types of components were identified as likely to have connected or internal EDDs and be used in NPPs in safety related applications (Table B-1). This list is not a complete list of components that may include EDDs, but a down-selection process was necessary to determine the widespread use of EDDs and how they are used.

This process focused on vendors and devices positioned to be included in nuclear power plants in the near term. Vendors operating outside of the nuclear industry in less safety critical applications are known to use more complex functionality in their EDDs than described in the sections below.

In the down-selection process, services (non-components), passive components (e.g., piping),

and structural components (including cable trays) were removed from further review.

Table B-1 Types of Components in Safety Related Applications in NPPs Likely to have EDDs Chart (data) recorders Priority logic modules Circuit breakers Pumps Diesel generators Radiation monitors Flowmeters Relays, time-delay relays Gas analyzers Temperature transmitters Level meters Uninterruptible power supplies (UPSs)

Motor control centers (MCCs) Valve actuators Power supplies Valves Pressure transmitters Voltage regulators B.1 Chart Recorder The vendor search identified four vendors of chart recorders and data readout devices that have also designed, built, and installed an I&C system at an NPP. A focused survey of these vendors was performed to identify the usage of EDDs in chart recorders and to determine the types of functional roles allocated to the devices.

Digital chart recorders are examples of a component that can have multiple functions. Chart recorders use video display units (VDUs) to display information to operators and touch screens to provide parameter, display, and alarm control. The data from the recorders can be made available using various communications protocols to other users.

The digital chart recorders identified through this search emulated their analog replacements. For example, the trend graphs on the VDUs look like the output from analog trend or strip-chart recorders. Not surprisingly, the human systems integration (HSI) provided by most man-machine interface system (MMIS) vendors today simply makes the analog HSI equipment into similar looking images on digital VDUs [B.1]. Few vendors seem to re-think the problem of process data display and control when moving to digital technologies. In fact, the digital upgrade of Mission Control Center (MCC) at the Johnson Spaceflight Center can provide insights for the nuclear B-1

industry with respect to displaying information and the use of chart recorders. Insights from the conversion of the MCC from analog to digital include the following [B.2]:

• The older, more experienced flight controllers preferred the mainframe/monochrome system, while the new controllers preferred the real-time data system color workstations.

• Having color graphics workstations that emulated the old displays wasted much of the color graphics capability.

• The original displays in the prototype system presented a large and potentially bewildering amount of information to the flight controller.

• High reliability is achievablethe new MCCs operate around the clock and ideally have no more than 20 minutes of downtime a year.

The advantages of digital chart recorders are that they can provide multiple displays that can be sequential or channel-selected digital indication of the channel readings and provide the operator interface for configuration. Alarms indicate an alarm condition on any display. With digital technology, microprocessors can be used to make ongoing controller adjustments based on the actual, real time process dynamics. Thus, the functionality of chart recorders can be greatly increased over the alanog counterparts.

The chart recorders may be used in safety related applications. For example, Yokogawa Corporation of Americas chart recorders [B.3] have been qualified under a 10 CFR 50, Appendix B program and can monitor and record up to 4, 12, 48 or 500 channels of data. These recorders, because they are recording data to be stored and analyzed, can have greater connectivity through a flash card slot, USB port, and ethernet connection.

B.2 Circuit Breakers The vendor search identified 23 vendors of circuit breakers; of these, 5 have also designed, built, and installed an I&C system at an NPP. A focused survey of these vendors was performed to identify the usage of EDDs in circuit breakers and to determine the types of functional roles allocated to the devices.

Engineers from a major industry supplier provided an overview on the availability and use of embedded digital components or piece parts of low voltage circuit breakersidentified as smart or intelligent devices. If desired, their low voltage circuit breakers may incorporate embedded digital equipment such as ASICs or microprocessors to provide (1) monitoring functions or (2) monitoring and control functions. Equipment diagnostics to ascertain component health and reliability are available using manufacturer-specific software.

For medium voltage circuit breakers, digital monitoring or control may be implemented via smart protective relays.

Low voltage circuit breakers equipped with embedded digital control features are capable of full control based on values of desired parameters, such as voltage, current, frequency, power factors, diagnostic results, etc. Circuit breakers equipped with embedded digital monitoring features may display similar parameters of interest, such as current, voltage, frequency, power factors, diagnostic results, etc. Control logic and monitoring features may be modified via local access at the device or from remote network access based on the customers requirements.

B-2

Medium voltage circuit breakers equipped with embedded digital control features implemented via smart or intelligent protective relays located either at or distant to the circuit breaker are capable of full control based on values of selected parameters, such as current, voltage, frequency, power factors, diagnostic results, etc. Circuit breaker protective relays equipped with embedded digital monitoring features may display similar parameters of interest, such as current voltage, frequency, power factors, diagnostic results, etc. Control logic and monitoring features may be modified via local access at the device or from remote network access based on the customers requirements.

Communications capabilities with the embedded digital equipment are available for common network types and topologies. Broadcast messages to groups of devices are not permitted; each device must be individually specified. By default, no configuration changes are allowed on operating devices; however, this may be overridden by the customer.

The embedded digital equipment may perform the logic operations or an external device (e.g.,

PLC) may perform the logic operations. Degrees of embedded equipment or external devices performing the logic operations are supported. For example, a PLC may be the primary controller, but the embedded equipment could pick up control functions in the event of a PLC or communications failure.

One supplier that was contacted writes its own firmware in-house for circuit breakers, which is typically implemented on dedicated IC chips. A style label is used with the component model number for configuration control purposes. Any change in form, fit, or function prompts a repeat of their system testing. It is not clear how field modifications would affect the style number and configuration control.

Vendors indicated they perform an extensive range of factory acceptance testing that would be made available depending on customer requirements, and they could include job-specific failure modes and effects analyses if needed.

Many of the suppliers contacted typically use third-party commercial grade dedicating entitys for equipment to be used in NPPs.

B.3 Diesel Generators The vendor search identified 16 vendors of diesel generators; of these, 3 have also designed, built, and installed an I&C system at an NPP. A focused survey of these vendors was performed to identify the usage of EDDs in diesel generators and to determine the types of functional roles allocated to the devices.

Diesel generators are complex devices requiring numerous control and monitoring systems, such as engine starting, fuel, speed control, cooling, and lubrication systems, plus electrical load sequencing and voltage regulation.

B.3.1 DG Transfer Switches Engineers from a major industry supplier provided an overview on the availability and use of embedded digital components or piece parts of DG transfer switches: smart or intelligent devices.

If desired, transfer switches may incorporate embedded digital equipment such as ASICs or microprocessors to provide (1) monitoring functions or (2) monitoring and control functions.

Equipment diagnostics to ascertain component health and reliability are available using manufacturer-specific software.

B-3

Transfer switches equipped with embedded digital control features are capable of full control based on values of desired parameters, such as current, voltage, frequency, power factors, diagnostic results, etc. Transfer switches equipped with embedded digital monitoring features may display similar parameters of interest such as current, voltage, frequency, power factors, diagnostic results, etc. Control logic and monitoring features may be modified via local access at the device or from remote network access based on the customers requirements.

Communications capabilities with the embedded digital equipment are available for common network types and topologies. Broadcast messages to groups of devices are not permitted; each device must be individually specified. By default, no configuration changes are allowed on operating devices; however, this may be overridden by the customer.

The embedded digital equipment may perform the logic operations or an external device (e.g.,

PLC) may perform the logic operations. Degrees of embedded equipment or external devices performing the logic operations are supported. For example, a PLC may be the primary controller, but the embedded equipment could pick up control functions in the event of a PLC or communications failure.

One supplier contacted writes its own firmware in-house for DG transfer switches, which is typically implemented on dedicated IC chips. A style label is used with the component model number for configuration control purposes. Any change in form, fit, or function prompts a repeat of their system testing. It is not clear how field modifications would affect the style number and configuration control.

An extensive range of factory acceptance testing is available depending on customer requirements and could include job-specific failure modes and effects analyses, if needed.

Many of the suppliers contacted typically use third-party commercial grade dedicating entitys for equipment to be used in NPPs.

B.4 Flowmeter The vendor search identified seven vendors of flowmeters that have also designed, built, and installed an I&C system at an NPP. A focused survey of these vendors was performed to identify the usage of EDDs in flowmeters and to determine the types of functional roles allocated to the devices.

Flow meters can be magnetic, coriolis, or vortex flow meters.

Magnetic flow meters are also known as electromagnetic flow meters or mag meters, and they are comprised of a transmitter and sensor that together measure flow. The magnetic flow meters sensor is placed inline and measures an induced voltage generated by the fluid as it flows through a pipe. The transmitter takes the voltage generated by the sensor, converts the voltage into a flow measurement, and transmits that flow measurement to a control system.

Vortex flow meters do not use impulse lines, and there are no moving parts to maintain or repair, less leak potential, and a wide flow turndown range. Vortex meters can be used in remote areas.

Additionally, vortex meters are unique in that they can accommodate liquids, gasses, steam and corrosive applications. Vortex flow meters are also able to withstand high process pressures and temperatures. An integral temperature sensor enables temperature compensated mass flow for B-4

saturated steam. Mass flow, volumetric flow, or temperature are available as configurable outputs.

Coriolis flow meters are composed of a sensor, which contains the measurement tubes, and a transmitter, which displays the outputs and allows the meter to be configured to the process.

Coriolis flow measurement can provide simultaneous measurement of mass flow, density, temperature and viscosity. A coriolis flowmeter has one or more measuring tubes which an exciter causes to oscillate artificially. As soon as the fluid starts to flow in the measuring tube, additional twisting is imposed on this oscillation due to the fluids inertia. Two sensors detect this change of the tube oscillation in time and space as the phase difference. This difference is a direct measure of the mass flow. In addition, the fluid density can also be determined from the oscillation frequency of the measuring tubes. The temperature of the measuring tube is also registered to compensate thermal influences. The process temperature derived from this is available as an additional output signal.

The flow meters provide diagnostics to monitor component health and an operator display. Flow meters for use in process industries can provide smart wireless adapters with communication capabilities.

B.5 Gas Analyzers The vendor search identified 26 vendors of gas analyzers; of these, 3 have also designed, built, and installed an I&C system at an NPP. A focused survey of these vendors was performed to identify the usage of EDDs in gas analyzers and to determine the types of functional roles allocated to the devices.

An engineer with a major industrial vendor of H2/O2 gas analyzers for 1E Containment Atmosphere Monitoring System (CAMS) provided an overview of their design and production processes. The gas analyzers measure gas concentrations in containment from 500 ppm to 100%.

The design of the gas analyzers uses ANSI/ASME NQA-1-2000 to meet the 10 CFR 50 Appendix B criteria. Seismic, environmental, and EMI testing of the gas analyzers follow NRC endorsed standards.

The system is arranged into two assemblies, a remote control center and a sample station assembly. The remote control center includes a PLC-based control and conditioning assembly, a touch screen display, and a system switch panel. The remote control center is designed for mild environment locations, and the sample station is designed for operation in the harsh post-accident conditions.

During normal operating conditions, the gas analyzers are in direct contact with the sample.

During post-accident conditions, the containment atmosphere includes super-heated steam. By terminating the heat trace on the inlet sample line upstream of the analyzer ~8 feet, the temperature in the sample line cools down to the dew point.

The CAMS takes analog input from sensors within containment and then uses the PLC to determine H2 partial pressure and total pressure. An analog signal is then sent to the control room for an alarm on high hydrogen partial pressure or if high total pressure occurs. The alarm values are plant specific per technical specifications. Plant response is also plant specific (operator actions for turning fans on, venting, hydrogen recombiners, etc.).

B-5

The PLC assembly provides all on-off control logic for the sample loop assembly and data processing for the sensors. The conditioner performs the necessary calculations and outputs the results in three forms: analog signals, a visual indication, and alarms.

The PLC is provided to the vendor by a supplier and is programmed with proprietary software.

The PLC includes a set of modules selected to process data accumulated from the local analyzer sample station, provide logic output for operation of all sample station ON-OFF functions, and provide information to the field in the forms of analog output signals, alarm contact closures, and as a visual display.

B.6 Level Meter The vendor search identified seven vendors of level meters that have also designed, built, and installed an I&C system at an NPP. A focused survey of these vendors was performed to identify the usage of EDDs in level meters and to determine the types of functional roles allocated to the devices.

Water level measurements in nuclear applications include level measurements in fuel pools, vessels, and sumps. Wireless transmission of its output signal can allow the transmitters to be installed in accessible indicator location(s) using either wired or wireless technology.

Intelligent buoyancy/displacement transmitters are designed to measure liquid level, interface, or density of liquids based on the Archimedes buoyancy principle. Buoyancy level sensors and switches include horizontal floats, vertical floats, and displacer switches of all kinds. Displacement instruments determine liquid level by sensing the buoyant force exerted on a displacer by the liquid it displaces, unlike float-type level instruments, in which the displacer moves very little relative to the rising or falling liquid.

Water (or liquid) levels can also be measured by ultrasonic technology. Unlike typical sight-glass or differential pressure indications using long runs of tubing, the ultrasonic technology is not susceptible to erroneous readings caused by air accumulation or constrictions in the tubing.

Ultrasonic technology is not sensitive to differing pressures, such as would be experienced during RCS vacuum refill evolutions.

Guided wave radar (GWR) sensors, both permanently installed is another level measurement technology for a wide variety of process media and conditions, including water at saturation (boiling) conditions.

Many level measurement instruments are microprocessorbased that communicate liquid level, specific gravity (density), and liquid level interface. HART or FOUNDATIONTM Fieldbus communications protocols are standard protocols. An HMI interface provides access to information, easy remote configuration and supervision with a PC or HART terminal or by using the local keys.

B.7 Motor Control Centers (MCCs)

The vendor search identified 18 vendors of MCCs; of these, 5 have also designed, built, and installed an I&C system at an NPP. A focused survey of these vendors was performed to identify the usage of EDDs in MCCs and to determine the types of functional roles allocated to the devices.

B-6

Engineers from a major industry supplier provided an overview on the availability and use of embedded digital components or piece parts of MCCs: smart or intelligent MCCs. If desired, their MCCs may incorporate embedded digital equipment such as ASICs or microprocessors to provide (1) monitoring functions or (2) monitoring and control functions. Equipment diagnostics to ascertain component health and reliability are available using manufacturer-specific software.

MCCs equipped with embedded digital control features are capable of full controlstart, stop, control based on values of desired parameters, such as voltage, current, frequency, power factors, diagnostic results, etc. Control logic and monitoring features may be modified via local access at the device or from remote network access based on the customers requirements.

Communications capabilities with the embedded digital equipment in the MCCs are available for common network types and topologies. Broadcast messages to groups of devices are not permitted; each device must be individually specified. By default, no configuration changes are allowed on operating devices; however, this may be overridden by the customer.

The embedded digital equipment may perform the logic operations or an external device (e.g.,

PLC) may perform the logic operations. Degrees of embedded equipment or external devices performing the logic operations are supported. For example, a PLC may be the primary controller, but the embedded equipment could pick up control functions in the event of a PLC or communications failure.

One supplier contacted writes its own firmware in-house, which is typically implemented on dedicated IC chips. A style label is used with the component model number for configuration control purposes. Any change in form, fit, or function prompts a repeat of their system testing. It is not clear how field modifications would affect the style number and configuration control.

An extensive range of factory acceptance testing is available depending on customer requirements and could include job-specific failure modes and effects analyses, if needed.

Many of the suppliers contacted typically use third-party commercial grade dedicating entitys for equipment to be used in NPPs.

As an example of the functionality of the MCCs, the display system for the Siemens tiastar (not capitalized by Siemens) Smart Motor Control Center with SmartStart displays the data for the following [B.4]:

• SIMOCODE pro for full-voltage non-reversing and reversing starters

• Siemens variable frequency drives

• SIRIUS 3RW44 soft starters

• Siemens WL circuit breaker

• The display panel emulates the front view of the MCC.

The tiastar Smart MCC also provides control for each starter device via:

• SmartStart control station mounted in the MCC

• Field-mounted 120 VAC pilot devices

• Ethernet-connected PLC/DCS system B-7

B.8 Pressure Transmitters The vendor search identified 43 vendors of pressure transmitters; of these, 8 have also designed, built, and installed an I&C system at an NPP. A focused survey of these vendors was performed to identify the usage of EDDs in pressure transmitters and to determine the types of functional roles allocated to the devices.

An engineer with a major industrial vendor of nuclear and commercial grade instrumentation and valves provided an overview of their design and production processes. As an illustration of the size of the vendor, product literature notes over 10 million of a particular model pressure transmitter have been installed worldwide. For nuclear applications, 10 CFR 50 Appendix B criteria govern all processes. For non-nuclear applications, processes are ISO 9001 compliant.

For both nuclear and non-nuclear use, significant product testing takes place, including intensive audits of a fraction of the production run to ensure all performance specifications are met.

Digital components make up a large share of the non-nuclear commercial market, with increasing penetration since the 1990s. Wireless communications are widely available in commercial products and provide productivity and diagnostics elements. ASICs to meet design specifications are used in some applications. The vendor assembles its own boards or procures pre-populated boards for which individual parts are specified. The vendor does its own programming of its digital devices and systems. Process controls of comparable levels are used for both software and circuit board products. Design and bill of material revisions are conducted under traceability requirements that include model numbers, serial numbers, and date codes.

B.9 Priority Logic Modules The vendor search identified 5 vendors of priority logic modules (PLMs); of these, 3 have also designed, built, and installed an I&C system at an NPP. A focused survey of these vendors was performed to identify the usage of EDDs in PLMs and to determine the types of functional roles allocated to the devices.

PLMs are an interface between actuators and multiple commanding systems (e.g., safety, control, manual). Section 2 of DI&C-ISG-04 refers to these devices as priority modules [B.5].

A PLM receives device actuation commands from multiple safety and non-safety sources and sends the command having highest priority on to the actuated device (Figure B-1). Priority logic is implemented with software, firmware, or a combination. Logic is required to determine which incoming command has priority to control safety equipment in order to meet NRC requirements.

The actuated device can be a safety-related component such as a motor actuated valve, a pump motor, a solenoid-operated valve, etc. The priority module must also be safety related.

Arevas AV-42 Priority Logic Module was to be the central interface in the protection system and was also referred to as a priority control module (Figure B-1). The Taiwan 1&2 plants have numerous AV-42 modules actuating 627 outputs [B.6].

B-8

Figure B-1 AV-42 Priority Logic Module Invensyss Triconex PLM receives diverse actuation commands from 1E-qualified safety and nonsafety sources such as safety systems, diverse systems, emergency control panels, and the operators normal HMI. Once received, the PLM sends the highest priority command to an actuation device such as a solenoid valve or a pump motor.

A PLM is also known as a component interface module (CIM) used in the APR1400. A CIM at the APR1400 is used, among other things, to interface the output signals from the engineering safety features-component control system (ESF-CCS) digital controllers to the plants safety components (e.g., pumps, valves, dampers) to allow control of each component based on automatic safety actuation signals and manual safety actuation signals from plant operators. For most applications, a single CIM controls a single engineered safety feature (ESF) plant component.

Each CIM is used to control one plant component.

A PLM may be considered different than an EDD. Both can be hardware or software (firmware) and can provide diagnostics, communication, and monitoring. However, the PLM has multiple inputs and the output is based on the priority of the inputs.

The key component in the CIM design is a FPGA. Its first use is within the Westinghouse AP1000 nuclear reactor protection and safety monitoring system. The CIM incorporates advanced features to allow for diagnostics, testability, and modularity. The main features of the CIM include:

• Command prioritization and component control for discrete plant components

• I/O for control of plant component, indication of component status and connection to plant systems

• Serial communication protocols for a reduction in hard-wired interfaces

• Online testing capabilities for rapid indication of component faults and assistance in troubleshooting and plant maintenance B-9

• Local control and indications provide additional test and troubleshooting capabilities B.10 Power Supplies The vendor search identified six vendors of power supplies that have also designed, built, and installed an I&C system at an NPP. A focused survey of these vendors was performed to identify the usage of EDDs in power supplies and to determine the types of functional roles allocated to the devices.

Smart panels enable users to pinpoint overloads and inefficiencies proactively. Ethernet connections allow the smart panels to communicate to users directly and to manage electrical distribution assets in different locations. Data provided include energy information, as well as physical properties, including trip status, cycle count, and contact wear indicators.

Power conditioners (also known as a line conditioners or power line conditioners) are devices that can be used to improve the quality of the power that is delivered to electrical load equipment.

When combined with voltage regulation, it provides noise filtering capabilities and surge protection to safeguard connected equipment against damage, degradation, or malfunction. Power conditioners filter the high frequency noise on the AC line. Circuit breakers, input filters, etc., can be interfaced in a power conditioning unit, depending on the application conditions and ripple current. None of the power conditioners reviewed had ethernet or communications capabilities.

The power supplies reviewed had internal diagnostics with visual diagnostic LEDs for input, and some had output status LEDs rather than an HMI, while others had a display that indicated voltages and currents simultaneously. The HMI screens can log data over time on one or more outputs to provide energy consumption over time. Some power supplies can be connected to a PC via an ethernet cable, allowing the test sequences to be automated and users to access data results. Data can then be exported to popular tools such as MATLAB and Microsoft Excel or Word for further analysis.

A power inverter, or inverter, is a power electronic device or circuitry that changes direct current (DC) to alternating current (AC). The input voltage, output voltage and frequency, and overall power handling depend on the design of the specific device or circuitry.

Surge protection devices / filters, power supplies, and UPSs can use a network protocol to interconnect control devices for data exchange.

B.11 Pumps (Pump Controllers)

The vendor search identified 59 vendors of pumps/pump controllers; of these, one has also designed, built, and installed an I&C system at an NPP. A focused survey of this vendor found their expertise to be in safety-related pumps that do not make use of EDDs. The survey was expanded to include vendors of pumps used in nuclear facilities other than those that installed an I&C system at an NPP.

Pump controllers can be used for managing pump flow and/or pressure, from full off to full on, and may incorporate flow or pressure control via varying pump speed or use of flow or pressure control valves, utilization bypass lines, etc., to help ensure the pump operates in the most efficient manner. When installed as part of an integrated control system, significant pump and system performance and reliability improvements may be achieved. Self-diagnostic capability provides pump performance and health evaluation in real time, plus historical trends and conditions.

B-10

Integrated controllers may provide responsiveness to large changes in flow or pressure and and/or precise control for small setpoint changes. Communication devices compatible with a number of standards can provide information that can be accessed anywhere along the loop.

Digital communication provides easy access to the performance and condition of the pump as well as other integrated components. Controllers may be located remotely from processes. This flexibility can reduce exposure to hazardous environments and make it easier to evaluate the condition of pumps in hard-to-reach locations. Electronics may be fully encapsulated so that they resist the effects of vibration, temperature, and corrosive atmospheres. Modular design allows critical working components to be replaced without removing field wiring or pneumatic or hydraulic tubing, if used.

One vendor responded to contacts via its website and discussed the usage of EDDs in their pumps/pump controllers, describing the types of functional roles allocated to the devices. Like the other vendor contacted, this vendor does not use EDDs on pumps used in NPPs. The vendor noted that utility customers were adamant about equipment specification and process control in order to prevent changes to their presently approved control or operability licensing basis. For non-nuclear use, the vendor noted digital monitoring for pump performance with various network connection options, with parameters such as flow, vibration, temperature, and pressure.

B.12 Radiation Monitors The vendor search identified 55 vendors of radiation monitors; of these, 4 have also designed, built, and installed an I&C system at an NPP. A focused survey of these vendors was performed to identify the usage of EDDs in radiation monitors and to determine the types of functional roles allocated to the devices.

The four vendors were contacted, and discussions were held with two. Both noted that their components widely use EDDs. One noted that it would not be practical to identify the specific components because there are too many.

Both noted applications in safety systems and non-safety systems. Components in safety systems were built to 1E and under 10 CFR 50 Appendix B or NQA-1 programs.

For general applications, one vendor mentioned several commercial power plant and research reactor implementations in the United States and noted long-term European use of digital reactor control systems. The vendor commented that the increasing performance of FPGAs was benefiting their implementation and did not carry the burden of OS software. However, they use ASICs, CPLDs, and microprocessors, as well, depending on the product. This vendor noted optical and hardwired network connections, with fiber backbones replacing prior generation master/slave configurations. In-house programming is used, as well as commercial software development tools. In-house programming was done in FORTRAN, C, or machine language.

DevTrack was one software tool noted. Product version control is maintained, as is visible through display via a menu button. Factory acceptance testing is used to confirm performance.

Customers may customize the testing program and witness the testing.

The vendor commented on difficulties in performing digital upgrades, noting a long wait for NRC approval of a research reactor digital upgrade and another research reactor operator choosing an analog upgrade because of anticipated delays for approving a digital system. The vendor also noted vendor component approval lists maintained for reactor sites and the benefit to industry in extending the vendor approvals across the industry.

B-11

The other vendor discussed layers of redundancy in components used in safety systems. The vendor noted that new chips were implemented as they became available in non-safety systems, primarily for performance benefits. The vendor employed project version control measures. For safety systems, updates were seldom required. For safety systems, devices have very limited connectivity and require validation activities. The vendor noted audits by customers, EPRI, etc.,

to ensure that requirements were met and processes were followed. Products are tested, documented, and certified as needed and required.

B.13 Relays, Time-Delay Relays The vendor search identified 14 vendors of relays and time-delay relays; of these, 4 have also designed, built, and installed an I&C system at an NPP. A focused survey of these vendors was performed to identify the usage of EDDs in relays and time-delay relays and to determine the types of functional roles allocated to the devices.

Engineers from a major industry supplier provided an overview on the availability and use of embedded digital components or piece parts of relays: smart or intelligent devices for the many types of relays they make. If desired, relays may incorporate embedded digital equipment such as ASICs or microprocessors to provide (1) monitoring functions or (2) monitoring and control functions. Equipment diagnostics to ascertain component health and reliability are available using manufacturer-specific software.

Relays equipped with embedded digital control features are capable of full control based on values of desired parameters, such as current, voltage, pressure, temperature, level, flow, frequency, power factors, diagnostic results, etc. Relays equipped with embedded digital monitoring features may display similar parameters of interest. Control logic and monitoring features may be modified via local access at the device or from remote network access based on the customers requirements.

Communications capabilities with the embedded digital equipment are available for common network types and topologies. Broadcast messages to groups of devices are not permitted; each device must be individually specified. By default, no configuration changes are allowed on operating devices; however, this may be overridden by the customer.

The embedded digital equipment may perform the logic operations or an external device (e.g.,

PLC) may perform the logic operations. Degrees of embedded equipment or external devices performing the logic operations are supported. For example, a PLC may be the primary controller, but the embedded equipment could pick up control functions in the event of a PLC or communications failure.

One supplier contacted writes its own firmware in-house. It is typically implemented on dedicated IC chips. A style label is used with the component model number for configuration control purposes. Any change in form, fit, or function prompts a repeat of their system testing. It is not clear how field modifications would affect the style number and configuration control.

An extensive range of factory acceptance testing is available depending on customer requirements and could include job-specific failure modes and effects analyses if needed.

Many of the suppliers contacted typically use third-party commercial grade dedicating entitys for equipment for use in NPPs.

B-12

B.14 Temperature Transmitters The vendor search identified 28 vendors of temperature transmitters; of these, 6 have also designed, built, and installed an I&C system at an NPP. A focused survey of these vendors was performed to identify the usage of EDDs in temperature transmitters and to determine the types of functional roles allocated to the devices.

An engineer with a major industrial vendor of nuclear and commercial grade instrumentation and valves provided an overview of their design and production processes. For nuclear applications, 10 CFR 50 Appendix B criteria govern all processes. For non-nuclear applications, processes are ISO 9001 compliant. For both nuclear and non-nuclear use, significant product testing takes place, including intensive audits of a fraction of the production run to ensure all performance specifications are met.

Digital components make up a large share of the non-nuclear commercial market, with increasing penetration since the 1990s. Wireless communications are widely available in commercial products and provide productivity and diagnostics elements. ASICs to meet design specifications are used in some applications. The vendor assembles its own boards or procures pre-populated boards for which individual parts are specified. The vendor does its own programming of its digital devices and systems. Process controls of comparable levels are used for both software and circuit board products. Design and bill of material revisions are conducted under traceability requirements that include model numbers, serial numbers, and date codes.

B.15 Uninterrupted Power Supplies (UPSs)

The vendor search identified 28 vendors of UPSs; of these, 5 have also designed, built, and installed an I&C system at an NPP. A focused survey of these vendors was performed to identify the usage of EDDs in UPSs and to determine the types of functional roles allocated to the devices.

Engineers from a major industry supplier provided an overview on the availability and use of embedded digital components or piece parts of UPSs: smart or intelligent devices. If desired, UPSs may incorporate embedded digital equipment such as ASICs or microprocessors to provide (1) monitoring functions or (2) monitoring and control functions. Equipment diagnostics to ascertain component health and reliability are available using manufacturer-specific software.

UPSs equipped with embedded digital control features are capable of full control based on values of desired parameters such as voltage, frequency, battery charge, load, etc. The UPS automatically transfers to battery mode if a utility power outage occurs or if the utility power does not conform to specified parameters. UPSs equipped with embedded digital monitoring features may display similar parameters of interest. Control logic and monitoring features may be modified via local access at the device or from remote network access based on the customers requirements. The UPS monitors the battery charge condition and reports the status on the control panel. The battery is always connected to the UPS and is ready to support the inverter should the utility input become unavailable.

Communications capabilities with the embedded digital equipment are available for common network types and topologies. Broadcast messages to groups of devices are not permitted; each device must be individually specified. By default, no configuration changes are allowed on operating devices; however, this may be overridden by the customer.

B-13

The embedded digital equipment may perform the logic operations or an external device (e.g.,

PLC) may perform the logic operations. Degrees of embedded equipment or external devices performing the logic operations are supported. For example, a PLC may be the primary controller, but the embedded equipment could pick up control functions in the event of a PLC or communications failure.

The UPS monitors its health and will automatically switch to bypass mode if it detects an overload, load fault, or internal failure. Bypass mode is an operating mode, not an alarm condition.

One supplier contacted writes its own firmware in-house. It is typically implemented on dedicated IC chips. A style label is used with the component model number for configuration control purposes. Any change in form, fit, and function prompts a repeat of their system testing. It is not clear how field modifications would affect the style number and configuration control.

An extensive range of factory acceptance testing is available depending on customer requirements and could include job-specific failure modes and effects analyses, if needed.

Many of the suppliers contacted typically use third-party commercial grade dedicating entitys for equipment for use in NPPs.

B.16 Valve Actuators The vendor search identified 57 vendors of valve actuators; of these, two have also designed, built, and installed an I&C system at an NPP. A focused survey of these vendors was performed to identify the usage of EDDs in valve actuators and to determine the types of functional roles allocated to the devices.

It is possible in many cases to automate an existing manual valve, thereby replacing an existing manual process valve into an automated on/off or control valve [B.7]. Most modern ball valves have pre-drilled mounting holes that can be used to mount the actuator without compromising the integrity of the valve.

A valve actuator may be an intermediate device between a valve controller or positioner and the valve itself that implements the command for a valve to change position or it could include its own integral processor/controller. Digital signal processing would take place in the controller or the actuator processor and could incorporate measured parameters from the valve and valve actuator, such as position, pneumatic or hydraulic pressure, motor current or voltage, etc., that relate to component condition monitoring or many system process parameters when used for control purposes. Additional discussion is provided in the next section on valves (valve controllers) due to the significant overlap of signal processing functions of valve actuators and controllers in the two sections.

B.17 Valves (Valve Controllers)

The vendor search identified 84 vendors of valves/valve controllers; of these, two have also designed, built, and installed an I&C system at an NPP. A focused survey of these vendors and several others was performed to identify the usage of EDDs in valves/valve controllers and to determine the types of functional roles allocated to the devices. Valve controllers are attached to the valve and can also be installed on existing valves.

B-14

Valve controllers can be used for throttling control and on/off control. Fully encapsulated electronics resist the effects of vibration, temperature, and corrosive atmospheres. The controllers provide quick responsiveness to large step changes and precise control for small setpoint changes. They may incorporate logic solvers to further improve performance. A communication device can provide information that can be accessed anywhere along the loop.

Digital communication provides easy access to the condition of the valve. This flexibility can reduce exposure to hazardous environments and make it easier to evaluate valves in hard to reach locations. The modular design allows critical working components to be replaced without removing field wiring or pneumatic tubing. When installed in an integrated control system, significant hardware and installation cost savings can be achieved. The self-diagnostic capability provides valve performance and health evaluation.

Diagnostics capabilities include real-time monitoring process and component parameters of the valve using on-board sensors built into or onto the valve and controller such as position, travel, supply and outlet pressure, air consumption, and internal component integrity. Alerts may be set to identify problems. Data may also be stored to support trend assessment and performance history. The collected data provide insights to the overall health of the valve and controller.

Diagnostics may run continuously or on set intervals and may be integrated over many components.

Operational performance is enhanced through improved accuracy of the digital positioner. The improved accuracy is achieved by enabling consideration of a number of factors digitally to adjust the positioner output pressure. Self-tuning features improve the dynamic response of the associated control valve resulting in better process control. The digital nature of the positioners permits remote diagnostics to be performed routinely or whenever deemed appropriate.

Implementing digital positioners on critical control valves also enables online partial stroke testing of the control valve without upsetting the normal process control. This testing provides assurance that the control valve actually moves upon demand.

For installation in high radiation areas, high temperature, etc., the controllers can be installed hundreds of feet away from the valve.

These results are similar to the NEET program results that primarily identified residential and business uses of valve controllers, with the exception that valve controllers in an NPP can be qualified for harsh environments and used in safety-related applications.

A major industrial vendor of nuclear and commercial grade instrumentation and valves was contacted and provided an overview of their design and production processes. As an illustration of the size of the vendor, product literature notes over 10 million of one model of a pressure transmitter have been installed. For nuclear applications, 10 CFR 50 Appendix B criteria govern all processes. For non-nuclear applications, processes are ISO 9001 compliant. For both nuclear and non-nuclear use, significant product testing takes place, including intensive audits of a fraction of the production run to ensure all performance specifications are met.

Digital components make up a large share of their non-nuclear commercial market, with increasing penetration since the 1990s. Wireless communications are widely available in commercial products and provide productivity and diagnostics elements. ASICs to meet design specifications are used in some applications. The vendor assembles its own boards or procures pre-populated boards for which individual parts are specified. The vendor does its own programming of its digital devices and systems. Process controls are of comparable levels for B-15

both software and circuit board products. Design and bill of material revisions are conducted under traceability requirements that include model numbers, serial numbers, and date codes.

A review of the retrofit of Fisher (Emerson) FieldVue' digital valve controllers at the Pickering nuclear station in Ontario, Canada [B.8], illustrated the benefits and the regulatory process for implementing digital valve controllers in safety significant systems of a commercial nuclear power station. The digital valve controllers, with an estimated population of two million in use worldwide per this article, replaced obsolescent equipment that was becoming more difficult and more costly to support and maintain, and it offered potential performance improvements, as well. The use of the digital controllers on safety significant valves meant that concerns with their reliability and different failure modes than analog-based controllers be examined to demonstrate that the design basis of the plant would not be affected.

B.18 Voltage Regulators The vendor search identified 8 vendors of voltage regulators; of these, 1 has also designed, built, and installed an I&C system at an NPP. A focused survey of this vendor was performed to identify the usage of EDDs in voltage regulators and to determine the types of functional roles allocated to the devices.

Engineers from one supplier contacted provided an overview on the availability and use of embedded digital components or piece parts of voltage regulators: smart or intelligent devices. If desired, voltage regulators may incorporate embedded digital equipment such as ASICs or microprocessors to provide (1) monitoring functions or (2) monitoring and control functions.

Equipment diagnostics to ascertain component health and reliability are available using manufacturer-specific software.

Voltage regulators equipped with embedded digital control features are capable of full control based on values of desired parameters, such as current, voltage, frequency, power factors, diagnostic results, etc. Voltage regulators equipped with embedded digital monitoring features may display similar parameters of interest. Control logic and monitoring features may be modified via local access at the device or from remote network access based on the customers requirements.

Communications capabilities with the embedded digital equipment are available for common network types and topologies. Broadcast messages to groups of devices are not permitted; each device must be individually specified. By default, no configuration changes are allowed on operating devices; however, this may be overridden by the customer.

The embedded digital equipment may perform the logic operations or an external device (e.g.,

PLC) may perform the logic operations. Degrees of embedded equipment or external devices performing the logic operations are supported. For example, a PLC may be the primary controller, but the embedded equipment could pick up control functions in the event of a PLC or communications failure.

One supplier contacted writes its own firmware in-house. It is typically implemented on dedicated IC chips. A style label is used with the component model number for configuration control purposes. Any change in form, fit, and function prompts a repeat of their system testing. It is not clear how field modifications would affect the style number and configuration control.

B-16

An extensive range of factory acceptance testing is available depending on customer requirements and could include job-specific failure modes and effects analyses, if needed.

Many of the suppliers contacted typically use third-party commercial grade dedicating entitys for equipment for use in NPPs.

B.19 References B.1 R. T. Wood, et. al., Emerging Technologies in Instrumentation and Controls, NUREG/CR-6812 (ORNL/TM-2003/22), March 2003 (ADAMS Accession No. ML031900433).

B.2 M. D. Muhlheim, et. al., Insights Gained for Updating an Analog I&C System to a Digital System, NPIC&HMIT 2012, San Diego, CA, July 22-26, 2012.

B.3 Yokogawa Electric Corporation, Daqstation DXAdvanced DX1000/DX2000, Bulletin 04L41B01-01E. https://web-material3.yokogawa.com/BU04L41B01-01E.pdf B.4 Siemens Industry, Inc (2016), tiastar TM Motor Control Center Catalog and Application Guide. Order No: CCPC-CATAG-0916 www.usa.siemens.com/mcc B.5 Digital Instrumentation and Controls, DI&C-ISG-04, Revision 1, Highly-Integrated Control RoomsCommunications Issues (HICRc), March 06, 2009 (ADAMS Accession No. ML083310185).

B.6 Memorandum to P. L. Hiland, from S. A. Arndt,

Subject:

Report of Foreign Travel to the International Atomic Energy Agency Technical Meeting on the Impact of Digital Instrumentation and Control Technologies on the Operation and Licensing of Nuclear Power Plants in Beijing, China from November 2-8, 2008, December 17, 2008.

B.7 R. Moore, Cross Co. How to Automate an Existing Manual Valve, Control Engineering, December 2018.

B.8 B. Fitzgerald, M. Cheng-Newsom, F. Mercaldi, Pickering Exploits Digital Valve Technology, Nuclear Engineering International, July 2015.

B-17

APPENDIX C SOFTWARE TOOLS This Appendix is provided for informational purposes and is not an evaluation of software tools, as that was not selected as an area of focus for this project. However, it is expected that the use of software tools will become more significant in the future. This will require both being able to determine that use of those tools is acceptable, but also being able to credit them as appropriate for the evidence they can produce.

C.1 Introduction Early software development methods relied on human inspection and testing for validation and verification; however, with increased automation (i.e., tool use) there is a comparable reduction in human involvement. That is, there is a tendency to rely on the software tools more. Although the use of software tools has always been a part of software development, there is a generally tendency to increase their use. When asked by ORNL, vendors indicated that they write software code by manual methods or use software tools to develop the code or for V&V depending on the customer and the application of the component.

The software in EDDs may be developed by software coders and through the use of software tools. The Information Systems Laboratories, Inc. (ISL) review of software development tools concluded that while it is unlikely that any tool can be certified as completely correct and error free, the use of a software development tool is generally considered to produce a better product than manual methods [C.1]. Many of the software tools in use have a large user base that provides feedback, are well supported, and have been in use long enough to be well tested. ISLs conclusion is that the risk of failures caused by using such a tool is less than the risk of failure from not using any tool. However, undetected faults in the automated tools or tool-assisted engineering activities may pose serious risks to nuclear safety. In either case, having a good process and consistent method to assess the safety of the software development is important to all stakeholders in the nuclear industry from equipment vendors, utility licensees, and government regulatory organizations.

C.2 Guidance Although the NRC and Industry guidance is focused on safety systems, it is applicable to the software in EDDs and throughout the software lifecycle.

C.2.1 NRC Related Guidance NRCs guidance in NUREG-0800 on the use of software tools [C.2] states that The software tool should be used in a manner such that defects not detected by the software tool will be detected by V&V activities. If, however, it cannot be proven that defects not detected by software tools or introduced by software tools will be detected by V&V activities, the software tools should be designed as Appendix B quality software itself, with all the attendant regulatory requirements for software developed under an Appendix B program.

The prospect of using commercial off the shelf (COTS) software in NPPs and the development of software design software tools is not new. NUREG/CR-6421 [C.3], published in 1996, recommends that software tools 17 be rated for safety impact, initially evaluated using assurance 16F 17 The original text of NUREG/CR-6421 references IEC 1226 and IEC 880. The new numbering system for IEC standards takes the old number + 60000 to create a new number, e.g. IEC 880 IEC 60880, and IEC 1226 IEC 61226.

C-1

methods for similar tools, and continuously evaluated during tool use. The NUREG/CR recommends that software tools could be placed in any one of the four categories depending on the tool function and the associated software classification (A, B, C, and unclassified). If a software tool can embed an error in other software important to safety, then the software tool is assigned the same category as the software in which the error can occur. If the software tool can only challenge software important to safety (e.g., exposing existing errors), then the software tool is assigned the next lower safety category. The NUREG/CR also presents prelimary COTS acceptance criteria (Table C-1).

Table C-1 Preliminary COTS Acceptance Criteria in NUREG/CR-6421 Description Risk and hazards analyses shall be used to identify system-level safety functions required.

The safety functions (if any) that the COTS product will perform shall be identified.

The COTS product shall be under configuration and change control.

The safety category of the COTS product shall be determined depending upon category A, B, or C, respectively.

SRP BTP 7-14 states that The SDP [software development plan] should require that tools be qualified with a degree of rigor and level of detail appropriate to the safety significance of the software which is to be developed using the tools. However, BTP 7-14 does not provide any specific guidance for qualifying the software tools. In short, the degree to which a tool is solely relied upon to ensure critical features are achieved, determines the degree to which it must be qualified. For example, a word processor that is used to prepare a printed paper document which is reviewed and approved, does not need to be qualified in any way because its output is independently (and completely) reviewed and approved.

BTP 7-14 does reference the software tool requirements from IEEE Std. 7-4.3.2-2003 (endorsed by Regulatory Guide 1.152, Rev. 3). IEEE Std. 7-4.3.2-2003 does not address justification for the selection of software tools and acceptance criteria for compilers, operating systems, and libraries but rather requires users to confirm the software tools are suitable for use. However, a major change implemented in the 2016 revision of IEEE 7-4.3.2 provides more specific criteria on the use of software tools used for digital devices and development of hardware, software, firmware, and programmable logic. IEEE 7-4.3.2-2016 [C.4] requires that software be developed, modified, or accepted in accordance with a software QA plan and that the software QA plan shall address the software tools used for system development and maintenance. This standard defines software tools as A sequence of instructions and commands used in the design, development, testing, review, analysis, or maintenance of a programmable digital device or its documentation.

The software tools are further specified to be either developed to a similar standard as the safety-related software or the tools be used in a manner such that defects not detected by the tools should be detected by validation and verification (V&V) activities. That is, the associated development tools should not introduce problems.

Regulatory Guides (RGs) 1.152 and 1.168 through 1.173 provide some guidance on software used in safety systems, primarily through the endorsement of various IEEE standards. RG 1.152 focuses on establishing and maintaining a secure operational environment and a secure C-2

development environment for system software. Because this guidance does not specifically address software tools, it is not clear if the software tools used to develop the software and the development environment of the software tool need to be secure for its use in developing safety-related software. That is, is the development of the software tools excluded from requiring a secure development environment. Obviously the software tools would need to be within the secure development and operating environment while in use on developing the safety related software. If the tools were dedicated through the verification option described in this section, then they would need to follow the same regulations as other safety software. IEEE 7-4.3.2 2016 includes a clause that such software tools shall be incorporated into the secure development and operational environment and controlled under configuration management.

Other ISL conclusions related to software tools and NRC include:

The NRC should consider regulatory guidance that clarifies the distinction between COTS software that becomes part of the final software product and COTS tools that are used in the software development process.

The NRC should consider regulatory guidance that requires automatically generated code to be scrutinized with the same rigor as hand-generated code.

This could be addressed in updating guidance for software development and the tools used to develop software in RG 1.152 or BTP 7-14.

ISL noted that based on its analysis of software tool qualification practices and guidance used in industry that the qualification of software tools would not fit well into the NRC regulatory framework [C.1]. If a software tool were subject to the CGD process, appropriate critical characteristic would need to be identified. Critical characteristics of software tools that could be reviewed and tested could include a review of the development process, security, and quality, and testing for determinism, simplicity, and reliability.

ISL defined qualification as used in industry practice as follows:

Qualification: (1) As used in the aerospace industry, qualification is a systematic process through which software tools are verified to be suitable for their intended use(s) and to the extent possible, to be free of deficiencies that could adversely affect critical DI&C system software or result in failure to detect deficiencies in that software.

C.2.2 Industry Practices Software tools are becoming a more major part of development forcing their consideration, and beyond that could have regulatory utility in their ability to support V&V activities. Guidance and practices show that although there is a framework for their use there are issues.

ISL noted that the overwhelming consensus of industry practice with respect to verification, validation, and qualification of software tools is that such activities are only required if (1) the software tool output is not systematically verified (i.e., the output is verified every time the tool is used), (2) the software tool automates, eliminates, or reduces activities and tasks required by software development life cycle processes, and (3) the software tool is being used to develop safety-related software [C.1].

Most industries use a graded software classification scheme to determine the rigor applied to the software development process. Some of those industries use the software classification scheme C-3

along with the type of software tool to determine the rigor necessary to verify, validate, or qualify of software tools used in the software development processes. The civil aviation industry has published a document (i.e., RTCA DO-330 [C.5]) that specifically covers software tool development and qualification including qualification of COTS software tools. The automotive industry (i.e., ISO 26262) and the European nuclear power industry (i.e., IEC 60880) recommend methods of qualifying software tools and provides guidance for those methods but lacks specific procedures for implementing the methods.

IAEA SSG-39 requires software tools to be verified and assessed consistent with tool reliability requirements, the type of tool, the potential of the tool to introduce fault or fail to make the user aware of existing faults, and the extent to which the tool may affect redundant elements of a system or diverse systems. Tools that can introduce faults or fail to detect faults need to be verified to a greater extent than other tools; however, verification is not necessary if the tool output is systematically and independently verified.

According to the former Multinational Design Evaluation Program (MDEP) Digital Instrumentation and Control Working Group (DICWG) Generic Common Position DICWG No 2 [C.6], the use of appropriate software tools can increase the integrity of the I&C development process and the software reliability by reducing the risk of introducing faults during the process. Tools can be used to capture system and software requirements; transform requirements into final system code and data; perform verification, validation, and testing; prepare and control application data; and manage and control processes. Tools can also reduce the effort required for testing and maintaining logs.

IEC 60880 [C.7] specifically addresses the use of software tools. The requirements in IEC 62138 are consistent with but less rigorous than the IEC 60880 requirements. IEC 62138 focuses efforts on tool certification and the certification of the tool development process rather than a rigorous tool qualification process. IEC 62138 [C.8] considers software tools to be support system software that is part of the system software in a typical I&C system and is either off-line or on-line (i.e.,

embedded in nonsafety support systems).

IEC 61226 [C.9] designates COTS software, including software tools, as safety class A, B, or C depending on the level of software produced and whether there exists a diverse alternative or another software tool that verifies the output. This places the same requirements for the software tools as those for the safety system requirements.

IEC 61508-7 [C.10] states that the certification of a tool will typically be certified against national or international standards. Ideally, the tools used in all development phases (specification, design, coding, testing and validation) and those used in configuration management, should be subject to certification. To date, only compilers (translators) are regularly subject to certification procedures.

IEC 61508 further notes that certified tools and certified translators are usually certified only against their respective language or process standards. And are usually not certified in any way with respect to safety.

CSA N-290.14-15 [C.11], in use by The Canadian Nuclear Safety Commission (CNSC), extends the software tool requirements of IEC 61508 and requires that the failure modes for each use of the software engineering tool should be considered and the relevant failure effects on the target software should be identified. The three-step process in Appendix D of this standard first determines the impact severity of the tool failure, the presence of any mitigating circumstances, and the assessment approach based on the first two steps.

C-4

1. The potential impact severity of the tool failure classifies the effects of failure into one of the following five categories based on its potential impact on the safety, functionality, reliability, performance, or security requirements of the related candidate product [C.11]:

a) Direct the tool has been incorporated within the candidate product, and as a result, tool failure effect can directly prevent the candidate product from meeting its requirements. Accordingly, the tool should be treated as a pre-developed digital item and shall be qualified to the same degree of rigor as the target digital item (e.g., a software library included in a custom software digital item).

b) Indirect-causal a tool failure effect can introduce errors in the candidate product which, if undetected, could result in the tool failing to meet its requirements (e.g., a compiler).

c) Indirect-preventive a tool failure effect can result in the non-detection of errors (e.g.,

during verification) in the candidate product which could result in the failure to meet its requirements.

d) Minimal a tool failure effect can have an impact on the candidate product, but no mechanism has been identified that could result in the candidate product failing to meet its requirements.

e) No impact a tool failure effect can have no impact on the candidate product in meeting its requirements.

2. Mitigating circumstances of the failure that eliminate or reduce the impact of the failure effect are divided into three groups:

a) None there are no circumstances which mitigate the impact of the failure.

b) Single there is a single, reliable mitigating activity or procedure which defends against the impact (e.g., testing, review, checksum comparison, etc.).

c) Multiple there are multiple (more than one) reliable mitigating activities or procedures which defend against the impact (e.g., different tests with overlapping coverage, a combination of verification processes and procedural factors, etc.).

3. The assessment approach (Category1, Category 2, Category 3, or 0) is identified based on the candidate products categorization, the impact severity of the tool failure, and the mitigating circumstances. For Category1, 2, or 3, the software engineering tool is treated as if it were a digital item of the identified category.

The FAA requires that all software tools be identified, validated, and addressed within the software development activities and documentation [C.12]. This software may include computer-aided software engineering (CASE) tools, data in these tools, compilers, test tools, test data, simulations, emulations, utilities, configuration management tools, databases and data files, and other software. For the FAA, software is classified based on how an error affects the software and the system that contains the software. The software classification defines the rigor necessary to demonstrate compliance with software development requirements.

C-5

The FDA guidance for medical device software [C.13] recognizes that developers are beginning to use component-based development tools and techniques. Object-oriented methodologies and the use of off-the-shelf software components hold promise for faster and less expensive software development. However, component-based approaches require very careful attention during integration. Prior to integration, time is needed to fully define and develop reusable software code and to fully understand the behavior of off-the-shelf components. Similar to other industries, FDAs guidance states that [software] tools should have a degree of quality no less than the software product they are used to develop.

DoD, in its guide for achieving reliability, availability, and maintainability [C.14], states that RAM Design Tools can be used to conduct formal design reviews and can use the specific tools for addressing RAM such as FMEA, FTA, RBD, WCCA, LCC, and Testability Analysis (TA), reliability tests, embedded diagnostic and prognostic instrumentation in the design, and a logistic support analysis.

The aerospace industry assigns software tools in a classification separate from the embedded system software, whereas the civil aviation industry classifies software tools to the same level as the software developed with the tool [C.1]. The aerospace industry classifications are based on effects of anomalous behavior of the software rather than software functionality.

In 1980, a special committee (SC-145) of the Radio Technical Commission for Aeronautics (RTCA) was created to develop guidelines for evaluating software used on aircraft. Avionics systems are not certified directly but are evaluated as part of the aircraft as a whole [C.15]. The primary method for qualifying software tools is in accordance with RTCA DO-330 [C.5]. RTCA DO-330 relies on the development, verification, and validation of software tools in accordance with a high-quality and well-organized life cycle process. Alternative tool qualification methods include using service history, exhaustive input testing, formal methods, and use of dissimilar tools. Unlike most other industries that superficially address COTS software tools, RTCA DO-330 provides a comprehensive qualification process for COTS tools that divides qualification responsibilities between the COTS developer and tool user [C.1].

The alternative tool qualification methods in RTCA DO-330 are analogous to CGI dedication when there is not much information available from the vendor beyond the published product description and a users manual, and commercial-grade surveys (EPRI Method 2) or source verifications (EPRI Method 3) are impractical leaving only special tests and inspections (EPRI Method 1) and use of supplier and product performance history (EPRI Method 4). ISL noted that RTCA DO-330 contains a tool qualification liaison process that contains similar activities and tasks as DI&C-ISG-06 to facilitate the review and approval of software tools.

Similar to other industries, NASA documents [C16, C17, C18, C19, C20, C21] state that software tools used in developing software that is used in safety-critical systems should be identified and the level of rigor associated with the verification, validation, and accreditation of software tools should be determined by the tool functions and the safety classification of the systems in which the software will be used [C.1].

BS EN 50128 [C.22] contains requirements and guidance for software tool selection, use, documentation, and qualification for the railway industry. BS EN 50128 also provides a comprehensive process for determining the confidence level in software tools used in the software development process similar to the tool qualification level used in the civil aviation industry. The BS EN 50128 safety-related software development life cycle process only depends on the tool C-6

functionality. Tools are assigned to one of three classes and all tools must be assigned to one of these classes depending on their potential to affect the executable code (Table D-2).

Table C-2 Classes of Software Tools Class Description Example T1 Tool output does not contribute to executable code Text editor Version control software (VCS)

T2 Tool tests / verifies design or executable code; Static analysis tool cannot introduce defects into the executable code, Code coverage test tool but may fail to detect existing defects T3 Tool output contributes to executable code Compiler Linker The T1 class applies to tools that affect neither the verification nor the final executable. T2 applies to tools where a fault could lead to an error in the results of verification or validation. An example of a T2 tool is a coding standard checker. T3 applies to tools which, if faulty, could introduce errors into the final executable (for example a compiler).

ISL noted that based on its analysis of industry practice, all industries should expand coverage of software tool requirements to cover software tool use in all phases of software development and all types of software tools to minimize the potential hazards of using tools [C.1]. Clause 5.3.2 of IEEE Std. 7-4.3.2-2016, revised after ISLs review, addresses the quality of software tools throughout the software lifecycle.

In Japan, a symbolic language (Problem Oriented LanguagePOL) is used to provide an intuitive structured representation of the software specifications (interlock block diagrams) that is implemented through graphically driven coding tools [C.23]. Additionally, simplicity of software structure is promoted through simple logic, cyclical execution, static resource usage, and avoidance of external interrupts. Thus, the Japanese nuclear power industry emphasizes consensus software development practices that are intended to facilitate software verification and validation as a primary means for minimizing the potential for systematic software faults.

C.3 Approved Platforms Software tools are used not only at the component level but at the system level. Examples of specific tools are provided below.

Framatome Technologies Control STAR system is a modular, digitally programmable system that is designed for safety-related applications in nuclear power plants. The Software Application Management System (SAMS) is a program generation software tool that allows the user to construct control algorithms for Control STAR using a personal computer [C.24]. SAMS is Windows-based and menu-driven, so Control STAR can be programmed by control personnel, without any special computer programming skills. Programming Control STAR simply requires selecting functional building block icons from the SAMS library and connecting them on the screen. The software converts the functional diagram to a BASIC code used by the module.

C-7

Schneider Electric used an automated software development tool called SAGA for its SPINLINE 3 system. This tool was used to develop most of the SPIN N4 software, which contains ~200,000 lines of 1E "C" code. The CLARISSE System and Software Development Environment of SPINLINE 3 includes SCADE, which is the evolution of SAGA, and all the tools to produce automatically generated executable code. The SPINLINE 3 has already been widely used on several NPPs for Safety and Safety-related applications at KOZLODUY, QINSHAN, DUKOVANY (in 2000). The previous version of the SPINLINE 3 system - the SPIN N4 - has been implemented at the N4 nuclear power plants in France (Chooz and Civaux) for RPS and RCLS.

The NRC approved the SPINLINE 3 in 2014 [C.25].

Software tools were used extensively in the development of the RadICS, which was reviewed by the NRC in its review of the RadICS Safety System Digital Platform. The RadICS Topical Report (TR) lists eight different software tool types and eleven specific software tools that are used during RadICS logic development activities. The functions of each tool are described in the TR and a tool classification is assigned based upon specific tool characteristics and usage. The TR also identifies configuration items generated for each software tool. Software tools used for RadICS function block logic (FBL) and Electronic Design (ED) development were not themselves developed in accordance with the RadICS Appendix B QA. These software tools are used in a manner such that defects not detected by the software tools will be detected by V&V activities described in the RadICS V&V Plan and corrected through the RadICS corrective action programs.

The NRC approved the RadICS in 2019 [C.26].

C.4 Conclusions Different industries, agencies, and organizations have different criteria for qualifying software tools and their use. For example, the NRC states that software tools should be used in such a manner that defects not detected by the software tool will be detected by V&V activities, but if this cannot be proven the software tool should be designated as Appendix B quality software itself. An ISL observation, based on an analysis of tool qualification practices in other industries, is that tool qualification would not fit well into the NRC regulatory framework.

IEEE Std. 7-4.3.2-2003, endorsed by RG 1.152, Rev. 3, does not address justification for the selection of software tools and acceptance criteria for compilers, operating systems, and libraries; rather, it requires users to confirm the software tools are suitable for use. A major change implemented in the 2016 revision of IEEE 7-4.3.2 provides criteria on the use of software tools used for digital devices and development of hardware, software, firmware, and programmable logic. Endorsing IEEE Std. 7-4.3.2-2016 or just Clause 5.3.2 would address the use of software tools throughout the software lifecycle and the quality issues associated with them.

Similar to some NRC guidance, NASA and IEC 61226 specify the same requirements for the software tools as those for the safety systemsthat the tools were used on. FDAs guidance states that [software] tools should have a degree of quality no less than the software product they are used to develop. The FAA requires that all software tools be identified, validated, and addressed within the software development activities and documentation. The aerospace industry assigns software tools in a classification separate from the embedded system software, whereas the civil aviation industry classifies software tools to the same level as the software developed with the tool. BS EN 50128 for the railroad industry contains several requirements for software tools used in the safety-related software development life cycle process that only depend on the tool functionality. Tools are assigned to one of three classes, and all tools must be assigned to one of these classes, depending on their potential to affect the executable code C-8

The coverage of software tool requirements and guidance throughout the nuclear and nonnuclear industries varies considerably. Only a few industries impose requirements and provide guidance for software tools use in all phases of the software development process. Most industries do not impose requirements or provide specific guidance for the qualification of software tools. Most industries focus their efforts on the coding and testing processes and modeling, construction, and implementation tools. Only a few industries specify software tool requirements and provide guidance for other software development processes like the requirements specification phase, the conceptual design phase, and the detailed design phase. Somewhat related but outside the scope of this review, a few industries specify requirements or provide guidance for management support tools, maintenance tools, documentation tools, configuration management tools, and quality assurance tools other than requiring that such tools be identified, and their use documented.

C.5 References C.1 J. Servatius, S. Alexander, and T. Gitnick, Evaluation of Guidance for Tools Used to Develop Safety-Related Digital Instrumentation and Control Software for NPPs, Task 2 Report: Analysis of the State of Practice, ISL-ESRD-TR-14-03, August 2014 (ML15043A206).

C.2 U.S. NRC NUREG-0800 Appendix 7.1-D,Rev. 1,Guidance for Evaluation of the Application of IEEE Std. 7-4.3.2, August 2016 (NRC ADAMS Accession No. ML16019A114).

C.3 G. G. Preckshot and J. A. Scott, A Proposed Acceptance Process for Commercial Off-the-Shelf (COTS) Software in Reactor Applications, NUREG/CR-6421, March 1996 (NRC Adams Accession No. ML063530384).

C.4 IEEE 7-4.3.2-2016, IEEE Standard Criteria for Programmable Digital Devices in Safety Systems of Nuclear Power Generating Stations, Institute of Electrical and Electronics Engineers, Piscataway, NJ, January 29, 2016.

C.5 Radio Technical Commission for Aeronautics (RTCA), Software Tool Qualification Considerations, DO-330, December 2011.

C.6 Multinational Design Evaluation Program (MDEP) Digital Instrumentation and Control Working Group (DICWG) Common Position on Software Tools for the Development of Software for Safety Systems, Generic Common Position DICWG No 2, Version C, March 13, 2013.

C.7 International Electrotechnical Commission, Nuclear Power Plants - Instrumentation and Control Systems Important to Safety - Software Aspects for Computer Based Systems Performing Category A Functions, IEC 60880:2006, Geneva, Switzerland, 2006.

C.8 International Electrotechnical Commission, NPPs - Instrumentation and Control Important for Safety - Software Aspects for Computer-Based Systems Performing Category B or C Functions, IEC 62138, First Edition, Geneva, Switzerland, January 2004.

C.9 International Electrotechnical Commission, Nuclear Power PlantsInstrumentation and Control Systems Important for SafetyClassification, IEC 61226, ed. 2.0, Geneva, Switzerland, February 2005.

C-9

C.10 International Electrotechnical Commission, Functional safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems - Part 7: Overview of Techniques and Measures, IEC 61508-7, Edition 2.0, Geneva, Switzerland, 2010-04.

C.11 CSA Group, Qualification of Digital Hardware and Software for Use in Instrumentation and Control Applications for Nuclear Power Plants, CSA N290.14-15.

C.12 U.S. Department of Transportation,Federal Aviation Administration,Software Development for the National Airspace System (NAS), FAA-STD-026A, June 2001.

C.13 U.S. Food and Drug Administration (FDA), General Principles of Software Validation; Final Guidance for Industry and FDA Staff, January 11, 2002. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-principles-software-validation C.14 U.S. Department of Defense, DOD Guide for Achieving Reliability, Availability, and Maintainability, August 3, 2005.

C.15 National Research Council 2007. Software for Dependable Systems: Sufficient Evidence?.

Washington, DC: The National Academies Press. https://doi.org/10.17226/11923.

C.16 National Aeronautics and Space Administration, NASA Software Engineering Requirements, NPR 7150.2A, September 27, 2004.

C.17 National Aeronautics and Space Administration, Software Assurance Standard, NASA-STD-8739.8, 2004-07-28.

C.18 National Aeronautics and Space Administration, Standard for Models and Simulations, NASA-STD-7009A with Change 1, 2016-07-13.

C.19 National Aeronautics and Space Administration, Software Safety Standard, NASA-STD-8719.13C, 05-07-2013.

C.20 National Aeronautics and Space Administration, NASA Software Safety Guidebook, NASA-GB-8719.13, March 31, 2004.

C.21 National Aeronautics and Space Administration, NASA Complex Electronics Handbook for Assurance Professionals, NASA-HDBK-8739.23, 02-02-2016.

C.22 British Standards Instutition (BSI), Railway applicationsThe Specification and Demonstration of Reliability, Availability, Maintainability, and Safety (RAMS)Part 1: Basic Requirements and Generic Process, BS EN 50128:1999, 1999.

C.23 R. T. Wood et al., Common-Cause Failure Mitigation Practices and Knowledge Gaps, ORNL/LTR-2012/556 (NEET/ASI/ORNL/TR-2012/01), October 2012.

C.24 EPRI 1001503, Identification and Description of Instrumentation, Control, Safety, and Information Systems and Components Implemented in Nuclear Power Plants, Electric Power Research Institute, Palo Alto, CA, June 2001.

C.25 U.S. NRC, Final Safety Evaluation by the Office of Nuclear Reactor Regulation for SPINLINE 3 Platform Licensing Topical Report Rolls Royce Civil Nuclear, September 8, 2014 (NRC Adams Accession No. ML14143A27).

C-10

C.26 U.S. NRC, Safety Evaluation for Topical Report 2016-RPC003-TR-001 RadICS Safety System Digital Platform, August 2019 (NRC Adams Accession No. ML19134A193).

C-11

APPENDIX D EMERGING TECHNOLOGY (ET)

In this work, emerging technologies refers to devices related to EDDs, practices, design development and assessment methods and tools, and issues associated with evolving technology and new initiatives by the industry that could be included in license amendment applications or impact digital systems of nuclear plants, but which are not yet widespread in the nuclear industry.

Investigating emerging technologies was not conducted as an independent effort to consider all types of emerging technologies, but served to capture those that were identified during the evaluation of EDDs and that are related to EDDs. In addition, existing literature reviewing emerging technologies in the U.S. nuclear industry was reviewed for relationships with EDDs. In many cases these emerging technologies could also apply to digital instrumentation and control systems generally.

It is undeniable that advances in the capabilities of electronically enhanced components are occurring at a high rate. These advances include technical areas that extend to applications in the nuclear industry, from upgrades to existing plant systems to enhanced monitoring and control to supporting autonomous operation for advanced reactor designs. It seems that increased penetration of digital components into current and future nuclear power plants is inevitable as vendors are incorporating EDDs into more and more of their components.

The field of I&C technologies is broad and varied. It can be visualized in two slices as described in NUREG/CR-6812 (ORNL/TM-2003/22) [D.1]:

• The vertical slice, which is functionally focused, addresses the technologies that embody the sensing, communications, monitoring, control, and presentation and command systems between the process (i.e., the reactor, heat transport, and energy conversion systems) and the plant personnel (i.e., operations and maintenance staff).

• The horizontal slice at the lowest level is equipment focused and consists of the instrumentation string from the sensors and signal processing elements to the diagnostic modules and controllers (e.g., computational platforms) to the actuation devices. The variety of technologies that constitute the I&C systems of an NPP can be difficult to address as a whole. Therefore, the tack taken in this survey is to identify technology focus areas.

Based on the vertical or function-focused slice, the I&C technology breakdown is as follows:

• measurement systems,

• communications or networking,

• diagnostics and prognostics,

• control and decision,

• human-system interaction, and

• high-integrity software.

Based on the horizontal or equipment-focused slice, the I&C technology breakdown is as follows:

• sensors,

• communications media,

• microprocessors and other integrated circuits, and D-1

• computational platforms (computers, programmable logic controllers, application-specific integrated circuits, etc.).

The chosen list of technology focus areas for section D.1 is derived from the technology breakdown offered by each of the vertical and horizontal slices.

• sensors and measurement systems,

• communications media and networking,

• microprocessors and other integrated circuits,

• computational platforms,

• self-diagnostics and prognostics,

• human-system interactions,

• high-integrity software, and

• I&C architectures in new plants.

Many of the emerging technology focus areas listed above may not have had any sort of digital controller when originally installed and may have had little or no logic, but now may contain a digital system that adds functionality. For example, a pump may now contain an array of sensors to support diagnostics or support cavitation detection through high frequency vibration sensors

[D.2]. These sensors digital subcomponents may be external and placed up to hundreds of feet away from the component to avoid a high radiation environment similar to the FIELDVUE DVC6200 controller [D.3].

Sections D.2, D.3, D.4, and D.5 come from areas of emerging technologies identified during the project, or that were otherwise known to the authors.

D.1 ET in I&C Applicable to EDDs ORNL reviewed the advances of I&C in several technology areas in the following reports:

• NUREG/CR-6812 (ORNL/TM-2003/22) [D.1]

• NUREG/CR-6888 (ORNL/TM-2005/75) [D.4]

• NUREG/CR-6992 (ORNL/TM-2008/184) [D.5]

• ORNL/TM-2006/626 [D.6]

The eight focus areas reviewed in NUREG/CR-6992the last update report on ETare summarized below, with an assessment of the advances in technology and its potential impact on EDDs.

It is expected that the use of EDDs will significantly increase at NPPs. The ability to add an EDD to existing components will lead to an increased use of such devices. Microprocessors allow EDDs to be designed to allow them to be configured for more than one application. This in turn means that many vendors not previously supplying components or digital field devices to NPPs will most likely begin to supply components or digital field devices to NPPs. Because the use of EDDs at NPPs will likely increase, and more vendors of EDDs will not be from inside the nuclear industry, cyber security vulnerabilities and concerns will be greater. In addition, concerns with respect to software development and the use of software tools will also increase.

D-2

D.1.1 Sensors and Measurement Systems The use of sensors with inherent drift-free characteristics can eliminate some of the need for calibration. Incorporating calibration capabilities in EDDs could potentially reduce the need for manual calibration. Methods such as cross calibration are not be available to EDDs because of their local use and isolation. It appears that, in general, the sensing technologies in the nuclear power industry represent adaptations of well-established measurement concepts, and new sensors are typically evolutionary rather than revolutionary in nature. Thus, new sensor technologies, primarily arising out of the needs for advanced reactors or 3-D printing sensors into components may be incorporated into EDDs at some point.

D.1.2 Communications Media and Networking Advances in digital communication systems in general have focused on boosting data transmission speeds, developing more robust protocols, error correction and encryption techniques, and (for wireless systems) spread spectrum techniques. Advances in communication techniques would be very slow to be incorporated into EDDs, simply because of their function.

EDDs do make extensive use of digital communication, but this use is to convey information on the component and not the system. The independence issue is not so easily resolved with regard to wireless communications systems in EDDs. The applications of wireless communication between EDDs are likely to be limited in the foreseeable future to non-safety-related diagnostics and maintenance systems, inventory management systems, and voice and data communications to employees and field crews.

D.1.3 Microprocessors and Other Integrated Circuits The growing system complexity of semiconductor devices and the cost of ASICs could lead to higher use of processors. This could make it more difficult to guarantee delivering future EDDs free of errors. In addition, the successful development of high-k transistor integrated circuits and the potential for multi-gate transistor ICs could revolutionize the integrated circuit industry, but it could also introduce new aging phenomena, higher sensitivity to environmental conditions (e.g.,

temperature and radiation), and other issues related to qualification methodologies if incorporated into EDDs.

Failure modes and mechanisms for both current and emerging digital I&C technologies in EDDs need to be characterized to assess whether any new failure modes can cause unforeseen or unknown component and system responses.

D.1.4 Computational Platforms The computational platforms for EDDs can cover an extraordinarily broad range of devices. At the simplest end, an EDD might consist of a few logic devices in a PLC or a few elements on an ASIC. The program being executed is almost as simple as getting an analog device to run when turned on. The regulatory question then becomes, when does an EDD become so simple that it no longer comes under the heading of digital computer? Regulatory guidance for such systems and devices (e.g., FPGAs, CPLDs) that are halfway between simple and complex is currently not as well defined. For example, DI&C-ISG-04 [D.7] requires a priority module design to be fully (i.e.,

100%) tested if it combines the diverse actuation signals with the actuation signals generated by the digital system or if software tools used in its development are not to be validated. If the priority module is designed using a CPLD or a device of similar complexity, it may be very difficult, if not impossible, to prove that such a device has been fully tested.

D-3

Complex computing platforms (e.g., those using multicore processors) and OSs are more likely to be used in control and information display applications in I&C systems rather than in EDDs because of the much more rigorous demand for V&V in a safety system application.

Microprocessors allow EDDs to be designed to allow them to be configured for more than one application. EDDs, if they use a processor, would have an OS that can to be used to run the application software. Operating systems provide the fundamental interface between software and hardware in most digital applications. Thus, their performance and reliability characteristics should be well understood.

D.1.5 Self-diagnostics, and Prognostics Self-diagnostic techniques can be used in EDDs for monitoring the condition of rotating machinery condition, instrument response time measurements, predictive analysis of failures in sensors and sensor lines, and motor current signature analysis. The advantage of EDDs is that diagnostics can move from periodic human-based inspection (e.g., surveillance testing) to online monitoring for condition-based maintenance and eventually prognostics. These areas include sensors, better understanding of measurement in the plant environment (e.g., what and how to measure),

enhanced data interrogation, communication and integration, new predictive models for damage/aging evolution, system integration for real-world deployments, and integration of enhanced condition-based maintenance/prognostics philosophies.

In some cases the EDD may not be integral to the device, but may be a separate device attached to the system of interest. For example, a pump may now contain an array of sensors to support diagnostics or support cavitation detection through high frequency vibration sensors [D.8]. These sensors may be external and designed for a nuclear power plant with its high radiation environment [D.8].

Self-diagnostics offers tremendous new opportunities for plants to operate more reliably, manually test less frequently, reduce risk of latent failures, reduce maintenance costs, and reduce worker exposure. The issues from a regulatory standpoint are mainly concerned when self-testing is applied to a safety system and the self-testing performs a required function under regulatory control. A number of fundamental questions emerge, as follows:

1. Are there any subjective monitoring criteria that an expert adds to surveillances that are lost in the self-diagnostic system?

2. Are the systems being monitored and their failure modes easy to recognize?

3. Are the failures in the self-diagnostics easy to recognize?

4. Can the operator accurately tell the difference between the failure of the self-diagnostics and the failure of the device it is monitoring?

5. Does the presence of the self-diagnostics affect the reliability of the safety function?

6. How can the self-diagnostic function be protected against a software fault that leads to a CCF to detect a failed protection system?

The modular nature of some EDDs can simplify resolving some of these questions. The EDD performing the diagnostics may not be tightly integrated with the portions of the EDD performing D-4

the safety function. For a diagnostic device bolted onto the component, this separation may be very clear and physical. However even within a device there may be internal separation, for example some EDDs have different SIL certifications for internally separated functions such as the DVC6200 SIS Digital Valve Controller and Position Monitor where portions are assessed at SIL 3 and others at SIL 2.

D.1.6 Human-system Interactions (HSIs)

There are many evolving design and evaluation tools that can optimize the design of human interfaces and speed up their evaluation, and all are based on computer software technologies.

Many of these tools are being developed outside of the nuclear power industry. It is widely accepted that poor human factors engineering contributes to poor human performance, increased errors, and reduced human reliability.

D.1.7 High-integrity Software Software cannot typically be proven to be error-free and therefore could be considered susceptible to CCFs if identical copies of the software are present in redundant EDDs. The use of diversity to protect against CCFs in software design is not likely to change. However, a great deal of effort can go toward advanced software development techniques to reduce the likelihood of software faults in an EDD, to make the software less costly, and to make the software easier to review and license for use. The software development cycle in safety system use models such as the waterfall lifecycle model for nuclear software development, although modern lifecycle models are more iterative, and can benefit from tools better able to track requirements in such a process.

Of the vendors contacted, software in EDDs can be developed by writing individual lines of code or using software tools to write the code. It is believed by many that the use of software tools helps automate design steps and report generation, organize the work in new ways that tend to make errors less likely, or automate testing and V&V. It is no longer just the computer program that runs on the EDD that affects quality, but the much larger system of software used to develop the software.

D.1.8 I&C Architectures in New Plants A review of the I&C features of new I&C system designs indicated that these designs use fully digital and networked architectures. Some safety-related modules and subsystems in the plants reviewed include ASICs, FPGAs, or CPLDs. The same issues for ensuring reliable safety system designsissues whose resolution can enhance the regulatory process for digital systemsare applicable to EDDs. These include (1) the need for a complete characterization of failure modes, (2) determining how much V&V should be required for EDDs that are halfway between simple (e.g., binary ON, OFF, and/or a small number of combinatorial logic) and complex, (3) determining how the self-testing function can be protected against a software fault that leads to a CCF, and (4) determining how much credit should be given to an online diagnostic system, which in itself could be more complex than a simple processing function.

D.2 ET in EDDs ET in EDDs can be from advances in industry migrating into the nuclear arena or unique needs for new nuclear plant designs.

Embedded digital capabilities will enable new types of components that are not feasible without the high-speed data acquisition and processing capabilities supplied by the on-board electronics.

D-5

For nuclear applications, there are some emerging applications of autonomous control for creating reactor components that operate in extreme environments. For example, replacing mechanical bearings with magnetic bearings can allow a pump to be made from materials that can operate above 650 °C.

Current generation NPPs use a centralized control architecture that requires exceptional operator knowledge of the power plant, and the cost and difficulty of designing the operational and safety systems are significant because of the system complexity. Localized control through the use of EDDs will allow for simplifying the design and operation of complex systems while improving modularity similar to object-oriented control architectures.

Future advanced reactors may employ EDDs more extensively than the existing fleet due to the opportunity to integrate instrumentation into the SSCs during fabrication and/or construction.

Embedding digital devices into components is also more likely at advanced reactors due to the advancement in the capabilities of digital technologies and consequent potential for improving component performance and reliability.

D.2.1 Future Uses of EDDs The combination of on-device processing and digital communication for optimizing process performance for both technical performance and enterprise-level business goals will likely be more ubiquitous in the future. Embedded digital capabilities will also enable new types of components that are not feasible without the high-speed data acquisition and processing capabilities supplied by the on-board electronics. It is likely that components with EDDs will

• Become more aware of their health

• Be aware of the health of other devices in the process

• Be able to autonomously take actions to operate resiliently

• Be aware of their place in the overall process

• Understand how changes they make to process variables under their control will impact the overall process

• Store data and analyze past behavior

• Coordinate with other EDD components

• Understand how the process changes over time

• Abstract the operational functions that are exposed to the operator

• Autonomously develop system models

• Solve optimization problems The search for EDDs in components was focused on those components that are supplied by vendors to the nuclear power industry. The review for EDDs also assumed a broader view to identify their use in industry. This review shows that EDDs are prevalent in industry. It is likely D-6

that their use will migrate into the NPP industry, and their use will become more prevalent. For example, 663 UPSs were identified with EDDs; only 8 of these were from vendors that supply UPSs to NPPs.

The primary functions of EDDs used in components are to perform diagnostics and to communicate via modem host interfaces. The expansive use of EDDs in industry, in which EDDs perform fine control of a system, will likely migrate into the nuclear sectors.

EDDs are used to monitor and communicate the health of the components and to identify problems or failures. EDDs will migrate into the NPP arena first through the nonsafety systems and eventually to safety systems. By employing EDDs in components in non-safety and secondary side control, NPPs will be able to add fine control to their system, thereby reducing uncertainties. Reducing uncertainties and increasing reliability via surveillance, testing (diagnostics), and auto-calibration on the secondary side means that more heat can be generated on the primary side. This in turn has resulted in some licensees requesting power uprates.

Installing EDDs on existing components is becoming easier. Because of this, its use will increase, and EDD vendors from outside the nuclear industry will most likely begin to market EDDs to nuclear vendors and nuclear plants.

Remote-mount digital controllers like Emerson's Fisher FIELDVUE DVC6205 have only the valve position feedback mounted on the control valve, while the remainder of the digital valve controller can be mounted over 300 feet away in a less severe or more accessible environment. This option now allows digital control where accessibility, extreme temperatures, extreme vibration, or confined space is an issue and where integral mounting is difficult or impractical. Because of this, the use of EDDs and controllers on components in harsh environments or severe conditions will most likely begin to increase.

Future uses could also come about from new software and hardware technologies:

• Communication (fountain code, time-sensitive networking, blockchain)

• Emerging hardware (peel-and-stick sensors)

D.2.2 ET in functionality Although of limited functionality, it is likely that new HMIs will have added features that will likely create new malfunctions. New physical interactions with the HMI will require an examination of how the actual physical interface could impact performance of SAR-described design functions.

For example, if a malfunction with a different result is created as a result of the physical interaction, then the HMI portion of the digital modification would be deemed adverse and would be evaluated per 10 CFR 50.59. Examples of new physical interactions include:

• Use of touch screens in place of pushbuttons, switches, or knobs

• A new interface requiring the human user to choose which component is to be controlled

• Changes to operating procedures

• Information overload

• Changes in how a parameter is displayed

• Changes in the data acquisition process Ideally, EDDs with limited functionality would operate like IIoT systems and would not require high IEC SILs. This would apply to EDDs in safety or nonsafety systems.

D-7

In principle, the added functionality of smart sensors could be the same as for conventional sensors. In reality, this is not the case [D.9]:

1. The signal processing in smart sensors can involve more elaborate calculations than are possible in conventional sensors. These calculations might for example correct for nonlinearity.

2. Smart sensors may have more modes of operation and more parameters than their conventional versions.

3. Smart sensors may measure multiple process variables at the same time.

4. Smart sensors may provide more information than conventional sensors do. Flow sensors for example often contain temperature sensors for improving the accuracy of the measurement.

Conventional sensors do not transmit this temperature, some smart sensors however do.

5. Smart sensors contain fault diagnostics; this inevitably leads to complicated algorithms in software and provisions in the hardware of the sensor.

At the plant and system levels, data communications are important. However, at the EDD component level, data communications between different EDDs is currently not allowed for safety related functions and is therefore not considered. Similarly, wireless communication is currently not allowed for safety related functions. If these capabilities are added or if EDDs are bundled into a system, then the reviews on the functionality of the EDDs would be like those reviews for systems.

D.2.3 Hardened EDDs Hardened may refer to cyber security hardening or radiation hardening. Each of these is discussed below.

D.2.3.1 Cyber Security Many companies, such as Lockheed Martin, Raytheon, BEA Systems, and others, are working towards developing hardened networks and devices. Some of the challenges faced are in hardening of existing technology for cases in which the original platform did not require such measures. The PTR Group, Inc., is approaching hardened EDDs by assessing the security risks in the software (Linux). To make software more robust, any data stored or any software implemented must require encryption keys, passwords, etc., and all non-essential software must be removed.

Implementing e-fuses to protect internal registers or storage is one way to address the physical security of EDDs. Removing all external penetrations (USBs, serial ports, ethernet ports, etc.)

and using tamper proof screws is also considered to physically harden EDDs.

The development, transport, and use of EDDs used in a safety-related application would follow NRC guidance for safety-related systems.

D.2.3.2 High Temperature and Radiation Environments Current technology allows the same digital hardware that could be embedded within a device to instead be installed hundreds of feet away from the component. For example, in high radiation D-8

areas, high temperature areas, etc., the digital hardware for valve controllers can be installed hundreds of feet away from the valve.

The development of wireless sensor nodes allows increased sensing, processing, and wireless communication capabilities of small, portable devices [D.10]. Self-powered wireless sensor nodes potentially offer significant expansion in remote monitoring at nuclear facilities and provide important data on plant equipment and component status during normal operation, as well as during abnormal operation or station blackouts and for post-accident evaluation.

Sporian Microsystems, Inc. is working on advancements in sensors and instrumentation to develop and improve the reliability of advanced sensors (and associated instrumentation) that can withstand harsh environments [D.11]. For example, for an internal control rod drive mechanism, it is not possible to verify full insertion externally. The technical challenges of developing a sensor that can reliably verify the control rod position and that can ultimately verify full control rod insertion include its sensitivity to particulates, small size, high reliability, and harsh environment operation, including very high temperatures (600°C), high pressures (2200 psig), borated Grade A water environment, and high irradiation. Ideally, such a sensor system would consist entirely of solid-state sensing (no moving parts) hardware and minimal electrical connections/vessel penetrations. Typical silicon-based electronic components and materials used in equivalent semiconductor devices are not suitable for use at the proposed temperatures. Important to this technology development, Sporian has identified novel materials, manufacturing, and signal conditioning methods, resulting in sensors and instrumentation with greater magnetic field sensitivity in high-temperature environments while minimizing system size and weight.

D.2.4 Wireless Technologies There is growing level of interest in wireless systems. Use of wireless technology at nuclear plants could include adding wireless sensors to improve the amount of information available to operators. Wireless technology also affords the ability to remotely gather information about equipment or systems in hard-to-reach areas of the plant. In the near future, wireless technology will not be limited to through air transmission of the signal. A self-powered wireless through-wall data communication of an audio signal has been successfully designed and tested and work is progressing on transmitting a video image [D.12].

In existing NPPs, it is often impractical, or cost prohibitive, to add new sensors if they must be hardwired to a monitoring location. This discourages the installation of additional condition monitoring. Wireless sensors may help to resolve this issue. Use of wireless technology to extend plant communication networks has shown promise in the U.S. nuclear industry, resulting in improved dissemination of information and overall personnel efficiency. Worldwide, NPPs have taken advantage of wireless technologies. As experience and confidence is gained, wireless technology applications may be extended from ancillary functions to monitoring of plant conditions for operator information and control. IAEA recommends the active pursuit of the deployment of wireless technology in monitoring and diagnostics applications in NPPs in order to gain experience and develop knowledge that will allow future use of wireless in more demanding plant applications [D.13].

Expected near term wireless applications will include remotely monitoring devices on/near safety related/important to safety, collection of equipment performance data collection, dose rate monitoring, tracking and automated survey map updates. In Canada, the Pickering Nuclear Generating Station (PNGS) already uses wireless sensors as part of its online monitoring to enable condition based monitoring [D.14]. Milestones at PNGS include the first deployment of D-9

wireless sensor networks to collect health data for various plant equipment, the use of Bluetooth 5.0 low energy and 900 MHz wireless sensors, in-house performance of EMI qualification testing, and collection of wireless sensor data at PNGSs historian database.

Concerns with the use of wireless technologies include the susceptibility and adequacy of protecting the devices from cyber-attacks, and the potential for interference between wireless equipment and equipment producing electro-magnetic waves or other wireless equipment. Previous research by NRC and ORNL staff indicates that cybersecurity and issues with electromagnetic propagation (electromagnetic and radio frequency interference, fading, interference abatement) as the major concerns with implementation of wireless technologies [D.15, D.16, D.17]. On February 20, 2020, NRC held a public meeting with industry representatives to have industry provide the NRC with details of their initiative on the use of wireless at NPPs and to discuss cyber security performance oversight [D.18].

PTR Group states that a window of vulnerability for any system using wireless technology is during the initial start-up sequence [D.19]. Also, firmware updates can present similar security problems and require a digital signature or physical token. When addressing wireless communication for EDDs, encryption technology will be critical for security of the system.

Encrypted data messages that are sent/received are classified as data-in-flight. For wireless, this is the point at which most attacks happen through spoofing or interception. Knowing the devices connected to the wireless network and regularly taking inventory can help to quickly identify intruders. Use of smart cards or trusted platform modules is one option to increase security.

Implementing cryptographic hash into a piece of firmware is another option.

Cameras using wireless technology can provide remote monitoring of equipment. Portable carts containing sensors and cameras can perform some of the work of fire watches, providing continuous monitoring of certain parts of the plant, serving as a replacement for hourly visits for a few minutes by personnel. Such carts are already in use in several U.S. NPPs.

Radiation protection technicians could use wireless technology to monitor radiation levels without visiting higher-dose areas of the plant in person. The Department of Energy has been funding research into advances in wireless technology such as thermoelectric generators for self-powered wireless sensor nodes. While the safety significance of the application of such technology isnt indicated, the research included evaluating the effects of gamma radiation on the materials, indicating uses in harsh environments [D.20].

D.2.5 Micro-Electrical Mechanical Systems (MEMS)

MEMS is a process technology used to create tiny integrated devices or systems that combine mechanical and electrical components [D.21]. These devices or systems have the ability to sense, control, and actuate on the micro scale, and generate effects on the macro scale.

MEMS usually consist of a central unit that processes data (the microprocessor) and several components that interact with the surroundings such as microsensors [D.22]. Because of the large surface area-to-volume ratio of MEMS, forces produced by ambient electromagnetism (e.g., electrostatic charges and magnetic moments), and fluid dynamics (e.g., surface tension and viscosity) are more important design considerations than with larger scale mechanical devices.

MEMS can be found in systems ranging across automotive, medical, electronic, communication and defense applications. Current MEMS devices include accelerometers for airbag sensors, inkjet printer heads, computer disk drive read/write heads, projection display chips, blood pressure D-10

sensors, optical switches, microvalves, biosensors, and many other products that are all manufactured and shipped in high commercial volumes.

A specific research effort for the use of MEMS in NPPs was the DOE NEET project Development of in-plane Single Crystal Silicon Microrelays for Nuclear Power Applications which planned to use MEMS to make physical micro-relays on a chip, allowing them to use purely analog logic

[D.23].

D.2.6 Autonomous Control Autonomous control means that the data acquisition, control, actuation, and computation all occur in, on, or physically near the physical object being controlled. This is the classic example of an EDD. Similarly, EDDs may allow external commands from an operator either locally or remote.

For example, a switched reluctance motor controller, satellite antenna attitude controller, or autonomous vehicle path planning controller are examples of localized control. While localized control could be as simple as a limit switch-controlled actuator, the greater concern is with the application of more complex advanced local feedback controllers.

For many decades autonomous control has been common in aerospace applications. The high-speed and high-performance of most aerospace applications required developing advanced techniques for designing, analyzing, synthesizing, and implementing controls [D.24, D.25].

Difficult measurement processing and integration applications such as inertial attitude and heading estimation also required high-speed data acquisition and processing platforms to execute the algorithms [D.26, D27].

Increasingly, many automotive applications are implementing more complex autonomous control.

Automotive manufacturers are moving away from mechanically coupled systems because of their complexity, weight, and performance restrictions. For example, the Ferrari 2018 GTC4lusso has active all-wheel steering instead of the traditional mechanical solution using track and tie rods to connect the left and right steering arms. The purely mechanical solution fixes the steering geometry and relative steering angle of the left and right wheels. Active all-wheel steering, on the other hand, allows the steering angles of all four wheels to be controlled independently. The GTC4lusso then uses its vehicle dynamics EDD and various sensors to implement advanced autonomous controllers that provide advanced functionality like controlled side slip [D.28],

increased grip and handling, optimized steering geometry for all driving conditions and increased overall stability [D.29]. The GTC4lusso also uses an adaptive suspension system and EDD local controller which can adjust suspension stiffness in real time, as well as an engine control unit EDD that currently makes it the most powerful naturally aspirated engine in a road vehicle [D.29].

Another emerging use of EDDs for autonomous, local control is seen in self-driving vehicles

[D.30]. These vehicles require complex algorithms for control, sensor fusion, simultaneous localization and mapping [D.31], optimization with dynamically changing constraints [D.32], and safety [D.33].

For nuclear applications, there are some emerging applications of autonomous control for creating reactor components that operate in extreme environments. For exampleechanical bearings begin to fail at around 400 °C and for molten salt reactor applications that operate above 650 °C. This complicates the design, fabrication, and integration of rotating components that are in contact with the high-temperature salt. One possible solution is to replace mechanical bearings with magnetic bearings which can be made from materials that can operate above 650 °C [D.34, D.35] but require a high-speed high-performance local feedback controller to function [D.40].

D-11

Autonomous control has the advantages of

• Increased autonomy

• Simplified operator interactions

• Abstracting the operational functions

• Decoupling the control and operation

• New functionality

• Enables the decoupling of physical systems

• Optimized performance

• Reactive to real-time changes in local operating conditions In contrast to autonomous control, NPPs are for the most part centrally controlled from a single control center, with some localized control employing simple open-loop (e.g., variable frequency drive) or proportional integral derivative controllers (e.g., control rod position controller). This centralized control architecture requires exceptional operator knowledge of the power plant, and the cost and difficulty of designing the operational and safety systems are significant because of the system complexity. Autonomus, localized control is one method for simplifying the design and operation of complex systems while improving modularity similar to object-oriented control architectures.

Previously, the cost to develop high-speed high-performance autonomous controllers was too great for many OEM components. Autonomous control required expensive specialized equipment for experimental design, testing, and validation of the controller and a laborious process of transferring that design into special hardware and software for the production implementation, followed by exhaustive safety and performance testing of the system. The advent of low-cost single board computers, simplified software modeling languages, automatic controller code generation, coupled multiphysics finite element and finite difference modeling, software control synthesis tools, open-source controller libraries, and open-source real-time operating systems have reduced the costs of developing, testing, and deploying complex autonomous controllers.

The only aspect of autonomous control that remains costly is the testing of the system performance and safety because of the mostly manual experimental design and execution.

The typical design process for a high-performance high-speed controller consists of the some or all of the following activities

• System dynamics model development

• System identification testing

• Uncertainty quantification

• Controller architecture design

• Controller synthesis

• Mathematical stability analysis

• Data acquisition design

• Signal processing

• Sensor fusion

• Startup/shutdown procedures

• Safety system design

• Software testing

• Hardware testing

• Human machine interface design D-12

Developing an accurate model is the first step in the design of a autonomous controller. Models are divided into two major categoriesfrequency domain and time domain. Standard linear frequency domain models typically use techniques such as transfer functions. Time domain models such as the state-space representation use techniques such as linear quadratic regulators.

Once an accurate low-order model is developed, it is used to synthesize a controller by various analytical techniques developed for different types of models. A brief (but by no means exhaustive) description of the most commonly used controller synthesis techniques is provided below:

• Loop-shaping

• Pole placement

• Optimal control

• Robust control

• Adaptive control

• Model predictive control

• Sliding-mode control

• Neural network control

• Lyapunov control This list is by no means complete: a major area of research is the development of new controller synthesis tools. However, this list includes the commonly used techniques in application.

D.2.7 Combined control Sensor information will be more commonly processed locally in future NPPs where possible because of to the expense and difficulty of long-distance cabling. Sensor signals tend to be small and may include high frequency content because of the characteristics of the process or component being monitored. Cable signal transmission line properties distort the higher frequency signal components. Nuclear plant environments are electromagnetically noisy because of the presence of electrical and electronic components necessitating careful cable grounding, shielding, and routing. Organic cable electrical insulation is combustible and has a lifetime shorter than that of a nuclear plant. Routing cables across plant boundaries can therefore create a fire vulnerability and increases the complexity of plant construction.

There are thousands of miles of cables in each reactor [D.38]. Cable pulling now costs $3,000-

$6,000 / meter for safety-related cable; such costs dominate instrumentation, controls, and human-machine interface capital costs [D.39]. Consequently, future reactor SSCs will tend to process sensor signals locally and will pass actionable information to the plant control and/or safety systems when necessary. Transmitted information will be digital, and it may be wireless, to an access point for the plants high-speed communication network. Other methods include piggybacking information and control onto single cables or using various schemes to put a multitude of devices on a single cable.

Localized information from EDDs could be collected at a control bank of EDDs and have its own I&C control system.

D-13

D.2.8 Additive Manufacturing Additive manufacturing processes allow for direct embedding of sensors in critical locations within nuclear components during the manufacturing process. Proper selection of the sensor to be embedded and placement of the sensor within a component could greatly enhance plant monitoring capabilities, identify early signs of component failure, and reduce the staffing required to operate nuclear plants. The ultimate goal of additive manufacturing processes is to allow for direct embedding of sensors in critical locations within nuclear components during the manufacturing process which, at least as is being considered for ORNLs Transformational Challenge Reactor, would enable fully autonomous control [D.39].

One application of embedded sensors in nuclear plants relates to placement of sensors in locations that are otherwise inaccessible using traditional manufacturing techniques.

D.3 Digital Twins DOE is performing research on digital twins, which can be applied at both the system and component level.

A digital twin refers to a digital replica of the system or component. Two aspects of a digital twin are important: (1) it recognizes the connection between the physical model and the corresponding virtual model or virtual counterpart, and (2) this connection is established by generating real-time data using sensors.

Digital twins integrate IoT, artificial intelligence, machine learning, and software analytics to create living digital simulation models that update and change as their physical counterparts change. A digital twin continuously learns and updates itself from multiple sources to represent its near real-time status, working condition, or position.

In the DOE world, one research project is using a digital twin to recognize cyber-attacks on the control system. Another DOE project is performing research to optimize the operation and maintenance of components.

Another DOE project will develop digital twin technology for advanced nuclear reactors, using artificial intelligence and advanced modeling controls to create tools that introduce greater flexibility in nuclear reactor systems, increased autonomy in operations, and faster design iteration. The development of these digital twins will work towards a 10x reduction of operating and management (O&M) costs at advanced reactor power plants [D.40].

EDDs, in addition to being in the components a digital twin may be analyzing to optimize its operation and maintenance, could support collecting the additional real-time data used by a digital twin.

D.4 Methods and Tools During the exploration for existing solutions to implement EDDs, several promising methods and tools were discovered. Properly reviewing all of these tools was determined to be beyond the time and budget allocated to this research effort; however, these should be noted as ETs that are already in use outside of the U.S. nuclear industry. Furthermore, while methods and tools are used for EDDs, they could be applied more broadly to RPSs and ESFASs, for example.

D-14

A research related report from Idaho National Laboratory is entitled Preliminary Results of a Bounded Exhaustive Testing Study for Software in Embedded Digital Devices in Nuclear Power Applications [D.41]. In the text describing the applicability of the document, the authors characterize an EDD as a reactive system, meaning it is characterized by its ongoing interaction with its environment, continuously accepting requests from the environment and continuously producing results. Their examples of such systems include process control systems and reactor protection systems; therefore, their scope is broader than this report. The report describes the use of combinatorial testing methods and boundary value analysis, along with studies supporting decisions as to how many values and combinations for the variables are sufficient. As with many methods, they then use a set of tools to realize the analysis and testing.

There are many specific software tools in use that fit the categories described in IEEE 7-4.3.2 (2016) and NQA-1. Their treatment is covered in Appendix C of this report. One thing that future evaluations may consider is that for particular tools and methods, claims may be made, such as in INL/EXT-19-55606 titled Preliminary Results of a Bounded Exhaustive Testing Study for Software in Embedded Digital Devices in Nuclear Power Applications, [D.41] which claims congruence with 100% testing for its proposed methods and tools. In many cases these advancements have been evolutionary in nature.

However, certain tools and methods represent a more substantial change, in particular model-based engineering. Model-based engineering can differ substantially from existing processes in that certain documents that are currently expected in regulatory guidance, such as a system requirement specification, are not produced, instead the digital engineering environment and the model itself could be used throughout the development lifecycle to capture, implement, and test the requirements. Model-based engineering also opens up the possibility of more substantial analysis and testing being performed during earlier lifecycle phases, which could be used to support NRC staff reviews, particularly when those reviews are focused on earlier lifecycle phases such as the alternate review process in ISG-06.

Such tools have different degrees of implementation across the lifecycle, but well-known examples include SysML, AADL, AnSys SCADE, and Mathworks Simulink (and associated toolboxes) [D.42, D.43, D.44, D.45, D.46].

There has been some work in this area specifically focused on use in NPPs.

EDF, in the framework of a collaborative project CONNEXION, has investigated model-based engineering methods based on simulations to formalize and evaluate DI&C requests in early design phases [D.47].

KAERI and Konkuk University have developed a model-based software development environment for safety-critical digital systems in NPPs to support formal verification and safety analysis called NuDE 2.0 [D.48].

Pakonen et al. [D.49] state that model checking has been used as a practical verification method in every major activity related to digital I&C in Finnish NPPs and that the experience at the VTT Technical Research Centre of Finland Ltd has shown that model checking can reveal design issues in DI&C application logic that are otherwise difficult to detect. However, they note that model checking did not seem commonplace in the nuclear domain outside of Finland as of 2017.

In addition to and somewhat associated with model-based engineering are improvements in the development of requirements. A more mathematically verifiable approach to requirements for D-15

computer controlled shutdown systems at the Nuclear Power Generating Station at Darlington, Canada, is described in Wassyng et al. [D.50].

Recent development in hazard analysis methods, such as Systems Theoretic Process Analysis have been evaluated by EPRI [D.51] and are being adopted by EPRI as part of their methodology for risk informing digital system in NPPs [D.52] and as an advanced method of hazard analysis in support of performing digital engineering modifications in [D.53]. In a study by the methods creators, systems theoretic process analysis was applied to a safety system in a U.S. NPP [D.54].

Such methods for identifying hazards could serve to ensure the correctness of requirements and critical characteristics for EDDs.

Various methods and tools are often used in concert to support a claim. For example, the SymPLe Architecture and Methodology described in Gibson et al. [D.44], as part of the DOE Nuclear Energy Enabling Technologies project, Realizing Verifiable I&C and Embedded Digital Devices for Nuclear Power, uses the MathWorks Simulink toolchain and Mentor Questasim tools to support model-based design and formal verification, with an original purpose of resolving CCF concerns for EDDs.

D.5 ET in Advanced Reactors The designs of advanced reactors will probably push the boundaries on technology, including increased use of sensors, autonomous control through EDDs, and advanced technology. Some new uses of EDDs not necessarily applicable to current plants include:

• EDDs in passive SSCs

• EDDs in new types of I&C devices

• Seismic isolators with expand reliance on EDDs

• Different fuel forms

• High temperatures Future advanced reactors may employ EDDs more extensively than the existing fleet because of the opportunity to integrate instrumentation into the SSCs during fabrication and/or construction.

For example, efforts to extend the life of existing LWRs have shown the value of monitoring the condition of the rebar within reinforced concrete and the difficulty of non-destructively externally measuring internal degradation. Consequently, future plants are likely to embed corrosion monitoring instrumentation into reinforced concrete during construction. Digital signal processing electronics would be anticipated to be deployed locally along with the sensors due to the comparative ease of digital networking.

The safety case of advanced reactors is anticipated to depend on the performance of passive SSCs, and EDDs can provide evidence of their continued functionality. Current plants rely instead on labor-intensive periodic inspections to demonstrate the functionality of safety-related SSCs.

For example, existing plants perform periodic containment pressure integrity tests as part of maintenance outages. The economic imperative to minimize staffing costs at future plants makes them much more likely to employ EDDs instead for continuous health monitoring. Directly measuring changes in component characteristics and performance can obviate schedule-based maintenance. For example, future passive decay heat rejection systems may include automatic health monitoring components that electrically impress heat pulses onto the heat transfer loop and subsequently monitor changes in loop flow and temperatures as evidence of system functionality.

While the logical elements of the health monitoring could be performed with non-embedded digital systems, having remote hardware would require employing additional safety-grade signal cabling D-16

to the system. Embedded health monitoring, in contrast, would only require providing system degradation notification to the plant control system.

Embedding digital devices into components is also more likely at advanced reactors due to the advancement in the capabilities of digital technologies and the consequent potential for improving component performance and reliability. The primary components at existing NPPs were designed and approved decades ago before the advent of high-speed digital systems. Modern control electronics now have sufficient speed and reliability to provide dynamic control of high-speed mechanical components such as pump and turbine shafts. Health and performance monitoring generally rely on small signals with high frequency content providing strong incentive to embed the signal processing rather than employing extensive cabling. Other industries have observed dramatic component reliability and performance improvements with the introduction of EDDs.

Modern jet engines have had dramatic reliability gains [D.55]. Locomotive traction drives gain up to 50% improvement in wheel thrust by monitoring the onset of slippage and controlling the drive force such that the wheel traction remains within the static friction regime. EDDs have already begun to be deployed internationally at advanced reactors. The HTR-10 helium circulator employs high-temperature magnetic bearings controlled using a multi-axis high-speed feedback scheme [D.56], avoiding the potential for water ingress across the seals experienced at Fort Saint Vrain helium gas circulator [D.57].

In-situ non-destructive evaluation and material property testing have widespread value for providing evidence of remaining material or component useful life. Properties as diverse as the elastic response of seismic isolators and changes in reactor vessel fracture toughness can be monitored using non-linear acoustics. Non-linear acoustic technologies are not yet commonly deployed in harsh environments. As health monitoring technologies mature, they would be anticipated to be deployed in embedded form (due to their dependence on integrated signal processing) in future reactors.

Most legacy mechanical systems and electronic components such as sensors, actuators, and control systems will not survive in a high-radiation, high-temperature corrosive environment expected in new reactor designs. A magnetic bearing suspension system for the rotor shaft in place of the mechanical bearings would decrease pump maintenance while increasing reliability and efficiency (Figure D-1). Embedded I&C techniques provide the functional and operational improvements [D.58].

Figure D-1 Concept Drawing of a Canned-Rotor, Magnetically Suspended, Reluctance Drive Motor-pump [D.58]

D-17

D.6 References D.1 R. T. Wood, et. al., Emerging Technologies in Instrumentation and Controls, NUREG/CR-6812 (ORNL/TM-2003/22), March 2003 (ADAMS Accession No. ML031900433).

D.2 T. Bass, Remote Monitoring of Pumps with wireless HART Transmitters, July 2017.

https://www.automation.com/en-US/Articles/2017/remote-monitoring-of-pumps-with-wirelesshart-trans D.3 Emerson Process Management (2014), FIELDVUEW DVC6200 Series Digital Valve Controller, https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=16&ved=2ahUKEwi hgvSohpTgAhVEOK0KHdSSDn4QFjAPegQIAxAC&url=http%3A%2F%2Fomeas.com%2F wp-content%2Fuploads%2F2018%2F08%2FProduct-catalog-Fisher-DVC6200.pdf&usg=AOvVaw3YHl4TXp34SfJKLCwK_VdV D.4 K. Korsah, R. Wetherington, and R. Wood, Emerging Technologies in Instrumentation and Controls: An Update, NUREG/CR-6888, January 2006 (ADAMS Accession No. ML060870216).

D.5 K. Korsah, et. al., Instrumentation and Controls in Nuclear Power Plants: An Emerging Technologies Update, NUREG/CR-6992, October 2009 (ADAMS Accession No. ML092950511).

D.6 K. Korsah, M. D. Muhlheim, and D. E. Holcomb, Industry Survey of Digital I&C Failures, ORNL/TM-2006/626, May 2007.

D.7 U.S. NRC Interim Staff Guidance DI&C-ISG-04, Highly-Integrated Control Rooms Communications Issues (HICRc), September 28, 2007 (ADAMS Accession No. ML072540138).

D.8 Wilcoxon Pump monitoring guide. https://wilcoxon.com/wp-content/uploads/2019/01/Pump-monitoring-guide.pdf D.9 M. van der Meulen, On the Use of Smart Sensors, Common Cause Failure and the Need for Diversity, Centre for Software Reliability, City University, London.

D.10 Yanliang Zhang and Vivek Agarwal, Thermoelectric Generator for Efficient Power Harvesting for Self-powered Sensor Nodes, Advanced Sensors and Instrumentation, Issue 5, September 2016.

D.11 K. Harsh and L. Frediani, Sporian Microsystems, Inc., A High Temperature High Reliability Control Rod Position Sensor for Improved Nuclear Power System Instrumentation, Advanced Sensors and Instrumentation, Issue 5, September 2016.

D.12 L. Zuo, Self-powered Wireless Through-wall Data Communication for Nuclear Environments, U.S. DOE, Advanced Sensors and Instrumentation Annual Webinar, October 31 - November 1, 2018.

D-18

D.13 International Atomic Energy Agency, Technical Challenges In The Application And Licensing Of Digital Instrumentation And Control Systems In Nuclear Power Plants, IAEA Nuclear Energy Series No. NP-T-1.13, Vienna, 2015.

D.14 EPRI 3002017641, EPRI Research Helps Ontario Power Generation (OPG) Deploy Its First Wireless Sensor Network at One Plant, Electric Power Research Institute, Palo Alto, CA, Dec 23, 2019.

D.15 J. Dion, M. K. Howlander, and P. D. Ewing, Wireless Network Security in Nuclear Facilities, NPIC&HMIT 2010, Las Vegas, Nevada, November 7-11, 2010. (Adams Accession No. ML103210371)

D.16 B.J. Kaldenbach, et. al., Assessment of Wireless Technologies and Their Application at Nuclear Facilities, NUREG/CR-6882, Oak Ridge National Laboratory, July 2006.

D.17 M. Howlader, C.J. Kiger and P.D. Ewing, Coexistence Assessment of Industrial Wireless Protocols in the Nuclear Environment, NUREG/CR-6939, Oak Ridge National Laboratory, July 2007.

D.18 U.S. NRC, NRC Notice of Meeting with the Nuclear Energy Institute February 20, 2020.

(NRC ADAMS Accession No. ML20063L416)

D.19 M. Anderson, Securing Embedded LINUX, [PowerPoint Presentation] Embedded Linux Conference, San Diego, CA April 4-6 2016 https://elinux.org/images/5/54/Manderson4.pdf D.20 Yanliang Zhang and Darryl P. Butt, Vivek Agarwal, Zhifeng Ren, Nanostructured Bulk Thermoelectric Generator for Efficient Power Harvesting for Self-powered Sensor Networks, Advanced Sensors and Instrumentation Award Summaries, Nuclear Energy Enabling Technologies - Advanced Sensors and Instrumentation, May 2016.

D.21 An Introduction to MEMS (Micro-electromechanical Systems), PRIME Faraday Partnership, Wolfson School of Mechanical and Manufacturing Engineering Loughborough University, Loughborough, Leics, 2002.

https://anastasiadiskonstantinos.appspot.com/pdf/mems.pdf D.22 Addison Engineering, Inc. About MEMS.

https://www.addisonengineering.com/about-mems.html D.23 C. Elks, T. Bakker, and M. Gibson, Verifiable Digital I&C and Embedded Digital Devices for Nuclear Power, Advanced Sensors and Instrumentation, United States Department of Energy, Issue 6, March 2017, pp. 1-4.

https://www.energy.gov/sites/prod/files/2017/03/f34/NEET-

%20Advanced%20Sensors%20and%20Instrumentation%20Newsletter%20-

%20Issue%206%20March%202017_4.pdf D-19

D.24 Vernon R. Schmitt, Gavin D. Jenney, and James W. Morris, Fly-by-Wire, SAE International, 1998.

D.25 Kenzo Nonnami, Farid Kendoul, and Satoshi Suzuki, Autonomous Flying Robots, Springer, 2010.

D.26 Rudolph E. Kalman, A New Approach to Linear Filtering and Prediction Problems, Trans.

of the ASME - Journal of Basic Engineering, Vol. 82, Series D, pp. 35-45, 1960.

D.27 Paul D. Groves, GNSS, Inertial, and Multisensor Integrated Navigation Systems, Artech House, 2013.

D.28 Osvaldo Barbarisi, Giovanni Palmieri, Stefanos Scala, Luigi Glielmo , LTV-MPC for Yaw Rate Control and side Slip Control with Dynamically Constrained Differential Braking, European Control Conference, 2009.

D.29 Chris Chin, 5 Crazy Technologies That Make the 2018 GTC4lusso the Ultimate Year-Round Ferrari, 2018. [Online]. Available: https://www.digitaltrends.com/cars/five-crazy-technologies-in-the-2018-ferrari-gtc4lusso/. [Accessed: 2-Jan-2019].

D.30 Alex Davies, Inside the Races that Jump-Started the Self-Driving Car, 2017. [Online].

Available: https://www.wired.com/story/darpa-grand-urban-challenge-self-driving-car/.

[Accessed: 2-Jan-2019].

D.31 Juan-Antonio Fernandez-Madrigal and Jose B. Claraco, Simultaneous Localization and Mapping for Mobile Robots: Introduction and Methods, IGI Global, 2012.

D.32 Dale Shu and Constantino M. Lagoa, A Linear Temporal Logic Based Approach for Vehicle Motion Planning, IEEE Int. Conf. on Mechatronics, Churchill, VIC, Australia, 2017.

D.33 Andrzej Wardzinski, Dynamic Risk Assessment in Autonomous Vehicles Motion Planning, Int. Conf. on Information Technology, Gdansk, Poland, 2008.

D.34 Roger A. Kisner, et al., Embedded Sensors and Controls to Improve Component Performance and Reliability: Conceptual Design Report, ORNL Report, ORNL/TM-2012/433, 2012.

D.35 Roger A. Kisner et al., Evaluation of Manufacturability of Embedded Sensors and Controls with Canned Rotor Pump System, ORNL Report, ORNL-TM-2013/269, July 2013.

D.36 Alexander M. Melin, Roger A. Kisner, and David L. Fugate, Embedded Sensors and Controls to Improve Component Performance and Reliability: System Dynamics Modeling and Control System Design, ORNL Report, ORNL/TM-2013/415, September 2013.

D.37 L. S. Fifield, State of Electrical Cable Aging in U.S. Nuclear Power Plants, Transactions of the American Nuclear Society, Vol. 118, Philadelphia, Pennsylvania, June 17-21, 2018.

D.38 D. D. Dudenhoeffer et. al., Technology Roadmap on Instrumentation, Control, and Human-Machine Interface to Support DOE Advanced Nuclear Energy Programs, INL/EXT 11862, March 2007.

D-20

D.39 C. M. Petrie, Embedding Sensors in Metal and Ceramic Structures, ANS Annual Meeting, Phoenix, Arizona, June 7-11, 2020.

D.40 Department Of Energy Announces $35 Million To Develop Tools To Transform Operations And Maintenance Of Advanced Nuclear Reactors. https://arpa-e.energy.gov/news-and-media/press-releases/department-energy-announces-35-million-develop-tools-transform D.41 Elks C., Jayakumar A., Collins A., Hite R., Karles T., Deloglos C., Simmons B., Tantawy A.,

Gautham S. (2019). Preliminary Results of a Bounded Exhaustive Testing Study for Software in Embedded Digital Devices in Nuclear Power Applications (Report INL/

EXT-19-55606), U.S. Department of Energy, Office of Nuclear Energy.

D.42 McDermott T.A., Hutchison N., Clifford M., Van Aken E., Salado A. Henderson K.,

Benchmarking the Benefits and Current Maturity of Model-Based Systems Engineering across the Enterprise (Technical Report SERC-2020-SR-001). Stevens Institute of Technology, March 19, 2020.

D.43 Simensen J., Sarshar S., (2016) Digital Instrumentation and Control Asurance - Systematic Literature Review (Report HWR-1184) OECD Halden Reactor Project.

D.44 Gibson M., Elks C., Tantawy A., Hite R., Gautham S., Jayakumar A., Delogos C., (2019)

Design, Verification and Demonstration of the SymPLe Architecture and Methodology (Milestone - M2CA-15-CA-EPRI-0703-0221 2019) U.S. Department of Energy, Advanced Sensors and Instrumentation Program.

D.45 Architecture Analysis & Design Language (AADL), SAE International Standards document AS5506A, Nov 2004, Revised Jan 2009. http://www.sae.org/technical/standards/AS5506A.

D.46 Feiler, Peter H. and Gluch, David P. Model-Based Engineering with AADL: An Introduction to the SAE Architecture Analysis & Design Language, Addison-Wesley (2012).

D.47 Neyret, Maxime, Model-Based Verification of I&C Specifications, in ANS NPIC&HMIT 2017, San Francisco, CA, USA., 2017.

D.48 J. Yoo, E.-S. Kim, D.-A. Lee, J.-G. Choi, Y. J. Lee, and J.-S. Lee, NuDE 2.0: A Model-Based Software Development environment for the PLC & FPGA Based Digital Systems in Nuclear Power Plants, in Integrated Circuits (ISIC), 2014 14th International Symposium on, 2014, pp. 604-607.

D.49 Pakonen, A., Tahvonen, T., Hartikainen, M., Pihlanko, M., Practical Applications of Model Checking in the Finnish Nuclear Industry, in 10th International Topical Meeting on Nuclear Plant Instrumentation, Control, and Human-Machine Interface Technologies, NPIC and HMIT 2017Volume 2, 2017, Pages 1342-1352.

D.50 Wassyng A., Lawford M., Maibaum T., Software Certification Experience in the Canadian Nuclear Industry: Lessons for the Future, Proceedings of the 11th International Conference on Embedded Software, EMSOFT 2011, part of the Seventh Embedded Systems Week, ESWeek 2011, Taipei, Taiwan, October 9-14, 2011.

D-21

D.51 EPRI 23002000509, Hazard Analysis Methods for Digital Instrumentation and Control Systems, Electric Power Research Institute, Palo Alto, CA: 2013.

D.52 EPRI 3002012755, HAZCADS: Hazards and Consequences Analysis for Digital Systems, Electric Power Research Institute, Palo Alto, CA: 2018.

D.53 EPRI 3002011816, Digital Engineering Guide: Decision Making Using Systems Engineering, Electric Power Research Institute, Palo Alto, CA: 2018.

D.54 Thomas J., Lemos F., Leveson N., (2012) Evaluating the Safety of Digital Instrumentation and Control Systems in Nuclear Power Plants (Research Report: NRC-HQ-11-6-04-0060)

D.55 James E. Tomayko, Computers Take Flight: A History of Nasas Pioneering Digital Fly-By-Wire Project, NASA SP-2000-4224, Washington, DC, 2000.

D.56 Yang Guojun, Xu Yang, Shi Zhengang, and Gu Huidong, Characteristic analysis of rotor dynamics and experiments of active magnetic bearing for HTR-10GT, Nuclear Engineering and Design, 237, 2007, 1363-1371.

D.57 D.A. Copinger, D.L. Moses, Fort Saint Vrain Gas Cooled Reactor Operational Experience, NUREG/CR-6839, ORNL/TM-2003/223, January 2004.

D.58 A. Melin, R. Kisner, and R. Vidrio, Embedded Instrumentation & Control for Extreme Environments, Advanced Sensors and Instrumentation, Issue 5, September 2016.

D-22

APPENDIX E DATA COMMUNICATION PROTOCOLS The information in this appendix does not represent an evaluation of data communication protocols but is a collection of information found during other evaluations provided as an information resource for the reader.

In many cases communication issues may be dealt with at the system level, using existing guidance as required for the system level interactions depending on the nature of the connectivity.

NUREG/CR-6082 (ADAMS Accession Number ML063530379) is cited as a source of additional guidance on protocols in revision 6 of section 7.9 Data Communication systems in chapter seven of the Standard Review Plan. However, as that was published in 1993, there may be value in updated guidance including the protocols referenced below.

Transmitters with EDDs typically use one or more of several protocols to communicate digitally:

Highway Addressable Remote Transducer (HART) Communication protocol, FOUNDATION fieldbus protocol, PROFIBUS PA protocol, or WirelessHART protocol [E.1]. An EDD can be compatible with several communication protocols. For example, the Fisher FIELDVUE DVC6200 Series digital valve controller is available with either the HART 5 or 7, WirelessHART FOUNDATION fieldbus, or PROFIBUS communication protocol.

Manufacturing industries have been implementing loT concepts for more than 20 years. (IoT is discussed in the other names used for smart devices.) In fact, the HART communication protocol was developed in the early 1990s to provide digital data from smart sensors previously providing one data point [E.2]. The estimated installed base of HART devices is more than 40 million.

Other open standards such as EtherNet/lP and Foundation Fieldbus that were developed in the late 1990s enabled placing sensors directly on networks.

IEC 61784 [E.3, E.4, E.5] lists specifications for seven fieldbus technologies (protocols):

1. FOUNDATION Fieldbus (FFB),

2. ControlNet,

3. Process Field Bus (PROFIBUS),

4. P-NET,

5. WorldFIP,

6. INTERBUS, and

7. SwiftNet.

Other communications protocols that support intelligent sensors (and EDDs) include:

• Highway Addressable Remote Transducer (HART)

• Device Net The HART version of the Rosemont 3144P has an independent circuit that triggers an alarm if the microprocessor fails, whether the failure takes place in hardware or software. A typical EDD transmitter will condition its output signal with its microprocessor, so a failure in the microprocessor cuts off the output signal [E.1].

ET will most likely result in devices or parts of a device communicating to a central processor.

Such an arrangement would require a communication protocol to ensure independence. A communications isolator may be sufficient to ensure independence. An advantage of these EDDs is the modular fashion in which they can be connected to central processing units. The advances E-1

in digital communication capabilities have also radically changed the way that the design and specification of such systems must be approached and have created major issues relative to system design and security.

With the connection to a central processor, the information from the devices could be used in different ways such as to balance heat loads, reduce stressors in one loop to extend lifetimes, etc.

API RP 554 is a recommended practice (RP) from the American Petroleum Institute (API) published to facilitate the broad availability of proven, sound engineering and operating practices.

API RP 554 has been divided into three parts, each focusing on a major aspect of process control systems. The three parts and the areas that they cover are:

• Part 1, Process Control System Functions and Functional Specifications [E.6], covers the basic functions that a process control system may need to perform, and describes recommended methodologies for determining the functional and integration requirements for a particular application.

• Part 2, Process Control System Design [E.7], covers the hardware and software applied to process control systems and provides recommendations for implementation. Design considerations and references to design practices for control centers and other control system buildings and enclosures are also provided.

• Part 3, Process Control System Project Execution and Ownership [E.8], covers project organization, skills and work processes required to execute a process control project and then to own and operate process control systems.

It states that these issues are related to the increased use of EDDs [E.6]:

• The virtual disappearance of conventional central control room control panels.

• Advances in computing power, software standards and communications standards have resulted in many of the functions historically implemented in stand alone process control and historization computers being integrated within the Process Control Systems. This has greatly expanded the scope of Process Control System design and blurred the division between real time control and historization functions and higher-level information systems that provide input to business and maintenance systems.

• Advances in field instrumentation design leading to the general use of smart digital field instrumentation. Further advances in fieldbus and related technologies allow these smart instruments to communicate directly with the Process Control Systems or with each other. These instruments not only transfer information about the basic process measurement, but also communicate diagnostic information about the health of the device or other secondary information derived from the primary measurements.

• Further developments in standardization of operating systems and software practices have enabled use of standard computer components and peripherals operating on standard operating systems.

This has resulted in a developing trend away from control systems applications being implemented on proprietary hardware and software systems, but rather being implemented on standard personal computer, workstation and network communication products running widely available operating systems.

E-2

• This standardization has reduced the cost and increased the flexibility of the systems. It has also resulted in greater exposure of the Process Control System to external interference and requires additional support to keep the operating systems current and secure.

• Security and virus-protection are major concerns of newer Process Control Systems and must be addressed at both the design and operational phases.

The communication paths to external systems, should have Cyclic Redundancy Checks, handshaking, and other protocol-based features, depending on which devices are attached to the communication modules and how the communication modules are programmed. In such cases, the EDD and any devices it is connected to would need to ensure that failures such as a melting fiber optic cable or otherwise compromised communication pathway will not cause erroneous operation or affect the continued operation of all automatic safety-related or nonsafety systems.

The data communication in an EDD should be similar to that for a system. For example, in its Safety Guide, the IAEA provides the following guidance for a system [E.9]:

• Each message sent and received via digital data communication should be automatically checked and flagged if errors are identified.

• Errors might include corrupted data, invalid data (unplanned messages) or inauthentic messages (messages from unexpected sources).

• If communications systems encrypt data or use proprietary protocols, these features should not prevent detection of errors.

• The actions to be taken when errors are detected in data communications should be defined in advance.

• Actions that might be taken when errors are detected include the automatic rejection of invalid or inauthentic data, the correction of corrupted data, where possible, or the rejection of corrupted data.

• The design should ensure that failures of data transmission and of the data communication equipment are detected, that suitable alarms are provided to the operators and that records are made for analysis of performance.

• The existence of certain types of error in digital data communication does not by itself constitute a failure in the system as such errors are expected and communication protocols are designed to deal with certain types of error and a range of occurrence rates of errors. Consequently, the application will involve specification of what constitutes a failure of data transmission. The criteria might, for example, specify a maximum allowable time interval between successful transmissions or a maximum error rate.

• Features for the detection and correction of errors improve the reliability of signal transmission.

• The extent of methods used for dealing with errors and detection of communications failures should be appropriate for the use of the data, appropriate for the frequency of demand for the functions that use the data and balanced against the complexity that is introduced.

• If the communication of safety related data malfunctions in any way, the safety system should continue to perform its safety function or go to a safe state.

E-3

E.1 References E.1 T. Jacobi et al., Investigation of Instrumentation Containing an Embedded Digital Device, NPIC&HMIT 2017, San Francisco, CA, June 11-15, 2017.

E.2 10 steps to lloT success. https://www.plantservices.com/articles/2017/automation-zone-10-steps-to-iiot-success/

E.3 International Electrotechnical Commission, Digital data communications for measurement and controlPart 1: profile sets for continuous and discrete manufacturing relative to fieldbus use in industrial control systems, IEC 61784-1, Geneva, Switzerland, 2001.

E.4 International Electrotechnical Commission, Digital data communications for measurement and controlPart 3: Profiles for functional safety communications in industrial networks, IEC 61784-3, Geneva, Switzerland, 2006.

E.5 International Electrotechnical Commission, Industrial communication networks - Profiles -

Part 3-1: Functional safety fieldbuses - Additional specifications for CPF 1, IEC 61784-3-1, Geneva, Switzerland, 2007.

E.6 American Petroleum Institute , Process Control Systems, Part 1Process Control Systems, Functions and Functional Specification Development, API Recommended Practice 554, Second Edition, July 2007, REAFFIRMED, NOVEMBER 2016.

E.7 American Petroleum Institute , Process Control SystemsProcess Control System Design, API Recommended Practice 554, Part 2, First Edition, October 2008, Reaffirmed, November 2016.

E.8 American Petroleum Institute , Process Control Systems-Project Execution and Process Control System Ownership, API Recommended Practice 554, Part 3, First Edition, October 2008.

E.9 International Atomic Energy Agency, Design of Instrumentation and Control Systems for Nuclear Power Plants, IAEA Safety Standards Series No. SSG-39, Vienna, 2016.

E-4

NRC FORM 335 U.S. NUCLEAR REGULATORY COMMISSION 1. REPORT NUMBER (12-2010) (Assigned by NRC, Add Vol., Supp., Rev.,

NRCMD 3.7 and Addendum Numbers, if any.)

BIBLIOGRAPHIC DATA SHEET (See instructions on the reverse) NUREG/CR-7273

2. TITLE AND SUBTITLE 3. DATE REPORT PUBLISHED MONTH YEAR Developing a Technical Basis for Embedded Digital Devices and March 2021 Emerging Technologies

4. FIN OR GRANT NUMBER

5. AUTHOR(S) 6. TYPE OF REPORT Muhlheim, M. D., Poore, W. P., Nack, A. M., Wood, R. T., Melin, A. M.,

Technical Bull Ezell, N. D., Hale, R. E., Holcomb, D. E., Huning, A. J., Halverson, D. S.

7. PERIOD COVERED (Inclusive Dates)

8. PERFORMING ORGANIZATION - NAME AND ADDRESS (If NRC, provide Division, Office or Region, U. S. Nuclear Regulatory Commission, and mailing address; if contractor, provide name and mailing address.)

Oak Ridge National Laboratory Managed by UT-Battelle, LLC Oak Ridge, TN 37831-6285

9. SPONSORING ORGANIZATION - NAME AND ADDRESS (If NRC, type "Same as above", if contractor, provide NRC Division, Office or Region, U. S. Nuclear Regulatory Commission, and mailing address.)

Division of Engineering Office of Nuclear Regulatory Research U.S. Nuclear Regulatory Commission Washington, DC 20555-0001

10. SUPPLEMENTARY NOTES

11. ABSTRACT (200 words or less)

This report provides a technical basis for evaluating the safe use of EDDs in commercial nuclear power plants (NPPs) in the United States (U.S.), along with relevant observations, based on their classification, functionality, configurability, consequences of failure, and potential for common-cause failures (CCFs), and it reviews how other agencies worldwide, both nuclear and nonnuclear, regulate, approve the use of, and actually use EDDs.

Areas of interest include the types of components in safety-related applications most likely to have EDDs, methods used by other industries and countries to regulate the use of EDDs, and potential issues noted in industry. This information serves to support the technical basis for a graded approach in the selection and use of EDDs. A tangential supply chain issue is the use of replacement parts or parts in upgrades that may contain an undeclared digital device, as it may not meet the requirements for the safety-related application it is being used in.

Other attributes such as reliability (the ability to perform with correct, consistent results), diagnostics, operating experience, and failure modes were reviewed because of their use in risk informing the acceptance of the use of EDDs. Emerging technologies associated with EDDs were noted during this work, and are described in this report.

12. KEY WORDS/DESCRIPTORS (List words or phrases that will assist researchers in locating the report.) 13. AVAILABILITY STATEMENT Embedded Digital Device, EDD, Emerging Technologies unlimited

14. SECURITY CLASSIFICATION (This Page) unclassified (This Report) unclassified

15. NUMBER OF PAGES

16. PRICE NRC FORM 335 (12-2010)

NUREG/CR-7273 Developing a Technical Basis for Embedded Digital Devices and March 2021 Emerging Technologies